安全岛：他们是什么？怎么能避开？
Published December 7, 2018 by Geri Jennings.
过去的十年对于技术行业来说是一个激动人心的时期，随着DevOps和现代工具等协作性业务实践的出现，我们能够比以往更快地前进。这使得成为一家科技公司软件团队的成员令人兴奋——你我可能都听过这样一句话：每个公司现在都是一家科技公司。
市场上的产品数量激增，旨在帮助我们实现业务目标。但是随着这些新的工作流和工具的出现，我们开始发现：如果想保护我们的系统和客户的数据，我们应该识别出需要缓解的额外风险。
一般来说，我们创建的现代管道（modern pipelines）经过精心设计，可以提高流量和速度，并允许我们快速构建、测试和部署新代码——然而并不总是为了安全而构建的。事实上，需要解决的威胁模型和漏洞正在扩大。
我们特别担心的一个威胁向量（threat vector）是公开的凭证和秘密（exposed credentials and secrets），比如那些在Github等代码库中不经意共享的凭证和秘密，或者那些在DevOps工具（这些工具可以访问这些凭证和秘密）中因漏洞或过度特权而暴露的凭证和秘密。
当您拥有所有这些工具，而每个工具都有自己一套管理安全策略和访问控制的机制时，您最终会得到我们称之为“安全岛”的东西：
安全岛是：一种内置了自己的安全组件（用于管理秘密、访问控制、审计、合规性等）的工具或平台，但不便于与其他工具的互操作，和/或安全策略、管理和审计数据的聚合。
安全岛是一个独立的子系统，它令整个系统的安全管理变得更加困难。这可能是因为该工具的功能不完备或互操作性不强——但最终结果是相同的，即为该工具实现的安全性必定是零碎化的，没有任何集中化监管。
安全岛
当建立起来的系统必须处理安全岛问题时，您会遭遇缺乏集中化审计和访问控制的困境，也很难以任何标准化方式授予管理子系统的权限。您缺乏对整个安全环境的集中化视图，且在大规模管理时越来越困难。
此外，也有可能建造人为安全岛（human security islands）。如果安全性太难搞或太复杂，团队将会选择自己的安全工具和流程，而这些工具和流程在官宣策略之外。一般来说，这通常被称为“影子IT”。
去一个更好的地方
在CyberArk，我们希望能够让您建立一片信任大陆（Continent of Trust），使您消除安全岛，而以一种将各种工具与您已建立的信任系统（systems of trust）连接起来的方式，将它们编织在一起。
我们并不是要放弃不同的工具套件，但是我们确实可以通过找出能将它们全部联系在一起的工具，开始改善管理它们的体验。
当您构建信任大陆时，您将获得集中化审计、访问控制和管理的好处。规模化的授权和管理也很容易。您还可以对整个安全环境以及各个机器和服务之间的交互情况，获得集中化视图。
特别地，为了建立针对应用特权管理（application privilege management）的信任大陆，您需要一个系统，以允许您定义整个基础设施、声明谁和什么可以访问哪些资源、审核已经建立的所有连接、以及监控异常行为。
实际上，您希望用于集中管理应用特权的系统能够做到：
· 自动授予机器身份给应用程序和进程（如CI服务器）；
· 部署应用程序，以便它们准备好与其所需资源进行无缝身份认证；
· 集中管理访问控制；
· 减少开发人员的复杂性，使得影子IT无需存在。
在CyberArk的Conjur团队中，我们的任务是创建这样一个集中化系统，来管理动态环境中的应用特权。我们提供了集成方式（像我们的Kubernetes authenticator）来简化Conjur机器身份的创立，并提供诸如Summon和Secretless Broker之类的工具来简化将应用程序连接到其所需资源（如数据库和API）的过程。我们的做法是尽可能减轻开发人员的责任。
如果您有兴趣了解更多信息，请访问conjur.org或join us on Slack！
