정책 리스크를 파악하십시오. 정책에 대한 질문을 일상 언어로 하십시오. 데모 신청하기 →
Published:
방화벽 보안: 안전한 방화벽 없는 네트워크가 가능한가? 가능할지 몰라도, 굳이 그래야 할까
by FireMon
불과 3년 전만 해도 방화벽은 한물갔다는 기사가 기술 분야 헤드라인을 가득 채웠습니다. 단순 패킷 필터링만 수행하던 예전 방화벽에 머물러 있었다면 그 예측이 현실이 되었을지도 모릅니다. 그러나 네트워크 경계를 정의하는 방식이 변화하고 그 경계가 흐려지는 와중에도 방화벽은 엔터프라이즈 보안 스택에서 중요한 자리를 지키고 있습니다. 방화벽이 그 자리를 잃을 듯할 때마다 그 유용성과 효과를 새롭게 하는 또 다른 혁신이 등장했기 때문입니다.
방화벽의 보편성은 수치로 확인됩니다. FireMon의 State of the Firewall 2019 설문조사 응답자의 30 percent가 100대 이상의 방화벽을 관리한다고 답했으며, 95 percent는 향후 5년간 방화벽이 지금과 같거나 그 이상으로 중요해질 것이라고 응답했습니다.
그러나 오늘날 네트워크 보안 위험이 계속 커지고 하이브리드 환경이 갈수록 복잡해지면서, 기술 리더들은 자사 네트워크에 대한 가시성을 확보하고 있다는 확신을 갖지 못하고 있습니다. 내부 방화벽, 애플리케이션 방화벽, 모바일 기기 방화벽 등 온갖 종류의 방화벽을 도입했지만, 이를 중앙에서 관리하거나 한 방화벽의 규칙이 다른 방화벽의 규칙과 충돌하지 않는지 검증할 방법이 없기 때문에 이 방화벽들이 인프라를 실제로 보호하고 있는지 판단할 수 없습니다.
FireMon Firewall Security가 가장 복잡한 문제를 어떻게 해결하는지 알아보십시오
복잡성이 불가피한 이유
얼마 전까지만 해도 보안 지침을 찾는 기업에 주어지는 표준적인 조언은 “단순하게 유지하라”였습니다. 물론 단순한 인프라는 복잡한 인프라보다 관리하기 쉽지만, 오늘날 복잡성을 피할 수 있는 기업이 있을까요? 비즈니스 요구는 디지털 전환, 다단계 공급망, 그리고 이제 대부분 원격으로 근무하는 인력을 위한 연결성을 필요로 합니다. 이것이 우리가 살고 있는 현실이며, “단순하게 유지하라”는 접근을 우선한다면 우리 모두 사업을 접어야 할 것입니다.
공개 서버에 대한 접근을 허용하기 위해 DMZ를 구축하는 시나리오를 생각해 보십시오. 서버를 모니터링하고 관리해야 하므로 공개적으로 제공되는 서비스만으로 서비스를 제한하는 것은 불가능합니다. 따라서 SSH, SNMP, 백업 서비스 등 관리용 서비스가 활성화됩니다. 각 서비스는 공격 표면을 넓힙니다.
이는 호스트에 내장된 방화벽을 사용해 알려진 호스트에서만 서비스에 접근하도록 제한함으로써 해결할 수 있습니다. 이는 호스트 수준의 접근 제어 필터링입니다. 즉, 접근을 효과적으로 통제하려면 모든 호스트를 개별적으로 구성해 접근 권한을 정의해야 합니다. 이 문제의 해결책으로 구성을 표준화하는 것이 쉬운 방법처럼 보일 수 있지만, 이러한 장비가 실제로 어떻게 사용되는지의 현실은 반영하지 못합니다.
네트워크 가시성을 가로막는 요인은 무엇인가
일반적인 기업에 그토록 많은 방화벽이 있다면 여러 벤더가 뒤섞여 있는 것도 당연합니다. 벤더마다 고유한 기본 규칙과 고유한 규칙 구성 방식을 가진 제품을 제공합니다. 이 모두를 관리하는 일은 감당하기 어렵습니다. 각 제품이 2000줄의 코드를 담고 있다면, 규칙이 변경될 때마다 200,000줄 이상의 코드를 살펴봐야 할 수도 있습니다. 그리고 규칙 변경은 끊임없이 발생합니다.
그렇다면 문제는 방화벽이 지나치게 복잡하고 서로 이질적이라는 데 있을까요? 아니면 많은 조직이 이처럼 역동적인 기술을 관리할 적절한 리소스를 갖추지 못했다는 데 있을까요?
분명한 것은 이 정도 규모의 변경 관리는 스프레드시트로는 불가능하다는 점입니다. 대부분의 기업은 각 변경 요청을 처리하거나 승인하는 데 두 개 이상의 팀이 관여하지만, 그럼에도 속도를 따라가기 어려워합니다.
해결책은 자동화된 방화벽 관리 솔루션을 도입하는 것입니다. 간단해 보이지만, 기술 관리자의 65 percent는 환경 관리에 자동화를 사용하지 않는다고 답했습니다.
방화벽 보안 문제
방화벽의 가장 큰 문제는 기술 자체가 아닙니다. 문제는 사람과 상황에서 비롯됩니다. 바로 잘못된 구성과 정책 복잡성입니다.
잘못된 구성이란 곧 사람의 실수를 완곡하게 표현한 말입니다. 실수를 프로그래밍으로 완전히 없앨 방법은 없습니다. 사람이 정보를 입력해야 하는 한 실수는 발생하기 마련입니다. 그리고 실제로 많이 발생하고 있습니다. 2018년에는 클라우드 구성 오류로 인한 데이터 유출이 424 percent 증가했으며, 그 원인은 사람의 실수로 밝혀졌습니다. 또한 Gartner에 따르면 앞으로 방화벽 침해의 99 percent는 사람의 실수에서 비롯될 것입니다.
사람이 실수하는 데에는 여러 이유가 있습니다. 제대로 교육받지 못했거나, 업무가 과중해 집중할 수 없거나, 통제되지 않는 정책과 규칙에 압도당하기 때문입니다. 앞의 두 가지 원인은 따로 설명이 필요 없습니다. 그러나 마지막 원인은 살펴볼 가치가 있습니다.
Gartner Cloud Report에 따르면, “2022년까지 클라우드 보안 실패의 최소 95%는 고객의 책임일 것입니다.”
정책과 규칙은 시간이 지나며 쌓입니다. 레거시 기술은 이미 정책과 규칙으로 비대해져 있고, 인수나 합병으로 또 한 무더기가 추가되며, 일상적인 업무 과정에서도 통상적인 추가분이 누적됩니다. 문제는 늘어나는 정책과 규칙 더미를 선제적으로 관리하지 않을 때 발생합니다. 최적화되지 않고 오래되었으며 중복된 규칙은 다른 규칙과 충돌해 공격자가 악용할 수 있는 취약점을 만들어냅니다.
그리고 잘못된 규칙이 있습니다. IT 담당자는 접근 권한을 제공하라는 요청을 받지만, 요청이 어디에서 왔는지 또는 어떤 서비스, 포트, 애플리케이션이 관련되는지와 같은 정보를 받지 못합니다. 담당자는 가진 정보로 최선을 다하며, 나중에 시간이 생기면 더 알아보고 수정하겠다는 생각으로 지나치게 허용적인 규칙을 만듭니다. 그러나 규칙 요청은 계속 들어오고, 담당자는 결국 수정하러 돌아오지 못합니다. 지나치게 허용적인 그 규칙은 정책 안에 박힌 채 수년간 남아 있을 수 있으며, 악의적인 행위자가 이를 발견하면 네트워크로 들어오는 통로가 될 수 있습니다.
모범 사례: 보안 자동화 도입
이러한 문제는 모두 자동화로 해결할 수 있습니다. 자동화는 규칙 관리에 소요되는 시간을 90 percent 줄이고 방화벽 구성 오류를 80 percent 없앨 수 있습니다. 자동화는 환경 변화를 지속적으로 모니터링하고, 일반적인 충돌을 완화하며, 예외적인 사례만 사람에게 넘기는 방식으로 작동합니다.
그런데 자동화가 그렇게 효과적이라면, 왜 더 많은 조직이 네트워크 보안 자동화로 방화벽을 관리하지 않을까요?
한 가지 문제는 매몰 비용 오류입니다. 기업은 클라우드로 이전하면서도 온프레미스에서 사용하던 것과 동일한 도구 세트를 그대로 쓰는 경향이 있습니다. 그런 도구가 반드시 클라우드에 맞는 것은 아니지만, 경영진이 그 구매에 대해 적절한 투자 수익을 얻고자 하기 때문에 계속 사용됩니다. 변경 요청 관리와 컴플라이언스에 드는 비용은 인건비에 가려져 있어 알아차리기 더 어려운 경우가 많습니다.
새로운 자동화 솔루션의 비용이 걸림돌이 될 수 있습니다. 직원들이 수작업으로 처리할 수 있으니 또 다른 제품을 구매할 이유가 없다고 생각할 수 있습니다. 그러나 수작업 프로세스를 고수하는 것은 잘못된 절약입니다. 인건비도 비쌀 뿐 아니라, 이에 따르는 다운타임과 데이터 유출 위험 또한 큽니다. 자동화를 통해 방화벽 200대를 보유한 기업은 매년 $1.7M을 절감할 수 있습니다.
기업이 자동화를 도입하지 않는 또 다른 이유는 자신의 문제를 해결할 솔루션이 존재한다는 사실을 단순히 모르기 때문입니다. 자동화가 여전히 반복적이고 단순한 작업만 수행할 수 있다고 생각하며, 오늘날 자동화와 인공지능이 결합해 강력한 솔루션을 만들어내고 있다는 점을 알지 못합니다.
방화벽은 여전히 강력한 보안 태세의 필수 요소
방화벽은 만능 해결책이 아닙니다. 보안에 만능 해결책은 없으며, 방화벽에 지나치게 의존하는 것은 어리석은 일이고 네트워크를 심각한 위험에 빠뜨립니다. 그러나 다른 보안 기술과 함께 위험을 제한하는 핵심적이고 중심적인 장치로 방화벽을 활용하는 것은 적절한 구현 방식입니다.