サーバーを仮想化すると、別のOS層がパッチと更新を行い、作業量が増え、リスクが大きくなりますか？

検索を行ったが、パッチの適用とシステムの更新に関する問題に対処するものは見つかりませんでした。サーバーには必要なパッチが必要であると言うガイドラインがあります。VMホストがある場合、それは、ベアメタルハイパーバイザーであっても、パッチを適用して更新するための追加のレイヤーですか？金属製のサーバーとは対照的に？（つまり、私のガイドラインに従って、より多くの作業とテストとドキュメント）。

タイプ1 /ベアメタルハイパーバイザーはどのくらいの頻度で更新されますか？それは問題ですか？追加のソフトウェアレイヤーであるという事実は、より複雑でリスクを伴いますか（セキュリティと信頼性）？（例：99％バグフリーソフトウェアx 99％バグフリーソフトウェア= 98％バグフリーシステム）？

（私の実務経験は、VMWareワークステーションとサーバー、およびVirtualBoxです。）

はい、VMwareのような製品には時々パッチを適用する必要があります（更新は累積的です）が、パッチはメインラインオペレーティングシステムよりも頻繁に来ず、潜在的な攻撃ベクトルは小さくなります。

例としてVMware ESXiバージョン5.0（5.1ではない）を使用します...

ESXi 5.0には次のアップデートスケジュールがあります。

2011分の9と現在の間、ありましたTENのESXi 5.0商品の最新情報。これらのうち、SIXはセキュリティに焦点を当てた更新であり、次のような説明を含む更新バンドルに組み込まれました

"ESXiのNFSトラフィック解析の脆弱性" - CVE-2012から2448。

これらのセキュリティ脆弱性は、一般的なLinuxセキュリティバグを反映することがあるため、本物ですが、ほとんどの組織はリスクをあまり受けません。ただし、このリスクを評価するのはエンジニアの責任です。ユーザーは、次のエクスプロイトを修正するために大規模なダウンタイムを必要としますか？

「ncpmountおよびmount.cifsで使用されるGNU Cライブラリ（別名glibcまたはlibc6）2.11.1以前のmisc / mntent_r.cのencode_nameマクロは、マウントポイント名の改行文字を適切に処理せず、ローカルユーザーを許可します細工されたマウントリクエストを介して、サービス拒否（mtabの破損）を引き起こしたり、場合によってはマウントオプションを変更して特権を獲得したりします。

多分？そうでないかもしれない。

VMwareのUpdate Managerを実行していますが、バグの影響を受けたり機能の強化が必要な場合にのみ更新する傾向があります。クラスター化されたセットアップで実行すると、実行中のVMにダウンタイムが発生することなく、簡単にパッチを適用できます。他に差し迫った理由がない場合は、四半期ごとに更新するよう努めます。パッチはモノリシックイメージとして配信されるため、個々のホストでは完全な再起動が必要になります。

ちなみに、VMware ESXiセットアップを継承したり、通常は管理していないシステムで作業したりすると、VMwareパッチが適用されていないホストが実行されていることがよくあります。それは間違いです！！しかし、システムが稼働すると、管理者がその間違いをどのように行うことができるかがわかります。

「ベアメタル」ホストを使用した仮想化を初めて使用する場合、これは非常に良い質問です。この方法で物事を行うには、従来のOS上でサービス/アプリケーションとして実行されるハイパーバイザーで取るアプローチに対する異なる考え方が必要です。

私の経験では、ESXとHyperVは、従来のオペレーティングシステムよりも全体的にパッチを当てる必要が少ないと言ってもいいでしょう。これは、パッチを適用する必要がない、または「必要」に関係なくパッチの一部を適用しても有益ではないという意味ではありませんが、ホストにパッチを適用するためのサービスの中断はあまり頻繁に行わず、あなたの管理下にあります。ハイパーバイザーOSには他と同様に潜在的なセキュリティリスクがあり、このリスクの露出を最小限に抑えることができます（たとえば、侵害されたサーバーから論理的に到達できない隔離されたVLANでのみハイパーバイザー管理を公開します）まったくリスクがないふりをするのは愚かなことです。

たとえば、4つの非仮想サーバーがあり、それらをすべて同じ個別の仮想化ホストに移動する場合、はい、ホストシステムにパッチを適用する（または対処する必要がある）ことによって引き起こされる混乱の量を増やしていますハードウェアの問題など）。

このリスクが発生する可能性は比較的低いことをお勧めしますが（仮想ホストへのパッチ適用と、とにかくスタンドアロンシステムに対して行う必要がある再起動が必要なパッチ適用の違いについて話している）、影響が大きいという事実から逃れることはできません。

では、なぜそれを行うのでしょうか？

仮想化の真のメリットは、複数のホストをセットアップし、ホストが連携して動作するように構成できることです。1つのホストに障害が発生したり、パッチをスケジュールしたりした場合にゲストをホスト間で移動できますホストシステム。

このアプローチを使用して、5台のESXホストをその上で実行されている40台の仮想サーバーにまったく混乱を与えることなく順番にパッチすることができました。これは単に規模の経済の問題です-潜在的な仮想ゲストマシンを十分に用意して、この種の複雑なセットアップを構築し、@ ewwhiteが回答で述べたようなツールで管理する価値があるようになったら、リスクを軽減することの見返りすぐに到着するのではないかと心配しています。

仮想サーバーは、物理サーバーと同じメンテナンスとパッチを必要とします。ベアメタルハイパーバイザーは、セキュリティのためだけでなく、バ​​グを修正し、パフォーマンスを向上させるために、更新を必要とします。サーバーが多いほど、サーバーを最新の状態に保つために必要な作業が多くなります。物理サーバーか仮想サーバーかは関係ありません。

上記の回答に基づいて、サーバーの仮想化はセキュリティと信頼性に複雑さとリスクをもたらしましたが、サーバーを仮想化することでダウンタイムを削減できるという利点と比較検討する必要があります。

環境に監査、テスト、およびドキュメントが必要な場合、仮想化環境に追加されたワークロードの費用対効果を、サーバーとシステムスタッフの数とともに考慮する必要があります。私たちの環境では、仮想化された環境の監査証跡を維持するスタッフ/スタッフの時間がありません。私たちのビジネスプロセスでは、ある程度のダウンタイムをとることができますが、監査証跡とドキュメントを見逃すことはできません。