[ISACA저널-특별기고] 서버 운영체제 접속에 대한 이중 인증 시스템 구축 사례 분석

책장을 정리하다 2015년 ISACA 저널에 기고했던 글이 실린 책을 발견했다. 무언가 글을 써서 어딘가 활자로 인쇄되어 나오는 것이 어떤 느낌인지를 알려주었던 소중한 경험이었다. 당시 올렸던 글의 원문을 이제 3년 넘게 지난 시점에 블로그에 올려 본다.

특별기고

서버 운영체제 접속에 대한 이중 인증 시스템 구축 사례 분석

인증이란?

인증이라 함은 다중 사용자 시스템 또는 망운용 시스템에서 접속자의 로그인 정보를 확인하는 보안 절차를 말한다. 그 외에 전송된 메시지의 무결성과 송신자를 검증하는 과정도 인증에 해당된다. 

서버 또는 애플리케이션에서 사용자들에게 사용권(접근권한)을 부여하기 위해 접속자의 신분을 검증하는 과정을 로그인이라 하며 이 로그인 과정에 “인증” 과정이 필요함은 두말할 나위가 없다. 

사용자는 로그인에 성공하기 위해서 “식별(Identification)”과 “인증(Authentication)”의 두 단계를 통과해야 한다. “식별”은 로그인 하려는 사용자가 누구(who)인지 계정정보(ID)를 입력 받아 시스템에 접속 권한을 가진 사용자인가를 검증하는 단계이고 식별을 완료한 뒤 현재 접속하려는 사용자가 입력한 계정의 소유자가 맞는가를 비밀번호와 같은 검증 수단을 이용해 확인하는 것이 “인증” 이다. 이러한 “식별”과 “인증”과정은 접속자가볼 때 동시에 실행되는 것으로 보여야만 하며 통상적으로 “식별”과 “인증”을 모두 “인증”이라고 표현한다.

지식 기반 인증(ID/ Password)의 취약성과 새로운 인증 기술

일반적으로 대부분의 운영체제에서 기본적으로 적용되어 있는 인증방식은 보안에 가장 취약한 ID/ Password에 의존하는 지식 기반 인증이다. ID/ Password를 사용하는 인증방식은 사람의 기억력에 의존하는 짧은 문자열을 검증하는 방식이기 때문에 Password Guessing(패스워드 추측), Brute-Force Attack(무작위 대입), Password Dictionary(패스워드 사전)등의 잘 알려진 패스워드 공격에 취약하며 개인 정보 유출, 패스워드를 기록한 파일의 유출 등에 의해 서도 쉽게 공격을 받고 뚫리기도 한다. 

때문에 ID/Password 이외의 인증 수단에 대한 지속적인 연구가 이루어졌으며 [그림 1]과 같이 다양한 인증 기법이 개발되어 적용되고 있다.

이중 인증 (또는 2차 인증)

이중 인증이라 함은 인증의 보안성 강화를 위해 [그림 1]에 설명되어 있는 4가지 타입의 인증 기술 중 2가지 이상을 로그인에 인증 수단으로 적용하는 것을 의미한 다. 예를 들어 비밀번호를 사용하는 지식기반 인증을 사용하는 인증과정에 추가적으로 OTP 인증을 적용하면 이중 인증을 구현한 것이 된다. 

최근에 금융 시스템에 적용되어 널리 사용되기 시작한 QR코드나 문자 메시지를 이용한 mOTP, 그리고 ARS 또한 이중 인증을 구현하기 위한 수단으로 사용 될 수 있다. 

이중 인증 시스템을 구현함에 있어 중요한 포인트는 사용자가 접속을 시도할 때 인증 로직의 구현상 하나의 스텝에서 두 가지의 인증이 동시에 이루어져야 한다는 점이다. 만약 두 가지의 인증 단계가 각각 분리된 시스템에서 수행되거나 이중 인증이 이루어지는 시간 차가 클 경우 취약점이 발생할 수 있기 때문이다.

서버의 운영체제 계정에 대한 이중 인증 필요성

2011년 4월 발생한 N은행의 APT 공격에 이은 200여 대의 서버에 대한 DOS 공격(서버의 파일시스템 파괴), 2013년 발생한 신용카드 3사의 서버 침투에 이은 개인 정보 유출 사고는 대표적인 “전산 시스템 운영 및 유지 보수 인력에 대한 내부통제”가 미흡해서 발생한 사고라 할 수 있다. 

그리고 사고 발생의 주요 원인으로 “서버의 접속(로그 인)에 대한 통제 미흡”이 지목 받은 바 있다. 

금융감독원은 위의 두 사례를 비롯해 서버 접속에 대한 내부 통제 미흡으로 지속적인 보안사고가 발생하자 금융전산망의 서버를 APT 공격과 내부자에 의한 고의 또는 실수로 발생되는 보안 사고로부터 예방하기 위해 다음과 같이 전자금융감독규정을 개정하여 고시하였다.

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

<중략>

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

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

출처 : 국가법령정보센터(http://www.law.go.kr)

새롭게 추가된 14조 9항에서는 서버의 운영체제 계정으로 로그인 할 때 ID, 비밀번호 이외의 추가 인증 시스템을 구축하라고 의무화하고 있다. 이는 기업 내부의 서버 관리자와 엔지니어들이 Telnet, SSH, FTP 등의 도구를 사용해 서버에 로그인할 때 ID, 패스워드 이외에 추가적으로 OTP, PKI, ARS 등의 실사용자 인증을 한번 더 거쳐야 한다는 것을 의미한다. 그래야만 APT 공격에 의해 해커에게 장악된 PC나 서버를 통해 다른 개인정보나 금융정보가 저장되어 있는 서버까지 해커가 침투하는 것을 차단할 수 있기 때문이다. 

이어진 10항에서는 Telnet, FTP, SSH 등의 방법을 통해 서버에 접속한 운영자와 엔지니어가 작업하는 내용을 실시간으로 모니터링 해야 하며 적법하지 않은 명령어 실행 및 파일에 대한 읽기/쓰기/수정/삭제 등을 통제하라고 하고 있다. 

이 시행규칙은 금융권에서 발생하는 개인정보 유출 사고가 서버에 운영체제 계정으로 로그인한 운영자 또는 개발자가 임의로 데이터베이스를 조회하는 명령어를 실행하고 그 결과로 출력되는 정보를 파일로 저장(생성)하여 FTP를 통해 외부로 반출했던 과정을 염두에 둔 것으로 보인다. 

그렇다면 운영체제 계정으로 서버에 접속할 때 어떤 방식으로 이중 인증을 구현할 수 있는지 그 사례와 기 술적인 방법론에 대해 살펴보자.

운영체제 계정의 이중 인증 구축 사례

서버 운영체제 계정의 로그인 시 이중 인증을 구현하 는 방식은 크게 3가지 정도로 분류할 수 있다.

1. 접속 기기에서의 추가 인증 방식

이 방식은 [그림 2]와 같이 서버에 접속할 PC에 로그인 할 때 혹은 PC에 로그인 한 뒤 서버에 접속하는 시점에 먼저 추가인증을 받는 방식이다.

이 방식은 서버의 형상을 변경하지 않고 가장 손쉽게 이중 인증을 구현할 수 있도록 해준다. 하지만 이 방식을 서버 접속에 대한 이중 인증이라고 보기는 어렵다. 접속자의 추가 인증 시점과 서버의 로그인 시점이 일치하지도 않을 뿐만 아니라 실제 서버 운영체제의 계정으로 서버에 접속할 때 수행되는 인증 과정에 별도의 인증과정이 추가되는 것도 아니기 때문이다. 또한 서버의 접속 이력 로그와 추가 인증 로그에 실 사용자의 식별정보가 전혀 기록되지 않기 때문에 서버 접속 이력과 추가 인증 감사 로그를 매칭하여 서버에 로그 인한 실사용자를 특정하는 것도 불가능하다.

2. 인증 게이트웨이 방식

두 번째 방식은 현재 가장 많은 레퍼런스를 확보하고 있는 인증 게이트웨이 방식이다.

[그림 3]에서와 같이 인증 게이트웨이 방식은 흔히 SAC(System Access Control)라는 솔루션들이 채택하는 방식이다. 이 방식은 서버에 로그인 하려는 사용자가 먼저 인증 게이트웨이에 로그인 하고 해당 사용자가 로그인 할 수 있는 서버의 목록을 보여준 뒤 접속하려는 서버를 선택하여 서버에 실제 로그인하는 방식이다. 이 방식은 게이트웨이 서버에 접속하는 대신 PC나 노트북에 에이전트를 설치하고 에이전트가 대신 인증 게이트웨이에 접속하는 형태로 변형되기도 한다. 이 방식에서 이중 인증은 게이트웨이에 로그인 할 때 이루어지는데 앞에서 설명한 것과 마찬가지로 실제 서버에 로그인할 때는 ID/Password 인증만 수행하게 된다. 심지어 인증 게이트웨이에 로그인하면 서버 로그인 시에는 ID/Password를 묻지도 따지지도 않고 자동으로 ID와 Password를 입력해주는 보안 취약점을 만들기도 한다. 다만 인증 게이트웨이가 양쪽 세션에 대한 정보를 모두 갖고 매칭시켜 주기 때문에 서버에 접속한 실제 사용자가 누구인지를 식별할 수는 있다. 

그리고 이 방식의 가장 큰 문제점은 인증 게이트웨이를 거치지 않고 우회하여 서버에 로그인하는 행위를 차단하기 어렵다는 점이다. 서버마다 “TCP Wrapper”와 같은 오픈소스 도구를 설치하기도 하지만 관리자 권한에서 너무 쉽게 해제가 가능하기 때문에 사실 큰 의미가 없다. 장시간 운영하다 보면 여기 저기 우회하여 서버에 로그인 할 수 있는 홀이 발생할 수 밖에 없다.

3. 운영체제 PAM 인증 추가 방식

세 번째 방식은 [그림 4]와 같이 서버 운영체제가 지원하는 PAM이라 불리는 인증모듈에 추가 인증 모듈을 추가하는 방식이다. 

Unix 와 Linux 운영체제는 기본적으로 PAM(Pluggable Authentication Module)이라고 하는 인증 모듈을 사용자가 개발하여 추가할 수 있는 기능을 지원한다. (Windows는 GINA / CP 모듈을 지원함) 즉 ID와 Password 인증 후 추가된 인증 모듈을 운영 체제가 호출해주는 방식이다. 이 기술은 수 십 년의 역사를 가진 Unix/Linux/Windows 함께 발전하고 안정화되었기 때문에 가장 안전하고 확실한 기술이라고 할 수 있다. 다만 추가 인증을 구현하고자 하는 모든 서버에 추가 PAM 모듈을 설치해야 하는 부담이 있다. 모든 서버의 형상을 변경해야 하는 부담이 있지만 이 방식은 서버 접속에 대한 우회 접속을 완벽하게 차단 할 수 있기 때문에 보안 관점에서 가장 권고할 만한 기술이다. 그리고 서버의 감사로그에 접속한 실제 사용자의 자연인 정보(이름, 사번 등)를 기록할 수 있으며 보안운영체제인 SecureOS 솔루션과 연계할 경우 자연인 기반의 위협 명령어 실행 통제까지도 구현이 가능하기 때문에 보안성과 확장성 측면에서 가장 우월한 위치에 있다고 할 수 있다.

장단점 및 결론

기업 내부 인력 혹은 외주 인력이 서버에 로그인 하여 어떤 행위를 하든 통제하지 못하는 현실을 감안하면 이중 인증 시스템을 구축하여 얻을 수 있는 가장 큰 장점은 서버에 기록되는 로그인 감사 로그를 보고 실제 접속한 사람이 “누구(who)”인지를 특정할 수 있고 그 사람이 “작업한 내용”을 명확하게 재연할 수 있다는 것이다. 이는 서버의 보안수준을 획기적으로 높여주는 결과를 얻을 수 있다. 사실 현재까지도 “서버”는 보안의 관심 대상에서 다소 벗어나 있는 것이 현실이다. 

서버라는 IT자원이 서비스에 핵심적인 자원이고 장애가 발생할 경우 매우 치명적인 피해를 유발할 수 있기 때문에 보안보다는 안정성과 가용성에 초점이 맞춰져 있다. 즉 “해킹이나 정보유출의 가능성이 있더라도 서비스가 우선”이라는 무언의 공감대를 깨지 못하고 있는 것이다. 하지만 해킹이나 내부 통제 취약점이 공격을 받아 서버에 침입이 발생하면 돌이킬 수 없는 치명적인 손실이 발생할 수 있다는 것을 최근 몇 차례의 보안 사고에서 경험할 수 있었다. 따라서 내부자 권한의 탈취를 통한 서버운영체제 계정으로의 불법적 접속과 접속 후 서버 내에서의 위협행위에 대한 보호대책으로서 운영 체제 접속에 대한 이중 인증 구현 및 실사용자 식별 시스템을 구축할 것을 신중히 고려하여야 한다.