Red Hat Training

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

第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 を無効にする必要があります。