Cloud & IT Cert Prep · レッスン

ユーザー、グループ、ロールの割り当て

Entra ID でユーザーとグループを作成し、組み込みの RBAC ロールを割り当てて Azure リソースへのアクセスを制御するとともに、最小権限の原則を適用します。

「ユーザー、グループ、ロールの割り当て」はCoddyKit上の無料Cloud & IT Cert Prepレッスンです。これはレッスン2/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはCloud & IT Cert Prep学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Cloud & IT Cert Prepコースには全4レッスンが含まれています。

Azure RBAC: ロールベースのアクセス制御

Azure Role-Based Access Control (RBAC) は、Azure リソースに対して誰が何を実行できるかを制御する認可システムです。個人に直接アクセス許可を割り当てるのではなく、特定のスコープでセキュリティプリンシパル（ユーザー、グループ、サービスプリンシパル、マネージド ID）にロールを割り当てます。この分離により、組織の成長に伴ってもアクセス許可を管理しやすくなります。

RBAC の 3 つの概念

すべての RBAC の割り当てには 3 つの要素があります。セキュリティプリンシパルはアクセスを付与される対象（ユーザー、グループ、マネージド ID）です。ロール定義は許可される操作（VM の読み取り、ストレージへの書き込みなど）です。スコープはアクセスが適用される範囲で、広い順に、管理グループ、サブスクリプション、リソースグループ、個別のリソースがあります。アクセス許可はスコープ階層に沿って下位に継承されます。

# View all role assignments in a subscription
az role assignment list \
  --output table

# Check your own permissions on a resource
az role assignment list \
  --assignee <your-user-principal-name> \
  --output table

組み込みロールの概要

Azure には数百種類の組み込みロールがあります。すべてのリソースタイプで最もよく使用される 4 つは次のとおりです。Owner — 他のユーザーへのロール割り当てを含む完全なアクセス。Contributor — リソースの作成と管理に関する完全なアクセス。ただし、他のユーザーにアクセスを付与することはできません。Reader — 閲覧のみのアクセス。User Access Administrator — 自身がリソースを操作することなく、ロールの割り当てを管理できます。

# List all built-in roles
az role definition list \
  --custom-role-only false \
  --query '[].{Name:roleName, Id:name}' \
  --output table | head -20

ロールの割り当て

ロールの割り当てにより、指定したセキュリティプリンシパルに対して、指定したスコープでロール定義に定められたアクセス許可が付与されます。ロールの割り当てはすべての子スコープに伝播します。リソースグループレベルで Contributor を割り当てると、そのグループ内のすべてのリソースに Contributor のアクセス権が付与されます。サブスクリプションレベルで割り当てると、そのサブスクリプション内のすべてのリソースグループに対して Contributor のアクセス権が付与されます。

# Assign Contributor role to a user at resource group scope
az role assignment create \
  --assignee alice@yourcompany.com \
  --role Contributor \
  --resource-group myRG

# Assign Reader role to a group at subscription scope
az role assignment create \
  --assignee-object-id <group-object-id> \
  --role Reader \
  --scope /subscriptions/<subscription-id>

最小権限の原則

最小権限の原則とは、すべての ID に対して、業務を遂行するために必要な最小限のアクセス許可だけを付与するという考え方です。Azure RBAC では、書き込みが不要な場合は Contributor よりも Reader を優先し、サブスクリプションスコープよりもリソースグループスコープを優先します。また、可能な場合は、広範な Contributor ロールではなく、リソースレベルの具体的なロール（Storage Blob Data Contributor など）を使用します。

カスタムロール定義

要件に正確に一致する組み込みロールがない場合は、カスタムロールを作成できます。カスタムロール定義では、Actions（許可されるコントロールプレーン操作）、NotActions（許可される操作の集合から除外する操作）、DataActions（blob コンテンツの読み取りなど、リソースに対するデータプレーン操作）、AssignableScopes（ロールを割り当てられるサブスクリプションまたは管理グループ）を指定します。

{
  'Name': 'VM Operator',
  'Description': 'Can start, stop, and restart VMs but not delete or reconfigure them',
  'Actions': [
    'Microsoft.Compute/virtualMachines/start/action',
    'Microsoft.Compute/virtualMachines/restart/action',
    'Microsoft.Compute/virtualMachines/deallocate/action',
    'Microsoft.Compute/virtualMachines/read'
  ],
  'NotActions': [],
  'AssignableScopes': ['/subscriptions/<subscription-id>']
}

大規模なロール割り当てのためのグループ

個々のユーザーではなくグループにロールを割り当てることは、ベストプラクティスです。新しい開発者が DevTeam に加わった場合は、Entra ID の DevTeam セキュリティグループに追加するだけで済みます。その開発者は、Azure RBAC を変更しなくても、グループが保持するすべてのロール割り当てを自動的に継承します。この一元的な管理ポイントにより、退職時に監査や取り消しが難しくなる、個別に分散した割り当てを防止できます。

# Create a group and assign a role to it
az ad group create \
  --display-name 'DevTeam' \
  --mail-nickname DevTeam

# Assign role to the group
az role assignment create \
  --assignee-object-id <group-object-id> \
  --role Contributor \
  --resource-group dev-rg

自動化のためのサービスプリンシパル

サービスプリンシパルは、アプリケーション、スクリプト、自動化ツールが Azure に対して認証し、リソースにアクセスするために使用する ID です。ユーザー ID とは異なり、サービスプリンシパルには対話型サインイン機能がありません。Entra ID の App Registrations から作成し、適切なスコープで RBAC ロールを割り当てます。たとえば、CI/CD パイプラインに単一のリソースグループへの Contributor アクセスを付与して、インフラストラクチャをデプロイできるようにします。

# Create a service principal and assign Contributor to a resource group
az ad sp create-for-rbac \
  --name myCICDprincipal \
  --role Contributor \
  --scopes /subscriptions/<sub-id>/resourceGroups/myRG

拒否割り当て

拒否割り当ては、ロールの割り当てによって本来許可される場合でも、セキュリティプリンシパルによる特定の操作をブロックします。ロールの割り当てとは異なり、拒否割り当てを管理者が直接作成することはできません。ユーザーによる保護されたリソースの変更を防ぐため、Azure Blueprints またはマネージドアプリケーションによって付加されます。拒否割り当ては、一致するロールの割り当てよりも優先されます。

# List deny assignments in a resource group
az role assignment list \
  --include-deny-assignments \
  --resource-group myRG \
  --query '[?type==`Microsoft.Authorization/denyAssignments`]'

Privileged Identity Management (PIM)

Privileged Identity Management (PIM) は、Just-In-Time の特権アクセスを提供する Entra ID P2 の機能です。Owner や Global Administrator ロールを恒久的に割り当てるのではなく、ユーザーをそのロールの対象にします。必要なときに、承認ワークフローや理由の提示を必須にすることもでき、一定時間（1～8 時間など）だけ割り当てを有効化します。これにより、過剰な権限を持つアカウントによる常時の攻撃対象領域を大幅に縮小できます。

継続的なガバナンスのためのアクセスレビュー

Access Reviews（Entra ID P2）は、リソース所有者やマネージャーに対して、チームメンバーが現在のロール割り当てを引き続き必要としているか確認する、定期的な自動レビューです。レビュー担当者は、レビューインターフェイスからアクセスの継続を直接承認または拒否できます。これにより、役割の変更、プロジェクトの完了、従業員の退職後に残された古いアクセス許可を検出できます。これは、規制コンプライアンスプログラムにおける重要な要件です。

クイックチェック

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

レッスンのまとめ

このレッスンでは、Azure RBAC は特定のスコープでセキュリティプリンシパルにロールを割り当てること、最小権限の原則とは必要な最小限のアクセス許可だけを付与すること、そしてPIM は高い権限を持つロールを恒久的に割り当てる代わりに、Just-In-Time で有効化できるようにすることを学びました。次は、Entra ID の多要素認証と条件付きアクセスについて説明します。

よくある質問