KNOWLEDGE - COLUMN ナレッジ - コラム

最新のWindows Server2022とそのセキュリティ機能 ~空の通ひ路~

フェロー 関原 弘樹顔写真2_1187x1313

夏と秋と行きかふ空の通ひ路は かたへ涼しく風や吹くらむ
凡河内躬恒(おおしこうちのみつね) -古今和歌集より-

なにはともあれ、多くの分断を抱え込んだまま2021年の夏が終わりました。

イメージ画像

COVID-19に対する”銀の弾丸”と信じられ、ようやく……ようやくデプロイ体制が整ったワクチンも、変種に対する効果や抗体の持続期間、副反応やサプライチェーンにおけるコンタミの観点で多くの疑問が噴出し、健康リスクを十分に低減できているか?という点についてはネット上を中心に様々な意見が飛び交っています。

デマや隠ぺいを含むこのような多くの情報を取捨選択し、判断を下していくには十分なリテラシーを持つことが必要といわれますが、その判断にはITのみならず他の専門的な知識が必要な情報も多く、そう簡単にはいかないのが現実だと感じています……

--------
※外部サイト:我が国における超過死亡数および過少死亡数 (2021年5月までのすべての死因を含むデータ分析)
>・30都道府県において、2021年5月中のすべての死因を含む超過死亡数は例年の同時期より多い結果でした。
>・大阪府や兵庫県等一部の県では、超過が認められる週が4月最終週から継続しています。
>・2021年1月から5月までの期間の全ての死因を含む全国の超過死亡数は、過去(2017~2020年)の同期間と比べて、最も大きい規模となっていました。
~ NIID 国立感染症研究所

日本における2020/6~2021/5の超過死亡数(平年の死者数をもとにした予想死者数)の分析
2020/6~2021/5の超過死亡数(平年の死者数をもとにした予想死者数)の分析
出典:※外部サイト:Excess and Exiguous Deaths Dashboard in Japan
 #このサイトで対象AreaをJapanからTokyoやOsakaに変えてみると……

さて、ここからが本題です。

今回は今秋OS界最大の話題となる「Windows11リリース」の陰でひっそりと発表されていたWindows Server 2022のリリースとそのセキュリティに関する新機能についてみていきましょう。

Windows Server 2022とは

2021/8/18にリリースされたMicrosoftの最新サーバOSでWindows Server 2019の後継です。

今秋以降もWindows10の半期ごとのアップデートは継続される模様ですが同時期にWindows11のリリースがあるため、これまでの
Windows Server 2008 ⇒ Windows Vista
Windows Server 2008 R2 ⇒ Windows 7
Windows Server 2012 ⇒ Windows 8
Windows Server 2012 R2 ⇒ Windows 8.1
Windows Server 2016 ⇒ Windows 10 version 1607 (Anniversary Update)
Windows Server 2019 ⇒ Windows 10 version 1809
といった世代の対応から考えると
Windows Server 2022(以下WS2k22) ⇒ Windows 11
という対応があるということはいえるでしょう。

Windows Server 2022のサポート期間

メインストリーム 2026/10/13まで 延長サポート 22031/10/14まで
となっており慣例通り約10年のサポートとなっているようです。

以下のリンクが公式発表です。
外部サイト:Windows Server 2022
Windows Server 2022 は、固定ライフサイクル ポリシーに従います。
これは次のエディションに適用されます。Datacenter、Datacenter: Azure Edition、Standard

Windows Server 2022の各エディション

WS2k22はWindows Server 2019までのような(Essentials,) Standard, Datacenterの3エディションではなくStandard, Datacenter, Datacenter: Azure Editionの3エディションで提供されるようです。

それぞれのエディションが持つ機能の違いは以下のリンクで確認できますが、Datacenter: Azure EditionとはAzureのVM上でのみ実行可能なエディションと理解してよさそうです。

※外部サイト:Windows Server 2022 の Standard、Datacenter、Datacenter: Azure Edition の各エディションの比較

Windows Server 2022の評価版のダウンロード

例によってWS2k22評価版は情報を登録することによって以下のサイトよりダウンロードすることが可能です。
※外部サイト:Evaluation Center

ちなみにここからダウンロードしたISOでインストールを開始すると以下のようなエディションとデスクトップエクスペリエンス(GUI)の有無の選択が可能です。

システムのセットアップ画面

Windows Server 2022のセキュリティに関する新機能

①ハードウェア・信頼性のある起動シーケンス

Windowsはx86やAMD64の互換性を持つ多くのベンダの様々なハードウェア上で動作することでそのシェア拡大を進めてきました。
しかしそれは同時にOSの視点からは必ずしもリスクをコントロールできない下位レイヤのソフトウェア、つまりファームウェア上で動作せざるを得ないということでもあります。

標的型攻撃で組織侵入の突破口となりやすいクライアントPCではこれまでもWindows 10でファームウェアを保護する「Secured-core PC」が提供されてきましたが、今回WS2k22も「Secured-core server」によりそのリスクを低減させる方向に向かいました。

限定されたサーバベンダと連携したうえでTPM2.0(そして今後セキュリティプロセッサを内蔵CPUがリリースされた際はそれを使って!)の機能を利用し、信頼されたファームウェアからのブートを実現させます。

なお、ファームウェアからアプリケーションまで信頼の連鎖に重要な役割を果たす暗号/署名用のキーの生成や保管の機能を持つTPM(Trusted Platform Module)ですがWindows10普及前に主流だったTPM1.2と現在主流のTPM2.0では利用できる暗号アルゴリズムに以下のような違いがあります。

※外部サイト:TPM 1.2と2.0の機能の比較

上のリンクの解説ではTPM2.0ではTPM1.2と異なり保持する各キーを複数のエンティティに分けられることが強調されています。

また、利用できる暗号アルゴリズムは今後に向けて安全性の高いものに限定されており

  • 暗号化と署名が可能な公開鍵暗号RSAでは危殆化(原理上通信の安全性侵害されるリスクが高い)した1024bit長のキーはオプション扱い2048bit長のキーが必須
  • 公開鍵暗号ECC(署名に使われる楕円暗号による256bit長のキー)が実装必須
  • データを直接暗号化する共通鍵暗号ではAES128(安心のキーワード!)の実装必須
  • 改ざん検知のためのハッシュアルゴリズムでは危殆化しているSHA-1が依然有効なものの安全なSHA-256も実装必須
となっています。


ここでは最後に参考として現在のサーバや様々なパソコンが起動するまでのシーケンスを記載しておきます。

電源オン
↓ BIOSやUEFI(ファームウェア)が読み込まれる
↓ ハードウェアのセルフテストと接続されたデバイスの認識
↓ 起動デバイス特定
↓ 起動デバイスの起動領域を読み込む
↓ 起動領域の情報で指定されたOSやハイパーバイザー起動のためのブートローダ(プログラム)呼び出し
↓ OSもしくはハイパーバイザー起動
↓ アプリケーション起動(ホスト型仮想化やコンテナのプロセスもここで起動)

ここで各ステップはそれ以前のステップを信頼していますのでそれ以前のステップに悪意がある行動があっても検出することはできないことがポイントです。

以下のリンクで解説されるようなOSのブートシーケンスを狙った極めて高度な攻撃に対応することが大きな課題であったことがうかがい知れます。

※外部サイト:OSの再インストールでも排除が困難な、UEFIファームウェアに感染するカスタマイズされたブートキットを発見

②ネットワーク・通信中のデータ保護

このセクションではHTTPS/TLS 1.3のデフォルト化とセキュリティで保護されたDNS、またSMB over QUICをピックアップします。

★HTTPS/TLS 1.3のデフォルト化★
ここは読んで字のごとくですが、以下のリンクによるとWS2k22はWindows OSでは初めてネイティブでTLS1.3をサポートしたOSになります。クライアントOSではWindows11もこれに続くことになるでしょう。

※外部サイト:TLS プロトコルバージョンのサポート

TLS1.1以前が危殆化しているという現在、最も利用されているのはTLS1.2のはずです。
TLS1.2も危殆化しているわけではないとの認識ですが、利用する暗号スイートの設定等、安全に使うにはやや気を遣うところもあり、今後サーバ/クライアントの対応が進むにつれTLS1.3への移行が進むことは必然でしょう。

★セキュリティで保護されたDNS★
一部のブラウザではすでに実装されていますがWS2k22ビルトインのDNSクライアントでDNS-over-HTTPS (DoH) がサポートされました。

DNS設定の編集画面

上図はWS2k22の画面ですが設定⇒ネットワークのDNS設定から、優先DNSの欄にDoHをサポートするDNSサーバを指定します。

優先DNS暗号化の設定は上から
非暗号化のみ ⇒ DoH無効 ⇒ 通常の53/UDPで名前解決
暗号化のみ~ ⇒ DoHのみ利用 ⇒TLS1.3でDNSサーバと通信
暗号化優先~ ⇒ DoH優先、無効な場合は通常DNSクエリにフォールバック
を意味します。

今回は”www.google.co.jp”に対するPING時の名前解決を1.1.1.1(Cloudflare DoH対応DNSサーバ)に対しそれぞれの設定で行った以下のキャプチャからDoHが有効になっていると53/UDPではなく443/TCPのTLS1.3で名前解決を行っていることがご確認いただけると思います。

非暗号化のみ ⇒ DoH無効 ⇒ 通常の53/UDPでクエリ


暗号化のみ~ ⇒ DoHのみ利用 ⇒TLS1.3でDNSサーバと通信


暗号化優先~ ⇒ DoH優先、無効な場合は通常DNSクエリにフォールバック(図はフォールバック無)


ちなみに「暗号化優先~」の設定は”1.1.1.1”や”8.8.8.8”の特定のDoH対応DNSサーバ以外はIPアドレスの入力時点でグレイアウトしてしまい選択できないようです。(フォールバックの検証ができませんでした)


ではここからはDoHのTLSパケットをもう少し詳しく見ていきます。

別に採取したシーケンスからパケット#9のClient Hello、#11のServer Hello、#13のApplication Dataの3パケットを取り上げます。

ここで見るべき最初のポイントはTLS1.3の仕様通りの実装である

  • 4way(2往復)が必要なTLS1.2と違い、#9のClient Hello、#11のServer Hello2つのパケットでハンドシェイクが完了し、3番目のパケットであるDNSサーバからの#13でペイロードがすでに暗号化されていること(オーバヘッドを最小化する2way=1往復でのハンドシェイク)
  • パケット内のTLSバージョン表示がTLS1.2(0x0303)であること(バグではなく後方互換性を維持するため RFC8446 Appendix.D.1)

という部分です。


パケット#9
最初にクライアントからサーバに提案するCipher Suite(TLSに必要な「鍵交換」⇒他のカギの共有「署名」⇒相手の認証「暗号化」⇒直接データを暗号化する鍵「ハッシュ関数」⇒改ざんの検知の4タイプの暗号アルゴリズムの集合体)は0x13で始まるTLS1.3専用のものを上位で提案し、その後にTLS1.2のものを並べています。


パケット#11
サーバではクライアントの最上位の提案を受け入れ0x1302のTLS_AES_256_GCM_SHA384を改めて提案します。
TLS1.2のCipher Suiteと違い4タイプ必要な暗号アルゴリズム表示に「暗号化」(AES256 GCM)と「ハッシュ関数」(SHA384)しかなく「鍵交換」(ECDHEとか)と「署名」(ECDSAとか)が無いように見えますが……
スペースの都合上詳しい説明は端折りますが、これはTLS1.3ではCipher Suiteの枠組みでネゴシエーションされずTLSの拡張属性でネゴシエーションすることになっています。

TLS1.2までは提案時の4つの暗号アルゴリズムタイプを1つの組にまとめる必要があるためその組み合わせ数(鍵交換*署名*暗号化*ハッシュ関数)は乗数的に多くなっていました。長々と列挙するテキストの文字数もばかにならず、この分離もオーバヘッドの最小化に貢献しています。


パケット#13
Application Data Protocolに”http-over-tls”の表示
ペイロードは暗号化されており読めません。


ちょっと長くなってしまいましたが、この機能によりこれまでの平文でのDNSクエリの弱点であった、内容の盗聴や改ざん、DNSサーバのなりすまし等を防止することができ、より安全なDNSベースのインターネットアクセスが可能となります。

なお、DoHについてご興味がある方は私の過去のコラムもご参照いただければ幸いです。
【エバンジェリスト・ボイス】インターネットを支えるインフラのセキュリティ-MozillaとCloudflare

★SMB over QUIC★
SMB(Server Message Block)は1980年代にIBMによりLAN環境で利用する通信アプリケーションとして開発され、現在ではIPネットワークの445/TCPで動作するWindowsのファイル・プリンタ共有でおなじみの機能です。

そして2022年、その機能がQUIC上で動作します!

QUICはGoogleがTCP上で動くアプリケーションの性能改善を目指して開発したものですが、2021年5月にインターネット上の技術標準を策定することでおなじみのIETFがRFC 9000とそれをサポートするRFC 8999、RFC 9001、RFC 9002を発行し標準規格としています。

IETFのTCP/IPレイヤの観点でいえばアプリケーションレイヤのSMBとインターネットレイヤのIPv4,IPv6は変わらないのでトランスポートレイヤのTCPがQUIC(+UDP)に変わっただけとも言えます。

イメージ画像

ここでTCPとQUICを簡単に比較してみます。

TCPとQUICの比較

表からは現時点で利用可能なアプリケーションは限定的ながら、コネクションの概念を引き継ぎつつTCPの制約から逃れることでそれらの性能向上を目指し、セキュリティについても必要なものは効率化して組み込んでいくといった方向で改善を図っていることがお分かりいただけると思います。

最後に以下のリンクでは
QUIC で SMB を使用するには、次のものが必要です。
外部サイト:QUIC での SMB (プレビュー)


  • Windows server 2022 Datacenter を実行するファイルサーバー: Azure Edition preview (Microsoft server オペレーティングシステムプレビュー)
  • Windows 11 insider Preview (Windows insider チャネル)
  • Windows管理センター (ホームページ)
  • Active Directory 証明書サーバーや、Verisign、Digicert、暗号化などの信頼されたサードパーティの証明書発行者へのアクセスなどの証明書を発行する公開キー基盤。

という前提が提示されています。


検証については現状ではちょっと準備が間に合いませんでしたので、別途機会があればと考えています。

ということで、これまでIPSec等の暗号化されたVPN上でSMBを使っていたケースでは、この機能によりオーバヘッドなしにWindowsファイル共有が利用できます。

とはいっても前提条件の様に公開キー基盤をはじめとする必要なコンポーネントがいくつかありますのでどの程度のスピードを持って普及していくかはわからない部分もあります。

おわりに

人間は自分が信じたいことを喜んで信じるものだ
ガイウス・ユリウス・カエサル


イメージ画像
出典:※外部サイト:WIKIMEDIA COMMONS

という名言があります。
とはいえ正しい判断を下すためには時間を要するものがあります。
そこまで待てれば簡単ですが……

ではまた、次回のエントリーでお会いしましょう。

Hiroki Sekihara,
CGEIT, CRISC, CISSP, CCSP, CEH, PMP, CCIE #14607 Emeritus,
AWS Certified Solutions Architect – Professional,
AWS Certified Security – Specialty,
Google Cloud Certified Professional Cloud Security Engineer,

当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。

エバンジェリストによるコラムやIDグループからのお知らせなどを
メルマガでお届けしています。

メルマガ登録ボタン

関原 弘樹

株式会社インフォメーション・ディベロプメント フェロー / CISSP

この執筆者の記事一覧

関連するナレッジ・コラム

地味に見えて優秀!マネージドプレフィックスリストでアドレス管理を効率化

DockerでJupyterLabの環境を作ろう

残された攻撃の痕跡を追え! ~Post-Exploitationで起きていること~