Shared Access Signature による Service Bus のアクセスの制御Service Bus access control with Shared Access Signatures

この記事では、Shared Access Signature (SAS)、そのしくみ、およびプラットフォームに依存しない方法で共有アクセス署名を使用する方法について説明します。This article discusses Shared Access Signatures (SAS), how they work, and how to use them in a platform-agnostic way.

SAS は、承認規則に基づいて Service Bus へのアクセスを保護します。SAS guards access to Service Bus based on authorization rules. これらは、名前空間またはメッセージング エンティティ (キューまたはトピック) のいずれかに構成されます。Those are configured either on a namespace, or a messaging entity (queue, or topic). 承認規則は、名前を持ち、特定の権限に関連付けられており、暗号化キーのペアを保持しています。An authorization rule has a name, is associated with specific rights, and carries a pair of cryptographic keys. Service Bus SDK または独自のコードから規則の名前とキーを使って SAS トークンを生成します。You use the rule's name and key via the Service Bus SDK or in your own code to generate a SAS token. その後、クライアントはトークンを Service Bus に渡して、要求する操作に対する承認を証明することができます。A client can then pass the token to Service Bus to prove authorization for the requested operation.

注意

Azure Service Bus では、Azure Active Directory (Azure AD) を使用する Service Bus 名前空間とそのエンティティへのアクセスの承認がサポートされます。Azure Service Bus supports authorizing access to a Service Bus namespace and its entities using Azure Active Directory (Azure AD). Azure AD によって返された OAuth 2.0 トークンを使用するユーザーまたはアプリケーションの承認では、Shared Access Signatures (SAS) よりも優れたセキュリティが提供され、使いやすくなります。Authorizing users or applications using OAuth 2.0 token returned by Azure AD provides superior security and ease of use over shared access signatures (SAS). Azure AD を使用すれば、コードにトークンを格納する必要がなく、潜在的なセキュリティ脆弱性のリスクはありません。With Azure AD, there is no need to store the tokens in your code and risk potential security vulnerabilities.

Microsoft では、可能な場合は、Azure Service Bus アプリケーションで Azure AD を使用することをお勧めします。Microsoft recommends using Azure AD with your Azure Service Bus applications when possible. 詳細については、次の記事を参照してください。For more information, see the following articles:

SAS の概要Overview of SAS

Shared Access Signature は、簡単なトークンを使う要求ベースの承認メカニズムです。Shared Access Signatures are a claims-based authorization mechanism using simple tokens. SAS を使うと、ネットワーク経由でキーが渡されることがなくなります。Using SAS, keys are never passed on the wire. キーは、後でサービスによって検証が可能な情報に暗号で署名するために使われます。Keys are used to cryptographically sign information that can later be verified by the service. SAS は、承認規則と照合キーをクライアントが直接所有しているユーザー名とパスワードの方式と同じように使うことができます。SAS can be used similar to a username and password scheme where the client is in immediate possession of an authorization rule name and a matching key. また、SAS は使用できます、フェデレーション セキュリティ モデルと同じように使うこともできます。その場合、クライアントは時間制限のある署名されたアクセス トークンをセキュリティ トークン サービスから受け取り、署名キーを所有することはありません。SAS can also be used similar to a federated security model, where the client receives a time-limited and signed access token from a security token service without ever coming into possession of the signing key.

Service Bus での SAS 認証は、アクセス権が関連付けられている名前付きの Shared Access Authorization 規則と、プライマリおよびセカンダリの暗号化キーのペアによって構成されます。SAS authentication in Service Bus is configured with named Shared Access Authorization Rules having associated access rights, and a pair of primary and secondary cryptographic keys. キーは、Base64 で表された 256 ビットの値です。The keys are 256-bit values in Base64 representation. 規則の構成は、名前空間レベルおよび Service Bus のリレーキュートピックで行うことができます。You can configure rules at the namespace level, on Service Bus relays, queues, and topics.

Shared Access Signature のトークンには、選択された承認規則、アクセスする必要があるリソースの URI、有効期限、および選択された承認規則のプライマリまたはセカンダリ暗号化キーを使ってこれらのフィールドについて計算された HMAC-SHA256 暗号化署名が含まれます。The Shared Access Signature token contains the name of the chosen authorization rule, the URI of the resource that shall be accessed, an expiry instant, and an HMAC-SHA256 cryptographic signature computed over these fields using either the primary or the secondary cryptographic key of the chosen authorization rule.

共有アクセス承認ポリシーShared Access Authorization Policies

各 Service Bus 名前空間と各 Service Bus エンティティには、規則で構成された共有アクセス承認ポリシーがあります。Each Service Bus namespace and each Service Bus entity has a Shared Access Authorization policy made up of rules. 名前空間レベルのポリシーは、個々のポリシー構成に関係なく、名前空間内のすべてのエンティティに適用されます。The policy at the namespace level applies to all entities inside the namespace, irrespective of their individual policy configuration.

各承認ポリシー規則について、名前スコープ、および 権限 という 3 種類の情報を決定します。For each authorization policy rule, you decide on three pieces of information: name, scope, and rights. 名前 とは、文字どおり名前を表します。そのスコープ内で一意の名前です。The name is just that; a unique name within that scope. スコープは簡単です。対象となるリソースの URI です。The scope is easy enough: it's the URI of the resource in question. Service Bus 名前空間の場合、スコープは、https://<yournamespace>.servicebus.windows.net/ のような完全修飾ドメイン名 (FQDN) です。For a Service Bus namespace, the scope is the fully qualified domain name (FQDN), such as https://<yournamespace>.servicebus.windows.net/.

ポリシー規則での権限は、次のものの組み合わせです。The rights conferred by the policy rule can be a combination of:

  • "送信" - エンティティにメッセージを送信する権限です'Send' - Confers the right to send messages to the entity
  • "リッスン" - 受信 (キュー、サブスクリプション) および関連するすべてのメッセージ処理の権限を付与します'Listen' - Confers the right to receive (queue, subscriptions) and all related message handling
  • "管理" - エンティティの作成や削除など、名前空間のトポロジを管理する権限です。'Manage' - Confers the right to manage the topology of the namespace, including creating and deleting entities

"管理" 権限には "送信" 権限と "受信" 権限が含まれます。The 'Manage' right includes the 'Send' and 'Receive' rights.

名前空間ポリシーまたはエンティティ ポリシーは最大 12 個の共有アクセス承認規則を保持でき、それぞれが基本権限と送信および受信の組み合わせをカバーする、3 つの規則セットに対応できます。A namespace or entity policy can hold up to 12 Shared Access Authorization rules, providing room for three sets of rules, each covering the basic rights and the combination of Send and Listen. この制限は、SAS ポリシー ストアがユーザーまたはサービス アカウント ストアのためのものではないことを明確に示します。This limit underlines that the SAS policy store is not intended to be a user or service account store. お使いのアプリケーションがユーザー ID またはサービス ID に基づいて Service Bus へのアクセスを許可する必要がある場合は、認証とアクセス チェックの後で SAS トークンを発行するセキュリティ トークン サービスを実装する必要があります。If your application needs to grant access to Service Bus based on user or service identities, it should implement a security token service that issues SAS tokens after an authentication and access check.

承認規則には、"主キー" と "セカンダリ キー" が割り当てられます。An authorization rule is assigned a Primary Key and a Secondary Key. これらは、暗号化された強力なキーです。These are cryptographically strong keys. これらをなくしたり、外部に漏らしたりしないでください。これらは、常に Azure portal から入手可能です。Don't lose them or leak them - they'll always be available in the Azure portal. 生成されたキーのいずれかを使用できます。また、いつでも再生成できます。You can use either of the generated keys, and you can regenerate them at any time. ポリシーのキーを再生成または変更すると、そのキーに基づいてそれまでに発行されたすべてのトークンが、すぐに無効になります。If you regenerate or change a key in the policy, all previously issued tokens based on that key become instantly invalid. ただし、そのようなトークンを基にして作成された進行中の接続は、トークンの有効期限が切れるまで動作し続けます。However, ongoing connections created based on such tokens will continue to work until the token expires.

Service Bus の名前空間を作成すると、RootManageSharedAccessKey という名前のポリシー規則が、その名前空間に対して自動的に作成されます。When you create a Service Bus namespace, a policy rule named RootManageSharedAccessKey is automatically created for the namespace. このポリシーには、名前空間全体の管理アクセス許可があります。This policy has Manage permissions for the entire namespace. この規則は管理 root アカウントと同じように扱い、アプリケーションでは使わないようにすることをお勧めします。It's recommended that you treat this rule like an administrative root account and don't use it in your application. ポータルの名前空間の [構成] タブ、PowerShell または Azure CLI を使って、追加のポリシー規則を作成できます。You can create additional policy rules in the Configure tab for the namespace in the portal, via PowerShell or Azure CLI.

SAS を使用する際のベスト プラクティスBest practices when using SAS

アプリケーションで Shared Access Signature を使用する場合は、次の 2 つの潜在的なリスクに注意する必要があります。When you use shared access signatures in your applications, you need to be aware of two potential risks:

  • SAS が漏えいすると、それを取得した人はだれでも使用できるため、Service Bus リソースが侵害される可能性があります。If a SAS is leaked, it can be used by anyone who obtains it, which can potentially compromise your Service Bus resources.
  • クライアント アプリケーションに提供された SAS が期限切れになり、アプリケーションでサービスから新しい SAS を取得できない場合は、アプリケーションの機能が損なわれる可能性があります。If a SAS provided to a client application expires and the application is unable to retrieve a new SAS from your service, then application’s functionality may be hindered.

Shared Access Signature の使用に関する次の推奨事項に従うと、これらのリスクの軽減に役立ちます。The following recommendations for using shared access signatures can help mitigate these risks:

  • 必要に応じて、クライアントで SAS が自動的に更新されるようにする:クライアントでは、SAS を提供するサービスを使用できない場合に再試行する時間を考慮して、有効期限までに余裕を持って SAS を更新する必要があります。Have clients automatically renew the SAS if necessary: Clients should renew the SAS well before expiration, to allow time for retries if the service providing the SAS is unavailable. SAS が、有効期間内の完了が予想される短時間で数の少ない即時操作に使用される予定の場合は、SAS が更新されることが想定されないため、不要である可能性があります。If your SAS is meant to be used for a small number of immediate, short-lived operations that are expected to be completed within the expiration period, then it may be unnecessary as the SAS is not expected to be renewed. ただし、クライアントが SAS 経由で日常的に要求を実行する場合は、有効期限に注意が必要になる可能性があります。However, if you have client that is routinely making requests via SAS, then the possibility of expiration comes into play. 重要な考慮事項は、SAS の有効期限を短くする必要性 (前述のように) と、(更新が正常に完了する前に SAS の期限が切れることによる中断を避けるために) クライアントで早めに更新を要求する必要性とのバランスです。The key consideration is to balance the need for the SAS to be short-lived (as previously stated) with the need to ensure that client is requesting renewal early enough (to avoid disruption due to the SAS expiring prior to a successful renewal).
  • SAS の開始時刻に注意する:SAS の開始時刻を [現在] に設定すると、クロック スキュー (コンピューターの違いによる現在時刻の差) により、最初の数分間にエラーが間欠的に発生する場合があります。Be careful with the SAS start time: If you set the start time for SAS to now, then due to clock skew (differences in current time according to different machines), failures may be observed intermittently for the first few minutes. 一般に、開始時刻は 15 分以上前になるように設定します。In general, set the start time to be at least 15 minutes in the past. または、まったく設定せず、すべての場合ですぐに有効になるようにします。Or, don’t set it at all, which will make it valid immediately in all cases. 同じことが、一般的には有効期限にも適用されます。The same generally applies to the expiry time as well. どの要求でも、最大 15 分のクロック スキューが前後に発生する可能性があることに注意してください。Remember that you may observer up to 15 minutes of clock skew in either direction on any request.
  • アクセス先のリソースを具体的に指定する:セキュリティのベスト プラクティスは、必要最小限の特権をユーザーに付与することです。Be specific with the resource to be accessed: A security best practice is to provide user with the minimum required privileges. ユーザーに必要なのは、1 つのエンティティへの読み取りアクセスだけの場合は、すべてのエンティティへの読み取り/書き込み/削除アクセスではなく、その 1 つのエンティティへの読み取りアクセスだけをユーザーに許可します。If a user only needs read access to a single entity, then grant them read access to that single entity, and not read/write/delete access to all entities. 攻撃者の手中にある SAS の機能を低下させるため、SAS が侵害された場合に損害を抑えるのにも役立ちます。It also helps lessen the damage if a SAS is compromised because the SAS has less power in the hands of an attacker.
  • 場合によっては SAS を使用しないようにする:Event Hubs に対する特定の操作に関連するリスクが、SAS の利点を上回ることがあります。Don’t always use SAS: Sometimes the risks associated with a particular operation against your Event Hubs outweigh the benefits of SAS. このような操作では、ビジネス ルールの検証、認証、および監査の後に Event Hubs に書き込む中間層サービスを作成します。For such operations, create a middle-tier service that writes to your Event Hubs after business rule validation, authentication, and auditing.
  • 常に HTTPS を使用する:常に HTTPS を使用して SAS を作成または配布します。Always use HTTPs: Always use Https to create or distribute a SAS. SAS が HTTP 経由で渡され、傍受された場合、中間者攻撃を実行している攻撃者は、SAS を読み取って、意図したユーザーと同様に使用することができます。そのため、機微なデータが侵害されたり、悪意のあるユーザーによるデータ破損が発生したりする可能性があります。If a SAS is passed over HTTP and intercepted, an attacker performing a man-in-the-middle attach is able to read the SAS and then use it just as the intended user could have, potentially compromising sensitive data or allowing for data corruption by the malicious user.

Shared Access Signature 認証の構成Configuration for Shared Access Signature authentication

SharedAccessAuthorizationRule 規則は、Service Bus の名前空間、キュー、トピックに構成できます。You can configure the SharedAccessAuthorizationRule rule on Service Bus namespaces, queues, or topics. Service Bus サブスクリプションに対する SharedAccessAuthorizationRule の構成は現在サポートされていませんが、名前空間またはトピックに構成されている規則を使用して、サブスクリプションへのアクセスをセキュリティで保護できます。Configuring a SharedAccessAuthorizationRule on a Service Bus subscription is currently not supported, but you can use rules configured on a namespace or topic to secure access to subscriptions. この手順を示す作業サンプルについては、 Service Bus サブスクリプションでの Shared Access Signature (SAS) 認証の使用 に関するサンプルを参照してください。For a working sample that illustrates this procedure, see the Using Shared Access Signature (SAS) authentication with Service Bus Subscriptions sample.

SAS

この図では、manageRuleNS sendRuleNS および listenRuleNS の承認規則は、キュー Q1 とトピック T1 の両方に適用されます。それに対し、listenRuleQ および sendRuleQ は、キュー Q1 にのみ適用され、sendRuleT はトピック T1 にのみ適用されます。In this figure, the manageRuleNS, sendRuleNS, and listenRuleNS authorization rules apply to both queue Q1 and topic T1, while listenRuleQ and sendRuleQ apply only to queue Q1 and sendRuleT applies only to topic T1.

Shared Access Signature トークンの生成Generate a Shared Access Signature token

承認規則の名前およびその署名キーの 1 つにアクセスできるすべてのクライアントは、SAS トークンを生成できます。Any client that has access to name of an authorization rule name and one of its signing keys can generate a SAS token. 次の形式の文字列を作成することで、トークンが生成されます。The token is generated by crafting a string in the following format:

SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>
  • se - トークンの有効期限。se - Token expiry instant. エポック 1970 年 1 月 1 日 00:00:00 UTC (UNIX エポック) からトークンの期限が切れるまでの秒数を示す整数。Integer reflecting seconds since the epoch 00:00:00 UTC on 1 January 1970 (UNIX epoch) when the token expires.

  • skn - 承認規則の名前。skn - Name of the authorization rule.

  • sr - アクセスされているリソースの URL でエンコードされた URI。sr - URL-encoded URI of the resource being accessed.

  • sig - URL でエンコードされた HMACSHA256 署名。sig - URL-encoded HMACSHA256 signature. ハッシュ計算は次の擬似コードのようになり、生のバイナリ出力の base64 が返されます。The hash computation looks similar to the following pseudo code and returns base64 of raw binary output.

    urlencode(base64(hmacsha256(urlencode('https://<yournamespace>.servicebus.windows.net/') + "\n" + '<expiry instant>', '<signing key>')))
    

SAS トークンを生成する C# コードの例を次に示します。Here's an example C# code for generating a SAS token:

private static string createToken(string resourceUri, string keyName, string key)
{
    TimeSpan sinceEpoch = DateTime.UtcNow - new DateTime(1970, 1, 1);
    var week = 60 * 60 * 24 * 7;
    var expiry = Convert.ToString((int)sinceEpoch.TotalSeconds + week);
    string stringToSign = HttpUtility.UrlEncode(resourceUri) + "\n" + expiry;
    HMACSHA256 hmac = new HMACSHA256(Encoding.UTF8.GetBytes(key));
    var signature = Convert.ToBase64String(hmac.ComputeHash(Encoding.UTF8.GetBytes(stringToSign)));
    var sasToken = String.Format(CultureInfo.InvariantCulture, "SharedAccessSignature sr={0}&sig={1}&se={2}&skn={3}", HttpUtility.UrlEncode(resourceUri), HttpUtility.UrlEncode(signature), expiry, keyName);
    return sasToken;
}

重要

さまざまなプログラミング言語を使用して SAS トークンを生成する例については、SAS トークンの生成に関する記事を参照してください。For examples of generating a SAS token using different programming languages, see Generate SAS token.

受信側が同じパラメーターでハッシュを再計算して、発行者が有効な署名キーを所有していることを確認できるように、トークンにはハッシュされていない値が含まれています。The token contains the non-hashed values so that the recipient can recompute the hash with the same parameters, verifying that the issuer is in possession of a valid signing key.

リソース URI とは、アクセスが要求される Service Bus リソースの完全な URI です。The resource URI is the full URI of the Service Bus resource to which access is claimed. たとえば、http://<namespace>.servicebus.windows.net/<entityPath> または sb://<namespace>.servicebus.windows.net/<entityPath> (つまり http://contoso.servicebus.windows.net/contosoTopics/T1/Subscriptions/S3) です。For example, http://<namespace>.servicebus.windows.net/<entityPath> or sb://<namespace>.servicebus.windows.net/<entityPath>; that is, http://contoso.servicebus.windows.net/contosoTopics/T1/Subscriptions/S3.

URI は パーセント エンコードになっている必要があります。The URI must be percent-encoded.

署名に使用される共有アクセス承認規則は、この URI、またはその階層の親のいずれかで指定したエンティティに構成する必要があります。The shared access authorization rule used for signing must be configured on the entity specified by this URI, or by one of its hierarchical parents. たとえば、前の例では、http://contoso.servicebus.windows.net/contosoTopics/T1 または http://contoso.servicebus.windows.net となります。For example, http://contoso.servicebus.windows.net/contosoTopics/T1 or http://contoso.servicebus.windows.net in the previous example.

SAS トークンは、signature-string で使われている <resourceURI> がプレフィックスになっているすべてのリソースで有効です。A SAS token is valid for all resources prefixed with the <resourceURI> used in the signature-string.

キーの再生成Regenerating keys

SharedAccessAuthorizationRule オブジェクトで使用されるキーは、定期的に再生成することをお勧めします。It is recommended that you periodically regenerate the keys used in the SharedAccessAuthorizationRule object. ときどきキーをローテーションできるように、主キーとセカンダリ キーのスロットが存在します。The primary and secondary key slots exist so that you can rotate keys gradually. お使いのアプリケーションが通常は主キーを使っている場合は、主キーをセカンダリ キー スロットにコピーし、主キーだけを再生成できます。If your application generally uses the primary key, you can copy the primary key into the secondary key slot, and only then regenerate the primary key. その後、セカンダリ スロットの古い主キーを使ってアクセスを続けてきたクライアント アプリケーションに、新しい主キーの値を構成します。The new primary key value can then be configured into the client applications, which have continued access using the old primary key in the secondary slot. すべてのクライアントが更新されたら、セカンダリ キーを再生成して、最終的に古い主キーの使用を終了できます。Once all clients are updated, you can regenerate the secondary key to finally retire the old primary key.

キーが侵害されたことがはっきりしているか疑わしく、キーを取り消す必要がある場合は、SharedAccessAuthorizationRulePrimaryKeySecondaryKey の両方を再生成し、それらを新しいキーに置き換えることができます。If you know or suspect that a key is compromised and you have to revoke the keys, you can regenerate both the PrimaryKey and the SecondaryKey of a SharedAccessAuthorizationRule, replacing them with new keys. この手順により、古いキーで署名されたすべてのトークンが無効になります。This procedure invalidates all tokens signed with the old keys.

Service Bus による Shared Access Signature 認証Shared Access Signature authentication with Service Bus

以下で説明するシナリオには、承認規則の構成、SAS トークンの生成、クライアントの承認などが含まれます。The scenario described as follows include configuration of authorization rules, generation of SAS tokens, and client authorization.

構成を説明して SAS 承認を使用する、Service Bus アプリケーションのサンプルについては、Service Bus による Shared Access Signature 認証に関するページを参照してください。For a sample of a Service Bus application that illustrates the configuration and uses SAS authorization, see Shared Access Signature authentication with Service Bus.

エンティティの共有アクセス承認規則へのアクセスAccess Shared Access Authorization rules on an entity

Service Bus .NET Framework ライブラリでは、Service Bus のキューまたはトピックに構成された Microsoft.ServiceBus.Messaging.SharedAccessAuthorizationRule オブジェクトに、対応する QueueDescription または TopicDescriptionAuthorizationRules コレクションを介してアクセスできます。With Service Bus .NET Framework libraries, you can access a Microsoft.ServiceBus.Messaging.SharedAccessAuthorizationRule object configured on a Service Bus queue or topic through the AuthorizationRules collection in the corresponding QueueDescription or TopicDescription.

次のコードでは、キューの承認規則を追加する方法を示します。The following code shows how to add authorization rules for a queue.

// Create an instance of NamespaceManager for the operation
NamespaceManager nsm = NamespaceManager.CreateFromConnectionString(
    <connectionString> );
QueueDescription qd = new QueueDescription( <qPath> );

// Create a rule with send rights with keyName as "contosoQSendKey"
// and add it to the queue description.
qd.Authorization.Add(new SharedAccessAuthorizationRule("contosoSendKey",
    SharedAccessAuthorizationRule.GenerateRandomKey(),
    new[] { AccessRights.Send }));

// Create a rule with listen rights with keyName as "contosoQListenKey"
// and add it to the queue description.
qd.Authorization.Add(new SharedAccessAuthorizationRule("contosoQListenKey",
    SharedAccessAuthorizationRule.GenerateRandomKey(),
    new[] { AccessRights.Listen }));

// Create a rule with manage rights with keyName as "contosoQManageKey"
// and add it to the queue description.
// A rule with manage rights must also have send and receive rights.
qd.Authorization.Add(new SharedAccessAuthorizationRule("contosoQManageKey",
    SharedAccessAuthorizationRule.GenerateRandomKey(),
    new[] {AccessRights.Manage, AccessRights.Listen, AccessRights.Send }));

// Create the queue.
nsm.CreateQueue(qd);

Shared Access Signature 承認の使用Use Shared Access Signature authorization

Service Bus .NET ライブラリと Azure .NET SDK を使用するアプリケーションでは、 SharedAccessSignatureTokenProvider クラスを介して SAS 承認を使用できます。Applications using the Azure .NET SDK with the Service Bus .NET libraries can use SAS authorization through the SharedAccessSignatureTokenProvider class. 次のコードでは、Service Bus キューにメッセージを送信するトークン プロバイダーの使用を示しています。The following code illustrates the use of the token provider to send messages to a Service Bus queue. ここで示した使用法の代わりに、以前に発行されたトークンをトークン プロバイダーのファクトリ メソッドに渡すこともできます。Alternative to the usage shown here, you can also pass a previously issued token to the token provider factory method.

Uri runtimeUri = ServiceBusEnvironment.CreateServiceUri("sb",
    <yourServiceNamespace>, string.Empty);
MessagingFactory mf = MessagingFactory.Create(runtimeUri,
    TokenProvider.CreateSharedAccessSignatureTokenProvider(keyName, key));
QueueClient sendClient = mf.CreateQueueClient(qPath);

//Sending hello message to queue.
BrokeredMessage helloMessage = new BrokeredMessage("Hello, Service Bus!");
helloMessage.MessageId = "SAS-Sample-Message";
sendClient.Send(helloMessage);

また、トークン プロバイダーを直接使って、他のクライアントに渡すトークンを発行することもできます。You can also use the token provider directly for issuing tokens to pass to other clients.

接続文字列には、規則名 (SharedAccessKeyName) と規則キー (SharedAccessKey) または以前に発行されたトークン (SharedAccessSignature) を含めることができます。Connection strings can include a rule name (SharedAccessKeyName) and rule key (SharedAccessKey) or a previously issued token (SharedAccessSignature). 接続文字列を受け付けるコンストラクターまたはファクトリ メソッドに渡される接続文字列にこれらが存在する場合、SAS トークン プロバイダーが自動的に作成されて設定されます。When those are present in the connection string passed to any constructor or factory method accepting a connection string, the SAS token provider is automatically created and populated.

Service Bus リレーで SAS 承認を使用するには、Service Bus 名前空間に構成されている SAS キーを使用できます。Note that to use SAS authorization with Service Bus relays, you can use SAS keys configured on the Service Bus namespace. 名前空間 (RelayDescription を指定した NamespaceManager) のオブジェクトにリレーを明示的に作成する場合は、そのリレーに SAS 規則を設定するだけです。If you explicitly create a relay on the namespace (NamespaceManager with a RelayDescription) object, you can set the SAS rules just for that relay. Service Bus サブスクリプションで SAS 承認を使用するには、Service Bus 名前空間またはトピックに構成されている SAS キーを使用できます。To use SAS authorization with Service Bus subscriptions, you can use SAS keys configured on a Service Bus namespace or on a topic.

Shared Access Signature の使用 (HTTP レベル)Use the Shared Access Signature (at HTTP level)

Service Bus ですべてのエンティティの Shared Access Signature を作成する方法を理解したので、HTTP POST を実行する準備ができました。Now that you know how to create Shared Access Signatures for any entities in Service Bus, you are ready to perform an HTTP POST:

POST https://<yournamespace>.servicebus.windows.net/<yourentity>/messages
Content-Type: application/json
Authorization: SharedAccessSignature sr=https%3A%2F%2F<yournamespace>.servicebus.windows.net%2F<yourentity>&sig=<yoursignature from code above>&se=1438205742&skn=KeyName
ContentType: application/atom+xml;type=entry;charset=utf-8

この方法は、すべての機能に対して利用できます。Remember, this works for everything. キュー、トピック、またはサブスクリプションに対して SAS を作成できます。You can create SAS for a queue, topic, or subscription.

送信者またはクライアントに SAS トークンを付与する場合は、送信者またはクライアントはキーを直接保持しないため、キーを取得するハッシュを反転できません。If you give a sender or client a SAS token, they don't have the key directly, and they cannot reverse the hash to obtain it. そのため、管理者は、送信者またはクライアントがアクセスできる対象とアクセスする期間を制御できます。As such, you have control over what they can access, and for how long. 重要なのは、ポリシーのプライマリ キーを変更する場合は、ポリシーから作成された Shared Access Signature がすべて無効になるということです。An important thing to remember is that if you change the primary key in the policy, any Shared Access Signatures created from it are invalidated.

Shared Access Signature の使用 (AMQP レベル)Use the Shared Access Signature (at AMQP level)

前のセクションでは、データを Service Bus に送信するために、HTTP POST 要求を使用して SAS トークンを使用する方法について説明しました。In the previous section, you saw how to use the SAS token with an HTTP POST request for sending data to the Service Bus. ご存じのように、Service Bus へのアクセスには、AMQP (Advanced Message Queuing Protocol) を使用できます。AMQP は、多くのシナリオでパフォーマンス上の理由から好まれているプロトコルです。As you know, you can access Service Bus using the Advanced Message Queuing Protocol (AMQP) that is the preferred protocol to use for performance reasons, in many scenarios. SAS トークンと AMQP の併用については、AMQP Claim-Based Security Version 1.0 のドキュメントを参照してください。このドキュメントは、2013 年から執筆されているドラフトですが、現在も Azure でサポートされています。The SAS token usage with AMQP is described in the document AMQP Claim-Based Security Version 1.0 that is in working draft since 2013 but it's supported by Azure today.

Service Bus へのデータ送信を開始する前に、発行元から適切に定義された $cbs という AMQP ノードに対して、AMQP メッセージ内で SAS トークンを送信する必要があります (すべての SAS トークンを取得して検証するためにサービスで使用される "特別な" キューと考えることができます)。Before starting to send data to Service Bus, the publisher must send the SAS token inside an AMQP message to a well-defined AMQP node named $cbs (you can see it as a "special" queue used by the service to acquire and validate all the SAS tokens). 発行元は、AMQP メッセージ内で ReplyTo フィールドを指定する必要があります。これは、サービスから発行元に対してトークンの検証結果を返信するノードです (発行元とサービス間の簡単な要求/応答のパターン)。The publisher must specify the ReplyTo field inside the AMQP message; this is the node in which the service replies to the publisher with the result of the token validation (a simple request/reply pattern between publisher and service). この応答ノードは、AMQP 1.0 仕様に記載されているように、"リモート ノードの動的作成" について話すことで "その場で" 作成されます。This reply node is created "on the fly," speaking about "dynamic creation of remote node" as described by the AMQP 1.0 specification. 発行元は SAS トークンが有効であることを確認した後に、次の処理に進み、サービスに対してデータを送信できるようになります。After checking that the SAS token is valid, the publisher can go forward and start to send data to the service.

次の手順は、AMQP.NET Lite ライブラリを使用して、AMQP プロトコルで SAS トークンを送信する方法を示しています。The following steps show how to send the SAS token with AMQP protocol using the AMQP.NET Lite library. この方法は、C# で開発する公式の Service Bus SDK (WinRT、.NET Compact Framework、.NET Micro Framework、Mono など) を使用できない場合に有効です。This is useful if you can't use the official Service Bus SDK (for example on WinRT, .NET Compact Framework, .NET Micro Framework and Mono) developing in C#. 当然ながら、HTTP レベル ("Authorization" ヘッダー内で送信される HTTP POST 要求と SAS トークン) の場合と同様に、要求ベースのセキュリティが AMQP レベルでどのように機能するかを理解するためにもこのライブラリは役立ちます。Of course, this library is useful to help understand how claims-based security works at the AMQP level, as you saw how it works at the HTTP level (with an HTTP POST request and the SAS token sent inside the "Authorization" header). AMQP についてこのような詳しい知識が不要な場合は、公式の Service Bus SDK と .NET Framework アプリケーションを利用できます。これがその役割を果たします。If you don't need such deep knowledge about AMQP, you can use the official Service Bus SDK with .NET Framework applications, which will do it for you.

C#C#

/// <summary>
/// Send claim-based security (CBS) token
/// </summary>
/// <param name="shareAccessSignature">Shared access signature (token) to send</param>
private bool PutCbsToken(Connection connection, string sasToken)
{
    bool result = true;
    Session session = new Session(connection);

    string cbsClientAddress = "cbs-client-reply-to";
    var cbsSender = new SenderLink(session, "cbs-sender", "$cbs");
    var cbsReceiver = new ReceiverLink(session, cbsClientAddress, "$cbs");

    // construct the put-token message
    var request = new Message(sasToken);
    request.Properties = new Properties();
    request.Properties.MessageId = Guid.NewGuid().ToString();
    request.Properties.ReplyTo = cbsClientAddress;
    request.ApplicationProperties = new ApplicationProperties();
    request.ApplicationProperties["operation"] = "put-token";
    request.ApplicationProperties["type"] = "servicebus.windows.net:sastoken";
    request.ApplicationProperties["name"] = Fx.Format("amqp://{0}/{1}", sbNamespace, entity);
    cbsSender.Send(request);

    // receive the response
    var response = cbsReceiver.Receive();
    if (response == null || response.Properties == null || response.ApplicationProperties == null)
    {
        result = false;
    }
    else
    {
        int statusCode = (int)response.ApplicationProperties["status-code"];
        if (statusCode != (int)HttpStatusCode.Accepted && statusCode != (int)HttpStatusCode.OK)
        {
            result = false;
        }
    }

    // the sender/receiver may be kept open for refreshing tokens
    cbsSender.Close();
    cbsReceiver.Close();
    session.Close();

    return result;
}

PutCbsToken() メソッドは、サービスに対する TCP 接続を表す connection (AMQP .NET Lite ライブラリに用意されている AMQP Connection クラス インスタンス) と、送信する SAS トークンである sasToken パラメーターを受け取ります。The PutCbsToken() method receives the connection (AMQP connection class instance as provided by the AMQP .NET Lite library) that represents the TCP connection to the service and the sasToken parameter that is the SAS token to send.

注意

(SAS トークンを送信する必要がないときに使用されるユーザー名とパスワードを含む既定の PLAIN ではなく) ANONYMOUS に設定された SASL 認証メカニズム を使用して、接続が作成されている点に注意してください。It's important that the connection is created with SASL authentication mechanism set to ANONYMOUS (and not the default PLAIN with username and password used when you don't need to send the SAS token).

次に、発行元は、SAS トークンの送信とサービスからの応答 (トークンの検証結果) の受信に使用される 2 つの AMQP リンクを作成します。Next, the publisher creates two AMQP links for sending the SAS token and receiving the reply (the token validation result) from the service.

AMQP メッセージには一連のプロパティと、簡単なメッセージより多くの情報が含まれています。The AMQP message contains a set of properties, and more information than a simple message. SAS トークンはメッセージの本文です (コンストラクターを使用)。The SAS token is the body of the message (using its constructor). "ReplyTo" プロパティは、受信側リンクで検証結果を受信するノード名に設定されます (必要に応じて名前を変更できます。名前はサービスで自動的に作成されます)。The "ReplyTo" property is set to the node name for receiving the validation result on the receiver link (you can change its name if you want, and it will be created dynamically by the service). 最後の 3 つの application/custom プロパティは、実行する必要がある操作の種類を示すためにサービスで使用されます。The last three application/custom properties are used by the service to indicate what kind of operation it has to execute. CBS ドラフト仕様に記載されているように、操作名 ("put-token")、トークンの種類 (この例では、servicebus.windows.net:sastoken)、およびトークンを適用する オーディエンスの "名前" (エンティティ全体) を設定する必要があります。As described by the CBS draft specification, they must be the operation name ("put-token"), the type of token (in this case, a servicebus.windows.net:sastoken), and the "name" of the audience to which the token applies (the entire entity).

発行元は、送信側リンクで SAS トークンを送信した後に、受信側リンクの応答を読み取る必要があります。After sending the SAS token on the sender link, the publisher must read the reply on the receiver link. 応答は、"status-code" というアプリケーション プロパティを含む簡単な AMQP メッセージです。このプロパティには、HTTP 状態コードと同じ値を含めることができます。The reply is a simple AMQP message with an application property named "status-code" that can contain the same values as an HTTP status code.

Service Bus の操作に必要な権限Rights required for Service Bus operations

次の表に、Service Bus のリソースでのさまざまな操作に必要となるアクセス権を示します。The following table shows the access rights required for various operations on Service Bus resources.

操作Operation 必要な要求Claim Required 要求のスコープClaim Scope
NamespaceNamespace
名前空間での承認規則を構成するConfigure authorization rule on a namespace 管理するManage 任意の名前空間アドレスAny namespace address
サービス レジストリService Registry
プライベート ポリシーを列挙するEnumerate Private Policies 管理するManage 任意の名前空間アドレスAny namespace address
名前空間でリッスンを開始するBegin listening on a namespace リッスンListen 任意の名前空間アドレスAny namespace address
名前空間のリスナーにメッセージを送信するSend messages to a listener at a namespace SendSend 任意の名前空間アドレスAny namespace address
キューQueue
キューを作成するCreate a queue 管理するManage 任意の名前空間アドレスAny namespace address
キューを削除するDelete a queue 管理するManage 任意の有効なキュー アドレスAny valid queue address
キューを列挙するEnumerate queues 管理するManage /$Resources/Queues/$Resources/Queues
キューの説明を取得するGet the queue description 管理するManage 任意の有効なキュー アドレスAny valid queue address
キューの承認規則を構成するConfigure authorization rule for a queue 管理するManage 任意の有効なキュー アドレスAny valid queue address
キューに送信するSend into to the queue SendSend 任意の有効なキュー アドレスAny valid queue address
キューからメッセージを受信するReceive messages from a queue リッスンListen 任意の有効なキュー アドレスAny valid queue address
ピーク ロック モードでメッセージを受信した後にそのメッセージを破棄または終了するAbandon or complete messages after receiving the message in peek-lock mode リッスンListen 任意の有効なキュー アドレスAny valid queue address
後で取得するためにメッセージを保留するDefer a message for later retrieval リッスンListen 任意の有効なキュー アドレスAny valid queue address
メッセージを配信不能にするDeadletter a message リッスンListen 任意の有効なキュー アドレスAny valid queue address
メッセージのキュー セッションに関連付けられた状態を取得するGet the state associated with a message queue session リッスンListen 任意の有効なキュー アドレスAny valid queue address
メッセージのキュー セッションに関連付けられた状態を設定するSet the state associated with a message queue session リッスンListen 任意の有効なキュー アドレスAny valid queue address
後で配信するメッセージのスケジュールを設定する (例: ScheduleMessageAsync())Schedule a message for later delivery; for example, ScheduleMessageAsync() リッスンListen 任意の有効なキュー アドレスAny valid queue address
トピックTopic
トピックを作成するCreate a topic 管理するManage 任意の名前空間アドレスAny namespace address
トピックを削除するDelete a topic 管理するManage 任意の有効なトピック アドレスAny valid topic address
トピックを列挙するEnumerate topics 管理するManage /$Resources/Topics/$Resources/Topics
トピックの説明を取得するGet the topic description 管理するManage 任意の有効なトピック アドレスAny valid topic address
トピックの承認規則を構成するConfigure authorization rule for a topic 管理するManage 任意の有効なトピック アドレスAny valid topic address
トピックに送信するSend to the topic SendSend 任意の有効なトピック アドレスAny valid topic address
サブスクリプションSubscription
サブスクリプションの作成Create a subscription 管理するManage 任意の名前空間アドレスAny namespace address
サブスクリプションを削除するDelete subscription 管理するManage ../myTopic/Subscriptions/mySubscription../myTopic/Subscriptions/mySubscription
サブスクリプションを列挙するEnumerate subscriptions 管理するManage ../myTopic/Subscriptions../myTopic/Subscriptions
サブスクリプションの説明を取得するGet subscription description 管理するManage ../myTopic/Subscriptions/mySubscription../myTopic/Subscriptions/mySubscription
ピーク ロック モードでメッセージを受信した後にそのメッセージを破棄または終了するAbandon or complete messages after receiving the message in peek-lock mode リッスンListen ../myTopic/Subscriptions/mySubscription../myTopic/Subscriptions/mySubscription
後で取得するためにメッセージを保留するDefer a message for later retrieval リッスンListen ../myTopic/Subscriptions/mySubscription../myTopic/Subscriptions/mySubscription
メッセージを配信不能にするDeadletter a message リッスンListen ../myTopic/Subscriptions/mySubscription../myTopic/Subscriptions/mySubscription
トピック セッションに関連付けられた状態を取得するGet the state associated with a topic session リッスンListen ../myTopic/Subscriptions/mySubscription../myTopic/Subscriptions/mySubscription
トピック セッションに関連付けられた状態を設定するSet the state associated with a topic session リッスンListen ../myTopic/Subscriptions/mySubscription../myTopic/Subscriptions/mySubscription
ルールRules
規則を作成するCreate a rule 管理するManage ../myTopic/Subscriptions/mySubscription../myTopic/Subscriptions/mySubscription
規則を削除するDelete a rule 管理するManage ../myTopic/Subscriptions/mySubscription../myTopic/Subscriptions/mySubscription
規則を列挙するEnumerate rules 管理またはリッスンManage or Listen ../myTopic/Subscriptions/mySubscription/Rules../myTopic/Subscriptions/mySubscription/Rules

次のステップNext steps

Service Bus メッセージングの詳細については、次のトピックをご覧ください。To learn more about Service Bus messaging, see the following topics.