PowerShellでの資格情報の安全な扱い ── 平文パスワードをスクリプトから追放する

スクリプトから平文パスワードを消したい。しかし、SecureString、Export-Clixml、SecretManagement、資格情報マネージャー、Azure Key Vaultのどれを選べばよいのか分からない。運用スクリプトの見直しで、よく迷うところです。

ファイルサーバーへの接続、基幹システムのDB、メール送信、Web APIのキー。動作を優先して埋め込んだパスワードは、スクリプトと一緒に共有フォルダやGit履歴へ残ります。大切なのは、保存の道具を選ぶ前に、スクリプトがその秘密を持つ必要があるかを決めることです。

この記事は、社内の運用スクリプトや定期バッチを管理する情シス・運用担当者向けです。保存しない設計 → 対話での受け取り → 無人実行での保存 → ログへの露出防止の順に整理します。PowerShell 7.xを基準に、Windows PowerShell 5.1への注意も併記します。

1. まず結論 ── 「持たない」を先に、保存方法は後に選ぶ

人がその場で実行するなら、Get-CredentialでPSCredentialを受け取るのが基本です。無人実行なら、まず実行アカウントへの権限付与やマネージドIDで、スクリプトからパスワードをなくせないかを調べます。¹²³

無人実行では、次の優先順位で検討します。

1. 接続先がWindows認証にできるなら、実行アカウント(ドメインアカウント/gMSA)への権限付与で資格情報を消す。ドメイン環境の無人ジョブはまずこれを検討します。²
2. それが無理な相手(SQL認証のDB、APIキー、ワークグループのNASなど)だけ、秘密を保存する。単発ならExport-ClixmlのDPAPI保存、複数あるならSecretManagement+SecretStore。⁴⁵
3. クラウド資源への接続は、キーの保存よりマネージドID/フェデレーション資格情報の利用を優先する。保存する場合もAzure Key Vaultのような専用ボールトへ。⁶⁷

flowchart TB
        accTitle: 保存方法を決める前の分岐
        accDescr: スクリプトに秘密を持たせない方法を先に検討し、必要な秘密だけを実行条件に合う方法で受け取ります。
        A["実行アカウントやIDで認証できるか"] -->|"できる"| B["スクリプトに秘密を保存しない"]
        A -->|"別の秘密が必要"| C{"人が入力できるか"}
        C -->|"できる"| D["Get-Credentialで受け取る"]
        C -->|"無人実行"| E["DPAPIやボールトで保存する"]

図1: スクリプトに秘密を持たせない方法を先に検討し、必要な秘密だけを実行条件に合う方法で受け取ります。

どの方法でも、SecureStringへ変換するだけでは、元の平文がスクリプトやログに残る問題は解消しません。 受け渡しの形式、保存先の保護、無人で取り出す条件、記録への露出を別々に確認します。⁸⁹¹⁰

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全24件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. 平文の何が問題か ── 漏えい経路はコピーの数だけある

2.1 コピーと一緒に秘密も広がる

パスワードの直書きが危険な理由は、「悪意ある侵入者に読まれるかもしれない」だけではありません。スクリプトという成果物の性質上、正規の運用をしているだけでコピーが増殖することです。

この構造が意味するのは、平文パスワードの対策は「ファイルを見られないようにする」ことでは達成できない、ということです。アクセス権をどれだけ絞っても、Git履歴とバックアップまでは締められません。パスワードをスクリプトの外へ、暗号化された保管場所へ出すことが本筋です。この考え方は、.NETアプリの設定ファイルについて「Windowsアプリの機密情報保存 - DPAPIで平文設定を避ける」で書いたことと同じで、PowerShellでも原則は変わりません。

flowchart TB
        accTitle: コピー先を守るだけでは足りない
        accDescr: スクリプトから平文を外さなければ、正規の共有や保存によって秘密を含むコピーも増えていきます。
        A["平文を含むスクリプト"] --> B["共有や履歴にコピーが残る"]
        B --> C["コピーが漏えい経路になる"]
        C --> D["秘密をスクリプトの外へ出す"]

図2: スクリプトから平文を外さなければ、正規の共有や保存によって秘密を含むコピーも増えていきます。

2.2 SecureStringへの変換だけでは解決しない

次は書き換え対象の例です。安全な保存方法の例ではありません。

# アンチパターン: どちらも「平文がスクリプトに残る」点で同じ
$password = "P@ssw0rd123"

# SecureStringに変換しても、元の平文は1行目に書かれたまま。
# PSScriptAnalyzerはこの -AsPlainText の使い方をエラーとして検出する
$secure = ConvertTo-SecureString $password -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential('svc-transfer', $secure)

平文をその場でSecureStringに変換するConvertTo-SecureString "P@ssw0rd" -AsPlainText -Forceは解決策ではありません。PSScriptAnalyzer(公式の静的解析ツール)はこの書き方をエラー(Severity: Error)として検出します。暗号化を迂回して平文をメモリに晒すうえ、元の平文がスクリプト内に残り続けるからです。⁸

flowchart TB
        accTitle: 変換しても元の平文は残る
        accDescr: 実行時にSecureStringへ変換しても、コードや履歴に書かれた元の平文が消えるわけではありません。
        A["コード内の平文パスワード"] --> B["SecureStringへ変換"]
        A --> C["コードと履歴には平文が残る"]
        C --> D["保存方法そのものを見直す"]

図3: 実行時にSecureStringへ変換しても、コードや履歴に書かれた元の平文が消えるわけではありません。

3. 最優先の現実解 ── そもそも資格情報を持たない

保存方法を工夫する前に、スクリプトが資格情報を持つ必要をなくせないかを確認します。

3.1 Windows認証は実行アカウントへ権限を与える

Windowsのタスクやサービスは、実行アカウントのセキュリティコンテキストで動きます。接続先がWindows認証で守られているなら ── 共有フォルダのACL、SQL ServerのWindows認証、社内APIのWindows統合認証 ── 実行アカウント自身に接続先の権限を与えれば、スクリプトにはパスワードもGet-Secretも一切登場しません。認証はKerberosが実行アカウントの身元で勝手にやってくれます。

この構成を支えるのがgMSA(グループ管理サービスアカウント)です。gMSAはドメインの管理されたアカウントで、パスワード管理をWindows OSが引き受けます。² パスワードは240バイトのランダム生成で30日ごとにOSが自動変更するため、人間は誰もパスワードを知らず、期限切れによる停止も起きません。¹¹ そしてgMSAは、Windowsサービスだけでなくタスクスケジューラのタスクにも使えます。¹²

flowchart TB
        accTitle: 実行アカウントで接続する
        accDescr: 接続先がWindows認証を使う場合は実行アカウントへ権限を与え、スクリプト自身のパスワード管理をなくします。
        A["タスクやサービスの実行アカウント"] --> B["接続先へ権限を付与"]
        B --> C["アカウントの身元で認証"]
        C --> D["スクリプトにパスワード不要"]
        A -.-> E["gMSAならOSがパスワード管理"]

図4: 接続先がWindows認証を使う場合は実行アカウントへ権限を与え、スクリプト自身のパスワード管理をなくします。

3.2 gMSAは前提確認・作成・サーバーへの導入を分ける

ここではgMSAの導入に必要な手順の骨格を示します。前提として、ドメイン・フォレストの機能レベルがWindows Server 2012以上であること、作業アカウントがDomain Admins相当であること、ドメインコントローラー以外で作業するならRSAT(ActiveDirectoryモジュール)が入っていることが必要です。¹²

# 1) ドメインに1つだけ: KDSルートキーを作る(既にあればこの手順は不要)
#    全ドメインコントローラーへの複製を待つため、実際にgMSAを作れるまで最大10時間かかる
Add-KdsRootKey -EffectiveImmediately

# 2) gMSAを作る。PrincipalsAllowedToRetrieveManagedPasswordには、
#    パスワードの取得を許すコンピューター(をまとめたセキュリティグループ)を指定する
New-ADServiceAccount -Name svc-transfer -DNSHostName svc-transfer.contoso.local `
    -PrincipalsAllowedToRetrieveManagedPassword 'gMSA-Hosts'

# 3) 実際にジョブを動かすサーバー側で: gMSAをインストールし、パスワードを取得できるか確認する
Install-ADServiceAccount -Identity svc-transfer
Test-ADServiceAccount -Identity svc-transfer

KDSルートキーの作成はドメインで1回だけの作業です。作成直後は複製の都合でgMSAを作れないため、検証環境で待ちたくない場合に-EffectiveTime ((Get-Date).AddHours(-10))で過去日時を指定する手順が公式に案内されています(本番では使わないでください)。¹³ 作成後は、KDSサービスの運用ログにイベントID 4004が記録されているかで確認できます。¹²

flowchart TB
        accTitle: gMSAを使うまでの確認順
        accDescr: ドメイン側の準備とサーバー側の導入・確認を済ませてから、タスクへgMSAを割り当てます。
        A["ADと作業権限の前提を確認"] --> B["KDSルートキーを確認・作成"]
        B --> C["複製の収束を待つ"]
        C --> D["gMSAと取得を許すホストを設定"]
        D --> E["実行サーバーへ導入・テスト"]
        E --> F["タスクへ割り当てる"]

図5: ドメイン側の準備とサーバー側の導入・確認を済ませてから、タスクへgMSAを割り当てます。

タスクへの割り当ては、アカウントの作成とは別の作業

タスクへの割り当ては、タスクの実行アカウントにgMSA(CONTOSO\svc-transfer$のように末尾が$のアカウント名)を指定します。gMSAは人間がパスワードを知らないので、「実行アカウントのパスワードを入力する」前提のGUI手順とは勝手が違います。実務ではScheduledTasksモジュールのNew-ScheduledTaskPrincipalとRegister-ScheduledTaskで登録することになるため、この2つのコマンドレットのドキュメントを次の調べ先にしてください。あわせて、そのサーバーでgMSAに「バッチ ジョブとしてログオン」の権利を与える設定が必要になることがあります。

3.3 クラウドではマネージドIDを先に検討する

クラウド資源への接続では、キーの保存よりもマネージドIDやフェデレーション資格情報を優先して検討します。⁶⁷ マネージドIDは、Azure上のリソースに割り当てたIDでトークンを取得し、パスワードや鍵を持たずにEntra ID対応のサービスへ認証する仕組みです。次に何を読むかという意味では、まず概要ページでシステム割り当てとユーザー割り当ての違いを押さえ、³ PowerShellから使うならAzモジュールのConnect-AzAccount -Identity(マネージドIDでのサインイン)を入口にすると迷いません。

flowchart TB
        accTitle: クラウド資源はIDによる認証を先に考える
        accDescr: マネージドIDではAzureリソースに割り当てたIDでトークンを取得し、対応するサービスへ認証します。
        A["Azureリソースに割り当てたID"] --> B["トークンを取得"]
        B --> C["Entra ID対応サービスへ認証"]
        A -.-> D["パスワードや鍵をスクリプトに置かない"]

図6: マネージドIDではAzureリソースに割り当てたIDでトークンを取得し、対応するサービスへ認証します。

リモートのサーバーに対して資格情報を明示的に渡して処理を実行する場面では、PowerShell Remotingの認証の仕組みも絡みます。同時公開の「PowerShell Remoting/WinRM入門」を参照してください。

4. 対話実行と受け渡し ── PSCredential・SecureStringの役割

4.1 Get-Credentialで受け取る

対話的なスクリプトの基本形はこれだけです。

# ユーザー名とパスワードの入力を求め、PSCredentialオブジェクトとして受け取る
$cred = Get-Credential -Message '基幹DBの接続アカウントを入力してください'

# -Credentialパラメーターを持つコマンドにそのまま渡せる
Invoke-Command -ComputerName APPSV01 -Credential $cred -ScriptBlock { hostname }

Get-Credentialはユーザー名とパスワードの入力を促し、PSCredentialオブジェクトを返します。Windows PowerShell 5.1ではダイアログ、PowerShell 6以降ではコンソールでの入力になります。¹ パスワードはPSCredentialの中でSecureStringとして保持され、画面には表示されません。「人がその場で入力する」運用が許される場面では、これ以上複雑なことをする必要はありません。

flowchart TB
        accTitle: 人が入力する場合の受け渡し
        accDescr: 人が入力した資格情報をPSCredentialとして受け取り、対応するコマンドのCredentialパラメーターへ渡します。
        A["人がユーザー名とパスワードを入力"] --> B["Get-Credential"]
        B --> C["PSCredential"]
        C --> D["コマンドのCredentialへ渡す"]

図7: 人が入力した資格情報をPSCredentialとして受け取り、対応するコマンドのCredentialパラメーターへ渡します。

4.2 自作スクリプトもPSCredentialで受け取る

自作関数を作る側は、パスワードを[string]で受けず、[PSCredential]の-Credentialパラメーターを受けるように設計します。書き方の詳細は公式の解説「Add Credential support to PowerShell functions」にまとまっています。¹⁴

# 自作スクリプトの受け口の作法: パスワードを[string]で受けない
[CmdletBinding()]
param(
    # 資格情報はPSCredentialで受ける。省略時はGet-Credentialで対話取得、
    # 無人実行ではImport-ClixmlやGet-Secretの結果を渡す
    [Parameter(Mandatory)]
    [System.Management.Automation.PSCredential]$Credential
)
# 秘密を含む変数はデバッグ出力しない。出すのはユーザー名まで
Write-Verbose "接続アカウント: $($Credential.UserName)"

この例のCredentialはMandatoryなので、呼び出し側で用意して渡します。コメントにある対話取得は、呼び出し側でGet-Credentialを使う場合として読み分けてください。無人実行なら5章・6章の取得結果を渡し、入力待ちを残さないようにします。

flowchart TB
        accTitle: 呼び出し側で資格情報を用意する
        accDescr: 対話入力や保存先から得たPSCredentialを呼び出し側で用意し、スクリプトへ渡します。
        A["対話ならGet-Credential"] --> C["PSCredentialとして渡す"]
        B["無人なら保存先から取得"] --> C
        C --> D["秘密をデバッグ出力しない"]

図8: 対話入力や保存先から得たPSCredentialを呼び出し側で用意し、スクリプトへ渡します。

4.3 SecureStringの「非推奨」とPowerShellでの役割を分ける

SecureStringには知っておくべき事実が3つあります。

• .NET公式は「新規開発では使わないことを推奨」しています。内部配列の暗号化はWindowsでのみ行われ、非Windowsプラットフォームでは内部ストレージが暗号化されません。また使う瞬間には結局平文表現へ変換されるため、露出時間を短くする効果しかありません。推奨される代替は「プロセス外に保存された資格情報への不透明なハンドル」、つまりOSの資格情報ストアやKey Vaultのような仕組みです。¹⁵
• それでもPowerShellの標準装備はSecureString前提です。PowerShellは互換性のためSecureStringをサポートし続けており、コンソールやログへの偶発的な露出を避ける用途で今も使われています。平文文字列よりは安全である、という位置づけです。⁹
• 簡単に平文へ戻せます。PowerShell 7ではConvertFrom-SecureString -AsPlainTextの一発で平文になります。¹⁶ SecureStringは「読めない金庫」ではなく「うっかり見えないための封筒」程度に考えるのが実像に合っています。

実務の結論はこうです。SecureStringを理由に複雑な自作暗号化へ走らない。PowerShellの道具(Get-Credential、SecretManagement)が要求する形式として使い、保護の本体はDPAPIやボールトなどプロセス外の仕組みに置く。

flowchart TB
        accTitle: 受け渡しの形式と保存の保護は別
        accDescr: SecureStringはPowerShellの受け渡しに使い、保存する秘密の保護はDPAPIやボールトへ委ねます。
        A["PowerShellの標準形式を使う"] --> B["偶発的な画面・ログ露出を減らす"]
        C["保存する秘密を保護する"] --> D["DPAPIやボールトを使う"]
        B -.-> E["SecureStringを万能な金庫にしない"]
        D -.-> E

図9: SecureStringはPowerShellの受け渡しに使い、保存する秘密の保護はDPAPIやボールトへ委ねます。

5. Windowsの無人実行 ── DPAPIで保存する条件と準備

タスクスケジューラで動く無人スクリプトは、Get-Credentialで人に聞くわけにいきません。別の秘密が必要な場合、最小構成の実用解がExport-Clixmlによる資格情報ファイルです。

5.1 保存したユーザー・コンピューターで使う

Export-Clixmlは資格情報オブジェクトをWindowsのDPAPI(データ保護API)で暗号化して保存します。復号できるのは、保存したユーザーアカウントが、保存したそのコンピューター上で開いたときだけです。エクスポートしたファイルは別のマシンや別のユーザーでは使えません。⁴¹⁷ ファイルが持ち出されても開けない、という性質が無人実行の保存先として都合がよいわけです。

flowchart TB
        accTitle: 資格情報ファイルを開ける条件
        accDescr: WindowsのExport-Clixmlで保存した資格情報は、保存したユーザーとコンピューターの組み合わせで復号します。
        A["実行アカウントと保存する端末"] --> B["Export-Clixmlで暗号化保存"]
        B --> C["同じアカウント・同じ端末で読む"]
        C --> D["Import-Clixmlで資格情報を取得"]

図10: WindowsのExport-Clixmlで保存した資格情報は、保存したユーザーとコンピューターの組み合わせで復号します。

「同一ユーザー・同一マシン限定」は保護であると同時に、導入前に確認すべき条件です。

• タスクスケジューラの実行アカウントと合わせる必要があります。自分のアカウントで作った.credentialファイルは、タスクがサービスアカウントで動いた瞬間に復号できなくなります。準備作業は必ず「タスクの実行アカウントとして」行います(そのアカウントでPowerShellを起動して保存する)。タスクの実行アカウントとログオン種別の考え方は「タスクスケジューラのタスクが実行されない・0x1で終わる」で詳述しています。
• サーバーの入れ替え・アカウント変更で必ず作り直しになります。「移行したら動かない」の定番原因なので、準備手順をスクリプト化してリポジトリに残しておきます(パスワード自体はもちろん含めません)。
• 同一アカウントで動くプロセスからは復号できます。DPAPIはそのユーザーとして動くコードには開かれているため、実行アカウントに不要なソフトウェアを同居させない、アカウントの権限を最小にする、という周辺の衛生管理は引き続き必要です。
• 非Windowsでは暗号化されません。macOS/Linuxでは実質平文(Unicode文字配列)で出力されると公式ドキュメントに明記されています。⁴

flowchart TB
        accTitle: コピーできることと利用できることは違う
        accDescr: 別のサーバーやアカウントへ移るときは資格情報ファイルを作り直し、同じアカウントで動くコードへの対策も続けます。
        A["保存した資格情報ファイル"] --> B{"使用する環境"}
        B -->|"同じ端末・同じユーザー"| C["復号して利用できる"]
        B -->|"端末やユーザーを変更"| D["その環境で作り直す"]
        C -.-> E["アカウントの権限は最小にする"]

図11: 別のサーバーやアカウントへ移るときは資格情報ファイルを作り直し、同じアカウントで動くコードへの対策も続けます。

5.2 初回の対話準備と本番の無人処理を分ける

次の例は、前半が初回の保存、後半が本番での読み取りです。準備時と本番時で実行アカウントをそろえます。

# --- 準備(1回だけ、タスクの実行アカウントで実行する) ---
$cred = Get-Credential -Message '連携用アカウント'
$cred | Export-Clixml -Path 'D:\Jobs\secrets\transfer.credential'

# --- 本番スクリプト(無人実行) ---
$cred = Import-Clixml -Path 'D:\Jobs\secrets\transfer.credential'
# 例: 別資格情報が必要な共有への接続やリモート実行に使う
Invoke-Command -ComputerName FILESV01 -Credential $cred -ScriptBlock { Get-ChildItem D:\Export }

「そのアカウントでPowerShellを起動して保存する」の具体的な手順も書いておきます。上の準備部分(Get-CredentialとExport-Clixmlの2行)をD:\Jobs\save-credential.ps1として保存しておき、そのアカウントとしてPowerShellを起動して実行します。

# 準備をタスクの実行アカウントで行う: runasでそのアカウントとしてPowerShellを起動する
# パスワードはrunasが対話で聞くため、コマンドライン・履歴・トランスクリプトに平文が残らない
runas /user:CONTOSO\svc-transfer "pwsh.exe -NoProfile -NoExit -File D:\Jobs\save-credential.ps1"

runasは対話ログオン相当の権限を使うため、そのアカウントに「ローカル ログオン」を許可していない環境では失敗します。その場合は、準備作業の間だけログオンを許可し、保存が終わったら元の設定に戻すのが現実的です。Get-Credentialの入力自体に対話セッションが必要なので、「無人のタスクを1本作って準備する」方法は使えません。なお、実行アカウントのプロファイルが一度も作られていないマシンでは、初回のログオンでプロファイルが作られてからDPAPIのマスターキーが置かれる点も、この手順を踏む理由のひとつです。

flowchart TB
        accTitle: 無人実行の前に必要な対話準備
        accDescr: 実行アカウントで対話的に資格情報を保存する準備と、本番でファイルから読み込む処理を分けます。
        A["タスクの実行アカウントで起動"] --> B["対話で資格情報を入力"]
        B --> C["Export-Clixmlで保存"]
        C --> D["本番ではImport-Clixml"]
        D --> E["入力を求めずジョブを実行"]

図12: 実行アカウントで対話的に資格情報を保存する準備と、本番でファイルから読み込む処理を分けます。

5.3 なぜ同じ環境に結び付くのか

なぜそうなるのかは、仕組みを一段だけ覗くと腑に落ちます。DPAPIはユーザーのログオン資格情報(通常はパスワードのハッシュ)から導いた鍵で「マスターキー」を暗号化し、それをそのユーザーのプロファイル内に置きます。データ本体は、そのマスターキーから作られるセッション鍵で暗号化されます。つまり鍵を握っているのは「そのユーザーとしてログオンできること」そのもので、鍵ファイルを別途どこかに保管する必要がない代わりに、鍵がユーザーとマシンに縛られます。公式ドキュメントも「通常、暗号化したユーザーと同じログオン資格情報を持つユーザーだけが復号でき、暗号化と復号は同じコンピューター上で行う必要がある」と説明しています。¹⁸ これが「同一ユーザー・同一マシン限定」の中身です。

flowchart TB
        accTitle: DPAPIの鍵とデータの関係
        accDescr: DPAPIはログオン資格情報に結び付いた鍵の階層でデータを保護するため、別に保管する鍵ファイルを用意せずに済みます。
        A["ログオン資格情報から導く鍵"] -->|"保護する"| B["プロファイル内のマスターキー"]
        B -->|"生成に使う"| C["データ用のセッション鍵"]
        C -->|"暗号化する"| D["保存するデータ"]

図13: DPAPIはログオン資格情報に結び付いた鍵の階層でデータを保護するため、別に保管する鍵ファイルを用意せずに済みます。

なお、ConvertFrom-SecureStringに-Keyを指定してAES暗号化する方法もありますが、こんどは「鍵ファイルをどう守るか」という同じ問題が一段ずれて残るだけになりがちです。¹⁶ マシンをまたぐ必要が出た時点で、6章のボールトか、3章の「持たない設計」に進むべきです。

6. 複数の秘密を管理する ── SecretManagementとSecretStore

接続先が増え、APIキーやトークンも混ざってくると、.credentialファイルの散在が管理限界を迎えます。そこで使うのがSecretManagementモジュールです。これは秘密の保管場所(ボールト)への統一インターフェースで、実際の保存は拡張ボールトが担います。ローカル保存のSecretStore(Microsoft製)のほか、Azure Key Vault、KeePassなどの拡張ボールトを同じコマンドで扱えます。⁷¹⁹

6.1 インストール前に、実行アカウントと保守方針を確認する

gMSAなどの管理されたアカウントでは動きません。SecretManagementはプロファイル($env:LOCALAPPDATA)とDPAPIに依存しており、プロファイルを持たないWindowsの管理されたアカウントを現在サポートしていないと明記されています。¹⁹ gMSAで動くジョブに秘密を持たせたい場合は、この組み合わせは選べません(そもそもgMSAなら秘密を持たない設計に寄せられることが多い ── 3章)。

SecretManagement/SecretStoreは機能完成(feature complete)扱いで、積極的な新機能開発は終了しています。セキュリティ修正と重大バグの対応は継続されるため使うこと自体は問題ありませんが、公式も「秘密の性質はパスワードレスや連携資格情報へ変わりつつある」としており、長期の設計では認証方式そのものの見直し(Entra IDのマネージドID等)も視野に入れるべきです。⁷

flowchart TB
        accTitle: 採用前に実行アカウントを確認する
        accDescr: SecretManagementとSecretStoreを選ぶ前にアカウントの制約を確認し、gMSAで動くジョブと混同しないようにします。
        A["ジョブの実行アカウントを確認"] --> B{"Windowsの管理されたアカウントか"}
        B -->|"gMSAなど"| C["この組み合わせは選ばない"]
        B -->|"それ以外"| D["プロファイルと利用条件を確認"]
        D --> E["保存先と解錠方法を選ぶ"]

図14: SecretManagementとSecretStoreを選ぶ前にアカウントの制約を確認し、gMSAで動くジョブと混同しないようにします。

6.2 インターフェースと保存先を分ける

SecretManagementは秘密を扱う共通の窓口で、実際に保存するのは登録した拡張ボールトです。コードでは秘密の名前を使い、保存先の選択はボールト登録で行います。⁷¹⁹

# 初回のみ: モジュール導入とボールト登録
Install-Module Microsoft.PowerShell.SecretManagement, Microsoft.PowerShell.SecretStore
Register-SecretVault -Name SecretStore -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault

# 秘密の登録(初回アクセス時にボールトのパスワードを設定する)
Set-Secret -Name TransferJobCred -Secret (Get-Credential)

# スクリプト側: 名前で取り出す。保存先が変わってもこの行は変わらない
$cred = Get-Secret -Name TransferJobCred

秘密の値にはPSCredentialやSecureStringのほか、文字列・バイト配列・ハッシュテーブルも保存でき、初回アクセス時にボールト自体を保護するパスワードの設定を求められます。²⁰ 利点は、スクリプトから「どこに保存されているか」の知識が消えることです。開発機ではSecretStore、本番ではAzure Key Vault(Az.KeyVaultモジュールが拡張ボールトを提供)という差し替えが、Register-SecretVaultの構成変更だけで済みます。⁶⁷

flowchart TB
        accTitle: 秘密の名前とボールトを分離する
        accDescr: スクリプトは共通コマンドで秘密を指定し、登録した拡張ボールトが実際の保存と取得を担います。
        A["秘密を名前で指定するスクリプト"] --> B["Set-Secret・Get-Secret"]
        B --> C["登録した拡張ボールト"]
        C --> D["ローカルやクラウドの保存先"]

図15: スクリプトは共通コマンドで秘密を指定し、登録した拡張ボールトが実際の保存と取得を担います。

6.3 無人実行は、プロンプト停止と解錠を別々に設計する

SecretStoreは既定で対話的にボールトパスワードを要求します。そのままタスクスケジューラに載せるとプロンプト待ちで止まります。公式ドキュメントは無人実行向けに、InteractionをNoneにし、DPAPI保護ファイル(Export-Clixml)に退避したボールトパスワードをUnlock-SecretStoreで渡す構成を案内しています。⁵ つまりボールトの鍵は結局DPAPIで守ることになり、前章の同一ユーザー・同一マシン制約を引き継ぎます。パスワード要求自体を無効化(Authentication None)する構成も可能ですが、鍵がファイルシステム権限だけで守られることになるため、強い保護が必要な用途では推奨されていません。²¹

flowchart TB
        accTitle: 無人実行でボールトを解錠する
        accDescr: 対話を出さない設定に加えてDPAPIで保護したパスワードを供給し、SecretStoreを解錠してから秘密を取得します。
        A["InteractionをNoneに設定"] -.-> C["Unlock-SecretStoreで解錠"]
        B["DPAPI保護ファイルから鍵を読む"] --> C
        C --> D["Get-Secretで必要な秘密を取得"]
        B -.-> E["同一ユーザー・同一端末が前提"]

図16: 対話を出さない設定に加えてDPAPIで保護したパスワードを供給し、SecretStoreを解錠してから秘密を取得します。

対話を出さないInteraction Noneと、パスワード要求そのものをなくすAuthentication Noneは別の設定です。 無人実行にするために保護まで外してしまわないよう、上記の供給方法と合わせて選びます。⁵²¹

6.4 別のボールトでも、利用するユーザーを確認する

Windowsの資格情報マネージャー(Credential Manager)をボールトとして使うコミュニティ拡張も存在します。⁷ cmdkeyで登録した資格情報が自動で使われる仕組みなど、資格情報マネージャー自体の挙動は「ネットワークドライブとUNCパスの落とし穴」で触れたとおり、こちらもユーザープロファイル単位である点は同じです。

7. ログ・トランスクリプトに秘密を残さない

保存を固めても、実行時の記録から漏れては意味がありません。記録する仕組みの保護と、秘密を出力しない書き方の両方を確認します。

7.1 イベントログとトランスクリプトの露出を把握する

第一に、PowerShellは実行内容を記録する機能を複数持っており、組織設定で有効になっていることがあります。スクリプトブロックログを有効にすると、処理したすべてのスクリプトブロックの内容がイベントログに記録されます。公式ドキュメントは「スクリプトログを有効にすると、スクリプトで使われた資格情報や機微データがイベントログに書かれうる」と明示的に警告し、診断以外の用途では保護されたイベントログ(Protected Event Logging)の併用を推奨しています。¹⁰ 保護されたイベントログは、対象のイベントログの内容をCMS(暗号メッセージ構文)の公開鍵で暗号化して書き込み、秘密鍵を持つ別の安全な場所でだけ復号できるようにする仕組みです。¹⁰ トランスクリプション(操作の書き起こし)も同様で、コンソールに流れた内容はファイルに残ります。

flowchart TB
        accTitle: 保存先とは別に記録も保護する
        accDescr: 保護されたイベントログは対象イベントを公開鍵で暗号化し、秘密鍵を置いた安全な場所で復号します。
        A["記録対象のイベント"] --> B["公開鍵で暗号化"]
        B --> C["暗号化した内容をログへ保存"]
        C --> D["安全な場所の秘密鍵で復号"]
        E["コンソールへ秘密を出さない"] -.-> F["トランスクリプトへの露出も防ぐ"]

図17: 保護されたイベントログは対象イベントを公開鍵で暗号化し、秘密鍵を置いた安全な場所で復号します。

7.2 保護されたイベントログと、5.1・7それぞれの設定を確認する

自分の環境がどうなっているかは、ポリシーが書き込むレジストリ値で確認できます。保護されたイベントログはグループポリシーの「コンピューターの構成 > 管理用テンプレート > Windows コンポーネント > イベント ログ記録(Event Logging)」にある「保護されたイベント ログを有効にする(Enable Protected Event Logging)」で設定され、対応するレジストリは次のとおりです。²²

# 保護されたイベント ログが有効か(ポリシー未構成ならキー自体が存在しない)
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\EventLog\ProtectedEventLogging' `
    -Name EnableProtectedEventLogging -ErrorAction SilentlyContinue

# スクリプトブロックログ側のポリシー(PowerShell 7系)
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\PowerShellCore\ScriptBlockLogging' `
    -Name EnableScriptBlockLogging -ErrorAction SilentlyContinue

# Windows PowerShell 5.1側は別のキー
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging' `
    -Name EnableScriptBlockLogging -ErrorAction SilentlyContinue

スクリプトブロックログのレジストリ値は、PowerShell 7系がPowerShellCore配下¹⁰、Windows PowerShell 5.1がWindows\PowerShell配下²³と分かれています。5.1と7が同居しているサーバーでは、両方を確認してください。

確認の勘所は、スクリプトブロックログだけが有効で保護されたイベントログが無効という組み合わせです。これは「記録は取るが平文で貯める」状態なので、資格情報を扱うスクリプトを載せる前に把握しておいてください。

flowchart TB
        accTitle: ログを取る設定と保護する設定を照合する
        accDescr: PowerShellの各バージョンのログ設定と保護されたイベントログの設定を照合し、記録だけが有効な状態を把握します。
        A["5.1と7のログポリシーを確認"] --> C["有効な設定の組み合わせを照合"]
        B["保護されたイベントログを確認"] --> C
        C --> D["資格情報を扱う前に状態を把握"]

図18: PowerShellの各バージョンのログ設定と保護されたイベントログの設定を照合し、記録だけが有効な状態を把握します。

7.3 引数・画面・例外メッセージに秘密を出さない

記録の保護と同時に、「平文がコマンドラインや画面を通過しない」書き方を徹底します。

• パスワードを引数で受け取る設計にしない。.\job.ps1 -Password "P@ssw0rd"と打った時点で、ログ・履歴・プロセス一覧に残る前提で考えます。受けるならPSCredentialかSecureStringで受けます。¹⁴

受け口のコード例は4.2節にまとめました。対話取得と無人での取得を呼び出し側で選び、PSCredentialとして渡します。

• 秘密を含む変数をWrite-HostやWrite-Verboseでデバッグ出力しない。トラブルシューティング時の「一時的なつもり」の出力が、トランスクリプトに永続化します。
• 例外メッセージへの混入に注意する。接続文字列を組み立ててからエラーを投げると、catchしたログに接続文字列ごと記録されがちです。エラー処理でログに何を書くかの設計は「PowerShellのエラー処理と再実行設計」も併せてどうぞ。

8. 実務の定石 ── 実行条件から最終確認する

3〜7章を確認したうえで、実際のジョブに合う方法を選びます。

迷ったら「持たない > マシンに固定して持つ(DPAPI) > ボールトで持つ」の順で、上から検討してください。

flowchart TB
        accTitle: 無人ジョブの保存方法を最終確認する
        accDescr: 保存方法だけでなく実行アカウント、解錠、移行時の再準備とログへの露出まで確認して運用へ進めます。
        A["必要な秘密だけを保存"] --> B["実行アカウントを確認"]
        B --> C["無人での取得・解錠を確認"]
        C --> D["移行時の再準備を決める"]
        D --> E["ログへ秘密を出さない"]

図19: 保存方法だけでなく実行アカウント、解錠、移行時の再準備とログへの露出まで確認して運用へ進めます。

9. まとめ

最初に検討するのは、スクリプトからパスワードをなくすことです。 Windows認証と実行アカウントへの権限付与、gMSA、マネージドIDを先に考え、別の秘密が必要な場合だけ保存方法を選びます。

対話実行はGet-CredentialとPSCredentialを基本にします。SecureStringはPowerShellの標準的な受け渡し形式として使い、自作の保護機構の土台にはしません。平文を変換しても、Git履歴・共有フォルダ・ログに残った元の平文は守れないからです。

Windowsの無人実行でDPAPIを使うなら、タスクの実行アカウント自身で保存し、同じコンピューターで使うことが要点です。移行時の作り直しと、非Windowsでは暗号化されない制約を含めて運用を決めます。秘密が増えたらSecretManagementと拡張ボールトで一元管理しますが、SecretStoreの解錠用パスワード、gMSAでは使えない条件、機能完成扱いの保守方針も確認します。

最後に、保存先を保護して終わりにしないでください。平文を引数・画面・例外メッセージへ出さず、スクリプトブロックログとトランスクリプトへの漏えいも設計に含める。 ここまでをそろえて、無人でも安全に扱える構成にします。

flowchart TB
        accTitle: 保存と実行と記録を一緒に確認する
        accDescr: 秘密の保存をなくせないかを検討したうえで、必要な秘密の受け渡し・保存・無人取得・記録を順に見直します。
        A["秘密を持つ必要を減らす"] --> B["標準の形式で受け渡す"]
        B --> C["必要な秘密だけ保護して保存"]
        C --> D["実行条件と解錠を確認"]
        D --> E["ログへの露出も防ぐ"]

図20: 秘密の保存をなくせないかを検討したうえで、必要な秘密の受け渡し・保存・無人取得・記録を順に見直します。

関連記事

• Windowsアプリの機密情報保存 - DPAPIで平文設定を避ける
• タスクスケジューラのタスクが実行されない・0x1で終わる ── 原因の切り分けと安全な運用設計
• ネットワークドライブとUNCパスの落とし穴 ── 業務アプリでファイルサーバー(共有フォルダ)を扱う実務
• PowerShell Remoting/WinRM入門
• PowerShellのエラー処理と再実行設計
• PowerShellスクリプトの引数設計とモジュール化 ── 「動くスクリプト」から「人に渡せるスクリプト」へ

関連する相談領域

合同会社小村ソフトでは、運用スクリプト・定期バッチに埋め込まれた資格情報の棚卸しと安全な保管への移行、gMSAを含む実行アカウント設計、無人実行ジョブのセキュリティレビューを扱っています。「動いているから触れない」まま放置された平文パスワードの整理からご相談ください。

• 技術相談・設計レビュー
• Windowsの最新化・保守
• 不具合調査・原因解析
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

PowerShellスクリプトにパスワードを平文で書いてはいけないのはなぜですか？

スクリプトはコピーされ、共有され、履歴に残る前提の成果物だからです。Gitに一度コミットすれば履歴から消すのは困難で、共有フォルダに置けば読み取り権限のある全員に見え、スクリプトブロックログやトランスクリプトにはコマンドの内容がそのまま記録されます。つまり平文パスワードは「ファイルが見えた時点で漏えい確定」の構造を作ってしまいます。まず漏えい経路を締めるのではなく、パスワードをスクリプトの外の保護された場所へ出すことが対策の本筋です。

Export-Clixmlで保存した資格情報はどこまで安全ですか？

WindowsではDPAPI(データ保護API)で暗号化され、保存したユーザーアカウントかつ同じコンピューター上でしか復号できません。ファイルが盗まれても他のマシン・他のユーザーでは開けないため、無人実行用の保存先としては実用的な選択肢です。ただし同一アカウントで動くプロセスからは復号できるので万能ではなく、またmacOSやLinuxでは暗号化されず実質平文で出力される点に注意が必要です。タスクスケジューラから使う場合は、タスクの実行アカウント自身で保存ファイルを作る必要があります。

SecureStringは今でも使うべきですか？

.NETの公式ドキュメントは新規開発でのSecureString使用を推奨しないと明記しています。暗号化はWindowsでしか行われず、非Windowsでは内部が暗号化されません。また使う瞬間には結局平文へ戻す必要があります。一方でPowerShellの世界では、Get-CredentialやSecretManagementなど標準の道具がSecureStringを前提にしており、平文文字列で持ち回るよりは露出が減るため、当面は「PowerShellの標準的な受け渡し形式」として付き合うのが現実的です。自前で暗号化の仕組みを作る材料にはしないでください。

タスクスケジューラの無人実行でSecretStoreを使うとパスワード入力で止まりませんか？

既定構成のままでは止まります。SecretStoreは既定でボールトパスワードを要求し、対話プロンプトを出すためです。無人実行では、Interactionを None にし、ボールトパスワードをDPAPI保護のファイル(Export-Clixml)から読み込んでUnlock-SecretStoreで解錠する構成が公式ドキュメントで案内されています。ただしこれは「ボールトの鍵をDPAPIで守る」構成であり、結局DPAPIの制約(同一ユーザー・同一マシン)を引き継ぎます。その手前で、gMSAや実行アカウントの権限付与で資格情報自体を不要にできないかを先に検討してください。

そもそも資格情報を保存しない方法はありますか？

あります。むしろそれが第一選択です。Windowsのタスクやサービスは実行アカウントの権限で動くため、接続先(共有フォルダ、SQL ServerのWindows認証など)に実行アカウント自身の権限を付与すれば、スクリプトはパスワードを一切持たずに済みます。実行アカウントをgMSA(グループ管理サービスアカウント)にすれば、パスワードは240バイトのランダム値をOSが30日ごとに自動更新し、人間は誰もパスワードを知らない状態を作れます。gMSAはタスクスケジューラのタスクにも使えます。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。