DRM은 암호화와 무엇이 다른가
DRM(Digital Rights Management)을 “파일을 암호화하는 기술”이라고만 설명하면 중요한 부분을 놓치게 된다. 암호화는 읽을 수 있는 데이터를 읽을 수 없는 형태로 바꾸는 기술이고, DRM은 누가 어떤 콘텐츠를 어떤 조건에서 사용할 수 있는지 통제하는 시스템이다.
암호화가 비밀성을 제공한다면 DRM은 비밀성 위에 정책, 키 배포, 클라이언트 강제, 감사 기록을 얹는다. 따라서 DRM을 설계할 때는 암호 알고리즘보다 먼저 콘텐츠의 사용 규칙과 공격자의 위치를 정의해야 한다.
암호화, 접근 제어, DRM의 차이
세 개념은 서로 대체 관계가 아니라 계층 관계에 가깝다.
| 구분 | 해결하려는 문제 | 통제가 끝나는 시점 |
|---|---|---|
| 암호화 | 저장·전송 중 내용을 읽지 못하게 함 | 복호화 키를 얻는 순간 |
| 접근 제어 | 사용자가 리소스에 접근할 수 있는지 결정함 | 요청을 허용하거나 거절하는 순간 |
| DRM | 허용된 사용자의 행위와 조건을 지속적으로 제한함 | 콘텐츠를 사용하는 동안 |
예를 들어 서버 디스크의 PDF를 AES로 암호화하면 디스크를 분리해 읽는 공격에는 강해진다. 하지만 정상 사용자의 브라우저에 평문을 내려주고 나면 그 파일을 복사하거나 다른 이름으로 저장하는 문제까지 해결되지는 않는다. DRM은 바로 이 “정상적인 사용 경로 안에서의 통제”를 다룬다.
반대로 DRM이 있다고 해서 인증과 인가를 생략할 수 있는 것도 아니다. 유효한 사용자에게만 라이선스를 발급하고, 그 사용자가 해당 문서를 열 권한이 있는지 먼저 확인해야 한다. DRM은 권한 시스템의 대체품이 아니라 권한 결정을 콘텐츠 사용 단계까지 전달하는 보안 계층이다.
DRM 시스템을 이루는 다섯 가지 구성 요소
제품마다 이름은 다르지만 일반적인 DRM은 다음 구성 요소로 나눌 수 있다.
1. 콘텐츠 보호기
원본 콘텐츠를 암호화하거나 DRM 컨테이너로 패키징한다. 문서 DRM은 파일 단위 또는 애플리케이션이 읽는 영역 단위로 보호하고, 스트리밍 DRM은 영상 세그먼트와 메타데이터를 별도로 다루는 경우가 많다.
보호기는 콘텐츠와 키를 함께 저장하지 않는다. 콘텐츠에는 식별자와 암호화 메타데이터를 붙이고, 실제 키는 별도의 키 관리 경계에서 관리하는 것이 기본이다.
2. 정책 엔진
사용자, 그룹, 문서, 작업, 시간, 기기 같은 속성을 조합해 사용 조건을 결정한다.
주체: 특정 사용자 또는 그룹
대상: 문서 ID 또는 콘텐츠 ID
행위: 열기, 미리보기, 다운로드, 인쇄, 복사
조건: 만료 시각, 기기 수, 네트워크, 오프라인 허용 여부
정책은 파일에 문자열로 적어 두는 설정값과 다르다. 정책을 변경하거나 회수할 수 있어야 하므로, 콘텐츠 식별자와 라이선스 발급 기록을 연결해 관리해야 한다.
3. 라이선스 또는 키 발급 서비스
클라이언트가 콘텐츠를 사용하기 직전에 정책을 평가하고, 허용된 경우에만 복호화에 필요한 키 또는 키 래퍼를 발급한다. 라이선스 응답은 단순한 “허용/거부”가 아니라 만료 시간, 사용 권한, 기기 바인딩 같은 제약을 포함할 수 있다.
웹 애플리케이션에서 이 서비스는 파일 다운로드 API와 같은 역할을 하지 않는다. 다운로드 권한과 라이선스 발급 권한을 분리해야 하며, 라이선스 응답에 원본 키가 직접 노출되지 않도록 보호된 클라이언트 경계를 사용한다.
4. 강제 실행 클라이언트
정책은 클라이언트가 실제로 강제해야 의미가 있다. 문서 DRM에서는 전용 뷰어 또는 운영체제 에이전트가 열기, 인쇄, 복사, 다른 이름으로 저장을 제어한다. 브라우저 기반 미디어에서는 브라우저와 콘텐츠 복호화 모듈(CDM)이 연결되어 재생 조건을 집행한다.
W3C의 Encrypted Media Extensions는 웹 페이지와 CDM 사이의 표준 API를 정의하지만 특정 DRM 제품이나 CDM 구현 자체를 정의하지는 않는다. 즉 EME를 사용한다고 해서 DRM이 자동으로 완성되는 것이 아니라, 라이선스 서버와 클라이언트의 보호 수준을 함께 설계해야 한다.
5. 감사와 운영 계층
누가 언제 어떤 콘텐츠의 사용을 요청했고 어떤 정책으로 허용되었는지 기록한다. 로그에는 키 값이나 원본 콘텐츠를 남기지 않고, 사용자 식별자, 콘텐츠 식별자, 정책 결과, 클라이언트 상태, 실패 유형 정도만 남기는 편이 안전하다.
감사 로그는 사후 조사뿐 아니라 정책이 너무 엄격해 정상 사용을 막고 있는지 확인하는 운영 데이터이기도 하다.
키 관리가 DRM의 중심인 이유
강한 암호 알고리즘을 사용해도 키가 소스 코드에 들어 있거나 모든 파일이 같은 키를 공유하면 DRM의 보호 수준은 낮아진다. NIST는 키 관리에 키의 생성, 저장, 배포, 사용, 회수, 폐기까지 전체 수명주기가 포함된다고 설명한다.
실무에서는 콘텐츠 암호화 키(DEK)와 키를 보호하는 키(KEK)를 분리하는 봉투 암호화 구조를 자주 사용한다.
원본 콘텐츠
└─ DEK로 암호화 → 암호화 콘텐츠
DEK
└─ KEK로 보호 → 키 저장소 또는 라이선스 서버
이 구조에서는 콘텐츠 저장소가 침해되어도 KEK에 접근하지 못하면 모든 파일을 한 번에 복호화하기 어렵다. 반대로 KEK가 유출되면 영향 범위가 크므로, 키 접근 권한과 사용 기록을 별도로 관리해야 한다.
키 수명주기에서 결정할 것
- 어떤 주체가 키를 생성하는가
- 키를 어느 경계에 저장하는가
- 콘텐츠별·테넌트별로 키를 분리할 것인가
- 키의 유효기간과 교체 주기는 얼마인가
- 폐기 또는 회수된 키로 기존 콘텐츠를 어떻게 처리할 것인가
- 백업과 재해 복구에서 키를 어떻게 복원할 것인가
키를 교체한다고 해서 이미 배포된 평문이 자동으로 회수되는 것은 아니다. 회수 정책은 클라이언트가 다음 라이선스 갱신 때 새 상태를 확인하도록 만들고, 오프라인 사용을 허용한다면 그 기간만큼 회수 지연을 감수해야 한다.
권한 모델은 행위 단위로 쪼개야 한다
“문서에 접근할 수 있다”는 한 가지 권한만으로는 DRM 정책을 표현하기 어렵다. 다음 행위를 별도 권한으로 두는 편이 현실적이다.
| 행위 | 확인할 조건 예시 |
|---|---|
| 열기 | 사용자가 문서의 독자 그룹에 포함되는가 |
| 미리보기 | 웹에서 허용된 문서 형식인가 |
| 다운로드 | 원본 반출 권한이 있는가 |
| 인쇄 | 보안 영역 또는 승인된 프린터인가 |
| 복사 | 클립보드와 다른 애플리케이션으로의 이동을 허용하는가 |
| 공유 | 다른 사용자에게 재위임할 수 있는가 |
이렇게 나누면 미리보기는 허용하되 다운로드는 막는 정책을 만들 수 있다. 또한 관리자가 권한을 변경했을 때 어떤 행위가 즉시 차단되어야 하는지 정의하기 쉬워진다.
서버 미리보기에서 생기는 새로운 위험
문서 DRM을 웹 서비스에 연결하면 서버가 일시적으로 평문을 볼 수 있는 구간이 생긴다. 이 구간은 저장소의 암호화만으로 보호되지 않으므로 별도의 생명주기 설계가 필요하다.
- 원본을 임시 파일로 복사할 때 원본 확장자와 SDK가 요구하는 메타데이터를 유지한다.
- 복호화 파일을 공개 디렉터리나 영구 캐시에 저장하지 않는다.
- 스트리밍이 성공하거나 실패해도
finally에서 임시 파일을 삭제한다. - 프록시와 브라우저 캐시가 평문 응답을 오래 보관하지 않도록 응답 헤더를 설정한다.
- 미리보기 API에도 파일별 인가 검사를 적용한다.
- 오류 응답에 키 경로, 내부 호스트, SDK 반환값을 그대로 노출하지 않는다.
임시 파일 삭제만으로 모든 문제가 해결되는 것은 아니다. 운영체제의 디스크 복구, 스왑 영역, 프로세스 메모리 덤프, 애플리케이션 로그까지 위협 모델에 포함할지 결정해야 한다. 요구 수준이 높다면 메모리 스트리밍, 암호화된 임시 디스크, 접근 가능한 운영자 범위까지 함께 검토한다.
DRM이 막을 수 없는 것
DRM을 “복제를 완전히 막는 기술”로 설명하면 기대치가 잘못 설정된다. 사용자가 합법적으로 콘텐츠를 볼 수 있다면 화면 캡처, 다른 카메라로 촬영, 취약한 클라이언트 변조 같은 경로가 남는다.
DRM의 현실적인 목표는 다음에 가깝다.
- 저장소나 전송 구간에서 원본이 유출되는 위험을 줄인다.
- 허가받지 않은 클라이언트가 콘텐츠 키를 얻기 어렵게 한다.
- 사용자의 권한과 콘텐츠 정책을 사용 시점까지 연결한다.
- 유출이나 오남용이 발생했을 때 추적 가능한 기록을 남긴다.
절대적인 보호를 약속하기보다 어떤 공격 비용을 높이고 어떤 유출 경로를 줄이는지 설명해야 한다. DRM은 보안 통제 중 하나이며, 인증·인가·네트워크 보안·악성 코드 방어를 대신하지 않는다.
DRM 설계를 검토하는 체크리스트
새 DRM을 도입하거나 기존 연동을 점검할 때는 다음 질문에 답할 수 있어야 한다.
- 저장소에서 평문이 남을 수 있는 위치는 어디인가
- 파일별 키와 테넌트별 키의 분리 수준은 적절한가
- 라이선스 만료와 권한 회수는 어떤 시점에 반영되는가
- 오프라인 사용을 허용할 때 최대 허용 기간은 얼마인가
- 미리보기와 다운로드 권한을 분리했는가
- 클라이언트가 정책을 집행하지 못할 때 서버는 어떻게 실패하는가
- 키 불일치와 사용자 입력 오류를 서버 장애와 구분하는가
- 감사 로그에서 민감 정보가 제외되어 있는가
- 레거시 평문 파일을 언제까지 허용할 것인가
- 키 백업을 복원하지 못했을 때 어떤 콘텐츠가 영향을 받는가
이 질문에 답하지 않고 SDK 연동부터 시작하면 정상 파일 하나를 여는 데는 성공해도, 키 교체나 권한 회수 같은 운영 단계에서 다시 설계를 바꾸게 된다.
마무리
DRM은 암호화 라이브러리 하나를 붙이는 작업이 아니다. 콘텐츠 암호화, 키 수명주기, 권한 정책, 클라이언트 집행, 감사 기록이 하나의 생태계를 이룬다.
특히 서버에서 문서를 미리보기로 제공하는 서비스라면 저장 파일의 상태뿐 아니라 평문이 생성되는 시간과 위치를 관리해야 한다. “어디에 암호화할 것인가”만큼 “어디에서 복호화할 수 있고, 언제 삭제할 것인가”가 중요하다.
결국 좋은 DRM 설계는 가장 강한 제품을 선택하는 데서 끝나지 않는다. 보호할 자산, 허용할 사용 방식, 감수할 사용자 불편, 회수 가능한 권한 범위를 먼저 정의하고 그에 맞는 기술과 운영 절차를 선택하는 데서 시작한다.