개인정보보호법의 비밀번호 일방향 암호화 및 패스워드 관리 솔루션

인터넷의 사용이 일반화 되면서 전 국민이 평균적으로 수 십 개의 웹 사이트에 가입되어 있고 그 숫자 만큼의 계정과 비밀번호를 갖고 있다. 그리고 웹 서버, DB서버 등 수 십에서 수 백 대의 서버를 관리하는 IT 기업의 운영자들은 웹 사이트의 계정 이외에도 서버 운영체제에 존재하는 여러 계정들에 대한 비밀번호도 관리해야 한다. 개인 사용자들의 계정과 비밀번호와는 달리 서버 운영체제의 계정은 유출될 경우 보안 관점에서 매우 치명적인 문제가 발생할 수 있기 때문에 특별하게 관리되어야 한다.

 

1. 패스워드의 일방향 암호화에 사용되는 Hash함수

 

개인정보보호법에서는 웹 사이트에서 사용되는 비밀번호는 물론 서버의 운영체제 관리자 계정, DB 관리자 계정, 어플리케이션 관리자 계정 등 주요 시스템 관리자 계정의 비밀번호가 유출되는 최악의 상황에서도 기밀성을 유지하도록 하기 위해 "일방향 암호화"를 해야 한다고 명시하고 있다.

 

개인정보의 안전성 확보조치 기준(안전행정부고시 제2011-43호, 2011.9.30 제정)   제7조(개인정보의 암호화)①영 제21조 및 영 제30조제1항제3호에 따라 암호화하여야 하는 개인정보는 고유식별정보, 비밀번호 및 바이오정보를 말한다. ②개인정보처리자는 제1항에 따른 개인정보를 정보통신망을 통하여 송.수신하거나 보조저장매체 등을 통하여 전달하는 경우에는 이를 암호화하여야 한다. ③개인정보처리자는 비밀번호 및 바이오정보는 암호화하여 저장하여야 한다. 단 비밀번호를 저장하는 경우에는 복호화되지 아니하도록 일방향 암호화하여 저장하여야 한다. ④개인정보처리자는 인터넷 구간 및 인터넷 구간과 내부망의 중간 지점(DMZ : Demilitarized Zone)에 고유식별정보를 저장하는 경우에는 이를 암호화하여야 한다.

(개인정보의 안전성 확보 조치 기준 고시 해설서)

 

일반적으로 패스워드(비밀번호) 이외의 데이터를 암호화를 할 때는 암호화에 사용되는 키(Key)가 필요하다. 암호화를 할 때는 평문(읽을 수 있는 문서)을 암호 시스템에 키(Key)와 함께 입력하면 암호화 된 암호문이 출력된다. 그리고 반대로 암호문을 키와 함께 복호화(해독) 시스템에 입력하면 평문이 출력된다.

 

이것이 일반적인 암호시스템의 암호화와 복호화다.

 

그런데 사용자 계정의 비밀번호 암호화에 사용되는 일방향 암호시스템은 복호화(해독) 시스템이 존재하지 않다. 이론적으로 복호화가 불가능한 암호 알고리즘을 사용하는 암호화 시스템이다. 따라서 일방향 암호화 시스템에 의해 암호화된 비밀번호가 유출되어도 안전이 보장된다. 이러한 암호시스템에서 사용되는 암호화 알고리즘을 해쉬(Hash)함수라고 부르며 MD-5, SHA-1, SHA-256, SHA-512 등 여러 알고리즘이 공개되어 있다.

 

비밀번호의 암호화에 사용되는 알고리즘인 해쉬함수에 대해 위키피디아에서는 다음과 같이 정의하고 있다.

 

해시 함수(hash function)는 임의의 길이의 데이터를 고정된 길이의 데이터로 매핑하는 알고리즘이다. 해시 함수에 의해 얻어지는 값은 해시 값, 해시 코드, 체크섬 또는 해시 등으로 불린다. 해시 함수는 결정론적으로 작동해야 하며, 두 해시 값이 다르다면 그 해시 값에 대한 원래 데이터도 달라야 한다. (역은 성립하지 않는다) 해시 함수의 질은 입력 영역에서의 해시 충돌 확률로 결정되는데, 해시 충돌의 확률이 높을 수록 서로 다른 데이터를 구별하기 어려워지고 검색하는 비용이 증가하게 된다.   해쉬함수 중에는 암호학적 해쉬함수(Cryptographic Hash Function)와 비암호학적 해쉬함수로 구분되곤 한다.   암호학적 해쉬함수의 종류로는 MD5, SHA 계열 해쉬함수가 있으며 비암호학적 해쉬함수로는 CRC32 등이 있다.   암호학적 해쉬함수는 역상(pre-image), 제2역상(2nd preimage), 충돌쌍(collision)에 대하여 안전상을 가져야 하며 인증에 이용된다. 암호학적 해쉬함수는 임의의 길이를 입력 받기는 하지만 MD Strength Padding할 때 길이정보가 입력되므로 최대 길이에 대한 제한이 있다. 예를 들어 패딩 시 하위 8비트에 길이 정보가 입력 되는 경우에는 해쉬가능한 최대 길이는 0xff가 되어 255바이트가 된다.(실제 길이정보는 패딩방식에 따라 다를 수 있다)

 

이 해쉬함수를 사용하는 대표적인 암호시스템은 Unix/Linux 운영체제의 계정에 대한 비밀번호를 예로 들 수 있다. Unix/Linux 시스템에는 root, oracle 등 다양한 계정들이 존재하게 되는데, 이 계정들의 비밀번호를 Hash 함수를 써서 생성하고 관리한다.

 

예를 들어, 다음과 같이 oracle 계정(운영체제 계정임)의 비밀번호를 oracle1로 변경한다.

 

$ id uid=105(oracle) gid=10(staff) $ $ passwd Enter existing login password:                      <--원래 비밀번호 입력 New Password:                                    <--변경할 비밀번호인 oracle1! Re-enter new Password:                            <--변경할 비밀번호 한번더 입력 oracle1! Passwd: password successfully changed for oracle    <--변경되었음. $

 

위와 같이 비밀번호를 변경하면 oracle1!라는 비밀번호가 hash 함수에 의해 암호화 되어 /etc/shadow 파일에 다음과 같이 저장된다.

 

rctest3:$5 $sr.Ua47p$C7JoY7vCoZW6BxcQFuZYA7T1THWn06U0KHvimHe.a/:16363::::::8016 Oracle:$5 $LWKPAHLI$/276CYHrCCxJ9fGMhF6k1HvdKBDem23.HLJ9LXu5:16408::::::

 

위에 굵게 표시된 부분이 oracle1!라는 비밀번호가 hash함수에 의해 암호화된 암호문이다. 암호화 된 문장만으로는 암호화되기 이전의 평문을 알아내는 것은 현재의 암호학으로는 불가능하다. 그래서 "단방향" 암호화라 부르는 것이다. 때문에 암호화된 문자열이 유출되어도 비밀번호인 oracle1!의 비밀이 지켜지는 것이다.(하지만 다른 서버(운영체체 버전이 동일한)의 shadow 파일에 동일 암호문이 있다면 그 계정의 비밀번호도 oracle1!라는 맹점이 존재하긴 한다.)

 

그래서 개인정보보호법에서는 모든 비밀번호는 "단방향 암호화" 하도록 의무화하도록 명시되어 있고 실제로는 서버마다 비밀번호를 다르게 설정하라고 권고하고 있는 것이다. 비밀번호가 암호화된 데이터베이스나 서버의 shadow 파일이 유출되더라도 비밀번호를 복호화하지 못하도록 하기 위해서다.

 

그런데 많은 보안솔루션들이 이를 위반하고 있다. 대표적인 제품들이 SAC(System Access Control)라 부르는 제품들이다. 그 중에서도 서버에 로그인을 자동으로 해주는 기능을 사용할 경우 SAC의 관리서버에 서버의 root, administrator, oracle, jeus 등 매우 치명적인 문제를 일으킬 수 있는 계정의 비밀번호를 복호화가 가능한 SEED 등의 암호기법으로 저장하고 있다.

 

물론 키를 알아야만 복호화가 가능하겠지만 그 키 조차도 서버에 저장되어 있기 때문에 취약성과 위험은 존재한다.

 

2. 비밀번호 관리 솔루션

 

SAC의 자동 로그인 기능을 사용하는 이유는 비밀번호 관리의 어려움을 극복하기 위해서이다. 비밀번호를 관리해 주는 솔루션은 세가지 정도가 있다.

 

먼저, 계정관리(Identity Management)솔루션이다. 전문적인 계정관리 솔루션으로서 계정의 비밀번호를 주기적으로 자동으로 변경해 주는 기능을 갖고 있다. 다만 변경된 비밀번호는 별도로 DB에 저장하지 않는 것이 원칙이다. 그래야만 한다.

 

그리고 두 번째는 SAC 솔루션이다. 자동으로 계정의 비밀번호를 변경하고 비밀번호를 복호화 가능하도록 SAC 관리서버의 DB에 저장한 뒤 사용자들도 서버에 접속할 때 비밀번호를 복호화하여 자동으로 입력해 준다. 서버 관리자들은 비밀번호를 직접 변경하지 않아도 되고 기억하지 않아도 되기 때문에 매우 편리하겠지만 분명히 "위법"이다.

 

그리고, 세번째는 랜덤 비밀번호 관리 솔루션이다. 외산으로 TPAM이라는 솔루션이 있고, 국산으로는 최근 개발된 시큐어가드테크놀로지의 APPM이라는 제품이 있다. 이 제품들은 평소에는 계정의 비밀번호를 랜덤하게 생성하여 접속을 차단하고 사용자의 특정 계정의 사용을 신청하면 랜덤하게 비밀번호를 다시 변경한 뒤 변경된 비밀번호를 신청자에게 전송하여 접속할 수 있도록 해준다. 그리고 사용 신청 시간이 지나면 다시 랜덤 비밀번호를 생성하여 변경하는 방식으로 운영된다.

 

하지만 두번째와 세번째 솔루션 모두 관리 솔루션 내의 DB에 복호화 가능한 형태로 비밀번호가 저장된다는 점에서 개인정보보호법의 위반 소지가 있다. 다만 세번째 솔루션의 경우 두번째 솔루션들 처럼 일반 사용자가 접속하지 않는 관리서버의 DB 혹은 별도의 비교적 안전한 보안USB 등에 저장한다라는 점에서 물리적인 접근통제와 보안S/W의 설치 등을 통해 보안을 강화하면 SAC 솔루션보다는 안전할 것으로 보인다.

 

일부 업체에서 패스워드를 결코 저장하지 않는다고 우기는 경우도 있는데 그것은 기술적으로 불가능하다.

 

3. 2차 인증의 필요성

 

비밀번호의 관리 문제로 인해 여러 비밀번호 관리 솔루션 들이 출시 되었지만 비밀번호가 복호화 가능한 암호화 기법으로 DB에 저장된다는 점에서 컴플라이언스 측면의 문제가 있다. 단지 비밀번호 관리의 편의성만을 강조한 솔루션들이기 때문이다.

 

때문에 2차 인증이 추가적으로 적용되어야 한다. 그래서 2013년 12월 개정된 금융감독 규정에 서버의 계정으로 접속 시 2차 인증 의무화가 명시 되어 있다. 하지만 법의 모호함은 SAC 서버에 접속할 때 2차 인증을 서버 계정의 접속 시 2차 인증으로 인정할 것인가라는 논란 거리를 만들고 있다. 하지만 분명히 "서버 계정의 접속"에 2차 인증 적용이기 때문에 SAC 접속할 때 2차 인증은 인정받지 못할 가능성이 높다.