문서를 좋아하는 사람은 없지만, 보안은 프로세스에 따라 향상될 수 있다. 라우터, 부하조절기 및 서버에서 구성을 바꾸기 이전에, 관리자의 관점에서뿐만 아니라 고객이 보는 애플리케이션의 관점에서도 인프라에 있는 각 장비에 대한 액세스 권한을 세분화할 필요가 있다.
다음과 같은 필요한 정보들을 파악하라.
■ 누가, 어떤 서비스, 애플리케이션, 데이터로의 액세스를 필요로 하는가.
■ 액세스가 어디서 비롯되는가? 외부인가, 내부인가?
■ 액세스가 가능해야 할 필요가 있을 때는 언제인가? 업무 시간 아니면 업무 시간 후인가?
■ 보호하려고 하는 정보는 어떤 것인가? 정책을 만들려면 우선 당신이 무엇을 보호하려 하고 있는지를 알아둘 필요가 있다. 이것은 세부적인 분석 작업이 되어야 한다. 만약 여러 비즈니스 파트너와 고객을 보유하고 있다면, 고객을 구분함으로써 고객 X가 고객 Y에게 기밀인 정보로 액세스할 수 없게 보장할 필요가 있을 것이다.
비바 인티그리티 모델(Biba Integrity Model)과 클라크 윌슨 인티그리티 모델(Clark-Wilson Integrity Model)을 포함해, 이런 정책을 만드는 데 사용할 수 있는 많은 모델들이 있다. 하지만 특정 방법을 이용하지 않더라도 정책이 문서화 돼 있도록, 그리고 이행 및 배치 동안에 이것을 참조해야 할 조직 내 기술자들이 입수할 수 있도록 보장해야 한다.
일단 정책이 만들어지면, 정책과 인프라 보안을 보조해줄 툴에 대한 정기적 분석 일정을 짜라. 최소한 분기당 한번씩은 정책과 이러한 정책 시행에 있어서의 효율성을 점검해볼 필요가 있다.
SSL, 과연 안전한가?
일부 회사들은 SSL(Secure Sockets Layer)이 모든 보안 위험을 가라앉혀 줄 것이라는 그릇된 믿음을 갖고 있다. SSL은 비즈니스 트랜잭션을 엿듣는 사람이 없도록 보장하는 데는 좋지만, SSL 전략의 일부로 클라이언트 증명서를 사용하지 않을 경우에는 트랜잭션이 전달 중일 때 여기에 대한 보안 담요 외에는 별다른 것을 얻지 못할 것이다. 클라이언트측 증명서는 사용자 이름 및 패스워드 조합보다도 더 믿을 수 있는 인증 방안을 제공한다. 액세스용으로 클라이언트 증명서를 요구할 경우 누군가 허가된 사용자를 흉내내기가 더 어려워지며, 당신의 데이터로 액세스를 시도하는 사람이 누구인지를 확실히 알고 있음으로써 보다 강도 높은 보안이 가능하다.
SSL 기반 커뮤니케이션은 보안 전략의 다른 부분들을 가로막을 수 있다. 대부분의 IDS(Intrusion Detection System)와 바이러스 스캐닝 서비스들은 SSL과 상호작동할 수 없으며, 따라서 암호화된 트래픽은 질문 없이 통과를 허가받는다. 여기서 필요한 것은, 암호화된 트래픽이 에지 보호 장비에 의해 검토된 다음 후방 인프라로 전달되도록 하는 메커니즘을 제공하는 약간 다른 아키텍처다. 여기서는 모든 논리적 접속용으로 두 개의 물리적 접속이 이루어진다. 클라이언트는 장비로 접속하며, 장비에서 서버로 또 다른 접속이 이루어짐으로써 어떠한 클라이언트 요청이건 충족시켜준다.
이러한 아키텍처는 코 어플라이언스(co-appliance) 혹은 사이드 암(side-arm) 구성으로 종종 불린다. 트래픽 관리 장비(보통 부하조절기)를 사용함으로써, 아주 힘들게 만들었던 이러한 보안 정책들을 따를 수 있는 방안을 제공할 수 있다.
이러한 구성에서 SSL 암호화 트래픽은 처음에 SSL 어플라이언스로 향해짐으로써 암호해독이 되어 IDS 및 바이러스 스캐닝 서비스에 의해 점검될 수 있다. 일단 이 외피를 통과하면 트래픽은 다시 부하조절기/컨텐츠 스위치로 전달되어 당신의 서버로 보내진다.
이러한 기능성을 제공하는 또 한 가지 방법은 트래픽 디렉터(traffic director)가 SSL 세션을 종료할 수 있게 하는 것이다. 트래픽 디렉터로 작동하는 장비는 SSL 접속에 대해 역 프록시(reverse proxy)로서 구성되어 자신과 클라이언트 사이에 있는 모든 암호화 및 비암호화 서비스들을 처리할 것이다. 이것은 외장 SSL 어플라이언스의 필요를 없애주지만, 다른 문제를 야기한다. 즉, 액세스의 권한부여를 위해 클라이언트 증명서를 사용할 경우, 이들은 당신의 애플리케이션 서버가 아니라 트래픽 관리 장비에 의해 인증될 것이다. 단 F5 네트웍스의 빅-IP와 같이 사용자 증명서를 HTTP에 삽입시켜주는 기능을 갖춘 트래픽 관리기를 사용하고 있을 경우는 예외다.
일부 업계에서는 후방 웹 서버로 향하는 모든 길에 SSL 세션을 지속시킬 필요가 있을 것이다. 특히, 금융 및 은행업무 기관들은 내부에서건 외부에서건 관계없이 모든 트랜잭션들이 암호화될 것을 요구하는 엄격한 보안 규정 아래 놓인다. 이런 상황에 있는 사람이라면, 클라언트에서 SSL 세션을 종료할 수 있고, 인프라보다 깊이 있는 장비에서 SSL 접속을 초기화시킬 수 있는 트래픽 디렉터가 반드시 필요하다. 이런 식의 구성은 트래픽 디렉터가 클라이언트 증명서를 사용할 수 있을 경우 더 큰 혜택을 준다. 클라이언트 증명서는 보다 안전한 신원확인 방안을 제공함으로써 보호 기능을 해주기 때문이다. 이것은 완벽한 솔루션은 아니지만(증명서는 디스크에 저장되는 경우가 많으며, 이런 디스크들은 도난이 가능하다), 아무 것도 없는 것보다는 안전하다. 이 방법을 선택하고, 후방 서버로 접속하기 위해 클라이언트 증명서를 요구한다면, 외부에서 서버로의 직접 접속을 막을 수 있다.
