機械学習のセキュリティリスクの概要

by Canonical on 10 July 2024

データはあらゆる機械学習(ML)プロジェクトの要であり、悪人もそれを知っています。技術者の間でAIが常に話題になるとともに、MLシステムは攻撃の標的としても注目を集めています。Identity Theft Resource Center(ID窃盗リソースセンター)の報告によれば、2023年にはデータ漏えいが72%も増加しており、MLプロジェクトが恰好の攻撃経路とならないよう適切な対策を施すことは極めて重要です。
このブログ記事では、機械学習のセキュリティリスクについて説明し、主要な脅威と課題に言及します。しかし、悲観的な話だけでなくベストプラクティスにも目を向け、オープンソースの役割も含め、可能なソリューションを探求します。

機械学習の攻撃対象領域

あらゆるテクノロジーにはセキュリティ上の懸念がありますが、機械学習には有能な人材が不足しており、AIの革新的なアプリケーションもないため、課題は特に困難なものとなります。セキュリティには次の要素があります。

  • データのセキュリティ:MLプロジェクトには大量のデータが必要で、多くの場合には個人情報、財務諸表、ジオロケーションなど、機密性が高いデータが含まれています。MLシステムは、組織を保護するだけでなく、人々のプライバシーも保護するため、この点を最初から考慮に入れる必要があります。これには、データの移動時と保管時の両方における、プライバシーとセキュリティが含まれます。
  • ツールのセキュリティ:機械学習のライフサイクルは複雑で、多くの場合にはいくつものツールが含まれます。それらのツールはさらに多数のパッケージを使用し、広範なシステム内ではセキュリティギャップになる可能性があります。セキュリティが不確実なパッケージでは、機械学習モデルに、さらにはデータ自体へのアクセスを許してしまうことがあり、セキュリティの巨大なリスクになります。企業は、最新のツールを使用する、機械学習のセキュリティリスクを低減するなどのベストプラクティスに従い、MLアーキテクチャを注意深く構築する必要があります。
  • MLモデルのセキュリティ:MLモデルはセキュリティ攻撃で真っ先に狙われるターゲットには見えないかもしれませんが、モデルは知的財産そのもので、モデルの盗難は極めて現実的な危険です。さらに、攻撃者は悪意のデータポイントを追加したり、モデルのトレーニング段階を操作したりすることで、モデルの性能を意図的に悪化させることができます。MLモデルはセキュリティを考慮し、モデルのテストやモデルのドリフト検証などの行為が通常のライフサイクルの一部となるように構築する必要があります。
  • ハードウェアのセキュリティ:MLプロジェクトは使用するコンピュータの能力に依存し、多くの場合は追加のハードウェアへの新たな投資が必要となります。ハードウェアのサプライチェーン、メンテナンス、ファームウェアの更新、または定期的な更新が行われないことは、すべてリスクの可能性があります。組織は自社のハードウェアサプライヤーと、自社のメンテナンス戦略を十分に検討する必要があります。
  • エンドデバイスのセキュリティ:MLモデルは毎年何百万台ものデバイスに展開され、それぞれのデバイスはアーキテクチャ、セキュリティ規制、能力が異なっています。実運用としてMLの実行を開始するときは、モデルがデバイス上にあるときと転送中の両方でのモデルへのアクセスも含めて、エッジデバイスへの望まないアクセスを避けることが重要です。エッジデバイスは、適切なモデルのパッケージング、更新、セキュリティ制限なしでは特に脆弱になりがちです。詳細はエッジAIについてのブログ記事をご覧ください。
  • 人的要因:結局のところ、MLプロジェクトにはソリューションアーキテクト、データアナリスト、データサイエンティスト、データエンジニアなど、さまざまな専門家が含まれます。特にMLプロジェクトのセキュリティに関して、それぞれの保有する技能セットやトレーニングは大きく異なっています。MLイニシアチブの一部である専門家には常にリスクがつきまとうため、それぞれに適切なトレーニングを行い、責任範囲を追跡することが不可欠です。

機械学習の最も大きな4つのセキュリティリスク

非常に動的で攻撃経路も多い機械学習プロジェクトには、多数のセキュリティリスクがあり、運用されるMLアプリケーションの数とともにリスクも増加します。以下では、知っておくべき最も大きな4つの一般的な脅威について説明します。

パッケージのセキュリティ脆弱性

それぞれの業界や組織の規制に応じて、企業は使用するソフトウェアに致命的または高い脆弱性が含まれていないことを確認する必要があります。しかし、MLプロジェクトは通常、多数のパッケージを使用するため、脆弱性が生じる可能性もおおいにあります。これらの脆弱性は、オペレーティングシステムからアプリケーションまで、スタックのあらゆるレイヤーに出現する可能性があり、悪用されればセキュリティの大きなリスクになります。AI分野で悪名高い例はShellTorchで、開発中に使用されたすべてのコードが明かされ、他人がモデルにアクセス可能になるものでした。

このリスクを軽減するには、MLプロジェクトが使用するパッケージ、およびそれらの依存関係を明確に理解する必要があります。脆弱性を報告してくれる定期的なスキャンを実装し、それらを修正するための戦略を用意すべきです。これには、使用するツールの更新とアップグレードを定期的に行うこと、最新のニュースやセキュリティ最新情報をチェックすること、信頼の置けるアドバイザーを持つことが含まれます。

データポイズニング

データポイズニングは、モデルや製品をトレーニングするためにデータが使用され、結果が改変されてシステムの性能に害を及ぼすときに発生します。新しいデータが頻繁にシステムに取り込まれ、モデルは何か新しい、不正確かつ意図しないことを学習します。たとえば、トレーニング用データセットに監視カメラの映像が含まれているなら、攻撃者が悪意でその映像をターゲットにし、特定の期間について赤色の車両だけを使用して、悪意でモデルをトレーニングします。間違ったラベルが付けられたデータが少量あるだけでもモデルの性能に影響を及ぼし、実運用では信頼性が欠けるものになります。

攻撃者によってデータがどのような影響を受けるかを明確に理解すれば、リスクを軽減する対策を講じることができます。たとえば継続的な再トレーニングのパイプラインはモデルを常に最新の状態に保ち、モデルとデータのドリフト監視はモデルの精度や構造が変化したときに専門家に速やかに通知します。

敵対的攻撃

これらは機械学習の分野で最も一般的な攻撃の種類であり、MLモデルを騙して望む結果を出させます。通常は攻撃者が入力を与え、期待する出力を得ます。基本的には、多くのMLシステムは少数の境界しか持たないことを利用してシステムを騙します。敵対的攻撃が人間の目でもモニタリングシステムでも発見しにくいのは主に、モデルが入力の特徴に基づいて各種クラスを分割する決定境界の学習を行わないためです。

敵対的攻撃によりモデルの正確性が減少し、専門家がそれ以後に特定のプロジェクトを実運用で実行することを避けるようになる可能性があります。組織は敵対的トレーニングについて考慮し、MLプロジェクトの構築とデータのクリーニングを行うときには明確な戦略を持つ必要があります。作成されるすべてのデータを直接トレーニングセットに組み込むべきとは限りません。また、すべての関係者が、組織内で作成されるすべてのモデルや、実験追跡、モデルストア、モデルの性能トラッカーなど、すべての機能にアクセスを許可されるべきでもありません。

データのプライバシー

MLアルゴリズムは、既存の情報を見るだけで新しいデータを予測または生成できるようにするため構築されます。企業は個人に比べて、数百万もの人々の個人データにアクセス可能です。データがMLシステムへのアクセスを許可されたとき、それに関係する新しいワークフローに起因し、データの機密性に関連するリスクがあります。

組織は明確なプライバシーポリシーを作り上げ、すべてのユーザーがそれを読んで同意し、すべての人々を保護するMLシステムを作成する必要があります。また、収集するデータや、それに関係するプロセスについても注意する必要があります。IDを削除する、データのフローを明確に可視化するなどのベストプラクティスにより、組織、および組織と関係する人々のプライバシーが保護されます。

機械学習のセキュリティを強化するためのベストプラクティス

前に概説した4つの脅威は、プロジェクトが直面する機械学習のセキュリティリスクの一部にすぎません。これらとともに、あらゆるテクノロジーで常に発生してきた、従来型のソフトウェアの脅威が存在します。そのため、MLシステムを保護するには、AI分野に存在する固有のリスクを考慮するとともに、より広範なセキュリティのベストプラクティスも取り入れた、特別な手法が必要です。

  • セキュリティを考慮してMLシステムのアーキテクチャを設計する。早くプロジェクトを開始したいという熱意から、専門家は手順を省略してMLモデルの構築に集中したいという誘惑にかられることがあります。熱意を抑え、構築するMLシステムが、コンプライアンスを守り、セキュリティの規制に従っていることを確認してください。パッケージを常に最新の状態に保つことから、分離されたパイプラインを作り上げることまで、アーキテクトが全体像を見据える必要があります。
  • データの暗号化を使用する。データを攻撃から保護し、モデルの正確性が減少することを防ぎます。データの暗号化だけではMLシステムを保護するために不十分ですが、実運用でMLプロジェクトを安全に実行するための基本的なステップです。
  • 異常の検出とバイアスの検出を行う。モデルの実運用が開始されるとエラーが発生する可能性があり、組織の信頼性や活動に影響する恐れがあります。異常の検出やバイアスの検出により、MLプロジェクトの堅牢性が向上し、ドリフトの誤検出が避けられ、脅威を早期に識別できる可能性が高まります。
  • ネットワークを分離する。すべての関係者がすべてのMLパイプラインへのアクセスを与えてはなりません。特に、プロジェクトで機密性が高いデータを使用する場合には禁物です。担当者は常に、分離されたネットワークで作業し、外部と内部からのパイプラインへのアクセスを制限する必要があります。これにより、パイプラインで使用するデータが保護され、プロジェクトの信頼性も守られます。
  • アクセスを制限する。組織内でMLプロジェクトが成長するにつれ、関係するデータサイエンティストやMLエンジニアの数も増加します。一部のチームメンバーによりプロジェクトが開発される可能性があるため、これらの関係者のアクセスを制御することは重要です。たとえば、データサイエンスチームのすべてのメンバーに、組織の財務データに関わることを承認してはなりません。また、社内から生じた可能性のある不正行為を追跡することも必要です。ユーザー管理機能は、システムの可視性のため不可欠です。
  • セキュアな設計の原則に従う。MLシステムは新しいものですが、セキュリティに関する既存のベストプラクティスも必ず適用すべきです。既存のセキュアな設計の原則に従い、必要なときには専門のヘルプを求める必要があります。さらに、システムのセキュリティをチェックするため、脅威のモデル化、静的コード分析、CVEパッチ処理などのタスクを行う必要があることに常に留意します。
  • ツールとアーティファクトをモニタリングする。MLプロジェクトに関係するデータ、モデル、ツール、パッケージの可視化は、長期的な成功を左右します。ツールのスキャンを毎日行う、データのドリフトをモニタリングする、モデルの性能を常時可視化するなどは、専門家がリスクの可能性を識別するため役立つ基本的なタスクです。さらに、明確な一連のアラートを作成する必要があります。これにより、悪意の攻撃や、アーティファクトのいずれかの動作が突然変化したことを、全員に通知できます。
  • 組織を教育する。人工知能と機械学習は、ほとんどの人々にとって依然として新しいトピックです。組織は、MLプロジェクト、それに関連するリスク、問題の可能性を報告するため使用される可能性がある方法について、専門家をトレーニングするため時間を費やす必要があります。
  • 機械学習のライフサイクル全体を見据える。セキュリティは、データの取り込みからモデルの展開まで、機械学習のライフサイクル全体を通してリスクになる可能性があります。この過程の全体を通して、すべてのアーティファクトを保護することでリスクを低減できます。攻撃者はパイプラインの弱い部分を狙うからです。脆弱性は多くの場合にサイクルの終わり近く、展開のフェーズで発見されますが、組織はほかのステップに関連するリスクにも注目すべきです。

オープンソースAIを使用するセキュリティソリューション

オープンソースは、機械学習の開発の中心となります。Linux Foundation Data & AIは、データサイエンティスト、MLエンジニア、アーキテクトがMLプロジェクトの実験や、実運用での実行のために使用できるツールが豊富に存在していることを示しています。モデルの開発、展開、モニタリング、保存に使用される、オープンソースのツールも含まれています。これらの多くはセキュリティに重点を置いたもので、その点については後でさらに解説します。

Canonicalは設立以来、常にオープンソースに携わっています。オペレーティングシステムからクラウドネイティブのアプリケーションまで、スタックのあらゆる部分で安全なオープンソースソフトウェアを提供することがCanonicalの目標です。当社のセキュリティツールと機能により、MLシステムがどのように拡張されるかを説明しましょう。

Livepatch

Livepatchは、カーネルのパッチを定期的にチェックし、再起動を行わずハードウェアに適用するソリューションです。これにより、組織はハードウェアを最新のカーネルパッチで更新し、ダウンタイムや計画外の作業を減らすことができます。これは、長期間にわたってトレーニングを行うときにも非常に便利で、結果をリスクにさらしたり、プロジェクトの遅延を引き起こしたりせずにトレーニングを続けることができます。さらに、組織がパッチの適用時期やロールアウトポリシーを計画することで、独自の更新戦略を作り上げ、実行できます。Ubuntuには、Ubuntu Proの一部としてLivepatchが付属します。

コンフィデンシャルコンピューティング

コンフィデンシャルコンピューティングは1970年代の後半に誕生しましたが、AIによって急速に普及しました。シリコンレベルで革新的なテクノロジーを使用することにより、オンプレミスまたはパブリッククラウドにホストされている機密性データの機密性と整合性を保護します。医療や金融サービスなど、規制の厳しい業界で多く採用されています。Ubuntuはコンフィデンシャルコンピューティングの中核で、すでにMicrosoft VMやIntel TDX上で利用できます。コンフィデンシャルコンピューティングの詳細をご覧ください。

脆弱性の修正

新しい共通脆弱性識別子(Common Vulnerabilities and Exposures:CVE)は毎日出現しており、適時パッチで対処する必要があります。Ubuntu Proはサブスクリプションの一部として30,000を超えるパッケージの修正を行い、この必要にチームが迅速に対処するため役立ちます。これには、Pandas、Python、Numpy、Tensorflow、PyTorchなどの機械学習ツールも含まれており、専門家が安全にモデルを開発できます。MLOpsツールのセキュリティについて詳細をご覧ください。

MLOpsプラットフォーム

機械学習運用(MLOps)プラットフォーム、たとえばCharmed Kubeflowを使えば、組織は大規模にAIを運用できます。これにより、MLシステムが認証やネットワーク分離などの機能を持ち、データとMLモデルが綿密に制御および保護されます。これらは、1つのツール内でMLのライフサイクル全体を実行し、MLのパイプライン全体に出現するセキュリティホールの数を減らするための基礎となるピースです。

モデルのパッケージング用のsnap

snapは、Linuxデバイスにアプリケーションを埋め込むためのセキュアでスケーラブルな方法です。また、パックされてエッジデバイスに展開されているMLモデルにも使用できます。これによりモデルのメンテナンスが簡素化され、OTA更新や、障害発生時の自動ロールバックの恩恵を受けることができます。ブランドストアも、複数のモデルを管理するために役立ちます。オープンソースによるエッジでのAIの詳細をご覧ください。

MLシステムは悪意の人々に目を付けられやすいターゲットですが、それを理由にAIによるイノベーションを恐れるべきではありません。脅威の全体像を十分に理解し、ベストプラクティスを組み入れ、オープンソースソリューションの利点を活用することで、モデルとデータを保護し、組織をリスクにさらすことなくAI/MLの長所を活用できるようになります。

参考資料

ニュースレターのサインアップ

Ubuntuニュースレターの配信登録

お客様が購読登録を行われる場合、以下の条件に同意されたことになります。Canonicalのプライバシーに関するお知らせ個人情報保護ポリシー

関連記事

Firefighting Supportを発表

新しいサービスでCanonicalの専門家が高度なクラウドサポートを提供 Canonicalのマネージドソリューションチームは、自社でインフラストラクチャの管理を行い、トラブルシューティングの必要があるときのみ専門家の対応を求める組織のために、新しいサービス「Firefighting Support」を発表しました。 Firefighting Supportでは、フルマネージドサービスを止めた、または厳しいセキュリティ規制によってサードパーティーに環境へのアクセスを許可できないお客様に対して、マネージドサービスレベルのサポートを提供します。このサービスはノードごとの年間料金で提供され、次のような内容です。 自己管理インフラストラクチャへの移行に理想的 現在の市場では、マネ […]

Linuxにセキュリティパッチを適用する頻度は?

セキュアな環境を維持するには定期的なパッチの適用が不可欠ですが、Linux環境を安全に保つための方法は環境によって異なります。運用の安定性を考えて、どのぐらいの更新頻度が妥当でしょうか? 最も制限が多く、規制が厳しい環境でも、準拠が保証され安全な方法で、セキュリティパッチの適用を自動化できる方針が存在します。セキュリティパッチの適用方針を定義するときは、Canonicalでのソフトウェア更新のリリーススケジュールを理解し、セキュリティパッチの適用の時間枠を知っておくことが不可欠です。私は最近、ライブのウェビナーとセキュリティの質疑応答を主催し、パッチ適用の回数を最小化するとともに、パッチが適用されていない脆弱性が悪用される回数も最小化する方法について解説しました。この記事 […]

CanonicalのCISOがEUサイバーレジリエンス法を完全解説

強力で対象の広い規制は、関係者の安全を確保する一方、不確定性をもたらす可能性があります。EUサイバーレジリエンス法(CRA)も例外ではありません。オープンソース関係者と技術業界全般にわたり、心配、不安、希望などさまざまな反応が見られます。 しかし怖がる理由があるのでしょうか? EUサイバーレジリエンス法が本当にオープンソースの状況を変えるのでしょうか? 企業はこの法律にどう備えれば良いのでしょうか? この記事ではEUサイバーレジリエンス法とその目的、要件、オープンソース関係者に対する影響を説明し、施行に備えたサイバーセキュリティ上のアドバイスをご紹介します。 EUサイバーレジリエンス法とは? EUサイバーレジリエンス法(CRA)とは、欧州連合(EU)の法律で、EUのIT業 […]