보안

디지털 인증서를 사용하여 전자 메일 보안

Matt Clapham and Blake Hutchinson

한 눈에 보기:

• 확인 가능한 ID 만들기
• 인증서 상태 업데이트
• 인증서 얻기 및 교환
• S/MIME 시스템 문제 해결

오래 전부터 사람들은 전송 중 정보 숨기기, 보낸 사람 확인 및 메시지 인증을 위해 다양한 방법을 사용해 왔습니다. 사회가 발달하면서 이 세 가지를 한 번에 해결하는 방법이 개발되었고 널리 사용되기 시작했습니다. S/MIME(Secure Multi-Purpose Internet Mail

Extensions)은 암호화 및 디지털 서명을 사용하여 전자 메일을 안전하게 보내는 시스템입니다.

현재의 암호화(숨기기) 기술은 크게 두 가지로 나눌 수 있는데, 하나는 DES(Data Encryption Standard) 또는 AES(Advanced Encryption Standard)와 같은 대칭(비밀) 키 알고리즘이고 다른 하나는 RSA 또는 ECC(Elliptical Curve Cryptography)와 같은 비대칭(공개/개인) 키 알고리즘입니다. 보낸 사람을 확인하는 이 현대적 도구는 해시라고 불리며, 고유한 서명을 만드는 수학적 단방향 함수입니다. 많이 사용되는 두 가지 해시 방법은 MD5(Message Digest Algorithm 5) 및 SHA(Secure Hash Algorithm)입니다. 컴퓨터는 이 방법으로 개별 원본 텍스트에 대응하는 고유한 해시 또는 숫자를 생성할 수 있습니다(동일한 원본 텍스트는 동일한 값으로 해시됨). 이 간단한 도구를 토대로 조합하여 만들어진 것이 PKI(공개 키 인프라) 시스템입니다.

확인 가능한 ID

인증 기관 리소스

• 암호화 파일 서비스를 위해 인증 기관 사용
• 네트워크에서 인증 기관 서버 이름을 바꾸거나 제거할 수 없음
• 도메인의 컴퓨터에서 신뢰할 수 있는 인증 기관을 제거하는 방법
• Windows 엔터프라이즈 인증 기관 역할을 해제하고 Windows Server 2003 및 Windows 2000 Server에서 모든 관련 개체를 제거하는 방법
• 인증 기관을 도메인 컨트롤러에서 실행 중인 새 서버로 이동하는 방법

PKI 시스템에서 디지털 인증서를 사용하여 관리되는 ID는 대부분의 사람들이 국경을 넘을 때 소지해야 하는 정부 발급 신분증, 즉 여권과 다르지 않습니다. 디지털 인증서 세계의 여권 표준은 S/MIME, IPsec(Internet Protocol Security), SSH(Secure Shell), 무선 네트워크 보안, VPN(가상 사설망), 보안 서버 통신(예: SSL 웹 사이트) 등의 기술에서 서명 및 암호화를 위해 널리 사용되는 X.509 형식입니다.

인증서는 비대칭 암호화 및 해시를 기반으로 작성됩니다. 인증서를 만들려면 요청자(상위 기관에서 서명한 키를 원하는 엔티티)가 개인 키를 생성해야 합니다. 이 키는 유효성이 의심되지 않도록 잠겨 있습니다. 개인 키와 함께 그 짝이 되는 공개 키도 생성됩니다. 이름에서 알 수 있듯이, 한 쌍의 키에서 공개되는 키 부분은 비밀이 아니며 유효성이 보장되는 방식으로 자유롭게 배포됩니다.

이 키 쌍은 두 가지 기본 기능을 수행합니다. 첫째, 누구든지 공개 키로 암호화하고 이것이 개인 키로만 해독되도록 할 수 있습니다. 둘째, 개인 키로 암호화된 것을 공개 키로 해독할 수 있습니다. 이것은 개인 키로만 만들 수 있는 서명을 확인하는 데 중요합니다.

인증 기관에 보내는 요청에는 해당 키를 사용할 개인이나 컴퓨터의 ID, 알고리즘 유형 및 강도, 키 쌍의 공개 부분과 같은 정보가 포함됩니다. 인증 기관(CA)은 요청의 정보를 수신하여 검증하고, 해시 알고리즘을 사용하여 이 정보에 맞는 고유한 식별자를 만듭니다.

CA는 개인 키를 사용하여 정보의 해시를 암호화하고 이를 표준 형식(X.509 등)으로 조합하여 원래 요청에 따른 인증서를 만듭니다. X.509 인증서에는 인증서의 ID(주체), 유효 기간, 공개 키, 인증서 용도 등의 클레임 목록이 포함됩니다. 그런 다음 이 인증서를 요청자에게 반환합니다. 사실 인증서는 "본 인증 기관(CA)은 이 공개 키와 그에 해당하는 개인 부분이 여기 설명된 모든 용도에 적합함을 보증합니다"라고 말하는 토큰입니다.

루트 CA(신뢰 체인의 최상위 CA)의 인증서는 자체 서명됩니다. 널리 통용되는 루트 CA는 기본 운영 체제 또는 응용 프로그램에 미리 설치되어 있으며 패키지 또는 엔터프라이즈 구성을 통해 업데이트하거나 변경할 수 있습니다. 루트 CA와 리프 노드(대개 개인 또는 개별 시스템) 사이에는 하나 이상의 중간 CA가 있을 수 있습니다.

이 체인은 모든 노드 및 노드에 포함된 모든 상위 인증서(해당 수준의 CA 서명)로 구성됩니다. 제3자가 인증서의 유효성을 검사할 때는 로컬에서 계산된 해시를 확인하고 해당 CA 또는 개인의 공개 키를 사용하여 인증서에서 해독한 값과 계산된 값을 비교합니다. 그러면 최하위에서 루트까지 유효성이 완벽하게 검사된 신뢰 체인이 완성됩니다. 물론 루트를 신뢰할 수 있어야 합니다.

인증서 상태 업데이트

모든 정상적인 CA에는 더 이상 신뢰할 수 없는 인증서 목록을 배포하는 방법이 있습니다. 이 인증서 해지 목록(CRL)은 해당 CA가 특별히 무효화한 발급 항목을 설명합니다. 편의상 CRL은 대개 CA 인증서의 속성에 위치합니다.

CA는 정기적으로 일정(예: 2주마다) 또는 이벤트(발급된 인증서를 더 이상 신뢰할 수 없는 상황)의 두 가지 기준으로 CRL을 발행합니다. 그리고 발행된 CRL에 CA 서명을 하여 게시합니다. 수신 시스템에서 체인의 유효성을 평가할 때는 대개 해당 체인에 속하는 각 발행 CA의 CRL을 확보하려고 합니다(인증서 자체에 포함된 정보 또는 사전 정의된 신뢰할 수 있는 배포 메커니즘 이용). CRL을 얻을 수 없는 경우, 클라이언트는 최근 캐시에 저장된 복사본 중 지정된 CRL 업데이트 기간보다 오래되지 않은 것을 사용할 수 있습니다. 이것도 실패하면 클라이언트 시스템에서는 인증서가 유효한 것 같지만 해지 상태를 확인할 수 없음을 나타내는 일종의 오류를 표시합니다.

많은 응용 프로그램의 경우, 체인 또는 체인에 포함된 각 노드의 CRL을 검증할 수 없으면 인증서를 로드하는 데 시간이 오래 걸립니다. 인증서의 보호 대상이 무엇인지에 따라 사용자가 신뢰하기도 하고 않기도 합니다. 모든 CA, 특히 공개 루트에는 정기적으로 업데이트되고 널리 사용 가능한 CRL 배포 지점이 반드시 있어야 합니다.

루트는 인증서 체인의 토대이며, 체인화는 모든 인증서 계층의 토대입니다. 대부분의 클라이언트 시스템이나 응용 프로그램에서는 신뢰할 수 있는 루트와 체인으로 연결된 경우에만 리프 노드 인증서가 유효하다고 간주합니다. 여기서 신뢰할 수 있는 루트란 특정 회사가 소유 및 운영하는 엔터프라이즈 CA 또는 공개 루트 CA(VeriSign 등) 등입니다.

공개 루트 CA의 경우 상당히 전문적으로 운영되며 무결성이 보장된다는 기대가 있습니다. 기업은 해당 환경에 있는 루트 CA의 신뢰성이 중요한 것만큼 내부 작업에 대해서도 동일한 수준을 달성하기 위해 노력해야 합니다. 최적의 보호를 위해 루트 CA는 오프라인 상태를 유지하다가 인증서 발행 및 CRL 업데이트에만 사용해야 합니다. 가장 좋은 CA 운영 방법에 대한 자세한 내용은 "인증 기관 리소스" 추가 기사를 참조하십시오.

키 복구 문제도 반드시 고려해야 합니다. 사용자가 데이터를 잠가 검색이 불가능해지는 일을 방지하고 검사 속도를 높이려면 모든 사용자 발행 키의 백업 사본을 만들어야 합니다. 또한 이 백업 사본을 안전한 장소에 보관해야 합니다. 이렇게 하면 스마트 카드를 택시에 두고 내렸을 때처럼 사용자의 키가 없어지더라도 해당 키로 보호된 콘텐츠에는 계속해서 액세스할 수 있게 됩니다.

마지막으로, 모든 우수한 암호화 시스템에는 수명 주기 관리라는 개념이 있습니다. 컴퓨터가 빨라질수록 알고리즘은 약해집니다. 제대로 된 암호화 시스템이라면 시간이 흐름에 따라 자체 갱신을 통해 새로운 알고리즘과 키 크기에 적응하는 능력을 갖춰야 합니다. CA는 암호화의 약점이 발견되었을 때 및 특정 기능을 도입 또는 퇴출할 때 적절히 업데이트되어야 합니다.

S/MIME 구현

서명되거나 암호화된 전자 메일을 S/MIME을 사용하여 부트스트랩, 작성, 전송 및 수신하려면 여러 단계를 거쳐야 합니다. 여기서는 일반적인 S/MIME 시나리오를 통해 이에 대한 자세한 내용과 문제점 및 가능한 해결 방법에 대해 설명합니다. 이 시나리오에서는 서로 다른 Active Directory® 포리스트 및 서로 다른 인증 기관 체인에 속하는 두 명의 사용자(즉, 사내/외를 불문하고 업무상 분리된 엔티티)가 Microsoft® Office Outlook® 2007을 사용하여 서명되거나 암호화된 전자 메일을 서로에게 보냅니다.

여기서 설명할 작업에 필요한 인프라는 이미 갖추어져 있다고 가정합니다. 이 시나리오에서는 Active Directory 통합 엔터프라이즈 인증서 서버를 사용합니다.

인증서 얻기

첫 번째로 해야 할 일은 알맞은 인증서를 얻는 것입니다. 이를 위해 인증서 관리자 MMC(certmgr.msc)를 열고 Personal 폴더를 마우스 오른쪽 단추로 클릭한 다음 팝업 목록에서 "모든 작업"을 선택하고 목록에서 "새 인증서 요청"을 선택합니다.

그러면 그림 1과 같이 "인증서 등록" 마법사가 시작됩니다. 기본적으로 엔터프라이즈 위주의 몇 가지 옵션이 표시되지만 중요한 것은 "사용자" 인증서입니다. 나중에 서명 및 암호화 프로세스에서 이 인증서를 사용하게 됩니다. 인증서는 다음에 대해 사용할 수 있어야 합니다.

그림 1** 인증서 요청 **(더 크게 보려면 이미지를 클릭하십시오.)

• 디지털 서명(만든 사람의 유효성이 포함된 메시지 작성)
• 키 암호화(암호화 파일 시스템 등의 기술에서는 한 키를 다른 키로 보호)
• 보안 메일(짝이 되는 개인 키를 가진 해당 수신자만 읽을 수 있도록 암호화된 메시지)

S/MIME 서명된 전자 메일을 보내는 데 키 암호화 속성은 필요하지 않습니다. 그러나 암호화된 메일을 보내거나 받을 때는 서명 속성은 필요 없지만 이 속성은 필요합니다. 기본적으로 Windows® 인증서 서비스의 템플릿을 통해 이러한 세 가지 속성을 사용할 수 있습니다. 사용자가 새 인증서를 요청할 수 없는 경우 마법사가 시작될 때 아무것도 표시되지 않습니다. 사용 가능한 엔터프라이즈 CA가 없는 경우 해당 도메인 또는 CA에 연결할 수 없음을 나타내는 "등록 오류"가 표시됩니다. 여기서는 인증서 하나로 서명과 암호화를 모두 허용한다고 가정합니다.

인증서 교환

두 사용자가 암호화된 전자 메일을 상대에게 보내는 가장 쉬운 방법은 서명된 메시지를 보내는 것입니다. 메시지를 작성한 후 "서명" 단추를 클릭하면 됩니다. (Outlook에서 이 단추는 기본적으로 숨겨져 있으며 한 번 사용한 뒤부터 표시될 수 있습니다. 새 메시지에서 "옵션" 설정을 클릭하고 "보안 설정..." 단추를 클릭한 다음 "보안 속성" 대화 상자에 있는 "이 메시지에 디지털 서명 추가" 상자를 선택하면 이 단추가 나타납니다.) 서명 단추("서명"이라고 표시된 빨간색 리본이 달린 작은 노란색 봉투)를 누르면 원본의 유효성을 설정하는 디지털 서명이 메시지에 추가됩니다.

"보내기" 단추를 누른 사용자에게 스마트 카드를 넣거나 PIN을 입력하라는 등 키 보유 사실을 입증하는 추가 토큰을 요청할 수 있습니다. 이 부분은 조직의 키 보호 방법에 따라 다릅니다.

S/MIME 서명된 메시지를 받은 사용자가 보낸 사람의 이름을 마우스 오른쪽 단추로 클릭하여 상황에 맞는 메뉴에서 "Outlook 연락처에 추가"를 선택하면 새 연락처 항목이 추가되거나 기존 연락처가 업데이트됩니다. 그리고 인증서가 해당 연락처 항목과 연결됩니다. 공용 Active Directory 환경(동일한 포리스트 또는 회사에 있는 두 사용자)에서는 사용자의 Active Directory 개체 속성에 따라 공개 사용자 인증서 배포가 자동으로 수행됩니다.

인증서를 교환하는 또 다른 방법은 각 사용자가 S/MIME 인증서를 첨부 파일로 보내는 것입니다. 이를 위해서는 두 당사자가 인증서를 CER 파일로 내보내야 합니다. 두 사용자는 인증서를 확인하고 그림 2와 같이 개인 키를 함께 내보내지 않도록 주의하면서 이어서 설명할 내보내기 프로세스를 수행합니다.

그림 2** 인증서를 교환할 때 개인 키 내보내지 않기 **(더 크게 보려면 이미지를 클릭하십시오.)

그런 다음 각 수신자가 Outlook에서 수동으로 연락처 항목을 만들고 보낸 사람의 항목에 인증서를 추가합니다. 인증서를 교환한 뒤부터 두 사용자는 서로 암호화된 전자 메일을 주고 받을 수 있습니다.

문제 해결

때때로 수신자가 암호화된 메시지를 여는 데 어려움을 겪을 수 있습니다. 이때 발생하는 문제의 세 가지 주된 원인은 신뢰할 수 없는 루트 CA, 확인할 수 없는 중간 CA, 그리고 사용할 수 없는 CRL입니다.

신뢰할 수 없는 루트 CA는 Outlook에서 "서명에 문제가 있습니다. 자세한 내용을 보려면 서명 단추를 클릭하십시오."라는 해당 서명과 연결된 오류 메시지로 표시됩니다. 이 문제를 해결하려면 Outlook에서 인증서를 열고 팝업 대화 상자에서 "인증 기관 보기" 단추를 클릭합니다. 인증서 속성 대화 상자의 일반 탭에 있는 메시지를 확인합니다. CA 루트 인증서를 신뢰할 수 없으며 설치해야 한다고 하면 "자세히" 탭으로 이동합니다. "파일에 복사..." 단추를 클릭하고 마법사에 따라 모든 기본값을 수용하고 파일 이름과 폴더를 입력합니다.

이제 시스템 관리자 계정으로 새 Microsoft 관리 콘솔(MMC)을 엽니다. "파일|스냅인 추가/제거(Ctrl+M)"로 이동하여 "인증서"를 선택한 다음 프롬프트가 나타나면 "로컬 컴퓨터"를 선택하여 해당 컴퓨터 계정에 대해 그 인증서를 추가합니다. 그런 다음 왼쪽 트리에서 "인증서" 노드를 확장하고 신뢰할 수 있는 루트 인증 기관에 대해 동일한 작업을 수행합니다. 마우스 오른쪽 단추를 클릭하고 팝업 메뉴에서 "모든 작업|가져오기"를 선택합니다. 앞에서 내보낸 인증서 파일을 "신뢰할 수 있는 루트 인증 기관"으로 가져온 뒤 "마침"을 클릭합니다. 그런 다음 해당 사용자가 Outlook을 다시 시작하도록 합니다.

이 방법은 신뢰할 수 있는 루트 CA를 추가할 때만 사용해야 합니다. 모든 루트가 동등하게 생성되지는 않습니다. 이 방법으로 시스템 전체의 저장소에 루트를 추가하려면 먼저 해당 루트 CA를 누가 소유하고 운영하는지 확인하십시오. 그룹 정책을 통해 신뢰할 수 있는 루트 목록을 제어하는 경우, 클라이언트 시스템으로 구성이 푸시됩니다. 이 경우에는 이 방법이 통하지 않을 수 있습니다. 전자 메일은 완벽하게 보호되는 통신 수단이 아니므로, 보안 웹 사이트나 서버 등 다른 데이터 교환 방법을 찾아야 합니다.

위에서 언급한 두 번째 문제인 확인할 수 없는 중간 CA는 대개 두 가지 상황에서 발생합니다. 인증서 검증을 시도하는 클라이언트가 인증서에 정의된 AIA(Authority Information Access) 위치에 접근할 수 없거나 CA가 발행하는 인증서와 일치하지 않는 중간 CA 인증서 버전이 클라이언트에 있는 경우(대개 클라이언트 버전이 더 낮음)입니다. 이러한 상황은 Outlook 사용자 인터페이스에서도 매우 유사하게 나타납니다. 체인의 중간 수준 CA가 만료되고 거기서 발행한 다른 하위 인증서가 만료되기 전에 이를 다시 발행한 아주 특별한 상황에서만 이런 문제가 발생했습니다.

기본적으로 이 문제는 체인이 끊어졌을 때 나타납니다. 상위 인증서가 제대로 정의되지 않았거나 리프 노드에 올바르게 포함되지 않은 경우 상황은 더 복잡해집니다.

이 문제를 해결하려면 보낸 사람이 새 메시지를 열고 새 메시지 "옵션"을 클릭한 다음 "보안 설정" 단추와 "설정 변경" 단추를 차례로 클릭해야 합니다. 이제 서명할 인증서에 대해 "선택" 단추를 클릭하고 팝업 대화 상자에서 "인증서 보기" 단추를 클릭합니다. "인증서 경로" 탭으로 이동하여 리프 노드의 발행자(체인에서 한 수준 상위)를 선택하고 "인증서 보기" 단추를 클릭합니다. "자세히" 탭을 클릭하고 "파일에 복사..." 단추를 클릭한 다음 내보내기 마법사를 완료하고 PKCS #7(.P7B)을 선택합니다. 그림 3과 같이 "인증 경로에 있는 인증서 모두 포함" 옵션이 선택되었는지 확인합니다. 마지막으로 내보낸 체인 파일을 원하는 수신자에게 보냅니다.

그림 3** 인증서 체인의 공백 해결 **(더 크게 보려면 이미지를 클릭하십시오.)

내보낸 인증서 체인을 받은 수신자는 앞서 루트를 가져올 때처럼 그 체인을 열어 가져와야 합니다. 한 가지 차이점은 선택한 저장 폴더가 중간 인증 기관이어야 한다는 것입니다. Outlook에서 메시지가 열리고 인증서가 유효한 것으로 표시되면 올바르게 작동하는 것입니다.

세 번째 문제인 사용할 수 없는 CRL은 해결 방법이 비교적 간단합니다. Outlook의 초기 반응은 앞의 문제와 매우 유사합니다. 하지만 루트 또는 중간 서명 CA를 신뢰할 수 있는 경우에도 오류가 표시됩니다. 인증서 체인에서 리프 위쪽의 각 수준에 대해 인증서 속성을 열고 "자세히" 탭으로 이동하여 "CRL 배포 지점" 필드를 확인합니다.

나열된 각 CRL 배포 지점(특히 인터넷 액세스 가능 지점)에 대해 CRL 파일 URL이 열리는지 확인합니다. 체인에서 한 수준씩 올라가면서 모두 검사합니다. CRL을 얻을 수 없다면 그것이 문제의 원인일 수 있습니다. 문제를 해결하려면 로컬 네트워크 정책에서 액세스를 차단하고 있지 않은지 확인해야 합니다. 차단되어 있지 않다면 해당 CA의 소유 회사에 문의하거나 CA의 CRL 배포 지점이 작동 상태로 돌아올 때까지 기다립니다.

인증서 배포

배포는 쉽습니다. 기본적으로 서명된 메시지는 메일 서버로 전송되고, 메일 서버는 검증된 방법인 SMTP를 통해 한 위치에서 다른 위치로 메시지를 보냅니다. 서명되거나 암호화된 메일을 전송할 때 발생하는 한 가지 문제는 일부 메일 시스템에서 서명 또는 암호화된 메시지를 거부하거나 차단한다는 것입니다. 해결 방법은 시스템 IT 관리자의 도움을 얻어 그러한 메시지 유형을 허용하는 것입니다. 물론, 어떤 메시지 유형은 계속해서 차단해야 할 수도 있습니다. 특정 운영 환경에서 암호화된 메시지를 허용하지 않을 타당한 이유가 수신자에게 있을 수 있기 때문입니다.

회신 암호화

암호화된 회신을 작성하려면(위의 부트스트랩 프로세스가 이미 완료되었다고 가정) 보내는 사람이 메시지를 작성한 다음 메시지 작성 창에서 "암호화" 단추(암호화라고 표시된 파란색 자물쇠가 있는 작은 노란색 봉투)를 클릭하면 됩니다. "암호화" 단추를 사용할 수 없는 경우 서명된 메시지 보내기 단계를 수행합니다. 단, 마지막 단계에서 "메시지 내용과 첨부 파일 암호화" 확인란을 선택합니다.

수신자에게 암호화된 메시지를 보낼 때 S/MIME 서명이 꼭 필요한 것은 아니지만, 서명을 하면 읽는 사람이 보낸 사람을 확인할 수 있으므로 두 가지를 함께 사용하는 것이 좋습니다(암호화 기능에는 보낸 사람에 대한 요구 사항이 없음). 암호화 프로세스에서는 모든 수신자에게 알려진 공개 키를 사용하여 메시지 암호화를 시도합니다. 인증서를 찾을 수 없는 일부 수신자의 경우, 위의 그림 4와 같이 암호화되지 않은 메시지를 보내도록 팝업 대화 상자에 표시됩니다.

그림 4** 인증서에 문제가 있을 때 암호화되지 않은 메시지 보내기 **(더 크게 보려면 이미지를 클릭하십시오.)

기본적으로 서명 및 암호화는 다르게 구성된 클라이언트 시스템에서도 작동해야 하지만, 하위 수준에서 지원되지 않는 해시 또는 암호화 알고리즘을 사용한 경우 다른 버전으로 암호화되거나 서명된 메시지에서 문제가 발생할 수도 있습니다. 서명된 전자 메일(SHA-512 해시 알고리즘 사용)을 Windows XP SP2 사용자에게 보낼 때 이러한 문제가 발생했습니다. 수신 시스템에서 해시를 지원하지 않기 때문에 사용자는 서명을 확인하거나 메시지를 읽을 수 없었습니다. 그러나 Outlook 기본값이 변경되지 않았다면 이 단계에서 많은 문제가 발생하지는 않습니다.

공개 인증서와 연결된 개인 키를 사용할 수 있다면 메시지를 받은 의도된 수신자가 해당 메시지를 열 수 있어야 합니다. 이때 사용자는 구현 방식에 따라 개인 키의 보유 사실을 입증하기 위한 추가 토큰을 다시 제공해야 할 수 있습니다. 이와 유사한 부트스트랩 프로세스를 완료한 다른 사용자들도 비슷한 서명 및 암호화 통신에 참여할 수 있습니다. 컴퓨터 분실 등으로 인해 개인 키를 변경한 사용자는 인증서를 다시 요청하고 암호화된 메일 교환을 기다리는 다른 사람에게 서명된 메시지나 인증서 파일을 재배포해야 합니다.

결론

서로 다른 두 디렉터리 또는 조직 사이의 서명 및 암호화된 S/MIME 작업은 대개 여기서 설명한 것보다 복잡하지 않습니다. 서명은 메시지에 유효성을 더하는 것이므로 제대로 사용하면 매우 간단합니다. 민감한 정보의 경우, 암호화된 메시지를 사용하여 전송 중인 데이터의 비밀을 한 단계 더 강하게 유지할 수 있습니다. 두 방법을 함께 사용하면 원본의 유효성과 데이터 비밀을 모두 유지할 수 있습니다. 여기서 설명한 프로세스에 따르면 대부분의 사용자가 어렵지 않게 이러한 이점을 활용할 수 있을 것입니다.

Matt Clapham은 CISSP이며 Microsoft IT의 보안 엔지니어입니다. 주로 LOB 응용 프로그램에 대한 보안 리뷰를 작성하고 기술, 게임, 컴퓨터 음악, 보안 등에 대한 해박한 지식을 가지고 있습니다. Puget Sound IT 보안 커뮤니티에서 의견을 발표하기도 합니다. 문의 사항이 있으면 matt.clapham@microsoft.com으로 연락하십시오.

Blake Hutchinson은 Microsoft의 BOSG(Business Online Services Group)에서 지원 분석가로 활약하고 있습니다. BOSG의 기업 고객을 위한 자체 제작 LOB 도구의 운영 지원 및 프로젝트 검토 업무를 담당하며 취미는 사진, 스키 및 컴퓨터 게임입니다. 문의 사항이 있으면 blakeh@microsoft.com으로 연락하십시오.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..