>
>
公開日
最終更新日
ホワイトリストとは、安全と判断して事前登録した対象だけを許可し、それ以外を原則として拒否する仕組みです。英語ではwhitelistまたはwhite listと表記されますが、現在はアローリストという中立的な呼称が広がっています。
ホワイトリスト方式は、未許可のプログラムや通信を入口で遮断できる一方、設定漏れや更新遅延によって正規の業務まで止める可能性があります。導入時はブラックリスト方式との違いを理解し、デジタル署名、学習モード、EDRを組み合わせる設計が欠かせません。本記事では、アプリケーション実行制御、IP制限、IPSの除外設定を混同せず、用途ごとの仕組みとリスクを整理します。
ホワイトリスト（アローリスト）とは
ホワイトリストとは、許可条件に一致する対象だけを利用可能にし、条件外の対象をデフォルトで拒否するアクセス制御方式です。
読む目的別の案内
基本理解編：用語の意味、ブラックリストとの違い、メリット・デメリットを知りたい場合は、「ブラックリストとの違いとホワイトリスト方式のメリット」までを読みます。
導入実務編：アプリ制御の設計、例外申請、更新管理、EDRとの役割分担を検討する場合は、「ハッシュ値管理」以降を参照します。
領域別応用編：生成AI、Kubernetes、OT、IoTなどの用途別の考え方を確認する場合は、「適用領域別のクラウド・生成AI・OT活用」を参照します。
本記事のポイント
ホワイトリスト方式は、許可済みのアプリ、ファイル、IPアドレス、ドメイン、通信だけを通します。
ブラックリスト方式との違いは、初期状態が「拒否」か「許可」かにあります。
未許可プログラムの抑止には有効ですが、正規ツールの悪用や許可済みアプリの脆弱性までは単独で防げません。
現在の実務では、ハッシュ値だけでなくデジタル署名、配布経路、ユーザーや端末の状態を組み合わせて判定します。
基本定義と英語表記
whitelistとwhite listはいずれも「許可リスト」を意味します。whitelistedは、IPアドレスやアプリなどが許可リストへ登録され、アクセスや実行を認められた状態です。日本語ではホワイトリストと呼ばれてきましたが、機能を直接表す名称としてアローリストが使われるようになっています。
対象はアプリケーションに限りません。ファイアウォールでは送信元IPアドレスや宛先ポート、メールでは送信元ドメイン、SaaSではログイン元ネットワーク、コンテナ環境ではイメージやPod間通信を許可条件にできます。ただし、制御対象が違えば設定単位と事故の起き方も変わるため、一つの仕組みとして一括管理するのではなく用途別にポリシーを分けます。
アプリケーション許可リストで使う判別属性
NIST SP 800-167「Guide to Application Whitelisting」は、アプリケーション許可リストの考え方を参照するための関連資料の一つです。実装では、ファイル名、保存先、ファイルの内容を示す値、デジタル署名、配布経路など、複数の属性を組み合わせて許可条件を作ります。
次の表は、アプリケーションを識別する代表的な属性と、更新頻度や偽装耐性を踏まえた実務上の使い分けを整理したものです。単一の属性だけに依存せず、端末用途と更新方式に合わせて条件を組み合わせます。
判別属性 | 実務上の強度 | 運用負荷 | 適した使い方 | 主なリスク |
|---|---|---|---|---|
ファイル名 | 低 | 低 | 他条件と組み合わせた補助判定 | 正規ファイルと同じ名前へ容易に偽装されます。 |
ファイルパス | 低～中 | 低 | 書き込み権限を制限した固定端末 | 許可先へ不正ファイルを配置されると突破されます。 |
ファイルサイズ | 中 | 中 | 改変の簡易検知 | 正規アップデートでも値が変わります。 |
暗号ハッシュ値 | 高 | 高 | 変更頻度が低い固定アプリ | 更新のたびに再登録が発生します。 |
デジタル署名・発行元 | 中～高 | 中 | 更新頻度が高い市販アプリ | 信頼範囲が広いと、同じ発行元の不要アプリも通ります。 |
IPSとファイアウォールの許可設定
ファイアウォールのホワイトリストは、登録した送信元IPアドレス、宛先、ポート、プロトコルだけを通す通信ルールです。一方、IPSのホワイトリストは、信頼済みと判断した通信を特定の検知ルールや遮断処理から除外する例外設定として使われることがあります。同じ名称でも目的が異なります。
IPSの除外範囲を送信元ネットワーク全体や全シグネチャに広げると、侵害された許可元からの攻撃まで見逃します。誤検知を回避する場合は、送信元、宛先、対象シグネチャ、プロトコル、時間帯を限定し、除外後もログを保存します。単に「信頼できる社内IPだから許可する」という設計では、端末侵害後の横展開を防げません。
アローリストへの呼称変更
アローリストとホワイトリストに機能上の違いはありません。英国NCSCは用語変更に関する公式ブログで、whitelistとblacklistをallow listとdeny listへ置き換える方針を説明しています。Inclusive Naming Initiativeも、技術用語をより中立的で説明的な表現へ移行する活動を続けています。
既存製品の画面や検索ではホワイトリストという名称が残っているため、社内規程では「アローリスト（旧ホワイトリスト）」と初出時に併記すると混乱を抑えられます。以降はアローリストへ統一すれば、海外ベンダーの仕様書や新しい標準文書とも用語を合わせられます。
ブラックリストとの違いとホワイトリスト方式のメリット
ホワイトリスト方式は未知の対象を未許可として止めやすく、ブラックリスト方式は通常業務を妨げずに既知の脅威を除外しやすい方式です。
デフォルト拒否とデフォルト許可の比較
ブラックリストとホワイトリストの違いは、危険性が未判定の対象をどう扱うかに集約されます。ホワイトリスト方式は未登録の対象を拒否するため、新種のマルウェアでも許可条件に一致しなければ実行を抑止できます。ブラックリスト方式は未登録の対象を通すため、業務への影響を抑えられる反面、脅威情報へ登録される前の攻撃を通す可能性があります。
比較項目 | ホワイトリスト方式 | ブラックリスト方式 |
|---|---|---|
基本方針 | デフォルト拒否 | デフォルト許可 |
登録対象 | 利用を認めるアプリや通信 | 拒否するマルウェアや通信先 |
未知の脅威 | 未許可なら実行前に遮断できます。 | 定義へ追加される前は通過する可能性があります。 |
業務影響 | 設定漏れで正規アプリも止まります。 | 通常業務を止める可能性は比較的低いです。 |
管理負荷 | 変更や更新の追跡に負荷がかかります。 | 脅威情報を製品側で更新しやすい方式です。 |
適用例 | OT、POS、管理者端末、基幹サーバー | メール、Web閲覧、一般端末のマルウェア対策 |
主な限界 | 許可済み機能の悪用と設定ミスです。 | 未知の脅威と検知回避です。 |
未知の脅威に対する予防統制
ホワイトリスト方式の利点は、悪性だと判明した後に止めるのではなく、許可条件を満たさない実行ファイルやスクリプトを先に止められる点です。新しいファイルが安全か危険かを完全に判定する仕組みではなく、「業務上の利用を承認したか」という統制によって攻撃面を狭めます。
そのため、未知の攻撃を100％防ぐ方式ではありません。許可済みアプリの脆弱性、盗まれたコード署名証明書、管理者権限の侵害、PowerShellなどの正規機能を使う攻撃は別の対策領域です。アローリストの効果は、攻撃に使える未承認プログラムを減らす予防統制として評価します。
被害と市場動向から見る運用範囲
KPMGジャパンは「サイバーセキュリティサーベイ2026」で、国内企業におけるサイバーインシデント被害や経営上の課題を扱っています。許可リストだけで被害をなくすことはできませんが、無断ツールや未知の実行ファイルを減らせば、侵入後に利用できる経路を限定できます。
国内のセキュリティ対策市場では、予防だけでなく、侵害後の検知・対応を含む対策への投資が継続しています。市場規模や成長率そのものは個別対策の有効性を直接証明するものではありませんが、アローリストを単独で扱わず、EDRや監視・対応体制と組み合わせる前提が広がっています。
規制とゼロトラストへの対応
PCI Security Standards CouncilのPCI DSS公式案内では、PCI DSSの現行文書や関連資料を参照できます。PCI DSSはあらゆる場面でアプリケーション許可リストを義務付ける規格ではありませんが、カード会員データ環境では必要な通信だけを認めるネットワーク制御や、決済ページで実行するスクリプトの管理が論点になります。自組織の適用範囲と要求事項は、契約先または評価担当者が参照するPCI DSS文書で確認できれば準拠計画へ反映し、対象外であれば自社の決済・個人情報保護方針に沿って制御範囲を定めます。
NIST SP 800-207が説明するゼロトラストは、社内ネットワークにいるという理由だけでアクセスを信頼せず、ID、端末状態、対象資源、継続的な評価に基づいて可否を決める考え方です。静的なIPリストだけをゼロトラストと呼ぶのは正確ではありません。NISCの政府機関等のサイバーセキュリティ対策のための統一基準群も踏まえ、端末の健全性や認証状態を許可条件へ加えると、固定リストより細かな制御が可能になります。
経済産業省はサプライチェーンセキュリティ評価制度に関する公式発表で、企業間取引を含むセキュリティ対策の可視化に向けた方針を示しています。取引先接続を許可する場合も、会社単位で無期限に許可するのではなく、接続元、対象システム、利用時間、担当者を条件化すれば、委託先の侵害が自社へ波及する範囲を狭められます。
▲ ホワイトリスト方式（デフォルト拒否）とブラックリスト方式（デフォルト許可）におけるアクセス判定の比較
「ハッシュ値管理」からデジタル署名・動的制御への進化
更新頻度が高い環境では、ファイルごとのハッシュ値登録から、署名、配布経路、端末状態を組み合わせた動的な許可判定へ移行します。
ハッシュ値管理の限界
SHA-256などの暗号ハッシュ値は、ファイルの内容が少しでも変わると別の値になります。この特性は改ざん検知に有効ですが、ブラウザ、会議ツール、セキュリティ製品のように更新が多いアプリでは、正規アップデートのたびに許可リストを変更しなければなりません。
更新から登録までの間に業務アプリが起動できず、利用部門から例外申請が殺到する状態は「ハッシュ地獄」と呼ばれます。ハッシュ値が不適切なのではなく、変更頻度が高い対象へ一律適用することが問題です。更新が少ない工場端末の固定プログラムにはハッシュ値を使い、頻繁に変わるアプリには別の条件を使い分けます。
コード署名とパブリッシャー制御
デジタル署名による制御では、ファイル単位ではなく、署名した開発元、製品名、ファイル名、バージョン範囲などを条件にできます。正規の署名を保持した更新版なら、新しいハッシュ値を手作業で登録せずに許可できます。
ただし、MicrosoftやAdobeなどの発行元を無条件で一括許可すると、同じ署名元が提供する業務不要のツールまで実行できます。署名の有効性だけでなく、製品名、最小バージョン、インストール先、配布元を絞ります。証明書が失効した場合や署名時刻を検証できない場合に、遮断するか隔離して申請へ回すかも事前に決めます。
信頼された配布経路と動的アローリスト
動的アローリストは、固定された一覧だけでなく、信頼されたインストーラー、端末管理ツール、クラウド評価情報、利用者の権限などを使って許可状態を更新する方式です。企業が管理する配布サーバーから導入され、正しい署名を持ち、脆弱な旧版ではないという条件を満たしたアプリだけを自動許可できます。
AIや機械学習を利用する製品もありますが、AIが安全性を保証するわけではありません。自動判定を採用する場合は、判定根拠・誤判定時の解除方法・管理者の上書き履歴をログとして取得できる構成にします。ログを取得できない製品では、自動許可ではなく保留判定に設定します。
コンテキストを使った許可判定
同じアプリでも、利用者、端末、場所、時間によってリスクは変わります。たとえば管理対象PCから勤務時間内に起動する署名済み会計ソフトは許可し、個人端末や国外IPからの実行は追加認証または拒否にできます。これにより、リストへ登録された対象を永続的に信頼する運用から脱却できます。
動的制御を採用する場合も、最終的な許可条件は人が説明できる形で残します。「AIが安全と判定したため許可」だけでは監査で再現できません。署名、配布経路、バージョン、利用者、端末状態のうち、どの条件が一致したかをログへ保存します。
ホワイトリスト方式のデメリットと実務課題
ホワイトリスト方式の最大の課題は、アプリや通信先の変更へ追従できないと、セキュリティ事故より先に業務停止を起こす点です。
初期棚卸しの工数
導入前には、端末上で動く実行ファイル、スクリプト、ブラウザ拡張、ドライバー、業務マクロ、更新プログラムを洗い出します。部署ごとに利用ツールが違う企業では、標準PCだけを調査しても、開発部門のコンパイラーや経理部門の銀行連携ソフトを見落とします。
OktaはBusinesses at Work 2025で、企業における業務アプリの利用状況を紹介しています。実際の許可対象にはローカルアプリや拡張機能も加わるため、SaaSの契約一覧だけでは棚卸しが完了しません。
自動更新による業務停止
ブラウザや会議ツールが自動更新された直後にハッシュ値が変わると、翌朝から全社員が起動できない事態が起こります。更新を全面的に止めると脆弱性対応が遅れるため、セキュリティのための許可リストが別のリスクを生みます。
更新頻度が週次以上のアプリは署名と管理配布元を条件にし、固定バージョンで稼働するOTアプリはハッシュ値を使うと役割を分けられます。テスト端末で更新後の動作と署名を先に確認できるなら段階配布へ進み、テスト環境を用意できないなら少数端末への先行配布と即時ロールバックを運用へ組み込みます。
例外申請の滞留
承認に数日かかると、利用部門は個人向けクラウド、Web版ツール、私物端末などの回避策へ流れます。制御を厳しくした結果、管理外の経路が増えるのは典型的な失敗です。申請には利用目的、データの種類、発行元、署名、利用期間、代替手段を記載し、承認者が同じ基準で判断できるようにします。
標準的な業務アプリは24時間以内、未知の開発ツールや生成AIは48時間以内を社内の処理目標に設定する方法があります。この時間は公的基準や製品仕様ではなく、無断利用へ流れる前に一次回答を返すための運用目安です。判定が終わらない場合も、放置せず「一時許可」「隔離環境で検証」「代替製品を提示」のいずれかを返します。
許可済み対象への過信
デジタル署名が正しいことは、アプリに脆弱性がないことを意味しません。許可済みのブラウザや文書閲覧ソフトが脆弱であれば、細工されたファイルを通じて攻撃される可能性があります。盗まれたコード署名証明書が不正プログラムに使われる事例もあります。
署名ベースで許可するなら、脆弱な旧バージョンを拒否する条件、証明書失効情報の取得、アプリの子プロセス制御を加えます。失効情報を取得できない閉域端末では、署名だけに依存せず、ハッシュ値と配布媒体の管理を併用します。
導入優先度が低い環境
業務ごとに異なる開発ツールを日々ビルドする端末や、利用アプリが短期間で頻繁に入れ替わる検証環境では、厳格な実行許可リストが開発を止める可能性があります。この場合は全端末へ一律適用せず、管理者権限の分離、サンドボックス、EDR、ネットワーク分離を先に整えます。
反対に、用途が固定されたPOS、受付端末、製造装置、踏み台サーバーは許可対象が安定しているため、アローリストの効果を得やすい領域です。導入可否は従業員数だけでなく、アプリの変更頻度、停止時の損失、管理者権限の有無で決めます。
失敗を防ぐ導入・運用設計と多層防御
初日から全遮断せず、学習、限定適用、例外処理、EDR連携の順で進めると、業務停止と検知漏れの両方を抑えられます。
初日からの全遮断という失敗
やってはいけないことは、標準イメージだけを基に許可リストを作り、全端末を同時にブロックモードへ切り替える運用です。月末だけ使う会計処理、四半期ごとの報告ツール、年次更新の電子証明書など、短い観測期間では見つからない処理が止まります。
最初の30～60日を学習またはシミュレーション期間にする目安は、日次・週次・月次の処理を少なくとも一巡させるためです。年次業務までは捕捉できないため、業務カレンダーと過去のソフトウェア台帳を照合します。月次処理がない固定端末なら期間を短縮でき、複数部門で月末処理があるなら60日側へ延ばします。
段階導入のタイムライン
段階導入では、ログを集めるだけでなく、各期間の終了条件を決めます。遮断件数が減らない状態で次へ進むと、問い合わせ件数だけが増えます。
時期 | 実施内容 | 終了条件 | 成果物 |
|---|---|---|---|
導入前 | アプリ、スクリプト、通信先、管理者権限を棚卸しします。 | 重要業務の責任者と停止時の連絡先が特定済みです。 | アプリ台帳、業務カレンダー、緊急連絡表 |
1～2カ月目 | 学習モードで許可候補と未承認対象を収集します。 | 日次・週次・月次業務を観測し、未分類ログを処理済みです。 | 許可候補、拒否候補、例外候補 |
限定適用 | 用途が固定された部門または端末群で遮断を開始します。 | 重大な業務停止がなく、緊急解除を記録できます。 | 障害記録、修正版ポリシー |
展開後 | 部門単位で対象を広げ、月次レビューを実施します。 | 例外の期限切れと不要ルールを定期削除できます。 | 監査ログ、例外台帳、改善一覧 |
PowerShellと正規ツールの悪用対策
Living Off The Land攻撃は、PowerShell、cmd.exe、WMIなど、OSに標準搭載された正規ツールを悪用します。これらを業務上許可している場合、単純なアローリストはプロセスの存在を正当と判定するため、コマンドの目的や実行後の不審な通信までは見抜けません。
PowerShellを全面許可する代わりに、利用者グループ、署名済みスクリプト、実行元フォルダー、子プロセス、ネットワーク接続先を制限します。管理部門でPowerShellを使わないなら拒否し、開発・運用部門では詳細ログとEDR監視を付けて許可すると、部門別に攻撃面を調整できます。
アローリストとEDR・MDRの役割分担
アローリストは未許可プログラムを実行前に止める予防統制です。EDRは、許可済みプロセスが認証情報へアクセスした、通常と異なる子プロセスを起動した、外部へ不審な通信を始めたといった挙動を記録・検知します。MDRは、その検知を継続監視し、調査や封じ込めを支援する運用サービスです。
対策 | 主な役割 | 得意な対象 | 単体で残るリスク |
|---|---|---|---|
アローリスト | 実行前の許可判定 | 無断ツール、未知の実行ファイル | 許可済み機能の悪用、設定ミス |
EDR | 実行後の挙動監視と調査 | PowerShell悪用、横展開、不審な子プロセス | 検知後に対応が遅れるリスク |
MDR | 継続監視と初動支援 | 夜間・休日の検知、侵害範囲の調査 | 端末側の予防設定不備 |
EDRへの投資が増えていることは、アローリストが不要になったことを意味しません。入口で未許可ファイルを減らし、実行を許可したプロセスをEDRで監視する構成なら、両者の機能重複を抑えながら防御範囲を広げられます。
緊急解除と監査証跡
業務停止時の緊急解除は、管理者がルールを消すのではなく、対象端末、対象アプリ、有効期限、承認者を記録した一時許可として扱います。解除後はEDR監視を強化し、期限が来たら自動的に元の状態へ戻します。
例外申請では、申請者と承認者を分離し、申請理由、署名情報、ハッシュ値、利用期間、対象データを保存します。監査ログをAPIで取得できるなら定期収集へ進み、APIがない場合は月次のCSV出力と改ざん防止ストレージへの保管に切り替えます。
▲ 業務停止を防ぐためのホワイトリスト方式の4段階導入手順
適用領域別のクラウド・生成AI・OT活用
アローリストは、アプリの実行制御だけでなく、生成AIの接続先、コンテナイメージ、工場端末、IoT通信を必要最小限に絞るために使えます。ここからは用途別の応用編として、基本的な実行制御とは異なる統制対象を扱います。
生成AIとシャドーAIの接続制御
シャドーAIとは、企業が契約・承認していない生成AIを従業員が業務へ使い、顧客情報、ソースコード、会議記録などを入力する状態です。Webサイトの利用規約を周知するだけでは、ブラウザ拡張、デスクトップアプリ、API連携からの送信を把握できません。
許可済みのAIサービス、APIエンドポイント、ブラウザ拡張だけを通し、未承認の接続先をSecure Web GatewayやCASB、DNSフィルタリングで遮断します。全面禁止では現場が個人端末へ移るため、「許可済み」「申請後に利用可能」「禁止」の3区分を作り、入力できるデータの機密区分も併記します。
接続先アローリストだけでは、許可済みAIへ機密情報を入力する行為を防げません。入力内容の検査、DLP、監査ログ、法人契約におけるデータ利用条件を組み合わせます。監査ログを取得できる契約なら部門限定で利用し、ログを取得できない場合は公開情報だけを扱う用途へ限定します。
LLMのツール・関数制御
生成AIを社内システムと接続する場合は、AIが呼び出せるAPIや関数をアローリスト化します。たとえば在庫照会は許可しても、支払い実行やユーザー削除は人の追加承認なしでは呼び出せないようにします。
関数名だけでなく、引数の型、金額上限、対象システム、実行者の権限を検証します。プロンプトに「危険な操作をしない」と書くだけではアクセス制御になりません。AIの出力を信用せず、APIゲートウェイや実行側アプリケーションで許可可否を判定します。
Kubernetesとコンテナの許可制御
コンテナ環境では、承認したレジストリに保存され、署名と脆弱性検査を通過したイメージだけをデプロイ対象にします。タグは同じ名前のまま中身を差し替えられるため、本番環境ではイメージのダイジェストや署名を使って同一性を確認します。
KubernetesのNetworkPolicyでは、最初に通信を原則拒否し、必要なPod間通信や外部接続だけを許可できます。Kubernetes公式のNetwork Policies解説が示す通り、実際に制御が有効になるかは利用するネットワークプラグインに依存します。NetworkPolicyを実装できるプラグインならデフォルト拒否へ進み、未対応ならクラウド側のセキュリティグループやサービスメッシュで同等の経路を制限します。
イメージの許可と通信の許可は別の統制です。署名済みコンテナであっても、不要な外部通信を認めれば情報を送信できます。イメージ署名、Admission Policy、実行時権限、NetworkPolicyを分離して監査します。
OT・ICSとレガシーOSの保護
工場の制御端末、医療機器、POSなどは、停止時間を確保できず、最新OSへ更新できない場合があります。パターンファイルの更新やフルスキャンが難しい固定用途端末では、実行可能なプログラムが限定されているため、アローリストと相性があります。
Trellix Embedded Controlは、組み込み機器や固定用途システムで未許可アプリケーションの実行を制御する製品です。公式製品ページで対応OSや導入要件を確認できます。
ただし、古いOSをアローリストで固定しても、許可済みサービスの脆弱性は残ります。ネットワーク分離、USB制御、保守用アカウントの時間制限、接続先の限定を併用します。脆弱性修正ができない場合は「安全になった」と判断せず、侵害されても生産ネットワーク全体へ広がらない構成にします。
IoTと固定通信先の制御
センサーやカメラなどのIoT機器は、通常時に接続するクラウドや管理サーバーが限定されています。宛先IPだけではクラウド側の変更へ追従しにくいため、DNS名、証明書、プロトコル、ポートを組み合わせて許可します。
ベンダーが通信先一覧と変更通知を提供するなら自動反映へ進み、一覧を提供しない場合は監視期間中の実通信を記録し、未知の宛先を遮断または隔離します。学習した通信を無条件で許可すると、観測期間中に存在した不審通信まで登録されるため、業務目的との照合を挟みます。
自社に合う導入判断と運用チェックリスト
導入範囲は従業員数だけで決めず、端末用途、アプリ更新頻度、停止時の損失、例外処理能力を基準に絞り込みます。
企業規模別の運用設計例
次の区分は公的規格が定めた基準ではなく、管理対象数の増加に伴って手動運用が破綻しやすくなる点を踏まえた設計例です。従業員50名未満でも工場や決済環境があれば自動化が必要であり、300名を超えても用途固定端末だけなら対象を限定できます。
企業規模の目安 | 優先する管理範囲 | 運用方法 | 避ける運用 |
|---|---|---|---|
50名未満 | 管理者PC、会計端末、VPN接続元、バックアップサーバー | 対象を重要端末へ限定し、月次で台帳を更新します。 | 少人数の担当者が全端末のハッシュ値を手作業で管理する運用 |
50～300名 | 基幹システム、SaaS管理画面、開発端末、部門別アプリ | 申請ワークフロー、署名許可、学習モードを組み合わせます。 | 全部門へ同一ルールを一斉配布する運用 |
300名超 | 全社端末、サーバー、特権端末、OT、クラウド環境 | 端末管理との自動同期、EDR連携、APIによる監査ログ収集を使います。 | 担当者個人の判断と表計算ソフトだけに依存する運用 |
制御対象ごとの選択基準
制御したい対象 | 主な選択肢 | 導入判断 |
|---|---|---|
Windowsアプリ | OS標準のアプリ制御、MDM、専用製品 | 署名、パス、ハッシュ値、子プロセスをどこまで指定できるかで選びます。 |
SaaS管理画面 | IP制限、IDプロバイダー、条件付きアクセス | 固定IPを維持できるならIP制限を使い、テレワーク中心なら端末状態と多要素認証を優先します。 |
Web・生成AI | SWG、CASB、DNSフィルタリング | ブラウザ以外のAPIや拡張機能も記録できる方式を選びます。 |
コンテナ | 署名検証、Admission Policy、NetworkPolicy | デプロイ前と実行時通信を別々に制御します。 |
OT・固定端末 | 専用アプリ制御、ネットワーク分離、USB制御 | 更新できない端末ほど、停止時の復旧手順を先に作ります。 |
導入・運用判断チェックリスト
次の項目へ回答すると、先に整えるべき統制を判断できます。
保護対象の端末、サーバー、SaaS、通信先を一覧化できていますか。
月次、四半期、年次だけ利用するアプリを業務カレンダーと照合しましたか。
アプリ更新前に検証できる先行端末またはテスト環境がありますか。
ハッシュ値、署名、発行元、バージョン、配布経路を条件として取得できますか。
例外申請の承認者、処理期限、有効期限を定めていますか。
緊急解除後に自動復旧し、誰が解除したかを記録できますか。
EDRとアローリストのログを端末IDと時刻で突合できますか。
PowerShellやスクリプトを利用する部門を特定していますか。
許可済み生成AIへ入力できるデータ区分を定めていますか。
OT端末が侵害された場合のネットワーク分離範囲を把握していますか。
アプリ台帳がなく更新前検証もできない場合は、全社遮断より棚卸しとログ収集を先に実施します。対象が固定され、復旧手順と責任者を定められる場合は、停止時の影響が大きい端末から限定適用へ進みます。
費用と管理体制の評価
導入費用はライセンス料だけでは決まりません。初期棚卸し、ポリシー設計、例外申請、更新テスト、監査ログ保管、障害対応にかかる人件費を含めます。製品料金が非公開なら要問合せとして扱い、端末単価を推測して投資判断へ使いません。
既存EDRにアプリ制御機能があるなら、追加製品を導入する前に、署名単位の許可、学習モード、例外期限、オフライン端末対応を検証します。必要な条件を満たせるなら既存機能で限定導入し、満たせない条件が業務停止や監査へ影響する場合だけ専用製品を比較します。
▲ 端末用途や更新頻度に応じた最適な制御方式の判断フロー
国内企業におけるホワイトリストの導入事例
国内事例では、変更の少ないOTやPOS、接続機器と通信が限定された製造環境でアローリストの特性が生かされています。
公開事例の確認範囲
以下は企業または提供元が公開した事例に基づく記述に限定しています。導入時期、対象端末数、障害削減率などを公式資料が公表していない事例では「非公開」と記載し、推測値を補っていません。また、AppGuardは一般的なハッシュ型アプリケーション許可リストと同一ではなく、信頼領域やアプリの動作をポリシーで制御するOSプロテクト型製品として区別しています。
企業・組織 | 業種・規模 | 導入製品・方式 | 導入時期 | 課題→施策→成果 |
|---|---|---|---|---|
富士通株式会社 | IT・流通向けPOSシステム | Trellix Embedded Control | 公式公開事例では詳細非公開 | 次世代POS「TeamStore/DX」で、決済性能を維持しながら未許可プログラムを抑止する必要がありました。実行許可リスト型の制御を組み込み、POSの処理負荷を抑えながら安定稼働を支える構成を採用しています。 |
株式会社市進ホールディングス | 教育サービス・公開事例時点で全国約200拠点 | InterSafe GatewayConnection | 2017～2018年頃の公開事例 | 拠点ごとの許可サイト登録を手作業で行い、反映遅延と運用負荷が発生していました。クラウドで一元管理する方式へ移行し、ALSIの公式導入事例では、ホワイトリスト管理にかかる手間を大幅に削減したと紹介しています。古い事例であり、現在の拠点数や契約条件を示すものではありません。 |
OT端末保護を検討する際の視点
停止しにくいOT端末では、一般オフィスPCと同じスキャン中心の対策をそのまま当てはめられない場合があります。製鉄所や工場の制御環境では端末停止が操業へ影響するため、通常動作を把握し、そこから外れる処理を制御する考え方が適合します。
製品を比較する際は、ハッシュ型許可リスト、OS保護ポリシー、アプリ隔離のどの方式を使うのかを分けて評価します。対象端末のOS、オフライン運用の有無、更新頻度、緊急時の復旧手順を製品仕様書と自社の端末台帳で照合できれば限定検証へ進み、照合できなければ通信分離やUSB制御などの先行対策を優先します。
富士通POSの実行制御
POSは実行するアプリが限定され、利用者が自由にソフトを追加する必要も少ないため、アローリストを適用しやすい端末です。富士通の事例では、決済処理の応答性能を維持しつつ、未許可コードの実行を抑止する目的でEmbedded Controlを採用しています。
ただし、公式公開情報では対象端末数、導入年、処理時間の改善率は確認できません。確認できる成果は、低負荷な実行制御をPOS製品へ組み込み、安定稼働とセキュリティの両立を図った点までです。
端末・接続機器・通信を分けた制御
製造環境やIoT環境では、アプリケーションだけでなく、接続機器と通信プロトコルも許可対象として整理します。正規アプリが動いていても、不明なUSB機器や想定外の通信を許せば攻撃経路が残るため、端末、機器、ネットワークを別々に制御します。
この方式を自社へ当てはめる場合は、アプリ台帳、接続機器台帳、通信フロー図を分けて作ります。3種類を一つの表へ詰め込むより、変更責任者と更新頻度を個別に設定した方が、設定漏れの原因を追跡できます。
よくある質問
アローリストの導入時に迷いやすい、EDRとの違い、署名許可のリスク、例外申請の監査方法を簡潔に整理します。
Q：アローリストとホワイトリストに違いはありますか？
A：機能上の違いはありません。アローリストは、ホワイトリストを中立的で機能が分かりやすい名称へ置き換えた呼称です。
Q：ホワイトリストとEDRはどちらを選ぶべきですか？
A：どちらか一方ではなく、役割で分けます。未許可プログラムを実行前に止める場合はアローリスト、許可済みプロセスの不審な挙動を検知・調査する場合はEDRを使います。
Q：デジタル署名があれば安全ですか？
A：署名は発行元と改ざんの有無を確認する材料であり、脆弱性や悪意の不存在を保証しません。発行元だけで一括許可せず、製品名、バージョン、配布経路、証明書の失効状態を条件へ加えます。
Q：IPSのホワイトリストは何を許可しますか？
A：IPSでは、特定の信頼済み通信を検知や遮断の対象から除外する例外設定を指す場合があります。ファイアウォールの通信許可ルールとは異なるため、送信元、宛先、シグネチャ、時間帯を限定して設定します。
Q：例外申請はどのように監査しますか？
A：申請者、承認者、対象ファイル、署名、ハッシュ値、理由、有効期限、解除履歴を保存します。期限切れの例外を月次で削除し、緊急解除は通常申請と分けて事後承認まで記録します。
Q：小規模企業でもホワイトリスト方式は必要ですか？
A：従業員数ではなく、停止時の損失と端末用途で判断します。会計端末、管理者PC、バックアップサーバーなど対象を限定できるなら、小規模企業でも部分導入の効果を得られます。
Q：ホワイトリスト方式だけでゼロトラストになりますか？
A：静的な許可リストだけではゼロトラストになりません。ID、端末の健全性、アクセス先、時間、継続的なリスク評価を組み合わせ、許可後も状態を検証します。
まとめ
止めないアローリスト運用への第一歩
ホワイトリスト方式は、未許可のアプリや通信を入口で減らせる一方、設定漏れや更新遅延によって正規業務を止める可能性があります。完全防御策として扱わず、デジタル署名、配布経路、EDR、例外申請を組み合わせる設計が現実的です。
明日からの最初の一歩は、重要端末で動くアプリ、通信先IP、SaaS、生成AIを一覧化することです。その後、30～60日の学習期間で未分類ログを減らし、用途が固定された端末から限定的に遮断を始めます。許可条件と解除履歴を監査できる状態を作れば、防御力と業務継続を両立しやすくなります。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
