PowerShellスクリプト実行を許可！set-executionpolicy RemoteSigned の設定方法

By /

PowerShellスクリプト実行を許可！set-executionpolicy RemoteSigned の設定方法と詳細解説

はじめに：PowerShellの実行ポリシーとは何か？ なぜ設定が必要なのか？

PowerShellは、Windowsシステムの管理や自動化に非常に強力なツールです。しかし、その強力さゆえに、悪意のあるスクリプトが悪用されるリスクも存在します。例えば、インターネットからダウンロードした未知のスクリプトを実行してしまい、システムが破壊されたり、情報が漏洩したりする可能性があります。

このようなリスクからユーザーを保護するために、PowerShellには「実行ポリシー（Execution Policy）」というセキュリティ機能が備わっています。実行ポリシーは、PowerShellがどの種類のスクリプトを実行することを許可するかを制御する仕組みです。これは、WordやExcelが開こうとするファイルに「インターネットからダウンロードされました。編集を有効にしますか？」といったセキュリティ警告が表示されるのと似た考え方です。

既定の状態では、PowerShellの実行ポリシーは最も制限の厳しい設定になっており、ローカルで作成したスクリプトであっても、そのままで実行することができません。これは、ユーザーが意図しないスクリプト実行を防ぐための安全策ですが、PowerShellを活用してシステム管理やタスク自動化を行いたいユーザーにとっては、この制限が作業の妨げとなります。

そこで必要となるのが、実行ポリシーの設定変更です。PowerShellスクリプトを実行可能にするためには、この実行ポリシーを、ある程度スクリプトの実行を許可する設定に変更する必要があります。

数ある実行ポリシー設定の中でも、特に多くのユーザーや管理者にとって実用的で、セキュリティと利便性のバランスが取れていると推奨されるのが、「RemoteSigned」というポリシーです。

この記事では、PowerShellの実行ポリシーについて、その種類、役割、そして特に「set-executionpolicy RemoteSigned」コマンドレットを用いた設定方法に焦点を当て、その詳細、メリット・デメリット、セキュリティ上の注意点などを徹底的に解説します。約5000語に及ぶ詳細な解説を通じて、PowerShellの実行ポリシーを深く理解し、安全かつ効果的にPowerShellを活用できるようになることを目指します。

PowerShell実行ポリシーの全体像：セキュリティと種類

PowerShellの実行ポリシーは、単にスクリプトを実行できるかできないかだけでなく、どのような条件であれば実行できるかを細かく制御します。このポリシーが存在する最大の理由は、前述の通り、悪意のあるスクリプトによるシステムへの被害を防ぐことです。

PowerShellは、非常に広範なシステム操作を行う能力を持っています。ファイルシステムへのアクセス、レジストリの操作、サービスやプロセスの管理、ネットワーク通信など、システム管理者が行うほとんどのタスクを自動化できます。もし実行ポリシーによる制限がなければ、悪意のあるスクリプト（マルウェアなど）が、ユーザーが知らぬ間にシステム上で実行され、重大な損害を引き起こす可能性があります。

実行ポリシーは、このようなリスクを軽減するための第一線の防御策として機能します。これは、スクリプトの実行を完全に禁止するのではなく、信頼性の基準に基づいて実行の可否を判断する柔軟な仕組みです。

PowerShellには、いくつかの異なる実行ポリシーが用意されており、それぞれスクリプトの実行を許可する範囲や条件が異なります。これらのポリシーを理解することは、自分の環境に最適な設定を選択するために不可欠です。

利用可能な実行ポリシーの種類は以下の通りです（PowerShellのバージョンやOSによってわずかに異なる場合がありますが、主要なものは共通です）。

  1. Restricted (既定の設定)

    • 最も制限の厳しいポリシーです。
    • 個別のPowerShellコマンドは実行できますが、スクリプト (.ps1ファイル) の実行は一切許可されません。
    • コマンドラインで直接入力されたコマンドのみが実行可能です。
    • 既定でこの設定になっているのは、PowerShellに馴染みのないユーザーが誤ってスクリプトを実行してしまうリスクを最小限に抑えるためです。
    • PowerShellを単にコマンドプロンプトの代わりに使うだけで、スクリプトは全く使わないというユーザーには安全な設定です。

  2. AllSigned

    • すべてのスクリプトの実行を許可しますが、すべてのスクリプトに信頼された発行元によるデジタル署名が必要です。
    • ローカルで作成したスクリプトであっても、インターネットからダウンロードしたスクリプトであっても、実行するには有効なデジタル署名が必要です。
    • 署名が有効でない場合や、署名が全くない場合は、スクリプトは実行されません。
    • スクリプトの作成者や配布元が明確であり、その信頼性を保証するためのデジタル署名を徹底できる、非常にセキュリティ意識の高い環境（例：大企業の管理された環境）に適しています。
    • 個人的な利用や小規模な組織では、自作スクリプトにデジタル署名を行う手間がかかるため、あまり一般的ではありません。

  3. RemoteSigned

    • この記事の主題となるポリシーです。
    • ローカルコンピューターで作成またはダウンロードされたスクリプトは、デジタル署名がなくても実行を許可します。
    • インターネットからダウンロードされたスクリプトや、UNCパス（ネットワーク共有フォルダなど）から取得されたスクリプトについては、信頼された発行元によるデジタル署名が必要です。
    • インターネットからダウンロードされたスクリプトで署名がない場合、実行前に警告が表示されるか、実行がブロックされます。ただし、そのスクリプトを「ブロック解除」することで実行可能になります（これについては後述します）。
    • ローカルで自作したスクリプトは自由に実行したいが、インターネット上の未知のスクリプトによるリスクは避けたい、というユーザーにとって、セキュリティと利便性のバランスが取れた現実的なポリシーです。多くのPowerShellユーザーがこのポリシーを選択しています。

  4. Unrestricted

    • 最も制限の緩いポリシーです。
    • すべてのスクリプトの実行を許可します。デジタル署名は必要ありません。
    • インターネットからダウンロードされたスクリプトを実行する場合、実行前に警告が表示されますが、その警告を無視して実行することが可能です。
    • このポリシーは、セキュリティリスクを承知の上で、どのようなスクリプトでも実行したい場合に設定されます。例えば、特定のテスト環境や、完全に信頼できるオフライン環境でのみ使用されるべきです。
    • インターネットに接続された環境でこのポリシーを使用することは、深刻なセキュリティリスクを伴うため、強く推奨されません。

  5. Bypass

    • ポリシーは完全に無視されます。
    • すべてのスクリプトを署名や警告なしに実行します。
    • ユーザーへの通知やブロックは一切行われません。
    • 特定の自動化されたタスクや、スクリプト実行中にユーザーの介入（警告ダイアログなど）を一切排除したい、非常に特殊な状況でのみ使用されます。
    • 実行ポリシーによる保護が全く働かないため、Unrestricted以上に危険な設定と言えます。利用には最大限の注意が必要です。

  6. Undefined

    • 現在のスコープでは実行ポリシーが設定されていない状態を示します。
    • この場合、より上位のスコープで設定されているポリシーが適用されます。
    • すべてのスコープでUndefinedの場合、Restrictedポリシーが適用されます（既定の動作）。

これらのポリシーは、システム上の複数の異なる「スコープ」に対して設定することができます。スコープとは、そのポリシー設定がどこまで影響を及ぼすかを指定するものです。主なスコープは以下の通りです。

  • CurrentUser: 現在ログインしているユーザーのみに適用される設定です。管理者権限なしで変更できます。既定ではこのスコープにはポリシーが設定されていません (Undefined)。
  • LocalMachine: コンピューター上のすべてのユーザーに適用される設定です。変更するには管理者権限が必要です。既定ではこのスコープにRestrictedが設定されています。
  • Process: 現在実行中のPowerShellプロセスのみに適用される設定です。PowerShellウィンドウを閉じると設定は失われます。一時的にポリシーを変更したい場合に便利です。管理者権限は不要です。
  • System Policy: グループポリシーによって設定されるポリシーです。これはLocalMachineやCurrentUserよりも優先されます。エンタープライズ環境で管理者が組織全体のセキュリティポリシーとして実行ポリシーを強制する場合に使用されます。
  • UserName: 特定のユーザーアカウントに対して設定されるポリシーですが、CurrentUserスコープとほぼ同義で扱われることが多いです。

これらのスコープには優先順位があります。ポリシーが複数のスコープで設定されている場合、以下の順序で優先的に適用されます（上にあるものほど優先度が高い）。

  1. Group Policy:Machine (グループポリシーでコンピューターに設定されたポリシー)
  2. Group Policy:User (グループポリシーでユーザーに設定されたポリシー)
  3. ExecutionPolicy:Process (Processスコープで設定されたポリシー)
  4. ExecutionPolicy:CurrentUser (CurrentUserスコープで設定されたポリシー)
  5. ExecutionPolicy:LocalMachine (LocalMachineスコープで設定されたポリシー)

つまり、グループポリシーが設定されている場合はそれが最も強く、Processスコープの設定は一時的ながらCurrentUserやLocalMachineよりも優先されます。何も設定されていなければ、既定のLocalMachine: Restrictedが適用されます。

RemoteSignedポリシーに焦点を当てる

ここまで見てきたように、PowerShellの実行ポリシーには様々な選択肢があります。その中で、なぜRemoteSignedポリシーが多くのユーザーにとって推奨されるのでしょうか？

RemoteSignedポリシーの最大の特徴は、「ローカルで作成したスクリプトは無条件に実行できるが、インターネットなどのリモートから取得したスクリプトは署名が必要」という点です。この特性が、セキュリティと利便性のバランスをもたらします。

  • 利便性: PowerShellを日常的に使用するユーザーは、自分でスクリプトを作成してタスクを自動化することが多いでしょう。RemoteSignedポリシーでは、これらのローカルで作成・編集されたスクリプトは、特別な設定や署名なしにすぐに実行できます。これは、AllSignedのように全てのスクリプトに署名を要求される場合に比べて、圧倒的に手間が省けます。
  • セキュリティ: 一方、インターネットやネットワーク共有といった「ゾーン」からダウンロードされたスクリプトは、信頼できるかどうか不明なソースから来ている可能性があります。RemoteSignedポリシーは、これらのスクリプトに対してデジタル署名を要求することで、少なくともそのスクリプトが誰によって作成・配布されたものかを確認する機会を与え、改ざんされていないことを保証するメカニズムを提供します。署名がない場合や、署名が信頼できない場合は、実行がブロックされるか警告が表示されるため、ユーザーは実行前にリスクを認識できます。

RemoteSignedポリシーのメリット

  • ローカルスクリプトの実行が容易: 自作スクリプトをすぐに実行できるため、PowerShellの学習や日常的なタスク自動化がスムーズに進みます。
  • 外部スクリプトに対する一定の防御: インターネット上の悪意あるスクリプトが、ユーザーの意識しないところで勝手に実行されるリスクを低減します。署名がないリモートスクリプトは実行前にブロックされるか警告されます。
  • セキュリティと利便性のバランス: Restrictedのように何も実行できないわけでもなく、Unrestrictedのように無防備でもありません。多くのユーザーが許容できるセキュリティレベルで、PowerShellの利便性を享受できます。

RemoteSignedポリシーのデメリット

  • 署名されていないリモートスクリプトの実行には手間がかかる: インターネットからダウンロードした便利なスクリプトが署名されていない場合、実行するためには「ブロック解除」という追加の操作が必要になります。
  • デジタル署名がセキュリティを完全に保証するわけではない: 信頼できない発行元が不正なスクリプトに署名する可能性はゼロではありません。署名は「誰が作ったか/改ざんされていないか」を示しますが、「スクリプトの中身が安全か」までは保証しません。常にスクリプトの中身を確認することが重要です。
  • ローカルスクリプトによる攻撃には無防備: もしコンピューター自体がマルウェアに感染し、ローカルに悪意のあるスクリプトを作成された場合、RemoteSignedポリシーはその実行をブロックできません。実行ポリシーは、外部からのスクリプトに対する防御として特に有効です。

どのような状況でRemoteSignedが適しているか

  • 個人的なWindows PCでPowerShellを学習・利用しているユーザー。
  • 小規模なオフィスやチームで、自作スクリプトを共有・実行することが多いが、厳格なデジタル署名運用を行うほどではない環境。
  • システム管理者や開発者で、日常的にスクリプトを記述・テスト・実行する必要があるが、UnrestrictedやBypassのような危険な設定は避けたい場合。

多くの一般的なPowerShellユーザーにとって、RemoteSignedポリシーは最も現実的で推奨される設定と言えます。

set-executionpolicy コマンドレットの詳細な使い方

実行ポリシーを設定または変更するには、set-executionpolicyコマンドレットを使用します。このコマンドレットは、PowerShellセッション内で実行します。

コマンドレットの基本的な構文

powershell
Set-ExecutionPolicy [-ExecutionPolicy] <ExecutionPolicy> [-Scope <ExecutionPolicyScope>] [-Force] [-Confirm] [<CommonParameters>]

主要なパラメーターの説明

  • -ExecutionPolicy (必須)

    • 設定したい実行ポリシーの名前を指定します。
    • 指定できる値は、先ほど説明したポリシー名です: Restricted, AllSigned, RemoteSigned, Unrestricted, Bypass, Undefined。
    • 例: -ExecutionPolicy RemoteSigned

  • -Scope (省略可能)

    • 設定を適用するスコープを指定します。
    • 指定できる値は、先ほど説明したスコープ名です: CurrentUser, LocalMachine, Process, SystemPolicy, UserName。
    • このパラメーターを省略した場合、既定ではLocalMachineスコープに設定しようとします。
    • 注意: LocalMachineスコープを変更するには、管理者権限が必要です。CurrentUserスコープであれば管理者権限なしで設定できます。
    • 例: -Scope CurrentUser

  • -Force (省略可能)

    • 通常、set-executionpolicyコマンドレットを実行すると、設定変更の確認を求めるプロンプトが表示されます。-Forceパラメーターを付けると、この確認プロンプトをスキップし、強制的に設定を変更します。
    • スクリプトの中で実行ポリシーを設定する場合など、対話的な操作ができない状況で便利ですが、意図しない設定変更を防ぐため、手動で実行する際には確認プロンプトをそのまま表示させた方が安全な場合もあります。
    • 例: -Force

  • -Confirm (省略可能)

    • set-executionpolicyコマンドレットは、既定で設定変更の確認プロンプトを表示します。-Confirmパラメーターを付けると、この確認動作を明示的に指定できます。
    • -Confirm:$falseのように指定することで、確認プロンプトを強制的に表示させなくすることもできます（-Forceと同じ効果）。
    • ほとんどの場合、このパラメーターを明示的に指定する必要はありません。

  • (省略可能)

    • PowerShellの多くのコマンドレットで共通して使用できるパラメーターです。例えば、-Verbose（詳細な情報を表示）、-Debug（デバッグ情報を表示）、-ErrorAction（エラー発生時の動作を指定）などがあります。実行ポリシーの設定においては、通常これらのパラメーターは必要ありません。

CurrentUserスコープとLocalMachineスコープの選択

実行ポリシーを設定する際に、どのスコープを選択するかは重要です。

  • CurrentUser:

    • 現在ログインしているユーザーにのみ影響します。
    • 管理者権限は不要です。
    • 個人的なコンピューターや、他のユーザーに影響を与えたくない場合に適しています。
    • 既定ではUndefinedであり、LocalMachineの設定が適用されます。ここに設定すると、LocalMachineの設定よりも優先されます。
    • 多くのホームユーザーや開発者にとって、このスコープへの設定が最も一般的で推奨されます。

  • LocalMachine:

    • そのコンピューターを使用するすべてのユーザーに影響します。
    • 設定するには管理者権限が必要です（PowerShellを「管理者として実行」する必要があります）。
    • コンピューター全体で統一されたセキュリティポリシーを適用したい場合に適しています。
    • 既定ではRestrictedが設定されています。
    • エンタープライズ環境では、通常、グループポリシーまたはこのLocalMachineスコープで実行ポリシーが管理されます。

現在の実行ポリシーを確認する方法

設定を変更する前に、現在の実行ポリシーがどのようになっているかを確認しておくと良いでしょう。これには、Get-ExecutionPolicyコマンドレットを使用します。

powershell
Get-ExecutionPolicy

このコマンドを実行すると、現在有効になっている（優先度の最も高いスコープで設定されている）実行ポリシーが表示されます。

特定のスコープに設定されているポリシーを確認したい場合は、-Scopeパラメーターを使用します。

powershell
Get-ExecutionPolicy -Scope CurrentUser
Get-ExecutionPolicy -Scope LocalMachine
Get-ExecutionPolicy -List # すべてのスコープのポリシーを表示

Get-ExecutionPolicy -Listは、各スコープにどのようなポリシーが設定されているかを一覧表示してくれます。この一覧表示を見れば、どのスコープの設定が現在有効になっているのか（最も優先度が高いもの）が一目でわかります。

set-executionpolicy RemoteSigned の設定方法 (ステップバイステップ)

それでは、実際にset-executionpolicy RemoteSignedを実行して、実行ポリシーを変更する手順を説明します。ここでは、最も一般的で推奨されるCurrentUserスコープに設定する方法を中心に解説します。

ステップ 1: PowerShellを開く

スタートメニューから「PowerShell」を検索して起動します。

  • CurrentUserスコープに設定する場合、通常のPowerShellで構いません。
  • LocalMachineスコープに設定する場合、PowerShellを右クリックし、「管理者として実行」を選択して起動する必要があります。

ステップ 2: 現在の実行ポリシーを確認する (任意)

設定変更前に、念のため現在の設定を確認しておきましょう。

powershell
Get-ExecutionPolicy

通常、既定の状態であればRestrictedと表示されるはずです（LocalMachineスコープの既定値が適用されているため）。

すべてのスコープの設定を確認したい場合は、以下のコマンドを実行します。

powershell
Get-ExecutionPolicy -List

ステップ 3: RemoteSignedポリシーを設定する

設定したいスコープに応じて、以下のコマンドを実行します。

A. CurrentUserスコープにRemoteSignedを設定する (推奨)

これが最も一般的な設定方法です。管理者権限は不要です。

powershell
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

このコマンドを実行すると、以下のような確認メッセージが表示されることがあります。

実行ポリシーの変更
実行ポリシーは、信頼されていないスクリプトからの保護に役立ちます。実行ポリシーを変更すると、セキュリティ上のリスクにさらされることがあります。
about_Execution_Policies のヘルプ トピックで実行ポリシーに関する詳細を確認してください。
よろしいですか?
[Y] はい(Y) [A] 全て続行(A) [N] いいえ(N) [L] 全て無視(L) [S] 中断(S) [?] ヘルプ (既定値は "Y"):

セキュリティ上のリスクを理解した上で変更する場合は、「Y」キーを押してEnterキーを押します。確認メッセージを表示させたくない場合は、コマンドに-Forceパラメーターを追加します（例: Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force）。

B. LocalMachineスコープにRemoteSignedを設定する

この設定はコンピューター上のすべてのユーザーに影響します。実行するには「管理者として実行」したPowerShellが必要です。

powershell
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine

こちらも同様に確認メッセージが表示されるので、「Y」キーを押してEnterキーを押します。管理者権限がないPowerShellでこのコマンドを実行しようとすると、「アクセスが拒否されました」といったエラーが表示されます。

ステップ 4: 設定が反映されたか確認する

設定コマンドがエラーなく完了したら、再度Get-ExecutionPolicyコマンドレットを使って設定が正しく変更されたか確認します。

CurrentUserスコープに設定した場合：

powershell
Get-ExecutionPolicy -Scope CurrentUser # CurrentUserスコープの設定を確認
Get-ExecutionPolicy # 現在有効なポリシーを確認 (CurrentUserが優先されるはず)

Get-ExecutionPolicy -Scope CurrentUserの出力がRemoteSignedになっており、かつGet-ExecutionPolicyの出力もRemoteSignedになっていれば成功です。

LocalMachineスコープに設定した場合：

powershell
Get-ExecutionPolicy -Scope LocalMachine # LocalMachineスコープの設定を確認
Get-ExecutionPolicy # 現在有効なポリシーを確認 (LocalMachineが優先されるはず - ただしCurrentUserやGPが設定されていなければ)

Get-ExecutionPolicy -Scope LocalMachineの出力がRemoteSignedになっていれば成功です。もし他のスコープ（例：CurrentUserやグループポリシー）でポリシーが設定されている場合、Get-ExecutionPolicyの出力はRemoteSignedにならないことがあります。その場合は、Get-ExecutionPolicy -Listで全体の状況を確認してください。

これで、PowerShellスクリプトの実行ポリシーがRemoteSignedに設定され、ローカルで作成したスクリプトを実行できるようになります。

設定を元に戻すには

もし設定を既定のRestrictedに戻したい場合や、特定のスコープの設定を解除したい場合は、再度Set-ExecutionPolicyコマンドレットを使用します。

  • CurrentUserスコープの設定を解除して既定に戻す（LocalMachineの設定が適用されるようになる）：
    powershell
    Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope CurrentUser
  • LocalMachineスコープの設定を既定のRestrictedに戻す（管理者権限が必要）：
    powershell
    Set-ExecutionPolicy -ExecutionPolicy Restricted -Scope LocalMachine

RemoteSignedポリシー下でのスクリプト実行

RemoteSignedポリシーが設定された環境では、スクリプトがどのように扱われるのでしょうか。具体例を挙げて説明します。

1. ローカルで作成・編集したスクリプトの実行

メモ帳などのテキストエディタやPowerShell ISEなどで自分で作成し、ローカルコンピューター上に保存した.ps1ファイルは、デジタル署名がなくても実行できます。

例: C:\Scripts\MyScript.ps1 というファイルを作成したとします。
“`powershell

MyScript.ps1

Write-Host “これはローカルスクリプトです！”
Get-Date
このスクリプトは、特に何の問題もなく実行できます。powershell
C:\Scripts\MyScript.ps1
またはpowershell
.\MyScript.ps1 # カレントディレクトリにある場合
“`

2. インターネットからダウンロードしたスクリプトの実行

Webブラウザを使ってインターネット上のウェブサイトからダウンロードしたスクリプトファイル（例: DownloadScript.ps1）は、そのファイルに「ゾーン識別子（Zone Identifier）」という情報が付与されます。この識別子は、ファイルがインターネットゾーンから来たことを示します。

RemoteSignedポリシーでは、インターネットゾーンから来たスクリプトは、信頼された発行元によるデジタル署名が必要です。

  • 署名付きのリモートスクリプト:
    もしダウンロードしたスクリプトに有効なデジタル署名が付いている場合、PowerShellはその署名を確認します。署名が有効で、発行元が信頼できる場合、スクリプトは実行されます。PowerShellは署名情報や発行元に関する情報を表示することがあります。

  • 署名なしのリモートスクリプト:
    ダウンロードしたスクリプトにデジタル署名がない、または署名が無効な場合、RemoteSignedポリシーでは既定でそのスクリプトの実行がブロックされます。以下のようなエラーメッセージが表示されることがあります。

    .\DownloadScript.ps1 : ファイル C:\Users\YourUser\Downloads\DownloadScript.ps1 はデジタル署名されていないため、このシステムでは実行できません。このスクリプトを実行する前に、信頼された発行元から署名されていることを確認してください。
    場所 行:1 文字:1
    + .\DownloadScript.ps1
    + ~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [.\DownloadScript.ps1], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess,DownloadScript.ps1

    これは、RemoteSignedポリシーが意図通りに機能している証拠です。未知のスクリプトが勝手に実行されるのを防いでいます。

署名なしのリモートスクリプトを実行したい場合（ブロック解除）

インターネットからダウンロードしたスクリプトの中には、有用であってもデジタル署名が付いていないものが多数あります。スクリプトの内容を自分で確認して安全だと判断した場合、これを実行可能にするには、ファイルに付与された「ゾーン識別子」を解除する必要があります。

ゾーン識別子を解除するには、いくつかの方法があります。

  • エクスプローラーを使用する方法:

    1. ダウンロードしたスクリプトファイルを右クリックします。
    2. 「プロパティ」を選択します。
    3. プロパティウィンドウの下部にある「全般」タブに、「セキュリティ」セクションが表示されている場合があります。（表示されない場合は、そのファイルにはゾーン識別子が付与されていません。）
    4. 「セキュリティ」セクションの「ブロックの解除」チェックボックスをオンにします。
    5. 「適用」または「OK」をクリックします。

    これで、ファイルからゾーン識別子が削除され、ローカルで作成されたスクリプトと同様に扱われるようになります。

  • PowerShellのUnblock-Fileコマンドレットを使用する方法:
    ファイルを一つずつ手動で解除するのが面倒な場合や、スクリプトで解除処理を自動化したい場合は、Unblock-Fileコマンドレットを使用できます。

    powershell
    Unblock-File -Path C:\Users\YourUser\Downloads\DownloadScript.ps1

    または、複数のファイルをまとめて解除することも可能です。

    powershell
    Get-ChildItem C:\Users\YourUser\Downloads\*.ps1 | Unblock-File

    Unblock-Fileコマンドレットは、指定したファイルのゾーン識別子を削除する働きをします。この操作を行えば、RemoteSignedポリシー下でも署名なしのリモートスクリプトが実行可能になります。

    重要な注意点: Unblock-Fileはセキュリティ警告を解除する強力なコマンドです。実行するスクリプトの内容を十分に信頼できる場合にのみ使用してください。安易に実行すると、悪意のあるスクリプトを実行してしまうリスクがあります。

セキュリティに関する考慮事項とベストプラクティス

RemoteSignedポリシーは、多くのユーザーにとって実用的でバランスの取れた選択肢ですが、セキュリティ上のリスクを完全に排除するものではありません。PowerShellを安全に利用するためには、以下の点を理解し、ベストプラクティスに従うことが重要です。

  1. 実行ポリシーはセキュリティ境界ではない:
    実行ポリシーは、PowerShellスクリプトの実行を制御する「 gatekeeper （門番）」のような役割を果たしますが、それ自体が完全なセキュリティソリューションではありません。これは、ユーザーが意図しないスクリプトを実行してしまうのを防ぐための層の一つに過ぎません。
    例えば、以下のような方法で実行ポリシーを回避することも技術的には可能です（悪用厳禁）：

    • スクリプトファイルとして保存せず、コマンドをPowerShellコンソールに直接コピー＆ペーストして実行する。
    • 他のプログラム（例: cmd.exe）からPowerShellを実行し、-ExecutionPolicy Bypassパラメーターを付けてPowerShellを起動する。
    • スクリプトの内容をエンコードしたり、複数の短いコマンドに分割したりして、PowerShellがスクリプトとして認識しないようにする。

    したがって、実行ポリシーを設定したからといって安心してはいけません。システム全体のセキュリティ対策（マルウェア対策ソフト、ファイアウォール、OSやソフトウェアの定期的なアップデート、強力なパスワードの使用など）と組み合わせて運用することが不可欠です。

  2. 信頼できないソースからのスクリプトは実行しない:
    インターネットや見知らぬ人から提供されたスクリプトは、たとえRemoteSignedポリシーが設定されていても、安易に実行すべきではありません。実行前に必ずスクリプトの中身を確認し、何を行うものなのかを理解してください。特に、ウェブサイトやフォーラムで見つけたスクリプトをコピー＆ペーストして実行する場合、実行ポリシーによる保護は働きません。

  3. 署名なしのリモートスクリプト実行のリスク:
    RemoteSignedポリシー下で署名なしのリモートスクリプトを実行するには、「ブロック解除」が必要です。この操作は、システムが発している「このファイルはインターネットから来たもので、注意が必要です」という警告を明示的に無視することを意味します。そのスクリプトを完全に信頼できる場合にのみ、ブロック解除を行ってください。

  4. 最小権限の原則を適用する:
    PowerShellスクリプトを実行するユーザーアカウントには、そのタスクを遂行するために必要最小限の権限のみを与えるようにします。例えば、システム全体に影響を与えるスクリプトを日常的に実行しないユーザーは、管理者権限を持たない通常のアカウントを使用すべきです。これにより、たとえ悪意のあるスクリプトが実行されてしまっても、その被害範囲を限定できます。

  5. グループポリシーによる実行ポリシー管理 (エンタープライズ環境向け):
    企業などの管理された環境では、個々のユーザーが自由に実行ポリシーを変更できてしまうと、セキュリティホールとなり得ます。このような環境では、Active Directoryのグループポリシーを使用して、組織全体のPowerShell実行ポリシーを強制的に設定・管理することが推奨されます。グループポリシーで設定されたポリシーは、ローカルのset-executionpolicyコマンドレットによる設定よりも優先されます。これにより、ユーザーはポリシーを変更できなくなり、管理者はセキュリティ基準を維持できます。

  6. PowerShellの学習と理解:
    PowerShellスクリプトは、その内容を理解していれば安全性を判断しやすくなります。PowerShellの基本的なコマンドや構文を学ぶことは、単にスクリプトを実行するだけでなく、スクリプトの中身を読み解く力を養う上で非常に役立ちます。

トラブルシューティング：設定変更やスクリプト実行がうまくいかない場合

set-executionpolicy RemoteSignedを設定しようとしたり、設定後にスクリプトを実行しようとしたりして、問題が発生する場合があります。よくある原因と対処法を説明します。

1. set-executionpolicy コマンドの実行時にエラーが表示される

  • 「アクセスが拒否されました」エラー:
    これは、LocalMachineスコープに設定しようとしているのに、PowerShellを管理者として実行していない場合に発生します。LocalMachineスコープの設定変更には管理者権限が必要です。PowerShellを右クリックし、「管理者として実行」を選択して再度コマンドを実行してください。CurrentUserスコープに設定する場合は管理者権限は不要です。

  • 「実行ポリシーを設定できませんでした。PolicyOverride レジストリ キーまたは PolicyMachine レジストリ キーで定義されたポリシーが、指定したポリシーよりも優先されます。」エラー:
    これは、グループポリシー（System Policyスコープ）によって実行ポリシーが設定されており、ローカルでの変更が許可されていない場合に発生します。グループポリシーによる設定は、LocalMachineやCurrentUserの設定よりも優先されます。
    この場合、ローカルでset-executionpolicyコマンドを実行しても、設定は反映されません。組織のシステム管理者に問い合わせて、グループポリシーの設定を変更してもらう必要があります。
    Get-ExecutionPolicy -Listコマンドを実行して、SystemPolicyの項目が設定されているか確認してください。

2. RemoteSignedに設定したはずなのにスクリプトが実行できない

  • PowerShellを再起動していない:
    設定変更後、新しいポリシーを反映させるために、PowerShellウィンドウを一度閉じてから再度開く必要がある場合があります。

  • 別のスコープで、より優先度の高いポリシーが設定されている:
    set-executionpolicy RemoteSigned -Scope CurrentUserで設定した場合でも、もしLocalMachineスコープがRestrictedのままで、かつグループポリシーも設定されていない場合、ユーザーログオン時にLocalMachineのRestrictedが先に読み込まれてしまうなど、予期しない挙動をすることがあります。
    また、グループポリシーでRestrictedが設定されている場合は、CurrentUserやLocalMachineでの変更は無視されます。
    Get-ExecutionPolicy -Listコマンドを実行して、すべてのスコープのポリシーを確認し、現在有効になっているポリシーが何であるかを特定してください。優先順位の高いスコープでRestrictedやAllSignedなどが設定されている可能性があります。

  • 実行しようとしているスクリプトがインターネットからダウンロードしたもので、署名がない:
    RemoteSignedポリシーでは、インターネットからダウンロードした署名なしのスクリプトは実行できません。前述の「ブロック解除」の手順を実行してください。

  • スクリプトファイルが見つからない、またはパスが間違っている:
    PowerShellは、既定ではカレントディレクトリにある実行可能ファイル（.ps1ファイルを含む）を、完全なパスまたは.\を付けずに実行することは許可していません（これもセキュリティ対策の一つです）。
    スクリプトを実行するには、フルパス（例: C:\Scripts\MyScript.ps1）を指定するか、カレントディレクトリにある場合はパスの先頭に.\（例: .\MyScript.ps1）を付けて実行する必要があります。
    もしスクリプトファイルが見つからない、または指定したパスが間違っている場合は、「ファイルが見つかりません」といったエラーになります。Get-ChildItemコマンドなどでファイルが存在するか確認してください。

3. スクリプトの実行時に署名の警告やエラーが表示される

  • リモートスクリプトに署名が付いているが、発行元が信頼されていない:
    RemoteSignedポリシーでは、インターネットからダウンロードしたスクリプトは「信頼された発行元」による署名が必要です。署名が付いていても、その発行元がWindowsによって信頼されていない場合、警告が表示されるか実行がブロックされます。
    発行元を信頼する場合は、警告が表示された際にその発行元を信頼リストに追加する選択肢が表示されることがあります。または、セキュリティ証明書をインポートして信頼リストに追加することも可能です。

  • スクリプトが改ざんされている、または署名が無効:
    デジタル署名は、スクリプトが署名後に改ざんされていないことを保証します。もしスクリプトが改ざんされた場合、署名が無効になり、PowerShellは実行をブロックします。これはセキュリティ機能が正常に働いている状態です。スクリプトを配布元から再ダウンロードするなどして、改ざんされていないオリジナルを入手してください。

よくある質問 (FAQ)

Q1: RemoteSignedとUnrestrictedの違いは何ですか？

A1: RemoteSignedは、インターネットからダウンロードしたスクリプトにはデジタル署名を要求します（署名がない場合はブロックまたは警告、ブロック解除が必要）。一方、Unrestrictedは、インターネットからダウンロードしたスクリプトでも、署名がなくても警告付きで実行を許可します（警告を無視して実行可能）。UnrestrictedはRemoteSignedよりもはるかにセキュリティリスクが高い設定です。

Q2: どのスコープに設定すべきですか？

A2: 個人のコンピューターで自分自身のために設定を変更する場合や、他のユーザーに影響を与えたくない場合は、CurrentUserスコープに設定するのが最も推奨されます。これは管理者権限も不要です。組織内の複数のユーザーに対して一律にポリシーを設定したい場合は、管理者としてLocalMachineスコープに設定するか、グループポリシーを使用します。一時的に特定のスクリプトを実行したいだけであれば、Processスコープを使用するのも一つの方法です。

Q3: set-executionpolicy で設定したポリシーは元に戻せますか？

A3: はい、元に戻せます。特定のスコープに設定したポリシーを解除して、そのスコープをUndefinedの状態に戻すには、Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope <スコープ名>コマンドを使用します。例えば、CurrentUserスコープの設定を解除するには Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope CurrentUser を実行します。LocalMachineスコープの設定を既定のRestrictedに戻すには、管理者として Set-ExecutionPolicy -ExecutionPolicy Restricted -Scope LocalMachine を実行します。

Q4: なぜ既定の実行ポリシーはRestrictedなのですか？

A4: 既定のRestrictedポリシーは、最も安全な設定であり、意図しないスクリプト実行によるシステムへの被害を防ぐための初期防御です。PowerShellに不慣れなユーザーが、インターネット上の悪意のあるスクリプトなどを誤って実行してしまうリスクを最小限に抑える目的で、既定でスクリプト実行がブロックされるようになっています。PowerShellスクリプトを実行したいユーザーは、意図的にポリシーを変更する必要があります。

Q5: グループポリシーで実行ポリシーが設定されている場合、set-executionpolicyで変更できますか？

A5: いいえ、できません。グループポリシー（System Policyスコープ）で設定された実行ポリシーは、LocalMachineやCurrentUserスコープで設定されたローカルポリシーよりも優先されます。グループポリシーによって実行ポリシーが設定されている場合、set-executionpolicyコマンドレットを使ってローカルでポリシーを変更しようとしても、エラーが表示されるか、変更できても実際にはグループポリシーの設定が適用され続けます。この場合、グループポリシーの設定を変更する必要があります。これは通常、組織のActive Directory管理者のみが行えます。

まとめ：安全かつ効果的なPowerShell活用のために

この記事では、PowerShellの実行ポリシー、特にRemoteSignedポリシーに焦点を当て、その詳細、設定方法、そしてセキュリティ上の注意点について詳しく解説しました。

PowerShell実行ポリシーは、PowerShellを安全に利用するための重要なセキュリティ機能です。既定のRestrictedポリシーは安全ですが、スクリプト実行を完全にブロックするため、PowerShellの真価を発揮できません。多くのユーザーにとって、RemoteSignedポリシーは、ローカルスクリプトの利便性を享受しつつ、インターネット上の未知のスクリプトによるリスクを軽減できる、実用的なバランスの取れた設定です。

set-executionpolicy RemoteSignedコマンドレットを使用することで、このポリシーを簡単に設定できます。特に、管理者権限なしで設定できるCurrentUserスコープへの設定は、個人のコンピューターでの利用に最適です。

しかし、実行ポリシーは万能のセキュリティ対策ではありません。RemoteSignedポリシーを設定した場合でも、以下を常に意識することが重要です。

  • インターネットからダウンロードしたスクリプトは、実行前に信頼性を確認し、必要であれば「ブロック解除」を自己責任で行う。
  • 安易にUnrestrictedやBypassのような危険なポリシーは使用しない。
  • 実行ポリシーだけでなく、他のシステムセキュリティ対策（マルウェア対策、最小権限など）と組み合わせて運用する。
  • 不明なスクリプトの中身は必ず確認する。

PowerShellは非常に強力なツールであり、システム管理やタスク自動化に計り知れないメリットをもたらします。この記事が、読者の皆様がPowerShellの実行ポリシーを正しく理解し、RemoteSignedポリシーを適切に設定することで、安全かつ効果的にPowerShellを活用するための一助となれば幸いです。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール