ADがない環境でファイルサーバーの権限管理をしていた話：ローカルユーザー運用の限界

どうもこんにちは。自然豊かな田舎に生息している情シスです。

ActiveDirectoryサーバーの導入が，承認されずに困った時に行っていた，運用でカバーしていました。
通常，ファイルサーバーのアクセス権を設定する場合，通常はユーザーごと，部署ごと，役職ごとに以下のようにアクセス権を設定します。

• 営業部フォルダ：営業部グループのみがアクセスできる
• サービス部フォルダ：サービス部のみがアクセスできる
• 役員フォルダ：役員だけが変更できるフォルダ

本来であれば，こうした管理は Active Directory，いわゆるADサーバー を使って行うのが一般的です。
ですが，当時はADサーバーがなかったため，かなり無理のある方法でファイルサーバーのアクセス制御を行っていました。今回はそんな昔話をします。

やっていた運用

当時の運用は，簡単に言うと次のようなものです。

この状態で，クライアントPCのユーザー 「Sato」としてログインし，ファイルサーバーへ接続すると，ファイルサーバー側では，同じユーザー名・同じパスワードの資格情報によって認証され，結果としてユーザー 「Sato」に許可されたフォルダへアクセスできるようになります。

一見すると，ちゃんとユーザーごとにアクセス制御できているように見えます。
ただし，これはADのようにユーザーを一元管理しているわけではありません。

クライアントPCとファイルサーバーに，同じ名前・同じパスワードのローカルユーザーをそれぞれ作っているだけです。

ADありとADなしの違い

ADがある場合

ADがある場合，ユーザー情報はドメイン側で一元管理されます。

ADサーバー
 ├─ ユーザー
 │    ├─ Sato
 │    └─ Suzuki
 └─ グループ
　     ├─ 営業部
       └─ サービス部

ファイルサーバー側では，NTFSのセキュリティ画面から，AD上のユーザーやグループに対して権限を設定できます。

共有フォルダ「営業部」　　：営業部グループのみ変更可
共有フォルダ「サービス部」：サービス部グループのみ変更可

しかも，入社，退職や異動が発生しても，AD上のユーザーやグループを変更すれば権限を整理できます。

ADがない場合

ADがない場合，各PCとファイルサーバーがそれぞれ独立してユーザーを持ちます。

クライアントPC
 ├─ ユーザー
 │    └─ Sato
 └─ グループ（ここは設定しても意味がない）

ファイルサーバー
 ├─ ユーザー
 │    ├─ Sato
 │    └─ Suzuki
 └─ グループ
　     ├─ 営業部
       └─ サービス部

同じユーザー「Sato」という名前でも，実体としては別々のローカルユーザーです。
そのため，クライアントPC側とファイルサーバー側で，ユーザー名とパスワードをそろえて運用する必要があります。
一応，ファイルサーバー側でグループを作成して，NTFSでグループ制御することは可能です。

次の章で，破綻しやすい理由を解説します。

この運用が破綻しやすい理由

ユーザーを二重管理する必要がある

前章で説明した通り，ユーザー Satoを制御したい場合，クライアントPCとファイルサーバーに同じユーザーを作る必要があります。

小規模なら問題ないんですが，規模が拡大していくと管理が難しくなります。
ユーザーが10人でも，20アカウントです。

しかも，仮にクライアントPCを複数人が使う場合はもっとアカウント数が増えます。

PC1：ユーザー Sato，Suzuki，Sasakiを作成
PC2：ユーザー Sato，Suzuki，Sasakiを作成
PC3：ユーザー Sato，Suzuki，Sasakiを作成
ファイルサーバー：ユーザー Sato，Suzuki，Sasakiを作成

まぁまぁ，そのくらいならPCキッティング時にやれば終わりだと思うでしょ。
異動や退職した場合を考えてみてください。
クライアントPC10台に設定していたら，10台の設定を変更する必要がでてきます。
これを人手で管理するのは，規模が小さいうちは成立しますが人数やPC台数が増えるとすぐに限界が来ます。

パスワード変更が地獄になる

この方式は，クライアントPC側とファイルサーバー側のパスワードが一致していることが前提です。
最近では，日本においても，内閣サイバーセキュリティセンター（NISC）からパスワードを定期変更する必要はなく，流出時に速やかに変更する旨が示されています。
ですが，当時は1年に1度の更新をしていたのです。これが地獄の始まりです。

パスワードの定期変更は基本は必要なし。ただし流出時は速やかに変更する。
利用するサービスによっては、パスワードを定期的に変更することを求められることがあります。しかし、
前出のように十分に複雑で使い回しのないパスワードを設定した上で、実際にパスワードを破られアカウン
トを乗っ取られたり、サービス側から流出したりした事実がないのならば、基本的にパスワードを変更する
必要はありません。
むしろ、パスワードの基準を定めず、定期的な変更のみを要求することで、パスワードが単純化したり、
ワンパターン化したり、サービス間で使い回しするようになることの方が問題となります。企業などでパス
ワードに関するルールを定める場合にも、利用者に対して定期的な変更を求めないようにすることが原則と
して必要となります。

国家サイバー統括室(NISC)：インターネットの安全・安心ハンドブックVer 5.10（令和7年3月11日）
https://security-portal.cyber.go.jp/guidance/pdf/handbook/handbook-05.pdf

この運用で，どちらか一方だけパスワードを変更すると，ファイルサーバーに接続できなくなります。

クライアントPC側　：ユーザー Sato を 新パスワードへ変更
ファイルサーバー側：ユーザー Sato が 旧パスワードのまま

この状態では，ファイルサーバー側で認証に失敗します。
パスワード変更のたびに複数の場所を正しく更新しなければなりません。

退職者・異動者の管理が危険が危ない

ADサーバーがあれば，退職者や異動者のアカウントを無効化したり，所属グループを変更したりできます。
しかし，ローカルユーザー運用で，対象となるPCやファイルサーバーを個別に対応が必要です。

退職者のアカウントがどこかに残っていると，不要なアクセス経路になりますが，アカウント削除漏れが発生しやすい環境であることが問題です。

まとめ

「動いている」と「安全に管理できている」は別

ADがない環境でも，ファイルサーバーのローカルユーザーを使えば，ある程度のアクセス制御はできます。

この運用では「動いてしまうこと」が一番の問題だと思っています。

同じユーザー名・同じパスワードを使えば，ファイルサーバー側のローカルユーザーとして認証できるため，ある程度はアクセス制御できます。

しかし，それはあくまで小規模環境での応急処置に近いものです。

• 動く
• 管理できる
• 監査できる
• 継続できる

この4つは別です。ローカルユーザーを複製する方式は「動く」までは到達できます。
しかし，「管理できる」「監査できる」「継続できる」という面では弱いです。

ファイルサーバーの権限管理は，単に「アクセスできる・できない」を設定するだけではありません。
誰が，どの権限で，どのフォルダにアクセスできるのかを継続的に管理できることが重要です。
そのためには，ローカルユーザーの複製ではなく，ADのような認証基盤を使って一元管理する必要があります。

次回は、ADサーバーを導入した後に、既存のローカルユーザー運用からどのように段階的に切り替えていくかを整理します。

参考

Super User: Sharing two computers on the same network
https://superuser.com/questions/1552178/sharing-two-computers-on-the-same-network

Microsoft Learn: Local accounts
https://learn.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts

Microsoft Learn: Security identifiers
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers

Petri: Enable Anonymous Access to a Windows Server File Share
https://petri.com/enable-anonymous-access-to-a-windows-server-file-share/

Ask Leo!: How Do I Get My Windows Computers to Network with Each Other?
https://askleo.com/how-do-i-get-my-windows-computers-to-network-with-each-other/