지난 10년 대부분, 런타임 보안은 에이전트를 의미했습니다. 모든 호스트에 소프트웨어를 설치했습니다 — 커널 모듈, ptrace 기반 shim, 사용자스페이스 데몬이 로그를 파싱합니다 — 나쁜 동작을 감시합니다. 이들은 작동했지만 세금을 부과했습니다: 의미 있는 CPU 및 메모리 오버헤드, 커널 버전 전반의 취약성, 커널 모듈의 경우 자신을 보호하려는 머신을 크래시시킬 수 있는 진정한 위험. 2026년까지 그 모델은 더 나은 모델로 크게 대체되었습니다. Extended Berkeley Packet Filter — eBPF —는 보안 도구가 Linux 커널 자체 내에서 샌드박스된 프로그램을 실행하도록 하며, syscall, 프로세스 실행, 네트워크 활동, 파일 접근을 소스에서 관찰합니다. 오버헤드는 CPU의 분수로 측정되며, 유지할 사용자 정의 커널 모듈이 없습니다.
이 전환은 클라우드 네이티브 환경에서 가장 중요합니다. 워크로드는 일시적이고, 컨테이너는 커널을 공유하며, 호스트당 무거운 에이전트의 이전 모델은 단순히 맞지 않습니다. 세 가지 오픈소스 도구가 eBPF 런타임 보안 공간을 지배하며, 철학이 진정으로 다릅니다: Falco, CNCF 졸업 탐지 표준; Tetragon, Cilium 프로젝트의 관찰성 및 강제 엔진; Tracee, Aqua Security의 탐지 및 포렌식 도구. 이 가이드는 eBPF가 게임을 어떻게 바꾸었는지 설명한 후, 탐지, 강제, 포렌식, 운영 적합성을 가로질러 세 가지를 비교하여 의도적으로 선택할 수 있습니다.
eBPF가 이긴 이유
세 가지 도구를 감상하려면 eBPF가 대안을 이렇게 결정적으로 대체한 이유를 이해하는 것이 도움됩니다. 더 오래된 접근 방식 각각 치명적 인 타협을 가지고 있었습니다. 커널 모듈은 깊은 가시성을 주었지만 전체 커널 권한으로 실행되고 시스템을 당황하게 할 수 있습니다; 보안 에이전트의 버그는 커널 크래시가 되었습니다. 유저스페이스 에이전트는 안전했지만 많은 커널 레벨 활동을 볼 수 없었으며 일부 구성에서 15-30% 오버헤드를 부과했습니다 — 커널과 유저스페이스 사이의 상수 컨텍스트 스위칭 때문입니다. 로그 파싱 접근 방식은 안전하고 저렴했지만 절망적으로 사후이며 회피하기 쉬웠습니다.
eBPF는 바늘을 통과했습니다. 프로그램은 커널 내에서 실행되므로 소스에서 모든 것을 봅니다 — syscall, 프로세스 생성, 네트워크 패킷, 파일 열기 — 하지만 검증된 샌드박스 내에서 실행됩니다: 커널의 verifier는 정적으로 eBPF 프로그램이 시스템을 크래시, 영원히 루프, 또는 접근할 수 있는 메모리를 로드하기 전에 증명합니다. 결과는 커널 레벨 가시성 유저스페이스 레벨 안전, CPU의 1% 미만에서 일관되게 측정되는 오버헤드입니다. 커널당 컴파일할 사용자 정의 모듈 없음, 공황 없음, 무거운 컨텍스트 스위칭 세금 없음. 일시적이고 고밀도 클라우드 네이티브 워크로드의 경우, 그 조합은 정확히 필요한 것이며, eBPF가 2026 런타임 보안 기본값이 되었습니다. 여러 옵션 중 하나가 아니라.
저를 명확하게 해야 할 문제는 eBPF가 합리적으로 현대적인 커널이 필요하다는 것이고, 가장 깊은 기능(특정 강제 후크 같은)은 BTF 및 LSM 지원과 같은 커널 기능에 따라 다릅니다. 실제로는 대부분의 현재 배포판이 자격이 있지만, 매우 오래된 커널은 여전히 제약 조건입니다.
Falco: 탐지 표준
Falco는 세 가지 중 가장 확립된 것입니다. Sysdig에서 생성, 2018년 CNCF에 기부, 이제 졸업 프로젝트, eBPF 기반 런타임 위협 탐지의 사실상 참조 구현입니다. 그 모델은 규칙 기반 경고입니다: Falco는 eBPF를 통해 커널 이벤트 흐름을 수집하고 읽을 수 있는 YAML 기반 구문으로 작성된 규칙 라이브러리에 대해 평가하며, 동작이 규칙과 일치할 때 경고를 내보냅니다. 규칙은 "컨테이너 내에서 쉘이 생성된 경우 경고" 또는 "프로세스가 알려진 민감한 경로에 쓰는 경우 경고" 또는 "예상치 못한 목적지로의 아웃바운드 연결 경고"일 수 있습니다.
Falco의 강점은 성숙도와 에코시스템입니다. 규칙 언어는 접근 가능하며, 기본 규칙셋은 의심스러운 동작에 대한 큰 커뮤니티 지식을 인코딩하며, CNCF 표준이기 때문에 본질적으로 모든 것과 통합됩니다 — Kubernetes, SIEM, 경고 파이프라인, 더 넓은 클라우드 네이티브 도구 조경. 당신의 목표가 "잘 이해되고 널리 지원되는 도구로 의심스러운 런타임 동작을 탐지하고 경고"라면, Falco는 안전한 기본값이며 가장 깊은 문서, 규칙, 운영 경험 풀을 가진 것입니다.
그 의도적 제한은 Falco가 탐지 중심이라는 것입니다. 뭔가 나쁜 일이 일어났다고 말합니다; 커널에서 멈추는 것이 주로 설계되지 않았습니다. 그것은 합리적인 범위입니다 — 많은 팀은 응답 워크플로우보다는 자동화된 커널 킬링보다는 탐지 공급을 원합니다 — 하지만 다른 두 도구가 자신을 구별하는 라인입니다.
Tetragon: 관찰성 및 커널 내 강제
Tetragon은 Cilium 프로젝트(원래 Isovalent, 이제 Cisco의 일부)에서 오며 깊은 관찰성 플러스 강제의 각도에서 런타임 보안에 접근합니다. Falco 같은 eBPF를 사용하여 프로세스 실행, 파일 접근, 네트워크 활동, 권한 변경을 관찰합니다. Kubernetes 인식 이벤트 스트림을 생산합니다. 하지만 정의하는 기능은 커널에서 작용할 수 있다는 것입니다: LSM 후크 강제를 통해, Tetragon은 오픈소스 eBPF 도구 중 네이티브 블록 및 킬 기능을 가진 것입니다. 나중에 반응할 무언가에 대한 경고가 아니라, 커널 내에서 동기적으로, 위반하는 프로세스를 종료하거나 syscall을 오버라이드하기 위해.
이것은 탐지와 응답 사이의 틈이 손상이 일어나는 곳이기 때문에 중요합니다. 프로세스가 데이터를 유출하고 있다는 경고는 유용합니다; 정책이 즉시 허용되지 않은 syscall을 만드는 순간 그 프로세스를 킬하는 정책은 방지입니다. Tetragon의 TracingPolicy 사용자 정의 리소스는 정확히 어떤 커널 동작을 감시할지 선언하고 어떤 작업을 할지 취할지 허용합니다 — 관찰, 또는 신호, 킬링, 또는 오류 반환으로 강제. 강력한 Kubernetes 식별 컨텍스트와 결합(이벤트는 PID가 아닌 pod 및 레이블과 연결), 이것은 깊은 가시성과 커널 레벨 정책을 강제할 수 있는 능력을 원하는 팀에게 특히 강력합니다. Tetragon 치트시트는 정책 모델을 세부 사항으로 다룹니다.
트레이드오프는 개념적 무게입니다. 강제는 강력하고 대응하기 위험합니다 — 부주의한 킬 정책은 합법적인 워크로드를 무너뜨릴 수 있습니다 — TracingPolicy 모델은 Falco의 규칙보다 더 많은 표면 면적을 배웁니다. Tetragon은 그 모델에 투자할 준비가 된 팀을 방지로 보상합니다.
Tracee: 탐지 플러스 포렌식
Tracee, Aqua Security로부터, 세 번째 위치를 점유합니다: eBPF 기반 탐지는 보통과 다른 강한 포렌식 강조로. 다른 것처럼 커널 이벤트를 추적하고 공격 기법을 플래그 하는 행동 서명을 적용합니다 — 안티 디버깅, 동적 코드 로딩, LD_PRELOAD 주입, 권한 상승, 컨테이너 탈출. 어디에서 자신을 구별하는 것은 조사를 위해 캡처할 수 있는 것입니다: Tracee는 실행된 바이너리, 메모리 영역, 및 이벤트당 네트워크 트래픽을 디스크에 캡처할 수 있으며, 인시던트 응답자가 공격이 일어났다는 알림뿐만 아니라 실제 아티팩트를 가지고 도착합니다 — 실제 악성 코드 바이너리, 실제 유출 트래픽 — 분석 준비.
그 포렌식 캡처는 차별화 도구입니다. 탐지가 불을 때, 질문은 즉시 "정확히 무엇을 했는가?"입니다 — Tracee는 증거를 보존하여 그 대답을 할 수 있도록 구축됩니다. 그 서명 시스템(Go 및 Rego)은 확장 가능하며, 그 이벤트 및 범위 필터링은 정확히 관심있는 프로세스 또는 컨테이너에 초점을 맞추기 충분히 세분화됩니다. Falco에서 탐지 겹치고 있는 팀의 경우, 포렌식 캡처 기능은 compelling합니다. Tracee 치트시트는 이벤트 선택자와 캡처 옵션을 정합니다.
Tracee의 위치는 Falco에서 탐지 겹치고 있으면서 포렌식을 연장하고, Tetragon의 강제 초점으로 덜 겹칩니다. 그것은 탐지하고 방지가 아니라 탐지하고 조사입니다.
어떻게 비교
세 가지 도구는 기능 체크리스트보다는 중력 중심으로 가장 잘 이해됩니다. 모든 세 가지는 eBPF 기반을 공유하고, 모든 세 가지는 의심스러운 동작을 탐지합니다. Falco는 탐지 및 경고에 중심을 두고 있으며, 가장 깊은 에코시스템 및 가장 부드러운 학습 곡선 — 응답 파이프라인을 공급하는 성숙하고 잘 지원되는 위협 탐지를 원할 때 표준 선택입니다. Tetragon은 관찰성 플러스 커널 내 강제에 중심을 두고 있으며, 커널 레벨에서 방지가 목표이고 팀이 정책 모델에 투자할 때 유일한 선택입니다. Tracee는 탐지 플러스 포렌식 캡처에 중심을 두고 있으며, 공격을 탐지하는 것만큼 재구성 및 분석이 중요할 때 선택합니다.
상용 조경과의 관계는 또한 명확합니다. Falco는 Sysdig의 상용 CNAPP 플랫폼을 underpins; Tetragon은 Cilium/Isovalent 계보에서 오며 이제 Cisco 내부; Tracee는 Aqua에서 옵니다. 세 경우 모두에서 오픈소스 도구는 진정하게 사용 가능하며, 공급자는 중앙 집중식 대시보드, 더 넓은 CNAPP 범위, 지원을 원하는 팀을 위해 맨 위에 관리 플랫폼을 제공합니다. 아무것도 사지 않고 세 가지 오픈소스 도구 중 하나를 채택할 수 있습니다. 이것이 이 공간이 세 가지 주위에 통합되는 부분입니다.
이러한 도구가 엄격히 상호 배타적이지 않다는 점은 가치가 있습니다. 일부 조직은 성숙한 탐지 규칙셋을 위해 Falco를 강제를 위해 Tetragon과 나란히 실행하여 겹치는 일부를 수용하는 것에 대해 겹칩니다. 더 일반적으로는 팀이 중심의 중력이 주요 요구와 일치하는 것을 선택합니다. 왜냐하면 여러 커널 계측 에이전트 실행이 자체 오버헤드 및 운영 비용을 갖기 때문입니다.
구체적 탐지, 세 가지 방법
차이를 구체적으로 만들려면, 일반적인 공격 시나리오 — 컨테이너 내부에서 생성된 역 쉘 — 를 하나 취하고 각 도구가 이를 처리하는 방법을 봅니다. 동작은 명확합니다: 컨테이너 프로세스는 /bin/sh (또는 유사)를 네트워크 소켓과 표준 스트림을 감싸서 생성합니다. 합법적인 컨테이너화된 워크로드에서 거의 본 적이 없는 패턴이며, 일반적으로 단일 정의된 프로세스를 실행합니다.
Falco로, 당신은 "컨테이너에서 생성된 쉘"과 일치하는 규칙을 첨부된 아웃바운드 연결과 가질 것입니다. 역 쉘이 실행할 때, Falco는 stdout, 파일, SIEM, 또는 경고 파이프라인으로 산출 채널을 통해 경고를 내보냅니다. 응답은 다운스트림 도구가 이 경고로 하는 것입니다: 인간을 페이지, 자동화 트리거, 조사를 위해 로그 합니다. Falco는 그것을 보고 당신에게 말했습니다; 행동은 다른 사람의 일입니다.
Tetragon로, 당신은 동일한 탐지를 할 수 있지만 또한 정책에 강제 작업을 첨부할 수 있습니다. TracingPolicy 감시 그 exec 패턴 carrying a Sigkill 작업을 수행할 수 있으므로, 위반하는 프로세스가 허용되지 않은 호출을 만드는 순간, Tetragon은 커널 내에서 그것을 종료합니다 — 유저스페이스로의 왕복 전에. 공격은 단순히 탐지되지만 방지되며, 동기적으로. 트레이드오프는 정책이 절대로 합법적인 프로세스와 일치하지 않을 것이라는 신뢰입니다. 거짓 일치의 결과는 죽은 워크로드입니다.
Tracee로, 탐지는 행동 서명에서 불을 무고하며 포렌식 기능은 참여합니다: 실행된 바이너리, 프로세스의 메모리, 연결의 네트워크 트래픽을 디스크에 캡처할 수 있습니다. 인시던트 응답자는 경고뿐만 아니라 분석 준비가 된 아티팩트의 보존된 세트에 도달합니다 — 실제 악성 코드 바이너리, 실제 유출 트래픽입니다. 강조는 사후 탐지 조사를 가능한 한 풍부하게 만드는 것입니다.
같은 공격, 세 가지 철학: 공지, 방지, 또는 분석-의뢰. 아무도 틀립니다; 그들은 나쁜 것이 탐지된 즉시 일어나야 하는 것에 대한 다른 답변을 반영하며, 그리고 그것은 당신이 도구를 선택하기 전에 대답해야 할 질문입니다.
선택 및 배포
결정은 당신이 실제로 달성하려고 시도하는 것에서 흐릅니다. 최소 마찰로 런타임 위협 탐지와 가장 넓은 지원을 원한다면, Falco로 시작합니다 — 좋은 이유로 표준이고 운영 및 직원 배치가 가장 쉽습니다. 당신의 우선 순위가 방지 나쁜 동작이 커널이라면 알게 되는 것이 아니며, Kubernetes를 실행합니다. 정책 모델을 배울 시간을 예산하고 프로덕션에서 킬 작업을 활성화하기 전에 강제 신중하게 테스트합니다. Tetragon을 선택하세요. 당신의 일이 인시던트 응답 무거운 것이고 공격의 아티팩트를 캡처하고 분석해야 한다면, Tracee를 포렌식 캡처로 선택합니다.
어떤 것을 선택하든, 일부 배포 현실은 세 가지 모두에 걸쳐 적용됩니다. 당신의 커널이 요구 사항, 특히 강제 기능에 LSM 및 BTF에 달려 있는 것을 확인합니다. 검출 전용 태세에서 시작하고 실제 워크로드에 대한 규칙 또는 서명을 튜닝하고 모든 강제를 고려하기 전에, 런타임 보안 도구를 신뢰하지 않는 가장 빠른 방법은 생산 프로세스를 킬하는 거짓 양수입니다. 이벤트 스트림을 기존 관찰성 및 SIEM으로 연결하는 대신 섬으로 대우합니다. 그리고 낮은 오버헤드가 극한 규모로 오버헤드가 없음이 아님을 기억합니다 — 최고 처리량 노드에서 영향을 검증합니다. eBPF 기반은 그들이 대체한 에이전트보다 세 가지 모두를 극적으로 더 가볍게 만듭니다. 하지만 규율있는 롤아웃은 여전히 중요합니다.
요약
eBPF는 도구에 확인된 서브-1%-오버헤드 안전으로 커널 레벨 가시성을 제공하여 런타임 보안을 다시 작성했습니다. 그것이 그들을 대체한 취약한 커널 모듈 및 무거운 유저스페이스 에이전트를 퇴역시키는 것입니다. 동일 기반의 세 오픈소스 도구는 공간을 정의하며, 각각은 중력 중심을 선택합니다: 성숙한 탐지 및 경고를 위해 Falco, 관찰성 및 커널 내 강제를 위해 Tetragon, 탐지 플러스 포렌식 캡처를 위해 Tracee. 당신의 주요 목표 — 탐지, 방지, 또는 조사 — 에 도구를 일치시키고, 탐지 전용 모드에서 배포하고, 실제 트래픽에 대해 튜닝하고, 마침내 당신은 클라우드 네이티브 시스템이 실제로 실행되는 방식에 맞는 보호를 얻습니다.
참고 & 리소스
도구
배경 및 분석
- eBPF Runtime Security Tools 2026: Falco vs Tetragon vs Tracee
- Container Runtime Security 2026 — NomadX
- Open Source CWPP: Falco, Tracee, Tetragon Overview
관련 1337skills 치트시트