금융감독원 전자금융감독규정에 서버 운영체제 계정 접속 시 2차 인증 의무화 시행되다.

Posted by taeho Tae-Ho
2014.07.17 23:47 서버보안

최근 수년간 빈번하게 발생하고 있는 금융사 내부망에 위치한 서버의 고객 금융정보 유출사고가 빈발하자 금융감독원이 그에 대한 보안 대책을 제시하고 나섰다. 네트워크, 개인 업무용 컴퓨터의 보안을 강화하고 또 강화했지만 서버에 접근권한을 부여받은 관리자, 개발자, 외부 인력에 의한 개인정보 유출사고가 발생하자 이제서야 서버에 대한 보안 대책의 필요성을 느끼고 있는 모양이다.


아마도 "서버"에 대한 지식이 많이 부족한 정책 입안자들의 입장에선 그나마 쉽게 접근할 수 있는 네트워크와 데스크탑 컴퓨터의 보안을 우선시할 수 밖에 없었을 것이고 금융시스템의 개발자나 운영자 입장에선 스스로의 발목(?)을 잡는 서버에 대한 보안 이슈는 쉽게 제기하지 않을 수 밖에 없었을 것이다.


하지만 금융사의 고객정보와 금융정보가 저장되고 유지되는 핵심 요소인 "서버"의 보안을 강화하여야 한다는 이슈는 언젠가는 터져나올 당연한 이슈라고 할 수 있다.


금융감독원 전자금융감독규정 2013년 12월 개정안 내용


일단 2013년 12월에 공지된 금융감독원의 전자금융감독규정을 보면.. 제14조에 다음과 같은 내용이 추가되었다.


제14조(정보처리시스템 보호대책) 금융회사 또는 전자금융업자는 정보처리시스템의 안전한 운영을 위하여 다음 각 호를 포함한 보호대책을 수립·운용하여야 한다. <개정 2013.12.3>


-- 중략 --


  9. 정보처리시스템의 운영체제(Operating System) 계정으로 로그인(Log in)할 경우 계정 및 비밀번호 이외에 별도의 추가인증 절차를 의무적으로 시행할 것 <신설 2013.12.3>


  10. 정보처리시스템 운영체제(Operating System) 계정에 대한 사용권한, 접근 기록, 작업 내역 등에 대한 상시 모니터링체계를 수립하고, 이상 징후 발생 시 필요한 통제 조치를 즉시 시행할 것 <신설 2013.12.3>


위의 제14조 9항과 10항은 서버에 Telnet, FTP, SSH 등의 방법을 통해 운영체제의 계정인 root, oracle, jeus 등 시스템관리자 계정 및 서비스관리자 계정으로의 접속 시 OTP, ARS, PKI 등의 추가적인 인증 수단을 마련하도록 의무화한 것이라 볼 수 있다.


이러한 조치는 외부 인력 및 내부 인력의 무분별한 서버 직접 접속을 제한하고 접속할 때 실제 접속자가 누구인지를 인증하고 접속함으로써 보안사고 발생 시 감사 추적을 용이하게 하고 사고 발생 시점에 서버에 접속한 사용자(개발자, 운영자, 외부 인력 등)를 식별 함으로써 책임추적성을 확보할 수 있게 하기 위함이다.


또한 더 나아가 접속 시 식별한 실제사용자(실명) 정보를 바탕으로 명령어 및 중요 데이터 파일에 대한 실사용자 접근 감사기록을 증적함으로써 개인정보 및 중요 정보의 유출을 탐지할 수 있게 하기 위함이다. 


물론... 실사용자 기반의 파일 접근 통제를 수행함으로써 개인정보 및 데이터베이스 파일의 유출을 차단할 수도 있다.


서버 Telnet, FTP, SSH 접속 시 2차 인증 구현 방안


서버 운영체제의 계정 접속에 대한 2차 인증 구현을 위해서는 서버 운영체제의 기능만으로는 불가능하다. 이는 운영체제의 인증과정에 추가적인 인증모듈을 강제로 삽입함으로써 구현하여야 하는데 이는 운영체제에 대한 심오한 이해가 있어야 가능한 기술이다.


이러한 기술은 이미 RedCastle SecureOS에 오래전부터 구현되어 있다. RedCastle은 기본적으로 서버에 Telnet, FTP, SSH, rlogin 등의 접속 시 IP, MAC주소, 시간, 서버계정, 서비스 종류에 대한 조합을 통해 추가적인 접속 통제를 하도록 기능이 구현되어 있으며 이 기술은 네트워크 기반의 게이트웨이 방식 서버 접근 제어 솔루션의 기능과는 차별적이리 만큼 뛰어난 접근통제 기술이다.


PKI, OTP, ARS를 통한 2차 인증은 RedCastle SecureOS와 AuthCastle 이라는 2차 인증 솔루션의 연동을 통해 구현된다.

개념도를 그려본다면 다음과 같다.



사용자는 Telnet, FTP, SSH 클라이언트를 통해 평소와 다름없이 접속을 시도하게 되며 1차로 ID와 Password를 이용한 인증을 받게 된다. 이따금씩 보안솔루션 벤더에서 제공하는 커스터마이징된 "전용 Telnet, SSH 클라이언트"를 사용하도록 하는 솔루션들이 있지만 업무의 편의와 보안성, 안정성, 성능측면에서 볼 때 범용 도구들을 사용할 수 있도록 하는 제품을 선택하는 것이 좋겠다.


만약 금융감독규정 14조 9항의 "운영체제 계정으로 서버 접속 시 2차 인증"을 수행하고 있다면 다음의 포스트도 함께 볼 것을 권한다. 시행하고 있는 2차 인증이 실제로 "운영체제 계정으로 접속 시 2차 인증"인지 확인할 필요가 있기 때문이다. 몇몇 솔루션들이 지원하는 실제 접속하는 서버 앞에 게이트웨이 형태의 장비를 두고 해당 장비에 접속할 때 2차 인증을 수행하는 "무늬만 2차 인증"은 아닌지 짚어볼 필요가 있기 때문이다.


그리고 로그인 과정에서 패스워드를 자동으로 입력해주는 솔루션이 있지만 이는 분명 보안에 위배되는 심각한 문제가 있음을 간과해서는 안된다. "패스워드는 복호화가 불가능하도록 단방향 암호화 되어야 한다"는 개인정보보호법을 위반하는 것이며 모든 서버의 ID, Password를 복호화가 가능한 형태로 하나의 DB에 저장하는 것은 오히려 위험을 키우는 상황이 될 수도 있기 때문이다.


이러한 형태의 무늬만 2차 인증은 보안 감사에서 문제가 될 가능성이 매우 높다고 볼 수 있다. 그리고 게이트웨이 접속 시 2차 인증이 과연 "운영체제 계정으로 접속 시 2차 인증"을 시행하는 것으로 인정할 수 있는가에 대한 이슈는 제기되고 있다.


ID와 Password 인증을 마치면 RedCastle의 로그인 통제 모듈에 의해 PKI, OTP, ARS 인증과정을 거치게 된다. 이때 RedCastle의 로그인 통제 모듈은 AuthCastle과 통신하여 PKI, OTP, ARS 인증에 필요한 추가적인 인증 기능을 수행하게 된다.


아래에 개인의 공인인증서를 활용한 PKI 추가 인증에 대해 예전에 올린 포스트를 제시한다.


[2 factor 인증] 공인인증서/OTP/ARS를 통한 자연인 기반의 서버 접근제어 포스트 보기


2차 인증에 사용될 수 있는 수단은 OTP와 PKI인증서(공인/비공인) 그리고 ARS(전화) 인증이다. 이러한 2차 인증을 통해 APT 공격을 통해 서버에 침투하는 것을 통제할 수 있다.


신고
이 댓글을 비밀 댓글로
  1. 과거와 달리 요즘은 서버에 접속하려면 통합 접속 통제를
    거치고 개인id 패스워드로 접속해서 처리해야 하거나 otp를 받아야 하거나
    하는등 늘상 서버에 접속하는 일을 하는지라 상당히 불편해진 부분이 많습니다.
    보안을 지키는건 원래 불편한것인가 봅니다 ^^
    • 보안이 강화되면 "불편함"은 증가하죠~ 뭐라도 한가지 액션을 더 취해야 하니까요.. ^^ 하지만 생각해보면 컴퓨터 보안이든 실생활이나 직장에서든 "안전" 이라는 것을 지키기 위해서는 "불편함"이 따르게 마련이지요~ ^^