メタデータ表示の構成

適用対象: SQL Server Azure SQL データベース Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW)

メタデータの表示は、ユーザーが所有するセキュリティ保護可能なリソース、またはそのユーザーが権限を許可されているセキュリティ保護可能なリソースに制限されています。

たとえば、次のクエリを実行すると、ユーザーがテーブル myTableに対する SELECT または INSERT 権限を許可されている場合は、1 行が返されます。

SELECT name, object_id  
FROM sys.tables  
WHERE name = N'myTable';  
GO  

ただし、ユーザーが myTableでの権限を許可されていない場合は、空の結果セットが返されます。

メタデータ表示の構成のスコープと影響

メタデータ表示の構成は、次のセキュリティ保護可能なメタデータにのみ適用されます。

メタデータ表示の構成は、次のセキュリティ保護可能なメタデータには適用されません。

メタデータへのアクセスを制限すると、次のような影響があります。

• システム ビューへのクエリを実行しても、行のサブセットまたは空の結果セットしか返されないことがあります。

• OBJECTPROPERTYEX などのメタデータ生成組み込み関数を実行すると、NULL が返されることがあります。

• データベース エンジン sp_help ストアド プロシージャを実行しても、行または NULL のサブセットしか返されないことがあります。

• その場合、メタデータへのパブリックなアクセスを前提とするアプリケーションは機能しません。

ストアド プロシージャやトリガーなどの SQL モジュールは、呼び出し元のセキュリティ コンテキストで実行されるので、メタデータへのアクセスが制限されます。 たとえば次のコードでは、ストアド プロシージャから、呼び出し元に権限のないテーブル myTable のメタデータへのアクセスが試行されると、空の結果セットが返されます。 以前のリリースの SQL Server では行が返されます。

CREATE PROCEDURE assumes_caller_can_access_metadata  
BEGIN  
SELECT name, object_id   
FROM sys.objects   
WHERE name = N'myTable';  
END;  
GO  

呼び出し元でのメタデータの表示を可能にするには、呼び出し元に VIEW DEFINITION アクセス許可を付与するか、または SQL Server 2022 以降では、適切なスコープ (オブジェクト レベル、データベース レベルまたはサーバー レベル) で VIEW SECUIRITY DEFINITION または VIEW PERFORMANCE DEFINITION を付与します。 したがって、上記の例では、呼び出し元に myTableに対する VIEW DEFINITION 権限が許可されていると、ストアド プロシージャから行が返されます。 詳細については、「GRANT (Transact-SQL)」と「GRANT (データベースのアクセス許可) (Transact-SQL)」を参照してください。

また、ストアド プロシージャを所有者の資格情報で実行するように変更することもできます。 プロシージャの所有者とテーブルの所有者が同じ場合は、所有権の継承が適用されます。したがって、プロシージャの所有者のセキュリティ コンテキストにより、 myTableのメタデータにアクセスできます。 このシナリオで次のコードを実行すると、メタデータの行が呼び出し元に返されます。

CREATE PROCEDURE does_not_assume_caller_can_access_metadata  
WITH EXECUTE AS OWNER  
AS  
BEGIN  
SELECT name, object_id  
FROM sys.objects   
WHERE name = N'myTable'   
END;  
GO  

メタデータ表示構成の利点と制限事項

メタデータ表示の構成は、セキュリティ計画全体にとって重要な役割を果たします。 ただし、上級ユーザーや事前に指定されたユーザーが一部のメタデータを強制的に公開できる場合もあります。 メタデータの権限の配置は、数ある堅牢な防御策の 1 つとして行うことをお勧めします。

理論上は、クエリで述語の評価の順序を操作することで、エラー メッセージ内にメタデータの生成を強制することも可能です。 このような試行錯誤による攻撃の可能性は、SQL Server に固有のものではありません。 関係代数で許可されている結合変換および相互変換に伴う場合もあります。 このリスクは、エラー メッセージで返される情報を制限することで緩和できます。 この方法でメタデータの表示を制限するには、トレース フラグ 3625 を使用してサーバーを起動します。 このトレース フラグは、エラー メッセージで表示される情報の量を制限します。 そのため、この方法を使用することで、メタデータの公開が強制されることを防ぐことができます。 その代わりに、エラー メッセージは簡潔になり、デバッグに使用するのは困難になる可能性があります。 詳細については、「データベース エンジン サービスのスタートアップ オプション」と「トレース フラグ (Transact-SQL)」を参照してください。

次のメタデータは公開を強制されません。

• sys.servers の provider_string 列に格納された値。 ALTER ANY LINKED SERVER 権限が許可されていないユーザーには、この列に NULL 値が表示されます。

• ストアド プロシージャやトリガーなどのユーザー定義オブジェクトのソース定義。 ソース コードは、次のいずれかの条件を満たしている場合のみ表示されます。

  • ユーザーがオブジェクトに対する VIEW DEFINITION 権限を許可されている場合。

  • ユーザーがオブジェクトに対する VIEW DEFINITION 権限を拒否されていなくて、そのオブジェクトに対する CONTROL、ALTER、TAKE OWNERSHIP のいずれかの権限を許可されている場合。 他のすべてのユーザーには NULL が表示されます。

• 次のカタログ ビューの定義列。

  • sys.all_sql_modules
  • sys.server_sql_modules
  • sys.default_constraints
  • sys.numbered_procedures
  • sys.sql_modules
  • sys.check_constraints
  • sys.computed_columns

• ctext 互換表示の syscomments 列。

• sp_helptext プロシージャの出力。

• 情報スキーマ ビューの次の列。

  • INFORMATION_SCHEMA.CHECK_CONSTRAINTS.CHECK_CLAUSE
  • INFORMATION_SCHEMA.DOMAINS.DOMAIN_DEFAULT
  • INFORMATION_SCHEMA.ROUTINES.ROUTINE_DEFINITION
  • INFORMATION_SCHEMA.COLUMNS.COLUMN_DEFAULT
  • INFORMATION_SCHEMA.ROUTINE_COLUMNS.COLUMN_DEFAULT
  • INFORMATION_SCHEMA.VIEWS.VIEW_DEFINITION

• OBJECT_DEFINITION() 関数

• sys.sql_logins の password_hash 列に格納された値。 CONTROL SERVER を持たないユーザー (または SQL Server 2022 以降では、VIEW ANY CRYPTOGRAPHICALLY SECURED DEFINITION 権限) には、この列に NULL 値が表示されます。

メタデータ表示の一般原則

次に、メタデータの表示に関して考慮する必要がある一般原則を示します。

• 固定ロールの暗黙の権限

• 権限のスコープ

• DENY の優先

• サブコンポーネントのメタデータの表示

固定ロールと暗黙の権限

固定ロールでアクセスできるメタデータは、それらのメタデータに対応する暗黙の権限によって決まります。

権限のスコープ

あるスコープで権限が許可されていると、そのスコープのメタデータと、そのスコープに含まれるすべてのスコープのメタデータを表示できることになります。 たとえば、あるスキーマに対する SELECT 権限が許可されると、そのスキーマに含まれるすべてのセキュリティ保護可能なメタデータに対する SELECT 権限がユーザーに許可されることになります。 したがって、あるスキーマに対する SELECT 権限を許可すると、ユーザーはそのスキーマと、スキーマ内のすべてのテーブル、ビュー、関数、プロシージャ、キュー、シノニム、型、および XML スキーマ コレクションのメタデータも表示できます。 スコープの詳細については、「権限の階層 (データベース エンジン)」を参照してください。

DENY の優先

通常、DENY は他の権限よりも優先されます。 たとえば、データベース ユーザーがあるスキーマに対する EXECUTE 権限を許可されていても、そのスキーマ内にあるストアド プロシージャに対する EXECUTE 権限が拒否されている場合は、ユーザーはそのストアド プロシージャのメタデータを表示できません。

また、ユーザーがあるスキーマに対する EXECUTE 権限を拒否されている場合は、そのスキーマ内のストアド プロシージャに対して EXECUTE 権限を許可されていても、ユーザーはそのストアド プロシージャのメタデータを表示できません。

もう 1 つの例として、ユーザーがあるストアド プロシージャに対する EXECUTE 権限を許可および拒否されている場合 (さまざまなロールのメンバーシップに属しているとこのような状況が生じます)、DENY が優先されるので、ユーザーはそのストアド プロシージャのメタデータを表示できません。

サブコンポーネントのメタデータの表示

インデックス、CHECK 制約、トリガーなどのサブコンポーネントが表示されるかどうかは、そのサブコンポーネントの親に対する権限によって決まります。 これらのサブコンポーネントには、権限を許可できません。 たとえば、ユーザーがあるテーブルに対していくつかの権限を許可されていると、そのテーブル、列、インデックス、CHECK 制約、トリガー、およびその他のサブコンポーネントのメタデータを表示できます。 もう 1 つの例は、特定のテーブルの単一の列に対してのみ SELECT を許可する場合です。これにより、被付与者はテーブル全体 (すべての列を含む) のメタデータを表示できます。 VIEW DEFINITION 権限はエンティティ レベル (この場合はテーブル) に対してのみ機能し、サブエンティティ リスト (列やセキュリティの式など) では使用できないと考えることができます。

次のコードはこの動作を示しています。

CREATE TABLE t1
(
    c1 int,
    c2 varchar
 );
GO
CREATE USER testUser WITHOUT LOGIN;
GO

EXECUTE AS USER='testUser';
SELECT OBJECT_SCHEMA_NAME(object_id), OBJECT_NAME(object_id), name FROM sys.columns;
SELECT * FROM sys.tables
-- this returns no data, as the user has no permissions
REVERT;
GO

-- granting SELECT on only 1 column of the table:
GRANT SELECT ON t1(c1) TO testUser;
GO
EXECUTE AS USER='testUser';
SELECT OBJECT_SCHEMA_NAME(object_id), OBJECT_NAME(object_id), name FROM sys.columns;
SELECT * FROM sys.tables
-- this returns metadata for all columns of the table and thge table itself
REVERT;
GO

DROP TABLE t1
DROP USER testUser

すべてのデータベース ユーザーがアクセスできるメタデータ

一部のメタデータは、特定のデータベースのすべてのユーザーがアクセスできる必要があります。 たとえば、ファイル グループには許可できる権限がないので、ファイル グループのメタデータを表示するための権限をユーザーに許可できません。 ただし、テーブルを作成できるすべてのユーザーは、ファイル グループのメタデータにアクセスして、CREATE TABLE ステートメントの ON filegroup 句または TEXTIMAGE_ON filegroup 句を使用できる必要があります。

DB_ID() 関数と DB_NAME() 関数で返されるメタデータは、すべてのユーザーが表示できます。

これは public ロールで表示できるカタログ ビューの一覧です。

参照

GRANT (Transact-SQL)
DENY (Transact-SQL)
REVOKE (Transact-SQL)
EXECUTE AS 句 (Transact-SQL)
カタログ ビュー (Transact-SQL)
互換表示 (Transact-SQL)