SQL Server 2016の行レベルセキュリティ（RLS）とは？仕組みと実装方法をわかりやすく解説

Microsoft®はSQL Server®においてセキュリティに力を入れており、ほぼすべてのリリースで既存機能の強化や新たなセキュリティ機能が導入されてきました。SQL Server 2016では、データ保護に役立つ多くの新しいセキュリティ機能が登場しました。代表的なものとして、行レベルセキュリティ（Row-Level Security：RLS）、Always Encrypted、動的データマスキング（Dynamic Data Masking）が挙げられます。

はじめに

前回の記事では、SQL Server 2016の動的データマスキングについてご紹介しました。本記事では、テーブル内のどの行（レコード）にどのユーザーがアクセスできるかを制御できる「行レベルセキュリティ（RLS）」機能について解説します。

RLSを利用すると、クエリを実行するユーザーの属性に基づいて、データへのアクセス制限を実装できます。異なるユーザーに対して完全に透過的な形で、データアクセスを簡単に制御できるのが大きな特徴です。

RLSが必要とされる理由

特定のユーザーにのみ選択したデータを返したいケースは多々あります。従来は、ビューを作成し、そのビューに対してユーザーにSELECT権限を付与する方法が一般的でした。しかし、データ量やユーザー数が増加するにつれて、必要なビューの数が膨大になり、管理しきれなくなるという課題がありました。

こうした状況下でのセキュリティ要件に応えるため、MicrosoftはRLSを導入しました。RLSにより、テーブルの行単位できめ細かなアクセス制御が可能となり、アプリケーション側に変更を加えることなく、どのユーザーがどのデータにアクセスできるかを容易に制御できます。

この機能では、現在のユーザーのアクセス権限ではなく、クエリの実行コンテキストに基づいて行がフィルタリングされます。柔軟かつ堅牢なセキュリティポリシーをテーブルに対して設計することで、どのユーザーにどの行を見せるかを決定する安全なロジックルールを作成し、任意の行やデータへのアクセスを制限できます。

画像出典： https://sqlwithmanoj.com/2015/07/13/implementing-row-level-security-rls-with-sql-server-2016/

RLSの主な特徴

RLSには以下のような特徴があります。

• きめ細かなアクセス制御：特定の行に対する読み取り・書き込みの両方を制御可能
• アプリケーションの透過性：アプリケーション側の変更は不要
• アクセス制御の一元化：データベース内でアクセスロジックを集中管理
• 導入と保守が容易

RLSの仕組み

RLSを実装するには、以下の3つの要素を理解しておく必要があります。

• 述語関数（Predicate Function）
• セキュリティ述語（Security Predicates）
• セキュリティポリシー（Security Policy）

以下、それぞれの項目について詳しく見ていきます。

述語関数（Predicate Function）

述語関数とは、インラインテーブル値関数の一種で、クエリを実行しているユーザーがその定義済みロジックに基づいてデータへアクセスできるかどうかを判定します。ユーザーがアクセスを許可されている各行に対して、この関数は1を返します。

セキュリティ述語（Security Predicates）

セキュリティ述語は、述語関数をテーブルにバインド（紐付け）する役割を担います。RLSでは2種類のセキュリティ述語がサポートされています。「フィルター述語」と「ブロック述語」です。

フィルター述語は、述語関数で定義されたロジックに従い、エラーを発生させることなくデータをサイレントにフィルタリングします。対象となる操作は以下の通りです。

• SELECT
• UPDATE
• DELETE

一方、ブロック述語は、述語関数のロジックに違反するデータに対して以下の操作を行おうとした際に、明示的にエラーを発生させてユーザーの操作をブロックします。

• AFTER INSERT
• AFTER UPDATE
• BEFORE UPDATE
• BEFORE DELETE

セキュリティポリシー（Security Policy）

セキュリティポリシーオブジェクトは、RLSのために作成され、述語関数を参照するすべてのセキュリティ述語をグループ化します。

RLSの活用シーン

RLSの設計例として、以下のような活用シーンが考えられます。

• 病院：看護師が自分の担当患者のデータ行のみを閲覧できるようセキュリティポリシーを構成する
• 銀行：従業員の事業部門や役割に基づいて、財務データ行へのアクセスを制限するポリシーを設ける
• マルチテナントアプリケーション：各テナントのデータ行を他テナントから論理的に分離するポリシーを適用する。多数のテナントのデータが1つのテーブルに格納されるため処理効率が高く、各テナントは自分のデータ行のみを参照できる

RLSの実装手順

ここからは、実際にRLSを実装する手順を紹介します。

ステップ1：データベースとテスト用ユーザーの作成

まず、以下のコードを実行して、データベースRowFilterとテスト用の2人のユーザーを作成します。

CREATE DATABASE RowFilter;
GO
USE RowFilter;
GO
CREATE USER userBrian WITHOUT LOGIN;
CREATE USER userJames WITHOUT LOGIN;
GO

ステップ2：サンプルテーブルの作成と権限付与

次に、サンプルデータを含むテーブルを作成し、新規ユーザーにSELECT権限を付与します。

CREATE TABLE dbo.SalesFigures (
[userCode] NVARCHAR(10),
[sales] MONEY)
GO
INSERT  INTO dbo.SalesFigures
VALUES ('userBrian',100), ('userJames',250), ('userBrian',350)
GO
GRANT SELECT ON dbo.SalesFigures TO userBrian
GRANT SELECT ON dbo.SalesFigures TO userJames
GO

ステップ3：フィルター述語関数の追加

続いて、フィルター述語関数を追加します。

CREATE FUNCTION dbo.rowLevelPredicate (@userCode as sysname)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS rowLevelPredicateResult
WHERE @userCode = USER_NAME();
GO

ステップ4：テーブルへのフィルター述語の追加

テーブルdbo.SalesFiguresにフィルター述語を追加します。

CREATE SECURITY POLICY UserFilter
ADD FILTER PREDICATE dbo.rowLevelPredicate(userCode)
ON dbo.SalesFigures
WITH (STATE = ON);
GO

ステップ5：結果の確認

最後に、ステップ2で追加したユーザーを使って結果を確認します。

EXECUTE AS USER = 'userBrian';
SELECT * FROM dbo.SalesFigures;
REVERT;
GO

このコードを実行すると、userBrianに許可された2行が返されます。

続いて、userJamesで実行してみます。

EXECUTE AS USER = 'userJames';
SELECT * FROM dbo.SalesFigures;
REVERT;
GO

このコードを実行すると、userJamesに許可された1行のみが返されます。

必要な権限

セキュリティポリシーの作成・変更・削除には、ALTER ANY SECURITY POLICY権限が必要です。

また、セキュリティポリシーの作成や削除には、スキーマに対するALTER権限も必要です。

さらに、各述語を追加するには、以下の権限が必要となります。

• 述語として使用される関数に対するSELECT権限およびREFERENCES権限
• ポリシーにバインドされる対象テーブルに対するREFERENCES権限
• 引数として使用される対象テーブルの各列に対するREFERENCES権限

セキュリティポリシーは、データベース所有者（DBO）を含むすべてのユーザーに適用されます。DBOユーザーはセキュリティポリシーを変更または削除できますが、その変更内容は監査される可能性があります。sysadminやdb_ownerといった高権限ユーザーがトラブルシューティングやデータ検証のために全行を参照する必要がある場合は、それを許可するようにセキュリティポリシーを記述する必要があります。

セキュリティポリシーがSCHEMABINDING = OFFで作成された場合、ユーザーが対象テーブルを照会するには、述語関数、およびその内部で使用される追加のテーブル・ビュー・関数に対するSELECTまたはEXECUTE権限が必要です。一方、デフォルトであるSCHEMABINDING = ONで作成された場合、ユーザーが対象テーブルを照会する際にはこれらの権限チェックはバイパスされます。

RLSの無効化と削除

ポリシーに対してSQL ServerのRLSを無効化するには、以下の操作を行います。

• セキュリティポリシーUserFilterをState = offでALTERする

フィルターおよびセキュリティポリシーを削除するには、以下の操作を行います。

• セキュリティポリシーUserFilterをDROPする
• 関数dbo.rowlevelPredicateをDROPする

ベストプラクティス

Microsoftは、以下のベストプラクティスを推奨しています。

• RLSオブジェクト（述語関数とセキュリティポリシー）専用の別スキーマを作成することを強く推奨
• ALTER ANY SECURITY POLICY権限は高権限ユーザー（セキュリティポリシー管理者など）向けのものである。セキュリティポリシー管理者は、自身が保護するテーブルに対するSELECT権限を必ずしも必要としない
• 実行時エラーの潜在的なリスクを回避するため、述語関数内での型変換は避ける
• パフォーマンス低下を防ぐため、述語関数内での再帰は可能な限り避ける。クエリオプティマイザーは直接再帰の検出を試みるが、間接再帰（別の関数が述語関数を呼び出す場合など）の検出は保証されていない
• パフォーマンス最大化のため、述語関数内での過剰なテーブル結合は避ける

RLSの制限事項

RLSには、以下のような制限があります。

• 述語関数はSCHEMABINDING付きで作成する必要がある。SCHEMABINDINGなしで作成された関数をセキュリティポリシーにバインドしようとすると、エラーが発生する
• RLSが実装されているテーブル上には、インデックス付きビューを作成できない
• インメモリテーブルはRLS非対応
• フルテキストインデックスは非対応

まとめ

SQL Server 2016のRLS機能を活用すれば、アプリケーションレベルで変更を加えることなく、データベースレベルでレコードのセキュリティを確保できます。既存のコードに並行して述語関数と新しいセキュリティポリシー機能を使用することで、データベース内のDML（データ操作言語）コードを変更する必要はありません。

コメントやご質問がある場合は、フィードバックタブをご利用ください。

専門家による環境の最適化支援

Rackspaceのアプリケーションサービス（RAS）のエキスパートは、幅広いアプリケーションポートフォリオにわたり、以下のプロフェッショナルサービスおよびマネージドサービスを提供しています。

>eコマースおよびデジタルエクスペリエンスプラットフォーム
• エンタープライズリソースプランニング（ERP）
• ビジネスインテリジェンス
• Salesforceカスタマーリレーションシップマネジメント（CRM）
• データベース
• メールホスティングおよび生産性向上ツール

Rackspaceが提供する価値：

• 中立的な専門知識：即座に価値をもたらす機能に焦点を当て、お客様のモダナイゼーションの道のりを簡素化し、ガイドします。
• Fanatical Experience™：「プロセスファースト、テクノロジーセカンド®」のアプローチと専任の技術サポートを組み合わせ、包括的なソリューションを提供します。
• 比類ないポートフォリオ：豊富なクラウド経験を活かし、適切なクラウド上に適切なテクノロジーを選定・導入するお手伝いをします。
• アジャイルなデリバリー：お客様の現在地に合わせて伴走し、私たちの成功をお客様の成功と一致させます。

今すぐチャットで相談を始めましょう。