本セッションでは、コンテナセキュリティの基本について説明し、後半ではコンテナの脅威について説明します。対象は、コンテナを作成するアプリケーション開発者や、KubernetesやDockerなどのインフラを管理運用する方、コンテナのセキュリティ対策に関わる方全般です。
会社紹介：About 3-shake
株式会社スリーシェイクは、SREを主軸としたクラウドネイティブエンジニアリングの内製化を支援する企業です。私が所属するスリーク事業部は、お客様の技術支援を行う部署であり、SRE、特にインフラ領域に強みを持っています。また、自社プロダクトの開発やフリーランスの紹介サービスも提供しています。以上が弊社の簡単な紹介です。
1. コンテナセキュリティ概要
ここからコンテナセキュリティの概要についてお話しします。まず、コンテナとは何かを簡単にご紹介します。
コンテナはプロセスであり、Linuxカーネルのいくつかの機能（chroot、cgroups、namespaces、capabilities）を利用して適度に分離されたプロセスとして定義されます。従来のサーバー環境とは異なり、ホスト上で動くプロセスであり、ホストとプロセス間の共有と分離の概念があります。カーネルはホストとコンテナで共有され、一部のファイルも共有されますが、その他のホストファイルや他のプロセスへのアクセスは基本的に制限されています。ただし、設定次第でアクセスが可能になる場合もあります。
次にコンテナイメージについて説明します。コンテナを実行するにはコンテナイメージが必要です。
コンテナイメージは、コンテナが実行に必要なルートファイルシステム、実行ファイル、依存ツール群、実行ユーザーや環境変数などの設定情報を含んでいます。これらはDockerfileという定義ファイルによって構成され、Infrastructure as Code (IaC)として管理されます。Dockerfileには、ベースイメージの決定、準備作業、ファイル追加、実行プロセスの記述などのステップがレイヤー構造で記載されています。
コンテナイメージは、イメージ名、タグ、ダイジェストという概念で一意に特定されます。コンテナを実行する際には、コンテナイメージ名とタグまたはダイジェストを指定して、コンテナイメージからコンテナを作成します。
コンテナ環境を構成する要素には、コンテナの実行基盤として、ホストマシンがあること、その上に動いている コンテナランタイムと呼ばれるものがあります。こちらはDockerだったりコンテナランタイムと呼ばれるものが動いております。
さらにそのコンテナをまとめてオーケストレーションツールとして使う代表的なツールとしてKubernetesがあります。
次に、コンテナイメージに関する構成要素としましては、Dockerfileと、コンテナイメージを格納するためのイメージ レジストリ、Dockerfileからコンテナイメージをビルドする環境になります。
コンテナセキュリティは、コンテナ環境の各構成要素に対するセキュリティ対策の組み合わせと考えられます。
具体的には、コンテナとホストの分離強化、コンテナイメージのセキュリティ設定、コンテナ実行基盤のセキュリティ強化が含まれます。重要なセキュリティ原則として、最小権限の原則や多層防御があります。リスクを評価し、優先順位をつけて対策を取ることが重要です。セキュリティの観点が重要ですが、コンテナ技術に関する理解も欠かせません。
コンテナとホスト間の分離を強化する方法として、以下の点が挙げられます。
Dockerfileの設定を最適化してセキュアなコンテナを作成する。
SELinuxやAppArmorなどのLinuxセキュリティ機能を活用する。
セキュアなサンドボックスコンテナランタイムを使用して、ホストとコンテナ間の分離を強化する。
これらの方法により、コンテナとホストの分離をより堅固にできます。
コンテナセキュリティの全体像としては、記載の要素が挙げられます。
Dockerfileやコンテナイメージのセキュリティ、実行基盤のセキュリティ、シークレット管理、ネットワークセキュリティ、ビルドとデプロイのセキュリティ、ランタイムセキュリティ、監視とログ取得、そしてバックアップ管理が含まれます。
コンテナに固有のセキュリティは少ないですが、他のサーバー環境と同様にセキュリティの強化が必要です。それらをコンテナレイヤーで同様に設定し、コンテナに即した形でセキュリティを実施することが重要です。
私が監訳したコンテナセキュリティの本は、前半ではLinuxのセキュリティ機能に焦点を当て、後半ではそれを実際の環境でどのように活用するかについて述べています。これにより、コンテナセキュリティの概念を簡潔に理解できるようになっています。興味があればぜひお読みいただけると嬉しいです。
『コンテナセキュリティ コンテナ化されたアプリケーションを保護する要素技術 (2023/4/12)』
コンテナセキュリティは、システム全体のセキュリティと比較してどのように異なるかを考えるために、Kubernetesのブログやドキュメントにある図を用いて紹介したいと思います。
クラウドネイティブのセキュリティは、4つのCと呼ばれており、コード、コンテナ、クラスター、クラウドの4つの要素に分類され、コンテナセキュリティはその中の一部です。システム全体のセキュリティを考慮する際には、他のレイヤーのセキュリティも考慮する必要があります。
コンテナ自体は外部からの直接的な脅威にはあまりさらされないが、上位層のアプリケーションコードや下位層のクラウドの権限など、他の要素からの侵害が起点となってコンテナが侵害されることが多いです。セキュリティの優先度はアプリケーションの脆弱性にあるが、コンテナレイヤーのセキュリティも多層防御の観点から重要であり、適切な検討が必要であります。
個人的に責任範囲とセキュリティ運用の重要性を感じています。
責任範囲では、コンテナのセキュリティに関する責任範囲を明確にすることが重要です。特定の範囲に焦点を当てることで、セキュリティに対する注力が容易になります。
コンテナイメージのセキュリティの責任者は、アプリ開発者やインフラ担当者など、作成者によって異なります。セキュリティ担当者がいる場合は、その範囲で責任が定まりますが、担当者がいない場合は、アプリ開発者やインフラ担当者がセキュリティを担当する必要があります。
セキュリティ運用において、継続的なセキュリティの確保が非常に重要です。現時点でセキュリティが十分であっても、将来的なセキュリティの脅威に対する保証はできないため、定期的なセキュリティ運用が必要です。新たな脆弱性が発見された場合、適切な対応が必要です。
セキュリティアラートの適切な処理と対策が重要です。定期的な設定の見直しも必要です。
2. コンテナの脅威と対策
ここからは、脅威に焦点を当てて話を進めます。
脅威に関しては、情報システムを通じて組織に悪影響を与えるもの全般を指します。外部からのサイバー攻撃や内部不正、設定ミスや事故による侵害などが含まれます。
脅威からセキュリティ対策を考える利点について説明します。
まず、脅威を知ることでセキュリティ対策の意義を理解できます。一般的な脅威の知識が前提ですが、その知識をもとに各セキュリティ対策がどのような脅威に対抗するかを考えることが重要です。これにより、対策の効果を評価し、他の対策との優先順位をつけることができます。
また、管理しているシステムやアプリケーションに特化して脅威を考える必要があります。システムのネットワーク環境や社内体制によって脅威の有無が異なるため、自分のシステムにおいて特に重要な脅威に対して重点的に対策を打つことが大切です。
こういった取り組みを体系的に行う方法として「脅威モデリング」があります。
脅威モデリングについて軽く説明します。
脅威モデリングとは、システムの潜在的な脅威を特定し、その優先順位を決定するプロセスです。これには、まずシステムのアーキテクチャの理解が必要です。その上で、一般的な脅威モデル（例えば、STRIDEやPASTA）を使用して、システムに対する具体的な脅威を洗い出し、優先順位をつけて対策を講じます。
脅威アクターも定義します。脅威アクターには、外部からの攻撃や内部からの攻撃などがあります。これらの脅威を洗い出し、対策を検討します。脅威モデリングは設計段階から取り組むことが推奨されます。もちろん、既存のシステムに対して脅威評価を行うことも有益ですが、早い段階で実施することで、セキュリティ対策を前倒しし、コストを抑えることができます。
ここからはコンテナの脅威について話します。
コンテナの脅威とは、コンテナを通じてシステムや情報資産に悪影響を与える事象のことです。具体的には、コンテナのプロセスや、コンテナを実行する基盤、コンテナイメージを狙った攻撃などが挙げられます。
コンテナ自体が攻撃の表面として外部に露出しているケースは、適切に設定されている限り少ないです。したがって、脅威を考える際には、コンテナに影響を与える要因を考慮する必要があります。たとえば、アプリケーションからコンテナに対する影響や、開発者の権限が悪用されてコンテナにアクセスされる場合などです。
代表的なコンテナの脅威として、3つを挙げ、それぞれについて詳しく説明します。
攻撃の起点
- コンテナ上で実行されるアプリケーション、OSパッケージの脆弱性
外部に公開されているWebアプリケーションがコンテナ上で実行されている場合、そのアプリケーションに脆弱性（例：OSコマンドインジェクション）が存在すると、攻撃者がコンテナに侵入する可能性があります。
- 意図しないコンテナ操作権限の外部公開
Docker APIが外部に公開されている場合や、適切なアクセス制限が設定されていない場合、攻撃者がコンテナに対して操作を行うことができるリスクがあります。
影響
- コンテナを介した情報資産への不正アクセス
広範な影響: コンテナに侵入されると、そのプロセス内で自由に操作が可能になり、情報資産の不正アクセスやサービスの破壊など多岐にわたる影響が考えられます。
- サービス停止、横展開によるシステム侵害の拡大など
データベースやクラウドサービスへのアクセス: アプリケーションコンテナがデータベースのアクセス権限やクラウドサービスへの権限を持っている場合、それらも脅威にさらされます。
対策
- アプリケーションやコンテナイメージの脆弱性対策
外部に公開されているアプリケーションを実行しているコンテナについては、特に注意が必要です。
コンテナイメージの脆弱性を定期的にスキャンし、脆弱性が発見された場合は即時に対応します。
- コンテナ実行基盤の適切なアクセス制御
Docker APIが外部に公開されていないかを確認し、匿名アクセスが許可されていないかをチェックします。
不要な公開やアクセス制限の不備を避け、コンテナ実行基盤への不正アクセスを防ぎます。
これらの対策により、外部からの攻撃に対するセキュリティを強化し、コンテナプロセスへの侵入リスクを軽減することができます。
この脅威はサプライチェーン攻撃に該当します。利用しているコンテナのベースイメージやアプリケーションが汚染されることで、悪意のあるコードが混入し、それを実行することでシステムが感染したり、プロセスに侵入されたりする可能性があります。
攻撃の起点
- 言語の依存関係やOSパッケージの汚染
正式なパッケージやライブラリが侵害され、それを使用することで悪意のあるコードが実行される。
- パッケージ名のTypoや、安全性の確認できないパッケージの利用
信頼性が確認されていない野良のパッケージやライブラリを使用することで、悪意のあるコードが実行される。
- Dockerfileやビルド環境への不正アクセス
Dockerfileやビルド環境にアクセスされ、内容が改変されることで悪意のあるコードが混入する。
影響
- コンテナプロセスへの侵入、マルウェア感染など
対策
- コンテナの構成把握と最新の脅威情報の収集
コンテナがどのような構成を取っているのか、どのような依存関係があるのかをきちんと把握することが必要です。ソフトウェア部品表（SBOM）の利用が有効です。
最新の脅威情報を収集し、自社システムに影響がないかを確認します。
例えば、不正なコードが仕込まれる可能性があるライブラリ（例：XZ）の情報をいち早く把握します。
- コードレビューの徹底、コードリポジトリやビルド環境の適切なアクセス制御
安全でないパッケージやライブラリの利用を避けるため、コードレビューを徹底します。
コードリポジトリやビルド環境へのアクセス制限をきちんと行い、不正なアクセスや改変を防止します。
これらの対策を講じることで、サプライチェーン攻撃によるリスクを軽減し、コンテナ環境のセキュリティを強化することができます。
コンテナ脆弱性の悪用は、脆弱性が含まれた環境を利用して不正な行動を行う脅威です。
攻撃の起点
- 脆弱なバージョンのコンテナ実行基盤(k8s、 containerd、 runc、 etc...)の利用
- 新たなコンテナ脆弱性の発見
ここでは主にコンテナの実行基盤に関する脆弱性を想定しています。例えば、コンポーネントやコンテナランタイムに存在する脆弱性です。
影響
- コンテナランタイムの脆弱性によるホストへのエスケープ
コンテランタイムの脆弱性が見つかる場合は、大体ホストへのエスケープが影響としては上げられることが多いので例としてあげております。
対策
- コンテナ実行基盤の脆弱性対策
定期的な脆弱性スキャンを実施し、発見された脆弱性に対して迅速にパッチを適用する。
- seccompなどのランタイムセキュリティによる影響緩和
緩和策としては、その他のランタイムセキュリティ、他のセキュリティ設定対策によって、完全に防げないまでも脆弱性による悪用を緩和することは可能です。
そういった意味でも多層防御というのは必要になってくると思います。
コンテナに関する脅威は 、MITRE ATT&CK フレームワークにおいてコンテナ用の攻撃マトリクスが定義されており、初期アクセスから内部への侵入、横展開、情報摂取、破壊行動などが分類されています。これらの脅威は、コンテナに影響を与えるものであり、脅威を考える際にこのような体系的なアプローチを用いることで、脅威をより包括的に考慮することができます。
コンテナの脅威に関して具体例を挙げさせていただきます。
脅威グループ「TeamTNT」は、Docker APIが公開されている場合に、ボットネットに感染をさせて、さらに横展開で広げていくアプローチを取ります。
Kinsingはコンテナ環境を標的とするクリプトマイナーで、アプリ開発者よりもコンテナの管理者が注意を払う必要があります。セキュリティベンダーが具体的なマルウェアやその動作を公開しており、これを参考にしてセキュリティ対策を強化することが重要です。
今年修正されたコンテナランタイムの脆弱性は、コンテナからホストへのエスケープを可能にするもので、コンテナとホストの分離が侵害される可能性があります。
対策としては、脆弱性の修正版にアップデートすることが最善ですが、緊急を要する場合やアップデートがまだ提供されていない場合には、セキュリティ対策の導入や検知ツールの活用なども考慮されます。
コンテナセキュリティの概要、コンテナの脅威と対策について具体例を上げて説明させていただきました。
運営が用意したテーマによるディスカッションへ
――ここからは運営の方で用意したテーマに沿って進めていきます。
最初は運営で用意したテーマを1つだけ紹介させて頂きます。
――資料では、コンテナ固有のセキュリティ対策として、プロセス分離の強化とか実行基盤とかイメージのセキュリティ対策などがあげられてかと思いますが、改めてWebアプリケーションのデプロイにおいて優先的に実施すべき対策であったりそのポイントについてお伺いできればと思っています。
――まず、デプロイ前に優先的に対策すべきことについてはいかが でしょうか。
水元：Webアプリケーションにおける脆弱性は外部攻撃の主な標的であり、静的解析や依存関係の確認、セキュリティテストなどを通じて対策する必要があります。本番環境にデプロイする前に脆弱性診断やセキュリティテストを行うことが重要です。
デプロイプロセスにおいてもセキュリティを考慮すべきであり、自動デプロイの場合も含め、脅威を排除する対策が必要です。
――デプロイ前だと、そのコンテナプロセスの侵入への対策で脆弱性の対策をしたり、アクセス制限をしたりというところでしょうかね。
水元：はい。そうですね。
――ちなみにいくつか関連する質問が今上がってきていますが、「脆弱性チェックを自分たちで行う場合、具体的にどのようなツールや方法で行うのが効果的なんでしょうか？」とのことですが、いかがでしょうか。
水元：脆弱性は大まかに2種類あります。1つはアプリケーションコード内のバグや脆弱性で、もう1つは基盤に関する既知の脆弱性です。アプリケーションコードの脆弱性に対しては、静的解析ツールを使用する一方で、セキュリティベンダーや脆弱性診断機関による外部からの視点での検証も重要です。一方、基盤に関する脆弱性は、自動ツールでの確認が比較的容易であり、OSSツールやエンタープライズソリューションを活用することでセキュリティ運用を効率化できます。
――そう言ったソリューションを入れながら脆弱性をチェックし、見つかった場合の対処方法だったり、開発チームとの連携のポイントとかは、なにかあったりしますでしょうか？
水元：セキュリティ脆弱性の管理は、誰がそのチェックを行うかという点が重要です。開発者とセキュリティ運用者が連携して対応する場合もあります。アプリ開発者には脆弱性のチェックやアラートの対応を行う仕組みを整えることも重要です。また、脆弱性が発見された後は、その対応状況や影響に関する情報を管理し、クローズまで追跡することが重要です。
――デプロイ後のランタイム防御で優先すべき対策は何があるのでしょうか？
水元：ランタイムの防御は、実際に稼働中のコンテナ内での活動を監視することが重要です。悪用を防ぐための対策として、適切なセキュリティコンプライアンスやアップデート、可能であればセキュリティ設定を実施することが必要です。また、特権コンテナ、またはPrivilegedコンテナを無効にして、そのようなコンテナがデプロイされないようにポリシーを設定することも重要です。
デプロイ前にセキュリティを確保し、デプロイされる環境のセキュリティを担保することが重要です。コンテナセキュリティに関しては、FalcoやTetragonなどのプロセス監視ツールを活用し、不正な活動を検知するルールを設定することが重要です。また、設定や運用が複雑な場合もありますが、ログの取得は重要です。ログを取得することで、侵入や侵害が発生した際にその影響を判断し、攻撃かどうかを分析するための情報を得ることができます。ログの取得はセキュリティ対策の基盤として重要です。
――「コンテナ実行基盤の適切なアクセス制御を行う上で、特に重要な設定や注意点はありますか？」とのことですが、いかがでしょうか。
水元：基本的にはデフォルト設定でそれほど危険な状態にはならないと思いますが、最も重要なのは外部からのアクセスを遮断することです。境界防御に関しては賛否がありますが、外部からの攻撃を防ぐことが非常に重要です。具体的には、DockerのAPIサーバーへの外部アクセスを遮断することが大切です。内部のアクセス制御や権限分離も必要ですが、外部アクセスの制限ほど優先度は高くありません。また、開発環境と本番環境の要件を明確に分け、本番環境に必要なアクセス制限やセキュリティレベルを開発環境からも適用すべきか検討することが重要です。
――seccompの設定について、先ほど話していましたが、例えばEKSやGKEでは自動的に適用されているイメージがあります。これ以外に考慮すべき点や設定として何かありますか？
水元：seccompの設定は自動的に適用されることが多いですが、システムのセキュリティ要件に応じて、独自のプロファイルを作成して設定を強化する必要がある場合もあります。クラウドを使用していない場合も自分たちで設定する必要があります。コンテナのセキュリティは内部の問題であり、外部から侵入された後の次の手段として考えるべきなので、デフォルト設定をそのまま使用することでも十分なセキュリティ強化が図れます。
――ありがとうございます。
――テーマ1では、Webアプリケーションのコンテナデプロイにおいて優先的に対策すべきポイントについてお伺いしました。デプロイ前は、コンテナプロセスへの侵入対策や脆弱性の対策、パッケージの更新が重要です。デプロイ後は、ランタイムの脆弱性対策としてアクセス制御やセックコンプの設定見直しが必要です。
――次に関連する質問がいくつか来ているので、それらを順番に消化していきたいと思います。残り時間は約10分ですので、上から順に質問をお聞きします。
――「コンテナエスケープによる被害を最小限に抑えるために、コンテナのサンドボックス化についてどのような手法が有効でしょうか？gVisor、Kata Containers、Firecrackerの特徴と使い分けについても教えて下さい。」とのことですが、いかがでしょうか。
水元：各環境によって使えるツールが異なるため、GKEやEKSなど、それぞれの環境で使用可能なものを選ぶ必要があります。コンテナのサンドボックス化はランタイムの設定で可能ですが、実際にそこまでの対策が必要かどうかを検討するべきです。特にコンテナからホストや他のコンテナへのアクセスを厳密に遮断するケースがどれほどあるかは疑問です。そのため、導入のコストとリスク軽減効果を比較し、慎重に検討することが重要です。
――続けて、「ざっくりした質問で申し訳ないのですが、ホストOSにEDRが入っている場合、どこまでコンテナ内の挙動を監視できているものでしょうか？例）ファイルやOS API call等は監視できるが、プロセスまでは監視できない等」とのことですが、いかがでしょうか。
水元：EDRによって異なる部分もありますが、私が普段使用しているCrowdStrikeのFalconは、コンテナのプロセスをある程度検知できます。コンテナ内でプロセスを実行し、そのログがEDRに記録されているかを確認しています。ログには実行したコマンドが残るため、ある程度の検知は可能です。ただし、全てのプロセスや、ネットワーク通信、ファイル操作などを完全に検知できるかは製品次第です。使用中のEDRがあれば、コンテナ内での操作を試し、確認することが推奨されます。
――続けて、「最新の脅威情報を集めるためにおすすめの方法やサイト等があれば教えて頂きたいです。」とのことですが、いかがでしょうか。
水元：最新のセキュリティ情報については、いくつかのニュースサイトもありますが、私は主にX（旧Twitter）で情報を収集しています。国内外の多くのエンジニアがセキュリティ情報を発信しているので、そういったアカウントをフォローしてウォッチするのが最も手軽です。もっと専門的な情報を求める場合は、HackerOneやTechFeedが良いです。TechFeedはセキュリティ情報のまとめとして特に優れている印象があります。
騒がれているセキュリティ情報は重要ですが、騒がれていないものはそこまで重要ではない場合もあります。CVE情報は大量に出ていますが、実際に深刻なものは少ないため、主要な情報ソースからまとめを取得する方が効率的です。
――続けて、「ホストとコンテナ間の境界防御の適切な設定方法・注意点や、アクセス制御の具体例などあれば教えていただきです。」とのことですが、いかがでしょうか。
水元：ホストとコンテナのセキュリティ設定では、ルートレスモードを使ったり、特権コンテナ、またはPrivilegedコンテナを使用しないことや制限するなど基本的な設定が重要です。これらの設定を行った後、Dockerfileのセキュリティスキャンを行い、重要な対策を選択することが推奨されます。
ベストプラクティスに基づいたセキュリティスキャンを行えば、ほとんどの対策が簡単に取れます。しかし、本当に必要な対策かどうかは検討が必要です。手軽にスキャンを行って、必要な対策を判断することができます。
――続けて、「悪意のあるパッケージ混入を防ぐうえで、コードレビュー徹底を上げてましたがどのような点をみるべきでしょうか？」とのことですが、いかがでしょうか。
水元：パッケージの混入や依存関係は、アプリケーションコードのセキュリティに影響を与えます。言語ごとに依存関係が記述されたファイルがあり、これを確認することが重要です。ソフトウェアサプライチェーンに関するフレームワークやツールを使用して、依存関係を管理・監視することが役立ちます。
また、完全な防御は難しいため、他のセキュリティ対策と組み合わせて対策を取る必要があります。具体的な攻撃は主に外部サーバーとの通信や内部プロセスの異常な挙動に関連しています。ネットワークの監視や不審なプロセスの監視と組み合わせた対策が有効です。
