AWS 認定資格 ラボ
SAA（Solutions Architect Associate）攻略 ・

SAA ドメイン1：セキュアなアーキテクチャの設計｜配点30%を IAM・暗号化・境界防御で攻略する

AWS SAA-C03 の配点最大ドメイン1「セキュアなアーキテクチャの設計（30%）」を、公式タスクステートメント1.1〜1.3に沿って完全攻略する。結論は「守る対象を “アクセス・通信・データ” の3層に分け、各層を最小権限・境界防御・暗号化で固める」こと。IAM ロールと一時認証、Security Group と NACL の使い分け、KMS による保管時／転送時の暗号化、Secrets Manager と Parameter Store の選択まで、SAA 本番で問われる設計判断と頻出ひっかけを、そのまま得点に変わる粒度で解説する。

#AWS #SAA #SAA-C03 #Solutions Architect #セキュリティ #IAM #KMS #試験対策 #AWS認定資格

「セキュリティの問題は、なんとなく “厳しそうな選択肢” を選べば当たる」——そう思っているうちは、SAA-C03 のドメイン1で安定した得点は望めない。配点最大の **30%（採点対象50問のうち約15問）を占めるこのドメインは、AWS が「セキュリティを最優先事項」として扱う姿勢の表れであり、出題は明確に3つのタスクステートメント（1.1〜1.4ではなく1.1〜1.3）**へ構造化されている。結論から言えば、ドメイン1は「守る対象を “アクセス・通信・データ” の3層に分け、それぞれを最小権限・境界防御・暗号化で固める」ことで攻略できる。本記事では、各タスクの中核サービス・設計判断・頻出ひっかけを、SAA 本番でそのまま選択肢を絞れる粒度まで分解する。読み終えれば、長いシナリオ問題を前にしても「これはアクセスの話か、通信の話か、データの話か」を一瞬で見抜けるようになる。

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

📑 目次

  1. 結論：ドメイン1は「アクセス・通信・データ」の3層で守る
  2. ドメイン1の全体像と3つのタスクステートメント
  3. タスク1.1：AWS リソースへのセキュアなアクセス設計
  4. タスク1.2：セキュアなワークロードとアプリケーション設計
  5. タスク1.3：適切なデータセキュリティ管理
  6. ドメイン1の頻出ひっかけパターン
  7. 責任共有モデルがドメイン1の土台になる
  8. 次のアクション チェックリスト
  9. 関連記事
  10. 関連サイト

1. 結論：ドメイン1は「アクセス・通信・データ」の3層で守る

SAA-C03 ドメイン1を攻略する最短ルートは、「何を守るか」を3つの層に分けて考えることだ。これが本記事の結論である。

理由は、ドメイン1の3つのタスクステートメントが、そのままこの3層に対応しているからだ。タスク1.1＝アクセスを守る（誰が触れるか）、タスク1.2＝通信を守る（どこから来るか）、タスク1.3＝データを守る（保管と転送）。セキュリティは漠然と「堅くする」ものではなく、層ごとに使うサービスと打ち手が決まっている。この対応を頭に入れておけば、問題文が「IAM の話なのか、ネットワーク境界の話なのか、暗号化の話なのか」を即座に判別できる。

具体例で見よう。「EC2 上のアプリから S3 にアクセスさせたい」という要件はアクセス層（1.1）——正解は IAM ロールのアタッチだ。「特定の IP からのみ Web サーバーに接続を許したい」は通信層（1.2）——Security Group の出番。「保存するデータを暗号化したい」はデータ層（1.3）——KMS で鍵を管理する。要件のキーワードから層を特定し、その層の定番サービスを引き出す——これがドメイン1の解き方の骨格だ。

SAA の4ドメイン全体像を先に押さえた人は、ここから配点最大のドメイン1に最初の学習時間を集中投下するのが正解だ。

2. ドメイン1の全体像と3つのタスクステートメント

まず、ドメイン1の構造を1枚の表で俯瞰する。公式試験ガイドのタスクステートメントを、本記事の3層モデルに対応づけたものだ。

タスク守る対象（層）問われる判断中核サービス
1.1アクセス層誰に・どの権限を・どう渡すかIAM（ユーザー / ロール / ポリシー）
1.2通信層どこからの通信を許すか・境界をどう防ぐかSecurity Group / NACL / WAF
1.3データ層保管時・転送時のデータをどう暗号化するかKMS / 暗号化 / Secrets Manager

3つのタスクは独立しているように見えて、実際の問題では重なって問われる。たとえば「機密データを扱う Web アプリ」のシナリオなら、IAM ロール（1.1）＋ WAF・SG（1.2）＋ KMS 暗号化（1.3）が同時に登場する。だからこそ、各層を個別に固めたうえで「3層を一気に貼り合わせる」訓練が効く。

3. タスク1.1：AWS リソースへのセキュアなアクセス設計

アクセス層の中心は IAM だ。SAA で最も繰り返し問われるのが、「長期のアクセスキーを配るのか、一時認証のロールを使うのか」という判断である。

IAM ロール vs アクセスキー——ほぼ常にロールが正解

EC2 上のアプリが S3 にアクセスするケースで、アクセスキーをコードや環境変数にハードコードする選択肢はほぼ確実に誤答だ。正解は IAM ロールをインスタンスにアタッチし、一時認証情報を自動で取得させる構成。キーの漏洩・ローテーション漏れというリスクを根本から消せるからだ。この「ロール＝一時認証」の型は、SAA では丸ごと暗記する価値がある。

IAM ポリシーの設計では最小権限の原則が貫かれる。「とりあえず *:* のフルアクセス」「ルートユーザーで運用」といった選択肢は罠だ。クロスアカウントアクセス（別アカウントのロールを AssumeRole）、外部 IdP とのフェデレーション、複数アカウントを束ねる Organizations ＋ SCP による権限のガードレールも、このタスクの定番である。

認証・ID 管理サービスの使い分け

要件適切なサービス
社内ユーザーの一元的なシングルサインオンIAM Identity Center
Web/モバイルアプリのエンドユーザー認証Cognito
付与済み権限が過剰でないかの分析IAM Access Analyzer

4. タスク1.2：セキュアなワークロードとアプリケーション設計

通信層の主役は、ネットワーク境界の制御だ。ここで毎回のように問われるのが Security Group と NACL の使い分けである。

Security Group と NACL の違い
評価項目
Security Group 推奨
NACL
適用単位 ENI（インスタンス単位） サブネット単位
状態管理 ステートフル（戻りは自動許可） ステートレス（戻りも明示）
ルールの種類 許可のみ 許可と拒否の両方
評価順 全ルールを総合評価 番号順に最初の一致を適用
主な用途 インスタンスへの基本防御 特定IPのブロック等の補助
「ステートフル/ステートレス」「許可のみ/拒否も可」の2点が即答できれば失点しない。

この差を即答できないと確実に失点する。「特定の IP アドレスからのアクセスを明示的に拒否したい」なら、許可ルールしか書けない SG では実現できず、NACL が正解になる——この型は頻出だ。

アプリケーション層の保護では、SQL インジェクションや XSS など Web 攻撃を防ぐ WAF、内部サービスへの非公開接続を実現する PrivateLink や VPC エンドポイントが選択肢に上がる。「S3 への通信をインターネットに出さずプライベートに保ちたい」なら Gateway 型 VPC エンドポイントが定番の答えだ。脅威検知が要件なら GuardDuty、API 通信の証明書管理は ACM で無料の SSL/TLS 証明書を発行・自動更新する。

5. タスク1.3：適切なデータセキュリティ管理

データ層は暗号化の設計が中心。KMS による鍵管理を軸に、「保管時の暗号化（at rest）と転送時の暗号化（in transit）」を区別して問われる。

保管時・転送時の暗号化

保管時の暗号化は、S3・EBS・RDS など各サービスが KMS と統合して提供する。S3 なら **SSE-S3（AWS 管理鍵）と SSE-KMS（顧客管理鍵で監査ログ・きめ細かな権限制御が可能）**の選択が頻出だ。「誰がいつ鍵を使ったかを CloudTrail で追跡したい」「鍵へのアクセスを IAM で細かく制御したい」なら SSE-KMS が正解になる。転送時の暗号化は TLS/HTTPS が基本で、ACM の証明書と組み合わせる。

認証情報・シークレットの管理

機密値（DB パスワード・API キー）の保管は、Secrets Manager と Parameter Store の使い分けが定番の出題だ。

観点Secrets ManagerParameter Store（SSM）
自動ローテーション✅ 標準対応（Lambda 連携）❌ 非対応
料金シークレット単位で課金標準パラメータは無料
主な用途DB 認証情報・自動更新が要る秘密設定値・環境変数・一般的な秘密

監査・コンプライアンスの文脈では、API 操作の記録を取る CloudTrail が「誰が何をしたか」の追跡手段として登場する。暗号化と監査ログはセットで問われやすい。

6. ドメイン1の頻出ひっかけパターン

ドメイン1は、AWS の設計思想（最小権限・一時認証・マネージドな鍵管理）に沿わない選択肢が誤答になりやすい。本番で迷ったときの判断材料として、正答に寄せる打ち手と避けるべき誤答を整理する。

7. 責任共有モデルがドメイン1の土台になる

ドメイン1のすべての判断は、**責任共有モデル（Shared Responsibility Model）**という1枚の地図の上に成り立っている。

AWS は「クラウドそのもののセキュリティ（of the cloud）」——データセンター・ハードウェア・基盤ネットワークを守る。一方、利用者は「クラウド内のセキュリティ（in the cloud）」——IAM の権限設計、SG/NACL の設定、データの暗号化を守る。ドメイン1で問われるのは、ほぼすべて利用者側の責任範囲だ。だから「AWS が勝手にやってくれる」と誤解した選択肢は誤答になりやすい。

たとえば「EC2 の OS パッチ適用は誰の責任か」と問われれば、答えは利用者（EC2 は IaaS なので OS から上は利用者責任）。一方「S3 の基盤インフラの物理的保護は誰の責任か」なら AWS。このマネージドサービスの抽象度に応じた責任の境界線が、ドメイン1の設計判断の前提になる。

8. 次のアクション チェックリスト

ドメイン1の3層モデルを、今日からの学習に落とし込むための具体アクションをまとめる。

9. 関連記事

10. 関連サイト

AWS 公式