こんにちは！クラウドインフラやサーバーの管理、そして日々の開発お疲れ様です。
セキュリティの勉強を始めると、「ファイアウォール」や「アクセス制御」といった言葉をたくさん耳にしますよね。「サーバーを外からの攻撃から守る（＝イングレス対策）」については、セキュリティの教科書やネットの記事でもよく見かけると思います。
でも、少し視点を変えてみてください。
「もし、すでにサーバーの中に泥棒（攻撃者）が入り込んでしまったら？」
そして、その泥棒が社内の大切なデータをこっそり外のサーバーに持ち出そうとしたら、今のあなたのシステムはそれを止められるでしょうか？
今回は、クラウド環境における「エグレス（Egress）トラフィックのフィルタリング」、つまり「内から外への通信制限」について、身近な防犯の仕組みに例えながら、一歩ずつ優しく紐解いていきたいと思います。難しく考えず、一緒にリラックスして学んでいきましょう！
—
1. 家の防犯に例える「エグレスフィルタリング」の重要性
皆さんが暮らしている「お家」を想像してみてください。
泥棒に入られないように、頑丈な玄関の鍵を閉め、窓には補助錠をつけますよね。これがサーバーでいう「外からの攻撃を防ぐファイアウォール（イングレス対策）」です。
では、もし万が一、留守番中の家族がうっかり玄関の鍵を開けてしまい、泥棒がリビングに入り込んでしまったらどうなるでしょうか？
泥棒はリビングにあるテレビや高級な時計をかばんにつめ、堂々と玄関から外へ持ち出そうとします。
ここで考えてほしいのです。
従来のセキュリティは、「家に泥棒を入れないこと」ばかりに気を取られていて、「一度入り込まれた泥棒が、盗んだものを外に持ち出すこと」を見落としがちでした。
クラウド上のサーバーもこれとまったく同じです。
どれだけ強固なパスワードを設定し、OSのアップデートを怠らなかったとしても、Webアプリケーションの思わぬ脆弱性（例えば、以前大きな話題になった Log4j や、よくあるSQLインジェクションなど）を突かれて、サーバーの内部で悪意あるコードを実行されてしまうリスクはゼロにはなりません。
攻撃者は、サーバーの内部に入り込むと、次のような悪事を働きます。
1. 外部の怪しいサーバーと通信を確立する（C2サーバーとの通信）
2. さらなる攻撃用のツールや、不正なプログラムを外部からダウンロードする
3. サーバー内にある機密情報や顧客データを、外部の置き場へこっそり送信する（データ持ち出し）
ここで活躍するのが、「エグレス（Egress）フィルタリング」です。
エグレスとは「出口」を意味します。つまり、「サーバー（内側）からインターネット（外側）へ出ていく通信」を監視し、許可された安全な宛先以外への通信をすべてブロックする仕組みのことです。
たとえサーバーの内部に侵入を許してしまったとしても、「外との連絡網」を断ち切ってしまえば、泥棒は盗んだデータを外に持ち出すことも、新しい指示を仰ぐこともできなくなります。これが、エグレスフィルタリング最大の強みなのです。
—
2. クラウドでよくある「うっかり」と、FQDNフィルタリングの必要性
「よし、じゃあサーバーからの外向き通信を全部禁止にすれば完璧だね！」と思った方、ちょっと待ってください。
現代のクラウドシステムは、外の世界とまったく通信をしない「孤島」では成り立ちません。たとえば、以下のような理由でサーバーから外へ通信する必要がありますよね。
- OSやミドルウェアのセキュリティパッチ（更新プログラム）をダウンロードする
- 外部のAPIサービス（決済システムやメール配信サービスなど）と連携する
- ログやメトリクスを外部の監視サービスへ送信する
ここで、「じゃあ、外への通信は全部自由（0.0.0.0/0 への全開放）にしよう」としてしまうのが、実務でよくある「うっかり」であり、最大のセキュリティホールになります。
従来のIPアドレスベースのファイアウォールでは、宛先のサーバーのIPアドレスが変わるたびにルールを書き換える必要があり、現実的ではありませんでした。特にクラウド上のパブリックなサービス（例: api.github.com や各種クラウドのAPI）は、IPアドレスが頻繁に変動します。
そこで登場するのが、「FQDN（Fully Qualified Domain Name）フィルタリング」です。
IPアドレスではなく、example.com のようなドメイン名をもとに、「このサーバーは、業務上必要な特定のドメインにしか外へアクセスしてはいけない」というルールを定義します。
—
3. 実践！クラウド環境（Squidプロキシ）でのエグレス制御設定
それでは、具体的にどうやってこの「出口の管理」を行うのか、代表的な手法を見ていきましょう。
クラウド環境では、外部への通信を直接各サーバーから行わせるのではなく、間に「フォワードプロキシサーバー（例: Squid）」を挟む構成がよく取られます。
プロキシサーバーを「家の勝手口の警備員」だとイメージしてください。
サーバー（家族）が外へゴミ出し（通信）をするときは、必ず警備員のところに行き、「どこへ行くのか」「何をしに行くのか」を申告します。警備員が「あ、そこは安全な行き先リストに載っているから通していいよ」と許可したときだけ、外に出られる仕組みです。
ここでは、オープンソースのプロキシサーバーである Squid を使って、特定のドメイン（FQDN）だけに外向きの通信を許可する設定例を見てみましょう。
Squidのコンフィグ設定例 (/etc/squid/squid.conf)
以下の設定では、社内システムやアップデートに必要な特定の安全なドメイン（ここでは api.github.com と security.ubuntu.com）へのアクセスだけを許可し、それ以外のすべての外部通信をガッチリとブロックします。
# ==========================================
# 1. アクセス許可する宛先ドメインの定義
# ==========================================
# 業務でどうしても必要な外部APIやアップデート用のドメインを指定します
acl allowed_domains dstdomain .github.com
acl allowed_domains dstdomain .ubuntu.com
# ==========================================
# 2. 標準的なポートの定義
# ==========================================
# Web通信の基本であるHTTP(80)とHTTPS(443)のみを対象とします
acl Safe_ports port 80
acl Safe_ports port 443
# 安全ではないポートへのアクセスは拒否する基本設定
http_access deny !Safe_ports
# ==========================================
# 3. アクセス制御ルールの適用
# ==========================================
# 定義した「許可されたドメイン」への通信のみを許可する
http_access allow allowed_domains
# 上記のルールに当てはまらなかった通信は、すべて容赦なくブロックする
http_access deny all
# プロキシが待ち受けるポート番号（デフォルトは3128）
http_port 3128この設定がもたらす現場での安心感
もし、あなたの管理するアプリケーションサーバーのどこかに脆弱性があり、攻撃者が侵入して外部の悪意あるサーバー（例: evil-hacker-server.com）から不正なマルウェアをダウンロードしようとしたとします。
サーバーは Squid プロキシ経由で外部へ通信を試みますが、Squidのコンフィグには evil-hacker-server.com が許可されていません。そのため、Squidは次のようなエラー（アクセス拒否）を返します。
Access Denied (HTTP 403 Forbidden)
攻撃者は「あれ？外のサーバーと通信できないぞ……？」と手詰まりになり、データの持ち出しや追加の攻撃ツールのダウンロードを諦めざるを得なくなるのです。これが、泥棒の足に重い枷（かせ）をはめるエグレスフィルタリングの実力です。
—
4. 現場のセキュリティ担当者からのアドバイス
エグレスフィルタリングの重要性がわかっても、いざ本番環境で導入しようとすると、最初は必ずと言っていいほど「あれ？このアプリも外と通信できなくなって動かないぞ！？」というトラブル（いわゆる「おまエラ」：お前の設定のせいでエラーが出てるぞ、の略）に直面します。
現場でスムーズに導入するためのコツをいくつかシェアしますね。
1. まずは「ログ監視（Audit Mode）」から始める
いきなりすべての通信を遮断（Deny）するのではなく、最初はプロキシのログを有効にして、「普段、自分のサーバーたちがどこのドメインと通信しているのか」を数日間じっくり観察してください。「あ、このバッチ処理は、知らなかったあの外部APIを叩いていたんだな」といった発見が必ずあります。
2. ホワイトリスト方式を徹底する
セキュリティの基本は「許可されたもの以外、すべて禁止（ホワイトリスト方式）」です。「怪しいものをブロックする」ではなく、「安全と確認されたものだけ通す」という姿勢を貫きましょう。
3. クラウドネイティブな機能も活用する
AWSを使っているなら AWS Network Firewall や NAT Gateway との組み合わせ、Azureなら Azure Firewall や UDR（ユーザー定義ルート） など、クラウドベンダーが提供するマネージドなエグレス制御サービスを利用するのも非常にスマートな選択肢です。
—
まとめ
今回は、クラウド環境におけるエグレス（Egress）トラフィックのフィルタリングについて、お家の防犯や泥棒の例えを交えながら解説しました。
- イングレス（入り口）だけでなく、エグレス（出口）の管理こそが、万が一の侵入を許したときの最終防衛ラインになる。
- 宛先のIPが変動するクラウド時代では、FQDNフィルタリングやプロキシサーバーを活用したドメイン単位の制御が極めて有効。
- 最初は通信ができなくて焦ることもあるけれど、丁寧なログ観察とホワイトリストの作成から一歩ずつ進めれば必ず強固な環境が作れる。
セキュリティ対策に「完璧」はありませんが、「攻撃者のコストを跳ね上げる（面倒くさいターゲットになる）」ことは、私たちインフラ・開発エンジニアの工夫次第でいくらでも可能です。
「一歩ずつ、確実に安全な環境を育てていく」。その楽しさを感じながら、ぜひ今日の構築や設定にエグレス制御の視点を取り入れてみてくださいね。それでは、また次回のセキュリティ解説でお会いしましょう！
コメント