生成AIからの情報漏洩対策、してますか？
AIから個人情報的なものが漏れてしまって企業として大打撃を受けることを避けたい・・・という話、多いと思います。
本記事では、リスクの整理とその対策を検討していきます。
まずはどんなリスクがあるのかを考える
よくお聞きする話としては、以下のようなものがあります。
①入力からの情報漏洩
- 従業員が生成AIに重要なデータを入力し、それがAI側で学習されてしまうリスク
(その後、AIがそのデータを他者へのレスポンスとして利用してしまうことで情報漏洩となる)
②出力からの情報漏洩 - 従業員が生成AIに重要なデータの出力を促すようなリクエストをし、実際の出力内にそのデータが含まれてしまう
③AI利用のためのキー(会社にて発行)の漏洩
他にもありますが、ひとまずこの３つについて考えていきます。
対策の方針を考える
基本方針として、大きく分けると「社内ルールを作り」「それを従業員に徹底させる」と言う2ステップが必要だという点です。
まずは「どの情報が出たらマズいか」といったルールが必要です。その上で、それを徹底させる仕組みが必要です。
今回考えていくのは後者の「徹底させる仕組み」の方です。
ルールを作ったとしても従業員がそれを守らなければ意味がありません。
しかし従業員全体に対してルールを徹底させることの難しさはハンパではありません。
なので、ルールを強制させるツールこそがガバナンスを確立するためのポイントになります。
①入力からの情報漏洩
これ１つをとっても、複数の観点や防ぎ方があります。
例えば以下のような、ツールという点で考えてみます。
・企業で契約しているAIから
・個人でこっそり利用しているAIから（シャドーAI）
前者の場合、基本的には学習Offになっていることが多いので心配は小さいでしょう。
しかし、後者の場合は基本的にOnになっているため、リスクは大きくなります。
他にもデータ的な観点で言うと
・個人情報（氏名、電話番号、住所、マイナンバーなど）
・企業特有の情報（顧客リスト、ソースコードなど）
と言う分類もアリでしょう。
この場合、正規表現で表せることができるもの(電話番号やマイナンバー、場合によっては顧客リストなど)と、難しいもの（氏名やソースコードなど）に分かれてきます。
①の対策を考える
上記を踏まえて、対策を考えていきます。
ここで出てくるのが、タイトルにあるようなCASBやSASE, AI Gateway(以下、AIGW)といったツール(ソリューション)達です。
CASB ... Cloud Access Security Broker. SASEの機能の一部として提供されることが多い。生成AIを含むクラウド全体への情報漏洩対策を実現
SASE ... Secure Access Service Edge. CASBやSWG, FireWallなどの機能を含んだもの
AIGW ... 開発者やユーザー、AIエージェントなどが生成AIにアクセスする際に通り、ここで様々なポリシーをつけることができる
シンプルになんでもかんでもAIGWで解決！などと言いたいところなのですがそう簡単にはいきません。
AIGWは「明示的に」利用者からAIGWを指定し、アクセスする必要があります。
そのため、従業員が勝手に利用するシャドーITに対しては効果が薄いと言う特徴があります。
企業管理のAIを使いやすくすることで間接的にシャドーAIの利用を減らす助けをすることはできますが「それでも個人契約したchatGPTを使いたい！」と言うような場合にはAIGWの出番ではありません。
では、どんな時にどのソリューションが有効で、どんなことができるのかを整理していきましょう。
こちらの図が、通信の絵です。
ちなみに条件を揃えるためにPCからの通信を例にとっていますが、SASEとAIGWを比較すると、そもそも観点が違います。
SASEは、基本的にはユーザー(従業員)を対象にしたものです。
サーバーなどに対して適用することもできますが、あまり多いユースケースではありません。
対してAIGWは「AIのモデルのAPI通信」に対して効くためユーザー、AIエージェント、その他のアプリにも適用可能です。
例えば「チャットボットのアプリがAIにアクセスする際に情報漏洩対策する」というような使い方ができます。
SASE(の中のCASB機能)の場合は基本的にフォワードプロキシとして機能します。他にもリバプロ型やAPI型などいろんな形がありますがここでは説明しません。
個人的にはSASEの中ではNetskopeが好きなのでここではNetskopeの動作を参考に考えます。
フォワードプロキシとして動作する場合はPCにエージェントを入れる方法が多いです。
するとPCとSASEの間にトンネルが張られ、その中をWebサイトやクラウドへの通信が通るようになります。
そのため、従業員が個人契約やフリーのchatGPTやGeminiなどを使おうとすると、その通信もSASEを通る = シャドーIT、シャドーAIの発見や制御ができるようになります。
SASEのエージェントには証明書も含まれており、その証明書でデータを暗号化して通信先であるSASE側で復号します。復号して何ができるかというと
・インスタンスの識別
・DLP(Data Loss Prevention)の適用
などです。
インスタンス(個人契約か法人契約かなど)はそもそもアクセスするドメインで識別可能な場合もありますが、ドメインが同じ場合でも復号して通信内容を見ることで確認できる場合があります。この辺り何ができるかはアクセス先のものの仕様によります。
また、DLPにより「通信の中にマイナンバーが含まれている場合には止める」と言うようなことができます。
なので「シャドーAIからの情報漏洩が怖い！」と言う場合には
・SASEでシャドーAIをそもそも使わせない
・シャドーAIを使わせつつも、通信にはDLPをかけて情報漏洩を防ぐ
ようなことができます。
ではAIGWについて考えてみましょう。
AIGWではKongが一番好きなのでKong AIGWを例にとって考えます。
前述の通りシャドーAIについてはSASEで保護すべきところでしょう。しかし、企業契約のAIについてはどのように情報漏洩対策をしていくべきでしょうか。
以下がKong のAIGWで適用できるプラグイン(ポリシー)の一覧です。
https://developer.konghq.com/plugins/?category=ai
この中DLP的なところで言うと、AI PII Sanitizer, AI AWS GuardRails, AI Azure Content Safety, AI GCP Model Armorなどのプラグインになります。
AI PII SanitizerはAIGWの横にdockerなどでSanizize用のサービスを展開し、そちらで重要情報の識別をします。
そのほかのIaaSの名前がついているプラグインは、実際にそのサービスを利用してリクエストとレスポンスの中身の検査をする仕組みです。
基本的にSASEはそれぞれが持っているDLPエンジンを利用することが多いので、この仕組みの違いはSASEとAIGWの差異になります。
例えばAWSを利用していて、すでにGuardRailを使っている場合には、運用などの面でAWS GuardRailを生成AIの情報漏洩対策としても使いたいという方は多いかと思います。
また、セキュリティポリシー上の理由から「重要情報の検知やマスキングはオンプレで完結したい」と言う場合にはPII Sanitizerが利用可能です。
SASEにおいても企業契約AIに対してのDLPはできます。
しかしAIGWの選択肢の広さを考えると、SASEの情報漏洩対策は網羅的である(シャドーITなどにも効く)一方で、AIGWの方がより柔軟であると言えそうです。
②出力からの情報漏洩
例えばRAGなどにより、意図的せず(または悪意を持って)従業員がAIを通して社内の情報に触れやすくなってきているかと思います。
極端な例を言うと、従業員AがAIを通し、本来見てはいけない従業員Bの個人情報や会社の機密事項に触れる可能性もあると思います。
権限管理が完璧ならば起こりにくいとは思いますが、どうしてもミスがあり得る以上は情報漏洩の対策をいくつか用意しておきたいのではないでしょうか。
②の対策を考える
権限管理以外でもいくつか対策があると思いますが、例えば以下のようなものが考えられます。
・レスポンスの内容を検査する
・リクエストに「生年月日や住所などは含めない」とうような内容を盛り込む
前者はリクエストの検査と同様のことを、レスポンスに対してやるだけです。AIGWではそれができますし、SASEでもできるものはあると思います。
後者はAIGW特有の発想です。例えばKong AIGWの場合には「AI Prompt Decorator」があります。
これはリクエストがAIGWを通った時にプロンプトを追加する機能です。
こちらを利用し、先ほど書いたような「生年月日や住所などは含めない」と言うようなプロンプトを追加することでレスポンスに影響を及ぼすことが可能です。
③AI利用のためのキーの漏洩
例えばOpenAIなどは、契約すると利用するためのキーが発行されます。
これが流出した場合には誰でもその企業の契約したchatGPTなどを利用できると言うことになります。
トークンを利用されてしまうような攻撃に晒される可能性がありますし、先ほどの出力の例のように、社内のデータが漏れてしまう可能性もあります。
③の対応を考える
これはSASEでの実装は難しいところだと思いますが、AIGWであれば対応可能です。
セキュリティと言う面でいうと、Kong AIGWではこちらの図のように様々なことができます。
まずは図の左上のように認証をキーではなく、IdPなどを利用したものなど、強固かつ柔軟なものに切り替えることができます。
次に、その認証を通ったものだけがAIGWの層を通る際にキーを埋め込む形にします。
これにより、キーをユーザーなどに配布することなくAIGWで一元管理することでキー流出のリスクを最小限にすることができます。
その他の観点
セキュリティという枠からは外れますが以下の図のようにAI利用で問題になりがちなコストに対してのガバナンスを効かせる(流量制限によるトークン量・コスト制御)ことや、キャッシュにより似たようなリクエストに対して、高速かつトークン量を抑えてAIGWからレスポンスをすることなどができます。
まとめ
「シャドーAIを含み、従業員を対象とし、DLPを中心とした情報漏洩対策」ならばSASEが良いと思います。
企業契約のAI、かつ従業員だけではなくAIエージェントやアプリも対象とし、プロンプトの追加や変更といった柔軟な制御が必要な場合はAIGWの方が適していると思います。
セキュリティに加えてコスト・流量の制御などもAIGWの得意分野です。
「情報漏洩対策」といっても色々と観点と対策があります。
社内ルールの作成と従業員への周知といった前提があった上で、そのルールを強制することができるソリューションとして、SASEとAIGWの説明をしました。
この２つのできることの違いが何となく伝われば幸いです。