需要考虑的数据库相关安全政策_MySQL

　　从技术上来说，为了准确判断需要哪个安全政策，你需要执行信息风险评估。然而，我理解，现实情况经常会导致其它内容。就是说，我可以考虑得很少，如果有的话，但是几乎很少有不再要求我思考如下数据库相关安全政策的环境出现：

　　?可接受的利用率――什么可以/不可以在数据库服务器上完成，例如网络浏览和安装/卸载中间件，以及个人防火墙保护，还有MSDE, SQL Server Express 2005，以及其它非服务器系统上的数据库软件的安装。

　　?认证控制――对于数据库，以及有关应用程序和操作系统来说，包括密码的要求，多种成分的使用等。

　　?业务合作――应对外部承包人、审计人员、寄存提供者商等，包括合同规定和应用的服务级别的协商。

　　?业务连续性――灾难恢复和/或业务连续性计划要求可以帮助你的数据库保持运转状态，可以访问。

　　?变更管理――记录谁、为什么、在什么时候，如何，以及所有相关的拆除过程。

　　?数据备份――什么，什么时候，以及使用的方法。

　　?数据保持和破坏――什么，为什么，使用的方法和时间线。

　　?加密――不仅覆盖了静止的数据，例如加密特定的行，还覆盖了传输的数据，例如数据库服务器和网络应用程序之间的TLS。数据备份也是覆盖的一部分。

　　?信息分类――为信息贴上公共、内部、机密等标签。

　　?物理安全――构建，数据中心和服务器的安全。

　　?财产的删除――服务器，驱动，磁带，和其它财产。

　　?安全测试和审计――什么，如何，什么时候，以及谁执行的测试，用的什么工具。

　　?职责的分隔――用户，数据库管理员，安全审计员，以及其它与数据库管理有关的人的角色/职责。

　　?系统维护――打补丁，系统清理/清楚和中间件的更新。

　　?系统监控和意外事件的响应――谁，为什么，什么时候，以及如何进行实时监控和记录审计日志，还有为了维护正式的意外响应计划所需要的特殊需求。

　　?用户授权――添加/删除用户，授予谁，为什么，什么时候，多长时间的管理权限。

　　我认为这里有几个关键点需要与数据库中心的安全政策相关。首先，如果管理层没有明确表示他们的支持(例如，他们将会接受并强制政策的执行)，你兴许也只能一起放弃这个计划。所以首先要把他们也拉上船。其次，尽可能地把你的政策提到最高级别上，这样你就可以最大化覆盖的部门和系统。最大化规则的数量，你可以真正地实施它。换句话说，如果你可以帮助它，不在你的数据库中发生以上所有的政策，并且在无线网络、存储系统等等中拥有另一套规则。同样，至少也要理解你的企业对解决PCI, GLBA, HIPAA, SOX等问题上的规则上的调整需求。这一点在你有一个依从性或者IT管理委员会来审视和现实安全政策的时候，可以带来最好的帮助。如果你能帮助它的话，你不会想要你自己管理一套政策。

　　最后，确保你尽可能地以一种可以直接带来最大理解和管理的方式记录你的政策。以下政策中的组成部分对于保证政策的简单性和长期的可管理性是至关重要的。

　　?简介――对题目的简单概括，例如加密

　　?目的――简单列出最高的目标和方针的策略。

　　?范围――说明覆盖了哪些雇员、部门和数据库系统。

　　?角色和职责――列出与谁有关，以及要他们支持政策的话，需要他们做什么。

　　?政策的陈述――你的真正的政策的陈述。你应该对每个主题有一篇陈述。换句话说，为前面列出的你选择使用的每个政策创建一个单独的模版。

　　?例外情况――强调没有包括在政策里面的人，部门，数据库等。

　　?过程――政策如何实现和在你的环境内强制执行的详细步骤。你可能会想要参考这个信息，并且把它放在不同的文件中。

　　?遵循――列出如何衡量是否遵循了这个政策的过程，包括所有涉及的衡量标准。

　　?制裁――列出当违反了政策时候会发生的事情。这可能包括了第一次违反的时候发生什么事情，第二次违反的时候发生什么事情，以及第三次违反的时候发生什么事情。

　　?回顾和评估――说明什么时候政策必须检查其准确性、实用性，以及遵循的目的(例如，. SOX, HIPAA, GLBA, PCI等)。

　　?参考――指出调整代码部分河信息安全标准(ISO/IEC 17799, ITIL, COBIT等)

　　?相关文档――指出其它政修订――记录针对这个政策文档进行的修改。

　　?修订――记录针对这个政策文档进行的修改。

　　?注意事项――最重要的注意事项，贴士等。它可以帮助以后的政策管理和加强。

　　如果你以正确的方式做完了以上所有内容来构建你的政策，它会在很长一段时间内节省你大量的时间和烦恼，让你的审计员很高兴。良好的回报值得你的努力。