新年は非常に独創的な方法で始まりました。 保守サービスは、家族の集まりの代わりに、MeltdownおよびSpectreプロセッサの脆弱性の発生を注意深く監視しました。 理論的には、それらは顧客データとキーに対する脅威を意味していました。 要するに、脆弱性の実装は次のようになります。
-AKSUを販売していますか？
-いや。
-そしてKPVT？
-いや。
-そして手rena弾？
「ええ、これはそうではありません。」
つまり、プロセッサの応答時間を測定することにより、物理ホストのRAMに保存されているものを間接的に明確にするクエリシステムを構築できます。 1月の前半に、OSおよびハイパーバイザーのメーカーは、この機会を利用できないようにするパッチを展開しましたが、同時にシステムパフォーマンスの一部を削減しました。
システムコールのピークが予想され、クラウドリソースの消費が10％以上増加する可能性があるため、DBMSについて非常に心配していました。
少し先を見据えて-何らかの理由で、MS SQLはパッチを迅速に処理します。
性能試験
テストなしでTechnoservクラウドにロールバックしないため、これらのパッチを完全に装備しました。ESXiとWinServer 2012がインストールされた2つのテスト環境を作成しました。
テスト結果は奇妙でした。 こちらがテスト方法です。
設定と条件を開始します。
更新されたシステム
サーバー：
Dell PowerEdge R630
2 x Intel Xeon E5-2690 v4 2.6 GHz
320 GBのRAM
UEFI v2.7.0
ハイパーバイザー：VMware ESXi 6.0ビルド7504637
仮想マシン：
VMバージョン11
8 vCPU（1ソケット）
24 GB RAM
ディスク0（システム）シックプロビジョニングEager Zeroed-Dell SC9000 SSD + HDDプロファイル上のPVSCSI Controller 0
ディスク1（DBファイル）シックプロビジョニングEager Zeroed-Dell SC9000 SSDプロファイルのPVSCSI Controller 1
ディスク2（トランザクションログファイル）シックプロビジョニングEager-Dell SC9000 SSDプロファイルのPVSCSI Controller 2
NIC：VMXNet3
OS：Microsoft Windows Server 2012 R2 s2018-01マンスリーロールアップ（KB4056895）
DB：Microsoft SQL Server 2016 Enterprise Edition SP1
テスト：
7-Zip v16.04 64ビット（4 CPUスレッド/ 192 MB辞書）
HammerDB v2.23（32ウェアハウス、8 vUsers、Rampup時間2分、テスト時間10分）
未解決のシステム
サーバー：
Dell PowerEdge R630
2 x Intel Xeon E5-2690 v4 2.6 GHz
320 GBのRAM
UEFI v2.6.0
ハイパーバイザー：VMware ESXi 6.0 Build 5572656
仮想マシン：
VMバージョン11
8 vCPU（1ソケット）
24 GB RAM
ディスク0（システム）シックプロビジョニングEager Zeroed-Dell SC9000 SSD + HDDプロファイル上のPVSCSI Controller 0
ディスク1（DBファイル）シックプロビジョニングEager Zeroed-Dell SC9000 SSDプロファイルのPVSCSI Controller 1
ディスク2（トランザクションログファイル）シックプロビジョニングEager-Dell SC9000 SSDプロファイルのPVSCSI Controller 2
NIC：VMXNet3
OS：Microsoft Windows Server 2012 R2 s2017-12のマンスリーロールアップ（KB4054519）
DB：Microsoft SQL Server 2016 Enterprise Edition SP1
テスト：
7-Zip v16.04 64ビット（4 CPUスレッド/ 192 MB辞書）
HammerDB v2.23（32ウェアハウス、8 vUsers、Rampup時間2分、テスト時間10分）
サーバー：
Dell PowerEdge R630
2 x Intel Xeon E5-2690 v4 2.6 GHz
320 GBのRAM
UEFI v2.7.0
ハイパーバイザー：VMware ESXi 6.0ビルド7504637
仮想マシン：
VMバージョン11
8 vCPU（1ソケット）
24 GB RAM
ディスク0（システム）シックプロビジョニングEager Zeroed-Dell SC9000 SSD + HDDプロファイル上のPVSCSI Controller 0
ディスク1（DBファイル）シックプロビジョニングEager Zeroed-Dell SC9000 SSDプロファイルのPVSCSI Controller 1
ディスク2（トランザクションログファイル）シックプロビジョニングEager-Dell SC9000 SSDプロファイルのPVSCSI Controller 2
NIC：VMXNet3
OS：Microsoft Windows Server 2012 R2 s2018-01マンスリーロールアップ（KB4056895）
DB：Microsoft SQL Server 2016 Enterprise Edition SP1
テスト：
7-Zip v16.04 64ビット（4 CPUスレッド/ 192 MB辞書）
HammerDB v2.23（32ウェアハウス、8 vUsers、Rampup時間2分、テスト時間10分）
未解決のシステム
サーバー：
Dell PowerEdge R630
2 x Intel Xeon E5-2690 v4 2.6 GHz
320 GBのRAM
UEFI v2.6.0
ハイパーバイザー：VMware ESXi 6.0 Build 5572656
仮想マシン：
VMバージョン11
8 vCPU（1ソケット）
24 GB RAM
ディスク0（システム）シックプロビジョニングEager Zeroed-Dell SC9000 SSD + HDDプロファイル上のPVSCSI Controller 0
ディスク1（DBファイル）シックプロビジョニングEager Zeroed-Dell SC9000 SSDプロファイルのPVSCSI Controller 1
ディスク2（トランザクションログファイル）シックプロビジョニングEager-Dell SC9000 SSDプロファイルのPVSCSI Controller 2
NIC：VMXNet3
OS：Microsoft Windows Server 2012 R2 s2017-12のマンスリーロールアップ（KB4054519）
DB：Microsoft SQL Server 2016 Enterprise Edition SP1
テスト：
7-Zip v16.04 64ビット（4 CPUスレッド/ 192 MB辞書）
HammerDB v2.23（32ウェアハウス、8 vUsers、Rampup時間2分、テスト時間10分）
結果は次のとおりです。
パッチを当てた
パッチ未適用
パッチを当てた
パッチ未適用
パッチを当てた
パッチ未適用
より重いテストでは、更新されたシステムはわずかに低いパフォーマンスを示します：
HammerDB v2.23（ウェアハウス：128、vUsers：24、ユーザーごとのトランザクション合計：1,000,000、ランプアップ時間：2分、テスト時間：10分、ユーザー遅延：500ms、繰り返し遅延：500ms）
パッチ未適用
パッチ未適用
パッチを当てた
パッチを当てた
SQL-一部のテストでは、パッチが適用されたシステムの結果は、パッチが適用されていないシステムよりも高い（高速）です。 これは非常に奇妙です。 この現象を説明することはできません-おそらく、累積更新では、作業を最適化する何か他のものが来たという事実でしょう。 はい、合成負荷を与えましたが、まだ実稼働環境の負荷とほぼ同じであるため、研究方法自体にはほとんど当てはまりません。
より複雑なテストの場合、パフォーマンスの低下は顕著ですが、10％を超えませんでした。
脅威評価
パッチを適用したハイパーバイザーでは、クラウドクライアントが使用しているゲストオペレーティングシステム（パッチを適用するかどうかに関係なく）は関係ありません。 つまり、更新後（既に完了しているため、インフラストラクチャ全体で合計4日かかったため、ダウンタイムなしでVMを慎重に前後に移行します）、クラウドはSpecterおよびMetldownから保護されます。
保護が確立される前に有効だったエクスプロイトの証拠は見つかりませんでした。
この脆弱性の詳細な評価は、大規模なクラウドで使用する理由はほとんどないことを示唆しています。直接攻撃を仕掛けるのは非常に困難です。 はい、攻撃者は自分のプロセスを展開し、カーネルまたは別のプロセスのメモリを調べることができますが、仮想マシンと他の誰かがいる同じ物理ホスト上でのみ可能です。 つまり、次のことが必要です。
- ターゲットがこのクラウド内にあることを知ってください。
- ストリーミング保護によって検出されない悪意のあるプロセスを引き出します。
- ターゲットと同じ物理ホストにデプロイします。
パブリッククラウドのリソースの少なくとも半分を引き換えない限り、後者はほとんどありません。 VMWare DRSは、それは実現しますが、VMの小さな部分を移動します。
インフラストラクチャサービスは、別のリソースクラスターで動作します。 クライアントの仮想マシンが回転しているホストと、インフラストラクチャの仮想マシンが存在するホストを物理的に分離しています。
プライベートクラウドのユーザーは何も心配していませんでした。 他のシステムと共通のSHD（およびこの脆弱性によりディスクから何も読み取れない）および独自のホストセットがあります。
スケーリングする必要がある場合、純粋なホストが追加されます。
結論-これで、主要な脅威からの閉鎖になりましたので、OSにパッチを適用することをお勧めします。 OSを最新の状態に保つことが良いトーンであるという理由だけである場合。 詳細な検査の後の脆弱性はひどいように見えますが、初期のように危険で気がかりではありません。
これは、 Technoserv Cloudサービスの責任者であるDmitry Maksimovの資料です。