循規報告：控制用戶端雲端存取的第一步

利用 NAP 和 IPsec 透過 DirectAccess 控制用戶端的存取，來改善稽核與循規報告。

Dan Griffin 與 Lee Walker

確立安全存取是將企業推向雲端必然的第一步。現在針對循規、報告和遠端連線設定原則，即可為您的小組鋪路，讓他們安全順利地在雲端工作。將網路存取保護 (NAP) 搭配 DirectAccess 之類的 IPsec 連線技術，可以改善稽核與循規報告。

在為新的 DirectAccess 或 IPsec 部署建立稽核與報告解決方案時，要識別和收集必要的資料並不容易。接下來我們要示範一家虛構公司如何建立 DirectAccess 和 NAP 解決方案，並提供報告資料來判斷連線的對象、何時連線以及用戶端電腦是否遵循規範。

循規問題

隨著工作人力逐漸行動化，有越來越多的組織開始採取彈性化的遠端存取技術，例如 DirectAccess。使用 DirectAccess 時，只要授權電腦一連上網際網路，使用者便會自動連上遠端網路。遠端用戶端的安全性修補程式難免有過期的時候，也有遭到惡意程式碼感染的可能，因此許多組織也開始部署 NAP 和 IPsec，以確保只有健康的用戶端得以存取安全資源。

金融服務、醫療和政府等機構為了資料完整性，必須進行驗證作業，確保只有健康且經過核准的用戶端能夠連接到雲端或本站網路資源。這些機構通常都需要借助內部循規原則和聯邦法律，來確認銀行帳號、姓名和醫療記錄等個人識別資訊 (PII) 沒有遭到任何未獲授權人士 (包括惡意程式碼和不明的協力廠商應用程式) 的存取。

使用者希望尋求更方便的途徑來存取遠端工作資源，而這些安全機構的 IT 管理者也必須確保只有健康的用戶端能夠存取公司網路。只是要從 NAP 和 DirectAccess 記錄建立有意義的報告，必須面對許多困難。

其解決方法是設定 DirectAccess 基礎結構以便順利進行遠端用戶端存取、利用 NAP 和 IPsec 來保護內部網路資源，以及透過報告來監視原則。TechNet 提供一些適當的資訊告訴您如何利用 DirectAccess 來實作 NAP，但是有關如何有效記錄和報告用戶端的健康狀況方面的指導方針卻不多。下面我們要分析一家虛構的公司 (Woodgrove 國家銀行)，示範公司顧問如何利用簡單的程式碼和 SQL 查詢來建立易讀的報告、詳細說明在指定時段內連線的用戶端，以及那些用戶端是否遵循 NAP 規範。

在 DirectAccess 設定 NAP

DirectAccess 要求連線用戶端必須執行相容版本的 Windows (Windows 7 Ultimate 或 Windows 7 Enterprise)。這些用戶端會連線到執行 Windows Server 2008 R2 的 DirectAccess 伺服器。DirectAccess 部署可包含一或多部 DirectAccess 伺服器 (我們建議您至少準備兩部伺服器，以協助維持忙碌網路的負載平衡)。部署也必須含有一部網路位置伺服器 (用來判斷用戶端是否連上網際網路或內部網路)，以及一或多個憑證撤銷清單 (CRL) 發佈點 (用來追蹤那些不再有權存取的用戶端)。若要瞭解如何設計 DirectAccess 部署，請參閱 TechNet 上的 DirectAccess 設計指南。

當您將 NAP 加入 DirectAccess 時，必須針對 NAP 實作 IPsec 強制方法。使用 IPsec 時，遵循 NAP 規範的用戶端會獲得健康情況憑證。不合規的電腦，便無法與合規的電腦通訊。若要瞭解如何設計和部署 NAP，請參閱 TechNet 上的利用網路存取保護來規劃 DirectAccess。若要瞭解如何透過 IPsec 將 NAP 設計為強制方法，請參閱 TechNet 上的 IPsec 強制設計。

值得考量的是 NAP IPsec 強制案例如何在 DirectAccess 及其 IPsec 連線原則的環境內運作。第一點，由於 DirectAccess 是使用 IPsec 來進行驗證和保密，因此 DirectAccess 部署中的 NAP 強制案例必須是 IPsec。第二點，請注意 IPsec 的 AuthIP 元件可讓您在原則內分別設定兩種驗證需求，而連線必須符合這兩種需求才能順利連線。如果這兩種 AuthIP 驗證選項都有設定，通常第一種是電腦認證，第二種是使用者認證。不過就技術上來說，您可以設定兩種電腦認證。

至於 NAP 要如何融入 AuthIP 原則呢？NAP/IPsec 強制案例會授予健康電腦一份含健康物件識別碼 (OID) 的憑證，而 AuthIP 原則引擎包含一個要求提供該健康 OID 的選項。因此只有健康的電腦才能滿足第一個 AuthIP 驗證需求，與 DirectAccess 伺服器建立 IPsec 連線。

最後一點，使用者認證是第二個 AuthIP 驗證選項的目的。就技術上來說，使用者認證對於 DirectAccess 而言並非必要。換句話說，用戶端只要使用一個電腦憑證，就可以對 DirectAccess 端點進行驗證。但是注重安全性的 IT 人員，對於沒有進行強式驗證就授予完整的遠端網路存取權，還是會有所存疑。因此您至少要設定 AuthIP 原則，要求對方提供第二個 Kerberos 驗證。索取使用者認證的憑證 (就像 Woodgrove 國家銀行案例的示範) 是比較理想的做法，因為它可以降低遠端靜態密碼攻擊的風險。

在這個案例當中，Woodgrove 國家銀行的網路安全性和循規部門要求提供報告，指出在過去指定時段內有誰連上公司網路，以及那些用戶端是否遵循 NAP 規範。這些群組認為客戶資料很有可能已經在那段時間受到入侵。身為銀行顧問，我們必須決定如何撰寫 DirectAccess 和 NAP 的事後報告，然後將該些資訊整合成易讀的報告。

適當的原則組態

在這個虛構案例當中，Woodgrove 國家銀行設定了 DirectAccess，因此 IPsec 原則要求對方必須提供含有 NAP 系統健康情況 OID 和用戶端驗證 OID 的用戶端憑證。Woodgrove 是以強制模式使用 NAP (而非只是報告模式)，這表示不健康的用戶端會受到封鎖，不得與健康的用戶端進行通訊。

最後一點，Woodgrove 將 DirectAccess IPsec 原則設定為使用兩種憑證式認證 — 一種是來自用戶端電腦，另一種是來自使用者。正如我們在前面所提到的建議，Woodgrove 為了更加妥善運用其 PKI 投資而選擇雙憑證組態，它捨棄遠端存取的靜態密碼，改採憑證自動註冊。

本案例的後文假設您已知道如何操作 DirectAccess、NAP 和 IPsec 強制模式。如需深入了解這些技術，請參閱下列資源：

• 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 國家銀行的 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 伺服器上的事件是下午兩點的事件，而 HRA 的事件卻是下午兩點半。因此，如果我們要反覆執行，就必須在實際執行環境採用集中收集事件的方式。

產生資料

為了產生資料，我們在 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.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 格式的資料字串不但超過這個長度 (尤其在 [字串] 欄位更是；請參閱 [圖 2])，而且還不能將它們截斷。根據實驗結果，您必須將預設長度設為 1023 才夠。

[圖 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》文章中範例程式碼所採用的方法。

下面這個程式碼範例詳細說明了將 RegEx 功能整合到我們 SELECT 陳述式中的 SQL 使用者定義函式的原始程式碼。該函式稱為 RegexGroup，與《MSDN Magazine》文章所提及的函式一樣。我們將函式主體的前兩行做了一處更改，讓我們得以檢查 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 位址。如果您要在其他環境使用它，必須加強這個模式。 ·        雖然 [字串] 資料行中還有其他內嵌的 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) 開始著手。QM SA 事件在本案例中相當有用，因為 IPsec 已設定為必須進行第二因素驗證 (使用者的認證)。我們選擇使用這種報告方法，是因為 QM SA 相對來說時間比較短 (以本案例來說是一小時，閒置五分鐘即逾時)，很適合稽核存取。相反的，MM SA 只使用電腦認證，而且預設得維持八小時 (不過如果稽核是您 DirectAccess 部署的一個重要元件，建議您最好能夠縮短 MM 使用期限)。

只不過，QM 事件不含使用者名稱或電腦名稱，只含 IP 位址。如果要將 IP 位址對應到電腦名稱和使用者名稱，可以在我們的 SQL 查詢中使用少許 SELECT 陳述式。在下面這個查詢當中，第一個 SELECT 陳述式會傳回在該時段內出現在新 QM SA 的位址清單。第二個 SELECT 陳述式是使用那些位址，對應到與記錄檔中其他地方出現的該位址相關聯的使用者名稱和電腦名稱 (這個使用者/電腦/位址關聯是位於 EM SA 事件中。這些事件在本練習當中具有舉足輕重的地位，因為它們包含了所有三個值；如果您不要求進行 IPsec 第二項驗證，就無法建立這類型的報告)。

/* 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 健康資訊和電腦與使用者識別資訊之間建立關聯，而這項資訊只能從 DirectAccess 伺服器取得。整合 HRA 伺服器資訊是一項強大的工具，可讓您判斷遠端連線到您網路的電腦是否會帶來風險 (因為不合規)。請參閱前一個 SQL 查詢中的 UPDATE 陳述式 — DirectAccess 和 HRA 資料之間的關聯，是使用用戶端電腦名稱所建立。

[圖 5] 示範的是完成的健康情況報告可能傳回的範例資料。

[圖 5] 完成的健康報告範例

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

 

您可以在 IPsec (包含 DirectAccess) 和 NAP 部署，利用一些自訂指令碼和 LogParser 工具，輕易地建立報告。這個方法可以協助公司著手建立一個安全的架構，在本端或雲端提供企業營運系統服務。

Dan Griffin 是西雅圖的軟體安全性顧問。他的聯絡方式為  www.jwsecure.com

 

Lee Walker 是 Microsoft 內部 IT 部門的技術架構設計師，負責 IPv6、IPsec、NAP、DirectAccess 和其他技術。他的聯絡方式為 lee.walker@microsoft.com.

 

相關內容

• Cable Guy：DirectAccess 和薄邊緣網路
• 安全性監控：  關於身分識別，第 1 篇
• 安全性監控：關於身分識別，第 2 篇