データウェアハウス内のデータをセキュリティで保護する

Microsoft Fabric のアクセス許可と詳細な SQL アクセス許可は連携して機能することで、ウェアハウスのアクセスとユーザーのアクセス許可を管理します。この演習では、詳細なアクセス許可、列レベルセキュリティ、行レベルセキュリティ、動的データマスクを使用してデータをセキュリティで保護します。

このラボは完了するまで、約 45 分かかります。

注:この演習を完了するには、Microsoft Fabric 試用版が必要です。

ワークスペースの作成

Fabric でデータを操作する前に、Fabric 試用版を有効にしてワークスペースを作成してください。

Microsoft Fabric ホームページで、Synapse Data Warehouse を選択します。
左側のメニューバーで、 [ワークスペース] を選択します (アイコンは 🗇 に似ています)。
任意の名前で新しいワークスペースを作成し、Fabric 容量を含むライセンスモード (“試用版”、Premium、または Fabric) を選択します。**
開いた新しいワークスペースは空のはずです。

データウェアハウスの作成

次に、作成したばかりのワークスペース内にデータウェアハウスを作成します。 Synapse Data Warehouse のホームページには、新しいウェアハウスを作成するためのショートカットがあります。

Synapse Data Warehouse ホームページで、新しいウェアハウスを任意の名前を付けて作成します。

1 分ほどで、新しいレイクハウスが作成されます。

テーブル内の列に動的データマスクを適用する

動的データマスクルールは、テーブルレベルで個々の列に適用されるため、すべてのクエリがマスクの影響を受けます。機密データを閲覧する明示的なアクセス許可を持たないユーザーにはクエリ結果においてマスクされた値が表示され、データを閲覧する明示的なアクセス許可を持つユーザーには伏せられていない状態で値が表示されます。マスクには、既定、メール、ランダム、カスタム文字列という 4 つの種類があります。この演習では、既定のマスク、電子メールマスク、およびカスタム文字列マスクを適用します。

ウェアハウスで [T-SQL] タイルを選択し、既定の SQL コードを次の T-SQL ステートメントに置き換えてテーブルを作成し、データを挿入して表示します。 CREATE TABLE ステートメントで適用されるマスクは、以下の処理を行います。

 CREATE TABLE dbo.Customer
 (   
     CustomerID INT NOT NULL,   
     FirstName varchar(50) MASKED WITH (FUNCTION = 'partial(1,"XXXXXXX",0)') NULL,     
     LastName varchar(50) NOT NULL,     
     Phone varchar(20) MASKED WITH (FUNCTION = 'default()') NULL,     
     Email varchar(50) MASKED WITH (FUNCTION = 'email()') NULL   
 );
 GO
 --Users restricted from seeing masked data will see the following when they query the table
 --The FirstName column shows the first letter of the string with XXXXXXX and none of the last characters.
 --The Phone column shows xxxx
 --The Email column shows the first letter of the email address followed by XXX@XXX.com.
    
 INSERT dbo.Customer (CustomerID, FirstName, LastName, Phone, Email) VALUES
 (29485,'Catherine','Abel','555-555-5555','catherine0@adventure-works.com'),
 (29486,'Kim','Abercrombie','444-444-4444','kim2@adventure-works.com'),
 (29489,'Frances','Adams','333-333-3333','frances0@adventure-works.com');
 GO

 SELECT * FROM dbo.Customer;
 GO

[▷ 実行] ボタンを使用して SQL スクリプトを実行します。これにより、データウェアハウスの dbo スキーマに Customer という名前の新しいテーブルが作成されます。
次に、[エクスプローラー] ペインで [スキーマ] > [dbo] > [テーブル] の順に展開し、Customer テーブルが作成されていることを確認します。あなたはマスクされていないデータを表示できるワークスペース管理者として接続されているため、SELECT ステートメントはマスクされていないデータを返します。
閲覧者 ワークスペースロールのメンバーであるテストユーザーとして接続し、次の T-SQL ステートメントを実行します。
```
 SELECT * FROM dbo.Customer;
 GO
```
このユーザーには UNMASK アクセス許可が付与されていないため、返されるデータの FirstName、Phone、Email 列はマスクされます。これらの列は CREATE TABLE ステートメント内でマスクを使用して定義されたためです。
ワークスペース管理者として再接続し、次の T-SQL を実行して、テストユーザーに対してデータのマスクを解除します。
```
 GRANT UNMASK ON dbo.Customer TO [testUser@testdomain.com];
 GO
```
もう一度テストユーザーとして接続し、次の T-SQL ステートメントを実行します。
```
 SELECT * FROM dbo.Customer;
 GO
```
今度はテストユーザーに UNMASK アクセス許可が付与されているため、データはマスクされていない状態で返されます。

行レベルセキュリティを適用する

行レベルセキュリティ (RLS) を使用すると、ID またはクエリを実行するユーザーのロールに基づいて行へのアクセスを制限できます。この演習では、セキュリティポリシーとインラインテーブル値関数として定義されたセキュリティ述語を作成して、行へのアクセスを制限します。

前の演習で作成したウェアハウスで、[新しい SQL クエリ] ドロップダウンを選択します。 [空白] ヘッダーの下のドロップダウンで、[新しい SQL クエリ] を選択します。

テーブルを作成してデータを挿入します。後の手順で行レベルセキュリティをテストできるように、’testuser1@mydomain.com’ を自分の環境のユーザー名に、’testuser2@mydomain.com’ を自分のユーザー名に置き換えます。

 CREATE TABLE dbo.Sales  
 (  
     OrderID INT,  
     SalesRep VARCHAR(60),  
     Product VARCHAR(10),  
     Quantity INT  
 );
 GO
     
 --Populate the table with 6 rows of data, showing 3 orders for each test user. 
 INSERT dbo.Sales (OrderID, SalesRep, Product, Quantity) VALUES
 (1, 'testuser1@mydomain.com', 'Valve', 5),   
 (2, 'testuser1@mydomain.com', 'Wheel', 2),   
 (3, 'testuser1@mydomain.com', 'Valve', 4),  
 (4, 'testuser2@mydomain.com', 'Bracket', 2),   
 (5, 'testuser2@mydomain.com', 'Wheel', 5),   
 (6, 'testuser2@mydomain.com', 'Seat', 5);  
 GO
   
 SELECT * FROM dbo.Sales;  
 GO

[▷ 実行] ボタンを使用して SQL スクリプトを実行します。これにより、データウェアハウスの dbo スキーマに Sales という名前の新しいテーブルが作成されます。
次に、[エクスプローラー] ペインで [スキーマ] > [dbo] > [テーブル] の順に展開し、Sales テーブルが作成されていることを確認してください。
新しいスキーマ、関数として定義されたセキュリティ述語、セキュリティポリシーを作成します。

```sql –Create a separate schema to hold the row-level security objects (the predicate function and the security policy) CREATE SCHEMA rls; GO

–Create the security predicate defined as an inline table-valued function. A predicate evalutes to true (1) or false (0). This security predicate returns 1, meaning a row is accessible, when a row in the SalesRep column is the same as the user executing the query.

–Create a function to evaluate which SalesRep is querying the table CREATE FUNCTION rls.fn_securitypredicate(@SalesRep AS VARCHAR(60)) RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS fn_securitypredicate_result
WHERE @SalesRep = USER_NAME(); GO

–Create a security policy to invoke and enforce the function each time a query is run on the Sales table. The security policy has a Filter predicate that silently filters the rows available to read operations (SELECT, UPDATE, and DELETE). CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE rls.fn_securitypredicate(SalesRep)
ON dbo.Sales
WITH (STATE = ON); GO
Use the ▷ Run button to run the SQL script
Then, in the Explorer pane, expand Schemas > rls > Functions, and verify that the function has been created.
Confirm that you’re logged as another user by running the following T-SQL.

```sql SELECT USER_NAME(); GO
Query the sales table to confirm that row-level security works as expected. You should only see data that meets the conditions in the security predicate defined for the user you’re logged in as.

```sql SELECT * FROM dbo.Sales; GO

Implement column-level security

Column-level security allows you to designate which users can access specific columns in a table. It is implemented by issuing a GRANT statement on a table specifying a list of columns and the user or role that can read them. To streamline access management, assign permissions to roles in lieu of individual users. In this exercise, you will create a table, grant access to a subset of columns on the table, and test that restricted columns are not viewable by a user other than yourself.

In the warehouse you created in the earlier exercise, select the New SQL Query dropdown. Under the dropdown under the header Blank, select New SQL Query.
Create a table and insert data into the table.

    CREATE TABLE dbo.Orders
    (   
        OrderID INT,   
        CustomerID INT,  
        CreditCard VARCHAR(20)      
        );
    GO

    INSERT dbo.Orders (OrderID, CustomerID, CreditCard) VALUES
    (1234, 5678, '111111111111111'),
    (2341, 6785, '222222222222222'),
    (3412, 7856, '333333333333333');
    GO

    SELECT * FROM dbo.Orders;
    GO

テーブル内の列を表示するためのアクセス許可を拒否します。以下の Transact SQL は、’testuser@mydomain.com’ が Orders テーブル内の CreditCard 列を表示することを防ぎます。以下の DENY ステートメントで、testuser@mydomain.com をワークスペースに対する閲覧者アクセス許可を持つシステム内のユーザー名に置き換えます。

DENY SELECT ON dbo.Orders (CreditCard) TO [testuser@mydomain.com];

SELECT アクセス許可を禁止したユーザーとして Fabric にログインすることで、列レベルセキュリティをテストします。
Orders テーブルに対してクエリを実行し、列レベルセキュリティが想定通りに機能していることを確認します。次のクエリが返すのは OrderID 列と CustomerID 列だけであり、CrediteCard 列は返しません。
```
 SELECT * FROM dbo.Orders;
 GO

 --You'll receive an error because access to the CreditCard column has been restricted.  Try selecting only the OrderID and CustomerID fields and the query will succeed.

 SELECT OrderID, CustomerID from dbo.Orders
```

T-SQL を使用して SQL の詳細なアクセス許可を構成する

Fabric ウェアハウスには、ワークスペースレベルおよびアイテムレベルでデータへのアクセスを制御できるアクセス許可モデルがあります。 Fabric ウェアハウスのセキュリティ保護可能なリソースに関してユーザーが何を実行できるかをより細かく制御する必要がある場合は、標準の SQL データ制御言語 (DCL) コマンドである GRANT、DENY、REVOKE を使用できます。この演習では、オブジェクトを作成し、それらを GRANT と DENY を使用してセキュリティで保護し、その後クエリを実行して、詳細なアクセス許可の適用の効果を確認します。

前の演習で作成したウェアハウスで、[新規 SQL クエリ] ドロップダウンを選択します。 [空白] ヘッダーで、[新規 SQL クエリ] を選択します。
ストアドプロシージャとテーブルを作成します。

    CREATE PROCEDURE dbo.sp_PrintMessage
    AS
    PRINT 'Hello World.';
    GO
  
    CREATE TABLE dbo.Parts
    (
        PartID INT,
        PartName VARCHAR(25)
    );
    GO
    
    INSERT dbo.Parts (PartID, PartName) VALUES
    (1234, 'Wheel'),
    (5678, 'Seat');
    GO  
    
    --Execute the stored procedure and select from the table and note the results you get because you're a member of the Workspace Admin. Look for output from the stored procedure on the 'Messages' tab.
      EXEC dbo.sp_PrintMessage;
    GO
    
    SELECT * FROM dbo.Parts
    GO

次にワークスペース閲覧者ロールのメンバーであるユーザーに対してテーブルに対するアクセス許可の DENY SELECT を実行し、同じユーザーに対してプロシージャに対する GRANT EXECUTE を実行します。

    DENY SELECT on dbo.Parts to [testuser@mydomain.com];
    GO

    GRANT EXECUTE on dbo.sp_PrintMessage to [testuser@mydomain.com];
    GO

[testuser@mydomain.com] の代わりに、上の DENY および GRANT ステートメントで指定したユーザーとして Fabric にログインします。次に、ストアドプロシージャを実行し、テーブルに対してクエリを実行することで、先ほど適用した詳細なアクセス許可をテストします。

    EXEC dbo.sp_PrintMessage;
    GO
    
    SELECT * FROM dbo.Parts

リソースをクリーンアップする

この演習では、テーブル内の列に対して動的データマスクを適用し、行レベルセキュリティを適用し、列レベルセキュリティを実装し、T-SQL を使用して SQL の詳細なアクセス許可を構成しました。

左側のバーで、ワークスペースのアイコンを選択して、それに含まれるすべての項目を表示します。
ツールバーの […] メニューで、 [ワークスペースの設定] を選択してください。
[全般] セクションで、[このワークスペースの削除] を選択します。

データ ウェアハウス内のデータをセキュリティで保護する