我們的一位開發者意外地將我們的AWS加密密鑰放到了Github上。除了很明顯要修改密鑰外，我們還應該做什么來減少我們在AWS上的應用基礎架構受到的傷害?我們應該監控Github來看是否密鑰過著其他的敏感數據在這次意外中暴露了嗎?

真不幸，你們遭遇的經歷太容易發生了。如果AWS加密密鑰——或者任何加密密鑰——存放于源控制下的目錄里，有人意外地將這個密鑰隨源碼放到了Github上。密鑰應該獨立于源碼保存。

但是，在密鑰已經暴露的前提下應該做什么呢?修改密碼是對的，而且要刪除已經暴露的任何密鑰配對。一旦刪除，任何拿到那個密鑰的人就無法使用了。

加密密鑰是成對生成的：一個私有密鑰和一個公有密鑰。公有密鑰應該共享給任何人，用來解密你發出的加密信息。當使用密鑰對來驗證服務器時，服務器可能會存儲你的公有密鑰。在你創建一個EC2實例時，AWS照顧到了這一點，而且會指定一個密鑰對。在Linux的實例中，私有密鑰添加到~/.ssh/authorized_keys。最后一步是人工創建一個EC2實例，核實你指派給實例的你擁有的密鑰對中的私有密鑰。如果你沒有這個私有密鑰，就無法驗證那個服務器。這種情況下假設你無法在服務器上創建邏輯登錄機制。

同AWS或者任何云提供商工作的企業應該有一個密鑰管理戰略。私有密鑰應該安全地存儲，并且對那些需要使用它們工作的人限制訪問。美國國家技術與標準研究所已經有密鑰管理的最佳實踐建議。AWS也發布了一套安全最佳實踐。

在Github或者任何其他的云注冊庫上存儲之前，掃描你的代碼可以防止類似的事情再次發生。一些企業使用數據丟失保護應用掃描網絡，防止私有或者敏感信息數據泄露，捕捉事件或者惡意泄露，比如社交安全成員。如果你的企業使用了這樣的工具，考慮配置一下檢測模式找到密鑰文件，比如“-----BEGIN RSA PRIVATE KEY-----”。

糟糕的密鑰管理不止會導致服務器受牽連，而且如果用來加密數據的密鑰丟失了，用這個密鑰加密的數據也就丟失了。聲音密鑰管理是無可替代的。