セキュリティーおよび強化ガイド

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

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

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

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

openstack network create internal-network

openstack network create internal-network

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

openstack network create internal-network --project testing

openstack network create internal-network --project testing

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 https://openstack.lab.local
..............................
Target: openstack.lab.local:443

prio  ciphersuite                  protocols  pfs                 curves
1     ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2    ECDH,P-256,256bits  prime256v1
2     ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2    ECDH,P-256,256bits  prime256v1
3     DHE-RSA-AES128-GCM-SHA256    TLSv1.2    DH,1024bits         None
4     DHE-RSA-AES256-GCM-SHA384    TLSv1.2    DH,1024bits         None
5     ECDHE-RSA-AES128-SHA256      TLSv1.2    ECDH,P-256,256bits  prime256v1
6     ECDHE-RSA-AES256-SHA384      TLSv1.2    ECDH,P-256,256bits  prime256v1
7     ECDHE-RSA-AES128-SHA         TLSv1.2    ECDH,P-256,256bits  prime256v1
8     ECDHE-RSA-AES256-SHA         TLSv1.2    ECDH,P-256,256bits  prime256v1
9     DHE-RSA-AES128-SHA256        TLSv1.2    DH,1024bits         None
10    DHE-RSA-AES128-SHA           TLSv1.2    DH,1024bits         None
11    DHE-RSA-AES256-SHA256        TLSv1.2    DH,1024bits         None
12    DHE-RSA-AES256-SHA           TLSv1.2    DH,1024bits         None
13    ECDHE-RSA-DES-CBC3-SHA       TLSv1.2    ECDH,P-256,256bits  prime256v1
14    EDH-RSA-DES-CBC3-SHA         TLSv1.2    DH,1024bits         None
15    AES128-GCM-SHA256            TLSv1.2    None                None
16    AES256-GCM-SHA384            TLSv1.2    None                None
17    AES128-SHA256                TLSv1.2    None                None
18    AES256-SHA256                TLSv1.2    None                None
19    AES128-SHA                   TLSv1.2    None                None
20    AES256-SHA                   TLSv1.2    None                None
21    DES-CBC3-SHA                 TLSv1.2    None                None

Certificate: trusted, 2048 bits, sha256WithRSAEncryption signature
TLS ticket lifetime hint: None
NPN protocols: None
OCSP stapling: not supported
Cipher ordering: server
Curves ordering: server - fallback: no
Server supports secure renegotiation
Server supported compression methods: NONE
TLS Tolerance: yes

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

$ ./cipherscan https://openstack.lab.local
..............................
Target: openstack.lab.local:443

prio  ciphersuite                  protocols  pfs                 curves
1     ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2    ECDH,P-256,256bits  prime256v1
2     ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2    ECDH,P-256,256bits  prime256v1
3     DHE-RSA-AES128-GCM-SHA256    TLSv1.2    DH,1024bits         None
4     DHE-RSA-AES256-GCM-SHA384    TLSv1.2    DH,1024bits         None
5     ECDHE-RSA-AES128-SHA256      TLSv1.2    ECDH,P-256,256bits  prime256v1
6     ECDHE-RSA-AES256-SHA384      TLSv1.2    ECDH,P-256,256bits  prime256v1
7     ECDHE-RSA-AES128-SHA         TLSv1.2    ECDH,P-256,256bits  prime256v1
8     ECDHE-RSA-AES256-SHA         TLSv1.2    ECDH,P-256,256bits  prime256v1
9     DHE-RSA-AES128-SHA256        TLSv1.2    DH,1024bits         None
10    DHE-RSA-AES128-SHA           TLSv1.2    DH,1024bits         None
11    DHE-RSA-AES256-SHA256        TLSv1.2    DH,1024bits         None
12    DHE-RSA-AES256-SHA           TLSv1.2    DH,1024bits         None
13    ECDHE-RSA-DES-CBC3-SHA       TLSv1.2    ECDH,P-256,256bits  prime256v1
14    EDH-RSA-DES-CBC3-SHA         TLSv1.2    DH,1024bits         None
15    AES128-GCM-SHA256            TLSv1.2    None                None
16    AES256-GCM-SHA384            TLSv1.2    None                None
17    AES128-SHA256                TLSv1.2    None                None
18    AES256-SHA256                TLSv1.2    None                None
19    AES128-SHA                   TLSv1.2    None                None
20    AES256-SHA                   TLSv1.2    None                None
21    DES-CBC3-SHA                 TLSv1.2    None                None

Certificate: trusted, 2048 bits, sha256WithRSAEncryption signature
TLS ticket lifetime hint: None
NPN protocols: None
OCSP stapling: not supported
Cipher ordering: server
Curves ordering: server - fallback: no
Server supports secure renegotiation
Server supported compression methods: NONE
TLS Tolerance: yes

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

サーバーのスキャン時に、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

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 Open Stack Platform 環境と統合できるように、以下の推奨事項を使用してください。

Red Hat Open Stack 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 の場合は、次の値を使用します。

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

この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能です。実稼働環境にはデプロイしないでください。テクノロジープレビュー機能についての詳しい情報は、対象範囲の詳細 を参照してください。

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

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

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

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

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

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

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

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

Fernet は、UUID トークンプロバイダーに代わるデフォルトのトークンプロバイダーです。

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 に渡します。

View larger image

関連情報

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

サービスのポリシーファイルはこれまで /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": "rule:admin_required"

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

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

"identity:create_user": "!"

"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"

"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_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"

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

利用可能な policy.json 構文オプションの詳細は、ポリシー構文 を参照してください。

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

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

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

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

オーバークラウド上で実行する OpenStack サービスは、Identity サービス (keystone) の認証情報により認証されます。これらのパスワードは、初期のデプロイメントプロセス時に生成され、heat パラメーターとして定義されます。以下に例を示します。

            'MistralPassword',
            'BarbicanPassword',
            'AdminPassword',
            'CeilometerMeteringSecret',
            'ZaqarPassword',
            'NovaPassword',
            'MysqlRootPassword'

            'MistralPassword',
            'BarbicanPassword',
            'AdminPassword',
            'CeilometerMeteringSecret',
            'ZaqarPassword',
            'NovaPassword',
            'MysqlRootPassword'

Workflow サービス (mistral) ワークフローを使用して、サービスアカウントが使用するパスワードをローテーションできます。ただし、Key Encrypting Keys(KEK) キーおよび Fernet キーなど、DO_NOT_ROTATE に記載のパスワードがローテーションされません。

DO_NOT_ROTATE_LIST = (
    'BarbicanSimpleCryptoKek',
    'SnmpdReadonlyUserPassword',
    'KeystoneCredential0',
    'KeystoneCredential1',
    'KeystoneFernetKey0',
    'KeystoneFernetKey1',
    'KeystoneFernetKeys',
)

DO_NOT_ROTATE_LIST = (
    'BarbicanSimpleCryptoKek',
    'SnmpdReadonlyUserPassword',
    'KeystoneCredential0',
    'KeystoneCredential1',
    'KeystoneFernetKey0',
    'KeystoneFernetKey1',
    'KeystoneFernetKeys',
)

これらのパスワードは、以下の理由により DO_NOT_ROTATE リストにあります。

以下の手順を使用して、対象のパスワードをローテーションします。次回 openstack overcloud deploy コマンドを実行してスタックの更新を完了すると、ローテーションされたパスワードの変更が適用されます。環境ファイルで指定したパスワードは、この方法を使用するパスワードの変更よりも優先されます。要件およびサービスへの影響に関する情報は、Outage requirements を参照してください。

オーバークラウドサービスアカウントのパスワードを変更すると、停止要件とサービスへの影響が発生することがあります。

スタック更新の一環としてパスワードをローテーションした後、古いパスワードが無効になります。その結果、サービス設定に新しいパスワードを追加するまでに、HTTP 401 エラーでサービスが利用できなくなります。

さらに、MySQL、RabbitMQ、および高可用性など、サポートサービスのパスワードを変更すると、一時的に停止することが予想されます。

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

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

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

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

ハイパーバイザープラットフォームを評価する際には、ハイパーバイザーを実行するハードウェアのサポート可能性を考慮してください。また、ハードウェアで利用可能な追加機能と、それらの機能が OpenStack デプロイメントの一部として選択したハイパーバイザーによってどのようにサポートされているかについて検討してください。そのため、ハイパーバイザーには、それぞれ独自のハードウェア互換性リスト (HCL) があります。互換性のあるハードウェアを選択する場合は、セキュリティーの観点から、ハードウェアベースの仮想化技術が重要なかを把握しておくことが重要です。

PCI パススルーを使用すると、インスタンスはノード上のハードウェアの一部に直接アクセスできます。たとえば、このパラメーターを使用して、インスタンスをビデオカードや GPU にアクセスできるようにし、高パフォーマンスの計算用にコンピュート統一されたデバイスアーキテクチャー (CUDA) を提供します。この機能は、ダイレクトメモリーアクセスとハードウェアの脆弱性の 2 種類のセキュリティーリスクを伴います。

ダイレクトメモリーアクセス (DMA) は、特定のハードウェアデバイスがホストコンピューター内の任意の物理メモリーアドレスにアクセスできるようにする機能です。多くの場合、ビデオカードにはこの機能があります。ただし、これにより、同じノードで実行されているホストシステムや他のインスタンスの両方を確認することがあるため、任意の物理メモリーアクセスを付与しないでください。ハードウェアベンダーは、出入力メモリー管理ユニット (IOMMU) を使用して、このような状況で DMA アクセスを管理します。ハイパーバイザーがこのハードウェア機能を使用するように設定されていることを確認する必要があります。

インスタンスがファームウェアや他のデバイスの一部に悪意のある変更を加えると、ハードウェア感染が発生します。他のインスタンスやホスト OS がこのデバイスが使用されるため、悪意のあるコードはこれらのシステムに配布できます。最終的には、あるインスタンスがそのセキュリティーゾーン外でコードを実行できることです。これは、仮想ハードウェアよりも物理ハードウェアの状態をリセットすることが難しくなるため、管理ネットワークへのアクセスなどが追加で公開される可能性があるためです。

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.*
   ******************************************************************

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

    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

    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:
        tripleo::firewall::firewall_rules:
          '301 allow zabbix':
            dport: 10050
            proto: tcp
            source: 10.0.0.8
            action: accept

    parameter_defaults:
      ControllerExtraConfig:
        tripleo::firewall::firewall_rules:
          '301 allow zabbix':
            dport: 10050
            proto: tcp
            source: 10.0.0.8
            action: accept

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

    parameter_defaults:
      ControllerExtraConfig:
        tripleo::firewall::firewall_rules:
          '098 allow rabbit from internalapi network':
            dport: [4369,5672,25672]
            proto: tcp
            source: 10.0.0.0/24
            action: accept
          '099 drop other rabbit access':
            dport: [4369,5672,25672]
            proto: tcp
            action: drop

    parameter_defaults:
      ControllerExtraConfig:
        tripleo::firewall::firewall_rules:
          '098 allow rabbit from internalapi network':
            dport: [4369,5672,25672]
            proto: tcp
            source: 10.0.0.0/24
            action: accept
          '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

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 に保存されます。

    tripleo.rabbitmq.firewall_rules:
      '109 rabbitmq':
        dport:
          - 4369
          - 5672
          - 25672

    tripleo.rabbitmq.firewall_rules:
      '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

  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

    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

  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

  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

  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

    parameter_defaults:
      ControllerExtraConfig:
        horizon::disallow_iframe_embed: false

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

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

詳細は、Ansible を使用した TLS-e の実装を参照してください。

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

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'

          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) は、パスワード検証チェックを使用してパスワードの複雑さを強制的に適用することができます。

パスワードの検証に正規表現を指定することや、テストに失敗した場合に表示されるヘルプテキストを指定することができます。以下の例では、8 文字から 18 文字までのパスワードを作成することをユーザーに要求します。

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

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

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

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

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

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

Dashboard の local_settings.py ファイルの ENFORCE_PASSWORD_CHECK 設定により、Change Password フォームに Admin Password フィールドが表示されます。これは、管理者がパスワード変更を開始していることを検証するのに役立ちます。

環境ファイルを使用して ENFORCE_PASSWORD_CHECK を無効にすることができます。

    parameter_defaults:
      ControllerExtraConfig:
        horizon::enforce_password_check: false

    parameter_defaults:
      ControllerExtraConfig:
        horizon::enforce_password_check: false

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

パスワード表示ボタンは、ダッシュボードのユーザーが入力するパスワードを表示できるようにします。このオプションは、DISABLE_PASSWORD_REVEAL パラメーターを使用して切り替えることができます。

    parameter_defaults:
      ControllerExtraConfig:
        horizon::disable_password_reveal: false

    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 サービスと対話します。OpenStack Networking サービスの主なプロセスは、neutron-server で、OpenStack Networking API を公開し、追加の処理のためにプロジェクト要求をプラグインスイートに渡す Python デーモンです。

OpenStack Networking のコンポーネントは以下のとおりです。

以下の図は、OpenStack Networking コンポーネントのアーキテクチャーおよびネットワークフローの図を示しています。

View larger image

このアプローチは、分散仮想ルーター (DVR) および Layer-3 高可用性 (L3HA) が使用された場合に大幅に変更されることに注意してください。L3HA はルーター間で VRRP を実装するため、これらのモードは neutron のセキュリティーランドスケープを変更します。デプロイメントは、ルーターに対する DoS 攻撃を軽減できるように適切にサイズで強化する必要があります。また、VRRP スプーフィングの脅威に対処するために、ルーター間のローカルネットワークトラフィックを機密として扱う必要があります。DVR はネットワークコンポーネント (ルーティングなど) をコンピュートノードに移行する一方で、まだネットワークノードが必要です。したがって、コンピュートノードはパブリックネットワーク間のアクセスを必要とするため、ファイアウォールルールとセキュリティーモデルがこのアプローチをサポートする必要があるため、公開機能が高まり、お客様が追加でセキュリティーを考慮する必要があります。

本項では、コントローラーノード、ネットワークノード、および実行中のインスタンス用のコンピュートノードセットが含まれる標準のアーキテクチャーを説明します。物理サーバーのネットワーク接続を確立するために、通常の neutron デプロイメントは、4 つの異なる物理データセンターネットワークで設定されます。

View larger image

このトラフィックを別のゾーンに分割することを推奨します。詳細は次のセクションを参照してください。

重大なシステムは互いに分離させて、セキュリティーゾーンという概念を使用することを推奨します。実用的な方法では、VLAN およびファイアウォールルールを使用してネットワークトラフィックを分離します。このキュレートは細かい詳細で行い、neutron に接続する必要のあるサービスのみがこれを実行できるようにする必要があります。

以下の図は、ゾーンが特定のコンポーネントを分離するために作成されていることがわかります。

View larger image

OpenStack Network インフラストラクチャーを設計するための初期アーキテクチャーフェーズでは、適切なセキュリティー制御および監査のメカニズムを特定できるようにするためにも、適切な専門知識で物理ネットワークインフラストラクチャーのデザインをアシストできるようにしておくことが重要です。

OpenStack Networking は、プロジェクト固有の仮想ネットワークをアーキテクトする機能を提供する、仮想ネットワークサービスのレイヤーを追加します。現在、これらの仮想化サービスは、従来のネットワークに対応するネットワークほど成熟していません。このような仮想化サービスの現在の状態を、仮想化および従来のネットワーク境界に実装する必要のあるコントロールを定めるため、それらを採用する前にこれらの仮想化サービスの現在の状態を考慮してください。

OpenStack Networking は、プロジェクト/ネットワークの組み合わせ: VLAN (IEEE 802.1Q タグ付け) または VXLAN または GRE カプセル化を使用する L2 トンネルのトラフィック分離に、2 つの異なるメカニズムを使用できます。OpenStack デプロイメントのスコープおよびスケーリングは、トラフィックの分離または分離に使用する方法を決定します。

Compute は、OpenStack Networking サービスの使用により、プロジェクトのネットワークトラフィックのアクセス制御をサポートします。セキュリティーグループにより、管理者およびプロジェクトがトラフィックの種別を指定することができ、かつ方向 (ingress/egress) が仮想インターフェイスポートを通過できる方向 (ingress/egress) を指定することができます。セキュリティーグループルールは、ステートフル L2-L4 トラフィックフィルターです。

OpenStack Networking ルーターは、複数の L2 ネットワークを接続でき、1 つ以上のプライベート L2 ネットワークを、インターネットにアクセスするためのパブリックネットワークなど、共有外部ネットワークに接続するゲートウェイを提供することもできます。

L3 ルーターは、ルーターを外部ネットワークにリンクするゲートウェイポートで、基本的なネットワークアドレス変換 (SNAT および DNAT) 機能を提供します。このルーター SNAT (ソース NAT) デフォルトですべての egress トラフィックをサポートし、Floating IP をサポートします。Floating IP は、外部ネットワーク上のパブリック IP からルーターに接続された他のサブネットにプライベート IP に静的 1 対 1 のプライベート IP へのマッピングを作成します。Floating IP (DNAT 経由) は、インスタンスに外部インバウンドの接続性を提供し、あるインスタンスから別のインスタンスから移行することができます。

プロジェクトインスタンスのより詳細な接続のために、プロジェクトごとの L3 ルーティングと Floating IP を使用することを検討してください。パブリックネットワークに接続されたインスタンス、または Floating IP を使用して、特別な考慮する必要があります。外部で公開される必要があるサービスのみに対して、セキュリティーグループの使用を慎重に検討することが推奨されます。

デフォルトでは、QoS (Quality of Service) ポリシーおよびルールはクラウド管理者によって管理されます。これにより、プロジェクトが特定の QoS ルールを作成できず、またポートに特定のポリシーをアタッチすることはできません。管理者が通信するアプリケーションなどの一部のユースケースでは、管理者がプロジェクトを信頼し、独自のポリシーをポートに作成および接続できるようにします。そのためには、policy.json ファイルを変更します。

Red Hat OpenStack Platform 12 から、neutron は、受信トラフィックと送信トラフィックの両方で、帯域幅を制限する QoS ルールをサポートしています。この QoS ルールは QosBandwidthLimitRule という名前で、毎秒キロビットで測定される負の整数を 2 つ受け取ります。

QoSBandwidthLimitRule は、neutron Open vSwitch、Linux ブリッジ、および SR-IOV ドライバーに実装されています。ただし、SR-IOV ドライバーでは、max-burst-kbps の値が使用されず、設定されている場合は無視されます。

QoS ルール QosDscpMarkingRule は、IPv4 (RFC 2474) のサービスヘッダーのタイプに Differentiated Service Code Point (DSCP) 値を設定し、仮想マシンから出るすべてのトラフィックで、IPv6 のトラフィッククラスヘッダー (ルールが適用されます) を設定します。これは、ネットワークが輻輳に合致するように、パケットのドロップの優先度を示す、有効な値が 21 の 6 ビットヘッダーです。また、ファイアウォールで使用して、アクセス制御リストに対する有効なトラフィックまたは無効なトラフィックを一致させることもできます。

OpenStack Load-balancing サービス (octavia) は、Red Hat OpenStack Platform director のインストール環境で、Load Balancing-as-a-Service (LBaaS) の実装を提供します。負荷分散機能を実現するために、octavia では複数のプロバイダードライバーを有効にする設定がサポートされます。参照プロバイダードライバー (Amphora プロバイダードライバー) は、オープンソースのスケーラビリティーに優れた高可用性負荷分散プロバイダーです。仮想マシン群 (amphora と総称される) を管理し、オンデマンドで起動することで、負荷分散サービスを提供します。

Load-balancing サービスの詳細は、Using Octavia for Load Balancing-as-a-Service を参照してください。

本項では、OpenStack デプロイメント内のプロジェクトネットワークセキュリティーに適用される、OpenStack Networking の設定に関する適切なプラクティスについて説明します。

リクエストごとの最大ボディーサイズが定義されていない場合、攻撃者は大きなサイズの任意の 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 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

 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 |
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+

 $ 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|
 +----+--------+-----------+-----------+----------------------------------+----------------------+

 $ 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

 $ 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 |
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+

 $ 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": "",
   }

   {
       "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 のセキュリティー強化は、ネットワークコンポーネントのセキュリティー保護から始まります。詳細は、Networking の章を参照してください。

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

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

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

View larger image

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 {} \;

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 に保管されている同じ (対称) キーを使用して処理されます。

詳細は、Barbican のインテグレーションガイド (https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/16.2/html-single/manage_secrets_with_openstack_key_manager/) を参照してください。

すべてのノードの /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.

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 にできないためです。

View larger image

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

OpenStack のドキュメントでは、イメージを作成して Image サービスにアップロードする方法についてのガイダンスを提供します。また、ゲストオペレーティングシステムをインストールおよび強化するプロセスがあることが前提となります。以下の項目は、イメージを OpenStack に転送する方法に関する補足情報を提供します。イメージを取得するオプションは複数あります。それぞれは、イメージの由来を検証するのに役立つ特定のステップを持ちます。

この例では、RHEL 6 CCE-26976-1 は、Oz 内に NIST 800-53 Section AC-19(d) を実装するのに役立ちます。

<template>
<name>centos64</name>
<os>
  <name>RHEL-6</name>
  <version>4</version>
  <arch>x86_64</arch>
  <install type='iso'>
  <iso>http://trusted_local_iso_mirror/isos/x86_64/RHEL-6.4-x86_64-bin-DVD1.iso</iso>
  </install>
  <rootpw>CHANGE THIS TO YOUR ROOT PASSWORD</rootpw>
</os>
<description>RHEL 6.4 x86_64</description>
<repositories>
  <repository name='epel-6'>
  <url>http://download.fedoraproject.org/pub/epel/6/$basearch</url>
  <signed>no</signed>
  </repository>
</repositories>
<packages>
  <package name='epel-release'/>
  <package name='cloud-utils'/>
  <package name='cloud-init'/>
</packages>
<commands>
  <command name='update'>
  yum update
  yum clean all
  sed -i '/^HWADDR/d' /etc/sysconfig/network-scripts/ifcfg-eth0
  echo -n > /etc/udev/rules.d/70-persistent-net.rules
  echo -n > /lib/udev/rules.d/75-persistent-net-generator.rules
  chkconfig --level 0123456 autofs off
  service autofs stop
  </command>
</commands>
</template>

<template>
<name>centos64</name>
<os>
  <name>RHEL-6</name>
  <version>4</version>
  <arch>x86_64</arch>
  <install type='iso'>
  <iso>http://trusted_local_iso_mirror/isos/x86_64/RHEL-6.4-x86_64-bin-DVD1.iso</iso>
  </install>
  <rootpw>CHANGE THIS TO YOUR ROOT PASSWORD</rootpw>
</os>
<description>RHEL 6.4 x86_64</description>
<repositories>
  <repository name='epel-6'>
  <url>http://download.fedoraproject.org/pub/epel/6/$basearch</url>
  <signed>no</signed>
  </repository>
</repositories>
<packages>
  <package name='epel-release'/>
  <package name='cloud-utils'/>
  <package name='cloud-init'/>
</packages>
<commands>
  <command name='update'>
  yum update
  yum clean all
  sed -i '/^HWADDR/d' /etc/sysconfig/network-scripts/ifcfg-eth0
  echo -n > /etc/udev/rules.d/70-persistent-net.rules
  echo -n > /lib/udev/rules.d/75-persistent-net-generator.rules
  chkconfig --level 0123456 autofs off
  service autofs stop
  </command>
</commands>
</template>

イメージの手動のビルドプロセスは複雑で、エラーが発生する可能性があるため、避けてください。さらに、イメージのビルドに Oz などの自動化システム、または起動後のイメージのハードニングのための設定管理ユーティリティー (Chef または Puppet など) を使用すると、一貫したイメージを作成したり、長期に渡りベースイメージが対応する強化ガイドラインに準拠していることを追跡したりできます。

パブリッククラウドサービスをサブスクライブする場合には、クラウドプロバイダーで、デフォルトのイメージを生成するために使用するプロセスの概要を確認する必要があります。プロバイダーで独自のイメージをアップロードできる場合、インスタンスを作成するためにイメージを使用する前に、イメージが変更されていないことを確認できる必要があります。これを行うには、イメージ署名の確認の以下のセクションまたは、署名を使用できない場合は以下の段落を参照してください。

Image サービス (glance) は、ノード上の Compute サービスにイメージをアップロードするために使用されます。この転送は、TLS 経由でさらに強化する必要があります。イメージがノード上にあると、これは基本的なチェックサムでチェックされ、そのディスクは起動されるインスタンスのサイズに基づいて拡張されます。後で、このノードで同じインスタンスサイズで同じイメージを起動すると、同じ拡張イメージから起動されます。この拡張されたイメージは起動前にデフォルトで再検証されないため、改ざんされたリスクがあります。ファイルの手動検査が、作成されるイメージで実行されていない限り、ユーザーは改ざんを認識しません。これを軽減するには、イメージの署名の確認トピックで以下のセクションを参照してください。

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

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

"compute_extension:admin_actions:migrate": "!",
"compute_extension:admin_actions:migrateLive": "!",

"compute_extension:admin_actions:migrate": "!",
"compute_extension:admin_actions:migrateLive": "!",

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

詳細は、Creating an image を参照してください。

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}]}
   ]}
].

[
  {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

[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

[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>

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 要求パイプラインに追加することによって導入される潜在的な漏えいを慎重に考慮することを検討します。

API エンドポイントプロセスを分離して、セキュリティーを高めることができます。公開されたセキュリティードメイン内の API エンドポイントを別のホストにデプロイし、隔離性を高めることを検討してください。

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