演習 - データ分類、動的データ マスク、SQL 監査

  • 10 分

この演習では、モジュールの学習を統合して、シナリオを順を追って説明します。 新しいデータ分類と動的データ マスクを追加する方法を学習すると、データ分類用にマークされた列を参照しようとしているユーザーを監査するためのさまざまな方法を確認できます。 この演習では、このモジュールでセキュリティの管理に関して既に学習したいくつかの概念を組み合わせます。

データ分類とデータ マスクを構成する

  1. Azure portal で、Azure SQL Database インスタンスに移動します (論理サーバーではありません)。

    Azure Portal

  2. 左側のペインの [セキュリティ] で、[データの検出と分類] を選択します。

  3. [分類] タブを選択して、[分類の追加] を選択します。

    Screenshot of how to add a new classification.

    前の演習では、推奨列の分類をすべて追加しました。 この手順では、機密性の高い列を分類された列の一覧に "手動で" 追加します。

  4. SalesLT Customer テーブルでは、FirstName と LastName は分類対象としてデータの検出と分類によって識別されましたが、MiddleName は識別されていません。 ドロップダウン リストを使用してここでそれを追加して、[分類の追加] を選択します。

    Screenshot of how to add a name-related classification for MiddleName.

  5. [保存] を選択します。

  6. [概要] タブを表示して分類の追加が成功したことを確認し、さらに SalesLT スキーマの下の分類済みの列の一覧に MiddleName が表示されるようになったことを確認します。

  7. 左側のウィンドウで、[概要] を選択して、ご利用のデータベースの概要に戻ります。

    動的データ マスク (DDM) は、Azure SQL と SQL Server の両方で使用できます。 DDM では、SQL Server レベル (その種のルールをコーディングする必要があるアプリケーション レベルではなく) で非特権ユーザーに対して機密データをマスクすることによりデータの公開が制限されます。 マスクすべき項目は Azure SQL によって推奨されます。マスクを手動で追加することもできます。

    次の手順では、前のステップで確認した FirstName、MiddleName、LastName の各列をマスクします。

  8. Azure portal で、Azure SQL Database に移動します。 左側のウィンドウにある [セキュリティ] で、[動的データ マスク] を選択して、[マスクの追加] を選択します。

  9. ドロップダウン リストで、SalesLT スキーマ、Customer テーブル、FirstName 列を選択します。 マスクのオプションを確認できますが、このシナリオでは既定のオプションが適しています。 [追加] を選択してマスク ルールを追加します。

    Screenshot of how to add First Name mask.

  10. このテーブルの MiddleName と LastName の両方に対して、前の手順を繰り返します。

    これで、次に示すような 3 つのマスク ルールが作成されました。

    Screenshot of how to review all masking rules.

  11. [保存] を選択します。

  12. 左側のウィンドウで、[概要] を選択して、ご利用のデータベースの概要に戻ります。

分類およびマスクされたデータを取得する

次に、分類された列に対して誰かがクエリを実行する場合をシミュレートし、動的データ マスクの動作を検証します。

  1. SQL Server Management Studio (SSMS) に移動します。

  2. AdventureWorks データベースで新しいクエリを作成するには、データベースを右クリックして、[新しいクエリ] を選択します。

  3. 次のクエリを実行すると、分類されたデータが、場合によっては、マスクされたデータとしてマークされた列が返されます。 [実行] を選択してクエリを実行します。

    SELECT TOP 10 FirstName, MiddleName, LastName
FROM SalesLT.Customer;

    結果には、マスクが適用されていない最初の 10 個の名前が表示されます。 なぜですか? あなたがこの Azure SQL Database 論理サーバーの管理者であるためです。

    Screenshot of SQL query results with no mask.

  4. 次のクエリでは、新しいユーザーを作成し、そのユーザーとして前のクエリを実行します。 また、EXECUTE AS を使用して Bob を借用することもできます。 EXECUTE AS ステートメントを実行すると、セッションの実行コンテキストはそのログインまたはユーザーに切り替わります。 つまり、EXECUTE AS コマンドを実行するユーザー (この場合は管理者) ではなく、ログインまたはユーザーに対してアクセス許可がチェックされます。 次に、REVERT を使って、ログインまたはユーザーの借用を停止します。

    次に示すコマンドの最初のいくつかの部分は、前の演習からの繰り返しであるため、見覚えがあるかもしれません。 次のコマンドを使用して新しいクエリを作成し、[実行] を選択してクエリを実行し、結果を確認します。

    -- Create a new SQL user and give them a password
CREATE USER Bob WITH PASSWORD = 'c0mpl3xPassword!';

-- Until you run the following two lines, Bob has no access to read or write data
ALTER ROLE db_datareader ADD MEMBER Bob;
ALTER ROLE db_datawriter ADD MEMBER Bob;

-- Execute as our new, low-privilege user, Bob
EXECUTE AS USER = 'Bob';
SELECT TOP 10 FirstName, MiddleName, LastName
FROM SalesLT.Customer;
REVERT;

    結果には最初の 10 個の名前が表示されますが、マスクが適用されています。 Bob は、このデータのマスクされていない形式へのアクセスを許可されていません。

    Screenshot of SQL query results with mask.

    何らかの理由で Bob が名前にアクセスする必要があり、アクセス許可を取得する場合はどうでしょうか。

    Azure portal で [セキュリティ] の下の [動的データ マスク] ペインに移動してマスクから除外されたユーザーを更新することもできますが、T-SQL を使用してこの操作を行うこともできます。

  5. AdventureWorks データベースを右クリックし、[新しいクエリ] を選択し、次のクエリを入力して Bob がマスクなしで名前の結果に対するクエリを実行できるようにします。 [実行] を選択してクエリを実行します。

    GRANT UNMASK TO Bob;  
EXECUTE AS USER = 'Bob';
SELECT TOP 10 FirstName, MiddleName, LastName
FROM SalesLT.Customer;
REVERT;

    結果には、すべての名前が含まれています。

    Screenshot of SQL query results with no mask.

  6. 新しいクエリで次の T-SQL コマンドを実行して、ユーザーのマスク解除特権を取り上げ、そのアクションを確認することもできます。

    -- Remove unmasking privilege
REVOKE UNMASK TO Bob;  

-- Execute as Bob
EXECUTE AS USER = 'Bob';
SELECT TOP 10 FirstName, MiddleName, LastName
FROM SalesLT.Customer;
REVERT;

    結果には、マスクが適用された名前が含まれています。

    Screenshot of SQL query results with mask.

SSMS で監査ログを確認する

管理者は、データベースおよび特に分類されたデータにアクセスしているユーザーを確認し、監査することをお勧めします。 次に、Azure Blob Storage に送信されている監査ファイルを確認できます。 ログが複数のファイルにまたがっている場合は、最初に監査ファイルをマージする必要があります。 SSMS では、次の手順を実行してこれを行うことができます。

  1. [ファイル]>[開く]>[監査ファイルの統合] を選択します。

    Screenshot of how to open audit files.

  2. [追加] を選択します。

    Screenshot of how to add a new file.

  3. [Azure Blob Storage から追加] を選択し、[接続] を選択します。

    Screenshot of how to add from Azure Blob storage.

  4. このモジュールで使っているアカウントで、Azure にサインインします。

    Screenshot of how to sign in to Azure.

  5. 監査ログの保存先として構成したサブスクリプション、ストレージ アカウント、および BLOB コンテナーを選択します。 ストレージ アカウントは sql で始まる必要があります。 コンテナーは sqldbauditlogs と呼ばれます。 その名前を持つコンテナーが存在しない場合は、監査用に別のストレージ アカウントを作成してあるので、代わりにそれを使用してください。

  6. Azure SQL Database 論理サーバーと AdventureWorks データベースを選びます。 [開始] 時刻が演習を開始した時点よりも前であることを確認してください。 [OK] を選択します。

  7. 確認ウィンドウでは、ダウンロードおよびマージされているファイルの数を確認できます。 [OK] を選択します。

  8. ファイルを確認し、最後にもう一度 [OK] を選択します。

    これで、すべての監査ログが表示されます。 Bob でマスクをテストしていた場所を探します。 リストは下の方にあるはずです。

  9. ステートメントを選択し、詳細ウィンドウの情報を確認します。 たとえば、Bob が分類されたデータを表示しようとしているクエリの 1 つについて、分類されているデータを data_sensitivity_information フィールドに表示できます。

  10. [詳細] ウィンドウで data_sensitivity_information の値をダブルクリックします。 データをより簡単に読み取ることができるように、ポップアップ ウィンドウが開きます。

    data_sensitivity_information の下の表示内容の例を次に示します。

    <sensitivity_attributes max_rank="20" max_rank_desc="Medium"><sensitivity_attribute label="Confidential - GDPR" label_id="bf91e08c-f4f0-478a-b016-23422b2a65ff" information_type="Name" information_type_id="57845286-7598-22f5-3422-15b24aeb125e" rank="20" rank_desc="Medium"/></sensitivity_attributes>

    その後、このマージされたファイルを XEL ファイル、CSV ファイル、またはテーブルにエクスポートして、追加の分析を行うことができます。 Azure PowerShell を使用して拡張イベント ファイルのクエリを実行することもできます。

Azure portal で監査ログを確認する

監査ログの分析は、ユーザーの設定によって異なります。 このセクションでは、Log Analytics を使用して Azure portal のセキュリティ ログを照会する方法について説明します。

  1. Azure portal で AdventureWorks データベースに移動します。 左側のウィンドウの [セキュリティ] で、[監査] を選択し、タスク バーの [監査ログの表示] ボタンを選択します。

    これで、イベント レコードのクエリ、クエリ エディターで実行するオプション (ポータル経由で T-SQL クエリを実行するオプション)、Log Analytics のオプション、ダッシュボードの表示などを表示できるようになりました。

    Screenshot of how to view audit records.

    自由に見て回って、いくつかのオプションについて理解してください。

  2. [Log Analytics] を選択します。 [ログ分析] ボタンにアクセスするために、[最新の情報に更新] を選択することが必要になる場合があります。 [開始] 画面が表示されたら、[OK] を選択します。 これによりクエリ エディターが表示されますが、これは T-SQL エディターではありません。 このビューでは、Kusto クエリ言語 (KQL) を使用してログのクエリを実行できます。KQL は、SQL の専門家が簡単に使用して理解できるように作られています。

    既定のクエリでは、カテゴリ SQLSecurityAuditEvents に対してクエリが実行されます。 今はこのカテゴリを使ってセキュリティ関連のインシデントを見ているかもしれませんが、このツールを使うと、Log Analytics の他の Azure ログやカテゴリのクエリを実行することもできます。 この手順では、Bob が機密情報にアクセスしようとしたステートメントを探すことができます。 SSMS で見たものと同じ情報を取得するには、> ボタンを選んで行の詳細を展開します。

    ここでは、結果が表示されるまで数分かかる場合があります。 クエリを最新の状態に更新するには、もう一度 [実行] を選択します。

    このアクティビティではログの KQL クエリを深く掘り下げませんが、後でさらに練習したい場合は、前述のリファレンスに多くのリソースがあります。

    次の手順では、ログとその他の SQL アクティビティを監視および監査できるように、SQL セキュリティで Log Analytics に基づいてダッシュボードを構築する方法を見ていきます。 [監査レコード] ウィンドウに戻るには、Log Analytics クエリ ウィンドウの右上にある [X] を選択してウィンドウを閉じます。

  3. [View dashboard (ダッシュボードの表示)] を選択します。

    Screenshot of the log analytics dashboard.

    概要ダッシュボードが表示されます。

  4. 詳細を表示するには、[Azure SQL - 機密データへのアクセス権] を選択します。

    項目がここに表示されるようにするには、3 - 5 分待ってから、[更新] を選択することが必要になる場合があります。

    この詳細情報を使用して、次のことを確認できます。

    • 機密データにアクセスしているクエリの数。
    • アクセスされているデータの型と機密性。
    • 機密データにアクセスしているプリンシパル。
    • 機密データにアクセスしている IP。

    ここで参照できる内容と、このツールで使用状況を監査する方法を確認してください。 これらをそれぞれ選んで、Log Analytics で関連するログを確認することもできます。

  5. 完了したら、[Azure SQL - 機密データへのアクセス権] ウィンドウの右上にある [X] を選択してペインを閉じます。

  6. 監査ダッシュボードの [概要] ペインに戻り、[Azure SQL - セキュリティの分析情報] を選びます。

    このダッシュボードでは、データベースの利用状況を理解し、異常についての分析情報を得るのに役立つより詳細な監査情報が表示されます。 ここでは、オプションの確認とドリルダウンを数分で行います。

Azure では、Azure SQL サービスのこれらの分析情報を表示することに加えて、Microsoft Defender for Cloud を利用して、Azure 資産全体に発生する問題の監視、管理、対応を行うことができます。 Azure SQL Defender for Cloud の外部で使用できるものを確認する場合は、Azure portal で [Microsoft Defender for Cloud] を探して選びます。 サブスクリプション レベルによっては、アクセスが制限される場合があります。