SQL Server (MSSQL) 암호화 실무 가이드

---

구성 방법 · 도입 고려점 · 체크사항 · 주의점까지 “암호화의 모든 것”

---

0. 이 글의 범위(중요)

이 글은 온프레미스 SQL Server(일반적으로 2019/2022 이상) 기준으로, 실무에서 가장 많이 쓰는 암호화 옵션을 도입 판단 → 구성 절차 → 운영/복구 체크리스트 순서로 정리합니다.

핵심 결론:

• “파일 유출(디스크/백업)” 대응이 목적이면 TDE + 백업 암호화
• “DBA/운영자도 평문을 못 보게”가 목적이면 Always Encrypted
• “레거시/특수 요구로 T-SQL로 직접 제어”가 목적이면 셀 수준(대칭키) 암호화
• 그리고 네트워크 구간(TLS) 은 별도로 반드시 고려해야 합니다.

---

1. 암호화는 ‘무엇을’ 막고, ‘무엇을’ 못 막나

1.1 암호화가 강한 영역

• 디스크/백업 파일 탈취: 파일 자체가 암호화되어 있으면 유출 피해를 크게 줄임
• 네트워크 도청: TLS로 서버-클라이언트 사이 패킷을 암호화
• 권한 분리(Zero Trust): Always Encrypted는 서버(및 DBA)가 키/평문에 접근하지 못하도록 설계 가능

1.2 암호화만으로 해결되지 않는 영역(현실 체크)

• 권한이 과도한 계정(sysadmin 등), 취약한 앱 계정 관리, SQL Injection, 데이터 접근 통제 부재는 암호화만으로 해결되지 않습니다.
• 암호화는 “마지막 방어선”이 아니라, 권한/감사/접근통제와 함께 설계해야 합니다.

---

2. SQL Server 암호화 지형도: 3개 레이어로 나누면 설계가 쉬워진다

2.1 At Rest (휴지 상태) — 파일/백업 보호

• TDE(Transparent Data Encryption): 데이터/로그 파일(그리고 TDE 적용 DB의 백업)을 암호화
• 백업 암호화(Backup Encryption): BACKUP ... WITH ENCRYPTION 으로 백업 파일 자체를 암호화 (TDE와 별개로 적용 가능)

2.2 In Transit (전송 구간) — TLS로 네트워크 암호화

• 서버 인증서 기반 TLS 구성
• 클라이언트 연결 옵션/드라이버 옵션까지 포함

2.3 In Use (사용 중/데이터 접근 레벨) — 컬럼/셀 단위 보호

• Always Encrypted: 클라이언트 측 암/복호화(서버는 키/평문을 모르게 설계 가능)
• 셀 수준(대칭키) 암호화: EncryptByKey/DecryptByKey 등 T-SQL로 직접 제어(서버에서 복호 가능)

---

3. 도입 전 “결정” 체크리스트 (이거 안 하면 나중에 무조건 고생합니다)

3.1 요구사항 정의(반드시 문서화)

• 어떤 데이터가 민감정보(PII/PHI/급여/계약/계정) 인가?
• 위협 모델은 무엇인가?
• 디스크/백업 유출?
• 네트워크 도청?
• 운영자(내부자) 접근 차단?
• 복구/DR 요구사항:
• “백업으로 다른 서버에 복구할 수 있어야 함”
• “재해복구 사이트에서도 복호 가능해야 함”
• 성능 영향 허용치:
• OLTP인지, DW/ETL인지, CPU 여유는 있는지

3.2 키/인증서 관리가 “성공의 80%”

암호화는 기술보다 키 관리가 어렵습니다.

• 키/인증서 백업 위치(오프사이트)
• 접근 권한(누가 키를 볼 수 있는가)
• 회전(rotate) 전략(연 1회? 6개월? 규제 기준?)
• 폐기/교체 절차(사고 대응 포함)
  이걸 먼저 합의하지 않으면, 운영 중 사고 때 복구가 막힙니다.

---

4. TDE (Transparent Data Encryption) — “파일/백업 유출” 방어의 기본

4.1 TDE가 적합한 상황

• 노트북/서버 디스크 분실, 스토리지 반출, 백업 유출 등 ‘파일 단위 유출’ 위험이 크다
• 앱 수정 없이 빠르게 “at rest encryption” 요구사항을 맞춰야 한다
• DBA가 평문을 보면 안 되는 요구는 TDE만으로는 충족하기 어렵다(엔진 내부에서는 평문으로 처리)

4.2 TDE 구성 절차 (표준 단계)

개념: master의 인증서/키가 사용자 DB의 DEK(Database Encryption Key) 를 보호하고, DEK가 데이터/로그 파일을 암호화합니다.

4.2.1 (1) master: DMK + TDE 인증서 생성

USE master;
GO

-- 1) DMK (이미 있다면 생략)
-- 운영에선 비밀번호를 안전한 금고에 저장하세요.
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Replace_With_A_Strong_Password!';
GO

-- 2) TDE 인증서
CREATE CERTIFICATE TdeServerCert
    WITH SUBJECT = 'TDE Server Certificate';
GO

4.2.2 (2) 대상 DB: DEK 생성 + 암호화 ON

USE [SalesDB];
GO

CREATE DATABASE ENCRYPTION KEY
  WITH ALGORITHM = AES_256
  ENCRYPTION BY SERVER CERTIFICATE TdeServerCert;
GO

ALTER DATABASE [SalesDB] SET ENCRYPTION ON;
GO

4.2.3 (3) 상태 확인

SELECT
    d.name,
    dek.encryption_state,
    dek.percent_complete,
    dek.key_algorithm
FROM sys.dm_database_encryption_keys AS dek
JOIN sys.databases AS d
  ON d.database_id = dek.database_id
WHERE d.name = 'SalesDB';

4.2.4 (4) 인증서/개인키 백업 (필수)

이 단계가 빠지면, 다른 서버 복구/DR/마이그레이션에서 복호가 안 됩니다.

USE master;
GO

BACKUP CERTIFICATE TdeServerCert
  TO FILE = 'D:\KeyBackup\TdeServerCert.cer'
  WITH PRIVATE KEY (
    FILE = 'D:\KeyBackup\TdeServerCert_PrivateKey.pvk',
    ENCRYPTION BY PASSWORD = 'Replace_With_A_Strong_PrivateKey_Password!'
  );
GO

4.3 TDE 운영 체크포인트(실무에서 자주 터지는 지점)

• tempdb 암호화 영향: TDE를 사용하면 인스턴스의 tempdb도 암호화되는 동작/오버헤드를 고려해야 합니다.
• AG/DR/이관:
• TDE 적용 DB를 다른 인스턴스로 복구/복제하려면 해당 인스턴스에도 인증서를 가져와야 합니다.
• 키/인증서 분실 = 데이터 분실:
• 인증서/개인키 백업이 없으면 TDE 적용 백업을 복원할 수 없습니다.
• 모니터링:
• 암호화 진행률(percent_complete)
• 상태(encryption_state)
• 장애 시 이벤트 로그/에러 로그 점검

---

5. 백업 암호화(Backup Encryption) — “백업 파일 자체”를 확실하게 잠그는 방법

5.1 언제 쓰나?

• TDE를 쓰지 않더라도 백업 반출/보관이 위험한 환경
• 백업을 S3/Blob/외부 스토리지에 저장하는데 2차 방어선이 필요
• 규제에서 “백업 암호화”를 별도로 요구

5.2 구성 예시: 백업용 인증서 생성 + 백업 암호화

USE master;
GO

-- 1) 백업 암호화용 DMK (없으면 생성)
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Replace_With_A_Strong_Password!';
GO

-- 2) 백업 암호화용 인증서
CREATE CERTIFICATE BackupEncCert
   WITH SUBJECT = 'Backup Encryption Certificate';
GO

-- 3) 인증서 백업(복구 필수)
BACKUP CERTIFICATE BackupEncCert
  TO FILE = 'D:\KeyBackup\BackupEncCert.cer'
  WITH PRIVATE KEY (
    FILE = 'D:\KeyBackup\BackupEncCert_PrivateKey.pvk',
    ENCRYPTION BY PASSWORD = 'Replace_With_A_Strong_PrivateKey_Password!'
  );
GO

-- 4) 백업 실행(암호화)
BACKUP DATABASE [SalesDB]
TO DISK = 'D:\Backup\SalesDB_full_encrypted.bak'
WITH
    COMPRESSION,
    ENCRYPTION (
        ALGORITHM = AES_256,
        SERVER CERTIFICATE = BackupEncCert
    ),
    STATS = 5;
GO

5.3 복구 시 주의점

• 복구 대상 인스턴스에 인증서/개인키를 먼저 Import 해야 합니다.
• 백업 암호화는 TDE와 별개로 적용 가능하므로, 정책에 따라 “둘 다” 적용할 수도 있습니다.

---

6. 네트워크 암호화(TLS) — “전송 구간”은 별도로 잠가야 한다

6.1 왜 TLS가 기본인가?

• 데이터가 아무리 저장 시 암호화되어 있어도, 전송 중 평문이면 도청에 취약합니다.
• 특히 외부망/망분리/클라우드-온프렘 혼재 환경에서 필수입니다.

6.2 서버 설정(개요)

• 서버에 신뢰 가능한 인증서를 배치(인증서 주체명/대체이름이 서버 FQDN과 일치)
• SQL Server Configuration Manager에서 프로토콜 설정 및 Force Encryption 여부 결정
• 클라이언트 드라이버/연결문자열에서 Encrypt=True 등 옵션 적용

실제 절차는 인증서 배포 정책/AD CS 유무/운영 표준에 따라 달라지므로, 사내 PKI팀/보안팀과 함께 표준화하는 것을 권장합니다.

6.3 연결이 암호화되었는지 확인(현장 점검용)

SELECT
    session_id,
    encrypt_option,
    auth_scheme,
    net_transport,
    client_net_address
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

• encrypt_option = TRUE 면 현재 세션이 암호화 연결입니다.

---

7. Always Encrypted — “DBA도 평문을 못 보게” 하는 컬럼 암호화

7.1 Always Encrypted가 필요한 상황

• 운영자/DBA/외주 인력이 DB에 접근하더라도 민감 컬럼 평문을 보이면 안 된다
• 애플리케이션 단에서 민감 데이터 처리 책임을 분리하고 싶다
• 규정상 “관리자도 개인정보 열람 금지” 같은 요구가 있다

7.2 핵심 개념 요약

• 서버는 키/평문을 모르고, 클라이언트 드라이버가 암/복호화를 수행
• 암호화 타입:
• Deterministic(결정형): 동등 비교/조인/그룹핑 일부 가능(패턴 노출 위험은 고려)
• Randomized(무작위형): 보안성 높지만 검색/연산 제약이 큼

7.3 도입 전 체크(실무 필수)

• 드라이버/클라이언트가 Always Encrypted를 지원하는가?
• 연결문자열에 Column Encryption Setting=Enabled 적용 가능한가?
• 컬럼에 필요한 쿼리 패턴(=, IN, JOIN, LIKE, 범위조건)이 무엇인가?
• LIKE/범위조건이 필요하면 Always Encrypted 단독으로는 설계가 어렵고, 별도 검색 전략(토큰화/해시/보조 컬럼)이 필요할 수 있습니다.

7.4 구성 흐름(실무 표준)

1) CMK(Column Master Key): 외부 키 저장소(Windows Cert Store / Azure Key Vault / HSM 등)
2) CEK(Column Encryption Key): DB 메타데이터에 저장(실제 키 재료는 CMK로 보호)
3) 암호화 대상 컬럼 지정 및 데이터 암호화(도구/스크립트/Enclave 구성 여부에 따라 방식 상이)
4) 앱 연결 옵션 활성화 및 기능 테스트
5) 프로시저/파라미터 메타데이터 갱신(필요 시)

7.5 빠른 예제(앱 개발자/DBA 협업 기준)

7.5.1 예제 테이블

CREATE TABLE dbo.CustomerPII
(
    CustomerID      int IDENTITY(1,1) PRIMARY KEY,
    FullName        nvarchar(100) NOT NULL,
    NationalID      char(13) NOT NULL,     -- 암호화 후보
    Phone           varchar(20) NULL       -- 암호화 후보
);
GO

7.5.2 앱 연결문자열(.NET 예시)

Server=tcp:myserver,1433;Database=SalesDB;
Integrated Security=true;
Encrypt=True;TrustServerCertificate=False;
Column Encryption Setting=Enabled;

7.5.3 스키마 변경 후(필요 시) 파라미터 메타데이터 갱신

EXEC sys.sp_refresh_parameter_encryption N'dbo.usp_UpdateCustomerPII';

실무 팁: Always Encrypted는 “DB만” 바꾸면 끝나는 기능이 아니라
클라이언트 드라이버/연결옵션/쿼리 패턴까지 함께 바꿔야 성공합니다.

---

8. 셀 수준(대칭키) 암호화 — T-SQL로 직접 제어하는 방식(레거시/특수 요구에 유용)

8.1 언제 이 방식을 선택하나?

• Always Encrypted를 쓸 수 없는 환경(드라이버/앱 제약, 특정 도구 미지원)
• 서버 내부에서 복호/연산이 반드시 필요(단, 권한 분리 효과는 약해짐)
• 특정 컬럼만 커스텀하게 암호화/복호화 로직을 제어하고 싶다

8.2 구현 예시(대칭키 + 인증서)

예시는 “기존 SSN 컬럼을 암호문 컬럼(varbinary)으로 이관”하는 형태입니다.

USE [SalesDB];
GO

-- 1) DB 마스터 키(없으면 생성)
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Replace_With_A_Strong_DbMasterKey_Password!';
GO

-- 2) 인증서 & 대칭키
CREATE CERTIFICATE PiiCert
    WITH SUBJECT = 'PII Column Protection';
GO

CREATE SYMMETRIC KEY PiiKey
    WITH ALGORITHM = AES_256
    ENCRYPTION BY CERTIFICATE PiiCert;
GO

-- 3) 암호문 컬럼 추가
ALTER TABLE dbo.CustomerPII
ADD NationalID_Encrypted varbinary(256) NULL;
GO

-- 4) 암호화 수행
OPEN SYMMETRIC KEY PiiKey DECRYPTION BY CERTIFICATE PiiCert;

UPDATE dbo.CustomerPII
SET NationalID_Encrypted =
    EncryptByKey(Key_GUID('PiiKey'), CONVERT(varbinary(13), NationalID));

CLOSE SYMMETRIC KEY PiiKey;
GO

-- 5) 복호화 조회(권한이 있는 세션에서만)
OPEN SYMMETRIC KEY PiiKey DECRYPTION BY CERTIFICATE PiiCert;

SELECT
    CustomerID,
    FullName,
    CONVERT(varchar(13), DecryptByKey(NationalID_Encrypted)) AS NationalID_Plain
FROM dbo.CustomerPII;

CLOSE SYMMETRIC KEY PiiKey;
GO

8.3 실무 주의점(반드시 읽기)

• 암호문은 보통 varbinary 형태라 정렬/LIKE/범위조건이 어렵습니다.
• 검색이 필요하면:
• (방법 A) 별도의 해시 컬럼(예: SHA-256) 저장 후 동등 비교
• (방법 B) 토큰화/부분 마스킹 전략
• (방법 C) 인덱싱 가능한 파생키 설계
  같은 “검색용 설계”를 병행해야 합니다.
• 키 관리(백업/회전)가 복잡해지므로 “정말 필요할 때만” 선택합니다.

---

9. 운영 체크리스트

9.1 공통(모든 암호화 공통)

• [ ] 키/인증서 백업은 오프사이트에 있으며 복구 절차가 문서화되어 있다
• [ ] 키/인증서 접근 권한은 최소화되어 있다(Separation of Duties)
• [ ] 복구 리허설(DR/다른 인스턴스 복원)을 분기/반기 단위로 수행한다
• [ ] 암호화 관련 변경(키 생성/회전/정책 변경)은 Change Management에 포함한다

9.2 TDE 전용

• [ ] sys.dm_database_encryption_keys로 상태를 상시 점검한다
• [ ] 인증서/개인키 분실 대비(이중 보관)
• [ ] AG/이관/복원 시 인증서 설치 순서가 Runbook에 있다

9.3 백업 암호화 전용

• [ ] 백업 복원 테스트(인증서 Import 포함)를 정기 수행
• [ ] 백업 파일이 외부로 나가는 경로(S3/Storage/FTP)에서 접근통제가 있다

9.4 TLS 전용

• [ ] sys.dm_exec_connections.encrypt_option로 암호화 연결이 확인된다
• [ ] 인증서 갱신 만료(Expiration) 알림 체계가 있다
• [ ] TrustServerCertificate=True를 운영에서 무분별하게 쓰지 않는다(원칙적으로 서버 인증서 검증이 필요)

9.5 Always Encrypted 전용

• [ ] 드라이버/클라이언트가 Column Encryption Setting=Enabled로 동작한다
• [ ] 결정형/무작위형 선택 근거가 문서화되어 있다
• [ ] 키 저장소(Azure Key Vault 등) 가용성/권한/감사 체계가 있다
• [ ] 프로시저/쿼리 호환성 테스트가 완료되었다

---

10. 실무 추천 조합(현실적인 “정답”)

• 기본 보안(대부분의 서비스): TLS + 백업 암호화
• 규제 대응(파일/백업 유출 리스크 큼): TLS + TDE + (필요 시) 백업 암호화
• 내부자/운영자 평문 차단이 핵심: TLS + Always Encrypted(PII 컬럼) + (보통) TDE
• 레거시/특수 요구: TLS + (필요 컬럼만) 셀 수준 암호화 + 백업 암호화

---