2026/08/26 14:15

【Netskope】社内を可視化した後は何をすればいいの？可視化データから「制御の線引き」を決める方法

はじめに

こんにちは、セキュリティを気にする年頃のネクストモード株式会社のtommyです

ネクストモードでは社内システムとして利用しているSaaSやWebへのアクセスにおいて、Netskopeを経由する構成を取り、通信の可視化や制御を行っています

前回はクラウドや生成AIの利用はまず可視化から始めましょう、という話をしました。今回は可視化の次に必ずぶつかる「で、どれを止めるのか」という問いについて、制御の線引きをどう決めていけばよいかを整理してみます。前回のブログはこちらからご覧ください

今回紹介するNetskopeについて

Netskopeとは、クラウドサービスの使用時に生じる情報漏洩のリスクや、外部の第三者による不正アクセス、マルウェアの感染といった脅威から機密情報を守り、SaaS環境のセキュリティを強化することができるSASEソリューションです

Netskopeでは暗黙の信頼がなく、通信を可視化することが可能です。また、ネットワークとセキュリティに関わる機能を備えているため、VPNやUTM、FW、CASB/SWG/DLP機能を持つ製品からのリプレース先になります

また推奨する理由として、弊社が利用していて使いやすい製品であるというのも大きいと言えます

詳細は下記を御覧ください

可視化の次で、多くの企業が止まる

可視化を始めてまず驚くのは、アプリの数です。想定していた数十ではなく、何百という未承認のサービスが一覧に並ぶこともあります。Netskopeの調査でも、1社あたりで使われているクラウドアプリ・サービスは平均1,295、そのうちIT部門が管理できているのは2%未満とされています

ところが、そこから手が進みません。よくあるのは次のような状態です

アプリ一覧は出たものの、どれが危ういのか優劣を付けられない
止めようとすると「業務で使っている」と言われ、それ以上話が進まない
判断が担当者の感覚に依存しており、上司や他部門に説明できない
結果として、毎月のレポートが「見るだけ」になっている

見ているうちに、リスクのほうは先に進んでいます。同じくNetskopeのレポートでは、機密データがAIアプリに送られるインシデントは過去1年で倍増し、1組織あたり月平均223件に達しています

仕組みは動いているのに、その先だけが進まない。担当者の意識が低いから起きているわけではありません

問題は手順ではなく、判断基準がないこと

「可視化の次に何をするか」の手順は、調べればいくらでも見つかります。リスクの高いアプリを特定し、ポリシーを作り、段階的に適用する。こう書けばそのとおりです

それでも進まないのは、リスクの大小を決める物差しが社内にないからです。手順書があっても、「このアプリはリスクが高い」と判断する根拠がなければ、最初の一歩で止まります

可視化の後に制御

この状態を放っておくと、二つの方向に振れやすくなります

ひとつは放置です。判断がつかないまま時間が過ぎ、危険な利用がそのまま残ります

もうひとつは過剰な遮断です。判断できないので、とりあえず未承認アプリをまとめてブロックする。その場は収まりますが、現場からの反発を招き、個人アカウントや個人端末へ逃げられます。実際、Netskopeの調査からは、生成AIの利用者の47%は個人のAIアプリを仕事で使っており、企業内のAI利用の約60%は管理外のいわゆるシャドーAIだとされています。雑に止めるほど、見えない利用は増えていきます

必要なのは、次にやることのリストではなく、判断の軸です

制御の線引きを決める4つの指標

可視化で見えてきたアプリを、次の4つの指標で仕分けてみます

指標	見るもの	判断への効き方	参照する情報の例
利用量と利用者数	何人が、どの頻度で使っているか	止めたときの業務影響の大きさが分かる	アプリ別の利用者数・通信量の集計
アプリの信頼度	提供元、法人契約の有無、データの扱い	使い続けてよい相手かを判断できる	アプリごとのセキュリティ指標
扱われるデータ種別	個人情報、ソースコード、顧客情報など	万が一のときの被害の重さが分かる	DLPの検知ログ、アップロード履歴
代替手段の有無	公式採用ツールで代えられるか	止めたときに逃げ場があるか分かる	社内の公式ツール一覧との突き合わせ

利用量と利用者数は、何百人もが毎日使っているのか、数人が試しに使っているだけなのかを見る軸です。広く使われているものは、止める前に「なぜ必要なのか」を聞くところから始めます

アプリの信頼度は、提供元や契約形態、入力データを学習に使う仕様かどうかといった点です。Netskopeにはアプリごとのセキュリティ特性を指標化して見る仕組みがあるので、一から調べ直さなくても目安はつきます

扱われるデータの種別は、同じアプリでも公開情報を要約させているのと、顧客リストやソースコードを貼り付けているのとでは意味が違う、という見方です。これは感覚の話ではなく、AIアプリで検知されるデータポリシー違反のうち、最も多いのは規制対象の個人データで全体の約58%、それにソースコードが続くというデータがあります

代替手段の有無は、公式に採用しているツールで同じことができるなら止める判断はしやすくなる、ということです。逆に代替がない場合に止めると、別の抑えられない手段へ流れていきます

この4つの指標でアプリを棚卸したのちに、下記の二軸を交差させた見方をすることで、優先度順に制御に落とし込むことができます

制御の線決め

データが重くて業務必要度が低いものから手を付ける。反対にデータが軽くて業務に根付いているものは、慌てて触らない。この順番で進めると、「業務で使っているのに勝手に止められた」という苦情の出やすいアプリが、最初の対象から外れます

ただし、この2軸にのらない利用があります。管理者権限や特権アカウント、共有アカウント、外部ベンダーに渡した一時権限で利用しているサービスです。ここは後半で改めて取り上げます

「止めるか許すか」の二択にしない

軸が決まったら、次は打ち手です。ここで大切なのは、制御は「止めるか許すか」の二択ではないということです。弱いものから強いものまで、ここでは六つの段階に分けて考えてみます

業務影響別制御方法

一番弱いのは、黙認して記録だけ残すやり方です。業務で広く使われていて、データのリスクも低いものに当てます。何もしないのとは違い、利用実態を記録し続けるという判断をします。この記録は、後で契約の見直しや公式採用の検討に使えます

一段上がると、利用者へのリアルタイム通知です。グレーなアプリに向いています。アクセスしたときに「このサービスは社内の推奨ツールではありません。機密情報の入力は控えてください」と伝え、続行するかどうかを本人に選ばせます。このコーチングを提示されたとき、そのまま続行するユーザーは27%だけで、残りの73%は利用をやめるという結果が報告されています。止めなくても、伝えるだけで行動は変わります

もう少し強くするなら、機能単位の制御。アプリ単位ではなく、操作単位で線を引きます。閲覧は許すがアップロードは止める、個人アカウントでのログインだけ止める、といった形です。「使えない」という反発を最小限にできます

アプリではなく中身で判断するのが、DLPによる内容ベースの制御です。カード番号やマイナンバーのように書式が決まっているものは確実に検知できます。一方で、ソースコードのように書式のないものは判定精度を見ながら調整していくことになります。日々増えるアプリの数を追いかけるより、こちらのほうが運用として続く場面もあります

止めるときも、いきなり扉を閉めないやり方があります。ブロック画面で「この用途なら社内ではこちらを使ってください」と代替先を案内する。同じブロックでも、受け入れられ方が変わります

一番強いのが、完全なブロックです。信頼度が低く、業務利用も少ないものは、止める判断で構いません。ただし、少数でも特定の部署が業務で使っていないかだけは、止める前に確認しておきます

こう並べてみると、最初からブロックを検討する必要があるアプリは、そう多くないことが分かります。Netskopeの調査で生成AIアプリを完全に止めているアプリ数は平均2.4個にとどまります。多くの組織は、全面禁止ではなく使い方を絞る方向で落としどころを探しています

2軸では線を引けない領域がある

ここまでの考え方で、クラウド利用の大半は整理できます。ただし、軸に当てはめても判断が下せない利用が残ります。管理者によるSaaS管理コンソールやクラウド基盤へのアクセス、共有アカウント、外部ベンダーに渡した一時権限などです

軸	一般ユーザーのクラウド利用	管理者権限／特権アカウント等
利用量・利用者数	多いものから少ないものまで幅がある	常に少ない（数人）
アプリの信頼度	高いものも低いものもある	高い（自社が採用したサービス）
扱われるデータ	軽いものから重いものまで	最も重い（全社員分の設定とデータ）
代替手段	あることが多い	ない（入れなければ運用が回らない）
判断結果	黙認〜ブロックのどこかに収まる	「止める」という選択肢がない

つまり、この領域には「止める」という選択肢がはじめから存在しません。にもかかわらず、一回の悪用で影響が最も大きいのはここです。調査結果から内部不正に関するインシデントの60%には個人のクラウドアプリインスタンスが関与しており、持ち出されるのは規制データやソースコード、そして認証情報です。権限を持つ側のアカウントをどう扱うかは、避けて通れない論点です

ここで必要になるのは、止めるか許すかとは別の発想です。必要な人に、必要な分だけ権限を渡す。これが最小権限の原則です。その上で、常時渡したままにしないこと（必要なときだけ権限を有効にする）と、使った記録を残すこと（監査証跡）が組み合わさります

特権アクセス管理（PAM）という打ち手

この三つをまとめて仕組みにしたものがPAM（Privileged Access Management：特権アクセス管理）です。管理者権限を持つアカウントを管理・保護し、「誰が、いつ、何にアクセスしたか」を記録します

製品によって実装範囲は異なりますが、一般には次の四つが挙げられます

機能	やっていること	効いてくる場面
パスワード管理	特権アカウントのパスワードを金庫に保管し、定期変更する	共有アカウントの使い回しをなくす
アクセス制御	申請・承認フローや、期間を区切った権限付与を行う	外部ベンダーへの一時的な権限付与
セッション管理	作業中の操作を記録・監視する	本番環境へのアクセス管理
監査・レポート	アクセス履歴をレポートとして出力する	監査対応での証跡提示