DP-300 시험에서 데이터 보호 파트는 '어떤 기능이 어떤 위협을 막는가'를 묻습니다. 저장 중 암호화, 전송 중 암호화, 클라이언트 측 암호화, 네트워크 격리는 각각 다른 위협을 방어합니다. 기능마다 키 관리 방식과 DBA의 가시성이 달라지고, 시험은 그 차이를 시나리오로 물어봅니다. 이 글에서는 각 기술이 어떤 상황에서 쓰이는지 사례를 중심으로 살펴봅니다.
TDE — 금고 안에 잠그는 암호화
회사 서버실에 물리적으로 침입한 공격자가 하드 드라이브를 통째로 들고 나갔다고 상상해보세요. 데이터 파일을 그대로 다른 컴퓨터에 연결하면 내용을 읽을 수 있을까요? TDE(Transparent Data Encryption)는 바로 이 시나리오를 막기 위한 기능입니다.
TDE는 Azure SQL Database의 데이터 파일, 로그 파일, 백업 파일을 페이지 단위로 자동 암호화합니다. 애플리케이션은 코드를 한 줄도 바꾸지 않아도 되고, 쿼리 성능에도 거의 영향이 없습니다. Azure SQL Database에서는 TDE가 기본으로 활성화되어 있습니다. 기본 설정에서는 Azure가 암호화 키를 직접 관리하는 Service-Managed Key 방식을 씁니다. 규정이나 감사 요건으로 키를 직접 통제해야 한다면 Azure Key Vault에 저장한 자체 키를 사용할 수 있습니다. 이를 Customer-Managed Key(CMK), 또는 BYOK(Bring Your Own Key)라고 부릅니다. CMK를 선택하면 키 교체·폐기 권한이 운영팀에 있고, 키를 삭제하면 데이터베이스 접근이 즉시 차단됩니다.
Always Encrypted — 봉인된 편지
이번에는 공격자가 외부인이 아니라 DBA 계정을 탈취한 내부 위협이라고 가정해봅시다. TDE는 디스크를 통째로 들고 나가는 시나리오는 막지만, 정상 접근 권한이 있는 쿼리에서 평문 데이터를 조회하는 것까지는 막지 못합니다. Always Encrypted는 이 빈자리를 채웁니다.
Always Encrypted는 클라이언트 드라이버가 데이터를 암호화해서 서버에 보냅니다. 서버는 암호화된 값만 저장하고 쿼리하며, 복호화 키는 클라이언트 측에만 있습니다. DBA가 직접 SELECT를 실행해도 암호화된 바이트만 볼 수 있습니다.
암호화 방식은 두 가지입니다. Deterministic은 같은 값이 항상 같은 암호문으로 변환되어 동등 비교()와 GROUP BY·JOIN이 가능하지만 빈도 분석에 취약합니다. Randomized는 같은 값도 매번 다른 암호문을 생성해 보안이 더 강하지만 해당 컬럼으로 검색·정렬을 할 수 없습니다. Always Encrypted with Secure Enclaves를 사용하면 서버 측 신뢰 실행 환경(TEE) 안에서 복호화가 일어나므로 Randomized 컬럼으로도 범위 쿼리(, )가 가능합니다.
전송 중 암호화 — TLS와 연결 문자열
은행 ATM에서 계좌 번호를 입력할 때 화면이 어깨 너머로 보이면 곤란하듯, 클라이언트와 데이터베이스 서버 사이 네트워크 트래픽도 중간에서 가로채지 않도록 암호화해야 합니다.
Azure SQL Database는 TLS 1.2 이상을 기본으로 강제합니다. 연결 문자열에 를 설정하면 모든 데이터가 암호화된 채널로 이동합니다. (기본값)로 두면 클라이언트가 서버 인증서를 검증하므로 중간자 공격을 방어합니다. 개발 환경에서 자체 서명 인증서를 쓸 때 이 값을 로 바꾸는 경우가 있는데, 프로덕션에서는 절대 권장하지 않습니다.
네트워크 격리 — Private Link와 Private Endpoint
공용 인터넷을 통해 데이터베이스에 접속하는 것 자체를 막고 싶다면 어떻게 할까요? 건물 로비에 누구나 들어올 수 있게 두는 것보다, 출입증이 있는 직원만 진입할 수 있는 사무용 건물이 처음부터 더 안전합니다.
Private Link와 Private Endpoint를 사용하면 Azure SQL Database가 VNet 내부의 사설 IP 주소를 얻습니다. 공용 Endpoint를 완전히 비활성화할 수 있고, 트래픽이 Microsoft 백본 네트워크 안에서만 이동합니다. Azure SQL Managed Instance는 VNet 통합이 기본이라 처음부터 공용 엔드포인트가 없습니다. Private Endpoint를 구성한 후에는 방화벽 규칙에서 공용 네트워크 액세스를 '거부'로 설정하면 공용 경로를 완전히 차단할 수 있습니다.
TDE vs Always Encrypted — 무엇이 다른가
같은 '암호화'라는 이름이지만 두 기능은 방어하는 위협이 다릅니다.
| 구분 | TDE | Always Encrypted | |:--|:--|:--| | 암호화 위치 | 서버(스토리지 계층) | 클라이언트 드라이버 | | 키 소유자 | Azure 또는 운영팀(CMK) | 애플리케이션 팀 | | DBA 가시성 | 평문 조회 가능 | 암호문만 보임 | | 쿼리 가능성 | 제한 없음 | Deterministic만 동등 비교 | | 주요 위협 | 물리적 매체 탈취, 백업 유출 | 내부자 위협 |
두 기능은 서로 배타적이지 않습니다. TDE로 저장 데이터를 보호하면서 특히 민감한 컬럼(주민번호, 카드번호 등)에는 Always Encrypted를 추가로 적용하는 구성이 실무에서 흔합니다.
!TDE vs Always Encrypted
암호화 범위와 키 관리 — 실무에서 선택하는 기준
집 전체를 잠그는 것과 귀중품 금고를 따로 두는 것은 다른 수준의 보안입니다. TDE는 집 전체 잠금과 같고, Always Encrypted는 그 안에 별도로 잠긴 금고와 같습니다. 둘 다 쓰면 외부 침입자도 내부 관리자도 막을 수 있습니다.
키 관리 측면에서는 TDE의 Customer-Managed Key가 Azure Key Vault와 연동되어 키 수명 주기를 운영팀이 완전히 제어합니다. Always Encrypted의 컬럼 마스터 키(CMK)는 애플리케이션 측 인증서 저장소나 Azure Key Vault에 보관되며, 데이터베이스 관리팀이 아닌 애플리케이션 팀이 소유합니다. 이처럼 키 소유권이 다르기 때문에, 두 기능을 함께 쓸 때는 팀 간 역할 분리가 명확해집니다.
함정 시나리오 — 시험이 자주 묻는 선택
"DBA가 쿼리해도 컬럼 값을 볼 수 없어야 한다"는 요건은 TDE가 아니라 Always Encrypted가 답입니다. TDE는 DBA의 정상 접근을 차단하지 않습니다. "회사 보안 정책상 암호화 키를 자체적으로 관리해야 한다"면 TDE의 Customer-Managed Key(BYOK)를 Azure Key Vault와 함께 쓰는 구성이 답입니다.
"백업 파일이 유출되어도 데이터가 노출되면 안 된다"는 시나리오는 TDE가 백업 파일도 암호화하므로 답이 TDE입니다. Always Encrypted는 이 시나리오와 직접 연관이 없습니다. "공용 인터넷 경로를 완전히 차단하고 싶다"면 Private Endpoint 또는 Azure SQL Managed Instance(VNet 기본 통합)가 답입니다. TLS 암호화는 경로를 차단하는 게 아니라 경로를 보호하는 기능입니다.
시험 핵심 정리
"저장 데이터 암호화, 코드 변경 없음" -- TDE "백업·로그 파일도 자동 암호화" -- TDE "키를 직접 관리, Azure Key Vault 연동" -- Customer-Managed Key (BYOK) "DBA도 평문 못 봄, 클라이언트 측 암호화" -- Always Encrypted "동등 비교 가능, 빈도 분석 취약" -- Deterministic 암호화 "검색 불가, 보안 강함" -- Randomized 암호화 "Randomized 컬럼에서도 LIKE·범위 쿼리" -- Always Encrypted with Secure Enclaves "전송 중 암호화, 인증서 검증" -- TLS 1.2+, Encrypt=true "공용 Endpoint 완전 차단, 사설 IP" -- Private Link / Private Endpoint "VNet 통합 기본, 공용 엔드포인트 없음" -- Azure SQL Managed Instance "물리적 매체 탈취 방어" -- TDE "내부자 위협, 권한 있는 사용자 차단" -- Always Encrypted
TDE = 저장소 계층 잠금, Always Encrypted = 클라이언트 측 봉인, TLS = 전송 경로 보호, Private Link = 네트워크 경로 차단.