⽣成 AI システムの セキュリティ対策 ~ ベストプラクティスと実践 ~ 2024.07.08 新規事業部 ⽣成 AI チーム ⻘柳 英明

ハッシュタグ #cm_odyssey 2 X (旧Twitter) への投稿、お願いします！ 登壇資料は後⽇ブログで公開します

⾃⼰紹介 3 青柳 英明 新規事業部 生成AIチーム ソリューションアーキテクト オンプレインフラエンジニア歴： 20年 2019.04～ クラスメソッド AWS事業本部 2019 AWS Samurai (JAWS-UG福岡支部) 2021 APN AWS Top Engineer 2024 Japan AWS All Certifications Engineer 2024.07～ 現職

本⽇お話しすること ‧⽣成 AI システムを構築∕利⽤する際の 基本的なセキュリティ対策の考え⽅ ‧暗号化 ‧ネットワーク ‧ID 管理∕アクセス制御 ‧⽣成 AI 観点からのセキュリティリスクと対策 4

⽣成 AI 利⽤時のセキュリティ懸念 情報漏洩‧盗聴 ‧ユーザーが⼊⼒したテキスト (質問内容に含まれている個⼈情報) ‧⽣成 AI が出⼒したテキスト (回答内容に含まれている機密情報) ‧RAG で使⽤する社内ドキュメント 5 不正アクセス ‧情報漏洩 ‧なりすまし 脆弱性を突いた攻撃 ‧サービス停⽌ ‧不正利⽤

典型的な⽣成 AI チャットアプリ 6

暗号化 7

暗号化 データ転送中の暗号化 データ保管時の暗号化 8

データ転送中の暗号化 クライアント 〜 アプリ間の通信： HTTPS ACM (AWS Certificate Manager) を使って無料で証明書を発⾏できる Route 53 を組み合わせることで独⾃ドメインでの HTTPS 運⽤も可能 9

データ転送中の暗号化 アプリ 〜 サービス間の通信： TLS デフォルトで TLS が使⽤される ‧Bedrock、S3、DynamoDB 等 設定により TLS を使⽤可能 ‧RDS、EFS 等 使⽤される TLS のバージョンに気をつける 現在の推奨は TLS 1.2 10

データ保管時の暗号化 LLM： ステートレスな API → データは保存しない ⽣成 AI アプリケーションにおいて保存されるデータ ‧会話履歴 ‧RAG (ベクトルデータベース、データソース) → 暗号化の検討の対象 11

データ保管時の暗号化 デフォルトで暗号化 ‧S3、DynamoDB、Kendra など デフォルトは⾮暗号化、設定により暗号化を有効にできる ‧RDS、EFS など 12

データ保管時の暗号化 KMS (Key Management Service) を使⽤して暗号化 ※ KMS キーの種類による暗号化強度の違いは無い 「データの重要度」「企業∕サービスのセキュリティポリシー」「コスト」 などを勘案して適切な種類を選択することが重要 13 AWS 所有キー (「デフォルト暗号化」とも) AWS 管理キー カスタマー管理キー キーの保管場所 AWS 管理アカウント 顧客アカウント 顧客管理アカウント キーの管理者 AWS AWS 顧客 キーの⾼度な管理 ✕ △ (⼀部のみ) ◯ 費⽤ 発⽣しない KMS の利⽤費 KMS の利⽤費

ネットワーク 14

ネットワーク領域の分類 15

オンプレミスと AWS の接続 VPN インターネット上にプライベートネットワークを構築 主⽬的： 暗号化されていない電⽂をインターネット経由で安全に通信 Direct Connect 専⽤線を⽤いてオンプレミスと AWS を直接接続 主⽬的： 不安定なインターネットを経由しないことによる帯域担保 16

「ネットワーク閉域化」の必要性 標準的なネットワーク構成でも、セキュリティは担保される クライアント〜アプリ間： ‧インターネットを経由するが HTTPS で暗号化されている アプリ〜サービス間： ‧AWS 内に閉じた通信であり、かつ、TLS による暗号化も⾏われる 閉域化を検討すべき場⾯： ‧企業∕システムのセキュリティポリシーで定められている ‧コスト (利⽤費、運⽤コスト) が増加しても強固なセキュリティが必要 17

ネットワーク閉域化の構成 18

ID 管理 ∕ アクセス制御 19

クライアント〜アプリのアクセス アプリケーションへアクセスするユーザーの認証を⾏い、 許可されたユーザーのみに利⽤を許可する 社内ユーザーの認証： SAML ベース ‧Active Directory (ADFS)、Entra ID、Google Workspace、etc. 社外ユーザーの認証： OpenID Connect ベース ‧Apple、Facebook、X、GitHub、etc. アプリケーションへのユーザー認証の実装 IAM Identity Center、Cognito、サードパーティ製ツールなどを使⽤ 20

アプリ〜サービスのアクセス IAM ロールを使う 21

IAM ロールのポリシー定義 ‧「AWS 管理ポリシー」は使わない (定義が⼤雑把すぎるため) ‧必要な権限を記述したカスタムポリシーを作成する ‧極⼒、アクション‧対象リソースを必要最⼩限に絞って記述 アプリ (ECS) に割り当てる IAM ロールのポリシー定義 (例) 22 "Action" : "bedrock:invokeModel" "Resource": "<基礎モデルのARN>" (※特に制限が不要であれば "*" でもよい) "Action" : "kendra:query" "Resource": "" "Action" : ["dynamodb:getItem", "dynamodb:putItem"] "Resource": ""

⽣成 AI のセキュリティ 23

⽣成 AI のセキュリティ OWASP Top 10 for Large Language Model Applications https://github.com/owasp-ja/Top10-for-LLM ‧01: Prompt Injection (プロンプトインジェクション) ‧02: Insecure Output Handling (安全が確認されていない出⼒ハンドリング) ‧03: Training Data Poisoning (訓練データの汚染) ‧04: Model Denial of Service (モデルのDoS) ‧05: Supply Chain Vulnerabilities (サプライチェーンの脆弱性) ‧06: Sensitive Information Disclosure (機微情報の漏えい) ‧07: Insecure Plugin Design (安全が確認されていないプラグイン設計) ‧08: Excessive Agency (過剰な代理⾏為) ‧09: Overreliance (過度の信頼) ‧10: Model Theft (モデルの盗難) 24

プロンプトインジェクション 悪意を持った者が LLM を意図的に誤動作させる指⽰を与え、 好ましくない内容を⽣成 AI に出⼒させる攻撃 (例) ‧犯罪⾏為に使うことができる情報を回答させる (ex. 爆弾の作り⽅) ‧個⼈情報、機密情報を聞き出す LLM 側で対策は⾏なっているものの、特定の指⽰の与え⽅をすることで 対処策をすり抜けて攻撃が⾏われることがある 25

プロンプトインジェクション プロンプトインジェクションを⽤いた攻撃⼿法： ‧攻撃者が LLM に対して直接プロンプトインジェクションを試みる ‧プロンプトインジェクションを含む情報 (ファイル、Webページ等) を ユーザーの⽬につく場所に置き、ユーザーが LLM へ指⽰を⾏うように 仕向ける (間接的な攻撃) (例) ⼀⾒普通の内容に⾒える Web ページだが、ユーザーがコピペして 「要約して」と指⽰するとプロンプトインジェクションが発動する 26

プロンプトインジェクション 対策 ‧システムプロンプトに「個⼈情報を出⼒しない」「有害な情報を出⼒ しない」等の指⽰を与える → 攻撃者はプロンプトインジェクションによってシステムプロンプト を無視するように仕向けるため、効果が無い場合もある ‧LLM への⼊⼒、LLM からの出⼒をチェックする → サードパーティ製ツール、Guardrails for Amazon Bedrock ‧最新バージョン∕最新リリースの LLM を利⽤する 27

⽣成 AI の出⼒の精査が不⼗分 LLM の出⼒を精査せずに利⽤したため引き起こされる問題 ‧LLM が出⼒したサンプルコードをシェルで実⾏した結果、 ファイルの誤削除など重篤な問題が発⽣してしまう ‧LLM が出⼒した HTML や JavaScript をブラウザが解釈した結果、 クロスサイトスクリプティング (XSS) が引き起こされてしまう 28

⽣成 AI の出⼒の精査が不⼗分 対策 ‧LLM が出⼒したコードは、必ず⼈の⼿でチェック∕レビューを⾏う ‧LLM の出⼒に対して検証やサニタイズを⾏う ‧LLM の出⼒をそのまま表⽰せずエンコード∕エスケープする → 検証やエンコードを⾏うようにプロンプトで指⽰を与えることも できるが、LLM は完全ではないため抜け漏れが発⽣することもある 後処理で⾏うのが確実 29

プラグイン‧エージェントのリスク 「プラグイン」 ⽣成 AI に「コマンドの実⾏」「API の呼び出し」「アプリとの連係」 などの機能を与えることによって、⽣成 AI の出⼒結果を⼈間が解釈 して作業を⾏う代わりに、⽣成 AI が⾏えるようにするもの 「エージェント」 与えられた指⽰を遂⾏するために必要なタスクを⽣成 AI が⾃ら考え、 必要に応じて API の呼び出しやアプリとの連係を⾏うことで⾃律的に 作業を⾏えるようにするもの 30

プラグイン‧エージェントのリスク 意図しない不正なパラメーターを受け付けてしまう ‧悪意のあるコードの実⾏、 SQL インジェクション ‧攻撃者が⽤意したコンテンツの注⼊や Web サイトへの誘導 意図しない操作の実⾏、意図しないデータへのアクセス ‧社内の重要なファイルやデータが削除されてしまう ‧個⼈情報や機密情報へのアクセス ‧システムファイルの削除や改竄 31

プラグイン‧エージェントのリスク 対策 ‧パラメーターの検証∕サニタイズを⾏う ‧パラメーターをエスケープ∕エンコードする ‧プラグインやエージェントに対して必要最⼩限の権限∕範囲を与える ‧データの参照のみが必要なエージェントに対して、書き込み権限を与えない ‧処理のために必要なデータ (DB、フォルダ) のみアクセスを許可する ‧⼈間によるチェック∕承認を⾏う ‧間違えることが許されない‧重⼤な処理を⾏うタイミング ‧⽣成 AI が提案する処理内容を提⽰して、⼈間が最終判断を⾏う 32

Guardrails for Amazon Bedrock LLM への⼊⼒‧LLM からの出⼒を精査して、 問題がある⼊出⼒を検出∕ブロックしてくれる機能 ‧「差別」「暴⼒」などが含まれる内容のフィルタリング ‧個⼈情報∕機密情報と判定される情報のフィルタリング ‧任意の単語∕フレーズによるフィルタリング Bedrock サービスと統合されており、シームレスなセキュリティ対策が可能 ※ ただし、現時点 (2024年7⽉) では⽇本語をサポートしておらず、 誤検出が発⽣したり、全く検出されないことがある 33

その他のセキュリティ対策 34

その他のセキュリティ対策 ロギング ‧AWS サービスやアプリのロギングを有効にする → インシデント発⽣時に追跡が⾏えるようにしておく シークレットの取り扱い ‧OpenAI の API Key など機微情報の取り扱いを厳密にする → アプリに直書きしない、Secrets Manager などを利⽤する GuardDuty、Security Hub などのセキュリティ対策サービスの活⽤ ‧⼈⼒による監視や対処は漏れや対応の遅れを⽣じさせる 35

おわりに 36

おわりに ‧「インフラ」「アプリ」「⽣成 AI 観点」の総合的な セキュリティ対策が重要 ‧初期導⼊時のセキュリティ対策だけで安⼼してはダメ 継続的なセキュリティのチェック、⾒直しが必要 そのために、セキュリティ対策の⾃動化サービスを活⽤ しましょう ご清聴、ありがとうございました 37

No content

No content