【Windows統合認証接続】ADODB 接続文字列に Trusted_Connection を組み込んだパスワード非保持のセキュアDB連携
レガシーシステムの深部、あるいは堅牢性が求められる社内基幹ネットワークにおいて、VBScript（WSH）とSQL Serverの連携は今なお現役のライフラインとして稼働し続けている。
しかし、いかに限定された環境とはいえ、接続文字列（Connection String）のなかに平文の `UID` と `PWD` をハードコーディングする悪習は、セキュリティ監査の文脈において万死に値する。
今回は、Windows統合認証（SSPI: Security Support Provider Interface）をVBScriptから極限までセキュアに扱い、認証情報の露出をゼロにする `Trusted_Connection` 活用術の真髄を解説する。
—
1. なぜ「パスワード非保持」でなければならないのか
実務の現場において、接続文字列へのクレデンシャル（資格情報）の直書きは、以下の致命的なリスクを孕む。
- ソースコード漏洩時の即時侵害: スクリプトファイル（`.vbs`）の権限設定ミスや、ファイルサーバー上の共有フォルダからの流出により、データベースの全権が奪われる。
- メンテナンス性の崩壊: SQL Server側のパスワード変更のたびに、無数に散らばるVBScriptファイルを修正・再配備する地獄の運用コストが発生する。
- コンプライアンス違反: SOC2やISO/IEC 27001などのセキュリティ監査において、平文パスワードの存在は一発で重大な不適合判定を受ける。
これに対する唯一にして最大の解決策が、「今、タスクを実行しているWindowsユーザーのコンテキストそのものをデータベースへのパスポートにする」こと、すなわち `Trusted_Connection=Yes` の採用である。
—
2. ADODB.Connectionにおける認証メカニズムの深層
VBScriptからSQL Serverへ接続する場合、通常は `ADODB.Connection` オブジェクトを使用する。
ここでOLE DBプロバイダ（`MSOLEDBSQL` または `SQLOLEDB`）に対し、どのようにWindows認証を指示するかが成否を分ける。
典型的な接続文字列の構造を以下に示す。
Provider=MSOLEDBSQL;Server=db_server01\instance_name;Database=EnterpriseDB;Trusted_Connection=yes;
ここで重要なのは、`UID` と `PWD` の項目を完全に排除し、代わりに `Trusted_Connection=yes`（または `Integrated Security=SSPI`）を付与することだ。
これにより、OSが保持するKerberosチケットあるいはNTLMセッションがそのままSQL Server側へ引き渡され、SQL ServerインスタンスにマッピングされたWindowsログイン（あるいはActive Directoryグループ）の権限に基づいてアクセスが許可される。VBScriptのメモリ空間にパスワード文字列が展開される余地すら与えない。
—
3. 【実務実装】完全セキュア・VBScriptテンプレート
メモリリークの防止、適切なエラーハンドリング、そしてオブジェクトの明示的な破棄（ライフサイクル管理）を徹底した、プロダクション品質のコードを提示する。
Option Explicit
‘ ==============================================================================
‘ Script Name: SecureDBConnector.vbs
‘ Description: Windows統合認証を用いたセキュアなSQL Serverデータ連携サンプル
‘ Author: Chief Architect
‘ ==============================================================================
Main()
Sub Main()
Dim conn, cmd, rs
Dim connectionString
Dim query
Dim affectedRows
‘ 1. 接続文字列の定義 (Trusted_Connectionによるパスワード非保持)
‘ ※ MSOLEDBSQL (Microsoft OLE DB Driver for SQL Server) の使用を推奨
connectionString = “Provider=MSOLEDBSQL;” & _
“Server=192.168.10.50\SQL2019;” & _
“Database=ProductionDB;” & _
“Trusted_Connection=yes;” & _
“DataTypeCompatibility=80;” & _
“MarsConnection=True;”
‘ 2. ADODB.Connection オブジェクトの生成
Set conn = CreateObject(“ADODB.Connection”)
‘ 接続タイムアウトの設定 (秒)
conn.ConnectionTimeout = 15
‘ コマンドタイムアウトの設定 (秒)
conn.CommandTimeout = 30
On Error Resume Next
‘ 3. データベース接続の確立
conn.Open connectionString
If Err.Number <> 0 Then
Call LogError(“データベース接続に失敗しました: ” & Err.Description)
Set conn = Nothing
WScript.Quit 1
End If
On Error GoTo 0
WScript.Echo “[INFO] データベースとのセキュア接続が確立されました。”
‘ 4. パラメータ化クエリによる安全なデータ取得 (SQLインジェクション対策)
query = “USP_GetEmployeeDataByDepartment”
Set cmd = CreateObject(“ADODB.Command”)
With cmd
Set .ActiveConnection = conn
.CommandText = query
.CommandType = 4 ‘ adCmdStoredProc (ストアドプロシージャの実行)
‘ パラメータの追加 (例: 部署ID ‘D001’ を渡す)
.Parameters.Append .CreateParameter(“@DeptID”, 200, 1, 10, “D001”) ‘ adVarChar = 200
Set rs = .Execute
End With
‘ 5. 結果セットの処理
If Not (rs.BOF And rs.EOF) Then
Do While Not rs.EOF
WScript.Echo “社員ID: ” & rs.Fields(“EmployeeID”).Value & _
” / 氏名: ” & rs.Fields(“FullName”).Value
rs.MoveNext
Loop
Else
WScript.Echo “[INFO] 該当するデータは存在しませんでした。”
End If
‘ 6. オブジェクトの明示的クローズとメモリ解放 (LIFO順序の遵守)
If Not rs Is Nothing Then
If rs.State = 1 Then rs.Close
Set rs = Nothing
End If
If Not cmd Is Nothing Then
Set cmd = Nothing
End If
If Not conn Is Nothing Then
If conn.State = 1 Then conn.Close
Set conn = Nothing
End If
WScript.Echo “[INFO] すべての処理が正常終了し、リソースが解放されました。”
End Sub
Sub LogError(errMsg)
‘ 冗長なエラーログ出力のスタブ
WScript.Echo “[ERROR] ” & Now & ” – ” & errMsg
End Sub
—
4. チーフアーキテクトが指摘する「見落としがちな罠」と最適化
このアーキテクチャを導入する際、現場のエンジニアが陥りがちな罠と、それを回避するための知見を共有する。
① 実行コンテキスト（権限）の錯覚
VBScriptは、それを実行しているプロセス（タスクスケジューラ、Wscript.exe、Cscript.exe）のセキュリティコンテキストで動作する。
- タスクスケジューラでの注意点: 「ユーザーがログオンしているかどうかにかかわらず実行する」かつ「最高特権で実行する」に設定した場合、実行ユーザーはシステムアカウント（NT AUTHORITY\SYSTEM）や特定のサービスアカウントになる。SQL Server側にそのアカウントのログイン（またはマッピング）が存在しなければ、当然接続は弾かれる。
- 対策: スクリプトを実行するWindowsアカウントに対して、明確にSQL Server上の `LOGIN` および `USER` 権限を付与しておくこと。
② プロバイダの選定 (SQLOLEDB vs MSOLEDBSQL)
レガシーなスクリプトでは古い `SQLOLEDB`（SQL Server OLE DB Provider）が使われがちだが、現代のインフラストラクチャにおいては、TLS 1.2/1.3の強制や最新のSQL Server機能（Always Encryptedなど）に対応した `MSOLEDBSQL` (Microsoft OLE DB Driver for SQL Server) を強く推奨する。
もしクライアント環境にドライバーが存在しない場合は、Microsoft公式から最新のMSOLEDBSQLランタイムを導入すべきである。
③ オブジェクトライフサイクルとCOMのガベージコレクション
VBScript（VBScriptエンジンのCOM相互運用）は、JScript等と同様にガベージコレクションのタイミングが必ずしもデモクラティックではない。
特に長時間稼働するバッチ処理において、`Set conn = Nothing` を怠ると、ADO接続プールが適切に解放されず、SQL Server側のセッション枯渇（Socket Exhaustion）を引き起こす。
生成した順序とは逆の順序（LIFO）で確実に `Close` し、`Nothing` を代立させてメモリからパージすることが、プロフェッショナルのコードの絶対条件である。
—
総括
VBScriptはレガシーな言語と揶揄されることもあるが、Windows OSの根幹機能（WMI, ADSI, そして今回のSSPI）とダイレクトに結合できる点において、依然として類まれな爆発力を持つ。
ハードコーディングされたパスワードという「技術的負債」を今すぐ捨て去り、`Trusted_Connection` を軸としたモダンかつ堅牢なWindows統合認証へ移行せよ。それこそが、システムを守るエンジニアの責務である。
