개인정보 보호 실전 가이드: 마스킹·DB암호화·설정값암호화
화면·로그 노출은 마스킹으로, DB에 저장되는 데이터는 컬럼 암호화로, 설정 파일의 민감값은 ENC() 방식으로 막는 3계층 개인정보 보호 방법을 정리합니다.
들어가며
개인정보 유출 사고가 발생하면 흔히 외부 해킹 공격만을 원인으로 떠올리기 쉽습니다. 그러나 실제 현장에서의 유출 경로는 훨씬 다양합니다.
API 응답에 필요 이상으로 포함된 민감 필드, 개발 편의를 위해 남겨둔 로그 출력, 형상 관리 도구에 그대로 커밋된 DB 접속 패스워드, 운영 환경에서 무심코 활성화된 쿼리 로그 등은 모두 의도치 않은 노출의 경로가 될 수 있습니다.
이러한 다양한 유출 경로를 막기 위해서는 단일 보안 조치만으로는 충분하지 않고, 데이터가 생성되고 저장되며 응답으로 나가는 전 구간에 걸쳐 마스킹, 암호화, 설정값 보호 등 여러 계층의 방어 수단을 갖추는 것이 중요합니다. 각 구간별 개인정보 보호 방법과 관련 구현 방식을 살펴보겠습니다.
마스킹
개인정보가 가장 빈번하게 노출되는 경로는 화면입니다. 콜센터 상담 화면이나 관리자 조회 화면에 주민등록번호와 계좌번호가 원문 그대로 표시되면, 화면 캡처나 사진 촬영 등으로 수백 건의 개인정보가 유출될 수 있습니다.
로그 파일도 마찬가지로, 디버깅 목적으로 개인정보를 로그에 출력하면 운영팀이나 인프라 접근 권한을 가진 인력까지 해당 정보에 접근할 수 있습니다.
프로젝트마다 마스킹 규칙은 다를 수 있지만, 일반적으로 아래와 같은 표현을 사용하며 어느 부분을 *로 처리할지는 협의하여 진행할 수 있습니다.
| 유형 | 원본 | 마스킹 결과 | 규칙 |
|---|---|---|---|
| 이름 | 홍길동 | 홍*동 | 2자 이상: 가운데 마스킹 |
| 주민등록번호 | 901225-1234567 | 901225-1****** | 뒷자리 6자리 마스킹 |
| 계좌번호 | 110-2345-6789-01 | 110-****-****-01 | 중간 8자리 마스킹 |
| 카드번호 | 1234-5678-9012-3456 | 1234-****-****-3456 | 중간 8자리 마스킹 |
| 휴대폰번호 | 010-1234-5678 | 010-****-5678 | 가운데 4자리 마스킹 |
| 이메일 | user@example.com | us**@example.com | ID 3자 초과분 마스킹 |
| 주소 | 서울시 강서구 마곡중앙8로 | 서울시 강서구 *** | 시구 이하 마스킹 |
마스킹은 주로 아래의 방식을 사용합니다.
1) 직렬화 시점
- 어노테이션을 활용하여 비즈니스 로직 내부에서는 원본 값을 그대로 사용하고, API 응답 시점에만 가려지는 구조입니다.
- 별도의 변환 로직 없이 어노테이션 선언만으로 적용이 가능해 구현 부담이 가장 낮습니다.
2) 메서드 반환 시점
- 서비스 레이어의 메서드가 값을 돌려주는 순간에 AOP로 반환 객체를 가로채 마스킹을 적용합니다.
3) 직접 호출
- 마스킹 유틸을 개발자가 명시적으로 호출하는 방식으로, 로그 출력, 외부 시스템 연동, 알림 메시지 조합 등 자동화하기 어려운 상황에서 사용됩니다.
주의할 점은, 마스킹된 값을 DB에 저장하거나 검색 조건으로 사용하면 원문 복원이 영구적으로 불가능해진다는 것입니다. 설계 시 이를 고려해야 합니다.
DB암호화
개인정보는 API 응답뿐 아니라 DB에 저장되는 순간에도 보호가 필요합니다. 복호화 키를 확보하지 않고서는 DB를 직접 조회해도 의미 있는 정보를 얻을 수 없으므로, 개인정보 저장 시 필수적으로 반영해야 할 부분입니다.
DB 암호화는 크게 두 가지 방식을 사용합니다.
1) MyBatis Interceptor
- SQL 실행 직전과 직후에 개입하는 구조로, Interceptor 인터페이스를 구현하여 쿼리 파라미터 바인딩 시점에 암호화, 결과셋 매핑 시점에 복호화를 자동으로 처리해 줍니다.
- TypeHandler를 활용하여 컬럼 단위로 암호화 적용 여부를 세밀하게 제어할 수 있고, Mapper XML이나 비즈니스 로직을 수정하지 않고도 암복호화 계층을 삽입할 수 있다는 점이 이 방식의 강점입니다.
2) AOP 방식
- 메서드 단위로 암호화 대상을 지정합니다. DTO 필드의 어노테이션으로 구분하여 파라미터를 암호화하고 반환값을 복호화합니다.
- Interceptor 방식과 달리 특정 메서드에만 선택적으로 적용할 수 있어 기존 시스템에 점진적으로 도입할 때 유리합니다.
두 방식 모두 암호화 알고리즘 자체는 별도의 유틸로 위임하는 것이 일반적입니다. 이에 대해서는 다음 섹션에서 다룹니다.
정보통신망법, 개인정보보호법에서 암호화를 요구하는 개인정보의 종류와 적용할 수 있는 암호 기술은 아래와 같습니다.
| 암호화해야 하는 개인정보 | 정보통신망법 | 개인정보보호법 | 적용 암호기술 |
|---|---|---|---|
| 비밀번호 | O | O | 해시함수 |
| 바이오정보 | O | O | 블록암호 |
| 주민등록번호 | O | O | |
| 신용카드번호 | O | O | |
| 계좌번호 | O | O | |
| 여권번호 | O | O | |
| 운전면허번호 | O | O | |
| 외국인등록번호 | O | O |
[출처] https://seed.kisa.or.kr/kisa/bbs/faq.do
암호화 알고리즘
| 구분 | 알고리즘 | 권장 판단 | 출처 |
|---|---|---|---|
| 대칭키 | AES-128/192/256 | 신규 구축 권장 | FIPS 197 AES 공식, PDF |
| AES-GCM, GMAC | 인증암호·무결성 모드 권장 | NIST SP 800-38D 공식, PDF | |
| ARIA-128/192/256 | 국내 공공·KCMVP 연계 시 사용 가능 | KISA ARIA | |
| LEA-128/192/256 | 국내 경량·고속 환경에서 사용 가능 | KISA LEA | |
| SEED-128 | 국내 레거시·상호운용 목적 중심 | KISA SEED | |
| DES, TDEA/3DES | 신규 사용 지양·제한 | NIST SP 800-131A Rev.2 공식, PDF | |
| 비대칭키 | RSA 2048 이상, 장기 보관용 RSA 3072 이상 | 권장 최소선 | NIST SP 800-131A Rev.2, PDF |
| ECDSA, EdDSA | 전자서명 권장 | FIPS 186-5 공식, PDF | |
| KCDSA, EC-KCDSA | 국내 전자서명 알고리즘 | KISA KCDSA/EC-KCDSA | |
| ML-KEM, ML-DSA, SLH-DSA | 양자내성 전환 검토 | FIPS 203, FIPS 204, FIPS 205 | |
| RSA 2048 미만, 신규 생성 DSA | 지양 | NIST SP 800-131A Rev.2, FIPS 186-5 | |
| 해시 | SHA-256/384/512 | 권장 | FIPS 180-4 공식, PDF |
| SHA3-256/384/512 | 권장 | FIPS 202 공식, PDF | |
| LSH | 국내 해시 알고리즘 | KISA LSH | |
| MD5, 서명 생성용 SHA-1 | 지양 | NIST SP 800-131A Rev.2, PDF |
DB 암호화 로직 내부에서 실제 암복호화를 수행하는 것은 알고리즘 구현체입니다. 그런데 각 구현체를 호출부에서 직접 참조하면 알고리즘을 교체할 때마다 호출 코드를 전부 수정해야 하는 문제가 생깁니다.
이를 해결하는 일반적인 방법이 EncryptUtil과 같은 단일 인터페이스를 만들어 두는 것입니다. 호출부는 encrypt(type, value), decrypt(type, value) 형태의 단일 메서드만 사용하고, 내부에서 type 파라미터를 기반으로 AES-256, ARIA, RSA 등 적절한 구현체로 분기합니다.
이 구조는 몇 가지 실용적인 이점을 갖습니다. 알고리즘을 교체하거나 추가할 때 구현체만 수정하면 되고, 호출부 코드는 변경이 없습니다. 또한 단위 테스트 시 type 값만 바꿔 여러 알고리즘에 대한 검증을 통합적으로 수행할 수 있습니다.
DevOn Framework는 국내 금융·공공 환경에서 요구하는 ARIA 알고리즘을 포함한 암호화 유틸을 제공하며, AES-256, RSA 등 범용 알고리즘도 동일한 인터페이스로 사용할 수 있도록 구성되어 있습니다.
설정값 암호화
DB 비밀번호, API 키, 외부 서비스 접속 정보 등 민감한 설정값이 application.yml에 평문으로 저장된 채 Git에 올라가는 상황은 실제로 흔히 발생합니다. 설정값 암호화는 이 위험을 줄이는 가장 직접적인 수단입니다.
주로 아래의 방식을 사용합니다.
1) ENC() 방식
- Jasypt 라이브러리를 기반으로 하여 암호화된 문자열을
ENC(...)형태로 설정 파일에 저장해두면, 애플리케이션이 기동하는 시점에 Jasypt Decryptor가 자동으로 복호화하여 Spring Environment에 원본 값을 주입합니다. - 이 방식의 전제 조건은 복호화에 사용하는 마스터 패스워드를 설정 파일 외부에서 관리하는 것입니다. 마스터 패스워드까지 같은 저장소에 포함된다면 암호화의 의미가 사라집니다.
2) KMS 연동 방식
- AWS KMS, GCP Cloud KMS, Azure Key Vault와 같은 클라우드 키 관리 서비스를 활용합니다. 암호화 키 자체가 코드베이스나 서버 파일시스템에 존재하지 않으므로 보안 수준이 높고, 키 접근에 대한 감사 로그를 남길 수 있습니다.
- 반면 외부 서비스 호출이 발생하므로 네트워크 지연과 가용성 의존성이 생깁니다. 이를 보완하기 위해 서버 기동 시 키를 조회한 후 메모리에 적재하여 사용합니다.
3) 환경변수 주입 방식
- 운영체제나 컨테이너 오케스트레이터(Kubernetes Secret, ECS TaskDefinition 등)가 실행 환경에 민감 값을 주입하고, 애플리케이션은
@Value어노테이션으로 이를 참조합니다.
세 방식 중 어느 것을 선택할지는 인프라 환경, 팀 규모, 규제 요건에 따라 달라집니다.
DevOn Framework는 Jasypt 기반의 ENC() 통합을 기본으로 제공하면서, KMS나 환경변수 방식과도 함께 사용할 수 있는 유연한 구성을 지원합니다.
마치며
개인정보 보호는 단일 기술의 문제가 아닙니다. 마스킹은 노출 경로를, DB 암호화는 저장 경로를, 설정값 암호화는 코드 관리 경로를 각각 방어합니다. 이 세 계층이 서로 보완하며 동작할 때 비로소 전체적인 방어가 성립합니다.
현실적으로는 모든 것을 처음부터 완벽하게 갖추기보다, 가장 노출 위험이 높은 지점부터 순차적으로 적용해가는 접근이 실현 가능합니다. 어떤 데이터가 어떤 경로로 이동하는지를 먼저 파악하고, 각 구간에 적합한 보호 수단을 배치하는 것이 출발점입니다.
DevOn은 여러 프로젝트에서 위에 언급한 각 계층의 정보보호를 위한 마스킹, DB암호화, 설정값 암호화 등을 지원하고, 필요 시 고객사 내부에서 사용하는 암호화 처리 library의 적용도 유연하게 대체 가능하여 개발의 편의성과 정보보호의 안정성을 제고할 수 있습니다.
※ 본 게시글의 이미지는 AI를 활용해 제작되었습니다.