機密データのコンプライアンス管理を実装する

  • 8 分

データベースの移行後にコンプライアンス制御を実装することは、データがセキュリティで保護され、関連する規制に準拠している状態を確実に維持するために重要です。 Azure SQL などの新しい環境に移行すると、新しいセキュリティ機能が導入されます。

サーバーとデータベースの監査を検討する

Azure SQL の監査は、データベース イベントを追跡し、それらを Azure Storage アカウント、Log Analytics ワークスペース、または Event Hubs の監査ログに書き込みます。 さらに、規制コンプライアンスの維持、アクティビティ パターンの分析、セキュリティ違反を示す可能性がある逸脱の検出をしやすくします。

サーバー レベルとデータベース レベルのポリシーを定義できます。 サーバー ポリシーは、Azure の新規とび既存のデータベースを自動的にカバーします。

  • サーバー監査を有効にすると、個々の監査設定に関係なく、データベースの監査がトリガーされます。
  • データベース レベルで監査を有効にして、サーバーとデータベースの両方のポリシーを同時に共存させることができます。
  • 読み取り専用レプリカでの監査は自動的に有効になります。

次のシナリオを除き、サーバー監査とデータベース監査の両方を一緒に有効にしないことをお勧めします。

  • 特定のデータベースに、異なるストレージ アカウント、保持期間、または Log Analytics ワークスペースが必要な場合。

  • サーバー上の他とは異なる一意のイベントの種類またはカテゴリを持つ特定のデータベースに対して監査が必要な場合。

他のすべての場合は、サーバー レベルの監査のみを有効にし、すべてのデータベースでデータベース レベルの監査を無効なままにしておくことをお勧めします。

SQL Database の既定の監査ポリシーには、次の一連のアクション グループが含まれています。

アクション グループ 定義
BATCH_COMPLETED_GROUP データベースに対して実行されるすべてのクエリとストアド プロシージャを監査します。
SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP これは、プリンシパルがデータベースへのログインに成功したことを示します。
FAILED_DATABASE_AUTHENTICATION_GROUP これは、プリンシパルがデータベースへのログインに失敗したことを示します。

Azure SQL サーバー上のすべてのデータベースで監査を有効にするには、サーバーのメイン ブレードの [セキュリティ] セクションで [監査] を選びます。

Screenshot of auditing option in the Security section of a SQL server.

[監査] ページでは、監査ログの送信先を設定したり、Azure SQL 監査と同じログ送信先で Microsoft サポート エンジニアの操作を追跡するか、別のものにするかを選んだりできます。

Screenshot of the Auditing page of a SQL server.

次のクエリを実行することで、Microsoft サポートの操作の監査ログを Log Analytics ワークスペースで確認できます。

AzureDiagnostics
| where Category == "DevOpsOperationsAudit"

重要

Azure SQL Database と Azure SQL Managed Instance の監査サービスは、最適な可用性とパフォーマンスのために微調整されています。 ただし、非常に高いアクティビティまたは重大なネットワーク輻輳の条件下では、特定の監査イベントがログに記録されない可能性があることに注意してください。

秘密度ラベルを監査する

データ分類と組み合わせることで、機密データへのアクセスを監視することもできます。 Azure SQL Auditing は拡張され、data_sensitivity_information という新しいフィールドが監査ログに追加されました。

このフィールドは、クエリによって返されるデータの秘密度ラベルをログに記録することで、分類された列へのアクセスを追跡する簡単な方法を提供します。

Screenshot of the Information Protection page from Azure portal.

監査は、データベース エンジンで発生するイベントの追跡と記録で構成されます。 Azure SQL 監査により、それを有効にするために必要な構成手順が簡略化され、SQL Database と SQL Managed Instance のデータベース アクティビティを追跡しやすくなります。

動的データ マスク

動的データ マスクは、露出を制限するためにデータを難読化することによって機能します。 これにより、機密情報へのアクセスを必要としないユーザーが、列は表示できますが、実際のデータはできません。 動的データ マスクはプレゼンテーション レイヤーで機能するため、高い特権を持つユーザーはマスクされていないデータを引き続き表示できます。

動的データ マスクを使用すると、アプリケーションまたはデータベースに必要な変更が最小限に抑えられるという利点があります。 これは、Azure portal 経由で、または T-SQL を使用して簡単に構成できます。

Screenshot of the dynamic data masking T-SQL commands.

PhoneNumber と EmailAddress の両方の列は、テーブルに対する SELECT アクセス許可のみを持つ DDMDemo ユーザーに対して非表示になります。 ユーザーは電話番号の最後の 4 桁を参照できます。これは列の最後の 4 桁を除くすべての数字を置き換える "partial 関数" を使用してマスクされているためです。 このマスクはカスタム関数と見なされます。 T-SQL に加えて、Azure SQL Database を使用している場合は、Azure portal 内で動的マスク ルールを作成できます。

Screenshot of how to add masking rule in Azure portal.

マスク ルールを追加するには、Azure portal 内でデータベースに移動し、データベースのメイン ブレードの [セキュリティ] セクションで [動的データ マスク] を選択します。

動的データ マスクでは、次のマスク パターンがサポートされていて使用できます。

マスク関数 定義 T-SQL の例
[Default] 値のどの部分もユーザーに公開されないように、列のデータをマスクします。 ユーザーには、文字列値が XXXX、数値が 0、日付値が 01.01.1900 として表示されます。 ALTER TABLE [Customer] ALTER COLUMN Address ADD MASKED WITH (FUNCTION = 'default()')
クレジット カード 最後の 4 文字を除くすべてがマスクされ、ユーザーには最後の 4 桁の数字が表示されます。 このマスクは、クレジット カード番号の最後の 4 桁を表示する必要があるが、数字全体を参照する必要はない顧客サービス エージェントに便利です。 データは、通常のクレジット カード番号形式 (XXXX-XXXX-XXXX-1234) で表示されます。 ALTER TABLE [Customer] ALTER COLUMN Address ADD MASKED WITH (FUNCTION = 'partial(0,"XXXX-XXXX-XXXX-",4)')
電子メール 最初の文字と末尾のドメイン サフィックスのみがマスクされません (例: "aXXX@XXXXXXX.com") ALTER TABLE [Customer] ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()')
番号 このマスク形式は、数値列で使う必要があります。 乱数が、実際の値ではなくマスクされた値として表示されます。 クエリごとに異なる数値が表示されます。 ALTER TABLE [Customer] ALTER COLUMN [Month] ADD MASKED WITH (FUNCTION = 'random(1, 12)')
カスタム文字列 このオプションを使用すると、テキストを任意の値でマスクしたり、マスクされた値の終わりにカスタムの文字数を表示したりできます。 マスクされる値の長さが、マスクが表示を指定した文字数以下の場合は、マスクされた文字のみが表示されます。 ALTER TABLE [Customer] ALTER COLUMN [PhoneNumber] ADD MASKED WITH (FUNCTION = 'partial(1,"XXXXXXX",0)')

マスクが定義されている列からマスクされていないデータをユーザーが取得できるようにするには、明示的に UNMASK アクセス許可を付与する必要があります。

Note

結果に基づく推論を使って、マスクされたデータを識別できます。 データ マスクを使っている場合は、ユーザーがアドホック クエリを実行する機能も制限する必要があります。

そのため、動的データ マスクを監査、暗号化、行レベルのセキュリティなどの他のセキュリティ機能と組み合わせて、機密データの保護を強化することをお勧めします。

ユース ケース

データ マスクはシンプルで軽量な機能であり、次のような多くのシナリオに最適です。

  • データベースに直接アクセスできないアプリケーション ユーザーからデータをマスクします。

  • ユーザーのグループに対して個人情報を制限します。

  • マスクされたデータを外部ベンダーに提供します。この場合は、機密情報を保護しながら、データ内の項目間のリレーションシップを維持する必要があります。

  • UNMASK アクセスがないユーザーを使用して、運用データベースのコピーを開発目的で下位環境にエクスポートします。 エクスポートされたデータはマスクされた形式です。

データのインポートとエクスポート

SELECT INTO または INSERT INTO を使って、マスクされた列のデータを別のテーブルにコピーすると、対象テーブルのデータはマスクされた状態になります。

UNMASK 特権を持たないユーザーが SQL Server のインポートとエクスポートを実行すると、エクスポートされたデータ ファイルにはマスクされたデータが含まれ、インポートされたデータベースには非アクティブにマスクされたデータが含まれます。