AZ-104試験対策 第2回:Azureのアクセス制御とサブスクリプション管理を理解する

この記事の内容

  • Azureの階層構造(アカウント → サブスクリプション → リソースグループ → リソース)を解説します
  • ロールベースアクセス制御(RBAC)の仕組みとロールの割り当て方法を学びます
  • Azureコスト管理・予算アラートの設定手順を確認します
  • タグ・管理グループ・Azureポリシーを使ったガバナンス管理を紹介します
  • リソースロックによる誤削除防止の方法を説明します

Azureの階層構造を理解する

AZ-104の試験範囲を学ぶ上で、まずAzureの階層構造を正確に把握することが重要です。

Azureの構造は以下の順で成り立っています。

MicrosoftVMMOSP

アカウントとは、Azureの契約を束ねる概念です。アカウントを持つ人が「アカウント所有者」であり、Microsoftアカウントまたは組織アカウント(Azure ADユーザー)がここに紐付きます。

サブスクリプションは課金を管理する単位です。アカウントに紐付いて作成され、このサブスクリプション以下のリソースに対してRBACでアクセス権を設定します。

アカウント管理者とRBACの所有者の違い

ここで混乱しやすい点を整理します。

  • アカウント管理者:アカウント自体を持っている存在で、サブスクリプションのプロパティ上で「アカウント管理者」と表示されます。RBACのロールとしては「所有者」に相当します。
  • 所有者(RBACロール):サブスクリプション以下のリソースに対して最も強い権限を持ち、他者にもロールを割り当てることができます。

アカウント管理者はサブスクリプションそのものを作成できる権限も持ち、RBACの所有者よりもさらに上位の存在です。


サブスクリプションとAzure ADの信頼関係

サブスクリプションは、必ず一つのAzure Active Directoryを「信頼」します。サブスクリプション内で権限を持つユーザーは、この信頼しているAzure ADの中に存在している必要があります。

ゲストとして招待された外部ユーザーも、Azure ADに存在していれば権限を割り当てることができます。

注意:信頼するAzure ADを変更すると、既存の権限設定はすべてリセットされます。変更後は権限の付け直しが必要になります。


エンタープライズ向けの契約構造(試験範囲外・参考)

個人や小規模での利用であればMOSP契約が一般的ですが、大企業ではエンタープライズアグリーメント(EA)契約やエンタープライズサブスクリプションアグリーメント(ESA)契約が使われます。

この場合、以下の役割が追加されます。

役割権限
エンタープライズ管理者アカウントの作成・アカウント所有者の設定が可能
部署管理者担当部署内のアカウント管理が可能
アカウント所有者サブスクリプションの作成・管理が可能

重要な注意点として、一つのMicrosoftアカウントは一つのアカウント所有者としてしか紐付けられません。個人で作成したサブスクリプションを持つアカウントをEA契約に追加すると、そのサブスクリプションがEA契約に移行してしまう場合があります。企業では組織アカウント(Azure ADユーザー)を使うことが推奨されます。


コスト管理:Azureコストマネジメント

サブスクリプションのコストを管理するためのツールがAzureコストマネジメントです。

コスト分析

コスト分析では、以下のようなカット軸でコストを確認できます。

  • サービスごと
  • ロケーションごと
  • リソースグループごと

表示形式は棒グラフ・折れ線グラフ・積み上げグラフ・テーブルなど自由にカスタマイズでき、作成したビューはURLとして共有することもできます。

予算とアラートの設定

予算を設定する際は、過去の使用履歴に基づいた予測値が自動的に提示されます。

  1. 予算額を月次・四半期・年次の単位で設定します
  2. アラートの条件を設定します(実際のコストが予算の50%に達したら通知など)
  3. アクショングループを設定して通知先を指定します(メール、SMS、Azure Mobile Appプッシュ通知など)

予測ベースのアラートも設定でき、「このまま使い続けると予算を超えそうだ」という段階で事前に通知を受け取ることができます。

Azureアドバイザー

AzureアドバイザーはAzure全体を分析し、改善すべき推奨事項を提示してくれるサービスです。カテゴリは以下の通りです。

  • コスト(例:使用率の低いVMのサイズダウン提案)
  • セキュリティ
  • 信頼性
  • オペレーショナルエクセレンス
  • パフォーマンス

コストマネジメント画面からも推奨事項を確認でき、その場でリソースのサイズ変更などを実施することも可能です。


リソースグループの活用

リソースグループは、サブスクリプション内にリソースをまとめる「箱」です。設計のセオリーとしては、同じライフサイクルを共有するリソースをひとつのリソースグループにまとめることが推奨されています。

リソースグループでまとめることで、以下のメリットがあります。

  • 削除の一括管理:リソースグループを削除するとその中のリソースがすべて消えるため、不要なリソースの残置を防げます
  • コスト管理:リソースグループ単位でコスト分析や予算設定ができます
  • 権限管理:リソースグループに設定した権限は、その中のすべてのリソースに継承されます

管理グループによる複数サブスクリプションの管理

複数のサブスクリプションをまとめて管理したい場合には、管理グループを使います。

管理グループの構造は以下の通りです。

AB

管理グループに対してもアクセス制御・ポリシーの設定が可能です。管理グループ上位でポリシーや権限を設定すると、その配下のすべてのサブスクリプション・リソースグループ・リソースに継承されます。


タグによる横断的な管理

階層構造をまたいだ管理を行いたい場合に便利なのがタグです。タグは「名前:値」のペアで、任意のリソース・リソースグループ・サブスクリプションに付与できます。

=ebisuda

タグを付与することで、Azureリソースグラフエクスプローラーを使ってタグで絞り込んだリソース一覧を取得できます。

Resources
| where tags['所有者'] == 'ebisuda'

注意:タグは権限設定と異なり、親から子へは継承されません。継承させたい場合はAzureポリシーを利用します。


Azureポリシーによるガバナンスの強制

Azureポリシーを使うと、リソースに対してさまざまなルールを強制適用できます。組織全体のルールを人間の運用ではなく、ポリシーで自動的に担保できます。

主な活用例

  • 使用できるリージョンを限定する
  • 使用できるVMのサイズを制限する
  • 特定のタグが付いていないリソースを作成させない
  • タグを親から子に継承させる

ポリシーの適用と監視

  1. ポリシー(またはイニシアチブ)を選択して割り当てる
  2. コンプライアンス画面で準拠状況を監視する
  3. 準拠していないリソースは修復機能で自動的に修正することもできる

イニシアチブ

複数のポリシーをひとつにまとめたものがイニシアチブです。業界標準のガイドラインに対応したイニシアチブがMicrosoftからあらかじめ提供されており、それを適用するだけで一括してポリシーを有効化できます。


RBAC(ロールベースアクセス制御)

ロール・スコープ・割り当ての三要素

RBACは以下の三要素で構成されます。

要素説明
ロール何ができるかを定義したもの
スコープどのリソースに対して適用するか
割り当てどのIDに対してロールを付与するか

スコープは以下のいずれかのレベルで設定できます。

>>>

主要なビルトインロール

ロール権限
所有者すべての操作+ロールの割り当て
共同作成者すべての操作(ロールの割り当ては不可)
閲覧者読み取りのみ

コントロールプレーンとデータプレーン

ロールの「操作」と「データアクション」は別物です。

  • 操作(コントロールプレーン):Azure Resource Manager(ARM)経由でのリソース管理操作
  • データアクション(データプレーン):リソースそのもの(VMのログイン、ストレージのデータ読み書きなど)への操作

カスタムロールの作成

ビルトインロールでは細かすぎたり粗すぎたりする場合、カスタムロールを作成できます。

作成画面では以下を設定します。

  1. ロール名と説明
  2. 許可するアクセス許可(個別に選択またはワイルドカード使用)
  3. 除外するアクセス許可
  4. 割り当て可能なスコープ

カスタムロールの定義はJSONファイルとして管理することもできます。ただし、カスタムロールの乱用は管理コストが高くなるため、必要最小限にとどめることが推奨されます。

ロールの割り当て手順

IAM///ID

上位スコープで設定した権限は下位のリソースに継承されます。アクセス制御画面では、直接割り当てられた権限と継承された権限を区別して確認できます。


リソースロックによる誤削除防止

削除権限を持つユーザーでも操作をブロックしたい場合には、リソースロックを使います。

ロックの種類

種類内容
削除削除操作をブロックする
読み取り専用削除および変更操作をブロックする

ロックの設定手順

OK

ロックを設定した状態でリソースグループを削除しようとすると、次のようなエラーが表示されます。

ロックは権限設定と同様に子リソースにも継承されます。リソースグループにロックをかければ、その中のすべてのリソースにもロックが適用されます。

解除するには、ロックが設定されたスコープに移動してロックを削除してから、改めて削除操作を行います。


まとめ

この記事では、AZ-104試験の「Azureのアクセス制御」および「サブスクリプションとガバナンスの管理」に関する内容を解説しました。

  • 階層構造:アカウント → サブスクリプション → リソースグループ → リソースという構造を理解することが基礎です
  • RBAC:ロール・スコープ・割り当ての三要素を組み合わせて権限管理を行います。権限は上位から下位へ継承されます
  • コスト管理:Azureコストマネジメントで予算設定・アラート・推奨事項を活用してコストを最適化できます
  • タグ:階層をまたいだ横断的な管理に有効ですが、継承はされません
  • Azureポリシー:組織のルールをポリシーで強制適用し、コンプライアンスを自動的に担保できます
  • リソースロック:削除権限があっても誤操作をブロックする安全装置として活用できます

試験勉強では概念を理解するだけでなく、実際にAzureポータルを操作して手を動かすことで、より深い理解が得られます。次回はネットワーク関連の項目を扱う予定です。