![数据库安全](https://linux22.com/image/542087/%E6%95%B0%E6%8D%AE%E5%BA%93%E5%AE%89%E5%85%A8.png)
为了拥有一个安全的数据库,应该考虑哪些方面?
除了避免之外sqlInjection
,还应该考虑什么?应该考虑什么不是做完了?
答案1
关机并清除磁盘……多次。稍微不那么极端的是
首先确保服务器、存储、网络和操作系统层面的安全
- 数据库服务器应具有最少的开放端口(例如,仅在端口 22 上启用 SSH,在端口 1521 上启用监听器)。还要注意传出连接。数据库可以发出 HTTP 请求、发送电子邮件和各种事情……在安全环境中,您可能不希望发生这种情况。
- 任何人都不应访问数据库服务器。实际上,最资深的 DBA 可能需要访问,并且如果高级 DBA 生病或因其他原因无法访问,还需要一名副手。您可能希望审核所有访问。您可能希望强制 DBA 在访问服务器之前向系统管理员请求访问权限。您可能希望锁定他们可以从哪里访问它(即特定的工作 PC)以及可能的时间。
- 应使用透明数据加密,以便数据库中的所有数据在进入文件之前都经过加密。这样即使有人拿到了磁盘或备份,他们也无法读取它们
- 您可能希望加密数据库和应用程序之间的网络流量。
接下来要锁定用户数据库访问
- 通常,仅当安装/升级时才需要架构所有者的访问权限。除此之外,架构应被锁定。
- 在数据库中分离出一个应用程序层,这样应用程序帐户只能执行预定义的功能(即不能删除表中的每一行)会更安全。数据库应用程序层是防御 SQL 注入的非常好的方法,因为连接的用户根本没有表的选择权限。
- 存储加密值时优先于明文,存储散列值时优先于加密值,并且不要存储任何不需要的内容。您真的需要人们的姓名、地址、电话号码、信用卡、SSN 和密码吗?
- 根据您的架构,您可能会受益于定期过期的密码或通过其他机制进行身份验证。
别忘了 DR。虽然我开玩笑说要擦除磁盘,但如果你的风险评估是有人会让你停业几天(或永久停业),那么烧毁你的数据中心就是一个安全问题。
答案2
以下是 SQL Server 安全性的检查表,其似乎侧重于 SQL 服务器本身的配置: http://www.sqlsecurity.com/FAQs/SQLSecurityChecklist/tabid/57/Default.aspx
此外(如果您无法依赖仅限 Windows 的安全模型)您还需要完成加密连接字符串所需的练习。
答案3
这是一个相当开放的问题。
一个好的开始是阅读一些基础知识,维基百科有一篇很好的文章那就得研究一下具体系统的细节。几乎所有数据库引擎都提供了大量关于如何具体保护系统的信息。别忘了放眼长远:不仅数据库要“安全”,运行它的系统也要“安全”。
SQL 注入是一个常见的安全问题,但也是需要注意的众多安全问题之一。
答案4
在 Oracle 中,我看到的一个常见的设计选择是应用程序始终以单个数据库用户/模式(该应用程序所有对象的所有者)的身份登录。
更好的设计是让一个用户/架构拥有应用程序的对象,然后REVOKE CREATE SESSION
从该用户那里获取。然后,创建另一个用户/架构,该用户/架构不拥有应用程序用于登录数据库的任何对象(同义词除外)。然后,向应用程序用户发出最低限度的必要授权(SELECT、INSERT、UPDATE、DELETE、EXECUTE 等)。
这样,您就知道,即使应用程序中的错误可能允许用户做一些他们不应该做的事情(例如从表中删除记录),您的数据库权限也会确保它不会发生。
否则,如果应用程序以所有者身份登录,则不可能REVOKE
对任何对象拥有任何特权。