Azure Storage AccountでABACの使い方検討
はじめに
長らくプレビューだった、Azure StorageのABACがGAされました。（2022/10）
対象となるのは、一部のサービスのみのようなのですがこれでも十分に使い道はありそうです。ということで今回は、使いどころを考えてました。
ABAC vs RBAC
RBACとは
「ロールベースのアクセス制御（Role Base Access Control＝RBAC）」というのがAzureの権限管理の基本です。以前下記の記事でまとめたことがありますが、ポイントは2点あります。
- Azureのアクセス権は、誰が（プリンシパル）×どこに（スコープ）×何をできる（ロール）の3点セットで実現する
- Azureのアクセス権は、上位スコープに付与した権限が全て継承される。
この2つの条件から、「サブスクリプション」をスコープに権限設定すると、中身のリソースグループ、個別のリソース全てに対して効力を発揮し、「一部だけ除外」が出来ないという課題がありました。
ABACとは
「属性ベースのアクセス制御（Attribute Base Access Control＝ABAC）」はRBACを拡張する形で実装されています。
RBACの【誰が×どこに×何を】に対して【条件】を付与することができます。
【条件】はいくつか設定できるものがあるようですが、代表的なのはBLOB自体（≠BLOBストレージ）のタグです。「特定のタグに特定の値が入っているときのみ、参照可」といった制御が可能です。
ABACの使いどころ
例えば公式ドキュメントには下記のような絵で解説されています。
（引用元）
ABACで嬉しいこと
従来のRBACでは、「リソースグループ」をスコープに「BLOBデータ閲覧者」ロールを付与してしまうと、同じリソースグループに含まれるストレージアカウント内のBLOBは全て読み込み可能となってしまいます。
ABACで「Project=Cascadeタグがある場合は」という条件を付けることで、同じリソースグループ内・ストレージアカウント内であっても、それ以外のタグ・値を持つBLOBは読み込むことができないようにできます。
特定のシステム内で、いろんなデータが書き込まれるストレージアカウントがあった場合に、ある職責のユーザーグループはこの範囲しか見られない…そんなことが実現できそうです。
RBACだけで頑張ると…
これまでは上記のような「タグ別にアクセス権を使い分ける」みたいなことをしたい場合は、ストレージアカウント自体を分割するしかなかったと思います。
※AさんはAlpine系のデータのみ見える、CさんはBakerとCascadeだけ見える。といった設定をするには下のような構成にするイメージ。
ただ本来、ストレージアカウントの分割は「権限」だけでなく、本来はストレージの性能、冗長性やネットワークの許可範囲など複数の要因で決めるものです。ただでさえ細かく分かれがちなストレージアカウントを、このためだけに必ず分割するとなるとなかなか管理負荷が厳しいものがあります。
また、そもそもRBACでのロール割り当ての上限という制限もあり、システム規模によっては上記の分割で細かく権限を割り当てる方式は成り立たない可能性もあります。
ABACであれば、1つのロール割り当ての中に条件で細かい制御を加えることができるので、このロール割り当ての制限下ではかなり優位に働きます。
使ってみた
さて、今回は下記のような設定を行い、ABACを試してみました。
想定（要件）
基本的には下記の通りで、
誰：「Aさん」
スコープ：「リソースグループ全体」
ロール：Storage BLOB データ所有者
条件として、ストレージアカウントの名称を使い「aaa*」で始まるストレージアカウントのみを対象とするようにABAC設定を行います。（「bbb*」のストレージアカウントが対象外になるようにします）
設定
IAM設定
まず、対象のリソースグループに対して「Storage blobデータ所有者」を割り当てに行きます。
通常、あるリソースのIAMのメニューからロールを割り当てようとすると下記のように「ロール」「メンバー」と2つのタブで設定するのですが、
「ABAC」に対応したロールを設定する場合は「条件」というタブが追加で表示されます。
「Storage blobデータ所有者」は、ABACに対応していますので条件を設定します。
条件
条件は、Azureポータル上のGUIでも、コードの形式でも設定することができます。どんなにIaCの時代が進んでも、出始めの機能はポータルで味見です。
actionの選択
まず、先ほど選んだロールに含まれるactionのうち、権限設定をしたいactionを選択します。
今回はデータ所有者権限の全てのactionに対して条件を設定するものとし、チェックボックスを全てONにしました。
条件の選択
次に、上で選んだactionが効力を発揮する条件を設定します。
想定のところに記載したように、【リソースのアカウント名が「aaa*」と一致】という条件で作成します。
GUIで設定すると、式の形で表示されます。
これを自力で設計（記述）しろと言われても結構厳しいような…
データ操作例
設定後、"aaastrac"と"bbbstrac"に対して、データの書き込み（BLOB作成）を検証します。
操作OKなストレージアカウント
aaastracに対しては、適当なtextファイルをUploadできました。
操作NGなストレージアカウント
bbbstracに対しては、uploadできません。
Azureポータルの表示からすると、upload前にまず、同じ名前のBLOBが作成されていないかチェックする動作が入るようなのですが、参照自体が出来ないので「ファイル名を検証できませんでした」というエラーになっています。
補足ですが、ストレージアカウントの「コンテナ」を作成するのは、データレイヤではなくリソースレイヤの操作なので、「testbbbコンテナ」は問題なく作成できています。
おわりに
といった形で、Storage AccountのABACを検証しました。うたい文句通り使えることを確認しました。
さて今回サクっと飛ばした「条件」について、actionごとに選べる条件の種類が変わるようです。まとめてactionを選択した場合は、どのactionでも使える最大公約数な条件しか選択できず、今回は「リソース名」を条件に選択しました。
多分次回、この辺りの選べる条件の条件について、少し深堀したいと思います。公開できるほどまとまるかわかりませんが…。。
Discussion