次の方法で共有


Windows PowerShell Web アクセスの認可ルールとセキュリティ機能

更新日:2013年6月24日

対象:Windows Server 2012 R2、Windows Server 2012

Windows Server 2012 R2およびWindows Server 2012におけるWindows PowerShell Web Accessは、制限的なセキュリティモデルを持っています。 ユーザーはWindows PowerShell Web Accessゲートウェイにサインインし、ウェブベースのWindows PowerShellコンソールを使用する前に、明示的にアクセス権が付与されなければなりません。

認可ルールとサイトセキュリティの設定

Windows PowerShell Web Accessがインストールされ、ゲートウェイが設定された後、ユーザーはブラウザでサインインページを開くことができますが、Windows PowerShell Web Access管理者が明示的にアクセスを許可するまでサインインできません。 「Windows PowerShell Web Access」アクセス制御は、以下の表に説明されているWindows PowerShellコマンドレットのセットを用いて管理されます。 認可ルールの追加や管理のための同等のGUIは存在しません。 Windows PowerShell Web Access Cmdletを参照してください。

管理者はWindows PowerShell Web Accessの認証ルール {0-n} 定義できます。 デフォルトの担保は許容的ではなく制限的です。認証ルールがゼロで、ユーザーは何もアクセスできません。

Windows Server 2012 R2のAdd-PswaAuthorizationRuleおよびTest-PswaAuthorizationRuleには、リモートコンピュータやアクティブなWindows PowerShell Web Accessセッション内からWindows PowerShell Web Access認可ルールを追加・テストできるCredentialパラメータが含まれています。 他のWindowsのPowerShellコマンドレットでCredentialパラメータを持つ場合と同様に、パラメータの値としてPSCredential objectを指定することができます。 リモートコンピュータに渡したい認証情報を含むPSCredential objectを作成するには、 Get-Credential コマンドレットを実行します。

Windows PowerShellのWeb Access認証ルールは 許可 ルールです。 各ルールは、ユーザー、ターゲットコンピュータ、特定のWindows PowerShell セッション構成 (エンドポイントや ランスペースとも呼ばれる)との間で許可される接続の定義です。 ランスペースの説明については「PowerShell Runspacesの初期使用」を参照してください

Important

ユーザーはアクセスを得るために、たった一つのルールが真であるだけで十分です。 ユーザーがウェブベースのコンソールから、完全な言語アクセス権を持つか、Windows PowerShellのリモート管理コマンドレットのみにアクセスできる1台のコンピュータにアクセス権を与えた場合、最初のターゲットコンピュータに接続された他のコンピュータにログイン(またはホップ)できます。 Windows PowerShell Web Accessを最も安全に設定する方法は、ユーザーが通常リモートで行う必要がある特定のタスクを実行できる制約付きセッション構成のみにアクセスできるようにすることです。

Windows PowerShell Web Access Cmdlets で参照されているコマンドレットは、Windows PowerShell Web Access ゲートウェイ上でユーザーを承認するためのアクセスルールのセットを作成することを可能にします。 これらのルールは宛先コンピュータのアクセス制御リスト(ACL)とは異なり、ウェブアクセスに追加のセキュリティ層を提供します。 セキュリティに関する詳細は以下のセクションで説明します。

ユーザーが前のセキュリティ層のいずれかを通過できない場合、ブラウザのウィンドウに一般的な「アクセス拒否」メッセージが表示されます。 セキュリティの詳細はゲートウェイサーバーに記録されますが、エンドユーザーには、通過したセキュリティ層の数や、サインインや認証失敗が発生した層の情報は表示されません。

認可ルールの設定についての詳細は、このトピックの認可 ルールの設定 を参照してください。

セキュリティ

Windows PowerShellのWeb Accessセキュリティモデルは、ウェブベースのコンソールのエンドユーザーとターゲットコンピュータの間に4つの層があります。 Windows PowerShell Web Access管理者は、IISマネージャーコンソールで追加設定を通じてセキュリティ層を追加できます。 IISマネージャーコンソールでのウェブサイトのセキュリティに関する詳細は、「 Web Server Security (IIS7)の設定」をご覧ください。

IISのベストプラクティスやサービス拒否攻撃の防止については、「 DoS/サービス拒否攻撃の防止ベストプラクティス」をご覧ください。 管理者は追加の小売認証ソフトウェアを購入・インストールすることもできます。

以下の表は、エンドユーザーとターゲットコンピュータ間の4つのセキュリティ層について説明します。

レベル レイヤー
1 IISウェブサーバーのセキュリティ機能
2 Windows PowerShell Web Access Formsベースのゲートウェイ認証
3 Windows PowerShell ウェブアクセス認可ルール
4 ターゲット認証および認可ルール

各層の詳細情報は以下の見出しでご覧いただけます。

IISウェブサーバーのセキュリティ機能

Windows PowerShell Web Accessのユーザーは、ゲートウェイ上でアカウントを認証するために必ずユーザー名とパスワードを提供しなければなりません。 ただし、Windows PowerShellのWeb Access管理者は、オプションのクライアント証明書認証のオン・オフも可能です。詳細は「 Windows PowerShell Web Accessのインストールと使用 によるテスト証明書の有効化」や、後には正規の証明書の設定方法を参照してください。

オプションのクライアント証明書機能は、エンドユーザーがユーザー名やパスワードに加えて有効なクライアント証明書を持つことを必要とし、Web Server(IIS)設定の一部です。 クライアント証明書レイヤーが有効になると、Windows PowerShell Web Accessのサインインページがユーザーに有効な証明書の提供を求め、その後にサインイン認証が評価されます。 クライアント証明書認証は自動的にクライアント証明書の有無を確認します。 有効な証明書が見つからない場合、Windows PowerShell Web Accessはユーザーに通知し、証明書を提供できるようにします。 有効なクライアント証明書が見つかると、Windows PowerShell Web Accessはサインインページを開き、ユーザーがユーザー名とパスワードを入力できるようにします。

これはIIS Web Serverが提供する追加のセキュリティ設定の一例です。 その他のIISセキュリティ機能の詳細については、「 Web Server Security (IIS 7)の設定」をご覧ください。

Windows PowerShell Web Access フォームベースのゲートウェイ認証

Windows PowerShell Web Accessのサインインページは、ユーザー名とパスワードの認証情報セットを必要とし、ターゲットコンピュータごとに異なる認証情報を指定するオプションがユーザーに提供されます。 ユーザーが代替認証情報を提供しない場合、ゲートウェイに接続するために使われるプライマリユーザー名とパスワードも対象コンピュータに接続に使われます。

必要な認証情報はWindows PowerShellのWeb Accessゲートウェイ上で認証されます。 これらの認証情報は、ローカルのWindows PowerShell Web Accessゲートウェイサーバー上、またはActive Directory上の有効なユーザーアカウントでなければなりません。

Windows PowerShell Web Access 認可ルール

ユーザーがゲートウェイで認証された後、Windows PowerShell Web Accessは認可ルールをチェックし、ユーザーが要求されたターゲットコンピュータへのアクセス権を持っているかを確認します。 認証が成功すると、ユーザーの認証情報がターゲットコンピュータに渡されます。

これらのルールは、ユーザーがゲートウェイによって認証された後、かつターゲットコンピュータで認証される前に評価されます。

ターゲット認証および認可ルール

Windows PowerShell Web Accessの最終的なセキュリティ層は、ターゲットコンピュータ自身のセキュリティ設定です。 ユーザーは、Windows PowerShell Web Accessを通じてターゲットコンピュータに影響を与えるWindows PowerShell Webベースのコンソールを実行するために、ターゲットコンピュータおよびWindows PowerShell Web Access認可ルールで適切なアクセス権を設定する必要があります。

このレイヤーは、ユーザーが Enter-PSSession または New-PSSession コマンドレットを実行して、Windows PowerShell内からターゲットコンピュータへのリモートWindowsのPowerShellセッションを作成しようとした場合の接続試行を評価するのと同じセキュリティメカニズムを提供します。

デフォルトでは、Windows PowerShell Web Accessはゲートウェイとターゲットコンピュータの両方で認証にプライマリユーザー名とパスワードを使用します。 ウェブベースのサインインページには「 オプション接続設定」というセクションがあり、必要に応じてターゲットコンピュータごとに異なる認証情報を設定できるオプションが提供されています。 ユーザーが代替認証情報を提供しない場合、ゲートウェイに接続するために使われるプライマリユーザー名とパスワードも対象コンピュータに接続に使われます。

認証ルールは、特定のセッション構成へのアクセスをユーザーに許可するために使用できます。 Windows PowerShell Web Accessに対して 制限されたランスペース やセッション構成を作成し、特定のユーザーがWindows PowerShell Web Accessにサインインする際に特定のセッション構成のみに接続できるようにできます。 アクセス制御リスト(ACL)を使って、どのユーザーが特定のエンドポイントにアクセスできるかを判別し、この節で説明する認可ルールを使って特定のユーザー群のエンドポイントへのアクセスをさらに制限することができます。 制限付きランスペースの詳細については、「 制約済みランスペースの作成」を参照してください。

認可ルールの設定

管理者は、Windows PowerShell Web Accessユーザーに対して、Windows PowerShellリモート管理用にすでに定義されているのと同じ認証ルールを望むことが多いです。 このセクションの最初の手順は、1つのユーザーにアクセスを許可し、1台のコンピュータを管理するサインインを行い、単一のセッション構成内で安全な認可ルールを追加する方法を説明しています。 2つ目の手順は、不要になった認可ルールを削除する方法を説明しています。

Windows PowerShell Web Accessで特定のユーザーが制限されたランスペース内でのみ作業できるようにカスタムセッション構成を使用する予定がある場合は、それを参照する認可ルールを追加する前に、まずカスタムセッション構成を作成してください。 Windows PowerShellのWeb Accessコマンドレットを使ってカスタムセッション構成を作成することはできません。 カスタムセッション構成の作成についての詳細は、 about_Session_Configuration_Filesを参照してください。

Windows PowerShell Web Access cmdlets は、1つのワイルドカード文字(アスタリスク * )をサポートしています。 文字列内のワイルドカード文字はサポートされていません。プロパティ(ユーザー、コンピュータ、セッション構成)ごとに1つのアスタリスクを使いましょう。

認証ルールを使ってユーザーにアクセスを付与し、Windows PowerShell Web Access環境のセキュリティを強化するためのさらなる方法については、このトピックの 他の認可ルールシナリオの例 をご覧ください。

制限的認可ルールを追加する

  1. 次のいずれかを実行して、管理者特権を使って Windows PowerShell セッションを開きます。

    • Windows デスクトップで、タスク バーの [Windows PowerShell] を右クリックし、[管理者として実行] をクリックします。

    • Windows のスタート 画面で、 Windows PowerShellを右クリックしてから 「管理者として実行」をクリックします。

  2. 任意のステップ セッション構成を使ってユーザーアクセスを制限する場合:

    使いたいセッション構成がすでにルールに存在しているか確認してください。

    まだ作成されていない場合は、 about_Session_Configuration_Filesでセッション構成を作成するための指示を使いましょう。

  3. この権限ルールにより、特定のユーザーは通常アクセス可能なネットワーク上の1台のコンピュータにアクセスし、その人の典型的なスクリプトやコマンドレットのニーズに合わせた特定のセッション構成にアクセスできます。 次のように入力し、 Enter キーを押します。

    Add-PswaAuthorizationRule -UserName <domain\user | computer\user> `
       -ComputerName <computer_name> -ConfigurationName <session_configuration_name>
    
    • 以下の例では、Contosoドメイン内のJSmithという名前のユーザーがコンピュータContoso_214の管理権限を与えられ、NewAdminsOnlyというセッション構成を使用します。
    Add-PswaAuthorizationRule -UserName 'Contoso\JSmith' `
       -ComputerName Contoso_214 -ConfigurationName NewAdminsOnly
    
  4. Get-PswaAuthorizationRuleコマンドレットを実行するか、Test-PswaAuthorizationRule -UserName <domain\user | computer\user> -ComputerName** <computer_name>を実行してルールが作成されたか確認してください。 たとえば、「 Test-PswaAuthorizationRule -UserName Contoso\\JSmith -ComputerName Contoso_214 」のように入力します。

承認ルールを削除する

  1. WindowsPowerShellセッションがまだ開かれていない場合は、このセクションで 制限的認可ルールを追加する ステップ1を参照してください。

  2. 以下を入力してから Enterキーを押してください。 ここでルールID は削除したいルールのユニークなID番号を表します。

    Remove-PswaAuthorizationRule -ID <rule ID>
    

    あるいは、ID番号がわからず、削除したいルールのフレンドリーネームが分かっている場合は、ルール名を取得し、 Remove-PswaAuthorizationRule コマンドレットにパイプしてルールを削除することもできます。以下の例に示されています。

    Get-PswaAuthorizationRule `
       -RuleName <rule-name> | Remove-PswaAuthorizationRule
    

指定された認可ルールを削除するか確認するよう促されることはありません。 Enterキーを押すとルールは削除されます。 Remove-PswaAuthorizationRuleコマンドレットを実行する前に、必ず認証ルールを削除してください。

その他の認可ルールシナリオの例

すべてのWindowsPowerShellセッションはセッション構成を使用します。セッションごとに指定されていない場合、Windows PowerShellはMicrosoft.PowerShellと呼ばれるデフォルトの組み込みWindows PowerShellセッション構成を使用します。 デフォルトのセッション構成には、コンピュータ上で利用可能なすべてのコマンドレットが含まれます。 管理者は、エンドユーザーが実行できる限られたコマンドレットやタスクの範囲を持つセッション構成を定義することで、すべてのコンピュータへのアクセスを制限できます。 1台のコンピュータに完全な言語アクセス権を持つか、Windows PowerShellリモート管理コマンドレットのみを持つユーザーも、最初のコンピュータに接続された他のコンピュータに接続できます。 制限されたランスペースを定義することで、ユーザーが許可されたWindows PowerShellランスペースから他のコンピュータにアクセスするのを防ぎ、Windows PowerShell Web Access環境のセキュリティを向上させます。 セッション構成は、管理者がWindows PowerShell Web Accessを通じてアクセスしたいすべてのコンピュータにグループポリシーを用いて配布できます。 セッション構成の詳細については、「about_Session_Configurations」を参照してください。 以下はこのシナリオのいくつかの例です。

  • 管理者は PswaEndpointというエンドポイントを作成し、ランスペースが制限されています。 その後、管理者はルールを作成し、 *,*,PswaEndpointし、エンドポイントを他のコンピュータに配布します。 このルールにより、すべてのユーザーは PswaEndpointというエンドポイントを持つすべてのコンピュータにアクセスできます。 もしこれがルールセットで定義された唯一の認可ルールであれば、そのエンドポイントを持たないコンピュータはアクセスできません。

  • 管理者は PswaEndpointという制限されたランスペースを持つエンドポイントを作成し、特定のユーザーへのアクセスを制限したいと考えています。 管理者は Level1Supportというユーザーグループを作成し、以下のルールを定義します: Level1Support,*,PswaEndpoint。 このルールは、 Level1Support グループ内のすべてのユーザーに PswaEndpoint 構成を持つすべてのコンピュータへのアクセス権を与えます。 同様に、アクセスは特定のコンピュータ群に制限されることがあります。

  • 管理者によっては特定のユーザーに他のユーザーよりも多くのアクセス権を与えています。 例えば、管理者は AdminsBasicSupportという2つのユーザーグループを作成します。 管理者はまた、PswaEndpointという制限されたランスペースを持つエンドポイントを作成し、以下の2つのルールを定義します:Admins,*,*およびBasicSupport,*,PswaEndpoint。 最初のルールは 管理者 グループの全ユーザーにすべてのコンピュータへのアクセスを許可し、2つ目のルールでは BasicSupport グループのすべてのユーザーが PswaEndpointを持つコンピュータのみにアクセスできるようにします。

  • 管理者がプライベートなテスト環境を設定し、すべての認可されたネットワークユーザーが通常アクセスできるすべてのコンピュータにアクセスできるようにしたいと考えています。 これはプライベートなテスト環境であるため、管理者は安全でない認可ルールを作成します。 - 管理者はコマンドレット Add-PswaAuthorizationRule * * *を実行し、ワイルドカード文字 * を使ってすべてのユーザー、すべてのコンピュータ、すべての構成を表現します。 - このルールは以下の通りです: Add-PswaAuthorizationRule -UserName * -ComputerName * -ConfigurationName *

    このルールは安全な環境では推奨されず、Windows PowerShell Web Accessが提供する認証ルール層のセキュリティを回避します。

  • 管理者は、ワーキンググループとドメインの両方を含む環境でユーザーがターゲットコンピュータに接続できるようにしなければなりません。そこでは、時折ワークグループコンピュータがドメイン内のターゲットコンピュータに接続するために使われたり、ドメイン内のコンピュータがワーキンググループのターゲットコンピュータに接続するために使われたりします。 管理者はワークグループ内のゲートウェイサーバーである PswaServerを持ち、そしてターゲットコンピュータ srv1.contoso.com ドメイン内にあります。 ユーザーChrisはワークグループゲートウェイサーバーとターゲットコンピュータの両方の認可されたローカルユーザーです。 彼のワークグループサーバー上のユーザー名は chrisLocalです。ターゲットのコンピューター上のユーザー名は Contoso\Chrisです。 クリスに srv1.contoso.com へのアクセスを許可するために、管理者は以下のルールを追加します。

Add-PswaAuthorizationRule -userName PswaServer\chrisLocal `
   -computerName srv1.contoso.com -configurationName Microsoft.PowerShell

前のルールの例は、ゲートウェイサーバー上でクリスを認証し、その後 SRV1へのアクセスを承認します。 サインインページでは、クリスが オプション接続設定 欄(contoso\chris)で2セット目の認証情報を入力する必要があります。 ゲートウェイサーバーは追加の認証情報を使ってターゲットコンピュータ上で認証します。 srv1.contoso.com

前述のシナリオでは、Windows PowerShell Web Accessは、以下の条件が成功し、少なくとも1つの認可ルールによって許可された場合にのみ、ターゲットコンピュータへの接続を成功させます。

  1. 認証ルールにユーザー名を server_name\user_name 形式で追加することで、ワークグループゲートウェイサーバーで認証

  2. ターゲットコンピュータでの認証は、サインインページの オプション接続設定 エリアで提供された代替認証情報で行います

    ゲートウェイとターゲットコンピュータが異なるワークグループやドメインに属している場合、2つのワークグループコンピュータ間、2つのドメイン間、またはワークグループとドメイン間で信頼関係を確立する必要があります。 この関係はWindows PowerShellのWeb Access認可ルールコマンドレットを使って設定することはできません。 認可ルールはコンピュータ間の信頼関係を定義しません。特定のターゲットコンピュータやセッション構成への接続のみを許可できます。 異なるドメイン間の信頼関係の設定方法については、「 ドメイン信託および森林信託の作成」を参照してください。 ワーグループコンピュータを信頼されたホストリストに追加する方法については、「 サーバーマネージャーによるリモート管理」をご覧ください。

複数のサイトに対して単一の認可ルールセットを使用すること

認可ルールはXMLファイルに保存されます。 デフォルトでは、XMLファイルのパス名は $env:windir\Web\PowershellWebAccess\data\AuthorizationRules.xmlです。

認可ルールのXMLファイルへのパスは powwa.config ファイルに保存されており、 $env:windir\Web\PowershellWebAccess\dataに記載されています。 管理者は powwa.config のデフォルトパスへの参照を好みや要件に合わせて変更する柔軟性があります。 管理者がファイルの場所を変更できるようにすることで、複数のWindows PowerShell Web Accessゲートウェイが同じ認証ルールを使用できるようになります。

セッション管理

デフォルトでは、Windows PowerShell Web Accessはユーザーを同時に3つのセッションに制限します。 IISマネージャーでウェブアプリケーションの web.config ファイルを編集し、ユーザーごとに異なるセッション数を割り当てることができます。 web.config ファイルへのパスは$env:windir\Web\PowerShellWebAccess\wwwroot\Web.configです。

デフォルトでは、IIS Web Serverは設定が編集されるとアプリケーションプールを再起動するよう設定されています。 例えば、 web.config ファイルに変更が加えられるとアプリケーションプールが再起動されます。 > Windows PowerShell Web Accessはメモリセッション状態を使用しているため、>Windows PowerShell Web Accessセッションにサインインしたユーザーは、アプリケーションプールの再起動時にセッションを失います。

サインインページでデフォルトパラメータを設定する

Windows PowerShell Web Access ゲートウェイが Windows Server 2012 R2 上で動作している場合、Windows PowerShell Web Access サインインページに表示される設定のデフォルト値を設定できます。 前の段落で説明した web.config ファイルで値を設定できます。 サインインページ設定のデフォルト値は web.config ファイルの appSettings セクションにあります。以下は appSettings セクションの例です。 これらの設定の有効値は、Windows PowerShellの New-PSSession コマンドレットの対応するパラメータの値と同じです。

例えば、以下のコードブロックに示されているように、 defaultApplicationName キーはターゲットコンピュータ上の $PSSessionApplicationName preference変数の値です。

  <appSettings>
      <add key="maxSessionsAllowedPerUser" value="3"/>
      <add key="defaultPortNumber" value="5985"/>
      <add key="defaultSSLPortNumber" value="5986"/>
      <add key="defaultApplicationName" value="WSMAN"/>
      <add key="defaultUseSslSelection" value="0"/>
      <add key="defaultAuthenticationType" value="0"/>
      <add key="defaultAllowRedirection" value="0"/>
      <add key="defaultConfigurationName" value="Microsoft.PowerShell"/>
  </appSettings>

タイムアウトと予期せぬ切断

Windows PowerShell Web Access セッションはタイムアウトします。Windows Server 2012上で動作するWindows PowerShell Web Accessでは、セッションが15分間非アクティブになるとサインインしたユーザーにタイムアウトメッセージが表示されます。 タイムアウトメッセージが表示されてから5分以内にユーザーが応答しない場合、セッションは終了し、ユーザーはサインアウトされます。IISマネージャーのウェブサイト設定でセッションのタイムアウト期間を変更できます。

Windows Server 2012 R2上で動作するWindows PowerShell Web Accessでは、セッションはデフォルトで20分間の非アクティブな時間が終了します。 ユーザーがネットワークエラーやその他の予期せぬシャットダウンや障害のためにウェブベースのコンソールのセッションから切断された場合、ユーザーがセッション自体を閉じたわけではない場合でも、Windows PowerShellのWeb Accessセッションはターゲットコンピュータに接続されたまま、クライアント側のタイムアウト期間が終了するまで実行を続けます。 セッションはデフォルトの20分後か、ゲートウェイ管理者が指定したタイムアウト時間のいずれか短い方で切断されます。

ゲートウェイサーバーがWindows Server 2012 R2を実行している場合、Windows PowerShell Web Accessは後で保存したセッションに再接続できますが、ネットワークエラー、予期せぬシャットダウン、その他の障害でセッションが切断されると、ユーザーはゲートウェイ管理者が指定したタイムアウト期間が終了するまで保存済みのセッションを見たり再接続したりできません。

こちらもご覧ください

Windows PowerShell Web Accessのインストールと使用

about_Session_Configurations

Windows PowerShell Web Access Cmdlets