自治体職員がガバクラの AWS 閉域ネットワークを理解するのにやって良かった個人検証環境

Transcript

1. 自治体職員がガバクラのAWS閉域ネット ワークを理解するのにやって良かった 個人検証環境 2025-08-20, Gov-JAWS#3 1
2. 今日お話ししたいこと ⚫ ガバメントクラウドのAWSネットワークは、AWS初学者には ハードルが高い。例えば…… ⚫ 複数のAWSアカウント環境を相互に接続 ⚫ 閉域内でオンプレミスとVPCを接続 ⚫ しかし自治体職員に調整を求められる場面がどうしてもある。 ガバメントクラウドのAWSネットワークの理解のため、 個人環境で検証した内容について共有します。 それなら調整が必要となる作業を自分で試せば、求められる知識の理 解が進むのでは？→実際にやってみました。 2
3. 今日のお話の構成 異なるAWSアカウント間のネットワーク接続パターン ⚫ Transit Gateway (TGW) で複数アカウントのVPC間を接続 ⚫ Route 53プライベートホストゾーン (PHZ) を複数アカウント のVPCで共有 ⚫ TGWとRoute 53で名前解決とVPCエンドポイントを集約 閉域網からS3への接続パターン ⚫ 閉域VPCから別アカウントのS3バケットへアクセス ⚫ 閉域オンプレミスからTransfer FamilyでS3への接続 オンプレミスとVPCの連携パターン ⚫ 閉域VPCとオンプレミスをEC2にVPNサーバーを立てて接続 ⚫ オンプレミスとRoute 53 Resolverを連携して名前解決を統合 ガバメントクラウド統制について少し触れてみる ⚫ OrganizationsとIAM Identity CenterでGCAS SSOを理解 3
4. 自己紹介 ⚫ 北海道の某市の職員（一般職採用） ⚫ 情シス歴10年 ⚫ AWS歴約3年 4 2023年 SAA、情報処理安全確保支援士試験 2024年 ANS、ネットワークスペシャリスト 2025年 SAP
5. 作成する検証環境の全体像（詳細は後ほど） 5
6. 異なるAWSアカウント間のネットワーク接続パターン 6
7. TGWで複数アカウントのVPC間を接続 7 別アカウントのTGWに接続するには双方のアカウントで作業が必要 ⚫ 自治体のガバメントクラウド利用のように複数VPC間の接続がある場合、TGWを 使うことが多い ⚫ 別アカウントのTGWに接続するには、双方のアカウントで作業が必要 ⚫ ポイントはTGWのResource Access Manager (RAM) 共有とアタッチメント作 成のタイミング ⚫ TGWでVPCを繋ぐだけなら、簡単に検証できる ⚫ TGWの共有元と共有先の２つのAWSアカウントを用意して検証してみます
8. TGWの共有・アタッチメントの承認 1. TGWのあるアカ ウントからRAMで TGWを共有 2. RAMでTGWの共 有を受入れ 3. 共有されたTGW にアタッチメント を作成 4. TGWのあるアカ ウントでアタッチ メントを承認（こ こで初めて疎通す る） 8
9. TGWで複数アカウントのVPC間を接続 9 1. 共有元アカウントのRAMからTGWを共有 2. 共有先アカウントのRAMでTGWの共有を承認 3. 共有先アカウントからTGWアタッチメントを作成（共有元アカウントが承認す るまで接続されない） 4. 共有元アカウントでTGWアタッチメントを承認 5. 共有元アカウントでTGWルートテーブルへTGWアタッチメントを関連付け 6. 共有先アカウントでTGWアタッチメントへのVPCルートテーブルを作成 7. TGWは、アタッチメントを作成すると時間単位で高額な料金がかかるので、検 証が終わったら速やかにアタッチメントは削除する 作業手順（参考）
10. 検証作業を実際やってみて分かったこと 10 ⚫ TGWの接続のように、AWSでの作業は双方のアカウント間などで連携しながら行 うものが結構ある ⚫ アカウントがそれぞれ別のベンダーに保守されているような場合、どの段階で何 の情報を各ベンダーに伝えればよいか理解できていると、連携に必要な調整がス ムーズに行える 複数アカウント間など連携が必要な作業のポイントが分かると 複数ベンダー間の作業の調整がやりやすくなる 以降はこれと同様に、異なるアカウント間や閉域のオンプレミスとVPC間の 接続など、ガバメントクラウドでよく調整が求められるポイントをピック アップしてお話しします。
11. Route 53 PHZを複数アカウントのVPCで共有 11 ⚫ AWS環境の名前解決で重要なRoute 53 PHZ（プライベートホストゾーン）は、別 アカウントのVPCに関連付けることで、別アカウントのVPCからも名前解決させる ことが可能 ⚫ ただし別アカウントのVPCとの関連付けの作業はマネジメントコンソールからは設 定できず、AWS CLIなどから行う必要あり ⚫ AWS CLIにセットするパラメーター（VPC ID、Hosted Zone ID）が双方のアカ ウントで必要になるのがポイント Route 53 PHZは複数アカウントで共有できる
12. 別アカウントのVPCへRoute 53プライベートホストゾーン を関連付け 1. Route 53 PHZを 作成してVPCへ関 連付け要求 2. 要求されたRoute 53 PHZの関連付け を承認 12
13. Route 53 PHZを複数アカウントのVPCで共有 13 1. Route 53 PHZを作成したアカウントからAWS CLIなどで関連付けたい別アカウン トのVPCへ関連付けを要求 2. 要求を受けた側のアカウントからAWS CLIなどでVPCへの関連付けを承認 作業手順（参考）
14. TGWとRoute 53で名前解決とVPCエンドポイントを集約 14 ⚫ VPCにRoute 53 Resolver（インバウンドエンドポイント）を作成すると、この VPCに関連付けられたRoute 53 PHZのレコードをRoute 53インバウンドエンド ポイントから名前解決できるようになる ⚫ TGW経由で別のVPCからのDNS参照先をRoute 53インバウンドエンドポイント にすれば、名前解決の参照先を1箇所に集約できる ⚫ この応用で、VPCエンドポイントを1箇所のVPCにまとめてRoute 53インバウン ドエンドポイントで名前解決できるようにし、TGW経由で別VPCからルーティン グでアクセスさせることもできる ⚫ Route 53インバウンドエンドポイントは高額なので、検証が終わったら速やか に削除を TGW経由でRoute 53 Resolverを共有すれば集約できる
15. TGW経由でRoute 53インバウンドエンドポイントを共有 TGWで別VPCから Route 53インバウ ンドエンドポイン トへルーティング VPCのDHCPオプ ションセットで DNS参照先をRoute 53インバウンドエ ンドポイントへ EC2の名前解決は Route 53インバウ ンドエンドポイン トで実施 別アカウントのEC2 からVPCエンドポ イントを名前解決 してアクセス可能 になる 15
16. 閉域網からS3への接続パターン 16
17. 閉域VPCから別アカウントのS3バケットへアクセス 17 ⚫ 閉域VPCからでもゲートウェイエンドポイント経由でS3にアクセス可能 ⚫ 別アカウントのS3バケットにアクセスするときも同様 ⚫ 別アカウントへのS3バケットのアクセス許可（クロスアカウントアクセス） は、IAMロールを使い、バケットポリシーやSTSのスイッチロールで制御する のがポイント ゲートウェイエンドポイントで閉域VPCからS3へアクセスし、 別アカウントからクロスアカウントアクセス
18. S3ゲートウェイエンドポイントとバケットポリシーの作成 S3へゲートウェイ エンドポイント経 由でアクセス 18 他アカウントから のS3へのアクセス はバケットポリ シーで制御
19. 閉域VPCから別アカウントのS3バケットへアクセス 19 1. 連携先アカウントでS3バケットを作成 2. 連携元アカウントのVPCにS3ゲートウェイエンドポイントを作成→閉域からS3 サービス全体へアクセスできるようになる 3. 連携元アカウントに連携先アカウントのS3バケットへアクセス権を付与したIAM ロールを作成し、S3に連携したいリソース（EC2など）へアタッチ 4. 連携先アカウントでバケットポリシーを設定し、連携元アカウントのIAMロール のみアクセスを許可する→連携元アカウントのIAMポリシーがアタッチされたリ ソースのみアクセスできる制限が可能 5. 連携元アカウントからSTSで連携先アカウントのIAMロールにスイッチロールする 方法もあり 6. S3バケットをカスタマー管理型キーで暗号化している場合はKMSへの権限も必要 作業手順（参考）
20. 閉域オンプレミスからTransfer FamilyでS3への接続 20 ⚫ 閉域のオンプレミスなど、認証認可の問題でS3 APIへのアクセスが難しい場合、 Transfer FamilyのSFTPサーバー経由でS3へアクセスさせることができる ⚫ SFTPユーザーに連携先のS3バケットを設定するのがポイント ⚫ SFTPユーザーの認証は公開鍵認証を使うが、鍵の管理はAWSのマネージドサービ スでできないので、AWS外で鍵管理が必要になるので注意 Transfer Familyなら認証認可をSFTPサーバーで行い、 SFTPプロトコルでS3バケットへアクセスすることが可能
21. 閉域オンプレミスからTransfer Familyの エンドポイント経由でS3へ接続 オンプレから Transfer Familyの SFTPサーバーのエ ンドポイントへ接 続 21
22. 閉域オンプレミスからTransfer FamilyでS3への接続 22 ⚫ Transfer FamilyでストレージサービスをS3とするSFTPサーバーを設定 ⚫ SFTPユーザーからS3バケットへのアクセス制限に使うIAMロール・セッションポ リシーを作成 ⚫ ローカルなどでユーザーの公開鍵認証に使うキーペアを作成（AWSマネージド サービスでは作成できない） ⚫ 上記セキュリティ設定でSFTPユーザーを作成 ⚫ 余裕があればTransfer Familyのエンドポイントをオンプレからアクセスさせやす いホスト名で名前解決できるようRoute 53を設定 ⚫ Transfer Familyの料金は高額なので、検証が終わったら速やかに削除を 作業手順（参考）
23. オンプレミスとVPCの連携パターン 23 少しだけギアを上げていきます
24. 閉域VPCとオンプレミスをEC2にVPNサーバーを立てて接続 24 ⚫ DNSやルーティングはやはり実際にオンプレミスと繋いで試したい ⚫ AWSマネージドサービスでSite-To-Site VPNするのはコストが高い ⚫ EC2にVPNサーバーを立てて、オンプレミスのVPNルーターとIPSecで接続すれば、 低コストで閉域オンプレミス間の接続が実現可能 ⚫ ただし本物のガバメントクラウド環境ではインターネット経由でのVPNは認めら れないので注意（ここではあくまで個人検証の用途をいかに低コストでやるかと いう主旨です） ⚫ ついでにBIRDなどでBGPの動的ルーティングを設定すると本物っぽさが出てよい （ただしVPCと直接動的に経路交換することはできない……） 検証用途であればEC2にVPNサーバーを立てて 閉域オンプレミス接続が低コストで実現できる
25. EC2でVPNサーバーを構築しVPNルーターと接続 パブリックサブ ネットのEC2に strongSwanを立て てオンプレとIPSec 接続 25 VPCのサブネット へはEC2とのIPSec トンネルへルー ティング
26. オンプレミスとRoute 53を連携して名前解決を統合 26 ⚫ DNSの連携はオンプレ側とRoute 53の双方の設定が要るので鬼門のひとつ ⚫ オンプレのDNSサーバーに、VPC内のドメインの名前解決要求をRoute 53インバ ウンドエンドポイントへ転送するよう条件付きフォワーダーを設定すると、オン プレミスからもVPC内の名前解決ができるようになる ⚫ ポイントはAWSというよりDNSそのものの理解 ⚫ これまでRoute 53インバウンドエンドポイントがDNSの委任に対応していなかっ たため、オンプレのドメインのサブドメインをVPCで使う場合でも条件付きフォ ワーダーが必要だったが、現在は対応しているため、今後はサブドメインをRoute 53インバウンドエンドポイントへ委任する方法もあり オンプレミスのDNSサーバーからの名前解決を Route 53インバウンドエンドポイントと連携する
27. オンプレDNSサーバーとRoute 53 Resolverと連携 VPCで使うドメイン への名前解決はオン プレDNSサーバーか らインバウンドエン ドポイントへ転送 27 VPCで使いたいド メインをRoute 53 PHZで管理する
28. ガバメントクラウド統制について少し触れてみる 28 さらにギアを上げてGCAS (ｼﾞｰｷｬｽ) とOrganizationsによるガバメントクラウドの統 制の仕組みを制圧しましょう
29. OrganizationsとIAM Identity CenterでGCAS SSOを理解 29 ⚫ ガバメントクラウドの統制の正体はOrganizationsと言っても過言ではない ⚫ 自治体が使うアカウントはOrganizationsのメンバーアカウントになっている ⚫ Organizations自体は無料で利用できるので、最初からOrganizationsとIAM Identity Centerでアカウント管理するのがおすすめ ⚫ IAM Identity Centerと外部Identity Provider (IdP) とSAML連携でSSOを構築して みると、ガバメントクラウドでGCASユーザーからAWSにSSOしてIAMロールで権 限がコントロールされていることが理解しやすい OrganizationsとGCAS SSOはガバメントクラウド統制の肝である
30. OrganizationsとIAM Identity Centerで外部IdP SSOを構築 30 Entra IDとIdCが連 携し、Entra IDの ユーザーでAWSに SSOするよう設定 ユーザーにIAM ロールを紐付けて 権限を管理する
31. 自治体職員がAWS検証して良かったことのまとめ 31
32. 実際にAWSの検証をしてみる意義 32 ⚫ ガバメントクラウドでは、複数アカウント間、閉域オンプレミス間の接続でポイ ントとなる部分がある ⚫ 今回取り上げたTGW、Route 53、S3は代表的なポイント ⚫ 一見難しそうだが、基本的なネットワークの知識さえあれば意外と簡単にできる ⚫ 高額なリソースも、検証後すぐに削除すれば大きな費用はかからない ⚫ 実際に検証作業をしてみることで、各ポイントで必要となる情報が分かるので、 複数のベンダーと連携して作業する際に情報共有を円滑にできるようになる ⚫ 特にオンプレのネットワークで腕に覚えのある自治体情シスはぜひ AWSネットワークを統合的に調整できる自信がつく ご清聴ありがとうございました！(ｼﾞｰｷｬｽ!!)