本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 實作和強制執行標記 在本節中，我們將介紹下列資源管理策略可用的工具：手動、基礎設施即程式碼 (IaC) 和持續整合/持續交付 (CI/CD)。這些方法的關鍵維度是部署頻率越來越頻繁。 ## 手動管理的資源 這些通常是屬於[採用基礎或遷移階段的](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-program-implementation/reviewing-frameworks.html)工作負載。通常，這些是使用傳統寫入程序建置的簡單主要靜態工作負載，或是**使用 AWS Application Migration Service 內部部署環境等工具遷移的工作負載。遷移工具，例如 Migration Hub 和 Application Migration Service，可以套用標籤作為遷移程序的一部分。不過，如果在原始遷移期間未套用標籤，或標記結構描述自那時起已變更，[標籤編輯器](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) ( 的功能 AWS 管理主控台) 可讓您使用各種搜尋條件搜尋資源，並大量新增、修改或刪除標籤。搜尋條件可以包含有或沒有特定標籤或值的資源。 AWS 資源標記 API 可讓您以程式設計方式執行這些函數。 隨著這些工作負載的現代化，會推出 Auto Scaling 群組等資源類型。這些資源類型可提高彈性並改善彈性。自動擴展群組會代表您管理 Amazon EC2 執行個體，不過，您可能仍希望 EC2 執行個體與手動建立的資源一致地加上標籤。[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html)提供指定 Auto Scaling 應套用至其建立之執行個體的標籤的方法。 手動管理工作負載的資源時，自動化資源標記會很有幫助。有各種可用的解決方案。其中一種方法是使用 AWS Config 規則，它可以檢查 `required_tags`，然後啟動 Lambda 函數來套用它們。本白皮書稍後 AWS Config 規則 會更詳細地說明 。 ## 基礎設施即程式碼 (IaC) 受管資源 AWS CloudFormation 提供常見的語言，用於佈建 AWS 環境中的所有基礎設施資源。CloudFormation 範本是以自動化方式建立 AWS 資源的 JSON 或 YAML 檔案。使用 CloudFormation 範本建立 AWS 資源時，您可以使用 CloudFormation Resource Tags 屬性，在建立時將標籤套用至支援的資源類型。使用 IaC 管理標籤和資源有助於確保一致性。 建立資源時 AWS CloudFormation，服務會自動將一組 AWS 定義的標籤套用至 AWS CloudFormation 範本建立的資源。這些時間為： ``` aws:cloudformation:stack-name aws:cloudformation:stack-id aws:cloudformation:logical-id ``` 您可以根據 AWS CloudFormation 堆疊輕鬆定義資源群組。這些 AWS 定義的標籤由堆疊建立的資源繼承。不過，對於 Auto Scaling 群組中的 Amazon EC2 執行個體，需要在 AWS CloudFormation 範本中 Auto Scaling 群組的定義中設定 [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html)。或者，如果您使用 [EC2 啟動範本](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html)搭配 Auto Scaling 群組，您可以在其定義中定義標籤。建議搭配 Auto Scaling 群組或 AWS 容器服務使用 [EC2 啟動範本](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html)。這些服務可協助確保 Amazon EC2 執行個體的一致標記，也支援[跨多個執行個體類型和購買選項的 Auto Scaling](https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/)，可改善彈性並最佳化運算成本。 [AWS CloudFormation 勾點](https://aws.amazon.com/blogs/mt/proactively-keep-resources-secure-and-compliant-with-aws-cloudformation-hooks/)為開發人員提供了一種方法，使其應用程式的關鍵層面與其組織的標準保持一致。勾點可設定為提供*警告*或*防止部署*。此功能最適合用於檢查範本中的金鑰組態元素，例如 Auto Scaling 群組是否設定為將客戶定義的標籤套用至其啟動的所有 Amazon EC2 執行個體，或確保所有 Amazon S3 儲存貯體都使用必要的加密設定建立。在這兩種情況下，此合規的評估都會在部署之前透過掛 AWS CloudFormation 鉤推送至部署程序的早期 。 AWS CloudFormation 提供偵測從範本佈建的資源 （請參閱[支援偏離偵測的資源](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-supported-resources.html)) 何時已修改，且資源不再符合其預期的範本組態的功能。這稱為*偏離*。如果您使用自動化將標籤套用至透過 IaC 管理的資源，則您正在修改它們，並引入偏離。使用 IaC 時，目前建議在 IaC 範本中管理任何標記需求、實作 AWS CloudFormation 勾點，以及發佈可供自動化使用的 AWS CloudFormation Guard 規則集。 ## CI/CD 管道受管資源 隨著工作負載的成熟度增加，可能會採用持續整合和持續部署 (CI/CD) 等技術。這些技術透過提高測試自動化，讓部署小型變更更頻繁，協助降低部署風險。偵測部署引入之非預期行為的可觀測性策略，可以在使用者影響最小的情況下自動復原部署。隨著您進入每天部署數十次的階段，追溯套用標籤不再實際。所有內容都必須以程式碼或組態、版本控制，並盡可能在部署到生產環境之前進行測試和評估。在合併[開發和操作 (DevOps) 模型](https://aws.amazon.com/devops/what-is-devops/)中，許多實務將操作考量事項視為程式碼，並在部署生命週期的早期進行驗證。 理想情況下，您希望儘早推送這些檢查 （如 AWS CloudFormation 勾點所示），以便您可以確信 AWS CloudFormation 範本在離開開發人員的機器之前符合您的政策。 [AWS CloudFormation Guard 2.0](https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-guard-2-0/) 提供撰寫預防性合規規則的方法，讓您使用 CloudFormation 定義任何內容。範本會根據開發環境中的規則進行驗證。顯然，此功能有一系列的應用程式，但在本白皮書中，我們將查看一些範例，以確保始終使用 [`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html)。 以下是 CloudFormation Guard 規則的範例： ``` let all_asgs = Resources.*[ Type == 'AWS::AutoScaling::AutoScalingGroup' ] rule tags_asg_automation_EnvironmentId when %all_asgs !empty { let required_tags = %all_asgs.Properties.Tags.*[ Key == 'example-inc:automation:EnvironmentId' ] %required_tags[*] { PropagateAtLaunch == 'true' Value IN ['Prod', 'Dev', 'Test', 'Sandbox'] <> } } rule tags_asg_costAllocation_CostCenter when %all_asgs !empty { let required_tags = %all_asgs.Properties.Tags.*[ Key == 'example-inc:cost-allocation:CostCenter' ] %required_tags[*] { PropagateAtLaunch == 'true' Value == /^123-/ <> } } ``` 在程式碼範例中，我們為類型為 的所有資源篩選範本`AutoScalingGroup`，然後有兩個規則： + **`tags_asg_automation_EnvironmentId`** - 檢查具有此索引鍵的標籤是否存在、在允許的值清單中具有值，且`PropagateAtLaunch`設定為 `true` + **`tags_asg_costAllocation_CostCenter`** - 檢查標籤是否存在於此索引鍵，其值開頭為定義的字首值，且`PropagateAtLaunch`設定為 `true` ## 強制執行 如前所述，**資源群組和標籤編輯器**提供識別資源無法滿足套用至組織 OUs 之標籤政策中定義的標記要求的方法。從組織成員帳戶內存取**資源群組和標籤編輯器**主控台工具，會顯示套用至該帳戶的政策，以及帳戶內不符合標籤政策需求的資源。如果從管理帳戶存取 （如果**標籤政策**已在 下的服務中*啟用存取* AWS Organizations)，則可以檢視[組織中所有連結帳戶的標籤政策合規性](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html)。 在標籤政策本身中，您可以針對特定資源類型啟用強制執行。在下列政策範例中，我們新增了強制執行，以便類型 `ec2:instance`和 的所有資源`ec2:volume`都必須符合政策。有一些已知的限制，例如資源上必須有標籤，才能由標籤政策評估。如需清單[，請參閱支援使用標籤政策強制執行的資源](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_supported-resources-enforcement.html)。 ### ExampleInc-Cost-Allocation.json 以下是報告和/或強制執行成本分配標籤的標籤政策範例： ``` { "tags": { "example-inc:cost-allocation:ApplicationId": { "tag_key": { "@@assign": "example-inc:cost-allocation:ApplicationId" }, "tag_value": { "@@assign": [ "DataLakeX", "RetailSiteX" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } }, "example-inc:cost-allocation:BusinessUnitId": { "tag_key": { "@@assign": "example-inc:cost-allocation:BusinessUnitId" }, "tag_value": { "@@assign": [ "Architecture", "DevOps", "FinanceDataLakeX" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } }, "example-inc:cost-allocation:CostCenter": { "tag_key": { "@@assign": "example-inc:cost-allocation:CostCenter" }, "tag_value": { "@@assign": [ "123-*" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } } } } ``` **AWS Config (`required_tag`)** AWS Config 是一項服務，可讓您評估、稽核和評估 AWS 資源的組態 （請參閱 [支援的資源類型 AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html))。在標記的情況下，我們可以使用 `required_tags`規則 （請參閱 [required\$1tags 支援的資源類型） 來識別缺少具有特定金鑰之標籤的資源](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)。從先前的範例中，我們可能會在所有 Amazon EC2 執行個體上測試金鑰是否存在。在金鑰不存在的情況下，執行個體會註冊為不合規。此 AWS CloudFormation 範本描述 AWS Config 規則，以測試資料表、Amazon S3 儲存貯體、Amazon EC2 執行個體和 Amazon EBS 磁碟區中描述的強制性金鑰是否存在。 ``` Resources: MandatoryTags: Type: AWS::Config::ConfigRule Properties: ConfigRuleName: ExampleIncMandatoryTags Description: These tags should be in place InputParameters: tag1Key: example-inc:cost-allocation:ApplicationId tag2Key: example-inc:cost-allocation:BusinessUnitId tag3Key: example-inc:cost-allocation:CostCenter tag4Key: example-inc:automation:EnvironmentId Scope: ComplianceResourceTypes: - "AWS::S3::Bucket" - "AWS::EC2::Instance" - "AWS::EC2::Volume" Source: Owner: AWS SourceIdentifier: REQUIRED_TAGS ``` 對於手動管理資源的環境，可以增強 AWS Config 規則，以透過 AWS Lambda 函數使用自動修復自動將遺失的標籤索引鍵新增至資源。雖然這適用於靜態工作負載，但在您開始透過 IaC 和部署管道管理 資源時，其效率會逐漸降低。 **AWS Organizations – 服務控制政策 SCPs)** 是一種組織政策，可用來管理組織中的許可。SCPs可讓您集中控制組織或組織單位 (OU) 中所有帳戶的可用許可上限。SCPs只會影響由屬於組織一部分的帳戶管理的使用者和角色。雖然它們不會直接影響資源，但會限制使用者和角色的許可，其中包含標記動作的許可。在標記方面，除了標籤政策可以提供的標籤之外，SCPs 還可以為標籤強制執行提供額外的精細程度。 在下列範例中，政策會拒絕不存在`example-inc:cost-allocation:CostCenter`標籤的`ec2:RunInstances`請求。 以下是拒絕 SCP： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyRunInstanceWithNoCostCenterTag", "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": [ "arn:aws:ec2:*:*:instance/*" ], "Condition": { "Null": { "aws:RequestTag/example-inc:cost-allocation:CostCenter": "true" } } } ] } ``` ------ 無法依設計擷取套用至連結帳戶的有效服務控制政策。當您使用 SCPs 強制執行標記時，開發人員需要提供文件，以確保其資源符合已套用至其帳戶的政策。在其帳戶中提供 CloudTrail 事件的唯讀存取權，可以支援開發人員在其資源不合規時進行偵錯任務。