ゼロトラストは、すべてのインタラクションが信頼できない状態から始まるという前提に基づきセキュリティーアーキテクチャーを設計するアプローチです。これは、通信がファイアウォールの内側で開始されるかどうかに基づき信頼性を決定する従来のアーキテクチャーとは対照的です。より具体的には、ゼロトラストは、暗黙的信頼モデルと 1 回限りの認証に依存するセキュリティーアーキテクチャーのギャップを埋めようとします。

OpenShift Container Platform は、コンテナーやコンテナー内で実行されているソフトウェアを変更することなく、プラットフォーム上で実行されているコンテナーにゼロトラストネットワーク機能を追加できます。Red Hat は、コンテナーのゼロトラストネットワーキング機能をさらに強化できる製品もさらにいくつか提供しています。コンテナー内で実行されているソフトウェアを変更できる場合は、Red Hat がサポートする他のプロジェクトを使用して、さらに機能を追加できます。

以下は、ゼロトラストネットワークの対象となる機能の詳細です。

6.7.1. Root of Trust

公開証明書と秘密鍵はゼロトラストネットワークにとって重要です。これらは、各コンポーネントを相互に識別し、認証し、トラフィックを保護するために使用されます。証明書は他の証明書によって署名され、ルート認証局 (CA) への信頼チェーンが存在します。ネットワークに参加するすべてが、信頼チェーンを検証できるように、最終的にルート CA の公開鍵を持っている必要があります。一般に公開されている場合、通常は世界的に知られているルート CA のセットであり、その鍵はオペレーティングシステムや Web ブラウザーなどとともに配布されます。ただし、プライベート CA の証明書がすべての関係者に配布されている場合、クラスターまたは企業向けにプライベート CA を実行できます。

活用方法:

OpenShift Container Platform: OpenShift は、クラスターリソースの保護に使用されるクラスター CA をインストール時に作成します。ただし、OpenShift Container Platform は、クラスター内でサービス証明書を作成して署名することもでき、そのクラスター CA バンドルを必要に応じて Pod に注入することもできます。OpenShift Container Platform によって作成および署名されたサービス証明書の有効期間 (TTL) は 26 カ月で、13 カ月ごとに自動的にローテーションされます。必要に応じて手動でローテーションすることも可能です。
OpenShift cert-manager Operator: cert-manager を使用すると、外部の root of trust によって署名された鍵を要求できます。委譲された署名証明書を使用して実行する方法の他に、外部発行者と統合するために設定できる発行者が多数あります。cert-manager API は、ゼロトラストネットワーク内の他のソフトウェア (Red Hat OpenShift Service Mesh など) が必要な証明書を要求するために使用することも、お客様のソフトウェアが直接使用することも可能です。

6.7.2. トラフィック認証と暗号化

回線上のすべてのトラフィックが暗号化され、エンドポイントが識別可能になります。一例として、相互認証方式である Mutual TLS (mTLS) が挙げられます。

活用方法:

OpenShift Container Platform: 透過的な Pod 間の IPsec を使用することで、トラフィックの送信元と宛先を IP アドレスで識別できます。Egress トラフィックを IPsec を使用して暗号化する機能があります。Egress IP 機能を使用すると、トラフィックの送信元 IP アドレスを使用して、クラスター内のトラフィックの送信元を識別できます。
Red Hat OpenShift Service Mesh: Pod から送信されるトラフィックを透過的に拡張して認証と暗号化を提供する強力な mTLS 機能を提供します。
OpenShift cert-manager Operator: カスタムリソース定義 (CRD) を使用して、プログラムが SSL/TLS プロトコルに使用するためにマウントできる証明書を要求します。

6.7.3. 識別と認証

CA を使用して証明書を作成できるようになると、それを使用して接続のもう一方の端 (ユーザーまたはクライアントマシン) のアイデンティティーを検証することで信頼関係を確立できるようになります。また、侵害された場合に使用を制限するために、証明書のライフサイクルを管理する必要もあります。

活用方法:

OpenShift Container Platform: クライアントが信頼済みエンドポイントと通信していることを確認するためのクラスター署名付きサービス証明書。これには、サービスが SSL/TLS を使用し、クライアントがクラスター CA を使用することが必要です。クライアントアイデンティティーは他の手段で提供する必要があります。
Red Hat Single Sign-On: エンタープライズユーザーディレクトリーまたはサードパーティーのアイデンティティープロバイダーとの要求認証インテグレーションを提供します。
Red Hat OpenShift Service Mesh: mTLS への接続の透過的なアップグレード、自動ローテーション、カスタム証明書の有効期限、JSON Web トークン (JWT) による要求認証。
OpenShift cert-manager Operator: アプリケーションで使用する証明書の作成と管理。証明書は CRD により制御され、シークレットとしてマウントできます。また、cert-manager API と直接対話するようにアプリケーションを変更することもできます。

6.7.4. サービス間認可

リクエスト元のアイデンティティーに基づきサービスへのアクセスを制御できることが重要です。これはプラットフォームによって実行されるため、各アプリケーションで実装する必要はありません。これにより、ポリシーの監査と検査がより適切に行えるようになります。

活用方法:

OpenShift Container Platform: Kubernetes NetworkPolicy および AdminNetworkPolicy オブジェクトを使用して、プラットフォームのネットワーク層で分離を強制できます。
Red Hat OpenShift Service Mesh: 標準の Istio オブジェクトおよび mTLS を使用してトラフィックの送信元と宛先を識別し、その情報に基づきポリシーを適用する、高度な L4 および L7 のトラフィック制御。

6.7.5. トランザクションレベルの検証

接続の識別および認証機能に加えて、個々のトランザクションへのアクセスを制御するのにも役立ちます。これには、ソースによるレート制限、可観測性、トランザクションが適切に形成されていることのセマンティック検証などが含まれます。

活用方法:

Red Hat OpenShift Service Mesh: 要求の L7 検査、不正な HTTP 要求の拒否、トランザクションレベルの可観測性およびレポートを行います。Service Mesh は、JWT を使用した要求ベースの認証も提供できます。

6.7.6. リスク評価

クラスター内のセキュリティーポリシーの数が増えるにつれ、ポリシーが許可および拒否する内容の可視化がますます重要になります。これらのツールを使用すると、クラスターセキュリティーポリシーの作成、可視化、管理が容易になります。

活用方法:

Red Hat OpenShift Service Mesh: OpenShift Web コンソールを使用して、Kubernetes の NetworkPolicy と AdminNetworkPolicy、および OpenShift Networking の EgressFirewall オブジェクトを作成および可視化します。
Red Hat Advanced Cluster Security for Kubernetes: 高度なオブジェクトの可視化。

6.7.7. サイト全体のポリシーの施行と配布

クラスターにアプリケーションをデプロイした後、セキュリティールールを構成するすべてのオブジェクトを管理することが困難になります。サイト全体にポリシーを適用し、デプロイしたオブジェクトがポリシーに準拠しているかどうかを監査することが重要になります。これにより、定義された範囲内でユーザーとクラスター管理者に一部の権限を委譲できるようになり、必要に応じてポリシーの例外も許可されるようになります。

活用方法:

Red Hat OpenShift Service Mesh: ポリシーオブジェクトを制御し、制御を委譲する RBAC。
Red Hat Advanced Cluster Security for Kubernetes: ポリシー適用エンジン。
Red Hat Advanced Cluster Management (RHACM) for Kubernetes: 一元的なポリシー制御。

6.7.8. 継続的かつ遡及的な評価のための可観測性

クラスターを実行した後は、トラフィックを観察し、トラフィックが定義したルールに準拠していることを確認する必要があります。これは侵入検知やフォレンジックのために重要であり、運用負荷管理にも役立ちます。

活用方法:

Network Observability Operator: クラスター内の Pod やノードへのネットワーク接続に関する検査、モニタリング、アラートを可能にします。
Red Hat Advanced Cluster Management (RHACM) for Kubernetes: プロセス実行、ネットワーク接続とフロー、権限昇格などのシステムレベルのイベントを監視、収集、評価します。クラスターのベースラインを決定し、異常なアクティビティーを検出して警告することができます。
Red Hat OpenShift Service Mesh: Pod に出入りするトラフィックを監視できます。
Red Hat OpenShift 分散トレーシングプラットフォーム: 適切にインストルメント化されたアプリケーションの場合、特定のアクションがマイクロサービスへのサブリクエストに分割されるときに、そのアクションに関連付けられたすべてのトラフィックを確認できます。これにより、分散アプリケーション内のボトルネックを特定できます。

6.7.9. エンドポイントセキュリティー

クラスター内のサービスを実行しているソフトウェアが侵害されていないことを確信できることが重要です。たとえば、認定されたイメージが信頼済みハードウェア上で実行されるようにし、エンドポイントの特性に基づいてエンドポイントとの間の接続のみを許可するポリシーを設定する必要がある場合があります。

活用方法:

OpenShift Container Platform: Secureboot を使用すると、クラスター内のノードが信頼済みのソフトウェアを実行していることを確認できるため、プラットフォーム自体 (コンテナーランタイムを含む) が改ざんされていないことを確認できます。OpenShift Container Platform を、特定の署名で署名されたイメージのみを実行するように設定できます。
Red Hat Trusted Artifact Signer: 信頼済みビルドチェーンで使用でき、署名付きコンテナーイメージを生成できます。

6.7.10. クラスター外への信頼の拡張

クラスターによるサブドメインの CA 作成を許可することで、クラスター外部に信頼を拡張する必要がある場合があります。あるいは、クラスター内のワークロードアイデンティティーをリモートエンドポイントに証明する必要があることもあります。

活用方法:

OpenShift cert-manager Operator: cert-manager を使用して委譲された CA を管理し、クラスターをまたいで、もしくは組織全体で信頼を分散できます。
Red Hat OpenShift Service Mesh: SPIFFE を使用して、リモートまたはローカルクラスターで実行されているエンドポイントに、ワークロードのリモートアテステーションを提供できます。