Red Hat OpenStack Platform の強化

デフォルトでは、Red Hat OpenStack Platform (RHOSP) director は、以下のツールを使用してオーバークラウドを作成し、セキュリティーに対するアクセス制御を行います。

組織のニーズおよび信頼レベルに基づいて、以下に示す新たなセキュリティー機能で director を設定することができます。

ユーザーに admin のロールを割り当てると、このユーザーには、任意のプロジェクトの任意のリソースを表示、変更、作成、または削除する権限があります。このユーザーは、公開されている Glance イメージやプロバイダーネットワークなど、プロジェクト間でアクセスできる共有リソースを作成できます。さらに、admin ロールを持つユーザーは、ユーザーを作成または削除し、ロールを管理できます。

ユーザーに admin ロールを割り当てるプロジェクトは、openstack コマンドが実行されるデフォルトのプロジェクトです。たとえば、development という名前のプロジェクトの admin ユーザーが次のコマンドを実行すると、internal-network という名前のネットワークが development プロジェクトに作成されます。

openstack network create internal-network

admin ユーザーは、--project パラメーターを使用して、任意のプロジェクトに internal-network を作成できます。

openstack network create internal-network --project testing

セキュリティーゾーンは、共通のセキュリティー上の懸念を共有するリソース、アプリケーション、ネットワーク、およびサーバーです。認証認可要件とユーザーを共有するようにセキュリティーゾーンを設計します。クラウドのアーキテクチャー、環境内で許可される信頼レベル、および標準化された要件に基づいて、独自のセキュリティーゾーンを必要な粒度で定義します。ゾーンとその信頼要件は、クラウドインスタンスがパブリック、プライベート、またはハイブリッドであるかによって異なります。

たとえば、Red Hat OpenStack Platform のデフォルトのインストールを以下のゾーンにセグメント化することができます。

以下のコマンドを実行して、Red Hat OpenStack Platform デプロイメントの物理的な設定に関する情報を収集します。

信頼レベルや認証要件が異なる複数のセキュリティーゾーンにまたがるコンポーネントは、慎重に設定する必要があります。これらの接続は、ネットワークアーキテクチャーの弱点になることが多々あります。これらの接続は、接続されるいずれかのゾーンの最高の信頼レベルのセキュリティー要件を満たすように設定されていることを確認してください。多くの場合、攻撃の可能性があるため、接続されたゾーンのセキュリティー制御が主要な懸念事項になります。ゾーンが交わるポイントは、新たな潜在的な攻撃サービスを提供し、攻撃者がデプロイメントのより繊細な部分に攻撃を移行する機会を増やします。

場合によっては、OpenStack 運用者は、統合ポイントのセキュリティーを、それが存在するどのゾーンよりも高い基準で確保することを検討する必要があるかもしれません。上記の API エンドポイントの例では、管理ゾーンが完全に分離されていない場合、敵対者はパブリックゾーンからパブリック API エンドポイントを標的とし、これを足掛かりにして管理ゾーン内の内部または管理者 API を侵害したりアクセスしたりする可能性があります。

OpenStack の設計は、セキュリティーゾーンの分離が難しいようになっています。コアサービスは通常 2 つのゾーンにまたがるので、セキュリティーコントロールを適用する際には、特別な考慮が必要になります。

クラウドデプロイメント、パブリック、プライベート、またはハイブリッドの多くのタイプは、一部のセキュリティーの脅威に公開されます。以下のプラクティスを使用すると、セキュリティーの脅威を軽減するのに役立ちます。

Compute サービスは、悪意のあるアクターに DDoS 攻撃やブルートフォース攻撃のツールを提供できます。防止策としては、出口のセキュリティーグループ、トラフィック検査、侵入検知システム、お客様への教育啓発などがあります。インターネットなどのパブリックネットワークからアクセスできる、またはパブリックネットワークにアクセスできる環境では、理想的にアウトバウンドの不正使用を検出し、またそれに対処するためのプロセスとインフラストラクチャーを整備する必要があります。

オーバークラウドのイメージでは、root ユーザーのセキュリティー強化機能が自動的に含まれます。たとえば、デプロイされる各オーバークラウドノードでは、root ユーザーへの直接の SSH アクセスを自動的に無効化されます。ただし、オーバークラウドノードの root ユーザーにアクセスすることはできます。各オーバークラウドノードには tripleo-admin ユーザーアカウントがあります。このユーザーアカウントにはアンダークラウドのパブリック SSH キーが含まれています。これにより、アンダークラウドからオーバークラウドノードへのパスワードなしの SSH アクセスが可能になります。

Red Hat OpenStack Platform をデプロイすると、各コアサービスがデフォルトのファイアウォールルールセットとともに各オーバークラウドノードにデプロイされます。ExtraFirewallRules パラメーターを使用して、追加サービスのポートを開くルールを作成したり、サービスを制限するルールを作成したりできます。

各ルール名はそれぞれの iptables ルールのコメントになります。各ルール名は、3 桁の接頭辞で始まる点に注意してください。この接頭辞は、Puppet が最終の iptables ファイルに記載されているルールを順序付けるのに役立ちます。デフォルトの Red Hat OpenStack Platform ルールでは、000 から 200 までの範囲の接頭辞を使用します。新しいサービスのルールを作成するときは、名前の前に 200 より大きい 3 桁の数字を付けます。

ルールを使用してサービスを制限できます。ルール名に使用する番号によって、ルールが挿入される iptables の場所が決まります。次の手順は、rabbitmq サービスを InternalAPI ネットワークに制限する方法を示しています。

director は、オーバークラウド向けのデフォルトの読み取り専用 SNMP 設定を提供します。SNMP の文字列を変更して、権限のないユーザーがネットワークデバイスに関する情報を取得するリスクを軽減することを推奨します。

オーバークラウドの環境ファイルで ExtraConfig フックを使用して、以下の hieradata を設定します。

以下に例を示します。

parameter_defaults:
  ExtraConfig:
    snmp::ro_community: mysecurestring
    snmp::ro_community6: myv6securestring

これにより、全ノードで、読み取り専用の SNMP コミュニティー文字列が変更されます。

以下に例を示します。

parameter_defaults:
  ExtraConfig:
    snmp::com2sec: ["notConfigUser default mysecurestring"]
    snmp::com2sec6: ["notConfigUser default myv6securestring"]

これにより、全ノードで、読み取り専用の SNMP コミュニティー文字列が変更されます。

詳細は man ページの snmpd.conf を参照してください。

Red Hat OpenStack Platform director の Open vSwitch (OVS) ファイアウォールドライバーを使用するように、セキュリティーグループを設定することができます。NeutronOVSFirewallDriver パラメーターを使用して、使用するファイアウォールドライバーを指定します。

openvswitch ファイアウォールドライバーはパフォーマンスがより高く、ゲストをプロジェクトネットワークに接続するためのインターフェイスとブリッジの数を削減します。

network-environment.yaml ファイルで NeutronOVSFirewallDriver パラメーターを設定します。

NeutronOVSFirewallDriver: openvswitch

Red Hat OpenStack Platform (RHOSP) デプロイメントの各ノードは、クラウドのインフラストラクチャーに貢献したり、クラウドのリソースを提供したりと、特定ロールを果たしています。

インフラストラクチャーに貢献するノードは、メッセージキューイングサービス、ストレージ管理、モニタリング、ネットワークなど、クラウドの運用やプロビジョニングをサポートするために必要なクラウド関連サービスを実行します。インフラストラクチャーロールの例としては、以下のようなものがあります。

クラウドリソースを提供するノードは、お客様のクラウド上で動作するインスタンスのために、コンピュートやストレージの容量を提供します。リソースロールの例としては、以下のようなものがあります。

お客様の環境で使用されているシステムロールを文書化します。これらのロールは、RHOSP のデプロイに使用されるテンプレート内で識別できます。たとえば、お客様の環境で使用されている各ロールの NIC 設定ファイルがあります。

イントロスペクションで収集されたデータを表示することで、Red Hat OpenStack Platform のデプロイメントに関するハードウェア情報を取得できます。Introspection では、CPU、メモリー、ディスクなどのハードウェア情報をノードから収集します。

Red Hat OpenStack Platform (RHOSP) インフラストラクチャーにデプロイしたノードで使用されているソフトウェアコンポーネントを文書化します。システムデータベース、RHOSP ソフトウェアサービス、およびロードバランサー、DNS、または DHCP サービスなどのサポートコンポーネントは、ライブラリー、アプリケーション、またはソフトウェアのクラスにおける漏洩や脆弱性の影響を評価する際に重要です。

Fernet は、UUID トークンプロバイダーに代わるデフォルトのトークンプロバイダーです。デフォルトでは、各 fernet トークンは最大 1 時間有効です。これにより、ユーザーは再認証を必要とせずに一連のタスクを実行できます。

認証後、Identity サービス (keystone) は次のことを行います。

Red Hat OpenStack Identity サービス (keystone) は、以下のエンティティーを認識します。

OpenStack Identity サービス (keystone) に必要な認証セキュリティー要件を調整できます。

ログイン試行の失敗が繰り返される場合は、ブルートフォース攻撃が試みられている可能性があります。ログインに何度も失敗した場合、Identity Service を使用してアカウントへのアクセスを制限できます。

外部認証プロバイダー (IdP) を使用して OpenStack サービスプロバイダー (SP) に対して認証することができます。SP は、OpenStack クラウドによって提供されるサービスです。

別の IdP を使用する場合、外部認証のクレデンシャルは、他の OpenStack サービスによって使用されるデータベースからは分離されます。このように分離することで、保存された認証情報が侵害されるリスクが軽減されます。

各外部 IdP には、OpenStack Identity サービス (keystone) ドメインへの 1 対 1 のマッピングがあります。Red Hat OpenStack Platform では複数のドメインを共存させることができます。

外部認証は、追加の ID を作成することなく、既存の認証情報を使用して Red Hat OpenStack Platform のリソースにアクセスする方法を提供します。認証情報は、ユーザーの IdP によって維持されます。

ID 管理には、Red Hat Identity Management (IdM) や Microsoft Active Directory Domain Services (AD DS) などの IdP を使用できます。この設定では、OpenStack Identity サービスには LDAP ユーザーデータベースへの読み取り専用アクセス権があります。ユーザーまたはグループのロールに基づく API アクセスの管理は、keystone によって実行されます。ロールは、OpenStack Identity サービスを使用して LDAP アカウントに割り当てられます。

4.5.1. LDAP 統合の仕組み

以下の図では、keystone は暗号化された LDAPS 接続を使用して Active Directory Domain Controller に接続します。ユーザーが horizon にログインすると、keystone は指定したユーザー認証情報を受け取り、Active Directory に渡します。

関連情報

• OpenStack Identity (keystone) と Active Directory の統合
• OpenStack Identity (keystone) と Red Hat Identity Manager (IdM) の統合
• ドメイン固有の LDAP バックエンドを使用する director の設定

PKI のコアコンポーネントを次の表に示します。

公開されている Red Hat OpenStack Platform ダッシュボードまたは公開されている API については、広く認知されている認証局 (CA) によって署名された証明書を取得する必要があります。

TLS で保護する各エンドポイントに DNS ドメインまたはサブドメインを付与する必要があります。指定したドメインは、CA が発行する証明書を作成するために使用されます。CA がエンドポイントを検証できるように、顧客は DNS 名を使用してダッシュボードまたは API にアクセスします。

Red Hat は、内部トラフィックを保護するために、別の内部管理 CA を使用することを推奨します。これにより、クラウドデプロイヤーは秘密鍵インフラストラクチャー (PKI) 実装の制御を維持でき、内部システムの証明書の要求、署名、デプロイが容易になります。

オーバークラウドのエンドポイントで SSL/TLS を有効にすることができます。どこでも TLS (TLS-e) を設定するために必要な証明書の数が多いため、director は Red Hat Identity Management (IdM) サーバーと統合して認証局として機能し、オーバークラウド証明書を管理します。TLS-e の設定の詳細は、Ansible を使用した TLS-e の実装 を参照してください。

OpenStack 全コンポーネントの TLS サポートのステータスを確認するには、TLS Enablement status matrix を参照してください。

独自の認証局で SSL 証明書を使用する場合は、オーバークラウドのパブリックエンドポイントでの SSL/TLS の有効化 を参照してください。

cipherscan を使用して、デプロイで提示されている TLS のバージョンを確認できます。暗号スキャンは、https://github.com/mozilla/cipherscan からクローンできます。この出力例は、horizon から受信した結果を示しています。

サーバーのスキャン時に、Cipherscan インターバリーが、ネゴシエートする最大の TLS バージョンである特定の TLS バージョンのサポートをアドバータイズします。ターゲットサーバーが TLS プロトコルを正しく従うと、相互に対応している最新バージョンで応答します。これは、最初にアドバータイズされた Cipherscan よりも低くなる可能性があります。サーバーが特定のバージョンを使用するクライアントとの接続を確立し続けると、そのプロトコルバージョンに対する耐性があるとみなされません。(指定されたバージョンまたは下位バージョンを使用する) 接続を確立しない場合は、そのバージョンのプロトコルの耐性があることが考慮されます。以下に例を示します。

Intolerance to:
 SSL 3.254           : absent
 TLS 1.0             : PRESENT
 TLS 1.1             : PRESENT
 TLS 1.2             : absent
 TLS 1.3             : absent
 TLS 1.4             : absent

この出力では、TLS 1.0 および TLS 1.1 のイントレランスは PRESENT として報告されます。これは、接続を確立できず、その Cipherscan がこれらの TLS バージョンのアドバタイズメントサポート中に接続できなかったことを意味します。そのため、スキャンされたサーバーでプロトコルの (およびそれより低い) バージョンが有効ではないことを確認する必要があります。

Red Hat では IdM サーバーと OpenStack 環境の統合が円滑に進むように、以下の情報を提供しています。

IdM インストール用に Red Hat Enterprise Linux を準備する方法は、Identity Management のインストール を参照してください。

ipa-server-installコマンドを実行して、IdM をインストールおよび設定します。コマンドパラメーターを使用すると対話型プロンプトをスキップできます。IdM サーバーを Red Hat OpenStack Platform 環境と統合できるように、以下の推奨事項を使用してください。

Red Hat OpenStack Platform ノードとの通信を有効にするには、IdM に必要なファイアウォールポートを開く必要があります。詳細は、IdM に必要なポートの解放 を参照してください。

新しい tripleo-ipa メソッドを使用して、どこでも TLS (TLS-e) と呼ばれるオーバークラウドエンドポイントで SSL/TLS を有効にすることができます。必要な証明書の数が多いため、Red Hat OpenStack Platform は Red Hat Identity Management (IdM) と統合されています。tripleo-ipa を使用して TLS-e を設定する場合、IdM が認証局です。

クラウドの完全修飾ドメイン名 (FQDN) を使用して、tripleo-ipa に必要なクラウド名とクラウドドメインパラメーターを定義します。たとえば、FQDN が overcloud.example.com の場合は、次の値を使用します。

環境の要件に基づいて、次の追加パラメーターを設定します。

memcached トラフィックを TLS-e で暗号化できるようになりました。この機能は、novajoin と tripleo-ipa の両方で機能します。

暗号化されたサービストラフィックの証明書の作成に使用する秘密鍵のサイズを増やすことで、セキュリティーを向上できます。デフォルトの RHOSP 秘密鍵のサイズである 2048 ビットは、米国国立標準技術研究所 (NIST) が推奨する最小値と同じです。

環境 Heat テンプレートでこれらのパラメーターを使用し、そのテンプレートをオーバークラウドのデプロイメントコマンドに含めます。オーバークラウドをすでにデプロイしている場合は、最初に使用したものと同じテンプレートを使用して同じ openstack overcloud deploy コマンドを再実行して、新しいパラメーターを追加し、変更を有効にする必要があります。

次の例では、秘密鍵のグローバル値は 4096 です。RedisCertificateKeySize がグローバルパラメーターをオーバーライドするため、redis の秘密鍵は 2048 になります。

parameter_defaults:
    CertificateKeySize: '4096'
    RedisCertificateKeySize: '2048'

既存の IPA サーバーをレプリカに置き換える場合は、必要なパラメーターを更新する必要があります。そうしないと、クラスターの設定を更新する際、オーバークラウドのデプロイメントが失敗します。

署名ホストとは、認証局を使用して新規証明書を生成し署名するホストです。選択した署名ホスト上で SSL 証明書を作成したことがない場合には、ホストを初期化して新規証明書に署名できるようにする必要がある可能性があります。

通常、SSL/TLS 証明書の署名には、外部の認証局を使用します。場合によっては、独自の認証局を使用する場合もあります。たとえば、内部のみの認証局を使用するように設定する場合などです。

SSL/TLS を使用して通信する外部クライアントについては、Red Hat OpenStack Platform 環境にアクセスする必要のある各クライアントに認証局ファイルをコピーします。

OpenStack 環境で SSL/TLS を有効にするには、証明書を生成するための SSL/TLS 鍵が必要です。

証明書署名要求を作成するには、以下の手順を実施します。

このコマンドにより、証明書署名要求として server.csr.pem ファイルが生成されます。このファイルを使用して OpenStack SSL/TLS 証明書を作成します。

OpenStack 環境の SSL/TLS 証明書を生成するには、以下のファイルが必要です。

上記のコマンドにより、server.crt.pem という名前の新規証明書が作成されます。OpenStack SSL/TLS 鍵と共にこの証明書を使用します。

OpenStack SSL/TLS 証明書をアンダークラウドのトラストバンドルに追加するには、以下の手順を実施します。

オーバークラウドで SSL/TLS を有効にするには、SSL/TLS 証明書と秘密鍵のパラメーターを含む環境ファイルを作成する必要があります。

証明書の署名者がオーバークラウドのイメージにあるデフォルトのトラストストアに含まれない場合には、オーバークラウドのイメージに認証局を注入する必要があります。

このファイルを編集して、下記のパラメーターに以下の変更を加えます。

CAMap パラメーターを使用して、別の CA を注入することもできます。

DNS ホスト名を使用して SSL/TLS でオーバークラウドにアクセスする場合には、/usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml ファイルを /home/stack/templates ディレクトリーにコピーします。

すべてのフィールドのホスト名およびドメイン名を設定し、必要に応じてカスタムネットワークのパラメーターを追加します。

デプロイメントコマンド openstack overcloud deploy で -e オプションを使用して、デプロイメントプロセスに環境ファイルを追加します。このセクションの環境ファイルは、以下の順序で追加します。

$ openstack overcloud deploy --templates \
[...]
-e /home/stack/templates/enable-tls.yaml \
-e ~/templates/custom-domain.yaml \
-e ~/templates/inject-trust-anchor-hiera.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml

TLS everywhere (TLS-e) プロセスで自動生成されない専用の SSL/TLS 証明書を使用する場合は、以下の手順を実施します。

Fernet トークンが適切に機能していることを確認するには、コントローラーノードの IP アドレスを取得し、コントローラーノードに対して SSH を実行し、トークンドライバーおよびプロバイダーの設定を確認します。

FIPS を有効にする場合は、アンダークラウドとオーバークラウドのインストール中に一連の手順を完了する必要があります。

ペルソナは、ロールとロールが属するスコープの組み合わせです。Red Hat OpenStack Platform 17 をデプロイすると、プロジェクトスコープから任意のペルソナを割り当てることができます。

セキュアなロールベースの認証をアクティブ化すると、Red Hat OpenStack Platform 環境でユーザーに割り当てられるパーミッションの範囲を定義する一連の新しいポリシーファイルがアクティブ化されます。

Red Hat OpenStack Platform で SRBAC を使用すると、ユーザーを project-admin、project-member、または project-reader のロールに割り当てることができます。

サービスのポリシーファイルはこれまで /etc/$service ディレクトリーに存在していました。たとえば、Compute (nova) の policy.json ファイルの完全パスは /etc/nova/policy.json でした。

既存のポリシーを見つける方法に影響を与える重要なアーキテクチャーの変更には、以下の 2 つがあります。

デフォルトでは、生成されたポリシーは oslo.policy CLI ツールにより stdout にプッシュされます。

サービスポリシーファイルステートメントは、エイリアス定義またはルールです。エイリアスの定義はファイルの先頭に存在します。以下のリストには、Compute (nova) 用に生成された policy.json ファイルからのエイリアス定義の説明が記載されています。

Policy.json ファイルは特定のオペレーターをサポートするので、これらの設定のターゲットスコープを制御できます。たとえば、以下の keystone の設定には、ユーザー作成の管理ユーザーだけがルールが含まれます。

"identity:create_user": "rule:admin_required"

: 文字の左側にあるセクションでは、特権を説明し、右側のセクションは、特権を使用できるユーザーを定義します。右側にオペレーターを使用して、スコープをさらに制御することもできます。

たとえば、以下の設定は、新規ユーザーを作成するパーミッションを持たないことを意味します。

"identity:create_user": "!"

デフォルトのルールを上書きするには、適切な OpenStack サービスの policy.json ファイルを編集します。たとえば、Compute サービスには nova ディレクトリーに policy.json があります。これは、コンテナーから表示する際にコンテナー化されたサービスの正しい場所となります。

このロールの意図は、admin アクセスを付与せずに、特定のユーザーに追加のパーミッションを付与することです。これらの特権を使用するには、以下のパーミッションをカスタムロールに付与する必要があります。

API 呼び出しを実行するユーザーの属性に基づいて、API 呼び出しへのアクセスを制限するポリシーを作成できます。たとえば、以下のデフォルトのルールは、管理者コンテキストから実行された場合のキーペアの削除が許可されるか、トークンのユーザー ID がターゲットに関連付けられたユーザー ID と一致することを示しています。

"os_compute_api:os-keypairs:delete": "rule:admin_api or user_id:%(user_id)s"

注記: *新しい実装機能は、各リリースと共に各サービスに保証される訳ではありません。したがって、ターゲットサービスの既存のポリシーの規則を使用してルールを作成することが重要です。これらのポリシーの表示に関する詳細は、既存ポリシーの確認を参照してください。* すべてのポリシーは、リリース間の互換性の保証が保証されないため、デプロイするすべてのバージョンの非実稼働環境でテストする必要があります。

上記の例では、API ルールを作成し、リソースを所有するかどうかに基づいてユーザーへのアクセスを拡張または制限できます。また、属性と他の制限を組み合わせて、以下の例で示すようにルールを形成できます。

"admin_or_owner": "is_admin:True or project_id:%(project_id)s"

上記の例を考慮すると、管理者およびユーザーに限定した一意のルールを作成し、そのルールを使用してさらにアクションを制限することができます。

"admin_or_user": "is_admin:True or user_id:%(user_id)s"
"os_compute_api:os-instance-actions": "rule:admin_or_user"

heat を使用して、オーバークラウド内の特定のサービスのアクセスポリシーを設定できます。次のパラメーターを使用して、それぞれのサービスにポリシーを設定します。

サービスのポリシーを設定するには、サービスのポリシーを含むハッシュ値をポリシーパラメーターに指定します。次に例を示します。

Red Hat OpenStack Platform で利用可能なツールを使用して、ユーザーおよび関連付けられた権限ごとのロール割り当てのレポートをビルドできます。

所定のロールがアクセスできる API 呼び出しを監査できます。各ロールに対してこのプロセスを繰り返すと、各ロールのアクセス可能な API に包括的なレポートが実行されます。

運用とセキュリティー上のニーズの両方で、組織全体で時刻が一貫していることが重要です。

Network time protocol (NTP) は、階層的な設定で整理されています。各レイヤーは stratum と呼ばれます。階層の最上位は、原子時計などの stratum 0 デバイスです。NTP 階層では、stratum 0 デバイスは、一般に利用可能な stratum 1 および stratum 2 の NTP 時刻サーバーに参照を提供します。

データセンタークライアントは、一般に利用可能な NTP stratum 1 または 2 サーバーに直接接続しないでください。直接接続の数は、パブリック NTP リソースに不必要な負荷をかけます。代わりに、データセンターで専用の時刻サーバーを割り当て、クライアントをその専用サーバーに接続します。

インスタンスがホストではなく専用の時刻サーバーから時刻を受信するように設定します。

クラウド環境で使用するハードウェアを追加する場合は、ハードウェア仮想化がサポートされていることを確認してください。使用しないハードウェア機能を無効にします。

セキュリティー、パフォーマンス、およびサポート性のために、Red Hat OpenStack Platform (RHOSP) を最新の状態に保ちます。

また、以下を行う際に SSH キーが 2048 ビット未満である場合は、SSH キーを更新する必要があります。

SSH キーをローテーションするプロセスを安全に自動化するために、ssh_key_rotation.yaml Ansible Playbook を実行します。オーバークラウドでは、バックアップキーが次のディレクトリーに保存されます。

/home/{{ ansible_user_id }}/backup_keys/{{ ansible_date_time.epoch }}/authorized_keys"

使用するハードウェアおよびソフトウェア機能のみを有効にして、攻撃の可能性にさらされるコードを少なくします。信頼できる環境でのみ有効にする必要がある機能がいくつかあります。

Network Functions Virtualization (NFV) などの特定のユースケースでは、PCI パススルーを有効にする必要があります。デプロイメントに必要でない限り、PCI パススルーを有効にしないでください。

SELinux (Security-Enhanced Linux) は、強制アクセス制御 (MAC) の実装です。MAC は、プロセスまたはアプリケーションがシステム上で実行できることを制限することにより、攻撃の影響を制限します。SELinux の詳細は、SELinux とは を参照してください。.

Red Hat OpenStack Platform (RHOSP) サービス用に SELinux ポリシーが事前設定されています。RHOSP では、SELinux は、個別のセキュリティーコンテキストで各 QEMU プロセスを実行するように設定されます。RHOSP では、SELinux ポリシーはハイパーバイザーのホストとインスタンスを次の脅威から保護するのに役立ちます。

RHOSP では、ディスク上のインスタンスイメージファイルは SELinux データ型 svirt_image_t でラベル付けされます。インスタンスの電源がオンになると、SELinux はランダムな数値識別子をイメージに追加します。ランダムな数値識別子により、侵害された OpenStack インスタンスが他のコンテナーへの不正アクセスを取得するのを防ぐことができます。SELinux は、各ハイパーバイザーノードに最大 524,288 個の数値識別子を割り当てることができます。

Red Hat OpenStack Platform に付属する OpenStack サービスは、コンテナー内で実行されます。コンテナー化により、依存関係に関連する競合なしでサービスの開発とアップグレードが可能になります。サービスがコンテナー内で実行される場合、そのサービスに対する潜在的な脆弱性も含まれます。

次の手順を使用して、環境で実行されているサービスに関する情報を取得できます。

コンテナーが再起動されても維持されるが、Red Hat OpenStack Platform (RHOSP) クラスターの永続的な設定には影響しない、コンテナー化されたサービスに変更を加えることができます。これは、設定の変更をテストしたり、トラブルシューティング時にデバッグレベルのログを有効にしたりするのに役立ちます。変更を手動で元に戻すことができます。または、RHOSP クラスターで再デプロイを実行すると、すべてのパラメーターが永続的な設定にリセットされます。

/var/lib/config-data/puppet-generated/[service] にある設定ファイルを使用して、サービスに一時的な変更を加えます。次の例では、nova サービスでデバッグを有効にします。

Heat を使用して、Red Hat OpenStack Platform (RHOSP) サービスのコンテナー化されたサービスに永続的な変更を加えることができます。最初に RHOSP をデプロイしたときに使用した既存のテンプレートを使用するか、新しいテンプレートを作成してデプロイスクリプトに追加します。次の例では、libvirt の秘密鍵のサイズを 4096 に増やしています。

物理サーバーは複雑なファームウェアを使用して、サーバーのハードウェアと軽量な管理カードを有効にして操作します。このカードでは、独自のセキュリティー脆弱性を持つことができ、システムアクセスと中断が可能になります。これに対処するために、ハードウェアベンダーは、オペレーティングシステムの更新とは別にインストールされるファームウェアの更新を発行します。この更新を取得、テスト、および実装する運用セキュリティープロセスが必要になります。ファームウェアの更新では多くの場合で、物理ホストの再起動が効果的に行われるためです。

SSH 経由で接続する全ユーザーにコンソールメッセージを表示するバナーを設定できます。環境ファイルの以下のパラメーターを使用して、/etc/issue にバナーテキストを追加できます。実際の要件に合わせて、このサンプルテキストをカスタマイズすることを検討してください。

resource_registry:
  OS::TripleO::Services::Sshd:
    /usr/share/openstack-tripleo-heat-templates/deployment/sshd/sshd-baremetal-puppet.yaml

parameter_defaults:
  BannerText: |
   ******************************************************************
   * This system is for the use of authorized users only. Usage of  *
   * this system may be monitored and recorded by system personnel. *
   * Anyone using this system expressly consents to such monitoring *
   * and is advised that if such monitoring reveals possible        *
   * evidence of criminal activity, system personnel may provide    *
   * the evidence from such monitoring to law enforcement officials.*
   ******************************************************************

この変更をデプロイメントに適用するには、設定を ssh_banner.yaml という名前のファイルで保存し、以下のように overcloud deploy コマンドに渡します。<full environment> は、元のデプロイメントパラメーターをすべて含める必要があることを示します。以下に例を示します。

    openstack overcloud deploy --templates \
      -e <full environment> -e  ssh_banner.yaml

すべての監査イベントの記録を維持すると、システムベースラインの確立、トラブルシューティングの実行、特定の結果の原因となったイベントシーケンスの分析に役立ちます。監査システムは、システム時刻の変更、Mandatory/Discretionary アクセス制御の変更、ユーザーおよびグループの作成や削除など、多数のタイプのイベントをログに記録できます。

環境ファイルを使用してルールを作成し、director がそれを /etc/audit/audit.rules に挿入します。以下に例を示します。

    resource_registry:
      OS::TripleO::Services::AuditD: /usr/share/openstack-tripleo-heat-templates/deployment/auditd/auditd-baremetal-puppet.yaml
    parameter_defaults:
      AuditdRules:
        'Record Events that Modify User/Group Information':
          content: '-w /etc/group -p wa -k audit_rules_usergroup_modification'
          order  : 1
        'Collects System Administrator Actions':
          content: '-w /etc/sudoers -p wa -k actions'
          order  : 2
        'Record Events that Modify the Systems Mandatory Access Controls':
          content: '-w /etc/selinux/ -p wa -k MAC-policy'
          order  : 3

ファイアウォールルールは、デプロイメント時にオーバークラウドノードに自動的に適用され、OpenStack の運用に必要なポートのみを公開することを目的としています。必要に応じて、追加のファイアウォールルールを指定できます。たとえば、Zabbix モニタリングシステムのルールを追加するには、以下のようにします。

parameter_defaults:
  ControllerExtraConfig:
    ExtraFirewallRules:
      '301 allow zabbix':
      dport: 10050
      proto: tcp
      source: 10.0.0.8

アクセスを制限するルールを追加することもできます。ルールの定義時に使用される数字は、ルールの優先順位を決定します。たとえば、RabbitMQ のルール番号は、デフォルトでは 109 です。これを抑制するには、小さい数字を使用するように切り替えます。

parameter_defaults:
  ControllerParameters
    ExtraFirewallRules:
      '098 allow rabbit from internalapi network':
        dport: [4369,5672,25672]
        proto: tcp
        source: 10.0.0.0/24
      '099 drop other rabbit access:
        dport: [4369,5672,25672]
        proto: tcp
        action: drop

この例では、098 と 099 は、RabbitMQ のルール番号 109 よりも小さい任意に選んだ番号です。ルールの番号を確認するには、適切なノードで iptables ルールを検査できます。RabbitMQ の場合は、コントローラーをチェックします。

iptables-save
[...]
-A INPUT -p tcp -m multiport --dports 4369,5672,25672 -m comment --comment "109 rabbitmq" -m state --state NEW -j ACCEPT

または、puppet 定義からポート要件を抽出することもできます。たとえば、RabbitMQ のルールは puppet/services/rabbitmq.yaml に保存されます。

    ExtraFirewallRules:
      '109 rabbitmq':
        dport:
          - 4369
          - 5672
          - 25672

ルールには、以下のパラメーターを設定できます。

AIDE (Advanced Intrusion Detection Environment) は、ファイルとディレクトリーの整合性チェッカーです。これは、承認されていないファイルの改ざんまたは変更のインシデントを検出するために使用されます。たとえば、AIDE は、システムパスワードファイルが変更された場合に警告を出すことができます。

AIDE は、システムファイルを分析し、ファイルハッシュの整合性データベースをまとめることで機能します。次に、データベースは、ファイルとディレクトリーの整合性を検証し、変更を検出する際の比較ポイントとなります。

director には AIDE サービスが含まれており、AIDE 設定にエントリーを追加でき、AIDE サービスはこれを使用して整合性データベースを作成できます。以下に例を示します。

  resource_registry:
    OS::TripleO::Services::Aide:
      /usr/share/openstack-tripleo-heat-templates/deployment/aide/aide-baremetal-ansible.yaml

  parameter_defaults:
    AideRules:
      'TripleORules':
        content: 'TripleORules = p+sha256'
        order: 1
      'etc':
        content: '/etc/ TripleORules'
        order: 2
      'boot':
        content: '/boot/ TripleORules'
        order: 3
      'sbin':
        content: '/sbin/ TripleORules'
        order: 4
      'var':
        content: '/var/ TripleORules'
        order: 5
      'not var/log':
        content: '!/var/log.*'
        order: 6
      'not var/spool':
        content: '!/var/spool.*'
        order: 7
      'not nova instances':
        content: '!/var/lib/nova/instances.*'
        order: 8

AIDE の設定ファイルで利用可能な属性の完全リストは、AIDE MAN ページ (https://aide.github.io/) を参照してください。

以下の手順を実行して、変更をデプロイメントに適用します。

    MyAlias = p+i+n+u+g+s+b+m+c+sha512

SecureTTY を使用すると、コンソールデバイス (tty) に対する root アクセスを無効にできます。この動作は、/etc/securetty ファイルのエントリーで管理されます。以下に例を示します。

  resource_registry:
    OS::TripleO::Services::Securetty: ../puppet/services/securetty.yaml

  parameter_defaults:
    TtyValues:
      - console
      - tty1
      - tty2
      - tty3
      - tty4
      - tty5
      - tty6

詳細な監査プロセスは、OpenStack デプロイメントの現在の状態を確認するのに役立ちます。これは、セキュリティーモデルにおけるそのロールにより、特に keystone で重要です。

Red Hat OpenStack Platform では、Identity およびトークン操作の CADF イベントを生成する keystone サービスにより、監査イベントのデータ形式として Cloud Auditing Data Federation (CADF) が採用されています。KeystoneNotificationFormat を使用して、keystone の CADF 監査を有効にできます。

  parameter_defaults:
    KeystoneNotificationFormat: cadf

新規システムユーザー (keystone 以外) のパスワード要件を強化するために、以下のこれらのパラメーターの例に従って、director はエントリーを /etc/login.defs に追加できます。

  resource_registry:
    OS::TripleO::Services::LoginDefs: ../puppet/services/login-defs.yaml

  parameter_defaults:
    PasswordMaxDays: 60
    PasswordMinDays: 1
    PasswordMinLen: 5
    PasswordWarnAge: 7
    FailDelay: 4

DEBUG パラメーターのデフォルト値は False です。実稼働環境では、デフォルト値を保持してください。この設定は、調査中のみ変更してください。DEBUG パラメーターの値を True に変更すると、Django は Web サーバーの状態に関する機密情報を含むスタックトレースをブラウザーユーザーに出力できます。

DEBUG パラメーターの値が True の場合は、ALLOWED_HOSTS 設定も無効になります。ALLOWED_HOSTS の設定の詳細は、ALLOWED_HOSTS の設定 を参照してください。

Dashboard サービス (horizon) は、任意のレベルの共有ドメインではなく、2 次レベルのドメインにデプロイすることを推奨します。それぞれの例を以下に示します。

Dashboard サービスを専用の 2 次レベルのドメインにデプロイすると、ブラウザーの same-origin ポリシーに基づいて、Cookie とセキュリティートークンが他のドメインから分離されます。サブドメインにデプロイされた場合、ダッシュボードサービスのセキュリティーは、同じ 2 次レベルのドメインにデプロイされた最も安全性の低いアプリケーションと同等になります。

クッキーでサポートされるセッションストアを回避し、HTTP Strict Transport Security (HSTS) (このガイドで説明されている) を設定することにより、このリスクをさらに軽減できます。

Horizon は python Django ウェブフレームワークでビルドされており、誤解を招く HTTP Host ヘッダーに関連するセキュリティ脅威からの保護が必要です。この保護を適用するには、OpenStack ダッシュボードによって提供される FQDN を使用するように ALLOWED_HOSTS を設定します。

ALLOWED_HOSTS 設定を設定すると、このリストの値と一致しない Host ヘッダーを持つ HTTP 要求は拒否され、エラーが発生します。

OpenStack ダッシュボードは、ほとんどのフィールドで Unicode 文字セット全体を受け入れます。悪意のある攻撃者は、この拡張性を利用して、クロスサイトスクリプティング (XSS) の脆弱性をテストしようとする可能性があります。OpenStack Dashboard サービス (horizon) には、XSS の脆弱性を強化するツールがあります。カスタムダッシュボードでこれらのツールを正しく使用することが重要です。カスタムダッシュボードに対して監査を実行する場合は、次の点に注意してください。

複数の JavaScript インスタンスを使用する Dashboard は、@csrf_exempt デコレーターの不適切な使用など、脆弱性について監査する必要があります。CORS (Cross Origin Resource Sharing) の制限を下げる前に、推奨されるセキュリティー設定に従っていないダッシュボードを評価してください。各応答で制限付き CORS ヘッダーを送信するように Web サーバーを設定します。ダッシュボードのドメインとプロトコルのみを許可します (例: Access-Control-Allow-Origin: https://example.com/)。ワイルドカードオリジンを許可しないでください。

DISALLOW_IFRAME_EMBED 設定は、Dashboard が iframe 内に埋め込まれるのを防ぎます。従来のブラウザーは、クロスフレームスクリプティング (XFS) に対して脆弱性があります。したがって、このオプションを使用すると、iframes を要求しないデプロイメントにさらにセキュリティー強化機能が追加されます。この設定は、デフォルトで True に設定されていますが、必要な場合は環境ファイルを使用して無効にできます。

    parameter_defaults:
      ControllerExtraConfig:
        horizon::disallow_iframe_embed: false

HTTPS を使用して Dashboard トラフィックを暗号化することが推奨されます。これは、認識されている認証局 (CA) からの有効な信頼される証明書を使用するように設定することで実行できます。プライベート組織が発行した証明書は、信頼の root がすべてのユーザーブラウザーで事前インストールされている場合にのみ適切になります。

完全修飾 HTTPS URL にリダイレクトするように、Dashboard ドメインへの HTTP 要求を設定します。

詳細は、7章オーバークラウドのパブリックエンドポイントでの SSL/TLS の有効化 を参照してください。

HTTP Strict Transport Security(HSTS) は、最初にセキュアな接続を行った後に、ブラウザーが後続の非セキュアな接続を確立できないようにします。パブリックまたは信頼できないゾーンに HTTP サービスをデプロイした場合、HSTS が特に重要になります。

director ベースのデプロイメントの場合、この設定は /usr/share/openstack-tripleo-heat-templates/deployment/horizon/horizon-container-puppet.yaml ファイルでデフォルトで有効になっています。

horizon::enable_secure_proxy_ssl_header: true

OpenStack API 要求から直接生成される動的コンテンツをレンダリングするため、Dashboard でフロントエンドキャッシュツールを使用することは推奨されません。そのため、varnish などのフロントエンドキャッシュレイヤーにより正しいコンテンツが表示されなくなります。Dashboard は Django を使用します。これは Web サービスから直接提供される静的メディアに対応し、Web ホストのキャッシュの利点をすでに活用します。

director ベースのデプロイメントの場合、horizon のデフォルトのセッションバックエンドは django.contrib.sessions.backends.cache で、memcached と組み合わされます。パフォーマンス上の理由から、このアプローチはローカルメモリーキャッシュに対して推奨されます。高可用性や負荷分散のインストールの場合により安全であり、単一キャッシュとして扱いながら複数のサーバーでキャッシュを共有することができます。

これらの設定は、director の horizon.yaml ファイルで確認することができます。

          horizon::cache_backend: django.core.cache.backends.memcached.MemcachedCache
          horizon::django_session_engine: 'django.contrib.sessions.backends.cache'

Dashboard は、一部のセキュリティー機能について共有の SECRET_KEY 設定に依存します。秘密鍵は、少なくとも 64 文字の長さで無作為に生成される文字列である必要があります。これは、すべてのアクティブな Dashboard インスタンスで共有する必要があります。この鍵を危険にさらすと、リモートの攻撃者は任意コードを実行できる可能性があります。このキーをローテーションすると、既存のユーザーセッションおよびキャッシュが無効になります。このキーをパブリックリポジトリーにコミットしないでください。

director のデプロイメントでは、この設定は HorizonSecret の値として管理されます。

Dashboard セッションクッキーは、JavaScript などのブラウザーテクノロジーによる対話のために開くことができます。TLS everywhere を使用した director デプロイメントの場合、HorizonSecureCookies 設定を使用してこの動作を強化することができます。

OpenStack Dashboard (horizon) は、パスワード検証チェックを使用してパスワードの複雑さを強制的に適用することができます。

    parameter_defaults:
      HorizonPasswordValidator: '^.{8,18}$'
      HorizonPasswordValidatorHelp: 'Password must be between 8 and 18 characters.'

    openstack overcloud deploy --templates \
      -e <full environment> -e  horizon_password.yaml

以下の設定は、デフォルトで True に設定されていますが、必要な場合は環境ファイルを使用して無効にできます。

    parameter_defaults:
      ControllerExtraConfig:
        horizon::enforce_password_check: false

disable_password_reveal パラメーターはデフォルトで True に設定されていますが、必要に応じて環境ファイルを使用して無効にすることができます。パスワード表示ボタンは、ダッシュボードのユーザーが入力するパスワードを表示できるようにします。

parameter_defaults:
  ControllerExtraConfig:
    horizon::disable_password_reveal: false

HIPAA、PCI-DSS、および米国政府などの規制では、ユーザーログオンバナーを表示する必要があります。Red Hat OpenStack Platform (RHOSP) Dashboard (horizon) では、horizon コンテナー内に保管されるデフォルトのテーマ (RCUE) が使用されます。

カスタムの Dashboard コンテナーでは、/usr/share/openstack-dashboard/openstack_dashboard/themes/rcue/templates/auth/login.html ファイルを手動で編集して、ログオンバナーを作成できます。

上の例では、次のようなダッシュボードが作成されます。

オプションとして、ファイルのアップロードのサイズを制限するように Dashboard を設定できます。この設定は、さまざまなセキュリティー強化ポリシーで必要になる場合があります。

LimitRequestBody: この値 (バイト単位) は、Dashboard を使用して転送できるファイル (イメージや他の大きなファイルなど) の最大サイズを制限します。

たとえば、この設定では、各アップロードファイルが最大 10 GB (10737418240) に制限されます。実際のデプロイメントに合わせて、この値を修正する必要があります。

OpenStack Networking は、ユーザーがネットワークリソースのセルフサービス設定を提供します。クラウドアーキテクトとオペレーターは、ユーザーが利用可能なネットワークリソースを作成、更新、破棄できる設計のユースケースを評価することが重要です。

OpenStack Networking 内のポリシーエンジンと設定ファイル (policy.json) は、プロジェクトネットワークのメソッドおよびオブジェクトに対するユーザーの詳細な認可を提供する方法を提供します。OpenStack Networking ポリシーの定義は、ネットワークの可用性、ネットワークセキュリティー、および OpenStack セキュリティー全体に影響します。クラウドアーキテクトとオペレーターは、ネットワークリソースの管理に対するユーザーおよびプロジェクトアクセスに対して、ポリシーを慎重に評価する必要があります。

OpenStack が複数の外部アクセスポイントを提供する場合は、複数の仮想 NIC を複数の外部アクセスポイントにアタッチするプロジェクトの機能を制限することが重要です。よりこれらのセキュリティーゾーンがブリッジされ、セキュリティーへの不正アクセスの原因となる可能性があります。Compute が提供するホスト集約関数を使用するか、プロジェクトインスタンスを異なる仮想ネットワーク設定を持つ複数のプロジェクトに分割することで、このリスクを軽減することができます。ホストアグリゲートの詳細は、Creating and managing host aggregates を参照してください。

セキュリティーグループとは、セキュリティーグループルールのコレクションです。セキュリティーグループとそれらのグループにより、管理者およびプロジェクトがトラフィックの種別を指定することができ、かつ方向 (ingress/egress) が仮想インターフェイスポートを通過できる方向 (ingress/egress) を指定することができます。OpenStack Networking で仮想インターフェイスのポートが作成されると、セキュリティーグループが関連付けられます。デプロイメントごとに動作を変更するには、デフォルトのセキュリティーグループにルールを追加できます。

Compute API を使用してセキュリティーグループを変更する場合、更新されたセキュリティーグループはインスタンスのすべての仮想インターフェイスポートに適用されます。これは、neutron にあるように、Compute セキュリティーグループ API がポートベースではなくインスタンスベースであるためです。

OpenStack Networking には、インスタンスの ARP スプーフィングの脅威を緩和するための組み込み機能が含まれています。これは、結果となるリスクに注意を払う場合を除き無効にしないでください。

/var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf で、[keystone_authtoken] セクションの auth_uri の値が https: で始まる Identity API エンドポイントに設定されていることを確認します。

リクエストごとの最大ボディーサイズが定義されていない場合、攻撃者は大きなサイズの任意の OSAPI リクエストを作成します。すると、その結果サービスがクラッシュし、最終的にサービス拒否攻撃につながることになります。最大値を割り当てると、悪意のあるリクエストはすべてブロックされ、引き続きサービスの可用性が確保されます。

cinder.conf の [oslo_middleware] セクションの max_request_body_size が 114688 に設定されているかどうかを確認します。

暗号化されていないボリュームデータにより、攻撃者が多数の仮想マシンのデータを読み取ることができるため、ボリュームホスティングプラットフォームは特に攻撃者にとってハイバリューターゲットとなります。さらに、物理ストレージメディアは、盗まれたり、再マウントされたりする可能性ががあり、別のマシンからアクセスされることもあり得ます。ボリュームのデータとボリュームのバックアップを暗号化すると、これらのリスクを軽減し、ボリュームをホストしているプラットフォームに厚い防御を提供することができます。Block Storage (cinder) は、ディスクに書き込まれる前にボリュームデータを暗号化できるため、ボリュームの暗号化を有効にし、秘密鍵ストレージに Barbican を使用することを検討してください。

ブロックストレージデバイスを消去する方法は複数あります。従来の方法として、lvm_type を thin に設定し、続いて volume_clear パラメーターを使用します。または、ボリュームの暗号化機能があれば、ボリュームの暗号化キーが削除される場合にボリュームのワイプは必要ありません。

volume_clear パラメーターは、zero または shred のいずれかを引数として受け入れることができます。zero は、デバイスにゼロのパスを 1 つ書き込みます。shred 操作は、事前に決定したビットパターンの 3 つを書き込みます。

Manila は keystone に登録されており、manila endpoints コマンドを使用して API を特定することができます。以下に例を示します。

 $ manila endpoints
 +-------------+-----------------------------------------+
 | manila      | Value                                   |
 +-------------+-----------------------------------------+
 | adminURL    | http://172.18.198.55:8786/v1/20787a7b...|
 | region      | RegionOne                               |
 | publicURL   | http://172.18.198.55:8786/v1/20787a7b...|
 | internalURL | http://172.18.198.55:8786/v1/20787a7b...|
 | id          | 82cc5535aa444632b64585f138cb9b61        |
 +-------------+-----------------------------------------+

 +-------------+-----------------------------------------+
 | manilav2    | Value                                   |
 +-------------+-----------------------------------------+
 | adminURL    | http://172.18.198.55:8786/v2/20787a7b...|
 | region      | RegionOne                               |
 | publicURL   | http://172.18.198.55:8786/v2/20787a7b...|
 | internalURL | http://172.18.198.55:8786/v2/20787a7b...|
 | id          | 2e8591bfcac4405fa7e5dc3fd61a2b85        |
 +-------------+-----------------------------------------+

デフォルトでは、manila API サービスは、tcp6 のポート 8786 でのみリッスンします。これは、IPv4 と IPv6 の両方をサポートします。

manila は複数の設定ファイルを使用します。これらは /var/lib/config-data/puppet-generated/manila/ に保存されます。

 api-paste.ini
 manila.conf
 policy.json
 rootwrap.conf
 rootwrap.d

 ./rootwrap.d:
 share.filters

manila を root 以外のサービスアカウントで実行するように設定し、システム管理者のみが変更できるようにファイルのパーミッションを変更することを推奨します。manila では、管理者のみが設定ファイルに書き込みを行うことができ、サービスは manila グループのグループメンバーシップを介して読み取りのみを行うことを想定します。サービスアカウントパスワードが含まれるため、他のユーザーがこれらのファイルを読み取り可能であってはいけません。

manila の共有ドライバーは、共有操作を管理するためにバックエンドに設定可能な Python クラスです。これらの一部はベンダー固有のものになります。バックエンドは、manila-share サービスのインスタンスです。manila は、多くの異なるストレージシステム用の共有ドライバーを持ち、商用ベンダーおよびオープンソースソリューションの両方をサポートします。各共有ドライバーは、1 つまたは複数のバックエンドモード (共有用サーバー および 共有用サーバーなし) をサポートします。管理者は、driver_handles_share_servers を使用して manila.conf でモードを指定して選択します。

共有サーバーは、共有ファイルシステムをエクスポートする論理 Network Attached Storage (NAS) サーバーです。今日のバックエンドストレージシステムは高機能で、異なる OpenStack プロジェクト間でデータパスとネットワークパスを分離することができます。

manila 共有ドライバーによってプロビジョニングされる共有サーバーは、作成するプロジェクトユーザーに属する分離ネットワーク上に作成されます。共有用サーバー モードは、ネットワークプロバイダーに応じて、フラットネットワークまたはセグメント化されたネットワークのいずれかで設定できます。

異なるモードのそれぞれのドライバーが、同じハードウェアを使用することができます。選択したモードによっては、設定ファイルでより多くの設定情報を提供する必要がある場合があります。

各共有ドライバーは、少なくとも 1 つの利用可能なドライバーモードをサポートします。

共有用サーバーなしモード: このモードでは、ドライバーは共有サーバーを設定しないため、新しいネットワークインターフェイスを設定する必要はありません。ドライバーが管理するストレージコントローラーには必要なネットワークインターフェイスがすべて含まれていることを前提とします。ドライバーは、以前共有サーバーを作成せずに直接共有を作成します。このモードで稼働するドライバーを使用してファイル共有を作成するには、manila では、いずれかのプライベート共有ネットワークを作成する必要はありません。

共有用サーバーなし モードでは、共有ドライバーは共有サーバーのライフサイクルを処理しません。管理者は、プロジェクトの分離を提供するのに必要なストレージ、ネットワーク、およびその他のホスト側の設定を処理することが想定されます。このモードでは、管理者はファイル共有をエクスポートするホストとしてストレージを設定できます。OpenStack クラウド内のすべてのプロジェクトは、共通のネットワークパイプを共有します。分離がない場合、セキュリティーおよび QoS (Quality of Service) に影響を及ぼす可能性があります。共有用サーバーを処理しない共有ドライバーを使用する場合には、クラウドユーザーは、ファイルシステムの最上位ディレクトリー上のツリーウォークにより、信頼できないユーザーが自分のファイル共有にアクセスできないことを確認することはできません。パブリッククラウドでは、1 つのクライアントですべてのネットワーク帯域幅が使用される可能性があるため、管理者はそうならないように注意する必要があります。ネットワークのバランシングは、必ずしも OpenStack ツールだけを使用しなければならない訳ではなく、どの方法ででも実行できます。

共有用サーバーモード: このモードでは、ドライバーは共有用サーバーを作成して、既存の OpenStack ネットワークにプラグインすることができます。manila は、新規共有用サーバーが必要であるかどうかを判別し、共有ドライバーが必須共有用サーバーを作成するのに必要なすべてのネットワーク情報を提供します。

共有用サーバーを処理するドライバーモードでファイル共有を作成する場合、ユーザーはファイル共有をエクスポートすることを期待する共有ネットワークを提供する必要があります。manila は、このネットワークを使用して、このネットワーク上の共有用サーバーのネットワークポートを作成します。

共有用サーバー および 共有用サーバーなし バックエンドモードの両方で、セキュリティーサービス を設定することができます。ただし、共有用サーバーなし バックエンドモードでは、管理者はホストで必要な認証サービスを手動で設定する必要があります。共有用サーバー モードでは、manila は、生成する共有用サーバーでユーザーが識別するセキュリティーサービスを設定することができます。

manila は、flat、GRE、VLAN、VXLAN など、さまざまなネットワーク種別と統合できます。

共有用サーバー バックエンドモードでは、共有ドライバーにより、ファイル共有ネットワークごとに共有用サーバーを作成および管理します。このモードは、2 つのバリエーションに分割できます。

ユーザーは、OpenStack Networking (neutron) サービスからのネットワークおよびサブネットを使用して、ファイル共有ネットワークを作成することができます。管理者が StandAloneNetworkPlugin の使用を決定した場合、ユーザーはネットワーク情報を提供する必要がありません。管理者が設定ファイルでこれを事前設定するためです。

ファイル共有ネットワークが作成されると、manila はネットワークプロバイダーによって決定されたネットワーク情報 (ネットワーク種別、セグメンテーション ID (ネットワークがセグメンテーションを使用する場合)、およびネットワークの割り当て元の IP ブロック (CIDR 表記)) を取得します。

ユーザーは、AD、LDAP ドメイン、Kerberos レルムなどのセキュリティー要件を指定するセキュリティーサービスを作成できます。manila は、セキュリティーサービスで呼び出されるホストが、共有用サーバーが作成されるサブネットから到達可能であることを前提としています。これにより、このモードが使用されるケースが制限されます。

manila は、ネットワーク認証プロトコルと統合することで、ファイル共有へのアクセスを制限できます。各プロジェクトには、クラウドの keystone 認証ドメインとは別に機能する独自の認証ドメインを持つことができます。このプロジェクトドメインを使用して、manila を含む OpenStack クラウド内で実行されるアプリケーションに承認 (AuthZ) サービスを提供することができます。利用可能な認証プロトコルには、LDAP、Kerberos、および Microsoft Active Directory 認証サービスが含まれます。

ファイル共有を作成してエクスポート場所を取得した後、ユーザーにはファイル共有をマウントし、ファイルを操作するパーミッションがありません。ユーザーは、新規共有へのアクセスを明示的に取得する必要があります。

クライアントの認証および承認 (authN/authZ) は、セキュリティーサービスと共に実行できます。LDAP、Kerberos、または Microsoft Active Directory が共有ドライバーおよびバックエンドでサポートされている場合、manila はこれらを使用できます。

セキュリティーサービス は、Active Directory ドメインや Kerberos ドメインなど、特定の共有ファイルシステムプロトコルのセキュリティーゾーンを定義するオプションのセットを抽象化する manila エンティティーです。セキュリティーサービスには、manila が指定のドメインに参加させるサーバーを作成するために必要な全情報が含まれます。

ユーザーは、API を使用してセキュリティーサービスの作成、更新、表示、および削除を行うことができます。セキュリティーサービスは、以下の前提条件に基づいて設計されています。

セキュリティーサービスの作成時に、以下のいずれかの認証サービスを選択できます。

manila では、以下のオプションを使用してセキュリティーサービスを設定することができます。

既存のセキュリティーサービスエンティティーには、ファイル共有ネットワークエンティティーを関連付けることができます。このエンティティーは、manila に、ファイル共有グループのセキュリティーおよびネットワーク設定を通知します。指定したファイル共有ネットワークに対するセキュリティーサービスのリストを確認し、ファイル共有ネットワークから関連付けを解除することもできます。

ファイル共有の所有者として、管理者およびユーザーは、IP アドレス、ユーザー、グループ、または TLS 証明書を使用した認証でアクセスルールを作成することにより、ファイル共有へのアクセスを管理できます。認証方法は、設定して使用する共有ドライバーやセキュリティーサービスによって異なります。その後、特定の認証サービスを使用するようにバックエンドを設定することができます。これにより、manila および keystone を使用せずにクライアントと機能することができます。

あるドライバーが特定の認証サービスをサポートするからと言って、任意の共有ファイルシステムプロトコルで設定できるという訳ではありません。サポート対象の共有ファイルシステムプロトコルは、NFS、CEPHFS、CIFS、GlusterFS、および HDFS です。特定のドライバーおよびそのセキュリティーサービスの設定に関する情報は、ドライバーベンダーのドキュメントを参照してください。

一部のドライバーは、セキュリティーサービスをサポートしますが、上記のセキュリティーサービスをサポートしないドライバーもあります。たとえば、NFS または CIFS 共有ファイルシステムプロトコルを使用する汎用ドライバーは、IP アドレスによる認証方法のみをサポートします。

実稼働環境用の manila デプロイメントの推奨設定は、CIFS 共有プロトコルを使用してファイル共有を作成し、それを Microsoft Active Directory ディレクトリーサービスに追加することです。この設定では、集中データベースと、Kerberos および LDAP アプローチを統合するサービスが提供されます。

ユーザーは、作成するファイル共有にアクセスできる特定のクライアントを指定できます。keystone サービスにより、個別ユーザーが作成したファイル共有は、作成したユーザーおよび同じプロジェクト内のユーザーだけに表示されます。Manila により、ユーザーは "パブリック" に表示されるファイル共有を作成することができます。所有者がアクセス権を付与した場合、これらのファイル共有は、他の OpenStack プロジェクトに属するユーザーのダッシュボードに表示されます。ネットワーク上でアクセス可能な場合、これらの共有をマウントできる場合もあります。

ファイル共有の作成時に、キー --public を使用して、他のプロジェクトに対してファイル共有をパブリックにし、ファイル共有のリストにその共有を表示し、詳細情報を表示します。

policy.json ファイルに従って、ファイル共有の所有者として、管理者およびユーザーは、アクセスルールを作成することにより、ファイル共有へのアクセスを管理できます。manila access-allow、manila access-deny、および manila access-list コマンドを使用すると、指定されたファイル共有へのアクセスを許可、拒否、およびリスト表示することができます。

ファイル共有が作成されたままの状態では、それに関連付けられたデフォルトのアクセスルールとマウントパーミッションはありません。これは、使用中のエクスポートプロトコルのマウント設定で確認できます。たとえば、NFS コマンド exportfs またはストレージの /etc/exports ファイルがあり、各リモートファイル共有を制御し、アクセスできるホストを定義します。誰もファイル共有をマウントできない場合、これは空です。リモート CIFS サーバーでは、設定を表示する net conf list コマンドがあります。hosts deny パラメーターは、共有ドライバーにより 0.0.0.0/0 に設定する必要があります。これは、いずれのホストも、ファイル共有のマウントを拒されることを意味します。

manila を使用して、サポートされるファイル共有へのアクセスレベルのいずれかを指定して、ファイル共有へのアクセスを許可または拒否できます。

サポートされる認証方法のいずれかも指定する必要があります。

アクセスルール (ACL) がファイル共有に対して正しく設定されていることを確認するには、そのパーミッションをリスト表示できます。

共有種別は、管理者の定義する サービスの種別 で、プロジェクトに表示される説明および 追加仕様 と呼ばれるプロジェクトに表示されないキー/値ペアのリストで構成されます。manila-scheduler は追加仕様を使用してスケジューリングの決定を行い、ドライバーはファイル共有の作成を制御します。

管理者は共有種別の作成や削除が可能で、さらに、共有種別に manila 内での意味を持たせる追加仕様を管理することもできます。プロジェクトでは共有種別をリスト表示でき、それらを使用して新規ファイル共有を作成することができます。共有種別は public および private として作成できます。これは共有種別の可視性のレベルで、他のプロジェクトがリストに共有種別を表示し、新規ファイル共有を作成するのに使用できるかどうかを定義するものです。

デフォルトでは、共有種別は public として作成されます。共有種別を作成する時に --is_public パラメーターを使用して False に設定し、共有種別をプライベートに設定します。これにより、他のプロジェクトがリストに共有種別を表示したり、それを使用して新たなファイル共有を作成するのを防ぐことができます。一方、public の共有種別は、クラウド内のすべてのプロジェクトで利用できます。

manila により、管理者はプロジェクトの private の共有種別へのアクセスを許可または拒否することができます。指定したプライベート共有種別のアクセスに関する情報を取得することもできます。

たとえば、admin プロジェクトの管理者ユーザーは、my_type という名前のプライベート共有種別を作成し、これをリストで確認できます。以下のコンソールの例では、ログインとログアウトが省略され、現在ログインしているユーザーを示す環境変数が提供されます。

 $ env | grep OS_
 ...
 OS_USERNAME=admin
 OS_TENANT_NAME=admin
 ...
 $ manila type-list --all
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+
 | ID | Name   | Visibility| is_default| required_extra_specs              | optional_extra_specs  |
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+
 | 4..| my_type| private   | -         | driver_handles_share_servers:False| snapshot_support:True |
 | 5..| default| public    | YES       | driver_handles_share_servers:True | snapshot_support:True |
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+

demo プロジェクトの demo ユーザーは種別をリスト表示できますが、my_type という名前のプライベート共有種別は表示されません。

 $ env | grep OS_
 ...
 OS_USERNAME=demo
 OS_TENANT_NAME=demo
 ...
 $ manila type-list --all
 +----+--------+-----------+-----------+----------------------------------+----------------------+
 | ID | Name   | Visibility| is_default| required_extra_specs             | optional_extra_specs |
 +----+--------+-----------+-----------+----------------------------------+----------------------+
 | 5..| default| public    | YES       | driver_handles_share_servers:True| snapshot_support:True|
 +----+--------+-----------+-----------+----------------------------------+----------------------+

管理者は、プロジェクト ID が df29a37db5ae48d19b349fe947fada46 の demo プロジェクトのプライベート共有種別へのアクセスを付与できます。

 $ env | grep OS_
 ...
 OS_USERNAME=admin
 OS_TENANT_NAME=admin
 ...
 $ openstack project list
 +----------------------------------+--------------------+
 | ID                               | Name               |
 +----------------------------------+--------------------+
 | ...                              | ...                |
 | df29a37db5ae48d19b349fe947fada46 | demo               |
 +----------------------------------+--------------------+
 $ manila type-access-add my_type df29a37db5ae48d19b349fe947fada46

その結果、demo プロジェクトのユーザーは、プライベートの共有種別を表示し、ファイル共有の作成で使用できます。

 $ env | grep OS_
 ...
 OS_USERNAME=demo
 OS_TENANT_NAME=demo
 ...
 $ manila type-list --all
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+
 | ID | Name   | Visibility| is_default| required_extra_specs              | optional_extra_specs  |
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+
 | 4..| my_type| private   | -         | driver_handles_share_servers:False| snapshot_support:True |
 | 5..| default| public    | YES       | driver_handles_share_servers:True | snapshot_support:True |
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+

指定されたプロジェクトのアクセスを拒否するには、manila type-access-remove <share_type> <project_id> を使用します。

Shared File Systems サービス API は、ロールベースのアクセス制御ポリシーで制御されます。これらのポリシーは、どのユーザーが特定の API にどのようにアクセスできるかを決定し、サービスの policy.json ファイルで定義されます。

manila への API 呼び出しを行うたびに、ポリシーエンジンは適切なポリシー定義を使用して、呼び出しを受け入れることができるかどうかを判断します。ポリシールールは、API 呼び出しを許可する状況を決定します。ルールが空の文字列 "" の場合、/var/lib/config-data/puppet-generated/manila/etc/manila/policy.json ファイルは常にアクションが許可されるルールを持ちます。ユーザーロールまたはルールに基づくルール、ブール値式のルール。以下は、manila の policy.json ファイルのスニペットです。OpenStack リリース間で変更することが想定されます。

   {
       "context_is_admin": "role:admin",
       "admin_or_owner": "is_admin:True or project_id:%(project_id)s",
       "default": "rule:admin_or_owner",
       "share_extension:quotas:show": "",
       "share_extension:quotas:update": "rule:admin_api",
       "share_extension:quotas:delete": "rule:admin_api",
       "share_extension:quota_classes": "",
   }

ユーザーは、ポリシーで参照するグループおよびロールに割り当てられる必要があります。これは、ユーザー管理コマンドが使用されている場合にサービスによって自動的に行われます。

swift のセキュリティー強化は、ネットワークコンポーネントのセキュリティー保護から始まります。詳細は、ネットワークの章を参照してください。

高可用性を確保する場合、rsync プロトコルがストレージサービスノード間でデータをレプリケートするために使用されます。さらに、プロキシーサービスは、クライアントエンドポイントとクラウド環境間でデータをリレーする際にストレージサービスと通信します。

これには、プロキシーノードにデュアルインターフェイス (物理または仮想) が必要です。

以下の図は、Object Storage ネットワークアーキテクチャーと管理ノード (OSAM) を使用する、可能なネットワークアーキテクチャーの 1 つを示しています。

root (UID 0) 以外のサービスアカウントで実行するように swift を設定することを推奨します。1 つの推奨事項として、director によりデプロイされるように、ユーザー名を swift に、プライマリーグループを swift にすることです。Object Storage サービスには、proxy-server、container-server、account-server が含まれます。

/var/lib/config-data/puppet-generated/swift/etc/swift/ ディレクトリーには、リングトポロジーと環境設定に関する情報が含まれます。以下のパーミッションが推奨されます。

chown -R root:swift /var/lib/config-data/puppet-generated/swift/etc/swift/*
find /var/lib/config-data/puppet-generated/swift/etc/swift/ -type f -exec chmod 640 {} \;
find /var/lib/config-data/puppet-generated/swift/etc/swift/ -type d -exec chmod 750 {} \;

この制限は、root だけに設定ファイルの変更を許可しますが、swift グループのメンバーシップにより、サービスにそれらの読み取りを許可します。

以下は、さまざまなストレージサービスのデフォルトリスニングポートです。

swift アカウントは、ユーザーアカウントまたは認証情報ではありません。定義は以下のとおりです。

各レベルでは、ユーザーアクセスを制御する ACL があり、ACL は使用中の認証システムを基に解釈されます。最も一般的な認証プロバイダーの種別は Identity サービス (keystone) です。カスタム認証プロバイダーも利用できます。

プロキシーノードには、少なくとも 2 つのインターフェイス (物理または仮想) が必要です。1 つはパブリック、および 1 つはプライベート。パブリックインターフェイスを保護するには、ファイアウォールまたはサービスのバインディングを使用できます。パブリック向けサービスは、エンドポイントのクライアント要求を処理し、認証を行い、適切なアクションを実行する HTTP Web サーバーです。プライベートインターフェイスにはリスニングサービスは必要ありませんが、代わりにプライベートストレージネットワーク上のストレージノードへの発信接続を確立するために使用されます。

director は、root 以外のユーザー (UID 0 以外) で実行するように Web サービスを設定します。1024 より大きいポート番号を使用すると、Web コンテナーのいずれの部分も root として実行されなくなります。通常、HTTP REST API を使用する (そして自動認証を実行する) クライアントは、認証応答から必要な完全な REST API URL を取得します。OpenStack REST API により、クライアントはある URL に対して認証を行い、実際のサービス用に完全に異なる URL を使用するためにリダイレクトできます。たとえば、クライアントは https://identity.cloud.example.org:55443/v1/auth に対して認証を行い、認証キーおよび、https://swift.cloud.example.org:44443/v1/AUTH_8980 のストレージ URL (プロキシーノードまたはロードバランサーの URL) を持つ応答を取得できます。

Apache を使用するオプションが実行できない場合や、パフォーマンス上の理由で TLS 作業をオフロードする場合は、専用のネットワークデバイスのロードバランサーを使用する場合があります。これは、複数のプロキシーノードを使用する場合に冗長性および負荷分散を提供する一般的な方法です。

TLS のオフロードを選択する場合は、ロードバランサーとプロキシーノード間のネットワークリンクがプライベート (V)LAN セグメント上にありるようにします。これにより、ネットワーク上の他のノード (セキュリティー侵害されている可能性がある) による非暗号化トラフィックの盗聴 (スニフィング) を防ぐことができます。このような侵害が発生した場合、攻撃者はエンドポイントクライアントまたはクラウド管理者の認証情報にアクセスし、クラウドデータにアクセスできるようになります。

使用する認証サービスは、エンドポイントクライアントへの応答で異なる URL を設定する方法を決定し、個別のプロキシーノードではなくロードバランサーを使用できるようにします。

Object Storage (swift) は WSGI モデルを使用して、一般的な機能拡張を提供するだけではなく、エンドポイントクライアントの認証にも使用されるミドルウェア機能を提供します。認証プロバイダーは、どのロールおよびユーザー種別が存在するかを定義します。従来のユーザー名およびパスワードの認証情報を使用するものもあれば、API キートークンやクライアント側の x.509 証明書を利用するものもあります。カスタムプロバイダーは、カスタムミドルウェアを使用して統合できます。

オブジェクトストレージには、デフォルトで 2 つの認証ミドルウェアモジュールが含まれています。これらのモジュールのいずれかを、カスタム認証ミドルウェアを開発するためのサンプルコードとして使用できます。

swift は、Barbican を統合して、保管されている (at-rest) オブジェクトを透過的に暗号化/復号化できます。at-rest 暗号化は、in-transit 暗号化とは異なり、ディスクに保管されている間にオブジェクトが暗号化されることを指します。

Swift はこれらの暗号化タスクを透過的に実行し、オブジェクトは swift にアップロードされる際には自動的に暗号化され、ユーザーに提供される際には自動的に復号化されます。この暗号化と復号化は、Barbican に保管されている同じ (対称) キーを使用して処理されます。

すべてのノードの /var/lib/config-data/puppet-generated/swift/etc/swift/swift.conf に、swift_hash_path_prefix 設定および swift_hash_path_suffix 設定があります。これらは、保存されるオブジェクトのハッシュ競合の可能性を低減し、あるユーザーが別のユーザーのデータを上書きするのを防ぐために提供されます。

この値は、最初に暗号的に安全な乱数ジェネレーターで設定し、すべてのノードで一貫性を持たせる必要があります。適切な ACL で保護し、データの喪失を回避するために、バックアップコピーを作成するようにします。

集中ロギングシステムは、侵入者にとって価値のあるターゲットです。侵入に成功すると、イベントの記録を消去または改ざんできるからです。この点を考慮に入れて、モニタリングプラットフォームを強化することが推奨されます。さらに、機能停止またはサービス拒否 (DoS) 攻撃に備えて、フェイルオーバーの計画を作成すると共に、このシステムのバックアップを定期的に作成することを検討してください。

イベントの監視は、環境を保護し、リアルタイムの検出および応答を提供するより予防的な手段です。監視に役立つツールが複数存在します。OpenStack のデプロイメントでは、ハードウェア、OpenStack サービス、およびクラウドリソースの使用状況をモニターする必要があります。

このセクションでは、認識する必要のあるイベントの例を説明します。

Identity サービス内のユーザー、プロジェクト、またはドメインの削除により使用されなくなったインスタンスからのセキュリティーリスクを軽減するには、システム内で通知を生成し、OpenStack コンポーネントに適切にこれらのイベントに応答させます (例: インスタンスの切断、攻撃を受けたボリュームの接続解除、CPU およびストレージリソースの再確保など)。

侵入検知ソフトウェア、ウイルス対策ソフトウェア、およびスウェアウェアの検出や削除ユーティリティーなどのセキュリティー監視は、攻撃または侵入がいつどのように発生したかを示すログを生成することができます。これらのツールは、OpenStack ノードにデプロイすると、保護のレイヤーを提供します。プロジェクトユーザーも、このようなツールをインスタンスで実行する必要があります。

データのプライバシーと分離は、過去数年にクラウド導入に対する主要なバリアとして、一貫して引用されています。クラウド内で誰がデータを所有するのか、クラウドオペレーターが究極的にこのデータの管理者として信頼できるかどうかの懸念が、これまで重大な問題となっていました。

特定の OpenStack サービスは、プロジェクトに属するデータおよびメタデータ、または参考プロジェクト情報にアクセスできます。たとえば、OpenStack クラウドに保存されるプロジェクトデータには、以下の項目が含まれます。

OpenStack クラウドにより保存されるメタデータには、以下の項目が含まれます (このリストがすべてを網羅している訳ではありません)。

オペレーターは、廃棄の前に、組織の管理から外す前に、または再使用のために解放する前に、クラウドシステムメディア (デジタルおよび非デジタル) をサニタイズする必要があります。サニタイズ方法は、その情報の具体的なセキュリティードメインおよび機密性に対し、適切な強度および整合性のレベルを実装する必要があります。

The sanitization process removes information from the media such that the information cannot be retrieved or reconstructed. Sanitization techniques, including clearing, purging, cryptographic erase, and destruction, prevent the disclosure of information to unauthorized individuals when such media is reused or released for disposal.

クラウドオペレーターは、データ破棄およびサニタイズに関する一般的なガイドラインを開発する場合は、以下を考慮してください (NIST の推奨セキュリティー制御に基づく)。

その結果、OpenStack のデプロイメントで以下のプラクティスを対処する必要があります (一例)。

OpenStack のボリューム暗号化機能の使用を強く推奨します。詳細は、下記データの暗号化セクションのボリュームの暗号化で説明されています。この機能が使用される場合、暗号鍵を安全に削除することでデータの破棄が実行されます。エンドユーザーは、ボリュームの作成時にこの機能を選択できますが、管理者はまず 1 度限りのボリューム暗号化機能の設定を実行する必要があることに注意してください。

OpenStack のボリューム暗号化機能が使用されていない場合、他のアプローチは通常有効にすることが困難になります。バックエンドプラグインが使用されている場合は、独立した暗号化方法や標準以外の上書きソリューションある可能性があります。OpenStack Block Storage へのプラグインでは、さまざまな方法でデータを保管します。多くのプラグインはベンダーや技術に固有のものですが、その他はファイルシステム (LVM または ZFS など) に関するより DIY 的なソリューションです。データを安全に破棄する方法は、プラグイン、ベンダー、およびファイルシステムによって異なります。

一部のバックエンド (ZFS など) は、データの公開を防ぐためにコピーオンライトをサポートします。このような場合、書き込まれていないブロックから読み取ると、常にゼロを返します。他のバックエンド (LVM など) はこれをネイティブにサポートしていない可能性があるため、cinder プラグインは、ブロックをユーザーに渡す前に以前に書き込まれたブロックを上書きします。選択したボリュームバックエンドが提供する保証を確認することや、提供されない保証についてどのような修復が利用できるかを確認することが重要です。

Image サービスには削除遅延機能があり、定義された期間イメージの削除を保留します。この動作がセキュリティー上の問題である場合は、この機能を無効にすることを検討してください。glance-api.conf ファイルを編集して delayed_delete オプションを False に設定すると、この機能を無効にすることができます。

Compute にはソフト削除機能があり、定義した期間、削除されるインスタンスをソフト削除状態にすることができます。この期間は、インスタンスを復元することができます。ソフト削除機能を無効にするには、/var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf ファイルを編集し、reclaim_instance_interval オプションを空のままにします。

ベアメタルプロビジョニングインフラストラクチャーの場合、一般的にはベースボード管理コントローラー (BMC)、特に IPMI のセキュリティー強化を検討する必要があります。たとえば、プロビジョニングネットワーク内のこれらのシステムを分離し、デフォルト以外の強力なパスワードを設定し、不要な管理機能を無効にします。詳細は、これらのコンポーネントのセキュリティーの強化に関するベンダーのガイダンスを参照してください。

サーバーをデプロイする場合、攻撃者のサーバーと区別するための信頼できる方法が常にあるとは限りません。この機能は、ある程度ハードウェア/BMC に依存する可能性がありますが、通常は立証可能な手段はサーバーに組み込まれていないようです。

プロジェクトデータがディスクのどこに保存されていても、あるいはネットワークを通じて転送されていても、実装者にはデータを暗号化するためのオプションがあります。たとえば、以下で説明されている OpenStack ボリューム暗号化機能です。これは、プロバイダーに送信する前にユーザーが自分のデータを暗号化する一般的な推奨事項を上回るものです。

プロジェクトの代わりにデータを暗号化することの重要性は、攻撃者がプロジェクトデータにアクセスできるというプロバイダーによって想定されるリスクに非常に関係します。政府、ポリシー、私的な契約、またはパブリッククラウドプロバイダーの私的な契約に関する法的な要件があります。プロジェクトの暗号化ポリシーを選択する前に、リスク評価と法的アドバイスを取得することを検討してください。

インスタンスまたはオブジェクトごとの暗号化が、降順、プロジェクト、ホスト、およびクラウドアグリゲーションごとよりも優先されます。この推奨事項は、実装の複雑性と困難度とは逆です。現時点で、一部のプロジェクトでは、プロジェクトごとの粗い粒度での暗号化を実装することが困難、または不可能な場合があります。実装者は、プロジェクトデータの暗号化に深刻な考慮事項を与えます。

多くの場合、データの暗号化は、単にキーを廃棄することで、プロジェクトやインスタンスごとのデータを確実に破棄する機能に貢献します。このようにすると、信頼できる安全な方法でこれらのキーを破棄することが非常に重要になります。

ユーザーのデータを暗号化する機会が存在します。

プロジェクトデータのプライバシーに関する頻出する懸念に対処するために、OpenStack コミュニティーでは、データの暗号化をより広範囲で行うことに大きな関心が寄せられています。クラウドに保存する前にエンドユーザーがデータを暗号化するのは比較的簡単です。メディアファイルやデータベースアーカイブなどのプロジェクトオブジェクトに関して、実行可能なパスがあります。一部では、クライアント側の暗号化は、今後の使用のためにデータを復号化するために、鍵の提示などのクライアントの連携を必要とする仮想化技術で保持されるデータの暗号化に使用されます。

barbican を使用すると、プロジェクトがデータをシームレスに暗号化し、キー管理でユーザーに負担をかけることなくデータにアクセスすることができます。OpenStack の一部として暗号化およびキー管理サービスを提供することにより、保管データのセキュリティー確保の採用が促進され、データのプライバシーや誤用に関するお客様の懸念に対処するのに役立ちます。

ボリューム暗号化機能は、Key Manager サービス (バービカン) などのキー管理サービスを使用しており、キーの作成とセキュリティー保護された保存を行います。

エントロピーとは、インスタンスで利用可能なランダムデータの質とソースのことです。暗号技術は一般的にランダム性に依存しており、エントロピーのプールから抽出する必要があります。エントロピーの枯渇は、暗号技術に必要なランダム性をサポートするのに十分なエントロピーをインスタンスが得られない場合に起こります。エントロピーの枯渇は、一見すると関係のないものとして現れることがあります。たとえば、インスタンスが SSH キーの生成を待機していることが原因で、起動時間が遅くなる可能性があります。また、エントロピーが枯渇すると、クラウドのユーザーがインスタンス内の質の悪いエントロピーソースを使用することになり、クラウド上で動作するアプリケーションの安全性が低下します。

高品質のエントロピー源をインスタンスに提供するためには、インスタンスをサポートするのに十分な数のハードウェア乱数生成器 (HRNG) がクラウドに必要です。日常的な運用であれば、最新の HRNG は 50 ~ 100 台の Compute ノードをサポートするのに十分なエントロピーを生成することができます。高帯域の HRNG は、より多くのノードを扱うことができます。十分なエントロピーを確保するためには、クラウドのアプリケーション要件を特定する必要があります。

VirtIO RNG は、デフォルトで /dev/urandom をエントロピーソースとして使用する乱数生成器で、起動時にインスタンスでエントロピーが枯渇しないようにします。また、デプロイメント全体でエントロピーを配布する方法を提供するために、HRNG またはエントロピー収集デーモン (EGD) などのツールを使用するように設定することもできます。Virtio RNG デバイスは、インスタンスのデフォルトで有効になっています。インスタンスで Virtio RNG デバイスを無効にするには、インスタンスフレーバーで hw_rng:allowed を False に設定する必要があります。

インスタンスを作成する前に、イメージのインスタンス化のホストを選択する必要があります。この選択は、コンピュートおよびボリューム要求のディスパッチ方法を決定する nova-scheduler により行われます。

FilterScheduler は Compute のデフォルトスケジューラーですが、他のスケジューラーが存在します。この機能は、フィルターヒント と協力して、インスタンスの開始場所を決定します。ホスト選択のこのプロセスにより、管理者はさまざまなセキュリティーおよびコンプライアンス要件を満たすことができます。データの分離が主な懸念である場合は、可能な場合は同じホストにプロジェクトインスタンスを配置することができます。逆に、インスタンスの可用性やフォールトトレランスの理由で、できるだけ異なるホストにインスタンスを配置することができます。

フィルタースケジューラーは、以下の主要なカテゴリーに分類されます。

複数のフィルターを一度に適用できます。たとえば、ServerGroupAffinity フィルターは、特定のホストセットのメンバーにインスタンスが作成されていることを確認し、ServerGroupAntiAffinity フィルターは同じインスタンスが別の特定ホストセットで作成されないことを確認します。これら 2 つのフィルターは通常同時に有効になり、互いに競合しないことに注意してください。特定のプロパティーの値をチェックし、いずれも同時に true にできないためです。

クラウド環境では、ユーザーは事前にインストール済みのイメージまたは自身がアップロードするイメージと連携します。いずれの場合も、使用するイメージが改ざんされていないことを確認できる必要があります。イメージを検証する機能は、セキュリティーに関する基本的な必須要件です。イメージのソースから使用される宛先まで、信頼チェーンが必要です。これは、信頼できるソースから取得したイメージを署名し、使用する前に署名を確認して実行できます。検証されたイメージを取得し、作成する各種の方法について以下に説明し、続いてイメージ署名の検証機能を説明します。

イメージを作成して Red Hat OpenStack Image サービス (glance) にアップロードする方法の詳細は、イメージの作成と管理 を参照してください。環境に信頼されたイメージを使用してセキュリティーを強化し、組織のハードニングガイドラインを使用して保護を強化します。環境のイメージは、次のいずれかの方法で取得できます。

イメージの署名検証を有効にして、Compute サービス (nova) がインスタンスを開始する前に、Image Service (glance) のイメージに不正な変更が含まれていないことを確認できます。この機能を有効にすると、マルウェアやセキュリティーの脆弱性が含まれる可能性のある新しいインスタンスが起動できなくなります。

OpenStack と基礎となる仮想化層は、OpenStack ノード間のイメージのライブマイグレーションを提供するため、インスタンスのダウンタイムなしに、Compute ノードのローリングアップグレードをシームレスに実行できます。ただし、ライブマイグレーションでは、大きなリスクも伴います。リスクを理解するため、ライブマイグレーション中に実行される手順の概要を以下に示します。

インスタンスは、ホスト間で複製可能なサーバーイメージです。したがって、物理ホストと仮想ホスト間と同様にロギングを適用することが推奨されます。ホストやデータへのアクセスイベント、ユーザーの追加および削除、権限の変更、要件で規定されるその他のイベントなどのオペレーティングシステムやアプリケーションイベントをログに記録する必要があります。結果をログアグリゲーターにエクスポートすることを検討してください。ログアグリゲーターは、ログイベントを収集し、解析用に関連付け、参照または今後のアクション用に保管します。これを実行するための一般的なツールの 1 つは、ELK スタックまたは Elasticsearch、Logstash、および Kibana です。

さらに、どのイベントがその後にアクションのレスポンダーに送信されるアラートのトリガーになるかを把握する必要があります。

ハイパーバイザーは、独立した仮想マシンを実行します。このハイパーバイザーは、オペレーティングシステム内または直接 (ベアメタルと呼ばれる) ハードウェア上で実行できます。ハイパーバイザーの更新は、仮想マシンに伝播されません。たとえば、デプロイメントが KVM を使用し、CentOS 仮想マシンのセットがある場合、KVM への更新では CentOS 仮想マシンで実行されているものは更新されません。

仮想マシンの明確な所有権を所有者に割り当て、その所有者が仮想マシンの強化、デプロイメント、および継続する機能を実施することを検討してください。また、更新を定期的にデプロイする計画を作成し、最初に実稼働環境と類似する環境でテストする必要があります。

最も一般的なオペレーティングシステムには、追加のセキュリティー層用のホストベースのファイアウォールが含まれています。インスタンスはできるだけ少ないアプリケーションを実行すべきで (可能な場合、単一目的のインスタンスの観点で)、インスタンス上で実行されているすべてのアプリケーションは、アプリケーションがアクセスする必要のあるシステムリソース、それの実行に必要な権限の最低レベル、および仮想マシンから送受信されると予想されるネットワークトラフィックを決定するために、プロファイリングする必要があります。この予想されるトラフィックは、SSH または RDP などの必要なロギングおよび管理通信と共に、許可されるトラフィックとしてホストベースのファイアウォールに追加する必要があります。その他のトラフィックは、すべてファイアウォール設定で明示的に拒否する必要があります。

Linux インスタンスでは、上記のアプリケーションプロファイルを、audit2allow などのツールと併用して、ほとんどの Linux ディストリビューションで機密システム情報をさらに保護する SELinux ポリシーを構築することができます。SELinux は、ユーザー、ポリシー、およびセキュリティーコンテキストの組み合わせを使用して、アプリケーションの実行に必要なリソースを区分し、必要のない他のシステムリソースから分離します。

OpenStack は、特定のプロジェクトのインスタンスに厚い防御を追加するために、ホストとネットワークの両方にセキュリティーグループを提供します。これらは、ポート、プロトコル、およびアドレスに基づいて着信トラフィックを許可または拒否するため、ホストベースのファイアウォールと似ています。ただし、ホストベースのファイアウォールルールは、着信トラフィックと送信トラフィックの両方に適用できますが、セキュリティーグループルールは、着信トラフィックにのみ適用されます。ホストおよびネットワークセキュリティーグループルールが競合して、正当なトラフィックを拒否することもあります。使用されているネットワークに対して、セキュリティーグループが正しく設定されていることを確認することを検討してください。詳細は、本ガイドのセキュリティーグループを参照してください。

デフォルトでは、インスタンスのコンソールには仮想コンソールからリモートでアクセスできます。これは、トラブルシューティングに役立ちます。Red Hat OpenStack Platform は、リモートコンソールアクセスに VNC を使用します。

インスタンスに SSH 接続する必要がある場合は、作成時に必要な SSH キーをインスタンスに自動的に挿入するよう Compute ノードを設定できます。

AMQP ベースのソリューション (Qpid および RabbitMQ) は、TLS を使用したトランスポートレベルのセキュリティーをサポートします。

メッセージキューのトランスポートレベルの暗号化を有効にすることを検討してください。メッセージングクライアント接続に TLS を使用すると、メッセージングサーバーへの改ざんおよび盗聴から通信を保護することができます。以下のガイダンスは、TLS が一般的な 2 つのメッセージングサーバー (Qpid および RabbitMQ) 用にどのように設定されているかに関するものです。メッセージングサーバーがクライアント接続を検証するために使用する信頼できる認証局 (CA) バンドルを設定する場合は、これをノードに使用される CA のみに制限することが推奨されます (内部管理 CA が推奨されます)。信頼された CA のバンドルは、承認されるクライアント証明書を決定し、TLS 接続の設定のクライアント-サーバー検証手順をスキップします。

[
  {rabbit, [
     {tcp_listeners, [] },
     {ssl_listeners, [{"<IP address or hostname of management network interface>", 5671}] },
     {ssl_options, [{cacertfile,"/etc/ssl/cacert.pem"},
                    {certfile,"/etc/ssl/rabbit-server-cert.pem"},
                    {keyfile,"/etc/ssl/rabbit-server-key.pem"},
                    {verify,verify_peer},
                    {fail_if_no_peer_cert,true}]}
   ]}
].

RabbitMQ および Qpid は、キューへのアクセスを制御する認証およびアクセス制御メカニズムを提供します。

Simple Authentication and Security Layer (SASL) は、インターネットプロトコルにおける認証およびデータセキュリティーのフレームワークです。RabbitMQ と Qpid はどちらも、簡単なユーザー名とパスワードより優れた SASL およびその他のプラグ可能な認証メカニズムを提供し、認証セキュリティーが強化されます。RabbitMQ は SASL をサポートしますが、現在 OpenStack のサポートでは、特定の SASL 認証メカニズムを要求することは許可されません。OpenStack の RabbitMQ サポートでは、暗号化されていない接続を使用したユーザー名およびパスワード認証、またはユーザー名/パスワードとセキュアな TLS 接続を確立するための X.509 クライアント証明書の組み合わせのどちらか可能です。

メッセージングキューへのクライアント接続用に、すべての OpenStack サービスノードで X.509 クライアント証明書を設定することを検討してください。また、可能であれば X.509 クライアント証明書を使用した認証を実施します (現在は Qpid のみ)。ユーザー名とパスワードを使用する場合は、キューへのアクセスをより細かく監査できるように、サービスおよびノードごとにアカウントを作成する必要があります。

デプロイメントの前に、キューサーバーが使用する TLS ライブラリーを考慮してください。Qpid は Mozilla の NSS ライブラリーを使用しますが、RabbitMQ は OpenSSL を使用する Erlang の TLS モジュールを使用します。

このセクションでは、OpenStack サービス用の標準的な RabbitMQ 設定を説明します。

[DEFAULT]
rpc_backend = nova.openstack.common.rpc.impl_kombu
rabbit_use_ssl = True
rabbit_host = RABBIT_HOST
rabbit_port = 5671
rabbit_user = compute01
rabbit_password = RABBIT_PASS
kombu_ssl_keyfile = /etc/ssl/node-key.pem
kombu_ssl_certfile = /etc/ssl/node-cert.pem
kombu_ssl_ca_certs = /etc/ssl/cacert.pem

このセクションでは、OpenStack サービス用の標準的な Qpid 設定を説明します。

[DEFAULT]
rpc_backend = nova.openstack.common.rpc.impl_qpid
qpid_protocol = ssl
qpid_hostname = <IP or hostname of management network interface of messaging server>
qpid_port = 5671
qpid_username = compute01
qpid_password = QPID_PASS

(オプション) Qpid で SASL を使用している場合は、以下を追加して、使用する SASL メカニズムを指定します。

qpid_sasl_mechanisms = <space separated list of SASL mechanisms to use for auth>

各プロジェクトは、メッセージを送信および消費するサービスを多数提供します。メッセージを送信する各バイナリーは、返信のみの場合、キューからのメッセージを消費します。

メッセージキューサービスのプロセスは、互いに、およびマシン上の他のプロセスから分離する必要があります。

Linux では、名前空間を使用してプロセスを独立したドメインに割り当てます。本ガイドのその他の部分では、システムの区分について詳細に説明します。

OpenStack は、パブリック向け内部管理エンドポイントとプライベート API エンドポイントの両方を提供します。デフォルトでは、OpenStack コンポーネントはパブリック向けに定義されたエンドポイントを使用します。適切なセキュリティードメイン内の API エンドポイントを使用するようにこれらのコンポーネントを設定することが推奨されます。内部管理エンドポイントにより keystone へのアクセスをさらに昇格できるため、これをさらに分離することが望ましい場合があります。

サービスは、OpenStack サービスカタログに基づいてそれぞれの API エンドポイントを選択します。これらのサービスは、リスト表示されるパブリックまたは内部 API エンドポイントの値に準拠していない可能性があります。これにより、内部管理トラフィックが外部 API エンドポイントにルーティングされる可能性があります。

Identity サービスカタログは内部 URL を認識している必要があります。この機能はデフォルトでは使用されていませんが、設定を介して利用できます。さらに、この動作がデフォルトになると、予想される変更と前方互換性があるはずです。

異なるアクセスレベルがある場合に、設定したエンドポイントをネットワークレベルから分離することを検討します。管理エンドポイントは、クラウド管理者によるアクセスを目的としています。内部またはパブリックエンドポイントでは利用できない keystone 操作へのアクセスを昇格できるためです。内部エンドポイントは、クラウド内部 (例: OpenStack サービス) の使用を目的としており、通常はデプロイメントネットワーク外からはアクセスできません。パブリックエンドポイントは TLS 対応の必要があり、クラウドユーザーが操作するデプロイメント外からアクセスできる唯一の API エンドポイントです。

エンドポイントの内部 URL の登録は、director により自動化されます。詳細は、https://github.com/openstack/tripleo-heat-templates/blob/a7857d6dfcc875eb2bc611dd9334104c18fe8ac6/network/endpoints/build_endpoint_map.py を参照してください。

特定の API エンドポイントを使用するように一部のサービスを強制することができます。したがって、別のサービスの API に接続する OpenStack サービスは、適切な内部 API エンドポイントにアクセスするように明示的に設定する必要があります。

各プロジェクトには、ターゲット API エンドポイントを定義する方法に一貫性がなくなる場合があります。OpenStack の今後のリリースでは、Identity サービスカタログの一貫した使用でこの不整合を解決します。

OpenStack の API エンドポイントおよびその他の HTTP サービスの多くは、Python Paste Deploy ライブラリーを使用します。このライブラリーは、セキュリティーの観点からは、アプリケーションの設定を介して要求フィルターパイプラインの操作を可能にします。このチェーンの各要素はミドルウェアを指します。パイプラインでフィルターの順序を変更したり、追加のミドルウェアを追加したりすると、予測不可能なセキュリティー上の影響を及ぼす可能性があります。

一般的に、実装者は OpenStack のベース機能を拡張するためにミドルウェアを追加します。標準以外のソフトウェアコンポーネントを HTTP 要求パイプラインに追加することによって導入される潜在的な漏えいを慎重に考慮することを検討します。

Red Hat OpenStack Platform (RHOSP) では、クラウド管理者はメタデータ定義 (metadef) API を使用してキー/値のペアおよびタグメタデータを定義することができます。クラウド管理者が作成できるメタデフ名前空間、オブジェクト、プロパティー、リソース、またはタグの数に制限はありません。

Image サービスのポリシーは metadef API を制御します。デフォルトでは、クラウド管理者のみがメタデフ API を作成、更新、または削除 (CUD) できます。この制限により、metadef API が権限のないユーザーに情報を公開することが防止され、悪意のあるユーザーがイメージサービス (glance) データベースに無制限のリソースを埋め込み、サービス拒否 (DoS) スタイルの攻撃を引き起こす可能性があるリスクが軽減されます。ただし、クラウド管理者はデフォルトのポリシーをオーバーライドできます。

メタデータ定義 (metadef) API への書き込みアクセスに依存するユーザーを持つクラウド管理者は、デフォルトの管理者専用ポリシーをオーバーライドすることで、すべてのユーザーがそれらの API にアクセスできるようにできます。ただし、この種の設定では、顧客名や内部プロジェクト等の秘匿すべきリソース名が意図せず漏えいする可能性があります。すべてのユーザーに読み取りアクセスしか付与していない場合であっても、管理者はシステムを監査し、過去に作成したセキュリティー的に脆弱なリソースを識別する必要があります。

オーバークラウドで SSL/TLS を有効にした場合は、HAProxy 設定で使用される SSL/TLS 暗号とルールを強化することを検討してください。SSL/TLS 暗号を強化することで、POODLE 脆弱性 などの SSL/TLS 脆弱性を回避できます。

API エンドポイントは通常複数のセキュリティーゾーンにまたがるので、API プロセスの分離に特に注意を払う必要があります。たとえば、ネットワーク設計レベルでは、指定したシステムにのみアクセスを限定することを検討してください。詳細は、セキュリティーゾーンに関するガイダンスを参照してください。

慎重にモデル化することで、ネットワーク ACL および IDS テクノロジーを使用して、ネットワークサービス間の明示的なポイントツーポイント通信を適用することができます。重要なクロスドメインサービスとして、このタイプの明示的な適用が OpenStack のメッセージキューサービスで機能します。

ポリシーを適用するには、サービス、ホストベースのファイアウォール (iptables など)、ローカルポリシー (SELinux)、およびオプションでグローバルネットワークポリシーを設定できます。

API エンドポイントプロセスは、互いに、およびマシン上の他のプロセスから分離する必要があります。これらのプロセスの設定は、Discretionary Access Controls (DAC) および Mandatory Access Controls (MAC) によってこれらのプロセスに制限される必要があります。これらの強化されたアクセス制御の目的は、API エンドポイントセキュリティー違反の封じ込めを支援することにあります。

レート制限は、ネットワークベースのアプリケーションによって受信されるイベントの頻度を制御する手段です。堅牢なレート制限が存在しない場合、アプリケーションはさまざまなサービス拒否攻撃を受けやすくなる場合があります。これは特に、その性質上、同様の要求タイプや操作を高い頻度で受け入れるように設計されている API が該当します。

すべてのエンドポイント (特にパブリック) には、物理ネットワーク設計、レート制限プロキシー、または Web アプリケーションのファイアウォールを使用するなど、追加の保護レイヤーを設定することが推奨されます。

レート制限機能を設定して実装する際に、運用者は OpenStack クラウド内のユーザーとサービスの個々のパフォーマンスニーズについて慎重に計画して考慮することが重要です。

Red Hat Single Sign-On (RH-SSO) を使用して、OpenStack 認証 (authN) 用の IdM ユーザーをフェデレーションすることができます。フェデレーションにより、IdM ユーザーは OpenStack サービスに認証情報を公開せずに OpenStack Dashboard にログインすることができます。代わりに、ダッシュボードがユーザーの認証情報を必要とする場合、ユーザーは RH-SSO に転送され、そこで IdM 認証情報を入力できます。これにより、RH-SSO はユーザーが正常に認証されたとして Dashboard に戻し、Dashboard はユーザーがプロジェクトにアクセスするのを許可します。

ここでは、Identity サービス (keystone)、RH-SSO、IdM の相互作用を説明します。OpenStack におけるフェデレーションは、認証プロバイダーとサービスプロバイダーの概念を使用します。

認証プロバイダー (IdP): ユーザーアカウントを保存するサービス。この場合、IdM に保持されるユーザーアカウントは、RH-SSO を使用して Keystone に表示されます。

サービスプロバイダー (SP): IdP のユーザーからの認証を必要とするサービス。この場合、keystone は IdM ユーザーに Dashboard へのアクセスを付与するサービスプロバイダーです。

RH-SSO (IdP) と通信するように Identity サービス (SP) を設定できます。これは、他の IdP のユニバーサルアダプターとしても機能します。この設定では、RH-SSO に keystone をポイントすることができ、RH-SSO は要求をサポートする認証プロバイダー (認証モジュールと呼ばれます) に転送します。現在、これらには IdM および Active Directory が含まれます。これは、サービスプロバイダー (SP) および認証プロバイダー (IdP) がメタデータを交換し、各システム管理者が信頼する決定を行うことで行われます。その結果、IdP は確実に決定を行い、SP はこれらの決定を受け取ることができます。