TechTargetは、「MLSecOps」に関する記事を公開した。MLSecOpsのベストプラクティスに従うことで、セキュリティに考慮したAI開発が可能になる。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
TechTargetは2024年1月30日(米国時間)、「MLSecOps」に関する記事を公開した。
近年、組織は、基本的な機械学習モデルから「ChatGPT」のような生成AI(人工知能)に至るまで、新しいAIテクノロジーをビジネスプロセスに統合しようと、急速に動き始めている。AI導入はビジネスに多くのメリットをもたらす一方、攻撃対象領域(アタックサーフェス)が広がるという懸念もある。
攻撃者はターゲットのIT環境へ侵入する方法を常に探しており、AIを利用したツールは彼らの新たな侵入ポイントになる可能性がある。そのため、企業データを不正アクセスから守るための「AIセキュリティ戦略」が不可欠となる。そこで注目したいのが「MLSecOps」だ。
MLSecOpsは、運用における機械学習(Machine Learning:ML)の知見とセキュリティ上の懸念をまとめたフレームワークで、AI/MLモデルが組織にもたらすリスクの軽減を目的としている。具体的には、MLモデルの開発とトレーニングに使用されるデータのセキュリティ保護、それらのモデルに対する敵対的攻撃の軽減、開発されたモデルが規制コンプライアンスフレームワークに準拠していることを確認する、といったことに重きを置いている。
本稿では、組織へのAI導入において懸念されるリスクをMLSecOpsでどのように解決するかについて解説する。
MLモデルは、反復的なタスクを自動化し、顧客サービスを向上させ、運用コストを削減し、競争上の優位性を維持することで、組織の効率を向上させることができる。一方、MLモデルを採用する場合(特にオープンソースの大規模言語モデル<LLM>を使用する場合)、開発およびデプロイフェーズを含むさまざまな点でリスクをもたらす。
重大なリスクには以下のようなものがある。
トレーニングに使用したデータが偏っており、偏向した結果が出力される可能性がある。
AIツールは多くの場合、トレーニングに膨大な量のデータを必要とする。だが、データの所有者全てがAIトレーニングでの使用に同意したかどうかが不明瞭なことがある。例えば、AIコーディングツールは、「GitHub」リポジトリにあるソフトウェアプロジェクトのコードスニペットでトレーニングされているかもしれない。そしてトレーニングに使われたコードにはアカウントの資格情報などの機密情報が含まれている可能性がある。
LLMに悪意のあるコードを挿入してユーザーの意図しない動作をさせたり、不正確な結果を生成させたりしようとする開発者がいるかもしれない。こうした“侵害されたLLM”を使うとさまざまなリスクを抱えることになる。例えばマルウェアスキャナーでそういったLLMを使うと、特定のマルウェアを「良性」と誤判定する可能性がある。
多くのLLMは、プラグインを使うことでさまざまな形式(自由形式)でテキストを受け取ることができる。だが、悪意を持って作成されたテキストによって、悪意のあるコードがリモートで実行され、特権昇格攻撃が発生する可能性がある。
多くのベンダーは、AIツールにサードパーティーベンダーの事前学習済みモデルを使用している。そうしたモデルの中には「バックドア」など組織のサプライチェーン内への不正アクセスを容易にするセキュリティ上の欠陥が仕込まれているものがあるかもしれない。
AIツールは、MLモデルへのアクセスを容易にするため、ホスティング用サーバやネットワーキングデバイスなどのコンピューティングインフラを必要とする。そこに目を付ける攻撃者もいる。MLモデルが展開されているインフラに侵入した攻撃者は、パフォーマンスや可用性に影響する「モデル抽出」「サービス拒否攻撃」などでAIのサービスを止めようとする可能性がある。
「MLOps」とは、「実稼働環境でMLモデルを運用化するプロセス」のことで、幾つかのフェーズで構成されている。
MLSecOpsはこのMLOpsの延長線上にある。DevOpsがソフトウェア開発ライフサイクルにセキュリティプラクティスを統合することでDevSecOpsに進化したように、MLSecOpsはMLモデルが、セキュリティのベストプラクティスを用いて開発、テスト、デプロイ、モニタリングされることを保証する。
MLSecOpsは、MLモデル開発プロセス全体にわたってセキュリティプラクティスを統合する。この統合によって、以下の2つの領域でMLモデルのセキュリティを確保できる。
MLSecOpsは、MLを使ったシステムに関連するセキュリティ問題に焦点を当てている。MLSecOpsが取り組む、セキュリティは以下の5つだ。
他のソフトウェアと同様、MLシステムはさまざまなサードパーティー製のコンポーネントやサービスを頻繁に使用しており、構成されるサプライチェーンは複雑なものになっている。MLシステムのサプライチェーンにセキュリティの脆弱性があると、そこから攻撃者が侵入し、さまざまな悪意のあるアクションを実行する可能性がある。
MLシステムの典型的なサプライチェーン要素には、以下のものがある。
(筆者の考えでは)米国は、ソフトウェアサプライチェーンセキュリティの先駆者だ。2021年、バイデン政権は大統領令「14028号」を発令し、公共部門と民間部門の全ての組織においてサプライチェーンの脆弱性対処を義務付けた。
モデルの来歴、つまり「そのモデルがどこから来たものか」は、開発、デプロイ、トレーニング、テスト、監視、使用を通じて、MLシステムの履歴を追跡するために必要な情報だ。モデルについて「誰が」「どのような変更を」「いつ実施したか」をセキュリティ監査人が特定するのに役立つ。
MLシステムのモデルの来歴には以下のような要素が含まれる。
モデルの来歴は、EU(欧州連合)の「GDPR」(一般データ保護規則)、米国の「HIPAA」(医療保険の携行性と責任に関する法律)などのさまざまなデータ保護コンプライアンス規制や、「PCI DSS」(クレジット産業向けデータセキュリティ標準)などの業界固有の規制に準拠するために不可欠な要素だ。
「ガバナンス、リスク、コンプライアンスフレームワーク」(GRCフレームワーク、以下GRC)は、政府や業界が施行する規制を満たすために組織内で使用される。MLシステムの場合、GRCはMLSecOpsの幾つかの要素にまたがっている。その目的は、組織が責任を持って倫理的にAIツールを使用しているかどうか確認することだ。
業務を進めるためにMLモデルに依存したAIツールを構築する組織が増えるにつれ、MLシステムの使用と開発において強固なGRCが必要になっている。例えばMLシステムを開発する場合、組織はデータセット、アルゴリズム、フレームワークなど、開発に使用される全てのコンポーネントのリストを維持する必要がある。このリストは「機械学習部品表」(MLBoM)と呼ばれる。ソフトウェア部品表(SBOM)と同様に、MLBoMはAIツールとその基礎となるMLモデルを作成するために使用される全てのコンポーネントとサービスを文書化する。
“信頼されるAI”はAIツールを使用する際の倫理的側面を扱う。多くの組織がAIツールに依存して業務を遂行していく中で、AIツールとその基盤となるMLモデルが倫理的な応答を返し、人種、性別、年齢、宗教、倫理、国籍などの特性に偏らないようにする必要性が高まっている。
AIツールの公平性を確認する方法の一つは、(AIツールに)回答の説明を求めることだ。例えば、ユーザーが「夏に訪れるのに最適な国はどこか」と尋ねたとする。モデルはその答えとともに「どうしてその答えをしたのか(そしてなぜそれが正しい答えだと考えたのか)」という理由(正当性)を証明しなければならない。この説明は、人間がAIツールの決定に影響を与えた要因を理解するのにも役立つ。
攻撃者はMLシステムを悪用して“悪意のあるアクション”を実行させる攻撃方法を研究している。それが“敵対的機械学習”だ。敵対的機械学習を使った攻撃手法は大きく4つに分類できる。
ポイズニング(Poisoning)
MLトレーニングデータセットに悪意のあるデータを挿入することで、誤った回答を生成させる手法。
回避(Evasion)
MLモデルのトレーニングが終わった後に仕掛けられる攻撃で、特別に細工されたプロンプトをMLシステムに送信することで、誤った応答を引き出すことができる手法だ。例えば、わずかに加工した犬の写真を使い、MLシステムをだまして“建物”と誤認させることができる。
推論(Inference)
MLモデルをリバースエンジニアリングし、機密性の高い情報が含まれている可能性があるトレーニングデータを抽出しようとする手法。
抽出(Extraction)
MLモデル全体またはMLモデルのトレーニングに使用されるデータを抽出または複製しようとする手法。
MLSecOpsの手法を効率的に使用することで、MLの開発チームはサイバー攻撃による被害を軽減できる。MLSecOpsのベストプラクティスを幾つか紹介する。
ML開発に関連する潜在的な攻撃ベクトルを特定することが重要だ。前述したような「ポイズニング」「抽出」などML開発には独自のセキュリティ脆弱性がある。
モデルのトレーニングに使用されるデータに、顧客の個人を特定できる情報などの機密情報が含まれている場合は、そのデータを暗号化またはその他の手段で適切にマスクする必要がある。
MLモデルの開発環境は、本番環境から隔離されるべきだ。開発フェーズでは、モデルはテスト中の段階であり、保護が不十分な状態だ。サンドボックスで隔離しておけば、そうした不安定な状況で攻撃者にアクセスされる心配がなくなる。
MLモデルの作成に使用される全てのソフトウェアコンポーネント、特にオープンソースのコンポーネントは、マルウェアやその他のセキュリティ脆弱性がないかどうかスキャンする必要がある。特にサードパーティーベンダーから提供されたコンポーネントは徹底的にスキャンして、セキュリティホールがないことを確認すべきだ。
MLモデルのテストで、悪意のあるプロンプトを入力し、MLモデルがそれらを正しく処理できること(悪意のある入力を受け付けないこと)を確認する。これは、インターネットに公開されているLLMにとっては不可欠なテストとなる。
Copyright © ITmedia, Inc. All Rights Reserved.