In Silico

クラウド

VPCとは？クラウドの仮想ネットワークの基本をわかりやすく解説

2026/10/13 シリーズ「クラウド入門」 第4回 / 全5回

🤖 AIを使用して執筆

  • VPC
  • 仮想ネットワーク
  • サブネット
  • クラウド
  • セキュリティグループ
  • ファイアウォール
  • ルートテーブル
  • インターネットゲートウェイ
  • NAT ゲートウェイ
  • AWS
  • Azure
  • Google Cloud
  • Amazon VPC
  • Azure Virtual Network
  • ネットワーク セキュリティ グループ
  • ネットワーク ACL
  • VPN
  • AWS Direct Connect
  • ExpressRoute
  • プライベート IP アドレス
  • CIDR
  • パブリックサブネット
  • プライベートサブネット
  • ゼロトラスト
  • セキュリティ
目次
背景・問い・要点
背景

自社のサーバー室では、機械は社内のネットワークの中にあり、外とつなぐ出入口は一つか二つだった。クラウドでは、機械もデータベースも事業者の建物の中にあり、事業者のネットワークは多くの利用者が共用している。そのため、借りた機械をどのネットワークに置き、どこから届くようにするかを、利用者が自分で設計することになる。この、利用者が設計する仮想ネットワークを、VPC（Virtual Private Cloud）と呼ぶ。ネットワークの設計を誤ると、権限をどれだけ絞っていても、外から届くはずのない要求が機械に届く。本稿は、VPC の部品と、各社の既定の設定、2009 年からの歴史、公開された設定の誤りの報告を順に取り上げる。

問い

VPC とは何で、どのような部品からできているのか。クラウドの機械を、どこまで外から届くようにすればよいのか。

要点

VPC は、事業者のネットワークの中に切り分けた、利用者が自分で設計する仮想ネットワークである。どこからどこへ通信が届くかは、サブネット、経路、通信を許可する規則の三つで利用者が決める。各社の既定の設定は使い始めやすさに寄っているので、外に開く範囲は利用者が絞る必要がある。 サブネットは、VPC のアドレスの範囲を区切ったものである。AWS では、インターネット宛ての通信をインターネットとの出入口へ送る経路を持つサブネットをパブリックサブネット、その経路を持たないものをプライベートサブネットと呼ぶ。外から機械に届くには、さらに公開の IP アドレスと、それを許す規則が要る。通信を通すかどうかは、セキュリティグループやファイアウォールの規則で決める。NIST（米国国立標準技術研究所）は 2009 年の指針で、明示的に許可していない通信を止める「既定で拒否」を原則とし、内向きの通信にはこの方針を使うよう求めている。三社の既定も内向きは止めるものが多いが、AWS の既定の VPC はパブリックサブネットで機械に公開の IP アドレスが付き、Google Cloud の既定のネットワークには SSH などを世界中から受け付ける規則がある。設定の誤りは大手の事業者自身にも起きる。Microsoft は、ネットワーク セキュリティ グループの規則の誤りで、社内のサポート用のデータベースが 2019 年 12 月の 26 日間、外から見える状態になっていたと公表した。

モデル・例示

オンライン英会話の予約サイトを区画に分ける

※ この節の数値は説明のための仮定で、測定値ではありません。

オンラインの英会話教室が、予約のサイトをクラウドで動かしているとする。機械は三つある。生徒が予約を入れる Web サーバー、生徒の名前や支払いの記録を入れるデータベース、事務所の職員が使う管理画面のサーバーである。

この三つを、どこから届くようにするかは、それぞれ違う。Web サーバーは、世界中の生徒の端末から届かなければ困る。データベースは、Web サーバーと管理画面のサーバーからだけ届けばよく、インターネットから直接届く必要はない。管理画面は、事務所からだけ届けばよい。

VPC では、この区別を、ネットワークの区画と規則で表す。Web サーバーはインターネットに出入りできる区画に置き、データベースと管理画面のサーバーは、インターネットへの出入口を持たない区画に置く。事務所とは、暗号化した専用の通路でつなぐ。通信を許可するときは、相手と、通信の種類を表す番号（ポート番号）を指定する。この設計のもとで、四つの要求がどう扱われるかを並べると、次のようになる。

  1. 外の端末Web サーバー1. 生徒が予約の画面を開く。公開の区画で、許可した番号なので届く
  2. 外の端末データベース2. 外からデータベースにつなごうとする。公開のアドレスも外への経路もなく届かない
  3. Web サーバーデータベース3. 予約を書き込む。Web と管理画面のサーバーだけを許可しているので届く
  4. 外の端末Web サーバー4. 遠隔操作用の番号（SSH）につなごうとする。許可していないので届かない
※概念図（やりとり）：本文の手順を図式化したもの。

データベースが守られる理由は二つある。一つは、データベースに公開の IP アドレスがなく、その区画からインターネットへの経路もないことで、外からは宛先にすることさえできない。もう一つは、データベースが Web サーバーと管理画面のサーバーからの通信だけを許可していることで、同じ VPC の中のほかの機械からも届かない。どちらか一方の設定を誤っても、もう一方が残っていれば、すぐには外から読まれない。

VPC とは：事業者のネットワークの中に切り分けた自分のネットワーク

AWS は Amazon VPC を、利用者が定義した、論理的に隔離された仮想ネットワークの中で AWS の資源を動かせるサービスと説明し、利用者のデータセンターで運用してきた従来のネットワークによく似ていると書いている1。Azure の Azure Virtual Network、Google Cloud の VPC ネットワークも同じ考え方の製品である23。NSA と CISA の 2024 年の文書は、こうした論理的に隔離された仮想ネットワークを、各社に共通して VPC と呼ぶことがあると書いている4。

「論理的に隔離された」とは、物理的には多くの利用者が同じ機械と同じ配線を使っていながら、ソフトウェアの働きで、それぞれの利用者からは自分だけのネットワークに見えるということである。この仕組みはネットワークの仮想化と呼ばれる。VMware の Koponen らは 2014 年の論文で、一つの物理的なネットワークの上に、それぞれ独立したアドレスの付け方と構成を持つ仮想ネットワークを作る層という理解が、広く共有されているようだと書いている5。Google の Dalton らは 2018 年の論文で、Google Cloud の仮想化の仕組み Andromeda を説明し、ネットワークの仮想化の最も基本の要件を、利用者ごとに隔離した仮想ネットワークを用意し、その中の仮想マシンが自分だけのネットワークで動いているように見せることだとしている6。

VPC の中の機械には、外の世界とは別のアドレスを付ける。1996 年の RFC 1918 は、組織の内部で使うために、10.0.0.0 から始まる範囲など三つのアドレスの範囲を予約した7。この範囲のアドレスはプライベート IP アドレスと呼ばれ、誰とも調整せずに使える。その代わり、ほかの組織と同じアドレスを使っていることがあり、重ならないのは一つの組織の中だけである7。AWS の既定の VPC が使う 172.31.0.0/16 も、この範囲の中にある8。「/16」は、アドレスを表す 32 桁の 2 進数のうち、先頭の 16 桁がネットワークを表すという書き方で、CIDR と呼ばれる9。172.31.0.0/16 なら、最大で 65,536 個のアドレスを使える8。

サブネット・経路・許可の規則：三つの部品

VPC の設計は、三つの部品で表される。

Azure では、ネットワーク セキュリティ グループが許可の規則を持ち、許可と拒否の両方を書ける。規則は優先度の番号の小さいものから順に調べ、一致したところで止まる17。Google Cloud では、VPC のファイアウォールの規則がこの役を担う。Azure のネットワーク セキュリティ グループも、Google Cloud のファイアウォールの規則も、AWS のセキュリティグループと同じくステートフルである1718。

区画が及ぶ範囲は、製品によって違う。AWS のサブネットは一つのアベイラビリティーゾーン（同じ地域の中で、電源や建物を分けたデータセンターの集まり）の中にしか置けない1。Azure の仮想ネットワークとサブネットは、地域の中のすべての可用性ゾーンにまたがる2。Google Cloud の VPC ネットワークは特定の地域に属さない全世界の資源で、サブネットが地域ごとに置かれる3。

既定で拒否する原則と、各社の既定の設定

通信の規則の書き方には、古くからの原則がある。NIST の 2009 年のファイアウォールの指針は、ファイアウォールの方針で明示的に許可していない通信は止めるべきだとし、これを「既定で拒否（deny by default）」と呼んでいる19。機械やネットワークや使う仕組みは変わり続けるので、禁止したもの以外を通すより、許可したもの以外を止めるほうが安全だというのが、その理由である19。同じ指針は、内向きの通信にはこの方針を使うべきだとする一方、外向きの通信には、利用者が外の多くのサービスを使うので、一般に緩い方針が使われているとも書いている19。

各社の既定の設定を見ると、内向きの通信は、規則を書くまで届かないものが多い。AWS のセキュリティグループは、作った直後は内向きの規則がなく、規則を足すまで内向きの通信は届かない15。Azure では、ネットワーク セキュリティ グループを作ると、同じ仮想ネットワークの中などからの通信を除いて、内向きの通信を拒否する既定の規則が入る17。Google Cloud にも、仮想マシンへの内向きの通信を拒否する暗黙の規則がある20。

ただし、既定のままで外に開いている部分もある。

使い始めやすさを優先した既定である。AWS 自身、既定の VPC は、すぐに始める場合や、ブログのような公開の機械を動かす場合に向いていると書いている22。既定を変える動きもある。Azure は、2026 年 3 月 31 日より後に出た版の API（設定を操作するための窓口）で作る新しい仮想ネットワークでは、サブネットを既定でプライベートにし、インターネットへ出るには明示的な方法を用意させるとしている23。NSA と CISA の文書は、利用者は既定の規則が何かを知り、必要なら、外からの通信をすべて拒否する方針を自分で設定するよう求めている4。

隔離から始まった VPC の歴史

VPC は、最初から今の形だったわけではない。AWS の初期の仮想マシンのネットワーク（後に EC2-Classic と呼ばれた）は平らなネットワークで、仮想マシンには起動したときに公開のアドレスが付いた24。

AWS は 2009 年 8 月、Amazon VPC を限定のベータ版として公開した25。最初の Amazon VPC は、会社の既存のネットワークと、隔離した AWS の資源を、暗号化した通路（VPN）でつなぐ橋として説明されていた25。インターネットへの直接の出入口はなく、VPC の中の機械からインターネットへ向かう通信は、すべて VPN を通って会社のネットワークへ戻り、会社のファイアウォールを通ってから外へ出た26。AWS の Jeff Barr は、初期に話を聞いた利用者の多くが、仮想マシンを完全に隔離し、すべての通信を自社のデータセンターに戻すことを望んだので、その機能を最優先にしたと書いている26。

2011 年には、インターネットへの直接の出入口、ルートテーブル、サブネットの間の通信を制御するネットワーク ACL が加わった27。2013 年には、新しい利用者と、その地域で初めて仮想マシンを作る利用者に、自動で VPC を用意する既定の VPC が導入され、2013 年 12 月 4 日より後に作られたアカウントは VPC だけを使うようになった2724。平らなネットワークの退役は、2023 年 8 月 23 日に完了したと告知されている24。

この流れは、隔離から始まり、2011 年に外への出入口を利用者が選んで開けられるようになり、2013 年には、それまでの使い方との互換を保つために、公開のアドレスを付けた状態が既定になった、とまとめられる27。Barr は、既定の VPC の機械に公開のアドレスを付けるのは、用意された経路表とインターネットゲートウェイを前提にすれば妥当な既定だと書いている27。

社内のネットワークとつなぐ方法

英会話教室の管理画面のように、事務所や社内のネットワークからだけ使う機械もある。社内とクラウドをつなぐ方法は、大きく二つある。

一つは、インターネットの上に暗号化した通路を作る、拠点間の VPN である。AWS の Site-to-Site VPN、Azure の VPN Gateway、Google Cloud の Cloud VPN がこれにあたる12829。もう一つは、通信の事業者を通した専用の回線で、インターネットを通らずにつなぐ方法である。AWS は 2011 年に AWS Direct Connect を始め30、Microsoft は 2014 年 5 月に ExpressRoute の一般提供を始めたと書いている31。Google Cloud では Cloud Interconnect がこれにあたる32。

クラウドの事業者自身のサービスを使うときにも、インターネットを通らない道がある。AWS の VPC エンドポイントを使えば、インターネットゲートウェイや NAT を通さずに、AWS のサービスへインターネットを通らない経路でつなげる1。NSA と CISA の文書も、一部の事業者はこうした接続口を用意しており、使えば事業者の API への通信をクラウドの中にとどめられると書いている4。

公開された設定の誤りの報告

ネットワークの規則の誤りが、データを外から見える状態にした例は、事業者自身の報告にもある。

Microsoft は 2020 年 1 月 22 日、サポートの案件の分析に使っていた社内のデータベースについての調査結果を公表した33。2019 年 12 月 5 日にデータベースのネットワーク セキュリティ グループに加えた変更に、誤った規則が含まれ、データが外から見える状態になった。通報を受けて、12 月 31 日に設定を直した33。Microsoft は、悪用は見つからず、記録の大半は個人情報を消してあったとしたうえで、設定の誤りは、残念ながら業界に共通する誤りだと書いている。誤りを防ぐ仕組みは持っていたが、このデータベースでは有効になっていなかった33。再発を防ぐ手立てとして挙げたのは、社内の資源のネットワークの規則を監査すること、規則の誤りを見つける仕組みの範囲を広げること、誤りを見つけたときに担当の部署へ知らせることなどである33。

2019 年の Capital One の事件でも、入口はネットワークの側にあった。連邦捜査局（FBI）の捜査官が裁判所に出した刑事告訴状によれば、ファイアウォールの設定の誤りから、外から送った命令が特定のサーバーに届き、実行できる状態になっていた34。米通貨監督庁（OCC）も、Capital One が、ネットワークセキュリティの管理を適切に設計し実装していなかったと認定している35。この事件では、外からの要求を通してしまったネットワークの誤りに、通った要求がロール（IAM で権限を持たせる ID）の資格情報を手に入れ、そのロールに権限のあるデータを写せたことが重なった34。

区切ることの価値と、ネットワークだけに頼らない考え方

ネットワークを区切る設計を強く勧めているのは、政府の文書である。NSA と CISA は、ネットワークを区切ることを、正しく実装すれば悪意のある活動をネットワークの一部に閉じ込め、侵入の影響を小さくできる基本の原則だとしている4。事業者は利用者の間をある程度隔離すべきだが、自分の区画の中のネットワークを正しく設定するのは利用者の責任だとも書く4。そのうえで、必要のない機械では SSH を止め、公開のアドレスは本当に必要な機械だけに付け、理想としては通常の業務に要る通信の道だけを許可するよう求めている4。同じ文書は、境界だけを固める守りでは、最初の防御を破った攻撃者が中の通信や資源に届いてしまうとして、現代のクラウドでは境界の守りだけでは足りないとも書いている4。総務省のガイドラインも、クラウドはインターネット経由で使うので、仮想プライベートクラウドのセキュリティの設定や境界の防御を確実に行う必要があるとしている36。

一方、区切りの中にあることを信頼の根拠にすること自体には、疑問も出されている。NIST の 2020 年のゼロトラストの文書は、ネットワーク上の位置だけを根拠に信頼を与えないことを前提にし、守る対象はネットワークの区画ではなくリソースだとしている37。Microsoft も PaaS の安全な使い方の指針で、自社でサーバーを持つ環境ではネットワークが主なセキュリティの境界だったが、現代の守りは攻撃者がネットワークの境界を破っていると仮定し、アイデンティティ（誰が、どのプログラムが要求しているか）へ移っていると書いている38。VPC の中にあるからといって安全とは限らず、中の機械どうしの通信も、要求ごとに相手と権限を確かめるべきだという考え方である。

どの文書も、区切りを捨てよとは言っていない。NIST のゼロトラストの文書も、資源ごとに小さな区画を作り、その入口で要求を確かめる方式（マイクロセグメンテーション）を、ゼロトラストの実装の一つとして挙げている37。NIST の 2016 年の文書も、ネットワークを区切ることを、何重にも守る戦略の一部か、少なくともその最初の一歩と考える実務家がいると書いている39。違いは、区切りの中にあることを、信頼してよい理由として扱うかどうかにある。英会話教室の予約サイトでいえば、データベースを公開しない区画に置き、Web サーバーと管理画面のサーバーからだけ許可したうえで、データベースへの接続にも、接続してくる側の ID と権限の確認を求めることになる。

ここまでの設計で、どの機械がどこから届くかは決められる。しかし、Web サーバーそのものは、借りた仮想マシンのままである。OS の更新を当て、台数を増やし、壊れたら作り直すのは、利用者の仕事として続く。機械をどこまで借り、どこから事業者に任せるかが、次の問いである。

出典39件

  1. AWS「Amazon VPC とは?」2026年10月13日取得. https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/what-is-amazon-vpc.html — 論理的に隔離された仮想ネットワーク、サブネット、ルートテーブル、ゲートウェイ、VPN。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. Microsoft「Azure Virtual Network とは」2025年7月17日更新、2026年10月13日取得. https://learn.microsoft.com/ja-jp/azure/virtual-network/virtual-networks-overview — 既定の外向きの通信、ゾーンにまたがるサブネット。 ↩ ↩2 ↩3

  3. Google Cloud「VPC ネットワーク」2026年10月9日更新、2026年10月13日取得. https://cloud.google.com/vpc/docs/vpc?hl=ja — 全世界の資源としての VPC ネットワークと、地域ごとのサブネット。 ↩ ↩2

  4. NSA, CISA「Implement Network Segmentation and Encryption in Cloud Environments」2024年3月、2026年10月13日取得（アーカイブ）. https://web.archive.org/web/20240307180414id_/https://media.defense.gov/2024/Mar/07/2003407861/-1/-1/0/CSI-CloudTop10-Network-Segmentation.PDF — 区切りの原則、既定の規則の確認、私的な接続口。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  5. T. Koponen ほか「Network Virtualization in Multi-tenant Datacenters」NSDI 14、2014年4月、2026年10月13日取得. https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-koponen.pdf — ネットワークの仮想化の層の理解。 ↩

  6. M. Dalton ほか「Andromeda: Performance, Isolation, and Velocity at Scale in Cloud Network Virtualization」NSDI 18、2018年4月、2026年10月13日取得. https://www.usenix.org/system/files/conference/nsdi18/nsdi18-dalton.pdf — 利用者ごとに隔離した仮想ネットワーク。 ↩

  7. Y. Rekhter ほか「Address Allocation for Private Internets」RFC 1918、1996年2月、2026年10月13日取得. https://www.rfc-editor.org/rfc/rfc1918.txt — 内部用に予約した三つのアドレスの範囲。 ↩ ↩2

  8. AWS「デフォルト VPC のコンポーネント」2026年10月13日取得. https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/default-vpc-components.html — 172.31.0.0/16 と、インターネットゲートウェイへの経路。 ↩ ↩2

  9. V. Fuller, T. Li「Classless Inter-domain Routing (CIDR)」RFC 4632、2006年8月、2026年10月13日取得. https://www.rfc-editor.org/rfc/rfc4632.txt — /16 の表記の意味。 ↩

  10. AWS「Amazon VPC のインフラストラクチャセキュリティ」2026年10月13日取得. https://docs.aws.amazon.com/vpc/latest/userguide/infrastructure-security.html — 層ごとのサブネット、セキュリティグループとネットワーク ACL の使い分け。 ↩ ↩2

  11. AWS「Enable internet access for a VPC using an internet gateway」2026年10月13日取得. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html — VPC とインターネットの間の通信と、公開の IP アドレスの必要。 ↩ ↩2

  12. AWS「Default subnets」2026年10月13日取得. https://docs.aws.amazon.com/vpc/latest/userguide/default-subnet.html — 既定のサブネットがパブリックサブネットである理由と、公開のアドレス。 ↩ ↩2

  13. AWS「NAT ゲートウェイ」2026年10月13日取得. https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-nat-gateway.html — 外から接続を始められない外向きの接続。 ↩

  14. AWS「Control traffic to your AWS resources using security groups」2026年10月13日取得. https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html — 仮想のファイアウォール、ステートフル。 ↩ ↩2

  15. AWS「Security group rules」2026年10月13日取得. https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html — 許可の規則だけを書けること、作った直後に内向きの規則がないこと。 ↩ ↩2

  16. AWS「Control subnet traffic with network access control lists」2026年10月13日取得. https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html — サブネットの単位、ステートレス。 ↩

  17. Microsoft「Azure network security groups overview」2025年7月15日更新、2026年10月13日取得. https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview — 優先度の順の評価、ステートフル、既定の規則。 ↩ ↩2 ↩3

  18. Google Cloud「VPC firewall rules」2026年10月9日更新、2026年10月13日取得. https://cloud.google.com/firewall/docs/firewalls?hl=en — ステートフル、既定のネットワークの事前に入った規則。 ↩ ↩2

  19. K. Scarfone, P. Hoffman「Guidelines on Firewalls and Firewall Policy」NIST SP 800-41 Rev. 1、2009年9月、2026年10月13日取得. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-41r1.pdf — 既定で拒否。 ↩ ↩2 ↩3

  20. Google Cloud「Firewall policy rule evaluation order」2026年10月13日取得. https://cloud.google.com/firewall/docs/firewall-policies-rule-eval-order?hl=ja — 内向きは拒否、外向きは許可の暗黙の動作。 ↩ ↩2

  21. AWS「Default security groups for your VPCs」2026年10月13日取得. https://docs.aws.amazon.com/vpc/latest/userguide/default-security-group.html — 既定のセキュリティグループの規則。 ↩

  22. AWS「デフォルト VPC」2026年10月13日取得. https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/default-vpc.html — 既定の VPC の構成と、向いている使い方。 ↩ ↩2

  23. Microsoft「Default outbound access in Azure」2026年7月24日更新、2026年10月13日取得. https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/default-outbound-access — 新しい仮想ネットワークのサブネットを既定でプライベートにする変更。 ↩

  24. AWS News Blog（Jeff Barr）「EC2-Classic Networking is Retiring – Here’s How to Prepare」2021年7月28日（2023年8月23日追記）、2026年10月13日取得. https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-heres-how-to-prepare/ — 平らなネットワークと退役の完了。 ↩ ↩2 ↩3

  25. AWS「Introducing Amazon Virtual Private Cloud」2009年8月26日、2026年10月13日取得. https://aws.amazon.com/about-aws/whats-new/2009/08/26/introducing-amazon-virtual-private-cloud/ — 限定のベータ版と、VPN でつなぐ橋としての説明。 ↩ ↩2

  26. AWS News Blog（Jeff Barr）「Introducing Amazon Virtual Private Cloud (VPC)」2009年8月25日、2026年10月13日取得. https://aws.amazon.com/blogs/aws/introducing-amazon-virtual-private-cloud-vpc/ — すべての通信を VPN で戻す初期の形と、その理由。 ↩ ↩2

  27. AWS News Blog（Jeff Barr）「Amazon EC2 Update – Virtual Private Clouds for Everyone!」2013年3月11日、2026年10月13日取得. https://aws.amazon.com/blogs/aws/amazon-ec2-update-virtual-private-clouds-for-everyone/ — 2011年の機能追加と既定の VPC。 ↩ ↩2 ↩3 ↩4

  28. Microsoft「Azure VPN Gateway とは」2026年10月13日取得. https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-about-vpngateways — インターネット経由の暗号化した通信。 ↩

  29. Google Cloud「Cloud VPN の概要」2026年10月13日取得. https://cloud.google.com/network-connectivity/docs/vpn/concepts/overview?hl=ja — IPsec VPN による接続。 ↩

  30. AWS「Announcing AWS Direct Connect」2011年8月3日、2026年10月13日取得. https://aws.amazon.com/about-aws/whats-new/2011/08/03/Announcing-AWS-Direct-Connect/ — 専用の接続の開始。 ↩

  31. Microsoft Azure Blog「ExpressRoute: An overview」2014年6月2日、2026年10月13日取得（アーカイブ）. https://web.archive.org/web/20140613055002id_/http://azure.microsoft.com:80/blog/2014/06/02/expressroute-an-overview/ — 2014年5月12日の一般提供。 ↩

  32. Google Cloud「Cloud Interconnect の概要」2026年10月13日取得. https://cloud.google.com/network-connectivity/docs/interconnect/concepts/overview?hl=ja — 低い遅延と高い可用性の接続。 ↩

  33. Microsoft Security Response Center「Access Misconfiguration for Customer Support Database」2020年1月22日、2026年10月13日取得（アーカイブ）. https://web.archive.org/web/20201231140338id_/https://msrc-blog.microsoft.com/2020/01/22/access-misconfiguration-for-customer-support-database/ — 規則の誤りと期間、再発防止。 ↩ ↩2 ↩3 ↩4

  34. United States v. Paige A. Thompson, Criminal Complaint, No. MJ19-344（W.D. Wash.）、2019年7月29日、2026年10月13日取得. https://www.justice.gov/media/1019711/dl?inline — ファイアウォールの設定の誤り。 ↩ ↩2

  35. OCC「Consent Order for the Assessment of a Civil Money Penalty」AA-EC-2020-36、2020年8月、2026年10月13日取得. https://www.occ.gov/static/enforcement-actions/ea2020-036.pdf — ネットワークのセキュリティの管理の不備の認定。 ↩

  36. 総務省「クラウドサービス利用・提供における適切な設定のためのガイドライン」2022年10月、2026年10月13日取得. https://www.soumu.go.jp/main_content/000843318.pdf — 仮想プライベートクラウドの設定と境界の防御。 ↩

  37. S. Rose ほか「Zero Trust Architecture」NIST SP 800-207、2020年8月、2026年10月13日取得. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf — ネットワーク上の位置だけで信頼を与えないこと。 ↩ ↩2

  38. Microsoft「Best practices for secure PaaS deployments」2026年5月5日更新、2026年10月13日取得. https://learn.microsoft.com/en-us/azure/security/fundamentals/paas-deployments — 境界がネットワークからアイデンティティへ移ったという見方。 ↩

  39. R. Chandramouli「Secure Virtual Network Configuration for Virtual Machine (VM) Protection」NIST SP 800-125B、2016年3月、2026年10月13日取得. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-125B.pdf — 区切りを多層の守りの一部とする見方。 ↩

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。