Microsoft Visual Studio 2005 Team Edition for Database Professionals のセキュリティの概要
Richard Waymire
Microsoft Corporation
January 2007
適用対象 :
Microsoft Visual Studio 2005 Team Edition for Database Professionals
概要: Microsoft Visual Studio 2005 Team Edition for Database Professionals (DB Pro) は、Microsoft Visual Studio Team Suite に最も新しく加わった製品です。この製品の役目は、データベース アプリケーション コード (Microsoft SQL Server 2000 および Microsoft SQL Server 2005 用の Transact-SQL) の開発者をアプリケーション開発ライフ サイクルに導くことにあります。Visual Studio 2005 Team Edition for Database Professionals の詳細は、製品情報のページを参照してください。
全体的なライフ サイクルへのデータベース開発の統合を最も効率よく行うには、Team Edition for Database Professionals におけるセキュリティの多彩な内容を理解している必要があります。そのような内容の例としては、製品のセットアップおよび構成をさらに安全に行う方法、製品のセキュリティ関連機能の使用方法、およびデータベース プロジェクトをさらに安全に実装するための、ベスト プラクティスなどがあります。
(本ドキュメントは https://msdn2.microsoft.com/en-us/library/bb264457(vs.80).aspx にて公開されているドキュメントの翻訳ドキュメントです)
目次
インストールおよび構成の権限
スキーマの開発および配置の権限
データベース プロジェクトにおけるセキュリティ オブジェクト
外部アクセスを伴った機能でのセキュリティの考慮事項
まとめ
インストールおよび構成の権限
Team Edition for Database Professionals のインストール時には、インストール内容のセキュリティを強化するためにいくつかのコンポーネントを構成する必要があります。
Team Edition for Database Professionals のインストールおよび実行
Team Edition for Database Professionals をインストールするには、ローカル コンピュータに対する管理権限を持ったアカウントを使用してログオンする必要があります。インストール中に、ファイルおよびレジストリ キーの作成、およびグローバル アセンブリ キャッシュへのアセンブリの登録を行います。
しかし、Team Edition for Database Professionals を実行するのに必要なのは、この後の項に述べているとおり、Windows に対する標準のユーザー権限および SQL Server 2005 に対する権限のみです。既定では、すべてのユーザー設定は、レジストリの HKEY_CURRENT_USER 部分またはドライブ:\\マイ ドキュメント ディレクトリに保存されます。
本稿の執筆時には、Team Edition for Database Professionals では Windows Vista はサポートされていませんでした。
SQL Server 2005 のインストール
Team Edition for Database Professionals と同じコンピュータに SQL Server 2005 がまだインストールされていない場合、そのコンピュータに対する管理権限を持ったアカウントを使用してログオンし、以下のうちの 1 つをインストールする必要があります。
- SQL Server 2005 Developer Edition
- SQL Server 2005 Enterprise Edition
- SQL Server 2005 Enterprise Evaluation Edition
Visual Studio 2005 Professional Edition または Visual Studio Team Edition を保有している場合、その製品用のインストール メディアから SQL Server 2005 Developer Edition をインストールすることができます。
DesignDB インスタンスとして知られるこの SQL Server インスタンスは、データベース プロジェクトをサポートするための検証エンジンとして機能します。この SQL Server インスタンスを直接使用する必要は生じないかもしれませんが、データベース プロジェクトを作成して使用するには、SQL Server データベース エンジン (MSSQLServer) サービスが実行されている必要があります。
DesignDB インスタンスのサービス アカウントは、ローカル システム アカウントであるか、または Visual Studio のターゲット ユーザーとして実行中である必要があります。
SQL Server 2005 のセキュリティを高める方法 (ベスト プラクティスも含む) の詳細は、SQL Server 2005 の技術文書ライブラリの中の「SQL Server 2005: Security and Protection」 (英語) を参照してください。
SQL Server のその他のコンポーネントのインストールおよび有効化
SQL Server のフルテキスト インデックス サービスを参照するプロジェクトの作成または使用を予定している場合、SQL Server 2005 のインストールと同時にフルテキスト検索サービスもインストールする必要があります。SQL Server 2005 Developer Edition および SQL Server 2005 Enterprise Edition の場合、既定でこのサービスがインストールされます。
データベース プロジェクト中で SQL 共通言語ランタイム (SQLCLR または .NET アセンブリ) を使用する予定の場合、これは既定では無効になっているので、有効化する必要があります。SQLCLR を有効にするには、SQL Server の DesignDB インスタンスに対するシステム管理者権限を受けたアカウントを使用して、Windows にログオンする必要があります。SQL Server のインストール後、SQL Server 2005 Surface Area Configuration ユーティリティを使用するか、または Transact-SQL コードを実行することによって、SQLCLR の構成が可能になります。
Surface Area Configuration ユーティリティを開くには、[スタート] をクリックし、[すべてのプログラム] をポイントし、[Microsoft SQL Server 2005] をポイントし、[構成ツール] をポイントしてから、[SQL Server Surface Area Configuration] をクリックします。DesignDB のインストールで使用する予定の SQL Server インスタンスを指定するには、ツリー内のインスタンスをクリックします。(図 1 でのインスタンス名は SQLEXPRESS です。) 指定したインスタンスに対して SQLCLR を有効化するには、ツリーの [CLR 統合] をクリックし、[CLR 統合を有効にする] チェック ボックスを選択して、[OK] をクリックします。指定した SQL Server インスタンスに対して変更が即時に行われます。
図 1. SQL Server 2005 Surface Area Configuration ユーティリティでの CLR 統合の有効化 (図をクリックすると拡大表示されます)
それに代わる方法として、SQL Server の sysadmin サーバー ロールをもったメンバとして DesignDB インスタンスに接続したうえで、次のような Transact-SQL コードを実行することもできます。
Exec sp_configure 'clr enabled', 1
Go
Reconfigure with override
Go
このステップを完了すると、SQL Server 2005 用のデータベース プロジェクトの一環として CLR オブジェクトをチームで作成できるようになります。
SQL Server 用の Windows セキュリティ グループの作成
多くの人が実行時には、SQL Server のローカルのプライベート コピーに対する sysadmin 権限を使用します。しかし通常は、DesignDB インスタンスの使用時には、それほどのアクセス権は必要ありません。ベスト プラクティスとしては、ローカル コンピュータ上で Windows セキュリティ グループを作成し、その DesignDB インスタンスを使用するすべてのユーザーを、そのセキュリティ グループのメンバに加えてから、そのグループに SQL Server へのアクセス権を認可することを検討してみることができます。
コマンド プロンプト ウィンドウで、次のように入力します。
Net localgroup 'VSTEDPUsers' /ADD
Net localgroup 'VSTEDPUsers' <YourUserName> /ADD
Windows セキュリティ グループに加える予定の各ユーザーごとに、それぞれ net localgroup コマンドを 1 回実行します。
あるいは、グラフィカル インターフェイス (Microsoft Windows XP 上の) で、次のようにします。
- [スタート] をクリックしてから、[コントロール パネル] をクリックします。
- [管理ツール] をダブルクリックしてから、[コンピュータの管理] をダブルクリックします。
- コンソール ツリーで [システム ツール] を展開し、[ローカル ユーザーとグループ] を展開してから、[グループ] をクリックします。
- [操作] メニューで [新しいグループ] をクリックします。
- [グループ名] に新規グループの名前を入力します (ここの例では VSTEDPUsers)。
- [説明] に新規グループの説明を入力します。
- 1 人以上のユーザーを新規グループに追加する場合は、[追加] をクリックします。
- [作成] をクリックしてから [閉じる] をクリックします。
セキュリティ グループを作成した後、Visual Studio のクエリ エディタのインスタンス、SQL Server Management Studio、または sqlcmd などのコマンド行ユーティリティを使用して、SQL Server に再度接続します。次のような Transact-SQL を実行して、Windows セキュリティ グループを SQL Server の有効なログインとして加えてから、そのログインを、SQL Server 内の dbcreator および securityadmin サーバー ロールのメンバにします。
CREATE LOGIN [ComputerName\VSTEDPUsers] FROM WINDOWS
EXEC sp_addsrvrolemember 'ComputerName\VSTEDPUsers','dbcreator'
EXEC sp_addsrvrolemember 'ComputerName\VSTEDPUsers','securityadmin'
GRANT VIEW SERVER STATE TO [ComputerName\VSTEDPUsers]
Team Edition for Database Professionals では、SQL Server の DesignDB インスタンス用として、この最低限の一連の権限が必要です。このサーバー ロールの詳細は、SQL Server 2005 Books Online の中の「Server-Level Roles」を参照してください。
スキーマの開発および配置の権限
組織環境の理解
他の Windows アプリケーションと同様に、データベース スキーマのアプリケーション開発ライフ サイクルでも、その一環としてテスト配置を行います。テスト配置の最終目的は当然、実働サーバーに対するスキーマの変更内容の配置です。ただし、たいていの環境では、データベース開発者は実働環境にアクセスできません。そのような状況は、Team Edition for Database Professionals のユーザーにとって障壁となります。通常のデータベース開発者は、実働システムからのスキーマ情報の読み取りは言うまでもなく、ログインする権限も与えられません。
したがって、Team Edition for Database Professionals の通常の使用シナリオには、データベース スキーマをビルドして配置するユーザーが少なくとも 2 人関与することになります。つまり、実働データベースへのアクセス権限を受けたデータベース管理者またはその他の担当者がデータベース プロジェクトを作成したうえで、既存のデータベース スキーマをその実働環境からインポートします。そのアクションによって、該当データベースのすべてのスキーマ情報がデータベース プロジェクト内のファイルにダウンロードされます。
データベース管理者がそのプロジェクトを保管してソース管理システムにチェックインした後、データベース開発者 (元の実働システムに対する権限を持っているとは限らない) が、そのスキーマのテスト配置の処理、変更、およびビルドを行うことができます。テスト配置は、まず開発者の「サンドボックス」に対して行うことになります。「サンドボックス」とは、データベース開発者の完全な管理下に置かれた、個人用のターゲット データベースのことです。それ以外に開発者は、サンドボックス内の情報およびスキーマの削除および置き換えを自在に行って、テストを簡単に行えるようにすることができます。開発者は、スキーマを変更し、データ生成計画またはそのスキーマ用の計画をたて、ストアド プロシージャ、関数、およびその他のオブジェクト用の単体テストを作成することができます。開発者は次に、サンドボックスに対してスキーマを配置し、そのスキーマ内のテーブル用のデータを生成し、そして単体テストを実行します。
開発者がスキーマの変更を終了し、テストの結果が完了しており、正しいことを検証したら、統合テスト環境に対してプロジェクトを配置することができます。他の開発者の作業に照らして変更内容をテストし、その変更内容を実働状態に移行する準備が整ったら、データベース管理者 (または、該当する権限を受けた別のユーザー) が、プロジェクトを開き、最終ビルドを行い、そしてその変更内容を配置することができます。
環境別の権限の設定
上記のそれぞれの環境で必要な権限は、厳密にどのアクションをとる予定であるかによって異なります。しかし、どの環境でも、ある一定の一般的なガイドラインに従うことができます。
サンドボックス
サンドボックスは、1 人の開発者の専用であり、通常は、ローカル側またはリモート側でインストールされる SQL Server 2000 または SQL Server 2005 環境です。サンドボックスは、プロジェクトを繰り返し配置する先のターゲットですが、ここではほぼ確実に開発者がデータベースを作成する必要が生じます。したがって、開発者は、CREATE DATABASE 権限または dbcreator サーバー ロールのメンバシップを持っている必要があります。ターゲット データベースが SQL Server 2005 であって、EXTERNAL_ACCESS または UNSAFE オプションを設定した CLR アセンブリを使用する計画をたてている場合、開発者は、そのサンドボックスに対する sysadmin ロールのメンバにならなければなりません。
統合テスト
開発者は、統合テスト環境での作業時には、サンドボックスの場合と同じような権限を受けている必要があります。ただし、既存のデータベースに対して変更内容を配置するだけの場合、ターゲット データベースでのスキーマの更新の権限と、データ生成計画によってデータを埋め込まれるテーブルの挿入、更新、および削除の権限しか開発者には必要ありません。
実働
実働環境では、データベース スキーマを更新する権限は、操作担当者とデータベース管理者のみに与えられなければなりません。実際にチーム メンバが必要とする権限は、変更内容の具体的な性質によって決まります。たとえば、新規のデータベースを配置するときは、チーム メンバには CREATE DATABASE 権限が必要になります。それ以外の場合、変更する予定の各オブジェクトに対する権限がチーム メンバにとって必要になり、配置前および配置後のスクリプトによってサーバー設定が変更される場合は、さらに別の権限も必要になります。配置を正常に完了するには、チーム メンバは変更内容を、データベースにアクセスするアプリケーションでの変更内容に完全に一致させる必要があります。それ以外に、変更内容を配置する前に、影響を受けるすべてのデータベースのバックアップをとる必要もあります。
データベース プロジェクトにおけるセキュリティ オブジェクト
データベース プロジェクト内のセキュリティ オブジェクトは、プロジェクトでサポートされる SQL Server のバージョンによって異なります。一部のオブジェクトは、配置前および配置後のスクリプトを通して処理されますが、大半のオブジェクトは、中心的プロジェクト オブジェクトとして組み入れられます。
SQL Server 2000 のデータベース プロジェクト
SQL Server 2000 のセキュリティ関連オブジェクトは、データベース プロジェクトのフル メンバとして処理されるか、または配置前および配置後のスクリプトを通して処理されます。
データベース プロジェクトにおけるセキュリティ オブジェクト
データベース プロジェクトは、ユーザー、アプリケーション ロール、およびデータベース ロールを直接サポートします。
ユーザーの追加
SQL Server 2000 でターゲットとされるデータベース プロジェクトの場合、プロジェクトへのユーザーの追加時の既定のストアド プロシージャは sp_grantdbaccess です。
ユーザーの SQL Server ログイン名を指定する必要があります。また、データベースで使用するための名前を指定することもできます。データベースで使用する名前を指定しないと、既定によって SQL Server ログイン名が使用されます。
sp_grantdbaccess [@loginame=] 'login' [,[@name_in_db=] 'name_in_db'
[OUTPUT]]
ユーザーをデータベース プロジェクトに追加する (データベース プロジェクトでの他のすべてのエントリと同様に) と、データベース プロジェクトをサポートする DesignDB インスタンス内にそのユーザーが作成されます。ただし、サポートする SQL Server ログインがなければ、SQL Server 2000 内のデータベースにユーザーを追加できません。この制限事項をう回するためにプロジェクト システムは、sp_addlogin の呼び出しを使用して、sp_grantdbaccess ストアド プロシージャ呼び出し内にスクリプト記述されている名前で SQL Server ログインを動的に生成します。SQL Server ログインが DesignDB インスタンス内に既に存在しても、エラー条件にはなりません。なぜなら、既存の SQL Server ログインは再利用可能であるため、SQL Server ログインの作成は必要なくなるからです。ただし、スクリプトまたはスキーマのインポート時のように、Logins.sql 配置前スクリプトに対して自動的に SQL Server ログインがスクリプト記述されることはありません。
必要があれば、sp_adduser を使用してユーザーをデータベース プロジェクトに追加することができます。ただし、SQL Server 2000 ではこのストアド プロシージャは、下位互換性のためにのみ使用されるものであり、推奨されていません。
アプリケーション ロールの追加
sp_addapprole システム ストアド プロシージャを使用して、アプリケーション ロールを追加できます。このストアド プロシージャを使用する場合、ロール名を指定する必要があります。また、パスワードを指定することもできます。
Sp_addapprole [ @rolename = ] 'role' , [ @password = ] 'password'
パスワードを指定すれば、アプリケーションのアクセス権をスキーマ オブジェクトにまで引き上げた場合のリスクが軽減されます。ただし、そのパスワードは、データベース プロジェクトの一部としてプレーン テキストで保管されることになります。パスワードを指定する場合、プロジェクト ファイルを暗号化して、そのパスワードを無許可アクセスから保護するよう配慮する必要があります。
データベース ロールの追加
sp_addrole ストアド プロシージャを使用して、データベース ロールを追加することができます。このストアド プロシージャを使用する場合、ロール名を指定する必要があります。また、そのロールの所有者を指定することもできます。(所有者は、データベース内で有効なユーザーでなければなりません。)
sp_addrole [ @rolename = ] 'role'[ , [ @ownername = ] 'owner' ]
ただしデータベース ロールのメンバシップは、ロール作成スクリプトの一部として追加されません。配置後のスクリプトの中で、データベース ロールにユーザーをマッピングするスクリプトを記述する必要があります。RoleMemberships.sql スクリプトを使用して、sp_addrolemember の呼び出しを追加しなければなりません。既存のデータベース スキーマをインポートすると、sp_addrolemember を呼び出す形でロール メンバシップの呼び出しが、この配置後ファイルに組み入れられます。
配置前および配置後のスクリプト
その他のオブジェクトは、データベース プロジェクト内で直接処理されるのでなく、配置前および配置後のスクリプト内でのスクリプト記述によって処理されます。これらのファイル内のオブジェクトは、DesignDB インスタンスでは作成されない (前述の SQL Server ログインは除いて) ので、これらのスクリプトを直接編集して変更する必要があります。データベース プロジェクトには、これらのファイルに対するその他のサポートは用意されていません。ただし、ファイルの作成および配置の前に、このファイルの構文が Team Edition for Database Professionals によって検査されます。
ログインの追加
Logins.sql ファイルは、配置前スクリプト ファイルとして追加されます。このファイルには、データベースに追加されるユーザーをサポートする SQL Server ログイン用の sp_addlogin の呼び出しが入ります。 既存のデータベース スキーマをインポートする場合、ソース サーバーの SQL Server ログインはプロジェクトにはインポートされません。 プロジェクトでデータベース ユーザーをサポートするのに明示的に必要とされた SQL Server ログインだけが、このスクリプト ファイルに自動的に追加されます。それ以外の SQL Server ログインを配置時にサーバーに追加する必要がある場合、このスクリプト ファイルに追加する必要があります。
リンク サーバーの追加
リンク サーバーは、データベース プロジェクトのインポート機能ではスクリプト記述されません。リンク サーバーを作成するスクリプト (sp_addlinkedserver) を持ったスクリプトをインポートする場合、その呼び出しは、LinkedServers.sql ファイルへ送られます。
権限のインポートおよび作成
既存のスキーマまたはスクリプトをインポートすると、権限は Permissions.sql ファイルに送られます。そのような権限には、すべての認可、取り消し、および拒否の権限があり、それらはスクリプト内に存在するか、またはスキーマのインポート時にはソース データベース内に存在します。
SQL Server 2005 のデータベース プロジェクト
SQL Server 2005 のデータベース プロジェクトには、SQL Server 2000 データベース プロジェクトよりも多くのセキュリティ オブジェクトがあります。しかも、同じオブジェクトの作成でも、その構文が大幅に変更されているものがあります。
データベース プロジェクトにおけるセキュリティ オブジェクト
SQL Server 2005 のデータベース プロジェクトは、スキーマ、ユーザー、アプリケーション ロール、およびデータベース ロールを直接サポートします。
スキーマの作成
スキーマは、SQL Server 2000 にも存在していましたが、オブジェクト作成スクリプトを囲む無名のラッパーにすぎませんでした。SQL Server 2005 ではスキーマは、データベース内のオブジェクト用の名前空間です。データベース プロジェクトは、CREATE SCHEMA ステートメントを使用したスキーマの作成をサポートします。
CREATE SCHEMA schema_name_clause [ <schema_element> [ ...n ] ]
<schema_name_clause> ::=
{
schema_name
| AUTHORIZATION owner_name
| schema_name AUTHORIZATION owner_name
}
<schema_element> ::=
{
table_definition | view_definition | grant_statement
revoke_statement | deny_statement
}
データベース プロジェクト内でのスキーマの追加の場合、schema_element 句はサポートされません。この句は、SQL Server 2000 スキーマへの下位互換のためのものです。
スキーマ名は、他のオブジェクトの名前空間になります。例をあげると、多数のデータベースで使用される既定のスキーマ「dbo」などがあります。
データベース プロジェクトにスキーマを追加すると、そのスキーマは DesignDB インスタンスに追加されます (構文的に正しいことを前提とします)。
ユーザーの追加
SQL Server 2005 では、ストアド プロシージャではなく CREATE USER ステートメントを使用して、データベースにユーザーを追加します。sp_grantdbaccess ストアド プロシージャを使用してもかまいませんが、推奨されません。
CREATE USER user_name [ { { FOR | FROM }
{
LOGIN login_name
| CERTIFICATE cert_name
| ASYMMETRIC KEY asym_key_name
}
| WITHOUT LOGIN ]
[ WITH DEFAULT_SCHEMA = schema_name ]
SQL Server 2000 ではユーザーは名前空間の一部を成すため、データベース プロジェクトのフル メンバであることが不可欠です。ただし、SQL Server 2005 でも同じ要件が適用されるとは限りません。ユーザーではなく、スキーマが名前空間参照になります。ユーザーには、スキーマと同じ名前が付いていてもかまいませんが、これらは 2 つの別々のデータベース オブジェクトになります。実際、SQL Server 2005 で sp_grantdbaccess を使用した場合、同じ名前の付いたユーザーとスキーマが自動的に作成されます。
既定では、SQL Server 2005 のデータベース プロジェクト内のユーザーは、WITHOUT LOGIN 句を使用して作成されるので、それに一致する SQL Server ログインは自動生成されません。ただし、SQL Server ログイン参照を指定した場合は、SQL Server 2000 のデータベース プロジェクトの場合と同じロジックが使用されて、サポートする側の SQL Server ログインが DesignDB インスタンス内に作成されます。ただし、スクリプトまたはスキーマのインポート時のように、Logins.sql 配置前スクリプトに対して自動的に SQL Server ログインがスクリプト記述されることはありません。
証明書または非対称鍵への参照を指定してユーザーを作成すると、Team Edition for Database Professionals では証明書または非対称鍵が DesignDB インスタンス内で自動的に作成されて、ランダム生成されたパスワードを持ったユーザーがサポートされます。ただし、証明書または非対称鍵スクリプトは、自動的に生成されることも、EncryptionKeysandCertificates.sql 配置前スクリプトに追加されることもありません。CREATE CERTIFICATE または CREATE ASYMMETRIC KEY ステートメントをこのファイルに手動で追加して、該当するデータベース ユーザーの配置をサポートする必要があります。
アプリケーション ロールの追加
CREATE APPLICATION ROLE ステートメントを使用するか、または、下位互換性のある sp_addapprole ストアド プロシージャを使用して、アプリケーション ロールを追加することができます。前述のとおり、アプリケーション ロールの名前を指定するとともに、SQL Server 2005 でのパスワードも指定する必要があります。
CREATE APPLICATION ROLE application_role_name
WITH PASSWORD = 'password' [ , DEFAULT_SCHEMA = schema_name ]
ここでも、アプリケーション ロールに対するプロダクション パスワードをオフラインでファイルに保管してもよいかどうかを慎重に検討しなければなりません。その情報を保管する必要がある場合、無許可アクセスから保護できるよう、そのファイルの暗号化を図る必要があります。
データベース ロールの追加
CREATE ROLE ステートメントを使用するか、または下位互換性のある sp_addrole ストアド プロシージャを使用して、データベース ロールを追加することができます。
CREATE ROLE role_name [ AUTHORIZATION owner_name ]
ただしデータベース ロールのメンバシップは、ロール作成スクリプトの一部として追加されません。配置後のスクリプトの中で、データベース ロールにユーザーをマッピングするスクリプトを記述する必要があります。RoleMemberships.sql スクリプトを使用して、sp_addrolemember の呼び出しを追加しなければなりません。既存のデータベース スキーマをインポートすると、sp_addrolemember を呼び出す形でロール メンバシップの呼び出しが、この配置後ファイルに組み入れられます。
配置前および配置後のスクリプト
その他のオブジェクトは、データベース プロジェクト内で直接処理されるのでなく、配置前および配置後のスクリプト内でのスクリプト記述によって処理されます。これらのファイル内のオブジェクトは、DesignDB インスタンスでは作成されない (前述の SQL Server ログインは除いて) ので、これらのスクリプトを直接編集して変更する必要があります。データベース プロジェクトには、これらのファイルに対するその他のサポートは用意されていません。ただし、ファイルの作成および配置の前に、このファイルの構文が Team Edition for Database Professionals によって検査されます。
ログインの追加
Logins.sql ファイルは、配置前スクリプト ファイルとして追加されます。このファイルには、データベースに追加されるユーザーをサポートする SQL Server ログイン用の CREATE LOGIN (ただし、SQL Server 2000 との下位互換性を保つ場合は sp_addlogin) の呼び出しが入ります。データベース スキーマをインポートする場合、ソース サーバーの SQL Server ログインはプロジェクトにはインポートされません。プロジェクトでデータベース ユーザーをサポートするのに明示的に必要とされた SQL Server ログインだけが、このスクリプト ファイルに自動的に追加されます。それ以外の SQL Server ログインを配置時にサーバーに追加する必要がある場合、このスクリプト ファイルに追加する必要があります。
リンク サーバーの追加
リンク サーバーは、データベース プロジェクトのインポート機能ではスクリプト記述されません。リンク サーバーを作成するスクリプト (sp_addlinkedserver) を持ったスクリプトをインポートする場合、その呼び出しは、LinkedServers.sql ファイルへ送られます。
権限のインポートおよび作成
スキーマまたはスクリプトをインポートすると、権限は Permissions.sql ファイルに送られます。そのような権限には、すべての認可、取り消し、および拒否の権限があり、それらはスクリプト内に存在するか、またはスキーマのインポート時にはソース データベース内に存在します。このセットには、SQL Server 2005 においてデータベース ユーザーを有効化する CONNECT 権限も入っています。
証明書および鍵の作成
EncryptionKeysandCertificates.sql 配置前ファイルには、証明書、非対称鍵、または対称鍵を作成するための呼び出しが入っています。それ以外に、このファイルを使用して、データベース マスタ キーを作成することもできます。通常、これらの種類のオブジェクトはいずれも、パスワードを持っていて、DesignDB インスタンスから取り消すことはできません。したがって、このようなオブジェクトの追加または変更は、この配置前スクリプトの一部として手動で行う必要があります。このファイルには、次のようなステートメントが入っていなければなりません。
CREATE MASTER KEY
CREATE CERTIFICATE
CREATE ASYMMETRIC KEY
CREATE SYMMETRIC KEY
このようなオブジェクトを収めたスキーマをインポートした場合、そのオブジェクトは Schema Compare によってサポートされないため、スクリプト記述されません。ただし、スケルトン スクリプトまたはコメント付きステートメントは、該当する配置前スクリプト ファイル (EncryptionKeysandCertificates.sql) に移動されます。
署名の追加
配置後ファイル Signatures.sql には、ADD SIGNATURE ステートメントを使用してデジタル署名をデータベース オブジェクトに追加する呼び出しが入っています。署名の入ったスキーマをインポートしても、その署名は組み入れられていません。ただし、ADD SIGNATURE ステートメントを収めたスクリプトをインポートした場合、その呼び出しは配置後スクリプト ファイルに移動されます。
外部アクセスを伴った機能でのセキュリティの考慮事項
Team System for Database Professionals の機能の多くは、データベースなどの外部リソースにアクセスします。この項では、そのような機能でのセキュリティ上の考慮事項を考察し、その使用にあたって必要となる権限について説明します。
ディスク上のプロジェクト ファイルの保護
プロジェクトを無許可アクセスから保護するには、NTFS ファイル システムを使用し、プロジェクトを保管するディレクトリに対する権限を、そこにアクセスする必要のある最小数のユーザーに限定する必要があります。また、暗号化ファイル システム (EFS) あるいはその他の暗号化技法を使用して、プロジェクト ファイルをローカル側で保護する方法も検討する必要があるかもしれません。既定では、プロジェクトはドライブ:\\マイ ドキュメント\Visual Studio 2005\Projects ディレクトリ内に作成されます。ここにアクセスできるのは、現在ログオン中のユーザーのみです。既定のプロジェクト ディレクトリを変更する場合、同様の権限を親ディレクトリに対して設定する必要があります。
このファイルをソース管理に保管する (これを強くお勧めします) 場合、機密プロジェクト (あるいは、プロジェクトのパスワードを収めるファイルなどの機密ファイルも含む) へのアクセスを、このファイルにアクセスする必要のある最小数のユーザーに限定するよう配慮する必要があります。
スキーマのインポート
SQL Server 2000
SQL Server 2000 からスキーマをインポートするには、インポートしようとしているスキーマを持ったデータベースに対して、有効なデータベース ユーザー権限を持っていなければなりません。SQL Server 2000 には明確なメタデータ権限は設けられていないので、データベースのすべてのユーザーがスキーマ定義を読み取ることができます。
ただし、オブジェクト定義中に WITH ENCRYPTION オプションを持ったストアド プロシージャ、トリガ、ビュー、および関数などのオブジェクトにユーザーがアクセスすることはできません。このオプションが組み入れられている場合、syscomments システム テーブル内のそのようなオブジェクトのテキストは難読化されていて、ソース データベースからリバース エンジニアリングすることもできません。インポート操作において暗号化されたオブジェクトが検出された場合、Visual Studio のエラー一覧ウィンドウに警告が表示されて、オブジェクトのスクリプトは作成されません。
SQL Server 2005
SQL Server 2005 では、オブジェクト定義を表示する機能 (メタデータ権限と呼ばれます) は自動ではありません。ユーザーは、データベース プロジェクトへのインポート候補にしたいオブジェクトを表示するには、該当する各オブジェクトに対して VIEW DEFINITION 権限を持っている必要があります。db_owner などの一部のデータベース ロールの場合、そのメンバに自動的に権限が認可されます。さらにオブジェクト所有者は、自分が所有するオブジェクトの定義を必ず表示することができます。
データベースのすべてのユーザーは、パーティション構成、パーティション関数、ファイル グループ、およびスキーマの定義を必ず表示することができます。
ビルドおよび配置
ビルド コマンドを使用すると、プロジェクトを表すスクリプトが作成されます。このスクリプトは、プロジェクト ディレクトリ (既定では \sql ディレクトリ) の下の .sql ファイルになります。データベース プロジェクトに関する機密情報を収める可能性のある、他のファイルを保護するのと同様に、このファイルも保護する必要があります。このスクリプトは、単一のファイルであり、すべてのスキーマ オブジェクトのスクリプト (ただし、既存のデータベースへの配置の場合は差分スクリプト) に加えて、配置前および配置後ファイルをすべてまとめて表すファイルです。
配置時に必要な権限は、配置しようとしているオブジェクトのタイプによって大幅に異なります。たとえば、SQL Server ログインを追加するチーム メンバは、ターゲット サーバーに対する securityadmin 権限を持っていなければなりません。スキーマ オブジェクトを配置するには、そのスキーマ オブジェクトの所有権または db_ddladmin 権限を持っているか、あるいは db_owner 権限を持っている必要さえあります。前出の「環境別の権限の設定」の項で注記したとおり、実働環境においてデータベースまたはデータベースの変更内容を配置するには、きわめて特殊な権限が必要な場合があります。
スキーマの比較
SQL Server 2000 と SQL Server 2005 のスキーマを比較するには、スキーマのインポートに必要なものと同じ権限が必要です。ただし、アップデート内容をターゲットに書き込みたい場合は、選択したデータベースを更新する権限も持っていなければなりません。
データの比較
2 つのテーブルまたはビューのデータを比較するには、データの比較のためのスクリプトの生成用として選択するオブジェクトに対する SELECT 権限が必要です。指定するデータ比較オプションによっては、オブジェクトに対するさらに別の権限 (たとえば INSERT、UPDATE、および場合によっては ALTER) も必要になります。
データの生成
データを生成するには、ターゲット データベースへのデータの追加のための INSERT 権限が必要です。また、ターゲットのテーブルでのデータの消去を指定する場合は、DELETE 権限も必要です。それ以外に、データ生成計画を正常に完了するために、挿入および削除のトリガを無効にする必要もあるかもしれません。これらのトリガが、データ生成計画の実行の妨げとなる場合は、SQL Server Management Studio などのツールを使用して、ターゲット システム上で手動で無効にする必要があります。また、すべてのテーブルまたはビューにデータを取り込むために、ターゲット サーバーに対する VIEW DEFINITION 権限も必要です。なぜなら指定したターゲットで、データ生成計画がこれまでどおり有効かどうかを検証するためのスキーマ比較が実行されるからです。
テーブル上の ID 列をリセットするには、テーブルのオブジェクト所有者であるか、または db_owner または db_ddladmin ロールのメンバでなければなりません。
単体テストの実行
単体テストを実行する場合は、ターゲット サーバーへの 1 つの接続を確立して単体テストを実行し、さらに別の接続を確立してテスト結果を検証する必要があります。検証接続には、さらに別の権限が必要になることがあります。それは、テスト結果を検証するためにアクセスするスキーマ オブジェクトなどの数が増えるからです。Windows 認証ではなく SQL Server 認証を使用する限り、別個のセキュリティ コンテキストの元でこのような接続を実行することができます。Windows 認証を使用する場合、ログオンしているユーザーとして両方の接続が実行されます。
SQL Server 認証を使用する場合、パスワードが必要になると考えられます。Team Edition for Database Professionals では、暗号化されたパスワードがレジストリ内に保管され、Windows ユーザー アカウントが鍵として使用されます。したがって、他のユーザーが同じコンピュータにログインしても、このパスワードにはアクセスできません。そのような他のユーザーは、データベース接続で SQL Server 認証を使用している場合は、パスワードを再入力する必要があります。
単体テストの特性によって、ターゲット システム上でのテストの実行のためにはどの権限が必要かが決まります。たとえば、単体テストでテーブル中の行が選択される場合、そのテーブルに対する SELECT 権限を持っていなければなりません。さらに、自動ビルドおよび配置の機能がテストで使用される場合は、スキーマ オブジェクトの更新および置換のために、ターゲット サーバーに対する管理権限を持っている必要があります (上述のとおり)。
まとめ
Microsoft Visual Studio 2005 Team Edition for Database Professionals でのセキュリティは多様な形態をとります。この製品は、データベース プロジェクト内のセキュリティ オブジェクトに加えて、データベースへのさまざまな接続をサポートします。
Visual Studio のセキュリティのその他の詳細は、MSDN のSecurity Developer Center を参照してください。SQL Server のセキュリティのその他の詳細は、SQL Server のセキュリティ ページを参照してください。Visual Studio Team Edition for Database Professionals の一般情報は、製品情報のページを参照してください。