/
ゼロトラストセグメンテーション

コンテナセキュリティ — 新しいフロンティア (Part 2)

コンテナの使用を安全に保つための考慮事項に関する2部構成のブログシリーズ。

新しい次元のコンテナセキュリティ

コンテナがもたらす可能性のあるセキュリティ上の課題について概説しました 最初のブログ投稿で。そのため、コンテナのセキュリティについてどう考えるべきかという疑問が残ります。

私たちは、クラウド、クラスタ、コンテナ、コードという4つのCを考慮した、階層化された多層防御アプローチを使用するというKubernetesのアドバイスから始めて(そしてそれを基に)すべきだと考えています。また、コンテナを危険にさらす脅威をセグメンテーションで封じ込める方法を検討すべきだとも感じています。

そういうわけで、私たちは5番目のCとして封じ込めを提案します。

先ほど、コンテナを保護するだけでなく、コンテナがデータセンターの内部を横方向に移動する際の足掛かりとして悪用されないようにする必要性について説明しました。そこで、コンテインメントの必要性が出てきます。

4Cに関する最初のKubernetesガイダンスを調べてから、コンテインメントについて説明します。

コンテナ

Kubernetes でソフトウェアを実行するには、コンテナ内にある必要があります。そのため、Kubernetes では次のような一般的なセキュリティ上の考慮事項を概説しています。

  • スキャン:コンテナをスキャンして既知の脆弱性がないか調べます。CoreOS の Clair のようなツールが役立つ場合があります。
  • コンテナイメージへの署名:Docker Engine に組み込まれた Docker Content Trust を使用して、コンテナコンテンツの信頼性を維持します。IBM の Portieris プロジェクトは、適切に署名されたイメージに対してコンテンツの信頼性を強化するためのアドミッションコントローラーとして使用できます。
  • ユーザー権限の制御:コンテナーの目的を達成するために必要最小限のオペレーティングシステム権限しか持たないユーザーをコンテナー内に作成するようにします。 

コード

アプリケーションコードレベルを調べてみると、Kubernetes のガイダンスには次のような点が挙げられます。

  • TLS 経由のアクセスのみを許可:ファイアウォールの内側にあるネットワークサービス間も含め、転送中のすべてのものをデフォルトで暗号化するようにします。
  • 通信のポート範囲を制限する:サービス上で絶対に不可欠なポートのみを公開します。
  • 静的コードの分析:コードを解析して、潜在的に危険なコーディング手法がないか調べます。
  • ダイナミック・プロービング攻撃のテスト:使用 OWASP ツール SQL インジェクション、CSRF などの一般的な攻撃を自動化します。

クラウド

各クラウドプロバイダーは、クラウドインフラストラクチャでコンテナワークロードを実行する方法に関する広範な推奨事項を提供しています。提供するセキュリティはクラウドプロバイダーによって異なる場合があり、ユーザーはこれらの推奨事項に細心の注意を払って従わなければなりません。一般的なクラウドプロバイダーへのリンクとセキュリティに関する推奨事項については、を参照してください。 https://kubernetes.io/docs/concepts/security/#the-4c-s-of-cloud-native-security

一般的なガイダンスには以下が含まれます。

  • ネットワークアクセスの制限:ほとんどのクラウドセキュリティプロバイダーが提供しています ネットワークセキュリティ アクセスコントロールリストの使用 — たとえば、AWSでは、ワークロードをグループに分割したり、グループごとにACLを設定したりできるセキュリティグループを用意しています。
  • API アクセスの制限:理想的には、クラスターの管理に必要なサーバーだけが API サーバーにアクセスできる必要があります。
  • Kubernetes クラスタ API へのアクセスを制限する:クラスタには、次のようなクラウドプロバイダーアクセスを提供するのが最適です。 最小権限の原則 管理に必要なリソースについて。AWS の Kops の例は以下にあります。https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles
  • 「etcd」へのアクセスを制限する:このディレクトリには、Kubernetes のクラウド設定ファイルが存在します。これらのファイルへのアクセスや変更には、必ず TLS を使用してください。
  • すべてのドライブ、特に etcd ドライブを暗号化:権限のないユーザーが Kubernetes クラスターに属する重要な設定ファイルやデータストアを閲覧できないようにします。

クラスタ

  • 以下を使用して、Kubernetes API へのアクセスをクラスターに制限します。 RBAC
  • クラスターを制御する API へのすべてのアクセスを認証します。
  • etcd のすべてのデータを含め、クラスターで使用されるすべてのシークレットキーを暗号化します。
  • ポッドのセキュリティ面の制御:ポッドセキュリティオブジェクトは、ポッドがシステムに受け入れられるために実行しなければならない一連の条件を定義します。
  • リソース利用の制御:アプリケーションを実行する Kubernetes ノードは、信頼性とリソースのバランスを取るために互いに依存しています。そのため、これらのノードが使用するリソースの量を制限するポリシーが必要です。
  • アクセス制御リストを使用して、ポッドへのすべてのネットワークポリシーを制御します。これは南北のセキュリティポリシーです。データセンター内のポリシーについては、以下の「コンテインメント」を参照してください。
  • すべてのイングレスアクセスを TLS 経由に制限します。

コンテインメント

これで、コンテナから発生する侵害の拡大を防ぐ封じ込めの5番目のCにたどり着きます。封じ込めが最も効果的であるためには、いくつかの点を考慮する必要があります。

  • 新しく作成されたコンテナをリアルタイムで検出します。
  • 新しいコンテナワークロードの自動セグメンテーションが可能になるため、セキュリティは「誕生時」に自動的に適用されます。
  • コンテナの可視性を他のコンピューティング環境と一緒に一元化することで、コンテナ化されたワークロードとベアメタル、仮想マシン、プライベートクラウドとパブリッククラウドの全体を一元的に把握できます。見えないものは保護できないからです。
  • コンテナ全体やその他のすべてに統一されたポリシーを適用することで、環境に関係なく、統一されたポリシーでセグメント化できます。これにより、VM、ベアメタルサーバー、クラウド、コンテナのセグメンテーションに複数のポイントツールを使用する必要がなくなります。

コンテナに対する幅広い多層防御アプローチにより、組織はコンテナのセキュリティの実行可能性が保証され、さらに自信を持ってコンテナを導入できます。

関連トピック

アイテムが見つかりません。

関連記事

ガートナーセキュリティ&リスク管理サミットでイルミオに会いましょう
ゼロトラストセグメンテーション

ガートナーセキュリティ&リスク管理サミットでイルミオに会いましょう

9月26~28日にロンドンで開催される今年のガートナー・セキュリティ&リスク・マネジメント・サミットで、イルミオ・ゼロトラスト・セグメンテーション(ZTS)の専門家に会いましょう。

ジョン・キンダーヴォーグがゼロトラストのオリジンストーリーを語る
ゼロトラストセグメンテーション

ジョン・キンダーヴォーグがゼロトラストのオリジンストーリーを語る

John Kindervagがゼロトラストを始めた経緯、ゼロトラストのベストプラクティスに関する初期の研究、ゼロトラストへの取り組みを進める組織へのアドバイスをご覧ください。

ファイアウォール:ネットワークセキュリティの簡単な歴史
ゼロトラストセグメンテーション

ファイアウォール:ネットワークセキュリティの簡単な歴史

私たちが置かれているセキュリティ環境を本当に理解するには、これまで起こっていたことを踏まえて考える必要があります。ネットワークセキュリティの重要な部分は、ネットワークの始まり以来、ファイアウォールでした。そこで、ファイアウォールの簡単な歴史をご紹介します。

アイテムが見つかりません。

違反を想定.
影響を最小限に抑えます。
レジリエンスを高めます。

ゼロトラストセグメンテーションについて詳しく知る準備はできていますか?