iT邦幫忙

2021 iThome 鐵人賽

DAY 23
0
Security

從以卵擊石到堅若磐石之 Web API 安全性全攻略系列 第 23

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 的服務,而且也不介意帳號密碼放在別人家機器的話AWSGCP 都有提供 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 用明碼的方式把帳密傳來傳去

小結

要守護自家的資料庫安全,第一步就是先從權限管理著手,只要不同使用者的權限分級有做好,該放好的帳號密碼也都有收好,那就不至於太容易出什麼大事

關於今天的內容有什麼問題歡迎在下方留言,沒問題的話那就明天見啦~


上一篇
Day22-不能說的秘密(四)
下一篇
Day24-你的資料安全嗎(二)
系列文
從以卵擊石到堅若磐石之 Web API 安全性全攻略30

尚未有邦友留言

立即登入留言