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

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

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

コンテナ・オーケストレーター (すなわち Kubernetes) はコンテナセキュリティにおいて重要な役目を果たし、豊富なコンテキストデータにアクセスでき、可視性とコンプライアンス、コンテキストベースのリスクプロファイリング、ネットワーク、ランタイム検出が改善されます。効果的なコンテナセキュリティは、デプロイメント、Pod、ネットワークポリシーなど、Kubernetes コンストラクトを基に構築されます。たとえば Kubernetes ネットワークポリシーは、Pod 間通信を制御し、攻撃者の影響範囲を最小化するために使用される、組み込みセキュリティ機能です。

一般に、エンタープライズ向けの連続的なコンテナセキュリティには以下の機能が備わっています。

• コンテナパイプラインとアプリケーションをセキュリティ保護する
• コンテナデプロイ環境とインフラストラクチャをセキュリティ保護する
• コンテナ化されたワークロードをランタイム時にセキュリティ保護する

コンテナセキュリティ実装の取り組みの事例をご覧ください。

従来のソフトウェア開発では、セキュリティレビューは開発の最後にある一連の最終テストに位置づけられます。しかし先進的なクラウドネイティブ開発ワークフローでは、攻撃対象領域ははるかに広いため、セキュリティはより複雑な問題になります。クラウドネイティブ環境では、コンテナは標準アプリケーション提供フォーマットであり、コードは頻繁に更新され、複数のリポジトリから挿入されます。構成ミスなどの人的ミスにより、開発およびデプロイサイクルの多数の時点で不正アクセスが行われる隙が生じます。セキュリティの脆弱性は、事実上あらゆる場面で発生します。この理由から、セキュリティは継続的なプロセスでなければなりません。

コンテナデプロイメントを自動化で処理するのと同様に (Kubernetes などのコンテナ・オーケストレーション・ツールを使用)、セキュリティも自動化する必要があります。DevSecOps の原則 (DevOps へのセキュリティ強化を追加するために作成されたコンセプト) を使用すると、開発サイクル全体を通じてコードを継続的に吟味し、チェックできます。見逃されていたために後になってからいきなり発覚するのではなく、脆弱性を早期段階で発見して即座に修復できます。コンテナはイミュータブルなので、コンテナセキュリティでは、コードの実行中ではなくビルド段階でコードにパッチを適用し、コンテナを破壊して再ビルドしたときに脆弱性が再度発生しないようにします。

コンテナイメージからマルウェアおよびその他のセキュリティ脆弱性をスキャンすることは重要なステップで、複数あるセキュリティレイヤーの 1 つにすべきです。組織は、ソフトウェア・サプライチェーン全体のセキュリティを十分に検討する必要があります。つまり、依存関係やランタイム環境を含め、コンテナ化ソフトウェアの開発およびデプロイメントにおけるすべてのステップを対象とします。 

サプライチェーン・セキュリティを考慮するコンテナ化された開発の戦略の具体例をいくつか紹介します。

• 信頼できるコンテンツとエンタープライズグレードのコンテンツリポジトリで、高度なセキュリティとアクセス制御によって事前に強化されたイメージを提供する
• ゼロトラストアプローチで、重要なリソースには最低限のアクセスレベル���割り当てる
• Policy as Code でセキュリティ制御を CI/CD パイプラインに直接埋め込む
• 署名と検証で認証を施行し、コンテナイメージが改ざんされていないことを確認して信頼を確立する
• GitOps プラクティスでアプリケーションおよびコンテナのセキュリティ構成の管理をサポートする

イメージを収集する

コンテナは、コンテナイメージと呼ばれるファイルの層から作成されます。 

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

コンテナイメージはクラウドネイティブ環境における標準的なアプリケーション配信形式ですが、クラウドネイティブな企業であっても複数のクラウドプロバイダー間でワークロードを混在させています。理想的なコンテナセキュリティ・ソリューションは、すべてのアーキテクチャをサポートします。プライベートハードウェア、共有データセンター、または Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Platform などのパブリッククラウドのどれでインフラストラクチャが実行されているかは関係しません。

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

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

• レジストリに組み込まれているか、独立したイメージスキャナーを使用して、一定間隔ですべてのイメージをスキャンします。特定の言語、パッケージ、イメージレイヤーに基づいてスキャンするスキャナーを探しましょう。
• ポリシーに違反していたり、文書化されたベストプラクティスに従っていなかったりする (つまりコンテナの設定ミスのある)、変更されたコンテナイメージを特定して、侵害の可能性と影響を低減させます。

コンテナイメージ・セキュリティに関するブログ記事を読む

脆弱性の予測と修正

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

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

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

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

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

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

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

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

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

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

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

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

• いずれかのコンテナに、プロダクション環境にデプロイする前に修正が必要な、既知の脆弱性が含まれていないか？
• デプロイメントは正しく構成されているか？強い特権が必要ではないのに過剰な特権が付与されたコンテナはあるか？読み取り専用の root ファイルシステムを使用しているか？
• CIS Benchmarks および NIST SP 800-190 へのコンプライアンス体制はどのような状態か？
• ネットワークポリシーや名前空間などの組み込み機能を使用して、機密性があると見なされるワークロードを分離しているか？
• SELinux、AppArmor、seccomp プロファイルなどの組み込みセキュリティおよび強化機能を使用しているか？

コンテナセキュリティはテストおよびデプロイメントの後も継続し、コンテナ化アプリケーションの実行中にまで及びます。脅威検出、ネットワークセキュリティ、インシデント対応などの側面の関連性が高くなります。

ランタイム時に、アプリケーションは予測不可能な現実世界の脅威にさらされ、ビルド時に見逃された脆弱性や構成ミスが悪用されかねません。ランタイムセキュリティは、予期しない方法で動作しているアプリケーションの検出を対象に含める必要があります。ランタイム時の異常検出は、特権昇格、クリプトマイニング、予期しないネットワークフロー、コンテナエスケープ、その他の安全ではない動作を特定できます。

ネットワーク・セグメンテーションは、攻撃対象領域を最小化するためのもう 1 つの検討事項です。Kubernetes では、デフォルトのネットワークポリシーでは Pod はクラスタ内の他の Pod と通信できます。ゼロトラストポリシーを施行すると、1つの Pod が侵害されてもそのクラスタ内にある他のすべての Pod は侵害されないようにすることができます。

最後に、インシデント対応戦略によって、チームはイベントに適切に対応できます。対応には、セキュリティ情報およびイベント管理 (SIEM) システムにイベントを送信する、アプリケーションオーナーに詳細情報およびデプロイメントに修復が必要なステップを通知する、さらには自動的に Pod を強制終了して再起動するなどがあります。対応として、実行中のコンテナにパッチを提供するのではなく、問題のあるコンテナを再ビルドして再デプロイするという手順に従います。

コンテナセキュリティのもう 1 つの層は、コンテナのノード/ホストのオペレーティングシステム (OS) が提供する分離です。コンテナ分離を最大化するホスト OS が必要です。これは、コンテナデプロイ環境を防御するための大きな部分を占めます。コンテナ化された Kubernetes 環境のホスト OS はコンテナ間で共有され、コンテナランタイムによって管理されます。これは Kubernetes と連携してコンテナ (またはコンテナの Pod) を作成して管理します。 

1 つの侵害されたコンテナがホスト OS およびその他のすべてのコンテナを侵害しないように、ホスト OS はコンテナから切り離される必要があります。コンテナプラットフォームに回復力を持たせるには、ネットワーク・ネームスペースを使用してアプリケーションと環境を隔離し、ストレージをセキュアなマウントによって接続します。コンテナランタイムがホストネットワーク名前空間、IPC 名前空間、または UPC 名前空間を共有するように構成してはいけません。事前に強化され、コンテナに最適化されたホスト・オペレーティングシステムを選び、ホスト脆弱性スキャニングを使用してください。

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 Service Interconnect は、コンテナが互いにアクセスしたり通信したりできるようにして、組織のセキュリティ��ユーザーのデータに加わるリスクを最小化します。

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

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

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