Python 用 Azure SDK ライブラリでの承認

Azure での承認によって、認証されたユーザーまたはサービスがリソースに対して実行できるアクションが決まります。 この記事では、 Azure SDK for Python を使用して承認を実装する方法について説明します。モデル、実装、トラブルシューティング、ベスト プラクティスについて説明します。 詳細な認証のセットアップについては、「 Azure に対する Python アプリの認証」を参照してください。

イントロダクション

認証 (AuthN) はユーザーまたはサービスの ID を検証しますが、 承認 (AuthZ) はユーザーが実行できる操作を定義します。 Azure では、承認により、アプリケーションとデータを保護するために重要なリソースへの安全なアクセスが保証されます。 開発者は、Azure SDK for Python で堅牢な承認を実装して、リソースの管理からサービス固有のデータへのアクセスまで、さまざまなワークフローでのアクセスを制御できます。

Azure 承認モデル

Azure には、アクセスを管理するための複数の承認メカニズムが用意されています。 これらのモデルを理解することは、効果的なアクセス制御に不可欠です。

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

Azure Role-Based アクセス制御 (RBAC) は、サブスクリプションやリソース グループなどのスコープで ID にロールを割り当てます。 組み込みロールには所有者、共同作成者、閲覧者が含まれますが、カスタム ロールではカスタマイズされたアクセス許可が許可されます。 特定のスコープでロールを割り当てると、ID (ユーザーやサービスなど) は、そのスコープとその子スコープ内のすべてのリソースに対するアクセス許可を取得します。 たとえば、サブスクリプション レベルで共同作成者ロールを割り当てると、そのサブスクリプション内のすべてのリソースを管理できます。 「Azure RBAC のスコープについて」を参照してください。

サービス固有のメカニズム

一部の Azure サービスでは、一意の承認方法が提供されています。

Azure SDK for Python で承認を使用する

Azure SDK for Python では、 azure-identity パッケージを介して認証と承認を処理するための組み込みのサポートが提供されます。 DefaultAzureCredential クラスは、マネージド ID やサービス プリンシパルなど、さまざまな環境に適応するさまざまな認証メカニズムをサポートします。

例: リソース グループを一覧表示する

この例では、Azure SDK for Python が資格情報 ( DefaultAzureCredential経由) を使用して認証する方法と、承認によって ID がリソース グループを正常に一覧表示できるかどうかを決定する方法を示します。 ID にサブスクリプションまたはリソース グループ スコープの閲覧者以上のロールがない場合、この呼び出しでは 403 Forbidden エラーが返されます。

from azure.identity import DefaultAzureCredential
from azure.mgmt.resource import ResourceManagementClient

credential = DefaultAzureCredential()
client = ResourceManagementClient(credential, "<subscription-id>")
resource_groups = client.resource_groups.list()
for rg in resource_groups:
    print(rg.name)

<subscription-id>を Azure サブスクリプション ID に置き換えます。これは通常、00000000-0000-0000-0000-000000000000の形式です。

スコープを含む Microsoft Graph

Microsoft Graph にアクセスするには、委任されたアクセス許可とアプリケーションアクセス許可の両方をサポートする公式の Microsoft Graph SDK for Python を使用します。

この例では、SDK が資格情報を使用して、必要な承認スコープ https://graph.microsoft.com/.default を持つアクセス トークンを要求し、Microsoft Graph リソースにアクセスする方法を示します。 ユーザー データを取得するには、適切なアプリケーションアクセス許可 ( User.Read.All など) を持つ Microsoft Entra ID で ID を承認する必要があります。それ以外の場合、要求は 403 Forbidden で失敗します。

Important

アプリまたは ID に、Microsoft Entra ID で付与された User.Read.All またはその他の必要なアクセス許可があることを確認します。

from azure.identity import DefaultAzureCredential
from msgraph.core import GraphClient

credential = DefaultAzureCredential()
client = GraphClient(credential=credential, scopes=["https://graph.microsoft.com/.default"])

response = client.get("/users")
users = response.json().get("value", [])
for user in users:
    print(user["displayName"])

この SDK の詳細については、Microsoft Graph を使用した公式の Python アプリのビルド に関するチュートリアルを参照してください。

承認エラーを診断する

承認の問題は、多くの場合、アクセス許可が不十分であることを示す HTTP 403 禁止エラーを引き起こします。 これらの問題を診断するには:

  • エラー メッセージを確認する: 不足しているアクセス許可の詳細については、応答を確認します。

  • ログ記録を有効にする: Pythonログを使用して、要求と応答を検査します。

    import logging
logging.basicConfig(level=logging.DEBUG)

  • アクセスの確認: Azure CLIまたはAzure ポータルを使用してロールの割り当てを確認します。

    az role assignment list --assignee <principal-id> --scope <scope>

    <principal-id>を、ユーザー、サービス プリンシパル、またはマネージド ID のオブジェクト ID に置き換えます。 <scope>を、サブスクリプション ID、リソース グループ名、リソースなどの Azure リソース スコープに置き換えます。 スコープの操作を参照してください。

スコープを操作する

多くの場合、次の例のようにスコープを指定する必要があります。

az role assignment list \
    --assignee <principal-id> \
    --scope <scope>

一般的なスコープ形式を次に示します。

スコープ レベル 値の例
Subscription /subscriptions/<subscription-id>
リソース グループ /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>
リソース名 /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/<provider-namespace>/<resource-type>/<resource-name>

たとえば、リソース グループ レベルでマネージド ID のすべてのロールの割り当てを一覧表示するには、次のようにします。

az role assignment list \
  --assignee 12345678-90ab-cdef-1234-567890abcdef \
  --scope /subscriptions/<subscription-id>/resourceGroups/my-resource-group

または、サブスクリプション レベルで次の手順を実行します。

az role assignment list \
  --assignee 12345678-90ab-cdef-1234-567890abcdef \
  --scope /subscriptions/<subscription-id>

ユーザーまたはマネージド ID のオブジェクト ID (<principal-id>) を取得するには、次の値を使用します。

az ad user show --id <user-email> --query id
az identity show --name <identity-name> --resource-group <rg-name> --query principalId

アクセスを管理する

ロールの割り当てを使用してアクセスを管理する方法:

  • Azureポータル: アクセス制御 (IAM) サービス メニューを使用してロールを追加します。

  • Azure CLI:

    az role assignment create --assignee <principal-id> --role <role-name> --scope <scope>

    <principal-id>を、ユーザー、サービス プリンシパル、またはマネージド ID のオブジェクト ID に置き換えます。 <scope>を、サブスクリプション ID、リソース グループ名、リソース名などの Azure リソース スコープに置き換えます。 スコープの操作を参照してください。

  • ARM テンプレート: 宣言型管理に使用します。

マネージド ID の場合は、仮想マシンなどのリソースに関連付けられている ID にロールを割り当てます。 Azure ポータルのアクセス確認機能またはAzure CLIを使用して、有効なアクセス許可を確認します。

サービス固有の承認に関する注意事項

「サービス固有のメカニズム」セクションでは、一部のAzure サービスで一意の承認方法が提供されていることを学習しました。 このセクションでは、前述の 3 つの Azure サービスのそれぞれについて詳しく説明します。

Azure Storage

  • RBAC: コントロール プレーン操作を管理します。
  • SAS と ACL: Microsoft Entra 認証もサポートされ、データ プレーンへのアクセスを制御します。

例: Microsoft Entra ID を使用して BLOB にアクセスする

from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

credential = DefaultAzureCredential()
client = BlobServiceClient(account_url="https://<account-name>.blob.core.windows.net", credential=credential)
containers = client.list_containers()
for container in containers:
    print(container.name)

<account-name>を Azure Storage アカウント名に置き換えます。

Azure Key Vault

一貫性を保つため、レガシ アクセス ポリシーの代わりに RBAC を使用します。 アクセス ポリシーは引き続きサポートされますが、推奨されません。

例: シークレットを取得する

from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient

credential = DefaultAzureCredential()
client = SecretClient(vault_url="https://<vault-name>.vault.azure.net", credential=credential)
secret = client.get_secret("my-secret")
print(secret.value)

<vault-name>を Key Vault リソース名に置き換えます。

Microsoft Graph

委任されたアクセス許可とデーモン アプリのアプリケーションアクセス許可に OAuth 2.0 スコープを使用します。 前の例に示すようにスコープを指定します。

ベスト プラクティス

  • 最小特権: 共同作成者ではなく閲覧者など、必要なアクセス許可のみを割り当てます。
  • RBAC を優先する: 特に、統合アクセス制御用の Key Vault の場合。
  • マネージド ID を使用する: コードで資格情報を管理しないようにします。
  • Graph のアクセス許可を制限する: リスクを最小限に抑えるために特定のスコープを要求します。

次のステップ

  • 最終更新: