Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

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

Red Hat OpenStack Platform 13

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

OpenStack Documentation Team

概要

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

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。

Red Hat ドキュメントへのフィードバック (英語のみ)

弊社ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があればお知らせください。

ドキュメントへのダイレクトフィードバック (DDF) 機能の使用 (英語版のみ)

特定の文章、段落、またはコードブロックに対して直接コメントを送付するには、DDF の Add Feedback 機能を使用してください。なお、この機能は英語版のドキュメントでのみご利用いただけます。

  1. Multi-page HTML 形式でドキュメントを表示します。
  2. ドキュメントの右上隅に Feedback ボタンが表示されていることを確認してください。
  3. コメントするテキスト部分をハイライト表示します。
  4. Add Feedback をクリックします。
  5. Add Feedback フィールドにコメントを入力します。
  6. (オプション) ドキュメントチームが連絡を取り問題についてお伺いできるように、ご自分のメールアドレスを追加します。
  7. Submit をクリックします。

第1章 セキュリティーの概要

Red Hat Openstack Platform (RHOSP) で提供されるツールを使用して、計画や操作においてセキュリティーの優先順位付けを行い、ユーザーのプライバシーとデータのセキュリティーを強化します。セキュリティー標準の実装に失敗すると、ダウンタイムやデータ違反が発生します。ユースケースは、監査プロセスおよびコンプライアンスプロセスを通過する必要のある法律が適用される場合があります。注記

本章の手順に従って、お使いの環境のセキュリティーを強化します。ただし、これらの推奨事項はセキュリティーやコンプライアンスを保証しません。環境が独自の要件に基づいてセキュリティーを評価する必要があります。

Ceph を強化する方法は、データセキュリティーおよび強化ガイドを参照してください。

1.1. Red Hat OpenStack Platform セキュリティー

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

SElinux
SELinux は、各プロセスに必要なアクセス制御を提供して、すべてのアクションに明示的なパーミッションを提供することで、RHOSP のセキュリティー拡張機能を提供します。
Podman
コンテナーツールとしての Podman は、root アクセスを持つプロセスが機能する必要のあるクライアント/サーバーモデルを使用しないため、RHOSP のセキュアなオプションです。
システムアクセスの制限
オーバークラウドのデプロイメント時に director が heat-admin に作成する SSH 鍵またはオーバークラウドで作成した SSH キーのいずれかを使用して、オーバークラウドノードにログインすることができます。オーバークラウドノードにログインしてオーバークラウドノードにパスワードで SSH を使用したり、root を使用してオーバークラウドノードにログインしたりすることはできません。

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

  • パブリック TLS および TLS-everywhere
  • OpenStack Key Manager (barbican) とハードウェアセキュリティーモジュールの統合
  • 署名付きイメージおよび暗号化されたボリューム
  • ワークフロー実行を使用したパスワードおよび fernet 鍵のローテーション

1.2. セキュリティーゾーン

セキュリティーゾーンは、共通のセキュリティー上の懸念を共有する一般的なリソース、アプリケーション、ネットワーク、およびサーバーです。セキュリティーゾーンは、同じ認証および承認要件およびユーザーを共有する必要があります。

独自のセキュリティーゾーンを再定義して、クラウドの一意のアーキテクチャー、環境内で許可される信頼レベル、および標準化された要件に基づいて、より粒度の高いセキュリティーゾーンを再定義する必要がある場合があります。ゾーンとその信頼要件は、クラウドインスタンスがパブリック、プライベート、またはハイブリッドであるかによって異なります。

セキュリティーが強化された OpenStack クラウドをデプロイするのに必要な最小ゾーンは、少なくとも信頼されているものから最も高いものになります。

  • パブリックゾーン: パブリックゾーンは、パブリック向け API およびインスタンスの外部接続向けに Floating IP や SNAT などの neutron 外部ネットワークをホストします。このゾーンは、クラウドインフラストラクチャーの信頼できない領域です。これは、クラウドアクセス、またはご自分の領域外のネットワークへのクラウドアクセス、または Red Hat OpenStack Platform デプロイメント外にある責任のいずれかを指します。

このゾーンを通過する機密性または整合性要件のあるデータは、補正制御を使用して保護する必要があります。

  • ゲストゾーン: ゲストゾーンのプロジェクトネットワーク (VXLAN または GENEVE のいずれか)これは、インスタンスが使用する文字列に関連する制御を持たないパブリックおよびプライベートクラウドプロバイダーでは信頼されないか、インスタンスへの無制限のインターネットアクセスを許可します。

プライベートのクラウドプロバイダーの場合は、インスタンスと関連するプロジェクトをアサートして基盤のハードウェアと物理ネットワークを組み込むように制御が実装されている場合には、このネットワークを内部と信頼済みとみなすことができます。

  • ストレージアクセスゾーン: ストレージアクセスゾーンは、ストレージ管理、モニターリング、およびクラスターリング用で、ストレージトラフィック自体です。

このネットワーク上で送信されるデータには、高いレベルの整合性と機密性が必要です。利用できる利用できる要件もある。

レプリケーション要件を除き、このゾーンにデプロイされたストレージアプライアンスコンポーネント以外、クラウド外からこのネットワークにアクセスできるようにしないでください。

  • 管理ゾーン: 管理ゾーンには、アンダークラウド、ホストオペレーティングシステム、サーバーハードウェア、物理ネットワーク、および Red Hat OpenStack Platform director コントロールプレーンが含まれます。

管理ネットワークは、システム管理、監視、またはバックアップに使用されます。このゾーン上で、OpenStack API をホストしたり、インターフェイスを制御したりしないでください。

  • 管理ゾーン: 管理ゾーンは、システム管理、モニターリング、またはバックアップのトラフィックをホストしますが、OpenStack API または制御インターフェイスがホストされない場所です。

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.2. アウトバウンド攻撃と風評被害の危険

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

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

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

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

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

第2章 ドキュメント

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

2.1. システムロールとタイプ

環境で使用されるロールのドキュメントOpenStack インストールを一般的に設定する、幅広い 2 種類のノードタイプは以下のとおりです。

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

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

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

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

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

  • MySQL や mongoDB などのシステムデータベース
  • Identity や Compute などの OpenStack ソフトウェアコンポーネント
  • ロードバランサーのコンポーネント、リバースプロキシー、DNS、または DHCP サービスなどのコンポーネントをサポートするには、ライブラリー、アプリケーション、またはソフトウェアのクラスにおける不正使用の影響を評価する際に、ソフトウェアコンポーネントの信頼できるリストが重要になります。

第3章 暗号化および鍵の管理

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

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

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

3.1. TLS と SSL の概要

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

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

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

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

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 が証明書失効リストの公開を委譲するオプションのシステム。
  • 証明書リポジトリー: エンドエンティティー証明書および証明書失効リストが保存され、クエリーされる場所 (証明書バンドルと呼ばれることもあります)。

3.3. 認証局

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

注記

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

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

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

注記

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

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

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

3.5. TLS ライブラリー

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

3.6. 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 の非推奨化がアップストリームからバックポートされることが予想されます。

3.6.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 バージョンのアドバタイズメントサポート中に接続できなかったことを意味します。そのため、スキャンされたサーバーでプロトコルの (およびそれより低い) バージョンが有効ではないことを確認する必要があります。

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

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 サービスで有効化または無効化する必要のある特定のアルゴリズムまたは暗号モードに関する規定はありません。

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

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

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

3.9. Perect Forward Secrecy

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

3.10. 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/13/html-single/manage_secrets_with_openstack_key_manager/ を参照してください。

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

Identity サービス (keystone) は、クラウドユーザーの認証と承認を提供し、セキュリティー上の考慮事項に重要なコンポーネントです。

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

4.1. 認証

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

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

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

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

4.2. 無効なログイン試行

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

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

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

4.3. 承認

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

4.4. Formal Access Control Policies を確立

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

4.5. サービス承認

クラウド管理者は、各サービスの 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 を設定します。この設定は、他のコンポーネントの証明書も無効になります。コンテナー化されたサービスでは、ファイルパスが異なる場合があります。

4.6. トークン

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

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

4.6.1. 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 トークンには存在しません。

Fernet トークンおよびローテーションの Fernet キーに関する情報は https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/13/html-single/deploy_fernet_on_the_overcloud/ を参照してください。

4.7. 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 ファイルでオプションを使用します。

4.8. LDAP での認証

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

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

外部認証では、既存の認証情報を使用して、追加の 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 属性にマッピングします。

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

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

4.9.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/13/html-single/integrate_with_identity_service/ を参照してください。

第5章 ポリシー

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

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

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

5.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 を使用します。

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

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

5.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 であることをチェックします。

5.3. ポリシー構文

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

"identity:create_user": "rule:admin_required"

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

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

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

"identity:create_user": "!"

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

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

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

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

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. 以下のエントリーを /var/lib/config-data/puppet-generated/nova/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"
    }

    このファイルを保存して nova コンテナーを再起動する際に、変更を実装する。PowerUsers keystone ロールに追加したユーザーは、これらの権限を受信します。

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

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 構文オプションの詳細は、ポリシー構文 を参照してください。

5.7. ユーザーおよびロールの監査

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

  1. openstack role list コマンドを実行して、環境内の現在ロールを表示します。

    openstack role list -c Name -f value
    
    swiftoperator
    ResellerAdmin
    admin
    _member_
    heat_stack_user
  2. openstack role assignment list コマンドを実行して、特定のロールのメンバーであるすべてのユーザーを一覧表示します。たとえば、admin ロールを持つユーザーを確認するには、以下を実行します。

    $ openstack role assignment list --names --role admin
    +-------+------------------------------------+-------+-----------------+------------+--------+-----------+
    | Role  | User                               | Group | Project         | Domain     | System | Inherited |
    +-------+------------------------------------+-------+-----------------+------------+--------+-----------+
    | admin | heat-cfn@Default                   |       | service@Default |            |        | False     |
    | admin | placement@Default                  |       | service@Default |            |        | False     |
    | admin | neutron@Default                    |       | service@Default |            |        | False     |
    | admin | zaqar@Default                      |       | service@Default |            |        | False     |
    | admin | swift@Default                      |       | service@Default |            |        | False     |
    | admin | admin@Default                      |       | admin@Default   |            |        | False     |
    | admin | zaqar-websocket@Default            |       | service@Default |            |        | False     |
    | admin | heat@Default                       |       | service@Default |            |        | False     |
    | admin | ironic-inspector@Default           |       | service@Default |            |        | False     |
    | admin | nova@Default                       |       | service@Default |            |        | False     |
    | admin | ironic@Default                     |       | service@Default |            |        | False     |
    | admin | glance@Default                     |       | service@Default |            |        | False     |
    | admin | mistral@Default                    |       | service@Default |            |        | False     |
    | admin | heat_stack_domain_admin@heat_stack |       |                 | heat_stack |        | False     |
    | admin | admin@Default                      |       |                 |            | all    | False     |
    +-------+------------------------------------+-------+-----------------+------------+--------+-----------+
    注記

    -f {csv,json,table,value,yaml} パラメーターを使用して、これらの結果をエクスポートできます。

5.8. API アクセスの監査

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

  • ターゲットロールのユーザーとしてソースとする認証ファイル。
  • JSON 形式のアクセストークン
  • 監査する各サービスの API のポリシーファイル。

手順

  1. 次に、必要なロールでユーザーの認証ファイルを一時停止します。
  2. Keystone 生成されたトークンを取得し、ファイルに保存します。そのためには、openstack-cli コマンドを実行し、--debug オプションを指定して、指定したトークンを stdout に出力します。このトークンをコピーして、アクセスファイルに保存できます。このコマンドを 1 つのステップとして実行します。

    openstack token issue --debug 2>&1 | egrep ^'{\"token\":' > access.file.json
  3. ポリシーファイルを作成します。これは、コンテナー化されたサービスをホストするオーバークラウドノード上で実行できます。以下の例では、cinder サービスのポリシーファイルを作成します。

    ssh heat-admin@CONTROLLER-1 sudo docker exec cinder_api \
    oslopolicy-policy-generator \
    --config-file /etc/cinder/cinder.conf \
    --namespace cinder > cinderpolicy.json
  4. これらのファイルを使用して、cinder の API にアクセスするための対象のロールを監査できるようになりました。

    oslopolicy-checker --policy cinderpolicy.json --access access.file.json

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

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

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

注記

更新の追跡に加えて、プロセスとデプロイメントが通常のセキュリティー更新のインストールに対応できるようにしてください。また、以下のガイドラインを使用します。

  • プロセスを設計する際に、インスタンスのセキュリティー更新を追加します。
  • カーネルの更新のために、コンピュートノードと管理ノードをリブートします。
  • ホスト Image サービス (glance) のイメージを定期的に更新して、新規に作成されるインスタンスが最新の更新を持つようにします。

6.1. ハイパーバイザー

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

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

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

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

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

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

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

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

6.2. PCI パススルー

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

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

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

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

6.3. SELinux

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 仮想マシンを使用できます。

6.3.1. ラベルとカテゴリー

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

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

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

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

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

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

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

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 コントロールをバイパスする可能性がある場合は、ストレージサブシステムから完全な仮想マシンイメージを取得できるためです。

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

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

6.7. Block Storage

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

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

6.7.1. ボリュームの接続

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

注記

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

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

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

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

cinder グループはホストにありません。ls -l を使用すると、グループ所有者の GID が表示されます。

sudo ls -l /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf
-rw-r-----. 1 root 42407 188012 Dec 11 09:34 /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf

sudo stat -L -c "%U %G" /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf
root UNKNOWN

以下のコマンドで、cinder.conf 設定ファイルのユーザーおよびグループの所有権が root および cinder に設定されていることを確認します。

sudo docker exec -it cinder_api stat -L -c "%U %G" /etc/cinder/cinder.conf
root cinder

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

cinder.conf 設定ファイルのパーミッションが 640 またはより厳格に設定されていることを確認します。

$ stat -L -c "%a" /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf

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

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

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

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

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

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

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

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

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

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

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

6.8. Networking

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

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

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

6.8.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-agentneutron-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 はネットワークコンポーネント (ルーティングなど) をコンピュートノードに移行する一方で、まだネットワークノードが必要です。したがって、コンピュートノードはパブリックネットワーク間のアクセスを必要とするため、ファイアウォールルールとセキュリティーモデルがこのアプローチをサポートする必要があるため、公開機能が高まり、お客様が追加でセキュリティーを考慮する必要があります。

6.8.2. 物理サーバーでの 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 割り当て範囲を使用する外部ネットワークのサブネットを作成することができるので、外部ネットワークと同じネットワークである可能性があります。このネットワークは、パブリックセキュリティーゾーンにあると見なされます。

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

6.8.3. セキュリティーゾーン

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

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

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

.

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

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

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

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

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

6.8.6. VLAN

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

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

6.8.7. L2 トンネリング

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

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

6.8.8. アクセス制御リスト

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

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

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

6.8.11. Load balancing

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

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

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

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

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

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

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

# Port the bind the API server to
bind_port = 9696

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

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

注記

RPC 通信を必要とするすべてのコンポーネント用に、「キュー認証およびアクセス制御」 に記載されているガイドラインに従うことが推奨されます。

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

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

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

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

注記

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

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

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

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

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

6.8.18. クォータ

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

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

quota_driver = neutron.db.quota_db.DbQuotaDriver

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

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

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

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

neutron グループはホストにありません。ls -l を使用すると、グループ所有者の GID が表示されます。

sudo ls -l /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf
-rw-r-----. 1 root 42435 41748 Dec 11 09:34 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf

sudo stat -L -c "%U %G" /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf
root UNKNOWN

neuton.conf 設定ファイルのユーザーおよびグループの所有権が、それぞれ root および neutron に設定されていることを確認します。

sudo docker exec -it neutron_api stat -L -c "%U %G" /etc/neutron/neutron.conf
root neutron

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

neutron.conf 設定ファイルのパーミッションが 640 またはより厳格に設定されていることを確認します。

$ stat -L -c "%a" /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf

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

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

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

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

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

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

第7章 ネットワークタイムプロトコル

Red Hat OpenStack Platform クラスター内のシステムが、システム間で正確かつ一貫性のあるタイムスタンプを持つことを確認する必要があります。

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

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

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

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

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

7.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 環境内で実行中のサービスコンテナーは、それらのサービスが存在するホストから時刻を受信します。

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

Red Hat OpenStack Platform director を使用して、デプロイメントプロセスの一部としてセキュリティーの強化値を適用します。OpenStack 設定ファイルは director により管理され、直接編集した場合には上書きすることができます。

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

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

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

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

この例では、098099 は、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 モジュールでサポートされる追加パラメーターのハッシュ

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

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

  1. /home/stack/templates/ ディレクトリーに aide.yaml というファイルとして設定を保存します。
  2. OS::TripleO::Services::Aide パラメーターの値が相対パスから絶対パスに変更されるようにする必要があります。

        OS::TripleO::Services::Aide: /usr/share/openstack-tripleo-heat-templates/puppet/services/aide.yaml
  3. ご自分の環境に固有のその他すべての heat テンプレートおよび環境ファイルと共に、/home/stack/templates/aide.yaml 環境ファイルを openstack overcloud deploy コマンドに追加します。

    openstack overcloud deploy --templates
    ...
    -e /home/stack/templates/aide.yaml

8.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.*')。

8.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 へのパスを設定します。

8.4.3. AIDE の cron 設定

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

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

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

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

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

8.6. Identity サービスの CADF 監査

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

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

  parameter_defaults:
    KeystoneNotificationFormat: cadf

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

第9章 Dashboard サービスの強化

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

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

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

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

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

9.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) (本書で説明されている) を設定することにより、このリスクをさらに軽減できます。

9.1.2. ALLOWED_HOSTS の設定

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    parameter_defaults:
      ControllerExtraConfig:
        horizon::disallow_iframe_embed: false

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

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

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

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

9.2.5. HTTP Strict Transport Security (HSTS)

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

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

enable_secure_proxy_ssl_header: true

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

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

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

9.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'

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

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

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

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

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

注記

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

9.6. 静的メディア

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

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

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

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

9.9. iframe 埋め込みの拒否

注記

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

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

    parameter_defaults:
      ControllerExtraConfig:
        horizon::disallow_iframe_embed: false

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

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

注記

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

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

    parameter_defaults:
      ControllerExtraConfig:
        horizon::disable_password_reveal: false

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

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

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

9.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 プロセスを実行するたびに、管理対象外の変更が上書きされます。

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

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

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

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

manila の詳細については、ストレージガイド https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/13/html-single/storage_guide/ を参照してください。

10.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.confmanila-rootwrap の設定および rootwrap.d/share.filters の共有ノードの manila-rootwrap コマンドフィルターに書き込みできる必要があります。

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

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

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

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

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

10.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 は、生成する共有用サーバーでユーザーが識別するセキュリティーサービスを設定することができます。

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

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

注記

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

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

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

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

注記

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

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

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

注記

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

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

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

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

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

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

注記

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

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

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

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

  • プロジェクトが、セキュリティーサービスの詳細を提供する。
  • 管理者がセキュリティーサービスに対応する (このようなセキュリティーサービスのサーバー側を設定する)。
  • manila API 内で、security_serviceshare_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 アプローチを統合するサービスが提供されます。

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

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

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

policy.json ファイルに従って、ファイル共有の所有者として、管理者およびユーザーは、アクセスルールを作成することにより、ファイル共有へのアクセスを管理できます。manila access-allowmanila 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 です。

10.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 認証方法によりアクセスを制御できます。

10.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 コードからデフォルトのポリシーを生成することができます。

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

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

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

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

  • プロキシーサービス
  • 認証サービス
  • ストレージサービス

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

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

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

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

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

注記

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

注記

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

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

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

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

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

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

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

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

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

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

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

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

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

注記

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

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

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

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

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

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

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

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

11.4.2. ロードバランサー

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

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

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

11.5. Object Storage の認証

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

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

11.5.1. Keystone

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

11.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/13/html-single/manage_secrets_with_openstack_key_manager/) を参照してください。

11.7. その他の項目

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

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

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

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

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

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

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

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

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

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

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

重要

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

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

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

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

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

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

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

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

13.1.1. データ保持

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

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

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

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

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

13.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 ボリュームデータ
  • コンピュートインスタンスの一時ストレージ
  • ベアメタルサーバーのサニタイズ

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

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

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

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

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

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

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

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

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

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

13.1.7. Compute のソフト削除機能

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

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

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

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

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

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

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

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

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

注記

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

13.2.1. ハードウェアの特定

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

13.3. データの暗号化

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

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

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

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

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

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

13.3.1. ボリュームの暗号化

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

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

13.3.2. エフェメラルディスク暗号化

エフェメラルディスク暗号化機能はデータのプライバシーに対処します。エフェメラルディスクは、仮想ホストオペレーティングシステムによって使用される一時的なワークスペースです。暗号化しないと、このディスク上のユーザーの機密情報にアクセスでき、ディスクがアンマウントされた後も痕跡情報が残る可能性があります。次のエフェメラルディスク暗号化機能がサポートされています。

13.3.2.1. 暗号化された LVM エフェメラルディスクの作成と使用

注記

コンピュートサービスは現在、LVM 形式でのエフェメラルディスクの暗号化のみをサポートしています。

コンピュート設定ファイル (/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 の使用を必要とするバックエンドキーマネージャーからのキーサイズ制限がある可能性があることに注意してください。これは、128 ビットの AES キーサイズのみを提供します。XTS は、AES が必要とする暗号化キーに加えて、独自の微調整キーを必要とします。これは通常、単一の大きなキーとして表現されます。この場合、512 ビット設定を使用すると、256 ビットが AES で使用され、256 ビットが XTS で使用されます。(NIST を参照)

13.3.2.2. キー管理サービスとのやりとり

キー管理サービスは、プロジェクトごとにエフェメラルディスク暗号化キーを提供することで、データの分離をサポートします。セキュリティーを強化するために、エフェメラルディスク暗号化がバックエンドキーストレージでサポートされています。キー管理サービスを使用すると、エフェメラルディスクが不要になったときに、単にキーを削除するだけで、エフェメラルディスクストレージ領域を上書きできます。

13.3.3. Object Storage オブジェクト

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

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

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

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

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

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

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

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

13.3.5. ネットワークデータ

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

13.4. キー管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

filteringWorkflow1

注記

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

重要

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

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

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

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

14.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 から取得された署名済みインスタンスを自動的に検証します。この検証に失敗すると、ブートプロセスは開始しません。

注記

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

14.4. インスタンスの移行

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

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

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

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

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

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

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

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

14.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) を制限します。

14.4.2.2. 移行ネットワーク

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

14.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 を参照してください。

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

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

注記

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

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

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

14.5.1. 更新およびパッチ

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

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

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

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

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

注記

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

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

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

注記

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

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

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

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

14.5.4. 証明書の挿入

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

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

第15章 メッセージキュー

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

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

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

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

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

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

このセクションでは、OpenStack で使用される 3 つの最も一般的なメッセージキューイングソリューションのセキュリティー強化アプローチ (RabbitMQ および Qpid) を説明します。

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

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

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

注記

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

15.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 オプションは制限する必要があります。

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

15.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 を適切なパスワードに置き換えます。

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

15.4. メッセージキュープロセスの分離およびポリシー

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

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

15.4.1. Namespaces

Neutron および Open vSwitch (OVS) ネットワークは名前空間内で実行しますが、vswitchd、libvirtd、QEMU などの特定の OVS ホストサービスは実行しません。コンテナー化されたコントロールプレーンを実行する場合、すべてのコントロールプレーンサービスはデフォルトでネットワーク名前空間内で実行されます。ネットワーク名前空間は、Compute ハイパーバイザーで実行するすべてのサービスに強く推奨されます (AMQP サービスを実行するため)。このアプローチは、インスタンスと管理ネットワーク間のネットワークトラフィックのブリッジを防ぐのに役立ちます。

第16章 API エンドポイントの強化

OpenStack クラウドと連携するプロセスは、API エンドポイントをクエリーすることで開始します。パブリックおよびプライベートのエンドポイントにはさまざまな課題がありますが、危険にさらされた場合に重大なリスクが生じる可能性のある価値の高いアセットがあります。

本章では、パブリックおよびプライベート向け API エンドポイント両方のセキュリティーを強化することを推奨しています。

16.1. API エンドポイント設定の推奨事項

このセクションでは、API エンドポイントを強化するための推奨事項について説明します。

16.1.1. 内部 API 通信

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

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

16.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 を参照してください。

16.1.3. 内部 URL のアプリケーションの設定

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

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

16.1.4. Paste およびミドルウェア

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

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

16.1.5. API エンドポイントプロセスの分離およびポリシー

API エンドポイントプロセス、特に、パブリックセキュリティードメイン内に存在するものは、可能な限り分離する必要があります。デプロイメントが許可する場合、分離性を高めるために、API エンドポイントは別のホストにデプロイする必要があります。

16.1.6. Namespaces

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

16.1.7. ネットワークポリシー

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

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

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

16.1.8. 必須のアクセス制御

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

16.1.9. API エンドポイントのレート制限

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

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

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

注記: Red Hat OpenStack Platform デプロイメントの場合、全サービスは負荷分散プロキシーの背後に置かれます。

第17章 フェデレーションの実装

警告

現時点では、Red Hat はフェデレーションをサポートしていません。これはテスト目的にのみご利用いただく機能で、実稼働環境にデプロイすべきではありません。

17.1. 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 はユーザーがプロジェクトにアクセスするのを許可します。

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

本セクションでは、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/13/html-single/federate_with_identity_service/) を参照してください。

法律上の通知

Copyright © 2017 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA").An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/.In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
OpenStack Security Guide から採用された部分。ドキュメントについては、Red Hat OpenStack Platform Licenses のセキュリティーガイドを参照してください。
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent.Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack Logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission.We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.