昨天講到 Udacity 把 credential 放到 git repository 裡的方式 (參考「Udacity 管理 credential 的方式...」這篇)，結果就看到另外一篇講當外洩時降低傷害的文章：「Leak Mitigation Checklist」。
裡面講的方法沒什麼特別的 (倒是花了不少篇幅在介紹各家的 credential 要怎麼重生)，畢竟這是一份 checklist，只是要確保最低標準的步驟都應該要確認有做。
不過這兩篇放在一起看還蠻有趣的...
Tag: credential
Udacity 管理 credential 的方式...
看到 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
Netflix 用 CloudTrail 記錄找出 AWS key 外洩的小工具
在「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 的定位是什麼啊，裡面好像有不少有趣的東西...
各種 credential 儲存的方式 (像是連到資料庫的密碼)
John Resig (現在在 Khan Academy) 在月初的時候發表了「Keeping Passwords in Source Control」討論要怎麼儲存 credential。
這不只是開發者的問題而已，這跟 code deploy 機制也很有關。目前沒有完美的方案，不同的解法都是在不同的環境與限制下而誕生出的產物。