Exchange Server 2007 서비스 팩 2를 사용한 사서함 액세스 감사 이해

 

적용 대상: Exchange Server 2007 SP2

마지막으로 수정된 항목: 2012-03-26

액세스 감사는 사서함 데이터베이스의 메일 액세스 지점인 Microsoft Exchange Store.exe 프로세스에서 구현되고, 사용자가 연 사서함 리소스에 대한 정보를 관리자에게 제공하기 위한 이벤트 로그 이벤트 집합을 나타냅니다. 이러한 이벤트는 새로운 이벤트입니다. 이러한 이벤트로 인해 다른 용도로 사용될 수 있는 기존 이벤트가 수정되지는 않습니다.

액세스 감사는 Microsoft Exchange IS 리소스의 진단 로깅 범주 집합을 통해 사용하도록 설정됩니다. 이때 각 범주는 서로 다른 유형의 리소스 액세스에 해당합니다. 각 범주를 독립적으로 사용하도록 설정할 수도 있습니다. 이렇게 하면 관리자가 특정 조직에 적합한 정보 수준과 이 정보를 기록할 때 발생하는 해당 부하를 선택할 수 있습니다.

진단 로깅 범주에는 다음이 포함됩니다.

  • 폴더 액세스: 받은 편지함, 보낼 편지함, 보낸 편지함 폴더 등의 폴더 열기에 해당하는 이벤트를 기록할 수 있습니다.

  • 메시지 액세스: 명시적 메시지 열기에 해당하는 이벤트를 기록할 수 있습니다.

  • 확장 다른 사람 이름으로 보내기: 사서함을 사용할 수 있는 사용자로 메시지 보내기에 해당하는 이벤트를 기록할 수 있습니다.

  • 확장 대신 보내기: 사서함을 사용할 수 있는 사용자 대신 메시지 보내기에 해당하는 이벤트를 기록할 수 있습니다.

각 범주는 0(사용 안 함)부터 5(최대 로깅)까지의 로깅 수준을 지원하며, 로깅 수준이 높을수록 기록되는 데이터의 양과 세부 정보가 많아집니다.

액세스 감사와 Windows 감사 비교

Microsoft Exchange 정보 저장소 서비스에서는 시스템 정책 기반 Windows NT 감사 이벤트를 지원합니다. 이러한 이벤트는 열린 개체의 각 인스턴스를 반영하며 보안 이벤트 로그에 기록됩니다. 이러한 로깅 유형은 제공되는 최고 감사 수준이며, 광범위한 개체 액세스 기록을 제공합니다. 액세스 감사는 Windows 감사를 대체하는 것이 아닙니다. Windows 감사에서는 개체 열기 및 닫기 이벤트를 주로 감사합니다. 액세스 감사에서는 액세스 중인 실제 사용자 데이터를 나타내는 이벤트를 먼저 처리하며 특정 개체 이벤트는 암시적으로 무시합니다.

다음 예제를 살펴보겠습니다.

Windows 감사를 사용하는 경우에는 "사서함 로그온" 위주로 감사합니다. 반면 Exchange의 로그온 이벤트는 데이터에 바인딩한 다음 클라이언트가 폴더를 열 수 있도록 하는 이벤트입니다. 즉, 로그온 개체 자체가 특정 데이터에 대한 액세스를 부여하지 않으며 거짓 감사 초점을 나타내는 것입니다.

액세스 감사에서는 실제 메시징 데이터에 액세스하거나 메시징 데이터에 영향을 주는 권한을 행사하는 클라이언트를 반영하는 이벤트를 주로 처리합니다. 예를 들면,

  • 클라이언트는 폴더를 열어 실제 데이터에 액세스합니다.

  • 클라이언트는 메시지를 열어 실제 데이터에 액세스합니다.

사서함 로그온은 폴더에 액세스하기 위한 암시적 작업입니다. 액세스 감사를 수행하면 약속 있음/없음 캐시 조회 작업 같이 IPM 하위 트리 아래에서 수행되는 작업을 무시할 수 있습니다. 또한 액세스 감사에서는 Exchange 시스템 프로세스의 액세스도 무시하며, 특정 액세스 클래스만 기록할 수도 있습니다. Windows 감사와 액세스 감사의 장단점은 구성 프로세스에서 확인할 수 있습니다. Windows 감사는 정책을 통해 설정할 수 있는 데 비해 액세스 감사는 Microsoft Exchange 정보 저장소의 진단 범주를 통해 제어됩니다.

중요

액세스 감사에서는 메시지 액세스만 감사하며 메시지 삭제는 감사하지 않습니다.

Exchange 감사 이벤트 로그

기록되는 감사 이벤트 양은 임의 시간에 사용자가 수행하는 감사 대상 유형 작업 수 및 서버 부하와 직접적으로 관련됩니다. 응용 프로그램 로그 역시 진단 및 문제 해결 데이터의 원본이므로, 액세스 감사에서는 응용 프로그램 로그에 이벤트를 기록하지 않습니다. Exchange 2007 SP2(서비스 팩 2)에서는 사서함 서버 역할을 서버에 설치하면 새 이벤트 로그가 만들어집니다. 이것이 Exchange 감사 이벤트 로그입니다. Exchange 감사 이벤트 로그의 기본 위치는 \Exchange Server\Logs\AuditLogs입니다. Windows Server 2008 기반 컴퓨터에서는 이 이벤트 로그가 Applications and Services Logs\Exchange Auditing에 있습니다. 이 로그 파일의 기본 파일 위치는 %PROGRAMFILES%\Exchange Server\Logging\Auditlogs입니다. Exchange 감사 로그의 기본 ACL(액세스 제어 목록)에서는 다음 사용 권한을 허용합니다.

  • Exchange 받는 사람 관리자: 읽기 및 지우기 권한

  • Exchange 조직 관리자: 읽기 및 지우기 권한

  • Exchange Server: 읽기 및 쓰기 권한

  • 로컬 서비스에 대한 모든 액세스

기본 ACL 목록을 변경하려면 레지스트리에서 CustomSD 값을 업데이트해야 합니다. Exchange 감사 이벤트 로그에 액세스할 그룹 또는 사용자를 포함하도록 CustomSD 값을 업데이트합니다. CustomSD 값은 다음 레지스트리 키 아래에 있습니다.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Exchange Auditing

참고

CustomSD 값에 저장되는 ACL은 SDDL 형식으로 저장됩니다. Windows 이벤트 로그에 대한 사용 권한을 변경하는 방법 및 SDDL 형식에 대한 자세한 내용은 Event Log(영문)를 참조하십시오.

사용자 또는 그룹 SID 값을 받으려면 Windows Sysinternals의 PsGetSid 도구를 사용합니다. 이 도구에 대한 자세한 내용은 PsGetSid v1.43(영문)을 참조하십시오.

또는 PowerShell을 사용하여 SID를 받을 수 있습니다. 예를 들어 사용자 SID를 받으려면 다음 명령을 사용합니다.

$objUser = New-Object System.Security.Principal.NTAccount("Exchange Organization Administrators")

$strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])

$strSID.Value

이벤트 로그 수준별 액세스 감사

다른 사용자 사서함에 대한 특정 사용자의 액세스를 나타내는 이벤트와 관련해, 다음 일반 지침에는 각 진단 로깅 수준에서 기록되는 이벤트가 나와 있습니다.

  • 로깅 수준 0에서는 아무런 내용도 기록되지 않습니다.

  • 로깅 수준 1에서는 작업을 수행하는 사용자가 관리 권한을 호출한 작업만 기록됩니다.

  • 로깅 수준 2 및 4에서는 다른 사서함에 대한 사서함 사용 가능 사용자의 액세스만 기록됩니다.

  • 로깅 수준 3 및 5에서는 모든 사서함에 대한 모든 사용자의 액세스가 기록됩니다.

공통 감사 이벤트 정보

사용자 로그온 기반 작업을 반영하는 감사 이벤트에는 공통 정보 집합이 표시됩니다. 확장 클라이언트 데이터는 프로그램에서 확장 클라이언트 데이터를 보낼 수 있는 경우에만 사용할 수 있습니다. Outlook 2003 이상 버전의 Outlook에서는 확장 클라이언트 데이터를 보냅니다.

폴더 액세스 감사

폴더 액세스 이벤트는 사서함의 폴더 열기를 나타내고, 여러 감사 수준에서 다양한 이벤트를 제공합니다. 따라서 관리자가 감사 요구 사항에 적합한 로깅 수준을 선택할 수 있습니다. 다음 목록에서는 각 로깅 수준에서 기록되는 이벤트에 대해 설명합니다.

  • 수준 0에서는 아무런 내용도 기록되지 않습니다. 즉, 폴더 액세스에 대한 응답으로 아무런 이벤트도 기록되지 않습니다.

  • 수준 1에서는 관리 권한을 사용한 액세스만 기록됩니다.

  • 로깅 수준 2 및 4에서는 사서함 사용 가능 사용자에 대한 다른 사서함 사용 가능 사용자의 액세스만 기록됩니다.

  • 로깅 수준 3 및 5에서는 폴더에 대한 모든 사용자의 액세스가 기록됩니다.

기본 이벤트 로깅 및 모든 이벤트 로깅

사서함 폴더 계층 구조는 비 IPM 하위 트리와 IPM 하위 트리로 구성됩니다. 비 IPM 하위 트리에는 검색 폴더와 같이 응용 프로그램에서 사용하는 폴더가 저장되고, IPM 하위 트리에는 받은 편지함 또는 보낸 편지함 폴더와 같이 사용자가 보고 사용하는 폴더가 저장됩니다. 기본 이벤트는 사용자에게 표시되는 폴더에 대한 일반적 액세스를 나타냅니다. 이러한 폴더를 보통 "메일 폴더"로 정의합니다. 폴더가 IPM 하위 트리의 하위 폴더인 경우 해당 폴더에 대한 액세스는 기본 수준으로 기록됩니다. 모든 이벤트 로깅에는 사서함 루트 폴더, 비 IPM 하위 트리 폴더 등 사용자에게 표시되지 않는 폴더가 포함됩니다. 받은 편지함 폴더, 보낸 편지함 폴더, 임시 보관함 폴더 등의 "메일 폴더"에 대한 액세스를 감사하려는 관리자는 더 높은 수준의 이벤트 로깅을 사용하도록 설정할 필요가 없습니다. 다음 표에서는 폴더 액세스 범주의 각 로깅 수준에서 기록되는 이벤트를 보여줍니다.

범주: 폴더 액세스

로깅 수준 관리자 권한 필요 작업 수행 사용자 사서함 결과

0

적용할 수 없음

적용할 수 없음

적용할 수 없음

없음

1

아니요

적용할 수 없음

적용할 수 없음

없음

1

적용할 수 없음

적용할 수 없음

기본 이벤트

2

적용할 수 없음

UserA

UserA

없음

2

적용할 수 없음

UserA

UserB

기본 이벤트

3

적용할 수 없음

UserA

UserA

기본 이벤트

3

적용할 수 없음

UserA

UserB

기본 이벤트

4

적용할 수 없음

UserA

UserA

없음

4

적용할 수 없음

UserA

UserB

모든 이벤트

5

적용할 수 없음

UserA

UserA

모든 이벤트

5

적용할 수 없음

UserA

UserB

모든 이벤트

폴더 액세스 감사를 사용하도록 설정하면 다음과 유사한 이벤트가 기록됩니다.

이벤트 ID: 10100

심각도: 정보

프로그램: AccessAuditing

%4 사용자가 사서함 '%3'의 %1 폴더를 열었습니다.

표시 이름: %2

액세스하는 사용자: %5

사서함: %6

관리 권한: %7

식별자: %8

클라이언트 정보(사용 가능한 경우):

컴퓨터 이름: %9

주소: %10

프로세스 이름: %11

프로세스 ID: %12

응용 프로그램 ID: %13

이 이벤트 메시지의 매개 변수는 다음 항목을 나타냅니다.

  • %1은(는) 폴더의 URL 이름을 나타내며, 폴더의 전체 경로가 표시됩니다.

  • %2은(는) 폴더의 표시 이름을 나타냅니다. 표시 이름과 폴더 경로를 함께 사용하면 이름이 같은 여러 폴더를 구분할 수 있습니다.

공통 감사 이벤트 정보:

  • %3은(는) 연 사서함의 legacyDN을 나타냅니다.

  • %4은(는) 정보 저장소에 대해 인증된 사용자의 이름을 나타냅니다.

  • %5은(는) 개체를 연 사용자의 legacyDN을 나타냅니다.

  • %6은(는) 사서함의 legacyDN을 나타냅니다.

  • %7은(는) 폴더를 여는 데 관리자 권한을 사용했는지 나타내는 플래그입니다.

  • %8은(는) 상대적으로 고유한 식별자로, 이 매개 변수를 사용해 짧은 기간 동안의 작업을 상관시킬 수 있습니다.

클라이언트 정보:

  • %9은(는) 컴퓨터 이름을 나타냅니다.

  • %10은(는) 클라이언트가 작성한 주소를 나타냅니다. 이 값은 서버에 연결하는 데 사용된 프로토콜에 따라 달라집니다. 로컬 연결(같은 컴퓨터로부터의 연결)에서는 컴퓨터 이름을 사용합니다. Exchange 이진 파일은 가능한 경우 IPv6 주소를 보내며, 그럴 수 없으면 IPv4 주소를 보냅니다. IP 주소를 보내는 경우 이 값은 클라이언트가 식별하는 IP 주소를 나타냅니다. 클라이언트가 NAT 게이트웨이 뒤에 있는 경우에는 IP 주소에서 고유한 주소를 제공하지 않을 수도 있습니다.

  • %11은(는) 프로세스 이름을 나타내며, 개체 액세스를 호출한 응용 프로그램 이진 파일입니다.

  • %12은(는) PID(프로세스 ID)를 나타내며, 특정 프로세스의 숫자 식별자입니다.

  • %13은(는) 응용 프로그램 ID를 나타냅니다. 이 항목은 Powershell.exe 인스턴스를 서로 구분할 수 있도록 클라이언트에서 설정하는 값이거나, 서버 액세스 작업 중에 프로세스의 추가 기능에 추가 기능 레이블을 지정할 수 있도록 하는 이벤트입니다.

예제 폴더 액세스 이벤트 로그 항목

로그 이름: Exchange 감사

원본: MSExchangeIS 감사

이벤트 ID: 10100

작업 범주: 사서함 액세스 감사

수준: 정보

키워드: 클래식

설명: CONTOSO\UserB 사용자가 사서함 'UserA'의 /Inbox 폴더를 열었습니다.

표시 이름: 받은 편지함

액세스하는 사용자: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB

관리 권한: false

식별자: 00000000318A00E0

클라이언트 정보(사용 가능한 경우)

컴퓨터 이름: <ClientName>

주소: <IP 주소>

프로세스 이름: OUTLOOK.EXE

프로세스 ID: 0

응용 프로그램 ID: 해당 없음

메시지 액세스 감사

메시지 액세스 이벤트는 Exchange 정보 저장소의 메시지 열기 작업을 나타냅니다. 메시지에서는 기본 이벤트가 지원되지 않습니다. 모든 메시지 액세스는 관리자가 설정하는 로깅 수준을 기반으로 감사됩니다. 다음 표에서는 메시지 액세스 범주의 각 로깅 수준에서 기록되는 이벤트를 보여줍니다.

범주: 메시지 액세스

로깅 수준 관리자 권한 필요 작업 수행 사용자 사서함 결과

0

적용할 수 없음

적용할 수 없음

적용할 수 없음

없음

1

아니요

적용할 수 없음

적용할 수 없음

없음

1

적용할 수 없음

적용할 수 없음

기본 이벤트

2

적용할 수 없음

적용할 수 없음

적용할 수 없음

적용할 수 없음

2

적용할 수 없음

적용할 수 없음

적용할 수 없음

적용할 수 없음

3

적용할 수 없음

적용할 수 없음

적용할 수 없음

적용할 수 없음

3

적용할 수 없음

적용할 수 없음

적용할 수 없음

적용할 수 없음

4

적용할 수 없음

UserA

UserA

없음

4

적용할 수 없음

UserA

UserB

모든 이벤트

5

적용할 수 없음

UserA

UserA

모든 이벤트

5

적용할 수 없음

UserA

UserB

모든 이벤트

메시지 액세스 감사를 사용하도록 설정하면 다음과 유사한 이벤트가 기록됩니다.

이벤트 ID: 10102

심각도: 정보

프로그램: AccessAuditing

%4 사용자가 사서함 %3의 %1 메시지를 열었습니다.

폴더: %2

액세스하는 사용자: %5

사서함: %6

관리 권한: %7

식별자: %8

클라이언트 정보(사용 가능한 경우):

컴퓨터 이름: %9

주소: %10

프로세스 이름: %11

프로세스 ID: %12

응용 프로그램 ID: %13

이 이벤트 메시지의 매개 변수는 다음 항목을 나타냅니다.

  • %1은(는) 열고 있는 메시지의 인터넷 메시지 ID를 나타냅니다.

  • %3은(는) 메시지를 저장하는 사서함을 나타냅니다.

  • %4은(는) 정보 저장소에 대해 인증된 사용자를 나타냅니다.

  • %5은(는) 메시지를 연 사용자의 legacyDN을 나타냅니다.

  • %6은(는) 사서함의 legacyDN을 나타냅니다.

  • %7은(는) 메시지를 여는 데 관리자 권한을 사용했는지 나타내는 플래그입니다.

  • %8은(는) 짧은 기간 동안의 작업을 상관시키는 데 사용할 수 있는 상대적으로 고유한 식별자입니다.

클라이언트 정보

  • %9은(는) 컴퓨터 이름을 나타냅니다.

  • %10은(는) 클라이언트가 작성한 주소를 나타냅니다. 이 값은 서버에 연결하는 데 사용된 프로토콜에 따라 달라집니다. 로컬 연결(같은 컴퓨터로부터의 연결)에서는 컴퓨터 이름을 사용합니다. Exchange 이진 파일은 가능한 경우 IPv6 주소를 보내며, 그럴 수 없으면 IPv4 주소를 보냅니다. IP 주소를 보내는 경우 이 값은 클라이언트가 식별하는 IP 주소를 나타냅니다. 클라이언트가 NAT 게이트웨이 뒤에 있는 경우에는 IP 주소에서 고유한 주소를 제공하지 않을 수도 있습니다.

  • %11은(는) 프로세스 이름을 나타내며, 개체 액세스를 호출한 응용 프로그램 이진 파일입니다.

  • %12은(는) PID(프로세스 ID)를 나타내며, 특정 프로세스의 숫자 식별자입니다.

  • %13은(는) 응용 프로그램 ID를 나타냅니다. 이 항목은 Powershell.exe 인스턴스를 서로 구분할 수 있도록 클라이언트에서 설정하는 값이거나, 서버 액세스 작업 중에 프로세스의 추가 기능에 추가 기능 레이블을 지정할 수 있도록 하는 이벤트입니다.

예제 메시지 액세스 이벤트 로그 항목

로그 이름: Exchange 감사

원본: MSExchangeIS 감사

날짜: <날짜>

이벤트 ID: 10102

작업 범주: 사서함 액세스 감사

수준: 정보

키워드: 클래식

설명: CONTOSO\UserB 사용자가 사서함 UserA의 <BA15978123F9C848B820A8C5C1DC29B5F06B6F@Server.Contoso.com> 메시지를 열었습니다.

폴더: /Inbox

액세스하는 사용자: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB

관리 권한: false

식별자: 00000000318A00E0

클라이언트 정보(사용 가능한 경우)

컴퓨터 이름: <ClientName>

주소: <IP 주소>

프로세스 이름: OUTLOOK.EXE

프로세스 ID: 0

응용 프로그램 ID: 해당 없음

확장 다른 사람 이름으로 보내기 감사

확장 다른 사람 이름으로 보내기 이벤트는 특정 사용자가 다른 사용자로 메시지를 보냈음을 나타냅니다. 이 이벤트는 기본 이벤트를 지원하지 않으며, 사용자가 다른 사용자로 메시지를 보낼 때만 적용됩니다. 로깅 수준 1에서는 사용자가 관리자 권한을 사용해 사서함을 연 다음 다른 사용자로 메시지를 보내는 경우에만 이벤트가 기록됩니다. 로깅 수준 5에서는 사용자가 다른 사용자로 메시지를 보내면 이벤트가 기록됩니다. 다음 표에서는 확장 다른 사람 이름으로 보내기 범주의 각 로깅 수준에서 기록되는 이벤트를 보여줍니다.

범주: 확장 다른 사람 이름으로 보내기

로깅 수준 관리자 권한 필요 작업 수행 사용자 사서함 결과

0

적용할 수 없음

적용할 수 없음

적용할 수 없음

없음

1

아니요

UserA

UserA

적용할 수 없음

1

UserA

UserB

모든 이벤트

2

적용할 수 없음

적용할 수 없음

적용할 수 없음

적용할 수 없음

2

적용할 수 없음

적용할 수 없음

적용할 수 없음

적용할 수 없음

3

적용할 수 없음

적용할 수 없음

적용할 수 없음

적용할 수 없음

3

적용할 수 없음

적용할 수 없음

적용할 수 없음

적용할 수 없음

4

적용할 수 없음

적용할 수 없음

적용할 수 없음

적용할 수 없음

4

적용할 수 없음

적용할 수 없음

적용할 수 없음

적용할 수 없음

5

적용할 수 없음

UserA

UserA

적용할 수 없음

5

적용할 수 없음

UserA

UserB

모든 이벤트

확장 다른 사람 이름으로 보내기 감사를 사용하도록 설정하면 다음과 유사한 이벤트가 기록됩니다.

이벤트 ID: 10106

심각도: 정보

프로그램: SendAs

%1이(가) %2(으)로 메시지를 보냈습니다.

메시지 ID: %3

계정 이름: %4

액세스하는 사용자: %5

사서함: %6

관리 권한: %7

식별자: %8

클라이언트 정보(사용 가능한 경우):

컴퓨터 이름: %9

주소: %10

프로세스 이름: %11

프로세스 ID: %12

응용 프로그램 ID: %13

이 이벤트 메시지의 매개 변수는 다음 항목을 나타냅니다.

  • %1은(는) 메시지를 보내는 사람의 legacyDN을 나타냅니다.

  • %2은(는) 메시지를 보낸 것으로 표시되는 사용자의 legacyDN을 나타냅니다.

  • %3은(는) 메시지의 인터넷 메시지 ID를 나타냅니다.

  • %4은(는) 정보 저장소에 대해 인증된 사용자를 나타냅니다.

  • %5은(는) 액세스하는 사용자의 legacyDN을 나타냅니다.

  • %6은(는) 사서함의 legacyDN을 나타냅니다.

  • %7은(는) 메시지를 보내는 데 관리 권한을 사용했는지 나타내는 플래그입니다.

  • %8은(는) 짧은 기간 동안의 이벤트를 상관시키는 데 사용할 수 있는 상대적으로 고유한 식별자입니다.

클라이언트 정보

  • %9은(는) 컴퓨터 이름을 나타냅니다.

  • %10은(는) 클라이언트가 작성한 주소를 나타냅니다. 이 값은 서버에 연결하는 데 사용된 프로토콜에 따라 달라집니다. 로컬 연결(같은 컴퓨터로부터의 연결)에는 컴퓨터 이름이 사용됩니다. Exchange 이진 파일은 가능한 경우 IPv6 주소를 보내며, 그럴 수 없으면 IPv4 주소를 보냅니다. IP 주소를 보내는 경우 이 값은 클라이언트가 식별하는 IP 주소를 나타냅니다. 클라이언트가 NAT 게이트웨이 뒤에 있는 경우에는 IP 주소에서 고유한 주소를 제공하지 않을 수도 있습니다.

  • %11은(는) 프로세스 이름을 나타내며, 개체 액세스를 호출한 응용 프로그램 이진 파일입니다.

  • %12은(는) PID(프로세스 ID)를 나타내며, 특정 프로세스의 숫자 식별자입니다.

  • %13은(는) 응용 프로그램 ID를 나타냅니다. 이 항목은 Powershell.exe 인스턴스를 서로 구분할 수 있도록 클라이언트에서 설정하는 값이거나, 서버 액세스 작업 중에 프로세스의 추가 기능에 추가 기능 레이블을 지정할 수 있도록 하는 이벤트입니다.

다른 사람 이름으로 보내기 권한을 부여하는 방법에 대한 자세한 내용은 사서함의 다른 사람 이름으로 보내기 권한 부여 방법을 참조하십시오.

예제 다른 사람 이름으로 보내기 이벤트 로그 항목

로그 이름: Exchange 감사

원본: MSExchangeIS 감사

날짜: <날짜>

이벤트 ID: 10106

작업 범주: 다른 사람 이름으로 보내기

수준: 정보

키워드: 클래식

설명: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB이(가) /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserA(으)로 메시지를 보냈습니다.

메시지 ID: <BA15978123F9C848B820A8C5C1DC29B5038E9D50@Server.Contoso.com>

사서함: UserB

계정 이름: CONTOSO\UserB

액세스하는 사용자: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB

사서함:<NULL>

관리 권한: false

식별자: 00000000317A7130

클라이언트 정보(사용 가능한 경우)

컴퓨터 이름: <ClientName>

주소: <IP 주소>

프로세스 이름: OUTLOOK.EXE

프로세스 ID: 0

응용 프로그램 ID: 해당 없음

확장 대신 보내기 감사

확장 대신 보내기 감사 이벤트는 사용자가 다른 사용자 대신 메시지를 보냈음을 나타냅니다. 이 이벤트는 기본 이벤트를 지원하지 않으며, 사용자가 다른 사용자 대신 메시지를 보낼 때만 적용됩니다. 수준 1에서는 사용자가 관리자 권한을 사용해 사서함을 연 다음 다른 사용자 대신 메시지를 보내는 경우에만 이벤트가 기록됩니다. 로깅 수준 5에서는 사용자가 다른 사용자 대신 메시지를 보내면 이벤트가 기록됩니다. 다음 표에서는 확장 대신 보내기 범주의 각 로깅 수준에서 기록되는 이벤트를 보여줍니다.

범주: 확장 대신 보내기

로깅 수준 관리자 권한 필요 작업 수행 사용자 사서함 결과

0

적용할 수 없음

적용할 수 없음

적용할 수 없음

없음

1

아니요

UserA

UserA

적용할 수 없음

1

UserA

UserB

모든 이벤트

2

적용할 수 없음

적용할 수 없음

적용할 수 없음

적용할 수 없음

2

적용할 수 없음

적용할 수 없음

적용할 수 없음

적용할 수 없음

3

적용할 수 없음

적용할 수 없음

적용할 수 없음

적용할 수 없음

3

적용할 수 없음

적용할 수 없음

적용할 수 없음

적용할 수 없음

4

적용할 수 없음

적용할 수 없음

적용할 수 없음

적용할 수 없음

4

적용할 수 없음

적용할 수 없음

적용할 수 없음

적용할 수 없음

5

적용할 수 없음

UserA

UserA

적용할 수 없음

5

적용할 수 없음

UserA

UserB

모든 이벤트

확장 대신 보내기 감사를 사용하도록 설정하면 다음과 유사한 이벤트가 기록됩니다.

이벤트 ID: 10104

심각도: 정보

프로그램: SendOnBehalfOf

%1이(가) %2 대신 메시지를 보냈습니다.

메시지 ID: %3

계정 이름: %4

액세스하는 사용자: %5

사서함: %6

관리 권한: %7

식별자: %8

클라이언트 정보(사용 가능한 경우):

컴퓨터 이름: %9

주소: %10

프로세스 이름: %11

프로세스 ID: %12

응용 프로그램 ID: %13

이 이벤트 메시지의 매개 변수는 다음 항목을 나타냅니다.

  • %1은(는) 메시지를 보내는 사람의 legacyDN을 나타냅니다.

  • %2은(는) 메시지를 보낸 것으로 표시되는 사용자의 legacyDN을 나타냅니다.

  • %3은(는) 메시지의 인터넷 메시지 ID를 나타냅니다.

  • %4은(는) 정보 저장소에 대해 인증된 사용자를 나타냅니다.

  • %5은(는) 액세스하는 사용자의 legacyDN을 나타냅니다.

  • %6은(는) 사서함의 legacyDN을 나타냅니다.

  • %7은(는) 메시지를 보내는 데 관리 권한을 사용했는지 나타내는 플래그입니다.

  • %8은(는) 짧은 기간 동안의 이벤트를 상관시키는 데 사용할 수 있는 상대적으로 고유한 식별자입니다.

클라이언트 정보

  • %9은(는) 컴퓨터 이름을 나타냅니다.

  • %10은(는) 클라이언트가 작성한 주소를 나타냅니다. 이 값은 서버에 연결하는 데 사용된 프로토콜에 따라 달라집니다. 로컬 연결(같은 컴퓨터로부터의 연결)에는 컴퓨터 이름이 사용됩니다. Exchange 이진 파일은 가능한 경우 IPv6 주소를 보내며, 그럴 수 없으면 IPv4 주소를 보냅니다. IP 주소를 보내는 경우 이 값은 클라이언트가 식별하는 IP 주소를 나타냅니다. 클라이언트가 NAT 게이트웨이 뒤에 있는 경우에는 IP 주소에서 고유한 주소를 제공하지 않을 수도 있습니다.

  • %11은(는) 프로세스 이름을 나타내며, 개체 액세스를 호출한 응용 프로그램 이진 파일입니다.

  • %12은(는) PID(프로세스 ID)를 나타내며, 특정 프로세스의 숫자 식별자입니다.

  • %13은(는) 응용 프로그램 ID를 나타냅니다. 이 항목은 Powershell.exe 인스턴스를 서로 구분할 수 있도록 클라이언트에서 설정하는 값이거나, 서버 액세스 작업 중에 프로세스의 추가 기능에 추가 기능 레이블을 지정할 수 있도록 하는 이벤트입니다.

예제 대신 보내기 이벤트 로그 항목

로그 이름: Exchange 감사

원본: MSExchangeIS 감사

날짜: <날짜>

이벤트 ID: 10104

작업 범주: 대신 보내기

수준: 정보

키워드: 클래식

설명: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB이(가) /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserA 대신 메시지를 보냈습니다.

메시지 ID: <BA15978123F9C848B820A8C5C1DC29B50406C46E@Server.Contoso.com>

사서함: UserB

계정 이름: CONTOSO\UserB

액세스하는 사용자: /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB

사서함:<NULL>

관리 권한: false

식별자: 0000000031718B30

클라이언트 정보(사용 가능한 경우)

컴퓨터 이름: <ClientName>

주소: <IP 주소>

프로세스 이름: OUTLOOK.EXE

프로세스 ID: 0

응용 프로그램 ID: 해당 없음

감사 무시 권한

응용 프로그램이 여러 사용자 사서함에 신뢰할 수 있는 서비스 계정으로 로그온하면 감사 부하가 높아집니다. 서비스 계정의 각 사서함 액세스 작업이 기록될 수 있기 때문입니다.

Exchange 2007 SP2에서는 감사 무시 권한이라는 새로운 확장 권한이 스키마에 추가되었습니다. 감사 무시 권한을 사용하면 권한이 부여된 사용자 계정에서 수행하는 작업을 기록하지 않을 수 있습니다. 따라서 감사하려는 사용자에게는 감사 무시 권한을 부여해서는 안 됩니다.

참고

Windows에서는 기본적으로 도메인 관리자 그룹에 모든 확장 권한을 부여합니다. 모든 사서함 액세스를 감사해야 하는 경우에는 도메인 관리자가 메일을 사용할 수 있도록 설정해서는 안 됩니다. 도메인 관리자의 감사를 허용하려면 Exchange 조직 수준에서 감사 무시 권한을 거부하면 됩니다. 그러면 메일 사용이 가능한 도메인 관리자 계정의 감사가 허용됩니다. 예를 들어 Domain Admins 그룹의 감사 무시 권한을 거부하려면 Exchange 관리 셸에서 다음 명령을 실행합니다.
Add-ADPermission -Identity "CN=Contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com" -User "Domain\Domain Admins" -AccessRights ExtendedRight -ExtendedRights Ms-Exch-Store-Bypass-Access-Auditing -Deny:$true

Add-ADPermission cmdlet를 사용하면 각 사서함 데이터베이스에 대해 감사를 무시할 수 있는 적절한 권한을 특정 서비스 계정에 부여할 수 있습니다. 예를 들어 Example\ServiceAccount액세스 감사 무시 권한을 부여하려면 Exchange 관리 셸에서 다음 명령을 실행합니다.

get-mailboxdatabase -Identity "Server01\StorageGroup01\MailboxDatabase01" | Add-ADPermission -User example\ServiceAccount -ExtendedRights ms-Exch-Store-Bypass-Access-Auditing -InheritanceType All

감사 방식 선택

Exchange에서 사서함 액세스를 감사하는 작업은 정보의 용도, 조직의 특정 감사 요구 사항, 사용 중인 응용 프로그램 및 관리자 신뢰 수준에 따라 달라지는 복잡한 프로세스입니다.

감사 요구 사항 수준이 가장 높은 조직에서는 Windows NT 보안 감사를 사용하는 것이 가장 좋습니다. 이 형식의 감사에서는 모든 사용자의 모든 개체 액세스를 기록하며 기록된 정보를 보안 로그에 저장합니다.

Windows 감사 보안이 필요하지 않은 조직에서는 Exchange 액세스 감사를 사용하는 것이 적절합니다. Exchange 액세스 감사는 다음을 감사하려는 조직에 적합합니다.

  • 관리자 권한을 사용하여 사서함을 여는 관리자만 감사

  • 사용자가 다른 사용자 사서함을 여는 작업만 감사

  • 액세스 대상 리소스가 IPM 하위 트리에 있는 경우만 감사

관리자 권한으로 관리자 액세스 감사

진단 로깅 수준 1에서 모든 범주는 작업을 수행하는 사용자가 관리 권한을 통해 사서함에 액세스하는 이벤트만 기록합니다. Exchange 액세스 감사를 사용하는 조직에서는 Exchange 관리자가 기본적으로 진단 로깅 수준을 수정하거나 Exchange 액세스 감사 이벤트 로그를 지울 수 있다는 점을 기억해야 합니다. 또한 Exchange 관리자는 감사 무시 권한을 부여할 수도 있습니다. Exchange 관리자만 감사하려는 조직에서는 사용 권한 분할 모델을 구현해 Exchange 관리자가 로깅 수준 또는 보안 설명자를 수정하거나 이벤트 로그를 지울 수 없도록 해야 합니다.

특정 사서함의 다른 사서함 액세스만 감사

로깅 수준 2 및 4에서 폴더 및 메시지 액세스 감사는 메일을 사용할 수 있는 특정 사용자가 사서함을 사용할 수 있는 다른 사용자의 폴더나 메시지를 열면 이벤트를 기록합니다. 이 로깅 수준에서는 모든 유형의 공유 사서함 액세스를 검색하지는 않습니다. 공유 사서함 또는 리소스 사서함은 사용하지 않도록 설정된 사용자 계정과 연결되며, 추가 사용자에게 사서함 액세스 권한이 부여됩니다. 추가 사용자가 사서함을 사용할 수 없으면 진단 수준 2 또는 4에서 공유 사서함 또는 리소스 사서함 액세스가 기록되지 않습니다.

기본 이벤트 감사와 모든 이벤트 감사 비교

진단 수준 2 및 3에서 폴더 액세스 감사는 기본 이벤트 또는 모든 이벤트를 기록합니다. 기본 이벤트에는 IPM 하위 트리의 하위 폴더나 비 IPM 하위 트리의 2순위 이상 하위 폴더(이러한 위치에서 데이터를 캐시하는 응용 프로그램의 경우)만 포함됩니다. 더 높은 진단 수준을 사용하도록 설정하면 더 많은 이벤트가 기록됩니다. 이러한 추가 로깅으로 인해 서버 부하가 높아질 수 있습니다. 또한 로깅 수준을 높이면 약속 있음/없음 캐시 조회 작업 등의 가양성 이벤트가 기록될 수 있습니다. 약속 있음/없음 캐시 조회 작업은 사서함 루트에 액세스하며, 악의적이지 않은 조회 작업입니다.

조직에서 감사해야 하는 이벤트(기본 이벤트/확장 이벤트)를 결정하려면 조직에서 배포한 응용 프로그램과 중요한 사용자 데이터가 저장되는 위치를 파악해야 합니다. 응용 프로그램에서 중요한 사용자 데이터를 비 IPM 하위 트리의 직계 하위 폴더에 저장하는 경우에는 모든 이벤트(진단 수준 4 또는 5) 로깅에서만 특정 폴더 액세스를 기록합니다.

액세스 로깅의 제한

확장 클라이언트 정보

확장 클라이언트 정보 블록을 보내지 않는 클라이언트 프로그램은 클라이언트 정보를 채우지 않는 감사 이벤트를 생성합니다. 이러한 현상은 Outlook 2003 이전의 Outlook 버전에서 나타납니다.

폴더 콘텐츠 테이블

메시지 액세스 감사에서 사서함에서 검색되는 모든 정보를 감지할 수는 없습니다. 폴더 콘텐츠 테이블(일반적으로 사용되는 메시지 속성의 요약 테이블)에 액세스할 때는 사용자가 메시지를 열 필요가 없기 때문입니다. 메시지 제목, 받는 사람 정보 및 다양한 기본 메시지 속성은 메시지 폴더 테이블에 포함되어 있습니다. 이러한 정보는 메시지를 열지 않아도 읽을 수 있기 때문에 메시지 액세스 이벤트를 생성하지 않습니다.

보안 고려 사항

조직에서 감사 요구 사항으로 액세스 감사를 선택하는 경우에는 다양한 보안 시나리오를 고려하여 감사 로그 액세스를 완벽하게 보안하고 로그 콘텐츠를 보호하는 데 필요한 최종 비용을 평가해야 합니다.

감사 무시

감사 무시 확장 권한을 부여받은 사용자는 감사되지 않습니다. Active Directory ACL을 모니터링하여 보안 설명자 작성 권한이 있는 사용자가 자신에게 감사 무시 권한을 부여하지 않는지 확인하는 것이 좋습니다.

도메인 관리자

Windows에서는 도메인 관리자에게 모든 확장 권한이 부여됩니다. 사서함 액세스를 감사해야 하는 경우에는 도메인 관리자 계정이 메일을 사용할 수 있도록 설정해서는 안 됩니다.

진단 로깅 변경 내용

진단 로깅 수준은 Exchange 감사 이벤트 로그에 기록되는 이벤트를 제어하므로, 특정 범주의 진단 로깅 수준을 변경하면 예기치 않은 결과가 발생할 수 있습니다. 예를 들어 기록될 것으로 예상했던 특정 이벤트가 더 이상 기록되지 않을 수 있습니다. 또한 Store.exe 프로세스는 로깅 수준을 변경한 사용자, 심지어는 로깅 수준이 이전 세션과 다르게 변경되었는지 여부도 식별할 수 없기 때문에 감사 구성의 변경 내용을 식별할 수 없습니다.

로컬 관리자

Exchange 감사 로그에는 감사된 이벤트 레코드가 포함되며, 이벤트 뷰어에는 일반 사용자가 이벤트 로그를 지우지 못하도록 하는 ACL이 있습니다. 로컬 관리자가 해당 레지스트리 키에 대한 소유권을 얻어 CustomSD 값을 다시 설정하고 서버를 다시 시작하면 Exchange 감사 로그를 지울 수 있게 됩니다.

성능 고려 사항

서버 구성 및 사용자 작업에 따라 Exchange 감사 이벤트 로그의 트래픽이 높을 수 있습니다. 따라서 공간이 충분하며 빠른 쓰기 작업을 지원할 수 있는 전용 하드 디스크 드라이브에 Exchange 감사 이벤트 로그를 배치하는 것이 좋습니다.

Exchange 감사 이벤트 로그를 구성하는 방법은 다음 항목을 참조하십시오.

자세한 내용

Exchange에서 진단 로깅 수준을 수정하는 방법에 대한 자세한 내용은 Exchange 프로세스의 로깅 수준을 변경하는 방법을 참조하십시오.