Inspector & Macie — 「穴」と「秘密」を自動で見つける

考えてみてください。あなたの家に window がある。その window、隙間があるかな？鍵、ちゃんと閉まってるかな？毎日目視で確認できますか？いや、しませんね。でも、セキュリティとなると、こういった「目視チェック」を毎日やってる企業、多い。「すべてのEC2、脆弱性チェック」——手作業で？ばかばかしい。AWSには、この自動化を任せるサービスがあります。Inspector と Macie。この2つの「自動スキャン番人」について話します。

Inspector の基本

今までのセキュリティは「設定を正しく保つ」「認証を強化」みたいな、構成的なアプローチ。今回は「環境に脆弱性があるか？」「機密データがどこかに漏れてないか？」という、発見的なアプローチ。

Inspector v2。旧バージョンの Classic は廃止。v2 が標準。何が変わったか。Classic はエージェント必須。v2 はエージェントレス。助かります。

スキャン対象。EC2、ECR コンテナイメージ、Lambda 関数。さらに、ネットワーク到達可能性。つまり「この脆弱性、実は外部からアクセスできないセキュリティグループで保護されてるから、優先度低め」みたいな判定。だから、優先度付けが正確。

重要な制約。EC2 スキャンには SSM Agent が必須。古い AMI で Agent 入ってないと、スキャン対象にならない。ここ、見落としやすい。「あ、スキャン対象の EC2 が表示されない」って状況、だいたい Agent 未インストール。

Finding の種別

3つある。パッケージ脆弱性。OS パッケージの既知 CVE。ネットワーク到達可能性。その脆弱性が、ネットワーク経由でアクセス可能か。コード脆弱性。Lambda のコードに SQLi とか硬度化されたシークレットとか。

でね。すべてのプログラミング言語に対応してない。Java、Python、JavaScript が主。Rust、Go は対応外。覚えておく。

Organizations 統合

複数アカウント。委任管理者を指定。その委任管理者アカウントから、全メンバーアカウントの Finding を読取可能。見た目は 1 個のダッシュボード。バックエンドでは全アカウント・全リージョンのデータ集約。

だけどね。修復権限は委任管理者にない。「Finding を削除」できない。読取専用。各アカウント自身で修復。ここ、理解してない人多い。

Macie の役割

Macie は S3 専任。「この S3 バケットに、クレジットカード番号が含まれてないか」「社員 ID 情報が漏れてないか」。こういった機密データを検出。

検出方法は 2 種類。自動検出。新規オブジェクトアップロード時に、サンプリングで検査。100% ではなく、デフォルト 25%。スケジュール型ジョブ。毎月とか定期的に、バケット全体をスキャン。

誤解しやすい。「自動検出で 100% カバー」って思う人がいるんですが、違う。既存オブジェクトのスキャンには、スケジュール型ジョブが必須。

カスタムデータ識別子

マネージドデータ識別子は、AWS が提供。PII、クレジットカード、医療情報。自動更新される。

カスタムデータ識別子は、組織で定義。正規表現とキーワード。「EMP12345678」みたいな社員 ID パターン。実装例。regex に「EMP[0-9]{8}」。keywords に「employee」「emp_id」。maximumMatchDistance に 50。これで「EMP」の 50 文字以内に「employee」キーワードがあれば、信度 UP。

重要。regex だけだとヒット多すぎて、誤検知が増えます。keywords で絞り込む。ignoreWords で「test_emp」とか テスト用語を除外。この組み合わせ。

Allow List

Allow List。「これは実は機密ではない」という許可リスト。テスト用ダミーデータ。公開ドキュメント。こういった正規ファイルを除外。

だけどね。乱用は NG。本当に非機密のデータのみ。「あ、ちょっと機密かもな」みたいなやつを Allow List に入れると、本当に漏れたときに見逃す。

試験ポイント

「Inspector がスキャンできないリソース」。RDS。マネージド。AWS 側で脆弱性管理。S3。データストレージ。脆弱性概念が異なる。DynamoDB。同じ理由。これらに問い合わせで「Inspector で対応」って言ったら、落とし穴。

「Macie の自動検出」。100% スキャンではない。既存オブジェクトはスケジュール型ジョブ必須。「Macie 有効化したから、既存のすべての機密データ発見される」って思い込みはダメ。

「Organizations 統合での権限」。委任管理者は「見える」だけ。「削除」「修復」はできない。各アカウント自身で対応。

できないこと

Inspector のカスタムルール。オリジナルの CVE パターンを追加できない。AWS 脆弱性 DB のみ。

Macie のリアルタイムスキャン。既存オブジェクトの自動スキャンなし。ジョブ実行時のみ。

両方とも、自動修復機能がない。検出のみ。修復は Lambda で別途実装。EventBridge で Finding トリガーして、Lambda 実行。それで自動化。

まとめ

Inspector は「環境の脆弱性」。Macie は「データの機密性」。セットで運用すると、セキュリティポスチャが大きく向上します。自動化（EventBridge + Lambda）が重要。

次の講義は Organizations、Control Tower、IAM Identity Center。マルチアカウント管理の 3 層。SCP の評価ロジック、ガードレール 3 種類、IDソース選択の重要性。では次の動画で。