条件とカスタム セキュリティ属性を使用して Azure ロールの割り当ての管理をスケーリングする

Azure ロールベースのアクセス制御 (Azure RBAC) には、サブスクリプションごとのロール割り当ての制限があります。 数百、数千単位の Azure ロールの割り当てを作成する必要がある場合、この上限に達する可能性があります。 数百または数千のロールの割り当てを管理するのは困難な可能性があります。 シナリオによっては、ロールの割り当ての数を減らして、アクセスの管理を容易にできる場合があります。

この記事では、Azure 属性ベースのアクセス制御 (Azure ABAC) 条件と Microsoft Entra カスタムセキュリティ属性をプリンシパルに使って、ロール割り当ての管理をスケーリングするソリューションについて説明します。

シナリオ例

数千人の顧客を擁する Contoso という会社が、次のような構成を設定したいと考えているとします。

• セキュリティとパフォーマンス上の理由から、顧客データを 128 個のストレージ アカウントに分散させる。
• 各ストレージ アカウントに 2,000 個のコンテナーを追加し、各顧客用のコンテナーを用意する。
• 各顧客を一意の Microsoft Entra サービス プリンシパルで表します。
• 各顧客に対して、自分のコンテナー内のオブジェクトへのアクセスを許可し、他のコンテナーへのアクセスは許可しない。

この構成にする場合、1 つのサブスクリプションに 256,000 個のストレージ BLOB データ所有者ロールの割り当てが必要になる可能性があります。これは、ロールの割り当ての制限をはるかに超えています。 ロールの割り当てがこれほど多くなると、保守するのは不可能ではないにしても困難です。

ソリューションの例

このシナリオを保守しやすい方法で処理する方法は、ロールの割り当て条件を使うことです。 次の図は、条件を使って 256,000 個のロールの割り当てを 1 つのロールの割り当てに減らすソリューションを示しています。 このロールの割り当ては、上位のリソース グループのスコープにあり、条件を使ってコンテナーへのアクセスを制御できます。 条件を使うと、コンテナー名が顧客のサービス プリンシパルのカスタム セキュリティ属性と一致するかどうかを確認できます。

このソリューションが機能する条件の式を次に示します。

  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name]
  StringEquals
  @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]

完成した条件は次のようになります。 アクションの一覧は、必要なアクションだけに調整できます。

(
 (
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/modifyPermissions/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/permanentDelete/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write'})
 )
 OR 
 (
  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name] StringEquals @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]
 )
)

このソリューションを使う理由

データ プレーン リソースへのアクセス権を付与するために使用できるアクセス制御メカニズムはいくつかあります。

アクセス キーは、データ プレーン リソースへのアクセス権を付与する一般的な方法です。 アクセス キーを使って、そのアクセス キーを持っているユーザーに読み取り、書き込み、削除のアクセス許可を付与できます。 これは、攻撃者がアクセス キーを入手できれば、機密データにアクセスできることを意味します。 アクセス キーには ID バインディングがなく、有効期限もなく、格納するのにセキュリティ上のリスクがあります。

アクセス キーと同様に、Shared Access Signature (SAS) トークンには ID バインディングがありませんが、定期的に有効期限が切れます。 ID バインディングがないので、アクセス キーと同様のセキュリティ リスクがあります。 クライアントにエラーが発生しないように有効期限を管理する必要があります。 SAS トークンは、日々の管理と運用のために追加のコードが必要であり、DevOps チームにとって大きなオーバーヘッドになる可能性があります。

Azure RBAC には、一元化されたきめ細かなアクセス制御が用意されています。 Azure RBAC には、セキュリティ リスクを軽減する ID バインディングがあります。 条件を使うと、ロールの割り当て管理をスケーリングできます。また、アクセスは柔軟で動的な属性に基づいているため、アクセス制御の保守が容易になります。

このソリューションの利点をいくつか紹介します。

• 一元化されたアクセス制御
• 保守が容易
• アクセス キーまたは SAS トークンに依存しない
• オブジェクトごとにアクセスを管理する必要がない
• セキュリティ体制を向上させることができる

このソリューションを使用できるか

同様のシナリオがある場合は、次の手順に従って、このソリューションを使用できる可能性があるかどうかを確認してください。

手順 1: 前提条件を満たしているかどうかを判断する

このソリューションを使うには、以下が必要です。

• BLOB ストレージ データ アクションを持つ、複数の組み込みまたはカスタムのロールの割り当て。 これらには、次の組み込みロールが含まれます。

  • ストレージ BLOB データ共同作成者
  • ストレージ BLOB データ所有者
  • ストレージ BLOB データ閲覧者

手順 2: 条件に使用できる属性を特定する

条件に使用できる属性は、次のようにいくつかあります。

• コンテナー名
• BLOB パス
• Blob index tags [Keys] (BLOB インデックス タグ [キー])
• Blob index tags [Values in key] (BLOB インデックス タグ [キー内の値])

また、ユーザー、エンタープライズ アプリケーション、マネージド ID に対して、独自のカスタム セキュリティ属性を定義することもできます。

詳細については、「Azure ロールの割り当て条件の形式と構文」と「Microsoft Entra ID のカスタム セキュリティ属性とは」を参照してください。

手順 3: 上位のスコープで条件を作成する

上位のスコープで条件を使ってアクセスを管理するロールの割り当てを 1 つ以上作成します。 詳細については、「Azure portal で Azure ロール割り当ての条件を追加または編集する」を参照してください。

次のステップ

• Azure の属性ベースのアクセス制御 (Azure ABAC) とは
• Microsoft Entra ID のカスタム セキュリティ属性とは
• タグとカスタム セキュリティ属性に基づいて BLOB への読み取りアクセスを許可する (プレビュー)