セキュリティ・コンプライアンス

Macieを6ヶ月運用して気づいた、S3機密データ検出の本当の課題

SOC2対応で導入したMacieの本番運用。False Positive地獄、予想外のコスト、実装の落とし穴...シニアエンジニアが正直に語る現実的な運用ノウハウ。

AWSMacieセキュリティコンプライアンスSOC2

Amazon Macie本番6ヶ月運用で見えたS3機密データ検出の現実

うちのチームがSOC2審査に向けてMacieを導入したのが昨年の11月。「S3のアクセス制御だけで大丈夫」と思ってた僕たちが、本番環境で直面した現実は想像以上にヘビーだった。今日は、同じくセキュリティ対応に追われてるエンジニアに、正直なMacie運用の話をしたい。

Macieを導入した理由と最初の失敗

最初のきっかけはシンプルだった。監査人から「S3に機密データが混在してないか、定期的に検証してください」と言われて、「そりゃ自動スキャンツール使うしかない」と判断した。

**GuardDutyじゃダメなの？**という質問も出たんだけど、GuardDutyはAPI呼び出しのアノマリー検知が中心。S3の中身を見るには、Macieが必須だった。

導入初日が悪夢の始まりだった。

デフォルト設定でMacieを有効にして、翌日レポート見たら「PII（個人識別情報）が5000個検出されました」と。営業チームのExcelがS3の古いフォルダに放置されてたせいだった。「これ全部手動で確認するの？」って目の前が真っ暗になった記憶がある。

そこで気づいたのが、Macieはとにかくアラートが多いってこと。テーブルからカード番号的なパターンをキャッチするけど、実は別の形式のIDだったり、テストデータだったり。この「False Positive地獄」が、本番運用の8割の労力を占めることになる。

False Positiveとの付き合い方

6ヶ月の運用で学んだのは、検出精度を追い求めるより、運用ルールを決める方が重要ってこと。

セッティングのポイント

最初は「PII検出」「パスワード検出」「ポリシー検出」全部有効にしてた。結果、週500件のアラートが来て、チームが疲弊した。3ヶ月目に思い切って設定を見直した。

{
  "classificationJob": {
    "s3JobDefinition": {
      "bucketDefinitions": [
        {
          "accountId": "123456789012",
          "buckets": ["production-logs", "api-data", "analytics"]
        }
      ]
    },
    "allowListDefinition": {
      "s3WordsList": {
        "bucketName": "macie-allowlist",
        "objectKey": "allowlist.txt"
      }
    },
    "classificationScopeUpdate": {
      "excludes": {
        "simpleScopeTerms": [
          {
            "comparator": "STARTS_WITH",
            "key": "OBJECT_NAME",
            "values": ["/test/", "/staging/"]
          }
        ]
      }
    }
  }
}

大事なのはスコープの明確化。本番環境だけに絞って、テスト環境は別バケットで管理。許可リスト（allowlist）も作った。営業チームの顧客マスターCSVは実際の顧客データなので除外できないけど、自動生成テストデータはフィルタした。

この調整だけで、週500件→週50件に減った。でも大事なのはここから。残り50件を「どこまで真摯に対応するか」のルール作りだった。

実運用で決めたルール

うちで決めたのは「Confidence高い検出」だけを対応対象にすること。Macieの検出には信頼度があるんだけど、低信頼度のアラート（スペルミスとか類似パターンとか）は一定期間Quietにして監視。

# Macie DetectionsをQuietに設定するコード例
import boto3
from datetime import datetime, timedelta

macie = boto3.client('macie2')

response = macie.list_findings(
    filterCriteria={
        'severity': {
            'eq': ['LOW']  # 低信頼度だけ
        },
        'createdAt': {
            'gte': datetime.now() - timedelta(days=7)
        }
    },
    maxResults=100
)

for finding in response['findings']:
    if finding['severity']['description'] == 'Low':
        macie.suppress_findings(
            findingIds=[finding['id']],
            suppressionType='UNTIL_EXPIRATION',
            suppressionDuration=30  # 30日間Quiet
        )

こうすることで、本当に重要な検出だけに集中できるようになった。正直、最初はこんなフィルタリング機構があること自体知らなかったから、全部に対応してた。チームの工数が減ったのと同じくらい、対応精度も上がったんで、早めに気付いてよかった。

機密データの分類戦略

Macieの設定をやり込むと気づくのが、何が「機密」かは組織によって違うってこと。一般的なPII（電話番号、メールアドレス）だけじゃなく、うちの場合は顧客IDの形式も機密度が高い。

そこで、カスタム識別子を作ることにした。

カスタム識別子の実装

{
  "customDataIdentifier": {
    "name": "customer_id_pattern",
    "description": "社内顧客ID形式：CUST-xxxxxxxx",
    "regex": "CUST-[0-9]{8}",
    "keywords": ["customer_id", "cust_id", "顧客番号"],
    "maximumMatchDistance": 50
  }
}

これをMacieに登録すると、S3内で「CUST-」で始まる8桁の数字を自動的に検出するようになる。つまり、顧客リストが誤ってパブリックバケットに置かれてないか、常に監視できるようになった。地味だけど、こういう小さなカスタマイズが運用を楽にする。

本番運用の監視・対応フロー

うちが実装した全体像を図で見るとこんな感じ。

graph TB
    subgraph VPC["AWS Account"]
        S3["S3 Buckets"]
        Macie["Amazon Macie"]
        EventBridge["EventBridge"]
        SNS["SNS Topic"]
        Lambda["Lambda<br/>Auto-Response"]
        RDS[("Audit Log DB")]
    end
    
    subgraph Monitoring["Monitoring & Response"]
        CloudWatch["CloudWatch Dashboard"]
        Slack["Slack Webhook"]
        SecurityTeam["Security Team"]
    end
    
    S3 -->|"Scanned by"| Macie
    Macie -->|"High Confidence"| EventBridge
    EventBridge -->|"Trigger"| Lambda
    EventBridge -->|"Notify"| SNS
    SNS -->|"Alert"| Slack
    Lambda -->|"Log Finding"| RDS
    Lambda -->|"Block Object"| S3
    Macie -->|"Daily Report"| CloudWatch
    CloudWatch -->|"Metrics"| Slack
    Slack -->|"Review"| SecurityTeam

このフロー、実装するのにけっこう時間がかかったんだけど、動き始めると本当に手間が減る。

具体的には、こんなふうに動く：

  1. Macieが高信頼度の検出をする → EventBridgeルールがトリガー
  2. Lambdaが自動応答 → 該当オブジェクトを隔離（別バケットに移動）、アクセス権剥奪
  3. 監査ログに記録 → RDSに永続化
  4. Slackで通知 → セキュリティチームがレビュー

この自動化がなかったら、毎日の対応で潰れてた。個人的には、セキュリティ対応の自動化ってここまで効果があるのかと驚いたくらい。

コスト最適化の現実的な話

正直、Macieのコストは予想より高かった。

初期設定では月15万円の請求が来た。スキャンバイト数で課金されるんで、「試しに全S3バケット対象」にすると一気に増える。S3の容量が多いなら、特定バケットに限定するのは必須。

コスト最適化で実装したこと：

  • 定期ジョブ制に変更 → 24時間連続スキャンから、週1回（日曜夜間）のスケジュール実行に。月5万円→月2.5万円に削減
  • バケットのホワイトリスト化 → 本当に機密データが入る可能性が高いバケットだけスキャン対象に
  • 古いオブジェクトの除外 → 更新日が1年以上前のファイルはスキャン対象外（Lifecycle Policyと組み合わせ）
{
  "classificationJob": {
    "jobType": "SCHEDULED",
    "scheduleFrequency": "WEEKLY",
    "s3JobDefinition": {
      "bucketDefinitions": [
        {
          "accountId": "123456789012",
          "buckets": ["production-api-data", "customer-uploads"]
        }
      ],
      "excludes": {
        "simpleScopeTerms": [
          {
            "comparator": "STARTS_WITH",
            "key": "OBJECT_NAME",
            "values": ["/.aws/", "/archive/"]
          }
        ]
      }
    }
  }
}

これで月2.5万円に安定した。SOC2対応としてはこのレベルで十分だと、監査人もOK出してくれた。正直、月5万円で運用できるなら安いくらい。セキュリティ監査のチケット対応の工数削減の方が遥かに大きい。

本番で痛い目を見た3つのこと

1. バケット名変更でジョブが死ぬ

4ヶ月目、リソース整理で「old-api-bucket」を「api-data-prod」にリネームした。その瞬間、Macieのスケジュール実行が失敗しまくった。理由は単純：ジョブ定義のバケット参照が古いままで、新しいバケットに気付いてなかった。

自動化したおかげで気付けたけど、手動チェックだったら1週間気付かなかったと思う。今はバケット変更時に「Macieジョブ定義も更新」をチェックリストに入れてる。

2. JSON構造のデータに弱い

顧客マスターがJSONで保存されてるバケットがあって、カード番号のフィールドが含まれてた。Macieは通常、テキストやCSVはスキャンするけど、JSON内の特定フィールドを「これは顧客ID、見逃して」みたいな指定ができない。

結果、毎週同じオブジェクトが「カード番号検出」でフラグ立つ。allowlistに入れるしかなかった。でも、このallowlist自体がセキュリティ監査のネタになる。「なぜ許可した？」と監査人に聞かれるたびに説明資料を作った。これが地味に手間だった。

3. マルチアカウント設定の複雑さ

うちは本番環境を別AWSアカウントに分けてるんで、Macieもそれぞれで設定してた。6ヶ月運用してみたら「本番のジョブ定義」と「開発のジョブ定義」で設定がズレてた。開発では「低信頼度も検出」、本番では「高信頼度のみ」みたいに。

この不統一が原因で、本番で見落としていた検出が後で見つかったり、開発で無駄なアラートが続いたり。今はOrganization全体で統一的なセキュリティポリシーを決めることにした。複数アカウント運用する場合は、最初からこの「設定統一」を念頭に置くべきだった。

Macieレポートの活用と定期レビュー

Macieの本当の価値は、検出エンジンじゃなく、監査証跡だと気付いた。

Monthly Finding Summary Reportをダッシュボード化して、セキュリティ委員会に報告してる。

import boto3
from datetime import datetime, timedelta
import json

macie = boto3.client('macie2')

def get_monthly_statistics():
    end_date = datetime.now()
    start_date = end_date - timedelta(days=30)
    
    response = macie.list_findings(
        filterCriteria={
            'createdAt': {
                'gte': int(start_date.timestamp() * 1000),
                'lte': int(end_date.timestamp() * 1000)
            }
        },
        maxResults=100,
        sortCriteria={
            'attributeName': 'severity',
            'orderBy': 'DESC'
        }
    )
    
    findings_by_type = {}
    for finding in response['findings']:
        classification_type = finding['classificationDetails']['result']['classification']
        if classification_type not in findings_by_type:
            findings_by_type[classification_type] = 0
        findings_by_type[classification_type] += 1
    
    return findings_by_type

stats = get_monthly_statistics()
print(json.dumps(stats, indent=2))

このレポートがあると、「今月は検出数が減りましたね」「このタイプの検出が増えてる」みたいな傾向分析ができて、セキュリティ投資の優先度も決めやすくなる。監査人の心象もよくなるし。

他のAWSセキュリティサービスとの組み合わせ

Macieだけじゃなく、GuardDuty・Config・Security Hubと連携させると、セキュリティ体制が一段階上がる。特にSecurity Hubでフィンディングを一元管理すると、Macie固有のログの見落としがなくなる。

個人的には、単一ツールじゃなく、複数のセキュリティレイヤーをちゃんと組み合わせることが大事だと痛感した。というか、Macieだけで完全な機密データ保護ができると思ってた僕たちが甘かった。データ検出だけじゃなく、アクセス制御（IAM）とネットワーク分離（VPC）も同時に進めないと、絵に描いた餅になる。

実運用で気づいた「やっておくべき準備」

ここまで6ヶ月やってみて、事前にやっておくべきことが見えてきた。

準備内容タイミング重要度やらないとどうなるか
事前バケット監査導入前★★★スコープ決定に迷って、不要なスキャンが増える
allowlist & 除外ルール設計導入初期★★★False Positiveで毎日疲弊
セキュリティチームのオンボーディング導入初期★★★検出の見方がわからず、対応が遅延
定期的なポリシー見直し3ヶ月ごと★★☆無駄な検出が積み重なる
コスト監視の自動化導入後すぐ★★☆予想外にスキャン対象が増えてる

具体的には：

  1. 事前にバケット監査をする → Macieのスコープ決定前に、どのバケットに何が入ってるかを把握。「え、このバケットにPII入ってるの？」という発見が必ず出てくる

  2. allowlistと除外ルールのガイドラインを作る → なぜそれを許可したか、を監査人に説明できるように。これがないと監査対応が地獄になる

  3. セキュリティチームのオンボーディング → 検出の見方、対応フロー、エスカレーションプロセスを共有。最初は全員で Macie コンソール見ながら「これってどう判断すればいいの？」を決める

  4. 定期的なポリシー見直し → 3ヶ月ごとに「本当にこの設定が有効か」をレビュー。最初は「いっぱい検出したい」だけど、運用してると「いかに信頼できる検出だけにするか」に変わる

  5. コスト監視の自動化 → 予想外にスキャン対象が増えてないか、月1回チェック。新しいバケットが作られてMacieの対象に勝手に入ってる、みたいなことが起きる

Macie導入を検討してる人へのアドバイス

Macieはいいツールだけど、導入するなら心構えを持っておいた方がいい。

まず、試験環境で「高信頼度のみ」「特定バケットのみ」という制約で試してみる。この段階で「どの程度のアラート量になるか」「対応フローはどうするか」を決める。

その上で、本番環境のスコープ・除外ルール・自動応答フローを設計する。一気に全部有効にすると、後悔することになる。うちはそれで 3 ヶ月目に見直すハメになった。

あと、Macieだけで完全なセキュリティ対応ができると思わない。データ検出・検知・対応の全体設計の中で、Macieをどう位置付けるかを考えることが大事。

正直、SOC2審査に向けて導入するなら、Macieの導入と同時にセキュリティガバナンスの全体設計もやった方がいい。データ検出だけやってても、「でもアクセス制御は？」「ログの保管期間は？」という質問が必ず出てくるから。

まとめ

  • Macieは検出ツールじゃなく、監視・監査ツール。False Positiveとの付き合い方が運用の80%を占める
  • スコープを絞ることが最優先。全S3をスキャンするのはコスト的にも運用的にも無理。本当に機密が混在してる可能性が高いバケットだけに限定
  • 自動化とルール化が必須。EventBridge + Lambdaで自動応答フローを作らないと、毎日のアラート対応で潰れる
  • Security Hubとの連携を前提に設計する。Macie単独では弱いが、他のセキュリティサービスと組み合わせると力を発揮
  • コスト管理も重要。スケジュール実行に変更して月5万円→2.5万円になった。監査効果は変わらず

Macieの導入を検討してるなら、この記事が参考になれば幸い。運用の大変さは想像よりあるけど、ちゃんと設計してしまえば、セキュリティ監査の強力な武器になる。

U

Untanbaby

ソフトウェアエンジニア｜AWS / クラウドアーキテクチャ / DevOps

10年以上のIT実務経験をもとに、現場で使える技術情報を発信しています。 記事の誤りや改善点があればお問い合わせからお気軽にご連絡ください。

関連記事

セキュリティ・コンプライアンス

SOC2審査でCloudTrail・Configに3ヶ月ハマった話。本当に動く監査設計パターン

セキュリティ・コンプライアンス

SOC2審査で月30万円の請求から学んだCloudTrail・Config設計｜実装コード付き

セキュリティ・コンプライアンス

CloudTrail・Config監査設計で失敗した話。SOC2審査3ヶ月の地獄から学んだ実装パターン

セキュリティ・コンプライアンス

Amazon Macieを本番導入したら「S3の闇」が見えた話｜SOC2審査がきっかけの6ヶ月実録

セキュリティ・コンプライアンス

Macie を本番環境で 6 ヶ月運用して気づいたこと｜False Positive との付き合い方

セキュリティ・コンプライアンス

AWS Organizations設計で10アカウント管理が崩壊した話｜実装を丸ごと作り直した3ヶ月

← 記事一覧に戻る