適用対象:Azure SQL Database
このチュートリアルでは、セキュリティで保護されたエンクレーブが設定された Always Encrypted の使用を Azure SQL Database で開始する方法について説明します。 Intel Software Guard Extensions (Intel SGX) エンクレーブを使います。 次のことを示します。
- Intel SGX エンクレーブが設定された Always Encrypted をテストおよび評価するための環境を作成する方法。
- SQL Server Management Studio (SSMS) を使用して、データのインプレース暗号化を行い、暗号化された列に対して高度な機密クエリを実行する方法。
前提条件
- 有効な Azure サブスクリプション アカウントがない場合は、無料アカウントを作成してください。 リソースを作成して構成証明ポリシーを構成できるようにするには、サブスクリプションの共同作成者ロールまたは所有者ロールのメンバーである必要があります。
- 省略可能。ただし、Always Encrypted: Azure Key Vault のキー コンテナーの列マスター キーを格納する場合に推奨されます。 キー コンテナーを作成する方法については、「クイックスタート: Azure portal を使用してキー コンテナーを作成する」を参照してください。
- キー コンテナーでアクセス ポリシーのアクセス許可モデルを使用する場合は、キー コンテナーに次のキーアクセス許可があることを確認します:
get
、list
、create
、unwrap key
、wrap key
、verify
、sign
。 詳細については、キー コンテナーへのアクセス ポリシーの割り当てに関するページを参照してください。 - Azure ロールベースのアクセス制御 (RBAC) アクセス許可モデルを使用している場合は、キー コンテナーの Key Vault Crypto Officer ロールのメンバーであることを確認してください。 「Azure のロールベースのアクセス制御を使用して Key Vault のキー、証明書、シークレットへのアクセス権を付与する」を参照してください。
- キー コンテナーでアクセス ポリシーのアクセス許可モデルを使用する場合は、キー コンテナーに次のキーアクセス許可があることを確認します:
- 最新バージョンの SQL Server Management Studio
PowerShell の要件
注
このセクションに記載されている前提条件は、このチュートリアルの一部の手順に PowerShell を使用する場合にのみ適用されます。 代わりに Azure portal の使用を予定している場合は、このセクションを省略できます。
Az PowerShell モジュール バージョン 9.3.0 以降が必要です。 Az PowerShell モジュールのインストール方法の詳細については、「Azure Az PowerShell モジュールのインストール」を参照してください。 お使いのマシンにインストールされている Az PowerShell モジュールのバージョンを確認するには、PowerShell から次のコマンドを実行します。
Get-InstalledModule -Name Az
手順 1: サーバーと DC シリーズ データベースを作成、構成する
この手順では、セキュア エンクレーブによる Always Encrypted に必要な DC シリーズのハードウェアを使用して、新しい Azure SQL Database 論理サーバーと新しいデータベースを作成します。 詳細については、DC シリーズに関するセクションをご覧ください。
[Select SQL deployment option](SQL デプロイ オプションの選択) ページを参照します。
まだ Azure portal にサインインしていない場合は、求められたらサインインします。
[SQL データベース] で、 [リソースの種類] を [単一データベース] に設定し、 [作成] を選択します。
[SQL データベースの作成] フォームの [基本] タブにある [プロジェクトの詳細] で、目的の Azure [サブスクリプション] を選択します。
[リソース グループ] の [新規作成] を選択し、リソース グループの名前を入力し、 [OK] を選択します。
[データベース名] に、「ContosoHR」と入力します。
[サーバー] で、 [新規作成] を選択し、 [新しいサーバー] フォームに次の値を入力します。
- [サーバー名] : 「mysqlserver」と入力し、一意にするためにいくつかの文字を追加します。 サーバー名は、サブスクリプション内で一意ではなく、Azure のすべてのサーバーに対してグローバルに一意である必要があるため、正確なサーバー名をここに示すことはできません。 mysqlserver135 のように入力してから、利用可能かどうかをポータルで確認できます。
-
[場所] :ドロップダウン リストから場所を選択します。
重要
DCシリーズのハードウェアとMicrosoft Azure Attestationの両方をサポートする場所(Azure リージョン)を選択する必要があります。 DC シリーズをサポートするリージョンの一覧については、DC シリーズの提供リージョンに関する記述を参照してください。 Microsoft Azure Attestation が提供されるリージョンは、こちらでご覧いただけます。
- [認証方法]: [SQL 認証を使用] を選びます。
- [サーバー管理者ログイン] : 管理者のログイン名を入力します (例: azureuser)。
- パスワード:要件を満たすパスワードを入力し、 [パスワードの確認入力] フィールドにもう一度入力します。
- [OK] を選択します。
[SQL エラスティック プールを使用しますか?] を [いいえ] に設定したままにします。
[コンピューティングとストレージ] で、[データベースの構成] を選択し、[構成の変更] を選択します。
[DC シリーズ] ハードウェア構成を選択し、 [OK] を選択します。
[適用] を選択します。
[基本] タブに戻り、 [コンピューティングとストレージ] が [General Purpose] 、 [DC、2 仮想コア、32 GB ストレージ] に設定されていることを確認します。
[バックアップ ストレージの冗長性] には [Locally-redundant backup storage] (ローカル冗長バックアップ ストレージ) を選びます。
ページの下部にある [Next: Networking](次へ: ネットワーク) を選択します。
[ネットワーク] タブの [接続方法] で、 [パブリック エンドポイント] を選択します。
[ファイアウォール規則] で、 [現在のクライアント IP アドレスを追加する] を [はい] に設定します。 [Azure サービスおよびリソースにこのサーバー グループへのアクセスを許可する] を [いいえ] に設定したままにします。
[接続ポリシー] の [接続ポリシー] は [Default - Uses Redirect policy for all client connections originating inside of Azure and Proxy for all client connections originating outside Azure] (既定 - Azure 内部で発生したすべてのクライアント接続にリダイレクト ポリシーを使用し、Azure 外部で発生したすべてのクライアント接続にプロキシを使用します) のままにします
[Encrypted connections] (暗号化された接続) の [Minimum TLS version] (最小 TLS バージョン) を [TLS 1.2] に設定したままにします。
ページ下部にある [確認と作成] を選択します。
[確認と作成] ページで、確認後、 [作成] を選択します。
手順 2:構成証明プロバイダーを構成する
この手順では、Microsoft Azure Attestation で構成証明プロバイダーを作成して構成します。 これは、データベースが使用するセキュア エンクレーブの構成証明を行うために必要となります。
[構成証明プロバイダーの作成] ページに移動します。
[Create attestation provider](構成証明プロバイダーの作成) ページで、次の情報を入力します。
- [サブスクリプション] : Azure SQL 論理サーバーを作成したのと同じサブスクリプションを選択します。
- [リソース グループ] : Azure SQL 論理サーバーで作成したのと同じリソース グループを選択します。
- [名前] : 「myattestprovider」と入力し、一意にするためにいくつか文字を追加します。 名前はグローバルに一意である必要があるため、正確な構成証明プロバイダー名を指定して使用することはできません。 そのため、myattestprovider12345 のように入力して、それが利用可能かどうかをポータルで確認できます。
- [場所]: Azure SQL 論理サーバーと同じ場所を選択します。
- [ポリシー署名者証明書ファイル]: 署名されていないポリシーを構成する場合は、このフィールドは空のままにします。
必要な情報を入力したら、 [確認と作成] を選択します。
[作成] を選択します。
構成証明プロバイダーが作成されたら、[リソースに移動] を選択します。
構成証明プロバイダーの [概要] タブで、Attest URI プロパティの値をクリップボードにコピーし、ファイルに保存します。 これは構成証明の URL です。後の手順で必要になります。
下部のペインまたはウィンドウの左側のリソース メニューで [ポリシー] を選択します。
[構成証明の種類] を [SGX-IntelSDK] に設定します。
上部のメニューにある [構成] を選択します。
[ポリシーの形式] を [テキスト] に 設定します。 [ポリシー オプション] は [ポリシーの入力] に設定されたままにします。
[ ポリシー] テキスト フィールドで、既定のポリシーを次のポリシーに置き換えます。 詳細については、「構成証明プロバイダーの作成と構成」を参照してください。
version= 1.0; authorizationrules { [ type=="x-ms-sgx-is-debuggable", value==false ] && [ type=="x-ms-sgx-product-id", value==4639 ] && [ type=="x-ms-sgx-svn", value>= 2 ] && [ type=="x-ms-sgx-mrsigner", value=="e31c9e505f37a58de09335075fc8591254313eb20bb1a27e5443cc450b6e33e5"] => permit(); };
[保存] を選択します。
上部のメニューにある [Refresh](最新の情報に更新) をクリックして、構成済みのポリシーを表示します
手順 3: データベースを設定する
この手順では、テーブルを作成し、後で暗号化してクエリを実行するデータを設定します。
SSMS を開き、データベース接続で Always Encrypted を有効にせずに、作成した Azure SQL 論理サーバーの ContosoHR データベースに接続します。
[サーバーに接続] ダイアログで、サーバーの完全修飾名 (例: myserver135.database.windows.net) を指定し、サーバーの作成時に指定した管理者のユーザー名とパスワードを入力します。
[オプション >>] を選択し、[接続プロパティ] タブを選択します。(既定の データベースではなく) 必ず
master
データベースを選択します。[Always Encrypted] タブを選択します。
[Always Encrypted を有効にする (列の暗号化)] チェック ボックスがオンになっていないことを確認します。
[接続] を選択します。
Employees
という名前の新しいテーブルを作成します。CREATE SCHEMA [HR]; GO CREATE TABLE [HR].[Employees] ( [EmployeeID] [int] IDENTITY(1,1) NOT NULL, [SSN] [char](11) NOT NULL, [FirstName] [nvarchar](50) NOT NULL, [LastName] [nvarchar](50) NOT NULL, [Salary] [money] NOT NULL ) ON [PRIMARY]; GO
Employees
テーブルにいくつかの従業員レコードを追加します。INSERT INTO [HR].[Employees] ([SSN] ,[FirstName] ,[LastName] ,[Salary]) VALUES ('795-73-9838' , N'Catherine' , N'Abel' , $31692); INSERT INTO [HR].[Employees] ([SSN] ,[FirstName] ,[LastName] ,[Salary]) VALUES ('990-00-6818' , N'Kim' , N'Abercrombie' , $55415);
手順 4:エンクレーブ対応キーをプロビジョニングする
この手順では、エンクレーブ計算を可能にする列マスター キーと列暗号化キーを作成します。
前の手順の SSMS インスタンスを使用し、オブジェクト エクスプローラーでデータベースを展開して、 [セキュリティ]>[Always Encrypted キー] に移動します。
エンクレーブ対応の列マスター キーをプロビジョニングします。
- [Always Encrypted キー] を右クリックし、 [新しい列マスター キー...] を選択します。
- 新しい列マスター キーの名前を入力します:
CMK1
。 - [エンクレーブ計算を許可する] が選択されていることを確認します。 (セキュリティで保護されたエンクレーブがデータベースに対して有効になっている場合は、既定でこれが選択されます。データベースでは DC シリーズ ハードウェア構成が使用されるため、有効にする必要があります)。
-
[Azure Key Vault] (推奨) または [Windows 証明書ストア] ([現在のユーザー] または [ローカル マシン]) を選択します。
- Azure Key Vault を選択した場合は、Azure にサインインし、使用するキー コンテナーを含む Azure サブスクリプションを選択し、キー コンテナーを選択します。 [キーの生成] を選択して、新しいキーを作成します。
- Windows 証明書ストアを選択した場合は、[証明書の生成] ボタンを選択して新しい証明書を作成します。
- [OK] を選択します。
新しいエンクレーブ対応の列暗号化キーを作成します。
- [Always Encrypted キー] を右クリックし、 [新しい列の暗号化キー] を選択します。
- 新しい列暗号化キーの名前を入力します:
CEK1
。 - [ 列マスター キー ] ドロップダウン リストで、前の手順で作成した列マスター キーを選択します。
- [OK] を選択します。
手順 5:一部の列のインプレース暗号化を行う
この手順では、サーバー側エンクレーブ内の SSN
列と Salary
列に格納されているデータを暗号化し、データに対する SELECT クエリをテストします。
新しい SSMS インスタンスを開き、データベース接続で Always Encrypted を有効にしてデータベースに接続します。
SSMS の新しいインスタンスを開始します。
[ サーバーへの接続 ] ダイアログで、サーバーの完全修飾名 (
<server name>.database.windows.net
など) を指定し、サーバーの作成時に指定した管理者ユーザー名とパスワードを入力します。[オプション >>] を選択し、[接続プロパティ] タブを選択します。(既定の データベースではなく) 必ず
master
データベースを選択します。[Always Encrypted] タブを選択します。
[Always Encrypted を有効にする (列の暗号化)] チェック ボックスをオンにします。
[Enable secure enclaves] (セキュリティで保護されたエンクレーブを有効にする) を選択します。 (この手順は SSMS 19 以降に適用されます。)
[プロトコル] を [Microsoft Azure Attestation] に設定します。 (この手順は SSMS 19 以降に適用されます。)
「手順 2: 構成証明プロバイダーを構成する」の手順に従って取得したエンクレーブ構成証明 URL を指定します。
[接続] を選択します。
Always Encrypted クエリのパラメーター化を有効にするよう求められたら、 [有効] を選択します。
同じ SSMS インスタンス (Always Encrypted が有効) を使用して、新しいクエリ ウィンドウを開き、次の T-SQL ステートメントを実行して
SSN
列とSalary
列を暗号化します。ALTER TABLE [HR].[Employees] ALTER COLUMN [SSN] [char] (11) COLLATE Latin1_General_BIN2 ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY = [CEK1], ENCRYPTION_TYPE = Randomized, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256') NOT NULL WITH (ONLINE = ON); ALTER TABLE [HR].[Employees] ALTER COLUMN [Salary] [money] ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY = [CEK1], ENCRYPTION_TYPE = Randomized, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256') NOT NULL WITH (ONLINE = ON); ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;
注
上記のスクリプトでデータベースのクエリ プラン キャッシュをクリアするには、
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE
ステートメントに注目してください。 テーブルを変更したら、テーブルにアクセスするすべてのバッチおよびストアド プロシージャのプランをクリアして、パラメーター暗号化情報を更新する必要があります。SSN
列とSalary
列が暗号化されたことを確認するには、データベース接続に対して Always Encrypted が有効になっていない SSMS インスタンスで新しいクエリ ウィンドウを開き、次のステートメントを実行します。 クエリ ウィンドウは、SSN
列とSalary
列で暗号化された値を返す必要があります。 Always Encrypted が有効な SSMS インスタンスを使用して同じクエリを実行した場合は、復号化されたデータが表示されます。SELECT * FROM [HR].[Employees];
手順 6:暗号化された列に対して高度なクエリを実行する
暗号化された列に対して高度なクエリを実行できます。 いくつかのクエリ処理は、サーバー側エンクレーブ内で実行されます。
Always Encrypted が有効になっている SSMS インスタンスで、Always Encrypted のパラメーター化も有効になっていることを確認します。
- SSMS のメイン メニューから [ツール] を選択します。
- [オプション...] を選択します。
- [クエリ実行]>[SQL Server]>[詳細] の順に移動します。
- [Always Encrypted のパラメーター化を有効にする] がオンであることを確認します。
- [OK] を選択します。
新しいクエリ ウィンドウを開き、次のクエリを貼り付けて実行します。 クエリでは、指定した検索条件を満たすプレーンテキスト値と行が返されます。
DECLARE @SSNPattern [char](11) = '%6818'; DECLARE @MinSalary [money] = $1000; SELECT * FROM [HR].[Employees] WHERE SSN LIKE @SSNPattern AND [Salary] >= @MinSalary;
Always Encrypted が有効になっていない SSMS インスタンスで同じクエリをもう一度試します。 エラーが発生します。
チュートリアル
このチュートリアルを完了すると、次のいずれかのチュートリアルに進むことができます。
- チュートリアル:セキュリティで保護されたエンクレーブが設定された Always Encrypted を使用する .NET アプリケーションの開発」をご覧ください。
- チュートリアル:セキュリティで保護されたエンクレーブが設定された Always Encrypted を使用する .NET Framework アプリケーションの開発
- チュートリアル:ランダム化された暗号化を使用してエンクレーブ対応の列でインデックスを作成して使用する