サービス プリンシパルについて
サービス プリンシパルにより、パイプライン、アプリケーション、ソフトウェアを認証する方法が提供されます。 このユニットでは、サービス プリンシパルがデプロイ パイプラインで重要である理由、それらが Azure のセキュリティ モデルにどのように適合するか、それらがどのように動作するかについて説明します。
パイプラインを認証する必要がある理由
Bicep テンプレートをデプロイする場合、Azure リソースを作成または変更するように Azure Resource Manager に適切に指示します。 この例のシナリオでは、玩具会社の Web サイトをデプロイするために Bicep テンプレートを作成しました。 Bicep テンプレートにより、Azure App Service プラン、アプリ、Application Insights インスタンスを含むリソースが宣言されます。
テンプレートをデプロイすると、Resource Manager により、リソースが存在するかどうかがチェックされます。 存在しない場合は、Resource Manager によって作成されます。 既に存在する場合、Resource Manager によって、構成がテンプレートで指定した構成と一致しているか確認されます。
これらのどの操作も Azure リソースにアクセスして変更を加えるため、アクセス許可が必要です。 デプロイに必要な特定のアクセス許可は、テンプレートに含まれるものによって異なります。 玩具会社の Web サイトのサンプル Bicep テンプレートをデプロイするには、デプロイ先のリソース グループ内で次のアクセス許可が必要になります。
- デプロイを作成する権限。 デプロイは、
Microsoft.Resources/deploymentsタイプのリソースと見なされます。 - App Service プランとアプリを作成および変更する権限。
- Application Insights インスタンスを作成および変更する権限。
これまでは、多くの場合、Azure CLI または Azure PowerShell を使用して自分で Bicep テンプレートをデプロイしていました。 これらのツールを使用する場合、通常は自分のユーザー アカウントを使用し、ブラウザーを使用して認証を行います。 これは、自分の ID を使用して呼び出されます。 デプロイを送信すると、Bicep テンプレートで指定した内容を実行するのに必要なアクセス許可が ID にあるかどうかが Azure によって検証されます。
パイプラインに移動した後は、ユーザーが直接関与することなくパイプラインでデプロイ自体が実行されるため、別の種類の ID を使用する必要があります。
セキュリティ プリンシパルの種類
Microsoft Entra ID は、Azure の ID を管理するサービスです。 Microsoft Entra ID には複数の種類の ID があり、これらは "セキュリティ プリンシパル" とも呼ばれます。
- "ユーザー" は、通常、ブラウザーを使用して対話形式でサインインする人間を表します。 ユーザーには、多くの場合、サインイン時に実行する追加のセキュリティ チェックがあります。多要素認証 (MFA) や、場所やネットワークに基づく条件付きアクセスなどです。
- "グループ" は、ユーザーの集合を表します。 グループは、直接認証を行うのではなく、一連のユーザーにアクセス許可をまとめて割り当てる便利な方法です。
- "サービス プリンシパル" は、通常は人間が直接実行しない自動化されたプロセスまたはシステムを表します。
- "マネージド ID" は、人間が認証プロセスに関与しない状況のために設計された特別な種類のサービス プリンシパルです。
サービス プリンシパル
サービス プリンシパルは、アカウントの一種です。 これは、Microsoft Entra ID にサインインできますが、サインインして認証プロセスを操作する人間はいません。 サービス プリンシパルでは、MFA や同様の保護は使用されません。それらは、人が自分の身元を証明するために何かを行う必要があるためです。
Microsoft Entra ID では、サービス プリンシパルは、"アプリケーション ID" と資格情報によって識別されます。 アプリケーション ID は、グローバルに一意の ID (GUID) です。 パイプラインでは通常、資格情報は "キー" と呼ばれる強力なパスワードです。 また、資格情報として "証明書" も使用できます。
マネージド ID
他の種類のサービス プリンシパルとは異なり、マネージド ID の場合、資格情報を知っていたり、保守したりする必要はありません。 マネージド ID が Azure リソースに関連付けられます。 Azure は資格情報を自動的に管理します。 リソースが何かにアクセスする必要がある場合、Azure は資格情報を使用して自動的にサインインします。
マネージド ID は、仮想マシンや App Service アプリなど、Azure でホストされるリソースに対して使用できます。 これらは、Azure 管理の自動化、データベースへの接続、Azure Key Vault からの秘密データの読み取りなどの状況で、Azure リソースが自身を認証するための優れた方法です。 また、他のシナリオのために、Azure Arc でマネージド ID を使用することもできます。
パイプラインを使用する場合は通常、マネージド ID は使用できません。 これは、マネージド ID では、デプロイを実行する Azure リソースを所有および管理する必要があるためです。 Azure Pipelines を使用する場合は通常、Microsoft によって提供される共有インフラストラクチャに依存します。
Note
パイプラインでマネージド ID を使用できる状況もあります。 Azure Pipelines では、独自の Azure ベースの仮想マシンを使用することで、パイプラインのスクリプトとコードを実行する "セルフホステッド エージェント" を作成できます。 仮想マシンを所有するため、それにマネージド ID に割り当てて、パイプラインから使用できます。
ただし、ほとんどの場合、パイプラインは、"ホステッド エージェント" (Microsoft が管理するサーバー) を使用して実行されます。 ホステッド エージェントは、現時点では、マネージド ID と互換性がありません。
ヒント
ソリューションのその他の部分で、マネージド ID を使うか、通常のサービス プリンシパルを使うかを選べる場合は、マネージド ID を使うのが最善です。 その方が、作業が簡単で、通常はいっそう安全です。
自分のユーザー アカウントを使用できない理由
完全に機能するユーザー アカウントがあるのに、パイプラインを認証するためだけに、このまったく新しい種類のオブジェクトを作成する必要があることについて疑問を持たれるかもしれません。
ユーザー アカウントは、無人使用のために設計されていません。 ユーザー アカウントの認証プロセスでは、多くの場合、サインインしようとしているのが人間であるかがチェックされます。 さらに、組織は認証時に追加のセキュリティ チェックを使用します。 これらのチェックには、MFA、CAPTCHA チェック、ユーザーが使用するデバイスとネットワークの検査などが含まれます。これらにより、サインイン要求の正当性を検証できます。
パイプラインは、誰もアクティブに実行していない場合でもデプロイを実行できるように設計されています。 実際に、パイプラインのほとんどの利点は、完全に自動化されていて、人間の介入を必要としないという事実に由来します。 ユーザー名とパスワードをパイプラインに保存し、それらを使用してサインインしようとしても、機能しないはずです。 これらが機能しているように見える場合でも、今後、Microsoft Entra ID または組織の管理者がユーザー認証プロセスにセキュリティ チェックをさらに追加すると、すぐに機能しなくなります。
警告
また、ユーザー名とパスワードを任意の場所に保存するのは、他のユーザーがアクセスし、それらを使用してなりすましを行う可能性があるため、適切ではありません。
このような理由から、Azure とやり取りする組み込みのパイプライン タスクでは、ユーザー アカウントの資格情報を指定できません。 この場合、サービス プリンシパルを使用する必要があります。
サービス プリンシパルのしくみ
サービス プリンシパル、または Azure portal や Microsoft Graph API などのツールを使用するとき、さまざまな用語が使用されているのを目にすることがあります。 パイプラインでサービス プリンシパルを使用するためだけにこれらの用語を理解する必要はありませんが、概念について少し知っておくと便利です。
サービス プリンシパルは、Microsoft Entra ID の機能です。 Microsoft Entra ID はグローバル ID サービスです。 多くの会社が Microsoft Entra ID を使用しており、各会社は "テナント" と呼ばれます。
Microsoft Entra ID には "アプリケーション" という概念があり、システム、ソフトウェア、プロセス、または人間ではないその他のエージェントを表します。 デプロイ パイプラインはアプリケーションと考えることができます。
Microsoft Entra ID では、アプリケーションは、認証およびパイプライン デプロイの範囲を超えた多くのことを実行できます。 アプリケーションを作成し、それについて Microsoft Entra ID に知らせる場合、"アプリケーション登録" と呼ばれるオブジェクトを作成します。 アプリケーション登録は、Microsoft Entra ID でのアプリケーションを表します。
サービス プリンシパルとアプリケーションは緊密にリンクされます。 アプリケーション登録が Microsoft Entra テナントに追加されるたびに、その Microsoft Entra テナントで "サービス プリンシパル" オブジェクトが作成されます。 Azure portal でサービス プリンシパルを確認すると、関連性がないように見えるその他の機能と構成が数多く表示されます。 この主な理由は、サービス プリンシパルがアプリケーションにリンクされているためです。
サービス プリンシパルを作成すると、使用するほとんどのツールでもアプリケーション登録が同時に作成されます。 そのため、2 つの異なるオブジェクトが存在することに気付かない場合があります。
サービス プリンシパルの一種であるマネージド ID は、アプリケーション登録に関連付けられません。 既に説明したように、マネージド ID の構成と資格情報はAzure によって管理されます。
Note
サービス プリンシパルは、"エンタープライズ アプリケーション" と呼ばれることもあります。 使用される名前はツールによって異なります。 "ローカル ディレクトリ内のマネージド アプリケーション" というサービス プリンシパルが表示される場合もありますが、これらはマネージド ID と同じものではありません。
要約すると、サービス プリンシパルを作成する場合、最初にアプリケーション登録を作成し、次にそのアプリケーション登録を使用するためにサービス プリンシパルを作成します。 使用するほとんどのツールでは、これは自動的に行われるため、ユーザーがこれを認識することはありません。 デプロイ パイプラインを使用するとき、Microsoft Entra アプリケーションのすべての機能は使用しない可能性があります。 ただし、サービス プリンシパルはアプリケーションに関連しているため、同じ Microsoft Entra オブジェクト構造が適用されます。