Azure Fundamentals · レッスン

エンタープライズ向け ID とアクセス設計

Q: 「エンタープライズ向け ID とアクセス設計」で何を学びますか？

管理グループ、カスタム ロール、Privileged Identity Management を使用して大規模な RBAC モデルを設計し、機密性の高い操作への Just-In-Time アクセスを適用します。 ブラウザで直接実行するハンズオンコードでAzure Fundamentalsを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

管理グループ、カスタムロール、Privileged Identity Management を使用して大規模な RBAC モデルを設計し、機密性の高い操作への Just-In-Time アクセスを適用します。

「エンタープライズ向け ID とアクセス設計」はCoddyKit上の無料Azure Fundamentalsレッスンです。これはレッスン4/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはAzure Fundamentals学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Azure Fundamentalsコースには全4レッスンが含まれています。

エンタープライズ規模の ID

エンタープライズ Azure 環境では、ID とアクセスの管理を数百のサブスクリプション、数千人のユーザー、数十のチームに対応させる必要があります。しかも、リソースへのアクセス要件はそれぞれ異なります。適切に設計された ID モデルは、過剰な権限付与（アクセス権が多すぎるユーザー）と権限不足（業務を遂行できないユーザー）の両方を防ぎます。その基盤となるのが、Microsoft Entra IDとAzure RBAC、そしてPrivileged Identity Management (PIM)などのガバナンスツールです。

RBAC の基礎を再確認

Azure Role-Based Access Control (RBAC)は、次の 3 つの要素によってアクセスを許可します。

セキュリティプリンシパル — 誰に許可するか（ユーザー、グループ、サービスプリンシパル、マネージド ID）
ロール定義 — 何を許可するか（許可されるアクションのセット。例: 'Contributor'）
スコープ — どこで許可するか（管理グループ、サブスクリプション、リソースグループ、個々のリソース）

この 3 つの要素を組み合わせることで、ロール割り当てが作成されます。ロールは階層の下位に継承されるため、管理グループで割り当てたロールは、その下にあるすべてのサブスクリプションに適用されます。

# Assign the Reader role at a management group level:
az role assignment create \
  --assignee 'user@company.com' \
  --role 'Reader' \
  --scope '/providers/Microsoft.Management/managementGroups/LandingZones'

組み込みロールとカスタムロール

Azure には、一般的なシナリオ（Owner、Contributor、Reader、サービス固有のロール）に対応する100 種類を超える組み込みロールが用意されています。ほとんどのエンタープライズのユースケースでは、組み込みロールで十分です。ただし、組み込みロールのどれにも一致しない権限が必要な場合、たとえば VM の読み取りはできるが削除はできないロールが必要な場合は、最小権限の原則に従って、必要な権限だけを持つカスタムロールを作成できます。

# Create a custom role:
az role definition create --role-definition '{
  "Name": "VM Operator",
  "Description": "Can start and stop VMs but cannot create or delete them",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/powerOff/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "NotActions": [],
  "AssignableScopes": ["/subscriptions/<subscription-id>"]
}'

グループベースのアクセス割り当て

可能な限り、個々のユーザーではなくEntra ID グループにロールを割り当てます。グループにロールを割り当てると、すべてのメンバーがそのロールを継承します。そのため、アクセス権の追加や削除は、複数のスコープにあるロール割り当てを変更するのではなく、グループにユーザーを追加または削除するだけで行えます。これにより管理の負担が大幅に軽減され、同じ職務を担当するチームメンバー間でアクセス権を一貫させることができます。

# Create a group and assign a role to the group:
az ad group create \
  --display-name 'ProductionContributors' \
  --mail-nickname 'prod-contributors'

az role assignment create \
  --assignee '<group-object-id>' \
  --role 'Contributor' \
  --scope '/subscriptions/prod-subscription-id'

Privileged Identity Management (PIM)

Privileged Identity Management (PIM)は、Azure リソースと Entra ID ロールへのJust-In-Time (JIT) 特権アクセスを提供する Entra ID サービスです。ユーザーに Owner や Global Administrator のアクセス権を永続的に付与するのではなく、特権ロールの適格者として登録し、昇格されたアクセス権が必要になったときにアクティブ化を要求してもらいます。アクティブ化には、MFA、理由の入力、指定された承認者による承認を必須にできます。

# Workflow with PIM:
# 1. Security team makes 'alice@company.com' eligible for 'Owner' on prod subscription
# 2. Alice requests activation via PIM portal or myaccess.microsoft.com
# 3. Alice provides justification: 'Emergency patching for CVE-2026-1234'
# 4. Manager approves the request (optional step)
# 5. Alice receives Owner access for 4 hours, then access expires automatically
# 6. All activation events are logged in Entra ID audit logs

エンタープライズにおける PIM の利点

PIM は、エンタープライズ環境に次のようなセキュリティ上の利点をもたらします。

攻撃対象領域の縮小 — 侵害される可能性のある永続的な管理者アカウントが存在しません
監査証跡 — すべてのアクティブ化が、タイムスタンプ、理由、承認者とともに記録されます
アクセスレビュー — 定期的なレビューを実施し、どのユーザーを引き続き適格者とするかを管理者が確認できます
期間限定のアクセス — 承認されたアクセスも自動的に期限切れになるため、昇格された権限が放置されるのを防げます

RBAC モデルの設計

適切に設計されたエンタープライズ RBAC モデルは、通常、次の階層で構成されます。

管理グループレベル — ガバナンスチームに幅広い閲覧アクセスを付与し、ポリシーを割り当てます
サブスクリプションレベル — 1 つのサブスクリプションを管理するアプリケーションチームに、チーム単位の Contributor アクセスを付与します
リソースグループレベル — サービス固有のロールを付与します（例: BLOB へのアクセスだけが必要なアプリに Storage Blob Contributor を付与します）
リソースレベル — きめ細かな制御が必要な例外的な場合にのみ使用します

サービスプリンシパルとマネージド ID

アプリケーションや自動化されたプロセスでは、Azure への認証にユーザーアカウントを使用しないでください。代わりに、次を使用します。

サービスプリンシパル — Entra ID に登録されたアプリケーションで、クライアント ID とシークレットまたは証明書を使用します。CI/CD パイプラインやオンプレミスの自動化で使用されます
マネージド ID — Azure でホストされるリソース（VM、App Service、AKS）向けに自動的に管理される資格情報です。管理やローテーションが必要なシークレットはありません

サービスプリンシパルとマネージド ID には、必要最小限の RBAC ロールを割り当ててください。

# Assign a role to a managed identity:
az role assignment create \
  --assignee-object-id '<managed-identity-object-id>' \
  --assignee-principal-type ServicePrincipal \
  --role 'Storage Blob Data Contributor' \
  --scope '/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>'

リソースアクセスの条件付きアクセス

Entra ID の条件付きアクセスポリシーは、認証の判断にインテリジェンスを追加します。Azure リソースの管理では、管理者アクセス（Azure portal、CLI）を次の条件を満たす場合にのみ許可できます。

準拠しているデバイス（Intune で管理されているデバイス）
名前付きの場所（企業ネットワークまたは VPN）
MFA 実行後（特権操作では常に適用）

条件付きアクセスと PIM を組み合わせることで、Azure 管理アクセスのセキュリティ体制を大幅に強化できます。

アクセスレビュー

Entra ID のアクセスレビューを使用すると、ユーザーが現在も付与されたアクセスを必要としているかどうかを管理者が定期的に確認できます。レビューはリソース所有者または管理者に委任でき、各ユーザーについて「このユーザーは引き続きアクセスを必要とする」または「このアクセスを削除する」と回答します。アクセスレビューは四半期ごとにスケジュールでき、承認されなくなったアクセスの削除を自動化して、時間の経過に伴うアクセス権の肥大化を防止できます。

緊急アクセスアカウント

すべてのエンタープライズでは、少なくとも 2 つの緊急アクセス（ブレークグラス）アカウントを維持する必要があります。これらは、条件付きアクセスや MFA の要件で保護されていないグローバル管理者アカウントです（代わりにハードウェア FIDO2 キーを使用します）。これらのアカウントは、Entra ID または MFA のシステムが利用できず、通常の管理者アカウントにアクセスできない場合にのみ使用します。緊急アクセスアカウントが使用された場合は、直ちにセキュリティアラートを発生させ、厳格に監査してください。

クイックチェック

このレッスンで学習した Microsoft Azure Fundamentals (AZ-900) の概念について、理解度を確認します。

レッスンのまとめ

このレッスンでは、エンタープライズ RBAC で管理グループ、サブスクリプション、リソースグループのスコープにおけるグループベースの割り当てを使用すること、Privileged Identity Managementによってジャストインタイムアクセスを提供し、永続的な管理者ロールをなくせること、アプリケーション認証にはユーザーアカウントではなくマネージド IDとサービスプリンシパルを使用することを学びました。おめでとうございます。AZ-900 トラックのエンタープライズアーキテクチャとガバナンスのセクションを修了しました。

よくある質問