🔬

新米情シスはWindowsサーバ管理方法を模索中

15 min read

はじめに

いつもはプログラム書いたり、Linuxとかアプリサーバの運用とかをする事が多いのですが、最近いわゆる情シスっぽい仕事をする機会がありWindowsサーバ管理の道を模索しています。ここで言う情シスっぽい仕事ってのは社内インフラとか言われるオフィス自体のNW(WiFiとかLAN)やPCの管理/運用のあとセキュリティ基盤ですね。なおクライアントはChromebookとかMacの事は忘れてWindowsのみの素晴らしきダイバーシティの無い世界です。やったね!

さて、ではWindowsサーバをどう管理するか? 当然、GUIで丹精込めて作った手順書をベースにポチポチやって運用することは出来るのですが、その伝統的なやり方はあまりに多くの問題を含んでいます。そのためMFA/CLI/IaC/自動化をキーワードに管理方法を検討中です。まだ模索段階のため 「これがベスト!」 と言えるものでは無いですが、いったん自分の整理のために中間レポート的なノリで書いておきたいと思います。

環境編 - どのクラウドに置く?

まずはどこに置くか。これは選べるならAzureです。

選択肢としてはオンプレ/AWS/Azure/GCPあたりですよね。正直、ここから選べる機会はあまり無いかもしれませんが、選べるならAzureがおすすめです。というのもWindows PCを利用するならMicrosoft 365 (旧Office 365)には入ってるでしょうし、その場合はAzureのIAM(アカウント管理)であるAzureADが統合されますし、クライアント管理のためにIntuneも必要になってくるのでAzureの方が良いでしょう。Microsoft 365はWord/Excel/PowerPointだけではなく、実際は多くのセキュリティやデバイス管理の機能を含んだ製品です。

そして、AzureはさすがMS謹製のクラウド環境だけあってSecurity Center/Admin Center/AutomationなどWindowsの管理面でかなり優位です。なので、選べるならAzureを選びましょう。プロビジョニングの遅さとかAzureへの不満は少なからずあるのですが、ことWindowsサーバの管理/Microsoft 365との連携と言う点で社内インフラには最適解ですね。値段が高い安いとか機能全体が豊富かどうかというよりWindows特攻が付いてることが重要。

そもそもLinuxじゃダメなのか?

ダメです。

いえ、絶対ダメではないのですがWindowsをPC環境として運用するならActiveDirectoryがほぼ必須です。SAMBAをはじめこれをOSSで運用する事も出来ますし、各クラウドでManaged ADもあります。そのためLinuxだけで不可能では無いのですがいくらか制限が付いてしまう事も多いです。例えば各端末に配る証明書周りとかも出来そうだけど余計な苦労しそう。なので、後述するADレスの環境を組まないならLinuxでの運用は割とチャレンジ領域になってしまうと思います。
慣れてるので正直Linuxのが良いのだけど、この道は断念。Windowsサーバと和解することにします。

AD ○○が多すぎる!

Acitive Direcotryという名前を聞いたことがある人は多いと思います。なんとなく 「Windowsのアカウント管理システム。MSが独自拡張したLDAPサーバ」 というイメージじゃないですかね? 私はそうでした。このイメージは間違ってはいないのですが、それはADの一部です。より正確にはAD DSの一部です。ADなんとかが実はかなりたくさんあってややこしいのですが、よく登場するのは以下の通り。

名前 環境 管理 概要
Azure Active Directory (Azure AD) Azure サーバレス Azure及びMicrosoft365のIAM。ユーザ、グループ、権限を管理できパスワードレス認証やMFAを含む条件付きアクセスなど強力な認証機能を提供. SAML認証にも対応
Azure AD Domain Services (AAD DS) Azure マネージドVM AzureADのProxyとしてADのようにドメイン参加やLDAP/Kerberos/GOPなどを提供。ADDSの全機能を提供してるわけではない
Azure AD Connect (AADC) Windows 自前 AzureADとAD DCを同期させるための仕組み。ユーザやグループを単方向または双方向で同期可能
Active Directory Domain Services(AD DS) Windows 自前 Windowsサーバ及びPCの認証/ユーザ管理/グループ管理/コンピュータの管理/NTP/DNSなどを提供。一般的にADと言われたらこれ。AzureADと区別してオンプレミスADとも。
Active Directory Federation Service (AD FS) Windows 自前 AD DSと連携してSAMLなどのフェデレーションによりSaaS等の認証を行う仕組み。インターネットから利用する場合はWeb Application Proxyというコンポーネントを経由させる

他にもAD CSとかありますがいったん割愛。Azure ADは名前に反してAD(DS)のクラウド版と言うよりはADFSの強化版がクラウド化されているという方がイメージに合います。そのため従来のAD認証(LDAP/Kerberos)等が必要な場合はAADDSを立てる必要があるのですが、こちら冗長構成に制限があったり、本格的にクライアントの認証に使うというよりはLDAP等の認証がサーバ側で必要になった時に使うもの、という印象が強いです。

そのため、オンプレミスADとAzureADを作りAADCで繋ぐというのが典型的な構成になると思います。ADのリージョン冗長までを期待しないならAAD DSで良いのかもしれません。

真のモダン環境 - ADレス運用の世界

さて、こんな訳の分からんADシリーズを捨ててAzureADだけで何とかならないの!? と思いませんか?
私は思いますし、実は最近は出来ます。

今でもまだハイブリッドジョインが安パイではあるのですが、ここ1,2年でAzureADや周辺機能も強化されADレスの社内インフラも夢では無くなってきました。あくまでカタログスペック等での評価ですが以下のような構成で実現できる気がします。

機能 対応
クライアントPCの認証 AD認証やDomain参加を使わずにAzure AD joinだけでの運用も可能です
サーバの認証 サーバのAD認証も最近導入されたAzure AD loginに対応しています。なお現時点ではクライアントPCのハイブリッドJoin的なことは出来ず、
パスワードレス認証 スマートカードはオンプレミスADのみ対応していましたが先日FIDO2ベースのパスワードレス認証にAzureADが対応したのでこちらで対応可能
各種PCの構成管理 GPOの代わりにクライアントPCに関してはIntuneを使う事で対応可能です
VDI 先日、マイクロソフト謹製のVDIのAVDでAzure AD Joinが出来る用に遂になりましたWindows 365を使う方法もあります。
プリンタ 業務用プリンタの多くはADと連携して社員証等ICカードによる認証を提供します。Universal Printという仕様が最近発表されたためそれに対応した業務用プリンタであればAzureADのみでICカード認証等を提供できるかもしれません。
WiFi/LAN認証 NW認証にもAD連携をさせてましたがAzureAD単独で提供できるかは謎。AADDSとかならRADIOUS認証も出来るっぽい。ただゼロトラストで考えればNWはカフェのWiFiレベルのセキュリティで良く強力な認証を不要とする設計もできる
証明書の発行 IntuneやWiFiなどの証明書の発行はAD CAを使って行う事ができました。代替手段はあるんだろうけど要調査
PaloAlto FWのUSER-IDなどAD連携したセキュリティ機能 たぶんAADDS立てない限りは対応できない。ただしWeb URLフィルタに関してはZscaler Internet Access や Cisco Umbrellaのようなクラウド系のセキュリティ製品に任せるのも手

割と何とかできそうな気がしますよね! とはいえ、プリンタやAP、あるいはWeb URLフィルタのようなセキュリティ製品までADがあることを前提に設計されたシステムが非常に多いので、そこに対応した製品を選ぶ必要があると思います。可能な限りMicrosoft 365に固めたとしても一部は不足しますし。運用コストが大幅に下がりそうだけど、まだ少しチャレンジ領域。試してみたい!

レガシーとの共存 - ADと過ごすイマドキの社内インフラ

さて、前振りというかWindowsサーバが捨てきれない理由をここまで述べてきましたが、ようやく本題のWindowsサーバの管理方法です。

ADのある世界ではWindowsはクライアントもサーバも管理の中心はGPO(Group Policy Object)でした。ただ個人的にADはAzureADと連携は出来るものの後述する通り別世界でありIAMにより柔軟で一貫したセキュリティ管理が困難な事と、なるべく管理系をクラウドに寄せることで(Windowsサーバ初心者の私にとって)見通しの良い構成を作りたかったので「GPOの利用は最小化する」というコンセプトを取っています。将来的にADレスの環境も作りやすくなりますしね。

あと、意図的にAzureにべったりの構成にしてるのでAWSやGCPあるいはオンプレミスで完全に同等の方法がとれるかは分かりません。

リモート管理 - RDP? SSH? いや、Windows Admin Centerだ!

まずはどのようにリモート管理をするか。伝統的なWindowsの管理ではRemote Desktopでのログインが基本です。ただSSHでの運用に慣れてる身としてはGUIが立ち上げるのは何ともめんどくさい。。。では、SSHとPowerShellで生き抜くかと考えていたのですが、良く見るとAzureのメニューいつのまにかWindows Admin Center (from Azure)が増えていました。

Windows Admin CenterはWindowsに直接ログインすることなくWebから各種管理が出来るツールです。オンプレミスでも動きますが、これはそのAzure Managed版のようです。Azureの管理画面から拡張をインストールしアクセスしてみると以下のような画面に遷移します。

システムのリソース情報やイベントなどをログインすることなくWeb画面から見る事が出来ます。現在動いているプロセスの一覧なども確認できて非常に便利です。

モニタリング機能だけではなくレジストリの確認やアプリやユーザの管理、PowerShellの実行、はてまたリモートデスクトップまで可能です。


PowerShellを直接こちらから実行できるのでSSHデーモンを立てて云々というよりずっと手軽です。Web UIで様々な情報も確認できるので今後のWindows管理の定番になるんじゃないかと思います。

ただし、現時点では大きな課題が2つあります。

  1. AzureのURLにアクセスして見えるが、実際はVMのIPアドレスへの直アクセス。
  2. 現時点ではパスワード認証のみサポートしているように見える

1に関してはhttps://portal.azure.com/#@xxxx/resource/subscriptions/xxx/resourceGroups/poc-core/providers/Microsoft.Compute/virtualMachines/vm-win-poc-core01/windowsAdminCenterな感じのURLにアクセスするのですが、指定したVMのpublic IPまたはprivate IPへのACLが必要になります。そのためインターネット越しにアクセスしようとすると全てのVMにPublic IPを紐づける必要があります。これはセキュリティ的にも避けたい。Azure Bastionのようにセキュリティを考慮してるわけでもないので不用意にインターネットに晒すべきものではありません。ということは選択肢はPrivate IPのみを付与する形になるのですが、当然直接はアクセスできないのでProxyサーバ等を立てる必要があります。今のところLinuxサーバを立てて認証をAzureAD Loginにし、SSHのSOCKS Proxy機能を使うことで無理やり対応しています。一応Proxyを使う事で間接的にIAMやPIMやConditional Accessといった認証機能でWindowsAdminCenterへのアクセスを制御できます。無理感強いけど。この辺は今後MSのマネージドな仕組みで出来ることを期待。

2はパスワード認証しかUI上できない用に見えまることです。これではパスワードレス運用ができずセキュリティに課題が出てしまいます。Bastionサーバ + RDPのがその点に関しては対応してるはずなので良いのですがログインしなくても色々見れるのは便利なのに…

ここら辺が改善されるとよりWindowsの管理がしやすくなるのですけどね。。。まだPreviewなので正式版では改善してることを祈りたいです。AzureAD対応まってるよ!

いまは遥か理想のパスワードレス - 捨てきれないパスワード

2021年現在、パスワードの運用は人類には早すぎたのでMFAやパスワードレスが推奨されています。AzureADもMFAやパスワードレスに対応していますし、WindowsもスマートカードやFIDO2(Windows Hello for Business)を利用した運用が可能です。これはセキュリティを飛躍的に高めつつ運用性を損なわないのでぜひ全面導入をしたいのですが、なかなかやり切れません。というのもWindows Admin Centerなど一部の機能がパスワード認証のみに対応しています。

今のところ、これに対する良い回答は持ち合わせていなくて、サーバ用のアカウントと十分に長いパスワードを作り適当なパスワードマネージャでの管理をする、ということくらいですかね。Windows Admin CenterもAzureADに切実に対応して欲しい。。。

そして、この問題はAzureADとADはクレデンシャルを同期していても結局のところ別物であるという事にも関連して次の章の話題とも絡みます。

PIMによるJITと最小権限の原則 - Azure ADとADの断絶

特権管理の世界の合言葉は最小特権の原則(PoLP)です。
常にアドミン権限で入らずに可能な限り小さな権限を選択しましょう、ってことですね。
Azureにはこれを支援する非常に便利な機能としてPIM (Privileged Identity Management)があります。こちらの解説が分かりやすいですね。

https://www.softbanktech.co.jp/special/blog/cloud_blog/2020/0012/

彼らがJIT(Just In Time)と呼ぶ、必要な時にだけ必要な権限を一時的に付与するという事をPIMでは実現可能です。これによって 「普段はリードオンリーだけど申請したらインスタンスの作成など書き込み作業ができて、IAMの変更などは申請だけじゃなくて承認も付ける」 といったシナリオを実現できます。メチャクチャ便利ですよね! GCPにも欲しい。

似たような名前の機能としてJIT VM accessがあります。こちらはVMへのACLを一時的に開けるというものなので全く別の機能となります。また、PIMを使うにはAzureADのP2というライセンスが必要なのですが、これはMicrosoft365のE5(ないしはE3にオプションを付ける)を利用していれば追加の購入もいらないので、Microsoft365との相性の良さが伺い知れます。

さて、このようにAzureのセキュアな運用に非常に有効なPIMなのですが、あくまでAzureADの機能であってオンプレADの機能ではありません。そのためPIMをWindowsサーバ上での権限管理やログイン管理に使う事が出来ません。ユーザやグループ、場合によってはクレデンシャルが共有できるから勘違いしがちですがAzureADとオンプレADは別の世界です。そのためサーバログイン後の権限をPIMで制御することは出来ません。またリモートデスクトップでのログインも制御できません。権限を分けたかったらUACや単純に権限の違うアカウントを用意しておくくらいしか方法は無い気がします。

一応、RDPによるリモートログインに関しては、AzureADログインを使ったWindowsサーバであればIAM/PIMにてVirtual Machine Administrator Login/Virtual Machine User Login roleを制御する事で可能です。

ただしWindowsサーバはHybrid AD joinに対応していないので、AzureAD LoginをWindowsサーバで有効にするとADドメインに参加できないという致命的な問題が発生するので実質選ぶことが出来ません。このあたりの統合が本当にあと一歩と言う感じ…

Windows Update - WSUS vs Azure Automation

WindowsといえばWindowsアップデートですね!

個人レベルでも当てて困ったという経験を持った人は居るでしょうし、企業レベルでは一層慎重に適用されることが多いです。一方でセキュリティ観点でWindows Updateは迅速にするべきです。古来よりIT管理者はこの二重拘束に悩まされてきました。

そのためWSUSやSCCMがパッチ管理に用いられることも多いですね。XPとか(たしか7あたりも)昔の環境だと、WindowsアップデートはIT管理者が必要なパッチを選んで個別に当てるといった運用をしていました。それを実現するために高機能なパッチ管理サーバが必要になったのですが最近のマイクロソフトのポリシーではWindows Updateの適用を延期する事は出来てもスキップする事はできません(無理やり出来るのかもだが非推奨のはず)。これはPCをプロビジョニングしたタイミングによって過去の選んでないパッチが当たってる端末とそうでない端末が混在する状況等を避けたのではいかと思われます。そのため、あまり高度な機能は必要なくWSUS等を使ってもキャッシュ(これはこれで大事だが)とタイミングの制御が主な用途になります。

今回はWindowsサーバのパッチ管理にはAzure Automationの更新プログラムの管理を使っています。

単純に自動アップデートするだけならAzureVMのパッチオーケストレーション機能で自動更新にしたり、ADのGPOを使って制御するのでも良かったのですが、タイミングの制御や全サーバの視認性などを考慮してAzure Automationの利用がベストプラクティスと考えています。セキュリティパッチだけは無条件ですぐ適用とか柔軟な構成もできそうですし。なお、ちゃんと設定すればAzure外のオンプレミスや別クラウドの管理もできますし、Linuxの管理もできます。

構成管理 - Docker? Ansible? いや Azure Automation DSCだ!

VMやNWの構築自体はARMテンプレートでやるとして、重要なのはサーバの構成管理です。ActiveDirectoryの構築をしたり設定を変更するのをなんとかIaCで実現したいですよね。

大きく分けてゼロからのプロビジョニングの話と既存のシステムに特定のソフトをインストールするようなケースで考えます。

Windowsサーバにおけるプロビジョニング

Active DirectoryサーバをIaCで構築するようなパターンですね。これはAutomation DSCを使います。

Linux系の環境であればAnsibleかDocker、あるいはChefを使う事が多いでしょう。これらはWindowsもサポートしてはいます。ただ、決して導入事例が多いわけではないですし、特にDockerもどちらかと言うと.NETのアプリを動かすような想定に現時点では感じます。Nano ServerもAD DSとして構築できないですし。

Ansibleでも良かったのですが、そこまで事例が多い感じはしなかったのでAzureに統合されているAzure Automation State Configuration(DSC)を使う事にしました。これは元々はローカルで動かすPowerShellベースのDesired State Configuration(DSC)をベースにしてAzure側で実行できるようにしたものです。

DSCは宣言型/冪等性という特徴を持ったIaCプラットフォームです。PowerShellでの記述になりますがRubyでChefを書くのと同じく宣言型のスクリプトです。下記のサイトが詳しいですね。

https://atmarkit.itmedia.co.jp/ait/articles/1405/22/news131.html
https://www.citrixlab.dk/archives/1938
https://docs.microsoft.com/ja-jp/learn/modules/protect-vm-settings-with-dsc/1-introduction

コミュニティの作ったリソースキットを使う事も出来ます。

https://www.powershellgallery.com/packages?q=Tags%3A"DSCResourceKit"

例えばシンプルなADのドメインコントローラは下記のようなスクリプトになります。スクリプト中のパスワードは適切なものに変えてください。

https://gist.github.com/koduki/eaabf4a57306dd9c11d7dc2e2cc0164c

実行状態はAzure Automationから確認する事が出来ます。

WACからリモートデスクトップで覗いてみるとADの管理画面から指定通りに出来てることが分かります。ADが作れるとなんかちょっと感慨深いですね。。

Windowsサーバに追加のソフトウェアや設定を配布する

続いてWindowsサーバへのソフトウェアの配布や設定変更です。完全なIaC環境が出来た後なら上記のフルプロビジョニングだけで良いのですが、常にそれが出来るとは限らないです。今回はこれもDSCで実施します。

Intuneでクライアントと同様に管理したい気もするのですが、基本的にクライアント向けのものなのでサーバでは上手く動作しない用ですね。

https://www.reddit.com/r/Intune/comments/l18a2v/windows_server/

最終的にはwingetを使うのがベストプラクティスになるだろう、と考えています。DSCと統合させても良いですし、Azure Automation runbookで直接実行しても良いと思います。wingetはapt-getのようにパッケージをCLIでインストールできるMS製のツールです。Chocolateyの公式版ってところですね。最終的には現在のMicrosoft Store for Enterpriseとかも廃止してwingetに統合するようです。。

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/evolving-the-microsoft-store-for-business-and-education/ba-p/2569423

ただ2021/08/21時点ではPrivate Repositoryは以下のように絶賛開発中のようですね。2022年Q2に向けて徐々にと言う感じでしょうか.

https://github.com/microsoft/winget-cli-restsource

それではAutomation DSCはどうでしょうか? もちろんパッケージのインストールに対応しているので以下の感じで利用可能です。

Configuration CommonConfiguration
{
	Node 'localhost'
	{
		Package SevenZip {
			Ensure = 'Present'
			Name = '7-Zip 16.02 (x64 Edition)'
			Path = 'http://osdn.mirror.liquidtelecom.com/sevenzip/70662/7z1900-x64.msi'
			ProductId = ''
			Arguments = '/qn /norestart'
		}
		Package VSCode{
			Ensure = 'Present'
			Name = 'Visual Studio Code'
			Path = 'http://az764295.vo.msecnd.net/stable/3866c3553be8b268c8a7f8c0482c0c0177aa8bfa/VSCodeUserSetup-x64-1.59.1.exe'
			ProductId = ''
			Arguments = '/VERYSILENT /NORESTART /MERGETASKS=!runcode'
		}
	}
}

こんな感じで任意のソフトをインストールさせる事は出来ます。ソフト以外の設定ファイルとかも可能。ただ、同時に複数のConfigはノードに紐づけれないのですよね。。。

一応、同時には適用出来ませんが以下のように複数のConfigをノードに紐づけることは出来るので手動で切り替えるなりで対応は出来そうです。一般的にIaCは混ぜるな危険だけど、どうだろ。ちょっとまだ様子を見なが使っていきたい構成ですね。

他の案としてそれぞれのConfigとして書いてビルドスクリプトかなんかで単一ファイルに固める、という方法もありますね。リリース承認のフローをPRとかにまとめたいからビルドパイプラインに組込むのはありかも?

ただ、アップデートとかを考えるとやはりDSCのパッケージより、wingetのが楽そうな気はするので、ここも将来的にもっとスマートな方法が出来て欲しい所。。。

まとめ

という分けで最近Windowsサーバと和解中なので、その中間レポートでした。

正直、やりたい事というか理想的な形まであと2歩というところでしょうか? 「この機能超便利そう!」 ってのを見つけても今一つというか未だ発展途上だったりするんですよね。とはいえいくつか別な方法で補えばだいぶ上手くいきそう。

Windowsの権限管理がサーバもPCもAzureADに統合されてくれたら本当に便利なんですが、ADが便利すぎてそこまで辿り着くにはもう少しかかりそう。WindowsはもはやAzureべったりで良いのでもっと統合してほしい><

なお、もっと良い方法があるよ! とかやり方の筋が悪いとかあればぜひコメント等頂ければと思います。

それではHappy Hacking!

Discussion

ログインするとコメントできます