backend.ai

엔터프라이즈 급 서버 클러스터를 관리한다면, 보안 감사는 규정 준수(컴플라이언스) 측면에서 굉장히 중요하게 여겨집니다. 침해 사고가 일어났을 때, 어느 IP로 시스템에 접속했는지, 누가 쉘 권한 상승을 요청했는지와 같은 민감한 행위가 기록으로 남아 있어야 무슨 일이 벌어졌는지 그 기원을 추적해볼 수 있기 때문입니다. 문제가 있다면, 이런 시스템 추적을 위해 모든 것을 로깅하기 시작하면 시스템에 가해지는 부담이 상당해진다는 것입니다. GPU 학습 클러스터를 예로 들어보죠. 모델 학습 작업을 진행하는 동안에는 초당 수만에서 수십만 건의 syscall 호출이 쏟아지는데, 이걸 일일이 추적하겠다고 사이드카 프로세스를 끼워 넣는 순간 GPU 간 통신 등의 지연이 늘어나고, 이는 지연시간에 민감한 GPU 학습의 특성 상 전체적인 학습 효율 저하로 이어지게 됩니다. 그렇다고 auditd 같은 전통적인 감사 도구를 그대로 사용하면 초당 수만 건의 이벤트 앞에서 감사 버퍼가 넘쳐 이벤트가 유실되거나 동기 쓰기 부하로 성능이 떨어지는 등의 문제가 발생합니다.

그래서 최근 몇 년 사이 인프라 운영자들에게서 자주 오르내리는 것이 eBPF라는 개념입니다. extended Berkeley Packet Filter의 약자인 eBPF는 커널 안쪽에 작은 이벤트 감지 프로그램을 심어둔 후 유효한 (의미 있는) 이벤트만 골라내는 것을 골자로 하는데요, 이번 글에서는 eBPF가 무엇인지, 어떻게 빠르고 안전한지, 그리고 어떤 방식으로 Linux 시스템의 보안 감사에 적용할 수 있는지를 살펴보겠습니다.

커널 안의 작은 가상 머신, eBPF와 그 역사

eBPF(extended Berkeley Packet Filter)는 Linux 커널 안에서 샌드박스 된 프로그램을 실행시킬 수 있는 기술입니다. 사실 이름을 보면 이 기술이 서론에서 언급한 감사 작업과 어떤 관계가 있는 지에 대해 의아할 수 있죠. eBPF의 역사를 함께 살펴보면 이 기술이 어떻게 발전되어 왔는지와 함께 이름에 대한 유래도 파악할 수 있습니다.

eBPF를 이루는 기술의 뿌리는 꽤 오래 전으로 거슬러 올라갑니다. eBPF의 기원은 1993년 USENIX Winter Conference에서 로렌스 버클리 국립연구소의 Steven McCanne와 Van Jacobson이 발표한 BSD Packet Filter 논문입니다. 해당 논문의 골자는 '패킷을 사용자 공간으로 다 옮긴 뒤 거르는 건 너무 비싸니, 커널 안에서 필터를 돌려 필요한 것만 위로 올리자'는 내용이었습니다. 그러나 인프라 기술의 발전과 함께 네트워크 패킷 필터만을 염두에 두고 만들었던 초기 스펙이 한계에 부딪히며 BPF의 한계가 수면 위로 드러났습니다. CPU 병목이나 I/O 패턴과 같은 것들을 들여다 보기 위해서는 다양한 모듈 추가가 필요했고, 서비스와 Pod의 개수가 늘어나면서 복잡도가 늘어난 시스템에서는 네트워킹 성능이 떨어지는 문제가 발생하는 것이죠. 이런 문제를 해결하기 위해 BPF의 개념과 스펙을 확장하여 더 많은 일들을 할 수 있도록 'extend'된 BPF가 도입된 것입니다. 레지스터와 저장소가 확장되어 더욱 복잡한 로직을 커널 내부에서 실행할 수 있게 되었고, 이벤트 훅이 네트워크 패킷뿐만 아니라 시스템 콜과 다양한 하드웨어 이벤트까지 감지할 수 있게 되면서 원래의 정체성보다 더욱 많은 일을 처리할 수 있게 진화한 것이죠. 커널이 이벤트를 만들면 사용자 공간 데몬이 받아 디스크에 쓰는 구조인 auditd와는 다르게 eBPF는 이벤트가 발생하는 커널 안에 프로그램을 직접 심어두고 그 자리에서 필터링과 집계를 처리하는 방식으로 동작합니다. 커널 내부에서 처리하는 방식 덕분에 커널 내외부를 오가는 컨텍스트 스위칭이 없고, 인터프리터를 거치는 기존 방식 대비 오버헤드가 적다는 장점이 있죠.

다만, 커널 안에서 모든 액션이 수행되는 만큼 잘못된 코드가 시스템을 위협할 수 있는 위험성이 존재합니다. 따라서 eBPF는 사용자가 작성한 프로그램을 별도의 바이트코드로 컴파일한 다음 커널에 제출하면 커널이 안전성을 검증한 뒤 실행해 주는 안전 장벽을 마련했습니다. 임의의 프로그램이 메모리를 무단으로 읽지는 않는지, 무한 루프가 없는지, 허용된 도우미 함수만 호출하는지를 eBPF의 검증기가 모두 확인하고, 통과하면 JIT 컴파일러가 네이티브 머신 코드로 바꿔 커널 곳곳의 훅 지점에 붙이죠. 덕분에 커널 모듈처럼 동작하지만 시스템 전체를 위협하지 않으면서 컨텍스트 전환 없이 효율적으로, 안전하게 실행된다는 특징을 가집니다.

이렇게 발전된 개념의 eBPF는 2014년, 리눅스 커널 3.15 버전을 시작으로 리눅스 커널에 순차적으로 병합되며 사람들에게 존재감을 알렸습니다. 이후 BCC, libbpf, bpftrace 같은 도구 체인이 자리잡으면서 운영자들이 직접 사용할 수 있는 기술로 자리매김했고, Cilium같은 프로덕트가 등장하며 클라우드 네이티브 인프라의 표준 도구 중 하나가 되었습니다. 2021년에는 Linux Foundation 산하에 eBPF Foundation이 설립되면서 거버넌스까지 갖추게 되었죠.

복잡도가 높은 시스템을 운영하는 사람들에게 주목받는 eBPF

이런 기술의 진화와 함께, eBPF는 복잡도가 높은 대규모의 AI 인프라 플랫폼을 운용하는 사람들에게 주목받기 시작합니다. 이벤트가 발생한 바로 그 자리, 커널 안에서 모든 것을 처리할 수 있다는 장점이 인프라 관리자들을 사로잡은 것이죠. 전통적인 감사 모델의 경우 커널이 이벤트를 만들어 사용자 공간 데몬으로 넘기고, 그 데몬이 데이터를 다시 처리해 디스크나 네트워크로 보냅니다. 이런 식으로 서로 주고받는 과정에서 발생하는 모든 활동은 '비용'으로 취급되고, 이 '비용'은 이벤트마다 반복되며 누적될 수밖에 없습니다. 이러한 비용을 획기적으로 줄이거나 없앨 수 있다면 좋겠죠. eBPF는 이러한 왕복 구조를 없애고, 필요한 데이터만 가져가는 구조로 동작하며, 이를 통해 불필요한 이벤트로 인해 발생하는 비용을 획기적으로 줄여주기 때문에 관리자들이 원하는 그림을 그릴 수 있도록 도와주는 셈입니다.

또 하나의 장점이 있는데, 바로 컴파일 단계에서의 효율입니다. eBPF 이전의 BPF 구현은 이벤트가 발생할 때마다 바이트코드를 한 줄씩 읽고 그때그때 기계어로 번역하는 인터프리터 방식으로 동작했습니다. eBPF는 이 구조를 바꿔, 프로그램을 커널에 올리는 시점에 CPU 아키텍처에 독립적인 중간 표현(BPF 바이트코드)을 네이티브 기계어로 단 한 번만 변환합니다. 인터프리터 오버헤드 없이 실행되는 구조이기 때문에 커널 안에 미리 컴파일된 코드와 사실상 동등한 속도로 실행되죠. 초당 수십만 건의 이벤트가 쏟아지는 GPU 학습 클러스터를 상정하면 절대 작은 차이가 아니게 되는 것입니다.

마지막으로, 앞서 이야기한 검증기 덕분에 안정성이 보장된다는 장점이 있습니다. 무한 루프나 비검증 메모리 접근이 원천 차단되어 있기 때문에 어떤 워크로드가 돌고 있든 eBPF 프로그램이 시스템을 망가뜨리지 않으리라는 보장 아래 hot path(매 이벤트마다 반복 호출되는 핵심 실행 경로)에 감사 프로브를 붙일 수 있습니다. 이처럼 밀리세컨드 단위가 중요한 HPC/AI 클러스터 환경에서 잘 설계된 eBPF 감사 시스템은 추가 CPU 부담을 최소화하면서 동시에 컴플라이언스를 충족할 수 있는 방법이 되는 것입니다.

eBPF를 다루기 전에 참고하면 좋을 것들: 권한이 곧 보안

앞서 다룬 다양한 장점에도 불구하고 사용자가 신경써야 하는 한 가지 영역이 있는데, 바로 보안입니다. '당신이 심연을 오랫동안 들여다본다면, 심연 또한 당신을 들여다볼 것이다.'라는 말이 있습니다. eBPF가 커널 깊숙이 들어가 패킷과 호출을 들여다볼 수 있는 만큼, 그 자리에 악의를 가진 누군가가 들어가도 똑같은 행동을 할 수 있다는 것입니다. BPF 기술을 악용한 리눅스 기반 백도어 악성코드, 'BPFDoor'가 가장 유명한 예시 중 하나죠. BPFDoor는 2022년 5월 PwC Threat Intelligence와 Elastic Security Labs가 각각 독립적으로 공개한 리눅스 백도어로, BPF의 패킷 필터링 기능을 악용하여 특정 패턴을 담은 패킷(이하 매직 패킷)이 들어오면 활성화되는 종류의 악성코드입니다. 이렇게 악성코드가 활성화되면 시스템은 공격자에게 제어권을 넘겨주는 식으로 의도치 않은 동작을 수행하게 됩니다.

이 방식으로 공격이 들어오면 실질적으로 탐지하기가 매우 까다로워지는데요, 포트를 열지 않기 때문에 포트 스캔으로 검출되지 않고, 메모리 기반 파일시스템에서 실행된 이후로 스스로 디스크 흔적을 제거하며, 명령 수신과 전송도 암호화되어 이뤄지므로 네트워크 탐지도 우회할 수 있기 때문입니다. 2025년 한국의 대형 통신사 보안 침해 사고에서도 이 계열 악성코드가 수년간 탐지망을 우회하는 데 쓰인 것으로 확인되었고, 통신사와 정부기관 등 다양한 대형 조직을 노린 공격에 동일한 수법이 오랜 기간 활용되어 온 것으로 알려져 있습니다.

따라서 가시성을 만드는 도구가 가시성을 지울 때에도 요긴하게 사용될 수 있음을 명시하고, eBPF 프로그램의 로드 권한 자체가 보안 자산이라는 점을 인지해야 이같은 시스템을 효과적으로 운용할 수 있습니다. 감시자를 제대로 설계하지 않거나 감시자를 감시하지 않으면 감시자가 침입자로 둔갑할 수 있다는 기본 보안 원칙을 머릿속에 새겨야 합니다.

eBPF 기반 감사 시스템의 활용 예시

클러스터 환경에서 eBPF 기반 감사 시스템이 해결할 수 있을 법한 클러스터 관리자의 문제 몇 가지를 소개합니다.

curl … | sh 패턴 잡아내기: 외부 스크립트를 내려받아 검증 없이 바로 실행하는 공격 패턴은 의외로 가장 흔합니다. eBPF로는 어떤 프로세스가 outbound TCP connect()를 한 직후, 같은 프로세스 트리에서 1초 이내에 execve()로 셸 바이너리(/bin/sh, bash, dash)를 호출했는지를 정확히 잇는 사슬로 잡아낼 수 있습니다. 부가적으로 /tmp, /dev/shm 같은 임시 영역에 떨어진 드롭 스크립트도 LSM 훅으로 함께 추적할 수 있어, "받아서, 떨어뜨리고, 실행했다"는 흐름이 한 줄의 타임라인으로 정리됩니다.

컨테이너 탈출 시도: 컨테이너 안에서 pivot_root, unshare(CLONE_NEWNS), mount, umount2, capset 같은 호출이 발생하는지를 들여다보면 대부분의 탈출 시도를 한 곳에서 감시할 수 있습니다. 다만 정상적인 runc init도 컨테이너 시작 시 같은 호출을 일으키므로, 단순히 호출 발생만 감지한다면 끝없는 false alarm에 시달리게 될 수도 있습니다. 그래서 일반적으로는 워크로드가 실행되는 사용자 컨테이너에서의 호출만 범위로 잡고, runc 등의 컨테이너 런타임 헬퍼에서 발생한 호출은 제외해 진짜 의심 사례만 남기는 경우가 흔합니다.

외부로의 데이터 유출: 클러스터 내부의 RFC1918 사설 대역 통신은 커널 안에서 미리 걸러내고, 비사설 대역으로 향하는 connect()만 위로 올린 다음 그 직전에 같은 컨테이너가 /etc/shadow, /root/.ssh/, /workspace/ 아래 자격증명 파일을 읽었는지를 시간 순으로 결합하면, 어떤 컨테이너가 어디서 무엇을 읽고 어디로 보냈는지 추적할 수 있습니다. 사고 후 수습이 길어지는 많은 원인이 이 과정을 추적하지 못했거나, 추적한 데이터를 확인하기 어렵게 설계되었기 때문인데, eBPF 훅은 이걸 평상시에도 켜둘 수 있을 만큼 가볍습니다.

SSH 권한 상승 체인: SSH로 들어온 세션이 짧은 시간 안에 root 권한을 상속받았는지, 그리고 그 직후 /etc/sudoers나 ~/.ssh/authorized_keys 같은 민감한 경로를 건드렸는지까지 손쉽게 확인할 수 있습니다.

이런 시나리오들이 그동안의 기술로 해결할 수 없었던 문제는 아닙니다만, eBPF는 이걸 워크로드 지연 시간에 민감한 환경 위에서도 부담 없이 돌릴 수 있는 형태로 바꿔주는 것이죠.

마무리

보안 감사를 평상시에도 켜둘 수 있다는 것은 단순히 로그를 더 많이 남긴다는 뜻이 아닙니다. 평소 운영 데이터를 쌓아두다가 사고가 터졌을 때 원인을 빠르게 짚고, 재발을 막을 근거를 확보한다는 뜻입니다. 지금까지 이 당연한 조건을 충족하기 어려웠던 이유가 성능 부담이었다면, eBPF는 그 전제를 시작부터 바꾸고 있습니다. 커널 안에서 필요한 이벤트만 골라내고, 실제 로드 시점에 한 번 컴파일된 코드가 이후 모든 이벤트를 처리하는 구조 덕분에 감사 시스템을 항상 켜두는 것이 더이상 성능과의 타협이 아니게 된 것이죠. 학습 효율을 깎지 않으면서 침해 사고에 대한 가시성을 확보할 수 있다는 점에서, eBPF는 성능과 보안을 동시에 요구하는 인프라 운영자에게 현실적인 선택지가 되고 있습니다.

AI 인프라와 워크로드를 관리하는 운영 플랫폼, Backend.AI의 보안 감사 컴포넌트는 eBPF를 기반으로 설계되고 있습니다. Backend.AI는 침해사고가 발생했을 때 어느 워크로드에서 무슨 일이 있었는지를 바로 들여다볼 수 있도록 하기 위해 시스템 호출, 파일 접근, 네트워크 소켓, 권한 변경을 eBPF로 추적하며 컨테이너 ID와 사용자 정보를 함께 기록하고 있습니다. 이러한 자료들을 바탕으로 의심스러운 패턴이 감지되면 운영자가 컨테이너 단위로 범위를 좁혀 정밀한 추적을 실시할 수 있는 여건을 마련하고 있죠. 인프라가 제공하는 AI 워크로드 성능을 온전히 유지하면서 보안 감사까지 챙기고 싶다면, Backend.AI를 그 출발점으로 삼아보세요.

Backend.AI에 대해 자세히 알아보고 싶다면, 공식 웹사이트를 방문해주세요.