완벽한 웹 보안, 어떤 것들이 필요한가?
완벽한 웹 보안 2/3사실 정보보안이라는 게 완벽함을 보장하긴 영 어려운 일이다. 완벽에 가까워지려면 아무리 초절정 전문가라 하더라도 구축 설계에서부터 운영에 이르기까지 무지무지 심각한 어려움이 따른다.특히나 웹 보안은 현재 표준화된 보안 대책 및 방법이 따로 없어서 제각각 처한 현실에 따라 보안 환경을 뚝딱뚝딱 각자 구축하는 실정이다. 대부분의 기업들이 웹 보안 솔루션을 운영하고 있지만 각각의 형편에 딱 알맞은 솔루션을 운영하는 곳은 그리 많지 않다. 종류부터 너무나 다양한 제품들이 마구 난립하는데다 각 솔루션이 제각각 역할에 맞춰 설치되고 운영되지 못하기 때문이다.
안전한 웹 보안을 위해서는 기업의 보안 담당자가 웹 보안 원리에 대해 충분히 이해하고 자사의 IT 시스템에 적합한 웹 보안 체계를 구축해야 한다. 어떻게? 우선 자사의 IT 시스템에
대한 적절한 이해와 파악이 선행되어야 한다.
“그래서 웹 보안, 도대체 뭘 어떻게 하라는 건데?”
먼저 기업에서 사용하는 IT 시스템 구조에 대해 간단히 알아보자. 일반적으로 IT 시스템은 크게 네트워크, 시스템, 애플리케이션으로 이루어진 3개의 계층으로 구성되어 있고, 보안은 각 계층에 빠짐없이 고루 적용되어야 한다.
가장 하단에 있는 ‘네트워크’ 계층은 데이터의 송수신과 관련된 통신을 담당하는 역할을 하고, ‘시스템’ 계층은 우리가 흔히 알고 있는 Windows, Linux 등 운영체제가 그러하듯 여러 애플리케이션이 동작할 수 있는 플랫폼 역할을 맡는다. 최상위 ‘애플리케이션’ 계층은 여러 가지 기능을 가지고 동작하는 프로토콜 및 응용 서비스들을 제공한다.
각종 서버의 시스템 구조 또한 이와 같은 구조를 기본적으로 따르기 때문에, 안전한 서버 보안이란 위 IT 시스템의 세 계층의 보안, 즉 네트워크 보안 + 서버 시스템 보안 + 애플리케이션 보안이 모두 안전하게 구축된 것을 뜻한다.
네트워크 보안
네트워크 보안은 쉽게 말해 가장 바깥에 있는 외피 보호막이라고 생각하면 된다. 시스템 내부와 외부 사이에 방화벽을 끼워 비정상적인 통신이나 패킷을 차단한다.
네트워크 보안을 위해서는 안전하지 않은 IP나 포트에 대한 접근 제어가 필요하고, 허용된 IP나 포트로 들어온 트래픽에 대해서도 유해성 여부를 체크할 필요가 있다. 이를 위해 방화벽과 침입 탐지/방지 시스템 IDS/IPS 등을 사용한다.
하지만 방화벽의 경우 허용된 IP나 Port로부터의 공격은 막을 수 없고, 그리고 IDS/IPS에서 이루어지는 네트워크 계층 유해성 검사는 애플리케이션 계층에 대한 이해가 없이 이루어지기 때문에 애플리케이션 취약성을 노린 공격에 대해서는 방어가 불가능하다는 한계가 있다. 애플리케이션을 노리는 공격이 많은가? 모든 정보보안 공격 중 절대적 다수가 애플리케이션 공격이다.
서버 시스템 보안
시스템 보안은 대부분 운영체제와 연관된다. Windows, Linux, Unix 등 운영체제에 관련된 개발을 주로 하는 업체들은 자사의 시스템에 대한 주기적인 보안 업데이트 및 패치를 통하여 ‘알려진 웹 위협’에 대응한다.
기업의 보안 담당자는 보안 업데이트 및 패치뿐만 아니라, 주기적으로 시스템 악성코드 점검을 통하여 시스템을 항상 안전한 상태로 유지해야 한다. 이를 위해 기업들은 주로 안티바이러스 솔루션을 구축한다. 필수 불가결한 조치이긴 하나, ‘알려진 공격’ 자체의 한계가 있다. 그럼 알려지지 않은 공격은? 알려지지 않은 공격도 많은가? 물론 매우 많다. 생각해 보라. 누군가 전신전령 최선을 다해 공격을 꼭 해내고야 말겠다 작정했다면,
이미 알려진 공격을 시도하겠나? 다들 백신 싹 다 돌려 보고 공격한다.
웹 애플리케이션 보안
애플리케이션 계층은 네트워크 계층이나 시스템 계층에 비해 기술적으로 고도화되어 있고 애플리케이션의 종류도 다양하기 때문에 대부분의 보안 관리자들이 보안 정책을 수립하고 또 적용함에 있어 가장 많은 어려움을 겪는다. 그러니 이를 가능한 한 쉽게 풀어서 말하자면,
우리가 일반적으로 생각하는 ‘웹’은 모두 다 애플리케이션으로 구성되어 있다. 웹사이트, 모바일 앱 등이 모두 애플리케이션이고, 이를 노리는 웹 공격 또한 애플리케이션의 취약성을 이용한 애플리케이션 공격이 전체 공격의 대부분을 차지한다.
SQL Injection, XSS 등 언론 보도 등을 통해 유명해진 웹 공격도 결국 모두 다 웹사이트의 애플리케이션 취약점을 노린 공격이고, 소위 ‘웹 쉘’이라 불리는 웹 기반 악성코드 또한 PHP 등으로 구성된 웹 애플리케이션이다. 웹 보안 업계에서 유명한 ‘OWASP(The Open Web Application Security Project)’가 선정한 ’10대 웹 취약점’ 또한 모두 다 웹 애플리케이션 공격이다. 즉,
현재 이루어지고 있는 웹 공격의 90% 이상이 웹 애플리케이션을 노린 공격이라고 해도 과언이 아니다. 결국 안전한 웹 보안을 구축하고자 한다면 안전한 웹 애플리케이션 보안 구축이 필연적인 것이다.
웹 애플리케이션 보로를 위해서는 웹 취약점 스캐너, 웹 방화벽, 웹 악성코드 탐지, 시큐어 코딩, 데이터 암호화 등과 같은 방법을 사용한다. 하지만 위험과 그에 대응하는 기술에 대한 계몽 부족으로 인해 보급 상황이 영 시원찮다. 실로 안타까운 일이다.
자 그럼 어디, 각 계층에서 필요한 보안 방법들을 그림으로 그려 보자.
거듭 강조하는 바 웹 애플리케이션 보안은 웹 보안 전체에 있어 가장 중요도가 높은데도 불구하고 정작 애플리케이션 보안에 대한 투자는 네트워크 보안 투자비용의 고작 1/10에 불과하다. 그 까닭은? 아마도 뭘 어떻게 해야 하는지 모르겠다 싶은 난해함 때문 아닌가 싶다. 네트워크 보안은? 비교적 간단하지. 그냥 기계 사다가 랙에 꽂고 “아, 끝났다!” 잊으면 되니까. (물론 네트워크 보안도 그렇게 하면 절대 안 된다,,)
완벽한 웹 보안! 어떤 것들이 필요한가?
기업의 보안 관리자들은 다양한 웹 보안 솔루션을 도입하여 웹 공격에 대비한다. 하지만, 자사에서 구입하고 관리하는 웹 보안 솔루션의 역할이 무엇이고, 그 중에서도 웹 애플리케이션 보안과 연관된 솔루션이 무엇인지 정확히 구분할 수 있는 보안 관리자는 그리 많지 않다.
다시 말해 기본적인 네트워크 보안 솔루션 외 따로 웹 애플리케이션 보안의 적절한 솔루션을 적용하고 운영 중인 기업이 많지 않다는 이야기이다. 그러한 환경은 기업의 전반적인 보안 수준을 낮추고, 나아가 해커들의 잠재적 공격 대상이 될 수 있다.
애플리케이션 구축은 집 짓기에 비유하면 그나마 이해가 쉽겠다. 집을 어떻게 짓느냐에 따라 집이 안전할 수도 불안할 수도 있듯, 애플리케이션을 어떻게 구축하냐에 따라 애플리케이션의 안정성이 결정된다.
애플리케이션 보안은 구축 초기인 개발 단계부터 구축 이후의 유지보수에 이르기까지 모든 단계에 걸쳐 신경을 써야 한다. 하지만, 이를 실천하기 힘든 건 적절한 방법론의 부재도 문제지만, 웹 애플리케이션 보안 자체를 쉽게 이해하기 어렵다는 점 때문이다. 웹 스캐너, 웹 애플리케이션 방화벽 등 용어의 뜻은 대략이나마 알겠는데, 그것들의 정확한 기능이나 동작 위치 등을 쉽게 이해하기는 쉬운 일이 아니다.
이에 웹 애플리케이션 보안과 각각의 솔루션이 동작하는 위치를 집을 짓는 것에 비유하여 보다 쉽게 접근해 보자.
시큐어 코딩, Secure Coding
개발의 전체 단계는 집을 짓는 과정이라고 생각해 보자. 집을 지을 때는 단단한 지반에 튼튼하고 안전한 벽돌로 집을 지어야 한다. 이는 집을 지을 때 가장 기본이 되는 것으로서, 기본이 튼튼해야 보다 안전한 집을 지을 수 있을 것이다.
‘시큐어 코딩’이란 개발 과정에서 개발자의 지식 부족이나 실수, 또는 각 프로그래밍 언어의 고유한 약점 등 다양한 원인으로 발생할 수 있는 온갖 취약점을 최소화하기 위해서, 설계 단계부터 보안을 고려하여 코드를 작성하는 제작 방식을 뜻한다.
미국의 정보 기술 연구 및 자문 회사 Gartner사의 조사에 따르면, (Gartner 같은 집단 하나 없는 나라가 ‘IT 강국’을 자처한다는 게 애초에 희극이긴 하다,,), 소프트웨어 배포 이전 상태에서 취약점을 50% 감소시키면 보안 사고 대응 비용이 75% 가량 감소한다고 한다. 애플리케이션 개발에 있어서 빠른 구축기간도 중요한 요소지만, 속도보다는 안전하고 체계적으로 개발하는 것이 더욱 중요하다는 사실을 알 수 있다.
안전하지 않은 개발 환경에다 여타 다른 웹 보안 솔루션을 마구 도입하는 짓은 아랫돌 빼어 윗돌 괴는 것처럼 허무한 임시방편에 불과하다.
웹 스캐너, Web Scanner
집이 완성된 이후에에도 벽돌에 금 간 건 없는지, 집이 기울어진 건 아닌지 확인할 필요가 있다. 보안적으로 설명하자면, 벽돌에 금 가거나 집이 기울어진 것을 체크하는 것과 같이 애플리케이션을 점검하는 ‘웹 스캐너’를 주기적으로 실행할 필요가 있다.
웹 스캐너는 ‘웹 취약점 점검 툴’로도 불리며, 웹 애플리케이션 외부에서 통신을 통하여 잠재적인 취약점이나 설계상의 취약점을 분석하는 프로그램이다. 시중에는 많은 종류의 웹 스캐너가 판매되고 있으며, 비상업적 용도로도 제공되는 다양한 웹 스캐너도 있다. 웹 스캐너의 성능과 동작은 각각 다를 수 있지만, 웹 스캐너의 핵심은 그 효과를 얻기 위해서는 꾸준한 점검을 통해 애플리케이션의 상태를 주기적 그리고 지속적으로 확인해야 한다는 점이다.
웹 서버 악성코드 탐지, Web-based Malware Detection
공사 완료 이후에 집 안에 혹시 비가 새는지 벌레가 숨어 들 구멍은 없는지 점검해야 한다. 애플리케이션 내부를 점검하는 솔루션에는 ‘웹 서버 악성코드 탐지’ 솔루션이 있다.
웹 서버 악성코드(Web-Based Malware)는 웹 쉘(WebShell)이라고도 불리며, 애플리케이션 내부에서 동작하는 악성코드다. 해커는 웹 쉘을 통해 보안 시스템을 우회하여 별도의 인증 없이 시스템에 접속하는 것이 가능하다. 이를 점검하기 위해서는 전문적으로 웹 쉘만 탐지해주는 솔루션을 활용하여 서버 내부에서 탐지해야 한다. 웹 스캐너와 동일하게 웹 서버 악성코드 탐지 솔루션 또한 주기적인 점검과 실행이 필수적이다.
웹 방화벽, Web Application Firewall
이제 애플리케이션이라는 집을 안전한 벽돌로 제작하고 안팎으로 점검했다. 이제 안전한 집인가?
집을 짓고 나면 우리는 예상치 못한 자의 접근으로부터 집을 지키고 미처 발견하지 못한 내부의 위험 요소를 최종적으로 보완하기 위해 울타리나 담을 짓는다. 애플리케이션 보안에 있어 이러한 울타리 역할은 ‘웹 방화벽(Web Application Firewall)’이 맡는다.
웹 방화벽은 웹을 통한 외부의 침입이나 웹 공격을 탐지하고 대응하는 역할을 한다. 특히 웹 보안 취약점을 외부에 노출되지 않도록 보호하고 해당 보호 솔루션들에게까지 공격이 미치기 이전에 외부에서 근본적으로 차단하는 역할까지 수행한다. 또한 웹 서버 악성코드가 웹 서버로 업로드되는 것도 막는다.
최신 웹 방화벽의 경우 광범위하고 다양한 웹 공격을 실시간으로 차단하고, 학습 모드를 통한 룰 적용이 가능한 특징을 지닌다. 이는 웹 방화벽이 일반적인 방화벽과는 달리 웹 애플리케이션에 특화되어 개발되어 있기에 가능한 일이다. 웹 방화벽은 여타 솔루션들과는 달리 서버에 구축 및 적용하는 비용이 들지 않고, 외부에 편리하게 설치할 수 있다.
데이터 보안, Data Security
마지막으로, 집안에 가장 중요한 현금과 통장 등 재산을 어떻게 보호할지의 문제다. 애플리케이션의 입장에서는 개인정보나 카드정보, 계좌정보와 같은 중요 데이터를 그러한 재산으로 볼 수 있다.
하지만 암호화만으로 모든 일이 끝나는 건 아니고, 누가 접근할 수 있고 언제 접근했는지 등을 확인하는 접근 제어와 로그 감사에도 많은 주의를 기울어야 한다. 또한 데이터 암호화에 있어서는 암호화된 데이터를 열어 볼 수 있는 데이터 암복호화 키 관리가 매우 중요하기에, 키 관리에도 각별히 주의해야 한다.
시큐어 코딩에서부터 데이터 보안에 이르기까지, 사실 위 전체 과정은 어떤 분야에 한정된 전문가가 담당하기보다는 각 분야 전문가와의 협업이 필수적이다. 즉, 분업이 필요하다. 그리고 개발자부터 사용자까지 각자의 역할을 충분히 발휘해야만 보다 완전한 보안을 이룰 수 있다.
그리고, 위와 같은 시스템을 구축한 것만으로는 안전한 웹 보안은 달성할 수 없다. 각 솔루션 요소의 설명에서도 언급했듯, 지속적인 관리를 통해 보안 상태를 확인하고 보완하는 과정이 필수적으로 동반되어야 한다.그런데,
“이건, 이제 새로 만드는 웹 서비스에만 해당하는 이야기 아닌가?”
그렇다. 그럼 이미 서비스 중인 현장에서는 뭘 어떻게 해야 하는가? 이어지는,
3편: “실제 현장에서 벌어지는, 실전 웹 보안”
..에서 알아보자.