Minimum Viable Networkの威力

クラウド活用を始めた組織にとって、クラウドネットワーキングの理解は最も大きな適応課題の一つです。アドレス設計や構成要素を見ると、一見するとIPネットワークのように見えます。多くの観点ではその通りですが、それ以外の多くの領域では異なります。クラウドで提供されるようなソフトウェア定義ネットワーク（SDN）は、物理ネットワークと同じ制約を受けないため、取り組み始めの段階ではかなり混乱を招きかねません。

SDNが物理ネットワークとどう違うかを理解しようとするのではなく、ネットワークに何をさせる必要があるのか、さらに重要な点として何を許可すべきでないのかに目を向けましょう。「デフォルト拒否」という考え方を覚えている方もいるでしょう。明示的に許可した接続以外は、既定でブロックされるという考え方です。その後Webが登場し、ほぼすべてのアプリケーションがポート80や443を使うようになったため、これらを制限することは不可能になりました。さらに「デフォルト拒否」が境界の内側まで適用されることは実際にはほとんどなく、内部ネットワークはフラットでオープンな傾向にあり、外部からの有害なトラフィックの排除はDMZに依存していました。相次ぐ侵害が示してきたとおり、このモデルの効果は限定的です。

しかしSDNを用いれば、「Minimum Viable Network（最小限の実行可能なネットワーク）」と呼ぶ考え方によって、デフォルト拒否にはるかに近づくことができます。これは、業務の遂行に必要な要素だけで構成され、それ以上を含まないカスタムネットワークの構築を可能にするものです。

Minimum Viable Networkでは、まずアプリケーションアーキテクチャを決定し、そのアプリケーションを支えるために必要なネットワークのみを構築します。その際、最小権限のルーティングとセキュリティグループを適用し、クラウドロードバランサーなどのPaaSコンポーネントも活用します。これにより、パケット交換ネットワークは実質的に回線交換ネットワークへと変わります。アプリケーションコンポーネントは許可された他のコンポーネントとのみ通信でき、その間のトラフィックを誰も傍受できません（一部のケースにおけるクラウドプロバイダーを除く）。ネットワークはそれ以外のすべてのトラフィックを破棄します。ネットワーク全体が最小権限かつデフォルト拒否となるため、従来のDMZやネットワークゾーンといった構成は不要になります。

例を使って、もう少し具体的に見ていきましょう。インターネットに面したApplication Load Balancerを備え、その背後にロードバランサーからのトラフィックのみを受け付けるプライベートサブネット内のWebサーバーを配置する、従来型の3層アプリケーションスタックを構築できます。Webサーバーは、Webサーバーからの接続を受け付けるアプリケーションサーバーにのみ接続できます。同様に、アプリケーションサーバーはそのような接続を許可しているデータベースにのみトラフィックを送信できます。各層はデフォルト拒否であり、ロードバランサーからのインバウンド接続とデータベースへのアウトバウンド接続のみを許可します。多くの場合、クラウドプロバイダーが維持する非常に安全なPaaS構成要素であるパブリックロードバランサーを除き、インターネット接続なし（プライベートサブネット内）でこれを実装できます。

ネットワークを構築してその中にアプリケーションを配置するのではなく、アプリケーションを設計し、そのニーズにネットワークを合わせます。これによりアプリケーションスタックの攻撃対象領域は大幅に縮小し、それに応じてリスクも低減します。

当社はこれらの原則を用いてsecurosis.comサイトを構築しました。下のアーキテクチャ図をご覧ください。この設計をネットワークセキュリティの観点から見ると、次のことがわかります。

• アクセスはクラウドWAFで制限され、クリーンなトラフィックのみがVPCに到達します。
• Application Load Balancer（ALB）はインターネットに面したサブネット内にある唯一のリソースであり、80/443のトラフィックのみを許可します。
• すべてのインスタンスはプライベートサブネット内にあり、ALBからのトラフィックのみを受け付けます。
• 「admin」インスタンスはログインを受け付けますが、別環境でホストされているVPNからのみに限定されています。
• 図には示されていませんが、RDSデータベース用のサブネットも同様にプライベート専用で、インスタンスからのトラフィックのみを受け付けます。データ加工のために直接ログインやRDBMSへのアクセスが必要な場合は、一時的なアクセスとしてセキュリティグループのルールを変更します。
• S3への接続はサービスエンドポイント経由で行われるため、インターネットアクセス用のNATゲートウェイが不要になります。
• admin以外のインスタンスではSSHを無効化しています。これらはオートスケールされるイミュータブルな構成で、変更はベースイメージの差し替えによってのみ行われます。
• 水平方向の攻撃を防ぐため、自己参照型のセキュリティグループ（内部アクセスを許可するセキュリティグループ）は設けていません。AWSのセキュリティグループはサブネット単位ではなくリソース単位で機能するため、East/West方向の攻撃を遮断するうえで非常に強力です。
• このアーキテクチャは、全体の攻撃対象領域を大幅に縮小します。ネットワークは必要最小限の接続のみを許可し、アクセスに必要な最小限のサブネットとルートテーブルのみで構成されます。つまり、ネットワークをアプリケーションに合わせたのです。実際、ネットワークはアプリケーションスタックの設計が完了した後に初めて設計されました。
• これは小規模サイトの非常に単純な例ですが、この原則は、より多くの層、内部ロードバランサー、API Gateway、PaaSコンポーネントを含む、はるかに大規模なアーキテクチャにも適用できます。

このように、クラウドネットワーキングの構成要素を用いることで、非常に高い柔軟性が得られます。既存のネットワークにアプリケーションを合わせるのではなく、アプリケーションが必要とするネットワークをようやく構築できるようになります。ただしこの柔軟性は、設定を誤ってインフラの広範な部分をパブリックインターネットに露出させてしまう可能性も伴います。そのため、クラウドセキュリティ運用プラットフォーム（DisruptOpsが提供するようなもの）によって、クラウドのセキュリティ態勢を監視し、ベストプラクティスを徹底することを常に推奨します。