Security Watch양자 보안 원리

Jesper M. Johansson

독특하지만 의미 있는 주제에 대해 논하는 것은 언제나 흥미롭습니다. 요 근래 필자는 보안 개념을 설명하는 데 하이젠베르크의 불확정성 원리를 자주 사용하곤 합니다. 이전에 유니콘 이야기를 들어본 적이 있는 독자는 필자가 이해를 돕기 위해 다른 분야의 기본 이론을 자주 차용한다는 사실을 잘 알 겁니다. 이상하게

들리겠지만 다른 과학 분야의 기본 개념에서 정보 보안 원리를 찾을 수 있습니다.

양자 물리학에서 비롯된 하이젠베르크의 불확정성 원리는 그림 1의 수식을 바탕으로 합니다. 이 원리 자체는 위치 측정의 정밀도를 높이면 운동량 측정의 정밀도가 낮아진다는 소립자의 위치(p)와 소립자의 운동량(x) 간의 관계를 설명하고 있습니다. 두 인자의 정밀도 한계는 플랑크 상수의 일정 배수로 매우 작습니다. 쉽게 말해 단일 소립자의 여러 측면을 동시에 정확하게 관찰할 수 없다는 사실을 밝힌 것입니다.

그림 1 하이젠베르크의 불확정성 원리

그림 1** 하이젠베르크의 불확정성 원리 **

이는 소립자와 관련한 몇 가지 측면에 대한 추론이 얼마나 불확정적인지를 예측할 수 있도록 하는 불확정성 범위 예측과 직접적인 연관이 있습니다. 정보 보안에 있어서는 불확정성 범위를 예측할 수는 없지만 단일 컴퓨터 네트워크에 대한 두 가지 변수가 네트워크의 보안에 어떤 영향을 미칠지 정확하게 예측할 수 없다는 사실이 중요합니다.

어느 정도 절충도 필요합니다. 정보 보안에서는 플랑크 상수에 따른 제한은 없지만 다른 형태의 제한이 있습니다. 가장 두드러지게 절충이 필요한 요소는 바로 보안과 유용성 또는 사용 편의성입니다. 가용성을 완전히 무시한다면 기능을 해제하는 방법이 가장 손쉬운 보안 방식이라 할 수 있습니다. (사실 개인적으로, 보안 담당자는 서비스 거부 공격 이외의 경우에는 가용성에 대해 책임질 필요가 없다고 생각합니다.) 기능을 아예 해제하면 해킹당할 위험도 없을 테니까요. 하지만 유용성은 크게 떨어지겠죠.

마찬가지로, 매년 한 번씩 직원에게 인스턴트 메시징 응용 프로그램이 업무용으로 부적합하다는 사실을 알리는 전자 메일을 보내는 것보다 값비싼 데이터 손실 방지 제품을 구현하면 비용은 크게 증가하겠지만 중요한 데이터의 누출을 훨씬 효과적으로 방지할 수 있습니다. 그런데 조직에서 과연 데이터 손실 방지 도구에 큰 비용을 투자하려 할까요? 이제 양자 물리학이 생각 외로 보안과도 밀접한 관련이 있다는 사실을 이해할 수 있을 겁니다.

슈뢰딩거의 고양이

슈뢰딩거의 고양이라는 비유에서는 이와 관련하여 전혀 다른 개념을 설명하고 있습니다. 이 이야기는 20세기의 저명한 물리학자, 에르윈 슈뢰딩거가 앨버트 아인슈타인과 중첩이라는 개념에 대해 긴 논쟁을 펼치던 당시로 거슬러 올라갑니다. 슈뢰딩거는 원소가 상당히 부조리하게 두 가지 상태로 중첩되어 있는 양자역학 분야를 발견했습니다.

이를 설명하기 위해 슈뢰딩거는 고양이를 완전히 밀폐된 상자에 넣는 사고 실험을 제안했습니다. 상자 안에는 독약이 든 병이 있고 (가상의) 아원자 방사능 입자를 사용해 독약 유출을 제어할 수 있습니다. 방사능 입자가 소멸하면 독약이 유출되고 고양이가 죽게 되는 겁니다.

양자역학의 법칙에 따라 아원자 입자는 중첩 상태로 존재합니다. 따라서 아원자 입자의 상태에 따라 상태가 좌우되는 원자 고양이도 이러한 중첩 상태로 존재하게 됩니다. 따라서 고양이의 상태를 실제로 관찰해야 살아 있는 상태 또는 죽은 상태로 확정할 수 있게 됩니다.

물론 슈뢰딩거는 양자역학의 일부 법칙을 원자계에 적용했을 때 어떠한 부조리가 발생하는지를 보여 주기 위해 이러한 예를 사용한 것이지만, 쉬운 말로 "관찰자 효과"라고 하는 개념을 설명하는 데에도 자주 사용됩니다. 관찰자 효과는 양자역학에서 다루는 아원자계에는 적용되지 않지만 우리 같은 보안 전문가에게는 중요한 의미가 있습니다. 이것은 한마디로 어떤 대상을 관찰하는 것이 그 대상을 변화시키는 결과를 낳게 된다는 개념입니다.

관찰자 효과

좀 더 자세한 설명을 위해 한 잔의 차를 예로 들어보겠습니다. 차가 얼마나 뜨거운지 확인하기 위해 잔에 온도계를 넣습니다. 온도계를 넣을 때 차 온도가 섭씨 80도이고 온도계 자체의 온도는 22도(실내 온도)라고 가정합니다. 온도계를 차에 넣는 순간 차의 열이 온도계로 전도되어 차는 열을 빼앗기고 온도계는 온도가 상승합니다. 그리고 결국 온도계와 차의 온도가 같아집니다. 이때 최종 온도는 80도나 22도가 아니라 그 사이의 값이 됩니다. 차의 온도를 측정하는 행위로 인해 대상이 변하게 되는 것입니다.

관찰자 효과는 정보 보안과도 관련이 있습니다. 즉, 보안 문제를 해결하기 위해 조치를 취할 때마다 시스템이 수정되어 보안 환경이 변할 수 있다는 것입니다. 마땅한 용어가 없으므로 이를 SPFE(보안 환경 가변 효과)라고 부르도록 하겠습니다.

좀 더 간단한 예로, 서비스 계정 종속성을 들 수 있습니다. Protect Your Windows Network(protectyourwindowsnetwork.com)의 8장에서 필자는 시스템에 IDS(Intrusion Detection Service)를 설치하여 공격을 탐지하는 방법에 대해 설명한 바 있습니다. 하지만 IDS는 중앙 시스템에 로그를 기록하며, 이는 모니터링되는 시스템에 대한 높은 액세스 권한을 필요로 합니다. 따라서 서비스는 대부분 높은 권한의 서비스 계정으로 실행되어야 합니다.

이 경우 시스템 중 하나라도 공격에 노출된다면 공격자가 서비스 계정 자격 증명에 액세스하여 다른 모든 시스템에 액세스할 뿐만 아니라 IDS 기능 자체를 해제할 수 있게 됩니다. 이는 SPFE의 전형적인 예입니다. 즉, 보안을 강화하기 위해 시스템 환경에 설치한 도구로 인해 새로운 보안 문제가 발생하는 것입니다.

SPFE의 예는 이외에도 많습니다. 802.1x가 유선 네트워크에서 특정한 문제를 초래하는 이유에 대한 Steve Riley의 설명(microsoft.com/technet/community/columns/secmgmt/sm0805.mspx)도 대표적인 예 중 하나입니다. 호스트 기반 방화벽의 사용은 분명 많은 환경에서 적절한 선택이 될 수 있지만, 802.1x와 함께 사용하면 이전에는 불가능했던 특정 공격 유형에 노출되는 결과를 낳습니다. 이 경우에도 보안 기술이 환경의 보안 상태를 변화시켜 불가능했던 공격을 가능하게 한 것입니다.

그렇다고 이러한 수단이 아예 쓸모가 없으므로 사용하지 말아야 한다는 의미는 아닙니다. 단지 전반적인 보안과 관련하여 어떠한 영향을 미치게 될지 신중하게 고려해야 한다는 의미입니다. 위험을 관리할 때는 작업과 방지 조치가 실제로 위험과 관련하여 어떠한 의미를 지니는지 고려해야 합니다. 문제를 해결할 때는 구현한 수단이 효과가 없다고 해서 간단히 중지할 수 있는 게 아닙니다. 현실적으로 보안은 지속적으로 진행되는 프로세스이기 때문입니다. 심층 방어 전략이 필요하기는 하지만 방어 전략이 보안 환경을 어떻게 변화시키고 전략 구현으로 인해 새롭게 발생하는 위협 요소를 어떻게 해결할지를 먼저 구상해야 합니다.

성숙해진 강화 전략

필자는 10여 년 동안 강화 지침을 다루어 왔습니다. 처음으로 작업했던 몇 가지 가이드를 되돌아보면 동료와 필자가 필요하다고 생각한 설정의 목록에 지나지 않았습니다. 그 당시에는 보안의 근간이 되는 일반 전략이 무척 단순했습니다. 보안 기능을 제공하는 수단은 무조건 사용하는 것이 기본 원칙이었으니까요. 애초에 해당 설정을 해제해야 할 합당한 이유가 있을 수도 있다는 사실은 거의 고려되지 않았습니다.

그러나 보안을 효과적으로 강화하려면 해당 강화 조치와 관련한 여러 가지 측면과 시스템에서 발생할 수 있는 위협을 고려해야 한다는 점을 배우게 되었습니다. 그 결과 Windows 2000 보안 강화 가이드(go.microsoft.com/fwlink/?LinkID=22380)의 시나리오 목록을 마련하게 되었습니다. 그리고 이 가이드가 차츰 발전하여 위협 정도에 따라 지침을 나눈 Windows Server 2003 보안 가이드(go.microsoft.com/fwlink/?linkid=14846)가 탄생했습니다.

그 동안 필자는 사용자들로부터 지침에 따라 설정한 후에도 시스템이 공격 받을 가능성이 있다는 불평을 들어야 했습니다. 그것은 설치되지 않은 패치가 있거나, 잘못된 운영 방식으로 공격의 여지가 생겼거나, 보안이 설정되지 않은 타사 소프트웨어를 설치했기 때문이었지요.

그런데 이 두 가이드의 강화 전략도 전체 보안 환경에는 별 도움이 되지 않는 것으로 드러났습니다. 그 이유는 몇 가지로 요약됩니다. 사실 필자가 구축한 가장 안전한 시스템(msdn2.microsoft.com/library/aa302370)에도 이러한 보안 가이드의 전략을 네다섯 가지밖에 활용하지 않았을 뿐더러, 그 중 어떤 것도 예상된 공격을 실질적으로 막지 못했습니다. 안타깝게도 사람들은 누르기만 하면 시스템이 자동으로 강화되는 "보안" 단추를 원하지만 보안은 그렇게 간단한 문제가 아닙니다.

위험에 대한 접근 방식

한계가 있는 보안을 구축하는 게 아니라 적절하게 보호를 받으려면 위험에 대한 합리적인 접근 방식이 필요합니다. 예상되는 위험을 파악하고 그 중에서 완화해야 할 위험을 결정하고 완화할 방법을 이해하는 것이 우선이며, 이는 스위치만 추가한다고 해서 되는 일이 아닙니다.

대개 이러한 보안 스위치는 특정한 시나리오에 맞게 설계되었기 때문에 당면한 시나리오에서 최적의 구성이 구축된다는 보장이 없습니다. 다만 보안 기반으로서 좋은 출발점이 될 수 있으며 이러한 간편한 보안 강화 도구에 대한 시장 수요가 크기 때문에 대개는 스위치가 제공됩니다. 최신 소프트웨어에서는 대부분의 스위치가 기본적으로 설정되며, 기본적으로 설정되지 않는 스위치는 부작용이 크기 때문인 경우가 많습니다.

게다가 스위치를 많이 사용하면 시스템이 불안정해지고 운영이 어려워져 필요한 작업조차 수행할 수 없게 됩니다. 이는 아직 발생하지도 않은 위협을 완화하기 위한 대가로는 너무 큽니다. SPFE와 양자 물리학은 보안 조치를 취한 후의 결과를 재분석하라는 교훈을 주고 있지만 실제로 그렇게 하는 조직은 거의 없습니다. 사실 애초에 위협에 대해 제대로 분석하는 조직도 적습니다. 보안을 강화하기 전에 먼저 위협을 실질적으로 분석하면 중요한 것은 계정 이름 나열에 대한 익명 제한이나 대규모의 액세스 제어 목록 변경 등이 아니라는 사실을 알게 될 것입니다.

그보다는 시스템에서 특정 서비스를 제공할 필요가 있는지, 제공할 경우 제공 대상은 누구인지 파악하고 그 후에 정책을 적용하는 것이 훨씬 효과적입니다. 또한 절대적으로 커뮤니케이션이 필요한 시스템과 사용자에게만 이를 허용하는 것이 중요합니다. 나아가 모든 응용 프로그램과 사용자가 최소 권한으로 실행하도록 해야 합니다. 요약하자면 보안에 대해 합리적으로 접근하고 까다로운 분석을 통해 각 시스템이 자체적으로 보안 책임을 지도록 해야 합니다.

오늘날의 보안 접근 방식에서 서버 및 도메인 격리(microsoft.com/sdisolation), Windows Server® 제품의 SCW(보안 구성 마법사), Windows Server 2008에서 역할 관리에 사용되는 서버 관리자 도구 등의 보안 도구를 이용하는 것도 이 때문입니다. 이러한 도구는 지원해야 할 시나리오를 파악하는 과정을 안내하고 그에 따라 적절히 시스템을 제한하도록 돕습니다. 이러한 도구가 누구나 원하는 만능의 해결책이 될 수는 없지만 소프트웨어를 구매한 용도에 맞는 작업을 실질적으로 수행할 수 있는 현실적인 설정을 구성할 수 있도록 지원합니다.

필요한 모든 곳에 보안 적용

한마디로 다른 주체나 단순한 도구에 보안을 맡길 수는 없다는 것입니다. 오늘날에는 "네트워크 경계"나 "내부 네트워크" 같은 개념이 의미가 없기 때문에 각각의 자산은 스스로를 방어할 수 있어야 합니다.

대부분의 조직 네트워크는 서로 어느 정도 다릅니다. 따라서 이러한 점을 이해하여 무조건 강화 지침을 따를 것이 아니라 시나리오에 맞는 적절한 단계를 따라야 합니다. 그러기 위해서는 먼저 요구 사항을 파악해야 합니다. 그리고 요구 사항을 알고 있는 다른 사람으로부터 지침을 구하는 것도 필요합니다.

최근 웹캐스트 이용자 중 한 명이 소규모 기업 사용자들에게 미 국토안보부 사이트에서 Internet Explorer® 보안 강화 가이드를 다운로드하라고 충고한 적이 있습니다. 국가적 안보를 책임지는 정부 기관에서 과연 소규모 기업의 웹 브라우저 보안에 대해 효과적인 가이드를 제공할 수 있을까요? 이는 아직 컴퓨터 보안 현장에 만연되어 있는 근거 없는 논리의 좋은 예입니다. 주요 정부 기관에서 발행한 지침이라고 해서 높은 보안 수준을 보장할 것이라는 잘못된 가정에 따른 것입니다.

보안 결정은 대개 양자택일의 형태로 나타납니다. 즉, "높은 수준의 보안"을 구현하거나 "낮은 수준의 보안"을 구현하게 됩니다. 이를 좀 더 정확하게 표현하면 "높은 수준의 보안"과 "적절한 수준의 보안" 사이의 선택이라고 할 수 있습니다. 보안의 기준은 조직마다 조금씩 차이가 있기 마련이니까요.

높은 수준의 보안이 모든 경우에 적합한 것은 아닙니다. 사실 대개 적합하지 않을 때가 많습니다. 또한 도달해야 할 목표도 아닙니다. 높은 수준의 보안이란 시스템이 공격에 노출되면 인명 피해로 이어질 수 있는 시스템을 위한 특별한 구성이니까요. 단, 위험의 양상과 위협 모델이 여기에 해당한다면 높은 수준의 보안을 사용해야 하겠지요.

위험 양상과 위협 모델이 이와 다르다면 보다 적절한 구성을 사용해야 합니다. 아마 구성 가능한 도구는 이미 기본적으로 적절한 위험 양상 수준에 맞도록 설정되어 있을 겁니다. 대부분의 최신 Microsoft 제품에 사용되는 이러한 기본 상태는 보안과 유용성, 사용 편의성 및 성능이 적절히 절충되어 있습니다. 일반적인 보안 강화 구성이 이미 구현되어 있다는 말입니다.

이제 다른 보안 단계를 고려해야 합니다. 먼저 TechNet 보안 센터(microsoft.com/technet/security)나 Windows Server 2008 Security Resource Kit 같은 책을 참조하면 도움이 됩니다.

위험 관리의 중요성

아마 필자가 궁극적으로 무엇에 대해 말하려는지 지금쯤 다들 눈치채셨을 겁니다. 그렇습니다. 바로 위험 관리입니다. 하이젠베르크의 불확정성 원리에서 말하는 중요한 교훈은 절충할 수밖에 없다는 점입니다. 이는 거창한 과학 이론이 아닙니다.

반면 슈뢰딩거의 고양이 이야기에서는 간과하기 쉬운 점을 지적하고 있습니다. 모든 측면에서 문제를 분석하고 절충안을 결정하는 것만큼 해결 방안을 구현하는 데 따른 변화를 고려하는 것도 중요하다는 점입니다. 변경 사항이 시스템에 미치는 영향을 고려하고 그러한 변경 사항이 위험 관리 전략의 일환으로 구현된 것인지 아니면 다른 이유로 발생한 것인지를 분명히 해야만 바람직한 위험 관리 전략이라고 할 수 있습니다.

연간 손실 예측

위험을 정량화하는 방법으로 그림 2의 ALE(연간 손실 예측) 수식이 많이 사용됩니다. 이 수식은 대부분의 보안 인증 교육 코스에서도 가르치고 있는 내용입니다. 표준 ALE는 간단합니다. 위험 발생 가능성과 각각이 발생한 경우 초래되는 비용을 확인하여 두 값을 곱합니다. 이를 통해 매년 보안 사고로 지출되는 금액을 예측할 수 있습니다. 그리고 이러한 위험 비용을 기준으로 문제 완화 솔루션 구현 여부를 결정합니다.

그림 2 손실 발생 가능성을 발생 시마다 소요되는 비용으로 곱한 값을 나타내는 ALE

그림 2** 손실 발생 가능성을 발생 시마다 소요되는 비용으로 곱한 값을 나타내는 ALE **(더 크게 보려면 이미지를 클릭하십시오.)

그런데 표준 ALE에서는 문제 완화에 소요되는 비용이 고려되지 않는다는 문제가 있습니다. 문제 완화 솔루션은 그 자체로 비용을 발생시킬 뿐만 아니라 부작용에 따른 비용도 발생하게 됩니다.

가장 일반적인 보안 수단 중 하나인 계정 잠금을 예로 들어보겠습니다. 공격자가 암호를 유추하지 못하도록 한다는 표면상의 목적으로 계정 잠금을 구축하는 조직이 많습니다. 공격자가 암호 하나를 유추해 낼 가능성은 수학적으로 계산할 수 있습니다. 창의력만 조금 발휘하면 공격자가 암호 유추에 성공했을 때 초래되는 평균 위험 비용도 구할 수 있습니다. 많은 조직에서는 이 두 값을 기준으로 ALE가 너무 높다고 판단된 경우 계정 잠금을 구현합니다.

그러나 이때 계정 잠금이라는 문제 완화 솔루션에 소요되는 비용은 간과하기가 쉽습니다. 계정 잠금 자체를 구현하는 비용은 물론 상당히 미미합니다. 하지만 엄밀하게 따지면 계정 잠금에 따른 부작용의 비용도 계산에 넣어야 합니다.

우선 지원 부서에서 잠겨진 사용자 계정을 풀어 주는 데 따른 비용이 발생합니다. 계정이 단기간 동안, 예를 들어 15분 정도만 잠기더라도 그 기간 동안의 생산성 손실에 따른 비용이 발생합니다. 이러한 요인은 일정 기간 동안 사고가 발생할 가능성을 각 보안 사고의 비용에 곱한 값으로 계산합니다. 또한 이 비용에 예상되는 잠금 이벤트 수(기존 로그에 기록된 수)를 곱해야 합니다.

사용자로 인해 악화되는 요인도 고려해야 합니다. 실제 사례들을 보면 계정 잠금이 적용될 경우 사용자가 잘못 입력할 위험이 상대적으로 적은 단순한 암호를 사용하게 되리라는 사실을 쉽게 예측할 수 있습니다. 따라서 계정 잠금을 구현하더라도 방지하고자 했던 사고의 가능성이 완전히 제거되지는 않습니다.

마지막으로, 문제 완화 솔루션을 도입하기 전에는 없었던 취약점이 솔루션 도입으로 새롭게 나타날 수도 있습니다. 계정 잠금 예의 경우 공격자가 잘못된 암호를 반복적으로 유추해 입력함으로써 네트워크의 모든 계정이 잠기게 할 수도 있습니다. 이러한 문제가 발생하면 그때마다 관련 비용이 초래됩니다.

이러한 요인을 모두 고려할 때 손실 예측 수식을 수정해야 한다는 사실은 자명합니다. 첫째, 사고 발생 가능성을 수정해야 합니다. 사고 발생 가능이 줄기는 했지만 위에서 살펴본 바와 같이 완전히 0이 되지는 않습니다. 사고 발생 시마다 소요되는 비용도 변경해야 합니다. 그리고 해당 제품 비용에 문제 완화 솔루션의 비용도 추가해야 합니다. 이 비용은 구현 비용에 모든 부작용의 연간 비용을 합산하여 구합니다. 부작용의 연간 비용은 부작용 발생 가능성과 부작용 발생 시에 소요되는 비용을 곱한 값입니다. 보다 정확한 위험 분석이 가능한 이 수식을 약간 단순화하면 그림 3과 같습니다.

그림 3의 수정된 수식을 사용하면 특정 문제에 따른 위험을 보다 정확하게 분석할 수 있습니다. 이미 많은 조직에서 위험 분석에 사용되고 있는 방법입니다. 그러나 아직도 문제 완화 솔루션이 미치는 영향을 분석하는 데 맞지 않는 단순한 방식으로 위험을 분석하는 조직이 너무 많습니다. 수정된 ALE 수식을 사용함으로써 이러한 문제를 해결할 수 있습니다.

그림 3 문제 완화 솔루션의 추가 비용 고려

그림 3** 문제 완화 솔루션의 추가 비용 고려 **(더 크게 보려면 이미지를 클릭하십시오.)

결론

이 글을 읽은 후에 할 일은 바로 보안 전략에 대한 진부한 지식을 다시 한번 검증하는 것입니다. 진부한 시각으로 세상을 보는 자세는 정보 보안 분야에서 일하는 사람에게 어울리지 않습니다. 그리고 구태의연한 가정들도 버려야 합니다.

공격자들은 끊임없이 진화하고 있습니다. 금전적인 이유로, 국가적 패권 전쟁의 일환으로, 자신의 신념을 관철하기 위해 공격자들은 점점 전문화되고 있습니다. 따라서 보안 개선에 전혀 도움이 되지 않는 보안 수단에 시간과 돈을 낭비할 여유가 없습니다. 또한 위험 관리에도 훨씬 더 복잡한 접근 방식이 요구됩니다.

첫째, 모든 보안 솔루션에는 절충이 필요하다는 점을 인식해야 합니다. 모든 결과를 확실히 예측할 수는 없습니다.

둘째, 보안 시스템은 상호 의존적인 시스템이라는 점을 이해해야 합니다. 시스템에 변경된 보안 솔루션을 도입하면 시스템 자체가 수정되므로 시스템을 다시 분석해야 합니다.

변경 사항이 시스템에 막대한 영향을 미쳐 득보다 실이 큰 경우가 많으므로 이러한 분석은 그러한 변경 사항을 실제로 구현하기 전에 미리 실시하는 것이 바람직합니다. 변경 내용 분석의 필요성을 알려 주는 좋은 분석 도구를 사용하면 잊지 않고 분석을 실시하는 데 도움이 됩니다.

마지막으로, 사용자라는 요소도 잊어서는 안 됩니다. 정보 보안과 관련한 모든 조치는 기업과 조직 내의 사용자가 가능한 안전하게 작업할 수 있도록 하기 위한 것입니다.

최근 필자는 한 프레젠테이션에서 바이러스 백신 프로그램을 실행하기 위해 컴퓨터를 구입하는 사용자는 없음을 지적한 바 있습니다. 보안이 관리자의 주된 목표일지는 모르지만 회사의 주된 목표는 아니라는 뜻입니다. 지금 당장은 조직에서 보안이 최대 화두로 떠올라 보안을 간과하지 않을지라도, 보안 부서가 회사를 위해 일하는 것이지 회사가 보안 부서를 위해 존재하는 것은 아니라는 사실을 잊어서는 안 됩니다. 이 사실을 간과하면 사용자가 작업을 수행하기 위해 자신이 이해하지 못하거나 동의하지 않는 보안 통제를 우회하는 등, 다른 편법을 사용하게 됩니다.

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. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..