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

コンテナセキュリティといっても、物理的な輸送用コンテナに関する話ではありません。テクノロジー分野での「コンテナ」は、コンテナ化されたソフトウェア環境を意味します。具体的には、ソフトウェアアプリケーションのコンポーネントを単独で実行するのに必要なすべてのパッケージ、ライブラリ、依存関係を含む環境のことです。

このような環境は、最小限の仮想化オペレーティングシステム(OS)と見なすことができます。コンテナは、ソフトウェアアプリケーションを実行するためのポータブルで再利用可能な自動化システムを提供します。

ソフトウェア開発チームの変化するニーズに対応するため、コンテナはオーケストレーションされ、調整されます。今日の組織は、コンテナを活用することで、DevOpsやアジャイルといった最新のソフトウェア開発ライフサイクル(SDLC)フレームワークで期待されるように、新しい製品機能の開発からリリースまでのサイクルを短縮し、市場への投入を迅速化できます。

開発サイクルの後にセキュリティチェックを行うことに慣れている開発チームにとって、このようなコンテナの保護は大変な作業に感じられるかもしれません。しかし今日、DevOpsチームではセキュリティ対策を初期段階から組み込む動きが進んでいます。そこで、コンテナセキュリティの重要性について考えてみましょう。

コンテナと従来の仮想化の違い

OSレイヤーと依存関係が複数のソフトウェアコンポーネント間で共有される従来の仮想化モデルと比べて、コンテナテクノロジーは何が違うのかを見ていきましょう。

コンテナテクノロジーは、主に次のような属性を共有します。

ポータビリティ

コンテナテクノロジーは、SDLCパイプラインのあらゆるステージで移植可能です。開発用にビルドしたコンテナイメージは、必要な構成、依存関係、ライブラリが常に共有されていれば、テスト、QA、本番環境の各ステージで変更を加えることなく再利用できます。

また、ベンダープラットフォーム間やサービスデリバリーモデル間でも移植可能です。たとえば、基盤となるホストOSによってサポートされている限り、コンテナはプライベート、パブリック、マルチクラウド、仮想化データセンターのいずれの環境でも実行できます。

最小限

アプリケーションコンテナは、アプリケーションコンポーネントの実行に必要な最小限のソフトウェアパッケージで構築されています。アプリケーションプロセスの実行に必要なOS機能のみを実行し、それ以外のOS機能はホストOSによって実行されます。

さまざまなOS機能のセットを必要とする複雑なアプリケーションの場合は、複数のコンテナがマイクロサービスアーキテクチャの一部として開発される場合もあります。

コンテナは、ソフトウェアをパッケージ化し、導入し、実行するための手法です。1つの巨大なモノリシックアプリケーションをコンテナとして持つこともできれば、コンテナをまったく使わないマイクロサービスでアプリケーションを構成することもできます。

宣言型

コンテナテクノロジーでは宣言型プログラミングが使用されているため、ユーザーは基盤となるハードウェアの運用プロセスが記述されたデータを解析できます。このデータには、OS、パッケージ、およびネットワーク構成に関する情報が含まれている場合があります。

不変性

コンテナの状態は、デプロイされ、実行される時も一貫性が保持されます。したがって、コンテナに加えた変更は次のように扱われます。

• 実行時には適用されません。
• 必要な変更を適用するために、新しいコンテナをゼロから作成することが必要になる場合があります。
• 実行時にアプリケーションの構成や動作を変更するには、環境変数を使用します。

不変性とデータの永続性

当然ながら、前述の特性はアプリケーションとデータのやり取りにも影響します。具体的には、データの永続性、つまりコンテナ終了後のデータの存続期間と取得に関わります。コンテナは、分離されたエフェメラル(一時的)な状態で動作するように設計されているため、データの永続性を確保するには、外部のデータベースまたはクラスターストレージシステムとの統合が必要になります。

コンテナテクノロジーの移植性と宣言型の特性により、さまざまなチームが一貫した構成や設定のコンテナ実行環境を導入できます。

また、コンテナの不変性は、「自分のマシンでは動く」というよくある問題にも対応します。コンテナでは必要なすべての依存関係とライブラリがパッケージ化されているため、実行環境を異なるマシンやホストOSで動作させるためにユーザーが調整する必要はありません。

コンテナの保護に関する課題

サイバーセキュリティに関して仮想マシンと比較すると、上記の特性を持つコンテナには特有の課題が伴います。

複数の独立した環境コンポーネントの存在

モノリシックな環境では、アプリケーションを実行するために多岐にわたる環境オブジェクトが必要になります。これには、同じインフラ環境で複数のアプリコンポーネントを実行する目的に特化した、移植性のないリソースも含まれます。

一方、コンテナとマイクロサービスには、分離されたコンテナ内で実行されるすべてのアプリコンポーネント向けにプロビジョニングされた、複数の独立したコンポーネントが含まれます。

たとえば、Webサービスでは、フロントエンドのWebサーバーVMとバックエンドのデータベースインフラストラクチャだけを用意すれば済む場合もあります。これに対してマイクロサービスでは、さまざまなアプリケーションコンポーネントやサービスのために、フロントエンドとバックエンドで複数のコンテナを実行する必要がある場合があります。

変更頻度の高さ

俊敏性はコンテナテクノロジーの主要なセールスポイントであり、このおかげで開発者は、新しいアプリケーション機能を頻繁にデプロイできます。マイクロサービスベースのSDLCプロセスでコンテナ環境を新たに構築したり頻繁に変更したりするには、このような動的な運用に対応できるセキュリティツールやセキュリティ対策が必要になります。

サイバーセキュリティに対する責任の分散

開発者は、SDLCの上流プロセスで構築および配布するコンテナに対して、責任を持って効果的なセキュリティ戦略を実施する必要があります。たとえば、コンポーネントの1つに脆弱性が見つかり、セキュリティパッチが提供された場合、開発者はそのコンテナイメージを更新することを求められます。このようなセキュリティ態勢を確立するには、開発者、インフラストラクチャチームと運用チーム、およびサイバーセキュリティエキスパートが組織内で緊密に連携することが欠かせません。

ポータビリティに対応したサイバーセキュリティ

コンテナが複数の異なるインフラストラクチャプラットフォームに配布されると、セキュリティの状況が動的になり、予測しづらくなります。特にサードパーティのクラウドサービスを使用している場合は、開発者がこれらのプラットフォームに関して動作を仮定することはできません。

したがって、コンテナに対する包括的なセキュリティ戦略では、ツール、プロセス、ネットワーク構成とトポロジー、ホストOSを考慮する必要があります。また、SDLCパイプライン全体で変わる可能性があるその他の依存関係も検討する必要があります。

エフェメラルな性質の確保

静的IPアドレスを使用するVMと異なり、コンテナではオーケストレーションツールを利用してIPアドレスを動的に割り当てます。そのため、コンテナの配布にあたって、セキュリティポリシーとファイアウォールルールの再構成が行われる場合がありますが、この作業にはたいてい人間の関与が必要です。

ホストOS

ホストOSでは、セキュリティのための最適化は行われていません。特にパブリッククラウド環境は汎用的な機能を提供するために設計されているため、その傾向が顕著です。

コンテナシステム自体に含まれるアプリケーション固有のコンポーネントは少ないため、ユーザーはリスクの軽減と管理を計画できますが、コンテナが共有している汎用的なホストOSコンポーネントの一部が、脆弱性を抱えていたり開発者に認識されていなかったりする可能性は依然としてあります。

コンテナの実行に伴うリスク

コンテナの実行によってリスクが発生する可能性も、わずかながら存在します。具体的には、コンテナ内に脆弱なソフトウェアパッケージがあると、攻撃者がマルウェアをインストールしてネットワーク全体に拡散させることができます。コンテナが侵害された場合、セキュリティツールやセキュリティプロセスがコンテナに適切に対応していないと、そのコンテナのトラフィックに対してセキュリティ脅威の検査が行われない可能性があります。

オーケストレーションとコンテナイメージのリスク

IDとアクセスの管理が不適切であるために発生するオーケストレーションとコンテナイメージのリスクは、サイバーセキュリティ上の新たな課題をもたらします。

このことが特に当てはまるのは、コンテナ間のネットワークトラフィックが管理されていない場合です。このようなトラフィックの実行や管理は、オーバーレイ仮想ネットワークによって行われます。しかし、仮想ネットワークを管理するオーケストレーションツールが、既存のネットワークセキュリティツールのセキュリティ機能を共有できない場合があります。

コンテナセキュリティの最適化

こうした課題がある中でコンテナのセキュリティを最適化するには、次の点に注力する必要があります。

• 開発者の責任とセキュリティ意識の確立。
• コンテナのオーケストレーションとネットワーク脅威インテリジェンスの強化。
• サードパーティのクラウドインフラストラクチャプラットフォームのリスク軽減。

基本的にコンテナ自体の安全性はコンテナ以外の環境とあまり変わりませんが、環境の複雑さゆえに対応が難しいセキュリティの課題がいくつかあります。その脆弱性の多くは設定ミスに起因するものです。実際、調査回答者の67%が、コンテナまたはKubernetes環境で深刻な設定ミスがあったと回答しています。また、同じ調査で90%の回答者が、過去12カ月間にコンテナまたはKubernetes環境でセキュリティインシデントが発生したと回答しています。

クラウドネイティブ環境のコンテナでも、他のタイプのコンピューティングインフラと同様の高いセキュリティを確保する必要があります。もちろん、セキュアな環境を実現するには継続的な取り組みが欠かせません。

このブログはこちらの英語ブログの翻訳です。