자, 얘들아. 이제 우리도 "그 얘기"를 나눌 때가 됐어. 무슨 얘기인지 알지? 친구들과는 소곤소곤 얘기해 왔지만, 지금까지는 차마 직접 물어보지 못했던 바로 그거 말이야. 당연히 다른 사람들은 모두 알고 있을 테고, 너만 제대로 모른다고 인정하면, 뭐랄까, 멋없어 보일까 봐 말이지.
하지만 사실 다들 잘 모릅니다. 설령 안다고 해도 그들 역시 그 이야기를 꺼내지 않죠. 이제는 클라우드를 사용할 때 올바른 예방 조치를 취하는 방법에 대해 진지하게 이야기해야 할 때가 한참 지났습니다. 클라우드의 앱을 감염과 공격으로부터 보호하는 방법 말입니다.
네, 오늘은 드디어 클라우드 애플리케이션 보안에 대해 이야기해 보겠습니다.
암호화도, ID 및 액세스 관리도, 네트워크 보안도 아닙니다.
애플리케이션 보안.
오늘날 방대한 인터넷에서 접할 수 있는 "클라우드 보안" 관련 문서, 연구, 조언 및 일반적인 논의는 매우 많지만, 그중 "앱 보안"을 언급하는 경우는 극히 드뭅니다*. 암호화 사용 현황, 클라우드 데이터를 보호해야 하는 주체와 실제로 보호하지 않는 주체, 그리고 언제 어디서나 앱에 대한 접근을 통제하기 위해 누가 어떤 종류의 ID 및 접근 관리 방식을 사용하는지에 관한 연구와 통계는 찾을 수 있습니다. 하지만 애플리케이션 보안에 관한 내용은요? 전무합니다. 아무것도 없습니다. 전혀요. 제로입니다.
최신 Verizon 데이터 침해 조사 보고서(DBIR)에 따르면 웹 앱은 금융 서비스 보안 사고의 두 번째 주요 원인으로, 이름부터 사악하게 들리는 크라임웨어 바로 다음이라는 점을 고려하면 이는 실로 놀랍고도 우려스러운 일입니다. 또한 금세기 발생한 상위 25건의 침해 사고를 간단히 분석해 보면 거의 절반(44%)이 웹 애플리케이션을 통해 실행되었다는 사실도 놀랍습니다. 더욱 안타까운 점은 보안 태세 약화와 애플리케이션의 클라우드 이전 사이에 상관관계가 있는 것으로 보인다는 것입니다.
현실적으로 암호화가 만병통치약은 아닙니다.
이 사안이 얼마나 심각한지 강조하기 위해 이번에는 모두 대문자로 다시 말씀드리겠습니다. 암호화는 만병통치약이 아닙니다.
네트워크 보안이나 ID 및 액세스 관리도 만능 해결책은 아닙니다.
이 모든 요소는 유용하지만, 각각은 훨씬 더 큰 보호 체계의 일부일 뿐입니다. 이 보호 체계에는 애플리케이션 보안도 포함되어야 하지만, 실제로는 그렇지 않은 경우가 많습니다.
Network security로는 HTTP DDoS 공격을 막을 수 없습니다. ID 및 액세스 관리로는 Heartbleed나 Apache Killer와 같은 웹 플랫폼 취약점의 악용을 막을 수 없습니다.
암호화로는 SQL 인젝션을 막을 수 없습니다. 악성 코드를 암호화하면 이를 숨길 뿐입니다 네트워크에서 악성 코드를 탐지하도록 설계된 수많은 서비스가 발견하지 못하도록 말입니다.
애플리케이션은 그 목적상 대중에게 공개되는 리소스입니다. 우리는 애플리케이션을 공개하고 소비자가 상호 작용하기를 기대합니다. 아니, 사용하고, 설치하고, 자주 방문하도록 권하고, 유도하고, 간청하기까지 합니다. 지금은 애플리케이션의 시대이며, 이는 고객용이든 직원용이든 내부 시스템 운영용이든 애플리케이션이 비즈니스의 모든 측면에서 매우 중요하다는 뜻입니다. 오늘날 우리는 거의 모든 일에 애플리케이션을 의존하지만, 보안을 이야기할 때면 정작 애플리케이션은 좀처럼 떠올리지 않습니다.
이제는 정말 애플리케이션 보안에 더 많은 관심을 기울여야 할 때입니다. 데이터 보안이나 네트워크 보안, 암호화된 통신에만 신경 쓸 것이 아닙니다. 데이터는 애플리케이션에서 처리되는 동안 가장 취약합니다. 이때 데이터는 평문 상태이며 해당 애플리케이션의 완전한 통제하에 있기 때문입니다. 애플리케이션은 데이터를 표시하고 수정할 수 있으며, 이를 빼내도록 유도할 수 있는 누구에게든(또는 봇, 스파이더, 멀웨어가 증가하는 상황을 고려하면 점점 더 어떤 것에든) 전달할 수 있습니다.
이는 보안 취약점 악용과 공격으로부터 애플리케이션을 보호하는 데 더 많은 주의를 기울여야 한다는 뜻입니다. 플랫폼(웹 서버 또는 앱 서버)부터 프로토콜(TCP 및 HTTP), 실제 코드 자체에 이르기까지 애플리케이션 스택 전체를 악용하는 수많은 공격 수법을 검사하고, 걸러내고, 탐지하고, 방어해야 합니다.
F-Secure Labs에 따르면 웹 애플리케이션 공격 빈도는 2012년 20% 미만에서 2013년 40%로 두 배 증가했으며, Neustar는 2014년에 DDoS 공격 대상의 55%가 연막 공격(실제 애플리케이션 계층 공격을 은폐하기 위한 대규모 트래픽 기반 DDoS)을 경험했고, 약 50%는 멀웨어/바이러스가 설치되었으며 26%는 고객 데이터를 잃었다고 밝혔습니다.
애플리케이션 공격은 실질적이고 중대한 위협이며, 특히 애플리케이션이 클라우드로 이전되면서 이를 보호할 수 있는 수단이 줄어들 수 있다는 점에서 더욱 그렇습니다.
클라우드에서 제공되는 보안 중심의 네이티브 서비스는 모두 액세스와 암호화에 초점을 맞추고 있습니다. 이 중 어느 것도 "애플리케이션 계층" 보안을 제공하지 않으며, 애플리케이션 자체를 악용하여 데이터를 무력화하거나 손상 또는 유출하도록 설계된 공격을 견딜 수 있다는 확신을 줄 만큼 충분한 보호 범위를 제공하지도 않습니다. 따라서 데이터 센터에서와 마찬가지로 클라우드에서도 애플리케이션과 애플리케이션이 처리하는 데이터를 보호하도록 설계된 또 다른 솔루션, 즉 별도의 서비스가 필요합니다. 이를 위해 클라우드 지원 WAF(웹 애플리케이션 방화벽) 또는 서비스형 WAF를 사용하거나, 최소한 클라우드에 배포되는 모든 애플리케이션에 OWASP에서 권장하는 모범 사례를 철저히 적용해야 할 수 있습니다.
클라우드 보안은 공급자와 고객이 "클라우드" 보안의 서로 다른 측면을 나누어 맡는 공동 책임으로 볼 수 있지만, 애플리케이션 보안은 해당 애플리케이션을 클라우드에 배포한 주체가 110% 책임져야 합니다. AWS 글로벌 보안 프로그램 책임자인 빌 머레이와의 다음 인터뷰(The Register 제공, 강조는 필자)를 살펴보십시오:
“AWS의 보안은 AWS와 고객이 공동으로 책임집니다.”라고 머레이는 최근 인터뷰에서 말했다. 그는 아마존 데이터 센터의 물리적 보안을 비롯한 AWS 보안을 담당하는 한편, 법 집행 기관이 발부한 영장과 소환장에도 대응한다.
그는 “고객은 AWS에서 실행하는 게스트 운영체제부터 그 위에서 구동하는 애플리케이션에 이르기까지 모든 것을 보호할 책임이 있습니다”라고 El Reg에 말했다. “호스트 운영체제와 가상 머신(VM), 그리고 데이터센터 바닥의 콘크리트에 이르기까지 그 아래의 모든 것은 저희가 책임집니다.”
머레이는 “우리는 ‘무엇 때문에 밤잠을 설치십니까?’라는 질문을 자주 받습니다. AWS 보안과 관련해 우리가 밤잠을 설치게 되는 이유는 고객이 보안을 유지할 수 있도록 애플리케이션을 올바르게 구성하지 않는 것입니다”라고 말했다.
바로 여러분의 이야기입니다. 즉, 필연적으로 닥쳐올 것으로 보이는 공격으로부터 해당 애플리케이션을 보호하기 위해 어떤 서비스와 솔루션을 배포할지 신중하게 고려해야 합니다.
애플리케이션 보안은 값비싼 경호원과 같은 것이 아닙니다. VIP 애플리케이션에만 필요한 것도 아닙니다. 오히려 개인 보안에 가까우며, 외부에 공개되는 모든 애플리케이션이 갖춰야 할 요소입니다. 이는 해당 애플리케이션이 데이터 센터에 있든 클라우드에 있든 마찬가지입니다.
* "거의 없다"고는 했지만, 솔직히 단 하나도 찾지 못했다. 어쩌면 내 검색 실력이 부족해서일 수도 있지만, 그보다는 아무도 이 문제에 관해 이야기하고 싶어 하지 않기 때문일 가능성이 더 크다.
작성자 소개
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 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.