隔離と境界保護のためのマルチメッシュデプロイメント

さまざまなコンプライアンス基準では、機密データ環境の保護が求められます。重要な基準と、それらが保護する機密データの種類を次の表に示します。

たとえば、PCI DSS では、カード会員データ環境をシステム内の他の部分から分離したネットワークに配置することを推奨しています。また、DMZ を使用し、公衆インターネットと DMZ の間、および DMZ と内部ネットワークの間にファイアウォールを設置することも要求しています。

機密データ環境を他の情報システムから隔離することで、コンプライアンスチェックの範囲を縮小し、機密データのセキュリティを向上させることができます。範囲を縮小すると、コンプライアンスチェックに失敗するリスクが軽減され、コンプライアンス要件に従ってチェックおよび保護するコンポーネントが少なくなるため、コンプライアンスのコストも削減されます。

機密データを処理するアプリケーションの部分を別のサービスメッシュに分離（できれば別のネットワーク上）し、異なるコンプライアンス要件を持つメッシュをマルチメッシュデプロイメントで接続することで、機密データの隔離を実現できます。メッシュ間アプリケーションを接続するプロセスは、メッシュフェデレーションと呼ばれます。

メッシュフェデレーションを使用してマルチメッシュデプロイメントを作成することは、複数のクラスターにまたがるサービスで構成される単一のサービスメッシュを定義するマルチクラスターデプロイメントを作成することとは大きく異なります。マルチメッシュとは異なり、マルチクラスターデプロイメントは、隔離と境界保護を必要とするアプリケーションには適していません。

このブログ記事では、隔離と境界保護の要件について説明し、マルチメッシュデプロイメントの原則について概説します。最後に、Istio のメッシュフェデレーションの現在のサポート状況と、現在進行中の自動化作業について触れます。

隔離と境界保護

隔離と境界保護のメカニズムについては、NIST Special Publication 800-53, Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations の付録 F、セキュリティ制御カタログ、SC-7 境界保護で説明されています。

特に、境界保護、情報システムコンポーネントの隔離制御の強化について

さまざまなコンプライアンス基準では、機密データを処理する環境を組織の他の部分から隔離することを推奨しています。Payment Card Industry (PCI) Data Security Standard では、カード会員データ環境にネットワーク隔離を実装することを推奨しており、この環境を DMZ から隔離する必要があります。FedRAMP 承認境界ガイダンスでは、連邦政府の情報とデータの承認境界について説明しており、NIST Special Publication 800-37, Revision 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy では、付録 G、承認境界の考慮事項でそのような境界の保護を推奨しています。

特に境界保護とは、

• 境界にアクセス制御メカニズム（ファイアウォール、ゲートウェイなど）を配置すること
• 境界での入出力トラフィックを監視すること
• すべてのアクセス制御メカニズムは、デフォルトですべて拒否でなければならないこと
• 境界からプライベート IP アドレスを公開しないこと
• 境界外のコンポーネントが境界内のセキュリティに影響を与えないようにすること

マルチメッシュデプロイメントは、異なるセキュリティおよびコンプライアンス要件を持つシステムをサブシステムに分割することを容易にし、境界保護を促進します。各サブシステムを別のサービスメッシュに配置します（できれば別のネットワーク上）。ゲートウェイを使用して Istio メッシュを接続します。ゲートウェイは、各メッシュの境界でメッシュ間のトラフィックを監視および制御します。

マルチメッシュデプロイメントの機能

• 均一でない命名。1つのメッシュの accounts 名前空間の withdraw サービスは、他のメッシュの accounts 名前空間の withdraw サービスとは異なる機能と API を持つ可能性があります。このような状況は、名前空間とサービスの名前付けに関する統一ポリシーがない組織や、メッシュが異なる組織に属している場合に発生する可能性があります。
• デフォルトでは何も公開しない。メッシュ内のサービスはデフォルトでは公開されません。メッシュの所有者は、公開するサービスを明示的に指定する必要があります。
• 境界保護。トラフィックのアクセス制御は、メッシュへの不正なトラフィックの侵入を阻止するイングレスゲートウェイで強制する必要があります。この要件は多層防御の原則を実装しており、Payment Card Industry (PCI) Data Security Standardなどの一部のコンプライアンス基準の一部です。
• 共通の信頼が存在しない場合がある。一部のセキュリティ要件や、メッシュの所有者が当初メッシュをフェデレートすることを計画していなかったため、1つのメッシュの Istio サイドカーは、他のメッシュの Citadel 証明書を信頼しない場合があります。

デフォルトでは何も公開しないと境界保護は、コンプライアンスを促進し、セキュリティを向上させるために必要ですが、均一でない命名と共通の信頼が存在しない場合があるは、異なる組織のメッシュを接続する場合、または均一な名前付けを強制できない組織、またはメッシュ間で共通の信頼を確立できない組織を接続する場合に必要です。

使用できるオプション機能は、サービスロケーションの透過性です。消費サービスは、ローカルサービス名を使用して、リモートメッシュで公開されたサービスにリクエストを送信します。消費サービスは、一部の宛先がリモートメッシュにあり、一部がローカルサービスであることを認識していません。たとえば、Kubernetes では、reviews.default.svc.cluster.local のように、ローカルサービス名を使用してアクセスは均一です。サービスロケーションの透過性は、アプリケーションのコードを変更せずに、一部のサービスがプライベートクラウドからパブリッククラウドに移行された場合など、消費されるサービスの場所を変更できるようにしたい場合に役立ちます。

現在のメッシュフェデレーションの取り組み

すでに今日、標準の Istio 構成を使用してメッシュフェデレーションを実行できますが、多くの定型 YAML ファイルを作成する必要があり、エラーが発生しやすくなります。メッシュフェデレーションプロセスを自動化する取り組みが進められています。それまでの間、これらのマルチメッシュデプロイメントの例を参照して、生成されたフェデレーションに何が含まれるかを確認できます。

まとめ

このブログ記事では、Istio マルチメッシュデプロイメントを使用して、機密データ環境の隔離と境界保護の要件について説明しました。Istio マルチメッシュデプロイメントの原則を概説し、Istio でのメッシュフェデレーションに関する現在の取り組みについて報告しました。

マルチメッシュとマルチクラスターについてのご意見をdiscuss.istio.ioでお聞かせください。