アカウント ログイン

組織がコンテナベースのエコシステムを採用するにつれ、継続的な IT セキュリティとコンプライアンスのアプローチを、従来のシステムセキュリティ評価から、クラウドベースのテクノロジーの運用方法を考慮した新しいメソドロジーに移行させる必要があります。コンテナは、仮想化環境でワークロードまたはアプリケーションをパッケージ化することにより、クラウド・コンピューティングの運用環境における依存関係をなくすことができます。このようなアプリケーションまたはワークロードはすべて、ホスト環境におけるセキュリティ面の利点を継承しつつ、ホスト環境で独立して動作します。コンテナテクノロジーは、ステートレスエンティティまたはイメージのように、デプロイはされるものの変更はされない、不変的概念を実装しています。

コンテナの登場は、ソフトウェア開発文化や、組織内における IT セキュリティの評価方法を破壊しました。従来の開発および運用プラクティスはコンテナ化された環境には直接適用できない場合があるため、組織はそれぞれの機能形態に最適な DevOps モデルに適応するように移行していく必要があります。セキュリティチームにとっては、新しい技術を使用して単にエンドポイントエージェントをインストールしたり、Secure Shell Protocol (SSH) プロトコルでリモート接続したりすることは不可能で、エージェントベースのソリューションを統合しようとすると、課題が浮上します。情報システムのリソースへのアクセスや管理には、従来からある共有システムのサービスアカウント方式ではなく、API (アプリケーション・プログラミング・インタフェース) を活用したソリューションが推奨されます。

ただし、ワークロードによっては Kubernetes (コンテナ化された機能をより複雑なエンタープライズ・アプリケーションにオーケストレーションする標準プラットフォーム) の恩恵を受けない場合があります。場合によっては、General Purpose Operating System (GPOS) または Single Purpose Operating System (SPOS) 環境のほうが適切に動作することがあります。GPOS の例は Red Hat Enterprise Linux (RHEL) ですが、SPOS の例は Red Hat Enterprise Linux CoreOS (RHCOS) です。Kubernetes は、高可用性 (HA) 機能を備えた分散アーキテクチャが不要な場合や、専門家の要員数が足りない場合に、リスクをもたらす可能性があります。技術関連のあらゆる点でも該当するように、アーキテクチャを不必要に複雑化することは避けるようにします。

組織が新たなリスクを発生させることなく、実際のコンテナベース環境に向け、効果的に準備を進めていく方法として、以下が挙げられます。

  • 開発、運用、セキュリティなどのロールすべてにわたり、ソフトウェア開発ライフサイクル (SDLC) に携わる人材に向けた教育やトレーニングを提供して、変化するクラウド技術のパラダイムを経験することでクラウド技術の理解を深める。

  • 個別の情報システム、含まれる可能性のあるデータの種類、許容範囲のリスクに合わせてカスタマイズした制御ベースラインを実装する。

  • コンテナ、そのアプリケーション、およびコンテナ化されたアプリケーションをホストする重要なテクノロジーを保護するソリューションを分析する。

Podman:コンプライアンス対応のソリューション

Podman (RHEL サブスクリプションに含まれる Pod マネージャーツール) は、アプリケーションの検索、ビルド、実行、共有、およびデプロイ用に設計された Open Containers Initiative (OCI) に準拠したソリューションです。Podman を使用すると、移植や再利用が可能な方法で自動的にアプリケーションをパッケージ化して実行できます。また、Podman は、Kubernetes なしに操作でき、アーキテクチャが複雑化する可能性を軽減できるため、コンテナベースのオーケストレーターの採用を躊躇しているセキュリティおよびコンプライアンスチームの興味を引き付けるものとなるでしょう。

アメリカ国立標準技術研究所の Special Publication 800-190 (NIST SP 800-190) Application Container Security Guide は、「単一ホストの OS カーネルに同じ目的、機密性、脅威への姿勢を持つコンテナのみをまとめる」際の指針となります。これは、連邦情報処理規格 (FIPS:Federal Information Processing Standards Publication) 199 Standards for Security Categorization of Federal Information and Information Systems に規定されている要件を満たすための参考資料となります。Podman は、イメージレジストリ、イメージ、カーネル、ストレージ、ネットワーク、1 つ以上の実行中のコンテナを Pod 本体ですべて管理することで、同じ目的を持つコンテナをグループ化できるようにします。これにより、対象となる動作環境で、分類レベルが異なるアプリケーションを分類して管理する運用が簡素化され、より一層のリスク管理が可能になります。

Podman は、リソースをルートレス (つまり特権なし) で設定してアプリケーションのセキュリティを強化する手段にもなります。これは RHEL 8 のデフォルト設定ですが、RHEL 7 では最小限の作業で設定できます。Podman は、リソースの構築や実行に管理者権限 (または sudo) を必要とするデーモンやシステムサービスを実行しないので、アプリケーションのセキュリティレベルを強化できます。このようにセキュリティレベルが強化されることで、コンテナイメージに脆弱なソフトウェアパッケージからの弱点が含まれる場合にアプリケーションだけでなく、ホスト環境の保護も強化します。

指標となるコントロールの相関関係

ここでは、必要とされる運用機能を確保するという観点から、一般的なコントロール (NIST SP 800-190 から抜粋) をいくつかサンプルとして選択して紹介します。(もちろん、環境はそれぞれ異なるので、自身のリスクと脅威を踏まえて、あらゆる技術の利用を評価する必要があります)。

ネットワーク分離

  • 3.3.3 適切に分離されていないコンテナ間のネットワークトラフィック

  • 3.3.4 ワークロードの機密レベルの組み合わせ

  • 3.4.2 バインドされていないネットワークへのコンテナからのアクセス

Podman には Container Network Interface (CNI) を管理する機能があるため、Pod をホスト上の分離された環境/仮想ネットワークに残すことができます。コンテナが使用できるように、完全に分離された仮想ネットワークがホストに構築されます。さらに、Podman は Netavark および Aardvark ベースのネットワークスタックを使用するため、コンテナのパフォーマンスの向上や IPv6 サポート向けに複数のネットワークをアタッチするなど、ネットワークな詳細な制御を可能にしています。CNI を使用した Podman の概要は こちら を参照してください。

デーモンなしでの操作

  • 4.5.4 不適切なユーザーアクセス権限

  • 5.2 コンテナランタイムの悪用

通常、Container Runtime Interface (CRI) には、ホスト上で昇格した特権で実行するデーモンがあります。Podman にはデーモンが必要ないため、追加の特権が割り当てられていない任意のユーザーを使用できます。

実行中のコンテナのほかにも、graphroot、runroot、レジストリ設定、ボリュームなどのローカル設定が分離されます。そのため、ホームディレクトリの利便性を活用して、ユーザー別のデータの境界が考慮されます。

参考までに、graphroot はコンテナ・ストレージ・プログラムが作成した書き込み可能なコンテンツすべてを保存するディレクトリを、runroot はコンテナ・ストレージ・プログラムが作成した一時的な書き込み可能なコンテンツすべてを保存するディレクトリを指します。

ユーザーの namespace

  • 3.1.5 信頼できないイメージの使用

  • 3.3.1 バインドされていない管理者アクセス

  • 4.5.5 ホストファイルシステムの改ざん

Podman にはデーモンを利用しない特性があるので、ホスト上のユーザーはそれぞれ、namespace として機能し、ネットワーク、ボリューム、シークレットなど、コンポーネントをさらに分離することができます。

シークレット

  • 3.1.4 組み込まれた平文シークレット

Podman は、ホスト上にあるシークレットを作成して管理できるので、コンテナとホストの間で機密情報をさらに分離できます。

シークレットは、コンテナ内ではなく、ホスト上のローカルに保存されます。その後、シークレットの情報はコンテナ内にマウントされ、アクセスできるようになります。こうすることで、イメージに埋め込まれたレジストリに (または、最悪の場合、デスクに平文で) 機密情報が保存されないようにします。

設定可能なレジストリポリシー

  • 3.2.1 レジストリへの安全ではない接続

  • 3.2.2 レジストリにある古いイメージ

  • 3.2.3 不十分な認証および認可制限

署名済みレジストリ、ミラーリングレジストリ、信頼できる/信頼できないレジストリは、すべてホスト上で設定できるので、イメージをプルするための制御ポリシーを指定できます。

この機能を探るために、CRI-O (Red Hat OpenShift および Kubernetes プロジェクトのランタイム) も /etc/containers/registries.conf の設定ファイルを使用しています。管理者は、レジストリの認証情報を保存して参照するクレデンシャルヘルパーを設定して、ミラーリングのデフォルトレジストリや TLS の有効化を構成できます。これは、Podman を使用して全ユーザーに対して、ユーザーごとに (グローバルのデフォルト設定とは別に) 設定できます。

今後の実装

ここまで、Podman が提供する基本的なセキュリティ制御の原則をいくつか紹介してきました。今後の記事では、Podman でさらにアプリケーションを保護する方法、Podman が動作するホスト、一般的なコントロール (NIST SP 800-190 を例として紹介) との相関関係について、掘り下げていく予定です。


About the authors

Trevor is a Solutions Architect supporting Federal customers with identifying solution capabilities to support business or mission processes, whether it is automation priorities, AI/ML enablement, or working with the security teams to achieve systems authorizations.

Read full bio

Employed at Red Hat since 2020 and advocate of Kubernetes since 2017, Samuel is passionate about working with baremetal and underying configuration. Everything from massive compute machines to SoC boards can become a node in his hands.

Read full bio
Red Hat logo LinkedInYouTubeFacebookTwitter

製品

ツール

試す、買う、売る

コミュニケーション

Red Hat について

エンタープライズ・オープンソース・ソリューションのプロバイダーとして世界をリードする Red Hat は、Linux、クラウド、コンテナ、Kubernetes などのテクノロジーを提供しています。Red Hat は強化されたソリューションを提供し、コアデータセンターからネットワークエッジまで、企業が複数のプラットフォームおよび環境間で容易に運用できるようにしています。

ニュースレター「Red Hat Shares」を購読する

今すぐ登録する

言語を選択してください

© 2022 Red Hat, Inc. Red Hat Summit