DB 암호화 방식(API, Plug-In, Hybrid, TDE) - Types of Database Encryption Methods

개요

DB 내 개인정보 및 민감정보 보호를 위한 암호화 방식은 보안성과 운영 편의성, 시스템 구조에 따라 다양하게 구분된다.

컬럼 암호화 방식 - Plug-In, API, Hybrid(Plug-In + API)
블록 암호화 방식 - TDE

본 포스팅에서는 암호화 적용 범위에 따라 크게 컬럼 암호화 방식, 블록 암호화 방식 두 방식으로 나누어 설명하며, 위와 같이 세부적인 방식들의 개념과 동작 원리를 이해해 볼 것이다.

---

컬럼 암호화

컬럼 암호화 방식이란 특정 열(Column) 단위로 암호화를 적용하는 방식

ex) 주민등록번호, 카드번호, 계좌번호와 같은 민감 데이터 컬럼만 암호화

기본적으로 컬럼 암호화 방식에서의 암호 알고리즘은 모두 SHA-256/384/512 및 키 길이 128bit 이상의 AES, 3DES, SEED, ARIA 등을 지원한다.

컬럼 암호화 방식에는 아래와 같이 총 3가지가 존재한다.

방식	운영 형태	특징
Plug-In	DB 서버	구축 시 일부 애플리케이션 수정이 필요하며 DB 서버의 성능에 대한 검토 필요
API	DB & 애플리케이션 서버	Plug-In 방식에 비해 DB 서버에 영향을 주지 않으나 구축 시 애플리케이션의 수정 필요
Hybrid	DB & 애플리케이션 서버	Plug-In과 API 방식이 조합된 형식

---

1. Plug-In 방식

• 암·복호화 모듈을 DB 서버 내·외부에 설치하고, 이 곳에서 암·복호화를 수행하는 구조
• 애플리케이션 코드를 수정할 필요가 없음

  동작 구조 : Application → SQL 실행 → Plug-in 모듈이 암·복호화 → DBMS

보통 가이드들에선 플러그인을 DB 서버 내부에 설치하여 진행한다고 되어있는데
현업에선 내·외부 모두 설치하여 이용할 수 있다고 한다.

Plug-In 위치	암·복호화 수행 주체	보안 위험
DBMS 내부	DB 서버	낮음 (상대적으로 안전)
DB 클라이언트	애플리케이션 서버	높음 (계정/키 탈취 시 평문 유출)

WAS에 Plug-In이 설치되어 있다고 가정했을 때 WAS는 사용자 요청을 처리하기 위해 DB에 접근해서 데이터를 조회하거나 저장하거나 하는데, 이때 WAS가 DB에 접속할 수 있도록 하기 위해 DB 계정과 비밀번호 정보를 가지고 있어야 한다.

WAS의 설정 파일에 DB 접속 정보가 하드코딩 돼있거나 환경변수로 지정되어 있을 때,
이 DB 계정 정보가 유출이 된다면 공격자는 평문을 얻을 수 있는 상황이 된다.

실제로도 위와 같은 이유로 DBMS 내부에 설치하여 암·복호화를 수행하는 방식을 많이 이용한다고 한다. 그래서 가이드에서도 애초에 보안적인 측면에서 위험도가 있는 방법을 아예 삭제시킨 게 아닐까 하는 생각이 든다.

장점

• 애플리케이션 수정이 거의 없음
  • 암복호화가 SQL 처리 과정 중 Plug-in에 의해 자동으로 이루어짐
  • 예외 처리, 데이터 타입 등 일부 보완을 위해 약간의 수정은 존재할 수 있음

단점

• Plug-In 이 어디 설치되느냐에 따라 보안성이 달라짐
  • 클라이언트에 설치되면 공격자가 복호화 가능

---

2. API 방식

• 애플리케이션에서 직접 암·복호화 API를 호출하여 데이터를 처리하는 방법
  • ex) encrypt(value), decrypt(value) 같은 함수 호출

    동작 구조 : Application → 암·복호화 API 호출 → 암호화된 데이터 DB 저장

API 방식에서의 암·복호화는 애플리케이션 코드 안에서 직접 수행된다.
암·복호화 로직이 코드로 직접 구현되거나, 암호화 모듈을 호출하는 방식이다.

예를 들어, 사용자가 주민등록번호를 입력하고 전송했을 때 애플리케이션 코드에서 암호화가 진행되고 출력된 암호문을 DB에 저장시킨다. 조회 시 애플리케이션에서 암호문을 불러와 복호화하는 방식이다.

위 내용을 봤을 때 한 가지 의문이 들었었는데 클라이언트가 개인정보를 전송했을 때 입력 값이 WEB을 거쳐 WAS에 도달할 때까지 평문 상태로 이동하게 되는 문제이다. 이 문제는 따로 HTTPS(SSL)나 VPN 등으로 구간 암호화를 진행하면 되겠다고 생각이 들었다. 꼬리에 꼬리를 무는 보안...

장점

• 암호화 대상과 범위를 개발자가 완전히 통제 가능
• 데이터 처리 전 암호화되므로 가장 강력한 보안성 제공

단점

• 애플리케이션 코드 대폭 수정 필요
• 운영 중인 서비스엔 적용 난이도가 높음
  • 차세대 시스템 개발 등에 기존 어플리케이션에 대한 전면적인 수정이 가능한 경우 적용

---

3. Hybrid 방식

• 암·복호화는 기본적으로 Plug-In 방식으로 처리되지만,
  복잡한 경우나 일부 민감 컬럼은 API 방식으로 우회처리하는 방식

일반 SQL은 Plug-In이 처리하고 특정 중요 컬럼은 애플리케이션이 직접 API 호출로 암호화하는 흐름이다.

Hybrid 방식 예시(Java + JDBC)(완전한 코드 아님!)

// 주민번호는 API 방식으로 직접 암호화
String rrnPlain = "000101-1234567";
String encryptedRRN = Encryptor.encrypt(rrnPlain); // 직접 암호화 수행

// 전화번호는 Plug-in 방식으로 처리되므로, 그냥 평문으로 넣음
String name = "뭉치치";
String phone = "010-1234-5678";

// SQL 구성 (Plug-in이 개입할 수 있도록 일반 SQL 그대로 사용)
String query = "INSERT INTO 고객 (이름, 전화번호, 주민번호) VALUES (?, ?, ?)";

try (Connection conn = dataSource.getConnection();
     PreparedStatement pstmt = conn.prepareStatement(query)) {

    pstmt.setString(1, name);               // 평문
    pstmt.setString(2, phone);              // 평문 (Plug-in이 암호화)
    pstmt.setString(3, encryptedRRN);       // 암호문 (API 직접 암호화)

    pstmt.executeQuery();
}

위와 같이 고객이라는 테이블에 이름, 전화번호, 주민번호를 삽입하는 SQL 쿼리를 예를 들었는데,
개인정보보호법에 따르면 이름, 전화번호는 반드시 암호화해야 하는 정보가 아니다.

그러나 다른 정보와 결합하여 개인을 식별할 수 있다면 그것은 개인정보가 되기도 하고,
기본적으로 개인정보처리자는 안전성 확보에 필요한 기술적·관리적 및 물리적 조치를 해야 한다.

모든 개인정보를 암호화하는 경우 보호 수준은 높아질 수 있으나 개인정보 처리자의 부담은 커지므로 전화번호 정도는 Plug-In 방식으로 암호화를 진행 후 DB에 저장하고, 주민등록번호는 따로 내부적으로 정한 암호화 API로 암호화하여 암호문을 바인딩 해서 DB에 저장하는 방식으로 필자는 Hybrid 방식에 대해 예를 들었다.

(잘못된 예시인 경우 댓글로 지적해주시면 감사하겠습니다😅😂)

장점

• 애플리케이션 수정을 최소화하면서 민감 정보는 더 강하게 보호
• 유연성과 보안성을 동시에 고려할 때 사용

단점

• 구조가 복잡해지고, 관리 포인트가 증가
• Plug-In과 API 모두 관리해야 하기에 운영에 대한 이슈가 발생할 가능성 존재

---

블록 암호화

블록 암호화 방식이란 데이터를 저장소에 저장할 때
저장단위(블록 or 파일)를 기준으로 암호화하는 방식

블록 암호화 방식 중에선 TDE 라는 방식을 이해해 볼 것이다.

방식	운영 형태	특징
TDE	DB 서버	어플리케이션 수정 필요 없음, 기존 시스템에 영향이 적고 성능이 뛰어나지만 DBMS 종류 및 버전에 따른 지원 가능 여부 확인 필요

TDE 방식에서 암호 알고리즘은 SHA-256/384/512 및 키 길이 128bit 이상의 AES, 3DES 등을 지원한다.

---

1. TDE 방식

• DB에서 데이터를 디스크에 저장될 때 자동으로 암호화하고, 읽을 때 자동으로 복호화하는 방식

암호화 대상

TDE는 보통 아래와 같은 저장 단위(Block)에 적용된다.

암호화 대상	설명
테이블 스페이스	전체 테이블이 저장된 논리적인 영역
DB File	DB가 물리적으로 저장되는 파일
로그 파일	redo 로그, 백업 로그 등
백업 파일	백업 덤프 파일도 암호화 가능

동작 흐름

1. 애플리케이션이 평문 데이터를 SQL로 전송
2. DBMS가 데이터를 디스크에 쓸 때 자동으로 암호화
3. 디스크에선 암호문 형태로 저장
4. SELECT로 데이터를 읽으면 DBMS가 자동 복호화 후 평문 전달

위 동작 흐름을 보면 개발자는 암호화된 줄도 모를 정도로 무관심하게 사용할 수 있다.
근데 저 흐름을 봤을 때 한가지 의문점이 든다.

WAS ↔ DB 구간의 데이터는 평문 노출 가능성이 생기는 것이다.

따로 저 구간도 암호화를 하면 되겠지만 위에서 배운 내용을 기반으로 좋은 방식이 하나 떠올랐다.

바로 TDE + API 를 조합하는 방식이다.
민감한 데이터에 대해 WAS→DB 전송 전에 API 방식으로 애플리케이션 레벨에서 암호화하고,
TDE 방식으로 암호화하여 디스크에 저장하면 해당 구간에서의 평문 노출은 없을 것이다.

이 방식은 실무에서도 많이 쓰이고, 금융권이나 공공기관에선 필수적인 보안 절차로 간주된다고 한다.

물론 쿼리 구조 자체가 노출이 된다거나, 암호화 하지 않은 일반 컬럼들이 노출이 될 가능성이 존재하여 네트워크 구간을 따로 암호화를 적용하는 경우가 많다.

장점

• 기존 시스템 수정이 거의 필요 없어서 설치/적용이 간단
• 운영/유지보수가 편함

단점

• 중요한 컬럼만 따로 암호화하는 것은 불가
• DB 계정이 탈취되면 평문의 노출 위험이 존재

---

마치며

사실 DB 암호화에 대해 깊이 생각해 본 적은 없었다.

그저 DB에는 정보가 있으니 암호화가 중요하다는 정도는 알고 있었고, 어떤 방식이 있는지, 어떻게 적용이 되는지에 대해 구체적으로 고민한 적은 없었다.

회사 업무를 진행하다가 얼떨결에 공부하게 되었는데, 이렇게 깊은 내용들이 있었고, 이 내용들이 하나씩 이해가 되기 시작하면서 DB 암호화의 중요성을 더욱 느끼게 되었다.

DB 암호화 방식에 여러 가지가 있다는 것을 알게 되었고,
단일 방식만 사용했을 때 발생하는 문제점들이 무엇이 있을까에 대해 생각해 보았고,
그 문제점들을 해결하기 위해 어떤 방식을 하이브리드로 조합해야 할 지도 생각해 볼 수 있는 좋은 기회가 되었다.