はじめる前に
- 必須AWS アカウントを持っていること
- 必須マネジメントコンソールにサインインできること
- 必須S3バケットの作成・バケットポリシーの編集をしたことがある
- あると良いIAMポリシー（JSON）を読んだ経験
※ このハンズオンは すべてコンソールだけで完結します。
参照する公式ドキュメント
手順に迷ったときや、用語の意味を確かめたいときに開きましょう。
※ リンク切れの場合は、ページタイトルで検索してください。
背景・シナリオ
S3バケットや IAM ロールなどに、意図せず外部のアカウントや全世界からアクセスできる設定を入れてしまうことは、よくあるミスの1つです。バケットポリシーやリソースベースポリシーは項目が複雑で、設定を見ただけでは「結局どこからアクセスできるのか」がひと目で分かりにくいという問題があります。
IAM Access Analyzer は、こうした「アカウントの外からアクセスできるリソース」を自動的に分析し、検出結果（Finding）として教えてくれるサービスです。今回は、わざと全世界に公開されるバケットポリシーを設定したS3バケットを用意し、Access Analyzer がそれを外部アクセスの検出結果として報告することを確認します。さらにポリシーを修正し、検出結果が解消される様子も確認します。
Access Analyzer はS3だけを見ているの？
いいえ。S3バケットだけでなく、IAMロール、KMSキー、Lambda関数、SQSキューなど、外部アカウントからアクセスできる可能性のある複数のリソースタイプを対象にしています。今回はわかりやすいS3バケットを例に使います。
見つかった検出結果は、自動的に直してもらえるの？
いいえ、検出するだけで自動修正はされません。S3コンソールからは、検出結果の画面でその場で「パブリックアクセスをブロック」を適用できる場合がありますが、ポリシーの内容自体は自分で見直して修正する必要があります。意図した公開であれば「アーカイブ」として記録することもできます。
アカウント用のアナライザーを作成し、外部公開を許可するバケットポリシーを設定したS3バケットについて、IAM Access Analyzer が「外部アクセス」の検出結果を報告することを確認したうえで、ポリシーを修正して検出結果が解消されることを確認する。
つくる構成
同じS3バケットのまま、バケットポリシーを変更する前後で、外部からのアクセス可否とAccess Analyzerの検出結果がどう変わるかを比較します。
誰でもオブジェクトを読める状態
外部からの読み取りを許可しない
※ IAM Access Analyzer はポリシーの変更を継続的に分析しており、反映には数分かかることがあります。
要件
以下の要件を満たし、「検出される」→「直す」→「検出結果が解消される」という変化を確認してください。
| No | 要件 |
|---|---|
| 1 | リージョンは「東京（ap-northeast-1）」を使用する。 |
| 2 | IAM Access Analyzerで、ゾーンタイプ「アカウント」のアナライザーを1つ作成する（名前は自由、例：account-analyzer）。 |
| 3 | テスト用のS3バケットを1つ作成する（名前は一意に、例：access-analyzer-demo-yourname）。中に適当なテストファイルを1つアップロードしておく。 |
| 4 | バケットの「パブリックアクセスをブロック」設定を一部解除し、Principalを *（全世界）として s3:GetObject を許可するバケットポリシーを設定する。 |
| 5 | Access Analyzerの検出結果一覧に、このバケットに対する「外部アクセス」の検出結果（アクティブ）が表示されることを確認する。 |
| 6 | バケットポリシーを削除し、パブリックアクセスのブロック設定を元に戻したうえで、同じ検出結果が「アーカイブ済み」に変わることを確認する。 |
構築の進め方
「アナライザーを作る」→「わざと公開して検出される」→「直して解消される」という順番で進めます。
- フェーズ1 — アナライザーを作成する
-
マネジメントコンソールにサインインし、リージョンを合わせる
ブラウザで AWS マネジメントコンソールにサインインし、画面右上のリージョンが「アジアパシフィック（東京）ap-northeast-1」になっていることを確認します。
-
IAM Access Analyzerでアナライザーを作成する
IAMコンソールの左メニュー「Access Analyzer」を開き、「分析機能の作成」を選びます。ゾーンタイプは「アカウント」を選び、名前を自由に決めて作成します（例：
account-analyzer）。作成すると自動的に分析が始まるアナライザーを作成すると、アカウント内の対象リソース（S3、IAMロールなど）のポリシーが分析され、その後も継続的に再分析されます。手動でスキャンを実行する必要はありません。
- フェーズ2 — わざと公開して検出される
-
テスト用のS3バケットを作成する
S3コンソールでバケットを1つ作成します（名前は一意に、例：
access-analyzer-demo-yourname）。中に適当なテストファイルを1つアップロードしておきます。 -
パブリックアクセスのブロックを一部解除する
バケットの「アクセス許可」タブで「パブリックアクセスをブロック（バケット設定）」を編集し、「新しいパブリックバケットポリシーまたはアクセスポイントポリシーを介したパブリックアクセスとクロスアカウントアクセスをブロックする」のチェックを外します。
学習目的の一時的な操作この設定はバケットポリシーによる公開を許可するためのものです。検証が終わったら、フェーズ3で必ず元に戻します。
-
全世界に読み取りを許可するバケットポリシーを設定する
「アクセス許可」タブの「バケットポリシー」に、
Principalを*、アクションをs3:GetObjectとして許可するポリシーを設定します。 -
Access Analyzerの検出結果を確認する
IAMコンソールの「Access Analyzer」→「検出結果」を開きます。少し時間が経つと、作成したバケットに対する外部アクセスの検出結果（ステータス：アクティブ）が表示されます。詳細を開き、どの外部プリンシパル（今回は「すべての人」）に、どのアクセス権が付与されているかを確認します。
反映には数分かかることがあるポリシーを変更してから検出結果に反映されるまで、数分程度かかることがあります。すぐに表示されない場合は、少し待ってから一覧を更新してみましょう。
- フェーズ3 — 直して解消される
-
バケットポリシーを削除する
「アクセス許可」タブの「バケットポリシー」を編集し、先ほど設定した内容を削除します。
-
パブリックアクセスのブロックを元に戻す
フェーズ2で解除した「パブリックアクセスをブロック（バケット設定）」のチェックを、すべて元のオン（ブロックする）の状態に戻します。
-
検出結果が解消されることを確認する
もう一度「Access Analyzer」→「検出結果」を開きます。しばらくすると、対象の検出結果のステータスが「アーカイブ済み」に変わっていることを確認します。
これがゴール同じ検出結果が「アクティブ」から「アーカイブ済み」に変わる——この変化を確認できたら、このハンズオンの目的は達成です。
つまずきポイント
初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直すか」の手がかりとして使ってください。
「ポリシーを設定したのに、Findingが出てこない」
「パブリックアクセスをブロック」の設定が有効なままだと、バケットポリシーの内容に関わらず実際には公開されないため、検出結果も生成されません。バケットレベルの設定を見直しましょう。
「修正したのに、まだアクティブと表示される」
Access Analyzerの再分析には数分程度かかることがあります。すぐに反映されない場合は、少し時間を置いてから一覧を更新してみましょう。また、ポリシーの削除や設定変更が実際に保存されているかも見直しましょう。
完了チェック
要件の再確認ではなく、画面のどこを見れば達成を確認できるかをまとめました。次を順に確かめましょう。
- IAMコンソールの「Access Analyzer」一覧に、作成したアナライザーが「アクティブ」と表示されている。
- バケットポリシーを公開状態に設定した後、「検出結果」一覧に対象バケットの外部アクセスFindingが「アクティブ」として表示される。
- ポリシーを修正し、パブリックアクセスのブロックを戻した後、同じFindingが「アーカイブ済み」になっている。
- S3バケットの「アクセス許可」タブで、パブリックアクセスがすべてブロックされた状態に戻っている。
考えてみよう
手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。
- バケットポリシーのJSONを見ただけでは、「外部に公開されているか」がなぜ分かりにくいのでしょうか。
ヒント
ポリシーは複数のステートメント（条件）が組み合わさってできています。Principal・Action・Condition・パブリックアクセスのブロック設定など、複数の要素を同時に読み解く必要がある、という点がヒントです。 - 静的ウェブサイトホスティングのように、意図的に外部公開しているS3バケットがある場合、Access Analyzerの検出結果をどう扱うべきでしょうか。
ヒント
意図した公開であれば、毎回「問題あり」として通知され続けるのは運用上望ましくありません。検出結果を「アーカイブ」として記録する機能が、どんな場面のために用意されているか考えてみましょう。 - S3以外に、Access Analyzerが外部アクセスの対象とするリソースにはどんなものがありそうでしょうか。なぜそれらが対象になるのでしょうか。
ヒント
「リソースベースのポリシーを持ち、他のAWSアカウントや外部のプリンシパルに権限を付与できるリソース」という共通点で考えてみましょう。IAMロールの信頼ポリシーなどが一例です。
後片づけ
作成したリソースを順番に削除します。
- S3バケットを空にして削除する：バケットの中のオブジェクトをすべて削除してから、バケット本体を削除します。
- アナライザーを削除する（必要であれば）：継続的に学習で使う予定がなければ、IAMコンソールの「Access Analyzer」から削除します。残しておいても料金はかかりません。
検証用に解除した設定は、検証後に必ず元に戻す
フェーズ2で一時的に解除した「パブリックアクセスをブロック」の設定は、バケットを削除する場合でも、先に元の状態に戻しておくことをおすすめします。誤って別の検証で同じバケット名を使い回した際に、公開状態のまま忘れてしまうことを防げます。
コストに関する注意: 今回作成する「アカウント用」の外部アクセスアナライザーには料金はかかりません。（IAMロールの未使用アクセス分析など、一部の追加機能には別途料金がかかる場合があります。）S3の保存容量・リクエストには料金がかかりますが、少量のテストファイルであれば無料利用枠の範囲内に収まることが多いです。IAM・バケットポリシー自体に料金はかかりません。検証が終わったら、上の「後片づけ」に沿って公開設定を元に戻し、バケットを削除しましょう。最新の料金は AWS の公式料金ページで確認してください。