3 월 2008 Auditing and Regulatory Compliance in 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 전문가 의 책임 
 규정 책임 
 Sarbanes - Oxley Act ( SOX ) , 2002 년 404 항 에서 는 정보 시스템 의 역할 을 명시 하 고 있 으며 공개 적 으로 거래 를 하 는 기업 에게 해당 기업 이 내부 회계 를 엄격 하 게 관리 하 고 있 음 을 증명 하 는 자료 를 매년 제출 하 도록 요구 하 고 있 습니다 . 
 Health Insurance Portability and Accountability Act ( HIPPA ) 의료 관련 데이터 의 보안 및 개인 정보 보호 에 대해 명시 합니다 . " Security Rule " 에서 는 의료 관련 데이터 의 관리 적 , 물리 적 , 기술 적 측면 의 보호책 에 대해 다루 고 있 습니다 . 
 Electronic Discovery ( eDiscovery ) 문서 에 액세스 하 는 사람 및 액세스 방법 에 대한 책임 을 비롯 하 여 문서 보존 및 액세스 표준 을 정의 합니다 . 
 Federal Information Security Management Act ( FISMA ) , 2002 년 미국 정부 시스템 , 다양 한 법률 집행 기관 과 의 협력 , 통제 권 확립 , 상용 제품 및 소프트웨어 기능 의 승인 을 위한 포괄 적 인 정보 보안 ( INFOSEC ) 프레임워크 를 제공 하 기 위한 연방 정부 명령법 입니다 . 3544 항 에서 는 IT 통제 를 비롯 한 기관 의 책임 에 대해 다룹니다 . 
 Federal Information Processing Standards ( FIPS ) Publication 200 연방 정보 와 정보 시스템 에 대한 최소 보안 요구 사항 을 명시 하 고 있 으며 NIST Special Publication ( SP ) 800 - 53 에 있 는 권장 사항 을 간략 하 게 보여 줍니다 . NIST SP 800 - 53 의 AU - 2 ( Auditable Events ) 조항 에서 는 정보 시스템 은 여러 구성 요소 의 감사 레코드 를 시스템 수준 의 시간 관련 감사 추적 에 컴파일 하 는 기능 과 감사 된 이벤트 를 개별 구성 요소 별 로 관리 하 는 기능 , 그리고 조직 이 정기 적 으로 감사 가능 한 이벤트 를 검토 할 수 있 도록 하 는 기능 을 제공 해야 한다고 명시 하 고 있 습니다 . 
 이러 한 모든 법률 적 인 규제 를 고려 했 을 때 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 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 하위 범주 를 표시 하 려면 다음 과 같이 입력 합니다 . 
 시스템 에 구성 되 어 있 는 GAP 하위 범주 목록 을 보 려면 다음 과 같이 입력 합니다 . 
 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 명령 을 사용 하 여 수행 할 수 있 습니다 . 
 레지스트리 변경 은 그림 4 와 같이 이벤트 ID 4657 로 나타납니다 . 
 그림 4 레지스트리 변경 전 과 후 ( 더 크 게 보 려면 이미지 를 클릭 하 십시오 . ) 
 이 기능 은 특히 Active Directory 개체 의 변경 을 추적 하 려는 경우 유용 합니다 . 디렉터리 서비스 변경 은 그림 5 와 같이 이벤트 ID 5136 이벤트 쌍 에서 나타납니다 . 각 이벤트 의 이벤트 본문 에 는 디렉터리 서비스 ' 개체 ', ' 특성 ' 및 ' 작업 ' 이 있 습니다 . 기존 데이터 가 있 는 특성 이 변경 된 경우 ' 값 이 삭제 됨 ' 과 ' 값 이 추가 됨 ' 이 라는 두 가지 작업 을 볼 수 있 습니다 . 채워져 있 지 않 았 던 특성 의 경우 데이터 가 특성 에 기록 될 때 ' 값 이 추가 됨 ' 작업 만 볼 수 있 습니다 . 예 를 들 어 telephoneNumber 와 같 은 사용 자 개체 의 특성 에 성공 적 인 수정 작업 을 수행 한 경우 Active Directory 는 자세 한 이벤트 로그 항목 에 이 특성 의 이전 값 과 현재 값 을 기록 합니다 . 
 그림 5 디렉터리 서비스 변경 이벤트 전 과 후 ( 더 크 게 보 려면 이미지 를 클릭 하 십시오 . ) 
 새 개체 가 만들 어 지 면 개체 가 만들 어 질 때 채워진 특성 값 이 기록 됩니다 . 개체 가 도메인 내 에서 이동 되 면 이전 위치 와 새 위치 가 구별 되 는 이름 형식 으로 기록 됩니다 . 이 " 이전 값 및 새 값 " 기능 은 알맞 은 감사 정책 설정 을 구성 하 면 기본 적 으로 설정 됩니다 . 직원 ID 번호 변경 과 같이 기밀 을 유지 해야 하 는 특성 이 있 는 경우 간단 한 스키마 수정 을 통해 해당 특성 을 제외 할 수 있 습니다 . 그림 6 과 같이 스키마 에서 특성 의 searchFlags 속성 을 0 x 100 ( 값 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 서버 를 비롯 하 여 특정 웹 사이트 와 연결 된 몇 대 의 시스템 이 있 다고 가정 해 보 십시오 . 새로운 이벤트 구독 기능 을 사용 하 면 이러 한 시스템 의 보안 이벤트 로그 정보 를 단일 시스템 에 통합 할 수 있 습니다 . 대 규모 환경 에서 는 대개 이 보다 고급 화 된 이벤트 로그 통합 도구 집합 이 필요 합니다 . 
 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 보 기 이름 용도 
 AdtServer . dvHeader 수집 된 이벤트 의 머리글 정보 
 AdtServer . dvAll 수집 된 이벤트 의 머리글 및 모든 본문 정보 
 AdtServer . dvAll 5 수집 된 이벤트 의 머리글 및 본문 정보 의 처음 다섯 문자열 
 성능 측면 에서 볼 때 단일 ACS 수집 기 는 초당 최대 100 , 000 개 의 이벤트 를 처리 할 수 있 으며 연속 적 으로 는 초당 최대 2 , 500 개 의 이벤트 를 처리 할 수 있 습니다 . 현재 계획 상 으로 단일 ACS 수집 기 는 기본 감사 정책 설정 을 기준 으로 최대 150 개 의 도메인 컨트롤러 , 3000 개 의 구성원 서버 또는 20 , 000 개 의 워크스테이션 을 지원 할 수 있 습니다 . 테스트 를 거친 한 실제 시나리오 에서 는 대략 150 개 의 도메인 컨트롤러 를 지원 할 경우 초 당 140 개 의 이벤트 처리 성능 과 시간 당 평균 최대 500 , 000 개 의 이벤트 처리 성능 을 보여 주 었 습니다 . 불과 14 일 ( ACS 에 대한 기본 보존 설정 값 ) 동안 150 GB 가 넘 는 보안 이벤트 데이터 가 SQL Server 데이터베이스 에 저장 되 었 습니다 . 보다 적극 적 으로 감사 정책 및 관련 SACL 구성 을 사용 한다면 시간 당 이 든 하루 당 이 든 분명히 전반 적 으로 더 많 은 데이터 가 생성 될 것 입니다 . 
 여기 서 핵심 은 이렇게 많 은 양 의 데이터 가 생성 된다면 일반 적 인 대 규모 엔터 프라이즈 환경 에서 사람 의 힘 으로 모든 이벤트 를 검토 하 는 것 은 불 가능 하 다는 점 입니다 . 역 으로 말 하 자면 조직 에서 는 여기 에 명시 된 수치 를 두려워해서 는 안 됩니다 . 환경 에서 발생 하 고 있 는 변경 을 이해 하 려면 대량 의 데이터 를 분석 하 는 수고 를 들여야 합니다 . 
 바로 여기 에서 ACS 의 가치 가 빛 을 발 합니다 . SQL Server Reporting Services 와 ACS 를 사용 하 면 일반 적 으로 보안 이벤트 로그 에 묻혀 알아볼 수 없 는 문제 를 응용 프로그램 이벤트 로그 의 색 으로 구분 된 이벤트 와 같이 쉽 게 식별 할 수 있 도록 바꿀 수 있 습니다 . ACS 에 는 기본 보고서 집합 이 포함 되 어 있 으며 이 를 사용 자 고유 환경 의 필요 에 맞 게 간단히 확장 할 수 있 습니다 . 
 이 정보 를 보 고 서로 만들 려면 보 고서 개발 기능 을 제공 하 는 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 은 모두 미연방 정부 고객 을 위한 보안 솔루션 을 개발 하 여 배포 하 는 업무 를 주로 담당 하 고 있 습니다 .