コトラ（広報チーム） 
ゼロトラスト導入を急ぐ前に押さえる基本
ゼロトラストが必要になる背景
ゼロトラストとは、社内ネットワークや社用端末だからといって無条件には信頼せず、利用者、端末、接続状況などを確認したうえで、必要なアクセスだけを許可する考え方です。
クラウドサービスの利用、テレワーク、外出先での業務、委託先との情報共有が広がったことで、「社内にいれば安全、社外は危険」という従来の前提は成り立ちにくくなっています。業務データが社外のクラウドサービスに保存され、社員が自宅や出張先からアクセスする環境では、ネットワークの場所だけで安全性を判断できません。
また、フィッシングによる認証情報の窃取、ランサムウェア、不正な端末利用などのリスクも高まっています。警察庁が公表しているランサムウェア被害の分析では、侵入経路が判明した事案のうち、VPN機器を経由したものが多くを占めています。ゼロトラストは、こうした侵入の可能性を前提に、被害の拡大を抑えるための取り組みです。
境界型の対策だけでは守りにくい理由
従来の境界型対策では、ファイアウォールやVPNで社内ネットワークと社外ネットワークの境目を守ります。しかし、いったんVPN経由で接続すると、利用者が社内ネットワークの広い範囲に接続できる場合があります。認証情報が盗まれたときや、端末がマルウェアに感染したときには、攻撃者が社内で複数のシステムへ移動するおそれがあります。
ゼロトラストでは、ネットワークに接続したこと自体を信頼の根拠にしません。利用者が誰か、端末が管理下にあるか、OSやセキュリティ対策が最新か、どのシステムに接続しようとしているかを確認し、必要な範囲に絞ってアクセスを許可します。
ただし、ゼロトラストは既存のネットワーク対策やVPNをただちに廃止することではありません。既存環境を活用しつつ、認証、端末管理、権限管理、通信制御、監視を段階的に強化する取り組みです。
最初の90日で目指す到達点
最初の90日で、すべての仕組みを置き換える必要はありません。むしろ、急いで広範囲に導入すると、業務への影響や問い合わせ対応が増え、現場の反発につながります。
90日間で目指すべき到達点は、守る対象と優先順位を明確にし、小規模な範囲で安全性と使いやすさを検証したうえで、本導入の稟議につなげられる状態を作ることです。
具体的には、利用中のシステム、アカウント、端末、VPN利用状況を把握し、優先度の高い利用者や業務に多要素認証と端末確認を試験導入します。その結果をもとに、費用、運用体制、段階的な展開計画を経営層へ説明できるようにします。
製品選びから始めない重要性
ゼロトラストの検討で起こりやすい失敗は、製品の比較から始めることです。高機能な製品を導入しても、誰にどの権限を与えるのか、私物端末をどこまで認めるのか、例外を誰が承認するのかが決まっていなければ、安全性は高まりません。
先に整理すべきなのは、守るべき情報、止められない業務、利用者の区分、端末の利用ルール、管理者権限、障害時の対応です。これらが決まると、必要な機能や導入範囲が明確になり、過剰な投資や機能の重複を避けやすくなります。
特に兼任の情シス担当者は、日常の問い合わせ対応と並行して導入を進める必要があります。最初から全体最適を目指すのではなく、現状把握と優先順位付けに時間を使うことが、結果的に導入期間の短縮につながります。
導入初日に整理する現状と優先課題
利用中の業務システムとクラウドサービスの棚卸し
最初に、社内で利用している業務システムとクラウドサービスを一覧化します。会計、人事、営業管理、ファイル共有、メール、チャット、勤怠、オンライン会議、顧客管理など、部門ごとに利用しているサービスを確認します。
棚卸しでは、サービス名だけでなく、利用部門、利用者数、管理者、保存している情報、外部からのアクセス有無、認証方法を記録します。部門が独自に契約しているサービスも確認対象です。情シスが把握していないサービスは、情報漏えいや退職者アカウントの残存につながるためです。
特に、個人情報、取引先情報、財務情報、設計資料、契約書などを扱うサービスは優先して把握します。重要な情報を扱うにもかかわらず、パスワードだけでログインできる状態であれば、初期対策の候補になります。
利用者アカウントと管理者権限の確認
次に、社員、役員、派遣社員、業務委託先などのアカウントを確認します。誰がどのシステムを使っているか、退職者や契約終了者のアカウントが残っていないかを確認します。
特に注意が必要なのは、管理者権限を持つアカウントです。管理者権限が侵害されると、利用者の追加、設定変更、データの持ち出しなどが可能になり、被害が大きくなります。通常業務用のアカウントと管理作業用のアカウントを分けているか、管理者権限が必要以上に付与されていないかを確認します。
確認時には、次の点を整理します。
- 利用者の所属、雇用区分、利用システム
- 管理者権限を持つ利用者と権限の利用目的
- 退職、異動、契約終了時のアカウント停止手順
- 共有アカウントの有無と利用理由
- 多要素認証が有効になっているアカウントの範囲
共有アカウントは、誰が操作したかを追跡しにくく、退職時の停止漏れも起こりやすいため、可能な限り個人アカウントへ移行します。
会社支給端末と私物端末の利用状況の把握
業務に利用する端末を、会社支給端末と私物端末に分けて把握します。パソコンだけでなく、スマートフォン、タブレットも対象です。端末ごとに、所有者、利用者、OSの種類、更新状況、暗号化の有無、セキュリティソフトの導入状況を確認します。
私物端末の利用を完全に禁止できない場合もあります。その場合は、私物端末から利用できるシステムやデータを限定する必要があります。たとえば、重要なファイルのダウンロードを制限し、閲覧だけにするなど、業務への影響と情報保護のバランスを取ります。
端末が管理されていない状態では、OSの更新漏れや端末紛失時の情報漏えいに対応しにくくなります。ゼロトラストでは、端末が安全な状態にあるかを確認し、基準を満たさない端末からのアクセスを制限する考え方が重要です。
VPNと社内ネットワークの利用実態の確認
VPNを利用している場合は、利用者、接続先、接続時間帯、接続目的を確認します。VPNが必要な業務と、インターネット経由で直接利用できるクラウドサービスを分けることで、移行対象を整理できます。
また、VPN接続後にどのシステムへアクセスできるかを確認します。必要以上に広いネットワークへ接続できる設定になっている場合は、優先的に見直す必要があります。利用者が必要とする業務システムだけにアクセスできる状態を目指します。
VPN機器の更新状況、保守期限、多要素認証の有無、ログの確認体制も確認します。VPNをすぐに停止するのではなく、リスクを下げながら、安全な接続方式への段階的な移行計画を立てます。
止められない業務と守るべき情報の優先順位付け
すべてのシステムを同じ順序で対策する必要はありません。業務停止の影響が大きいもの、情報漏えい時の影響が大きいものから優先します。
優先順位を決める際は、各部門へ次のような確認を行います。
- 停止すると当日中に業務が止まるシステムは何か
- 漏えいすると契約、信用、法令対応に影響する情報は何か
- 外部の利用者や委託先がアクセスするシステムは何か
- 管理者権限を持つ利用者が多いシステムは何か
- 代替手段がなく、復旧に時間がかかる業務は何か
優先度が高い対象としては、管理者アカウント、経理や人事のシステム、顧客情報を扱うサービス、外部公開されているシステムなどが考えられます。最初の導入対象は、重要性が高く、対象人数や業務範囲を絞りやすいものを選ぶと進めやすくなります。
最初の30日で決める導入方針と対象範囲
守る対象を利用者・端末・通信・データに分けて定める
ゼロトラストは、単にログイン時の認証を強くするだけでは実現できません。対象を利用者、端末、通信、データに分け、それぞれに必要な対策を決めます。
利用者では、本人確認、権限の最小化、管理者権限の分離を検討します。端末では、OS更新、暗号化、セキュリティ対策、紛失時の対応を定めます。通信では、業務システムへの接続経路、VPNの利用範囲、外部からの接続条件を整理します。データでは、重要情報の保管場所、共有範囲、ダウンロードや外部送信の扱いを決めます。
この4つを分けて考えると、対策漏れを防ぎやすくなります。たとえば、多要素認証を導入しても、管理されていない端末から重要データを保存できる状態であれば、端末とデータの対策が不足していると判断できます。
最初に対策する利用者と業務を選ぶ
最初の導入対象は、全社員ではなく、影響を管理しやすい小規模な範囲に絞ります。対象候補としては、管理者権限を持つ利用者、機密情報を扱う部門、外部からのアクセスが多い利用者、新規入社者などが考えられます。
ただし、対象部門を選ぶ際は、業務負荷だけで判断しないことが重要です。重要情報を扱う部門であっても、繁忙期に導入すると問い合わせが集中し、通常業務に支障が出る場合があります。部門責任者と相談し、検証に協力を得られる時期と範囲を決めます。
最初の対象では、利用者数、対象システム数、例外の数を抑えます。検証の結果を踏まえて、次の対象へ展開する順番を決めることが重要です。
多要素認証を導入する対象と例外を決める
多要素認証は、パスワードに加えて、認証アプリ、端末通知、生体認証などを用いて本人確認を行う方法です。パスワードが漏えいした場合でも、不正ログインのリスクを下げられます。
最初に適用すべき対象は、管理者アカウント、メール、ファイル共有、VPN、顧客情報を扱うシステムです。特にメールアカウントが侵害されると、なりすましメールの送信やパスワード再設定の悪用につながるため、優先度が高い対象です。
一方で、例外が必要になる場合もあります。業務システムの仕様上、多要素認証に対応していない場合や、緊急時に利用する共用端末がある場合などです。例外を認める場合は、対象、理由、承認者、有効期限、代替対策を必ず記録します。例外を恒久化せず、定期的に見直すことが必要です。
端末管理と端末の安全確認の基準を決める
端末の安全性を判断するため、業務システムへ接続できる端末の最低基準を定めます。最初から厳しい基準を設定すると現場が混乱するため、重要度に応じて段階的に適用します。
最低基準としては、OSと主要ソフトウェアが更新されていること、端末にログイン用のパスワードが設定されていること、保存領域が暗号化されていること、セキュリティ対策ソフトが有効であることなどが考えられます。
会社支給端末では、設定を一元管理できる状態を目指します。私物端末については、業務データを端末内に保存しない、特定のクラウドサービスへのアクセスだけに限定するなど、会社支給端末とは異なるルールを設けます。
VPNからの移行方針と併用期間を決める
VPNを安全な接続方式へ移行する場合は、対象業務を分けて段階的に進めます。すべてのVPN接続を一度に切り替えると、利用していないと思われていたシステムが実際には使われていたことが判明し、業務停止につながるおそれがあります。
移行方針では、まずクラウドサービスへのアクセスと、社内に残る業務システムへのアクセスを分けます。次に、社内システムのうち、利用者や接続先を限定しやすいものから安全な接続方式へ移行します。
VPNと新しい接続方式の併用期間を設け、接続状況、問い合わせ件数、業務影響を確認します。VPNを停止する条件として、対象システムの移行完了、利用者テスト完了、障害対応手順の整備、管理者承認などを事前に定めます。
31日目から60日目で進める設計と検証
利用者ごとのアクセス権限を見直す
設計と検証の段階では、利用者が必要なシステムだけにアクセスできるよう、権限を見直します。全員に同じ権限を与えるのではなく、職務、所属、担当業務に応じて権限を分けます。
権限見直しでは、現在の権限を削減するだけでなく、申請、承認、付与、変更、削除の流れを整えることが重要です。担当者の異動後も以前の権限が残る状態を防ぐため、異動時の確認項目に権限見直しを組み込みます。
管理者権限は、通常の業務アカウントと分離します。管理作業が必要なときだけ専用アカウントを利用することで、日常的なメール閲覧やWeb利用中に管理者権限が悪用されるリスクを抑えます。
多要素認証とログイン管理を試験導入する
選定した利用者とシステムを対象に、多要素認証を試験導入します。導入前に、認証方法、端末変更時の手順、認証アプリを使えない場合の対応、緊急時の連絡先を周知します。
試験導入では、安全性だけでなく、利用者の負担も確認します。認証の要求が多すぎると、利用者が手順を回避しようとしたり、問い合わせが増えたりする可能性があります。信頼できる会社支給端末からの利用時は追加認証の頻度を抑えるなど、業務とのバランスを検討します。
ログインの記録を確認し、通常と異なる国や地域からのアクセス、多数回のログイン失敗、短時間での異常な操作がないかを確認できる状態にします。ただし、ログを収集するだけでは不十分です。誰が確認し、どのような事象を調査対象とするかを決めます。
端末の更新状況とセキュリティ対策を確認できるようにする
端末については、OSの更新状況、暗号化、セキュリティ対策の稼働状況を確認できるようにします。端末管理の仕組みを導入する場合も、最初は対象台数を絞り、設定の影響を確認します。
端末が基準を満たしていない場合に、直ちにすべてのアクセスを遮断すると、業務停止につながる可能性があります。初期段階では、利用者へ通知して更新を促す運用から始め、期限までに改善されない場合にアクセスを制限する方法が現実的です。
端末紛失時の遠隔ロックや業務データの削除が可能かも確認します。操作を誤ると業務データが失われるおそれがあるため、実行権限を持つ担当者、判断基準、連絡手順を明確にしておきます。
小規模な対象で安全な接続方法を検証する
VPNからの移行を検討する場合は、対象アプリケーションと利用者を限定して検証します。利用者が許可された業務システムだけに接続できるか、不要なネットワークへ接続できないか、通信速度や操作性に問題がないかを確認します。
検証対象には、実際に業務を行う利用者を含めます。情シスだけで問題なく使えても、現場の業務手順に合わなければ本導入は成功しません。ファイルのアップロード、印刷、社外からの接続、複数端末での利用など、実務に近い操作を確認します。
問題が見つかった場合は、例外を恒久的に増やす前に、権限設定、接続方式、業務手順で解決できないかを検討します。例外を増やしすぎると、設計が複雑になり、運用負荷とリスクが増えます。
問い合わせ対応と障害時の手順を整える
試験導入中は、認証できない、端末を変更した、通信が遅い、利用できるはずのシステムに接続できないといった問い合わせが発生します。問い合わせ窓口と対応時間を明確にし、よくある質問を事前に用意します。
障害時には、誰が状況を確認し、誰が利用者へ連絡し、どの条件で一時的な代替手段を許可するかを決めます。セキュリティを優先するあまり、緊急時の業務継続手段がないと、現場が独自の方法で情報を持ち出す原因になります。
手順書は、情シス担当者だけが理解できる内容ではなく、引き継ぎ可能な形で残します。認証端末の紛失、退職者のアカウント停止、不審なログイン、接続障害など、発生頻度の高い事象から整備します。
61日目から90日目で行う稟議と本導入の準備
導入効果を経営層に説明できる形にまとめる
経営層への説明では、技術用語を並べるよりも、事業継続、情報漏えい、取引先対応、運用負荷の観点で整理することが重要です。
たとえば、多要素認証の導入により、パスワード漏えい時の不正ログインリスクを下げられること、端末確認により管理対象外端末からの情報持ち出しを抑えられること、接続先を限定することで侵入後の被害拡大を防ぎやすくなることを説明します。
試験導入で得られた結果も示します。対象人数、多要素認証の登録率、問い合わせ件数、利用者からの意見、検出された設定不備、改善すべき課題を整理すると、導入後のイメージを共有しやすくなります。
初期費用と継続費用を分けて予算化する
予算化では、初期費用と継続費用を分けて整理します。初期費用には、設計、設定、既存環境との連携、端末設定、利用者教育、手順書作成などが含まれます。継続費用には、利用者数に応じた利用料、保守、ログ監視、問い合わせ対応、定期見直しなどが含まれます。
初期費用だけで比較すると、導入後に運用負荷が増え、想定外の費用が発生することがあります。特に、ログ監視やインシデント対応を社内で担うのか、外部へ委託するのかは、費用と体制の両面から判断します。
既に契約しているクラウドサービスや端末管理機能に、認証や端末管理の機能が含まれている場合もあります。新たな製品を追加する前に、既存契約で利用できる機能を確認すると、投資の重複を避けられます。
段階導入の計画と評価指標を示す
本導入では、認証、端末、通信を段階的に整備する計画を示します。一般的には、まず利用者の本人確認を強化し、次に端末の安全確認を行い、その後にVPNからの移行や通信制御を進める順序が取り組みやすい方法です。
評価指標も事前に決めます。経営層が導入効果を確認できるよう、次のような指標を用意します。
- 多要素認証が有効なアカウントの割合
- 管理対象として登録された端末の割合
- OS更新や暗号化の基準を満たす端末の割合
- 退職、異動時のアカウント停止や権限変更にかかる時間
- 不審なログインや端末の異常を検知した件数
- VPN接続に関する問い合わせ件数
- 定期的な権限見直しの実施率
指標は、数値を集めること自体が目的ではありません。リスクが下がっているか、運用が回っているか、利用者の負担が過大になっていないかを確認するために使います。
利用部門と管理部門の役割分担を決める
ゼロトラストは情シスだけで完結しません。利用部門には、利用者の情報変更、不要になった権限の連絡、業務影響の確認、利用者への周知などを担ってもらう必要があります。
情シスは、技術設定、アカウント管理、端末管理、ログ確認、障害対応を担います。人事や総務は、入社、異動、退職の情報を速やかに連携します。経営層や部門責任者は、例外の承認や優先順位の判断を担います。
役割分担が曖昧だと、退職者のアカウント削除が遅れる、端末返却が確認できない、例外が放置されるといった問題が起こります。担当者名だけでなく、担当変更時にも引き継げるよう、役割と手順を文書化します。
本導入前の確認項目と承認手順を整える
本導入前には、対象システム、対象利用者、端末基準、例外、障害対応、問い合わせ窓口が整理されているかを確認します。特に、管理者アカウントに多要素認証が適用されているか、退職者のアカウントを停止する手順が機能するかは、優先的に確認します。
承認手順では、誰が導入範囲を決め、誰が業務影響を確認し、誰が例外を承認するかを定めます。導入後に設定変更が必要になった場合も、変更理由、影響範囲、承認者、実施者を記録する運用を整えます。
導入判定は、機能が動作するかだけでなく、運用担当者が対応できるか、利用者が手順を理解しているか、障害時に連絡できるかまで含めて行います。
導入後に負担を増やさない運用設計
入社・異動・退職時のアカウント管理を標準化する
ゼロトラストの効果を維持するには、入社、異動、退職に合わせたアカウント管理を標準化する必要があります。入社時には必要なアカウントと端末を用意し、異動時には不要な権限を削除し、退職時には当日中にアクセスを停止できる状態を目指します。
人事情報の連携が遅れると、退職者や契約終了者がシステムへアクセスできる期間が残ります。人事部門、総務、情シスの間で、いつ、誰が、どの情報を連絡するかを決めます。
定期的にアカウント一覧と在籍者一覧を照合し、不要なアカウントがないか確認することも重要です。共有アカウントは管理が難しいため、利用理由を確認し、廃止または個人アカウントへの移行を進めます。
端末紛失や不審なログインへの対応手順を決める
端末紛失や不審なログインは、発生時の初動が重要です。利用者が迷わず連絡できる窓口を用意し、連絡後に実施する作業を標準化します。
端末紛失時には、本人確認、端末の利用停止、業務アカウントの保護、端末の位置確認や遠隔操作の可否、関係部門への連絡を行います。不審なログイン時には、アカウントの利用停止、認証情報の変更、ログ確認、影響範囲の調査を行います。
すべての事象を同じ緊急度で扱う必要はありません。管理者アカウントや重要情報を扱うアカウントに関する事象は優先度を高くし、休日や夜間の連絡方法も定めます。
利用者が困りやすい場面を事前に周知する
利用者にとって、多要素認証や端末管理はこれまでより手順が増えたように感じられる場合があります。導入前に、認証方法、端末変更時の操作、認証アプリを利用できない場合の連絡先、海外出張時の注意点などを周知します。
特に、スマートフォンの機種変更、紛失、故障は認証できなくなる原因になりやすいため、事前に手順を案内します。利用者が困ったときに自己判断で認証を無効化したり、パスワードを共有したりしないよう、支援窓口を明確にします。
周知は一度だけではなく、入社時教育、定期研修、社内ポータルなどで継続します。専門用語を避け、利用者が自分に関係する行動を理解できる内容にすることが重要です。
ログの確認頻度と確認する担当者を決める
ログは、収集するだけでは対策になりません。誰が、どの頻度で、どのような事象を確認するかを決めます。兼任の情シス担当者が毎日すべてのログを確認することが難しい場合は、優先度の高いアラートに絞る、外部の監視支援を利用するなど、実行可能な体制にします。
確認対象としては、管理者アカウントへのログイン、多数回の認証失敗、通常と異なる地域からのアクセス、端末のセキュリティ対策停止、重要データの大量ダウンロードなどがあります。
アラート発生時の対応手順も必要です。確認だけで終わらせず、利用者への確認、アカウント停止、端末隔離、上長への報告など、事象ごとの初動を定めます。
定期的な権限見直しと設定変更の管理を続ける
ゼロトラストは導入後も継続的な見直しが必要です。組織変更、業務変更、新しいクラウドサービスの利用開始により、必要な権限やリスクは変化します。
権限は、少なくとも定期的に部門責任者と確認します。管理者権限、外部委託先のアカウント、長期間利用されていないアカウント、例外設定は優先的に見直します。
設定変更については、変更内容、変更理由、影響範囲、承認者、実施日を記録します。記録を残すことで、障害発生時に原因を追跡しやすくなり、担当者交代時の引き継ぎにも役立ちます。
ゼロトラスト導入で起こりがちな失敗と回避策
製品の導入だけで対策が完了したと考える
ゼロトラストは製品名ではなく、利用者、端末、通信、データを継続的に確認する考え方です。認証や端末管理の製品を導入しても、設定が適切でなければ効果は限定的です。
回避策は、導入目的と運用責任を明確にすることです。誰のどの業務を守るのか、どの状態を満たせば安全と判断するのか、異常を検知したときに誰が対応するのかを決めます。製品の機能一覧ではなく、自社のリスクと業務に照らして評価します。
管理者権限と例外対応を放置する
管理者権限は、攻撃者に悪用された場合の影響が大きいため、最優先で管理すべき対象です。しかし、業務の都合で付与した権限や、多要素認証を免除した例外が、そのまま残るケースは少なくありません。
回避策は、管理者権限を通常アカウントと分離し、利用者と目的を明確にすることです。例外は理由、承認者、有効期限、代替対策を記録し、定期的に見直します。例外を認めること自体ではなく、例外を把握できない状態が問題です。
現場の業務影響を確認せずに利用を制限する
安全性を優先してアクセスを一律に制限すると、必要な業務ができなくなり、現場が独自の共有手段や個人アカウントを利用する原因になります。これでは、かえって管理対象外の利用が増えます。
回避策は、導入前に利用部門と業務手順を確認し、小規模な試験導入を行うことです。現場が実際に行う操作を確認し、業務に必要な権限を設定します。問題があれば、利用制限を緩めるだけでなく、業務手順や端末運用を含めて解決策を検討します。
VPNを急に停止して業務を止める
VPNにリスクがあるからといって、代替手段が整う前に停止すると、社外から利用する業務システムへ接続できなくなります。利用実態を把握していないと、情シスが知らない利用者やシステムへの影響も発生します。
回避策は、VPNと新しい接続方式を一定期間併用し、対象システムを段階的に移行することです。移行完了の条件を事前に定め、利用者テスト、障害対応手順、問い合わせ体制を確認してからVPN停止を判断します。
運用担当者と問い合わせ窓口を決めない
導入後に多要素認証でログインできない、端末を変更した、不審な通知が届いたといった問い合わせが発生します。窓口や担当者が不明確だと、利用者が対応できず、業務停止や不適切な回避行動につながります。
回避策は、導入前に運用担当、問い合わせ窓口、対応時間、緊急連絡先を決めることです。情シスだけで対応が難しい場合は、対象範囲を絞る、手順を標準化する、外部支援を活用するなど、継続できる体制を設計します。
ゼロトラストの導入は、90日で完了する一度きりのプロジェクトではありません。最初の90日で現状を整理し、優先度の高い領域から安全性と運用性を確認しながら進めることで、無理のない継続的な改善につなげられます。
