Azure SQL への接続情報を外部ベンダーと共有しない——Entra ID の認証梯子で「鍵を渡さない設計」を組む

外部ベンダーや受託開発者にDB接続情報（ID/パスワード）を渡す運用は、今すぐ替えられる。
Microsoft Entra ID のマネージドID・サービスプリンシパルを使えば、**パスワードなしに「身分認証・名前指定の最小権限・失効制御」**を組める。
4段の梯子（Basic → サービスアカウント → サービスプリンシパル → マネージドID）のどこに乗るかが判断の核心で、GUIツールの制限とライセンス条件がその判断を左右する。

共有パスワード運用の4つの構造問題

DB接続情報（ユーザー名とパスワードの組み合わせ）を外部の作り手と共有する運用には、次の4つの問題が構造として組み込まれている。

追えない：誰がいつDBに接続したか、共有アカウントでは個人単位の追跡ができない。監査ログを取っても「account1というアカウントが接続した」としか見えない。

回せない：パスワードを複数人に渡した後で変更しようとすると、全員の接続設定を同時に更新する調整コストが発生する。「まあ変えなくていいか」が常態化する理由はここにある。

全権：接続情報を持っていれば、そのアカウントに紐づく権限を丸ごと使える。外部の作り手に「Read Onlyでいい」と思っていても、共有した接続情報がadminアカウントのものであれば全権が渡る。

気づけない：接続情報が漏洩しても、それが「内部者の流出」なのか「外部からの窃取」なのかを特定しにくい。被害規模の把握に時間がかかる。

認証情報の侵害を含む漏洩インシデントは、特定・封じ込めに平均292日を要し、1件あたり平均コストが481万ドルに達する（IBM「Cost of a Data Breach Report 2024」・2024年7月、認証情報侵害全般の数値）。また、Verizonの2025年版DBIRでは全侵害の22%が盗まれた認証情報を初期アクセスに使用しており、基本的なWebアプリ攻撃の88%で盗まれた認証情報が使われている（Verizon「2025 Data Breach Investigations Report」・2025年）。これらは共有パスワード専用の統計ではなく認証情報漏洩全般のデータだが、4つの構造問題を抱えたまま外部接続を続けることのリスク感覚として参照できる。

判断の核心：認証と認可は別物

設計の前提として押さえておくべき区別がある。認証（Authentication）は「誰か」を確認すること、認可（Authorization）は「何ができるか」を決めること——この2つは別々の仕組みで制御できる。

Entra ID によるマネージドID接続を Azure SQL で設定する場合、まず Entra が身分を確認し（認証）、次に DB 側で CREATE USER [<app-service-name>] FROM EXTERNAL PROVIDER を実行して「この身分にはどの権限を開けるか」を個別に定義する（認可）。身分が確認できても、DB側で権限を開けていなければ触れる範囲はゼロだ（Microsoft Learn「Securely connect .NET apps to Azure SQL Database using Managed Identity」・2025年）。

ここが共有パスワード運用との決定的な違いで、共有パスワードは認証と認可が実質的に一体化している。パスワードを持っていること自体が全権の証明になってしまう。

4段の梯子：上段ほど漏れる秘密が減る

接続設計には4段の梯子がある。Microsoft は「プログラムアクセスにはマネージドIDが第一選択。使えない場合のフォールバックとしてサービスプリンシパルを使用する」と明示している（Microsoft Learn「Managed identities for Azure resources overview」・2025年）。

段4のマネージドIDは、Azure App Service・Azure Functions 等の Azure リソースに直接紐づく「システム割り当て」と、複数のリソースで共有できる「ユーザー割り当て」の2種類がある。システム割り当てはリソース削除時に自動削除されるため、権限の剥奪漏れが起きにくい。どちらも開発者がシークレットを保持する必要がなく、Azureが自動的にクレデンシャルを管理する。

段3のサービスプリンシパルは、Entra ID にアプリを登録すると作成されるアプリIDだ。GitHub ActionsやCI/CDパイプラインなど、Azure外から Azure SQL へ接続する用途ではマネージドIDが使えないため、SPが実質的な上位選択肢になる。ただし、SPはクライアントシークレット（最大24ヶ月）のローテーション管理が必要な点で段4より手間がかかる。また、SPのアプリオンリーアクセスはテナント全体へのアクセス権限を持つ可能性があるため、ユーザーコンテキストが使えるならSPを使わないことが公式に推奨されている（Microsoft Learn「Microsoft Entra Service Principals with Azure SQL」・2025年）。SPを使う判断をした場合は、DB側の権限付与を最小限に絞ることがより重要になる。

判断が分かれるポイント：GUIツールの制限

「では全部マネージドIDに替えよう」とはならない場合がある。Power Automate や Power BI を使っている構成では、コネクタの対応範囲によってSP認証自体が使えないケースがある。

Power Automateにおけるサービスプリンシパルのサポート状況（2026年時点の仕様）：

（Microsoft Learn「Support for service principal owned flows」・2025年）

つまり、SharePoint・Outlook・Teamsを使うフローでは、段3（SP）どころか段4（マネージドID）への完全移行は現時点では難しい。デリゲートユーザーコンテキスト——実在するユーザーアカウントの権限を委任して使う方式——が引き続き必要になる。この場合は専用のサービスアカウント（段2）を使い、個人アカウントの共用を避ける、パスワードを厳密に管理するという現実的な対応になる。

Power BIでも、マネージドSPを使う1時間を超えるワークフローは失敗するという制限がある（Microsoft Learn「Automate Power BI Premium workspace and semantic model tasks with service principals」・2025年）。マネージドIDやSPに移行したとしても、長時間処理では追加の設計が必要になる。

コネクタ全体を網羅したSP対応の公式リストは存在しない。Dataverse対応・SharePoint/Outlook/Teams非対応は公式確認済みだが、それ以外のコネクタは個別のドキュメントを確認する必要がある。

設計時に詰める4つのチェック

梯子の段を決めた後、以下4点を設計段階で確認する。これを省くと、後から統制が取れなくなる。

1. 権限は名前指定・最小権限で

Entra ID で身分を認証したうえで、DB側の権限は CREATE USER [identity-name] FROM EXTERNAL PROVIDER のあとに GRANT SELECT ON [schema].[table] TO [identity-name] のように特定テーブルへの特定操作だけを開ける。adminロールや広範なスキーマ権限を渡さない。

外部の作り手には「どのIDに・どのSQLで権限を付与するか」の手順書だけを渡す。実際のID作成とロール割り当ては発注側の管理者が実行する。これが build/bind 分割——外部が設計（build）し、内部が紐づけ（bind）する役割分離だ。

2. 失効の設計（CAEの対応状況に注意）

「身分を消せばアクセスが切れる」は正確ではない。CAE（Continuous Access Evaluation：継続的アクセス評価）対応アプリでは即時失効が可能だが、CAE非対応アプリではアクセストークンの有効期限（通常最大1時間）が切れるまで待つ必要がある（Microsoft Learn「Revoke user access in an emergency in Microsoft Entra ID」・2025年）。

「プロジェクト終了後は即日アクセスを切りたい」という要件がある場合、接続先のアプリがCAEに対応しているかを事前に確認する。システム割り当てマネージドIDを使っている場合は、Azureリソースごとライフサイクルが連動するため、リソース削除＝権限削除になる。

JIT（Just-In-Time）アクセスを実現したい場合は、Entra PIM（Privileged Identity Management）を使う選択肢がある。必要な時間帯だけ権限を有効化し、期限が来たら自動的に特権ロールが外れる仕組みだ（Microsoft Learn「What is Privileged Identity Management?」・2025年）。ただしPIMの利用にはMicrosoft Entra ID P2またはMicrosoft Entra ID Governanceライセンスが必要で、無料・P1では使えない。顧客環境のライセンスを確認したうえで設計に含めるかどうかを判断する。

3. 監査ログの保持期間

アクセス記録を「追える」状態にしておくには、ログの保持期間がライセンスに依存する点を把握しておく（Microsoft Learn「Microsoft Entra data retention」・2025年）。

Azure Monitor へのルーティングを設定すれば、E5なしでもカスタム保持期間が設定できる。監査要件がある場合は、ログの保持先と保持期間を最初に確認する。

4. SP使用時のシークレットローテーション

段3（SP）を選んだ場合、クライアントシークレットの有効期限（最大24ヶ月）を管理するフローが必要になる。Key Vault に格納し、期限切れ前に自動ローテーションする仕組みを組まないと、ある日突然接続が切れる。Power Automate でSP所有フローを使う場合は標準の90日接続期限切れが発生しないメリットはあるが（Microsoft Learn「Support for service principal owned flows」・2025年）、シークレット自体の期限管理は別途必要だ。

外部の作り手がいる環境でこの設計を提案したい場合

自分がフリーランス・受託開発者の立場で、顧客に「鍵を渡さない接続設計」を提案するケースを考える。

渡すものと渡さないものの区別を整理すると：

• 渡すもの：DB側でのユーザー作成SQL・権限付与SQL・Entra SP登録手順書
• 渡さないもの：接続文字列・クライアントシークレット・管理者アカウントのパスワード

実際の接続設定・シークレットの管理・本番への反映は顧客側の管理者が実行する。開発者は動作確認用に開発環境向けの限定的なアクセスだけを受け取り、本番データには直接触らない設計にする。

この設計の前提・根拠・内部リンクは「AI外部委託のマクロ設計（build/bind分割・経営説明責任）」の観点から掘り下げている記事がある。

→ 関連記事：外部AIパートナーへの情報開示設計——鍵もPIIも預けない委託の作り方

段ごとの限界を誠実に整理する

「マネージドIDに移行すれば完全にセキュアになる」とは言えない。現時点での制約を整理しておく。

• GUIコネクタの対応制限：Power AutomateのSharePoint・Outlook・TeamsではSP認証が使えない（2026年時点）。デリゲートユーザーコンテキストが必要な構成では、段2止まりが現実的な選択になる
• 即失効の条件：CAE非対応アプリではトークン有効期限（通常最大1時間）まで猶予がある。「即日切断保証」は環境によって成立しない
• PIMのライセンス：JITアクセス制御にはEntra ID P2以上が必要。全ての顧客環境で使えるとは限らない
• 長時間処理の制限：Power BIでマネージドSPを使う1時間超のワークフローは失敗する制限がある
• 監査ログの追跡可能性：Free/Basicでは7〜30日しか保持されない。インシデント対応に必要なログ期間を確保するには有料ライセンスが必要

この制約リストは「だから使えない」という話ではなく、「どこからどこまでが有効か」の範囲を確認するためのものだ。

まとめ

外部へのDB接続は「誰か確認する認証」と「何ができるか制御する認可」を分離し、上段の梯子（マネージドID・SP）で設計するのが現代の標準だ。ただし、GUIツールの対応制限・即失効の条件・ライセンス要件が設計の有効範囲を決める——これを把握したうえで選択することが、3年後に統制を維持するための判断軸になる。

次の一歩：Azure SQL のパスワードレス接続は Microsoft Learn「Tutorial: Connect an App Service app to SQL Database without secrets using a managed identity」から動作確認できる。まず開発環境で CREATE USER ... FROM EXTERNAL PROVIDER の動作を確認し、接続文字列からパスワードが消えることを自分の目で確認するのが最短の理解経路だ。

関連記事：Dataverse のビュー・フィルターによる行レベルアクセス制御（入口の認証＋DB内の権限制御で両輪が揃う）