第 4 章 ストレージを実装して管理する（15〜20%）
ストレージへのアクセスを構成する
この章で学ぶこと
- Azure Storage ファイアウォールおよび仮想ネットワークを構成する
- Shared Access Signature (SAS) トークンを作成して使用する
- 保存されているアクセス ポリシーを構成する
- アクセス キーを管理する
- Azure Files の ID ベースのアクセスを構成する
この章に出てくる用語
- Azure Storage
- Azure でデータを置く土台になるサービス。 「ストレージアカウント」という器を 1 つ作ると、その中で 4 つのサービスが使える。Blob（ファイルを名前で出し入れする。画像・ログ・バックアップなど）、Files（SMB / NFS でマウントできるファイル共有）、Queue（アプリ間でメッセージを受け渡す待ち行列）、Table（キーと値の簡易なデータベース）。AZ-104 で中心になるのは Blob と Files の 2 つ。
- SAS（Shared Access Signature）
- 期限と権限を限定した「一時的な鍵つき URL」。 アカウントキーそのものを渡さずに、「このコンテナーのこのファイルを、来週まで、読み取りだけ」といった形で外部にアクセスを委任できる。URL の末尾にクエリ文字列として署名が付く。
「権限は正しいはずなのにアクセスできない」という状況が頻出する。原因を切り分けられるようにするため、まず層を分けて捉える。
① がストレージファイアウォール。特定の仮想ネットワーク・IP 範囲・リソースからのアクセスだけを許す。② が認可で、アクセスキー、SAS、Microsoft Entra ID のいずれかで本人確認と権限判定を行う。どちらか一方を通っただけではデータに到達できない。
試験では
ストレージファイアウォールの既定は「すべてのネットワークから許可」。絞り込むときに自分の管理端末の IP を許可リストに入れ忘れると、ポータルからも自分で触れなくなる。試験でもこの筋書きが出る。
補足
ファイアウォールで拒否していても、Azure Backup や Azure Monitor など一部のサービスは「信頼された Azure サービスの例外」で通せる。「バックアップが取れなくなった」という状況の答えがこれになることがある。
ストレージアカウントには key1 と key2 の 2 つのアクセスキーが用意される。どちらもアカウント全体へのフルアクセス権を持つ、極めて強い鍵だ。
試験では
2 つある理由はローテーションのため。 key1 でアプリを動かしている間に key2 を再生成し、アプリの参照先を key2 に切り替え、そのあと key1 を再生成する。こうすれば止めずに鍵を入れ替えられる。「冗長性のため」「読み取り用と書き込み用」は誤り。
# キーを取得する （PowerShell: Get-AzStorageAccountKey）
az storage account keys list \
--account-name <名前>
# キーを再生成する （PowerShell: New-AzStorageAccountKey）
az storage account keys renew \
--account-name <名前> --key key2SAS（Shared Access Signature）は、アカウントキーそのものを渡さずに期限付き・権限限定のアクセスを委任する仕組みだ。署名に使う鍵で 3 種類に分かれる。
| 署名に使う鍵 | 対象範囲 | ストアドアクセスポリシー | 推奨度 | |
|---|---|---|---|---|
| ユーザー委任 SAS | ユーザー委任キー（Entra ID） | Blob / Queue / Table / Files | 使えない | 最も推奨 |
| サービス SAS | アカウントキー | 1 つのサービスのリソース | 使える | 次点 |
| アカウント SAS | アカウントキー | 複数サービス＋サービス操作 | 使えない | 最も広い |
試験では
「どの SAS を使うべきか」と問われたら、第一候補はユーザー委任 SAS。アカウントキーを使わないので、キーが漏れても影響がなく、Entra ID の監査にも乗る。Microsoft の推奨もこれ。
ここが SAS の設計で一番効く分かれ目になる。期限と権限を SAS の URI に直接書き込む形式をアドホック SAS と呼ぶ。手軽だが、いったん配ってしまうと取り消す手段がほとんどない。
保存されているアクセスポリシー（ストアドアクセスポリシー）を使うと、期限や権限をコンテナー側に置ける。SAS はそのポリシーを参照するだけになるので、ポリシーを変更・削除すれば、その SAS だけをピンポイントで失効できる。
試験では
「発行済みの SAS を取り消したい」→ ストアドアクセスポリシーを使っていれば、それを削除する。使っていなければアカウントキーの再生成しかなく、そのキーで署名した SAS がすべて無効になる。1 つのコンテナーに置けるポリシーは最大 5 個。この数字も出る。
補足
ストアドアクセスポリシーを使えるのはサービス SAS だけ。アカウント SAS とユーザー委任 SAS では使えない。ユーザー委任 SAS は、代わりにユーザー委任キーを失効させることで取り消せる。
もう 1 つ、SAS 有効期限ポリシーという設定がストレージアカウント側にある。「SAS の有効期間は最長 7 日まで」といった推奨上限を定め、それを超える SAS が作られたときに警告を出す。強制ではなく検知の仕組みだ。
Azure Files を SMB でマウントして使う場合、ストレージアカウントのキーではなくユーザーの ID で認証させられる。ファイルサーバーの置き換えとして使うなら、こちらが本筋になる。
権限は二段構えになる。共有レベルは「そもそもこの共有に接続できるか」をRBAC ロールで決める。ディレクトリ／ファイルレベルは、接続できた後にどのフォルダーやファイルを読み書きできるかを、Windows と同じ NTFS の ACL で決める。
| 共有レベルの RBAC ロール | できること |
|---|---|
| Storage File Data SMB Share Reader | 読み取り |
| Storage File Data SMB Share Contributor | 読み取り・書き込み・削除 |
| Storage File Data SMB Share Elevated Contributor | 上記に加えて NTFS ACL の変更 |
ID ソースは 3 つから 1 つ選ぶ
| 方式 | こう書かれていたら選ぶ |
|---|---|
| オンプレミス AD DS | 既存の AD がある／クライアントがドメイン参加している |
| Microsoft Entra Kerberos | ドメインコントローラーに到達できない／クラウド専用 ID／FSLogix プロファイル／macOS |
| Microsoft Entra Domain Services | すでに Entra Domain Services を使っている Azure 上の VM から |
試験では
1 つのストレージアカウントで使える ID ソースは 1 つだけで、そのアカウント内のすべてのファイル共有に適用される。「共有ごとに別の認証方式にしたい」はできない。アカウントを分ける必要がある。
補足
オンプレミス AD DS 方式を使う場合、そのオンプレ AD は Microsoft Entra ID に同期されている必要がある。共有レベルの権限を RBAC で与える相手が Entra ID 側の ID だからだ。
この章のまとめ
- ストレージファイアウォールの既定の設定
- アクセスキーが 2 つある理由
- 最も推奨される SAS
- ストアドアクセスポリシーを使える SAS
- アドホック SAS を取り消す唯一の方法
- 1 コンテナーあたりのストアドアクセスポリシーの上限