「新しいPCでスクリプトが『このシステムではスクリプトの実行が無効になっているため…』と言われて動かない」「とりあえず -ExecutionPolicy Bypass を付けたら動いたので、全部のタスクにそう書いてある」「共有フォルダーに置いた .ps1 が、ある人の端末でだけ署名エラーになる」── PowerShellの実行ポリシーは、社内の自動化を進めるとほぼ確実にぶつかる壁です。そして多くの現場で、仕組みを理解しないまま「Bypassで蓋をする」対処が積み重なっています。
厄介なのは、実行ポリシーが「何を守るための機能なのか」が誤解されやすいことです。セキュリティ機能だと思って厳しくしすぎて業務が止まる。逆に「どうせ意味がない」と全部Bypassにして、うっかり事故を防ぐ最後の安全装置まで外してしまう。どちらも仕組みを知っていれば避けられます。
この記事では、中小企業の情シス担当者や、PowerShellで社内の定型作業を自動化している方を対象に、実行ポリシーの正体とスコープの優先順位、Zone.Identifier(いわゆるMark of the Web)との関係、そしてスクリプト署名による配布運用までを、公式ドキュメントの裏付けつきで整理します。
1. まず結論
- 実行ポリシーはセキュリティ境界ではなく安全装置です。公式ドキュメントは「実行ポリシーはユーザーの操作を制限するセキュリティシステムではない」「スクリプトの内容をコマンドラインに入力すれば簡単に迂回できる」と明言しています。目的は、基本ルールを決めて意図しない実行(うっかり事故)を防ぐことです。1
- 実行ポリシーが影響するのはスクリプトの実行だけで、対話的なコマンド実行は常に可能です。Windows PowerShell 5.1の既定はクライアントOSでRestricted(スクリプト実行不可)、Windows ServerでRemoteSignedです。PowerShell 7ではRemoteSignedが既定とされています。21
- ポリシーには5つのスコープがあり、優先順位は MachinePolicy > UserPolicy > Process > CurrentUser > LocalMachine です。MachinePolicy/UserPolicyはグループポリシー専用で、
Set-ExecutionPolicyでは変更できず、コマンドラインの指定でも上書きできません。13 - RemoteSignedが署名を要求するのは「インターネット由来」のスクリプトだけです。由来の判定はファイルに付くZone.Identifier代替データストリーム(Mark of the Web)で行われ、内容を確認したうえで
Unblock-Fileで除去すれば、ポリシーを変えずに実行できます。14 - AllSignedはローカル作成分も含むすべてのスクリプトに信頼された発行元の署名を要求します。署名は
Set-AuthenticodeSignatureで付与し、ファイル末尾に# SIG #のコメントブロックとして埋め込まれます。15 - 署名には必ずタイムスタンプ(-TimestampServer)を付けます。タイムスタンプがあれば、署名証明書の期限が切れた後もスクリプトが有効であり続けます。コード署名証明書の多くは有効期間1年なので、これを省くと毎年の時限爆弾になります。65
- 自己署名証明書はテスト用途限定です。自己署名で署名したスクリプトは他のコンピューターでは実行できません。組織配布には証明機関(社内CAまたは商用CA)発行のコード署名証明書を使います。57
- 組織で統制するならグループポリシーの「スクリプトの実行を有効にする」で一元管理します。この設定はPowerShell側のすべてのスコープ設定に優先します。1
2. 実行ポリシーの正体 ── 「セキュリティ境界」ではなく「安全装置」
まず前提の確認です。公式ドキュメント(about_Execution_Policies)の記述は率直です。実行ポリシーは、PowerShellが構成ファイルを読み込みスクリプトを実行する条件を制御する「安全機能(safety feature)」であり、「ユーザーの操作を制限するセキュリティシステムではない」。スクリプトを実行できないユーザーでも、スクリプトの内容をコマンドラインに貼り付ければ同じ処理を実行できるからです。実行ポリシーの役割は、基本ルールを設定し、それに意図せず違反することを防ぐことだ、と明記されています。1 入門ドキュメントでも「セキュリティ境界ではない。意図的にスクリプトを実行しようとするユーザーは止められない」と繰り返されています。2
この位置づけを押さえると、運用の設計方針が定まります。「実行ポリシーを厳しくしたから攻撃は防げる」も「どうせ迂回できるから無意味」も、どちらも間違いです。攻撃対策は別レイヤー(アプリケーション制御、権限最小化、監査ログ)の仕事、実行ポリシーは事故防止の仕事です。8
主要なポリシーの違いを整理します。1
| ポリシー | スクリプト実行 | 署名要求 | 位置づけ |
|---|---|---|---|
| Restricted | 不可(個別コマンドのみ) | ─ | Windows PowerShell 5.1のクライアントOS既定2 |
| AllSigned | 可 | すべてのスクリプト・構成ファイルに要求。未分類の発行元は実行前に確認 | 署名運用ができる組織向け |
| RemoteSigned | 可 | インターネット由来のスクリプトにのみ要求。ローカル作成分は不要 | 実務の標準。PowerShell 7の既定1 |
| Unrestricted | 可 | なし(イントラネットゾーン外は警告) | 非Windowsの既定(変更不可)1 |
| Bypass | 可 | なし。警告もプロンプトもなし | PowerShellを土台に独自のセキュリティモデルを持つアプリ組み込み用1 |
見落とされがちですが、Restrictedは業務スクリプトだけでなく、プロファイル(.ps1)やモジュール(.psm1)、書式構成ファイル(.ps1xml)の読み込みまで止めます。1「新しい端末でプロファイルが読み込まれない」の原因が実行ポリシーだった、というのは定番の相談です。
3. スコープと優先順位 ── 「設定したのに変わらない」の正体
実行ポリシーは1つの値ではなく、5つのスコープごとに設定でき、優先順位の高いものが実効値になります。1
| スコープ | 設定手段 | 保存先 | 優先順位 |
|---|---|---|---|
| MachinePolicy | グループポリシー(コンピューターの構成) | GPO | 1(最優先) |
| UserPolicy | グループポリシー(ユーザーの構成) | GPO | 2 |
| Process | -ExecutionPolicy 起動パラメーター / -Scope Process |
環境変数 $Env:PSExecutionPolicyPreference(セッション終了で消滅) |
3 |
| CurrentUser | Set-ExecutionPolicy -Scope CurrentUser |
ユーザーの構成 | 4 |
| LocalMachine | Set-ExecutionPolicy(既定スコープ、要管理者) |
全ユーザー共通の構成 | 5 |
「設定したのに変わらない」トラブルの切り分けは、実効値ではなく一覧を見るのが定石です。
# 実効ポリシーだけでなく、どのスコープが効いているかを必ず確認する
Get-ExecutionPolicy -List
# 例: LocalMachineをAllSignedにしていても、CurrentUserのRemoteSignedが勝つ
# Scope ExecutionPolicy
# ----- ---------------
# MachinePolicy Undefined
# UserPolicy Undefined
# Process Undefined
# CurrentUser RemoteSigned
# LocalMachine AllSigned
# 自分の環境だけ変えるなら管理者権限不要のCurrentUserスコープが手軽
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
CurrentUserはLocalMachineより優先されるため、上の例の実効ポリシーはRemoteSignedです。1 Set-ExecutionPolicy は既定でLocalMachineスコープに書き込むため管理者権限が必要ですが、CurrentUserスコープなら一般ユーザーでも変更できます。3
そして組織管理の本命がグループポリシーです。「スクリプトの実行を有効にする(Turn on Script Execution)」ポリシーは、PowerShell側で設定したすべてのスコープに優先します。無効にするとRestricted相当、有効にすると「すべてのスクリプトを許可(Unrestricted)」「ローカルスクリプトとリモートの署名済みスクリプトを許可(RemoteSigned)」「署名済みスクリプトのみを許可(AllSigned)」から選択でき、管理用テンプレートの Windowsコンポーネント\Windows PowerShell 配下にあります。コンピューターの構成はユーザーの構成に優先します。1 GPOで管理された環境では Set-ExecutionPolicy は設定を保存こそすれ実効せず、競合を説明するメッセージが表示されます。3
ここで重要な帰結がひとつ。GPOで管理していれば、タスクやショートカットに書かれた -ExecutionPolicy Bypass は効きません。Processスコープの指定はLocalMachine/CurrentUserの構成には勝ちますが、グループポリシーには勝てないと明記されています。1「Bypassを書けば何とかなる」が通用するのは、逆に言えば組織として実行ポリシーを管理していない環境だけです。
4. Zone.Identifier(Mark of the Web)とUnblock-File
RemoteSignedの「リモート(インターネット由来)」は、ファイルの置き場所ではなく印で判定されます。ブラウザーなどのプログラムはダウンロードしたファイルに代替データストリームを付加し、「インターネットから来たファイル」としてマークします。1 このストリームがZone.Identifierで、インターネットゾーンを示す値3が入っています。いわゆるMark of the Webです。4
RemoteSigned環境でこの印付きの未署名スクリプトを実行しようとすると、「デジタル署名されていません」というエラーでブロックされます。対処は2段階です。
# 1) まずどのファイルがブロックされているかを確認する(読み取りだけの安全な操作)
Get-Item -Path C:\Tools\*.ps1 -Stream Zone.Identifier -ErrorAction SilentlyContinue
# 2) 内容をレビューして安全だと判断できたものだけブロック解除する
# (Unblock-FileはZone.Identifierストリームを除去する。実行ポリシー自体は変わらない)
Unblock-File -Path C:\Tools\Get-InventoryReport.ps1
Unblock-File はZone.Identifier代替データストリームを除去するコマンドレットで、エクスプローラーのプロパティにある「許可する(Unblock)」ボタンと同じ操作です。実行ポリシーを緩めずに、確認済みのファイルだけを通せるのがポイントです。4 公式ドキュメントも「使う前にファイルと入手元を確認し、安全であることを検証すること」を必須の手順としています。43
逆方向の落とし穴も知っておく価値があります。すべての入手経路がMark of the Webを付けるわけではありません。curl.exe や Invoke-WebRequest、Invoke-RestMethod でダウンロードしたファイルにはインターネットゾーンの印が付かないことがあると明記されています。1 つまりRemoteSignedは「ダウンロードした危険なファイルをすべて止める」保証ではありません(だからこそ安全装置なのです)。また、UNCパスとインターネットパスを区別しない構成のシステムでは、共有フォルダー上のスクリプトがRemoteSignedで実行を拒否されることがある、という注意書きもあります。1「共有に置いた .ps1 が一部の端末でだけ止まる」ときは、ゾーン設定とZone.Identifierの有無を疑ってください。
なお、ダウンロードした実行ファイル(.exe)側で似た症状を起こすSmartScreenの仕組みは「Windowsで「Windows によって PC が保護されました」が出る理由」で扱っています。
5. スクリプト署名の実務 ── Set-AuthenticodeSignatureとタイムスタンプ
AllSigned運用、あるいはRemoteSigned環境で配布物に署名する運用に進むには、コード署名証明書が必要です。入手経路は3つに整理できます。5
| 入手経路 | 信頼される範囲 | 判断 |
|---|---|---|
自己署名(New-SelfSignedCertificate) |
自分のコンピューターのみ。他の端末では実行不可 | テスト・検証専用。配布には使わない57 |
| 社内CA(証明機関)発行 | 社内CAを信頼するよう構成した組織内の端末 | ADドメイン環境の本命。証明書の発行・失効を組織で統制できる |
| 商用CA発行(有償) | Windows全般(パブリックCAを信頼済み) | 社外にスクリプトを配布する場合 |
公式ドキュメントの整理も同じで、「証明機関が発行する証明書は他のコンピューターでも信頼される」「自己作成の証明書は無料だが自分のコンピューター専用であり、テスト目的に限定すべき」とされています。5 社内配布が目的なら、Active Directory証明書サービスなどの社内CAからコード署名証明書を発行するのが現実的です。
まずテスト用の自己署名証明書で流れを確認します。
# テスト用のコード署名証明書を作る(自己署名 ── この端末でしか信頼されない)
$params = @{
Subject = 'CN=KomuraSoft Code Signing (Test)'
Type = 'CodeSigningCert'
CertStoreLocation = 'Cert:\CurrentUser\My'
HashAlgorithm = 'sha256'
}
$cert = New-SelfSignedCertificate @params
New-SelfSignedCertificate はテスト目的の自己署名証明書を作成するコマンドレットで、-Type CodeSigningCert を指定するとコード署名用の拡張が入ります。有効期間は既定で1年です。7 自己署名証明書をAllSigned環境のテストに使う場合は、その端末の信頼されたルート証明機関ストアへの登録が必要です。5
署名の本番はこの1行です。
# 証明書ストアからコード署名証明書を取得して署名する
# -CodeSigningCertは「コード署名に使える証明書」に絞るだけなので、
# 期限内で秘密鍵を持つものに限定し、複数ある環境ではSubjectやThumbprintで特定する
$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert |
Where-Object { $_.HasPrivateKey -and $_.NotAfter -gt (Get-Date) -and
$_.Subject -eq 'CN=KomuraSoft Code Signing (Test)' } |
Sort-Object NotAfter -Descending |
Select-Object -First 1 # 更新などで同じSubjectが複数あるときは有効期限が最も先のもの1枚に絞る
# タイムスタンプは必須。証明書の期限が切れても署名が有効であり続ける
# URLは証明書の発行元(社内CA/購入先)が案内するタイムスタンプサービスに置き換えること
Set-AuthenticodeSignature -FilePath .\Invoke-NightlyBatch.ps1 -Certificate $cert `
-HashAlgorithm SHA256 -TimestampServer 'http://timestamp.example.com'
# 署名の状態はGet-AuthenticodeSignatureで確認できる(Valid/NotSigned/HashMismatchなど)
Get-AuthenticodeSignature -FilePath .\Invoke-NightlyBatch.ps1
- 署名はファイル末尾の
# SIG #コメントブロックとして埋め込まれます。既存の署名があれば置き換えられます。つまり、署名後にスクリプトを1文字でも書き換えれば署名は無効になります。これが改変検知として機能します。 -TimestampServerを指定すると、証明書の有効期限が切れてもスクリプトが失敗しなくなります。署名の有効性は「署名証明書が有効な間」または「証明書が有効だった時点で署名されたことをタイムスタンプサーバーが検証できる限り」であり、コード署名証明書の多くは有効期間1年なので、タイムスタンプが長期運用の生命線です。65 利用するタイムスタンプサービスのURLは証明書の発行元(CA)の案内に従ってください。- Windows PowerShell 5.1やPowerShell 7.2より前で署名するスクリプトは、ASCIIまたはUTF8NoBOMで保存が必要でした。PowerShell 7.2以降は任意のエンコーディングで署名済みスクリプトをサポートします。5 5.1が残る現場では、日本語コメント入りスクリプトのエンコーディングで署名検証が壊れる事故が起きやすいので要注意です。5.1と7の違い全般は「Windows PowerShell 5.1とPowerShell 7の違いと移行」を参照してください。
AllSigned環境では、署名済みでも発行元をまだ信頼済み/拒否に分類していない場合、実行時に「この信頼されていない発行元からのソフトウェアを実行しますか?」というプロンプトが出ます。「常に実行する」を選ぶと以後その発行元では確認されません。15 社内CA運用ではあわせて発行元証明書を各端末の「信頼された発行元」に配布しておくと、この確認を運用から消せます。
6. 実務の定石(判断表) ── 「Bypassで蓋」から署名運用まで
社内スクリプトの配布・実行の統制は、次の判断表で考えるのが定石です。
| 論点 | 選択肢 | 判断の目安 |
|---|---|---|
| 環境側のポリシー | Restrictedのまま / RemoteSigned / AllSigned | 自動化を進めるならRemoteSignedが下限。署名体制があるならAllSigned1 |
| 設定の配布 | 各自でSet-ExecutionPolicy / グループポリシー | ドメイン環境ならGPO一択。全スコープに優先し、勝手な変更も封じられる1 |
| 配布物の信頼 | 無署名+共有内配置 / コード署名 | 無署名運用は改変を検知できない。定期実行される運用スクリプトから順に署名へ |
| 証明書 | 自己署名 / 社内CA / 商用CA | 社内配布は社内CA。自己署名はテスト限定、社外配布は商用CA5 |
| ダウンロード物の扱い | ポリシーを緩める / レビューしてUnblock-File | ポリシーは触らず、確認済みファイルだけ通す4 |
| 定期タスクの起動 | -ExecutionPolicy Bypass を常用 / 環境ポリシー整備+署名 |
Bypass常用は安全装置の放棄。GPO管理下ではそもそも効かない1 |
最後の行を補足します。「ExecutionPolicy Bypassで蓋をする」運用の問題は、セキュリティホールを開けることそのものではありません(実行ポリシーはもともと境界ではないので)。問題は次の3点です。
- 安全装置の放棄 ── うっかり別のスクリプトを実行する事故、改変されたスクリプトに気づかず実行する事故を防ぐ最後の網を、恒久的に外すことになります。
- 統制との乖離 ── GPOで実行ポリシーを管理し始めた瞬間、Bypass指定は効かなくなり、蓋をしていたタスクが一斉に失敗します。1「動いていた理由」が管理外の抜け道だった、という技術的負債です。
- 原因調査の攪乱 ── Bypassが散在すると、環境の実効ポリシーから動作を推測できなくなり、端末ごとの差異調査(なぜこの端末だけ失敗するのか)が難航します。
Bypass自体は、PowerShellを組み込んだアプリケーションが独自のセキュリティモデルで統制している構成のために用意された設定です。1 人が書いた運用スクリプトの起動オプションに常用するものではない、と割り切ってください。タスクスケジューラでの安全な定期実行の組み立ては「タスクスケジューラのタスクが実行されない・0x1で終わる ── 原因の切り分けと安全な運用設計」で詳しく扱っています。
7. まとめ
- 実行ポリシーはセキュリティ境界ではなく安全装置です。攻撃対策は別レイヤーで行い、実行ポリシーには「うっかり事故の防止」を担わせます。
- ポリシーは5つのスコープを持ち、MachinePolicy > UserPolicy > Process > CurrentUser > LocalMachine の順に優先されます。切り分けは
Get-ExecutionPolicy -Listから始めます。 - RemoteSignedが見ているのはZone.Identifier(Mark of the Web)です。確認済みのファイルは
Unblock-Fileで、ポリシーを緩めずに通します。 - 署名は
Set-AuthenticodeSignatureで行い、-TimestampServerを必ず指定します。証明書は社内配布なら社内CA発行、自己署名はテスト限定です。 - 組織統制はグループポリシーの「スクリプトの実行を有効にする」で一元化します。この設定はすべてのスコープと
-ExecutionPolicy指定に優先します。 -ExecutionPolicy Bypassの常用は安全装置の放棄であり、GPO管理下では効きません。環境ポリシーの整備と署名運用で「蓋」を不要にするのが正道です。
関連記事
- PowerShellコマンドの基本 ── まず覚える操作と安全な使い方
- Windowsで「Windows によって PC が保護されました」が出る理由
- タスクスケジューラのタスクが実行されない・0x1で終わる ── 原因の切り分けと安全な運用設計
- PowerShellスクリプトのエラー処理と再実行(リトライ)設計
- Windows PowerShell 5.1とPowerShell 7の違いと移行
- バッチファイルからPowerShellへの移行判断
関連する相談領域
合同会社小村ソフトでは、社内PowerShellスクリプトの実行ポリシー・署名運用の設計、グループポリシーによる展開の検討、「特定の端末でだけスクリプトが動かない」といった環境差異の調査を扱っています。既存のバッチ・スクリプト資産を安全な運用に載せ替える支援も可能です。
参考リンク
-
Microsoft Learn, about_Execution_Policies. 実行ポリシーが安全機能でありユーザーを制限するセキュリティシステムではないこと、各ポリシー(AllSigned/Bypass/RemoteSigned/Restricted/Unrestricted等)の定義、5つのスコープと優先順位、Processスコープが$Env:PSExecutionPolicyPreferenceに保存されGPOには勝てないこと、グループポリシー「Turn on Script Execution」が全スコープに優先すること、ダウンロードファイルへの代替データストリーム付加とcurl.exe等では印が付かない場合があること、UNCパスの注意書きについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25
-
Microsoft Learn, Chapter 1 - Getting started with PowerShell. 実行ポリシーがセキュリティ境界ではないこと、Windows 10/11の既定がRestricted、Windows Server 2016/2019/2022の既定がRemoteSignedであること、実行ポリシーがスクリプトにのみ影響し対話的なコマンドは常に実行できることについて。 ↩ ↩2 ↩3
-
Microsoft Learn, Set-ExecutionPolicy. 既定スコープがLocalMachineで管理者権限が必要なこと、MachinePolicy/UserPolicyスコープは変更できないこと、グループポリシーを上書きできず競合時にメッセージが表示されること、Unblock-Fileが実行ポリシーを変更せずスクリプトのブロックを解除する例について。 ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, Unblock-File. Unblock-Fileがインターネットゾーンを示す値3のZone.Identifier代替データストリームを除去すること、エクスプローラーのプロパティの「許可する」ボタンと同じ操作であること、使用前にファイルと入手元の安全性を確認すべきこと、Get-Item -StreamでZone.Identifier付きファイルを検出できることについて。 ↩ ↩2 ↩3 ↩4 ↩5
-
Microsoft Learn, about_Signing. 署名対象のファイル種別、証明機関発行の証明書と自己署名証明書の違い(自己署名はテスト用途限定で他のコンピューターでは実行不可)、署名が# SIG #コメントブロックとして付加されること、PowerShell 7.2より前はASCII/UTF8NoBOM保存が必要だったこと、タイムスタンプサーバーにより証明書の期限後も署名が有効であり続けること、信頼されていない発行元のプロンプトについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12
-
Microsoft Learn, Set-AuthenticodeSignature. Authenticode署名の付与、既存署名の置き換え、-TimestampServerパラメーターにより証明書の期限切れ後もスクリプトが失敗しなくなること、Cert:ドライブの-CodeSigningCertパラメーターで秘密鍵つきコード署名証明書を取得する例について。 ↩ ↩2 ↩3
-
Microsoft Learn, New-SelfSignedCertificate. テスト目的の自己署名証明書を作成するコマンドレットであること、-Typeパラメーターでコード署名証明書を指定できること、有効期間の既定が1年であることについて。 ↩ ↩2 ↩3
-
Microsoft Learn, PowerShell security features. 実行ポリシーがスクリプト実行環境のセキュリティを高める複数の機能の一つとして位置づけられ、悪意あるスクリプトの実行防止を助ける安全機能とされていることについて。 ↩
関連する記事
同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。
PowerShellでの資格情報の安全な扱い ── 平文パスワードをスクリプトから追放する
PowerShellスクリプトに埋め込まれた平文パスワードを安全な保管へ移行する実務手順を整理します。Get-CredentialとPSCredential、SecureStringの実像と限界、Export-ClixmlによるDPAPI保存が同一ユーザー・同一マシン限定で...
PowerShell Remoting(WinRM)入門 ── 複数台のWindowsを一括管理する
PowerShell Remoting(WinRM)で複数台のWindowsを一括管理する入門。仕組みとポート5985/5986、Enable-PSRemotingで起きること、ワークグループのTrustedHosts、Invoke-CommandとPSSession、se...
PowerShellスクリプトの引数設計とモジュール化 ── 「動くスクリプト」から「人に渡せるスクリプト」へ
PowerShellスクリプトを他人に渡せる品質に引き上げる実務手順を整理します。paramブロックと[CmdletBinding()]による高度な関数化、型指定とMandatory、ValidateSetなどの入力検証、パイプライン入力、コメントベースヘルプ、-WhatI...
PowerShellでファイルサーバーを棚卸しする ── 容量調査とアクセス権(ACL)監査
PowerShellでファイルサーバーを棚卸しする実務手順。容量調査とアクセス拒否の記録、古いファイル一覧と重複候補のハッシュ抽出、Get-Aclによる権限監査と継承切れの検出、CSVレポート化、icaclsとの使い分け、Set-Aclの安全な変更手順まで整理します。
Windows PowerShell 5.1とPowerShell 7の違い ── 社内スクリプト移行の実務ガイド
Windows PowerShell 5.1とPowerShell 7の関係(共存・powershell.exeとpwsh.exe)、5.1は新機能追加なしという公式方針、既定エンコーディング差による文字化け、互換機能の制約、#Requiresでの防御、タスクスケジューラ更...
関連トピック
このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。
Windows技術トピック
Windows 開発、不具合調査、既存資産活用の技術トピックをまとめた入口です。
このテーマがつながるサービス
この記事は次のサービスページにつながります。近い入口からご覧ください。
Windowsアプリ開発
業務アプリ、装置連携、通信ツールなどの Windows ソフト開発を支援します。
よくある質問
この記事のテーマについて、相談時によくある質問をまとめています。
- PowerShellの実行ポリシーはセキュリティ機能ですか？
- 公式ドキュメントは「実行ポリシーはユーザーの操作を制限するセキュリティシステムではない」と明言しています。スクリプトの内容をコマンドラインに貼り付ければ簡単に迂回できるためです。実行ポリシーの目的は、基本ルールを決めて「うっかり意図しないスクリプトを実行してしまう」事故を防ぐ安全装置であり、攻撃者を止めるセキュリティ境界として設計を組んではいけません。攻撃対策は別のレイヤー(アプリ制御、権限最小化など)で行います。
- RemoteSignedとAllSignedはどう違いますか？
- RemoteSignedは、インターネット由来(Mark of the Web付き)のスクリプトにのみ信頼された発行元の署名を要求し、ローカルで作成したスクリプトは署名なしで実行できます。AllSignedはローカル作成分も含むすべてのスクリプトと構成ファイルに署名を要求し、未分類の発行元のスクリプトは実行前に確認を求めます。社内で署名運用(コード署名証明書の配布と署名手順)を整備できるならAllSigned、そこまでの体制がないならRemoteSignedが現実的な選択です。
- ダウンロードしたスクリプトが「デジタル署名されていません」と言われて実行できないのはなぜですか？
- ブラウザーなどでダウンロードしたファイルにはZone.Identifierという代替データストリームが付き、「インターネットから来たファイル」として扱われるためです。実行ポリシーがRemoteSignedの場合、この印が付いた未署名スクリプトは実行がブロックされます。内容を確認して安全だと判断できたら、Unblock-Fileコマンドレットかエクスプローラーのプロパティにある「許可する」でZone.Identifierを除去すれば、実行ポリシーを変えずに実行できます。
- 社内配布のPowerShellスクリプトはどう運用するのが現実的ですか？
- 選択肢は大きく2つです。第一はRemoteSigned+ファイルサーバー配置で、署名の仕組みを作らずに始められますが、配布経路によってはMark of the Webが付いて止まることがあり、スクリプトの改変も検知できません。第二はAllSigned+署名運用で、コード署名証明書(社内CA発行が現実的)でSet-AuthenticodeSignatureにより署名し、グループポリシーでポリシーを一元管理します。実行ポリシーの統制と改変検知が効く分、証明書の配布・更新の運用コストがかかります。
- タスクスケジューラで -ExecutionPolicy Bypass を指定し続けてよいですか？
- 動きはしますが推奨しません。まず、グループポリシーで実行ポリシーを管理している環境では、コマンドラインのExecutionPolicy指定はグループポリシーに勝てないため、そもそも効きません。またBypassの常用は「うっかり実行を防ぐ」安全装置を自ら外す運用であり、組織のポリシーと現場の実態が乖離していく原因になります。恒久運用にするなら、グループポリシーか管理者によるSet-ExecutionPolicyで環境側のポリシーを適切に設定し、スクリプト側は署名で信頼を示すのが筋です。
- スクリプト署名にタイムスタンプ(-TimestampServer)はなぜ必要ですか？
- 署名の有効性は原則として署名証明書の有効期限に縛られますが、タイムスタンプがあれば「証明書が有効だった時点で署名された」ことをタイムスタンプサーバーが保証するため、証明書の期限が切れた後もスクリプトを使い続けられます。コード署名証明書の多くは有効期間が1年程度なので、タイムスタンプなしで運用すると毎年「ある日突然、社内の署名済みスクリプトが一斉に動かなくなる」リスクを抱えることになります。署名時には必ず-TimestampServerを指定してください。
著者プロフィール
記事の著者プロフィールページです。
小村 豪
合同会社小村ソフト 代表
Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。
公開リンク