하플링, 드래곤, 그리고 DDoS 공격
오늘날 애플리케이션에 있어 너무나 흔한 제약은 예산입니다. 보안 예산은 늘어나고 있을 수 있지만, 해킹 비용을 너무 비싸게 만드는 전략적 접근 방식에 걸맞은 속도는 아닙니다.
이 접근 방식은 다음과 같이 명시하는 하플링-드래곤 원칙과 유사합니다.
만약 당신이 하플링과 성질 급한 용과 함께 있다면, 용보다 빨리 도망갈 필요는 없다는 걸 기억하세요. 그저 하플링보다 빨리 도망가면 됩니다.
아이디어는 플레이어가 자신의 환경을 공격하는 데 너무 많은 비용이 들게 만들어 용이 배고픈 눈을 경쟁자인 하플링에게 돌리도록 만드는 것입니다.
이제 윤리적 논쟁에 대해서는 언급하지 않겠지 만 , 해킹 비용이 환경을 너무 비싸게 만드는 개념은 나쁘지 않습니다.
문제는 그것이 종종 당신이 감당하기에는 너무 비싸다는 것을 의미한다는 것입니다. 그 이유는 일반적으로 이러한 전략을 실행하는 데 대한 조언은 많은 솔루션을 구매하고 마치 중세 장갑처럼 던지고, 새로운 장벽을 세우고 공격자가 이를 실행하여 실제로 원하는 것, 즉 데이터에 도달하도록 강요하는 것을 수반하기 때문입니다. 이로 인해 공격자는 감지되지 않기 위해 공격을 확산시키려고 하면서 시간, 에너지, 그리고 궁극적으로 비용을 소모해야 하므로 비용이 많이 듭니다. 이는 공격자뿐만 아니라 기업에도 큰 비용이 듭니다. 솔루션 측면(capex)뿐만 아니라 운영 측면(opex)에서도 각 솔루션을 관리, 업데이트, 모니터링하고 궁극적으로 확장해야 합니다.
또한 안에서 바깥으로 뒤집히는 경우도 있습니다. 공격자가 원하는 것은 여러분의 데이터입니다. 하지만 우리는 네트워크 경계, 즉 데이터에서 가장 먼 지점부터 방어와 보호책을 구축하는 경향이 있습니다.
그러면 어떻게 하면 구현하는 데 비용이 너무 많이 들지 않게 하면서, 그들이 원하는 것을 얻는 데 비용이 너무 많이 들게 만들 수 있을까요?
이 경우에는 은(도금) 총알이 없지만 공격 비용을 늘리는 동시에 비용을 줄일 수 있는 방법이 몇 가지 있습니다.
1. 레버리지 플랫폼
플랫폼은 공통 환경을 공유한다는 개념을 기반으로 합니다. 가상화와 컨테이너화가 컴퓨팅 리소스의 효율성을 높이는 것과 같은 방식으로 비용을 절감합니다. 예를 들어 ADC는 보안을 포함한 다양한 전송 기능을 지원하는 모듈로 확장될 수 있습니다. 많은 조직에서는 이미 WAF 및 기타 보안 관련 기능의 배포를 지원할 수 있는 부하 분산을 통해 가용성을 보장하기 위해 ADC를 사용하고 있습니다. 전체적인 솔루션으로서 적합한 ADC의 총 비용은 포인트 솔루션으로 개별 기능을 합친 비용보다 훨씬 저렴할 수 있습니다.
로드 밸런서 자체의 기능도 탐색해 볼 가치가 있습니다. 기본적인 부하 분산과 달리 ADC는 일반적으로 공격을 어렵게 만드는 데 사용할 수 있는 보안 관련 여러 가지 조절 기능을 제공합니다. SYN 플러드 감지, 쿠키 암호화, URL 난독화, IP/포트 필터링은 종종 부하 분산 서비스의 일부로 제공될 수 있습니다. 앱에 가까운 곳에서 보호 수준을 높이면 공격자가 접근하기 더 어려워집니다.
2. 운영화하다
아직도 일부 사람들에게는 불만스럽고 다른 사람들에게는 기쁨이지만, 애플리케이션을 보호하고 확장하는 데 필요한 모든 것을 단독으로 제공할 수 있는 알려진 "신의 상자"는 없습니다. 여러 솔루션이 필요할 것입니다(중요한 것은 사용 플랫폼의 수를 최소화하는 것입니다. 위 참조). 즉, 여러 콘솔, 관리 패러다임, 그리고 아마도 사람들이 필요할 것입니다. 이 모든 것이 여러분의 예산을 초과하게 될 것입니다.
자동화와 오케스트레이션을 가능하게 하는 운영화를 통해 반드시 필요한 솔루션 비용을 절감할 수 있습니다. 이미 확장할 수 있는 리소스를 활용하여 자동 확장 기능을 사용하고 공격자가 동일한 방식으로 대응하도록 강제하는 기능조차도 공격 비용을 증가시키는 동시에 방어 비용을 통제할 수 있습니다.
운영화(DevOps, SDN, SDDC, SDx, 프라이빗 클라우드 등)를 통해 높은 위험의 원천인 인적 오류와 프로세스 부족도 해결할 수 있습니다. 후자의 경우, 존재하지 않는 프로세스(그런데 이것이 오케스트레이션입니다)를 자동화할 수 없습니다. 만약 하나도 없다면, 꼭 가져야 해요. 프로덕션에 앱을 투입할 때 보안과 확장을 위해 필요한 단계가 수행되도록 보장합니다. 전자인 인적 오류는 큰 위험입니다. 의도치 않게 보안에 구멍을 뚫어 악당이 볼륨 DDoS 공격으로 주의를 돌리는 동안 직접 또는 은밀하게 몰래 침입할 수 있기 때문입니다.
3. 규모로서의 클라우드
더 이상 자동 확장이 불가능하거나 대역폭이 초과되면 항상 클라우드가 있습니다. 규모로서의 클라우드(원한다면 클라우드 버스팅)는 공격 비용을 높이는 동시에 효율적으로 방어할 수 있는 훌륭한 옵션입니다. 공격이 발생하는 동안(또는 처음 시작될 때) DDoS 스크러빙 및 보호 기능을 클라우드로 전환하면 생산성과 수익 측면에서 비즈니스에 미치는 로컬 영향을 즉시 줄일 수 있으며, 실제로 방어 비용을 줄일 수 있습니다. (거의) 무한한 규모와 엄청난 대역폭을 갖춘 클라우드가 공격을 흡수하도록 하면 장기적으로는 비용이 훨씬 적게 들지만 공격자 입장에서는 그렇지 않습니다.
4. 안에서부터 밖까지 안전하게
앞서 언급했듯이 공격자는 일반적으로 사용자의 데이터를 원합니다. 그 이유는 공개된 불법 시장에서 귀하의 데이터는 $$와 같기 때문입니다. 따라서 경계를 보호하는 것만큼(혹은 그보다 더 많이) 데이터 보안에 집중하세요. 즉, 공격자가 공격으로부터 가치를 뽑아내는 데 많은 비용이 들도록(데이터를 빼내는 데) 모든 속임수와 기술을 동원해야 한다는 의미입니다. 앱에 들어가는 것뿐만 아니라 나오는 것도 보호하여 끊임없이 경계해야 합니다. 요청 및 응답 보호입니다.
2016년 애플리케이션 제공 상태에 대한 조사에 응답한 사람 중 현재 WAF를 배포한 사람 대부분(67%)은 해당 조직이 애플리케이션 계층(요청-응답) 공격을 견뎌낼 수 있는 능력이 있다고 확신했습니다. 여기에는 SQLi와 XSS와 같은 것뿐만 아니라 WebSocket 보안과 세션 하이재킹 방지를 비롯한 다양한 기능이 있어 공격자가 사용자의 데이터를 탈취하는 데 드는 비용이 매우 많이 듭니다.
실제로 세 가지 공격 표면(클라이언트, 요청, 응답) 전반에 걸쳐 보다 일관된 보호가 이루어지면 애플리케이션 계층 공격을 견뎌낼 수 있는 확신도 높아졌습니다. 그건 "엣지" 기능이 아닙니다. 앱 중심 기능입니다. 네트워크 가장자리보다는 앱에 더 가깝게 위치하며, 네트워크 공격을 막는 것이 목적이 아니라 실제로 데이터를 빼내는 공격을 막는 것이 목적입니다. 이것이 바로 공격자가 찾는 가치이며, 공격자가 포기하고 다른 곳으로 갈 만큼 비용을 많이 들여야 하는 가치입니다.
보안을 저렴하게 만들 수 있는 방법은 없습니다. 존재하지 않아요. 하지만 공격자에게 더 많은 비용을 지불하게 하면서 앱을 보호하기 위해 너무 돈이 없어지는 일 없이 비용을 줄일 수 있는 방법이 있습니다. 그리고 만약 당신이 그것을 잘 해내고 당신의 방어가 공격자들이 자신의 자원(그리고 돈)을 너무 많이 소모하도록 강요한다면, 드래곤은 그 반감을 위해 나아갈 만큼 지쳐(파산해) 있을 것입니다. 그러면 하플링은 스스로 방어에 앞서나갈 기회를 얻게 될 겁니다.