법률을 준수하는 보안 설계

프로젝트 수행 시 정보 시스템을 구축하게 되고 정보 시스템을 보호하기 위해 보안 솔루션들을 도입하게 되는데 이때 ‘보안 관련 법률을 잘 준수되는 시스템을 구축되도록 하려면 어떻게 하면 될까?’ 고민하였던 적이 있었습니다. 보안 법률을 잘 준수하기 위한 절차 및 설계 방법에 대해 이야기하고자 합니다.

1. 준수해야 될 보안 법률 식별하기

2. 법적 요건 도출하기

3. 보안 설계 요건 도출하기

4. 설계 시 반영•검토하기

위와 같은 절차대로 수행하면 보안 관련 법률을 준수하는 보안 설계가 가능하지 않을까요?

준수해야 될 보안 법률 식별하기

보안 관련 어떤 법률을 적용받아야 하는지는 해당 기관 또는 기업이 어떤 비즈니스를 하고 있는지? 구축 대상 시스템이 어떤 업무를 수행하게 되는지?에 따라 적용받는 법률이 다양할 수 있습니다.

온라인에서 전자금융거래 업무를 한다면 “전자금융거래법” 적용
개인 신용평가 관련 업무가 존재하면 “신용정보법” 적용
개인정보를 다루는 업무가 존재하면 “개인정보보호법” 적용을 받을 수 있습니다.

일반적으로 금융 기관의 시스템들은 전자금융거래법, 신용정보법, 개인정보보호법 등을 적용받습니다.

여러분이 프로젝트 보안 담당자라면 어떤 법률을 적용받는지 알 수 있을까요?

해당 기관 또는 기업의 비즈니스 및 구축 대상 시스템의 업무를 파악하고, 관련 법률을 알고 있으면 됩니다. 보다 효율적인 방법은 보안팀, 법무팀 등 관련 부서에서 준수해야 될 법률들을 이미 알고 있으므로 담당자 미팅을 통해서도 알 수 있을 것입니다.

법적 요건 도출하기

적용받는 법률을 확인하였으면 해당 법률 조항 내용을 확인해야 합니다.

우리나라의 모든 법률은 법제처의 국가법령정보센터(http://www.law.go.kr/)에서 확인할 수 있습니다. 대표적인 보안 관련 법률은 아래 표와 같습니다.

금융기관: 전자금융거래법, 신용정보법
행정/공공기관: 정보통신기반보호법
민간/기업: 정통망법, 개인정보보법

l 대표적인 보안 관련 법률

국가법령정보센터에서 ‘전자금융거래법’을 찾아보면 본문이 제7장으로 이루어져 있습니다. 그중 ‘제3장 전자금융거래의 안전성 확보 및 이용자 보호’ 이 부분이 보안 관련 내용이 담겨 있습니다.

많은 법률 조항 중에 시스템 구축 관련 필요한 법률 조항만을 어떻게 식별하여 정리하는 것이 효율적일까 고민해 보게 되었습니다.

시스템 구축 관련은 관리적, 물리적, 기술적 보안 중 주로 기술적 보안 영역에 해당됩니다. 기술적 보안 영역은 세부적으로 데이터, 어플리케이션, 네트워크, 시스템, 클라이언트 영역으로 세분화할 수 있습니다.

또한, 시스템 구축 시 필요한 대표적인 보안 요소 기술로 인증, 접근 통제, 암호화, 로깅, 위협 대응 등이 필요합니다. 이를 정리하면 아래 표 형태로 나오는데 기술적 보안 세부 영역 별 보안 요소 기술에 해당되는 보안 법률의 조항 및 내용을 찾아 매핑하는 방법입니다.

프로젝트 수행 시 아래와 같이 실제 법률 조항을 기술적 보안 세부 영역별 보안 요소 기술 별로 매핑해 ‘법적 요건 가이드’라는 이름으로 문서로 만들어보았습니다.

법적 요건 가이드 활용은 기술적 보안의 세부 영역에 해당되는 시스템 또는 보안 솔루션 구축 시 법적 요건을 고려하여 설계에 반영하고 구축 시 법적 요건이 충족되었는지 확인할 수 있습니다.

보안 설계 요건 도출하기

‘법적 요건 가이드’를 활용해 기술적 보안 영역 보안 요소 기술에 대한 설계 요건을 도출합니다. 아래 표는 기술적 보안의 데이터 영역에 대한 보안 요소 기술(인증, 접근 통제, 암호화, 로깅, 위협 대응) 중 암호화 부분에 대한 법적 요건 및 보안 설계 요건을 도출한 예시입니다.

l 보안 아키텍처 설계(데이터 영역, 암호화 부분 ) – LG CNS 사례

암호화에 대한 법적 요건을 보시면 ‘고유식별 정보가 분실•도난•유출•변조 또는 훼손되지 아니하도록 암호화 한다.’라고 되어 있으나 실제 어떤 암호화 방식, 알고리즘에 대한 언급은 없습니다. 그래서 보안 설계 요건으로 필요한 설계 항목을 도출해 정의했습니다.

설계 요건 도출 시 참고할 만한 사항은 KISA 기술 안내서(https://www.kisa.or.kr), 행안부 가이드, ISMS 체크리스트 등을 활용하는 방법을 추천해 드립니다.

설계 시 반영•검토하기

도출된 보안 설계 요건(데이터 영역, 암호화 부분)을 참고해 DB 암호화 설계에 대해 이야기하고자 합니다. 상용 DB 암호화 제품들이 많이 나와 있습니다. 제품 선정 시 아래와 같은 보안 요구 사항을 참고해 선정하면 됩니다.

선정된 제품을 통해 DB 암호화 설계 시 다음과 같은 사항들도 고려하면 됩니다.

안전한 암호화 알고리즘 확인(특히, 공공기관 도입 시 보안 적합성 검증 신청)
암호화 적용 방식 선정(Plug in 방식 / API 방식 등)
암호화 수행 관련 성능 저하 여부
암호화 키 관리의 보안성 등

그럼, 이제 DB 암호화 관련 주요 설계(예시)를 설명드리겠습니다.

설계 예시 1) 암호화 대상 선정

관련 법적 요건에 의해 비밀번호는 일방향 암호화 적용하고, 고유식별 번호(주민등록번호, 여권번호, 운전면허번호, 외국인 등록번호) 및 계좌번호, 카드번호는 양방향 암호화 적용합니다. 추가적인 개인정보 보호를 위해 이메일, 전화번호, 핸드폰 번호도 암호화를 적용합니다.

암호화 대상 선정 및 적용할 때 아래와 같은 사항을 참고하시길 바랍니다.

암호화 대상의 데이터 타입은 CHAR, VARCHAR 등 문자열만 가능
각 칼럼의 전체 값을 암호화(전체 암호화)를 원칙으로 함. 단, 데이터의 형태 (주민등록번호, 전화번호 등)에 따라 부분 암호화 적용 가능
전체 암호화의 경우 like 검색을 위한 인덱싱칼럼 추가 필요 / 부분 암호화의 경우 별도의 칼럼 추가 없이 like 검색 가능
한 칼럼에는 동일 종류의 데이터가 입력되는 것으로 간주함 (분리하는 것을 권고함) 예) 한 칼럼에 주민번호와 사업자 번호가 있을 경우 사업자 번호도 암호화됨

설계 예시 2) 암호화 적용 방식

DB 암호화 적용 방식은 Plug-In 대비 성능이 우수한 것으로 알려진 API 방식을 적용합니다. 암복호화를 위해 사용되는 암호화 키는 키 관리 전용 장비에 암호화 저장하여 운영합니다.

DB 암호화 적용 방식은 응응 프로그램에서 암호화 모듈을 호출하여 암복호화를 수행하는 API 방식과 암호화 모듈을 DB 내부에 설치하여 암복호화를 수행하는 Plug-In 방식이 있습니다. AP 서버의 소스 수정이 가능하다면 Plug-In 대비 성능이 우수한 것으로 알려진 API 방식을 적용합니다.

l API 방식 vs Plug-in 방식 비교 – LG CNS 수행 사례

키는 크게 AP 서버의 인증을 위한 인증 키와 데이터를 암복호화 하는 암호키로 구분됩니다. 암호화키는 별도 키 관리 서버에 존재하게 하여 보안성을 제공합니다.

설계 예시 3) 암호화 알고리즘 및 키 길이 적용 방안

데이터 암호화를 위해 금융감독원의 규정을 준수하는 AES 알고리즘을 사용하고 KISA 권고에 따라 128bit 길이의 키를 사용하며, 일방향 암호화가 적용되는 비밀번호는 금융감독원의 규정과 KISA의 권고안에 따라 SHA-256 알고리즘을 사용합니다.

데이터 암호화는 대칭 키를 사용한 블록 단위 암호화 알고리즘이 사용되며 주로 AES 알고리즘을 사용합니다. 비밀번호는 랜덤 상수를 키로 하는 일방향(해쉬) 함수를 사용합니다.

AES 알고리즘(양방향 암호화)의 주요 특징입니다.

금융감독원의 규정을 준수하는 알고리즘
KISA 권고에 따라 128 bit 키 사용 (제2010-28호-암호 정책 수립기준 안내서 p.15)
미국 NIST에서 1998년에 발표한 블록 암호화 방식
지금까지 알려진 블록 암호화 알고리즘에 대한 모든 공격 방법에 대하여 안전
3DES, SEED, ARIA 등의 알고리즘보다 성능이 우수

SHA 알고리즘(일방향 암호화)의 주요 특징입니다.

금융감독원의 규정을 준수하는 알고리즘
KISA 권고에 따라 SHA-256 선정 (제2010-28호-암호 정책 수립기준 안내서 p.15)
미국 국가 안전 보장국(NSA)에서 1993년에 발표한 해시 알고리즘
SHA-0, SHA-1 SHA-2 (224,256,384,512) 존재

설계 예시 4) 암호화 운영 모드 및 초기 값

암호화 운영 모드는 보안성이 우수한 CBC 방식을 사용하며 초기 값(Initialization Vector)는 JOIN 쿼리의 원활함을 위해 FIXED 값을 사용합니다.

일반적인 데이터의 암호화 알고리즘은 블록 단위별 암호화 운영 모드와 암호화 초기 값(Initial Vector)를 설정합니다.

운영 모드는 CBC 모드와 CFB 모드가 존재하며 보안성이 뛰어난 CBC 방식을 사용합니다.

초기 값(Initialization Vector)은 AES 알고리즘과 같은 블록 단위 암호화 알고리즘에서 사용되며 최초의 평문 블록을 암호화할 때는 ‘1단계 앞의 암호문 블록’이 존재하지 않으므로 이를 대신할 비트열 블록을 말하며 랜덤 값과 고정된 값을 선택적으로 사용할 수 있다. 여러 테이블에 분산된 동일한 데이터의 JOIN 쿼리를 위해 FIXED 값을 사용합니다.

설계 예시 5) 전체 암호화, 부분 암호화

원칙적으로 전체 암호화를 적용하며 주민등록번호와 외국인 등록번호처럼 암호화 대상이 아닌 생년월일을 포함하는 데이터에 대해 부분 암호화를 적용합니다.

부분 암호화는 주민등록번호처럼 암호화 대상이 아닌 생년월일을 포함하는 경우 적용 가능하며 특징은 아래와 같습니다.

위와 같이 DB 암호화 관련 주요 설계 내용을 설명드렸습니다. 법적 요건은 ‘비밀번호, 고유식별 번호 등을 안전하게 암호화 하라.’라는 것이지만 실제 설계에서는 보다 많은 내용을 포함하고 있습니다.

마지막으로 법적 요건이 실제 설계에 반영되었는지 확인하면서 부족한 부분이나 누락된 부분이 있다면 재 검토하여 설계에 반영하는 시간을 갖고 설계를 보완하면 됩니다.

프로젝트 수행 초반에 보안 요구 사항이 명확하게 식별되지 않거나, 준수해야 될 법률 이름만 쓰여 있다면 해당 법률에서 준수해야 될 보안 관련 조항들을 빠짐없이 검토하여 설계 시 반영해야 됩니다.