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

Red Hat OpenStack Platform 15

グッドプラクティス、コンプライアンス、およびセキュリティーの強化

概要

このガイドでは、Red Hat OpenStack Platform 環境のセキュリティーを強化するためのグッドプラクティスのアドバイスと概念的な情報を提供します。

第1章 はじめに

セキュリティーは重要な懸念事項であり、デプロイメントの重点を置く必要があります。データの漏洩やダウンタイムはコストがかかり、管理が難しくなります。また、法律によって監査やコンプライアンスのプロセスが必要になることもあり、プロジェクトでは一定レベルのプライバシーとデータのセキュリティーが求められます。このセクションでは、Red Hat OpenStack Platform のセキュリティーに関する全般的な概要と、お客様のシステムのセキュリティーをサポートする上での Red Hat の役割について説明します。

注記

本ドキュメントでは、ディレクターベースのデプロイメントを中心に、Red Hat OpenStack Platform デプロイメントのセキュリティーを強化するためのアドバイスおよびグッドプラクティス情報を提供します。本書の指示に従って、お使いの環境のセキュリティーを強化しますが、これらの推奨事項に従ってセキュリティーやコンプライアンスを保証しません。

1.1. OpenStack の基本概念

1.1.1. OpenStack とは

OpenStack とは何かを理解するためには、まず クラウド とは何かを理解する必要があります。簡単に言うと、クラウドコンピューティングとは、処理能力、ディスクストレージ、データベース処理、ネットワークサービスを消費者が利用できるようにすることであり、顧客は一連の API を通じてプログラム的にそれらを操作することができます。

このアプローチを、仮想マシン (VM) のホスティングに特化した従来のハイパーバイザー製品と比較してみましょう。VM は、従来の物理的なスタンドアロンサーバーと同じように使用され、一人のシステム管理者が仮想マシンのプロビジョニングを行い、別のシステム管理者がログインしてデータベースアプリケーションやその他のソフトウェアをインストールします。その後、VM は数年間稼働し、データはローカル (または付属の SAN) に保存され、毎日バックアップされます。

OpenStack でも仮想マシンを運用するのは正しいのですが、その管理方法は上記のものとは大きく異なります。インスタンスは、作成後すぐに使用でき、アプリケーションの準備ができていて、さらに設定を行う必要はありません。問題が発生した場合は、障害のトラブルシューティングに時間を費やすのではなく、新しい代替インスタンスをデプロイする必要があります。

OpenStack には、上述したことを実現するために連携するサービスが揃っていますが、これは数あるユースケースの 1 つに過ぎません。

詳しい情報は、『OpenStack Product Guide』： https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/15/html-single/product_guide/を参照してください。

1.1.2. 主要な用語

このガイドの残りの部分に進む前に、新規ユーザーが最初に遭遇するであろう OpenStack 固有の専門用語に慣れておくことをお勧めします。

  • インスタンス: これは仮想マシンです。これらは、Compute ノードと呼ばれる専用のハイパーバイザーサーバー上でホストされます。
  • プロジェクト: ユーザー、インスタンス、仮想ネットワーク（その他）を組み合わせた OpenStack リソースのパーティション化されたコレクション。プロジェクトでは、ユーザーやインスタンスのあるコレクションを、別のコレクションとは別に管理することができます。これは、複数の異なる部門や組織をホストする OpenStack のデプロイメントに有効です。管理者は、作成したユーザーやインスタンスごとに、送信先のプロジェクトを指定する必要があります。
  • イメージ: オペレーティングシステムテンプレート。インスタンスを作成する際には、どの OS で動作させるかを決定する必要があります。OpenStack では、イメージ と呼ばれる OS のテンプレートを選択することができます。CentOS および Red Hat Enterprise Linux では、ビルド済みのイメージが利用できます。
  • フレーバー: 仮想マシンのハードウェアテンプレート。インスタンスを構築するたびに RAM と CPU の割り当て量を指定するのではなく、フレーバー を定義してこれらの値をあらかじめ設定しておくことができます。Red Hat OpenStack Platform のデプロイメントでは、1GB の RAM を搭載した m1.tiny から 16GB のRAM を搭載した m1.xlarge までのフレーバーがすでに定義されています。
  • セキュリティーグループ: ファイアウォールルールです。各プロジェクトには独自の セキュリティーグループ を設け、ネットワークへの出入りを許可するトラフィックを定義することができます。

1.1.3. ディレクターによる設定管理

Red Hat OpenStack Platform director では、YAML テンプレートを使用して OpenStack 環境をデプロイおよび管理を行うことができます。これにより、自分の設定がどのようになっているのかを簡単に把握することができます。OpenStack 設定ファイルは Puppet によって管理されるため、openstack overcloud deploy プロセスを実行するたびに、管理対象外の変更が上書きされます。これにより、YAML の設定が特定の時点での現実を表していることをある程度保証することができます。また、このアプローチにより、OpenStack 導入時のセキュリティー構成管理に一貫性、監査性、再現性を持たせることができます。障害復旧についても、Director が構成管理とオーケストレーションを使用することで、クラウドの導入と構成が体系化され、復旧時間が向上します。

さらに、デプロイ時に渡されるカスタム環境ファイルを使って、独自のカスタマイズを追加することもできます。

詳しくは、『director のインストールと使用方法』を参照してください。https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/15/html-single/director_installation_and_usage/

1.2. セキュリティーの境界線と脅威

クラウドデプロイメントに存在するセキュリティーリスクを理解するためには、クラウドを、共通の機能、ユーザー、共通のセキュリティー問題を持つコンポーネントの集合体として抽象的に考えることが有効ですが、本書ではこれを セキュリティーゾーン と呼びます。脅威のアクターとベクターは、その動機とリソースへのアクセスに基づいて分類されます。目的に応じて、各ゾーンのセキュリティー上の懸念を把握することを目的としています。

1.2.1. セキュリティゾーン

セキュリティーゾーンは、一般的な信頼要件とシステム内で期待するユーザー、アプリケーション、サーバー、またはネットワークで構成されます。通常、これらは同じ認証と承認の要件とユーザーを共有します。これらのゾーンの定義はさらに細かく設定することができますが、本ガイドでは、セキュリティーが強化された OpenStack クラウドを展開するために必要な最低限のセキュリティーゾーンとして、以下の明確なセキュリティーゾーンを参照しています。これらのセキュリティゾーンは、少なくとも信頼されているものから順に一覧表示されます。

  • パブリックゾーン - 外部の公開用 API、neutron の外部ネットワーク (Floating IP や SNAT による外部接続など)。
  • ゲストゾーン - プロジェクトネットワーク (VLAN または VXLAN)。
  • ストレージアクセスゾーン - ストレージ管理 (ストレージ監視およびクラスターリング)、ストレージ (SAN/オブジェクト/ブロックストレージ)。
  • マネージメントゾーン - 一般的に、アンダークラウド、ホストのオペレーティングシステム、ハードウェア、ネットワーク、アンダークラウドのコントロールプレーン (オーバークラウドホストのプロビジョニング/管理)、オーバークラウドのシステム管理者/監視/バックアップを含みます。
  • アドミンゾーン - オーバークラウドを介したエンドポイントアクセス、インフラストラクチャー API、DB、RPC を含む内部 API を許可します (オーバークラウド上のプロジェクトのさまざまな API アクセスロールによって異なります)。オーバークラウドへの管理者アクセスは、アンダークラウドとハードウェアへの管理アクセスを必要としないこと。

これらのセキュリティーゾーンは、個別にマッピングすることも、特定の OpenStack デプロイメント内で信頼の可能な領域の大部分を表すこともできます。たとえば、デプロイメントトポロジーによっては、1 つの物理ネットワーク上に複数のゾーンを組み合わせて構成していたり、他のトポロジーではこれらのゾーンが分離されていたりします。いずれの場合も、適切なセキュリティー上の注意点を知っておく必要があります。セキュリティーゾーンは、お客様の OpenStack デプロイメントトポロジーに合わせてマッピングする必要があります。ゾーンとその信頼要件は、クラウドインスタンスがパブリック、プライベート、またはハイブリッドのいずれであるかによって異なります。

1.2.1.1. パブリックゾーン

パブリックセキュリティーゾーンは、クラウドインフラストラクチャーの完全に信頼されていない領域です。この環境は、インターネット全体として参照することも、認証局がない Red Hat OpenStack Platform デプロイメント外部のネットワークにも言及することができます。このゾーンを経由する機密性または整合性要件があるデータはすべて、補正制御を使用して保護する必要があります。

注記

このゾーンは常に信頼できないものと考えてください。

1.2.1.2. ゲストゾーン

通常、Compute インスタンス間のトラフィックに使用されるゲストセキュリティーゾーンは、クラウド上のインスタンスが生成するコンピュートデータを処理しますが、API コールなどのクラウドの運用をサポートするサービスは処理しません。

インスタンスの使用を厳格に管理していない、またはインスタンスへの無制限のインターネットアクセスを許可しているパブリックおよびプライベートクラウドプロバイダーは、このゾーンを信頼できないと考えるべきです。プライベートクラウドのプロバイダーは、インスタンスとそれに関連するすべてのプロジェクト (基盤となるハードウェアと内部ネットワークを含む) が信頼できることを保証するための適切なコントロールが実装されている場合に限り、このネットワークを内部で信頼できるものとみなすことができるでしょう。

1.2.1.3. ストレージアクセスゾーン

このネットワークを介して送信されるデータのほとんどは、高いレベルの完全性と機密性を必要とします。また、デプロイメントの形態によっては、強い可用性が求められる場合もあります。

ストレージアクセスネットワークは、絶対に必要な場合を除き、デプロイ外からアクセスできないようにする必要があります。このネットワークは、レプリケーションの要件を除いて、ストレージアプライアンス以外のクラウド外部からはアクセスできないと想定されており、このゾーンにデプロイされたコンポーネントは、セキュリティーの観点から機密のものとして扱われます。

このネットワークの信頼レベルはデプロイ時の判断に大きく依存するため、本ガイドではこのゾーンにデフォルトの信頼レベルを割り当てていません。

1.2.1.4. コントロールプレーン

コントロールプレーンは、サービスが相互に作用する場所です。このゾーンのネットワークは、設定パラメーター、ユーザー名、パスワードなどの機密データを伝送します。コマンドおよびコントロールのトラフィックは通常このゾーンに存在するため、厳しい整合性要件が必要となります。このゾーンへのアクセスは厳しく制限され、監視される必要があります。同時に、このゾーンでは、本ガイドに記載されているセキュリティーのグッドプラクティスをすべて採用する必要があります。

ほとんどのデプロイメントでは、このゾーンは信頼されていると見なされます。しかし、OpenStack の導入を考えると、このゾーンと他のゾーンを橋渡しするシステムが多く、このゾーンに置ける信頼度が低下する可能性があります。

1.2.1.5. Management ネットワーク

Management ネットワークは、システムの管理、監視、バックアップに使用されますが、OpenStack の API や制御インターフェイスはホストされない場所です。この場所は、オンプレミスまたはプライベートの Red Hat OpenStack Platform のデプロイメントに使用される PXE ネットワークを配置する場所で、director および compute、storage、management ノードのハードウェア管理インターフェイス、ネットワーク機器、基本的なオペレーティングシステムのアクセスを含みます。

1.3. セキュリティゾーンの接続

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

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

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

1.4. 脅威の分類、アクター、および攻撃ベクター

パブリック、プライベート、ハイブリッドを問わず、ほとんどのタイプのクラウドデプロイメントは、何らかの形で攻撃を受けます。このセクションでは、攻撃者を分類し、各セキュリティーゾーンで起こりうる攻撃の種類をまとめています。

1.4.1. 脅威アクター

脅威アクターは、防御を試みる可能性のある敵のクラスを指す抽象的な方法です。アクターの能力が高いほど、攻撃の軽減と防止を成功させるために必要なセキュリティー制御が厳しくなります。セキュリティーは、要件に基づいて、利便性、防御、およびコストのバランスを取ることです。場合によっては、ここで説明したすべての脅威主体に対してクラウドのデプロイメントを保護することができないこともあります。OpenStack クラウドをデプロイする場合は、デプロイメントと使用方法のバランスを判断する必要があります。

リスク評価の一環として、保存するデータの種類やアクセス可能なリソースも考慮する必要があります。これは、特定のアクターにも影響するためです。しかし、お客様のデータが脅威アクターにとって魅力的でなくても、ボットネットに参加したり、不正な暗号通貨のマイニングを実行したりと、単純にお客様のコンピューティングリソースに惹かれる可能性があります。

  • ネーションステートアクター - これは最も有能な敵です。国民国家の攻撃者は、ターゲットに対して莫大なリソースをもたらす可能性があります。彼らは他のどの攻撃者よりも優れた能力を持っています。人間と技術の両方で非常に厳格な管理が行われていなければ、これらの攻撃者から身を守ることは非常に困難です。
  • 深刻な組織犯罪 - このクラスは、非常に有能で経済的に主導された攻撃者のグループを説明します。彼らは、社内のエクスプロイト開発とターゲット研究に資金を提供することができます。近年、大規模なサイバー犯罪企業である Russian Business Network などの組織の台頭により、サイバー攻撃がどのように商品になったかが実証されています。産業スパイは、深刻な組織犯罪グループに分類されます。
  • 非常に有能なグループ - これは、通常は商業的には資金提供されていませんが、サービスプロバイダーやクラウドオペレーターに重大な脅威を招く可能性がる「ハクティビスト」タイプの組織を指します。
  • 一人で行動するやる気のある個人 - この攻撃者は、不正または悪意のある従業員、不満を持った顧客、小規模な産業スパイなど、さまざまな形で登場します。
  • 幼稚なクラッカー - この攻撃者は特定の組織をターゲットとしませんが、自動化された脆弱性スキャンと不正使用を実行します。多くの場合、これらは厄介なものにすぎませんが、これらの攻撃者の 1 人による侵害は、組織の評判に対する大きなリスクです。

次の方法は、上記で特定されたリスクの一部を軽減するのに役立ちます。

  • セキュリティー更新 - ネットワーク、ストレージ、サーバーハードウェアなど、基礎となる物理インフラストラクチャーのエンドツーエンドのセキュリティーポジションを考慮する必要があります。このようなシステムには、独自のセキュリティー強化プラクティスが必要です。Red Hat OpenStack Platform のデプロイメントでは、セキュリティーアップデートを定期的にテストしてデプロイする計画を立てる必要があります。
  • アクセス管理 - システムへのアクセスを個人に許可する際には、最小特権の原則 を適用し、実際に必要な粒度のシステム特権のみを許可する必要があります。AAA (access、authorization、および accounting) という手法を用いて、このポリシーを実施することができます。このアプローチは、システム管理者からの悪意のあるアクターと誤字エラーのリスクを軽減するのに役立ちます。
  • インサイダーの管理 - ロールベースのアクセス制御 (最低限必要なアクセス) を慎重に割り当て、内部インターフェースで暗号化を使用し、認証/認可セキュリティー (集中管理など) を使用することで、悪意のあるインサイダーの脅威を軽減できます。また、職務の分離や不規則な職務のローテーションなど、技術以外の追加オプションを検討することもできます。

1.4.1.1. アウトバウンド攻撃と風評被害の危険

クラウドデプロイメントでは、アウトバウンドの不正使用の可能性を慎重に検討する必要があります。クラウドデプロイメントでは、多くのリソースが利用できる傾向にあります。ハッキングや不正を行う従業員などによる権限のあるアクセスによってクラウド内に存在感を示した攻撃者は、悪意のある目的のためにこれらのリソースを使用することができます。Compute サービスを備えたクラウドは、DDoS やブルートフォースエンジンに最適です。特にパブリッククラウドでは、ユーザーが責任を負うことがほとんどできず、アウトバウンド攻撃のために多数の使い捨てインスタンスをすぐに立ち上げることができるため、この問題は切実です。防止策としては、出口のセキュリティーグループ、トラフィック検査、侵入検知システム、お客様への教育啓発、詐欺不正行為の緩和策などがあります。インターネットなどのパブリックネットワークからアクセスできる、またはパブリックネットワークにアクセスできる環境では、理想的にアウトバウンドの不正使用を検出し、またそれに対処するためのプロセスとインフラストラクチャーを整備する必要があります。

1.5. ソフトウェアのサポート

Red Hat のソリューションスタック全体を支えているのは、安全なソフトウェアのサプライチェーンです。Red Hat のセキュリティー戦略の要であるこの戦略的に重要な一連の実践と手順の目標は、セキュリティーが前もって組み込まれ、長期的にサポートされるソリューションを提供することです。Red Hat の具体的な取り組みは以下の通りです。

  • アップストリームの関係とコミュニティーの関係を維持することで、最初からセキュリティーに重点を合わせることができます。
  • セキュリティーおよびパフォーマンス追跡レコードに基づいてパッケージを選択して設定します。
  • (アップストリームビルドを受け入れる代わりに) 関連付けられたソースコードからバイナリーをビルドします。
  • 検査および品質保証ツールのスイートを適用して、潜在的なセキュリティー問題やリグレッションを防ぎます。
  • リリースされたすべてのパッケージにデジタル署名し、暗号化で認証されたディストリビューションチャンネルで配布します。
  • パッチと更新を配信するための単一の統合メカニズムを提供します。また、OpenStack の基盤となる Red Hat Enterprise Linux と KVM コンポーネントも Common Criteria の認証を受けています。これは、サードパーティー監査人が実際にサイトを訪問し、サプライチェーンや開発などのグッドプラクティスを遵守しているかどうかをスタッフにインタビューするというものです。

さらに、Red Hat は、製品に対して脅威と脆弱性を分析する専用のセキュリティーチームを維持し、カスタマーポータルから適切なアドバイスと更新を提供します。このチームは、ほとんどが理論上の問題である問題とは対照的に、どの問題が重要であるかを決定します。Red Hat Product Security チームは専門知識を保ち、弊社のサブスクリプション製品に関連するアップストリームのコミュニティーへの大規模な貢献を行います。プロセスの重要な部分である RedHat Security アドバイザリーは、脆弱性が最初に公開された日に頻繁に配布されるパッチとともに、Red Hat ソリューションに影響を与えるセキュリティーの欠陥を事前に通知します。

1.6. システムドキュメント

1.6.1. システムロールと種類

一般的に OpenStack のインストールを構成するノードには、大きく分けて 2 つのタイプがあります。

  • インフラストラクチャーノード- OpenStack API プロバイダー (neutron など)、メッセージキューイングサービス、ストレージ管理、モニターリング、ネットワークなど、クラウドの運用やプロビジョニングをサポートするために必要なクラウド関連サービスを実行します。
  • コンピュート、ストレージ、またはその他のリソースノード - クラウド上で動作するインスタンスにコンピュートとストレージの容量を提供します。

1.6.2. システムインベントリー

ドキュメントは、OpenStack 環境の一般的な説明を提供し、使用されているすべてのシステム (たとえば、本番、開発、またはテスト) をカバーする必要があります。システムコンポーネント、ネットワーク、サービス、およびソフトウェアを文書化することは、多くの場合、セキュリティーに関する懸念事項、攻撃ベクトル、および考えられるセキュリティーゾーン障害点を重視するために必要な全体像を提供します。システムインベントリーでは、従来の IT 環境では永続的なリソースであった仮想マシンや仮想ディスクボリュームなどの一時的なリソースを捕捉することが必要になる場合があります。

1.6.3. ハードウェアインベントリー

文書化に関する厳格なコンプライアンス要件がないクラウドでは、構成管理データベース (CMDB) の導入が有効です。CMDB は通常、ハードウェアの資産追跡と全体的なライフサイクル管理のために使用されます。CMDB を活用することで、企業はコンピュートノード、ストレージノード、ネットワークデバイスなどのクラウドインフラストラクチャーハードウェアを迅速に特定することができます。CMDB は、ネットワーク上に存在する資産の中で、メンテナンスが不十分であったり、保護が不十分であったり、移動して忘れ去られていたりすることで脆弱性を持つ可能性のある資産を特定するのに役立ちます。OpenStack のプロビジョニングシステムは、基盤となるハードウェアが必要なオートディスカバリー機能をサポートしていれば、いくつかの基本的な CMDB 機能を提供することができます。

1.6.4. ソフトウェアインベントリー

ハードウェアと同様に、OpenStack デプロイメント内のすべてのソフトウェアコンポーネントを文書化する必要があります。以下に例を示します。

  • MySQL や mongoDB などのシステムデータベース
  • Identity や Compute などの OpenStack ソフトウェアコンポーネント
  • ロードバランサー、リバースプロキシー、DNS、DHCP サービスなどのサポートコンポーネント: ソフトウェアコンポーネントの権威あるリストは、ソフトウェアのライブラリー、アプリケーション、クラスにおける侵害や脆弱性の影響を評価する際に重要となる場合があります。

1.6.5. ネットワークトポロジー

ネットワークトポロジーは、セキュリティーゾーン間のデータフローと橋渡しの場所を明確に示すハイライトを提供する必要があります。ネットワークの入口と出口のポイントは、OpenStack の論理システムの境界とともに特定する必要があります。システムを完全に視覚的に含めるには、複数の図が必要になる場合があります。ネットワークトポロジーのドキュメントには、システムによってプロジェクトに代わって作成された仮想ネットワーク、OpenStack によって作成された仮想マシンインスタンスおよびゲートウェイ、さらにノードと外部ネットワーク間の通信に使用される物理ネットワークおよびオーバーレイネットワークを含める必要があります。

1.6.6. サービス、プロトコル、およびポート

組織の資産に関する情報を知ることは、一般的にはグッドプラクティスです。資産表は、セキュリティー要件の検証を支援し、ファイアウォール構成、サービスポートの競合、セキュリティー修復領域、コンプライアンスなどの標準的なセキュリティーコンポーネントの維持に役立ちます。さらに、このテーブルは、OpenStack コンポーネント間の関係を特定するのにも役立ちます。テーブルには以下のようなものがあります。

  • OpenStack のデプロイメントで使用されているサービス、プロトコル、およびポート。
  • クラウドインフラストラクチャー内で動作するすべてのサービスの概要。

OpenStack のデプロイメントでは、この情報を記録しておくことが推奨されます。director のデプロイメントに必要なポートの一覧は、「 https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/15/html-single/firewall_rules_for_red_hat_openstack_platform/ 」を参照してください。

ポートの設定は、各サービスのヒートテンプレートにも含まれています。この情報は、以下のコマンドで抽出できます。 

find -L /usr/share/openstack-tripleo-heat-templates/ -type f | while read f;do if `grep -q firewall_rules $f`;then echo -e "\n $f " ; grep firewall_rules "$f" -A10;fi; done

第2章 暗号化および鍵管理

デバイス間通信は、セキュリティー上の重大な問題です。Heartbleed などの重大な脆弱性や、BEAST や CRIME などのより高度な攻撃に見られるように、ネットワーク上での安全な通信手段はますます重要になっています。しかし、暗号化は、より大きなセキュリティー戦略の一部に過ぎません。エンドポイントが侵害されると、攻撃者は使用されている暗号を解読する必要がなくなり、システムで処理されるメッセージを閲覧したり操作したりすることができるようになります。

本章では、TLS (Transport Layer Security) を設定して社内外のリソースを保護するための機能を確認し、特に注意すべきシステムのカテゴリを紹介します。

OpenStack のコンポーネントは、様々なプロトコルを使用して相互に通信しますが、その通信には機密データが含まれる場合があります。攻撃者は、機密情報にアクセスするために、チャネルを盗聴しようとするかもしれません。そのため、すべてのコンポーネントが安全な通信プロトコルを使用して相互に通信することが重要です。

2.1. TLS と SSL の概要

OpenStack の導入において、ネットワークトラフィックの機密性や完全性を保証するためのセキュリティー要件が必要となる場合があります。一般的には、TLS プロトコルなどの暗号化手段を用いて設定します。一般的な導入では、パブリックネットワークを介して送信されるすべてのトラフィックをセキュリティーで強化する必要がありますが、セキュリティーのグッドプラクティスでは、内部トラフィックもセキュリティーで保護されなければならないと考えられています。セキュリティーゾーンの分離に頼った保護では不十分です。攻撃者がハイパーバイザーやホストのリソースにアクセスしたり、API エンドポイントを侵害したり、その他のサービスにアクセスした場合は、メッセージやコマンドを簡単に注入したりキャプチャしたり、クラウドの管理機能に影響を与えたりすることができないようにする必要があります。

管理ゾーンのサービスやサービス内通信を含め、すべてのゾーンを TLS でセキュリティー強化する必要があります。TLS は、OpenStack サービスへのユーザー通信、および OpenStack サービスとサービスの間で、認証、否認防止、機密性、および完全性を確保するメカニズムを提供します。

SSL (Secure Sockets Layer) プロトコルの脆弱性が公開されているため、SSL よりも TLS 1.2 以上の使用を検討し、旧式のブラウザーやライブラリーとの互換性が必要な場合を除き、すべてのケースで SSL を無効にしてください。

2.1.1. 公開鍵インフラストラクチャー

PKI (Public Key Infrastructure) とは、データや認証を保護するための暗号化アルゴリズム、暗号モード、プロトコルを提供するためのフレームワークです。これは、当事者の身元を確認しながら、トラフィックを確実に暗号化して送信するための一連のシステムとプロセスで構成されています。ここで説明する PKI プロファイルは、PKIX ワーキンググループによって開発された Internet Engineering Task Force (IETF) の Public Key Infrastructure (PKIX) プロファイルです。PKI の中核となるコンポーネントは以下の通りです。

  • デジタル証明書 - 署名入り公開鍵証明書は、エンティティーの検証可能なデータ、その公開鍵、およびその他の属性を持つデータ構造です。これらの証明書は、認証局 (CA) によって発行されます。証明書は信頼できる CA によって署名されているため、一度検証されれば、エンティティーに関連付けられた公開鍵は、当該エンティティーに関連付けられていることが保証されます。これらの証明書を定義するための最も一般的な規格は、X.509 規格です。現在の標準である X.509 v3 は、RFC5280 に詳細が記載されており、RFC6818 で更新されています。証明書は、オンラインエンティティーのアイデンティティを証明する仕組みとして、CA によって発行されます。CA は、証明書からメッセージダイジェストを作成し、そのダイジェストを自分の秘密鍵で暗号化することで、証明書にデジタル署名します。
  • エンドエンティティー - 証明書の対象となるユーザー、プロセス、またはシステム。エンドエンティティーは、その証明書要求を登録機関 (RA) に送り、承認を得ます。承認された場合、RA は要求を認証局 (CA) に転送します。認証局はリクエストを検証し、情報が正しければ証明書を生成して署名します。この署名された証明書は、証明書レポジトリに送られます。
  • 依拠当事者 - 証明書に記載されている公開鍵を参照して検証可能なデジタル署名された証明書を受け取ったエンドポイント。依拠当事者は、チェーン上の証明書を検証し、CRL に存在しないことを確認し、また、証明書の有効期限を検証できる立場にある必要があります。
  • 認証局 (CA) - CA は、認証ポリシー、管理処理、および証明書の発行において、エンドパーティと、証明書に依存するパーティの両方から信頼されるエンティティーです。
  • RA (REgistration Authority): CA が特定の管理機能を委譲するオプションのシステムです。これには、CA が証明書を発行する前の、エンドエンティティーの認証などの機能が含まれます。
  • 証明書失効リスト (Certificate Revocation List、CRL): 証明書失効リスト (CRL) は、失効した証明書シリアル番号の一覧です。これらの証明書を表示するエンティティーは、PKI モデルでは信頼できません。たとえば、鍵が不正アクセスし、CA 侵害などの理由によって失効が発生することがあります。
  • CRL 発行者: CA が証明書失効リストの公開を委譲するオプションのシステム。
  • 証明書リポジトリー: エンドエンティティー証明書および証明書失効リストが保存され、クエリーされる場所 (証明書バンドルと呼ばれることもあります)。

API エンドポイント用の TLS の使用を含め、セキュリティーで公開鍵インフラストラクチャー (PKI) を使用してすべてのサービスを強化することが強く推奨されます。これらの問題すべてを解決するには、暗号化またはメッセージの署名だけでは不可能です。さらに、ホスト自体は強化され、ポリシー、名前空間、およびその他のコントロールを実装して、プライベートの認証情報および鍵を保護する必要があります。ただし、キー管理および保護の課題は、これらの制御の必要性が低くなったり、それらの重要度が低下することはありません。

2.1.2. 認証局

多くの組織には、独自の認証局 (CA)、証明書ポリシー、および内部 OpenStack ユーザーまたはサービスの証明書を発行するのに使用する公開鍵インフラストラクチャーが確立されています。パブリックセキュリティーゾーンがインターネットに接続される組織には、一般に認識されるパブリック CA によって署名された証明書が必要です。管理ネットワークを介した暗号化通信には、パブリック CA を使用しないことが推奨されます。その代わりに、ほとんどのデプロイメントでは独自の内部 CA をデプロイすることが推奨されます。

注記

TLS の効果的な使用では、DNS のドメインまたはサブドメインが付与されたデプロイメントに依存します。これはワイルドカードまたは内部 CA のいずれかで使用できる、または一連の特定証明書の問題です。TLS 証明書を効果的に検証できるようにするには、プラットフォームサービスへのアクセスは、これらの DNS レコードを通じて行う必要があります。

OpenStack クラウドアーキテクトは、内部システムおよび顧客がアクセスするサービス用に別の PKI デプロイメントを使用することを検討することを推奨します。これにより、クラウドデプロイヤーが PKI インフラストラクチャーの制御を維持でき、内部システムの証明書の要求、署名、デプロイが容易になります。高度な設定では、異なるセキュリティーゾーンに別の PKI デプロイメントを使用する場合があります。これにより、OpenStack のオペレーターは環境の暗号化の分離を維持でき、発行された証明書が別の方法で認識されないようにします。

インターネット向けのクラウドエンドポイント (またはお客様が標準オペレーティングシステムが提供する証明書バンドル以外のインストールを期待しない) で TLS をサポートするために使用される証明書は、オペレーティングシステムの証明書バンドルにインストールされている認証局を使用してプロビジョニングする必要があります。

注記

証明書の作成および署名に関する管理、ポリシー、および技術的な課題があります。これは、クラウドアーキテクトまたはオペレーターが推奨するガイダンスに加えて、業界のリーダーとベンダーのアドバイスを求めたい領域です。

2.1.3. director を使用した暗号化の設定

デフォルトでは、オーバークラウドはサービスに暗号化されていないエンドポイントを使用します。これは、オーバークラウドの設定に、パブリック API エンドポイントに SSL/TLS を有効化するための追加の環境ファイルが必要であることを意味します。『オーバークラウドの 高度なカスタマイズ』 では、SSL/TLS 証明書を設定して、オーバークラウドの作成プロセスの一部として追加する方法を説明します。https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/15/html/advanced_overcloud_customization/sect-enabling_ssltls_on_the_overcloud

2.1.4. TLS ライブラリー

OpenStack エコシステム内の一部のコンポーネント、サービス、およびアプリケーションは TLS ライブラリーを使用するように設定できます。OpenStack 内の TLS および HTTP サービスは、通常、FIPS 140-2 で検証されているモジュールが含まれる OpenSSL を使用して実装されます。ただし、各アプリケーションまたはサービスは、OpenSSL ライブラリーを使用する方法においても脆弱点が発生することを考慮してください。

2.1.5. TLS 1.0 が非推奨に

重要

FedRAMP 認可システムは、TLS 1.0 から離れる必要があります。推奨されるレベルは 1.2 で、幅広い互換性が必要な場合に 1.1 を使用できます。詳細は、https://www.fedramp.gov/assets/resources/documents/CSP_TLS_Requirements.pdf を参照してください。

Red Hat OpenStack Platform 13 デプロイメントでは、HAProxy によって TLS 1.0 接続が許可されません。これにより、TLS 対応の API の TLS 接続を処理します。これは、no-tlsv10 オプションで実装されます。InternalTLS が有効な HA デプロイメントでは、コントローラープレーン上のノード間のトラフィックも暗号化されます。これには、RabbitMQ、MariaDB、Redis などがあります。MariaDB と Redis の TLS1.0 が非推奨になり、RabbitMQ の非推奨化がアップストリームからバックポートされることが予想されます。

2.1.5.1. TLS 1.0 が使用されているかどうかを確認する

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

注記

実稼働以外のシステムから cipherscan を実行すると、初回実行時に追加の依存関係をインストールする場合があるためです。 

$ ./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

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

2.1.6. 暗号化アルゴリズム、暗号モード、およびプロトコル

TLS 1.2 のみを使用することを検討してください。TLS 1.0 や 1.1 などのその他のバージョンは複数の攻撃に対して脆弱であり、多くの政府機関や規制対象者によって表現的に禁止されています。お使いの環境で TLS 1.0 を無効にする必要があります。TLS 1.1 は幅広いクライアント互換性に使用される場合がありますが、このプロトコルを有効にする際には注意が必要です。互換性要件が必須で、関係するリスクを認識している場合は、TLS バージョン 1.1 を有効にします。すべてのバージョンの SSL (TLS への前提条件) は、複数のパブリック脆弱性により使用すべきではありません。

TLS 1.2 を使用し、クライアントとサーバーの両方を制御する場合、暗号スイートは ECDHE-ECDSA-AES256-GCM-SHA384 に制限される必要があります。エンドポイントの両方を制御しておらず、TLS 1.1 または 1.2 を使用している場合、より一般的な HIGH:!aNULL:!eNULL:!DES:!3DES:!SSLv3:!TLSv1:!CAMELLIA は、妥当な暗号選択です。

注記

本ガイドは暗号化の参照として意図されておらず、OpenStack サービスで有効化または無効化する必要のある特定のアルゴリズムまたは暗号モードに関する規定はありません。

2.2. TLS プロキシーおよび HTTP サービス

OpenStack のエンドポイントは、パブリックネットワーク上のエンドユーザーや管理ネットワーク上の他の OpenStack サービスの両方に API を提供する HTTP サービスです。現在、TLS を使用して外部要求を暗号化できます。Red Hat OpenStack Platform でこれを設定するには、HAproxy の背後にある API サービスをデプロイすることができます。これは、TLS セッションを確立および終了できます。

ソフトウェアの終了でパフォーマンスが不十分な場合には、ハードウェアアクセラレーターは代替オプションとして使用したものになるかもしれません。このアプローチにはプラットフォーム上で追加の設定が必要で、すべてのハードウェアロードバランサーが Red Hat OpenStack Platform と互換性がある訳ではありません。選択した TLS プロキシーによって処理される要求のサイズに留意する必要があります。

2.2.1. Perect Forward Secrecy

perfect forward secrecy の TLC 設定では、キーサイズ、セッション ID、およびセッションチケットに関する注意を払ってプランニングする必要があります。さらに、マルチサーバーデプロイメントの場合、共有状態は重要な考慮事項です。実際のデプロイメントでは、パフォーマンスを向上させるためにこの機能を有効にすることを検討してください。これはセキュリティーが強化された方法で行うことができますが、キー管理に関して特別な考慮が必要になります。このような構成については、本書では扱いません。

2.3. Barbican を使用したシークレットの管理

OpenStack Key Manager (barbican) は Red Hat OpenStack Platform のシークレットマネージャーです。barbican API とコマンドラインを使用して、OpenStack サービスの使用する証明書、キー、パスワードを一元管理することができます。barbican は現在以下のユースケースをサポートします。

  • 対称暗号鍵: Block Storage (cinder) ボリュームの暗号化、一時ディスク暗号化、および Object Storage (swift) オブジェクトの暗号化に使用されます。
  • 非対称鍵および証明書: glance イメージの署名および検証、Octavia TLS 負荷分散

本リリースでは、barbican は cinder、swift、Octavia、および Compute (nova) コンポーネントとの統合を提供します。たとえば、以下のユースケースに barbican を使用できます。

  • 暗号化されたボリュームのサポート: barbican を使用して cinder 暗号化キーを管理できます。この設定は、LUKS を使用して、インスタンスに接続されているディスク (ブートディスクを含む) を暗号化します。キー管理の機能は、ユーザーに透過的に行われます。
  • Glance Image Signing: Image Service (glance) を設定して、アップロードしたイメージが改ざんされていないことを検証することができます。イメージは、barbican に保管されているキーで最初に署名され、毎回そのイメージを使用する前に検証されます。

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

第3章 アイデンティティーおよびアクセス管理

3.1. アイデンティティー

このセクションには、ID に関する概念情報が含まれています。

3.1.1. 認証

認証は、あらゆる実際の OpenStack デプロイメントの不可欠な要素です。システム設計のこの側面に注意を払う必要があります。このトピックの完全な取り扱いについては、本書では扱いませんが、以下の主要なトピックについて記載します。

最も基本的な認証は、アイデンティティーを確認するプロセスです。システムにログインする際に、使い慣れている例は、ユーザー名とパスワードを提供します。

OpenStack Identity サービス (keystone) は、ユーザー名とパスワード、LDAP、およびその他の外部認証方法など、複数の認証メソッドをサポートしています。認証に成功すると、Identity サービスは、後続のサービスリクエストに使用される承認トークンを提供します。

TLS (Transport Layer Security) は、X.509 証明書を使用してサービスとユーザーの間の認証を提供します。TLS のデフォルトモードはサーバー側の認証のみですが、米国の政府標準で義務付けられているため、クライアント認証に証明書を使用することを検討する必要があります。

3.1.1.1. 無効なログイン試行

Identity Service (keystone) は、ログイン試行が繰り返し失敗した後にアカウントへのアクセスを制限する方法を提供していません。ログイン試行の失敗のパターンは、一般的にブルートフォース攻撃の指標です。このタイプの攻撃は、パブリッククラウドのデプロイメントでさらに複雑になります。設定された回数のログイン試行の失敗後にアカウントをブロックする外部認証システムを使用することで、これを軽減するのに役立ちます。その後、アカウントは他の管理者の介入でのみロックを解除できます。

検出技術を使用して、破損を軽減することもできます。検出では、アクセス制御ログの頻繁にレビューが行われ、承認されていないアカウントへのアクセス試行を特定します。修復には、ユーザーのパスワードの強度の確認やファイアウォールルールによる攻撃のネットワークソースのブロックなどが含まれます。接続の数を制限する keystone サーバーにファイアウォールルールを追加することができます。これにより、攻撃の効果を減らすことができます。

さらに、ログイン時間や疑わしいアクションについてアカウントアクティビティーを調べたり、アカウントを無効にするなどの修正措置を取ると役に立ちます。

3.1.1.2. マルチファクター認証

特権ユーザーアカウントへのネットワークアクセスに多要素認証を採用します。Identity サービスは、この機能を提供できる外部認証サービスと統合できます。たとえば、keystone は、Active Directory、Red Hat Identity Manager、Free IPA、または汎用 LDAP サーバーと統合でき、これらのいずれかによって多要素認証が適用されます。

この推奨事項は、パスワードを危険にさらす可能性のあるさまざまなブルートフォース、ソーシャルエンジニアリング、およびスピアフィッシングと大量フィッシング攻撃の両方を軽減するのに役立ちます。Red Hat Identity Management と統合するデプロイメントについては、『 Identity Management の計画』を参照してください。

3.2. 承認

Identity サービスは、グループおよびロールの概念をサポートします。ユーザーはグループに属している間にグループに属します。OpenStack サービスは、サービスへのアクセスを試みるユーザーのロールを参照します。OpenStack ポリシーエンフォーサーは、各リソースに関連付けられたポリシールールを考慮に入れて、次にユーザーのグループ/ロールと関連付けて、要求されたリソースにアクセスできるかどうかを判別します。

3.2.1. Formal Access Control Policies を確立

ロール、グループ、ユーザーを設定する前に、OpenStack インストールに必要なアクセス制御ポリシーを文書化する必要があります。ポリシーは、組織の規制要件または法的要件に準拠する必要があります。アクセス制御設定に対する今後の変更は、フォームポリシーを使用して一貫して実行するはずです。このポリシーには、アカウントの作成、削除、無効化、有効化、アカウントへの権限の割り当てを行う条件およびプロセスが含まれます。ポリシーを定期的に確認し、承認済みのポリシーで設定が準拠していることを確認します。

3.2.2. サービス承認

クラウド管理者は、各サービスの admin ロールを持つユーザーを定義する必要があります。このサービスアカウントは、ユーザーを認証するための承認をサービスに提供します。

Compute および Object Storage サービスは、Identity サービスを使用して認証情報を保存するように設定できます。Identity サービスは、TLS のクライアント認証をサポートしますが、これは有効にされる可能性があります。TLS クライアント認証は、ユーザー名とパスワードに加えて、ユーザー ID の信頼性を向上させる、ユーザー名とパスワードの他に追加の認証要素を提供します。ユーザー名とパスワードが侵害されると、承認されていないアクセスのリスクが軽減されます。ただし、すべてのデプロイメントで実行できないユーザーに証明書を発行するのに、追加の管理オーバーヘッドやコストが発生します。

クラウド管理者は、機密の設定ファイルを承認されていない変更から保護する必要があります。これは、/var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf ファイルや X.509 証明書など、SELinux などの強制アクセス制御フレームワークを使用して設定できます。

TLS を使用したクライアント認証では、証明書がサービスに発行される必要があります。これらの証明書は、外部または内部の認証局で署名できます。OpenStack サービスは、デフォルトで信頼できる CA に対して証明書署名の有効性をチェックし、署名が有効で CA が信頼されていない場合に接続は失敗します。クラウドデプロイヤーは自己署名証明書を使用できます。この場合、有効性チェックを無効にするか、証明書が信頼できるものとマークされる必要があります。自己署名証明書の検証を無効にするには、/etc/nova/api.paste.ini ファイルの [filter:authtoken] セクションに insecure=False を設定します。この設定は、他のコンポーネントの証明書も無効になります。コンテナー化されたサービスでは、ファイルパスが異なる場合があります。

3.2.3. 管理ユーザーアカウント

管理ユーザーアカウントは、keystone と、証明書などの 2 要素認証をサポートする外部認証サービスの両方を使用して認証する必要があります。外部認証サービスには、Red Hat Identity Management または Microsoft Active Directory を含めることができます。これらのサービスとの統合については、https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/15/html-single/integrate_with_identity_service/ に記載されています。このアプローチは、侵害される可能性のあるパスワードによるリスクを軽減するのに役立ちます。この推奨事項は、特権アカウントへのネットワークアクセスに多要素認証を使用する際の NIST 800-53 IA-2(1) ガイダンスに準拠しています。

3.2.4. エンドユーザー

Identity サービスは、エンドユーザー認証を直接提供するか、または外部の認証方法を使用して、組織のセキュリティーポリシーおよび要件に準拠するように設定できます。

3.3. ポリシー

各 OpenStack サービスには、アクセスポリシーで管理されるリソースが含まれています。たとえば、リソースには以下の関数が含まれる場合があります。

  • インスタンスを作成して起動するパーミッション
  • インスタンスにボリュームを接続する機能

Red Hat OpenStack Platform (RHOSP) 管理者は、カスタムポリシーを作成して、さまざまなアクセスレベルで新しいロールを導入することや、既存のロールのデフォルト動作を変更することが必要になる場合があります。また、変更後に API アクセスポリシーを検証し、これらのポリシーが変更されない場合にデバッグする機能もあります。プロダクションデプロイメント以外の検証およびデバッグポリシー。構文エラーが発生すると、ダウンタイムが発生し、誤って認証が適用されないとセキュリティーやユーザビリティーに悪影響を及ぼす可能性があります。

3.3.1. 既存のポリシーの確認

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

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

  • Red Hat OpenStack Platform はコンテナー化されています。

    • サービスコンテナーからポリシーファイルを確認する場合は、ポリシーファイル (ある場合) は従来のパスにあります。

      /etc/$service/policy.json

    • サービスコンテナーの外部からそれらを表示する場合は、以下のパスに配置されます。

      /var/lib/config-data/puppet-generated/$service/etc/$service/policy.json

  • 各サービスには、コードで提供されるデフォルトのポリシーがあります。これは、手動で作成した場合にのみ利用できるファイル、または oslopolicy ツールで生成された場合に限ります。ポリシーファイルを生成するには、以下の例のように、コンテナーから oslopolicy-policy-generator を使用します。 

    podman exec -it keystone oslopolicy-policy-generator --namespace keystone

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

3.3.2. サービスポリシーについて

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

  • "context_is_admin": "role:admin"

    ターゲットの後に rule:context_is_admin が表示されたら、そのアクションを許可する前にユーザーが管理コンテキストで動作していることを確認します。

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

    ターゲットの後に admin_or_owner が表示されると、ポリシーはそのユーザーが admin であるか、またはプロジェクト ID がターゲットオブジェクトの独自のプロジェクト ID と一致することを確認してからそのアクションを許可します。

  • "admin_api": "is_admin:True

    ターゲットの後に admin_api が表示されると、ポリシーはそのアクションを許可する前にそのユーザーが admin であることをチェックします。

3.3.3. ポリシー構文

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

"identity:create_user": "rule:admin_required"

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

  • !: このアクションを実行するユーザー (admin を含む) はありません。
  • @ および "": 任意のユーザーがこのアクションを実行できます。
  • not、and、or: 標準の Operator 機能を利用できます。

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

"identity:create_user": "!"

3.3.4. アクセス制御でのポリシーファイルの使用

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

注記
  • ステージング環境でポリシーファイルへの変更をよくテストしてから、それらを実稼働環境で実装する必要があります。
  • アクセス制御ポリシーへの変更が、リソースのセキュリティーを意図せずに脆弱化しないことを確認する必要があります。また、policy.json ファイルへの変更はすぐに有効であり、サービスの再起動は必要ありません。

3.3.4.1. 例: パワーユーザーロールの作成

keystone ロールのパーミッションをカスタマイズするには、サービスの policy.json ファイルを更新します。これは、ユーザーのクラスに割り当てるパーミッションをより詳細に定義できることを意味します。以下の例では、以下の特権を使用してデプロイメントの power user ロールを作成します。

  • インスタンスを起動するには、以下のコマンドを実行します。
  • インスタンスを停止します。
  • インスタンスに割り当てられているボリュームを管理します。

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

  • インスタンスを起動する: "os_compute_api:servers:start": "role:PowerUsers"
  • インスタンスを停止する: "os_compute_api:servers:stop": "role:PowerUsers"
  • 特定のボリュームを使用するようにインスタンスを設定する: "os_compute_api:servers:create:attach_volume": "role:PowerUsers"
  • インスタンスに割り当てられているボリュームを一覧表示する: "os_compute_api:os-volumes-attachments:index": "role:PowerUsers"
  • ボリュームを割り当てる: "os_compute_api:os-volumes-attachments:create": "role:PowerUsers"
  • 割り当てられたボリュームの詳細を表示する: "os_compute_api:os-volumes-attachments:show": "role:PowerUsers"
  • インスタンスに割り当てられているボリュームを変更する: "os_compute_api:os-volumes-attachments:update": "role:PowerUsers"
  • インスタンスに割り当てられているボリュームを削除する: "os_compute_api:os-volumes-attachments:delete": "role:PowerUsers"
注記

policy.json ファイルを変更すると、デフォルトのポリシーを上書きします。その結果、PowerUsers のメンバーは、これらのアクションを実行できる唯一のユーザーになります。admin ユーザーがこれらのパーミッションを保持できるようにするには、admin_or_power_user. のルールを作成できます。また、基本的な条件ロジックを使用して role:PowerUsers or role:Admin を定義することもできます。

  1. コマンドラインセッションで keystone v3 API を使用するには、source コマンドで v3 エンドポイントおよび設定を定義する rc ファイルを読み込みます。 

    OS_AUTH_URL=http://controller-hostname.lab.local:5000/v3
OS_USERNAME=username
OS_PASSWORD=password
OS_USER_DOMAIN_NAME=Default
OS_PROJECT_DOMAIN_NAME=Default
OS_PROJECT_NAME=project-name
OS_IDENTITY_API_VERSION=3

  2. カスタム keystone ロールを作成します。 

    $ openstack role create PowerUsers
+-----------+----------------------------------+
| Field     | Value                            |
+-----------+----------------------------------+
| domain_id | None                             |
| id        | 7061a395af43455e9057ab631ad49449 |
| name      | PowerUsers                      |
+-----------+----------------------------------+

  3. 既存のユーザーをロールに追加し、ロールをプロジェクトに割り当てます。 

    $ openstack role add --project [PROJECT_NAME] --user [USER_ID] [PowerUsers-ROLE_ID]
    注記

    ロールの割り当ては、1 つのプロジェクトのみとペアになります。つまり、ロールをユーザーに割り当てると、ターゲットプロジェクトも同時に定義します。ユーザーが同じロールを受信し、別のプロジェクトを対象にする場合は、ロールを別々に割り当てる必要がありますが、別のプロジェクトが対象となります。

  4. デフォルトの nova ポリシー設定を表示します。 

    $ oslopolicy-policy-generator --namespace nova

  5. 以下のエントリーを /etc/nova/policy.json に追加して、新しい PowerUsers ロールのカスタムパーミッションを作成します。

    注記

    デプロイメント前にポリシーの変更をテストし、想定通りに機能していることを確認します。 

    {
"os_compute_api:servers:start": "role:PowerUsers",
"os_compute_api:servers:stop": "role:PowerUsers",
"os_compute_api:servers:create:attach_volume": "role:PowerUsers",
"os_compute_api:os-volumes-attachments:index": "role:PowerUsers",
"os_compute_api:os-volumes-attachments:create": "role:PowerUsers",
"os_compute_api:os-volumes-attachments:show": "role:PowerUsers",
"os_compute_api:os-volumes-attachments:update": "role:PowerUsers",
"os_compute_api:os-volumes-attachments:delete": "role:PowerUsers"
}

    このファイルを保存すると、変更はすぐに有効になります。PowerUsers keystone ロールに追加したユーザーは、これらの権限を受信します。

3.3.4.2. 例: 属性に基づくアクセスの制限

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"

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

3.3.4.3. ロール割り当ての確認

  1. ロール割り当てのレポートを生成します。 

    openatck role assignment list --names
+---------------+--------------------+-------+----------------------+--------+-----------+
| Role          | User               | Group | Project              | Domain | Inherited |
+---------------+--------------------+-------+----------------------+--------+-----------+
| admin         | glance@Default     |       | services@Default     |        | False     |
| admin         | ceilometer@Default |       | services@Default     |        | False     |
| ResellerAdmin | ceilometer@Default |       | services@Default     |        | False     |
| PowerUsers    | demo-user@Default  |       | demo-project@Default |        | False     |
| admin         | swift@Default      |       | services@Default     |        | False     |
| admin         | aodh@Default       |       | services@Default     |        | False     |
| admin         | neutron@Default    |       | services@Default     |        | False     |
| admin         | nova@Default       |       | services@Default     |        | False     |
| _member_      | demo@Default       |       | demo@Default         |        | False     |
| admin         | cinder@Default     |       | services@Default     |        | False     |
| admin         | admin@Default      |       | admin@Default        |        | False     |
| admin         | gnocchi@Default    |       | services@Default     |        | False     |
+---------------+--------------------+-------+----------------------+--------+-----------

  2. 特定のユーザーのロール割り当てを表示します。 

    $ openstack role assignment list --user demo-user --project demo-project --names
+-------------+----------------+-------+----------------------+--------+-----------+
| Role        | User           | Group | Project              | Domain | Inherited |
+-------------+----------------+-------+----------------------+--------+-----------+
| PowerUsers  | demo-user@Default |       | demo-project@Default |        | False  |
+-------------+----------------+-------+----------------------+--------+-----------+

3.4. トークン

ユーザーが認証されると、OpenStack 環境の認証およびアクセスのためにトークンが生成されます。トークンには変数のライフサイクルを指定できますが、有効期限のデフォルト値は 1 時間です。推奨される期限切れ値は、内部サービスがタスクを完了するのに十分な時間を確保できるように、低い値に設定する必要があります。トークンがタスクが完了する前に期限切れになる場合、クラウドはサービスの提供を応答しなくなるか、または停止する可能性があります。使用中に展開される時間の例としては、Compute サービスがディスクイメージをローカルキャッシュ用にハイパーバイザーに転送するために必要な時間があります。

このトークンは、多くの場合、Identity サービスの応答の大きなコンテキストの構造内で渡されます。これらの応答は、さまざまな OpenStack サービスのカタログも提供します。各サービスは、その名前、内部、admin、およびパブリックアクセスのエンドポイントと共に一覧表示されます。Identity サービスは、トークンの失効をサポートします。トークンを取り消す API として、取り消したトークンや、取り消しされたトークンについてクエリーする個別の OpenStack サービスを一覧表示し、それらをキャッシュから削除し、キャッシュされた取り消したトークンの一覧に同じものを追加します。

サポートされているトークンタイプには、UUID と Hadoop の 2 つのタイプがあります。PKI トークンおよび PKIZ トークンは、Red Hat OpenStack Platform 11 で非推奨となりました。

3.4.1. UUID トークン

UUID トークンは永続トークンであり、長さが 32 バイトで、認証メタデータとともに Identity サービスバックエンドに保存されます。クライアントは検証のために UUID トークンを Identity サービスに渡す必要があります。UUID トークンは、デフォルトのトークンプロバイダーが 1 度でした。

3.4.2. fernet トークン

Fernet トークンがデフォルトのトークンプロバイダーになりました。fernet は、API トークンでの使用に対して明示的に設計されたセキュアなメッセージング形式です。fernet トークンは永続的ではなく (データベースに永続化する必要はありません)、軽量 (180 から 240 バイト)、クラウドの実行に必要な運用のオーバーヘッドを削減します。認証および認可メタデータは、メッセージパックのペイロードにバンドルされます。これは、Fernet トークンとして暗号化され、署名されます (180 から 240 バイトまで)。

UUID、PKI、PKIZ トークンとは異なり、Fernet トークンには永続性は必要ありません。keystone トークンデータベースには、認証の副次的な影響がなくなりました。Fernet トークンの使用時に、トークンデータベースからの期限切れのトークンのプルーニングが不要になりました。Fernet トークンは永続的ではないため、複製する必要はありません。各 keystone ノードが同じリポジトリーを共有している限り、ノード間で Fernet トークンを即時に作成/検証することができます。

PKI トークンおよび PKIZ トークンと比較すると、Fernet トークンのサイズは小さくなり、通常は 250 のバイト制限下に保持されます。PKI および PKIZ トークンの場合、サービスカタログが大きいとトークンの長さが長くなります。このパターンは、暗号化されたペイロードの内容が最小限に保持されるため、Fernet トークンには存在しません。

Hadoop トークンおよびローテーションキーの詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/15/html-single/deploy_fernet_on_the_overcloud/ を参照してください。

3.5. Keystone ドメイン

keystone ドメインは高レベルのセキュリティー境界で、プロジェクト、ユーザーおよびグループを論理的にグループ化します。そのため、keystone ベースのすべてのアイデンティティーコンポーネントを一元管理できます。アカウントドメイン、サーバー、ストレージ、およびその他のリソースの導入により、複数のプロジェクト (以前はテナントと呼ばれていました) に論理的にグループ化され、マスターアカウントのようなコンテナーでグループ化できるようになりました。さらに、アカウントドメイン内で複数のユーザーを管理でき、プロジェクトごとに異なるロールを割り当てることができます。

Identity V3 API は複数のドメインをサポートします。異なるドメインのユーザーは、異なる認証バックエンドで表される場合があります。また、さまざまなサービスリソースにアクセスするためにポリシー定義で使用される単一のロールおよび特権のセットにマップする必要がある異なる属性が存在する可能性があります。

ルールが、プロジェクトに属する admin ユーザーおよびユーザーのみへのアクセスを指定する場合には、マッピングが簡単な場合があります。他のシナリオでは、クラウド管理者はプロジェクトごとにマッピングルーチンを承認する必要がある場合があります。

ドメイン固有の認証ドライバーにより、ドメイン固有の設定ファイルを使用して Identity サービスを複数のドメインに設定できます。ドライバーを有効にし、ドメイン固有の設定ファイルの場所を設定することは、/var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf ファイルの [identity] セクションで行います。以下に例を示します。 

[identity]
domain_specific_drivers_enabled = True
domain_config_dir = /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/

ドメイン固有の設定ファイルのないドメインは、プライマリー /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf ファイルでオプションを使用します。

3.6. アイデンティティサービスとの連携

フェデレーション ID は、ID プロバイダーとサービスプロバイダー (SP) 間の信頼を確立するためのメカニズムです。この場合、サービスプロバイダーは OpenStack クラウドによって提供されるサービスです。

認証および承認サービスの場合、OpenStack アイデンティティーモデルは外部の認証データベースを別の keystone ドメインとみなします。各フェデレーション認証メカニズムは keystone ドメインに関連付けられ、複数の共存ドメインをサポートします。ロールを使用して、外部のドメインのユーザーにクラウドのリソースへのアクセスを許可できます。このアプローチは、ドメイン間のマルチテナントデプロイメントでも機能します。また、このアプローチは、すべての OpenStack ロールを外部認証ユーザーに戻すことができないため、コンポーネントごとのポリシーにも影響を与えます。たとえば、外部認証データベースのユーザーが admin ドメインの admin ユーザーと同様の管理アクセスが必要な場合は、通常は追加の設定や考慮が必要になります。

フェデレーション対応の Identity では、既存の認証情報を使用して、追加の ID を用意したり、複数回ログインしたりせずに、複数の認証クラウドで提供される複数のエンドポイント間で、サーバー、ボリューム、データベースなどのクラウドリソースにアクセスする方法を提供します。認証情報はユーザーの認証プロバイダーによって維持されます。

Identity サービスは、ユーザーの認証情報を SQL データベースに保存したり、LDAP 準拠のディレクトリーサーバーを使用したりできます。Identity データベースは、他の OpenStack サービスが使用するデータベースとは異なる可能性があり、保存された認証情報のリスクが軽減されます。

ユーザー名とパスワードを使用して認証する場合、Identity はパスワードの強度、有効期限、または失敗した認証試行でポリシーを強制しません。より強力なパスワードポリシーを強制する組織は、Identity 拡張機能または外部認証サービスを使用することを検討する必要があります。

LDAP は、Identity 認証を組織の既存のディレクトリーサービスおよびユーザーアカウントの管理プロセスに統合できるようにします。OpenStack の認証および承認ポリシーは、別のサービスに委譲される可能性があります。一般的なユースケースは、プライベートクラウドをデプロイするように組織で、LDAP システムに従業員およびユーザーのデータベースをすでに持つ組織です。これを認証機関として使用すると、Identity サービスへの要求は LDAP システムに委任され、そのポリシーに基づいて承認または拒否されます。認証に成功すると、Identity サービスは、承認されたサービスへのアクセスに使用されるトークンを生成します。

LDAP システムに admin、finance、HR など、ユーザーに属性が定義されている場合には、さまざまな OpenStack サービスで使用するために、Identity 内のロールおよびグループにマップされる必要があります。/var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf ファイルは、LDAP 属性を Identity 属性にマッピングします。

3.7. Red Hat Single Sign-On を使用した IdM でのフェデレーション

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

3.7.1. フェデレーションのワークフロー

本セクションでは、keystone、RH-SSO、および IdM が相互に対話する方法を説明します。OpenStack におけるフェデレーションは、認証プロバイダーとサービスプロバイダーの概念を使用します。

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

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

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

フェデレーション rhsso idm

詳細は、フェデレーションガイド( https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/15/html-single/federate_with_identity_service/)を参照してください。

3.8. LDAP ベースのサービスとの統合

Identity サービス (keystone) は、Microsoft Active Directory Domain Services (AD DS) および Red Hat Identity Management (IdM) などの LDAP ベースのサービスに保存されているユーザーアカウントを認証できます。このユースケースでは、keystone は LDAP ユーザーデータベースの認証を読み取り専用でアクセスし、認証されたアカウントに割り当てられた authZ 権限で管理を維持します。authZ 機能 (パーミッション、ロール、プロジェクト) は keystone によって実行されます。この場合、パーミッションとロールは、keystone の管理ツールを使用して LDAP アカウントに割り当てられます。

3.8.1. LDAP 統合の仕組み

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

ad 統合 keystone v3

OpenStack と AD DS の統合および IdM の統合に関する情報は、『統合ガイド』を参照してください。https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/15/html-single/integrate_with_identity_service/

第4章 インフラストラクチャーおよび仮想化の強化

このセクションには、コンポーネント固有のアドバイスと情報が含まれています。

4.1. 脆弱性の認識

運用上の手順では、新しい脆弱性およびセキュリティー更新について把握する計画が必要です。ハードウェアおよびソフトウェアベンダーは、通常、脆弱性の存在を発表するため、これらの問題に対処するために回避策およびパッチが提供されます。

セキュリティー更新を認識できるように、Red Hat セキュリティーレスポンスチームサイトをご利用ください。

注記

更新の追跡に加えて、定期的なセキュリティー更新のインストールに対応できるようにプロセスとデプロイメントが設計されていることを確認する必要があります。カーネルの更新の場合、これにはコンピューティングノードと管理ノードを再起動する必要があります。これらのプロセスを設計するときは、インスタンスのセキュリティー更新も深く考慮する必要があります。また、新しく作成されたインスタンスが最新の更新を確実に取得できるように、ホストされた Glance イメージも定期的に更新する必要があります。

4.2. ネットワークタイムプロトコル

Red Hat OpenStack Platform クラスター内のシステムが、システム間で正確かつ一貫性のあるタイムスタンプを持つことを確認する必要があります。RHEL8 上の Red Hat OpenStack Platform は、時間管理のために Chrony をサポートしています。詳細は、「Using the Chrony suite to configure NTP」を参照してください。

4.2.1. 一貫した時刻が重要な理由

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

セキュリティーイベントの特定
一貫した時刻を維持することにより、影響を受けるシステムのイベントのタイムスタンプを関連付けることができ、イベントのシーケンスを理解することができます。
認証システムおよびセキュリティーシステム

セキュリティーシステムは、以下の例のように、時刻のずれの影響を受ける場合があります。

  • Kerberos ベースの認証システムは、時刻のずれの秒数により影響を受けるクライアントの認証を拒否する可能性があります。
  • トランスポート層セキュリティー (TLS) 証明書は、有効な時刻ソースに依存します。クライアントとサーバーシステム間の差異が Valid From の日付範囲を超えると、クライアントからサーバーへの TLS 接続が失敗します。
Red Hat OpenStack Platform のサービス
高可用性 (HA) や Ceph など、一部の OpenStack のコアサービスは、特に正確な時刻管理に依存しています。

4.2.2. NTP 設計

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

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

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

注記

Red Hat OpenStack Platform 環境内で実行中のサービスコンテナーは、それらのサービスが存在するホストから時刻を受信します。

4.2.3. Red Hat OpenStack プラットフォームでの NTP の構成

heat を使用して、アンダークラウドノードとオーバークラウドノードで NTP を構成します。

  1. NTP を使用してアンダークラウドを構成するには、openstack undercloud install コマンドを実行する前に、undercloud.conf の undercloud_ntp_servers パラメーターを使用します。アンダークラウドミニオンの場合は、minion_ntp_servers パラメーターを使用します。詳細は、Director Configuration Parameters を参照してください。

  2. NTP を使用してオーバークラウドを構成するには、例として次のパラメーターを使用します。 

    parameter_defaults:
  TimeZone: 'US/Central'
  NtpServer: ['ntpserver01.example.com']

ネットワークタイムキーピングパラメーターの詳細は、Overcloud Parameters ガイドの Time Parameters を参照してください。

4.3. Compute

このセクションでは、Compute (nova) のセキュリティーに関する考慮事項について説明します。

4.3.1. OpenStack のハイパーバイザー

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

4.3.1.1. ハイパーバイザーとベアメタル

Linux コンテナーまたはベアメタルシステムの使用と KVM のようなハイパーバイザーの使用の違いを認識しておくことは重要です。具体的には、このセキュリティーガイドは、ハイパーバイザーと仮想化プラットフォームに非常に重点を置いています。ただし、実装にベアメタルまたはコンテナー化環境を使用する必要がある場合は、その環境のデプロイメントに関して、特定の違いに注意する必要があります。

ベアメタルの場合は、再プロビジョニングして使用を停止する前に、ノードが正しくデータがサニタイズされていることを確認します。また、ノードを再使用する前に、ハードウェアが改ざんされていないか、またはセキュリティーが侵害されていないことを保証する必要があります。詳細は https://docs.openstack.org/ironic/queens/admin/cleaning.htmlを参照してください。

4.3.1.2. ハイパーバイザーメモリーの最適化

特定のハイパーバイザーは、メモリーをゲスト仮想マシンにオーバーコミットするメモリー最適化手法を使用します。これは、非常に高密度のコンピュートクラスターをデプロイすることができる便利な機能です。この手法の 1 つは、メモリーページの重複排除または共有により、メモリーページに 2 つの仮想マシンが同じデータがある場合、同じメモリーを参照する利点があります。これは通常、カーネル same-page merging (KSM) などの Copy-On-Write (COW) メカニズムで実行されます。これらのメカニズムは攻撃に対して脆弱です。

  • メモリーの重複排除システムは、サイドチャネル攻撃に対して脆弱です。攻撃者は、近傍の仮想マシンで実行しているソフトウェアパッケージとバージョンを特定し、攻撃者が仮想マシンのメモリーアクセス時間を分析することで、ソフトウェアのダウンロードやその他の機密情報を特定できていました。したがって、ある仮想マシンが別の状態について何かを推測できる可能性があります。これは、すべてのテナントが信頼されず、同じレベルの信頼レベルを共有する、マルチテナント環境に適さない場合があります。
  • さらに重要なことは、KSM に対して row-hammer タイプ攻撃 を参照して、実行可能なメモリーのクロス修正を行います。つまり、悪意のあるインスタンスが、同じ Compute ホスト上の他のインスタンスへのコード実行アクセスを取得できることを意味します。

Deployer は、(パブリッククラウドやプライベートクラウドを使用して) 強力なプロジェクトの分離が必要な場合は、KSM を無効にする必要があります。

4.3.2. 仮想化

4.3.2.1. 物理ハードウェア (PCI パススルー)

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

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

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

PCI パススルーに関連するリスクおよび複雑性により、デフォルトでは無効になっています。特定のニーズに応じて有効になっている場合は、ハードウェアを再利用する前に、ハードウェアがクリーンアップされるように適切なプロセスを用意する必要があります。

4.3.2.2. 仮想ハードウェア (QEMU)

仮想マシンを実行する場合、仮想ハードウェアは、仮想マシンのハードウェアインターフェイスを提供するソフトウェアレイヤーです。インスタンスはこの機能を使用して、必要になる可能性のあるネットワーク、ストレージ、ビデオ、およびその他のデバイスを提供します。これを念頭に置いて、環境内のほとんどのインスタンスは仮想ハードウェアのみを使用しますが、ハードウェアに直接アクセスする必要がある少数のインスタンスもあります。必要なハードウェアのみをプロビジョニングすることをお勧めします。たとえば、CD ドライブが必要ない場合は、プロビジョニングする必要はありません。

iptables にネットワークトラフィックをフィルターリングするように構成されたデフォルトのポリシーがあることを確認し、既存のルールセットを調べて各ルールを理解し、ポリシーを拡張する必要があるかどうかを判断することを検討してください。

QEMU プロセスの権限を制限し、必要なものだけに制限すると、強制アクセス制御により、攻撃が試行される影響を制限します。Red Hat OpenStack Platform では、SELinux は、個別のセキュリティーコンテキストで各 QEMU プロセスを実行するように設定されます。Red Hat OpenStack Platform サービス用に SELinux ポリシーが事前設定されています。

OpenStack の SELinux ポリシーでは、ハイパーバイザーホストと仮想マシンを 2 つの主要な脅威ベクトルから保護するのに役立ちます。

  • ハイパーバイザーの脅威: ハイパーバイザーが基礎となるリソースにアクセスするためにハイパーバイザーを攻撃する、危険にさらされるアプリケーション。たとえば、仮想マシンがハイパーバイザー OS、物理デバイス、またはその他のアプリケーションにアクセスできる場合。この脅威ベクトルは、ハイパーバイザーで危険にさらされるリスクを表し、他の仮想マシンおよびネットワークセグメントを公開することも可能となります。
  • 仮想マシン (multi-project) の脅威: ハイパーバイザーが、別の仮想マシンとそのリソースにアクセスしたり、制御したりするために、VM 攻撃内で実行される、危険にさらされたアプリケーションです。これは、仮想化に固有の脅威ベクトルであり、1 つのアプリケーションの脆弱性により、仮想マシンファイルイメージの多重化のリスクにさらされる可能性があるためです。この仮想ネットワーク攻撃は、実際のネットワークを保護する管理手法が仮想環境に直接適用されないため、大きな懸念となります。KVM ベースの各仮想マシンは SELinux によってラベル付けされ、各仮想マシンのセキュリティー境界を効果的に確立します。このセキュリティー境界は Linux カーネルによって監視および実施され、ホストマシンのデータファイルや他の仮想マシンなど、仮想マシンの境界外にあるリソースへのアクセスを制限します。

Red Hat の SELinux ベースの分離は、仮想マシン内で実行されるゲストオペレーティングシステムに関係なく提供されます。Linux または Windows 仮想マシンを使用できます。

4.3.2.3. ラベルとカテゴリー

KVM ベースの仮想マシンインスタンスには、svirt_image_t と呼ばれる独自の SELinux データ型でラベルが付けられます。カーネルレベルの保護により、マルウェアなどの未承認のシステムプロセスが、ディスク上で仮想マシンイメージファイルを操作できなくなります。仮想マシンの電源がオフの場合、イメージは以下のように svirt_image_t として保存されます。 

system_u:object_r:svirt_image_t:SystemLow image1
system_u:object_r:svirt_image_t:SystemLow image2
system_u:object_r:svirt_image_t:SystemLow image3
system_u:object_r:svirt_image_t:SystemLow image4

svirt_image_t label はディスク上のイメージファイルを一意に識別し、SELinux ポリシーでアクセスを制限することができます。KVM ベースのコンピュートイメージの電源が入ると、SELinux は、イメージにランダムな数値 ID を追加します。SELinux は、ハイパーバイザーノードごとに仮想マシン (最大 524,288) に数値識別子を割り当てることができますが、ほとんどの OpenStack デプロイメントでは、この上限に達することはほとんどありません。以下の例は、SELinux カテゴリー ID を示しています。 

system_u:object_r:svirt_image_t:s0:c87,c520 image1
system_u:object_r:svirt_image_t:s0:419,c172 image2

4.3.2.4. SELinux ユーザーおよびロール

SELinux はユーザーロールを管理します。これらは、-Z フラグまたは semanage コマンドで表示できます。ハイパーバイザーでは、管理者のみがシステムにアクセスできる必要があり、管理ユーザーとシステムにあるその他のユーザーの両方に適切なコンテキストが必要です。

4.3.2.5. コンテナー化されたサービス

nova、glance、keystone 等の特定のサービスは、コンテナー内で実行されるようになりました。このアプローチにより、サービスに更新を適用することが容易になりました。独自のコンテナーで各サービスを実行すると、同じベアメタル上で共存するサービス間の分離が強化されます。これは、隣接するサービスへの簡単なアクセスを回避することで、攻撃対象領域を低減するのに役立てることで、1 つのサービスが攻撃を受けることができるはずです。

注記

コンテナーにマウントするホストマシン上のパスは、ro/rw として設定されている場合、コンテナーとホスト間でデータを転送するマウントポイントとして使用できます。

設定ファイルを更新する場合は、特定の管理プラクティスを考慮する必要があります。これにより、コンテナー化されたサービスは一時的なものになります。

  • 物理ノードのホストオペレーティングシステム上の設定ファイル (例: /etc/cinder/cinder.conf) は更新しないでください。コンテナー化されたサービスはこのようなファイルを参照しません。
  • コンテナー内で実行されている設定ファイルは更新しないでください。コンテナーを再起動すると変更が失われてしまいます。

代わりに、コンテナー化されたサービスに変更を加える必要がある場合は、コンテナーのシードに使用される設定ファイルを更新する必要があります。これらのファイルは、puppet の初期デプロイメント時に生成され、クラウドの実行に重要な機密データが含まれ、それに応じて処理する必要があります。これらのファイルは /var/lib/config-data/puppet-generated/ 内に保管されています。以下に例を示します。

  • keystone: /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf
  • cinder: /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf
  • nova: /var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf

これらのファイルに加えられた変更は、コンテナーが再起動されると適用されます。

4.3.3. コンピュートデプロイメントのハード化

OpenStack のデプロイメントに関する主なセキュリティー上の問題点の 1 つは、/var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf ファイルなどの機密ファイルのセキュリティー制御です。この設定ファイルには、設定の詳細やサービスパスワードなど、多くの機密オプションが含まれています。このような機密ファイルはすべて厳密にファイルレベルのパーミッションが付与され、AIDE などのファイル整合性監視(FIM)ツールの変更の有無を監視します。これらのユーティリティーは、既知の正常な状態のターゲットファイルのハッシュを取得して、ファイルの新しいハッシュを定期的に取得し、これを既知の適切なハッシュと比較します。アラートは、予期せずに変更された場合に作成できます。

ファイルのパーミッションは、ls -lh コマンドに含まれているディレクトリーに移動して実行します。これにより、ファイルへのアクセスがあるパーミッション、所有者、およびグループ、ファイルの最終変更日時などのその他の情報が表示されます。

/var/lib/nova ディレクトリーには、指定したコンピュートノード上のインスタンスに関する情報を保持します。このディレクトリーは、厳密にファイルパーミッションを適用して、高感度として考慮する必要があります。また、そのホストに関連付けられたインスタンスの情報やメタデータが含まれるため、定期的にバックアップする必要があります。

デプロイメントで完全な仮想マシンのバックアップが必要ない場合は、/var/lib/nova/instances ディレクトリーを除外して、そのノード上で実行される各インスタンスの結合領域として大きな値になることに留意してください。デプロイメントで完全な仮想マシンのバックアップが必要な場合は、このディレクトリーが正常にバックアップされることを確認する必要があります。

注記

Block Storage (cinder) ボリュームに使用されているストレージサブシステム (Ceph) に保存されているデータも、高感度として考慮する必要があります。これは、ネットワークまたは論理アクセスでネットワークまたは論理アクセスにより、OpenStack コントロールをバイパスする可能性がある場合は、ストレージサブシステムから完全な仮想マシンイメージを取得できるためです。

4.3.4. ハードウェアの脆弱性の軽減

OpenStack は物理サーバーハードウェア上で実行されますが、これには本質的に独自のセキュリティー上の課題があります。この章では、ハードウェアベースの脅威と脆弱性を軽減するためのアプローチを紹介します。

4.3.4.1. PCI パススルーの強化

PCI パススルーを使用すると、ホストにインストールされている特定の物理ハードウェアにインスタンスが直接アクセスできるようになります。これは、多くのネットワーク機能仮想化 (NFV) のユースケースで発生する可能性があります。ただし、考慮すべきセキュリティー対策がいくつかあります。

PCI パススルーを使用する場合は、割り込みの再マッピングをサポートするハードウェアの導入を検討してください。そうしないと、allow_unsafe_interrupts 設定を有効にする必要があります。これにより、Compute ノードが悪意のあるインスタンスからの割り込みインジェクション攻撃に対して脆弱になる可能性があります。

詳しくは、『ネットワークガイド』の https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/15/html-single/networking_guide/#review-the-allow_unsafe_interrupts-settingを参照してください。

4.3.4.2. セキュリティー強化管理コンソール

多くのサーバーベンダーには、サーバーへのリモートセッションを可能にする個別の管理コンソールが含まれています。このアクセスポイントをセキュリティー強化するためにベンダーが規定した慣行を確認することを検討してください。

4.3.4.3. ファームウェアの更新

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

4.4. Block Storage

OpenStack Block Storage (cinder) は、ソフトウェア (サービスおよびライブラリー) を提供するサービスで、永続的なブロックレベルのストレージデバイスをセルフサービスで管理するサービスです。これにより、Compute (nova) インスタンスで使用する Block Storage リソースへのオンデマンドアクセスが作成されます。これにより、ブロックストレージのプールをさまざまなバックエンドストレージデバイスに仮想化することで、ソフトウェア定義のストレージが作成され、ソフトウェア実装または従来のハードウェアストレージ製品のいずれかになります。これの主な機能は、ブロックデバイスの作成、割り当て、切断を管理することです。コンシューマーは、バックエンドストレージ機器の種類や、そのタイプの配置先に関する知識は必要ありません。

コンピュートインスタンスは、iSCSI、ATA over Ethernet、または Fibre-Channel などの業界標準のストレージプロトコルを使用してブロックストレージを保存し、取得します。これらのリソースは、OpenStack ネイティブ HTTP RESTful API を使用して管理および設定されます。

4.4.1. ボリュームの接続

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

注記

以前のバージョンでは、lvm_type=default は wipe を示すために使用されていました。この手法は依然として機能しますが、secure delete の設定に lvm_type=default は推奨されません。

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

4.4.2. ブロックストレージの強化

このセクションには、OpenStack Block Storage のセキュリティーを強化するための実践的なアドバイスが含まれています。

4.4.2.1. 設定ファイルのユーザー/グループ所有権を root/cinder に設定します。

設定ファイルには、コンポーネントのスムーズに機能するために必要な重要なパラメーターおよび情報が含まれます。非特権ユーザーが故意・過失で変更したり、ファイル自体を変更したり、削除したりすると、重大な可用性の問題が原因で、他のエンドユーザーにサービス拒否が発生します。そのため、このような重要な設定ファイルのユーザー所有権を root に設定し、グループの所有権を cinder に設定する必要があります。

次のコマンドを使用して、これらの構成ファイルのユーザーとグループの所有権がそれぞれ root と cinder に設定されていることを確認します。 

$ stat -L -c "%U %G" /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf | egrep "root cinder"
$ stat -L -c "%U %G" /var/lib/config-data/puppet-generated/cinder/etc/cinder/api-paste.ini | egrep "root cinder"
$ stat -L -c "%U %G" /var/lib/config-data/puppet-generated/cinder/etc/cinder/policy.json | egrep "root cinder"
$ stat -L -c "%U %G" /var/lib/config-data/puppet-generated/cinder/etc/cinder/rootwrap.conf | egrep "root cinder"

4.4.2.2. 設定ファイルの厳密なパーミッションの設定

次のファイルの権限が 640 以上に設定されていることを確認してください。 

$ stat -L -c "%a" /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf
$ stat -L -c "%a" /var/lib/config-data/puppet-generated/cinder/etc/cinder/api-paste.ini
$ stat -L -c "%a" /var/lib/config-data/puppet-generated/cinder/etc/cinder/policy.json
$ stat -L -c "%a" /var/lib/config-data/puppet-generated/cinder/etc/cinder/rootwrap.conf

4.4.2.3. 認証には keystone を使用します。

/var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf で、[DEFAULT] セクションの auth_strategy の値が、noauth ではなく keystone に設定されていることを確認します。

4.4.2.4. 認証用に TLS を有効にする

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

4.4.2.5. Block Storage が Compute との通信に TLS を使用するのを確認

cinder.conf で、[DEFAULT] セクションの glance_api_servers の値が https:// で始まる値に設定されていることを確認します。また、パラメーター glance_api_insecure の値が False に設定されていることを確認します。

4.4.2.6. NFS に使用される NAS デバイスが強化された環境で動作していることを確認します

ブロックストレージサービス (cinder) は、従来のブロックストレージドライバーとは異なる動作をする NFS ドライバーをサポートします。

NFS ドライバーは、インスタンスがブロックレベルでストレージデバイスにアクセスすることを実際には許可しません。代わりに、ファイルは NFS 共有上に作成され、ブロックデバイスをエミュレートするインスタンスにマップされます。

Block Storage サービスは、cinder ボリュームの作成時にファイルのアクセス許可を制御することにより、このようなファイルの安全な構成をサポートします。Cinder 構成では、ファイル操作を root ユーザーとして実行するか、現在の Red Hat OpenStack Platform プロセスユーザーとして実行するかを制御することもできます。

注記

director のさまざまな heat パラメーターにより、NFS バックエンドまたは NetApp NFS Block Storage バックエンドが NetApp 機能 (NAS secure と呼ばれる) をサポートするかどうかが制御されます。

  • CinderNetappNasSecureFileOperations
  • CinderNetappNasSecureFilePermissions
  • CinderNasSecureFileOperations
  • CinderNasSecureFilePermissions

通常のボリューム操作に干渉するため、Red Hat では、この機能を有効にすることを推奨していません。director はデフォルトでこの機能を無効にするため、Red Hat OpenStack Platform はこの機能をサポートしません。

注記

ベンダー固有のドライバーを使用して Block Storage サービスに統合された NAS デバイスは、機密性が高いと見なされ、強化された分離された環境にデプロイする必要があります。これらのデバイスに違反すると、インスタンスデータへのアクセスまたは変更につながる可能性があります。

  1. cinder.conf ファイルの [DEFAULT] セクションの nas_secure_file_permissions の値が auto に設定されているかどうかを確認します。

    nas_secure_file_permissions パラメーターが auto に設定されている場合、起動時に、Block Storage サービスは既存の cinder ボリュームがあるかどうかを検出します。

    • 既存のボリュームがない場合、cinder はオプションをTrueに設定し、安全なファイル権限を使用します。
    • cinder が既存のボリュームを検出した場合、cinder はオプションを False に設定し、ファイルのアクセス許可を処理する安全でない方法を使用します。

  2. cinder.conf ファイルの [DEFAULT] セクションの nas_secure_file_operations パラメーターが auto に設定されているかどうかを確認します。

    nas_secure_file_operations パラメーターが auto に設定されている場合、起動時に、Block Storage サービスは既存のシンダーボリュームがあるかどうかを検出します。

    • 既存のボリュームがない場合、cinder はオプションを True に設定し、root ユーザーとして実行しません。
    • cinder が既存のボリュームを検出した場合、cinder はオプションを False に設定し、root ユーザーとして操作を実行する現在の方法を使用します。
注記

新規インストールの場合、Block Storage サービスはマーカーファイルを作成し、その後の再起動時に Block Storage サービスが元の決定を記憶するようにします。

4.4.2.7. 要求のボディーの最大サイズの設定

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

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

4.4.2.8. ボリュームの暗号化の有効化

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

4.5. ネットワーキング

OpenStack Networking サービス (neutron) により、エンドユーザーまたはプロジェクトがネットワークリソースを定義および消費できるようになります。OpenStack Networking は、ネットワーク設定のオーケストレーションに加えて、クラウド内のインスタンスのネットワーク接続や IP アドレスを定義するためのプロジェクト向け API を提供します。API 中心のネットワークサービスへの移行により、クラウドアーキテクトと管理者は、物理ネットワークおよび仮想ネットワークのインフラストラクチャーおよびサービスをセキュアにするための優れたプラクティスを考慮する必要があります。

OpenStack Networking は、オープンソースのコミュニティーまたはサードパーティーサービスを使用して API を拡張性を提供するプラグインアーキテクチャーと共に設計されました。アーキテクチャーの設計要件を評価する上で、OpenStack Networking のコアサービス、サードパーティー製品で提供される追加のサービス、物理インフラストラクチャーに実装する必要のある補助サービスを判断しておくことは重要です。

本項では、OpenStack Networking の実装時に、プロセスと適切なプラクティスについて概説します。

4.5.1. ネットワークアーキテクチャー

OpenStack Networking は、複数のノードに複数のプロセスをデプロイするスタンドアロンのサービスです。これらのプロセスは、相互、その他の OpenStack サービスと対話します。OpenStack Networking サービスの主なプロセスは、neutron-server で、OpenStack Networking API を公開し、追加の処理のためにプロジェクト要求をプラグインスイートに渡す Python デーモンです。

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

  • Neutron サーバー (neutron-server および neutron-*-plugin): neutron-server サービスは、Networking API とその拡張機能 (またはプラグイン) と対話するためにコントローラーノード上で実行されます。また、各ポートのネットワークモデルと IP アドレス処理も実施します。neutron-server では、永続データベースへの直接アクセスが必要です。エージェントは、neutron-server を介してデータベースに間接的にアクセスできます。このデータベースは AMQP (Advanced Message Queuing Protocol) を使用して通信します。
  • Neutron データベース: データベースは neutron 情報の一元化ソースで、API がデータベースのトランザクションをすべて記録します。これにより、複数の Neutron サーバーが同じデータベースクラスターを共有でき、すべてが同期され、ネットワーク設定トポロジーの永続性が可能になります。
  • プラグインエージェント (neutron-*-agent): 各コンピュートノードおよびネットワークノード (L3 および DHCP エージェントあり) で実行され、ローカルの仮想スイッチ (vswitch) 設定を管理します。有効なプラグインは有効なエージェントを決定します。これらのサービスにはメッセージキューのアクセスが必要で、使用されているプラグインによっては、外部ネットワークコントローラーまたは SDN 実装へのアクセスが必要です。OpenDaylight (ODL) や Open Virtual Network (OVN) などの一部のプラグインでは、コンピュートノード上に python エージェントを必要としません。統合には、有効な Neutron プラグインのみが必要です。
  • DHCP エージェント (neutron-dhcp-agent): プロジェクトネットワークへの DHCP サービスを提供します。このエージェントはすべてのプラグインで同じで、DHCP 設定を維持します。neutron-dhcp-agent にはメッセージキューのアクセスが必要です。プラグインに応じてオプションになります。
  • メタデータエージェント (neutron-metadata-agent、neutron-ns-metadata-proxy): インスタンスオペレーティングシステムの設定とユーザー指定の初期スクリプト ('userdata') を適用するために使用されるメタデータサービスを提供します。この実装では、cloud-init が送信するメタデータ API 要求をメタデータエージェントにプロキシー化するために、L3 または DHCP エージェント名前空間で neutron-ns-metadata-proxy を実行する必要があります。
  • L3 エージェント (neutron-l3-agent): プロジェクトネットワーク上の仮想マシンの外部ネットワークアクセスに L3/NAT 転送します。メッセージキューのアクセスが必要です。プラグインに応じてオプションになります。
  • ネットワークプロバイダーサービス (SDN サーバー/サービス): プロジェクトネットワークに対して追加のネットワークサービスを提供します。これらの SDN サービスは、REST API などの通信チャネルを介して neutron-server、neutron-plugin、およびプラグインエージェントと対話する可能性があります。

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

ネットワーク接続

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

4.5.1.1. 物理サーバーでの Neutron サービスの配置

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

ネットワークドメインの図
  • 管理ネットワーク: OpenStack コンポーネント間の内部通信に使用されます。このネットワークの IP アドレスはデータセンター内でのみ到達でき、管理セキュリティーゾーンとみなされます。デフォルトでは、Management network ロールは Internal API ネットワークにより実行されます。
  • ゲストネットワーク: ゲストクラウドデプロイメント内の仮想マシンデータ通信に使用します。このネットワークの IP アドレス要件は、使用中の OpenStack Networking プラグインや、プロジェクトによる仮想ネットワークの選択肢により異なります。このネットワークは、ゲストセキュリティーゾーンとみなされます。
  • 外部ネットワーク: 一部のデプロイメントシナリオにおいて、インターネットにアクセスできる仮想マシンを提供するのに使用します。このネットワークの IP アドレスは、インターネット上の誰でも到達できるはずです。このネットワークは、パブリックセキュリティーゾーンにあると見なされます。このネットワークは、neutron 外部ネットワーク により提供されます。これらの neutron VLAN は、外部ブリッジ上でホストされます。これらは Red Hat OpenStack Platform director により作成されませんが、デプロイ後の neutron により作成されます。
  • パブリック API ネットワーク: OpenStack Networking API を含むすべての OpenStack API をプロジェクトに公開する。このネットワークの IP アドレスは、インターネット上の誰でも到達できるはずです。これは、IP ブロック内の IP アドレスの完全な範囲より小さい IP 割り当て範囲を使用する外部ネットワークのサブネットを作成することができるので、外部ネットワークと同じネットワークである可能性があります。このネットワークは、パブリックセキュリティーゾーンにあると見なされます。

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

4.5.2. セキュリティーゾーンの使用

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

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

  • ダッシュボード： パブリックネットワークおよび管理ネットワークへのアクセス。
  • keystone: 管理ネットワークへのアクセスが可能です。
  • コンピュートノード： 管理用ネットワークおよびコンピュートインスタンスにアクセスできます。
  • ネットワークノード： 使用中の neutron-plugin に応じて、管理ネットワーク、コンピュートインスタンス、およびパブリックネットワークへのアクセスが可能です。
  • SDN サービスノード： 製品の使用および設定に応じて、管理サービス、コンピュートインスタンス、および公開されている。
ネットワークゾーン

.

4.5.3. ネットワークサービス

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

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

4.5.3.1. VLAN およびトンネリングを使用した L2 分離

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

4.5.3.2. VLAN

VLAN は、特定の VLAN ID (VID) フィールド値を持つ IEEE 802.1Q ヘッダーが含まれる特定の物理ネットワーク上のパケットとして認識されます。同じ物理ネットワークを共有する VLAN ネットワークは、L2 で相互に分離され、IP アドレス空間が重複している可能性もあります。VLAN ネットワークをサポートする各物理ネットワークは、別個の VLAN トランク として扱われ、異なる領域の VID 値を持ちます。有効な VID の値は 1 から 4094 までです。

VLAN 設定は、OpenStack の設計要件によって異なります。OpenStack Networking が VLAN をより効率的に使用できるようにするには、VLAN 範囲 (各プロジェクトの 1 つ) を割り当てて、各コンピュートノードの物理スイッチポートを VLAN トランクポートに切り替える必要があります。

注記

ネットワークで 4094 を超えるプロジェクトをサポートする場合は、VLAN よりも L2 トンネリング構成をお勧めします。

4.5.3.3. L2 トンネリング

ネットワークトンネリングは、各プロジェクト/ネットワークの組み合わせを、その組み合わせに属するネットワークトラフィックの特定に使用される一意の “tunnel-id” と組み合わせてカプセル化します。プロジェクトの L2 ネットワーク接続は、物理ローリティーまたは下層のネットワーク設計とは独立しています。IP パケット内にトラフィックをカプセル化することで、そのトラフィックはレイヤー 3 の境界をまたがり、事前設定済みの VLAN および VLAN トランク接続の必要性がなくなります。トンネリングにより、ネットワークデータのトラフィックに難読化のレイヤーが追加され、個別のプロジェクトトラフィックの可視性が、ビューのモニターポイントを模倣します。

OpenStack Networking は現在 GRE および VXLAN カプセル化の両方をサポートしています。L2 分離を提供する技術は、デプロイメントで作成されるプロジェクトネットワークのスコープおよびサイズによって異なります。

4.5.3.4. ネットワークサービス

プロジェクトネットワークの分離の選択は、プロジェクトサービスのネットワークセキュリティーと制御境界の実装方法に影響します。以下の追加のネットワークサービスは、OpenStack ネットワークアーキテクチャーのセキュリティー体制を強化するために利用可能であるか、現在開発中です。

4.5.3.5. アクセス制御リスト

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

4.5.4. L3 ルーティングおよび NAT

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 を使用して、特別な考慮する必要があります。外部で公開される必要があるサービスのみに対して、セキュリティーグループの使用を慎重に検討することが推奨されます。

4.5.5. Quality of Service (QoS)

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

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

  • max-kbps: 帯域幅
  • max-burst-kbps: バーストバッファー

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

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

4.5.5.1. 負荷分散

OpenStack Networking には Load-Balancer-as-a-service(LBaaS)が含まれます。LBaaS リファレンス実装は HAProxy をベースにしています。仮想インターフェースポート用に豊富な L4-L7 機能を提供する OpenStack Networking の拡張機能用にサードパーティーのプラグインがあります。LBaaS は、パブリックネットワークからのインスタンスへの ingress 接続を提供する点で Floating IP と似ています。Floating IP とは異なり、LBaaS インスタンスは複数のインスタンスにアタッチして、接続済みのインスタンス上で実行されるサービスの負荷分散および高可用性を提供することができます。

LBaaS の詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/15/html-single/networking_guide/index#sec-lbaasを参照してください。

4.5.6. Networking サービスのハードニング

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

4.5.6.1. API サーバーのバインドアドレスの制限: neutron-server

OpenStack Networking API サービスが受信クライアント接続用にネットワークソケットをバインドするインターフェースまたは IP アドレスを制限するには、/var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf ファイルで bind_host および bind_port を指定します。 

# Address to bind the API server
bind_host = IP ADDRESS OF SERVER

# Port the bind the API server to
bind_port = 9696

4.5.6.2. OpenStack Networking サービスの DB および RPC 通信を制限

OpenStack Networking サービスのさまざまなコンポーネントは、メッセージングキューまたはデータベース接続のいずれかを使用して、OpenStack Networking の他のコンポーネントと通信します。

注記

RPC 通信を必要とするすべてのコンポーネント用に、??? に記載されているガイドラインに従うことが推奨されます。

4.5.6.3. プロジェクトネットワークサービスのワークフロー

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

4.5.6.4. ネットワークリソースポリシーエンジン

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

注記

このポリシーはセキュリティーの問題に応じて変更できるため、デフォルトのネットワークリソースポリシーを確認することが重要です。

OpenStack が複数の外部アクセスポイントを提供する場合は、複数の仮想 NIC を複数の外部アクセスポイントにアタッチするプロジェクトの機能を制限することが重要です。よりこれらのセキュリティーゾーンがブリッジされ、セキュリティーへの不正アクセスの原因となる可能性があります。Compute が提供するホスト集約関数を使用するか、プロジェクトインスタンスを異なる仮想ネットワーク設定を持つ複数のプロジェクトに分割することで、このリスクを軽減することができます。ホストアグリゲートに関する詳しい情報は、「 https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/15/html/instances_and_images_guide/ch-manage_instances#section-manage-host-aggregates 」を参照してください。

4.5.6.5. セキュリティーグループ

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

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

4.5.6.6. クォータ

クォータは、プロジェクトで利用可能なネットワークリソースの数を制限できます。すべてのプロジェクトに対してデフォルトのクォータを適用できます。クォータオプションを確認するには、/var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf を参照してください。

OpenStack Networking は、クォータ拡張 API 経由でプロジェクトごとのクォータ制限もサポートします。プロジェクトごとのクォータを有効にするには、/var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf で quota_driver オプションを設定する必要があります。以下に例を示します。 

quota_driver = neutron.db.quota_db.DbQuotaDriver

4.5.6.7. ARP スプーフィングの緩和策

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

4.5.6.8. 設定ファイルのユーザー/グループの所有権を root/neutron に設定します。

設定ファイルには、コンポーネントのスムーズに機能するために必要な重要なパラメーターおよび情報が含まれます。非特権ユーザーが故意または過失で変更したり、ファイル自体を変更したり、削除したりすると、重大な可用性の問題が原因で、他のエンドユーザーにサービス拒否が発生します。そのため、このような重要な設定ファイルのユーザー所有権を root に設定し、グループの所有権を neutron に設定する必要があります。

次のファイルのユーザーおよびグループの所有権がそれぞれ root と neutron に設定されていることを確認してください。コンテナー化されたサービスでは、ファイルパスが異なる場合があります。 

$ stat -L -c "%U %G" /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf | egrep "root neutron"
$ stat -L -c "%U %G" /var/lib/config-data/puppet-generated/neutron/etc/neutron/api-paste.ini | egrep "root neutron"
$ stat -L -c "%U %G" /var/lib/config-data/puppet-generated/neutron/etc/neutron/policy.json | egrep "root neutron"
$ stat -L -c "%U %G" /var/lib/config-data/puppet-generated/neutron/etc/neutron/rootwrap.conf | egrep "root neutron"

4.5.6.9. 設定ファイルの厳密なパーミッションの設定

次のファイルの権限が 640 以上に設定されていることを確認してください。コンテナー化されたサービスでは、ファイルパスが異なる場合があります。 

$ stat -L -c "%a" /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf
$ stat -L -c "%a" /var/lib/config-data/puppet-generated/neutron/etc/neutron/api-paste.ini
$ stat -L -c "%a" /var/lib/config-data/puppet-generated/neutron/etc/neutron/policy.json
$ stat -L -c "%a" /var/lib/config-data/puppet-generated/neutron/etc/neutron/rootwrap.conf

4.5.6.10. 認証には keystone を使用します。

/var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf で、[DEFAULT] セクションの auth_strategy の値が、noauth または noauth2 ではなく keystone に設定されていることを確認します。

4.5.6.10.1. 認証にセキュアプロトコルを使用

/var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf の [keystone_authtoken] セクションの auth_uri の値が https: // で始まる Identity API エンドポイントに設定され、[keystone_authtoken] でも セキュアでない パラメーターの値が False に設定されていることを確認してください。

4.5.6.10.2. Neutron API サーバーでの TLS の有効化

/var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf で、[DEFAULT] セクションのパラメーター use_ssl が True に設定されていることを確認します。

第5章 director を使用したセキュリティー強化の設定

この章では、Director がデプロイメントプロセスの一部としてセキュリティー強化値を適用する方法を説明します。

注記

openstack overcloud deploy を実行する場合は、加える変更と共に、必ずオーバークラウドのデプロイに必要な環境ファイルをすべて含めなければならない点に注意してください。

5.1. SSH バナーテキストの使用

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

    resource_registry:
      OS::TripleO::Services::Sshd: ../puppet/services/sshd.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

5.2. システムイベントの監査

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

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

    resource_registry:
      OS::Tripleo::Services::Auditd: /usr/share/openstack-tripleo-heat-templates/puppet/services/auditd.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

5.3. ファイアウォールルールの管理

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

    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

この例では、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 に保存されます。 

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

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

  • port: ルールに関連付けられたポート。puppetlabs-firewall により非推奨になりました。
  • dport: ルールに関連付けられた宛先ポート
  • sport: ルールに関連付けられた送信元ポート
  • proto: ルールに関連付けられたプロトコル。デフォルトは tcp です。
  • action: ルールに関連付けられたアクションポリシー。デフォルトは accept です。
  • jump: ジャンプ先のチェーン
  • state: ルールに関連付けられた状態の配列。デフォルトは [NEW] です。
  • source: ルールに関連付けられた送信元の IP アドレス
  • iniface: ルールに関連付けられたネットワークインターフェース
  • chain: ルールに関連付けられたチェーン。デフォルトは INPUT です。
  • destination: ルールに関連付けられた宛先の cidr
  • extras: puppetlabs-firewall モジュールでサポートされる追加パラメーターのハッシュ

5.4. AIDE を使用した侵入検知

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

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

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

  resource_registry:
  OS::TripleO::Services::Aide: ../puppet/services/aide.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 の値を選択する必要があります。

  1. TripleORules という名前のエイリアスを宣言することで、毎回同じ属性を繰り返し除外する必要がなくなります。
  2. エイリアスは p+sha256 の属性を受け取ります。AIDE では、これは次の命令として解釈されます。sha256 の整合性チェックサムを使用してすべてのファイルパーミッション p を監視する。

AIDE の設定ファイルで利用可能な属性の完全リストは、http://aide.sourceforge.net/stable/manual.html#config の AIDE MAN ページを参照してください。

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

openstack overcloud deploy --templates -e <full environment> /usr/share/openstack-tripleo-heat-templates/environments/aide.yaml

5.4.1. 複雑な AIDE ルールの使用

前述の形式を使用して、複雑なルールを作成できます。以下に例を示します。 

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

上記は、次の命令として解釈されます。チェックサムの生成に sha256 を使用して、パーミッション、inode、リンクの数、ユーザー、グループ、サイズ、ブロック数、mtime、ctime をモニターする。

エイリアスの順番の位置は常に 1 であることに注意してください。つまり、AIDE ルールの先頭に配置され、それ以下のすべての値に再帰的に適用されます。

エイリアスの後は、監視するディレクトリーになります。正規表現を使用できます。たとえば、var ディレクトリーの監視を設定しますが、! を使用して not 句で上書きします ('!/var/log.*' および '!/var/spool.*')。

5.4.2. その他の AIDE 値

以下の AIDE 値も使用できます。

AideConfPath: aide 設定ファイルへの完全な POSIX パス。デフォルトは /etc/aide.conf です。ファイルの場所を変更する要件がない場合は、デフォルトのパスのままにすることが推奨されます。

AideDBPath: AIDE 整合性データベースへの完全な POSIX パス。この値は設定が可能で、オペレーターが独自のフルパスを宣言できます。多くの場合、AIDE データベースファイルはノード外に保管されるためです (読み取り専用のファイルマウント)。

AideDBTempPath: AIDE 整合性一時データベースへの完全な POSIX パス。この一時ファイルは、AIDE が新規データベースを初期化する際に作成されます。

AideHour: この値は、AIDE cron 設定の一部として hour 属性を設定します。

AideMinute: この値は、AIDE cron 設定の一部として minute 属性を設定します。

AideCronUser: この値は、AIDE cron 設定の一部として linux ユーザーを設定します。

AideEmail: この値は、cron が実行されるたびに AIDE レポートを受信するメールアドレスを設定します。

AideMuaPath: この値は、AideEmail で設定したメールアドレスに AIDE レポートを送信するために使用される Mail User Agent へのパスを設定します。

5.4.3. AIDE の cron 設定

AIDE director サービスにより、cron ジョブを設定できます。デフォルトでは、レポートを /var/log/audit/ に送信します。メールアラートを使用する場合は、AideEmail パラメーターを有効にして、設定されたメールアドレスにアラートを送信します。重大なアラートをメールに依存することは、システム停止や意図しないメッセージフィルタリングに対して脆弱である可能性があることに注意してください。

5.4.4. システムアップグレードの影響に関する考慮

アップグレードが実行されると、AIDE サービスが新しい整合性データベースを自動的に再生成し、アップグレードしたすべてのファイルが正しく再計算され、更新されたチェックサムが生成されるようにします。

openstack overcloud deploy が初期デプロイメントに対して後続の実行として呼び出され、AIDE 設定ルールが変更されると、director AIDE サービスはデータベースを再構築して、整合性データベースに新規設定属性が取り込まれるようにします。

5.5. SecureTTY の確認

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

5.6. Identity サービスの CADF 監査

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

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

  parameter_defaults:
    KeystoneNotificationFormat: cadf

5.7. login.defs 値の確認

新規システムユーザー (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

第6章 Dashboard サービスの強化

この章では、OpenStack Dashboard (horizon) を使用する Red Hat OpenStack Platform デプロイメントのセキュリティー強化に関する考慮事項を説明します。

Dashboard により、ユーザーには、(管理者によって設定される制限内において) 独自のリソースをプロビジョニングするためのセルフサービスポータルが提供されます。たとえば、ダッシュボードを使用して、インスタンスフレーバーの定義、仮想マシン (VM) イメージのアップロード、仮想ネットワークの管理、セキュリティーグループの作成、インスタンスの開始、および管理コンソールを介したインスタンスへのリモートアクセスを行うことができます。

ダッシュボードは、OpenStack API と同じ感度で処理する必要があります。どちらにも、クラウドリソースと構成へのアクセスを許可する機能があるためです。

6.1. ダッシュボードデプロイメントの計画

このセクションでは、ダッシュボード (horizon) サービスをデプロイする前に考慮すべきセキュリティーの側面について説明します。

6.1.1. ドメイン名の選択

Dashboard は、任意のレベルの共有サブドメイン (例: https://openstack.example.org または https://horizon.openstack.example.org) にデプロイするのではなく、2 次レベルのドメインにデプロイすることが推奨されます (例: https://example.com)。また、https://horizon/ などのベア内部ドメインへの Dashboard のデプロイを回避することが推奨されます。これらの推奨事項は、ブラウザーの same-origin-policy の制限に基づいています。

このアプローチは、コンテンツを完全に制御できない他のドメインからクッキーとセキュリティートークンを分離するのに役立ちます。サブドメインにデプロイされる場合、ダッシュボードのセキュリティーは、同じ 2 次ドメインにデプロイされた最も安全ではないアプリケーションと同じです。

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

6.1.2. ALLOWED_HOSTS の設定

Web サービスは、偽の HTTP ホストヘッダーに関連する脅威に対して脆弱です。これを軽減するために、ALLOWED_HOSTS を設定して OpenStack Dashboard で提供される FQDN を使用することを検討してください。

設定すると、受信 HTTP リクエストの Host: ヘッダーがこの一覧のいずれの値にも一致しない場合、エラーが発生し、要求側は処理を続行できなくなります。

horizon は、python Django web フレームワーク上に構築されています。この場合、HTTP Host: ヘッダーの悪意のある操作から保護するために、ALLOWED_HOSTS を設定する必要があります。この値を、ダッシュボードにアクセスできる FQDN に設定します。director の場合、この設定は HorizonAllowedHosts によって管理されます。

6.2. 一般的な Web サーバーの脆弱性の理解

この章では、一般的な Web サーバーの脆弱性を軽減する方法を説明します。

6.2.1. クロスサイトスクリプティング (XSS)

OpenStack Dashboard はカスタマイズ可能で、ほとんどのフィールドで全 Unicode 文字セットを使用できます。この拡張性により、クロスサイトスクリプティング (XSS) の脆弱性が導入される可能性があります。horizon には、開発者が XSS の脆弱性を誤って作成するのを防ぎ、開発者が正しく使用している場合に限り機能するようにするためのツールが含まれています。カスタムダッシュボードを監査し、以下の機能に特に注意してください。

  • mark_safe 関数
  • is_safe: カスタムテンプレートタグと共に使用する場合
  • safe テンプレートタグ
  • 自動エスケープがオフで、不適切にエスケープされたデータを評価する可能性のある JavaScript の場合

6.2.2. クロスサイトリクエストフォージェリー (CSRF)

OpenStack Dashboard は、脅威を導入する可能性があるので、カスタムダッシュボードを使用して、クロスサイトスクリプティングの脆弱性を導入しないように設計されています。複数の JavaScript インスタンスを使用する Dashboard は、@csrf_exempt デコレーターの不適切な使用など、脆弱性について監査する必要があります。これらの推奨セキュリティー設定に準拠しないダッシュボードは、CORS (Cross Origin Resource Sharing) の制限が緩和される前に、慎重に評価する必要があります。

各応答で制限的な CORS ヘッダーを送信し、ダッシュボードのドメインおよびプロトコルのみを許可するように、 Web サーバーを設定する必要があります。例: Access-Control-Allow-Origin: https://example.com/ワイルドカードオリジンを許可しないでください。

6.2.3. クロスフレームスクリプティング (XFS)

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

以下のパラメーターを使用して、iframe 埋め込みを許可できます。 

    parameter_defaults:
      ControllerExtraConfig:
        horizon::disallow_iframe_embed: false

6.2.4. Dashboard トラフィックの HTTPS 暗号化の使用

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

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

director ベースのデプロイメントについては、「 https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/15/html/advanced_overcloud_customization/sect-enabling_ssltls_on_the_overcloud 」を参照してください。

6.2.5. HTTP Strict Transport Security (HSTS)

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

director ベースのデプロイメントの場合、この設定はデフォルトで有効になっています。 

enable_secure_proxy_ssl_header: true

6.3. ダッシュボードコンテンツのキャッシュ

6.3.1. フロントエンドキャッシング

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

6.3.2. セッションバックエンド

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'

6.4. シークレットキーの確認

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

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

6.5. セッションクッキーの設定

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

注記

CSRF またはセッションクッキーを、先頭のドットでワイルドカードドメインを使用するように設定しないでください。

6.6. 静的メディア

Dashboard の静的メディアは、Dashboard ドメインのサブドメインにデプロイして、Web サーバーによって提供されます。また、外部のコンテンツ配信ネットワーク (CDN) の使用も受け入れ可能です。このサブドメインに Cookie を設定したり、ユーザーによって提供されるコンテンツを提供したりしないでください。メディアは HTTPS で提供される必要もあります。

Dashboard のデフォルト設定では、django_compressor を使用して CSS および JavaScript コンテンツを圧縮および最小化してから提供します。このプロセスは、デフォルトのリクエスト内動的圧縮を使用し、デプロイされたコードと共に得られたファイルをコピーまたは CDN サーバーに送付するのではなく、Dashboard をデプロイする前に静的に行う必要があります。圧縮は実稼働以外のビルド環境で実行する必要があります。これができない場合は、リソース圧縮を完全に無効にすることを検討してください。オンライン圧縮の依存関係 (less, Node.js) は、実稼働マシンにインストールしないでください。

6.7. パスワードの複雑性の検証

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

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

    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

6.8. 管理者パスワードチェックの強制

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

注記

これらの設定は、潜在的なセキュリティーの影響を完全に理解した後にのみ、False に設定するべきです。

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

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

    parameter_defaults:
      ControllerExtraConfig:
        horizon::enforce_password_check: false

6.9. iframe 埋め込みの拒否

注記

これらの設定は、潜在的なセキュリティーの影響を完全に理解した後にのみ、False に設定するべきです。

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

    parameter_defaults:
      ControllerExtraConfig:
        horizon::disallow_iframe_embed: false

6.10. パスワード表示の無効化

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

注記

これらの設定は、潜在的なセキュリティーの影響を完全に理解した後にのみ、False に設定するべきです。

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

    parameter_defaults:
      ControllerExtraConfig:
        horizon::disable_password_reveal: false

6.11. Dashboard へのログインバナーの表示

HIPAA、PCI-DSS、U.S などの多くの規制産業。政府により、ユーザーログオンバナーを表示することが要求されます。Dashboard サービスはコンテナー内で実行されるため、バナーを適用するために Dashboard コンテナーイメージをカスタマイズする必要があります。Dashboard コンテナーのカスタマイズに関する詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/15/html-single/introduction_to_the_openstack_dashboard/index#dashboard-customization を参照してください。

6.11.1. テーマのカスタマイズ

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

  1. {% include 'auth/_login.html' %} セクションの直前に、必要なログオンバナーを入力します。HTML タグが許可されることに注意してください。以下に例を示します。 

    <snip>
<div class="container">
  <div class="row-fluid">
    <div class="span12">
      <div id="brand">
        <img src="../../static/themes/rcue/images/RHOSP-Login-Logo.svg">
      </div><!--/#brand-->
    </div><!--/.span*-->

    <!-- Start of Logon Banner -->
    <p>Authentication to this information system reflects acceptance of user monitoring agreement.</p>
    <!-- End of Logon Banner -->

    {% include 'auth/_login.html' %}
  </div><!--/.row-fluid→
</div><!--/.container-->

{% block js %}
  {% include "horizon/_scripts.html" %}
{% endblock %}

  </body>
</html>

更新されたダッシュボードは、以下のようになります。

logonbanner

6.12. ファイルのアップロードサイズの制限

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

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

重要

この設定は、Red Hat では正式にテストされていません。この設定の影響を十分にテストしてから、実稼働環境にデプロイすることが推奨されます。

注記

値が小さすぎると、ファイルのアップロードは失敗します。

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

  • /var/lib/config-data/puppet-generated/horizon/etc/httpd/conf/httpd.conf 

    <Directory />
  LimitRequestBody 10737418240
</Directory>

  • /var/lib/config-data/puppet-generated/horizon/etc/httpd/conf.d/10-horizon_vhost.conf 

    <Directory "/var/www">
  LimitRequestBody 10737418240
</Directory>

  • /var/lib/config-data/puppet-generated/horizon/etc/httpd/conf.d/15-horizon_ssl_vhost.conf 

    <Directory "/var/www">
  LimitRequestBody 10737418240
</Directory>
注記

これらの設定ファイルは Puppet によって管理されるため、openstack overcloud deploy プロセスを実行するたびに、管理対象外の変更が上書きされます。

6.13. Dashboard サービスのデバッグ

実稼働環境では、DEBUG 設定を False に設定したままにすることが推奨されます。True に設定されている場合、Django は Web サーバーの状態に関する機密情報が含まれるスタックトレースをブラウザーユーザーに出力する可能性があります。さらに、DEBUG モードは ALLOWED_HOSTS を無効にするので、要件に応じて望ましくない結果となる可能性があります。

第7章 Shared File Systems (Manila) のセキュリティー強化

Shared File System サービス(manila)は、マルチプロジェクトのクラウド環境で共有ファイルシステムを管理するための一連のサービスを提供します。これは、OpenStack が Block Storage サービス (cinder) プロジェクトを通じてブロックベースのストレージ管理を提供する方法に似ています。manila を使用すると、共有ファイルシステムを作成し、可視性、アクセシビリティー、使用状況クォータなどの属性を管理できます。

manila の詳細は、『Storage Guide: https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/15/html-single/storage_guide/』を参照してください。

7.1. manila のセキュリティーに関する考慮事項

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 グループのグループメンバーシップを介して読み取りのみを行うことを想定します。サービスアカウントパスワードが含まれるため、他のユーザーがこれらのファイルを読み取り可能であってはいけません。

注記

root ユーザーのみが、rootwrap.conf の manila-rootwrap の設定および rootwrap.d/share.filters の共有ノードの manila-rootwrap コマンドフィルターに書き込みできる必要があります。

7.2. manila のネットワークおよびセキュリティーモデル

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

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

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

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

7.3. ファイル共有バックエンドモード

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

  • 共有用サーバー (driver_handles_share_servers = True): 共有ドライバーは共有サーバーを作成し、共有サーバーのライフサイクルを管理します。
  • 共有用サーバーなし (driver_handles_share_servers = False): ファイル共有サーバーの存在に依存するのではなく、管理者 (共有ドライバーではなく) がネットワークインターフェースでベアメタルストレージを管理します。

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

注記

共有用サーバーなしモード では、manila は、ファイル共有をエクスポートするネットワークインターフェースがすべてのプロジェクトからすでに到達可能であることを想定します。

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

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

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

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

7.4. manila のネットワーク要件

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

注記

manila はネットワーク情報をデータベースに格納するだけで、実際のネットワークはネットワークプロバイダーによって提供されます。Manila は、OpenStack Networking サービス (neutron) および「スタンドアロン」の事前設定されたネットワークの使用をサポートしています。

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

  • 共有用サーバー バックエンドモードのフラットネットワーク
  • 共有用サーバー バックエンドモードのセグメント化されたネットワーク

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

注記

一部の共有ドライバーにより起動するファイル共有用サーバーは、Compute サービスで作成した Compute サーバーです。これらのドライバーの一部は、ネットワークプラグインに対応していません。

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

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

注記

共有ドライバーによっては、すべてのタイプのセグメンテーションに対応していない場合があります。詳細は、使用しているドライバーの仕様を参照してください。

7.5. manila を使用したセキュリティーサービス

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

7.5.1. セキュリティーサービスの概要

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

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

注記

場合によっては、NetApp, EMC などのセキュリティーサービスの 1 つを明示的に指定する必要があります。Windows ドライバーには、CIFS プロトコルを使用したファイル共有の作成にActive Directory が必要です。

7.5.2. セキュリティーサービスの管理

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

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

  • プロジェクトが、セキュリティーサービスの詳細を提供する。
  • 管理者がセキュリティーサービスに対応する (このようなセキュリティーサービスのサーバー側を設定する)。
  • manila API 内で、security_service は share_networks に関連付けられる。
  • 共有ドライバーは、セキュリティーサービスのデータを使用して、新規に作成された共有用サーバーを設定する。

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

  • LDAP: Lightweight Directory Access Protocol。IP ネットワークを通じて分散ディレクトリー情報サービスにアクセスし、維持するためのアプリケーションプロトコル。
  • Kerberos: セキュアでないネットワーク上で通信するノードが、安全な方法で互いに ID を証明できるように、チケットベースで機能するコンピューターネットワーク認証プロトコル
  • Active Directory: Windows ドメインネットワーク向けに Microsoft が開発したディレクトリーサービス。LDAP、Microsoft バージョンの Kerberos、および DNS を使用します。

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

  • プロジェクトネットワーク内で使用される DNS IP アドレス
  • セキュリティーサービスの IP アドレスまたはホスト名
  • セキュリティーサービスのドメイン
  • プロジェクトが使用するユーザーまたはグループ名
  • ユーザー名を指定した場合は、ユーザーのパスワード

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

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

注記

さまざまな認証サービスが、さまざまな共有ドライバーによりサポートされます。さまざまなドライバーによりサポートされる機能に関する詳細は、https://docs.openstack.org/manila/latest/admin/share_back_ends_feature_support_mapping.html を参照してください。

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

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

注記

ほとんどの場合、CIFS 共有ファイルシステムプロトコルをサポートするドライバーは、Active Directory を使用して、ユーザー認証でアクセスを管理するように設定できます。

  • GlusterFS プロトコルをサポートするドライバーは、TLS 証明書を使用する認証で使用できます。
  • IP アドレスを使用した NFS プロトコル認証をサポートするドライバーは、唯一のサポートされているオプションです。
  • HDFS 共有ファイルシステムプロトコルは、NFS アクセスを使用するので、IP アドレスを使用して認証するように設定することもできます。

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

7.6. ファイル共有へのアクセスの制御

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

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

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

注記

manila は、ストレージシステムのエンドツーエンド管理を提供しません。したがって、別途バックエンドシステムを承認されていないアクセスから保護する必要があります。その結果、アウトオブバンドアクセスを取得することでバックエンドストレージデバイスが侵害された場合、manila API が提供する保護は損なわれる可能性があります。

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

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

  • rw: 読み取りおよび書き込み (RW) アクセス。これはデフォルト値です。
  • ro: 読み取り専用 (RO) アクセス
注記

RO アクセスレベルは、パブリックなファイル共有で役立ちます。この場合、管理者が特定のエディターまたはコントリビューターに対して読み取りおよび書き込み (RW) アクセスを提供し、残りのユーザー (ビューアー) には読み取り専用 (RO) アクセスを提供します。

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

  • IP: インスタンスの認証に IP アドレスを使用します。IP アクセスは、適切に形成された IPv4 アドレスまたは IPv6 アドレスで指定可能なクライアント、または CIDR 表記で指定されるサブネットに提供できます。
  • cert: インスタンスの認証に TLS 証明書を使用します。TLS アイデンティティーを IDENTKEY として指定します。有効な値は、証明書の共通名 (CN) の 64 文字までの任意の文字列です。
  • user: 指定したユーザーまたはグループ名で認証します。有効な値は、特殊文字を含む 4 から 32 文字の長さの英数字の文字列です。
注記

サポートされる認証方法は、使用する共有ドライバー、セキュリティーサービス、および共有ファイルシステムプロトコルにより異なります。サポート対象の共有ファイルシステムプロトコルは、MapRFS、CEPHFS、NFS、CIFS、および HDFS です。サポートされるセキュリティーサービスは、LDAP、Kerberos プロトコル、または Microsoft Active Directory サービスです。

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

注記

ファイル共有にセキュリティーサービスを選択する場合は、共有ドライバーが利用可能な認証方法を使用してアクセスルールを作成できるかどうかを考慮する必要があります。サポートされるセキュリティーサービスは、LDAP、Kerberos、および Microsoft Active Directory です。

7.7. 共有種別のアクセス制御

共有種別は、管理者の定義する サービスの種別 で、プロジェクトに表示される説明および 追加仕様 と呼ばれるプロジェクトに表示されないキー/値ペアの一覧で構成されます。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> を使用します。

注記

共有種別の目的を実証する例については、2 つのバックエンドを持つ状況 (LVM をパブリックストレージとして、Ceph をプライベートストレージとして) を検討します。このような場合には、特定のプロジェクトにアクセスを許可し、user/group 認証方法によりアクセスを制御できます。

7.8. ポリシー

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

注記

設定ファイル policy.json はどこにも配置できます。パス /var/lib/config-data/puppet-generated/manila/etc/manila/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": "",
   }

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

注記

/var/lib/config-data/puppet-generated/manila/etc/manila/policy.json への変更はすぐに有効になります。したがって、manila の稼働中に新規ポリシーを実装できます。ポリシーを手動で変更することは、予期しない副作用が発生する可能性があり、推奨されません。Manila ではデフォルトのポリシーファイルが提供されず、すべてのデフォルトポリシーがコードベース内にあります。oslopolicy-sample-generator --config-file=var/lib/config-data/puppet-generated/manila/etc/manila/manila-policy-generator.conf を実行することで、manila コードからデフォルトのポリシーを生成することができます。

第8章 オブジェクトストレージ

Object Storage (swift) サービスは、HTTP 経由でデータを保存および取得します。オブジェクト (データの塊) は、組織的な階層に保存され、匿名の読み取り専用アクセス、ACL 定義のアクセス、または一時的なアクセスを提供するように設定できます。swift は、ミドルウェアを使用して実装される複数のトークンベースの認証メカニズムをサポートします。

アプリケーションは、業界標準の HTTP RESTful API を使用して、オブジェクトストレージにデータを保存し、取得します。バックエンドの swift コンポーネントは同じ RESTful モデルに従いますが、一部の API (耐久性を管理する API など) はクラスターに対してプライベートなままになります。

swift のコンポーネントは以下のプライマリーグループに分類されます。

  • プロキシーサービス
  • 認証サービス

  • ストレージサービス

    • アカウントサービス
    • コンテナーサービス
    • オブジェクトサービス
swift ネットワークダイアグラム 1
注記

オブジェクトストレージのインストールは、インターネットに接続する必要はなく、パブリックスイッチ (組織の内部ネットワークインフラストラクチャーの一部) を持つプライベートクラウドにすることもできます。

8.1. ネットワークセキュリティー

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

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

注記

swift は、ノード間通信に暗号化または認証を使用しません。これは、swift がパフォーマンス上の理由でネイティブ rsync プロトコルを使用し、rsync 通信に SSH を使用しないためです。これが、アーキテクチャー図にプライベートスイッチまたはプライベートネットワーク ([V]LAN) が表示される理由です。このデータゾーンは、他の OpenStack データネットワークからも分離する必要があります。

注記

データゾーン内のストレージノードには、プライベート (V)LAN ネットワークセグメントを使用します。

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

  • コンシューマーが到達できるパブリックインターフェースとして 1 つのインターフェース。
  • ストレージノードにアクセスできるプライベートインターフェースとしての別インターフェース。

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

swift ネットワークダイアグラム 2

8.2. 一般的なサービスセキュリティー

8.2.1. 非 root ユーザーとしてのサービスの実行

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

8.2.2. ファイル権限

/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 グループのメンバーシップにより、サービスにそれらの読み取りを許可します。

8.3. ストレージサービスのセキュリティー保護

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

  • アカウントサービス: TCP/6002
  • コンテナーサービス: TCP/6001
  • オブジェクトサービス: TCP/6000
  • rsync: TCP/873
注記

rsync ではなく ssync が使用される場合、耐久性を維持するためにオブジェクトサービスポートが使用されます。

注記

認証はストレージノードで発生することはありません。これらのポートのいずれかでストレージノードに接続できる場合は、認証なしでデータにアクセスしたり変更したりすることができます。この問題を軽減するには、プライベートストレージネットワークの使用に関する前述の推奨事項に従ってください。

8.3.1. Object Storage アカウントの用語

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

  • Swift アカウント: コンテナーのコレクションです (ユーザーアカウントや認証ではない)。使用する認証システムは、アカウントに関連付けられているユーザー、およびそのアクセス方法を決定します。
  • swift コンテナー: オブジェクトのコレクション。コンテナーのメタデータは ACL で利用できます。ACL の使用は、使用される認証システムによって異なります。
  • swift オブジェクト: 実際のデータオブジェクト。オブジェクトレベルの ACL もメタデータで利用できますが、使用する認証システムに依存します。

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

8.4. プロキシーサービスのセキュリティー保護

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

8.4.1. HTTP リッスンポート

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) を持つ応答を取得できます。

8.4.2. ロードバランサー

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

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

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

8.5. Object Storage の認証

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

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

8.5.1. Keystone

Keystone は、OpenStack で一般的に使用される ID プロバイダーです。Object Storage での認証にも使用できます。

8.6. 保存されている swift オブジェクトの暗号化

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

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

詳細は、『Barbican 統合ガイド』を参照してください： https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/15/html-single/manage_secrets_with_openstack_key_manager/

8.7. その他の項目

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

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

第9章 監視およびロギング

ログ管理は、OpenStack デプロイメントのセキュリティーステータスを監視する重要なコンポーネントです。ログは、OpenStack デプロイメントを構成するコンポーネントのアクティビティーに加えて、管理者、プロジェクト、およびインスタンスの BAU アクションに関する洞察を提供します。

ログは、予防的なセキュリティー活動および継続的なコンプライアンスアクティビティーのみならず、調査およびインシデントへの対応に関する貴重な情報ソースでもあります。たとえば、keystone アクセスログを分析すると、その他の関連情報に加えて、ログインの失敗、その頻度、送信元 IP、およびイベントが特定のアカウントに限定されるかどうかなどについて、警告が得られます。

director には、AIDE を使用した侵入検知機能、および keystone の CADF 監査が含まれています。詳しくは、director によるセキュリティー強化に関する章を参照してください。

9.1. モニタリングインフラストラクチャーの強化

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

9.2. 監視するイベントの例

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

本セクションでは、認識する必要のあるイベントの例について説明します。

重要

このリストがすべてを網羅している訳ではありません。実際のネットワークに適用される可能性のある追加のユースケースを考慮する必要があります。また、異常な動作を考慮する必要があります。

  • ログが生成されないことを検出するのは、価値の高いイベントです。このようなギャップは、サービス障害や、攻撃を隠すために侵入者が一時的にログを停止したり、ログレベルを変更したりしたことを示す場合があります。
  • スケジュールされていないイベントの開始や停止などのアプリケーションイベントは、セキュリティーと何らかの関係がある可能性があります。
  • ユーザーのログインや再起動などの OpenStack ノードでのオペレーティングシステムイベントこれにより、システムの適切な使用方法と不適切な使用方法を区別するための、貴重な洞察が得られます。
  • ネットワークブリッジがダウンする。これは、サービスが停止するリスクがあるため、対処を要するイベントです。
  • コンピュートノードでの IPtable のフラッシュイベント、およびそれに伴うインスタンスへのアクセス不能

Identity サービスでの孤立したインスタンス、テナント、またはドメインの削除からセキュリティーリスクを低減するために、システムで通知を生成し、OpenStack コンポーネントがこれらのイベントに対応すること（インスタンスの終了、アタッチされているボリュームの切断、CPU およびストレージリソースの回収など）について説明します。

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

第10章 プロジェクトのデータのプライバシー

OpenStack は、異なるデータ要件を持つプロジェクト間のマルチテナンシーをサポートするように設計されています。クラウドオペレーターは、適用可能なデータのプライバシーに関する懸念点と規制を考慮する必要があります。本章では、OpenStack デプロイメントにおけるデータ保持および破棄の要素に対応しています。

10.1. データプライバシーの懸念

このセクションでは、OpenStack デプロイメントのデータプライバシーに関して発生する可能性のあるいくつかの懸念について説明します。

10.1.1. データ保持

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

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

  • Object Storage オブジェクト
  • コンピュートインスタンスの一時ファイルシステムのストレージ
  • コンピュートインスタンスのメモリー
  • Block Storage ボリュームデータ
  • Compute アクセス用の公開鍵
  • Image サービスの仮想マシンイメージ
  • インスタンスのスナップショット
  • Compute の configuration-drive 拡張に渡されるデータ

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

  • 組織名
  • ユーザーの「本名」
  • 実行中のインスタンス、バケット、オブジェクト、ボリューム、およびその他のクォータ関連項目の数またはサイズ
  • インスタンスの実行時間またはデータの保存時間
  • ユーザーの IP アドレス
  • コンピュートイメージのバンドル用に内部的に生成された秘密鍵

10.1.2. データの破棄

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

注記

NIST Special Publication 800-53 Revision 4 に、本トピックが具体的に説明されています。 

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 のデプロイメントで以下のプラクティスを対処する必要があります (一例)。

  • セキュアなデータイレイジャー
  • インスタンスメモリーのスクラブ
  • Block Storage ボリュームデータ
  • コンピュートインスタンスの一時ストレージ
  • ベアメタルサーバーのサニタイズ

10.1.3. 安全に消去されないデータ

OpenStack の一部のデータは削除される可能性がありますが、上記の NIST 規格のコンテキストでは安全に消去されません。通常、これは、データベースに保存されている上記のメタデータと情報の多くまたはすべてに適用できます。これは、自動バキュームおよび定期的な空き領域の消去のためのデータベースやシステム設定で修正される可能性があります。

10.1.4. インスタンスメモリーのスクラブ

さまざまなハイパーバイザーに固有のことは、インスタンスメモリーの取り扱いです。一般に、インスタンスの削除時もしくは作成時に、またはその両方で、ハイパーバイザーはベストエフォートでメモリーのスクラブを行うと考えられますが、この動作は Compute では定義されません。

10.1.5. cinder ボリュームデータの暗号化

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

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

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

10.1.6. Image サービスの削除遅延機能

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

10.1.7. Compute のソフト削除機能

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

10.1.8. コンピュートインスタンスの一時ストレージ

OpenStack の一時ディスク暗号化機能は、アクティブな使用時やデータが破棄される時において、一時ストレージのプライバシーと分離を改善する手段を提供する点に注意してください。暗号化されたブロックストレージの場合と同様に、暗号鍵を削除して、データを効果的に破棄できます。

一時ストレージの作成や破棄を行う際に、データのプライバシーを提供するその他の手段は、選択したハイパーバイザーとコンピュートプラグインによって異なります。

コンピュート用の libvirt ドライバーは、ファイルシステム上または LVM で一時ストレージを直接維持する場合があります。ダーティーエクステントがユーザーにプロビジョニングされないことは保証されますが、ファイルシステムストレージは通常、削除時にデータを上書きしません。

ブロックベースの LVM がサポートする一時ストレージを使用する場合は、情報の公開を防ぐために Compute ソフトウェアが安全にブロックを消去する必要があります。以前は、一時ブロックストレージデバイスの不適切な消去に関連する情報公開の脆弱性がありました。

ダーティーエクステントがユーザーにプロビジョニングされないため、ファイルシステムストレージは、一時ブロックストレージデバイスとして LVM よりもセキュアなソリューションです。ただし、ユーザーデータが破棄されないため、バッキングファイルシステムを暗号化することが推奨されます。

10.2. ベアメタルプロビジョニングのセキュリティー強化

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

注記

可能な場合は、レガシーに代えて Redfish ベースの BMC の評価を検討してください。

10.2.1. ハードウェアの特定

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

10.3. データの暗号化

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

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

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

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

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

  • Object Storage オブジェクト
  • ネットワークデータ

10.3.1. ボリュームの暗号化

OpenStack のボリューム暗号化機能は、プロジェクトごとにプライバシーをサポートします。以下の機能がサポートされます。

  • Dashboard またはコマンドラインインターフェースから開始された暗号化されたボリューム種別の作成および使用
  • 暗号化を有効にし、暗号化アルゴリズムやキーサイズなどのパラメーターを選択します。
  • iSCSI パケットに含まれるボリュームデータの暗号化
  • 元のボリュームが暗号化されている場合、暗号化されたバックアップをサポートします。
  • Dashboard には、ボリューム暗号化のステータスが表示されます。ボリュームが暗号化されていること、およびアルゴリズムやキーサイズなどの暗号化パラメーターが含まれます。
  • 鍵管理サービスとのインターフェース

10.3.2. 一時ディスクの暗号化

一時ディスクの暗号化機能は、データのプライバシーに対応します。一時ディスクは、仮想ホストのオペレーティングシステムで使用されている一時的なワークスペースです。暗号化しないと、機密ユーザー情報がこのディスクからアクセスできます。また、重大な情報は、ディスクのマウント解除後もそのまま残ります。以下の一時ディスクの暗号化機能がサポートされます。

10.3.2.1. 暗号化された LVM 一時ディスクの作成と使用方法

注記

現在、Compute サービスでは、LVM 形式の一時ディスクの暗号化しかサポートされません。

Compute 設定ファイル(/var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf)には、ephemeral_storage_encryption セクション内に以下のデフォルトパラメーターがあります。

  • cipher = aes-xts-plain64: このフィールドは、一時ストレージの暗号化に使用する暗号およびモードを設定します。AES-XTS はディスクストレージ専用の NIST で推奨されます。名前は、XTS 暗号化モードを使用した AES 暗号化の短縮形です。利用可能な暗号は、カーネルのサポートにより異なります。コマンドラインで cryptsetup benchmark と入力して、利用可能なオプションを確認します（ベンチマーク結果を参照）、または /proc/crypto に移動します。
  • enabled = false - 一時ディスクの暗号化を使用するには、設定オプション enabled = trueを設定します。
  • key_size = 512 - バックエンドキーマネージャーのキーサイズの制限があり、key_size = 256 の使用が必要になる可能性があることに注意してください。これは、AES 鍵のサイズである 128 ビットのみを提供することに注意してください。XTS には、暗号化キー AES で必要な独自の「tweak key」が必要です。通常、これは単一の大きなキーとして表現されます。この場合、512 ビット設定を使用すると、256 ビット設定が AES、256 ビット、XTS により 256 ビットが使用されます（NIST を参照）。

10.3.2.2. キー管理サービスとの対話

キー管理サービスは、プロジェクトごとに一時ディスクの暗号化キーを提供することで、データの分離をサポートします。一時ディスクの暗号化は、セキュリティーを強化するためにバックエンドキーストレージでサポートされます。Key Management サービスでは、一時ディスクが必要なくなった場合に、単にキーを削除すると、一時ディスクのストレージ領域の上書きが行われている可能性があります。

10.3.3. Object Storage オブジェクト

Object Storage (swift) は、ストレージノードに保管されているオブジェクトデータのオプション暗号化をサポートします。オブジェクトデータの暗号化は、承認されていないユーザーがディスクへの物理アクセスを取得している場合に、ユーザーのデータが読み取られるリスクを軽減することを目的としています。

保管されているデータの暗号化は、プロキシーサーバー WSGI パイプラインに含まれる可能性のあるミドルウェアにより実装されます。この機能は swift クラスターに内部にあり、API 経由で公開されません。クライアントは、swift サービス内のこの機能によりデータが暗号化されていることを認識しません。内部で暗号化されたデータは swift API 経由でクライアントに返されません。

swift で保管されている間、以下のデータは暗号化されます。

  • オブジェクトコンテンツ (例: オブジェクト PUT 要求ボディーのコンテンツ)。
  • ゼロ以外のコンテンツを持つオブジェクトのエンティティータグ (ETag)。
  • すべてのカスタムユーザーオブジェクトのメタデータ値。たとえば、 PUT または POST リクエストで、X-Object-Meta- のプレフィックスが付けられたヘッダーを使用して送信されるメタデータなどです。

上記のリストに含まれていないデータまたはメタデータは暗号化されません。以下に例を示します。

  • アカウント、コンテナー、およびオブジェクト名
  • アカウントおよびコンテナーのカスタムユーザーメタデータの値
  • すべてのカスタムユーザーメタデータ名
  • オブジェクトコンテンツ種別の値
  • オブジェクトサイズ
  • システムメタデータ

10.3.4. Block Storage のパフォーマンスおよびバックエンド

オペレーティングシステムを有効にすると、Intel および AMD プロセッサーの両方で現在利用可能なハードウェアアクセラレーション機能を使用して、OpenStack Volume Encryption のパフォーマンスを強化できます。OpenStack Volume Encryption 機能および OpenStack Ephemeral Disk Encryption 機能の両方は、dm-crypt を使用してボリュームデータを保護します。DM-crypt は、Linux カーネルバージョン 2.6 以降の透過的なディスク暗号化機能です。ハードウェアアクセラレーションを使用する場合、両方の暗号化機能のパフォーマンスの影響は最小限に抑えられます。

10.3.5. ネットワークデータ

コンピュートノードのプロジェクトデータは IPsec または他のトンネルで暗号化される可能性があります。これは、OpenStack では一般的または標準ではありませんが、興味のある実装者が利用可能なオプションです。同様に、ネットワーク上で転送されるため、暗号化されたデータは暗号化された状態のままです。

10.4. キー管理

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

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

ボリュームの暗号化および一時ディスク暗号化機能は、鍵の作成やセキュリティーが強化された保管に関して、鍵管理サービス (barbican など) に依存します。

第11章 インスタンスのセキュリティーの管理

仮想化環境でインスタンスを実行する利点の 1 つは、通常ベアメタルへのデプロイ時に利用できないセキュリティー制御の新しい機会です。OpenStack デプロイメントの情報セキュリティーを向上させる特定のテクノロジーを仮想化スタックに適用できます。セキュリティー要件が強固な運用者は、これらの技術のデプロイを検討する必要がある場合がありますが、すべての状況に該当する訳ではありません。場合によっては、規定されたビジネス要件により、クラウドでの使用にテクノロジーを除外できる場合があります。同様に、一部の技術は、動作状態などのインスタンスデータを検査しますが、システムのユーザーにとって望ましくない可能性があります。

本章では、これらのテクノロジーと、インスタンスまたは基盤のノードのセキュリティーを強化するために使用できる状況について説明します。プライバシーの懸念事項も詳しく説明します。これには、データパススルー、イントロスペクション、またはエントロピーソースが含まれます。

11.1. インスタンスへのエントロピーの提供

本章で使用される エントロピー という用語は、インスタンスで利用可能なランダムデータの品質およびソースを指します。暗号化技術は、通常、エントロピーの高品質なプールから取得される必要がある無作為性に強く依存します。通常、インスタンスがこれらの操作をサポートするのに十分なエントロピーを取得するのが困難です。これはエントロピー不足と呼ばれます。この状況は、無関係に思われるインスタンスに現れます。たとえば、ブート時間が遅くなるのは、インスタンスが SSH 鍵の生成を待機することが原因である可能性があります。また、この状況では、ユーザーがインスタンス内から、適切でない品質のエントロピーソースを使用するリスクを招く可能性があり、クラウド内で実行するアプリケーションの全体的なセキュリティーレベルが低くなります。

ただし、インスタンスにエントロピーの高品質ソースを提供することで、これらの問題に対処するのに役立ちます。これは、クラウド内にインスタンスをサポートするのに十分なハードウェア乱数ジェネレーター (HRNG) を持つことで実現できます。この場合、十分かどうかはドメインに依存します。毎日の操作では、今日的な HRNG は、通常 50 - 100 コンピュートノードをサポートするのに十分なエントロピーを生成します。Intel Ivy Bridge 以降のプロセッサーで利用可能な RdRand 命令など、高帯域幅 HRNG では、より多くのノードを処理できる可能性があります。特定のクラウドでは、十分なエントロピーを利用できることを確保するために、アーキテクトはアプリケーションの要件を理解する必要があります。

Virtio RNG は、デフォルトでエントロピーのソースとして /dev/random を使用する乱数ジェネレーターです。また、デプロイメント全体でエントロピーを適切に配布する方法を提供するために、ハードウェア RNG またはエントロピー収集デーモン (EGD) などのツールを使用するように設定することもできます。hw_rng メタデータプロパティーを使用して、インスタンスの作成時に Virtio RNG を有効にすることができます。

11.2. ノードへのインスタンスのスケジューリング

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

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

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

  • リソースベースのフィルター: ハイパーバイザーホストセットのシステムリソース使用状況に基づいてインスタンスの配置を決定し、RAM、IO、CPU 使用率などの空きまたは使用されるプロパティーで起動することができます。
  • イメージベースのフィルター: 仮想マシンのオペレーティングシステムや使用するイメージの種別など、使用されるイメージメタデータに基づいて、インスタンスの作成を委譲します。
  • 環境ベースのフィルター: 特定の IP 範囲内、アベイラビリティーゾーン間、または別のインスタンスと同じホストなど、外部の詳細に基づいてインスタンスの配置を決定します。
  • カスタム基準: 信頼やメタデータの解析などの、ユーザーまたは管理者が提供する基準に基づいて、インスタンスの作成を委譲します。

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

filteringWorkflow1

注記

DiskFilter フィルターは、ディスクスペースをオーバーサブスクライブすることができます。通常は問題になりませんが、これは、シンプロビジョニングされたストレージデバイスで問題になる可能性があります。このフィルターは、十分にテストされたクォータを適用して使用する必要があります。この機能は廃止されたため、Red Hat OpenStack Platform12 以降は使用しないでください。

重要

ユーザーが提供するオブジェクトまたは操作可能なオブジェクト (メタデータなど) を解析するフィルターを無効にすることを検討してください。

11.3. 信頼できるイメージの使用

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

11.3.1. イメージの作成

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

  • オプション 1: 信頼されたソースからブートメディアを取得します。たとえば、公式の Red Hat ソースからイメージをダウンロードしてから、追加のチェックサム検証を実行できます。
  • オプション 2: OpenStack Virtual Machine Image Guide を使用します。この場合、組織の OS 強化ガイドラインに従うようにしてください。
  • オプション 3: 自動化されたイメージビルダーを使用します。以下の例では、Oz イメージビルダーを使用します。OpenStack コミュニティーは、最近 disk-image-builder という新しいツールを作成しました。ただし、セキュリティー評価はまだ実施されていません。

この例では、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>

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

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

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

11.3.2. イメージの署名の確認

イメージの署名に関連する特定の機能が OpenStack で利用可能になりました。Red Hat OpenStack Platform 13 の時点で、Image サービスはこれらの署名済みイメージを検証して、完全な信頼チェーンを提供するために、Compute サービスにはイメージ署名の検証をイメージブートの前に実施するオプションがあります。イメージブート前の署名の検証に成功すると、署名済みイメージが変更されていないことを確認します。この機能を有効にすると、マルウェアやルートキットを含むようにイメージを変更するなど、権限のないイメージの変更を検出できます。

/var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf ファイルの verify_glance_signatures フラグを True に設定して、インスタンス署名の検証を有効にすることができます。有効にすると、Compute サービスは glance から取得された署名済みインスタンスを自動的に検証します。この検証に失敗すると、ブートプロセスは開始しません。

注記

この機能を有効にすると、署名のないイメージ (署名されていないイメージ) も検証に失敗し、ブートプロセスは開始しません。

11.4. インスタンスの移行

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

  1. 移行先ホストでインスタンスを起動する
  2. メモリーを転送する
  3. ゲストを停止してディスクの同期する
  4. 状態を遷移する
  5. ゲストを起動する
注記

コールドマイグレーション、サイズ変更、退避などの特定の操作により、インスタンスのデータをネットワークを通じて他のサービスに転送することになります。

11.4.1. ライブマイグレーションのリスク

ライブマイグレーションプロセスのさまざまな段階では、インスタンスのランタイムメモリーとディスクの内容は、ネットワークを通じてプレーンテキストで送信されます。したがって、ライブマイグレーションの使用時には、対応する必要があるリスクが複数含まれています。以下は、これらのリスクについて詳しく説明します (すべてを網羅している訳ではありません。)。

  • サービス妨害 (DoS): 移行プロセス中に何らかの障害が発生した場合、インスタンスは失われる可能性があります。
  • データ漏えい: メモリーまたはディスク転送は安全に処理する必要があります。
  • データ操作: メモリーまたはディスク転送が安全に処理されない場合、攻撃者は移行中にユーザーデータを操作できます。
  • コード挿入: メモリーまたはディスク転送が安全に処理されない場合、攻撃者は移行中にディスクまたはメモリーいずれかの実行ファイルを操作できます。

11.4.2. ライブマイグレーションの緩和

ライブマイグレーションに関連するリスクの一部を軽減するために利用できる複数の方法があります。これらについては、次のセクションで説明します。

11.4.2.1. ライブマイグレーションの無効化

現時点で、OpenStack ではデフォルトでライブマイグレーションが有効になっています。ライブマイグレーションは、デフォルトでは管理者専用タスクであるため、ユーザーはこの操作を開始できず、管理者 (信頼されると考えられる) しか開始できません。policy.json ファイルに以下の行を追加して、ライブマイグレーションを無効にすることができます。 

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

あるいは、TCP ポート 49152 から 49261 までブロックする、または、nova ユーザーにコンピュートホスト間でのパスワードなしの SSH アクセスが含まれないようにすると、ライブマイグレーションに失敗することが期待されます。

ライブマイグレーションの SSH 設定は大幅にロックされていることに注意してください。新しいユーザーが作成され (nova_migration)、SSH キーがそのユーザーに制限され、ホワイトリストに登録されているネットワークでのみ使用されます。次に、ラッパースクリプトは実行可能なコマンド (例: libvirt ソケット上の netcat) を制限します。

11.4.2.2. 移行ネットワーク

ライブマイグレーションのトラフィックは、実行中のインスタンスのディスクおよびメモリーのコンテンツをプレーンテキストで転送し、デフォルトでは内部 API ネットワークでホストされています。

11.4.2.3. 暗号化されたライブマイグレーション

ライブマイグレーションを有効にするのに十分な要件 (アップグレードなど) がある場合、libvirtd はライブマイグレーション用に暗号化されたトンネルを提供できます。ただし、この機能は OpenStack Dashboard または nova-client コマンドで公開されず、libvirtd の手動設定でのみアクセスできます。ライブマイグレーションプロセスは、以下の手順概要に変わります。

  1. インスタンスデータがハイパーバイザーから libvirtd にコピーされます。
  2. 移行元ホストと移行先ホストの両方で libvirtd プロセス間で暗号化されたトンネルが作成されます。
  3. 移行先の libvirtd ホストは、インスタンスを基礎となるハイパーバイザーにコピーして戻します。
注記

Red Hat OpenStack Platform 13 では、推奨されるアプローチはトンネル化された移行を使用することで、ceph をバックエンドとして使用する場合にデフォルトで有効化されます。詳細は、https://docs.openstack.org/nova/queens/configuration/config.html#libvirt.live_migration_tunnelled を参照してください。

11.5. モニタリング、アラート、およびレポート

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

注記

これらのログは、定期的に確認したり、ネットワークオペレーションセンター (NOC) によって実行されるライブビュー内で監視する必要もあります。

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

詳細は、『 監視ツール設定ガイド』を参照してください。

11.5.1. 更新およびパッチ

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

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

11.5.2. ファイアウォールおよびインスタンスプロファイル

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

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

注記

Red Hat OpenStack Platform では、OpenStack サービス用にカスタマイズされるポリシーと共に、デフォルトで SELinux が有効化されます。必要に応じて、これらのポリシーを定期的に確認することを検討してください。

11.5.2.1. セキュリティーグループ

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

注記

特に無効にする必要がある場合を除き、セキュリティーグループおよびポートセキュリティーを有効なままにしておくべきです。厚い防御のアプローチを構築するには、インスタンスに細かな粒度のルールを適用することが推奨されます。

11.5.3. インスタンスのコンソールへのアクセス

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

  • ファイアウォールルールを使用して VNC ポートをロックダウンすることを検討してください。デフォルトでは、nova_vnc_proxy は 6080 と 13080 を使用します。
  • VNC トラフィックが TLS で暗号化されていることを確認します。director ベースのデプロイメントの場合は、UseTLSTransportForVnc で開始します。

11.5.4. 証明書の挿入

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

詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/15/html-single/instances_and_images_guide/#section-create-imagesを参照してください。

第12章 メッセージキュー

メッセージキューサービスは、OpenStack でのプロセス間通信を容易にします。これは、以下のメッセージキューサービスのバックエンドを使用して行われます。

  • RabbitMQ: Red Hat OpenStack Platform はデフォルトで RabbitMQ を使用します。
  • Qpid

RabbitMQ と Qpid はいずれも Advanced Message Queuing Protocol (AMQP) フレームワークで、ピアツーピア通信用のメッセージキューを提供します。キューの実装は、通常、キューサーバーの集中的または分散プールとしてデプロイされます。

メッセージキューは、OpenStack デプロイメント全体にわたるコマンドおよび制御機能を効果的に容易化します。キューへのアクセスが許可されたら、それ以上の承認チェックは実行されません。キュー経由でアクセス可能なサービスは、実際のメッセージペイロード内のコンテキストおよびトークンを検証します。ただし、トークンは再使用でき、インフラストラクチャー内の他のサービスを承認できるため、トークンの有効期限に注意してください。

OpenStack は、メッセージ署名などのメッセージレベルの機密性をサポートしません。したがって、メッセージトランスポート自体をセキュア化し、認証する必要があります。高可用性 (HA) 設定には、キューツーキュー認証および暗号化を実行する必要があります。

12.1. メッセージングセキュリティー

本項では、OpenStack で使用される最も一般的な 3 つのメッセージキューソリューション（RabbitMQ および Qpid）に対するセキュリティー強化アプローチについて説明します。

12.2. メッセージングトランスポートのセキュリティー

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

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

注記

証明書と鍵ファイルをインストールする場合は、ファイルパーミッションが制限されており (たとえば、chmod 0600 を使用)、メッセージングサーバーの他のプロセスやユーザーによる不正アクセスを阻止するために、その所有権がメッセージングサーバーのデーモンユーザーに制限されるようにしてください。

12.2.1. RabbitMQ サーバーの SSL 設定

以下の行をシステム全体の RabbitMQ 設定ファイル (通常は /etc/rabbitmq/rabbitmq.config) に追加する必要があります。 

[
  {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}]}
   ]}
].
注記

SSL 以外のポートでリッスンしないように、tcp_listeners オプションは [] に設定します。サービスの管理ネットワークでのみリッスンするように、ssl_listeners オプションは制限する必要があります。

12.3. キュー認証およびアクセス制御

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 モジュールを使用します。

12.3.1. RabbitMQ 用 OpenStack サービスの設定

本項では、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
注記

RABBIT_PASS を適切なパスワードに置き換えます。

12.3.2. Qpid 用 OpenStack サービスの設定

本項では、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_PASS を適切なパスワードに置き換えます。

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

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

12.4. メッセージキュープロセスの分離およびポリシー

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

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

12.4.1. Namespaces

Neutron および Open vSwitch (OVS) ネットワークは名前空間内で実行しますが、vswitchd、libvirtd、QEMU などの特定の OVS ホストサービスは実行しません。コンテナー化されたコントロールプレーンを実行する場合、すべてのコントロールプレーンサービスはデフォルトでネットワーク名前空間内で実行されます。ネットワーク名前空間は、Compute ハイパーバイザーで実行するすべてのサービスに強く推奨されます (AMQP サービスを実行するため)。このアプローチは、インスタンスと管理ネットワーク間のネットワークトラフィックのブリッジを防ぐのに役立ちます。

第13章 API エンドポイントの強化

OpenStack クラウドと連携するプロセスは、API エンドポイントをクエリーすることで開始します。パブリックおよびプライベートのエンドポイントにはさまざまな課題がありますが、危険にさらされた場合に重大なリスクが生じる可能性のある価値の高いアセットがあります。

本章では、パブリックおよびプライベート向け API エンドポイント両方のセキュリティーを強化することを推奨しています。

13.1. API エンドポイント構成の推奨事項

このセクションでは、API エンドポイントを強化するための推奨事項について説明します。

13.1.1. 内部 API 通信

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

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

13.1.2. Identity サービスカタログでの内部 URL の設定

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

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

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

13.1.3. 内部 URL のアプリケーションの設定

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

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

13.1.4. Paste およびミドルウェア

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

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

13.1.5. API エンドポイントプロセスの分離およびポリシー

API エンドポイントプロセス、特に、パブリックセキュリティードメイン内に存在するものは、可能な限り分離する必要があります。デプロイメントが許可する場合、分離性を高めるために、API エンドポイントは別のホストにデプロイする必要があります。

13.1.6. Namespaces

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

13.1.7. ネットワークポリシー

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

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

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

13.1.8. 必須のアクセス制御

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

13.1.9. API エンドポイントのレート制限

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

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

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

注記: Red Hat OpenStack Platform デプロイメントの場合、全サービスは負荷分散プロキシーの背後に置かれます。