PowerShell で認証情報を安全に扱う — パスワード平文直書きをやめる（SecureString / Export-Clixml）

みなさんこんにちは！ヒロポンです！！

運用スクリプトのレビューで、こういう行を見たこと、ないですか？？

$password = "P@ssw0rd!"

パスワードの平文直書き。

動くには動きます。ただセキュリティ監査で一発で刺されるやつです。しかも Git のコミット履歴に残るから、後から消しても手遅れ。

今日は PowerShell で認証情報を安全に扱うために、実務でよく踏む落とし穴を5つ、実コードでまとめていきます。Get-Credential / SecureString / Export-Clixml の使いどころと、「別マシンで読めない」みたいな業務でハマる制約まで。

💡 この記事は「1人で運用の自動化を回す」シリーズの1本です。CSV から AD ユーザーを一括作成 や イベントログ監視をメール通知 と同じ、無人で回すスクリプトの前提として読んでもらえるはず。

はじめに: なぜこの5つか

認証情報まわりは「暗号化すれば安全」で終わらないのが厄介なところ。

暗号化した瞬間に、「どこで復号できるか」「鍵をどこに置くか」という別の問題が生えてくる。

ここで挙げる5つは、平文をやめた 次に 詰まるやつを順に並べています。特に2番目（別マシンで読めない）と4番目（無人バッチ）は、1人で夜間バッチを回してる現場だと確実に踏む。そこだけでも押さえてください。

⏱ 対処の目安サマリ

1. パスワードを平文でスクリプトに直書きしている

一番多いやつ。動くけど、スクリプトを見た人全員にパスワードが漏れます。

# NG: 平文直書き。コミット履歴にも残る
$password = "P@ssw0rd!"
$secure = ConvertTo-SecureString $password -AsPlainText -Force

# OK: 対話で都度もらう。スクリプトに秘密を残さない
$cred = Get-Credential -UserName "svc_batch" -Message "バッチ実行アカウント"

Get-Credential は、ユーザー名とパスワードを PSCredential オブジェクトで受け取ります。パスワードは中で SecureString として保持されるので、画面にもスクリプトにも平文が出ない。こんな感じで、秘密を手元にベタ書きせずに済みます。

教訓: 平文の文字列は、書いた時点でもう漏れてる。

2. Export-Clixml で保存したら別マシンで復号できない

無人で回したいから、Get-Credential の結果をファイルに保存する。ここまでは正しい。

# 実行アカウントで一度だけ暗号化保存
$cred = Get-Credential
$cred | Export-Clixml -Path "C:\secure\batch-cred.xml"

# 以降のバッチはこれを読むだけ
$cred = Import-Clixml -Path "C:\secure\batch-cred.xml"

問題はここから。

Export-Clixml の SecureString は、既定で Windows の DPAPI で暗号化されます。この暗号化は「保存したユーザー × 保存したマシン」に紐づく。

つまり、この XML を別のサーバーにコピーしても、別のアカウントで実行しても、復号できずに落ちる。

俺も昔、開発機で作った cred.xml を本番サーバーにそのままコピーして、「なんで動かないんだ」と小一時間ハマりました。原因に辿り着くまでずっと復号エラーを睨んでたやつです。「開発機では通るのに本番で落ちる」の正体は、だいたいこれ。

教訓: Export-Clixml の暗号化は、作った本人・そのマシン専用。持ち出せない。

3. -Key で移植できるが、鍵の置き場所が新たな問題になる

マシンを跨ぎたいなら、DPAPI に頼らず AES キーを自分で指定します。

# 32バイトの AES キーを生成
$key = New-Object byte[] 32
[System.Security.Cryptography.RandomNumberGenerator]::Create().GetBytes($key)

$secure = ConvertTo-SecureString "P@ssw0rd!" -AsPlainText -Force
$encrypted = ConvertFrom-SecureString -SecureString $secure -Key $key

# $key さえあれば、別マシンでも復号できる
$restored = ConvertTo-SecureString -String $encrypted -Key $key

実行結果（同じ $key で暗号化 → 復号して元のパスワードに一致）:

-Key を渡すと DPAPI ではなく AES で暗号化されるので、$key を持っていけばどのマシンでも復号できる。いい感じに移植性は出ます。

ただ、ここで一回冷静になってほしいんですよね。じゃあ その $key はどこに置くのか？？

スクリプトの隣に鍵ファイルを平文で置いたら、鍵を持ってる人＝復号できる人。1番の「平文直書き」に逆戻りです。

教訓: -Key は「パスワードの平文問題」を「鍵の平文問題」にすり替えるだけ。鍵は別レイヤー（資格情報マネージャー等）で守る。

4. 無人バッチで Get-Credential は使えない

タスクスケジューラやサービスで無人実行するスクリプトに Get-Credential を書くと、対話プロンプトを出せずにその場で固まります。

誰も応答できないので、バッチが永遠に待つ。これ、地味に本番で刺さるやつです！！

現実的な落としどころは、だいたいこの3つ。

# 案A: 実行アカウント本人が事前に Export-Clixml しておき、バッチは読むだけ
$cred = Import-Clixml -Path "C:\secure\batch-cred.xml"
Invoke-Command -ComputerName "SRV01" -Credential $cred -ScriptBlock { hostname }

• 案A: 実行アカウントで一度だけ Export-Clixml（2番の DPAPI 制約は「同じアカウント・同じマシン」で回すなら逆に好都合）
• 案B: Windows 資格情報マネージャー（cmdkey や SecretManagement モジュール）に預ける
• 案C: そもそも専用のサービスアカウント + 最小権限で、パスワードを持ち回らない設計にする

教訓: 無人バッチに対話コマンドを混ぜない。事前準備か、資格情報ストアに寄せる。

5. SecureString を過信する

最後に、これは意識の話。

SecureString にしたから安全、ではないんですよ。

# SecureString も、その気になれば平文に戻せる
$secure = (Get-Credential).Password
$plain = [System.Net.NetworkCredential]::new("", $secure).Password
# → $plain には平文が入る