コンテナランタイムセキュリティについて知っておくべきこと

コンテナオーケストレーションシステムのKubernetesを使うと、大規模なコンテナのセットアップや管理が簡単になります。コンテナの導入が進むにつれ、こうしたオーケストレーションシステムの利用も急増しています。たとえば現在、Kubernetesはコンテナ化されたアプリケーションの4分の3以上をオーケストレーションしています。もちろん、こうしたプラットフォームの人気が高まるほど、サイバー犯罪者に狙われやすくなります。Kubernetesでは、開発中のコンテナを保護するために、Podセキュリティポリシーやドリフト管理を提供しています。しかし、コンテナがランタイム環境に移行した後はどうでしょうか。

DockerやKubernetesには、コンテナにセキュリティを組み込むためのツールが数多くありますが、ランタイム環境そのものを保護するわけではありません。その結果、本番環境のコンテナを保護するために、ツール、プロセス、ポリシーを組み合わせた豊富なランタイムスタックが登場しました。

コンテナランタイムに伴うリスクと、本番環境のコンテナを保護するためのプロセスについて解説します。

実行中のコンテナを保護する際の課題

コンテナのビルドにセキュリティを組み込む、小さなコンテナイメージを作成するといった対策は、コンテナイメージにセキュリティ上の問題が入り込むのを防ぐのに役立ちます。しかし、コンテナの実行後には、次のような脅威が発生する可能性があります。

• 古いイメージに含まれる、後から発見されたアプリケーションの脆弱性

• 構成ドリフト（権限のないユーザー権限の変更など）

• 攻撃者がシークレット、ストレージボリューム、その他のリソースにアクセスできるようにする権限昇格攻撃

• アクセス制御の不具合を悪用したコンテナのデプロイ

• コンテナ内に書き込まれた悪意のあるコードの実行

コンテナ監視ツールのPrometheusやGrafanaは、実行中のコンテナのパフォーマンスや効率を高めるためによく導入されますが、セキュリティを目的としたツールではありません。

コンテナランタイムのリスクを検出して修正する方法

実行中のコンテナを保護するには、ログインなどの重要なイベントを監視することが欠かせません。しかし、コンテナランタイムセキュリティは単なるイベント監視にとどまりません。まず、Kubernetesまたはカーネルレベルでポリシーを設定・適用するポリシー適用ツールを使い、アーキテクチャにセキュリティを組み込みます。次に、スキャンツールで監査ログ、Infrastructure as Code（IaC）、構成設定、アプリケーションコードそのものを分析し、本番環境の新たな脆弱性や設定ミスを検出します。

コンテナランタイムセキュリティの責任者は？

従来、アプリケーションランタイムの保護は、専任のセキュリティチームが担ってきました。しかし、アジャイル開発やクラウドネイティブ開発のスピードと複雑さが増すなか、開発者もコードに潜むセキュリティリスクへの対応にますます関与するようになっています。開発者はシフトレフトを進め、計画やコーディングの初期段階からセキュリティを取り入れています。

開発者が担うセキュリティの責任は、計画、コーディング、スキャン、デプロイからランタイム環境まで、コンテナのライフサイクル全体に広がっています。開発ライフサイクルの先を見据え、コンテナがランタイム環境に移行した後に何が起きるかも考慮する必要があります。

コンテナエンジンの安全なランタイム設定を選ぶ

コンテナエンジンのランタイム設定を適切に行うと、ネットワーク侵害後に攻撃者がアクセス範囲を広げるのを防げます。組織の保護を強化するために、次の設定を検討してください。

rootで実行しない

コンテナはrootではなく、一般ユーザーとして実行します。DockerfileでユーザーIDを定義してから、そのユーザーとして実行してください。これにより、ロールベースのアクセス制御でアクセスを簡単に制限できます。

ルートファイルシステムはデフォルトで読み取り専用にする

これにより、攻撃者がマシンを乗っ取ったり、ホストに悪意のあるコードを書き込んだりするのを防ぎます。

コンテナホストへのアクセスを制限する

サーバーへのSSH接続を禁止します。これにより、攻撃者やマルウェアがコンテナから脱出してホストシステムを攻撃するのを防ぎやすくなります。

Linuxのケイパビリティを削除する

ケイパビリティを使うと、監査ログの読み取りや権限チェックの回避など、カーネル上の権限を細かく調整できます。コンテナからLinuxのケイパビリティを削除することで、攻撃者がカーネルを操作する能力を制限できます。

特権モードで実行しない

コンテナランタイムには、ホストシステムからコンテナを隔離するための強固な仕組みが備わっています。これらのチェックの大半を回避してしまうため、特権モードでの実行は避けてください。

IaCスキャンでランタイムをスキャンし、設定ミスを検出する

開発者がクラウドインフラストラクチャやコンテナオーケストレーターを設定する際、設定ミスが入り込むのは簡単です。Snyk IaCによるIaCスキャンなら、Kubernetesなどの設定ミスを自動検出し、開発者のワークフローで使うツールに分析結果を返します。

ランタイムセキュリティ設定について詳しくは、「理解しておきたいKubernetes Security Context設定10選 | Snyk」をご覧ください。

コンテナランタイムセキュリティにおけるSysdigとSnykのパートナーシップ

実行中のコンテナを保護する万能なソリューションや魔法のボタンはありません。そのため、可能な限りセキュリティプロトコルを組み込むことが重要です。まず、脆弱性や設定ミスのある箇所を特定し、重大な問題から修正します。セキュリティはリスク管理の一環であるため、脆弱性だけでなく、その影響も把握する必要があります。さらに、Kubernetesのツールや設定を活用し、コンテナのセキュリティ態勢を強化することも重要です。

完全に自動化されたコンテナランタイムセキュリティソリューションで大半の問題を検出できても、セキュリティ問題を修正するには開発者の目が欠かせません。スキャンツールでランタイム環境の脆弱性や設定ミスを検出できますが、修正を適用するには、開発者が該当するコードに戻る必要があります。これは時間とリソースの無駄につながり、問題の見落としを招くこともあります。そこで役立つのがSnykです。Snykは開発者のワークフロー内で問題を検出し、修正方法を提案します。Snyk ContainerやKubernetes Configuration Securityなどのツールを使えば、DockerコンテナやKubernetesの構成をスキャンし、CI/CDツール内でフィードバックを受け取れます。

さらにSnykはSysdigと提携し、開発者ファーストのセキュリティをランタイム環境にも取り入れています。Sysdigのランタイムセキュリティは、オープンソースのFalcoを利用して、コンテナやKubernetes全体の侵入、脅威、脆弱性をリアルタイムで検出します。SnykとSysdigを連携することで、こうした分析結果を開発チームに直接共有でき、問題の優先順位付けと修正に役立てられます。

よくある質問