
오늘날 애플리케이션이 직면하는 너무나 흔한 제약 중 하나는 예산입니다. 보안 예산이 늘고 있는 것은 사실이지만, 해킹에 드는 비용을 감당하기 어려울 만큼 높이는 전략적 접근 방식에 걸맞은 속도로 증가하고 있지는 않습니다.
이 접근 방식은 다음과 같은 하플링-드래곤 원칙과 유사합니다:
하플링과 성질 고약한 용과 함께 있게 된다면, 용보다 빨리 달릴 필요는 없다는 점을 기억하라. 그저 하플링보다 빨리 달리기만 하면 된다.
핵심은 자신의 환경을 공격하는 데 너무 큰 비용이 들게 만들어, 용이 굶주린 눈을 당신의 경쟁자인 하플링에게 돌리도록 하는 것입니다.
이제 윤리적 논쟁으로 이야기가 새지 않도록 하겠습니다. 그런 논쟁은 당연히 격렬하게 벌어져야겠지만, 여러분의 환경을 해킹하는 데 너무 큰 비용이 들게 만든다는 발상 자체는 나쁘지 않습니다.
문제는 그렇게 하려면 대개 여러분이 감당하기에도 너무 많은 비용이 든다는 것입니다. 일반적으로 이러한 전략을 실행하라는 조언은 수많은 솔루션을 구매해 중세 시대의 장애물 코스처럼 배치하고, 새로운 장벽을 세워 공격자가 진정으로 원하는 것, 즉 여러분의 데이터에 도달하려면 그 모든 장벽을 통과하도록 만드는 것이기 때문입니다. 공격자는 탐지를 피하기 위해 공격을 분산하는 과정에서 시간과 에너지, 궁극적으로는 비용까지 들여야 하므로 공격 비용이 높아집니다. 하지만 이는 공격자뿐 아니라 기업에도 많은 비용을 초래합니다. 솔루션 구매 비용(자본적 지출, capex)뿐만 아니라 각 솔루션을 관리, 업데이트, 모니터링하고 궁극적으로 확장해야 하므로 운영 비용(운영적 지출, opex)도 발생합니다.
또한 접근 방식도 거꾸로되어 있습니다. 공격자가 노리는 것은 데이터인데도, 우리는 데이터에서 가장 멀리 떨어진 네트워크 경계부터 방어 체계와 보호 장치를 구축하는 경향이 있습니다.
그렇다면 공격자가 원하는 것을 얻는 데 드는 비용은 크게 높이면서도, 이를 구현하는 데 드는 비용은 지나치게 커지지 않도록 하려면 어떻게 해야 할까요?
이 문제를 단번에 해결할 묘책은 없지만, 공격에 드는 비용은 높이면서 여러분의 비용은 낮게 유지할 수 있는 몇 가지 방법이 있습니다.
1. 플랫폼 활용
플랫폼은 공통 환경을 공유한다는 개념을 기반으로 합니다. 가상화와 컨테이너화가 컴퓨팅 리소스의 효율성을 높이는 것과 같은 방식으로 비용을 절감합니다. 예를 들어 ADC는 모듈을 추가하여 보안을 비롯한 다양한 딜리버리 기능을 지원하도록 확장할 수 있습니다. 많은 조직이 이미 로드 밸런싱을 통해 가용성을 보장하기 위해 ADC를 사용하고 있으며, 이를 통해 WAF 및 기타 보안 관련 기능의 배포도 지원할 수 있습니다. 통합 솔루션으로서 적합한 ADC 는 개별 기능을 포인트 솔루션으로 각각 도입할 때 드는 비용을 모두 합한 것보다 총비용이 훨씬 적을 수 있습니다.
로드 밸런서 자체의 기능도 살펴볼 가치가 있습니다. 기본적인 로드 밸런싱과 달리 ADC는 일반적으로 공격을 더 어렵게 만드는 데 활용할 수 있는 다양한 보안 관련 설정과 제어 기능을 제공합니다. SYN 플러드 탐지, 쿠키 암호화, URL 난독화, IP/포트 필터링은 로드 밸런싱 서비스의 일부로 제공되는 경우가 많습니다. 앱에 더 가까운 지점에서 보호를 강화하면 공격자가 접근하기가 더욱 어려워집니다.
2. 운영 체계화
여전히 어떤 이들에게는 유감스럽고 또 어떤 이들에게는 반가운 일이지만, 애플리케이션의 보안과 확장에 필요한 모든 것을 단독으로 제공할 수 있는 만능 솔루션은 알려진 바가 없습니다. 여러 솔루션이 필요하며(핵심은 플랫폼을 활용해 그 수를 최소화하는 것입니다. 위 내용을 참조하세요), 이는 여러 관리 콘솔과 관리 방식, 그리고 아마도 여러 인력이 필요하다는 뜻입니다. 이 모든 것이 예산을 크게 초과하게 만들 것입니다.

자동화와 오케스트레이션을 지원하는 운영 체계화를 통해 반드시 구축해야 하는 솔루션의 비용을 억제할 수 있습니다. 이미 보유하고 있을 가능성이 높은 리소스를 활용해 규모를 확장하고 공격자도 이에 맞춰 대응하도록 만드는 자동 확장 같은 기능만으로도 방어 비용은 통제하면서 공격 비용을 높일 수 있습니다.
운영 체계화(DevOps, SDN, SDDC, SDx, 프라이빗 클라우드 등)는 인적 오류와 프로세스 부재라는 고위험 요인도 해결합니다. 프로세스 부재와 관련해서는, 존재하지 않는 프로세스를 자동화할 수 없습니다(참고로 이를 오케스트레이션이라고 합니다). 프로세스가 없다면 마련해야 합니다. 프로세스는 앱을 프로덕션 환경으로 전환할 때 보안을 강화하고 확장하는 데 필요한 단계가 빠짐없이 수행되도록 보장합니다. 한편 인적 오류는 의도치 않게 보안 허점을 만들어 공격자가 직접 침입하거나 대규모 DDoS 공격으로 주의를 분산시킨 틈을 타 몰래 침투하게 할 수 있으므로 매우 큰 위험 요소입니다.
3. 확장 수단으로서의 클라우드
더 이상 자동 확장이 불가능하거나 대역폭이 한계에 달했을 때는 언제나 클라우드를 활용할 수 있습니다. 확장 수단으로서의 클라우드(원한다면 클라우드 버스팅이라고 해도 좋습니다)는 공격 비용은 높이면서 효율적으로 방어할 수 있게 해 주는 탁월한 선택입니다. 공격이 진행 중이거나 막 시작되었을 때 DDoS 트래픽 정화 및 방어를 클라우드로 전환하면 생산성과 수익 측면에서 비즈니스에 미치는 로컬 영향을 즉시 줄일 수 있으며, 이는 실제로 방어 비용 절감으로 이어집니다. 사실상 무한한 확장성과 막대한 대역폭을 갖춘 클라우드가 공격을 흡수하도록 하면 장기적으로 방어자의 비용은 훨씬 줄어들지만, 공격자의 비용은 그렇지 않습니다.
4. 내부에서부터 보안 강화

앞서 언급했듯이 공격자는 대개 여러분의 데이터를 노립니다. 암시장에서 데이터는 곧 돈이기 때문입니다. 따라서 경계를 보호하는 것만큼, 아니 그 이상으로 데이터를 안전하게 보호하는 데 집중해야 합니다. 즉, 가능한 모든 방법과 기술을 동원해 공격자가 데이터를 탈취하여 공격의 성과를 얻는 데 막대한 비용이 들도록 해야 합니다. 이를 위해서는 지속적으로 경계하면서 앱으로 들어오는 것뿐만 아니라 앱에서 나가는 것까지 보호해야 합니다. 이것이 바로 요청 및 응답 보호입니다.
현재 WAF를 배포한 당사의 ‘2016년 애플리케이션 딜리버리 현황’ 설문 응답자 대다수(67%)는 소속 조직이 애플리케이션 계층(요청-응답) 공격을 견뎌낼 수 있다고 확신했습니다. 여기에는 SQLi 및 XSS뿐만 아니라 WebSocket 보안, 세션 하이재킹 방지 등 공격자가 데이터 탈취에 성공하기까지 막대한 비용을 치르게 하는 다양한 기능이 포함됩니다.
실제로 세 가지 공격 표면(클라이언트, 요청, 응답) 모두를 더욱 일관되게 보호할수록 애플리케이션 계층 공격을 견딜 수 있다는 확신도 높아지는 것으로 나타났습니다. 이는 ‘에지’ 기능이 아니라 애플리케이션 중심의 기능입니다. 네트워크 에지보다 애플리케이션에 더 가까이 위치하며, 네트워크 공격이 아니라 실제로 데이터를 빼내려는 공격을 차단하는 것이 목적입니다. 공격자가 노리는 것은 바로 그 데이터의 가치이며, 공격자가 포기하고 다른 곳으로 떠날 만큼 공격 비용을 높여야 하는 대상도 바로 그것입니다.
보안을 저렴하게 구현할 방법은 없습니다. 정말 없습니다. 하지만 비용을 낮게 유지하면서도 애플리케이션을 보호할 여력까지 소진하지 않고, 공격자가 치러야 할 비용을 방어자가 부담하는 비용보다 더 크게 만드는 방법은 있습니다. 이를 제대로 수행해 방어 체계가 공격자로 하여금 너무 많은 자원과 비용을 소모하게 만든다면, 드래곤은 지쳐서(혹은 빈털터리가 되어) 그 하플링을 쫓지 못할 수도 있습니다. 그러면 하플링은 자체 방어 체계를 구축하는 데 한발 앞서 나갈 기회를 얻게 됩니다.
작성자 소개

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.
Lori Mac Vittie의 다른 블로그 게시물관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.
TLS 검사에서 피터 파커 원칙 다루기
“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.
Venafi와 F5를 통한 머신 아이덴티티 보호
‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.
마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...
내 클라우드에서 나가!
F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.
Shift(웹 앱) 보안 레터
웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.