マルチクラスタ OpenShift 環境における NIST 800-53 コントロールの管理 - パート 1

この 3 部構成のブログシリーズでは、マルチクラスタの OpenShift デプロイメントを管理する際に組織が直面する課題について説明し、それらが大規模組織のセキュリティとコンプライアンスにどのような影響を与えるかを検証します。その後、具体的なセキュリティ対策と、Red Hat OpenShift Platform Plus の機能を使って複数のクラスタにそれらを実装し、OpenShift クラスタ群のコンプライアンスを向上させる方法を説明します。標準的な参考資料として、NIST special publication 800-53 security controls を使用しています。Kubernetesと NIST 800-53 コントロールに関する既存の知識がある程度あることが前提です。

ソフトウェアだけでは NIST 800-53 コントロールに完全に対応できないことに注意してください。コントロールの多くは、組織的なプロセスの実装によって満たされる必要があります。しかし、ソフトウェアを使用して、特定の技術的フレームワークへの準拠を自動化および監視することができます。

現代的な考え方

かつて企業は、すべてのワークロードを実行するために、いくつかのオンプレミス・アプリケーション・プラットフォームを導入・管理することに注力していました。デジタル・トランスフォーメーションにより、新しいテクノロジーを使ってビジネス目標を達成するために組織が迅速に行動する必要性が加速し、組織は常により少ない資源でより多くのことを行う必要性に迫られています。COVID-19 は、多くの組織におけるデジタルトランスフォーメーションの役割を、戦略的な取り組みからダーウィン的な必須事項へと変えました。パブリック・クラウドの成長と、クラウド以外への投資を維持する必要性から、ハイブリッド・クラウド・ソリューションにはかつてないチャンスが生まれています。

クラウドネイティブ環境向けに構築されたコンテナ型アプリケーションのオーケストレーションには、Kubernetes が有力なソリューションとして登場しています。Red Hat OpenShift は、エンタープライズ向けのオープンソース・コンテナオーケストレーション・プラットフォームで、Kubernetes に加えて、大規模企業にとって重要な生産性とセキュリティの機能を備えています。企業は現在、複数のパブリッククラウドやプライベートクラウド、およびオンプレミスのデータセンターでワークロードを実行する複数の Kubernetes クラスタを管理することができます。これらのクラスタはそれぞれ、次のような異なるビジネスニーズを満たすように設計することができます。:

• 本番環境のワークロードの稼働

• ソフトウェア開発のテストおよび品質保証機能の実行

• 特定のビジネスユニットのワークロードの稼働

• クラスタ管理や AI/ML ワークロードなど、割り当てられた役割の実行

• エッジコンピューティング機能の実行

最新のソリューションが最新の課題を生み出す

ハイブリッドやマルチクラウドへの移行に伴い、組織内に多くの新しい課題が発生しました。デジタルトランスフォーメーションへの道のりにおいて、企業はしばしば次のような質問を投げかけます。:

1. NIST 800-53 のような契約上、規制上の義務をどのようにして適合し続けるのか？

2. 大規模な Kubernetes のデプロイメントをどうやって管理するか?

3. 組織のニーズや、セキュリティやソフトウェアエンジニアリングのエンタープライズスタンダードを満たすために、複数のクラスタで一貫した構成を維持するにはどうやればよいのか？

4. 新しいアプリケーションアーキテクチャでワークロードをセキュアにするにはどうすればよいか?

Red Hat OpenShift Platform Plus は、組織がこれらの疑問に答えるために設計されています。2021 年 4 月、Red Hat は、OpenShift Platform Plus を発表しました。これは、以下のコアソリューションを含むことで、DevSecOps のための高度なマルチクラスタ管理、ガバナンス、セキュリティを備えた OpenShift を拡張するものです。

1. Red Hat Advanced Cluster Management for Kubernetes (RHACM) - Red Hat Advanced Cluster Management for Kubernetes は、クラスタとアプリケーションのライフサイクル管理、ガバナンス、観測性をエンドツーエンドで提供し、マルチクラスタの Kubernetes 環境を管理します。

2. Red Hat Quay (Quay) - Red Hat Quay は、コンテナイメージの保存、ビルド、デプロイを行うプライベートコンテナレジストリです。コンテナイメージのセキュリティ脆弱性を分析する Clair が含まれており、セキュリティリスクを軽減するための潜在的な問題を特定します。

3. Red Hat Advanced Cluster Security for Kubernetes (RHACS) - Red Hat Advanced Cluster Security for Kubernetes は、クラスタおよびアプリケーションセキュリティのための Kubernetes ネイティブなアーキテクチャを提供し、DevOps および InfoSec チームがセキュリティを運用できるようにします。

NIST 800-53 とは?

NIST 800-53 は、米国政府の連邦情報システムのためのリスク管理フレームワークです。組織は通常、NIST 800-53 のリスク管理プログラムを導入する必要がありますが、その理由は、米国連邦政府の請負業者やベンダーであること、または米国政府との契約義務を維持するために NIST 800-53 に準拠しなければならない顧客を持っていることです。当初は連邦政府の情報システムを対象としていましたが、これらの統制は一般的に有用であり、ますます多くの企業が NIST 800-53 を活用して自社のセキュリティポリシーや要件を伝えています。

NIST 800-53 のコントロールは、以下の表のようにファミリーに分けられています。:

引用元: NIST 800-53 Rev5

これらのコントロールファミリーは、連邦政府の情報システムのセキュリティを確保するために必要な技術的およびプロセス管理のコントロールを定義しています。ソフトウェアだけで NIST 800-53 コントロールに完全に対応することはできませんが、ソフトウェアを使用して特定の技術的コントロールへの準拠を自動化および監視することができます。このガイドでは、NIST 800-53 準拠に向けて、OpenShift Platform Plus を使用して Kubernetes クラスタで特定の技術的統制に対処する方法をいくつか紹介します。

まず、OpenShift が単一の OpenShift クラスタのコンプライアンス管理にどのように役立つかを見て、次に OpenShift Platform Plus がクラスタ群全体のコンプライアンス管理の拡張にどのように役立つかを見ていきます。

OpenShift と OpenShift Compliance Operator

Compliance Operator により、OpenShift Container Platform の管理者は、クラスタが準拠すべき一連の技術的コントロールを特定し、ギャップの概要とそのギャップを修正する方法を知ることができます。Compliance Operator は、OpenShift の Kubernetes リソースと、クラスタを実行するノードのOSの両方のコンプライアンスを評価します。Compliance Operator は、NIST 認定のツールである OpenSCAP を使用して、Compliance Operator で提供されるプロファイルで提供されるセキュリティポリシーをスキャンし、実施します。Compliance Operator には、NIST 800-53 の関連する技術的コントロールに対するOpenShift クラスタの評価用プロファイルが含まれています。このソリューションは、OpenShift Platform Plus 内のコアビルディングブロックとして統合されています。

ここでは、「Compliance Operator」の仕組みについて詳しくご紹介します。

OpenShift compliance operator をインストールした後、以下のコマンドを実行することで、利用可能なコンプライアンスプロファイルを表示することができます。

$ oc get profiles.compliance -n openshift-compliance

NAMESPACE            NAME                      AGE

openshift-compliance   ocp4-cis                          35m

openshift-compliance   ocp4-cis-node                     35m

openshift-compliance   ocp4-e8                           35m

openshift-compliance   ocp4-moderate                     35m

openshift-compliance   rhcos4-e8                         35m

openshift-compliance   rhcos4-moderate                      35m

ocp4-moderateプロファイルは、OpenShift 4のデプロイメントにおけるNIST SP 800-53の影響度「中」(moderate impact）を与えるベースライン構成に焦点を当てています。このコンプライアンスプロファイルに関連するルールを表示するには、次のコマンドを実行して、ルールセクションの出力を確認します。

$ oc get profiles.compliance ocp4-moderate -n openshift-compliance -o yaml

apiVersion: compliance.openshift.io/v1alpha1

…..

rules:

- ocp4-api-server-client-ca

- ocp4-api-server-encryption-provider-cipher

- ocp4-api-server-encryption-provider-config

- ocp4-api-server-etcd-ca

- ocp4-api-server-tls-cert

- ocp4-api-server-tls-private-key

- ocp4-audit-log-forwarding-enabled

- ocp4-audit-profile-set

- ocp4-classification-banner

- ocp4-etcd-peer-cert-file

- ocp4-etcd-peer-key-file

- ocp4-kubelet-configure-tls-cert

- ocp4-kubelet-configure-tls-key

- ocp4-ocp-allowed-registries

- ocp4-ocp-allowed-registries-for-import

- ocp4-ocp-idp-no-htpasswd

title: NIST 800-53 Moderate-Impact Baseline for Red Hat OpenShift

各ルールは、NIST SP 800-53 セキュリティコントロールに関連付けられた OpenShift セキュリティプラクティスを反映しています。たとえば、ocp4-api-server-encryption-provider-cipher ルールは、etcd データベースが、AES-CBC 暗号化プロパイダで暗号化されていることを確認します。このルールの詳細を知るには、次のコマンドを実行します。

$ oc get rule.compliance ocp4-api-server-encryption-provider-cipher -n openshift-compliance -o yaml

apiVersion: compliance.openshift.io/v1alpha1

availableFixes:

- fixObject:

apiVersion: config.openshift.io/v1

kind: APIServer

metadata:

  name: cluster

spec:

  encryption:

    type: aescbc

description: To ensure the correct cipher, set the encryption type aescbc in the apiserver object which configures the API server itself …

kind: Rule

metadata:

 annotations:

compliance.openshift.io/image-digest: pb-ocp4dvvb5

compliance.openshift.io/rule: api-server-encryption-provider-cipher

control.compliance.openshift.io/CIS-OCP: 1.2.34

control.compliance.openshift.io/NIST-800-53: SC-28(1)

policies.open-cluster-management.io/controls: 1.2.34,SC-28(1)

policies.open-cluster-management.io/standards: CIS-OCP,NIST-800-53

 labels:

compliance.openshift.io/profile-bundle: ocp4

   name: ocp4-api-server-encryption-provider-cipher

 namespace: openshift-compliance

rationale: aescbc is currently the strongest encryption provider, it should be preferred over other providers.

このルールは、NIST SP 800-53 規格のセキュリティコントロール「SC-28 (1) Protection of information at rest」と関連していることに注意してください。

Compliance Operator のドキュメントに記載されているとおりにコンプライアンス スキャンを実行すると、選択したプロファイルまたはプロファイルに環境が準拠しているかどうかを検証できます。次の例では、ocp4-api-server-encryption-provider-cipher ルールに準拠していません

$ oc get ComplianceCheckResult -n openshift-compliance | grep cipher

NAME                                                                    STATUS          SEVERITY

ocp4-moderate-api-server-encryption-provider-cipher                     FAIL         medium

compliance operator のコンプライアンス ルールには、自動化された修復アクションが含まれていることがよくあります。コンプライアンス・ルールの修正は、ComplianceRemediation カスタム・リソースで表されます。ComplianceRemediation リソースの名前は、そのリソースが修正を提供するコンプライアンスルールの名前と同じです。例えば、ocp4-api-server-encryption-provider-cipher ルールの修正は、ocp4-api-server-encryption-provider-cipher ComplianceRemediation リソースによって提供されます。

$ oc get ComplianceRemediation -n openshift-compliance | grep cipher

NAME                                               STATE

ocp4-moderate-api-server-encryption-provider-cipher   NotApplied

ocp4-api-server-encryption-provider-cipher ComplianceCheckResult を修正するには以下のコマンドを実行します。:

$ oc patch ComplianceRemediation/ocp4-moderate-api-server-encryption-provider-cipher --patch '{"spec":{"apply":true}}' --type=merge -n openshift-compliance

コンプライアンス是正措置を適用した後、再度コンプライアンス スキャンを実行する。新しいスキャンでは、環境がルールとNIST 800-53 SC-28 (1) security controlに準拠していることが示されます。

$ oc get ComplianceCheckResult -n openshift-compliance | grep cipher

NAME                                                                    STATUS          SEVERITY

ocp4-moderate-api-server-encryption-provider-cipher                     PASS         medium

Compliance Operator は、基礎となるオペレーティングシステムである Red Hat Enterprise Linux CoreOS (RHEL CoreOS) をレビューするプロファイルも提供しています。Compliance Operator を使用すると、rhcos4-moderateプロファイルを使用して、NIST SP 800-53 技術的セキュリティコントロールに対する RHEL CoreOS ノードのコンプライアンスを評価することができます。

関連する NIST 800-53 技術的コントロールに準拠するように OpenShift クラスタを構成することは簡単です。ほとんどの技術的コントロールは、OpenShift 内でデフォルトで実装されています。デフォルトで実装されていないものは、Kubernetes 内に Software-Defined Network Boundary を実装するソリューションである NetworkPolicy など、OpenShift に組み込まれたメカニズムを使用して構成することができます。また、ResourceQuotas は、Kubernetes にデプロイされたアプリケーションが利用できるリソースを制限するソリューションです。

OpenShift クラスタの数が増えれば増えるほど、それらを安全に保つために必要なリソース、時間、注意事項が増えていきます。OpenShift Platform Plus は、宣言型のガバナンスとセキュリティポリシーを可能にし、RHACM と RHACS を使って OpenShift クラスタ群全体でそれらのポリシーの管理を自動化することで、組織のスケールアップを支援します。

以下のシナリオを見て、OpenShift のマルチクラスタ環境が、適用可能な NIST 800-53 技術的セキュリティコントロールに簡単に非準拠になることを理解しましょう。その後、RHACM と RHACS を使って、クラスタを技術的コントロールに準拠させる方法を見てみましょう。

マルチクラスタの構成とコンプライアンスの逸脱

A 社が、顧客のレイテンシーを軽減するために、複数の OpenShift クラスタを異なるサイトに展開することを決めたとします。すべてのクラスタは同じアプリケーションを実行しており、次の図のように組織内の管理チームによって管理されています。

Figure 1: 異なるサイトに展開された複数の個別の OpenShift クラスタを管理する管理者

この設定でのコンプライアンスのニーズにどのように対処すればよいか？

続きを読むと、このような状況でセキュリティコンプライアンス上の問題を引き起こす可能性のあるいくつかの要因と、関連する NIST 800-53 のセキュリティコントロールが表示されます。

• AC-3 - AC-3 コントロールでは、「適切なアクセス制御ポリシーに従って、情報およびシステムリソースへの論理アクセス に対して承認された認可を実施する」とされています。
  このシナリオでは、各クラスタがユーザーとグループに関連した一連の権限を維持します。大規模なマルチクラスタ環境では、特にセキュリティポリシーの変更が発生した場合に、承認された権限セットを維持することは困難です。
  このシナリオでは、ロールベースのアクセスコントロール（RBAC）のドリフトが頻繁に発生する可能性があり、AC-3 のセキュリティコントロールに準拠することが困難になります。

• SI-4(a.1)  - SI-4(a.1) のコントロールでは、「組織は、組織が定義した監視目的に従って、攻撃および潜在的な攻撃の指標を検出するために情報システムを監視する 」としています。
  このコントロールを満たすための1つの要素は、新たに発見された脆弱性がないかアプリケーションを監視し、その脆弱性の修正プログラムでアプリケーションを更新することです。組織がアプリケーションのインスタンスの脆弱性をスキャンしないと、一部のインスタンスが環境内で弱くなり、環境が SI-4(a.1) のセキュリティ管理に準拠しなくなる可能性があります。
  アプリケーションが複数のクラスタ上にインスタンスを持っている環境では、アプリケーションのバージョンのズレが発生しやすくなります。正しくプロビジョニングされていない場合、アプリケーションがクラスタ A ではバージョン 1、クラスタ B ではバージョン2を実行してしまうことがあります。このような場合、クラスタ A では、アプリケーションのバージョン 2 でパッチが適用されたセキュリティ脆弱性が発生しやすくなります。

• CM-2 - CM-2 コントロールでは、「組織は、情報システムの現在のベースライン構成を開発し、文書化し、構成管理の下で維持する 」としています。
  マルチクラスタ環境を管理していると、クラスタのベースライン構成間でズレが発生する可能性があります。個々のクラスタに加えられた変更により、異なるクラスタのベースライン構成がずれてしまうことがあります。組織内で構成管理が行われていないと、CM-2 セキュリティコントロールに準拠していない不整合な環境になってしまいます。

• SC-8 - SC-8 のコントロールでは、「情報システムは、送信される情報の機密性と完全性を保護する」とされています。
  この要求を満たすためには、転送中のデータ保護のために TLS を有効にし、TLS に使用する証明書を適切に管理する必要があります。証明書は、サービスの認証と安全なデータ伝送の両方に使用されます。そのため、TLS を設定し、TLS に使用する証明書を適切に管理し、ローテーションし、期限切れにならないようにすることが重要です。大規模な環境で証明書を手動で管理している場合、管理者は使用されているすべての証明書を把握できません。自動化と可視化ができないと、証明書の有効期限が切れたり、ローテーションが行われなかったりして、SC-8 のセキュリティ・コントロールに準拠しない環境になってしまいます。

上記の記載だけではなく、1 つのクラスタが他のクラスタと異なる状態になると、そのクラスタにセキュリティリスクが生じることがあります。権限が一致していない場合、その環境は AC セキュリティ・コントロールに準拠していない可能性があります。同様に環境内に構成管理ツールがない場合、環境は CM セキュリティ・コントロールに準拠していない可能性があります。

これまで述べてきたことは、ベスト・プラクティスやエンタープライズ・スタンダードとの整合性という 1 つのアイデアに焦点を当てています。整合性のない環境は、安全でない環境です。整合性のない環境は、すべてのクラスタが組織のセキュリティ要件や規制遵守義務に従っていないことを意味します。それらのクラスタは、環境内の攻撃対象を増やし、脆弱性を形成します。

これらの問題に取り組むために、Red Hat は大規模なアライメントの管理に役立つ2つのソリューションを提供しています。Red Hat Advanced Cluster Security と Red Hat Advanced Cluster Management for Kubernetes です。セキュリティとリスク管理には、Red Hat Advanced Cluster Security を使用します。ポリシーベースのガバナンスのためには、Red Hat Advanced Cluster Management を使用します。この2つの機能を併用することで、OpenShift クラスタ全体で大規模にエンタープライズセキュリティとガバナンスの目標を達成することができます。

Red Hat Advanced Cluster Security for Kubernetes を使用したワークロードセキュリティの拡張

Red Hat Advanced Cluster Security for Kubernetes は、Kubernetes に高度なセキュリティを提供し、組織が大規模でインテリジェントなアプリケーションを安全に構築、デプロイ、実行、管理できるようにします。複数のセキュリティ分析のレイヤーを持つこのプラットフォームは、DevSecOps の導入を可能にし、管理されたクラスタ全体のリスクを総合的にランク付けして評価します。これらにより、NIST 800-53 の目標を達成し、広範なセキュリティユースケースを実現することができます。

RHACS は、Kubernetes と OpenShift のための情報セキュリティアーキテクチャとリスク管理戦略の基本的な部分として機能します。RHACS は、チームが脆弱性管理、構成管理、およびコンプライアンスデータを使用してワークロードのリスクを可視化し、ランタイムイベントアラートと結合することを可能にします。

例えば、RHACS を使用して、Kubernetes のデプロイメントにセキュリティ属性を割り当てるために必要なラベリング戦略チームを強制することができます。これは、あらゆるデプロイメントが組織的に定義されたラベルを持つことを保証するために使用できます。組織は頻繁に、コストセンターからセキュリティコンテキストに至るまでのラベルを要求します。このセキュリティコンテキストは、その後、より広範なベースラインの構成と変更のためのアクセス制限の構成の一部として、適切な制御を割り当てるために使用できます。

ラベルの例としては、以下のようなものがあります:

• データの分類がサポートされている場合

• デプロイメントが最も重要なアプリケーションの一部である場合

• アプリケーションのデプロイメントがテストまたは本番環境である場合

これらは、以下の高度なセキュリティ制御を実施するために使用することができます:

• テスト環境に限り、Kubernetes API を通じてポッドへの直接アクセスを許可する。

• クラスタ内で実行されているデプロイメントに対して脆弱性スキャンを実行し、デプロイメントのデータ分類に基づいて異なる実行アクションを適用する。

• 攻撃対象を限定するために、最も重要なデプロイメントの一部であるコンテナイメージにセキュアシェルを使用できないようにする。

• 特権のあるコンテナに外部ロードバランサーを使用することを禁止する。

また、RHACS は、インシデント対応チームが自動および手動でインシデント対応を行うことを可能にします。RHACS は、アプリケーションの正常な動作を観察して、既知の正常なプロセスのリストを構築することにより、プロセスの自動発見とベースライン化の機能を提供します。セキュリティチームは、このベースラインを使用して、環境内で実行されている異常なプロセスを特定し、警告を発し、防止することができます。すぐに検出される一般的な攻撃指標としては、ポッド内でのパッケージマネージャの実行、クライポマイナの実行、ポッド内の特権的な機能を使用して既存の制御が不十分なホストOSを変更しようとする行為などがあります。

RHACS は、異常な動作を管理するために、リスク管理のアプローチをとっています。望ましい動作と望ましくない動作を区別するのは比較的簡単です。従来の検知技術の多くは、悪意のある動作か良性の動作かを判断するために、実行時のイベントだけを単独で見て、異常な動作を特定することに重点を置いています。RHACS は、クラウド・ネイティブ・インフラストラクチャの利点を活用して、異常なイベントを文脈の中に配置し、それらのイベントに基づいて強制力を適用するために必要な忠実度のレベルを下げます。

RHACS は、特定のアプリケーションのベースラインから外れたプロセス実行イベントを、そのアプリケーションがどのように構築され、設定され、実行時に何をすることになっているかという文脈で見ることができます。ユーザーはこの情報をもとに、そのアクティビティをベースラインに追加して望ましい動作として分類するかどうかを判断することができます。望ましくない動作を判断するには、この動作を制御するための RHACS ポリシーを作成し、ポッドを削除したり、通知先（チームの slack チャンネルや SIEM など）にアラートを送信したりすることで、インシデント対応のワークフローを開始します。

Red Hat Quay を使用してコンテナイメージを安全に配布し、プライベートコンテナイメージに最小特権を適用する

Red Hat Quay コンテナイメージレジストリは、ストレージを提供し、コンテナの構築、配布、およびデプロイを可能にします。組織は、Quay で利用可能な自動化、認証、および認可システムを使用して、イメージリポジトリのセキュリティを強化するために、アクセス制御を実施することができます。

コンテナイメージレジストリは、コンテナ化されたアプリケーションのセキュリティ確保に重要な役割を果たします。あなたのチームは、ダウンロードした公開コンテナイメージの上に必要なイメージを載せてコンテナを構築しています。ほかの種類のバイナリを管理するのと同じ方法で、ダウンロードしたコンテナイメージや内部でビルドしたイメージへのアクセスやプロモーションを管理する必要があります。

Red Hat Quay にはイメージスキャン用の Clair が含まれています。Clair プロジェクトはオープンソースのエンジンで、Red Hat Quay のセキュリティスキャナーを強化し、Red Hat Quay 内のすべてのイメージの脆弱性を検出します。Red Hat OpenShift Container Security Operator は Red Hat Quay と統合し、OpenShift コンソールでデプロイされたイメージの既知の脆弱性をクラスタ全体で表示します。

Red Hat Advanced Cluster Management for Kubernetes を使用して、クラスタの構成とガバナンスを拡張する

Red Hat Advanced Cluster Management for Kubernetes は、開発者や管理者が複数の OpenShift クラスタ上で動作するクラウド・ネイティブ・アプリケーションを管理するためのプラットフォームです。RHACM は、複数のクラウドプロバイダーにまたがる OpenShift クラスタの作成をサポートします。環境内のすべてのクラスタのリソースやメトリクスを可視化する監視システムを提供しています。RHACM は、複数のクラスタでアプリケーションをプロビジョニングするデプロイメントツールを実装しています。最も重要なのは、ポリシーベースのガバナンスを提供することで、ベストプラクティスに基づいた望ましい構成状態でのクラスタの運用を可能にすることです。また、このような望ましい構成状態から外れてしまったクラスタを簡単に検出することができます。

ガバナンス・リスク・コンプライアンス

大規模なマルチクラスタ環境を規制するために、RHACM は重要なツールであるポリシーベースのガバナンスフレームワークを提供し、以下の主要な機能を提供します。:

• 拡張可能なポリシーフレームワークを使用して、複数のクラスタの構成を管理

• 配置ルールを使用してポリシーを管理対象クラスタにバインド

• OpenShift Compliance Operator との統合をサポート

• Gatekeeper/OPA、Kyverno など、複数のポリシーエンジンをサポート

• GitOpsのデプロイメントポリシーに対応

• ハードウェア/ソフトウェアスタック全体に適用可能

• マルチクラスタオブザーバビリティ機能により、クラスタやアプリケーションを横断したビューを提供

• Policy Collection Repo でのポリシーの共同開発のための活発なアップストリームコミュニティをサポートする

• SysDig/Galco、Synopsys Black Duck などのサードパーティ製 PEP（Policy Enforcement Point）をサポート

• コンプライアンス・オペアレーターでは提供されない、セキュリティ、耐障害性、およびソフトウェア・エンジニアリングの制御のためのアウトオブボックス・ポリシーを提供

• Red Hat、IBM、およびサードパーティのコミュニティコントリビュートを支援

RHACM は、ポリシーフレームワークを使用して、企業内部および外部の技術的規制のコンプライアンス基準を満たすために、お客様の Kubernetes クラスタが望ましい状態に設定されていることを確認します。管理対象のクラスタが定義されたポリシーに違反した場合、RHACMコンソールにアラートが送信されます。管理可能な構成の例としては、OpenShift Compliance Operator、Red Hat OpenShift Container Security Operator、OPA Gatekeeper Operator など、機能を提供する様々なオペレーターが OpenShift クラスタ群上に展開され、実行されていることを確認することが挙げられます。

ガバナンスの仕組みや概念をさらに理解するために、以下の情報を参照してください:

•  Red Hat Advanced Cluster Management for Kubernetes Governance documentation.

•  Comply to standards using policy based governance of Red Hat Advanced Cluster Management for Kubernetes , Implement Policy-based Governance Using Configuration Management of Red Hat Advanced Cluster Management for Kubernetes.

ブログシリーズのこのパートでは、マルチクラスタ OpenShift デプロイメントにおけるコンプライアンスをサポートする主な考え方とツールについて説明しました。マルチクラスタ OpenShift の実装におけるセキュリティ上の課題と、特定の NIST SP 800-53 技術的統制への準拠を実現するためのツールについて説明しました。この複数ブログシリーズの次の章では、OpenShift Platform Plus に付属するツールを使って、マルチクラスタ OpenShift 環境で特定の NIST SP 800-53 セキュリティコントロールへの準拠を実現するための実践的なデモンストレーションをご紹介します。

• マルチクラスタ OpenShift 環境における NIST 800-53 コントロールの管理 - パート２
• マルチクラスタ OpenShift 環境における NIST 800-53 コントロールの管理 - パート３