Shared Access Signature (SAS) は、Event Hubs 名前空間内のリソースへの制限付きアクセスを許可する方法を提供します。 SAS では、承認規則に基づいて Event Hubs リソースへのアクセスが保護されます。 これらの規則は、名前空間またはイベント ハブで構成します。 この記事では、SAS モデルの概要を説明し、SAS のベスト プラクティスを確認します。
注意
この記事では、SAS を使用する Event Hubs リソースへのアクセスの承認について説明します。 SAS を使用する Event Hubs リソースへのアクセスの認証については、SAS を使用した認証に関する記事を参照してください。
Shared Access Signature とは
Shared Access Signature (SAS) では、承認規則に基づいて Event Hubs リソースへの委任アクセスが提供されます。 承認規則は、名前を持ち、特定の権限に関連付けられており、暗号化キーのペアを保持しています。 ルールの名前とキーを Event Hubs クライアントまたは独自のコードで使用して SAS トークンを生成します。 その後、クライアントではトークンを Event Hubs に渡して、要求された操作の承認を証明することができます。
SAS は、単純なトークンを使用するクレーム ベースの承認メカニズムです。 SAS を使用する場合、ネットワーク上でキーを渡すことはありません。 代わりに、キーを使用して、サービスが後で検証できる情報に暗号で署名します。 クライアントが承認規則名と一致するキーをすぐに所有しているユーザー名とパスワードスキームに似た SAS を使用できます。 また、フェデレーション セキュリティ モデルと同様の SAS を使用することもできます。クライアントは、署名キーを所有することなく、セキュリティ トークン サービスから期限付きの署名付きアクセス トークンを受け取ります。
注意
Azure Event Hubsでは、Microsoft Entra IDを使用した Event Hubs リソースへの承認もサポートされています。 Microsoft Entra IDによって返される OAuth 2.0 トークンを使用してユーザーまたはアプリケーションを承認すると、Shared Access Signature (SAS) よりも優れたセキュリティと使いやすさが提供されます。 Microsoft Entra IDを使用することで、コードにトークンを格納する必要がなく、潜在的なセキュリティの脆弱性を危険にさらす必要はありません。
Microsoft では、可能な場合は、Azure Event Hubs アプリケーションで Microsoft Entra ID を使用することをお勧めします。 詳細については、「Authorize access to Azure Event Hubs resource using Microsoft Entra ID」 (Microsoft Entra ID を使用して Event Hubs リソースへのアクセスを承認する) を参照してください。
重要
SAS トークンは、リソースを保護するために不可欠です。 詳細な設定が可能で、SAS ではクライアントに Event Hubs リソースへのアクセス権が付与されます。 パブリックに共有しないでください。 トラブルシューティングの理由で必要な場合は、共有する場合は、ログ ファイルの縮小バージョンを使用するか、SAS トークン (存在する場合) をログ ファイルから削除することを検討してください。 スクリーンショットに SAS 情報も含まれていないことを確認します。
共有アクセス承認ポリシー
各 Event Hubs 名前空間と各 Event Hubs エンティティ (イベント ハブまたは Kafka トピック) には、規則で構成される共有アクセス承認ポリシーがあります。 名前空間レベルのポリシーは、個々のポリシー構成に関係なく、名前空間内のすべてのエンティティに適用されます。
各承認ポリシー規則について、名前、スコープ、および権限という 3 つの情報を決定します。 名前は、そのスコープ内の一意の名前です。 スコープは、対象となるリソースの URI です。 Event Hubs 名前空間の場合、スコープは、https://<yournamespace>.servicebus.windows.net/ のような完全修飾ドメイン名 (FQDN) です。
ポリシー規則によって提供される権限では、次のものを組み合わせることができます。
- 送信 – エンティティにメッセージを送信する権限を付与します
- リッスン – エンティティからのメッセージをリッスンまたは受信する権限を付与します
- 管理 – エンティティの作成と削除を含む、名前空間のトポロジを管理する権限を付与します 管理権限には、送信とリッスンの権限が含まれます。
名前空間ポリシーまたはエンティティ ポリシーでは最大 12 個の共有アクセス承認規則を保持でき、それぞれが基本権限、送信とリッスンの組み合わせをカバーする、3 つの規則セットに対応できます。 この制限は、SAS ポリシー ストアがユーザーまたはサービス アカウント ストアのためのものではないことを明確に示します。 ご利用のアプリケーションで、ユーザー ID またはサービス ID に基づいて Event Hubs リソースへのアクセスを許可する必要がある場合は、認証とアクセス チェックの後で SAS トークンを発行するセキュリティ トークン サービスを実装する必要があります。
承認規則には、主キーとセカンダリ キーが割り当てられます。 これらのキーは暗号化された強力なキーです。 これらをなくしたり、外部に漏らしたりしないでください。 これらは常にAzure ポータルで使用できます。 生成されたキーのいずれかを使用できます。また、いつでも再生成できます。 ポリシーのキーを再生成または変更すると、そのキーに基づいてそれまでに発行されたすべてのトークンが、すぐに無効になります。 ただし、そのようなトークンを基にして作成された進行中の接続は、トークンの有効期限が切れるまで動作し続けます。
Event Hubs 名前空間を作成すると、RootManageSharedAccessKey という名前のポリシー規則が、その名前空間に対して自動的に作成されます。 このポリシーには、名前空間全体の管理アクセス許可があります。 この規則は管理ルート アカウントと同様に扱い、アプリケーションでは使用しないでください。 ポータル、PowerShell、または Azure CLI を使用して、名前空間の Configure タブでさらにポリシー ルールを作成できます。
SAS を使用する際のベスト プラクティス
アプリケーションで Shared Access Signature を使用する場合は、次の 2 つの潜在的なリスクに注意してください。
- SAS がリークした場合、取得したユーザーはだれでもそれを使用でき、Event Hubs リソースが侵害される可能性があります。
- クライアント アプリケーションに提供された SAS の有効期限が切れ、アプリケーションがサービスから新しい SAS を取得できない場合、アプリケーションの機能が妨げられる可能性があります。
Shared Access Signature の使用に関する次の推奨事項に従うと、これらのリスクの軽減に役立ちます。
- 必要に応じてクライアントに SAS を自動的に更新させます。クライアントは、SAS を提供するサービスが使用できない場合に再試行する時間を許可するために、有効期限の前に SAS を更新する必要があります。 SAS が、有効期限内に完了することが予想される短期間の少数の操作を対象とする場合は、更新が不要になる可能性があります。 ただし、SAS 経由で定期的に要求を行うクライアントがある場合は、有効期限が切れる可能性があります。 重要な考慮事項は、(前述のように) SAS の有効期間が短い必要性と、クライアントが更新を十分に早く要求する必要性 (更新が成功する前に SAS の有効期限が切れる原因による中断を避けるため) のバランスを取るということです。
- SAS の開始時刻に注意してください。SAS の開始時刻を 現在に設定した場合、クロック スキュー (異なるマシンによる現在の時刻の違い) が原因で、最初の数分間、エラーが断続的に発生する可能性があります。 開始時刻は通常、少なくとも15分過去に設定してください。 または、まったく設定しないでください。これにより、すべてのケースですぐに有効になります。 同じことが、一般的には有効期限にも適用されます。 どの要求でも、最大 15 分のクロック スキューが前後に発生する可能性があることに注意してください。
- アクセスするリソースを特定する: セキュリティのベスト プラクティスは、必要最小限の特権をユーザーに提供することです。 ユーザーが 1 つのエンティティへの読み取りアクセス権のみを必要とする場合は、すべてのエンティティへの読み取り、書き込み、または削除アクセス権ではなく、その 1 つのエンティティへの読み取りアクセス権をユーザーに付与します。 この方法は、SAS が攻撃者の手に与える能力が少ないため、SAS が侵害された場合の損害を軽減するのにも役立ちます。
- 常に SAS を使用しない: Event Hubs に対する特定の操作に関連するリスクが、SAS の利点を上回る場合があります。 このような操作には、ビジネス ルールの検証、認証、および監査の後にイベント ハブに書き込む中間層サービスを作成します。
- 常に HTTPS を使用する: 常に HTTPS を使用して SAS を作成または配布します。 SAS が HTTP 経由で渡されて傍受された場合、中間者攻撃を実行している攻撃者は SAS を読み取り、意図したユーザーと同じように SAS を使用し、機密データを侵害したり、悪意のあるユーザーによるデータ破損を許容したりする可能性があります。
まとめ
Shared Access Signature は、Event Hubs リソースへの制限付きアクセス許可をクライアントに提供する場合に役立ちます。 これらは、Azure Event Hubsを使用するすべてのアプリケーションのセキュリティ モデルの重要な部分です。 この記事に示したベスト プラクティスに従うと、SAS を使用して、アプリケーションのセキュリティを損なうことなく、リソースへのアクセスの柔軟性を高めることができます。
関連するコンテンツ
次の関連記事を参照してください。