Day23-你的资料安全吗（一）

前言

就如第一天提到的，资料库可以说是一家公司的命脉，如果资料库不小心被外部攻击者入侵导致资料遗失、外泄，或是不小心被公司新来的实习生误删，那造成的损失之大几乎可以使一家公司倒闭

因此对外如何把自己的资料库保护好，对内如何防止自己人手滑失误，是接下来的三天要讨论的课题。而今天就从所有资料库不管是 SQL、NoSQL 都通用的权限管理开始谈起

权限管理

现在的资料库为了方便管理，一般都允许管理者建立多个 user，并且给他们不同的权限，像 MongoDB 的 creareUser 跟 MySQL 的 CREATE USER/GRANT 用起来都很简单，文件看一看就差不多会用了～

所以为了安全起见，最好是可以把资料库的 user 分成许多不同的等级，譬如说想要让新来的实习生了解资料库内的架构，或是要让资料分析团队可以从资料库内拿资料，那就在 Mongo 里面开一个 read 权限的 user 给他们就好了。有了这个角色他们就可以在 web database 里面取得任何他们想要的资料，而且再怎麽样手残也不可能把资料库弄坏

use web; // use web database
db.createUser({
    user: "intern",
    pwd: "pa55w0rd",
    roles: ["read"]
})

而如果是自己团队内的工程师要用的，那就可以开个高一点的 readWrite 给他，而若对象是 DBA 那就可以开 dbAdmin 或是 dbOwner 给他，让他需要时可以删除 collection、对资料库做 profile 等等

而除了团队开发时需要这样做之外，即便是自己开发的 side project 也可以多开几个低权限的 user，这样如果你现在只是想到资料库上看看资料量，那就可以用比较低权限的 user 连上去，不用担心自己手残删到好不容易搜集来的资料，等之後真的确定要做什麽事了，再用有写入权限的 user 重新登入

credential 放哪？

建了那麽多 user 之後，势必有非常多组帐号密码，那这些 credential 要怎麽进行管理呢？

如果已经有在用 AWS 或 GCP 的服务，而且也不介意帐号密码放在别人家机器的话，AWS 跟 GCP 都有提供 Secret Manager 的服务，只要你把想保存的 secret 都放上去，就可以让开发人员透过 CLI 取得开发时需要的 secret，而应用程序方面也可以用他们提供的 library 直接取得执行时需要的 secret，非常的方便（当然是要付钱XD）

如果不放心放在别人的机器上，那也可以用 Hashicorp Vault，只要自己租一台机器然後自己把 Vault Server 架起来就好了。之後在开发时就可以用 Vault CLI 来取得 secret，而线上在跑的应用程序以及 CI/CD 所需要的 secret 则是可以自动塞进环境变数，虽然 Vault Server 一开始的设定稍微有点麻烦，但我自己用过之後真的觉得不错～

如果用别人家的 Secret Manager 跟自己架你都觉得太麻烦，而且要管理的帐号密码也不算多，那我也还满推荐 KeePass 的，他是一个本地端的密码管理软件，你用他新增一个密码资料库之後就可以开始把帐号密码输入进去，并且你只要有一个 master password 就可以进去拿到所有的帐号密码。而且因为每个资料库他会帮你储存成一个 .kdbx 档，所以当你想要把这些密码传给同事时，就只需要把这个 .kdbx 传给他然後给他 master password 就好了，如此一来就可以避免在 slack 或是 line 用明码的方式把帐密传来传去

小结

要守护自家的资料库安全，第一步就是先从权限管理着手，只要不同使用者的权限分级有做好，该放好的帐号密码也都有收好，那就不至於太容易出什麽大事

关於今天的内容有什麽问题欢迎在下方留言，没问题的话那就明天见啦～