在本系列的前两部分中，我们研究了：（1）Amazon Web Services（AWS）凭据管理和（2）远程登录/开发人员安全性。在今天的帖子中，我们将了解CloudBees在管理我们的平台即服务（PaaS）环境时使用的凭据和密码策略方面的一些最佳实践。这些都是很容易遵循的重要实践，不会给开发带来不必要的负担团队。集中密码管理除了amazonwebservices（AWS）之外，我们还有很多外部服务提供商，用于CloudBees的日常业务。对于许多这样的提供商，我们有一个单独的帐户，CloudBees使用它来提供面向内部和外部的服务。有时，我们的开发人员可能需要登录这些服务来更新信息、检查设置或获取报告。如在我的博客系列文章的第1部分中提到，拥有一组凭据是不可取的。每个新开发人员都必须获得这些证书，而且很难准确地了解他们在这方面的能力。另外，如果开发人员离开或者发生了一些需要更改的事件，那么重新分发新凭证就变成了痛苦。就像一个小的团队，这不是什么问题，但随着团队的成长，必须开发出更好的处理方法。在过去的一年半里，我们主要通过我们使用的提供商来解决这个问题，OneLogin.OneLoginEach开发者有一个单独的登录到我们的OneLogin系统。这可以是基于用户名/密码的，或者像我喜欢的那样，与我的Google Apps帐户同步，并通过OpenId使用我的Google Apps登录。一旦登录，我就会看到一个服务菜单，这些服务已经为我预先定义好了，以便我能够登录。只需单击一下，我就会进入服务提供商页面并自动登录。我不需要记住任何特定的登录凭据和帐户密码不必共享.OneLogin使我们能够非常容易地控制对所有重要系统的访问（包括登录到AWS控制台）。一个明显的缺点是OneLogin现在是访问我们的关键基础设施的单点故障。但是，我们从未遇到过阻止我们使用该服务的技术问题。我们的管理员仍然维护各种登录的用户名/密码列表，只是在案例。如作为一个额外的安全层，我们的管理员在登录时通过手机应用程序使用双因素身份验证OneLogin密码重置安全控制中一个经常被忽略的区域是用于服务注册的电子邮件地址。对于我们的许多服务，我们注册alias@cloudbees.com转发给使用该服务的开发团队的电子邮件地址。这对于信息更新非常有用，但也意味着密码重置信息会转到该别名，然后转到我们可能试图提取该信息的团队成员的电子邮件地址从。这个这是我们在建立amazonec2帐户时梳理过的一个重要细节；我们想确保是否有一组凭证做到了这一点被盗，特别是从黑客电子邮件帐户，攻击者将发现很难重置帐户密码，以获得访问系统。保持私有凭证我们是GitHub的忠实粉丝，我们在那里有很多公共和私有的存储库。不过，我们还为一些关键存储库维护一个本地私有Git服务器，出于内部安全原因，我们决定最好将这些存储库放在离家较近的地方。这包括某些回购，这些回购不需要广泛使用，对幕后操作更为关键。我们倾向于将存储有服务凭证的回购协议完全包含在我们自己的基础设施中，而不是存储在第三方位置.EmailIn此外，我们从不使用纯文本电子邮件向最终用户发送重要凭证。当与新开发人员共享AWS凭据或设置SSH密钥时，我们总是使用GPG加密的数据进行事务处理。这个增加的步骤只增加了大约30秒的过程，但有助于确保如果开发人员的电子邮件被泄露，凭据不属于泄露的一部分数据。我们他发现，许多开发人员将电子邮件用作数据的永久存档。如果你给他们发送某种登录信息，这些信息将永远保存在他们的收件箱/存档中以供"将来参考"。通过发送加密的凭据，这些凭据将来将继续可用，如果需要，但将确保安全漏洞不会导致数据泄露损失汇总希望在这个由三部分组成的系列博客中，您了解到CloudBees团队对安全性的重视程度，并能够欣赏到我们在日常维护安全性方面使用的一些最佳实践。如果你对这些帖子中没有提到的安全性有什么建议或想法，请添加评论下面是Caleb网球，精英开发者CloudBeescloudbees.com阅读Caleb的Securing the Cloud blog中的第1部分和第2部分系列：固定云：第1部分-管理证书保护云：第2部分-管理远程登录和开发CloudBees的安全性cloudbees.com网站