本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
工作負載 OU — 應用程式
| 通過進行簡短的調查 |
下圖說明應用程式帳戶 (以及應用程式本身) 中設定的 AWS 安全服務。
應用程式帳戶主控執行和維護企業應用程式的主要基礎結構和服務。應用程式帳戶和工作負載 OU 有幾個主要的安全性目標。首先，您要為每個應用程式建立個別的帳戶，以便在工作負載之間提供界限和控制，以避免角色、權限、資料和加密金鑰的問題。您想要提供一個單獨的帳戶容器，讓應用程式團隊可以獲得廣泛的權限來管理自己的基礎結構，而不會影響他人。接下來，您可以為安全性作業團隊提供監視和收集安全性資料的機制，藉此增加一層保護。採用組織追蹤和本機部署的帳戶安全服務 (亞馬遜 GuardDuty、AWS Config、AWS Security Hub、亞馬遜 EventBridge、AWS IAM 存取分析器)，這些服務由安全團隊設定和監控。最後，您可以讓您的企業集中設定控制項。您可以將應用程式帳戶與更廣泛的安全性結構對齊，方法是將其設為 Workload OU 的成員，藉此繼承適當的服務權限、條件約束和防護。
設計考量
-
在您的組織中，您可能會有一個以上的商務應用程式。工作負載 OU 旨在容納您大部分的業務特定工作負載，包括生產環境和非生產環境。這些工作負載可以混合商業 off-the-shelf (COTS) 應用程式，以及您自己內部開發的自訂應用程式和資料服務。有幾個模式用於組織不同的業務應用程序以及它們的開發環境。一種模式是根據您的開發環境 (例如生產、測試、測試和開發) 建立多個子系 OU，並在與不同應用程式相關的 OU 下使用個別的子 AWS 帳戶。另一個常見的模式是每個應用程式有個別的子系 OU，然後針對個別的開發環境使用個別的子 AWS 帳戶。確切的 OU 和帳戶結構取決於您的應用程式設計以及管理這些應用程式的團隊。請考慮您要強制執行的安全性控制項，不論它們是環境特定的還是應用程式特定的，因為在 OU 上將這些控制項實作為 SCP 會比較容易。如需組織以工作負載為導向的 OU 的進一步考量，請參閱 AWS 白皮書使用多個帳戶組織 AWS 環境的組織工作負載導向 OU 一節。
應用程式 VPC
應用程式帳戶中的虛擬私有雲端 (VPC) 需要輸入存取 (針對您建模的簡單 Web 服務) 和對外存取 (針對應用程式需求或 AWS 服務需求)。默認情況下，VPC 內的資源可以相互路由。有兩個私有子網路：一個用於託管 EC2 執行個體 (應用程式層)，另一個用於 Amazon Aurora (資料庫層)。不同層之間的網路分段 (例如應用程式層和資料庫層) 是透過 VPC 安全群組完成的，這些群組會限制執行個體層級的流量。為了獲得恢復能力，工作負載跨越兩個或更多可用區域，並在每個區域使用兩個子網路。
設計考量
-
您可以使用流量鏡像從 EC2 執行個體的 elastic network interface 複製網路流量。然後，您可以將流量傳送至 out-of-band 安全性和監控設備，以進行內容檢查、威脅監控或疑難排解。例如，您可能想要監視離開 VPC 的流量或來源位於 VPC 之外的流量。在這種情況下，您將鏡像 VPC 中傳遞的流量除外的所有流量，並將其傳送到單一監控設備。Amazon VPC 流程日誌不會擷取鏡像流量；它們通常只會從封包標頭擷取資訊。流量鏡像可讓您分析實際的流量內容，包括承載，從而提供更深入的網路流量洞察。僅針對 EC2 執行個體的 elastic network interface 啟用流量鏡像，這些介面可能在敏感工作負載中運作，或者您預期在發生問題時需要詳細診斷的 EC2 執行個體。
VPC 端點
VPC 端點提供了另一層的安全控制以及可擴展性和可靠性。使用這些功能將您的應用程式 VPC 連接到其他 AWS 服務。在應用程式帳戶中，AWS SRA 針對 AWS KMS、AWS Systems Manager 和 Amazon S3 採用 VPC 端點。) 端點是虛擬裝置。這些端點是水平擴展、冗餘且高度可用的 VPC 元件。其可讓您 VPC 中的執行個體與服務進行通訊，而不會強加網路流量的可用性風險或頻寬限制。您可以使用 VPC 端點將 VPC 私有連接到由 AWS 提供支援的 AWS 服務和 VPC 端點服務， PrivateLink 而無需網際網路閘道、NAT 裝置、VPN 連線或 AWS Direct Connect 連線。VPC 中的執行個體不需要公有 IP 地址即可與其他 AWS 服務通訊。您的 VPC 和其他 AWS 服務之間的流量不會離開 Amazon 網路。
使用 VPC 端點的另一個好處是啟用端點策略的配置。當您建立或修改端點時，VPC 端點政策是您連接至端點的 IAM 資源政策。如果您在建立端點時未附加 IAM 政策，AWS 會為您附加允許完整存取服務的預設 IAM 政策。端點政策不會覆寫或取代 IAM 政策或服務特定政策 (例如 S3 儲存貯體政策)。這是個別的 IAM 政策，用於控制從端點到指定服務的存取。透過這種方式，它增加了另一層控制，讓 AWS 主體可以與資源或服務通訊。
Amazon EC2
組成我們應用程式的 Amazon EC2
使用不同的 VPC (做為帳戶界限的子集)，依工作負載區段隔離基礎架構。使用子網來隔離單一 VPC 內的應用程式層 (例如，Web、應用程式及資料庫)。如果不應該從網際網路直接存取，則針對您的執行個體使用私有子網。若要在不使用網際網路閘道的情況下從私有子網路呼叫 Amazon EC2 API，請使用 AWS PrivateLink。使用安全性群組限制執行個體的存取權。使用 VPC 流程日誌監控到達您執行個體的流量。使用 AWS Systems Manager 的工作階段管理員從遠端存取執行個體，而不是開啟傳入 SSH 連接埠和管理安全殼層金鑰。針對作業系統和資料使用個別的 Elastic Block Store (Amazon EBS) 磁碟區。您可以設定 AWS 帳戶，對您建立的新 EBS 磁碟區和快照複本強制加密。
實作範例
AWS SRA 程式碼程式庫
Application Load Balancer
應用程式負載平衡器
AWS Certificate Manager (ACM) 會與應用程式負載平衡器原生整合，而 AWS SRA 則使用 ACM 來產生和管理必要的 X.509 (TLS 伺服器) 公有憑證。您可以透過應用程式負載平衡器安全性原則，針對前端連線強制執行 TLS 1.2 和強式加密。如需詳細資訊，請參閱 Elastic Load Balancing 說明文件。
設計考量
-
對於常見案例，例如在應用程式負載平衡器上需要私有 TLS 憑證的嚴格內部應用程式，您可以使用此帳戶內的 ACM 從中AWS 私有 CA產生私有憑證。在 AWS SRA 中，ACM 根私有 CA 託管在安全工具帳戶中，可與整個 AWS 組織或與特定 AWS 帳戶共用，以發行最終實體憑證，如安全工具帳戶部分先前所述。
-
對於公用憑證，您可以使用 ACM 來產生這些憑證並加以管理，包括自動循環。或者，您可以使用 SSL/TLS 工具建立憑證簽署要求 (CSR) 來產生自己的憑證，取得憑證授權單位 (CA) 簽署的 CSR 以產生憑證，然後將憑證匯入 ACM 或將憑證上傳至 IAM 以搭配應用程式負載平衡器使用。如果您將憑證匯入 ACM，則必須監控憑證的到期日，並在憑證到期前進行更新。
-
如需額外的防禦層，您可以部署 AWS WAF 政策來保護 Application Load Balancer。擁有邊緣原則、應用程式原則，甚至私有或內部原則強制執行層可增加通訊要求的可見度，並提供統一的原則強制執行。如需詳細資訊，請參閱部落格文章使用 AWS AWS WAF 的 AWS 受管規則深入部署防禦
。
AWS 私有 CA
AWS Private Certificate Authority(AWS 私有 CA) 用於應用程式帳戶，以產生與應用程式 Application Load Balancer 搭配使用的私有憑證。應用程式負載平衡器是透過 TLS 提供安全內容的常見案例。這需要在 Application Load Balancer 上安裝 TLS 憑證。對於嚴格內部的應用程式，私有 TLS 憑證可以提供安全通道。
在 AWS SRA 中，託管AWS 私有 CA在安全工具帳戶中，並使用 AWS RAM 與應用程式帳戶共用。這可讓應用程式帳戶中的開發人員從共用的私有 CA 要求憑證。跨組織或 AWS 帳戶共用 CA 有助於降低在所有 AWS 帳戶中建立和管理重複 CA 的成本和複雜性。當您使用 ACM 從共用 CA 發行私有憑證時，憑證會在本機要求的帳戶中產生，而 ACM 則提供完整的生命週期管理和更新。
Amazon Inspector
AWS SRA 使用 Amazon Inspector
Amazon Inspector 會放在應用程式帳戶中，因為它為此帳戶中的 EC2 執行個體提供弱點管理服務。此外，Amazon Inspector 還會報告往返 EC2 執行個體的不需要的網路路徑。
會員帳戶中的 Amazon Inspector 是由委派的管理員帳戶集中管理。在 AWS SRA 中，安全工具帳戶是委派的管理員帳戶。委派的系統管理員帳戶可以管理發現項目資料和組織成員的特定設定。這包括檢視所有成員帳戶的彙總發現項目詳細資料、啟用或停用成員帳戶的掃描，以及檢閱 AWS 組織內掃描的資源。
設計考量
-
您可以使用 AWS Systems Manager 的一項功能修補程式管理員來觸發隨需修補，以修復 Amazon Inspector 零時差或其他重大安全漏洞。修補程式管理員可協助您修補這些弱點，而不必等待正常的修補排程。修復是使用 Systems Manager 自動化手冊來執行。如需詳細資訊，請參閱使用 Amazon Inspector 和 AWS 系統管理員在 AWS 中自動化弱點管理和修復的兩個部落格系
列。
亞馬遜 Systems Manager
AWS Systems Manager
除了這些一般自動化功能之外，Systems Manager 還支援許多預防性、偵測和回應式安全性功能。AWS Systems Manager 代理程式 (SSM 代理程式) 是 Amazon 軟體，可在 EC2 執行個體、現場部署伺服器或虛擬機器 (VM) 上安裝和設定。SSM Agent 讓 Systems Manager 能夠更新、管理和設定這些資源。Systems Manager 會掃描這些受管理的執行個體，並針對修補程式、組態和自訂原則中偵測到的任何違規報告 (或採取修正措施)，協助您維護安全性與合規性。
AWS SRA 使用工作階段管理員 (Systems Manager 的一項功能) 來提供互動式、以瀏覽器為基礎的殼層和 CLI 體驗。這可提供安全且可稽核的執行個體管理，而不需要開啟輸入連接埠、維護防禦主機或管理安全殼層金鑰。AWS SRA 使用修補程式管理員 (Systems Manager 的一項功能) 將修補程式套用至作業系統和應用程式的 EC2 執行個體。
AWS SRA 也使用 Systems Manager 的自動化功能，簡化 Amazon EC2 執行個體和其他 AWS 資源的常見維護和部署任務。Automation 可以簡化一般 IT 任務，例如變更一個或多個節點的狀態 (使用核准自動化) 和根據排程管理節點狀態。Systems Manager 包含的功能可協助您使用標籤以大型執行個體群組為目標，而速度控制可協助您根據您定義的限制推出變更。自動化提供一鍵式自動化功能，可簡化複雜的任務，例如建立黃金 Amazon 機器映像 (AMI) 和復原無法存取的 EC2 執行個體。此外，您可以將 IAM 角色授予特定 Runbook 的存取權，以執行特定功能，而無需直接授予這些角色的許可，藉此增強作業安全性。例如，如果您希望 IAM 角色具有在修補程式更新後重新啟動特定 EC2 執行個體的許可，但不想直接將權限授予該角色，則可以改為建立自動化執行手冊，並授予僅執行 runbook 的角色許可。
設計考量
-
Systems Manager 依賴 EC2 執行個體中繼資料才能正確運作。Systems Manager 可以使用執行個體中繼資料服務 (IMDSv1 和 IMDSv2) 的版本 1 或第 2 版來存取執行個體中繼資料。
-
SSM 代理必須與不同的 AWS 服務和資源，例如 Amazon EC2 消息，Systems Manager 和 Amazon S3 進行通信。若要進行此通訊，子網路需要輸出網際網路連線或佈建適當的 VPC 端點。AWS SRA 針對 SSM 代理程式使用 VPC 端點來建立通往各種 AWS 服務的私有網路路徑。
-
使用 Automation 可讓您與整個組織分享最佳實務。您可以在 Runbook 中建立資源管理的最佳實務，並在 AWS 區域和群組之間共用手冊。您也可以限制 Runbook 參數允許的值。對於這些使用案例，您可能必須在安全工具或共用服務等中央帳戶中建立自動化手冊，並與 AWS 組織的其他部分共用。常見使用案例包括集中實作修補和安全更新、修復 VPC 組態或 S3 儲存貯體政策上的漂移，以及大規模管理 EC2 執行個體的功能。如需實作詳細資訊，請參閱 Systems Manager 文件。
Amazon Aurora
在 AWS SRA 中，Amazon Aurora
設計考量
-
與許多資料庫服務一樣，Aurora 的安全性分為三個層級進行管理。若要控制誰可以在 Aurora 資料庫叢集和資料庫執行個體上執行 Amazon 關聯式資料庫服務 (Amazon RDS) 管理動作，請使用 IAM。若要控制哪些裝置和 EC2 執行個體可以為 VPC 中的 Aurora 資料庫叢集開啟叢集端點和資料庫執行個體連接埠的連線，請使用 VPC 安全群組。若要驗證 Aurora 資料庫叢集的登入和許可，您可以採用與使用 MySQL 或 PostgreSQL 獨立資料庫執行個體相同的方法，也可以針對 Aurora MySQL 相容版本使用 IAM 資料庫身份驗證。使用後一種方法，您可以使用 IAM 角色和身份驗證令牌向 Aurora MySQL 相容資料庫叢集進行驗證。
Amazon S3
Amazon S3
AWS KMS
AWS SRA 說明建議的金鑰管理分發模型，其中 KMS 金鑰與要加密的資源位於相同的 AWS 帳戶中。因此，除了包含在安全工具帳戶中之外，還會在應用程式帳戶中使用 AWS KMS。在應用程式帳戶中，AWS KMS 可用來管理應用程式資源專屬的金鑰。您可以使用金鑰原則將金鑰使用權限授與本機應用程式角色，以及限制金鑰託管人的管理和監視權限，以實作責任分離。
設計考量
-
在分散式模型中，應用程式團隊有 AWS KMS 金鑰管理責任。但是，您的中央安全團隊可以負責治理和監控重要的密碼編譯事件，例如：
-
KMS 金鑰中匯入的金鑰材料接近其過期日期。
-
KMS 金鑰中的金鑰材料會自動輪換。
-
已刪除 KMS 金鑰。
-
解密失敗率很高。
-
AWS CloudHSM
AWS CloudHSM
設計考量
-
如果您對 FIPS 140-2 級別 3 有一定的要求，您也可以選擇將 AWS KMS 設定為使用 CloudHSM 叢集做為自訂金鑰存放區，而不是使用原生 KMS 金鑰存放區。如此一來，您就能從 AWS KMS 和 AWS 服務之間的整合中受益，這些服務會加密您的資料，同時負責保護 KMS 金鑰的 HSM。這將您控制的單租戶 HSM 與 AWS KMS 的易用性和整合結合在一起。若要管理 CloudHSM 基礎架構，您必須採用公開金鑰基礎架構 (PKI)，並擁有一個具有管理 HSM 經驗的團隊。
AWS Secrets Manager
AWS Secrets Manager
透過 Secrets Manager，您可以使用精細的 IAM 政策和以資源為基礎的政策來管理密碼的存取。您可以使用 AWS KMS 管理的加密金鑰加密密鑰，以協助保護機密安全。Secrets Manager 也與 AWS 記錄和監控服務整合，以進行集中稽核。
Secrets Manager 使用包絡加密搭配 AWS KMS 金鑰和資料金鑰來保護每個機密值。建立密碼時，您可以在 AWS 帳戶和區域中選擇任何對稱的客戶受管金鑰，也可以使用 Secrets Manager 的 AWS 受管金鑰。
最佳做法是，您可以監視密碼以記錄任何變更。這有助於您確保可以調查任何意外的使用或變更。不需要的變更可以回復。Secrets Manager 目前支援兩種 AWS 服務，可讓您監控組織和活動：AWS CloudTrail 和 AWS Config。 CloudTrail 會將 Secrets Manager 的所有 API 呼叫擷取為事件，包括來自 Secrets Manager 主控台的呼叫，以及從密碼管理員 API 呼叫的呼叫。此外，還可 CloudTrail 擷取其他相關 (非 API) 事件，這些事件可能對您的 AWS 帳戶造成安全或合規影響，或可協助您解決操作問題。這些包括某些機密輪替事件和秘密版本的刪除。AWS Config 可以透過追蹤和監控秘密 Secrets Manager 中的機密變更來提供偵測控制。這些變更包括機密的說明、輪替組態、標籤，以及與其他 AWS 來源的關係，例如 KMS 加密金鑰或用於秘密輪替的 AWS Lambda 函數。您也可以設定 Amazon EventBridge，從 AWS Config 接收組態和合規變更通知，以路由特定機密事件以進行通知或修復動作。
在 AWS SRA 中，Secrets Manager 位於應用程式帳戶中，可支援本機應用程式使用案例，並管理接近其使用情況的機密。在此，執行個體設定檔會附加至應用程式帳戶中的 EC2 執行個體。然後可以在 Secrets Manager 中設定個別的密碼，以允許該執行個體設定檔擷取密碼，例如加入適當的 Active Directory 或 LDAP 網域，以及存取 Aurora 資料庫。秘密管理員與 Amazon RDS 整合，以便在您建立、修改或還原 Amazon RDS 資料庫執行個體或異地同步備份資料庫叢集時管理使用者登入資料。這可協助您管理金鑰的建立和輪換，並以程式設計 API 呼叫 Secrets Manager 取代程式碼中的硬式編碼認證。
設計考量
-
一般而言，請在最接近密碼使用位置的帳戶中設定和管理 Secret Manager。這種方法充分利用當地使用案例的知識，並為應用程式開發團隊提供速度和靈活性。對於可能有額外控制層可能適當的嚴格控制資訊，Secrets Manager 可以在安全性工具帳戶中集中管理機密。
Amazon Cognito
Amazon Cognito
Amazon Cognito 為使用者註冊和登入提供內建且可自訂的使用者介面。您可以使用適用於 Amazon Cognito 的 Android、iOS 和 JavaScript 開發套件，將使用者註冊和登入頁面新增至您的應用程式。Amazon Cognito Sync 是一種 AWS 服務和用戶端程式庫，可讓應用程式相關的使用者資料進行跨裝置同步。
Amazon Cognito 支援多因素身份驗證和靜態資料和傳輸中資料的加密。Amazon Cognito 使用者集區提供進階安全功能，以協助保護對應用程式中帳戶的存取。這些進階安全性功能可提供風險型調適性驗證和防護，避免使用遭到入侵的認證。
設計考量
-
您可以建立 AWS Lambda 函數，然後在使用者集區操作期間觸發該函數，例如使用者註冊、確認和使用 AWS Lambda 觸發器登入 (身份驗證)。您可以新增驗證挑戰、遷移使用者，以及自訂驗證訊息。有關常見操作和使用者流程的資訊，請參閱 Amazon Cognito 文件。亞馬遜認知同步調用 Lambda 函數。
-
您可以使用 Amazon Cognito 使用者集區來保護小型多租用戶應用程式的安全。多租戶設計的常見使用案例是執行工作負載，以支援測試多個版本的應用程式。多重租用戶設計對於使用不同資料集測試單一應用程式也很實用，可讓您充分利用叢集資源。但是，請確保租用戶數量和預期的數量與相關的 Amazon Cognito 服務配額保持一致。應用程式中的所有租用戶會共用這些配額。
Amazon Verified Permissions
Amazon 驗證許
您可以透過 API 將應用程式連線至服務，以授權使用者存取要求。針對每個授權要求，服務會擷取相關原則，並評估這些原則，以判斷是否允許使用者對資源採取動作 (例如使用者、角色、群組成員資格和屬性)。您可以設定和連接已驗證的許可，將政策管理和授權日誌傳送到 AWS CloudTrail。如果您使用 Amazon Cognito 做為身分識別存放區，您可以與已驗證的許可整合，並使用 Amazon Cognito 在應用程式中的授權決策中傳回的 ID 和存取權杖。您將 Amazon Cognito 權杖提供給已驗證的許可，該權限會使用權杖包含的屬性來代表主體並識別主體的權利。如需有關此整合的詳細資訊，請參閱 AWS 部落格文章使用 Amazon 驗證許可和 Amazon Cognito 簡化精細授權
已驗證的權限可協助您定義原則型存取控制 (PBAC)。PBAC 是一種存取控制模型，它使用以原則表示的權限來決定誰可以存取應用程式中的哪些資源。PBAC 結合了基於角色的訪問控制（RBAC）和基於屬性的訪問控制（ABAC），從而產生了更強大和靈活的訪問控制模型。若要進一步了解 PBAC，以及如何使用已驗證許可設計授權模型，請參閱 AWS 部落格文章使用 Amazon 驗證許可開發應用程式中的政策型存取控制
在 AWS SRA 中，已驗證的許可位於應用程式帳戶中，透過與 Amazon Cognito 整合來支援應用程式的許可管理。
分層防禦
應用程式帳戶提供了說明 AWS 啟用的分層防禦主體的機會。考慮構成 AWS SRA 中代表的簡單範例應用程式核心的 EC2 執行個體的安全性，您可以看到 AWS 服務在分層防禦中協同運作的方式。此方法與 AWS 安全服務的結構檢視保持一致，如本指南稍早在 AWS 組織中套用安全服務一節所述。
-
最內層是 EC2 執行個體。如前所述，EC2 執行個體預設或選項包含許多原生安全功能。範例包括 IMDSv2、硝基系統
和亞馬遜 E BS 儲存加密。 -
第二層保護著重於 EC2 執行個體上執行的作業系統和軟體。Amazon Inspector
和 AWS Systems Manager 等服務可讓您對這些組態進行監控、報告和採取修正動作。Inspector 會監控軟體中的弱點，Systems Manager 會掃描受控執行個體的修補程式和組態狀態，然後回報並採取您 指定的任何修正措施，協助您維護安全性與合規性。 -
執行個體和在這些執行個體上執行的軟體都與您的 AWS 聯網基礎設施一起使用。除了使用 Amazon VPC 的安全功能之外，AWS SRA 還利用 VPC 端點在 VPC 和支援的 AWS 服務之間提供私有連線，並提供在網路邊界放置存取政策的機制。
-
EC2 執行個體、軟體、網路和 IAM 角色和資源的活動和組態由 AWS 帳戶為中心的服務 (例如 AWS Security Hub、亞馬遜、AWS、AWS Config GuardDuty CloudTrail、AWS IAM 存取分析器和 Amazon Macie) 進一步監控。
-
最後，除了應用程式帳戶之外，AWS RAM 還有助於控制要與其他帳戶共用的資源，而 IAM 服務控制政策可協助您在整個 AWS 組織中強制執行一致的許可。
