- Authors

- Name
- Youngju Kim
- @fjvbn20031
- 들어가며
- 왜 런타임 보안인가
- 탐지와 차단은 다른 문제입니다
- Falco: 룰 기반 런타임 탐지의 표준
- Tetragon: 관찰을 넘어 차단으로
- BPF LSM: 커널 보안 훅에 eBPF를 꽂다
- seccomp, AppArmor와의 관계
- 쿠버네티스 배포와 이벤트 파이프라인
- 룰 운영: 노이즈와의 전쟁
- 우회 가능성과 한계 — 방어자의 관점에서
- 성능 영향 측정
- 도입 로드맵: 관측 → 탐지 → 차단
- 도입 체크리스트
- 마치며
- 참고 자료
들어가며
이미지 스캔을 통과하고, 시크릿도 안전하게 관리하고, 네트워크 폴리시도 걸었습니다. 그럼 끝일까요? 2020년대의 보안 사고들은 "아니오"라고 답합니다. 정상으로 보이던 의존성 패키지가 빌드 파이프라인을 통과한 뒤 런타임에 악성 행위를 시작하는 공급망 공격, 취약한 커널 기능이나 잘못 설정된 권한을 통한 컨테이너 이스케이프, 탈취된 자격 증명으로 들어온 공격자의 내부 이동(lateral movement)까지 — 이 모든 것은 배포 이전의 정적 검사로는 잡을 수 없습니다. 실행 중에 일어나는 일이기 때문입니다.
런타임 보안은 "실행 중인 워크로드가 지금 무엇을 하고 있는가"를 관찰하고, 정책에 어긋나는 행동을 탐지하거나 차단하는 계층입니다. 그리고 이 계층을 구현하는 현재 가장 유력한 기술이 eBPF입니다. 이전 글들에서 다룬 eBPF의 기초와 관측성 기술이, 이번에는 보안으로 향합니다. Falco의 룰 기반 탐지, Tetragon의 커널 레벨 차단, 그리고 그 기반이 되는 BPF LSM까지 차례로 살펴보겠습니다.
왜 런타임 보안인가
전형적인 컨테이너 침해 시나리오를 시간 축으로 보면, 정적 보안과 런타임 보안이 커버하는 구간이 명확히 갈립니다.
공격 체인과 방어 계층
빌드 타임 런타임
+---------------------------+ +------------------------------------+
| 이미지 스캔, SBOM, 서명 | | 여기서부터는 런타임 보안의 영역 |
+---------------------------+ +------------------------------------+
|
취약점 악용 / 악성 의존성 발동 |
v v
[초기 침투] --> [정찰] --> [권한 상승] --> [지속화] --> [목표 행동]
웹셸 실행 ls, id 컨테이너 크론 등록 데이터 유출
리버스 셸 /etc 열람 이스케이프 백도어 암호화폐 채굴
^ ^ ^ ^ ^
| | | | |
exec 이벤트 파일 접근 커널 시스콜 파일 쓰기 네트워크
탐지 가능 탐지 가능 탐지/차단 탐지 가능 탐지 가능
핵심 관찰은 이것입니다. 공격의 모든 단계는 결국 시스템 콜로 나타납니다. 프로세스 실행은 execve, 파일 접근은 openat, 네트워크 연결은 connect입니다. 시스템 콜 경계를 관찰할 수 있다면 공격자의 행동은 숨을 곳이 없고, eBPF는 바로 그 경계를 낮은 오버헤드로 관찰(그리고 커널 5.7 이후로는 차단)할 수 있는 기술입니다.
탐지와 차단은 다른 문제입니다
런타임 보안 도구를 평가할 때 가장 먼저 구분해야 할 축입니다.
| 구분 | 탐지 (Detection) | 차단 (Enforcement) |
|---|---|---|
| 동작 | 이벤트를 관찰하고 알림 생성 | 정책 위반 동작 자체를 거부/중단 |
| 시점 | 행위 발생 후 (비동기) | 행위 발생 시점 (동기) |
| 오탐 비용 | 알림 노이즈, 피로도 | 정상 서비스 중단 — 훨씬 비쌈 |
| 대표 도구 | Falco (기본 모드) | Tetragon (시그킬/오버라이드), BPF LSM, seccomp |
| 도입 난이도 | 낮음 (관찰만 하므로) | 높음 (정책 정확도가 먼저 확보되어야) |
비동기 탐지에는 근본적인 한계가 하나 있습니다. 이벤트가 유저 공간 에이전트에 도달해 룰을 평가하는 사이에 악성 행위는 이미 실행되었을 수 있습니다(TOCTOU 문제). 그래서 성숙한 운영 모델은 "광범위한 탐지 + 좁고 확실한 차단"의 조합입니다. 이 글의 마지막 도입 로드맵에서 다시 다룹니다.
Falco: 룰 기반 런타임 탐지의 표준
Falco는 CNCF 졸업(graduated) 프로젝트로, 시스템 콜 스트림을 룰과 대조해 이상 행위를 탐지합니다.
아키텍처
+--------------------------------------------------------------+
| Falco 아키텍처 |
| |
| 이벤트 소스 |
| ├── 시스템 콜: 최신 eBPF 프로브 (CO-RE, 기본값) |
| │ 구형: 커널 모듈 / 레거시 eBPF |
| └── 플러그인: k8s audit log, 클라우드 로그 등 |
| | |
| v |
| libs (libscap/libsinsp): 이벤트 수집, 컨테이너 메타데이터 보강 |
| | |
| v |
| 룰 엔진: YAML 룰과 조건식 매칭 |
| | |
| v |
| 출력: stdout / gRPC / 파일 --> Falcosidekick |
| ├── Slack / PagerDuty |
| ├── Elasticsearch / Loki |
| └── SIEM / 웹훅 |
+--------------------------------------------------------------+
현대 Falco의 기본 드라이버는 CO-RE 기반 modern eBPF 프로브입니다. 커널 모듈 설치가 필요 없어 노드 OS 업그레이드에 강하고, BTF가 있는 커널(5.8 이상 권장)이면 바로 동작합니다.
룰 문법과 실전 예제
Falco 룰은 condition(조건식), output(알림 메시지), priority(심각도)로 구성되고, macro와 list로 재사용 가능한 조각을 만듭니다.
예제 1 — 컨테이너 안에서의 셸 실행 탐지 (가장 고전적인 룰):
- macro: container
condition: (container.id != host)
- macro: spawned_process
condition: (evt.type in (execve, execveat) and evt.dir = <)
- list: shell_binaries
items: [bash, sh, zsh, dash, ksh]
- rule: Shell Spawned in Container
desc: A shell was spawned inside a container, possible interactive access
condition: >
spawned_process and container
and proc.name in (shell_binaries)
output: >
Shell spawned in container
(user=%user.name container=%container.name image=%container.image.repository
parent=%proc.pname cmdline=%proc.cmdline)
priority: WARNING
tags: [container, shell, mitre_execution]
예제 2 — 민감 파일 접근 탐지:
- list: sensitive_files
items: [/etc/shadow, /etc/sudoers, /root/.ssh/authorized_keys]
- rule: Sensitive File Opened for Reading
desc: Detect attempts to read sensitive files by non-trusted programs
condition: >
evt.type in (open, openat, openat2) and evt.dir = <
and fd.name in (sensitive_files)
and not proc.name in (sshd, systemd, sudo)
output: >
Sensitive file opened (file=%fd.name user=%user.name
proc=%proc.name cmdline=%proc.cmdline container=%container.name)
priority: CRITICAL
tags: [filesystem, secrets, mitre_credential_access]
예제 3 — 예상 밖의 아웃바운드 연결 탐지 (채굴/유출 시그널):
- rule: Unexpected Outbound Connection from Web Container
desc: Web tier should only talk to the app tier and DNS
condition: >
evt.type = connect and evt.dir = <
and container.image.repository = "myorg/web-frontend"
and fd.type = ipv4
and not fd.sip in ("10.0.20.0/24")
and not fd.sport = 53
output: >
Unexpected outbound connection (dest=%fd.rip:%fd.rport
container=%container.name image=%container.image.repository)
priority: NOTICE
tags: [network, mitre_exfiltration]
룰 작성의 실무 요령은 세 가지입니다. 첫째, condition의 부정 조건(not ...)이 예외 목록이 되므로 처음부터 macro/list로 분리해 관리합니다. 둘째, output에 컨테이너/이미지/명령행 필드를 충분히 넣어야 분류(triage)가 빨라집니다. 셋째, priority는 대응 절차와 1:1로 묶어 두어야 알림이 행동으로 이어집니다.
Tetragon: 관찰을 넘어 차단으로
Tetragon은 Cilium 생태계(Isovalent, 현재 Cisco)의 eBPF 기반 런타임 보안 도구로, CNCF 산하 프로젝트입니다. Falco와의 가장 큰 차이는 커널 안에서의 인라인 필터링과 차단입니다. 이벤트를 모두 유저 공간으로 보내 평가하는 대신, 정책을 eBPF 프로그램으로 커널에 내려보내고, 매칭 시 커널 안에서 즉시 시그널(SIGKILL)을 보내거나 반환값을 오버라이드할 수 있습니다.
아키텍처와 TracingPolicy CRD
+---------------------------------------------------------------+
| Tetragon 아키텍처 |
| |
| TracingPolicy CRD (YAML, 클러스터 리소스) |
| | Tetragon 오퍼레이터/에이전트가 해석 |
| v |
| 노드별 Tetragon 에이전트 (데몬셋) |
| | 정책을 eBPF 프로그램으로 컴파일/로드 |
| v |
| 커널: kprobe / tracepoint / LSM 훅에 부착 |
| ├── 매칭 이벤트 --> ringbuf --> 에이전트 --> JSON/gRPC |
| └── matchActions: Sigkill / Override (커널 내 즉시 실행) |
+---------------------------------------------------------------+
쿠버네티스 네이티브라는 점도 중요합니다. 이벤트에 Pod/네임스페이스/컨테이너 메타데이터가 자동으로 붙고, 정책도 CRD이므로 GitOps로 관리됩니다.
예제 1 — 컨테이너 안에서 패키지 매니저 실행을 차단(시그킬):
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: deny-package-managers
spec:
kprobes:
- call: "sys_execve"
syscall: true
args:
- index: 0
type: "string"
selectors:
- matchArgs:
- index: 0
operator: "Prefix"
values:
- "/usr/bin/apt"
- "/usr/bin/apk"
- "/usr/bin/yum"
- "/usr/bin/dnf"
matchActions:
- action: Sigkill
런타임에 패키지를 설치하는 컨테이너는 거의 항상 잘못된 신호(이뮤터블 이미지 원칙 위반 또는 침해)이므로, 비교적 안전하게 차단할 수 있는 대표 사례입니다.
예제 2 — 특정 파일에 대한 쓰기를 LSM 훅에서 거부(반환값 오버라이드):
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: protect-ssh-authorized-keys
spec:
lsmhooks:
- hook: "file_open"
args:
- index: 0
type: "file"
selectors:
- matchArgs:
- index: 0
operator: "Postfix"
values:
- ".ssh/authorized_keys"
matchActions:
- action: Override
argError: -1
LSM 훅 기반 차단은 시그킬보다 한층 깔끔합니다. 행위가 일어난 뒤 프로세스를 죽이는 것이 아니라, 커널이 해당 연산 자체를 권한 오류로 거부하기 때문입니다(BPF LSM이 활성화된 커널 필요).
Falco vs Tetragon 비교
| 항목 | Falco | Tetragon |
|---|---|---|
| 주 모델 | 유저 공간 룰 엔진의 탐지 | 커널 내 필터링 + 탐지/차단 |
| 차단 능력 | 기본은 알림 (대응은 외부 연동) | Sigkill, Override 등 내장 |
| 정책 형식 | 자체 YAML 룰 (macro/list) | 쿠버네티스 CRD (TracingPolicy) |
| 기본 룰셋 | 풍부한 커뮤니티 기본 룰 제공 | 정책을 직접 설계하는 경향 |
| 생태계 | Falcosidekick의 폭넓은 출력 연동 | Cilium/Hubble과 자연스러운 통합 |
| 성숙도 | CNCF 졸업, 오랜 운영 실적 | CNCF 산하, 빠르게 성장 |
실무에서는 양자택일이라기보다 "Falco로 넓게 탐지하고, 확신이 쌓인 좁은 정책만 Tetragon으로 차단"하는 병행 구성도 충분히 합리적입니다.
BPF LSM: 커널 보안 훅에 eBPF를 꽂다
LSM(Linux Security Modules)은 SELinux와 AppArmor가 사용하는 커널의 보안 결정 지점들입니다. 파일 열기, 프로그램 실행, 소켓 생성 같은 연산마다 보안 훅이 호출되고, 훅이 0이 아닌 값을 반환하면 연산이 거부됩니다. 커널 5.7부터는 이 훅에 eBPF 프로그램을 직접 부착할 수 있습니다. 즉, SELinux 정책 언어 대신 C로 보안 정책을 짤 수 있게 된 것입니다.
활성화 여부는 커널 부트 파라미터의 lsm 목록에 bpf가 포함되어 있는지로 확인합니다.
cat /sys/kernel/security/lsm
# 예: lockdown,capability,landlock,yama,apparmor,bpf
미니 예제 — 특정 경로의 파일 실행을 거부하는 BPF LSM 프로그램:
// SPDX-License-Identifier: GPL-2.0
#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
#define EPERM 1
/* bprm_check_security: 프로그램 실행 직전에 호출되는 LSM 훅 */
SEC("lsm/bprm_check_security")
int BPF_PROG(deny_tmp_exec, struct linux_binprm *bprm)
{
const char *path = bprm->filename;
char buf[16];
bpf_probe_read_kernel_str(buf, sizeof(buf), path);
/* /tmp/ 아래의 바이너리 실행을 거부 */
if (buf[0] == '/' && buf[1] == 't' && buf[2] == 'm' &&
buf[3] == 'p' && buf[4] == '/')
return -EPERM;
return 0;
}
char LICENSE[] SEC("license") = "GPL";
음수 에러 코드를 반환하면 커널이 해당 실행을 거부합니다. 실전 정책이라면 경로 비교를 맵 기반 허용/차단 목록으로 만들고 네임스페이스/cgroup 조건을 더하겠지만, "LSM 훅 + eBPF = 프로그래머블 강제"라는 골격은 이 미니 예제 그대로입니다. Tetragon의 lsmhooks 기능과 KRSI(Kernel Runtime Security Instrumentation)라 불렸던 이 메커니즘이 같은 기반입니다.
seccomp, AppArmor와의 관계
eBPF 런타임 보안이 기존 메커니즘을 대체하는 것은 아닙니다. 계층이 다릅니다.
| 계층 | 메커니즘 | 정책 단위 | 강점 | 한계 |
|---|---|---|---|---|
| 시스콜 필터 | seccomp-bpf | 프로세스별 시스콜 허용 목록 | 단순, 커널 표준, 컨테이너 런타임 기본 지원 | 인자 검사 제한적, 동적 변경 어려움 |
| 강제 접근 제어 | AppArmor / SELinux | 경로/레이블 기반 프로파일 | 성숙, 배포판 통합 | 정책 작성 난이도, 컨테이너별 세밀화 번거로움 |
| LSM + eBPF | BPF LSM, Tetragon | 임의 조건의 프로그래머블 정책 | 컨텍스트 풍부(Pod 메타데이터 등), 동적 배포 | 비교적 신생, 커널 요구사항 |
| 탐지 계층 | Falco 등 | 룰 기반 이벤트 매칭 | 도입 쉬움, 가시성 | 기본적으로 사후 탐지 |
권장 구도는 "기본 위생 + 정밀 정책"의 적층입니다. seccomp 기본 프로파일과 AppArmor로 명백히 불필요한 능력을 잘라 공격 표면을 줄이고, 그 위에 eBPF 계층으로 워크로드별 행동 정책과 탐지를 더합니다. 하나의 계층이 뚫려도 다음 계층이 받치는 심층 방어(defense in depth)입니다.
쿠버네티스 배포와 이벤트 파이프라인
런타임 보안 에이전트는 노드마다 있어야 하므로 데몬셋으로 배포합니다. Falco를 Helm으로 배포하는 전형적인 예입니다.
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco \
--namespace falco --create-namespace \
--set driver.kind=modern_ebpf \
--set falcosidekick.enabled=true \
--set falcosidekick.config.slack.webhookurl=https://hooks.slack.com/services/XXX
탐지 이벤트는 반드시 노드 밖으로 보내야 합니다. 공격자가 노드를 장악하면 로컬 로그부터 지우기 때문입니다. 표준적인 수집 파이프라인은 다음과 같습니다.
[노드] Falco/Tetragon (데몬셋)
| JSON 이벤트 (stdout 또는 gRPC)
v
[수집] Falcosidekick / Fluent Bit / Vector
| 필터링, 라우팅, 버퍼링
v
[저장/분석] Elasticsearch / Loki / S3 ---> SIEM (Splunk 등)
| 상관 분석, 보존 정책
v
[대응] Slack, PagerDuty 알림 / SOAR 자동 대응 (Pod 격리 등)
Tetragon의 경우 이벤트가 JSON 로그와 gRPC 스트림으로 제공되어 같은 파이프라인에 자연스럽게 합류합니다.
# Tetragon 이벤트 실시간 확인 (tetra CLI)
kubectl exec -ti -n kube-system ds/tetragon -c tetragon -- \
tetra getevents -o compact
룰 운영: 노이즈와의 전쟁
런타임 보안 도입이 실패하는 가장 흔한 이유는 기술이 아니라 알림 피로입니다. 운영 원칙을 정리합니다.
- 베이스라이닝 먼저. 룰을 켜기 전에 탐지 전용(audit) 모드로 1~2주 돌려서 환경의 "정상"을 수집합니다. 어떤 잡이 셸을 띄우는지, 어떤 에이전트가 /etc를 읽는지 데이터로 파악합니다.
- 예외는 코드로 관리. Falco의 macro/list, Tetragon의 selector를 Git 저장소에서 리뷰와 함께 변경합니다. "일단 무시" 버튼은 예외의 블랙홀이 됩니다.
- 심각도별 대응 채널 분리. CRITICAL은 페이저, WARNING은 일일 다이제스트처럼 채널을 나눠야 진짜 사건이 묻히지 않습니다.
- 알림에 컨텍스트를 충분히. Pod, 이미지, 명령행, 부모 프로세스가 알림 본문에 있으면 분류 시간이 크게 줄어듭니다.
- 룰셋 버전 관리와 회귀 테스트. 룰 변경이 기존 탐지를 깨지 않는지, 시뮬레이션 이벤트(예: 의도적 셸 실행)로 CI에서 검증합니다.
- 지표를 둡니다. 주간 알림 수, 오탐률, 평균 분류 시간을 추적해서 룰 튜닝의 효과를 측정합니다.
우회 가능성과 한계 — 방어자의 관점에서
eBPF 런타임 보안도 만능이 아닙니다. 방어 설계에 반영해야 할 한계를 정리합니다(공격 기법의 재현이 아니라 방어 관점의 논의입니다).
- 비동기 탐지의 시간 창: 유저 공간 룰 평가 모델에서는 탐지 전에 행위가 완료될 수 있습니다. 치명적인 자산은 LSM 기반 동기 차단으로 보호하는 것이 원칙입니다.
- 가시성의 사각: 시스콜 기반 탐지는 시스콜로 나타나지 않는 행위(예: 이미 매핑된 메모리 안에서의 연산)를 보지 못합니다. 메모리 보호, 이미지 서명 같은 다른 계층이 필요한 이유입니다.
- 에이전트 자체가 공격 대상: 루트 권한을 가진 보안 에이전트는 매력적인 표적입니다. 에이전트 프로세스/설정의 변조 탐지(자기 보호 룰)와 최소 권한 구성이 필요합니다.
- 커널 장악 이후는 게임 오버: 공격자가 커널 권한을 얻으면 eBPF 프로그램을 내릴 수 있습니다. bpf() 호출 자체를 감사 대상으로 삼고, 커널 취약점 패치 주기를 짧게 유지하는 것이 전제 조건입니다.
- 이벤트 폭주에 의한 드롭: 이벤트 버퍼가 넘치면 탐지 누락이 생깁니다. 드롭 카운터를 모니터링 대상에 반드시 포함합니다.
요약하면, 런타임 보안은 다른 계층(이미지 서명, 최소 권한, 네트워크 정책, 패치)을 대체하는 것이 아니라 마지막 가시성과 통제의 층을 더하는 것입니다.
성능 영향 측정
도입 전 부하 테스트에서 확인할 항목입니다.
# 1. 시스콜 집약 워크로드의 처리량 비교 (에이전트 on/off)
# 예: 파일 IO 벤치마크
fio --name=randrw --rw=randrw --size=1g --runtime=60 --time_based
# 2. 네트워크 집약 워크로드의 p99 비교
wrk -t8 -c256 -d60s http://service.example/api
# 3. 에이전트 자체의 리소스 사용
kubectl top pod -n falco
kubectl top pod -n kube-system -l app.kubernetes.io/name=tetragon
# 4. 이벤트 드롭 여부 (Falco 내부 메트릭)
# falco_metrics 활성화 후 n_drops 지표 확인
경험적으로 시스콜 빈도가 매우 높은 워크로드(소형 IO를 대량으로 내는 DB, 고QPS 프록시)에서 오버헤드가 가장 잘 드러납니다. 일반 웹 워크로드에서는 한 자릿수 퍼센트 이내가 보통이지만, 절대 수치는 룰 수와 이벤트량에 좌우되므로 자신의 워크로드로 측정하는 것이 유일하게 믿을 수 있는 방법입니다.
도입 로드맵: 관측 → 탐지 → 차단
차단부터 시작하면 반드시 서비스 사고로 되돌아옵니다. 단계를 밟는 것이 빠른 길입니다.
- 1단계 — 관측 (2~4주): 에이전트를 탐지 전용으로 배포하고 이벤트 파이프라인(수집/보존/대시보드)을 완성합니다. 알림은 아직 보내지 않습니다. 환경의 베이스라인을 수집하는 기간입니다.
- 2단계 — 탐지 (4~8주): 기본 룰셋을 활성화하고 환경에 맞게 튜닝합니다. 오탐률과 분류 시간을 지표로 관리하며, 심각도별 대응 절차를 런북으로 만듭니다.
- 3단계 — 선별적 차단: 오탐이 사실상 0임이 증명된 좁은 정책부터 차단으로 전환합니다. 좋은 첫 후보는 "컨테이너 내 패키지 매니저 실행", "런타임의 authorized_keys 변경", "알려진 채굴 풀 도메인 연결"처럼 정상 워크로드에서 일어날 이유가 없는 행위입니다.
- 4단계 — 자동 대응 연동: SOAR/오퍼레이터와 연계해 Pod 격리(네트워크 폴리시 적용), 노드 코든 같은 대응을 자동화합니다. 자동 대응에도 서킷 브레이커(시간당 최대 실행 횟수)를 둡니다.
도입 체크리스트
- 노드 커널이 요구 버전을 충족한다 (BTF 존재, BPF LSM 사용 시 lsm 목록에 bpf 포함)
- 탐지 전용 모드로 베이스라인 수집 기간을 거쳤다
- 이벤트가 노드 외부(SIEM/로그 저장소)로 전송되고 보존 정책이 있다
- 룰/정책이 Git으로 버전 관리되고 변경에 리뷰가 강제된다
- 심각도별 알림 채널과 대응 런북이 연결되어 있다
- 이벤트 드롭 카운터와 에이전트 리소스가 모니터링된다
- 차단 정책은 오탐 0이 검증된 항목으로 한정했다
- 에이전트 자체에 대한 변조 탐지 룰이 있다
- 대표 워크로드에서 성능 영향을 측정하고 기록했다
- seccomp/AppArmor 기본 프로파일 등 하위 계층 방어와 적층 구성이다
마치며
이 시리즈에서 우리는 eBPF라는 하나의 기술이 세 가지 얼굴을 갖는 것을 보았습니다. 기초 편에서는 커널을 안전하게 프로그래밍하는 방법으로, 관측성 편에서는 시스템의 블랙박스를 여는 도구로, 그리고 이번 보안 편에서는 실행 중인 워크로드를 지키는 마지막 방어선으로서입니다. 셋의 공통 기반은 같습니다. 검증된 프로그램이 커널의 훅에서 이벤트를 보고, 맵으로 데이터를 나누는 구조입니다.
런타임 보안의 도입은 도구 선택보다 운영 성숙도의 문제에 가깝습니다. 관측에서 시작해 탐지를 다듬고, 확신이 쌓인 곳에만 차단을 거는 순서를 지키면, eBPF는 과장 없이 현재 가장 강력한 런타임 방어 수단이 되어 줄 것입니다.