Security Watch

EFS 배포: 1부

John Morello

랩톱 도난이나 방치로 인해 개인 데이터나 중요한 데이터가 손실되었다는 보고를 들어 보지 않은 사람은 없을 것입니다. 랩톱 분실은 아주 흔한 일입니다. ID 도용이 증가하고 규정 준수가 그 어느 때보다도 중요해진 상황에서 모바일 컴퓨팅 시스템의 데이터를 철저하게 보호하는 것은 필수적입니다.

한 가지 해결 방법은 Windows 2000부터 Windows®에 포함되었으며 고성능의 디스크 기반 암호화를 기본적으로 제공하는 EFS(파일 시스템 암호화)를 사용하는 것입니다. EFS는 Windows 탐색기와 완벽하게 통합되므로 최종 사용자는 대개 사용 중인 파일이 언제 암호화되는지조차 알지 못합니다. 또한 기본 Windows 인증 및 액세스 제어 기술과도 동등하게 잘 연동되므로 사용자는 데이터 액세스를 위해 별도의 암호를 기억할 필요가 없습니다. 마지막으로 사용자가 자신의 암호화 키에 액세스할 수 없는 경우(예: 사용자 프로필이 삭제 또는 손상되었거나 스마트 카드가 분실된 경우) 데이터를 복구할 수 있도록 관리하기 쉬운 옵션을 제공합니다.

EFS는 Windows에서 기본적으로 제공하는 암호화 기술을 사용하여 강력한 암호화 키를 생성, 저장 및 배포함으로써 데이터를 보호합니다. Windows XP 서비스 팩 1(SP1) 이상 버전에서 EFS는 AES(고급 암호화 표준) 알고리즘을 256비트 키와 함께 사용하여 디스크의 데이터를 암호화합니다. 이러한 대칭 키는 비대칭(RSA) 키 쌍으로 보호됩니다. EFS는 AES 키를 사용하여 각 파일을 암호화한 다음 사용자의 RSA 키를 사용하여 이 키를 암호화하고 그 결과를 파일에 저장합니다. EFS 암호화에 대한 자세한 내용은 "EFS 리소스" 추가 기사를 참조하십시오. 지금은 EFS의 기술적인 토대에 초점을 맞추지 않고 EFS를 배포하고 현재 환경에서 작동되도록 하는 방법에 대해 중점적으로 다루겠습니다. 따라서 이 문서에서는 독자가 EFS 암호화 개념을 이미 이해하고 있다는 전제 하에 설명합니다.

EFS 보안 참고 사항

EFS 암호화를 해독하거나 손상시킬 수 있다고 주장하는 응용 프로그램이 있습니다. 이러한 응용 프로그램은 AES (또는 DES(데이터 암호화 표준)나 DESX(Expanded Data Encryption Standard))로 암호화된 암호 텍스트를 실제로 해독하는 것이 아니라 사용자 암호를 무작위로 추측하여 사용자의 EFS 개인 키에 대한 액세스 권한을 얻는 것입니다. EFS 암호화에 대해 유념해야 할 중요한 사항은 암호화된 데이터를 생성하고 보호하는 데 사용되는 개인 키는 DPAPI(데이터 보호 API)를 사용한다는 점입니다. DPAPI는 사용자 로그온 자격 증명에서 파생된 정보를 이용하여 데이터를 보호하므로 EFS를 사용한 데이터 보호 수준은 사용자 암호에 의해 결정됩니다. Windows Vista™에서는 이제 EFS 암호화 인증서를 스마트 카드에 저장할 수 있게 됨에 따라, 이 패러다임이 달라질 뿐 아니라 EFS로 보호된 데이터의 상대적 보안이 크게 강화됩니다.

암호가 공격에 견디려면 얼마나 길어야 할까요? 오늘날의 하드웨어 성능과 최신 암호 공격 알고리즘을 고려할 때 11자 이상의 암호(또는 보다 정확하게 암호 구문)를 사용하는 것이 좋습니다. 11자 이상의 암호 구문은 미리 계산된 해시 공격(예: 레인보우 테이블)을 비롯한 오늘날의 최첨단 공격 방식에 매우 잘 대응합니다. 레인보우 테이블에 대한 자세한 내용은 "리소스" 추가 기사에 나열된 "Why you shouldn't be using passwords of any kind on your Windows networks"(영문)가 게시된 블로그를 참조하십시오.

PKI 사용 여부 결정

EFS에 대한 가장 흔한 오해 중 하나는 EFS를 사용하려면 PKI(공개 키 인프라)가 작동해야 한다는 것입니다. EFS는 PKI와 쉽게 통합되고 PKI를 활용할 수 있으므로 조직에 이미 PKI가 있을 수는 있지만 PKI가 반드시 있어야 하는 것은 아닙니다. 하지만 EFS 배포에서 PKI를 사용할 것인지 여부에 따라 배포와 관련된 추후의 여러 사항들이 다르게 결정될 수 있으므로 PKI 사용 여부를 먼저 검토해야 합니다.

EFS와 함께 PKI를 사용할 경우의 기본적인 이점은 키 보관 및 복구를 수행할 수 있다는 점입니다. 데이터 복구의 경우 관리자가 EFS만 사용해도 수행할 수 있지만, 자동 키 복구는 PKI를 함께 사용할 경우에만 가능합니다. 그 경우라도 Windows Server® 2003 Enterprise Edition을 CA(인증 기관)으로 실행해야만 가능합니다. 데이터 복구는 자신의 암호화 키에 액세스할 수 없는 사용자가 자신의 암호화된 데이터를 DRA(데이터 복구 에이전트)라고 알려진 지정된 관리자에게 제공할 수 있는 프로세스로서, DRA는 이 데이터를 해독한 다음 해당 사용자에게 다시 보내거나 새 개인 키와 함께 사용할 수 있도록 다시 암호화합니다. DRA는 사용자의 암호화 프로세스에서 보이지 않게 작업을 수행하는데, 이로 인해 사용자가 자신의 키를 사용하여 암호화하는 모든 내용도 DRA 키 복사본을 사용하여 암호화됩니다. 따라서 사용자 키를 분실한 경우 DRA는 이 과정에 개입하여 암호 텍스트 데이터를 가져와서 DRA 키를 이 데이터에 적용하여 해독(또는 다시 암호화)한 다음 데이터를 사용자에게 돌려보낼 수 있습니다. DRA 접근 방법은 잘 작동하지만 사용자가 대용량의 데이터를 암호화했거나 DRA 역할을 수행할 로컬 IT 직원이 없을 경우에는 관리하기 어려울 수 있습니다.

반면 키 복구를 사용하려면 키 생성 프로세스 중 CA에서 사용자 암호화 키 복사본을 만들어 이 키 복사본을 CA의 데이터베이스에 안전하게 저장해야 합니다. 그러면 사용자가 암호화된 파일에 액세스할 수 없을 경우 CA 관리자가 이 데이터베이스에 액세스하여 사용자 키를 검색하기만 하면 됩니다. 이때 사용자는 DRA에 데이터 복구를 의뢰할 필요 없이 즉시 자신의 데이터에 다시 액세스할 수 있습니다. 이와 같은 방식으로 수행될 경우 키 복구가 보다 빠르고 효율적으로 수행될 수 있습니다. 그러나 키 복구를 사용하는 경우라도 DRA를 항상 지정하여 키 분실에 대비한 백업 메커니즘을 제공하는 것이 최선의 방법입니다. 그러면 대규모 조직에서도 PKI 관리자 그룹에 참여할 필요 없이 로컬 IT 관리자가 사용자 데이터를 복구할 수 있는 분산된 복구 시스템을 사용할 수 있습니다.

EFS와 함께 PKI를 사용할 경우 얻을 수 있는 또 다른 이점은 암호화된 파일을 보다 쉽게 공유할 수 있다는 점입니다. EFS는 랩톱 시스템에만 국한되어 사용되는 것이 아니라 컴퓨터의 물리적 보안을 보장할 수 있는 모든 상황에서도 마찬가지로 아주 유용하게 활용할 수 있습니다. 이러한 상황에서는 여러 명의 사용자가 암호화된 동일한 파일에 액세스해야 할 수 있습니다. Windows에서는 디렉터리가 아닌 개별 파일의 공유만 허용하기 때문에 암호화된 파일의 공유에 대한 지원이 다소 제한적이므로 PKI가 유용한 도구가 될 수 있습니다. EFS 파일을 쉽게 공유하기 위해서는 파일을 공유하는 사용자가 함께 공유하고 있는 다른 사용자들의 공개 키에 액세스할 수 있어야 하는데, 가장 쉬운 방법은 다른 사용자들이 올바른 EFS 인증서를 Active Directory®의 자신의 계정에 게시한 경우입니다. 수동으로 게시할 수도 있지만 엔터프라이즈(Active Directory에 통합) 모드로 설치된 Windows CA를 사용하여 이 프로세스를 완전히 자동으로 수행할 수 있습니다.

EFS 키 관리

Windows Server 2003 기반 PKI를 사용할 수 있는 경우 사용자의 EFS 인증서를 생성하는 과정은 간단합니다. Windows Server 2003 CA는 기본 EFS라는 인증서가 포함된 기본 인증서 템플릿 집합과 함께 제공됩니다. 그러나 이 템플릿은 버전 1 템플릿이므로 키 보관을 지원하지 않습니다. 따라서 CA에서 이 템플릿을 사용할 수 있도록 하기 전에 먼저 템플릿을 복제하여 새로운 버전 2 템플릿을 만들 수 있는데, 예를 들면 그림 1에 나타난 것처럼 "키 보관이 가능한 EFS"라고 이름을 붙일 수 있습니다. 이 새 템플릿에서 요청 처리 탭으로 이동하여 사용자의 암호화 키를 보관하는 옵션을 선택합니다. 이 옵션을 사용하기 위해서는 먼저 CA에 키 보관이 적절하게 구성되어 있어야 합니다. 리소스 섹션에 이 프로세스의 세부 단계가 나와 있습니다. 클라이언트에서 이 새로운 버전을 사용하게 하려면 이 템플릿이 기본 EFS 템플릿을 대체하도록 설정해야 합니다(그림 2 참조).

그림 1 키 보관이 가능한 EFS (Click the image for a smaller view)

그림 1 키 보관이 가능한 EFS (Click the image for a larger view)

그림 2 기본 EFS 템플릿 대체 (Click the image for a smaller view)

그림 2 기본 EFS 템플릿 대체 (Click the image for a larger view)

이제 올바른 사용자 집합이 템플릿에 대한 액세스 권한을 등록할 수 있도록 템플릿에 대해 적절한 권한을 설정해야 합니다. Windows의 EFS 구성 요소는 EFS가 처음 사용될 때 자동으로 인증서를 요청하므로 일반적으로 사용자가 EFS 템플릿에 자동으로 등록하도록 허용할 필요가 없습니다. 자동 등록된 모든 사용자가 EFS를 사용할 것이 확실하지 않다면 EFS 인증서에 대한 자동 등록을 사용하지 않는 것이 좋습니다. 그림 3은 EFS 등록 설정을 보여 줍니다. EFS를 사용할 가능성이 없는 사용자에게 인증서를 발급하면 CA 데이터베이스의 크기만 커질 뿐 아무런 이점도 없습니다. CA 데이터베이스 자체에 대한 크기 제한은 없지만 발급된 인증서가 많아질수록 관리, 특히 MMC(Microsoft Management Console)를 통한 관리가 어려워질 수 있습니다.

그림 3 EFS 사용자 권한 설정 (Click the image for a smaller view)

그림 3 EFS 사용자 권한 설정 (Click the image for a larger view)

끝으로, 암호화된 파일의 공유를 지원해야 할 경우 CA에서 자동으로 사용자의 인증서를 Active Directory에 게시하도록 할 수 있습니다.

CA에 템플릿이 적절하게 구성되면 EFS를 사용하여 파일을 처음 암호화할 때 사용자는 CA에서 자신의 인증서를 가져오며 CA는 사용자의 개인 키를 자동으로 보관합니다.

DRA 키 관리

PKI가 적절히 설정된 경우 다음으로 고려해야 할 사항은 CA에서 생성한 DRA 인증서를 사용할지 여부입니다. PKI의 DRA 인증서를 사용하지 않으려는 이유는 무엇일까요? 인증서 유효 기간을 매우 짧게(2년 이하) 발급하는 CA가 있다고 가정해 보겠습니다. 이 CA는 이보다 유효 기간이 긴 인증서는 발급할 수 없으므로 DRA 인증서의 유효 기간은 길어야 2년입니다. 이로 인해 데이터 복구 시나리오가 상당히 복잡해질 수 있습니다. 이와 같은 가상 예제를 보여 주는 다음과 같은 시나리오를 생각해 볼 수 있습니다.

1. 2006년 1월 한 사용자가 파일을 암호화했는데, 그룹 정책을 통해 자신의 컴퓨터로 보내진 DRA 인증서의 유효 기간은 2년입니다. 즉, 2008년 1월에 만료됩니다.
2. 이 사용자는 그때까지 EFS를 사용하여 새 파일을 암호화합니다.
3. 2008년 1월 DRA 인증서가 만료되어 관리자가 그룹 정책을 통해 새 인증서를 사용자에게 보냅니다.
4. 따라서 이 이후로 수행된 모든 암호화 작업에는 새 DRA 인증서가 사용되지만(이전 DRA를 사용하여 암호화된 파일을 여는 경우 이 파일이 저장될 때는 새 DRA가 사용됨) 이 사용자가 손대지 않은 파일은 여전히 이전 DRA에 의해 보호됩니다.
5. 그런데 실수로 사용자의 프로필이 손상되어 데이터 복구가 필요한 상황이 발생합니다.
6. IT 관리자는 이제 두 개의 DRA 인증서 집합을 가지고 있어야 합니다. 하나는 3단계 이후에 사용된 파일을 위한 새 인증서이고, 다른 하나는 3단계 이후에는 사용되지 않은 파일에 대한 이전 인증서입니다.

IT 관리자가 3단계 이후에 스크립트를 실행하여 모든 파일을 새 DRA로 업데이트할 수는 있지만(cipher.exe /u 사용) 이를 수행하려면 시간이 많이 걸립니다. 또한 만료된 DRA 인증서가 복구 정책에 포함되어 있을 경우 EFS 구성 요소가 어떠한 새로운 암호화 작업도 허용하지 않는다 할지라도, 만료 날짜에 도달한 후에 DRA 키 쌍이 필요할 수 있습니다. 물론 만료된 DRA 키 쌍으로 암호화된 이전 파일은 여전히 이 키 쌍을 사용하여 복구할 수 있습니다. 따라서 유효 기간이 만료된 후라도 DRA 키 쌍이 필요한 경우가 있을 수 있으므로 DRA 키 쌍은 절대 제거해서는 안 됩니다.

이러한 이유로 CA의 인증서 유효 기간이 짧은 환경에서는 유효 기간이 이보다 긴 자체 서명 DRA 인증서를 사용하는 것이 좋습니다. 암호화 유틸리티에는 유효 기간이 100년인 EFS 복구 에이전트 키 쌍을 자동으로 만드는 스위치(cipher.exe /r)가 포함되어 있습니다(그림 4 참조). 이 키 쌍의 인증서는 GPO(그룹 정책 개체)에 연결되어 조직 전체에서 DRA로 사용될 수 있습니다. EFS 구성 요소는 DRA 인증서의 신뢰 체인을 검사하지 않으므로 이러한 자체 서명 인증서는 시스템에서 신뢰할 수 있는 루트 인증 기관 목록을 변경하지 않고도 작동합니다. 조직의 CA 유효 기간과는 무관하게, 이보다 유효 기간이 긴 DRA 인증서를 최소한 하나 만들어 이를 도메인 전체에 적용되는 GPO에 연결하는 것이 좋습니다. 이는 다른 모든 옵션을 사용할 수 없는 경우에 사용할 대체 데이터 복구 옵션으로, 보관된 CA 키가 없어 CA에서 생성한 DRA 키를 사용할 경우에 특히 필요한 옵션입니다. DRA 인증서는 손상되어서는 안 되므로 새 인증서로 GPO를 업데이트한 다음 앞에서 설명한 cipher.exe /u를 사용하여 파일을 업데이트할 수 있습니다.

그림 4 Ciquer /R 실행 (Click the image for a smaller view)

그림 4 Ciquer /R 실행 (Click the image for a larger view)

EFS 리소스

EFS에 대한 세부 사항 및 유용한 방법에 대한 자세한 정보를 보려면 다음 사이트를 방문하십시오

• Why you shouldn't be using passwords of any kind on your Windows networks(영문)
• Implementing Key Archival Walkthrough(영문)
• Encrypting File System in Windows XP and Windows Server 2003>(영문)

KRA 및 DRA 배포

키 보관을 통해 CA 관리자는 사용자를 대신해서 보관된 암호화 키를 복구할 수 있습니다. 이 경우 CA에서 서명한 키를 사용한 조직의 데이터를 CA 관리자가 해독할 수 있으므로 이는 매우 민감하면서도 강력한 기능입니다. 따라서 키 보관 및 복구는 매우 신중하게 처리해야 하며 소수의 신뢰할 수 있는 보안 직원에게만 이 권한을 부여해야 합니다. 키 복구는 매우 민감한 사안이므로 EFS 암호화 데이터에 다시 액세스하는 기본 메커니즘으로 키 복구를 사용할 때에는 복구 요청을 CA 관리 팀으로 보내기 위한 단계적 프로세스를 명확하게 정의하는 것이 중요합니다. 복구 요청을 신중하게 검토한 후에만 복구 프로세스를 시작해야 합니다. 복구된 키로는 모든 사용자의 EFS 보호 데이터에 액세스할 수 있으므로 키가 실제로 복구되면 안전한 방법으로(즉, 전자 메일을 통해 보내선 안 됨) 사용자에게 제공해야 합니다.

KRA(키 복구 에이전트) 키는 생성되면 CA 관리자에 의해 보관되므로 그룹 정책을 통해 알려지지 않습니다. 실제로 EFS 자체에서는 사용되는 키가 보관되었는지 여부를 확인할 수 없으므로 평상시대로 단순히 암호화 작업만 수행합니다. 또한 CA에서 생성된 KRA 키는 EFS에만 국한되지 않습니다. 키 보관을 사용하는 CA의 경우 CA 수준에서 n개의 KRA 키가 첨부되어 CA에 의해 보관된 키를 보호하는 데 사용됩니다. 이러한 키에는 EFS와 함께 사용된 키, 보안 전자 메일에 사용된 키 또는 암호화가 포함된 기타 인증서 용도로 사용된 키 등이 있습니다. KRA 키는 개별 키 복구 에이전트에 의해 안전하게 저장되어야 하며 키 하나를 분실하더라도 다른 키를 사용할 수 있도록 적어도 두 개의 KRA를 사용해야 합니다.

관리자가 새로 만들어진 도메인의 도메인 컨트롤러에 처음 로그인하면 DC의 관리자 프로필에 저장된 자체 서명 인증서와 키 쌍을 사용하여 도메인 수준에서 기본 복구 정책이 만들어집니다. 이 DRA 인증서의 유효 기간은 3년입니다. 이 기본 인증서를 제거하고 유효 기간이 이보다 긴 자체 서명 인증서나 PKI에서 발급한 인증서로 대체하는 것이 좋습니다. 이 기본 자체 서명 인증서를 제거하지 않을 경우 인증서를 만든 지 3년이 경과하면 EFS는 더 이상 도메인을 통해 새 파일을 암호화하지 않습니다. 이는 인증서가 만료되었으므로 만료된 DRA 인증서가 복구 정책에 포함되어 있을 경우 EFS에서 더 이상 데이터를 암호화하지 못하게 하기 때문입니다. Windows XP 이상의 시스템은 복구 에이전트 정책 없이도 작동할 수는 있지만 이 방법은 사용하지 않는 것이 좋습니다. 이 방법을 사용하면 사용자가 어떤 이유로든 자신의 암호화 키에 액세스할 수 없고 키 복구도 가능하지 않은 경우 모든 데이터가 영구적으로 손실될 수 있습니다.

이미 설명한 것처럼 DRA 키는 자체 서명된 키이거나 CA에서 발급한 키일 수 있습니다. 대부분의 경우 여러 키를 혼용하는 것이 가장 바람직한데 최소한 2개의 자체 서명된, 유효 기간이 긴 DRA를 기업 전체에서 최후의 복구 에이전트로 사용하는 것이 좋습니다. DRA 인증서는 그룹 정책 개체를 통해 배포되므로 다른 GPO와 동일한 상속 기능을 갖습니다. 즉, 다른 GPO 설정의 적용을 제어하는 표준 로컬, 사이트, 도메인, OU(조직 구성 단위) GPO 누적 및 적용 알고리즘도 DRA에 적용됩니다. 따라서 조직에서는 중앙 IT 그룹이 기업의 모든 부문에 대한 DRA 액세스 권한을 가지고 있지만 로컬 IT 그룹도 특정 담당 영역에 대해서는 기능을 유지 관리하는, DRA에 대한 계층형 접근 방식을 쉽게 구현할 수 있습니다. 이 접근 방식은 WAN 링크를 통해 대용량의 암호화된 데이터를 전송할 필요가 없어 데이터 복구를 수월하게 수행하므로 특히 지리적으로 분산된 대규모 조직에서 유용하게 사용할 수 있습니다. 그림 5는 여러 계층으로 구성된 일반적인 DRA 배포를 보여 줍니다.

그림 5 여러 계층으로 구성된 DRA 배포

이 경우 Baton Rouge OU의 사용자는 암호화된 파일마다 6개의 DRA를 갖습니다. 즉, 로컬 관리자로부터 두 개, North America IT 그룹에서 두 개, 도메인 수준에서 두 개를 받게 됩니다. 따라서 사용자가 자신의 암호화된 데이터에 액세스할 수 없을 경우 North America IT 그룹 또는 Baton Rouge의 로컬 DRA에 의해 데이터를 복구할 수 있습니다. 이러한 네 개의 DRA를 사용할 수 없거나 손실한 경우 최후의 대체 방법으로 도메인 수준 DRA를 사용하여 데이터를 복구할 수도 있습니다. 어떤 DRA가 복구를 수행했는지에 관계없이 복구 프로세스는 본질적으로 동일합니다. 먼저 사용자는 데이터를 DRA에 제공합니다. DRA는 요청이 합법적이고 실제 데이터 소유자로부터 보내진 것인지 확인하기 위해 필요한 단계를 수행해야 합니다. 이 단계를 완료한 후 DRA는 DRA 인증서를 로드하고 데이터를 해독(및 가능하면 다시 암호화)한 다음 데이터를 다시 최종 사용자에게 보냅니다. 경우에 따라 일부 조직에서는 DRA가 문제가 되는 사용자를 실제로 찾아 이 사용자의 DRA 키 쌍을 프로필로 로드한 다음 데이터를 해독하고 키 쌍을 제거하는 로컬 복구를 수행하기도 합니다. 이제 사용자는 일반 텍스트 형식의 데이터에 액세스할 수 있게 되고 새로운 키를 사용하여 데이터를 다시 암호화할 수 있습니다. 이 접근 방법은 DRA 키 쌍이 일시적이기는 하지만 로컬 컴퓨터에 복사되기 때문에 별로 안전하지 않다는 단점이 있지만, 특히 많은 양의 데이터를 복구해야 할 경우에는 시간을 다소 절약할 수 있습니다.

복구가 키 보관 및 복구를 통해 사용자에게 제공되어야 하는 경우 복구 요청은 이 프로세스와는 완전히 별도로 처리됩니다. DRA를 사용하는 대신 사용자의 키 복구 요청이 CA 관리자에게 전달되고 CA 관리자는 요청을 검사한 다음 사용자의 개인 키를 보관하고 검색해야 합니다. 그런 다음 이 개인 키를 다운로드할 수 있도록 보안 웹 사이트에 배치하는 등의 안전한 방식으로 사용자에게 제공합니다. 사용자가 스마트 카드를 사용하여 Windows Vista에서 사용할 수 있는 EFS 키를 저장하는 경우 키도 다시 발급해야 합니다. 사용자는 이 키를 자신의 프로필로 로드하여 암호화된 모든 데이터에 즉시 액세스할 수 있습니다.

DRA 및 KRA 키 쌍은 중요한 데이터를 해독하는 데 사용될 수 있으므로 적절히 보호하는 것이 중요합니다. 따라서 이들 키 쌍은 관리자의 일반 데스크톱 프로필(관리자가 일상적인 업무를 수행하는 데 사용하는 프로필)에 저장해서는 안 되며, 플로피 미디어, 광 미디어 또는 플래시 미디어에 오프라인으로 안전하게 저장하여 물리적으로 안전한 장소에 보관해야 합니다. 그러면 복구가 필요할 때 복구 에이전트에서 이러한 미디어에 있는 키 쌍을 복구 워크스테이션으로 로드하여 복구 작업을 수행한 다음 이들 키 쌍을 제거할 수 있습니다. 특별히 보안에 민감한 몇몇 조직에서는 이러한 키 쌍에 대한 보안을 강화하기 위해 복구 전용의 워크스테이션을 지정하기도 하는데, 모든 조직에서 이 방법을 사용할 필요는 없습니다.

다음 기사 소개

이번 기사에서는 EFS 계획의 키 관리, 데이터 복구 및 Active Directory 측면을 살펴봤으므로 다음 달에 발표될 이 기사의 2부에서는 클라이언트 쪽 배포 질문에 대해 중점적으로 다룰 것입니다. 또한 그룹 정책을 통한 EFS 사용 제어, 암호화할 항목 선택, 로그온 스크립트를 통한 데이터 자동 암호화, EFS 보호 데이터를 보다 쉽게 사용할 수 있도록 하는 Windows 탐색기의 클라이언트 쪽 개선 사항 등에 대해 설명할 것입니다.

---

John Morello는 LSU를 수석으로 졸업했으며 지난 6년 동안 Microsoft에서 다양한 업무를 담당했습니다. 시니어 컨설턴트로서 Fortune 100대 기업 및 연방 민간 및 방어 클라이언트용 보안 솔루션을 설계하였으며, 현재는 Windows Server 그룹의 프로그램 관리자로서 보안 및 원격 액세스 기술을 담당하고 있습니다.