ログ配布のセキュリティSQL Server構成する

この記事では、SQL Serverログ配布のセキュリティを構成する方法について説明し、ログ配布のセキュリティを構成するときに発生する可能性がある問題SQL Server情報を提供します。

元の製品バージョン: SQL Server
元の KB 番号: 321247

概要

この記事では、ログ配布のセキュリティを構成する方法について説明します。 トランザクション ログ バックアップが存在するネットワーク共有のアクセス許可を共有SQL Server、スタートアップ アカウントからその範囲のログ配布SQL Serverセキュリティを構成する場合は、考慮すべきいくつかの問題があります。 これらの問題については、この記事で説明します。

ドメイン アカウント

ドメインにSQL Serverを配置している場合は、ドメイン アカウントを使用してSQL Server サービスを開始することをお勧めします。 Windows クラスタリングで仮想サーバーとして実行するようにSQL Serverを構成する場合は、ドメイン アカウントを使用する必要があります。 ドメイン アカウントは、パスワードを変更した場合の最小限のメンテナンスの利点を提供します。 ただし、ワークグループ内のサーバーに存在SQL Server場合、ドメイン アカウントで SQL を起動できない場合があります。

ローカル ネットワーク アカウント

SQL Serverを使用して、ローカルに作成されたネットワーク アカウントで開始できます。 SQL Server プロセスで必要なネットワーク アクセスがある状況では、ログ配布を使用するようにSQL Server構成している場合は、ネットワーク パススルー セキュリティを使用できます。 パススルー セキュリティでは、SQL Serverによってアクセスされるすべてのマシンは、同じパスワードと適切なアクセス許可を持つ同じネットワーク アカウントを持ち、ローカルで構成されている必要があります。 さらに、SQL Server プロセスが 2 台目のコンピューターからリソースを要求すると、同じアカウント (要求元の SQL Server サービスが開始されている) が同じパスワードで存在する場合、従来のネットワーク セキュリティはバイパスされます。 2 台目のコンピューター上のアカウントが、SQL Serverを呼び出して要求されたタスクを実行するための十分なアクセス許可を持って構成されている限り、タスクは成功します。

ローカル システム アカウント

ローカル システム アカウントで開始するようにSQL Serverを構成することもできます。 LocalSystem アカウントのパスワードを変更すると、システムの安定性にとって重要な一部のサービスが失敗する可能性があります。 このアカウントは、そのアカウントが存在するコンピューターに対してローカルです。つまり、SQL Server サービスが使用するセキュリティ コンテキストはローカルです。 「ローカル ネットワーク アカウント」セクションで説明されているように、LocalSystem アカウントでSQL Serverを開始するときにネットワーク パススルー セキュリティを使用することはできません。これは、異なるコンピューター上の LocalSystem アカウントのパスワードが異なるためです。 ネットワーク リソースへのアクセスが必要な場合、このアカウントでSQL Serverが開始されると、タスクが正常に完了しない可能性があります。

ネットワーク アカウントがSQL ServerおよびSQL Server エージェントサービスを正常に開始して実行するために必要な最小限の権限については、「Windows サービス アカウントのセットアップ」を参照してください。

SQL Server セキュリティ モデルについて

セキュリティへの影響を完全に理解するには、Microsoft が 2000 年SQL Serverに実装したセキュリティ モデルを理解することが重要です。 ログインを作成すると、MASTER データベースの syslogins テーブルに追加されます。 この新しく追加されたログインがアクセス権を提供されるデータベースごとに、そのデータベース内の sysusers テーブルに追加されます。 テーブルとsysusersテーブルの間sysloginsのマッピングは SID フィールドにあります。

ユーザー データベースが別のサーバーに移動された場合、SID 値は前のサーバーから引き継がされます。 2 番目のサーバー上のログインが同じ SID 値で作成されていない場合、または SID 値が一致しないためにセキュリティが不適切に構成されている場合は、データベース セキュリティが中断されます。

詳細については、「SQL Serverを実行しているサーバー間でデータベースを移動するときのアクセス許可の問題を解決する方法」を参照してください。

セキュリティ要件

• バックアップ共有

  (ログ配布用に構成されているセカンダリ サーバー上の) SQL Server サービスが開始されているアカウントの読み取り/変更アクセス許可を持つトランザクション ログ バックアップを保持するように構成されているネットワーク共有を構成します。

  トランザクション ログ バックアップを保持するように構成されているネットワーク共有は、ログ配布用に構成されたセカンダリ サーバー上のSQL Server サービスが開始されているアカウントの読み取り/変更アクセス許可を持つよう構成する必要があります。 この共有には、セカンダリ サーバー上のコピー ジョブによってアクセスされ、トランザクション ログ バックアップを各セカンダリ サーバーのローカル フォルダーにコピーします。 その後、Load ジョブはローカル フォルダーからこれらのバックアップを読み込みます。

• クロス ドメイン ログ配布

  SQL Serverを実行しているコンピューターがマルチドメイン環境に配置されている場合、ログ配布に関係するすべてのドメイン間で双方向の信頼を設定することをお勧めします。 ただし、ドメイン間で信頼を確立できない場合は、ネットワーク パススルー セキュリティを使用してログ配布を行うことができます。 SQL Server関連サービスの LocalSystem ネットワーク アカウントのスタートアップ オプションについて説明する、この記事のセクションを参照してください。

• 監視サーバーに接続するための認証モードの選択

  Windows 認証認証または SQL 認証 (プライマリ サーバーとセカンダリ サーバー) のいずれかを選択して、モニター サーバーに接続し、モニター テーブルを更新できます。 これは、ログ配布の設定中、またはログ配布を設定して機能した後で選択できます。 既定では、SQL ServerはWindows 認証を使用します。ただし、SQL 認証を選択すると、プライマリ、セカンダリ、および監視サーバーに新しい SQL ログイン log_shipping_monitor_probeが作成されます (存在しない場合)。 この目的で [SQL 認証] を選択した場合は、[SQL と Windows 認証] オプションを使用するようにSQL Serverを構成します。

スタンバイ データベースのセカンダリ サーバーでのセキュリティ構成

セカンダリ データベースをスタンバイ モードで構成した場合は、読み取り専用の状態でこのデータベースにアクセスできます。 このモードでセカンダリ データベースを復元することで、オフライン レポートを実行し、運用システムから作業の一部をオフロードする手段を提供できます。 ただし、スタンバイ データベースが読み取り専用機能をサポートするには、セカンダリ サーバーに同じセキュリティ設定を適用する必要がある場合があります。 データベースはスタンバイ状態であるため、セキュリティの構成のために変更を加えることさえできません。 この場合、セカンダリ サーバーで同じ SID 値を持つすべてのSQL Server ログインを作成する必要があります。 複数のドメインを使用する場合でも、Windows GUID はグローバルに一意であるため、Windows ログインでは同じ SID が自動的に保持されます。

異なるサーバーで同じ SID を使用して SQL ログインを作成する方法の詳細については、「SQL Serverでゲストが無効になっているときにスタンバイ データベース上の SQL ログインへのアクセスを許可する方法」を参照してください。

ロールの変更を実行するときのセキュリティ構成

ログ配布のロール変更手順では、セカンダリ サーバーをプライマリとして引き継ぐよう昇格する必要があります。 これは、プライマリ サーバーがオンラインになっている場合とない場合に実行できます。 ロールの変更の一環として、最大 4 つのストアド プロシージャが実行されます。 これらのストアド プロシージャの 1 つである は、 sp_resolve_logins プライマリ データベースとして使用できるようになる直前に、スタンバイ データベースに存在するログインの SID 値を修正するのに役立ちます。

このストアド プロシージャの一部として、 .bcp 以前のプライマリ サーバーのテーブルの syslogins ファイルが一時テーブルに読み込まれます。 この一時テーブルに存在する各ログインは、セカンダリ サーバーの syslogins MASTER データベース内のテーブルとセカンダリ データベースのテーブルと sysusers 比較されます。 テーブルに同じ名前 syslogins のログインがあり、セカンダリ データベースのテーブル内の SID と同じ SID sysusers を持つ一時テーブル内のログインごとに、 を使用 sp_change_users_login して、テーブル内 syslogins のログインと一致するように SID が修正されます (セカンダリ データベース内)。

このストアド プロシージャを使用したセキュリティ構成には、次のものが必要です。

• SQL ログインは、セカンダリ サーバーに既に作成されている必要があります。 そのためには、「オンラインブック」トピック「ログ配布ロールの変更を設定して実行する方法」SQL Server説明されているログインの転送 DTS タスクを使用します。

• プライマリ サーバーからテーブルのファイルをsyslogins指定.bcpする必要があります。 古いファイルによってログインの修正が失敗する可能性があるため、このファイルは最新である必要があります sp_resolve_logins 。

セカンダリ データベース内のログインを実際に修正するには、次の 3 つの条件 sp_resolve_logins を満たす必要があります。

1. テーブルのファイルからの .bcp ログイン名は、 syslogins プライマリ サーバーのテーブル内の syslogins 名前と一致している必要があります。

2. SID 値は、ファイルのログイン .bcp とセカンダリ データベース内の sysusers テーブルの間で一致する必要があります。

3. セカンダリ データベースの SID 値は、セカンダリ サーバー上の MASTER データベースの syslogins テーブル内の SID 値とは異なる必要があります。

Q303722で説明されているようにSQL Serverログインを作成する場合、すべてのログインがテーブル (セカンダリ サーバーの MASTER データベース内) とテーブル (セカンダリ データベース内) にsyslogins同じ SID 値で既に提示されているため、このストアド プロシージャをsysusers実行する必要はありません。

よく寄せられる質問

• 質問: ログ配布では、セキュリティ関連の変更がセカンダリ サーバーに自動的に反映されますか?

  回答: はい。 システム テーブルに対するすべての変更はログに記録された操作であるため、これらは自動的にセカンダリ サーバー (またはサーバー) に伝達されます。

• 質問: 同じ SID を持つセカンダリ サーバーに 2 つのログインがありますか? 私は複数のサーバーから複数のスタンバイデータベースを維持するために同じSQL Serverコンピュータを使用しているので、私はこれを必要とします。

  回答: いいえ。 SQL Serverセキュリティ モデルでは、同じ SID を持つ 2 つのログインを許可しません。 複数のサーバーでログ配布を使用しているときに SID で競合が発生した場合、これを修正する唯一の方法は、プライマリ サーバーで競合しているログインを削除してから、セカンダリ サーバーに存在しない SID を使用して作成することです。