数据库安全

closures它，并擦拭磁盘….几次。 稍微不太极端的是

首先确保服务器，存储，networking和操作系统级别的安全

1. 数据库服务器应该有最小的开放端口（例如，在端口22上的SSH和在1521上的监听器）。 也要注意传出连接。 数据库可以发出HTTP请求，发送电子邮件和各种各样的东西….你可能不希望在一个安全的环境。
2. 没有人应该访问数据库服务器。 实际上，最高级的DBA可能需要访问，如果高级DBA生病或者不可用，则需要一名副主pipe。 您可能需要审核所有访问权限。 您可能需要强制DBA在可以访问服务器之前实际请求系统pipe理员的访问权限。 你可能想locking他们可以访问它（即特定的工作电脑），也可能是时间。
3. 应使用透明数据encryption，以便数据库中的所有数据在encryption文件之前进行encryption。 所以即使有人拿到磁盘或备份，他们也无法读取它们
4. 您可能需要encryption数据库和应用程序之间的networking通信。

接下来你想locking用户数据库访问

1. 通常，架构所有者只能在安装/升级时才需要访问。 除此之外，模式应该被locking。
2. 在数据库中分离出应用程序层是比较安全的，这样应用程序帐户只能执行预定义的函数（即不能删除表中的每一行）。 数据库应用程序层对于SQL注入来说是一个非常好的防御措施，因为连接的用户根本没有对表的select权限。
3. 将encryption值优先存储为纯文本，并将散列值优先于encryption值并存储不需要的内容。 你真的需要人的姓名，地址，电话号码，信用卡，SSN，密码吗？
4. 根据您的体系结构，您可能受益于定期过期的密码，或通过其他机制进行身份validation。

别忘了DR。 当我在开玩笑擦拭磁盘时，如果您的风险评估是有人会在几天（或永久）中停业，那么烧毁您的数据中心是一个安全问题。

下面是一个SQL Server安全清单，看起来主要关注SQL Server本身的configuration： http : //www.sqlsecurity.com/FAQs/SQLSecurityChecklist/tabid/57/Default.aspx

另外（如果你不能依靠windows唯一的安全模型），你还需要通过encryption连接string的必要练习。

一个相当开放的问题。

一个好的开始是阅读一些基础知识， 维基百科有一个很好的文章 。 那么你必须查看你的具体系统的细节。 几乎所有的数据库引擎都提供了一堆信息来明确如何保护他们的系统。 不要忘了查看地平线：不仅要保护数据库，还要运行系统。

SQL注入是常见的，但是需要注意的许多安全问题之一。

在Oracle中，我所看到的频繁的deviseselect是，应用程序始终以单个数据库用户/模式login – 该应用程序的所有对象的所有者。

更好的devise是拥有一个拥有应用程序对象的用户/模式，然后从该用户REVOKE CREATE SESSION 。 然后，创build另一个用户/模式，该用户/模式将不会拥有应用程序用来login数据库的对象（可能除了同义词）。 然后，向应用程序用户发出最低限度的必要授权（SELECT，INSERT，UPDATE，DELETE，EXECUTE等）。

这样，即使应用程序中的错误可能允许用户执行某些他们不应该执行的操作（例如从表中删除logging），那么您的数据库特权将确保不会发生。

否则，如果应用程序以所有者的身份login，则无法对任何对象进行REVOKE权限。