Windows Server 2019 の FSRM（ファイル サーバー リソース マネージャー）で「基本すべてのファイルをブロックし、例外として *.doc だけ許可したい」という要件は、共有フォルダーの“用途固定”をしたい現場でよく出てきます。本記事では、ファイル スクリーン（File Screening）と例外（Exception）を使って実現する具体手順と、運用で詰まりやすいポイントをまとめます。
Windows Server 2019 の FSRM で「全ファイルをブロックしつつ *.doc だけ許可」は実現できる
結論から言うと、Windows Server 2019 の FSRM では「全ファイルを対象にブロック」→「.doc だけ例外として許可」という形で要件を満たせます。
ポイントは、FSRM のファイル スクリーンが基本的に“ブロック対象（禁止）を定義する仕組み”であることです。いわゆる「許可リスト（Allow list）」モードがあるわけではありません。しかし、ワイルドカードで“全部禁止”を作り、例外で“許可したい拡張子だけ除外”すると、結果として「.doc だけ通る」状態を作れます。
まず押さえるべき前提：FSRM は拡張子（ファイル名パターン）ベース
FSRM のファイル スクリーンは、ファイルの中身（MIME/署名）ではなくファイル名パターン（主に拡張子）で判定します。この仕様を理解しておくと、期待値ズレやトラブルを避けやすくなります。
| 項目 | FSRM（ファイル スクリーン）でできること | FSRMだけでは難しいこと |
|---|---|---|
| 判定方法 | ファイル名パターン（例：*.doc, *.tmp, *） | ファイル内容の解析、実体の種類判定 |
| 主な用途 | 共有フォルダーの用途制限（画像禁止、動画禁止、実行ファイル禁止など） | DLPのような機密判定、マルウェア本体検出 |
| 回避され得る点 | 拡張子変更によるすり抜け（例：.exe を .doc に変更） | 拡張子偽装の完全封じ |
今回の要件は「拡張子で運用ルールを固定する」という範囲に収まっているため、FSRM と相性が良い部類です。ただし、後半で触れるOffice の一時ファイル問題は現場で非常に起きやすいので、実装前に把握しておく価値があります。
用語整理：ファイル グループ、ファイル スクリーン、例外、アクティブ/パッシブ
ファイル グループ（File Group）
「どのファイル名パターンを対象にするか」をまとめたものです。たとえば、次のように作ります。
- Block-All：*（すべてのファイル）
- Allow-DOC：*.doc
この「*」が重要です。よくあるミスとして「*.*」を使ってしまうケースがありますが、運用上は次の差が効いてきます。
| パターン | マッチしやすさ | 注意点 |
|---|---|---|
| * | 最も広い（拡張子なしファイルも含めて基本すべて） | 「本当に全部」をブロックしたいときの基本 |
| *.* | ドットを含むファイル名が中心 | 拡張子なし（ドットなし）ファイルが想定外に通る可能性がある |
ファイル スクリーン（File Screen）
ファイル グループを使って、指定フォルダー配下へのファイル保存を制御します。
- アクティブ スクリーニング：該当ファイルを作成/コピー/リネーム等できない（ブロック）
- パッシブ スクリーニング：保存は許すがログ/通知する（監視）
今回の「全ブロックして .doc だけ通す」は、アクティブ スクリーニングが前提です。
ファイル スクリーンの例外（File Screen Exception）
既にかかっているファイル スクリーンの制御を、特定のフォルダーで緩めるための仕組みです。今回のように、
- 親側で「全部ブロック」
- 子（対象）側で「*.doc は例外」
という作りにすると、結果として「対象フォルダーは *.doc だけ通る」状態になります。
最もトラブルが少ない設計：親で全部ブロック→対象で .doc だけ例外
「ある特定フォルダーだけ .doc のみ許可したい」場合、実装を安定させるコツは“親フォルダー（共有ルート）で全ブロックを作り、対象フォルダーに例外を置く”ことです。
イメージ：
\\SERVER\Share（共有ルート）
├─ DocsOnly（ここだけ *.doc を許可したい）
├─ Public（別ルール）
└─ Temp（別ルール）
方針：
Share に「* をブロック」するファイル スクリーン（アクティブ）を設定
DocsOnly に「*.doc を許可」する例外を設定この構造にすると、例外の適用範囲が明確になり、管理画面上の把握もしやすくなります。
手順：GUI で「全ファイルをブロックしつつ *.doc だけ許可」を設定する
前提：FSRM（ファイル サーバー リソース マネージャー）をインストール
FSRM が未導入の場合は、サーバー マネージャーから追加します。
- サーバー マネージャー →「管理」→「役割と機能の追加」
- 「ファイル サービスと記憶域サービス」→「ファイル サービスおよび iSCSI サービス」
- 「ファイル サーバー リソース マネージャー」にチェック
PowerShell で入れる場合の例（管理者権限）：
Install-WindowsFeature -Name FS-Resource-Manager -IncludeManagementToolsインストール後、管理ツールの「ファイル サーバー リソース マネージャー」または fsrm.msc でコンソールを開きます。
ファイル グループを作る（Block-All と Allow-DOC）
まず、ブロック用と例外用のファイル グループを作ります。
Block-All（全部ブロック用）
- FSRM コンソール →「ファイル スクリーニング管理」→「ファイル グループ」
- 右クリック →「ファイル グループの作成」
- グループ名：Block-All
- ファイル名：*
Allow-DOC（例外で許可する .doc）
- 同様に「ファイル グループの作成」
- グループ名：Allow-DOC
- ファイル名：*.doc
運用でよくある追加（要件次第）：
- .docx も許可したい：*.docx を Allow 側に追加
- テンプレート：*.dot, *.dotx
- Word のバックアップや自動回復が必要：後述の「一時ファイル」設計を参照
親フォルダーに「全ファイルブロック」のファイル スクリーンを作成（アクティブ）
次に、共有ルートなど親フォルダーに対して「全部禁止」を作ります。
- FSRM コンソール →「ファイル スクリーニング管理」→「ファイル スクリーン」
- 右クリック →「ファイル スクリーンの作成」
- スクリーン パス：例 D:\Shares\ShareRoot（運用の共有ルート）
- 「カスタム プロパティを定義」またはテンプレートを選ぶ
- スクリーニングの種類：アクティブ スクリーニング
- ファイル グループ：Block-All を追加（= * をブロック）
通知（Notification）は必須ではありませんが、運用を考えると設定しておくと後で助かります。
- イベント ログに記録（最低限）
- 管理者へメール通知（運用に応じて）
- コマンド実行（SIEM 連携や独自ログ収集が必要なら）
対象フォルダーに「*.doc を例外として許可」するファイル スクリーン例外を作成
次に、.doc だけ許可したいフォルダーに例外を作ります。
- FSRM コンソール →「ファイル スクリーニング管理」→「ファイル スクリーンの例外」
- 右クリック →「ファイル スクリーン例外の作成」
- 例外パス：例 D:\Shares\ShareRoot\DocsOnly
- 例外にするファイル グループ：Allow-DOC を追加（= *.doc を例外扱いにして許可）
ここでの実務ポイント：
- 例外は、ファイル スクリーンが適用される範囲内（親にスクリーンがあり、その配下）に置くのが基本です。
- 「対象フォルダーに直接ファイル スクリーンを作って、同じフォルダーに例外を置く」という構成が環境や操作手順によってやりにくい場合は、親（共有ルート）に全ブロックを作り、対象フォルダーに例外という形に寄せると安定します。
動作確認：期待通り「.doc だけ通る」かテストする
設定を入れたら、必ずクライアント側（SMB 経由）で検証します。サーバー上でローカル作業するのと、ネットワーク越しの挙動が違って見えるケースもあるためです。
| テスト内容 | 例 | 期待される結果 | 補足 |
|---|---|---|---|
| .doc を新規作成/コピー | test.doc | 成功 | 例外が効いていれば通る |
| .txt を新規作成/コピー | test.txt | 失敗（ブロック） | “全ブロック”が効いているか確認 |
| 拡張子なしファイルの作成 | test | 失敗（ブロック） | Block-All を * にしていると確実 |
| .doc へリネーム | test.txt → test.doc | 環境・操作で差が出ることがある | FSRM は拡張子判定のため、運用ルールの説明が必要 |
ブロックされた場合、ユーザーからは「保存できない」「アクセスが拒否される」といった形で見えます。管理者側はイベント ログや FSRM の通知で追えるようにしておくと、問い合わせ対応が格段に楽になります。
ハマりどころ：Office は「一時ファイル → リネーム」で保存することがある
今回の構成で最も起きがちなトラブルが、Word など Office アプリの保存動作です。
Office は編集中にロックファイルを作ったり、保存時に一時ファイルを作ってから本体へ置き換えたりすることがあります。つまり、最終的に .doc を作りたいだけでも、途中で .tmp など別拡張子のファイルが同じフォルダーに作られると、「.doc は許可したのに保存できない」が起きます。
代表的に考慮が必要になりやすい例（実際の挙動は Office バージョン・設定・操作に依存します）：
| 用途 | ファイル例（パターン） | 起きる症状 | 対処の考え方 |
|---|---|---|---|
| 一時ファイル | *.tmp など | 保存時に失敗、上書き保存できない | 本当に必要な場合のみ例外に追加（後述） |
| 自動回復 | *.asd など | 復元ファイルが作れず、回復機能が弱くなる | 要件として必要なら例外に含める |
| バックアップ/差分 | *.wbk など | バックアップが残らない | 運用ポリシーに合わせて許可 |
現実的な落としどころとしては、次のいずれかを選ぶことが多いです。
- 厳格に “.doc のみ” を守る：Office の一部挙動を犠牲にする（保存/自動回復が不安定になる可能性）
- 業務上必要な一時ファイルだけ許可する：Allow 側ファイル グループに必要最小限のパターンを追加し、実運用を成立させる
おすすめは、いきなりアクティブで本番投入するのではなく、短期間だけパッシブ スクリーニング（監視）で実際に作られているファイル名パターンを把握し、許可すべき一時ファイルがあるかを見極めてからアクティブ化する流れです。これだけで「保存できない」系のトラブルをかなり減らせます。
運用のコツ：許可リストを“増やしすぎない”ための設計
「全ブロック＋例外許可」は強力ですが、例外が増えすぎると“いつの間にか何でも置けるフォルダー”に戻ってしまいます。運用で破綻しないためのコツを整理します。
例外ファイル グループは「用途別」に分けて管理する
Allow-DOC にすべてを詰め込むのではなく、用途別に分けると判断が速くなります。
| ファイル グループ名（例） | 入れるパターン例 | 狙い |
|---|---|---|
| Allow-DOC | *.doc | 本命の許可拡張子 |
| Allow-Office-Temp | *.tmp など（必要最小限） | Office 保存を成立させるため |
| Allow-Templates | *.dot, *.dotx | テンプレ運用がある場合 |
こうしておくと、「なぜ *.tmp を許可しているのか？」が後から見ても説明しやすくなり、無駄な許可拡張子の追加を抑制できます。
通知は“入れすぎず、捨てすぎず”
通知を多くしすぎるとアラート疲れで見なくなります。おすすめは次の順で整備することです。
- 最初はイベント ログ記録を有効化
- 問い合わせが多い／監査が必要ならメール通知を追加
- SIEM 連携があるならコマンド実行でログ転送
共有設計で“そもそも例外が少ない”状態を作る
FSRM の制御は、共有の設計段階で難易度が決まります。
- 用途ごとに共有やフォルダーを分ける（DocsOnly、ImagesOnly、Temp など）
- 「何でも置ける共有」を作らない（作る場合は監視を強める）
- ユーザーが誤って置き場を間違えにくい命名・案内をする
FSRM を“最後の砦”にするより、共有設計＋FSRMで二段構えにすると運用は安定します。
セキュリティ上の注意：拡張子だけの制御には限界がある
FSRM は便利ですが、拡張子ベースである以上、次の点は仕様として割り切りが必要です。
- 拡張子偽装は理屈上可能（例：実体が実行ファイルでも .doc にする）
- ファイル内容の危険性判定はしない（マクロや脆弱性を検出するものではない）
もし「機密情報の持ち出しを防ぐ」「悪性ファイルを根絶する」まで求められるなら、FSRM 単体ではなく、次のような仕組みとの併用を検討した方が現実的です。
- エンドポイント/サーバー側のアンチウイルス（リアルタイム保護）
- アプリ制御（実行ファイルの実行制限）
- DLP、情報保護、監査ログ強化
ただし、共有フォルダーの「置き場ルール」を強制するという意味では、FSRM の“全ブロック＋例外許可”は今でも非常に有効です。
PowerShell で設定を自動化したい場合の考え方
複数サーバーへ同じルールを展開する場合、PowerShell での自動化が便利です。FSRM には専用のコマンドレットが用意されており、概ね次の流れで作れます。
# FSRM のインストール（未導入の場合）
Install-WindowsFeature -Name FS-Resource-Manager -IncludeManagementTools
# モジュール読み込み（環境によっては不要）
Import-Module FileServerResourceManager
# 1) 全ブロック用ファイル グループ（*）
New-FsrmFileGroup -Name "Block-All" -IncludePattern "*"
# 2) 許可用ファイル グループ（*.doc）
New-FsrmFileGroup -Name "Allow-DOC" -IncludePattern "*.doc"
# 3) 親フォルダーへ “全部ブロック” のファイル スクリーン
New-FsrmFileScreen -Path "D:\Shares\ShareRoot" -IncludeGroup "Block-All"
# 4) 対象フォルダーへ “.doc 許可” の例外
New-FsrmFileScreenException -Path "D:\Shares\ShareRoot\DocsOnly" -IncludeGroup "Allow-DOC"コマンドレットやパラメーターは環境差や更新で表示が異なることがあるため、手元のサーバーで次を確認してから組み立てると確実です。
Get-Command -Module FileServerResourceManager
Get-Help New-FsrmFileScreen -Full
Get-Help New-FsrmFileScreenException -FullGUI でまず 1 回作ってから、PowerShell で設定を“再現”する方が事故が少なく、運用もスムーズです。
まとめ：FSRM の基本は「全部禁止」＋「例外許可」で疑似 Allow list を作る
Windows Server 2019 の FSRM（ファイル スクリーン）は「許可だけを通す」専用機能ではありませんが、*（全ファイル）をブロックし、*.doc を例外として許可することで、実質的に「.doc だけ許可」を実現できます。
ただし、Office の一時ファイルや保存プロセスが原因で、運用開始直後に「保存できない」系の問い合わせが出やすい構成でもあります。導入時は、パッシブで状況観測→必要最小限の例外追加→アクティブ化、という段階的な進め方を強くおすすめします。
コメント