규정 준수 보고: 클라이언트 클라우드 액세스 제어의 첫 번째 단계

아티클
08/24/2016

NAP 및 Ipsec을 사용하여 DirectAccess를 통한 클라이언트 액세스를 제어함으로써 감사 및 규정 준수 보고 기능을 개선하십시오.

Dan Griffin 및 Lee Walker

엔터프라이즈를 클라우드로 확장하기 위한 첫 번째 단계는 안전한 액세스를 확립하는 것입니다. 규정 준수, 보고 및 원격 연결에 대한 정책을 설정하면 클라우드 내에서 원활하고 안전하게 팀 작업을 수행할 수 있게 됩니다. DirectAccess와 같은 IPsec 연결 기술과 NAP(네트워크 액세스 보호)을 함께 사용하면 감사 및 규정 준수 보고 기능을 개선할 수 있습니다.

새로운 DirectAccess 또는 IPsec 배포를 위한 감사 및 보고 솔루션을 만들 때는 필요한 데이터를 식별하고 수집하기가 어려울 수 있습니다. 여기에서는 가상의 회사가 DirectAccess 및 NAP 솔루션을 사용해서 보고 데이터를 제공함으로써 누가, 언제 연결했는지, 그리고 클라이언트 컴퓨터가 규정을 준수했는지 확인하는 방법을 살펴보겠습니다.

규정 준수 문제

이동 업무가 증가함에 따라 DirectAccess와 같은 유연한 원격 액세스 기술을 도입하는 조직이 많아지고 있습니다. DirectAccess를 사용하면 승인된 컴퓨터가 인터넷에 연결될 때마다 사용자는 자동으로 원격 네트워크에 연결됩니다. 원격 클라이언트는 종종 최신 보안 패치가 적용되지 않아 맬웨어에 감염되었을 가능성이 있으므로 많은 조직에서는 NAP과 IPsec도 함께 배포하여 정상적인 클라이언트만 보안 리소스에 액세스할 수 있도록 합니다.

금융 서비스, 보건, 정부 기관 등의 업계에서는 정상적이고 승인된 클라이언트만 클라우드 기반 또는 현장 네트워크 리소스에 연결하도록 하는 것이 데이터 무결성을 위해 필수적인, 중요한 일입니다. 이러한 업계에서는 내부 규정 준수 정책과 연방법에 따라 승인되지 않은 주체(맬웨어 및 알 수 없는 타사 응용 프로그램 포함)에 의해 은행 계좌 번호, 이름 및 건강 기록과 같은 PII(개인 식별 정보)가 액세스되지 않도록 해야 하는 경우가 많습니다.

사용자들은 작업 리소스에 대한 더 쉬운 원격 액세스 방법을 원하므로 이러한 업계의 IT 관리자는 정상적인 클라이언트만 회사 네트워크에 액세스하도록 해야 합니다. 그러나 NAP 및 DirectAccess 로그를 통해 의미 있는 보고서를 작성하기란 어려운 일입니다.

해결 방법은 원활한 원격 클라이언트 액세스를 위해 DirectAccess 인프라를 설정하고, NAP 및 IPsec으로 인트라넷 리소스를 보호하고, 보고를 통해 정책을 모니터링하는 것입니다. TechNet에는 DirectAccess에서 NAP을 구현하는 방법에 대해서는 여러 유용한 정보가 있지만 클라이언트 상태를 효과적으로 로깅 및 보고하는 데 대한 지침은 거의 없습니다. 여기서는 가상의 회사(Woodgrove National Bank)를 살펴보면서 컨설턴트가 간단한 코드와 SQL 쿼리를 사용하여 지정된 기간 동안 연결된 클라이언트에 대한 세부 정보와 이러한 클라이언트가 NAP을 준수하는지 여부에 대한 정보를 제공하는, 사용자가 읽을 수 있는 보고서를 작성하는 방법을 알아보겠습니다.

DirectAccess 위에 NAP 설정

DirectAccess에는 연결되는 클라이언트가 호환되는 Windows 버전(Windows 7 Ultimate 또는 Windows 7 Enterprise)을 실행해야 한다는 요구 사항이 있습니다. 이러한 클라이언트는 Windows Server 2008 R2를 실행하는 DirectAccess 서버에 연결됩니다. DirectAccess 배포에는 하나 이상의 DirectAccess 서버가 포함될 수 있습니다. 사용량이 많은 네트워크에서는 부하 분산을 위해 최소 두 대 이상의 서버를 사용하는 것이 좋습니다. 또한 배포에는 네트워크 위치 서버와(클라이언트가 인터넷에 연결되었는지, 아니면 인트라넷에 연결되었는지 확인하기 위한 용도) 하나 이상의 CRL(인증 해지 목록) 배포 지점(더 이상 액세스를 허용하면 안 되는 클라이언트를 추적하는 데 사용)이 포함되어야 합니다. DirectAccess 배포를 설계하는 방법은 TechNet의 DirectAccess 디자인 가이드를 참조하십시오.

DirectAccess 위에 NAP을 추가할 경우 NAP을 위한 IPsec 시행 방법을 구현해야 합니다. IPsec을 사용할 경우 NAP 준수 클라이언트에 상태 인증서가 부여됩니다. NAP을 준수하지 않는 컴퓨터는 준수하는 컴퓨터와 통신할 수 없습니다. NAP을 설계 및 배포하는 방법은 TechNet의 네트워크 액세스 보호를 적용한 DirectAccess 계획을 참조하십시오. IPsec을 시행 방법으로 하여 NAP을 설계하는 방법은 TechNet의 IPsec 시행 설계를 참조하십시오.

DirectAccess 및 IPsec 연결 정책과 연계하여 NAP IPsec 시행 시나리오가 작동하는 방법은 흥미롭습니다. 첫째, DirectAccess는 인증 및 기밀성을 위해 IPsec을 사용하므로 DirectAccess 배포의 NAP 시행 시나리오는 IPsec이어야 합니다. 둘째, IPsec의 AuthIP 구성 요소를 사용하면 정책에서 두 개의 인증 요구 사항을 별도로 구성할 수 있습니다(연결이 성공하려면 두 가지 요구 사항을 모두 충족해야 함). 일반적으로 두 가지 AuthIP 인증 옵션이 모두 구성되는 경우 첫 번째는 컴퓨터 자격 증명이고 두 번째는 사용자 자격 증명입니다. 그러나 두 개의 컴퓨터 자격 증명을 구성하는 것도 기술적으로 가능합니다.

AuthIP 정책에서 NAP는 어떤 역할을 할까요? NAP/IPsec 시행 시나리오에서는 정상적인 컴퓨터에게 정상 OID(개체 ID)가 포함된 인증서를 부여합니다. AuthIP 정책 엔진에는 정상 OID를 요청하기 위한 옵션이 포함되어 있습니다. 따라서 정상적인 컴퓨터만 첫 번째 AuthIP 인증 요구 사항을 충족하고 DirectAccess 서버에 IPsec 연결을 설정할 수 있습니다.

마지막으로, 사용자 자격 증명은 두 번째 AuthIP 인증 옵션을 위해 필요합니다. 기술적인 측면에서 사용자 자격 증명은 DirectAccess에서 선택 사항입니다. 즉, 클라이언트는 컴퓨터 인증서만으로도 DirectAccess 끝점에 인증할 수 있습니다. 보안에 민감한 IT 담당자라면 강력한 인증 없이 전체 원격 네트워크 액세스 권한을 부여하기를 꺼릴 것입니다. 따라서 최소한 AuthIP 정책은 두 번째 Kerberos 인증을 요구하도록 구성되어야 합니다. Woodgrove National Bank 시나리오와 같이 사용자 자격 증명에 대한 인증서를 요구하는 것이 좋습니다. 이렇게 하면 원격 정적 암호 공격의 위험이 완화되기 때문입니다.

이 시나리오에서 Woodgrove National Bank의 네트워크 보안 및 규정 준수 부서는 지정된 기간 동안 누가 회사 네트워크에 연결했는지, 그리고 이러한 클라이언트가 NAP을 준수했는지 여부에 대한 보고서를 요청했습니다. 이 그룹에서는 해당 기간 동안 고객 데이터가 손상되었을 수 있다고 생각합니다. 우리는 은행 컨설턴트로서 DirectAccess 및 NAP에 대한 사후 보고를 설정한 다음 이 정보를 사용자가 읽을 수 있는 보고서로 가져오는 방법을 결정해야 합니다.

적절한 정책 구성

이 가상 시나리오에서 Woodgrove National Bank는 IPsec 정책에서 NAP 시스템 상태 OID와 클라이언트 인증 OID가 포함된 클라이언트 인증서를 요구하도록 DirectAccess를 구성했습니다. Woodgrove는 NAP을 단순한 보고 모드가 아닌 시행 모드로 사용 중인데, 이는 정상적인 상태가 아닌 클라이언트는 정상적인 클라이언트와의 통신이 차단됨을 의미합니다.

마지막으로 Woodgrove는 두 개의 인증서 기반 자격 증명(하나는 클라이언트 컴퓨터, 하나는 사용자의 자격 증명)을 사용하도록 DirectAccess IPsec 정책을 구성했습니다. 앞에서 언급되었듯이 Woodgrove는 PKI 투자 활용도를 높이기 위해 원격 액세스에 대한 정적 암호를 제거하고 인증서 자동 등록을 이용하도록 이중 인증서 구성을 선택했습니다.

이 기사의 나머지 부분에서는 여러분에게 DirectAccess, NAP 및 IPsec 시행 모드의 작동 방법에 대한 실무 지식이 있다고 가정하겠습니다. 이러한 기술에 대한 자세한 내용은 다음 리소스를 참조하십시오.

다음 보고 솔루션은 DirectAccess 서버의 IPsec 기본 제공 감사 기능과 NPS(네트워크 정책 서버)의 HRA(상태 등록 기관) 기능에 있는 감사 기능을 사용합니다. 이러한 감사 기능들은 보안 이벤트 로그에 이벤트를 생성하며, 이를 우리가 추출해서 보고하게 됩니다. 이 접근 방법을 개발하는 과정에서 HRA 이벤트는 기본적으로 생성되는 반면 IPsec 이벤트는 명시적으로 설정해야 한다는 것을 발견했습니다. 명령 프롬프트 창에서 다음 명령을 사용하여 IPsec 이벤트를 설정할 수 있습니다.

auditpol.exe /set /category:"Logon/Logoff" /subcategory:"IPsec Main Mode" /success:enable /failure:enable

auditpol.exe /set /category:"Logon/Logoff" /subcategory:"IPsec Quick Mode" /success:enable /failure:enable

auditpol.exe /set /category:"Logon/Logoff" /subcategory:"IPsec Extended Mode" /success:enable /failure:enable

DirectAccess 상태 보고

Woodgrove National Bank에서 NAP 및 DirectAccess 이벤트 작업을 시작하기 위해 Microsoft에서 Log Parser 2.2를 다운로드하여 설치했습니다. Log Parser는 이렇게 새 이벤트 소스를 탐색하고 적절한 스키마를 개발해야 하는 프로젝트를 위한 필수 도구입니다. 간단히 말해 Log Parser는 Windows 이벤트 로그(.evtx), CSV 및 SQL을 포함한 다양한 데이터 형식을 가져오고 내보낼 수 있습니다.

다음 단계는 관심 대상 이벤트를 캡처하는 것입니다. 여기에는 다음이 포함됩니다.

DirectAccess 서버 보안 로그의 IPsec 보안 연결 관련 이벤트
HRA 서버 보안 및 시스템 로그의 상태 등록 기관 관련 이벤트(이 항목은 NAP을 사용하는 경우에만 적용됨)

이러한 이벤트를 수집하기 위한 이상적인 방법은 자동, 그리고 중앙 집중식이라는 두 가지 요건을 충족하는 방법입니다. 선택 가능한 옵션 중 하나는 Windows 이벤트 전달 기능입니다. 대규모 프로덕션 배포에서는 Microsoft System Center가 더 일반적일 것입니다. 우리는 프로덕션 서버에 대한 새로운 종속성을 발생시킬 생각이 없었으므로 이벤트 수집을 위한 간단한 스크립트를 사용했습니다.

이 접근 방법에는 두 가지 과제가 있습니다. 첫째, 목표가 여러 데이터 소스를 상호 연계하는 것이므로 모든 소스의 데이터를 대략적으로, 동시에 수집하는 것이 중요합니다. 둘째, 단순히 로그의 스냅숏을 만드는 것이고, 트래픽이 많은 이벤트 로그는 빠르게 롤오버되므로 특히 스냅숏 기간의 경계 근처에서 일부 연관된 이벤트의 손실이 불가피합니다. 이로 인해 실험이 무효화되지는 않지만 쿼리를 튜닝하기가 더 어렵게 됩니다.

각 IPsec 주 모드 보안 연결(DirectAccess 서버 중 하나에서)에 대해 NAP 상태 트래픽(HRA 서버 중 하나에서)이 표시되도록 해야 합니다. NAP 보고 모드에서는 클라이언트 컴퓨터가 규정을 준수했을 수도 있고 그렇지 않을 수도 있습니다. NAP 시행 모드에서는 클라이언트 컴퓨터가 규정을 준수했을 것입니다. 그렇지 않다면 어떻게 DirectAccess 서버로 인증하고 SA(보안 연결)를 설정하기 위한 유효한 인증서를 가질 수 있을까요? 오후 3시에 모든 DirectAccess 및 HRA 서버에 대해 동시에 한 번의 로그 캡처를 수행한다고 가정해 보겠습니다. MM SA(주 모드 보안 연결) 이벤트는 볼 수 있겠지만 상태 이벤트는 볼 수 없을 가능성이 있습니다.

더 가능성이 높은 것은 IPsec QM SA(빠른 모드 보안 연결) 및 IPsec EM SA(확장 모드 보안 연결) 이벤트는 볼 수 있지만 MM SA 또는 상태 이벤트는 볼 수 없는 경우입니다. 전자는 후자보다 한 시간 이상 뒤에 발생할 수 있습니다. 또한 개별적인 서버의 로그는 거의 확실히 서로 다른 빈도로 롤오버되므로 DirectAccess 서버에는 오후 2시의 이벤트가 있지만 HRA에는 가장 빠른 시간이 오후 2시 30분의 이벤트인 경우도 있을 수 있습니다. 이러한 이유로 프로덕션 환경에서는 중앙 집중식 이벤트 수집을 사용하는 것이 중요하다는 것을 다시 한 번 말씀드립니다.

데이터 생성

데이터를 생성하기 위해 DirectAccess 서버와 HRA 서버에서 스크립트를 실행했습니다. 또한 작업 스케줄러를 사용하여 스크립트가 자동으로 실행되도록 구성했습니다. DirectAccess 서버와 모든 HRA에서 동시에 한 번 실행되도록 스크립트를 구성했습니다.

DirectAccess 서버에서 데이터 수집

다음 스크립트를 사용하여 DirectAccess 서버의 이벤트를 캡처했습니다(그림 1 참조).

set MPATH=c:\temp\Logs

%MPATH%\LogParser.exe "SELECT * INTO %MPATH%\DA_Security_Events_%COMPUTERNAME%.csv FROM Security WHERE EventCategory=12549 OR EventCategory=12547 OR EventCategory=12550" -o:CSV

참고: 이 스크립트는 LogParser.exe(및 LogParser.exe의 종속 항목인 LogParser.dll)의 로컬 복사본을 사용합니다. 이 참조는 서버 간에 손쉽게 스크립트를 복사하기 위한 목적으로 사용되었습니다.

그림 1 작업 스케줄러를 통해 자동으로 실행되는 스크립트를 사용하여 DirectAccess 서버에서 캡처된 이벤트의 세부 정보

이벤트	설명
12547	IPsec 주 모드 보안 연결 정보
12549	IPsec 빠른 모드 보안 연결 정보
12550	IPsec 확장 모드 보안 연결 정보

HRA 서버에서 데이터 수집

HRA 서버의 이벤트를 캡처하기 위해 다음 스크립트를 사용했습니다.

set MPATH=c:\temp\Logs

%MPATH%\LogParser.exe "SELECT * INTO %MPATH%\HRA_Security_Events_%COMPUTERNAME%.csv FROM Security WHERE EventCategory=12552" -o:CSV

%MPATH%\LogParser.exe "SELECT * INTO %MPATH%\HRA_System_Events_%COMPUTERNAME%.csv FROM System WHERE SourceName='HRA'" -o:CSV

참고: HRA 스크립트에서 이벤트 범주 12552는 네트워크 정책 서버 서비스에 매핑됩니다.

데이터 가져오기

스크립트가 실행된 후 출력 CSV 파일을 SQL Server 2008을 실행하는 별도의 컴퓨터로 수집했습니다. CSV 데이터를 SQL로 가져오기 위해 다음 스크립트를 사용했습니다.

LogParser.exe "SELECT * INTO DaSasTable FROM DA_*.csv" -i:CSV -o:SQL -server:dev1 -database:NapDa -createTable:ON -maxStrFieldLen:1023
LogParser.exe "SELECT * INTO HraSecurityEventsTable  FROM HRA_Security_*.csv" -i:CSV -o:SQL -server:dev1 -database:NapDa -createTable:ON -maxStrFieldLen:1023
LogParser.exe "SELECT * INTO HraSystemEventsTable  FROM HRA_System_*.csv" -i:CSV -o:SQL -server:dev1 -database:NapDa -createTable:ON -maxStrFieldLen:1023

참고:

SQL 호스트 컴퓨터의 이름은 dev1입니다. 데이터베이스 이름은 NapDa이며 이 데이터베이스는 SQL Management Studio에서 기본값을 사용하여 만들었습니다.
세 개의 테이블(DaSasTable, HraSecurityEventsTable 및 HraSystemEventsTable)은 아직 존재하지 않습니다. -createTable:ONLog Parser 명령줄 옵션은 Log Parser에서 입력 데이터(여기서는 이벤트 로그 CSV 파일)를 기반으로 적절한 스키마를 사용하여 자동으로 이러한 테이블을 만들도록 지정합니다.
-maxStrFieldLen:1023setting은 이 시나리오에서 중요합니다. 이 설정이 없으면 Log Parser에서 다양한 이벤트 로그 문자열 필드에 대해 기본 varchar 필드 길이인 255를 사용할 것입니다. 그러나 이벤트 로그 CSV 형식에는 이것보다 긴 일부 데이터 문자열이 있으며(특히 Strings 필드. 그림 2 참조) 이러한 문자열이 잘리지 않도록 하는 것이 중요합니다. 경험적으로 보면 기본 길이인 1023 정도면 충분합니다.

그림 2는 Log Parser CSV 이벤트 로그 가져오기의 결과 스키마를 보여 줍니다.

그림 2는 Log Parser CSV 이벤트 로그 가져오기의 결과 스키마를 보여 줍니다.

그림 2 Log Parser CSV 이벤트 로그 가져오기의 스키마

데이터 준비

DirectAccess 상태 보고서를 만들 때 필요한 데이터를 추출하는 과정의 가장 큰 과제는 이벤트 로그 CSV 형식이 데이터 문자열을 기반으로 한다는 점입니다. GUI 관점에서 데이터는 각 데이터 필드의 의미를 설명하는 정적 문자열로 인터리빙됩니다. 데이터 문자열에는 DirectAccess 상태 보고서와 관련된 모든 항목(사용자 이름, 컴퓨터 이름, 정책 그룹 이름, IP 주소 등)이 포함됩니다.

이 데이터 문자열들은 하나의 CSV 필드로, 최종적으로 하나의 SQL 열(역시 문자열)로 연결됩니다. 각 문자열은 “|” 문자로 다음 문자열과 구분됩니다. 한 가지 방법은 데이터를 SQL로 가져오기 전이나 가져온 직후에 문자열을 토큰화하는 것입니다. 그러나 이 방법 대신 우리는 문자열을 SQL로 가져온 다음 구문 분석하고, 필요한 몇 가지 데이터 항목을 추출하여 이 항목으로 별도의 SQL 테이블을 채우는 방법을 사용했습니다.

T-SQL을 사용한 문자열 패턴 대조를 통해 이 작업을 수행하기는 어렵습니다. 그 대안으로 우리는 지난 MSDN Magazine 기사인 정규식을 활용한 손쉬운 패턴 검색 및 데이터 추출에 설명된 방법을 사용했는데, 특히 정규식 기반 패턴 검색을 위해 C#을 사용하여 SQL용 사용자 정의 함수를 구현했습니다.

Visual Studio 2008을 사용하여 이 기사의 단계를 거의 그대로 따랐으며, Visual Studio에서의 처음 SQL 및 CLR 통합에 대한 추가 설명서도 참조했습니다. 또한 정규식(RegEx)은 기본적으로 복잡하기 때문에 이 정규식 기술에 대한 설명서도 도움이 되었습니다(특히 MSDN Magazine 기사의 샘플 코드에 사용된 방법인 그룹화에 대한 섹션).

다음 코드 샘플은 SELECT 문에 RegEx 기능을 제공하는 SQL 사용자 정의 함수에 대한 소스 코드를 보여 줍니다. 함수의 이름은 MSDN Magazine 기사와 마찬가지로 RegexGroup입니다. 함수 본문의 처음 두 줄을 수정하여 NULL 입력 값을 확인할 수 있도록 했습니다. 이 두 줄을 추가하기 전에 여러 SQL 도우미 테이블 열(여기에 설명됨)의 NULL 값으로 인해 많은 예외가 발생했습니다.

usingSystem;

usingSystem.Data;

usingSystem.Data.SqlClient;

usingSystem.Data.SqlTypes;

usingMicrosoft.SqlServer.Server;

usingSystem.Text.RegularExpressions;

publicpartialclassUserDefinedFunctions

{

    [Microsoft.SqlServer.Server.SqlFunction]

publicstaticSqlChars RegexGroup(

SqlChars input, SqlString pattern, SqlString name)

{

if (true == input.IsNull)

returnSqlChars.Null;

Regex regex = newRegex(pattern.Value, Options);

Match match = regex.Match(newstring(input.Value));

returnmatch.Success ?

newSqlChars(match.Groups[name.Value].Value) : SqlChars.Null;

}

};

다음 SQL 명령은 RegEx를 사용하여 초기 데이터 집합에서 추출한 문자열로 구성된 두 개의 도우미 테이블을 만들고 채웁니다.

/* Create the User-Computer-Address mapping helper table */
/* This step should only be performed once per data set */
CREATE TABLE UserComputerAndAddr
(
[RowN] int null,
[UserName] varchar(1023) null,
[ComputerName] varchar(1023) null,
[Address] varchar(1023) null
)

/* Populate the User-Computer-Address table */
/* This step should only be performed once per data set */
INSERT INTO UserComputerAndAddr(RowN, UserName, ComputerName, Address)
SELECT RowNumber,
    dbo.RegexGroup([Strings],N'(?<un>[0-9a-zA-Z]+)@redmond.corp.microsoft.com',N'un'),
    dbo.RegexGroup([Strings],N'(?<machine>[0-9a-zA-Z\-]+)(?<!CO1RED-TPM-01)\$@redmond.corp.microsoft.com',N'machine'),
    dbo.RegexGroup([Strings],N'(?<ipv6addr>[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4})',N'ipv6addr')
FROM [NapDa].[dbo].[DaSasTable]

/* Create the Computer-Health mapping helper table */
/* This step should only be performed once per data set */
CREATE TABLE ComputerHealth
(
[RowN] int null,
[TimeGenerated] datetime null,
[EventType] int null,
[ComputerName] varchar(1023) null
)

/* Populate the Computer-Health mapping table */
/* This step should only be performed once per data set */
INSERT INTO ComputerHealth(RowN, TimeGenerated, EventType, ComputerName)
SELECT RowNumber,
    TimeGenerated,
    EventType,
    dbo.RegexGroup([Strings],N'REDMOND\\(?<machine>[0-9a-zA-Z\-]+)\$',N'machine')
FROM [NapDa].[dbo].[HraSystemEventsTable]

첫 SELECT 문, 그리고 이 문에서 앞서 설명한 기술을 사용하여 설치된 RegexGroup 함수를 사용하는 것을 살펴보면 문자열 패턴의 감을 잡을 수 있습니다. 그림 3은 정의한 세 개의 RegEx 패턴을 보여 줍니다.

그림 3 SQL 명령을 사용하여 정의한 세 개의 RegEx 패턴

정규식 패턴	참고
사용자 이름	예: ichiro@redmond.corp.microsoft.com
컴퓨터 이름	예: dan-dev-1@redmond.corp.microsoft.com 이 패턴에서 DirectAccess 서버 자체에 대한 대조는 명시적으로 제외합니다.
IPv6 주소	예: 2001:0:4137:1f6b:8c8:2f30:e7ed:73a8 · 이 패턴에서 유효한 모든 IPv6 주소가 대조되지는 않습니다. 다른 컨텍스트에서 사용하려면 이 패턴을 강화해야 합니다. · Strings 열에는 다른 포함된 IPv6 주소 필드도 있지만 이 패턴과 일치하는 항목은 클라이언트 주소밖에 없습니다. 쿼리에 예상하지 못한 주소가 있는 경우 이 패턴을 다시 검토해야 합니다.

이러한 정규식들은 DaSasTable의 각 행에 있는 사용자, 컴퓨터 및 주소 정보로 구성된 테이블을 만드는 데 도움이 됩니다(즉, DirectAccess 컴퓨터에서 내보낸 IPsec SA 이벤트).

UserComputerAndAddr 테이블이 만들어져 채워지고 나면 HraSystemEventsTable 테이블의 각 행에 대해 컴퓨터 이름을 이벤트 유형에 매핑하는 두 번째 테이블이 만들어집니다. 컴퓨터 이름 패턴을 살펴보면 이 로그의 컴퓨터 이름 형식이 DirectAccess 로그와 다른 것을 알 수 있습니다. 여기서는 경우 REDMOND\dan-dev-1과 같은 문자열을 찾습니다. 그림 4는 EventType 필드에 있을 수 있는 다양한 이벤트를 보여 줍니다.

그림 4 EventType 필드에 있을 수 있는 이벤트 유형

이벤트 유형	설명
0	성공. 컴퓨터가 규정을 준수하는 NAP 상태 문을 제출했습니다.
1	실패. 컴퓨터가 NAP 정책을 준수하지 않았습니다.

이 배포에 대한 상태 보고서에서는 이벤트 유형 0만 표시될 것입니다. NAP이 시행 모드로 사용 중이기 때문입니다. 아래에서 볼 수 있듯이 성공적인 IPsec 보안 연결도 필터링합니다. 정책을 준수하지 않은 클라이언트는 유효한 IPsec 인증서를 얻어 SA를 설정하지 못했을 것입니다. 반면 조직에서 보고 모드로 NAP을 배포했다면 정책을 준수하지 않은 일부 컴퓨터가 연결되었을 수 있습니다. 네트워크에 연결된 컴퓨터의 정책 준수/비준수 비율은 중요한 보고 통계 항목입니다.

참고: RegEx 결과에 테이블을 사용할 경우 영구 SQL 테이블을 사용하는 것이 좋습니다. 임시 테이블을 사용할 경우(다음 단계의 데모에서 임시 테이블을 사용함) RegEx 쿼리 속도가 느려집니다.

보고서 작성

정규식 구문 분석이 완료되고 도우미 테이블이 만들어졌으므로 이제 상태 보고서 작성 자체에 집중할 수 있습니다. 데이터가 준비되었다면 보고서 쿼리를 작성하는 일은 상대적으로 쉽습니다.

이 샘플 보고서의 목적은 2010년 5월 5일 오후 3시에서 4시 사이에 DirectAccess 연결을 설정한 모든 사용자를 나열하는 것입니다. 보고서에는 사용자 이름과 함께 컴퓨터 이름과 상태도 나열됩니다.

이러한 사용자를 식별하기 위해 먼저 해당 기간 내의 성공적인(이벤트 유형 8) QM SA(이벤트 범주 12549)를 쿼리합니다. IPsec이 두 번째 요소 인증(사용자의 자격 증명)을 요구하도록 구성되었으므로 QM SA 이벤트는 이 시나리오에서 유용합니다. 이 보고 방법을 사용하기로 한 이유는 QM SA의 수명이 비교적 짧고(여기서 수명은 1시간, 비활성 시간 제한은 5분) 따라서 액세스 감사에 유용하기 때문입니다. 반면 MM SA는 컴퓨터 자격 증명만 사용하고 기본적으로 8시간 동안 유지됩니다(DirectAccess 배포에서 감사가 중요한 요소일 경우 MM의 수명을 줄이는 것이 좋음).

QM 이벤트에는 사용자 이름이나 컴퓨터 이름이 포함되지 않고 IP 주소만 포함됩니다. IP 주소를 컴퓨터 이름 및 사용자 이름과 매핑하려면 SQL 쿼리에서 몇 가지 SELECT 문을 사용하면 됩니다. 다음 쿼리의 첫 번째 SELECT 문은 해당 기간 내의 새 QM SA에 표시되는 주소 목록을 반환합니다. 두 번째 SELECT 문은 이러한 주소를 사용하여 로그의 다른 곳에서 해당 주소와 연결된 사용자 이름과 컴퓨터 이름을 매핑합니다. 이 사용자/컴퓨터/주소 연결은 EM SA 이벤트에 있습니다. 이러한 이벤트는 세 개의 값을 모두 포함하므로 이 실습의 핵심적인 부분입니다. IPsec 2차 인증을 요구하지 않는 경우 이러한 유형의 보고를 할 수 없게 됩니다.

/* The following steps build the report, based on the three imported tables

* plus the two helpers above. These steps can be run any number of times as

* you refine your query.

*/

/* Create a temporary table to populate as the final report */

CREATE TABLE #SaHealthReport
(

[UserName] varchar(1023) null,

[ComputerName] varchar(1023) null,

[HealthEventType] int null

)

/* Run a query to find all IPsec Quick Mode Security Associations established

* within a given period. Populate a temporary table with the client IPv6

* addresses. */

SELECT DISTINCT[Address] INTO #TempAddresses

FROM [NapDa].[dbo].[DaSasTable] JOIN [NapDa].[dbo].[UserComputerAndAddr]

      ON RowN = RowNumber

WHERE [EventType]=8 AND

      [EventCategory]=12549 AND

      ([TimeGenerated] BETWEEN'2010-05-10 15:00:00.000' AND '2010-05-10 16:00:00.000')

/* Map the QM SA addresses to user and computer names and insert those into

* the final report. */

INSERT INTO #SaHealthReport(UserName,ComputerName)

SELECT UserComputerAndAddr.UserName,UserComputerAndAddr.ComputerName

FROM [NapDa].[dbo].[UserComputerAndAddr] JOIN #TempAddresses

      ON #TempAddresses.Address = UserComputerAndAddr.Address

WHERE (UserComputerAndAddr.UserName IS NOT NULL) AND (UserComputerAndAddr.ComputerName IS NOT NULL)

/* Populate the health column of the report. */

UPDATE #SaHealthReport

SET HealthEventType = ComputerHealth.EventType

FROM #SaHealthReport JOIN [NapDa].[dbo].[ComputerHealth]

      ON #SaHealthReport.ComputerName = ComputerHealth.ComputerName

/* Display all rows and columns of the report. */

SELECT DISTINCT *

FROM #SaHealthReport

SaHealthReport 보고서 테이블을 채우기 위한 마지막 단계는 HRA 상태 정보를 컴퓨터 및 사용자 ID 정보(지금까지 DirectAccess 서버에서만 얻은 정보)와 연계하는 것입니다. 이렇게 HRA 서버 정보를 포함하면 네트워크에 원격으로 연결하는 컴퓨터가 위험(정책 비준수로 인한)을 수반하는지 여부를 확인할 수 있는 강력한 도구가 됩니다. 이전 SQL 쿼리의 UPDATE 문을 보면 클라이언트 컴퓨터 이름을 사용하여 DirectAccess와 HRA 데이터가 상호 연계됨을 알 수 있습니다.

그림 5는 완성된 상태 보고서에서 반환될 수 있는 샘플 데이터를 보여 줍니다.

그림 5 완성된 샘플 상태 보고서

UserName	ComputerName	HealthEventType
Ichiro	ichiroadmin1	0
Grinch	whoville-cli	0
Raquel	omybc	0

사용자 지정 스크립트와 LogParser 도구를 사용하면 비교적 쉽게 IPsec(DirectAccess 포함) 및 NAP 배포에 대한 보고를 설정할 수 있습니다. 이 방법은 회사가 온사이트로, 또는 클라우드에서 LOB(기간 업무) 서비스를 제공하기 위한 보안 프레임워크를 만드는 데 도움이 될 것입니다.

Dan Griffin에게 전자 메일 보내기

Dan Griffin은 시애틀에 거주하는 소프트웨어 보안 컨설턴트입니다. 문의 사항이 있으면 www.jwsecure.com으로 연락하시기 바랍니다.

Lee Walker에게 전자 메일 보내기

*Lee Walker는 Microsoft 내부 IT 부서의 기술 설계자로 IPv6, IPsec, NAP, DirectAccess 및 기타 기술을 담당합니다. 문의 사항이 있으면 *lee.walker@microsoft.com으로 연락하시기 바랍니다.