Google Cloudとコンテナの継続的なセキュリティ
本文の内容は、docs.sysdig.com上のThreat Detection Policies and Rules を元に日本語に翻訳・再構成した内容となっております。(2022年6月24日現在)
このページでは、Sysdigの脅威検知ポリシーとそれを構成するルールについて紹介し、お客様の環境でセキュリティポリシーを作成、編集、適用するために必要な概念的背景を提供します。
Sysdig Secureのポリシーは、企業が環境内で検出したい活動に関するルール、ポリシールールに違反した場合に実行すべきアクション、そして潜在的には送信すべき通知に関するルールの組み合わせで構成されています。多くのポリシーがすぐに使える状態で提供され、そのまま使用したり、複製したり、必要に応じて編集したりすることができます。また、定義済みのルールやカスタムルールを使用して、ゼロからポリシーを作成することもできます。
Policies > Runtime Policies を選択すると、Sysdig Secureにロードしたデフォルトポリシーと、作成したカスタムポリシーが表示されます。
この概要から、以下のことが可能です。
このパネルでは、次のことも可能です：
+Add Policy ボタンを使用して新しいポリシーを作成する。定期的に種類が追加されます。
Falcoエンジンを搭載し、柔軟な条件式を使用してシステムコールをフィルタリングする方法を提供します。詳細については、Sysdig Secure内でFalcoを使用するを参照してください。
コンテナ、システムコール、プロセスなどに対して、単純なマッチングまたは非マッチングを使用するポリシーです。詳細については、Understanding List Matching Rulesをご参照ください。
デフォルトのドリフト検出と防止を提供する単一のルールを持つポリシー。
こちらも参照してください。DriftControlとDrift Policy Typeの追加パラメータを理解する。
機械学習を活用して、高度な検出機能を提供するポリシー。
こちらもご覧ください。機械学習について、および機械学習ポリシータイプの追加パラメーターを参照してください。
Falcoエンジンを搭載し、柔軟な条件式を使用してKuernetes監査ログをフィルタリングする方法を提供します。Kubernetes Audit Loggingも参照。
Falco互換の条件式を使用してAWS CloudTrailイベントをフィルタリングする方法を提供します。AWS CloudTrailイベントを送信するためには、Sysdig Secure for cloudがインストールされている必要があります。
Falco と互換性のある条件式を使用して GCP 監査ログをフィルタリングする方法を提供します。
Falco と互換性のある条件式を使用して Azure プラットフォームログをフィルタリングする 方法を提供する。
利用可能なスコープとアクションは、タイプによって異なります：
| スコープオプション | アクションオプション | |
|---|---|---|
| ランタイム | ||
| ワークロード | CustomHosts onlyContainer only |
Stop/ pause/ killキャプチャー 通知チャンネル |
| リストマッチング | CustomerHosts onlyContainer only |
Stop/ pause/ killキャプチャー 通知チャンネル |
| ドリフト | Custom only | 検知 通知チャンネル |
| ログ検知 | ||
| Kubernetes | kubernetes.cluster.namekubernetes.namespace.name |
通知チャンネル |
| AWS Cloud | aws.accountIdaws.region |
通知チャンネル |
| GCP | gcp.projectidgcp.location |
通知チャンネル |
| Azure | azure.subscriptionIdazure.tenantIdazure.locationazure.resourceGroup |
通知チャンネル |
ドリフトとは、バージョン管理システムにチェックされた期待される状態とは異なる環境での変化、例えば、本番環境に導入、更新、アップグレードされたソフトウェアのことを指します。
Sysdigのドリフトコントロール機能は、コンテナ起動前にはコンテナイメージに含まれていなかった新しい実行可能ファイルがコンテナ内でダウンロード、更新、変更されたときにシステムを監視するなど、さまざまな検知技術を使用します。
デフォルトのエージェント構成では、ドリフトポリシー/ルールは、このような検知されたプロセスを開始後に停止します。
特定のタスクの開始を確実にブロックする必要がある場合は、エージェント設定ファイルで以下の設定を有効にします。
drift_killer:
enabled: true
このオプションは ptraceを使用するため、デフォルトのモードよりもリソースを消費することに注意してください。
機械学習は、インフラストラクチャーから低レベルのアクティビティを収集し、時間的に集約してアルゴリズムを適用します。
機械学習ポリシーでは、使用する検知とその閾値を設定できます。
検知アルゴリズムは、これらのアクティビティが検知対象（マイナーなど）に関連する確率を推定することで機能します。
Sysdigの機械学習による検出は、単なるプログラム名や実行ファイルのチェックサムの一致に依存するものではありません。その代わり、実際の実行時の動作に基づいています。
ルールは、セキュリティポリシーを構成するために使用する基本的な構成要素です。ルールは、企業がその環境において検出したいと考えるあらゆるタイプの活動です。
ルールは、2つの形式で表現することができます。
ルールライブラリには、ポリシーで参照できるすべての作成されたルールが含まれています。Sysdigの脅威リサーチチーム、Falcoのオープンソースコミュニティのルール、CISやMITRE ATT&CKなどの国際的なセキュリティベンチマークによって開発されたコンテナ固有のルール（および定義済みのポリシー）を含む包括的なランタイムセキュリティライブラリをすぐに利用することが可能です。
ルールライブラリのインターフェースでは、
Published By:
Last Updated
を一目で確認でき、トレーサビリティと監査を強化します。
デフォルトのルールは、UI上ではPublished By: Sysdigとして表示されます。
ユーザー定義のルールは、Published By: Secure UIとして表示されます。
ルールはタグによって分類されるため、機能、セキュリティ基準、ターゲットなど、組織にとって意味のあるスキーマでルールをグループ化できます。
さまざまなタグがあらかじめ定義されており、ポリシーを作成または編集する際に、ルールを論理的なグループに整理するのに役立ちます。
上部にある検索ボックスを使用して、ルールの名前またはタグで検索します。
Falcoは、オープンソースの侵入検知およびアクティビティモニタリングのプロジェクトです。Sysdigによって設計されたこのプロジェクトは、Cloud Native Computing Foundationに寄贈され、コミュニティによって継続的に開発・強化されています。Sysdig Secureは、Policy and Complianceモジュールの一部としてFalco Rules Engineを組み込んでいます。
Sysdig Secureのコンテキスト内で、ほとんどのユーザーは、主に自分の環境のためのポリシーに展開されたルールを書いたりカスタマイズしたりすることでFalcoと接することになります。
Falcoのルールは、アラートが生成されるべき条件と、アラートとともに送信されるべき出力文字列から構成されます。
舞台裏では、 falco_rules.yaml ファイルは、Falco マクロとリストを含む、環境内のすべての Falco ルールのための生コードを含んでいます。
すべてのFalcoルールは、以下の基本パラメータを含んでいます。
ルールライブラリからルールを選択すると、その基本的な構造を見たり編集したりすることができます。新しいFalcoルールを作成し、それをライブラリに追加する際にも、同じ構造が適用されます。
既存のルール
ルールの作成
注記
k8s_auditをソースとするFalcoルールは、条件を満たすためにKubernetes Auditのロギングを有効にする必要があります。
ルールライブラリ内の多くのFalcoルールは、その条件コードにFalcoマクロを含んでいます。
あなたは、Falcoマクロのリストを参照したり、マクロの基礎となるコードを調べたり、あなた自身のマクロを作成したりすることができます。デフォルトのFalcoルールセットは、ルールを書き始めるのを容易にするいくつかのマクロを定義しています。これらのマクロは、多くの一般的なシナリオのためのショートカットを提供し、任意のユーザ定義のルールセットで使用することができます。
デフォルトの Falco リストは、環境のためのカスタムルールを書く際のユーザーエクスペリエンスを向上させるために追加されます。
例えば、 allow.inbound.source.domains というリストはカスタマイズ可能で、任意のルール内で簡単に参照することができます。
Sysdig Secure SaaSは、常に最新のFalcoルールセットを使用しています。
Sysdig Secure On-Premのアカウントは、定期的にFalcoルールセットをアップグレードする必要があります。
ルールインストーラ
Rules InstallerのDocker pullコマンドと手順については、Falco Rules On-Premisesのインストールを参照してください。
リストマッチングルール（以前は「高速」ルールとして知られていた）は、アイテムのリストに対するマッチング（matchItems=trueのとき）、またはアイテムのリスト以外のすべてのマッチング（matchItems=falseのとき）に使用されます。このルールは、プロセス、ネットワーク接続、およびその他の操作の簡単な検出を提供します。例えば
または
Falcoルールとは異なり、リストマッチングルールタイプでは、"y IPアドレスからのxポートでの接続が検出された場合... "などの複雑なルールの組み合わせは許可されません。
5つのリストマッチングルールタイプを以下に説明します。
これらのルールは、特定のイメージ名が環境内で実行されているかどうかを通知するために使用されます。ルールは、コンテナが起動されたときに評価されます。リスト内の項目はイメージパターン名で、構文は <host.name>:<port>/<name>/<name2>:<tag>@<digest> となっています。
<name2> のみが必須で、それ以外はオプションであり、名前から推測されます。
こちらもご覧ください。マッチングの仕組み：コンテナの例とリストマッチングルールの作成も参照してください。コンテナタイプの例 も参照してください。
これらのルールは、特定のディレクトリ/ファイルへの書き込みアクティビティがあるかどうかを通知するために使用されます。このルールは、ファイルが開かれたときに評価されます。リストの項目は、パスの接頭辞です。
たとえば /one/two/three は、パス /one/two/three, /one/two/three/four にマッチしますが、/one/two/three-fourにはマッチしないでしょう。
これらのルールは、以下の目的で使用されます。
現在のSysdig UIでは、ネットワーク・ルールによる接続の「許可」または「拒否」について説明していますが、これにはいくつかの混乱が生じる可能性があることに注意してください。
インバウンドとアウトバウンドの両方の接続について。
Allow は何もしないことを意味します。Deny とは、インバウンドまたはアウトバウンドの接続の試みにマッチすることを意味します。
それでも、このルールをポリシーに追加し、接続が発生したコンテナを停止/一時停止/停止することで、接続の試行に対応するアクションを追加する必要があります。こちらもご参照ください：ポリシーアクションのトリガーを理解する。
これらのルールは、SSH などの特定のプロセスが、環境の特定の領域で実行されているかどうかを検出するために使用されます。
このルールは、プロセスが起動されたときに評価されます。リストの項目はプロセス名であり、Linux カーネルによって強制される 16 文字の制限に従います。(プロセス名の長さに関する情報も参照してください)。
注記
syscall ルールタイプは、ユーザーが作成したポリシーに展開されることはほとんどなく、以下の定義は情報提供のみを目的としています。
これらのルールは、（内部的に）以下の目的で使用されます。
このルールは、インバウンド (accept, recvfrom, recvmsg, listen) および/またはアウトバウンド (connect, sendto, sendmsg) 接続を作成するシステムコールで評価されます。リスト内の項目はポート番号です。
コンテナイメージは、以下の要素で構成されます。<registry host>:<registry port>/<image>:<tag>@<digest>.
ただし、<image>は<project>/<image>や<project>/<subproject>/<image>のように複数のパスで構成されている場合があります。
完全な例: docker.io:1234/sysdig/agent:1.0@sha256:da39a3ee5e6b4b0d3255bfef95601890afd80709
ここで
<registry host> = docker.io
<registry port> = 1234
<image> = sysdig/agent
<tag> = 1.0
<digest> = sha256:da39a3ee5e6b4b0d3255bfef95601890afd80709
コンテナリストの各項目は、まず、以下のルールで上記の構成要素に分解される。
項目が構成要素に分解されると、それらは画像名の候補に対して前方一致とみなされます。
例を挙げます：docker.io:1234/sysdig/agent:1.0 @sha256:da39a3ee5e6b4b0d3255bfef95601890afd80709: すべてのコンポーネントに正確に一致しなければなりません。docker.io:1234/sysdig/agent:1.0: レジストリのホスト、ポート、イメージ、およびタグと、任意のダイジェストで一致する必要があります。docker.io:1234/sysdig/agent: レジストリのホスト、ポート、およびイメージに、任意のタグまたはダイジェストを付けて一致させる必要があります。sysdig/agent: イメージと、任意のタグまたはダイジェストで一致する必要があります。イメージはマッチ式にない追加情報を提供するため、イメージ docker.io:1234/sysdig/agent にはマッチしないでしょう。docker.io:1234/: レジストリのホストとポートにあるすべてのイメージにマッチします。docker.io/: そのレジストリホストに対するすべてのイメージにマッチします。