データセキュリティとリスク管理

AWS 環境内には、コンプライアンス要件やセキュリティ要件が異なるアカウントが存在する可能性があります。例えば、開発者用サンドボックスと、支払い処理などの規制の厳しいワークロード用の本番環境をホストするアカウントがあるとします。それらを異なるアカウントに分離して、個別のセキュリティ制御を適用し、機密データへのアクセスを制限すれば、規制対象のワークロードの監査範囲を狭めることができます。

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

表 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 バケットが含まれます。このセキュリティツールの自動化では AWS Config ルール s3-bucket-public-read-prohibited がデプロイされます。このルールでは、Amazon S3 バケットの ブロックパブリックアクセス設定、バケットポリシー、バケットアクセスコントロールリスト (ACL) が確認され、バケットの構成がデータ分類に対して適切かどうかを確認できます。バケットの内容が分類と一致していることを確認するために、Amazon Macie は個人識別情報 (PII) をチェックするように設定できます。ブログ「Amazon Macie を使用して S3 バケットデータ分類を検証する」では、このパターンについて詳しく説明しています。

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

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