機密データのコンプライアンスコントロールを実装する
データベースの移行後にコンプライアンス制御を実装することは、データがセキュリティで保護され、関連する規制に準拠していることを確認するために重要です。 Azure SQL などの新しい環境に移行すると、新しいセキュリティ機能が導入されます。
サーバーとデータベースの監査を検討する
Azure SQL 監査では、データベース イベントを追跡し、Azure Storage アカウント、Log Analytics ワークスペース、または Event Hubs に格納されている監査ログに記録します。 さらに、規制コンプライアンスの維持、アクティビティ パターンの分析、およびセキュリティ違反を示す可能性のある偏差の検出が容易になります。
サーバー レベルとデータベース レベルのポリシーを定義できます。 サーバー ポリシーは、Azure の新規とび既存のデータベースを自動的にカバーします。
- サーバー監査を有効にすると、個々の監査設定に関係なく、データベースの監査がトリガーされます。
- データベース レベルで監査を有効にして、サーバー ポリシーとデータベース ポリシーの両方を同時に共存させることができます。
- 読み取り専用レプリカでの監査は自動的に有効になります。
次のシナリオを除き、サーバー監査とデータベース監査の両方を一緒に有効にしないことをお勧めします。
特定のデータベースには、個別のストレージ アカウント、保有期間、または Log Analytics ワークスペースが必要です。
監査は、サーバー上の他とは異なる一意のイベントの種類またはカテゴリを持つ特定のデータベースに対して必要です。
それ以外の場合は、サーバー レベルの監査のみを有効にし、すべてのデータベースに対してデータベース レベルの監査を無効にしておくことをお勧めします。
SQL Database の既定の監査ポリシーには、次の一連のアクション グループが含まれています。
| アクション グループ | 定義 |
|---|---|
| バッチ完了グループ | データベースに対して実行されるすべてのクエリとストアド プロシージャを監査します。 |
| データベース認証成功グループ | これは、プリンシパルがデータベースへのログインに成功したことを示します。 |
| データベース認証グループの失敗 | これは、プリンシパルがデータベースへのログインに失敗したことを示します。 |
Azure SQL サーバー上のすべてのデータベースの監査を有効にするには、サーバーのメイン ブレードの [セキュリティ] セクションで [監査] を選択します。
![SQL サーバーの [セキュリティ] セクションの監査オプションのスクリーンショット。](../../wwl-data-ai/perform-post-migration-tasks-azure-sql/media/4-sql-auditing.png)
[監査] ページでは、監査ログの送信先を設定したり、Azure SQL 監査と同じログ宛先で Microsoft サポート エンジニアの操作を追跡するか、別のログを選択するかを選択したりできます。
![SQL サーバーの [監査] ページのスクリーンショット。](../../wwl-data-ai/perform-post-migration-tasks-azure-sql/media/4-audit-log-destination.png)
次のクエリを実行することで、Microsoft サポートの操作の監査ログを Log Analytics ワークスペースで確認できます。
AzureDiagnostics
| where Category == "DevOpsOperationsAudit"
重要
Azure SQL Database と Azure SQL Managed Instance の監査サービスは、最適な可用性とパフォーマンスを実現するために微調整されています。 ただし、非常に高いアクティビティまたは重大なネットワーク輻輳の条件下では、特定の監査イベントがログに記録されない可能性があります。
秘密度ラベルを監査する
データ分類と組み合わせることで、機密データへのアクセスを監視することもできます。 Azure SQL Auditing は拡張され、data_sensitivity_information という新しいフィールドが監査ログに追加されました。
このフィールドは、クエリによって返されるデータの秘密度ラベルをログに記録することで、分類された列へのアクセスを追跡する簡単な方法を提供します。
![Azure portal の [Information Protection] ページのスクリーンショット。](../../wwl-data-ai/perform-post-migration-tasks-azure-sql/media/4-sensitive-data.png)
監査は、データベース エンジンで発生するイベントの追跡と記録で構成されます。 Azure SQL 監査により、それを有効にするために必要な構成手順が簡略化され、SQL Database と SQL Managed Instance のデータベース アクティビティを追跡しやすくなります。
動的データマスキング
動的データ マスクは、 データの露出を制限するために難読化することによって機能します。 これにより、機密情報へのアクセスを必要としないユーザーは、列を表示できますが、実際のデータは表示できません。 動的データ マスクはプレゼンテーション レイヤーで機能し、マスクされていないデータは高い特権を持つユーザーに表示されます。
動的データ マスクは、アプリケーションまたはデータベースの変更を最小限に抑えるという利点を提供します。 Azure portal または T-SQL を使用して簡単に構成できます。
PhoneNumber 列と EmailAddress 列の両方が、テーブルに対するSELECT権限のみを持つ DDMDemo ユーザーには表示されません。 ユーザーは、列の最後の 4 桁以外のすべてを置き換える 部分関数 を使用してマスクされているため、電話番号の最後の 4 桁を表示できます。 このマスクはカスタム関数と見なされます。 T-SQL に加えて、Azure SQL Database を使用している場合は、Azure portal で動的マスク ルールを作成できます。
マスク ルールを追加するには、Azure portal でデータベースに移動し、データベースのメイン ブレードの [セキュリティ] セクションで [動的データ マスク] を選択します。
動的データ マスクでは、次のマスク パターンがサポートされていて使用できます。
| マスク関数 | 定義 | T-SQL の例 |
|---|---|---|
| デフォルト | 値のどの部分もユーザーに公開されないように、列のデータをマスクします。 ユーザーには、文字列値が 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 アクセス許可を明示的に付与する必要があります。
注
結果に基づく推論を使って、マスクされたデータを識別できます。 データ マスクを使っている場合は、ユーザーがアドホック クエリを実行する機能も制限する必要があります。
そのため、動的データ マスクを監査、暗号化、行レベルのセキュリティなどの他のセキュリティ機能と組み合わせて、機密データの保護を強化することをお勧めします。
利用事例
データ マスクはシンプルで軽量な機能であり、次のような多くのシナリオに最適です。
データベースに直接アクセスできないアプリケーション ユーザーからデータをマスクします。
ユーザーのグループに対して個人情報を制限します。
マスクされたデータを外部ベンダーに提供します。この場合は、機密情報を保護しながら、データ内の項目間のリレーションシップを維持する必要があります。
UNMASK権限を持たないユーザーを使用して、開発目的で運用データベースのコピーを低い環境にエクスポートします。 エクスポートされたデータはマスク形式です。
データのインポートとエクスポート
SELECT INTO または INSERT INTO を使って、マスクされた列のデータを別のテーブルにコピーすると、対象テーブルのデータはマスクされた状態になります。
UNMASK 権限のないユーザーが SQL Server のインポートとエクスポートを実行すると、エクスポートされたデータ ファイルにはマスクされたデータが含まれます。インポートされたデータベースには、非アクティブなマスクされたデータが含まれます。