コンテナセキュリティのベストプラクティス5選
2022年7月19日
0 分で読めますコンテナセキュリティが重要なのは、コンテナイメージにアプリケーションの実行に必要なすべてのコンポーネントが含まれているためです。イメージに脆弱性が潜んでいると、本番環境でセキュリティ上の問題が発生するリスクと潜在的な影響が大きくなります。そのため、本番環境も監視することが重要です。脆弱性や過剰な権限のないイメージをビルドしても、実行時のアクティビティを監視し続ける必要があります。
安全なコンテナイメージを作成するための重要なステップは、大きく分けて次の5つです。
1. コードと依存関係を保護する
コンテナ化は、クラウドネイティブアプリケーションをより迅速に提供する方法の一つです。そもそもコンテナを作成する理由も、おそらくそのためでしょう。コンテナによってアプリケーションコードの意味する範囲は広がりましたが、コードは依然として、開発者が最も直接的に管理できる領域です。オープンソースの依存関係が独自コードの量を大きく上回ることも珍しくありません。そのため、ソフトウェア構成分析（SCA）と静的アプリケーションセキュリティテスト（SAST）ツールを統合してスキャンを行い、コードと依存関係の分析を自動化することが重要です。また、コンテナをスキャンして、Gitのコミットやリポジトリ内の問題を直接検出することもできます。こちらのほうが、開発プロセスに適している場合もあります。
2. 信頼できるソースの最小限のベースイメージから始める
イメージを小さくすると、移植性が高まりダウンロードも速くなるだけでなく、脆弱性が潜む可能性のある構成要素を減らせます。理想的には、各コンテナイメージにはコードと、アプリケーションの実行に必要な最小限の追加パッケージだけを含めます。ただし実際には、多数のアプリケーションを扱うため、管理しやすいコンテナイメージを作るには、共通の基準を見つける必要があります。
ベースイメージの選定にあたっては、信頼できるベンダーが多数のコンテナベースイメージを提供しています。なかでもDocker Hubは圧倒的に人気が高く、提供されているイメージは380万以上、リポジトリは700万以上で、月間プル数は約110億回に上ります。その一部は、厳選されたDockerのオープンソースや「ドロップイン」ソリューションのリポジトリとして、Dockerが公開するDocker Official Imagesです。また、DockerはVerified Publishersが直接メンテナンスする高品質なイメージも提供しています。Verified Publishersに関するDockerのガイドラインは、独自のコンテナイメージのベストプラクティスを定める際の優れた出発点となります。
Docker Hubで用途に合った公開イメージを見つけるのは簡単ですが、その出所には注意が必要です。Docker Official Imagesプログラムのイメージかどうかを確認するか、Notaryなどを使ってデジタル署名を検証し、ソースと内容を確認することで、一定の品質を確保しましょう。
3. ベースイメージとコードの間にあるすべてのレイヤーを管理する
ベースイメージには、特に注意が必要です。独自のイメージをその上に構築すると、ベースイメージに含まれるものをすべて引き継ぐことになります。軽量なイメージから始めても、コードや動作に必要なインストールに加えて、ツールやライブラリを追加することになるでしょう。これらすべてについて、脆弱性がないか監視する必要があります。
幸い、中間レイヤーは直接管理できます。ただし、開発、テスト、本番環境へのデプロイの各段階で、どこに注力するかを優先順位付けすることが重要です。各段階で異なるツールが必要になる場合もありますが、イメージを本番環境に移行する際には、どうしても必要なもの以外はすべて削除しましょう。
最小限のベースイメージから始め、必要なツールだけを追加しておけば、Dockerfileからツールを削除して再ビルドするだけで、あとから簡単に取り除けます。また、マルチステージビルドを使えば、すべての段階を単一の自動化されたビルドプロセスにまとめることができます。中間レイヤーにインストールされたツールやサポートパッケージに脆弱性が見つかっても、本番イメージに含まれないのであれば、無視しても問題ない場合があります。マルチステージビルドのベストプラクティスについては、こちらのブログ記事をご覧ください。
4. アクセス管理を導入する
コンテナにおけるアクセスとは、特定のユーザーが、特定のコンテナリソースに対して特定の操作を実行できることを指します。一般的な操作は、作成、読み取り、更新、削除（CRUD）に分類されます。アクセス管理の詳細は、コンテナプラットフォームによって異なります。たとえばKubernetesでは、ユーザーはクラスターの外部に存在するため、管理者はTLS証明書、OAuth2、その他の認証方式を使って、クラスター外でIDを管理する必要があります。
シークレットとネットワークアクセスは、最小権限の原則に基づいて管理しましょう。管理者アクセスは、インフラの構築に必要な範囲に制限する必要があります。コンテナがすべてのリソースに完全にアクセスできないよう、コンテナごとに役割と責任を明確に割り当て、それらの役割を支援、適用、監視するツールを活用しましょう。
5. コンテナインフラを保護する
コンテナイメージや実行中のコンテナを保護するだけでなく、コンテナの実行に必要なインフラスタックも管理する必要があります。Docker Hubのようなコンテナレジストリから、Kubernetesによる本番環境のオーケストレーションまでが対象です。
コンテナレジストリは、コンテナを安全に保管・共有できる場所を提供してコラボレーションを促進するよう設計されていますが、脆弱性やマルウェア、漏えいしたシークレットを持ち込む可能性もあります。多くの場合、セキュリティ機能が組み込まれていますが、レジストリへの接続には常にTLSなどのセキュリティプロトコルを使用してください。またKubernetesには、クラスターとネットワークの両方のレベルでセキュリティ制御を作成・適用するツールが含まれています。詳しくはコンテナレジストリのセキュリティに関する記事をご覧ください。
コンテナは必ず、セキュアなシステムまたはクラウドサービス上で実行してください。サービスを利用する場合は、レジストリへのアクセスにロールベースのアクセス制御（RBAC）を使用しましょう。
もう一点、攻撃者はCI/CDパイプラインのより早い段階に狙いを定めています。初期の開発段階の保護も見落とさないようにしましょう。アプリケーションやコンテナをビルドする際は、アプリケーションで使用する前、そしてデプロイ前にコードをスキャンすることが重要です。さらに、最小権限の原則（POLP）に従い、開発パイプライン内のセキュリティチェックと制御を自動化しましょう。