ランタイムセキュリティ: リアルタイム監視
La ランタイムセキュリティ DevSecOps パラダイムにおける最後の防御線は保護です 本番環境で実行中のアプリケーション。 SAST、DAST、SCA が脆弱性を発見 導入前に、ランタイム セキュリティがアクティブな脅威や動作を検出して対応します 異常と進行中の攻撃。
この記事では、syscall ベースの脅威検出、eBPF の Falco について説明します。 低オーバーヘッドの監視、異常検出技術、SIEM システムとの統合 完全な可視性を実現します。
何を学ぶか
- ランタイム脅威検出の仕組み
- Falco: Kubernetes でのルール、構成、デプロイメント
- eBPF: 高性能カーネル監視
- 異常検出と動作分析
- 自動化されたインシデント対応
- SIEM (Splunk、ELK、Datadog) との統合
Falco: ランタイム脅威検出
ファルコン およびランタイム セキュリティ用の参照 CNCF プロジェクト。監視する システムコール Linux カーネルの動作をリアルタイムで監視し、動作を検出するとアラートを生成します。 定義された安全規則に違反するもの。 Falco はコンテナ内のシェルスポーンを検出できます。 機密ファイルへのアクセス、不審なネットワーク接続、権限昇格など。
Helm を使用した Kubernetes へのインストール
# Aggiungere il repository Helm di Falco
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
# Installare Falco con il driver eBPF
helm install falco falcosecurity/falco \
--namespace falco --create-namespace \
--set driver.kind=ebpf \
--set falcosidekick.enabled=true \
--set falcosidekick.webui.enabled=true
# Verificare l'installazione
kubectl get pods -n falco
kubectl logs -n falco -l app.kubernetes.io/name=falco
ファルコカスタムルール
Falco には何百もの事前定義されたルールが含まれていますが、それらを環境に適応させ、 カスタム ルールを作成することが不可欠です。
# falco-custom-rules.yaml
customRules:
custom-rules.yaml: |-
# Rileva shell in container di produzione
- rule: Shell in Production Container
desc: Detect shell execution in production namespace
condition: >
spawned_process and container and
proc.name in (bash, sh, zsh, dash) and
k8s.ns.name = "production"
output: >
Shell spawned in production container
(user=%user.name command=%proc.cmdline
container=%container.name namespace=%k8s.ns.name
pod=%k8s.pod.name image=%container.image.repository)
priority: CRITICAL
tags: [container, shell, production]
# Rileva accesso a file di credenziali
- rule: Read Sensitive Credential Files
desc: Detect access to credential files
condition: >
open_read and container and
(fd.name startswith /etc/shadow or
fd.name startswith /root/.ssh or
fd.name startswith /run/secrets)
output: >
Sensitive file read in container
(file=%fd.name user=%user.name
container=%container.name command=%proc.cmdline)
priority: WARNING
tags: [container, filesystem, credentials]
# Rileva connessioni di rete inattese
- rule: Unexpected Outbound Connection
desc: Detect outbound connections from containers that should not have network
condition: >
outbound and container and
k8s.pod.label.network-restricted = "true"
output: >
Unexpected outbound connection from restricted pod
(connection=%fd.name pod=%k8s.pod.name
namespace=%k8s.ns.name image=%container.image.repository)
priority: ERROR
tags: [container, network]
eBPF: 高性能カーネル監視
eBPF (拡張バークレー パケット フィルター) そしてLinuxカーネルテクノロジーは、 カーネルを変更せずに、カーネル内でサンドボックス プログラムを実行できます。 eBPF とテクノロジー Falco、Tetragon、その他のツールが低レベルの監視に使用する基盤となるもの システムコールのオーバーヘッド。
eBPF のオーバーヘッドは通常、1 ～ 2% CPU、作る 高性能環境でも継続的な監視が可能です。
Tetragon: eBPF セキュリティ オブザーバビリティ
四角形 Isovalent (現 Cisco) と、単純な機能を超えた eBPF ベースのツールによる モニタリング:できる 積極的にブロックする カーネルレベルでの不審な動作、 許可されていないプロセスの実行や予期しないネットワーク接続など。
# tetragon-policy.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: block-privilege-escalation
spec:
kprobes:
- call: "__x64_sys_setuid"
syscall: true
args:
- index: 0
type: int
selectors:
- matchArgs:
- index: 0
operator: Equal
values:
- "0" # UID 0 = root
matchNamespaces:
- namespace: production
operator: In
matchActions:
- action: Sigkill # Termina il processo
異常検出
L'異常検出 行動ベースラインを使用して識別します 通常の行動からの逸脱。既知の攻撃パターンを探す代わりに、 障害を示す可能性のある異常な行動。
- ネットワークベースライン: 一般的なネットワーク トラフィックを監視し、予期しない接続を検出します
- プロセスベースライン: 正常なプロセスを記録し、未知のプロセスを警告します
- ファイルアクセスパターン: ファイルアクセスを監視し、異常な読み取り値を検出します
- リソースの使用量: CPU/メモリのスパイクはクリプトマイニングまたは DoS を示している可能性があります
一般的な侵害指標 (IoC)。
| インジケータ | 攻撃の可能性 | 楽器 |
|---|---|---|
| コンテナ内でシェルがスポーン | RCE、バックドア | ファルコン |
| 既知の悪意のある IP への接続 | C2通信 | ネットワーク監視 |
| 突然のCPUスパイク | クリプトマイニング | メトリクス/プロメテウス |
| /etc/shadow の読み取り | 資格情報の盗難 | ホーク、テトラゴン |
| コンテナ内でのCurl/wget処理 | データの引き出し | ファルコン |
自動化されたインシデント対応
セキュリティインシデントが発生した場合、対応速度は非常に重要です。インシデント対応 自動化により、数時間ではなく数秒で対応できるようになります。
# Falcosidekick: risposte automatiche agli alert
# values.yaml per Helm
falcosidekick:
config:
# Notifica Slack per alert WARNING+
slack:
webhookurl: "https://hooks.slack.com/services/xxx"
minimumpriority: "warning"
# Esegui azione Kubernetes per alert CRITICAL
kubernetesCR:
enabled: true
minimumpriority: "critical"
# Pagerduty per on-call
pagerduty:
routingkey: "xxx"
minimumpriority: "critical"
# Azioni automatiche
customActions:
# Isola il pod compromesso (rimuovi label di network policy)
- name: isolate-pod
priority: critical
action: kubernetes
parameters:
namespace: "production"
action: "label"
value: "quarantine=true"
SIEMとの統合
ランタイム セキュリティ アラートは集中システムに流入する必要があります (シェムリアップ) 相関関係、分析、長期保存のために。エコシステム内で最も一般的な SIEM DevSecOps は次のとおりです。
SIEM統合
- エルクスタック (Elasticsearch、Logstash、Kibana): オープンソース、柔軟性、ログ分析に最適
- スプランク: エンタープライズ、強力なクエリ、コンプライアンスに適しています
- Datadog セキュリティ監視: SaaS、クラウドおよびコンテナとのネイティブ統合
- グラファナ + ロキ: 軽量で、Kubernetes 環境に最適
ランタイムセキュリティのベストプラクティス
- 各クラスターに Falco をデプロイする: ランタイム監視はワークロードの 100% をカバーする必要があります
- コンテキストのカスタム ルール: Falco ルールをアプリケーション環境に適応させます
- インシデント対応の自動化: 侵害されたポッドの自動分離
- 行動ベースライン: 異常アラートをトリガーする前にベースラインを確立します
- ログの保存: セキュリティ ログを少なくとも 90 日間 (できれば 1 年間) 保存します。
- 文書化された運用手順書: 調査手順を含む各タイプのアラートの手順
結論
ランタイム セキュリティは、DevSecOps 保護のループを閉じます。ツールをしながら 導入前 (SAST、DAST、SCA、IaC スキャン) による脆弱性の防止、実行時セキュリティ 本番環境でアクティブな脅威を検出し、対応します。 Falco、eBPF、インシデント対応との連携 自動化されているため、組織はリアルタイムで対応できます。
次の記事では、詳しく見ていきます コンプライアンスの枠組み、どのように分析するか DevSecOps コントロールを GDPR、SOC2、ISO27001 要件にマッピングし、 コードとしてのコンプライアンスの遵守。