Splunkにおける包括的なネットワークセキュリティ

ネットワークのセキュリティ確保のためのツールは数多く存在し、個々のツールがアイデンティティ、ポリシー、可観測性をトラフィックに追加することで、ネットワークをより安全にする方法を示すチュートリアルやデモを見つけるのは容易です。しかし、本番環境でネットワークに包括的なセキュリティを提供するために、これらのツールがどのように連携するかは、多くの場合、明確ではありません。必要なツールはいくつありますか？ネットワークはいつ十分に安全になりますか？

この記事では、SplunkがKubernetesネットワークインフラストラクチャを保護するために活用するツールと実践について、VPC設計と接続性から始まり、HTTPリクエストベースのセキュリティまで、スタック全体にわたって探ります。その過程で、クラウドネイティブスタックに包括的なネットワークセキュリティを提供するために必要なもの、これらのツールがどのように連携するか、そしてそれらのツールをどのように改善できるかを見ていきます。Splunkは、次を含むさまざまなツールを使用してネットワークを保護しています。

• AWS機能
• Kubernetes
• Istio
• Envoy
• Aviatrix

Splunkのユースケースについて

Splunkは、さまざまなソースによって生成されたデータを収集、分析、視覚化するプラットフォームを提供するテクノロジー企業です。主に、Webスタイルのインターフェースを通じて、マシン生成のビッグデータを検索、監視、分析するために使用されます。Splunk Cloudは、Splunkの内部インフラストラクチャをクラウドネイティブアーキテクチャに移行するための取り組みです。現在、Splunk Cloudは、世界中のリージョンでAWSとGCPに35以上の完全にレプリケートされたクラスタで構成されています。

レイヤー3/4のセキュリティ：AWS、Aviatrix、およびKubernetes

Splunk Cloudでは、「クッキーカッターVPC」と呼ばれるパターンを使用しています。このパターンでは、各クラスタに独自のVPCがプロビジョニングされ、PodとノードのIPアドレス用に同一のプライベートサブネット、インターネットへの送受信用のパブリックサブネット、クラスタ間のトラフィック用の内部サブネットが用意されています。これにより、異なるクラスタのPodとノードが完全に分離され、同時にクラスタ外部からのトラフィックに対してパブリックサブネットと内部サブネットで特定のルールを適用できます。さらに、このパターンは、多くのクラスタを利用する場合にRFC 1918プライベートIPアドレスの枯渇の可能性を回避します。

各VPC内では、ネットワークACLとセキュリティグループが設定され、接続は絶対に必要なものだけに制限されています。たとえば、パブリック接続はイングレスノード（Envoyイングレスゲートウェイをデプロイするノード）に制限されています。通常の東西トラフィックと南北トラフィックに加えて、すべてのクラスタがアクセスする必要がある共有サービスもSplunkにあります。Aviatrixを使用して、重複するVPCアクセスを提供し、同時にいくつかの高度なセキュリティルール（ドメインごとのセグメンテーション）を適用しています。

Splunkのスタックにおける次のセキュリティレイヤーはKubernetes自体です。検証用Webhookを使用して、クラスタ内で安全でないトラフィックを許可するようなK8Sオブジェクトのデプロイを防止します（通常はNLBとサービスに関するもの）。Splunkは、Pod間の接続を保護および制限するためにもNetworkPoliciesに依存しています。

レイヤー7のセキュリティ：Istio

SplunkはIstioを使用して、各リクエストの詳細に基づいてアプリケーションレイヤーでポリシーを適用します。Istioは、リクエストレベルのセキュリティの検証に役立つテレメトリデータ（メトリクス、ログ、トレース）も出力します。

IstioによるEnvoyサイドカーの注入の重要な利点の1つは、アプリケーションを変更することなく、メッシュ全体の転送中暗号化を提供できることです。アプリケーションはプレーンテキストのHTTPリクエストを送信しますが、Envoyサイドカーはトラフィックをインターセプトし、相互TLS暗号化を実装して、傍受や改ざんから保護します。

Istioは、パブリックおよび内部NLBからのトラフィックを受信するSplunkのイングレスゲートウェイを管理します。ゲートウェイはプラットフォームチームによって管理され、Istio Gateway名前空間に配置されているため、ユーザーはそれらに接続できますが、変更することはできません。Gatewayサービスには、デフォルトでTLSを適用するための証明書もプロビジョニングされており、検証用Webhookにより、サービスは独自のホスト名に対してのみゲートウェイに接続できます。さらに、ゲートウェイは、トラフィックがアプリケーションPodに影響を与えることができるようになる前に、イングレスでリクエスト認証を適用します。

Istioおよび関連するK8Sオブジェクトは構成が比較的複雑であるため、Splunkは抽象化レイヤーを作成しました。これは、仮想サービス、デスティネーションルール、ゲートウェイ、証明書などを含むサービスのすべてを構成するコントローラーです。正しいNLBに直接接続するDNSを設定します。エンドツーエンドのネットワークデプロイメントのためのワンクリックソリューションです。より複雑なユースケースでは、サービスチームは抽象化をバイパスして、これらの設定を直接構成することもできます。

課題

Splunkのアーキテクチャは多くのニーズを満たしていますが、検討する価値のあるいくつかの課題があります。Istioは、アプリケーションPodと同じ数のEnvoyサイドカーを作成することで動作しますが、これはリソースの非効率的な使用です。さらに、特定のアプリケーションが、追加のCPUやメモリなど、サイドカーから独自のニーズを持つ場合、メッシュ内のすべてのサイドカーに対して調整することなく、これらの設定を調整することは困難です。Istioサイドカーの注入には多くのマジックが関与しており、ミューテートWebhookを使用して作成時にサイドカーコンテナをすべてのPodに追加するため、これらのPodは対応するデプロイメントと一致しなくなります。さらに、注入はPodの作成時のみに行うことができるため、サイドカーのバージョンまたはパラメーターが更新されるたびに、新しい設定を取得する前にすべてのPodを再起動する必要があります。全体として、このマジックは本番環境でサービスメッシュを実行することを複雑にし、アプリケーションに多くの運用上の不確実性をもたらします。

Istioプロジェクトはこれらの制限を認識しており、Istioの新しいAmbientモードによって大幅に改善されると考えています。このモードでは、アイデンティティや暗号化などのレイヤー4構造はノード上で動作するデーモンによって適用されますが、アプリケーションと同じPod内にはありません。レイヤー7機能は引き続きEnvoyによって処理されますが、Envoyは独自のデプロイメントの一部として隣接するPodで実行され、サイドカー注入のマジックに依存しません。AmbientモードではアプリケーションPodは変更されません。これにより、サービスメッシュ操作の予測可能性が大幅に向上するはずです。Ambientモードは、Istio 1.18でアルファ品質に達すると予想されています。

結論

Splunk Cloudのネットワークセキュリティにはこれらすべてのレイヤーがあるため、これらのレイヤーをトラバースするリクエストのライフサイクルを振り返ってみると役立ちます。クライアントがリクエストを送信すると、最初にNLBに接続します。NLBは、VPC ACLによって許可またはブロックされます。次に、NLBはリクエストをイングレスノードの1つにプロキシし、TLSを終了してレイヤー7でリクエストを検査し、リクエストを許可またはブロックすることを選択します。次に、Envoy GatewayはExtAuthZを使用してリクエストを検証し、クラスタに許可される前に、適切に認証され、クォータ制限を満たしていることを確認します。次に、Envoy Gatewayはリクエストをアップストリームにプロキシし、Kubernetesからのネットワークポリシーが再び有効になり、このプロキシが許可されていることを確認します。ワークロードのアップストリームサイドカーはレイヤー7リクエストを検査し、許可された場合はリクエストを復号化してクリアテキストでワークロードに送信します。

この大規模な企業のスケーラビリティのニーズを満たしながら、Splunkのクラウドネイティブネットワークスタックを保護するには、各レイヤーで慎重なセキュリティ計画が必要です。

スタックの各レイヤーでアイデンティティ、可観測性、およびポリシーの原則を適用することは、一見冗長に見えるかもしれませんが、各レイヤーは他のレイヤーの欠点を補うことができるため、これらのレイヤーが連携して、不要なアクセスに対する強力で効果的な障壁を形成します。

Splunkのネットワークセキュリティスタックの詳細を知りたい場合は、Cloud Native SecurityConのプレゼンテーションをご覧ください。