방화벽의 실용적 역사 – 2부: 관리의 가치

Jody Brazil, FireMon CEO Check Point과 스테이트풀 인스펙션 방화벽은 프록시 방화벽과의 초기 경쟁에서 승리했습니다(1부: 초창기). 이를 모두 검사 기술 덕분이라고 말하기는 쉽지만, 그렇게 보면 Check Point 솔루션의 핵심 혁신인 정책 관리를 놓치게 됩니다. 90년대 중반 스테이트풀 인스펙션 방화벽이 프록시 경쟁 제품을 앞선 데에는 관리의 편의성이 상당 부분 작용했습니다. 이 글의 상당 부분은 Check Point에 초점을 맞추고 있습니다. 이는 주로 90년대 후반과 2000년대 초반 방화벽 시장에서 Check Point가 차지했던 지배적 위치 때문입니다. 다만 그 시기에 제가 Check Point를 접했던 경험 때문이기도 할 것입니다. 여러분의 관점을 환영하며 의견을 기다리겠습니다. 90년대 중반은 네트워크가 빠르게 진화하던 시기였습니다. 예를 들어 이더넷은 하나의 선택지였을 뿐, 항상 사용되던 로컬 네트워크 프로토콜은 아니었습니다(토큰 링을 기억하십니까?). 인터넷 연결은 당연한 것이 아니라 논의의 대상이었습니다. 전화 접속은 여전히 흔했고 AOL이 지배적인 사업자였습니다. 방화벽이 주류 기술이었다고 말하는 것은 인터넷을 주류로 잘못 이해하는 것입니다. 이처럼 빠르게 변화하는 네트워크가 가져온 결과 중 하나는 상당한 수준의 무지와 경험 부족이었습니다. 이러한 맥락에서 방화벽의 관리 용이성은 결국 이 시장의 승자를 결정한 핵심 동인으로서 간과되어서는 안 됩니다. 오늘날 소프트웨어 개발에서는 사용자 경험과 사용성을 이야기합니다. 당시에는 그런 용어가 유행어가 아니었지만, 우리가 오늘날 이를 논하는 이유는 그때도 똑같이 중요했습니다. 고객은 그 제품을 더 "좋아"했습니다. 따라서 보안과 성능도 중요했지만, Check Point 방화벽 GUI의 사용성 또한 간과해서는 안 됩니다. 당시 Gauntlet 영업 담당자의 말을 빌리자면, "잠재 고객이 누구든 상관없었습니다. 어떤 계정에 들어가든 Check Point GUI와 싸워야 했고, 대개는 졌습니다." Check Point는 중앙 관리 기능과 매우 혁신적인 사용자 인터페이스를 갖춘 방화벽을 선보였습니다. 주요 기능 중 몇 가지는 다음과 같습니다.

• 그래픽 규칙 편집기
• 방화벽 정책 간에 공유되는 중앙 객체 저장소
• 중앙 집중식 로깅
• 멀티 도메인 관리 및 OPSEC

Check Point 정책 편집기

방화벽 규칙이 출발지, 목적지, 프로토콜, 포트(프로토콜과 포트는 서비스라는 단일 객체로 결합됨), 작업의 5-튜플이라는 개념은 Check Point 정책 편집기보다 훨씬 이전부터 존재했습니다. 초기 액세스 제어 목록은 80년대에 이미 이 개념을 지원했습니다. 그러나 Check Point는 그래픽 규칙 편집기로 패러다임을 바꾸었습니다. 더 이상 규칙을 생성하기 위해 CLI 구문을 알 필요가 없었습니다. 마우스와 몇 번의 클릭이면 충분했습니다. 또한 규칙 편집에는 복사 및 붙여넣기, 사용자 정의 주석, 열당 다중 객체와 같은 유용한 기능이 추가되었습니다. 열당 다중 객체라는 마지막 요소는 혁명적이었습니다. 이전의 액세스 제어 목록은 각 열에 단일 출발지, 단일 목적지, 단일 서비스만 지원했습니다. 다중 객체 지원은 각 규칙을 더욱 강력하게 만들었고, 정책 편집은 새로운 규칙을 만드는 것이 아니라 기존 규칙을 수정하는 작업이 되는 경우가 많아졌습니다. 이 정책 편집기의 상당 부분은 또 다른 진전인 중앙 객체 저장소를 전제로 하고 있었습니다.

Check Point 중앙 객체 저장소

과거에는 액세스 제어 목록을 출발지 또는 목적지에 대한 특정 IP 주소를 참조하여 작성했습니다. 이 방식은 작동했지만, 시스템의 IP가 변경되면 모든 규칙을 업데이트해야 했습니다. Check Point는 재사용 가능한 소스 코드와 유사하게, 중앙 객체 저장소를 만들고 그 객체를 규칙에 사용하는 것이 더 나은 전략임을 깨달았습니다. 이제 호스트의 IP가 변경되면 객체만 업데이트하면 되었고, 정책이 저장된 객체에 대한 참조를 사용했기 때문에 해당 업데이트가 정책에 자동으로 올바르게 반영되었습니다. 또한 이러한 객체의 그룹(그리고 그룹의 그룹)을 만들어 정책 전반에서 공통 객체 그룹을 재사용할 수 있었습니다. 이는 보다 효과적인 정책 관리를 위한 중요한 발전이었습니다.

중앙 집중식 로깅

방화벽에서 매우 흔한 문제는 잘못된 트래픽을 차단하는 것입니다. 특히 이전에 분리되지 않았던 두 네트워크 사이에 방화벽을 배치할 때 그렇습니다. 90년대 후반에는 거의 모든 신규 방화벽 배포가 이런 경우였습니다. 모든 방화벽 로그를 중앙에서 수집하고 손쉽게 검색할 수 있게 되면서 정책 오류 진단이 매우 명확하고 비교적 간단해졌습니다. 사용자가 문제를 보고하고 출발지 IP / 목적지 IP 조합을 제공하면, 관리자는 로그 뷰어에서 "drop" 로그와 해당 차단을 유발한 규칙을 찾을 수 있었습니다(또는 "accept" 로그를 찾아 사용자에게 잘못 알고 있다고 알려줄 수도 있었습니다). 방화벽 정책 관리에서 실수는 과거에도, 지금도 흔하기 때문에 손쉬운 문제 해결은 모든 방화벽 플랫폼의 핵심 부가 가치였습니다.

멀티 도메인 관리 및 OPSEC

2000년대 초, Check Point는 Provider-1을 통한 멀티 도메인 관리와 OPSEC을 통한 통합 API를 도입하며 관리의 힘에 더욱 집중했습니다. 두 가지 모두 Check Point를 다른 방화벽 경쟁사와 차별화하기 위해 관리의 힘에 건 중대한 베팅이었고, 실제로 효과가 있었습니다. Provider-1은 이름에서 알 수 있듯이 프로바이더 업계, 즉 통신 사업자 및 관리형 서비스 제공업체를 대상으로 했습니다. 프로바이더가 이 기술의 초기 도입자였지만, 기업들도 곧 이 제품을 사용할 이유를 찾아냈습니다. 권한 제어, 대규모 정책과 객체 데이터베이스를 분할함으로써 얻는 관리 및 UI 성능, 전역적으로 적용하고 시행할 수 있는 전역 규칙 등 주요 기능은 모두 대기업이 원하던 핵심 기능이었습니다. 이는 상당 부분 표준 관리 플랫폼의 한계였습니다. 고객에게 Provider-1에 대한 상당한 추가 비용을 요구하는 대신 Check Point가 관리 플랫폼을 개선했어야 한다고 주장할 수도 있겠지만, 고객은 그 이점을 인식하고 이러한 고급 관리 기능에 기꺼이 비용을 지불했습니다. OPSEC은 서드파티 제품 통합을 장려하기 위해 Check Point가 공개한 파트너 프로그램이자 API 모음이었습니다. 초기 성공 사례로는 Log Export API(LEA)를 사용한 리포팅 제품, URL Filtering Protocol(UFP)을 사용한 URL 필터링 제품, 그리고 Check Point Management Interface(CPMI)를 사용한 FireMon과 같은 관리 제품이 있습니다. 이 프로그램과 통합은 큰 성공을 거두었습니다. 오늘날 100곳이 훨씬 넘는 OPSEC 파트너가 이 플랫폼과의 통합 기능을 제공하고 있습니다. 이러한 보안 제품 생태계는 고객에게 추가적인 가치와 투자에 대한 확신을 제공합니다. 오늘날 우리는 API 통합을 당연하게 여기지만, OPSEC이 출시된 2001년에는 결코 그렇게 흔한 일이 아니었습니다.

Cisco와 CLI는 지배적인 주자였다

시장이 Check Point와 GUI에 의해 완전히 지배된 것은 아니었습니다. Check Point가 강력하고 사용하기 쉬운 GUI로 방화벽 시장의 리더로 자리 잡는 동안, Cisco는 Pix의 명령줄 인터페이스(CLI)로 자신의 뿌리에 충실했습니다. Pix는 1994년으로 거슬러 올라가는 방화벽 시장의 초기 경쟁 제품으로, 1995년 Cisco에 인수되었습니다. 네트워크 관리자에게 익숙한 Cisco와 CLI 덕분에, 네트워크 팀이 보안을 담당하는 경우 Pix가 선호되는 선택이었습니다. Check Point는 보안 기능과 GUI로 이 우위를 조금씩 잠식해 나갔고, 보안이 네트워크 팀과 분리된 별도 조직이 되는 기업 조직 구조의 완만한 변화가 이를 뒷받침했습니다. 이러한 변화가 진행되면서 Cisco가 네트워크 팀과 맺고 있던 기존 관계는 방화벽 벤더 선정에서 점점 더 작은 역할만 하게 되었습니다. 강화된 관리 기능은 Check Point의 시장 내 입지를 확립하는 데 기여했고 보안 제품에서 관리의 가치를 재확인시켰습니다. 그러나 90년대에 성능이 Check Point가 프록시를 이기는 데 도움이 되었던 것처럼, 이후 몇 년간 성능은 다시 한번 핵심 결정 기준이 되었고 이번에는 Check Point가 위협을 받게 됩니다. 3부: 성능이 무대 중앙에 서다