コンテナを俊敏かつ安全にするにはどうすればよいでしょうか?これらの点に注意する必要がある

技術開発の目的は問題を解決することですが、ほとんどの新興技術の誕生と普及は、しばしば新たな問題をもたらします。同じ状況は、過去 10 年間に IT 環境全体に混乱をもたらした 3 つの主要な新興テクノロジー、つまりマイクロサービス、コンテナ、Kubernetes でも​​発生します。マイクロサービス アーキテクチャとコンテナ化されたアプリケーションは多くの問題を解決しますが、管理、セキュリティ、コンプライアンスの面で新たな課題ももたらします。

こうした新しいテクノロジーを効果的に活用するための前提条件は、当然ながら、こうした課題に冷静に対処することです。この記事では、企業がマイクロサービスとコンテナ テクノロジーを導入する際に直面するさまざまな課題と、その問題の解決に役立つベスト プラクティスについて説明します。

[[353710]]

セキュリティ、コンプライアンス、コンテナ化されたアプリケーション

マイクロサービスとコンテナは、一連のレイヤーを導入し、それらのレイヤーの一部をアプリケーションのデプロイメントに移行するため、IT チームに多くの新たな課題をもたらします。複雑さが増すにつれて、セキュリティとコンプライアンスの要件を満たすことがますます困難になります。

具体的には、現在、一般的なマイクロサービス アプリケーションのデプロイメントには次のレイヤーが含まれています。

• アプリケーション コードを含むコンテナー イメージ。
• Docker などのコンテナ ランタイムは、単一のコンテナを起動するために使用されます。
• すべてのコンテナを管理するKubernetes。

コンテナ イメージ、ランタイム、Kubernetes オーケストレーション ツールをホストする基盤となるインフラストラクチャ。

各レイヤーには、独自の潜在的な脆弱性とセキュリティ リスクが存在します。コンテナ イメージに悪意のあるコードが含まれていたり、コンテナ ランタイムまたは Kubernetes が権限昇格攻撃に対して脆弱であったり、コンテナ クラスター内の特定のリソースへの不正アクセスに使用できる脆弱性が含まれていたりする可能性があります。ホスト インフラストラクチャは、オペレーティング システム レベルまたはクラウド プロバイダーの IAM フレームワークの脆弱性や誤った構成により侵害される可能性があります。

さらに、コンテナ化された環境で強力で信頼性の高いセキュリティ システムを構築するには、次のような独自の特別な要件があります。

• コンテナとポッドを相互に分離します。
• ホストを各コンテナとポッドから分離します。
• コンテナ クラスターを構成するさまざまなネットワークを管理し、ネットワークが相互に分離されていることを確認します。
• コンテナ クラスターが依存する永続データ ストレージを保護します。

非常に動的で絶えず変化する環境におけるコンプライアンス要件を満たします。しかし、監査全体は「ウォーターフォール」スケジュールに従って完了するまでに数週間、場合によっては数か月かかることが多く、実際の状況の変化に対応することが困難です。

仮想マシンなどの従来のアーキテクチャと比較すると、上記の要件は IT チームの保護作業に多くの問題をもたらします。対照的に、従来の仮想マシンは自然に互いに分離されており、通常、異なるネットワーク、アプリケーション コンポーネント、またはストレージ リソース間の分離は必要ありません。これらすべては、コンテナ化されたアプリケーションを展開する際に IT チームが直面しなければならない課題となっています。

コンテナは新たなセキュリティの機会をもたらす

これを見ると、コンテナとマイクロサービスには本質的にセキュリティと信頼性が欠けていると感じるかもしれません。つまり、さらなる努力を重ねることでのみ、適切に管理・保護することが可能になるのです。実際、コンテナ テクノロジーは一連の新たなセキュリティ上の課題をもたらしましたが、IT チームには対処するための新しいツールと戦略も提供されました。

1 つ目は、環境構成に対して宣言的なアプローチを採用できることです。 Kubernetes クラスターでは、ほとんどすべてを単純な JSON または YAML ファイルを通じて構成できます。したがって、IT チームは、クラスターの動作方法、さまざまなコンポーネントの分離方法などを定義する一連のファイルを作成し、それに応じて環境を構築できます。この点では、Kubernetes 環境構成にセキュリティ権限を統合する難しさは、最初に環境を構築してから追加のセキュリティ保護を提供する場合よりもはるかに低くなります。

2 番目に、Kubernetes とコンテナを使用すると、不変のインフラストラクチャを簡単に構築できます。つまり、ユーザーは通常、実行中のコンポーネントを更新するのではなく、以前のものを完全に元に戻すことで、新しいコンテナとポッドをデプロイします。不変のインフラストラクチャにより、チームは新しいソフトウェア リリースを展開前に徹底的に検証できるようになり、偶発的な構成の問題によって運用環境にセキュリティ リスクが導入される可能性が軽減されます。

したがって、コンテナ、マイクロサービス、Kubernetes によって、セキュリティとコンプライアンスの実現が必ずしも困難になるわけではありません。言い換えれば、レイヤーやコンポーネントを追加しても、IT チームが管理する必要がある攻撃対象領域が拡大するだけです。しかし同時に、新しいテクノロジーは新しいツールや戦略ももたらし、最終的には攻撃対象領域を完全に管理できるようになります。

最新のアーキテクチャを保護するためのベストプラクティス

上記の特定の戦略に加えて、組織はコンテナベースおよび Kubernetes ベースの環境のセキュリティ レベルを最大化するために、次の重要な方法を採用することもできます。

Kubernetes クラスターが稼働すると、その極度の複雑さにより保護作業に大きな負担がかかります。したがって、チームはクラスターを起動する前にセキュリティを設計し、関連するリスクを軽減する必要があります。前述のように、宣言的な構成はこの目標の達成に役立ちます。

同様に、IT チームは、コンテナ化されたアプリケーションの展開と管理に使用するコードにセキュリティ保護を完全に組み込む必要があります。言い換えれば、実際の環境で脆弱性をスキャンしたり、悪意のある動作を追跡するだけでは不十分です。環境を制御しアプリケーションを実行するために使用されるコード自体が安全であることを確認するとともに、安全でない構成を自動的に継続的に監査して検出する必要があります。

このようにして、IT チームは、問題が発生してから脆弱性が発見される、最初に破壊して後で修正するリアクティブ アプローチから、環境がデフォルトで安全であるプロアクティブ アプローチに移行できます。

Kubernetes 環境には多数のレイヤーが含まれており、各レイヤーには独自のタイプのセキュリティ監査と監視があるため、IT チームはそれらを個別に保護するための対応する対策を講じる必要があります。シンプルなインフラストラクチャとは異なり、コンテナとマイクロサービスは、1 つのレイヤーだけに焦点を当てて効果的に保護することはできません。

Kubernetes は、IT チームが分離を実現し、セキュリティ リスクを軽減するために使用できるさまざまなネイティブ セキュリティ機能を提供します。ただし、Kubernetes 自体はセキュリティ ツールではないことを覚えておくことが重要です。そのため、これらのネイティブ ツールの制限を十分に理解し、セキュリティ ギャップを埋めるために他にどのようなツールを導入する必要があるかを理解しておく必要があります。

要約する

マイクロサービス、コンテナ、Kubernetes で構築された最新のインフラストラクチャでは、従来のアプリケーションよりも攻撃対象領域が広く複雑になっています。しかし、複雑さが増すにつれて、現代の環境におけるセキュリティ上の課題に対処するための新しいツールや戦略を適用する大きな機会が生まれます。したがって、Kubernetes デプロイメントのセキュリティを確保するための鍵は、これらの機会を最大限に活用することにあります。現代の環境で単に従来のセキュリティ慣行に従うことは、ビジネス システムに「時限爆弾」を仕掛けるのと同じことになります。