认证和合规声明¶
合规性和安全性并非相互排斥，必须同时解决。OpenStack部署不太可能在没有安全加固的情况下满足合规性要求。以下列表为OpenStack架构师提供基础知识和指导，以实现符合商业和政府认证及标准。
商业标准¶
对于OpenStack的商业部署，我们建议将SOC 1/2与ISO 27001/2结合起来，作为OpenStack认证活动的基础。这些认证要求的安全活动有助于建立安全最佳实践和通用控制标准的基础，从而有助于实现更严格的合规活动，包括政府证明和认证。
完成这些初始认证后，其余认证将更加具体地取决于部署情况。例如，处理信用卡交易的云需要PCI-DSS，存储医疗保健信息的云需要HIPAA，而联邦政府内的云可能需要FedRAMP/FISMA和ITAR认证。
SOC 1 (SSAE 16) / ISAE 3402¶
服务组织控制 (SOC) 标准由美国注册会计师协会 (AICPA) 定义。SOC控制评估相关财务报表和服务提供商的声明，例如符合萨班斯-奥克斯利法案。SOC 1是审计准则第70号（SAS 70）II型报告的替代方案。这些控制通常包括物理数据中心在范围内。
SOC 1报告有两种类型
I型 - 报告管理层对服务组织系统描述的公正性以及控制设计是否适合实现描述中包含的相关控制目标的评估，截至特定日期。
II型 - 报告管理层对服务组织系统描述的公正性以及控制的设计和运行有效性是否适合实现描述中包含的相关控制目标在特定期间内的评估。
有关更多详细信息，请参阅AICPA服务组织控制报告。
SOC 2¶
服务组织控制 (SOC) 2是对影响服务组织用于处理用户数据以及这些系统处理的信息的安全性、可用性和处理完整性以及保密性和隐私性的控制的自我证明。用户示例包括负责服务组织治理的人员、服务组织的客户、监管机构、业务合作伙伴、供应商以及对服务组织及其控制有了解的其他人。
SOC 2报告有两种类型
I型 - 报告管理层对服务组织系统描述的公正性以及控制设计是否适合实现描述中包含的相关控制目标的评估，截至特定日期。
II型 - 报告管理层对服务组织系统描述的公正性以及控制的设计和运行有效性是否适合实现描述中包含的相关控制目标在特定期间内的评估。
有关更多详细信息，请参阅AICPA服务组织控制报告。
SOC 3¶
服务组织控制 (SOC) 3是服务组织的信任服务报告。这些报告旨在满足希望对服务组织控制获得保证的用户需求，这些控制与安全性、可用性、处理完整性、保密性或隐私性相关，但不需要或没有必要的知识来有效使用SOC 2报告。这些报告是使用AICPA/加拿大注册会计师协会 (CICA) 信任服务原则、标准和说明书，用于安全性、可用性、处理完整性、保密性和隐私性编制的。由于它们是通用报告，因此SOC 3报告可以自由分发或发布在网站上作为印章。
有关更多详细信息，请参阅AICPA服务组织信任服务报告。
ISO 27001/2¶
ISO/IEC 27001/2标准取代了BS7799-2，是信息安全管理体系 (ISMS) 的规范。ISMS是组织创建和维护的一套全面的策略和流程，用于管理信息资产的风险。这些风险基于用户信息的保密性、完整性和可用性 (CIA)。CIA安全三要素已被用作本书许多章节的基础。
有关更多详细信息，请参阅ISO 27001。
HIPAA / HITECH¶
健康保险可携性和责任法案 (HIPAA) 是美国国会颁布的一项法律，管理患者健康记录的收集、存储、使用和销毁。该法案规定，受保护的健康信息 (PHI) 必须对未经授权的人员“无法使用、无法读取或无法破译”，并且应解决“静态”和“传输中”数据的加密问题。
HIPAA不是一项认证，而是保护医疗保健数据的一项指南。与PCI-DSS类似，PCI和HIPAA最重要的议题是信用卡信息和健康数据的泄露不会发生。发生泄露时，云提供商将受到对其符合PCI和HIPAA控制的审查。如果证明符合，预计提供商将立即实施补救控制、泄露通知责任以及在其他合规活动上进行大量支出。如果不符合，云提供商可以预期现场审计团队、罚款、潜在的商家ID丢失（PCI）以及巨大的声誉影响。
拥有PHI的用户或组织必须支持HIPAA要求，并且是HIPAA涵盖实体。如果实体打算使用服务，或者在本例中，使用可能使用、存储或访问该PHI的OpenStack云，则必须签署业务伙伴协议 (BAA)。BAA是HIPAA涵盖实体与OpenStack服务提供商之间的合同，要求提供商根据HIPAA要求处理该PHI。如果服务提供商不处理PHI，例如通过安全控制和加固，则他们将受到HIPAA罚款和处罚。
OpenStack架构师解释和响应HIPAA声明，数据加密仍然是核心实践。目前，这将需要OpenStack部署中包含的任何受保护的健康信息都必须使用行业标准加密算法进行加密。潜在的未来OpenStack项目，例如对象加密，将有助于遵守该法案的HIPAA指南。
有关更多详细信息，请参阅健康保险可携性和责任法案。
PCI-DSS¶
支付卡行业数据安全标准 (PCI DSS) 由支付卡行业标准委员会定义，旨在增加对持卡人数据的控制，以减少信用卡欺诈。年度合规性验证由外部合格安全评估员 (QSA) 评估，QSA创建合规报告 (ROC)，或由自我评估问卷 (SAQ) 评估，具体取决于持卡人交易量。
存储、处理或传输支付卡详细信息的OpenStack部署在PCI-DSS范围内。所有未从处理支付数据的系统或网络正确隔离的OpenStack组件都受PCI-DSS指南约束。在PCI-DSS的背景下，分段不支持多租户，而是物理分离（主机/网络）。
有关更多详细信息，请参阅PCI安全标准。
政府标准¶
FedRAMP¶
“联邦风险和授权管理计划 (FedRAMP) 是一个政府范围内的计划，为云产品和服务提供标准化的安全评估、授权和持续监控方法”。NIST 800-53是FISMA和FedRAMP的基础，它强制执行专门选择的安全性控制，以在云环境中提供保护。FedRAMP在安全性控制的特异性和满足政府标准所需的文档数量方面可能非常密集。
有关更多详细信息，请参阅FedRAMP。
ITAR¶
国际武器贸易条例 (ITAR) 是一套美国政府法规，控制美国军火清单 (USML) 上与国防相关的物品和服务以及相关技术数据的进出口。云提供商通常将ITAR视为“运营对齐”，而不是正式认证。这通常涉及实施根据FISMA要求基于NIST 800-53框架的隔离云环境，并辅以额外的控制措施，限制访问“美国公民”并进行背景调查。
有关更多详细信息，请参阅国际武器贸易条例 (ITAR)。
FISMA¶
联邦信息安全管理法案要求政府机构制定全面的计划，以实施众多政府安全标准，并在2002年的电子政务法案中颁布。FISMA概述了一个流程，该流程利用多个NIST出版物，为信息系统准备存储和处理政府数据。
此过程分为三个主要类别
- 系统分类
信息系统将根据联邦信息处理标准出版物199 (FIPS 199) 获得安全类别。这些类别反映了系统妥协的潜在影响。
- 控制选择
基于FIPS 199中定义的系统安全类别，组织使用FIPS 200来识别信息系统的特定安全控制要求。例如，如果系统被分类为“中等”，则可能会引入一项要求，强制执行“安全密码”。
- 控制定制
一旦识别出系统安全控制，OpenStack架构师将使用NIST 800-53来提取定制控制选择。例如，指定什么构成“安全密码”。
