中小企業の特権アカウント管理（PAM）実践ガイド｜adminアカウント共有・使い回しを情シス1人でゼロにする手順

「サーバーの管理者パスワードを何年も変えていない」「担当者が退職しても共有のadminアカウントをそのまま引き継いでいる」「システム保守業者に付与したアクセス権限を契約終了後も削除していなかった」──こうした状況は中小企業では珍しくありません。しかし、特権アカウントは攻撃者にとって最も価値の高いターゲットです。
一般ユーザーへの侵入から特権奪取まで時間をかけるより、最初から管理者アカウントを奪えれば攻撃者の手間は激減します。管理が甘い特権アカウントは、外部攻撃の突破口にも内部不正の温床にもなります。

この記事では、特権アカウント管理（PAM）の基本概念から、専用ツールや大きな予算がなくても中小企業で今日から実践できる具体的な手順まで、現場目線で解説します。

特権アカウント管理（PAM）とは？なぜ最優先で取り組むべきか

PAM（Privileged Access Management）は「特権アクセス管理」と訳され、管理者権限を持つアカウントを安全に管理するための概念・手順・ツールの総称です。

特権アカウントとは、一般ユーザーには許可されていない操作が可能なアカウントのことです。

・Windowsの「Administrator」アカウント、Administratorsグループのメンバー全員
・Linuxの「root」、またはsudo権限を持つユーザー
・ルーター・スイッチ・UTM・NASの管理者アカウント
・クラウドサービスの管理者ロール（Microsoft Entra全体管理者・AWS AdministratorAccessなど）
・データベースのDBA（Database Administrator）アカウント

IAM（アイデンティティ・アクセス管理）が「誰が何にアクセスできるか」の全体設計であるのに対し、PAMはその中でも特権を持つアカウントに特化した管理手法です。特権アカウントはシステム全体を操作できるため、侵害された場合の被害は通常アカウントの比ではありません。

攻撃者が企業ネットワークに侵入した後、次の目標は権限昇格です。特権アカウントの管理が甘ければ、この過程が大幅に短縮されます。逆に言えば、特権アカウントの管理を適切に行うことは攻撃者のコストを跳ね上げる最も効果的な防御の一つです。

特権アカウントが狙われる仕組み（敵を知る）

攻撃者がどのように特権アカウントにアクセスしようとするかを把握することが、実効性ある対策の前提です。

1. デフォルト認証情報の悪用

購入直後のネットワーク機器や新規セットアップしたサーバーには、製品共通の初期パスワードが設定されています。これが変更されないまま運用されているケースは中小企業では珍しくなく、インターネット上で公開されているデフォルト認証情報リストを使えば、自動化スクリプトで大量の機器に試行することができます。

2. 共有アカウントのパスワード窃取と転用

「admin」「operator」という汎用名義の共有アカウントを複数人で使っている場合、一人の端末がマルウェアやフィッシングに感染すると、そのパスワードが窃取されて他のサーバーやサービスへの不正アクセスに転用されます。さらに、共有アカウントでは「誰が使ったか」を特定できないため、侵害後の調査が著しく困難になります。

3. 退職者・委託業者のアカウント残存

退職した社員や業務委託先が使っていたアカウントが削除されずに残り続ける事例は一般的に多く報告されています。こうした「幽霊アカウント」は攻撃者に悪用されるだけでなく、元社員や元委託業者による意図的な不正アクセスの経路にもなります。

4. 特権の過剰付与

「とりあえずAdministrators」「念のためroot」という設定が横行していると、侵害された一般ユーザーアカウントがすでに特権を持っているため、追加の権限昇格攻撃が不要になります。攻撃者にとっては手間が省けるありがたい状況です。

【想定例】共有アカウントが招く侵害の流れ

一般的なインシデントパターンとして次のような流れが知られています。ある社員がフィッシングメールのリンクをクリックし、ブラウザに保存していた認証情報が窃取される。その社員がファイルサーバーの共有adminアカウントにもアクセスしていたため、攻撃者はサーバー全体への特権アクセスを得る。操作ログには「admin」としか記録されておらず、誰がどの操作をしたかの特定も、被害範囲の確認もできない──これはあくまで想定例ですが、共有アカウント運用が抱える根本的なリスクを示しています。

中小企業のPAM実装手順

1. 特権アカウントの棚卸しと現状把握

「どんな特権アカウントが存在するか」を把握することが出発点です。意識していないアカウントは管理できません。次のコマンドで現状を洗い出しましょう。

Windowsの棚卸し（管理者権限のPowerShellで実行）

# Administratorsグループのメンバーを列挙
Get-LocalGroupMember -Group "Administrators"

# 有効なローカルユーザー一覧（最終ログインとパスワード最終変更日も確認）
Get-LocalUser | Where-Object { $_.Enabled -eq $true } | Select-Object Name, LastLogon, PasswordLastSet

Linuxの棚卸し

# sudo権限グループのメンバーを確認
getent group sudo wheel

# sudoersファイルの実効設定を確認（コメント行・空行を除外）
sudo grep -v '^#' /etc/sudoers | grep -v '^$'

# /etc/sudoers.d/ 配下の追加設定も確認
sudo ls -la /etc/sudoers.d/

棚卸し結果はスプレッドシートで管理します。「アカウント名・用途・利用者・最終ログイン日・パスワード最終変更日」の列を作り、定期的に更新します。6か月以上ログインのないアカウントは即時無効化を検討してください。

2. 共有アカウントの廃止と個人割り当て

共有アカウントの根本的な問題は「誰がいつ何をしたかを追跡できない」ことです。インシデント調査でも、職務分離による内部不正防止でも、個人に紐づいた操作ログが前提となります。

・共有の「admin」「operator」アカウントを無効化し、個人用の管理者アカウントを作成・移行する
・Windowsのビルトイン Administrator（SID末尾500）はリネームと無効化を推奨
・Linuxのrootへの直接SSH接続を禁止し、個人sudoアカウントで代替する

SSH経由でのrootログイン禁止はsshdの設定変更で実現できます。

# /etc/ssh/sshd_config を編集（変更箇所のみ）
PermitRootLogin no   # デフォルト値（yes または prohibit-password）から変更

# 設定を反映する
systemctl restart sshd

# 変更が反映されたことを確認
sshd -T | grep permitrootlogin

3. 最小権限の原則を貫く

特権アカウントには「本当に必要な権限だけ」を付与するのが基本です。「とりあえずAdministrators全権」という設定は攻撃者への無用な恩恵になります。Linuxのsudoerでは実行可能なコマンドを限定することで、特定の作業だけを特権で行えるよう制限できます。

# /etc/sudoers（visudoで編集）
# webチームのユーザーがnginxの再起動のみ実行できるよう制限
%webteam ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx
%webteam ALL=(ALL) NOPASSWD: /usr/bin/systemctl reload nginx

# バックアップ担当者がrsyncのみ実行できるよう制限
backup_user ALL=(ALL) NOPASSWD: /usr/bin/rsync

Windowsでは「ローカル管理者」ではなく、タスクマネージャーやリモートデスクトップといった個別の権限グループを活用することで、フルのAdministrator権限を与えずに特定の管理作業だけを委任できます。

4. 特権の一時付与（Just-in-Time Access）

「作業時だけ有効化し、終わったら無効化する」という運用が理想です。CyberArkやBeyondTrustといった専用PAMツールは大企業向けで価格も高価ですが、手動または簡単なスクリプトでも同等の効果が得られます。

Windowsのローカルユーザーを作業時だけ有効化する方法

# 通常時は無効化しておく（棚卸しで判明した特権アカウントに適用）
Disable-LocalUser -Name "tanaka-admin"

# 作業前にだけ有効化する
Enable-LocalUser -Name "tanaka-admin"

# 作業終了後は即時無効化する
Disable-LocalUser -Name "tanaka-admin"

AWSを利用している場合は、IAMロールの一時的引き受け（AssumeRole）と最大セッション時間の制限を組み合わせることで、常時アクセス権限を持たせずに必要な時だけ特権を使う設計が実現できます。

Linuxのユーザー権限管理の基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。

5. 操作ログの記録と定期レビュー

特権操作は必ず記録してください。ログがなければインシデント後に「何が起きたか」が判明せず、原因究明も再発防止策の立案もできません。

Windowsでは次のイベントIDが特権アカウント監視に重要です。

・イベントID 4624: ログオン成功（ログオンタイプ3=ネットワーク、10=リモート対話型は特に注目）
・イベントID 4625: ログオン失敗（繰り返しは総当たり攻撃の可能性）
・イベントID 4728・4732: セキュリティグループへのメンバー追加（Administrators追加は要注意）
・イベントID 4720: ユーザーアカウント作成
・イベントID 4672: 特殊権限を持つアカウントのログオン

Linuxはauditdで特権昇格を記録する設定を追加します。

# 特権使用を記録するauditdルール追加
auditctl -a always,exit -F arch=b64 -S setuid -S setgid -k privilege_use

# sudo使用ログの確認（Debian/Ubuntu系）
grep sudo /var/log/auth.log | tail -50

# sudo使用ログの確認（RHEL/CentOS系）
grep sudo /var/log/secure | tail -50

中小企業のActive Directoryセキュリティ対策では、ドメイン環境における特権アカウントの監査ログ設定についてさらに詳しく解説しています。

中小企業でも今日からできること（予算0円から）

専用のPAMツールがなくても、次の手順で着手できます。棚卸しだけでも実施すれば、リスクの全体像が見えてきます。

・今週中：特権アカウント棚卸しリストを作成する（上記コマンドで洗い出し、スプレッドシートに記録）
・今月中：長期未使用アカウントを無効化する（6か月以上ログインなし→即無効化）
・今月中：退職者・委託業者のアカウントを確認・削除する（退職時チェックリストに特権アカウント削除項目を追加）
・翌月中：rootのSSH直接ログインを禁止する（sshd_configの1行変更）
・3か月以内：特権アカウントにMFAを必須化する（Microsoft 365・Google Workspace管理コンソールで設定可能、無料）
・3か月以内：操作ログの月次確認サイクルを確立する（月1回、特権アカウントのログイン履歴を確認する習慣）

中小企業の定期セキュリティ点検チェックリストに、特権アカウントの棚卸しとレビューを月次・四半期作業として組み込むことを推奨します。

よくある誤解と注意点

【誤解1】「PAMツールがなければ何もできない」

専用ツールがあれば管理は効率化されますが、棚卸しリストの作成・共有アカウントの廃止・ログ確認の習慣化だけでも、リスクは大幅に下げられます。ツールなしでも今日から始められることは多い。高価なソリューションは段階的な整備が終わってから検討しても遅くありません。

【誤解2】「Administratorアカウントを使わなければ安全」

「adminというアカウントを使っていないから安全」は誤りです。Administratorsグループのメンバーになっているユーザーアカウントはすべて特権アカウントです。グループメンバーの棚卸しまで行わないと死角が生まれます。

【誤解3】「特権アカウントにMFAは手間がかかりすぎる」

日常的に使う一般アカウントへのMFAは確かに摩擦を生むことがあります。しかし特権アカウントは使用頻度が低いため、MFAの手間は相対的に小さい。守るべき価値は最大なので、特権アカウントへのMFA非適用こそ本末転倒です。

【注意】委託業者のアカウント管理も必須

システム保守を外部に委託している場合、業者に付与したアクセス権限が契約終了後も残存しているケースは一般的に多く報告されています。委託先との契約書に「契約終了時のアカウント削除義務」を明記し、定期的に確認するプロセスを作りましょう。

本記事のまとめ

特権アカウント管理（PAM）は、高価なツールより「棚卸し・個人割り当て・ログ確認」の地道な運用が9割です。次の表を参考に、できるものから着手してください。

特権アカウントは攻撃者が最初に狙う標的であり、管理の甘さは侵害リスクを直接高めます。今日の棚卸しが、明日の被害を防ぐ最も確実な一歩になります。