コンテナの静的・動的スキャン

コンテナの動的スキャン

コンテナの静的スキャンが動作していないコンテナイメージを対象としているのに対し、動的コンテナスキャンは動作中のコンテナを対象とします。

コンテナのCPU／メモリ使用量などのリソースは、DockerやKubernetesで制限可能です。アプリケーションの脆弱性やマルウェアの感染などは、使用前にイメージへ静的スキャンを行うことで防ぐことができます。では、コンテナの動的スキャンで何をスキャンすべきなのかを説明します。

コンプライアンス準拠

静的スキャンと同様に、動的スキャンでもセキュリティ基準を守る必要があります。コンテナの動的スキャンツールには、以下の基準に対応したものがあります。

• CIS
• PCI DSS
• NIST
• HIPPA（Health Insurance Portability and Accountability Act）
  • HIPAAは、米国保健福祉省の健康情報に関するセキュリティ基準

コンテナの大規模運用は欧米で行われることが多いため、セキュリティツールも欧米のセキュリティ基準に対応していることが多いようです。これは需要的な問題です。

コンテナ内プロセスの制限

多くの動的スキャンツールでは、コンテナ内のプロセスの動作に関して制限をかけることができます。

プロセス数／フォーク数／スレッド数の上限

コンテナ内のプロセス数の制限はDockerでは可能ですが、Kubernetesでは制限をかけられません。動的スキャンツールにより、1コンテナ（1ポッド）内で動作するプロセス数を制御することが求められます。Linuxではスレッドもプロセスとして扱われるため、プロセス数上限に含まれます。プロセス数の上限を制限することで、フォークボムや必要以上のサービス要求によりコンテナホストの負荷が上がることを防ぎます。

実行ユーザ／グループのブラックリスト・ホワイトリスト

セキュリティ上、コンテナ内の動作プロセスは非特権ユーザで動作することが望ましいです。実行プロセスのユーザ／グループを制限することで、想定外のユーザでのプロセス実行を防ぐことができます。この制限を行う場合は、ブラックリスト（除外するユーザ／グループ）とホワイトリスト（許可するユーザ／グループ）を併用して設定することが多いです。

実行ファイルのブラックリスト、ホワイトリスト

実行可能なファイルを指定することで、不必要な実行ファイルの起動の制御が求められます。実行ファイルを制限する場合、ブラックリスト（コンテナ内で、実行を許可しないファイルを指定）／ホワイトリスト（コンテナ内で、実行を許可するファイルを指定）で設定することが多いです。

ファイルのブラックリスト、ホワイトリスト

読み書きを行わないファイルを指定することで、不必要なファイルへのアクセスを制御することが求められます。これらも実行ファイルの制御と同様に、ブラックリスト／ホワイトリストで設定することが多いです。

パッケージのブラックリスト、ホワイトリスト

コンテナイメージに含まれる、特定パッケージ内のファイルの読み書き実行を防止することが求められます。この制御により、依存関係により含まれてしまうパッケージでも、その使用を制御可能です。

コンテナホスト機能の制限

コンテナ起動時もしくは動作中に、コンテナホスト側から動作を制限することでセキュリティを保ちます。

コンテナ特権の制限

指定された特権をつけた状態で、コンテナが実行されないよう制御します。この制御により、特権実行可能なコンテナ実行を許可しない／ホスト名前空間を使用しないなど、コンテナホストとコンテナの関係をセキュアに保つことが可能です。例えば、以下のような特権を許可／不許可できます。

• コンテナ実行時に新たな権限を追加
• ホストネット枠へのアクセス
• 特権ユーザでの1024ポート未満へのポートバインディング
• 特権ユーザでのユーザプロセス起動
• ホストIPC名前空間の使用
• ホストPID名前空間の使用
• ホストユーザ名前空間の使用
• ホストUTS名前空間の使用

system callのブラックリスト、ホワイトリスト

コンテナ内からカーネルへ呼び出されるsystem callを制御します。この制御により、不要なカーネル機能の呼び出しを防ぐことができ、コンテナホストの安全性を保つことができます。これらはブラックリスト（使用許可しないsystem callを指定）、ホワイトリスト（使用許可するsystem call を指定）で設定することが多いです。

セキュリティ設定の上書き防止

OSのセキュリティ設定（SELinux/AppArmor）を無効にした状態で、コンテナを起動しないよう制限できます。これによりセキュリティ設定を必ず有効にし、コンテナホストおよびコンテナをセキュアな状態に保つことができます。

ボリュームのブラックリスト

コンテナがホスト上の特定名のディレクトリを、ボリュームとしてマウントしないよう制御できます。例えば「/」や「/var」などをブラックリストに入れることで、コンテナからホスト側の情報を知ることができなくなります。

読み取り専用ディレクトリの指定

コンテナ内でinitdなどのスーパーデーモンを動作させるとき、「/sys/fs/cgroup」などをマウントすることが必要です。ただし、/sys/fs/cgroupは読み取り専用マウントでよいため、読み書き可能なボリュームマウントは必要ありません。このようなディレクトリを読み取り専用とすることで、コンテナ側からホスト側のファイルに書き込みする事態を防止できます。

コンテナホストのユーザ振る舞い検知

ほとんどのコンテナホストでは、コンテナホスト上の全ユーザの全実行コマンドを引数付きで、監査ログに保管可能です。この監査ログを保持することにより、コンテナホストの全ユーザ／全コンテナを対象として、全実行コマンドを後から監査可能です。また、ネットワークの振る舞いも同様に保持できます。

振る舞いを監査することにより、不正な動作が発生した場合に何が起こったのかをトレースできます。

差分の検知

コンテナ起動時の状態から、コンテナイメージにファイル差分を検知することがあります。このファイル差分は、攻撃を受けた結果の可能性があります。そのため、動作中のコンテナイメージの差分を検知することは、とても重要です。

差分があるファイルの実行防止

もとのイメージにないファイル／変更があったファイルの実行を制御することは、動的スキャンツールに必須の機能です。もとのイメージにないファイルを実行することは、マルウェアの感染やコンテナ外部からの攻撃を意味します。また、もとのイメージから変更されたファイルを新たに実行することも同様に、危険なことです。とあるコンテナセキュリティスキャンベンダーによると、差分があるファイルの実行を行わないようにすることで、コンテナへの攻撃の大部分は防げるそうです。

差分があるコンテナイメージの起動防止

静的脆弱性スキャンを実行済みのコンテナイメージは、そのイメージのチェックサムを保管すべきです。同じ名称でチェックサムが異なるコンテナイメージは、不正なイメージである可能性が高くなります。このようなイメージは操作ミス、もしくは内部からの攻撃により発生した可能性があります。このようなコンテナイメージの起動は防ぐ必要があります。

コンテナイメージの制限

コンテナ静的脆弱性スキャンをかけたコンテナイメージは、その情報（名称／チェックサムなど）を保管すべきです。また、静的脆弱性スキャンは繰り返し行われるべきです。コンテナ実行環境をセキュアに保つためには、コンテナイメージを起動してよいかどうかを判断する必要があります。

脆弱性スキャンで問題が出たイメージの実行禁止

脆弱性スキャンで問題が出たコンテナイメージは、そのイメージの新規起動を停止すべきです。

検出された脆弱性による影響などを考慮し、そのイメージを実行しても問題ないか検討する必要があります。コンテナイメージの再作成を行う必要や、一部機能を制限するなどの処置を行うべきかなどを検討し、問題なしと判断されたコンテナイメージだけを新規に起動するべきです。

指定されたイメージの実行禁止

脆弱性スキャンで問題が出たイメージや、不具合がわかっているイメージなど、特定のコンテナイメージを実行禁止にできます。指定されたイメージには、上記の脆弱性スキャンで問題が出たイメージなどを含みます。

指定されていないイメージの実行禁止

脆弱性スキャンが行われていないなど、許可されていないイメージを実行しないことは重要です。この制御により、本番環境での起動ミスや、内部からの悪意ある操作を禁止できます。

ネットワーク制御

コンテナの動的スキャンでは、ポートスキャンの検知／ブラックリストを使用したIP制限／ネットワークリンク制限などが可能です。これらの制御については次回説明予定です。

終わりに

コンテナの静的／動的スキャンにより、コンテナ実行環境をセキュアな状態に保つことができます。この制御にはOS機能やコンテナデーモンを制御することが重要です。また、不適切な設定を行っても事前に実行不可とすることで、人的ミスをある程度カバーすることも可能になります。

次回は、コンテナ間のネットワーク制限について説明します。次回をお楽しみに。