Service Broker 對話安全性

適用于:SQL ServerAzure SQL 受控執行個體

對話安全性為特定交談提供加密、遠端驗證和遠端授權。 當交談使用對話安全性時,Service Broker 會加密在SQL Server實例外部傳送的所有訊息。 Service Broker 交談預設會使用對話安全性。

對話安全性基本概念

Service Broker 對話方塊安全性可讓您的應用程式針對個別對話對話使用驗證、授權或加密, (或對話方塊) 。 依預設,所有對話交談都會使用對話安全性。 當您開始對話時,可以在 BEGIN DIALOG CONVERSATION 陳述式中加入 ENCRYPTION = OFF 子句,明確地允許對話在不使用對話安全性的情況下繼續進行。 不過,如果做為交談目標的服務存在遠端服務繫結,則即使 ENCRYPTION = OFF,對話也會使用安全性。

針對使用安全性的對話方塊,Service Broker 會加密SQL Server實例外部傳送的所有訊息。 保留在SQL Server實例內的訊息永遠不會加密。 在對話安全性中,只有裝載起始服務的資料庫和主控目標服務的資料庫才需要具有對安全性所使用之憑證的存取權。 也就是說,執行訊息轉送的實例不需要能夠解密實例轉送的訊息。

Service Broker 提供兩種類型的對話安全性、完整安全性和匿名安全性。 對於使用對話安全性的交談,Service Broker 會提供遠端授權,以將交談的遠端端對應至本機使用者。

當交談使用完整安全性或匿名安全性時,會在網路上加密訊息。 不過,目標資料庫中的有效權限和用於訊息加密的策略,在這兩種方法中會稍有不同。

無論交談使用完整安全性還是匿名安全性,都會使用為特定交談產生的對稱工作階段金鑰加密訊息主體。 只有使用為對話方塊安全性提供的憑證,使用私密金鑰加密來加密金鑰。 Service Broker 也會執行訊息完整性檢查,以協助偵測訊息損毀或竄改。

SQL Server會為使用對話安全性的交談建立工作階段金鑰。 為了在儲存在資料庫中時保護工作階段金鑰,Service Broker 會使用資料庫的主要金鑰來加密工作階段金鑰。 如果資料庫主要金鑰無法使用,則交談的訊息會保留在 transmission_status 中,併發生錯誤,直到資料庫主要金鑰建立,或直到交談逾時為止。因此,參與交談的兩個資料庫都必須包含主要金鑰,即使資料庫裝載在同一個實例中也一樣。 如果起始資料庫不包含主要金鑰,則對話將會失敗。 如果目標資料庫不包含主要金鑰,則訊息會保留在起始資料庫的傳輸佇列中。 這些訊息的最後一個傳輸錯誤表示無法傳遞訊息的原因。 使用 ENCRYPTION = OFF 參數來建立未加密對話方塊,或使用下列命令來建立資料庫主要金鑰:

    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<password>'

為了方便起見,不論資料庫是否包含主要金鑰,Service Broker 都允許在單一資料庫中保持的安全交談繼續進行。 在交談存留時間期間,可以將兩個不同的資料庫移動到不同的 SQL Server 執行個體,單一資料庫內的交談會永遠保留在該資料庫內。 這樣一來,交談就可以繼續進行。

完整安全性

完整安全性有助於保護起始服務,防止將訊息傳送至不受信任的資料庫,並協助保護目標服務免于接收來自不受信任資料庫的訊息。 當交談使用完整安全性時,Service Broker 會加密透過網路傳輸的訊息。

完整安全性可以同時為起始服務和目標服務提供識別。 完整安全性要求起始服務信任目標服務,同時也要求目標服務信任起始服務。 例如,從零售商訂購零件的服務可能要求訂購應用程式信任零售商服務,同時要求零售商服務信任訂購應用程式。

資料庫管理員會透過交換包含公開金鑰的憑證來建立信任。 對於完整對話安全性,交談的每一端都要包含本機使用者的私密金鑰和遠端使用者的公開金鑰。 裝載起始服務的資料庫包含「遠端服務繫結」。 此遠端服務繫結會指定擁有對應至遠端資料庫中的私密金鑰之憑證的本機使用者。 因此,代表起始服務的作業,會以指定的使用者身分在目標資料庫內執行。

目標資料庫包含使用者。 該使用者擁有一個憑證,其可對應至擁有起始服務之使用者所擁有的私密金鑰。 因此,代表目標服務的作業,會以擁有起始服務之使用者的身分在起始資料庫內執行。

對於使用完整安全性的對話,交談的每一端都會產生工作階段金鑰。 每個方向的第一則訊息包含使用金鑰交換金鑰加密的工作階段金鑰,如 憑證和 Service Broker中所述。

匿名安全性

匿名安全性可協助保護起始服務,以防止將訊息傳送至不受信任的資料庫。 當交談使用匿名安全性時,Service Broker 會加密透過網路傳輸的訊息。

匿名安全性會識別到起始服務的目標服務,但不識別到目標服務的起始服務。

例如,提交工作訂單的應用程式可能需要保證工作訂單的收件者是所需目標,但目標資料庫則不需要為提交工作訂單的服務提供任何特殊權限。 在此情況下,包含起始服務的資料庫必須包含目標服務的遠端服務繫結。

因為目標服務無法驗證起始服務的身分識別,所以代表起始服務的作業會以目標資料庫中固定資料庫角色 公用 的成員身分執行。 目標資料庫不會接收到有關起始交談之使用者的任何資訊。 目標資料庫不需要包含起始交談之使用者的憑證。

對於使用匿名安全性的對話,交談的兩端都會使用起始資料庫所產生的工作階段金鑰。 目標資料庫不會將工作階段金鑰傳回給起始資料庫。

對話安全性的安全性內容

Service Broker 遠端授權可控制個別服務的遠端存取。 遠端授權會決定傳送至SQL Server實例的傳入訊息傳送至服務的安全性內容。

Service Broker 一律會針對未完全在 SQL Server 實例內進行的安全交談使用遠端授權。 針對交談設定的對話方塊安全性會決定 Service Broker 用於遠端授權的安全性內容。

當交談保留在SQL Server實例內時,Service Broker 不會使用遠端授權,即使已設定遠端授權也一樣。 對於實例內的交談,SQL Server安全性主體已可供SQL Server使用,因此不需要使用遠端授權來判斷 Service Broker 作業的正確安全性內容。 不過,如本主題稍早所述,Service Broker 會建立工作階段金鑰,以便在其中一個資料庫在交談期間移至另一個實例時繼續交談。

對於使用匿名安全性的交談,連線會以目標資料庫中固定資料庫角色 公用 的成員身分執行。 在此情況下,固定資料庫角色 公用 必須具有將訊息傳送至服務的許可權。 但是,該角色不需要資料庫中的其他權限。

對於使用完整安全性的交談,交談每一端的連接都會使用遠端服務繫結中指定之使用者的權限來運作。 例如,如果遠端服務系結將服務名稱InventoryService 與使用者 InventoryServiceRemoteUser產生關聯,SQL Server使用InventoryServiceRemoteUser的安全性內容,將InventoryService應用程式的訊息放在目的地服務的佇列上。

為了獲得更高的安全性,通常,擁有服務私密金鑰的使用者與為啟用指定的使用者不應為同一個。 擁有私密金鑰的使用者只需要將訊息新增至佇列的許可權,也就是使用佇列之服務的 SEND 許可權。 相反地,為啟用指定的使用者需要具有完成所要求之工作並傳送回應的必要權限。 在上述範例中, InventoryServiceRemoteUser 不需要查詢清查資料表或傳送傳回訊息的許可權。 使用者只需要許可權,才能將訊息傳送至 InventoryService 使用的佇列。 會在具有佇列指定之認證的其他工作階段中發生預存程序啟用。 不需要在將訊息加入佇列的工作階段和處理訊息的工作階段之間共用任何認證。

建立安全對話

當 Service Broker 在兩個資料庫之間建立對話方塊時,起始服務必須在目標資料庫中建立使用者內容,才能將訊息放入目標佇列中。 這個使用者內容會決定起始服務是否具有權限,可開啟與目標的對話。

這樣做的最具彈性方法是建立憑證和遠端服務繫結。 如需建立憑證的詳細資訊,請參閱 CREATE CERTIFICATE (Transact-SQL) 。 如需建立遠端服務系結的詳細資訊,請參閱 CREATE REMOTE SERVICE BINDING (Transact-SQL)

注意

如果安全性內容未正確設定,在對話方塊上傳送的訊息會保留在起始服務的sys.transmission_queue中,並在 [transmission_status] 資料行中出現下列錯誤訊息: 伺服器主體 '%.*ls' 無法存取目前安全性內容下的資料庫 '%.*ls'

另請參閱