主要阅读了谷歌云平台的一篇文章，大概梳理翻译了一下：https://cloudplatform.googleblog.com/2018/04/best-practices-for-securing-your-Google-Cloud-databases.html
Security is a journey, not a destination
1. First Considerations
首先要明确目标，是自己部署一个DB server？ 或者是使用cloud provider的数据库服务？
2. Access Controls
尽可能的缩小数据库访问的权限。
- 防火墙。VPC Firewalls Rules, 只允许固定几个已知的host访问。
- 防火墙监控。对于防火墙的变化，有日志以及alert报警。可以使用工具：Forseti Security，有些云平台本身也具备这些功能
3. Data Security
- data retention policy（数据保留策略）。不需要的敏感数据可以被存档或者删除。有许多法规(HIPAA, PCI, GDPR, SOX)来保护敏感数据。
- 监控报警： 如果发生一些威胁到数据库的情况，应当收到报警，比如过高的流量负载。
- 金丝雀数据：数据库中有一些正常时候永远也访问不到的数据。如果这些数据出现在log或者网络传输中，应当立即报警并自动采取一些强制措施。
- 容灾恢复计划：制定与测试容灾恢复计划。比如备份数据库。好的容灾计划应当考虑到尽可能多的情况：数据丢失、硬件损坏、网络问题等等。并且经常的测试backup system可以正常work
4. Configuration
登录：
- 如果你的DB使用了默认账户，你首先就应该change || disable掉它。
- 如果DB使用密码登录，确保密码够长够复杂
- 此外，确保定期更换credential，制定一个更换时间表；并制定一个周期外更新credentials的规则，比如密码错误push到代码库上了，肯定要更新一次。
- 有些Cloud Service本身提供的一些服务，比如 Google Key Managed System
权限
- read, write, admin不同的权限应当有不同的credentials，尽管一个应用既有read, 又有write的权限。可以减少bad code或者其他的风险
- 不同的人应当有自己访问数据库的账号，并且给予账号所需的最小权限
日志与记录
- 日志。尤其是对于登录尝试、admin操作，要有记录。此外日志权限与数据库权限分开管理。
- 对于暴力强制的登录方式，需要有monitoring & alert
- OS中为DB创建一个专门的用户，而不是使用root或者admin用户。host上的文件应当被赋予合适的权限，来阻止其他用户对文件的修改。
image.png
5. Application Consideration
-
连接。设计app时候，app与db的连接使用加密连接。防止通过网络嗅探导致泄密
image.png - 数据保留。如果app本身保留了一些敏感数据，确认你需要保留他们，并且采取一些额外的措施来保证他们的安全，以避免相应的法律风险。比如用户你如果只想知道他们是否是同一个，你可以把他们的身份id替换成hash值
- 发送的数据：所有发送到数据库的输入，都必须设置如sanified这样的安全措施。应用代码需经过同行评审，对常见的安全漏洞，如SQL注入和XSS，需要有频繁的自动化安全扫描
- 硬件任何有权访问数据库的人和计算机都应遵守组织安全策略
- 多环境，任何情况下不要在开发或者测试环境使用unsanitized的生产环境的数据。可以增加数据库安全性，也避免一些对生产环境的误操作，比如不小心给用户发邮件，账户充值，等。
6. Self-Host DB concerns
通常云提供商都有很多数据库的保护措施，而自己host的话需要管理员确保每种攻击方式都被secured.
- 数据库拥有一个独立的host，而不与其他service共享，并且确保最小访问权限。
- self-host常见混合云的情况，通常在云上有一个master节点以及多个replicas节点，甚至本地也有一个副本。确保不要把数据库连到公司局域网，或其他公开网络。同时本地物理机器也应当physically secure，防止被盗
- Regular Attention, 确保数据库版本更新。
- IDS 入侵检测系统
- 阅读数据库本身的文档，很多数据库都有特别的权限控制以及安全建议, Hardening Guid.
- 本身底层的操作系统也应当尽量保证安全。并且与DB不相关的服务都应该被停掉。可以通过sandbox或者container进行进一步隔离。
- 阅读OS maker的文章，来harden os
7. Organizational Security
这个话题可就大了。。。但是有些与DB相关的。
- 所有能接触到敏感数据的人，都应该考虑背景、尤其是犯罪背景调查。
- 人员下项目时候，立刻取消或锁定用户账户
- 用户账户密码遵守 2017 NIST Digital Identity Guidelines,
- 执行social engineering penetration tests 以及培训，来减少员工无意中导致attack的风险。
其他阅读资料：
OS-specific hardening guides
DB-specific hardening guides
