taeho's life logger

root 와 Administrator 그리고 Information Security 본문

정보보호

root 와 Administrator 그리고 Information Security

taeho Tae-Ho 2016.02.05 16:12

요즘 심심치 않게 ISMS인증 또는 PCI/DSS 인증 등 여러 정보보안 관련 인증심사에 대비하는 기업이나 기관으로 부터 RedCastle SecureOS와 AuthCastle 등의 제품소개를 요청받는 경우가 있습니다.  왜냐하면 ISMS 등 심사에서 인증기준으로 삼는 수 많은 통제항목 중 "서버"에 관련된 심사항목은 많을 수 밖에 없고 운영체제의 보안설정이나 취약점제거 만으로는 해당 통제항목의 요구사항을 충족하기 어려울 뿐만아니라 통합관리가 어렵기 때문입니다.


서버에 대한 접근통제, 중요 감사로그 파일에 대한 위변조 차단, 소스파일에 대한 보호, 서버의 패스워드 통제 그리고 중요한 암호화키 및 중요 데이터가 저장된 파일에 대한 읽기/수정/삭제 통제와 무결성 보장 등 다수의 서버에 대한 정보보호 수준을 높이기 위한 활동은 무척 어려운 사안일 수 밖에 없습니다. 


하지만 그러한 서버의 보안수준을 높이기 위해 무엇보다 먼저 시행해야 하는 것은 서버에 접속하는 개발자 및 관리자들에 대한 1인1계정 부여입니다. 즉, 내부통제 강화죠.

무시되는 Unix/Linux 서버에서의 1인 1계정

Unix/Linux 서버는 기본적으로 다중사용자를 지원하는 서버 운영체제입니다. 그래서 서버의 운영자가 웬만큼 많지 않고서는 서버의 보안강화를 위한 "1인1계정" 원칙을 지켜 서버에 로그인 해야하는 개발자와 운영자에게 각각 개인 계정을 발급해도 전혀 문제가 되지 않습니다.



하지만 실제 서버의 운용 상황은 그렇지 않습니다. 실제 수많은 기업이나 금융기관 혹은 공공기관에서 운용하는 서버에 접속해 보면 root와 같은 서버 운영체제의 수퍼유저 계정과 oracle, jeus 등 별도의 계정이 필요한 시스템SW와 데이터베이스 관리자 계정 이외의 개발자나 서버운영자의 개인계정은 찾아보기 힘듭니다.


실제로 하나의 서버에 Telnet, SSH 등을 통해 접속하는 개발자나 운영자는 적게는 두세명에서 많게는 10여명이 넘기도 합니다. 여러사람이 root, oracle, jeus 등의 매우 크리티컬한 계정으로 직접 로그인하여 권한의 분리를 수행하지 않는게 현실입니다. 그리고 이러한 행위를 "통제"하거나 "제한"할 만한 서버 운영체제에 대한 보안적 지식을 갖고 있는 사람이 없는 것 또한 현실입니다. 조직의 보안관리자나 경영진은 서버 운영체제에 대한 지식이 부족한 경우가 태반이기 때문에 서버의 운영조직에서 "그렇게 해야한다"고 하면 "OK"하는 경우가 대부분입니다.


하지만 보안 관점에서 다수의 개발자나 운영자가 공용계정으로 직접 로그인하는 것은 매우 큰 위협요인 입니다.


사고가 발생해도 누가 언제 서버에 로그인하여 사고의 원인이 되는 작업을 수행했는지 실제 작업자를 식별할 수 없습니다. 그리고 사고를 인지하는 것은 사고의 원인이 된 행위가 발생한지 오랜 시간이 지난 뒤인 경우가 많기 때문에 이미 꽤 긴 시간이 흘러 실제 누가 로그인했는지 확인하기 어려운 경우가 대부분입니다. 특히 개인정보의 유출과 같은 사고는 더욱 그러합니다.


그럼에도 불구하고 서버에 계정이 많으면 "시스템이 느려진다", "작업이 너무 어렵다", "서비스 운영이 안된다", "계정 관리가 어렵다" 등 설득력 부족한 이유를 들어 모든 개발자나 운영자의 root  또는 oracle 계정의 직접 접속을 고집하는 경우가 많습니다.


(Windows서버는 구조적으로 더 큰 문제를 안고 있습니다. 보안이 조금이라도 중요한 서비스를 Windows 서버에 구현하는 것은 솔직히 보안 관점에서 권하고 싶지 않습니다.)


1인 1계정의 장점

Unix나 Linux 서버에서 서버 운영자, 개발자의 개인계정을 생성하여 운영하는 것은 정보보안 측면 뿐만아니라 시스템의 효율적이고 안정적인 운영에 큰 도움이 됩니다. 


먼저 서버의 보안이 강화됩니다.


서버 개발자나 운영자가 개인계정으로 접속하여 su 명령을 통해 한번 더 root 비밀번호를 입력해야 하므로 2단계의 인증을 거치게 됩니다. 또한 root 계정으로의 직접 접속을 원천적으로 차단할 수 있기 때문에 보안성은 높아집니다. 그래서 서버 운영체제에서도 기본적으로 root 계정으로의 접속을 차단하는 기능을 제공하는 것입니다. 


그리고 sudo 명령의 사용은 권장되지 않습니다. 흔히 개인계정으로 접속한 뒤 sudo - 명령으로 root 권한으로 넘어가게 하는 경우가 있는데... 세부적인 명령어 통제까지 수행하지 않으면 오히려 보안성이 낮아지는 부작용이 생깁니다.


그리고 1인 1계정을 사용하면 책임추적성을 확보할 수 있습니다. 


서버 운영체제는 각 계정으로 접속하는 시점에 누가 어느 IP에서 접속했고 언제 접속을 끊었는지에 대한 기록을 남깁니다. 그런데 모든 접속이 root, oracle 등으로 남게 되면 실제 해당 세션이 누가 접속한 것인지 확인이 불가능합니다. 하지만 1인 1계정 원칙을 지키면 실제 접속자가 누구인지를 오랜시간이 지난 뒤에도 추적할 수 있게 됩니다. 게다가 누가 언제 su 명령을 통해 root 계정으로 전환했는지 실제 사용자를 시간이 지난 뒤에도 확인할 수 있습니다.


또한 서버의 파일시스템 정리가 용이해지고 깨끗해집니다.


서버에 파일을 업로드 할 때 root 계정으로 파일을 업로드하면 업로드 된 파일들이 여기저기 흩어져 남게 됩니다. 임시 디렉토리도 root 계정으로 생성되고 삭제되지 않은채 남게 되는 경우가 많습니다. 그리고 시간이 흐르면 그 파일들이 서비스 운영에 필요한 파일인지 식별하기 어렵습니다. 하지만 1인1계정 원칙을 지키면 작업을 위해 최초로 업로드하는 파일은 개인의 홈디렉토리에 업로드됩니다. 그리고 압축을 풀고 준비과정을 거친 뒤 root 계정이나 SW 관리자 계정으로 넘어가 시스템에 적용됩니다. (물론 작업 과정은 한두과정을 더 거치게 됩니다만 그리 긴 시간이 더 걸리지는 않습니다.)

때문에 작업 후에도 개인계정의 소유자로 생성된 파일들은 서비스에 관련되지 않은 파일이기 때문에 삭제해도 서비스 운영에 문제가 없습니다. 당연히 서버는 깨끗해지는 효과를 얻을 수 있습니다.


공용계정 (root, oracle 등)의 치명적인 단점 - Super User 계정이라는 것..!!

root 계정은 Super User 계정입니다. oracle과 같은 어플리케이션 관리자 계정은 해당 어플리케이션의 Super User 계정입니다. Super User 계정은 서버 내에서는 전지전능한 계정입니다. 다른 계정으로 비밀번호 없이도 이동이 가능하고 root에서 접근을 차단해 둔 파일에도 차단을 해제하고 접근할 수 있습니다. 심지어 보안 정책으로 규정한 비밀번호 복잡성 규칙마저도 무시할 수 있는 전지전능한 계정입니다.


이렇듯 서버 운영체제와 서버에 설치된 수 많은 애플리케이션 그리고 데이터베이스 입장에서 root 계정과 oracle 등의 계정은 "전지전능"의 능력을 가진 계정입니다. 때문에 root 계정이나 데이터베이스 관리자 계정인 oracle과 같은 계정을 별다른 통제 없이 여러 사람이 무차별적으로 사용하는 것은 생선을 고양이 여러마리에게 지키도록 한 것과 같습니다. 말 잘듣는 착한 고양이가 배가 부를 때는 문제가 없지만 배가 고픈 상태가 되면 언제 생선을 먹어치워도 전혀 이상한 일이 아닙니다. root 비밀번호를 알고 직접 접속할 수 있는 사용자가 악의적 목적을 갖는 범죄자로 변신하는 것 또한 전혀 이상한 일이 아닙니다 사람이 나쁜게 아니라 사람이 나쁘게 변할 수 있도록 방치하는 것 또한 "방관"의 범죄를 저지르는 것 일 수 있습니다.


보호대책

사실 이러한 취약성과 위협에 대응할 수 있는 솔루션은 SecureOS가 유일합니다. 일부 응용단에서 키보드 입력을 가로채 명령어 통제와 행위 감사를 수행하는 솔루션이나 네트워크 수준에서 동작하는 게이트웨이 방식의 솔루션이 있지만 그 기술적 수준이 낮기 때문에 얼마든지 우회가 가능합니다. 심지어 그런 홀(hole)이 있기 때문에 도입하여 사용하고 있다는 웃지못할 이야기까지도 들리죠. (엔지니어들은 우회방법을 알기 때문에 불편함 없이 서버에 접속하여 작업할 수 있다는 이야기... -.-) 


보안그룹과 등급에 따른 계정 이동(SU) 통제 정책을 수립하고 root 계정에서도 해제할 수 없는 비밀번호 규칙 설정과 중요 파일에 대한 무결성 보장 및 명령어 실행 통제를 수행하면 됩니다. 또한 응용 수준에서의 행위감사 추적과 커널 수준에서의 행위 추적 그리고 서버 접근통제 및 파일 위변조 통제 기능 등을 통해 보안을 강화할 수 있습니다.


다른 여러 보안 솔루션을 통해 서버의 보안을 강화하려는 기업이나 기관이 많지만 SecureOS를 도입하여 사용하는 것이 서버를 운용하는 조지에서 선택할 수 있는 가장 현명한 보호대책이 아닐까 생각됩니다.

신고
2 Comments
댓글쓰기 폼
Prev 1 ... 35 36 37 38 39 40 41 42 43 ... 572 Next