【AZ-305】合格への道(DAY1) — ガバナンス設計/ID・アクセス管理
Microsoft Learn を教材にした AZ-305（Designing Microsoft Azure Infrastructure Solutions）の4日間研修、その DAY1 の受講メモです。
講師の解説のうち「Learn の本文だけでは拾いにくい判断基準」を中心に記録しています。
前提知識として、AZ-104合格後です。
⚠️ 本記事は受講メモをベースにした個人の整理です。正確な仕様は必ず公式ドキュメントをご確認ください。
研修全体の構成
| 内容 | |
|---|---|
| DAY1 | ID・ガバナンス |
| DAY2 | ストレージアカウント、データベース |
| DAY3 | バックアップとサイトリカバリ |
| DAY4 | インフラストラクチャ ソリューション設計 |
試験情報（講師談）
- 目的を達成するための手法が Well-Architected Framework
- 選択問題は部分点方式。選択肢を絞り込めるほど得点になり、外しすぎると0点になる形式がある
- ポリシーの問題は出やすい
Azure Policy の effect（ポリシールールの実際の箇所）
| effect | 内容 |
|---|---|
modify |
修復（主にタグ） |
deny |
拒否 |
audit |
監査 |
★ ポリシーを作る前から存在しているリソースには、
auditは適用されるがdenyは適用されない。
（既存リソースに対しては、拒否が監査として振る舞う）
第1部: ガバナンス ソリューションを設計する
1-1. ガバナンスとコンプライアンスの違い
| 用語 | 意味 |
|---|---|
| ガバナンス | 「おさめる」。会社の中のルールに従って動いていること |
| コンプライアンス | 外部の基準。法律や社外の基準に従って動いていること |
1-2. Azure リソース管理の階層
テナントルートグループ
└ 管理グループ … サブスクリプションをグループ化する
└ サブスクリプション … Azure 契約の最小単位、会計的な単位
└ リソースグループ … リソースをまとめておく
└ リソース
サブスクリプションは「お金を稼ぐアプリケーション」「社内システム」のように、会計的に違いがあるものを分ける単位です。
1-3. 管理グループを計画する
テナントルートは必ず最初からあるものです。
- Entra ID ごとにテナントが作成され、Entra ID テナントと紐づく（ポータルからは見えない）
- 他の管理グループは自分で作るもの
第1階層の作り方
- 全社的な規模で作成するのが一般的（会社全体の管理グループ: 例 Tailwind）
- 現在はテナントルートの機能が拡張されてきたが、会社全体の管理グループを作成する慣習がある
分割の判断基準
組織または部署の構造を検討しますが、会社組織図をそのまま意識した階層構造は良くありません。
★ 管理者権限とポリシールールが共通になることを意識して分けること。
- 人事部と総務部の IT 管理者が同じであれば、グループを分ける必要があるのか？
- 地理的な構造も、権限が分かれているのかで考える（地理的な条件そのものではなく、ルールが同じかどうか）
- 本番環境とテスト環境はグループを分けること
- サブスクリプションを分けることが、Azure 設定を完全に分離することになる
すべては管理者を優先して考えること。 階層化するとグループの管理が継承されます。
★ 管理グループを使う目的はサブスクリプションを管理するため。管理グループは「管理と課金のための箱」。
1-4. Azure 契約の種類
| 契約 | 内容 |
|---|---|
| 従量課金（PAYG: Pay As You Go） | 標準 |
| CSP（Cloud Service Provider） | 中規模会社が利用することが多い。複数のサブスクリプション |
| EA（Enterprise Agreement） | Microsoft と直接契約。利用料をコミットすると大幅なディスカウントあり。審査あり |
いずれにせよ サブスクリプションが基本です。
サブスクリプション毎のスケール制限（上限）
- CPU コアの上限がデフォルト20。サポートに言えばすぐに上げてくれる
- API 同時実行数など
1-5. 共有サービスをどう扱うか
たとえば以下の構成を考えます。
- 顧客向けグループ（VM・VNet など）
- 開発部向けグループ（VM・VNet など）
- 社内（オンプレミス）
社内オンプレミスと開発部向けグループを VPN Gateway でつないだ場合、その VPN Gateway は誰が管理するのか？
★ 様々な部門が利用する VPN Gateway のような共有サービスには、共通サブスクリプションを設けることが多い。
演習で議論になった点
- 管理グループ: Tailwind、販売、企業、IT、運用 という構成
- R&D を IT の下位にサブスクリプションとして割り当てるのはどうか？
- 人事と法務は一般的に IT 部門が管理しないか？分ける意味はあるのか、1つでもよいのか？
★ 管理者は Entra ID にユーザーがいて、グループがある。Entra ID に対してロールを割り当てる。
管理者は階層には出てこない。階層は「管理される側」であり、「管理する側」と混同しないこと。
1-6. サブスクリプションとは
- コンプライアンス達成のため、ロールベースのアクセス制御を行う単位
- スケーリングの単位
- コスト管理の単位（まれにリソースグループに入らないサービスがある）
- 管理の観点から見ると分離されることが多い
1-7. リソースグループを考慮して設計する
リソースを作成するときにはリソースグループの指定が必須です。
① ライフサイクルで分ける
1つのリソースグループはまとめて一括削除ができるため、同じ寿命（ライフサイクル）のものをリソースグループ化します。
★ データベースは別のリソースグループにすることが多い。
② 種類・アプリ・場所・課金で分ける
- 実は種類で分けることはあまりない（同じ管理者が種類ごとに管理することがあるのか、という観点）
- アプリケーション毎に管理者がいることはよくある
- 場所で分けることはあまりなく、サブスクリプションで分けることが多い
- 課金目的であればサブスクリプションが多い
③ 適用するポリシー毎に分ける
- コンプライアンス上「日本のみに VM を作れる」など
- ロールベースアクセス管理で分ける
④ リソースロックの単位で分ける
- うっかりミス防止や、読み取り専用のリソースグループにする目的
- ただしログの監査目的でリソースグループを分けることはない。なぜならリソースロックは管理者が設定を変更できてしまうため（監査は Log Analytics ワークスペース側のルールで行う）
1-8. リソースのタグ付けを考慮して設計する
- タグは単なるメモである
- このメモを使って課金集計することも可能
- タグはキーと値のペア
- タグを付けた場合は定期的にタグをチェックすること（ミスや付け忘れなど）
- Azure Policy でタグのチェックができる
- タグが存在しない場合、リソースグループからタグを継承する
1-9. Azure Policy を設計する
Azure Policy は、組織の標準を適用し、コンプライアンスを大規模に評価するのに役立ちます。組み込みポリシーがあり、カスタムポリシーも作成できます。
考慮事項
- 可能な限り最大のスコープで適用する
- ポリシーが適用（評価）されるタイミング
- ポリシーの追加・変更・削除時
- リソースの追加・変更時
- 24時間に1回（念のため）
- リソースが準拠していない場合に何を行うか決定する
- ポリシー定義のダッシュボードから確認する
⚠️ 管理者自身をブロックして手も足も出なくなることがあるため注意。複数の管理者を用意しておくことが重要。
＜重要＞ Policy と RBAC のデフォルト挙動は逆向き
| 設定しない場合 | |
|---|---|
| Azure Policy なし | すべて許可（制限なし） |
| Azure RBAC なし | すべて不可（許可なし） |
| 役割 | |
|---|---|
| Azure Policy | 環境の制約（誰であっても制約される。ダメなことを記載するイメージ） |
| RBAC | ユーザーやグループの権限（できる人を追加する。許可するルールを記載するイメージ） |
この2つを効果的に組み合わせます。
1-10. Azure ロールベースアクセス制御（RBAC）
- 最小権限
- グループに割り当てること。ユーザーには割り当てない（人事異動などがあると大変になる）
- 組み込みロールを積極的に使うとよい。読み取り専用（閲覧者）もある
- 例: 仮想マシン共同管理者からシャットダウン権限を奪う、ネットワーク管理を奪う → カスタムロールを作成する
主要ロールの関係
--- 所有者（Owner）-------------------- ユーザーアクセス管理者（User Access Administrator）
| -- 共同作成者（Contributor）--
| ・閲覧者（Reader）
★ 共同作成者 + ユーザーアクセス管理者 = 所有者
ロール追加時の2分類
| 分類 | 内容 |
|---|---|
| 職務ロール | リソース固有の権限と非特権（閲覧） |
| 特権管理者ロール | 全リソースに共通の管理者権限 |
※ 職務ロールに閲覧者が含まれているが、これは例外的に全リソース共通。
ハマりどころ: 所有者でも Blob の中身は見えない
- ストレージアカウントは、所有者アカウントだからといって Blob の中身が見えているわけではない
- 認証方法の違い: アクセスキーは所有者と閲覧者であれば読み取れる（RBAC を使っていない）が、Blob のアクセスロールがないと見れないケースがある
- Blob や Key の場合は、職務ロールがないと中身を見られない可能性がある
- Blob はデフォルトでは Key アクセス
★ 一部のサービスは、特権管理者ロールがあっても職務ロールがない場合、中身が見られない可能性がある。
1-11. Azure Policy と Azure RBAC を組み合わせるタイミング
★ ポリシーと RBAC は独立しており、連携はしていない。
デプロイ時に問うべきことは以下の3つ。
- 管理者にデプロイする権限があるか
- 管理者にこのリソースの種類をデプロイする権限があるか
- 管理者にこのリソースグループにデプロイする権限があるか
1-12. ランディングゾーン設計
コマンドを準備して実行することで、同じものを複製でき、ミスも減ります。
手順を書いて自動的に実行でき、必要なパラメータを変えるだけで再実行できます。インフラのテンプレートを作っておくと便利です。
立案ガイド: AzureCAF.LandingZones.Demo（GitHub）
1-13. ケーススタディ（コストと会計 / 新しい開発プロジェクト）
- 製品開発、マーケティング、営業に対してサブスクリプションがあればよい（6つ）。管理グループとサブスクリプションは別物
- サブスクリプションを跨いだ連携（ネットワークピアリング等）は容易
- 事業部門はコストを正確に知りたい。ただしサブユニットはサブスクリプション化しない。リソースグループ化する必要もなく、タグ付けする方法もある
★ サブスクリプションで全体のコストを把握する。詳細や細かいところはリソースグループやタグで行う。
AWS との違い（命名とロケーション）
| AWS | Azure | |
|---|---|---|
| 名前 | Name タグで付ける。あとから自由に変えられる | 管理 ID が振られるため、あとから自由に変えられない |
| ロケーション | — | あとから変えられない |
★ 場所と命名規則は「制約」、サイズは「監査」。
参考: ケーススタディ: ガバナンス
第2部: 認証・認可ソリューション
Entra の機能は「Office の機能」だと思った方が分かりやすい、という説明が印象的でした。
2-1. ID とアクセス管理の変遷
オンプレミス
Windows 2000: Active Directory
↓
Windows 2008: Active Directory（ID＆アクセス管理のブランド = IAM）
Active Directory Domain Services（AD DS）
Microsoft Online
Microsoft Online Server ユーザー
↓
Azure Active Directory（Azure AD）
↓
Microsoft Entra ID
現在、Azure を使うときは Entra ID が必須です。
2-2. ユーザーの種別
| 種別 | 内容 |
|---|---|
| 一般ユーザー（従業員用） | Entra ID テナントに対して従業員の ID を直接登録 |
| ゲスト（B2B / ビジネスパートナー） | 別テナントに登録されているユーザーを自分の Entra ID テナントに招待する。ユーザー管理・パスワード管理は元の Entra ID テナントで管理。一部の Azure サービスを見せるイメージ |
| 外部 ID（External ID） | 社内とは無関係にアプリケーションを登録する |
- ゲストは Entra ID 外のユーザー（Gmail など）も登録できる
- ただし B2B 機能を100%発揮するためには Entra ID が必要
2-3. Entra Connect と クラウド同期
いずれも**オンプレミスの AD DS からクラウドの Entra ID に同期するサービス（一方通行）**です。
両者の違いは公式の比較表が分かりやすいです。
参考: Microsoft Entra Connect とクラウド同期の比較
2-4. B2B で招待するときの挙動
- Gmail はもともと Entra ID と連携しているため、パスワードは Gmail と同じもので OK（フェデレーション機能あり）
- Entra ID と連携されていないユーザーアドレスの場合は、Microsoft アカウントが作られる
- リンクをクリックすると、任意のメールアドレスで Microsoft アカウントを作る必要がある
- そのため ID は同じでパスワードは別途設定が必要
- フェデレーションに登録されているプロバイダであれば、そのフェデレーション機能が使われる
参考: 直接フェデレーションの概要
ゲストユーザーに必須の MFA は、Microsoft Entra ID 側で決まります。
例え話: パスポートチェックが「認証」、入国チェックが「MFA」
外部 ID は、アプリケーションのプロファイルを作成するイメージです。Microsoft Entra ID は「人員の B2B コラボレーション用」と「外部アプリ用」の2つの顔を持ちます。
2-5. B2C（Microsoft External ID）
アプリを使うためのデータベースとして登録するもので、アプリケーション専用のテナントが存在します。
2-6. 条件付きアクセス
例え話の続き: 条件付きアクセスは「入国審査」に相当する。 国によって条件が変わる（メキシコ人がアメリカに入国するときなど）。
設定できる内容:
- 多要素認証を有効にするか
- このデバイスを許可するか
- このアプリケーションを OK とするか
- サインインを想定しない地域を除外する
- 侵害された可能性があるアカウントへの応答（SKU は P2 から）
- アクセスを完全にブロックする
- レガシ認証プロトコルをブロックする
- レポート専用モードを使用してテストする
⚠️ Entra ID 管理者自身もブロックしてしまう可能性があるため、レポート専用モードがある。
2-7. Identity Protection（P2 契約が必要）
サインインリスクポリシー
Tor ブラウザなどからサインインしていないかをチェックするポリシー。
Tor ブラウザ: 通信を世界中の複数の中継サーバー経由で暗号化し、閲覧履歴や IP アドレスを隠すことで極めて高い匿名性を提供する無料の Web ブラウザ。
ユーザーリスクポリシー
2-8. アクセスレビュー（P2 契約が必要）
ユーザーの役割（ロール）やグループのメンバーシップについて、ユーザーのアクセスを確認し、リソースへ継続してアクセスできるようにするための Microsoft Entra ツールです。
- ユーザーが人事異動のたびに役割が変わるのを追跡する
- アクセスレビューを「計画するのか、追跡するのか」を叶える機能
2-9. アプリケーションのサービスプリンシパル
人間のログインではなく、プログラムのログインのための仕組みです。
背景として、ブラウザ側にアプリケーションが認証するための接続文字列が置かれていると、ユーザー名やパスワードが漏洩するリスクがあります。
- アプリケーションの ID を発行して Entra ID 側に登録する
- あたかもユーザーのように使える
- アプリケーションに対応したコードを書く必要がある
- アプリケーション毎に ID を付与でき、アプリケーション毎に設定できる
2-10. マネージド ID
★ Azure リソースに限る（VM、App Service、Functions など）
仮想マシンや対応しているコンテナサービス上で動いているアプリケーション単位で使います。
| 種類 | 内容 |
|---|---|
| システム割り当てマネージド ID | リソースに紐づく |
| ユーザー割り当てマネージド ID | Azure リソースの一部として利用する |
管理の流れ: 管理ツール → ARM テンプレート → Azure Resource Manager
Azure Arc 対応サーバを使うと、システム割り当て・ユーザー割り当ての両方のマネージド ID が利用可能になります。
2-11. Azure Key Vault
接続文字列を埋め込んだアクセスは、既存のアプリケーションで一番多いパターンです。
Key Vault は、User / Password / Server などの接続文字列をシークレットとして管理するためのサービスです。
- 管理者権限があればアクセス可能
- 中身の権限のみ別のアクセス権限として設定できる
- Key Vault に対して証明書を設定できる
- キーコンテナについてロールの割り当てが可能（アクセス制御（IAM））
- アクセス元はキーコンテナのロール割り当てでメンバーを指定できる（ユーザー、グループ、サービスプリンシパル、マネージド ID）
キーペアの管理
Key Vault ではキーペアを作成できます（公開キー / 秘密キー）。
公開キーから秘密キーを推測できない根拠は、乱数に基づいているためです。その乱数発生をハードウェアで行う機能が HSM（Hardware Security Module）。
★ 要注意ポイント
SKU 乱数 Standard ソフトウェア乱数 Premium ハードウェア乱数（HSM） ハードウェアは共有されるが、乱数は共有されない。
専用 HSM（Dedicated HSM） はキーペア管理のみ。
DAY1 の重点ポイントまとめ
- Policy なし = すべて許可 / RBAC なし = すべて不可（デフォルト挙動が逆向き）
- Policy と RBAC は独立しており、連携していない
- 既存リソースには
auditは適用されるがdenyは適用されない - 管理グループは組織図ではなく「管理者権限とポリシーが共通か」で分ける
- 管理グループは「管理と課金のための箱」。完全な分離はサブスクリプション
- リソースグループは ライフサイクル（一括削除の単位） で分けるのが基本
- 共同作成者 + ユーザーアクセス管理者 = 所有者
- 所有者でも Blob の中身は見えないことがある（職務ロールが必要、Blob はデフォルト Key アクセス）
- マネージド ID は Azure リソース限定。オンプレは Azure Arc で対応
- Key Vault の HSM（ハードウェア乱数）は Premium から
おわりに
DAY1 は「どのサービスを使うか」よりも前段の、組織をどう切るか・誰に何を許すかという設計思想が中心でした。
特に Policy と RBAC のデフォルト挙動が逆向きであること、管理グループを組織図で切ってはいけないことは、試験だけでなく実務でも効いてきそうな観点です。
DAY2 以降も、整理でき次第まとめていきます。