FargateではRuntime Securityは本当にできないのか？
― eBPFが使えない世界のRuntime防御
Serverless Container Runtime Securityの実装
はじめに ― よくある誤解
「FargateではRuntime Securityはできない」
これはよく聞く話です。理由は明確です。
Fargate
↓ Host access 不可
↓ eBPF 不可
↓ Falco 不可
しかし実際には、完全に不可能ではありません。
Fargateでは実装レイヤーが変わります。
Kernel Runtime → Userspace Runtime
(eBPF) (ptrace)
この記事では、「なぜeBPFが使えないのか」から始めて、
「それでもどうやってRuntime Securityを実現するか」を構造的に解説します。
1. Runtime Securityの基本 ― なぜsyscallを見るのか
従来のRuntime Securityの構造：
Container Process
↓
Syscall
↓
Kernel hook (eBPF / kprobe)
↓
Runtime Detection
代表的なツール：
| ツール | ドライバ方式 |
|---|---|
| Falco | eBPF / kernel module |
| Sysdig | eBPF / kernel module |
| Tetragon | eBPF |
| Tracee | eBPF |
なぜsyscallを見るのか？
syscall = OSの真実
プロセスがどんなに偽装しようとも、
カーネルへの要求（syscall）は偽れません。
だからRuntime SecurityはKernelレイヤーを見ます。
2. なぜFargateではeBPFが使えないのか
Fargateのアーキテクチャを見ると理由が明確になります。
┌─────────────────────────────┐
│ Customer │
│ ┌───────────────────────┐ │
│ │ Container (Task) │ │
│ └───────────────────────┘ │
└─────────────────────────────┘
┌─────────────────────────────┐
│ AWS (管理外) │
│ ┌───────────────────────┐ │
│ │ Kernel / Host OS │ │
│ └───────────────────────┘ │
└─────────────────────────────┘
ユーザーはKernelにアクセスできません。
その結果、以下がすべて使用不可になります：
| 技術 | 理由 |
|---|---|
| eBPF | Kernelへのプログラム挿入が不可 |
| kernel module | Kernel空間への書き込み不可 |
| kprobe | Kernel関数へのフックが不可 |
これがFargateにおけるRuntime Securityの制約です。
3. それでもRuntime Securityは可能 ― ptraceという答え
Fargateで使われるアプローチが ptrace runtime です。
Process
↓
ptrace attach（プロセスへのアタッチ）
↓
syscall tracing（ユーザー空間から観測）
↓
behavior detection
これは strace コマンドと同じ仕組みです。
Kernelを直接フックするのではなく、
ユーザー空間からプロセスをトレースすることでsyscallを観測します。
カーネルへのアクセスがなくても、
プロセスのsyscallは見られる。
4. Falco for Fargate ― ptraceドライバの活用
Falcoは通常、以下のドライバで動作します：
通常環境：
Falco → kernel module
or
Falco → eBPF
Fargateでは：
Fargate環境：
Falco → ptrace driver
構造は以下のようになります：
Container
↓
ptrace（ユーザー空間からsyscall観測）
↓
syscall event
↓
Falco rule engine
↓
Alert / Block
これにより、Fargate上でも以下の攻撃を検知できます：
- Reverse shell（外部への接続試行）
- Crypto miner（不審なネットワーク・CPU使用）
- Privilege escalation（権限昇格の試み）
- ファイルシステムへの不審なアクセス
5. Amazon GuardDuty Runtime Monitoring
AWSはプラットフォームレベルで別のアプローチを提供しています。
Fargate telemetry（AWS内部）
↓
AWS internal detection engine
↓
GuardDuty Finding
ユーザーから見ると ブラックボックス です。
GuardDuty vs Falco の比較
| 項目 | GuardDuty | Falco（ptrace） |
|---|---|---|
| 検知方法 | AWS内部テレメトリ | syscall（userspace） |
| 可視性 | 低（結果のみ） | 高（rawイベント参照可） |
| カスタムルール | 不可 | 可能 |
| 導入コスト | 低（有効化するだけ） | 中（エージェント導入必要） |
| 検知の透明性 | 低 | 高 |
どちらか一方ではなく、層を重ねて使うのが現実的な設計です。
6. Runtime Securityの3つの実装方式
┌──────────────────────────────────────────────────────┐
│ Runtime Security Evolution │
│ │
│ 1. Kernel Runtime (eBPF / kernel module) │
│ 対象：EC2 / EKS on EC2 │
│ 精度：最高 / オーバーヘッド：最小 │
│ │
│ ↓ Kernelアクセスが失われる │
│ │
│ 2. Userspace Runtime (ptrace) │
│ 対象：Fargate / ECS / EKS on Fargate │
│ 精度：高 / オーバーヘッド：中 │
│ │
│ ↓ プロセスアタッチも難しい場合 │
│ │
│ 3. Platform Runtime (Cloud telemetry) │
│ 対象：Serverless全般 │
│ 精度：中（ブラックボックス）/ 導入：最小 │
└──────────────────────────────────────────────────────┘
環境によって使える方式が変わります。
重要なのは「方式が変わるだけで、Runtime Securityは諦めない」ことです。
7. Serverless Container Securityの本質
Serverless Container環境でのセキュリティは、2つのレイヤーの組み合わせです。
Serverless Container Security
↓
┌─────────────────┐ ┌─────────────────────┐
│ Build Security │ + │ Runtime Security │
│ │ │ │
│ Image Scan │ │ Behavior Detection │
│ SCA │ │ Anomaly Detection │
│ Secret検出 │ │ syscall監視 │
└─────────────────┘ └─────────────────────┘
| フェーズ | 手法 | 目的 |
|---|---|---|
| Build | Image Scan / SCA | 既知の脆弱性・設定ミスを防ぐ |
| Runtime | ptrace / GuardDuty | 実行時の異常挙動を検知する |
Buildだけでは不十分です。
既知の脆弱性は防げても、未知の攻撃は防げません。
Runtimeが必要な理由はここにあります。
まとめ
| 問い | 答え |
|---|---|
| FargateでeBPFは使えるか？ | 使えない（Kernel access不可） |
| FargateでRuntime Securityはできるか？ | できる（ptraceで代替） |
| GuardDutyで十分か？ | 用途による（可視性・カスタマイズ性が必要なら不十分） |
FargateはRuntime Securityを消したのではない。
Runtime Securityの実装方法を変えただけです。
制約を理由に諦めるのではなく、制約の中で最善を尽くす。
それがServerless Container Securityの設計思想です。
参考