2022-01-20 16:05 (목)
[암호화 키 관리 A to Z②] 암호화 키 관리 권고 사항
상태바
[암호화 키 관리 A to Z②] 암호화 키 관리 권고 사항
  • 길민권
  • 승인 2014.08.05 16:19
이 기사를 공유합니다

KISA 권고안, 암호화 키는 별도의 분리된 장소에 보관하는 것
[박종필 세이프넷코리아 이사. 사진] 개인정보 보호에 있어 가장 보편적으로 적용되는 기술은 암호화이다. 이처럼 널리 쓰이는 암호화 기술이 제 역할을 하기 위해서는 한 가지 전제 조건이 만족되어야 한다. 바로 암호화된 데이터와 암호화 키는 물리적으로 안전하게 분리되어 있어야 한다는 것이다. 하지만 이를 제대로 실천하지 못하는 곳이 생각 외로 많다. 암호화를 했음에도 데이터 유출/침해 시도에 번번히 당하는 곳이 늘면서 최근 암호화 키 관리의 중요성이 뜨는 이유다. 연재를 통해 전사 차원의 암호화 키 관리 방안을 살펴보겠다.
 
<연재 순서>
1. 암호화 키 관리 및 공격 유형
2. 암호화 키 관리 권고 사항
3. HSM 도입의 가장 중요한 판단 기준 ‘FIPS 140-2’
4. 데이터 생성부터 폐기까지 생명주기 차원의 암호화 키 관리
5. 온 프레미스와 클라우드 간 암호화 및 키 관리 연계 전략
 
암호화 키를 안전하게 관리하는 것은 아무리 강조해도 지나치지 않다. 하지만 이를 실제 잘 적용하고 있는 곳은 많지 않다. 관리자의 PC에 보관하거나 암호화 대상 시스템 내 한 켠에 키를 저장하는 경우가 많다. 이런 관리 방식이 위험한 이유는? 결국 관리자의 ID와 비밀번호만 알아내면 키 값을 빼오는 것이 너무나도 쉽기 때문이다.
 
◇마음만 먹으면 ID와 비밀번호 얻을 수 있는 시대
보안은 막는 자와 뚫는 자 간의 싸움이다. 공격자들은 시대에 따라 실력과 쓰는 도구가 다르다. 1980년대와 1990년대까지만 해도 공격자들은 고도의 보안 지식을 갖추고 있는 실력자들이 많았다. 이들이 이용한 방법은 패스워드 유추, 코드 복제(self-replicating code), 비밀번호 크래킹(cracking), 취약점 공격(Exploiting known vulnerabilities), 백도어 사용, 세션 탈취(session hijacking), 스위퍼(sweepers) 등이었다. 이들 방법은 지금 공격 방식에 비하면 그리 복잡하지는 않다. 하지만 이를 이용하는 해커들의 지식 수준은 높았다.
 
반면에 2000년대로 접어들면서 공격자들은 보안에 대한 지식이 점점 얕아 지는 반면 공격 방식은 정교해 졌다. 그 이유는 누구나 맘만 먹으면 구할 수 있는 해킹 도구가 많아지면서 생긴 현상이다. 전문 해커가 아니라도 도구만 잘 다룰 줄 알면 패킷 스누핑, 스니퍼, DoS, 크로스 사이트 스크립팅 등 복잡한 공격을 하는 것은 이제 일도 아닌 시대다.
 
ID와 비밀번호 탈취 역시 마찬 가지다. 온라인 상에는 이메일 계정 해킹, 패스워드 해킹 등 용도 별로 쓸 수 있는 도구가 널렸다. 요즘에는 도구를 넘어 해킹 서비스도 널리 쓰이고 있다. 일례로 클라우드크래커(CloudCracker) 같은 서비스를 쓰면 SHA-512, MD5 등의 키 값도 풀어 낼 수 있다. 각종 단체나 기관 그리고 소프트웨어 업체에서 암호화 키 관리를 전용 HSM(Hardware Security Module) 장비로 하라고 권하는 이유가 괜히 있는 것이 아니다. 전용 장비 상에 넣어 놓지 않은 암호화 키는 안전을 보장할 수 없다.


▲해킹 기법의 고도화와 도구의 보편화 간 관계
 
◇KISA의 키 관리 권고 사항
한국인터넷진흥원(KISA)에서 공개한 암호 구현 가이드를 보면 키 관련 내용이 나온다. KISA의 권고안은 암호화 키는 별도의 분리된 장소에 보관하는 것이다. 가이드 책자에는 두 가지 시나리오가 나온다. 첫 번째는 블록 암호 적용 시나리오로 암호화 대상 데이터의 경우 비밀 키를 생성한 후 블록 암호화 알고리즘을 적용해 암호화 하여 저장을 한다. 그리고 비밀 키는 사용자 데이터베이스와 물리적으로 분리된 장소에 별도로 보관한다.


▲블록 암호 적용 시나리오 (출처: KISA)
 
두 번째 시나리오는 일방향 해쉬 함수를 적용하는 것이다. 비밀번호, 생체 정보 등을 소유자가 아닌 서비스 제공자가 복호화 할 수 없도록 일방향 해쉬를 적용해 저장한다. 비밀번호에만 해쉬 함수를 적용하면 보안성이 낮기 때문에 SALT 값을 비밀번호에 추가해 일방향 해쉬 함수를 적용한다. SALT 값이 비밀번호의 안전성을 높여 주는 역할을 하는데 이 값을 물리적으로 떨어진 별도의 저장소에 보관한다.


▲일방향 해쉬 함수 적용 시나리오 (출처: KISA)
 
◇ISMS의 암호화 키 관리 가이드
정보보호관리체계(ISMS) 인증을 준비 또는 받은 기업이나 기관이라면 암호화 키 관리에 대한 점검 항목이 있다는 사실을 잘 알 것이다. ISMS의 점검 항목 중 아홉 번째 내용인 암호 통제 부문에는 암호화와 함께 키 관리에 대한 설명이 포함되어 있다. 이를 옮겨 보면 다음과 같다. 별도의 안전한 장소에 소산 보관할 것 그리고 물리적으로 분리된 서버에 저장할 것을 권고하고 있음을 알 수 있다.


▲ISMS 암호화 키 관리 점검 항목
 
◇PCI DSS의 키 관리 요구 사항
글로벌 하게 통용되는 대표적인 보안 가이드라인 중 하나로 PCI DSS(Payment Card Industry Data Security Standard)를 꼽을 수 있다. PCI DSS는 카드를 통한 지불 방식을 이용하는 업계의 경우 반드시 따라야 하는 글로벌 표준이다. PCI DSS에는 방화벽 구축 및 관리, 사용자 비밀번호 관리, 신용카드 정보 관리, 백신 소프트웨어 사용, 신용카드 정보에 대한 물리적 접근 통제 등 여러 보안에 대한 가이드가 포함되어 있는데 이중 중요한 부문 중 하나로 신용카드 정보의 암호화가 언급되어 있다. 아래 표는 PCI DSS의 키 관리 요구 사항에 대한 내용으로 암호화 키에 대한 접근 제어, 키에 대한 분리 저장 방안, 키 관리 절차에 대한 내용이 포함되어 있다.


▲PCI DSS의 키 관리 요구 사항
 
◇TDE를 이용할 때도 HSM 사용이 권장
데이터베이스 암호화 방법 중 하나인 TDE(Transparent Data Encryption)을 선택할 때도 키의 별도 저장 및 관리는 필수다. 이는 오라클, 마이크로소프트 모두 동일한 가이드를 제시하고 있다. 먼저 오라클의 경우 자사 데이터베이스의 TDE를 이용해 암호화를 할 경우 두 가지 옵션을 제시한다.
하나는 월렛(Wallet) 기능이다. 데이터베이스 관리자는 Oracle Wallet Manager를 이용해 키 관리를 할 수 있다. 다른 하나는 써드파티 HSM을 이용하는 것이다. 오라클의 문서에서도 HSM이 월렛보다 훨씬 더 안전한 키 관리를 위한 대안이라고 명시되어 있다(Oracle Database Advanced Security Administrator’s Guide 78쪽). 그리고 이 가이드 문서에는 세이프넷의 HSM을 오라클 데이터베이스와 연계하는 설정 방법이 나와 있다(176쪽).
 
마이크로소프트 SQL 서버 역시 마찬가지다. 마이크로소프트는 EKM(확장 가능 키 관리) 기능을 제공한다. 마이크로소프트는 HSM과 연계를 통한 안전한 키 관리 방안을 아래와 같이 안내하고 있다.


▲마이크로소프트 SQL 서버에서 HSM 이용에 대한 설명 (출처: TechNet)
 
이상으로 암호화 키 관리에 대한 주요 보안 가이드의 내용을 살펴보았다. 다음 회에서는 HSM 도입의 가장 중요한 판단 기준이라 할 수 있는 ‘FIPS 140-2’ 인증에 대해 소개하겠다.
 
<★정보보안 대표 미디어 데일리시큐!★>
 
[글. 박종필 세이프넷코리아 이사]