MS BitLocker FBI 해제 사건이 보여준 것: 암호화보다 중요한 키 통제권

최근 공개된 마이크로소프트(Microsoft) 암호화 복구 키 제출 사례는 많은 사용자가 막연하게 생각해 온 전제를 흔듭니다.

노트북의 로컬 디스크 드라이브를 암호화해 두었다고 해서 그 데이터에 대한 통제권까지 오직 사용자 본인만 가진다고 볼 수는 없다는 점입니다.

비트라커(BitLocker)가 아무리 안전하더라도 복구 키를 보관하던 제3자가 법적 절차에 따라 그 키를 제공할 수 있었다는 사실이 이번 사건의 핵심이라고 할 수 있습니다.

본 포스트에서는 이번 사건을 계기로 암호화 알고리즘 자체보다 더 중요한 키 통제권의 문제를 정리해 보겠습니다. 그리고 비교 관점에서 시놀로지(Synology)/큐냅(QNAP) 나스(NAS)의 공유 폴더 암호화, 볼륨 암호화는 어떤 점이 다른지, 마지막으로 외부 클라우드 의존을 줄인 프라이빗 나스 저장소를 어떻게 설계해야 하는지까지 함께 짚어보겠습니다.

사건 개요

이번에 일어난 일은 괌 지역의 사기 사건 수사 중 FBI가 마이크로소프트 윈도우(Windows) 운영체제의 비트라커 암호화 데이터를 영장 제시를 통해 풀어내 원본 데이터를 복구한 건입니다.

해당 사건의 구조는 다음과 같습니다.

1. 용의자의 Windows에서 사용하던 저장장치는 비트라커로 암호화되어 있었습니다.
2. 하지만 해당 장치의 복구 키가 마이크로소프트 측 계정/서버 기반 복구가 가능했습니다.
3. 수사기관은 장치를 직접 해독하지 않고, 복구 키를 보유한 3자(마이크로소프트)에게 법적 절차로 접근했습니다.
4. 결과적으로 MS는 영장에 의해 복구 키를 제공했고, FBI는 암호화 데이터에 접근할 수 있었습니다.

자세한 기술적 내막이 알려지지 않았을 때는 많은 사람들이 충격에 휩싸였습니다. 로컬 암호화는 말 그대로 나 말고는 절대로 내용을 해독하지 못하게 하기 위한 수단인데, 사법기관의 영장 제시가 있었다고 한들 MS가 이걸 해독할 수 있다면, 결국 운영체제 제조사는 모든 사용자들의 데이터를 쉽게 해독해서 읽어낼 수 있다는 거였으니까요.

하지만 이번 사건이 보여준 것은 키 에스크로(key escrow)의 문제에 가깝고, MS 역시 조건이 맞춰지지 않을 경우 Windows 사용자의 데이터를 마음대로 복호화하는 건 불가능합니다.

암호화 자체는 강하더라도, 복구 키가 서비스 사업자나 조직의 관리 체계 안에 있으면 그 통제권 역시 그 체계의 영향을 받습니다.

저장장치 암호화 시 정말 먼저 확인해야 할 것은 "AES 몇 비트인가"와 같이 암호화 강도가 강한지가 아니라 복구 키가 어디에 얼마나 안전하게 저장되는가입니다.

왜 많은 사용자들이 이 문제를 놓치기 쉬울까

여기에는 UI와 설정의 자연스러운 흐름이 크게 작용합니다.

윈도우에서는 장치를 마이크로소프트 계정이나 조직 계정으로 아주 자연스럽게 연동시킵니다. 마치 당연히 꼭 해야하는 것처럼 말이죠. 사용자는 비트라커를 통해 디스크의 내용을 암호화하는 과정에서 "내 PC는 암호화되었다"라는 인식을 갖게 되지만, 동시에 복구 키가 계정에 연결되거나 자동 백업되는 구조까지 깊게 생각하지 않는 경우가 많습니다.

개인 사용자 입장에서는 이 방식이 사실 편리합니다.

• 비밀번호 분실
• 하드웨어 변경으로 복구 화면 발생
• 부팅 관련 문제

위와 같은 상황에서도 온라인 계정에 연동된 복구 키를 사용해 다시 데이터에 쉽게 접근할 수 있기 때문입니다.

하지만 이 편의성은 반대로 말하면 복구 키가 사용자 단말 밖에 존재할 수 있음을 의미합니다.

이 부분에서 로컬 암호화와 완전한 프라이빗 암호화는 갈라집니다.

로컬에서 암호화된 것이 즉 완전한 프라이빗 데이터를 의미하진 않습니다

실제로는 아래 질문이 더 중요합니다.

같은 "암호화" 상황에서도 보안 성질은 완전히 달라집니다.

비트라커 자체에는 문제가 없습니다

이번 사건이 비트라커 암호화 자체의 성능 문제로 생긴 건 아닙니다. 비트라커를 사용하는 것은 여전히 굉장히 안전합니다. 단 문제는 어떤 복구 경로를 허용하느냐입니다.

복구 키가 아래와 같은 구조에 들어가면, 사용자는 편의성을 얻습니다.

• 마이크로소프트 계정 기반 복구
• 조직 계정 기반 복구
• 헬프데스크가 회수 가능한 중앙 관리형 복구
• 계정 포털에서 다시 조회 가능한 온라인 보관

하지만 동시에 이런 질문도 생깁니다.

• 그 키를 나 말고 누가 가질 수 있는가
• 법적 절차, 계정 탈취, 내부자 접근, 관리 실수 같은 상황에서 누가 복구를 실행할 수 있는가
• 사용자는 정말 이 설계를 의식적으로 선택했는가, 아니면 기본 UI 흐름을 따라가다 사실상 동의한 것인가

이번 사건이 불편한 이유는 바로 여기에 있습니다.

많은 사용자가 "로컬 디스크 암호화"라는 표현만 보고, 복구 키까지 자신만 쥐고 있다고 생각해 왔기 때문입니다.

시놀로지와 큐냅 등 나스의 암호화는 어떤 점이 다른가

여기서 시놀로지나 큐냅 같은 나스의 공유 폴더 암호화와 볼륨 암호화를 비교 대상으로 보는 이유가 있습니다.

이유는 단순합니다.

기본 복구 철학이 벤더 클라우드 중심이 아니라, 로컬 또는 온프레미스 키 관리 중심에 가깝다는 점입니다.

시놀로지는 공유 폴더 암호화에서 키를 내보내서 다른 장치에 저장하는 방식을 제공하고, 볼륨 암호화에서는 복구 키를 사용자가 별도로 안전한 위치에 보관하는 구조를 사용합니다.

특히 볼륨 암호화는 더 강한 분리를 원하면 외부 시놀로지 나스 기반 키 저장소(KMIP)로 데이터와 키를 분리하는 게 가능합니다.

즉, 설계 철학 자체가 "누가 키를 들고 있을 것인가"를 운영자가 정하게 하는 구조에 가깝습니다.

다만 이것도 무조건 절대 안전하다는 뜻은 아니며, 로컬 키 저장소를 사용할 경우에는 나스 자체가 도난당했을 때 암호화 키를 탈취당할 수 있습니다. 가장 좋은 것은 키를 별도 보안 USB에 저장하고, 암호 자체를 기억하거나 프린트해서 안전한 곳에 보관하는 것입니다.

큐냅 역시 공유 폴더 암호화 시 암호화 키 파일을 다운로드할 수 있게 하고, 볼륨 암호화의 경우 자동 마운트, 수동 마운트를 모두 지원합니다. 당연히 KMIP 서버와 연계도 지원하고요.

즉, 큐냅도 키를 어디에 둘지, 자동 언락을 허용할지를 운영자가 결정합니다.

이 차이는 생각보다 큽니다.

마이크로소프트 계정 연동형 복구처럼 사용자가 자연스럽게 계정 기반 복구 흐름에 편입되는 구조와 달리, NAS 암호화는 키 위치를 더 명시적으로 선언하고 관리하는 쪽에 가깝기 때문입니다.

때문에 저희도 가끔 암호화 기능을 단순히 폴더에 암호를 거는 기능 정도로 착각하고 있다가, 나스 재부팅을 한 다음 키 파일도 잃어버리고 암호 자체도 잊어버린 상황에서는 복구해드릴 수가 없습니다. 저희는 매뉴얼에서 비교적 자세하게 이 부분에 대한 주의를 안내하고 있지만, 다른 많은 나스 사용자들이 암호화 기능을 켠 채로 몇 달, 혹은 1년 넘는 긴 기간 동안 사용하다가 오랜만에 재부팅을 하여 잠긴 폴더를 열지 못해 문제를 겪는 경우가 은근히 많습니다.

정말 프라이빗한 나스 저장소를 만들려면

여기서부터가 실제 구축을 취해 중요합니다. 진짜 프라이빗 저장소는 암호화 기능 하나 켜는 것으로 끝나지 않습니다.

1) 키를 벤더 클라우드가 아니라 운영자 통제 영역에 둡니다

가장 먼저 정할 것은 이것입니다.

• 복구 키를 오프라인 보관할 것인지
• 별도 안전 금고, 암호화 USB, 내부 KMIP, 보조 나스 등 온프레미스 체계로 둘 것인지
• 부팅 때마다 수동 언락할 것인지
• 가용성을 위해 자동 언락이 필요하다면, 어디까지 감수할 것인지

이 선택이 전체 보안 수준을 결정합니다.

2) 관리 인터페이스를 외부에 그대로 열지 않습니다

아무리 볼륨을 암호화해도 관리 포털이 외부에 열려 있고 관리자 계정이 약하면 전체 설계가 무너집니다.

아래 조합을 먼저 봐야합니다.

• 필요하지 않다면 QuickConnect, myQNAPcloud, 벤더 릴레이 경로 최소화
• 관리자 계정 분리, MFA 적용
• 일반 사용자와 관리자의 권한 체계 분리
• 감사 로그와 로그인 알림 활성화

3) 자동 언락 정책을 업무 연속성과 함께 판단합니다

모든 조직이 "부팅할 때마다 사람이 키를 넣어야 한다"는 모델을 현실적으로 운영할 수 있는 것은 아닙니다.

예를 들어 아래처럼 나뉩니다.

• 프라이버시 최우선: 수동 언락, 오프라인 키 보관, 외부 노출 최소화
• 가용성 우선: Key Vault 또는 KMIP 기반 자동 언락, 대신 망분리와 접근 통제 강화
• 절충안: 주요 민감 데이터만 별도 암호화 볼륨/공유 폴더로 분리

이런 선택은 보안과 사용성 양쪽 모두 고려해 정해두어야 합니다.

4) 저장소를 "내 것처럼 보이는 클라우드"로 만들지 않습니다

프라이빗 저장소를 원하면서도 실제로는 아래를 켜 두는 경우가 많습니다.

• 외부 계정 연동 자동 복구
• 항상 켜진 원격 접속 릴레이
• 복구 키 파일을 같은 NAS나 같은 사무실 서랍에 보관
• 관리자 계정과 일반 업무 계정 혼용

이러면 저장 위치만 나스일 뿐, 실질적인 프라이버시는 다소 떨어질 수 있습니다.

완벽한 보안은 없지만, 통제권은 설계할 수 있습니다

냉정하게 말하면 완벽히 안전한 저장소는 없습니다.

다만 외부 클라우드에 복구 키를 맡기지 않고, 키와 데이터를 분리하고, 자동 언락과 외부 접근을 통제하고, 스냅샷과 백업까지 함께 설계한 저장소는 충분히 만들 수 있습니다.

특히 아래 같은 점들이 필요하다면 초기 설계가 중요합니다.

• 외부 계정/클라우드에 복구 키를 두고 싶지 않은 경우
• 개인 민감 자료나 법인 핵심 자료를 온프레미스 중심으로 보호해야 하는 경우
• 시놀로지 또는 큐냅에서 공유 폴더 암호화와 볼륨 암호화 중 무엇이 맞는지 판단이 필요한 경우
• 나스 구축 이후에도 운영 실수 없이 복구 가능한 구조까지 함께 잡고 싶은 경우

저희 스튜디오 엘은 보안 전공 대표와 함께 고객사의 데이터를 최우선으로 보호할 수 있는 여러 전략을 제공합니다. 위 버튼으로 문의를 주시면 전문가의 상담을 받으실 수 있습니다.

마무리

이번 마이크로소프트 비트라커 해제 사례는 우리에게 한 가지를 분명하게 보여줍니다.

암호화 여부보다 더 중요한 것은 키의 위치와 통제권이라는 점입니다.

로컬 암호화처럼 보여도 복구 키가 계정, 조직, 벤더 시스템 안에 있으면 그 암호화는 생각만큼 프라이빗하지 않을 수 있습니다. 반대로 시놀로지나 큐냅 같은 나스는 키를 다운로드해서 로컬에 보관하거나, 온프레미스 키 저장소/KMIP로 분리하는 식의 설계가 가능하므로, 더 높은 통제권을 목표로 한 구축에 유리한 면이 있습니다.