Inspector & Macie — 脆弱性スキャン・機密データ検出

はじめに

Amazon InspectorとAmazon Macieは、AWSのセキュリティスキャン機能の車の両輪です。Inspectorは脆弱性を検出し、Macieは機密データを検出します。SCS-C03では両者の詳細な機能差、スキャン対象の正確な理解、そして組織規模での運用方法が問われます。

本講では、実務レベルの設定知識から試験での落とし穴まで、徹底的に解説します。

---

Inspector v2 スキャンパイプライン

Amazon Macie データ検出フロー

Inspector マネジメントコンソール画面

Macie マネジメントコンソール画面

---

Inspector v2とは

Amazon Inspector v2（以下「Inspector」）は、AWS環境における脆弱性の継続的な検出と優先順位付けを自動化するマネージドサービスです。

主な特徴

• エージェントレス：EC2やコンテナの脆弱性をエージェントなしで検出
• 継続的スキャン：イメージプッシュやEC2起動時に自動的にスキャン
• 複数の検出対象：EC2、ECRコンテナイメージ、Lambda関数、Lambda レイヤー

旧Inspector Classicとの比較

試験で狙われるポイント

• Classic はもう新規有効化できず、v2が標準
• ただし、既存のClassicデータはしばらく保持される
• v2ではエージェント不要だが、EC2スキャンにはSSM Agent必須

---

スキャン対象と仕組み

1. EC2インスタンスのスキャン

前提条件

• SSM Agent がEC2に実装されていること
• EC2に適切なIAM ロール（AmazonSSMManagedInstanceCore）が付与されていること
• EC2がSystems Manager の認識可能な状態にあること

スキャンプロセス：

1. Inspector がSSM経由でEC2のメタデータを取得
2. OSのパッケージ管理システムから依存関係を読み取り
3. AWS脆弱性データベース（VulnerabilityDatabase）に照合
4. 脆弱性とそのネットワーク到達可能性を判定

重要： SSM Agent がいなければスキャン対象にならない。EC2が自動Systems Manager登録対象でも、エージェント起動に遅延があると初期スキャンが遅れる。

2. ECRコンテナイメージのスキャン

自動スキャン

Inspectorが有効化されたアカウント・リージョンでは、リポジトリへのプッシュ時に自動的にコンテナイメージをスキャンします。

メリット：

• CI/CDパイプライン内のゲートとして機能
• レジストリ側で一元管理、イメージレプリケーション時の再スキャン
• イメージレイヤーの詳細な解析

注意点：

• スキャン対象はPushされたレイヤーのみ（古いイメージの遡及スキャンなし）
• 暗号化イメージもスキャン対象
• リポジトリが削除されると関連Findingも自動削除

3. Lambda関数とLambda レイヤーのスキャン

Lambda関数のスキャン

• 関数コード＋デプロイパッケージの依存関係を解析
• パッケージが明示的に記載されている場合のみ検出可能
• Layer内の依存関係も対象

ベストプラクティス

• 関数のSHA-256フィンガープリント変更時に再スキャン
• 同じコードに対する再スキャンはスキップ（コスト節約）

---

Finding種別：3つの検出タイプ

1. パッケージ脆弱性（Package Vulnerability）

内容：

• OSパッケージやライブラリの既知脆弱性
• CVE ID、CVSS スコア、修復方法を含む

例

• OpenSSL 1.1.1未満 → OpenSSL 1.1.1g以上へアップグレード推奨
• Log4Shell（CVE-2021-44228）

重要な特性：

• 最も一般的な検出タイプ
• CVSS スコアで自動的に優先度が計算される
• 修復パッチの有無を自動判定

2. ネットワーク到達可能性（Network Reachability）

内容：

• インスタンス上の脆弱なパッケージが、ネットワーク経由でアクセス可能か判定
• VPC フローログ、セキュリティグループ、NACLを考慮

メカニズム

1. VPC フローログ分析：実際のトラフィックパターンを抽出
2. セキュリティグループ・NACL評価：ポートが許可されているか確認
3. インターネットゲートウェイ経由の外部到達判定
4. IAM メタデータサービス（IMDSv1）経由のメタデータ泄露リスク

活用例

Apache 2.4.50の脆弱性が検出されたが、セキュリティグループでHTTP/HTTPSが外部から遮断されている場合 → 優先度が低く表示

3. コード脆弱性（Code Vulnerability）

対象

• Lambda関数、コンテナイメージ内のアプリケーションコード
• SAST（Static Application Security Testing）手法で検出

例

• SQLインジェクション
• 硬度化されたシークレット
• デッドコード内のセキュリティホール

制限：

• すべてのプログラミング言語対応ではない
• Java、Python、JavaScript が主対象

---

SBOMエクスポートとトレーサビリティ

SBOM（Software Bill of Materials）とは

アプリケーションが依存するすべてのコンポーネント、ライブラリのリスト化。

Inspectorでの SBOM：

# AWS CLI でFinding検索時に SBOM参照
aws inspector2 list-findings \
  --filter-criteria vulnStatus=ACTIVE \
  --region us-east-1 \
  --query 'findings[*].[resources,vulnerabilities]'

エクスポート形式：

• CycloneDX（XML/JSON）
• SPDX（RDF/Tag-value）

ユースケース：

• ライセンスコンプライアンス確認
• サプライチェーンリスク評価
• 規制要件への対応（FDA 21 CFR Part 11など）

---

抑制ルールと除外管理

抑制ルール（Suppression Rule）の設定

脆弱性の検出を一時的または永続的に非表示にする機能。

# 抑制ルールの作成（CLI例）
aws inspector2 create-finding-aggregation-account \
  --region us-east-1

# 特定のFindingを抑制
aws inspector2 update-finding-aggregation \
  --finding-aggregation-scope ACCOUNT \
  --suppress-rules type=ACCOUNT,region=us-east-1

抑制ルールの種類

ベストプラクティス

抑制は「理由」をコメント付きで記録する

• 「修復不可能な設計」
• 「WAFで保護されている」
• 「本番環境ではなく開発環境」

定期的に抑制ルールを見直す（月次推奨）

抑制期限を設定し、自動失効させる

---

組織での委任管理者運用

Organizations統合

一元管理アカウント（Management Account）が複数の
メンバーアカウントのInspectorを一括統合

委任管理者の設定手順

1. Organization内での有効化：

aws organizations register-delegated-administrator \
  --account-id 123456789012 \
  --service-principal inspector.amazonaws.com \
  --region us-east-1

2. 委任管理者アカウントでの統合有効化：

aws inspector2 enable-delegated-admin-account \
  --delegated-admin-account-id 123456789012 \
  --region us-east-1

メリット

• 複数アカウントの脆弱性を単一ダッシュボードで監視
• クロスアカウント Findingの集約
• 組織全体のセキュリティポスチャ可視化

Organizations integration での挙動

管理アカウント → 全メンバーアカウントのFindingを読取専用で閲覧
メンバーアカウント → 自アカウントのFinding完全制御

---

できないこと・制約

Inspectorが対応していない検出対象

機能制限

重要：SSM Agent依存性

EC2スキャンはSSM Agent 必須
→ 古いAMIや自作AMIで未インストール
→ スキャン対象にならない（見落とし！）

---

ベストプラクティス

1. 全アカウント・全リージョンでの有効化

# 組織全体での有効化スクリプト（Python例）
import boto3

orgs_client = boto3.client('organizations')
inspector_client = boto3.client('inspector2')

accounts = orgs_client.list_accounts()['Accounts']
regions = ['us-east-1', 'eu-west-1', 'ap-southeast-1']

for account in accounts:
    if account['Status'] == 'ACTIVE':
        for region in regions:
            inspector_client = boto3.client('inspector2', region_name=region)
            try:
                inspector_client.enable()
                print(f"✓ Enabled for {account['Id']} in {region}")
            except Exception as e:
                print(f"✗ Failed: {e}")

2. ECRスキャンでCI/CDゲート

# CodePipeline段階での検証例
REPO_NAME="my-app"
IMAGE_TAG="v1.0.0"

aws ecr describe-images \
  --repository-name $REPO_NAME \
  --image-ids imageTag=$IMAGE_TAG \
  --query 'imageDetails[0].imageScanFindingsSummary'

# Critical/High 脆弱性がある場合はパイプライン停止
if [ $(aws ecr describe-image-scan-findings \
  --repository-name $REPO_NAME \
  --image-id imageTag=$IMAGE_TAG \
  --query 'imageScanFindings.findingSeverityCounts.CRITICAL' | grep -c '.[1-9]') -gt 0 ]; then
  echo "CRITICAL vulnerability found. Deployment blocked."
  exit 1
fi

3. Findingの優先順位付けと自動通知

# EventBridge ルール：CRITICAL脆弱性を自動検知
aws events put-rule \
  --name InspectorCriticalFindings \
  --event-pattern '{
    "source": ["aws.inspector2"],
    "detail-type": ["Inspector2 Finding"],
    "detail": {
      "severity": ["CRITICAL"]
    }
  }'

# SNS通知へ
aws events put-targets \
  --rule InspectorCriticalFindings \
  --targets "Id=1,Arn=arn:aws:sns:region:account:AlertTopic"

---

第2部：Amazon Macie の詳細設定

Macieとは

Amazon Macieは、機密データ（PII、カード情報、認証情報など）をS3バケット内で自動検出・分類するマネージドサービスです。

主な特徴

• S3専任：Amazon S3バケットのみが対象
• 機密データ検出：マネージドデータ識別子＋カスタム識別子
• 複数の検出方法：スケジュール型ジョブ、自動検出、Allow List
• Organizations統合：複数アカウント一元管理

---

機密データ検出ジョブ

スケジュール型ジョブ

# Macieでジョブ作成（AWS CLI）
aws macie2 create-classification-job \
  --job-type SCHEDULED \
  --job-config '{
    "s3JobDefinition": {
      "bucketDefinitions": [
        {
          "accountId": "123456789012",
          "buckets": ["my-sensitive-bucket"]
        }
      ],
      "scoping": {
        "includes": {
          "and": [
            {
              "simpleScopeTerm": {
                "comparator": "STARTS_WITH",
                "key": "OBJECT_KEY",
                "values": ["logs/"]
              }
            }
          ]
        }
      }
    },
    "scheduleFrequency": "MONTHLY"
  }' \
  --name "MySensitiveDataScan"

ジョブの設定要素

フィルタリングの実践例

# 設定例：画像ファイルを除外、logs フォルダのみ対象
{
  "s3JobDefinition": {
    "bucketDefinitions": [{"accountId": "111111111111", "buckets": ["data-bucket"]}],
    "scoping": {
      "includes": {
        "and": [
          {
            "simpleScopeTerm": {
              "key": "OBJECT_KEY",
              "comparator": "STARTS_WITH",
              "values": ["logs/"]
            }
          }
        ]
      },
      "excludes": {
        "and": [
          {
            "simpleScopeTerm": {
              "key": "OBJECT_SIZE",
              "comparator": "GT",
              "values": ["1000000"]  // 1MB以上を除外
            }
          },
          {
            "simpleScopeTerm": {
              "key": "OBJECT_KEY",
              "comparator": "ENDS_WITH",
              "values": [".jpg", ".png", ".gif"]
            }
          }
        ]
      }
    }
  }
}

コスト計算式

Macie料金 = スキャン済みオブジェクト数 × 単価（約 $0.001 per 1,000 objects）

重要：スケジュールジョブは繰り返し実行されるため、
毎月のコスト = 月間スキャンオブジェクト数 × 単価 × 実行回数

---

マネージドデータ識別子

Macieの標準データ識別子

Macieに組み込まれた識別子。AWS側で自動更新・メンテナンス。

カテゴリ別一覧：

マネージドデータ識別子の強度

高感度（High Confidence）：

クレジットカード番号（Luhnアルゴリズム検証済み）
AWS IAM Access Key ID（`AKIA...` パターン）
OpenSSH 秘密鍵（`-----BEGIN OPENSSH PRIVATE KEY-----`）

中感度（Medium Confidence）：

Email アドレス（一般的なパターン）
電話番号（複数フォーマット対応）
IPv4アドレス（プライベートレンジ除外）

注意点： マネージドデータ識別子はカスタマイズ不可。精度調整はカスタム識別子で実施。

---

カスタムデータ識別子

カスタム識別子とは

組織独自の機密データパターンを正規表現と近接ルールで定義。

作成手順

aws macie2 create-custom-data-identifier \
  --name "Internal-Employee-ID" \
  --regex "EMP[0-9]{6}" \
  --keywords ["employee", "emp_id", "staff_number"] \
  --maximum-match-distance 50 \
  --ignore-words ["test", "example"] \
  --description "Internal employee ID format"

パラメータ解説

実践的なカスタム識別子の例

# 1. 社員番号パターン
{
  "name": "CompanyEmployeeID",
  "regex": "^[A-Z]{3}-[0-9]{5}$",
  "keywords": ["employee_id", "staff_code", "emp_no"],
  "maximumMatchDistance": 30
}

# 2. 内部プロジェクトコード
{
  "name": "ProjectCodeInternal",
  "regex": "PROJECT_[A-Z0-9]{10}",
  "keywords": ["project", "code", "internal"],
  "maximumMatchDistance": 20,
  "ignoreWords": ["template", "example"]
}

# 3. 顧客ID（企業向けサービス）
{
  "name": "CustomerIDFormat",
  "regex": "CUST-[0-9]{8}-[A-Z]",
  "keywords": ["customer", "cust_id", "client_number"],
  "maximumMatchDistance": 40,
  "ignoreWords": ["test_cust", "demo"]
}

# 4. データベース接続情報
{
  "name": "DBConnectionString",
  "regex": "(Server=|host=)[^;]+;(Password=|password=).+",
  "keywords": ["database", "connection", "db_"],
  "maximumMatchDistance": 100
}

カスタム識別子のベストプラクティス

1. 正規表現は具体的に
   ❌ [0-9]+ → 数字だけはヒット多すぎ
   ✓  EMP[0-9]{6} → 社員番号フォーマットに限定

2. キーワードは複数用意（別表記対応）
   ✓ ["employee_id", "emp_no", "staff_code"]

3. ignoreWords でテスト・デモを除外
   ignoreWords: ["test", "example", "demo_"]

4. maximumMatchDistance は適切に設定
   30~50文字 → キーワード近辺のみ
   100文字以上 → 誤検知増加注意

5. 定期的に有効性を監視
   → カスタム識別子で検出したFindingを月次レビュー

---

自動機密データ検出

自動検出の仕組み

Macieを有効化したアカウントのS3に自動的に
新規オブジェクトまたは更新オブジェクトをサンプリング

サンプリングベースの挙動

# 有効化
aws macie2 enable-macie

# 自動検出の設定確認
aws macie2 get-macie-session \
  --query 'status'

重要な特性：

自動検出と定期ジョブの使い分け

---

Allow List（許可リスト）

Allow List の用途

機密データと判定されたオブジェクトを「実は機密ではない」と除外登録。

設定例

# Allow List の作成
aws macie2 create-allow-list \
  --criteria '{
    "regex": "^test_data/.*\.csv$"
  }' \
  --name "TestDataExclusion" \
  --description "テスト環境のダミーデータ（機密ではない）"

# Finding検出時にAllow List適用
aws macie2 create-classification-job \
  --job-type SCHEDULED \
  --job-config '{
    ...
    "allowListIds": ["al-abc123..."]
  }'

Allow List 適用時の挙動

1. Classification Job 実行
2. 機密データ検出時に Allow List パターンと照合
3. マッチ → Finding 生成しない
4. 未マッチ → Finding 生成

ベストプラクティス

Allow List を乱用しない
→ 本当に非機密データのみ登録

例：
✓ test_data/sample-*.csv （テストデータ確定）
✓ public/*/readme.txt （公開ドキュメント）
❌ logs/.*-password.* （これは機密扱いすべき）

定期的に見直し（月次推奨）

---

組織での委任管理者運用

Organizations統合

# 管理アカウントで委任管理者登録
aws organizations register-delegated-administrator \
  --account-id 123456789012 \
  --service-principal macie.amazonaws.com

# 委任管理者での有効化
aws macie2 enable-macie

# メンバーアカウント関連付け
aws macie2 associate-member-account \
  --member-account-id 987654321098

メンバーアカウントの管理オプション

重要：Organizations統合時の権限

委任管理者アカウント：
  - メンバーアカウントのMacieを有効化可能
  - メンバーのジョブを作成・管理可能
  - メンバーのFindingを読取可能（修復不可）

メンバーアカウント：
  - 自アカウントの Macie 設定に制限
  - ローカルジョブ作成は委任管理者の許可下

---

できないこと・制約

Macieが非対応の機能・対象

重要：KMS暗号化の注意点

# KMS暗号化されたオブジェクトの場合
# Macie はメタデータのみ検出（内容は解析不可）

# 解決策：
# 1. KMS 権限を Macie に付与
aws kms grant create \
  --key-id arn:aws:kms:region:account:key/key-id \
  --grantee-principal arn:aws:iam::account:role/aws-macie-role \
  --operations Decrypt DescribeKey

# 2. その後、ジョブを再実行

---

ベストプラクティス

1. 自動検出を有効化し、定期ジョブで補完

# 自動検出有効化
aws macie2 enable-macie

# 月次のフルスキャンジョブ作成
aws macie2 create-classification-job \
  --job-type SCHEDULED \
  --job-config '{
    "s3JobDefinition": {
      "bucketDefinitions": [
        {"accountId": "111111111111", "buckets": ["prod-data-bucket"]}
      ]
    },
    "scheduleFrequency": "MONTHLY"
  }' \
  --name "MonthlyFullScan"

2. カスタム識別子で自社データパターン検出

# 組織固有のシークレット形式を識別
aws macie2 create-custom-data-identifier \
  --name "APIKeyCompany" \
  --regex "company-api-[a-z0-9]{32}" \
  --keywords ["api_key", "secret_key"] \
  --maximum-match-distance 50

3. Finding優先順位付けと自動通知

# EventBridge でHIGH以上のFindingをキャプチャ
aws events put-rule \
  --name MacieSensitiveDataAlert \
  --event-pattern '{
    "source": ["aws.macie"],
    "detail-type": ["Macie Finding"],
    "detail": {
      "severity": ["HIGH", "CRITICAL"]
    }
  }'

# Lambda で自動修復トリガー（例：通知＋隔離）

4. コスト管理戦略

大規模バケット（1000万オブジェクト以上）の場合：

1. プレフィックスでフィルタリング
   → logs/ フォルダのみスキャン（85%削減も可能）

2. オブジェクトサイズ制限
   → 1MB以上の画像・動画は除外

3. スケジュール頻度調整
   → MONTHLY 推奨（本番）/ QUARTERLY（少量環境）

4. サンプリング活用
   → 初期調査：50%サンプリング
   → 本番：100%スキャン

---

第3部：InspectorとMacieの連携パターン

Security Hub統合

InspectorのFindingをSecurity Hub へ送出

# Security Hub有効化
aws securityhub enable-security-hub \
  --region us-east-1

# Inspector Finding 自動同期（設定不要）
# → SecurityHubのInsights画面で一元表示

Macieのビデータ

Macieの機密データ Finding も同じく Security Hub へ統合。

# Security Hub で Macie Findings フィルタリング
aws securityhub get-findings \
  --filters '{
    "ResourceType": [
      {"Value": "AwsMacie", "Comparison": "EQUALS"}
    ],
    "SeverityLabel": [
      {"Value": "CRITICAL", "Comparison": "EQUALS"}
    ]
  }' \
  --region us-east-1

Security Hub での可視化

+---------------------------------------------+
|  Security Hub - All Findings               |
+---------------------------------------------+
| Inspector Findings (脆弱性)               |
|  ├─ CRITICAL:    3件 （パッケージ脆弱性） |
|  ├─ HIGH:       15件 （ネットワーク到達） |
|  └─ MEDIUM:     42件 （コード脆弱性）    |
|                                            |
| Macie Findings (機密データ)                |
|  ├─ CRITICAL:    1件 （クレジットカード） |
|  └─ HIGH:        8件 （社員ID）          |
|                                            |
| 他のサービス Finding                      |
+---------------------------------------------+

---

EventBridge → Lambda 自動修復パターン

パターン1：Inspector CRITICAL脆弱性の自動通知・隔離

// Lambda Function
const AWS = require('aws-sdk');
const ec2 = new AWS.EC2();
const sns = new AWS.SNS();

exports.handler = async (event) => {
  const finding = event.detail;
  
  if (finding.severity === 'CRITICAL') {
    const instanceId = finding.resources[0].id;
    
    // 1. インスタンスをセキュリティグループ隔離
    await ec2.modifyInstanceAttribute({
      InstanceId: instanceId,
      Groups: ['sg-isolated'] // 隔離用SG
    }).promise();
    
    // 2. SNS通知
    await sns.publish({
      TopicArn: process.env.ALERT_TOPIC_ARN,
      Subject: `CRITICAL Inspector Finding - Instance Isolated`,
      Message: JSON.stringify(finding, null, 2)
    }).promise();
    
    // 3. Slack通知（オプション）
    // ... WebhookでSlack通知
  }
};

EventBridge ルール設定：

aws events put-rule \
  --name InspectorCriticalResponse \
  --event-pattern '{
    "source": ["aws.inspector2"],
    "detail-type": ["Inspector2 Finding"],
    "detail": {
      "severity": ["CRITICAL"]
    }
  }'

aws events put-targets \
  --rule InspectorCriticalResponse \
  --targets "Id=1,Arn=arn:aws:lambda:region:account:function:IsolateInstance"

---

パターン2：Macie 機密データFinding → S3ブロック

// Lambda: 機密データ検出時にS3オブジェクトをプライベート化
const AWS = require('aws-sdk');
const s3 = new AWS.S3();
const macie2 = new AWS.Macie2();

exports.handler = async (event) => {
  const finding = event.detail;
  
  if (finding.type === 'Policy:PrincipalPolicy/S3-ManagedData') {
    const bucket = finding.resources[0].s3BucketName;
    const key = finding.resources[0].s3ObjectKey;
    
    // 1. ACL を Private に変更
    await s3.putObjectAcl({
      Bucket: bucket,
      Key: key,
      ACL: 'private'
    }).promise();
    
    // 2. PublicAccessBlock 強制
    await s3.putBucketPublicAccessBlock({
      Bucket: bucket,
      PublicAccessBlockConfiguration: {
        BlockPublicAcls: true,
        BlockPublicPolicy: true,
        IgnorePublicAcls: true,
        RestrictPublicBuckets: true
      }
    }).promise();
    
    // 3. 監査ログ記録
    console.log(`Remediated: s3://${bucket}/${key}`);
  }
};

---

Organizations統合時の運用フロー

運用での注意点：

1. 委任管理者は Inspector/Macie有効化が必須
2. メンバーアカウント は 有効化されなくても検査対象
3. Finding の削除権限は委任管理者にのみ
4. メンバーアカウントはローカル設定を上書きしてはいけない

---

統合ダッシュボード構築例

# AWS CloudWatch で統計情報を集約
aws cloudwatch put-metric-alarm \
  --alarm-name InspectorCriticalFindings \
  --metric-name CriticalFindings \
  --namespace AWS/Inspector \
  --statistic Sum \
  --period 3600 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:region:account:AlertTopic

CloudWatch Dashboard JSON 例：

{
  "widgets": [
    {
      "type": "metric",
      "properties": {
        "metrics": [
          [ "AWS/Inspector", "CriticalFindings" ],
          [ ".", "HighFindings" ],
          [ "AWS/Macie", "SensitiveDataDetections" ]
        ],
        "period": 300,
        "stat": "Sum",
        "region": "us-east-1",
        "title": "Security Posture"
      }
    }
  ]
}

---

試験攻略ポイント

頻出問題パターン

パターン1：「スキャン対象の正確な理由付け」

問題例：

Q. InspectorがRDSの脆弱性をスキャンできない理由として
   最も正しいものは？

A. RDS はマネージドサービスで、AWS側で
   脆弱性パッチを管理しているため
   
（正解：A）

落とし穴： 「設定不可」ではなく「マネージドだから」が正解。

---

パターン2：「Organizations統合での権限範囲」

問題例：

Q. Inspectorの委任管理者がメンバーアカウントで
   実行可能なアクション は？

A. メンバーのFinding を修復（削除）できる
B. メンバーの抑制ルール を作成できる
C. メンバーのEC2スキャン設定 を変更できる
D. メンバーのFinding を読取専用で表示できる

（正解：D）

要点： 委任管理者は「可視化」だけ。修復権限なし。

---

パターン3：「カスタム識別子の正規表現」

問題例：

Q. Macieで社員番号「EMP000001〜EMP999999」のみを
   検出するカスタム識別子の正規表現として
   最も適切なものは？

A. EMP[0-9]*
B. EMP[0-9]{6}
C. EMP[0-9]+
D. EMP[0-9]{1,6}

（正解：B）

要点： {6} は「正確に6桁」。* や + は過度にマッチ。

---

よくある間違い

---

実装チェックリスト

組織全体でInspector + Macieを導入する際の確認項目：

[ ] 全リージョンでInspector有効化
[ ] EC2の SSM Agent インストール確認
[ ] ECRスキャンの CI/CD ゲート設定
[ ] Macie 自動検出有効化
[ ] 月次スケジュール型ジョブ作成
[ ] カスタムデータ識別子 3〜5個定義
[ ] Security Hub 統合確認
[ ] EventBridge ルール（CRITICAL通知）設定
[ ] Lambda 自動修復関数デプロイ
[ ] Organizations 委任管理者設定
[ ] CloudWatch ダッシュボード構築
[ ] コスト監視アラーム設定
[ ] 月次 Finding レビュープロセス定義
[ ] 四半期ごとのカスタム識別子見直し予定
[ ] インシデント対応ドキュメント作成

---

参考リンク・公式ドキュメント

• Amazon Inspector ユーザーガイド
• Amazon Macie ユーザーガイド
• AWS Security Best Practices
• SCS-C03 公式ガイド

---

まとめ

Inspector と Macie は、脆弱性と機密データという「セキュリティの二大脅威」を自動検出するAWSの目玉機能です。

• Inspector v2：エージェントレス、EC2/ECR/Lambda対応、ネットワーク到達可能性判定
• Macie：S3専任、カスタム識別子で自社パターン検出、Organizations統合

SCS-C03では、「何ができるか」だけでなく「何ができないか・制約は何か」が重大な採点基準。特に Organizations統合での権限スコープ、エージェント依存性、スキャン対象の正確な理解が試験合格のカギになります。

実装の際は、自動化（EventBridge + Lambda）とコスト管理を両立させることで、真の「自走セキュリティ」が実現できます。