최근 몇년간 대형 보안사고 및 정보유출 사고가 증가하는 추세다. 그리고 대형 공공기관과 금융기관 그리고 일반 기업에서 보호 대책의 일환으로 다양한 보안 솔루션들을 많이 도입하고 있다. 그중에서도 핫~한 솔루션이 바로 SAC (System(or Server) Access Control) 솔루션이다. 그리고 이러한 SAC 솔루션들이 인사시스템과 연계하여 계정통합관리(Identity Management : IM) 솔루션의 영역까지 접수(?)하면서 시장을 넓혀가고 있기도 하다. 게다가 SecureOS의 기능까지 갖고 있는 것처럼 영업을 하면서 계정통합관리솔루션과 서버보안솔루션(SecureOS) 시장을 잠식하고 있다.
하지만 보안업계에서 10년이상 일을 하고 있는 내 관점에서 보았을 때 SAC는 보안솔루션의 범주에 넣기가 망설여지는 솔루션이다. SAC는 많은 애플리케이션과 서버 그리고 계정(Account)이 있는 네트워크 장비에 대한 접근 경로 관리의 편의성 증대를 위한 통합 관리 솔루션이지 “보안솔루션”으로 보기에는 어딘가 어정쩡한 범주에 있다.
IM솔루션의 경우 시장에서 “계정통합관리”라는 새로운 영역을 개척하였고 명확한 타켓팅을 두고 영업을 하고 있지만 SAC의 경우 단순히 시스템(서버, 네트워크 장비)에 대한 접근경로의 단일화 라는 기능 이외에는 특별한 기능이 없다 보니 계정통합관리, 서버의 명령어 통제 등 본연의 기능이 아닌 기능을 응용수준에서 지속적으로 추가하며 타 솔루션의 영역을 침범하면서 덩치를 키우는 상황이 되었다.
하지만 많은 IT 담당자 들이 생각하고 있듯이 SAC 솔루션은 제대로 된 보안 솔루션으로 보기에는 무리가 있다. SAC가 일부 계정통합관리 및 접근제어(Access Control)와 감사(Audit) 기능을 갖고 있지만 그 기능이라는 것이 대부분 우회와 인젝션이 매우 쉽게 가능하기 때문에 단독으로는 어떠한 기능도 제대로 된 수준으로 구현할 수 없음에도 불구하고 그러한 단점을 감추며 승승장구 하고 있는 모습을 보면서 우리나라 IT 종사자들의 기초체력의 부실함(?)이 드러나는 것 같아 안타까운 마음이 들곤 한다.
실제로 SAC 솔루션을 도입한 대부분의 대기업이나 공공기관에서 SAC를 이용해 계정통합관리와 서버보안 그리고 시스템접근제어를 한번에 해결하려 시도하지만 프로젝트 기간이 지나면 지날 수록 그 한계를 절감하고 서버보안SW를 별도로 도입하기로 하거나 이미 도입되어 있는 서버보안SW를 대체할 수 없음을 절감하게 된다.
어찌보면 계정통합관리솔루션도 아니고 서버보안솔루션도 아닌 어정쩡한 포지션의 틈새시장을 노리고 시장에진입한 SAC 솔루션이 시장에서 살아남기 위한 처절한 몸부림이 계정통합관리와 서버보안의 영역의 침범으로 표현되고 있다고 보여진다. 하지만 계정통합관리와 서버보안은 쉽게 영역을 침범할 수 있는 솔루션이 아니다. 그래선지 실제로 SAC를 도입해 통합계정관리와 서버보안의 구현하고 있는 프로젝트를 들여다 보면 제대로 마무리가 되는 경우를 찾아보기가 힘들다.
게다가 SAC 솔루션의 개발사나 프로젝트 수행사 자체가 서버기반의 솔루션이나 운영체제의 특징을 제대로 이해하지 못하기 때문에 서버의 계정과 비밀번호에 대한 통제가 제대로 구현되지 못하는 경우도 많다. 보안을 강화하려다 오히려 취약점만 키우는 경우도 발생하게 되는 것이다.
가장 대표적인 사례가 바로 root, oracle, jeus등 시스템 관련 패스워드를 모든 관리자가 모르게 한다는 것이다.
SAC의 경우 SAC에 로그인하면 서버로의 로그인에는 비밀번호를 몰라도 로그인이 가능하도록 비밀번호를 자동으로 입력하는 기능이 제공된다. SAC가 root 계정은 물론 서버의 모든 계정에 대한 비밀번호를 랜덤하게 변경하고 사용자가 서버에 Telnet, FTP 등의 접속 시 자동으로 패스워드를 입력해주는 것이다. 200대, 300대에 대한 패스워드를 그렇게 관리하는 것이다.
즉 SAC의 서버만 뚫리면 전체 시스템에 대한 관리자 계정과 패스워드가 한번에 유출될 수 있는 SPOF (Single Point of Failure) 지점이 생기는 것이다. SPOF는 점점 복잡해지는 시스템과 네트워크의 환경에서 반드시 피해야 하는 요소 중 하나 인데 SAC로 인해 매우 Critical한 SPOF가 만들어지는 것이다. 모든 시스템의 패스워드가 하나의 DB에 저장 됨으로 해서 장애나 정보 유출 등이 발생할 경우 그 피해는 상상하기 어렵다. 게다가 특정 시스템에서 보안사고가 발생할 경우 모든 출발지가 SAC 장비로 운영체제의 감사 로그에 기록되기 때문에 서버 입장에서는 감사 추적이 더 어려워지고 모든 감사 추적과 분석을 SAC에 의존할 수 밖에 없게 된다. 이 또한 피해야 하는 현상이라고 할 수 있다.
경영 이론에서 투자의 위험은 분산 시켜야 한다고 한다. 역시 보안의 관점에서도 위험은 분산 시키는 것이 기본이다. 하지만 SAC는 수많은 시스템의 위험이 SAC로 집중되는 역효과가 일어날 수 밖에 없다.
이쯤되면 SAC는 보안 솔루션의 범주에 두기는 어렵다고 판단할 수 있다. SAC는 보안감사와 패스워드 관리의 편의성을 위해 도입되는 통합관리솔루션 정도로 봐야할 것이다. 아직은 SAC가 시장에 진입한지 몇년되지 않기 때문에 도입 대비 보안강화의 효과는 단언할 수는 없다. 분명 관리의 편의성은 높아지겠지만 실제 보안의 관점에서 SAC의 효과는 기대하기 어렵기 때문이다.
SAC의 미래가 자못 궁금해진다.
첨부: SAC와 서버보안SW의 비교표
관련 포스트
2 채널인증과 2 팩터 인증의 차이점과 네트워크 기반 서버접근제어 2 팩터 인증의 취약점