コンテナのセキュリティとは

コンテナのセキュリティには、Linux コンテナ (コンテナがサポートするアプリケーションからコンテナの基盤となるインフラストラクチャまで) を保護するビルド、デプロイ、およびランタイムのプラクティスを定義し、順守することが含まれます。

マイクロサービスを使用する設計パターンやコンテナ・テクノロジー (Docker や Kubernetes など) への移行が進むにつれて、セキュリティ・チームは、こうしたインフラストラクチャの移行を促進するコンテナ・セキュリティ・ソリューションの開発という課題に直面しています。コンテナのセキュリティは、統合された継続的なものでなくてはならず、また、企業の全体的なセキュリティ体制をサポートする必要があります。一般に、エンタープライズ向けの連続的なコンテナセキュリティには以下の機能が備わっています。

• コンテナパイプラインとアプリケーションをセキュリティ保護する
• コンテナデプロイ環境とインフラストラクチャをセキュリティ保護する

イメージを収集する

コンテナはファイルの層から作成されます。コンテナコミュニティでは、このようなファイルは一般に「コンテナイメージ」と呼ばれています。 

Buildah のようなツールを使用すると、OCI および Docker 互換のイメージをゼロからビルドできます。その際には既存のコンテナイメージを出発点として使用することもできます。

コンテナイメージはクラウドネイティブ環境における標準的なアプリケーション配信形式ですが、クラウドネイティブな企業であっても複数のクラウドプロバイダー間でワークロードを混在させています。理想的なコンテナセキュリティソリューションは、すべてのアーキテクチャをサポートする必要があります。

セキュリティの観点からは、最も重要なのはベースイメージ (ゴールデンイメージとも呼ばれる) です。派生イメージを作成する出発点として使用されるからです。コンテナセキュリティは、ベースイメージの信頼できるソースを見つけることから始まります。そのためには、イメージが既知の企業またはオープンソースグループからのものであること、評判の良いレジストリでホストされていること、イメージ内のすべてのコンポーネントのソースコードが参照可能であることを確認します。

ただし信頼できるイメージを使用しても、アプリケーションを追加して構成を変更していけば、新たな可変要素も導入されます。アプリを構築するために外部コンテンツを持ち込むときは、プロアクティブな脆弱性管理を念頭に置いておく必要があります。

• 企業全体で使用されているネイティブのセキュリティツールを統合して、既存のネットワークセキュリティポリシーをコンテナエコシステム全体で満たし (あるいは強化し) ます。強力なクラウドセキュリティ基準とアプリケーション・セキュリティ基準を確立します。
• ポリシーに違反していたり、文書化されたベストプラクティスに従っていなかったりする (つまりコンテナの設定ミスのある)、変更されたコンテナイメージを特定して、侵害の可能性と影響を低減させます。

コンテナが普及した理由は、アプリケーションまたはサービスのライフサイクル全体を通じて、すべての依存関係を含めて、各種のワークフローおよびデプロイターゲットに対して、ビルド、パッケージ、プロモーションが簡単になるためです。しかし、そのセキュリティにはまだ解決すべき課題があります。コンテナはワークロードレベルできめ細かいセキュリティを実装するのに役立ちます。しかし同時に、新しいインフラストラクチャ・コンポーネントや、なじみのない攻撃対象領域も導入されます。適切なコンテナ・セキュリティ・ソリューションは、実行されるコンテナ化アプリケーションだけでなく、クラスタ・インフラストラクチャと オーケストレーターのセキュリティ保護にも役立つものでなくてはなりません。

固定的なセキュリティポリシーやチェックリストでは、エンタープライズのコンテナに合わせて拡張できません。

• サプライチェーンにはさらに多くのセキュリティ・ポリシー・サービスが必要です。
• セキュリティチームは、コンテナ化された環境によるネットワークとガバナンスのニーズを調整する必要があります。
• ビルド、メンテナンス、サービスの各ステージで使用されるツールには、それぞれ異なる権限ポリシーが必要です。

効果的なコンテナセキュリティプログラムは、イメージをデプロイする前に脆弱性をリアルタイムで修正し、攻撃対象領域を縮小させます。セキュリティをコンテナパイプラインに組み込んでインフラストラクチャを保護すると、コンテナが確実でスケーラブルなものになり、信頼性が高まります。

コンテナイメージを収集するときには、以下の事項を検討してください。

• コンテナイメージは署名済みで、信頼できるソースから取得されているか？
• ランタイムレイヤーとオペレーティングシステム・レイヤーは最新のものか？
• コンテナはどの程度の期間と頻度でアップデートされているか？
• セキュリティリスクは特定されているか、その問題はどのように追跡されるか？

イメージを取得したら、次のステップとして、チームが使用するすべてのコンテナイメージへのアクセスとプロモーションを管理します。これは、ダウンロードするイメージと、ビルドするイメージの両方を保護するということです。プライベートレジストリを使用すると、ロールベースの割り当てによってアクセスを制御でき、関連メタデータをコンテナに割り当ててコンテンツ管理をサポートすることもできるようになります。このメタデータは、既知の脆弱性を特定して追跡するのに役立ちます。プライベート・コンテナ・レジストリは、保管したイメージに対するポリシーを自動化して割り当てる機能も実現できるので、コンテナ環境に脆弱性を招く原因となる人的ミスを最小限に抑えられます。

アクセスの管理方法を決定するときには、以下の事項を検討してください。

• コンテナイメージの管理にどのようなロールベースのアクセス制御を使用できるか？
• イメージを分類するタグ付け機能があるか？開発用のみ、テスト用、プロダクション用に承認済みと、イメージにタグ付けできるか？
• 既知の脆弱性を追跡できるように、レジストリから視覚的なメタデータが得られるか？
• レジストリを使用してポリシーを割り当てて自動化できるか (署名のチェック、アプリケーションのコードスキャンなど)？

パイプラインの最後のステップは、デプロイです。ビルドが完了したら、業界標準に従って管理する必要があります。ここでのポイントは、特に新しい脆弱性が検出される中で、ポリシーを自動化してセキュリティの問題があるビルドを洗い出す方法を理解することです。脆弱性スキャンは確かに重要ですが、コンテナ環境の保護に使用されるセキュリティイニシアチブ全体の一部にすぎません。

コンテナへのパッチ適用は再ビルドほど良い解決策ではないので、セキュリティテストの統合では自動再ビルドをトリガーするポリシーを考慮する必要があります。このステップの最初のパートとして、問題を追跡してフラグを立てられるコンポーネント分析ツールを実行します。2 番目のパートでは、自動化されたポリシーベースのデプロイ向けのツールを確立します。

セキュリティテストを統合してデプロイを自動化するときには、以下の事項を検討してください。

• どのようにして、実行中のコンテナへのパッチ適用を防ぎ、トリガーを使用してコンテナを再ビルドして自動アップデートで置換するか？

コンテナセキュリティのもう 1 つの層は、コンテナのノード/ホストのオペレーティングシステム (OS) が提供する分離です。コンテナ分離を最大化するホスト OS が必要です。これは、コンテナデプロイ環境を防御するための大きな部分を占めます。ホスト OS はコンテナランタイムを使用して有効化され、理想的にはオーケストレーション・システムを通じて管理されます。コンテナプラットフォームに回復力を持たせるには、ネットワーク・ネームスペースを使用してアプリケーションと環境を隔離し、ストレージをセキュアなマウントによって接続します。API 管理ソリューションには、認証と認可、LDAP 統合、エンドポイントアクセス制御、レート制限を含める必要があります。

コンテナ・インフラストラクチャの保護方法を決定するときには、以下の事項を検討してください。

• どのコンテナが互いにアクセスする必要があるか？どのように互いの存在を検出するか
• 共有リソース (ネットワークとストレージなど) へのアクセスとその管理をどのように制御するか？
• コンテナの正常性をどのように監視するか？
• 需要に対応するため、アプリケーション容量の自動的なスケーリングをどのように行うか？
• ホストのアップデートをどのように管理するか？すべてのコンテナを同時にアップデートする必要があるか？

Red Hat® OpenShift® には、Red Hat Enterprise Linux® が含まれています。コンテナ・アプリケーションのライフサイクルを自動化し、セキュリティをコンテナ・パイプラインに統合し、DevOps 戦略から DevSecOps 戦略への移行を可能にします。Red Hat のコンテナカタログを利用すると、多数の認定済みイメージ、言語ランタイム、データベース、Red Hat Enterprise Linux を実行していればどこからでも実行できるミドルウェアにアクセスできます。Red Hat からのイメージは常に署名済みで、出処と整合性が検証されています。

Red Hat は、コンテナイメージに新たに検出された脆弱性 (継続的にアップデートされ、公開された正常性インデックスを含む) がないか監視し、セキュリティアップデートとコンテナ再リビルドをリリースし、パブリックレジストリにプッシュします。Red Hat Advanced Cluster Security for Kubernetes は、DevOps やセキュリティツールと統合することで、脅威を軽減し、アプリケーションの運用リスクを最小限に抑え、セキュリティポリシーを強化します。

Red Hat のセキュリティパートナーは認証済みの統合によってコンテナセキュリティ機能を拡張および強化します。Red Hat OpenShift プラットフォームにはセキュリティパートナーのソリューションを補完するセキュリティが組み込まれており、DevOps ライフサイクル全体でアプリケーションやコンテナのセキュリティを保護します。

さらに、この他にも極めて優れた機能を備えています。

• Web スケールのコンテナ・オーケストレーションと管理
• マルチユーザー・コラボレーション機能を備えたリッチな Web コンソール
• CLI および IDE インタフェース
• CI との統合
• 自動化および Source-to-Image の構築
• デプロイの自動化
• リモート・ストレージ・ボリュームのサポート
• 単純化されたインストールと管理
• 幅広いプログラミング言語、フレームワーク、サービスのサポート