Practice for云数据库安全

主要阅读了谷歌云平台的一篇文章，大概梳理翻译了一下：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的风险。

其他阅读资料：

• OWASP Secure Configuration Guide

• OS-specific hardening guides

• Ubuntu

• RedHat

• Debian

• CentOS

• CoreOS

• SUSE Linux

• Windows Server

• DB-specific hardening guides

• MySQL

• PostgreSQL

• MSSQL

• Oracle

• MongoDB

• Redis

• Google Cloud Storage

• 2017 NIST Digital Identity Guidelines