AWS SAA-C03 セキュア設計 完全攻略 — Domain 1（30%）を「暗記」ではなく「判断」で取る

AWS Certified Solutions Architect – Associate（SAA-C03）の学習を始めて、最初の壁にぶつかるのが Domain 1「Design Secure Architectures」です。配点は全体の 30%。4 ドメインの中で最大であり、ここを落とすと合格が一気に遠のきます。

それにもかかわらず、多くの受験者が IAM のサービス名を暗記するだけで Domain 1 を乗り切ろうとして失敗します。SAA-C03 のセキュア設計が問うのは「IAM を知っているか」ではなく「この要件ならどの認証方式・暗号化方式を選ぶか」という設計判断だからです。

この記事では、AWS SAA-C03 セキュア設計の核心を「典型シナリオ → 決め手 → 落とし穴」の 3 点セットで整理します。試験当日に選択肢を 2 つまで絞ってから迷う、あの状況を抜け出すための判断軸を提供します。

なぜ Domain 1 が SAA-C03 の天王山なのか

SAA-C03 の試験仕様は 65 問・130 分・合格点 720（スケール 100〜1000）です。このうち採点対象は 50 問で、残り 15 問は採点されない評価用の問題が混在します。4 ドメインの配点は次の通りです。

Domain 1 だけで 3 割を占めるため、単純計算で採点対象 50 問のうち約 15 問がセキュリティ設計です。逆に言えば、ここを安定して取れるかどうかが合否のボトルネックになります。

なぜ AWS はセキュリティをこれほど重く配点するのでしょうか。理由は、クラウドにおける設計ミスが直接インシデントに直結するからです。S3 バケットの公開設定をひとつ誤れば、機密データが世界中に晒されます。アクセスキーをソースコードに埋め込んで公開リポジトリに push すれば、数分で不正利用が始まります。ソリューションアーキテクトは、こうした事故を「設計の段階で」防ぐ責任を負います。だからこそ Domain 1 は、知識ではなく判断力を問う設問構成になっているのです。

試験全体の位置づけは、AWS Solutions Architect Associate SAA-C03 完全攻略入門（2026-05-30 公開）で解説しました。本記事はその Domain 1 を、設計判断のレベルまで掘り下げます。

IAM の設計判断 — User / Group / Role / Policy の使い分け

セキュア設計の土台は IAM（AWS Identity and Access Management）です。ここで問われるのは 4 つのエンティティの役割分担です。

• User: 人間または個別のアプリに紐づく長期的な ID。長期アクセスキーを持つ
• Group: User をまとめてポリシーを一括付与する箱。Group 自体は認証情報を持たない
• Role: 一時的に「成りすます」ための器。長期認証情報を持たず、STS で発行される一時認証情報で動く
• Policy: 「誰が・何に・何をできる/できない」を定義する JSON ドキュメント

試験で頻出するのが「EC2 上のアプリが S3 にアクセスする際、どう認証情報を渡すべきか」という問題です。アクセスキーをコードや環境変数に埋め込む選択肢は、たとえ動作しても誤りです。正解は IAM Role を EC2 インスタンスプロファイルとしてアタッチする。これにより、アプリは自動で更新・失効される一時認証情報を取得し、キー管理の負担そのものが消えます。

ここが Domain 1 の判断軸の出発点です。長期キーが登場したら疑う。Role で代替できないかを真っ先に考える。この発想が AWS SAA-C03 セキュア設計の全体を貫きます。

Policy の構造も押さえておきましょう。IAM ポリシーは JSON で記述され、Effect（Allow/Deny）、Action（操作）、Resource（対象）、Condition（条件）の 4 要素で構成されます。たとえば「特定のバケットへの読み取りだけを許可する」最小権限のポリシーは、次のような形になります。

Effect: Allow
Action: s3:GetObject
Resource: arn:aws:s3:::example-bucket/*

最小権限の原則（least privilege）は Domain 1 の通底するテーマです。「とりあえず管理者権限を付けて動かす」は実務でも試験でも最大のアンチパターン。必要な Action と Resource だけを許可し、Condition で送信元 IP や MFA の有無といった条件を絞り込む。この積み上げが、攻撃対象領域（attack surface）を最小化します。

一時認証情報の原則 — STS・AssumeRole・フェデレーション

IAM Role の裏側で動くのが AWS Security Token Service（STS）です。STS は有効期限付きの一時認証情報（アクセスキー・シークレットキー・セッショントークンの 3 点セット）を発行します。

AWS は公式に「すべての API・CLI リクエストで長期認証情報ではなく一時認証情報を使うべき」と明言しています。マネジメントコンソールにサインインする時でさえ、内部的には一時認証情報が生成されています。

主要な利用パターンは次の 3 つです。

一時認証情報には有効期限が設定され、期限が切れれば自動的に無効になります。これは「鍵が漏れても被害が時間的に限定される」という強力な防御特性です。落とし穴は「フェデレーション＝IAM User の大量作成」という誤解です。数千人の社員に AWS アクセスを与える要件で IAM User を人数分作る選択肢は不正解。正解は既存の IdP とフェデレーションし、一時認証情報で都度アクセスさせる設計です。AWS IAM Identity Center（旧 AWS SSO）を中心に据えると、複数アカウントへのアクセスを一元管理できます。

クロスアカウントアクセスとリソースベースポリシー

組織が成長すると、AWS アカウントは本番・開発・監査などに分割されます。SAA-C03 では、このマルチアカウント環境でのアクセス設計が問われます。

ポリシーには 2 種類あります。

• アイデンティティベースポリシー: User・Group・Role に付与。「この ID は何ができるか」を定義
• リソースベースポリシー: S3 バケットや SQS キューなど、リソース側に付与。「このリソースに誰がアクセスできるか」を定義

クロスアカウントで S3 バケットを共有する場合、2 つのアプローチがあります。ひとつはバケットポリシー（リソースベース）で相手アカウントを許可する方法。もうひとつは相手アカウントの Role に AssumeRole を許可する方法です。一時的・限定的なアクセスなら Role 経由、恒久的なバケット共有ならバケットポリシーが選ばれます。

S3 への公開アクセスを防ぐ設計では、リソースベースポリシーだけに頼らず S3 Block Public Access を併用するのが正攻法です。多層で守るという発想が、ここでも効いてきます。

クロスアカウントの典型シナリオを具体化しましょう。監査アカウントが本番アカウントのログバケットを読み取りたい、というケースを考えます。本番側のバケットポリシーで監査アカウントの ARN を信頼し、監査側の Role に該当バケットへの読み取りを許可する。この「両側で許可が揃って初めて通る」という構造が、クロスアカウントアクセスの本質です。片側だけの設定では通らない点が、試験のひっかけになりやすいので注意してください。

権限の評価ロジック — 明示的 Deny・SCP・権限境界

SAA-C03 のセキュア設計で最も差がつくのが、ポリシー評価ロジックの理解です。リクエストが許可されるか否かは、複数のポリシーを統合して決まります。

評価の大原則は明確です。明示的な Deny は常に最優先される。どれだけ Allow が積み重なっていても、ひとつでも明示的 Deny があればアクセスは拒否されます。そして、明示的な Allow がどこにも無ければ、デフォルトは暗黙の Deny です。

組織レベルで効くのが次の 2 つです。

試験で頻出のひっかけは「IAM ポリシーで Allow したのに動かない」というシナリオです。原因は SCP による組織レベルの制限、あるいは権限境界の天井であることが多い。AWS SAA-C03 セキュア設計では、この多層の評価を頭の中で順にたどれることが求められます。

データ保護の設計 — KMS のキー種別を選ぶ

保管時の暗号化を担うのが AWS Key Management Service（KMS）です。試験では「AWS 管理キー」と「カスタマー管理キー」のどちらを選ぶかが論点になります。

• AWS 管理キー: サービスが自動で作成・管理。ローテーションも自動。設定の手間がほぼゼロ
• カスタマー管理キー（CMK）: ユーザーが作成・管理。キーポリシーの細かな制御、ローテーション間隔の指定、削除のスケジュール、監査が可能

判断軸はシンプルです。コンプライアンス要件でキーポリシーや監査を自分で制御する必要があれば、カスタマー管理キーを選ぶ。手軽さ優先で要件が無ければ AWS 管理キーで十分です。複数の AWS サービスにまたがってアクセス制御を統一したい、特定の Role だけに復号を許したい、といった要件が出たらカスタマー管理キーの出番です。

なお、暗号化には保管時（at rest）と転送時（in transit）の 2 面があります。S3 や EBS、RDS は保管時の暗号化を KMS で実現し、転送時は TLS で守る。両方を押さえる設計が問われます。

KMS の内部では、エンベロープ暗号化という仕組みが使われています。実データはデータキーで暗号化し、そのデータキー自体をマスターキー（KMS キー）で暗号化する二段構えです。これにより、大量のデータを高速に暗号化しつつ、鍵管理は KMS に集約できます。試験では細部までは問われませんが、「KMS は鍵の鍵を守るサービス」というイメージを持っておくと、選択肢の正誤判断がぶれません。

シークレット管理 — Secrets Manager と Parameter Store

データベースのパスワードや API キーといったシークレットの扱いも、Domain 1 の頻出領域です。選択肢は主に 2 つです。

判断の決め手は「自動ローテーションが要るか」です。RDS のパスワードを定期的に自動で入れ替えたい要件なら Secrets Manager 一択。Secrets Manager は RDS 向けに組み込みのローテーション機能を持ち、その他のシークレットも Lambda 関数でカスタムローテーションできます。

一方、頻繁に変わらない設定値や、コストを抑えたい軽量な用途なら Parameter Store が適します。なお Secrets Manager のシークレットは KMS で暗号化され、AWS 管理キー（aws/secretsmanager）かカスタマー管理キーを選べます。前述の KMS の判断軸がここでも連動します。

設計判断として覚えておきたいのは、「ハードコードされた認証情報を、コードからどう追い出すか」という問いです。データベース接続文字列をソースに直書きする設計は、漏洩リスクとローテーション不能という二重の問題を抱えます。アプリ起動時に Secrets Manager から取得し、メモリ上だけで保持する。この一手で、認証情報の管理は劇的に堅牢になります。Domain 1 の設問は、こうした「あるべき設計」へ誘導する形で出題されます。

ネットワーク層のセキュリティ — SG・NACL・多層防御

認証・暗号化と並ぶもう一本の柱がネットワークセキュリティです。VPC 内のトラフィック制御は、性質の異なる 2 つの仕組みで行います。

• セキュリティグループ（SG）: インスタンス単位。ステートフル（戻りの通信は自動許可）。許可ルールのみ
• ネットワーク ACL（NACL）: サブネット単位。ステートレス（戻りの通信も明示が必要）。許可と拒否の両方を設定可能

「特定の IP アドレスをブロックしたい」という要件では、SG では拒否ルールが書けないため NACL を使うのが正解です。逆に「この EC2 はこの ALB からの通信だけ受ける」なら SG で送信元を SG 参照に設定します。

実務でも試験でも、正解は片方だけに頼らない多層防御です。NACL でサブネットの大枠を守り、SG でインスタンス単位の細かい制御をかける。さらに前段に AWS WAF や AWS Shield を置いてアプリ層・DDoS を防ぐ。セキュリティの考え方はAWS 共有責任モデル 完全解説 — CLF-C02 Domain 2（2026-05-27 公開）でも触れましたが、Associate ではこれを「設計の選択」として問われます。

検知と監査 — CloudTrail・GuardDuty・Config の役割分担

セキュアな設計は「防ぐ」だけでは完結しません。「記録する・検知する・評価する」の 3 サービスを正しく使い分けられるかが問われます。

混同しやすいのが CloudTrail と Config です。「S3 バケットが意図せず公開設定に変更された事実を後から追跡したい」なら、リソース構成の変化を記録する Config が適任。「誰がその変更 API を叩いたか」を知りたいなら CloudTrail です。両者は補完関係にあり、組み合わせて使うのが定石です。

GuardDuty の位置づけも理解しておきましょう。GuardDuty は CloudTrail のログや VPC フローログ、DNS ログを継続的に取り込み、機械学習で「普段と違う振る舞い」を検知します。たとえば、見慣れない地域からの API コール、暗号資産マイニングを思わせる通信、漏洩したアクセスキーの不正利用などです。重要なのは、GuardDuty は「検知」に特化し、自動で遮断はしない点。検知結果を Amazon EventBridge に連携し、Lambda で自動対応を組むのが実践的な設計です。防御（SG/NACL/WAF）、記録（CloudTrail/Config）、検知（GuardDuty）という三層をどう組み合わせるかが、Domain 1 の総合力として問われます。

設計シナリオ演習 — 5 つの典型問題

ここまでの判断軸を、試験形式で確認します。各問、選択肢を絞る思考をたどってください。

シナリオ 1: EC2 上のアプリが S3 にアクセスする最も安全な方法は。 選択肢にはたいてい「アクセスキーを環境変数に設定」「アクセスキーをコードに記述」が混ざっています。どちらも動作はしますが、長期キーの漏洩リスクを抱えるため不正解です。正解は IAM Role をインスタンスプロファイルとしてアタッチすること。アプリは自動更新される一時認証情報を取得し、キー管理が不要になります。長期キーを見たら疑う、という原則がそのまま効きます。

シナリオ 2: 数千人の社員に AWS コンソールアクセスを与えたい。 IAM User を人数分作成する選択肢は、管理破綻と退職者のキー残存リスクで不正解です。正解は既存の IdP（Active Directory 等）とフェデレーションし、IAM Identity Center で複数アカウントへのアクセスを一元管理する設計。ユーザーは都度、一時認証情報でアクセスします。

シナリオ 3: IAM ポリシーで Allow したのに操作が拒否される。 焦って IAM ポリシーをさらに追記しても解決しません。原因は上位レイヤーにあります。AWS Organizations の SCP で組織全体から禁止されているか、Role に権限境界の天井がかかっているか、あるいはどこかに明示的 Deny が存在するか。明示的 Deny が常に勝つ、という評価順を思い出せば筋道が見えます。

シナリオ 4: RDS のデータベースパスワードを定期的に自動で入れ替えたい。 Parameter Store の標準パラメータには自動ローテーションがないため不正解です。正解は AWS Secrets Manager。RDS 向けの組み込みローテーション機能があり、Lambda を介して任意の間隔で入れ替えられます。

シナリオ 5: 特定の IP アドレスレンジを VPC でブロックしたい。 セキュリティグループは許可ルールしか書けないため、ブロック要件には使えません。正解はネットワーク ACL の拒否ルールでサブネット単位に遮断する設計です。

5 問とも、出発点は「長期キーを疑う」「多層で守る」「評価ロジックを順にたどる」という共通の判断軸です。サービス名の暗記では届かない領域が、ここに集約されています。試験本番では、選択肢のうち「動くが安全でないもの」を見抜いて捨てる訓練が効きます。

まとめ — Domain 1 のチェックリスト

AWS SAA-C03 セキュア設計の攻略は、次のチェックリストに集約できます。

• 長期アクセスキーが登場したら、まず IAM Role と STS 一時認証情報で代替できないか考える
• 大量の人間アクセスは IAM User ではなくフェデレーション＋Identity Center
• 「Allow したのに動かない」は SCP・権限境界・明示的 Deny を順に疑う
• KMS は「キーポリシー制御と監査が要るか」でカスタマー管理キーを判断
• 自動ローテーションが要るシークレットは Secrets Manager
• SG（ステートフル・許可のみ）と NACL（ステートレス・拒否可）を多層で組む
• 記録は CloudTrail、検知は GuardDuty、構成評価は Config

配点 30% の Domain 1 を「判断」で取れるようになれば、合格は大きく近づきます。次は配点 26% の Domain 2、高可用・回復性アーキテクチャの設計に進みます。冗長化と疎結合という 2 本の柱を、同じく設計判断のレベルで整理していきましょう。

参照

• AWS Certified Solutions Architect – Associate（SAA-C03）公式
• AWS IAM 公式ドキュメント
• AWS Well-Architected Security Pillar — 一時認証情報の利用
• IAM ポリシー評価ロジック
• AWS Secrets Manager 公式
• AWS Key Management Service（KMS）公式

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.