SSO のセキュリティに関する推奨事項
このセクションには、Enterprise Single Sign-On (SSO) システムをセキュリティで保護する方法に関する推奨事項が含まれています。
エンタープライズ シングル サインオン (SSO) システムを使用すると、ユーザーは 1 組の資格情報だけを使用してさまざまなシステムに接続できるようになります。 Host Integration Server は、機密情報のストアとして SSO システムを使用します。 Host Integration Server ランタイムをインストールするたびに自動的にインストールされますが、ホスト統合サーバー環境とは無関係に、スタンドアロン コンポーネントとして Enterprise Single Sign-On をインストールすることもできます。 Enterprise SSO サービスとリソースをセキュリティで保護して環境内にデプロイするには、次のガイドラインに従うことをお勧めします。
SSO の展開に関する一般的な推奨事項
すべての SSO サーバーが同期されるように、環境内には 1 台のタイム サーバーを配置する必要があります。 SSO サーバー上のクロックが同期されていない場合は、環境のセキュリティが損なわれる可能性があります。
環境全体にマスター シークレット サーバーが 1 つしかないことを考慮すると、マスター シークレット サーバーにはアクティブ/パッシブ クラスター構成を使用します。 マスター シークレット サーバーのクラスタリングの詳細については、「マスター シークレット サーバー をクラスター化する方法」を参照してください。
マスター シークレット サーバーは、SSO システムが SSO データベース内の情報を暗号化するために使用する暗号化キーを保持します。 このコンピューターに他の製品やサービスをインストールまたは構成しないことをお勧めします。
Note
マスタ シークレット サーバーをインストールおよび構成するコンピュータは、サーバーである必要はありません。
マスタ シークレット サーバーは、マスタ シークレットをバックアップおよび復元するため、リムーバブル メディアまたは NTFS ファイル システム フォルダにアクセスできる必要があります。 リムーバブル メディアを使用する場合は、リムーバブル メディアを保護するための適切な対策を講じてください。 マスター シークレットを NTFS ファイル システムにバックアップする場合は、ファイルとフォルダーを確実に保護してください。 また、このファイルには、SSO 管理者のみがアクセスできるようにする必要があります。
マスタ シークレットは、マスタ シークレット サーバーによって生成されたら、すぐにバックアップする必要があります。 これは、マスター シークレット サーバーが失敗した場合に SSO データベース内のデータを復旧できるようにするためです。 マスター シークレットのバックアップの詳細については、「マスター シークレット の管理」を参照してください。
現在のシークレットをバックアップするか、月に 1 回など、定期的に新しいシークレットを生成します。 シークレットがないと、SSO データベースから情報を取得できません。 マスター シークレットのバックアップと復元の詳細については、「マスター シークレットの管理」を参照してください。
SSO グループとアカウントのセキュリティに関する推奨事項
特に SSO 管理者グループと SSO 関連管理者グループでは、単一のユーザー アカウントではなく、Windows グループを使用することをお勧めします。 これらのグループには、少なくとも 2 つのユーザー アカウントがメンバとして常に含まれている必要があります。
SSO ランタイム サービス アカウントと SSO 管理者ユーザー アカウントが同じ SSO 管理者グループのメンバである場合も、これらのアカウントには、別のアカウントを使用することをお勧めします。 シークレットの生成やバックアップなどの管理タスクを実行する SSO 管理者ユーザーは Windows 管理者である必要があります。一方、SSO ランタイム サービス アカウントは Windows 管理者である必要はありません。
重要
Windows 管理者のユーザー権限は、SSO 管理者のユーザー権利に代わるものではありません。 SSO 管理レベルのタスクを実行するには、既に Windows 管理者であっても、SSO Administrators グループのメンバーである必要があります。
SSO のチケット発行機能を使用する場合、処理ドメイン (SSO サーバーが配置されているドメイン) のコンピュータで認識されるドメイン アカウントを使用する必要があります。
マスター シークレット サーバーに対応する SSO サービスには、一意のサービス アカウントを使用することをお勧めします。
SSO 管理者アカウントは、SSO システムの高い特権を持つアカウントです。これは、SSO データベースを持つ SQL サーバーのSQL Server管理者アカウントでもあります。 SSO 管理者には専用のアカウントを用意し、他の目的には使用しないでください。 SSO Administrators グループへのメンバーシップは、SSO システムの実行と保守を担当するアカウントのみに制限する必要があります。
SSO 展開のセキュリティに関する推奨事項
ネットワークが Kerberos 認証をサポートしている場合、すべての SSO サーバーを登録する必要があります。 マスタ シークレット サーバーと SSO データベース間に Kerberos 認証を使用する場合、SSO データベースが存在する SQL Server コンピュータにサービス プリンシパル名 (SPN) を構成する必要があります。
Windows Server 2003 を実行している場合、マスター シークレット サーバーが他の SSO サーバーとは異なるドメイン上にあり、SSO データベースとは異なるドメインにある場合は、マスター シークレット サーバー (処理ドメイン内のコンピューターの処理) で、マスター シークレット サーバー上の RPC セキュリティ (コンピューター間のデータ トランザクション コーディネーター (DTC) 認証に使用される) を無効にする必要があります。 と を SSO データベースに置き出します。 RPC セキュリティは、Windows Server 2003 の新しい DTC 機能です。 RPC セキュリティを無効にすると、RPC 呼び出しの DTC 認証セキュリティ レベルが Microsoft Windows で使用できるレベルに戻ります。 RPC セキュリティを無効にする方法の詳細については、「 Microsoft ヘルプとサポート」を参照してください。
SSO 管理者は、マスタ シークレット サーバーと SSO サーバーのイベント ログで SSO 監査イベントを定期的に監視することをお勧めします。
ファイアウォールに加えて、すべての SSO サーバーと SSO データベースの間でインターネット プロトコル セキュリティ (IPsec) または Secure Sockets Layer (SSL) を使用することをお勧めします。 SSL の詳細については、「 Microsoft ヘルプとサポート」を参照してください。
境界ネットワーク
インターネット インフォメーション サービス (IIS) とエンタープライズ シングル サインオンを実行する際は、次の推奨事項に従ってください。
IIS が境界ネットワーク (スクリーン サブネットとも呼ばれます) にある場合は、ファイアウォールの背後で IIS を実行している別のサーバーを指定して、SSO システムに接続します。
IIS ではリモート プロシージャ コール (RPC) ポートを開かないでください。
SQL Server へのアクセス
すべての SSO サーバーは、SQL Server資格情報データベースにアクセスします。
Microsoft では、SECURE Sockets Layer (SSL) やインターネット プロトコル セキュリティ (IPsec) を使用して、SSO サーバーと資格情報データベース間のデータの転送をセキュリティで保護することをお勧めします。 SSL の使用の詳細については、「 Microsoft ヘルプとサポート」を参照してください。
SSO サーバーと資格情報データベース間の接続に対してのみ SSL を有効にするには、ssoconfig ユーティリティを使用して、すべての SSO サーバーで SSL サポートを設定できます。 このオプションを使用すると、資格情報データベースにアクセスするときに SSO で常に SSL を使用できます。 詳細については、「 How to Enable SSL for Enterprise Single Sign-On」を参照してください。
強力なパスワード
すべてのアカウントには、強力なパスワードを使用する必要があります。特に SSO 管理者グループのメンバ アカウントは SSO システム全体を制御できるので、強力なパスワードを使用することが重要になります。
SSO 管理者アカウント
異なるコンピューターで実行されている SSO サービスには、異なるサービス アカウントを使用することをお勧めします。 SSO サービス アカウントには、シークレットの生成やバックアップなどの管理タスクを実行する SSO 管理者アカウントを使用しないでください。 SSO サービス アカウントは、そのコンピューターのローカル管理者にすることはできませんが、管理操作を実行している SSO 管理者は、一部の操作ではコンピューターのローカル管理者である必要があります。
マスタ シークレット サーバー
マスター シークレット サーバーをセキュリティで保護してロックダウンすることを強くお勧めします。 マスタ シークレット サーバーは、処理サーバーとして使用しないでください。 このサーバーは、マスタ シークレットを保持する目的にのみ使用してください。 このコンピュータの物理的なセキュリティを確保し、このコンピュータには SSO 管理者のみがアクセスできるようにする必要があります。
Kerberos
SSO では Kerberos がサポートされており、SSO 用に Kerberos を設定することをお勧めします。 SSO に Kerberos を設定するには、SSO サービスのサービス プリンシパル名 (SPN) を登録する必要があります。 既定では、Kerberos を設定すると、SSO はその SPN を使用して SSO サービスを使用してコンポーネントを認証します。 SSO 管理サブ サービスと SSO サーバーの間で Kerberos 認証を設定することをお勧めします。 また、SSO サーバー間、SSO サーバーと資格情報データベースがあるSQL Server間の Kerberos 認証をユーザーに許可することもできます。
Kerberos を設定して確認するには、ユーティリティ setspn と kerbtray を使用します。
委任
Windows Server 2003 を使用している場合は、制約付き委任を使用できますが、委任を使用して単一 Sign-On 管理者のタスクを実行しないことをお勧めします。 同様に、追加のタスクやユーザー権限を単一 Sign-On 管理者に委任しないことをお勧めします。
監査
監査は、環境内の情報を追跡するための重要なメカニズムです。 Enterprise Single Sign-On (SSO) は、資格情報データベースで実行されたすべての操作を監査します。 SSO では、データベースに備わっているイベント ログと監査ログを使用します。 SSO には、シングル サインオン サーバーに対して次の 2 つの監査レベルが用意されています。
正の監査レベルは、成功した操作を監査します。
負の監査レベルは、失敗した監査操作をレベルします。
SSO 管理者は、企業の規定に応じて、成功と失敗の監査レベルを設定できます。
成功と失敗の監査は、次のレベルのいずれかに設定できます。
0 = なし - このレベルでは監査メッセージは発行されません。
1 = 低。
2 = 中。
3 = 高 - このレベルでは、可能な限り多くの監査メッセージが発行されます。
正の監査の既定値は 0 (なし) で、負の監査の既定値は 1 (低) です。 これらの値は、SSO システムで必要な監査レベルに応じて変更できます。
重要
Enterprise Single Sign-On 監査では、単一 Sign-On サービスによって生成されたメッセージが発行されます。 これはセキュリティ監査ではなく、SSO システムによってイベント ログのセキュリティ ログに情報が保存されません。 SSO システムは、SSO 監査メッセージをアプリケーション イベント ログに直接保存します。
データベース レベルの監査
データベース レベルの監査の場合、SSO システムは、データベース内の監査テーブル内の資格情報データベースに対して実行された操作を追跡します。 これらの監査テーブルのサイズは、SSO システム レベルで定義されます。 関連アプリケーションやマッピングの削除、資格情報の参照などの操作を監査できます。 既定では、監査サイズは 1000 エントリに設定されています。 SSO 管理者は、企業のポリシーに応じて、このサイズを変更できます。
Enterprise Single Sign-On アカウントの使用
このセクションでは、Enterprise Single Sign-On (SSO) システムでドメインとローカル グループと個々のアカウントを使用する場合のベスト プラクティスについて説明します。
ドメイン Windows グループとアカウント
ドメイン Windows グループを使用している場合は、次の推奨事項が適用されます。
ドメイン グループとドメイン アカウントを使用します。
SSO 管理者にはドメイン グループを使用します。 単独のドメイン アカウントは別の単独アカウントに変更することができません。そのため、単独のドメイン アカウントを SSO 管理者として指定しないことをお勧めします。
SSO 関連管理者として単独のドメイン アカウントを指定することはできますが、SSO 関連管理者にはドメイン グループを使用することをお勧めします。
アプリケーション管理者として単独のドメイン アカウントを指定することはできますが、アプリケーション管理者にはドメイン グループを使用することをお勧めします。
アプリケーション ユーザー アカウントにはドメイン グループを使用する必要があります。 SSO アプリケーション ユーザー アカウントは、個々のアカウントをサポートしていません。