昨今のIT業界では、コンテナ仮想化がトレンドである。コンテナを利用することでテスト環境や本番環境による環境差異を最小化し、スケールアウトやバージョン管理を容易にすることで変化のスピードが早いITへの対応を可能にしている。
本稿ではコンテナ環境で新たに考慮されるべき脆弱性とその対策について解説する（ホストOSやハードウェアなどコンテナ外の脆弱性については、以前と大きく変わらないため本稿では割愛とする）。
ここではコンテナ環境を以下の階層に分け、脆弱性とそれに関する対策方法を説明する。
・イメージ
・レジストリ
・オーケストレータ
・コンテナ
イメージの脆弱性とその対策
イメージには、以下の5つの脆弱性が存在している。
①イメージ作成時の脆弱性
OSのfixレベルが低いなど、作成したコンテナイメージに脆弱性が含まれている場合、その脆弱性を利用される可能性がある。
対策としては、イメージのセキュリティ診断ツール（Docker Banch for Security、Dockle、Hadolint）の利用が考えられる。
②イメージの構造上の欠陥がある
利用しないにも関わらず、SSHなどのサービスが起動する状態でイメージを作成した場合、それらのサービスを悪意あるユーザーに利用される場合がある。
対策としては、コンテナのスキャンツール（CIS Docker BenchMark）を利用し、sshdの無効化やnon-rootユーザーでの起動を強制する方法がある。
また、Alpine Linuxなどの軽量で余計なサービスを含んでいないOSイメージを選択し、攻撃対象領域を減らす運用方法も考えられる。
③マルウェアの混入
作成するイメージにもともと、マルウェアなど悪意あるソフトウェアが混入している場合がある。その場合、作成されたコンテナにもマルウェアが混入してしまう。
対策としては、イメージのマルウェアスキャンツール（Clair、Twistlock）や不自然なリソース使用率、ネットワークをツール（Prometheus、Datadog）で監視する方法がある。
④イメージに対する機密情報の埋め込み
パスワードに関するなんらかの情報など、機密情報を含んだコンテナイメージを作成することは、その情報の漏洩リスクがある。
対策としては、オーケストレータのSecretsを利用して機密情報を保管する、あるいは機密情報管理ツール（Hashicorp Vault、Sealed Secrets）を利用するといった方法がある。
⑤イメージの信頼性
自分自身で作成していない第三者のコンテナイメージを利用する場合、第三者が信頼できるユーザーでない限り、なにかしらの脆弱性が埋め込まれている可能性がある。
対策としては、DockerHubやRedHat Catalogに登録されている公式のイメージを利用する方法がある。
レジストリの脆弱性とその対策
レジストリには、以下の3つの脆弱性が存在している。
①レジストリに対する危険な通信
レジストリへの通信をHTTPなどの非暗号化プロトコルで実装した場合、その通信を傍受される恐れがある。
対策としては、HTTPSなどの暗号化通信を前提としているレジストリやレジストリサービスを利用することが考えられる。
②古くなったコンテナイメージの利用
すでに脆弱性が発見されている古いイメージをレジストリに保管したままにすると、そのイメージの脆弱性を悪意あるユーザーに利用される可能性がある。
対策としては、イメージの保有数やプッシュ後の経過日数に対してクリーンアップ機能を備えるレジストリを利用するか、経過時間ベースでのポリシー設定が可能なレジストリサービス（Quay）を利用することが考えられる。
③レジストリに対する認証認可
レジストリに対して認証なし、あるいは簡易なパスワード認証を使ってアクセス可能にすると、攻撃者によってレジストリにアクセスされることがある。
対策としては、強力な認証認可機能を提供するサービス（Quay、クラウドサービスを利用している場合はそのクラウドサービスで利用可能なIAMサービスとの連携）を利用することが考えられる。
オーケストレータの脆弱性とその対策
オーケストレータには、以下の5つの脆弱性が存在している。
①制限のない管理者権限
cluster-adminなど、適切な権限を設定せず制限のないユーザーを利用してクラスタを操作すると、悪意あるユーザーによって意図しないような操作をされてしまう可能性がある。
対策としては、RBAC（Role-Based Access Control)などを利用し、開発者やテストチームなど利用ユーザーに応じた細かな権限を設定する方法がある。また、Role（Namespaceごと）やClusterRole（クラスタ全体）を適切に用いる必要がある。
②オーケストレータ自体の認証認可
オーケストレータの操作ユーザーに対して認証認可を実行しない、または容易に推測できるパスワードなどで認証していた場合、攻撃者はオーケストレータを介してシステムを攻撃する可能性がある。
対策としては、クラウドサービスのIAM機能などと連携し、オーケストレータの操作ユーザーを一元管理することが考えられる。
③コンテナ間のネットワーク
重要度の異なるコンテナを同一ネットワーク内に配置した場合、攻撃者は重要度の低いコンテナから高いコンテナに対し、ネットワーク経由で攻撃する可能性がある。
対策としては、特定のコンテナとのみ通信を許可するポリシーをCNI（Calico、OpenShift SDN）によって設定することが考えられる。
④セキュリティレベルの異なるコンテナ
セキュリティレベルの異なるコンテナを同一ノード内に配置した場合、セキュリティレベルの低いコンテナからセキュリティレベルの高いコンテナに、アクセスを試みられる場合がある。
対策としては、ワークロードのセキュリティレベルごとにグループ化（Node Selector、Taints／Tolerations、Node Affinity）を行い、特定のホストが単一のグループのコンテナのみを実行可能にする方法がある。
⑤オーケストレータ内のノードの信頼性
ノード、ノード間通信を十分に保護していない場合、通信を介して攻撃される可能性がある。
対策としては、ノード間をセキュアに通信できるオーケストレータ（Kubernetes、OpenShift）を用いることや、ノードを監視する方法（Prometheus、Datadog）がある。
コンテナの脆弱性とその対策
コンテナには、以下の5つの脆弱性が存在する。
①コンテナ・ランタイムの脆弱性
最新でないコンテナ・ランタイムを利用すると、既知の脆弱性に対する安全性が確保されないため、攻撃者はその脆弱性を狙って攻撃を仕掛ける。
対策としては、ノードからPodを退避させるアプリケーション（Cordon）などを利用し、定期的かつ計画的にコンテナ・ランタイムをアップデートする方法が考えられる。
②コンテナからの無制限のネットワークアクセス
コンテナからのネットワークアクセスを制限していない場合、悪意のあるコンテナが存在すると、そこから他のコンテナやホストOSに対して不正にアクセスされる可能性がある。
対策としては、通信をポリシーによって制御する（Calico、OpenShift SDN）、ネットワークを監視する（Prometheus）などの方法がある。
③安全でないコンテナ・ランタイムの構成
コンテナ・ランタイムに対して安全性を考慮しないオプション設定を行った場合、攻撃者はその部分を狙うことがある。
対策としては、ランタイムの保護機能の利用（PodSecurityPolicy、PodSecurityContext、SecurityContext、SCC）が考えられる。
④アプリケーションの脆弱性
コンテナ上で稼働しているアプリケーションに脆弱性があった場合、そのアプリケーションの脆弱性が狙われる可能性がある（XSS、SQLインジェクション）。
対策としては、アプリケーションの脆弱性対応が考えられる。
⑤悪意あるコンテナ
悪意あるユーザーによって予期せぬコンテナがデプロイされ、そのコンテナを攻撃に利用される可能性がある。
対策としては、本番環境と開発環境を分離し、本番環境への影響を軽減するほか、ユーザーのアクセス監査や脆弱性のあるイメージのデプロイを禁止する（Docker Banch for Security、Dockle、Hadolint）ことが挙げられる。
このようにコンテナ環境でのセキュリティは、従来のセキュリティとは別にイメージやレジストリ、オーケストレータ、コンテナの観点から考える必要がある。
とくにクラウド環境やコンテナ環境の場合、従来のオンプレミス環境とは異なり、ネットワークの物理的な分離が難しい側面もあるので、アプリケーションを用いて環境の分離、ネットワークの分割、ユーザー管理を行うことが望ましい。
またサービスメッシュなどの考え方から生じるコンポーネントの増大により、運用は肥大化・複雑化している。そのため可能な限り人手による運用を避け、CI／CDやIAMなどを利用した自動管理にすることが望ましい。
参考サイト
NIST SP800-190
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf
著者
伊藤 哲也
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
セキュリティー
ITスペシャリスト
2008年に日本アイ・ビー・エム システムズ・エンジニアリングに入社。入社以来、IBM Securityに関するプロジェクトに参画し、技術支援を実施。2015年からはAPI Connectを用いたREST APIやそれに関わる認証などセキュリティの技術支援を行っている。
［i Magazine・IS magazine］
