はじめに：PII検出、なぜ自動化が必要か？
金融、保険、医療、政府機関などの規制産業では、顧客の個人情報（PII）を扱うことが日常的です。氏名、住所、社会保障番号などの標準PIIから、ポリシー番号、会員ID、医療記録番号などのドメイン固有識別子まで、さまざまな形態の機密データがファイルとして流入します。
問題は、手動分類では絶対にスケールしないことです。GDPR、HIPAA、CCPA、PCI DSSなどの規制は、PIIがどこにあるか、誰がアクセスできるか、どのように保護されるかを明確に文書化することを要求します。Amazon Macieが標準提供するマネージドデータ識別子だけでは不十分なケースも多いです。組織固有のデータ形式（例：特定形式の保険証券番号）は、標準の検出エンジンが認識しないためです。
この記事では、Amazon S3にファイルが到着した瞬間にPIIを自動検出するイベント駆動パイプラインの構築方法をステップバイステップで解説します。Macieの組み込み識別子に加えて、カスタムデータ識別子を組み合わせ、組織固有の機密情報も見逃さないことがポイントです。Amazon MacieとStep Functionsを活用した公式ガイドをベースに、実務適用の観点で再構成しました。
ソリューションアーキテクチャ：3バケットパターンの力
このパイプラインはイベント駆動アーキテクチャを採用しています。ファイルがS3にアップロードされるとEventBridgeがそれを検知し、Step Functionsワークフローをトリガーします。Step FunctionsはMacie分類ジョブをオーケストレーションし、レポートを生成し、高リスク検出時にSNSで通知します。
主要コンポーネント
| サービス | 役割 |
|---|---|
| Amazon S3 | raw、staged、scannedの3バケットでデータ状態を分離 |
| Amazon EventBridge | 新規オブジェクトアップロードを検知、ポーリングなしで自動トリガー |
| AWS Step Functions | スキャンライフサイクル全体をオーケストレーション |
| Amazon Macie | 組み込み＋カスタム識別子でPII検出 |
| AWS Lambda | ジョブ作成、状態ポーリング、結果解析、レポート生成、オブジェクト移動 |
| Amazon SNS | 高リスク検出時にリアルタイム通知 |
3バケットパターンの設計理由
- rawバケット: 未処理データ。スキャン完了後にオブジェクトを移動（バージョニング有効）。
- stagedバケット: スキャン待ちデータ。7日後に自動失効。
- scannedバケット: 検証済みデータとレポートを保存。
これにより、未処理データと検証済みデータが決して混ざらず、データリネージ（系列）が明確になります。
Step Functionsステートマシン構成
ワークフローは5つの順次状態で構成されます：
- TriggerScan: rawバケットの新規オブジェクトをstagedにコピーし、Macie分類ジョブを作成
- WaitForMacie: 60秒待機（Macieジョブの処理時間を確保）
- CheckStatus:
DescribeClassificationJobAPIでジョブ完了をポーリング - GetFindings: 分類結果を取得、CSV/JSONレポート生成、SNS通知送信
- MoveFiles: rawバケットの元オブジェクトをscannedに移動し、stagedをクリーンアップ
主要コード：CloudFormationデプロイ
以下はAWS CLIでCloudFormationスタックをデプロイするコマンドです。CustomIdentifierPatternsパラメータに組織固有の正規表現パターンを指定すると、Macieカスタム識別子が自動生成されます。
# AWS CLIでCloudFormationスタックをデプロイ
aws cloudformation create-stack \
--stack-name pii-detection-pipeline \
--template-body file://template.yaml \
--parameters \
ParameterKey=BucketNamePrefix,ParameterValue=my-pii \
ParameterKey=CustomIdentifierPatterns,ParameterValue='"\\b(?:POL|MEM)-[0-9]{6}\\b"' \
ParameterKey=KmsKeyArn,ParameterValue='' \
ParameterKey=NotificationEmail,ParameterValue='security@example.com'
注意: 上記コマンドは例です。実際のデプロイはGitHubリポジトリからCloudFormationテンプレートをダウンロードして進めてください。
注意点：プロダクション適用前のハードニング必須
このソリューションはサンプルコードであるため、そのままプロダクションで使うのは危険です。以下のハードニング対策を必ず適用してください。
セキュリティ強化
- マルチテナント環境: テナントごとに別スタックをデプロイし、
BucketNamePrefixを変えてデータ分離を維持してください。 - S3デフォルト暗号化: SSE-S3またはKMSキーを設定してください。
KmsKeyArnパラメータで指定できます。 - SNS暗号化: SSE-KMSを有効にしてください。
- CloudTrail: S3データイベントログを有効化し、監査証跡を完全に残してください。
Macieの制限とパフォーマンス考慮
- カスタムデータ識別子: アカウントあたり最大10,000個、分類ジョブあたり最大30個。それ以上必要な場合は複数ジョブに分割してください。
- APIスロットル:
CreateClassificationJobは1秒あたり0.1回（10秒に1回）の制限。大容量ワークロードではオブジェクトをバッチ処理してください。 - スキャン時間: データ量、圧縮方式、識別子数によって15〜20分以上かかる場合があります。
日本市場での適用コンテキスト
日本では個人情報保護法（改正個人情報保護法）が厳格で、特にマイナンバー（個人番号）は重要な特定個人情報として扱われます。カスタム識別子でマイナンバーや運転免許証番号などのパターンを必ず登録してください。また、日本のクラウド移行プロジェクトでは、3バケットパターンがデータ状態を明確に分離し監査に有利なため、提案書でよく見られるアーキテクチャです。ただし、Macieがサポートするリージョンが限られているため、東京リージョン（ap-northeast-1）で利用可能か事前に確認してください。
批判的視点：このソリューションの限界
- オブジェクト単位スキャンはコスト高: ファイルごとにMacieジョブを作成すると、大容量環境ではコストが急増する可能性があります。バッチ処理への移行を検討してください。
- Macieの検出限界: 正規表現ベースのカスタム識別子は、パターンが改変されると見逃す可能性があります。機械学習ベースの検出と併用するのが良いでしょう。
- 単一障害点: Step Functionsのエラーハンドリングが不十分だと、パイプラインが停止する可能性があります。
Catch句と再試行ポリシーを強化してください。
まとめ：実務適用のための次のステップ
このパイプラインは、S3にアップロードされるすべてのファイルをリアルタイムでスキャンし、標準PIIと組織固有の機密情報の両方を検出します。CSV/JSONレポートは規制監査にすぐ使用でき、高リスク検出時にはSNS通知で即座に対応できます。
拡張アイデア
- データレイク統合: JSON結果をAthenaやGlueに送りトレンド分析、QuickSightダッシュボード構築
- 修復ワークフロー: 高リスクPII検出時にファイル隔離やアクセス権限剥奪を行う分岐を追加
- マルチアカウント環境: OrganizationsとEventBridgeクロスアカウントルールで、専用セキュリティアカウントに集中スキャン
- セキュリティハブ連携: Security Hubに結果を公開し、統合セキュリティ管理
関連記事
ぜひ実際にデプロイしてみてください。CloudFormationテンプレートをダウンロードし、カスタム識別子を登録して、サンプルファイルをアップロードすれば、数秒以内にStep Functionsの実行が開始されることを確認できます。ご質問はコメント欄でどうぞ。