Shared Access Signature を使用する Event Hubs リソースへのアクセスの承認

Shared Access Signature (SAS) では、Event Hubs 名前空間のリソースへの制限付きアクセスを許可する方法が提供されます。 SAS では、承認規則に基づいて Event Hubs リソースへのアクセスが保護されます。 これらの規則は、名前空間、またはイベント ハブのいずれかで構成されます。 この記事では、SAS モデルの概要を提供し、SAS のベスト プラクティスを確認します。

Shared Access Signature とは

Shared Access Signature (SAS) では、承認規則に基づいて Event Hubs リソースへの委任アクセスが提供されます。 承認規則は、名前を持ち、特定の権限に関連付けられており、暗号化キーのペアを保持しています。 Event Hubs クライアントから、または独自のコードで、規則の名前とキーを使用して、SAS トークンを生成します。 その後、クライアントではトークンを Event Hubs に渡して、要求された操作の承認を証明することができます。

SAS は、シンプルなトークンを使用する要求ベースの承認メカニズムです。 SAS を使うと、ネットワーク経由でキーが渡されることがなくなります。 キーは、後でサービスによって検証が可能な情報に暗号で署名するために使われます。 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 portal から入手可能です。 生成されたキーのいずれかを使用できます。また、いつでも再生成できます。 ポリシーのキーを再生成または変更すると、そのキーに基づいてそれまでに発行されたすべてのトークンが、すぐに無効になります。 ただし、そのようなトークンを基にして作成された進行中の接続は、トークンの有効期限が切れるまで動作し続けます。

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

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

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

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

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

• 必要に応じて、クライアントで SAS が自動的に更新されるようにする:クライアントでは、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 を読み取って、宛先のユーザーと同様に使用することができます。このため、機密データの安全性が損なわれたり、悪意のあるユーザーによるデータ破損が発生したりする可能性があります。

まとめ

Shared Access Signature は、クライアントに Event Hubs リソースへの制限付きアクセス許可を提供するのに有用です。 これらは、Azure Event Hubs を使用するあらゆるアプリケーションのセキュリティ モデルの重要な部分です。 この記事に示したベスト プラクティスに従うと、SAS を使用して、アプリケーションのセキュリティを損なうことなく、リソースへのアクセスの柔軟性を高めることができます。

関連するコンテンツ

次の関連記事を参照してください。

• Shared Access Signature を使用して Azure Event Hubs に対する要求を認証する
• Microsoft Entra ID を使用してアプリケーションから Azure Event Hubs への要求を認証する
• Microsoft Entra ID を使って Event Hubs リソースにアクセスするためのマネージド ID を認証する