コンテナスキャンなどによるコンテナのセキュリティ管理
SHARE:
昨今、コンテナセキュリティといえば Kubernetes などのオーケストレーションプラットフォームのセキュリティ要件が話題にのぼりますが、コンテナのセキュリティリスクの中にはオーケストレーションレベルでは対応できないものもあります。個々のコンテナへの脅威についても管理する必要があるのです。
そのための最良の方法は標準的な Docker のセキュリティプラクティスに従うことです。これは Docker コンテナが 2013 年に一般公開されてまもなく定められています。今日のコンテナエコシステムは Docker をはるかに超えた形へと進化を遂げています。実際のところ、もはや Docker 自体はあまたあるコンテナアプリケーションスタックの一部ではありません。コンテナアプリケーションでは他のランタイムやオーケストレーションソリューションを使用します。しかし、コンテナのスキャン、コンテナの脆弱性管理、コンテナのアクセス制御といった Docker のセキュリティ基本原則は現在も有効です。
そこで、この記事では基本に立ち返り、コンテナの脆弱性に関する主なカテゴリの概要と、コンテナの脆弱性管理に役立つ対策をご紹介します。
コンテナイメージの脆弱性
イメージの脆弱性は依然として個々のコンテナに対する最も一般的なタイプのセキュリティ脅威となっています。コンテナイメージの脆弱性は、コンテナイメージの内部に埋め込まれたセキュリティリスクです。脆弱なイメージそのものが実際の脅威をもたらすわけではありませんが、脆弱なイメージからコンテナを作成すると、そのコンテナが本番環境に脆弱性をもたらすことになります。
通常、コンテナイメージの脆弱性はコンテナイメージに取り込まれた不適切なライブラリや他の依存関係から生じます。また、ソフトウェアサプライチェーン攻撃などの開発環境のセキュリティ侵害を通じてイメージに悪質なコードが挿入されていることもあります。
コンテナスキャンによるイメージの脆弱性の検出
幸いなことに、コンテナイメージの脆弱性のほとんどはコンテナスキャンを実行することで比較的簡単に検出できます。コンテナスキャンでは、各コンテナのコンテンツを既知の脆弱性に関するデータベースに照会する自動化ツールを使用します。このツールによってコンテナイメージ内のライブラリや他の依存関係に既知の脆弱性が見つかった場合、イメージにフラグが設定され、そのイメージは安全ではないとされます。
コンテナスキャンの一番の弱みは、一般にコンテナスキャンが未知の脆弱性の検出には役立たないという点にあります。未知の脆弱性とは、公開されていないなど、まだセキュリティ分析の対象となっていない脆弱性のことです。つまり、コンテナイメージが使っているライブラリにセキュリティに関するバグがあったとしても、そのバグを “善意の人” がまだ発見していなければスキャナが検出することはありません。こうしたバグはスキャナに使われている脆弱性データベースに登録されていないからです。また、カスタマイズされた独自のコードに影響する脆弱性は外部から追跡されることがないため、こうした脆弱性も通常は検出されません。
コンテナイメージのスキャンはコンテナ保護に向けた重要な一歩ではありますが、あくまでも一歩にすぎません。完全な脆弱性管理ソリューションではないということを心に留めておくことが大事です。
悪質なコンテナイメージ
正規のコンテナイメージにも脆弱性が含まれることがしばしばありますが、攻撃者が正規のイメージを偽装して作成した悪質なイメージは Docker イメージのセキュリティにとってはるかに大きなリスクとなります。攻撃者は正規のイメージと思わせるような名前（mysqldatabase や nginxserver など）で、マルウェアが含まれるイメージを Docker Hub などのパブリックコンテナレジストリにアップロードし、疑いを持たない管理者をだまして悪質なバージョンの公開ソフトウェアをデプロイさせようとします。
悪質なイメージの回避
Docker のイメージスキャナでは、一般に公開されている脆弱性と関連のないマルウェアが含まれているイメージを検出できません。このため、悪質なイメージから組織を保護する最良の策は、信頼できるソースからのみイメージをダウンロードするよう徹底することです。非公式の Docker Hub レジストリや GitHub リポジトリは避けてください。
また、コンテナイメージをプルするときに “latest” タグを使うことも避けましょう。このタグを使うのではなく、イメージのバージョンを指定するようにします。そうすることで、攻撃者が他のイメージよりも新しいバージョン番号を付けて正規のコンテナレジストリに忍ばせた悪質なイメージを誤って利用する、といったリスクを軽減できます。
特権エスカレーションの脅威
デプロイするすべてのコンテナイメージに脆弱性が一切なかったとしても、特権エスカレーション攻撃によって侵害が発生するおそれがあります。
特権エスカレーション攻撃では、所定のコンテナ内のリソースにしかアクセスできないはずのプロセスがそのコンテナを “脱出” し、別のコンテナやホストサーバー内のリソースにアクセスします。
特権エスカレーションの防止
特権エスカレーション攻撃の主な攻撃ベクトルは、コンテナの実行を担うコンテナランタイムソフトウェアまたはホストオペレーティングシステムのいずれかのバグです。
このため、特権エスカレーションを防ぐには、まずコンテナランタイムおよびホストオペレーティングシステムを保護する必要があります。主な方法としては、ホストサーバーなどのサーバーで実行されているソフトウェアをすべて最新の状態に更新し、既知の脆弱性がないようにします。
また、AppArmor や SELinux などのカーネル強化フレームワークを導入することも特権エスカレーション攻撃のリスク低減につながります。こうしたフレームワークによってホストオペレーティングシステムに新たなアクセス制御（ポリシーを構成して適用できます）が追加され、プロセスが本来のコンテナから脱出することを第 2 の防御層で防ぎます。
最後に、Alpine Linux などの最小限のオペレーティングシステムを選ぶと、コンテナにおける特権エスカレーションのリスクを低減できます。攻撃者に悪用されるおそれのあるライブラリとサービスの数が減ることになるからです。ベストプラクティスとして、ホスト OS にはコンテナのデプロイ、オーケストレーション、モニタリング、保護を行うための必要最小限のソフトウェア以外は搭載しないようにします。コンテナと共にその他のワークロードを実行する場合には、別のサーバーか VM で実行します。
アプリケーションの脆弱性
コンテナイメージとその実行環境の保護を徹底したとしても、コンテナを使ってホストしているアプリケーションのソースコードに不具合があればセキュリティの問題に直面することになります。
たとえば、データ入力の検証が不十分だと SQL インジェクションなどの攻撃が可能になり、攻撃者が機密情報にアクセスできるようになります。ほかにも、バッファオーバーフローの脆弱性があれば、攻撃者は任意のコードを実行して、コンテナや場合によってはホスト全体を乗っ取ることができます。
アプリケーションの脆弱性管理
アプリケーションの脆弱性はコンテナに関連付けられたプロセスやツールで発生するのではなく、アプリケーションコードの内部で発生します。そのため、アプリケーションの脆弱性はアプリケーションレベルで管理する必要があります。
静的アプリケーションセキュリティテストを使い、CI/CD パイプラインの一部としてアプリケーションのソースコードの脆弱性をスキャンしてください。このテストによって、脅威につながる不適切なコーディングを特定できます。デプロイの前にもう一度、今度は動的アプリケーションセキュリティテストを使用してアプリケーションをテストします。この手法では、サンドボックス環境で実行しているアプリケーションをモニターし、セキュリティ上の脆弱性を示す動作を検出します。
この場合も SELinux や AppArmor などのカーネル強化フレームワークを使用すると、脆弱性の悪用を困難にし、アプリケーションの脆弱性がもたらすリスクを低減するのに効果的です。ただし、こうしたリソースがアプリケーションの危険性の根本原因を解決してくれるわけではありません。
Docker の CIS ベンチマークの使用
コンテナに対するセキュリティ脅威からの完全な解放を保証する方法はありませんが、基準を定めるために役立つ方法はあります。それは、コンテナの構成を CIS（Center for Internet Security）による Docker のセキュリティベンチマークに照らして評価することです。
CIS のコンテナセキュリティベンチマークはコンテナのソフトウェアスタックすべての層に対応します。これらのベンチマークでは、ホストの保護、コンテナイメージ内の権限の構成、コンテナランタイムの構成など、さまざまな側面についてのベストプラクティスが策定されています。
CIS による推奨事項に準拠しているからといって Docker のセキュリティが保証されるわけではありませんが、それでも時間を作ってベンチマークを一通り試し、それぞれの要件を満たしておく価値はあります。
安全なコンテナを安全な環境にデプロイするには、多種多様な脅威の低減につながるツールと実践が求められます。コンテナイメージのスキャナからカーネル強化フレームワーク、アプリケーションの保護など、コンテナアプリケーション環境内におけるセキュリティ上の脆弱性のリスクを低減するには、幅広い防御策が必要です。