VB.NETにおけるSecureStringの正しい使い方とメモリ保護：平文パスワードを保持しない安全な認証情報管理
開発現場で、次のようなコードを見たことはないだろうか。
.net
‘ 【アンチパターン】絶対にやってはいけない平文保持
Dim password As String = “P@ssw0rd123!”
Dim connStr As String = “Server=myServerAddress;Database=myDataBase;Uid=myUsername;Pwd=” & password & “;”
業務アプリケーションや自動化ツールにおいて、データベースの接続情報やAPIの認証トークン、ユーザーのパスワードを扱うのは日常茶飯事だ。しかし、`String`型を使って平文でメモリ上にパスワードを保持することは、セキュリティの観点から重大な脆弱性を生む。
`String`型は不変（Immutability）の特性を持ち、ガベージコレクション（GC）によってメモリからいつ解放されるか予測できない。つまり、メモリダンプ採取やプロセスのハッキングによって、平文のパスワードが長期間にわたってメモリ上に残存し続けることになる。
今回は、このリスクを根本から断つための `.NET` の要塞、`SecureString` を用いた堅牢な認証情報管理の極意を伝授する。
—
なぜ `String` 型のパスワード保持は「悪」なのか？
メモリ上のデータ保護を語る上で、開発者が知るべき `.NET` の内部挙動がある。
1. メモリ上の常駐とピン留め
`String` 型のインスタンスは、マネージドヒープ上に生成される。GCが動作するまで、その文字列がメモリのどの位置に存在し続けるかは制御不能である。
2. 文字列インターニング（String Interning）
`.NET` はパフォーマンス最適化のために、同一の文字列リテラルをメモリ上で共有する仕組みを持っている。これにより、意図せず予期せぬ領域にパスワードがキャッシュされる危険性がある。
このリスクを回避するために用意されたのが、`System.Security.SecureString` クラスである。
—
SecureString の本質とアーキテクチャ
`SecureString` は、格納された文字列をWindowsのData Protection API (DPAPI) 等を用いてメモリ上で暗号化し、さらにアンマネージドメモリ領域に確保することで、平文がマネージドヒープ上に露出し続けるのを防ぐクラスだ。
ただし、注意してほしい。`SecureString` は「万能の魔法の杖」ではない。誤った使い方をすれば、結局平文に戻してしまったり、パフォーマンスを著しく低下させたりする。プロフェッショナルが守るべき実装の鉄則を以下に示す。
プロダクションコード：セキュアな認証情報管理クラス
実務でそのまま使える、`SecureString` を安全に生成・利用・破棄するためのラッパークラスをVB.NETで実装した。
.net
Imports System.Security
Imports System.Runtime.InteropServices
Imports System.Net
Public NotInheritable Class SecureCredentialManager
Implements IDisposable
Private _securePassword As SecureString
Private _disposed As Boolean = False
”’
”’
”’ 平文のパスワード
Public Sub New(plainTextPassword As String)
If String.IsNullOrEmpty(plainTextPassword) Then
Throw New ArgumentNullException(NameOf(plainTextPassword))
End If
_securePassword = New SecureString()
‘ 1文字ずつ文字コード（Char）をSecureStringに流し込む
For Each c As Char In plainTextPassword
_securePassword.AppendChar(c)
Next
‘ SecureStringを読み取り専用（イミュータブル）にロックする
_securePassword.MakeReadOnly()
End Sub
”’
”’
Public Sub ExecuteWithUnencryptedPassword(action As Action(Of String))
If _disposed Then Throw New ObjectDisposedException(Me.GetType().FullName)
‘ IntPtrへのアンマネージ変換を安全に行う
Dim bstrPtr As IntPtr = IntPtr.Zero
Try
‘ BSTR形式でアンマネージメモリに復号化してエクスポート
bstrPtr = Marshal.SecureStringToBSTR(_securePassword)
Dim plainText As String = Marshal.PtrToStringBSTR(bstrPtr)
‘ 処理を実行（ラムダ式等で呼び出し元へ渡す）
action(plainText)
‘ 使用後は速やかにローカル変数をクリア（完全ではないが気休め以上の効果）
plainText = Nothing
Finally
If bstrPtr <> IntPtr.Zero Then
‘ アンマネージメモリ上のBSTRを即座にゼロクリアして解放
Marshal.ZeroFreeBSTR(bstrPtr)
End If
End Try
End Sub
”’
”’
Public Sub Dispose() Implements IDisposable
Dispose(True)
GC.SuppressFinalize(Me)
End Sub
Private Sub Dispose(disposing As Boolean)
If Not _disposed Then
If disposing Then
‘ SecureStringはIDisposableを実装しているため、ここで確実涯破棄する
If _securePassword IsNot Nothing Then
_securePassword.Dispose()
_securePassword = Nothing
End If
End If
_disposed = True
End If
End Sub
End Class
—
実務における活用とデータベース・API連携の注意点
作成した `SecureCredentialManager` をどのように実務の自動化ツールやデータベース接続に応用すべきか。ここで重要な現実問題に直面する。
「現代の多くのADO.NETプロバイダやAPIクライアントは、内部で平文の `String` 型の接続文字列やトークンを要求する」 という事実だ。
例えば、`SqlConnection` は `ConnectionString` プロパティに `Password=…` を平文の文字列として渡さなければならない。では、`SecureString` を使う意味がないのだろうか？
答えは「ノー」である。
設計アプローチ：平文化の時間を「極限まで短縮」する
メモリ上でのリスクを最小限に抑える鉄則は、「平文が存在するライフサイクルをマイクロ秒単位に絞る」ことだ。
先ほど作成したクラスを用いて、データベース接続を安全に行う模範的な実装を見てみよう。
.net
‘ 【使用例】SecureStringから安全に接続文字列を構築し、瞬時に破棄する
Public Sub ConnectToDatabase(secureManager As SecureCredentialManager)
‘ 接続確立の直前までパスワードは暗号化されたまま
secureManager.ExecuteWithUnencryptedPassword(
Sub(plainPassword)
‘ 接続文字列をローカルスコープでのみ一時的に生成
Dim connectionString As String = $”Server=myServer;Database=prodDB;Uid=admin;Pwd={plainPassword};”
Using connection As New System.Data.SqlClient.SqlConnection(connectionString)
connection.Open()
Console.WriteLine(“データベース接続成功：セキュアに処理されました。”)
‘ 業務処理…
End Using
‘ connectionString変数はこのスコープを抜けた瞬間にGCの対象となり、
‘ パスワードの生存期間を最小限に抑えられる
End Sub)
End Sub
このアプローチにより、パスワードが平文としてメモリ上に存在する時間は、データベース接続処理を行っているごく短い瞬間だけに限定される。アプリケーションがアイドル状態のときや、メモリダンプが取得されたとき、平文が露出するリスクは劇的に低下する。
—
チーフアーキテクトからの最終提言
セキュリティ対策において「100%安全」なシステムなど存在しない。あるのは「攻撃コストをいかに引き上げるか」というエンジニアリングの最適化だけだ。
今回解説した `SecureString` によるアプローチは、コードの行数を少し増やし、パフォーマンスにわずかなオーバーヘッドをもたらす。しかし、ひとたびインシデントが発生した際、「平文でパスワードをメモリに放置していたシステム」と「SecureStringで厳重に保護していたシステム」では、企業の存続を揺るがすほどの決定的な差を生む。
「動けばいい」というアマチュアのコードから脱却し、メモリのライフサイクルまで支配するプロフェッショナルなVB.NET開発を、今日からあなたの現場にも実装してほしい。
