Microsoft Visual Studio 2005 Team Edition for Database Professionals のセキュリティの概要

[アーティクル]
11/21/2008

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 ]

配置前および配置後のスクリプト

ログインの追加

Logins.sql ファイルは、配置前スクリプトファイルとして追加されます。このファイルには、データベースに追加されるユーザーをサポートする SQL Server ログイン用の CREATE LOGIN (ただし、SQL Server 2000 との下位互換性を保つ場合は sp_addlogin) の呼び出しが入ります。データベーススキーマをインポートする場合、ソースサーバーの SQL Server ログインはプロジェクトにはインポートされません。プロジェクトでデータベースユーザーをサポートするのに明示的に必要とされた SQL Server ログインだけが、このスクリプトファイルに自動的に追加されます。それ以外の SQL Server ログインを配置時にサーバーに追加する必要がある場合、このスクリプトファイルに追加する必要があります。

リンクサーバーの追加

権限のインポートおよび作成

スキーマまたはスクリプトをインポートすると、権限は 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 の一般情報は、製品情報のページを参照してください。

次の方法で共有

Microsoft Visual Studio 2005 Team Edition for Database Professionals のセキュリティの概要

目次

インストールおよび構成の権限

Team Edition for Database Professionals のインストールおよび実行

SQL Server 2005 のインストール

SQL Server のその他のコンポーネントのインストールおよび有効化

SQL Server 用の Windows セキュリティグループの作成

スキーマの開発および配置の権限

組織環境の理解

環境別の権限の設定

データベースプロジェクトにおけるセキュリティオブジェクト

SQL Server 2000 のデータベースプロジェクト

SQL Server 2005 のデータベースプロジェクト

外部アクセスを伴った機能でのセキュリティの考慮事項

ディスク上のプロジェクトファイルの保護

スキーマのインポート

ビルドおよび配置

スキーマの比較

データの比較

データの生成

単体テストの実行

まとめ

その他のリソース

次の方法で共有

Microsoft Visual Studio 2005 Team Edition for Database Professionals のセキュリティの概要

目次

インストールおよび構成の権限

Team Edition for Database Professionals のインストールおよび実行

SQL Server 2005 のインストール

SQL Server のその他のコンポーネントのインストールおよび有効化

SQL Server 用の Windows セキュリティ グループの作成

スキーマの開発および配置の権限

組織環境の理解

環境別の権限の設定

データベース プロジェクトにおけるセキュリティ オブジェクト

SQL Server 2000 のデータベース プロジェクト

SQL Server 2005 のデータベース プロジェクト

外部アクセスを伴った機能でのセキュリティの考慮事項

ディスク上のプロジェクト ファイルの保護

スキーマのインポート

ビルドおよび配置

スキーマの比較

データの比較

データの生成

単体テストの実行

まとめ

その他のリソース

SQL Server 用の Windows セキュリティグループの作成

データベースプロジェクトにおけるセキュリティオブジェクト

SQL Server 2000 のデータベースプロジェクト

SQL Server 2005 のデータベースプロジェクト

ディスク上のプロジェクトファイルの保護