昨天講到 Udacity 把 credential 放到 git repository 裡的方式 (參考「Udacity 管理 credential 的方式...」這篇),結果就看到另外一篇講當外洩時降低傷害的文章:「Leak Mitigation Checklist」。
裡面講的方法沒什麼特別的 (倒是花了不少篇幅在介紹各家的 credential 要怎麼重生),畢竟這是一份 checklist,只是要確保最低標準的步驟都應該要確認有做。
不過這兩篇放在一起看還蠻有趣的...
幹壞事是進步最大的原動力
昨天講到 Udacity 把 credential 放到 git repository 裡的方式 (參考「Udacity 管理 credential 的方式...」這篇),結果就看到另外一篇講當外洩時降低傷害的文章:「Leak Mitigation Checklist」。
裡面講的方法沒什麼特別的 (倒是花了不少篇幅在介紹各家的 credential 要怎麼重生),畢竟這是一份 checklist,只是要確保最低標準的步驟都應該要確認有做。
不過這兩篇放在一起看還蠻有趣的...
看到 Udacity 管 credential 的方式,可以用「我就是想把這些東西放到 Git 裡面管理啦」來解釋:「Three Simple Rules for Putting Secrets into Git」。
看了一下 Udacity 的架構,從 catalog-api.udacity.com
看起來應該是放在 AWS 的 us-west-2
上?那麼不考慮使用 AWS 的 KMS 是什麼?或是退一步來說,連自架的 Vault 也不考慮的原因又是什麼?下面的 response 好像沒什麼人提出問題... 在不知道前提的情境下,選擇這樣的方法其實有點怪,2012 年成立的公司有這麼重的包袱嗎?
先看看就好 XD
在「aws-credential-compromise-detection – Detecting Credential Compromise in AWS」這邊看到可以抓漏的專案 Netflix-Skunkworks/aws-credential-compromise-detection。
透過分析 CloudTrail 記錄找出有哪些可疑的 AWS key 被外部使用,看起來預設值會過濾掉 Private IP range 以及 100.64.0.0/10
(設給給 CGNAT 使用的網段)。
不過 Netflix-Skunkworks 的定位是什麼啊,裡面好像有不少有趣的東西...
John Resig (現在在 Khan Academy) 在月初的時候發表了「Keeping Passwords in Source Control」討論要怎麼儲存 credential。
這不只是開發者的問題而已,這跟 code deploy 機制也很有關。目前沒有完美的方案,不同的解法都是在不同的環境與限制下而誕生出的產物。