概要
コンテナ (Container) という技術をご存知でしょうか？
古くは Docker から始まり、Kubernetes や Amazon Elastic Container Service (Amazon ECS) 、 AWS Fargate、 Google Cloud Run、 Google Kubernetes Engine (GKE) で利用される、軽量な仮想化サービスを実現する技術です。
コンテナはカーネル (OS の中核となる機能) を共有していますが、仮想化に近い技術領域であるため、OS レベルで利用者による管理が必要とされます。
コンテナを本番環境で利用する際には、仮想マシンと同様にウイルス対策を実施することが望まれます。
しかし、技術的基盤が仮想マシンとは異なるため、その対策方法は全く異なります。
たとえば、CSPM / KSPM による態勢管理を実装したり。
たとえば、イメージスキャンを実施したり。
たとえば、システムコールを観測したり。
いずれも、今までのウイルス対策では出てこないキーワードであると考えます。
本記事では、技術的な差に触れつつ、コンテナに対するウイルス対策などのセキュリティ対策のベストプラクティスを示したいと思います。
コンテナセキュリティは難しい
今までのアンチウイルスソフトは Linux などの OS 上にインストールして、各アプリケーションの保護やウイルス対策などを実施していました。
コンテナは、OS 上にインストールされるアプリケーションです。
しかし、コンテナ上のアプリケーションはコンテナアプリケーションによってブラックボックス化されています。
そのため、 一般的には OS 上で動作するアンチウイルスソフトではコンテナ上のアプリケーションを保護することは出来ません。
(仮想化に対応したウイルス対策ソフトであれば可能です)
では、コンテナ上の OS にウイルス対策ソフトを入れることは可能でしょうか？
これは、可能であるが、コンテナのメリットを消しかねません。
コンテナは、一般的には最低限の機能のみを有した軽量 OS をゲスト OS として使用します。
これは、コンテナ上で利用されることを前提として、OS の処理を限りなく少なくしたものです。
他にも、ソフトウェアの配布がコンテナイメージで行われている場合、ゲスト OS がコンテナイメージで固定されていることもあります。
これらの軽量 OS に対応したアンチウイルスソフトが少ないため、対策を難しくしています。
コンテナはライフサイクルが短い
コンテナは、アプリケーションの負荷に応じて作成・削除が行われます。
一般的なアンチウイルスソフトでは、パターンファイルという定義ファイルを用いますが、この仕組みもコンテナとの相性が良くありません。
ライフサイクルが短いため、コンテナ起動の都度パターンファイルを要求したり、パターンファイルの差分ダウンロードに対応しない場合は完全ダウンロードが必要になるなど、管理サーバーへの負荷が無視できなくなります。
そのため、コンテナのウイルス対策を行う場合は、従来のウイルス対策ソフトと異なる設計思想をもったコンテナに特化したソリューションが必要となります。
コンテナにリスクは有るの？
コンテナにもリスクは有るのでしょうか？
『マネージドサービスを利用すれば、ウイルス対策は不要ではないか？』と考える方もいるかも知れません。
結論としては、コンテナにもリスクはあります。
下図に、リスクの例を挙げます。
コンテナには、従来のアプリの脆弱性や、OS コンポーネントの脆弱性だけでなく、イメージの脆弱性やオーケストレーターの管理不備など、コンテナ特有のリスクが存在しています。
そのため、従来のようなウイルス対策やホストベース IPS / IDS、ホストベースの WAF などでなく、コンテナに対応したソリューションが必要となります。
コンテナのリスクへ対応しよう
この章では、実際にいくつかの観点から、コンテナに対するセキュリティ対策の例を示します。
クラウドの「設定ミス」を防ぐ
コンテナのセキュリティ対策の一つは、コンテナ実行環境の「設定ミス」を防ぐことです。
コンテナのアプリケーションは、多くの場合クラウド上のマネージドサービス上で実行されています。
マネージドサービスを利用する場合でも、利用者側で設定ミスがあるとリスクになりえます。
たとえば、管理ポートへの接続がインターネット全体に許可されていたり、シークレット情報にアクセスが許可されているような場合です。
このような設定不備がないかを確認して、安全な運用ができるように、実行環境を堅牢化することが重要です。
クラウドや Kubernetes などの実行環境の設定を調査して、CIS Benchmarks や PCI DSS などの基準に照らし合わせて検証を実施するソリューションは CSPM や KSPM と呼ばれます。
- CSPM (Cloud Security Posture Management)
- KSPM (Kubernetes Security Posture Management)
これらのツールを活用することで、コンテナ実行環境のリスクがないかをチェックすることが可能です。
イメージを守る
Linux などの OS 上のアプリケーションと、コンテナ上のアプリケーションは、アプリケーションを実行する環境の作成方法が異なります。
OS 上のアプリケーション実行環境は、 OS に対して必要なアプリをインストールしたり、設定ファイルを作成するなど、順次作られていきます。
コンテナ上のアプリケーションは Dockerfile などの定義ファイルに基づいて Image 化され、実行されます。
アプリケーションの実行環境の作成方法が、Linux などの OS とコンテナでは異なるため、保護の方法も異なります。
OS に対するアンチウイルスソフトはそれぞれの変化する状態を確認して、常に問題がないことをチェックするような保護を提供しています。
それに対して、コンテナのアプリケーション実行環境は静的です。
Dockerfile などの定義ファイルをもとに Image が作成されるため、イメージングの際にイメージスキャンを実施することで環境を保護します。
イメージ保護では、定義だけでなくサプライチェーン攻撃にも注意することが必要です。
コンテナイメージは誰でも作成、公開することが可能です。
利用しているイメージの提供元が『信頼できる公開元』であるかに注意が必要です。
初回の評価時には安全なイメージであっても、更新がされずに放置され、攻撃者によってイメージを乗っ取られることもあります。
そのため、コンテナ利用時にはサプライチェーン攻撃にさらされていないか常に確認が必要となります。
Linux などの OS 環境は動的であるため、スナップショット的なスキャンの他に変更の都度リアルタイムスキャンが必要となります。
リアルタイムスキャンを実現するために OS 内にパターンファイルを保持してスキャンすることが一般的です。
コンテナ環境は静的なイメージファイルに基づき作成されます。
そのため、イメージファイルをまずスキャンし、内容や利用イメージに問題がないかスキャンするのが一般的です。
新たな脅威や脆弱性に対応するため、イメージは変更がなくても定期的にスキャンを行うことが推奨されます。
ドリフトを防ぐ
ドリフトを防ぐという概念は、OS の保護にはないコンテナ保護に固有の概念です。
イメージファイルをベースとして保護すると先の章に記載しましたが、『実行時の状態』が『イメージの状態』とずれている状態のことを『ドリフト』といいます。
ドリフトが発生する原因はさまざまです。
たとえば、実行中のコンテナにログインしてコマンドを実行したり、実行中のコンテナに直接パッチを適用することでドリフトが発生します。
その他にも、マルウェアによる改ざんが発生した場合などもドリフトが発生します。
ドリフトが発生した状態は、コンテナセキュリティにとって望ましくありません。
イメージスキャンの結果から状態が変わっていることはもちろん、実行中の複数のコンテナで状態が異なるため、安全であることが確認できないためです。
コンテナセキュリティソフトには、ドリフト検知という機能を有したものがあります。
これは、実行中の各コンテナを確認して、ドリフトがないことを確認するものです。
コンテナをスキャンして、不正なコンテナを検知・停止することで運用上の不備はもちろん、ウイルスなどによって不正な状態となったコンテナによる影響を防ぐことができます。
安全なコンテナ運用にとってドリフト状態にしないことはとても重要です。
これによって、イメージスキャンの有効性を高めるとともに、不正な改ざんから保護することが可能です。
実行中コンテナの保護
イメージを保護したうえで、更に実行中のコンテナ内の保護も必要となります。
コンテナ上のアプリケーションも、常にマルウェアなどの脅威に曝されています。
仮想通貨マイニングなどの、コンテナに対する攻撃だけでなく、コンテナからの脱獄をおこない、コンテナを実行するホストへの侵入を試みるマルウェアも存在します。
Linux などのアンチウイルスソフトがメモリ上のウイルスを検知するように、コンテナでも不正な動作が発生していないことを常時監視します。
コンテナ上ではアンチウイルスソフトなどを導入することは運用上望ましくないため、ホスト OS 上にソフトウェアをインストールし、システムコールを観測する手法が良く用いられます。
システムコールは、ユーザーアプリケーションと OS カーネル間のやり取りであり、ファイルオープン、ネットワークオープン、シェルの実行などの OS 機能を用いる際には必ずシステムコールが発生します。
システムコールを観測することで、たとえばウイルスが機密ファイルにアクセスしようと試みたり、C&C サーバーなどの信頼できない通信先への接続を試みるなどの動作をリアルタイムで検知・制御することが可能となります。
コンテナ上のアプリケーションであっても、実行時保護はウイルスからの保護の最後の砦となります。
しかし、手法としては従来のメモリ上のパターンマッチではなくシステムコールの観測といったコンテナに対応する方法での対策が必要となります。
利便性と安全性のトレードオフ
マネージドサービスの限界
コンテナは、軽量で柔軟なライフサイクルを実現しています。
アプリケーションの負荷に応じて高速にスケールが変更され、実行されます。
そのため、従来型の OS にアンチウイルスソフトを導入するような設計は非常に難しくなっています。
コンテナでは、OS に対して導入していたアンチウイルスソフトなどをホスト OS 側のアプリケーションとして導入し、実行時保護として提供します。
しかし、この方法は現在提供されているマネージドサービス型のコンテナサービスとの相性が良くありません。
ホスト OS でのスキャンには、ホスト OS でのセキュリティ支援が必須です。
マネージドサービス型のコンテナサービスでは、ホスト OS をクラウドサービスプロバイダー側で提供されることが一般的であり、ソフトウェアの導入などが制限されているためです。
設計からコンテナ保護の検討を
コンテナサービスを保護するためには、 OS に対してアンチウイルスソフトを入れて対策完了といったセキュリティ対策はとても難しくなっています。
コンテナ上の OS 上にアンチウイルスソフトを入れること自体が難しく、設計段階からどのように保護をするかを考慮したセキュリティ設計が求められます。
アプリを作成しリリース時にセキュリティ対策を検討するような運用ではなく、設計段階からセキュリティ対策を検討するようにしてください。
まとめ
コンテナは、セキュリティ対策が不要となるような仕組みではありません。
そのため、従来のリスクのほか、コンテナ特有のリスクに常にさらされています。
コンテナには、コンテナ用のセキュリティ対策が必要です。
有効な対策を実施するためにも、設計段階からセキュリティ運用を考慮してください。
アイレットでは、各種コンテナセキュリティを提供しています。
コンテナアプリケーションのセキュリティ対策に不安がある際は、ぜひご相談ください。
