Always Encrypted 登場!(後編) (1/2):EnterpriseZine(エンタープライズジン)
Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

Always Encrypted 登場!(後編)

2016/05/10 06:00

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

サンプルアプリケーション

 サンプルアプリケーションは、引数としてnameを1つ取って下記のテーブルに対してクエリを実行し、該当レコードを表示するという、とても単純なアプリケーションとなります。

表1) customers テーブルのデータ
表1) customers テーブルのデータ

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

図1) 実行イメージ
図1) 実行イメージ

 ……えっと、まあ、なんというか、アレな感じですが、普段コード書かない仕事なので、今回はこれくらいで勘弁してください(涙)。

 動作としては、上記のようなとても簡素ですが、移行シナリオの都合上、きちんと以下のことは実装しています。

 1) 引数をSqlParameterとしてバインドしている

 2) 接続文字列はConfigurationファイルから読み込んでいる

 さて、サンプルアプリケーションについて説明したところで、早速Always Encrypted対応を進めていきます。

暗号化するカラムと暗号化の方式を考える

 Always Encryptedでは、下記の表のように2種類の暗号化の方式をサポートしています。前述のとおり、customersテーブルは、3つのカラムを持っていますので、これらのカラムの内、どのカラムをどの方式で暗号化するか検討します。

表2) サポートする暗号化方法
表2) サポートする暗号化方法

 Randomized encryptionの方が、より安全ということになりますが、検索条件としては使用できないので、適用するカラムを選ぶ必要があります。

 今回のサンプルアプリケーションでは、nameカラムを検索条件としているので、必然的にnameカラムの暗号化方式はDeterministic encryptionになります。cardnumberカラムについては、どっちでもいいのですが、まあ、折角なのでRandomized encryptionを選ぶことにします。

 さて、既存のアプリケーションである以上、すでにテーブルも存在しており、データを保持した状態です。この状態から、直接ALTER TABLE等でAlways Encryptedに対応したテーブルに変更はできません。SQL ServerはCMKにアクセスできないので、CEKを使用してデータを暗号化できないですからね。

 ということで、一旦、別の名前でテーブルを作りましょう。こんな感じで、nameカラムとcardnumber カラムをCEKを使用して暗号化カラムとして指定します。

図2) テーブル作成クエリ
図2) テーブル作成クエリ

※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 本間崇(ホンマタカシ)

     日本マイクロソフト株式会社  プレミアフィールドエンジニアリング  プレミアフィールドエンジニア  2001年5月にMicrosoftに入社以来、2015年5月までサポート部門で、サポートエスカレーションエンジニアとして勤務していました。現在は、プレミアフィールドエンジニアとして、密...

バックナンバー

連載:ここから始めよう SQL Server 2016 新機能

もっと読む

All contents copyright © 2007-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5