本文の内容は、2022年9月14日にAlba Ferriが投稿したブログ(https://sysdig.com/blog/how-to-improve-your-kubernetes-security-posture-kspm/)を元に日本語に翻訳・再構成した内容となっております。
Kubernetes Security Posture ManagementまたはKSPMは、Kubernetesクラスターとその上で動作するワークロードの防御を管理するためのセキュリティ状態とその能力を指します。それらの能力が、Kubernetesに関連するサイバー脅威をどの程度予測、防御、対応できるかを教えてくれるのです。
この定義に聞き覚えがあるとしたら、それはSecurity Postureの一般的な定義であり、Kubernetes セキュリティに焦点を当てたものだからです。
クラウドセキュリティポスチャー vs Kubernetesセキュリティポスチャー
クラウドセキュリティポスチャー管理(CSPM)とは、クラウドリソースのポリシー違反(設定ミスやコンプライアンス違反の特定など)を評価し、優先順位をつけるために設計されたセキュリティツールのことを指します。CSPMは、クラウド環境に影響を及ぼす可能性のあるさまざまな脅威に対して、組織が可能な限り安全であるように支援します。したがって、KSPMはCSPMのサブケースの1つであると考えることができます。
クラウドセキュリティエンジニアにとって、Kubernetesセキュリティポスチャーは、単純にパーセンテージの数字やスコアで表すことができます。スコアが高ければ高いほど、インフラ/運用チームがセキュリティのベストプラクティスに従ってより良く機能していることを意味します。KSPMのスコアが低ければ低いほど、セキュリティガイドラインを満たさない設定上の問題をすべて修正するまで、運命的な数字があなたを追いかけることを意味します。
コンプライアンス監査が近づくと、セキュリティチームと監査人は、KSPMスコアを含む会社の現在のセキュリティ体制に関するすべての関連文書が必要になります。
セキュリティ監査 vs セキュリティポスチャー
今日の企業では、セキュリティ監査が当たり前の手続きになってしまいました。セキュリティ監査について考えるとき、最初に思い浮かぶのはネガティブなことかもしれませんが、セキュリティ監査は恐れるべきものではありません。事実、セキュリティ監査は、組織が機密データを保護し、セキュリティリスクを特定し、従業員がセキュリティ慣行に従うようにするために役立っています。定期的な監査によって、最新の脅威に対応するためにセキュリティポリシーを継続的に再評価したり、新しいポリシーを策定したりすることが求められるとともに、セキュリティ戦略の有効性を追跡することもできます。
セキュリティ監査は、ベストプラクティスや社内のセキュリティガイドラインを遵守するために、企業によって実施されることがあります。機密データを扱う特定の分野に属する企業は、HIPAAやNISTなどの業界規制基準に基づいて、こうしたセキュリティ監査の実施を余儀なくされることがあります。大半の場合、企業は少なくとも自国の規制を遵守しなければならないでしょう。
Center for Internet Security (CIS) は、システムを安全に構成するための構成ベースラインとベストプラクティスを提供する独立組織です。CISガイダンスは、セキュリティチームの間で最も利用されているリファレンスの1つです。あらゆる種類のIT環境に対してCISベンチマークがあり、Kubernetesにも独自のCISベンチマークがあります。CIS Kubernetes Benchmarksを利用して、Kubernetes セキュリティポスチャー を強化できることは言うまでもありません :)
油断は禁物です
クラウド上でもオンプレでも、Kubernetesを使ってワークロードをオーケストレーションしている場合、ある日突然、あの恐ろしい言葉を耳にする可能性があるでしょう:「Kubernetes セキュリティポスチャーを改善する必要がある」。すでに日常業務に追われているインフラ/運用チームにとって、Kubernetesの悪習を修正するための余分な作業は大きな頭痛の種になりかねません。
Kubernetes セキュリティポスチャーのインサイトを提供するために導入したツールやプロセスによっては、KSPMのスコアの改善にある程度は成功することでしょう。では、Kubernetes セキュリティポスチャーのトラッキングを最初から始めていきましょう。
適切なツールやプロセスがあるかどうかの確認ポイントがいくつかあります:
- 私のKSPMスコアは何点か?
- どのコントロールに失敗しているのか?
- どの違反を最初に修正すべきか、どのように判断すればよいか?
- 特定の問題を修正するための最短の方法は何か?
KSPMでKubernetesセキュリティポスチャーを改善する
下記の3つのステップに従うだけでKubernetesセキュリティポスチャーの向上に必要な戦略を立てることができます。ステップ1: 可視性 – 基礎を設定する
これは当たり前のように思えるかもしれませんが、始める前に、全員が同じ情報を共有できていることを確認する必要があります。Kubernetesの管理プロセスに関与するチームには、KSPMスコアの実際の状態を認識してもらいたいですよね?可視性を持つことは、良い仕事をするために非常に重要です。
図1. KSPMのスコアを表示するダッシュボード
Kubernetes セキュリティポスチャーは、ポスチャー管理プロセスのサイクルの結果です。
開始する前に、KSPMの結果をチームで共有し、進捗の追跡を開始します。
ステップ2:優先順位付け – 作業戦略を定義する
すべての悪習慣が同じ評価を受けているわけではありません。中には、より大きなリスクをもたらすものもあります。リソース・タイプに過度の寛容なアクセスがあることと、クラスターにPodを作成する能力を持つServiceAccountsがあることは同じではありません(これは、最終的に特権昇格の可能性を高めます)。
フィルタリングと優先順位付けができることは、戦略を設計する際の重要なポイントです。時間をできるだけ有効に使うために、最もリスクの高いものから順に修復していきましょう。
これは、Kubernetesセキュリティポスチャーの改善戦略を開始するための基礎となり、どのように取り組むかについて考えることができます。
コントロールは不合格か合格のどちらかです。そこに魔法はありません。しかし、なぜこのようなことが起こるのか、その理由は微妙に異なることがあります。
例えば、Container permitting root コントロールを例にとってみましょう。この失敗したコントロールでは、属性値が設定されていないことがわかります。危険な値、許可されていない値を持っているわけではないのです。
図2. Actionable Complianceは、コントロールが失敗した理由を理解するための豊富な
セキュリティコンテキストを提供します。
なぜ失敗したのか、その本当の理由を知ることは、一見、興味がないことに思えますが、実は、このニュアンスに注目することで、チームの働き方のギャップを明らかにすることができるのです:
- デプロイを計画するのに十分な時間がない
- 基盤技術のセキュリティリスクに関する知識不足
- リソースの最適化ができていない
ステップ3:修復 – ソースレベルで
セキュリティポリシーで失敗したコントロールを修復する必要がある場合、自動化を採用しているチームは、修復ワークフローを自社のツールに統合して、この方法を使い続けることを好みます。Sysdigでは、Kubernetesのセキュリティ違反を、Kubernetesリソースを定義するInfrastructure-as-Code(IaC)マニフェストとgitリポジトリに結びつけ、パイプラインの両端を特定することができます。
このアプローチを使用すると、ランタイムの攻撃対象が狭まるだけでなく、それらの変更がIaCマニフェストに反映され、二度と起こらないことを確認することができるのです。
図3. 最適な修復方法を選択する
改善フローでは、問題の内容を正確に理解し、その問題に対してSysdigが特別に作成した推奨パッチを確認し、パッチの適用方法を選択することが可能です。
- 手動 – パッチコードをコピーして、本番環境に適用することができます。
- 自動 – パッチを統合したプルリクエストを作成するだけで、ソースから修正することができます(コードフォーマットのクリーンアップも確認できます)。
図4. PRをマージする前に、推奨されるすべての変更点を確認します。
あなたとあなたのチームが違反を修復する準備ができたら、提案された解決策を再確認することが重要です。なぜなら、それはあなたのランタイム環境に影響を与えることになるからです。
まとめ
Kubernetesは、ガバナンス、コンプライアンス、およびセキュリティ管理が含まれていることを確認するために、熟考された設計が必要です。自動化を利用して、Kubernetesセキュリティポスチャーを高めながら、適切に管理された安全なクラウドを修復・維持することができます。KSPMとソースコードマニフェストでの自動修復を含むアクション可能なコンプライアンスを提供するSysdigのようなツールでは、Kubernetes環境のセキュリティ違反の修復は、監査が近づいたときに慌てて一気に行うものではなく、時々微調整するだけで基本的にコンプライアンス/セキュアなインフラストラクチャーを得ることを目的とした、継続した改善プロセスでなければなりません。
30日間の無料トライアルに登録し、ご自分の目でお確かめください!