我们的一位开发者意外地将我们的AWS加密密钥放到了Github上。除了很明显要修改密钥外，我们还应该做什么来减少我们在AWS上的应用基础架构受到的伤害？我们应该监控Github来看是否密钥过着其他的敏感数据在这次意外中暴露了吗？

真不幸，你们遭遇的经历太容易发生了。如果AWS加密密钥——或者任何加密密钥——存放于源控制下的目录里，有人意外地将这个密钥随源码放到了Github上。密钥应该独立于源码保存。

但是，在密钥已经暴露的前提下应该做什么呢？修改密码是对的，而且要删除已经暴露的任何密钥配对。一旦删除，任何拿到那个密钥的人就无法使用了。

加密密钥是成对生成的：一个私有密钥和一个公有密钥。公有密钥应该共享给任何人，用来解密你发出的加密信息。当使用密钥对来验证服务器时，服务器可能会存储你的公有密钥。在你创建一个EC2实例时，AWS照顾到了这一点，而且会指定一个密钥对。在Linux的实例中，私有密钥添加到~/.ssh/authorized_keys。最后一步是人工创建一个EC2实例，核实你指派给实例的你拥有的密钥对中的私有密钥。如果你没有这个私有密钥，就无法验证那个服务器。这种情况下假设你无法在服务器上创建逻辑登录机制。

同AWS或者任何云提供商工作的企业应该有一个密钥管理战略。私有密钥应该安全地存储，并且对那些需要使用它们工作的人限制访问。美国国家技术与标准研究所已经有密钥管理的最佳实践建议。AWS也发布了一套安全最佳实践。

在Github或者任何其他的云注册库上存储之前，扫描你的代码可以防止类似的事情再次发生。一些企业使用数据丢失保护应用扫描网络，防止私有或者敏感信息数据泄露，捕捉事件或者恶意泄露，比如社交安全成员。如果你的企业使用了这样的工具，考虑配置一下检测模式找到密钥文件，比如“—–BEGIN RSA PRIVATE KEY—–”。

糟糕的密钥管理不止会导致服务器受牵连，而且如果用来加密数据的密钥丢失了，用这个密钥加密的数据也就丢失了。声音密钥管理是无可替代的。