Skip to content

MS_SQLServerAuthentication

Jump to bottom
nishi_74322014 edited this page Aug 13, 2026 · 2 revisions

SQL Server の認証

概要

SQL Serverの認証には、以下の 2 つがあります。

  • SQL Server 認証
  • Windows 認証

詳細

SQL Server認証

SQL Serverの接続文字列にユーザアカウントを指定して認証します。

Data Source=localhost\sqlexpress;Initial Catalog=Northwind;User ID=xxxx;Password=yyyy;

サーバアプリケーション経由でのリソース アクセス ストラテジとしては、
「サーバ信頼セキュリティ モデル」にのみ対応します。

Windows認証

Windows のアカウントを使用して認証します。

Data Source=localhost\sqlexpress;Initial Catalog=Northwind;Integrated Security=True;

※ Integrated Security の部分は、=SSPI; でも同じ意味らしい。

使用するアカウント

DBClient と DBServer が別のマシンにインストールされる場合は、

が考えられますが、「ミラーアカウントを利用する方法」は少々、裏ワザ的です。
従って、通常は、Active Directory アカウントを利用する方法を採用して下さい。

補足（Windows 認証が推奨される理由）: 2 方式のうち、
可能なら Windows 認証（現在は Entra ID 認証）を選ぶのが原則である。

SQL Server 認証 Windows 認証
パスワード 接続文字列に平文で書くことになる 書かない
資格情報の管理 アプリごとに個別 ADで一元管理
パスワード ポリシー SQL Server 側で個別設定 AD のポリシーが効く
退職者の無効化 見落としやすい AD で 1 箇所
監査 SQL Server のログのみ AD と突合できる

「接続文字列にパスワードを書かない」という一点だけでも大きい。
書く場合は Key Vaultや
.NET configのユーザー シークレットを使い、
リポジトリに入れないことが必須である。

リソース アクセス ストラテジ

サーバアプリケーション経由でのリソース アクセス ストラテジとしては、
以下の双方のセキュリティ モデルに対応します。

DBClientがAPサーバーの場合

モデル 使われるアカウント
サーバ信頼セキュリティ モデル Windows サービスの実行アカウント（必要に応じて変更・偽装）
ベース クライアント セキュリティ モデル ベース クライアントの実行アカウントを Windows サービスが偽装

詳しくはサービス・タスク系のアカウント問題を参照。

補足（ベース クライアント モデルはダブルホップを踏む）: 後者
（エンドユーザーの資格情報で DB に接続する）は、
クライアント → AP サーバー → DB サーバーという 2 ホップになるため、
委任の設定が必要になる。

設定が無いと「AP サーバーまでは認証されるが、
DB 接続で NT AUTHORITY\ANONYMOUS LOGON になって失敗する」という
典型的な症状が出る。
対処はサービス・タスク系のアカウント問題の
「ダブルホップ」を参照（RBCD が推奨）。

なお、接続プールが効かなくなる（ユーザーごとに別プールになる）ため、
性能面でも不利になる。
「DB 側で行レベルの権限制御をしたい」という強い要件が無い限り、
サーバ信頼モデル + アプリ側で認可とする方が実務的である。

ユーザ登録方法

  • ログイン（サーバー レベル）とデータベース ユーザー（DB レベル）は別物。
  • 通常は、ログインを作成 → 各 DB にユーザーをマップ → ロールを付与、の順。

補足（最新化：Entra ID 認証と包含データベース）: 現在は
選択肢が増えている。

認証方式 対象
SQL Server 認証 従来
Windows 認証（Kerberos / NTLM） オンプレの AD 環境
Microsoft Entra ID 認証 Azure SQL / SQL Server 2022 以降。クラウド前提
マネージド ID Azure 上のアプリからパスワードなしで接続 
// マネージド ID で Azure SQL に接続（パスワード不要）
"Server=tcp:xxx.database.windows.net;Database=mydb;
 Authentication=Active Directory Default;"

Key Vaultの補足で述べた
「秘密をどこにも置かない」構成が、DB 接続でも実現できる。
クラウド移行時に併せて検討したい。

また、包含データベース ユーザー（Contained Database User） を使うと、
サーバー レベルのログインを作らずに DB 単位で完結できる。
可用性グループでのフェイル オーバー時に
「ログインが移っていない（孤立ユーザー）」という問題を避けられる。

参考

Microsoft Learn

Tags: 移行, データアクセス, SQL Server, 認証基盤, セキュリティ

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally