올인원 보안 어플라이언스(all-in-one security appliance)는 장비 관리 부담을 가중시키지 않으면서 수많은 위협들로부터의 보호 기능을 제공한다.
우리 조직에 맞는 모델은 어떻게 선택할지 알아보자.

배치하고 관리해야 하는 네트워크 어플라이언스를 일부러 더 필요로 하는 사람이 있겠는가? 장비가 늘어나는 것은 어찌할 수가 없으며, 통합 네트워크 관리 방안에 속해 있는 수많은 제품들을 다뤄야 할 때면 사태는 훨씬 더 심각해진다.
조직의 통계치와 고성능 네트워크 필요조건은 기능성을 별도로 유지해야 한다는 주장을 뒷받침해 주겠지만, 전문 장비들의 종류가 늘어남에 따라 ‘모든 기능을 각자의 장비로 처리한다’는 방안에는 한계가 드러나고 있다. 분명 위협의 수가 늘어남에 따라 방어 부대도 늘어나야겠지만, 종류를 늘이지 않고 효과적인 보안을 달성할 수 있는 방법은 없을까? 올인원 보안 어플라이언스들이 여기에 대한 해답을 제시하고 있다.
올인원 보안 어플라이언스란 어떤 장비인가? 이것은 바이러스, 웜, 스파이웨어, 애드웨어, 스팸 및 트로이 목마 등과 같은 멀웨어(malware)에 대한 보호에서부터 시작되며, 방화벽과 콘텐츠 필터링(최소한 웹과 이메일 트래픽용으로)뿐만 아니라, 침입 탐지 및 방지 기능도 제공된다. 그리고 이 패키지는 VPN 종료, 지능형 로그 분석 및 보고, 애플리케이션 인지(application awareness: 데이터베이스 엔진이나 엔터프라이즈 메시징과 같은 애플리케이션에 보호 기능 연결) 등과 같은 기능들로 마무리가 된다. 그러면 이제 완벽한 보안 시스템을 하나의 박스로 갖추게 된 것이며, 이 어플라이언스는 네트워크가 요구하는 대로 열심히 따라서 작동할 것이다.

배치 모델의 차이
올인원 보안 어플라이언스를 구입하기 전에 고려해야 할 몇 가지 요소들을 살펴 보자. 우선 배치 모델이 있는데, 즉 어플라이언스가 보호되는 서비스와 인라인으로 배치돼야 하는지, 아니면 프록시 구성으로 배치가 가능한지 여부를 살펴야 한다. 인라인 구성이 네트워크 아키텍처적으로는 더 간편하겠지만, 이것은 장비에 단일 오류지점을 가져다 주며, 이렇게 되면 자동 페일오버 모드로 두 개의 장비를 배치해야 하는 추가 경비를 물게 될 확률이 높다.
프록시 구성의 경우 네트워크 관리자의 입장에서는 일이 더 많아지는데, 그 이유는 보안 어플라이언스의 어드레스가 보호되는 모든 데이터 유형(웹이나 이메일 등)에 대한 타깃으로 주어져야 하기 때문이다. 장비 오류로 인해 네트워크가 차단되는 일은 없겠지만, 어플라이언스가 개별적인 패킷을 조사하는 방식과 패킷이 어플라이언스로 도달하게 허용하는 방화벽 구성 요건(별도의 방화벽일 경우)에 한계가 있다. 클라이언트가 다른 프로토콜과 트래픽 조합을 이용해 보안 스캐닝을 피해가는 일을 막기 위해, 필터링되는 유형의 트래픽만이 올인원 장비를 통과할 수 있다.
올인원 보안 어플라이언스는 그 정의대로 패킷 콘텐츠가 좌우되고 애플리케이션 레이어를 포함하는 딥 패킷 점검(deep packet inspection)을 통해 규정 위반을 조사하는 기능이 있다. 이 장비의 성능은 구성에 관계없이 장비가 수상쩍은 패킷의 행동 코스를 파악하기 위해 그 주변을 검토해야 하는 패킷이 얼마나 많으냐에 따라 적어도 부분적으로 좌우된다. 인라인과 프록시 구성은 둘 다 장비로 하여금 패킷 스트링을 볼 수 있게 해주며, 어떤 것이든 저장 후 전송(store-and-forward) 기술을 이용해 수상한 패킷이 식별된 후에는 이전 패킷을 사용할 수 있도록 보장해 줄 것이다.
한편, IDS/IPS(Intrusion-Detection/Prevention System) 기능이 어플라이언스 애플리케이션 스위트의 일부일 경우에는 보다 복잡한 상황이 벌어진다. IDS와 IPS는 둘 다 규정이 위반됐는지 여부를 확인하기 위해 네트워크의 양쪽 로케이션에 있는 트래픽의 패킷을 필요로 하며, IPS의 경우 조사 결과에 따라 접속을 재설정, 차단, 혹은 속도를 제한할 수 있는 능력이 있다. IDS와 IPS의 기능성이 포함된 어플라이언스라면 인라인과 프록시 배치 옵션을 모두 제공하겠지만, 그 능력은 다양할 것이다. 필요한 기능이 선택한 배치 모델에서 이용 가능한지 확인해 보라.

수적인 차이
데이터 스트림에 적용되는 기능의 수는 어플라이언스의 성능에 영향을 미칠 것이다. 그리고 어플라이언스가 갖고 있는 프로세서의 양에 따라 막대한 성능 차가 생길 수 있다. 이것이 각각의 기능용으로 별도의 프로세서나 맞춤 실리콘을 갖고 있는가, 아니면 하나의 다용도 CPU에게 모든 것을 처리하라고 요청하는가?
검토되는 프로토콜이 많아질수록 이것은 매우 중요한 문제가 되는데, 그 이유는 어플라이언스 성능이 느려지면(특히 온라인 배치에서) 사용자들이 경험하는 네트워크 성능은 훨씬 더 느려질 수 있기 때문이다. 안티멀웨어 스캐닝과 같은 보다 복잡한 기능들은 프로세싱 오버헤드를 추가시키는 반면, 프로토콜과 어드레스 정보를 기반으로 한 간단한 예스/노 결정(대부분의 방화벽에서 볼 수 있는 기능들 같은)은 보통 성능에 미치는 영향이 한정돼 있다.

시그니쳐 업데이트와 맞춤 규정
필요에 맞게 어플라이언스의 성능을 조절하고, 새로운 위협에 맞게 능력을 업데이트 시키기 위해서는 두 가지 부문에 특히 신경을 써야 하는데, 그것은 바로 시그니처 업데이트(signature update)와 맞춤 규정(custom-rule) 생성이다. 조직들은 보안 장비가 인터넷에 액세스할 수 있는 방법에 대해 매우 다양한 규정들을 갖고 있다.
시그니처는 어플라이언스 안에 있는 여러 가지 기능 부문들용으로 사용될 수 있기 때문에 어플라이언스가 그 시그니처 데이터베이스를 업데이트하는 데 어떤 메커니즘을 사용하는지 물어보아야 한다. 업체측에서 시그니처가 아니라 행동 모델(behavioral model)을 사용한다고 말하더라도 새로운 위협을 해결하기 위한 업데이트에 대해 물어보라.
조직들은 IDS, IPS 및 콘텐츠 필터링과 같은 기능을 위한 맞춤 규정을 만들기 위해 많은 메커니즘들을 사용한다. 어떤 어플라이언스는 필요조건에 맞지 않을 수 있는 규정 컴포넌트 리스트들로부터 선택할 수 있는 능력만 제공함으로써, 맞춤화가 많이 되는 규정을 만들기 힘들게 하기도 한다.
규정 생성 프로세스를 신중하게 검토하고, 많은 맞춤 규정들이 어플라이언스 성능에 어떤 영향을 미칠 수 있는지를 물어보라. 이런 기능을 사용할 계획이라면 직원 교육에 들어가는 시간도 감안해야 하는데, 그 이유는 적당한 규정을 만들기 위해서는 네트워크 프로토콜과 보안 위협의 본성에 대한 포괄적인 지식이 필요하기 때문이다.

보고서 만들기
장비 관리와 보고서 생성은 성능만큼의 비중은 아니겠지만, 공격과 이에 관련된 네트워크 활동을 상세히 열거할 수 있는 능력은 보안 유지에 필수다. 예를 들어 HIPAA나 GLB 등과 같은 규정 준수가 기본이 돼야 하는 업계에서는 감사 필요를 충족시키는 보고서 포맷을 제공하는 어플라이언스를 통해 일이 훨씬 수월해질 것이다. 외부용으로 특정 보고서 포맷이 필요치 않다 하더라도 어플라이언스가 문제를 진단하는 데 도움을 주고, 사건이 발생하는 필연적인 경우를 위해 포렌식스(forensics)를 지원하는지 반드시 확인해야 한다.
웹 기반 관리 인터페이스용으로 어떤 브라우저가 지원되는지와 같은 작은 것에서부터, 어플라이언스가 유니센터(Unicenter), 티볼리(Tivoli), 오픈뷰(OpenView), 혹은 다른 어떤 엔터프라이즈 네트워크 관리 툴에 의해 만들어진 관리 프레임워크에 맞게 작동하는지와 같은 큰 것에 이르기까지 모두 주의를 기울여야 한다. 올인원 어플라이언스는 유용한 네트워크 보안 툴일 수 있겠지만, 이것이 기존의 관리 인프라에서 따로 떨어진 섬이 된다면 아무런 소용이 없다.