こんにちは、はむたまです。
アプリ開発、インフラ開発をしているとどちらかは分かってももう片方がわからないことで、結局どうしてアクセス可能になっているのかわからないということがあるかもしれません。

この記事自体は若手エンジニアが陥るインターネットからアプリまでの到達経路にフォーカスして解説します。
もちろんこの記事の内容が全てのアーキテクチャに適用されるわけではございませんが、理解の一助になればと思います。

生成AIの記事に負けないように実体験をベースにアーキテクチャを描いていきますので、気ままに読んでいただければ幸いです。

概要

インターネットからアプリサーバまでの通信経路において、意外と知らないことが多いと思い記載します。
この記事を読んで理解しやすいように、Wordpressのサーバにインターネットからアクセスするとしたときのアーキテクチャとします。
お手軽なアーキテクチャだとあまり解説し甲斐がないので、アクセス集中することを前提とした非機能要素も盛り込んで記載していきます。

この記事を読んでわかるアーキテクチャ全容
<画像>

読んで理解できる技術領域

• セキュリティ
• ルーティング
• DNS
• 負荷分散
• 冗長構成

詳細

インターネットから内部NWに入るまで

皆さんがインターネットからワードプレスのWebサイトを閲覧するにはGoogleなどの検索エンジンに検索ワードを入力し、SEOにヒットしたWebページのリンクをクリックすることでアクセスするかと思います。
一方で過去に訪問したことがあるサイトであれば履歴からアクセスしたり、お気に入りからアクセスすることがあるかもしれません。
いずれもサイトのドメインを選択してインターネット経由でアクセスするということで一致します。
例えば私のサイトであればhamtama47.comのドメインをクリックすることでアクセス可能となります。
この時このドメインのサーバがインターネット上のどこに配置されているかを探すために外部DNSを使います。
ドメインにはxxx.xxx.xxxみたいな表記でメールアドレスの後半みたいな名前があります。こちらはどのネームサーバで名前解決するかを示しています。私のhamtamaについては.comドメインで購入しているためルートDNSが.com DNSに名前解決を以上することで見つけられます。その先のページの構成等はサイトについてから内部で振り分けをしています。

ただ単にアクセスするだけなら上記のドメインだけでアクセスできますが、サイトの管理者である私は変な人にアクセスしてほしくないと思います。
その時に地球上のどの地域やどの端末からしかアクセスできないようにするといった制約をつけられます。ここがインターネットゲートウェイにおけるIP制限です。第二層のMacアドレスで制約することも特定の地域と限定するIP制限も可能です。

インターネットゲートウェイを通過するには他にも通信規格の制限もあります。メール規格のようなPOPやIMAPなのかWEBサイトのようなHTTP/HTTPSなのか。これもドメイン振り分け時に制限をつけることが可能です。

扱っていないサービスの通信企画でアクセスされると攻撃と変わらないですからね、、、

インターネットゲートウェイから内部DNSまで

インターネットゲートウェイ通過後は一旦FWやUTMといったセキュリティツールに到達するかと思います。リバースプロキシ（LB）を配置してサーバ証明書を持たせてTLS通信の範囲を決めることもあります。
想定内の通信が来た場合にアプリが配置された内部のサーバに到達するまでの振り分けが必要です。この役割を担うのが内部DNSです。

内部DNSはインターネットゲートウェイ側で確保しているグローバルアドレス（GIP）とは異なり、内部で管理するIPアドレスであり、ローカルIPアドレスといいます。

確保したIPアドレスのサブドメインごとにIPアドレスを分割し、商用利用IP、運用管理IP等に分割することが多いです。

今回はアプリ側へ到達することを前提とするため、商用利用IP帯にルーティングすることが必要です。
FW/UTMで不正な通信を落とした後内部DNSで該当するサブドメインを名前解決して、ルータを使って該当ドメインにルーティングしていきます。

FW/UTMについて

FWルールは基本的にドロップがデフォルトです。特定の通信だけ通すようにFWルールを追加していきます。またどのドメインと繋ぐかをインターフェースおよびルーティング設定に書くことがあります。PJによってはFWにルーティング機能を持たせないこともあります。

UTMであれば単純なアクセス拒否だけでなく通信量の取得や分析することも可能です。UTMは一般的なFW機器よりリッチなことが多いです。値段的にも機能的にも。ただいずれが適当であるかは要件によります。私は高い製品を配置したからセキュリティ強度が高いとは考えません。

一般的にセキュリティ強度を保つにはセキュリティツールを並べて通信上の弱い点をベースとしてレベル設定がされます。仮に高めのUTMを使っても使っているプログラミングコードで明らかな脆弱性がありパッチが適用されていない場合簡単に突破されてしまう可能性があるため、UTMが機能していないのも同然になってしまいます。
必要なセキュリティレベルに準拠させていくことが必要です。

セキュリティ周りで言うともう一つ大事な考えがあります。多段防御です。特定のセキュリティツールに偏ったNW構成では一つの製品の脆弱性が発覚したときに一発で突破されてしまいます。少しでも攻撃されないように複数のセキュリティツールを組み合わせて構築するのがいいと考えます。

例えばUTMで一般的なFW機能を設定したとして、FWではより細かな設定を追加して多段防御を実現します。これにより一つが突破されてももう一つを突破しないと目的地に到達できないようにすることができます。

イメージは自転車のツーロックみたいなものです。攻撃者が一ヶ所突破してももう一ヶ所で確実に止めておくようなものです。別に幾つの防御網を設定することも問題ではありません。ただたくさん構築することは逆にメンテナンスが面倒になることと、運用コストが嵩むことにつながります。セキュリティツールもタダではないし、それ租管理できるように日々情報をアップデートする必要があるためです。

なのでインターネットから内部DNSの中で幾つのセキュリティツールを使うべきかは予算と被害規模から妥当なラインを検討するのがいいと考えます。

ルータからLBにかけて

ルータは内部のIPをサブドメインとして区切ったLANを繋ぐものです。どの通信はどちらに振り分けるのかを決めています。今回のhamtama47.comが内部に到達した後、10.10.18.xxxへの通信が来たら10.10.18.254に一旦渡すといったルールがあるとします。
この時ルータがやっていることはどこから来た通信はどこに渡すかという右手と左手を見て振り分けるのみです。細かな設定をして複数のLANに振り分けることも可能ですが、ルータのルーティングルールは簡潔に作ることをお勧めします。
ルータでありがちな設定としてはNAT設定です。
インターネットから来た通信もしくは内部のサーバからきた通信の送信元IPを変えて通常の通信ルートを通らずに曲げる方式です。
このメリットとしては特定の内部IPがわかりにくいようにできること、NW設計をたくさん変えずともルータの設定変更のみで通信切り替えができることです。
こちらも組み込めばたくさんのルールができますがわかりにくくなるのであまりおすすめはしません。

前者の通信元を解らないようにするのであれば前段か後段かにLBを置いてプロキシ/リバースプロキシとして使うのがいいかと思います。

LBからWebサーバについて

LBではルータから振り分けられた通信をWebサーバにアクセスする必要があります。ただWebサーバに配置された情報は非常に重要な情報なので信頼していない通信元からのアクセスは拒否したいですよね。
ここで使われるのがLBを使ったリバースプロキシです。外部からアクセスが来た時にGIPもしくは内部のルータのIPをもとにWebサーバの設定を変更するのは煩雑です。信頼できるリバースプロキシからしかアクセスできないようにすれば設定が簡潔にできます。また運用性も上がります。Webサーバ側で修正が入って再デプロイになった時に外部IPやドメインを指定してのアクセスルールを作るのはイケてません。
マイクロサービスアーキテクチャとしてWebサーバ側ではアプリの情報以外は持たせるべきではありません。今回でいえばwordpressの記事の情報があるHTMLやcssを持たせるのみにすべきであり、アクセス制限やシークレット情報は渡すべきではありません。これは保守性や運用性の観点で非常に重要です。アプリエンジニアの方ならわかると思うのですが、インフラの設定変更があったからpropertiesファイルを変更してくれと言われても何が正しいのか判断がつかないですよね。
これはインフラ側も同じでアプリの設定で振り分け/制限しているとどこまでを守らねばならないといけないのかわからなくなります。球技でいうお見合い状態かつ責任のなすりつけあいみたいになってしまいます。

お見合いを回避するためにもアプリにはアプリ以外の情報を持たせるべきではありません。

WebサーバからDBサーバについて

Webサーバは一般にリクエストに対してドキュメントを描画して表示させる機能を持ちます。ではどのドキュメントを表示すべきなのか。そもそもドキュメントはどこにあるのかと言うことが気になりますね。
ドキュメントは内部のDBサーバに配置されます。Windowsサーバのファイルシステムのような形で階層構造を持ち、名前等で検索できると考えるとわかりやすいです。例えばIT関連の記事で、セキュリティに関しての記事が見たい場合に、IT＞セキュリティといったファイル構成であったら非常にアクセスが簡易になります。このようなファイルシステムに似たようなDBの構造をリレーショナルDB形式といいます。基本的なファイル構成であればこれで十分ですが、より安価に高速な通信を実現するならNoSQL型がおすすめです。特定のキーに対して唯一のバリューを返す形式です。

サイトの構成で言えばどちらのDB形式でも構いません。ただDBにアクセスする際のシークレットキーの管理については気をつける必要があります。

WebサーバがDBサーバにアクセスするときは私が安全なWebサーバですと証明するためにアクセスキーが必要です。一般にユーザパス認証をイメージしてもらえればわかりやすいです。ただWebサーバが偽っていた場合に情報が盗まれる可能性があります。そこで少し前にブームになったのが、シークレットキーを用いたアクセスです。

シークレットキーをキー管理サーバに配置しておき、特定のサーバから指定したパスのキーを取得してその鍵を使ってアクセスすると言うものです。

イメージするなら鍵屋さんに鍵を預けておいて、個人を特定できる認証を経たら鍵を借りて目的地の部屋を開けるものです。

この鍵屋があるとないとで保守性と安全性がだいぶ異なります。シークレット管理サーバがあることでアプリ側にDBアクセス情報を持たせる必要がなくなります。鍵屋の場所を指定しておくだけでいいのです。鍵が交換になってもアプリを修正することなく、鍵屋の鍵の入れ替えのみでいいのです。

また鍵屋へのアクセスを厳重にしたらアプリ側のセキュリティをたくさん考える必要が減ります。セキュリティ水準を統一させるのは必要ですが、権限によってアクセス制御させるのに役立つのです。

Webサーバ側での描画制御

Webサーバ側でDBサーバから取得したHTML等のドキュメントファイルを描画します。このときどのドメインでリクエストが来たかによって第7層で制御することが可能です。

まとめ

今回はインターネットからワードプレスの記事にアクセスするとしたときに一般的なシステムアーキテクチャについて解説しました。もちろんこれが正解というわけではありません。一つの設計例でしかございませんし、細かな設定については割愛しています。需要があればAWSでこの構成を実現するならコンポーネント単位で解説しようかと思います。

ではでは。