Security Watch암호와 신용 카드 - 제2부

Jesper M. Johansson

목차

의사 다단계 로그온 프로세스
브라우저 추가 기능의 문제점
인증자 변경 불가
보안 수준이 낮은 암호로 다운그레이드
의사 다단계 로그온 우회
암호 노출의 문제점
몇 가지 이점
사용자의 오해를 부르는 잘못된 보안 표시
열 것인가, 열지 않을 것인가
보안 통신 제공
개인 정보 보호

IT 산업의 보안 문제에 있어서 사용자에게 도움이 아니라 오히려 혼란을 주는 사안을 다룬 3부 시리즈 중 2부를 시작합니다. TechNet Magazine 2008년 7월호에서는 적용이 불가능하거나 잘못된 보안 권고와 혼동스러운 로그온 워크플로에 대해 다루었습니다. (제1부를 아직 읽지 않은 경우

technet.microsoft.com/magazine/cc626076에서 찾아볼 수 있습니다.) 지난 호에서는 취약한 보안 권고와 잘못된 로그온 워크플로로 인해 사용자들이 얼마나 많은 혼란을 겪고 있으며, 개인 정보를 보호하려는 사용자들의 노력을 무용지물로 만드는 일이 공공연하게 발생하고 있다는 얘기를 했었습니다.

이번에는 실제 사용자 보안 환경의 좀더 구체적인 예를 들어 관련 내용을 설명해 보겠습니다. 보안 전문가들의 의견을 소개할 이 시리즈의 마지막 편은 TechNet Magazine 다음 호에 게재될 예정입니다.

의사 다단계 로그온 프로세스

2005년 10월, FFIEC(미국 연방 금융감독원)에서는 "인터넷 뱅킹 환경의 인증" 기준을 발표했습니다(www.ffiec.gov/press/pr101205.htm 참조). 시행 준비 기간은 14개월밖에 되지 않았으며, 미국 연방 기관들은 이러한 새로운 기준을 충족하기 위한 방안을 강구하기 시작했습니다.

대부분의 기관들은 이 기간에 맞추지 못했습니다. 기준을 충족한 많은 기관들도 기준을 통과하기 위한 조치만 마련했습니다. 즉, 기관들은 사용자를 더욱 안전하게 보호하기 위한 조치를 마련하지 못했으며 "보안 전시 행정"에 불과했습니다. 전혀 도움이 되지 않는 재미있는 솔루션 중의 하나는 실제로 다단계가 아닌 다단계 인증을 만들려고 하는 것입니다.

사용자가 암호를 입력할 때 입력 흐름을 측정하는 기술을 예로 들어 보겠습니다. 웹 사이트에서 사용되는 이 솔루션은 기존의 로그온 대화 상자와 동일한 모양의 로그온 대화 상자를 표시합니다. 하지만 이 대화 상자는 Adobe Flash 개체입니다.

Flash 개체는 키를 얼마나 오래 누르고 있는지 그리고 키 입력 간의 시간 간격이 얼마인지와 같은 특성을 포함하는 사용자의 입력 흐름을 기록합니다. 이 데이터는 암호와 함께 웹 사이트로 제출되어 저장된 값과 비교됩니다. 입력 흐름 데이터가 저장된 데이터의 편차 범위 내에 있고 암호가 일치하면 로그온이 허용됩니다. 일반적인 생각은 이 솔루션을 통해 클라이언트에 타사 하드웨어를 설치하지 않고도 사이트에서 의사 생체 인증 방식을 사용할 수 있다는 것입니다.

이것을 의사 다단계 인증이라고 하겠습니다. 이 방식은 다음과 같은 정식 요소 중 두 항목 이상을 측정하는 진정한 다단계 인증이 아닙니다.

• 사용자가 가지고 있는 것(스마트 카드 등)
• 사용자가 알고 있는 것(암호 등)
• 사용자를 증명할 수 있는 것(지문 등)

의사 다단계 인증은 인증 프로세스에서 실제로 다중 요소를 포함하는 대신 여러 매개 변수 중 하나인 암호만 읽습니다. 그런 다음 추가 매개 변수를 사용하여 사용자를 증명할 수 있는 것에 대한 추론을 합니다.

의사 다단계 인증에 사용된 기술에는 많은 결함이 있습니다. 이러한 결함으로 인해 이 기술은 보안 문제를 해결하는 데 있어 대체로 비효과적입니다.

브라우저 추가 기능의 문제점

의사 다단계 인증 시스템은 브라우저 추가 기능을 통해 필요한 클라이언트측 처리 기능을 제공합니다. 물론 모든 소프트웨어에는 버그가 있으며, 이러한 버그 중 일부로 인해 취약점이 발생합니다. 이러한 취약점은 소프트웨어를 업데이트하기 어렵고 업데이트가 설치되었는지 확실치 않을 때 실제로 문제가 됩니다.

브라우저 추가 기능은 이러한 두 가지 사항에 모두 적용됩니다. 추가 기능은 업데이트하기가 어렵고 설치된 버전이 최신 버전인지 아닌지를 사용자가 확실히 알기가 어렵습니다. 따라서 사용자는 필요하지 않을 수도 있는 소프트웨어의 일부분을 인터넷에 노출해야 합니다.

추가 기능을 최신 버전으로 유지하기 위해 해당 웹 사이트에 정기적으로 방문하여 업데이트를 확인해야 하는 경우도 있습니다. 하지만 대부분의 사용자는 이렇게 하고 있지 않습니다. 단순한 보안 기능을 제공하기 위해 최종 사용자가 관련성 없는 추가 소프트웨어를 인터넷에 노출해야 하는 모든 시스템은 심각하게 검토를 해야 합니다.

인증자 변경 불가

"사용자를 증명할 수 있는" 요소에는 다른 두 가지 요소에 영향을 주지 않는, 단점일 수도 있는 특성이 있습니다. 암호(사용자가 알고 있는 것)를 변경할 수 있고 새 보안 토큰(사용자가 가지고 있는 것)을 만들 수 있지만 사용 가능한 생체 인증자의 수는 대체로 제한적입니다. 예를 들어, 지문의 경우 평생 10개만 사용할 수 있으며, 만약 사고로 이 중 하나를 잃게 된다면 대개는 대체가 불가능합니다.

이제 이것이 의사 다단계 로그온 사례에 어떻게 적용되는지 살펴보겠습니다. 다른 요소의 일부로 수집된 측정 정보는 쉽게 교체하거나 수정할 수 없습니다. 암호가 변경되면 사용자가 입력하는 방식도 변경되겠지만, 사용자가 키보드에서 키를 누르는 일반적인 방식은 바뀌지 않습니다. 이것이 바로 이 기술의 핵심 요소입니다. 이러한 측정 정보가 노출되면 합성이 가능해지며, 공격자가 이러한 측정 정보를 알아내고 재생할 수 있습니다.

보안 수준이 낮은 암호로 다운그레이드

긴 암호를 사용하고 자주 암호를 변경하는 것이 좋습니다. 또한 일부 권고 사항에 반할 수도 있지만 제1부에서 언급한 대로 안전한 곳에 암호를 기록해 두는 것이 좋습니다. 하지만 이렇게 하면 손으로 암호를 입력할 때 편하지는 않습니다. 긴 암호는 입력하기가 어려우므로 암호를 기록해 두면 복사하여 붙여 넣을 수 있습니다. 수백 개 이상의 암호를 관리할 수 있는 가장 좋은 방법 중 하나는 Password Safe(sourceforge.net/projects/passwordsafe)와 같은 소프트웨어 유틸리티를 사용하는 것입니다. 이와 같은 도구를 사용하면 완전한 무작위 암호를 생성하여, 암호화된 형태로 저장한 후, 로그온 대화 상자에 바로 붙여 넣을 수 있습니다. 사실, 이러한 도구를 사용하면 암호가 무엇인지 알 필요도 없습니다.

하지만 여기에는 한 가지 문제가 있습니다. 사용자가 암호를 입력하지 않으면 입력 흐름을 측정할 수 없습니다. 그리고 입력 흐름을 측정하는 개체에 암호를 입력해야 하는 경우 이 암호 관리 기술은 효용성이 떨어집니다. 15자의 완전한 무작위 암호를 정확하게 입력하는 작업은 간단한 일이 아닙니다. 따라서 사용자들은 대개 이와 같은 유형의 시스템에서 간단한 암호를 사용합니다. 그래도 15자의 완전한 무작위 암호는 그 자체만으로도 의사 다단계 인증 시스템의 간단한 암호보다 안전합니다.

배타적으로 구현된 의사 다단계 인증은 사용자들이 안전하지 않은 암호를 사용하도록 유도합니다. 곧 알게 되겠지만 실제로는 적절한 암호 관리 기술을 사용하는 것이 의사 다단계 인증 시스템으로 얻을 수 있는 어떠한 이점보다도 우수합니다.

의사 다단계 로그온 우회

사이트에서 의사 다단계 인증을 구현하더라도 의사 다단계 시스템을 우회할 수 있는 방법을 지원해야 합니다. 첫째, 일부 사이트에서는 사이트에 액세스하려는 모든 사용자에게 "제4자" 기술을 설치하도록 요구할 수 있습니다. TechNet Magazine 저자와 같은 일부 사용자는 이러한 종류의 소프트웨어를 설치하는 것을 항상 거부합니다.

둘째, 입력 흐름은 여러 가지 이유로 바뀔 수 있으므로 사이트에서 이러한 사실을 고려해야 합니다. 예를 들어, 손목이 골절된 사용자의 경우 입력 흐름이 일시적으로 바뀔 수 있습니다. 사이트에서 입력 흐름을 분석한 후 다른 사람이 해당 사용자의 자격 증명으로 로그인하려고 시도하고 있다고 간주된다면 어떻게 해야 하겠습니까? 손목 부상이 영구적이라면 사용자는 저장된 흐름 값을 재설정할 수 있습니다. 하지만 일시적인 부상이라면 사용자는 입력 흐름이 곧 원래대로 돌아올 것이라 생각하고 저장된 값을 재설정하려고 하지 않을 것입니다.

마지막으로, 모든 사용자가 의사 다단계 인증 시스템을 사용할 수 있는 것은 아닙니다. 예를 들어, 음성 인식을 통해 컴퓨터를 작동하는 장애인의 경우 프로그래밍 방식 입력 허용 여부에 상관없이 대화 상자에 암호를 입력하지 못할 수 있습니다. 이 경우 법적으로 장애인을 위한 대체 시스템이 마련되어 있어야 합니다.

이러한 모든 시나리오에 대비한 가장 간단하고도 직관적인 방식은 표준 암호 기반 인증을 지원하는 것입니다.

암호 노출의 문제점

의사 다단계 인증 시스템은 암호 기반 인증과 관련된 다양한 문제를 해결하기 위해 고안되었습니다. 하지만 이러한 시스템은 암호가 무력화될 수 있는 모든 주요 문제를 완전히 해결하지는 못합니다. 암호 기반 인증을 사용하는 시스템의 암호를 노출시킬 수 있는 5가지의 기본적인 방법이 있습니다. 여기서 "노출"이란 공격자가 다른 사용자의 암호를 알아내서 사용할 수 있음을 말합니다.

• 암호 추측
• 키 입력 로거
• 피싱 공격
• 사용자에게 묻기
• 암호나 암호 해시를 저장하는 시스템에 침투

암호 추측은 이제 공격자가 일반적으로 사용하는 공격 방식이 아니며, 키 입력 로거 및 피싱보다 드뭅니다. 암호 추측은 의사 다단계 인증으로 인해 불가능해졌다고도 볼 수 있습니다. 공격자는 암호뿐 아니라 입력 흐름도 추측해야 하기 때문에 일반적인 암호 추측 방법은 의사 다단계 인증 시스템에서는 효과가 없습니다. 입력 측정 정보를 합성하는 것이 이론적으로 가능하기는 하지만 실제 데이터는 대개 피싱 공격이나 키 입력 로거로 알아낼 수 있으므로 거의 그럴 필요가 없습니다. 또한 시스템에서 암호만 사용하는 표준 로그온 인터페이스를 제공한다면 공격자는 암호 추측을 위해 해당 시스템만 사용할 수 있습니다.

게다가 암호 추측 공격은 강력한 암호를 사용함으로써 막을 수 있습니다. 사용자들에게 관련 도구를 사용하도록 하는 등 보다 강력한 암호를 사용하도록 할 수 있다면 굳이 의사 다단계 인증은 필요하지 않습니다. (반면, 일반적으로 의사 다단계 인증 시스템과 함께 사용되는 간단한 암호는 실제로 암호 추측 공격을 받을 가능성이 높습니다.) 따라서 구현에서 암호만 사용하는 로그온을 지원하지 않는 경우 암호 추측을 막기 위해 제공할 수 있는 값은 실제로 값을 추가하는 것뿐입니다. 그리고 아까도 말했듯이 이 방법은 가능하더라도 실제로는 거의 사용되지 않습니다. 즉, 사용자가 의사 다단계 인증 시스템에서 간단한 암호를 사용할 경우 암호 추측 공격이 다시 가능해질 것이므로 의사 다단계 인증은 보안을 강화하는 대신 약화시키게 됩니다. 이 문제에 대해서는 추가 연구가 필요합니다.

또한 의사 다단계 인증은 키 입력 로거의 문제도 해결하지 못합니다. 현재 일반적으로 사용되는 키 입력 로거 중에서 입력 흐름을 감지하는 것이 있는지 모르겠지만 키 입력 로거에 이 기능을 구현할 이유는 전혀 없습니다. 키 입력 로거는 키보드와 컴퓨터 사이에서 기능하는 하드웨어이거나 키 입력을 캡처하는 소프트웨어입니다. 두 경우 모두 로거는 의사 다단계 인증 솔루션에서 사용되는 모든 데이터에 액세스할 수 있습니다.

사실, 인증 솔루션은 사용자 모드에서 실행되고 키 입력 로거는 그것보다 훨씬 아래쪽에 있기 때문에 키 입력 로거에서 더 많은 데이터에 액세스할 수 있습니다. 암호를 캡처하는 데 사용되는 웹 기반 개체와 키보드 간에 신뢰할 수 있는 경로가 없으면 이러한 유형의 암호 노출 공격을 막을 수 없습니다. 의사 다단계 인증 솔루션이 보편화된다면 누군가 반드시 그러한 키 입력 로거를 만들어낼 것입니다.

마찬가지로 피싱 공격도 의사 다단계 인증으로 막을 수 없습니다. 가짜 로그온 화면을 사용하는 대신 공격자는 Flash 개체를 사용하여 암호와 입력 흐름을 알아낼 수 있습니다.

의사 다단계 인증은 공격자의 기술이 사용자의 암호만 제공하는 일부 시나리오에 유용합니다. 예를 들어, 사용자로부터 암호를 알아내는 가장 쉬운 방법은 사용자에게 묻는 것입니다. 결과적으로 이 방법은 사용자에게 직접 만나서, 전화를 통해 또는 피싱 메시지를 통해 물어보든지 간에 효과적인 방법으로 입증되었습니다.

물론 사용자에게 입력 흐름을 물어보는 것은 효과가 떨어집니다. 마찬가지로 회사의 암호 데이터베이스가 노출될 경우 공격자는 암호만 액세스할 수 있습니다. 하지만 이 경우에도 시스템에서 암호만 사용하는 표준 인증을 제공하지 않을 때만 공격을 막을 수 있습니다.

실제로 암호 데이터베이스 자체만 노출되었더라도 공격자는 한 개 또는 여러 개의 정식 사용자 계정 암호를 알고 있을 때보다 더 심층적으로 시스템 정보를 노출시킬 수 있을 것입니다. 따라서 암호 데이터베이스를 소유한 공격자를 막으려는 시도는 실제로 의미가 없을 수 있습니다.

몇 가지 이점

공정하게 평가해 볼 때 시스템에서 암호만 사용하는 표준 로그온 옵션을 제공하지 않는다면 의사 다단계 인증으로 두 가지 문제점을 해결할 수 있습니다. 예를 들어, 암호 공유를 막을 수 있습니다. 하지만 공동 은행 계좌와 같이 여러 사용자가 계정을 공유하는 시스템에서는 단점이 될 수도 있습니다.

또한 웹 사이트 로그인이 아니고 제대로 구성된 대화형 로그온 대화 상자는 입력 흐름이 일치하지 않을 경우 추가 인증 단계를 거치도록 할 수 있습니다. 이를 통해 기밀을 요하는 환경에서 보안 취약한 계정에 대해 추가 보안을 제공할 수 있습니다.

사용자의 오해를 부르는 잘못된 보안 표시

사용자를 혼란스럽게 하는 가장 주된 요소 중 하나는 잘못된 보안 표시입니다. 가장 흔히 볼 수 있는 표시는 그림 1과 같이 웹 페이지에 표시되는 자물쇠 이미지입니다. 이 페이지의 경우 자물쇠 옆에 "Secure(보안)"라는 단어도 표시되어 있습니다.

그림 1 자물쇠 아이콘의 잘못된 사용(크게 보려면 이미지 클릭)

다들 알고 있겠지만 페이지에 자물쇠 이미지와 "보안"이라는 단어를 표시한다고 해서 안전한 것은 아닙니다. 그러나 이러한 표시는 가장 유명하고 가장 많은 공격 대상이 되는 웹 사이트에서 보편화되어 있습니다. 이로 인해 많은 사용자들은 이러한 표시가 주소 표시줄에서 실제로 어떤 의미를 갖는지 확인하는 대신 웹 페이지 본문에서 이러한 안전 표시만을 찾고 있습니다. W3C Web Security Context Wiki는 w3.org/2006/WSC/wiki/PadlockIconMisuse에서 이 문제를 지적했습니다.

이렇게 잘못 사용되는 사례를 쉽게 볼 수 있다는 것은 안타까운 일입니다. 연구에 따르면 사용자들은 인증서가 매우 분명한 경우에도 악의적인 웹 사이트를 식별하지 못하는 것으로 나타났습니다(www.usablesecurity.org/papers/jackson.pdf 참조). 비교할 실제 인증서가 없으니 가짜와 진짜를 쉽게 구분하지 못하는 것입니다. 여기에는 기술이 필요하지만, 웹 페이지에 표시되는 잘못된 보안 표시로 인해 그러한 기술의 개발이 저지되고 사용자들은 잘못된 정보에 익숙해지게 됩니다.

그림 2는 이와 관련된 특히 심각한 문제를 보여 줍니다. 이 경우 정보를 표시하는 페이지는 실제로 안전하지 않습니다. 주소 표시줄을 보면 프로토콜을 나타내는 "http"가 있습니다. 이 사이트에서는 가장 일반적인 최적화 기술을 사용하고 있는데, 로그온 폼이 포함된 페이지를 암호화하는 대신 폼 제출만 암호화합니다. "안전"을 "암호화"와 동일하게 생각한다면 로그인은 페이지에 표시되어 있는 대로 안전합니다. 하지만 여기서 가장 중요한 문제는 사용자가 자격 증명을 보내기 전에 자격 증명이 어디로 전송되는지 확인할 수 있는 방법이 없다는 것입니다. 사이트에서는 폼을 제출하기 전에 사이트를 인증하는 인증서를 사용자에게 보여 주지 않습니다. 이것은 일종의 도박으로, 뒤쳐지면 뒤따라 오던 사람에게 붙잡히게 되듯이 폼이 제출될 쯤에는 이미 피해를 입을 수도 있습니다.

그림 2 안전하지 않은 페이지의 보안 표시(크게 보려면 이미지 클릭)

HTTPS로 보안을 제공하는 프로토콜인 SSL(Secure Sockets Layer)에는 두 가지 중요한 목적이 있습니다. 첫째, 사용자에게 서버를 인증합니다. 둘째, 클라이언트와 서버 간에 사용할 수 있는 세션 암호화 키의 협상을 위한 간편한 메커니즘을 제공합니다.

실제 폼 제출만 암호화될 경우에는 우선적으로 가장 중요한 목적이 달성되지 않습니다. 이 최적화를 구현하는 사이트는 키를 협상하기 위한 방법으로 SSL을 사용합니다. 모순되지만, 사이트에서는 단순히 표준 키 협상 프로토콜을 사용함으로써 이러한 목적을 달성하고 결과적으로 SSL의 비용과 오버헤드를 피할 수 있습니다.

그림 2의 사이트는 흔히 볼 수 있습니다. 많은 사이트에서는 폼 제출에 대해서만 SSL 보호 기능을 제공하고 폼 자체에 대해서는 제공하지 않습니다. 하지만 이 사이트는 그보다 더 놀라운 특징을 보여 줍니다. 브라우저의 주소 표시줄에 https://www.<site>.com(보안이 유지되는 https에 주목)을 입력하면 SSL을 지원하지 않는 사이트 버전으로 리디렉션된다는 것입니다. 자격 증명을 사이트에 보내기 전에 인증서를 검사하려고 해도 사이트에서 인증서를 보여 주지 않습니다.

모든 사이트가 이런 것은 아니지만 많은 사이트가 그러합니다. 그리고 미국의 대표적인 신용 카드 회사 중 두 곳도 그렇습니다. 사실 현재 이용하고 있는 세 곳의 신용 카드 회사 중 American Express에서만 로그온 폼에 인증서를 제공하는 실정입니다. American Express에서는 HTTP 요청도 HTTPS로 리디렉션합니다. 훌륭하지요!

의미 없는 보안 표시와 로그온 폼의 인증서 부재와 관련하여 한 가지 의문이 생깁니다. 사이트에서는 왜 이렇게 할까요? 그 이유는 경제적인 부분 때문입니다. 인증서를 표시하면 페이지를 암호화해야 하고, 페이지를 암호화하면 처리 오버헤드가 발생합니다. 처리 오버헤드는 동일한 부하를 서비스하는 데 더 많은 컴퓨터를 필요로 하며, 컴퓨터가 늘어날수록 비용이 증가합니다. 안타깝게도 고객 개인 정보 보호와 수익 증대 사이에서 많은 기업들은 수익을 먼저 생각하고 있습니다.

열 것인가, 열지 않을 것인가

최근에 건강 보험 회사로부터 놀라운 전자 메일 메시지를 받았습니다. 10년 동안 컴퓨터를 사용해 온 사람이라면 누구나 요청하지 않은 전자 메일 첨부 파일을 열어서는 안 된다는 것을 알고 있습니다. 그러니 그림 3과 같은 메시지를 받았을 때 얼마나 놀랐겠습니까?

그림 3 “보안 첨부 파일”이 포함된 전자 메일 메시지(크게 보려면 이미지 클릭)

사실 건강 보험 회사의 웹 사이트에 문의를 한 적이 있으며, 의심되는 메시지가 도착했을 때는 이 사실에 대해 잊어버렸습니다. 회사에서는 이렇게 답신을 보냈습니다. 처음에는 이것이 똑똑한 피싱 방식이라고 생각했습니다. 하지만 이것이 정당한 메시지였다는 것을 알았을 때 놀라움을 금할 수 없었습니다.

가장 첫 번째 지침은 첨부 파일을 두 번 클릭하여 메시지의 암호화를 풀라는 것이었습니다. 보안 커뮤니티와 IT 관리자들은 지난 10년 동안 사용자들에게 첨부 파일을 두 번 클릭하지 말도록 가르치는 데 수많은 시간을 쏟아 왔습니다. 그런데 보험 회사에서는 보안을 위해 첨부 파일을 클릭하라고 했습니다. 사실 이 건강 보험 회사만이 이 방식을 사용하는 것이 아닙니다. 이런 상황에서 사용자는 어떻게 해야 합니까? 누구의 말을 따르고, 누구의 말을 따르지 말아야 합니까?

그래서 저는 Microsoft® Office Outlook® 2007의 미리 보기 기능을 사용하여 메시지를 확인했습니다. 그림 4에 나와 있는 것처럼 Outlook에서는 해당 메시지가 위험할 수 있으므로 열지 말도록 경고했습니다!

그림 4 Outlook 2007에서 보안 문서를 악의적인 것으로 판단(크게 보려면 이미지 클릭)

건강 보험 회사가 전 세계적으로 가장 많이 보급된 전자 메일 클라이언트에서 사용되는 매우 기본적인 보안 확인을 위반하고 있다는 사실은 정말 안타깝고도 어리둥절한 일입니다. 이 회사가 Outlook으로 새 보안 솔루션을 테스트하지도 않았다고 생각하니 이 회사가 도대체 개인 정보 보호를 위해 무엇을 하고 있을지 의문스러웠습니다. 또한 단지 고객의 개인 정보를 충분히 보호하지 않는다는 고소를 피하기 위해 이 회사가 다른 어떤 솔루션을 구현하고 있을지도 모르겠다는 생각이 들었습니다. 이것은 재무 기관에서 수행하고 있는 보안 전시 행정과 유사합니다. 이 회사의 경우 실제로 고객을 보호하기 위해서가 아니라 고소를 면하기 위한 것이 솔루션의 기본 목적이라고 생각합니다.

저는 첨부 파일이 실제로 무엇인지 확인해 보기로 했습니다. ActiveX® 컨트롤 개체였습니다. 첨부 파일을 확인하려면 Internet Explorer®에서 열고 개체를 설치해야 했습니다. 그림 5와 같이 확인하는 화면이 다시 표시되었습니다. 보시다시피 설계자들은 메시지가 실제 우편 봉투와 같이 보이도록 하기 위해 많은 노력을 했으며, 봉투에는 신뢰할 수 있다는 것을 나타내기 위한 스탬프도 있습니다.

그림 5 봉투에 “Trusted(신뢰할 수 있음)”가 찍힌 보안 문서(크게 보려면 이미지 클릭)

이와 같은 기술은 여러 가지 이유로 위험합니다. 첫째, 사용자에게 원치 않는 첨부 파일을 열도록 하는, 권장되지 않는 행동을 요구합니다. 둘째, 실제 메시지에서 확인 없이 항상 첨부 파일을 열도록 시스템을 구성하라는, 바람직하지 않은 지침을 제공하고 있습니다. 셋째, 전자 메일에서는 신뢰할 수 있다고 말하고, Outlook에서는 신뢰할 수 없다고 말하게 되면 메시지가 매우 의심스러워 보입니다. 마지막으로, 실제 첨부 파일에는 사용자에게 신뢰할 수 있다고 확신시키는 의미 없는 보안 표시가 포함되어 있습니다. 사용자가 이러한 종류의 메시지를 신뢰하기 시작하면 유사한 형태의 악의적인 메시지를 신뢰하는 것은 시간 문제입니다.

보안 통신 제공

이 기술이 해결하려고 시도하는 문제가 매우 중요하다는 것은 인정합니다. 고객과 신뢰할 수 있는 방식으로 통신하는 것은 쉬운 일이 아닙니다. 하지만 이 특정 솔루션은 과도하게 구현되었습니다. 이로 인해 고객은 혼란을 느끼고 해결하려는 의도와 반대의 결과로 이어질 수 있습니다. 즉, 고객의 시스템이 노출될 수 있습니다.

제대로 구현된 웹 사이트에서는 "메시지 센터"를 사용합니다. 이러한 설계에서는, 회사에서 고객과 통신해야 할 때 "귀하에게 메시지 센터에 도착한 메시지가 있습니다. 메시지를 보려면 웹 사이트에 방문하여 로그온하고 메시지 센터 링크를 클릭하십시오."라는 내용의 전자 메일 메시지를 보냅니다. 회사에서 S/MIME(Secure Multipurpose Internet Mail Extensions)을 사용하여, 고객이 보는 모든 전자 메일 메시지에 서명을 하면 사용자가 소스를 인증할 수 있으므로 추가 이점이 있습니다. 메시지에 "이 링크를 클릭하십시오"라는 항목을 포함시키지 않으면 또 하나의 추가 이점이 있습니다. 사용자가 직접 회사의 URL을 입력해야 원하는 사이트로 이동할 수 있다는 것입니다.

메시지 센터와 서명된 메시지를 사용하여 회사에서는 고객과 신뢰할 수 있는 경로로 통신할 수 있게 됩니다. 메시지 워크플로 중 고객이 보는 모든 것은 인증되며, 회사에서는 낮은 수준의 보안 방식을 요구하지 않습니다.

개인 정보 보호

지금까지 이번 시리즈의 두 편의 글을 통해 보안 전문가들이 사용자에게 실제로 얼마나 피해를 주고 있는지 설명했습니다. 보안을 유지하는 것은 우리의 임무입니다. 그러나 많은 결정 및 구현 솔루션을 통해 사용자들에게 혼란을 주고, 잘못된 결정을 내리게 하며, 잘못된 보안 인식을 심어 주고 있습니다. 우리는 이렇게 혼란스럽게 사용자에게 부담을 주어서는 안 됩니다.

앞에서도 말했듯이 일반 사용자에게 보안은 단순히 암호 및 신용 카드 번호를 보호하는 것입니다. 사용자들은 기술이 제대로 작동하고 신뢰할 수 있기를 원합니다. 안타깝게도 결정은 사용자들이 내려야 하고, 이러한 결정을 내리도록 정보를 제공하는 것은 우리의 임무입니다.

이번 시리즈의 마지막 편에서는 고객이 사용할 수 있는 가장 중요한 기술 중 일부가 얼마나 기대에 못 미치는지에 대해 설명하겠습니다. 또한 다른 전문가들의 의견도 수록할 예정입니다. 2008년 9월의 Security Watch 칼럼으로 다시 찾아 뵙겠습니다.

Jesper M. Johansson은 보안 소프트웨어 분야의 소프트웨어 설계자이며 TechNet Magazine의 객원 편집자로서, 정보 관리 시스템 분야 박사 학위와 20여 년의 보안 관련 경력을 보유한 Enterprise Security 영역의 Microsoft MVP(Most Valuable Professional)입니다. 그의 최근 저서로는 Windows Server 2008 Security Resource Kit가 있습니다.

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