Azure 属性ベースのアクセス制御 (Azure ABAC) を使用してリソースを完全にセキュリティで保護するには、Azure ロールの割り当て条件で使用される属性も保護する必要があります。 たとえば、条件がファイル パスに基づいている場合、プリンシパルにファイル パスの名前を変更するための無制限のアクセス許可がある場合、アクセスが侵害される可能性があります。
この記事では、ロールの割り当て条件を考慮する必要があるセキュリティに関する考慮事項について説明します。
重要
Azure 属性ベースのアクセス制御 (Azure ABAC) は、ストレージ アカウントの Standard と Premium 両方のパフォーマンス レベルで、request、resource、environment、principal を使用して Azure Blob Storage、Azure Data Lake Storage Gen2、Azure キューへのアクセスを制御するために一般提供 (GA) されています。 現在、コンテナー メタデータ リソース属性とリスト BLOB インクルード要求属性はプレビュー段階です。 Azure Storage の ABAC の完全な機能状態情報については、「Azure Storage の条件機能の状態」を参照してください。
ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用される法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。
その他の承認メカニズムの使用
ロールの割り当て条件は、承認に Azure RBAC を使用する場合にのみ評価されます。 代替承認方法を使用してアクセスを許可する場合は、次の条件をバイパスできます。
- 共有キーの 承認
- アカウント共有アクセス署名 (SAS)
- サービス SAS。
同様に、階層型名前空間 (HNS) を持つストレージ アカウントでアクセス制御リスト (ACL) を使用してアクセスが許可されている場合、条件は評価されません。
ストレージ アカウントの共有キー承認を無効にすると、共有キー、アカウント レベルの SAS、およびサービス レベルの SAS 承認を 防ぐことができます。 ユーザー委任 SAS は Azure RBAC に依存するため、この承認方法を使用するとロールの割り当て条件が評価されます。
条件で使用されるストレージ属性のセキュリティ保護
BLOB パス
条件の @Resource 属性として BLOB パスを使用する場合は、階層型名前空間を持つアカウントを使用するときに、ユーザーが BLOB の名前を変更してファイルにアクセスできないようにする必要もあります。 たとえば、BLOB パスに基づいて条件を作成する場合は、ユーザーのアクセスを次のアクションに制限する必要もあります。
| アクション | 説明 |
|---|---|
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action |
このアクションを使用すると、パス作成 API を使用してファイルの名前を変更できます。 |
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action |
このアクションにより、さまざまなファイル システムおよびパス操作にアクセスできます。 |
BLOB インデックス タグ
BLOB インデックス タグ は、ストレージ内の条件の自由形式の属性として使用されます。 これらのタグを使用してアクセス条件を作成する場合は、タグ自体も保護する必要があります。 具体的には、 Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write DataAction を使用すると、ユーザーはストレージ オブジェクトのタグを変更できます。 このアクションを制限して、ユーザーがタグ キーまたは値を操作して未承認のオブジェクトにアクセスできないようにすることができます。
さらに、条件で BLOB インデックス タグが使用されている場合、データと関連するインデックス タグが個別の操作で更新されると、データが脆弱になる可能性があります。 BLOB 書き込み操作で @Request 条件を使用して、同じ更新操作でインデックス タグを設定するように要求できます。 このアプローチは、ストレージに書き込まれた瞬間からデータをセキュリティで保護するのに役立ちます。
コピーされた BLOB でのタグ
デフォルトでは、Copy Blob API またはそのバリアントを使用する場合、BLOBインデックスタグはソース BLOB から宛先の BLOB にコピーされません。 コピー時に BLOB のアクセススコープを保持するには、タグもコピーする必要があります。
スナップショットのタグ
BLOB スナップショットのタグは変更できません。 そのため、スナップショットを作成する前に、BLOB のタグを更新する必要があります。 ベース BLOB のタグを変更した場合、スナップショット上のタグは引き続き以前の値になります。
スナップショットの作成後にベース BLOB のタグが変更された場合、ベース BLOB とスナップショットに対してアクセスのスコープが異なる場合があります。
BLOB バージョンでのタグ
PUT BLOB、Put Block List、または Copy BLOB API を使用して BLOB バージョンが作成された場合、BLOB インデックス タグはコピーされません。 これらの API のヘッダーを使用してタグを指定できます。
タグは、現在のベース BLOB と各 BLOB バージョンで個別に設定できます。 ベース BLOB のタグを変更しても、以前のバージョンのタグは更新されません。 タグを使用して BLOB とそのすべてのバージョンのアクセススコープを変更する場合は、各バージョンのタグを更新する必要があります。
バージョンとスナップショットのクエリとフィルター処理の制限事項
タグを使用してコンテナー内の BLOB のクエリとフィルター処理を行う場合、応答にはベース BLOB のみが含まれます。 要求されたキーと値を含む BLOB のバージョンまたはスナップショットは含まれません。
ロールとアクセス許可
Azure 組み込みロールにロールの割り当て条件を使用している場合は、ロールがプリンシパルに付与するすべてのアクセス許可を慎重に確認する必要があります。
継承されたロールの割り当て
ロールの割り当ては、管理グループ、サブスクリプション、リソース グループ、ストレージ アカウント、またはコンテナーに対して構成でき、指定された順序で各レベルで継承されます。 Azure RBAC には追加モデルがあるため、有効なアクセス許可は各レベルでのロールの割り当ての合計です。 プリンシパルに複数のロールの割り当てによって同じアクセス許可が割り当てられている場合、そのアクセス許可を使用する操作のアクセスは、各レベルの割り当てごとに個別に評価されます。
条件はロールの割り当ての条件として実装されるため、無条件ロールの割り当てにより、ユーザーは条件をバイパスできます。 たとえば、ストレージ アカウントとサブスクリプションのユーザーに ストレージ BLOB データ共同作成者 ロールを割り当て、ストレージ アカウントの割り当てにのみ条件を追加するとします。 その結果、ユーザーはサブスクリプション レベルでロールの割り当てを通じてストレージ アカウントに無制限にアクセスできます。
そのため、リソース階層全体のすべてのロールの割り当てに条件を一貫して適用する必要があります。
その他の考慮事項
BLOB を書き込む条件操作
BLOB を書き込む多くの操作には、 Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write または Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action のアクセス許可が必要です。
ストレージ BLOB データ所有者やストレージ BLOB データ共同作成者などの組み込みロールは、両方のアクセス許可をセキュリティ プリンシパルに付与します。
これらのロールに対してロールの割り当て条件を定義する場合は、両方のアクセス許可で同じ条件を使用して、書き込み操作の一貫性のあるアクセス制限を確保する必要があります。
Copy Blob と Copy Blob From URL の動作
BLOB のコピー操作と URL からの BLOB のコピー操作では、@Request アクションの属性として BLOB パスを使用する条件をMicrosoft.Storage/storageAccounts/blobServices/containers/blobs/tags/writeし、そのサブ操作は宛先 BLOB に対してのみ評価されます。
ソース BLOB の条件の場合、@Resource アクションのMicrosoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read条件が評価されます。