Windows 11のユーザープロファイルからAdministrators権限を外すべきか？安全なアクセス許可設定と運用ガイド

企業利用のWindows 11環境では、「ユーザープロファイルのフォルダーにローカル管理者（Administrators）がフルアクセスできてしまうのはコンプライアンス的にNGでは？」という相談が増えています。新しいユーザープロファイルを作成すると自動的にAdministratorsが権限を持つのは、実はWindowsの設計上の既定動作です。本記事では、その技術的な背景と、無理に権限を削るリスク、そして現実的にコンプライアンス要件を満たすための運用・設定の考え方を、システム管理者目線で詳しく解説します。

Windows 11のユーザープロファイルとAdministrators権限の関係

Windows 11で新しいユーザープロファイル（C:\Users\<ユーザー名>）が作成されると、そのフォルダーのアクセス許可には多くの環境で次のようなエントリが含まれます。

• そのユーザー本人（<ドメイン\ユーザー名>）
• SYSTEM
• Administrators（ローカル管理者グループ）
• （環境によって）Users や TrustedInstaller 等

ここで争点になるのが Administrators グループがプロファイルフォルダーにフルアクセス権を持っている 点です。コンプライアンス要件によっては、「ユーザー本人と SYSTEM だけにしたい」「ローカル管理者にも見られたくない」という要求が出てきます。

しかし、この設定は「たまたまそうなっている」のではなく、Windowsの復旧性・運用性を考慮した上での設計上の既定動作です。特に企業環境では、障害対応や調査、退職者データの回収など、管理者がユーザープロファイルにアクセスしなければならないケースが現実的に存在します。

項目	概要
C:\Users	各ユーザーのプロファイルフォルダー（ドキュメント、デスクトップ、AppDataなど）のルート。
デフォルトプロファイル	C:\Users\Default を基に、新しいユーザープロファイルが作成される。
ユーザープロファイルサービス	プロファイル作成時にACL（アクセス制御リスト）を自動的に設定し、必要な保護を行う。
Administrators 権限	復旧・バックアップ・トラブルシュート・マイグレーションなどを可能にするための設計。

このため、Administratorsのアクセス許可を「完全に排除しよう」とすると、OSの想定から外れた構成となり、将来的なトラブルの原因になりやすいことを理解しておく必要があります。

「管理者から守りたい」はどこまで技術的に可能か

コンプライアンス要件としてよくあるのが「ローカル管理者と言えど、エンドユーザーのデータを勝手に覗いてはいけない」「技術的にアクセスできないようにして欲しい」といったものです。しかしWindowsのセキュリティモデル上、管理者は最終的にはどんなファイルにもアクセスできてしまう存在である、という前提を変えることはできません。

たとえば、Adminsitratorsの明示的なアクセス許可を削除しても、管理者は次のような手段でアクセスできてしまいます。

• フォルダーの所有権を取得し、ACLを差し替える
• 別のOSで起動してディスクをマウントし、オフラインで閲覧する
• 「システムの復元」やバックアップイメージから検証用コピーを取る

つまり、「Administratorsの許可を消したから、管理者は絶対に見られない」という状況は作れません。作れるのは、せいぜい次のような状態です。

• 通常運用の範囲では簡単にアクセスできない（ひと手間かかる）
• アクセスしようとした痕跡がログとして残る
• 正規プロセス（申請・承認）を経ないとアクセスしてはいけない、というルールと運用が整備されている

このギャップを整理すると、ACLをいじるだけでコンプライアンス要件を丸ごと満たすのは難しく、「技術的な制御」と「運用上の統制」を組み合わせる必要があることがわかります。

やりたいこと	ACL削除だけで達成できるか	現実的なアプローチ
管理者が勝手に中身を覗けないようにしたい	部分的にしか不可（迂回手段がある）	PAM、監査ログ、申請・承認プロセスで統制する。
障害時やインシデント調査でのみアクセスしたい	ACL削除はむしろ復旧を困難にする可能性	Administrators権限は残し、利用時に理由とログを残す。
「技術的に完全遮断されている」と説明したい	Windowsの権限モデル上ほぼ不可能	「最終的なアクセスは可能だが、使い方を厳格に管理する」と説明する。

推奨される方針：権限は残し、特権の使い方を厳格に管理する

実務的にもっとも安全で現実的な方針は、Administratorsのアクセス許可は既定のまま維持しつつ、特権の使い方を統制・記録することです。ここからは、具体的な統制手段を整理します。

特権アクセス管理（PAM / JIT / JEA）で「常用管理者」をなくす

まず取り組みたいのが、「常に管理者でログオンする運用」をやめることです。常時管理者で作業していると、「ちょっと見ただけ」という軽い気持ちでユーザープロファイルを覗けてしまい、統制もログも効きません。

施策	概要	ポイント
管理者アカウントの分離	通常業務用アカウントと管理用アカウントを分ける。	管理用アカウントでの常用ログオンは禁止し、必要時のみ利用。
JIT (Just-In-Time) 管理	必要なタイミングでだけ管理者グループに所属させる。	時間制限付きでグループに追加する仕組みを導入。
JEA (Just Enough Administration)	PowerShellなどで、必要最小限の管理コマンドだけを許可する。	「閲覧禁止だが特定操作は可能」など細かい制御も検討できる。
LAPS 等によるローカル管理者パスワード管理	ローカルAdministratorのパスワードを端末ごとに自動ランダム化。	勝手にローカル管理者でログオンできない状態を作る。

これらを導入しておくと、「そもそも簡単には管理者になれない」状態になるため、ユーザープロファイルへの不要なアクセスも自然と減少します。

監査と証跡：アクセスしたら必ずログに残す

次に重要なのが、管理者がユーザープロファイルにアクセスした際の証跡を残すことです。Windowsでは、監査ポリシーとSACL（監査用ACL）を利用して、「誰が、いつ、どのフォルダーにアクセスしたか」をセキュリティログに記録できます。

代表的な設定の流れは次の通りです。

• グループポリシーで「監査ポリシー > オブジェクトアクセス」を有効化
• 対象となるユーザープロファイルフォルダー（または親フォルダー）にSACLを設定
• Administrators（または管理用アカウント）によるアクセスを成功／失敗ともに記録するよう指定
• セキュリティログを中央のSIEMやログサーバーに集約し、一定期間保管

SACLの設定は、フォルダーのプロパティ画面から GUI でも行えます。

• フォルダーを右クリック →「プロパティ」 →「セキュリティ」タブ →「詳細設定」
• 「監査」タブでエントリを追加
• プリンシパルにAdministrators、アクセスに「フォルダーへのアクセス」などを指定

これにより、「管理者が正当な理由なくユーザープロファイルを覗いていないか」を後から検証できるようになります。技術的に完全遮断できない以上、「のぞけば必ずバレる」状態を作ることが、統制上は非常に有効です。

BitLockerとクラウドサービス、DLPによるデータ保護

ユーザープロファイルを守るという観点では、フォルダーのACLだけではなく、デバイス全体とデータのライフサイクルも考える必要があります。

• BitLockerによるフルディスク暗号化：ノートPCの盗難・紛失時に、第三者がオフラインでディスクの中身を読むことを防ぐ。
• OneDrive for Business や SharePoint Online へのデータ集約：ローカルプロファイルの「ドキュメント」「デスクトップ」をクラウドと同期し、端末依存度を下げる。
• DLP / IRM：ファイル自体に利用制限や暗号化ポリシーを埋め込み、コピー・印刷・共有を制御する。

これらを組み合わせることで、「ローカルプロファイルに置かれたデータ」に対するリスクも大幅に下げることができます。

手順化・ルール化：正当なアクセスを定義する

最後に、管理者がユーザープロファイルにアクセスしてよいケースと、その手順をあらかじめ定義しておくことが重要です。たとえば次のようなシナリオがあります。

• 障害調査のためにログや設定ファイルを確認する
• コンプライアンス違反の疑いがあり、端末内のデータを調査する
• 退職者のファイルを引き継ぎ先へ移管する
• 法的要請に基づくデータ保全・提出

これらについて、「誰が」「どのような申請・承認プロセスを経て」「どの範囲まで」アクセスしてよいかを文書化し、教育しておくと、コンプライアンス部門との合意形成がスムーズになります。

Administratorsの明示的な許可を外したい場合（非推奨）

重要：ここから紹介する内容は「どうしてもAdministratorsの明示的な許可を削りたい」という場合の、現実的なやり方とリスクの整理です。一般的にはサポート外になりやすく、OS更新やツールの動作にも影響する可能性があるため、本番環境での適用は十分な検証とリスク承認が前提になります。

ローミングユーザープロファイルの場合のグループポリシー

Active Directory環境でローミングユーザープロファイルを使っている場合、次のグループポリシーで Administrators がローミングプロファイルに追加される挙動を制御できます。

ポリシーパス（例）

コンピューターの構成 > 管理用テンプレート > システム > ユーザー プロファイル > 「ローミング ユーザー プロファイルに Administrators セキュリティ グループを追加する」

• 既定では「有効」または「未構成」で、Administrators が追加される動作になる。
• これを「無効」に設定すると、ローミングプロファイルのACLにAdministratorsを自動的に追加しないよう制御できる。
• このポリシーはローミングプロファイル向けであり、ローカルプロファイル（C:\Users\<ユーザー名>）のACLには直接影響しない。

プロファイル種別	対象となるストレージ	このGPOの影響
ローカルプロファイル	端末ローカルの C:\Users	影響なし（ACLはユーザープロファイルサービスが設定）。
ローミングプロファイル	ファイルサーバー上のプロファイルパス	Administrators の追加有無を制御可能。
フォルダーリダイレクト＋クラウドストレージ	OneDrive/SharePoint 等	別の仕組みでアクセス制御される。GPOの影響は間接的。

ローミングプロファイルを使っている環境では、まずこのGPOの設定を確認し、「そもそもサーバー側に余計な権限が付かないようにする」ことを検討するとよいでしょう。

ローカルプロファイルからAdministratorsの明示的許可を削除するスクリプト例

ローカルプロファイルに対しては、既定でAdministratorsを外すための公式設定はありません。そのため、実現しようとすると「プロファイル作成後にスクリプトでACLを調整する」というアプローチになります。

代表的なツールとしては、ACL操作用の icacls を利用します。例えば、ログオンスクリプトや Intune などから次のようなバッチを流す方法が考えられます。

@echo off
setlocal
set "P=C:\Users\%USERNAME%"
echo Target Profile: %P%

rem Administrators の「明示的な許可」を削除（継承された分はそのまま）
icacls "%P%" /remove:g Administrators >nul 2>&1

endlocal

PowerShellで書くと次のようになります。

$profilePath = "C:\Users\$env:USERNAME"
Write-Host "Target Profile: $profilePath"
icacls $profilePath /remove:g Administrators | Out-Null

複数ユーザーに対して一括で適用する場合は、Public や Default などの特殊フォルダーを除外してループ処理をすることになります。

$usersRoot = "C:\Users"
$exclude = @("Public","Default","Default User","All Users")

Get-ChildItem $usersRoot -Directory |
  Where-Object { $exclude -notcontains $_.Name } |
  ForEach-Object {
      Write-Host "Processing $($_.FullName)"
      icacls $_.FullName /remove:g Administrators | Out-Null
  }

いずれの場合も、プロファイルのルートフォルダーだけを対象にし、配下を再帰的に書き換えないことが重要です。AppData 以下にはOSやアプリケーションが想定しているACLが多数設定されており、無闇な変更は動作不良の原因になります。

また、次の点にも注意が必要です。

• バックアップエージェントやEDR、資産管理ツールなどが、管理者権限でプロファイルにアクセスする設計になっている場合、動作に影響する可能性がある。
• プロファイルの修復・退避・マイグレーション手順が正常に動かなくなる可能性がある。
• ベンダーサポートを受ける際、「既定のACLに戻してから再現してください」と言われるケースが出てくる。

ベースイメージ（ゴールデンイメージ）で対応しにくい理由

「それならベースイメージ側で C:\Users\Default のACLを調整しておけば、新規ユーザープロファイルでもAdministratorsが入らないのでは？」と考えるケースもあります。しかし実際には、次の理由から期待通りには動かないことが多いです。

試み	意図	起こりがちな実際
デフォルトプロファイルのACLを変更	新規プロファイル作成時にそのACLがコピーされることを期待。	プロファイルルートのACLはユーザープロファイルサービスが再設定し、結果的にAdministratorsが入る。
イメージ内でC:\Users配下を事前作成	ユーザーフォルダーをあらかじめ作っておく。	ドメイン参加や初回ログオン時の処理でACLが上書きされる、もしくはProfile不整合の原因になる。
インプレースアップグレードで引き継ぎ	過去バージョンからACL設定を持ち越す。	アップグレードプロセスでACLが標準化されることがあり、意図しない戻りが発生。

このため、「ベースイメージをいじれば済む」という発想は危険で、実際にはOSのプロファイル作成ロジックと戦うことになると考えた方がよいでしょう。

Administrators権限を削ることによるリスク整理

Administratorsの明示的な許可を削った場合に起こりうる影響を、少し視点を変えて整理してみます。

影響領域	具体的なリスク
障害対応	ユーザーがログオンできない状態で、プロファイル内のログや設定ファイルを取得できず、復旧が遅延する。
バックアップ・リストア	バックアップソフトがアクセス拒否となり、ユーザーデータが正しく保護されない可能性。
マイグレーション	PC入れ替え時のプロファイル移行ツール（USMT等）が正常に動作しない。
EDR・資産管理	エージェントがプロファイル配下のファイルをスキャンできず、検知・保護の穴が生まれる。
ベンダーサポート	サポートに問い合わせた際、「標準構成ではない」と判断され、切り分けに時間がかかる、もしくはサポート対象外となる。

これらのリスクを踏まえると、「管理者からユーザープロファイルを守りたい」という目的だけで、既定のAdministrators権限を安易に削るのは得策とは言えません。

実務で使えるチェックリスト

ここまでの内容を踏まえ、Windows 11環境でユーザープロファイルのAdministrators権限をどう扱うか検討する際のチェックリストをまとめます。社内設計書や標準化ドキュメントを作る際のひな型としても利用できます。

観点	確認・検討内容
プロファイル形式	ローカルプロファイルのみか、ローミングプロファイル／フォルダーリダイレクトを利用しているか。
ローミングプロファイルGPO	「ローミング ユーザー プロファイルに Administrators セキュリティ グループを追加する」の設定状態を確認したか。
特権アクセス管理	PAM、JIT、JEA、LAPSなどを導入し、「常用管理者」を排除する計画があるか。
監査とログ	オブジェクトアクセスの監査を有効化し、ユーザープロファイルへのアクセスがログに残るようSACLを設定したか。
バックアップ・EDR	ACL変更後もバックアップ、EDR、資産管理ツールなどが問題なく動作するかテストしたか。
更新・再作成	Windows Updateやプロファイル再作成を行っても、ACL変更が元に戻らないか確認したか。
運用手順	障害対応・調査・退職者対応など、正当な理由でのアクセス手順と承認フローを文書化したか。
リスク承認	Administrators権限を削る場合、そのリスクをセキュリティ・コンプライアンス・IT運用など関係部門で明示的に合意したか。

まとめ：Windows 11のユーザープロファイルとコンプライアンス要件をどう折り合いをつけるか

Windows 11のユーザープロファイルにAdministrators権限が付与されるのは、OS設計上の既定動作であり、復旧性や運用性を確保するためのものです。一方で、コンプライアンスの観点から「管理者といえども無制限にアクセスできるべきではない」という考え方も、企業として当然の要求です。

この二つを無理に「技術だけ」で解決しようとすると、サポート外構成や運用不能な状態に陥るリスクが高まります。現実的な落としどころは、次のような方針になります。

• 基本方針：Administratorsのアクセス許可は既定のまま残し、特権アクセス管理・監査・データ保護・運用手順で統制する。
• ローミングプロファイル：グループポリシーでAdministratorsが追加されないようにすることを検討し、サーバー側でのアクセス制御と監査を強化する。
• ローカルプロファイル：やむを得ずAdministratorsの明示的許可を削る場合は、スクリプトによる後処理と十分な検証、ロールバック手順を用意する。
• コンプライアンス部門との対話：「技術的に完全遮断はできないが、その代わりにアクセスのハードルと透明性を高める」という説明を行い、ルールとログで要求を満たす方向で合意形成する。

最終的には、「どこまでを技術で、どこからを運用ルールでカバーするか」という設計判断になります。本記事の内容をベースに、自社のセキュリティポリシーと運用現場の現実のバランスを取りながら、Windows 11のユーザープロファイル設計を見直していただければ幸いです。