生成AI活用で高まるセキュリティリスクからデータセキュリティ技術で機密データを守ります! - db tech showcase 2024参加レポート
PostgreSQLインサイド


柴垣 向志
富士通株式会社
ソフトウェアオープンイノベーション事業本部 データマネジメント事業部
専門分野
- データベース
2022年からPostgreSQLをベースにしたデータベース「Fujitsu Enterprise Postgres」の開発業務に従事
はじめに
2024年7月11日、12日に開催されたdb tech showcase 2024に参加しました。
db tech showcaseは、データに関わるすべての技術者に「学び」「気づき」「変化」を提供する、国内最大規模のデータとデータベース関連のカンファレンスです。2011年の開催以来、国内外のデータベースの革新的な技術や最新事例が紹介され、今回が13回目となりました。近年では生成AIに関連した技術が注目を集めています。
今回私は、生成AIのビジネス活用が進む中で注目されている「生成AIでの自社データの活用」におけるセキュリティリスクと対策について講演しました。この記事ではその内容を中心に紹介します。
図1:会場となったTKP市ヶ谷カンファレンスセンター(東京都新宿区)
講演内容:生成AIで自社データを活用する場合のセキュリティ対策
従来の生成AIは、誰もがアクセスできる公開データを元に開発されてきました。最新の動向では、企業が持つ自社データも活用することにより業種や分野に特化した生成AIの利用が増えています。しかし、自社データの活用にはセキュリティリスクが伴います。私は講演で、RAG(Retrieval-Augmented Generation:検索拡張生成)を導入し生成AIで自社データを活用する際に高まる3つのセキュリティリスクとそれらへの対策について解説しました。
図2:講演の様子
この記事では講演を元に以下の流れで説明します。
- RAG(Retrieval-Augmented Generation:検索拡張生成)とは
- 自社データを管理するベクトルデータベースのアクセス権設定誤り
- 生成AIへの悪意ある質問による自社データの漏洩
- 自社データ改ざんによる誤った回答の生成
RAG(Retrieval-Augmented Generation:検索拡張生成)とは
RAGとは、LLM(Large Language Models:大規模言語モデル)が生成する回答の精度を高める技術です。LLMに質問と質問の意味に近いデータを一緒に渡すことで、回答精度を向上させます。これにより、LLMが不得意とする最新の情報に基づいた回答・特定の業務や分野に特化した質問への回答が可能となります。質問の意味に近いデータはあらかじめベクトルデータに変換されてベクトルデータベースに格納されており、生成AIツールはそこから質問に関連する自社データを検索します。そして返却された検索結果と質問をLLMに渡し、回答を取得してユーザーに回答します。
図3:生成AI+RAG
近年、RAGが自社データを生成AIで活用するための技術として注目されています。しかし、機密情報を含む自社データを生成AIで活用する場合、セキュリティリスクに気を付ける必要があります。代表的なものを以下に示します。
- 自社データを管理するベクトルデータベースのアクセス権設定誤りによる情報漏洩
- 生成AIへの悪意ある質問による自社データの漏洩
- 自社データ改ざんによる誤った回答の生成
これらのリスクに対し、生成AIツール・データベースそれぞれで必要となる対策を下図に示します。
図4:3つのセキュリティリスクとそれらへの対策(講演資料より)
以降では、各セキュリティリスクの詳細と生成AIツールによる従来の対策における課題、およびデータベースによる課題解決について解説します。
自社データを管理するベクトルデータベースのアクセス権設定誤りによる情報漏洩
自社データを生成AIで活用する場合には、すでにある自社データのアクセス権を見直す必要があります。生成AIの効果を最大限発揮するために、利用者がアクセスできるデータの範囲を最大限広げ、質問に関連する自社データを検索できる可能性を上げる必要があるからです。そのため従来、特定の部門しかアクセスできなかった自社データに対して他の部署や組織外からのアクセスを可能にする必要が生じます。
このときアクセス権の再設計・再設定が必要となりますが、それには膨大な労力が必要となります。同じコンテンツであったとしてもデータごとにアクセス権を変える必要があるためです。よりきめ細かなアクセス権を設定することになるので、利用者とデータの組み合わせが膨大となりアクセス権の設計・設定が複雑化します。これにより設計・設定ミスが発生しやすくなり、情報漏洩につながってしまいます。
図5:複雑化するアクセス権の設定(講演資料より)
生成AIツール側でこのようなきめ細かなアクセス制御の仕組みを実装する場合、常にアクセス制御を踏まえてアプリケーション開発を行う必要があります。そのため脆弱性を作りこまないようにするには、アプリケーションの開発・改修に膨大なコストが必要となります。生成AIツールの開発は用途ごとに行われ、短いサイクルで頻繁に改善する必要があるため、この影響はさらに深刻です。
データベースによる対策
一方、データベース側でアクセス制御を実装する場合、ユーザーがデータにアクセス可能かどうかの判断はデータベースが担うため、生成AIツールのプログラム側ではデータベースへの問い合わせをするだけでよくなります。これにより、強固なセキュリティ実現のための開発・改修コストを大幅に削減できます。
図6:ベクトルデータベースのアクセス権設定誤りによる情報漏洩への対策
富士通のデータベース「Fujitsu Enterprise Postgres(以降、Enterprise Postgres)」の機能である「機密管理支援機能」を使用し、各データに対して機密レベルを付与して分類することでデータの分類に対してアクセス権を定義し管理を簡単に行うことができます。詳細は以下をご覧ください。
生成AIへの悪意ある質問による自社データの漏洩
RAGを導入した場合、プロンプトインジェクションによりベクトルデータベース内のデータが漏洩するリスクが生じます。
プロンプトインジェクションとは、悪意のある質問を入力し、LLMに命令することで開発者が想定していない情報を生成させる攻撃です。RAGの場合、ユーザーからの質問と検索結果と生成AIツールで追加される命令を併せてLLMに命令します。通常、検索結果はLLMが回答を生成するために使用されユーザーには表示されませんが、検索結果をそのまま出力させるような質問が入力された場合には、ベクトルデータベースからの検索結果をユーザーに表示してしまいます。
図7:プロンプトインジェクションによる情報漏洩の例
生成AIツール側では、あらかじめ作成した検出ルールに基づいて悪意のある質問を検出し、悪意のある命令が実行されるのを阻止します。しかし、質問文の自由度が高いため、ルールベースの検証では、情報漏洩を防ぎきることはできません。
データベースによる対策
最も安全な方法は、ユーザーに表示してはいけない情報を、見えない状態に秘匿化・匿名化してからLLMに渡すことです。データベース側で回答精度に寄与する情報は匿名化、寄与しない情報は秘匿化することで、万が一データが流出した場合でも、情報漏洩を防止できます。
図8:データベース側の対策 ー 秘匿化・匿名化
Enterprise Postgresにも、秘匿化機能があります。参照するユーザーによってデータを見せる・見せないを設定できます。詳細は以下をご覧ください。
自社データ改ざんによる誤った回答の作成
ベクトルデータベース内のデータが改ざんされた場合、誤った情報が関連情報としてLLMに渡されるため、誤った回答が生成されます。これをPoisonedRAGと言います。
生成AIツール側では、複数の検索結果から複数の出力を生成し、これらを集約することで誤った回答を防ぐことができます。
図9:生成AIツール側の対策 ー 複数の回答を集約し誤った回答を防止
しかし、検索結果が少ない場合や改ざんデータが多い場合、誤った回答を防ぐことができません。そのため改ざん自体を防ぐ対策が重要です。
データベースによる対策
データベース側で不正アクセスの防止、改ざん検知、および監査ログによる対策を行うことで、改ざん自体の防止や、もし改ざんされたとしても誤回答を防止し、改ざんされたデータを復旧できます。
パスワードでの認証を行う場合は、パスワードの作成、管理、使用に関するルールであるパスワードポリシーを定め、ユーザーに遵守させることでより不正アクセスを防止することができます。Enterprise Postgresには、これを実現するための機能「ポリシーに基づくパスワード運用」があります。詳細は以下をご覧ください。
万が一不正アクセスされデータを改ざんされた場合に備えて、改ざん検知や監査ログを使用した対策が必要です。
Enterprise Postgresは、Scalar社が提供するミドルウェア製品であるScalarDLと連携することで、ベクトルデータベースの検索時に改ざんを検知することが可能になります。これにより万が一データが改ざんされた場合でも、改ざんされたデータを参照した際にエラーが発生し、関連情報として検索することができなくなります。改ざんされたデータが生成AIツール側へと流れ込むことがなくなるため、データ改ざんによる誤った回答を確実に防止することができます。詳細は以下をご覧ください。
また検知後の対応としては、監査ログを使用して改ざんの影響範囲を特定し、復旧する必要があります。影響範囲を特定するため重要となるのは、「いつ」、「誰が」、「どこから」、「なにに対して」「どのような処理」を行ったかという詳細な情報です。そのため監査ログには、日付、時間、コネクション情報、スキーマ情報、SQL実行結果などを詳細に記録する必要があります。それらの情報により影響範囲を特定したあと、あらかじめ取得していたバックアップデータを使用してリストアなどの対応を行うことでデータベースを復旧します。
図10:データベース側の対策 ー 改ざん検知、監査ログ
監査ログについての詳細は以下をご覧ください。
おわりに
本講演では、RAGを導入し生成AIで自社データを活用する際に高まる3つのセキュリティリスクについて、データベースでの対策の重要性を解説しました。各セキュリティリスクの対策として生成AIツール側でも様々な対策技術が研究されていますが、まだ課題はあります。機密情報である自社データを守るためには、機密情報を格納しているデータベース側で根本的な対策を実施する必要があります。弊社のデータベースEnterprise Postgresを使用すると、それらの対策を簡単に導入・運用することができます。データセキュリティを損なうことなく自社データを安全に活用するために、Enterprise Postgresの利用をご検討ください。
関連リンク
2024年8月27日公開
富士通のソフトウェア公式チャンネル(YouTube)
-
- 富士通のミドルウェア製品のご紹介や各種イベント・セミナーの講演内容、デモンストレーションなどの動画をご覧いただけます。
- 富士通のミドルウェア製品のご紹介や各種イベント・セミナーの講演内容、デモンストレーションなどの動画をご覧いただけます。
PostgreSQLについてより深く知る
PostgreSQLに興味をお持ちのお客様はこちらのコンテンツもお勧めです。ぜひご覧ください。
本コンテンツに関するお問い合わせ
お電話でのお問い合わせ
-
富士通コンタクトライン(総合窓口)
0120-933-200受付時間:9時~12時および13時~17時30分(土曜日・日曜日・祝日・当社指定の休業日を除く)