運用環境

運用環境には、物理システムとそのコンポーネント、データセンター設計者、管理者、および IT 組織のメンバーが含まれます。セキュリティー侵害は、運用環境内のどこでも発生する可能性があります。

仮想化では、実際のハードウェアと、本番サービスを実行するゲストドメインの間にソフトウェアのレイヤーが設定されるため、複雑さが増します。そのため、仮想システムを慎重に計画および構成するとともに、人為的ミスに注意する必要があります。また、「ソーシャルエンジニアリング」を使用して運用環境へのアクセスを取得するしようとする攻撃者の試みにも注意してください。

以降のセクションでは、運用環境のレベルで対応できる特徴的な脅威について説明します。

脅威: 意図しない構成ミス

仮想化環境での主なセキュリティー上の問題は、ネットワークセグメントを分離し、管理アクセスを分離し、さらにサーバーを同じセキュリティー要件と権限を持つドメインのグループであるセキュリティークラスに配備することによって、サーバーの分離を維持することです。

仮想リソースを慎重に構成し、次のようなエラーを回避します。

• 本番ゲストドメインと実行環境の間に不要な通信チャネルを作成する

• ネットワークセグメントへの不要なアクセスを作成する

• 個別のセキュリティークラス間に意図しない接続を作成する

• ゲストドメインを間違ったセキュリティークラスに誤って移行する

• 不十分なハードウェアを割り当てる (予期しないリソースの過負荷を招く可能性がある)

• ディスクまたは I/O デバイスを間違ったドメインに割り当てる

対応策: 運用ガイドラインの作成

開始する前に、Oracle VM Server for SPARC 環境の運用ガイドラインを慎重に定義します。これらのガイドラインでは、実行する次のタスクと、それらの実行方法について説明します。

• 環境のすべてのコンポーネントに対するパッチの管理

• 変更の適切に定義され、トレース可能でセキュアな実装の有効化

• 一定間隔でのログファイルのチェック

• 環境の整合性と可用性のモニタリング

チェックを定期的に実行して、これらのガイドラインが最新で、適切な状態に維持されるようにするとともに、日常の運用でこれらのガイドラインに従っていることを確認します。

これらのガイドラインに加えて、意図しないアクションのリスクを軽減するためのいくつかのより技術的な対策を実行できます。Logical Domains Managerを参照してください。

脅威: 仮想環境のアーキテクチャー内のエラー

物理システムを仮想化環境に移行する場合は通常、元の LUN を再利用することによって、ストレージ構成を現状のままに維持できます。ただし、ネットワーク構成は仮想化環境に適応させる必要があるため、結果として得られるアーキテクチャーが物理システム上で使用されているアーキテクチャーと大幅に異なる可能性があります。

個別のセキュリティークラスの分離を維持する方法や、それらのセキュリティークラスのニーズを検討する必要があります。また、プラットフォームの共有ハードウェア、およびネットワークスイッチや SAN スイッチなどの共有コンポーネントも検討してください。

環境のセキュリティーを最大化するために、ゲストドメインとセキュリティークラスの分離を確実に維持するようにしてください。アーキテクチャーを設計する場合は、可能性のあるエラーや攻撃を予測し、防御線を実装します。適切な設計は、複雑さやコストを管理しながら、潜在的なセキュリティーの問題を制限するのに役立ちます。

対応策: ゲストをハードウェアプラットフォームに慎重に割り当てる

同じセキュリティー要件と権限を持つドメインのグループであるセキュリティークラスを使用して、個々のドメインを互いに分離します。同じセキュリティークラスに属するゲストドメインを特定のハードウェアプラットフォームに割り当てることによって、分離の侵害が発生した場合でも、攻撃が別のセキュリティークラスに及ばないようにします。

対応策: Oracle VM Server for SPARC ドメインの移行を計画する

ライブドメイン移行機能には、次の図に示すように、ゲストドメインが別のセキュリティークラスに割り当てられたプラットフォームに誤って移行された場合、分離が破壊される可能性があります。そのため、セキュリティークラスの境界をまたがる移行が許可されることがないように、ゲストドメインの移行を慎重に計画してください。

図 1-4  セキュリティーの境界をまたがるドメイン移行

移行操作によって発生するセキュリティーの脆弱性を最小化または解消するには、ldmd で生成されたホスト証明書を手動で交換し、ソースマシンとターゲットマシンの各ペア間の帯域外にインストールする必要があります。SSL 証明書を設定する方法については、Oracle VM Server for SPARC 3.2 管理ガイド の移行のための SSL 証明書の構成を参照してください。

対応策: 仮想接続を正しく構成する

すべての仮想ネットワーク接続を追跡できなくなると、ドメインがネットワークセグメントへの誤ったアクセスを取得する可能性があります。たとえば、このようなアクセスは、ファイアウォールまたはセキュリティークラスを迂回する可能性があります。

実装エラーのリスクを軽減するには、環境内のすべての仮想および物理接続を慎重に計画し、ドキュメント化します。シンプルで管理しやすいように、ドメイン接続計画を最適化します。本番に移行する前に、計画を明確にドキュメント化し、計画に対する実装の正確性を検証してください。仮想環境が本番に移行したあとであっても、一定間隔で実装を計画に対して検証してください。

対応策: VLAN タグ付けを使用する

VLAN タグ付けを使用すると、複数の Ethernet セグメントを単一の物理ネットワークに統合できます。この機能はまた、仮想スイッチにも使用できます。仮想スイッチの実装でのソフトウェアエラーに関連したリスクを軽減するには、物理 NIC および VLAN ごとに 1 つの仮想スイッチを構成します。Ethernet ドライバ内のエラーからさらに保護するには、タグ付き VLAN の使用を控えます。ただし、このタグ付き VLAN の脆弱性はよく知られているため、このようなエラーが発生する確率は低いです。Oracle VM Server for SPARC ソフトウェアがインストールされた Oracle の Sun SPARC T シリーズプラットフォーム上の侵入テストでは、この脆弱性は示されていません。

対応策: 仮想セキュリティーアプライアンスを使用する

パケットフィルタやファイアウォールなどのセキュリティーアプライアンスは分離のための機器であり、セキュリティークラスの分離を保護します。これらのアプライアンスは、ほかのすべてのゲストドメインと同じ脅威にさらされるため、これを使用しても分離の侵害からの完全な保護は保証されません。そのため、このようなサービスを仮想化することを決定する前に、リスクとセキュリティーのすべての側面を慎重に検討してください。

脅威: リソース共有の副作用

仮想化環境内のリソース共有が、別のコンポーネント (別のドメインなど) に悪影響を与えるまでリソースを過負荷状態にする、サービス拒否 (DoS) 攻撃につながる可能性があります。

Oracle VM Server for SPARC 環境では、DoS 攻撃によって影響を受ける可能性のあるリソースは一部だけです。CPU およびメモリーリソースは各ゲストドメインに排他的に割り当てられるため、ほとんどの DoS 攻撃が回避されます。これらのリソースの排他的な割り当てによってさえ、次のようにゲストドメインの速度が低下することがあります。

• ストランド間で共有され、2 つのゲストドメインに割り当てられているキャッシュ領域のスラッシング

• メモリー帯域幅の過負荷

CPU およびメモリーリソースとは異なり、ディスクおよびネットワークサービスは通常、ゲストドメイン間で共有されます。これらのサービスは、1 つ以上のサービスドメインによってゲストドメインに提供されます。これらのリソースのゲストドメインへの割り当ておよび配分方法を慎重に検討してください。最大のパフォーマンスとリソース使用率を可能にする構成はすべて、同時に副作用のリスクも最小限に抑えることに留意してください。

評価: 共有リソースによる副作用

ドメインに排他的に割り当てられているか、またはドメイン間で共有されているかにかかわらず、ネットワークリンクが飽和したり、ディスクが過負荷状態になったりする場合があります。このような攻撃は、その攻撃の間、サービスの可用性に影響を与えます。攻撃のターゲットが危険にさらさることはなく、データが失われることもありません。この脅威の影響を最小限に抑えることは簡単ですが、Oracle VM Server for SPARC 上のネットワークおよびディスクリソースに制限されるとしても、この脅威に注意するようにしてください。

対応策: ハードウェアリソースを慎重に割り当てる

ゲストドメインには、必要なハードウェアリソースのみを割り当てるようにしてください。未使用のリソースは、そのリソースが必要なくなったら必ず割り当てを解除してください。たとえば、インストール中にのみ必要なネットワークポートまたは DVD ドライブがあります。これを実践することによって、攻撃者にとって可能性のあるエントリポイントの数が最小限に抑えられます。

対応策: 共有リソースを慎重に割り当てる

物理ネットワークポートなどの共有ハードウェアリソースは、DoS 攻撃にとって可能性のあるターゲットになります。DoS 攻撃の影響をゲストドメインの単一のグループに制限するには、どのゲストドメインがどのハードウェアリソースを共有するかを慎重に決定してください。

たとえば、ハードウェアリソースを共有するゲストドメインを、同じ可用性またはセキュリティー要件でグループ化することもできます。グループ化にかかわらず、異なる種類のリソース制御を適用できます。

ディスクおよびネットワークリソースを共有する方法を検討する必要があります。専用の物理アクセスパスまたは専用の仮想ディスクサービスを通してディスクアクセスを分離することによって、問題を軽減できます。

サマリー: 共有リソースによる副作用

このセクションで説明されているすべての対応策では、配備の技術的な詳細と、そのセキュリティーへの影響を理解する必要があります。アーキテクチャーを慎重に計画し、適切にドキュメント化し、さらにできるだけシンプルに維持してください。Oracle VM Server for SPARC ソフトウェアのセキュアな配備を準備できるように、仮想化されたハードウェアの影響を理解するようにしてください。

CPU やメモリーの共有は実際にはほとんど発生しませんが、論理ドメインはそれらの共有の影響に対して堅牢です。それにもかかわらず、ゲストドメイン内での Solaris リソース管理などのリソース制御を適用することが最善です。これらの制御を使用すると、仮想環境と仮想化されていない環境のどちらでも、不正なアプリケーション動作から保護されます。