はじめに: PII検出、なぜ自動化が必要なのか
金融、保険、ヘルスケア、政府機関など規制産業に携わっているなら、PII(Personally Identifiable Information)管理の重要性は十分にご存知でしょう。
GDPR、HIPAA、CCPAなどの規制は「自社組織にどの個人情報がどこにあるのか」を正確に把握し、アクセス権限を管理し、保護措置を講じたという証跡を求めます。問題は、そうしたデータがファイル、ログ、パートナーフィード、社内ワークフローなど、無数の経路から継続的に流入する点です。
手動での分類作業はすでに限界に達しています。この記事では、ファイルがAmazon S3に到着した瞬間に自動でPIIを検出するイベント駆動型パイプラインの構築方法を詳しく解説します。
ポイントは、AWSのマネージド型データ検出サービスであるAmazon Macieを拡張し、組織固有のカスタム識別子まで併用することです。標準的なPII(クレジットカード番号、メールアドレスなど)はもちろん、ドメイン特化データ(保険証券番号、会員IDなど)まで自動的に検出できます。
💡 要約: S3へのファイルアップロード → EventBridgeで検知 → Step Functionsでオーケストレーション → Macieでスキャン → コンプライアンス報告書を自動作成、という一連の流れを実装します。
本記事の根拠資料はAWS Architecture Blog原文です。
本論1: 全体アーキテクチャと設計の要点
アーキテクチャ概要
このパイプラインは完全なイベント駆動型アーキテクチャで設計されています。ポーリングなしで、イベントが発生すると自動的にワークフローが開始されます。
[Amazon S3] --(オブジェクト作成イベント)--> [Amazon EventBridge] --> [AWS Step Functions]
|
v
[AWS Lambda] (各ステップ)
|
v
[Amazon Macie] (スキャン)
|
v
[CSV/JSONレポート生成] + [Amazon SNS通知]
各サービスの役割
| サービス | 役割 |
|---|---|
| Amazon S3 | データを3つのバケット(raw、staged、scanned)に分離し、処理状態を分離 |
| Amazon EventBridge | 新規オブジェクトのアップロードを検知し、ワークフローを自動トリガー |
| AWS Step Functions | Macieジョブ作成からレポート生成まで、スキャンライフサイクル全体をオーケストレーション |
| Amazon Macie | 組み込み+カスタムデータ識別子でPIIを検出 |
| AWS Lambda | 各ステップ間のコンピューティングロジックを担当(ジョブ開始、ステータスポーリング、結果解析、レポート生成、オブジェクト移動) |
| Amazon SNS | 高リスク検出時にリアルタイムアラートを送信 |
設計上の重要ポイント3選
-
オブジェクトごとに専用のMacie分類ジョブを作成: バッチ化せず、ファイルごとにジョブを作成することで、取り込み時点でのリアルタイム検出を実現します。
-
3バケットパターン: raw(未処理) → staged(待機) → scanned(完了)に分離し、未検査データと検証済みデータを混在させません。
-
EventBridgeの採用: S3のデフォルトイベント通知ではなくEventBridgeを使用することで、高度なフィルタリングとクロスアカウントルーティングを実現します。
本論2: 実装ワークフロー(コード中心)
前提条件
- 管理者権限を持つサンドボックス(または非本番)AWSアカウント
- AWS CLI v2のインストールと設定
- 対象リージョンでAmazon Macieを有効化
- 高リスク通知用の有効なメールアドレス
ステップ1: CloudFormationスタックのデプロイ
AWS CLIでのデプロイ方法です。コンソールから直接アップロードしても構いません。
# テンプレートファイルをローカルに保存して実行
export STACK_NAME=pii-detection-pipeline
export BUCKET_PREFIX=my-company-pii
export CUSTOM_PATTERN='[{"name":"PolicyNumber","regex":"POL-[0-9]{6}","confidence":80},{"name":"MemberID","regex":"MBR-[A-Z]{3}-[0-9]{4}","confidence":90}]'
export KMS_KEY_ARN='' # オプション。SSE-KMSを希望する場合に指定
export EMAIL_ADDRESS='security@yourcompany.com'
aws cloudformation create-stack \
--stack-name $STACK_NAME \
--template-body file://template.yaml \
--parameters \
ParameterKey=BucketNamePrefix,ParameterValue=$BUCKET_PREFIX \
ParameterKey=CustomIdentifierPatterns,ParameterValue=$CUSTOM_PATTERN \
ParameterKey=KmsKeyArn,ParameterValue=$KMS_KEY_ARN \
ParameterKey=NotificationEmail,ParameterValue=$EMAIL_ADDRESS \
--capabilities CAPABILITY_IAM
# デプロイ状況の確認
echo "スタック作成には3〜5分かかります"
aws cloudformation wait stack-create-complete --stack-name $STACK_NAME
ステップ2: SNSサブスクリプションの確認
デプロイ後、メールボックスを確認し、SNSサブスクリプション確認メールを開いてConfirm subscriptionをクリックします。その後、SNSコンソールでサブスクリプションがConfirmedになっていることを確認します。
ステップ3: カスタムデータ識別子の検証
CloudFormationパラメータで渡したCustomIdentifierPatternsがMacieコンソールに正しく登録されているか確認します。
Macieコンソール > Custom data identifiers > 一覧確認
ステップ4: パイプラインのテスト
サンプルファイルをrawバケットにアップロードし、フロー全体を検証します。
# サンプルデータ作成(カスタムパターンを含む)
cat > sample_claim.txt << 'EOF'
Customer Name: John Doe
Email: john.doe@example.com
Policy Number: POL-123456
Member ID: MBR-ABC-1234
SSN: 123-45-6789
EOF
# rawバケットにアップロード
export RAW_BUCKET="${BUCKET_PREFIX}-raw"
aws s3 cp sample_claim.txt s3://$RAW_BUCKET/
アップロード後、数秒以内にStep Functionsの実行が開始されます。コンソールでステートマシンを開き、実行状況をモニタリングしてください。
注記: Macieのスキャン時間はデータ量と種類によって異なります。サンプルでは約15〜20分かかりました。スキャン時間が長くなる可能性があるため、Step FunctionsのWait状態の動作を理解して進めることをお勧めします。
ステップ5: レポートと通知の確認
スキャンが完了すると、scannedバケットにタイムスタンプ付きのCSVとJSONレポートが生成されます。高リスク検出時にはSNS通知も届きます。
# 結果確認
export SCANNED_BUCKET="${BUCKET_PREFIX}-scanned"
aws s3 ls s3://$SCANNED_BUCKET/
# レポート内容確認
export LATEST_REPORT=$(aws s3 ls s3://$SCANNED_BUCKET/ --recursive | sort | tail -1 | awk '{print $4}')
aws s3 cp s3://$SCANNED_BUCKET/$LATEST_REPORT -
本論3: 本番環境適用時の注意点とハードニング
必ず適用すべきセキュリティ強化策
このソリューションはサンプルコードです。実際の本番適用には、以下のセキュリティ推奨事項に従ってください。
-
マルチテナント分離: テナントごとに別スタックをデプロイし、
BucketNamePrefixを変えて完全なデータ分離を維持してください。 -
暗号化のデフォルト適用: S3バケットのデフォルト暗号化をSSE-S3、またはKMS(カスタマーマネージドキー)で設定してください。
-
クロスアカウント対応: 複数アカウントからデータが流入する場合は、EventBridgeのクロスアカウントルールを構成してください。
-
CloudTrailの有効化: S3データイベントログを有効にし、すべてのオブジェクトアクセスと移動履歴を記録してください。
Macieの制限と対策
| 制約 | 値 | 対処戦略 |
|---|---|---|
| アカウントあたりのカスタム識別子数 | 10,000個 | 超過時は追加アカウントを検討 |
| 分類ジョブあたりのカスタム識別子数 | 30個 | 複数ジョブに分割して実行 |
| CreateClassificationJobスロットリング | 0.1 rps (10秒に1回) | 高負荷ワークロードはオブジェクトをバッチ化 |
日本市場での適用文脈
日本では個人情報保護法(いわゆる「個情法」)が適用されます。AWS Macieが標準提供するPIIパターンに加えて、以下のようなカスタム識別子を登録しておくと効果的です。
- 日本の郵便番号: 〒XXX-XXXX パターン
- マイナンバー: 12桁の数字パターン
- 法人番号: 13桁の数字パターン(国税庁発行)
また、日本のガイドラインでは「個人情報の安全管理措置」として、暗号化とアクセス制御の記録が求められます。このパイプラインで生成されるタイムスタンプ付きレポートがその証跡として活用できます。日本語ベースのPII(例: 漢字氏名、カナ氏名)は正規表現のカスタム識別子で独自に作成する必要がある点に注意してください。
まとめ: 実務適用のためのアドバイス
これで、S3にファイルがアップロードされると即座にPIIを自動検出し、監査に耐えうるレポートを生成し、リスク状況をリアルタイム通知で受け取るパイプラインを構築できます。
最後に3点だけお伝えします。
-
ファイル名に日付と時刻を含め、レポート体系を整理しておきましょう。後で監査要求が来たときに迅速に対応できます。
-
Macieのコストをモニタリングしてください。カスタム識別子を多用するとコストが増加する可能性があります。カスタムパターンは本当に必要なものだけ最小限に登録することをお勧めします。
-
次のステップとしてデータレイク拡張を検討しましょう。JSON結果をAmazon Athenaに接続してダッシュボードを作成すれば、PII密度の推移を可視化できます。
この記事が実際の業務でデータ保護パイプラインを設計する際の一助となれば幸いです。ご不明な点があればコメント欄でお知らせください。
合わせて読みたい記事
