금융기관의 내부시스템 접근권한을 갖고 있는 사용자들에 의한 개인정보유출사고가 빈번하게 발생하자 금융기관 내부망에 위치한 서버 접근통제를 위한 추가적인 보호 대책이 2014년에 제시됐다.
네트워크, 개인 업무용 컴퓨터의 보안을 강화하고 또 강화했지만 서버에 접근권한을 부여받은 관리자, 개발자, 외부 인력에 의한 개인정보 유출사고가 빈번하게 발생하자 서버 접속 시 강화된 보안 대책의 필요성을 느꼈기 때문이다. 항상 그렇듯 소 잃고 외양간 고치기 식의 보안 강화이긴 하지만 뒤늦게 라도 서버에 에 대한 강화된 접근통제 필요성을 인지했다는 사실 자체만으로도 의미가 있다.
아마도 “서버”에 대한 지식이 많이 부족한 정책 입안자들의 입장에선 그나마 눈에 잘 띄고 사고가 빈번한 네트워크와 데스크탑 컴퓨터의 보안을 우선시할 수 밖에 없었을 것이고 금융시스템의 개발자나 운영자 입장에선 스스로의 발목(?)을 잡는 서버에 대한 보안 이슈는 쉽게 제기하지 않을 수 밖에 없었기 때문에 정작 금융기관의 중요한 정보자산을 실질적으로 저장하고 있는 서버에 대한 접근통제는 뒷전이었던 것이 사실이다.
그렇기 때문에 금융사의 고객정보와 금융 및 거래 정보가 저장되고 유지되는 핵심 자원인 “서버”의 보안을 강화하여야 한다는 이슈는 언젠가는 터져나올 당연한 이슈였다고 할 수 있다.
금융감독원 전자금융감독규정 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항은 서버에 애플리케이션을 통한 간접적인 접근이 아닌 개발자, 시스템운영자, DBA 등 내부자가 Telnet, FTP, SSH 등의 방법을 통해 운영체제의 계정인 root, oracle, jeus 등 시스템관리자 계정 및 개인 계정으로의 접속 시 OTP, ARS, PKI 등의 추가적인 인증 수단을 마련하도록 의무화한 것이라 볼 수 있다.
이러한 조치는 외부 인력 및 내부 인력의 무분별한 서버 직접 접속을 제한하고 접속할 때 실제 접속자가 누구인지를 인증하고 식별함으로써 내부자에 의한 보안사고 발생 시 감사 추적을 용이하게 하고 사고 발생 시점에 서버에 접속한 사용자(개발자, 운영자, 외부 인력 등)가 누구인지를 확인하여 책임추적성을 확보할 수 있게 하기 위함이다.
또한 더 나아가 서버 접속 시 식별한 실제사용자(실명) 정보를 바탕으로 명령어 및 중요 데이터 파일에 대한 실사용자 접근 감사기록을 유지하여 개인정보 및 중요 정보의 유출을 탐지할 수 있게 하기 위함이다.
물론… 실사용자 기반의 파일 접근 통제를 수행함으로써 개인정보 및 데이터베이스 파일의 유출을 차단할 수도 있다.
서버 Telnet, FTP, SSH 접속 시 2차 인증 구현 방안
서버 운영체제의 계정 접속에 대한 2차 인증 구현을 위해서는 서버 운영체제의 기능만으로는 불가능하다. 이는 운영체제의 인증과정에 추가적인 인증모듈을 강제로 삽입함으로써 구현하여야 하는데 이는 운영체제에 대한 심오한 이해가 있어야 가능한 기술이다.
이러한 기술은 이미 RedCastle 등 SecureOS(시큐어 오에스) 솔루션에 오래전부터 구현되어 있다. SecureOS는 기본적으로 서버에 Telnet, FTP, SSH, rlogin 등의 접속 시 IP, MAC주소, 시간, 서버계정, 서비스 종류에 대한 조합을 통해 추가적인 접속 통제를 하도록 기능이 구현되어 있으며 이 기술은 네트워크 기반의 게이트웨이 방식 서버 접근 제어 솔루션의 기능과는 차별적이리 만큼 뛰어난 접근통제 기술이다.
RedCastle SecureOS를 예로 들면 PKI, OTP, ARS를 통한 2차 인증은 RedCastle SecureOS와 AuthCastle 이라는 2차 인증 솔루션의 연동을 통해 구현된다.
개념도를 그려본다면 다음과 같다.
사용자는 Telnet, FTP, SSH 클라이언트를 통해 평소와 다름없이 접속을 시도하게 되며 1차로 서버 운영제에 접속 시 1차적으로 운영체제의 ID와 Password를 이용한 인증을 하게 된다. 이따금씩 보안솔루션 벤더에서 제공하는 커스터마이징된 “전용 Telnet, SSH 클라이언트”를 사용하도록 하는 솔루션들이 있지만 업무의 편의와 보안성, 안정성, 성능측면에서 볼 때 범용 도구들을 사용할 수 있도록 지원하는 제품을 선택하는 것이 좋겠다.
서버 운영체제에서 1차적으로 ID와 Password 인증을 마치면 RedCastle의 설치 시 함께 설치된 PAM(Unix 및 리눅스) 혹은 CP(Windows) 모듈에서 추가적으로 OTP, 인증서, ARS 등의 인증을 수행하는 2차 인증과정을 수행하게 된다. 이 때 서버 운영체제의 접속 로그에 더해 실제 운영체제 계정으로 접속한 사용자가 누구인지 사번, 실명 등 실제 접속자의 자연인 정보를 기록할 수 있다.
게다가 전산실 내부에서 서버의 콘솔장비 혹은 네트워크 장비에 직접 노트북 등의 단말기를 접속한 뒤 서버에 접속하는 경우에도 2차 인증을 강제화할 수 있다.
만약 금융감독규정 14조 9항의 “운영체제 계정으로 서버 접속 시 2차 인증”을 이미 수행하고 있다면 몇몇 솔루션들이 지원하는 실제 접속하는 서버 앞에 게이트웨이 형태의 장비를 두고 해당 장비에 접속할 때 2차 인증을 수행하는 “무늬만 2차 인증”은 아닌지 짚어볼 필요가 있다. IT 직종의 내부 임직원들이라면 게이트웨이를 우회하거나 전산실에 직접 들어가 별도의 장비에서 서버에 직접 접속할 수 있는 취약점을 간파하고 있을 가능성이 매우 높기 때문이다.
실제로 서버의 접속로그를 조회하면 게이트웨이 장비 이외의 IP에서 접속한 흔적이 다수 발견할 수 있는 경우가 많아 보안 담당자들이 당황하는 경우를 종종 볼 수 있다.
그리고 로그인 과정에서 패스워드를 자동으로 입력해주는 경우가 많은데.. 이는 분명 비밀번호에 대한 법적인 요구사항을 심각하게 위배하고 있을 가능성이 높다는 것을 간과해서는 안된다. “패스워드는 복호화가 불가능하도록 단방향 암호화 되어야 한다”는 개인정보보호법을 위반하는 것이며 모든 서버의 ID, Password를 복호화가 가능한 형태로 하나의 DB에 저장하는 것은 오히려 위험을 키우는 상황이 될 수도 있기 때문이다.
이러한 형태의 무늬만 서버 접속 시 2차 인증은 법적으로나 기술적으로 취약점이 많아 문제가 될 가능성이 매우 높다고 볼 수 있다. 그리고 게이트웨이 접속 시 2차 인증이 과연 “운영체제 계정으로 접속 시 2차 인증”을 시행하는 것으로 인정할 수 있는가에 대한 이슈가 언젠가 또 불거질 가능성이 높기 때문이다.
어쨌든 금융기관의 경우 전자금융감독규정의 강제 규정으로 인해 서버 운영체제 계정으로 접속 시 2차 인증을 구현한 사례가 매우 많다. 하지만 아직도 일부 기관에서는 서버 앞단에 위치한 게이트웨이에서 2차 인증을 수행하고 실제 서버에 접속할 때는 ID와 비밀번호 인증만 수행하는 경우가 많다. 심지어 누군가 입사하게 되면 서버 접속을 위한 게이트웨이에 인사시스템과 연동하여 무조건 계정이 생성되고 부서 혹은 업무에 따라 접근 권한을 신청할 경우 접속할 서버의 목록을 보여주고 있어 서버에 접근하는 업무를 하지 않는 임직원이 서버 접근을 위한 게이트웨이 장비에 계정을 갖고 있는 경우가 많다.
이런 경우 게이트웨이 서버에서 취약점이 발견되고 해당 취약점을 악용한다면 비인가자에게 서버 목록이 보이고 원치않게 서버에 접속이 가능해지는 잠재적인 위험이 있다.