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 はフェデレーション セキュリティ モデルと同様に使用でき、その場合、クライアントは時間制限のある署名されたアクセス トークンをセキュリティ トークン サービスから受け取り、署名キーを所有することはありません。

注意

Azure Event Hubs では、Azure Active Directory (Azure AD) を使用した Event Hubs リソースに対する承認がサポートされます。 Azure AD によって返された OAuth 2.0 トークンを使用するユーザーまたはアプリケーションの承認では、Shared Access Signatures (SAS) よりも優れたセキュリティが提供され、使いやすくなります。 Azure AD を使用すれば、コードにトークンを格納する必要がなく、潜在的なセキュリティ脆弱性のリスクはありません。

Microsoft では、可能な場合は、Azure Event Hubs アプリケーションで Azure AD を使用することをお勧めします。 詳細については、「Authorize access to Azure Event Hubs resource using Azure Active Directory」 (Azure Active Directory を使用して Event Hubs リソースへのアクセスを承認する) を参照してください。

重要

SAS (Shared Access Signature) トークンは、リソースを保護するために重要です。 詳細な設定が可能で、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 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 の利点を上回ることがあります。 このような操作では、ビジネス ルールの検証、認証、および監査の後に Event Hubs に書き込む中間層サービスを作成します。
  • 常に HTTPS を使用する:常に HTTPS を使用して SAS を作成または配布します。 SAS が HTTP 経由で渡され、傍受された場合、中間者攻撃を実行している攻撃者は、SAS を読み取って、意図したユーザーと同様に使用することができます。そのため、機微なデータが侵害されたり、悪意のあるユーザーによるデータ破損が発生したりする可能性があります。

まとめ

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

次のステップ

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