次の方法で共有

Azure Container Instances のセキュリティに関する考慮事項

  • [アーティクル]

この記事では、Azure Container Instances を使用してコンテナー アプリケーションを実行するためのセキュリティに関する考慮事項について説明します。 取り上げるトピックは次のとおりです。

  • Azure Container Instances のイメージとシークレットの管理に関するセキュリティについての推奨事項
  • 任意のコンテナー プラットフォームのコンテナー ライフサイクル全体に関するコンテナー エコシステムの考慮事項

デプロイのセキュリティ態勢を改善するために役立つ包括的な推奨事項については、「Container Instances の Azure セキュリティ ベースライン」を参照してください。

Azure Container Instances のセキュリティに関する推奨事項

プライベート レジストリを使用する

コンテナーのイメージは、1 つ以上のリポジトリに格納されています。 これらのリポジトリは、Docker Hub などのパブリック レジストリに属していても、プライベート レジストリに属していてもかまいません。 プライベート レジストリには Docker Trusted Registry があります。これは、オンプレミスまたは仮想プライベート クラウドにインストールできます。 また、Azure Container Registry などの、クラウドベースのプライベート コンテナー レジストリ サービスを使うこともできます。

パブリックに使用可能なコンテナー イメージでは、セキュリティは保証されません。 コンテナー イメージは、複数のソフトウェア レイヤーから構成され、各ソフトウェア レイヤーが脆弱である可能性があります。 攻撃の脅威を減らすには、Azure Container Registry や Docker Trusted Registry などのプライベート レジストリにイメージを格納して、そこから取得する必要があります。 Azure Container Registry では、マネージド プライベート レジストリが提供されるだけでなく、基本認証フロー用に Microsoft Entra ID によるサービス プリンシパルに基づく認証がサポートされています。 この認証には、読み取り専用 (プル)、書き込み (プッシュ)、およびその他のアクセス許可を対象としたロールベースのアクセスが含まれます。

コンテナー イメージを監視してスキャンする

ソリューションを利用して、プライベート レジストリ内のコンテナー イメージをスキャンし、潜在的な脆弱性を識別します。 さまざまなソリューションの脅威検出の深さを理解することが重要です。

たとえば、Azure Container Registry を必要に応じて Microsoft Defender for Cloud と統合して、レジストリにプッシュされたすべての Linux イメージを自動的にスキャンします。 Microsoft Defender for Cloud の統合 Qualys スキャナーにより、イメージの脆弱性が検出され、それらが分類され、修復のガイダンスが提供されます。

Twistlock や Aqua Security などのセキュリティの監視とイメージ スキャンのソリューションは、Azure Marketplace からも入手できます。

資格情報を保護する

コンテナーは、複数のクラスターと Azure リージョンに広がることがあります。 そのため、パスワードやトークンなど、ログインまたは API アクセスに必要な資格情報をセキュリティで保護する必要があります。 転送中または保存中のそれらのコンテナーには、特権を持つユーザーのみがアクセスできるようにします。 すべての資格情報シークレットの一覧を作成した後、コンテナー プラットフォーム対応に設計されている新しいシークレット管理ツールを使うよう開発者に要求します。 ソリューションに、暗号化されたデータベース、転送中のシークレット データ用の TLS 暗号化、および最小特権の Azure ロールベースのアクセス制御 (Azure RBAC) が含まれていることを確認します。 Azure Key Vault は、コンテナー化されたアプリケーションの暗号化キーとシークレット (証明書、接続文字列、パスワードなど) を保護するクラウド サービスです。 このデータは慎重な扱いを要する情報であり、ビジネス上重要であるため、承認されたアプリケーションとユーザーのみがキー コンテナーにアクセスできるように、キー コンテナーへのアクセスをセキュリティで保護します。

コンテナー エコシステムに関する考慮事項

次のセキュリティ対策を適切に実装して効果的に管理すると、コンテナー エコシステムをセキュリティで保護するのに役立ちます。 これらの対策は、開発から運用デプロイまでのコンテナーのライフサイクル全体、およびコンテナー オーケストレーター、ホスト、プラットフォームの範囲に適用されます。

コンテナー開発ライフサイクルの一部として脆弱性管理を使用する

コンテナー開発ライフサイクル全体で有効な脆弱性の管理を使うことで、深刻な問題になる前にセキュリティ上の懸念を識別して解決できる可能性が高くなります。

脆弱性をスキャンする

新しい脆弱性は絶えず発見されているので、脆弱性のスキャンと識別は継続的なプロセスです。 コンテナーのライフサイクル全体に脆弱性のスキャンを組み込みます。

  • 開発パイプラインの最終チェックとして、パブリック レジストリまたはプライベート レジストリにイメージをプッシュする前に、コンテナーで脆弱性スキャンを実行する必要があります。
  • 開発中に何らかの理由で見落とされたすべての欠陥を識別し、コンテナー イメージで使用されているコードに存在する可能性のある新しく検出された脆弱性に対処するために、レジストリ内のコンテナー イメージのスキャンを続行します。

イメージの脆弱性を実行中のコンテナーにマップする

セキュリティの問題を軽減または解決できるように、コンテナー イメージで識別された脆弱性を実行中のコンテナーにマッピングする手段が必要です。

承認されたイメージだけが環境内で使用されるようにする

不明なコンテナーを許可しなくても、コンテナー エコシステムには十分な変更と不安定さがあります。 承認されたコンテナー イメージのみを許可します。 承認されていないコンテナー イメージの使用を監視して禁止するためのツールとプロセスを導入します。

攻撃面を削減し、開発者の重要なセキュリティの間違いを防ぐのに効果的な方法は、開発環境へのコンテナー イメージのフローを制御することです。 たとえば、基本イメージとして 1 つの Linux ディストリビューションを承認し (できれば、無駄のないもの (Ubuntu ではなく Alpine や CoreOS))、潜在的な攻撃面を最小限に抑えます。

イメージの署名またはフィンガープリントは、コンテナーの整合性を検証できる証拠の連続性を提供できます。 たとえば、Azure Container Registry では Docker のコンテンツ信頼モデルがサポートされており、イメージ発行者はレジストリにプッシュされるイメージに署名することができ、イメージ使用者は署名付きイメージだけをプルできます。

承認されたレジストリのみを許可する

環境で承認されたイメージのみを使用することの延長は、承認されたコンテナー レジストリの使用のみを許可することです。 承認されたコンテナー レジストリの使用を要求すると、未知の脆弱性またはセキュリティの問題が持ち込まれる可能性が制限され、リスクにさらされる機会が減少します。

ライフサイクル全体でイメージの整合性を確認する

コンテナーのライフサイクル全体でのセキュリティ管理の一部は、レジストリ内、変更時、または運用環境へのデプロイ時にコンテナー イメージの整合性を確保することです。

  • ささいなものでも脆弱性があるイメージは、運用環境での実行を許可しないでください。 理想的には、運用環境にデプロイされているすべてのイメージを、選択された少数のユーザーしかアクセスできないプライベート レジストリに保存する必要があります。 運用環境のイメージの数は、効果的に管理できるように少なく抑えます。

  • 公開されているコンテナー イメージからソフトウェアの配信元を特定するのは難しいため、ソースからイメージを作成して、レイヤーの配信元情報を確認します。 自作のコンテナー イメージで脆弱性が表面化した場合、お客様はより迅速に解決できます。 パブリック イメージの場合は、パブリック イメージのルートを見つけて修正するか、公開元から別の安全なイメージを入手する必要があります。

  • 運用環境にデプロイされた完全にスキャンされたイメージは、アプリケーションの有効期間中は最新であることが保証されません。 以前は知られていなかった、または運用環境へのデプロイ後にもたらされたセキュリティの脆弱性がイメージのレイヤーで報告されることがあります。

    運用環境にデプロイされているイメージを定期的に監査して、最新ではない、またはしばらく更新されていないイメージを特定します。 Blue-Green デプロイ手法およびローリング アップグレード メカニズムを使用して、ダウンタイムなしでコンテナー イメージを更新できます。 前のセクションで説明したツールを使用して、イメージをスキャンすることができます。

  • 統合されたセキュリティ スキャンで継続的インテグレーション (CI) パイプラインを使用して、安全なイメージを作成し、プライベート レジストリにそれをプッシュします。 CI ソリューションに組み込まれている脆弱性スキャンにより、すべてのテストに合格したイメージが、運用環境のワークロードのデプロイ元プライベート レジストリに確実にプッシュされます。

    CI パイプラインの失敗により、脆弱なイメージが、運用環境のワークロード デプロイに使用されるプライベート レジストリにプッシュされないことが保証されます。 また、イメージの数がかなり多い場合は、イメージのセキュリティ スキャンが自動化されます。 そうしないと、セキュリティの脆弱性について手動でイメージを監査する作業は、エラーが発生しやすいうえ、時間もかかります。

実行時には最低限の権限を適用する

最低限の特権の概念は、コンテナーにも適用できる基本的なセキュリティのベスト プラクティスです。 脆弱性が悪用されると、一般に、侵害されたアプリケーションやプロセスのものと等しいアクセス件や特権が攻撃者に与えられます。 ジョブの実行に必要な最低限の特権とアクセス権でコンテナーを動作させれば、リスクにさらされる機会が減ります。

不要な特権を削除してコンテナーの攻撃面を減らす

使用されていない、または必要のないプロセスや特権をコンテナー ランタイムから削除することにより、潜在的な攻撃面を最小化することもできます。 特権を持つコンテナーは、ルートとして実行されます。 悪意のあるユーザーまたはワークロードが特権のあるコンテナー内に紛れ込むと、そのコンテナーはルートとしてそのシステム上で実行されます。

コンテナーがアクセスまたは実行を許可されたファイルと実行可能ファイルを事前に承認する

変数または未知の要素の数を減らすことは、安定した信頼性の高い環境を維持するのに役立ちます。 コンテナーでアクセスまたは実行できるものを、事前に承認されているかセーフ リストに登録されているファイルおよび実行可能ファイルだけに制限することは、リスクにさらされる機会を制限する実績のある方法です。

最初から実装しておけば、セーフ リストの管理がはるかに簡単になります。 アプリケーションの正常な機能に必要なファイルと実行可能ファイルがわかっていれば、セーフ リストで制御と管理の手段が提供されます。

セーフ リストでは、攻撃面が減るだけでなく、異常に対するベースラインが提供され、"迷惑な隣人" やコンテナー ブレイクアウトのシナリオのユース ケースも防止されます。

実行中のコンテナーでネットワークのセグメント化を適用する

あるサブネット内のコンテナーを別のサブネットでのセキュリティ リスクから保護するには、ネットワークのセグメント化 (またはナノセグメント化) または実行中のコンテナー間の分離を維持します。 コンプライアンス要件を満たす必要のある業界でコンテナーを使用するためにも、ネットワークのセグメント化の維持が必要な場合があります。

たとえば、パートナー ツール Aqua では、ナノセグメント化の自動アプローチが提供されます。 Aqua では、実行時のコンテナー ネットワーク アクティビティが監視されます。 他のコンテナー、サービス、IP アドレス、パブリック インターネットとの間のすべての受信および送信ネットワーク接続が識別されます。 ナノセグメント化は、監視対象トラフィックに基づいて自動的に作成されます。

コンテナーのアクティビティとユーザー アクセスを監視する

他の IT 環境と同様、コンテナー エコシステムに対するアクティビティおよびユーザー アクセスを常に監視し、疑わしいアクティビティや悪意のあるアクティビティをすばやく識別する必要があります。 Azure では、次のようなコンテナー監視ソリューションが提供されます。

  • コンテナー向け Azure Monitor では、Azure Kubernetes Service (AKS) 上でホストされている Kubernetes 環境にデプロイされているワークロードのパフォーマンスが監視されます。 コンテナーに対する Azure Monitor では、Kubernetes で使用可能なコントローラー、ノード、およびコンテナーから Metrics API 経由でメモリやプロセッサ メトリックを収集することにより、パフォーマンスを把握できます。

  • Azure コンテナー監視ソリューションを使用すると、他の Docker と Windows のコンテナー ホストを 1 か所で表示して管理できます。 次に例を示します。

    • コンテナーで使用されるコマンドを示す詳細な監査情報を確認します。
    • Docker または Windows ホストをリモートで確認しなくても、一元化されたログを表示および検索して、コンテナーのトラブルシューティングを行います。
    • ホストで余分なリソースを使用しているコンテナーや、ノイズが大きいコンテナーを特定します。
    • コンテナーについて、CPU、メモリ、ストレージ、ネットワークの使用量とパフォーマンスに関する情報を一元的に確認します。

    ソリューションでは、Docker Swarm、DC/OS、アンマネージド Kubernetes、Service Fabric、Red Hat OpenShift などのコンテナー オーケストレーターがサポートされています。

コンテナー リソースのアクティビティを監視する

コンテナーがアクセスするファイル、ネットワーク、他のリソースなどのリソースのアクティビティを監視します。 リソースのアクティビティと消費量を監視することは、パフォーマンスの監視とセキュリティ対策の両方に役立ちます。

Azure Monitor は、Azure サービスのコアな監視用に、メトリック、アクティビティ ログ、および診断ログを収集します。 たとえば、アクティビティ ログでは、新しいリソースが作成または変更されたときに通知するよう設定できます。

メトリックでは、各種リソースはもちろんのこと、仮想マシン内のオペレーティング システムについても、パフォーマンス統計情報を収集できます。 Azure portal で、いずれかのエクスプローラーを使用してこのデータを表示し、これらのメトリックに基づいてアラートを作成することができます。

監査のためにコンテナー管理ユーザーのすべてのアクセスをログに記録する

ご使用の Kubernetes クラスター、コンテナー レジストリ、およびコンテナー イメージを含むコンテナー エコシステムへの管理アクセスの正確な監査証跡を維持します。 これらのログは、監査のために必要な場合があり、セキュリティ インシデント後の法的証拠として役に立ちます。 Azure ソリューションには次のものがあります。

次のステップ