認証情報の聖域を守れ：Access VBAにおけるADO接続文字列の暗号化とDPAPIによる堅牢な実装
Access VBAを「単なるデスクトップアプリのスクリプト」と侮る者は、いずれ致命的なセキュリティインシデントによってそのキャリアに終止符を打つことになる。
社内基幹システムとして稼働するAccessアプリケーションにおいて、SQL Serverなどの外部データベースへの接続情報は、システムの心臓部であり、同時に最大の脆弱性でもある。多くの開発者が、`ConnectionString = “UID=sa;PWD=password123;”` といった、あまりにも無防備なコードを、まるで日常の風景であるかのように書き連ねている。
VBAプロジェクトのパスワード保護など、霧のように儚いものだ。バイナリエディタやリバースエンジニアリングの手法を知る者からすれば、それは鍵をかけずに宝箱を置いているのと同義である。
本稿では、レガシーな環境を維持しつつも、現代的なセキュリティ基準を満たすための、Windows APIを用いたDPAPI（Data Protection API）による接続情報の秘匿化、およびオブジェクトのライフサイクル管理に関する極限の知見を伝授する。
1. アーキテクチャの選定：なぜ独自の暗号化アルゴリズムでは不十分なのか
よくある誤りが、自作のXOR演算や単純なBase64エンコード、あるいは独自のAES実装をVBA内に組み込むことだ。これらは「難読化」には寄与するが、「暗号化」としては極めて脆弱である。アルゴリズムがコード内に存在している以上、攻撃者はそのロジックを容易に解析できるからだ。
我々が目指すべきは、「コード自体には秘密の鍵を持たせない」という設計思想である。
ここで登場するのが、Windows OSが提供するDPAPI (Data Protection API) である。DPAPIは、ユーザーのログイン資格情報やマシン固有のコンテキストに紐付いたマスターキーを使用してデータを暗号化する。これにより、たとえ暗号化されたデータ（接続文字列）が流出したとしても、別のユーザーや別のマシンからは解読不能となる。
「コードに鍵を持たない」――これこそが、プロフェッショナルが選ぶべきアーキテクチャである。
2. 実装：Windows APIによるDPAPIの制御
それでは、具体的な実装に入る。まずは、Windows APIを呼び出すための宣言と、暗号化・復号化のコアロジックを構築する。64bit環境（Access 2016以降の標準）を前提とした `LongPtr` を用いた記述を行う。
modWinAPI_DPAPI: 低レイヤーの制御
Option Explicit
' --- Windows API Declarations for DPAPI ---
' CryptProtectData: データをユーザー/マシンコンテキストで暗号化する
Private Declare PtrSafe Function CryptProtectData Lib "crypt32.dll" ( _
ByRef pDataIn As DATA_BLOB, _
ByVal szDataDescr As LongPtr, _
ByRef pOptionalEntropy As DATA_BLOB, _
ByVal pvReserved As LongPtr, _
ByVal pPromptStruct As LongPtr, _
ByVal dwFlags As Long) As Long
' CryptUnprotectData: 暗号化されたデータを復号する
Private Declare PtrSafe Function CryptUnprotectData Lib "crypt32.dll" ( _
ByRef pDataIn As DATA_BLOB, _
ByVal ppSafeBlob As LongPtr, _
ByRef pOptionalEntropy As DATA_BLOB, _
ByVal pvReserved As LongPtr, _
ByVal pPromptStruct As LongPtr, _
ByVal dwFlags As Long) As Long
' DATA_BLOB 構造体の定義
Private Type DATA_BLOB
cbData As Long
pbData As LongPtr
End Type
' --- Constants ---
Private Const CRYPTPROTECT_UI_FORBIDDEN As Long = &H1
''' <summary>
''' 文字列をDPAPIを用いて暗号化し、Base64形式の文字列を返す
''' </summary>
Public Function EncryptString(ByVal strInput As String) As String
Dim blobIn As DATA_BLOB
Dim blobOut As DATA_BLOB
Dim byteData() As Byte
Dim result As Long
' 文字列をバイト配列に変換
byteData = StrConv(strInput, vbFromUnicode)
' 入力用BLOBのセットアップ
blobIn.cbData = UBound(byteData) + 1
blobIn.pbData = VarPtr(byteData(0))
' 暗号化実行
result = CryptProtectData(blobIn, 0, ByVal 0&, 0, 0, CRYPTPROTECT_UI_FORBIDDEN)
If result <> 0 Then
' 出力用BLOBからバイト配列を抽出
Dim encryptedBytes() As Byte
ReDim encryptedBytes(blobOut.cbData - 1)
' ※実際の実装ではメモリコピーを行う必要があるが、ここでは概念を示す
' 簡略化のため、本来は RMemCopy 等を使用
' ここでは説明のため、メモリの内容を直接扱うロジックを省略
' 実際の実装では、blobOut.pbData から encryptedBytes へコピーする
' ※実用的な実装では、ここでのメモリ管理が極めて重要となる
EncryptString = "ENCRYPTED_DATA_BASE64_STRING" ' 擬似的な戻り値
Else
Err.Raise vbErr_Critical, "modWinAPI_DPAPI", "Encryption failed."
End If
End Function
' ※注: 実際の運用環境では、バイナリデータの転送に RtlMoveMemory 等を使用し、
' 厳密なメモリ操作を行う必要がある。*注釈：実際の製品レベルでは、`RtlMoveMemory` を用いて `pbData` からバイト配列への正確なコピーと、`CoTaskMemFree` によるメモリ解放が必要である。これは、メモリリークを防ぎ、システム全体の安定性を担保するための「作法」である。*
3. 接続管理：オブジェクトのライフサイクルと例外処理
暗号化された情報を取得した後、いかにしてADOオブジェクトを扱うか。ここで差が出る。
シニアエンジニアは、`ADODB.Connection` オブジェクトを単に `Close` するだけでは不十分だと知っている。エラー発生時の状態、メモリへの残存、そしてオブジェクトの破棄までを完璧にコントロールしなければならない。
modDatabase_Core: セキュアな接続エンジン
Option Explicit
''' <summary>
''' 暗号化された接続文字列を使用してSQL Serverへ接続する
''' </summary>
Public Sub ExecuteSecureQuery()
Dim conn As ADODB.Connection
Dim rs As ADODB.Recordset
Dim strEncryptedConn As String
Dim strDecryptedConn As String
' 1. 外部（レジストリ等）から暗号化された接続文字列を取得
' ここでは例として、あらかじめ暗号化済みの文字列を想定
strEncryptedConn = GetSecretFromRegistry("HKEY_CURRENT_USER\Software\MyApp\DBConfig")
' 2. DPAPIにより復号
strDecryptedConn = DecryptString(strEncryptedConn)
' 3. オブジェクトの生成と接続
' エラーハンドリングを極限まで厳格にする
On Error GoTo ErrorHandler
Set conn = New ADODB.Connection
conn.ConnectionString = strDecryptedConn
conn.CursorLocation = adUseClient ' 業務ロジックに応じて最適化
conn.Open
' 4. クエリ実行
Set rs = New ADODB.Recordset
rs.Open "SELECT TOP 10 * FROM CriticalTable", conn, adOpenStatic, adLockReadOnly
' --- データ処理ロジック ---
Do While Not rs.EOF
Debug.Print rs.Fields(0).Value
rs.MoveNext
Loop
' -----------------------
CleanExit:
' 5. ライフサイクルの厳格な管理
' オブジェクトを明示的に解放し、メモリ上の機密情報をクリアする
On Error Resume Next
If Not rs Is Nothing Then
If rs.State = adStateOpen Then rs.Close
Set rs = Nothing
End If
If Not conn Is Nothing Then
If conn.State = adStateOpen Then conn.Close
Set conn = Nothing
End If
' 復号した機密文字列をメモリから消去（重要）
strDecryptedConn = String(Len(strDecryptedConn), vbNullChar)
strDecryptedConn = ""
Exit Sub
ErrorHandler:
MsgBox "Critical Database Error: " & Err.Description, vbCritical, "System Error"
Resume CleanExit
End Sub
''' <summary>
''' レジストリから機密情報を取得する（実装の骨子）
''' </summary>
Private Function GetSecretFromRegistry(regPath As String) As String
' 実装例: WshShell等を用いてレジストリから取得
' ここでは簡略化
GetSecretFromRegistry = "..."
End Function
''' <summary>
''' DPAPIを用いた復号ロジック（API呼び出しの実体）
''' </summary>
Private Function DecryptString(ByVal strEncrypted As String) As String
' ここに CryptUnprotectData を用いた復号処理を記述
' 復号プロセスで、メモリリークが発生しないよう注意深く実装する
DecryptString = "UID=sa;PWD=ActualPassword123!;" ' 復号結果の例
End Function4. 伝説のアーキテクトが教える「極限の作法」
コードを書き終えた後、以下の3点を自問自答せよ。これらが満たされていなければ、その実装は「プロ」の仕事とは呼べない。
I. メモリ上の「痕跡」を抹消しているか？
`strDecryptedConn` に格納されたパスワードは、変数のスコープが終了するまでメモリ上に存在し続ける。これは、メモリダンプ攻撃に対して脆弱であることを意味する。
極限のセキュリティを求めるならば、使用直後に `String(Len(str), vbNullChar)` を用いて、変数の中身をヌル文字で上書きし、物理的に情報を消去せよ。
II. オブジェクトの解放順序は正しいか？
ADOの `Recordset` と `Connection` の関係において、`Recordset` を先に閉じ、`Nothing` を代入すること。この順序を誤ると、COMオブジェクトの参照カウントが正しく減少しず、メモリリークを引き起こす。特に、長時間稼働するAccessアプリケーションにおいて、この微細な漏れがシステムの「突然の死」を招く。
III. 接続文字列の「組み立て」を動的に行っているか？
接続文字列全体を一つの暗号化された塊として保存するのではなく、「サーバー名」「DB名」「ユーザー名」を個別に管理し、実行時にのみ結合する手法も検討せよ。これにより、万が一一つの要素が漏洩しても、攻撃者が接続を確立するまでのコストを劇的に高めることができる。
結論
Access VBAは、適切なアーキテクチャさえ備えれば、極めて強力なエンタープライズ・ツールへと昇華する。
パスワードをコードに書くという「安易な妥協」を捨て、Windows APIというOSの力を借りて、堅牢な防壁を築け。技術の真髄は、動くコードを書くことではなく、「壊れない、そして侵されないシステム」を設計することにある。
