코더의 보안 정복: 코드형 인프라(IaC) 시리즈 - 비즈니스 로직

자, (일단은) 여기까지입니다. Infrastructure as Code 시리즈의 마지막에 도달했습니다. Docker, Ansible, Kubernetes, Terraform, CloudFormation에서 보안 문제를 해결하며 즐거운 시간 보내셨기를 바랍니다. 마무리하기 전에, 여러분이 정복해야 할 마지막 취약점인 비즈니스 로직 버그가 하나 더 남아 있습니다.
이제 실력을 테스트할 준비가 되셨나요? 마지막 게임화 챌린지에 도전해 보세요:
아직 명확하지 않은 부분이 있다면 계속 읽어보세요:
오늘 집중적으로 다룰 취약점은 비즈니스 로직 결함입니다. 이는 개발자가 비즈니스 로직 규칙을 제대로 구현하지 못할 때 발생할 수 있으며, 악의적인 사용자가 이를 악용할 경우 애플리케이션이 다양한 공격에 노출될 수 있습니다. 각 애플리케이션의 목적과 구현된 기능에 따라, 비즈니스 로직 결함은 권한 상승, 부적절한 리소스 사용 또는 의도하지 않은 수많은 비즈니스 프로세스 수행을 허용할 수 있습니다.
많은 취약점과 달리, 비즈니스 로직 규칙의 잘못된 구현은 매우 미묘할 수 있습니다. 애플리케이션과 코드에 이러한 결함이 스며들지 않도록 각별한 주의가 필요합니다.
비즈니스 로직 결함의 예로는 어떤 것들이 있을까요?
비즈니스 로직 결함이 얼마나 쉽게 발생할 수 있는지 보여주는 예로, Docker Compose 파일로 정의된 Docker 환경의 다음 사례를 살펴보겠습니다. 컨테이너가 기능을 수행하도록 준비하기 위해 개발자는 다음과 같이 Docker Compose 파일에 정의된 표준 리소스 정책을 사용할 수 있습니다:
deploy:
resources:
limits:
cpus: "0.5"
reservations:
cpus: "0.5"
겉보기에는 괜찮아 보이지만, 이 컨테이너 리소스 정책은 리소스 사용량을 제대로 제한하지 못합니다. 공격자는 이러한 비즈니스 로직 결함을 악용하여 서비스 거부(DoS) 공격을 수행할 수 있습니다.
사용자가 너무 많은 리소스를 점유하는 것을 제한하기 위해 개발자는 각 컨테이너가 지원할 수 있는 범위를 더 명확하게 정의하려고 할 수 있습니다. 따라서 새로운 코드에는 배치 제약 조건이 포함될 수 있습니다:
deploy:
resources:
limits:
cpus: "0.5"
reservations:
cpus: "0.5"
placement:
constraints:
- "node.labels.limit_cpu == 100M"
- "node.labels.limit_memory == 0.5"
언뜻 보기에는 이 방법이 비즈니스 로직 결함을 해결할 것처럼 보입니다. 하지만 새로운 배치 제약 조건은 Docker 컨테이너 서비스의 리소스 사용 제한에는 영향을 주지 않습니다. 이는 컨테이너를 예약할 노드를 선택하는 데만 사용됩니다. 이 경우에도 여전히 DoS 공격이 가능합니다. 공격자는 먼저 Docker 컨테이너를 침해해야 하지만, 그 이후에는 제한 없이 리소스를 고갈시킬 수 있습니다.
보시다시피, 비즈니스 로직 결함을 고려하고 이를 제거하기 위해 프로그래밍하는 것은 까다로운 작업이 될 수 있습니다.
비즈니스 로직 결함 제거하기
비즈니스 로직 결함의 경우, 결함의 존재를 인지하는 것이 핵심입니다. 새로운 코드를 작성할 때 환경에 결함이 유입되지 않도록 경계해야 합니다. 비즈니스 규칙과 모범 사례는 설계, 구현, 테스트를 포함한 애플리케이션 개발 프로세스의 모든 단계에서 명확하게 정의되고 확인되어야 합니다.
예를 들어, 위 사례와 같은 DoS 공격을 가능하게 하는 비즈니스 로직 결함을 방지하려면 생성하는 모든 Docker 컨테이너가 사용할 수 있는 리소스 양을 제한하는 것이 모범 사례입니다. 구체적으로, limits 섹션에서 Docker 컨테이너가 사용할 수 있는 CPU 수와 메모리 양을 지정해야 합니다. 예시는 다음과 같습니다:
deploy:
resources:
limits:
cpus: "0.5"
memory: 100M
reservations:
cpus: "0.5"
memory: 50M
위 예시와 같은 코드를 정책으로 사용하면 환경에서 주요 비즈니스 로직 결함을 제거하고 DoS 공격을 방지할 수 있습니다. 이는 공격자가 Docker 컨테이너 중 하나를 침해하더라도 효과가 있습니다. 이 경우 공격자는 확보한 거점을 이용해 리소스를 고갈시킬 수 없습니다.
위협 모델링은 다양한 공격이 발생하는 방식을 정의하고 비즈니스 로직 규칙을 사용하여 이를 방지 및 제한함으로써 큰 도움이 될 수 있습니다. 규정 준수 규칙과 알려진 악용 사례를 기반으로 테스트를 수행하면 간과하기 쉬운 비즈니스 로직 결함을 찾아내는 데 효과적입니다.
비즈니스 로직 결함은 애플리케이션에 침투할 수 있는 가장 미묘한 취약점 중 하나이지만, 다른 유명한 위험 요소 못지않게 위험합니다. 이러한 결함이 발생하는 방식을 이해하고 모범 사례를 적용하면 애플리케이션 개발 단계에서 이를 차단할 수 있습니다. 이를 통해 공격자가 악용할 수 있는 운영 환경으로 결함이 유입되는 것을 원천적으로 방지할 수 있습니다.
이 취약점에 대한 더 자세한 정보와 다른 보안 결함으로부터 조직과 고객을 보호하는 방법은 Secure Code Warrior 블로그 페이지에서 확인해 보세요. 또한 Secure Code Warrior 교육 플랫폼에서 데모를 체험하며 사이버 보안 기술을 꾸준히 연마하고 최신 상태로 유지할 수 있습니다.
배포 전 AI 기반 개발 거버넌스 확보
AI 기반 위험을 측정하고, 커밋 시점에 보안 코딩 정책을 적용하며, SDLC 전반에 걸쳐 안전한 소프트웨어 제공 속도를 높이세요.
더 많은 블로그 살펴보기
보안 코딩, AI 거버넌스, 소프트웨어 리스크 관리에 관한 전문가 콘텐츠를 확인해 보세요.
%252520%252520(3).avif)
Supercharged Security Awareness: How Tournaments are Inspiring Developers at Erste Group
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

Security as culture: How Blue Prism cultivates world-class secure developers
Learn how Blue Prism, the global leader in intelligent automation for the enterprise, used Secure Code Warrior's agile learning platform to create a security-first culture with their developers, achieve their business goals, and ship secure code at speed
배포 전 AI 기반 개발 보안 확보
소프트웨어 개발 수명 주기 전반에서 개발자 리스크를 파악하고, 정책을 시행하며, 취약점을 예방하세요.



.avif)