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

Transcript

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