平台工程的六大支柱之一：安全

平台团队的工作流程和检查表，用于在其平台中构建安全性、流水线、预配、连接性、编排和可观察性。

译自 The 6 Pillars of Platform Engineering: Part 1 — Security 。本系列其他文章也会陆续发出，欢迎大家关注本公众号“云云众生s”和网站。

平台工程是设计和构建工具链和工作流程的学科，这些工具链和工作流程为软件工程团队提供自助服务功能。这些工具和工作流程组成了一个内部的开发者平台，通常简称为“平台”。平台团队的目标是提高开发者生产力，促进更频繁的发布，改进应用程序稳定性，降低安全和合规风险，并降低成本。

本指南概述了平台工程中六个主要的开发者体验技术领域的工作流程和检查表步骤。分六部分发布，本部分，第一部分，介绍了该系列，并侧重于安全性。(注意:您可以下载平台工程六大支柱的完整PDF版本，以获取完整的指导、大纲和检查表。)

在 HashiCorp 工作的解决方案工程师和架构师支持过许多组织，这些组织通过平台团队扩展其云操作模型，而这些团队实现其目标的关键是提供令人满意的开发者体验。我们观察到提供出色开发者体验的公司有两个共同主题：

1. 标准化一组基础设施服务以减少开发者和运维团队的摩擦：这赋能了一个小型的、集中化的平台工程师组，具有正确的工具来通过 API、文档和倡导改进整个组织的开发者体验。目标是减少工具和流程的碎片化，从而提高您的软件交付系统和环境的核心稳定性。
2. 将平台作为产品实践：传统 IT 项目通常有确定的开始和结束日期。但内部开发者平台情况并非如此。它永远不会真正完成。正在进行的任务包括 Backlog 管理、定期发布新功能以及向利益相关者更新路线图。考虑以迭代式敏捷开发的方式思考，而不是像瀑布开发那样大量前期规划。

任何平台都不应该在真空中设计。只有当开发者想要使用它时，平台才有效。构建和维护平台涉及与开发者(平台团队的客户)和业务利益相关者的持续对话和认可。本指南通过帮助平台团队围绕软件交付过程的六个技术要素或“支柱”以及每个要素的一般要求和工作流程来组织其产品，作为这些对话的起点。

平台战略的具体构建块是什么？在与各行各业的客户合作中，HashiCorp 的解决方案工程师和架构师确定了组成大多数平台的六个基础支柱，每个支柱将在单独的文章中解决:

1. 安全性(包括简介)
2. 流水线(VCS、CI/CD)
3. Provisioning
4. 连接性
5. 编排
6. 可观测性(包括总结和下一步)

当开发者开始使用任何系统时，他们首先要问的问题是：“我该如何创建账户？在哪里设置凭据？我怎样获取 API 密钥？” 即使版本控制、持续集成和基础设施预配对启动和运行平台至关重要，安全也应该是首要关注的问题。早期关注安全可以从一开始就推动默认安全的平台体验。

历史上，许多组织投资于基于网络边界的安全性，通常被描述为“城堡和护城河”的安全方法。然而，随着基础设施变得越来越动态，如果不妨碍开发者速度，边界会变得模糊且难以控制。

作为回应，领先公司正在选择采用基于身份的安全性、身份代理解决方案和现代安全工作流程，包括凭据的集中管理和加密方法。这促进了在一个碎片化的解决方案组合中降低操作开销的同时，提高了可见性和一致的审计实践。

领先公司还采用了“左移”安全性；在整个软件开发生命周期中实施安全控制，从而提早检测和补救潜在的攻击向量，并提高对控制实现的警惕。这种方法要求默认自动化，而不是特殊强制执行。

启用这种 DevSecOps 心态需要支持现代基于身份的安全性的工具决策。还需要“即代码”实现范例，以避免根据工单驱动流程分配和授权身份。这为传统的特权访问管理(PAM)实践铺平了道路，以采用现代方法论，如即时(JIT)访问和零信任安全性。

在云操作模型方法中，人、应用程序和服务都呈现可以针对中心、规范源进行身份验证和验证的身份。一个多租户机密管理和加密平台以及一个身份提供者(IdP)可以充当您组织的身份代理。

工作流程：身份代理

在实践中，典型的身份代理工作流程可能如下所示：

1. 请求：人、应用程序或服务通过请求发起交互。
2. 验证：一个(或多个)身份提供者针对一个(或多个)真实/信任来源验证提供的身份。
3. 响应：向请求方发送经过身份验证和授权的验证响应。

成功的身份代理有若干先决条件：

• 所有人、应用程序和服务必须具有明确定义的身份形式。
• 身份可以针对受信任的 IdP 进行验证。
• 身份系统必须在多运行时和多云平台之间互操作。
• 身份系统应该是集中化的，或者具有有限的细分，以简化跨环境的审计和操作管理。
• 为每个 IdP 建立身份和访问管理(IAM)控制。
• 客户端(人、机器和服务)必须呈现有效的身份进行 AuthN 和 AuthZ)。
• 一旦验证，访问通过默认拒绝策略进行代理，以尽量减少发生破坏后的影响。
• AuthZ 审查集成到审核流程中，最理想的是，它被授予及时访问权限。
  • 定期审查审计跟踪，以识别过度宽泛或未使用的特权，并在检测到威胁后进行追溯分析。
  • 历史审计数据为数据存储要求提供不可否认性和合规性。
• 使用灵活的身份代理系统最小化碎片化，支持异构运行时，包括：
  • 平台(VMware、Microsoft Azure VM、Kubernetes/OpenShift等)
  • 客户端(开发者、运营商、应用程序、脚本等)
  • 服务(MySQL、MSSQL、Active Directory、LDAP、PKI等)
• 通过服务级协议(SLA)提供 7*24 小时企业支持
• 通过自动化(基础设施即代码、运行手册)配置

一旦建立了身份，客户端希望具有一致且安全的机制来执行以下操作：

• 检索机密(凭据、密码、密钥等)
• 代理对安全目标的访问
• 管理安全数据(加密、解密、哈希、屏蔽等)

这些机制应该是可自动化的——设置后需要尽可能少的人为干预——并促进合规的做法。它们还应该是可扩展的，以确保未来的工具与这些系统兼容。

典型的机密管理工作流程应遵循五个步骤:

1. 请求：客户端(人、应用程序或服务)请求机密。
2. 验证：针对 IdP 验证请求。
3. 请求：如果由请求的平台管理，则服务机密请求。或者：

• 平台从第三方请求临时凭证。
• 第三方系统响应代理请求，提供短期机密。

4. 代理响应：初始响应通过 IAM 加密屏障进行卸载或缓存。
5. 客户端响应：最终响应返回给请求者。

机密管理流程

在传统的城堡和护城河模型中，人与机器之间的访问一直很低效。该工作流程需要多个身份、计划干预 AuthN 和 AuthZ 控制、机密生命周期规划以及复杂的网络细分规划，这带来了很多开销。

虽然 PAM 解决方案在过去十年中发展，提供了动态 SSH 密钥生成等委派解决方案，但它并不能满足更广泛的生态系统要求，包括多运行时审计或跨平台身份管理。 引入云架构模式(如短暂资源、异构云网络拓扑和 JIT 身份管理)进一步复杂化了传统解决方案的任务。

现代远程访问解决方案解决了短暂资源及其带来的动态资源注册、身份、访问和机密等复杂性的挑战。这些现代安全远程访问工具不再依赖网络访问(如 VPN)作为初始入口点、CMDB、堡垒主机、手动 SSH 和/或带有签入/签出工作流的机密管理器。

企业级安全远程访问工具使用零信任模型，其中人员用户和资源都有身份。用户直接连接到这些资源。 通过动态资源注册表、控制器和机密注入资源的作用域角色，可以消除许多手动流程和安全风险，例如广泛的直接网络访问和长期有效的机密。

对于人类用户，现代远程基础设施访问工作流程通常遵循以下八个步骤：

• 请求：用户请求系统访问。
• 验证(人)：针对受信任的身份代理验证身份。
• 验证(到机器)：一旦通过身份验证，验证目标系统的授权。
• 请求：平台请求目标系统的机密(静态或短期)。
• 注入机密：平台将机密注入目标资源。
• 代理响应：平台向身份代理返回响应。
• 客户端响应：平台向最终用户授予访问权限。
• 访问机器/数据库：用户通过现代安全远程访问工具安全访问目标资源。

安全远程访问流程

机密管理系统中的所有机密都应该：

• 集中化
• 传输和静态加密
• 作用域角色和访问策略有限
• 动态生成(如果可能)
• 时间绑定(即定义的生存时间 - TTL)
• 完全审计

机密管理解决方案应该：

• 支持多运行时、多云和混合云部署
• 提供灵活的集成选项
• 包含各种合作伙伴生态系统
• 采用零接触自动化实践(API 驱动)
• 在范围界定的边界内授权开发者并委派实现决策
• 在行业中有良好的文档记录和常见用途
• 由 7*24 小时企业支持按 SLA 提供
• 支持自动化配置(基础设施即代码、运行手册)

此外，实施安全远程访问做法的系统还应：

• 动态注册服务目录
• 实现基于身份的模型
• 从可信来源提供多种形式的身份验证功能
• 可配置为代码
• API启用且包含内部和/或外部工作流功能以进行审查和审批流程
• 使机密注入资源
• 提供详细的基于角色的访问控制(RBAC)
• 提供记录操作、命令、会话的功能，并提供完整的审计跟踪
• 高可用性、多平台、多云能力，用于分布式操作，且对操作影响具有弹性

敬请关注我们关于平台工程第二支柱的文章：版本控制系统(VCS)和持续集成/持续交付(CI/CD)流水线。 或者下载平台工程六大支柱的完整 PDF 版本，以获取完整的指导、大纲和检查表。