seobangwool 님의 블로그

국내 CSP 현황과 해외 CSP 현황 비교 분석

seobangwool — Tue, 16 Jun 2026 10:52:11 +0900

국내 클라우드

국내 클라우드 시장은 공공과 민간을 중심으로 점진적으로 성장하고 있으며, 특히 공공 부문에서의 도입 확대가 주요한 특징으로 나타납니다.

그 이유는 시장을 분석할 때 공공 부문이 시장의 방향성과 보안 기준을 결정하는 핵심 영역으로 작용하기 때문입니다. 더 자세한 이유로, CSAP과 같은 보안 인증과 규제를 필수적으로 요구하며, 해당 기준을 충족해야만 서비스 제공이 가능하기 때문입니다. 공공 시장은 CSP에게 기술력과 보안 수준을 검증받는 중요한 레퍼런스 역할을 수행하고 공공 환경에서 요구되는 높은 수준의 보안, 감사, 접근 통제 요건을 충족해야 이후 민간 시장에서도 신뢰를 확보할 수 있기 때문입니다.

결과적으로 국내 클라우드 시장은 기술 중심으로 빠르게 확장된 해외 시장과 달리, 규제와 보안 기준을 기반으로 점진적으로 성장하는 특징을 가지고 있으며, 이러한 차이는 이후 국내 CSP와 해외 CSP를 비교 분석하는 데 있어 중요한 기준으로 작용합니다.

공공 클라우드 도입 특징 및 제약 요인

출처: 삼성 SDS 2025 국내 퍼블릭 클라우드 현황 보고서

국내 공공 클라우드 도입률은 약 45% 수준으로, 민간(약 70%)과 해외 대비 낮은 수준을 보이고 있습니다. 이러한 차이는 공공기관이 다루는 데이터의 민감성과 높은 보안 요구사항으로 추정됩니다. 삼성 SDS의 퍼블릭 클라우드 현황보고서에 따르면 이러한 이유는, 외부 데이터 저장의 우려와 법적 제약이 가장 높은 이유였습니다. 이를 통해, 보안에 대한 높은 요구 수준과 법적 규제 준수가 필요한 공공기관의 특성이 클라우드 도입의 중요한 고려사항으로 보입니다.

또한 한 가지 흥미로운 점은, 공공 부문에서 멀티클라우드를 도입하는 주요 이유로 운영 비용 최적화가 1위로 나타났다는 점입니다. 이는 해외나 민간 기업이 멀티클라우드를 선택할 때 가용성 확보, 서비스 확장성, 기술적 유연성 등 혁신 중심의 목적을 가지는 것과는 다른 양상입니다.

공공 환경에서는 예산이 제한되어 있기 때문에, 특정 CSP에 대한 의존도를 낮추고 비용 효율적인 자원을 선택적으로 활용하는 전략이 더 중요하게 작용합니다. 즉, 멀티클라우드가 기술적 최적화 수단이기보다는 비용 절감을 위한 운영 전략으로 활용되는 경향이 강합니다.

이러한 차이는 국내 공공 클라우드가 기술 중심이 아닌 정책과 예산 중심으로 운영되고 있음을 보여주며, 해외 클라우드 시장과의 구조적 차이를 더욱 명확하게 드러내는 요소로 볼 수 있습니다.

국내 클라우드 시장 점유율

국내 클라우드 시장은 AWS가 약 60%로 매우 높은 이용 비율을 보이며 시장을 주도하는 구조를 나타냅니다.

다만, 이를 완전한 독점 구조로 보기는 어렵습니다. Google Cloud, Microsoft Azure, 네이버클라우드 등 일부 CSP가 일정 수준 이상의 점유율을 확보하며 추격 구도를 형성하고 있기 때문입니다.

결과적으로 국내 클라우드 시장은 AWS를 중심으로 소수의 CSP가 경쟁하는 과점 구조와 그 외 사업자가 존재하는 형태로 볼 수 있습니다. 특히 상위 CSP와 하위 CSP 간 점유율 격차가 크다는 점에서, 시장 내 경쟁이 균등하게 이루어지고 있다기보다는 특정 사업자 중심으로 집중된 구조적 특징을 가진다고 해석할 수 있습니다.

클라우드 시장 변화 가능성

출처: 삼성 SDS 2025 국내 퍼블릭 클라우드 현황 보고서

이러한 시장 구조에도 불구하고, 퍼블릭 클라우드에 대한 추가 도입 및 교체 의향이 지속적으로 존재한다는 점은 주목할 필요가 있습니다.

자료에 따르면 일반 산업군의 경우 약 48%, 공공 부문에서는 약 57%가 추가 도입 또는 교체 의향을 보이고 있으며, 이는 현재의 시장 점유율 구조가 고정된 것이 아니라 향후 변화 가능성이 충분히 존재함을 의미합니다. 특히 공공 부문에서 더 높은 수치를 보인다는 점은, 기존의 보수적인 도입 기조에도 불구하고 클라우드 전환이 점진적으로 확대되고 있음을 시사합니다. 이는 충분히 후발 CSP가 점유율을 확대할 수 있는 기회가 존재한다고 판단 가능합니다.

CSP 선택 기준과 향후 경쟁 전략

출처: 삼성 SDS 2025 국내 퍼블릭 클라우드 현황 보고서

한편, 클라우드 사업자 선택 시 고려 요소를 살펴보면, 데이터 보안 체계(43%), 비용 효율성(35%), 법적 안정성(33%)이 상위 요소로 나타났습니다. 이는 특히 국내 환경에서 보안과 규제가 여전히 가장 중요한 의사결정 기준으로 작용하고 있음을 보여줍니다.

이러한 점을 종합하면, 국내 CSP가 향후 경쟁력을 확보하기 위해서는 단순한 인프라 제공을 넘어 다음과 같은 방향으로 전략을 수립할 필요가 있습니다.

보안 및 컴플라이언스 역량 강화
CSAP, 데이터 주권, 감사 대응 등 공공 및 규제 환경에서 요구되는 수준을 만족시키는 것이 필수적이며, 이는 국내 CSP가 글로벌 CSP 대비 차별화할 수 있는 핵심 영역입니다.
비용 효율적인 운영 구조
공공 및 국내 기업은 비용에 민감하기 때문에, 운영 비용(TCO)을 낮출 수 있는 구조와 서비스 제공이 중요합니다.
기존 시스템과의 호환성 및 연계성 확보
온프레미스 및 레거시 시스템과의 연동은 국내 시장에서 중요한 요소이며, 이를 지원하는 하이브리드/멀티클라우드 전략이 필요합니다.
AI 및 고급 서비스 역량 확대
현재는 보안과 비용이 주요 선택 기준이지만, 장기적으로는 AI/데이터 기반 서비스 경쟁으로 확장될 가능성이 높기 때문에 이에 대한 선제적 대응이 필요합니다.

요약하자면, 국내 클라우드 시장은 현재 AWS 중심의 과점 구조를 보이지만, 추가 도입 및 교체 수요를 기반으로 점진적인 경쟁 심화와 구조 변화가 예상되는 시장이며, 국내 CSP는 보안, 비용, 규제 대응 역량을 중심으로 차별화 전략을 구축해야 할 필요가 있습니다.

국내 CSP 보안 차별성 및 개선 과제

국내 CSP 보안 강점

CSP	주요 보안 강점
NAVER Cloud	CSAP 레퍼런스 기반 공공 시장 경쟁력, 24/365 보안 관제 체계, 공공 SaaS 및 인증 컨설팅 지원
Kakao Cloud	제로트러스트 기반 설계, 키 관리 서비스 및 내부 보안 구조 강화, SmartNIC 기반 하드웨어 오프로딩
NHN Cloud	자체 SOC 운영, CSAP 및 ISMS-P 인증 확보, 공공/금융 특화 보안 역량
KT Cloud	CSAP(IaaS) 인증 및 공공시장 1위, 24/365 보안관제 서비스 제공

국내 CSP는 전반적으로 공공 및 규제 대응 중심의 보안 체계를 갖추고 있으며, CSAP 인증을 기반으로 한 신뢰성과 운영 안정성이 주요 강점으로 나타납니다. 특히 보안 관제(SOC), 인증 체계, 데이터 보호 측면에서는 일정 수준 이상의 성숙도를 확보하고 있습니다.

또한 공공 및 금융 환경에서 요구되는 보안 요건을 충족하기 위해, 접근 통제, 감사 로그, 인증 관리 등 컴플라이언스 중심 보안이 강화된 구조를 보입니다.

그러나 이러한 구조는 규제 대응에는 강점을 가지지만, 클라우드 네이티브 보안 영역에서는 상대적으로 한계를 가지는 특징이 있습니다. 이는 국내 CSP가 CSAP, ISMS-P 등 인증 기반 보안 요구사항을 충족하는 데 집중하면서, 컨테이너, 마이크로서비스, 서버리스 환경에서 요구되는 런타임 중심의 동적 보안 기술 적용이 상대적으로 제한적이기 때문입니다.

또한 서비스별로 로그와 보안 기능이 분산된 구조를 가지는 경우가 많아, 멀티클라우드 및 분산 환경에서 요구되는 통합 가시성과 중앙화된 보안 분석 체계(SIEM, SOAR 연계)가 부족한 측면이 있습니다.

더불어 IaC(Infrastructure as Code) 기반의 보안 정책 자동화나 DevSecOps 파이프라인과의 연계 수준이 글로벌 CSP 대비 낮아, Shift Left 보안 적용이 제한되는 경향을 보입니다.

이와 같은 이유로 국내 CSP는 전통적인 보안 통제와 컴플라이언스 대응에는 강점을 가지지만, 클라우드 네이티브 환경에서 요구되는 실시간 탐지, 자동화, 통합 보안 운영 측면에서는 개선이 필요한 것으로 이해됩니다.

해외 CSP 대비 한계점

해외 CSP(AWS, GCP, Azure)는 클라우드 네이티브 환경을 전제로 설계된 보안 서비스를 제공하는 반면, 국내 CSP는 공공 및 규제 대응 중심으로 발전해왔기 때문에 다음과 같은 한계가 존재합니다.

런타임 보안 제한

국내 CSP는 컨테이너 및 워크로드 실행 시점의 위협을 탐지하는 기능이 제한적인 경우가 많습니다.
AWS GuardDuty, GCP Security Command Center, Azure Defender와 같이 런타임 기반 이상 행위 탐지 및 행위 분석 기능이 기본 서비스로 통합되어 있는 것과 달리, 국내 CSP는 주로 네트워크 및 접근 통제 중심의 보안 기능에 집중되어 있습니다.

또한 eBPF 기반 행위 탐지, 컨테이너 런타임 보호, Kubernetes 보안 정책 자동 적용 등의 기능이 제한적이거나 별도 구성에 의존하는 경우가 많아, 실시간 공격 대응 능력에서 차이가 발생합니다.

로그 통합 및 가시성 부족

해외 CSP는 CloudWatch, Cloud Logging, Azure Monitor와 같이 로그 수집, 저장, 분석이 통합된 플랫폼을 제공하며, 이를 기반으로 SIEM 연계 및 중앙 분석이 가능합니다.

반면 국내 CSP는 서비스별 로그가 분산되어 있거나, 통합 로그 분석 플랫폼이 제한적인 경우가 많아 멀티클라우드 및 분산 환경에서 전체 공격 흐름을 추적하는 데 어려움이 있습니다.

특히 보안 이벤트를 하나의 타임라인으로 상관 분석하는 기능이 부족하여, 복합 공격 시나리오 대응에 한계가 발생할 수 있습니다.

위협 탐지 및 대응 자동화 부족

해외 CSP는 AI/ML 기반 이상 탐지(UEBA), 위협 인텔리전스 연계, SOAR 기반 자동 대응 기능을 기본적으로 제공하거나 쉽게 연계할 수 있는 구조를 가지고 있습니다.

예를 들어, AWS는 GuardDuty + Security Hub + Lambda를 통해 자동 대응을 구성할 수 있으며, Azure는 Sentinel 기반의 SOAR 기능을 제공합니다.

반면 국내 CSP는 탐지 이후 대응을 수동으로 처리하는 경우가 많고, 자동화된 대응 플레이북이나 정책 기반 차단 기능이 제한적이기 때문에 대응 속도와 운영 효율성 측면에서 차이가 발생합니다.

IaC 기반 보안 자동화 미흡

해외 CSP는 Terraform, CloudFormation, ARM Template 등 IaC와 보안 정책을 긴밀하게 통합하여, 인프라 생성 단계에서부터 보안이 적용되는 구조를 제공합니다.

또한 CSPM(Cloud Security Posture Management), CIEM(Cloud Infrastructure Entitlement Management) 기능이 통합되어 있어, 설정 오류나 과도한 권한을 자동으로 탐지하고 수정할 수 있습니다.

반면 국내 CSP는 IaC 기반 보안 정책 자동화 지원이 상대적으로 부족하며, DevSecOps 파이프라인과의 연계도 제한적인 경우가 많아 보안이 사후적으로 적용되는 구조가 나타납니다.

이로 인해 보안 설정 오류나 권한 관리 문제를 사전에 방지하기보다는, 운영 이후에 대응하는 방식이 되는 한계가 존재합니다.

결론

국내 클라우드 시장은 AWS 중심의 과점 구조 속에서 공공 및 규제 환경을 기반으로 성장해왔으며, 보안 측면에서는 CSAP, ISMS-P 등 인증 기반의 컴플라이언스 대응 역량에서 강점을 보이고 있습니다.

그러나 해외 CSP와 비교할 때, 클라우드 네이티브 환경에서 요구되는 런타임 보안, 통합 로그 가시성, 위협 탐지 자동화, IaC 기반 보안 자동화 측면에서는 상대적인 한계가 존재합니다. 이는 국내 CSP가 규제 대응 중심으로 발전해온 구조적 특성에서 기인한 것으로 볼 수 있습니다.

한편, 퍼블릭 클라우드의 추가 도입 및 교체 의향이 지속적으로 증가하고 있다는 점은 시장이 고정되어 있지 않으며, 향후 경쟁 구조 변화 가능성이 존재함을 의미합니다.

따라서 국내 CSP는 클라우드 네이티브 환경에 적합한 자동화된 보안 체계와 통합 운영 플랫폼으로의 전환이 필요하며, 이를 통해 글로벌 CSP와의 기술 격차를 줄이고 경쟁력을 확보해야 할 것입니다.

결론은, 향후 클라우드 보안 경쟁력을 올리기 위해서 규제 대응에 더불어 실시간 탐지, 자동 대응, DevSecOps 기반 보안 자동화 역량을 올릴 수 있느냐에 의해 결정될 것으로 판단합니다.

출처

클라우드 보안사고 트렌드

seobangwool — Tue, 16 Jun 2026 10:44:27 +0900

클라우드 보안 사고

클라우드 도입률: 86%
멀티클라우드 사용률: 70%

출처: NIA 한국지능정보사회진흥원, 클라우드 컴퓨팅 동향 - 2025 플렉세라 보고서 분석

대부분의 기업은 클라우드를 도입한 상태이며, 그 중 상당수는 멀티클라우드 환경으로 전환한 상태입니다. 특정 벤더에 대한 종속을 줄이기 위한 전략으로, 예를 들어 핵심 서비스는 AWS에서 운영하면서 데이터 분석이나 AI 워크로드는 GCP를 활용하는 방식으로 구성할 수 있습니다. 이러한 구조는 서비스 장애 발생 시 다른 클라우드로 트래픽을 분산하거나 백업 시스템을 활용할 수 있어 안정성을 높이며, 동시에 각 클라우드의 강점을 선택적으로 활용할 수 있어 유연성 또한 확보할 수 있습니다.

그러나 이러한 전환과 확산에 따라 보안 및 개인정보보호 이슈가 주요 우려사항으로 부각되고 있으며, 동시에 클라우드 비용 증가와 관리 복잡성 또한 중요한 우려사항으로 나타나고 있습니다. 멀티클라우드 환경에서는 각 클라우드별 정책과 규제를 통합적으로 관리해야 하기 때문에 거버넌스/컴플라이언스 측면에서도 높은 수준의 관리 체계가 요구됩니다.

클라우드 보안 사고 근본 원인 top 5

1. Misconfiguration / 설정 오류

클라우드 보안 사고의 가장 대표적인 근본 원인은 잘못된 설정입니다.
공개되면 안 되는 스토리지 버킷이 외부에 노출되거나, 사용자 정의 방화벽 규칙이 과도하게 열려 있거나, 변경 통제가 제대로 이루어지지 않아 권한과 네트워크 설정이 의도와 다르게 확장되는 경우가 이에 해당합니다. CSA는 2024년 Top Threats에서 Misconfiguration and inadequate change control를 가장 먼저 제시했으며, Google Cloud도 최근 위협 동향에서 사용자가 관리하는 소프트웨어와 허용적인 사용자 정의 방화벽 규칙이 실제 초기 침투 경로로 악용된다고 설명합니다. 실제 사고 사례에서는 클라우드 자체보다도 잘못 구성된 고객 환경에서 시작되는 경우가 많습니다.

2. Identity and Access Management / IAM 관리 실패 (권한 설정 오류)

두 번째 근본 원인은 인증과 권한 관리 실패입니다. 과도한 권한 부여, MFA 미적용, 페더레이션 계정 통제 미흡, 토큰 탈취, 공유 계정 사용 같은 문제가 여기에 포함됩니다. CSA는 Identity and Access Management를 독립적인 핵심 위협으로 제시했고, Google Cloud Threat Horizons H1 2026은 침해의 83%가 identity compromise를 기반으로 했다고 명시합니다. 또한 Google은 피싱을 넘어 음성 기반 사회공학, 토큰 탈취, 다중 클라우드와 SaaS를 아우르는 인증 경계 공격이 확대되고 있다고 설명합니다.

3. 계정정보 도난 (Credential Theft)

클라우드 환경에서는 계정이 곧 시스템 접근 권한을 의미합니다. 따라서 계정 정보가 탈취되는 순간 공격자는 별도의 취약점 없이도 내부 자원에 접근할 수 있게 됩니다. 특히 피싱과 같은 사회공학 공격으로 인한 계정 탈취가 매우 흔해졌으며, 치명적인 초기 침투 경로가 생기게 됩니다. 추가로 토큰 탈취와 같은 자격 증명이 유출되게 된다면, 클라우드같은 경우에는 콘솔과 API와 CLI 접근이 모두 계정을 통해 이루어지기 때문에 피해 범위가 빠르게 확장됩니다. 실제로 최근 클라우드 침해 사고의 상당수는 인프라 취약점이 아닌 계정 탈취에서 시작되는 것으로 나타나고 있습니다.

4. SSH 키 유출 및 오용

SSH 키는 서버와 인스턴스 접근을 위한 핵심 인증 수단이지만, 관리가 미흡할 경우 공격자가 직접 서버에 접근할 수 있는 통로가 됩니다. 개인 PC, 코드 저장소, CI/CD 환경 등에 저장된 키가 유출되거나, 재사용된 키가 여러 시스템에 적용된 경우 공격 범위가 크게 확대됩니다. 또한 키에 대한 회전정책과 폐기 정책이 없을 경우, 장기간 무단 접근이 지속될 수 있어 심각한 보안 위협으로 이어집니다.

5. 접근 통제 실패 (Access Control Failure)

클라우드에서는 세밀한 권한 관리가 가능하지만, 실제 운영에서는 과도한 권한 부여(Over-privilege)가 빈번하게 발생합니다. 관리자 권한을 불필요하게 부여하거나, 역할 기반 접근 제어(RBAC)가 제대로 설계되지 않은 경우 공격자는 하나의 계정만 확보해도 전체 시스템을 제어할 수 있습니다. 특히 멀티클라우드 환경에서는 권한 정책이 분산되어 관리되기 때문에, 일관되지 않은 접근 통제가 보안 취약점으로 이어질 가능성이 높습니다.

추가 관점: 탐지 실패로 인한 영향 심화

위와 같은 문제들이 발생한다면, 적절한 탐지 체계를 갖춰야합니다. 그러지 않을 경우 피해가 더욱 확대됩니다. 로그 수집은 되어 있으나 실시간 분석이 이루어지지 않거나, 이상 행위 탐지 체계가 부재한 경우 공격자는 장기간 시스템에 머무르며 권한을 확장하고 데이터를 유출할 수 있습니다. 탐지 실패는 피해 규모를 증폭시키는 주요 원인이 됩니다.

통합 대응 전략

클라우드 보안 사고의 주요 원인은 설정 오류, 권한 관리 실패, 인증 취약점, 그리고 탐지 부족에서 비롯됩니다.

이에 따라 구성 관리, 권한 통제, 인증, 모니터링을 통합적으로 적용하는 전략이 필요합니다. 이러한 통합 대응 전략은 예방과 탐지를 동시에 강화하여 클라우드 환경 전반의 보안 수준을 향상시켜야합니다.

구성 관리 및 권한 통제 강화

클라우드 환경에서는 설정과 권한을 코드 기반으로 관리하고 최소 권한 원칙을 적용하는 것이 중요합니다.

IaC (Infrastructure as Code)
인프라를 코드로 정의하고 관리하여, 설정 변경을 추적 가능하게 만들고 휴먼 에러를 최소화합니다. 코드 리뷰와 CI/CD 파이프라인을 통해 보안 정책을 사전에 검증할 수 있습니다.
CSPM (Cloud Security Posture Management)
클라우드 리소스의 설정 상태를 지속적으로 점검하여, 공개 스토리지, 과도한 포트 개방, 정책 위반 등 보안 설정 오류를 자동으로 탐지하고 수정합니다.
Least Privilege (최소 권한 원칙)
사용자 및 서비스 계정에 필요한 최소한의 권한만 부여하여, 계정 탈취 시 피해 범위를 제한합니다. 권한 사용 패턴을 기반으로 지속적인 권한 축소가 필요합니다.

강력한 인증 및 지능형 모니터링

계정 탈취와 탐지 실패를 방지하기 위해서는 인증 체계를 강화하고, 로그 기반의 실시간 분석 체계를 구축해야 합니다.

MFA (Multi-Factor Authentication)
단일 인증 요소에 의존하지 않고 추가 인증 수단을 적용하여 계정 탈취 위험을 크게 낮춥니다. 특히 관리자 계정과 외부 접근 경로에는 필수적으로 적용해야 합니다.
로그 중앙화 (Centralized Logging)
여러 클라우드와 서비스에서 발생하는 로그를 중앙에서 수집/관리하여, 전체 시스템의 가시성을 확보합니다. 이를 통해 이상 행위 탐지와 사고 대응 속도를 향상시킬 수 있습니다.
지능형 위협 탐지 (Intelligent Threat Detection)
AI 분석 기능을 활용한 SIEM(Security Information and Event Management) 또는 SOAR(Security Orchestration, Automation and Response)를 통해 로그를 실시간으로 분석하고, 이상 행위를 탐지합니다. 단순 이벤트 탐지를 넘어 공격 패턴을 상관 분석하고 자동 대응까지 수행함으로써, 초기 침투 단계에서 위협을 식별하고 대응 속도를 크게 향상시킬 수 있습니다.

Enterprise Best Practices

클라우드 환경에서는 인프라와 운영 전반을 포함한 보안 체계 구축이 필요합니다.

특히 기업 환경에서는 다양한 서비스와 계정, 파이프라인이 복합적으로 연결되기 때문에, 영역별 Best Practice를 이해하고 일관된 보안 정책을 적용해야 합니다.

1. 컨테이너 보안

컨테이너 환경에서는 이미지, 레지스트리, 런타임, 오케스트레이션까지 전체 라이프사이클 보안이 필요합니다.

신뢰된 베이스 이미지 사용 및 취약점 스캔 (이미지 빌드 단계)
최소 이미지(distroless, slim) 사용 및 CVE 지속 관리
이미지 서명 및 무결성 검증 (Sigstore, Cosign 등)
최소 권한 실행 (non-root user, capability drop, seccomp profile 적용)
런타임 보안 적용 (read-only filesystem, no-new-privileges)
Kubernetes 보안
- NetworkPolicy 기반 마이크로세그멘테이션
- Pod Security Standards / Admission Controller 적용
- Secret 외부 관리 (Secret Manager 연동)
컨테이너 간 lateral movement 방지

2. 스토리지 보안

데이터 보호는 접근 제어, 가시성, 정책 기반 관리가 중요합니다.

모든 저장소 기본 비공개 설정 (Public access 차단)
데이터 암호화
- At-rest (KMS 기반)
- In-transit (TLS 적용)
IAM + Resource Policy 기반 세분화된 접근 제어
접근 로그 및 감사 로그 활성화 (CloudTrail, Access Log)
데이터 분류 체계 구축 (PII, 민감정보)
DLP(Data Loss Prevention) 정책 적용
데이터 버전 관리 및 백업 (Versioning, Immutable storage)
DR(Disaster Recovery) 및 리전 간 복제 전략 수립

3. 자격 증명 보호 (Credential Protection)

클라우드 보안의 핵심은 자격 증명 관리입니다.

코드 및 레포지토리 내 하드코딩된 키/토큰 제거
Secret Manager, Vault 등을 사용하여 중앙 집중 관리
키 로테이션 및 만료 정책 자동화
장기 키 제거 및 단기 자격 증명 사용 (STS, OIDC)
MFA 및 조건부 접근 정책 적용
서비스 간 인증 (Workload Identity, Service Account)
Credential Leakage 탐지 (코드, 이미지, CI 로그)

4. CI/CD 파이프라인 보안

CI/CD는 공급망 공격의 핵심 지점으로, 코드부터 배포까지 전 과정 보호가 필요합니다.

SAST / SCA / DAST 자동화 적용 (Shift-left 적용)
Secret Scanning 및 정책 기반 차단
빌드 환경 격리 (Ephemeral Runner)
빌드 아티팩트 무결성 검증 (서명, checksum)
SBOM(Software Bill of Materials) 생성 및 관리
CI/CD 권한 최소화 (OIDC 기반 접근)
외부 dependency 검증 및 공급망 공격 대응
승인 기반 배포 (Policy Gate)

5. 보안 관제 및 사고 대응

보안은 탐지와 대응 속도가 중요하며, 이를 위한 가시성과 자동화가 필요합니다.

클라우드 네이티브 로그 통합 (멀티클라우드 및 SaaS 로그 수집)
위협 탐지 자동화 (SIEM 기반 상관 분석 및 이상 행위 탐지)
SOAR 기반 대응 자동화
- 계정 차단
- 키 폐기
- 리소스 격리
침해사고 대응 훈련
포렌식 준비성 확보 (로그 보존, 타임라인 재구성, 증거 수집 체계)

출처

CSAP 인증제도와 사이버 보안 실태평가 지표

seobangwool — Tue, 16 Jun 2026 10:38:10 +0900

CSAP 인증제도

CSAP 인증제도는 정보보호 기준의 준수 여부를 인증기관이 평가하고 인증하여, 이용자들이 안심하고 클라우드 서비스를 이용할 수 있도록 지원하는 제도입니다.

공공기관에 안정성과 신뢰성이 검증된 민간 클라우드 서비스가 공급되며, 이를 통해 공공 영역에서도 안전한 클라우드 도입이 가능해집니다. 공공기관은 민감한 개인정보와 주요 국가 데이터를 처리하기 때문에, 일반적인 상용 서비스보다 높은 수준의 보안이 요구됩니다. 하지만 민간 클라우드 서비스는 사업자마다 보안 수준이 상이하기 때문에, 이를 객관적으로 검증할 수 있는 기준이 필요합니다.

CSAP 인증은 이러한 문제를 해결하기 위해 도입되었으며, 공공기관이 안전하게 사용할 수 있는 클라우드 서비스를 선별하는 역할을 수행합니다.

CSAP 인증 서비스 유형별 분류

CSAP 인증은 클라우드 서비스 제공 형태에 따라 평가 기준과 보안 통제 항목이 달라지며, 각 계층별 책임 범위에 따라 인증이 구분됩니다.

IaaS (Infrastructure as a Service)
- 가상 서버, 스토리지, 네트워크 등 인프라 자원을 제공하는 형태입니다.
- 사용자는 OS, 애플리케이션, 데이터에 대한 보안을 직접 관리합니다.
- CSP는 물리 인프라와 가상화 계층을 보호합니다.
PaaS (Platform as a Service)
- 애플리케이션 개발 및 실행 환경을 제공하는 형태입니다.
- 사용자는 애플리케이션과 데이터 중심으로 보안을 관리합니다.
- 플랫폼(OS, 미들웨어 등)은 CSP가 관리합니다.
SaaS (Software as a Service)
- 완성된 소프트웨어를 서비스 형태로 제공하는 모델입니다.
- 사용자는 서비스 이용과 데이터 관리에 집중합니다.
- 애플리케이션 및 인프라 전반은 CSP가 관리합니다.
DaaS (Desktop as a Service)
- 가상 데스크탑 환경을 클라우드 기반으로 제공하는 서비스입니다.
- 사용자는 네트워크를 통해 언제 어디서든 동일한 업무 환경에 접근할 수 있습니다.
- 디바이스와 물리적 환경에 대한 의존도를 낮추고, 중앙 집중형 보안 통제가 가능합니다.
- 제로트러스트 환경에서는 디바이스 신뢰 대신 사용자 신원과 세션 기반 접근 제어와 결합되어 활용됩니다.

CSAP 인증제도 절차

출처: https://www.kisa.or.kr/1050603

CSAP 인증은 정책기관, 평가기관, 신청기관, 이용자 간의 역할 분리를 기반으로 구성되며, 보안 평가와 인증 과정을 통해 공공에서 신뢰할 수 있는 클라우드 서비스를 선별하는 구조입니다.

클라우드 서비스 제공자가 인증을 신청합니다.
평가/인증기관이 보안 평가를 수행합니다.
필요 시 기술자문기관의 지원을 받아 평가의 신뢰성을 확보합니다.
평가 결과를 기반으로 인증이 부여됩니다.
공공기관은 인증된 클라우드 서비스를 이용합니다.

CASP 인증제도 통제항목

CASP 통제항목의 자세한 표는 다음과 같습니다.

출처: https://isms-p.or.kr/sysm/intro/selectSysmVrtlDetail.do

사이버보안 실태평가

출처: https://www.ncsc.go.kr:4018/PageLink.do?link=forward:/PageContent.do&tempParam1=&menuNo=010000&subMenuNo=010200&thirdMenuNo=010202

사이버보안 실태평가는 기관의 정보보호 수준을 점검하고, 취약점을 식별하여 전반적인 보안 수준을 향상시키기 위한 평가 제도입니다. 각 기관이 자체적으로 보안 상태를 점검한 이후, 국가정보원이 이를 검증하고 보완하는 단계적 구조로 운영됩니다.

사이버보안 실태평가는 다음과 같은 단계로 진행됩니다.

기관 자체평가
- 각 기관이 내부 보안 통제 수준을 점검하고 자체적으로 평가를 수행합니다.
현장실사 (국가정보원)
- 국가정보원이 직접 현장을 점검하여 실제 보안 수준을 검증합니다.
추가 증빙 및 이의신청
- 기관은 평가 결과에 대한 추가 자료를 제출하거나 이의를 제기할 수 있습니다.
평가 결과 검토·확인 (국가정보원)
- 제출된 자료를 기반으로 최종 평가 내용을 검토하고 확정합니다.
평가 결과 통보 (국가정보원)
- 확정된 평가 결과를 기관에 공식 통보합니다.
개선대책 제출
- 기관은 식별된 취약점에 대한 개선 계획을 수립하여 제출합니다.
개선대책 이행 여부 확인 (국가정보원)
- 국가정보원이 개선 조치 이행 여부를 확인하고 후속 관리합니다.

2026년 사이버보안 실태평가지표 주요 변화

출처: igloo 2026년도 사이버보안 실태 평가지표’ 개정 내용으로 본 공공 보안 정책의 변화

2025년에는 다음과 같은 항목이 존재했습니다.

내부망과 인터넷을 분리하였는가? 1점
망분리 위반사항에 대해 주기적으로 점검하는가? 2점
승인없는 자료 반출입이 불가토록 망간 자료전송 시스템 등 망분리 시스템을 운영하고 있는가? 2점

이와 비교해보았을 때, 기존 망 분리 중심 보안에서 N2SF 기반 제로트러스트 구조로 전환되는 흐름임을 알 수 있습니다.

현재의 평가 기준은 대부분 형식적인 실제 보안 운영 능력 중심입니다.
재난 대응, 복구 체계, 보안 훈련 항목의 배점이 증가한 이유는 사고 대응 역량을 직접 평가하기 위함입니다. AI의 발전에 따라 AI 기반 보안 기술과 자동화된 운영 체계도 주요 평가 요소가 되었습니다. 대규모 환경에서 수동 대응이 아닌 자동화 기반 보안 운영이 필수이며, 다중인증과 같은 인증 강화 항목은 신원 기반 통제를 강화하기 위한 요소입니다.

2026년 사이버보안 실태평가는 기존처럼 정적인 보안 구조가 아니라, 지속적으로 검증되고 운영되는 동적인 보안 체계를 요구하는 방향입니다.

출처

제로트러스트 보안 모델 (Zero Trust Architecture)

seobangwool — Mon, 15 Jun 2026 17:24:19 +0900

제로트러스트란?

제로 트러스트(Zero Trust)는 네트워크 위치나 내부,외부 여부와 관계없이 어떠한 사용자 것도 기본적으로 신뢰하지 않고, 지속적인 검증과 최소 권한 원칙을 통해 보안을 강화하는 보안 모델입니다.

핵심원칙

모든 트래픽과 요청을 신뢰하지 않고 항상 검증합니다.
업무에 필요한 Least Privilege(최소권한)만 부여합니다.
Assume Breach(침해가정) 기반으로 방어 전략을 수립합니다. (내부망 침해 가정)
지속적인 상태 모니터링을 통해 실시간 위협에 대응합니다.

현대 IT 환경 변화와 새로운 보안 요구사항

사이버 보안 위협은 과거 단순한 외부 침입 중심에서 점차 정교하고 복합적인 형태로 진화하고 있습니다. 기존에는 방화벽과 같은 경계 기반 방어를 통해 외부 공격을 차단하는 것이 주요 전략이었지만, 최근에는 계정 탈취, 피싱, 공급망 공격, API 악용 등 정상적인 접근 경로를 활용한 공격이 증가하고 있습니다. 특히 공격자가 내부 사용자 권한을 획득한 이후에는 기존 보안 체계를 우회하여 시스템 전반으로 확산될 수 있기 때문에, 내부망 침투 시에 무방비 상태에 노출됩니다.

이와 동시에 업무 환경 또한 크게 변화하고 있습니다. 클라우드 기술의 확산으로 온프레미스 중심의 인프라에서 벗어나 하이브리드/멀티 클라우드 환경이 확산되었으며, SaaS 서비스와 원격 근무, 모바일 기기 사용이 증가하면서 사용자와 시스템은 다양한 네트워크를 통해 연결되고 있습니다. 이로 인해 내부와 외부의 경계는 점점 모호해지고 있으며, 특정 네트워크 위치를 기준으로 신뢰를 판단하는 방식은 현실적으로 유지되기 어려운 구조로 변화하고 있습니다.

이러한 변화는 결국 보안 원칙의 근본적인 전환을 요구하고 있습니다. 과거에는 내부를 신뢰하고 외부를 차단하는 경계 기반 보안 모델이 효과적이었으나, 현재는 모든 접근을 기본적으로 신뢰하지 않고 지속적으로 검증하는 방식이 필요해졌습니다. 즉, 보안의 중심이 네트워크 위치에서 사용자와 디바이스의 신원, 그리고 행위 기반 검증으로 이동하고 있는 것입니다. 이러한 흐름 속에서 최소 권한 원칙, 지속적인 인증과 인가, 그리고 모든 요청에 대한 검증을 핵심으로 하는 새로운 보안 패러다임이 자리잡고 있습니다.

(요약 정리) 왜 제로트러스트인가?

사이버 위협에 진화
- 계정 기반 공격 증가: 피싱, 크리덴셜 스터핑 등을 통해 정상 사용자 계정을 탈취하는 공격이 증가하였습니다.
- 내부자 및 권한 오남용 위협: 탈취된 계정 또는 내부 사용자의 과도한 권한을 악용한 공격이 주요 위협으로 부상하였습니다.
- 공급망 공격 확대: 신뢰된 외부 라이브러리, 패키지, 협력사를 통한 우회 침투 공격이 증가하고 있습니다.
- API 및 애플리케이션 계층 공격 증가: 네트워크가 아닌 애플리케이션/API 레벨에서의 공격이 주요 공격 벡터로 자리잡았습니다.
업무 환경의 변화
- 원격근무 확산: 재택/원격 근무 확대로 접속 위치와 단말의 다양성이 증가하였습니다.
- 클라우드/SaaS 확산: 데이터가 사내망을 벗어나 외부 클라우드와 SaaS 서비스에 분산 저장됩니다.
보안 원칙의 전환
- Perimeter-less: 신뢰하는 내부망의 개념을 폐기합니다. 모든 네트워크를 신뢰하지 않습니다.
- Verify Explicitly: 세션 단위의 최소 권한 부여와 지속적으로 동적 정책을 재평가해야 합니다.

추가로, 현재 보안적합성을 받는 경우에는 내부망 침투를 가정하고 검증하는 방식이 일반적이라고 합니다. 외부 경계 방어만으로 충분하지 않다는 전제는 굉장히 중요한 평가 기준이 되었습니다.

제로트러스트 보안 모델

ZTA 아키텍처

출처: https://www.microsoft.com/en-us/security/blog/2024/08/06/how-microsoft-and-nist-are-collaborating-to-advance-the-zero-trust-implementation/

위 다이어그램은 NIST ZTA 기준 아키텍처 위에 마이크로소프트 솔루션을 매핑한 다이어그램입니다. 각 박스의 제목을 통해 전체적인 흐름을 참고하면 됩니다.

사용자와 디바이스의 신원을 중심으로 접근이 결정되며, 정책 기반으로 모든 요청이 검증되고, 그 결과가 다시 분석 및 피드백으로 이어지는 순환 구조를 갖습니다.

해당 아키텍처를 기준으로 ZTA의 핵심 구성요소를 알아봅니다.

ZTA의 핵심 구성요소

PE (Policy Engine)
Policy Engine은 접근 요청에 대한 허용 여부를 최종적으로 판단하는 핵심 구성요소입니다. 사용자 신원, 디바이스 상태, 위치, 위험도 등 다양한 정보를 종합하여 보안 정책에 따라 접근 가능 여부를 결정합니다.

접근 요청에 대한 최종 의사결정 수행
정책 및 신뢰도 평가
허용 또는 차단 결정

PA (Policy Administrator)
Policy Administrator는 Policy Engine의 결정 결과를 실제 실행 가능한 형태로 변환하는 역할을 수행합니다. 또한 인증,인가 서비스와 연계하여 세션을 생성하고 토큰이나 크리덴셜을 관리합니다.

PE의 결정을 실제 정책으로 실행
인증 및 인가 서비스 연계
세션 생성 및 토큰 관리

PEP (Policy Enforcement Point)
Policy Enforcement Point는 사용자와 보호 대상 리소스 사이에서 실제 접근을 통제하는 게이트웨이 역할을 수행합니다. PE와 PA의 결정에 따라 접근을 허용하거나 차단하며, 연결 상태를 지속적으로 관리합니다.

사용자와 리소스 간 접근 통제
접근 허용 및 차단 수행
연결 생성, 모니터링 및 종료

PIP (Policy Information Point)
Policy Information Point는 정책 판단에 필요한 다양한 정보를 수집하여 제공하는 구성요소입니다. 사용자 속성, 디바이스 상태, 자산 정보, 위협 인텔리전스 등 다양한 데이터를 제공하여 PE가 보다 정확한 결정을 내릴 수 있도록 지원합니다.

사용자 및 디바이스 정보 제공
자산 상태 및 위협 정보 수집
정책 판단을 위한 근거 데이터 제공

ZTA 성숙도 모델

출처: https://blog.securesky.com/zero-trust-maturity-model-ztmm-2.0-a-transition-to-zta

Zero Trust 성숙도 모델(Zero Trust Maturity Model)은 조직의 현재 보안 수준을 평가하고, Zero Trust Architecture를 단계적으로 도입하기 위한 기준을 제공합니다. 단순히 보안 솔루션을 추가하는 것이 아니라, 신원 기반 접근 통제와 지속적 검증 체계를 얼마나 구현하고 있는지를 기준으로 성숙도를 판단합니다.

Traditional

기존의 경계 기반(Perimeter-Based) 보안 모델 단계입니다. 내부망은 신뢰하고 외부는 차단하는 구조를 기반으로 하며, 대부분 방화벽(Firewall)과 VPN을 중심으로 보안이 구성됩니다.

내부망 신뢰, 외부 차단 구조
방화벽 및 VPN 중심 보안 운영
ID/PW 기반의 정적 인증 방식 사용
수동 대응 위주의 보안 운영
자산 및 사용자 활동에 대한 가시성 부족

Initial

Zero Trust 도입이 시작되는 단계입니다. 신원 관리와 인증 체계를 강화하기 위해 MFA를 도입하고, 사용자와 디바이스에 대한 기본적인 관리 체계를 구축하기 시작합니다.

MFA(다중요소인증) 적용
사용자 및 디바이스 식별 체계 구축
기본적인 클라우드 보안 기능 적용
로그 수집 및 모니터링 자동화 시작
보안 정책 표준화 추진

Advanced

Zero Trust의 핵심 개념이 실제 운영 환경에 적용되는 단계입니다. 사용자 신원뿐 아니라 디바이스 상태와 접근 환경을 함께 고려하여 접근을 제어하며, 최소 권한 원칙이 본격적으로 적용됩니다.

신원 기반 접근 제어 체계 정착
디바이스 상태 기반 접근 통제
최소 권한(Least Privilege) 정책 적용
세션 단위 접근 제어 수행
통합 로그 분석 및 모니터링 체계 구축
보안 이벤트에 대한 자동 대응 기능 적용

Optimal

Zero Trust가 조직 전반에 완전히 정착된 단계입니다. 접근 요청은 지속적으로 검증되며, 위험 수준에 따라 정책이 실시간으로 변경됩니다. 또한 데이터 중심 보안과 자동화된 운영 체계가 구축되어 있습니다.

지속적 검증(Continuous Verification)
위험 기반 동적 접근 제어(Risk-Based Access)
정책 자동화 및 오케스트레이션
데이터 중심 보안 체계 운영
전사적 통합 모니터링 및 대응
AI 및 분석 기반 보안 운영 고도화

제로트러스트 책임 모델

출처: https://aws.amazon.com/ko/compliance/shared-responsibility-model/

클라우드 환경에서의 보안은 서비스 제공자와 사용자 간 역할이 명확히 구분되는 책임 공유 모델을 기반으로 구성됩니다. 인프라 자체는 CSP가 보호하지만, 그 위에서 동작하는 모든 접근과 설정, 데이터는 고객이 직접 통제해야 하기 때문에 책임 경계를 정확히 이해하는 것이 필수입니다.

추가자료)

금융권 제로 트러스트 N2SF 연계 아키텍처

출처: [2025 정보보호 솔루션 컨퍼런스] ’금융권 제로 트러스트 아키텍처 전환 사례 및 N²SF 연계 전략’ - KB국민은행 이형철 정보보호부 수석 (youtube영상 중)

CSP 책임 영역

CSP는 클라우드 기반 인프라에 대한 보안을 책임집니다.
사용자가 직접 제어할 수 없는 영역으로, 물리적 데이터센터부터 글로벌 인프라까지 포함됩니다.

물리적 보안
- 데이터센터 출입 통제 및 물리적 시설 보호를 수행합니다.
- 서버, 스토리지, 네트워크 장비 등 하드웨어 자산을 보호합니다.
인프라 및 가상화 계층
- 하이퍼바이저 및 가상화 계층의 보안을 담당합니다.
- 물리 네트워크 및 스토리지 인프라를 안정적으로 운영합니다.
관리형 서비스 보안
- PaaS/SaaS 서비스의 플랫폼 보안과 가용성을 제공합니다.
- DDoS 방어, 기본 보안 통제 기능을 제공합니다.

고객 책임 영역

고객은 클라우드 위에서 사용하는 모든 자산과 설정, 그리고 접근 제어에 대한 보안을 책임집니다. 제로트러스트 관점에서는 특히 신원, 정책, 데이터 보호가 핵심 영역입니다.

데이터 및 아이덴티티
- 데이터 암호화 및 보호(Data Protection)를 수행합니다.
- 사용자, 서비스, 디바이스에 대한 접근 제어(Identity & Access)를 구성합니다.
- 애플리케이션 보안과 로그 관리까지 포함하여 운영합니다.
워크로드 및 디바이스 보안
- 워크로드 구성 및 배포를 관리합니다.
- 위협 모니터링 및 사고 대응을 수행합니다.
- 엔드포인트와 디바이스 상태를 지속적으로 관리합니다.
네트워크 보안 (P7 반영)
- 네트워크 트래픽을 암호화하고 전송 구간을 보호합니다.
- VCN/VPC 구성, 마이크로 세그멘테이션을 통해 네트워크를 분리합니다.
- 보안 그룹(NSG), 방화벽 설정을 통해 접근을 제어합니다.
- Zero Trust 기반 게이트웨이를 통해 트래픽을 통제합니다.

마무리하며 ..

N2SF와 제로트러스트를 어떻게 접목할 수 있을까?

N2SF와 제로트러스트는 함께 활용할 수 있는 지점이 많다고 생각했습니다. N2SF가 보안 통제 항목과 관리 기준을 제시하는 역할이라면, 제로트러스트는 그 통제 기준을 접근 제어 구조로 구현하는 방식에 가깝습니다.

즉, N2SF의 보안 요구사항을 ZTA의 구성요소인 PE, PA, PEP와 연결하여 정책 판단과 접근 통제 구조로 구체화할 수 있습니다. 예를 들어 사용자 인증, 디바이스 상태 점검, 네트워크 접근 제어, 데이터 보호와 같은 항목은 각각 신원 기반 검증, 세션 단위 접근 제어, 마이크로 세그멘테이션, 데이터 중심 보안 정책으로 확장될 수 있습니다.

특히 금융권이나 클라우드 환경처럼 규제와 보안 요구사항이 높은 영역에서는 단순히 보안 솔루션을 도입하는 것보다, 기존 통제 체계를 기준으로 현재 환경을 점검하고 어떤 부분을 제로트러스트 방식으로 전환할 수 있는지 단계적으로 판단하는 것이 중요하다고 느꼈습니다.

N2SF는 무엇을 통제해야 하는가에 대한 기준을 제공하고, 제로트러스트는 그 통제를 어떤 구조로 지속적으로 검증하고 실행할 것인가에 대한 방향을 제시한다고 볼 수 있습니다. 따라서 제로트러스트를 도입할 때에는 N2SF와 같은 기존 보안 프레임워크를 함께 참고하여, 조직의 현재 수준과 필요한 통제 항목을 기준으로 점진적으로 고도화하는 방식이 현실적인 접근이라고 생각합니다.

이번 정리를 통해 제로트러스트는 단순히 내부망을 신뢰하지 않는다는 개념에 그치지 않고, 신원, 디바이스, 네트워크, 애플리케이션, 데이터 전반을 지속적으로 검증하는 보안 운영 모델이라는 점을 확인할 수 있었습니다. 또한 N2SF와 같은 보안 기준과 연계하면 제로트러스트를 보다 체계적으로 도입하고 설명할 수 있다는 점에서, 향후 클라우드 보안 아키텍처를 설계할 때 중요한 기준으로 활용할 수 있을 것 같습니다.

출처

[Cloudtrail-guard] 02. 전체 아키텍처를 구성하며 고민했던 점

seobangwool — Tue, 9 Jun 2026 16:32:25 +0900

어떤 클라우드를 로그 분석 대상으로 삼을지 정해졌으니, 해당 클라우드 서비스를 통해 API 시퀀스를 처리하는 전체 아키텍처를 잡아두어야 했다.

CloudTrail 로그를 수집하고 분석하는 기능 자체는 어렵지 않게 설명할 수 있지만, 실제로 프로젝트 구조를 잡는 과정에서는 여러 고민이 있었다. 로그를 어디까지 저장할 것인지, Lambda 내부에서 어떤 로직을 처리할 것인지, 단일 이벤트 중심으로 볼 것인지 API 호출 흐름 중심으로 볼 것인지, 탐지 결과를 어떤 방식으로 남길 것인지 등을 고민하게 되었다.

이번 글에서는 현재 구상한 전체 아키텍처를 간단히 소개하고, 그 과정에서 고민했던 지점들을 중심으로 정리해보려고 한다.

전체 아키텍처 소개

현재까지 구상한 전체 아키텍처는 크게 세 단계로 나눌 수 있다.

로그 수집 단계
로그 처리 및 분석 단계
결과 저장 및 시각화 단계

로그 수집 단계에서는 AWS CloudTrail에서 발생한 이벤트 로그를 S3에 저장한다. 이후 로그 처리 및 분석 단계에서는 S3에 저장된 CloudTrail 로그를 Lambda가 읽어와 파싱하고, API 호출 시퀀스를 특정 기준으로 나눈 뒤 위협 유형을 매핑한다. 마지막으로 결과 저장 및 시각화 단계에서는 분석 결과를 별도의 저장소에 저장하고, 이후 Dashboard를 통해 탐지 결과를 확인할 수 있도록 구성한다.

조금 더 상세한 설명으로는, AWS CloudTrail에서 발생한 이벤트 로그는 S3에 저장된다. 이후 S3에 저장된 CloudTrail 로그를 Lambda가 읽어와 파싱하고, API 호출 시퀀스를 특정 기준으로 나눈 뒤 위협 유형을 매핑한다.

이때 각 API 이벤트와 위협 유형에는 기본 위험 점수를 부여하여 1차적으로 정량적인 위험도를 계산한다. 예를 들어 권한 변경, Access Key 생성, 로그 비활성화, 대량 조회와 같은 행위는 각각의 위험도에 따라 점수화할 수 있다. 이를 통해 어떤 이벤트나 시퀀스가 상대적으로 더 위험한지 대략적인 비교가 가능할 것이다.

다만 위험 점수만으로는 해당 행위가 실제 공격 흐름인지, 정상적인 운영 행위인지 판단하기 어려운 경우가 있다. 같은 API 호출이라도 호출 주체, source IP, 발생 시간, 이전에 수행된 API 흐름에 따라 의미가 달라질 수 있기 때문이다. 예를 들어 IAM 정책 변경이라는 행위 자체는 위험도가 높은 이벤트일 수 있지만, 정상 관리자가 업무 중 수행한 작업인지, 낯선 IP에서 악의적인 목적으로 수행된 권한 상승 시도인지는 추가적인 맥락을 함께 봐야 한다.

따라서 이 프로젝트에서는 위험 점수, API 호출 시퀀스, 위협 유형, 호출 주체, source IP, 시간 흐름 등의 정보를 AI 모델에 함께 입력하여 최종 위험 판단을 보완하는 구조를 고려하고 있다. 여기서 AI 모델은 위험 점수를 대체하는 것이 아니라, 점수 기반 판단에 맥락 해석과 설명 가능성을 더하는 최종 판단 보조 계층으로 사용된다.

AI 판단의 범위를 어디까지 지정할 것인가

전체 아키텍처를 구상하면서 가장 많이 고민했던 부분은 AI 모델을 어디까지 사용할 것인지였다.

처음에는 API 호출 시퀀스를 분리하는 과정부터 위험 점수 계산, 최종 위험 판단까지 AI 모델을 활용하는 구조도 생각했다. 하나의 모델이 아닌, 3개의 AI 모델을 별개로 학습시켜 순차적으로 적용시키는 것이다. CloudTrail 로그에는 다양한 필드가 포함되어 있고, API 호출 흐름도 상황에 따라 의미가 달라지기 때문에, AI 모델을 활용하면 복잡한 맥락을 더 유연하고 효율적으로 해석할 수 있을 것이라고 생각했기 때문이다.

예를 들어 AI 모델이 연속된 로그를 통으로 받은 뒤, 하나의 공격 흐름으로 볼 수 있는 구간을 판단하게 하는 것이다. 이후에는 다른 AI 모델이 특정 시퀀스가 정찰 행위인지, 권한 상승 시도인지, 데이터 접근 흐름인지 직접 분류하도록 구성하는 방식이다.

하지만 모든 과정을 AI 모델에 맡기는 방식에는 확실한 한계가 있다고 판단했다.

첫 번째는 비용 문제이다. CloudTrail 로그는 이벤트 단위로 지속적으로 쌓이는 데이터이기 때문에, 모든 로그나 모든 API 호출 시퀀스를 AI 모델 추론에 넣으면 호출 비용이 커질 수 있다. 특히 프로젝트가 단순 데모 수준을 넘어 로그 양이 늘어나는 구조를 고려한다면, AI 모델을 무분별하게 사용하는 것은 비용 측면에서 너무 큰 부담이 된다.

두 번째는 설명 가능성 문제이다. 위험 점수나 위협 유형 매핑을 모두 AI 모델에 맡기면, 왜 특정 이벤트가 위험하다고 판단되었는지 명확하게 설명하기 어려워질 수 있다. 보안 탐지에서는 위험하다는 결과도 물론 중요하지만, 어떤 API가 어떤 기준에 의해 위험하다고 판단되었는지 설명하는 것이 더 중요하다. 따라서 기본적인 위험 판단 기준은 규칙과 점수 기반으로 명확하게 남기는 것이 필요하다고 생각했다.

세 번째는 일관성 문제이다. 같은 유형의 API 호출에 대해 매번 다른 판단이 나오면 탐지 시스템으로 사용하기 어렵다. 명확하게 위험도가 높은 행위는 AI 모델의 해석에 의존하는 것 보다는 사전에 정의한 기준에 따라 점수를 부여하는 것이 더 안정적일 것이라고 판단했다.

이러한 이유로 현재는 규칙 기반 분석과 AI 모델의 역할을 분리하는 방향을 고려하고 있다. AI가 판단을 할 때 까지 어떤 단계를 거치는지 간략하게 적어보자면 다음과 같다.

우선 API 시퀀스 분리를 특정 규칙을 통해 1차적으로 처리한다. 위협 유형 매핑과 위험 점수 계산도 사전에 정의한 기준에 따라 먼저 수행한다. (이 규칙 설정에 대한 고민은 다음 챕터에서 다룰 예정)
이를 통해 기본적인 탐지 기준을 명확하게 유지하고, 비용이 많이 드는 AI 추론을 모든 이벤트에 적용하지 않도록 한다.

이후 AI 모델은 위험 점수, API 호출 시퀀스, 위협 유형, 호출 주체, source IP, 시간 흐름 등의 정보를 입력받아 최종 판단을 보완하는 역할로 사용한다. 즉, AI 모델은 위험 점수를 대체하거나 시퀀스 분리 전체를 담당하는 것이 아니라, 점수 기반 판단만으로 부족한 맥락 해석과 설명 가능성을 더하는 보조 판단 계층으로 활용한다.

Lambda 내부에 모든 분석 로직을 넣어도 되는가

다음으로 고민했던 부분은 Lambda 내부에 어느 정도의 로직을 넣을 것인지였다.

현재 아키텍처에서는 Lambda 내부에 CloudTrail Log Parser, API Sequence Builder, Threat Category Mapper, Risk Score Calculator, AI Model Inference를 배치하였다. 구조상으로는 S3에 저장된 CloudTrail 로그를 Lambda가 읽고, 분석한 뒤, 최종 결과를 생성하는 흐름이다.

이 방식의 장점은 구조가 단순하다는 점이다. 별도의 서버를 직접 운영하지 않아도 되고, CloudTrail 로그가 S3에 저장되는 시점에 Lambda를 트리거하면 자동으로 분석을 수행할 수 있다. 프로젝트 초기 단계에서 구현 범위가 명확하고, 전체 흐름을 데모로 보여주기에도 적합하다고 판단했다.

하지만 가장 큰 문제점은 유지보수가 어려워진다는 점이다. Lambda 하나에 너무 많은 로직이 들어가 있다 ...
로그 파싱, 시퀀스 생성, 위협 유형 매핑, 위험 점수 계산, AI 모델 추론은 각각 성격이 다른 작업이다. 이러한 것들을 하나의 함수 내부에 단순히 작성하면 코드가 복잡해지고, 이후 테스트나 유지보수가 어려워질 것이다.

또한 CloudTrail 로그의 양이 많아질 경우 Lambda 실행 시간, 메모리 사용량, 재시도 처리, 중복 이벤트 처리 문제도 고려해야 한다. 특히 AI 모델 추론까지 Lambda 내부에서 직접 수행한다면 실행 시간이 길어질 수 있고, 비용이나 성능 측면에서도 부담이 생길 수 있다.

따라서 현재의 구조가 완벽하다고 볼 수가 없다. Lambda 중심 구조는 로그 양이 증가하거나 분석 로직이 복잡해질수록 실행 시간, 비용, 유지보수 측면에서 한계가 생길 수 있다. 특히 AI 모델 추론까지 포함되기 때문에 Lambda가 단순 처리 계층을 넘어 과도한 책임을 가지게 될 수도 있다.

그럼에도 이러한 구조를 채택한 이유가 있다. 현재 단계에서 구조의 확장성보다는 전체 탐지 흐름을 명확하게 검증하는 것이 더 중요하다. 아직 프로젝트 초기 단계이기 때문에, 처음부터 복잡한 분산 구조를 설계하는 것은 오히려 독이 될 수 있다는 것을 뼈저리게 느껴왔다. 따라서, CloudTrail 로그가 수집되고, 파싱되고, 시퀀스로 구성되며, 위험 점수와 AI 판단을 거쳐 결과로 남는 전체 흐름을 끝까지 구현해보는 것이 우선이라고 생각한다.

현재 구조의 단점은 인지하고 있는 상태에서, 구현의 복잡도를 줄이고 초기 검증 가능성을 높이는 것에 더 높은 가치를 두고 있다. 이후 로그 규모가 커지거나 분석 로직이 복잡해질 경우에 Lambda 내부 로직을 단계별로 분리하거나, AI 추론 계층을 별도 서비스로 분리하는 방식으로 확장할 수 있을 것이다.

탐지 결과를 어떤 형태로 저장할 것인가

마지막으로 고민했던 부분은 탐지 결과를 어떤 형태로 저장할 것인지였다.

CloudTrail 원본 로그를 S3에 저장하는 것만으로는 탐지 시스템으로서의 의미가 부족하다. 원본 로그는 이후 분석의 근거가 되는 데이터이지만, 사용자가 바로 이해하기에는 정보가 너무 많고 복잡하다. 따라서 Lambda가 분석한 결과를 Dashboard에서 바로 활용할 수 있는 형태로 정리해서 저장할 필요가 있다고 판단했다.

처음에는 탐지 결과를 단순히 위험 점수와 위협 유형 정도만 저장하는 방식도 생각했다. 예를 들어 특정 API 시퀀스에 대해 High Risk, Privilege Escalation, Risk Score: 95와 같은 결과만 남기는 방식이다. 이 방식은 구조가 단순하지만, 실제 Dashboard에서 탐지 결과를 보여주기에는 정보가 부족하다고 느꼈다.

탐지 결과는 왜 위험하다고 판단했는지까지 함께 저장되어야 한다. Dashboard에서 전체 위험 점수, 위험 점수 추이, 주요 이상 행위, 이벤트 수, Alert 수, Principal 수, Source IP 수 등을 보여주려면 분석 결과가 구조화된 데이터 형태로 저장되어야 한다.

특히 Top Anomalies 영역을 구성하려면 탐지된 주체, 위험 API, 위험 점수, 탐지 사유가 필요하다. 예를 들어 backup-role에서 StopLogging이 발생했기 때문에 위험하다고 판단했다면, 어떤 주체가 어떤 API를 호출했고, 이 API가 어떤 위협 유형에 해당하며, 왜 높은 위험 점수를 받았는지 함께 남겨야 한다.

또한 Event Volume처럼 시간대별 이벤트 수를 보여주기 위해서는 각 이벤트의 발생 시간과 집계 가능한 형태의 데이터가 필요하다. Detection Center에서는 개별 Alert를 확인해야 하고, User Timeline에서는 특정 사용자의 API 호출 흐름을 시간 순서대로 보여줘야 한다. Attack Reconstruction에서는 여러 API 호출이 어떤 공격 흐름으로 이어졌는지 재구성할 수 있어야 한다.

이런 기능들을 고려하면 탐지 결과에는 최소한 다음과 같은 정보가 포함되어야 한다고 생각했다.

탐지 ID 또는 Alert ID
호출 주체
source IP
발생 시간
탐지된 API 이벤트 목록
API 호출 시퀀스
매핑된 위협 유형
위험 점수
AI 모델의 최종 판단 결과
위험하다고 판단한 근거
원본 CloudTrail 로그와 연결할 수 있는 식별 정보

이렇게 저장하면 Dashboard는 원본 CloudTrail 로그를 다시 분석하지 않아도 된다. 이미 분석이 끝난 결과를 읽어와 전체 위험 점수를 계산하고, 위험도 추이를 그리며, Top Anomalies와 Alert 목록을 구성할 수 있다. 또한 특정 사용자를 선택했을 때 Timeline을 보여주거나, 특정 Alert를 기준으로 공격 흐름을 재구성하는 것도 가능해진다.

결국 탐지 결과 저장소는 단순히 Lambda의 출력값을 임시로 보관하는 공간이 아니다. Dashboard가 탐지 결과를 해석하고 시각화하기 위한 기준 데이터이며, 이후 탐지 로직을 검증하고 개선하기 위한 기록이기도 하다.

따라서 원본 CloudTrail 로그와 탐지 결과는 분리해서 저장하는 것이 적절하다고 판단했다. 원본 로그는 변경되지 않는 근거 데이터로 남기고, 탐지 결과는 위험 판단, 점수, 시퀀스, 판단 근거를 포함한 분석 데이터로 저장하는 방식이 현재 아키텍처에 더 적합하다고 생각했다.

데모페이지 예시 일부

마무리하며

이번 아키텍처 설계 과정에서는 CloudTrail 로그를 어떤 관점에서 분석할 것인지에 대한 고민이 더 컸다.

처음에는 CloudTrail 로그를 수집하고 분석하는 구조만 잡으면 된다고 생각했지만, 실제로는 API 시퀀스를 어떤 기준으로 나눌 것인지, AI 모델을 어디까지 사용할 것인지, Lambda 내부에 어느 정도의 책임을 둘 것인지, 탐지 결과를 어떤 형태로 저장할 것인지까지 함께 고려해야 했다.

현재 구조는 완성된 최종 구조라기보다는, 프로젝트 초기 단계에서 전체 흐름의 틀을 잡는 설계도에 가깝다. 진행하면서 부족한 부분이 있거나 개선할 점이 있다면 수정이 많이 일어날지도 모른다. 그럼에도 이번 설계를 통해 CloudTrail Guard가 위험 행위를 해석하고 탐지하고 결과를 설명하는 구조를 더 명확하게 할 수 있었다.

앞으로는 실제 샘플 데이터를 만져가며 API 시퀀스 분리 기준과 위험 점수 산정 방식 등을 구체화해볼 예정이다.

[Cloudtrail-guard] 01. AWS Cloudtrail을 선택한 이유

seobangwool — Tue, 9 Jun 2026 15:18:54 +0900

CloudTrail Guard에서 가장 먼저 결정해야 했던 것은 “어떤 클라우드를 로그 분석 대상으로 삼을 것인가”였다.

처음부터 AWS만을 전제로 두지는 않았다. GCP의 Cloud Audit Logs는 시스템 이벤트를 깔끔하게 기록해주며, Azure의 Activity Log와 Entra ID 로그 역시 가시성 측면에서 매우 강력한 추적 기능을 제공합니다. 즉, 벤더사의 로깅 기능 자체만 놓고 보면 어느 것을 선택해도 보안 분석 관점에서 충분히 의미 있는 데이터를 얻을 수 있을 것 같았다.

이에 따라 기능의 유무보다는 다른 기준이 필요하다는 생각이 들었다.
따라서 데이터 확보와 연구 생태계의 성숙도를 중심으로 4가지 기준을 세워서 비교를 해보았다.

클라우드 로그를 선택할 때 고려한 기준

데이터 전처리 용이성: 로그를 정규화하고 탐지 모델의 피처로 변환하기 위한 선행 연구가 많은가?
오픈소스 생태계 성숙도: 구체적인 공격 페이로드와 탐지 룰 레퍼런스가 충분한가?
공격 시뮬레이션 접근성: 양질의 이상 행위 및 침해 데이터를 직접 생성하고 검증할 수 있는가?
프로젝트 완수 가능성: 3인 팀 규모 내에서 아키텍처 구성 및 파이프라인 검증을 깊이 있게 완수할 수 있는가?

이러한 엔지니어링 관점의 기준들을 적용한 결과, 최종적으로 AWS CloudTrail를 선택하기로 했다.

1. 사실상의 표준이 된 로그 구조 (기준 1)

AWS의 모든 리소스 통제는 철저하게 API 기반으로 이루어진다. 콘솔 조작, CLI 명령, SDK 호출 등 모든 행위가 CloudTrail에 일관된 JSON 포맷으로 기록된다. 이는 "사용자 행위 → API 호출 → 로그 이벤트"로 이어지는 매핑을 직관적으로 만들어준다. 수많은 상용 SIEM 솔루션과 오픈소스 보안 도구들이 이 구조를 기본으로 다루고 있기 때문에, 수집된 로그를 파싱하고 기계학습 모델을 위한 데이터로 전처리하는 과정에서 참고할 수 있는 레퍼런스가 타 클라우드 대비 월등히 많다.

2. 압도적인 공격 시뮬레이션 및 위협 모델링 생태계 (기준2, 3)

AWS는 클라우드 시장 점유율이 가장 높기 때문에, 그만큼 보안 연구원들의 주요한 타겟이 되었다. 이는 방어자 입장에서 엄청난 이점이다. Pacu, CloudGoat, Stratus Red Team 등 AWS에 특화된 오픈소스 공격 시뮬레이션 도구들이 존재한다. 이를 활용하면 실제 침해 사고와 동일한 시나리오를 재현하고, 이 과정에서 발생하는 공격 데이터를 직접 수집할 수도 있게 된다. 그럼 우리가 설계한 모델의 신뢰성을 확실하게 검증할 수 있을 것이다.

3. 프로젝트 범위와 연구 목표에 가장 적합한 선택 (기준 4)

GCP와 Azure 역시 감사 로그와 보안 분석 기능을 제공하지만, 이번 프로젝트의 목표는 API 호출 시퀀스를 기반으로 이상 행위를 탐지하는 모델을 설계하는 것이다. 따라서 하나의 플랫폼에 집중하여 데이터 수집, 시퀀스 생성, 라벨링, 모델 학습, 성능 평가까지의 전 과정을 깊이 있게 수행하는 것이 더 중요하다고 판단하였다.

AWS는 CloudTrail을 중심으로 한 연구 사례, 공격 시나리오, 탐지 레퍼런스, 공개 자료가 가장 풍부한 환경 중 하나이다. 또한 IAM, S3, EC2 등 주요 서비스의 행위가 CloudTrail에 일관된 형태로 기록되기 때문에 공격 흐름을 시퀀스 단위로 분석하기 용이하다. 제한된 인원과 기간 내에서 탐지 모델과 전체 파이프라인을 완성도 있게 검증하기 위해서는, 가장 많은 참고 자료와 검증 수단을 제공하는 AWS가 현실적인 선택이라고 판단하였다.

마무리하며

결론적으로 AWS를 선택한 것은, 가진 리소스 안에서 가장 풍부한 공격 데이터를 확보할 수 있고, 가장 신뢰성 있는 위협 탐지 시나리오를 검증하기에 최적이라 판단했기 때문이다.

물론 GCP나 Azure 역시 충분히 훌륭한 로그 환경과 보안 분석 기능을 제공한다. 다만 이번 프로젝트의 목적은 API 호출을 시퀀스로 묶어서 탐지한다는 아이디어를 실제로 구현하고 검증하는 것이다. 따라서 가장 많은 레퍼런스와 연구 사례, 공격 시뮬레이션 환경을 제공하는 AWS로 진행하기로 결정하였다.

[Cloudtrail-guard] 00. 프로젝트를 시작하게 된 이유

seobangwool — Tue, 9 Jun 2026 13:45:45 +0900

이 프로젝트를 시작하게 된 이유

kisia에서 운영하는 클라우드 보안 수업을 수강하다가,
클라우드 서비스가 API 중심 아키텍처로 동작한다는 점에 관심을 갖게 되었다. 특히 AWS 환경에서는 사용자의 대부분의 행위가 API 호출 형태로 기록되므로, 이러한 API들을 하나의 흐름으로 분석할 수 있다면 비정상 접근이나 위험 행위 등을 탐지할 수 있지 않을까? 라는 궁금증이 생겼다.

총 3인으로 진행하는 프로젝트이고, 현재 한 달간 진행이 되었다.
아직 프로젝트 초기이지만, 데이터 수집과 탐지 기준 설정 등 여러 시행착오를 겪고 있다. 지금까지 마주한 문제점과 기술 선정 이유와 같이 프로젝트 진행에 있었던 고민의 흔적을 남겨두면 추후 보완할 때 도움이 될 것 같아서 작성하게 되었다.

간단하게 프로젝트에 대해 설명하고, 다음 글부터 흔적을 남길 수 있도록 해야겠다.

프로젝트 소개

CloudTrail Guard는 AWS CloudTrail 로그를 분석하여, 사용자의 API 호출 흐름에서 이상 행위와 공격 가능성을 탐지하는 클라우드 보안 프로젝트이다.

AWS 환경에서는 콘솔 조작을 포함하여 대부분의 행위가 API 호출 형태로 기록된다. 이 프로젝트는 이러한 API 호출을 단일 로그로만 판단하지 않고, 여러 로그를 하나의 시퀀스로 묶어서 위험 행위를 탐지할 수 있는 AI를 만드는 것을 1차 목표로 한다. 이후에는 생성한 AI와 기존 LLM 모델과 성능을 비교해보고, 로그 수집부터 시퀀스 생성, 위험도 분류, 대시보드 시각화까지 이어지는 전체 파이프라인에 병합하는 것을 목표로 한다.

깃허브 링크

https://github.com/CloudTrail-lab/cloudtrail-guard

[eBPF Advanced] 05. LSM을 사용한 보안 탐지 & 방어

seobangwool — Wed, 3 Jun 2026 16:25:31 +0900

LSM (Linux System Modules)

LSM은 Linux 2.6 부터 리눅스 커널의 공식 보안 프레임 워크로 사용되어왔다. 리눅스 5.7에서 BPF LSM이 도입되면서 시스템 개발자는 함수 수준의 보안 검사를 자유롭게 구현할 수 있게 됐다. LSM은 커널이 특정 자원에 접근하기 전에 보안 훅을 심어두고 이를 통해 보안 모듈이 커널 동작을 허용할지 판단할 수 있도록 만들었다.

LSM에서 지원하는 훅 지점의 예시로는 아래와 같다.

파일 열기, 생성, 삭제 및 이동
파일 시스템 마운트
작업 및 프로세스에 대한 운영
소켓 관련 작업(소켓 생성, 바인딩, 메시지 송수신 등)

더 많은 훅 포인트는 아래 링크에서 확인할 수 있다.

https://github.com/torvalds/linux/blob/master/include/linux/lsm_hook_defs.h

BPF LSM 가용성 확인

커널이 5.7 이상인지, BPF LSM 지원이 활성화되어 있는지 확인을 해주어야한다.

$ uname -r
6.8.0-90-generic

$ cat /boot/config-$(uname -r) | grep BPF_LSM
CONFIG_BPF_LSM=y

출력에서 커널의 버전과 LSM 지원을 확인했다면 다음 명령어를 통해 bpf 옵션이 포함되어 있는지 확인할 수 있다.

$ cat /sys/kernel/security/lsm
lockdown,capability,landlock,yama,apparmor

만약 위와 같이 출력결과에 bpf가 포함되지 않는다면 /etc/default/grub을 수정해준다. 이전 결과에 bpf를 추가하여 적어준다.

GRUB_CMDLINE_LINUX="lsm=lockdown,capability,landlock,yama,apparmor,bpf"

그리고 grub 설정을 업데이트를 하고 재시작해주면 된다 (업데이트 명령어는 시스템에 따라 다를 수 있음)

$ sudo update-grub
$ sudo reboot

실습 코드

// lsm-connect.bpf.c
#include "vmlinux.h"
#include <bpf/bpf_core_read.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>

char LICENSE[] SEC("license") = "GPL";

#define EPERM 1
#define AF_INET 2

const __u32 blockme = 16843009; // 1.1.1.1 -> int

SEC("lsm/socket_connect")
int BPF_PROG(restrict_connect, struct socket *sock, struct sockaddr *address, int addrlen, int ret)
{
    // Satisfying "cannot override a denial" rule
    if (ret != 0)
    {
        return ret;
    }

    // Only IPv4 in this example
    if (address->sa_family != AF_INET)
    {
        return 0;
    }

    // Cast the address to an IPv4 socket address
    struct sockaddr_in *addr = (struct sockaddr_in *)address;

    // Where do you want to go?
    __u32 dest = addr->sin_addr.s_addr;
    bpf_printk("lsm: found connect to %d", dest);

    if (dest == blockme)
    {
        bpf_printk("lsm: blocking %d", dest);
        return -EPERM;
    }
    return 0;
}

// lsm-connect.bpf.c
#include "vmlinux.h"
#include <bpf/bpf_core_read.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>

char LICENSE[] SEC("license") = "GPL";

#define EPERM 1
#define AF_INET 2

const __u32 blockme = 16843009; // 1.1.1.1 -> int

SEC("lsm/socket_connect")
int BPF_PROG(restrict_connect, struct socket *sock, struct sockaddr *address, int addrlen, int ret)
{
    // Satisfying "cannot override a denial" rule
    if (ret != 0)
    {
        return ret;
    }

    // Only IPv4 in this example
    if (address->sa_family != AF_INET)
    {
        return 0;
    }

    // Cast the address to an IPv4 socket address
    struct sockaddr_in *addr = (struct sockaddr_in *)address;

    // Where do you want to go?
    __u32 dest = addr->sin_addr.s_addr;
    bpf_printk("lsm: found connect to %d", dest);

    if (dest == blockme)
    {
        bpf_printk("lsm: blocking %d", dest);
        return -EPERM;
    }
    return 0;
}

코드 해석

이번 코드는 매우 간단하다.
lsm 이 제공하는 socket_connect 훅에 코드를 붙인 구조이다.
데이터를 전송할 맵도 별도로 존재하지 않고 훅에 붙인 코드에서 차단되는 코드인지 확인하고 차단 대상이라면 연결을 거부하는 방식이다.

ret을 먼저 검사하는 이유는 다른 LSM이 거부한 요청을 다시 허용하지 않기 위해서이다. 거부했다면 그대로 반환한다. 그리고 ipv4만 처리하도록 하고 ipv6 등 다른 주소 패밀리에 속한다면 검사하지 않고 그대로 허용한다.

목적지 ip는 dest로 저장하고 이 값을 이전에 설정한 차단ip인 blockme와 비교한다. 추가하고 싶은 ip가 있다면 여기를 수정하면 될 것 같다.

요약하자만 connect 호출 시점에 시작되는 프로그램이고 차단 대상 IP인지 검사하고 SYN 패킷이 전송되기 전에 시스템콜 단계에서 연결을 거부한다.

코드 실행 & 컴파일

코드를 컴파일 하기 위해서 유저 코드가 있어야하는데 따로 코드가 없어서 간단하게 만들어봤다.

lsm-connect.c

#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
#include <arpa/inet.h>
#include <bpf/libbpf.h>
#include "lsm-connect.skel.h"

static void print_block_log(const char *line)
{
    const char *key = "lsm: blocking ";
    const char *p = strstr(line, key);
    if (!p)
        return;

    unsigned long v = strtoul(p + strlen(key), NULL, 10);

    struct in_addr addr = {
        .s_addr = (uint32_t)v
    };

    char ip[INET_ADDRSTRLEN];
    if (!inet_ntop(AF_INET, &addr, ip, sizeof(ip)))
        snprintf(ip, sizeof(ip), "unknown");

    printf("[LSM] BLOCKED connect() to %s\n", ip);
}

int main(void)
{
    struct lsm_connect_bpf *skel;
    FILE *tp;
    char line[4096];

    skel = lsm_connect_bpf__open();
    if (!skel)
        return 1;

    if (lsm_connect_bpf__load(skel))
        return 1;

    if (lsm_connect_bpf__attach(skel))
        return 1;

    printf("[LSM] attached\n");

    tp = fopen("/sys/kernel/debug/tracing/trace_pipe", "r");
    if (!tp)
        return 1;

    while (fgets(line, sizeof(line), tp)) {
        if (strstr(line, "lsm: blocking"))
            print_block_log(line);
    }

    lsm_connect_bpf__destroy(skel);
    return 0;
}

그리고 실행시킬 sh 코드도 같이 만들었다.
추가로 이전 시간에 사용했던 tcpstates를 활용해서 보낸 패킷을 보다 자세하게 확인할 수 있도록 만들었다.

#!/usr/bin/env bash
set -euo pipefail


sudo ./tcpstates &
TCPSTATES_PID=$!
sleep 1


echo "=============================="
echo "[LSM X - google.com]"
echo "=============================="

curl -4 -sS -o /dev/null --connect-timeout 2 https://google.com || true
sleep 1


echo "=============================="
echo "[LSM X - 1.1.1.1]"
echo "=============================="

curl -4 -sS -o /dev/null --connect-timeout 2 https://1.1.1.1 || true
sleep 1


echo "=============================="
echo "[ATTACH LSM]"
echo "[LSM O - google.com]"
echo "=============================="


sudo ./lsm-connect &
LSM_PID=$!
sleep 1


curl -4 -sS -o /dev/null --connect-timeout 2 https://google.com || true
sleep 1


echo "=============================="
echo "[LSM O - 1.1.1.1]"
echo "=============================="

curl -4 -sS -o /dev/null --connect-timeout 2 https://1.1.1.1 || true
sleep 1


echo "=============================="
echo "[LSM O - one.one.one.one]"
echo "=============================="

curl -4 -sS -o /dev/null --connect-timeout 2 https://one.one.one.one/ || true
sleep 1


sudo kill $LSM_PID
wait $LSM_PID 2>/dev/null || true

sudo kill $TCPSTATES_PID
wait $TCPSTATES_PID 2>/dev/null || true

1.1.1.1 주소에 대해서는 도메인 주소로도 실험을 해보기 위해서 ebpf에 코드도 일부 수정해줬다.
1.1.1.1은 one.one.one.one 주소를 가지는데 이 주소는 A 레코드가 2개이므로 두 주소에 대해 차단해줬다.

$ dig one.one.one.one
;; ANSWER SECTION:
one.one.one.one.        65003   IN      A       1.1.1.1
one.one.one.one.        65003   IN      A       1.0.0.1

// 생략 
const __u32 block1 = 16843009; // 1.1.1.1 
const __u32 block2 = 16777217; // 1.0.0.1 추가 

SEC("lsm/socket_connect")
int BPF_PROG(restrict_connect, struct socket *sock, struct sockaddr *address, int addrlen, int ret)
{
    // 생략

    if (dest == block1 || dest == block2)
    {
        bpf_printk("lsm: blocking %d", dest);
        return -EPERM;
    }
    return 0;
}

오브젝트 파일을 만들어주고,

clang -O2 -g -target bpf -D__TARGET_ARCH_x86 -I. -c lsm-connect.bpf.c -o lsm-connect.bpf.o

스켈레톤 헤더파일도 만들어주고,

bpftool gen skeleton lsm-connect.bpf.o > lsm-connect.skel.h

유저 프로그램을 빌드해준다.

cc -O2 -g lsm-connect.c -o lsm-connect -I. -lbpf

그리고 실행시켜줬다.

sudo ./runall.sh

실행 결과

실행결과를 정리하면 아래와 같다.

[LSM X - google.com]
- 상황 : LSM이 적용되지 않은 상태에서 google.com으로 연결을 시도.
- 결과 : TCP 동작이 잘 보인다.

[LSM X - 1.1.1.1]
- 상황 : LSM이 적용되지 않은 상태에서 1.1.1.1로 연결을 시도하였다.
- 결과 : google.com과 동일하게 정상적으로 TCP 연결이 됐다.

[ATTACH LSM]
[LSM O - google.com]
- 상황 : LSM이 적용된 상태에서 google.com으로 연결을 시도하였다.
- 결과 : 차단 대상이 아닌 연결에 대해서는 동일하게 잘 연결이 된다.
[LSM O - 1.1.1.1]
- 상황 : LSM이 적용된 상태에서 차단 대상 IP인 1.1.1.1로 연결을 시도하였다.
- 결과 : connect() 단계에서 즉시 연결이 거부되었다.
  - tcpstates 상에서는 SYN_SENT 상태가 거의 또는 전혀 관찰되지 않았다.
  - 즉, LSM socket_connect 훅은 TCP 3-way handshake 이전에 실행되는 것으로 이해할 수 있다.
  - SYN 패킷 자체가 네트워크로 전송되지 않는다. TCP 스택에 진입하기 전에 시스템 콜 단계에서 연결이 차단된다는 것이다.
[LSM O - one.one.one.one]
- 상황 : one.one.one.one 도메인으로 연결을 시도하였다.
- 결과 : DNS 결과로 여러 IPv4 주소가 반환되었고, 각 IP에 대해 순차적으로 connect()가 시도되었다.
  - 차단 목록에 포함된 모든 IP에 대해 LSM 차단이 발생하였다.
  - IP 기반 차단은 특정 도메인에 대해 모든 IP를 차단하지 않으면 우회가 가능하다.

References

Full practice sequence : https://github.com/eunomia-bpf/bpf-developer-tutorial/blob/main/src/16-memleak/README.md
More hook points : https://github.com/torvalds/linux/blob/master/include/linux/lsm_hook_defs.h

[eBPF Advanced] 04. TCP 연결 상태와 TCP RTT 기록

seobangwool — Wed, 3 Jun 2026 16:25:14 +0900

개요

전 실습인 TCP 연결 지연 확인에서 TCP connect를 호출한 시점부터 연결이 완료되는 시점까지 시간을 확인했다. 이번 실습에서는 연결이 성립된 이후에 데이터의 왕복 지연 시간을 기록한다. connent가 끝난 뒤에 내트워크는 혼잡/지연 등 여러 요인으로 RTT가 변하게되는데, 이번 실습을 통해 어느 state에서 얼마나 걸렸는지 확인할 수 있는 방법을 알아본다.

tcpstates

tcprtt와 tcpstates 도구를 사용하면 네트워크 문제를 더 쉽게 찾을 수 있도록 TCP 연결의 왕복 시간을 모니터링하고 네트워크 품질을 평가하여 문제를 식별하는데 도움을 줄 수 있다.

TCP State transition

실습 코드

// SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)
/* Copyright (c) 2021 Hengqi Chen */
#include <vmlinux.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
#include <bpf/bpf_core_read.h>
#include "tcpstates.h"

#define MAX_ENTRIES    10240
#define AF_INET        2
#define AF_INET6    10

const volatile bool filter_by_sport = false;
const volatile bool filter_by_dport = false;
const volatile short target_family = 0;

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, MAX_ENTRIES);
    __type(key, __u16);
    __type(value, __u16);
} sports SEC(".maps");

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, MAX_ENTRIES);
    __type(key, __u16);
    __type(value, __u16);
} dports SEC(".maps");

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, MAX_ENTRIES);
    __type(key, struct sock *);
    __type(value, __u64);
} timestamps SEC(".maps");

struct {
    __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY);
    __uint(key_size, sizeof(__u32));
    __uint(value_size, sizeof(__u32));
} events SEC(".maps");

SEC("tracepoint/sock/inet_sock_set_state")
int handle_set_state(struct trace_event_raw_inet_sock_set_state *ctx)
{
    struct sock *sk = (struct sock *)ctx->skaddr;
    __u16 family = ctx->family;
    __u16 sport = ctx->sport;
    __u16 dport = ctx->dport;
    __u64 *tsp, delta_us, ts;
    struct event event = {};

    if (ctx->protocol != IPPROTO_TCP)
        return 0;

    if (target_family && target_family != family)
        return 0;

    if (filter_by_sport && !bpf_map_lookup_elem(&sports, &sport))
        return 0;

    if (filter_by_dport && !bpf_map_lookup_elem(&dports, &dport))
        return 0;

    tsp = bpf_map_lookup_elem(&timestamps, &sk);
    ts = bpf_ktime_get_ns();
    if (!tsp)
        delta_us = 0;
    else
        delta_us = (ts - *tsp) / 1000;

    event.skaddr = (__u64)sk;
    event.ts_us = ts / 1000;
    event.delta_us = delta_us;
    event.pid = bpf_get_current_pid_tgid() >> 32;
    event.oldstate = ctx->oldstate;
    event.newstate = ctx->newstate;
    event.family = family;
    event.sport = sport;
    event.dport = dport;
    bpf_get_current_comm(&event.task, sizeof(event.task));

    if (family == AF_INET) {
        bpf_probe_read_kernel(&event.saddr, sizeof(event.saddr), &sk->__sk_common.skc_rcv_saddr);
        bpf_probe_read_kernel(&event.daddr, sizeof(event.daddr), &sk->__sk_common.skc_daddr);
    } else { /* family == AF_INET6 */
        bpf_probe_read_kernel(&event.saddr, sizeof(event.saddr), &sk->__sk_common.skc_v6_rcv_saddr.in6_u.u6_addr32);
        bpf_probe_read_kernel(&event.daddr, sizeof(event.daddr), &sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32);
    }

    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &event, sizeof(event));

    if (ctx->newstate == TCP_CLOSE)
        bpf_map_delete_elem(&timestamps, &sk);
    else
        bpf_map_update_elem(&timestamps, &sk, &ts, BPF_ANY);

    return 0;
}

char LICENSE[] SEC("license") = "Dual BSD/GPL";

코드 해석

우선 맵 부터 확인을 해보면 네개의 맵을 확인할 수 있다.
sports 맵과 dports 맵은 각각 소스 포트와 목적지 포트를 키로 저장하고 value는 각 포트 번호가 필터링 대상인지 판별하기 위한 플래그로 사용된다.
timestamps 맵은 소켓 포인터를 키로 가지며 소켓 단위로 어떠한 시점을 저장하기 위해 사용된다. 이 값들을 통해 각 state에서 걸린 시간을 계산하는데 쓰일 것이다.
events 맵은 사용자 공간으로 이벤트를 전달하기 위해 사용된다. 타입 또한 BPF_MAP_TYPE_PERF_EVENT_ARRAY이며 ebpf 코드에서 수집한 정보를 유저공간으로 전달하는데 사용될 것이다.

이제 inet_sock_set_state 지점에 붙여진 함수가 나온다. inet_sock_set_state는 커널이 tcp 소켓의 state를 변경할 때 발생하는 tp이다. 즉 상태가 변경되는 지점에서 정확히 관측이 가능하다는 의미이다.

event 구조체를 채우는 부분을 보면 skaddr로 소켓의 주소값, ts_us로 이벤트 발생시각, delta_us로 직전 상태전이 이후부터 지난 시간, pid, oldstate/newstate로 tcp의 상태가 어떻게 변했는지, sport/dport로 포트 정보를 저장했다.

이후로 ipv4와 ipv6에 따라 각각 다르게 주소를 읽어주고 유저공간으로 event를 전송한다.

코드 컴파일

오브젝트 파일을 만들어주고,

clang -O2 -g -target bpf -D__TARGET_ARCH_x86 -I. -c tcpstates.bpf.c -o tcpstates.bpf.o

스켈레톤 헤더파일도 만들어주고,

bpftool gen skeleton tcpstates.bpf.o > tcpstates.skel.h

유저 프로그램을 빌드해준다.

cc -O2 -g tcpstates.c -o tcpstates -I. -lbpf -lelf -lz

이제 실행을 해주면된다. 간단하게 sh 코드를 작성해봤다.
이전 실습에서는 백그라운드에서 실행한 후 kill 해주는 부분이 없어서 이번에 추가해봤다.

#!/usr/bin/env bash
set -euo pipefail

sudo ./tcpstates &
TCPSTATES_PID=$!
sleep 3

echo
echo "=============================="
echo "[HTTP CONNECTION]"
echo "=============================="

curl -4 -s http://1.1.1.1 > /dev/null || true
sleep 2

echo
echo "=============================="
echo "[HTTPS CONNECTION]"
echo "=============================="

curl -4 -s https://www.google.com > /dev/null || true
sleep 2

echo
echo "=============================="
echo "[LONG ESTABLISHED STATE]"
echo "=============================="

curl -4 -s --limit-rate 30k https://www.google.com > /dev/null || true
sleep 2

echo
echo "=============================="
echo "[CONNECTION TIMEOUT]"
echo "=============================="

curl -4 -s --connect-timeout 1 http://203.0.113.1 > /dev/null || true
sleep 2


sudo kill $TCPSTATES_PID
wait $TCPSTATES_PID 2>/dev/null || true

우선 가장 기분적인 http 연결을 관측해보고, 다음으로 https도 관측해보자.
그리고 --limit-rate 30k를 사용하여 데이터를 천천히 보내서 지속시간이 어떻게 변하는지도 관측해보고 마지막으로 타임아웃 상황일 때 어떻게 되는지도 알아보자. 타임아웃은 203.0.113.1 대역으로 실제 존재하지 않는 테스트용 주소이다 (TEST-NET-3)

실행 결과

위 결과를 해석하면 아래와 같다.

[HTTP CONNECTION]
- 흐름 : CLOSE - SYN_SENT - ESTABLISHED - FIN_WAIT1 - FIN_WAIT2 - CLOSE
- 의미 : 매우 빠른 TCP 수명 주기이다. 서버 응답(5ms)과 데이터 전송(6ms) 모두 즉각적으로 이루어졌다.
[HTTPS CONNECTION]
- 흐름 : CLOSE - SYN_SENT - ESTABLISHED - FIN_WAIT1 - FIN_WAIT2 - CLOSE
- 의미 : TLS 암호화 통신으로 오버헤드가 있음을 보여준다. TCP 연결은 성공했지만, 내부적으로 암호화 키를 교환하느라 ESTABLISHED 상태 유지 시간이 HTTP 대비 약 45배(269ms) 증가한 것을 확인할 수 있다.
[LONG ESTABLISHED STATE]
- 흐름 : CLOSE - SYN_SENT - ESTABLISHED - FIN_WAIT1 - FIN_WAIT2 - CLOSE
- 의미 : 데이터 전송 속도가 느릴수록 소켓 점유 시간이 길다는 것을 알 수 있다. 인위적인 속도 제한(30k)을 통해 ESTABLISHED 상태가 1.5초(1546ms) 넘게 유지되었으며, 이는 네트워크 대역폭이 좁을수록 서버의 연결 자원이 더 오래 소모됨을 뜻한다.
[CONNECTION TIMEOUT]
- 흐름 : CLOSE - SYN_SENT - CLOSE
- 의미 : 응답이 없는 상황에서의 자원을 회수하는 과정을 보여준다. 서버의 응답이 없으니 curl에 설정된 1초 타임아웃에 맞춰 커널이 SYN_SENT 상태에서 약 1002ms를 대기한 후, 다음 단계로 넘어가지 않고 즉시 자원을 해제(CLOSE)하는 것을 확인할 수 있다.

References

Full practice sequence : https://github.com/eunomia-bpf/bpf-developer-tutorial/blob/main/src/16-memleak/README.md

[eBPF Advanced] 03. TCP 연결 지연 확인

seobangwool — Wed, 3 Jun 2026 16:25:00 +0900

TCP 연결 지연

개발을 할 때 데이터베이스를 호출하거나, 원격 호출을 수행하는 경우가 종종 나타난다. 이럴 때 구현은 보통 TCP 프로토콜을 기반으로 한다. 이는 안정적인 연결과 오류가 일어날 때 재전송, 혼잡 제어 등의 장점을 가지고 있기 때문이다. 하지만 TCP는 이러한 장점을 가지지만 UDP 보다 연결 지연이 크다는 단점이 있다. TCP 연결 지연을 분석하면 네트워크의 성능 분석과 문제 해결에 유용하다.

tcpconnlat

tcpconnlat 도구는 TCP 연결을 수행하는 connect()와 같은 커널 함수를 추적하고, 연결지연 시간에 해당하는 SYN 패킷 전송부터 응답 패킷 수신까지의 시간을 측정하고 표시할 수 있다.

3-Way Handshake
TCP 연결은 일반적으로 3방향 핸드셰이킹 과정을 거치게 된다. 순서는 아래와 같다.

Client -> Server : SYN 전송
- 클라이언트는 connect() 시스템 호출을 통해 TCp 연결을 요청한다. 이 과정에서 커널 진입, 소프트웨어 interrupt 처리 등으로 CPU 시간 비용이 발생한다.
Server -> Client : SYN 패킷 처리 및 SYN/ACK 응답
- 서버 측 커널에서 SYN 패킷을 수신하고 이를 listen queue에 등록한 뒤 SYN/ACK 패킷을 생성하여 응답한다.
Client -> Server : SYN/ACK 처리 및 ACK 전송
- 클라이언트 측 커널은 STN/ACK 패킷을 수신하여 상태를 갱신한 뒤 최종 확인을 위한 ACK 패킷을 전송
- Server 측에서는 ACK 응답을 수신하고 해당 연결을 listen queue에서 established queue로 이동시켜 연결을 확정
- 이때 Server 측 사용자 프로세스는 accept() 시스템 콜로 대기 중이었다면 커널은 이를 깨워 확정된 연결을 반환한다. 이 과정에서 context switch로 인한 CPU 비용이 발생한다

전체 순서도는 아래와 같다.

tcpconnlat ebpf 구현

TCP 연결 설정 과정을 이해하기 위해 linux 커널에서 TCP 연결 처리에 사용하는 두 가지 큐를 알아야한다.

Listen Queue (SYN Queue) : 3-way handshake가 진행 중인 연결을 저장하는 큐
Established Queue (Accept Queue) : 3-way handshake가 완료된 연결을 저장하는 큐

tcpconnlat 구현은 커널 공간과 유저 공간으로 두 부분으로 나눌 수 있다. 여기서 중요한 trace point는 아래와 같다.

tcp_v4_connect, tcp_v6_connect, tcp_rcv_state_process

이 tp는 커널의 TCP/IP 네트워크 스택에 존재한다.

SEC("kprobe/tcp_v4_connect")
int BPF_KPROBE(tcp_v4_connect, struct sock *sk)
{
 return trace_connect(sk);
}

SEC("kprobe/tcp_v6_connect")
int BPF_KPROBE(tcp_v6_connect, struct sock *sk)
{
  return trace_connect(sk);
}

SEC("kprobe/tcp_rcv_state_process")
int BPF_KPROBE(tcp_rcv_state_process, struct sock *sk)
{
  return handle_tcp_rcv_state_process(ctx, sk);
}

실제 코드에서 언급한 지점에 kprobe를 통해 tcp_v4_connect, tcp_v6_connect 각각에 해당하는 IPv4와 IPv6 연결이 초기화될 때 마다 trace_connect()이라는 함수가 실행된다. tcp_rcv_state_process에는 handle_tcp_rcv_state_process()라는 함수를 붙인 걸 확인해 볼 수 있는데 이는 커널에서 TCP 연결 상태가 변결될 때 트리거되는 것이다.

실습 코드

tcpconnlat.bpf.c

// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2020 Wenbo Zhang
#include <vmlinux.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_core_read.h>
#include <bpf/bpf_tracing.h>
#include "tcpconnlat.h"

#define AF_INET    2
#define AF_INET6   10

const volatile __u64 targ_min_us = 0;
const volatile pid_t targ_tgid = 0;

struct piddata {
    char comm[TASK_COMM_LEN];
    u64 ts;
    u32 tgid;
};

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 4096);
    __type(key, struct sock *);
    __type(value, struct piddata);
} start SEC(".maps");

struct {
    __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY);
    __uint(key_size, sizeof(u32));
    __uint(value_size, sizeof(u32));
} events SEC(".maps");

static int trace_connect(struct sock *sk)
{
    u32 tgid = bpf_get_current_pid_tgid() >> 32;
    struct piddata piddata = {};

    if (targ_tgid && targ_tgid != tgid)
        return 0;

    bpf_get_current_comm(&piddata.comm, sizeof(piddata.comm));
    piddata.ts = bpf_ktime_get_ns();
    piddata.tgid = tgid;
    bpf_map_update_elem(&start, &sk, &piddata, 0);
    return 0;
}

static int handle_tcp_rcv_state_process(void *ctx, struct sock *sk)
{
    struct piddata *piddatap;
    struct event event = {};
    s64 delta;
    u64 ts;

    if (BPF_CORE_READ(sk, __sk_common.skc_state) != TCP_SYN_SENT)
        return 0;

    piddatap = bpf_map_lookup_elem(&start, &sk);
    if (!piddatap)
        return 0;

    ts = bpf_ktime_get_ns();
    delta = (s64)(ts - piddatap->ts);
    if (delta < 0)
        goto cleanup;

    event.delta_us = delta / 1000U;
    if (targ_min_us && event.delta_us < targ_min_us)
        goto cleanup;
    __builtin_memcpy(&event.comm, piddatap->comm,
            sizeof(event.comm));
    event.ts_us = ts / 1000;
    event.tgid = piddatap->tgid;
    event.lport = BPF_CORE_READ(sk, __sk_common.skc_num);
    event.dport = BPF_CORE_READ(sk, __sk_common.skc_dport);
    event.af = BPF_CORE_READ(sk, __sk_common.skc_family);
    if (event.af == AF_INET) {
        event.saddr_v4 = BPF_CORE_READ(sk, __sk_common.skc_rcv_saddr);
        event.daddr_v4 = BPF_CORE_READ(sk, __sk_common.skc_daddr);
    } else {
        BPF_CORE_READ_INTO(&event.saddr_v6, sk,
                __sk_common.skc_v6_rcv_saddr.in6_u.u6_addr32);
        BPF_CORE_READ_INTO(&event.daddr_v6, sk,
                __sk_common.skc_v6_daddr.in6_u.u6_addr32);
    }
    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU,
            &event, sizeof(event));

cleanup:
    bpf_map_delete_elem(&start, &sk);
    return 0;
}

SEC("kprobe/tcp_v4_connect")
int BPF_KPROBE(tcp_v4_connect, struct sock *sk)
{
    return trace_connect(sk);
}

SEC("kprobe/tcp_v6_connect")
int BPF_KPROBE(tcp_v6_connect, struct sock *sk)
{
    return trace_connect(sk);
}

SEC("kprobe/tcp_rcv_state_process")
int BPF_KPROBE(tcp_rcv_state_process, struct sock *sk)
{
    return handle_tcp_rcv_state_process(ctx, sk);
}

SEC("fentry/tcp_v4_connect")
int BPF_PROG(fentry_tcp_v4_connect, struct sock *sk)
{
    return trace_connect(sk);
}

SEC("fentry/tcp_v6_connect")
int BPF_PROG(fentry_tcp_v6_connect, struct sock *sk)
{
    return trace_connect(sk);
}

SEC("fentry/tcp_rcv_state_process")
int BPF_PROG(fentry_tcp_rcv_state_process, struct sock *sk)
{
    return handle_tcp_rcv_state_process(ctx, sk);
}

char LICENSE[] SEC("license") = "GPL";

코드 해석

우선 맵을 먼저 살펴보면 start와 events 맵이 정의되어있다.

start 맵은 해시맵으로 소켓 포인터를 키로 사용하고 있다. 그리고 piddata를 value로 가지는 것으로 보아 수신한 소켓와 추가데이터를 저장하는 맵으로 보인다.
events 맵은 BPF_MAP_TYPE_PERF_EVENT_ARRAY 타입으로 이벤트를 저장하고 전달하기 위한 맵으로 보인다.

그리고 바로 trace_connect와 handle_tcp_rcv_state_process가 나오는데 이것이 이전에 tracepoint에 붙인 두 함수이다.
trace_connect부터 살펴보면 tgid를 받고 piddata 구조체에 값을 저장하여 start 맵에 저장한다. targ_tgid가 정의되어있다면 특정 프로세스만 추적할 수도 있다. 구조체에 쓰이는 값은 bpf_get_current_comm로 얻을 프로세스의 이름과 ts에 해당하는 타임스탬프와 해당 소켓을 생성한 프로세스 id가 기록된다. 이러한 과정을 TCP 연결이 시작되는 순간 어떤 프로세스가 언제 연결을 시도했는지 기록할 수 있게된다.
handle_tcp_rcv_state_process는 (BPF_CORE_READ(sk, __sk_common.skc_state) != TCP_SYN_SENT)에 보이듯 TCP_SYN_SENT 상태인 경우에만 처리된다. client가 첫 SYN 패킷을 전달했다는 뜻이므로 start 맵을 조회하여 이전에 기록한 정보가 있는지 확인한다. 그리고 걸린 시간을 보기 좋게 계산해주고 프로세스 이름과 시각 프로세스 id를 저장한다. event.lport 는 로컬포트를 뜻하고 skc_dport 는 통신 상대방 포트를 뜻한다. event.af는 ipv4인지 ipv6인지 구분해준다. 그리고 각각 ipv4일때와 ipv6일때에 따라 알맞은 형태로 ip 주소를 채운다. 마지막으로 지금까지 채운 event 구조체를 events 맵을 통해 사용자 공간으로 전송한다.

코드 컴파일

오브젝트 파일을 만들어주고,

clang -O2 -g -target bpf -D__TARGET_ARCH_x86 -I. -c tcpconnlat.bpf.c -o tcpconnlat.bpf.o

스켈레톤 헤더파일도 만들어주고,

bpftool gen skeleton tcpconnlat.bpf.o > tcpconnlat.skel.h

유저 프로그램을 빌드해준다.

gcc -O2 -g tcpconnlat.c -o tcpconnlat -I. $(pkg-config --cflags --libs libbpf) -lelf -lz

그리고 실행을 해주기 위해선 실제로 TCP 연결을 실행하고 응답을 받아야하므로 간단한 sh파일을 만들어봤다.

#!/usr/bin/env bash
set -euo pipefail

sudo ./tcpconnlat &
TCPCONNLAT_PID=$!
sleep 3

echo "=============================="
echo "[TCP CONNECT TESTS]"
echo "=============================="
nc -vz -w 1 8.8.8.8 80  >/dev/null 2>&1 || true
nc -vz -w 1 8.8.8.8 443  >/dev/null 2>&1 || true
nc -vz -w 1 8.8.8.8 53  >/dev/null 2>&1 || true


echo "=============================="
echo "[HTTP/HTTPS TESTS]"
echo "=============================="
curl -4 -sS -o /dev/null http://www.google.com || true
curl -4 -sS -o /dev/null https://www.google.com || true
curl -4 -sS -o /dev/null https://www.naver.com || true


echo "=============================="
echo "[UDP TESTS]"
echo "=============================="
dig +time=1 +tries=1 @8.8.8.8 example.com A >/dev/null 2>&1 || true
echo ping | nc -u -w 1 8.8.8.8 53 >/dev/null 2>&1 || true


echo "=============================="
echo "[ICMP TESTS]"
echo "=============================="
ping -c 2 1.1.1.1 >/dev/null 2>&1 || true
ping -c 2 8.8.8.8 >/dev/null 2>&1 || true

이렇게 네가지 경우를 짜두고 실행을 해주어 각 결과를 관측해보자.

실행 결과

각 케이스에 대해서 결과가 나온다. TCP 연결에 대해서 실제 구글과 네이버에 보낸 연결은 잘 도착했고, 결과가 알맞게 나왔다.

하지만 UDP나 TCP 연결을 하지 않는 ping 경우에는 결과가 나오지 않는 모습을 보였다.
tcpconnlat는 TCP 3-way handshake 경로를 추적하므로, ICMP나 UDP 트래픽은 관측 대상이 아니므로 로그가 출력되지 않는 것이다.

References

Full practice sequence : https://github.com/eunomia-bpf/bpf-developer-tutorial/tree/main/src/13-tcpconnlat
tcp_v4_connect : https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_ipv4.c#L340