Windowsサーバーのハードニングとは？構築直後にやるべき優先順位付き対策ガイド

サーバーを構築したら、動作確認をして終わり次の案件へ。。。
このサイクルで案件を回していたら、ハードニング（セキュリティ強化設定）が後回しになってしまうケースがあります。

この記事では、Windowsサーバーのハードニングをどう考え、何から手をつけるべきかを整理します。

ハードニングとは？
構築直後が一番危険?
優先順位をどうつけるか
不要なサービス・ロールを洗い出す
アカウント・権限まわりの見直し
ログ・監査設定の最低ライン
パッチ適用の考え方
今日から始めるチェックリスト
あわせてご覧ください

ハードニングとは？

ハードニング（Hardening） システムの攻撃対象領域（アタックサーフェス）を減らすため、不要な機能・サービスを無効化し、デフォルト設定を見直し、セキュリティ上望ましい状態にシステムを構成すること。

要は システムの防御力を高めましょうよ ってことですね

「新しい脆弱性に対応する」というよりは、「そもそも攻撃者に狙われる面積を減らす」という考え方に近いです。

ファイアウォールで外部からの通信を絞るのと同じ発想を、サーバー内部の設定に対しても適用するイメージです。

構築直後が一番危険?

構築直後が危険な理由は2つあります。

デフォルト状態は「使いやすさ」優先で設計されている。
不要なサービスが有効なまま、監査ポリシーも最低限、といった状態でOSがインストールされます。
つまり使っていない脆弱なサービスが悪用されたり、攻撃時に必要なログで記録されないリスクが高いです。
構築直後は「動くこと」の確認に意識が向きがちで、ハードニングが後回しになりやすい。
サービスが無事に立ち上がった時点で「完了」とみなされ、セキュリティ設定の見直しは次のタスクに押し出されてしまいます。
また、机上で検討した最低限のセキュリティ設定で構築をすると、運用後はシステムが止まるのが怖くてセキュリティ設定の見直しは二の次にされがちです。

この「動いた後の見直し」が実施されないまま本番稼働に入ってしまうサーバーは、決して珍しくありません。

優先順位をどうつけるか

すべてのサーバーに完璧なハードニングを同時に施すのは非現実的です。以下の軸で優先順位をつけるのが現実的です。

外部からの到達性が高いサーバーを最優先
インターネットに公開されている、または社外から接続されうるサーバーは、攻撃者との接点が最も多い箇所のため優先度「高」です。
権限の高いサーバーを次に
ドメインコントローラーや特権管理用のサーバーは、侵害されたときの影響範囲が桁違いに大きいため優先度が高くなります。
内部の一般サーバーは、その後段階的に
外部への通信が発生しないからと言ってノーマークにするのは危険です。
1,2を優先で対応し、その後段階的に対応することをオススメ致します

参考として、Microsoft Security BaselineやCISベンチマークのような公開基準があります。ゼロから独自に設計するより、これらの推奨値をベースに自組織向けに調整する方が効率的です。

参考：Microsoft Security Baseline

不要なサービス・ロールを洗い出す

構築時に一時的に使っただけの機能や、テンプレートに含まれていた不要なロールが有効なままになっていないか確認します。

powershell

Get-WindowsFeature | Where-Object {$_.InstallState -eq "Installed"}

代表的な見直し対象は以下の通りです。

Print Spooler サービス：印刷機能を使わないサーバーでは無効化を検討（過去に深刻な脆弱性の温床にもなったサービスです）
SMBv1：古いプロトコルで、無効化が推奨されて久しいですが、意外と有効なまま残っている環境があります
未使用のIISコンポーネント・機能：構築時のテンプレートに含まれていただけのものは、使っていなければ削除対象です

「入っているから使っている」とは限りません。
一つずつ、本当に必要かどうかを確認する作業になります。

アカウント・権限まわりの見直し

ローカルAdministratorアカウントの扱いを見直す。
有効なまま、かつ全サーバーで同じパスワードを使い回している状態は特に危険です。
LAPSでの自動ローテーションは非常に有効です。LAPSについては「LAPSのセットアップガイド」で解説しています。
Guestアカウントが無効化されているか確認する。
既定では無効ですが、念のため確認しておく価値はあります。
サービスアカウントの権限を見直す。
必要以上に強い権限（Domain Adminsなど）が付与されたまま放置されているサービスアカウントは、よくある見落としポイントです。

権限設計の基本的な考え方については「最小権限の原則」もあわせてご覧ください。

ログ・監査設定の最低ライン

デフォルトの監査ポリシーは最低限の設定に留まっていることが多く、いざ調査が必要になったときに「必要なログが記録されていなかった」という事態になりがちです。少なくとも以下のカテゴリは有効化を検討してください。

ログオン／ログオフ
アカウント管理
重要なオブジェクトへのアクセス（監査対象として明示的に設定したもの）

どのイベントIDを優先的に見るべきかは「Windowsイベントログの重要ID一覧」
複数サーバーのログを集約したい場合は「ADのログをsyslogに転送する方法とは」で解説しています。

パッチ適用の考え方

パッチ適用のタイミングは意外と勘違いしている方が多い印象です。
「出たらすぐ全台に適用する」または「様子見して溜め込む」どちらもあまりおすすめできません。
段階的な適用（テスト環境 → 一部の本番 → 全体）を基本としつつ、緊急度の高い脆弱性については優先的に前倒しで対応する、というメリハリが必要です。

パッチ管理の運用設計については「パッチマネジメントの基本」で詳しく解説しています。