Azure BLOBにて共有してないはずのユーザからアクセスできてしまう事象が発生した原因と対策

# はじめに

みなさん、こんにちは。私は最近Azure BLOBを使ったファイル共有の設計をした際、構築の直後は期待したようにアクセス抑止が動作せず原因を調査することがありました。原因はストレージアカウントキーを使って想定外のユーザがアクセス出来てしまうことにありました。

この記事では、その対策として実施した、Azure BLOBの認証にストレージアカウントキーを使わない理由と、Azure ADアカウントを使ってアクセス制御する方法を解説します。

# 概要
![image-20221205165601975.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1733841/128b4537-22e8-46bc-3253-40f089bdcc4e.png)

この記事で実現したいファイル共有時のアクセス制御は、上記の概要図になります。

ファイル共有時のアクセス制御としては、ユーザ単位にフォルダを用意し、各ユーザが自分のフォルダだけに読み書きができ、他ユーザのフォルダは参照も不可にすることです。

Azure上に今回構築したシステムは、オンプレミスとは独立した環境です。そのため、既存のAcitive Directory(AD)と連携させることが出来ないため、独自のユーザ認証を実装してファイル共有を構築する必要があります。

Azure上のファイル共有サービスといえば、最初にAzure Filesが候補になるかと思います。しかし、Azure Filesでサポートされる認証シナリオには、オンプレミスのActive Directory Domain Service(AD DS)や、Azure Active Directory Domain Services (Azure AD DS)が必要となります。今回はオンプレとは接続されていないためAD DSは使えず、Azure AD DSを新たに構築するのは設計範囲が増えすぎると判断したためAzure Filesは検討から外しました。

今回はAzure BLOB Storage(以下BLOBと略す)を使ってファイル共有を実装することにしました。BLOBの場合、Azure PortalへログインするAzure ADユーザを使って認証ができます。また、図「実現したいアクセス制御の概要図」のようにBLOB内に作成するコンテナ単位でユーザ単位のアクセス制御が可能です。



# 課題
![image-20221205172701286.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1733841/ebbe60bc-9209-db81-14fa-c7f6d66ec43a.png)

実際に環境を構築し、動作確認をしたところ次のような課題が見つかりました。

- 本来、参照できないはずのユーザAが、コンテナ#2のフォルダ#2やファイル群が参照できる。

上記図の赤点線のアクセスが想定外に出来てしまいました。



原因を調査した結果、Microsoftの公式ドキュメントに次のような記載を見つけました。

### 　[BLOB 用の Azure 組み込みロール](https://learn.microsoft.com/ja-jp/azure/storage/blobs/authorize-access-azure-active-directory#azure-built-in-roles-for-blobs)

> 　**所有者**、**共同作成者**、**ストレージ アカウント共同作成者**などの組み込みロールでは、セキュリティ プリンシパルによるストレージ アカウントの管理は許可されますが、Azure AD を介したそのアカウント内の BLOB データへのアクセスは提供されません。 ただし、ロールに **Microsoft.Storage/storageAccounts/listKeys/action** が含まれている場合、そのロールが割り当てられているユーザーは、アカウントアクセスキーを使った共有キーによる承認を介してストレージ アカウントのデータにアクセスできます。



つまり、**所有者**のロールを割り当てたユーザは、アカウントアクセスキーを使って同じストレージアカウント内のデータにアクセスが出来ていました。

組み込みロールを確認すると下記表のように**Microsoft.Storage/storageAccounts/listKeys/action** に対してアクションが許可されていました。

![image-20221206163235102.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1733841/0991f40e-a307-5744-367a-35723339e2f0.png)

詳しい解説は下記の公式ドキュメントを参照することをお勧めします。

### 　　[アカウント アクセス キーを使用する](https://learn.microsoft.com/ja-jp/azure/storage/blobs/authorize-data-operations-portal#use-the-account-access-key)



# 解決方法
![image-20221205172807062.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1733841/6c57e180-6431-c373-93bc-926a0b214548.png)

アカウントアクセスキーによる認証を禁止するには、下図のようにストレージアカウントの構成の「**ストレージアカウントキーへのアクセスへの許可**」の設定を「有効」から「**無効**」へ変更します。

また、Azure ADを使って認証をさせるためには、同じ設定画面の「**Azure portalでAzure Active Directoryの承認を既定にする**」を「**有効**」に設定します。

![image-20221205173631574.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1733841/8353b1a5-7ca0-9f52-e3fe-c54b158bbc3a.png)

そして、ユーザAがコンテナ#1だけを参照・更新が出来るようにするために、コンテナ#1の**スコープ**でAzure ADアカウントAに対して組み込みロール名「**ストレージBLOBデータ共同作成者**」を割り当てます。

以上の設定変更を行うことで、実現したいアクセス制御が実現できました。

- ユーザAはコンテナ#1だけが参照・更新が可能。コンテナ#2は参照できない。
- ユーザBはコンテナ#2だけが参照・更新が可能。コンテナ#1は参照できない。



# 終わりに

Azure BLOBにてAzure ADを使ってアクセス制御する方法について解説させて頂きました。分かってしまえば簡単な設定です。ただし、Azureに慣れていない場合は認証の仕組みが2種類存在するというのは想定外だと思います。

また、Azureの仕様は随時更新されています。実際に適用する前には必ず実機検証を実施下さい。

今回の記事が少しでも参考になれば幸いです。以上、最後まで読んでいただきありがとうございました。

---

- Microsoft Azure は，Microsoft Corporation の商標または登録商標です。
- その他、記載されている会社名および商品・製品・サービス名は、各社の商標または登録商標です。