会社PCでゲーム利用を制御するには、古い「ゲーム情報のダウンロード」ポリシーではなく、AppLockerまたは組織のApp Control for Businessで実行可能アプリを管理します。最初は監査モードで実際の実行ファイル、パッケージアプリ、スクリプト、インストーラーを収集し、業務アプリの許可ルールを整えてから強制へ移します。ゲーム名の拒否リストだけでは、名前変更、別フォルダー、ブラウザーゲーム、クラウド配信を防げません。
アプリ制御はゲーム対策だけでなく、業務アプリ停止にも直結します。既定ルールなしで強制するとWindowsや管理ツールまで実行不能になり得るため、必ず検証OUと監査モードから始めます。
制御対象を定義する
禁止対象を「未承認の実行ファイル」「Microsoft Store等のパッケージアプリ」「スクリプト」「インストーラー」「Webゲーム」「USBからの実行」に分けます。AppLockerは実行ファイル、Windows Installer、スクリプト、DLL、パッケージアプリをコレクション別に制御しますが、Webサイトや動画ストリーミングはDNS、Webフィルター、ブラウザーポリシー側で管理します。
人事・法務・情報セキュリティと、適用対象、例外、ログ利用目的、私物利用、休憩時間、異議申立てを決めます。技術的に止められることと、過度な監視をしてよいことは別です。「ゲームらしい名前」を情シス判断だけで禁止せず、承認済みアプリカタログと申請経路を整備します。
AppLockerの前提を確認する
対象Windowsのエディション、管理方式、Application Identityサービス、GPMC/RSAT、イベントログ収集を確認します。MicrosoftはAppLockerを多層防御機能と位置付け、より強固なセキュリティ境界が必要な場合はApp Control for Businessを検討するよう案内しています。ゲーム抑止だけか、マルウェア対策も期待するかで製品選定を分けます。
AppLockerでは特定コレクションに一つでもルールがあると、許可ルールに合わない対象が実行できなくなります。Microsoftの既定ルールはWindowsやProgram Files配下の必要ファイル、管理者などを許可する出発点ですが、ユーザーが書き込める場所や管理者利用を広く許可しすぎないかを評価します。
監査モードのGPOを作る
- 検証端末と一般ユーザーを含む専用グループ・OUを作ります。
- 新規GPOでコンピューターの構成 → Windowsの設定 → セキュリティの設定 → アプリケーション制御ポリシー → AppLockerを開きます。
- 実行ファイル、パッケージアプリ、スクリプト、インストーラーの必要な既定ルールを作成します。DLLルールは負荷と複雑性を評価して別途扱います。
- 各ルールコレクションの適用を最初は「監査のみ」に設定します。
- Application Identityサービスが対象端末で開始され、ログが収集基盤へ送られることを確認します。
監査期間は少なくとも通常業務、月次処理、更新、VPN、リモート支援を含めます。イベントビューアーのApplications and Services Logs配下にあるAppLockerログから、許可されるものと拒否予定のものを分類します。端末一台の一日だけで許可リストを完成としません。
ルール条件を選ぶ
Publisher条件
署名済みアプリは発行元、製品名、ファイル名、バージョン範囲でルールを作れます。正規更新に追随しやすい一方、発行元全製品を許可すると不要ゲームまで含む場合があります。サンプルファイルの署名と証明書チェーンを確認し、製品・ファイル粒度を選びます。
Path条件
Program Filesなど標準ユーザーが書き込めない管理パスの許可に向きます。Downloads、Desktop、Temp、ユーザープロファイル配下を広く許可すると、持ち込んだ実行ファイルも動きます。共有パスを条件にする場合は、利用者がファイルを置き換えられないACLと可用性を確認します。
Hash条件
署名のない固定ファイルに使えますが、ファイル更新ごとにハッシュが変わります。未知のゲームを一つずつ拒否する用途では運用負荷が高く、更新後の業務ツールを止める原因になります。署名取得、パッケージ化、管理配布へ移す計画も持ちます。
ゲームを止める設計
基本は承認済み業務アプリを許可するAllow方式です。明確な禁止ゲームだけDenyにする場合も、DenyはAllowより優先されるため、同じバイナリを業務で使う例外部署がないか確認します。パッケージアプリは発行元ルールでパッケージのインストールと実行を制御できます。Store自体の管理やアプリ取得経路はMDM/Storeポリシーも併用します。
ブラウザーゲームはブラウザー自体を止めず、セキュアWebゲートウェイ、DNSフィルター、Chrome/EdgeのURLポリシーでカテゴリまたは承認URLを管理します。CDN全体やJavaScriptを無差別にブロックすると業務SaaSが壊れます。ブラウザー拡張、WebSocket、VPNアプリ、個人プロキシも管理対象として設計します。
強制前の受入試験
- Windowsサインイン、エクスプローラー、Office、ブラウザー、VPN、EDRが動く
- 情シスの遠隔支援と復旧ツールを最小権限で実行できる
- 業務アプリの更新・修復・アンインストールが承認経路で動く
- 禁止対象はローカル、USB、共有、ダウンロードから実行できない
- ログに利用者、端末、ファイル、ルールが記録される
- 誤検知時の一時例外が期限付きで発行・削除できる
検証ではゲームを本番ネットワークから取得しません。承認されたテストファイルか既知ハッシュで判定し、ライセンス違反やマルウェア持ち込みを避けます。拒否メッセージに申請先を案内し、ヘルプデスクがイベントIDと端末を確認できるようにします。
段階的に強制する
監査ログを修正したら、まずIT部門または小規模部署で一つのルールコレクションだけ強制します。実行ファイルとスクリプト、パッケージアプリを同日に全面強制すると原因特定が難しくなります。業務時間外の保守窓口、緊急解除GPO、現地管理者の復旧手順を用意します。
強制後は拒否件数だけでなく、アプリ起動時間、更新失敗、サインインスクリプト、印刷、Web会議を監視します。大量拒否が出た端末を利用者の回避と決めつけず、業務アプリの補助プロセスや自動更新を調べます。
切り戻しと継続運用
重大な業務停止が起きたら、対象グループを強制GPOから外し、監査モードGPOへ戻します。ローカルでポリシーファイルを削除する手順を一般配布せず、中央管理で復旧します。サービス設定、GPOリンク、ルールXMLのバックアップを同じ変更番号で保管します。
月次で新規アプリ、署名変更、Storeパッケージ、例外期限をレビューします。退職者や廃止部署の例外グループを削除し、ゲーム名の追加競争ではなく承認アプリカタログを維持します。高度な防御要件では、App Control for Businessへの移行と管理インストーラーを評価します。
利用者が管理者の場合
利用者がローカル管理者なら、ソフトウェア導入、サービス、仮想マシン、ポータブルアプリ、ポリシー改変による回避余地が大きくなります。業務上の理由を棚卸しして標準ユーザーへ移し、必要な管理操作はJIT/JEA、管理者承認、専用管理アカウントで提供します。AppLockerだけで管理者端末の完全な防御境界を作れるとは考えません。
開発者や検証担当には、署名済み社内アプリ、管理インストーラー、専用サンドボックス、期限付き例外を用意します。広いフォルダー許可を恒久化すると、そこへゲームや不正ツールを置けます。例外パスのACL、所有者、作成可能な利用者を監査します。
ブラウザー以外の配信経路
ゲームはStore、ランチャー、チャット添付、クラウドストレージ、Git、USB、仮想マシンからも入ります。Webカテゴリだけを塞いで完了とせず、アプリ配布、デバイス制御、EDR、ネットワーク、ライセンス管理のログを統合します。業務で必要な開発ツールやGPU処理まで一律に止めないよう、用途と所有者を識別します。
コメント