今日のデジタル環境は、頻繁なセキュリティ侵害によって特徴付けられ、収益の損失、潜在的な法的責任、および顧客の信頼の喪失につながります。 ゼロトラストモデルは、組織のセキュリティ体制を改善し、セキュリティ侵害のリスクと範囲を最小限に抑えるために考案されました。
この投稿では、ゼロトラストのセキュリティについて調査し、 Docker Desktopベースの開発環境内でゼロトラストを実装するためのいくつかの戦略について説明します。 この概要は網羅的ではありませんが、組織が独自のセキュリティ戦略を改良して実装する際に構築できる基本的な視点を提供します。
ゼロトラストセキュリティとは?
ゼロトラストセキュリティモデルでは、ネットワーク境界の内部または外部のエンティティが自動的に信頼されるべきではないと想定しています。 このアプローチでは、自動的な信頼を排除し、リソースへのアクセスを許可する前に、すべての要求と操作の厳密な検証を義務付けます。 ゼロトラストは、信頼の獲得を一貫して要求することで、セキュリティ対策を大幅に強化します。
ゼロ トラストの原則と実践については、米国国立標準技術研究所 (NIST) の特別刊行物 (800- 207 — ゼロ トラスト アーキテクチャ) で詳しく説明されています。このドキュメントは、厳格なアクセス制御、最小限の特権、すべての運用属性と環境属性の継続的な検証など、ゼロトラストのコア原則を概説する権威あるガイドとして機能します。 たとえば、セクション 2です。この出版物の1 では、組織が独自のセキュリティニーズに合わせた堅牢なゼロトラスト環境を実装するために採用できる基本原則について詳しく説明しています。これらのガイドラインを参照することで、実務家はゼロトラストを包括的に理解することができ、ネットワークアーキテクチャ全体にその原則を戦略的に実装し、組織のセキュリティ体制を強化するのに役立ちます。
組織がコンテナ化されたアプリケーションやクラウドベースのアーキテクチャに移行するにつれて、ゼロトラストの採用が不可欠です。 これらの環境は、ビジネス需要を満たすためにコンテナフリートが急速に拡張および進化するダイナミズムが特徴です。 境界防御に依存する従来のセキュリティモデルとは異なり、これらの最新のインフラストラクチャには、システムの安定性を確保しながら継続的な変更をサポートするセキュリティ戦略が必要です。
ゼロトラストを最初からソフトウェア開発ライフサイクル(SDLC)に統合することは非常に重要です。 早期導入により、ゼロトラストの原則は単にデプロイ後に追加されるだけでなく、開発プロセスに組み込まれ、最初から基本的なセキュリティフレームワークが提供されます。
コンテナとゼロトラスト
コンテナ化によってアプリケーションと環境を相互に分離することで、アクセス制御の適用、より詳細な監視および検出ルールの適用、結果の監査が容易になり、ゼロトラストの実装に役立ちます。
前述のように、これらの例は Docker Desktop に固有のものですが、 Kubernetes などのオーケストレーション システムを含む、任意のコンテナベースの環境に概念を適用できます。
強固な基盤:ホストとネットワーク
ゼロトラストの原則をDocker Desktopに適用する場合、ホストシステムから始めることが重要です。 このシステムは、暗号化されたストレージの使用、オペレーティング システム内のユーザー特権の制限、エンドポイントの監視とログの有効化など、ゼロ トラスト要件も満たす必要があります。 ホスト システムのネットワーク リソースへの接続には認証が必要であり、すべての通信はセキュリティで保護され、暗号化されている必要があります。
最小特権の原則
最小特権の原則は、ユーザー、プログラム、またはプロセスが意図した機能を実行するために必要な最小限のアクセス許可のみを持ち、それ以上の権限を持たないという基本的なセキュリティ アプローチです。 コンテナの操作に関しては、この原則を効果的に実装するには、AppArmor / SELinuxの使用、 seccomp (セキュアコンピューティングモード)プロファイルの使用、コンテナがrootとして実行されないようにすること、コンテナが昇格した権限を要求または受信しないようにすることなどが必要です。
ただし、強化された Docker Desktop (Docker Business または Docker Government サブスクリプションで利用可能) は、Enhanced Container Isolation (ECI) 設定を通じてこの要件を満たすことができます。ECI がアクティブな場合、次の処理を行います。
- 権限のないコンテナの実行: ECI は、コンテナが
--privilegedフラグで起動された場合でも、コンテナ内の実際のプロセスがホストまたは Docker Desktop VM 内で昇格された権限を持たないようにします。 この手順は、特権昇格攻撃を防ぐために重要です。 - ユーザー名前空間の再マッピング: ECI では、コンテナ内のルート ユーザーが Docker Desktop VM 内のコンテナ外の非ルート ユーザーにマップされる手法を使用します。 このアプローチにより、コンテナが侵害された場合でも、潜在的な損害とアクセス範囲が制限されます。
- ファイルシステムへのアクセス制限: ECI で実行されるコンテナは、ホストマシンのファイルシステムへのアクセスが制限されています。 この制限により、侵害されたコンテナがシステムファイルを変更したり、ホストファイルシステムの機密性の高い領域にアクセスしたりするのを防ぐことができます。
- 機密性の高いシステムコールのブロック:ECIは、特定の種類の
mount操作など、攻撃で一般的に使用されるコンテナからのシステムコールをブロックまたはフィルタリングできるため、ブレイクアウトのリスクをさらに軽減できます。 - Docker エンジンからの分離: ECI は、明示的に許可されていない限り、コンテナが Docker エンジンの API と直接対話するのを防ぎ、Docker インフラストラクチャ自体を標的とする攻撃から保護します。
ネットワーク・マイクロセグメンテーション
マイクロセグメンテーションは、コンテナ間のトラフィックフローを制御することで、セキュリティをさらに強化する方法を提供します。 厳格なネットワークポリシーの実装により、許可されたコンテナのみが対話を許可され、セキュリティ違反が発生した場合の水平移動のリスクが大幅に軽減されます。 たとえば、支払い処理コンテナは、アプリケーションの特定の部分からの接続のみを受け入れ、安全性の低い他のネットワークセグメントから分離することができます。
マイクロセグメンテーションの概念は、AIシステムとワークロードにも役割を果たします。 ネットワークとデータをセグメント化することで、組織はAIインフラストラクチャのさまざまな部分に制御を適用し、トレーニング、テスト、本番環境に使用される環境を効果的に分離できます。 この分離により、環境間のデータ漏洩のリストが減り、セキュリティ侵害の影響範囲が縮小されます。
Docker Desktop の堅牢なネットワークは、マイクロセグメンテーションに対処するためのいくつかの方法を提供します。 ブリッジネットワークを利用して同じホスト内に分離されたネットワークを作成するか、コンテナを個別のMACアドレスを持つ物理デバイスとして扱うことができる Macvlan ネットワークドライバを使用することで、管理者はゼロトラストの最小特権アクセス原則に沿った正確な通信パスを定義できます。 さらに、 Docker Compose は、事前定義されたネットワーク上で通信できるコンテナを指定して、これらのネットワークを簡単に管理および構成できます。
この設定により、インフラストラクチャ レベルでのきめ細かなネットワーク ポリシーが容易になります。 また、コンテナアクセスの管理を簡素化し、厳格なネットワークセグメンテーションポリシーを適用して、攻撃対象領域を最小限に抑え、コンテナ化された環境での不正アクセスのリスクを軽減します。 さらに、Docker Desktop はサードパーティのネットワーク ドライバーをサポートしており、これを使用してこの問題に対処することもできます。
Docker Desktop でコンテナにホストとは異なるエグレス ルールが必要なユースケースでは、「エアギャップ コンテナ」を使用すると、コンテナに適用される詳細なルールを設定できます。 たとえば、コンテナはインターネットから完全に制限されていても、ローカルネットワーク上では許可されている場合もあれば、承認されたホストの小さなセットにプロキシ/ファイアウォールで接続することもできます。
Kubernetesでは、このタイプのマイクロセグメンテーションとネットワークトラフィック管理は通常、サービスメッシュによって管理されることに注意してください。
認証と承認
Dockerベースのゼロトラスト環境では、強力な認証とロールベースのアクセス制御(RBAC)を実装することが重要です。 これらの原則は、上記のようにホストとネットワークから始めて、いくつかの異なる領域で対処する必要があります。
シングルサインオン(SSO)とクロスドメインID管理システム(SCIM) を有効にして、Docker SaaSへのユーザー認証を管理するために使用する必要があります。 これらのツールを使用すると、グループを使用してアカウントレベルでロールとチームのメンバーシップを適用するなど、ユーザーの管理を改善できます。 さらに、Docker Desktop は、使用中の Docker 組織へのログインを要求し、強制するように設定して、ユーザーが他の組織や個人アカウントにログインできないようにする必要があります。
Docker Desktop でコンテナをローカルで設計、デプロイ、ビルド、テストする場合、セキュリティのベストプラクティスと原則に合わせるためには、堅牢な認証と承認のメカニズムを実装することが重要です。 コンテナのライフサイクルの各段階で厳格なアクセス制御を実施することが不可欠です。
このアプローチは、レジストリとイメージのアクセスを管理することから始めて、承認されたイメージのみが開発プロセスに取り込まれるようにします。 これは、内部レジストリを使用し、他のレジストリへのアクセスをブロックするファイアウォール規則を適用することで実現できます。 ただし、より簡単な方法は、Hardened Docker Desktop が提供する機能である レジストリ アクセス管理 (RAM) と イメージ アクセス管理 (IAM) を使用してイメージとレジストリを制御することです。
シークレット管理に関するポリシーと手順の実装 (目的に合わせて設計されたシークレット ストアの使用など) は、開発プロセスの一部である必要があります。 最後に、Enhanced Container Isolation (前述のとおり) を使用すると、コンテナの特権がベスト プラクティスに従って一貫して管理されるようになります。
この包括的なアプローチは、セキュリティを強化するだけでなく、特に機密性の高いアプリケーションデータや独自のアプリケーションデータを扱う場合に、開発環境の整合性と機密性を維持するのにも役立ちます。
監視と監査
Docker環境内のアクティビティの継続的な監視と監査は、潜在的なセキュリティ問題を早期に検出するために不可欠です。 これらのコントロールは、上記の領域に基づいて構築されており、これらのコントロールの影響の監査と監視を可能にします。
Docker Desktop は、アプリケーション プラットフォーム全体の操作に関する洞察を提供する多数のログを生成します。 これには、ローカル環境、内部 VM、イメージ ストア、コンテナ ランタイムなどに関する情報が含まれます。 このデータは、業界標準のツールによってリダイレクトおよび解析/分析できます。
コンテナのロギングは重要であり、処理のためにリモートログアグリゲーターに送信する必要があります。 最適な開発アプローチでは、開発のログ形式とログ レベルが運用環境で使用されるものを反映する必要があるため、このデータを使用して開発プロセスの異常を探すだけでなく、運用チームが運用環境がどのように見えるかを把握することもできます。
ドッカースカウト
コンテナ化されたアプリケーションがセキュリティポリシーとプライバシーポリシーに準拠していることを確認することも、継続的な監視の重要な部分です。 Docker Scout は、この取り組みをサポートするためにゼロから設計されています。
Docker Scoutは、イメージソフトウェアの部品表(SBOM)から開始し、既知および新しいCVEとセキュリティポリシーに対して継続的にチェックします。 これらのポリシーには、軽減すべき注目度の高いCVEの検出、承認されたベースイメージが使用されていることの検証、有効なライセンスのみが使用されていることの確認、イメージにroot以外のユーザーが定義されていることの確認が含まれます。 さらに、Docker Scout ポリシーエンジンを使用して、利用可能なさまざまなデータポイントを使用してカスタムポリシーを記述できます。
不変コンテナ
デプロイ後に変更されないイミュータブル コンテナの概念は、環境を保護する上で重要な役割を果たします。 コンテナを変更するのではなく置き換えることで、環境のセキュリティを強化し、実行時の不正な変更や悪意のある変更を防ぎます。
Dockerイメージ(より広義にはOCI準拠のイメージ)は、デフォルトでは不変です。 コンテナとしてデプロイされると、不変イメージの上に「スクラッチレイヤー」を追加することで、実行中に書き込み可能になります。 このレイヤーは、コンテナの寿命を超えて保持されないことに注意してください。 コンテナを取り外すと、スクラッチ層も削除されます。
docker run コマンドに --read-only フラグを追加するか、 docker compose に read_only: true キーと値のペアを追加することで、不変フラグを追加すると、Docker はルート ファイル システムを読み取り専用でマウントし、コンテナ ファイル システムへの書き込みを防ぎます。
コンテナを不変にするだけでなく、 Dockerボリューム を read/write または read-onlyとしてマウントすることも可能です。 コンテナのルートファイルシステムを読み取り専用にしてから、ボリュームの読み取り/書き込みを使用して、コンテナの書き込みアクセスをより適切に管理できることに注意してください。
暗号化
転送中と保存中の両方でデータが安全に暗号化されていることを確認することは、安全なDocker環境では交渉の余地がありません。 Docker コンテナは、コンテナ間とコンテナ環境の外部の両方で TLS を使用するように設定する必要があります。 Docker イメージとボリュームはローカルに保存され、保存時にはホスト システムのディスク暗号化の恩恵を受けることができます。
ツールチェーンの更新
最後に、Docker チームは CVE が発見されたときに継続的に改善を行い、軽減しているため、Docker Desktop が 最新バージョンに更新されていることを確認することが重要です。 詳細については、 Docker のセキュリティ ドキュメント と Docker のセキュリティに関するお知らせを参照してください。
ゼロトラスト導入における課題の克服
Docker Desktopを使用したゼロトラストアーキテクチャの実装には、課題がないわけではありません。 このような課題には、このような環境の管理の複雑さ、潜在的なパフォーマンスのオーバーヘッド、セキュリティ意識の向上に向けた組織内の文化的な変革の必要性が含まれます。 しかし、安全で回復力のあるインフラストラクチャのメリットは、これらの課題をはるかに上回るため、ゼロトラストへの取り組みと投資は価値があります。
結論
Docker Desktop環境にゼロトラストの原則を組み込むことは、高度なサイバー脅威から最新のインフラストラクチャを保護するために不可欠です。 これらの原則を理解して実装することで、組織はアプリケーションとデータをより効果的に保護し、安全で回復力のあるデジタル プレゼンスを確保できます。
さらに詳しく
- Docker Newsletter を購読してください。
- 参考記事: Docker で開発者を強化: SOC 2、ISO 27001、FedRAMP などのコンプライアンスの簡素化とセキュリティの強化。
- Docker Scout が 、本番環境に移行する前にセキュリティ問題に対処する方法をご覧ください。
- Docker Scout の正常性スコア、Docker Hub リポジトリ内のコンテナー イメージのセキュリティ評価について説明します。
- Docker デスクトップの最新リリースを入手します。
- 次のものに投票してください! 公開ロードマップをご覧ください。
- 質問がありますか? Docker コミュニティがお手伝いします。
- ドッカーは初めてですか? 始めましょう。