CMS+클라우드 사용자에게, 웹사이트란 무엇인가?
“웹사이트란 무엇인가?”
이거, 웹사이트 보호 도구를 개발하고 판매하는 자에겐 가장 곤혹스러운 질문이다. 물건 사는 사람이 그게 뭔지 알아야 팔든 말든 할 게 아닌가,,
기술적으로 말하자면 웹사이트란 ‘인터넷 프로토콜 기반 네트워크 상에 존재하는 각각 주소와 경로를 따로 가진 페이지들이 유의미하게 묶인 구조체’다. 근데 온통 기술 천지인 듯하지만 실은 기술-소외 시대인 요즘 누가 기술적으로 말하나? 기술적으로 말하면 다들 “쟤 왜 저래?” 막 싫어하니까 공공장소에선 감히 입밖에 내지 않는 게 좋다. 그러니 톤을 좀 달리해 말해 보자.
요즘 웹사이트 개발 및 운영 추세를 살펴본다.
CMS : Content Management System
CMS, 이건 확실히 대세다. 보다 정확하게는 ‘WCMS: Web Content Management System, 웹 컨텐츠 관리 시스템’이라고 해야 보다 정확한 용어겠지만, 편리하게 그냥 CMS.
컨텐츠의 홍수, 많다 못해 지나치다 싶을 정도로 마구 범람하는 컨텐츠를 ‘관리’하는 일이 과연 가능하기나 할까 싶을 지경이지만, 이를 꽤 간단히 처리해냄으로써 자칫 그냥 버려질 것들을 유용한 자원으로 가공하기 위한 도구가 CMS다. 요즘 CMS는 홈페이지 저작도구, 전자상거래 카탈로그 관리, 각종 컨텐츠 관리 등 일반적인 웹 개발 및 운영 도구라는 일반적 용도뿐 아니라 대형 웹사이트의 소스코드 등 전사적 자원 관리 ERP의 면모까지 갖추고 있다.
최근 들어 뜨거운 유행어가 되었을 뿐 사실 CMS는 꽤 오래된 용어다. 1990년대, 조직의 여러 자원을 쉽고 간단하게 통합관리 하기 위한 방법을 모색하던 시절 제시된 방법론. 그 시도가 웹의 대중화에 힘입어 폭발적으로 성장해 오늘날의 웹 환경에서 주도적 위치를 점하게 되었다.
CMS 인기의 가장 큰 이유는 쉽고 간단하기 때문이다. 애초에 “어렵지 않게 만든다”는 철학 하에 개발된 도구다. 어렵고 복잡하게 만들어도 된다면 다른 좋은 방법도 무수히 많으니, 처음 생겼을 때부터 지금까지 계속 유지되고 있는 철학이다.
물론 제품마다 기술적 난이도 차이는 있다. 예컨대 ‘드루팔’은 여타 경쟁 제품에 비해 어렵다는 불평이 많다. 하지만 자유도와 난이도는 반비례하는 법이니, 대신에 개인 블로그에서부터 대형 웹사이트 나아가 기업용 ERP 애플리케이션에 이르기까지 개발 자유도가 높다는 강점이 돋보인다. 그리고 어렵다곤 하나 상대적으로 그렇다는 것일 뿐, 같은 수준의 웹사이트를 맨땅에 헤딩하듯 만드는 일에 비하면 손바닥 뒤집기처럼 쉽고 간단하다. 게다가 전세계 개발자 커뮤니티가 제공하는 모듈과 테마 그리고 온라인 지원 등, 안 그래도 쉬운 일을 더 쉽게 만드는 자원도 풍부하다. 그러니, 대세일 수밖에.
그렇다면, CMS 사용자에게 웹사이트란 어떤 의미일까? 실제로 CMS를 이용해 웹사이트를 구축하고 운영하고 있는 몇몇 친구들에게 “웹사이트가 뭐라고 생각해?” 질문했다. 대답은,
“내 웹사이트는 워드프레스야.”
“가산디지털단지 인터넷 데이터 센터 안에 있는데 왜?”
“요즘 누가 그냥 호스팅을 해? 내 웹사이트는 대세에 따라 아마존 클라우드야.”
아 뭐냐, 뜻밖에도 위 대답이 가장 많았다. 반면,
“내 소유의 웹 페이지와 컨텐츠 데이터”
..라고 정답(!)을 말한 사람은, 단 한 명도 없었다! (물론 그리 답해도 “얘 뭐야?” 왠지 기분 좀 이상할 거 같긴 하다,,)
이 질문이 왜 중요하냐면, 웹사이트가 뭐라고 인식하느냐 정체에 따라서 웹사이트 보호 방법이 완전히 달라지기 때문이다.
CMS 그리고 관련 플러그인 모듈 등은 웹사이트 저작 및 운영관리 도구다. 즉, 애플리케이션이므로 애플리케이션 개발 및 배포 시 필요한 보안이 핵심이다. 따라서, ‘시큐어 코딩
(Secure Coding)’ 등 애플리케이션 개발 보안 방법론을 통해 안전한 애플리케이션을 만드는 일이 가장 중요하다. 완벽할 수 없으니 애초에 불안한 대답이긴 하지만.
CMS 사용자 입장에서는 사용하는 CMS의 버전을 늘 확인하고 제때 보안 패치 및 업데이트를 받는 일이 거의 일상이 되어야 한다. (WAF를 제대로 활용한다면 이런 일상적 노력이 거의 필요 없긴 한데, 이는 뒤에 다시 이야기하자.) 그래야지 어떤 위험이 발견되고 문제를 해결하는 패치가 적용되어 위험이 사라질 때까지의 시간적 틈을 노리는 공격, 즉 ‘제로데이 공격’ 등의 위험을 피할 수 있다. CMS 자체뿐 아니라 각종 모듈들도 안전성을 확인하는 관심과 노력이 필요하다. 뭐든 확실히 믿을 수 있는 사이트에서만 내려받아야 하고.
모듈 개발자가 아니라면 CMS 애플리케이션 자체 관련해 사용자가 따로 할 일은, 없다.
2. “내 웹사이트는 어디어디 IDC에 있다.”
이는 기술적으로는 대충 적절한 답변이긴 하다. 웹사이트란 결국 데이터이고 웹사이트 데이터는 대개 IDC에 저장되니까. 그리고, “내 웹사이트는 어떤 클라우드 서비스다.” 사실 거의 똑같은 말이다. 클라우드 서비스라고 해서 데이터가 진짜로 구름 속에 저장되는 건 아니니까.
데이터를 안전하게 관리하는 방법은, 사실 너무 방대한 내용이라 뭐라 딱 잘라 말하기 어려운 일이다. 하지만 아래 ‘컨텐츠’ 개념을 따로 분리했으니 간단하게 IDC 내부의 네트워크 및 데이터베이스 등 시스템 장치 보안으로 단순화해 보자. IDC 운영자는 서버를 보호하기 위해 방화벽이나 IDS/IPS 등 각종 네트워크 보안 설비를 구축하고 운영한다. 보다 아래 계층에서부터 네트워크 스위치에 보안 기능을 추가하기도 한다. 이러한 일련의 관리를 통해 바이러스와 악성코드 유입 그리고 해커의 네트워크 침입 등을 막는다.
그럼 CMS 사용자 입장에서의 IDC 관련 보안 조치는? 각자 형편에 따라 다르다.
웹사이트 보유자가 웹 데이터를 저장하는 방식에는 대략 3가지 경우가 있다. 첫째, IDC에 설치한 웹 서버를 분할해 사용료를 받고 임대하는 호스팅 서비스를 이용하는 경우. 소규모 기업이나 개인이 운영하는 웹 서비스가 대개 이 방식을 택한다. 둘째, IDC에 있는 웹 서버를 직접 관리하는 경우. 예전엔 대부분의 기업들이 대안이 없었기에 대개 이 방식을 취했다. 하지만 요즘은 아주 큰 기업 아니라면 점차 다음 방식으로 전환하는 추세다. 셋째, 클라우드 호스팅 서비스를 이용하는 경우. 아직은 어째 좀 불확실성이 있다 싶어 전환을 주저하기도 하지만 머잖아 폭발적으로 성장하리라 예상한다. 지금도 굉장히 성행하고 있지만, 훨씬 더!
만약 CMS 사용자가 세번째 방법, 즉 ‘AWS’ 등 클라우드 호스팅 서비스를 이용한다면? IDC 관련 보안에 대해 보안 서비스 옵션 선택 외에는 딱히 할 수 있는 일이 없다. 심지어 클라우드 서비스 특성 상 내 데이터가 저장된 데이터 센터가 세계 어느 나라 어느 지방에 있는지도 모를 수 있다.
3. “내 웹사이트는 나의 웹 페이지와 컨텐츠 데이터다.”
드디어 최초 질문의 의도 핵심에 도달했다. 웹사이트 보호에 있어 가장 중요한 것은 무엇인가?
CMS가 안전하게 개발되었다고 전제한다면 저작 및 관리 애플리케이션 보안성은 충족했다고 볼 수 있고, 어떤 서비스를 이용하든 데이터가 저장된 IDC가 적절한 네트워크 보안 조치를 취하고 있다면 일단 데이터 저장소는 안전하다고 가정할 수 있다. 하지만 웹 컨텐츠 보호는 그 두 가지 보안대책에 비해 상대적으로 매우 취약한 편이고 또 사용자가 직접 결정하고 처리해야 할 몫도 큰 편이다.
CMS 애플리케이션의 취약점을 악용한 공격 그리고 데이터의 물리적 저장소의 보안 취약성을 노리는 공격에 비해, 웹 컨텐츠를 노리는 그리고 웹 컨텐츠를 통해서 일어나는 공격은 얼마나 될까? 모든 웹 보안 공격 중 무려 90%를 차지한다..는 말을 지금껏 몇 번이나 했는지 모를 정도로 늘 강조하지만 늘 간과되니 참 딱할 노릇이다.
근데 이는 참으로 복잡다단한 웹 보안의 요소들을 순전히 편의를 위해 서로 배타적으로 분류한 것이다. 위 3개 요소는 딱 잘라 나눌 수 있는 것들이 아니라 실은 서로 연결되어 있다는 뜻이다.
이를테면, WAF는 CMS의 소프트웨어적 취약점까지도 보호해 준다. 예를 들어, 대개 CMS는 관리자 페이지에 취약성이 많다. 관리자 페이지에 들어가려면 관리자 로그인을 딱 한 번 거치면 되는데 일단 들어가고 나면 관리자 페이지 내부는 보안에 거의 신경을 쓰지 않는 구조다. 그러니 앞서 말한 보안 패치 및 업데이트의 상당수가 로그인 화면 취약성 문제 해결을 위한 것들이다. 보다 정직하게 말하자면 위 ‘시큐어 코딩을 잘해서 취약성 문제를 해결하자’는 말은 결국 달성할 수 없는 이상적 목표에 가까운 말. 하지만 WAF를 통해 시큐어 코딩이 부실하게 이루어진 취약점을 막을 수 있으니, 방법론의 효과로만 말하자면 서로 배타적 요소가 아니라 포함된 요소라 할 수 있다.
CMS+클라우드 사용자의, 웹 컨텐츠 보호 방법
웹 컨텐츠를 노리는 공격, 그리고 웹 컨텐츠를 통해 일어나는 공격은 ‘WAF (Web Application Firewall, 웹 애플리케이션 방화벽)’을 이용해 막는 수밖에 없다. 복잡하게 말하자면, 절대적 다수의 웹 컨텐츠 공격이 주로 네트워크 L7 계층에서 발생하는데 WAF만이 유일하게 L7 계층을 사수하기 때문이라는 등의 설명이 따라야겠지만 앞서 기술적으로 말하지 않기로 했으니 간단하게, WAF뿐이다.
그럼, WAF 적용을 위 3가지 데이터 저장 방식에 차례차례 대응해 보자.
첫째, 기존 웹사이트 호스팅 서비스를 이용하는 경우, 서비스 업체가 적절한 WAF 시스템을 갖추고 있는지, 아니면 뒤에서 알아볼 클라우드 WAF 서비스와 협조관계를 맺고 있는지 알아본다. “그냥 방화벽은 있는데, 웹 방화벽은 또 뭐예요?” 되묻는다면 즉시 더 이상의 대화는 포기하고 어서 다른 업체를 알아본다. 적절한 WAF 시스템을 갖추고 있다면, 그리고 적절하게 운용하고 있다면 일단은 안심해도 좋다. ‘적절하다’는 말은 늘 좀 무섭긴 하나,,
둘째, 자체 보유한 웹 서버를 직접 관리하는 경우. 적절한 WAF 시스템을 구축하고 운영한다. 적절한 WAF와 그렇지 않은 WAF를 구별하는 결정적 변수는 당연히 문제 탐지 엔진의 성능이다. 웹 서버를 직접 관리하는 경우라면 이미 웹 개발 관련 전문가 수준일 거라, 뭐 알아서 잘하시리라 기대한다.
셋째, 클라우드 호스팅 서비스를 이용하는 경우. 이게 좀, 구멍이다. 대부분의 유명한 클라우드 호스팅 서비스들은 모두 충분히 믿을 만한 네트워크 보안 서비스를 제공한다. 필요에 따라 선택적으로 보안 서비스를 받을 수도 있다. 하지만 웹 컨텐츠 보호에 대해서는 특별한 방법을 따로 제공하지 않는다.
안티바이러스? “OK!”
네트워크 보안? “OK!”
웹 컨텐츠 보호? “아니 그건 좀,,”
대개 이런 식이다. 단지 기술적 문제 때문만은 아니고 웹 컨텐츠 레벨에서의 내용 검수 등 법적 적절성 문제까지도 얽혀 있어 굉장히 복잡한 문제인데 어쨌든 중요한 건, 클라우드 호스팅 서비스들의 보안성은 웹 컨텐츠 보호에서만큼은 매우 취약하다는 점이다. 이를 어쩌지?
클라우드는 클라우드로 막는다. 클라우드 WAF 서비스가 있다. 매우 간단하다. 버튼 몇 개만 누르면 해당 웹사이트를 어떤 저작도구로 만들었든 그 데이터가 어디에 저장되어 있든 상관 없이 웹 컨텐츠를 보호하는 WAF 기능을 제공한다. 일정한 양의 트래픽은 일종의 체험판으로서 무료로 사용할 수도 있고 위험 부담도 없으니 한 번쯤 시도해 보시길.
물론 기존 웹사이트 호스팅 서비스를 이용하는 경우에도 클라우드 WAF 서비스를 이용할 수 있다. 만약 호스팅 서비스 사업자가 클라우드 WAF 서비스 업체와 서로 협조관계를 이루고 있다면 개인이 따로 신청하는 것보다 더 저렴하게 이용할 수 있다. 회사가 자체 보유한 웹 서버를 직접 관리하는 경우도 그러하다. 클라우드 WAF 서비스는 언제 어디서나 누구나 클릭 몇 번만 하면 바로 동작하니까.
아무래도 좀 복잡한 주제를 이야기하다 보니 애초 의도와 달리 막 길어졌다 싶은데 짧고 간단히 정리하면,
CMS + 클라우드 웹사이트 운영자라면,
– CMS의 보안 취약성과 패치 및 업데이트 여부를 늘 챙길 것
– 클라우드든 아니든, 보안에 충분히 신경을 쓰는 데이터 센터인지 알아볼 것
– 특히 웹 컨텐츠 안전성을 맡는 WAF 기능의 적절성에 집중해 볼 것
– 유연한 구조라 어떤 상황에서도 즉시 이용할 수 있는 클라우드 WAF 서비스를 알아볼 것