シャドーITへの対応は、未承認サービスを見つけたところで終わりません。誰が、何の業務に、どの情報を使っているかを把握し、利用を続ける条件か代替先を決めることが必要です。
この記事では、企業のIT担当者と部門責任者に向けて、利用実態の調べ方と扱いを決める確認表を整理します。SaaS管理台帳に登録する前の、発見から承認判断までが対象です。
シャドーITとは、IT部門が把握・承認していない業務利用
IBMはシャドーITを、IT部門の承認・認識・監督なしに企業ネットワークで使われるソフトウェア、ハードウェアなどのIT資源と説明しています。例として、個人のクラウドストレージへの業務ファイル保存、未承認のオンライン会議やチャットを挙げています。IBMのシャドーIT解説
同解説では、承認を待たずに使いたい、会社が提供する選択肢より業務に合う機能を使いたい、といった導入の動機も示されています。管理側が存在を知らなければ、脆弱性や設定、権限の点検が行き届かず、情報漏えいなどのリスクにつながります。
確認するときは、「無料か有料か」「有名な製品か」より、自社が認めた利用範囲と実際の使い方を照合しましょう。同じサービス名でも、会社管理のアカウントと個人のアカウントを分けて記録すると、承認対象を明確にできます。
利用実態は、申告・支出・技術的な記録から探す
以下の確認表と判断手順は、本稿の運用整理案です。自社の規程、収集できる記録、担当者の権限に合わせて使ってください。
最初に対象部門と調査期間を決め、次の情報を突き合わせます。調査の案内には、対象となるサービスの例、回答先、回答期限を記載します。
| 調べる入口 | 確認したいこと | 読み取る際の注意 |
|---|---|---|
| 部門への聞き取り・自己申告 | 業務で使うサービス、目的、利用者、保存情報 | 取引先から招待されたものや試用中のものも質問する |
| 経費・購買の記録 | 契約名、支払部門、契約者、更新時期 | 無料サービスは別の入口で補う |
| 管理対象端末・通信の記録 | サービスへのアクセスや利用の手掛かり | 対象端末、通信経路、取得期間を記録する |
技術的な発見手段の例として、Microsoft Defender for Cloud Appsでは、端末製品との連携やファイアウォール・プロキシのログ収集が案内されています。ただし、同製品は既定ではカタログにないアプリを発見できません。検出されなかったことを、利用されていない証明にしないことが大切です。Microsoftの発見・管理手順
通信記録にサービス名が出てきたら、業務利用の有無、使っているアカウント、扱う情報を利用部門に確認します。社内で認められた調査範囲を守り、目的に必要な項目を収集してください。
発見したサービスごとに、判断用の一枚を作る
サービス名だけの一覧から、次の確認表へ進みます。空欄は「問題なし」にせず、確認する担当者と期限を付けて残します。
| 項目 | 記入する内容 |
|---|---|
| サービスと利用単位 | 名称、URL、契約プラン、会社用・個人用の別 |
| 業務の必要性 | 使う作業、必要な機能、既存ツールでは難しい点 |
| 利用者と責任者 | 部門、利用者、業務責任者、管理者 |
| 扱う情報 | 保存・入力・共有する情報、機密性、社外の共有相手 |
| 管理できること | アカウント回収、権限変更、共有制限、記録の確認方法 |
| 終了できること | データの取り出し・削除方法、契約の解約・更新条件 |
| 判定の根拠 | 提供元資料、実際の設定、確認日、未解決の質問 |
| 決定 | 扱い、条件、承認者、対応担当、期限、次回確認日 |
提供元のセキュリティ説明を読む際は、利用しているプランや機能との対応を確かめます。認証情報を評価材料にする場合の読み方は、クラウドのセキュリティ認証と対象範囲を参照してください。
共有機能を使っているサービスなら、保存先だけでなく相手と権限を確認対象にします。具体的な点検項目は、クラウドストレージの外部共有とアクセス権で整理しています。
扱いは「正式利用・条件付き・移行・停止」に分けて決める
Microsoftの手順でも、利用者に業務上の理由を確認し、評価を経て承認やブロックを決める流れが示されています。その考え方を社内の判断記録に落とすなら、次の四つに分けると条件を具体化できます。
| 扱い | 選ぶ際に確かめること | 決定時に残すもの |
|---|---|---|
| 正式利用へ移す | 業務に必要で、自社の利用基準を満たせるか | 承認範囲、管理者、許可する情報・共有方法 |
| 条件付きで利用する | 未解決事項を残しても、用途や期間を限定して認められるか | 制限事項、承認者、期限、再判定条件 |
| 承認済みサービスへ移行する | 必要な業務を代替先で継続できるか | 移行対象、担当、移行日、旧環境の終了条件 |
| 利用を停止する | 許容できないリスクや利用基準との不一致があるか | 停止範囲、業務への対応、情報の保全・回収方法 |
条件付き利用を選ぶなら、「当面使ってよい」だけでは記録が足りません。たとえば入力できる情報を限定する場合、その条件を実際の業務で守れるか、誰が確認するかまで決めます。確認できていない重要事項が残る場合は、正式利用の承認と区別してください。
漏えいの疑いなど緊急性があるケースは、自社のインシデント対応手順に引き継ぎます。通常の承認審査とは担当と優先順位を分け、証跡の扱いも確認しましょう。
正式利用への移行は、管理を引き継いで完了にする
正式利用と決めた後は、管理台帳への登録に加え、判断時に約束した条件を実行します。次のように担当と完了条件を割り当てることを勧めます。
- 利用部門：必要なデータと業務を確認し、移行後に作業を続けられることを確かめる。
- IT担当：管理権限、利用者、共有設定、退職・異動時の権限回収手順を確認する。
- 契約担当：契約名義、支払方法、更新・解約条件を整理する。
- 承認者：条件の実施結果と未解決事項を確認し、管理台帳へ引き継ぐ。
個人アカウントから会社管理へ切り替える場合は、所有権やデータを移せるかをサービスごとに調べます。移せない場合の代替手順も、旧環境を終了する前に決めておきます。
移行・停止の場合も、通信の遮断だけを完了条件にせず、データ、共有権限、アカウント、契約の終了確認を記録しましょう。旧環境の削除は、必要な保全と移行結果を確認してから実施する手順にします。
次の未承認利用を相談できる入口を用意する
調査で把握した「既存ツールではできなかった作業」「申請で分からなかった項目」を、利用申請の見直しに使います。申請先、必要項目、回答の目安、急ぎの場合の相談先を示し、利用部門が判断を仰げる状態にします。
まずは一つの部門で利用サービスを確認し、各サービスについて業務責任者、扱う情報、次の対応を記入してください。判断待ちのものに担当と期限を付けるところまで進めれば、発見した一覧を承認や移行の作業につなげられます。