2차 인증 및 워크플로 기반 명령어 통제 시스템

Posted by taeho Tae-Ho
2015.05.15 15:23 서버보안

명령어 실행 및 파일 접근 통제

정보보안이라고 하면 흔히 악성코드나 모의해킹 그리고 취약성 분석 등을 떠올리기 마련이지만..사실상 해커들이 그러한 공격기법들을 통해 얻으려 하는 것은 매우 단순하다. 


바로 "정보"다.


그리고 해커들이 원하는 정보는 99%가 "파일" 혹은 "데이터베이스"에 저장되어 있기 마련이다. 그렇다면 이 "정보"를 획득하기 위해 사용되는 "명령어" 또는 정보가 담겨있는 "파일"에 대한 접근(실행/읽기)을 완벽하게 통제하면 모든 것은 해결된다. 해커들은 "정보"를 획득하는데 사용되는 "파일"이나 "명령어"를 실행할 권한을 얻기 위해 그 생쑈~를 하는 것이다.


벌써 많은 사람들의 기억에서 잊혀져가고 있는 농협의 200대가 넘는 서버 해킹사고와 다수의 카드사에서 발생한 엄청난 양의 금융정보 유출 사고가 대표적인 서버 보안 사고다. 그리고 그 두 사고의 핵심 이슈는 "내부자에 의한 명령어 실행 통제"와 "데이터 파일 접근 통제"다.


하지만 그러한 사고가 발생한지 수 년이 지났지만 아직도 우리나라의 정보보호 수준은 "네트워크에서의 접근통제"와 같이 정보에 접근하는 길목을 지키는 네트워크 보안과 PC를 장악하기 위해 전파되는 악성코드 분석에 포커스가 맞춰져 있다. 그나마 변화한 것은 금융감독원의 IT금융감독규정에 "운영체제 계정으로 접속 시 2차 인증 의무화" 와 같이 이제 서버 운영체제에 대한 보안에 관심을 갖는 정도다. 그리고 그 조차도 아직 제대로 구현되지 않은 금융기관이 태반인 것이 현실이다.


그리고 더 나아가 서버 내 운영체제 및 데이터베이스 그리고 애플리케이션의 중요한(위험하다고 표현할 수 있는) "명령어"의 실행에 대한 통제는 꿈도 못꾸고 있는 것이 현실이다. 하지만 보안사고가 발생할 경우 최종적으로 정보유출 및 피해를 발생시키는 취약점은 바로 "서버 내의 명령어와 파일"의 존재다.


그래서 서버 내의 명령어와 파일에 대한 접근 통제는 보안의 최후 방어선 이라고 할 수 있다.


서버 로그인 시 이중 인증(2차 인증)

일부 금융기관과 공공기관은 서버에 운영체제의 계정으로 접속할 때 2차 인증을 구현하고 있다. 아래 화면처럼 운영체제의 ID와 패스워드 인증을 완료하면 2차 인증을 위한 접속자의 사용자 정보와 OTP 번호를 입력하는 것과 같이 2차 인증을 수행한다.


OTP를 통한 2차 인증(이중인증)OTP를 통한 2차 인증(이중인증)


하지만 대부분의 2차 인증 솔루션들은 여기까지가 한계다. 사실 Unix(HPUX, Solaris, AIX)와 Linux 그리고 Windows 운영체제 수준에서 2차 인증을 지원해주는 솔루션은 몇개 되지 않는다. 대부분은 서버팜의 앞단에 게이트웨이를 두고 게이트웨이에 접속할 때 2차 인증을 해준 뒤 실제 서버에 로그인할 때는 2차 인증을 해주지 못하는 솔루션이 태반이다. 당연히 우회 접속의 길이 열려 있어 보안에 취약할 수 밖에 없다.


그리고 대부분의 2차 인증 솔루션은 단순히 인가된 OTP 기기를 사용하면 실사용자가 누구든 관계 없이 OTP기기와 OTP번호만 확인하고 서버에 접속을 허가한다. 하지만 OTP기기를 빌려주거나 분실하였을 때 다른 사용자의 OTP 기기를 사용지 못하도록 통제할 필요가 있다.


2차 인증 기반 명령어 통제

그렇다면 2차 인증을 받고 서버에 접속한 사용자는 신뢰할 수 있는가? 농협사태와 카드사 사고는 "단순한 2차 인증 만으로는 부족하다"는 것을 시사한다. 서버에 접속할 권한을 부여받은 사용자라 할지라도 서버에 접속한 뒤 특정 명령어를 사용하기 위해서는 추가적인 "허가" 절차가 구현되어야 한다.


명령어 사용에 대한 추가적인 "허가" 절차가 실시간이든 아니면 사전에 "작업 신청"을 통해 사용할 명령어에 대한 사용 신청을 하고 "결재(승인)"을 받아야하든 어떤 방식으로든 구현되어야 하는 것이다.


최종적으로 2차 인증 기반 명령어 통제 시스템은 다음과 같이 구현될 수 있다.


2차 인증(실사용자 기반) 명령어 통제 시스템2차 인증(실사용자 기반) 명령어 통제 시스템



그리고 위의 2차 인증 기반 명령어 통제 시스템은 다음과 같은 절차에 의해 통제가 이루어진다. 당연히 작업 신청에 의해 사용되어야 하는 명령어나 파일은 서버보안SW에 의해 실행이나 접근이 통제되고 있어 운영자나 개발자 그리고 외부 엔지니어가 서버에 접속해도 실행이나 수정/삭제가 불가능한 상태다.

  1. 작업자의 명령어 사용 신청 (작업 신청)
  2. 승인자의 작업 승인
  3. 작업 시작 시간에 명령어 통제 정책 스케줄링을 통한 권한 부여
  4. 작업 시작 시간에 작업자의 2차 인증을 통한 서버 접속
  5. 2차 인증 수행
  6. 명령어 사용 및 파일 접근(생성/수정/삭제 등)
  7. 작업 종료 시간에 권한 회수


REDBC의 AuthCastle과 RedCastle

레드비씨의 서버보안 솔루션은 명령어 사용과 중요 파일들에 대한 접근을 통제하는 현존하는 가장 강력한 보안 솔루션이다. 서버 내의 자원은 특성상 네트워크 수준에서는 통제 불가능하다. 클라이언트의 키보드 입력 가로채기, 패킷 스니핑의 방법으로는 너무도 다양한 파일이나 명령어에 대한 접근 기법을 모두 통제할 수 없다. 
오로지 운영체제의 커널에서 동작하는 참조모니터 만이 가장 확실한 통제 수단을 제공해 준다. 
레드비씨는 2차 인증 솔루션인 AuthCastle과 서버내의 자원에 대한 현존하는 가장 완벽한 접근통제를 가능하게 해주는 RedCastle을 통해 단순한 명령어 및 파일 접근 통제는 물론 2차 인증과 연동한 실사용자 기반의 명령어 통제 및 파일 접근통제를 지원하며 워크플로(결재 절차) 지원을 통해 서버에서의 작업관리와 작업 승인에 기반한 명령어 실행 권한 자동 부여 및 권한 회수를 지원하는 서버보안 솔루션을 제공하는 국내 유일의 보안 솔루션 기업이다.


신고
이 댓글을 비밀 댓글로