内部脅威への対策 - 従業員による情報漏洩と退職者リスクを防ぐ
この記事は約 13 分で読めます
公開日: 最終更新日:
内部脅威は、組織が直面するセキュリティリスクの中で最もコストが高く、検知が困難なものの 1 つです。境界防御を突破する必要がある外部攻撃とは異なり、内部者はすでに正当なアクセス制御の認証情報と組織内部の知識を持っているため、その操作は通常の業務と見分けがつきにくく、発覚までが長期化しやすいという特徴があります。しかも内部脅威の多くは機密を狙った持ち出しではなく、誤送信や設定ミスといった日常業務の中の過失から生まれます。本記事では、最小権限の原則の実装から行動分析の導入、セキュリティ意識の高い組織文化の構築まで、内部脅威を軽減する実践的な戦略を解説します。
内部脅威の統計と実態
悪意ある内部者 vs 過失による漏洩
内部脅威と聞くと、企業秘密を持ち出すスパイのような存在を想像しがちですが、実態は大きく異なります。内部脅威は大きく 3 つに分かれます - 従業員の過失 (メールの誤送信、共有設定のミス、フィッシングへの引っかかり)、悪意ある内部者による持ち出し、そして外部の攻撃者が正規の認証情報を盗んで内部者になりすますケースです。件数の大半を占めるのは過失で、1 件あたりの損害は他の 2 つより小さくても、頻度が高い分だけ積み上がります。対策の優先順位を「悪意ある内部者の摘発」だけに置くと、最も件数の多い部分が手つかずのまま残ります。
悪意ある内部者による事件は、1 件あたりの損害が大きく、しかも発覚までに数か月を要することが珍しくありません。退職予定者が競合他社への転職前に顧客リストや技術文書を持ち出すケースが典型的で、本人には正規のアクセス権があるため、持ち出しの瞬間だけを見てもログ上は通常業務と変わりません。一方、認証情報の窃取は、外部の攻撃者がフィッシングやソーシャルエンジニアリングで従業員の認証情報を入手し、正規ユーザーになりすましてシステムに侵入するパターンです。この場合も認証は成功しているため、認証の可否だけを見る仕組みでは検知できません。
最小権限の原則の実装
RBAC と ABAC の使い分け
内部脅威対策の基盤は、最小権限の原則の徹底です。従業員には業務に必要な最小限のアクセス権限だけを付与し、不要な権限は即座に剥奪します。これを実現する代表的な手法が RBAC (役職ベースのアクセス制御) と ABAC (属性ベースのアクセス制御) です。
RBAC は「営業部長」「開発者」「経理担当」といった役職にアクセス権限のセットを紐づける方式で、管理がシンプルで導入しやすい反面、同じ役職でも担当プロジェクトによって必要な権限が異なるケースに対応しにくい欠点があります。ABAC はユーザーの属性 (部署、役職、勤務地)、リソースの属性 (機密レベル、プロジェクト)、環境の属性 (時間帯、アクセス元 IP、デバイス種別) を組み合わせて動的にアクセスを制御します。例えば「経理担当者が、業務時間内に、社内ネットワークから、自部門の財務データにのみアクセスできる」といったきめ細かいポリシーを定義できます。組織の規模が大きくなり、業務委託や兼務、リモート勤務が混在するほど、役職だけでは必要な権限を言い表せなくなるため、属性を組み合わせる方式の必要性が高まります。
実務上は RBAC と ABAC を組み合わせるハイブリッドアプローチが効果的です。基本的なアクセス権限は RBAC で管理し、機密性の高いリソースへのアクセスには ABAC の動的制御を追加します。こうしたアクセス制御の設計は、企業のパスワードポリシー全体と整合させることが重要です。また、90 日ごとのアクセスレビューを実施し、使われていない権限を定期的に棚卸しすることが重要です。
退職者のアクセス無効化チェックリスト
退職日までのタイムライン
退職者のアクセス管理は、内部脅威対策の中でも最も見落とされやすい領域の一つです。人事の退職手続きと情報システム側のアカウント停止が別々に進むため、最終出社日を過ぎても社外の SaaS やクラウドストレージ、共有アカウント、個人端末に残ったキャッシュ経由でアクセスが生き残りがちです。とくに部門が個別契約したサービスは情報システム部門の台帳から漏れやすく、誰も止める担当がいないまま放置されます。退職通知を受けた時点から、段階的にアクセスを縮小するプロセスを開始すべきです。
退職 2 週間前には、機密プロジェクトへのアクセスを解除し、引き継ぎに必要な範囲のみに権限を限定します。退職 1 週間前には、共有ドライブの書き込み権限を読み取り専用に変更し、大量のファイルダウンロードを監視対象に追加します。退職日当日には、全アカウントを即座に無効化します。Active Directory、Google Workspace、Microsoft 365 のアカウント停止はもちろん、見落としがちな SaaS アカウント (Slack、GitHub、Notion、Figma、Jira、Salesforce など) も漏れなく無効化してください。
現代の職場では 1 人の従業員が業務で触れる SaaS が数十種類に及ぶことも多く、IT 部門が把握していないシャドー IT を含めると実数はさらに多くなります。手作業のチェックリストで退職時のアカウント停止を漏れなく行うことは、この規模では現実的ではありません。退職者のアクセス無効化を確実に行うには、SCIM (System for Cross-domain Identity Management) プロトコルに対応した ID 管理基盤を導入し、アカウントの一括プロビジョニング・デプロビジョニングを自動化することが理想的です。
UEBA による異常検知
行動ベースラインとアラート
UEBA (User and Entity Behavior Analytics) は、ユーザーやデバイスの通常の行動パターンをベースラインとして学習し、逸脱した行動をリアルタイムで検知する技術です。従来のルールベースの検知 (「深夜 2 時にログインしたらアラート」) とは異なり、UEBA は個々のユーザーの行動パターンを機械学習で分析するため、「普段は 9 時〜18 時に勤務する従業員が深夜にアクセスした」場合にのみアラートを発し、夜勤の従業員の深夜アクセスは正常と判断します。
UEBA が検知する典型的な異常パターンには、通常アクセスしないデータベースやファイルサーバーへのアクセス、短時間での大量ファイルダウンロード、USB デバイスへの大量データコピー、通常と異なる時間帯や場所からのアクセス、権限昇格の試行などがあります。これらの異常をSIEM (Security Information and Event Management) と連携させることで、ログの相関分析が可能になり、単独では見逃しがちな複合的な脅威を検知できます。UEBA はゼロトラストセキュリティの「常に検証する」という原則を技術的に実現する中核コンポーネントでもあります。
UEBA の導入で注意すべきは、誤検知 (false positive) の管理です。導入初期はベースラインの学習が不十分なため、大量の誤検知が発生します。有効なベースラインを作るには、月初と月末、繁忙期と閑散期といった業務の周期を一通り含む期間の観測が必要で、稼働直後の判定を鵜呑みにすることはできません。また、アラートの優先度付け (リスクスコアリング) を適切に設計しないと、セキュリティチームがアラート疲れに陥り、本当に重要なアラートを見逃す危険があります。
組織文化と内部通報制度
技術的な対策だけでは内部脅威を完全に防ぐことはできません。監視ツールを導入しても、従業員が「監視されている」と感じれば信頼関係が損なわれ、かえって不満や離職を招き、内部脅威のリスクを高める逆効果が生じます。Carnegie Mellon 大学の CERT Insider Threat Center の研究では、内部脅威の多くが職場での不満、評価への不公平感、人間関係の悪化をきっかけに発生していると報告されています。
心理的安全性の高い組織では、従業員がセキュリティ上の懸念を報告しやすくなります。「同僚が不審な行動をしている」「自分が誤ってデータを外部に送信してしまった」といった報告が、報復を恐れずにできる環境が重要です。内部通報制度 (whistleblowing system) を設計する際は、匿名での通報を可能にし、通報者の保護を明文化し、通報に対する調査プロセスを透明化してください。EU の内部通報者保護指令 (2019/1937) や日本の公益通報者保護法を参考に、法的な保護の枠組みも整備すべきです。
ゼロトラストアーキテクチャは、内部脅威対策とも相性がよい設計です。社内ネットワークからの通信を無条件に信頼せず、リソースごとにアクセスの正当性を都度確認するため、正規の認証情報を持つ内部者の異常な振る舞いも検査の対象に入ります。ゼロトラストの「決して信頼せず、常に検証する」という原則は、内部者に対しても例外なく適用されるべきです。ただし、ゼロトラストの導入は従業員の業務効率に影響を与える可能性があるため、セキュリティと利便性のバランスを慎重に設計する必要があります。
今すぐできること
- 全従業員のアクセス権限を棚卸しし、業務に不要な権限を即座に削除する (90 日以上使用されていない権限は優先的に見直す)
- 退職者のアクセス無効化チェックリストを作成し、SaaS アカウントを含む全サービスの棚卸しを実施する
- 内部通報制度を整備し、匿名での報告が可能な仕組みを導入する
- パスつく.com で各システムに固有の強力なパスワードを生成し、認証情報の共有・使い回しを排除する
よくある質問
- 内部脅威で最も多い原因は何ですか？
- 件数で見ると、従業員の過失が大半を占めるとされます。メールの誤送信、クラウドストレージの設定ミス、フィッシングメールへの引っかかりなど、悪意のない行動が多くを占めます。悪意ある持ち出しや、盗まれた認証情報の悪用はそれより少数ですが、1 件あたりの被害は大きくなりがちです。
- UEBA の導入にはどのくらいの期間が必要ですか？
- UEBA ツールの技術的な導入自体は数週間で完了しますが、有効なベースラインの構築には、月初と月末や繁忙期といった業務の周期を一通り含む期間の観測が必要です。導入初期は誤検知が多発するため、3〜6 か月かけてチューニングを行い、アラートの精度を高めていくのが一般的です。
- 退職者のアカウント無効化で最も見落とされやすいものは何ですか？
- SaaS アカウントが最も見落とされやすい領域の一つです。Active Directory や Google Workspace は IT 部門が管理していますが、部門単位で契約した Slack、Notion、Figma、GitHub などのアカウントは IT 部門の管理外にあることが多く、退職後もアクセスが残りがちです。SCIM 対応の ID 管理基盤で一元管理するか、退職チェックリストに全 SaaS を網羅することが重要です。
この記事は役に立ちましたか？