Azure StorageでAzure Data Lake StorageのACLを管理している場合、今回確認すべき結論は「すぐに権限が変わる破壊的変更ではないが、ACL設計で間違いやすいポイントを再点検すべき」という点です。2026年5月19日の更新情報として扱われている「Access Control Lists in Azure Data Lake Storage – Azure Storage」は、Microsoft Learn上では最終更新日が2026年5月18日、GitHub上のメタデータも ms.date: 05/18/2026 に更新されています。公開差分を見る限り、機能追加よりも説明の明確化と鮮度更新が中心です。(Microsoft Learn)
ただし、内容が軽いわけではありません。Azure Data Lake StorageのACLは、Azure RBAC、Microsoft Entra ID、SAS、サービスプリンシパル、ディレクトリ階層の実行権限が絡むため、設定ミスが「見えるはずのファイルが見えない」「制限したつもりなのにアクセスできる」といった障害につながります。この記事では、Access Control Lists in Azure Data Lake Storage – Azure Storageの更新内容を踏まえ、管理者・開発者が確認すべき設定、移行時の注意点、よくある失敗を実務目線で整理します。
Azure Storageの「Access Control Lists in Azure Data Lake Storage」は何が変わるのか
今回の公式差分から読み取れる範囲では、Azure StorageやAzure Data Lake Storageのアクセス制御仕様そのものが大きく変更されたとは判断できません。主な変更は、ページタイトルの表記変更、更新日の変更、説明文の自然化、ACLの評価や権限設定に関する表現の明確化です。たとえば、サービスプリンシパルではアプリ登録のObject IDではなくサービスプリンシパルのObject IDを使う点、親ディレクトリのdefault ACL変更が既存の子項目に反映されない点、ファイル削除時にファイル自体のWrite権限が必須ではない点などが、より読みやすい表現に整理されています。(GitHub)
| 観点 | 今回の更新で押さえるべき内容 | 管理者・開発者への影響 |
|---|---|---|
| 仕様変更の有無 | 公開差分上は、日付更新と文言整理が中心 | 既存ワークロードの即時変更より、設定棚卸しが重要 |
| ACLの対象 | ファイル・ディレクトリ単位のPOSIX風ACL | コンテナー全体のRBACだけでは細粒度制御できない |
| 認証方式 | Shared Keyや通常のSASではACLが効かないケースがある | ACL検証時は認証方式を必ず確認する |
| サービスプリンシパル | アプリ登録ではなくサービスプリンシパルのObject IDを使う | ADF、Databricks、バッチ処理の権限設定でミスが起きやすい |
| 継承 | default ACLは新規作成される子項目に効く | 既存ファイル・既存ディレクトリには再帰適用が必要 |
| 権限評価 | Azure RBACで許可された権限をACLで後から制限できない | 「ACLを絞ったのにアクセスできる」原因になりやすい |
つまり、今回の更新を「新機能の発表」として読むよりも、「Azure Data Lake StorageのACL運用ルールを再確認するタイミング」として扱うのが現実的です。
対象となる環境と読者
Access Control Lists in Azure Data Lake Storage – Azure Storageの内容が直接関係するのは、階層型名前空間、つまりHierarchical Namespace（HNS）を有効にしたストレージアカウントです。HNSが有効な場合、ACLによるアクセス制御が利用できます。HNSが無効な場合は、Azure RBACの承認ルールが引き続き適用されます。(Microsoft Learn)
特に確認すべき読者は、次のような立場の人です。
- Azure StorageやAzure Data Lake Storageの権限設計を担当するクラウド管理者
- Microsoft Entra IDグループやサービスプリンシパルを管理するID管理担当者
- Azure Data Factory、Azure Databricks、Synapse、バッチ処理などからデータレイクへアクセスする開発者
- Storage Explorer、Azure CLI、PowerShell、SDKでACLを変更する運用担当者
- 監査対応や最小権限設計を担当するセキュリティ担当者
特に、ユーザー単位でACLを直接付与している環境、Shared KeyやSASでテストしている環境、既存ディレクトリに対して後からdefault ACLを変更している環境は、設定の見直し優先度が高いです。
ACLの基本は「ファイル・ディレクトリ単位の細かな権限制御」
Azure Data Lake StorageのACLは、POSIX風のアクセス制御リストです。各ファイル・各ディレクトリにACLがあり、ユーザー、グループ、サービスプリンシパル、マネージドIDなどのセキュリティプリンシパルに対して、Read、Write、Executeの権限を関連付けます。アクセス要求が発生すると、そのプリンシパルに必要な権限があるかをACLで確認します。(Microsoft Learn)
Azure RBACとACLは、役割が異なります。Azure RBACはストレージアカウントやコンテナー単位の大きな権限付与に向いており、ACLはディレクトリやファイル単位の細かな権限制御に向いています。Microsoft Learnのアクセス制御モデルでも、Azure RBACは粗い粒度、ACLは細かい粒度のアクセス許可として説明されています。(Microsoft Learn)
| 仕組み | 主なスコープ | 使いどころ |
|---|---|---|
| Azure RBAC | サブスクリプション、リソースグループ、ストレージアカウント、コンテナー | データ所有者、閲覧者、運用者など大枠の権限管理 |
| Azure ABAC | Azure RBACの条件付き割り当て | タグなどの属性条件を使った追加制御 |
| ACL | ディレクトリ、ファイル | 特定フォルダーだけ読み取り可、特定処理だけ書き込み可などの細粒度制御 |
実務では、Azure RBACで「このストレージアカウントのデータにアクセスできる人」を絞り、ACLで「どのディレクトリやファイルにアクセスできるか」を絞る構成が基本です。
権限評価の順番を理解する：ACLでRBACの許可は打ち消せない
Azure Data Lake Storageの権限設計で最も重要なのは、評価順序です。Microsoftのアクセス制御モデルでは、セキュリティプリンシパルベースの承認時に、まずAzureロール割り当てを確認し、条件がある場合はABAC条件を評価し、その結果で明示的に許可されなかった場合にACLを評価します。十分なアクセス権がAzure RBACと条件で許可された場合、ACLは無視されます。(Microsoft Learn)
これは、次のような運用ミスにつながります。
たとえば、あるユーザーにストレージアカウント全体でStorage Blob Data Contributorを付与している場合、特定ディレクトリのACLを厳しくしても、そのRBAC権限によってアクセスできる可能性があります。「ACLで制限したのに読める」というトラブルでは、まずAzure RBACのスコープを確認してください。
逆に、Azure RBACを付与していない、またはRBACでは十分な許可が出ていない場合、ACLがアクセス可否を決めます。このとき、ファイルそのもののReadやWriteだけでなく、そこに到達するまでの各ディレクトリにExecute権限が必要です。ACLだけでファイルへの読み書きを許可する場合、コンテナーのルートから対象ファイルまでの各フォルダーにExecute権限が必要だと公式ドキュメントでも説明されています。(Microsoft Learn)
Read、Write、Executeの意味を実務で理解する
Azure Data Lake StorageのACLでは、Read、Write、Executeの意味がファイルとディレクトリで変わります。特にExecuteは、Linuxの実行ファイルのような意味ではなく、ディレクトリ階層をたどるための権限として理解する必要があります。
| 権限 | ファイルの場合 | ディレクトリの場合 | 実務での注意点 |
|---|---|---|---|
| Read | ファイル内容を読める | ディレクトリ一覧にはReadとExecuteが必要 | 一覧表示とファイル読み取りを混同しない |
| Write | ファイルへ書き込み・追記できる | 子項目の作成にはWriteとExecuteが必要 | アップロード先ディレクトリには-WXが必要になりやすい |
| Execute | Data Lake Storageのファイルでは実質的な意味を持たない | 子項目へ到達するために必要 | 深い階層のファイルでアクセス拒否が起きる典型原因 |
たとえば、/finance/2026/report.csv を読みたい場合、report.csv に R-- があるだけでは足りません。/、/finance、/finance/2026 に少なくとも --X が必要です。ディレクトリ一覧も見せたい場合は、対象ディレクトリに R-X が必要になります。
この考え方を知らないと、開発者は「ファイルにはRead権限があるのに403になる」と判断しがちです。実際には、途中のディレクトリにExecute権限がないケースが多くあります。
access ACLとdefault ACLの違い
Azure Data Lake Storageには、access ACLとdefault ACLの2種類があります。access ACLはファイルやディレクトリそのものへのアクセスを制御します。一方、default ACLはディレクトリに関連付けられるテンプレートで、その配下に新しく作成される子項目のACLを決めます。ファイルにはdefault ACLはありません。(Microsoft Learn)
重要なのは、親ディレクトリのdefault ACLを変更しても、すでに存在する子ファイルや子ディレクトリのACLは自動では変わらないことです。既存データに反映したい場合は、対象階層に対してACLを再帰的に追加、更新、削除する必要があります。(Microsoft Learn)
| やりたいこと | 設定すべきACL | 注意点 |
|---|---|---|
| 既存ファイルへのアクセスを許可したい | access ACL | 対象ファイルと親階層のExecuteを確認する |
| 今後作成されるファイルにも同じ権限を付けたい | 親ディレクトリのdefault ACL | 既存ファイルには自動反映されない |
| 既存配下すべてへ反映したい | 再帰的なACL更新 | 失敗時の継続トークンや権限不足に注意する |
新しいデータレイク領域を作るときは、先にディレクトリ構造とdefault ACLを設計してからデータ投入を始めるのが安全です。データ投入後にdefault ACLだけを変更しても、既存ファイルには期待した権限が付かないためです。
管理者が確認すべき設定
HNSが有効か確認する
ACLを前提にした設計は、HNSが有効なストレージアカウントで行います。HNSが無効なアカウントでは、ファイル・ディレクトリ単位のACLではなくAzure RBACを中心に考える必要があります。(Microsoft Learn)
確認観点は単純です。対象アカウントが「Azure Data Lake Storageとしてディレクトリ階層を扱うアカウント」なのか、「通常のBlob Storageとして使っているアカウント」なのかを分けて棚卸ししてください。
Azure RBACのスコープを確認する
ACLのトラブル調査では、まずAzure RBACを確認します。Storage Blob Data Owner、Storage Blob Data Contributor、Storage Blob Data Readerなどのデータアクセスロールが、サブスクリプション、リソースグループ、ストレージアカウント、コンテナーのどこで付与されているかを確認してください。Storage Blob Data OwnerはBlobコンテナーとデータへのフルアクセスに加え、所有者設定や全項目のACL変更が可能です。Storage Blob Data Contributorは読み書き削除が可能ですが、所有者設定はできず、所有している項目のACL変更に限られます。(Microsoft Learn)
特に避けたいのは、広いスコープで強いロールを付与したまま、ACLだけで細かく制限しようとする設計です。ACLは、すでにRBACで許可されたアクセスを拒否するための仕組みではありません。
ACLは個人ではなくMicrosoft Entraセキュリティグループに付与する
公式ドキュメントでは、ACLエントリの割り当て先としてMicrosoft Entraセキュリティグループを使うことが推奨されています。個人ユーザーや個別のサービスプリンシパルを直接ACLに追加すると、退職者対応、組織変更、アプリケーションの入れ替え時に、ディレクトリ階層全体へACL変更を再適用する必要が出やすくなります。(Microsoft Learn)
実務では、たとえば次のように分けます。
| グループ例 | 役割 | 付与する権限例 |
|---|---|---|
LogsReaders | ログ分析を行うユーザーや分析基盤 | 対象ディレクトリにr-x、ファイルにr-- |
LogsWriters | ログを投入するアプリや運用担当 | 投入先ディレクトリにrwxまたは-wxを含む設計 |
DataLakeAdmins | ACL変更や所有者管理を行う管理者 | 必要に応じてStorage Blob Data OwnerとACL管理権限 |
ただし、Microsoft Entra IDのグループメンバーシップが多すぎると、JWT内のグループ情報の制限によりData Lake Storage Gen2で予期しないパフォーマンス問題につながる可能性があるため、1つのセキュリティプリンシパルに対するグループメンバーシップは200未満に抑えることが推奨されています。(Microsoft Learn)
サービスプリンシパルは「アプリ登録のObject ID」ではなく「サービスプリンシパルのObject ID」を使う
Azure Data Factory、Azure Databricks、カスタムアプリ、CI/CDなどでサービスプリンシパルを使う場合、ACLに指定するIDを間違えやすいです。公式ドキュメントでは、ACL設定時にアプリ登録側のObject IDではなく、関連するサービスプリンシパルのObject IDを使うよう明記されています。(Microsoft Learn)
Azure CLIでは、アプリケーションIDを指定して次のように確認します。
az ad sp show --id <Your-App-ID> --query objectId取得したObject IDを、named user相当のACLエントリとして追加します。アプリ登録画面で見えるObject IDをそのまま使うと、ACLを付けたつもりでも対象アプリがアクセスできない原因になります。
Shared Key、SAS、ユーザー委任SASの違いを確認する
ACLの検証でよくある落とし穴が、認証方式の混在です。ACLは同一テナント内のセキュリティプリンシパルに適用されます。Shared Key認証では呼び出し元にIDが紐づかないため、ACLによるプリンシパルベースの承認は行えません。通常のSASについても同様ですが、ユーザー委任SASでは、条件を満たす場合にPOSIX ACLチェックが行われます。(Microsoft Learn)
検証時は、「Azure Portalではアクセスできる」「CLIでは403」「アプリでは読める」といった結果だけで判断しないでください。どの認証方式で、どのプリンシパルとしてアクセスしているかを必ず揃える必要があります。
ACLエントリ数の上限を意識する
ACLは便利ですが、無制限に増やせるわけではありません。公式のアクセス制御モデルでは、ACLはファイルまたはディレクトリごとに32エントリ、実質的には28エントリが上限として説明されています。access ACLとdefault ACLはそれぞれ32エントリの制限を持ちます。(Microsoft Learn)
この上限を考えると、個人ユーザー単位のACL運用は長期的に破綻しやすいです。部門、職務、ワークロード単位のMicrosoft Entraセキュリティグループを作り、ACLにはグループを割り当てる設計が現実的です。
開発者・運用担当者が使う確認コマンド
Azure CLIでは、ACLの取得、設定、再帰更新が可能です。公式ドキュメントでは、Azure CLI 2.14.0以上、HNS有効のストレージアカウント、Storage Blob Data Ownerまたは対象項目の所有者権限などが前提として示されています。(Microsoft Learn)
ACLを確認する
az storage fs access show \
-p my-directory \
-f my-file-system \
--account-name mystorageaccount \
--auth-mode loginファイル単位で確認する場合は、-pに対象ファイルのパスを指定します。
az storage fs access show \
-p my-directory/upload.txt \
-f my-file-system \
--account-name mystorageaccount \
--auth-mode loginACLを設定する
ACLをsetする操作は、既存エントリを含むACL全体を置き換えます。特定プリンシパルだけを追加・変更したい場合は、置き換えではなくupdateを使うべきです。公式CLIドキュメントでも、ACLを設定すると全エントリを置換するため、既存エントリへ影響を与えたくない場合は更新操作を使うよう説明されています。(Microsoft Learn)
az storage fs access set \
--acl "user::rw-,group::rw-,other::---" \
-p my-directory \
-f my-file-system \
--account-name mystorageaccount \
--auth-mode login既存配下に再帰的に反映する
既存ディレクトリ配下へACLを広げる場合は、再帰操作を使います。
az storage fs access set-recursive \
--acl "user::rwx,group::r-x,other::---,user:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:r-x" \
-p my-parent-directory/ \
-f my-container \
--account-name mystorageaccount \
--auth-mode login再帰処理では、実行途中の権限不足やランタイムエラーにも注意が必要です。公式CLIドキュメントでは、失敗時に継続トークンを使って処理を再開できること、ACLの再適用自体は悪影響なく行えることが説明されています。(Microsoft Learn)
Azure Portal、Storage Explorer、CLIの使い分け
ACL管理は、どのツールを使うかでできることが変わります。
| ツール | 向いている作業 | 注意点 |
|---|---|---|
| Azure Portal | 個別のディレクトリやBlobのACL確認・簡易変更 | 既存子項目への再帰適用はできない |
| Azure Storage Explorer | GUIでのACL管理、既存配下への伝播 | ACL管理にはMicrosoft Entra IDでのサインインが必要 |
| Azure CLI | 自動化、再帰更新、CI/CD連携 | setとupdateの違いに注意 |
| SDK | アプリケーションや運用ツールへの組み込み | 実行主体のIDとACLを明確にする |
Azure Portalの公式ドキュメントでは、既存の子項目へACLを再帰的に適用することはPortalではできず、Storage Explorer、PowerShell、Azure CLI、またはSDKを使うよう案内されています。(Microsoft Learn)
Storage Explorerを使う場合、HNS有効アカウントのACL管理ではBlobエンドポイントとDFSエンドポイントの両方が使われます。プライベートエンドポイント構成では、blobとdfsの2つのサブリソースに対するプライベートエンドポイントを確認してください。(Microsoft Learn)
移行・展開時の注意点
既存データへdefault ACLだけを設定して終わらせない
データレイク移行で多い失敗は、親ディレクトリにdefault ACLを設定して「配下にも反映された」と思い込むことです。default ACLは、設定後に新しく作られる子項目のテンプレートです。既存ファイルに反映したい場合は、access ACLの再帰更新が必要です。(Microsoft Learn)
展開手順としては、次の順番が安全です。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 事前設計 | ディレクトリ構造、管理グループ、読み書きグループを決める | 個人単位のACLを避ける |
| 権限付与 | Azure RBACで大枠、ACLで細部を設定する | RBACが広すぎないか確認する |
| default ACL設定 | 新規作成される子項目向けに親へ設定する | 既存データには自動反映されない |
| 既存データ更新 | 必要に応じて再帰的にaccess ACLを更新する | 途中失敗時の再開方法を決める |
| 検証 | 実際のユーザー、サービスプリンシパル、マネージドIDでテストする | Shared Keyや通常SASでの検証結果と混同しない |
削除権限は「ファイルのWrite」だけで判断しない
ファイル削除では、ファイルそのもののWrite権限が不要な場合があります。ディレクトリの権限が適切であれば削除できるため、削除可否は親ディレクトリ側のWriteとExecuteを含めて確認する必要があります。一方、ディレクトリとその中身を再帰的に削除する場合は、親ディレクトリにWriteとExecuteが必要で、削除対象のディレクトリおよび内部の各ディレクトリにRead、Write、Executeが必要です。ルートディレクトリ/は削除できません。(Microsoft Learn)
この仕様を知らないと、「ファイルにWriteを付けていないから削除されないはず」という誤った前提で設計してしまいます。削除制御を厳密に行う場合は、ファイル単体ではなく親ディレクトリの権限を確認してください。
maskによる有効権限を見落とさない
ACLエントリ上はrwxが付いているのにアクセスできない場合、maskが原因になることがあります。maskはnamed user、named group、owning groupのACLエントリに適用され、実際に承認で使われる権限の上限として働きます。リクエストごとにmaskを指定すると、既定のmaskを完全に上書きできます。(Microsoft Learn)
トラブルシュートでは、ACLエントリだけでなくeffective permissionを確認してください。特に、複数のツールやクラスターから同じデータレイクを操作している場合は、ツールごとのmask指定が影響していないかを見る必要があります。
よくある失敗と対処法
| 失敗しやすいポイント | 症状 | 対処法 |
|---|---|---|
| 親ディレクトリのExecute不足 | ファイルにReadがあるのに403になる | ルートから対象ファイルまで各階層に--Xを付与する |
| RBACが広すぎる | ACLで制限したのにアクセスできる | Storage Blob Data Owner/Contributor/Readerのスコープを見直す |
| default ACLだけ変更した | 既存ファイルの権限が変わらない | 既存配下には再帰的にaccess ACLを更新する |
| アプリ登録のObject IDを使った | サービスプリンシパルがアクセスできない | az ad sp show --id <App ID> --query objectIdで取得したIDを使う |
| Shared KeyやSASで検証した | ACLの効果が確認できない | Microsoft Entra IDベースの認証でテストする |
| 個人ユーザーをACLに大量追加した | 退職・異動時の修正が大変、上限に近づく | Microsoft Entraセキュリティグループに集約する |
| Portalだけで再帰反映しようとした | 既存配下に反映できない | Storage Explorer、Azure CLI、PowerShell、SDKを使う |
| 削除権限をファイルだけで判断した | 想定外に削除できる、または削除できない | 親ディレクトリのWriteとExecuteを確認する |
管理者・開発者が今すぐ行うべき確認
今回の更新を受けて、まず行うべきことは大規模な移行ではなく、既存設定の棚卸しです。次の順番で確認すると、実害につながりやすい問題を見つけやすくなります。
| 優先度 | 確認項目 | 理由 |
|---|---|---|
| 高 | 対象ストレージアカウントでHNSが有効か | ACLが使える前提条件を確認するため |
| 高 | Azure RBACのロールとスコープ | ACLより先に評価されるため |
| 高 | Shared KeyやSASで運用・検証していないか | ACLが効かないアクセス経路を見落とさないため |
| 高 | サービスプリンシパルのObject ID | アプリ登録IDとの取り違えを防ぐため |
| 中 | default ACLと既存access ACLの差分 | 既存データへ反映漏れが起きやすいため |
| 中 | 個人単位のACLエントリ | 運用負荷とACL上限の問題を防ぐため |
| 中 | Storage Explorer利用時のblob/dfsエンドポイント | プライベートエンドポイント環境で接続問題を防ぐため |
| 低 | sticky bitやmaskの利用有無 | 高度な制御による想定外の挙動を確認するため |
Access Control Lists in Azure Data Lake Storage – Azure Storageの今回の更新は、目立つ新機能追加というより、ACLの基本仕様を正しく理解して運用するための再確認と捉えるべきです。特に、Azure RBACとACLの評価順、default ACLの反映範囲、ディレクトリのExecute権限、サービスプリンシパルのObject ID、Shared Key/SAS利用時のACL無効化は、実務で障害や過剰権限につながりやすいポイントです。
まずは、対象のAzure Storageアカウントを一覧化し、HNSの有無、RBACロール、ACLエントリ、認証方式を確認してください。そのうえで、個人単位のACLをMicrosoft Entraセキュリティグループへ寄せ、既存データへの反映が必要な場合はAzure CLIやStorage Explorerで再帰更新を計画するのが、安全な次の一手です。
コメント