【セキュリティ対策】VBScriptの平文コードを保護する VBE 化と暗号化の限界・運用上の注意点
レガシーシステムの自動化、あるいはActive Directory環境下でのキッティングスクリプトにおいて、VBScript（Visual Basic Scripting Edition）は今なお現場のインフラを陰で支え続けている。
だが、WSH（Windows Script Host）の宿命として、`.vbs` ファイルは完全に平文のテキストとしてディスク上に存在し、誰でもメモ帳一つで中身を覗き見ることができる。ここに社内システムのAPIキー、データベースの接続文字列、特権アカウントのパスワードなどがハードコーディングされているとすれば、それはセキュリティ上の重大な瑕疵（かし）と言わざるを得ない。
今回は、スクリプトの難読化手法である VBE (VBScript Encoded) 化 の実務的な手順と、その裏に潜む「暗号化の決定的な限界」、そして現場のチーフアーキテクトとして知っておくべき真のセキュリティ運用法について、妥協のない極限の知見を共有する。
—
1. VBE化（Script Encoder）のメカニズムと実務手順
Windowsに標準添付（あるいは無償配布）されている `screnc.exe`（Microsoft Script Encoder）を使用することで、`.vbs` や `.js` のコードをエンコードし、`.vbe` 形式に変換することが可能だ。
難読化の基本コマンド
実務では、ビルドプロセスやバッチファイル（`.bat`）に組み込んで実行するのが定石である。
:: 構文: screnc [/s] [/f] [/xl] source_file destination_file
:: /s : サイレントモード（画面出力抑制）
:: /f : 上書き許可
screnc /s /f C:\Projects\DeployApp.vbs C:\Projects\DeployApp.vbe
VBEファイルの内部構造
VBE化されたファイルを開くと、以下のような難読化された文字列に変換されていることがわかる。
@~^AQAAAA==[D~^.D[N+wDb,rK@#@&[ExbWvDk+dODx@#@&kWx`D~k+dOtm@#@&kWxDk+dOtbODm@#@&k+dOtbODm@#@&k+dOtbODmD^#~@
これは暗号化（Encryption）ではなく、あくまで難読化（Obfuscation）である。WSHのランタイム（`wscript.exe` / `cscript.exe`）は、実行時にこのヘッダー（`#@~^`）を検知すると、メモリ上で自動的に元のVBScriptコードにデコードしてインタプリタに渡す。つまり、OSが読めるということは、人間も原理的には必ず読めるということを意味する。
—
2. VBE暗号化の限界：なぜ「気休め」に過ぎないのか
「これでソースコードを守れる」と安心するのは早い。シニアエンジニアであれば、この手法の脆弱性を正確に把握しておく必要がある。
1. リバースエンジニアリングの容易さ
ネット上には、VBEのデコーダー（`vbe decoder` や各種スクリプト）がゴロゴロ転がしている。数秒あれば、平文の `.vbs` に完全復元されてしまう。
2. メモリダンプによる抽出
前述の通り、WSHは実行時に必ずメモリ上でコードを復元する。プロセスのダンプを取得すれば、難読化の壁など何の意味も持たない。
3. APIキーや認証情報の保護には全く無力
コード内に直書きされたパスワードを隠すためにVBEを使うのは、鍵のかかっていないガラスの箱に宝物を入れるようなものだ。
—
3. チーフアーキテクトが推奨する「真のセキュア運用」
では、レガシーなVBScript環境において、機密情報をどのように取り扱うべきか。その実践的なアプローチを提示する。
アプローチ A: 認証情報の外部隔離（環境変数・設定ファイル）
コード自体にパスワードを持たせず、OSの環境変数や、アクセス権限が厳格に絞られた外部の暗号化された設定ファイル（INIやJSON）から動的に読み込ませる。
以下は、WSHからWindows環境変数を安全に取得するコードスニペットである。
Option Explicit
‘ —————————————————————–
‘ オブジェクトのライフサイクル管理を意識した環境変数取得
‘ —————————————————————–
Dim objShell, dbPassword
Set objShell = CreateObject(“WScript.Shell”)
‘ 事前にOS側（ユーザーまたはシステム）で設定された環境変数を取得
dbPassword = objShell.Environment(“Process”)(“PROD_DB_PASSWORD”)
If dbPassword = “” Then
WScript.Echo “Critical Error: データベース接続パスワードが取得できません。”
‘ メモリリークを防ぐため、即座にオブジェクトを破棄して終了
Set objShell = Nothing
WScript.Quit 1
End If
‘ 接続処理（ここではモック）
Call ConnectToDatabase(dbPassword)
‘ 【重要】明示的なオブジェクト解放（メモリ最適化）
Set objShell = Nothing
Sub ConnectToDatabase(ByVal pwd)
‘ 実際のDB接続ロジックがここに入る
WScript.Echo “Connecting with secure password…”
End Sub
アプローチ B: Windows資格情報マネージャー（Credential Manager）の活用
さらに高度なセキュリティが求められる場合、VBScriptからWindowsの資格情報マネージャーをAPI経由で叩く、あるいはCOMコンポーネント（またはVB.NET製ラッパーDLL）を呼び出して安全にクレデンシャルを取得する設計を採用すべきだ。
—
4. レガシー環境におけるVBScriptメモリ最適化の極意
VBScriptはガベージコレクタ（GC）の挙動が.NETほど洗練されていない。特に長期稼働する常駐スクリプトや、大量のファイル・APIを叩くバッチ処理では、メモリリーク（Memory Leak）が原因でリソースを枯渇させることがある。
- `Set obj = Nothing` の徹底
オブジェクト変数（`WScript.Shell`, `Scripting.FileSystemObject`, `ADODB.Connection` など）のスコープを抜けたり、使い終わったりした際は、必ず明示的に `Nothing` を代入してメモリを解放すること。
- 変数の強制宣言 (`Option Explicit`)
型安全性がないVBScriptにおいて、タイプミスによる暗黙のグローバル変数生成はメモリ肥大化の温床となる。すべてのスクリプトの先頭に `Option Explicit` を記述することは、プロフェッショナルとしての最低限の責務である。
—
5. 総括：VBE化は「悪意なき覗き見防止」のフィルターに留めよ
VBScriptのVBE化（`screnc.exe`）は、エンドユーザーが誤ってコードを書き換えてしまったり、開発中のロジックが不用意に目に入ったりするのを防ぐための「簡易的な覗き見防止フィルター」としては有効である。
しかし、それをセキュリティ対策の要（かなめ）と錯覚してはならない。真のシステム保全を考えるならば、機密情報はコードから完全に排除し、OSのセキュリティ機構や外部の厳格な権限管理と統合する――これこそが、レガシーの呪縛を断ち切り、堅牢なシステムアーキテクチャを維持するための唯一の道である。
