Windows Serverの特権アカウント管理Administrator運用の見直しポイント

Windows Serverの管理者(Administrator)アカウントは、侵害されたときの影響が社内で最も大きいアカウントです。ファイルサーバーや業務システムの基盤に触れられるため、悪用されれば業務停止やデータの暗号化に直結します。

この記事は、サーバーの管理者アカウント固有の運用の問題点と見直し方に絞ります。最小権限の考え方は特権管理・権限設計の解説記事で扱っています。

なぜサーバーの管理者アカウントが最優先の保護対象なのか

一般利用者のアカウントと比べて、何が違うのかを確認します。

特権アカウントは、設定変更、他アカウントの作成・削除、ログやバックアップの操作など、システム全体に影響する操作ができるアカウントです。

ランサムウェアの被害でも、管理者権限の取得が拡大の分岐点になりやすく、ランサムウェア対策の基本でも権限を取られない前提づくりが重視されています。

現場でよくある管理者アカウント運用の問題

長く運用しているサーバーほど、「これまで問題が起きていない」ために次の状態が残りがちです。

• 複数人で共用している — 誰が操作したか後から特定できません
• パスワードを長く変えていない — 退職者や過去の委託先も知っている可能性が残ります
• ベンダーや委託先も同じアカウントを使う — 社外に管理者権限が広がっています
• 日常業務も管理者権限のまま — 不注意がそのまま重大な被害につながります
• 社外から直接ログインできる — 外部公開の経路は狙われやすくなります

共用そのものの整理は共有アカウント廃止の進め方も参考にしてください。

見直しの方向性

問題に対応する5つの見直しを、着手しやすい順に並べます。

1. 利用者を特定できる状態にする

共用をやめ、管理作業を行う人ごとにアカウントを分けます。誰のものか分からない場合は、ID棚卸しから始めるのが現実的です。

2. 日常作業と管理作業のアカウントを分ける

メールや資料作成は一般権限で行い、設定変更のときだけ管理用アカウントを使います。管理者権限を使う時間を短くすることが、被害の想定範囲を狭めます。

3. 管理者アカウントの認証を強化する

ID・パスワードだけで通る状態では、パスワードが漏れた時点で入られます。考え方は多要素認証の基本、Windowsでの導入方法はWindows OSログインの2要素認証で解説しています。

4. 使える場所・経路を限定する

管理作業ができる端末やネットワークを限定し、社外から管理者アカウントで直接入れる状態を避けます。リモート接続の経路はVPN機器の脆弱性・社内Wi-Fiの入口も確認してください。

5. いつ誰が何をしたかの記録を残す

記録がなければ、異常にも気づけず経緯も追えません。取得するだけでなく、定期的に見る運用になっているかを確認します（侵入検知と侵入防御の違い）。

委託先・ベンダーに管理者権限を渡すときの注意

既存の管理者アカウントを貸し出すと、作業の切り分けができず、契約終了後も認証情報が残ります。

• 貸与ではなく、委託先向けに個別のアカウントを発行する
• 作業に必要な期間を限定する（常時有効にしない）
• 作業後に無効化されたかを自社側で確認する

ADのグループを使った権限の割り当てはActive DirectoryのID管理で扱っています。

Windowsの管理者アカウントには何があるのか

「管理者アカウント」には性質の異なるものが複数あります。棚卸しでは、この区別をつけないと漏れが出ます。

実際の事案で起点になりやすいのは、ローカル管理者の共通パスワードと契約終了後も残る保守用アカウントです。前者は1台への侵入が横展開に直結し、後者は誰も見ていないまま放置されます。

サービス実行用の扱いは サービスアカウントの管理方法、外部への貸与は 委託先・ベンダーアカウントの管理で個別に扱っています。

サーバーの管理者を確認する方法（コマンド）

サーバーにサインインし、コマンドプロンプトを管理者として開いて次を実行します。

net localgroup Administrators

そのサーバーのAdministratorsグループに入っているユーザーとグループが一覧になります。Active Directoryのドメインに参加しているサーバーでは、ドメイン全体の管理者も確認します。

net group "Domain Admins" /domain

一覧に出た名前が、それぞれ誰のものか説明できるかを確かめてください。PCも含めた確認のしかたはWindowsの管理者アカウント一覧を確認する方法で扱っています。確認できても、パスワードを知っていれば誰でもその管理者として入れる状態は変わりません。サーバーのログインに2つ目の鍵を足す考え方は、下の「認証の強化が要になる理由」で説明します。

棚卸しの実施手順

全台を一度に調べるのは現実的ではありません。影響の大きいところから、次の順で進めます。

認証の強化が要になる理由

見直しの中で後回しになりやすいのが、サーバーのOSログインそのものの認証です。クラウドは多要素認証を有効にしていても、社内サーバーはID・パスワードのまま、という例は多く見られます。

管理者アカウントは影響範囲が広い分、この差がそのままリスクになります。まず管理者アカウントのログインから強化するのが、負担の割に効果が見込みやすい進め方です。

管理者で誰がいつどこから入ったかを、サーバー1台ずつのイベントログで追うのは手間がかかります。全PC・サーバーのログイン記録が1か所に集まっていれば（アプリップリキー）、棚卸しや委託先の作業の確認もその画面で済み、聞かれたときにCSVですぐ出せます。さらにサーバー版で管理者のログインを本人のスマホを鍵にしたワンタッチログインにすれば、パスワードだけでは入れなくなります。管理者本人の操作はスマホでワンタッチなので、作業のたびの手間はほとんど増えません。

入れたあと日々の仕事で変わること

サーバーの管理者アカウントは、触る人が少ない分、「最後に誰が入ったか」を確かめるのに時間がかかりがちです。ログイン記録を1か所で見られるようにしておくと、保守ベンダーの作業日に「本当にその時間だけ入っていたか」を画面で確かめられ、委託先との確認も記録を見ながらできます。夜間・休日にログインの連続失敗があったときだけ担当者のLINEに届き、相手のIPは自動で遮断されるので、何もない日はサーバーを見に行かなくて済みます。

取引先から対応状況を問われる機会が増えているなら、SCS評価制度の解説記事も優先順位の整理に役立ちます。

いまの運用を棚卸ししてみる

管理者アカウントの共用や、パスワードだけで入れるサーバーが残っていないかは、確かめると想定と違うことがあります。

applippliの無料棚卸しなら、10問・約3分で「解決済み／一部解決／人手で対応／未解決」に仕分けた一覧にできます。