本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

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

合規是 AWS 與其服務消費者共同的責任。一般而言，AWS 負責「雲端安全」，而其使用者負責「雲端安全」。說明 AWS 及其使用者所負責內容的行會因服務而異。例如，透過 Fargate，AWS 負責管理其資料中心、硬體、虛擬基礎設施 (Amazon EC2) 和容器執行期 (Docker) 的實體安全性。Fargate 的使用者負責保護容器映像及其應用程式的安全。在執行必須遵循合規標準的工作負載時，了解誰負責處理什麼是重要的考量事項。

下表顯示不同容器服務符合的合規計劃。


| 合規計劃 | Amazon ECS Orchestrator | Amazon EKS Orchestrator | 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 III  |  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 Moderate (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 高級  |  1  |  1  |  0  |  1  | 
|  OSPAR  |  1  |  1  |  0  |  1  | 
|  HITRUST CSF  |  1  |  1  |  1  |  1  | 

合規狀態會隨著時間而變更。如需最新狀態，請務必參閱 https：//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>

政策可視為一組管理行為的規則，即允許的行為或禁止 的行為。例如，您可能有一個政策，指出所有 Dockerfiles 都應包含 USER 指令，導致容器以非根使用者身分執行。做為文件，這類政策可能很難探索和強制執行。它也可能隨著您的需求變更而過時。透過政策即程式碼 (PaC) 解決方案，您可以自動化偵測、預防、減少和對抗已知和持久性威脅的安全性、合規性和隱私權控制。此外，它們為您提供機制來編纂您的政策，並在您執行其他程式碼成品時對其進行管理。這種方法的好處是您可以重複使用 DevOps 和 GitOps 策略，以管理和一致地在 Kubernetes 叢集的機群間套用政策。如需 PaC 選項和 PSPs 未來的相關資訊，請參閱 [Pod Security](https://aws.github.io/aws-eks-best-practices/security/docs/pods/#pod-security)。

### 在管道中使用policy-as-code工具，在部署之前偵測違規
<a name="_use_policy_as_code_tools_in_pipelines_to_detect_violations_before_deployment"></a>
+  [OPA](https://www.openpolicyagent.org/) 是一種開放原始碼政策引擎，屬於 CNCF。它用於制定政策決策，並且可以執行各種不同的方式，例如 作為語言程式庫或服務。OPA 政策是以稱為 Rego 的網域特定語言 (DSL) 撰寫。雖然它通常作為 [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) 專案的 Kubernetes 動態許可控制器的一部分執行，但 OPA 也可以納入您的 CI/CD 管道。這可讓開發人員在發行週期之前取得有關其組態的意見回饋，進而協助他們在進入生產環境之前解決問題。您可以在此專案的 GitHub [儲存庫](https://github.com/aws/aws-eks-best-practices/tree/master/policies/opa)中找到常見 OPA 政策的集合。
+  [Conftest](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 [網站上找到所有 Kyverno](https://kyverno.io/policies/) 社群政策，如需使用 Kyverno 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-security](https://github.com/docker/docker-bench-security) 
+  [AWS Inspector](https://aws.amazon.com/inspector/) 
+  [Kubernetes Security Review](https://github.com/kubernetes/community/blob/master/sig-security/security-audit-2019/findings/Kubernetes%20Final%20Report.pdf) Kubernetes 1.13.4 的第三方安全性評估 (2019)
+  [NeuVector by SUSE](https://www.suse.com/neuvector/) 開放原始碼、零信任容器安全平台，提供合規報告和自訂合規檢查