鳩小屋

落書き帳

コンテナの脅威モデル

脅威分析の目的は下記参照。

kurobato.hateblo.jp

セキュリティの観点から見ると、コンテナ化された環境では、多くが従来のデプロイメントと同じになります。世の中には、データを盗んだり、システムの動作を変更したり、他人のコンピュートリソースを使って自分の暗号通貨を採掘しようとする攻撃者がいます。これは、コンテナに移行しても変わりません。しかし、コンテナはアプリケーションの実行方法を大きく変え、その結果、さまざまなリスクが発生します。

リスクは、潜在的な問題が発生した場合の影響を指します。脅威は、そのリスクの発生源です。緩和策は、脅威に対する対策です。

脅威のアクター

脅威モデルについて考え始める一つの方法は、関係するアクターを考えることです。関係者には次のようなものがあります。

  • 外部から配置にアクセスしようとする外部攻撃者

  • デプロイメントの一部になんとかアクセスしようとする内部攻撃者

  • デプロイメントにアクセスするためのある程度の権限を持つ開発者や管理者などの悪意のある内部アクター

  • 偶然に問題を引き起こす可能性のある内部アクター

  • システムを侵害しようとする意識を持った存在ではないが、システムにプログラムでアクセスできる可能性のあるアプリケーションプロセス

コンテナの脅威

f:id:FallenPigeon:20210419100731p:plain

f:id:FallenPigeon:20210410181319p:plain

  • 脆弱なアプリケーションコード

ライフサイクルは、開発者が作成するアプリケーションコードから始まります。このコードと、コードが依存しているサードパーティの依存関係には、脆弱性として知られる欠陥が含まれている可能性があり、公開されているものだけでも数千件あります。
脆弱性は、アプリケーションに存在した場合に攻撃者が悪用できるものです。既知の脆弱性を持つコンテナの実行を避けるための最良の方法は、イメージをスキャンすることです。既存のコードには常に新しい脆弱性が発見されているため、これは1回限りの活動ではありません。また、スキャンプロセスでは、セキュリティパッチの更新が必要な古いパッケージを使用したコンテナが実行されているかどうかを特定する必要があります。スキャナの中には、イメージに組み込まれたマルウェアを識別できるものもあります。

  • 不適切に設定されたコンテナイメージ

コードが書かれると、それがコンテナイメージに組み込まれます。コンテナイメージの構築方法を設定する際には、後で実行中のコンテナを攻撃するために使用できる弱点を導入する機会がたくさんあります。例えば、コンテナをルートユーザとして実行するように設定すると、ホスト上で実際に必要な以上の権限が与えられます。

  • ビルドマシンへの攻撃

攻撃者がコンテナイメージのビルド方法を変更したり、影響を与えたりすると、後に本番環境で実行される悪意のあるコードが挿入される可能性があります。また、ビルド環境で足場を確保することで、本番環境への侵入の足がかりとなる可能性もあります。

コンテナのイメージが構築されると、それはレジストリに保存され、実行される時点でレジストリから取り出される、つまり「プル」されます。取り出したイメージが以前にプッシュしたものと全く同じであることをどうやって確認することが必要になります。

  • 不適切に設定されたコンテナ

コンテナに不必要な権限を与える設定でコンテナを実行することが可能です。インターネットからYAML設定ファイルをダウンロードした場合、安全でない設定が含まれていないことを確認して実行する必要があります。

  • 脆弱なホスト

コンテナはホストマシン上で動作しますが、これらのホストが脆弱なコード(例えば、既知の脆弱性を持つ古いバージョンのオーケストレーションコンポーネントなど)を実行していないことを確認する必要があります。攻撃対象を減らすために、各ホストにインストールされているソフトウェアの量を最小限にするか、ベストプラクティスに従って正しく設定する必要があります。

  • 露出したシークレット情報

アプリケーションコードは、システム内の他のコンポーネントと通信するために、認証情報、トークン、またはパスワードを必要とすることがよくあります。コンテナ化されたデプロイメントでは、これらの秘密の値をコンテナ化されたコードに渡すことができなければなりません。環境変数やマウントを利用するアプローチがあります。

  • 安全でないネットワーキング

コンテナは通常、他のコンテナや外部と通信する必要があります。コンテナ間通信や他ホスト上のコンテナと通信する際にバインドポートの制限や通信の暗号化が必要になります。

containerd や CRI-O など、広く使用されているコンテナランタイムは、現在ではかなり強化されていますが、コンテナ内で実行されている悪意のあるコードをホスト上に逃がしてしまうようなバグがまだ見つかる可能性もあります。アプリケーションによっては、エスケープの結果が十分に損害を与える可能性があるため、より強力な隔離機能の仕組みを検討する価値があります。