Special Coverage: Windows Server 2008

Windows Server 2008의 감사 및 규정 준수

Rob Campbell, Joel Yoker

한 눈에 보기:

• 중요성이 증대되고 있는 규정 준수
• 환경의 변경 파악
• 보안 이벤트 감사의 문제점
• 감사의 기술적 측면

정보 기술의 세계에서는 끊임 없이 변경 사항이 발생합니다. 대부분의 IT 조직은 조직의 환경에서 발생하는 이와 같은 변경을 파악하는 데 점점 더 많은 부담을 느끼고 있습니다. IT 환경의 복잡함과 규모가 증대될수록

관리상의 부주의 및 실수로 인한 데이터 노출이 미치는 영향도 막대해집니다. 오늘날과 같이 이러한 사고에 대해 책임을 묻는 사회에서 IT 조직은 정보를 안전하게 보호해야 하는 법적인 책임을 안고 있습니다.

따라서 환경의 변경을 감사하는 작업이 매우 중요한 일로 부각되었습니다. 그 이유는 무엇일까요? 감사는 오늘날과 같이 규모가 크고 고도로 분산된 IT 환경의 변경을 파악하고 관리할 수 있는 수단을 제공합니다. 이 기사에서는 대부분의 조직에서 직면하고 있는 일반적인 문제와 IT 부서가 감당해야 하는 규정 준수 및 규제의 전반적인 추세, Windows® 감사의 몇 가지 기본 사항에 대해 살펴본 다음 Windows Server® 2008 및 Microsoft® System Center Operations Manager 2007의 ACS(Audit Collection Services) 기능을 사용하여 포괄적인 감사 전략을 수립하는 방법을 알아봅니다.

감사의 문제점

뉴스 헤드라인만 보더라도 알 수 있듯이 데이터 노출은 일상적인 문제가 되어 버렸습니다. 이와 같은 사고가 발생하면 대개 해당 조직은 법적 소송에 휘말리거나 재정적인 손실을 부담해야 하며 홍보에서도 문제가 발생하게 됩니다. 어떤 변경이 발생했는지 설명하거나 문제를 신속하게 파악하는 능력은 데이터 노출 사고가 미치는 영향을 줄이는 데 매우 중요한 역할을 합니다.

예를 들어 여러분의 조직에서 특정 고객층의 PII(개인 식별 정보)를 관리한다고 가정해 보십시오. 조직에서 관리 대상인 시스템에 포함된 정보를 보호할 수 있는 다양한 방법을 보유하고 있다 하더라도, 데이터 손상이 발생할 가능성은 여전히 존재합니다. 이 경우 조직에서 적절한 감사를 수행한다면 정확히 어떤 시스템이 손상되었는지, 더 구체적으로는 어떠한 데이터가 손실되었는지 쉽게 알 수 있을 것입니다. 감사를 수행하지 않으면 데이터 손실로 인한 영향이 훨씬 커질 수 있으며, 이는 대개 데이터 손실로 인한 손상의 범위를 예측할 수 있는 방법이 없기 때문입니다.

그렇다면 왜 IT 조직은 사전에 감사를 수행하지 않을까요? 사실을 얘기하자면 대부분의 조직은 감사의 기술적인 측면을 완전하게 이해하고 있지 못합니다. 고위 관리자는 일반적으로 백업 및 복원과 같은 개념에 대해서는 이해하고 있습니다. 그러나 환경의 변경을 감사하는 데 따르는 고유의 복잡함은 전달하기 어려운 메시지입니다. 그 결과 대개 큰 사고가 발생한 후에야 감사에 대한 질문이 제기되곤 합니다. 예를 들어 기본 감사 기능이 실행되어 있긴 하지만 특정 변경을 감사하도록 시스템이 구성되어 있지 않다면 계획 부족으로 인해 해당 정보는 수집되지 않을 것입니다.

더욱이 감사된 보안 이벤트에는 IT 전문가가 다루어야 할 몇 가지 고유의 문제가 있습니다. 이러한 어려움을 야기하는 요인 중 하나로는 오늘날과 같은 대규모 컴퓨팅 환경에서의 분산된 시스템을 꼽을 수 있습니다. 이러한 환경에서는 언제 어떤 시스템이나 시스템 집합에서든 변경이 발생할 수 있으며 이는 수집 및 집계의 어려움으로 이어집니다. 이는 상관 관계라는 또 다른 문제를 야기합니다. 발생하고 있는 현상의 의미를 올바르게 이해하려면 대개 단일 시스템 및 여러 시스템에서 발생한 이벤트 간의 관계를 분석해야 합니다.

일반적으로 감사는 전통적인 조직의 경계를 초월한다는 점에서도 문제가 발생합니다. 여러 가지 이유로 인해 다양한 조직 구조나 팀 구조가 존재할 수 있으며 이들을 연결하기가 쉽지 않을 수 있습니다. 대부분의 조직에는 디렉터리 서비스 팀, 메시징 인프라 팀, 데스크톱 팀이 있지만 이러한 영역을 모두 담당하는 보안 팀은 대개 하나뿐입니다. 또한 조직의 보안 전담 직원이 모든 영역에 상주하지 않을 수도 있습니다. 예를 들어 대부분의 경우 지점에서는 보안 이벤트 로그 관리를 비롯한 모든 작업을 한 사람 또는 소규모 인원으로 구성된 팀에 의존합니다.

마지막으로, 이벤트의 양이 엄청납니다. 감사된 보안 이벤트는 다른 종류의 이벤트 로그보다 그 양이 훨씬 많습니다. 수집된 이벤트의 수가 많으므로 로그를 효과적으로 보관하고 검토하기가 어렵습니다. 또한 이와 같은 정보의 보존 요구 사항을 명시하는 현재의 규정 및 제안된 규정은 오늘날과 같은 컴퓨팅 인프라에서 이러한 부담을 줄이는 데 전혀 도움이 되지 않고 있습니다.

과거에는 정보 액세스에 대한 감사는 단순히 알고 싶은 욕구와 보안을 유지하려는 시도로 요약할 수 있었습니다. 그러나 조직과 조직의 최고 관리자가 정보의 손실이나 적절한 대비책 결여에 대한 법적인 책임을 져야 하는 현재의 경우 IT 관리자는 자신이 담당하는 환경에 적용되는 모든 규정에 대해 잘 알고 있어야 합니다. 다국적 기업의 경우 국가마다 정보 및 정보 보호와 관련된 고유의 규정을 적용해야 하므로 감사에 따른 문제가 더욱 복잡해집니다. 그림 1에는 기존의 규정 준수 관련 법률 조항 및 이에 따라 IT 조직에 부여되는 책임이 나열되어 있습니다.

Figure 1 규정 및 이에 따른 IT 전문가의 책임

이러한 모든 법률적인 규제를 고려했을 때 IT 전문가는 어떤 준비를 해야 할까요? IT 관리자와 기술 전문가는 조직의 내/외부에 제공할 수 있는 명확하면서도 간략한 전략을 마련해야 합니다. 여기에는 적절한 감사 전략을 개발하는 것이 포함되며 이를 위해서는 사전 대응적 평가와 투자가 필요합니다. 여기서 중요한 사항은 감사는 설계의 후기 단계에서 고려할 대상이 아니라는 점입니다. 그러나 안타깝게도 현실에서는 이런 경우가 너무나 빈번히 발생하고 있습니다.

IT 조직이 직면한 이와 같은 문제는 일반적으로 사람, 프로세스 및 기술의 조합을 통해 해결할 수 있습니다. 감사의 경우 프로세스가 가장 중요합니다. 따라서 무엇보다도 감사의 기본 사항을 완벽하게 이해함으로써 규정 준수와 관련된 조직의 필요 및 요구 사항에 대응할 수 있어야 합니다. 이제 Windows 감사의 몇 가지 기본 사항을 살펴본 다음 Windows Server 2008과 Windows Vista®에서 변경된 내용에 대해 자세히 알아보겠습니다.

보안 이벤트 감사

감사된 모든 이벤트는 Windows 보안 이벤트 로그에 기록됩니다. 이러한 이벤트는 통상 즉각적인 조치를 취할 수 있는 것이 아니며 대개는 정보 제공을 목적으로 합니다. 각 이벤트는 발생한 특정 액세스 유형에 대해 간단히 '감사 성공' 또는 '감사 실패'를 기록합니다. 보안 이벤트 로그는 색 구분을 통해 문제를 쉽게 식별할 수 있는 응용 프로그램 이벤트 로그나 시스템 이벤트 로그와는 다릅니다. 예를 들어 응용 프로그램 이벤트 로그나 시스템 이벤트 로그에서 문제를 찾으려면 빨간색 이벤트를 보면 됩니다.

보안 이벤트 로그의 경우 감사된 이벤트의 양이 너무 많아서 이벤트가 표시되지 않을 뿐 아니라, 앞에서 언급했듯이 보안 데이터의 상관 관계로 인해 중대한 문제가 야기될 수 있다는 점에서 다른 이벤트 로그와 차별화됩니다. 단일 시스템에서 발생한 단순한 데이터 노출조차도 문제가 될 수 있습니다. 이 경우 보안 이벤트 로그를 분석하여 데이터 액세스에 사용된 계정이 어떤 것인지 확인해야 하며 이를 위해 관리자는 로그를 추적하여 계정을 찾아내야 합니다. 안타깝게도 오늘날의 정교한 공격은 대개 교묘하게 조정 및 분산되어 발생하므로 피해자는 이러한 종류의 분석을 하기가 몹시 어렵습니다.

따라서 Windows의 보안 이벤트 로그에 정보가 기록되도록 하는 핵심 요소인 감사 정책 및 SACL(시스템 액세스 제어 목록)에 대해 올바르게 이해하는 것이 중요합니다. 감사 정책은 그룹 정책이나 로컬 보안 정책을 통해 로컬 컴퓨터에 구성할 수 있는 설정이며, 특정 액세스 유형에 대한 성공 및 실패 이벤트의 모음을 정의합니다. 다음은 지난 수년 간 Windows에 제공된 기본 감사 정책 범주입니다. Windows Server 2008에 새로 도입된 세부적 감사 정책에 대해서는 뒤에서 자세히 설명합니다.

• 계정 로그온 이벤트 감사
• 계정 관리 감사
• 디렉터리 서비스 액세스 감사
• 로그온 이벤트 감사
• 개체 액세스 감사
• 정책 변경 감사
• 권한 사용 감사
• 프로세스 추적 감사
• 시스템 이벤트 감사

대부분의 IT 조직에서는 감사 정책 및 위와 같은 관련 범주를 정의해야 할 필요성에 대해 잘 이해하고 있습니다. 그러나 감사 정책은 솔루션의 한 부분일 뿐입니다. SACL 또한 전체적인 감사 계획을 구현하는 데 중요한 역할을 합니다. 특히 디렉터리 서비스 액세스 감사와 개체 액세스 감사 이 두 가지 감사 정책 범주는 전적으로 SACL에 의존하여 보안 이벤트 로그에 정보를 반환합니다. 그렇다면 SACL은 정확히 무엇일까요?

파일, 레지스트리, 디렉터리 서비스와 같은 각 개체에는 하나 이상의 ACE(액세스 제어 항목)가 포함된 ACL(액세스 제어 목록)이 있으며, 이 ACL은 DACL(임의 액세스 제어 목록)과 SACL이라는 두 가지 종류로 나뉩니다. 이 중에서 SACL은 보호된 개체에 대한 액세스 시도를 기록하는 설정을 정의합니다. SACL의 각 ACE는 지정된 트러스트를 받을 대상에 의한 액세스 시도 유형 중 보안 이벤트 로그에 기록되어야 할 유형을 지정합니다. ACE는 지정된 개체에 대해 성공 및/또는 실패 액세스 시도를 기록할지 여부를 정의합니다. 그림 2에서는 개체에 SACL을 사용하여 특정 액세스 유형에 대한 이벤트를 생성하는 방법을 보여 줍니다.

그림 2** 개체에 SACL 사용 **(더 크게 보려면 이미지를 클릭하십시오.)

환경의 변경과 관련된 "올바른" 감사된 이벤트를 캡처하기 위해서는 구성이 필요하며 감사 정책과 SACL 간의 관계를 이해하는 것이 매우 중요한 이유는 바로 이 때문입니다. 앞에서 언급했듯이, 디렉터리 서비스 액세스 감사와 개체 액세스 감사 정책은 해당되는 특정 범주에 대해서만 보안 이벤트 로그에 감사 이벤트가 생성되도록 하지만 개체의 SACL에 감사 ACE가 구성된 경우에만 이벤트가 생성됩니다. 정책과 SACL이 적절히 구성되면 Windows LSA(로컬 보안 기관)에 의해 보안 이벤트가 생성되어 보안 이벤트 로그에 기록됩니다.

이벤트는 두 가지 고유 영역으로 구성됩니다. 하나는 정적이며 각 이벤트 ID에 대해 미리 정의된 머리글이고, 다른 하나는 동적이며 다양한 이벤트에 대해 서로 다른 정보를 포함하는 본문입니다. 그림 3에서는 샘플 Windows Server 2008 보안 이벤트의 두 요소를 보여 줍니다. 이와 같은 이벤트 구성 요소에 대한 이해는 감사 프로젝트의 분석 단계에서 중요하며 특히 ACS와 같은 도구에서의 정보 반환 방법을 이해하는 데 필요합니다.

그림 3** 감사된 이벤트의 머리글 및 본문 **(더 크게 보려면 이미지를 클릭하십시오.)

Windows Eventing 6.0

지금까지 감사에 따르는 문제를 살펴보았으므로 이제 Windows Server 2008을 사용하여 조직에서 이러한 문제를 해결하는 방법에 대해 알아보겠습니다. Windows Server 2008은 보안 이벤트 관리와 관련된 환경을 대폭 개선한 새로운 Windows Eventing 6.0 이벤트 하위 시스템이 포함된 첫 번째 서버 릴리스입니다. 여기서는 Windows Server 2008에 대해 중점적으로 설명하지만 이러한 새로운 기능의 95%는 Windows Vista에도 포함되어 있습니다.

대부분의 사람들이 Windows Eventing 6.0에서 처음 주목하는 요소 중 하나가 바로 새로운 사용자 인터페이스입니다. 새로운 이벤트 뷰어 MMC(Microsoft Management Console) 스냅인은 알아보기 쉬운 개요 및 요약 페이지, 유연성이 뛰어난 사용자 지정 보기 및 대폭 개선된 설명 텍스트를 제공합니다. 이러한 인터페이스를 통해 이제 최종 사용자나 시스템 관리자는 이벤트 뷰어 자체에서 이벤트 정보를 찾고 중요한 이벤트 로그 옵션을 구성할 수 있습니다.

대개 이벤트 로그 내의 보안 데이터에 영향을 미치는 주요 문제는 데이터 보존이었습니다. 이전에는 이벤트 로그 하위 시스템 및 모든 로그가 확장성 한계라는 문제에 직면해 있었습니다. 이 한계가 초과되면 전체 하위 시스템의 이벤트 기록이 중지되었습니다. 그러나 Windows Eventing 6.0의 경우 이와 같은 문제가 발생하지 않으므로 이제 조직에서는 가용 디스크 공간의 문제만 해결하면 됩니다. 그러나 크기가 매우 큰 이벤트 로그의 경우 필터링을 통해 개별 이벤트 로그 항목을 분석해야 하고 이는 매우 번거로운 작업이 될 수 있으므로 로그를 관리 가능한 크기로 유지하려고 할 것입니다.

물론 이 경우에도 다수의 시스템에 대한 이벤트 로그 보관 계획을 마련하는 작업은 IT 관리자의 몫입니다. 로컬 서버 수준에서 이와 같은 업무를 지원하기 위해 Windows Eventing 6.0에는 "로그가 꽉 차면 로그 보관. 이벤트를 덮어쓰지 않음"이라는 옵션이 추가되었습니다. 이전 버전의 Windows에서는 AutoBackupLogFiles 레지스트리 값을 직접 수정하는 방법을 통해서만 이 옵션을 설정할 수 있었습니다. 이 옵션은 로그의 로컬 보관을 위한 메커니즘을 제공할 뿐이며 시간의 경과에 따른 파일 관리 솔루션을 제공하거나 여러 시스템에 걸쳐서 발생하는 집계 문제를 해결하지는 않습니다. Audit Collection Services는 이를 위한 완전한 솔루션을 제공합니다. 지금부터 ACS에 대해 간단히 살펴보겠습니다.

새로운 인터페이스는 시작에 불과합니다. Windows Eventing 6.0의 진정한 성능은 새로운 Windows 이벤트 로그 서비스와 기본 XML 기반 엔진에 있습니다. 바로 이 두 개의 구성 요소를 통해 개선된 확장성, 액세스 가능성 및 관리 옵션이 제공됩니다. 이제 유연성이 뛰어난 XML 형식으로 이벤트가 저장되므로 기본적으로 이벤트 정보를 활용하는 사용자 지정 솔루션을 만들 수 있습니다.

또한 Windows Eventing 6.0은 관리 작업을 특정 이벤트에 연결하는 기능을 제공합니다. Windows Eventing 6.0은 Windows 이벤트 수집기 서비스와 작업 스케줄러를 통합하여 작업 기반 이벤트를 제공함으로써 이와 같은 기능을 제공합니다. 이는 이전에는 시간을 기준으로 이벤트를 트리거하는 것으로만 제한되었던 작업 스케줄러를 위한 새로운 패러다임입니다. Windows Server 2008 이벤트 뷰어에서 모든 이벤트의 상황에 맞는 메뉴에서 사용할 수 있는 "이 이벤트에 작업 연결" 마법사는 특정 이벤트가 기록될 때마다 간편하게 프로그램을 시작하거나 전자 메일을 보내거나 메시지를 표시하는 방법을 제공합니다. 이 기능은 환경에서 발생하는 작업 중 보안 이벤트로 분류할 수 있는 특정 작업을 식별하려는 경우에 매우 유용합니다. 예를 들어 도메인 컨트롤러에 대한 "Schema Update Allowed" 레지스트리 키의 변경을 감사하는 경우, 이 레지스트리 키가 수정되면 특정 보안 관리자에게 해당 사실을 알리는 전자 메일을 보내는 작업을 만들 수 있습니다.

다수의 이벤트 항목을 수집하고 저장하는 이 새로운 기능 이외에도 이제 이벤트 로그에 기록되는 이벤트를 보다 정확하게 제어할 수 있게 되었습니다. 이는 GAP(세부적 감사 정책)라는 새로운 기능을 통해 수행할 수 있습니다. 이전 버전의 Windows에서는 아홉 개의 광범위한 감사 범주로 인해 너무 많은 이벤트가 생성되곤 했습니다. 이제 각각 관련된 이벤트 하위 집합을 나타내는 50개의 세분화된 하위 범주를 사용하여 이와 같은 상위 범주를 제어할 수 있습니다.

이러한 하위 범주를 통해 범주 수준 자체는 그대로 표시하면서 중요하지 않은 정보는 필터링을 통해 이벤트 로그에서 제외할 수 있습니다. 예를 들어 이전에는 레지스트리의 변경만 모니터링하고 파일 시스템은 모니터링하지 않으려는 특정 시스템이 있을 경우 개체 액세스 범주에 대해 성공 또는 실패를 보고하도록 하는 것 외에는 다른 방법이 없었습니다. 이제 GAP를 사용하여 필터링을 통해 파일 시스템, 인증 서비스, 파일 공유와 같은 하위 범주는 제외하고 레지스트리 하위 범주에 대해서만 이벤트를 보고할 수 있습니다. Windows Server 2008 시스템의 GAP 하위 범주를 보려면 상승된 명령 프롬프트에서 Auditpol 명령을 실행해야 합니다. 사용할 수 있는 GAP 하위 범주를 표시하려면 다음과 같이 입력합니다.

auditpol /list /subcategory:*

시스템에 구성되어 있는 GAP 하위 범주 목록을 보려면 다음과 같이 입력합니다.

auditpol /get /category:*

GAP는 표준 그룹 정책 사용자 인터페이스를 통해 구성할 수 없으며 auditpol.exe를 통해 관리해야 합니다. Windows Server 2008 및 Windows Vista 시스템용 그룹 정책을 통해 GAP 설정을 배포하는 방법에 대한 지침은 support.microsoft.com/kb/921469의 기술 자료 문서를 참조하십시오.

또한 Windows Server 2008에서는 보안 이벤트 로그의 특정 유형에 대한 이전 값 및 새 값을 모두 캡처할 수 있습니다. 이전 버전 Windows의 감사 하위 시스템에서는 변경된 Active Directory® 개체 특성의 이름이나 레지스트리 값만 기록하고 특성의 이전 값과 현재 값은 기록하지 않았습니다. 이 새로운 기능은 Active Directory 도메인 서비스, Active Directory Lightweight Directory Services 및 Windows 레지스트리에 적용됩니다. "레지스트리" 또는 "디렉터리 서비스 변경" 하위 범주에 대해 '감사 성공' 또는 '감사 실패'를 설정하고 관련된 SACL을 설정하면, 해당 개체에 대해 수행된 작업에 대한 자세한 이벤트가 이벤트 로그에 생성됩니다. 이 설정 작업은 다음 auditpol 명령을 사용하여 수행할 수 있습니다.

auditpol /set /subcategory:"Registry" /success:enable
auditpol /set /subcategory:"Directory Service     
    Changes" /success:enable

레지스트리 변경은 그림 4와 같이 이벤트 ID 4657로 나타납니다.

그림 4** 레지스트리 변경 전과 후 **(더 크게 보려면 이미지를 클릭하십시오.)

이 기능은 특히 Active Directory 개체의 변경을 추적하려는 경우 유용합니다. 디렉터리 서비스 변경은 그림 5와 같이 이벤트 ID 5136 이벤트 쌍에서 나타납니다. 각 이벤트의 이벤트 본문에는 디렉터리 서비스 '개체', '특성' 및 '작업'이 있습니다. 기존 데이터가 있는 특성이 변경된 경우 '값이 삭제됨'과 '값이 추가됨'이라는 두 가지 작업을 볼 수 있습니다. 채워져 있지 않았던 특성의 경우 데이터가 특성에 기록될 때 '값이 추가됨' 작업만 볼 수 있습니다. 예를 들어 telephoneNumber와 같은 사용자 개체의 특성에 성공적인 수정 작업을 수행한 경우 Active Directory는 자세한 이벤트 로그 항목에 이 특성의 이전 값과 현재 값을 기록합니다.

그림 5** 디렉터리 서비스 변경 이벤트 전과 후 **(더 크게 보려면 이미지를 클릭하십시오.)

새 개체가 만들어지면 개체가 만들어질 때 채워진 특성 값이 기록됩니다. 개체가 도메인 내에서 이동되면 이전 위치와 새 위치가 구별되는 이름 형식으로 기록됩니다. 이 "이전 값 및 새 값" 기능은 알맞은 감사 정책 설정을 구성하면 기본적으로 설정됩니다. 직원 ID 번호 변경과 같이 기밀을 유지해야 하는 특성이 있는 경우 간단한 스키마 수정을 통해 해당 특성을 제외할 수 있습니다. 그림 6과 같이 스키마에서 특성의 searchFlags 속성을 0x100(값 256 -NEVER_AUDIT_VALUE)으로 수정하면 이 특성이 변경되어도 디렉터리 서비스 변경 이벤트가 발생하지 않습니다.

그림 6** 디렉터리 서비스 변경에서 특성 제외 **(더 크게 보려면 이미지를 클릭하십시오.)

마지막으로, Windows Eventing 6.0에는 이벤트 구독이라는 또 다른 주목할 만한 새로운 기능이 포함되어 있습니다. 앞에서 언급했듯이, 이벤트 로그에 액세스하고 검토하는 것은 시스템 관리자의 주요 작업입니다. 새로운 이벤트 구독 기능은 시스템 간에 이벤트를 직접 전달할 수 있는 방법을 제공합니다. 이벤트 구독은 이벤트를 수집하는 이벤트 수집기와 이벤트를 지정된 호스트로 전달하도록 구성된 이벤트 원본으로 이루어집니다. 이벤트를 사용하는 기능은 Windows Eventing 6.0의 새로운 기능인 Windows 이벤트 수집기 서비스에서 제공하고, 구독자 기능은 Windows 이벤트 로그 서비스에서 기본적으로 제공합니다. Windows Server 2008이나 Windows Vista 시스템과 같은 여러 이벤트 원본에서 이벤트를 수집하도록 수집기를 구성할 수 있습니다.

이벤트 원본에서 수집된 모든 데이터는 전달된 이벤트(ForwardedEvents.evtx)라는 별도의 이벤트 로그에 보관되고 수집기의 이벤트 로그 서비스를 통해 관리됩니다. 수집기와 원본의 두 끝점 모두에서 구성 작업이 필요합니다. 원본에서는 winrm quickconfig –q를 사용하고 수집기에서는 wecutil qc /q를 사용하여 구성 작업을 자동화할 수 있습니다. 이 이벤트 구독 기능은 엔터프라이즈용으로 설계된 것이 아니며 외부 데이터베이스에 이벤트를 전달하는 시스템을 대체하지 않는다는 점에 유념하십시오.

일례로 이 기능은 소규모 웹 팜에서 사용하기에 적합합니다. 웹 서버와 SQL 서버를 비롯하여 특정 웹 사이트와 연결된 몇 대의 시스템이 있다고 가정해 보십시오. 새로운 이벤트 구독 기능을 사용하면 이러한 시스템의 보안 이벤트 로그 정보를 단일 시스템에 통합할 수 있습니다. 대규모 환경에서는 대개 이보다 고급화된 이벤트 로그 통합 도구 집합이 필요합니다.

Audit Collection Services

Windows Server 2008의 모든 새로운 기능을 사용할 경우 보안 이벤트 로그 정보에 대한 장기적인 관리 및 보관을 위한 실질적인 솔루션은 중앙 집중화된 감사 정보 데이터베이스를 통해 확보할 수 있습니다. System Center Operations Manager 2007의 핵심 기능인 Audit Collection Services는 보안 이벤트 데이터의 전달, 수집, 저장 및 분석을 위한 메커니즘을 제공합니다. 보안 이벤트는 거의 실시간으로 수집되어 중앙 SQL 저장소에 저장됩니다. 또한 ACS는 감사 정보에 대해 최소 권한 액세스를 제공하는 방법을 제공하는데 이는 실제로 감사되는 시스템에 대해 어떠한 물리적 액세스도 필요하지 않기 때문입니다. 이제 ACS가 어떤 방식으로 작동하는지 살펴보겠습니다.

ACS에는 세 가지 주요 구성 요소가 있습니다. 하나는 Operations Manager 에이전트의 일부이며 이벤트 로그 데이터를 클라이언트에서 ACS 인프라로 전송하는 전달자입니다. 전달자는 데이터를 두 번째 구성 요소이자 서버 쪽 수신기인 수집기로 전송합니다. ACS 전달자는 TCP 포트 51909를 통해 연결하여 할당된 수집기와 안전한 방식으로 통신합니다. 이벤트 로그 데이터는 전송되기 전에 XML로 정규화됩니다. 즉, 불필요한 정보는 제거되고 이벤트 정보는 이벤트 머리글 및 본문 정보를 기준으로 매핑된 필드에 요약됩니다. 정보가 수집기에 도달하면 세 번째이자 마지막 구성 요소인 ACS 데이터베이스로 전송됩니다. 이 데이터베이스는 보안 이벤트 정보의 장기 저장을 위한 저장소가 됩니다. 한번 저장된 정보는 SQL 쿼리를 통해 직접 검색하거나 SQL Server® Reporting Services를 사용하여 HTML 보고서로 렌더링할 수 있습니다. ACS는 그림 7에 나오는 세 가지 기본 보기를 제공합니다.

Figure 7 ACS 보기

성능 측면에서 볼 때 단일 ACS 수집기는 초당 최대 100,000개의 이벤트를 처리할 수 있으며 연속적으로는 초당 최대 2,500개의 이벤트를 처리할 수 있습니다. 현재 계획상으로 단일 ACS 수집기는 기본 감사 정책 설정을 기준으로 최대 150개의 도메인 컨트롤러, 3000개의 구성원 서버 또는 20,000개의 워크스테이션을 지원할 수 있습니다. 테스트를 거친 한 실제 시나리오에서는 대략 150개의 도메인 컨트롤러를 지원할 경우 초당 140개의 이벤트 처리 성능과 시간당 평균 최대 500,000개의 이벤트 처리 성능을 보여 주었습니다. 불과 14일(ACS에 대한 기본 보존 설정값) 동안 150GB가 넘는 보안 이벤트 데이터가 SQL Server 데이터베이스에 저장되었습니다. 보다 적극적으로 감사 정책 및 관련 SACL 구성을 사용한다면 시간당이든 하루당이든 분명히 전반적으로 더 많은 데이터가 생성될 것입니다.

여기서 핵심은 이렇게 많은 양의 데이터가 생성된다면 일반적인 대규모 엔터프라이즈 환경에서 사람의 힘으로 모든 이벤트를 검토하는 것은 불가능하다는 점입니다. 역으로 말하자면 조직에서는 여기에 명시된 수치를 두려워해서는 안됩니다. 환경에서 발생하고 있는 변경을 이해하려면 대량의 데이터를 분석하는 수고를 들여야 합니다.

바로 여기에서 ACS의 가치가 빛을 발합니다. SQL Server Reporting Services와 ACS를 사용하면 일반적으로 보안 이벤트 로그에 묻혀 알아볼 수 없는 문제를 응용 프로그램 이벤트 로그의 색으로 구분된 이벤트와 같이 쉽게 식별할 수 있도록 바꿀 수 있습니다. ACS에는 기본 보고서 집합이 포함되어 있으며 이를 사용자 고유 환경의 필요에 맞게 간단히 확장할 수 있습니다.

다음 시나리오를 예로 들어 보겠습니다. 환경에 있는 외부 트러스트의 민감도 문제로 인해 우리 팀은 관리자로부터 Active Directory 트러스트 만들기에 대한 과정을 자세히 보여 주는 보고서 개발을 요청 받았습니다. 몇 가지 조사를 실시한 결과, 트러스트가 만들어질 때 Active Directory의 특정 도메인 이름 지정 컨텍스트 내에서 cn=System 컨테이너에 trustedDomain 개체가 만들어진다는 사실을 알게 되었습니다. 이에 따라 이 컨테이너의 SACL을 편집하여 모든 트러스트된 도메인 개체가 성공적으로 생성되는지 여부를 감사하도록 하였고, 그 이후부터는 이러한 유형의 개체가 만들어질 때마다 보안 이벤트를 캡처할 수 있게 되었습니다. 이로 인해 트러스트 만들기가 수행된 DC의 보안 이벤트 로그에 566개의 이벤트가 기록되었습니다. 그런 다음 ACS에서 이 정보를 검색하기 위해 간단한 SQL 쿼리를 작성했습니다.

select * from AdtServer.dvAll 
where EventID = '566' and
String05 like '%trustedDomain%'
order by CreationTime desc

이 정보를 보고서로 만들려면 보고서 개발 기능을 제공하는 SQL Server 2005 Reporting Services가 포함된 Visual Studio® 2005 버전을 사용하십시오. 마법사를 완료하면 그림 8에 나오는 것과 유사한 보고서가 만들어집니다. 또한 보안 이벤트 로그에 나타낼 수 있는 환경의 모든 변경 사항도 이와 유사한 모양의 보고서로 요약할 수 있습니다.

그림 8** 샘플 ACS 보고서 **(더 크게 보려면 이미지를 클릭하십시오.)

감사 계획 개발

지금까지 감사에 따르는 문제와 감사의 법적, 기술적 측면을 살펴보았습니다. 그렇다면 IT 관리자는 조직의 "감사 계획"을 개발하기 위해 어떤 식으로 접근해야 할까요? 대부분의 작업과 마찬가지로 포괄적인 감사 정책의 개발은 여러 단계로 이루어진 프로세스입니다. 첫 번째 단계에서는 감사할 대상을 결정해야 합니다. 여기에는 환경을 분석하고 감사를 생성할 이벤트 및 변경의 유형을 결정하는 작업이 포함됩니다. 여기에는 계정 잠금, 중요한 그룹 변경, 트러스트 만들기와 같은 간단한 항목 또는 환경에 존재하는 응용 프로그램 내의 구성 요소 수정과 같은 복잡한 변경이 포함될 수 있습니다. 여기서 핵심은 감사 계획의 "감사 대상"을 결정하는 데 반드시 관리자가 참여해야 한다는 것입니다. 이 과정은 서류로 기록해야 하고, 중대한 사건이 일어난 후뿐만 아니라 정기적으로 반복해야 합니다.

두 번째 단계에는 특정 변경과 관련하여 보안 이벤트 형태로 반환될 감사 정보의 양이 얼마나 되는지 식별하는 작업이 포함됩니다. 감사 정보는 암호화되어 쉽게 해독할 수 없습니다. 따라서 보안 이벤트가 실제로 의미하는 바를 이해할 수 있도록 감사를 실행하기 전에 보안 이벤트와 다양한 작업 간에 상관 관계를 설정해야 합니다. 즉, 사건이 일어나기 전에 이벤트와 작업 간의 관계를 파악해야 합니다.

세 번째 단계는 실제로 감사 정책과 SACL을 구현하는 것입니다. 앞에서 설명했듯이 디렉터리, 파일 시스템 및 레지스트리의 변경을 완전하게 파악하려면 이들 영역에 대해 감사 정책 설정(보안 이벤트 생성을 위해)과 SACL(관련된 작업에 대한 감사 추적 생성을 위해)을 정의해야 합니다.

이 모든 단계를 마치면 네 번째이자 마지막 단계인 수집, 트리거 및 분석을 수행합니다. 조직의 규모와 요구 사항에 따라 이들 작업은 Windows Server 2008의 기본 기능을 사용하여 처리하거나 System Center Operations Manager의 Audit Collection Services 기능과 같은 고급 솔루션을 통해 처리할 수 있습니다. 대부분의 조직의 경우 SACL을 정의하지 않고 감사 정책만 설정하는 실수를 흔히 하게 됩니다. 마지막 단계는 조직 내의 이해 관계자와 데이터를 공유하고 보고하기 위한 기술 솔루션을 구현하는 작업과 관련이 있습니다. 앞에서도 언급했듯이 대부분의 조직에는 보안을 담당하는 부서가 있으므로 기존의 조직 요소를 중심으로 감사 계획을 수립해야 해당 계획이 효과적으로 실현될 수 있습니다. 마지막 단계에서의 핵심 작업은 환경의 변경을 숙지하고 있어야 하는 모든 관련자에게 유의적인 방법으로 정보를 수집하고 제공하는 것입니다.

단순히 포괄적인 감사 계획을 떠나서라도 대부분의 IT 조직은 하나의 중대한 이벤트입니다. 이전 플랫폼에 비해 Windows Server 2008은 보안 이벤트 데이터의 수집 및 분석을 위한 향상된 메커니즘을 제공합니다. ACS와 같은 고급 수집 및 보고 기술은 분산되어 있는 많은 양의 이벤트로 인해 모호해진 문제를 명확하게 드러냄으로써 변경을 즉시 파악할 수 있도록 합니다.

대부분의 IT 문제와 마찬가지로 프로세스가 가장 문제가 됩니다. IT 관리자가 기대하는 바를 얻으려면 언제나 추가적인 구성 및 분석 작업이 필요합니다. 따라서 환경의 요구 사항을 심층적으로 이해하고 Windows 플랫폼의 기능을 사용하면 이러한 문제를 사전에 해결할 수 있습니다. 이것으로 설명을 마치겠습니다.

Rob Campbell, Joel Yoker Rob Campbell은 Microsoft Federal 팀의 수석 기술 전문가이고 Joel Yoker는 수석 컨설턴트입니다. Rob과 Joel은 모두 미연방 정부 고객을 위한 보안 솔루션을 개발하여 배포하는 업무를 주로 담당하고 있습니다.

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