Service Broker 對話安全性

發行項
12/15/2008

對話安全性為特定交談提供加密、遠端驗證和遠端授權。當交談使用對話安全性時，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 會加密透過網路傳輸的訊息。

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

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

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

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

對話安全性的安全性內容

Service Broker 遠端授權控制對個別服務的遠端存取。遠端授權可以決定將 SQL Server 執行個體的內送訊息傳送至服務所使用的安全性內容。

對不完全發生在 SQL Server 執行個體內的安全交談，Service Broker 會永遠使用遠端授權。為交談設定的對話安全性會決定 Service Broker 用於遠端授權的安全性內容。

當交談保留在 SQL Server 執行個體內時，即使已設定遠端授權，Service Broker 也不會使用遠端授權。對於執行個體內的交談，SQL Server 已可以使用 SQL Server 安全性主體，因此不需要使用遠端授權來決定 Service Broker 作業的正確安全性內容。不過，如這個主題前面所述，Service Broker 會建立工作階段金鑰，以便在交談期間將其中之一個資料庫移動到其他執行個體時，交談可以繼續進行。

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

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

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

建立安全對話

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

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

另一種建立憑證和遠端服務繫結的方法是使用 SQL Server 安全性，來建立這兩個資料庫之間的信任關聯性。起始服務的擁有者會在目標服務中模擬使用者。這可能需要將起始資料庫上的 TRUSTWORTHY 資料庫屬性設定為 ON，並將驗證權限授與目標資料庫中的使用者。如需詳細資訊，請參閱＜使用 EXECUTE AS 擴充資料庫模擬＞。

附註：
如果未正確設定安全性內容，則對話所傳送的訊息會保留在起始服務的 sys.transmission_queue 中，且在 transmission_status 資料行會有下列錯誤訊息：*伺服器主體 '%.ls' 在目前的安全性內容下無法存取資料庫 '%.ls'。*

請參閱

共用方式為