Istioにおける出力トラフィックの安全な制御 パート1
出力トラフィックに関連する攻撃と出力トラフィック制御の要件。
これは、Istioにおける出力トラフィックの安全な制御に関する新しいシリーズのパート1です。このパートでは、クラスタに出力トラフィック制御を適用する理由、防止したい出力トラフィックに関連する攻撃、および出力トラフィック制御システムの要件について説明します。クラスタからの出力トラフィックを制御する必要があることに同意したら、次の疑問が生じます。出力トラフィックの安全な制御のためのシステムには何が求められるのでしょうか？これらの要件を満たすための最良のソリューションは何でしょうか？（ネタバレ：私の意見ではIstioです）今後のパートでは、Istioにおける出力トラフィックの安全な制御の実装について説明し、他のソリューションと比較します。
サービスメッシュにとって最も重要なセキュリティの側面はおそらく入力トラフィックです。攻撃者が入力APIを介してクラスタに侵入するのを確実に防ぐ必要があります。そうは言っても、メッシュから出ていくトラフィックを保護することも非常に重要です。クラスタが侵害された場合（そして、そのシナリオに備える必要があります）、可能な限り損害を軽減し、攻撃者がクラスタを使用してクラスタ外の外部サービスやレガシーシステムへのさらなる攻撃を行うのを防ぐ必要があります。その目標を達成するには、出力トラフィックの安全な制御が必要です。
コンプライアンス要件は、出力トラフィックの安全な制御を実装するもう1つの理由です。たとえば、ペイメントカード業界（PCI）データセキュリティ基準では、インバウンドおよびアウトバウンドトラフィックをカード会員データ環境に必要なトラフィックに制限し、他のすべてのトラフィックを明示的に拒否する必要があります
そして、特にアウトバウンドトラフィックに関しては
出力トラフィックに関連する攻撃から始めましょう。
攻撃
IT組織は、まだ攻撃されていない場合、攻撃されると想定する必要があり、インフラストラクチャの一部がすでに侵害されているか、将来侵害される可能性があると想定する必要があります。攻撃者がクラスタ内のアプリケーションに侵入できると、外部サービス（レガシーシステム、外部Webサービス、データベース）への攻撃に進むことができます。攻撃者はアプリケーションのデータを盗んで外部サーバーに転送したい場合があります。攻撃者のマルウェアは、更新をダウンロードするために攻撃者のサーバーにアクセスする必要がある場合があります。攻撃者は、クラスタ内のポッドを使用してDDOS攻撃を実行したり、外部システムに侵入したりする可能性があります。すべてのタイプの攻撃を知ることはできませんが、既知および未知の攻撃の可能性を減らしたいと考えています。
外部の攻撃者は、アプリケーションのバグを通じてメッシュの外部からアプリケーションのコンテナにアクセスできますが、攻撃者は内部にいることもできます。たとえば、組織内の悪意のあるDevOps担当者などです。
上記の攻撃を防ぐために、何らかの形の出力トラフィック制御を適用する必要があります。次のセクションで出力トラフィック制御を紹介します。
ソリューション：出力トラフィックの安全な制御
出力トラフィックの安全な制御とは、出力トラフィックを監視し、出力トラフィックに関するすべてのセキュリティポリシーを適用することを意味します。出力トラフィックを監視することで、おそらくオフラインで分析し、リアルタイムで防ぐことができなかったとしても攻撃を検出できます。攻撃の可能性を減らすためのもう1つの優れた方法は、知る必要がある原則に従ってアクセスを制限するポリシーを指定することです。外部サービスを必要とするアプリケーションのみが、必要な外部サービスにアクセスできるようにする必要があります。
次に、収集した出力トラフィック制御の要件について説明します。
出力トラフィック制御の要件
IBMの同僚と私は、複数の顧客から出力トラフィックの安全な制御の要件を収集し、Kubernetesネットワーク特別利益団体の出力トラフィック制御要件と組み合わせました。
Istio 1.1は、収集されたすべての要件を満たしています
SNIを使用したTLS、またはIstioによるTLSオリジネーションのサポート。
すべての出力アクセスのSNIと送信元ワークロードを監視します。
クラスタごとにポリシーを定義して適用します。例：
クラスタ内のすべてのアプリケーションは、
service1.foo.com（特定のホスト）にアクセスできますクラスタ内のすべてのアプリケーションは、
*.bar.com（ワイルドカードドメイン）形式の任意のホストにアクセスできます
指定されていないすべてのアクセスはブロックする必要があります。
送信元ごとにポリシーを定義して適用します。Kubernetes対応
アプリケーション
Aは*.foo.comにアクセスできます。アプリケーション
Bは*.bar.comにアクセスできます。
他のすべてのアクセスはブロックする必要があります。特に、アプリケーション
Aからservice1.bar.comへのアクセスはブロックする必要があります。改ざんを防止します。アプリケーションポッドが侵害された場合、侵害されたポッドが監視を回避したり、監視システムに偽の情報を送信したり、出力ポリシーを破ったりするのを防ぎます。
あると便利：トラフィック制御はアプリケーションに対して透過的です。
各要件について詳しく説明しましょう。最初の要件は、外部サービスへのTLSトラフィックのみがサポートされる必要があると述べています。この要件は、クラスタから出ていくすべてのトラフィックを暗号化する必要があるという観察に基づいて生まれました。これは、アプリケーションがTLSオリジネーションを実行するか、IstioがアプリケーションのためにTLSオリジネーションを実行する必要があることを意味します。アプリケーションがTLSオリジネーションを実行する場合、Istioプロキシは元のトラフィックではなく暗号化されたトラフィックのみを参照できるため、プロキシはTLSプロトコルのみを参照できることに注意してください。プロキシにとって、元のプロトコルがHTTPかMongoDBかは関係ありません。Istioプロキシが参照できるのはTLSトラフィックのみです。
2番目の要件は、SNIとトラフィックの送信元を監視する必要があると述べています。監視は、攻撃を防ぐための最初のステップです。攻撃者がクラスタから外部サービスにアクセスできたとしても、アクセスが監視されていれば、疑わしいトラフィックを発見して是正措置を講じる可能性があります。
アプリケーションによってオリジネーションされたTLSの場合、IstioサイドカープロキシはTCPトラフィックとSNIを含むTLSハンドシェイクのみを参照できることに注意してください。送信元ポッドのラベルはトラフィックの送信元を識別できますが、ポッドのサービスアカウントまたは他の送信元識別子を使用できます。出力制御システムのこのプロパティをKubernetes対応と呼びます。システムは、ポッドやサービスアカウントなどのKubernetesアーティファクトを理解する必要があります。システムがKubernetesに対応していない場合、IPアドレスのみを送信元の識別子として監視できます。
3番目の要件は、Istioオペレーターがクラスタ全体の出力トラフィックのポリシーを定義できる必要があると述べています。ポリシーは、クラスタ内のどのポッドがどの外部サービスにアクセスできるかを規定します。外部サービスは、サービスの完全修飾ドメイン名（例：www.ibm.com）またはワイルドカードドメイン（例：*.ibm.com）で識別できます。指定された外部サービスのみにアクセスでき、他のすべての出力トラフィックはブロックされます。
この要件は、攻撃者が悪意のあるサイトにアクセスするのを防ぐ必要があることから生じます。たとえば、マルウェアの更新/指示をダウンロードする場合などです。また、攻撃者がアクセスして攻撃できる外部サイトの数を制限したいと考えています。クラスタ内のアプリケーションがアクセスする必要がある外部サービスへのアクセスのみを許可し、他のすべてのサービスへのアクセスをブロックすることで、攻撃対象領域を削減します。外部サービスには独自のセキュリティメカニズムがありますが、多層防御を実行し、外部システムのセキュリティ層に加えて、クラスタ内にセキュリティ層を設ける必要があります。
この要件は、外部サービスをドメイン名で識別できる必要があることを意味します。出力制御システムのこのプロパティを*DNS対応*と呼びます。システムがDNSに対応していない場合、外部サービスはIPアドレスで指定する必要があります。IPアドレスを使用することは便利ではなく、サービスのIPアドレスが変更される可能性があるため、多くの場合実現不可能です。たとえば、CDNの場合のように、サービスのすべてのIPアドレスがわからない場合もあります。
4番目の要件は、出力トラフィックの送信元をポリシーに追加して、3番目の要件を効果的に拡張する必要があると述べています。ポリシーは、どの送信元がどの外部サービスにアクセスできるかを指定でき、送信元は2番目の要件と同様に、たとえば送信元ポッドのラベルまたはポッドのサービスアカウントによって識別する必要があります。これは、ポリシーの適用も*Kubernetes対応*である必要があることを意味します。ポリシーの適用がKubernetesに対応していない場合、ポリシーはポッドのIPによってトラフィックの送信元を識別する必要がありますが、これは特にポッドが出入りするためIPが静的ではないため、便利ではありません。
5番目の要件は、クラスタが侵害され、攻撃者が一部のポッドを制御している場合でも、出力制御システムの監視を欺いたり、ポリシーに違反したりできない必要があると述べています。このようなシステムは、出力トラフィックの*安全な*制御を提供すると言います。
6番目の要件は、アプリケーションコンテナを変更せずに、特にアプリケーションのコードを変更したり、コンテナの環境を変更したりせずに、トラフィック制御を提供する必要があると述べています。このような出力トラフィックの制御を*透過的*と呼びます。
今後の投稿では、Istioがこれらの要件をすべて満たす egress トラフィック制御システムの一例として機能することを示します。特に、透過性があり、DNS を認識し、Kubernetes を認識しています。
概要
egress トラフィックの制御がクラスタのセキュリティにとって重要であることをご理解いただけたでしょうか。 このシリーズのパート2では、Istio による egress トラフィックの安全な制御方法について説明します。 このシリーズのパート3では、Kubernetes Network Policy や従来の egress プロキシ/ファイアウォールなどの代替ソリューションと比較します。
