コンテナ・セキュリティーとは

コンテナ・セキュリティーは、保護対策の強化とセキュリティー・リスクの最小化の両方を目的としています。

まず、「コンテナ・セキュリティー」には複数の意味があるため、ここでは何を説明しているのかを明確にしましょう。コンテナとは、アプリケーションのコードと必要なすべてのライブラリーおよび依存関係をバンドルした自己完結型のソフトウェア・ユニットです。これより、デスクトップ、従来型のITインフラストラクチャーおよびクラウド・インフラストラクチャーなど、あらゆるコンピューティング環境でコードを実行できるようになります。ここで説明しているセキュリティー上の課題は、データを保持・保護するコンテナに焦点を当てています。

データは今や商取引とコミュニケーションの生命線です。現代の世界はデータがなければ機能しなくなるため、何としてでも情報を保護する必要があります。欺瞞と犯罪は、今なお人間の本質の一部として根強く存在しています。現在のサイバー犯罪者は、以前の泥棒と同じ動機を持っており、セキュリティーの脆弱性を悪用するためのツールとノウハウを備えているに過ぎません。

データを完全に保護するためには、コンテナを理解する必要があります。さらにコンテナには、企業や個人のデータに対して多数のアクションを実行するアプリが格納されているため、アプリの重要性をしっかり理解する必要があります。

アプリはいくつあるでしょうか。正確な数を探り当てるのは困難ですが、2025年4月までに、Google PlayとApple App Storeはそれぞれ約200万種類のアプリを提供しました。これらのアプリを使用するのが組織か個人かにかかわらず、アプリのユーザーからアプリ自体へのデータ転送が行われる以上、セキュリティーの脆弱性はほぼ確実に発生します。

こうした転送は、ゲーム・アプリで遊ぶために個人的な財務データを提供する個人から、会計アプリに機密データや専有情報を提供する企業まで幅広く行われます。こうした情報がもしも（マルウェアやその他のタイプのサイバー脅威によって）盗まれたり暴露されたりすれば、渉外業務上の悪夢、競争優位性の喪失、セキュリティー侵害につながりかねません。さらには、数百万ドル、いや数十億ドル相当の顧客データ盗難に至る可能性さえあります。

あらゆるレベルで、膨大な個人情報がアプリと共有され、またアプリを通じて共有されています。リスクは大きいため、強力なコンテナ・セキュリティー体制を維持することは、サイバーセキュリティーの極めて重要な部分となります。

ソフトウェア開発の文脈では、コンテナ・テクノロジーはアプリケーションの実行に必要なものすべてを保持しています。コンテナは、すぐに使用でき、さまざまな環境で一貫して実行できる自己完結型のエンティティーとしてすべてのものをパッケージ化します。アプリの実行に必要なすべてのファイルは次のとおりです。

• アプリケーション・コード： アプリケーション・コードには、ソースコードやコンパイル済みバイナリー・コードなど、アプリケーションのすべての実行可能ファイルが含まれます。

• ランタイム環境： コンテナ・ランタイム環境には、アプリケーションのコードの実行に必要なフレームワーク、ライブラリー、およびツールが含まれています。

• システム・ライブラリー： システム・ライブラリーは、グラフィック・ライブラリー、ネットワーク・ライブラリー、ファイル入出力トランスポート・ノードなどの共通機能を提供する共有リソースです。

• システム・ツール：各アプリには、アプリの機能を適切に実行するための特定のユーティリティーとツールが必要です。

• 構成ファイル：構成ファイルは、アプリの動作方法と、アプリに適用される設定を確立します。

• 依存関係：依存関係とは、アプリが期待どおりに動作するためにアクセスする必要がある、外部にあるフレームワーク、コンポーネント、ライブラリーのことです。

• 環境変数：開発環境、テスト環境、本番環境は、コンテナ実行時の動作に応じて変更できます。コンテナ化された環境内の変数は、こうした設定の制御に役立ちます。

• オペレーティング・システム・カーネル： コンテナには、完全な オペレーティング・システム（OS）は必要ありません。代わりに、OSカーネルの機能を活用する、一種のオペレーティング・システム仮想化を使用します。

• セキュリティー設定：この設定により、ユーザーはアクセス制御、機能、リソース制限などの変数を調整して、導入されているセキュリティー対策をカスタマイズできます。

コンテナ・イメージは静的で変更されることのないファイルで、実行可能なコードを含み、ITインフラ上で他と分離された状態で動作します。コンテナ・イメージには、オペレーティング・システム上でコンテナを作成する際に必要なコンポーネントが格納されています。コンテナ・イメージはさまざまなレイヤーで構成されており、テンプレートのように機能します。

コンテナ・イメージは、クラウドネイティブ環境でアプリケーションを配信するためのデフォルトの形式であり、ここがコンテナ・セキュリティーの開始点です。ベース・イメージは、すべての派生イメージの基盤となるため、セキュリティーの観点から非常に重要です。コンテナのセキュリティーは、信頼できるソースを使用することから始まります。イメージが信頼できる組織から取得され、信頼できるレジストリーでホストされ、すべてのコンポーネントについて入手可能なソースコードが含まれていることを確認する必要があります。

たとえ信頼できるベースイメージから始めた場合でも、ライフサイクル全体を通じて脆弱性を積極的に管理することが不可欠です。レジストリーに統合されているか、別のツールとして提供されているイメージ・スキャナーを使用して、すべてのコンテナ・イメージを定期的にスキャンしましょう。また、一般的にコンテナ構成ミスと呼ばれる、ポリシーやベスト・プラクティスに違反するコンテナ・イメージも特定してください。

ソフトウェア開発ライフサイクル（SDLC）は、ソフトウェアとその稼働期間における寿命の「シーズン」を管理します。ここに概説されている7つの段階はすべて必要なものであり、順番に実行する必要があります。

これらの開発段階には、数多くの重要なテクノロジーが密接に関連しており、それぞれのソリューション（およびそれらが提供するセキュリティ対策）についても、SDLCにおいて使用する段階で説明します。

最初の段階は、プロジェクトのあらゆる側面を定義することです。つまり、まずはプロジェクトの範囲、期待する目標、取り組みに利用できるリソースを大まかに定めるということです。ただし通常は、コストとメリットの分析、実現可能性調査、スケジュール設定などといった他の活動もこの段階において行います。

次の2つの関連するテクノロジーは、SDLCのどの段階でも実装できるため、計画段階で議論することをおすすめします。

• CI/CDパイプライン：継続的インテグレーション/継続的デプロイメント （CI/CD）パイプラインは、自動化したセキュリティー・チェックを使用してコンテナ化されたアプリのスピードアップと合理化を実現するDevOpsワークフローです。自動化した継続的なセキュリティー監視を通じて、問題にフラグを立てて修復作業を行うことができるため、さらなる影響が発生する前に修復を行うことができます。このパイプラインは、シフトレフトの導入によってさらに強化できます。これは、DevOpsプロセスの早い段階でセキュリティー対策を組み込むアプローチです。コンテナをCI/CDパイプラインと組み合わせることで、DevSecOpsチームが用いるワークフロー全体にセキュリティー・プラクティスを統合できるようになります。

• サプライチェーン：サプライチェーンも、コンテナのセキュリティー要素と密接に絡み合っている関連テクノロジーの一例です。サプライチェーンにおけるコンテナ・セキュリティーの強化に取り組むセキュリティーチームは、コンテナ・イメージと関連コンポーネントを定期的にスキャンします。そうすることで、新たなサイバー脅威や既知の脆弱性に対処できます。

次の段階では、利害関係者とユーザーのニーズというレンズを通して、プロジェクトのニーズをさらに掘り下げます。ここでは、プロジェクトに適用されるさまざまな要件をすべて収集、分析、管理する必要があります。

この段階では、通常は設計者が注目されます。これは、要件に関して収集したすべての情報を実際のソフトウェア設計に集約するためです。この設計の青写真では、必要なアーキテクチャー、必要なデータ構造、採用すべきユーザー・インターフェースを記述します。

以下に挙げる4つの関連テクノロジーは、使用する際には設計段階において扱うことが望ましいものです。

• クラウド：コンテナの普及は、クラウド・コンピューティングの広範な受容と時期を同じくしています。コンテナは現在、クラウド内において、クラウドネイティブ・アプリケーションを作成するために大量に使用されています。クラウドベースの情報資産を保護する責任は、IBM Cloud、Google Cloud、Microsoft Azure、Amazon Web Services（AWS）などのクラウド・サービス・プロバイダーにあります。クラウド・セキュリティーを確立するには、データ保護、インフラストラクチャー・セキュリティー、およびID管理を促進するセキュリティー対策を講じる必要があります。クラウドに移行したワークロードは、従来のワークロードと同じ基本的なセキュリティー問題に対処します。イメージ・リポジトリーは、クラウド環境に保存されている場合でも、その実行可能性を確保するために定期的なスキャンが必要です。クラウドの実装は、理想的にはSDLCの設計段階から開始すべきです。これは、クラウドがアーキテクチャとリソース計画に大きな影響を与えるためです。この両方とも、開発を開始する前に対処すべき課題です。

• Linux：Linuxはコンテナ・セキュリティーにおいて重要な役割を果たします。オープンソース・プラットフォームは、コンテナ・セキュリティーで使用される基本的な構成要素と、ファイアウォールなどの必要なセキュリティー機能を提供します。Linuxの名前空間は、環境内で実行中のコンテナを効果的に分離し、リソースへのアクセスを最小限に抑えながら、一貫したオペレーションを維持するための場所です。Linuxコンテナは、コンテナ化されたワークロードを制限および分離するためのさまざまな方法を用いて、Linuxカーネルの機能を最大限に活用します。Linuxは、主要なプログラムの詳細が確定し、実際のコーディングが始まる場所です。そのため、設計段階またはその後の実装で取り組むことができます。

• マイクロサービス：Linuxと同様に、マイクロサービスはコンテナを使用して各マイクロサービスの分離を強制し、ホストOSや他のサービスとは独立した「サンドボックス」環境を提供します。これにより、マイクロサービスのコンテナの拡張性が高まるだけでなく、攻撃対象領域が縮小され、防御能力が向上します。他のコンテナ・セキュリティーのベスト・プラクティスと同様に、マイクロサービスも最小権限の原則を採用しています。この原則では、コンテナには必要最小限の権限のみが付与されるため、意図したとおりに機能を実行できますが、リソースにアクセスしたり、他のコンテナに悪影響を与えたりすることはありません。理想的には、マイクロサービスは設計段階で使用すべきです。なぜなら、モノリシック・アプリはより小さいサービスに分割され、個別にデプロイできるからです。ただし、状況によっては、デプロイメント段階でマイクロサービスを使用することもできます。

• 仮想マシン：仮想マシン（VM）は追加の分離レイヤーを提供するため、コンテナのセキュリティーを強化できます。VMは独立したOSを持ち、リソースを求めてホスト・システムにアクセスする必要がないため、他のコンテナとのやりとりによってコンテナが汚染されるリスクを軽減できます。VMはまた、セキュリティー境界がコンテナ単体で達成できるよりも強力なため、セキュリティー侵害がファイルシステム全体に広がって処理中のワークフローに悪影響を及ぼす可能性を減らすために役立ちます。仮想マシンの使用は、設計段階で行うべきです。なぜなら、システムのアーキテクチャーと構造が理論化され、計画されるのは設計段階だからです。

すべての「準備」作業が完了したら、いよいよソフトウェア・デザイナーが提供した設計仕様を使用してソフトウェアを構築します。開発者はコードを記述し、アプリケーション・プログラミング・インターフェース（API）を作成し、必要に応じてコンポーネントが統合されていることを確認します。

Linuxは通常、設計段階で使用されますが、開発段階でも使用されます。なぜなら、開発段階ではソフトウェアのアーキテクチャーやプラットフォームが決定され、コーディング・プロセスもこの段階から始まるためです。

適切なテスト・システムを作成することで、作成したコードが期待どおりに動作し、バグがないことが保証されます。特に新しい脆弱性が発見された場合、セキュリティー上の問題があるビルドにフラグを立てるポリシーを自動化することが重要です。コンテナにパッチを適用するのは、コンテナを再構築するほど効果的ではないため、セキュリティー・テストには、自動で再構築をトリガーするポリシーを含めるべきです。テスト段階には、統合テスト、単体テスト、システム・テストを含めることができます。

これまでの段階がすべて完了したのなら、ソフトウェアを公開し、ユーザーにリリースします。デプロイメントには、ソフトウェアのパッケージ化や構成など、ソフトウェア製品を大量配布用に準備するために必要なすべての関連タスクが含まれます。

Kubernetesは、コンテナ化されたアプリを保護するための自動化されたオープンソース・プラットフォームを提供することで、コンテナ・オーケストレーションの取り組みとコンテナのセキュリティーをサポートします。Kubernetes環境は、ロールベースのアクセス制御（RBAC）、ポッド（Kubernetesにおけるコンテナの管理単位）間の通信を管理するネットワーク・ポリシーなどのセキュリティー機能を提供します。また、シークレット管理（パスワード、APIキー、暗号化キー、トークンなどの機密データの安全な保管を優先）も提供します。

Kubernetes のセキュリティー・プロセスでは、Kubernetesクラスター全体を定期的に監視して、設定ミス、つまりセキュリティー・リスクの扉を開いて脆弱性を露呈する可能性のある設定がないかを確認します。技術的には、Kubernetesはソフトウェアのライフサイクルのどの段階でも採用できますが、一般にKubernetesの主な用途として認識されているのは、コンテナ化されたアプリケーションのデプロイメントとスケーリングの処理です。

前述したように、マイクロサービスはデプロイメント段階でも使用できます。

SDLCプロセスの最終段階は、ソフトウェアに対する継続的なサポートを提供することです。この段階では、プログラムの機能拡張、バグ修正、その他のパフォーマンス改善などが行われる場合があります。

セキュリティー・ポリシーの有効性を強調するために組織が実行できる日常的な手順はさまざまです。これらの多くは、常識的なアプローチに基づいており、実証済みの脆弱性管理原則を用います。