云安全技术参考架构（第二版）（上）

阅读： 538

执行摘要

第14028号行政命令《改善国家网络安全》更新了对联邦网络安全现代化和战略的承诺以及相关重点事项。为了紧跟现代技术的发展和不断演变的威胁，联邦政府持续向云迁移。为支持此项举措，国土安全部部长（通过网络安全和基础设施安全局（CISA）局长）与行政管理和预算局（OMB）局长以及总务署署长（通过联邦风险和授权管理计划（FedRAMP））磋商，制定了《云安全技术参考架构》，为机构利用云安全态势管理（CSPM）收集和上报数据提供了建议方法，以顺利进行云迁移，保护数据安全。通过该技术参考架构，机构可了解实施零信任架构时采用云服务的优势和内在风险。

授权

第14028号行政命令《改善国家网络安全》在第3条（c）款中规定（对某些句子增加了加粗显示，以示强调）：

各机构在使用云技术的过程中，须协调行动，审慎行事，以便联邦政府预防、检测、评估网络事件并进行相关补救。为此目的，各机构须尽可能采用零信任架构向云技术迁移。CISA须更新其现有的网络安全计划、服务和能力，以便在使用零信任架构的云计算环境中充分发挥作用。国土安全部部长（通过CISA局长）须与总务署署长磋商（通过FedRAMP），制定云服务商（CSP）安全原则，作为机构现代化工作的一部分。为促进这项工作的完成：

[……]

在本命令颁布后90天内，国土安全部部长（通过CISA局长）须与OMB局长以及总务署署长（通过FedRAMP）磋商，为联邦文职行政部门（FCEB）制定和发布云安全技术参考架构文档，为机构收集和上报数据提供建议方法，以顺利进行云迁移，保护数据安全。

一、前言

第14028号行政命令《改善国家网络安全》（2021年5月12日）更新了对联邦网络安全现代化和战略的承诺以及相关重点事项。除了其他的政策授权，第14028号行政命令还将零信任作为理想的安全模式，要求网络安全和基础设施安全局（CISA）更新其当前的网络安全计划、服务和能力，使其能够在云计算环境中充分发挥作用。第14028号行政命令标志着联邦政策的转变，但近年来所做的许多工作都与该行政命令的关键原则相一致。例如：

第13636号行政命令《提升关键基础设施网络安全》（2013年2月）扩大了信息共享计划，比如增加了“增强网络安全服务”，向美国公司提供机密和非机密的网络威胁信息。
第13800号行政命令《加强联邦网络和关键基础设施的网络安全》（2017年5月）授权机构利用NIST CSF实施风险管理措施，降低未授权访问政府信息技术（IT）资产的风险。第13800号行政命令还指示各机构在IT采购中优先考虑共享服务。这样，就将有效的风险管理和IT现代化放到了同等重要的位置，指示机构在迁移到云环境时对数据实施有效保护。该命令进一步强调了CSF的重要性，并为联邦政府尽快上云奠定了基础。
第13873号行政命令《确保信息和通信技术及服务供应链的安全》（2019年5月）重点提出通过确保供应链采办安全来保护关键基础设施IT。通过这种方式，它强调了供应链和IT采购对于政府运营和机构任务履行的重要性。

这些工作当然应该继续进行下去。同时，新的领导班子、不断演变的威胁以及千变万化的需求和技术也为增强现有战略和架构方法提供了机会。此外，近期发生的针对云计算环境的网络入侵产生了广泛影响，需要国家做出回应。这些入侵表明，传统方法已无法有效防止国家受到网络威胁。此外，要成功进行云迁移，需要在整个组织内推行文化变革、明确优先事项、采用设计方法，并得到组织的接受和支持。

《云安全技术参考架构》以上述文件为基础，重点关注云现代化工作，即共享服务、云软件设计和云安全态势管理，支持联邦机构持续演进，适应快速发展的环境和技术。

二、目的和范围

《云安全技术参考架构》旨在指导各机构在实施云技术时协调行动，审慎行事。一方面帮助联邦政府识别、检测、防护、应对和恢复网络事件，另一方面提高整个政府的网络安全。如第14028号行政命令所述，本文目的在于让机构了解实施零信任架构时采用云服务的优势和内在风险。《云安全技术参考架构》还为机构收集和上报数据提供了建议方法，以顺利进行云迁移，保护数据安全。

本技术参考架构旨在为采用云服务的机构提供如下指导：

云部署：为机构安全过渡到、部署、集成、维护和运营云服务提供指导。
自适应方案：提供灵活且广泛适用的架构，用于选择云功能和不受厂商限制的解决方案。
安全架构：支持建立云环境和安全的基础设施、平台和服务，助力机构运营。
开发、安全和运营（DevSecOps）：支持安全、动态的开发和工程周期，在机构过渡和发展过程中，围绕能力的设计、开发和交付，构建、学习和迭代解决方案。
零信任：为计划采用零信任架构的机构提供支持。

本技术参考架构有三大组成部分：

共享服务：本章介绍评估云服务安全的标准化基线。
云迁移：本章概述了云迁移的策略和注意事项，包括对常见迁移场景的解释。
云安全态势管理：本章定义了云安全态势管理（CSPM），列举了云环境中用于监控、开发、集成、风险评估和事件响应的相关安全工具。

虽然各部分聚焦于云安全的不同方面，但它们具有协同作用，共同支持云安全现代化的总体目标。了解共享服务的特征以及管理和保护此类服务的职责划分对于机构的云迁移和安全态势管理至关重要。上云后可以改善运营和安全性，帮助机构跟上不断发展的技术形势。最后，借助于CSPM能力，机构可根据需要在整个基础设施中动态保护其云资源。

图1详细说明了云安全技术参考架构的组成部分和各部分之间的共性。

图1：云安全技术参考架构组成以及协同作用

附录A以三个云中使用场景—联合身份管理、微服务和温备站点—为例阐述了需要考虑的相关因素。附录B列举了本技术参考体系结构中的术语和缩略词。

2.1关键计划和倡议

为实现信息技术（IT）现代化和云安全，出台了一系列联邦云计划和战略，其中的重点项目介绍如下。

联邦风险和授权管理计划

联邦风险和授权管理计划（FedRAMP）成立于2011年，为联邦政府部署、使用云服务提供了一种经济高效、基于风险的方法。FedRAMP授权机构使用现代云技术，同时强调联邦信息的安全和保护。

云智能计划

在提交总统的《联邦IT现代化报告》一文中提出了“云智能”（Cloud Smart)，这是继“云优先”（Cloud First）之后的另一联邦云计算战略，于2017年启动。云智能包括三大支柱：安全、采购和人员。这些支柱均为云战略关注的重点，但由于安全与其他两方面均有交叉，因而显得尤为重要。例如，在培养联邦IT员工队伍的专业性方面，云计算安全架构方面的技能集和培训应作为重点强调。

三、共享服务层

本章介绍共享服务及其对机构和厂商的安全影响，概述了云服务模型，解释了各机构如何利用FedRAMP服务支持云迁移。需要注意的是，本章所描述的云服务模型的功能依赖于采购期间设定的合同条款；云采办不在本文讨论之列。

本章将：

定义云服务模型：识别和定义云服务模型，并将该定义与其他权威资源对比。
介绍FedRAMP：介绍FedRAMP及其相关角色和职责。
概述FedRAMP的安全考虑因素：描述FedRAMP对持续监控、事件响应和授权范围的要求。

3.1云服务模型概述

将基础设施、应用程序或服务移入云中时，有多种方案可选。这些方案通常称为“_aaS”，其中“_”代表描述云产品类型的一个或多个字母。NIST定义了三种基本的云服务模型：SaaS(软件即服务）、PaaS（平台即服务）以及IaaS（基础设施即服务）。

软件即服务（SaaS）：消费者使用基于云基础设施提供的应用程序。这些应用程序可以通过各种客户端平台访问，消费者无需管理或控制底层基础设施。
平台即服务（PaaS）：消费者能够使用服务商提供的语言、库、服务和工具在云基础设施上部署自己的应用程序。消费者无需管理或控制底层基础设施，但可以控制所部署的应用程序以及应用程序所在环境（服务商提供）的配置设置。
基础设施即服务（IaaS）：消费者能够配置计算资源，部署和运行环境及应用程序。云服务商管理底层基础设施，消费者控制计算资源，包括对特定网络组件的部分控制（例如，基于主机还是基于网络的防火墙）。

云技术经过多年发展，衍生出了各种_aaS服务，包括桌面即服务（DaaS）、安全即服务（SECaaS）、人工智能即服务（AIaaS）、容器即服务（CaaS）、灾难恢复即服务（DRaaS）、物联网即服务（IOTaaS）、位置即服务（LaaS）、监控即服务（MaaS）、统一通信即服务（UCaaS）和工作空间即服务（WaaS）等，这一名单仍在不断更新。这些新增的服务与三种基本服务模型重叠，模糊了SaaS、PaaS和IaaS之间的界限，使得维护和安全责任愈加复杂。

不过，SaaS、PaaS和IaaS仍是最流行的云服务模型，它们在使用和保护方面各有不同，如图2的共享安全模型所示。这类模型简要说明了哪一方对技术、安全、数据等负责。

图2：不同服务模式的责任

共享安全模型（图2）显示，保护SaaS产品的责任主要由服务商承担。不过，这也意味着服务使用机构对服务商更加信任。这与IaaS形成了鲜明对比，IaaS的主要责任由机构承担，部分责任由云服务商（CSP）承担，其他责任共同承担。CSP对这种共享安全关系的定义可能会因厂商而异。

机构必须明确定义并充分理解自己与CSP之间的职责划分，认真制定服务等级协议（SLA），确定每一CSP的责任以及对其的期望。机构可能会发现需要在CSP更新服务时保持同步，做出相应修改。机构务必从一开始就了解所选CSP的安全状况，且后续需要保持这种了解。

机构也可以使用其他机构提供的服务，例如使用母机构提供的服务，如SaaS应用程序（电子邮件等）和母机构授权访问的IaaS环境。在这些情况下，母机构和子机构之间必须达成共识，协调彼此的角色和职责，包括但不限于事件管理、日志监测和分析、身份、访问和凭证管理（ICAM）、以及配置管理。

3.1.1.云服务模式

如上所述，有三种主要的云服务模式：SaaS、PaaS和IaaS。每种云服务都提供了独特的功能，有自己的安全含义，机构在实施高效架构时应予以考虑。机构还应意识到，提供IaaS服务的CSP通常也提供PaaS和SaaS服务，提供PaaS的CSP一般也提供SaaS。因此，一个机构使用同一CSP的多个云服务模式并不鲜见。此外，有些CSP允许客户使用预装好的硬件和虚拟化在本地部署其服务；因此，一个机构可能同时会有多个CSP服务在本地、卫星或远程办公室、数据中心和/或云中运行。下面详细介绍这些云服务。

3.1.1.1 软件即服务

本质上，SaaS通常是专用服务，主要针对某一业务需求，如通信（电子邮件等）、文档管理或人力资源功能。SaaS服务一般通过Web提供，但也可能是应用或应用程序编程接口（API），与其他服务集成。软硬件由服务商控制，责任很少分担；但是，连接到这些环境的应用程序或API必须由机构和服务商共同保护。

有些SaaS提供商将能够与现有的身份访问服务集成；有些没有身份认证集成方案，有自己的身份域。IaaS和PaaS提供商可能会在自己的服务包中加入一些SaaS内容。

3.1.1.2 平台即服务

在PaaS中，厂商提供平台如Web服务器和数据库，用以构建解决方案。有些PaaS功能通常包含在IaaS中，但也可以独立提供。PaaS相对于IaaS的优势在于，机构可以根据任务需求创建服务，而不是购买、部署和管理服务器硬件或应用程序或数据库服务器。这意味着机构可以专注于管理平台资源以及开发和部署服务和解决方案，而无需管理底层基础设施。

3.1.1.3 基础设施即服务

IaaS环境提供丰富的服务和功能用于构建和编排解决方案。机构应该了解云原生特性，在开发解决方案时可考虑利用这些资源。这些特性包括弹性和扩展性，以及网络、操作系统、容器等资源的虚拟化。

3.1.2 部署类型

上述服务产品可以通过四种不同的方式部署在云中。具体部署方法及相关NIST定义见下文：

私有：云基础设施专门提供给存在多个客户的组织（例如具有多个业务单元的机构）使用，由组织、授权第三方或双方共同拥有、管理和运营。基础设施可部署在组织内部，也可部署在外部的云提供商处。

社群：云基础设施提供给关注相同问题（例如使命、安全需求、策略和合规性考虑）的特定消费者人群，由一个或多个组织、授权第三方或多方共同拥有、管理和运营。基础设施可在本地，也可以不在本地。

公共：云基础设施为公用，由一个或多个组织、授权第三方或多方共同拥有、管理和运营。基础设施不在本地部署。

混合：云基础设施采用上述两种或多种模式（即私有、社群或公共）部署。这种情况下，通过服务商提供的标准化或专有技术连接用不同方式部署的服务，保持数据和应用程序的兼容性。

许多人认为政府云产品就是一种社群云。政府云部署能提供公共云之外的额外保护（比如，对在CSP数据中心工作的美国公民），但也存在一些不足之处。通常，CSP首先在公共云中提供新的安全特性和工具。为政府云部署提供这些新的安全功能和工具可能需要数周、数月或数年的时间。并且，CSP在公共云中提供的工具中的某些功能对于政府也许根本无法实现。此外，政府云部署仅限于美国地区。有些机构可能需要通过公共云部署来最大化全球影响力。

3.1.3 多云

有些机构会使用多云环境。存在多云的机构需要优化环境，同时对于各相关CSP保持态势感知和良好安全实践。机构可能会将每个服务作为独立实体单独保护，也可能会对其使用的所有服务的安全采取整体视角。鼓励机构使用工具对所有应用程序和基础设施进行全局总览，覆盖所有CSP，实现对安全策略的集中管理。机构还可以选择使用CSP和第三方厂商提供的工具进行跨CSP安全分析。机构希望根据其特定需求确定哪些工具最有利于改善其安全状况。它们应评估CSP提供的安全工具和专为多云环境设计的独立工具的优缺点，应尽可能使用同时支持多个CSP的安全工具。

机构应评估哪些方法可以最有效地监控所有云服务，确保组织感知态势并维持良好的安全习惯。保证各种云服务之间的安全信息一致性对机构来说非常重要。按类型对日志进行数据归一化有助于实现这种一致性，因为每种服务的日志字段名称和数量都会有所不同。机构应确定是否需要将日志集中到中央位置进行分析，若是，再确定哪些日志需要回传以及如何回传。如果使用跨CSP的集成身份访问程序，某些日志—例如身份认证日志—将统一存放。各机构必须了解并按照OMB（M）-21-31备忘录进行日志管理。

在规划采用云服务时，机构必须确定如何为每项服务实施身份认证和访问管理，考虑身份服务所在位置的影响（例如，在本地还是在CSP处，如果有多个CSP，则还要指定具体的CSP来托管该身份服务）。机构应尽可能实施最强安全功能，例如防网络钓鱼的多因素身份认证 (MFA)，并应考虑何时使用单点登录等便利功能。

在多云环境中运营时，存在厂商锁定的可能性，机构应认识到这一点。厂商锁定指租户依赖某一CSP的服务和资源。有些情况下，锁定单一厂商构建解决方案有许多优势。但在其他情况下，机构可能需要尽可能避免厂商锁定，以便能够轻松地跨服务部署解决方案，同时尽可能不更改配置和部署设置。

3.1 FedRAMP简介

FedRAMP于2011年根据OMB备忘录《云计算环境中信息系统的安全授权》（简称为FedRAMP备忘录）成立。FedRAMP为联邦政府部署、使用云服务提供了一种经济高效、基于风险的方法。FedRAMP授权机构使用现代云技术，同时强调联邦信息的安全和保护。FedRAMP是一个政府范围的计划，为云技术和联邦机构提供标准化的安全和风险评估方法，促进整个联邦政府采用安全云服务。如FedRAMP备忘录中所述，FedRAMP适用于：

执行部门和机构采购信息系统提供的商业和非商业云服务，用于支持部门和机构的运营和资产，包括由其他部门或机构、承包商或其他来源提供或管理的系统；
NIST定义的所有云部署模式（如公共云、社群云、私有云和混合云）；
NIST定义的所有云服务模式（如基础设施即服务、平台即服务和软件即服务）。

FedRAMP备忘录进一步要求各执行部门或机构：

在对所有执行部门或机构使用云服务进行风险评估、安全授权和运营授权（ATO）时，使用FedRAMP；
在启动、审查、授予和撤销云服务的安全授权时，使用FedRAMP项目管理办公室（PMO）流程并将联合授权委员会（JAB）批准的FedRAMP安全授权要求作为基线；
确保适用合同合理要求CSP遵守FedRAMP安全授权要求；
根据DHS指南，针对云服务的安全和隐私事件建立并实现事件响应和缓解能力；
确保采办要求与FedRAMP的安全授权要求相一致，对CSP有承包商审查和检查相关的合同规定；
根据DHS指南，要求CSP路由其流量，使服务符合可信互联网连接（TIC）计划的要求；
每年4月30日向联邦首席信息官（CIO）提供（1）执行部门或机构CIO和首席财务官（CFO）的书面证明，以及

（2）机构确定无法满足FedRAMP安全授权要求的所有云服务的列表，附有原因说明和建议的解决方案。

益处

减少重复工作，确保一致性，提升成本效率；
建立公私伙伴关系，促进创新和更安全信息技术的进步；
通过创建透明的安全授权标准和流程，机构可在政府范围内利用安全授权，进而加速联邦政府的云计算实施步伐。

目标

促进政府机构使用安全云技术；
加强政府的云技术保护和授权框架；
与FedRAMP利益相关者建立并培育牢固的伙伴关系；
指导机构和厂商提供如何获取安全的云解决方案。

为实现计划任务，FedRAMP持续寻找现代化和自动化方法。FedRAMP与NIST和业界合作开发了开放式安全控制评估语言（OSCAL），这是一种用XML、JSON和YAML表示的格式。这些格式提供了机器可读的控制目录、控制基线、系统安全计划以及评估计划和结果。FedRAMP基线和安全包材料现使用OSCAL，旨在简化授权包的开发和审查。针对初次使用OSCAL的用户，FedRAMP还发布了开源工具，包括OSCAL生成器和转换工具。基于2021财年成果，FedRAMP将继续重点考虑业务流程的持续改进，覆盖所有利益相关者。

对于主要利益相关群体带来的好处如下：

机构能够更透彻地理解风险管理，从而在授权云服务产品的同时做出更明智的决策，最终加速本组织对新服务的采用；
CSP和第三方评估机构（3PAO）能够自动自测、开发、提交和修正安全包，减少授权工作量和时间；CSP还能自动进行持续监控，更快地解决网络安全威胁；
FedRAMP将在授权生命周期开始时收到改进后的包，以免审查过程被持续打断。通过自动化格式，包审查被简化，对利益相关者来说，减少了麻烦，加速了决策。

3.2.1 FedRAMP利益相关者：角色和责任

FedRAMP有四个利益相关群体： CSP、3PAO、联邦机构和JAB。

云服务商

联邦政府是云技术的最大买家之一，CSP为机构提供创新产品，节省机构的时间和资源，同时满足其关键任务需求。CSP当前若有云服务产品（CSO）被联邦政府使用，应获得FedRAMP授权，在了解FedRAMP的基础上，利用FedRAMP模板与FedRAMP制定的共享责任要求对齐，确保合规性。FedRAMP为所有的云产品和服务提供了已获得全体联邦文职行政部门（FCEB）机构认可的标准化安全框架。CSP只需要为每个CSO走一次FedRAMP授权流程，但要对每个授权服务进行持续监控。所有机构都要审查相同的持续监控交付件，以提高整个政府的效率。FedRAMP项目办为CSP提供培训、指导和咨询支持，帮助他们了解FedRAMP流程及要求。为联邦消费提供CSO的CSP应了解FedRAMP，利用FedRAMP模板与FedRAMP制定的共享责任要求对齐，确保合规性。

第三方评估机构

第三方评估机构（3PAO）评估CSO的安全性，在授权流程中发挥着关键作用。作为独立的第三方，3PAO根据联邦安全要求对云系统进行初步和定期评估。联邦政府基于3PAO评估，对云产品和服务的授权使用进行基于风险的明智决策。在FedRAMP评估期间，3PAO需要按照JAB授权流程提交一份准备度评估报告（RAR）。虽然RAR对于机构授权并非强制要求，但强烈建议使用。对于JAB和机构授权，3PAO编制安全评估计划（SAP）和安全评估报告（SAR）。SAP和SAR须提交给政府授权人（AO）进行授权。

联邦机构

FedRAMP助力联邦机构使用云服务安全地更新其技术并支持其任务。为此目的，机构使用FedRAMP的标准化基线评估云服务安全。机构与CSP合作，评判安全态势，授权CSO使用所需的云服务。为了建立一致的联邦云采用方法，鼓励机构和CSO接受FedRAMP培训，使用FedRAMP模板开发系统级安全工件。一旦CSO安全包在FedRAMP市场（FedRAMP Marketplace）中标记为“已授权”，机构就可以授权使用产品，审查和复用该CSO安全包。得益于FedRAMP的“一次授权，多次使用”原则，机构能够扩大联邦政府可用的安全云服务范围。

联合授权委员会

JAB是FedRAMP的主要治理和决策机构，由国防部、国土安全部和总务署的首席信息官组成。JAB负责：

定义并定期更新FedRAMP安全授权要求；
批准3PAO认证标准；
基于优先级评审云服务授权包；
为云服务授予临时授权，执行部门和机构可基于此进行安全授权及运营授权（ATO）；
定期评审、更新临时授权，并在发生变更（包括撤销此类授权）时通知执行部门和机构；
制定和发布授权包评审的优先级要求。JAB章程就委员会的目标和责任做了具体规定。

3.2 FedRAMP的安全考虑因素

FedRAMP旨在为云技术和联邦机构提供标准化的安全和风险评估方法。授权之后，CSP和机构仍要持续关注最新的安全要求和考虑因素。

3.3.1 持续监控

获得授权后，由于云服务产品的硬件或软件发生了变更或者发现了新漏洞，机构系统的安全态势将不可避免地发生变化。通过持续评估和授权，使用云服务的联邦机构能够发现系统安全态势的变化，基于风险做出决策。使用云环境的机构始终负责监控不受CSP监控的环境，通常使用单独授权（参见3.1节有关云服务各层的角色和责任的描述）。

《FedRAMP持续监控策略指南》阐述了CSP在收到FedRAMP授权（通过机构授权或JAB临时授权）后需要遵循的FedRAMP策略。CSP必须持续监控云服务产品，检测系统安全态势的变化，才能基于风险做出明智决策。该指南指导CSP采用FedRAMP策略持续监控其系统。FedRAMP还提供了其他持续监控指导文件，如《FedRAMP多机构持续监控指南》。FedRAMP强烈鼓励各机构利用该指南，分担持续监控责任，减少对初始授权机构的依赖，并与CSP和其他成员机构合作，确保云服务持续满足成员机构的需求。此外，各机构应考虑使用《FedRAMP持续监控绩效管理指南》，通过持续监控统一管理CSO的安全态势。要通过自动化和工具提高效率，在CSP许可的情况下，机构可以将厂商提供的安全工件纳入机构的治理、风险和合规（GRC）能力，确保机构风险管理框架（RMF）利益相关者和授权人了解云服务安全态势。

3.3.2 事件处理

《2014年联邦信息安全现代化法案》（FISMA）（《美国法典》第44编3552（b）（2）款）将“事件”定义为“（A）在没有合法授权的情况下，实际或即将危及信息或信息系统完整性、机密性或可用性的事件；或（B）违反或即将违反法律、安全政策、安全程序或可接受使用政策的威胁”。本文档中，术语“安全事件”和“信息安全事件”与“事件”可互换使用。

CSP为其提供的服务获得FedRAMP机构ATO或临时ATO(P-ATO)后，会进入持续监控阶段。与利益相关者明确、及时地沟通事件是持续监控的重要部分，可以确保事件处理的透明度，让所有利益相关者了解当前状态和补救措施。《FedRAMP事件沟通程序》文档概述了FedRAMP利益相关者上报信息安全事件的步骤，包括对已发布紧急指令的响应。FedRAMP要求CSP上报疑似或确认已导致或可能导致云服务或其存储、处理或传输的数据/元数据机密性、完整性或可用性丧失的任何事件。真实和可疑事件上报后，机构和其他受影响客户可采取措施保护重要数据，维持正常的效率水平，及时、全面地解决问题。

3.3.3 授权范围

NIST将安全授权范围定义为“由授权人授权运营的信息系统的所有组件，不包括与信息系统相连的单独授权的系统”。就如何定义CSO授权范围，FedRAMP为CSP提供指导，以支持其FedRAMP授权包。

授权范围：授权范围为CSO的内部服务、组件和其他设备以及与外部服务和系统的连接提供了图解说明。授权范围图涵盖CSP负责的所有联邦信息、数据和元数据的所有技术、内外部服务以及所使用的系统和账号。授权范围是与NIST SP 800-37《联邦信息系统应用风险管理框架 (RMF) 指南》和 OMB A-130通告《将信息作为战略资源管理》相关的关键组件。

FedRAMP当前正在更新授权范围指导文件，以反映与FedRAMP相关的云计算技术和联邦信息安全政策的变化。主要变化包括：

确定和定义云授权范围；
定义数据类型，包括云中的联邦数据和联邦元数据；以及
利用互联连接、外部和公司服务。

FedRAMP对美国/美国领土或美国管辖的地理区域的数据中心提出了要求，但仅适用于高基线。对于FedRAMP低基线和中等基线，机构应意识到，联邦机构没有隐性或明确的保护措施确保其数据仅留在美国境内，或其资源仅建立在美国境内地区。各机构必须与其CSP定义范围和期望，通过SLA或谅解备忘录（MOU）解决美国/美国领土或美国管辖的地理区域之外的任何问题。

四、云迁移

本章介绍了计算面以及机构在设计、实现和维护云数字服务时的考虑事项。要高效、安全地向云服务迁移，各机构应：

设计适用于云的软件：确定哪些服务和功能需要首先实施，为创建安全高效的云环境做好准备。
制定云迁移策略：设计适用于本机构的计划，将数据和服务从内部部署环境迁移到云环境。
采用开发、安全和运营（DevSecOps）方法：利用代码和集成支持人员，创建可靠的自动化数字服务。
集中通用云服务：确定将在整个机构使用的CSP，集中进行采购和管理。
进行人才投资：云迁移要求机构培养专业技能。

4.1 设计适用于云的软件：

机构可以利用云的灵活性，根据任务需要选用服务。在软件开发生命周期（SDLC）中，机构应在基于云的数字服务中尽早实施安全措施。机构若在DevSecOps过程中采用自动化安全测试，可开发出可扩展、可重复且符合零信任理念的可靠架构。这一过程需要跨机构团队协作构建数字服务。DevSecOps可以与IT部门支持的集中式SaaS相结合，对软件进行安全测试后发布。基于云的数字服务包括IaaS、PaaS和SaaS。如第3章所述，这些服务模式以及本地模式在系统架构的不同层次要求不同的负责人。机构必须确认厂商能够提供和不能够提供的服务和功能。

4.1.1. 为什么要将软件迁移到云端

机构将软件和数字服务从本地数据中心迁移到云，可以开发出可靠性、扩展性和可预测性更高的软件。利用云服务，机构可为其他地区提供灾难恢复，根据需要快速扩容，而无需再购买数据中心。在迁移较大服务之前，机构可以首先将较小的内部项目和工具迁移到云，获得新环境运营经验和信心。迁移到云为改造旧数字服务提供了机会，使后续的大踏步前进或现代化成为可能。

云提供了许多众所周知的好处，最明显的是，在云中构建零信任架构和更安全的应用程序会更容易，机构应加以考虑。CSP可以满足身份、设备、网络、应用程序和数据这五大零信任支柱的需求，为跨支柱交互提供必要的可见性。机构若能为云服务确定合适的FedRAMP批准级别，通常可以加快ATO，简化迁移过程。正确配置这些服务、建立有效的ICAM角色以及使用密钥管理系统（KMS）提供的加密保护敏感信息可由DevSecOps团队或其他管理员承担。第5章就云安全态势管理提供了补充指导。

机构应考虑使用API（见第5.3.8节）或数据服务来安全地管理其云部署的安全优势。机构可以通过CSP和第三方厂商提供的服务访问相同数据，而无需构建、验证和维护复杂的软件。由CSP等提供的API通常配有专门的开发人员和专家。在机构内创建同等团队既费钱又耗时，会占用机构的任务资源。

4.2 云迁移策略

云迁移是将业务运营和任务迁移到云中的过程。对许多机构来说，这意味着从无法再支持其需求的传统基础设施转向现代基础设施，为机构的应用程序提供更灵活、更具成本效益的解决方案。从本地方案迁移到云环境，要求思维方式随之改变。某些云功能的运行方式无法在本地实现，如基础设施即代码（IaC）概念。这些概念包括基于弹性服务需求的动态资源调配和停用，出于安全目的替换部分基础设施的定时维护也是此类。

云迁移需要大量准备工作，具体工作量取决于应用程序生态系统的规模、当前应用程序和系统的已使用年限、用户群以及数据量。机构应考虑应用生态系统中数据的保留时间和数量；日积月累，会产生海量数据，给云迁移带来更多挑战。决定将应用生态系统迁移到云时，机构应该权衡采用云技术的好处、风险和挑战。

4.2.1 潜在的云迁移挑战

所有大型软件项目都存在挑战，但从本地部署迁移到云在人员、资金和数据方面的挑战却有其独特之处。表1列出了机构进行云迁移时面临的常见挑战。

表1：云迁移的常见挑战

常见挑战	对迁移的影响
资金	应用基础设施和数据在多个环境中存在，需要识别重叠资金需求，这样才能实现成本节约。此外，传输数据也会产生成本。根据具体CSP要求、所使用的架构以及方法，将数据迁入CSP通常成本不高，甚至可能免费，但将数据迁出，成本可能会更高。
入职培训	入职培训意味着需要额外的时间来培训团队使用新技术，促进应用程序的成功迁移。
基础设施支持	没有云迁移经验的团队可能需要在他人帮助下设置云服务器、网络支持、应用程序和数据库。
人员配备	项目进行中，可能需要有专门的团队重点支持迁移工作。
政策支持	由于云迁移通常会突破现有应用程序/项目ATO的界限，可能需要更新或替换ATO。
变更管理	除了技术变革之外，迁移到云架构还需要流程变更。认识到这一点，留出余地修改流程，能够从一定程度上缓解变更带来的不便。

除了这些常见挑战，各机构还应考虑数据迁移带来的技术挑战。数据量越大，需要的迁移、验证和支持时间就越长。如果还要求应用程序持续运行或仅有短时中断，或底层数据频繁更改，迁移难度就会进一步增加。表2详细介绍了将数据迁移到云的技术挑战。

表2：云迁移的技术挑战

技术挑战	对迁移的影响
数据完整性	迁移必须通过加密确保数据在传输过程中的安全性，还要确保数据完整无缺地到达其最终存储位置。
尽量缩短停机时间	机构的许多应用程序都在政府办公时间内运行，可在周末停机。特定应用程序可能有更严格的停机要求。更换系统时，需要做好准备工作，并且在许多情况下，建议在云中迭代推出应用程序，从而最大限度地减少过渡期间的停机时间。
网络支持	数据迁移时，会有大量数据通过机构的网络基础设施，机构应了解网络的延迟和吞吐量。这些指标有助于做出明智决策，将数据顺利迁移到云厂商环境。对于不得不迁移数据和应用程序的开发人员以及家庭网络上的最终用户来说，带宽可能也是一个问题。

4.2.2 云迁移的好处

云服务可为机构带来许多运营和经济效益，因为许多业务和任务流程本质上都是以云为中心的。NIST SP 800-145总结了云计算的五大基本特征，即按需自助服务、广泛网络访问、资源池化、快速弹性和可计量服务。硬件可根据租户的需求进行配置，与传统硬件采购和管理相比，这是一大巨变。租户可以选择虚拟机（VM），而非保留硬件。此外，租户可以彻底放弃实例化服务器（虚拟机或裸机），而在CSP提供的平台上构建。这样的话，机构可将健康监测和补丁管理的一些日常工作移交给CSP，不过，仍需对系统的安全负责。调配的资源也可能位于区域内的不同地点和可用区（Availability Zone），而不是仅在某处，如本地服务器机房或数据中心。研究云服务时，机构应该考虑自己的资产和需要，确定是否适合实施云服务。表3列出了云迁移带来的部分显著效益。

表3：云迁移的好处

效益	对项目的益处
更广泛支持	有多个云厂商和多种支持服务可供选择。
设计的灵活性	云服务提供托管服务，如文档存储、具有复制功能的数据库存储和自动化应用程序接口。
可扩展性能	云服务支持大幅度水平扩展，允许向应用程序的资源池添加机器。可扩展是分布式系统的关键特性。
可用性	云服务能管理应用程序底层基础设施的故障，可以在尽可能不中断运行的情况下移动代码。
成本	CSP服务可以提高效率，同时允许机构将财政资源向关键任务倾斜。
灾难恢复和业务连续性	机构若拥有外部云数据和基础设施，本地发生意外（如自然灾害）时就能更好地应对并恢复。
网络安全	CSP通常提供各种安全方案，客户无需自行构建支持方案。然而，至关重要的是，各机构要了解这些方案，选择最合适的方案进行实施和配置。

4.2.3 云迁移策略

表4列举了行业合作伙伴宣传的一些主要云迁移策略。机构在迁移应用程序时可能需要使用多种策略。并非所有应用程序都适用于云环境，机构在迁移时必须考虑自己的特定需求。例如，应用程序可能需要使用本地网络，保证低延迟，而CSP可能无法提供这种速度。

表4：云迁移策略

云迁移策略	说明
再托管（Rehost)	这项技术以一种“平移”（Lift and Shift)方式重新创建应用程序架构，将原始设置转移到云服务器上。
重构（Refactor/Rearchitect)	该方法将应用程序重组为用例，基本原理是从代码和架构的角度利用云原生服务。
修改/重建平台（Revise/Re-platform）	修改应用程序是指迁移和扩展应用程序的一部分，以利用云原生服务。流行的方案是利用云原生托管数据库，因为这可以降低维护工作量。
重建	重建应用程序是指放弃现有应用程序，利用云基础设施创建新的应用程序。这需要将应用程序创建或放置到云原生解决方案中。
替换	这种技术是指将用例迁移到第三方厂商的SaaS环境，因而无需继续使用老旧应用程序。

在再托管策略和重构或修改策略之间存在着很多争论，各机构应仔细斟酌，选用适合自己的策略。有些时候，由于弃用了老旧系统，需要将应用程序迁移到云中，但重构又不可行。这种情况下，正确的策略可能是在完成再托管后进行重构。重构仍然值得考虑，因为IaaS或PaaS的云原生服务可以通过多种方式降低复杂性、提高性能并降低托管成本。

将服务迁移到云环境以及在云环境之间迁移服务时，机构可能必须考虑不同类型的服务之间的细微差别。例如，机构可以选择迁移开发过程。在这种情况下，可采用DevSecOps实时维护新集成的云原生解决方案，满足按需基础设施的独特的可扩展性和灵活性需求。例如，机构可能决定利用容器化为每项服务的消费者编排计算资源。

4.3 云迁移场景

应用程序不同，云迁移也不同，因此，很难给出统一的迁移建议。不过，若按以下阶段循序渐进可以提高成功率。

计划：确定选用哪种策略、哪个CSP和哪种服务类型，制定应用程序的路线图。
设计：为应用程序创建架构，重点关注系统的分布式特性。试用CSP的云原生功能。
引导：创建最小可行产品（MVP），证明该应用程序可在云中工作。
迁移：做好准备，生产云版本，包括移植必要数据。
维护：从产品功能角度以及性能角度持续改进云应用程序。

以下各小节概述了机构的常见迁移场景。这些场景侧重于迁移到云环境时应用程序架构的变化方式，未关注环境中的常规安全功能。

4.3.1 场景1—PDF存储上云（IaaS）

场景1描述：

机构要迁移一个有1万名用户的内部应用程序，其中存储了用户上传的数百万份PDF文档，数据总量达1 PB（1000 TB）。该应用程序使用本地数据中心，数据存储在多个服务器机架上。

在云迁移的第一阶段，该机构希望在云中存储新上传的文件，暂不迁移旧文件。在这种情况下，机构需要额外一层来管理已存储文件位置的标识。机构应研究如何将新上传的文件正确无误地转移到云环境，再加上当前本地和云中都有文件，机构还应通过反向代理将用户重定向到正确的文件位置。最后，机构还需要在开发环境中仔细测试所有假设，为迁移做好准备。图3概要呈现了了第一阶段的架构。

图3：场景1—第一阶段概念性架构

在云迁移的第二阶段，机构希望将旧文件迁移到云存储。他们需要与网络团队协调一个最佳时间，通过网络传输总量达1PB数据。本地部署的应用服务器将收集分布式数据，生成一组完整性校验和以供将来验证，并通过加密链接将流量转发到云环境。机构应尽可能可考虑通过硬盘或其他存储器将所有数据传输至CSP。与通过网络传输所有数据比，这种技术可能效率更高。

两个阶段的不同如图4所示。

图4：场景1—第二阶段带外数据传输的概念性架构

数据进入云存储时要进行验证以确保正确性。一旦数据迁移，机构应确保用户和文件上传者都能无缝使用云环境。这时，本地数据中心就可以停用或改变用途了。

4.3.2 场景2—网站迁移到PaaS服务

场景2描述：

机构决定将本地托管的传统网站基础设施迁移到新设计的现代内容管理系统。在过去20年中，该机构在本地维护的传统内容管理系统（CMS）上托管了数千个页面。

在这种情况下，老旧基础设施明显过时，许多网页需要重新设计。机构决定使用PaaS改进CMS。图5显示了迁移和重新设计期间一些网页的架构。

图5：场景2—网站迁移至PaaS的概念性架构

在迁移和重新设计之后，机构认识到，大多数网页内容是公开的，不会频繁更改，因此适用于内容交付网络（CDN）。使用CDN后，机构可将大部分内容缓存在更靠近用户的位置，提高上传速度。机构将进行测试，将文件迭代迁移到CDN，并配置CDN处理用户流量。机构应进行评估，确定将哪些数据缓存在CDN服务中。许多CDN提供了额外的安全功能，如分布式拒绝服务（DDoS）攻击防护和Web应用程序防火墙（WAF），机构可以利用这些功能。大多数数据都是公开的，因此可以在授权范围之外缓存。有些数据有受控非密信息（CUI）要求，因此不应缓存，或者可以使用授权CDN服务商。图6为网站迁移到PaaS的示例。

图6：场景2—使用CDN的网站的概念性架构

预期结果是，停用本地环境，机构网站将在PaaS环境中运行，CDN入口如图7所示。

图7：场景2—新网站的概念性最终架构

4.3.3 场景3—监控面向公众的应用程序

场景3描述：

机构需要监控其面向公众的网站，保证正常运行，为用户持续提供服务。

该机构拥有多个网站，位于不同地点，因此需要研究能够处理这种分布式系统的性能监控方案。机构决定进行综合监控，包括自动化潜在用户操作，查看系统如何响应，并根据这些请求收集有关正常运行时间的指标。是在PaaS或IaaS系统中部署自己的监控基础设施抑或设计SaaS系统生成综合流量、收集相关指标？机构考虑了技术因素并权衡了成本，最终决定使用SaaS系统（图8）。

图8：场景3—基于SaaS进行网站监控的概念性部署架构

4.4 培养DevSecOps思维

DevSecOps，指开发、安全和运营，是一种软件开发理念，将代码编写与代码测试、保护和部署紧密结合在一起。传统的DevSecOps循环如图9所示。它可以打破开发人员、安全工程师、运营工程师和质量保证人员等传统角色之间的隔阂，让他们发挥团队作用。这可以通过跨职能团队实现，这些角色并肩工作，对成功开发、启动和维护服务负全权责任。

DevSecOps应该是各机构开发、保护和交付云应用程序的主要方法。DevSecOps通常利用持续集成（CI）、持续交付（CD）、基础设施即代码（IaC）、安全测试和最小权限原则来实现自动化，开发出可扩展、可预测的可靠数字服务。

图9：DevSecOps循环

4.4.1 持续集成和持续交付

有了持续集成，代码集成、构建和测试中的重复活动可以自动化，减少人为错误，加速进程，保证可靠性。持续集成发生在产品生命周期的早期，随着项目的成熟而扩展。有很多工具可用于存储、构建和测试源代码，部分SaaS产品已经FedRAMP批准，开发团队可根据需要选用具体产品。IaaS和PaaS服务商也可以提供这些服务。

源代码管理软件还可以执行代码审查和代码检入程序，进一步减少人为错误，在系统中添加抗抵赖性。

持续交付指使用自动化定期集成、构建和测试代码的过程。它以持续集成管道（CI Pipeline）为基础，确定代码何时可以投入生产。这些过程统称为CI/CD。

通过设置测试的通过/失败标准，在SDLC早期做好部署准备，然后使用自动化流程检查是否满足标准，机构可以生产出更可靠的软件用于部署。这种做法不仅有助于及早发现部署问题，还能够支持敏捷工作流，允许在开发过程中进行更频繁的小改动，向利益相关者演示具有部分功能的产品，从而得到他们的更大支持。

4.4.2 基础设施即代码

除了用代码编写应用程序外，开发团队还可以将基础设施编写为机器可读的定义文件，对数字服务进行自动化配置、运行时更改和停用并进行文字记录。这就是基础设施即代码（IaC），允许团队在检入代码之前审查IaaS或PaaS中所使用资源的更改情况。IaC还能促进云基础设施的批量生产，进而快速应用补丁，使环境可以自动扩展。手动维护的服务器需要一台台单独修补；因此，手动更新后，基础设施容易偏离原始配置。

IaC可以提供多种好处：

无需为每台设备配置用户界面（UI），进一步减少了人为错误的机会；
使用IaaS或PaaS功能自动进行合规性检查，例如对存储容器强制执行静态加密；
自动化ICAM策略的部署以及细粒度访问控制；
简化安全测试、补丁部署和更新；
对网络实施加密以及通过代码进行存储，实现更为成熟的零信任。

与其他软件一样，IaC还可以对环境进行降级更改，可能在以前安全的环境中意外引入新漏洞。为了降低漏洞风险，机构应监控IaC代码，防止出现错误配置，并/或对生产部署执行安全代码审计。

4.4.3 安全测试自动化

DevSecOps流程中的另一因素是应用程序安全测试。作为DevSecOps流程中的一部分，测试应在软件开发生命周期的早期进行，是集成安全的关键方法。应用程序安全测试利用对代码的静态分析来查找常见的编码问题（如潜在的结构化查询语言（SQL）注入漏洞），并利用动态测试来查看代码如何协同工作。通过该测试，机构可在生产之前以及更易修复时修复潜在的安全问题。在整个CI/CD过程中进行测试也会提升零信任成熟度。

开发过程中的自动化安全测试只是针对应用程序漏洞的一层防御措施。人工分析、第三方安全测试、公开漏洞披露程序以及漏洞赏金计划协同工作，构成多层防御，确保应用程序得到执行，提高漏洞在被利用之前的检出率。

图10为CI/CD系统架构示例，其中有两处存在安全测试。开发人员将应用程序和基础设施的代码检入到相关存储库中。构建系统构建应用程序，开始测试。失败的测试记录到监控系统，测试结果（或会带有告警或状态页面）通知开发人员。构建中的所有问题解决后，应用程序就可以部署到开发环境中接受进一步测试。解决所有问题后，应用程序可以升级到生产环境，准备付诸使用。

图10：具有安全测试的构建系统的参考架构

基础设施测试也可以自动化。根据IaC中定义的结构，使用安全扫描器扫描不应开放的端口，以便尽早（最好是在互联网上公开之前）发现潜在问题。

4.4.4 最小权限原则

机构应确保每个DevSecOps团队成员有足够权限完成工作，且权限不超过工作需要的范围。最小权限原则根据任务和角色确定每个人的权限范围和时长。这限制了内外部恶意人员提权或移动的可能性，降低了滥用风险。有些CSP能够根据给定时间范围内的活动在基础设施内提供不同的权限。当有人监督运营时（“轮班”），可以授予他们额外角色，以便访问和更改生产。轮班结束后，移除角色。另一种方法是授予临时紧急访问权限进行故障修复。

通过其他安全最佳实践，可以降低角色不断扩展的风险，例如在整个团队中设置更细粒度的访问权限，并强制定期撤销不必要权限。

员工离开团队后及时删除权限也很重要。

在最小权限方面，兴起了基于属性的访问控制（ABAC）。ABAC比基于角色的控制更进一步，对用户身份、被访问资源的属性和环境进行检查。角色成为用户身份的一个属性。另一个需要检查的同等重要属性是“该用户可以访问数据吗？”此外，基于公共环境的属性检查针对的是用户正在使用的设备的信息：该机构设备是否打了最新补丁？组合多个属性可以提高下述信息的可信度：用户身份与其宣称相符；用户有权执行所请求的操作。ABAC是成熟零信任体系结构的核心组件，在访问决策中涉及多个支柱。

传统上，职责分离被用来阻止内部威胁，重要任务要求多人执行，以便发现无心之失。例如，开发和编码团队与生产部署团队为两个不同团队。这种方法与DevSecOps存在矛盾，因为对于后者，这些责任在同一团队中分担。

替换过程是涉及两人的代码审查，目的是检查代码的完整性。这意味着在提交更改并将其合入主存储库之前，每一代码和配置更改都必须由另一个授权团队成员进行审查和批准。这对于应用程序代码和IaC都很有用，可以在部署前发现问题。许多代码存储库可配置为强制执行代码审查。此外，允许禁用此设置的存储库管理员账号不应用于常规的日常活动。

4.5 集中通用云服务

开发人员将应用程序迁移到云以及在云中创建和部署应用程序时，机构可以通过管理和维护共享服务来提供帮助。通过提供共享服务，开发人员可将更多的时间集中在任务上，不用分散精力考虑开销或维护任务。这些服务分为四个领域：

代理PaaS
开发工具和服务
面向公众的服务
安全服务

在机构级别共享部分服务，省去了管理费用，团队可以加速采用云原生技术，进而可以考虑如何节省其他费用。团队开始可能为Web服务器运行完整的虚拟机，后续可以转移到使用容器运行，再然后从容器转到“功能即服务”。

机构从传统的本地部署服务器转向IaaS，还会导致特定角色的职责发生转变。团队将不再需要专门人员来管理数据库所在服务器，但仍然需要专业知识来理解如何使数据库发挥性能。这种模式下，数据库管理员可以专注于战略运营，同时在机构内提供咨询。

4.5.1 为什么要集中？

在机构内集中IaaS、PaaS和SaaS有两个主要原因：节省资源、构建共享体验。新工具和软件的采购是资源密集型任务。机构可以集中成立一个综合团队来降低总体成本，负责所有团队所使用工具的研究、采购和培训。此外，集中服务（如后续章节所述）有助于理顺维护和合规工作，达到节省资源的目的。

通过集中服务，机构可以向内部各团队提供通用工具，构建共享体验，实现协作。集中式文档有助于将知识传播到团队外部。使用同一工单、寻呼和监控系统，团队可在云服务中断时协同工作，还有助于让跨团队调动人员快速融入新团队。

有云项目经验的团队还能总结最佳实践和挑战领域并进行分享，其他团队可以从中吸取经验教训。经验丰富的团队可以指导新团队，传授掌握的知识和技能，从而增加对人员的总体投资。节省资源和打破组织中的孤岛是集中云工具的两个重要原因。

4.5.2 机构平台即服务

机构可以批量采购云基础设施，根据需要向各团队分配访问权限，从而集中处理对现有IaaS工具的访问。这样，权限分配就能有理可依，新团队也可以快速使用基础设施。机构的云团队更像是PaaS角色，对操作系统、软件库和日志进行标准化配置。这些原则共同作用，可以加快云化数字服务的发展，节省资源。

集中式IaaS可以建立规范行为，确保合规，同时减轻开发团队的安全文书（如ATO）工作负担。主流IaaS平台支持合规检查，例如当存储容器是公共或未加密时通知团队快速解决问题。各团队共享平台时，可以从组织账号继承NIST SP 800-53控制措施，在其软件支持计划（SSP）协议中使用通用语言，加快文书工作。

机构可以集中“黄金镜像”（Gold Image）虚拟机并建立工件库，这样，团队就可以共享IaC中使用的容器。也可以根据OMB M-21-31中提出的日志标准设置虚拟机和容器。可用性和安全性之间的矛盾是：机构可以在基础镜像（Base Image）上添加安全监控，但同时要保证镜像正常工作，避免系统因进行过多额外处理而过载。在整个环境中强制执行定期修补可以增加额外的安全保护。

在引入IaC的同时使用工件库，开发团队距离“不可变工作负载”（Immutable Workloads）概念就更近了一步。云基础设施和代码部署后就不会再手动升级或更改。任何变更都将通过CI/CD管道进行，系统将重新部署。

加密服务为Web服务器上的应用程序提供证书，确保应用程序使用安全信道（如TLS）。此外，必要时，这些服务可直接或通过托管服务加密静止数据。

对密钥和密码进行管理，要求应用程序定期更改密钥和密码，而不中断应用程序运行。密码泄露后，该服务必须能够使其失效。

4.5.3 开发工具和服务

开发工具和服务是快速高效构建和维护应用程序的关键。本节介绍了应用程序开发中的部分常用工具和服务。

除了DevSecOps，软件开发生命周期也广泛使用协作工具、需求跟踪和文档来共享团队内部和团队之间的当前状态评估结果。在全机构范围内进行合作并统一文档实践造就了共享和协作文化。

源代码控制产品是CI/CD管道的基础，因为它决定了哪些工具可用于构建、测试和部署代码。以“linter”形式执行代码质量控制并检查编码“反模式”也是 CI/CD 的重要组成部分，可以在整个机构内标准化；前者检查代码是否存在妨碍执行或难以读取的问题，后者防止不当编码约定导致不安全或未优化代码。

在CI/CD管道中集成安全测试对于全机构的集中和标准化也很重要，因为统一的安全应用可以改善整体流程。静态和动态安全测试可以达到提前预防的目的，防止将漏洞意外带入生产环境。

4.5.4 面向公众的服务

机构向公众提供的数字服务会从集中化中局部受益。

部署新网站的常规工作包括获取域名、为站点配置域名系统（DNS）条目以及设置超文本传输安全协议（HTTPS）证书。将这些流程集中起来，机构可以准确记录其网络活动。

应用程序和API如果可以通过互联网访问，需要防止恶意流量。可以采用WAF、API网关和内容交付网络（CDN）进行保护，这些措施还可以防护DDoS攻击。WAF通常可以控制对网络的访问，检查发往Web服务器的请求，检测常见的网站攻击。API网关控制特定用户对API的访问，同一网关可以保护多个API。

CDN不仅将缓存数据存储在更靠近用户的位置以加快交付，通常还可以吸收拒绝服务（DoS）攻击中的超常流量，或者通过防火墙限制网络流量。机构的所有互联网财产都需要这种保护，批量购买可以节省成本。

4.5.5 安全服务

各机构应尽可能在全组织范围内部署集中式综合安全服务。同一服务的独立实例越少，机构的攻击面就越小。安全服务提供应用程序保护，如日志记录、身份认证、授权、加密和密钥管理。

集中式日志是改善事件响应的关键，为本地存储的日志实现了冗余，减少了删除日志的影响。集中式日志还减少了事件响应者的调查时间。OMB M-21-31也规定了各部门须与上级部门共享日志，而集中化简化了该过程。集中式日志还有助于跨CSP和本地解决方案查找威胁。

就机构服务而言，可首先从单点登录的ICAM入手，因为首席信息官（CIO）可能已经有能力让员工登录到电子邮件等服务。即使在本地，轻量级目录访问协议（LDAP）也可以代理对云服务的访问，这样，就免去了员工再记一个密码的麻烦。图11为集中式身份和日志的示例配置。

图11：集中式安全服务参考架构

机构在将新的SaaS产品安装到集中式ICAM系统时，应尽量减少冲突。在全面采用和集成服务之前，机构应探索建模或进行试连接，以发现并解决初始性能和安全相关问题，更好地进行后续集成。

授权（即确定用户是否有权执行操作的过程）通常包含在ICAM服务中。但是，有时需要应用程序强制授权。开发团队需要能够持续请求获取授权信息。在机构实现零信任的过程中，授权将从基于角色转向基于属性，并需要包含多个支柱的信息。集中化也有利于授权。

4.6 人为因素

通过CSP构建可扩展、可复用的架构需要对流程和过程进行更改，这不仅适用于部署工具和应用程序的员工，也适用于利益相关者和这些工具的用户。机构需要进行人力投资开展云项目，还需要重新设计流程，开展全员教育，确保访问的可靠性。

4.6.1 进行人才投资

人才投资是云项目成功的关键，包括培训、雇佣和采购。在传统软件开发环境中工作的联邦雇员可以接受云技术方面的再培训，但这需要机构进行相关投资，以获取外部课程、培训和认证，并允许员工利用工作时间学习新技术。这还可以包括现代项目管理方法上的培训。为了加强培训，机构需要为员工提供机会练习新技能（例如，进入沙箱环境对新技术进行实验）。实验、迭代以及允许“快速失败”（Fail Fast）可以帮助刚接触云技术的员工培养技能，提供卓越的数字服务。

雇佣具有云项目经验的新员工是另一种人才投资方式。为新职位招人具有一定难度，因为人才储备通常有限。为高效聘用技术人才，可采用人事管理局（OPM）的主题专家资格评估（SME-QA）流程。使用该方案，需要类似员工（如设计师或产品经理）的机构可共享工作申请，通过技术评估筛选候选人，创建合格候选人库，供各自选择。SME-QA提高了通过竞争性招聘的职位数量，缩短了招聘时间。很难从私营部门吸引有经验的软件开发专业人员。原因有很多，工资是其中之一。

机构可以与人事管理局合作，想办法按照一般俸表（GS）提高工资水平，并提供签约奖金和高质量培训机会。

最后，可以采购承包商服务，开发数字服务和部署CSP产品。TechFAR Hub是一个采购资源中心，采购人员可以获取IT服务采购方法，包括云服务和软件开发承包商。TechFAR Hub推出了一项名为“数字IT采办人员培训”（DITAP）的计划，为采购人员提供培训。

4.6.2 支持人员

机构应提供入职培训和其他书面程序，通过额外培训和及时访问来支持联邦工作人员。所有人员都需要额外培训，学习使用新CSP工具，了解云工具如何改变安全模式。安全培训可包括反钓鱼培训和正确的数据处理。

这种新安全模式要求下述人员做出调整：（1）直接参与数字服务开发的人员（例如DevSecOps工作人员）；（2）从非技术角度支持数字服务的人员。开发团队和利益相关者之间加强沟通有助于打破长期以往形成的孤岛。跨部门合作，将开发、安全和运营融为一体，能够促进协作，消除信息孤岛。

提供及时访问还降低了员工开发“影子IT”服务的可能性，这些服务能绕过IT或安全团队的监控，削弱联邦政府的整体网络安全态势。

免责声明：该文章原文版权归原作者所有。文章内容仅代表原作者个人观点。本译文仅以分享先进网络安全理念为目的，为业内人士提供参考，促进思考与交流，不作任何商用。如有侵权事宜沟通，请联系littlebee@nsfocus.com邮箱。

译者简介

小蜜蜂翻译组公益译文项目，旨在分享国外先进网络安全理念、规划、框架、技术标准与实践，将网络安全战略性文档翻译为中文，为网络安全从业人员提供参考，促进国内安全组织在相关方面的思考和交流。

一、 前言