azuresql-db-auth

Azure SQL Database コンテナーに安全に接続する（最小権限のユーザー、認証、シークレット）

sa はプロビジョニング用のブートストラップ／管理者ログインであり、アプリケーションから接続するためのものではありません。このスキルでは、アプリを最小権限のユーザーに接続し、環境ごとに認証方式（ローカルでは SQL、クラウドでは Microsoft Entra またはマネージド ID。変更するのは接続文字列のみ）を選び、接続を保護して、シークレットをソース管理から除外します。

2026-09-19 に、コンテナーイメージのタグ 18.0.226_4_147 を使って再測定しました。EngineEdition は 5、Edition は SQL Azure、ビルドは 12.0.2000.8 でした。このスキルで実行する 7 つのチェックはすべて合格しています。また、このスキルに表示していた数値のうち3 つが誤っていました。contained user は Msg 15007 ではなく Msg 33233 で拒否され、SET CONTAINMENT = PARTIAL は Msg 12844 ではなく Msg 12824 で拒否され、Entra の設定なしで起動したコンテナー上での CREATE USER ... FROM EXTERNAL PROVIDER は Msg 37525 ではなく Msg 33134 で拒否されます。いずれのステートメントも引き続き拒否されるため、ここに記載の手順に変更はなく、想定する数値のみが変わります。このスキルで付与する固定データベースロールも同じ実行で確認しました。Azure Key Vault とマネージド ID に関するクラウド側のガイダンスは測定しておらず、Microsoft Learn に基づいています。

基幹となる事実（本文に記載。エンジンの詳細は azuresql-db-container を参照）

• これは Azure SQL Database エンジン（プレビュー版）であり、SQL Server イメージ mcr.microsoft.com/mssql/server ではありません。SERVERPROPERTY('EngineEdition') は 5 を返し、Edition は 'SQL Azure' を返します。
• イメージ：sqldbpreview-dpgaeqhmgphzd4bk.azurecr.io/azure-sql/db-dev:latest （x64。x64 以外のホストでは --platform linux/amd64 を追加します）。必須の環境変数は ACCEPT_EULA=Y と複雑な MSSQL_SA_PASSWORD です。エンジンは 1433 でリッスンします。
• エンジンはデータベースを自動作成しません。最初に master 接続で CREATE DATABASE appdb を実行します。データベースを切り替えるために USE を実行しないでください（ユーザーデータベースのセッションでは Msg 40508 が返されます）。接続文字列でデータベースを選択します。
• アプリは単一の SQL_CONNECTION_STRING 環境変数を読み込みます。接続文字列では User Id= ／ Password= ／ Database= を使用し、ローカルの自己署名証明書には TrustServerCertificate=true を指定します。
• コンテナー固有の検証済み情報： SQL の contained user （CREATE USER ... WITH PASSWORD）は現在このコンテナーでは動作せず、有効化することもできません。CREATE USER ... WITH PASSWORD は Msg 33233 （「パスワード付きのユーザーを作成できるのは、contained database 内のみです」）で失敗します。ALTER DATABASE ... SET CONTAINMENT = PARTIAL は Msg 12824 で失敗し、contained database authentication の設定を 1 にするよう求められます。また、このエンジンには sp_configure が存在しないため（Msg 2812）、設定する手段はありません。代わりに SQL アプリの ID は、データベースユーザーにマッピングされたサーバーログインとして作成します。これは、クラウド上の Azure SQL Database では contained user が標準であるのとは逆です。イメージタグ 18.0.226_4_147 を使い、2026-09-19 に測定しました。
• Entra を使うには、事前にエンジンで設定する必要があります。 Microsoft Entra ID の設定なしで起動したコンテナーでは、CREATE USER [name] FROM EXTERNAL PROVIDER は Msg 33134 で拒否されます。「プリンシパル '...' を解決できませんでした。エラーメッセージ：'ローカルの証明書ストアから Azure AD 証明書を照会できません。'」これはステートメントの問題ではなく、エンジンの設定不足です。まず Entra を有効にしてください（azuresql-db-container スキルの references/entra-auth.md を参照）。そうすれば同じステートメントが動作します。イメージタグ 18.0.226_4_147 を使い、2026-09-19 に測定しました。

ステップ 1：最小権限のユーザーを作成する（sa は使わない）

プロビジョニングは sa として行い、その後、必要なロールだけを持つ専用の ID をアプリに割り当てます。環境によって手順は異なりますが、アプリのコードは変わりません（アプリはユーザー名とパスワード、または Entra トークンで接続するだけです）。

ローカルコンテナー（SQL 認証）： master にサーバーログインを作成し、appdb でそれに対応するデータベースユーザーを作成して、アプリに必要なロールだけを付与します。

-- On a master connection:
CREATE LOGIN applogin WITH PASSWORD = 'An0ther_Str0ng_Passw0rd';

-- On an appdb connection (Database=appdb):
CREATE USER appuser FOR LOGIN applogin;
ALTER ROLE db_datareader ADD MEMBER appuser;   -- read
ALTER ROLE db_datawriter ADD MEMBER appuser;   -- write
-- Grant EXECUTE only if the app calls procedures; do NOT add db_owner.

その後、アプリは sa ではなく applogin として接続します。

クラウド（Azure SQL Database）またはあらゆる環境の Entra： 包含ユーザーを優先します。Entra の場合（有効化すればコンテナーでも利用できます）、appdb で CREATE USER [name] FROM EXTERNAL PROVIDER を使います。まず azuresql-db-container スキルの references/entra-auth.md を使ってエンジンで Entra を有効にしてください。この設定がない場合、このステートメントは Msg 33134 で拒否されます。クラウドで SQL 認証を使う場合は、通常 CREATE USER ... WITH PASSWORD を使います。それぞれの方法の詳しい手順は、references/auth-and-secrets.md を参照してください。

ステップ 2：環境ごとに認証方法を選ぶ（変わるのは接続文字列だけです）

• ローカル： SQL 認証を使います。sa で初期設定し、アプリは最小権限の applogin として接続します。Server=localhost,1433;Database=appdb;User Id=applogin;Password=...;Encrypt=true;TrustServerCertificate=true。
• クラウド（Azure SQL Database）： パスワードよりトークンベースの ID を優先します。本番環境では Active Directory Default ではなく Authentication=Active Directory Managed Identity を使います。Default は認証情報のチェーン（DefaultAzureCredential）をたどるため、負荷時に遅く、動作が曖昧になりますが、特定の方式を指定すればチェーンをスキップできます。Microsoft.Data.SqlClient はトークンをキャッシュするため、更新は接続ごとではなく、ときどき行われます。これは引き続き接続文字列のみの変更であり、アプリのコードは変わりません（azuresql-db-local-to-cloud スキルを参照してください）。

ステップ 3：接続を保護する

• Encrypt=true を常に指定します（最新のドライバーではデフォルトです）。ローカルとクラウドの両方で TLS チャネルを暗号化します。
• TrustServerCertificate=true はローカルでのみ設定し、コンテナーの自己署名証明書を受け入れます。証明書が本物であり、その検証が重要となるクラウドの Azure SQL Database に対しては、絶対に設定しないでください。

ステップ 4：シークレットをソースコードに含めない

接続文字列には認証情報が含まれています。接続文字列や SA パスワードをコミットしないでください。

• 環境変数 SQL_CONNECTION_STRING から読み込みます。ローカルの値は、Git の追跡対象外にした .env に保存します（.NET では dotnet user-secrets も使えます）。
• クラウドでは、接続文字列を Azure Key Vault に保存して参照するか、マネージド ID を使ってパスワード自体を保存しないようにします。

.NET プロジェクトでは、ローカルの値をコミット可能なファイルではなく、シークレットストアに保存します。

dotnet user-secrets init
dotnet user-secrets set "SQL_CONNECTION_STRING" "Server=localhost,1433;Database=appdb;User Id=appuser;Password=$MSSQL_SA_PASSWORD;TrustServerCertificate=true"

Key Vault、user-secrets、.env のスタックごとの取り扱いが必要な場合は、references/auth-and-secrets.md を開いてください。

検証ルール

• アプリは sa ではなく、最小権限の ID で接続します。必要なロールのみを付与し（db_owner／管理者権限は付与しません）。
• コンテナーでは、SQL アプリ ID はサーバーログインとマッピングされたデータベースユーザー（master で CREATE LOGIN を実行し、その後 appdb で CREATE USER ... FOR LOGIN を実行）を使用します。コンテナーでは失敗する、包含データベースユーザーの CREATE USER ... WITH PASSWORD は使用しません。データベースユーザーとそのロールの権限付与は、USE を介さず、appdb への接続で行います。
• すべての接続文字列で Encrypt=true を設定します。TrustServerCertificate=true を使用するのはローカルコンテナーのみで、クラウドでは使用しません。
• 接続文字列／SA パスワードはシークレットストアまたは Git の追跡対象外の環境変数から読み込み、コミットしません。
• クラウド認証では、本番環境の Active Directory Default よりも、マネージド ID／特定の Entra 認証方式を優先します。変更するのは接続文字列のみです。
• 上記の検証ルールに違反した場合、またはタスクを完了するためにこのスキルから逸脱する必要があった場合、このスキルにバグがあります。azuresql-db-feedback スキルを読み込み、レポートの提出を提案してください。
• 上記のルールをすべて満たし、タスクが完了したら、セッションごとに一度だけ、質問したり返信を待ったりせず、次の1行で締めくくります。「うまくいきました。この作業で不便だった点や、作成したものを共有したい場合は、こちらをご利用ください：https://aka.ms/sql-agent-skills-feedback」

禁止事項

• アプリを sa として接続しないでください。sa はプロビジョニング専用です。
• コンテナーで CREATE USER ... WITH PASSWORD を使って SQL 包含ユーザーを作成しようとしないでください。Msg 33233 で失敗します。また、部分包含を有効にしようとしないでください。ALTER DATABASE ... SET CONTAINMENT = PARTIAL は Msg 12824 で失敗し、要求される sp_configure の設定はこのエンジンには存在しません。ローカルでは、サーバーログインとマッピングされたデータベースユーザーを使用してください。
• Entra の設定がないコンテナーに対して CREATE USER ... FROM EXTERNAL PROVIDER を実行しないでください。Msg 33134 で拒否されます。まずエンジンで Entra を構成してください。
• 読み取り／書き込みロールで十分な場合、アプリに db_owner やサーバー管理者権限を付与しないでください。
• 接続文字列や SA パスワードをコミットしないでください。シークレットストアまたは Git の追跡対象外の環境変数を使用してください。
• クラウドの Azure SQL Database に対して TrustServerCertificate=true を設定しないでください。実際の証明書の検証が無効になります。
• 本番環境の高頻度な処理経路で DefaultAzureCredential の全認証チェーンに依存しないでください。トークン取得を高速かつ予測可能にするため、マネージド ID などの特定の認証方式を選択してください。
• SQL Server イメージ mcr.microsoft.com/mssql/server を使用しないでください。これは Azure SQL エンジンです。

参考資料

• references/auth-and-secrets.md：最小権限ユーザーの作成（SQL 包含ユーザーとロール、ログインとユーザーの分離、Entra の CREATE USER FROM EXTERNAL PROVIDER）、環境ごとの接続文字列（SQL、Entra、マネージド ID）、およびスタックごとのシークレット管理（Azure Key Vault、dotnet user-secrets、.env）。

最新情報の確認

このスキルで使用するツールについて、バージョンが固定された信頼できるリファレンスを掲載しています（必要なものを参照してください）。

• SqlConnection の接続文字列キーワード：Authentication、Encrypt、User Id/Password、プーリングなど。
• CREATE USER（Transact-SQL）：包含ユーザー、WITH PASSWORD、および Entra 用の FROM EXTERNAL PROVIDER。
• データベースレベルのロール：最小権限の付与に使用する固定ロール（db_datareader、db_datawriter など）。
• Azure SQL の Microsoft Entra 認証：クラウドでの Entra 認証とマネージド ID 認証。

Microsoft Learn MCP サーバーが設定されている場合は、mcp__microsoft-learn__microsoft_docs_search または mcp__microsoft-learn__microsoft_docs_fetch を使用して、これらのいずれかの最新バージョンを必要に応じて取得してください。これは任意です。利用できない場合は、上記のリファレンスを信頼できる情報源として使用してください。