SQL Server データベース エラー 5123 の解決方法

なぜなら、SQL Server 2005 に基づくデータベース チュートリアルがあり、そこで使用されているサンプル データベースは AdventureWorks for SQL Server 2005 だからです。しかし、私のコンピューターには SQL Server 2008 がインストールされており、サンプル データベースは AdventureWorks for SQL Server 2008 です。最初は、サンプル データベース AdventureWorks for SQL Server 2005 と AdventureWorks for SQL Server 2008 のデータベース構造は似ているはずだと考えていましたが、実際に実行してみると、2 つのデータベース内の多くのテーブルの構造がまだ大きく異なっていることがわかりました。

そこで、スムーズに実習を行えるように、Microsoft ダウンロード センターから SQL Server 2005 用のサンプル データベース AdventureWorks をダウンロードし、SQL Server 2008 にアタッチすることにしました。

SQL Server 2008 スーパー管理者アカウント「sa」として SQLSERVER2008 インスタンスにログインします。

サンプル データベース AdventureWorks for SQL Server 2005 をアタッチすると、次のエラーが表示されます。

「CREATE FILE で物理ファイルを開いたり作成したりしようとしたときに、オペレーティング システム エラー 5 (アクセスが拒否されました) が発生しました...」というメイン情報をよく見ると、添付するデータ ファイルの操作権限が不十分であることが一目でわかりました。 一般的な思考習慣に従って、十分な操作権限を持たないファイルには十分な操作権限を付与します。たとえば、一部のネットユーザーは「添付するデータ ファイルと対応するログ ファイルへのアクセス許可を Everyone に付与する」と述べています。承認プロセスは次の 3 つのスクリーンショットに示されています (データ ファイルとログ ファイルの両方を承認する必要があることに注意してください)。

（図1：認証データファイル）

（図2：承認後のデータファイル）

（図3：認証後のログファイル）

アタッチするデータ ファイルとログ ファイルに対して Everyone に [読み取りと実行] および [読み取り] 権限を付与した後、SQL Server 2008 でデータベースを再度アタッチしようとしたところ、正常にアタッチできることが分かりました。問題はこうやって解決するのでしょうか？これは正しいやり方でしょうか? 実際のデータベース管理プロセスで、データ ファイルとログ ファイルの権限を Everyone に拡張すると、それは間違いなく間違ったアプローチになります。

データベースのセキュリティが大幅に低下するため、Everyone に [読み取りと実行] および [読み取り] 権限のみが付与されているにもかかわらず、データ漏洩のリスクが残っています。 データ ファイルには、通常どおりアクセスできるようにしながら、最小限のアクセス権しか持たないようにする必要があります。以前は Everyone を許可していたため、すべてのユーザーまたはアカウントが対応するファイルを操作でき、これは決して安全ではありません。

では、最小限のアクセス権を付与するにはどうすればよいでしょうか?考えてみてください。SQL Server 2008 を使用して対応するデータ ファイルを添付すると、「アクセスが拒否されました」というエラーが報告されます。これは、権限が不十分であることを意味します。つまり、現在の SQL Server 2008 には、これらのファイルにアクセスする権限がありません。以下に示すように、ファイルを右クリックしてファイルのプロパティに移動し、ファイルの権限を確認します。

（対応するデータファイルの元の権限）

このデータ ファイルを操作する権限を持つのは、SYSTEM および xrm グループまたはユーザーのみであることがわかりました。図に示すように、SYSTEM はユーザー グループ (つまり [Local System] グループ) であり、xrm は管理者ユーザーです。

(xrm ユーザー情報)

SYSTEM ユーザー グループと管理者ユーザー xrm は、どちらもこのデータ ファイルとログ ファイルを操作する権限を持っています。ただし、SQL Server 2008 のスーパー管理者 SA としてインスタンスにログインした後、SQL Server にはこのデータ ファイルにアクセスする権限がありません。つまり、SQL Server 2008 スーパー管理者 SA としてインスタンスにログインした後、ログインした ID は SYSTEM ユーザー グループに含まれず、管理者 xrm でもありません。

それは何でしょうか？ 現在の SQL Server 2008 インスタンス サービスの関連情報を確認することで確認できます。次の図に示すように、Sql Server 構成マネージャー (つまり、SQL Server 構成マネージャー) を開いて、現在接続されているインスタンス サービスの関連情報を確認します。

（現在のインスタンスサービスに関する関連情報）

現在のインスタンス SQLSERVER2008 のログイン ID は「NT AUTHORITY\LocalService」であり、これはオペレーティング システムによって承認された [ローカル サービス] であることがわかります。ローカル サービスはユーザー グループでもあります。つまり、[Local Service] ユーザー グループ (Everyone ではなく) にのみ権限を付与すると、SQL Server 2008 で sa アカウントを使用してデータベースをアタッチできるようになります。

このためには、対応するデータ ファイルとログ ファイルに対して Everyone に付与した権限を削除し、対応するデータ ファイルとログ ファイルに対して LocalService ユーザー グループに権限を付与して、対応するデータベースを再度アタッチしてみます。実際に正常にアタッチできることがわかります。言うまでもなく、[Local Service] ユーザー グループにオペレーティング システムの承認を付与することは、Everyone に付与するよりもはるかに安全です。

上記の方法では、データ ファイルの元の権限範囲を変更しました (元の権限範囲には、[ローカル システム] ユーザー グループである SYSTEM と、システム管理者である xrm のみが含まれます)。

より良い方法は、データ ファイルの権限スコープを変更しないことです。SQL Server 2008 インスタンスに SA としてログインして、対応するデータ ファイルにアクセスできます。

この目標を達成するには、対応するインスタンスのログイン ID を SYSTEM [ローカル システム] ユーザー グループに変更するだけです。SYSTEM は対応するデータ ファイルのアクセス許可範囲内のユーザー グループでもあり、SQL Server インスタンスはローカル システムとして実行されるため、セキュリティが強化されます。次の図に示すように、SQL Server 構成マネージャーで、対応する SQL Server インスタンスのログイン ID を [Local System] に変更できます。

(インスタンスのログインIDを変更する)

(インスタンスのログインIDはLocalSystemになります)

次に、対応するインスタンス サービスを再起動し、SQL Server 2008 の対応するインスタンスに SA として再接続してログインし、データベースのアタッチを試みます。データベースも正常にアタッチできます。 ！ ！

実際、対応するデータベースをアタッチするために、対応する SQL Server 2008 インスタンスに SA として接続する必要がない場合は、対応する SQL Server 2008 インスタンスに接続するときに、認証に [Windows 認証] を選択すると、前の記事で説明したように、他の変更を加えずにデータベースをアタッチできます。その理由は、[Windows 認証] では現在のオペレーティング システムのユーザーの権限が使用され、その権限は通常十分に大きいためです。また、[SQL Server 構成マネージャー] のインスタンス サービスに対して実行できる操作は、Windows の [サービス] でも実行できます。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。