【Windows統合認証接続】ADODB 接続文字列に Trusted_Connection を組み込んだパスワード非保持のセキュアDB連携
現場の自動化スクリプトやレガシーな業務ツールで、いまだにVBScriptのコード内にSQL ServerのユーザーIDや平文のパスワードをハードコーディングしている光景を目にする。
「動けばいい」という妥協の産物であるそのコードは、セキュリティ監査において最大の弱点となり、パスワード変更のたびにスクリプトの修正を強いられるという終わりのない負債を産む。
プロの業務自動化エンジニアであれば、Windows統合認証（Trusted Connection / SSPI）を使いこなすべきだ。ログイン中のWindowsユーザーの権限をそのままデータベースへ引き継ぎ、認証情報を一切コード上に持たないセキュアなアーキテクチャを構築する。
今回は、VBScriptと`ADODB.Connection`を用いた、パスワード非保持の堅牢なDB連携手法の極意を伝授しよう。
—
なぜ「平文パスワードのハードコーディング」は悪なのか？
実務において、DB接続文字列に `UID=sa;PWD=PaSsWoRd123;` のような記述を見かけることがある。これの何が問題か、エンジニアリングの観点から整理しておこう。
1. 情報漏洩リスクの直結: スクリプトが共有フォルダやGitリポジトリ（誤ってプッシュされた場合など）に置かれた瞬間、全権限が剥き出しになる。
2. 保守性の欠如: DBのパスワードポリシー変更（例：90日ごとの強制変更）のたびに、無数にあるVBScriptファイルを総しぼりして書き換える地獄が発生する。
3. 監査の不適合: 誰が実行したクエリなのかがDB側で「sa」や「共通ID」として処理され、トレーサビリティ（追跡可能性）が完全に失われる。
これらを一撃で解決するのが、Windowsのセッションが持つ認証トークンをそのまま利用するTrusted_Connection=Yesというアプローチである。
—
アーキテクチャの要件と前提条件
この手法を実装するにあたり、以下の前提条件とインフラ要件を満たしている必要がある。
- 認証方式: SQL Server 認証ではなく、Windows 認証モードまたは混合モードがSQL Server側で有効であること。
- 権限管理: スクリプトを実行するWindowsユーザー（またはサービスアカウント）に対して、対象DBへの適切な権限（`SELECT`, `INSERT` など）が事前に付与されていること。
- ドライバ選定: 近年の環境では、レガシーな `Provider=SQLOLEDB` ではなく、現代的な `MSOLEDBSQL`（Microsoft OLE DB Driver for SQL Server）または `ODBC Driver` を使用すべきである。
—
【プロダクションコード】セキュアDB連携テンプレート
実務の現場でそのままコピー＆ペーストして使用でき、かつエラーハンドリングとリソースのライフサイクル管理を完璧に網羅したVBScriptコードを提示する。
‘ ==============================================================================
‘ Script Name : SecureDBConnect.vbs
‘ Description : Windows統合認証を用いたセキュアなSQL Serverデータ連携サンプル
‘ Author ：Enterprise Automation Architect
‘ ==============================================================================
Option Explicit
‘ メイン処理の実行
Main
Sub Main()
Dim conn, cmd, rs
Dim connectionString
Dim query
Dim recordCount
‘ 1. オブジェクト変数の初期化
Set conn = Nothing
Set cmd = Nothing
Set rs = Nothing
On Error Resume Next
‘ 2. 接続文字列の構築（パスワードを含めない）
‘ Provider: 現代的なOLE DBドライバを指定
‘ Server: 接続先サーバー名またはIPアドレス
‘ Database: 対象データベース名
‘ Trusted_Connection: “Yes” または “True”を指定することでWindows統合認証を有効化
connectionString = “Provider=MSOLEDBSQL;” & _
“Server=your_server_name\instance_name;” & _
“Database=your_database_name;” & _
“Trusted_Connection=yes;” & _
“Encrypt=yes;” & _
“TrustServerCertificate=yes;”
‘ 3. コネクションの生成とオープン
Set conn = CreateObject(“ADODB.Connection”)
conn.ConnectionString = connectionString
conn.ConnectionTimeout = 15 ‘ 接続タイムアウト（秒）
conn.CommandTimeout = 30 ‘ クエリタイムアウト（秒）
conn.Open
If Err.Number <> 0 Then
WScript.Echo “[FATAL] データベース接続に失敗しました: ” & Err.Description
Call Cleanup(conn, cmd, rs)
Exit Sub
End If
WScript.Echo “[INFO] データベース接続成功（Windows統合認証）”
‘ 4. パラメータ化クエリの実行準備（SQLインジェクション対策）
query = “SELECT EmployeeID, EmployeeName FROM dbo.M_Employee ” & _
“WHERE DepartmentID = ? AND IsActive = 1”
Set cmd = CreateObject(“ADODB.Command”)
Set cmd.ActiveConnection = conn
cmd.CommandText = query
cmd.CommandType = 1 ‘ adCmdText
‘ パラメータの安全なバインド（ハードコーディングした文字列結合は絶対に行わないこと）
‘ 例として部署ID ‘D001’ を指定
cmd.Parameters.Append cmd.CreateParameter(“@DeptID”, 200, 1, 10, “D001”) ‘ 200 = adVarChar
‘ 5. レコードセットの取得
Set rs = cmd.Execute
If Err.Number <> 0 Then
WScript.Echo “[ERROR] クエリの実行中にエラーが発生しました: ” & Err.Description
Call Cleanup(conn, cmd, rs)
Exit Sub
End If
‘ 6. 結果の処理
recordCount = 0
Do Until rs.EOF
WScript.Echo “社員ID: ” & rs.Fields(“EmployeeID”).Value & ” / 氏名: ” & rs.Fields(“EmployeeName”).Value
recordCount = recordCount + 1
rs.MoveNext
Loop
WScript.Echo “[INFO] 処理完了。総レコード数: ” & recordCount
‘ 7. 正常系クリーンアップ
Call Cleanup(conn, cmd, rs)
On Error GoTo 0
End Sub
‘ ==============================================================================
‘ 資源の解放とメモリリーク防止のためのクリーンアップ関数
‘ オブジェクトは明示的に閉じてからNothingを代入するのがプロの作法
‘ ==============================================================================
Sub Cleanup(ByRef conn, ByRef cmd, ByRef rs)
On Error Resume Next
If Not rs Is Nothing Then
If rs.State = 1 Then rs.Close
Set rs = Nothing
End If
Set cmd = Nothing
If Not conn Is Nothing Then
If conn.State = 1 Then conn.Close
Set conn = Nothing
End If
On Error GoTo 0
End Sub
—
コードの設計思想とプロの勘所
上記のコードが、単なる「動くスクリプト」と決定的に違うポイントを解説する。
1. 接続文字列における `Trusted_Connection=yes` の魔力
`UID` と `PWD` の記述が完全に排除されている点に注目してほしい。これにより、スクリプトを実行しているOSユーザー（タスクスケジューラであれば実行アカウント、手動実行であればログオンユーザー）の Kerberosチケット または NTLM トークンがそのままSQL Serverへ渡される。
「認証情報の委任（Credential Delegation）」が適切に機能するため、パスワードのハードコーディングというリスクが根本から消滅する。
2. オブジェクトのライフサイクル管理とメモリリーク防止
VBScriptのガベージコレクションは完全ではない。特にCOMオブジェクトである `ADODB` は、スクリプト終了までメモリ上に残り続けることがある。
プロは必ず `Cleanup` サブルーチンを用意し、以下の鉄則を守る。
- `State` プロパティをチェックし、開いている（State = 1）レコードセットやコネクションを明示的に `.Close` する。
- 変数に `Nothing` を代入して参照カウントを確実にデクリメントする。
3. 動的SQLの排除とパラメータ化クエリ
実務においてSQLインジェクションはWebアプリだけの脅威ではない。ローカルのVBScriptであっても、外部から取り込んだCSVの値などをそのまま `&` でSQL文に結合するのは自殺行為である。
`ADODB.Command` オブジェクトと `CreateParameter` を使用し、プレースホルダー（`?`）を経由したパラメータ化クエリを強制すること。これによりセキュリティと型安全性が同時に担保される。
—
運用時の注意点（トラブルシューティング）
Windows統合認証を導入した現場でよく遭遇するトラブルと、その解決策を記す。
- 「NTLM認証エラー」や「ログイン失敗」と言われた場合
- スクリプトを実行しているWindowsアカウントが、SQL Server側のログインユーザーとして登録されているか確認する。
- ローカルPCからリモートのSQL Serverに接続する際、SPN（Service Principal Name）の登録不備によりKerberos認証が失敗し、NTLMフォールバックが発生することがある。インフラ管理者と連携し、適切なSPNが構成されていることを確認すること。
- タスクスケジューラ実行時の罠
- 「ユーザーがログオンしているかどうかにかかわらず実行する」で、かつ「最上位の特権で実行する」にチェックが入っている場合、実行されるコンテキストが期待するサービスアカウントになっているか、DB側でそのアカウントのアクセス権が許可されているかを必ずテストすること。
—
総括
VBScriptはレガシーな言語と揶揄されることもあるが、Windows環境におけるインフラ親和性の高さは依然として圧倒的だ。
しかし、古い慣習のまま書かれた「パスワード剥き出しのコード」は、現代のセキュリティ基準において許容されない。
`Trusted_Connection=yes` を標準装備し、堅牢なエラーハンドリングとリソース管理を実装したスクリプトこそが、プロの業務自動化エンジニアが目指すべきゴールである。今日の設計が、明日のセキュリティインシデントを防ぐ防壁となる。
