仕事関係 — コンセプト記事
— 注意に頼らず、仕組みで防ぐ。AI 時代の脅威に備えて —
AI を使った攻撃、取引先や連携サービスを経由する攻撃、内部の操作や設定の誤りによる漏えい。こうした脅威に対して、情報セキュリティ部門や IT 管理部門が取り入れたい実践を、5つの視点でまとめました。 答えを先に言うと、従業員の「注意」に頼る運用から、防ぐ・気づく・自動で回す仕組みを組み込んだ運用へ移すことです。
この記事を読むとできること
想定している使い方
情報セキュリティ部門、IT 管理部門、開発部門の担当者が、自社の取り組みを見直すときの手がかりにすることを想定しています。 個人の Mac で試した考え方（前の記事）を、組織の仕組みに広げて書きました。 製品の名前は種類の例として挙げているだけで、特定の製品を勧めるものではありません。
読む目安：約13分 ・ 仕事関係のコンセプト記事 ・ 図7枚
セキュリティポリシーやガイドラインは、守る範囲と責任を決めるために欠かせません。ただし、それだけで止めようとすると、忙しい日の見落とし、設定の誤り、悪意のある操作の前で、簡単に破られます。攻撃する側も、AI を使って、もっともらしい文面や、大量の試行を安く作れるようになりました。人の注意に頼る部分が多いほど、守りは確率の勝負になります。
そこで、決まりを仕組みに落とし込みます。防ぐ仕組み、気づく仕組み、そしてそれらが働いているかを自動で確かめる仕組みです。人の注意は、仕組みでは決められない判断に集中させます。
図の見方：上の段は、従業員の注意に頼る運用です。人も設定も間違える日があり、1回の誤りが侵入や漏えいにつながります。下の段は、防ぐ・気づく・自動で回す仕組みを組み込んだ運用です。間違えても止まり、早く気づけるので、被害を小さく保てます。
APPROACH 1
物理的・機械的に止める仕組みを、3つの層に重ねます。製品の種類でいえば、EDR（端末の振る舞いを見張り、怪しい動きを止める仕組み）、DLP（機密の持ち出しを検知して止める仕組み）、権限の管理、実行環境の分離などが当たります。
図の見方：上から順に、1層目・2層目・3層目と重ね、1つが破られても次の層が受ける形にします。その全体を、疑似攻撃の自動の試験と、定期的なペネトレーションテストの2つで確かめ続けます。
運用で大切なのは、入れて終わりにしないことです。疑似攻撃の道具（攻撃の手口を安全に再現し、守りが反応するかを確かめるもの）で、止まるべき操作が止まるかを継続して自動で試します。同時に、業務の操作が誤って止められていないかも確かめます。止めすぎる守りは、現場で例外が積み重なり、いずれ外されるからです。
個人の実験から見えたこと
個人の環境でも、名指しで止めたつもりの操作が別の形で通ったり、便利さのために緩めた設定が別の層を迂回させたりしました。どちらも、実際に投げて試すまで気づけませんでした。規模が大きくなるほど、設定の変更は増えます。
小さく始めるなら：「既定は拒否」にする対象を、まず1つ（たとえば認証情報の保管場所）に絞り、その対象への疑似攻撃の試験を毎週自動で回すところから始めます。
APPROACH 2
退職者のアカウントの放置だけが問題ではありません。業務の効率化のために一時的に許可した SaaS（インターネット越しに使う業務サービス）の連携や、OAuth（ほかのサービスに、自分の代わりの操作を許す仕組み）の許可、ブラウザの拡張機能、API トークン（サービスを使うための鍵になる文字列）が、使われないまま残ります。こうした権限の残りは、取引先や連携サービスを経由する攻撃の入口になります。
従業員が使っている連携の許可や、長いあいだ使われていない鍵・トークンを、IAM（アカウントと権限をまとめて管理する仕組み）や CASB（クラウドサービスの利用を見える化して制御する仕組み）で定期的に自動で集め、危険度の順に並べます。会社が把握していない道具の利用（シャドー IT）も、ここで浮かび上がります。
一定の期間使われていない権限は、自動で無効にする仕組みを入れます。ただし、いきなり消さず、まず止めます。そのうえで、業務に影響が出たときに、利用者が決まった手順で再申請して戻せる道を用意します。セキュリティ部門が1件ずつ対応しなくて済み、止めることへの現場の抵抗も下がります。
図の見方：上から順に、権限を与えるときに持ち主と期限を付け、自動で集め、使われていないものを持ち主に知らせます。まず停止し、必要なら本人が再申請して戻し、戻す申請がなかったものだけを期限で削除します。
個人の実験から見えたこと
個人の点検の道具でも、危険度だけで消すと、その許可に頼っていた自動の処理が、黙って失敗し続けることが分かりました。組織では、人のいない時間に動く連携や、サービス用のアカウントほど、この形で止まります。止める前に「頼っているもの」を確かめる手順が要ります。
小さく始めるなら：まずは、社外のサービスとの連携の許可（OAuth）の一覧を1回作り、持ち主の分からないものを洗い出すところから始めます。
APPROACH 3
生成 AI を全社で使い始めると、これまでの Web の守りとは違う危険が出てきます。プロンプトインジェクション（文章に紛れた命令で、AI を操る手口）と、入力した機密の扱いです。契約や設定によっては、入力した内容がサービスの側に保存されたり、改善のために使われたりすることがあります。全社の決まり（ガバナンス）として、扱いを決める必要があります。
外部の AI へデータを送る出口に、社内の窓口（ゲートウェイ）を置き、個人情報、マイナンバー、クレジットカードの番号などを自動で検知して伏せ字にします。ただし、自動の検知には漏れがあります。文書の区分（どの文書を、どこまで外に出してよいか）を先に決め、検知はその補助と位置づけます。
AI に業務の最終判断や、正確さが要る計算をさせません。AI は意図の読み取りや下書きにとどめ、決定と計算は社内の基幹のシステムで行う形を、標準の作りにします。これで AI の誤り（もっともらしい誤り＝ハルシネーション）そのものは無くなりませんが、誤りが、そのまま業務の決定に入ることを防げます。
極秘の案件や、高度な個人情報のように、外部に出せない情報を扱う業務には、社内のネットワークや専用の環境の中で完結する AI を用意し、データの境界線を守ります。
図の見方：上から順に、従業員の依頼は社内の窓口を通り、そこで伏せ字化・記録・持ち出しの検知を行います。データの区分に応じて、外部の AI か社内で完結する AI に振り分けます。最後の計算・判定は基幹のシステムが、決定は人が行います。
個人の実験から見えたこと
個人の実験でも、外から取り込んだ文章に紛れた命令を探す検査は作れましたが、言い回しを変えた命令はすり抜けられます。本命は、外部の文章を読む AI に、送信や削除の権限を持たせないことでした。組織でも、AI につなぐ道具の権限の設計が、検知より先に来ます。
小さく始めるなら：社内の文書を「外部の AI に渡してよい／伏せれば渡してよい／渡さない」の3つに分ける表を作り、全社に配るところから始めます。
APPROACH 4
VPN（決まった端末どうしだけをつなぐ通信の仕組み）や社内のネットワークの中なら安全、という境界の考え方だけでは、守り切れなくなっています。従業員の端末が踏み台にされ、ブラウザ経由で社内のシステムが叩かれることがあるからです。そこで、毎回確かめるゼロトラスト（社内外を問わず、すべての接続を都度確かめる考え方）を取り入れます。
社内のシステムでも、サーバーどうしの通信や接続を、必要な最小限の区画に分けます（マイクロセグメンテーション）。あわせて、社内のアドレスへの思わぬ転送や、DNS リバインディング（DNS＝名前からアドレスを引く仕組みを悪用し、名前の引き直しで、外のサイトを社内の宛先に見せかける手口）を検知して止めるよう、プロキシ（通信の中継役）や WAF（Web アプリへの攻撃を手前で止める仕組み）の設定を見直します。
別のサイトを経由した、意図しない操作（設定の変更やデータの削除）を断るため、社内向けのアプリでも、要求の出どころ（ブラウザが付ける Sec-Fetch-Site という印）と宛先の名前（Host という印）を確かめます。Cookie（ブラウザがサイトごとに覚える情報）の送り方の制限や、画面ごとの合言葉といった、昔からある対策と組み合わせ、社内の開発のガイドラインに標準の作りとして書き込みます。
図の見方：上から順に、社内の道具への要求ごとに、誰からか、端末の状態、宛先が必要な範囲か、要求の出どころの4つを確かめます。すべて通ったものだけを許可し、1つでも違えば断って記録を残します。
個人の実験から見えたこと
個人の環境では、同じ機械で複数の道具を動かすと、ブラウザの印が番号（ポート）の違いを見ないため、別の道具からの要求まで「同じサイト」に見えました。組織でも、同じ名前の下に複数の社内アプリを置く構成では、同じことが起きます。「同じサイトなら通す」ではなく、「同じ画面から来たものだけを通す」形を標準にします。
小さく始めるなら：削除・設定変更・起動のような「変更を伴う操作」を持つ社内アプリを一覧にし、要求の出どころを確かめているかを点検するところから始めます。
APPROACH 5
開発や IT の部門が原因になる事故を防ぐには、開発の流れそのものに守りを組み込みます（DevSecOps＝開発・運用の流れにセキュリティを組み込む考え方）。とくに、作った仕組みやログから秘密が漏れる2次漏洩を、仕組みで防ぎます。
合言葉や API キーを、ソースコードや、共有されるファイルにそのまま書くことを、社内の規定で禁じます。本番の環境では、秘密の管理の専用の道具（例：HashiCorp Vault）や、クラウドの鍵の管理サービス（KMS）にまとめ、そこから取り出して使います。
SIEM（さまざまな記録を集めて、異常を見つける仕組み）や、エラーの監視の道具に、認証情報や個人情報がそのまま記録されることがあります。記録を集める前の段階で、値を自動で伏せる、または取り除く仕組みを入れます。守りのために集めた記録が、漏えいの元になっては本末転倒です。
開発の保管場所に対し、いまのコードだけでなく過去の変更の履歴も含めて、書き込まれた秘密や危険な関数（文字列をそのまま実行するものなど）を、自動の組み立ての中で検査します。履歴に入った秘密は、ファイルを消しても残ります。見つけたら、その秘密を無効にして作り直すところまでを、手順に含めます。
図の見方：上から順に、コードを書くとき、記録する前、自動の組み立ての中、本番での取り出し、ログを集める前、の各段階で秘密を守ります。どこかで秘密が見つかったら、消すだけでなく、無効にして作り直します。
小さく始めるなら：まずは、開発の保管場所の全体を、履歴まで含めて1回スキャンし、見つかった秘密を作り直すところから始めます。そのあとで、記録する前の検査を全員の環境に入れます。
ROADMAP
5つを一度に進める必要はありません。費用が小さく、効き目が大きいものから並べると、次の順番になります。最初の3つは、大きな製品を入れる前にでき、そのあとの判断の材料にもなります。
図の見方：上から順に、秘密の置き場所とスキャン、権限の一覧、AI に渡す文書の区分、既定は拒否と疑似攻撃の試験、社内アプリの要求の検証、と進めます。最後に、全体が働いているかを継続して確かめ続けます。
どの段階でも、「入れたか」ではなく「いま働いているか」を測ることが共通の軸です。仕組みは、設定の変更や組織の変化で、気づかないうちに効かなくなるからです。