
この記事の要点
- 仮想のネットワークの住所の範囲は、社内や将来つなぐネットワークと重ならないよう、作る前に決めます
- インターネットに公開する部分と公開しない部分をサブネットで分け、データベースなどは公開しない側に置きます
- 社内との接続は、インターネット越しの暗号化されたVPNと、事業者を通した専用の接続(専用線)から、帯域と費用で選びます
クラウドのネットワーク設計は、仮想のネットワークの住所(IPアドレス)の範囲を決め、インターネットに公開する部分と公開しない部分を分けることから始めます。この2つは、後から変えにくいため、サーバーを作る前に決めておきます。
ここでいう仮想のネットワークは、AWS と Google Cloud では VPC(Virtual Private Cloud)、Microsoft Azure では仮想ネットワーク(VNet)と呼ばれます。この記事では、AWS の説明を中心に、3つのクラウドに共通する考え方を説明します。
仮想のネットワークの基本の部品
AWS は、VPC を「自社のデータセンターで運用する従来のネットワークによく似た仮想のネットワーク」と説明しています。VPC を作った後、その中にサブネット(住所の範囲を小さく区切ったもの)を作り、サーバーなどの資源を置きます。サブネットは、1つのアベイラビリティゾーン(同じ地域の中の独立したデータセンターの集まり)の中に置かれます。
通信の行き先は経路表(ルートテーブル)で決め、ほかのネットワークとはゲートウェイでつなぎます。たとえば、インターネットとはインターネットゲートウェイでつなぎ、AWS のサービスへは、インターネットを通さずに VPC エンドポイントでつなげます。社内のネットワークとは、Site-to-Site VPN や、中継の仕組み(トランジットゲートウェイ)を使ってつなぎます。
障害に備えてサーバーを複数のアベイラビリティゾーンに分けて置くには、サブネットもゾーンごとに用意します。配置の考え方は、リージョンとアベイラビリティゾーン。障害に備えた配置の考え方で説明しています。
住所の範囲は、重ならないように先に決める
VPC の住所の範囲は、作った後に大きさを変えられないため、作る前に計画します。
AWS は、VPC を作るときは、RFC 1918 で定められた私的な住所の範囲(10.0.0.0〜10.255.255.255、172.16.0.0〜172.31.255.255、192.168.0.0〜192.168.255.255)から選ぶよう勧めています。1つの範囲の大きさは、/16(65,536個)から /28(16個)までで、作った範囲の大きさは後から増やしも減らしもできません(別の範囲を足すことはできます)。また、つなぐ相手の VPC や、専用線で同じゲートウェイにつながる VPC と、住所の範囲が重なってはいけない、とされています。
社内のネットワークとつなぐ予定がある場合は、社内で使っている住所の範囲を確かめ、重ならない範囲を選びます。社内の機器が 192.168.0.0 から始まる範囲を使っている場合に、クラウドの側でも同じ範囲を選ぶと、つないだときに通信の行き先が決まらなくなります。将来、別の拠点や、M&A で加わった会社のネットワークとつなぐ可能性も考え、余裕を持った範囲を、会社全体の住所の割り当ての表で管理しておくと安心です。
公開する部分と公開しない部分を分ける
サブネットは、インターネットから直接届く「公開する側」と、届かない「公開しない側」に分けて使います。
| 置く場所 | 置くものの例 |
|---|---|
| 公開する側のサブネット | 外からの要求を受けるロードバランサー |
| 公開しない側のサブネット | Webアプリケーションのサーバー、データベース、社内向けのシステム |
データベースや社内向けのシステムを公開しない側に置き、外からの要求はロードバランサーなどの入口だけで受ける形にすると、設定を誤ったときに外から直接つながる範囲を小さくできます。サーバーの管理のための接続も、インターネットに管理用の入口を開けるのではなく、社内からの VPN や、管理のための中継の仕組み(踏み台サーバーなど)を通すようにします。
サーバーごとの通信の許可(AWS ではセキュリティグループ)は、必要な相手と必要な番号(ポート)だけに絞ります。公開の範囲を広げすぎる設定は、想定していない相手からの接続を許す原因になります。設定の誤りを防ぐ考え方は、クラウドの設定ミスによる情報漏えいと、防ぎ方にまとめています。
社内との接続:VPN と専用線
社内のネットワークとクラウドをつなぐ方法は、大きく分けて、インターネット越しに暗号化した通信路を作る VPN と、通信の事業者を通した専用の接続(専用線)の2つです。
Microsoft は、Azure の専用の接続である ExpressRoute について、通信の事業者の助けを借りて、社内のネットワークを Microsoft のクラウドへ私的な接続で延ばすもので、公衆のインターネットを通らないため、一般的なインターネット越しの接続より、信頼性・速さ・遅延の安定・セキュリティの面で優れる、と説明しています。
出典:What is Azure ExpressRoute?(Microsoft Learn)
Google Cloud は、費用を抑えたい場合や、帯域の要求が小さい場合、ワークロードの移行を試す段階では Cloud VPN を、高い帯域の企業向けの接続が要る場合は Cloud Interconnect を選ぶよう案内しています。Cloud Interconnect の上で社内と Google のネットワークの間の通信を暗号化したい場合は、HA VPN を組み合わせる方法が案内されています。
出典:Choosing a Network Connectivity product(Google Cloud)
まずは VPN で始め、通信の量が増えたときや、遅延の安定が業務に要るようになったときに専用線を検討する、という順番が、無理のない進め方です。専用線は、敷設に時間がかかることがあるため、必要になりそうな時期が見えた段階で、通信の事業者に確かめておきます。VPN の機器そのものの脆弱性への備えも、接続の設計とあわせて考えます。
設計の前に確かめること
ネットワークの設計を始める前に、次の点を確かめておくと、後からの作り直しを減らせます。
- 社内・拠点・ほかのクラウドで使っている住所の範囲
- クラウドに置くシステムのうち、インターネットに公開するものと、社内からだけ使うもの
- 社内とクラウドの間を流れる通信の量の見込みと、遅延の許される範囲
- 管理のための接続を、誰が、どこから行うか
- 通信の記録(フローログなど)を、どこに、どれだけの期間残すか
5つ目の通信の記録は、不正な通信に気づくためにも、障害の原因を調べるためにも役立ちます。クラウドの外へ出ていく通信には料金がかかるため、通信の量の見込みは費用の見積もりにも使います。
当社のご支援
当社は、クラウドのネットワークの住所の計画、サブネットの分け方、社内や拠点との VPN・専用線での接続の設計と構築、移した後の運用管理を、クラウドの構築と運用管理でお手伝いしています。いまの設定に公開しすぎの部分がないかを確かめたい場合は、セキュリティ診断と対策でもご相談いただけます。
- クラウド
- ネットワーク
- VPN
- 専用線
この記事に出てくる用語
このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。