はじめに
Linuxエンジニアにとって、ファイルの権限管理といえば ls -l で見る rwxr-xr-x です。「所有者・グループ・その他」の3区分に対して「読み・書き・実行」を割り振るだけで、非常に直感的です。
しかし、WindowsのNTFS（New Technology File System）は 「誰が、何に対して、どんな詳細な操作ができるか」をリスト形式で管理します。この「リスト形式」こそが、Linuxエンジニアを混乱させる ACL（Access Control List）の正体です。
1. 「3つの数字」vs「リスト形式」
Linuxは固定の3枠（User / Group / Other）ですが、Windowsは 「ACE（Access Control Entry）」 というエントリを束ねた 「ACL（Access Control List）」 というリストで管理します。
| 比較項目 | Linux（基本権限） | Windows（NTFS） |
|---|---|---|
| 管理単位 | 所有者 / グループ / その他（固定3枠） | ユーザー/グループを任意の数だけ追加可能 |
| 権限の種類 | r, w, x（3種） | 読取、書込、変更、フルコントロール等（10種以上） |
| 拒否の概念 | 明示的な拒否なし（権限を与えない＝拒否） | 「拒否（Deny）」という明示的な設定がある |
| 継承の概念 | 基本的にない（umask のみ） | 上位フォルダの設定が下位に自動で伝播する |
ACL のイメージ
Linux の権限が「1枚のチケット（3枠固定）」だとすると、Windows の ACL は 「入場者リスト（名刺の束）」 です。
【Linux: /data ディレクトリの権限】
rwxr-x--- owner=alice group=devs
【Windows: C:\Data の ACL（概念図）】
┌──────────────────────────────────────────┐
│ ACE 1: SYSTEM → フルコントロール │
│ ACE 2: Administrators → フルコントロール │
│ ACE 3: devs グループ → 変更（M） │
│ ACE 4: alice → フルコントロール │
│ ACE 5: mallory（拒否） → 読み取り拒否 │
└──────────────────────────────────────────┘
2. Windowsの特異点①：継承（Inheritance）
Linuxエンジニアが最もハマるのが 「継承」 です。
-
Linux:
/dirの権限を変えても、その下の/dir/fileの権限は-Rオプションを付けない限り変わりません。 - Windows: 親フォルダに「devs グループ：変更許可」を与えると、その下に作成されるすべてのファイル・サブフォルダに 自動的にその権限が継承（コピー） されます。
C:\Projects\ ← ここに devs:変更(M) を設定
│
├── frontend\ ← 自動的に devs:変更(M) を継承
│ └── index.html ← 自動的に devs:変更(M) を継承
│
└── backend\ ← 自動的に devs:変更(M) を継承
└── app.py ← 自動的に devs:変更(M) を継承
継承の無効化
「このフォルダだけ親の設定を引き継ぎたくない」という場合、継承の無効化（Disable Inheritance） を行います。継承を無効化せずに権限を個別変更しようとしても「親から継承されているため変更できません」とブロックされます。
# PowerShell で継承を無効化し、現在の権限をコピーとして保持する
$acl = Get-Acl "C:\Projects\secret"
$acl.SetAccessRuleProtection($true, $true) # 第1引数: 継承を無効化, 第2引数: 既存ACEを保持
Set-Acl "C:\Projects\secret" $acl
icacls を使う場合は以下のとおりです。
:: 継承を無効化し、既存の権限をそのまま保持する
icacls C:\Projects\secret /inheritance:d
3. Windowsの特異点②：「許可」と「拒否」の優先順位
Linuxには「明示的な拒否」という概念はありません。しかしWindowsには 「拒否（Deny）」 という設定があり、複数の ACE が存在するときに厳密な優先順位で評価されます。
優先度（高） ─────────────────────────── 優先度（低）
明示的な拒否 > 明示的な許可 > 継承された拒否 > 継承された許可
具体例で理解する
シナリオ:
- alice は devs グループのメンバー
- devs グループ: 読み取り「許可」
- alice 個人: 読み取り「拒否」（明示的）
結果: alice はアクセス「拒否」
→ 明示的な拒否がグループの許可より優先される
運用上の注意：
「特定のユーザーだけアクセスさせない」目的で「拒否」を使いたくなりますが、継承と組み合わさると予期しない挙動を招きやすく、障害調査が困難になります。基本は「許可を与えない」ことで制御するのがWindows運用の鉄則です。「拒否」はどうしても必要な場合の最終手段と位置づけましょう。
4. 実践：コマンドで権限を確認・操作する
権限の確認
Linux の ls -l に相当するのが PowerShell の Get-Acl と、コマンドプロンプトの icacls です。
# ACL を一覧表示する（ls -l 相当）
Get-Acl C:\SharedData | Format-List
# ACE を1行ずつ見やすく表示する
(Get-Acl C:\SharedData).Access | Select-Object IdentityReference, FileSystemRights, AccessControlType, IsInherited
出力例：
IdentityReference FileSystemRights AccessControlType IsInherited
----------------- ---------------- ----------------- -----------
BUILTIN\Administrators FullControl Allow True
DOMAIN\devs Modify Allow True
DOMAIN\alice Read Deny False
IsInherited が True のものが親から継承された ACE です。
権限の変更
# devs グループに「変更（Modify）」権限を付与する（chmod g+w 相当）
$acl = Get-Acl "C:\Data"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
"DOMAIN\devs", "Modify", "ContainerInherit,ObjectInherit", "None", "Allow"
)
$acl.AddAccessRule($rule)
Set-Acl "C:\Data" $acl
icacls でも同様の操作が可能です。
:: devs グループに変更権限を付与（サブフォルダ・ファイルにも継承）
icacls C:\Data /grant "DOMAIN\devs:(OI)(CI)M"
:: OI = ObjectInherit（ファイルに継承）
:: CI = ContainerInherit（サブフォルダに継承）
:: M = Modify（変更）
Linux の chmod との対応表
| Linux | Windows（icacls） | 意味 |
|---|---|---|
r |
R |
読み取り |
rw |
M（Modify） |
読み取り＋書き込み（削除・名前変更も含む） |
rwx |
F（FullControl） |
すべての操作 |
chmod +x |
直接対応なし（実行可能ファイルはOS拡張子で判断） | 実行権限 |
覚えておくべき制限：
Linux の755や644を NTFS に完璧に翻訳することはできません。Windows には「属性の読み取り」「拡張属性の書き込み」などOS独自の細かい権限（特殊なアクセス許可）が存在するためです。まずは 「読み取り（R）」「変更（M）」「フルコントロール（F）」 の3つを押さえることから始めましょう。
まとめ
| 観点 | Linux | Windows（NTFS） |
|---|---|---|
| 権限の構造 | 固定3枠（UGO） × 3ビット | ACL（ACE の積み重ね） |
| 対象の柔軟性 | グループは1つのみ | ユーザー・グループを任意の数だけ設定可能 |
| 継承 | なし（-R で手動再帰） | あり（親→子へ自動伝播） |
| 拒否の優先 | なし（権限なし＝拒否） | 明示的な拒否が最強 |
| 確認コマンド | ls -l |
Get-Acl、icacls
|
| 変更コマンド |
chmod、chown
|
Set-Acl、icacls /grant
|
WindowsのNTFSアクセス許可は、Linuxエンジニアから見ると「過剰に複雑」に映るかもしれません。しかしこの細かさがあるからこそ、数万人規模の組織で「この部署のこの役職の人だけ、このファイルの上書きを禁止する」といった緻密な制御が実現できています。「継承」と「拒否の優先順位」 の2点を押さえれば、Windowsのファイルサーバー管理は格段に理解しやすくなります。