|
|
|
|
솔루션은 많고 “표준은 없다” |
| 엔터프라이즈 키 관리(EKM) |
 |
2007년 09월 10일 00:00:00 |
데이터넷
|
 |
|
|
법률·정책·규정 준수에 효과적 …
‘ 정책 애플리케이션의 일관성’이 성공의 관건
암호화와 이것이 만들어내는 키를 현명하게 관리하지 않을 경우, 데이터는 결국 유실되거나 손상될 것이다. 여기서는 키를 관리할 수 있도록, 그리고 현 상태에서 안전하도록 유지할 수 있는 방법을 논의하고, 엔터프라이즈 키 관리 시스템에서 추구해야 할 것이 무엇인지를 살펴봤다.
CIO들은 하룻밤 만에 “통합이 잘 된 전사적 암호화 인프라에 수백 달러를 들이붓자”고 결정하는 게 아니다. 그 프로세스는 백업 테이프에서 출발해 규정 준수 문제가 부각되거나, 혹은 특정 애플리케이션이 재무적 책임이 있음을 깨달으면서 확산되는 방식으로 서서히 진행된다. 그리고 결과적으로 암호화 관리의 층이 쌓여가면서 여러 가지 키 관리 문제들이 속출하기 마련이다.
이제 가던 길을 멈추고 다음과 같은 생각해 봐야 할 때다. 암호화와 키 관리에 있어 이렇듯 점진적인 방식으로 접근한다면 많은 비용이 들어가지 않을까? 아마도 그렇겠지만 선택의 여지는 거의 없다.
“나쁜 소식은 규정 기관의 압박으로 인해 밑바닥에서부터 보안을 가동시켜야 하게 됐다는 것”이라고 크립토그래피 리서치(Cryptography Research)의 기술 부사장인 벤야민 준은 말했다. 그는 또 “지금의 키 관리가 5년 전 신원정보 관리 상태”라고 덧붙였는데, 이는 곧 업계에서 공통 표준을 완성하기를 기다리는 중이라는 뜻이다.
표준이 없다
잔인하게 들릴지 모르겠지만 대기업들이 수년간 이 문제를 두고 씨름하고 있음에도 불구하고 별개 시스템에 존재하는 키를 통합적으로 관리할 수 있도록 지원해 주는 표준은 현재 전무하다.
RSA의 ‘퍼블릭키 크립토그래피 스탠다드(Public-Key Cryptography Standard) 11’과 마이크로소프트의 ‘크립토API(CryptoAPI)’가 도움이 되긴 하지만, 이들은 표준이 아니다. 오픈SSL 프로젝트는 크립토 이행을 위한 표준 기반 툴킷이지만, 키 관리는 다루지 않는다. 자바 JCA/JCE(Java Cryptography Architecture/Java Cryptography Extensions)는 마이크로소프트의 크립토API와 유사하다. 즉 자바와 JCE를 사용하고 있는 사람이라면 이런 애플리케이션용의 EKM(Enterprise Key Management) 필요조건만 충족시킬 수 있을 것이다. 썬의 ‘SKIP(Simple Key Management for Internet Protocols)’는 관리가 아니라 키 공유 기능만 제공한다.
본지에서 실시한 키 관리 제품 분석에 의하면, 정해진 표준이 없는 상태에서도 제대로 된 방향으로 첫 발자국들을 떼고 있는 업체들이 있었다. 하지만 대부분의 경우 암호화를 사용하는 업체들은 R&D의 초점을 원래의 자리, 즉 자체 제품용의 키 관리를 향상시키는 데 두고 있었다.
그리고 물론 우리는 우리가 바라는 것에 신중해야 한다. 편리함에는 대부분 위험이 함께 따르며, 달걀을 한 바구니에 모두 담기 위해서는 하드웨어 중복성, 보안 백업 및 복구 능력, 그리고 시스템 액세스용으로 강력한 인증 정책이 필요하다.
유비쿼터스 암호화를 막 시작한 회사들은 이기종 시스템들 수가 너무 많아지기 전에 EKM 프로젝트를 시작하고, 사후에 지원을 강화하려고 마음먹는 대신 새 제품들이 기존의 전략과 호환되도록 보장하는 게 중요하다. 애드혹 기반으로 암호화를 채택했던 사람들이라면 보안은 가장 약한 링크만큼만 강력하다는 사실을 깨달아야 한다. 즉 키를 제대로 처리하지 못하면 결과적으로는 민감한 데이터로의 액세스를 잃게 되며, 더 나쁜 경우에는 이것을 노출시키고 그 결과로 인해 고통받게 된다.
기업의 암호화 현황
최근의 끔찍한 데이터 누출 사례들로 미루어 볼 때, 대부분의 기업에서는 통합성이 뛰어난 암호화 계획을 만드느라 여념이 없을 것이라고 생각할 수 있다. 하지만 꼭 그렇지만도 않은 것이 최근 포네몬 인스티튜트(Ponemon Institute)의 조사 결과에 따르면, 768명의 미국 IT 전문가 응답자들 가운데 66%가 어느 정도의 암호화 전략을 갖고 있지만, 전사적으로 접근하는 사람들은 16%에 불과한 것으로 나타났다.
이것은 부분적으로 암호화의 동력이 정부 및 산업 규정에서부터 계약상 의무(contractual obligations), 감사 기관의 요구, 강제 공개 법안으로 성문화된 세이프 하버 조항에 대해 냉소적인 입장을 띠는 경우가 많은 내부 정책 등 매우 다양하기 때문이다. 하지만 다양해서 안 될 것은 바로 암호화 키를 관리하는 전략이다. 키 관리는 규정준수 기관에서 키가 어떻게 생성, 저장 및 파괴되는지를 알고 싶어하기 때문이 아니라, 키가 잘못 처리됐을 경우 데이터가 유실될 수 있기 때문에 중요한 것이다. 집중식 키 관리 전략에 대한 필요는 회사의 암호화 필요가 늘어남에 따라 더욱 중요하게 부각될 것이다.
이제 이 문제를 바닥에서부터 짚고 올라가 보자.
암호화에 대한 동력은 크게 세 가지로 나눌 수 있는데, 바로 무형의 것, 법률, 그리고 표준이다. 무형의 것으로는 좋은 브랜드 이미지를 유지하는 것과 프라이버시 정책과 고객의 신뢰를 존중하는 것이 포함된다. 포네몬 조사에서는 불과 7%의 응답자만이 프라이버시 존중이 민감하거나 중요한 데이터를 암호화하는 데 대한 최고의 이유라고 답했다. 브랜드나 명성을 보호하는 형태의 자기 보존은 이보다 나은 40% 수준이었다.
법률, 특히 강제 공개 법률은 무형의 것들과 서로 교차된다. 캘리포니아에서 세너트 빌(Senate Bill) No. 1386을 입법화한 이래로 4년 가까운 시간이 흐르는 동안, 다른 30개 주에서도 개인 정보가 암호화되지 않은 사람들에게는 보안 침해 결과로(보안의 구멍을 강조) 그 정보가 공개될 수 있다는 사실을 조직에서 반드시 통보해야 한다는 이와 유사한 법안이 통과됐다. 그리고 그램-리치-브릴리(Gramm-Leach-Bliley), HIPAA 및 사베인-옥슬리(Sarbanes-Oxley) 같은 미 연방 규정들이 암호화를 권장하거나 요구하는 것들로 인식되고 있다.
보안 업체들은 e탐색 협박 전술과 함께 이런 규정들을 주저없이 제품 판매에 활용하고 있다. 하지만 이 외에도 따르지 않기가 힘든 한 가지 강력한 규정이 있으니 그것은 바로 PCI DSS(Payment Card Industry Data Security Standard)다. PCI DSS는 아메리칸 익스프레스, 디스커버, 마스터카드, 비자 및 국제 신용카드 발행회사인 JCB 등으로 구성된 PCI 보안 표준 위원회(Security Standards Council)에서 제정된 것이다.
지난 1월 1일자로 모든 신용카드 프로세서용 표준이 된 PCI DSS 1.1에서는 카드 소지자의 데이터가 공중망을 통과하기 이전에 반드시 암호화되도록 명시하고 있다. 표준은 명확해야 하며, 데이터 액세스를 제한하는 데 암호화가 필요할 수 있는 다른 여러 가지 상황을 고려해야 한다는 한 가지 포괄적인 규칙을 기반으로 해서 세부 사항들이 규정돼 있다.
뿐만 아니라 PCI DSS에 있는 키 처리 필요조건도 또한 포괄적이다. 키 보관기관과 그 장소는 제한돼야 한다. 모든 키 관리 프로세스는 성문화돼야 하며, 강력한 키 생성 뿐만 아니라 키의 보안 저장, 전송, 폐기, 에이징(aging) 및 취소(revocation) 등도 포함해야 한다.
그렇다면 우리가 암호화에 대해 본 대부분의 통계가 신용카드 트랜잭션을 처리하는 조직들의 수와 맞지 않아 보이는 이유는 무엇일까? 암호화가 실제보다 적게 보고되고 있는 것일까? 우리가 보기에 보안 전문가들은 암호화 시장에서 가장 큰 문제, 즉 솔루션은 너무 많고 표준은 너무 없다는 문제에 봉착하고 있다.
성장 산업
올해 RSA 컨퍼런스에서는 암호화가 성장 산업이라는 게 여실히 드러났다. 381곳의 전시 업체들 중에서 1/5이 데이터 암호화나 키 관리에 초점을 두고 있었기 때문이다. 이것은 전시된 부문이 몇 되지 않음을 감안할 때 매우 높은 비율이다. 여기서 회사들은 테이프와 하드 드라이브에 있는 데이터용과, 모든 종류의 VPN과 작동하는 데이터용, 그리고 데이터가 네트워크를 통과해 갈 때 자동 투명 암호화용의 암호화를 보여 주었다. 마이크로소프트의 빌게이트와 크레이드 번디의 기조 연설에서도 데이터가 네트워크 장비들 사이를 이동해 갈 때 이것을 IPsec이 어떻게 자동으로 암호화할 수 있는지가 집중 조명될 정도였다.
그렇다면 이제 이 모든 솔루션들이 어떻게 함께 잘 작동하는지, 혹은 경우에 따라서 그렇지 못한지를 살펴보자.
우리가 인프라에서 발생하는 암호화의 양을 늘리고 키가 다중 애플리케이션에 널리 배치되도록 하면서, 각 애플리케이션이 그 자체 키를 관리하도록 하는 기존 모델로는 유지하기 힘들게 됐다. 물론 암호화 필요가 비교적 많지 않은 작은 조직에서는 몇 개의 독립 암호화 사일로들로도 헤쳐나갈 수 있겠지만, 얼마나 오래 지탱할 수 있을지는 의문이다. 암호화 필요조건은 분명 금새 사라지지 않을 것이기 때문이다.
교차 플랫폼의 능력이 가능한 한도 내에서, 개방형 키 관리 인터페이스가 없는 상태에서 암호화 키를 사용하는 스위치, 스토리지 시스템 및 테이프 드라이브는 써드파티 용도로 이들의 키 관리 API를 퍼블리싱함으로써만 협력이 가능하다. 현재는 어떤 업체도 네트워크, 디스크 및 데이터베이스 애플리케이션용으로 이동 중인 데이터를 암호화하는 데 뿐만 아니라, 테이프나 디스크에 보관된 데이터를 암호화하는 용도로 다양한 시스템을 지원할 수 있는 특정 목적에 맞게 제작된 키 관리기를 제공하지 못하고 있다.
현재 대부분의 키 관리 업체들은 보관 중인 데이터를 강조하고 있는데, 그 이유는 이것이 IT에서 가장 큰 도전 가운데 하나를 대변하기 때문이다. 테이프와 백업 애플리케이션에서는 엄청나게 많은 키가 만들어진 다음, 수십년 간 안전하게 유지보수돼야 한다. 키는 또한 재앙 복구나 e-탐색용으로 데이터에 액세스가 가능하도록 원격지에 있을 필요가 있다.
정책에 대한 모든 것
다중 독립 시스템의 관리 오버헤드를 통합시키는 외에, EKM 성공을 알리는 가장 큰 지표는 바로 일관성 있는 정책 애플리케이션이다. 마이크로소프트는 자사의 윈도 서버 2003용 윈도 라이츠 매니지먼트 서비스(Windows Rights Management Services)에서 이 문제에 대한 솔루션의 가능성을 보여주고 있다.
물론 윈도 RMS는 동종의 마이크로소프트 환경에서만 작동을 한다. 하지만 우리의 목적에서 중요한 것은 RMS 뒤에 있는 기본 원칙으로, 마이크로소프트는 RMS가 “정보가 향하는 곳이 어디든 관계없이 정보와 함께 남아 있는 일관성 있는 이용 정책을 통해 정보를 보호함으로써 조직의 보안 전략을 보완한다”고 말했다.
여기서 마법의 단어는? 바로 정책이다.
암호화의 열쇠는 데이터로의 액세스를 보호하는 것이다. 서로 다른 사람들이 그 위치를 기반으로 같은 데이터로 액세스할 수 있게 허용하는 것은 소용이 없다. 네트워크 엔지니어들은 데이터가 VPN을 가로지를 때 키로의 액세스를 갖고 있어야 하고, 메일 서버 관리자는 데이터가 메일 서버에서 암호화되는 동안 액세스를 갖고 있어야 하며, 사용자는 자신의 랩톱에서 데이터가 암호화될 때 액세스를 갖고 있어야 하는 이유는 무엇인가?
보안 업계는 정책 준수와 정책 주도식 보안을 강력히 밀어붙이고 있으며(NAC가 이런 추세를 대변해 준다), 데이터 암호화에는 또한 회사의 정책을 직접적으로 반영하고 있는 제품들이 필요하다. 데이터 보안 표준이 우선 만들어져야 하며, 그런 다음 이런 표준을 기반으로 데이터가 있는 장소에 상관없이 일관성 있는 보호 수단을 이행하는 보안 메커니즘이 필요하다.
불행히도 모든 제품이나 네트워크의 조각에 그 자체의 암호화 메커니즘이 있는 사일로 방식에서는 이것이 불가능하다.
해결책은?
우리는 서로 다른 업체의 암호화 장비와 소프트웨어에 말을 건낼 수 있고, 우리의 모든 키를 관리할 수 있는 EKM 제품을 원한다. 키 관리는 하나의 스위트로 해결하기에는 너무 힘든 과제며, 서로 다른 유형의 많은 제품들을 통합하는 것도 물론 마찬가지다.
EKM 스위트가 효과적일 수 있으려면 최소한 다음과 같은 희망 사항을 해결할 수 있어야 한다.
>> 보안 키 생성. 이것은 실제로 보기보다 힘든 일이며, 소위 암호화 이행에 대한 사이드 채널 공격을 막을 수 있게 특별히 제작된 FIPS 140-2 레벨 3 암호화 하드웨어를 이용해 수행돼야 한다.
>> 필요에 따른 낡은 키 재 암호화를 포함한 키 취소(key revocation)와 키 에이징(key aging).
>> 신원정보 관리 시스템과 자동 통합. 여기서는 새 계정이 새 키와 동일하고, 삭제된 계정이 취소된 키와 동일함.
>> 키 에스크로(key escrow). 여기서는 시스템이 써드파티를 대신에 키를 보관하며, 예를 들어 갑작스럽게 회사를 그만두거나 해고된 직원이 고용주를 곤란하게 할 수가 없다;
>> 분할 키(split keys). 종종 조직의 임원들간에 마스터 복구 키를 분배하는 데 사용된다. 이것이 있으면 마스터를 복구하는 데 다수의 일정 인원이 동원돼야 한다. 데크루(Decru)의 라이프타임 키 매니지먼트(Lifetime Key Management) 제품은 비상 키 액세스용으로 분할 키를 사용하는데, 단 이 제품은 이 회사 자체의 데이터포트(DataFort) 시스템을 이용한 키 관리용으로 개발됐다.
그리고 이들은 어려운 문제가 아니다. 일단 이런 문제가 해결이 된다 하더라도 인간 언어의 데이터 보안 표준을 각 암호화 메커니즘용의 기술 정책으로 어떻게 바꿀 것인지와 같은 힘든 문제들이 여전히 남아 있다. 제품은 반드시 각 장비가 있는 곳과 그 키를 관리하는 방법뿐만 아니라, 이것이 처리하는 데이터에 대한 적절한 정책을 이용해 장비를 구성하는 방법도 알아야 한다.
이렇듯 이상적인 EKM의 실현을 가로막는 한 가지 큰 장애는 인터페이스 표준의 부재다. 물론 예를 들어 FIPS 140-2와 같이 암호화의 적절한 이행을 위한 표준들이 많이 나와 있으며, 심지어 RFC3852 같이 키가 전송용으로 봉입될 수 있는 방식에 대한 표준들도 있다. 하지만 이렇듯 제안된 EKM 장비가 각 업체 플랫폼용의 API를 학습할 필요 없이 다중 암호화 제품과 통신할 수 있는 방식에 대한 표준은 없는 상태다.
솔루션에 가까워 보이는 것으로 PKCS#11(Public-Key Cryptography Standards 11)이 있는데, 여기서는 ‘크립토 키(Crypto-key)’와 발음이 같은 ‘크립토키(Cryptoki)’라 불리며, 키를 보유하고 있거나 암호화 작업을 수행하는 장비에서 키 관리를 하는 용도의 API를 규정하고 있다. PKCS#11은 특히 암호 토큰(cryptographic token)의 엔터프라이즈 관리를 허용하도록 만들어졌지만, 모든 문제를 해결하지는 못한다. 우선 이것은 네트워크 API가 아니며, 네트워크에서 사용 가능하려면 보다 높은 레벨의 래퍼(wrapper)가 필요하다. 물론 언제나 이렇게 할 수 있는 방법이 있긴 하지만, 서로 다른 이행안들간에 상호운용성을 보장해 주는 표준을 기반으로 하는 것은 아무 것도 없다.
게다가 PKCS#11은 완전한 EKM에 필요한 모든 키와 메커니즘을 다루고 있지 않다. 엔터프라이즈 규모에서의 키 관리 상호운용성은 PKCS#11이 해결하고자 했던 문제가 아니기 때문이다.
마이크로소프트의 CAPI(CryptoAPI)는 윈도 애플리케이션이 표준 암호 인터페이스용으로 개발될 수 있게 해준다는 점에서 또 하나의 퍼즐 조각이 될 수 있으며, 모듈에 의해 바뀌는 자체적인 기반 메커니즘을 갖고 있다. 이 모듈들은 윈도 애플리케이션이 자신들의 키 관리를 EKM 플랫폼에 통합시킬 수 있게 해주지만, CAPI를 이용하면 윈도 기반 애플리케이션에 대한 문제만 해결할 수 있으며, 암호 기능을 이용하게 될 각각의 종단 지점에 관리 애플리케이션의 조각이 설치돼 있어야 하는데, 이것은 배치시 귀찮은 일이 될 수 있다.
PKI(Public Key Infrastructure) 이니셔티브는 EKM에 핵심이 되는 많은 문제들을 다루고 있다. 사실 PKI는 보안 이메일과 인스턴트 메시징, 사용자 인증, 그리고 일종의 문서 권한 관리 등과 같은 신원정보 기반의 여러 가지 암호화 형태에 대한 키 처리 문제를 해결하고자 하고 있다. 하지만 PKI 기술은 예를 들어 테이프 백업과 같은 경우에서처럼, 특정 사용자와 연관되지 않은 암호화 키는 처리할 수 있게 돼 있지 않다.
맛뵈기 제품
서로 다른 접근 방안을 키 관리로 통합시킬 수 있는 표준이 없음에도 불구하고, 몇몇 업체들은 EKM이 갖춰야 할 모습을 맛볼 수 있는 제품을 제공하고 있다. 네오스케일(NeoScale)의 ‘크립토스토키볼트(CryptoStor KeyVault)’, 엔사이퍼(nCipher)의 ‘키오쏘리티솔루션스위트(keyAuthority Solution Suite)’와 RSA의 ‘키매니저(Key Manager)’는 모두 시작하기 좋은 제품들이긴 하지만, 통합된 업계 표준 키 관리 인터페이스가 없다는 문제가 있으며, 이들 중 어떤 것도 기존의 엔터프라이즈 환경에 들어맞거나, 현재 암호화를 하고 있는 서로 다른 모든 애플리케이션 관리를 쉽게 시작하지는 못한다.
그리고 업계에서 받아들이는 표준 없이는, 혹은 막중한 고객의 압력이 없이는, 포인트 솔루션 암호화 업체들이 이러한 현실을 바꿔 나갈 만한 동기를 부여받기 힘들다. 키 관리 제품은 여전히 한 업체의 제품으로 한정되거나, 혹은 기존의 암호화 제품에 통합하고자 하는 주요 기관들의 노력을 필요로 할 것이다.
현재로서는 기업들은 우리가 리뷰한 제품들(nwc.com/go/
0430review) 중 하나를 구입해서 그 암호화 업체에게 통합을 하도록 압력을 행사할 수 있을 것이다. 그 대안으로 자체 암호화 관리기를 개발하고자 하는 회사들에게는 엔사이퍼나 RSA 제품과 사용할 수 있는 API가 있다. 한 가지 보편적인 진실은, 하나의 완벽한 솔루션이 없다 하더라도 기업에서는 추적해야 하는 비밀과 키가 너무 많아질 때까지 기다릴 수 없다는 사실이다. 지금부터 계획을 시작해야만 최종 표준이 완성됐을 때를 대비할 수 있을 것이다.
암호화 조항들
GLBA나 SOX 같은 규정이 정말 암호화를 지시하고 있을까? 20명의 변호사와 감사자를 한 자리에 모으면 30가지의 의견이 나오겠지만, 우리 생각은 다음과 같다.
GLBA에는 암호화가 명시돼 있지 않을지 모르지만, 금융 기관에서 “비공개 개인 정보의 보안과 기밀성”을 보호해야 한다는 조항이 있다. HIPAA도 마찬가지로 직접적으로 암호화에 해당하는 형태를 설명하기보다 전자 의료 기록을 다루는 특수 지침을 만드는 일을 SHHA(Secretary of Health and Human Services) 소관으로 돌렸다. 하지만 HIPAA에는 의료 정보를 관리 및 전송하는 모든 사람은 다른 위협들 가운데서도 특히 “정보의 허가받지 않은 사용이나 공개”에 대해 데이터를 보호해야 한다는 규정이 있다. 물론 좋은 액세스 제어 및 암호화가 이러한 지시를 따르는 데 있어 근본적인 툴이 될 것이다.
SOX는 표면적으로는 정보 기술과 관련이 없어 보인다. 엔론과 월드콤 스캔들로 인해 시장이 요동을 친 이후 회사 비즈니스 및 재무 부문의 베스트 프랙티스를 지시하기 위해 만들어진 SOX는 일부 대형 조직에서의 재무 데이터 제출 프로세서에서 사용되는 시스템에 IT 제어가 존재하도록 규정하고 있다.
우발적인 공개로부터 데이터가 보호돼야 한다는 이런 모든 규정들에서 재미있는 부분은 법원에 의해 지시를 받을 때 데이터를 신속하게 수집 및 공개할 수 있어야 한다는 지시다.
연방 민사 사건이 처리돼야 하는 방식을 정하기 위해 대법원에서 제정하고 국회에서 승인한 RFCP(Federal Rules of Civil Procedure)는 2006년 e탐색 조항이 포함되어 업데이트되었는데, 이것은 증거를 만들어낼 수 없으면 유죄라는 상황을 강요하는 듯하다. 디지털 증거는 매우 쉽게 조작과 유실 및 말소가 가능하기 때문에, 새 프로시저 아래서는 암호화된 콘텐츠의 키를 잃어버리면 법에 금방 저촉될 수 있다.
FYI Define Universal
PGP의 유니버설서버(Universal Server)에는 진정한 EKM에 필요한 모든 요소들이 포함돼 있지만, 이들은 PGP 제품만을 위한 것이다. 단 PGP 서포트 포 블랙베리(Support for BlackBerry)는 여기서 예외인데, 이것은 PGP의 API를 이용해 PGP 유니버설 서버로 통합이 되는 RIM에 의해 개발된 것이다.
모두 마이크로소프트로 간다
여러 가지 기술적인 문제들에 있어 한 업체의 관련 애플리케이션만 이행을 하면 접하게 되는 문제의 수는 대폭 줄어든다. 이것은 정치적, 기술적, 혹은 다른 이유들로 인해 언제나 실현 가능하진 않지만, 전체를 마이크로소프트와 함께 하면 엔터프라이즈 암호화에 대한 필요를 충족시킬 수 있다.
마이크로소프트 암호화 아키텍처의 초석은 액티브 디렉토리(AD)며, 이는 AD가 거의 모든 마이크로소프트 엔터프라이즈 애플리케이션의 기반이라는 사실을 감안하면 놀라운 일도 아니다. 그룹 폴리시(Group Polic)를 이용해 모든 종단지점은 원격으로 지시된 IPsec 프로파일을 가질 수 있으며, 결과적으로 모든 도메인 클라이언트와 서버에서, 혹은 필요한 곳에만, 지시된 대로 종단간 암호화를 갖출 수 있다.
민감한 정보를 보관하고 있는 랩톱을 분실하는 데 대한 위험을 해결하기 위해, 마이크로소프트는 비트록커 드라이브 인크립션(BitLocker Drive Encryption)을 개발했다(실제로 이것은 볼륨 암호화기 때문에 이름은 잘못 붙인 것 같다). 비스타(엔터프라이즈와 얼티미트)와 롱혼에서 새로 선보인 비트록커는 추가 부트 패스워드나 하드웨어 토큰과 함께, 혹은 이들이 없이도 작동할 수 있으며, TPM(Trusted Platform Module) 칩이 없이 작동할 경우에는 하드웨어 토큰이 필요하다. 이전의 TPM 1.1 칩은 소용이 없을 것이며, TPM 1.2는 랩탑에 쓰이기 시작한 게 약 일년밖에 되지 않는다.
EFS(Encrypting File System)은 윈도 2000때부터 NTFS에 탑재됐지만, 기존의 NTFS 파일 시스템 이상에서만 그것과 연계돼서 작동하며 전체 드라이브를 암호화하는 데, 혹은 그 반대로 부팅시 시스템의 무결성을 보호하는 데 사용될 수 없다. 반면 비트록커는 시스템이 부팅될 때 이것을 인증할 수 있는 쉽고 효율적인(사용자 상호작용면에서) 방편으로서 암호화를 사용한다는 생각에서 특별히 고안된 것이다.
비트록커 개발에서 마이크로소프트가 중요하게 생각한 한 가지는 하드웨어와 사용자, 모두에게 그 영향력을 최소화한다는 것이었다. 따라서 디폴트 모드에서 작동할 때 비트록커는 사용자에게 어떠한 추가 단계가 필요없이 가장 일상적인 오프라인 공격들에 대해 드라이브가 암호화된 보안 상태를 유지할 수 있게 해준다.
이러한 메커니즘은 하지만 키가 TPM에서 추출이 된 후 공격자가 비트록커 프로세스를 파괴할 경우에는 희생자가 생길 수 있다. 이러한 위협이 발생할 가능성은 매우 미미하긴 하지만, 위험도가 높은 환경에서는 비트록커가 부트 프로세스의 일부로서 특수 USB 키나 PIN을 요구하도록 구성돼야 한다. 보다 엄중한 필요조건에서는 디폴트 키 길이와 다른 암호화 옵션들도 또한 조정 가능하다.
비트록커의 또 한 가지 중요한 기능은 드라이브 키가 액티브 디렉토리를 이용해 에스크로잉(escrowing) 되도록 할 수 있다는 것으로, 이는 EFS로 암호화된 콘텐츠에서 데이터 복구 대행자가 지정되게 할 수 있는 방식과 유사하다. 에스크로는 하드 드라이브나 암호화된 파일, 혹은 볼륨이 하나의 랩톱에서 다른 랩톱으로 이동될 수 있게 해주며(예를 들어 마더보드 고장시), 암호화된 데이터의 복구를 지원한다.
마이크로소프트의 윈도 2003용 RMS(Rights Management Services)는 기업에서 디지털 권한 관리 문제를 해결할 수 있게 하고자 개발됐다. RMS가 있으면 문서로의 액세스가 특정 사용자 서브세트, 혹은 심지어 행동 서브세트(읽기만 되고 출력은 되지 않는다는 식)로 제한될 수 있다. 물론 다른 조직과 문서를 공유하기 위해서는 각각의 RMS 시스템들간에 트러스트(trust)를 만들거나, RMS 지원 인프라 내 수신자용의 마이크로소프트 닷넷 패스포트 서비스를 이용하거나, 혹은 보호를 중단해야 한다.
마이크로소프트 엔터프라이즈 암호화 및 키 관리 제품의 전체 라인업은 어마어마하다. 이제 이메일 보안용 S/MIME을 완전히 지원하는 익스체인지 2003을 비롯해 키 인프라를 만들고 관리하는 윈도 서버 2003 CA(Certificate Authority), 암호화된 IM 통신을 위한 마이크로소프트 오피스 라이브 커뮤니케이션 서버(Microsoft Office Live Communications Server) 2005에 이르기까지, 기꺼이 종단간에 마이크로소프트를 이용할 의지만 있다면 매끈하게 자동으로 암호화될 수 없는 통신과 데이터 스토리지 부문을 찾기가 힘들 정도다.
수치로 보는 암호화
40 개월 : 2004년 12월 9일 이후 미 상무부의 산업안보청에서 상용 암호화 제품 수출에 관한 규정을 업데이트한 이후로 지나간 개월 수.
자료: 미 산업안보청
월 600만 개 : 워싱턴 대학의 커뮤니케이션 조교수인 필 하워드의 조사에서 2007년에 훼손된 것으로 보고된 미국의 개인 데이터 기록 수.
자료: UW 뉴스
550건 : 1980년과 2006년 사이에 확인된 데이터 공개 사건 수. 이들 가운데 60%는 하드웨어 분실이나 도난 등 조직의 관리 소홀로 인한 것이었다. 악성 침입이 31%를 차지하며, 기타 침해가 나머지 9%를 차지한다고 하워드는 밝혔다. 자료: UW 뉴스
184.6 킬로미터 : 지금까지 알려진 것들 중 가장 안전한 데이터 보호 방안인 퀀텀(quantum) 암호화용으로 키를 배포하는 데 있어 보고된 거리들 가운데 최장 거리. 이 작업은 LANA(Los Alamos National Laboratory)와 NIST(National Institute of Standards and Technology) 그리고 미시건 알비온 대학의 과학자들에 의해 수행되었다. 자료: LANL/NIST
좋은 암호와 나쁜 암호
영화 “스니커즈” 중에서 가장 멋진 장면 가운데 하나는 보안 컨설턴트들이 두 개 집단으로 나뉘면서 시작된다.한 쪽에서는 스크래블을 하고 있고, 다른 한 쪽에서는 “복구(recovering)"하도록 명령받은 위조 자동응답장치를 해킹하고 있다.
이 블랙박스에 대해 이들이 아는 유일한 한 가지는 코드 네임이 “Setec Astronomy"라는 것뿐이다. 스크래블을 하던 사람들이 코드 네임이 두문자어가 아니라 철자가 바뀌어 만들어진 단어라는 사실을 알아내자 해커들은 장비에 숨겨진 특수 칩을 탐색하기 시작하고, 마침내 어떤 암호화 방안이든 크랙킹할 수 있는 알고리즘을 찾아낸다.
어느 순간 진짜 코드 네임이 스크래블 테이블에서 한자 한자 드러나는데, 그것은 바로 ”too many secrets"였다.
대부분의 컴퓨터들은 현대의 암호 키를 짐작할 수 있을 만큼 충분한 비트를 처리하기에는 많이 역부족이기 때문에, 우리의 암호화가 갑자기 풀릴 가능성은 다행히도 얼마 되지 않는다. 하지만 우리가 암호화하고 있는 비밀의 수는 엄청난 속도로 늘어나고 있으며, 암호 방안을 선택하는 일은 쉽지 않을 수 있다.
‘좋은 암호’와 ‘나쁜 암호’는 가끔씩 같아 보이기도 하지만 결코 속아 넘어가서는 안 된다. 나쁜 암호로 소중한 비밀을 시키고 싶어하는 사람은 없을 것이기 때문이다.
좋은 것과 나쁜 것을 구분할 수 있는 몇 가지 팁을 소개한다.
좋은 암호: 암호 커뮤니티에서 오랫동안 면밀히 검토해 온 역사가 있다.
나쁜 암호: “아무도 내가 어떻게 돌아가는지 이해하지 못하기 때문에 나는 안전하다!”고 주장한다.
좋은 암호: FIPS 140-2와 같이 명망 있는 표준에 의해 검증됐다.
나쁜 암호: FIPS 140-2 모듈 검증과 FIPS 암호를 사용하는 것간에 차이가 있다는 언급이 없이 “FIPS 암호도 사용한다!”고 말한다.
좋은 암호: 비트록커가 엘리펀트 디퓨저(Elephant Diffuser)에서 AES CBC를 사용하도록 신중히 고안된 것처럼, 적재적소에 맞는 툴을 사용한다. 암호 프로토콜의 선택을 돕기 위해 마이크로소프트에서 내놓은, 읽고 이해하기가 너무도 쉬운 가이드에 있는 알고리즘 선택에 대한 설명을 보라.
나쁜 암호: 적용이 가능한지 여부에 관계없이 듣기좋은 말이면 무엇이든(친숙한 이름일수록 더 좋다) 다 마케팅 자료로 사용한다. |
|
|
|
|
|
|
|
|
|
| ⓒ 데이터넷(http://t564.ndsoftnews.com) 무단전재 및 재배포금지 | 저작권문의 |
|
|
|
|
|
|
| |
| 가장 많이 본 기사 |
|
|
 |
|
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
