無害化はどこまで残すべきか｜専用装置を前提にしない構成と適用範囲の絞り方

自治体のネットワークモデル移行で、ほぼ確実に議論が止まるのが「無害化」です。

三層分離の設計では、インターネット接続系からLGWAN接続系へファイルを持ち込む際、テキスト化・画像化・再構成などの処理で悪性コードを除去する仕組みが置かれてきました。分離を前提とした構造では合理的な対策です。

問題は、ネットワークモデルを見直してクラウドサービスを直接使う構成に変えたとき、この仕組みをそのまま維持すべきかどうかが自明でなくなることです。実際、支援に入った自治体でも「どう実装するか」ではなく「そもそもどこまで必要か」で悩んでいるケースが目立ちます。

なお、Google Workspace の製品機能で無害化要件をどこまで満たせるかという論点は、自治体のGoogle Workspaceで無害化要件をどう満たすかで個別に整理しています。本記事は、その手前にある「無害化そのものの適用範囲をどう決めるか」を扱います。

無害化を維持したときに起きること

クラウド前提の構成に無害化を素直に残すと、次のような副作用が出ます。

つまり、無害化を残すこと自体が、クラウド移行の目的である業務効率化を打ち消す方向に働くという構図です。効果と副作用を並べて評価しないまま「従来どおり」を選ぶと、投資に対する効果が出ません。

専用装置を前提にしない代替構成

ある自治体の案件では、専用装置を導入せず、以下の組み合わせで代替する方針を採りました。

1. ファイアウォールでの経路振り分け

ローカルブレイクアウトの対象を、許可した特定のクラウドサービスに限定します。宛先ドメイン単位で経路を分け、それ以外の通信は従来どおり都道府県セキュリティクラウド経由とします。「どこへ出ていく通信か」で制御するという考え方です。

2. クラウド側のスキャン機能

主要なクラウドサービスは、アップロード時のマルウェアスキャン、リンクの実行時検査、添付ファイルの隔離といった機能を標準または上位エディションで備えています。これを有効化し、検知ログを収集対象に含めます。

3. エンドポイント側での検知と対応

境界での除去に依存せず、端末側で挙動を検知して止める考え方に寄せます。ここがしっかりしていないと代替は成立しません。EDRの導入と、アラートに対応する体制（内製か外部委託か）をセットで設計する必要があります。

4. 同期クライアントを使わせない前提

PC版の同期クライアントを利用しない運用にすることで、ローカルにファイルが降りる経路を絞ります。ブラウザ経由の利用に統一すると、制御点が集約され、設計がかなり単純になります。

この構成が成立する条件

万能ではありません。以下が満たせないなら、無害化の縮小は勧められません。

3点目は特に重要です。技術的に妥当な構成であっても、庁内の規程と整合していなければ導入できません。ポリシー改定のスケジュールを逆算して、プロジェクト計画に組み込んでおくことをお勧めします。改定には庁内の合議や情報セキュリティ委員会の議決が必要になることが多く、数か月単位の期間を見込むべき領域です。

全廃ではなく適用範囲を絞る

現実的な着地点は、無害化をゼロにすることではなく、適用範囲を絞ることです。

たとえば次のような整理が考えられます。

• 外部から受け取るメール添付は従来どおり処理し、クラウドストレージ上での共同編集は対象外とする
• 機密性の高い情報を扱う特定の部署だけ、従来の処理を残す
• 庁外からの持ち込み経路（USB、他システム連携、紙のスキャン）は別枠で扱う

情報資産の重要度に応じて対策の強度を変えるという、本来の考え方に立ち返る形です。一律に適用するから無理が出るのであって、リスクに応じて濃淡をつければ、利便性とのバランスは取れます。

適用範囲を絞る場合は、絞った理由と、絞った範囲で残るリスクをどう受容したかを文書として残してください。ここが残っていないと、後任者が判断の経緯をたどれず、次の更改でまた同じ議論が始まります。

技術選定ではなくポリシー設計の問題

無害化の扱いは、製品を比較して決める問題ではありません。どのリスクをどの手段で受け止め、残ったリスクを誰が受容するのかという、ポリシー設計の問題です。

そのため、進め方も技術検討から入るべきではありません。次の順序が実務的です。

1. 現行の対策基準で、無害化がどう規定されているかを確認する
2. ネットワークモデルの変更で、その規定が前提としていた条件が変わるかを整理する
3. 変わるなら、規定の改定案と代替構成をセットで検討する
4. 改定の手続き（合議・委員会）に必要な期間を、プロジェクト計画に組み込む
5. そのうえで、代替構成を満たす製品・機能を選定する

ネットワークモデルの選定そのものについては、自治体ネットワークの次期モデルはどう選ぶかで判断軸を整理しています。無害化の扱いは、モデル選定と同じ検討の中で決めるべき論点です。

よくある質問

クラウド移行後も無害化は必要ですか？

必要かどうかは自庁の対策基準と、扱う情報資産の重要度によって決まります。ただしクラウド前提の構成に従来型の無害化をそのまま残すと、ファイル形式の破損、同期クライアントの利用不可、コストの二重化といった副作用が出て、移行の目的である業務効率化を打ち消します。効果と副作用を並べて評価してください。

専用の無害化装置を導入せずに済ませることはできますか？

ファイアウォールでの経路振り分け、クラウド側のスキャン機能、EDRによる端末側の検知と対応、同期クライアントの制限を組み合わせることで代替できる場合があります。ただしEDRのアラートに対応する体制がない、利用するクラウドサービスを限定できない、ポリシー改定が通せないという状況では成立しません。

無害化を縮小するとき、セキュリティポリシーの改定は必要ですか？

無害化の実施が情報セキュリティ対策基準に明記されている場合は必要です。実装を先に変えて規程が追いつかない状態にすると、監査で必ず指摘されます。改定には庁内の合議や情報セキュリティ委員会の議決が必要になることが多く、数か月単位の期間を見込んでプロジェクト計画に組み込んでください。

無害化を全廃するのと範囲を絞るのはどちらがよいですか？

現実的な着地点は範囲を絞ることです。外部から受け取るメール添付は従来どおり処理し、クラウドストレージ上での共同編集は対象外とする、機密性の高い情報を扱う部署だけ従来の処理を残すといった形で、情報資産の重要度に応じて強度を変えます。一律に適用するから無理が出ます。

同期クライアントを使わせない運用にする理由は何ですか？

PC版の同期クライアントを有効にすると、無害化やスキャンを経由せずにローカルへファイルが降りる経路が生まれるためです。ブラウザ経由の利用に統一すると制御点が集約され、設計も運用も単純になります。ただし業務上どうしても同期が必要な部署がある場合は、その範囲を限定して別途の対策を設計します。

まとめ

クラウド前提の構成に従来型の無害化をそのまま残すと、ファイル形式の破損、同期クライアントの利用不可、コストの二重化という形で、移行の目的そのものと衝突します。

専用装置を前提にしない代替は、ファイアウォールでの経路振り分け、クラウド側のスキャン、EDRによる端末側の検知と対応、同期クライアントの制限という組み合わせです。ただし成立条件は明確で、EDRのアラートに対応する体制、利用サービスの限定、ポリシー改定の見通しが揃わなければ勧められません。

そして現実的な着地点は、全廃ではなく情報資産の重要度に応じて適用範囲を絞ることです。無害化は技術選定というよりポリシー設計の問題であり、規程の改定手続きに必要な期間まで含めて計画に組み込んでください。