集中管理用于访问应用程序、服务和IT生态系统所有其他部分的工具、方法和凭据是值得企业关注的。
如今的企业IT场景的特点是持续的数字化转型和大规模的数据生成。随着远程工作和移动工作成为新冠疫情发生之后的新常态，移动性和敏捷性已经成为企业业务连续性的重要驱动因素。文章源自玩技e族-https://www.playezu.com/213624.html
为了自动化和集成所有可能的业务功能，集中并加快数据和信息的流动，提高生产力并提供更好的客户体验，很多企业正在使用复杂的混合多云的运营模型构建敏捷的DevOps环境。文章源自玩技e族-https://www.playezu.com/213624.html
然而，随着巨大的移动性和即时的数据，随之而来的是巨大的责任。企业在保持数据、服务和个人身份信息(PII)安全方面面临着越来越多的挑战。尽管技术一直不断进步，但人们仍然年复一年地看到大量的数据泄露事件。文章源自玩技e族-https://www.playezu.com/213624.html
企业如何发展其数据存储、管理和保护方法，以确保员工能够直接访问数字资源，同时加强整个IT基础设施的安全性?答案在于有效的企业机密管理。文章源自玩技e族-https://www.playezu.com/213624.html
什么是机密管理?为什么需要机密管理?
机密管理是一套适当的工具和最佳实践，用于在整个生命周期内安全地存储、访问和集中管理数字身份验证凭证。机密是用于身份验证和授权的数据项——它们包括密码、公共和私人加密密钥、SSH密钥、API、令牌和证书。机器和人类都使用机密进行身份验证和通信。文章源自玩技e族-https://www.playezu.com/213624.html
但是，为什么首先需要机密管理?基于SaaS的机密管理工具Akeyless公司首席执行官兼联合创始人Oded Hareven解释说，“随着向混合多云基础设施的普遍转变以及对应用程序容器化的依赖，机器和人员持续访问系统和数据的需求已经大幅增长。例如，越来越多的应用程序必须不断地访问不同的数据源、云服务和服务器，通常每个资源都需要不同类型的凭据。这在DevOps流程中产生了对机密的指数级需求。”文章源自玩技e族-https://www.playezu.com/213624.html
棘手的是，开发人员经常将各种机密编码到应用程序或微服务代码、脚本、自动化工具和代码库中——所有这些都驻留在各种基础设施中。更糟糕的是，这些代码处于不同的开发阶段，存在管理不当和未受保护的实际风险。其结果是总体上缺乏对机密的控制和整合，导致安全行业称之为“机密蔓延”。文章源自玩技e族-https://www.playezu.com/213624.html
麻烦还不止于此。在执行持续集成(CI)/持续交付(CD)的云平台中保存的机密本质上是管理和允许访问其他机器和软件所必需的。为此，他们需要存储机密和签名密钥(用于密封代码和软件更新)，这些密钥通常存储在非安全位置，如开发人员的笔记本电脑或他们构建的服务器。文章源自玩技e族-https://www.playezu.com/213624.html
机密蔓延不仅使凭证难以跟踪和管理，而且容易受到黑客攻击。事实上，根据Verizon公司日前发布的一份调查报告，被盗凭证占所有数据泄露的近一半。文章源自玩技e族-https://www.playezu.com/213624.html
最近发生的许多黑客攻击，包括软件供应链黑客攻击，都利用了代码中的机密，这些机密再次存储在GitHub等易于访问的存储库中。事实上，GitHub最近在数千个私有存储库中检测到70多万次潜在的凭证泄漏，并且已经准备就绪。文章源自玩技e族-https://www.playezu.com/213624.html
这些例子不断涌现。最近曝光的软件供应链攻击劫持了流行的PHP和Python库以窃取AWS密钥。在另一个例子中，一项帮助开源开发人员编写和测试软件的常用服务被发现泄露了数千个身份验证令牌和其他机密，允许黑客访问开发人员在Docker、Github、AWS和其他代码存储库上的私人账户.
但是有人会问，是否已经有方法可以保护密码、密钥和其他凭据?有，这就是问题的一部分。
机密管理中的挑战
在管理机密方面，当今的安全解决方案存在相当低的效率和重复。其中的一些挑战是：
(1)机密蔓延
很多企业将业务从内部部署迁移到云端——机密也是如此。全球三大云计算提供商和其他云计算提供商都提供自己的机密管理解决方案，大多数企业默认接受这些解决方案，只是为了获得更好的解决方案，还有什么比云计算提供商自己采用的平台更安全的呢?
但是，随着混合多云架构占据中心位置(这是唯一一种越来越多采用的IT运营模型)，大多数DevOps团队发现自己要处理充满不同工作负载的微服务和容器的多个环境。这些环境拥有数千个相互通信的机器对机器组件，导致流通中的密钥、令牌和其他机密的数量多得惊人。
机密的爆炸式增长和分散对管理员和DevOps从业者来说是一个巨大的运营负担。当今可用的大量云计算和虚拟化解决方案让用户可以大规模创建和销毁虚拟机和应用程序。不用说，这些虚拟机实例中的每一个都有自己的一组需要管理的机密。此外，在企业中仅SSH密钥就可以达到数百万个。除此之外，Ansible作业、Kubernetes容器和日常批处理例程都倾向于使用需要轮换的密码。
所有这些系统都无法访问其环境外部的安全资源。没有统一的控制平台可以帮助企业管理存储在不同平台上的多个机密存储库。
(2)能见度不足
本地化到不同环境(如云平台、内部部署、边缘计算或混合部署)的静态机密由不同的个人、团队和管理员管理，从而创建“机密孤岛”。这不可避免地会导致审计挑战和安全漏洞。
(3)保管库解决方案的复杂性
由于大量现有和遗留工具和平台(包括DevOps和非DevOps)以及每个工具和平台的大量扩展，本地库解决方案在许多情况下都无法正常工作。此外，在混合环境中很难根据底层计算、存储和网络基础设施配置保管库。频繁更新的需求只会增加内部部署保管库的复杂性。
基于云计算的保管库也并不安全。一个巨大的危险信号是，这些产品是云计算提供商专有的，只支持在他们自己的环境和生态系统中运行的工作负载，因此它们也不适合混合云架构。即使企业只采用一个主要的云提供商提供的服务，也只会导致保管库蔓延。另一个问题是企业的主密钥与云计算提供商共享。这意味着流氓管理员、黑客或政府机构可以访问它们，而用户却束手无策。
完美的机密管理解决方案
完美的机密管理解决方案可能并不存在。但这并不意味着企业无法创建万无一失的身份和访问管理(IAM)策略来保护自己免受已知类型的威胁。
身份和访问管理(IAM)是新的边界——它是现代安全策略的基础。随着自动化程度的提高和随需求波动的动态工作负载的数量的增加，验证人类和机器用户的身份(身份验证)并证明他们访问资源(授权)的需求变得越来越复杂。
此外，身份验证的性质在不断变化。应用程序和数据库模块不再像以前那样局限于一些代码。与其相反，它们是微服务和子组件的复杂且动态的集成，每个子组件都有自己的身份验证过程。
以下是在多云环境中运营或拥有内部部署、私有云和公有云系统混合组合的企业应该在机密管理平台或解决方案中寻找的内容：
- 适用于混合云、多云和多个云区域设置：这可能是企业最重要的一个关注因素。尽可能选择使用云原生技术与跨平台、跨环境工作流无缝集成的平台。企业的机密管理解决方案应支持启用身份和访问管理(IAM)的机器对机器和人对机器身份验证和验证不同类型的机密，例如SSH证书、API密钥、x.509证书、加密密钥等，以强制执行连续安全合规性。
- 适用于不同的身份验证协议、语言和设备：重要的是，企业的机密管理工具通过所有主要接口(当然)包括命令行、GUI、RESTAPI和SDK，通过第三方身份提供者支持人工、硬件和软件身份验证主要语言。不用说，它应该促进动态机密并与常见的基于云的平台集成，例如Docker、Kubernetes、Terraform、Ansible和Jenkins，以实现不间断的DevOps操作。
然后是扩展问题。如果企业想以“云计算规模”增长并扩展其地理或技术基础设施，需要能够扩展其机密管理功能以支持所有现有以及即将推出的工具和插件。
- 可以通过统一的SaaS平台进行管理：当今的安全团队需要对企业使用的所有环境中的所有用户、应用程序和设备的身份验证进行集中可见性和控制。Hareven说，“一些安全负责人表示，直观的基于SaaS的机密管理工具可以实时查看每个机密使用实例、审计日志记录和强大的分析，这是他们的需求。”
- 实现机密零问题并实施零信任模型：密码管理是当今的常见功能。例如某人可能有一个电子表格或文档，其中存储了他们使用的各种应用程序或控制面板的所有密码。然而，要打开这个电子表格，他们可能需要另一个密码。他们还需要用户凭据才能登录操作系统并访问电子表格。
机密管理解决方案应该提供一组初始凭证，其中包含一个临时令牌或密钥，用于进行持续身份验证，以便永远不会泄露机密。
这属于零信任架构(ZTA)的前提，该架构遵循最小特权(PoLP)原则，在这一原则下，用户和应用程序被授予“即时”和细粒度访问特定时间内的特定数量的资源——只有在向管理员“证明”他们的请求合理之后。这些特权是动态授予的，并在预设的时间范围后自动过期。
保守机密
理想的机密管理平台通过使不同的团队能够访问他们需要的资源并自主管理他们的机密，从而为企业中的DevOps、云迁移和数字化转型提供支持。通过从云中“即服务”交付的解决方案，可以减少维护开销、提高可用性并扩展运营，以满足企业的增长目标。