최근 발생한 현대캐피탈과 농협 그리고 이번 KBS, MBC, YTN, 신한은행, 농협의 치명적인 보안사고로 인해 금융산업분야 뿐만 아니라 비지니스를 위해 혹은 전산시스템이 비즈니스 그 자체인 많은 기업과 공공기관에 초비상이 걸렸다. 덕분에 나도 너무 많이 바빠진 사람중의 하나가 되었다.
하지만 Unix/Linux 운영체제는 자체적인 보안기능이 매우 부족하다. Unix/Linux가 애초부터 “보안”을 염두에 두고 개발한 운영체제가 아니기 때문에 운영체제 자체적으로 엄청나게 많은 관리적/기술적 취약성을 갖고 있다. 기술적 취약성 중 일부는 운영체제의 설정을 변경하여 보완할 수도 있지만 근본적으로 한계를 갖고 있으며 관리적 취약성은 운영체제 차원에서는 대응할 수 있는 방안이 없다.
그래서 공공기관 및 금융부문에서는 RedCastle과 같은 SecureOS S/W를 서버에 설치하여 Unix/Linux 운영체제의 기술적/관리적 취약성을 보완하고 있다. 하지만 보안강화를 위해 RedCastle에 보안정책을 “넣어달라”는 요청은 많은데 비해 “어떤” 정책을 수립 할 것인가에 대해서는 아무런 생각이 없는 경우가 대부분이다.
그래서 Unix/Linux 서버의 운영자 및 보안부서의 IT 담당자분들께 도움이 될만한 서버보안 정책 가이드라인을 제시해본다.
Unix/Linux 계정 통제 정책
흔히 계정통제라고 하면 여러 서버에 동시에 계정을 생성하고 패스워드를 일괄 변경하는 것을 생각하기 쉽다. 하지만 서버보안에서 계정통제라 함은 다음을 의미한다.
l 계정은 몇 개를 어떤기준에 의해 생성할 것인가
l 각 계정별 로그인 통제는(계정/서비스/IP/시간의 조합에 의한 로그인 통제) 어떻게 할 것인가
l 서버에 로그인한 사용자가 다른 계정으로의 Switch User를 하는 행위에 대해 어떻게 통제할 것인가
l 계정을 이용한 행위 감사(Audit)는 어떻게 할 것인가
흔히 계정관리와 혼동하는 패스워드의 일괄 변경은 기본적인 보안정책 즉 서버마다 패스워드를 다르게 설정하여야 한다는 아주 기본적인 보안정책에 위배된다. 이는 하나의 패스워드가 유출되면 전체 서버의 패스워드가 유출되는 끔찍한 결과를 차단하기 위해 권고되는 패스워드 관리 정책이다.
금번 농협의 보안사고에서도 단 몇 개의 root 패스워드가 내부자에 유출되었을 것이지만 피해는 275대의 서버에서 발생한 것처럼 어쩌다~ 한번 발생한 사고가 너무도 큰 피해를 유발하게 될 수 있다.
1) 계정은 몇 개를 어떤기준에 의해 생성할 것인가
서버에 TELNET, FTP, SSH 로그인을 수행하는 개인들은 서버에 혼자만 사용할 개인의 계정을 만들고 서버에 로그온할 때는 자신의 계정을 이용해 로그온 할 것을 권고한다.
이것을 굉장히 어려운 일이라거나 서버의 장애를 유발할 것이라는 막연한 두려움을 가진 관리자들이 너무도 많다. 서버의 운영체제는 다수의 사람들이 동시에 접속할 것을 전제로 만들어진 Multi-User, Multi-Tasking 운영체제다. 계정을 100~200 개 생성해도 계정이 많다는 이유로 서버가 느려지거나 장애가 유발되지는 않는다. 그 사람들이 동시에 접속하여 부하가 큰 명령을 동시에 실행하지만 않는다면 말이다. 몇개의 계정을 100명이 사용하는 것이나 100개의 계정을 100명이 사용하는 것은 동일한 부하를 유발한다고 생각하면 맞다.
시스템관리자, DB관리자, 어플리케이션 관리자 등 수많은 사람들이 Root, oracle, weblogic, jeus, tuxedo 등 공용계정을 공유하여 사용하는 것은 장애 혹은 보안사고 발생 시 원인분석을 어렵거나 불가능하게 만드는 주요 원인이다. 때문에 개인계정을 생성하여 스스로의 관리 책임하에 서버에 로그온 하는 것이 올바른 계정 생성 정책이다.
자신만의 계정으로 로그인 한 뒤 root, oracle 등과 같은 수퍼유저 및 애플리케이션 관리자 계정으로 SU하여 사용하도록 하여야 한다.
2) 계정의 로그인 통제는 어떻게 할 것인가
Root, oracle, tmax, weblogic, tuxedo 등 Super-User의 계정과 애플리케이션 관리자 계정등 공용계정으로의 직접 로그인은 차단하여야 한다.
Super-user 계정인 root로 여러 사람이 직접 telnet 로그인하는 것을 허용하게 되면 문제 발생 시 도대체 누가 로그인하여 작업했는지에 대한 추적이 불가능해진다. 때문에 서버에 로그온 하여 작업을 수행해야 하는 개인들은 모두 개인계정을 만들어 사용하고 root 이하 공용계정으로는 직접 로그온 하지 못하도록 통제하여야 한다.
추가적으로 각 개인별로 사용하는 IP에 대해서만 로그온 할 수 있도록 IP 통제까지 수행한다면 보안성은 대폭 개선될 수 있다.
3) 서버에 로그인한 사용자가 다른 계정으로의 Switch User를 하는 행위에 대해 어떻게 통제할 것인가
계정의 이동(Switch User)통제는 시스템운영에 상당히 민감한 영향을 끼칠 수 있다. 그리고 체계가 잡히지 않은 중구난방~식의 SU 통제는 시간이 지날수록 문제를 유발시킬 가능성이 커지기 때문에 SU를 통제할 때에는 시스템을 운영하는 전산부서 전체에 적용할 수 있도록 정책을 확실하게 수립하는 것이 좋다.
계정이동통제(SU) 정책 수립 시 기본 지침은 다음과 같다.
– Super User인 root 계정으로의 SU를 허용할 개인계정을 그룹핑한다.- Oracle, Weblogic 등 애플리케이션 별로 SU를 허용할 계정을 그룹핑한다.
위의 두 지침에 의해 계정들이 그룹핑 되면 다음의 기본 SU통제 지침을 적용한다.
– root 과 oracle, weblogic 등 애플리케이션 관리자 계정간의 SU는 차단한다.- 앞에서 그룹핑된 각 그룹에 속한 내부 사용자간의 SU는 허용한다.- 서로 다른 그룹간의 SU는 차단한다.
4) 계정을 이용한 행위 감사(Audit)는 어떻게 할 것인가
계정에 대한 행위감사는 사용자가 서버에 telnet, ssh, rlogin 등의 방법으로 서버에 로그온 한 시점부터 로그아웃 시점까지의 모든 명령어 수행에 대해 기록을 남겨야 한다. 운영체제에서 제공되는 Shell History는 모든 명령어 입력에 대해 감사기록을 남겨주지만 세션에 대한 구분 및 하나의 계정으로 여러명이 접속하였을 때 각각의 원래 사용자를 식별하지 못하는 문제가 있기 때문에 큰 의미는 없다.
RedCastle과 같이 모든 세션을 식별하여 SU하기 전과 SU한 이후까지도 연결고리가 끊기지 않고 추적이 가능하도록 해야 하며 커널레벨과 TTY레벨의 추적 모두가 가능하도록 하면 최고의 사용자추적(행위감사)이 가능하다.
이상 네가지 기본적인 서버의 계정통제 정책을 적용하면 체계적인 계정관리가 가능하고 Unix/Linux 운영체제에서 제공되는 기본기능인 su 를 통해 타 계정의 권한을 탈취하는 악의적인 행동을 방지할 수 있다.
물론 이 계정통제 만으로 Unix/Linux 서버를 운영하는 전산시스템의 내부보안을 강화하는 것에는 한계가 있다. 추가적으로 파일접근통제 정책을 적용해야 제대로 된 서버보안 정책을 적용했다고 할 수 있다.
기회가 되면 파일접근통제에 대한 정책가이드도 올려보도록 하겠다.
현대캐피탈과 농협의 보안사고 여파로 인해 요즘…살이 다 빠질 지경이다.. ^^