第 2 章 セキュアなアーキテクチャの設計（30%）
セキュアなワークロードとアプリケーション
この章で学ぶこと
- アプリケーションの設定と認証情報のセキュリティ
- AWS のサービスエンドポイント
- ポート・プロトコル・ネットワークトラフィックの制御
- セキュアなアプリケーションアクセス
- 適切なユースケースを伴うセキュリティサービス（Cognito、GuardDuty、Macie）
2-1 門は 2 枚ある ―― セキュリティグループとネットワーク ACL
VPC の中の通信を止めたり通したりする仕組みは 2 つある。どちらも「許可するルールを書く」ように見えるが、動きが正反対だ。
| セキュリティグループ | ネットワーク ACL | |
|---|---|---|
| 付く場所 | インスタンス（正確には ENI） | サブネット |
| 状態の扱い | ステートフル（行きを許せば帰りは自動） | ステートレス（行きと帰りを別々に書く） |
| 書けるルール | 許可だけ | 許可と拒否の両方 |
| 評価のしかた | 全ルールをまとめて見る（1 つでも許可があれば通る） | 番号の小さい順に見て、最初に当たったもので決まる |
| 既定の状態 | 受信は全拒否・送信は全許可 | 既定の ACL は全許可／自作の ACL は全拒否 |
| 向いている用途 | ふつうはこちらだけで足りる | サブネット全体で特定の IP を落としたいとき |
試験では
ネットワーク ACL はステートレスなので、戻りの通信を忘れると繋がらない。Web サーバーに 80 番を許可しても、戻りのエフェメラルポート（1024〜65535）を送信側で許可していないと応答が返らない。「SG は正しいのに繋がらない」という設問は、まずこれを疑う。
補足
セキュリティグループのルールには、送信元として別のセキュリティグループを指定できる。「ALB の SG からの通信だけを許可する」と書けば、ALB のインスタンスが入れ替わっても IP を書き直さずに済む。実務でも試験でも、IP を直書きする選択肢よりこちらが正解になりやすい。
2-2 公開するものと、隠すもの
設計の基本形は決まっている。外から受けるものだけをパブリックサブネットに置き、残りはプライベートに置く。典型的な 3 層（Web・アプリ・DB）はこうなる。
- ロードバランサーだけがパブリックサブネットに立つ。
- アプリのサーバーはプライベートサブネットに置き、ロードバランサーの SG からだけ受ける。
- データベースはさらに奥のプライベートサブネットに置き、アプリの SG からだけ受ける。
- 外へ出る通信（更新の取得など）は NAT ゲートウェイ経由にする。
では、プライベートサブネットのサーバーにログインして作業したいときはどうするか。昔は踏み台サーバー（Bastion）をパブリックに置いたが、今の正解は AWS Systems Manager の Session Manager だ。
| 踏み台サーバー | Session Manager | |
|---|---|---|
| 受信ポート | 22 番を開ける必要がある | 開けなくてよい（エージェントから外へ出る） |
| 鍵の管理 | SSH 鍵を配る | 不要。IAM で制御する |
| サーバーの用意 | 踏み台用の EC2 が要る | 不要 |
| 操作の記録 | 自分で仕込む | CloudTrail と S3 / CloudWatch Logs に残せる |
試験では
「SSH ポートを開けずに管理したい」「踏み台を無くしたい」と書かれていたら Session Manager。この型は運用負荷の問い方（least operational overhead）と一緒に出ることが多い。
2-3 外からの攻撃に備える層
攻撃の種類によって、当てる道具が違う。量で押してくる攻撃（DDoS）と、中身が悪い攻撃（SQL インジェクション）は別の層で止める。
| 道具 | 止めるもの | 付ける先・特徴 |
|---|---|---|
| AWS Shield Standard | L3 / L4 の DDoS | 無料・自動で有効。全利用者が対象 |
| AWS Shield Advanced | 大規模な DDoS | 有償。専門チームの支援と、攻撃で増えた料金の補償 |
| AWS WAF | L7（SQL インジェクション・XSS・ボット） | CloudFront／ALB／API Gateway／AppSync などに付ける |
| AWS Network Firewall | VPC 全体の通信検査 | VPC 単位。ドメイン名での絞り込みもできる |
| AWS Firewall Manager | ルールを組織全体に配る | Organizations が前提。管理を 1 か所に |
補足
WAF には「レートベースのルール」があり、一定時間に同じ IP から来すぎたら落とすという書き方ができる。総当たり攻撃やスクレイピング対策として問われる。
試験では
Shield は量、WAF は中身。「SQL インジェクションを防ぎたい」に Shield を選ぶ選択肢が必ず混ざる。逆に「大量のリクエストでサービスが落ちた」なら Shield（と CloudFront）の話。
2-4 秘密をコードに書かない
データベースのパスワードや API キーをソースコードや環境変数に直接書くのは誤りだ。AWS には預け先が 2 つある。
| AWS Secrets Manager | Systems Manager パラメータストア | |
|---|---|---|
| 主な用途 | パスワード・DB の認証情報 | 設定値全般（文字列・パラメータ） |
| 自動ローテーション | 組み込みであり（RDS などと連携） | 無い（Lambda を自分で書けば可能） |
| 料金 | シークレット 1 件あたり有償 | 標準パラメータは無料 |
| 暗号化 | KMS で常に暗号化 | SecureString を選べば KMS で暗号化 |
試験では
「認証情報を自動でローテーションしたい」と書かれていたら Secrets Manager。パラメータストアは安いが、ローテーションの仕組みを自分で作ることになる。逆に「ただの設定値をたくさん置きたい・コストを抑えたい」ならパラメータストア。
2-5 インターネットを通らずに AWS のサービスへ行く
プライベートサブネットの EC2 から S3 を読むとき、NAT ゲートウェイ経由でインターネットへ出て S3 のエンドポイントへ行く、という経路になる。これは遅く、高く、外へ出ている。VPC エンドポイントを使うと、AWS の内部だけで届く。
| ゲートウェイ型エンドポイント | インターフェース型エンドポイント（PrivateLink） | |
|---|---|---|
| 使えるサービス | S3 と DynamoDB だけ | 多数の AWS サービス／他社や自社のサービス |
| 仕組み | ルートテーブルに経路を足す | サブネットに ENI（プライベート IP）が立つ |
| 料金 | 無料 | 時間課金＋データ処理料 |
| 別 VPC・オンプレから | 使えない | 使える |
補足
インターフェース型の土台になっているのが AWS PrivateLink だ。自社の VPC で動かしているサービスを、相手の VPC に ENI として出して使わせることもできる。VPC ピアリングと違い、相手のネットワーク全体を見せずに、1 つのサービスだけを公開できる。
試験では
「S3 への通信をインターネットに出したくない」「NAT の費用を減らしたい」はゲートウェイ型エンドポイント。 無料なので、コストの設問（第 14 章）でも同じ答えになる。
2-6 社外・社内とつなぐ
オンプレミスのネットワークと VPC をつなぐ方法は 2 つある。速さと安定を金で買うか、既存のインターネット回線で済ませるかの違いだ。
| AWS Site-to-Site VPN | AWS Direct Connect | |
|---|---|---|
| 経路 | インターネット経由（IPsec で暗号化） | 専用線。インターネットを通らない |
| 開通までの時間 | 短い（すぐ使える） | 長い（数週間〜数か月） |
| 帯域と遅延の安定 | インターネット次第で揺れる | 安定する |
| 暗号化 | 最初から暗号化される | されない（必要なら上に VPN を重ねる） |
| 費用 | 安い | 高い |
補足
ここまでは拠点と拠点を繋ぐ話（Site-to-Site）だった。個人の端末から VPC へ繋ぐときは AWS Client VPN を使う。在宅勤務者が社内システムに入る、という要件で出てくる。どちらも VPN だが、繋ぐ相手が「ネットワーク」か「人」かで分かれる。
試験では
「一貫した帯域と低遅延が要る」なら Direct Connect、「すぐに・安く繋ぎたい」なら VPN。さらに「Direct Connect の障害時に備える」なら、VPN をバックアップとして併用する構成が正解になる。
2-7 脅威を見つける道具の分担
検出系のサービスは名前が似ていて混ざりやすい。何を入力にして、何を出すかで覚えると分かれる。
| サービス | 何を見るか | 何が分かるか |
|---|---|---|
| Amazon GuardDuty | CloudTrail・VPC フローログ・DNS ログ | 不審な振る舞い（マイニング、既知の悪性 IP との通信） |
| Amazon Inspector | EC2・ECR のイメージ・Lambda | 既知の脆弱性とパッチ当て漏れ |
| Amazon Macie | S3 の中身 | 個人情報など機密データがどこにあるか |
| Amazon Detective | 各種ログを束ねたグラフ | 見つかった問題の原因の追跡 |
| AWS Security Hub | 各サービスの検出結果 | 1 か所に集約して、基準との適合を見る |
試験では
「S3 に個人情報が置かれていないか知りたい」は Macie。GuardDuty は中身を見ない（振る舞いを見る）ので、ここで選ぶと誤り。逆に「不正アクセスの兆候を検出したい」は GuardDuty。
シナリオ演習
演習 2-1
プライベートサブネットの EC2 から S3 へ毎日大量に書き込んでいる。NAT ゲートウェイのデータ処理料が月々の請求で目立つようになった。どう直すか。
補足
答え：S3 のゲートウェイ型 VPC エンドポイントを作り、ルートテーブルに経路を足す。
ゲートウェイ型は無料で、通信が AWS の内部で完結するのでデータ処理料が消える。NAT を増やす・インスタンスを大きくする案は、どちらも費用が増える方向。
演習 2-2
Web アプリが SQL インジェクションを受けた。同じ攻撃を止めたい。
補足
答え：AWS WAF を CloudFront か ALB に付け、SQL インジェクション対策のルールを有効にする。
Shield は L3 / L4 の DDoS（量で押す攻撃）が対象で、リクエストの中身は見ない。セキュリティグループはポートの話なので、正規の 443 番で来る攻撃は止められない。
この章のまとめ
- セキュリティグループが付く場所
- ネットワーク ACL が付く場所
- ステートフルなのはどちらか
- 拒否のルールを書けるのはどちらか
- ネットワーク ACL の評価順
- セキュリティグループの既定
この端末にだけ保存されます（登録不要）