데이터 암호화

INFO — 조문 좌표와 기술 선택지를 정리한 참조 문서다

기준 시점은 「개인정보의 안전성 확보조치 기준」(개인정보보호위원회고시 제2026-9호, 2026-07-01 시행)과 2026-09-11 시행 개정 개인정보 보호법(법률 제21445호)이다. 법률 자문이 아니므로, 실제 판단은 시행 시점의 조문으로 대조한다.

데이터베이스 암호화에서 담당자가 막히는 지점은 알고리즘이 아니다. “이 컬럼을 암호화해야 하는가”를 물었을 때 근거로 댈 조문을 못 찾는 것이다. 암호화 의무는 항목 이름만으로 결정되지 않고, 정보주체가 이용자인지 아닌지, 데이터가 인터넷망 구간·DMZ·내부망 중 어디에 저장되는지, 저장인지 전송인지의 조합으로 갈린다. 같은 여권번호라도 어느 트랙에 걸리느냐에 따라 무조건 암호화 대상이 되기도 하고 위험도 분석으로 범위를 정할 수 있는 대상이 되기도 한다.

그래서 이 문서는 암호화 대상 정답표가 아니라 좌표다. 어느 조문이 무엇을 요구하는지 확인하고, 그 요구를 스키마·키·운영 설계로 옮길 때 무엇을 잃는지까지 함께 본다.

암호화를 요구하거나 심사하는 기준은 넷이다.

전자정부법 계열 요구는 행정기관을 대상으로 한다. 민간 서비스의 DB 설계 근거로 병렬 배치하면 적용 범위가 흐려진다.

법정 암호화 의무

현행 고시는 개인정보보호위원회고시 제2026-9호이고 2026-07-01 발령·시행됐다. 부칙에 따라 제15조제5호와 제18조는 2027-01-01 시행이다. 공개된 최신 해설서는 「개인정보의 안전성 확보조치 기준 안내서(2025.11.)」다.

근거 조문의 연결 구조

암호화 의무는 법률에서 바로 나오지 않는다. 법률이 대통령령에 위임하고, 시행령이 다시 고시에 세부 기준을 위임한다. 고시를 봐야 하는 이유가 이 사슬이다.

시행령 제30조제1항제4호는 네 갈래를 든다.

컬럼 목록이 아니라 조치의 유형을 정하고, 구체 항목은 고시 제7조로 내려보낸다.

주민등록번호는 별도 트랙이다. 법 제24조의2제2항이 암호화 보관을 직접 요구하고, 시행령 제21조의2가 적용 대상을 “주민등록번호를 전자적인 방법으로 보관하는 개인정보처리자”로 정한다. 적용 시기는 100만명 미만이 2017-01-01, 100만명 이상이 2018-01-01이므로 이미 전면 적용 상태다.

고유식별정보의 범위는 고시가 아니라 시행령 제19조가 정한다. 주민등록번호, 여권번호, 운전면허의 면허번호, 외국인등록번호 넷이다. 단서에 따라 공공기관이 법 제18조제2항제5호부터 제9호까지를 근거로 처리하는 경우 해당 정보는 범위에서 빠진다.

이용자와 이용자가 아닌 정보주체

고시 제7조는 제2항에서 “이용자의”, 제3항에서 “이용자가 아닌 정보주체의”로 갈린다. 이 분기가 문서 전체의 갈림길이다. 정보통신서비스 제공자를 대상으로 했던 「개인정보의 기술적·관리적 보호조치 기준」이 이 고시로 합쳐진 결과가 현행 이원 구조이고, 이용자 트랙이 그때 넘어온 부분이다.

설계 단계에서 먼저 정할 것은 알고리즘이 아니라 이 판정이다. 서비스 유형별로 어느 테이블의 정보주체가 이용자에 해당하는지 고시 제2조 정의로 매핑한 표를 남긴다. 회원 DB와 임직원·거래처 DB가 같은 인스턴스에 있으면 테이블 단위로 트랙이 갈린다.

두 번째로 정할 것은 망 구간이다. 제7조제3항제1호와 제2호, 제4항의 적용이 네트워크 구간으로 갈리므로, DB 인스턴스가 인터넷망 구간·DMZ·내부망 중 어디에 있는지 배치도로 확정해 둔다. 고시 제2조제12호는 내부망을 “인터넷망 차단, 접근 통제시스템 등에 의해 인터넷 구간에서의 접근이 통제 또는 차단되는 구간”으로 정의한다.

저장 시 암호화 대상

고시 제7조 전체를 항 단위로 펼치면 다음과 같다.

IMPORTANT — 이용자의 신용카드번호와 계좌번호는 조건 없는 법정 의무다

제7조제2항 제5호가 신용카드번호, 제6호가 계좌번호다. 고유식별정보가 아니라는 이유로 위험도 판단 대상으로 분류하면 근거 없는 평문이 된다. 결제·정산 테이블은 이 두 항목 때문에 이용자 트랙에서 빠져나갈 수 없다.

용어는 고시 정의를 따른다. 제2조제9호 생체정보는 지문·얼굴·홍채·정맥·음성·필적 등을 가리키고, 제2조제10호 생체인식정보는 생체정보 중 특정 개인을 인증·식별할 목적으로 쓰는 것이다. 암호화 의무 조문이 쓰는 용어는 생체인식정보이며, 현행 고시에 “바이오정보”라는 용어는 없다. 비밀번호는 제2조제8호, 보조저장매체는 제2조제14호에 정의가 있다.

제7조제5항은 DB 담당자가 자주 놓친다. 운영 중 뽑은 덤프, 검증용 CSV, 분석가 노트북에 내려간 추출물이 모두 이 항에 걸린다. 추출 경로를 막지 못한다면 추출물 자체를 암호화하는 절차가 필요하다.

전송 구간 암호화

전송 암호화는 두 항으로 나뉜다. 제7조제1항은 인증정보를 정보통신망으로 송수신할 때 구간 제한 없이 암호화를 요구한다. 제7조제4항은 개인정보를 정보통신망을 통해 인터넷망 구간으로 송·수신할 때 암호화를 요구한다. 상위 근거는 시행령 제30조제1항제4호 다목이다.

문언대로 읽으면 내부망 안의 애플리케이션 서버와 DB 사이 구간은 제7조제4항의 범위 밖이다. DB 연결에 TLS를 쓰라고 직접 요구하는 조문은 없다. 그래도 켜는 편이 낫다. 근거는 조문이 아니라 위협모델이다. 저장 암호화는 네트워크를 보호하지 않으며, MySQL 문서도 데이터가 네트워크에 올라간 시점에는 평문 형태라고 명시한다. 인증정보가 같은 연결을 타고 흐른다면 제7조제1항이 그 구간에도 걸린다.

위험도 분석에 따른 예외

예외는 하나뿐이고 조건이 셋 모두 맞아야 한다. 이용자가 아닌 정보주체의 정보이고, 주민등록번호를 제외한 고유식별정보이고, 내부망에 저장하는 경우다. 이때 제7조제3항제2호 가목과 나목에 따라 적용 여부와 범위를 정해 시행할 수 있다.

• 가목 — 법 제33조 영향평가 대상 공공기관이 그 영향평가 결과에 따르는 경우
• 나목 — 암호화를 적용하지 않을 때 위험도 분석 결과에 따르는 경우

나머지에는 예외 문언이 없다.

• 주민등록번호는 예외가 없다. 법 제24조의2제2항과 시행령 제21조의2가 별도로 요구한다.
• 이용자의 제7조제2항 7개 항목은 예외가 없다.
• 인터넷망 구간과 DMZ에 저장하는 고유식별정보는 예외가 없다.

위험도 분석은 고시 제2조제13호에 정의가 있다. 다만 고시는 위험도 분석의 문서화나 내부 승인 절차를 명문으로 요구하지 않는다. 조문 의무와 입증 실무를 구분해서 쓸 필요가 있다.

IMPORTANT — 문서화는 조문 의무가 아니라 면책을 입증하는 수단이다

분석 결과와 승인 기록을 남기는 이유는 고시가 요구해서가 아니다. 유출이 발생했을 때 법 제64조의2제1항제9호 단서인 “제29조에 따른 안전성 확보에 필요한 조치를 다한 경우”를 증명할 수단이 기록뿐이기 때문이다. 기록이 없으면 판단이 없었던 것과 구별되지 않는다.

위반 시 제재

2026-09-11 시행 개정법(법률 제21445호) 기준이다.

과징금은 매출액이 없거나 산정이 곤란하면 20억원 이내, 가중 시 50억원 이내로 정한다. 가중 사유는 3년 내 같은 호를 고의·중과실로 반복한 경우, 고의·중과실로 피해 정보주체가 1천만명 이상인 경우, 법 제64조제1항 시정명령을 이행하지 않은 경우다.

제64조의2제1항제9호 단서가 안전성 확보에 필요한 조치를 다한 경우를 과징금 대상에서 제외한다. 제64조의2제5항제4호는 암호화 등 안전성 확보 조치 이행 노력을 과징금 산정 고려사항으로 두고, 제6항은 보호 투자 등 대통령령이 정한 사유가 있으면 감경을 허용한다(고의·중과실은 제외). 과태료도 제75조제5항에 따라 감경·면제될 수 있다. 암호화 설계 기록을 남기는 실무적 이유가 이 조항들이다.

암호 알고리즘 선택

고시 제7조는 알고리즘 이름을 열거하지 않고 “안전한 암호 알고리즘”만 요구한다. 따라서 선택 기준은 두 갈래로 갈린다. 민간 일반에서는 무엇이 안전한 알고리즘인지 판단해 근거를 남기면 되고, 검증필 암호모듈이 요구되는 환경에서는 선택 가능한 목록 자체가 다르다.

KCMVP 검증필 모듈이 필요한 경우

KCMVP의 현행 근거는 「사이버안보 업무규정」(대통령령 제34287호, 2024-03-05 개정) 제9조다. 제2항은 국가정보원장이 보안대책을 수립할 수 있다고 정한다. 대상은 정보보호시스템, 암호장치, 암호모듈 및 보안기능이 있는 정보통신기기의 도입·운영과 클라우드컴퓨팅서비스 이용이다. 제3항은 중앙행정기관등이 도입·운영하거나 이용하는 정보보호시스템등과 클라우드컴퓨팅서비스가 그 보안대책에 적합한지 검증할 수 있다고 정한다. 제4항은 국가정보원장이 직접 개발·보급할 수 있게 한다.

전자정부법 계열도 함께 본다. 제56조제3항은 행정기관의 장이 정보통신망으로 전자문서를 보관·유통할 때 국가정보원장이 안전성을 확인한 보안조치를 하도록 요구한다. 시행령 제69조는 제목이 “전자문서의 보관·유통 관련 보안조치”이고, 제1항제1호에서 국가정보원장이 개발하거나 안전성을 검증한 암호장치와 정보보호시스템의 도입·운용을 정한다. 이 조문에 “암호모듈”이라는 표현은 없다. 암호모듈을 명시한 조문은 사이버안보 업무규정 제9조제2항이므로, 근거를 전자정부법 시행령 하나로만 적으면 불완전하다.

의무 주체는 문언상 중앙행정기관등이다. 즉 국가·공공기관 조달 요건이다. 민간에는 검증필 암호모듈 사용 의무가 없다. 「개인정보의 안전성 확보조치 기준」 제7조는 안전한 암호 알고리즘만 요구하고 검증필 암호모듈을 요구하는 문언을 두지 않는다.

정리하면 판정 순서는 이렇다. 공공 조달이나 보안적합성 검증을 통과해야 하는 시스템이면 검증대상 알고리즘 안에서 고른다. 민간 서비스면 알고리즘 선택은 자유롭고, 대신 그 선택이 안전하다는 근거를 남긴다.

검증대상 알고리즘

검증대상으로 알려진 알고리즘은 다음과 같다.

블록암호의 운영모드는 ECB·CBC·CFB·OFB·CTR, 인증모드는 CCM·GCM이다(HIGHT는 인증모드 없음). 해시는 SHA-2와 SHA-3가 224·256·384·512, LSH가 224·256·384·512·512-224·512-256이다. RSAES는 2048·3072비트에 해시 SHA-224·SHA-256을 쓴다. KBKDF는 HMAC·CMAC 기반, PBKDF는 HMAC 기반이다.

여기서 중요한 사실은 블록암호가 국산 4종이고 AES가 목록에 없다는 것이다. 민간에서 AES를 쓰는 것이 문제라는 뜻이 아니다. 검증필 모듈이 요구되는 환경에서 AES-256으로 구현하면 그 요건을 충족하지 못한다는 뜻이다. 두 맥락을 섞어 “AES-256 권장”만 적어 두면 공공 조달에서 설계를 되돌리게 된다.

위 목록은 조달 요건을 확정하는 근거로 쓰기에 충분하지 않다. 제품을 발주하거나 모듈을 선정할 때는 국가정보원과 국가사이버안보센터가 공개하는 검증대상 목록과 검증필 암호모듈 목록으로 대조한다.

권고되지 않는 알고리즘

SHA-1, MD5, DES, 3DES는 검증대상 목록에 없다. 고시가 알고리즘 이름을 열거하지 않으므로, 민간에서 하한선을 판단할 때는 제품 문서가 강제하는 선을 기준으로 쓸 수 있다. MySQL 8.4는 TLS 연결에 네 가지를 요구한다 — TLSv1.2 또는 TLSv1.3, 순방향 비밀성, 암호군·인증서에 SHA2 사용, GCM 등 AEAD 모드 사용이다. 이 선에 미치지 못하는 암호군은 금지한다.

기본값도 확인할 대상이다. PostgreSQL의 pgcrypto에서 pgp_sym_encrypt의 기본 cipher-algo는 aes128이므로 256비트가 필요하면 명시해야 하고, 기본 s2k-digest-algo는 sha1이다. 원시 encrypt()·decrypt()는 문서가 권장하지 않는다. 키를 그대로 사용하고, 무결성 검증이 없고, IV를 직접 관리해야 하기 때문이다.

알고리즘과 키 길이는 코드에 박지 말고 설정으로 분리한다. 정부는 2023년 7월 「양자내성암호 전환 마스터플랜」을 발표하며 2035년까지 국가 암호체계를 전환한다는 목표를 제시했다. 교체가 예정된 값을 스키마와 코드에 하드코딩하면 그때 다시 마이그레이션한다.

비밀번호는 일방향

비밀번호는 복호화 가능한 암호화로 저장하면 안 된다. 고시 제7조제1항 단서가 “복호화되지 아니하도록 일방향 암호화하여 저장”을 요구하고, 시행령 제30조제1항제4호 가목도 일방향을 명문으로 쓴다. 제7조제1항은 비밀번호와 생체인식정보 등 인증정보 전체를 암호화 대상으로 묶되, 일방향 요구는 비밀번호 저장에 한정된다. 생체인식정보는 제2항·제3항 트랙에서 저장 암호화 대상이기도 하다.

일방향이면 아무 해시나 되는 것은 아니다. 연산 비용을 조절할 수 있는 KDF를 쓰고 솔트를 계정마다 다르게 생성한다.

WARNING — 범용 해시 단독은 비밀번호 저장에 쓰지 않는다

PostgreSQL 18 pgcrypto 문서의 상대 비용표는 같은 조건에서 crypt-bf/8이 초당 1,792회, 원시 md5가 초당 150,085,504회 해시된다고 적는다. 범용 해시는 빠른 것이 목적이라 대입 공격에도 그만큼 빠르다. SHA-256·SHA-3 단독은 가명처리용 식별자 치환처럼 속도가 필요한 용도에만 쓴다.

구현 환경에 따라 선택지가 좁아진다. KCMVP 검증대상 키 유도 함수는 KBKDF와 PBKDF이고 Argon2·bcrypt·scrypt는 목록에 없다. pgcrypto도 Argon2와 scrypt를 지원하지 않는다. 공공 조달과 PostgreSQL 환경에서는 이 제약을 먼저 확인하고 알고리즘을 고른다.

pgcrypto의 gen_salt는 알고리즘별로 반복 횟수 범위가 다르다.

sha256crypt·sha512crypt의 기본값 5000에 대해서는 문서가 현대 하드웨어에는 너무 낮다고 경고한다. 기본값을 그대로 쓰지 않고, 실제 서버에서 로그인 지연을 측정해 값을 정하고 하드웨어를 교체할 때 다시 올린다.

-- 비밀번호는 복호화되지 않는 형태로 저장한다
-- gen_salt('bf') 의 기본 반복 횟수는 6 이다. 값은 측정해서 정한다
UPDATE accounts
   SET pw_hash = crypt(:password, gen_salt('bf'))
 WHERE id = :account_id;

-- 검증은 저장된 해시를 솔트로 써서 다시 계산한다
SELECT id FROM accounts
 WHERE id = :account_id
   AND pw_hash = crypt(:password, pw_hash);

WARNING — 두 문장 모두 WHERE 로 대상을 한정한다

UPDATE 에서 WHERE 를 빼면 전 계정의 해시를 한 번에 덮어쓰고, 해시는 복호화되지 않으므로 되돌릴 수 없다. SELECT 에서 식별 조건을 빼면 모든 행에 crypt() 를 계산하게 되는데, 반복 횟수를 올려 둔 만큼 그 비용이 그대로 곱해진다.

DB 에 적용하는 방식

고시 제7조는 암호화 구현 계층을 지정하지 않는다. 문언은 “안전한 암호 알고리즘으로 암호화하여 저장”이다. 그래서 컬럼·TDE·볼륨 중 무엇을 고르느냐는 조문 해석 문제가 아니라 어느 위협을 막으려는지의 문제다.

컬럼 수준 암호화

특정 컬럼만 암호화하고 나머지는 평문으로 둔다. 암호화·복호화 지점은 애플리케이션 코드이거나 DB 함수다. 암호문과 함께 키 버전 식별자를 저장해 두면 키를 교체한 뒤에도 옛 값을 복호화할 수 있다.

DB 함수로 처리할 때 한계가 있다. pgcrypto 문서는 모든 함수가 데이터베이스 서버 안에서 실행되므로 데이터와 비밀번호가 pgcrypto와 클라이언트 애플리케이션 사이를 평문으로 이동한다고 적는다. 그래서 로컬 접속이나 SSL이 필요하고 시스템 관리자와 DB 관리자를 신뢰해야 한다. 그럴 수 없으면 클라이언트 애플리케이션 안에서 암호화하는 편이 낫다고 권한다. 측면 채널 공격 저항은 제공하지 않고, 컬럼 암호화 시 복호화된 데이터와 복호화 키가 짧은 시간 서버에 존재한다.

-- pgp_sym_encrypt 의 기본 cipher-algo 는 aes128 이므로 명시한다
INSERT INTO members (ci_enc, key_ver)
VALUES (pgp_sym_encrypt(:plain, :key, 'cipher-algo=aes256'), :key_ver);

투명 데이터 암호화(TDE)

엔진이 데이터 파일을 쓰고 읽을 때 암복호를 처리한다. 스키마와 쿼리를 바꾸지 않으므로 도입 비용이 가장 낮고, 검색·정렬에 영향이 없다. 막는 것은 데이터 파일과 디스크, 그리고 암호화된 테이블스페이스 파일의 탈취다.

막지 못하는 것이 더 중요하다. DB에 로그인한 계정의 조회와 SQL 인젝션은 그대로 통과한다. MySQL 문서는 데이터가 네트워크에 올라가면 평문 형태라고 명시하고, mysqldump 같은 논리 백업 산출물은 암호화되지 않는다고 적는다. TDE만 켜고 암호화를 마쳤다고 보면 유출 경로 대부분이 열려 있다.

파일·볼륨 암호화

PostgreSQL 공식 Encryption Options 문서는 파일시스템 계층(eCryptfs·EncFS·PEFS)과 블록 계층(dm-crypt+LUKS·geli·gbde)을 선택지로 제시한다. 볼륨을 마운트한 뒤에는 DB 프로세스에 평문으로 보이므로 막는 범위는 TDE와 비슷하고, 키 관리 주체가 엔진이 아니라 OS 쪽이라는 점이 다르다. 엔진이 관여하지 않으니 어떤 테이블이 암호화됐는지 DB 안에서는 확인할 수 없다.

세 방식과 법정 요구의 관계

조문만 보면 계층 선택의 답이 나오지 않는다. 위협모델을 보면 답이 좁아진다. 주민등록번호처럼 예외가 없는 항목은 컬럼 또는 애플리케이션 계층에서 처리하기를 권고한다. 조문이 그 계층을 요구하기 때문이 아니라, 저장매체 탈취만 막는 조치로는 실제 유출 경로를 덮지 못하기 때문이다.

엔진별 현황

MySQL 8.x의 InnoDB 저장 암호화는 AES-256을 쓰고, 테이블스페이스 키는 ECB, 데이터는 CBC로 처리하며 다른 알고리즘으로 대체할 수 없다. 암호화 범위는 file-per-table 테이블스페이스, 일반 테이블스페이스, mysql 시스템 테이블스페이스, redo 로그, undo 로그, 암호화된 테이블스페이스의 doublewrite 페이지, 암시적 FULLTEXT 인덱스 테이블이다. InnoDB 시스템 테이블스페이스는 지원하지 않는다. redo·undo 로그 암호화는 기본값이 꺼져 있다.

[mysqld]
# 기본값은 OFF 다. 켜지 않으면 로그 파일에 평문이 남는다
innodb_redo_log_encrypt=ON
innodb_undo_log_encrypt=ON

8.4에서 키링 플러그인이 제거되고 컴포넌트로 전환됐다. keyring_file은 component_keyring_file로(keyring_file_data 변수도 제거), keyring_encrypted_file은 component_keyring_encrypted_file로, keyring_oci는 component_keyring_oci로, openssl_udf는 component_enterprise_encryption으로 바뀌었다. 플러그인으로 남은 keyring_okv(KMIP), keyring_aws(AWS KMS), keyring_hashicorp는 모두 Enterprise 기능이다.

PostgreSQL 18에는 코어 TDE가 없다. 공식 Encryption Options 문서가 제시하는 선택지는 비밀번호 해시, pgcrypto 컬럼 암호화, 파일시스템·블록 암호화, 네트워크 암호화(SSL·GSSAPI), SSL 호스트 인증, 클라이언트측 암호화이고 투명 데이터 암호화 항목은 없다. 따라서 PostgreSQL에서 저장 데이터를 암호화하려면 컬럼 암호화나 OS 계층 암호화를 선택한다.

pgcrypto는 OpenSSL을 필요로 하는 trusted 확장이다. 18에서 pgcrypto.builtin_crypto_enabled(on·off·fips)와 fips_mode()가 추가됐다. ignore-cipher-failure 옵션은 CVE-2026-14663 이전 동작과의 호환용이며 문서가 위험을 명시하므로 새로 쓰지 않는다.

암호화가 스키마에 미치는 영향

이 문서가 DB 문서인 이유가 이 절이다. 컬럼을 암호화하면 그 컬럼은 더 이상 검색·정렬·조인의 대상이 아니다.

인덱스와 검색

같은 평문이 항상 같은 암호문이 되는 결정적 암호화는 인덱스를 쓸 수 있다. Microsoft Always Encrypted 문서는 결정적 암호화에서 점 조회, 동등 조인, 그룹화, 인덱싱이 가능하다고 적고, 허용 연산을 =·IN·GROUP BY·DISTINCT로 한정한다. 무작위 암호화는 암호화된 컬럼에서 검색·그룹화·인덱싱·조인을 지원하지 않는다.

결정적 암호화의 대가는 분포 누설이다. 같은 문서가 권한 없는 사용자가 암호화된 컬럼의 패턴을 관찰해 값을 추측할 수 있고, 참·거짓이나 동서남북 같은 작은 값 집합일 때 특히 그렇다고 경고한다. 성별·등급처럼 카디널리티가 낮은 컬럼에 결정적 암호화를 쓰면 사실상 평문이다.

동등 검색만 필요하면 블라인드 인덱스가 설계 관용구로 쓰인다. 원문의 HMAC 값을 별도 컬럼에 저장하고 그 컬럼에 인덱스를 건다. 본문 컬럼은 무작위 암호화로 두어 분포 누설을 피하고, 검색은 인덱스 컬럼으로만 한다. pgcrypto가 hmac()을 제공하므로 구현 수단은 있다.

-- 검색용 컬럼에는 원문의 HMAC 을 넣는다. 동등 비교만 가능하다
SELECT id FROM members WHERE email_idx = hmac(:email, :idx_key, 'sha256');

정렬과 범위 조건

허용 연산이 동등 비교 계열뿐이라는 말은 ORDER BY·BETWEEN·<·>·LIKE가 모두 막힌다는 뜻이다. Always Encrypted는 FULLTEXT 인덱스도 지원하지 않는다. 암호화한 생년월일로 연령 범위를 조회하거나 암호화한 이름으로 정렬하는 화면은 스키마 설계 단계에서 이미 불가능하다.

애플리케이션에서 전부 읽어 복호화한 뒤 정렬하는 방식은 데이터가 늘면 유지되지 않고, 키셋 페이지네이션도 성립하지 않는다. 대안은 요구사항을 바꾸는 쪽이다. 범위 조건이 필요한 값은 범주화한 파생 컬럼(연령대·지역 구분 등)을 평문으로 따로 두고 원문만 암호화한다. 부분 검색이 꼭 필요하다면 그 컬럼을 암호화 대상으로 유지할지, 가명처리로 요구사항을 바꿀지를 먼저 결정한다.

길이와 타입

암호문은 이진 데이터이고 원문보다 길다. 컬럼 폭을 원문 길이로 잡으면 값이 잘린다. IV를 직접 관리해야 하는 구현이라면 IV도 함께 저장해야 하고, 키 버전 식별자도 자리를 차지한다. 알고리즘을 교체할 때 길이가 또 바뀌므로 폭을 촘촘하게 잡지 않는다.

문자 타입으로 받을 때는 정렬 규칙에도 제약이 있다. Always Encrypted는 문자 컬럼에 이진 정렬(_BIN2) collation을 요구한다. 그 밖에 계산 컬럼·기본값·체크 제약·파티션 키에 암호화 컬럼을 쓸 수 없고, 암호문과 평문을 한 식에서 섞으면 피연산자 충돌 오류가 난다. 기존 테이블에 암호화를 얹을 때 이 제약들이 마이그레이션 작업량의 대부분을 만든다.

키 관리

법정 요구

키 관리를 요구하는 조문은 고시 제7조제6항 하나다. 대상은 10만명 이상(대기업·중견기업·공공기관) 또는 100만명 이상(중소기업·단체) 정보주체를 처리하는 개인정보처리자다. 요구 내용은 안전한 암호 키의 생성·이용·보관·배포·파기 등에 관한 절차를 수립·시행하는 것이다. 이 규모에 걸리는지 판정하려면 정보주체 수 산정 기준과 기업 규모 구분 근거를 문서로 남겨 둔다.

시행령 제30조제1항에는 암호키 관리 조항이 없다. 제4호는 저장·전송 암호화를 정한다. 키를 어디에 분리 보관하라거나, 몇 개월마다 교체하라거나, HSM을 쓰라고 명문으로 정한 법령 조문은 없다. 그런 요구는 인증기준과 실무 관행에서 온다.

ISMS-P에서는 2.7.1 암호정책 적용과 2.7.2 암호키 관리가 해당 항목이다. 인증기준은 관리체계 16개, 보호대책 64개, 개인정보 처리단계별 21개로 구성되고 공개된 인증기준 안내서는 2023년 11월판이다. 2025년 12월 전면 개편 추진이 보도됐으므로 항목 번호는 심사 시점 기준으로 대조한다. DB를 다루면 2.6.4 데이터베이스 접근, 2.9.4 로그 및 접속기록 관리, 2.9.5 점검, 3.x 개인정보 처리단계별 요구사항이 함께 범위에 들어온다.

키 분리 보관과 접근통제

키를 데이터와 같은 곳에 두면 암호화가 성립하지 않는다. MySQL 문서는 component_keyring_file과 component_keyring_encrypted_file이 규제 준수 솔루션으로 의도된 것이 아니며 PCI·FIPS 등은 KMS나 HSM을 요구한다고 명시한다. 로컬 파일 키링은 개발·검증 환경까지로 보고, 규제 대상 데이터는 외부 키 저장소를 쓴다. keyring_aws는 Enterprise 전용이면서 키 저장에 로컬 파일을 사용한다는 점도 확인해 둔다.

마스터 키를 잃으면 암호화된 테이블스페이스 파일의 데이터는 복구할 수 없다. 키 백업과 접근 권한자 목록은 데이터 백업과 같은 급으로 관리한다.

키 교체

운영 중인 테이블은 한 번에 재암호화할 수 없다. 컬럼 암호화는 키 버전 컬럼으로 진행 상황을 추적하며 나눠 처리한다.

1. 새 키를 발급하고 키 버전을 부여한다. 신규 쓰기는 새 키로 한다
2. 기존 행을 배치로 읽어 복호화한 뒤 새 키로 다시 암호화한다
3. 옛 키 버전을 가진 행이 0이 되면 옛 키를 폐기한다. 그전에 폐기하면 복구할 수 없다
4. 백업 보관 기간이 지날 때까지 옛 키를 폐기 대상이 아니라 보관 대상으로 분리한다

MySQL TDE의 키 교체는 성격이 다르다.

-- 마스터 키만 교체한다. 테이블스페이스 데이터를 복호화하거나 재암호화하지 않는다
ALTER INSTANCE ROTATE INNODB MASTER KEY;

-- 테이블 단위 암호화 전환은 COPY 알고리즘이므로 테이블을 다시 만든다
ALTER TABLE members ENCRYPTION = 'Y';

-- 일반 테이블스페이스 전환은 INPLACE 로 동시 DML 을 허용하고 동시 DDL 을 막는다
ALTER TABLESPACE ts1 ENCRYPTION = 'Y';

테이블스페이스 키까지 바꾸려면 암호화를 끄고 다시 켜야 한다. 큰 테이블에서 ALTER TABLE ... ENCRYPTION은 테이블 재생성 비용을 그대로 부담하므로 작업 창을 확보하고 진행한다.

위 절차의 마지막 단계는 어느 계층으로 암호화했는지에 따라 성격이 달라진다. 컬럼 암호화라면 덤프 안에도 암호문이 남으므로 옛 키를 보관해야 한다. TDE라면 논리 백업 산출물이 애초에 평문이므로, 옛 키 보관이 아니라 덤프 파일 자체의 보호가 과제다.

KMS 를 쓸 때

AWS 문서는 AWS KMS에서 만든 키가 FIPS 140-3 Security Level 3 검증 하드웨어 보안 모듈로 보호되며 암호화되지 않은 상태로 KMS를 떠나지 않는다고 적는다. AWS가 공개한 컴플라이언스 프로그램 목록에는 CSAP와 K-ISMS, Privacy 분류의 Korea Data Privacy, FIPS 140-3이 있고 ISMS-P 표기는 없다. KCMVP도 그 목록에 없다. 검증필 암호모듈이 요구되는 공공 환경에서 KMS나 CloudHSM이 그 요건을 대신한다고 볼 공개 근거는 없다. 조달 요건이 있으면 검증필 모듈 목록으로 별도 확인한다.

관리형 DB를 쓸 때는 제공되는 암호화가 어느 계층인지 먼저 확인한다. 저장 볼륨 암호화는 파일·볼륨 계층이다. 고시 제7조제2항처럼 예외 없는 항목을 그 하나로 덮으려 하면 「세 방식과 법정 요구의 관계」 절에서 짚은 위협모델 문제가 그대로 남는다.

운영 고려사항

성능 영향은 숫자로 인용할 공개 자료가 마땅치 않다. MySQL 문서는 저장 공간 추가 부담이 없고 자체 내부 벤치마크에서 성능 부담이 한 자릿수 백분율 차이라고 적는다. 이를 재현한 독립 측정 자료는 공개되어 있지 않으므로, 도입 판단은 자기 워크로드에서 측정해 정한다. 측정 대상은 네 가지다.

• 암호화 대상 컬럼을 읽는 쿼리의 응답시간 분포와 CPU 사용량
• 인덱스를 못 쓰게 된 쿼리의 실행 계획 변화
• 배치 재암호화 작업의 소요 시간과 락 점유
• 키 저장소 호출 실패 시 애플리케이션의 동작

백업과 복구에서는 키가 데이터와 함께 필요하다. mysqldump 산출물은 암호화되지 않고, redo·undo 로그 암호화는 기본값이 꺼져 있으며, 바이너리 로그와 릴레이 로그 암호화는 별도 기능이다. 복제 경로와 백업 경로를 모두 목록으로 만들어 각 경로에서 데이터가 평문인지 확인한다. 키를 잃으면 데이터를 잃는다는 사실이 복구 계획의 출발점이다.

복호화 조회 기록은 구현 위치를 정해야 남는다. 애플리케이션 계층에서 암호화하면 DB 접속기록에는 암호문 조회만 남고 누가 무엇을 복호화했는지는 기록되지 않는다. 복호화 함수 호출 지점에 로깅을 넣을 책임이 애플리케이션에 있음을 설계에 명시한다.

심사에서 요구받는 것은 설정 화면이 아니라 기록이다. 사후에 만들 수 없으므로 운영 중에 남긴다.

검증필 암호모듈 항목은 공공 조달 대상에만 해당한다. 민간 시스템 증빙 목록에 그대로 넣으면 충족할 수 없는 요건을 스스로 만드는 셈이 된다.

참고

• 개인정보보호위원회 — 개인정보의 안전성 확보조치 기준(제2026-9호)과 안내서(2025.11.)
• 국가법령정보센터 — 개인정보 보호법·시행령, 고시 원문(행정규칙 일련번호 2100000281400)
• ISMS-P 인증제도 — 인증기준과 안내서(2023.11.)
• MySQL 8.4 Reference Manual — InnoDB Data-at-Rest Encryption, 키링 컴포넌트, FAQ A.17
• PostgreSQL 18 문서 — Encryption Options, pgcrypto
• 관련 문서: 데이터 3법

요약

• 기준 시점은 고시 제2026-9호(2026-07-01 시행)와 2026-09-11 시행 개정 보호법이다
• 의무는 이용자(제7조제2항)와 이용자가 아닌 정보주체(제7조제3항)로 갈린다. 이 판정이 먼저다
• 이용자의 주민등록번호·여권번호·운전면허번호·외국인등록번호·신용카드번호·계좌번호·생체인식정보는 조건 없이 저장 암호화 대상이다
• 위험도 분석 예외는 이용자가 아닌 정보주체의, 주민등록번호 외 고유식별정보를, 내부망에 저장하는 경우에 한정된다
• 검증필 암호모듈은 중앙행정기관등 조달 요건이고 민간에는 의무가 없다. 검증대상 블록암호는 ARIA·SEED·LEA·HIGHT이며 AES는 목록에 없다
• 컬럼을 암호화하면 동등 비교 외의 검색·정렬이 막힌다. 블라인드 인덱스로도 LIKE와 범위 조건은 대체되지 않는다
• 키 관리 절차를 요구하는 조문은 제7조제6항이고 규모 요건이 붙는다. 키를 잃으면 데이터를 잃는다