コンプライアンスに基づいたアクション（プレビュー）

By 清水 孝郎 - JUNE 22, 2022
Topics: クラウド セキュリティ, コンテナ、Kubernetes、ホストのセキュリティ, コンプライアンス

SHARE:

本文の内容は、docs.sysdig.com上のActionable Compliance (Preview)を元に日本語に翻訳・再構成した内容となっております。(2022年6月23日現在)

はじめに

Sysdigのコンプライアンス機能は進化し続けており、Actionable Complianceは次の成熟段階であると同時に、CSPM/KSPMを初めてサポートします。バックエンドでは、コンプライアンスモジュールは、違反を取得するだけのアプローチではなく、インベントリ内のリソースの永続化に依存するようになりました。このようにリソースの可視性が強化されたことにより、フルコンテキストでの優先順位付けが可能となり、修復と違反の解消が促進されます。

Validatorツールは、様々なコンプライアンス標準から選択されたコントロールをチェックし続け、新しい標準も定期的に追加されます。



アクショナブルコンプライアンスの新機能

  • 定期的なレポートと違反のストリーム
    • 従来のアーキテクチャーは、レポートモデルに基づいて構築されていました。ユーザーは、さまざまなコンプライアンス・ベンチマーク/標準のレポートスケジュールを定義し、これらのレポートは定義された間隔でトリガーされ、照合されます。各レポートは独立して実行され、特定のコンプライアンスフレームワーク/ベンチマークにおける特定のスコープの違反を取得します。
    • 現在、さまざまなエンドポイントがコンプライアンス ポリシーに対して評価され、違反は継続的に報告され、Compliance Views ページでタイルまたは「ビュー」に収集されます。この新しいアプローチは、（関連するあらゆる種類の）リソースをバックエンドにフェッチし、あらゆる種類のあらゆるスコープのポリシーの関連分析を実行するという共通のプロセスに依存しています。
  • このとき、Sysdigは舞台裏でポリシーを提供し、1日に1回チェックを実行する。
  • 違反のリストではなく、リソースそのものをクリックします。
  • IaC統合が有効な場合、開発パイプラインでPRを開くなど、改善策を提供。
  • 様々な用語の変更

重要
Actionable ComplianceとUnified Complianceは並行して実行できる。ベンチマークがEOL（End of Life）に達した場合、データ収集はActionable Complianceのみとなり、Legacy Reportsは作成日から1年間、インターフェース上で利用できるようになる予定です。なお、コンプライアンスバージョン間のデータ移行は予定されていません。

典型的な使用例

コンプライアンス/セキュリティチームメンバー

以下のような目的で使用されます：

  • 事前に定義されたポリシーに対する現在のコンプライアンス状況を確認する
  • 特定の時点（監査）におけるコンプライアンス状況を監査人に示す。
  • 事前に定義されたポリシーに関するレポートを作成し、経営陣に送付したい。
  • コンプライアンスギャップの大きさを把握する

DevOpsチームメンバー

以下のような目的で使用されます：

  • 事前定義されたポリシーのコンプライアンス違反を特定する
  • 違反の重大性に応じて違反を管理する
  • 違反を修正するために何が必要かをソリューションから教えられる
  • 違反を簡単に修正することができる
  • 例外を文書化し、必要な場合はリスクを受容する

検出から修復までの流れ

以下は、ユーザーが Actionable Compliance 画面を使用して、優先順位の高い脆弱性を検出し、分析し、修復するまでの簡単な概要です。

1. 事前に定義されたポリシー/フィルターのそれぞれについて、ハイレベルな姿勢パフォーマンス指標 (PPI) を取得します。

Compliance Views 画面を確認します。


2. ポリシーを選択して結果を取得し、失敗した要件を選択して、その要件を構成するコントロールを確認します。

3. リソースの横に [Start Remediation] リンクが表示され、修復パネルが表示されます。

4. 修復（可能な場合）を開始します。修復フローでは、問題の内容を正確に把握し、Sysdig がその問題専用に作成した推奨パッチを確認し、パッチの適用方法（手動または開発パイプライン）を選択できます。
  • 手動では、パッチコードをコピーして本番環境に適用することができます。
  • CICDパイプラインで修正するには、関連するGitHubソースを選択すると、Actionable Complianceがパッチを統合したプルリクエストを作成します（コードフォーマットのクリーンアップもチェックします）。マージする前にPRのすべての変更点を確認することができます。

残りのページでは、画面とアクションの詳細を説明します。

Actionable ComplianceUIを有効にする

前提条件

Agentのアップグレード

以下のパラメータでエージェントをアップグレードする必要があります (例: Helm)。
-set nodeAnalyzer.kspmAnalyzer.deploy=true 
--set kspmCollector.deploy=true

より詳細な情報は、製品インターフェースの Get Started の Install Agent セクション、または Quick Install ドキュメントも参照してください。

Git プルリクエストと統合された修復（オプション）

PR に統合された修復を利用するためには、IaC Security を有効にする必要があります。

これらの前提条件を満たすと、actionable compliance 用の UI に、あなたの環境のコンテンツが入力されるようになります。

使用方法

Compliance Overview

1. Posture > Actionable Compliannce | Compliance Views を選択します。

2. compliance posture Overviewを確認します。各行またはタイルは、コンプライアンス結果をフィルタリングするビューです。



All Results は常に最初に表示されます。

残りのタイルは、カスタム フィルターが適用されるまでアルファベット順に表示されます。

  • Views と Scope: これは、コンプライアンス結果を整理するためのレンズであり、ポリシーとスコープを組み合わせたものです。デフォルトでは、スコープは Entire Infrastructureです。
  • Passing Score: このポリシー ビューでパスした要件の数をパーセントで表します。高いほど良い傾向です。
  • Requirements Failing: 過去 7 日間の結果の棒グラフで表示されます。数値が小さいほど良い傾向です。要件は、1つ以上のコントロールで構成されているため、要件は小さい数字になります。
  • Controls to Fix: 満点を取るために修正すべきコントロールの数。小さいほど良い。(複数のコントロールで1つの要件が構成されるため、コントロール数は要件数より大きくなる）。
  • Resources Passing: 評価された全リソースのうち、パスした（または受理された）リソースの割合。リ ソ ース は、 結果の中で も っ と も 細か く な る も のです。こ の割合が高 く な る ほ ど、 失敗す る リ ソ ース が少 な く な る と い う こ と にな り ます。
  • Violations by Severity: すべてのコントロールには、深刻度（高／中／低）があります。リソース違反は、深刻度別に分類された、フェイルしたリソースの数です。複数のコントロールに障害が発生している場合、1つのリソースが複数回カウントされることがあります。低ければ低いほどよい傾向です。

3. タイルを選択すると、特定のポリシーの結果を詳しく見ることができます。

結果へのアクセスとフィルタリング

コンプライアンス ビュー]ページから、特定のタイルを選択すると、結果ページが表示されます。



フェイルした要件は、深刻度および重要度によって並べ替えられます。

2. 次の項目でフィルタリングできます。

  • ポリシー（タイプまたはドロップダウンから選択）
  • 要件名と要件番号（入力するか、ドロップダウンから選択します）
  • 深刻度 (高/中/低)
  • フェイルまたはパスの要件


評価と修復

修復ソリューションは、製品で継続的に開発中です。現時点では、1つの違反に対して1つのリソースを対象とした修復が行われます。いくつかのタイプの修復がサポートされています。
  • Static: 違反を修正するためのプレイブックテキストが表示されます。
  • Manually apply patch: （ユーザー入力あり、またはなし）パッチコードが提示され、新しい値が必要な場合は入力フィールドがあり、ユーザーはパッチをダウンロードしてパッチアプリケーションコードをコピー/ペーストします。
  • Set up a Pull Request:（ユーザー入力の有無にかかわらず）パッチコードが表示され、新しい値が必要な場合は入力フィールドが表示され、ユーザーはPRを開く。

コントロール ペインへのドリルダウン

このオプションを選択すると、選択した要件が変更されます。コントロール をクリックすると、右側にある コントロール ペインが表示されます。



ここでは、以下を確認できます：

  • コントロールの説明
  • コントロールの説明 パスおよびフェイルになったすべてのリソースの概要、および
  • 実際のリソースのリスト

リソースとその属性(Kubernetes)

コントロールが適用されるリソースです：

  • Host
    • Status
    • Name
    • Cluster
    • OS
    • OS Image
  • Workload
    • Status
    • Name
    • Type: Deployment, Daemonset, StatefulSet, ReplicaSet, Pod, Job, CronJob
    • Cluster
    • Namespace
    • Labels
  • Identity Object
    • Status
    • Name
    • Type: ServiceAccount, User, System Group\Builtin Group, Role, ClusterRole
    • Cluster
    • Namespace

コントロールペインでのフィルター

コントロールペインには、上位 50 件の結果が表示されます。その制限外のものを見つけるには、フィルターを使用します。

コントロールペインでは、すべてのリソース フィールドに対してフィルター式を作成できます。




修復：ソースの検出とパッチの仕組み

ソースの検出

Sysdigは、プルリクエストを作成するために、ソースと特定のリソースを一致させようとします。一致するものが見つからない場合は、検索フィールドを使用して、関連するGitHubリポジトリ内のファイルを手動で検索します。

パッチとプルリクエスト (PR)

修復フローには静的なものもあれば、Sysdigがパッチを提示するような対話的なものもあります。これは手動で本番環境に適用するか、IaCで設定されている場合はCI/CDパイプラインのプルリクエストを通じて適用することができます。

プルリクエストが開かれると、Sysdigは修正パッチを適用します。PRをマージする前に、PRの推奨されるすべての変更を確認することができます。

修復ペインを確認する

リソースを選択すると、右側にある修復ペインが表示されます。このペインは、検出された内容によって異なります。

修復パスが見つかり、IaC統合が設定され、パイプラインソースが検出された場合、完全な修復ペインが表示されます。



問題の確認

ここでは、修復の影響をチェックし、リソースの属性を確認し、関連する場合は、パッチコードに組み込まれる必要な値を入力します。

必要な値が自動検出された場合、その値は自動挿入され、値の入力フィールドは読み取り専用になります。



パッチの確認

手動で適用できるパッチがある場合、またはIaCファイルを修正するためのPull Requestで使用できるパッチコードがレビューのために表示されます。ほとんどの場合、Continue Remediationセクションでコードをダウンロードすることが推奨されますが、コピー/ペーストすることも可能です。



修復を続ける – 手動

パイプラインのPRをSysdigのIaC Scanningと統合していない場合、または特定のリソースの障害でプルリクエストの作成が必要でない場合、手動で修復を実行することができます。

ボタンを使ってパッチと提供されたコードをダウンロードし、適用してください。



修復を続ける – プルリクエスト

IaC Scanningがシステム上で設定されている場合、SysdigはGitソースで定義されたマニフェストを分析し、そこからリソースをスクレイピングして、評価済みのデプロイ済みリソースと照合します。このプロセスは毎日実行され、リソースを分析し、新しいgitソースが追加された場合は、そのリソースを分析します。

マニフェストとリソースが一致すると、修復 ペインにソースが表示されます。

また、フル URL パスでソースを手動で検索することもできます。



ボタンを使用して、 Create a Pull Request し、リポジトリ（例：Github）で評価します。

Helm/Kustomize用のワークフロー名セレクター

Helm/Kustomizeタイプのソースを選択すると、ワークロード名のセレクターを入力することができます。なぜかというと Helmでは、ほとんどの場合、ワークロード名はリリース名から派生しており、新しいリリースごとに変更されることを意味します。セレクタは、接頭辞/接尾辞（またはより複雑なパターン）でワークロードをマッチングする正規表現です。そのセレクタを使用すれば、リリースに関係なく、同じチャートから生成されたワークロードに対して、改善策を使用することができます。



付録

用語の変更

Previous TermNew Term
Framework, Benchmarkポリシー
ポリシーは、ビジネス/セキュリティ/コンプライアンス/運用要件のグループで、コンプライアンス標準（例：PCI 3.2.1）、ベンチマーク（例：CIS Kubernetes 1.5.1）、またはビジネスポリシー（例：ACME corp policy v1）を表すことが可能です。

技術プレビューリリースでは、様々なポリシーに直接アクセスすることができないことに注意してください。将来的には、Sysdig SecureのPoliciesモジュールで利用できるようになる予定です。
Control要件（またはポリシー要求事項）
要件は、1つのポリシーに存在し、ポリシーの不可欠な部分である。要件は、コンプライアンス・オフィサーや監査役が熟知しており、コンプライアンスが必要であることを認識しているポリシーのセクションを表します。
Family要件グループ
ポリシーに含まれる要求事項のグループ化
Ruleコントロール
コントロールは、問題を特定する方法（チェック）と、チェックによって検出された違反を修復するためのプレイブックを定義します。
Vulnerability Exceptionリスクアクセプタンス
新しいモジュールでは、ユーザーが違反や脆弱性をレビューし、まだ修正されていない場合は、ポリシーをフェイルさせることなく、それを承認する機能が追加されました。

含まれるポリシー

テクニカルプレビューでは、以下のポリシーが裏側で含まれています。

  • CIS Distribution Independent Linux v2.0.0
  • CIS Docker v1.3.1
  • CIS Kubernetes v1.6.0
  • CIS Kubernetes 1.20 v1.0.0
  • CIS Kubernetes 1.23 v1.0.0
  • CIS Kubernetes 1.51
  • CIS EKS v1.0.1
  • CIS GKE v1.1.0
  • CIS AKS v1.1.0
  • Sysdig Kubernetes – Sysdigのセキュリティリサーチとベストプラクティスに基づいたカスタムポリシー

近日公開予定：
  • OpenShift 3.11 v1.2.1
  • CIS OpenShift 4 v1.1.0