使用共用存取簽章授與事件中樞資源的存取權
共用存取簽章 (SAS) 可讓您授權有限制存取事件中樞命名空間中的資源。 SAS 根據授權規則來保護存取事件中樞資源。 您可以在命名空間或事件中樞上設定這些規則。 本文提供 SAS 模型的概觀，並回顧 SAS 最佳做法。
注意
本文涵蓋使用 SAS 來授權存取事件中樞資源。 若要了解如何使用 SAS 來驗證對事件中樞資源的存取，請參閱使用 SAS 進行驗證。
什麼是共用存取簽章？
共用存取簽章 (SAS) 根據授權規則來委派存取事件中樞資源。 授權規則具有名稱、與特定權限相關聯，並且承載了密碼編譯金鑰組。 您透過事件中樞用戶端或在您自己的程式碼中，使用規則的名稱和金鑰來產生 SAS 權杖。 接著，用戶端可以將權杖傳遞至事件中樞，以證明獲授權執行所要求的作業。
SAS 是使用簡單權杖的宣告型授權機制。 使用 SAS 時，金鑰一律不會透過網路傳遞。 金鑰可用來以密碼編譯方式簽署稍後可由服務驗證的資訊。 SAS 的作用可類似於用戶端直接擁有授權規則名稱和相符金鑰的使用者名稱和密碼。 SAS 的用法類似於同盟安全性模型，其中，用戶端收到來自安全性權杖服務的時效性且已簽署的存取權杖，但從未擁有簽署金鑰。
注意
Azure 事件中樞也支援使用 Microsoft Entra ID 授權事件中樞資源。 使用由 Microsoft Entra ID 傳回的 OAuth 2.0 權杖來授權使用者或應用程式，可透過共用存取簽章 (SAS) 提供卓越的安全性與易用性。 透過 Microsoft Entra ID 即不需要冒著潛在安全性弱點的風險，將權杖儲存在程式碼中。
Microsoft 建議盡可能搭配使用 Microsoft Entra ID 與 Azure 事件中樞應用程式。 如需詳細資訊，請參閱使用 Microsoft Entra ID 授權存取 Azure 事件中樞資源。
重要
為了保護資源，SAS (共用存取簽章) 權杖不可或缺。 SAS 細微地授權用戶端存取事件中樞資源。 不應公開共用。 如果為了疑難排解而需要共用，請考慮使用經過縮略的任何記錄檔，或從記錄檔中刪除 SAS 權杖 (如果有的話)，還要確定螢幕擷取畫面不含 SAS 資訊。
共用存取授權原則
每個事件中樞命名空間和每個事件中樞實體 (事件中樞或 Kafka 主題)，都具有由規則組成的共用存取授權原則。 命名空間層級的原則會套用至命名空間內的所有實體，無論其個別的原則組態為何。
對於每個授權原則規則，您會決定三項資訊：名稱、範圍和權限。 名稱是該範圍內的唯一名稱。 範圍是所涉及資源的 URI。 就事件中樞命名空間而言，範圍是完整網域名稱 (FQDN)，例如 https://<yournamespace>.servicebus.windows.net/。
原則規則提供的權限可以是下列各項的組合：
- 傳送 - 授權將訊息傳送至實體
- 接聽－授權接聽或接收來自實體的訊息
- 管理－授權管理命名空間的拓撲，包括建立和刪除實體。 管理權限包含傳送和接聽權限。
命名空間或實體原則最多支援 12 個共用存取授權規則，有空間存放三組規則 (各涵蓋基本權限) 及「傳送」與「接聽」的組合。 此限制突顯 SAS 原則存放區並非使用者或服務帳戶存放區。 如果應用程式需要根據使用者或服務識別，以授權存取事件中樞，則應該實作安全性權杖服務，在驗證和存取檢查後發出 SAS 權杖。
授權規則會獲得主要金鑰和次要金鑰。 這些是強式密碼編譯的金鑰。 請勿遺失或洩漏。 一律都在 Azure 入口網站中。 您可以使用其中一個產生的金鑰，以及您可以隨時重新產生它們。 如果您重新產生或變更原則中的金鑰，所有先前根據該金鑰發行的權杖都將立即無效。 不過，根據這類權杖建立的作用中連線會繼續運作，直到權杖到期。
建立事件中樞命名空間時會自動為命名空間建立名為 RootManageSharedAccessKey 的原則規則。 此原則具有整個命名空間的管理權限。 建議將此規則視為管理根帳戶，不要用在應用程式中。 您可以在入口網站中，透過 PowerShell 或 Azure CLI，在命名空間的 [設定] 索引標籤中建立額外的原則規則。
使用 SAS 時的最佳做法
當您在應用程式中使用共用存取簽章時，您必須留意兩個潛在風險：
- 如果洩漏 SAS，則任何取得之人皆可使用，有可能危害事件中樞資源。
- 如果提供給用戶端應用程式的 SAS 過期，且應用程式無法從服務擷取新的 SAS，則可能阻礙應用程式的功能。
下列關於使用共用存取簽章的建議，將可協助您平衡這些風險：
- 必要時讓用戶端自動更新 SAS：用戶端應該在 SAS 到期之前儘早更新 SAS，萬一提供 SAS 的服務無法使用，至少還有時間重試。 如果打算將 SAS 用於少數即時的短暫作業，而這些預計都在到期時間內完成，則不需要此建議，因為預期不會更新 SAS。 不過，如果您有定期透過 SAS 做出要求的用戶端，則到期的可能性便有可能發生。 究竟是需要短期的 SAS (如先前所述)，還是需要確保用戶端及早要求更新 (以避免因為 SAS 在成功更新之前過期而導致中斷)，主要考量即在這兩者之間尋求平衡。
- 注意 SAS 開始時間：如果您將 SAS 的開始時間設定為現在，由於時鐘誤差 (不同機器的目前時間差距)，前幾分鐘可能間歇失敗。 一般而言，請將開始時間設為至少 15 分鐘之前的時間。 或者，完全不設定，在所有情況下立即生效。 到期時間通常也是如此。 請記住，在任何要求上，順逆時鐘誤差可能長達 15 分鐘。
- 特別針對要存取的資源：安全性最佳做法是為使用者提供最低必要權限。 如果使用者只須要針對單一實體的讀取存取權，請為該單一實體授予讀取存取權限，無須為所有實體授予讀取/寫入/刪除權限。 這也有助於減輕 SAS 洩露所造成的損害，因為 SAS 在攻擊者手中權限較低。
- 不一定要使用 SAS：對事件中樞執行特定作業時，引起的風險有時高過 SAS 的優點。 針對這類作業，請建立中介層服務，在商務規則確認、驗證和稽核之後才寫入事件中樞。
- 一律使用 HTTPS：一律使用 HTTPS 來建立或發佈 SAS。 若透過 HTTP 來傳遞 SAS 並遭到攔截，執行攔截式攻擊的攻擊者即可讀取並使用 SAS (就如同預期使用者執行般)，這有可能會洩露敏感資料或允許惡意使用者損毀資料。
推論
共用存取簽章有助於提供有限權限給用戶端存取事件中樞資源。 對於任何使用 Azure 事件中樞的應用程式，這些是安全性模型的重要部分。 如果您遵循本文所列的最佳做法，則可以使用 SAS 以更高彈性存取資源，而不會危及應用程式的安全性。
下一步
請參閱下列相關文章：