2000년을 전후하여 처음 접하게 된 보안 솔루션이 있었습니다.
첫 직장에 입사 후 2년간의 개발 업무를 거쳐 Ingres RDBMS 기술지원 2년여… 그리고 시스템 통합관리 소프트웨어인 CA Unicenter 제품군과 BMC Patrol 제품을 거쳐 공부하게 된 보안솔루션이 바로 SecureOS 솔루션인 CA eTrust Access Control 입니다.
eTrust Access Control은 운영체제에 동적 커널 모듈 (DLKM : Dynamic Loadable Kernel Module)로 구현된 Secure OS 즉 보안 운영체제입니다. 운영체제라고 하여 Solaris, Linux와 같은 통~ 운영체제는 아니고 상용 운영체제에 DLKM으로 개발된 일종의 드라이버를 로드하여 보안 기능을 강화하도록 만들어진소프트웨어 모듈입니다.
그리고 몇년 뒤 회사를 이직할 때 선택한 회사가 바로 국산 SecureOS 제품인 RedCastle을 개발하는 레드게이트였습니다. 이때 부터 서버보안만 한우물을 파게 되었는데 10여년이 다된 지금까지도 SecureOS(서버보안)를 중심으로 대부분의 업무를 수행하고 있습니다. 다만 SecureOS의 제품변화 또는 기술적 발전 속도는 매우 더딥니다. 일부 영업맨들과 보안 전문가들은 몇년 전부터 SecureOS(서버보안) 시장이 포화상태라 할 정도로 시장의 성장도 느리고 기술의 변화도 느립니다.
하지만 SecureOS는 서버 운영체제에 로그인한 사용자 혹은 서버 운영체제 위에서 실행되는 서비스에 대한 통제를 수행하는 보안SW이기에 서버 운영체제를 잘 아는 엔지니어나 개발자가 아니면 이해하기 어려운 솔루션입니다.
SecureOS는 예전에 발생한 농협사태와 카드사 개인정보 유출과 같이 서버 엔지니어나 서버에 직접 로그인하여 작업을 수행하다 발생하는 보안사고를 예방하고 차단할 수 있는 유일한 보안 솔루션입니다.
SecureOS(보안 운영체제:서버보안)의 역사
SecureOS 역사의 시작은 Unix 서버 운영체제가 미국 국방망에 도입되어 사용되기 시작한 1970년대 초 즈음 부터~라고 보는 것이 옳습니다. 때문에 딱히 언제다…라고 못박기는 쉽지 않습니다. (대략 1970년대 라고 알려져 있음) 초기 SecureOS는 메인프레임 및 유닉스 운영체제의 소스코드내에 강화된 보안기능을 지원하는 코드를 추가하면서 즉, 운영체제 자체의 보안성을 강화하는 형태로 발전하였습니다. 이렇게 자체적으로 보안성이 높은 운영체제를 Trusted OS 라고 부르기도 합니다.
하지만 운영체제 마다 각기 다른 형태로 보안성을 강화하다 보니 기능적인 측면이나 관리적인 측면에서 일관된 보안 정책의 구현이나 통합관리가 어려웠기 때문에 당시 시장에서 확산되기 시작한 Unix 운영체제에 공통적으로 사용될 수 있는 DLKM 형태의 SecureOS가 연구되기 시작하였습니다.
그리고 확실하게 알려진 바는 없지만 1990년에 설립된 이스라엘의 Memco(멤코)라는 보안기업에 기술이 이전(추측)되었고 1990년대 중반에 최초의 DLKM 방식의 SecureOS인 SeOS가 개발되어 판매되기 시작하였습니다. 이후 이스라엘 Memco사의 SeOS를 플라티늄테크놀로지가 인수하였고 다시 다시 미국의 거대 소프트웨어기업인 CA(컴퓨터어소시에이츠)에 인수되는 우여곡절을 거칩니다.
우리나라에 최초로 SecureOS가 도입되기 시작한 것은 1990년대 후반입니다. SeOS가 매우 완성도가 높고 경쟁상대가 없었기에 거의 독점적으로 국내의 금융관련공기업과 일부 공공기관 그리고 대기업 위주로 알음알음 시장을 장악해 들어왔습니다. 당시에는 네트워크 기반의 방화벽 조차도 제대로 갖추지 못한 기관들이 많았기 때문에 매우 단순한 형태의 서버 해킹이 자주 발생하였고 SeOS를 통해 방어하도록 정책을 구현했던 사례들이 많습니다.저도 이때 처음 SeOS를 접하게 되었습니다.
하지만 초기에는 Unix 운영체제 자체의 안정성이 낮았던 데다 SecureOS의 커널모듈을 로드하게 되어 안정성을 더욱 떨어뜨리는 요인이 되었고 수 많은 장애를 유발하기도 하였습니다. 때문에 지금까지도 SecureOS는 “장애를 많이 일으키는 보안 솔루션”으로 인식되고 있기도 합니다.
국산 보안운영체제(SecureOS)의 개발
그리고 국내에서도 1990년 즈음부터 연구가 시작되어 2000년을 전후하여 ETRI와 KISA를 거친 일부 연구원들에 의해 국산 SecureOS가 개발되어 시장에 뛰어듭니다. 국산 SecureOS는 모두 DLKM 방식입니다. 이 DLKM의 핵심기능은 바로 참조모니터 기능입니다. 이 참조모니터를 얼마나 안정적으로 빠르게 동작하도록 만드느냐가 핵심 기술입니다. 그리고 운영체제의 다양한 자원에 대한 액세스를 안정적으로 빠르고 가볍게 가로채는 참조모니터의 개발은 결코 쉽지 않습니다. 때문에 2015년 현재 안정적인 SecureOS의 참조모니터 개발 기술을 보유하고 있는 보안 기업은 중소기업 두세곳에 지나지 않습니다. 그리고 늘어날 가능성도 거의 없습니다.
현재 국산 보안운영체제를 개발하여 시장에 공급하고 있는 기업은 딱~ 세 곳 입니다. 가히 삼국시대라 할 수 있습니다.
가장 먼저 SecureOS를 개발한 곳은 바로 Secuve(시큐브) 입니다. 제품명은 TOS 구요. 아마 Trusted-OS의 약자인 듯 싶습니다. 시큐브는 현재 코스닥에 상장되어 있습니다. Secuve TOS의 가장 큰 특징은 PKI 인증서 기반의 접근통제를 수행한다는 점입니다. 인증서에 단순한 인증정보만 담는 것이 아니라 인증서를 발급받은 사용자의 추가적인 권한에 대한 정보를 담아 서버에 접속할 때, 명령어나 파일에 접근할 때 접근통제를 수행하도록 정책을 구현할 수 있습니다. 하지만 인증서를 사용하는 방식은 실제 서버 운영자들에게는 매우 불편한 방식이어서 인증서를 사용하지 않고도 보안 정책을 수립할 수 있게 되어 있지만 TOS의 가장 핵심적인 가치를 배제하는 것이고 접근 통제 방식 자체를 변경하게 되면서 조금은 어정쩡한 상태의 제품이 되었습니다.
그리고 시큐브는 사업 영역을 점차 응용보안 쪽으로 이동시키고 있는 듯 합니다. 이는 시큐브가 여러 고객사에 제안하는 내용을 보면 알 수 있는데 아무래도 서버보안(SecureOS) 시장의 성장이 정체되어 있다고 생각하기 때문이 아닌가 싶습니다. TOS 자체의 기능 보강이나 확장이 그다지 눈에 띄지 않습니다. 그리고 개선해야할 것으로 보이는 기능도 개선되지 않고 있습니다. 대신 시큐브는 계정관리(Identity Management), 로그 통합관리 솔루션 그리고 커널 수준이 아닌 응용 수준에서 명령어의 실행을 통제하는 방향으로 제품을 개발하고 있는 것으로 보입니다.
시큐브의 TOS는 주로 공공기관을 주 고객으로 삼고 있습니다. 그리고 최근 몇년간 민수 시장을 적극 공략하고 있지만 공공시장에서만큼의 파급력을 보이지는 못하고 있습니다.
두번째로 출시된 SecureOS는 티에스온넷의 레드아울(RedOwl) 입니다. 하지만 티에스온넷은 하우리에 인수되었고 점차 시장에서 그 위상을 잃고 있는 분위기 입니다. 과거 시큐브레인이라는 회사의 하이자드라는 SecureOS가 안철수연구소에 인수되었다가 시장에서 사라진 사례를 떠올리게 하고 있습니다. 현재는 주로 국방과 철도 등 일부 시장에서 사용하고 있는 것으로 보입니다.
그리고 초창기와는 달리 제품의 형상도 크게 변화가 없고 군쪽을 제외하면 최근에는 대형 프로젝트에도 제안하지 않는 경우가 많습니다.
세번째로 출시된 SecueOS는 바로 레드비씨의 RedCastle입니다. 최초의 제조사는 RedGate라는 회사입니다. 제 블로그에서 주로 다루는 SecureOS이기도 합니다. 레드비씨는 PKI 및 전자문서 보안 기업인 비씨큐어와 RedCastle 제조사인 레드게이트가 합병되어 탄생한 보안솔루션 기업입니다. 그리고 코스닥에 상장되어 있기도 합니다.
RedCastle은 다른 두 SecureOS에 비해 가볍고 실제 서버 운영체제 내의 자원에 대한 접근통제 정책을 수립하기에 매우 적합하게 개발되어 있습니다. eTrust Access Control (SeOS)의 주요 기능을 벤치마킹하여 파일접근통제 기능을 개발하였고 직접 개발이 어려운 서버방화벽 기능을 과감하게 운영체제에서 제공하는 패킷필터링 모듈을 연동하여 지원하는 등 운영체제의 성능과 안정성에 최대한 영향을 적게 주도록 최적화 시켰습니다. 때문에 1금융권의 계정계와 정보계, 인터넷뱅킹 시스템 등은 물론 공인인증기관의 주요 핵심 공인인증 업무 서버에서도 안정적으로 도입되어 사용중에 있다고 할 수 있습니다.
게다가 레드비씨는 최근의 시장 요구를 가장 먼저 반영하고 있습니다. OTP, ARS, PKI 등의 2차 인증 인프라를 접목하여 서버에 접속할 때 2차 인증을 수행하고 서버에 로그인한 사용자가 누구인지 실제 자연인을 식별하여 명령어 실행 및 파일에 대한 감사로그를 기록하도록 하는 기능을 업계 최초로 적용하였으며 이미 서버에 로그인한 사용자라 하더라도 특정 명령어를 실행할 때는 한번 더 2차 인증을 받거나 ARS를 통해 상급자에게 실시간으로 승인을 받아야만 실행을 할 수 있도록 하는 명령서 사용 승인 기능과 시스템의 주요 작업 시 작업 신청/승인/정책스케줄링을 수행하는 명령어 통제 시스템으로의 확장도 구현하였습니다.
SecureOS(서버보안)의 주요 벤더인 3개 사 중에서 SecureOS의 본연의 역할에 가장 충실하고 체계적이고 보수적으로 기능을 확장해 나가는 벤더가 바로 레드비씨 입니다. 저 또한 그러한 레드비씨의 SecureOS 개발 철학이 마음에 들었고 같은 목표를 지향하기에 10년 이라는 시간을 우여곡절이 많았음에도 레드비씨에 투자할 수 있었다고 하겠습니다.
Secuve TOS .vs. RedCastle
글로 두 제품을 비교하는 것은 큰 의미가 없습니다. 많은 고객사와 SI 기업에서 비교자료를 요구하지만 그것은 그저 “두 제품을 비교했다”라는 요식행위를 갖추기 위한 것일 뿐입니다.
두 제품을 제대로 비교하자면 많은 테스트와 필드 경험이 필요합니다. 전 총 3제품을 테스트해봤습니다. 외산인 eTrust Access Control (현재 이름은 Control Minder : 콘트롤 마인더)과 RedCastle 그리고 Secuve TOS 입니다.
SecureOS의 아키텍쳐 측면에서는 RedCastle에게 가장 큰 점수를 주고 싶습니다. Security Category와 Security Level로 구성되는 보안속성(Security Label)을 사용자와 파일에게 부여하고 프로세스에게는 사용자의 보안속성이 상속되며 부여된 보안속성을 비교하여 Switch User 통제, Kill 통제, 프로세스 생성통제, 파일접근통제를 수행하는 강제적접근통제 기능은 처음 보았을 때 무릎을 치며 감탄할 수 밖에 없었습니다. eTrust Access Control 도 B1 시큐리티 기능에서 해당 기능을 제공하지만 기술적인 문제와 기능상의 문제로 실제 적용하기에는 부적합했는데 RedCastle에서는 파일접근통제를 제외한 나머지 부분에는 훌륭하게 적용이 가능했기 때문입니다. TOS의 경우 제가 테스트 했던 버전에는 인증서 기반이 아니기 때문인지 보안속성과 관련된 메뉴를 찾아볼 수 없었습니다.
게다가 일부 Secuve TOS와 RedCastle을 모두 사용해본 고객사에서는 접근통제가 가능한 파일의 개수에 제한이 있다는 정보도 얻을 수 있었습니다. RedCastle에 파일접근통제 기능을 개발할 때 Wildcard인 * 을 사용할 수 있게 개발해달라고 요청하여 접근을 통제할 파일을 /usr/bin/* 혹은 /web/html/*.html 과 같이 하나의 규칙으로 파일의 개수와 관계없이 접근 통제를 할 수 있도록 하였습니다. 그래야만 보안 정책을 단순화할 수 있고 실제 보안정책의 수립이 가능하기 때문입니다. (사실 이렇게 지원해도 불편한 경우가 생기긴 합니다.) 하지만 Secuve TOS는 와일드카드를 지원하지 않기 때문에 모든 보호대상 파일을 리스트업하거나 디렉토리명을 기준으로 정책을 수립해야 합니다. 게다가 개수의 제한도 발생할 수 밖에 없습니다.
와일드카드인 * 는 RedCastle과 eTrust Access Control 만이 지원하는 기능입니다.
기능 면에서는 SecureOS의 조상이자 원조라 할 수 있는 eTrust Access Control이 가장 다양한 기능을 제공합니다. 앞에서 설명한 와일드카드의 경우 eTrust Access Control은 * 기호 이외에도 ? (한글자 패턴매칭)를 지원합니다. 그 외에도 글로벌 기업 답게 매우 다양한 기능을 제공하는데 어떤 고객사도 모든 기능을 다 사용하지는 않습니다. 전체의 50%도 사용하지 못합니다. 다음이 RedCastle이고 그 다음이 Secuve TOS 입니다. TOS의 경우 제가 테스트하는 서버에 전체 기능이 모두 설치되지 않았는지는 모르겠지만 제품의 스펙으로 제시하는 기능의 일부를 찾을 수 없는 경우가 많았습니다. 고객마다 다른 제품을 설치하는 것인지 모르겠습니다.
마지막 비교 포인트는 SecureOS에서 가장 중요한 지표인 안정성입니다.
안정성의 경우에도 경험에 의해 주관적으로 판단할 수 밖에 없는데 RedCastle이 단연 최고의 안정성을 보여줍니다. 어떤 인터넷 쇼핑몰 고객사의 경우 RedCastle을 초기에 도입했다가 유지보수 비용 문제로 인해 타 제품으로 교체하였습니다. 하지만 채 3년이 되지 않아 다시 RedCastle을 설치하기로 한 사례가 있습니다. 그 당시 이유는 바로 “기능’과 “안정성” 이었습니다.
RedCastle은 한 고객사에서 운영하는 수백대의 서버에 단시간에 설치하는 사례가 흔합니다. 하지만 장애가 발생하는 경우는 많아야 한-두대에 지나지 않습니다. 그 한-두 대도 CPU 사용율이 높다던가 특별한 설정이나 SW가 설치되어 있어 발생하는 경우가 대부분입니다. 제품의 자체 버그로 인해 장애가 발생하는 경우는 훨씬 빈도가 낮아집니다.
그 외에도 해킹으로 인한 보안사고가 발생한 고객사에서 타사 제품을 통해 해킹을 차단하지 못해 RedCastle로 교체 도입하거나 기능상의 제약으로 인해 제품을 변경하는 경우도 경험할 수 있었습니다.
하지만 어쨌든 비교 대상인 세 SecureOS는 일정 수준의 안정성을 확보한 제품입니다. 그랬기에 시장에서 살아남을 수 있었고 나름대로 점유율을 확보할 수 있는 것입니다. 다만 차이가 크지는 않지만 분명 안정성과 기능면에서는 차이가 있다는 것을 말씀드리고 싶습니다. 특히 SecureOS를 제대로 활용하여 서버의 보안성을 높이고 싶은 기업이나 공공기관이라면 다른 제품보다는 RedCastle을 도입할 것을 권하고 싶습니다.