Shared Access Signature による Service Bus のアクセスの制御

[アーティクル]
11/28/2023

この記事では、Shared Access Signature (SAS)、そのしくみ、および Azure Service Bus を使用してプラットフォームに依存しない方法でそれらを使用する方法について説明します。

SAS は、名前空間またはメッセージングエンティティ (キューまたはトピック) で構成された承認規則に基づいて、Service Bus へのアクセスを保護します。承認規則は、名前を持ち、特定の権限に関連付けられており、暗号化キーのペアを保持しています。 Service Bus SDK または独自のコードから規則の名前とキーを使って SAS トークンを生成します。その後、クライアントはトークンを Service Bus に渡して、要求する操作に対する承認を証明することができます。

Note

Azure Service Bus では、Service Bus 名前空間とそのエンティティへの Microsoft Entra ID を使ったアクセスの認可がサポートされます。 Microsoft Entra ID によって返される OAuth 2.0 トークンを使用してユーザーまたはアプリケーションを認可すると、Shared Access Signature (SAS) よりもセキュリティと使いやすさが向上します。 SAS キーにはきめ細かなアクセスの制御がなく、管理/ローテーションが困難であり、その使用を特定のユーザーまたはサービスプリンシパルに関連付ける監査機能がありません。これらの理由から、Microsoft Entra ID の使用をお勧めします。

Microsoft では、可能であれば Azure Service Bus アプリケーションで Microsoft Entra ID を使用することをお勧めします。詳細については、次の記事を参照してください。

Service Bus 名前空間に対するローカルまたは SAS キーの認証を無効にし、Microsoft Entra 認証のみを許可することができます。詳細な手順については、「ローカル認証の無効化」を参照してください。

SAS の概要

Shared Access Signature は、簡単なトークンを使う要求ベースの承認メカニズムです。 SAS を使うと、ネットワーク経由でキーが渡されることがなくなります。キーは、後でサービスによって検証が可能な情報に暗号で署名するために使われます。 SAS は、承認規則と照合キーをクライアントが直接所有しているユーザー名とパスワードの方式と同じように使うことができます。また、SAS は使用できます、フェデレーションセキュリティモデルと同じように使うこともできます。その場合、クライアントは時間制限のある署名されたアクセストークンをセキュリティトークンサービスから受け取り、署名キーを所有することはありません。

Service Bus での SAS 認証は、アクセス権が関連付けられている名前付きの共有アクセス承認ポリシーと、主およびセカンダリの暗号化キーのペアで構成されます。キーは、Base 64 表現の 256 ビットの値です。規則の構成は、名前空間レベルおよび Service Bus のキューおよびトピックで行うことができます。

Note

これらのキーは Base 64 表現を使用するプレーンテキスト文字列であり、使用する前にデコードしないようにする必要があります。

Shared Access Signature のトークンには、選択された承認ポリシー、アクセスする必要があるリソースの URI、有効期限、および選択された承認規則のプライマリまたはセカンダリ暗号化キーを使ってこれらのフィールドについて計算された HMAC-SHA256 暗号化署名が含まれます。

共有アクセス承認ポリシー

各 Service Bus 名前空間と各 Service Bus エンティティには、規則で構成された共有アクセス承認ポリシーがあります。名前空間レベルのポリシーは、個々のポリシー構成に関係なく、名前空間内のすべてのエンティティに適用されます。

各承認ポリシー規則について、名前、スコープ、および権限という 3 種類の情報を決定します。名前とは、文字どおり名前を表します。そのスコープ内で一意の名前です。スコープは簡単です。対象となるリソースの URI です。 Service Bus 名前空間の場合、スコープは、https://<yournamespace>.servicebus.windows.net/ のような完全修飾名前空間です。

ポリシー規則での権限は、次のものの組み合わせです。

送信 - エンティティにメッセージを送信する権限を許可します
リッスン - 受信 (キュー、サブスクリプション) および関連するすべてのメッセージ処理の権限を許可します
管理 - エンティティの作成や削除をはじめとする、名前空間のトポロジの管理権限を許可します

管理権限には、送信とリッスンの権限が含まれます。

名前空間またはエンティティポリシーは最大 12 個の共有アクセス承認規則を保持でき、基本権限と、送信およびリッスンの組み合わせにそれぞれ対応する、3 つの規則のセットの場所を提供します。この制限はエンティティごとです。つまり、名前空間と各エンティティには最大 12 個の共有アクセス承認規則を含めることができます。この制限は、SAS ポリシーストアがユーザーまたはサービスアカウントストアのためのものではないことを明確に示します。お使いのアプリケーションがユーザー ID またはサービス ID に基づいて Service Bus へのアクセスを許可する必要がある場合は、認証とアクセスチェックの後で SAS トークンを発行するセキュリティトークンサービスを実装する必要があります。

承認規則には、"主キー" と "セカンダリキー" が割り当てられます。これらのキーは暗号化された強力なキーです。これらをなくしたり、外部に漏らしたりしないでください。これらは、常に Azure portal から入手可能です。生成されたキーのいずれかを使用できます。また、いつでも再生成できます。ポリシーのキーを再生成または変更すると、そのキーに基づいてそれまでに発行されたすべてのトークンが、すぐに無効になります。ただし、そのようなトークンを基にして作成された進行中の接続は、トークンの有効期限が切れるまで動作し続けます。

Service Bus の名前空間を作成すると、RootManageSharedAccessKey という名前のポリシー規則が、その名前空間に対して自動的に作成されます。このポリシーには、名前空間全体の管理アクセス許可があります。この規則は管理 root アカウントと同じように扱い、アプリケーションでは使わないようにすることをお勧めします。ポータルの名前空間の [Shared access policies] (共有アクセスポリシー) タブで、または PowerShell か Azure CLI 経由で、さらにポリシー規則を作成できます。

SharedAccessAuthorizationRule オブジェクトで使用されるキーは、定期的に再生成することをお勧めします。ときどきキーをローテーションできるように、主キーとセカンダリキーのスロットが存在します。お使いのアプリケーションが通常は主キーを使っている場合は、主キーをセカンダリキースロットにコピーし、主キーだけを再生成できます。その後、セカンダリスロットの古い主キーを使ってアクセスを続けてきたクライアントアプリケーションに、新しい主キーの値を構成します。すべてのクライアントが更新されたら、セカンダリキーを再生成して、最終的に古い主キーの使用を終了できます。

キーが侵害されたことがはっきりしているか疑わしく、キーを取り消す必要がある場合は、SharedAccessAuthorizationRule の PrimaryKey と SecondaryKey の両方を再生成し、それらを新しいキーに置き換えることができます。この手順により、古いキーで署名されたすべてのトークンが無効になります。

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

アプリケーションで Shared Access Signature を使用する場合は、次の 2 つの潜在的なリスクに注意する必要があります。

SAS が漏えいすると、それを取得した人はだれでも使用できるため、Service Bus リソースが侵害される可能性があります。
クライアントアプリケーションに提供された SAS が期限切れになり、アプリケーションでサービスから新しい SAS を取得できない場合は、アプリケーションの機能が損なわれる可能性があります。

Shared Access Signature の使用に関する次の推奨事項に従うと、これらのリスクの軽減に役立ちます。

必要に応じて、クライアントで SAS が自動的に更新されるようにする:クライアントでは、SAS を提供するサービスを使用できない場合に再試行する時間を考慮して、有効期限までに余裕を持って SAS を更新する必要があります。有効期間内に完了することが予想される短時間で少数の即時操作に SAS が使用される予定の場合は、SAS が更新されることが予測されないため、不要である可能性があります。ただし、クライアントが SAS 経由で日常的に要求を実行する場合は、有効期限に注意が必要になる可能性があります。重要な考慮事項は、SAS の有効期限を短くする必要性 (前述のように) と、(更新が正常に完了する前に SAS の期限が切れることによる中断を避けるために) クライアントで早めに更新を要求する必要性とのバランスです。
SAS の開始時刻に注意する: SAS の開始時刻を [現在] に設定すると、クロックスキュー (コンピューターの違いによる現在時刻の差) により、最初の数分間にエラーが間欠的に発生する場合があります。一般に、開始時刻は 15 分以上前になるように設定します。または、まったく設定せず、すべての場合ですぐに有効になるようにします。同じことが、一般的には有効期限にも適用されます。どの要求でも、前後に最大 15 分のクロックスキューが発生する可能性があることに注意してください。
アクセス先のリソースを具体的に指定する:セキュリティのベストプラクティスは、必要最小限の特権をユーザーに付与することです。ユーザーに必要なのは、1 つのエンティティへの読み取りアクセスだけの場合は、すべてのエンティティへの読み取り/書き込み/削除アクセスではなく、その 1 つのエンティティへの読み取りアクセスだけをユーザーに許可します。攻撃者の手中にある SAS の機能を低下させるため、SAS が侵害された場合に損害を抑えるのにも役立ちます。
場合によっては SAS を使用しない: Service Bus に対する特定の操作に関連するリスクが、SAS の利点を上回ることがあります。このような操作では、ビジネスルールの検証、認証、監査の後に Service Bus に書き込む中間層サービスを作成します。
常に HTTPS を使用する:常に HTTPS を使用して SAS を作成または配布します。 SAS が HTTP 経由で渡され、傍受された場合、中間者攻撃を実行している攻撃者は、SAS を読み取って、意図したユーザーと同様に使用することができます。そのため、機微なデータが侵害されたり、悪意のあるユーザーによるデータ破損が発生したりする可能性があります。

Shared Access Signature 認証の構成

共有アクセス承認ポリシーは、Service Bus の名前空間、キュー、トピックに構成できます。 Service Bus サブスクリプションにおける構成は現在サポートされていませんが、名前空間またはトピックに構成されている規則を使用して、サブスクリプションへのアクセスをセキュリティで保護できます。

いくつかの認可規則を持つ名前空間の例を示す図。

この図では、manageRuleNSsendRuleNS および listenRuleNS の承認規則は、キュー Q1 とトピック T1 の両方に適用されます。それに対し、listenRuleQ および sendRuleQ は、キュー Q1 にのみ適用され、sendRuleT はトピック T1 にのみ適用されます。

Shared Access Signature トークンの生成

承認規則の名前およびその署名キーの 1 つにアクセスできるすべてのクライアントは、SAS トークンを生成できます。次の形式の文字列を作成することで、トークンが生成されます。

SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>

se - トークンの有効期限。エポック 1970 年 1 月 1 日 00:00:00 UTC (UNIX エポック) からトークンの期限が切れるまでの秒数を示す整数。
skn - 承認規則の名前。
sr - アクセスされているリソースの URL でエンコードされた URI。
sig - URL でエンコードされた HMACSHA256 署名。ハッシュ計算は次の擬似コードのようになり、生のバイナリ出力の base64 が返されます。
```
urlencode(base64(hmacsha256(urlencode('https://<yournamespace>.servicebus.windows.net/') + "\n" + '<expiry instant>', '<signing key>')))
```

重要

さまざまなプログラミング言語を使用して SAS トークンを生成する例については、SAS トークンの生成に関する記事を参照してください。

受信側が同じパラメーターでハッシュを再計算して、発行者が有効な署名キーを所有していることを確認できるように、トークンにはハッシュされていない値が含まれています。

リソース URI とは、アクセスが要求される Service Bus リソースの完全な URI です。たとえば、http://<namespace>.servicebus.windows.net/<entityPath> または sb://<namespace>.servicebus.windows.net/<entityPath> (つまり http://contoso.servicebus.windows.net/contosoTopics/T1/Subscriptions/S3) です。

URI はパーセントエンコードになっている必要があります。

署名に使用される共有アクセス承認規則は、この URI、またはその階層の親のいずれかで指定したエンティティに構成する必要があります。たとえば、前の例では、http://contoso.servicebus.windows.net/contosoTopics/T1 または http://contoso.servicebus.windows.net となります。

SAS トークンは、signature-string で使われている <resourceURI> がプレフィックスになっているすべてのリソースで有効です。

キーの再生成

共有アクセス承認ポリシーで使用されるキーは、定期的に再生成することをお勧めします。ときどきキーをローテーションできるように、主キーとセカンダリキーのスロットが存在します。お使いのアプリケーションが通常は主キーを使っている場合は、主キーをセカンダリキースロットにコピーし、主キーだけを再生成できます。その後、セカンダリスロットの古い主キーを使ってアクセスを続けてきたクライアントアプリケーションに、新しい主キーの値を構成します。すべてのクライアントが更新されたら、セカンダリキーを再生成して、最終的に古い主キーの使用を終了できます。

キーが侵害されたことがはっきりしているか疑わしく、キーを取り消す必要がある場合は、共有アクセス承認の主キーとセカンダリキーの両方を再生成し、それらを新しいキーに置き換えることができます。この手順により、古いキーで署名されたすべてのトークンが無効になります。

Azure portal でプライマリキーとセカンダリキーを再生成するには、次の手順のようにします。

Azure portal で Service Bus の名前空間に移動します。
左側のメニューで、[共有アクセスポリシー] を選びます。
一覧からポリシーを選択します。次の例では、RootManageSharedAccessKey が選ばれています。
主キーを再生成するには、[SAS ポリシー: RootManageSharedAccessKey] ページで、コマンドバーの [主キーの再生成] を選択します。
セカンダリキーを再生成するには、[SAS ポリシー: RootManageSharedAccessKey] ページで、コマンドバーの [...] を選択し、次に [セカンダリキーの再生成] を選択します。

Azure PowerShell を使用する場合は、New-AzServiceBusKey コマンドレットを使用して、Service Bus 名前空間の主およびセカンダリキーを再生成します。 -KeyValue パラメーターを使うことで、生成されるプライマリとセカンダリのキーの値を指定することもできます。

Azure CLI を使用する場合は、az servicebus namespace authorization-rule keys renew コマンドを使用して、Service Bus名前空間の主およびセカンダリキーを再生成します。 --key-value パラメーターを使うことで、生成されるプライマリとセカンダリのキーの値を指定することもできます。

Service Bus による Shared Access Signature 認証

以下で説明するシナリオには、承認規則の構成、SAS トークンの生成、クライアントの承認などが含まれます。

構成を説明して SAS 承認を使用する、Service Bus アプリケーションのサンプルについては、Service Bus による Shared Access Signature 認証に関するページを参照してください。

エンティティの共有アクセス承認規則へのアクセス

Service Bus が対応する共有アクセス商品規則にアクセスまたは更新するには、管理ライブラリのキューまたはトピックに対して get/update 操作を使用します。これらのライブラリを使用してキューまたはトピックを作成するときに、規則を追加することもできます。

Shared Access Signature 承認の使用

.NET、Java、JavaScript、Python などの公式にサポートされている任意の言語で Service Bus SDK を使用するアプリケーションは、クライアントコンストラクターに渡される接続文字列経由で SAS 承認を利用できます。

接続文字列には、規則名 (SharedAccessKeyName) と規則キー (SharedAccessKey) または以前に発行されたトークン (SharedAccessSignature) を含めることができます。接続文字列を受け付けるコンストラクターまたはファクトリメソッドに渡される接続文字列にこれらが存在する場合、SAS トークンプロバイダーが自動的に作成されて設定されます。

Service Bus サブスクリプションで SAS 承認を使用するには、Service Bus 名前空間またはトピックに構成されている SAS キーを使用できます。

Shared Access Signature の使用 (HTTP レベル)

Service Bus ですべてのエンティティの Shared Access Signature を作成する方法を理解したので、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

この方法は、すべての機能に対して利用できます。キュー、トピック、またはサブスクリプションに対して SAS を作成できます。

送信者またはクライアントに SAS トークンを付与する場合は、送信者またはクライアントはキーを直接保持しないため、キーを取得するハッシュを反転できません。そのため、管理者は、送信者またはクライアントがアクセスできる対象とアクセスする期間を制御できます。重要なのは、ポリシーのプライマリキーを変更する場合は、ポリシーから作成された Shared Access Signature がすべて無効になるということです。

Shared Access Signature の使用 (AMQP レベル)

前のセクションでは、データを Service Bus に送信するために、HTTP POST 要求を使用して SAS トークンを使用する方法について説明しました。ご存じのように、Service Bus へのアクセスには、AMQP (Advanced Message Queuing Protocol) を使用できます。AMQP は、多くのシナリオでパフォーマンス上の理由から好まれているプロトコルです。 SAS トークンと AMQP の併用については、AMQP Claim-Based Security Version 1.0 のドキュメントを参照してください。このドキュメントは、2013 年から執筆されているドラフトですが、現在も Azure でサポートされています。

Service Bus へのデータ送信を開始する前に、発行元から適切に定義された $cbs という AMQP ノードに対して、AMQP メッセージ内で SAS トークンを送信する必要があります (すべての SAS トークンを取得して検証するためにサービスで使用される "特別な" キューと考えることができます)。発行元は、AMQP メッセージ内で ReplyTo フィールドを指定する必要があります。これは、サービスから発行元に対してトークンの検証結果を返信するノードです (発行元とサービス間の簡単な要求/応答のパターン)。この応答ノードは、AMQP 1.0 仕様に記載されているように、"リモートノードの動的作成" について話すことで "その場で" 作成されます。発行元は SAS トークンが有効であることを確認した後に、次の処理に進み、サービスに対してデータを送信できるようになります。

次の手順は、AMQP.NET Lite ライブラリを使用して、AMQP プロトコルで SAS トークンを送信する方法を示しています。これは、C# で開発する公式の Service Bus SDK (WinRT、.NET Compact Framework、.NET Micro Framework、Mono など) を使用できない場合に便利です。 HTTP レベル ("Authorization" ヘッダー内で送信される HTTP POST 要求と SAS トークン) の場合と同様に、要求ベースのセキュリティが AMQP レベルでどのように機能するかを理解するためにも、このライブラリは役立ちます。 AMQP に関してこのような深い知識が必要ない場合は、自動実行する公式の Service Bus SDK をサポートされている任意の言語 (.NET、Java、JavaScript、Python、Go など) で使用できます。

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 might be kept open for refreshing tokens
    cbsSender.Close();
    cbsReceiver.Close();
    session.Close();

    return result;
}

PutCbsToken() メソッドは、サービスに対する TCP 接続を表す PutCbsToken() (AMQP .NET Lite ライブラリに用意されている AMQP Connection クラスインスタンス) と、送信する SAS トークンである sasToken パラメーターを受け取ります。

注意

(SAS トークンを送信する必要がないときに使用されるユーザー名とパスワードを含む既定の PLAIN ではなく) ANONYMOUS に設定された SASL 認証メカニズム を使用して、接続が作成されている点に注意してください。

次に、発行元は、SAS トークンの送信とサービスからの応答 (トークンの検証結果) の受信に使用される 2 つの AMQP リンクを作成します。

AMQP メッセージには一連のプロパティと、簡単なメッセージより多くの情報が含まれています。 SAS トークンはメッセージの本文です (コンストラクターを使用)。 "ReplyTo" プロパティは、受信側リンクで検証結果を受信するノード名に設定されます (必要に応じて名前を変更できます。名前はサービスで自動的に作成されます)。最後の 3 つの application/custom プロパティは、実行する必要がある操作の種類を示すためにサービスで使用されます。 CBS ドラフト仕様に記載されているように、操作名 ("put-token")、トークンの種類 (この例では、servicebus.windows.net:sastoken)、およびトークンを適用するオーディエンスの "名前" (エンティティ全体) を設定する必要があります。

発行元は、送信側リンクで SAS トークンを送信した後に、受信側リンクの応答を読み取る必要があります。応答は、"status-code" というアプリケーションプロパティを含む簡単な AMQP メッセージです。このプロパティには、HTTP 状態コードと同じ値を含めることができます。

Service Bus の操作に必要な権限

次の表に、Service Bus のリソースでのさまざまな操作に必要となるアクセス権を示します。

操作	必要な要求	要求のスコープ
Namespace
名前空間での承認規則を構成する	管理する	任意の名前空間アドレス
サービスレジストリ
プライベートポリシーを列挙する	管理する	任意の名前空間アドレス
名前空間でリッスンを開始する	リッスン	任意の名前空間アドレス
名前空間のリスナーにメッセージを送信する	Send	任意の名前空間アドレス
キュー
キューを作成する	管理する	任意の名前空間アドレス
キューを削除する	管理する	任意の有効なキューアドレス
キューを列挙する	管理する	/$Resources/Queues
キューの説明を取得する	管理する	任意の有効なキューアドレス
キューの承認規則を構成する	管理する	任意の有効なキューアドレス
キューに送信する	Send	任意の有効なキューアドレス
キューからメッセージを受信する	リッスン	任意の有効なキューアドレス
ピークロックモードでメッセージを受信した後にそのメッセージを破棄または終了する	リッスン	任意の有効なキューアドレス
後で取得するためにメッセージを保留する	リッスン	任意の有効なキューアドレス
メッセージを配信不能にする	リッスン	任意の有効なキューアドレス
メッセージのキューセッションに関連付けられた状態を取得する	リッスン	任意の有効なキューアドレス
メッセージのキューセッションに関連付けられた状態を設定する	リッスン	任意の有効なキューアドレス
後のデリバリー向けにメッセージをスケジュールする	リッスン	任意の有効なキューアドレス
トピック
トピックを作成する	管理する	任意の名前空間アドレス
トピックを削除する	管理する	任意の有効なトピックアドレス
トピックを列挙する	管理する	/$Resources/Topics
トピックの説明を取得する	管理する	任意の有効なトピックアドレス
トピックの承認規則を構成する	管理する	任意の有効なトピックアドレス
トピックに送信する	Send	任意の有効なトピックアドレス
サブスクリプション
サブスクリプションの作成	管理する	任意の名前空間アドレス
サブスクリプションを削除する	管理する	../myTopic/Subscriptions/mySubscription
サブスクリプションを列挙する	管理する	../myTopic/Subscriptions
サブスクリプションの説明を取得する	管理する	../myTopic/Subscriptions/mySubscription
ピークロックモードでメッセージを受信した後にそのメッセージを破棄または終了する	リッスン	../myTopic/Subscriptions/mySubscription
後で取得するためにメッセージを保留する	リッスン	../myTopic/Subscriptions/mySubscription
メッセージを配信不能にする	リッスン	../myTopic/Subscriptions/mySubscription
トピックセッションに関連付けられた状態を取得する	リッスン	../myTopic/Subscriptions/mySubscription
トピックセッションに関連付けられた状態を設定する	リッスン	../myTopic/Subscriptions/mySubscription
ルール
規則を作成する	リッスン	../myTopic/Subscriptions/mySubscription
規則を削除する	リッスン	../myTopic/Subscriptions/mySubscription
規則を列挙する	管理またはリッスン	../myTopic/Subscriptions/mySubscription/Rules

次のステップ

Service Bus メッセージングの詳細については、次のトピックをご覧ください。

次の方法で共有

Shared Access Signature による Service Bus のアクセスの制御

SAS の概要

共有アクセス承認ポリシー

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

Shared Access Signature 認証の構成

Shared Access Signature トークンの生成

キーの再生成

Service Bus による Shared Access Signature 認証

エンティティの共有アクセス承認規則へのアクセス

Shared Access Signature 承認の使用

Shared Access Signature の使用 (HTTP レベル)

Shared Access Signature の使用 (AMQP レベル)

C#

Service Bus の操作に必要な権限

次のステップ

フィードバック

その他のリソース

次の方法で共有

Shared Access Signature による Service Bus のアクセスの制御

SAS の概要

共有アクセス承認ポリシー

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

Shared Access Signature 認証の構成

Shared Access Signature トークンの生成

キーの再生成

Service Bus による Shared Access Signature 認証

エンティティの共有アクセス承認規則へのアクセス

Shared Access Signature 承認の使用

Shared Access Signature の使用 (HTTP レベル)

Shared Access Signature の使用 (AMQP レベル)

C#

Service Bus の操作に必要な権限

次のステップ

フィードバック

その他のリソース

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