對話安全性的憑證
當交談開始時,Service Broker 會使用遠端服務繫結來尋找要用於交談的憑證。此主題描述 Service Broker 如何決定要用於交談的憑證。
尋找對話的憑證
Service Broker 會先尋找交談的遠端服務繫結,然後再選取繫結中指定之使用者擁有的憑證。
為了尋找繫結,Service Broker 會檢查資料庫,以找到指定交談之目標服務名稱的繫結。
為了選取憑證,Service Broker 會尋找遠端服務繫結中指定之使用者所擁有並具有最晚到期日的憑證。Service Broker 不會考慮尚無效、已經過期或未標示為可用於開始對話的憑證。如需有關憑證的詳細資訊,請參閱<CREATE CERTIFICATE (Transact-SQL)>。
如果不存在遠端服務繫結,或遠端服務繫結的使用者不具有可用於開始對話的有效憑證,則 Service Broker 無法加密交談的訊息。如果不存在繫結,且資料庫包含「Broker 設定服務」,則 Service Broker 會透過該服務要求繫結。如果資料庫中沒有「Broker 設定服務」或「Broker 設定服務」不提供遠端服務繫結,則當加密設定為 ON 時交談會延遲,設定為 OFF 時交談會繼續且不進行加密。如需詳細資訊,請參閱<決定對話安全性類型>。
遠端授權和對話安全性
Service Broker 對話安全性使用憑證進行遠端授權。當對話使用對話安全性時,交談之每個參與者所傳送的第一則訊息,都會包含以傳送使用者之私密金鑰加密的標頭資訊,以及以接收使用者之公開金鑰加密的標頭資訊。訊息的內容則會使用工作階段金鑰進行加密。工作階段金鑰本身也已加密,且只能使用接收使用者的私密金鑰進行復原。
如果訊息的接收者可以成功加密訊息,則表示接收者擁有對應的金鑰,並確認交談中每個參與者的識別。在資料庫中安裝憑證會建立與保留私密金鑰之資料庫的信任關係。
實際上,以本機參與者的私密金鑰加密標頭,會詢問「遠端資料庫是否信任本機資料庫?」如果遠端資料庫包含對應的公開金鑰,則資料庫只能解密標頭。以遠端資料庫中使用者的公開金鑰加密標頭,會詢問「本機資料庫是否信任遠端資料庫?」如果遠端資料庫包含對應的私密金鑰,則資料庫只能解密標頭。為了安全性和效能考量,Service Broker 會同時提出這兩個問題。不過會建構訊息,確保接受者可以確認這兩個問題,來正確回應訊息。
此策略的推理很簡單。如果遠端資料庫可以解密使用本機資料庫之私密金鑰加密的標頭,則遠端資料庫包含對應的公開金鑰,且遠端資料庫信任本機資料庫。如果遠端資料庫可以解密使用本機資料庫之公開金鑰加密的標頭,則遠端資料庫包含對應的私密金鑰,且本機資料庫信任遠端資料庫。只要私密金鑰保持機密,則只有交談所涉及的兩個資料庫才能成功交換交談的訊息。
附註: |
---|
僅安裝來自受信任來源的憑證。不要散發私密金鑰。 |
完整對話安全性會在首次交換訊息時雙向驗證識別。對於使用匿名對話安全性的交談,起始端會驗證目標資料庫是否包含預期的私密金鑰。不過,使用匿名對話安全性,目標資料庫不會驗證起始端的識別,而裝載目標服務的資料庫必須允許 public 固定資料庫角色將訊息傳送至該服務。
訊息必須進行雙向交換,本機資料庫才會考慮確認遠端資料庫的識別。僅當本機資料庫包含遠端資料庫憑證的正確公開金鑰時,才會進行驗證。
Service Broker 會在交談之每一端所傳送的第一則訊息中包括下列標頭:
- 「服務配對」安全性標頭,包含有關訊息所使用之憑證的資訊。服務配對安全性標頭使用擁有服務之使用者的私密金鑰來簽署。
- 「金鑰交換金鑰」,對訊息主體以 128 位元工作階段金鑰進行加密。金鑰交換金鑰使用遠端使用者的公開金鑰進行加密。
對於使用匿名安全性的對話,服務配對安全性標頭不會加密。但訊息本身會加密,且金鑰交換金鑰會使用目標資料庫中安全性主體的公開金鑰進行加密。在此情況下,第一個傳回的訊息將不包含金鑰交換金鑰、服務配對安全性標頭或加密的工作階段金鑰。
當 Service Broker 本身產生回應內送訊息的訊息 (例如,錯誤或收條) 時,該訊息會使用內送訊息的工作階段金鑰,無論對話是使用完整安全性還是匿名安全性。
請參閱
概念
其他資源
CREATE REMOTE SERVICE BINDING (Transact-SQL)
ALTER REMOTE SERVICE BINDING (Transact-SQL)
DROP REMOTE SERVICE BINDING (Transact-SQL)
CREATE CERTIFICATE (Transact-SQL)
ALTER CERTIFICATE (Transact-SQL)
DROP CERTIFICATE (Transact-SQL)