SQL Server 2005 リレーショナル エンジン セキュリティ機能の紹介

  • [アーティクル]

2003 年 10 月

要約 : セキュリティは、Microsoft SQL Server のすべての管理者や開発者の作業に影響を及ぼすデリケートなテーマです。 Microsoft SQL Server 2005 の主な目的の 1 つは、例外事項がさほど多くなく明確に説明することのできるシンプルな規則モデルを用いて、サーバーのセキュリティ フレームワークを定義し直すことにあります。 このホワイトペーパーでは、この新たなセキュリティ モデルを実装する SQL Server 2005 への変更点について論じます。

トピック

はじめに
パスワード ポリシー
ユーザーとスキーマの分離
メタデータのビジビリティ制限
概要
権限
SQL-CLR セキュリティ
プログラム可能なモジュールの実行コンテキスト
まとめ

はじめに

Microsoft SQL Server 2005 の主な目的の 1 つは、例外事項がさほど多くなく説明することのできる、強化されたセキュリティ アーキテクチャを創出することにあります。

簡潔に言うとリレーショナルエンジンセキュリティアーキテクチャ

SQL Server は、権限で保護することのできる階層化されたエンティティの集合を管理します。 最も目につく保護対象はサーバーとデータベースですが、権限はより詳細なレベルで個別に設定することが可能です。 SQL Server は、適切な権限が与えられているかどうかを確認することで、保護対象に対するプリンシパルの動作を統制します。

sqlsys01

SQL Server のリソースを要求することのできる個人、グループ、そしてプロセスは、「プリンシパル」と呼ばれています。プリンシパルの影響力の範囲は、その定義の範囲 (Windows、サーバー、データベース) と、それがプライマリ プリンシパルなのか、あるいはセカンダリ プリンシパルなのかによって異なります。 Windows ログインはプライマリ プリンシパルの例であり、Windows グループはセカンダリ プリンシパルの例です。

Windows レベルのプリンシパル

  • Windows ドメイン ログイン

  • Windows ローカル ログイン

  • Windows グループ

SQL Server レベルのプリンシパル

  • SQL Server ログイン (Windows レベルのプリンシパルへのマッピングが可能)

  • サーバー ロール

データベースレベルのプリンシパル

  • データベース ユーザー (サーバー レベルのプリンシパルへのマッピングが可能)

  • データベース ロール、固定データベース ロールまたはユーザー定義ロールのいずれか

  • アプリケーション ロール

保護対象は、SQL Server 認証システムによってアクセスが規制されるリソースです。 保護対象の中には、他の保護対象内に含めることのできるものがあり、それ自体を保護することのできる「スコープ」と呼ばれるネスト化された階層を形成します。 保護対象スコープは、サーバー、データベース、およびスキーマです。

保護対象スコープ : サーバー

次の保護対象が含まれます。

  • ログイン

  • HTTP エンドポイント

  • 証明書

  • イベント通知 (DDL イベント、動作イベント、エラー イベント、言語イベント、リソース イベント、セキュリティ イベント、バックアップ イベント)

  • データベース

保護対象スコープ : データベース

次の保護対象が含まれます。

  • ユーザー

  • ロール

  • アプリケーション ロール

  • アセンブリ

  • メッセージ タイプ

  • サービス コントラクト

  • サービス

  • フルテキスト カタログ

  • DDL イベント

  • XML スキーマ (プレビュー内のみ)

  • スキーマ

保護対象スコープ : スキーマ

次の保護対象が含まれます。

  • テーブル

  • ビュー

  • 関数

  • プロシージャ

  • キュー

  • タイプ

  • ルール

  • 既定

  • シノニム

  • 集計

サーバー レベルでの権限の付与は新しい機能です。 SQL Server 2005 以前は、固定サーバー ロールを使用してサーバー レベルの権限が管理されていました。

SQL Server のあらゆる保護対象には、プリンシパルに与えることが可能な、関連する権限があります。 権限の詳細については、Books Online を参照してください。

使用される用語

SQL Server 2005 のセキュリティ モデルの機能について説明するため、新しい用語が取り入れられるとともに、従来の用語の一部もやや異なった方法で使用されます。 以下のリストには、ここで使用されているセキュリティ関連用語の定義が示されています。

  • 保護対象

    権限の設定が可能なエンティティ。 SQL Server の保護対象リストは、権限のセクションに記載します。

  • スコープ

    他の保護対象を含む保護対象。 具体的にはサーバー、データベース、スキーマ。

  • プリンシパル

    保護対象オブジェクトにアクセスできるエンティティ。 プライマリ プリンシパルは単一のユーザー (SQL Server や Windows のログインなど)、セカンダリ プリンシパルは複数のユーザー (ロールや Windows グループなど) をそれぞれ表します。

  • ( 権限の ) 設定者

    権限を与えるプリンシパル。 保護対象の所有プリンシパルまたは CONTROL 権限を持つプリンシパルには、通常、その保護対象の権限を与えることができます。 しかしカタログでは、たとえ権限が CONTROL 権限によってその他の誰かによって与えられた場合でも、所有者が常に設定者として示されます。

  • ( 権限の ) 被設定者

    被設定者は、権限を設定されるプリンシパルです。

パスワード ポリシー

パスワードは認証プロセスの重要な部分であり、大抵の場合、セキュリティ リンクで最大の弱点であることがよく知られています。 単純なパスワードや空白のパスワードを使用できるようにすることは、悪意を持ったユーザーやアタッカーに仕事をさせやすくすることに他なりません。

ログイン機能の施行

SQL Server 2005 では、データベース管理者は、SQL のログインに堅固なパスワードの複雑さと有効期限のポリシーを適用することが可能です。 SQL Server 2005 は、Windows の API を使用してパスワード ポリシーを施行し、SQL と Windows のポリシーの一貫性を保証します。 これにより、管理者は、パスワードのポリシーに 1 つの標準を定めることができます。 標準的な SQL ログインのパスワード ポリシーは、Windows 2003 以降が起動している SQL Server 2005 で適用することができます。

新たなログインが追加された際は、ローカル ポリシーのパスワード強化がそのログインに適用されるかどうかを示すフラグを用意することができます。 ログインの CHECK_EXPIRATION および CHECK_POLICY プロパティは、sysadmin および securityadmin、そして ALTER ANY LOGIN 権限を持つログインによって設定および照会可能です。

Windows 2003 では、パスワード有効期限の確認が行われたかどうかは CHECK_EXPIRATION のフラグ値によって判定されます。 既定値は「ON」です。 このログインのフラグを OFF の値に設定すると、パスワードに有効期限のないプロパティを持つアカウントを Windows で作成したのと同様になります。 Windows 2000 Server には新しいセキュリティ API がなく、従ってこのフラグは意味がないことから、このオペレーティング システムでは CHECK_EXPIRATION フラグは無視されます。

Windows 2003 Server では、ローカルの Windows ポリシーを使用してパスワードの強度が確認されたかどうかは CHECK_POLICY フラグの値で判定されます。 既定値は「ON」です。 Windows 2000 では SQL Server に固有のポリシーがあり、ローカルの Windows ポリシーでは判定されません。 Windows 2000 の SQL ポリシーは MBSA (Microsoft Baseline Security Analyzer) のポリシーと同一であり、以下のパスワードに対して警告を発します。

  • 空白または NULL

  • ユーザー名

  • マシン名

  • 「Password」という固定文字列

  • 「Admin」という固定文字列

  • 「Administrator」という固定文字列

CHECK_POLICY フラグの値を OFF に設定することは、パスワードにあらゆる文字列を使用したり、パスワードを NULL にしたりすることが可能となってしまうことを意味します。 この設定は使用しないようにすることを強く推奨します!

新規 DDL

パスワード ポリシーをサポートするため、CREATE LOGION と ALTER LOGIN という 2 つの新しい DDL ステートメントを利用することができます。 これらの DDL ステートメントは、ログインの作成と管理のために前のバージョンの SQL Server で使用されていた、システムに保存されたプロシージャに取って代わるものです。

CREATE LOGIN の構文は次のとおりです。

CREATE LOGIN login_name 
     { WITH option_list1 | FROM WINDOWS [ WITH option_list2 [,...] ] } option_list1 ::= 
     PASSWORD password [ HASHED ] [ MUST CHANGE ] [ , option_list3 [,...] 
] option_list2 ::= 
     DEFAULT_DATABASE = database | DEFAULT_LANGUAGE = language option_list3 ::= 
     | SID = sid 
     | DEFAULT_DATABASE = database 
     | DEFAULT_LANGUAGE = language 
     | CHECK_EXPIRATION = { ON | OFF } 
     | CHECK_POLICY = { ON | OFF }

引数

login_name

作成される SQL Server または Windows のログイン名を指定します。

PASSWORD password

作成されるログインのパスワードを指定します。

HASHED

SQL Server ログインにのみ適用されます。 パスワードがハッシュ済みであることを指定します。

MUST_CHANGE

SQL Server ログインにのみ適用されます。 このオプションが含まれている場合、SQL Server は新しいログインが最初に使用される際にパスワードの更新を促します。

SID = sid

SQL Server ログインにのみ適用されます。 新しい SQL ログインの GUID を指定します。 このオプションが含まれていない場合、SQL Server は自動的に GUID を指定します。

DEFAULT_DATABASE = database

ログインに指定される既定のデータベースを指定します。 このオプションが含まれていない場合、既定のデータベースは MASTER に設定されます。

DEFAULT_LANGUAGE = language

ログインに指定される既定の言語を指定します。 このオプションが含まれていない場合、既定言語はサーバーの現在の既定言語に設定されます。 サーバーの既定の言語が先々変更されても、ログインの既定の言語はそのまま変更されません。

CHECK_EXPIRATION

SQL Server ログインにのみ適用されます。 パスワード有効期限のポリシーをログインで使用するように指定します。 既定値は ON です。 パスワード ポリシー API が存在する場合は、これによって、ローカルの Windows パスワード 有効期限ポリシーが使用されます。

CHECK_POLICY

SQL Server ログインにのみ適用されます。 SQL Server が起動しているコンピュータの Windows パスワード ポリシーをログインで使用するように指定します。 これは、Windows 2000 では、パスワードを複雑にするための SQL ポリシーを適用します。 既定値は ON です。

備考

事前のパスワード ハッシングは、SQL Server のログイン作成時のみサポートされます。

CHECK_POLICY および CHECK_EXPIRATION には次のルールが適用されます。

  • CHECK_POLICY が OFF ならば、CHECKEXPIRATION は ON にできません。 CHECKEXPIRATION が ON の場合、CHECK_POLICY が OFF に設定されると CREATE LOGIN でエラーが生じます。

  • MUST_CHANGE が指定されている場合、CHECK_EXPIRATION は ON でなければならず、従って CHECK_POLICY も ON でなければなりません。 これらの条件が満たされない場合、CREATE LOGIN でエラーが生じます。

権限

sysadmin および securityadmin ロールのメンバは、既定でログインを作成することができます。 これに加え、ALTER ANY LOGIN の権限を伴うログインもログインを作成することが可能です。

CREATE LOGIN の構文は次のとおりです。

ALTER LOGIN login_name WITH set_option [,...] Set_option::=  
PASSWORD = password [OLD PASSWORD = oldpassword 
| secadmin_pwd_option [secadmin_pwd_option] ] 
      | DEFAULT_DATABASE = dbname 
      | DEFAULT_LANGUAGE = language 
      | NAME =  login_name 
      | CHECK_POLICY = {ON|OFF} 
      | CHECK_EXPIRATION = {ON|OFF} Secadmin_pwd_opt := MUST_CHANGE | UNLOCK

引数

login_name

変更される SQL Server または Windows ログインの名前を指定します。

PASSWORD password

変更されるログインのパスワードを指定します。

MUST_CHANGE

SQL Server ログインにのみ適用されます。 このオプションが含まれている場合、SQL Server は新しいログインが最初に使用される際にパスワードの更新を促します。

DEFAULT_DATABASE = database

ログインに指定される既定のデータベースを指定します。 このオプションが含まれていない場合、既定のデータベースは MASTER に設定されます。

DEFAULT_LANGUAGE = language

ログインに指定される既定の言語を指定します。 このオプションが含まれていない場合、既定言語はサーバーの現在の既定言語に設定されます。 サーバーの既定の言語が先々変更されても、ログインの既定の言語はそのまま変更されません。

NAME

このログインのための新しいログイン名。 ログイン名が変更されても、その SID は変更されません。

CHECK_EXPIRATION

SQL Server ログインにのみ適用されます。 パスワード有効期限のポリシーをログインで使用するように指定します。 既定値は ON です。

CHECK_POLICY

SQL Server ログインにのみ適用されます。 SQL Server が起動しているコンピュータの Windows パスワード ポリシーをログインで使用するように指定します。 既定値は ON です。

UNLOCK

ロックされたログインのロックを解除するように指定します。

次のルールが適用されます。

  • CHECK_POLICY が OFF ならば、CHECK_EXPIRATION は ON にできません。 この条件が満たされない場合、ALTER LOGIN でエラーが生じます。

  • MUST_CHANGE が指定されている場合、CHECK_EXPIRATION は ON でなければならず、従って CHECK_POLICY も ON でなければなりません。 ログインをこの状態にする ALTER LOGIN では、いずれもエラーが発生します。

  • CHECK_POLICY が OFF に切り替えられると、そのパスワードの履歴はすべて削除されます。 これには、後に admin が長い期間をおいてポリシー フラグを再び ON に切り替えた場合、CHECK_POLICY が ON であった時の履歴が使用されないという利点があります。 また、CHECK_POLICY が OFF に切り替えると、CHECK_EXPIRATION も OFF に切り替えられます。

DEFAULT_DATABASE、DEFAULT_LANGUAGE、そして NAME を除き、その他のオプションは標準の SQL ログインにのみ適用することができます。

sysadmin および securityadmin 固定サーバー ロールのメンバは、他のすべてのログインに上記のすべてのオプションを設定したり、リセットしたりすることができます。 その唯一の例外は、securityadmin のメンバが sysadmin ロールのメンバであるログインに以下を行えないことです。

  • パスワードのリセット

  • MUST_CHANGE 、 CHECK_POLICY、または CHECK_EXPIRATION オプションの指定

  • NAME の変更

他のログインでは、各々のログインの以下の項目以外、変更できません。

  • DEFAULT_DATABASE

  • DEFAULT_LANGUAGE

  • PASSWORD (すでにパスワードが指定されている場合のみ)

アカウントのロックアウト

アカウントのロックアウトを解除するには、次のコマンドを使用することができます。

ALTER LOGIN <Login Name> WITH PASSWORD = '<newpwd>' UNLOCK

SQL Server 2005 では、ログインのロックアウト解除のみ可能です。 管理者は、アカウントをロックアウトするためにこのコマンドを使用することはできません。

UNLOCK オプションは、Windows 2000 を実行中の SQL Server には適用されません。

例

安全でないパスワードの 1 つが使用されることから、強度条件を満たさないパスワードでログインを作成します。 CHECK_POLICY は既定で ON なので、このステートメントはエラーとなります。

CREATE LOGIN Daniel WITH PASSWORD = 'password'

しかし、明示的に CHECK_POLICY の値を OFF に設定した場合、このログインは安全でないパスワードで作成することができます。 この設定は使用しないようにすることを強く推奨します!

CREATE LOGIN Daniel WITH PASSWORD = 'password', CHECK_POLICY = OFF

アカウントプロパティの照会

パスワード ポリシーに関してアカウントの状態を判定しやすくするため、新たに組み込まれた LoginProperty という機能を使用することができます。 これは、ログイン名と照会されるプロパティをパラメータとして取り入れ、アカウントのそのプロパティが含まれているかどうかを整数で示します。

構文

LoginProperty ( 'login-name', 'property')

引数

login-name

状態を判定しようとしている標準の SQL ログイン名。 Windows ログインとすることはできません。

property

照会されるログインのプロパティでは、以下のいずれかが可能です。

  • IsLocked - ログインが現在ロックされているかどうかを確認します。

  • IsExpired - ログインの有効期限が切れているかどうかを確認します。

  • IsMustChange - 次回のログインでパスワードの変更が必要かどうかを確認します。

次の例では、特別なフラグが一切提供されていない新たなログインが作成された後、LoginProperty 機能で各フラグの既定値が確定されます。

CREATE LOGIN Susan WITH PASSWORD = '438kljLHLBUuii4' 
SELECT LoginProperty('Susan', 'IsLocked') 
SELECT LoginProperty('Susan', 'IsExpired') 
SELECT LoginProperty('Susan', 'IsMustChange')

ユーザーとスキーマの分離

ANSI SQL-92 標準では、スキーマは 1 つのプリンシパルが所有し、1 つのネームスペースを形成するデータベース オブジェクトの集合と定義されています。 ネームスペースとは、重複した名前を持つことのできない一式のオブジェクトです。 たとえば、2 つのテーブルは、スキーマが別の場合にのみ同じ名前とすることが可能で、スキーマが同じならばそれらのテーブルを同じ名前にすることはできません。 スキーマはオブジェクトのコンテナと考えることができます。 (データベース ツールを扱う際は、スキーマは、スキーマまたはデータベース内のオブジェクトについて記述したカタログ情報にもあてはまります。 Analysis Services では、スキーマとは立方体や次元などの多次元オブジェクトについて記述するものです。

SQL Server 2000 では、ユーザーとスキーマとのあいだに暗黙の関係があります。 事実、その関係が非常に密接なため、多くのユーザーはユーザーとスキーマが 2 つの異なるものであることを認識していません。 SQL Server 2000 では、すべてのユーザーがそのユーザーと同じ名前を持ったスキーマの所有者です。

SQL Server 2000 には CREATE SCHEMA ステートメントがあるにはありましたが、実際にスキーマが作成されるわけではありませんでした。 CREATE SCHEMA は、オブジェクトを作成し、管理者が依存関係を見落とさないようにするのにも役立つ権限を 1 つのステートメントで与える方法を提供していました。

SQL Server では、オブジェクトの完全修飾名には server.database.schema.object という 4 つの部分があります。 SQL Server 2000 では、「スキーマ」は実際のところオブジェクトの所有者と同じです。 ですから、「スキーマ」の完全修飾名はデータベースの user となります。

データベースからユーザーを削除するにあたって、管理者は、まずそのユーザーが所有するすべてのオブジェクトを削除するか、またはその所有者を変更しなければなりません。 次のオブジェクトが含まれる SQL Server 2000 のデータベースを考えてみましょう。

accounting.ap.george.reconciliation

このオブジェクトは「george」というユーザーが所有しています。この「george」というユーザーを削除する必要がある場合、管理者はまずこのオブジェクトを削除するか、あるいはその所有者を変更しなければなりません。 所有者を変更する場合、このオブジェクトは次のようにすることができます。

accounting.ap.sandra.reconciliation

オブジェクトの所有権を移すと、その完全修飾名が変更されます。 「accounting.ap.george.reconciliation」を参照するコードは、すべて変更やテスト等を行わなければなりません。

SQL Server 2005 では、オブジェクトはユーザーから完全に切り離されたスキーマに収められます。 スキーマの所有権は、その名前を変更することなく移転することができます。 プログラムは、たとえば「accounting.ap.processes.reconciliation」のように、データベースにユーザーが追加されたり、データベースからユーザーが削除されたりしても変更の必要がない名前のオブジェクトを参照することが可能です。

既定スキーマ

SQL Server 2005 では、「既定スキーマ」という表記も取り入れられています。 これは、完全修飾名のない参照オブジェクトの名前を解決するのに使用されます。 SQL Server 2000 では、最初にチェックされる場所は、呼び出す側のユーザーが所有するスキーマとなります。 名前解決のアルゴリズムは、次に DBO が所有するスキーマをチェックします。 SQL Server 2005 では、DEFAULT_SCHEMA は CREATE USER および ALTER USER の引数で、オブジェクトの名前を解決する際にサーバーが検索する最初のスキーマを指定します。 DEFAULT_SCHEMA が未定義の場合、ユーザーは既定のスキーマとして DBO を使用することになります。 DEFAULT_SCHEMA は、現在データベースに存在しないスキーマに設定することができます。 DEFAULT_SCHEMA は、参照するスキーマを作成する前に設定可能です。

新規 DDL

CREATE SCHEMA

データベースにスキーマを作成します。 スキーマはユーザーまたはロールが所有し、これにはテーブル、ビュー、プロシージャなど、1 つ以上のデータベース オブジェクトが含まれます。

構文

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 }

引数

schema_name

データベース内で識別されるスキーマの名前。

AUTHORIZATION owner_name

スキーマを所有するユーザー、ロール、またはアプリケーション ロールの名前を指定します。

table_definition

スキーマ内にテーブルを作成する CREATE TABLE ステートメントを指定します。 ユーザーまたはロールには CREATE TABLE の権限が与えられなければなりません。

view_definition

スキーマ内にビューを作成する CREATE VIEW ステートメントを指定します。 ユーザーまたはロールには CREATE VIEW の権限が与えられなければなりません。

grant_statement

ユーザーまたはユーザー グループに権限を与える GRANT ステートメントを指定します。

備考

CREATE SCHEMA は、1 つのステートメントでテーブルおよびビューを作成し、保護対象に権限を与えることができます。 保護対象を作成する際、または CREATE SCHEMA ステートメントで指定された権限を付与する際にエラーが生じた場合、オブジェクトは一切作成されません。

CREATE SCHEMA で作成される保護対象は、他のビューを参照するビューを除き、どのような順番でもリストすることが可能です。 他のビューを参照するビューの場合は、参照する側のビューを作成する前に、参照される側のビューが作成されなければなりません。 たとえば、GRANT ステートメントはオブジェクト自体が作成される前にそのオブジェクトに権限を与えることができ、CREATE VIEW ステートメントはビューで参照されるテーブルを作成する CREATE TABLE ステートメントの前に示すことができます。 また、CREATE TABLE ステートメントは、後に指定されるテーブルへの外部キーを宣言することが可能です。 例外として、1 つのビューからの選択で別のビューが参照される場合、参照されるビューは参照するビューよりも先に指定されなければなりません。

作成されているスキーマの所有者として別のユーザーを指定することも可能ですが、これには以下に述べられる権限の追加条件があります。

以下のフォームの CREATE SCHEMA ステートメントは、厳密に下位互換性のみを目的としたものです。 schema_name は提供されないことに注意してください。

CREATE SCHEMA AUTHORIZATION owner_name

このように指定すると、このステートメントは実際にデータベースの内側にスキーマを作成しません。 このフォームでは、CREATE SCHEMA は 1 つのステートメントの一部として主にテーブルやビューを作成し、それらに権限を与えるための手段として使用されます。

この場合、認証されたすべてのユーザーは、このフォームでステートメントを発行することができます。 スキーマは一切作成されていないので、CREATE SCHEMA に対する権限はチェックされません。

権限

CREATE SCHEMA に必要な権限の説明は、Books Online を参照してください。

ALTER SCHEMA

スキーマの所有者を変更します。

構文

ALTER SCHEMA schema_name 
     AUTHORIZATION owner_name

引数

schema_name

データベース内で識別されるスキーマの名前。

AUTHORIZATION owner_name

スキーマを所有するユーザー、ロール、またはアプリケーション ロールの名前を指定します。

備考

スキーマの所有権を変更すると、所有権のチェイニングが分断される場合があります。 スキーマの所有権変更により、そのスキーマおよびそれに含まれるオブジェクトからすべての権限が削除されます。

権限

ALTER SCHEMA に必要な権限の説明は、Books Online を参照してください。

DROP SCHEMA

データベースからスキーマを削除します。

構文

DROP SCHEMA schema_name

引数

schema_name

データベース内で識別されるスキーマの名前。

備考

削除されるスキーマにはオブジェクトが含まれていてはなりません。 スキーマにオブジェクトが含まれていると、DROP ステートメントはエラーとなります。

権限

DROP SCHEMA に必要な権限の説明は、Books Online を参照してください。

ユーザーの追加、変更、および削除のための新規 DLL

SQL Server 2005 では、CREATE USER ステートメントでデータベース アクセスが与えられます。 ログインと同様に、データベースの既存のユーザーは ALTER USER ステートメントで変更され、DROP USER ステートメントでデータベースから削除されます。

CREATE USER <user_name> 
 [FOR LOGIN <Login_name>] 
 [WITH DEFAULT_SCHEMA  schema_name] 
ALTER USER <user_name> 
WITH <set item> [,...n] 
<set item> ::= 
NAME = <user_name> 
| LOGIN = <login_name> 
| DEFAULT_SCHEMA   <schema_name>

ログイン名が指定されていない場合、ユーザーは <user_name> と同じ名前のログインに関連付けられます。 そのようなログインが存在しない場合、CREATE USER はエラーとなります。 <login_name> としては、Windows ログイン、Windows グループ ログイン、または SQL Server ログインが可能です。

DROP USER <User_name>

スキーマまたはロールを所有している場合、そのユーザーは削除できません。 それらのユーザーを削除するには、まず所有されるスキーマまたはロールの所有権を変更するか、あるいはユーザーを削除する前にそのスキーマを削除しなければなりません。 また、DROP USER は、ユーザーが権限のチェーンで権限の GRANTOR である場合にもエラーとなります。

下位互換性

SQL Server 2000 では、ユーザー名とスキーマの概念は区別されていませんでした。 実際、「スキーマ」という表し方はありませんでした。 そのため、ユーザーが作成したオブジェクトには、スキーマであるかのようにユーザー名が付されました。 SQL Server 2000 の動作には、ユーザー名と同じ名前で自動的にスキーマを作成する効果があったのです。 結果として、下位互換性を維持するため、sp_adduser プロシージャは新しい DDL を利用するように書き換えられています。

Sp_adduser

sp_adduser [ @loginame = ] 'login_name' 
    [ , [ @name_in_db = ] 'user_name' ] 
 [ , [ @grpname = ] 'group' ]

SQL Server 2005 では、sp_adduser はユーザーと同じ名前と ID でユーザーおよびスキーマを作成します。 このスキーマはそのユーザーの既定のスキーマとして設定され、ユーザーはこのスキーマの所有者と見なされます。

たとえば、SQL Server 2005 で次のプロシージャが実行されるとしましょう。

sp_adduser Susan, sue, db_datareader 
これは内部で新しい DDL に変換されます。 
CREATE USER sue FOR LOGIN Susan 
    WITH DEFAULT_SCHEMA = sue 
GO 
CREATE SCHEMA sue AUTHORIZATION sue 
GO 
sp_addrolemember db_datareader, sue 
さらに、sp_dropuser は内部で次のように書き換えられます: 
DROP SCHEMA sue 
DROP USER sue

スキーマは、名前と ID がユーザーと同じ場合にのみ削除されます。

sp_adduser の代わりに CREATE USER を実行し、既定のスキーマを指定しない場合、既定のスキーマはユーザーと同じ名前のスキーマではなく dbo となり、新しいスキーマは作成されないことを忘れないでください。

ユーザーの利点 - スキーマの分離

スキーマからユーザーを分離すると、管理者や開発者にとって次のようなメリットがあります。

  • スキーマの所有者として複数のユーザーを設定できます (ロールまたは Windows グループのメンバシップを使用)。 これは、以前の SQL Server のリリースに追加された、ロールおよびグループがオブジェクトを所有できるようにする拡張機能に類似したものです。

  • 特にユーザーの削除に関わるシナリオで、ユーザーの管理が非常に容易になります。

  • ユーザーの削除にアプリケーションの書き換えやテストが必要ありません。

  • 抽象化層が用意されており、ユーザーとは名前の異なる既定のスキーマにユーザーを関連付けることが可能です。

  • 共通名の解決のため、複数のユーザーの関係を同じ既定スキーマで関連付けることができます。

  • 再定義可能な「既定スキーマ」の追加により、DBO スキーマに共有オブジェクトを保存することを望まない開発者には別の方法が与えられます。 これは、SQL Server 2000 よりも一層きめ細かな権限の管理を促進し、従って大幅なセキュリティの強化となります。

関連カタログのビュー

特定のデータベースにあるスキーマのリストを表示するには、以下を実行します。

SELECT * FROM SYS.SCHEMAS

データベースのプリンシパルを表示するには、以下を実行します。

SELECT * FROM SYS.DATABASE_PRINCIPALS

メタデータのビジビリティ制限

SQL Server 2005 では、システム カタログはメタデータのビジビリティを制限し、関係者のみに知らせるという原則でメタデータを開示します。 カタログへのすべてのアクセスに対して行レベルのフィルタリングが自動的に適用され、ユーザーがアクセス権を持つオブジェクトのメタデータのみが返されます。 たとえば、

SELECT * FROM sys.objects

では、現在のユーザーに何らかの権限が与えられているオブジェクトのメタデータのみが返されます。 このクエリでは、空の集合が返される可能性があります。 sa ログイン アカウントおよび sysadmin 固定サーバー ロールのメンバにはすべてのメタデータが示されます。 dbo ユーザー アカウントおよび db_owner 固定サーバー ロールのメンバには、データベース レベルのすべてのメタデータが示されます。

概要

この SQL Server 2005 のプレビューでは、システム内のほとんどのビュー (すべてのビューではありません) にメタデータのビジビリティ制限が適用されています。 メタデータへのアクセス制限は、メタデータを出力する OBJECTPROPERTY などの機能には適用されていません。

このプレビューのリリースでは、以下のシステム ビューでメタデータのビジビリティが制約され、限定されています。

Sys.all_columns

sys.numbered_procedure_parameters

Sys.all_objects

sys.numbered_procedures

Sys.all_parameters

sys.objects

Sys.all_views

sys.parameters

Sys.allocation_units

sys.partition_functions

Sys.assemblies

sys.partition_parameters

Sys.assembly_files

sys.partition_range_values

Sys.assembly_modules

sys.partition_schemes

Sys.assembly_references

sys.partitions

Sys.assembly_types

sys.procedures

Sys.backup_devices

sys.remote_logins

Sys.check_constraints

sys.remote_service_bindings

sys.column_defaults

sys.routes

sys.column_rules

sys.schemas

sys.columns

sys.server_permissions

sys.computed_columns

sys.server_principals

sys.configurations

sys.server_role_members

sys.conversation_endpoints

sys.servers

sys.data_spaces

sys.service_contract_message_usages

sys.database_files

sys.service_contract_usages

sys.database_permissions

sys.service_contracts

sys.database_principals

sys.service_instances

sys.database_role_members

sys.service_message_types

sys.databases

sys.service_queues

sys.default_constraints

sys.services

sys.destination_data_spaces

sys.sql_dependencies

sys.event_notifications

sys.sql_logins

sys.events

sys.sql_modules

sys.filegroups

sys.stats

sys.foreign_key_columns

sys.stats_columns

sys.all_columns

sys.numbered_procedure_parameters

sys.foreign_keys

sys.synonyms

sys.fulltext_catalog

sys.system_columns

sys.fulltext_index_columns

sys.system_objects

sys.fulltext_indexes

sys.system_parameters

sys.identity_columns

sys.system_views

sys.index_columns

sys.tables

sys.indexes

sys.trigger_events

sys.key_constraints

sys.triggers

sys.linked_logins

sys.views

sys.master_files

sysconfigures

sys.messages

 

システムオブジェクトの実装

マイクロソフトが提供する「システム オブジェクト」は、物理的にどのユーザーも見ることのできない場所に配置されます。 これらのオブジェクトには、システムに保存されるプロシージャ、システム機能、カタログ ビューと呼ばれる新たなクラスのオブジェクト (SQL Server 2000 のシステム テーブルおよび一部のシステム ビューに代わるものです)、そして INFORMATION SCHEMA VIEWS が含まれます。 これらの「システム オブジェクト」は、あらゆるデータベースの「sys」スキーマに論理的に示されます。 すべてのデータベース (マスタを含む) には、自動的に「sys」スキーマが含まれます。

カタログビュー

カタログ ビューには、SQL Server 2005 の核となる持続型メタデータが含まれます。これらのカタログ ビューは、SQL Server 2000 のほとんどのシステム テーブル (すべてではありません) に取って代わるものです。 たとえば、これまで sysobjects および sysfiles テーブルに収められていた情報は、今ではカタログ ビューに収められます。 実際、今では SQL Server 2000 のシステム テーブルの多くはまったく存在せず、システム テーブルへのアクセスは、すべてカタログ ビューを通じて行うようにすることが推奨されます。 さらに、カタログ ビューは、次のような SQL Server 2005 の機能をサポートするのにも使用することができます。

  • サービス ブローカー

  • HTTP エンドポイント

  • XML スキーマ

  • CLR およびアセンブリ情報

カタログ ビューは sysprocesses のような仮想テーブルではないことに注意してください。 また、以下のような msdb テーブルの多くも含まれません。

  • レプリケーション テーブル (例、MSPublications)

  • バックアップ テーブル (例、restorehistory)

  • SQL Server エージェント テーブル (例、sysjobs)

  • ログ配布テーブル (例、log_shipping_plans)

上記のテーブルへは、SQL Server 2000 のときと同様、msdb からアクセスすることができます。

カタログ ビュー自体は以下のとおりです。

  • 物理的に隠された場所に収められます。

  • 論理的に すべての データベースの sys schema に収められています。

  • すべての データベースの sys.system_views ビューに備えられているメタデータの行で記述されます。

メタデータのビジビリティ

新規のカタログ ビューを含むシステム オブジェクトは、ユーザーにメタデータを公表します。 SQL Server 2005 の目的の 1 つは、ユーザーが権限を持ったオブジェクトのメタデータ以外見ることのないように、メタデータのビジビリティを規制することにあります。 以下の操作では、メタデータが選択的に開示されます。

  • SYS スキーマのカタログ ビューから SELECT する。

  • オブジェクトの拡張プロパティにアクセスする。

  • INFORMATION_SCHEMA ビューから SELECT する。

  • (これらのビューは ANSI に準拠するために用意されたものであり、SQL Server 2005 ではカタログ ビューを参照することで定義されます。)

  • 下位互換ビュー

    SQL Server 2005 では、SQL Server 2000 の「sys」テーブルに相当する一式のビューが保持されます。 これらのテーブルのマスタ データベースのみに備えられるものもあれば、すべてのデータベースに備えられているものもあります。 これらは、sysobjects、syscomments、sysindexes などのような SQL Server 2000 の各システム テーブルに相当する、いわゆる「下位互換ビュー」です。 これらの下位互換ビューへは、SQL Server 2000 と同じようにアクセスできるので、SQL Server 2005 でこのコードを実行する際は次のようになります。

    • 



SELECT * FROM sysobjects



SQL Server は、実際は sys.objects カタログ ビューから選択します。

<pre IsFakePre="true" xmlns="http://www.w3.org/1999/xhtml">



SELECT * FROM sys.objects



sys.object のような下位互換ビューは、実際には新しい SQL Server 2005 のカタログを参照することから、メタデータ開示制限の対象となることに注意してください。 また、下位互換ビューは新たな SQL Server 2005 のビューに基づいているものの、上記の 2 つのステートメントで同一の結果が返されるわけではなく、さらには結果一式の行が同数となるわけではありません。 SQL Server 2005 には、たとえば サービス ブローカー キュー、XML インデックス、分割インデックスなどのように、SQL Server 2000 の sysobjects フォーマット形式にマップすることのできない新しいオブジェクトがあります。 また、下位互換ビューではなく SQL Server 2005 の新しいカタログ ビューを使用することにより、動作上の利点も実現されます。 できる限り sys.object などの新しいカタログ ビューを使用することを推奨します。


図 1 は、下位互換ビューとそれらに対応する SQL Server 2005 のカタログ ビューの一覧です。 メタデータの開示制限は、図 1 のすべての下位互換ビューに適用されます。











SQL Server 2000


SQL Server 2005








Sysaltfiles


sys.master_files






Sysconfigures


sys.configurations






Sysdatabases


sys.databases






Sysdevices


sys.backup_devices






Syslogins


sys.server_principals






Sysmessages


sys.messages






Sysoledbusers


sys.linked_logins






Sysremotelogins


sys.remote_logins






Sysservers


sys.servers






Syscolumns


sys.columns






Syscomments


sys.sql_modules






Sysconstraints


sys.check_constraints

sys.default_constraints

sys.key_constraints

sys.foreign_keys






Sysdepends


sys.sql_dependencies






Sysfilegroups


sys.filegroups






sysfiles1


sys.database_files






Sysforeignkeys


sys.foreign_keys






Sysindexes


sys.indexes






sysindexkeys


sys.index_columns






sysmembers


sys.database_role_members






sysobjects


sys.objects






syspermissions


sys.database_permissions

sys.server_permissions






sysprotects


sys.database_permissions

sys.server_permissions






sysreferences


sys.foreign_keys






systypes


sys.types






sysusers


sys.database_principals






sysfulltextcatalogs


sys.fulltext_catalogs







図 1 SQL Server 2000 のシステムテーブルに対応する SQL Server 2005 のビュー


SQL Server 2005 では、sp_help や sp_helpdb のようにエンジンが所有する「ヘルプ」のプロシージャは、基本的なカタログ ビューを使用するように書き換えられており、従ってこれらもメタデータ開示制限の対象となります。


モジュール定義におけるメタデータのビジビリティ


SQL 言語定義でユーザーにオブジェクトの実行 (EXECUTE) または参照 (REFERENCES) 権限が与えられている (GRANT) 場合でも、それでそのユーザーにソース定義を見る権利が与えられるわけではありません。 SQL Server は、一般に見ることのできる残りのプロシージャの属性から SQL ソース コードを解釈します。


たとえば、保存されたプロシージャ P には sys.procedures に保存された、一般に見ることのできる属性があり、これは sys.object から派生したものです。 SQL ソース テキスト P は、sys.sql_module.definition の列内に保存されています。 プロシージャ P の実行 (EXECUTE) または参照 (REFERENCES) が与えられていれば (GRANT)、ユーザーは以下を実行した際、空でない結果一式を得ます。


select * from sys.procedures where name = 'P'



以下を実行すると、空の結果が返ります。


select * from sys.sql_modules where name = 'P'



同様の方法は、以下の SQL ソース定義を含むすべてのオブジェクトに使用されます。


    

  • プロシージャ
    

    • 

  • 関数
    

    • 

  • セキュリティ式
    

    • 

  • 計算される列
    

    • 

  • CHECK 制約
    

    • 

  • トリガ
    

    • 



VIEW DEFINITION 権限


VIEW DEFINITION 権限は、メタデータのビジビリティ規制を回避することで下位互換性を実現します。 また、この VIEW DEFINITION 権限によって、特権ユーザーには微調整やこれらの規制を無効にするための能力がある程度可能になります。


VIEW DEFINITION 権限を使用したカタログメタデータ制限の無効化


VIEW DEFINITION 権限によって、被設定者は権限設定可能オブジェクトのメタデータを見ることが可能となります。 この権限は、前のセクションで説明した機能を無効にします。 VIEW DEFINITION がユーザー U に与えられていれば (GRANT)、U はこのような場合以外見ることのできない権限設定可能オブジェクトのメタデータを見ることができます。 逆に、U に対して VIEW DEFINITION が拒否されていると (DENY)、U はさもなければ見ることのできる権限設定可能オブジェクトのメタデータを見ることができません。


VIEW DEFINITION 権限は、きめ細かなさまざまなレベルで適用することができます。 異なるきめ細かさのレベルで権限を与える (GRANT) ことのできる性能は、次のセクションで述べられる「All Permissions Grantable」(すべての権限を付与可能) の新しい機能です。 以下は VIEW DEFINITION 権限を与える (GRANT) ための構文です (拒否 (DENY) の構文も同様です)。


-- データベース レベルのスコープ 
GRANT VIEW DEFINITION TO <principal> [WITH GRANT OPTION]; 
-- スキーマ レベルのスコープ 
GRANT VIEW DEFINITION ON SCHEMA :: <schema> TO <principal> [WITH GRANT 
OPTION]; 
-- インスタンス レベルのスコープ 
GRANT VIEW DEFINITION ON <object> TO <principal> [WITH GRANT OPTION]; 
-- 補助的な構文上の変数 
<principal> ::= <user> | <role> | PUBLIC 
<object> ::= <table name> | <view name> | <function name> | <procedure 
name> | ...



データベース レベルで U に VIEW DEFINITION が与えられた場合 (GRANT)、データベースのメタデータはすべて U に示されます。 同様に、データベース レベルで U への VIEW DEFINITION が拒否された場合 (DENY)、権限設定可能なメタデータは一切 U に示されません。 例外はデータベースのメタデータ (sys.database のコンテンツ) で、これ自体はデータベース ユーザーから非表示にされることはありません。


スキーマ レベルで U に VIEW DEFINITION が与えられた場合 (GRANT)、そのスキーマ内のオブジェクトのメタデータはすべて U に示されます。 同様に、スキーマ レベルで U への VIEW DEFINITION が拒否された場合、権限設定可能なスキーマのメタデータは一切 U に示されません。


特定のオブジェクト O に関して U に VIEW DEFINITION が与えられた場合 (GRANT)、U は O のメタデータを見ることができます。 同様に、特定のオブジェクト O に関して U への VIEW DEFINITION が拒否された場合、O のメタデータは U に示されません。


権限


SQL Server 2005 では権限設定全体が大幅に拡大されており、ほぼすべての操作に対して権限を設定することができます。 権限は、前のバージョン同様、GDR (Grant、Deny、Revoke) に基づいているので、特定のプリンシパル (ログイン、ユーザー、グループ、またはロール) は、明確に権限が付与 (GRANT) されているか、明示的に権限が拒否されているか、あるいは権限が指定されていないかのいずれかとなります。 権限が未指定の場合は、そのプリンシパルがメンバとなっているロールまたはグループの権限が継承されます。 REVOKE (取り消し) は、権限が未指定の状態に戻るように、プリンシパルに対する特別なアクセス権の付与または拒否を取り消すのに使用することができます。 あらゆるレベル (個人またはグループ) で適用される拒否 (DENY) は、ちょうど Windows と同様に、下位レベルでのアクセス権の付与 (GRANT) をすべて無効にします。 従って、データベースの所有者が明示的に ROLE1 への CREATE TABLE 権限を拒否した場合、ROLE1 のメンバも、たとえ明示的に CREATE TABLE の権限が付与 (GRANT) されていたとしてもテーブルを作成することはできません。 加えて、拒否 (DENY) は、付与されたその他すべてのアクセス権に優先します。 データベース所有者が Role1 への CREATE VIEW アクセス権を明示的に拒否し、Role2 への CREATE VIEW を明示的に付与した場合、両方のロールのメンバとなっているユーザーはビューを作成できません。


権限のスコープ


SQL Server 2005 では、さまざまなスコープで権限を付与することが可能です。 これらのスコープには、サーバー レベル、データベース レベル、スキーマ レベル、そしてオブジェクト レベルが含まれます。 サーバー レベルでの権限の付与は新しい機能です。 SQL Server 2005 以前は、固定サーバー ロールを使用してサーバー レベルの権限が管理されていました。


GRANT への拡張


GRANT ステートメントは、SQL Server セキュリティ アーキテクチャの向上を反映させるため、大幅に改変されています。 GRANT では、現在のデータベースのログインまたはセキュリティ アカウントがサーバーの管理、現在のデータベースでのデータ作業、または特定の Transact-SQL ステートメントの実行を可能にするセキュリティ システムにエントリが作成されます。


構文


サーバーの権限 ( マスタデータベースのみ )


GRANT { server_permission [ ,...n ] } 
TO login [ ,...n ] 
[ WITH GRANT OPTION ] 
[ AS { group | role } ]



HTTP エンドポイントの権限 ( マスタデータベースのみ )


GRANT { http_endpoint_permission [ ,...n ] } 
ON HTTP ENDPOINT :: http_endpoint_name 
TO login [ ,...n ] 
[ WITH GRANT OPTION ] 
[ AS { group | role } ]



証明書の権限 ( マスタデータベースのみ )


GRANT { certificate_permission [ ,...n ] } 
ON CERTIFICATE :: certificate_name 
TO login [ ,...n ] 
[ WITH GRANT OPTION ] 
[ AS { group | role } ]



データベースの権限


GRANT { database_permission [ ,...n ] } 
TO security_account [ ,...n ] 
[ WITH GRANT OPTION ] 
[ AS { group | role } ]



スキーマの権限


GRANT { schema_permission [ ,...n ] } 
ON SCHEMA :: schema_name 
TO security_account [ ,...n ] 
[ WITH GRANT OPTION ] 
[ AS { group | role } ]



アセンブリの権限


GRANT { assembly_permission [ ,...n ] } 
ON ASSEMBLY :: assembly_name 
TO security_account [ ,...n ] 
[ WITH GRANT OPTION ] 
[ AS { group | role } ]



タイプの権限


GRANT { type_permission [ ,...n ] } 
ON TYPE :: type_name 
TO security_account [ ,...n ] 
[ WITH GRANT OPTION ] 
[ AS { group | role } ]



フルテキストカタログの権限


GRANT { fulltext_catalog_permission [ ,...n ] } 
ON FULLTEXT CATALOG :: fulltext_catalog_name 
TO security_account [ ,...n ] 
[ WITH GRANT OPTION ] 
[ AS { group | role } ]



サービスブローカーの権限


GRANT { service_broker_permission [ ,...n ] } 
ON <service_broker_securable_class_name> :: 
     <service_broker_securable_instance_name> 
TO security_account [ ,...n ] 
[ WITH GRANT OPTION ] 
[ AS { group | role } ] 
<service_broker_securable_class_name> ::= 
     { MESSAGE TYPE | CONTRACT | SERVICE | ROUTE | REMOTE BINDING} 
<service_broker_securable_instance_name> ::= 
      { message_type_name | contract_name | service_name | route_name | 
remote_service_binding_name }



サーバープリンシパルの権限 ( マスタデータベースのみ )


GRANT { server_principal_permission [ ,...n ] } 
ON LOGIN :: <subject_security_account> 
TO <target_security_account> [ ,...n ] 
[ WITH GRANT OPTION ] 
[ AS { group | role } ] 
<security_account_class_name> ::= 
     { USER | ROLE | APPLICATION ROLE } 
<subject_security_account> ::= security_account 
<target_security_account>  ::= security_account



データベースプリンシパルの権限


GRANT { database_principal_permission [ ,...n ] } 
ON <security_account_class_name> :: 
     <subject_security_account> 
TO <target_security_account> [ ,...n ] 
[ WITH GRANT OPTION ] 
[ AS { group | role } ] 
<security_account_class_name> ::= 
     { USER | ROLE | APPLICATION ROLE } 
<subject_security_account> ::= security_account 
<target_security_account>  ::= security_account



オブジェクトの権限


GRANT 
     { ALL [ PRIVILEGES ] | object_permission [ ,...n ] } 
     { 
          [ ( column [ ,...n ] ) ] ON { table | view | table_valued_function } 
          | ON { table | view | table_valued_function } [ ( column [ ,...n  
] ) ] 
          | ON { stored_procedure | extended_procedure } 
          | ON { scalar_function | aggregate_function } 
          | ON { service_queue } 
          | ON { security_expression } 
          | ON { synonym } 
     } 
TO security_account [ ,...n ] 
[ WITH GRANT OPTION ] 
[ AS { group | role } ]



引数


server_permission


付与されるサーバー レベルの権限。 サーバーの権限は、マスタ データベースのコンテキストで与えられなければなりません。 以下は server_permission のリストです。












権限


説明


暗示される権限








CONNECT SQL


被設定者による SQL Server への接続を可能にします。


CONTROL SERVER 権限






CONNECT SOAP


被設定者による HTTP エンドポイントを通じた SQL Server への接続を可能にします。


CONTROL SERVER 権限






CREATE LOGIN


 


ALTER ANY LOGIN






CREATE HTTP ENDPOINT


 


ALTER ANY HTTP ENDPOINT






CREATE ANY DATABASE


 


ALTER ANY DATABASE






ALTER ANY LOGIN


 


CONTROL SERVER 権限






ALTER ANY HTTP ENDPOINT


 


CONTROL SERVER 権限






ALTER ANY LINKED SERVER


 


CONTROL SERVER 権限






ALTER ANY CONNECTION


 


CONTROL SERVER 権限






ALTER ANY DATABASE


 


CONTROL SERVER 権限






ALTER RESOURCES


 


CONTROL SERVER 権限






ALTER SETTINGS


 


CONTROL SERVER 権限






ALTER TRACE


 


CONTROL SERVER 権限






ALTER ANY CERTIFICATE


 


CONTROL SERVER 権限






ADMINISTER BULK OPERATIONS


 


CONTROL SERVER 権限






EXTERNAL ACCESS


被設定者が、SQL Server サービス アカウント証明書のもと、外部リソースにアクセスできるようにします。


CONTROL SERVER 権限






CREATE DDL EVENT


 


ALTER ANY EVENT






CREATE ERROR EVENT


 


ALTER ANY EVENT






CREATE LANGUAGE EVENT


 


ALTER ANY EVENT






CREATE RESOURCE EVENT


 


ALTER ANY EVENT






CREATE PERFORMANCE EVENT


 


ALTER ANY EVENT






CREATE SECURITY EVENT


 


ALTER ANY EVENT






CREATE BACKUP EVENT


 


ALTER ANY EVENT






ALTER ANY EVENT


 


CONTROL SERVER 権限






CONTROL SERVER


CONTROL SERVER 権限は、sa または sysadmin 固定ロールのメンバシップと同等です。


 







login


サーバー レベルの権限が適用されるログイン名です。


http_endpoint_permission


付与される HTTP エンドポイントの権限。 HTTP エンドポイントの権限は、マスタ データベースのコンテキストでのみ付与することができます。 以下は http_endpoint_permission のリストです。












権限


説明


暗示される権限








CONNECT


被設定者が HTTP エンドポイントに対してリクエストを実行できるようにします。


CONTROL SERVER 権限、または HTTP エンドポイント自体の CONTROL 権限






VIEW DEFINITION


被設定者に HTTP エンドポイントのメタデータが示されます。 被設定者は実質的に HTTP エンドポイントのカタログ セキュリティから除外されます。


CONTROL SERVER 権限、または HTTP エンドポイント自体の CONTROL 権限






ALTER


 


サーバーの ALTER ANY ENDPOINT 権限、または HTTP エンドポイント自体の CONTROL 権限






TAKE OWNERSHIP


 


CONTROL SERVER 権限、または HTTP エンドポイント自体の CONTROL 権限






CONTROL


HTTP エンドポイントの CONTROL 権限は、共同所有と同等です。


CONTROL SERVER 権限、または HTTP エンドポイント自体の CONTROL 権限







http_endpoint_name


権限が適用される HTTP エンドポイント名。


付与される証明書権限。 証明書権限は、マスタ データベースのコンテキストでのみ付与することができます。 以下は certificate_permission のリストです。












権限


説明


暗示される権限








ALTER


被設定者が証明書を改変 (ALTER) できるようにします。


CONTROL SERVER 権限、または証明書自体の CONTROL 権限






CONTROL


被設定者が証明書を変更 (ALTER) または削除 (DROP) できるようにします。


CONTROL SERVER 権限







certificate_name


権限が適用される証明書の名前。database_permission


付与されるデータベース レベルの権限。 データベース 権限は、マスタ データベースを含む、あらゆるデータベース コンテキストで付与することができます。 以下は database_permission のリストです。












権限


説明


暗示される権限






CREATE TABLE


被設定者が、ALTER 権限を持つあらゆるスキーマでテーブルを作成できるようにします。


データベースの ALTER 権限、または CONTROL SERVER 権限






CREATE VIEW


被設定者が、ALTER 権限を持つあらゆるスキーマでビューを作成できるようにします。


データベースの ALTER 権限、または CONTROL SERVER 権限






CREATE PROCEDURE


被設定者が、ALTER 権限を持つあらゆるスキーマでプロシージャを作成できるようにします。


データベースの ALTER 権限、または CONTROL SERVER 権限






CREATE FUNCTION


被設定者が、ALTER 権限を持つあらゆるスキーマでファンクションを作成できるようにします。


データベースの ALTER 権限、または CONTROL SERVER 権限






CREATE RULE


被設定者が、ALTER 権限を持つあらゆるスキーマでルールを作成できるようにします。


データベースの ALTER 権限、または CONTROL SERVER 権限






CREATE DEFAULT


被設定者が、ALTER 権限を持つあらゆるスキーマで初期設定を作成できるようにします。


データベースの ALTER 権限、または CONTROL SERVER 権限






BACKUP DATABASE


 


データベースの CONTROL 権限、または CONTROL SERVER 権限






BACKUP LOG


 


データベースの CONTROL 権限、または CONTROL SERVER 権限






CREATE TYPE


被設定者が、ALTER 権限を持つあらゆるスキーマでタイプを作成できるようにします。


データベースの ALTER 権限、または CONTROL SERVER 権限






CREATE ASSEMBLY


被設定者がデータベースにアセンブリを作成できるようにします。


データベースの ALTER ANY ASSEMBLY 権限、または CONTROL SERVER 権限






CREATE XML SCHEMA


被設定者がデータベースに XML スキーマを作成できるようにします。


データベースの ALTER ANY XML SCHEMA、または CONTROL SERVER






CREATE SCHEMA


被設定者がデータベースのスキーマにアクセスできるようにします。


データベースの ALTER ANY SCHEMA、または CONTROL SERVER






CREATE SYNONYM


被設定者が、ALTER 権限を持つあらゆるスキーマでシノニムを作成できるようにします。


データベースの ALTER 権限、または CONTROL SERVER 権限






CREATE AGGREGATE


被設定者が、ALTER 権限を持つあらゆるスキーマで集計関数を作成できるようにします。


データベースの ALTER 権限、または CONTROL SERVER 権限






CREATE ROLE


被設定者がデータベースにロールを作成できるようにします。


データベースの ALTER ANY ROLE 権限、または CONTROL SERVER 権限






CREATE MESSAGE TYPE


 


データベースの ALTER ANY MESSAGE TYPE、または CONTROL SERVER






CREATE SERVICE CONTRACT


 


データベースの ALTER ANY SERVICE CONTRACT、または CONTROL SERVER






CREATE QUEUE


 


データベースの ALTER 権限、または CONTROL SERVER 権限






CREATE ROUTE


 


データベースの ALTER 権限、または CONTROL SERVER 権限






CREATE REMOTE BINDING


 


データベースの ALTER 権限、または CONTROL SERVER 権限






CONNECT


 


データベースの CONNECT REPLICATION、または CONTROL SERVER






CONNECT REPLICATION


 


データベースの CONTROL 権限、または CONTROL SERVER 権限






CHECKPOINT


 


データベースの CONTROL 権限、または CONTROL SERVER 権限






ALTER ANY USER


 


データベースの ALTER 権限、または CONTROL SERVER 権限






ALTER ANY ROLE


 


データベースの ALTER 権限、または CONTROL SERVER 権限






ALTER ANY APPLICATION ROLE


 


データベースの ALTER 権限、または CONTROL SERVER 権限






ALTER ANY SCHEMA


 


データベースの ALTER 権限、または CONTROL SERVER 権限






ALTER ANY ASSEMBLY


 


データベースの ALTER 権限、または CONTROL SERVER 権限






ALTER ANY XML SCHEMA


 


データベースの ALTER 権限、または CONTROL SERVER 権限






ALTER ANY MESSAGE TYPE


 


データベースの ALTER 権限、または CONTROL SERVER 権限






ALTER ANY SERVICE CONTRACT


 


データベースの ALTER 権限、または CONTROL SERVER 権限






ALTER ANY SERVICE


 


データベースの ALTER 権限、または CONTROL SERVER 権限






ALTER ANY ROUTE


 


データベースの ALTER 権限、または CONTROL SERVER 権限






ALTER ANY REMOTE BINDING


 


データベースの ALTER 権限、または CONTROL SERVER 権限






ALTER ANY FULLTEXT CATALOG


 


データベースの ALTER 権限、または CONTROL SERVER 権限






SELECT


被設定者がデータベースのあらゆるスキーマのオブジェクトに SELECT クエリを実行できるようにします。


データベースの CONTROL 権限、または CONTROL SERVER 権限






INSERT


被設定者がデータベースのあらゆるスキーマのオブジェクトに INSERT クエリを実行できるようにします。


データベースの CONTROL 権限、または CONTROL SERVER 権限






UPDATE


被設定者がデータベースのあらゆるスキーマのオブジェクトに UPDATE クエリを実行できるようにします。


データベースの CONTROL 権限、または CONTROL SERVER 権限






DELETE


被設定者がデータベースのあらゆるスキーマのオブジェクトに DELETE クエリを実行できるようにします。


データベースの CONTROL 権限、または CONTROL SERVER 権限






REFERENCES


被設定者がデータベースのあらゆるオブジェクト、アセンブリ、またはタイプに REFERENCES をバインドできるようにします。


データベースの CONTROL 権限、または CONTROL SERVER 権限






EXECUTE


被設定者が、データベースのあらゆるスキーマのプロシージャ、あらゆるスキーマのスカラ関数、またはあらゆるアセンブリのメソッドを実行 (EXECUTE) できるようにします。


データベースの CONTROL 権限、または CONTROL SERVER 権限






CREATE DATABASE DDL EVENT


 


データベースの ALTER、CONTROL SERVER、またはサーバーの CREATE DDL EVENT






EXEMPT ROW SECURITY


被設定者は、通常データベースのすべてのスキーマのオブジェクトに適用される行レベルのセキュリティ式から除外されます。


データベースの CONTROL 権限、または CONTROL SERVER 権限






ALTER OPTIONS


 


データベースの ALTER 権限、または CONTROL SERVER 権限






TAKE OWNERSHIP


 


データベースの CONTROL 権限、または CONTROL SERVER 権限






ALTER


 


データベースの CONTROL、またはサーバーの ALTER ANY DATABASE






CONTROL


データベースの CONTROL 権限は、dbo または db_owner 固定ロールのメンバシップと同等です。


CONTROL SERVER 権限







schema_permission


付与されるスキーマ レベルの権限。 スキーマ 権限は、マスタ データベースを含む、あらゆるデータベース コンテキストで付与することができます。 以下は schema_permission のリストです。












権限


説明


暗示される権限








SELECT


被設定者がスキーマのあらゆるオブジェクトに SELECT クエリを実行できるようにします。


スキーマの CONTROL 権限、またはデータベースの SELECT 権限






INSERT


被設定者がスキーマのあらゆるオブジェクトに INSERT クエリを実行できるようにします。


スキーマの CONTROL 権限、またはデータベースの INSERT 権限






UPDATE


被設定者がスキーマのあらゆるオブジェクトに UPDATE クエリを実行できるようにします。


スキーマの CONTROL 権限、またはデータベースの UPDATE 権限






DELETE


被設定者がスキーマのあらゆるオブジェクトに DELETE クエリを実行できるようにします。


スキーマの CONTROL 権限、またはデータベースの DELETE 権限






REFERENCES


被設定者がスキーマのあらゆるオブジェクトに REFERENCES をバインドできるようにします。


スキーマの CONTROL 権限、またはデータベースの REFERENCES 権限






EXEMPT ROW SECURITY


被設定者は、通常スキーマのすべてのオブジェクトに適用される行レベルのセキュリティ式から除外されます。


スキーマの CONTROL 権限、またはデータベースの EXEMPT ROW SECURITY 権限






VIEW DEFINITION


被設定者にスキーマのすべてのオブジェクトのメタデータがすべて示されます。 被設定者は実質的にスキーマ全体にわたってカタログ セキュリティから除外されます。


スキーマの CONTROL 権限、またはデータベースの VIEW DEFINITION 権限






ALTER


被設定者がスキーマのあらゆるオブジェクトを変更 (ALTER) できるようにします。


スキーマの CONTROL 権限、またはデータベースの ALTER ANY SCHEMA 権限






TAKE OWNERSHIP


 


スキーマの CONTROL 権限、またはデータベースの CONTROL 権限






CONTROL


スキーマの CONTROL 権限は、そのスキーマに含まれるすべてのオブジェクトの共同所有と同等です。


データベースの CONTROL 権限







schema_name


スキーマ レベルの権限が適用されるスキーマの名前。


assembly_permission


付与されるアセンブリ 権限。 アセンブリ権限は、マスタ データベースを含む、あらゆるデータベース コンテキストで付与することができます。 以下は assembly_permission のリストです。












権限


説明


暗示される権限








REFERENCES


 


データベースの REFERENCES 権限、またはアセンブリ自体の CONTROL 権限






EXECUTE


 


データベースの EXECUTE 権限、またはアセンブリ自体の CONTROL 権限






VIEW DEFINITION


被設定者にアセンブリのメタデータを示します。 被設定者はアセンブリのカタログ セキュリティから実質的に除外されます。


データベースの VIEW DEFINITION 権限、またはアセンブリ自体の CONTROL 権限






ALTER


 


データベースの ALTER ANY ASSEMBLY 権限、またはアセンブリ自体の CONTROL 権限






TAKE OWNERSHIP


 


データベースの CONTROL 権限、またはアセンブリ自体の CONTROL 権限






CONTROL


アセンブリの CONTROL 権限は共同所有と同等です。


データベースの CONTROL 権限







assembly_name


アセンブリ 権限が適用されるアセンブリの名前。


type_permission


付与されるタイプ 権限。 タイプ 権限は、マスタ データベースを含む、あらゆるデータベース コンテキストで付与することができます。 以下は type_permission のリストです。












権限


説明


暗示される権限








REFERENCES


 


包含されるスキーマの REFERENCES 権限、またはタイプ自体の CINTROL 権限






EXECUTE


 


包含されるスキーマの EXECUTE 権限、またはタイプ自体の CINTROL 権限






VIEW DEFINITION


被設定者にタイプのメタデータを示します。 被設定者はタイプのカタログ セキュリティから実質的に除外されます。


包含されるスキーマの VIEW DEFINITION 権限、またはタイプ自体の CINTROL 権限






TAKE OWNERSHIP


 


包含されるスキーマの CONTROL 権限、またはタイプ自体の CINTROL 権限






CONTROL


タイプのフルテキスト カタログそれ自体に対する権限の CONTROL は共同所有と同等です。


包含されるスキーマの CONTROL 権限







type_name


権限が適用されるタイプの名前。


fulltext_catalog_permission


付与されるフルテキスト カタログの権限。 フルテキスト カタログ 権限は、マスタ データベースを含む、あらゆるデータベース コンテキストで付与することができます。 以下は fulltext_catalog_permission のリストです。












権限


説明


暗示される権限








REFERENCES


 


データベースの REFERENCES 権限、またはフルテキスト カタログ自体の CONTROL 権限






VIEW DEFINITION


被設定者にフルテキスト カタログのメタデータを示します。 被設定者はフルテキスト カタログのカタログ セキュリティから実質的に除外されます。


データベースの VIEW DEFINITION 権限、またはフルテキスト カタログ自体の CONTROL 権限






TAKE OWNERSHIP


 


データベースの CONTROL 権限、またはフルテキスト カタログ自体の CONTROL 権限






CONTROL


フルテキスト カタログの CONTROL 権限は共同所有と同等です。


データベースの CONTROL 権限







fulltext_catalog_name


権限が適用されるフルテキスト カタログの名前。


service_broker_permission


付与されるサービス ブローカーの権限。 サービス ブローカー 権限は、マスタ データベースを含む、あらゆるデータベース コンテキストで付与することができます。 以下は service_broker_permission のリストです。 \












権限


説明


暗示される権限








REFERENCES


被設定者がこのメッセージ タイプに REFERENCES をバインドできるようにします。


データベースの REFERENCES 権限、またはメッセージ タイプ自体の CONTROL 権限






VIEW DEFINITION


被設定者にメッセージ タイプのメタデータを示します。 被設定者はメッセージ タイプのカタログ セキュリティから実質的に除外されます。


データベースの VIEW DEFINITION 権限、またはメッセージ タイプ自体の CONTROL 権限






TAKE OWNERSHIP


 


データベースの CONTROL 権限、またはメッセージ タイプ自体の CONTROL 権限






CONTROL


メッセージ タイプの CONTROL 権限は共同所有と同等です。


データベースの CONTROL 権限







以下は CONTRACT の service_broker_permission のリストです。












権限


説明


暗示される権限








REFERENCES


被設定者がこのサービス コントラクトに REFERENCES をバインドできるようにします。


データベースの REFERENCES 権限、またはサービス コントラクト自体の CONTROL 権限






VIEW DEFINITION


被設定者にサービス コントラクトのメタデータを示します。 被設定者はサービス コントラクトのカタログ セキュリティから実質的に除外されます。


データベースの VIEW DEFINITION 権限、またはサービス コントラクト自体の CONTROL 権限






TAKE OWNERSHIP


 


データベースの CONTROL 権限、またはサービス コントラクト自体の CONTROL 権限






CONTROL


サービス コントラクトの CONTROL 権限は共同所有と同等です。


データベースの CONTROL 権限







以下は SERVICE の service_broker_permission のリストです。












権限


説明


暗示される権限








SEND


被設定者がこのサービスに REFERENCES をバインドできるようにします。


データベースの REFERENCES 権限、またはサービス自体の CONTROL 権限






VIEW DEFINITION


被設定者にサービスのメタデータを示します。 被設定者はサービスのカタログ セキュリティから実質的に除外されます。


データベースの VIEW DEFINITION 権限、またはサービス自体の CONTROL 権限






TAKE OWNERSHIP


 


データベースの CONTROL 権限、またはサービス自体の CONTROL 権限






CONTROL


サービスの CONTROL 権限は共同所有と同等です。


データベースの CONTROL 権限







以下は ROUTE の service_broker_permission のリストです。












権限


説明


暗示される権限








ALTER


被設定者がルートを変更 (ALTER) できるようにします。


データベースの CONTROL 権限、またはルート自体の CONTROL 権限






VIEW DEFINITION


被設定者にルートのメタデータを示します。 被設定者はルートのカタログ セキュリティから実質的に除外されます。


データベースの VIEW DEFINITION、またはルート自体の CONTROL 権限






TAKE OWNERSHIP


 


データベースの CONTROL 権限、またはルート自体の CONTROL 権限






CONTROL


ルートの CONTROL 権限は共同所有と同等です。


データベースの CONTROL 権限







以下は REMOTE BINDING の service_broker_permission のリストです。












権限


説明


暗示される権限








ALTER


被設定者がリモート サービスのバインディングを変更 (ALTER) できるようにします。


データベースの CONTROL 権限、またはリモート サービス バインディング自体の CONTROL 権限






VIEW DEFINITION


被設定者にリモート サービス バインディングのメタデータを示します。 被設定者はリモート サービス バインディングのカタログ セキュリティから実質的に除外されます。


データベースの VIEW DEFINITION 権限、またはリモート サービス バインディング自体の CONTROL 権限






TAKE OWNERSHIP


 


データベースの CONTROL 権限、またはリモート サービス バインディング自体の CONTROL 権限






CONTROL


リモート サービス バインディングの CONTROL 権限は共同所有と同等です。


データベースの CONTROL 権限







message_type_name


権限が適用されるサービス ブローカーのメッセージ タイプの名前。


contract_name


権限が適用されるサービス ブローカーのコントラクトの名前。


service_name


権限が適用されるサービス ブローカーのサービスの名前。


route_name


権限が適用されるサービス ブローカーのルートの名前。


remote_service_binding_name


権限が適用されるサービス ブローカーのリモート サービス バインディングの名前。


server_principal_permission


付与されるサーバー プリンシパル 権限。 サーバー プリンシパル権限はマスタ データベースのコンテキストでのみ付与することができます。 以下は server_principal_permission のリストです。












権限


説明


暗示される権限








IMPERSONATE


被設定者がログインを偽装できるようにします。


CONTROL SERVER 権限またはログイン自体の CONTROL 権限






VIEW DEFINITION


被設定者に、ログインを記述するメタデータを示します。 被設定者はログインのカタログ セキュリティから実質的に除外されます。


CONTROL SERVER 権限またはログイン自体の CONTROL 権限






ALTER


 


サーバーの ALTER ANY LOGIN 権限、またはログイン自体の CONTROL 権限






TAKE OWNERSHIP


 


CONTROL SERVER 権限またはログイン自体の CONTROL 権限






CONTROL


ログインの CONTROL 権限により、被設定者はログインを変更 (ALTER)、削除 (DROP)、または偽装 (IMPERSONATE) することができます。


CONTROL SERVER 権限







database_principal_permission


付与されるデータベース プリンシパル 権限。 データベース プリンシパル 権限は、マスタ データベースを含む、あらゆるデータベース コンテキストで付与することができます。 以下は USER の database_principal_permission のリストです。












権限


説明


暗示される権限








IMPERSONATE


被設定者がユーザーを偽装できるようにします。


データベースの CONTROL 権限、またはユーザー自体の CONTROL 権限 VIEW DEFINITION






VIEW DEFINITION


被設定者に、ログインを記述するメタデータを示します。 被設定者はユーザーのカタログ セキュリティから実質的に除外されます。


データベースの VIEW DEFINITION 権限、またはユーザー自体の CONTROL 権限






ALTER


 


データベースの ALTER ANY USER 権限、またはユーザー自体の CONTROL 権限






CONTROL


ユーザーの CONTROL 権限により、被設定者はユーザーを変更 (ALTER)、削除 (DROP)、または偽装 (IMPERSONATE) することができます。


データベースの CONTROL 権限







以下は ROLE の database_principal_permission のリストです。












権限


説明


暗示される権限








VIEW DEFINITION


被設定者に、ロールを記述するメタデータを示します。 被設定者はロールのカタログ セキュリティから実質的に除外されます。


データベースの VIEW DEFINITION 権限、またはロール自体の CONTROL 権限






ALTER


 


データベースの ALTER ANY ROLE 権限、またはロール自体の CONTROL 権限






TAKE OWNERSHIP


 


データベースの CONTROL 権限、またはロール自体の CONTROL 権限






CONTROL


ロールの CONTROL 権限により、被設定者はロールを変更 (ALTER)、削除 (DROP)、または偽装 (IMPERSONATE) することができます。


データベースの CONTROL 権限







以下は APPLICATION ROLE の database_principal_permission のリストです。












権限


説明


暗示される権限








VIEW DEFINITION


被設定者に、アプリケーション ロールを記述するメタデータを示します。 被設定者はアプリケーション ロールのカタログ セキュリティから実質的に除外されます。


データベースの VIEW DEFINITION 権限、またはアプリケーション ロール自体の CONTROL 権限






ALTER


 


データベースの ALTER ANY APPLICATION ROLE 権限、またはアプリケーション ロール自体の CONTROL 権限






CONTROL


ロールの CONTROL 権限により、被設定者はアプリケーション ロールを変更 (ALTER)、削除 (DROP)、または偽装 (IMPERSONATE) することができます。


データベースの CONTROL 権限







object_permission


付与されるオブジェクト レベルの権限。 オブジェクト権限は、テーブル、ビュー、プロシージャなどのように、スキーマでスコープ化されるオブジェクトに与えられます。 オブジェクト権限は、マスタ データベースを含む、あらゆるデータベース コンテキストで付与することができます。 以下は object_permission のリストです。












権限


説明


暗示される権限








SELECT


被設定者がオブジェクトに対して SELECT クエリを実行できるようにします。


包含されるスキーマの SELECT 権限、またはオブジェクト自体の CONTROL 権限






UPDATE


被設定者がオブジェクトに対して UPDATE クエリを実行できるようにします。


包含されるスキーマの CONTROL UPDATE 権限、またはオブジェクト自体の CONTROL 権限






REFERENCES


被設定者がオブジェクトに REFERENCES をバインドできるようにします。 テーブルを参照する FOREIGN KEY の制限を作成するには、そのテーブルの REFERENCES 権限が必要です。


オブジェクトを参照する WITH SCHEMABINDING 節で FUNCTION または VIEW を作成するには、そのオブジェクトの REFERENCES 権限が必要です。


包含されるスキーマの REFERENCES 権限、またはオブジェクト自体の CONTROL 権限






INSERT


被設定者がオブジェクトに対して INSERT クエリを実行できるようにします。


包含されるスキーマの INSERT 権限、またはオブジェクト自体の CONTROL 権限






DELETE


被設定者がオブジェクトに対して DELETE クエリを実行できるようにします。


包含されるスキーマの DELETE 権限、またはオブジェクト自体の CONTROL 権限






EXECUTE


被設定者が実行 (EXECUTE) プロシージャ、スカラ値の関数、および集計関数を実行できるようにします。


包含されるスキーマの EXECUTE 権限、またはオブジェクト自体の CONTROL 権限






RECEIVE


被設定者がサービス キューからメッセージを読み出せるようにします。


包含されるスキーマの CONTROL 権限、またはオブジェクト自体の CONTROL 権限






VIEW DEFINITION


被設定者にオブジェクトのメタデータを示します。 被設定者はオブジェクトのカタログ セキュリティから実質的に除外されます。


包含されるスキーマの VIEW DEFINITION 権限、またはオブジェクト自体の CONTROL 権限






ALTER


被設定者がオブジェクトに対して ALTER ステートメントを実行できるようにします。


包含されるスキーマの ALTER 権限、またはオブジェクト自体の CONTROL 権限






TAKE OWNERSHIP


被設定者がオブジェクトを所有できるようにします。


包含されるスキーマの CONTROL 権限、またはオブジェクト自体の CONTROL 権限






CONTROL


被設定者にオブジェクトに関するすべての権限を与えます。 また、オブジェクトの CONTROL 権限により、被設定者はオブジェクトを変更 (ALTER) または削除 (DROP) することができます。


包含されるスキーマの CONTROL 権限







次の表に、さまざまな種類のオブジェクトに適用されるオブジェクト レベルの権限を示します。











権限


適用先








SELECT


セキュリティ式

シノニム

テーブル + 列

テーブル値関数 (T-SQL および CLR) + 列

ビュー + 列






UPDATE


シノニム

テーブル + 列

ビュー + 列






REFERENCES


スカラ & 集計関数 (T-SQL および CLR)

サービス ブローカー キュー

テーブル + 列

テーブル値関数 (T-SQL および CLR) + 列

ビュー + 列






INSERT


シノニム

テーブル + 列

ビュー + 列






DELETE


シノニム

テーブル + 列

ビュー + 列






EXECUTE


プロシージャ (T-SQL および CLR)

スカラ & 集計関数 (T-SQL および CLR)

シノニム






RECEIVE


サービス ブローカー キュー






VIEW DEFINITION


プロシージャ (T-SQL および CLR)

サービス ブローカー キュー

スカラ & 集計関数 (T-SQL および CLR)

シノニム

テーブル

テーブル値関数 (T-SQL および CLR)

ビュー






ALTER


プロシージャ (T-SQL および CLR)

スカラ & 集計関数 (T-SQL および CLR)

サービス ブローカー キュー

テーブル

テーブル値関数 (T-SQL および CLR)

ビュー






TAKE OWNERSHIP


プロシージャ (T-SQL および CLR)

スカラ & 集計関数 (T-SQL および CLR)

シノニム

テーブル

テーブル値関数 (T-SQL および CLR)

ビュー






CONTROL


プロシージャ (T-SQL および CLR)


スカラ & 集計関数 (T-SQL および CLR)

サービス ブローカー キュー

シノニム

テーブル

テーブル値関数 (T-SQL および CLR)

ビュー







ALL


適用可能な権限をすべて付与します。 オブジェクト以外の権限では、sysadmin および db_securityadmin ロールのメンバのみ ALL を使用することができます。 オブジェクトの権限では、sysadmin 、 db_securityadmin、および db_owner ロールのメンバ、そしてデータベース オブジェクトの所有者が ALL を使用することができます。


オブジェクト以外のアクセス権では、ALL は SQL Server 2000 で定義された「ステートメントの権限」を意味します。 これには、CONTROL、IMPERSONATE、VIEW_DEFINITION といった新しい権限は一切含まれません。


オブジェクトのアクセス権では、ALL は ANSI に準拠した SELECT、INSERT、UPDATE、DELETE、EXECUTE、そして REFERENCES の権限を意味します。 これには、CONTROL、TAKE OWNERSHIP、VIEW DEFINITION といった新しい権限は一切含まれません。


n


カンマ区切りリストで繰り返し可能なアイテムであることを示すプレースホルダ。


security_account


権限が適用されるセキュリティ アカウント。 セキュリティ アカウントは以下が考えられます。


    

  • Microsoft SQL Server ユーザー
    

    • 

  • SQL Server ロール
    

    • 

  • Microsoft Windows NT ユーザー
    

    • 

  • Windows NT グループ
    

    • 



SQL Server または Windows NT のユーザー アカウントに権限が与えられた場合、その権限の影響が及ぶアカウントは指定された security_account のみとなります。 SQL Server のロールまたは Windows NT のグループに権限が与えられた場合、その権限はグループまたはロールのメンバである現在のデータベースのすべてのユーザーに影響します。 グループまたはロールとそのメンバとのあいだに権限の不一致が存在する場合、最も制約の厳しい権限 (DENY) が優先されます。 現在のデータベースには security_account がなければなりません。 すでにユーザーが作成されているか、現在のデータベースへのアクセスが与えられているのでない限り、別のデータベースのユーザー、ロール、またはグループに権限を与えることはできません。


GRANT では 2 つの特別なセキュリティ アカウントを使用することができます。 public ロールに与えられる権限は、データベースのすべてのユーザーに適用されます。 guest ユーザーに与えられる権限は、データベースにユーザー アカウントはないものの、ゲスト アカウントでデータベースに入るすべてのログインに使用されます。


Windows NT のローカル グループまたはグローバル グループに権限を与える際は、そのグループが定義されているドメイン名またはコンピュータ名、バックスラッシュ、グループ名の順で指定します。 ただし、Windows NT に組み込まれたローカル グループに権限を与えるには、ドメイン名またはコンピュータ名の代わりに BUILTIN を指定してください。


PRIVILEGES


SQL-92 に準拠するために含めることのできるオプションのキーワードです。


permission


付与されるオブジェクトの権限です。 テーブル、テーブル値関数、またはビューにオブジェクトのアクセス権が与えられる場合、SELECT、INSERT、DELETE、REFERENCES、または UPDATE の権限を 1 つ以上権限のリストに含めることができます。 列リストは、SELECT および UPDATE 権限に加えて提供することができます。 SELECT や UPDATE 権限とともに列リストが提供されない場合、テーブルのすべての列、ビュー、またはテーブル値関数にそのアクセス権が適用されます。


ストアド プロシージャに与えられたオブジェクト権限には EXECUTE のみ含めることができます。 スカラ値関数に与えられたオブジェクト権限には EXECUTE と REFERENCES を含めることができます。


SELECT ステートメントの列にアクセスするには、その列に SELECT 権限が必要です。 UPDATE ステートメントを使用して列を更新するには、その列に UPDATE 権限が必要です。


テーブルを参照する FOREIGN KEY の制限を作成するには、そのテーブルに REFERENCES 権限が必要です。


オブジェクトを参照する WITH SCHEMABINDING 節で FUNCTION または VIEW を作成するには、そのオブジェクトの REFERENCES 権限が必要です。


column


権限が与えられる現在のデータベースの列の名前です。


table


権限が与えられる現在のデータベースのテーブルの名前です。


view


権限が与えられる現在のデータベースのビューの名前です。


table_valued_function


権限が与えられる現在のデータベースのテーブル値関数の名前です。


stored_procedure


権限が与えられる現在のデータベースのストアド プロシージャの名前です。


extended_procedure


権限が与えられる拡張ストアド プロシージャの名前です。


user_defined_function


権限が与えられるユーザー定義関数の名前です。


scalar_function


権限が与えられるスカラ関数 (T-SQL または CLR) の名前です。


aggregate_function


権限が与えられる CLR 集計関数の名前です。


service_queue


権限が与えられるサービス ブローカー サービス キューの名前です。


security_expression


権限が与えられる行レベルのセキュリティ式の名前です。


synonym


権限が与えられるシノニムの名前です。


WITH GRANT OPTION


指定されたオブジェクト権限を security_account が他のセキュリティ アカウントに与えられるように指定します。


AS {group | role}


現在のデータベースの GRANT ステートメントを実行する権限を持ったセキュリティ アカウントのオプションの名前を指定します。 オブジェクトの権限がグループまたはロールとして付与されるときは、AS が使用されます。 GRANT ステートメントを実行できるのはグループやロールではなくユーザーのみであるため、グループまたはロールの特定のメンバは、そのグループまたはロールの権限でオブジェクトの権限を付与します。


備考


データベース間で共通する権限は認められません。 権限は、現在のデータベースのオブジェクトおよびステートメントについて現在のデータベースのユーザーにのみ与えることができます。 ユーザーが別のデータベースのオブジェクトへの権限を必要としている場合は、他のデータベースにそのユーザーのアカウントを作成するか、または、現在のデータベースに加え、他のデータベース アカウントへのアクセスをそのユーザーに付与してください。


EXECUTE 権限はすでに public ロールに与えられ、誰でも実行できることから、一部のシステム ストアド プロシージャは除外されます。 しかしこれらのプロシージャ内では、権限のチェックは固定ロールのメンバシップに基づいています。 ユーザーがストアド プロシージャを実行するのに必要な、適切な固定サーバーまたはデータベース ロールのメンバでない場合、ストアド プロシージャは中断されます。


REVOKE ステートメントは付与された権限を削除するのに使用することができ、DENY ステートメントはユーザーが各自のユーザー アカウントの GRANT を通じて権限を得るのを防ぐために使用することができます。


与えられた権限は、その付与レベル (ユーザー、グループ、またはロール) で拒否または取り消された権限を削除します。 グループやロールなどのユーザーを含む、別のレベルで拒否された同じ権限が優先されます。 ただし、同じ権限の別のレベルでの取り消しは引き続き適用されるものの、ユーザーがオブジェクトにアクセスするのを妨げるわけではありません。


アプリケーション ロールがアクティブになると、コンテキスト切り替えの効果があります。 ユーザーに関する権限はすべて削除され、アプリケーションに関する権限が有効となります。


権限


sysadmin ロールのメンバは、サーバーまたはデータベースのあらゆる権限を与えることが可能です。 オブジェクト所有者は、各自が所有するオブジェクトの権限を与えることができます。 db_owner ロールのメンバは、各自のデータベースのあらゆるスキーマまたはオブジェクトの権限を与えることができます。


権限が必要なのは、データベースにオブジェクトを加えたり、あるいはデータベースまたはサーバーそれ自体で管理活動を行ったりするステートメントです。 そのようなステートメントには、そのステートメントを実行するための権限を自動的に得る一定のロール一式がそれぞれに含まれます。 たとえば、CREATE TABLE 権限は、既定の sysadmin と db_owner および db_ddladmin ロールのメンバに設定されます。 テーブルに SELECT ステートメントを実行するための権限は、既定の sysadmin および db_owner ロール*、*そしてオブジェクトの所有者に設定されます。


Transact-SQL ステートメントには、権限として付与できないものがあり、これらのステートメントを実行できるようにするには、特別なステートメントを実行するための権限が含まれている固定ロールのメンバシップが必要です。


Dbcreator、processadmin、securityadmin、serveradmin、および bulkadmin 固定サーバー ロールのメンバには、次の表に示された Transact-SQL のみを実行する権限があります。















ステートメント


dbcreator


processadmin


securityadmin


serveradmin


bulkadmin








ALTER DATABASE


X


 


 


 


 






CREATE DATABASE


X


 


 


 


 






BULK INSERT


 


 


 


 


X






DBCC


 


 


 


X (1)


 






DENY


 


 


X (2)


 


 






GRANT


 


 


X (2)


 


 






KILL


 


X


 


 


 






RECONFIGURE


 


 


 


X


 






RESTORE


X


 


 


 


 






REVOKE


 


 


X (2)


 


 






SHUTDOWN


 


 


 


X


 







(1) 詳細は Books Online の DBCC ステートメントを参照してください。


(2) CREATE DATABASE ステートメントにのみ適用されます。


注意 diskadmin および setupadmin 固定サーバー ロールのメンバには Transact-SQL ステートメントを実行するための権限は一切なく、実行のための権限は一定のシステム ストアド プロシージャに限られます。 しかし、sysadmin 固定サーバー ロールのメンバにはあらゆる Transact-SQL ステートメントを実行する権限があります。


以下の固定データベース ロールのメンバには、特定の Transact-SQL ステートメントを実行するための権限があります。
















ステートメント


db_owner


db_datareader


db_datawriter


db_ddladmin


db_backupoperator


db_securityadmin








ALTER DATABASE


X


 


 


X


 


 






ALTER FUNCTION


X


 


 


X


 


 






ALTER PROCEDURE


X


 


 


X


 


 






ALTER TABLE


X (1)


 


 


X


 


 






ALTER TRIGGER


X


 


 


X


 


 






ALTER VIEW


X (1)


 


 


X


 


 






BACKUP


X


 


 


 


X


 






CHECKPOINT


X


 


 


 


X


 






CREATE DEFAULT


X


 


 


X


 


 






CREATE FUNCTION


X


 


 


X


 


 






CREATE INDEX


X (1)


 


 


X


 


 






CREATE PROCEDURE


X


 


 


X


 


 






CREATE RULE


X


 


 


X


 


 






CREATE TABLE


X


 


 


X


 


 






CREATE TRIGGER


X (1)


 


 


X


 


 






CREATE VIEW


X


 


 


X


 


 






DBCC


X


 


 


 


X (2)


 






DELETE


X (1)


 


X


 


 


 






DENY


X


 


 


 


 


X






オブジェクトでの DENY


X


 


 


 


 


 






DROP


X (1)


 


 


X


 


 






EXECUTE


X (1)


 


 


 


 


 






GRANT


X


 


 


 


 


X






オブジェクトでの GRANT


X (1)


 


 


 


 


 






INSERT


X (1)


 


X


 


 


 






READTEXT


X (1)


X


 


 


 


 






REFERENCES


X (1)


 


 


X


 


 






RESTORE


X


 


 


 


 


 






REVOKE


X


 


 


 


 


X






オブジェクトでの REVOKE


X (1)


 


 


 


 


 






SELECT


X (1)


X


 


 


 


 






TRUNCATE TABLE


X (1)


 


 


X


 


 






UPDATE


X (1)


 


X


 


 


 






UPDATE STATISTICS


X (1)


 


 


 


 


 






UPDATETEXT


X (1)


 


X


 


 


 






WRITETEXT


X (1)


 


X


 


 


 







(1) 権限はオブジェクト所有者にも適用されます。


(2) 詳細は DBCC ステートメントを参照してください。


注意 db_accessadmin 固定データベース ロールのメンバには Transact-SQL ステートメントを実行するための権限は一切なく、実行のための権限は一定のシステム ストアド プロシージャに限られます。


自動的に public に与えられ、実行に権限を必要としない Transact-SQL ステートメントは以下のとおりです。


    

  • BEGIN TRANSACTION
    

    • 

  • COMMIT TRANSACTION
    

    • 

  • PRINT
    

    • 

  • RAISERROR
    

    • 

  • ROLLBACK TRANSACTION
    

    • 

  • SAVE TRANSACTION
    

    • 

  • SET
    

    • 



システム ストアド プロシージャを実行するのに必要な権限についての詳細は、Books Online の適切なシステム ストアド プロシージャの説明を参照してください。


固定サーバーロールから権限の指定へ


この表は、固定サーバー ロールがどのようにサーバー レベルの権限にマップされるのかを示しています。











ロール


権限の指定








Serveradmin


GRANT ALTER ANY HTTP ENDPOINT TO serveradmin


GRANT ALTER SETTINGS TO serveradmin


GRANT ALTER RESOURCES TO serveradmin


GRANT ALTER TRACE TO serveradmin


GRANT ALTER ANY CONNECTION TO serveradmin






Sysadmin


GRANT CONTROL SERVER TO sysadmin






Setupadmin


GRANT ALTER ANY LINKED SERVER TO setupadmin






securityadmin


GRANT ALTER ANY LOGIN TO securityadmin






processadmin


GRANT ALTER ANY CONNECTION TO processadmin






dbcreator


GRANT ALTER ANY DATABASE TO dbcreator






diskadmin


GRANT ALTER RESOURCES ON SERVER TO diskadmin







固定データベースロールから権限の指定へ


この表は、固定データベース ロールがどのようにデータベース レベルの権限にマップされるのかを示しています。











ロール


権限の指定








db_accessadmin


GRANT ALTER ANY USER TO db_accessadmin


GRANT CREATE SCHEMA TO db_accessadmin


GRANT CONNECT DATABASE TO db_accessadmin WITH GRANT OPTION






db_securityadmin


GRANT ALTER ANY APPLICATION ROLE TO db_securityadmin


GRANT ALTER ANY ROLE TO db_securityadmin


GRANT CREATE SCHEMA TO db_securityadmin






db_ddladmin


GRANT CREATE TABLE TO db_ddladmin


GRANT CREATE VIEW TO db_ddladmin


GRANT CREATE PROC TO db_ddladmin


GRANT CREATE FUNCTION TO db_ddladmin


GRANT CREATE RULE TO db_ddladmin


GRANT CREATE DEFAULT TO db_ddladmin


GRANT CREATE TYPE TO db_ddladmin


GRANT CREATE SYNONYM TO db_ddladmin


GRANT CREATE AGGREGATE TO db_ddladmin


GRANT ALTER ANY SCHEMA TO db_ddladmin


GRANT ALTER ANY MESSAGE TYPE TO db_ddladmin


GRANT ALTER ANY SERVICE CONTRACT TO db_ddladmin


GRANT ALTER ANY SERVICE TO db_ddladmin


GRANT ALTER ANY XML SCHEMA TO db_ddladmin


GRANT ALTER ANY DATASPACES TO db_ddladmin


GRANT ALTER ANY FULLTEXT CATALOG TO db_ddladmin






db_dumpoperator


GRANT CHECKPOINT TO db_dumpoperator


GRANT BACKUP DATABASE TO db_dumpoperator


GRANT BACKUP LOG TO db_dumpoperator






db_datareader


GRANT SELECT TO db_datareader






db_denydatareader


DENY SELECT TO db_denydatareader






db_datawrite


GRANT INSERT, UPDATE, DELETE TO db_datawrite






db_denydatareader


DENY INSERT, UPDATE, DELETE TO db_datawrite







例


A. データベース権限の付与


この例では、Mary と John というユーザー、そして Corporate\BobJ という Windows NT のグループに複数のデータベース 権限を与えます。


GRANT CREATE DATABASE, CREATE ASSEMBLY 
TO Mary, John, [Corporate\BobJ]



B. オブジェクト権限の付与


この例は、好ましい権限の順番を示します。 まず SELECT 権限が public ロールに与えられた後、特定の権限が Mary、John、そして Tom というユーザーに与えられます。 その結果、これらのユーザーには author テーブルへのすべての権限が与えられます。


USE pubs 
GO 
GRANT SELECT 
ON authors 
TO public 
GO 
GRANT INSERT, UPDATE, DELETE 
ON authors 
TO Mary, John, Tom 
GO



C. SQL Server ロールへの権限の付与


この例では、Accounting ロールのすべてのメンバに CREATE TABLE および ALTER SCHEMA の権限が与えられます。 新たなテーブルを作成するには、権限を与えられるユーザーに ALTER SCHEMA と CREATE TABLE の両方の権限がなければなりません。


GRANT CREATE TABLE TO Accounting 
GRANT ALTER ON SCHEMA :: AccountingSchema TO Accounting



D. AS オプションを使用した権限の付与


Plan_Data テーブルは Jean というユーザーが所有しています。 Jean は WITH GRANT OPTION 節を指定し、Accounting ロールに Plan_Data の SELECT 権限を付与します。 Accounting のメンバである Jill は、Accounting のメンバではない Jack に Plan_Data テーブルの SELECT 権限を与えたいと考えています。


他のユーザーの SELECT 権限を Plan_Data テーブルに付与するための権限は、明示的に Jill ではなく Accounting ロールに与えられているため、Jill は Accounting ロールのメンバであることによって与えられる権限を基にテーブルの権限を与えることはできません。 Accounting ロールの権限の付与を肩代わりするには、Jill は AS 節を使用しなければなりません。


/* ユーザー Jean */ 
GRANT SELECT ON Plan_Data TO Accounting WITH GRANT OPTION 
/* ユーザー Jill */ 
GRANT SELECT ON Plan_Data TO Jack AS Accounting



E. HTTP エンドポイント権限の付与


この例では、Jean に CREATE HTTP ENDPOINT 権限を与えます。 後に、Jean は、Izabella が、以前、自身で作成したエンドポイントに接続できるようにします。


USE master 
GO 
GRANT CREATE HTTP ENDPOINT TO JeansLogin 
GO 
/* ユーザー Jean、HTTP ENDPOINT accouting_ep 作成後 */ 
GRANT CONNECT ON HTTP ENDPOINT :: accounting_ep to IzabellasLogin 
GO



F. オブジェクト権限の付与


この例では、Izabella および Sophie に VIEW_DEFINITION が付与されます。 これにより、この二人はアカウンティング データベースのカタログ セキュリティ ルールから実質的に除外され、すべてのメタデータを見ることが可能となります。 次に、Alexander に AccountSchema スキーマの VIEW_DEFINITION が与えられます。 これにより、Alexander は AccountsSchema のあらゆる事柄に関するカタログ セキュリティ ルールから実質的に除外されます。


USE TheAccountingDB 
GO 
GRANT VIEW_DEFINITION TO Izabella, Sophie 
GO 
GRANT VIEW_DEFINITION ON SCHEMA :: AccountsSchema TO Alexander 
GO



G. オブジェクト権限の付与


この例では、選択 (SELECT) 可能なアカウント スキーマのオブジェクトの SELECT 権限が Mariza に付与されます。


GRANT SELECT ON SCHEMA :: accounts TO Mariza 
GO



H. アセンブリ権限の付与


この例では、AccountingAssembly というアセンブリの権限を Izabella に付与します。


GRANT EXECUTE, REFERENCES ON ASSEMBLY :: AccountingAssembly TO Izabella 
GO



I. タイプ権限の付与


この例では、AccountingCurrency というスカラ タイプの完全なコントロールを Izabella に付与します。


GRANT CONTROL ON TYPE :: AccountingCurrency TO Izabella 
GO



J. サーバー権限の付与


この例では、SQL Server 2005 のインスタンスの完全なコントロールが Izabella に付与され、Izabella は実質的に sa となります。 次に、Alexander がリンクされたあらゆるサーバーを変更したり、あらゆる種類のイベントを追跡および監査したりできるようにします。


USE master 
GO 
GRANT CONTROL SERVER to IzabellasLogin 
GO 
GRANT ALTER ANY LINKED SERVER, ALTER ANY EVENT TO AlexandersLogin 
GO



K. フルテキストカタログ権限の付与


この例では、Kim にフルテキスト カタログの完全なコントロールが付与されます。


GRANT CONTROL ON FULLTEXT CATALOG :: AccountsFullTextCatalog TO Kim 
GO



L. サービスブローカー権限の付与


この例では、Izabella が送信サービスで送信したり、AccountsSchema の受信キューから受信したりできるようにします。


GRANT SEND ON SERVICE :: AccountingOutboundService TO Izabella 
GO 
GRANT RECEIVE ON AccountsSchema.AccountingInboundQueue TO Izabella 
GO



M. サーバープリンシパル権限の付与


この例では、Lilith がログイン レベルで Alexander を偽装できるようにします。


USE master 
GO 
GRANT IMPERSONATE ON LOGIN :: AlexandersLogin TO LilithsLogin 
GO



N. データベースプリンシパル権限の付与


この例では、Lilith がデータベースのユーザー レベルで Alexander を偽装できるようにします。


USE TheAccountingDB 
GO 
GRANT IMPERSONATE ON USER :: Alexander TO Lilith 
GO



SQL-CLR セキュリティ


Microsoft SQL Server 2005 は、.NET 共通言語ランタイムをホストし、プログラム化可能な以下の拡張をサーバーに提供します。


    

  • 任意の .NET 言語で書かれたルーチン (ストアド プロシージャ、関数、およびトリガ)
    

    • 

  • 任意の .NET 言語で書かれたユーザー定義型 (UDT) および集計 (UDAggs)
    

    • 



TSQL ルーチンが CLR ルーチンまたは SQL Server データベースのデータオブジェクトにアクセスしようとするか、あるいは CLR ルーチンが TSQL ルーチンまたは SQL Server データベースのデータオブジェクトにアクセスしようとする際は、認識すべきセキュリティ上の問題がさらに加わります。 ユーザー認証および許可に基づく SQL Server セキュリティ モデルと、コード アクセス セキュリティ モデルに基づく CLR セキュリティ モデルとの相互作用の詳細については、本書では扱いません。 詳細は Books Online を参照してください。


プログラム可能なモジュールの実行コンテキスト


この Microsoft SQL Server 2005 のプレビュー版では、以下のユーザー定義ルーチンの実行コンテキストを定義する能力が取り入れられています。


    

  • ストアド プロシージャ
    

    • 

  • ユーザー定義関数 (インライン テーブル値関数を除く)
    

    • 



ルーチンが実行されるコンテキストを指定することによって、そのルーチンで参照されるデータベース オブジェクトの権限を確認するために SQL Server が使用するユーザー アカウントを規制することができます。 これにより、ユーザー定義ルーチンとそれらのルーチンで参照されるオブジェクトの間に存在する、オブジェクト チェーン全体に渡るアクセス権の管理に、さらなる柔軟性と統制が実現されます。 権限は、参照されるオブジェクトの権限を明示的に与えることなく、ルーチン自体のユーザーにのみ与える必要があります。 ルーチンでアクセスされるオブジェクトの権限を得る必要があるのは、そのルーチンを実行しているユーザーだけです。


SQL Server の以前のバージョンでは、参照されるすべてのオブジェクトへのアクセスを呼び出し側のユーザーに付与しなければならない事態を回避するのに利用できる唯一の方法は所有権のチェイニングでした。 EXECUTE AS 節で指定されたユーザーの権限は、参照されるオブジェクトに関し、引き続き SQL Server によって判定されます。 所有権のチェイニングに関する詳細は、Books Online の所有権チェイニングの説明を参照してください。


所有権のチェイニングには以下の制限があります。


    

  • 所有権のチェイニングが適用されるのは DML ステートメント (SELECT、INSERT、UPDATE、および DELETE) のみです。
    

    • 

  • 呼び出す側と呼び出される側のオブジェクトの所有者は同一でなければなりません。
    

    • 

  • 所有権チェイニングのルールは動的 SQL には適用されません。
    

    • 



所有権チェイニングのルールは、ルーチンに指定された実行コンテキストに関わらず、引き続き適用されます。


指定された実行コンテキストを含む、ルーチンの定義を表示するには、sys.sql_modules カタログ ビューを使用してください。


EXECUTE AS オプション


このプレビュー版のリリースでは、EXECUTE AS に以下のオプションがあります。


    

  • CALLER (既定)
    

    • 

  • SELF
    

    • 

  • USER = user_name
    

    • 



EXECUTE AS CALLER


EXECUTE AS CALLER を指定すると、ルーチン内のステートメントは、ルーチンの呼び出し側のコンテキストで実行されます。 従って、ルーチンを実行するユーザーには、ルーチンそれ自体だけでなく、そのルーチンで参照されるあらゆるデータベース オブジェクトの適切な権限がなければなりません。 SQL Server が参照されるオブジェクトの権限を判定する方法は、呼び出す側のオブジェクトと参照されるオブジェクトの間に存在する所有権チェーンによって異なります。


シナリオ 1: 切れ目のない所有権チェーン


切れ目のない所有権チェーンとは、呼び出し側のオブジェクトの所有者が、参照されるすべてのオブジェクトの所有者でもあるようなチェーンです。 たとえば、Mary は、自身が所有するテーブルを参照するストアド プロシージャを作成します。


CREATE PROCEDURE AccessMyTable 
WITH EXECUTE AS CALLER 
AS SELECT * FROM MyTable



Mary は Scott という別のユーザーにストアド プロシージャの実行権限を与えています。 Scott がこのストアド プロシージャを実行する際、SQL Server は、Scott (呼び出し側) にそのストアド プロシージャを実行するための権限があるかどうかを確認します。 Scott にはストアド プロシージャの権限があり、ストアド プロシージャおよび参照されるデータの所有者は同じであることから、これ以上権限のチェックは行われず、ステートメントは成功します。 つまり、Scott にストアド プロシージャの権限を与えた際、Mary は参照されるテーブル (同じく Mary が所有) の権限も与えたわけです。


シナリオ 2: 途切れている所有権チェーン


Mary は、自身の所有ではないものの、SELECT 権限を有するテーブルを参照するストアド プロシージャを作成します。


CREATE PROCEDURE AccessTable1 
WITH EXECUTE AS CALLER 
AS SELECT * FROM John.Table1



Mary は Scott にストアド プロシージャの実行権限を与えています。 Scott がこのストアド プロシージャを実行する際、SQL Server は、Scott (呼び出し側) にそのストアド プロシージャを実行するための権限があるかどうかを確認します。 Scott は実行の権限を持っていますが、Mary は参照されるテーブルの所有者ではないので、SQL Server は Scott にそのテーブルへの権限があるかどうかをチェックします。 Scott に権限がなければ、ストアド プロシージャのステートメントはエラーとなります。


EXECUTE AS CALLER は既定 (下位互換) の動作です。


EXECUTE AS USER = user_name


EXECUTE AS USER = user_name を指定すると、ルーチンは、user_name で指定されたユーザーのコンテキストで実行されます。 ルーチンが実行される際、SQL Server はまずルーチンを実行するユーザーにそのルーチンを実行権限があることを確認しますが、ルーチン内のあらゆるステートメントの権限は user_name と照らし合わされます。 ただし、さらなる権限のチェックは所有権チェイニング ルールの対象となることにも注意してください。


ユーザー名を指定するためには、以下のとおりでなければなりません。


    

  • sysadmin 固定サーバー ロールまたは db_owner 固定データベース ロールのメンバであること、あるいは
    

    • 

  • サーバーの CONTROL SERVER 権限があること、あるいは
    

    • 

  • データベースの CONTROL 権限があること、あるいは
    

    • 

  • user_name に対応するログインの偽装権限があること。
    

    • 



自身を偽装することは常に可能です。 実行コンテキストのユーザー ID はメタデータに保存され、sys.sql_modules カタログ ビューで見ることができます。


注意 このプレビュー版のリリースでは、実行コンテキストのスコープが SQL Server のインスタンス全体にわたって有効となっています。 従って、特定のコンテキストでルーチンを実行し、そのルーチンがデータベースのスコープの外で動作するように指定して、指定された実行コンテキストのログイン レベルで偽装権限が必要となるようにすることができます。 これは不完全な機能の実装であり、完全な実装では、偽装のスコープが既定でデータベースに限られ、そのスコープは他のセキュリティ制限に基づき、選択的にデータベース以外に広げられます。


シナリオ


Mary は、自身の所有ではないものの、SELECT 権限を有するテーブルを参照するストアド プロシージャを作成します。 Mary は、次の例に示されるとおり、CREATE PROCEDURE ステートメント内で EXECUTE AS USER = Mary と指定しています。


CREATE PROCEDURE AccessMyTable 
WITH EXECUTE AS USER = Mary 
AS SELECT * FROM MyTable



Mary は Scott という別のユーザーにストアド プロシージャの実行権限を与えています。 Scott がこのストアド プロシージャを実行する際、SQL Server は、Scott (呼び出し側) にそのストアド プロシージャを実行するための権限があるかどうかを確認しますが、参照されるテーブルの権限は Mary に対してチェックされます。 このシナリオでは、Scott は直接的にテーブルの SELECT 権限を持っていませんが、プロシージャは Mary のコンテキストで実行され、Mary にはプロシージャへのアクセスがあるため、Scott はそのプロシージャを通じてデータにアクセスできます。


EXECUTE AS SELF


EXECUTE AS SELF は、ルーチンのステートメントを実行させるコンテキストとして自身を指定するための、(ルーチンを作成または変更する) 現在のユーザーへのショートカットです。 EXECUTE AS SELF は、指定されたユーザーがルーチンを作成または変更する人物となる EXECUTE AS USER = user_name に相当します。 カタログには、SELF という値ではなく、その人物の実際のユーザー ID が保存されます。


EXECUTE AS Options 選択のガイドライン


以下の場合は EXECUTE AS CALLER を使用します。


    

  • 呼び出し側のユーザーとしてルーチンのステートメントを実行したい場合。
    

    • 

  • 呼び出し側のユーザーに対して権限の基本的なチェックを行い、所有権のチェイニングによってのみ基礎的なオブジェクトの権限の確認が回避されるようにしたい場合。 所有権のチェイニングは、DML ステートメントのみに適用されることを忘れないようにしてください。
    

    • 

  • 参照される基礎的なオブジェクトをユーザーから隠す必要がアプリケーションにない場合。 あるいは、所有権が同一のオブジェクトのみを参照し、従って所有権チェーンによってスキーマを隠すことができる場合。
    

    • 



以下の場合は EXECUTE AS USER = user_name を使用します。


    

  • 指定されたユーザーのコンテキストでルーチンのステートメントを実行したい場合。
    

    • 

  • 基礎的なスキーマを隠すのに所有権チェイニング (たとえば、ルーチンは所有権の異なるオブジェクトにアクセスします) を使用できず、参照されるオブジェクトの権限を付与することを避けたい場合。
    

    • 

  • カスタムの権限一式を作成したい場合。 たとえば、通常は特別な権限を付与することのできない DDL 操作の権限を提供するため。 この後に続く「カスタム 権限の作成」のシナリオを参照してください。
    

    • 



以下の場合は EXECUTE AS SELF を使用します。


    

  • 作成または変更するルーチンのステートメントを実行するコンテキストのユーザーとして自身を指定するショートカットが必要な場合。
    

    • 

  • 呼び出し側のユーザーにルーチンを作成するアプリケーションがあり、それらのユーザーに実行コンテキストでルーチンを作成したい場合。 このシナリオでは、設計時、呼び出し側のユーザーの名前は分かりません。
    

    • 



シナリオ : カスタム権限の作成


一部の操作は、TRUNCATE TABLE などのように付与することが不可能な権限です。 TRUNCATE TABLE を実行するには、ユーザーにそのテーブルの ALTER 権限がなければなりません。 ALTER TABLE 権限についての詳細は、Books Online を参照してください。


ユーザーには実質的にテーブルの切り詰めをはるかに超えた権限が与えられることになるので、これらの権限の 1 つをユーザーに与えることは望ましくない場合があります。 TRUNCATE TABLE ステートメントをルーチンに組み入れ、EXECUTE AS SELF 節を指定することで、自身の権限をテーブル所有者からルーチンの EXECUTE 権限を付与するユーザーにまで拡張し、なおかつルーチン内で参照するオブジェクトへのユーザーの権限を制限することができます。


次のストアド プロシージャを考えてみましょう。


CREATE PROCEDURE TruncateMyTable 
WITH EXECUTE AS SELF 
AS TRUNCATE TABLE MyDB..MyTable



Mary がこのプロシージャを作成し、TruncateMyTable の実行権限を Scott に与えるとします。 Scott がこのストアド プロシージャを実行すると、SQL Server はあたかも Mary 自身がそのストアド プロシージャを実行しているかのように、テーブルを切り詰めるための権限を確認します。 Mary はテーブルの所有者であることから、このステートメントは、Scott にテーブルそれ自体の直接的な権限がなくとも成功します。 Mary は、このタスクを行うのに必要な権限を超える権限を与えることなく、迅速かつ能率的に希望どおり Scott にまで権限を拡張しています。


まとめ


SQL Server 2005 のリレーショナル エンジンでは、日常的な作業を簡略化しつつ、管理者や開発者により強力な機密データへのアクセス管理を提供する、大幅に改良されたセキュリティ アーキテクチャが採用されています。 これらの変更は、前のバージョンの弱点に対処するとともに、顧客から求められた性能を提供します。


関連情報 :


https://www.microsoft.com/japan/sql/


著作権および免責条項


このドキュメントで説明されている機能と計画は、SQL Server の次のバージョンの現在の方向性を示しています。 これらの機能と計画はこの製品の仕様ではなく、また、変更されることもあります。 黙示されているかどうかにかかわらず、これらの機能が最終の製品リリースに含まれる保証はありません。


このドキュメントでは、いくつかの機能について、読者が SQL Server 2000 の機能とサービスに精通していることを前提にしています。 SQL Server の機能とサービスに関する基礎的な情報については、公式の製品 Web サイト https://www.microsoft.com/japan/sql/、または Microsoft Press から入手可能な SQL Server 2000 リソース キットを参照してください。


免責条項


このドキュメントは製品仕様ではありません。


本書に記載された情報は、本書各項目に関する発行日現在の Microsoft の見解を表明するものです。 Microsoftは絶えず変化する市場に対応しなければならないため、ここに記載した情報に対していかなる責務を負うものではなく、情報の信憑性については保証できません。 本書は情報提供のみを目的としています。 Microsoft は、明示的または暗示的を問わず、本書にいかなる保証も与えるものではありません。


このドキュメントは、最終版ドキュメントの初期リリースであり、その内容は製品リリース前に大幅に変更される場合があります。これは Microsoft Corporation が所有する機密情報です。 受取人と Microsoft の間で結ばれた機密保持契約に従って開示されます。 本書の情報は、URL や他のインターネット Web サイト参照を含めて、予告なく変更されることがあります。 このドキュメントの使用に伴うリスクや結果は全て、使用するユーザーの責任となります。 特に断りのない限り、本書に例示したすべての会社、組織、製品、ドメイン名、電子メール アドレス、ロゴ、人物、場所、およびイベントは架空のもので、実在の会社、組織、製品、ドメイン名、電子メール アドレス、ロゴ、人物、場所、あるいはイベントとは一切無関係です。 すべての当該著作権法を遵守することはユーザーの責務です。 Microsoftの書面による明示的な許可なく、本書の一部または全部について、転載や検索システムへの格納または挿入を行うことは、どのような形式または手段（電子的、機械的、複写、レコーディング、その他）、および目的を問わず、禁じられています。これらは著作権保護された権利を制限するものではありません。


Microsoft Corporation は、本書の内容を保護する特許または特許申請中のアプリケーション、商標、著作権、またはその他の知的所有権を保有している場合があります。 Microsoft から書面による明示的な使用許諾契約書が供給される場合を除き、本書の提供はこれらの特許、商標、著作権、またはその他の知的財産へのライセンスを与えるものではありません。


Microsoft は、このドキュメントで言及された仕様、およびこれらの仕様に基づいて開発されたすべての製品または品目に関する一切の説明および保証を行いません。 Microsoft は、商品性の保証や特定目的の適合性、侵害からの免除などに限らず、明示的または暗示的ないかなる保証も与えるものではありません。 上述の一般原則を制限することなく、Microsoft はこれらの仕様またはその任意の一部に基づいて開発されたあらゆる種類のあらゆる品目に対して一切の保証を行いません。また、あらゆる著作権、特許、企業秘密、その他あらゆる国家のいずれの個人または企業体の知的所有権を侵害することはありません。 適切な場合において、そうした知的所有権のライセンスを求めることはその方自身の責任です。 Microsoft は、利益損失、事業の中断、その他任意の損害などを含め、これらの仕様の利用に起因または関連するいかなる損害についても一切責任を負いません。 州によっては、重大または付随的な損害に対する責任の排除または制限を許していないところがあり、上記の内容は該当しないことがあります。


Active Directory、ClearType、Direct3D、DirectDraw、DirectInput、DirectMusic、DirectShow、DirectSound、DirectX、DirectVA、Exchange、IntelliMirror、Internet Explorer、Microsoft、Microsoft Word、MS-DOS、NetMeeting、Office、Office XP、Paint、SharePoint、SQL Server、Visual Basic、Win32、Win64、Windows、Windows 95、Windows 98、Windows Millennium Edition、Windows 2000、Windows NT、Windows XP、および Windows .NET Server ファミリ (Windows .NET Standard Server、Windows .NET Enterrpise Server、Windows .NET Datacenter Server、Windows .NET Web Server) は米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。 その他、記載されている会社名および製品名は、各社の商標または登録商標です。


© 2003 Microsoft Corporation. All rights reserved.