금번 포스팅에서는 '개인정보 암호화' 에 중점을 두고 여러 보안담당자 혹은 사용자들이 궁금해할 만한 정보를 Q & A 형식으로 정리하였다.
6. 암호화를 규정하고 있는 법제도는 무엇이 있나요?
7. 주민번호를 저장하면 무조건 암호화 해야하나요?
8. DB에 저장된 주민등록번호를 일부분만 암호화해서 저장해도 되나요?
9. DB에 외국인 등록번호와 주민등록번호를 저장하고 있습니다. 둘 다 전체 암호화해서 저장해야 하나요?
10. 개인정보처리시스템을 위탁하거나, ASP(Application Service Provider)를 이용하는 경우 암호 수행을 위탁기관에서 해야하나요? 아니면 수탁기관에서 해야하나요?
7. 주민번호를 저장하면 무조건 암호화 해야하나요?
8. DB에 저장된 주민등록번호를 일부분만 암호화해서 저장해도 되나요?
9. DB에 외국인 등록번호와 주민등록번호를 저장하고 있습니다. 둘 다 전체 암호화해서 저장해야 하나요?
10. 개인정보처리시스템을 위탁하거나, ASP(Application Service Provider)를 이용하는 경우 암호 수행을 위탁기관에서 해야하나요? 아니면 수탁기관에서 해야하나요?
1-1. 안전한 암호 알고리즘
- 개인정보의 안전성 확보조치 기준 제7조제6항의 ‘안전한 암호알고리즘 (이하 ‘암호알고리즘’이라 한다) 이란 국내의 전문기관에서 권고하는 알고리즘을 의미한다.
- 암호 알고리즘 등은 2012년 10월 기준으로 작성됨에 따라 국내외 암호전문기관의 최신 정보를 반드시 확인하도록 한다.
- 공공기관은 “붙임 1] 국가정보원(IT보안인증사무국) 검증대상 암호알고리즘 목록” 을 참고
- 단순히 개인정보를 암호화 한다고 하면 DB에 있는 혹은 업무담당자 PC에 있는 고객의 패스워드 및 주민번호를 암호화 한다는 것에 국한하여 생각할 수 있다.
- 하지만 아래와 같이 ‘개인정보 암호화’ 에는 아래와 같이 [전송시 / 저장시] 에 따라 많은 분류로 구분된다.
2-1. 전송시 암호화
- 웹서버와 클라이언트 간 암호화
- SSL 방식
- 응용프로그램 방식
- 개인정보처리시스템 간 암호화
- IPSec VPN 방식
- SSL VPN 방식
- SSH VPN 방식
- 개인정보취급자 간 암호화
- 이메일 암호화 방식
- 이메일 첨부문서 암호화 방식
2-2. 저장시 암호화
- 개인정보처리시스템 암호화
- 응용프로그램 자체 암호화 방식
- DB 서버 암호화 방식
- DBMS 자체 암호화 방식
- DBMS 암호화 기능 호출 방식
- 운영체제 암호화 방식
- 업무용 컴퓨터 암호화
- 문서 도구 자체 암호화 방식
- 암호 유틸리티를 이용한 암호화 방식
- DRM 방식
- 디스크 암호화 방식
- 정보통신망 이용촉진 및 정보보호 등에 관한 법률 (이하 ‘정보통신망법’), 개인정보보호법 등에서는 인터넷을 통해 유통되는 정보의 보호를 위해 암호기술을 구현하도록 규정하고 있으며, 개인정보의 종류와 적용할 수 있는 암호기술은 다음과 같다.
3-2. 암호화가 필요한 정보의 종류
- 개인정보 등이 분실 / 도난 / 유출 또는 훼손되지 아니하도록 암호화가 필요한 정보는 다음과 같이 크게 두 가지로 분류할 수 있다.
- 비밀번호
- 바이오정보, 주민등록번호, 신용카드번호, 계좌번호, 여권번호, 운전면허번호, 외국인등록번호
** 이러한 정보들은 데이터베이스에 저장하는 경우는 물론, 정보통신망을 통해 송/수신되는경우에도 반드시 암호화되어야 한다.
3-3. 정보 저장 시 적용 가능한 암호기술
- 3.1에서 도출한 정보들의 종류에 따라, 암호화된 정보를 다시 복호화 할 수 없어야 하는 정보들은 해쉬함수, 복호화 할 수 있어야 하는 정보들은 블록 암호 알고리즘을 사용하여 암호화 하여야 한다.
2) 블록함수
3-3. 정보 송 / 수신 시 적용 가능 암호기술
- 3.1 에서 도출한 정보들을 정보통신망을 통해 송 / 수신 하는 경우 SSL / TLS 등 통신 암호기술을 사용해야 한다.
- 웹사이트 사용자의 로그인 수단으로 비밀번호를 사용하는 경우, 비밀번호 생성 / 변경 이용 등 비밀번호 생명 주기에 따라 비밀번호를 안전하게 관리해야 한다.
4-1. 비밀번호 생성단계
- 안전한 비밀번호는 제 3자가 쉽게 추측할 수 없으며, 시스템에 저장되어 있는 사용자 정보 또는 인터넷을 통해 전송되는 정보를 해킹하여 알아낼 수 없거나, 알아낸다 하더라도 많은 시간이 요구되는 비밀번호를 말한다. 업체는 자사의 서비스에 접근하기 위해 사용자가 비밀번호를 생성하는 경우, 안전한 비밀번호를 사용하도록 유도하여야 한다.
- 안전한 비밀번호의 문자구성 및 길이 조건은 다음과 같이 사용할 것을 권고한다.
4-2. 비밀번호 변경단계
- 업체는 모든 사용자에게 주기적으로 비밀번호를 변경하도록 유도하여 비밀번호의 노출 위협을 최소화하여야 한다. 이를 위해 업체는 반기 혹은 분기 동안 변경되지 않은 비밀번호 사용자가 로그인 한 경우, 비밀번호를 변경할 수 있는 화면을 보여주어야 한다. 일반적으로 사용자 비밀번호 변경 주기는 3개월에서 6개월 이하로 설정해야 한다.
- 사용자가 비밀번호 변경을 필요로 하거나 요청하였을 때 언제든지 비밀번호를 변경할 수 있는 기능을 제공해야 한다. 또는 비밀번호 변경 시, 이전에 사용하지 않은 새로운 비밀번호를 사용하도록 유도해야 하며 변경된 비밀번호는 이전 비밀번호와 연관성이 없어야 한다.
4-3. 비밀번호 이용 단계
- 업체는 회원으로 가입된 사용자의 비밀번호를 해쉬함수를 적용하여 저장하여야 한다. 또한 오직 인가된 관리자만이 사용자의 비밀번호가 저장된 시스템에 접근 할 수 있어야하며, 해당 시스템은 외부의 침입으로부터 안전한 장소에 보관하여야 한다.
4-4. 비밀번호 검증 기능
- 업체는 서비스 종류, 취급하는 개인정보의 종류, 개인정보 노출시 파급효과 등을 고려하여 적합한 비밀번호 정책을 수립하고 공시하여야 한다. 비밀번호 정책에는 최소 비밀번호 길이 및 문자조합, 변경 주기 등을 포함해야 한다.
- 비밀번호 정책이 수립되면, 업체는 사용자 비밀번호가 자사의 비밀번호 정책을 만족하는지 확인할 수 있는 비밀번호 검증 기능을 구현하여 적용해야 한다. 비밀번호 검증 기능은 사용자가 설정하는 비밀번호가 업체의 비밀번호 정책을 만족하는지 여부를 직접적으로 검토하여, 보안성이 떨어지는 비밀번호는 변경하도록 유도할 수 있다.
- 다음 조건에서 해당하는 비밀번호는 취약한 비밀번호 이므로, 비밀번호 검증 기능에서 아래 조건에 해당하는 비밀번호인지를 검증하여 이를 사용하지 않도록 구현할 것을 권고한다.
- 암호 적용에 책임이 있는 관리자는 키관리 계획을 수립하고 암호 초기 적용 단계 부터 키 관리를 고려해야 한다. 키 관리는 암호 알고리즘과 프로토콜에 사용되는 키의 안전한 생성, 저장, 분배 및 파기할 수 있는 기반을 제공한다.
- 암호를 이용하여 정보를 보호할 때는 암호키의 강도, 사용하는 암호 알고리즘과 프로토콜의 안전성, 사용하는 다양한 암호 알고리즘 및 프로토콜의 적절한 조합 등을 고려하는 것이 중요하다.
- 암호키 관리의 가장 기본적인 고려사항은 1) 암호에 사용되는 모든 키는 불법으로 변경되거나 대체되지 못하도록 해야 한다는 것과, 2) 암호키와 개인키는 노출되지 않아야 한다는 것이다.
키 사용에 대한 고려사항
- 암호 방식에 사용되는 키는 하나의 목적(암호화용, 인증용, 키 암호화용, 키분배용 등) 으로만 사용되어야 한다.
- 이렇게 하는 가장 큰 이유는 키의 용도를 제한하면 키가 외부에 노출되었거나 손상되었을 경우 피해 범위를 최소화할 수 있기 때문이다.
5-1. 암호키 사용기간 및 유효기간
- 정의
- 사용기간 : 사용자 또는 관리자가 암호키를 사용할 수 있도록 허용된 기간
- 유효기간 : 사용기간이 완료된 이후라도 추후 복호화를 위해 해당 암호키를 사용하도록 허용된 기간
- 암호키의 사용기간은 최대 2년, 유효기간은 최대 5년으로 설정할 수 있다.
5-2. 암호키 저장 방법의 예
- 암호키는 서버 또는 하드웨어 토큰에 저장되어질 수 있다. 암호키를 저장하는 서버는 웹 서버 또는 DB서버와 같은 서버일 수 있으나, 물리적으로 분리되어 있는 서버를 사용하는 것을 권고한다.
- 하드웨어 토큰은 저장된 정보가 위 / 변조 또는 외부로 노출되기 어려운 장치로 스마트카드. USB 토큰 등의 보안토큰 (HSM, Hardware Security Module)을 의미한다.
예제 1) 서비스 및 DB에서 사용하는 암호키
- 하나의 암호키를 사용하는 경우
- 암호키는 앞에서 언급한 바와 같이 서버 또는 하드웨어 토큰에 저장한다. 만일 사용 중인 서버가 Trusted Platform Module(TPM)을 지원한다면 TPM 에 암호키를 저장할 수 있다.
- 두 개 이상의 암호키 사용하는 경우
- 각각의 암호키생성키들을 물리적으로 다른 공간에 저장하는 방법을 사용할 수 있다. 즉, 하나의 암호키생성키는 서버에, 다른 암호키생성키는 하드웨어 토큰에 저장하여 사용할 수 있다.
- 이 경우 공격자가 두 개의 암호키 생성키들을 모두 획득해야 하기 때문에 하나의 암호키를 사용/저장하는 방법보다 좀 더 안전한다.
예제 2) 직원 PC에서 사용하는 암호키
- 한명의 사용자가 한 개의 암호키를 사용하는 경우
- 한명의 사용자가 자신의 PC에 고객의 개인정보, 중요정보 등을 암호화하여 저장하기 위해 암호키를 생성해야하는 경우가 있다. 이 경우에는 사용자 본인만이 암호키를 생성해 낼 수 있도록 PBKDF를 사용할 수 있다. 이 경우에는 사용자 비밀번호를 통해 암호키가 생성되므로 암호키를 PC에 저장할 필요가 없다.
- 다수의 사용자가 한 개의 암호키를 사용하는 경우(공용PC)
- 한개의 암호키로 암호화된 정보들을 다수의 사용자가 공유하기 위한 방법으로는 해당 암호키를 사용자마다 다른 "사용자별암호키"로 다시 암호화하는 방법을 사용할 수 있다.
- 사용자별암호키는 PBKDF를 이용하여 생성할 수 있으며, 이때 사용되는 비밀번호는 사용자마다 각각 다른 비밀번호를 사용하여야 한다.
- 암호키는 사용자별암호키로 암호화되어 저장되고, 사용시에는 사용자가 비밀번호로 자신의 사용자별암호키를 생성하여 암호화된 암호키를 복호화하여 사용한다.
- 암호화를 규정한 국내 법률은 아래와 같습니다.
6-2. 전자정부법
6-3. 정보통신망 이용촉진 및 정보보호 등에 관한 법륭
6-4. 전자금융거래법, 전자금융감독규정
6-5. 위치정보의 보호 및 이용 등에 관한 법률
- 인터넷에서 직접 접근이 가능한 구간(인터넷망, DMZ 구간)에 위치한 개인정보처리시스템에 주민등록번호를 저장하면 반드시 암호화해야 하며, 물리적인 망분리, 방화벽 등으로 분리된 내무방에 고유식별정보를 저장하는 경우에는 암호화 기술을 적용하거나 또는 암호화에 상응하는 조치를 할 수 있습니다.
- 네, 일부분 암호화가 가능합니다. 시스템 운영이나 개인 식별을 위해 해당 정보를 활용해야 하는 경우 생년월일 및 성별을 포함한 앞 7자리를 제외하고 뒷자리 6개번호를 암호화하여 사용할 수 있습니다.
10. 개인정보처리시스템을 위탁하거나, ASP(Application Service Provider)를 이용하는 경우 암호 수행을 위탁기관에서 해야하나요? 아니면 수탁기관에서 해야하나요?
- 개인정보의 암호화 등 안전성확보조치는 원칙적으로 “개인정보처리자”의 의무입니다. 따라서 개인정보처리시스템을 위탁하거나 ASP를 이용하는 경우에도 암호화 조치 사항에 대한 이행여부에 대한 책임은 위탁기관이 지게 됩니다.
- 다만, 위탁기관은 암호화에 대한 요구사항을 수탁기관과의 계약서 등에 명시하여 수탁기관으로 하여금 처리하게 요구할 수 있습니다.
<Reference>
- 상용소프트웨어에서의 암호기능 이용 안내서, KISA
- 암호기술 구현 안내서, KISA
- 암호이용 안내서, KISA
- 암호정책 수립 기준 안내서, KISA
- 패스워드 이용 및 선택 안내, KISA
- 개인정보 암호화 조치 안내서, 행안부
0 개의 댓글:
댓글 쓰기