【入門編】インターネット非接続プライベートサブネットにおけるソフトウェアアップデート時の通信要件 – クラウド＆コンテナネットワーク実践ガイド

皆さん、こんにちは！技術メディア「クラウドの深淵を覗く者たち」主筆ライターの私がお届けする、SRE視点のディープな解説ブログへようこそ！

今日のテーマは、クラウドの世界では当たり前のように使われているのに、実はその裏側で色々な工夫が凝らされている「インターネット非接続のプライベートサブネット」についてです。

「インターネットに繋がってないのに、どうやってソフトウェアをアップデートするの？」
「パッケージマネージャー（yumとかaptとか）って、どうやってインターネットからファイルを持ってくるの？」

そう思ったことはありませんか？まさに今日の主役は、そんな皆さんの素朴な疑問に答えるためのキーパーソン、NATゲートウェイと、それにまつわる「宛先IPホワイトリスティングの課題と対策」です！

小難しい話は抜きにして、皆さんの身近な世界の例え話を交えながら、パケットがネットワークを駆け巡るリアルな挙動を一緒に紐解いていきましょう。一歩ずつ理解を深めていきましょうね！

—

## クラウドの基本のキ！パブリックとプライベート、その違いって何？

まず、クラウドの世界でよく聞く「パブリックサブネット」と「プライベートサブネット」って何でしょう？

とってもシンプルに言うと、

パブリックサブネット：インターネットから直接アクセスできる「表玄関」のような場所。
例えるなら、「番地と部屋番号が公開されている自宅の住所」みたいなものですね。誰でも郵便物を送れますし、宅配便も直接届きます。
プライベートサブネット：インターネットから直接アクセスできない「裏口」や「関係者以外立ち入り禁止」の場所。
こちらは「郵便局留め」や「会社の受付を挟んで入る社内フロア」に似ています。外部の人が直接あなたのデスクにやってくることはできません。

ほとんどの企業では、セキュリティをしっかり確保するために、データベースサーバーやアプリケーションサーバーといった「外から直接触られたくない重要なシステム」は、このプライベートサブネットに配置するのが一般的です。

セキュリティはバッチリ！…なんですが、ここで一つの疑問が生まれます。

「じゃあ、プライベートサブネットにあるサーバーが、インターネット上にあるソフトウェアのアップデート（OSのパッチとか、新しいライブラリとか）をしたい時、どうすればいいの？」

そうですよね、インターネットに繋がってないんだから、普通は何も持ってこれません。まるで「郵便局留め」にしているのに、こちらから外部に郵便物を送りたい時と同じです。どうにかして外の世界と通信する方法が欲しい…！

そこで登場するのが、今日の主役の一人、NATゲートウェイなんです！

## プライベートサブネットからインターネットへ！NATゲートウェイの魔法

プライベートサブネット内のサーバーが、インターネット上にある「OSのパッケージリポジトリ」（yumやaptがソフトウェアを取りに行く場所）や、外部のAPIサービスなどにアクセスしたい時、どうすればいいのでしょうか？

直接アクセスはできませんが、裏口からこっそり外に出る「抜け道」を用意してあげれば良いんです。その抜け道こそが、NATゲートウェイの役割になります。

NATゲートウェイは、例えるなら「郵便局の転送サービス」や「会社の代表電話」のようなものです。

1. 郵便局の転送サービス：

あなたが「郵便局留め」にしていると、外部の人はあなたの住所を知りません。
でも、あなたがどこかのお店に注文した荷物は、お店から一度郵便局に届き、そこからあなたに「転送」される形で受け取れますよね。そしてあなたが誰かに手紙を送りたい時は、郵便局を経由して送ることができます。
NATゲートウェイは、この「郵便局」のような役割を果たします。プライベートなサーバーから来た通信を、自分の公開された住所（IPアドレス）に変換してインターネットに送り出します。

2. 会社の代表電話：

会社の社員（プライベートサブネット内のサーバー）が外部の顧客（インターネット）に電話をかける時、社員個人の電話番号ではなく、会社の「代表電話番号」（NATゲートウェイの持つパブリックIPアドレス）を使って発信することが多いですよね。
そうすることで、外部からは会社の代表番号だけが見えて、個々の社員の番号は隠蔽されます。

### NATゲートウェイの仕組みをもう少しだけ詳しく

NATゲートウェイは、プライベートサブネット内のインスタンス（サーバー）が持っているプライベートIPアドレスを、自分自身が持つパブリックIPアドレスに「変換（NAT: Network Address Translation）」して、インターネットに通信を送り出します。

そして、インターネットからの応答（例えば、OSアップデートのファイルなど）が戻ってきたら、今度はそのパブリックIPアドレス宛の通信を、元のプライベートIPアドレスに変換して、適切なインスタンスに届けてくれるんです。

これにより、プライベートサブネット内のサーバーは、インターネットから直接アクセスされることなく、安全に外部と通信できるようになるわけです。素晴らしいですよね！

## セキュリティの番人たち：ネットワークACLとセキュリティグループ

NATゲートウェイでインターネットへの出口は確保できました。しかし、これだけではまだ不十分です。セキュリティの観点からは、むやみやたらに通信を許可するわけにはいきません。

そこで登場するのが、クラウド環境におけるセキュリティの番人、ネットワークACLとセキュリティグループです。

ネットワークACL（ネットワークアクセスコントロールリスト）：
これは「建物の入り口にいる警備員」のようなものです。サブネット全体への出入りを制御します。
「このサブネットには、このIPアドレスからの通信しか入れないぞ！」「このサブネットから外には、この種類の通信しか出さないぞ！」という、かなり大雑把だけど強力なルールを設定できます。
セキュリティグループ：
こちらは「各部屋の鍵」のようなものです。個々のサーバー（インスタンス）への出入りを制御します。
「このサーバーには、Webアクセス（ポート80/443）だけ許可するぞ！」「このサーバーからは、外部へのアップデート通信（ポート80/443）だけ許可するぞ！」といった、よりきめ細やかなルールを設定できます。

これらを組み合わせることで、プライベートサブネット内のサーバーがNATゲートウェイを通じてインターネットにアクセスする際も、「HTTPS（ポート443）での通信だけを許可する」といった具体的なルールを設け、不要な通信をシャットアウトし、セキュリティをさらに強化できるのです。

## 本題へ！ソフトウェアアップデートの壁：変化するIPアドレス問題

さあ、これでプライベートサブネット内のサーバーも、NATゲートウェイを経由してインターネットにアクセスし、yum updateやapt upgradeでOSを最新に保つことができるようになりました。めでたしめでたし！

…と、思いきや、ここで一つ大きな問題が浮上します。それが今日のメインテーマ、「宛先IPホワイトリスティングの課題」です。

セキュリティ意識の高い現場では、「インターネットへの通信は、必要な宛先だけに限定する」というポリシーがよく採用されます。
つまり、「このIPアドレスには通信を許可するけど、それ以外はダメ！」というホワイトリスト方式で通信を制御するわけです。

これは非常に堅牢なセキュリティ対策ですよね。しかし、ソフトウェアアップデートの際にアクセスする「OSのパッケージリポジトリ」や「外部ライブラリのダウンロード元」のIPアドレスは、果たして固定されているでしょうか？

残念ながら、ほとんどの場合、固定されていません！

多くのベンダーは、世界中のユーザーに高速でコンテンツを配信するために、CDN（Content Delivery Network）を利用しています。
CDNは、ユーザーの場所に応じて最適なサーバー（IPアドレス）に誘導したり、負荷分散のためにIPアドレスを動的に変更したりします。
また、AWSなどのクラウドプロバイダーが提供するソフトウェアリポジトリ（例えばAmazon Linuxのyumリポジトリ）も、リージョンやサービス状況に応じてIPアドレスが変動する可能性があります。

つまり、「このリポジトリのIPアドレスは X.X.X.X だから、ホワイトリストに追加しよう！」と思っても、明日にはそのIPアドレスが変わっているかもしれないのです。

これは困りましたね。「郵便局の転送サービスは利用できるけど、送る先の住所が毎回変わっちゃう！」というような状況です。毎回住所を調べてリストを更新するなんて、現実的ではありませんし、セキュリティルールが頻繁に変わるのは運用上もリスクになります。

この「変動する宛先IPアドレス」という課題に、どう立ち向かえば良いのでしょうか？

## 解決策その1：FQDNベースのフィルタリング（マネージドサービス活用）

最初の解決策は、IPアドレスではなく、ドメイン名（FQDN: Fully Qualified Domain Name）で通信を許可するというアプローチです。

「repo.example.comにはアクセスを許可するけど、それ以外はダメ！」というように、IPアドレスの変動を気にせず、人間が識別しやすいドメイン名でルールを設定できれば、管理がぐっと楽になりますよね。

しかし、一般的なネットワーク機器（ルーターやファイアウォール）では、通信が始まった時点ではIPアドレスしか見ていないため、ドメイン名でフィルタリングするのは実は難しいのです。

そこで登場するのが、AWSでいうところのAWS Network Firewallや、GCPでいうところのCloud Next Generation Firewallといった、高機能なマネージドファイアウォールサービスです。

これらのサービスは、パケットの中身を深く検査する機能（ディープパケットインスペクション）を持っており、通信先のIPアドレスだけでなく、その通信がどのドメイン名に対して行われているかまでを判別し、ルールに基づいて許可・拒否を決定できます。

メリット：

IPアドレスの変動を気にしなくて済むため、運用が非常に楽になります。
より詳細なレベルで通信を制御でき、セキュリティが向上します。
ファイアウォール自体の運用・保守をクラウドプロバイダーに任せられます。

デメリット：

高性能なマネージドサービスであるため、コストがかかる場合があります。
導入や設定には、ある程度の専門知識が必要になることもあります。

## 解決策その2：プロキシサーバーの活用（オンプレミス的なアプローチ）

もう一つの解決策は、プライベートサブネット内にプロキシサーバーを立てる方法です。

プロキシサーバーは、例えるなら「社内から外部へのインターネット接続をすべて一手に引き受ける部署」のようなものです。

1. プライベートサブネット内のサーバーは、直接NATゲートウェイに向かうのではなく、まずプロキシサーバーに「このURLにアクセスしたい！」と依頼します。
2. プロキシサーバーは、その依頼を受けて、インターネット上のリソース（パッケージリポジトリなど）にアクセスします。
3. プロキシサーバーは、インターネットからの応答を受け取ると、それを依頼元のサーバーに返します。

このプロキシサーバーが、プライベートサブネットからインターネットへの唯一の出口となります。そして、このプロキシサーバー上で、どのドメイン名へのアクセスを許可するか、どのIPアドレスへのアクセスを許可するかといったルールを詳細に設定できるのです。

例えば、オープンソースのSquidのようなプロキシソフトウェアを利用すれば、特定のURLやFQDNのみを許可する設定が可能です。

メリット：

きめ細やかなアクセス制御が可能です。
すべての通信がプロキシサーバーを経由するため、通信ログの一元管理が容易になります。
キャッシュ機能を持つプロキシであれば、同じファイルのダウンロードを高速化することもできます。
クラウドプロバイダーのマネージドサービスに依存しない、柔軟な運用が可能です。

デメリット：

プロキシサーバー自体を構築し、運用・保守する必要があります（OSのアップデート、セキュリティパッチ適用、監視など）。
プロキシサーバーが単一障害点にならないよう、高可用性を考慮した設計（複数台構成やロードバランサーの導入など）が必要になります。
サーバーを立てる分のコストや、運用負荷が発生します。

## 実践例：AWSでの設定イメージ

ここまで、色々な概念を見てきました。では、具体的にAWS環境でどのような設定が必要になるのか、そのイメージを掴んでいきましょう。

### 1. VPCとサブネットの作成

まず、クラウド上に仮想ネットワーク（VPC）を作成し、その中に「パブリックサブネット」と「プライベートサブネット」を用意します。

### 2. NATゲートウェイの配置とルートテーブルの設定

パブリックサブネットにNATゲートウェイを配置し、プライベートサブネットのルートテーブルに、インターネット（0.0.0.0/0）への通信はNATゲートウェイを経由するように設定します。

# AWS VPC プライベートルートテーブルの例
# 説明: プライベートサブネットからインターネット(0.0.0.0/0)への通信は、
#       このNATゲートウェイを経由するようにルーティングを設定します。
#       これにより、プライベートなインスタンスがインターネットにアクセスできるようになります。
- Destination: 0.0.0.0/0 # すべてのインターネット宛てのトラフィック
  Target: nat-xxxxxxxxxxxxxxxxx # 作成したNATゲートウェイのIDを指定します

*補足：このルートテーブルを、プライベートサブネットに関連付けます。*

### 3. セキュリティグループでのアウトバウンド許可

プライベートサブネット内のEC2インスタンスにアタッチするセキュリティグループで、必要な通信（OSアップデートであればHTTPS/HTTPなど）のアウトバウンド（外向き）通信を許可します。

# AWS セキュリティグループの例 (プライベートサブネット内のEC2インスタンス向け)
# 説明: このセキュリティグループをアタッチしたEC2インスタンスが、
#       外部のWebサイトやパッケージリポジトリにアクセスできるよう、
#       HTTPS (443) と HTTP (80) のアウトバウンド通信を許可します。
#       通常、インバウンドルールは、内部からのアクセス（アプリケーション、DB等）や
#       管理アクセス（SSHなど）を許可しますが、ここではアウトバウンドに焦点を当てます。

---
# アウトバウンドルール1: HTTPS (ポート443)
- Direction: "Outbound" # 外向きの通信に対するルールです
  Protocol: "TCP"      # プロトコルはTCP
  PortFrom: 443        # 宛先ポートは443（HTTPSの標準ポート）
  PortTo: 443          #
  Destination: "0.0.0.0/0" # 宛先IPアドレスは全て（インターネット全体）
  Description: "Allow outbound HTTPS for software updates and external APIs" # 説明

---
# アウトバウンドルール2: HTTP (ポート80)
- Direction: "Outbound" # 外向きの通信に対するルールです
  Protocol: "TCP"      # プロトコルはTCP
  PortFrom: 80         # 宛先ポートは80（HTTPの標準ポート）
  PortTo: 80           #
  Destination: "0.0.0.0/0" # 宛先IPアドレスは全て（インターネット全体）
  Description: "Allow outbound HTTP for some older repositories or initial redirects" # 説明

*補足：上記の0.0.0.0/0は「全てのIPアドレス」を意味します。ここを特定のIPアドレス範囲に限定しようとすると、IPアドレス変動問題に直面するわけですね。*

### 4. 宛先IPホワイトリスティングの課題への対応（解決策の適用）

そして、上記の「宛先0.0.0.0/0」を、より細かく制御したい場合に、先ほどの解決策を適用します。

マネージドファイアウォール（AWS Network Firewallなど）を使う場合：
VPCのトラフィックをNetwork Firewallに通すようにルーティングを設定し、Firewall側でFQDNベースのルール（*.amazon.com、*.ubuntu.comなど）を設定します。
プロキシサーバーを使う場合：
プライベートサブネット内にプロキシサーバー（例：Squid）を立て、そのプロキシサーバーのセキュリティグループで、外部への必要なポート（443, 80など）を許可します。
プライベートサブネット内のインスタンスのルートテーブルを調整し、インターネットへの通信はプロキシサーバーを経由するように設定します。
インスタンス側の環境変数（http_proxy, https_proxy）を設定し、プロキシ経由で通信するようにします。

## まとめ：セキュリティと利便性のバランスを追求するSREの視点

今日のブログでは、インターネット非接続のプライベートサブネットで、いかにしてソフトウェアアップデートを行うか、そしてその際に直面する「宛先IPアドレスの変動問題」と、その解決策について深掘りしてきました。

振り返ってみると、

プライベートサブネットがセキュリティの要であること。
NATゲートウェイがプライベートな場所からインターネットへの安全な出口を提供すること。
yumやaptでのアップデート時に、宛先IPアドレスが変動する問題があること。
その解決策として、FQDNベースのマネージドファイアウォールやプロキシサーバーがあること。

これらの知識は、クラウド上で安全で堅牢なシステムを構築し、運用していく上で非常に重要です。

完璧な正解というものはなく、皆さんのシステムの要件、コスト、運用体制に応じて、最適な解決策は変わってきます。セキュリティを最優先するのか、それとも運用負荷の軽減を優先するのか、SREとしては常にこのバランスを考え、最適なアーキテクチャを設計していくことが求められます。

今日の記事が、皆さんのクラウドネットワークの理解を深める一助となれば幸いです。
それでは、また次回の記事でお会いしましょう！安全で楽しいクラウドライフを！