Data Classification・Retention・規制要件を見直す

ゴール

既存環境について、

• データの機密性とデータ分類を区別する
• 分類ごとに必要な保護を整理する
• 保持要件と現在のデータ管理を照合する
• 自動削除と削除・上書き防止を区別する
• データ所在地の要件と実際のコピー先を確認する
• 暗号化がデータ分類・規制要件と一致しているか確認する
• Amazon Macieを機密データの発見へ利用する
• AWS Audit ManagerとAWS Artifactの役割を区別する
• 規制要件から必要な証拠やAWS側の資料まで確認する

ことを目指します。

1. データの機密性とデータ分類を分ける

データの機密性とデータ分類は関連しますが、同じ意味ではありません。

例えば、

氏名
住所
生年月日

などが含まれることが分かっても、その情報を組織内でどの分類へ割り当て、

誰がアクセスできるか
どの暗号化が必要か
何年間保持するか
保持中の削除を許可するか
どの地域へ保存できるか

を決めるのは、組織側の分類ポリシーです。

2. 現在の保存場所から分類を推測しない

既存環境では、

このS3バケットは社内用
だから中身もすべて社内データ

といった前提が長期間残っていることがあります。

しかし実際には、

当初
一般的な業務ファイルだけ

↓

数年間運用

↓

個人情報
取引情報
サポートログ
エクスポートデータ

のように用途が変化する可能性があります。

そのため、リソース名や現在の設定ではなく、実際に保存されているデータを確認することが重要です。

3. Amazon MacieでS3内の機密データを把握する

Amazon Macieは、Amazon S3に保存されているデータについて機密データの検出を支援します。

例えば、

多数のAWSアカウント
+
多数のS3バケット
+
どこに機密データがあるか把握できていない

という既存環境では、

Amazon Macie
↓
S3データを分析
↓
機密データの存在を把握
↓
分類・保護方針の見直し

につなげられます。

ここで重要なのは、Amazon Macieが組織の最終的なデータ分類ポリシーそのものを決めるわけではないことです。

Macieによる検出結果は、

どこに機密データが存在する可能性があるか

を把握するための証拠として使います。

そのうえで、

組織の分類基準
規制要件
業務上の重要性

と照合します。

また、MacieをすべてのAWSデータストアを横断する汎用データ分類サービスとして扱いません。中心となる対象はAmazon S3です。

4. データ分類から必要な保護へつなげる

データ分類は、ラベルを付けること自体が目的ではありません。

データ
↓
分類
↓
必要な保護

へつなげます。

例えば組織が、

公開
社内
機密
制限付き

という分類を使用している場合、分類ごとに、

アクセス条件
暗号化
保持期間
削除・変更の可否
保存可能な場所
監査要件
削除条件

などが変わる可能性があります。

したがって、既存環境では、

現在の分類
↓
必要な制御
↓
実際の設定

を比較します。

5. 暗号化は「有効か」だけで評価しない

保管中・転送中の暗号化方法そのものは既習です。

ここで見るのは、現在の暗号化がデータ分類や規制要件を満たしているかです。

例えば、

一般データ
→ AWSサービス標準の暗号化で要件を満たす

制限付きデータ
→ 組織が管理するキーが必要

という社内要件があるなら、単に、

暗号化
有効

を確認するだけでは不十分です。

データ分類
+
規制 / 社内要件
↓
必要な暗号化条件
↓
現在の実装

を比較します。

KMSキーやTLSの具体的な設計をやり直すのではなく、要求されている保護と現在状態の不一致を探すことが中心です。

6. 保持は「できるだけ長く保存」ではない

保持要件では、

長く保存するほど安全

とは限りません。

データによっては、

最低7年間保持

という要件もあれば、

利用目的終了後は削除

という要件もあります。

したがって、

必要保持期間
↓
実際の保持期間

を比較します。

短すぎる場合

要件
7年保持

現在
3年で削除

なら、必要な証拠や記録を早く削除する可能性があります。

長すぎる場合

削除すべきデータを必要以上に残していれば、

不要なデータ
+
不要な保有期間
↓
不要なリスク

につながる場合があります。

保持期間は、業務・法令・契約・プライバシー要件から決める必要があります。

7. 保持期間と「削除・上書き防止」を分ける

「7年間保持する」という要件でも、求められている内容を確認します。

例えば、

7年より前に
自動削除しなければよい

という要件と、

7年間は
削除・上書きを
防止する必要がある

という要件では、必要な制御が異なります。

自動削除時期を制御する

Amazon S3のライフサイクルでは、

いつ別のストレージクラスへ移行するか
いつ期限切れとして削除するか

を管理できます。

保持期間中の削除・上書きを防止する

規制などでWORM形式の保持が要求される場合は、Amazon S3 Object Lockなどの保持制御を評価します。

S3 Object Lockでは、要求される保護レベルによって保持モードを区別します。

ガバナンスモード
↓
通常の利用者による削除・上書きを防止
↓
特別な権限を持つ利用者は
保持設定をバイパスできる

コンプライアンスモード
↓
保持期間中は
rootユーザーを含めて
保護対象バージョンを削除・上書きできない
↓
保持期間の短縮もできない

したがって、

管理権限を持つ利用者でも
保持期間中に削除できないことが必要

という規制要件なら、コンプライアンスモードが決定打になります。

整理すると、

いつ削除するか
→ ライフサイクル

保持期間中に
削除・上書きを防ぐ必要があるか
→ Object Lock

特別な権限による
バイパスを許容するか
→ ガバナンスモード / コンプライアンスモード

を分けて判断します。

8. データ保持とバックアップ保持を混同しない

同じ「保持」という言葉でも責任が異なります。

データ保持
→ そのデータ自体を
   どの期間・条件で保持するか

バックアップ保持
→ 復旧のためのコピーを
   どの期間残すか

です。

例えば、

業務データを7年間保持

という要件があるからといって、

7年間分のすべてのバックアップを保持

と自動的に決まるわけではありません。

逆に、

バックアップがあるから
本体データの保持要件を満たす

とも限りません。

ここでは、復旧設計ではなくデータそのものの保持要件を扱います。

9. 保持要件をライフサイクルへ反映する

保持要件が決まったら、実際のライフサイクルと一致しているか確認します。

例えばAmazon S3では、

作成
↓
利用
↓
必要に応じてアーカイブ
↓
保持期限
↓
削除

という流れをライフサイクルルールへ反映できます。

重要なのは、

ライフサイクルを設定している

ことではなく、

必要な保持・削除条件と
ライフサイクルが矛盾していない

ことです。

例えば、

規制
7年間はデータを残す

S3 ライフサイクル
3年後に期限切れ

なら不一致です。

一方で、

7年間は削除・上書き禁止

まで求められている場合は、ライフサイクルを7年後に設定するだけでは、その保持要件を完成できません。

保持中の保護
+
保持終了後の削除

を別々に確認します。

10. データ所在地はすべてのコピーを見る

規制や契約によって、

特定の国
特定の地域
指定されたAWSリージョン

だけでデータを扱う必要がある場合があります。

ここで確認するのはプライマリだけではありません。

例えば、

プライマリデータ
東京

レプリカ
シンガポール

分析用エクスポート
米国

バックアップコピー
別リージョン

という構成なら、

メインデータが東京にある

だけでは所在地要件を判断できません。

確認対象は、

保存先
複製先
エクスポート先
処理先

です。

11. データ所在地と暗号化は別要件

次の2つは同じではありません。

暗号化されている

と、

許可された地域に保存されている

です。

例えば、

強力に暗号化
+
許可されていないリージョンへ複製

していれば、暗号化要件は満たしていても、所在地要件を満たしているとは限りません。

逆に、

許可されたリージョンだけを使用

していても、必要な暗号化が欠けていれば別の不備があります。

データ所在地
暗号化
アクセス制御
保持

は、それぞれ必要な条件として確認します。

12. 規制要件はAWSサービス名へ直接変換しない

例えば、

PCI DSS対象
HIPAA対象
個人情報を扱う

という情報だけから、

このサービスを使えば準拠

とは判断しません。

まず、

どのデータが対象か
↓
何を要求されているか
↓
現在の制御はどうなっているか
↓
何が不足しているか

を確認します。

また、AWS側のコンプライアンスと、利用者側のコンプライアンスは同じではありません。

AWSが特定の認証を取得していることだけで、利用者側の設定や運用まで自動的に準拠するわけではありません。

13. AWS Audit Managerは「自社側の証拠」を整理する

規制や監査では、

暗号化しているはず
アクセス制限しているはず

ではなく、

その制御が実際に動いていることを示す証拠

が必要になる場合があります。

AWS Audit Managerでは、評価の対象となる制御について、AWS環境から証拠を継続的に収集・整理できます。

概念的には、

規制 / 監査要件
↓
評価する制御
↓
AWS環境の証拠
↓
レビュー

という役割です。

例えば証拠の元には、

AWS Config
AWS Security Hub CSPM
AWS CloudTrail
AWS API

などがあります。

重要なのは、AWS Audit Managerが法律への準拠を自動的に保証するわけではないことです。

監査を支援するための証拠収集・評価を効率化します。

14. AWS ArtifactはAWS側のレポートや契約を確認する

AWS Artifactは、AWSのセキュリティ・コンプライアンス文書や契約を確認するときに使用します。

例えば、

SOCレポート
ISO関連文書
PCI関連文書
AWSとの契約

などです。

役割を整理すると、

AWS ArtifactからAWS側の監査資料を取得しただけで、

自社のAWS環境も準拠している

とは判断しません。

15. Macie・Audit Manager・Artifactを混同しない

3サービスは、どれもセキュリティ・コンプライアンスに関係しますが責任が異なります。

Amazon Macie
↓
S3データ内の
機密データ発見

AWS Audit Manager（設定済み環境）
↓
自社の制御に関する
監査証拠の収集・整理

AWS Config Conformance Packs（新規設計の候補）
↓
Config Rulesをまとめて展開し
リソースの準拠状態を監視

AWS Artifact
↓
AWS側の
コンプライアンス資料・契約

試験では、

何を知りたいのか
どの証拠が必要なのか

を確認します。

16. 既存環境では「要件 → データ → 設定」の順で見直す

例えば既存環境で、

すべて7年保持

すべて同じ暗号化

すべて東京リージョン

という統一ルールがあっても、それが正しいとは限りません。

必要なのは、

規制・業務要件
↓
対象データを特定
↓
データ分類
↓
保持
保持中の削除防止
暗号化
データ所在地
ライフサイクル
↓
現在設定と比較
↓
不一致を修正

という流れです。

現在の設定を正解として要件を合わせるのではなく、要件を基準に現在設定を評価します。

17. 混同しやすいポイント

18. SAP-C02での判断手順

1. 対象データは何か
        ↓
2. 機密性・分類は何か
        ↓
3. 適用される業務 / 規制要件は何か
        ↓
4. 必要条件を整理

   保持期間
   保持中の削除・上書き防止
   必要な保持モード
   暗号化
   データ所在地
   ライフサイクル

        ↓
5. 実環境と比較
        ↓
6. 不明なS3データは
   Amazon Macieで把握
        ↓
7. 監査・準拠状態の管理が必要なら
   ├─ Audit Manager設定済み環境
   │   → AWS Audit Managerの継続利用を評価
   └─ 新規アカウント / 新規設計
       → AWS Config Conformance Packs等を要件に応じて評価
        ↓
8. AWS側のレポート / 契約が必要なら
   AWS Artifact
        ↓
9. 不一致を改善

まとめ

データ保護を見直すときは、

現在の保存設定
↓
必要要件を推測

ではなく、

データの機密性
↓
データ分類
↓
規制・業務要件
↓
保持期間
保持中の削除・上書き防止
暗号化
データ所在地
ライフサイクル
↓
現在状態と比較

の順で考えます。

特に保持では、

いつ自動削除するか
→ ライフサイクル

保持期間中に
削除・上書きを防止する必要があるか
→ Object Lock

特別な権限による
保持のバイパスを許容するか
→ ガバナンスモード / コンプライアンスモード

を区別します。

サービスの役割も分けます。

Amazon Macie
→ S3内の機密データを発見

AWS Audit Manager（設定済み環境）
→ 自社環境の監査証拠を収集・整理

AWS Config Conformance Packs（新規設計の候補）
→ Config Rulesをまとめて展開し準拠状態を監視

AWS Artifact
→ AWS側のコンプライアンス資料・契約

特に、

データ分類
≠
Macieによる自動決定

保持
≠
バックアップ保持

ライフサイクル
≠
削除・上書き防止

暗号化
≠
データ所在地

AWS側のコンプライアンス
≠
利用者側のコンプライアンス

を混同しないことが重要です。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional (SAP-C02) 試験ガイド — Task 3.2
• AWS — データ分類
• Amazon Macie — 機密データの検出
• Amazon S3 — オブジェクトのライフサイクル管理
• Amazon S3 — S3 Object Lockによるオブジェクトのロック
• AWS Audit Manager — 証拠収集
• AWS Artifact — セキュリティおよびコンプライアンス文書 / 契約
• AWS — データプライバシー
• AWS Audit Manager — availability change / AWS Config Conformance Packsへの移行検討
• AWS Config — Conformance Packs