サービス プリンシパルとキーを作成する

  • 6 分

サービス プリンシパルの概念を理解したので、サービス プリンシパルがその ID を Microsoft Entra ID に対してどのように証明するのか疑問を持たれるかもしれません。 このユニットでは、サービス プリンシパルの認証プロセスと資格情報について説明します。 また、サービス プリンシパルを作成し、それにキーを付与する方法についても説明します。

サービス プリンシパルの認証方法を理解する

Azure と通信する必要がある場合、サービス プリンシパルは Microsoft Entra ID にサインインします。 Microsoft Entra ID は、サービス プリンシパルの ID を検証した後、"トークン" を発行します。クライアント アプリケーションはこれを保存し、Azure に対して要求を行うときに使用します。

大まかに言うと、このプロセスは、ユーザーとして Azure にサインインするときの動作方法と似ています。 ただし、ユーザーと比較すると、サービス プリンシパルでは、身元を証明するために若干異なる種類の資格情報が使用されます。 サービス プリンシパルでは、キーと証明書という 2 つの主要な資格情報が使用されます。

Note

マネージド ID は、Azure 内で動作する特別なサービス プリンシパルであることに注意してください。 これらには、資格情報を知る必要や処理する必要がまったくない、異なる種類の認証プロセスが使用されます。

[キー]

キーはパスワードに似ています。 ただし、キーはより長く、より複雑です。 実際、ほとんどの状況で、Microsoft Entra ID では、次のことを保証するためにキー自体が生成されます。

  • キーは、"暗号的にランダム" になります。 つまり、推測が非常に困難です。
  • 人間が、誤って脆弱なパスワードをキーとして使用することはありません。

多くの場合、サービス プリンシパルには高い特権を持つアクセス許可が付与されるため、セキュリティで保護することが重要です。 キーは通常、サービス プリンシパルとパイプラインを最初に構成するときに、簡単に処理する必要があるのみです。 このため、キーは、覚えやすいものや、入力が簡単なものである必要はありません。

1 つのサービス プリンシパルは同時に複数のキーを所持できますが、ユーザーは複数のパスワードを所持できません。 パスワードと同様に、キーには有効期限があります。 これについては後ほど詳しく説明します。

Note

キーは、ストレージ アカウント キーと同様に、非常に重要なパスワードと考えてください。 これらは、同じレベルのセキュリティと注意深さで取り扱う必要があります。

証明書

証明書は、サービス プリンシパルを認証するもう 1 つの方法です。 これらは非常に安全ですが、管理が困難な場合があります。 一部の組織では、特定の種類のサービス プリンシパルに対して証明書を使用することを必須としています。

このモジュールでは、証明書については説明しません。 ただし、証明書認証を使用するサービス プリンシパルを使用する場合、サービス プリンシパルを管理し、パイプラインのアクセス許可を付与するという点で、他のサービス プリンシパルと基本的には同じ方法で使用します。

Note

証明書は、使用できる場合には適切なオプションです。 攻撃者がこれらを盗むのは困難です。 また、証明書を使用する要求を傍受して変更することも困難です。 ただし、証明書では、より多くのインフラストラクチャが必要であり、継続的なメンテナンスのオーバーヘッドが発生します。

サービス プリンシパルのキーを使用する

サービス プリンシパルを作成する場合は一般的に、キーを同時に作成するよう Azure に指示します。 通常、Azure によってランダム キーが生成されます。

Note

サービス プリンシパルのしくみについて前にした説明を思い出してください。 キーは、アプリケーション登録オブジェクトの一部として保存されます。 Azure portal を開き、Microsoft Entra の構成を確認し、アプリケーション登録に移動すると、そこでキーの作成と削除も実行できます。

サービス プリンシパルを作成すると、Azure によってキーが示されます。 Azure でキーが示されるのはこのときだけです。 その後では、取得できなくなります。 キーを安全にコピーすることが重要です。これにより、パイプラインを構成するときにそのキーを使用できます。 キーを電子メールや安全ではない別の方法で共有しないでください。 キーがわからなくなった場合は、それを削除して、新しいものを作成する必要があります。

Azure Pipelines のサービス プリンシパルを管理する

パイプラインのサービス プリンシパルのキーを作成する場合、すぐにキーをパイプラインの構成にコピーすることをお勧めします。 この方法により、不必要にキーを保存することや、送信することが避けられます。

パイプライン ツールには、サービス プリンシパルのアプリケーション ID とキーを指定する安全な方法が用意されています。 ソース管理ではどの種類の資格情報も保存しないでください。 代わりに Azure Pipelines を使用する場合は "サービス接続" を使用します。 このモジュールでは、サービス プリンシパルとキーを作成する方法についてのみ説明します。 後のモジュールで、キーを使用してパイプラインを構成する方法について説明します。

ヒント

Azure Pipelines では、サービス プリンシパルが自動作成されます。 このモジュールでは、行われていることをいっそう良く理解できるよう、サービス プリンシパルを手作業で作成して管理します。 他のモジュールでは、簡単な自動作成手法を使用します。

サービス プリンシパルとキーを作成する

Azure CLI を使用して、サービス プリンシパルの作成と管理を行うことができます。

Note

サービス プリンシパルの作成と変更には、Microsoft Entra ID での関連するアクセス許可が必要です。 組織によっては、管理者にこれらの手順を実行してもらう必要があります。

サービス プリンシパルとキーを作成するには、az ad sp create-for-rbac コマンドを使用します。 このコマンドは、複数の引数を受け取り、必要に応じて、サービス プリンシパルにロールを割り当てることができます。 この件については、このモジュールで後述します。 ここでは、Azure ロールの割り当てを使用せずにサービス プリンシパルを作成する方法の例を示します。

az ad sp create-for-rbac --name MyPipeline

このコマンドを実行すると、Azure CLI により、password プロパティを含む JSON 応答が返されます。 このプロパティは、サービス プリンシパルのキーです。 このキーは再取得できません。そのため、ただちに使用するか、安全な場所に保存する必要があります。

Note

az ad sp create-for-rbac コマンドを使用すると、Microsoft Entra ID でアプリケーション登録が作成され、Microsoft Entra テナントにサービス プリンシパルが追加され、アプリケーション登録のためのキーが作成されます。 別のコマンドの az ad sp create を使用すると、テナントで (アプリケーション登録ではなく) サービス プリンシパルのみが作成されます。 パイプラインのサービス プリンシパルを作成する場合は通常、az ad sp create-for-rbac コマンドを使用するのが最も適切です。

Azure PowerShell コマンドレットを使用して、サービス プリンシパルの作成と管理を行うことができます。

Note

サービス プリンシパルの作成と変更には、Microsoft Entra ID での関連するアクセス許可が必要です。 組織によっては、管理者にこれらの手順を実行してもらう必要があります。

サービス プリンシパルとキーを作成するには、New-AzADServicePrincipal コマンドレットを使用します。 このコマンドレットは、複数の引数を受け取ります。必要に応じて、サービス プリンシパルにロールを割り当てることができます。 この件については、このモジュールで後述します。 ここでは、Azure ロールの割り当てを使用せずにサービス プリンシパルを作成する方法の例を示します。

$servicePrincipal = New-AzADServicePrincipal -DisplayName MyPipeline

このコマンドを実行すると、Azure PowerShell によって、キーを含むサービス プリンシパルに関する情報が servicePrincipal 変数に設定されます。

$servicePrincipalKey = $servicePrincipal.PasswordCredentials.SecretText

このキーは再取得できません。そのため、ただちに使用するか、安全な場所に保存する必要があります。

Note

New-AzADServicePrincipal コマンドレットを使用すると、Microsoft Entra ID でアプリケーション登録が作成され、Microsoft Entra テナントにサービス プリンシパルが追加され、アプリケーション登録のためのキーが作成されます。

サービス プリンシパルを識別する

サービス プリンシパルには、それらを識別して操作するために使用する識別子と名前がいくつかあります。 よく使用する識別子を以下に示します。

  • アプリケーション ID: アプリケーション登録には、一意の識別子があります。多くの場合、これは "アプリケーション ID" (場合によっては "クライアント ID") と呼ばれます。 これは通常、サービス プリンシパルが Azure にサインインするときにユーザー名として使用されます。
  • オブジェクト ID:アプリケーション登録とサービス プリンシパルには、個別のオブジェクト ID があります。これは、Microsoft Entra ID によって割当てられる一意の識別子です。 場合によっては、サービス プリンシパルを管理するときに、これらのオブジェクト ID を使う必要があります。
  • 表示名: これは、サービス プリンシパルを説明する、人間が判読できる名前です。

ヒント

サービス プリンシパルには明確でわかりやすい表示名を使用してください。 誰かがサービス プリンシパルを誤って削除したり、そのアクセス許可を変更したりしないようにするために、その用途をチームが理解できるようにすることが重要です。

注意事項

表示名は一意ではありません。 複数のサービス プリンシパルが同じ表示名を共有する場合があります。 表示名を使用してサービス プリンシパルを識別し、アクセス許可を付与する場合には、注意が必要です。 間違ったサービス プリンシパルに誤ってアクセス許可を付与してしまう可能性があります。 代わりに、アプリケーション ID を使用することをお勧めします。

サービス プリンシパルを作成するとき、通常は表示名のみ設定します。 Azure により、他の名前と識別子が自動的に割り当てられます。

期限切れのキーを処理する

サービス プリンシパルには有効期限がありませんが、それらのキーにはあります。 キーを作成するとき、その有効期限を構成できます。 既定では、有効期限は 1 年に設定されます。 この有効期限が切れると、キーは機能しなくなり、パイプラインは Microsoft Entra ID にサインインできなくなります。 キーは定期的に更新または "ローテーション" する必要があります。

注意事項

キーに対して長い有効期限を設定したくなりますが、そうするべきではありません。 サービス プリンシパルは、資格情報によってのみ保護されます。 攻撃者がサービス プリンシパルのキーを取得した場合、大きな損害を被る可能性があります。 攻撃の続行期間を最小限にする最適な方法は、キーを定期的に変更することです。 また、キーが漏えいしたと考えられる場合、キーを削除し、再作成する必要があります。

サービス プリンシパルのキーをリセットするには、この例のように、アプリケーション ID を指定して az ad sp コマンドを使用します。

az ad sp credential reset --id "b585b740-942d-44e9-9126-f1181c95d497"

az ad sp credential delete コマンドを使ってから az ad sp credential reset --append コマンドを使う 2 つの個別のステップで、サービス プリンシパルのキーの削除と再作成を行うこともできます。

サービス プリンシパルのキーをリセットするには、最初に Remove-AzADServicePrincipalCredential コマンドレットを使用して既存の資格情報を削除します。 次に、New-AzADServicePrincipalCredential コマンドレットを使用して新しい資格情報を追加します。 これらの両方のコマンドレットでは、サービス プリンシパルを識別するために、そのオブジェクト ID が使用されます。 コマンドレットを使用する前に、アプリケーション ID からこの ID を取得する必要があります。

$applicationId = APPLICATION_ID
$servicePrincipalObjectId = (Get-AzADServicePrincipal -ApplicationId $applicationId).Id

Remove-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId

$newCredential = New-AzADServicePrincipalCredential -ObjectId $servicePrincipalObjectId
$newKey = $newCredential.SecretText

ヒント

1 つのサービス プリンシパルが複数のキーを所持できます。 古いキーがまだ有効である間に新しいキーを使用するようにアプリケーションを安全に更新でき、その後、古いキーが使用されなくなったときに削除できます。 この手法により、キーの有効期限が原因のダウンタイムを回避できます。

サービス プリンシパルのライフサイクルを管理する

作成する各サービス プリンシパルのライフサイクル全体を考慮することが重要です。 パイプラインのサービス プリンシパルを作成する場合、パイプラインが最終的に削除されたり、使用されなくなったときには、どのようなことが起こるでしょうか。

サービス プリンシパルは自動的に削除されないため、古いサービス プリンシパルを監査して削除する必要があります。 古いサービス プリンシパルを削除することが重要です。これは、古いユーザー アカウントを削除するのと同じ理由です。攻撃者がキーにアクセスできる可能性があります。 頻繁に使用しない資格情報は所持しないようにすることをお勧めします。

自分とチームが簡単にアクセスできる場所で、サービス プリンシパルを文書化することをお勧めします。 各サービス プリンシパルについて、次の情報を含める必要があります。

  • 名前やアプリケーション ID など、基本的な識別情報。
  • そのサービス プリンシパルの目的。
  • 作成者、それ自体とそのキーの管理担当者、問題発生時に回答を行う担当者。
  • それ自体に必要なアクセス許可と、それらが必要な明確な理由。
  • 予定されている有効期間。

サービス プリンシパルを定期的に監査して、それらがまだ使用されているかどうか、それらに割り当てられたアクセス許可がまだ正しいかどうかを確認する必要があります。