こんにちは、日本マイクロソフト プレミアフィールド エンジニアの本間です。前編に引き続き、Always Encryptedについて紹介を続けていきます!後編では、予告した通り、既に作成してある簡単なサンプルアプリケーションとデータを、Always Encryptedに対応させる流れを見てみたいと思います。
サンプルアプリケーション
サンプルアプリケーションは、引数としてnameを1つ取って下記のテーブルに対してクエリを実行し、該当レコードを表示するという、とても単純なアプリケーションとなります。

.NET Framework 4.5.2を使用したコンソールアプリケーションで、実行すると以下のように素っ気なく、該当レコードを表示してくれます。

……えっと、まあ、なんというか、アレな感じですが、普段コード書かない仕事なので、今回はこれくらいで勘弁してください(涙)。
動作としては、上記のようなとても簡素ですが、移行シナリオの都合上、きちんと以下のことは実装しています。
1) 引数をSqlParameterとしてバインドしている
2) 接続文字列はConfigurationファイルから読み込んでいる
さて、サンプルアプリケーションについて説明したところで、早速Always Encrypted対応を進めていきます。
暗号化するカラムと暗号化の方式を考える
Always Encryptedでは、下記の表のように2種類の暗号化の方式をサポートしています。前述のとおり、customersテーブルは、3つのカラムを持っていますので、これらのカラムの内、どのカラムをどの方式で暗号化するか検討します。

Randomized encryptionの方が、より安全ということになりますが、検索条件としては使用できないので、適用するカラムを選ぶ必要があります。
今回のサンプルアプリケーションでは、nameカラムを検索条件としているので、必然的にnameカラムの暗号化方式はDeterministic encryptionになります。cardnumberカラムについては、どっちでもいいのですが、まあ、折角なのでRandomized encryptionを選ぶことにします。
さて、既存のアプリケーションである以上、すでにテーブルも存在しており、データを保持した状態です。この状態から、直接ALTER TABLE等でAlways Encryptedに対応したテーブルに変更はできません。SQL ServerはCMKにアクセスできないので、CEKを使用してデータを暗号化できないですからね。
ということで、一旦、別の名前でテーブルを作りましょう。こんな感じで、nameカラムとcardnumber カラムをCEKを使用して暗号化カラムとして指定します。

この記事は参考になりましたか?
- ここから始めよう SQL Server 2016 新機能連載記事一覧
-
- Always Encrypted 登場!(後編)
- Always Encrypted登場!(前編)
- クエリ ストア (後編)
- この記事の著者
-
本間崇(ホンマタカシ)
日本マイクロソフト株式会社
プレミアフィールドエンジニアリング
プレミアフィールドエンジニア 2001年5月にMicrosoftに入社以来、2015年5月までサポート部門で、サポートエスカレーションエンジニアとして勤務していました。現在は、プレミアフィールドエンジニアとして、密やか...※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア