翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# データセキュリティとリスク管理
<a name="data-security-and-risk-management"></a>

 AWS 環境内では、コンプライアンス要件とセキュリティ要件が異なるアカウントが存在する可能性があります。例えば、開発者用サンドボックスと、支払い処理などの規制の厳しいワークロード用の本番環境をホストするアカウントがあるとします。それらを異なるアカウントに分離して、[個別のセキュリティ制御を適用し](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#apply-distinct-security-controls-by-environment)、[機密データへのアクセスを制限すれば](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#constrain-access-to-sensitive-data)、規制対象のワークロードの監査範囲を狭めることができます。

 すべてのワークロードに同じ標準を採用することは、問題の発生につながるおそれがあります。多くの制御機能が環境全体に等しく適用されていますが、特定の制御機能の枠組みを満たす必要のないアカウントや、個人を特定できるデータが存在しないアカウント (開発者用サンドボックスやワークロード開発アカウントなど) には、その存在が過剰な制御や無関係な制御もあります。そのような状況は、一般に、優先順位を付けて何もしないでクローズしなければならないセキュリティ上の誤検出につながるため、本来の調査すべき発見に費やされる労力が無駄に奪われます。

 *表 11 — データセキュリティタグとリスク管理タグの例* 


|  ユースケース  |  タグキー  |  根拠  |  値の例  | 
| --- | --- | --- | --- | 
| インシデント管理  | example-inc:incident- management:escalationlog |  サポートチームがインシデントを記録するために使用しているシステム  |  jira, servicenow, zendesk  | 
| インシデント管理  | example-inc:incident- management:escalationpath |  エスカレーションの経路  | ops-center, dev-ops, app-team  | 
| データ分類  | example-inc:data:classification |  コンプライアンスとガバナンスのためのデータの分類  | Public, Private, Confidential, Restricted  | 
| コンプライアンス  | example-inc:compliance:framework |  ワークロードが対象となるコンプライアンスフレームワークを特定します。 | PCI-DSS, HIPAA  | 

 AWS 環境全体で異なるコントロールを手動で管理すると、時間がかかり、エラーが発生しやすくなります。次のステップでは、適切なセキュリティ制御の導入を自動化し、そのアカウントの分類に基づいてリソースの検査を設定します。アカウントとその中のリソースにタグを適用すると、制御の導入を自動化し、ワークロードに合わせて適切に設定できます。

**例: **

 ワークロードには、値 `Private` のタグ `example-inc:data:classification` が付いた Amazon S3 バケットが含まれます。セキュリティツールの自動化は`s3-bucket-public-read-prohibited`、Amazon S3 バケットのブロックパブリックアクセス設定、バケットポリシー、バケットアクセスコントロールリスト (ACL) をチェックし、バケットの設定がデータ分類に適していることを確認する AWS Config ルール をデプロイします。バケットの内容が分類と一致していることを確認するために、[Amazon Macie は個人識別情報 (PII) をチェックするように設定できます](https://aws.amazon.com/about-aws/whats-new/2021/05/amazon-macie-supports-criteria-based-bucket-selection-sensitive-data-discovery-jobs/)。ブログ「[Amazon Macie を使用して S3 バケットデータ分類を検証する](https://aws.amazon.com/blogs/architecture/using-amazon-macie-to-validate-s3-bucket-data-classification/)」では、このパターンについて詳しく説明しています。

 保険や医療などの特定の規制環境では、必須のデータ保持ポリシーが適用される場合があります。タグを使用したデータ保持と Amazon S3 ライフサイクルポリシーを組み合わせると、オブジェクトを別のストレージ階層で調べるための効果的で簡単な方法が得られます。Amazon S3 ライフサイクルルールで、必須の保持期間の終了後にデータを削除するオブジェクトを期限切れにすることもできます。このプロセスの詳細なガイドについては、「[Amazon S3 ライフサイクルでオブジェクトタグを使用してデータライフサイクルを簡素化する](https://aws.amazon.com/blogs/storage/simplify-your-data-lifecycle-by-using-object-tags-with-amazon-s3-lifecycle/)」を参照してください。

 さらに、セキュリティ上の検出結果の優先順位付けや対処を行う際に、調査担当者にはタグでリスクの見極めに役立つ重要なコンテキストが得られ、適切なチームを関わらせて調査結果や軽減に役立てることができます。