サーバー セキュリティの計画

  • [アーティクル]

適用対象: Application Virtualization

環境のセキュリティを強化するには、周囲の潜在的脅威への露出度を検討する必要があります。App-V にセキュリティを提供するには、基礎的インフラストラクチャに対するセキュリティの実行と機能だけでなく、特定の App-V セキュリティ機能をインフラストラクチャに活用する必要があります。インターネット インフォメーション サービス (IIS)、Active Directory ドメイン サービス、SQL サーバーなどのサービスの基盤となるインフラストラクチャを保護することにより、App-V システムの全体的なセキュリティが向上します。

サーバー インストール用の規定の設定は、最高レベルのセキュリティを提供します。ただし、一部のコンポーネントはインストールの一環としては構成されない基礎的インフラストラクチャに依存しています。ポストインストール手順を実行することによって、App-V インフラストラクチャのセキュリティが強化されます。

コンテンツ ディレクトリには、クライアントにストリームされるすべてのパッケージが含まれています。セキュリティに対する多くの脅威を除去するために、これらのリソースには可能な限り強固なセキュリティが必要です。さらに次のようなガイダンスが挙げられます。

  • UNC ベース公開かストリーミングのいずれか、または両方 — この項目への許可には環境内で最も厳しい制限を課すべきです。NTFS 権限を使用して、コンテンツ ディレクトリに対し最も厳しいアクセス制御リスト (ACL) を実装します (ユーザー = 読み取りのみ、管理者 = 読み取りおよび書き込み)。

  • 公開とストリーミングのいずれか、または両方に IIS を使用 — Windows 統合認証のみをサポートするように IIS を構成します。IIS サーバーへの匿名アクセスを削除して、NTFS 権限によるディレクトリへのアクセスを制限します。

  • RTSP/RTSPS でアプリケーション パッケージをストリームする — App-V プロバイダ ポリシーを構成して、認証を要求し、アクセス許可を適用して、プロバイダ ポリシーへのアクセス権を要求グループのみに限定するようにします。データベース内で適切なアクセス許可のあるアプリケーションを構成します。

データ ストア内のデータへの潜在的脅威を低減し、インフラストラクチャへの悪質なアプリケーションの公開を避けるために、管理者権限を持つユーザーの数を最少限に抑えます。

Application Virtualization Security

App-V はインフラストラクチャのさまざまなコンポーネント間の通信に複数の方法を使用します。App-V インフラストラクチャを計画するとき、サーバー間の通信のセキュリティを確保することによって、既存のネットワークにすでに存在する可能性のあるセキュリティ リスクを軽減できます。

データ ストア

Application Virtualization Management Server と Application Virtualization Management Service は、TCP ポート 1433 を介した SQL 接続を使用してデータ ストアと通信します。Management Server はデータ ストアを使用してアプリケーションおよび構成用のデータを取得し、使用方法に関する情報をデータベースに書き込みます。Management Service は、App-V インフラストラクチャの構成を行う管理者の代理としてデータ ストアと通信します。データ ストアには重要な情報が含まれるため、このデータへの脅威は最小限に抑えることが重要です。

App-V Management Server、Management Service、およびデータ ストア間の通信は、インターネット プロトコル セキュリティ (IPsec) で保護することをお勧めします。特に、データ ストア (SQL) と Management Server 間、およびデータ ストアと Management Service 間の通信チャネルのセキュリティ保護のためのポリシーを作成します。また、すべての App-V インフラストラクチャ コンポーネントがセキュリティで保護されたチャネルのみで通信するように、IPsec を使用してサーバーおよびドメインの分離を展開することもできます。IPsec の実装についての詳細については、以下のドキュメントを参照してください。

コンテンツ ディレクトリ

App-V Management Server のインストールにより、コンテンツ ディレクトリの場所が構成されます。このディレクトリは、仮想化アプリケーション パッケージの保存先です。この場所は、サーバーのローカルでも、リモートのネットワーク共有でも構いません。したがって、コンテンツ ディレクトリをリモートにした場合、通信をセキュリティで保護するためには IPsec の実装が役立ちます。

また、クライアントにパッケージをストリームするために IIS サーバー上の仮想ディレクトリを使用することもできます。コンテンツ用に作成した仮想ディレクトリがリモートのソースにある場合、IIS サーバーとリモートの保存先間の通信をセキュリティで保護するために IPsec を使用します。

コンテンツ ディレクトリには、クライアントにストリームされるすべてのパッケージが含まれています。セキュリティに対する多くの脅威を除去するために、これらのリソースには可能な限り強固なセキュリティが必要です。

セキュリティ プロトコル

RTSPS または HTTPS を使用して、通信のセキュリティを強化することができます。RTSPS は App-V サーバーで、RTSPS は IIS サーバーで使用されるプロトコルです。これらのプロトコルは、サーバーから Application Virtualization Desktop Client へアプリケーションを公開するときに使用されます。どちらのプロトコルを使用するか決めてから、そのプロトコルを使用する公開サーバーを追加します。

RTSPS 用に App-V サーバーを構成する

TLS などのセキュリティ強化を使用して App-V Management Server または Streaming Server をインストールしたり構成する場合、App-V サーバーに X.509 V3 証明書を準備する必要があります。サーバーにセキュリティをインストールまたは構成の準備をするには、特定の要件を満たす必要があります。セキュリティの強化された App-V Management Server または Streaming Server 用に証明書を展開し構成するには、次の技術的要件があります。

  • 証明書は有効である必要があります。そうでなければ、クライアントは接続を終了します。

  • 証明書には正しい拡張キー使用法 (EKU) が含まれてる必要があります - サーバー認証 (OID 1.3.6.1.5.5.7.3.1)。そうでなければ、クライアントは接続を終了します。

  • 証明書の完全修飾ドメイン名 (FQDN) がインストール先サーバーと一致する必要があります。たとえば、クライアントが RTSPS://Myserver.mycompany.com/content/MyApp.sft を呼び出しているが、証明書の [発行先] フィールドが Myserver1.mycompany.com を含んでいる場合、たとえ Myserver.mycompany.com と Myserver1.mycompany.com が同じ IP アドレスに解決するとしても、クライアントはサーバーに接続せずセッションは終了します。

    注意

    ネットワーク負荷分散クラスタ内で App-V を使用する場合、RTSPS をサポートするために証明書をサブジェクト代替名 (SAN) で構成する必要があります。証明機関 (CA) の構成と SAN での証明書の作成については、「セキュリティで保護された LDAP 証明書にサブジェクトの別名を追加する方法」(https://go.microsoft.com/fwlink/?LinkId=133228) を参照してください。

  • App-V サーバーに証明書を発行する CA は、このサーバーに接続しているクライアントに信頼される必要があります。そうでなければ、クライアントは接続を終了します。

  • サーバーの App-V サービスによるアクセスを有効にするには、証明書の秘密キーに対する許可を変更する必要があります。既定では、App-V Management Server および Streaming Server のサービスは Network Service アカウントの下で実行されます。サーバー上で PKCS#10 が生成されると、秘密キーが作成されます。このキーにアクセスできるのは、Local System および Administrators グループのみです。これら既定の ACL は、App-V サーバーがセキュリティで保護された接続を受け入れるのを防ぎます。

    注意

    公開キー基盤 (PKI) の構成については、「Windows Server 2003 の公開キー基盤 (PKI)」(https://go.microsoft.com/fwlink/?LinkId=133229) を参照してください。

HTTP で IIS サーバーを構成する

App-V は特定のインフラストラクチャ構成の IIS サーバーを使用する場合があります。IIS サーバーの構成については、「IIS 6.0 Security Best Practices (IIS 6.0) (IIS 6.0 のセキュリティのベスト プラクティス)」(https://go.microsoft.com/fwlink/?LinkId=133230) を参照してください。

注意

IOC および OSD ファイルの公開に IIS を使用している場合、OSD=TXT の MINME タイプを構成する必要があります。そうしないと、IIS は ICO および OSD ファイルのクライアントへの提供を拒否します。

アプリケーション レベルのセキュリティ

特定のアプリケーションをユーザーのデスクトップへストリームするようにサーバーを構成することができます。ただし、実際にアクセスが許可されるのはアプリケーション レベルではなく、パッケージ レベルです。特定のアプリケーションがユーザーのデスクトップに公開されない場合もありますが、ユーザーがアプリケーション追加権限を有する場合やクライアント コンピュータの管理者である場合、ユーザーはパッケージ内のすべてのアプリケーションを実行するためのショートカットを作成して、使用することができます。

分散環境への App-V 管理の構成

特定の組織のインフラストラクチャを設計するときに、App-V Management Server をインストールしているコンピュータとは別のコンピュータに App-V Management Web Service をインストールできます。これらの App-V コンポーネントを分割する一般的な理由は、次のとおりです。

  • パフォーマンス

  • 信頼性

  • 可用性

  • スケーラビリティ

インフラストラクチャを正しく動作させるために、App-V Management Console、Management Server と Management Web Service を分割する場合は、追加の構成を行う必要があります。サーバーの構成方法の詳細については、「サーバーを委任に対して信頼されるように構成する方法」を参照してください。

参照:

その他のリソース

セキュリティと保護の計画

-----
MDOP の詳細については、TechNet ライブラリの参照、TechNet Wiki でのトラブルシューティングの検索、または Facebook や Twitter をフォローしてください。 MDOP ドキュメントに関するご意見やご提案は、以下までお送りください。 MDOPdocs@microsoft.com。