次の方法で共有

AD FS のセキュリティを考慮した設計と展開のベスト プラクティス

  • [アーティクル]

このトピックでは、Active Directory フェデレーション サービス (AD FS) の展開を設計するあたってセキュリティを計画および評価するのに役立つベスト プラクティスの情報を示します。 このトピックは、AD FS を使用する際の全体的なセキュリティに影響する考慮事項の確認と評価のための出発点となります。 このトピックの情報は、既存のセキュリティ計画と他の設計のベスト プラクティスを補完および強化することを意図しています。

AD FS のセキュリティの主要ベスト プラクティス

以下の主要ベスト プラクティスは、設計または展開のセキュリティを改善または強化させたいすべての AD FS のインストールに共通するものです。

  • "階層 0" システムとしての安全な AD FS

    AD FS は基本的に認証システムであるため、ネットワーク上の他の ID システムと同様に "階層 0" システムとして扱う必要があります。 詳細については、「Active Directory 管理階層モデル」を参照してください。

  • セキュリティの構成ウィザードを使用して AD FS 固有のセキュリティのベスト プラクティスをフェデレーション サーバーとフェデレーション サーバー プロキシ コンピューターに適用する

    セキュリティの構成ウィザード (SCW) は、すべての Windows Server 2008、Windows Server 2008 R2、Windows Server 2012 コンピューターにプレインストールされているツールです。 このウィザードは、インストールするサーバーの役割に基づいて、サーバーが攻撃を受ける機会を削減するのに役立つセキュリティのベスト プラクティスを適用するのに使用できます。

    AD FS をインストールすると、セットアップ プログラムによって役割拡張ファイルが作成されます。このファイルは、セットアップ時に選択する特定の AD FS サーバーの役割 (フェデレーション サーバーまたはフェデレーション サーバー プロキシ) に適用されるセキュリティ ポリシーを作成するために SCW で使用できます。

    インストールされるそれぞれの役割拡張ファイルは、各コンピューターに構成される役割とサブ役割の種類を表します。 次の役割拡張ファイルが C:WindowsADFSScw ディレクトリにインストールされます。

    • Farm.xml

    • SQLFarm.xml

    • StandAlone.xml

    • Proxy.xml (このファイルはコンピューターをフェデレーション サーバー プロキシの役割に構成した場合にのみ存在します)

    AD FS の役割の拡張を SCW で適用するには、次の手順を順番に実行してください。

    1. AD FS をインストールし、そのコンピューターに適したサーバーの役割を選択します。 詳細については、AD FS 展開ガイドの 「フェデレーション サービス プロキシ役割サービスをインストールする 」を参照してください。

    2. Scwcmd コマンドライン ツールを使用して適切な役割拡張ファイルを登録します。 下記の表で、コンピューターに構成される役割でこのツールを使用する方法の詳細を参照してください。

    3. SCWRegister_log.xml ファイル (WindowssecurityMsscwLogs ディレクトリに格納) を調べて、コマンドが正常に完了したことを確認します。

    AD FS ベースの SCW セキュリティ ポリシーを適用するフェデレーション サーバーまたはフェデレーション サーバー プロキシ コンピューターごとに、これらの手順をすべて実行する必要があります。

    次の表では、AD FS をインストールしたコンピューターで選択する AD FS サーバーの役割に基づいて、適切な SCW の役割の拡張を登録する方法について説明します。

    AD FS サーバーの役割 使用する AD FS 構成データベース コマンド プロンプトで入力するコマンド
    スタンドアロン フェデレーション サーバー Windows Internal Database scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwStandAlone.xml"
    ファームに加わったフェデレーション サーバー Windows Internal Database scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwFarm.xml"
    ファームに加わったフェデレーション サーバー SQL Server scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwSQLFarm.xml"
    フェデレーション サーバー プロキシ 該当なし scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwProxy.xml"

    AD FS に使用できるデータベースの詳細については、「AD FS 構成データベースの役割」を参照してください。

  • キオスクを使用する場合など、セキュリティが非常に重要な懸念事項となる状況でトークン リプレイ検出を使用する トークン リプレイ検出は AD FS の機能で、フェデレーション サービスに対するトークンの要求をリプレイするあらゆる試みを検出して要求が破棄されるようにします。 トークン リプレイ検出は既定で有効になっています。 この機能は、同じトークンが複数回使用されないようにすることで、WS-Federation パッシブ プロファイルと Security Assertion Markup Language (SAML) WebSSO プロファイルの両方に対して機能します。

    フェデレーション サービスが開始されると、サービスが対応するすべてのトークンの要求のキャッシュを構築し始めます。 時間と共に、キャッシュに後続のトークンの要求が追加されると、フェデレーション サービスにおいて、トークンの要求を複数回リプレイしようとする試みをより一層検出できるようになります。 トークン リプレイ検出を無効にして、後で再度有効にする場合は、リプレイ キャッシュがコンテンツを再構築するのに十分な時間が経過するまで、フェデレーション サービスは以前に使用された可能性のあるトークンを一定期間受け入れることに留意してください。 詳細については、「AD FS 構成データベースの役割」を参照してください。

  • 特にサポート対象の SAML アーティファクト解決を使用する場合に、トークンの暗号化を使用する

    AD FS の展開で実行される可能性がある man-in-the-middle (MITM) 攻撃に対するセキュリティと保護を強化するために、トークンを暗号化することを強くお勧めします。 暗号化の使用はスループットに多少影響する可能性がありますが、認識されることは通常なく、多くの展開においてセキュリティの強化のメリットはサーバーのパフォーマンスの点であらゆるコストに勝ります。

    トークンの暗号化を有効にするには、最初に証明書利用者信頼の暗号化証明書を設定して追加します。 暗号化証明書は、証明書利用者信頼の作成時または後で構成できます。 後で既存の証明書利用者信頼に暗号化証明書を追加するには、AD FS スナップインの利用時に、信頼プロパティ内の [暗号化] タブで使用するための証明書を設定できます。 AD FS コマンドレットを利用し、既存の信頼の証明書を指定するには、Set-ClaimsProviderTrust コマンドレットまたは Set-RelyingPartyTrust コマンドレットの EncryptionCertificate パラメーターを使用します。 トークンの暗号化を解除する際に使用するフェデレーション サービスの証明書を設定するには、Set-ADFSCertificate コマンドレットを使用して "Token-Encryption" を CertificateType パラメーターに指定します。 特定の証明書利用者信頼に対する暗号化を有効または無効にするには、Set-RelyingPartyTrust コマンドレットの EncryptClaims パラメーターを使用します。

  • 認証に対する保護の強化を活用する

    展開をセキュリティで保護するために、AD FS で認証に対する保護を強化する機能を設定して使用できます。 この設定では、フェデレーション サーバーでサポートされる認証に対する保護の強化のレベルを指定します。

    認証に対する保護の強化は、攻撃者がクライアントの資格情報を傍受してサーバーに転送する man-in-the-middle (MITM) 攻撃に対する保護に役立ちます。 このような攻撃に対する保護は、チャネル バインディング トークン (CBT) を使用することで可能になります。サーバーでは、クライアントと通信を確立するときに CBT を必須、許容、または不要のいずれかにできます。

    保護を強化する機能を有効にするには、ExtendedProtectionTokenCheck パラメーターを Set-ADFSProperties コマンドレットで使用します。 次の表に、この設定で使用できる値と、値によって指定されるセキュリティのレベルを示します。

    パラメーター値 セキュリティ レベル 保護設定
    必須 サーバーは完全にセキュリティで保護されます。 保護の強化が適用され常時必須です。
    Allow サーバーは部分的にセキュリティで保護されます。 保護の強化は、関係するシステムでパッチによってサポートされている場合に適用されます。
    なし サーバーは保護されていません。 保護の強化は適用されません。

  • ログとトレースを使用する場合は、すべての機密情報のプライバシーを確保する

    AD FS では、既定で、フェデレーション サービスや通常の運用の一環として、個人を特定できる情報 (PII) を直接公開または追跡することはありません。 ただし、イベントのログとデバッグ トレースのログが AD FS で有効な場合、構成した要求ポリシーによっては、一部の要求の種類とその関連値に PII が含まれている可能性があり、それが AD FS イベントまたはトレース ログに記録されることがあります。

    そのため、AD FS の構成とログ ファイルへのアクセス制御を実施することを強くお勧めします。 このような情報を参照できないようにするには、ログインを無効にするか、他のユーザーとログを共有する前にログのすべての PII や機密情報をフィルター処理する必要があります。

    以下のヒントは、意図せずにログ ファイルの内容が公開されるのを防ぐのに役立ちます。

    • AD FS のイベント ログとトレース ログ ファイルが、アクセス制御リスト (ACL) によって保護されていることを確認してください。この ACL では、ファイルへのアクセスが必要な信頼されている管理者のみにアクセスを制限します。

    • Web 要求を使用して簡単に処理できるファイル拡張子やパスを使用してログ ファイルをコピーしたりアーカイブしたりしないでください。 たとえば、ファイル名の拡張子として .xml を選択するのは安全ではありません。 インターネット インフォメーション サービス (IIS) の管理ガイドを参照して、処理できる拡張子のリストを確認します。

    • ログ ファイルのパスを変更する場合は、ログ ファイルのある場所への絶対パスを指定するようにしてください。この場所は、部外者が Web ブラウザーを使用してアクセスできないように、Web ホストの仮想ルート (vroot) パブリック ディレクトリの外部にする必要があります。

  • AD FS エクストラネットのソフト ロックアウトとエクストラ AD FS スマート ロックアウト保護

    Web アプリケーション プロキシ を介して受け取った無効な (正しくない) パスワードを使用した認証要求の形式で攻撃を受けた場合、AD FS エクストラネット ロックアウトを使用すると、AD FS アカウントのロックアウトからユーザーを保護できます。 AD FS アカウントのロックアウトからユーザーを保護するほか、AD FS エクストラネット ロックアウトはブルート フォース パスワード推測攻撃からも保護します。

    Windows Server 2012 R2 の AD FS のエクトラネット ソフト ロックアウトについては、「AD FS エクストラネット ソフト ロックアウト保護」を参照してください。

    Windows Server 2016 の AD FS のエクトラネット ソフト ロックアウトについては、「AD FS エクストラネットスマート ロックアウト保護」を参照してください。

SQL Server 特有の AD FS のセキュリティに関するベスト プラクティス

以下のセキュリティのベスト プラクティスは、AD FS の設計と展開でデータを管理するために使用するデータベース テクノロジが Microsoft SQL Server® または Windows Internal Database (WID) である場合に特有のものです。

注意

これらの推奨事項は SQL Server 製品のセキュリティ ガイダンスを強化するためのものであって、取って代わるものではありません。 セキュリティで保護された SQL Server のインストールの計画について詳しくは、「 SQL Server インストールのセキュリティに関する注意点 」(https://go.microsoft.com/fwlink/?LinkID=139831) を参照してください。

  • 常に SQL Server を物理的にセキュリティで保護されたネットワーク環境内のファイアウォールの背後に展開する。

    SQL Server のインストールを直接インターネットに公開しないでください。 データセンター内のコンピューターのみが AD FS をサポートする SQL Server のインストールにアクセスできるようにようにしてください。 詳細については、「セキュリティのベスト プラクティス チェックリスト (https://go.microsoft.com/fwlink/?LinkID=189229)」を参照 してください。

  • 既定のビルトイン システム サービス アカウントを使用せずに、別のサービス アカウントで SQL Server を実行する。

    SQL Server は既定で、LocalSystem や NetworkService アカウントなど、サポートされているビルトイン システム アカウントの 1 つを使用するようインストールおよび構成されることがよくあります。 AD FS に対する SQL Server のインストールのセキュリティを強化するために、できる限り SQL Server サービスへのアクセスに別のサービス アカウントを使用し、このアカウントのセキュリティ プリンシパル名 (SPN) を Active Directory の展開に登録することで Kerberos 認証を有効にしてください。 これによってクライアントとサーバー間で相互認証ができるようになります。 別のサービス アカウントの SPN を登録しないと、SQL Server は Windows ベースの認証で NTLM を使用するので、クライアントのみが認証されます。

  • SQL Server での外部からのアクセスを最小限にする。

    必要な SQL Server エンドポイントのみを有効にしてください。 SQL Server では、既定で組み込みの TCP エンドポイント (削除不可) が 1 つ提供されています。 AD FS では、この TCP エンドポイントを Kerberos 認証のために有効にする必要があります。 現状の TCP エンドポイントを確認してユーザー定義の別の TCP ポートが SQL のインストールに追加されていないか調べるには、Transact-SQL (T-SQL) セッションで "SELECT * FROM sys.tcp_endpoints" クエリ ステートメントを使用できます。 SQL Server エンドポイントの構成の詳細については、「 複数の TCP ポートでリッスンするようにデータベース エンジンを構成する方法 」(https://go.microsoft.com/fwlink/?LinkID=189231) を参照してください。

  • SQL ベースの認証を使用しない。

    ネットワークでパスワードをクリア テキストとして転送したり、構成設定にパスワードを保存したりすることを避けるために、SQL Server インストールで Windows 認証のみを使用してください。 SQL Server 認証は以前の認証モードです。 SQL Server 認証の使用時に構造化照会言語 (SQL) ログイン資格証明書 (SQL ユーザー名とパスワード) を保存することは推奨されません。 詳細については、「認証モード (https://go.microsoft.com/fwlink/?LinkID=189232)」を参照してください。

  • SQL のインストールで追加のチャネル セキュリティが必要か慎重に評価する。

    Kerberos 認証が有効でも、SQL Server セキュリティ サポート プロバイダー インターフェイス (SSPI) ではチャネル レベルのセキュリティは提供されません。 ただし、サーバーがファイアウォールで保護されたネットワークに安全に配置されているインストールでは、SQL 通信の暗号化は必要でない場合があります。

    暗号化は、セキュリティの強化に役立つ便利なツールですが、すべてのデータまたは接続に対して考慮すべきものではありません。 暗号化を実装するかどうかを検討する際は、ユーザーがデータにどのようにアクセスするかを考慮する必要があります。 ユーザーがパブリック ネットワーク経由でデータにアクセスする場合は、セキュリティを強化するためにデータの暗号化が必要になると考えられます。 ただし、AD FS による SQL データのすべてのアクセスがセキュリティで保護されたイントラネット構成で行われる場合は、暗号化は必要ないかもしれません。 暗号化を使用する場合は、それに伴ってパスワード、キー、および証明書のメンテナンス計画が必要になります。

    ネットワークで何らかの SQL データの参照または改ざんの可能性が懸念される場合は、インターネット プロトコル セキュリティ (IPsec) または Secure Sockets Layer (SSL) を使用して SQL 接続をセキュリティで保護してください。 ただし、これは SQL Server のパフォーマンスに悪影響を及ぼす可能性があり、場合によっては AD FS のパフォーマンスが影響を受けたり制限されたりすることがあります。 たとえば、SQL ベースの属性ストアからの属性参照がトークンの発行で不可欠な場合、トークンの発行における AD FS のパフォーマンスが低下する可能性があります。 SQL の改ざんの脅威は、境界セキュリティの構成を強固にすることでより確実に排除することができます。 たとえば、SQL Server のインストールをセキュリティで保護するためのより良いソリューションは、SQL Server に対して、インターネット ユーザーとコンピューターはアクセスできない状態にし、データセンター環境内のユーザーとコンピューターのみがアクセスできる状態にすることです。

    詳細については、「SQL Server への接続の暗号化」または「SQL Server の暗号化」を参照してください。

  • AD FS が実行する SQL で保存されたデータの SQL ベースの参照すべてにストアド プロシージャを使用することで、セキュリティを考慮した設計のアクセスを構成する。

    サービスとデータの分離をより確実にするために、すべての属性ストア参照コマンドのためにストアド プロシージャを作成できます。 次に、ストアド プロシージャを実行する権限を付与するデータベースの役割を作成できます。 このデータベースの役割に AD FS Windows サービスのサービス ID を割り当てます。 AD FS Windows サービスは、属性参照に使用される適切なストアド プロシージャを除いて、他の SQL ステートメントはすべて実行できないようにする必要があります。 このような方法で SQL Server データベースへのアクセスをロックダウンすることで、特権の昇格攻撃のリスクが低減されます。

参照

Windows Server 2012 での AD FS 設計ガイド