選擇安全性 QOS 選項

安全性 QOS 選項會當做提供給RpcBindingSetAuthInfoEx函式之 SecurityQOS參數的一部分傳遞。 使用下列最佳做法。

使用相互驗證

真正的相互驗證僅適用于特定安全性提供者：交涉 kerberos) 、Kerberos 和安全通道時，交涉 (。 NTLM 不支援相互驗證。 使用相互驗證需要提供格式正確的伺服器主體名稱。 許多開發人員都使用下列錯誤的安全性做法：系統會呼叫伺服器來要求其主體名稱， (RpcMgmtInqServerPrincName) ，然後他們盲目要求使用該主體名稱進行相互驗證。 此方法會中斷相互驗證的整個概念;相互驗證的概念是只會呼叫某些伺服器，因為它們受到信任來剖析及處理您的資料。 使用剛才描述的錯誤安全性做法，開發人員會將其資料提供給任何聰明的人，以傳回其名稱。

例如，如果用戶端軟體應該只呼叫在 Joe、Pete 或 Alice 帳戶下執行的伺服器，則應該呼叫 RpcMgmtInqServerPrincName 函式，並檢查傳回的名稱。 如果是 Joe、Pete 或 Alice，應該使用其伺服器主體名稱來要求相互驗證。 這可確保交談的兩半都會移至相同的主體。

如果用戶端軟體應該只呼叫在 Joe 帳戶下執行的服務，請直接撰寫 Joe 的伺服器主體名稱並進行呼叫。 如果伺服器不是 Joe，則呼叫只會失敗。

許多時候，服務會以 Windows 系統服務的形式執行，這表示它們會在電腦帳戶下執行。 仍建議使用相互驗證和建立伺服器主體名稱。

使用允許呼叫通過的最低 ImpersonationType

此最佳做法相當容易理解。 即使使用相互驗證，也不會讓伺服器擁有比必要更多的許可權;合法的伺服器可能已遭到入侵，即使您傳送的資料在這類情況下落在錯誤的手上，伺服器至少將無法代表您存取網路上的其他資料。 有些伺服器會拒絕沒有足夠資訊的呼叫，以判斷可能模擬呼叫端。 此外，請注意，某些通訊協定序列支援傳輸層級安全性 (ncacn_np 和 ncalrpc) 。 在這種情況下，當您建立系結控制碼時，如果您透過 NetworkOptions 參數指定了足夠高模擬層級，則伺服器一律可以模擬您。

最後，某些安全性提供者或傳輸可能會以透明方式將 ImpersonationType 提升至高於指定的層級。 開發程式時，請務必嘗試使用預期的 ImpersonationType 進行呼叫，並檢查您是否在伺服器上取得較高的 ImpersonationType。