AWS Well-Architected Framework 入門：セキュリティの柱を IAM + MFA + GuardDuty でハンズオンを作成・実践してみた

はじめに

こんにちは。クラスメソッドオペレーションズの藤瀨です。

Well-Architected Framework ハンズオンシリーズの第 3 回です。

• 第 1 回 Well-Architected Framework の概要
• 第 2 回 オペレーショナルエクセレンスの柱

今回はセキュリティ（Security）の柱に基づいて筆者が作成したハンズオンを行います。

この柱が扱うのは、クラウド技術を活用してデータ・システム・資産を保護しながら、セキュリティ体制を継続的に高めていく仕組みづくりです。

本記事では、以下の 4 つの内容をハンズオン形式で確認します。

• 最小権限の IAM ポリシー設計と、IAM ポリシーシミュレーターによる検証
• IAM Access Analyzer による意図しない外部公開の検知
• IAM ユーザーの MFA 設定状況の確認
• Amazon GuardDuty による脅威検知

本記事は、AWS マネジメントコンソールの基本操作を経験したことがある初学者を対象としています。IAM、S3、GuardDuty の詳細な運用設計までは扱いません。

セキュリティとは

はじめに、セキュリティの柱の概要を整理します。
AWS Well-Architected Framework では、セキュリティの柱をクラウド技術を活用してセキュリティ体制を改善しながら、データ、システム、資産を保護する能力と説明しています。

この柱には 7 つの設計原則があります。

• 強力なアイデンティティ基盤を実装する: 最小権限の原則を徹底し、職務を分離し、長期的な固定認証情報への依存をなくす
• トレーサビリティの維持: 環境への操作や変更をリアルタイムで監視・記録・監査する
• すべての層にセキュリティを適用する: ネットワークの境界から OS、アプリ、コードまで多層的に防御する
• セキュリティのベストプラクティスを自動化: 統制をコードとして定義・管理し、安全に素早くスケールする
• 転送中・保管中のデータを保護する: データを機密度で分類し、暗号化やアクセス制御を適切にかける
• 人をデータから遠ざける: 直接アクセスや手作業の処理を減らし、誤操作・誤取扱いのリスクを下げる
• セキュリティイベントの準備: インシデント対応の体制と手順を整え、模擬訓練を通じて対応速度を上げる

今回のハンズオンでは、この中でも「強力なアイデンティティ基盤を実装する」（最小権限の IAM ポリシーと MFA）と「トレーサビリティの維持」（GuardDuty）、そして「セキュリティのベストプラクティスを自動化」（IAM Access Analyzer による公開設定の自動検知）という観点を中心に体感していきます。

具体的な手順

大まかな手順は以下の通りです。

1. 最小権限の IAM ポリシーを設計して IAM ユーザーにアタッチする
2. IAM Access Analyzer で外部共有をチェックする
3. IAM ユーザーの MFA 設定状況を確認する
4. GuardDuty を有効化する

ステップ 1 とステップ 2 の題材として、今回は IAM ポリシーの動作を学ぶため、検証用の IAM ユーザーに権限を付与します。

ただし、実環境で人が AWS にアクセスする場合は、IAM ユーザーではなく、AWS IAM Identity Center または外部 IdP を利用し、一時的な認証情報を使用することが推奨されています。

前提条件

このハンズオンを行う前に、以下を確認しておくことをおすすめします。

• 検証用に用意した AWS アカウントで実施し、本番環境では行わないこと
• 作業する AWS リージョンをステップごとに統一すること（IAM Access Analyzer や GuardDuty はリージョンサービスです）
• IAM ポリシーやユーザーの作成・削除、S3 バケットの作成・設定変更、GuardDuty の有効化・無効化に必要な IAM 権限があること
• AWS Organizations に参加している場合、サービスコントロールポリシー（SCP）などによって一部の操作が制限される可能性があること
• S3 の使用量や GuardDuty の無料トライアル終了後など、条件によっては料金が発生する可能性があること

① 最小権限の IAM ポリシーを設計して IAM ユーザーにアタッチする

1. AWS マネジメントコンソール上部の検索ボックスで S3 を検索してクリックします。［バケットを作成］画面で、任意のバケット名を入力し、これ以降の手順で IAM Access Analyzer を作成するリージョンと同じ AWS リージョンを選択します。「パブリックアクセスをすべてブロック」はチェックを入れた状態（デフォルト）のまま作成します。

2. バケットの中に、内容を「This is a public test file.」など、公開しても問題のない固定文字列だけを記載したテキストファイルをアップロードします。個人情報や実在するファイル名・メタデータを含めないでください。

3. 検索ボックスで IAM を検索してクリックします。
4. ページ左側のナビゲーションペインで「ポリシー」を選び、［ポリシーを作成］を押下します。「JSON」タブに切り替えて、以下の最小権限ポリシーを貼り付けます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListTargetBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::waf-sec-handson-bucket"
    },
    {
      "Sid": "ReadObjectsInTargetBucket",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::waf-sec-handson-bucket/*"
    }
  ]
}

5. ［次へ］を押下し、ポリシー名を waf-sec-s3-readonly-policy として［ポリシーを作成］を押下します。

6. ページ左側のナビゲーションペインで「ユーザー」を選び、［ユーザーを作成］を押下します。

7. ステップ 1 の「ユーザーの詳細」で、ユーザー名を waf-sec-readonly-user とします。「AWS マネジメントコンソールへのユーザーアクセスを提供する」のチェックは外したままにします。この IAM ユーザーには、コンソールパスワードやアクセスキーを発行しません。そのため、この手順ではポリシーの作成とアタッチまでを確認します。権限の評価結果を確認する場合は、IAM ポリシーシミュレーターなどを利用してください。検証のみを目的として長期アクセスキーを発行することは推奨しません。

8. ステップ 2 の「許可を設定」で「ポリシーを直接アタッチする」を選び、検索ボックスで、先ほど作成した waf-sec-s3-readonly-policy を検索してチェックを入れ、［次へ］を押下します。
   

9. ステップ 3 の「確認して作成」で設定内容を確認し、［ユーザーの作成］を押下します。

10. 作成したポリシーが意図した許可・拒否の判定になるか、IAM ポリシーシミュレーターで検証します。このツールはコンソールの検索ボックスからは見つからない独立した画面で、ブラウザで直接 https://policysim.aws.amazon.com/ にアクセスします。

11. 左側の「Users, Groups, and Roles」で「Users」を選び、先ほど作成した waf-sec-readonly-user を選択します。

12. 「Select service」で「S3」を選び、「Select actions」で許可されているはずの GetObject と ListBucket、許可されていないはずの PutObject と DeleteObject にチェックを入れます。

13. 選択した各アクションの行を展開すると、リソースタイプごとに入力欄が表示されます。ListBucket は「bucket」欄にバケットの ARN（arn:aws:s3:::waf-sec-handson-bucket）を入力し、GetObject・PutObject・DeleteObject は「object」欄にオブジェクトの ARN（arn:aws:s3:::waf-sec-handson-bucket/*）を入力します。「accesspointobject」欄は S3 アクセスポイント経由でアクセスする場合にのみ使う項目で、今回は使用しないため空欄のままにします。
    

14. 画面右上の［Run Simulation］を押下します。「Permission」列に各アクションの判定結果が表示され、GetObject と ListBucket は「allowed」、PutObject と DeleteObject は「denied」となり、最小権限ポリシーが意図通りに機能していることを確認できました。
    

② IAM Access Analyzer で外部共有をチェックする

1. 検索ボックスで IAM を検索してクリックし、ページ左側のナビゲーションペインで「Access Analyzer」を選びます。
2. アナライザー一覧をまず確認します。S3 バケットを作成した AWS リージョンと同じリージョンで、［アナライザーを作成］からゾーンオブトラストを「現在のアカウント」のまま、アナライザー名を waf-sec-external-access-analyzer として作成します。

3. アナライザーを開き、「リソース分析」タブを選びます。検出結果一覧をリソースタイプ AWS::S3::Bucket やリソース名で絞り込み、ステップ 1 で作成した waf-sec-handson-bucket に関する検出結果が出ていないことを確認します。該当する検出結果が表示されなければ、IAM Access Analyzer が分析対象とするリソースベースポリシーなどに、ゾーンオブトラスト外へのアクセスを許可する設定が検出されていないことを確認できます。
   AM Access Analyzer の検出結果が更新されるまで待ってから、検出結果一覧を確認します。バケットポリシーやバケット ACL の変更については、検出結果の生成・更新まで最大 30 分程度かかる場合があります。
   なお、アカウントレベルの S3 Block Public Access 設定も変更した場合、その設定に関連する検出結果の生成・更新には最大 6 時間かかることがあります。
   
   ここまで、アナライザーが有効で、分析結果の更新を待った後も該当する検出結果が表示されていないことから、IAM Access Analyzer が分析対象とする設定において、バケットへのパブリックアクセスまたはゾーンオブトラスト外からのアクセスが検出されていないことを確認できました。
   次は、実際に外部公開した場合に IAM Access Analyzer が検出する様子を確認します。

4. （検証専用アカウントで実施する場合）実際に検出される様子を確認するために、ステップ 1 で作成したバケットを一時的に公開状態にします。S3 の「汎用バケット」から waf-sec-handson-bucket のリンクをクリックします。
5. 「アクセス許可」タブから「パブリックアクセスをすべてブロック」の［編集］を開き、チェックをすべて外して保存します（確認のため confirm の入力を求められます）。

6. 同じ「アクセス許可」タブの「バケットポリシー」→［編集］から、以下のポリシーを貼り付けて保存します。保存時に「このバケットは公開されます」という警告が表示されますが、今回は検証目的なのでそのまま保存します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPublicReadForTest",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::waf-sec-handson-bucket/*"
    }
  ]
}

7. IAM Access Analyzer の検出結果が更新されるまで待ってから、検出結果一覧を確認します。バケットポリシーやバケット ACL の変更が反映されるまで、最大 30 分程度かかる場合があります。
   
8. 確認できたら、バケットポリシーを削除し、「パブリックアクセスをすべてブロック」の 4 つの設定をすべて再度有効にし、［変更の保存］を選択します。

③ IAM ユーザーの MFA 設定状況を確認する

1. IAM コンソールの「ユーザー」一覧画面では、「MFA」列でどのユーザーに MFA デバイスが割り当てられているかをまとめて確認できます。個別のユーザー詳細画面からも、「セキュリティ認証情報」タブの「割り当てられた MFA デバイス」で確認可能です。
2. IAM ユーザーによるロールの引き受けに MFA を要求する場合は、ロールの信頼ポリシーに、例えば次のような Condition が設定されているかを確認します。

"Condition": {
  "Bool": {
    "aws:MultiFactorAuthPresent": "true"
  }
}

あわせて、Principal、sts:AssumeRole の許可、セッション時間など、信頼ポリシー全体が意図した設定になっていることを確認してください。
IAM ユーザーが AWS STS の AssumeRole を使用してロールを引き受ける構成では、この条件を設定することで、MFA 認証済みの一時的な認証情報からの引き受けに制限できます。ただし、IAM Identity Center や外部 IdP を使用する構成では、IdP 側の MFA ポリシーやセッション情報を含め、認証方式に応じて設計してください。

IAM ユーザーに MFA を設定すると、パスワードが漏えいした場合でも、攻撃者が追加の認証要素を所持していなければ、AWS マネジメントコンソールへの不正なサインインを防止できます。

一方、IAM ユーザーの長期アクセスキーを使用した AWS CLI や API の操作には、MFA が自動的に適用されるわけではありません。プログラムによるアクセスにも MFA を要求する場合は、MFA 認証済みの一時的な認証情報を使用し、IAM ポリシーで MFA なしの操作を拒否するなどの設計が必要です。

IAM ユーザーを使用している場合は、MFA デバイスの割り当て状況を定期的に確認してください。あわせて、不要な IAM ユーザーや長期アクセスキーが残っていないかも確認します。

④ GuardDuty を有効化する

1. AWS マネジメントコンソール上部の検索ボックスで GuardDuty を検索してクリックします。GuardDuty をまだ有効化していないアカウントの場合、サービスの概要を紹介する案内画面が表示されます。
2. 案内画面の［今すぐ始める］ボタンを押下します。
3. 「GuardDuty にようこそ」という画面に切り替わるので、内容を確認して［GuardDuty を有効にする］ボタンを押下します。
4. 「GuardDuty が正常に有効になりました。」というメッセージとともに「要約」画面が表示されれば有効化は完了です。その AWS アカウントで GuardDuty を当該 AWS リージョンに初めて有効化する場合、そのリージョンで 30 日間の無料トライアルが開始されます。GuardDuty の初回無料トライアル終了後に新しい保護プランを初めて有効化した場合は、その保護プランに個別の無料トライアルが適用されることがあります。なお、オンデマンドマルウェアスキャンなど、一部の機能は 30 日間の無料トライアルの対象外です。

5. サンプル検出結果を試します。ページ左側のナビゲーションペインを下にスクロールして「設定」を選び、「サンプル検出結果」セクションの「サンプル検出結果の生成」を押下します。［検出結果］画面から、複数種類のサンプル検出結果を確認できます。サンプルの検出結果には [例] のプレフィックスが表示されます。
   

一覧画面から任意のタイトルをクリックすることで、その検出結果の詳細情報を確認できます。

使用したサービスと料金の考え方

今回使用したサービスの料金の考え方は以下の通りです。

クリーンアップ

検証が終わったら、以下の項目を確認してリソースを片付けてください。

• バケットポリシーを削除する
• S3 Block Public Access を再度有効化する
• テストオブジェクトとバケットを削除する
• 検証用 IAM ユーザーとカスタマー管理ポリシーを削除する
• 不要であれば Access Analyzer を削除する
• GuardDuty を一時停止または無効化する
• GuardDuty を有効化したほかのリージョンがないか確認する

おわりに

このブログでは、最小権限の IAM ポリシー設計、IAM Access Analyzer による公開設定の監査、IAM ユーザーの MFA 設定状況の確認、GuardDuty による脅威検知という 4 つの観点からセキュリティの柱を体感しました。

これらは、セキュリティの柱の設計原則である「強力なアイデンティティ基盤を実装する」「トレーサビリティの維持」「セキュリティのベストプラクティスを自動化」と関連する内容です。

MFA の設定状況を定期的に見直すことや、意図しない外部共有を自動で検知する仕組みを持つことの大切さを体感し、また、サンプル検出結果を使用して、GuardDuty が検出結果を生成した際の画面構成や、検出結果に含まれる情報を確認できました。

セキュリティは Well-Architected Framework の中でも特に重要な柱であり、実際の業務でも継続的に取り組むべき観点です。今回のハンズオンを通じて、その基礎的な実装パターンを体験できました。今後のハンズオンでも、セキュリティの観点を意識しながら進めていきます。

引き続き、次回は「信頼性」の柱を、マルチ AZ 構成の RDS と Auto Scaling でハンズオンする予定です。

最後までお読みいただきありがとうございました！

参考リンク

• Security Pillar
• Security: Design principles
• Security: Definition
• IAM policy testing with the IAM policy simulator
• 仮想 MFA デバイスを AWS Management Console で割り当てる
• IAM ロールへの切り替え（AWS Management Console）
• MFA 保護された API アクセスの設定
• Getting started with GuardDuty
• AWS Identity and Access Management Access Analyzer の開始方法
• IAM Access Analyzer の外部アクセスアナライザーを作成する

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、 IT・AI をフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイトをぜひご覧ください。
※2026 年 1 月 アノテーション㈱から社名変更しました。