はじめに
ガバメントクラウドへの移行検討を実施する中で重要な要素であるネットワークを考えていきたいと思います。
移行検討ポイント
上記のような構成を考えてみます。
するとネットワークに関する移行ポイントがいくつか見えてくるでしょう。
①国民向けのインターネット接続部分
②関連省庁からの職員アクセス部分
③連携システムの接続部分
④運用保守拠点との接続部分
大きく分けるとこの４つです。
また、データセンター内のサーバ間通信やFWなども対象ですが、今回は割愛します。
上記に関しては、AWSのベストプラクティスに基づいて適切な設計をすることが必要ですが別の機会で触れることにします。
順に解説していきます。
①インターネット接続部分
以下リファレンスアーキテクチャをベースに考えてみましょう。
デジタル庁では、GCASガイド上に、参考となるアーキテクチャを公開しています。
ポイントはいくつかあります。
①名前解決
②接続部分がどこになるか
③証明書
まず、①の名前解決をどこでじっすするかを考える必要があります。当然ながら外部に公開するWEBサイトではカスタムドメインで各省庁が管理するドメインを利用することが多いです。
そうなると、そのドメインは誰が管理しているのか、どのような準備が必要かなどを事前に確認する必要があります。選択肢はいかになるでしょう。
・名前解決を外部で実施する（Route53以外）
この場合、接続ポイントとなるFQDNが変更となる場合、例えば、図の場合CloudFrontですが、これを作り直すたびに、外部のDNSへの反映が必要です。また、Route53ならではの機能、ALIASレコードやフェイルオーバールーティングなどの機能は利用できません。
・名前解決をAWS側で実施する。
この場合、接続ポイントのFQDNが変わっても、AWS側で自由にレコード定義が可能です。またRoute53ならではの機能も利用可能です。ただし、ドメイン管理元から、サブドメイン等をこちらのDNSへ委任して貰う必要があります。
どちらの場合もメリット・デメリットはありますが、事前の調整が肝になります。
②の接続部分についてはシンプルですが、GCASガイドにあるようにCloudFrontやAPIGWによるエッジロケーションでの分散と、セキュリティ対策を検討する必要があります。また、インバウンド通信だけでなく、アウトバウンド通信もある場合（メールなど）その方式も検討する必要があります。
③の証明書についても事前に検討が必要です。証明書には３段階のランクがあることは自明ですが、どのランクにするのか、どこで購入するのかなど事前に検討が必要です。
ACMで無料で発行できる証明書は、DV証明書になります。これでよいのか、OVやEVなどが要求されるのかなどは事前に調整を行う必要があります。
②関連省庁からの職員アクセス部分
以前こちらで紹介したようにガバメントクラウドへの接続方式は複数あります。
関連省庁との接続においてもガバメントクラウドの基準からすれば、インターネットで可能かは検討すべきでしょう。とはいえ、職員からのアクセスに限定したい場合は、GSSが第一候補に挙げられると思いますので、GSSとの調整というところが最も調整として力を入れるべきところです。
このように名前解決方式や、各省庁のNW担当との調整など、接続の元と先でどこを経由するのかを明確にし、その担当と調整が必要です。検討時には関係各所とどのような申請等が必要か、構成が必要かをまず確認し検討ポイントを抽出する必要があります。
③連携システムの接続部分
検討ポイントは以下です。
①接続方式
②名前解決方式
連携システムとの接続方式は複数あります。上記のように複数の方式の中から検討する必要があります。
とはいえ、ガバメントクラウドの指針からまずは見てみることがおすすめです。
上記でも触れている通り、同一CSPで構成されるシステムではまず、CSPのマネージドサービスで連携することが推奨されます。
また、APIベースでの連携が推奨されていますので、基本的にはAPIGWのリソースを共有する形式で検討するとよいでしょう。それが難しい場合は、上記の図に記載しているように、PeeringやTGWなどが選択肢になります。しかしながら、上記記事で書いたように、IPアドレスのバッティングを意識しなければならいこと、セキュリティ上不要な通信が許可されてしまうリスクを鑑みると、PrivateLinkやVPCLatticeなどを検討にいれてもよいでしょう。PrivateLinkについては、上記記事をご参照下さい。
そもそも同一のCSP出ない場合は、専用線やなどを検討する必要があります。
回線はどの事業者と契約するのか、ハードウェアは誰が設計し管理するのか、パラメータの責任分界点はどこかなど事前に検討が必要です。
また、名前解決も必要です。
専用線等の場合、接続元、接続先でそれぞれ対抗側の名前解決を実施する必要があります。
IPアドレスベースで接続することも場合によっては可能ですが、名前解決をベースとしたサービスが多いため、どのような名前解決を実施するのか事前に整理しておくことが必要です。
必要に応じてRoute53Resolveエンドポイントを用意する必要があります。ただし、このエンドポイントはコストがそれなりにかかりますので、集約できないか、ホストゾーンの共有などで代替できないかなどコスト観点での検討も必要です。
運用保守拠点との接続
ガバメントクラウドにおいてはインターネット接続が原則となっており、VPNや専用線構成を取っている場合は運用を見直す必要があります。
特に意識すべきは以下です。
・AWSマネジメントコンソールへの接続
・VPC内リソースへの接続
マネジメントコンソールへの接続はガバメントクラウドが提供するGCASを経由します。
この部分のアクセスをどのように制御するのかは事前に検討が必要です。
CEPが利用可能ですので、端末のシリアル番号やIPアドレスで接続元を限定することが可能です。
どのような運用を行うのか事前に検討が必要です。もちろんロール側でIPアドレスを制御することも可能ですが、そもそもIPアドレスが限定できるのかなどは事前に確認することが大切です。
VPC内リソースへの接続は、ユースケースを整理することが大切です。
そもそも、接続するケースはどのようなものか、これまでであれば、EC2への接続、DBへの接続などでしたが、ガバメントクラウドでは、基本的に仮想サーバの利用は認めておらず、リソースへの接続がほぼないかもしれません。とはいえ、閉域構成のAPの動作確認につかう、DBの緊急メンテをしたい、VPC外だがコードリポジトリにアクセスしたいなどがあるかもしれません。
そのようなユースケースを整理し、それぞれ方式を検討しましょう。
共通
どのケースでも大抵ドメインの移行が発生します。
どのような移行をとるのか事前に検討が必要です。
大きく２つのケースが考えられます。
・ドメインそのまま引き継ぎパターン
この場合まず、DNSサーバの移行があるかを検討する必要があります。
移行の必要がある場合当日にするのか事前にするのかを整理しましょう。
個人的には事前にRoute53に引き継ぎ動作確認するほうが望ましいです。
このケースであれば、ユーザ側やシステム側としては接続先の見た目は変わりませんので、特に変更や意識をせずにこれまで通り接続が可能です。
一方で開発する側としては、事前に同一ドメインでテストすることができないので、仮ドメインなどでの動作確認をせざる得なく想定外のミスが生まれる可能性もあります。また、切り戻す際は、レコードを戻してもTTLやキャッシュがクリアされるまでは利用できないケースもあります。
・ドメイン変更パターン
この場合、ドメインを別で用意するためテストも本番同等のドメインで実施可能です。ただし、連携先やユーザ側からすると、接続先を切り替える必要があり、知らなかったユーザからすると接続ができないなどの予期せぬ問い合わせを生む可能性があります。事前の周知やリダイレクトなども考える必要があります。また、連携先側では接続先変更という作業が必要となるため、切替時に要員の確保と作業工数がかかります。
どちらもメリデメはありますので、どのパターンが良いのか事前に議論し意識合わせが必要です。
まとめ
ガバメントクラウドへの移行NW編でした。NW移行はかなり大変です。特に接続ポイントが多数あるケースでは移行が複雑になったり、調整先が多かったり大変なものですので、移行のポイントをしっかりと見極め、重点的に検討を行うことが大切です。