本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 合规
<a name="compliance"></a>

合规是 AWS 及其服务使用者的共同责任。一般而言，AWS负责 “云安全”，而其用户负责 “云安全”。界定 AWS 及其用户应负责的界限将因服务而异。例如，在 Fargate 中，AWS 负责管理其数据中心、硬件、虚拟基础设施 (Amazon EC2) 和容器运行时 (Docker) 的物理安全。Fargate 的用户负责保护容器镜像及其应用程序。在运行必须遵守合规性标准的工作负载时，知道谁应对什么负责，这是一项重要的考虑因素。

下表显示了不同容器服务所遵循的合规计划。


| 合规计划 | 亚马逊 ECS Orchestrator | 亚马逊 EKS 管弦乐器 | ECS Fargate | Amazon ECR | 
| --- | --- | --- | --- | --- | 
| PCI DSS 1 级 | 1 | 1 | 1 | 1 | 
| 符合 HIPAA 要求 | 1 | 1 | 1 | 1 | 
| SOC I | 1 | 1 | 1 | 1 | 
| SOC II | 1 | 1 | 1 | 1 | 
| SOC II | 1 | 1 | 1 | 1 | 
| ISO 27001:2013 | 1 | 1 | 1 | 1 | 
| ISO 9001:2015 | 1 | 1 | 1 | 1 | 
| ISO 27017:2015 | 1 | 1 | 1 | 1 | 
| ISO 27018:2019 | 1 | 1 | 1 | 1 | 
| IRAP | 1 | 1 | 1 | 1 | 
| FedRamp 中等 () East/West | 1 | 1 | 0 | 1 | 
| FedRamp High () GovCloud | 1 | 1 | 0 | 1 | 
| DOD CC SRG | 1 | DISA 评论 (IL5) | 0 | 1 | 
| HIPAA BAA | 1 | 1 | 1 | 1 | 
| MTCS | 1 | 1 | 0 | 1 | 
| C5 | 1 | 1 | 0 | 1 | 
| K-ISMS | 1 | 1 | 0 | 1 | 
| ENS High | 1 | 1 | 0 | 1 | 
| OSPAR | 1 | 1 | 0 | 1 | 
| HITRUST CSF | 1 | 1 | 1 | 1 | 

合规状态会随着时间的推移而变化。要了解最新状态，请务必参阅 https://aws.amazon.com/compliance/services-in-scope/.

有关云认证模式和最佳实践的更多信息，请参阅 AWS 白皮书《[安全采用云的认证模型](https://d1.awsstatic.com/whitepapers/accreditation-models-for-secure-cloud-adoption.pdf)》 

## 向左移动
<a name="_shifting_left"></a>

左移的概念涉及在软件开发生命周期的早期发现违反政策的行为和错误。从安全角度来看，这可能非常有益。例如，开发人员可以在将应用程序部署到集群之前修复其配置问题。尽早发现这样的错误将有助于防止部署违反策略的配置。

### 政策即代码
<a name="_policy_as_code"></a>

政策可以看作是一套管理行为的规则，即允许的行为或禁止的行为。例如，您可能有一个策略，规定所有 Dockerfile 都应包含一个 USER 指令，该指令使容器以非 root 用户身份运行。作为一份文件，这样的政策可能很难发现和执行。随着需求的变化，它也可能过时。借助策略即代码 (PaC) 解决方案，您可以自动执行安全、合规和隐私控制，以检测、预防、减少和抵消已知和持续存在的威胁。此外，它们还为您提供了编纂策略并像管理其他代码工件一样管理策略的机制。这种方法的好处是，你可以重复使用你的 DevOps 和 GitOps策略，在各个 Kubernetes 集群中管理和一致地应用策略。有关 PaC 选项和 PSP 未来的信息，请参阅 P [od Secur](https://aws.github.io/aws-eks-best-practices/security/docs/pods/#pod-security) ity。

### 在部署之前，使用管道中的策略即代码工具检测违规行为
<a name="_use_policy_as_code_tools_in_pipelines_to_detect_violations_before_deployment"></a>
+  [OPA](https://www.openpolicyagent.org/) 是一个开源政策引擎，是 CNCF 的一部分。它用于制定政策决策，可以以各种不同的方式运行，例如作为语言库或服务。OPA 策略是用一种名为 Rego 的域特定语言 (DSL) 编写的。虽然 OPA 通常作为 Kubernetes 动态准入控制器的一部分作为 [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) 项目运行，但它也可以整合到你的管道中。 CI/CD 这使开发人员能够在发布周期的早期获得有关其配置的反馈，从而帮助他们在投入生产之前解决问题。可以在该项目的 GitHub[存储库](https://github.com/aws/aws-eks-best-practices/tree/master/policies/opa)中找到常用 OPA 策略的集合。
+  C@@ [onftest](https://github.com/open-policy-agent/conftest) 建立在 OPA 之上，它为测试 Kubernetes 配置提供了以开发人员为中心的体验。
+  [Kyverno](https://kyverno.io/) 是一款专为 Kubernetes 设计的策略引擎。在 Kyverno 中，策略作为 Kubernetes 资源进行管理，无需使用任何新语言即可编写策略。这允许使用熟悉的工具，例如 kubectl、git 和 kustomize 来管理策略。Kyverno 策略可以验证、变异和生成 Kubernetes 资源，并确保 OCI 映像供应链的安全。[Kyverno CLI](https://kyverno.io/docs/kyverno-cli/) 可用于测试策略和验证作为管道一 CI/CD 部分的资源。[所有Kyverno社区政策都可以在K [yverno网站上找到，有关使用Kyverno](https://kyverno.io/policies/) CLI在管道中编写测试的示例，请参阅策略存储库。](https://github.com/kyverno/policies)

## 工具和资源
<a name="_tools_and_resources"></a>
+  [Amazon EKS 安全沉浸式研讨会——合规性](https://catalog.workshops.aws/eks-security-immersionday/en-US/10-regulatory-compliance) 
+  [kube-bench](https://github.com/aquasecurity/kube-bench) 
+  [docker-bench 安全](https://github.com/docker/docker-bench-security) 
+  [AWS Inscetor](https://aws.amazon.com/inspector/) 
+  [Kubernetes 安全评论](https://github.com/kubernetes/community/blob/master/sig-security/security-audit-2019/findings/Kubernetes%20Final%20Report.pdf) Kubernetes 的第三方安全评估 1.13.4 (2019)
+  [NeuVector 由 SUSE](https://www.suse.com/neuvector/) 开源提供的零信任容器安全平台提供合规性报告和自定义合规性检查