Access Analyzer — 「外から見えてますよ」を自動で教える
IAM Access Analyzer、Trusted Advisor、Audit Managerを講義形式で解説
セキュリティの盲点を見つけ出すツール群についてお話しします。
AWS のセキュリティ設定は非常に複雑です。IAM ロール、バケットポリシー、キーペア、セキュリティグループ。これらを設定していると、「実は外から見えていた」「権限が多すぎた」という気づきが往々にして遅れます。「気づいた時には既に 3 ヶ月前からアクセスされていた」という事例は珍しくありません。
これらの盲点を見つけ出し、継続的に監視するのが、IAM Access Analyzer、Trusted Advisor、AWS Audit Manager です。
Access Analyzer — Zone of Trust という概念
一番重要な概念から。「Zone of Trust」って何か。Zone of Trust = 信頼できる範囲。デフォルトは「自分のアカウント内」。その外からのアクセスを検出するのが Access Analyzer。
S3 バケットポリシーで「他のアカウントからのアクセス許可」してたら Finding 発生。IAM ロール の信頼ポリシーで「フェデレーション IDP からの AssumeRole」許可してたら Finding 発生。
外部アクセスの検出——Finding の種類
いくつかパターンあります。
Public：インターネット全体（Principal: *）にアクセス許可。最も危険。
Cross-Account：他の AWS アカウントにアクセス許可。ビジネスパートナーとの連携なら OK。でも「どの AWS アカウント？」を明確にする必要。
AWS Service：AWS サービスプリンシパル（例：Lambda、EC2）にアクセス許可。これ自体は悪くないが、権限の粒度を確認。
Federated：外部 IdP（Okta、Auth0 など）のユーザーに AssumeRole 許可。これも事業要件で OK / NG が分かれます。
対応リソースと制限
Access Analyzer が分析できるリソース：
- S3 Bucket ポリシー
- IAM Role（信頼ポリシー）
- KMS Key ポリシー
- Lambda リソースベースドポリシー
- SQS、SNS
できない：
- VPC Security Group
- Network ACL
- CloudFront Distribution
- API Gateway（一部）
- Route 53
つまり、「リソースベースドポリシー」に限定されてます。
未使用アクセス分析（Unused Access）
これ強力。CloudTrail の過去90日ログをベースに「使われていない権限」を検出。
例えば、アシスタント用の IAM ユーザーに「S3 DeleteBucket 権限」がついてるけど、3ヶ月使ってない——Finding 発生。
つまり、「権限の棚卸し→削減」が自動化されます。セキュリティ原則「最小権限」を実現できます。
ポリシー生成（Policy Generation）
これ試験で狙われます。
CloudTrail から「ユーザーが実際に実行したアクション」を抽出。それを IAM ポリシーの形に自動変換。
重要：生成されたポリシーに Deny は含まれません。Allow のみ。つまり「ユーザーが実行できた操作」だけから推測。失敗した操作は含まれない——ここ注意。
ポリシー検証（Policy Validation）
新しいポリシーをデプロイする前にセキュリティチェック。ポリシーを検証すると「SECURITY_WARNING: ワイルドカード過度使用」と警告。
アーカイブルール
既知のクロスアカウントアクセスとか「これは許可されるべき」なケースを自動非表示化。
例えば「会計部門の専用アカウント XXX からだけ S3 アクセス許可」って場合、そいつを自動アーカイブ。ノイズ除外。
組織での委任管理者
複数アカウント環境なら、Organization 管理アカウントから「Security Account」を委任管理者に指定。
Security Account が全メンバーアカウントの リソースアクセスを一元監視。スケーラビリティ確保。
Trusted Advisor — セキュリティチェック一覧
Core Checks（すべてのプランで利用可）：
- MFA on AWS Account Root User
- Security Groups - Specific Ports Unrestricted（22, 3306, 5432 等）
- IAM Access Key Rotation（90日未更新）
- CloudTrail Logging
Full Checks（Business/Enterprise Support 限定）：
- EBS Encryption
- RDS Encryption
- S3 Bucket Permissions（パブリックアクセス）
- IAM Policy Check（過度に Permissive）
Core Checks の実例
MFA on Root：「ルートユーザーに MFA が有効か」。リスク最高。
IAM Access Key Rotation：「アクセスキーが90日以上未更新」。これも高リスク。
CloudTrail Logging：「CloudTrail が有効か」。監査証跡の確保。
これらが赤い WARNING 状態だったら、即座に対応。
API で Trusted Advisor を自動化
AWS Support API を使って、Trusted Advisor チェック結果をプログラム的に取得します。
結果を EventBridge で検知して、Lambda で Slack 通知——完全自動化。
Audit Manager — コンプライアンス評価
これは「監査業務の自動化」。PCI DSS、GDPR、SOC 2 などフレームワーク別に、コンプライアンス評価を実施。
対応フレームワーク
CIS AWS Foundations Benchmark：一般的なセキュリティベスト・プラクティス。
PCI DSS v3.2.1：決済関連。クレジットカード扱う事業者は必須。
GDPR：EU 顧客データ。厳格。
SOC 2：SaaS 提供企業向け。
HIPAA：医療。
FedRAMP Moderate：米国政府契約。
自動エビデンス収集
Config Rules、CloudTrail、Security Hub から自動的に「証拠」を集めます。
例えば「S3 バケットは暗号化されているか？」という項目なら：
- Config Rule で「暗号化状態」を確認
- CloudTrail で「暗号化を設定した」という操作ログ
- Security Hub の findings で「問題なし」確認
これら3つ自動集約。
評価実施・レポート生成
Audit Manager が自動評価を実施。その結果を「法的に有効な監査レポート」に変換。
月次レポートを経営層に報告。外部監査対応時も、このレポートを提出。
まとめ
Access Analyzer で外部アクセスを検出。Trusted Advisor でセキュリティベストプラクティスをチェック。Audit Manager でコンプライアンス評価——この三つの組み合わせで、セキュリティポスチャーが可視化されます。
IAM Access Analyzer — 「外部アクセス権限の自動検出」
IAM Access Analyzer は、シンプルに言うと、あなたの AWS リソースが誰に見えているのかを自動的に教えてくれるツールです。
例えば、S3 バケットを作成し、バケットポリシーで「外部アカウントの特定ユーザーに読み取り許可」と設定したとします。その時点では「大丈夫だろう」と思われ、細かく確認されません。ですが 3 ヶ月後、そのユーザーのアカウントが実は不要になっていたことに気づくような状況があります。つまり、3 ヶ月間、不要なアカウントがアクセス可能な状態だったわけです。
Access Analyzer は、このような権限設定の「気づき遅れ」を防ぎます。その仕組みが Zone of Trust の概念です。
AWS アカウント作成時に、「このアカウント内 = 信頼できるゾーン」「このアカウント外 = 信頼できないゾーン」が定義されます。Access Analyzer は Zone of Trust の境界を監視し、外部ユーザーへの権限付与を自動検出します。「このバケットポリシーは Zone of Trust 外のアカウントに読み取り権限を与えている」「この KMS キーは Zone of Trust 外のロールに復号化権限を与えている」「この Lambda は Zone of Trust 外から呼び出し可能」といった外部アクセスが全て可視化されます。
外部アクセスの可視化
では、Access Analyzer を有効化したら、何が見えるようになるんですか？
AWS コンソールを開くと、Access Analyzer のダッシュボードが現れます。
そこには——
「あなたの AWS リソースのうち、Zone of Trust の外からアクセス可能なもの：全部」
——が、リスト化されてるんです。
例えば——
S3 バケット「my-bucket」: 外部アカウント「123456789012」に s3:GetObject を許可している KMS キー「arn:aws:kms:…」: 外部アカウント「999888777666」に kms:Decrypt を許可している Lambda「my-function」: ルートアカウント「*」（つまり、誰でも）に lambda:InvokeFunction を許可している
——こんな感じで、全部が見える。
そしてね、それぞれに対して「これ、ほんとに外部に見えてても大丈夫？」ってチェックができるんです。
「あ、これは確認済み。取引先だから OK」——にマークを付けるとか。
「あ、これはやばい。即座に削除しよう」——修正するとか。
Zone of Trust の境界にある権限 = セキュリティリスク候補。可視化して、1つずつ検証する。
未使用権限の自動分析
別の視点から考えてみましょう。IAM ロールを作成するとき、「この EC2 DBA タスク用ロールは EC2 と RDS に必要だし、ついでに CloudWatch Logs にも権限を付けよう」という判断をします。運用開始後、3 ヶ月経ったとき、実は CloudWatch Logs には一度も アクセスされていないことに気づくような状況があります。
これはセキュリティの観点から問題です。最小権限の原則に違反しています。IAM ロールは「必要な権限だけ」を持つべきです。使わない権限を持っていると、万が一その権限が悪用された場合、被害が拡大する可能性があります。
Access Analyzer の未使用権限分析がこれを解決します。CloudTrail（実際のアクセスログ）と IAM ポリシー（付与権限）を比較して、「DBA-Task ロールには以下の権限が付与されているのに、過去 90 日間使用されていません：logs:CreateLogGroup、logs:CreateLogStream、logs:PutLogEvents」とレポートします。これを確認して、不要な権限をポリシーから削除できるわけです。
金融機関では、Access Analyzer の未使用権限分析を使って、2,000 以上の不要な権限を削除し、セキュリティリスク面積を 40% 削減した事例があります。
カスタム分析期間
ちょっと実務的な話になります。
「過去 90 日間」って言いましたけど、これ固定じゃないんです。
Organization のセキュリティ方針で「権限の未使用期間は 180 日以上なら削除」って決めてたら、Access Analyzer にそう設定できるわけです。
で、以下の質問が出ます。
「あ、でも新しいロールをね、作ったばっかりだと、使用履歴がないから、全部『未使用』判定されちゃうんじゃ？」
その通り。だからね、「新規ロールを除外する」設定とか、「特定の権限は除外する」設定とか——実務的な調整ができるようになってるんです。
IAM ポリシー自動生成
ここからが、本当に面白い。
あなたが新しいアプリケーションを書きました。EC2 で走ります。
で、そのアプリケーションが何をするか——
S3 から設定ファイルを読む RDS にデータを書く CloudWatch Logs に実行ログを出す
——こういう処理をするわけです。
では、このアプリケーション用の IAM ロールのポリシーは——何に設定するべきか？
経験則では、「まあ、S3、RDS、CloudWatch のアクセス権があればいいだろう」って——ざっくり決めちゃうんですよ。
でもね、実務的には——
「このロールは S3 のこのバケットの、このプレフィックス配下のファイルだけ読める」 「RDS のこのデータベースの、このテーブルだけ書き込める」 「CloudWatch Logs のこのロググループにだけ書き込める」
——こういう細粒度の権限が必要なわけです。
でもね、これ、手で書くのは面倒なんですよ。
ここで Access Analyzer が登場します。
Access Analyzer は、あなたのアプリケーションが実際にアクセスしたログを見て、必要な権限を自動生成できるんです。
例えば——
- アプリケーション用の IAM ロールを作る（一旦、権限なし）
- アプリケーションを実行する
- 失敗します。「Permission denied」
- Access Analyzer にね、「こいつが失敗したアクセスログを見て、必要なポリシー生成して」って言う
- Access Analyzer がね、失敗したアクセスを分析して——「以下の権限があれば動きます」ってポリシーを自動生成
その生成されたポリシーをロールにアタッチすれば——アプリケーションが正常に動く。
最小権限自動化 = ログから学習し、必要な権限だけを自動生成する
これ、本当に革命的なんですよ。なぜなら——
従来のやり方： 「とりあえず s3: と rds: と logs:* をアタッチしとこう」 → セキュリティリスクが大きい
新しいやり方： 「実際に何をするか見てから、必要な権限だけを自動生成」 → 最小権限の原則を自動で満たす
Trusted Advisor — 「AWS 全体の健全性チェック」
では、Access Analyzer で権限関連は整理されました。では、他のセキュリティリスクはどうするんですか？
Trusted Advisor があります。
これはね——AWS が提供する、「AWS 環境全体の健全性チェック」なんです。
例えば——
「セキュリティグループが、ポート 22（SSH）を全世界に開いてますね」——検出します。
「S3 バケットがパブリック公開されてますね」——検出します。
「CloudTrail が無効化されてますね」——検出します。
「EC2 の EBS 暗号化が有効化されていないですね」——検出します。
こんな感じで、セキュリティ、コスト、性能、耐障害性——複数の観点から、AWS 環境をチェックしてくれるんです。
Trusted Advisor の3段階
Trusted Advisor には、サポートプランに応じて、チェック項目の数が変わります。
無料版（AWS Basic Support）： 6 個の基本的なチェック（セキュリティグループ、EBS 暗号化、など） リアルタイムじゃなく、週1回のチェック
Business / Enterprise Support： 100+ のチェック項目 リアルタイムチェック AWS Lambda と連携してアラーム設定
つまり、本気でセキュリティを運用するなら——Business Support 以上が実質必須なんですよ。無料版は、あくまで「最低限の安全弁」程度のイメージ。
Audit Manager — 「コンプライアンス証跡の自動収集」
さあ、ここからが実は一番大事な話なんです。
セキュリティが重要なのは、誰でも知ってます。でもね、実は企業運用では——コンプライアンスが最重要課題なんですよ。
例えば、金融機関なら SOC 2。医療業界なら HIPAA。——こういう規制基準に対して、「うちは準拠してますよ」ってね、証拠を示す必要があるんです。
「証拠」って何ですか？
ログです。記録です。「このポリシーがあります」「このアクセス制御があります」「このアラームが設定されています」——こういう「证拠」を、監査人に提示する必要があるわけです。
で、これを手で集めるのは——大変ですよ。
CloudTrail を見たり、Config を見たり、CloudWatch を見たり、IAM を見たり——いろんなところから、「コンプライアンスに関連する情報」を集めてくる。
そこで登場するのが——AWS Audit Manager です。
これはね——
コンプライアンス基準（SOC 2、HIPAA、など）に必要な証拠を、全自動で収集・整理する。
例えば、あなたが Audit Manager で「SOC 2 のコンプライアンス監査を実施したい」って言うと——
Audit Manager はね、自動的に——
CloudTrail のログを見て、「アクセス制御の証拠」を集める Config のレポートを見て、「リソース設定の証拠」を集める CloudWatch Logs を見て、「監視ログの証拠」を集める Systems Manager を見て、「パッチ管理の証拠」を集める
——全部、自動で集めてくれるんです。
そして、「SOC 2 のコンプライアンスレポート」を自動生成する。
監査人に「はい、ここが証拠です」って提示できる。
コンプライアンス運用 = 手作業から自動化へ。証拠収集は機械がやる。
Audit Manager の実務的な側面
ちょっと実務的に。
Audit Manager を使うには、まず——Assessment（評価）を作ります。
例えば「SOC 2 Type II の評価」みたいなやつ。
すると、Audit Manager はね、「以下の証拠を集める必要があります」って、要件をリスト化するんです。
で、那些個別の要件に対して——
「この CloudTrail ログが該当する」 「このセキュリティグループ設定が該当する」 「このカスタム証拠（例：表計算シート）が該当する」
——こんな感じで、1つずつ「どの証拠が該当するか」を登録していくわけです。
そうするとね、最後に——完成したコンプライアンスレポートが生成される。
それを監査人に提示すれば——
「はい、以下の証拠で、SOC 2 の要件を満たしていることが証明されます」
——って説明できるわけです。
まとめ：セキュリティから運用へ
では、3つのツールをまとめます。
IAM Access Analyzer： Zone of Trust の外からのアクセスを検出 未使用権限を自動分析 必要な権限を自動生成
Trusted Advisor： AWS 環境全体の健全性を定期チェック セキュリティ、コスト、性能の観点から問題検出
Audit Manager： コンプライアンス基準に必要な証拠を自動収集 監査報告書を自動生成
これらが、セキュリティから運用へ向かう流れを作ってるんです。
セキュリティって、「ルールを決める」だけじゃなくて——
- 検出（Access Analyzer）：リスクや問題を見つける
- 検証（Trusted Advisor）：環境全体が安全かチェック
- 証明（Audit Manager）：コンプライアンスを立証する
——この3つが、循環して、初めて「安心な運用」が成り立つんですよ。
では、次に行きましょう。