Azure Machine Learning での脆弱性の管理
脆弱性の管理には、組織のシステムとソフトウェアに存在するあらゆるセキュリティ脆弱性の検出、評価、軽減、報告が含まれます。 脆弱性の管理は、お客様と Microsoft の共同責任です。
この記事では、これらの責任について説明し、Azure Machine Learning が提供する脆弱性の管理コントロールの概要を紹介します。 最新のセキュリティ更新プログラムを使用してサービス インスタンスとアプリケーションを最新の状態に保つ方法と、攻撃者の機会を最小限に抑える方法について説明します。
Microsoft が管理する VM イメージ
Azure Machine Learning は、Azure Machine Learning コンピューティング インスタンス、Azure Machine Learning コンピューティング クラスター、Data Science Virtual Machines のホスト OS 仮想マシン (VM) イメージを管理します。 更新の頻度は月単位であり、次の詳細が含まれます。
新しい VM イメージ バージョンごとに、最新の更新プログラムが OS の元の発行元から提供されます。 最新の更新プログラムを使うと、該当する OS 関連のパッチをすべて確実に取得できます。 Azure Machine Learning では、Ubuntu のすべてのイメージについて発行元は Canonical です。 これらのイメージは、Azure Machine Learning コンピューティング インスタンス、コンピューティング クラスター、および Data Science Virtual Machines で使用されます。
VM イメージは毎月更新されます。
Azure Machine Learning では、元の発行元によって適用されるパッチの他に、更新プログラムが利用可能になるとシステム パッケージの更新も行います。
Azure Machine Learning では、アップグレードが必要になる可能性があるすべての機械学習パッケージをチェックして検証します。 ほとんどの場合、新しい VM イメージにはパッケージの最新バージョンが含まれています。
すべての VM イメージは、脆弱性のスキャンを定期的に実行するセキュリティで保護されたサブスクリプション上に構築されています。 Azure Machine Learning は、未対処の脆弱性にフラグを設定し、次のリリースで修正します。
その頻度は、ほとんどのイメージで月単位です。 コンピューティング インスタンスの場合、イメージのリリースは、環境にプレインストールされている Azure Machine Learning SDK のリリース周期に合わせて行われます。
Azure Machine Learning は、通常のリリース周期に加えて、脆弱性が表面化した場合に修正プログラムを適用します。 Microsoft は、Azure Machine Learning コンピューティング クラスターについては 72 時間以内、コンピューティング インスタンスについては 1 週間以内に修正プログラムをロールアウトします。
Note
ホスト OS は、モデルのトレーニングまたはデプロイ時に環境に対して指定できる OS バージョンではありません。 環境は Docker 内で実行されます。 Docker はホスト OS で実行されます。
Microsoft が管理するコンテナー イメージ
Azure Machine Learning が管理する基本 docker イメージは、新たに検出された脆弱性に対処するためにセキュリティ パッチを頻繁に取得します。
Azure Machine Learning は、脆弱性に対処するために、サポートされているイメージの更新プログラムを 2 週間ごとにリリースします。 Microsoft では、コミットメントとして、サポートされるイメージの最新バージョンで 30 日を超える脆弱性が存在しないことを目指しています。
パッチが適用されたイメージは、新しい不変タグと、更新された :latest タグの下でリリースされます。 :latest タグを使用したり、特定のイメージ バージョンにピン留めしたりすると、機械学習ジョブでセキュリティと環境の再現性の間のトレードオフになる可能性があります。
環境とコンテナー イメージの管理
再現性は、ソフトウェア開発と機械学習の実験の重要な側面です。 Azure Machine Learning 環境コンポーネントの主要な焦点は、ユーザーのコードが実行される環境の再現性を保証することです。 機械学習ジョブの再現性を確保するために、以前に構築されたイメージは、再具体化を必要とすることなくコンピューティング ノードにプルされます。
Azure Machine Learning は、リリースごとに基本イメージにパッチを適用しますが、最新のイメージを使用するかどうかは、再現性と脆弱性管理の間のトレードオフになる可能性があります。 ジョブまたはモデル デプロイに使う環境バージョンを選ぶのはお客様の責任となります。
既定では、依存関係は、環境を構築するときに Azure Machine Learning で提供される基本イメージの上に階層化されます。 また、環境を Azure Machine Learning で使うときに、独自の基本イメージを使うこともできます。 Microsoft が提供するイメージの上にさらに多くの依存関係をインストールするか、独自の基本イメージを使う場合は、脆弱性の管理はお客様の責任となります。
Azure Machine Learning ワークスペースには、コンテナー イメージのキャッシュとして機能する Azure Container Registry インスタンスが関連付けられています。 具体化されるすべてのイメージは、コンテナー レジストリにプッシュされます。 ワークスペースがそれを使うのは、対応する環境で実験またはデプロイがトリガーされた場合です。
Azure Machine Learning は、コンテナー レジストリからイメージを削除しません。 時間の経過に伴うイメージの必要性を評価するのは、お客様の責任となります。 環境の検疫状態を監視および維持するために、Microsoft Defender for Container Registry を使用して、イメージの脆弱性のスキャンに役立てることができます。 Microsoft Defender からのトリガーに基づいてプロセスを自動化するには、「修復応答を自動化する」を参照してください。
プライベート パッケージ リポジトリの使用
Azure Machine Learning は、Conda と Pip を使って Python パッケージをインストールします。 既定では、Azure Machine Learning はパブリック リポジトリからパッケージをダウンロードします。 組織から、Azure DevOps フィードなどのプライベート リポジトリのパッケージのみを使うことを求められている場合は、基本イメージとコンピューティング インスタンスの環境構成の一部として Conda および Pip の構成をオーバーライドできます。
次の構成例は、既定のチャネルを削除し、Conda および Pip の独自のプライベート フィードを追加する方法を示しています。 自動化のために、コンピューティング インスタンスのセットアップ スクリプトを使用することをご検討ください。
RUN conda config --set offline false \
&& conda config --remove channels defaults || true \
&& conda config --add channels https://my.private.conda.feed/conda/feed \
&& conda config --add repodata_fns <repodata_file_on_your_server>.json
# Configure Pip private indexes and ensure that the client trusts your host
RUN pip config set global.index https://my.private.pypi.feed/repository/myfeed/pypi/ \
&& pip config set global.index-url https://my.private.pypi.feed/repository/myfeed/simple/
# In case your feed host isn't secured through SSL
RUN pip config set global.trusted-host http://my.private.pypi.feed/
Azure Machine Learning で独自の基本イメージを指定する方法については、Docker ビルド コンテキストから環境を作成する方法に関する記事を参照してください。 Conda 環境の構成の詳細については、Conda サイト上に手動で環境ファイルを作成する方法に関する記事を参照してください。
コンピューティング ホストでの脆弱性の管理
Azure Machine Learning のマネージド コンピューティング ノードは、Microsoft が管理する OS VM イメージを使います。 ノードをプロビジョニングすると、最新の更新された VM イメージがプルされます。 この動作は、コンピューティング インスタンス、コンピューティング クラスター、サーバーレス コンピューティング (プレビュー)、マネージド推論コンピューティング オプションに適用されます。
OS VM イメージには定期的にパッチが適用されますが、Azure Machine Learning は、使用中にコンピューティング ノードの脆弱性をアクティブにスキャンしません。 追加の保護層については、お使いのコンピューティングのネットワークの分離を検討してください。
環境を最新の状態にし、コンピューティング ノードに最新の OS バージョンを使うようにすることは、お客様と Microsoft の共同責任です。 アイドル状態ではないノードは、最新の VM イメージに更新できません。 次のセクションに示すように、コンピューティングの種類ごとに、考慮事項は若干異なります。
コンピューティング インスタンス
コンピューティング インスタンスは、プロビジョニング時に最新の VM イメージを取得します。 Microsoft は、毎月新しい VM イメージをリリースします。 コンピューティング インスタンスをデプロイした後は、アクティブに更新されません。 インスタンスのオペレーティング システムのバージョンに対してクエリを実行できます。 最新のソフトウェア更新プログラムとセキュリティ パッチを常に最新の状態に保つには、次のいずれかの方法を使用できます。
コンピューティング インスタンスを再作成して最新の OS イメージを取得します (推奨)。
この方法を使う場合、インスタンスの OS や一時ディスクに保存されているインストール済みパッケージなどのデータやカスタマイズは失われます。
インスタンスを再作成する場合:
イメージ リリースの詳細については、「Azure Machine Learning コンピューティング インスタンス イメージのリリース ノート」を参照してください。
OS と Python パッケージを定期的に更新します。
Linux パッケージ管理ツールを使用して、パッケージ リストを最新バージョンに更新します。
sudo apt-get updateLinux パッケージ管理ツールを使用して、パッケージを最新バージョンにアップグレードします。 この方法を使うと、パッケージの競合が生じる可能性があります。
sudo apt-get upgradePython パッケージ管理ツールを使用して、パッケージをアップグレードし、更新プログラムを確認します。
pip list --outdated
コンピューティング インスタンスに追加のスキャン ソフトウェアをインストールして実行することで、セキュリティに関する問題をスキャンできます。
- Trivy は、OS と Python のパッケージ レベルの脆弱性を検出するために使います。
- ClamAV は、マルウェアを検出するために使います。 これはコンピューティング インスタンスにプレインストールされています。
Microsoft Defender for Servers エージェントのインストールは現在サポートされていません。
自動化のためにカスタマイズ スクリプトを使用することを検討してください。 Trivy と ClamAV を組み合わせたセットアップ スクリプトの例については、コンピューティング インスタンスのサンプル セットアップ スクリプトに関する記事を参照してください。
コンピューティング クラスター
コンピューティング クラスターは、ノードを最新の VM イメージに自動的にアップグレードします。 min nodes = 0 を指定してクラスターを構成している場合は、すべてのジョブが完了し、クラスターのノード数が 0 になったときに、ノードが最新の VM イメージ バージョンに自動的にアップグレードされます。
次の条件では、クラスター ノードはスケールダウンしないため、最新の VM イメージを取得できません。
- クラスターの最小ノード数は 0 より大きい値に設定されます。
- クラスター上のジョブは継続的にスケジュールされます。
最新の OS VM イメージの更新プログラムを取得するには、アイドル状態ではないクラスター ノードをお客様がスケールダウンする必要があります。 VM の更新プログラムを発行するために、コンピューティング ノード上で実行中のワークロードを Azure Machine Learning が停止することはありません。 最小ノード数を一時的に 0 に変更し、クラスターのノード数が 0 になるのを許可します。
マネージド オンライン エンドポイント
マネージド オンライン エンドポイントは、脆弱性修正プログラムを含む OS ホスト イメージの更新プログラムを自動的に受け取ります。 イメージの更新頻度は、少なくとも 1 か月に 1 回です。
そのバージョンがリリースされると、コンピューティング ノードは最新の VM イメージ バージョンに自動的にアップグレードされます。 何らかのアクションをとる必要はありません。
カスタマー マネージド Kubernetes クラスター
Kubernetes コンピューティングを使用すると、Azure Machine Learning でモデルをトレーニングし、推論を実行し、管理するように Kubernetes クラスターを構成できます。
Kubernetes を使う環境の管理はお客様が行うため、OS VM の脆弱性とコンテナー イメージの脆弱性の管理はどちらもお客様の責任となります。
Azure Machine Learning は、新しいバージョンの Azure Machine Learning 拡張機能コンテナー イメージを Microsoft アーティファクト レジストリ内に頻繁に発行します。 新しいイメージ バージョンに脆弱性が存在しないことを確認するのは、Microsoft の責任です。 各リリースでは、脆弱性が修正されます。
クラスターが中断することなくジョブを実行する場合、実行中のジョブで古いコンテナー イメージ バージョンが実行されることがあります。 amlarc 拡張機能を実行中のクラスターにアップグレードすると、新しく送信されたジョブは最新のイメージ バージョンを使うようになります。 amlarc 拡張機能を最新バージョンにアップグレードする場合は、必要に応じて、古いコンテナー イメージのバージョンをクラスターからクリーンアップします。
Azure Arc クラスターで最新バージョン amlarcが実行されているかどうかを確認するには、Azure portal を使います。 Kubernetes - Azure Arc という種類の Azure Arc リソースで [拡張機能] に移動して、amlarc 拡張機能のバージョンを確認します。
AutoML と Designer の環境
コードベースのトレーニング エクスペリエンスでは、使う Azure Machine Learning 環境をお客様が管理します。 AutoML と Designer を使うと、環境はサービスの一部としてカプセル化されます。 このような種類のジョブは、お客様が構成したコンピューティング上で実行し、ネットワークの分離など、追加の制御を行うことができます。
AutoML ジョブは、Azure Machine Learning ベースの Docker イメージ上に階層化された環境で実行されます。
Designer ジョブは、コンポーネントにコンパートメント化されます。 各コンポーネントには、Azure Machine Learning ベースの Docker イメージ上に階層化された独自の環境があります。 コンポーネントの詳細については、コンポーネントに関するリファレンスを参照してください。