データを保護する
ネットワークと ID アクセスが構成され、セキュリティで保護されたので、データを保護する方法を考えていきましょう。保存されているものであるか、移動中であるか、またはユーザーと管理者が参照しているものであるかは関係ありません。
データの暗号化
Azure SQL Database によって暗号化された接続が強制され、必要に応じて、受信トランスポート層セキュリティ (TLS) の必要な最小バージョン (1.0 以降、1.1 以降、または 1.2 以降) を追加で指定できます。 ベスト プラクティスとして、クライアントで暗号化を強制してサーバーのネゴシエーションを回避し、サーバー証明書を信頼しないようにすることをお勧めします。
透過的なデータ暗号化
Transparent Data Encryption (TDE) は、保存データを暗号化し、Azure SQL Database のすべての新しいデータベースに対して既定でオンになります。 次に示すように、Azure portal のスイッチを使って、すべてのデプロイ オプションに対してそれを構成できます。
サーバー レベルでは、サービス マネージド キーを使うか、または [カスタマー マネージド キー] オプションを使って Bring Your Own Key (BYOK) を使うこともできます。 既定では、Azure サービスがキーを管理します。 Azure によって、データベースを暗号化するためのキーが自動的に生成され、キーのローテーションが管理されます。 Azure portal でこれを行う方法について学習しましたが、Azure PowerShell、Azure CLI、Transact-SQL (T-SQL)、または REST API を使うこともできます。
TDE でのカスタマー マネージド キー
または、BYOK を使って、Azure キー コンテナーを活用することもできます。 カスタマー マネージド キーを使うと次のような利点があります。
- TDE 保護機能の使用と管理の完全かつ詳細な制御
- TDE 保護機能の使用の透過性
- 組織内でキーとデータの管理における職務の分離を実施することが可能
- キー コンテナー管理者は、キーのアクセス許可を取り消して、暗号化されたデータベースにアクセスできないようにすることができる
- AKV でのキーの一元管理
- AKV は Microsoft が暗号化キーを表示したり抽出したりできないように設計されているため、エンド カスタマーからの信頼が高まる
また、TDE のカスタマー マネージド キーでユーザー割り当てマネージド ID (UMI) を活用することもでき、次のような利点があります。
- サーバーまたはデータベースが作成される前であっても、ユーザー割り当てマネージド ID を作成し、キー コンテナーへのアクセスを許可することで、Azure SQL 論理サーバーにキー コンテナーへのアクセスを事前に認可できるようになります。
- TDE と CMK が有効になっている Azure SQL 論理サーバーを作成できます。
- 同じユーザー割り当てマネージド ID を複数のサーバーに割り当てることができるので、Azure SQL 論理サーバーごとにシステム割り当てマネージド ID を個別に有効にして、キー コンテナーへのアクセスを提供する必要がなくなります。
- 利用できる組み込みの Azure ポリシーを使って、サーバーの作成時に CMK を適用できるようになります。
TDE を使用するカスタマー マネージド キーに、キーの自動ローテーションが導入されました。 有効にすると、サーバーは、TDE 保護機能として使われているキーの新しいバージョンを、キー コンテナーで継続的にチェックします。 新しいバージョンのキーが検出されると、サーバー上の TDE 保護機能が 60 分以内に最新のキー バージョンに自動的にローテーションされます。
Always Encrypted
SQL Server の場合と同様に、Azure SQL でサポートされている列レベルの暗号化を利用することもできます。 このプロセスには、データベース システムに与えられていないキーを使用する、機密データのクライアント側での暗号化の使用が含まれます。 さらに、クライアント ドライバーは、クエリ パラメーターを透過的に暗号化し、暗号化された結果を解読します。 現在は、決定論的暗号化によって、JOIN、GROUP BY、DISTINCT 演算子などの等値比較について、暗号化データでサポートされています。
セキュリティで保護されたエンクレーブが設定された Always Encrypted は、インプレース暗号化と豊富な機密クエリを有効にすることで、Always Encrypted の機密コンピューティング機能を拡張します。 セキュリティで保護されたエンクレーブを使用した Always Encrypted 機能は、現在 Azure SQL Database で使用できますが、Azure SQL Managed Instance ではまだサポートされていません。
動的なデータ マスキング
特定のデータをマスクまたは変更して、特権のないユーザーはそのデータを表示できないけれどもそれを含むクエリを実行することはできるようにしたい場合があります。 この機能は SQL Server の場合と同様にサポートされています。 一方で、Azure portal には、マスクが推奨されるフィールドを確認できる追加の機能とビューがあります。
データに氏名やメールアドレスなどの機密情報が含まれている例を見てみましょう。 Azure portal でそれらの列にマスクを適用するには、SQL データベースの構成ペインの [セキュリティ] で [動的データ マスキング] メニューを選ぶか、次の T-SQL コマンドを使います。
ALTER TABLE Data.Membership ALTER COLUMN FirstName
ADD MASKED WITH (FUNCTION = 'partial(1, "xxxxx", 1)')
ALTER TABLE Data.Membership ALTER COLUMN Email
ADD MASKED WITH (FUNCTION = 'email()')
ALTER TABLE Data.Membership ALTER COLUMN DiscountCode
ADD MASKED WITH (FUNCTION = 'random(1, 100)')
GRANT UNMASK to DataOfficers
上記のコマンドから、関数を使用してマスクを適用する方法が複数あることがわかります。
たとえば、一部のユーザーに DataOfficers などのロール (これは例であり、公式のロールではありません) が割り当てられている場合、彼らはマスクされたデータを表示できる必要がある場合もあります。 そのようなユーザーには、次の T-SQL コマンドを使って UNMASK 特権を付与できます。
GRANT UNMASK TO DataOfficers
誰がクエリを実行したかに応じて、結果は次のようになります。
動的データ マスキングのきめ細かいアクセス許可の導入により、データベース ユーザー、Microsoft Entra の ID、Microsoft Entra グループ、またはデータベース ロールに対して、データベース レベル、スキーマ レベル、テーブル レベル、または列レベルで、UNMASK アクセス許可の付与または取り消しを行うことができます。
データ保護のタスク
データ保護をセットアップして構成するには、次のことを行う必要があります。
- アプリケーションで接続の暗号化が強制されていることを確認し、アプリケーション、クライアント、ドライバーと互換性のある最高バージョンの TLS を使います。
- TDE を評価して有効にします。 これは新しいデータベースについては既定の設定ですが、移行した場合は有効にする必要がある場合があります。
- 動的データ マスクを利用します。
- 高度な保護を行う場合は、セキュリティで保護されたエンクレーブが設定された Always Encrypted 機能を構成できます。