ポリシーとは？

Google では、プライバシーの重要性を認識しております。以下は、Google のサービスをご利用になる際に Google が取得および収集する個人情報の種類、また情報を保護するために Google が講じている対策についてまとめたものです。以下を参考に、Google の個人情報の取り扱いについて十分に納得された上で、Google との個人情報の共有についてご判断いただければ幸いです。
以下は、Google のプライバシー ポリシー全文のハイライト版です。プライバシー ポリシー全文では、Google の各国向け製品、サービスおよびウェブサイト (以下、総称して Google の「サービス」) に適用される個人情報の取り扱いについて詳しく説明しています。Google のサービスごとに定められている個人情報の取り扱いについては、画面左のナビゲーションバーから参照できます。
Google では、Google のサービスに登録する場合や、お客様の意思で情報をご提供いただく際に個人情報を収集しています。収集した情報は、Google の他のサービスまたは第三者から取得した情報と統合し、お客様のためのコンテンツのカスタマイズなど、お客様の利便性向上のために使用する場合があります。
Google では、オンライン エクスペリエンスの拡充を図るとともに、サービスの品質を向上する目的で、お客様がどのように Google のサービスをご利用になっているか、クッキー (cookie) その他の技術を使用して分析しています。
Google のウェブサイトにアクセスしたり、または Google の一部の製品を利用すると、URL、IP アドレス、ブラウザの種類および言語、リクエストの日時などの情報が Google のサーバーによって自動的に記録されます。
個人情報は、カスタマイズ コンテンツおよび広告を表示するサービスを含め、お客様からご依頼のあったサービスを提供するために使用する場合があります。
また、Google の技術およびサービスの運用および向上のため、個人情報を監査、リサーチ、および分析に使用する場合もあります。
個人情報の処理にあたって第三者に協力を依頼するときは、Google のプライバシーポリシーの遵守とともに、適切な秘密保持およびセキュリティ対策の徹底を求めます。
法的手続きの遵守、詐欺または差し迫った被害の防止、Google のネットワークおよびサービスのセキュリティ確保の場合など、限られた状況において第三者と情報を共有する場合があります。
Google では、個人情報の処理を米国その他各国の Google サーバーで行っていますが、お客様の居住国以外のサーバーで個人情報を処理する場合もあります。
Google では、個人情報の提供をお願いするにあたって、合理的に可能な限り複数の選択肢をご用意しています。詳細は、各サービスの「プライバシーに関する考え方」または「よくある質問」をお読みください。
Google への個人情報の提供を拒否したり、ブラウザの設定でクッキーを受け入れないようにすることも可能です。ただしその場合は、Google の機能またはサービスが一部正常に機能しなくなることがあります。
お客様からお申し出があった場合、お客様本人の個人情報を開示し、誤った情報があるときはこれを訂正し、合理的に可能であればお客様自身で削除できるよう、誠意をもって対応します。
Google サービスに関する情報については、左側のメニューから関連するプライバシー ポリシーにアクセスするか、Google ヘルプ ページをご覧ください。 Google はヨーロッパおよびアメリカのセーフ ハーバー プログラムに登録しています。
Google のプライバシー ポリシーの詳細については、プライバシー ポリシー全文をご覧ください。 プライバシーについて他にご質問がありましたら、お問い合わせください。 Google のプライバシー ポリシーと関係のないお問い合わせにはお応えできませんのであらかじめご了承ください。

[ 69] Google プライバシーセンター
[引用サイト]　 http://www.google.com/intl/ja/privacy.html

Google では、プライバシーの重要性を認識しております。次ののプライバシー ポリシーは、Google Inc.、その子会社または関連会社が提供している製品、サービスおよびウェブ サイト (以下、総称して 「Google のサービス」) のすべてに適用されるものです。また、Google の個人情報の取り扱いについてより詳しいご説明が必要な事項については、サービスごとに「プライバシーに関する考え方」を掲載し、各サービスでどのように個人情報を処理しているかについて説明しています。各サービスの「プライバシーに関する考え方」は、画面左のナビゲーションバーからアクセスできます。
Google は、告知、オプション、第三者への転送、セキュリティ、データ保全、アクセスおよび強制履行に関する米国セーフハーバー プライバシー原則を遵守し、米国商務省のセーフハーバー プログラムに登録しています。
Google では、Google 検索サービスなど、アカウントを登録したり個人情報を提供しなくても利用できるサービスを多数ご用意していますが、あらゆる種類のサービスを提供するため、次のような情報を収集させていただく場合があります。
ご提供いただく情報 - Google アカウントまたは登録が必要な Google の他のサービスもしくはプロモーションのご登録手続きに際して、個人情報 (お名前、メール アドレス、およびアカウント パスワードなど) の提供をお願いしています。広告プログラムなど一部のサービスでは、クレジットカードその他のお支払いに関するアカウント情報の提供もお願いしていますが、これらの情報は安全なサーバー上で暗号化して管理しています。Google では、お客様のアカウントに含まれる情報を Google の他のサービスまたは第三者から取得した情報と統合し、お客様の利便性の向上および Google のサービスの品質向上のために使用する場合があります。一部のサービスについては、情報を統合しないように選択することもできます。
Google の cookie - はじめて Google にアクセスすると、Google からお客様のコンピュータに cookie が送信されます。 cookie は、文字列情報からなる小さなファイルで、個々のユーザーのブラウザを識別します。Google では、Google のサービスの品質向上のため、ユーザーの設定内容の保存やユーザーの傾向 (どのように検索が行われているかなど) の追跡に cookie を使用します。多くのブラウザが初期状態では cookie を受け入れるように設定されていますが、設定を変更して cookie の受け入れを拒否したり、cookie が送信されると表示するように設定することも可能です。ただし、cookie を無効にすると、Google の一部の機能およびサービスが正常に機能しなくなることがあります。
ログ情報 - Google のサービスを利用すると、お客様がウェブサイトにアクセスするたびにブラウザから送信される情報が Google のサーバーによって自動的に記録されます。これらのサーバー ログには、お客様のアクセス リクエスト、IPアドレス、ブラウザの種類、ブラウザの言語、リクエストの日時、およびブラウザを識別する cookie などの情報が含まれる場合があります。
お客様からのご連絡 - メールその他により Google 宛てにご連絡をいただいた場合、お問い合わせの処理、ご要望への対応、また Google のサービス向上のためにメッセージの内容を保存させていただく場合があります。
関連サイト - Google では、他のウェブサイトに関連してサービスの提供を行う場合があります。サービスを提供する都合上、お客様がそれらのサイトに提供した個人情報が Google に送信されてくることがあります。それらの情報は、本プライバシーポリシーに従って処理されます。ただし、関連サイトごとに個人情報の取り扱いが異なる場合もあるため、それらのサイトのプライバシー ポリシーも一読されることをお勧めいたします。
リンク - Google では、ユーザーがリンクを辿ったかどうか追跡できるフォーマットでリンクを表示しています。これらの情報は、Google の検索技術、カスタマイズ コンテンツおよび広告の品質を向上させるために使用しています。リンクおよびリダイレクト URL についてについて詳しくお知りになりたい場合は、「よくある質問」を参照してください。
他のサイト - 本プライバシー ポリシーは、Google が所有および運営しているウェブ サイトおよびサービスに適用されるものです。Google は、検索結果として表示されるサイトまたは Google の各サービス内からリンクされているサイトについては管理権限がありません。これら他のサイトも、それぞれ cookie その他のファイルをお客様のコンピュータに送信し、データまたは個人情報を取得する可能性があります。
Google では、プライバシー ポリシーおよび／または各サービスの「プライバシーに関する考え方」に記載されている目的でのみ個人情報を処理します。これらの目的には、前述したものの他、下記が含まれます。
Google の個人情報の処理方法についてさらに詳しくお知りになりたい場合は、各サービスの「プライバシーに関する考え方」をお読みください。
Google では、個人情報の処理を米国その他各国の Google サーバーで行っていますが、お客様の居住国以外のサーバーで個人情報を処理する場合もあります。また、Google のサービスの提供のために個人情報を処理する場合もありますが、広告パートナーなど第三者のために当該第三者の指示に従って個人情報を処理することもあります。
Google では、登録が必要なサービスの手続きに際して個人情報の提供をお願いしていますが、当初の収集目的とは異なる方法でこれらの情報を使用する場合には、あらかじめお客様本人の同意を得るものとします。
本プライバシー ポリシーおよび／または各サービスの「プライバシーに関する考え方」に記載されている目的以外で個人情報を使用する場合には、そのような他の目的に個人情報を利用されることを拒否できる効果的な手段を用意しています。お客様本人の同意を事前に得ることなく、本プライバシー ポリシーおよび／または各サービスの「プライバシーに関する考え方」に記載されていない目的で、機密性の高い情報を収集または使用することはありません。
お客様は、Google の各サービスに個人情報を提供することを拒否できます。その場合は該当するサービスを提供できない場合があります。
Google では、以下の限られた状況においてのみ、個人情報を Google 以外の企業または個人と共有します。
個人情報の処理業務を委託する目的で Google の子会社、関連会社その他信頼できる企業または個人に情報を提供する場合。これらの当事者に対しては、Google の指示に基づいて、本ポリシーを遵守するとともに、その他適切な秘密保持、セキュリティ対策を徹底して情報の処理にあたることに同意するよう求めます。
これらの情報にアクセス、またはこれらの情報を使用、保護、開示することについて、(a) 適用される法律、規制、法的手続きもしくは法的強制力のある政府の要求に従う、(b) 利用規約の履行強制 (違反の可能性がある場合にこのような調査を行う場合を含む)、(c) 不正行為、セキュリティ問題もしくは技術的問題の発見、防止、または対応、(d) Google、そのユーザーまたは公共の権利、財産または安全が脅かされる危険がある場合に、法律上必要とされるまたは法律で認められる方法でこれを阻止する目的において、誠意に基づいて正当であると確信する場合。
Google が合併、吸収、その他 Google の資産の一部もしくは全部の売却を伴う取引の対象となった場合は、個人情報の譲渡により適用されるプライバシー ポリシーが変更される前に告知します。
Google は、一部の匿名ベースの集計情報 (たとえば、特定の語を検索したユーザー数や広告をクリックしたユーザー数など) を第三者と共有する場合があります。これらの情報は、個人を識別または特定するものではありません。
Google では、データへの不正アクセス、またはデータの不正な改変、開示、破壊を防止するために適切なセキュリティ対策を講じています。たとえば、データの収集、保管、処理の方法およびセキュリティ対策について社内監査を実施するとともに、個人データを保管しているシステムに外部の者が不正に近づけないように物理的なセキュリティ対策を採用しています。
Google では、個人情報にアクセスできる者を、Google の社員、請負業者および代理人のうち、Google のサービスの運営、開発または向上のために当該情報を知る必要のある者に限定しています。各人が秘密保持義務を負っており、義務を履行しなかった場合には解雇および刑事訴追を含め、懲戒処分の対象となります。
Google では、個人情報を当初の収集目的のためにのみ、また本ポリシーあるいは各サービス固有のプライバシーに関する考え方に従ってのみ処理します。Google では、個人情報の収集、保存、処理がサービスの提供または向上に必要な範囲においてのみ行われるように、データの収集、保存、処理の仕方を監査しています。Google では、処理される個人情報が正確かつ完全で最新の情報となるように合理的な措置を講じていますが、個人情報の更新または訂正はお客様本人にご協力いただく必要があります。
Google では、サービスのご利用にあたり、お客様本人に当該本人の個人情報を開示して、誤ったデータがあれば訂正し、法律上または正当な業務の都合上保存しなければならないデータでない限り、お申し出により削除するよう努めています。Google では、個人のお客様より個人情報の開示、訂正または削除を求められた場合、あらかじめご本人であることの確認と当該情報の特定をお願いしています。お客様のご依頼が正当な理由なく何度も繰り返され、もしくは定期的に行われる場合、過度な技術的作業を要する場合、他人のプライバシーが脅かされる場合、きわめて非現実的な場合 (たとえばバックアップテープ上の情報に関するご依頼など)、またはその他開示の必要がないと判断される場合は、お断りすることがあります。いずれの場合も、情報の開示および訂正は過度な作業を要するものを除いて無料で受け付けています。サービスによっては、個人情報の開示、訂正または削除の手順が異なる場合があります。詳しくは、各サービスの「プライバシーに関する考え方」または「よくある質問」を参照してください。
Google では、本ポリシーの遵守を定期的に確認しています。本ポリシーまたは Google の個人情報の取り扱いについてご質問またはご不明な点がある場合は、お気軽にこちらへご連絡いただくか、Privacy Matters c/o Google Inc. 1600 Amphitheatre Parkway，Mountain View California 94043, USA まで文書にてお問い合わせください。この住所宛に書面にて正式に問題を報告していただいた場合は、Google からご本人様に連絡を取らせていただく方針です。個人データの送信に関して Google とお客様の間で解決できなかった問題については、現地のデータ保護当局などの規制当局と協力して解決にあたります。
このプライバシー ポリシーは随時変更されることがあります。Google は、本ポリシーに基づくお客様の権利をお客様の明示的な許可なく制限することはありません。また、多くは若干の変更にとどまるものと考えています。いずれの場合も、ポリシーの変更に際してはこのページに掲載し、大幅な変更の場合はより明確な方法で告知します (一部のサービスについてはメールでお知らせします)。本ポリシーのバージョンは、ページ上部の日付で確認いただけます。さらに、プライバシー ポリシーの過去のバージョンも参照用にアーカイブに保存されています。

[ 70] Google プライバシーセンター
[引用サイト]　 http://www.google.com/intl/ja/privacypolicy.html

ここでは、グループ ポリシーを使ってユーザーを管理するためのポリシーについて説明します。これらのポリシーは System.adm に含まれているため、既定ではコンソールに表示されます。これらのポリシーを構成するには、「グループ ポリシー スナップインを開くには」で説明されているようにグループ ポリシーを開きます。コンソール ツリーで、グループ ポリシー ノードをクリックします。
コンピュータの (バックグラウンドでの) 使用中にユーザーのグループ ポリシーが更新される頻度を指定します。この設定は、ユーザーの構成フォルダのグループ ポリシー設定だけに対するバックグラウンドの更新間隔を指定します。
既定では、ユーザーのグループ ポリシーは、バックグラウンドで 90 分ごとに更新されます。0 分から 30 分のランダムなオフセットもあります。
更新間隔として 0 〜 64,800 分 (45 日) を指定できます。0 分を選択した場合、コンピュータは 7 秒ごとにユーザーのグループ ポリシーを更新しようとします。ただし、更新処理は作業を妨害し、ネットワーク トラフィックを増大させるので、大半のインストールでは、更新間隔を非常に短くするのは適切ではありません。
この設定を無効にすると、ユーザーのグループ ポリシーは 90 分ごとに更新されます (既定値)。コンピュータの使用中にユーザーのグループ ポリシーが更新されないように指定するには、[バックグラウンドでのグループ ポリシーの更新を無効にする] 設定を選択します。
この設定を使用すると、実際の更新間隔のばらつきの範囲も指定できます。同じ更新間隔に設定されている複数のクライアントが同時に更新を要求しないように、各クライアントの更新間隔がランダムな分数ずつずらされます。ランダム時間ボックスに入力した値によって、ずらされる値の範囲の上限値が設定されます。たとえば、30 分と入力すると、ずらされる値として 0 〜 30 分が選択されます。大きな数を入力すると、設定される範囲が広がるので、クライアントからの要求が重なる可能性が低くなります。ただし、更新が大幅に遅れることがあります。
この設定は、ユーザーのグループ ポリシーの更新間隔を確立します。コンピュータのグループ ポリシーの更新間隔を設定するには、[コンピュータのためのグループ ポリシーの更新間隔] 設定を使用します。この設定は、コンピュータの構成\管理用テンプレート\システム\グループ ポリシーにあります。
この設定は、[バックグラウンドでのグループ ポリシーの更新を無効にする] 設定が選択されていない場合に限り使用できます。
ユーザーがポリシー更新の兆候を認識できるように、グループ ポリシーが定期的に更新される旨をユーザーに通知することを検討してください。グループ ポリシーを更新すると、Windows デスクトップが更新されます。デスクトップは一瞬点滅し、開いているメニューが閉じられます。また、グループ ポリシーによって課される制限事項 (ユーザーの実行できるプログラムを制限するものなど) が、進行中のタスクに干渉することがあります。
グループ内のコンピュータのポリシーを更新するドメイン コントローラから転送されるデータの速度がこの設定の指定速度より遅い場合、その接続は低速とみなされます。
低速ポリシー接続に対するシステムの応答は、ポリシーごとに異なります。ポリシーを実装するプログラムによって、低速リンクへの応答を指定できます。また、フォルダ内のポリシーを処理するポリシーを使用すると、プログラムが指定した低速リンクに対する応答を無効にすることができます。
このポリシーを使うには、[接続速度] ボックスに 0 〜 4,294,967,200 (0xFFFFFFA0) の 10 進値を入力します。この値は、秒あたりのキロビット数で表した転送速度です。これより低速の接続は、低速と見なされます。「0」を入力すると、すべての接続が高速と見なされます。
このポリシーは [コンピュータの構成] および [ユーザーの構成] フォルダに表示されます。[コンピュータの構成] のポリシーによって、[コンピュータの構成] フォルダのポリシーに対して低速リンクが定義されます。ユーザーの構成のポリシーは、そのフォルダのポリシーにとっての低速リンクを定義します。
[プライマリ ドメイン コントローラを使う] は、ユーザーがログオンしているドメインのプライマリ ドメイン コントローラによってポリシーが適用されるように指定します。
[Active Directory スナップインから継承する] は、グループ ポリシー スナップインをホストするドメイン コントローラによってポリシーが適用されるように指定します。
[任意の利用可能なドメイン コントローラを使用する] は、ドメイン内で最初に見つかった利用可能なドメイン コントローラを使用するように指定します。
このポリシーを無効にするか構成しない場合、プライマリ ドメイン コントローラがグループ ポリシーを適用します。
このポリシーを有効にすると、Active Directory ユーザーとコンピュータ スナップインと Active Directory サイトとサービス スナップインの [新しいグループ ポリシー オブジェクト] チェック ボックスが既定でオフになります。管理者は、チェック ボックスをオンにして、オプションを選択できます。
このポリシーを無効にするか構成しない場合、[新しいグループ ポリシー オブジェクト] チェック ボックスが既定でオンになり、管理者が手動でオフにしなければなりません。
このポリシーは、グループ ポリシーの管理用テンプレート ノードにある表示メニュー項目 [ポリシーだけを表示] に影響します。
このポリシーを有効にすると、[ポリシーだけを表示] メニュー項目の選択を解除できなくなります。このポリシーを無効にすると、このメニュー項目を選択できなくなります。
このコンテキストでのポリシーとは、Windows NT 4.0 スタイルのシステム ポリシーではなく、Windows 2000 グループ ポリシーのことです。この区別が重要な理由については、「Windows NT 4.0 のシステム ポリシー」 を参照してください。
既定では、グループ ポリシーを起動すると、%systemroot%\inf フォルダにある更新済みの管理テンプレート ソース ファイル (.adm) がロードされます。.adm ファイルは、グループ ポリシーの管理テンプレートの下に表示されるポリシーの一覧を作成します。
このポリシーを有効にすると、最後にグループ ポリシーを実行したときに使われた .adm ファイルがロードされます。この後、ユーザーが手動で .adm ファイルを更新しなければなりません。
.adm ファイルをアップグレードしても、ポリシーの構成設定は上書きされません。それらの設定は、.adm ファイルではなく Active Directory に格納されています。
.adm ファイルを手動でアップグレードするには、グループ ポリシーで、[管理用テンプレート] (どちらかのインスタンス) を右クリックし、[テンプレートの追加と削除] をクリックします。
MMC スナップインなど多くの Windows プログラムは、Component Object Model が提供するインターフェイスを使用します。これらのプログラムは、必要なコンポーネントが内部で登録されない限り、すべての機能を実行できません。
このポリシーを有効にしたけれどもコンポーネントの登録が行われていない場合、Active Directory が検索されます。見つかった場合は、ダウンロードされます。この検索によって、一部のプログラムの起動または実行が低速になることがあります。
このポリシーを無効にするか、または構成していない場合は、登録しなくてもプログラムは続行します。この結果、プログラムはその機能を何も実行しないか、または停止することがあります。
このポリシーはユーザーに適用されます。このポリシーをコンピュータに対して設定するには、コンピュータの構成\管理用テンプレート\システム\グループ ポリシーの [COM コンポーネントが存在しない場合ダウンロードする] ポリシーを使います。

[ 71] グループ ポリシーのポリシー：ユーザーの構成
[引用サイト]　 http://www.microsoft.com/products/windows/windows2000/ja/advanced/help/UserADM.htm

TechNet アーカイブ ホーム運用向けグループ ポリシーの設計最終更新日: 2002年7月24日トピックはじめに設計の前提条件構造化設計まとめはじめにグループ ポリシーの使用は、組織の総保有コスト (TCO) の削減に大きくかかわります。ソリューションの設計は、たとえ小規模な組織向けのものであっても、やさしいものではありません。対象となる構成のオプションは多く、レジストリ設定の変更、システム セキュリティの定義、ファイル アクセス許可の設定、およびソフトウェア アプリケーションの配布を行う能力を必要とするからです。このような複雑さに直面する管理者の場合、グループ ポリシー オブジェクト (GPO) を一本化して作成する方法を選択することも珍しくなく、作成する GPO に 1 台のコンピュータまたは複数のコンピュータの構成に必要な設定を "すべて" 含ませます。あるいは、スクリプト用、フォルダ リダイレクト用、ソフトウェア インストール用などに分けた小さな GPO を数多く作成する方法を選択する場合もあります。どちらの方法でも技術的な目的を短期的に満たすことはできますが、長期的には問題となる可能性があります。たとえば、ユーザーが他部門に異動したり、新しいアプリケーションが必要になったり、あるいはオペレーティング システムのほかの機能を使用しなければならなくなった場合は、どのようなことになるでしょうか。このような変更を行った場合に発生する問題のトラブルシューティングは簡単でしょうか。この章での主な目的は、必要な機能と管理手段を提供し、実運用環境における長期的な管理と日々の運用にも対応できるグループ ポリシー ソリューションの設計を支援することです。ページのトップへ設計の前提条件概要グループ ポリシー ソリューションの作成に着手する前に、次の点を確認してください。•グループ ポリシーを使用して達成しようとする目的•サービス レベル契約 (SLA) の内容•Microsoftｮ Windows 2000ｮ の設計に影響を及ぼす技術•運用要件、相互運用の必要性、およびグループ ポリシーの制約事項ここでは、以上の点が重要な理由を説明します。明確に定義した目的グループ ポリシーの配置を計画する場合、プロジェクトの目的を定義する必要があります。つまり、達成すべき業務目的を具体的に特定し、その目的の達成にグループ ポリシーをどう利用できるかを把握することです。この方針に沿うことで、最も有効なポリシー設定と構成オプションを選択できます。グループ ポリシーに関するプロジェクトの目的は、プロジェクトごとに異なります。プロジェクトによっては、オペレーティング システムの機能の中で、ユーザーが使用すると危険を伴ったり混乱を招くおそれのある機能を、ユーザーが利用できないように機能の一部を削除する必要があります。また、別のプロジェクトでは、次のような目的のためにグループ ポリシーを使用することがあります。•オペレーティング システムのオプションの構成•Internet Explorer の接続設定の定義•監査ポリシーの確立メモ : 組織によっては、不可欠な機能以外はユーザー環境から "すべて" 削除しようとする強力な動機がある場合があり、また、そのようにすることも可能ですが、厳しいポリシーを適用すると、ユーザーの反感を買うおそれがあり、また生産性を著しく低下させる可能性さえあります。技術的な目的に配慮すると共に、グループ ポリシーを配置する運用環境にも配慮する必要があります。ソリューションは、変更が多く適応能力が成功への鍵となる環境に配置される傾向があります。現在の技術的な問題のみに捕らわれ、ソリューションの将来的な管理や運用面に配慮しないと、グループ ポリシー適用による TCO の削減メリットを最大限に活かすことはできません。プロジェクトの目的によっては、技術チームが GPO の作成と管理をどう行うかについても考える必要があります。GPO を集中的に管理する組織もありますし、分散した複数のチームに GPO の作成と管理を任せる組織もあります。技術チームが利用できるグループ ポリシーのトラブルシューティング ツールによっても、作成する GPO の数と内容に影響を及ぼす場合があります。グループ ポリシーの解析ツールを持たない組織が、数多くの GPO を特定のコンピュータやユーザーに適用する場合、問題のトラブルシューティングは複雑になる可能性があります。サービス レベル契約の理解組織によっては、サービス レベル契約 (SLA) を定義し、SLA に、ワークステーションの電源投入後 Microsoft Windows 2000 のログオン画面が表示されるまでの許容最長時間や、ログオンしてからデスクトップが利用できるようになるまでの最長許容時間を定めます。特定のユーザーやコンピュータに適用される GPO の数により、コンピュータのスタートアップやユーザーのログオンに要する時間が変わりますが、最も影響が大きいのは GPO 内の "ポリシー設定" です。ソフトウェア アプリケーションを配布したり、ファイルやレジストリのアクセス許可を設定するポリシー設定 (一連の指示) を含む GPO を作成した場合、その実行に要する時間は、単に GPO を読み込む場合よりも "かなり" 長くなります。操作の数を次のように減らすと、GPO の読み取り (処理) に要する時間を短縮できます。•GPO にコンピュータやユーザーの設定のみを含めている場合、適用しないポリシー部分を無効にします。クライアント側拡張は、GPO の無効部分をスキャンしません。•GPO は、ユーザー オブジェクトやコンピュータ オブジェクトにグループ ポリシーの読み取り許可と適用許可がある場合にのみ適用されます。グループ ポリシーの適用許可を削除しているのに読み取り許可を与えている場合は、クライアント側拡張は、GPO を適用できないにもかかわらず GPO を処理 (スキャン) することになります。処理時間を短縮するには、まず GPO の [セキュリティ] タブで [Autheticated Users] グループを削除します。次に、GPO へのアクセス許可を持たさなければならないグループを追加し、そのグループに、グループ ポリシーの読み取り許可と適用許可を与えます。•小さな GPO をいくつか組み合わせて、より複雑なポリシーを作成します。たとえば、レジストリを変更する GPO とファイル システムのアクセス許可を設定する GPO を組み合わせます。このような組み合わせで GPO の数は減らせますが、ログオン時間はあまり短縮できません。前に述べたように、ログオン時間に最も影響するのは、GPO 内のポリシー設定です。GPO を組み合わせると、複数の GPO にある同じポリシー設定を変更しなければならない可能性があるため、長期的なサポートを難しくする可能性があることに注意してください。サービス レベル契約では、サービスの応答性に関する基準も定義できます。たとえば、ユーザーが新しいソフトウェア アプリケーションを受け取るまでにかかる期間や、コマンド プロンプトなど無効化していた機能を利用可能とするのに要する時間を定義します。考慮すべきことは、Windows 2000 のサイトとレプリケーション トポロジ、各ドメイン コントローラの位置 (特に、プライマリ ドメイン コントローラの役割を担っているもの)、およびグループ ポリシー管理者の所在場所です。Windows 2000 の設計への影響力論理面 (フォレスト、ドメイン、および組織単位 (OU) のモデル)GPO は、複数のサイトやドメインに適用することが可能であり、またセキュリティ フィルタを使用すると個々のコンピュータにも適用可能ですが、作成したポリシーのほとんどは、組織単位の構造に割り当てることになります。したがって、フォレスト内のドメイン "ごと" の組織単位の設計が、グループ ポリシーの適用を確実にサポートし、また問題のトラブルシューティングと修正を管理者が容易に行えるようにすることが重要です。メモ : ドメインによりポリシー要件が異なることがあります。ドメインごとに個別にポリシー要件を検討することが重要です。本社環境用とブランチ オフィス環境用のドメインを別々に作成している組織では、これら 2 つのドメイン間には、組織単位モデルとしての構造およびグループ ポリシーの要件の観点から、大きな相違点が起こる可能性があります。起こりうる相違点には、次の表のようなものがあります。場所ユーザーの種類説明要件本社多様なユーザー デスクトップの利用
ユーザーによる設定変更は最小限にとどめる。同一のアプリケーション セットおよびデスクトップ構成の利用。メモ : 組織単位 (OU) モデルの設計に不十分な点があると、グループ ポリシーの適用が困難になります。このような場合、特定のポリシーを組織のさまざまな部門に適用できるように複製せざるを得なくなったり、あるいはポリシーの目的を達成するために複数のコンテナに同じ GPO をリンクせざるを得なくなる可能性があります。このような複製やリンクは、どちらも綿密に検討され作成された操作手順に従えば実施可能ですが、組織単位モデルの設計が完了してからさまざまな工夫をするよりも、組織単位構造とドメインモデルを設計する際に、グループ ポリシーのねらいと目的を含めた適用についても考慮する方が賢明です。ドメイン内のコンピュータとユーザーにグループ ポリシーを適用する予定の場合、組織単位構造を設計する最善の方法は、管理対象とするオブジェクトを中心に考えることです。この考え方をとると、図 1 に示すようにグループ、サーバー、ユーザー、ワークステーションを最上位に据えた構造となります。これらの下位レベルへの組織単位の追加は、追加することでポリシーの適用が明確になる場合、理解しやすくなる場合、または管理の委任が必要になった場合のみに限定してください。以上の設計手法をとることで、作業対象の組織単位の構造の一部には適用しない GPO を部分的に無効にすることが可能になります。これは、各組織単位にはユーザー オブジェクト、またはコンピュータ オブジェクトのどちらかが含まれ、両方は含まれないからです。このようにすることで、グループ ポリシーを適用する複雑さを軽減でき、また迅速に適用できるようになります。メモ : 組織単位構造の上位に割り当てた GPO は継承されるので、GPO を複製したり、複数のコンテナに GPO をリンクする必要性も少なくなります。図 1: 最上位レベルの組織単位構造メモ : グループ ポリシー オブジェクトをユーザーに適用すると、ユーザーは異なるコンピュータ上で同じ構成オプションと同じソフトウェア アプリケーションを利用できます。ただし、一部のコンピュータ、ターミナル サーバー、ドメイン コントローラでは、このような利用は避けたい場合があります。また、コンピュータにどのユーザーがログオンしてもコンピュータの環境を同一にしたい場合もあります。ポリシー設定の "ループバックの処理" (GPO で有効にします) を使用すると、管理者は、その GPO 内でユーザー ベースのポリシー設定を構成できます。また、コンピュータにどのユーザーがログオンしても、これらの設定を適用できます。この設定を正しく動作させるには、GPO のユーザーとコンピュータの部分が有効である必要があります。ループバックの処理の詳細については、Microsoft サポート技術情報の Knowledge Base の文書 Q231287 http://support.microsoft.com/support/kb/articles/q231/2/87.asp (英語) を参照してください。
ユーザーに割り当てたポリシーによってターミナル サーバーが影響されないようにするこの方法の使用例については、Microsoft サポート技術情報の Knowledge Base の文書 Q260387 http://support.microsoft.com/support/kb/articles/q260/3/87.asp (英語) を参照してください。物理面 (サイトとレプリケーション)適切なポリシー設定を判断する場合、Microsoft Active Directory・の物理的な側面 (サイト、レプリケーション、ドメイン コントローラの物理的な配置など) を把握しておくことがことが重要です。たとえば、キャッシュされたログオン情報の使用を無効にすることができます。この場合、ユーザーがローカル ワークステーションにログオンするには、ドメイン コントローラが必要です。次の設定を変更すると、これを無効にできます。
[コンピュータの構成¥Windows の設定¥セキュリティの設定¥ローカル ポリシー¥セキュリティ オプション]
あるサイトにローカルのドメイン コントローラが存在せず、また WAN リンクも失われている場合、その場所のユーザーはログオンできなくなります。セキュリティで高度に保護された環境では、このような制約が必要な場合がありますが、ほとんどの場合、ドメイン コントローラが利用できない場合でも業務を継続するのが一般的です。その場所のドメイン コントローラの交換は不可能または望ましくない場合、その場所のコンピュータがポリシーを受信しないようにすることが望ましいことがあります。また、ドメイン コントローラの配置が問題になるのは、低速リンクがかかわる場合です。クライアントと認証ドメイン コントローラ間のネットワークのリンク速度が 500 kbps を下回る場合、管理用テンプレート (レジストリ) 設定とセキュリティ設定のみが適用されます。そのほかのグループ ポリシー設定は、ソフトウェア配布とフォルダ リダイレクトを含め、いずれも既定では適用されません。管理者は、GPO のユーザーとコンピュータの両方に対するポリシー設定を通して低速リンクのしきい値を次のポリシー設定で変更できます。ただし、その場所にローカルのドメイン コントローラを設置する方がより適切な場合があります。
[ユーザーの構成 (および、コンピュータの構成)¥管理用テンプレート¥システム¥グループ ポリシー]
メモ : ソフトウェアのインストール、フォルダのリダイレクト、およびログオン スクリプトが低速のネットワーク リンクのため適用できなかった場合、Windows 2000 のイベント ログには "報告されません"。運用要件の理解グループ ポリシー ソリューションを設計する場合、技術的なソリューションだけでなく、ソリューションを長期的に継続できる運用手順とシステムについても考慮する必要があります。最初の手順としては、次の点を容易に識別できる有効な命名規則を採用することです。•GPO が制御する内容•GPO の目的•コンピュータ、ユーザー、またはその両方に適用するかどうか•ローカル コンピュータ、サイト、ドメイン、または組織単位に割り当てるかどうかメモ : 長期的にもサポート可能とするには、有効な命名規則が不可欠です。Windows 2000 では、GPO の "編集" や "リンク" の権限を別のサポート グループに委任できますが、ポリシー設定や GPO を複製されないようにするにはどうしたらよいでしょうか。適切な管理が行われていないと、委任された管理者が会社の基準に反する GPO を作成したり、ほかの人が設定したものと競合するポリシー設定を含む GPO を作成する可能性があります。最悪の場合、ユーザーのデスクトップ環境を破壊するおそれもあります。このような事態が発生すると、ヘルプ デスクやサポートへの問い合わせが増加し、問題のトラブルシューティングが困難となり、さらに TCO が大幅に増加することにもなりかねません。このような事態を避けるには、グループ ポリシーにかかわる運用手順を作成して、変更には承認を必要とし、また厳格に管理されることを保証する必要があります。メモ : 日常の運用にかかわる主な要件として、構成管理データベース (CMDB : Configuration Management Database) があります。CMDB はグループ ポリシーの一部として提供されるものではありませんが、Microsoft Access または Microsoft Excel を利用して作成することができます。図 2 に示すとおり、このデータベースには作成した各 GPO に関する情報、つまり名前、リンクしているコンテナ、含まれるポリシー設定、および [上書きなし] などの適用している特別なオプションを含める必要があります。ユーザーやコンピュータに選択的に GPO を適用するポリシー フィルタを使用している場合は、この点も記録します。図 2: CMDB に記録されるグループ ポリシー情報図 2 に示すようなデ−タベ−スを、問題のトラブルシューティングや診断に使用できます。この例では、ワークステーションの組織単位に割り当てた既定の GPO に [上書きなし] を定義しています。また、デスクトップの壁紙を変更するポリシー設定を Finance と Accounts の GPO に設定していますが、これらの設定は無視されます。これは、既定の GPO に割り当てた [上書きなし] オプションが優先されるからです。メモ : このデータベースが問題のトラブルシューティングと診断に役に立つのは、データベースに最新の状態が反映されている場合に限られます。グループ ポリシーへの変更は、既存のポリシー設定の修正および GPO の新規作成を含め、すべて記録する必要があります。GPO の作成やリンク権限をほかの人に委任している場合は、その人が行った変更分も確実にデータベースに記録されるようにする必要があります。(構成管理データベースを使用してグループ ポリシーをサポートする方法の詳細は、このガイドの「構成管理」を参照してください。)管理者が必要な承認なしには新しいグループ ポリシー オブジェクトを導入できないようにするには、グループ ポリシー オブジェクトをサイト、ドメイン、または組織単位に "リンク" 権限を削除する必要があります。また、既存の GPO に対する "編集" 権限を削除することも検討します。このような権限削除の実施に際しては、管理者は、グループ ポリシーを修正できる変更アクセス許可を、変更を管理する委員会から取得する必要があります。変更内容が承認された場合、変更作業中に必要なアクセス権限およびアクセス許可を認めることができます。このようにすることで、グループ ポリシーへの変更を確実に CMDB に記録させることもできます。また、新しいグループ ポリシー オブジェクトはすべて既定では無効となるように作成し、作成したポリシーを明示的に "有効" にすることを管理者に強制する手順を確実に実施する必要があります。この追加の手順は、効果的なチェックポイントとして機能し、またサイト、ドメイン、または組織単位内のすべてのオブジェクトに新しいポリシーが誤って適用されないようにするのにも役に立ちます。次の設定を変更すると、このオプションを選択できます。
組織によっては、グループ ポリシーのそれぞれの側面を別のチームが担当する場合があります。たとえば、ソフトウェアのインストール チームは、グループ ポリシーの Microsoft 管理コンソール (MMC) スナップインにある "ソフトウェア インストール (ユーザー)" および "ソフトウェア インストール (コンピュータ)" 部分に関与します。このチームが、コンピュータのセキュリティ、フォルダ リダイレクトなど、ほかの設定に関与する必要性はあまりありません。混乱を避け、複雑さを排除し、またエラー発生の可能性を抑えるために、各管理者について、変更権限を認めているグループ ポリシー部分のみに、権限を制限することを考慮します。次のコマンドを使用すると、Admin UI を制限できます。
メモ : チームによっては、複数の種類の拡張スナップインにアクセスする必要があります。ソフトウェアのインストール チームは、アプリケーション固有の管理用テンプレートを修正できる権限が必要となることが多く、またファイル システムやレジストリのアクセス許可を変更する必要になることもあります。相互運用性の把握Windows 2000 のグループ ポリシーは、Windows 2000 または Windows XP を実行しているコンピュータのみに適用されます。メモ : Windows XP クライアントに対しては多くの追加のポリシー設定を利用できますが、Windows 2000 ではこれらのポリシー設定は無視されます。Microsoft Windows NTｮ、Windows 95、または Windows 98 を実行しているコンピュータは、コンピュータ アカウント (Windows NT 4.0 の場合) とログオン ユーザー アカウントが Windows 2000 ドメインにあったとしても、"システム ポリシー" を適用します。コンピュータが Windows 2000 (または、Windows XP) を実行していて、コンピュータとログオン ユーザーの "両方の" アカウントが Windows 2000 ドメインにある場合は、GPO にあるコンピュータとユーザーの両方の部分が処理されます。ログオン ユーザー アカウント、またはコンピュータ アカウントのどちらかが Windows NT 4.0 ドメインにある場合は、そのドメインにあるこれら 2 つのオブジェクトの一方のシステム ポリシーが処理されます。このドメインは、コンピュータ オブジェクトまたはユーザー オブジェクト (または、両方) があるドメインとなります。Windows NT 4.0 のシステム ポリシーと Windows 2000 のグループ ポリシーがコンピュータに適用されている混在環境での問題の識別とトラブルシューティングは、困難で時間がかかる可能性があります。可能であれば、コンピュータ アカウントとユーザー アカウントを両方とも Windows 2000 ドメインに移動してください。グループ ポリシーの限界の理解すべての技術的ソリューションと同様に、グループ ポリシーにも限界があるので、グループ ポリシーでうまく処理できることと対応策を講じなければならないことがあることを理解し、必要に応じてほかの製品を使用して目的を達成するという現実的な心構えが必要です。実装する予定のポリシー設定を注意深く検討し、既知の問題は 1 つも残さないようにする必要があります。これには、複雑であったり、通常では使用しないようなポリシー設定や運用があるかどうか、Microsoft サポート技術情報の Knowledge Base を調べることをお勧めします。グループ ポリシー設定に対する変更は、直ちにユーザーのデスクトップに反映されるものではありません。グループ ポリシー テンプレート (GPT) とグループ ポリシー コンテナ (GPC) が適切なドメイン コントローラにレプリケートされるのを待つ必要があります。ポリシーの変更が集中的に管理されている場合、[Active Directory サイトとサービス] MMC で定義した "複製スケジュール" により、レプリケーション プロセスが非常にゆっくり行われる可能性があります。レプリケーションの問題に対処するには、ユーザーに最も近いドメイン コントローラに接続し、構成変更をローカルで行います。また、ポリシーの更新間隔も、変更をグループ ポリシー オブジェクトに適用する速度に影響します。既定では、Windows 2000 Professional やメンバ サーバーは、グループ ポリシー オブジェクトに対する変更があるかどうか、90 分ごとに調べます (最大 30 分までのランダムなオフセットを使用します)。Windows 2000 のドメイン コントローラは、5 分ごとに調べます。このポーリングの周期は変更できますが、この変更については "推奨していません"。ネットワークのトラフィックの増加や、ドメイン コントローラに余計な負荷がかかるおそれがあるからです。ローカル ドメイン コントローラに GPO が到着していても、自動バックグラウンド更新の発生を待たず更新する必要がある場合は、次のコマンドを使用してユーザー (または、コンピュータ) のポリシー設定を更新します。
この対処法は、ユーザーがコマンド ラインにアクセスできること前提にしています。グループ ポリシーの適用を通してコマンド ラインにアクセスできないようにしている場合は、ユーザーは、いったんログオフしてからログオンするか、コンピュータを再起動してポリシーの変更を反映させる必要があります。メモ : ポリシー設定によっては、ユーザーがいったんログオフしてから再びログオンしないと反映されません。この種のポリシー設定には、フォルダ リダイレクトやソフトウェア アプリケーションのアドバタイズがあります。コンピュータにアドバタイズされたソフトウェア アプリケーションは、コンピュータを "再起動" しないと反映されません。グループ ポリシーを使用してソフトウェア アプリケーションを正常にインストールすることは可能ですが、関連する問題点を理解している必要があります。グループ ポリシーでは、(ファイル レプリケーション サービスまたは Systems Management Server が使用されて) ソフトウェアのソース ファイルが利用可能であることが前提となり、さらにアプリケーションはコンピュータを再起動するか、ユーザーがログオンした場合にのみインストールすることができます。後者の場合、サービス レベル契約の "ログオンに要する時間" および "デスクトップの表示に要する時間" に抵触する可能性があります。この点から、グループ ポリシーを使用してデスクトップの構成、およびシステム セキュリティとアクセス許可の設定を行い、次に Systems Management Server を使用してソフトウェア アプリケーションを配布する方法を採用することもできます。この方法では、帯域幅を制御でき、また通常の業務時間外にアプリケーションのインストールをスケジュールできます。また、Systems Management Server には、有効な機能が数多くあり、たとえば、ハードウェアおよびソフトウェアのインベントリ、ソフトウェア インストール ステータス レポート、およびクライアント ワークステーションのリモート コントロールがあります。これらの機能は、Windows 2000 には "用意されていない" ものです。ツールの選択やツールの併用は、要件、環境、および Systems Management Server が備える追加の機能が必要かどうかにより異なります。そのほかの要因以上ですべてをとりあげたわけではなく、組織ごとに固有の要因が数多くあります。たとえば、ユーザーのスキルと能力、組織内部の力関係、プロジェクトの推進体制、時間の制約、予算などがあります。これらの問題は、いずれもグループ ポリシーの設計に大きく影響し、技術的な要件や目的とは別に配慮する必要があります。ページのトップへ構造化設計概要これまでグループ ポリシーの目的を文書化し、サービス レベル契約、Windows 2000 の設計、運用要件、相互運用性、およびグループ ポリシーの限界を考慮してきました。ここでは、設計計画のさまざまな段階について説明し、追加情報を提供する Web サイトへのリンクも付け加えています。設計プロセスでは、次の作業を行います。•グループ ポリシー スナップイン拡張の選択•手法の選択•グループ ポリシー オブジェクト数の決定•グループ ポリシー オブジェクトの割り当て先の決定•[上書きなし] オプションの使用場所の特定•既定値の設定場所の特定•ユーザーまたはコンピュータの種類に基づくポリシーの特定•インストールするソフトウェアおよびインストール先の特定グループ ポリシー スナップイン拡張の選択グループ ポリシーの設計計画を開始する前に、グループ ポリシー スナップインのどの拡張が設計に有益かを確認し定義します。適用可能な拡張を初期段階で判断することを推奨します。次の表でグループ ポリシー スナップイン拡張の種類について説明します。各種類の詳細については、ホワイト ペーパー「Windows 2000 グループ ポリシー」 http://www.microsoft.com/japan/windows2000/techinfo/howitworks/management/grouppolwp.asp を参照してください。グループ ポリシーの設定説明レジストリ管理用テンプレートこの拡張には、レジストリ ベースのポリシー設定がすべて含まれます。これらのポリシーを使用すると、レジストリ ベースのポリシーを提供するデスクトップ、オペレーティング システム コンポーネント、およびアプリケーションの動作と外観を制御するレジストリ設定を指定できます。リモート インストール サービス (RIS)RIS を使用すると、リモート オペレーティング システム インストール機能のクライアント コンピュータに表示される動作を制御できます。フォルダ リダイレクトフォルダ リダイレクトを使用すると、Windows 2000 の特別なフォルダを既定のユーザー プロファイルの場所からインターネット上の別の場所にリダイレクトできます。スクリプトスクリプトを使用すると、コンピュータのスタートアップ/シャットダウン時のタスク、およびユーザーのログオン/ログオフ時のタスクを自動化できます。セキュリティこの拡張を使用すると、グループ ポリシー オブジェクトのスコープ内にあるコンピュータとユーザーのセキュリティ オプションを設定できます。ソフトウェアのインストールソフトウェアのインストール スナップインを使用すると、組織内のソフトウェアを一元管理できます。また、さまざまなユーザーやコンピュータに対するソフトウェアの割り当てと公開ができます。Internet Explorer のメンテナンスこの拡張を使用すると、Internet Explorer の管理とカスタマイズができます。Windows 95、Windows 98、および Windows NT 4.0 クライアント用の設定をエクスポートするのに使用できます。管理者は、ブラウザの UI、接続、URL、プロキシ設定、セキュリティ ゾーン、およびお気に入りのオプションを設定できます。メモ : 管理用テンプレート ファイル (.adm) を作成すると、グループ ポリシー スナップインの現在の機能を拡張できます。詳細については、ホワイト ペーパー「Implementing Registry-Based Group Policy」 http://www.microsoft.com/WINDOWS2000/techinfo/howitworks/management/rbppaper.asp (英語) を参照してください。すべてのグループ ポリシー プロジェクトで、以上の数多くの設定を実施する "必要があります"。一部は既定値として設定することもできますが、そのほかの設定についてはコンピュータとユーザーの種類、機能、および役割に応じてコンピュータとユーザーの環境を構成します。また、ソフトウェア アプリケーションのインストールや構成にポリシー設定が必要な場合もあります。グループ ポリシーの設計には、次の要件を考慮してください。•実施するポリシー設定を選択し、適用対象のユーザーやコンピュータのグループを決定する。これらのポリシー設定を含む GPO を作成し、[上書きなし] とマークする。また、適切なサイト、ドメイン、または組織単位にリンクする。•既定値とするポリシー設定を決定し、その設定を実装する GPO を作成する。これらをサイト、ドメイン、または組織単位にリンクする。•組織内のユーザーとコンピュータの種類を調査し、その種類、役割、または機能に応じた環境を構成する GPO を作成する。作成した GPO を組織単位構造 (または、サイト) にリンクし、Windows 2000 のセキュリティ グループを使用して、特定のユーザーまたはコンピュータにこれらの GPO を選択的に適用する。•Systems Management Server を使用しない場合は、ソフトウェア アプリケーションをインストールする GPO を作成する。作成した GPO を組織単位構造 (または、サイト) にリンクし、Windows 2000 のセキュリティ グループを使用して、特定のユーザーまたはコンピュータにこれらの GPO を選択的に適用する。メモ : ソフトウェア アプリケーションのインストール、あるいは、コンピュータやユーザーの種類、役割、機能に応じてコンピュータまたはユーザーの構成を行うグループ ポリシー オブジェクトは、サイト、または組織単位構造にリンクする必要があります。これらはドメインにリンクすることはできません。実施するポリシー設定または既定値を定める GPO がソリューションの適用期間中に変更される頻度は、あったとしても少ないので、このような方法をとることでグループ ポリシーにより長期的な TCO の利点がもたらされます。採用する手法の計画グループ ポリシーの使用は、組織の総保有コスト (TCO) を削減する重要な要素となりますが、その効果は、グループ ポリシー設計を綿密に計画した場合にのみ実現可能です。ソリューションの設計が不十分だと、影響が少ない場合でも管理者は問題のトラブルシューティングと変更管理に多大な時間をとられることになります。最悪の場合、ユーザーが自分の役割を遂行するのに必要なツールやソフトウェア アプリケーションを利用できなくなります。グループ ポリシーの設計については、機能が 1 つのポリシー、複数の機能を持つポリシー、管理チームに基づくポリシーの作成など、既に多くの手法が記述されています。(詳細については、『Windows 2000 システム展開ガイド』 の 「第 23 章 クライアント管理と標準構成の規定」 および 「第 24 章 変更と構成管理の適用」 を参照してください。)
これらの方法の中には、ほかよりも柔軟な手法があり、また一元管理をめざす組織に適した手法や管理を委任する組織に適した手法もあります。ポリシー設定を変更し、新しい GPO を導入することも避けられません。組織の内部構造の変更に対処しなければならないこともあります。設計が "変更" にうまく対応できるかどうかにより、TCO 全体への効果が決まります。運用環境要件への対応、変更に対する対応能力と変更の実装に必要な時間と手間をいかに最小限にとどめるかということ、そして問題のトラブルシューティングとその解決を迅速に行える能力について考慮すると、これから採用するグループ ポリシーの設計手法は、短期的な技術的目的のみに対応した手法とはかなり異なることになります。メモ : 設計手法をどれだけ入念に計画し体系化したとしても、またソリューションが技術的にはどれほど優れていたとしても、グループ ポリシーを制御する "変更管理" 手順を組織が実施していなければ、TCO の削減に成功することはできません。管理者が、管理されることなくポリシー設定への変更を行ったり、ほかの人に通知することなく新たに GPO を作成したりすると、運用環境に重大な危険をもたらすおそれがあります。また、ポリシー設定への変更が管理されずに行われる環境で発生する問題のトラブルシューティングと解決は、困難で時間を要するものとなります。グループ ポリシー オブジェクト数の決定必要となるグループ ポリシー オブジェクトの数は、前に述べた設計手法と環境の複雑さにより異なります。また、プロジェクトの目的と範囲によっても異なります。たとえば、作成する計画がグループ ポリシーを使用してソフトウェア アプリケーションを配布するものである場合、Systems Management Server にこのタスクを行わせた場合よりも多くのポリシーが必要となります。複数ドメイン フォレストがある場合は、各ドメインで必要となる GPO の数は異なることがわかります。基幹業務を行う環境をサポートする Windows 2000 ドメインには、通常、ブランチ オフィス ドメインよりも多様なユーザーを抱えることになるので、より多くの数の GPO が必要となります。1 つの組織をサポートするのに必要な GPO の数は、通常、技術的な問題とはなりませんが、運用スタッフの作業量を増加させることになります。特に、複数のグループ ポリシー オブジェクトで構成オプションが設定されている場合は負荷が大きくなります。環境内の GPO の数が増加するほど、負荷が増大する可能性が高くなり、また運用面に要件を反映させる作業を急ぐ必要があります。管理を単純化するには、対象となるすべてのコンピュータへの GPO の実装に継承を使用することで、たった 1 つの GPO にある構成設定を変更すればよいように検討する必要があります。この方法が、いつも可能であり、または現実的であるとは限らないので、更新内容を関連するすべてのグループ ポリシーに確実に適用するために、原則に対する例外事項を変更管理データベースに記録する必要があります。また、コンピュータに適用する GPO の数により、ユーザーのログオンに要する時間も増加する可能性があることを考慮する必要があります。ただし、コンピュータのスタートアップとユーザーのログオン時間に "大きな違い" をもたらすのは、適用する GPO 内のポリシー設定です。作成したグループ ポリシー ソリューションをラボ環境でテストし、定義したポリシー設定が、"ログオンに要する時間" および "デスクトップの表示に要する時間" に関するサービス レベル契約に違反しないようにする必要があります。グループ ポリシー オブジェクトの割り当て先の決定既定では、グループ ポリシー オブジェクトは継承され累積的に、Active Directory コンテナ内のすべてのコンピュータとユーザーに影響します。GPO は、サイト、ドメイン、組織単位の順に処理されます。既定の継承メソッドは、グループ ポリシーを評価することで、コントロールやユーザーから最も遠い Active Directory コンテナから開始されます。既定では、[上書きなし] オプションが設定されていない限り、コンピュータやユーザーに "最も近い" Active Directory コンテナが、上位レベルの Active Directory コンテナに設定されているグループ ポリシーを上書きします。メモ : 1 つの Active Directory コンテナには複数の GPO をリンクできますが、適用順序 (優先順位) に注意してください。Admin UI に表示される一覧の最上位にある GPO は、"既定で" 優先されます。1 つ以上の GPO に [上書きなし] オプションが設定されている場合、最上位の [上書きなし] オプションが優先されます。GPO のサイトへのリンク特定の場所 (例、エジンバラ) にあるコンピュータやユーザーにのみ適用するポリシー設定が多い場合には、ユーザーに run コマンドの実行を許可します。これらの設定は、サイト ベースのポリシーに含めることを検討してください。このサイト (フォレスト全体) 内のすべてのコンピュータまたはユーザーにポリシー設定を適用する場合、サイトに GPO をリンクすることが適切です。ただし、1 つのドメインのメンバのみに設定を適用する場合は、サイトに GPO を割り当てるより、ドメインまたは組織単位の構造に GPO を割り当てる方が適しています。GPO のドメインへのリンクドメイン ベースの GPO は、会社の基準を強制するのに組織内のセキュリティ チームに利用されることがよくあります。このような GPO は、通常 [上書きなし] オプションを有効にして作成され、ドメイン内に作成されているすべての組織単位に適用されます。名前が示すように "Default Domain Policy (既定のドメイン ポリシー)" GPO はドメインに割り当てられますが、この GPO を変更する際は、必ず Microsoft サポート技術情報の Knowledge Base の文書 Q259576 http://support.microsoft.com/support/kb/articles/q259/5/76.asp (英語) の指示に従って行ってください。 ドメイン全体に及ぶポリシー設定を指定したり、修正する必要がある場合は、カスタム GPO を作成し、既定のドメイン ポリシーよりも優先度を高くしてください。GPO の組織単位構造へのリンク作成する GPO のほとんどは、最も柔軟性が発揮される組織単位構造に割り当てることになります。この構造内でユーザー オブジェクトとコンピュータ オブジェクトを分離すると、GPO の適用しない部分を "無効" にすることもできます。このようにしておくと、トラブルシューティングにも役立ち、GPO の適用に要する時間も大幅に短縮できます。メモ : ダウンレベルのアプリケーション プログラミング インターフェイス (API) は、"コンピュータ" コンテナに新しいコンピュータ アカウントを設定し、また "ユーザー" コンテナに新しいユーザー アカウントを設定します。これらのコンテナにグループ ポリシー オブジェクトを適用することはできません。グループ ポリシーをすべてのコンピュータとユーザーに確実に適用するには、これらのコンテナを定期的にチェックし、新しいコンテナがあればそれらを組織単位構造の適切な部分に移動する必要があります。GPO のスタンドアロン コンピュータへの適用ドメインに参加していないコンピュータに対しては、ローカル グループ ポリシー オブジェクト (LGPO) を作成する必要があります。このコンピュータを後で Windows 2000 ドメインに参加させる場合、作成した LGPO を削除し、サイト、ドメイン、または組織単位に割り当てた GPO を使用してこのコンピュータを構成する必要があります。このコンピュータを Windows NT 4.0 ドメインに参加させる場合は、作成した LGPO を削除し、Windows NT 4.0 のシステム ポリシーを使用する必要があります。LGPO の問題は、"各" コンピュータにポリシーを定義しなければならないことです。複数のコンピュータ上で設定を変更することは、時間がかかる作業であり、エラーの発生原因ともなります。さらに、ポリシーの適用に伴う問題の識別と解決は、より困難な作業となります。GPO の選択したグループへの適用 (フィルタ処理)GPO を選択的に適用するには、そのポリシーに対する読み取り許可と適用許可を与えたセキュリティ グループを作成します。グループ ポリシーを適用させるには、ユーザー オブジェクトとコンピュータ オブジェクトにグループ ポリシーの読み取り許可と適用許可が必要です。特定のグループに GPO を適用しない場合は、この 2 つのアクセス許可を両方とも削除する必要があります。読み取り許可を削除すると、クライアント側拡張がポリシーをスキャンする必要がなくなるので、ポリシーの適用が早くなります。メモ : 既定では、Authenticated Users グループには、すべての新しい GPO に対するグループ ポリシーの読み取り許可と適用許可が与えられています。管理者アカウントとコンピュータ アカウントは常にこのグループの一部なので、これらの許可を削除すると、望ましくない結果を招くおそれがあります。新しいすべての GPO については、グループ ポリシーの [セキュリティ] タブで [Authenticated Users] グループを削除することをお勧めします。各 GPO に対して、GPO を適用する必要があるコンピュータ アカウントとユーザー アカウントをメンバとして含む Windows 2000 のカスタム セキュリティ グループを作成します。次に、このグループにグループ ポリシーの読み取り許可と適用許可を与えます。メモ : ローカル グループ ポリシー オブジェクトをフィルタ処理して適用するには、ローカル ワークステーション上の %Systemroot%･System32･GroupPolicy フォルダへのアクセス許可を "拒否" する必要があります。LGPO を使用する必要がある場合は、このメカニズムを使用してポリシーが管理者に適用されないようにします。LGPO の使用は、ポリシー設定を定義する必要があってもコンピュータがドメインに参加していない場合に限定してください。[上書きなし] オプションの使用場所の特定業務要件に "ブランチ ドメインのすべてのユーザーは、非アクティブ状態になった 15 分後に起動する標準のスクリーン セーバーを使用する必要がある" と規定されている場合は、ポリシーを強制する適切な例となります。この場合、このドメイン内のすべてのユーザーにポリシー設定を適用し、ほかのグループ ポリシー オブジェクトが定義した設定を上書き (置き換え) できないようにすることが可能です。メモ : ポリシー設定を強制するには、GPO にポリシーを設定し、その GPO の [上書きなし] オプションを選択します。[上書きなし] オプションを指定すると、その GPO 内のすべてのポリシー設定が下位レベルの GPO によって上書きされることを防止できます。強制しなければならないポリシー設定の大部分は、プロジェクトの初期段階で特定した業務要件により定義されるものですが、社内のセキュリティ基準を適用したり、委任先の管理者が利用可能な構成オプションの数を制限するために、追加設定の作成が必要になる場合があります。[上書きなし] オプションを強制するために有効にしたグループ ポリシーを Users 組織単位に割り当て、非アクティブ状態になった 15 分後に画面をロックするスクリーン セーバーをすべてのユーザーに設定する例を図 3 に示します (使用するスクリーン セーバー自体は、ここでは指定されていません)。図 3: ワークステーションの管理目的で強制するポリシーの使用図 3 の例では、会社の標準のスクリーン セーバーは、会社のロゴ付きの 3D 飛行物体ですが、このスクリーン セーバーは、ドメイン コントローラやサーバーに頻繁にログオンする管理者には不適当です。3D 飛行物体のスクリーン セーバーは、その画像を表示するのに CPU の使用率が高く、サーバー パフォーマンスにとって好ましいものではありません。管理者には "ログオン" スクリーン セーバーの使用を強制し、ユーザーには 3D 飛行物体のスクリーン セーバーの使用を強制するには、図に示したように追加の GPO を作成する必要があります。追加した GPO は、ほかの GPO でこれらの設定が変更 (上書き) されないようにする必要があります。既定値の設定場所の識別業務要件に "承認されている場合を除いて、すべてのユーザーは、コマンド プロンプトおよびレジストリ編集ツールにはアクセスできない" と規定されている場合は、既定値を使用する場所として適切な例となります。この場合、すべてまたはサブセットのユーザーから機能を削除し、例外的なユーザーに対してはその機能の利用を許可するとします。このような設定は、その GPO に対するグループ ポリシーの読み取り許可と適用許可を持っているグループからユーザーを削除することでも可能ですが、必ずしも望ましい方法ではありません。その GPO に関連する設定がまだほかにも含まれている可能性があるからです。図 4: グループ ポリシー利用による既定値の設定危険性があり問題を引き起こしやすいと考えられるコマンド プロンプトとレジストリ編集ツールの利用をすべてのユーザー アカウントから削除している設定例を図 4 に示します。管理者にはこれらのツールが "必要" なので、既定のユーザー ポリシーに対するグループ ポリシーの適用許可があるグループから管理者を削除したり、Admin 組織単位についてはポリシーを継承しないオプションを使用して既定のユーザー ポリシーが継承されないようにすることもできますが、その GPO にはまだ関連する設定がほかにも含まれる可能性があります。管理者がコマンド プロンプトとレジストリ編集ツールを利用できるようにするには、既定のユーザーに対する設定を上書きする GPO (Admin ユーザー ポリシー) を Admin 組織単位に割り当てます。メモ : 管理者がポリシーを継承しないオプションを使用するのは、トラブルシューティングや障害の発見が困難になる可能性があるため、必要な場合のみに限定する必要があります。。Business Banking に属するユーザーは、ライセンスされたアプリケーションを実行する場合などにコマンド プロンプトにアクセスする必要があるので、これを可能にする GPO を作成します。ただし、Business Banking の GPO は既定のユーザーに対する設定を上書きしていないので、レジストリ編集ツールへのアクセスは、既定のままで拒否されています。実際には、既定の GPO は、前に示した単純な例よりも多くの設定や構成オプションから構成されます。設定する既定値は、会社の要件、および組織内のほかの管理者の熟練度やスキル レベルにより異なります。一般に、次の点を達成する既定のグループ ポリシー オブジェクトを作成することが考えられます。•ユーザーに対して、危険性があり問題を引き起こしやすいと考えられる機能をすべて削除し、フォルダ リダイレクトなどを構成する。•メンバ サーバーとワークステーションに対して、アクセス権、セキュリティ設定、およびファイル システムとレジストリのアクセス許可を定義する。•ドメイン コントローラに対して、アクセス権、セキュリティ設定、およびファイル システムとレジストリのアクセス許可を定義する。Default Domain Controllers Policy (既定のドメイン コントローラ ポリシー) の設定は、変更しないことを推奨します。このポリシー設定を部分的に変更する場合は、新しい GPO を作成し、この GPO を Domain Controllers 組織単位に割り当てます。次に、Default Domain Controllers Policy よりも高い優先順位をこれに与えます。既定のポリシー設定を実装するために作成した GPO は、ドメインやサイトではなく、組織単位の構造に割り当てることが予想されます。組織単位モデルが、ユーザー、ワークステーション、およびサーバーに基づいて構造化されている場合 (図 5 を参照)、既定の設定を特定するプロセスが容易になり、またポリシーの適用しない部分を "無効" にすることも可能になるので、ポリシーの適用が速くなります。図 5: 既定の GPO が割り当てられた組織単位構造の例メモ : 制限されたグループのメンバシップ、ファイル システム、およびレジストリ キーへのアクセス許可に既定値を設定する場合、これらの設定は、"最後に記述された内容が適用される" 規則に従って適用されることを理解している必要があります。これらの設定は、マージ (結合) されません。たとえば、ローカル Power Users グループのメンバシップをテクニカル サポート グループおよびヘルプ デスクとして定義する既定のワークステーション GPO を作成するとします。この場合、Business Banking は、Business Banking サポート グループをリストに追加することを希望し、そのための新しい GPO を作成する可能性があります。この新しい GPO で 3 つのグループ "すべて" が Power Users のメンバであると指定されていなければ、Business Banking サポート グループのみが、影響を受けるワークステーション上で Power Users の権限を持つことになります。ユーザーまたはコンピュータの種類に基づくポリシーの特定前に説明した強制する既定のグループ ポリシー オブジェクトには、ディレクトリ内の、すべてではないにしても、ほとんどのコンピュータ オブジェクトとユーザー オブジェクトにわたる共通のポリシー設定を定義します。また、ユーザーの役割と機能に応じたユーザーの環境を構成し、さまざまな種類のワークステーションとサーバー向けのセキュリティなどの構成設定を定義する GPO を定義する必要もあります。メンバ サーバーメンバ サーバーとして、Exchange 2000 サーバーからターミナル サーバーやファイル サーバー、プリント サーバーまで、さまざまな種類のサーバーを使用している場合、各種類のサーバーの設定を構成するさまざまなグループ ポリシー オブジェクトを作成することが必要になることがよくあります。ただし、プロジェクトによっては、既定のサーバーのポリシーが提供する既定値で十分な場合もあります。たとえば、管理を委任したモデルでは、"制限されたグループ" の設定を使用して、特定のコンピュータ上で管理機能を実行できるユーザーのリストを定義することも可能です。ターミナル サーバーに対しては、さまざまなユーザーがコンソールにログオンした場合でもコンピュータの構成が危険にさらされないようにすることも可能です。これを実現するには、ループバック処理の使用を考慮する必要があります。詳細については、Microsoft サポート技術情報の Knowledge Base の文書 Q260370 http://support.microsoft.com/support/kb/articles/q260/3/70.asp (英語) を参照してください。トラブルシューティングと問題解決を簡単にするには、さまざまな種類のサーバーを別々の組織単位に配置し、図 6 に示すように、グループ ポリシー オブジェクトを割り当てる必要があります。図 6: グループ ポリシーのメンバ サーバーへの割り当てメンバ サーバーが組織の個々の部分で管理される、管理を委任したモデルでは、特定のポリシー設定用に既定値を作成し (または、必要に応じて "強制する" GPO を使用して)、委任した管理者に、各自の要件に応じてサーバー環境を調整するのに必要なポリシー設定を上書きできるようにすることを考慮することもできます。図 6 では、Business Banking が独自の Microsoft SQL Server・環境を管理し、グループ ポリシーを使用して、そのコンピュータへのログオン、ソフトウェアのインストール、およびサービスの開始と停止を可能とする権限を管理者に認めています。メモ : 図 6 では、組織単位あたり GPO が 1 つだけの例を示しています。実際には、ターミナル サーバーのそれぞれのグループに割り当てる設定は 2 つ以上必要となる可能性があります。これを行うために別の組織単位を作成することもできますが、このような作成は、グループ ポリシーの適用が容易になる場合や、管理の委任が必要な場合に限って行うようにしてください。ユーザーの状況ユーザーの状況により、さまざまな設定が必要になることもあります。ユーザーによっては、業務内容や組織内における職位のために、ほかのユーザーよりも柔軟で利用可能範囲の広い設定が必要になります。ユーザーの種類またはカテゴリごとの適切なポリシー設定、利用しなければならないデスクトップの要素、および多くの MMC のうち利用可能としなければならないものの確立、を行う必要があります。その後、GPO を 1 つ、またはセットを作成して実装します。それぞれに合ったポリシー設定の一覧を作成するには、ユーザーの業務上の機能と役割を調査する必要があります。たとえば、コール センターのユーザーは、通常、アプリケーションを 1 つだけ使用して業務時間のほとんど過ごします。彼らに Windows 2000 コントロール パネルへのアクセスを認めると、問題が発生する可能性があるばかりでなく、ユーザーが各自の環境を変更できる場合には、サポートへの問い合わせも増加することが考えられます。ホワイト ペーパー「Implementing Common Desktop Management Scenarios」(英語) は、組織内のユーザーの種類とカテゴリを識別し、適切と思われるポリシー設定を特定するのに参考になります。このホワイト ペーパーは、http://www.microsoft.com/windows2000/techinfo/howitworks/management/grouppolicy.asp にあります。 この文書に記述されているシナリオ、GPO のサンプル、およびポリシー設定は、あくまでもガイドであり、対象の環境に合わせて変更する必要があることに注意してください。運用面からいえば、ユーザーの役割と機能に基づいてポリシー設定を割り当てると、ユーザーには各自の役割を遂行するのに必要な機能のみへのアクセスを許可することになるので、サポートへの問い合わせを大幅に減少させることができます。ただし、ユーザーが割り当てられたコンピュータ以外の制約が異なる別のワークステーションを使用すると、トラブルシューティングや障害の発見が困難になります。ワークステーション前の項で特定したユーザーの場合と同様に、異なるコンピュータには、異なるポリシー設定が必要です。たとえば、図書館に設置されているワークステーションの場合、ログオンしているユーザーに関係なく図書館の閲覧アプリケーションのみを実行する必要があります。ただし、オープンなオフィス環境では、ログオンしているユーザーのニーズに応じて、デスクトップを再構成する可能性があります。このような相違に対応するには、各ワークステーションが実行する役割の種類に応じて、ワークステーションを構成する GPO を作成する必要があります。この点をよく表す業務要件としては、"すべてのワークステーションで RAS および接続マネージャ サービスを無効にする" があります。このポリシーは、ダイヤルイン接続を行うのにこれらのサービスを必要とするラップトップ コンピュータに対しては明らかに不適切です。したがって、ラップトップ用のポリシー設定ではこれらの機能を有効にする必要があります。メモ : グループ ポリシーを通すと、ワークステーションの外観と機能を変更できます。たとえば、ユーザーがタスク ステーションにアクセスすると、そのインターフェイスが普段使用しているデスクトップ環境とはかなり異なることがわかります。前に説明したユーザーの場合と同様に、ホワイト ペーパー「Implementing Common Desktop Management Scenarios」では、ワークステーションの種類に基づいてグループ ポリシーを作成するガイドを提供しています。管理ユーザーやコンピュータの種類に基づく GPO は、ユーザーとデスクトップの環境を制御するのに役立ち、またサポートへの問い合わせを少なくできます。ただし、数多くの GPO を作成すると、管理の難しい複雑な環境をもたらすことになります。ユーザーやコンピュータの種類の増加に対応するために GPO の数を増加させていくと、障害の発見や問題の解決が困難になるおそれがあります。前に述べたように、環境をすべて文書化し、ポリシーに対するすべての変更をもらさず CMDB に記録することが不可欠です。メモ : 組織の別の部門に対するデスクトップとユーザーの構成要件が存在する可能性もあります。ローカルに配置された管理者は、管理するコンピュータとユーザーの設定が適切なものとなるよう、それぞれの条件において設定を調整できることを希望することがあります。シナリオで定義されたポリシー設定は "強制" されてはいないので、管理され記録を必須とする手続きに従う限り、各管理者にある程度任せることもできます。図 7 に示す例では、すべてのユーザーは、比較的少数のオプション (例、ネットワーク構成の変更権限) を削除した規制の少ない管理シナリオを使用することが認められています。また、このシナリオは、Business Banking に属するユーザーにも適していますが、run コマンドを実行できないようにするなど、多少の変更が必要です。したがって、追加の GPO を作成してから Business Banking の組織単位構造にリンクし、変更を加えます。図 7: グループ ポリシー シナリオの調整シナリオに基づく GPO をユーザーやコンピュータの特定のグループに適用するには、Windows 2000 のセキュリティ グループを作成し、このグループのメンバーに適切な GPO に対するグループ ポリシーの読み取り許可と適用許可の権限を与える必要があります。ほかのユーザーとコンピュータについては、これらの権限を削除します。ホワイト ペーパー「Implementing Common Desktop Management Scenarios」(英語) のプロファイルでは、管理しやすくするために "既定のワークステーション" または "既定のユーザー" の GPO を使用して、適用が必要なレジストリ、セキュリティ設定、およびアクセス許可を変更していることに留意してください。(このホワイト ペーパーは、http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/management/csws2003.mspx でご覧になれます。)また、長期的な運用およびトラブルシューティングに役立てるには、別の種類のワークステーションとユーザーをサポートするために作成したポリシーでは、必要な場合に "限定して" 既定値を変更する必要があります。インストールするソフトウェアとインストール先の特定グループ ポリシーに基づくソフトウェア ソリューションの設計を開始する前に、その設計が適切なメカニズムに基づいていることを確認してください。前に述べたように、重要な制限事項がいくつかあります。たとえば、インストールのスケジュール化、ネットワーク帯域幅の管理、またはインストールの成功/不成功のフィードバックなど、これらは行えません。また、サービス レベル契約からグループ ポリシーの使用が除外されることも考えられます。これは、グループ ポリシーを使用した方式でインストールを実行できる唯一のタイミングであるコンピュータのスタートアップ時やユーザー ログオン時に、待ち時間が発生するためです。インストールのスケジュー化を行う場合、ネットワークの利用率やハードウェア、ソフトウェアのインベントリを管理すること、またはインストール状態を監視できようにすることは、運用環境にとって不可欠なので、Systems Management Server の使用を検討する必要があります。ソフトウェア アプリケーションを配布するのにグループ ポリシーを使用する必要や予定がある場合、次の事項も考慮する必要があります。•すべてのアプリケーションがグループ ポリシーを使用してインストールできることを確認する。これは、各アプリケーション用の Windows インストーラ ファイルが用意されている必要がある、またはスナップショットやオーサリング ツールを使用して作成できる必要があるということです。レガシ アプリケーションのインストールについては .zap ファイルの使用も可能ですが、多くの運用環境にとっては制限事項が多いため適切ではありません。詳細については、Microsoft サポート技術情報の Knowledge Base の文書 JP231747 http://support.microsoft.com/default.aspx?scid=kb;JA;JP231747 を参照してください。•ソフトウェア使用許諾契約の内容を理解していることを確認する。アプリケーションのインストールに Systems Management Server やグループ ポリシーを使用するかどうかにかかわらず、ソフトウェア使用許諾契約書が意味することを理解していることが重要です。アプリケーションには、接続クライアント数によってライセンスされるものもあり、ユーザーごと、またはサイトごとにライセンスされるものもあります。アプリケーションの使用許諾契約書の内容によって、採用すべきインストール方法が決まり、グループ ポリシーがアプリケーションをコンピュータに割り当てる必要があるのか、アプリケーションをユーザーに割り当て、公開する必要があるのかが決まります。また、アクセスを制限するのにポリシーの "フィルタ処理" が必要か、およびアプリケーションをアドバタイズするグループ ポリシー オブジェクトをサイト、ドメイン、または組織単位構造に割り当てる必要があるかも判断できます。ソフトウェア アプリケーションをアドバタイズするグループ ポリシー オブジェクトは、デスクトップへのユーザー アクセスを制限するオブジェクト、またはレジストリやファイル システムのアクセス許可を設定するオブジェクトよりも変更頻度が高いことが予想されます。ソリューションを設計する場合、ソフトウェア アプリケーションを配布するグループ ポリシー オブジェクトがそのタスク専用のものかどうかを可能な限り確認してください。メモ : アプリケーションをアドバタイズする GPO は、アプリケーションに "直接" 関連するグループ ポリシー設定のみを変更する必要があり、またアプリケーションを正常に動作させるために必要な "アプリケーション固有の" レジストリ設定、またはファイルとレジストリのアクセス許可を変更する必要があります。%ProgramFiles% 内のアプリケーション フォルダは、アプリケーションによってはその保護が要件となっているので、不正なアクセスからの保護が必要な場合があります。必要なソフトウェア インストール ポリシー数ソフトウェア アプリケーションをアドバタイズする GPO は、組織単位構造のできるだけ上位に配置する必要があります。このように配置すると、組織内のすべてのユーザー (またはコンピュータ) にアプリケーションへのアクセスを容易に提供できるからです。また、アプリケーションをアドバタイズする GPO を 1 つ使用すればすむので、Active Directory の下位レベルにある複数のコンテナ内にこのような GPO を再作成する場合よりも、管理負荷を少なくすることができます。環境内にソフトウェア アプリケーションをインストールするために必要な GPO の数を最少限に抑えるには、GPO で "関連する" 複数のアプリケーションをアドバタイズすることを推奨します。たとえば、Microsoft Project をインストールしていて、多くのユーザーがほぼ常に Microsoft Visioｮ を必要とする場合は、これら 2 つのアプリケーションを 1 つの GPO にまとめる方が合理的です。複数のアプリケーションを論理的にグループ化すると、全体的な管理コストを削減できます。ただし、ソフトウェアのライセンスを追加購入することが必要になる場合があります。メモ : 管理者は、すべてのアプリケーションを単一の GPO に配置し、セキュリティ グループを使用して特定のユーザーとコンピュータにアプリケーションを選択的にアドバタイズしようとすることがあります。この方法は、多くの理由から推奨できません。主な理由としては、インストール順序を管理者がコントロールできないことが挙げられます。グループ ポリシーの Admin UI にはアプリケーションの一覧がアルファベット順に表示されますが、インストールの順序は、アプリケーションが GPO に追加された順序に基づきます。このため、あるアプリケーションがほかのアプリケーションより前にインストールされないと正常に動作しないなど、予想外の結果が発生するおそれがあります。ソフトウェア アプリケーションごとに GPO を作成する方が、柔軟性も高くなり、GPOが処理される順序を変更することで、インストールの順序をコントロールできます。ただし、各クライアントに割り当てる GPO の数が多くなれば多くなるほど、ログオンとコンピュータのスタートアップが遅くなります。規模の小さな組織では、100 種類以上のアプリケーションを使用していることはまれですが、大規模な多国籍企業では、使用しているアプリケーションの種類は相当な数になります。このような数多くのポリシーをすべて管理することは、難しく時間のかかる作業となります。ユーザーやコンピュータへのアプリケーションの割り当て特定ユーザーへのアプリケーションの割り当てや公開を行う場合、ドメイン コントローラへの接続速度が 500 Kbps 以上あるなど、ネットワークの速度が十分であれば、このようなアプリケーションはユーザーがどこでログオンしても利用可能となります。アプリケーションを "割り当てた" 場合、そのアイコンが [スタート] メニューに表示され、ユーザーがこのアイコンをクリックしたり、アプリケーションに関連付けられたドキュメントを開くと、アプリケーションのインストールが開始されます。"公開した" 場合は、これまでのように [アプリケーションの追加と削除] ウィザードを使用するか、ドキュメントの関連付けを通してアプリケーションを手動でインストールできます。メモ : この機能を使用すると、アプリケーションを複数のコンピュータにインストールすることになるので、アプリケーションをユーザーに割り当てる前に、必ずソフトウェア使用許諾契約書を確認してください。[管理の対象でなくなったときは、このアプリケーションをアンインストールする] オプションを使用しても、問題が発生する可能性があります。アプリケーションをあるコンピュータに割り当てた場合、このアプリケーションはコンピュータのスタートアップ時にインストールされ、そのコンピュータ上で "のみ" 利用可能です。この場合、ほかのコンピュータからはアプリケーションのインストールと利用ができないので、ライセンス契約の遵守は容易になります。したがって、市販されている多くのアプリケーションは、このメカニズムを使用してインストールすることが求められます。配布ポイントへのソフトウェアの配置前に述べたように、グループ ポリシーでは、ソフトウェアのソース ファイルが利用可能であることが前提となります。ソース ファイルをリモート サイトのサーバーに配置するには、ファイル レプリケーション サービス (FRS) または SMS (Systems Management Server) を利用する必要があります。SMS が利用可能な場合は、これを利用してソフトウェアのソース ファイルをリモート サーバーに配置し、"次に" ソフトウェアのインストール タスクを実行します。FRS には重要な制限事項がいくつかあるので、Microsoft サポート技術情報の Knowledge Base の文書 Q224512 http://support.microsoft.com/support/kb/articles/q224/5/12.asp (英語)、および Q220938 http://support.microsoft.com/support/kb/articles/q220/9/38.asp (英語) を参照してください。また、アプリケーションのソース ファイルが各リモート サイトに到達するのを待ってから、アプリケーションをアドバタイズする GPO を作成する必要があります。この GPO はソース ファイルよりもサイズが小さくレプリケーションも早く行われるので、必要なファイルがすべて揃う前にインストールが開始される可能性があるからです。このような事態が発生した場合、Windows インストーラ サービスがインストール作業をロール バック (中止) しますが、コンピュータの再起動時、またはユーザーがログオンする "たびに" (アプリケーションがユーザーに割り当て、または公開されている場合)、インストールの再試行が行われます。メモ : ソフトウェアのソース ファイルを分散ファイル システム (DFS) のレプリカ上に配置していて、ローカルのレプリカが利用できない場合、既定では、クライアント ワークステーションは、ほかのレプリカを "ランダムに" 選択します。このレプリカの選択は、完全にランダムに行われ、ネットワークのリンク速度や可用性、または Windows 2000 のレプリケーション トポロジとは "まったく" 関係なく行われます。したがって、クライアントがサイト外のレプリカを検索しないようにすることを推奨します。詳細については、Microsoft サポート技術情報の Knowledge Base の文書 Q282071 http://support.microsoft.com/support/kb/articles/q282/0/71.asp (英語) を参照してください。ソフトウェアのインストール先ソフトウェアには、"すべての" ワークステーションに適用されるもの、"すべての" ユーザーに適用されるもの、また "すべての" メンバ サーバーに適用されるものがあります。これらのグループごとに GPO を作成し、組織単位の構造に割り当てると (図 8 参照)、割り当てられた組織単位とその子の組織単位内のオブジェクトはすべて、ポリシーを継承します (したがって、アプリケーションはインストールされます)。図 8: コア ソフトウェア GPO の割り当てメモ : アプリケーションによっては、特定のワークステーションのみにインストールする必要があります。たとえば、Microsoft Project は Business Banking のワークステーションにインストールする必要があっても、ほかのアプリケーションはユーザーのサブセットのみに利用可能とすればよい場合があります。アプリケーションを選択的にアドバタイズするには、GPO を組織単位構造の適切な部分に割り当ててから、適切なユーザー (またはコンピュータ) オブジェクトを含む Windows 2000 のセキュリティ グループを作成します。このグループのみに、GPO に対するグループ ポリシーの読み取り許可と適用許可を認めることが必要です。サービス レベル契約に一連のソフトウェア アプリケーションの配布が規定されている場合は、クライアント ワークステーションにできるだけ近い場所にソフトウェアのソース ファイルのコピーを配置する必要があります。また、使用が認められたアプリケーションの一覧に対する変更は、細心の注意を払って管理し、レプリケーション メカニズムが関連する配布ポイントにソース ファイルを配置する時間に余裕を見込んでおきます。ソフトウェアのアップデートや新しいアプリケーションをインストールする必要があるときでも、サービス レベル契約の例外が認証されない場合は、SMS (Systems Management Server) を利用する必要があります。SMS を利用すると、インストール作業を通常の業務時間外にスケジュールできます。メモ : ソフトウェアをインストールする GPO を作成する場合は、そのソフトウェアのソース ファイルが利用可能であることが前提となります。ローカル サーバーにファイルをレプリケートするには、ファイル レプリケーション サービス、または SMS を使用する必要があります。サイト間のレプリケーションのスケジュール化と管理が可能な SMS の使用をお勧めします。ページのトップへまとめ技術よりも業務要件に基づいた設計GPO 構造の設計は、技術ではなく、業務要件に基づいて行ってください。組織内のコンピュータとユーザーをよく調査し、それらの種類、機能、および役割に基づいて、強制しなければならないポリシー設定、既定値とするポリシー設定、またはコンピュータやユーザーを構成する設定の選択を行います。これらさまざまな種類のポリシー設定を個別の GPO に割り当て、適切なサイト、ドメイン、組織単位にリンクします。長期的運用を念頭に設計作成したグループ ポリシーの設計が技術的に優れ、特定された業務要件のすべてに対応し、サポートへの当面の問い合わせ件数を大幅に削減したとしても、"変更" に対応していなければ、削減できる予定の TCO も実際には削減できなくなります。すべての変更を管理適切な管理ができていなければ、管理者は次のような危険性がある GPO を作成するおそれがあります。•会社の諸規程との矛盾•各ポリシー設定間の矛盾•ユーザー デスクトップ環境の破壊このような事態が発生すると、ヘルプ デスクやサポートへの問い合わせが増加し、問題のトラブルシューティングが困難となり、TCO が大幅に増加することになりかねません。ユーザーやコンピュータに関連付けるグループ ポリシー オブジェクトの数を最少限にとどめるユーザーに適用するグループ ポリシー オブジェクトの数は、ユーザーのログオン処理時間に影響します。(同様に、コンピュータに適用する GPO の数は、コンピュータのスタートアップ時間に影響します。) 関連付けられたグループ ポリシー オブジェクトの数が増えれば増えるほど、ログオン処理に要する時間も長くなります。ユーザーに、グループ ポリシー アクセス制御エントリ (ACE) に対する読み取り許可と適用許可の両方が認められている場合、ログオン時に、ユーザーのサイト、ドメイン、および組織単位の階層にある各 GPO が適用されます。メモ : [グループ ポリシーの適用] ACE が未設定で、[読み取り] ACE が設定されている場合、GPO は適用されませんが処理はされるので、ログオン時間に影響します。したがって、セキュリティ グループに基づくフィルタを実装する場合でも、グループ ポリシーの適用を解除するユーザーに対しては、読み取り許可も解除する必要があります。[ポリシーを継承しない] 機能の使用は最少限にとどめる親 Active Directory コンテナのグループ ポリシーが、下位レベルの親 Active Directory コンテナ内のユーザーとコンピュータに影響を及ぼさないようにします。この機能は便利で強力ですが、特定の状況で必要な場合に限って上手に使用する必要がある機能です。親 Active Directory コンテナからポリシーを継承しないようにすると、ポリシーのトラブルシューティングが複雑になる可能性があります。[上書きなし] 機能の使用は最少限にとどめる[上書きなし] オプションを使用すると、上位レベルの親 Active Directory コンテナのグループ ポリシー オブジェクトに指定したポリシー設定が、下位レベルの親 Active Directory コンテナで確実に強制されるようになります。この機能の使用は、状況が許す限り避けてください。[ポリシーを継承しない] 機能などの関連する機能と一緒にこの機能を多用すると、ポリシーのトラブルシューティングが複雑になります。ループバック処理の使用は必要な場合に限るコンピュータごとにユーザー構成を設定し、ユーザー固有のポリシーをコンピュータ固有のポリシーで上書きする方法は、コンピュータにどのユーザーがログオンするかにかかわらず、特定のデスクトップ構成を提供する場合に便利です。特に、ターミナル サーバーやドメイン コントローラの場合に便利です。ただし、トラブルシューティングは難しくなるので使用には注意が必要です。ドメインを跨ぐ GPO の割り当ては避ける特定の状況で必要とされる場合、さまざまなドメインのグループ ポリシー オブジェクトを単一の Active Directory コンテナに割り当てることができますが、このような場合、グループ ポリシーの処理は遅くなることに注意してください。これは、ドメイン境界を越えるからです。組織単位構造でのポリシーのリンクは避けるGPO を組織単位構造の上位に配置し、可能な限りグループ ポリシーの継承を使用します。GPO を組織単位構造の一部に割り当て、グループ ポリシー リンクを使用してほかの部分に適用することもできますが、この方法はお勧めできません。管理者が不注意にリンク (と GPO) を削除し、その結果、その管理者の担当外の組織単位内のオブジェクト グループにまで影響を及ぼす事例が多いからです。ページのトップへ

[ 72] 運用向けグループ ポリシーの設計
[引用サイト]　 http://www.microsoft.com/japan/technet/archive/ittasks/maintain/s1impgp.mspx

“あなたは会社のコンピュータから、仕事に関係のない趣味のホームページを見たことがありますか？”
“あなたの会社は、仕事に関係のないホームページを会社のコンピュータから閲覧することを許可していますか？”
という問いに自信を持ってYESと答えられる人は一体どれくらいいるだろう。恐らく10％にも満たないのではないだろうか。ほとんどの人が、「許可はされていないが、常識の範囲なら私用しても何もいわれない」とか、「たぶん禁止されていると思うので、よくないとは思うがたまに暇になると見る」などと答えるだろう。
ホームページの閲覧だけでなく、電子メールなどを含めたインターネット利用に関しては、どこからどこまでを私用とするかの切り分けが難しい。例えば、電子メールは業務とは関係なくても、部での飲み会の連絡など、会社組織内でのコミュニケーションの手段の1つとして利用されたりすることがある。これを私用とするか公用とするかは個人の考えにもよるだろうし、第一そんな細かいところまで決めても意味があるのかという議論にもなってくる。
どこの企業のネットワーク管理者も「本当は禁止したいが、禁止しても皆使うだろう。いちいち監視して違反者を注意していたらきりがないので、個人のモラルに任せればいいと思う」というところが本音なのではないだろうか。ただ、だからといってまったく制限をかけないのも問題があるということで、アダルトサイトやオークションサイトなどをあらかじめ閲覧禁止サイトとして設定し、ユーザーがアクセスした場合には「警告」の2文字をページ一面に表示するなどの対策を施している企業も少なくない。
ではなぜ、ホームページの私用閲覧は禁止されるのだろうか。昔でいう「私用電話」と同じで、会社のものだから私用してはいけないというもっともな意見もあるが、この場合、それだけではなさそうだ。
つまり、多くの社員が無駄なページに多数アクセスすることによって、本当に業務に必要なアクセスまで滞ってしまうということだ。ある企業が株式を店頭公開した際に、社員が株価指数のページにアクセスし過ぎてサーバに負荷がかかったため、ネットワークアクセスをフィルタリングし、株価指数のページにはアクセスできないように制御した、といった例もある。
ということである。少し前までは、社内ネットワークを利用するうえで、ユーザーが気を付けなければならないことといえば、メールに添付されてくるウイルスに感染することくらいであったが、ここ数年の間に、Internet
Explorerのセキュリティホールを悪用して、ユーザーがある特定のサイトにアクセスした際に自動的に悪意のあるプログラムを実行させられたりする、いわゆる能動的な被害が急激に増加している。この被害を避けるためには、ユーザーにそのような危険性があることをまず理解してもらう必要がある。そのうえで、Internet
Explorerのセキュリティホール情報を常にチェックし、何らかの対策か、修正プログラムが公開されたらすぐに、社内ネットワークに接続するすべてのコンピュータに適用する必要がある。
このような理由により、これらを制限する作業を、だれが、いつ、どのくらいのペースで、どういった手順で行うのか。また、修正プログラムを適用するまでは社内ネットワークに接続してはならない、といったことを、会社の「規約」としてはっきりと文書化し、すべての社員のセキュリティに対する意識を向上させるように啓発し、実践していく必要がある。
ネットワークセキュリティにおいて企業が守るべきものは何かと考えてみると、顧客の情報、社員の住所録などの個人情報、重役会議の資料、新製品の企画書など、例を挙げるときりがないが、これらすべてに共通することは、企業の「情報」であるということだ。
「情報」は企業にとって重要な「資産」であるのだが、この「情報資産」という考えが日本人に根付いていないため、守るべきものが何であるのかを見誤ってしまうことが多々ある。
しかし、例えば、物理的に誰かが会社に侵入しコンピュータが盗まれたとして、その損害を考えたときに、本当に損害が大きいのはコンピュータ自体よりもむしろコンピュータの中に入っている「情報資産」を盗まれたことであるはずだ。つまり、本当に守るべきものは企業の「情報資産」なのである。
また、セキュリティというと、一般的にはコンピュータのネットワーク上にある情報漏えいの危険性などが示唆されるが、企業が守るべき「情報資産」は必ず
しも電子的なものではなく、情報を印刷した紙、ひいては人間が話す話の内容などさまざまな形態で存在する。
従って、企業は「セキュリティ」を考える際に、ネットワークセキュリティ、つまり技術的な側面だけでなく、物理的、人的なセキュリティまで考慮する必要がある。
「情報資産」を守るべく施す対策や、規約をまとめたものを「情報セキュリティポリシー」と呼ぶのである。
また、ファイアウォールの設定ファイルなどを指して、「セキュリティポリシー」 と呼ぶことがあるため、これと区別するためにも必ず「情報」を付ける。
では次に、なぜいま、この情報セキュリティポリシーが注目されているのかということを説明していこう。
ネットワークセキュリティにも流行というものはあって、これまでの流れを考えると、企業が積極的に導入してきたセキュリティ関連の機器やシステムには、ファイアウォール、ウイルス対策ソフト、IDS（侵入検知システム）などがあるが、これらがその例として挙げられると思う。
少なくとも3〜4年前には、まだ大多数の企業が情報セキュリティポリシーという単語すら聞いたことがないというのがほとんどで、情報セキュリティポリシーの存在を知っていても、ただの紙切れであるとしか認識されておらず、まさかそれに大枚をはたいて導入しようなどとは考えもしなかった。それよりもとにかく、ファイアウォールやウイルス対策ソフトなどのいわゆるセキュリティ製品を導入することに躍起になっていたのが当時の現状だったように思う。
しかし、ここ数年で、前述したような、企業のネットワーク管理者のみがセキュリティ対策を行えばそれでよいという時代は終わり、ユーザー1人1人がセキュリティ意識を持ち、全社的なセキュリティ対策を実施していく必要性が増してきている。
また、企業の情報資産は、ユーザーの認識不足や外部からの不正アクセスなどによるものだけでなく、内部犯行という大きな脅威にもさらされている。
不正に内部の人間と同じ資格を得た人間もさることながら、正社員、契約社員、派遣社員、アルバイト、パートタイマーなどによる情報資産の漏えいは回避することが非常に難しい。特に日本人は内部犯行に関して意識が低く、まさか内部の人間がそのようなことをするはずがないなどと思いがちであるが、実際、社会的に問題となった情報漏えい事件が内部犯行によるものである場合も少なくない。
しかし、情報セキュリティポリシーを整備し、物理的な入退室管理や、適切なアクセス制御を実施し、またユーザーのセキュリティ意識レベルを上げることで、内部犯行を未然に防げる可能性は飛躍的に高くなる。
上記のことも、企業に情報セキュリティポリシーが必要だと認識させるようになってきた要因でもあるが、それとは別に情報セキュリティポリシー運用の制度が全世界で本格化されてきており、その認定取得の動きが盛んになってきていることも、民間企業が情報セキュリティポリシーの導入に目を向けるようになった大きな要因の1つである。
情報セキュリティマネジメントに関する国際標準や、国内制度などの動向については次回以降で解説するのでここでは詳しくは説明しないが、情報セキュリティポリシーの代名詞といわれている英国規格BS7799の初版が1995年に発行されてからその流れは全世界に広がり、日本国内でもこの流れを受け継いだISMS（Information
現在、このISMS適合性評価制度のパイロット運用が行われているのだが、2002年2月4日の時点で18社（3月末までに39社認定予定）が認定を受けているとのことである。2002年4月からの本格運用が始まれば各企業がこぞってこの認定を取得しようとすることは間違いないと見られており、今後情報セキュリティポリシーの波はますます勢いを増すであろう。
いままではセキュリティ自体、費用ばかりかさんで効果がまったく見えてこないものとして敬遠こそされていたが、
いまでは情報セキュリティポリシーを運用しているということは、企業としての対外的なアピールになりつつあるということだ。
情報セキュリティポリシーを「持っている」ことがアピールになると勘違いされている方が非常に多い。この勘違いが、「とにかく」情報セキュリティポリシーがほしいという現在の1つの風潮を生んでいる。
しかし、残念なことに、情報セキュリティポリシーは持っているだけでは何の意味もない。ただの紙切れである。先にも述べたように情報セキュリティポリシーは情報セキュリティに関する「文書化された規約」である。規約であるからには全ユーザーに配布し、その内容を認識してもらい、そのうえで規約を守ってもらう必要がある。このことがつまり情報セキュリティポリシーを運用するということなのであるが、これをすることなしにセキュリティレベルを上げることはできないし、まして認定を取得することは絶対にできない。
また、情報セキュリティポリシーを策定するだけで運用しないのであれば、セキュリティレベルは策定する前と同じであるから、お金をかけて策定することの意味はないのではないだろうか。
このもっともな理論に反して、とにかく情報セキュリティポリシーがほしいという企業や、その情報セキュリティ管理者は実際にはたくさんいる。
確かに、情報セキュリティポリシーを策定している企業はまだそれほど多くないので、いまの段階では情報セキュリティポリシーを「持っている」という事実は、情報セキュリティポリシーについて知識の浅い人に対してはアピールとなり得るかもしれない。しかし、情報セキュリティポリシーの波は日ごとにその勢いを増してきているので、情報セキュリティポリシーを「持っている」だけでは何の意味もないということが世間の常識になる日もそう遠くないだろう。情報セキュリティポリシーを持っていること＝セキュリティ対策をしっかりと行っているという、一見成り立ち得るように見える図式が崩れることは目に見えている。
図3 情報セキュリティポリシーを「持つこと」と「運用する」ことの意味を混同しないでほしい
この記事を読まれている、賢明な読者の皆さんには「取りあえず」とか「とにかく」情報セキュリティポリシーがほしいということの意味のなさをご理解いただき、まず情報セキュリティポリシーを「持つ」ことと、「運用する」ことの違いをはっきりと認識していただきたい。
そして本当に意味のある、効果の高い情報セキュリティポリシーの策定とその運用を行っていただきたいと思う。
次回は、情報セキュリティポリシーの構成についてもう少し詳しくお話ししたうえで、実際に策定していく手順と、策定時の注意点および、策定期間を短縮する方法とそのポイントなどを紹介していく。
APIアクセス権を委譲するプロトコル、OAuthを知る （2008/1/21）マッシュアップでAPIアクセス権の委譲をどう扱うべきか――この問題を解決すべく作られたプロトコル「OAuth」に迫る
その文字列はセーフ？ 本当は奥深いデコード処理 （2008/1/18） Webアプリを勉強した人ならば、エンコードなんて当たり前。だけどこの文字列、しっかり処理をしないと「%91%e5%95%cf」！
己を知り、敵を知る――Nmapで見つめ直す自分の姿 （2008/1/8） ポートスキャンは正義の管理者には関係ない？ いいえ、己の姿を客観的に見るためには、的確なポートスキャン術が必要なのです
最終手段？ 京都に究極のセキュリティ対策を見た （2007/12/26） 思いが集まる場所には場の力が生まれる、祈りこそ力……なんの話かって？ もちろん、セキュリティ対策の話に決まってるじゃないですか！
ホワイトペーパー利用者に「Amazonギフト券」を抽選で100名様にプレゼント！――TechTargetジャパン リニューアル・キャンペーン
＠ITトップ｜Security&Trustフォーラム トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ

[ 73] 情報セキュリティポリシー入門
[引用サイト]　 http://www.atmarkit.co.jp/fsecurity/rensai/policy11/policy01.html



ポリシーとは？トップへ↑

お気に入り