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