It's My Life(마이라이프)

웹사이트 소유자들은 웹의 취약점을 알고는 있지만 악성해커와 유해한 코드로부터 침해당하는것을 원치는 않습니다. 대부분의 웹사이트가 웹 취약점으로 인해 위험에 노출되어 있음에도 불구하고 이에 대한 정보의 부족, 고가 장비도입의 어려움 등으로 손을 못쓰고 있는 실정입니다.

현재 수천가지의 취약점과 공격방법이 전세계적으로 발견되었고 이에 대한 보안이 필요합니다.
많은 호스팅회사들은 방화벽 및 IDS, IPS등의 L4단의 보안시스템을 가지고 고객들의 서버를보호하지만 불행히도 방화벽등의 L4 장비는 웹 어플리케이션 방어에 충분하지 않습니다.

최근 뉴스와 언론에 보도되었듯이 기업체의 정보유출 및 기밀 서류 등이 국내외 해커들에 의해 기업들과 개인사용자들이 피해를 입고 있습니다.

 웹 보안이란?

 웹 방화벽의 필요성!
 

           IDS  차단 기능 부재, Network 계층의 취약점만을 분석!
           IPS  알려진 유형의 공격에만 보호가 가능!
           결국, 웹 방화벽 만이 변화하는 공격에 대응이 가능합니다!
  
  일반방화벽과 웹방화벽의 비교! 

네트워크 트래픽을 보호하기 위한 표준 보안장비는 방화벽(Network Firewall), 침입 방지 시스템(Intrusion Prevention System 이하 IPS), 침입 탐지 시스템(Intrusion DetectionSystem 이하 IDS)이 있으나 어플리케이션 레벨의 공격을 위한 솔루션은 포함되어 있지 않습니다.

대부분의 기업들은 인터넷상의 수많은 위협에 노출되어있습니다. 그러나 네트워크 방화벽으로 보호받고 생각하기 때문에 웹을 통한 공격에 대해서 잘알지 못하고 무방비인 상태라는 것이 큰 문제입니다.

사실 웹 방화벽은 고가의 장비이기 때문에 많은 기업들이 장비를 도입하기에는 어려움이 따랐던 것이 사실이었습니다.
그러나 최근에는 다양한 하드웨어 장비 뿐 아니라, 금전적 부담이 적은 ASP(SaaS)형태의 소프트웨어 웹 방화벽도 서비스가 가능하여 선택의 폭이 다양해졌습니다.

인터넷 공격의 75% 이상을 차지하는 SSO, SQL Injection 등의 어플리케이션 공격에 대비하여 기존의 네트워크 방화벽 뿐 아니라 웹 취약점 분석을 통한 소스의 수정이나 웹 방화벽도입 등의 적극적인 대처가 필요할 것입니다.

[SSL의 개념]

일반적인 웹사이트에서 HTTP를 사용한다면 아래 그림과 같이 보안이 전혀 고려되지 않은 채로 패킷이 교환된다. 중간에 해커가 가로챘을 경우에 어떻게 해볼 도리가 없다. 예를 들어 amazon.com에서 신용 카드를 사용해서 책을 구매했다고 할 때 일반 사용자가 입력한 카드번호는 수많은 경로를 거치게 된다. 아마 수십 개의 라우터를 거쳐야만 amazon.com의 웹 서버와 정보를 교환할 수 있을 것이다. 이렇게 개방된 환경에서 중요한 데이터를 그냥 보낸다는 것은 위험한 일이며 적절한 보안이 반드시 필요하다고 할 수 있다.

앞의 네트워크의 개념에서 다룬 내용이지만 다시 한번 설명하면 네트워크에 연결된 각각의 컴퓨터가 서로 패킷을 교환하기 위해서는 여러 개의 레이어를 둔다고 하였다. TCP는 데이터가 적절하게 전송이 되었는지 확인하는 역할을 하고, IP는 각각의 데이터가 정확한 위치로 배달되도록 도와주는 역할을 한다. HTTP는 단지 웹 브라우저와 웹 서버간의 데이터 교환을 위한 규약이다. 패킷에 대한 보안을 강화하기 위해서 오른쪽 그림에서는 SSL이라는 통로를 지나가도록 한다. 웹 브라우저나 서버의 입장에서는 기존의 HTTP 프로토콜에 전혀 변화를 주지 않은 채로 SSL이라는 통로를 패킷이 지나가도록 하면 보안에 대한 처리가 이루어진다. 이것이 SSL의 개념이다. 영어에서도 알 수 있듯이 하나의 보안을 위한 ‘레이어’ 역할을 하는 것이 SSL이다. SSL은 HTTP 프로토콜 이외에 많은 어플리케이션 레이어의 프로토콜을 지원한다.

패킷을 암호화하기 위해서 사용하는 방법은 SSL 이외에 Secure HTTP와 같이 HTTP 자체에 보안 기능을 넣는 방법과 IPSEC과 같이 IP에 보안을 추가하는 방법도 있으나 가장 널리 사용하는 방법은 역시 SSL이다.

해킹을 통해서 실력을 인정받고 싶어하는 해커가 많은데 반해, 현재 SSL에 대한 해킹이 이루어졌다는 이야기가 들리지 않는 것으로 보아 SSL은 해킹에 대해서 매우 정교한 구조를 가지고 있다고 할 수 있다.

단순히 패킷을 암호화 시켜서 보내고, 받는 쪽에서는 패킷을 다시 해석해서 사용하는 구조라면 SSL은 이미 해커에 의해서 해킹이 되었을 것이다. 그러나 SSL은 이외에 별도의 과정을 거쳐서 데이터를 안전하게 보낼 수 있는 기능을 제공하고 있다.

[보안 통신의 구성 요소]

암호화 방법에 대해서는 수천 년간의 관심거리였다. 아무래도 인간이 비밀리에 작업하는 일이 많기 때문이 아닌가 한다. 한 쪽에서는 “어떻게 암호화를 할 것인가”가 관심거리인 반면 다른 한쪽에서는 “어떻게 암호를 풀것인가”였다. 일반적으로 안전한 통신을 위해서는 다음과 같이 세 가지가 만족되어야 한다.

(1)보내고자 하는 내용을 특정 사람만 읽을 수 있어야 한다.

(2)받는 사람은 보낸 사람에 대해서는 신뢰를 할 수 있어야 한다.

(3) 주고받는 정보가 변형되지 않아야 한다.

위 세 가지의 조건을 만족해야 정말 안전하게 메시지가 교환되었다고 할 수 있다. 그럼 각각의 조건을 만족시키기 위해서 어떤 방법이 사용되는지 알아보도록 하자.

첫 번째, 보내고자 하는 내용을 특정 사람만 읽을 수 있어야 한다는 것은 내용을 누구나 닑을 수 없고 수신인만 읽을 수 있도록 암호화되어야 한다는 것이다. 고구려의 유명한 설화인 바보 온달 이야기에서 평강공주가 아버지인 평원왕의 눈을 피해 사랑의 메시지를 보낸다고 가정해 보자. 평강공주는 바보온달과 메시지를 교환하기 위해서 비밀 코드를 만들었다.

두 사람은 서로 만나는 약속을 하는데 필요한 정보를 위와 같이 암호화해서 보내고 자신들이 보낸 메시지는 코드표가 있어야 읽을 수 있기 때문에 평강공주는 자신이 보낸 메시지는 바보온달만 읽을 수 있다는 것을 믿을 수 있게 된다. 물론 실제 세계에서 암호화를 이렇게 단순하게 하지 않는다.

그럼 바보온달은 메시지가 평강공주로부터 온 것을 어떻게 확신할 수 있을까? 평강공주와 바보온달 사이에 메시지를 교환할 때 서로 특정 사인을 뒷면에 적기로 했다면 바보온달은 평강공주로부터 온 메시지가 평강공주로부터 온 것을 확신할 수 있게 된다. 이런 식으로 두 번째 조건인 ‘받는 사람은 보낸 사람에 대해서 신뢰를 할 수 있어야 한다.’를 만족할 수 있다.

그런데 메시지에서 MCM9라는 메시지를 중간에 누군가가 빼서 보낸다면, 가장 중요한 정보가 빠지고 그냥 ‘사랑한다’라는 단순한 편지가 되어버리고 만다. 바보온달이 메시지를 받을 때 정말 평강고주가 보낸 메시지에 누가 빼거나 더하지 않았는지 어떻게 믿을 수 있을까? 메시지가 변경되지 않았다는 것을 확인하기 위해서 hash 함수를 사용한다. 전체 메시지에 대해서 hash 함수를 돌리게 되면 유일한 값을 얻을 수 있다. 평강공주는 이 값을 메시지에 비밀값으로 적어놓는다. 메시지를 받은 바보온달은 다시 받은 메시지를 hash 함수에 넣고 돌린 결과가 평강공주가 적어 놓은 값과 일치하면 메시지가 변경되지 않았다고 믿을 수 있게 된다. 만약 평원왕이 메시지를 가로채 수정해서 바보온달에게 보낸다면 바보온달은 수정된 메시지를 hash 함수에 넣게 되고, 그 결과가 평강공주가 보낸 것과 일치하지 않기 때문에 메시지가 수정되었다는 것을 알게 된다. 보통 흔히 사용하는 hash 알고리즘으로는 MD5(Message Digest5)와 SHA(Secure Hash Algorithm)이 있다. 시스템 엔지니어의 입장에서는 이 알고리즘을 알 필요는 없을 것 같다.

[암호화의 종류]

암호화의 방법은 크게 두 가지로 나눌 수 있다. ‘비밀키 암호화’ 방법과 ‘공개키 암호화’ 방법으로 나눌 수 있다.

비밀키를 사용해서 암호화를 하는 경우는 앞에서 평강공주와 바보온달의 사랑의 메시지 예제에서 볼 수 있듯이 두 사람 모두 암호를 해독할 수 있는 키를 가지고 있어야 하기 때문에 ‘대칭적 암호화’라고 부른다. 이에 비해 ‘공개키 암호화’ 방법은 두 사람이 다른 키를 가지고 메시지를 주고받기 때문에 ‘비대칭적 암호화’라고 부른다.

=======================================================================

[TIP]

[키란 무엇인가?]

암호화에 대한 이야기가 나오면 반드시 나오는 용어가 바로 ‘key’라는 용어이다. 한국어로는 ‘열쇠’로 번역할 수 있다. 물론 번역을 하지 못하는 독자는 없을 것이다. 그런데 ‘열쇠’라는 단어 속에 키에 대한 모든 의미가 들어가 있다. 우리가 열쇠를 사용하는 이유는 열쇠를 가지고 있는 사람들만이 금고를 연다든지 집의 문을 연다든지, 또는 반대로 금고를 닫고 집의 문을 닫기 위해서이다. 이와 마찬가지로 암호화해서 나오는 키는 해당 메시지를 암호화, 해독하기 위해서 특정 사람들만 가지고 있는 열쇠가 바로 ‘key’이다.

===============================================================================================

[“비밀키 암호화” 기법]

대칭적 암호화는 메시지를 주고받는 두 사람간에 똑 같은 키(대칭적 키)로 암호화를 하고 다시 이 키를 통해서 해독을 하기 때문에 ‘대칭적 암호화’ 방법이라고 이전에 설명하였다. 위의 그림을 보면 데이터를 암호화하는 데 쓰이는 키와 암호를 해석하는데 쓰이는 키가 똑같다. 대칭적 암호화는 역사적으로 일반화된 암호화된 기법이라고 할 수 있다. 메시지를 교환하는 사람들만이 비밀키를 공유하고 있다면 메시지는 안전하게 교환된다고 믿는 방법이다. 그러나 컴퓨터의 세계에서는 키라는 것이 비트의 나열로 나타낼 수 밖에 없다. 키의 크기가 작다면 아무래도 다른 사람이 키를 알아낼 수 있는 확률은 높아진다. 우리가 집에 열쇠를 달 때 보조키를 사용하느냐 생체 인증 시스템을 사용하느냐와 같은 암화 수준을 말하는 것이다. 현재 전자 상거래에서 사용하는 SSL은 56비트와 128비트가 있으나 아무래도 128비트 암호화키를 사용하는 것이 훨씬 높은 수준의 보안을 제공하는 것이다.

[“공개키 암호화”기법]

앞서서 이야기한 비밀키 암호화 기법은 한 가지 중대한 문제를 가지고 있다. 적어도 한번은 평강고주와 바보온달이 만나서 요런 요런 키를 우리끼리만 사용을 하자는 합의를 해야 한다. 그러나 인터넷 환경에서는 두 사람이 만나서 서로의 키를 주고받고 이런 키를 사용해서 서로 메시지를 주고받자고 합의를 할 수가 없다. 또, 온라인 상으로 이 키를 주고받다가 이 키가 해킹을 당했을 경우 나머지 메시지의 안전을 보장할 수가 없다.

이런 문제점 때문에 요즈음 나온 것이 바로 ‘공개키 암호화’ 기법이다. 공개 암호화 기법은 기존의 비밀키 암호화 기법과 같이 메시지를 교환하고자 하는 두 사람이 모두 같은 키를 가지고 있지 않는다. 따라서 ‘비대칭적 암호화’라고 부른다. 두 사람이 가지고 있는 각각의 키를 ‘공개키’와 ‘개인키’로 부른다. 공개키는 여러 사람이 모두 공유할 수 있는 키이고 개인키는 오직 한 사람만이 가지고 있는 키이다. 이런 공개키에 기반한 암호화 구조를 PKI라고 부른다. 앞에서 설명한 평강공주와 바보온달의 이야기를 조금 더 진행해 보겠다. 평강공주가 몰래 넣어둔 비밀 코드를 그만 아버지에게 들켜 더 이상 이전의 방법으로는 안심하고 연애 편지를 쓸수가 없어서 바보온달은 새로운 방법으로 편지를 교환하기로 했다. 바보온달이지만 꽤 똑똑하다.

바보온달은 개인키와 공개키를 만든다. 공개키로 암호화된 데이터는 개인키를 이용해서만 해석할 수 있어야 한다. 물론 개인키로 암호화된 데이터는 공개키를 사용해서 해석할 수 있다. 그리고 바보온달은 성문 앞 게시판에 자신이 만든 공개키를 대문짝만하게 붙인다. 평강공주는 그 공개키를 받아 자신이 보내고자 하는 메시지를 공개키를 이용해서 암호화한다. 평강공주는 자신의 메시지를 해독할 수 있는 사람은 오직 바보온달이기 때문에 안심하고 데이터를 보낼 수 있게 된다.

===============================================================================

[NOTE]

[디지털 서명]

앞의 바보온달과 평강공주의 이야기에서 서로의 메시지가 변경되지 않았다는 것을 확인하기 위해서 비밀값을 적어 놓는다고 했다. 이 비밀값을 보통 디지털 서명이라고 한다. 디지털 서명은 데이터가 수정, 변경되는 것을 막아준다.

해쉬 알고리즘을 사용하면 문서에 대해서 유일한 값(One-way hash)을 얻을 수 있다. 이 값을 개인키로 암호화해서 원래의 데이터와 함께 보낸다. 받은 쪽에서는 받은 데이터를 다시 똑 같은 해쉬 알고리즘을 사용해서 다시 유일한 값을 도출해 낸다. 그리고 보낸 사람으로부터 온 디지털 서명을 자신의 공개키를 사용해서 해석을 한 다음에 이전에 값과 비교를 해서 두 개가 일치를 한다면 문서는 변경이 되지 않았다는 것을 믿을 수 있게 된다.

===================================================================================================

바보온달과 평강공주는 이런 방법으로 몇 일간을 서로 편지를 통해서 이야기할 수가 있었다. 그러나 서로의 이야기가 길어지게 되자 암호화고 해석하는데 너무 많은 시간을 할애해야만 했다. 어떤 날은 A4 한 장을 해석하기 위해서 하루 종일 매달린 적도 있게 되었다.

공개키, 암호화 방법은 메시지를 주고받는데 확실한 보안을 제공하지만 암호화하고 해석하는데 시스템은 많은 비용을 치뤄야 한다. 따라서 인터넷을 사용할 때 모든 데이터를 암호화해서 보낸다는 것은 시스템에게는 엄청난 부하를 주게 된다.

다시 바보온달과 평강공주의 이야기로 돌아가 보자. 암호화하는데 너무 많은 시간이 걸리자 평강고주는 더 좋은 방법을 생각해 냈다. 기존에 사용했던 방법과 새로운 방법을 조합하기로 한 것이다.

위의 그림에서 볼 수 있듯이 서로가 메시지를 주고받기 위한 단계는 많아졌지만 비밀키를 한번만 교환하게 되면 다음 메시지를 주고받을 때에는 훨씬 간단해진다는 점이 평강공주가 바보온달보다는 한수 위라는 것을 보여준다.

비밀키라는 것이 등장하고 이 비밀키를 서로 주고받기 위한 과정은 공개키를 사용한 방법과 동일하다. 그러나 메시지를 공개키를 사용해서 주고받는 것이 아니라 의사 소통을 위해서 필요한 코드와 같은 비밀키만을 주고받는다. 그리고 나서 이 비밀키를 가지고 의사 소통을 하면 되니 이전 보다 훨씬 암호화하고 해석하는 작업이 편해졌다고 할 수 있다.

[인증서와 CA(Certificate Authority)]

이제 바보온달과 평강공주는 안심하고 메시지를 주고받을 수 있게 되었을까? 답은 아니다. 지금까지의 과정을 예리하게 지켜본 독자라면 알 수 있겠지만 만약 성문 앞에 공개키를 붙여놓은 사람이 바보온달이 아니라 옆나라 왕자라면 큰일이 아닐 수 없다. 아무나 공개키, 비밀키를 만들 수 있는 상황이라면 공주의 입장에서는 성문 앞의 공개키가 바보온달의 것인지 아니면 옆나라 왕자가 바보온달인 척하며 붙여놓은 것인지 알 수가 없다.

온라인 상에서 카드를 입력했는데 사용자는 입력한 사이트가 신뢰할 수 있는 amazon.com이라고 믿었는데, 유령 회사였다면 사용자는 막대한 금전 손실을 입을 수밖에 없다. 이러한 문제를 해결하기 위해서 등장한 것이 CA(Certificate Authority)이다. 굳이 비유를 하자면 주민등록증을 발급해주는 동사무소와 같은 역할이다. 우리가 주민등록증을 믿는 이유는 곡가라는 신뢰할 수 있는 기관에서 발행한 신분증이기 때문이다. 여기서 국가에 해당하는 인터넷 기관이 CA이다. CA는 verisign이나 thawte와 같은 기관이 있다. 이처럼 공개키에 대해서 인증 기관이 인증서를 발부하고 그 기관이 인증서를 보장해준다면 인터넷과 같이 개방된 공간에서도 서로를 믿고 거래할 수 있게 된다. 반대로 인증서를 받은 사람이나 업체는 인증서를 다른 사람이 악용하지 못하게 보관할 책임이 있다. 이런 이유 때문에 인증서를 인증기관으로 받기 위해서는 대단히 까다로운 절차를 거쳐야 겨우 받을 수 있다.

인증 기관으로부터 인증서를 받게 되면 아래와 같이 인코딩된 데이터를 웹 브라우저에서 보여준다. 웹 브라우저에서 보이는 문자를 편집기에 그대로 복사해서 도메인이름.crt라는 이름으로 파일을 저장하면 인증 기관으로부터 인증서를 받은 것이다. 복사를 할 때에는 불필요한 문자가 들어가지 않도록 조심해야 한다.

위의 인코딩된 데이터를 사람이 읽을 수 있는 형식으로 바꾸면 아래와 같다. Issuer는 인증서를 발행한 기관의 이름이고 Validity는 인증서의 유효 기간이다. 읹,d서는 한번 받으면 영원히 유효한 것이 아니다. 보통 매년 인증서를 갱신해야 하는데, 갱신되지 않은 인증서는 사용할 수가 없다. Subject는 인증서를 받은 기관 또는 사람의 이름이며 Signature는 인증 기관의 서명이다.

이 파일을 윈도우 운영체제에서 탐색기를 통해 더블 클릭을 하면 보다 편하게 볼 수 있다. 첫번째 일반 탭을 보면 간략하게 인증서의 내용을 볼 수 있다. 발행 기관이 어디이고 누구에게 발행됐는지 유효 기간은 언제부터 언제까지인지를 알 수 있다.

두 번째 탭을 누르면 보다 자세한 인증서의 정보를 볼 수 있다. 위에서 설명한 인증서의 내용을 보다 편하게 요약해 놓은 것이다.

세 번째 탭을 눌러보면 인증의 계층 구조를 확인할 수 있다. 인증의 계층 구조에 대해서는 다시 설명하도록 하겠다. 현재는 바로 Thawte라는 인증 기관으로부터 인증을 받은 것으로 이해하고 넘어가도록 하자.

이제 앞에서 이야기하지 않은 인증 기관에 대해서 알아보도록 하자. 인증서를 발행하는 서버를 인증 서버라고 한다. 인증 서버는 모든 사람이 운영할 수 있다. 우리가 인증 서버를 운영하고 인증서를 발행한다고 하더라도 다른 사람이 내가 발행한 인증서를 믿지 못한다면 그 인증서는 무용지물이 되고 만다. 그러나 어떤 회사에서 인증 서버를 운영하고 있고, 이 회사 내의 모든 컴퓨터는 이 인증 서버로부터 발행된 인증서를 믿기로 했다. 이와 같이 사설 인증 서버를 운영하더라도 인증서를 사용하는 컴퓨터끼리 약속되어 있다면 개인 또는 특정 회사가 발행한 인증서는 유효하다. 하지만 우리에게 인증서가 필요한 곳은 익명성이 보장되는 인터넷이다. 이런 환경에서는 모든 컴퓨터가 신뢰할 수 있는 기관으로부터 발행된 인증서만이 유효하다. 따라서 인증서의 유효성은 얼마나 많은 컴퓨터가 그 기관을 신뢰하느냐가 중요한 이슈가 된다.

우리는 이런 인증기관을 보통 Root CA라고 부른다. 웹 브라우저를 처음 설치했다면 자신의 웹 브라우저에 기본적으로 설정되어 있는 Root CA를 확인할 수 있다. 인터넷 익스플로러의 [도구] 메뉴에서 [옵션]을 클릭한 후 [내용] 탭을 누른다. [내용] 탭 안에 있는 [인증서] 버튼을 클릭하면 다시 ‘인증서’ 다이얼로그 상자가 하나 더 뜨는데, 이 다이얼로그에는 현재 컴퓨터에 설치된 많은 인증서를 확인할 수 있다. 다시 [신뢰된 루트 인증기관] 탭을 누르면 많은 Root CA 인증서가 출력된다.

항목 중에 하나를 클릭하면 이 인증서는 다른 인증서와 약간 다르다. 다른 인증서의 경우는 발행 기관이 대부분 Root CA이고 발행 대상이 자신의 회사가 되는 반면에 인 인증서는 발행 기관과 발행 대상이 일치한다. Root CA의 경우는 자신이 발행을 하고 자신이 발행을 받기 때문에 일치한다. Root CA를 제외하고는 두 개의 항목이 일치할 수는 없다.

이제 인증이 계층적으로 이루어지는 관계에 대해서 이야기해 보자. 계측적 인증 구조를 보면 네트워크에 흐르는 정보를 지키는 것이 얼마나 효율적으로 이루어지고 있는지 알 수 있다. 인증서를 발행하는 것에 효율성을 높이기 위해서 인증서는 계층적으로 이루어져 있다. 아래 그림과 같이 Root CA는 자기 자신에 대해서 자기가 서명을 하는 인증 기관이다.

하위 인증 기관인 USA CA는 Root CA로부터 인증을 받고 Engineering CA는 USA CA로부터 인증을 받았다. 사실 Root CA를 제외한 다른 인증 기관은 클라이언트가 신뢰할 수 있는 인증 기관은 아니다. 그러나 인증 체인을 따라가면서 Engineering CA가 발급한 인증서도 신뢰할 수 있는 인증서로 클라이언트는 간주한다.

아래는 인증서를 확인하는 프로그램이 Engineering CA로부터 발급 받은 인증서 역시 유효하다는 것을 확인하는 절차에 대한 그림이다. 인증 체인(Certificate Chain Verification)은 주어진 인증서가 유효한 인증서인지 확인하는 절차를 말한다. 인증서를 검사하는 프로그램은 Engineering CA로부터 받은 인증서의 유효 기간이 남았는지 확인하고 Engineering CA가 신뢰할 수 있는 CA인지 확인한다.

Engineering CA가 신뢰할 수 없는 CA이기 때문에 Engi-neering CA에게 인증서를 발급해준 USA CA에 똑 같은 절차로 유효성 검사를 하게 된다. 하지만 USA CA는 신뢰할 수 있는 Root CA로부터 인증서를 받았기 때문에 인증 체인이 멈추고 Engineerring CA로부터 받은 인증서는 유효하다고 판단을 하게 된다.

한번 이런 절차를 거쳐서 인증된 Engineering CA는 신뢰할 수 있는 CA로 시스템에 등록되게 된다. 이러한 인증 기관을 중개 인증 기관(Intermediate CA)이라고 부른다. 자신의 웹 브라우저에 등록된 중간 인증 기관의 리스트를 보고 싶은 경우 이전에 보았던 ‘인증서’ 다이얼로그에서 [중개 인증 기관] 탭을 누르면 확인할 수 있다.

[SSL Handshake]

앞에서 바보온달 설화를 통해서 SSL 보안 통신 개념을 쉽게 설명을 하였다. 실제 클라이언트와 서버간의 통신은 바보온달과 평강공주의 메시지 전달과 유사하다. 이제부터는 지금까지 지식을 가지고 서버와 클라이언트간에 안전한 통신을 하기 위해서 어떤 과정을 거치는지 알아 보도록 하자.

핸드쉐이크에 대해서는 TCP 프로토콜을 설명할 때 언급하였다. SSL에서 핸드쉐이크를 하는 것은 TCP 프로토콜에서 핸드쉐이크를 하는 것과 비슷하지만 TCP가 단순히 데이터를 정상적으로 보내는데 초점이 맞추어져 있는 반면, SSL에서의 핸드쉐이크는 정보를 안전하게 보내는데 초점이 맞추어져 조금 더 복잡한 과정을 거친다.

클라이언트는 서버에게 ‘Client Hello’ 메시지를 보내서 인사를 한다. 클라이언트가 보낸 메시지에 서버는 ‘Server Hello’로 답을 한다. 클라이언트가 메시지를 보냈지만 서버가 응답이 없다면 에러가 발생한다. 클라이언트는 ‘Client Hello’ 메시지를 보낼 때 자신이 지원할 수 있는 SSL 버전 중에서 가장 높은 버전, 암호화를 할 때 사용하는 임의의 32바이트의 값, Session ID, 자신이 지원하는 암호화 패키지 등을 같이 보낸다. 물론 처음 메시지를 보낼 때에는 Session ID가 비어있지만 다음에 메시지를 보낼 때는이전의 Session ID를 실어서 보낸다. 따라서 두번째 통신을 할 때에는 보다 빠르게 통신할 수 있다.

클라이언트의 인사에 서버는 ‘Server Hello’ 메시지로 답을 한다고 했다. ‘Server Hello’ 메시지에는 클라이언트가 제시한 SSL 버전의 수용 유무를 판단한다. 만약 클라이언트가 SSL 버전 3.0으로 통신을 하자고 제안했지만 서버는 버전 2.0밖에 지원하지 못한다면 통신은 SSL 버전 2.0으로 통신을 하게 된다. 그러나 요즈음에 나오는 거의 모든 클라이언트와 서버는 SSL 버전 3.0을 지원하지 못하기 때문에 일반적인 상황이라면 SSL 버전 3.0으로 통신한다고 생각하면 된다. 또한 ‘Server Hello’ 메시지 안에는 클라이언트가 보낸 암호화 리스트 중에서 서버가 선택한 암호화 알고리즘도 클라이언트 쪽으로 함께 보낸다. 이외에도 ‘Sefver Hello’ 메시지에는 클라이언트가 보낸 임의의 랜덤값, 서버가 지정한 Session ID가 같이 들어 있다.

클라이언트와 사버는 앞의 과정을 통해서 통신을 하기 위한 가장 기초적인 상황 파악 단계를 마친다. 이제는 서로 메시지를 암화하기 위해 사용할 키를 주고받는 과정이 남아 있다.

앞에서 이야기했듯이 클라이언트와 서버간의 통신을 위해서는 ‘비밀키’와 ‘공개키’ 방식을 모두 사용한다.

두 가지 방식을 모두 사용하기 때문에 약간 복잡할 수도 있으나, 바보온달 이야기를 완전히 이해했다면 그리 어려울 것은 없다. 일단 서버는 ‘ServerHello’ 메시지를 전달하고 난 후에 ‘Certificate’ 메시지를 보내서 앞으로 서버가 보낼 공개키는 이런 이런 기관에서 공식적으로 인정해줬으니, 믿고 자신과 통신해도 좋다는 것을 알린다. 그리고 난 연후에 ‘SeverKeyExchange’ 메시지 속에 ‘공개키’를 실어서 보낸다. 그리고 나서 서버는 ‘ServerHelloDone’ 메시지를 보내서 서버의 기본 작업이 모두 끝났다고 클라이언트에게 알린다.

클라이언트는 서버로부터 ‘ServerHelloDone’ 메시지를 받으면 앞으로 통신할 때 사용할 비밀키 또는 세션키를 서버가 준 공개키를 사용해서 생성하고 이 키를 ‘ClientKeyExchange’ 메시지에 실어서 서버에게 보낸다.

키를 서로 교환한 클라이언트와 서버는 이제 보안 서비스를 사용하기 위한 세세한 스팩을 서로 교환해서 암호화 방법을 동기화시킨다. 이 과정이 ‘ChangeCipherSpec’,’Finish’의 단계이다. 이로써 모든 핸드쉐이크 과정이 끝나게 된다. 이제 어플리케이션 레이어에서 데이터를 서로 주고받아도 안전한 데이터 교환이 보장된다.

WebKnight는 AQTRONIX사에서 개발한 IIS 웹서버에 설치할 수 있는 공개용 웹 방화벽입니다.
WebKnight는 ISAPI 필터 형태로 동작하며, IIS 서버 앞단에 위치하여 웹서버로 전달되기 이전에
IIS 웹서버로 들어온 모든 웹 요청에 대해 웹서버 관리자가 설정한 필터 룰에 따라 검증을 하고
SQL Injection 공격 등 특정 웹 요청을 사전에 차단합니다.

1.설치 방법

• 아래 URL에서 WebKnight를 다운로드 받습니다.
  http://www.aqtronix.com/?PageID=136

• 설치 전 IIS의 ISAPI필터를 설치합니다.

• 압축을 푼 뒤 사용자의 시스템 종류에 맞는 폴더의 WebKnight.msi를 실행하여 설치를 진행합니다.

• 기본 설치를 하면 C:Program FilesAQTRONIX WebKnight 폴더에 WebKnight설치가 됩니다.
  동시에 인터넷 정보 서비스에 Global Filter로 ISAPI Filter에 자동 등록됩니다.

• IIS를 재시작 합니다.

• IIS 재시작 후에 관리자에서 정상적으로 설치가 완료되었을 경우 다음과 같이 WWW 서비스 마스터
  속성에서 “ISAPI 필터” 탭에 다음과 같이 WebKnight 필터가 정상적으로 적용이 된 것을 확인할
  수 있습니다.

• 주요 파일

◦ Config.exe : WebKnight의 설정파일을 읽어들여 조작 할 수 있게 해주는 파일
◦ denied.htm : 설정에서 ‘Response Directly’ 옵션을 통해 보여지는 기본 차단 메시지
◦ LogAnalysis.exe : 로그 분석기
◦ Robots.xml : User-Agent에 대한 DB 파일
◦ WebKnight.dll : ISAPI Filter 파일, WebKnight가 실제 동작하는 파일
◦ WebKnight.xml : WebKnight 동작을 제어할 수 있는 설정 파일

2.설정 방법

• Config.exe를 실행시켜 WebKnight.xml을 열어줍니다.

• 사용자의 환경에 맞춰 수정을 합니다.
  자세한 수정 항목들은 참고 사이트의 pdf를 참고하여 작성합니다.

• 탐지 된 로그는 LogAnalysis.exe를 통해 확인할 수 있습니다.

참고 사이트

http://www.kisa.or.kr/public/laws/laws3_View.jsp?mode=view&p_No=259&b_No=259&d_No=42

침입차단 시스템 도입 시 고려사항 [Firewall]

자사에 적합한 F/W 도입 후 효율적 관리가 ‘최선’

​

다기능보다 안정성·편이성 우선… 지속적 관심·노력 ‘필수’

​

​

서버 레벨에서의 보안 작업이 가정의 각 방마다 문을 설치하고 자물쇠를 설치하는 것이라면 네트워크 관문에 침입차단시스템(Firewall)을 설치하는 것은 대문을 다는 것에 비유될 수 있다. 중앙 집중화된 접근 제어를 할 수 있는 침입차단시스템은 보안을 위해 필수적 요소라고 할 수 있다. 이번 호에서는 이러한 침입차단시스템 초기 도입을 위해 사전에 고려해야 할 점과 도입한 후에 효율적으로 관리하기 위한 방안에 대해 다루고자 한다.

​

<편집자>

이미 보안 솔루션을 도입한 대부분 업체에서는 침입차단시스템을 구축해 사용하고 있으며, 아직 보안 솔루션을 도입하지 않고 향후 계획을 가지고 있는 업체에서도 가장 우선적으로 구축하고자 하는 솔루션으로 침입차단시스템을 고려한다. 기업의 관문에 설치돼 보안의 3대 요소인 AAA(Authentication, Authorization, Accounting)를 네트워크에 대해 적용한 침입차단시스템은 필수적인 보안 솔루션 중의 하나다.

아무리 서버 하나 하나에 대해 불필요한 서비스를 모두 제거하고 패치를 완벽히 수행한다 하더라도 사소한 인적 실수는 있을 수 있기 마련이다. 이런 사실을 잘 반영하는 필자가 경험한 한 예를 소개하자면, 침입차단시스템을 아직 구축하지 않았지만 보안에 대한 기본 개념이 있는 전산 관리자가 있었다. 그는 최신 보안 패치를 발표될 때마다 적용하고 불필요한 서비스 제거 등의 하드닝 작업을 수행해 1년이 넘는 기간 동안 보안상 아무런 문제도 없이 지내왔다.

그러던 어느 날 기술지원 차 방문한 타 업체 엔지니어가 잠시 연결한 시스템이 마침 유행하는 인터넷 웜에 감염돼 기업의 네트워크를 마비시킨 경우가 있었다. 원인은 문제의 시스템에 최신 서비스팩이 설치돼 있지 않아 취약한 상태였다. 이와 같은 웃지 못할 에피소드는 현업에 종사하면서 많이 본 적이 있는데 이러한 경우 침입차단시스템이 있었고 유입되는 트래픽에 대해 적절한 보안 정책이 적용돼 있었다면 잠깐의 관리적인 실수에 의한 이런 일은 없었을 것이다.

작년 한 해의 가장 큰 보안 이슈였던 1.25 사태의 경우에 있어서도 이미 침입차단시스템을 도입하고 있었던 기업에서는 큰 피해를 보지 않았다. 이것은 미처 패치를 적용하지 못했더라도 다행히 해당 웜이 이용하던 공격 포트(UDP/1434)가 방화벽 정책에서 보통 개방되지 않는 서비스였기 때문이다.

서버 레벨에서의 보안 작업이 가정의 각 방마다 문을 설치하고 자물쇠를 설치하는 것이라면 네트워크 관문에 침입차단시스템을 설치하는 것은 대문을 다는 것에 비유될 수 있다. 중앙 집중화된 접근 제어를 할 수 있는 침입차단시스템은 보안을 위해 필수적 요소라고 할 수 있다. 이번 호에서는 이러한 침입차단시스템 초기 도입을 위해 사전에 고려해야 할 점과 도입한 후에 효율적으로 관리하기 위한 방안에 대해 다루고자 한다.

​

​

침입차단시스템 도입 시 고려사항

국내외적으로 많은 침입차단시스템 솔루션 벤더가 존재하고 있으며 그러한 벤더의 제품 사이에서도 다양한 제품군이 존재하기 때문에 이 중 어떤 침입차단시스템이 적합한지를 선택하는 것은 고민거리다. 몇 가지 체크할 사항과 그러한 판단에 있어서 유념해야 할 점을 정리하면 크게 6가지 정도로 간추릴 수 있다.

​

·성능과 안정성

침입차단시스템은 보안 장비이기도 하지만 기업의 네트워크 관문에 설치되는 장비인 만큼 성능은 가장 중요한 요소다. 최근에는 계속 고성능의 침입차단시스템이 나옴에 따라 보안 측면의 강화에도 눈을 돌리는 경향이 있지만 보안성 때문에 성능을 포기할 수 없음은 불변의 사실이다. 안정성은 말할 것도 없다. 흔히 침입차단시스템의 성능 평가 요소로 볼 수 있는 것은 다음과 같다.

​

- 최대 패킷 처리량(Throughput)

- 최대 동시 처리 세션 수

- 최대 초당 처리 세션 수(Session rate)

​

특히 위에 열거된 사항 중 가장 중요한 것은 최대 패킷 처리량으로 장비가 패킷 손실 없이 처리할 수 있는 최대 트래픽을 말하는데, 초당 처리하는 데이터량을 뜻하는 bps, 혹은 초당 처리하는 패킷의 개수를 뜻하는 pps의 단위로 표현할 수 있다.

여기서 반드시 주의 깊게 짚고 넘어가야 할 점은 pps로 표현한 수치는 평균 패킷 사이즈에 따라 큰 차이가 없지만 bps로 표현한 수치는 큰 차이가 있다는 사실이다. 그것은 현재 대부분의 침입차단시스템이 채택하고 있는 방식인 스테이트풀 패킷 필터링 방식에서 패킷의 통과 여부를 결정하기 위해 패킷 헤더를 검사하기 때문에 256바이트의 패킷 한 개를 처리하는데 걸리는 자원과 512바이트의 패킷 한 개를 처리하는데 걸리는 자원이 크게 다르지 않기 때문이다.

bps 단위의 최대 패킷 처리량은 pps 단위의 최대 패킷 처리량, 평균 패킷 사이즈, 그리고 8을 곱한 값으로 계산될 수 있다. 예를 들어 침입차단시스템이 200,000pps를 처리 가능한 침입차단시스템이고 해당 사이트의 평균 패킷 사이즈가 256바이트라면 그 환경에서의 최대 패킷 처리량은 약 400Mbps로 볼 수 있으며, 평균 패킷 사이즈가 512바이트라면 약 800Mbps로 볼 수 있다.

따라서 벤더의 데이터시트 자료에서 해당 침입차단시스템이 2Gbps를 처리할 수 있다고 한다면 어느 정도의 평균 패킷 사이즈에서 그 정도를 처리할 수 있다는 것인지 반드시 확인해야 한다. 벤더의 마케팅 자료에서는 대개의 경우 이더넷 규약 상 패킷 사이즈가 가장 큰 1,518바이트에서의 처리 성능을 이야기하고 있는 것이기 때문에 자사 실환경에서의 성능과는 매우 큰 차이가 있다.

​

·관리적인 편이성

침입차단시스템 역시 네트워크 장비면서 보안 장비이기 때문에 지속적인 관리가 필수적인 장비다. 중요한 몇 가지를 보면 다음과 같다.

​

- 설치 및 업데이트의 용이성

- 지원하는 관리 인터페이스

- 보안 정책 관리의 편이성

- 다양한 관리자 역할 지원

- 로그 관리 기능

- 리포트 기능

- 침입차단시스템 상태 모니터링

​

다양한 관리자 역할의 지원은 롤 구획화를 실현하는 것이다. 관리자별로 가능한 명령어를 제한해 특정 관리자는 읽기 기능만 가능하도록, 특정 관리자는 쓰기 기능도 가능하도록 할 수 있으며, 아울러 관리자가 수행한 작업에 대한 감사 기능도 제공해야 향후 문제 발생 시 원인 파악을 빠르게 할 수 있다.

로그 관리 기능에 있어서 syslog, SNMP 등의 다양한 로그 포맷을 지원하는지, 중대한 이벤트 발생 시는 별도로 SNMPtrap이나 이메일 등의 수단을 통해 전송이 가능한지 여부를 살펴봐야 한다. 자사 네트워크에 접근한 서비스에 대한 감사와 문제 분석을 위해 다양한 로깅 기능의 지원은 필수적이며 보안상 무의미한 불필요한 로그에 대해서는 남기지 않고, 그렇지 않은 로그는 남길 수 있도록 하는 상세 설정도 가능해야 한다.

침입차단시스템의 CPU, 메모리 사용량은 기본이고 이에 대한 현재의 세션 수, 성립된 세션의 내용과 같은 수치 등 다양한 값에 대한 모니터링 역시 필수 사항이다. 특히 이런 정보에 대한 다양한 SNMP MIB 정보를 제공하면 MRTG와 연동해 히스토리 분석이 가능하다.

​

·이중화를 통한 고가용성/로드 분산을 통한 고성능

침입차단시스템은 관문의 장비이기 때문에 장애 발생 시 모든 네트워크가 마비되는 특정 지점의 오류(single point of failure)가 될 수도 있다. 따라서 끊김 없는 네트워크 환경을 위해 이중화 방안을 마련해두는 것이 필수적이다.

하나의 침입차단시스템이 장애가 발생해 다른 침입차단시스템으로 페일오버(failover)가 발생될 때 단순히 패킷 처리만 이양되는 것이 아니라 연결중인 세션도 끊기지 않고 이양돼야 한다. 이는 스테이트풀 페일오버(stateful failover)라고 한다. 주된 서비스가 HTTP 프로토콜인 사이트의 경우라면 이는 세션 기반의 프로토콜이 아니기 때문에 크게 중요하지는 않으나, 금융거래가 이뤄지는 사이트나 온라인 게임 사이트와 같은 경우는 매우 중요한 기능이다.

이중화 구성 방안으로는 액티브-스탠바이(Active-Standby), 액티브-액티브(Active-Active) 구성의 두 가지 방안이 있는데 전자는 하나의 침입차단시스템은 다른 침입차단시스템이 장애 발생될 때까지 대기 중인 상태로 있다가 장애 발생 시 활성 모드로 전환해 트래픽을 처리하게 된다. 후자의 경우는 두 침입차단시스템이 모두 활성 모드로 있으면서 로드밸런싱을 하는 것인데 레이어 4 스위치가 추가적으로 필요하다.

이 경우 고려해야 할 점은 스테이트풀 페일오버가 불가능하다는 점과 침입차단시스템 처리 가능한 최대 세션 수가 레이어 4 스위치에 의해 병목현상(bottleneck)이 발생할 수 있다는 점, 그리고 레이어 4 스위치가 또 다른 장애 포인트가 될 수 있다는 점이다. 그 외 일부 침입차단시스템은 레이어 2 스위치만으로 로드밸런싱까지도 수행할 수 있는 기술을 구현하고 있다.

​

·침입차단시스템 인증 기능

종래의 패킷 헤더 정보에만 기반해 필터링을 수행한 침입차단시스템은 재택 근무자와 같은 유동 IP 사용자에 대한 접근 제어를 하기 위해 그러한 재택 근무 사용자의 작업 시작과 함께 임시로 방화벽 정책을 허용해야 하고 작업 완료 후 해당 정책을 다시 삭제해야 한다는 번거로운 점이 있었다. 이런 과정에서 작업 완료 후 정책을 삭제해주는 과정을 누락했다면 불필요한 정책은 증가돼 성능상의 문제, 보안상의 문제가 야기될 수 있다.

이런 점을 해소하기 위해 추가된 것이 침입차단시스템 인증 기능이다. 재택 근무자가 작업이 필요할 시에 정책을 따로 입력하는 대신, 인증을 요구하는 창에 ID와 패스워드를 입력한다. 이렇게 인증 받은 사용자 IP에 대해 인증 정보가 캐쉬되어 있는 동안 정책은 허용돼 있는 것과 같은 효과를 얻고 작업이 완료되면 인증 정보가 사라지면서 다시 해당 정책은 차단된다. 물론 사용자 인증은 침입차단시스템 정책 라인별로 정의할 수 있어 유연성이 있다.

이 때 제품에 따라 사용자 데이터베이스는 침입차단시스템 자체만으로 충분하기도 하고 TACACS+/래디우스 같은 다른 인증 제품과의 연동이 필수적인 경우가 있다. 침입차단시스템 자체만을 이용한 인증은 설정이 간편하나 ID, 패스워드 관리도 침입차단시스템에서 이뤄져야 하기에 불편할 수 있다는 점인데, 그런 점은 TACACS+/RADIUS 등과 같은 인증 서버와 연동함으로 해결이 가능하다. 또한 시큐어ID와 같은 일회용 패스워드 인증 솔루션과 연동함으로써 이러한 인증 사용자에 대한 접근에 한층 더 보안을 강화할 수도 있다.

​

·상위 레벨 프로토콜 분석(protocol inspection) 기능

초기 방화벽에서 다루기 힘든 연결 중 하나가 FTP 프로토콜이었다. 이 프로토콜은 FTP 명령어를 전달하는 컨트롤 세션과 실제 데이터를 교환하는 데이터 세션 두개의 세션으로 나뉘며 데이터 세션은 동적으로 개방되는 것이기 때문이다. 침입차단시스템에서는 이러한 동적으로 개방되는 데이터 세션을 처리하기 위해 상위 레벨 프로토콜에 대한 지원이 필요했다. 즉 최근의 대부분 침입차단시스템은 FTP 프로토콜을 지원하기 때문에 동적으로 오픈될 데이터 세션을 별도로 허용해줄 필요가 없다.

이 외에도 H.323, SIP 등의 프로토콜이 자사에서 이용된다면 침입차단시스템에서 지원되는지 확인이 필요하다. 정상적인 서비스 사용을 위한 프로토콜 분석 기능 외에 보안성 향상을 위한 기능도 있는데 URL 필터링, SMTP, FTP 명령어들에 대한 제한 기능 등이다. 이러한 보안성 향상을 위한 프로토콜 분석을 위해서는 자체 제품만으로 가능한 경우가 있고, 웹센스(WebSense) 등과 같은 제품과의 연동이 필요한 경우가 있으니 해당 기능이 필요하다면 그러한 점도 확인돼야 한다.

​

·VPN 기능

VPN 기능은 지사간의 연결에 있어서 저렴한 비용으로 사설망의 효과를 얻을 수 있기 때문에도 사용되지만, 재택 근무자, 파견자 등과 같이 원격 액세스 사용자로 하여금 안전한 접속 환경을 제공하기도 한다. VPN 장비는 전용 장비 형태로 침입차단시스템과 함께 서로 병렬 구조로 설치되거나 직렬로 설치된다. 또 침입차단시스템의 DMZ에 VPN 장비를 구성하기도 하는데 아예 침입차단시스템에 VPN 기능이 통합돼 나오는 경우도 있다. 따라서 간단한 VPN 기능을 사용할 예정이라면 기능이 통합된 장비를 선택하는 것도 효과적이다. 이 때 별도의 라이선스 구매가 필요한 경우가 있으므로 확인해야 한다.

침입차단시스템의 관리

이러한 침입차단시스템을 도입한 후, 올바른 활용을 위해 알아야 할 점을 몇 가지 제안한다.

​

·구성 관리

침입차단시스템의 도입 후 구성을 하면서 고려하는 사항 중 하나와 흔히 받게 되는 질문이 DMZ 구성을 할지 여부와 그것의 필요성이다. 간단히 말해서 DMZ는 보안 레벨이 서로 다른 네트워크를 구분하기 위해 구성한다. 예를 들어 웹 서버, DNS, 메일 서버와 같은 경우는 외부의 임의의 클라이언트로부터의 접근이 필요하며, DB 서버와 같은 경우는 웹 서버 등의 일부 서버만 접근하면 되고 외부에서는 접근할 필요가 없으므로 이들은 보안 레벨이 서로 다른 것이다.

이 경우 임의의 클라이언트로부터의 접근이 필요한 서버는 DMZ에, 그렇지 않은 나머지 서버들은 내부 네트워크 쪽으로 배치하며, 이 경우의 보안 레벨을 상대적으로 비교하면 내부 네트워크 > DMZ > 인터넷 순이다. 외부로부터 임의의 클라이언트에 대해 노출돼 있는 DMZ에 있는 서버가 해킹을 당한다 하더라도 훨씬 중대한 정보들이 담겨 있는 내부 네트워크에 접근하기 위해서는 침입차단시스템을 한번 더 통과해야 하기 때문에 침입차단시스템 한 대를 이용해 침입차단시스템을 이중으로 구축한 것과 같은 효과를 얻을 수 있다.

이에 반해 DMZ를 구축하지 않고 메일 서버, DNS 서버들을 그대로 내부 네트워크에 방치할 경우 해당 서버가 침해된다면 그 서버를 통해 내부 네트워크에 있는 다른 서버들로도 모두 접근할 수 있기 때문에 쉽게 전이 공격을 시행할 수가 있게 된다.

​

·보안 정책 관리

보안 정책 관리는 침입차단시스템에 있어 핵심적인 부분이다. 정책에서 허용돼 있는 서비스가 많으면 많을수록 침입 가능성은 높아지기 때문이다. 초기 디자인부터 세심하게 지속적인 리뷰가 필요하다. 정책 디자인에서는 크게 내부로의 접근, 그리고 외부로의 접근 두 가지로 나눠 생각하도록 한다.

내부로의 접근은 다시 모든 클라이언트로부터의 접근을 허용해야 하는 정책, 그리고 특정 클라이언트로부터의 접근만 허용하면 되는 관리적인 정책의 두 가지로 분류해 관리한다. 모든 클라이언트로부터의 접근을 허용하는 정책은 주기적으로 리뷰를 해야 한다. 아무리 정책을 상세하게 세웠다 하더라도 테스트를 위해 잘못 입력된 단 한 줄의 정책으로 보안상 돌이킬 수 없는 구멍이 될 수 있기 때문이다. 또한 구성을 단순화하기 위해서 외부로의 접근은 모두 허용하도록 설정할 수 있으나, 보안을 고려하기 위해서는 외부로의 접근에 대해서도 철저한 보안 정책이 필요하다.

​

·로그 관리

로그는 어느 정도 수준까지를 남길 것인지에 대한 회사의 정책부터 결정해야한다. 다음과 같이 크게 세 가지의 분류로 나누어 어떠한 로그를 남길지 판단한다.

​

- 모든 클라이언트로부터의 서비스 목적의 접근을 허용하는 서비스에 대한 허용 로그

- 특정 클라이언트로부터의 관리적인 접근을 허용하는 서비스에 대한 허용 로그

- 접근 거부 로그

​

위해서 두 번째와 세 번째는 보안상 의미를 가지기 때문에 남기는 것이 보통이며, 첫 번째는 로그량에 따른 침입차단시스템의 성능과 로그를 저장할 서버의 용량(capacity)을 고려해 남길지 그러지 않을지를 결정해야 한다. 백업 미디어를 통한 이러한 로그의 정기적인 백업이 필수적인 것은 물론이다.

​

·모니터링

침입차단시스템 장비에 대한 장애여부 체크(Aliveness Check)는 필수적이며, MRTG 등을 통한 트래픽, CPU 사용량, 메모리 사용량, 세션 사용량 등은 주기적으로 모니터링 해야 한다. 또한 MRTG를 통해 조기 경보 기능을 설정할 수 있는데 네트워크 장애에 대한 조기 발견 및 대응에 매우 효과적이다. 예를 들어 침입차단시스템의 CPU 점유율이 50% 이상 올라가면 메일로 관리자에게 오도록 설정할 수 있는데 이것을 잘 활용해 이상 트래픽의 급증에 대한 조기 탐지 및 대응도 가능하다. 설정에 대한 상세한 방법은 MRTG 관련 사이트를 참고하기 바란다.

​

·운영 절차 관리

막대한 투자 비용을 들여 도입한 침입차단시스템일지라도 그것을 관리할 보안 인력이 없고 절차가 없다면 무용지물이다. 따라서 솔루션 도입과 더불어 그것을 효율적으로 관리할 보안 인력과 적절한 운영 체계 마련이 근간 시 돼야 한다.

결론

이제까지 가장 기본적인 보안 솔루션인 침입차단시스템의 도입 이전에 고려해야 할 점, 그리고 도입 이후 활용에 대한 몇 가지 방안을 알아봤다. 그리고 최근에는 침입차단시스템과 침입탐지시스템의 장단점을 접목한 침입방지시스템(Intrusion Prevention System)도 국내 시장에서 점차 소개되고 있으나 아직 시장이 활성화되지는 않은 상태다.

가장 중요한 것은 복잡한 기능을 구가할 수 있는 솔루션의 도입이 아니라 자사에 적합한 솔루션을 선정해 도입하고 그것을 얼마나 효율적으로 관리하느냐 하는 것이다. 즉, 관리자의 관심과 노력이 무엇보다도 중요한 셈이다.