行レベルのセキュリティの詳細な調査

はじめに

組織は、統合を使用してデータベースソリューションのライセンス供与のコストを削減する方法についてますます懸念を抱いています。インスタンスとデータベース間の既存の1対多の関係を利用するだけで、SQLServerである程度の統合を実現できます。ただし、ソリューションでデータを1つのテーブルに統合する必要がある場合があります。このような場合、データへのアクセスを制限する方法について懸念があるかもしれません。

行レベルのセキュリティは、上記と同様のシナリオのソリューションとしてSQLServer2016で導入されました。 述語関数と呼ばれるインラインテーブル値関数で定義された条件に基づいて、テーブル内の行へのアクセスを制限できます。 。述語関数が統合データを含むユーザーテーブルに適用されると、システムは、役割に応じてさまざまなデータセットをさまざまなユーザーに返すように構成できます。役割は、職務内容や部門などに依存します。

シナリオ

金融機関を使用して、この概念を説明するための簡単なシナリオを作成します。銀行は、すべての顧客のアカウントを1つのデータベースとトランザクションに統合することを決定しました。 tableは、 Customers と同様に、すべてのトランザクションを含む単一のパーティションテーブルです。 すべての銀行の顧客を保管するためのテーブル。銀行はいくつかの国にあり、また拡大しています。各国はAffiliateIDで識別されます 桁。会社は、年功序列に基づいてキーテーブルへのアクセスが制限されるように構成されています。

セキュリティ保護可能なものを特定する

ロールと行レベルのセキュリティポリシーに基づいて、顧客とトランザクションデータへのアクセスを制限する行レベルのセキュリティソリューションを実装する必要があります。最初のステップは、必要なテーブルを作成することです。リスト1は、テストするキーテーブルのDDLを示しています。このテストに使用されたデータベース全体は、ここからダウンロードできます。

Listing 1 – Core Tables in West African Commercial Bank Database;
-- Customers;
create table Customers
(CustID int identity (1000,1) not null Primary Key
,FirstName varchar(100)
,LastName varchar(100)
,PhoneNo bigint
,ContactAddress varchar(4000)
,AffiliateID char(3) foreign key references Affiliates(AffiliateID)
,AccountNo1 bigint
,AccountNo2 bigint
,AccountNo3 bigint
,AccountNo1Curr char (3)
,AccountNo2Curr char (3)
,AccountNo3Curr char (3)
)
GO

-- Transactions;
create table Transactions
(TranID int identity (1000,1) not null 
,AcctID int foreign key references Accounts (AcctID)
,TranDate datetime 
,TranAmt money
,AffiliateID char(3) foreign key references Affiliates(AffiliateID)
,primary key (TranID,TranDate))
ON PartSch (TranDate)

-- Transaction_History;
create table Transaction_History
(TranID int identity (1000,1) not null 
,AcctID int foreign key references Accounts (AcctID)
,TranDate datetime 
,TranAmt money
,AffiliateID char(3) foreign key references Affiliates(AffiliateID)
,primary key (TranID,TranDate))
ON PartSch (TranDate)

次に、スタッフを識別するために使用できる一連のテーブルを作成します。この設定では、各スタッフが ScopeIDを持っています これにより、データをどの程度表示または操作できるかが決まります。

1. 全国 –スタッフは、スタッフの国（彼または彼女が勤務している国）でのみデータを操作できます
2. 地域 –スタッフは、スタッフの地域（西アフリカなど）のデータのみを操作できます
3. グローバル –スタッフは、銀行に支店がある国ならどこでもデータを操作できます

各スコープは、指定に基づいてスタッフに割り当てられます。グループマネージャーのスコープはグローバルです 、カントリーマネージャーのスコープはリージョナル エグゼクティブの範囲はNational 。データへのアクセスを制限する従来の方法は、多くの場合、役割と権限を使用することです。ロールに権限を割り当て、続いてユーザーにロールを割り当てるということは、問題のテーブルのデータセット全体に対して、ユーザーがそのロールに関連付けられた権限を持っていることを意味します。行レベルのセキュリティにより、よりきめ細かい処理を行うことができます。ユーザーのSELECT / UPDATE / DELETE権限を、テーブル内のデータセットのサブセットに制限します（きめ細かいアクセス制御）。

図。 1。 StaffScopeとStaffTables

データベースの役割とユーザー

リスト2は、ソリューションを進めるために作成する必要のあるユーザーとロールを示しています。アイデアは、ユーザーテーブルStaffおよびStaffScopeに格納されているスタッフと、これらのスタッフが最終的にデータにアクセスするために使用するデータベースプリンシパルとの間に関係があるということです。図1のDBUserIDという列を確認します。 。この列は、DATABASE_PRINCIPAL_ID関数を使用して入力されます（リスト2を参照）

Listing 2 – Staff, Database User IDs and Roles

-- Populate Staff Table
use WACB
go
insert into Staff values ('John','Edu',DATABASE_PRINCIPAL_ID(),'Manager','233205678493','2','Accra, Ghana','EGH');
insert into Staff values ('Margaret','Harrison',DATABASE_PRINCIPAL_ID(),'Group Manager','2348030006574','3','Lagos, Nigeria','ENG');
insert into Staff values ('Edward','Antwi',DATABASE_PRINCIPAL_ID(),'Executive','22824567493','1','Lome, Togo','ETG');
insert into Staff values ('Barbara','Orji',DATABASE_PRINCIPAL_ID(),'Executive','22424567493','1','Abuja, Nigeria','ENG');
GO

-- Create Database User IDs for Staff
create user jedu without login;
create user mharrison without login;
create user eantwi without login;
create user borji without login;

-- Associate Database Principal IDs with Staff
update staff set DBUserID=DATABASE_PRINCIPAL_ID(concat(left(firstname,1),lastname));


-- Create Database Roles
create role [National] ;
create role [Regional] ;
create role [Global] ;

-- Grant Permissions on Desired Tables to Database Roles
grant select on customers to [National];
grant select, update on customers to Regional;
grant select, update on customers to Global;
grant select on Transactions to Regional, Global;
grant select on Transaction_History to Regional, Global;
grant update on Transactions to Global;


-- Grant Database Roles to Database Users Associated with Staff
alter role [National] add member eantwi;
alter role [National] add member borji;
alter role [Regional] add member jedu;
alter role [Global] add member mharrison;

これまでのところ、私たちが行ったことは次のとおりです。

1. 保護する必要のあるテーブルを作成/特定します
2. 行レベル（スコープ）でデータへのアクセスを制限するために使用する基準を示すテーブルを作成します
3. 作成されたデータベースの役割とユーザーに制限を適用します
4. 役割と権限を使用したコアテーブルへの制限付きアクセス（「テーブルレベルのセキュリティ」）

予測機能とセキュリティポリシー

これまでのところ、ロールと権限を使用して実装されたテーブルレベルセキュリティと呼ばれるものがあります。今、私たちはもっと深く行きたいです。テーブルに対するSELECT権限を持つ2つのプリンシパルがテーブルをクエリできるようにしたいが、設定した条件に基づいて異なるデータセットを表示する必要があります。 リスト3 これをどのように達成するかを示しています。

Listing 3 - Implement Row Level Security

-- Create Predicate Function
create schema rls;
go

create function rls.AccessPredicate (@AffiliateID char(3))
returns table
with schemabinding
as
return select 1 as access 
from dbo.Staff as s 
join dbo.StaffScope ss on s.ScopeID=ss.ScopeID 
join dbo.Affiliates a on s.AffiliateID=a.AffiliateID
where (
IS_MEMBER('National')=1
and s.DBUserID=DATABASE_PRINCIPAL_ID()
and @AffiliateID=s.AffiliateID
)
OR
(
IS_MEMBER('Regional')=1
and @AffiliateID in (select a.AffiliateID from dbo.Affiliates where Region='West Africa')
)
OR
(
IS_MEMBER('Global')=1
);
GO

-- Create Security Policy
create security policy rls.dataSecurityPol
add filter predicate rls.AccessPredicate (AffiliateID) on dbo.Customers,
add filter predicate rls.AccessPredicate (AffiliateID) on dbo.Transactions,
add filter predicate rls.AccessPredicate (AffiliateID) on dbo.Transaction_History,
add block predicate rls.AccessPredicate (AffiliateID) on dbo.Customers after update,
add block predicate rls.AccessPredicate (AffiliateID) on dbo.Transactions after update,
add block predicate rls.AccessPredicate (AffiliateID) on dbo.Transaction_History after update;
GO

-- Alter Security Policy
alter security policy rls.dataSecurityPol
add filter predicate rls.AccessPredicate (AffiliateID) on dbo.Transaction_History,
add block predicate rls.AccessPredicate (AffiliateID) on dbo.Transaction_History after update;
GO

述語関数は、プリンシパルが対象データのサブセットを表示するために満たす必要のある条件を定義します。この関数には、次の3つの条件があります。

1. スタッフのデータベースユーザーは、 Nationalのメンバーです。 役割とAffiliateID スタッフのそれと一致するまたは
2. スタッフのデータベースユーザーは、地域のメンバーです。 役割とAffiliateID AffiliateIDのリストと一致します は西アフリカ地域に属している、または
3. スタッフのデータベースユーザーは、グローバルのメンバーです。

これは、グローバルのメンバーであることを意味します ロールは、そのロールに属しているという理由だけですべてのデータを参照します。ただし、他の2つの役割のメンバーは、 AffiliateIDsに隣接する追加の基準を満たす必要があります。 。

関数を使用するには、これをFILTER述語またはBLOCK述語としてテーブルに適用します。 FILTER述語はプリンシパルが見ることができるものを制限し、BLOCK述語は、プリンシパルが関数で定義された制限によって提示されたデータ以外のデータを操作できないようにします。セキュリティポリシーは、関心のあるすべてのテーブルのFILTER述語とBLOCK述語を指定するコンテナです。リスト3をご覧ください。 もう一度。

このアプローチの非常に興味深い側面の1つは、モジュール性です。既存の定義済みテーブルに影響を与えることなく、セキュリティポリシーの追加のテーブルに述語を適用できます。データベースユーザーを作成して適切なロールを付与することにより、新しいデータベースプリンシパル（スタッフ）を追加できます。スタッフの移動が発生すると、役割の割り当てなどを更新できます。

実装のテスト

これで、データベースプリンシパルになりすまして、リスト4のコードを使用して、期待どおりの結果が得られるかどうかを判断できます。その前に、図2の各スタッフとその関連会社に関連付けられている役割を見てみましょう。

図。 2。 スタッフリスト

Listing 4 – Testing the Implementation

select * from Customers;
execute ('select * from Customers') as user='eantwi';
execute ('select * from Customers') as user='borji';
execute ('select * from Customers') as user='jedu';
execute ('select * from Customers') as user='mharrison';

最初の行で、顧客にクエリを実行します sysadmin、としてのテーブル しかし、私は行を取得しません。つまり、管理者でさえ、なりすましなしにRLSの影響を無効にすることはできません。

図。 4。 SysAdminに行が表示されない

バーバラとエドワードはどちらもエグゼクティブであり、ナショナルスコープに属していますが、異なる国で働いているため、それぞれのアフィリエイトに関連付けられている顧客を確認できます。 （図1のスタッフ名を参照してください。）

図。 5. 幹部はアフィリエイトの列を見る

ジョンとマーガレットはカントリーマネージャーとグループマネージャーです。それらは地域に属しています およびグローバル それぞれスコープ。ジョンは西アフリカのデータを表示し、マーガレットはすべての地域のデータを表示します。

図。 6。 マネージャーは自分の地域の行を見る

結果は、セキュリティポリシーが適用されている他のすべてのテーブルで同じです。 トランザクションの権限なしでそれを観察します 表、行レベルのセキュリティは価値がありません。

図。 7。 トランザクションにSELECT権限がありません テーブル

Listing 5 – Permissions on Transactions Table
grant select on dbo.Transactions to [National];

図。 8。 トランザクション 幹部から見た表

結論

行レベルのセキュリティは、SQLServerのきめ細かいアクセス制御機能を活用する強力な方法です。この機能を使用するには、SQLServer2016以降を実行している必要があります。名前が示すように、目的は、「テーブルレベルのセキュリティ」を処理した後、複雑なクエリを使用してテーブル内の行へのアクセスを制限することです。この機能を適用できるシナリオは無限であるため、幅広い環境で非常に役立ちます。それがあなたのために何ができるかを探求し、見るためにうまくやってください。

参考資料

イサコフ、V。（2018）。 Exam Ref70-764SQLデータベースインフラストラクチャの管理 。ピアソン教育

行レベルのセキュリティ