コンテナセキュリティとは？
コンテナセキュリティには、 コンテナ化されたアプリケーションと そのインフラストラクチャを、開発からデプロイ、ランタイムに至るまで、ライフサイクル全体を通して保護することが含まれます。脆弱性スキャン、コンフィギュレーション管理、アクセス制御、ネットワークセグメンテーション、モニタリングなどが含まれます。コンテナセキュリティは、リソースの共有と潜在的なアタックサーフェスに関連するリスクを最小限に抑えながら、アプリケーションの分離がもたらす本来の利点を最大限に引き出すことを目的としています。ベストプラクティスを順守し、専用のセキュリティツールを使用することで、組織はコンテナ環境を不正アクセスや データ漏洩から 保護しながら、業界規制のコンプライアンスを維持することができます。
コンテナセキュリティの説明
コンテナは 、 マイクロサービス・アーキテクチャを 活用し、より高速で移植性の高い運用を可能にします。コンテナには本質的なセキュリティ上のメリットもあります。ワークロードの 分離、アプリケーションの抽象化、コンテナの不変的な性質は、実際にコンテナの採用に大きく影響しています。
Kubernetesにもセキュリティ機能が組み込まれています。管理者は、ロールベースのアクセス制御（RBAC）ポリシーを定義して、クラスタリソースへの不正アクセスを防止できます。ポッドセキュリティポリシーとネットワークポリシーを構成して、ポッドとそれらを接続するネットワークでの特定のタイプの不正使用を防止できます。管理者は、クラスタの一部分を侵害する攻撃者による混乱を緩和するために、リソースの割り当てを課すことができます。たとえば、リソースクォータが設定されていれば、攻撃者は実行に必要なクラスタリソースの残りを奪って サービス拒否攻撃を 実行することはできません。
しかし、お察しの通り、悪意ある行為と無縁な技術はありません。コンテナセキュリティは、アプリケーションだけでなく、ホスト、ランタイム、レジストリからオーケストレーションプラットフォームや基礎システムに至るまで、コンテナ化された環境を保護するために実装される技術と実践が重要です。
ビデオコンテナイメージの脆弱性を検出し、コンテナスキャンによって開発ライフサイクル全体を通じてセキュリティとコンプライアンスを確保します。
背景
コンテナ セキュリティは、ITアーキテクチャの変化を反映しています。 クラウドネイティブ・コンピューティングの 台頭は、アプリケーションの作成方法を根本的に変えました。テクノロジーと歩調を合わせるには、セキュリティ確保へのアプローチを調整する必要があります。
これまでのサイバーセキュリティは、単一の境界を保護することを意味していました。コンテナはこの概念を時代遅れにし、コンテナ化された環境を解釈し、監視し、保護するための特別なツールを必要とする抽象化の複数の層を追加しました。
コンテナのエコシステムは、ツールの多さや、それらが従来のプラットフォームと比較して解決するユニークな問題を考えると、理解するのが難しいかもしれません。同時に、コンテナ技術の普及は、 CI/CDパイプラインの 初期段階からデプロイメント、ランタイムに至るまでコンテナセキュリティを確保するという、シフト・レフトの機会を与えてくれます。
しかし、コンテナ・セキュリティの詳細に入る前に、コンテナを管理するためのプラットフォームを理解する必要があります。ここでは、最大かつ最も有名なプラットフォームの1つであるKubernetesに焦点を当てます。
Kubernetesとは？
Kubernetesは、コンテナベースのインフラストラクチャの最適化と実装を支援する主要なオーケストレーション・プラットフォームの1つです。具体的には、アプリケーション開発、デプロイメント、管理などのプロセスを自動化することによって、 コンテナ化されたワークロードを 管理するために使用されるオープンソースのプラットフォームです。
広く採用されているオープンソースプラットフォームであるKubernetesのセキュリティ確保は、コンテナ化されたアプリケーションをデプロイする組織にとって極めて重要です。組織は、特にオープンソースのコードをサードパーティのアプリケーションに組み込む場合、安全な環境を確立する必要があります。コンテナを管理するための広範なエコシステムと数多くの統合機能を備えたKubernetesは、セキュリティをビルドとデプロイのパイプラインの中核に統合する自動化された体系的なプロセスの作成を可能にします。RBAC、ポッドセキュリティポリシー、ネットワークポリシーなど、Kubernetesのネイティブ機能を活用することで、組織は弾力性のあるコンテナオーケストレーションインフラストラクチャで強固なセキュリティ体制を構築し、維持することができます。
コンテナの利点
簡単に言うと、コンテナはクラウド ネイティブ アプリケーションの構築、デプロイ、スケーリングをこれまで以上に簡単にします。クラウドネイティブアプリの開発者にとって、コンテナがもたらすメリットには次のようなものがあります：
- 摩擦の排除：コンテナとしてパッケージ化されたアプリケーション・コードはどこでも実行できるため、開発者はアプリケーション・コードをテストから本番環境に移行する際の摩擦の多くを回避できます。
- アプリケーション開発のための真実の単一ソース：アプリケーションに関連するすべての依存関係は、コンテナ内に含まれます。これにより、仮想マシン、ベアメタルサーバー、パブリッククラウドのいずれにおいても、アプリケーションを簡単かつ同一に実行できます。
- ビルド時間の短縮：コンテナの柔軟性と移植性により、開発者はこれまで達成できなかった生産性の向上を実現できます。
- 開発者の自信開発者は、アプリケーションやプラットフォームがすべてのオペレーティング・システムで同じように動作することを知っているため、自信を持ってアプリケーションをデプロイできます。
- コラボレーションの強化：コンテナを使用する複数のチームは、他のコンテナにパッケージされたコードを中断することなく、アプリやサービスの個々の部分で作業できます。
他のITアーキテクチャと同様に、クラウドネイティブアプリケーションにもセキュリティが必要です。コンテナ環境は、そのイメージ、コンテナ、ホスト、ランタイム、レジストリ、オーケストレーション・プラットフォームを対象としたさまざまな サイバーセキュリティの課題を もたらします。
アタックサーフェスの理解
Kubernetesの広大で多層的なフレームワークを考えてみましょう。コードやコンテナからクラスタやサードパーティのクラウドサービスに至るまで、各レイヤにはそれぞれ固有のセキュリティ上の課題があります。
Kubernetesの デプロイメントを保護 するには、基盤となるインフラストラクチャ（ノード、ロードバランサーなど）、設定可能なコンポーネント、クラスタ内で実行されるアプリケーションを保護する必要があります。また、クラスタ内で悪意のあるワークロードが実行されないようにし、厳格な ネットワーク制御によってワークロードの通信を分離することも重要です。
コンテナランタイムには、コンテナ内での権限昇格を可能にするコーディング上の欠陥がある可能性があります。Kubernetes APIサーバーが不適切に設定されている可能性があり、攻撃者はロックされていると想定されるリソースにアクセスする機会を与えられます。 特権昇格攻撃を 可能にする脆弱性は、コンテナ化されたアプリケーション内、またはKubernetesノード上で稼働するオペレーティングシステム内に存在する可能性があります。
図1：コンテナ・アタックサーフェスの解剖
このシステムでは、あるレイヤーの問題が他のレイヤーのセキュリティ問題によって増幅されます。
そして、コンテナにはもちろん脆弱性が潜んでいる可能性があります。同時に、コンテナは視界を遮ります。1つの安全でないコンテナイメージが、別々の実行コンテナとして何度もインスタンス化されることを想像してみてください。ひとつの亀裂であった要塞は、今では広大な亀裂ネットワークとなっています。
コンテナのデプロイが進むにつれて、システム運用とセキュリティの可視性を維持することがますます難しくなっています。そしてそれは、知名度を維持することであり、数え切れないほどの目的のひとつです。
図 1 は、コンテナ型アプリケーションのアタックサーフェスを理解するための出発点となるものです。
重要なのは、描写が単純化されていることです。現実には、攻撃者はコンテナ化されたアプリケーションの脆弱性を悪用しようとする試みにおいて、多くの入り口を探っています。この技術スタックを守ることは、他の環境や技術を守ることよりも必ずしも難しいことではありません。コンテナ化は 、組織が安全で弾力性のあるインフラストラクチャのために対処する必要がある、独自のセキュリティ上の考慮事項を提示しているにすぎません。
| アタックサーフェス面積 | 攻撃ベクトル | 説明 | 例 |
| ネットワーク経由 | 悪意のあるネットワークトラフィック | ネットワークの脆弱性や設定ミスを悪用してコンテナ環境にアクセスすること。 | 開いているポートをスキャンし、設定ミスを悪用してワーカーノードにアクセスします。 |
| ホスト構成 | ホストシステムの設定ミス | ホストOSの設定ミスを悪用してコンテナ環境にアクセス。 | コンテナ設定ファイルなどの機密ファイルにアクセスするための、安全でないファイルパーミッションを検出します。 |
| ホストの脆弱性 | 未パッチのホスト脆弱性 | ホストオペレーティングシステムの脆弱性を悪用してコンテナ環境にアクセスします。 | パッチが適用されていないカーネルの脆弱性を特定し、それを悪用してワーカーノードの root 権限を獲得します。 |
| ホストアプリケーションの脆弱性 | 未パッチのホストアプリケーションの脆弱性 | ホストアプリケーションの脆弱性を悪用してコンテナ環境にアクセスします。 | ワーカーノードのroot権限を取得する脆弱性を持つ古いバージョンのDockerをターゲットにしています。 |
| コンテナ・オーケストレーションの脆弱性と誤認識 | コンテナ・オーケストレーションの設定ミス | コンテナ・オーケストレーション・システムの設定ミスを悪用してコンテナ環境にアクセス。 | Kubernetesクラスタの安全でないアクセス制御ポリシーを利用して、ポッドやサービスにアクセスします。 |
| 侵害されたコンテナイメージ | 攻撃者がコンテナイメージのビルドプロセスにアクセス | コンテナイメージのビルドプロセスを侵害し、コンテナイメージに悪意のあるコードを注入します。 | CI/CDパイプラインの 脆弱性を悪用して、コンテナイメージのビルドプロセス中に悪意のあるコードを注入します。 |
| コンテナの脆弱性と誤認識 | 未パッチのコンテナ脆弱性 | コンテナ自体の脆弱性を悪用して、コンテナ環境にアクセスします。 | コンテナ内で実行される一般的なアプリケーションのパッチ未適用の脆弱性を標的としたアクセス。 |
| コンテナ脱出 | 攻撃者がコンテナへの特権アクセス権を獲得 | コンテナの隔離を抜け出し、ホスト・システムにアクセスすること。 | コンテナランタイムの脆弱性を悪用したり、ホストシステムの設定ミスを悪用して、ホストシステムの root 権限を取得します。 |
表1：コンテナのアタックサーフェスの破壊
幸いなことに、アタックサーフェスの各レイヤーは、設計とプロセスの考慮、およびネイティブとサードパーティのセキュリティオプションによって強化することができ、ワークロードが侵害されるリスクを低減することができます。多角的な戦略が必要ですが、このセクションのガイドの目的は、まさにそれを提供することです。
図2：コンテナ セキュリティは、ソフトウェア開発ライフサイクル全体に及びます。
コンテナのセキュリティ方法
コンテナユーザは、コンテナ化アプリケーションの脆弱性管理、コンプライアンス、ランタイム保護、ネットワークセキュリティ要件に対応するために、目的に応じた フルスタックセキュリティを 確保する必要があります。
コンテナネットワーク セキュリティ
コンテナ化されたアプリケーションは、クリプトジャッキング、ランサムウェア、ボットネットC2など、ベアメタルやVMベースのアプリケーションと同じリスクに直面しています。コンテナネットワークセキュリティは 、不要な通信をプロアクティブに制限し、多数の戦略によって脅威がアプリケーションを攻撃するのを防ぎます。ネットワークセキュリティの主要コンポーネントには、 マイクロセグメンテーション、アクセス制御、暗号化、ポリシーが含まれ、安全で回復力のある環境を維持します。継続的なモニタリング、ロギング、定期的な監査は、潜在的なセキュリティギャップの特定と是正に役立ちます。
シフト・レフトのセキュリティ・ツールが既知の脆弱性に対するデプロイタイムの防御を提供するのに対し、 コンテナ型の次世代ファイアウォールは 未知の脆弱性やパッチ未適用の脆弱性に対する防御を提供します。 レイヤー7の ディープ・パケット・インスペクションを実行し、許可されたすべてのトラフィックをスキャンすることで、クラスタ内へのマルウェアの侵入と拡散を特定・防止し、データの流出やコマンド＆コントロール（C2）攻撃に使用される悪意のあるアウトバウンド接続をブロックします。IDベースのマイクロセグメンテーションは、レイヤ3と4のアプリケーション間の通信を制限するのに役立ちます。
コンテナランタイムセキュリティ
クラウドネイティブの ランタイムセキュリティは 、実行中のコンテナの新しい脆弱性を特定し、それに対してアプリケーションを保護するプロセスです。コンテナを使用する組織は、 強化されたランタイム保護を 活用して、異常検知の拠り所となる行動ベースラインを確立する必要があります。ランタイム・セキュリティは、ベースラインから逸脱した悪意のあるプロセス、ファイル、ネットワークの動作を特定し、ブロックすることができます。
組織は、OWASP Top 10 のようなレイヤ 7 攻撃を防ぐ深層防衛戦略を使用して、コンテナ化された次世代ファイアウォールによるコンテナネットワークセキュリティに加えて、 Web アプリケーションと API セキュリティによる ランタイム保護を実装する必要があります。
コンテナレジスタセキュリティ
コンテナの構築段階にセキュリティを導入するということは、実行時に反応的にではなく、左側にシフトするということです。構築段階のセキュリティは、脆弱性、マルウェア、安全でないコードの除去に重点を置くべきです。コンテナはライブラリ、バイナリ、アプリケーション・コードで構成されているため、コンテナ・レジストリのセキュリティは非常に重要です。
コンテナレジストリのセキュリティの 第一歩は、組織の公式コンテナレジストリを確立することです。間違いなく、1つ以上のレジストリがすでに存在しています。それを見つけ、セキュリティ基準やプロトコルの設定など、適切なセキュリティを確保するのがセキュリティチームの仕事です。コンテナ・レジストリのセキュリティ標準の包括的な目的は、信頼できるイメージを作成することにあります。そのためには、 DevOps チームとセキュリティチームは、何よりも、信頼できないレジストリからコンテナがデプロイされるのを防ぐポリシーで一致する必要があります。
レジストリ内の侵入や脆弱性は、実行中のアプリケーションを侵害するための容易な隙を提供します。脆弱性の状態が変化していないか、継続的にレジストリを監視することは、依然として中核的なセキュリティ要件です。その他の要件としては、レジストリをホストするサーバーをロックダウンし、安全なアクセスポリシーを使用することが挙げられます。
コンテナ・オーケストレーション セキュリティ
コンテナ・オーケストレーション・セキュリティは 、過剰な特権アカウント、ネットワーク経由の攻撃、望ましくない横移動によるリスクを防止するために、適切なアクセス制御測定を実施するプロセスです。 IDアクセス管理（IAM ）と 最小限のアクセス権を活用し、DockerとKubernetesのアクティビティを明示的にホワイトリストに登録することで、セキュリティチームとインフラチームは、ユーザが適切なロールに基づいたコマンドのみを実行できるようにすることができます。
さらに組織は、ポッド間通信を保護し、攻撃者が環境内を横方向に移動するのを防いで被害を抑え、あらゆるフロントエンドサービスを攻撃から保護する必要があります。
ホスト・オペレーティング・システム（OS）のセキュリティ
ホストOSセキュリティとは 、オペレーティングシステム（OS）をサイバー攻撃から保護することです。クラウドネイティブアプリの開発技術が成長するにつれ、 ホストのセキュリティに対するニーズも高まっています。
コンテナ環境をホストするOSは、おそらくコンテナセキュリティに関して最も重要なレイヤーです。ホスト環境を侵害する攻撃は、侵入者にスタック内の他のすべての領域へのアクセスを与える可能性があります。そのため、ホストは脆弱性をスキャンし、CIS Benchmarksを満たすようにハード化し、弱いアクセス制御（Dockerコマンド、SSHコマンド、sudoコマンドなど）から保護する必要があります。
コンテナ セキュリティ ソリューション
コンテナ環境のセキュリティを確保するには、潜在的な脆弱性や脅威に対処するための多層的なアプローチが必要です。近年、組織が開発、デプロイ、実行の各段階を通じてコンテナ化されたアプリケーションとインフラストラクチャを保護するために信頼できるコンテナセキュリティソリューションは、より洗練された機能を備えています。最新のセキュリティツールは、侵害やデータ漏えいのリスクを効果的に最小化し、コンプライアンスを促進し、安全な環境を維持しながら、 DevSecOps の 導入を加速します。
コンテナ監視
レジストリの 脆弱性を 監視 する機能は、コンテナのセキュリティを維持するために不可欠です。開発者はコンテナを継続的に取り替えたり取り替えたりしているため、コンテナ化された環境で何が起こったかを判断しようとする場合、セキュリティチームがコンテナに時系列スタンプを適用できる監視ツールが重要になります。
コンテナ監視に人気のあるツールには、Prometheus、Grafana、Sumo Logic、Prisma Cloudなどがあります。Prisma Cloudは、クラウドネイティブアプリケーションと従来型アプリケーションの両方に対して、ランタイムの脅威検知と異常分析を提供します。機械学習と行動分析を活用して、ビルドからランタイムまで、コンテナのライフサイクル全体にわたって疑わしいアクティビティを特定します。
コンテナスキャンツール
コンテナは、本番環境にデプロイする前も、交換した後も、継続的に脆弱性をスキャンする必要があります。開発者が、既知の脆弱性を持つライブラリを誤ってコンテナに入れることはあまりにも簡単です。また、新しい脆弱性が毎日のように発見されていることも忘れてはなりません。つまり、今日は完全に安全なコンテナイメージに見えても、明日にはあらゆる種類のマルウェアを配布するための手段になってしまう可能性があるということです。 コンテナイメージの信頼性を 維持することが、コンテナスキャンツールの中心的な要素であるのはそのためです。
コンテナ・スキャン・ツールには、Aqua Security、Anchore、Clair、Prisma Cloudなどがあります。Prisma Cloudは、レジストリおよび CI/CDパイプライン中のコンテナイメージに対して、ディープレイヤーの脆弱性スキャンを提供します。既知の脆弱性、設定ミス、マルウェアを検出し、最初からセキュアなコンテナの構築を支援します。
コンテナネットワークセキュリティツール
デプロイメントされたコンテナは、専有データやコンピュートリソースを盗もうとする絶え間ない試みから保護される必要があります。コンテナ型次世代ファイアウォール、 WebアプリケーションおよびAPIセキュリティ（WAAS）、マイクロセグメンテーションツールは、コンテナに出入りするすべてのトラフィック（南北および東西）を検査および保護し、Kubernetes環境に対する完全な レイヤー7の 可視性と制御を実現します。さらに、 コンテナ化されたファイアウォールは 、急速に変化するコンテナインフラストラクチャのサイズや要求に合わせて動的に拡張され、ビジネス運用のためのセキュリティと帯域幅を保証します。
ネットワークセキュリティツールには、Calico、Flannel、CNIプラグイン（Istio、Ciliumなど）、Kubernetes NetworkPolicy、Prisma Cloudなどがあります。Prisma Cloudは、Kubernetesのようなコンテナオーケストレーションプラットフォームと統合し、ネットワーク脅威検知を提供します。コンテナ間の東西トラフィックを保護し、環境内での不正な横方向の移動を防止します。
政策エンジン
最新のツールにより、 クラウドセキュリティチームは 、特定のマイクロサービスに誰と何がアクセスできるかを基本的に決定するポリシーを定義することができます。組織には、これらのポリシーを定義し、高度に分散したコンテナ・アプリケーション環境全体で一貫して維持できるようにするためのフレームワークが必要です。
人気のポリシーエンジンには、Cilium、OPA Gatekeeper、Neutrino、Kubernetes Network Policy API、Prisma Cloudなどがあります。Prisma Cloudは、ネットワークアクセス制御、リソース制限、イメージ署名など、コンテナデプロイメント全体にセキュリティポリシーを適用します。これにより、一貫したセキュリティ態勢と組織の標準へのコンプライアンスが保証されます。
正しいソリューションの選択
コンテナ環境のセキュリティを確保するソリューションを選択する際には、組織のニーズとリスク領域を考慮してください。高度な脅威検知、脆弱性管理、厳格なポリシー適用が必要ですか？既存のツールやインフラとの統合を評価します。開発パイプライン、オーケストレーション・プラットフォーム、SIEMシステムとのシームレスな統合は、ゲームを変えます。
効果的なコンテナセキュリティは、個々のツールにとどまらないことを忘れないでください。継続的な監視、プロアクティブなスキャン、強力なポリシー、信頼性の高いネットワークセキュリティなど、階層的なアプローチを実装することで、コンテナ化環境の脅威に対する耐性を大幅に強化できます。
コンテナ セキュリティ FAQ
ポリシー エンジンは、 DevSecOps チームがアプリケーション、ネットワーク、データなどのリソースへのアクセスや使用を管理するポリシーを定義、管理、実施できるようにするソフトウェア コンポーネントです。
ポリシーエンジンは、事前に定義されたルールや条件に照らして受信リクエストを評価し、それらのポリシーに基づいて意思決定を行います。コンプライアンスを確保し、セキュリティを強化し、リソースを管理します。コンテナ化された環境では、ポリシー・エンジンは、分散アプリケーションや マイクロサービス全体のアクセス・ポリシーとセキュリティ・ポリシーを一貫して維持する上で重要な役割を果たし、複雑で動的なインフラストラクチャにおけるポリシー施行の管理と自動化を支援します。
MITRE ATT&CK Matrixは、サイバー敵の戦術と技術に関する包括的でグローバルにアクセス可能な知識ベースです。米国政府が後援する研究開発センターを運営する非営利組織MITREによって開発・維持されています。ATT&CKとは、Adversarial Tactics, Techniques, and Common Knowledgeの略。
このマトリックスは、サイバー敵対者がシステム、ネットワーク、アプリケーションを侵害するために使用するさまざまな手法を理解、分類、文書化するためのフレームワークとして機能します。脅威検知、防御、対応、緩和など、サイバーセキュリティ・ライフサイクルのさまざまな段階において、セキュリティチーム、研究者、組織を支援するように設計されています。
MITRE ATT&CK マトリックスは、敵の攻撃ライフサイクルのさまざまな段階を表す戦術と呼ばれる一連のカテゴリーに組織化されています。各戦術には、敵がその段階で目的を達成するために使用する複数のテクニックが含まれています。テクニックはさらにサブテクニックに分けられ、サイバー攻撃で使用される特定の手法やツールについて、より詳細な情報を提供します。
セキュリティ・コンテキストは、コンピューティング・システム内のプロセス、ユーザー、またはオブジェクトのセキュリティ設定に関連する属性またはプロパティのセットです。コンテナ化環境のコンテキストでは、セキュリティ・コンテキストは、コンテナとポッドのセキュリティとアクセス制御の設定（ユーザーとグループのパーミッション、ファイルシステムへのアクセス、特権レベル、その他のセキュリティ関連の設定など）を定義します。
Kubernetesでは、ポッドレベルまたはコンテナレベルでセキュリティコンテキストを設定できます。セキュリティ・コンテキストを構成することで、コンテナ化されたアプリケーションのセキュリティ設定と制限を制御し、適切な権限と安全な方法でアプリケーションを実行できるようにします。
セキュリティ・コンテキスト内で定義できる主な属性には、以下のようなものがあります：
- UID（ユーザーID）とGID（グループID）：これらの設定は、コンテナまたはポッドが実行されるユーザーとグループを決定し、それによってリソースとシステム機能へのアクセスを制御します。
- 特権昇格の制御：この設定は、コンテナ内のプロセスがルート・ユーザーとして実行するなどの追加特権を取得できるかどうかを決定します。特権の昇格を無効にすることで、侵害されたコンテナの潜在的な影響を抑えることができます。
- ファイルシステムへのアクセス：セキュリティ・コンテキストを使用すると、コンテナがファイルシステムにアクセスする方法を定義することができます。
- Linuxの機能：これらの設定は、ネットワークバインディング、システム時間設定、管理タスクなど、コンテナが使用できる特定の機能を制御します。
- SELinux コンテキスト：コンテナやポッドの SELinux コンテキストを定義するためにコンテナ セキュリティ コンテキストを使用することができ、必須のアクセス制御ポリシーを強制し、コンテナをホスト システムからさらに分離します。
Kubernetesのセキュリティコンテキストを適切に設定することで、コンテナ化されたアプリケーションのセキュリティを強化し、最小特権の原則を実施し、システム全体を潜在的なセキュリティリスクから保護することができます。
コードセキュリティとは、ソフトウェアコードが安全に記述され、維持されることを保証するために実装されるプラクティスとプロセスのことです。これには、潜在的な脆弱性の特定と緩和、セキュリティリスクを予防するためのセキュアコーディングのベストプラクティスに従うことが含まれます。コード・セキュリティは、以下のような様々な側面を含んでいます：
- 静的アプリケーションセキュリティテスト（SAST）：ソースコード、バイトコード、バイナリコードを解析し、コードを実行することなく潜在的なセキュリティ脆弱性を特定します。
- 動的アプリケーション・セキュリティ・テスト（DAST）：実行中のアプリケーションをテストして、攻撃をシミュレートし、アプリケーションの動作を分析することによって、セキュリティの脆弱性を特定します。
- ソフトウェア構成分析：既知の脆弱性を特定し、それらが最新であることを確認するために、コードで使用されている依存関係（ライブラリ、フレームワークなど）をスキャンして監視します。
- 安全なコーディングの実践ガイドラインやベストプラクティス（OWASP Top Ten Projectなど）に従い、安全なコードを記述し、脆弱性の導入を回避すること。
ポリシーは、Kubernetes環境内でセキュリティ要件を実施するために使用される特定のセキュリティルールとガイドラインであり、IaCは、コードを使用してインフラリソースを管理し、プロビジョニングするための広範なプラクティスです。この2つを併用することで、Kubernetes環境のセキュリティ、一貫性、自動化を向上させることができます。
IaCを使用すると、インフラストラクチャ定義の一部として、ネットワークポリシー、ファイアウォールルール、アクセス制御などのセキュリティ設定を定義および管理できます。たとえば、Kubernetesのネットワークポリシー、イングレスとイグレスの設定、ロールベースのアクセス制御（RBAC）ポリシーをKubernetesマニフェストに含めることができ、これらはインフラストラクチャとしてコード管理されます。
Terraform、CloudFormation、Kubernetesマニフェストなどのツールにより、インフラリソースとセキュリティ設定を一貫性のある自動化された方法で管理できます。IaC定義にセキュリティ対策を組み込むことで、コンテナとKubernetes環境の全体的なセキュリティを向上させ、ベストプラクティスとコンプライアンス要件の順守を確実にすることができます。
Policy as Code（PaC ）は、インフラストラクチャのポリシー、コンプライアンス、セキュリティルールを、バージョン管理システム内のコードとしてエンコードし、管理するものです。PaCにより、組織はポリシーの実施と監査を自動化し、インフラストラクチャが要件に従って構築され、維持されていることを確認できます。これらのポリシーをポリシー・アズ・コード・プロセスまたはインフラストラクチャ構築の一部として統合することで、組織は、必要な標準とベスト・プラクティスに沿ったツーリングを確保することができます。
アラート・ディスポジションは、アラートがいつ通知されるか、またはいつ異常が発生するかを指定する方法です。設定には保守的、穏健、積極的があります。優先順位は、問題の重大度（低、中、高）に基づいています。
- 保守的な場合、重大度の高い警告が発生します。
- Moderate（中程度）」は、重大度「高」および「中」のアラートを生成します。
- Aggressiveは、重大度高、中、低のアラートを生成します。
セキュア ID ストレージとは、パスワード、暗号化キー、API トークン、その他の機密情報などの機密情報を、高度に保護された暗号化された方法で安全に保存するように設計されたソリューションとメカニズムを指します。秘密金庫とハードウェア・セキュリティ・モジュール（HSM）は、安全な ID ストレージの 2 つの一般的な例です。
シークレットボールトは、機密データを管理、保管、保護するために設計された安全なソフトウェアベースのストレージシステムです。暗号化とアクセス制御の仕組みを採用し、許可されたユーザーやアプリケーションだけが保存された秘密にアクセスできるようにします。秘密保管庫の例としては、HashiCorp Vault、Azure Key Vault、AWS Secrets Managerなどがあります。
秘密の金庫の特徴
- 静止時と転送時の暗号化
- きめ細かなアクセス制御
- 監査ログとモニタリング
- キーのローテーションとバージョニング
- 既存のアイデンティティ・アクセス管理（IAM）システムとの統合
ハードウェア・セキュリティ・モジュール（HSM）は、暗号鍵を保護・管理し、暗号化・復号化処理を実行し、機密性の高い暗号機能を実行するためのセキュアな環境を提供する、耐タンパー性の高い専用の物理デバイスです。HSMは、物理的攻撃と論理的攻撃の両方から保護するように設計されており、保存された鍵の完全性と機密性を保証します。HSMの例としては、SafeNet Luna HSM、nCipher nShield、AWS CloudHSMなどがあります。
HSMの主な特徴
- FIPS 140-2 レベル3以上の認定（暗号モジュールに関する米国政府規格）
- 安全な鍵の生成、保管、管理
- ハードウェアによる乱数生成
- いたずら検出と保護
- 幅広い暗号アルゴリズムをサポート
秘密金庫もHSMも、安全なID保管ソリューションを提供し、不正アクセス、データ漏洩、その他のセキュリティ事故のリスクを低減することを目的としています。これらのどちらを選ぶかは、セキュリティ要件、予算、統合ニーズなどの要因によって異なります。
