CASBは革新を止めずに外部AIプラットフォームを制御する方法

外部AIプラットフォームをイノベーションを殺さずに制御する方法

まずは問題から始めましょう。

人々がChatGPT、Claude、Canva、Midjourney、Gemini、またはその他のAIツールを使うのをやめる理由は、セキュリティインシデントを起こしたいからではありません。

ほとんどの場合、仕事を前に進めたいから使っています。

• 開発者は、エラーメッセージへの支援が欲しい。
• プロジェクトマネージャーは、散らかったドキュメントを要約したい。
• デザイナーは、素早いドラフトを作りたい。
• セキュリティエンジニアは、検知クエリの作成に手助けが欲しい。
• 運用チームのメンバーは、クラウドログやrunbookをより早く理解したい。

その行動はもっともです。

セキュリティ上の問題は、内部データがプロンプトと一緒に送られたときに始まります。

ユーザーは、顧客名、AWSのエラーログ、セキュリティアーキテクチャの抜粋、ソースコード、HRのコンテンツ、契約の詳細、Confluenceのポリシーなどを外部AIツールに貼り付けるかもしれません。そうなった時点で、組織はそのデータがどこで処理され、保持され、レビューされ、使われるのかをコントロールできなくなる可能性があります。

したがって、目標にすべきではないのは：

「どうやって全員がAIを使うのを止めるのか？」

より良い問いは：

「機密または制限されたデータが組織の外へ出るのを止めつつ、人々が安全にAIを使えるようにするにはどうすればいいのか？」

この部分で、CASB、Secure Web Gateway、DLP、セキュアブラウザの制御、そして強力な社内AIの代替手段が一体になります。

短いまとめ

CASBは、ユーザーとSaaSアプリの間に入り込むことで、外部AIプラットフォームを制御するのに役立ちます。セキュリティチームにAI利用の可視性を提供し、ユーザー、デバイス、アプリ、データ、アクションに基づいてポリシーを適用できるようにします。

たとえば：

ユーザーはChatGPT、Claude、Canva、Midjourney、または別のAI SaaSを使いたい
        |
        v
CASB / SWG / DLP / Secure Browser
        |
        |-- アプリを発見する
        |-- ユーザーとデバイスを特定する
        |-- プロンプト、アップロード、または貼り付けのアクティビティを検査する
        |-- データの分類を確認する
        |-- ポリシーを適用する
        v
許可 / 警告 / ブロック / コーチ / ログ / 例外ワークフロー

エンタープライズのRAG設計では、ここが重要です。** AWS Kendra と AWS Bedrock が承認済みの社内AIパスを守り*、一方で **CASB が管理されていない外部AIパスを制御する*のです。

両者は、同じ問題の異なる部分を解決します。

AIガバナンスのアーキテクチャにおけるCASBの位置づけ

前提として、組織には Amazon Kendra と Amazon Bedrock を使った社内AIアシスタントがすでにあるとします。

その社内アシスタントは、社内ナレッジのための安全な経路です：

社内ポリシー / runbook / クライアントプロジェクトの質問
        |
        v
承認済みの社内AIアシスタント
        |
        v
Amazon Kendra が認可されたコンテンツを取得する
        |
        v
Amazon Bedrock が根拠のある回答を生成する

しかし、ユーザーは外部AIツールを直接開くかもしれません：

ユーザー
  |
  | 内部コンテンツを外部AIに貼り付けようとする
  v
ChatGPT / Claude / Canva / Midjourney / その他のAI SaaS

その領域で必要になるのが、CASB、SWG、DLP、そしてセキュアブラウザの制御です：

ユーザー
  |
  v
CASB / SWG / DLP / Secure Browser
  |
  | 到達先、コンテンツ、アイデンティティ、デバイス、リスクを検査
  v
外部AIプラットフォーム

社内RAGプラットフォームは、ユーザーにとって社内の質問をするより良い場所を提供します。

CASBのレイヤーは、ユーザーが安全な経路を迂回して、機密データを管理されていないAIツールに貼り付けてしまう可能性を下げます。

CASBが実際に行うこと

CASBは抽象的な言い方で説明されることが多いので、ここでは単純にします。

外部AIプラットフォームに対して、CASBは次の5つの問いに答えるのに役立ちます：

1. 人々はどのAIツールを使っているのか？
2. 誰がそれを使っているのか？
3. どのデータを送っているのか？
4. このアクションは許可、警告、ブロック、コーチ、ログのどれにすべきか？
5. SOCまたはデータオーナーは何をレビューすべきか？

これにより、すべてのユーザーを悪意ある行為者のように扱わずに、セキュリティが実践的な制御ポイントを持てるようになります。

1. 外部AI利用の発見

何かをブロックする前に、可視性を確保します。

承認済みのAIポリシーができる前に、影のAI（シャドーAI）がすでに使われていることは、多くの組織でよくあります。それは正常です。最初の仕事は、何が起きているのかを理解することです。

CASBまたはSWGが特定するのに役立つのは以下です：

このフェーズが重要なのは、早すぎる強制ブロックが正当なワークフローを壊し、ユーザーを回避策に追いやってしまう可能性があるからです。

まずは可視性から始めます。次にポリシーを調整します。

2. AIプラットフォームを分類する

すべてのAIプラットフォームが同じリスクを持つわけではありません。

承認された条件がある契約済みのエンタープライズAIサービスは、未知のコンシューマ向けAIウェブサイトとは別物です。公開マーケティングコンテンツに使うデザインツールは、顧客データやソースコードを受け取るチャットボットとは別物です。

シンプルなAIアプリのレジストリを用意すると役立ちます：

これにより、ポリシーのバランスが保たれます。

ユーザーへのメッセージは次のようになります：

「適切な種類の作業には承認済みのAIツールを使ってください。社内データには社内アシスタントを使ってください。」

これは、「AI禁止」のような一律ポリシーよりも導入しやすいです。

3. プロンプト、アップロード、貼り付けられたコンテンツを検査する

これは中核となるデータセキュリティの制御です。

CASB、または統合型DLPエンジンは、ユーザーが外部AIプラットフォームに送信するコンテンツを検査する必要があります。

価値の高い検知は次のとおりです：

• AWSアクセスキー
• APIトークン
• プライベートキー
• パスワード
• ソースコード
• 顧客レコード
• 規制対象の個人データ
• HR、法務、または財務に関するコンテンツ
• 社内のアーキテクチャ図
• インシデント対応の詳細
• クライアント名またはプロジェクト名
• 機密（Confidential）または制限（Restricted）としてラベル付けされたドキュメント
• セキュリティポリシー、脆弱性レポート、ランブック
• （使用している場合）Google DriveまたはMicrosoft Purviewの感度ラベル

実用的なポリシーは、次のようになる可能性があります：

IF destination category = External AI
AND content contains AWS access key OR private key OR password
THEN block the action
AND alert the SOC
AND show the user safe guidance.

別のポリシー：

IF destination app = consumer AI
AND content classification = Confidential or Restricted
THEN block upload or paste
AND recommend the approved internal AI assistant.

ユーザー向けのメッセージは重要です。

悪いメッセージは次のように言います：

Blocked by security policy.

より良いメッセージは次のように言います：

This looks like internal or restricted information.
Please use the approved internal AI assistant for company policies, AWS runbooks,
client/project information, source code, or security procedures.

この種のメッセージはユーザーに学びを与え、安全な次のステップを提示します。

4. コンテキストに応じたポリシーを適用する

優れたCASBポリシーは、フラット（単一の基準）であってはなりません。

判断は、ユーザー、デバイス、アプリ、実行アクション、およびデータに依存するべきです。

ここに実用的なマトリクスがあります：

これにより、よくある2つの極端なケースを回避できます：

• 強制が難しいため、すべてを許可してしまう。
• すべてをブロックしてしまい、ユーザーを困らせる。

より良いアプローチは、リスクベースの制御です。

5. 正しいイベントをログに記録する

CASBのイベントはSIEMまたはSOARプラットフォームに取り込まれるべきです。

ただし重要な注意点があります：CASBまたはDLPシステムを、別の「機密データのリポジトリ」にしないでください。

調査に必要なイベント詳細はログに記録しますが、完全なプロンプトのキャプチャ、完全なファイルキャプチャ、機微な断片（スニペット）の取り扱いには注意してください。

有用なイベントには次が含まれます：

SOCの検知例：

IF user has 3 or more blocked AI DLP events in 24 hours
THEN create a SOC case for review.

別の例：

IF user attempts to paste an AWS secret, private key, password, or customer export
into an external AI platform
THEN create a high-severity DLP incident.

すべてのイベントが悪意あるものとは限りません。

制御が機能し、ユーザーにガイダンスが必要な場合もあります。このSOCプロセスは、偶発的な誤用と、繰り返されるまたは疑わしい行動を切り分けるべきです。

推奨されるロールアウト計画

初日から最も厳しいポリシーで開始しないでください。

段階的なロールアウトのほうが、安全で、事業側が受け入れやすいです。

フェーズ1：可視化のみ

ディスカバリーとログ記録を有効化します。

まだブロックは行いません。

目標：

• どのAIアプリが利用されているかを特定する；
• 高リスクな部門または利用ケースを特定する；
• 正当なワークフローを理解する；
• 承認済みのAIアプリ登録簿を作成する；
• カテゴリとラベルを調整する；

一般的な可視化フェーズは2〜4週間程度実施されることがあります。

フェーズ2：警告とコーチング

承認されていないAIツールを訪問したとき、または機微の可能性があるコンテンツを貼り付けたときに、ユーザーへの警告を開始します。

警告例：

You are using an external AI tool.
Do not enter client data, internal security designs, credentials, source code,
HR/legal data, or restricted information.
Use the approved internal AI assistant for internal content.

このフェーズでは、強制的な取り締まりが始まる前にユーザーが調整する機会を与えます。

フェーズ3：確度の高い機微データをブロックする

誤検知のリスクが低い検知から開始します：

• AWSアクセスキー
• プライベートキー
• パスワード
• APIトークン
• 規制対象の識別子
• 「制限（Restricted）」としてラベル付けされたファイル
• 顧客のエクスポート
• 既知の機密プロジェクトまたはクライアントの用語

あいまいな「社内データ」パターンをあちこちでブロックし始めないでください。それはノイズとユーザーの不満を生みます。

フェーズ4：AIアプリのガバナンスを強制する

アプリのカテゴリごとに異なるルールを適用します。

フェーズ5：実際の例外ワークフローを追加する

外部AIを利用するための正当な業務上の理由を持つユーザーもいます。

それは問題ありませんが、例外には制御が必要です。

優れた例外処理プロセスには、以下が含まれます：

1. ユーザーがリクエストを送信する；
2. 事業オーナーが必要性を確認する；
3. データオーナーがデータ型を確認する；
4. セキュリティがリスクをレビューする；
5. 法務／プライバシーがベンダーの利用規約をレビューする；
6. 例外は、ユーザー、アプリ、データ、時間によってスコープされる；
7. アクセスは自動的に期限切れになる；
8. 利用状況がログに記録される。

恒久的で広範な例外は避けてください。

それらは、誰もが忘れてしまう「穴」になりがちです。

CASB と AI セキュリティソリューションで考慮すべきこと

適切なツールは、組織のスタック、ライセンシング、トラフィックのルーティングモデル、DLP の成熟度、エンドポイント戦略によって異なります。ポイントは、最も人気のあるツールを買うことではありません。ポイントは、関心のある AI トラフィックを「実際に可視化して、強制できる」コントロールプレーンを選ぶことです。

以下は、評価するための実用的な選択肢です。

実用的な選定ルール：

ユーザーが実際に作業している場所でポリシーを強制できるプラットフォームを選ぶ：ブラウザ、エンドポイント、ネットワーク、SaaS API、モバイル、または上記すべて。

CASB が社内 RAG アシスタントに接続する方法

ここが重要なアーキテクチャ上のポイントです。

CASB は、社内 RAG の代替として位置づけるべきではありません。社内 RAG は、CASB の代替として位置づけるべきではありません。

両者は連携して機能します。

ビジネスに伝えるべき、明確なメッセージは次のとおりです：

私たちは AI をブロックしません。安全な社内 AI の選択肢を提供し、外部の AI ツールに送ってよいデータを制御します。

これは、はるかに良い議論になります。

例：制御の判断例

ポリシーを実際のものにする、シンプルな例を示します。

例 1：開発者が AWS のエラーを ChatGPT に貼り付ける

エラーにシークレット、顧客データ、または社内のアーキテクチャが含まれていない場合：

判断：警告または許可。
理由：低リスクのトラブルシューティングであれば、承認済みのツールで許容できる可能性があります。

エラーに AWS のアクセスキー、クライアントに紐づくアカウント ID、社内ホスト名、または本番ログの抜粋が含まれる場合：

判断：ブロックし、社内アシスタントまたは承認済みのエンジニアリングツールにルーティング。
理由：機密性の高いクラウド情報や、クライアント／プロジェクト情報が組織の外部に出てしまう可能性があります。

例 2：セキュリティエンジニアが incident notes（インシデントのメモ）を Claude に貼り付ける

判断：ブロック。
理由：インシデントのメモには、指標（indicator）、影響を受けたシステム、ユーザーの詳細、クライアント情報、または法務／プライバシーに関わる機微な事実が含まれる可能性があります。

より良い手順：

承認済みの社内 RAG アシスタント、または承認済みのインシデント対応ワークスペースを使用します。

例 3：マーケティングが Canva で一般向けバナーを作る

判断：許可。
理由：承認済みのデザインワークフローにおける公開用マーケティングコンテンツは、通常は許容可能です。

例 4：人事が従業員記録を外部の AI 要約サービスにアップロードする

判断：正式に承認されたベンダーとユースケースが存在しない限りブロック。
理由：人事データは機微であり、通常は法務／プライバシーのレビューが必要です。

よくある失敗として避けるべきこと

失敗 1：代替手段を用意せずに AI をブロックする

これは通常、シャドー AI を生みます。

人はやはり助けを必要とします。承認済みの手順が遅すぎると、より速い手段を探し出します。

失敗 2：ポリシーだけに頼る

ポリシーは重要ですが、ポリシーだけではコピペを止められません。

制御は、ユーザーが実際に AI ツールとやり取りしている場所に存在する必要があります。

第3のミス：どこでも全文のプロンプトやファイルをログに記録する

プロンプトデータは機密性が高い場合があります。

CASBおよびDLPの証拠は保護し、必要な期間だけ保持し、承認されたセキュリティ担当者またはデータ保護担当者にのみアクセス可能にしてください。

第4のミス：広すぎる例外を作る

「エンジニアリングは任意のAIツールを使ってよい」という恒久的な例外は、統制（コントロール）ではありません。

例外は、対象範囲を絞り、期限を設け、見直しを行うべきです。

第5のミス：すべてのAIツールを同じものとして扱う

契約しているエンタープライズ向けAIプラットフォーム、一般公開のチャットボット、正体不明のブラウザ拡張機能では、同じリスクを伴いません。

ツールを分類し、異なるルールを適用してください。

良い状態とは何か

良い実装は、ユーザーにとって実用的で、セキュリティにとって有益だと感じられるものです。

ユーザーには次が見えます：

• 承認済みのAIツール；
• 明確なガイダンス；
• 役に立つ警告；
• 社内データのための安全な内部アシスタント；
• 迅速な例外処理。

セキュリティには次が見えます：

• どのAIツールが使われているか；
• どのデータ移動がリスクか；
• どのアクションがブロックまたは警告されたか；
• どのユーザーに指導（コーチング）が必要か；
• どのベンダーを見直す必要があるか；
• どの検知をチューニングする必要があるか。

経営層には次が見えます：

• データ漏えいリスクの低減；
• より良いAI導入のガバナンス；
• 監査の証拠；
• 管理されていないAIの業務フローの削減；
• イノベーションのためのより安全な道筋。

それが私たちが望む成果です。

推奨される運用モデル

これは官僚的である必要はありません。

ユーザーがどこへ行けばよいかが分かり、セキュリティが何を監視すべきかが分かり、データオーナーが自分の承認の役割を理解できる程度に、明確である必要があります。

最終推奨

外部のAIプラットフォームはCASBで制御しますが、ユーザーを妨げるのではなくユーザーを助ける形で行ってください。

実務的なモデルは次のとおりです：

社内データの質問 -> 承認済みの内部RAGアシスタント
外部AIアクセス -> CASB/SWG/DLPで検査
公開データまたは承認済みデータ -> 許可
リスクのある行動 -> 警告し、コーチング
機密または制限付きデータ -> ブロック
繰り返し、または重大な事象 -> SOC/SOARのケース
正当な業務上の必要性 -> 期限付きの例外

これがバランスの取れたエンタープライズとしてのアプローチです。

私たちは人々がAIの恩恵を受けられるようにします。

私たちは、社内の知識のための安全な内部ルートを提供します。

そして、機密や制限付きデータが管理されていないツールに貼り付けられることを止めます。

さらに、時間の経過とともにプログラムを改善できるだけの可視性とガバナンスを構築します。

目的はAIを難しくすることではありません。

目的は、安全な道筋を最も簡単な道筋にすることです。