実際の導入に際し、注意すべきポイント等を以下に記します。
- 確実なバックアップ
PDELで暗号化された情報はマップファイル・レシピファイルを紛失すると、復号不可能となります。必ず確実なバックアップを取得し、絶対に紛失しないでください。
- PDELで暗号化する情報と方式の検討
- ログイン用パスワード
PDELで暗号化すべき情報は、復号が求められる重要な情報です。ログイン用パスワードは重要な情報ですが、復号不要な情報のため、PDELで暗号化すべきではありません。(単純なSHA-1やMD5ではなくsaltを付与したほうが好ましいです。ハッシュ値の説明もご参考願います。)
- 固定暗号化方式
RDBでユニークキーが設定される可能性の高い情報(メールアドレス、端末識別番号等)は固定暗号化方式を採用すべきです。
- RDBユニークキーのバイト数制限
RDBによっては「ユニークキーを定義する列のサイズは255バイト以下でなくてはならない」等の制限があるので、注意してください。「ユニークキーに255バイト以下の制限があり、なおかつ、メールアドレスを暗号化したい」場合、「メールアドレスのSHA-1等のハッシュ値」および「ハッシュ値カウンタ」2列の組み合わせでユニークキーを定義し、「PDELで暗号化したメールアドレスを格納する列にはユニークキーを定義しない」方式で検討してください。ハッシュ値カウンタは通常は0ですが、重複時に1、2、…とカウントアップするイメージです。(もっとも、例えばRedmineで登録可能なメールアドレスの最大桁数は60です。開発するシステムによっては、このように割り切るのも一案です。)
- メールアドレスの大文字と小文字
PDELと無関係ですが、多くのメールサーバではメールアドレスの大文字と小文字を同一視します。「入会時やログイン時の存在チェック等で大文字小文字を区別するか?」も忘れずに検討してください。区別しないのなら「ハッシュ値算出やDB登録等は小文字化したメールアドレスをもとに行う」等が必要となります。
- 新規開発システムへの導入
新規開発案件の多くは、現行システムのリプレース(なんらかの機能追加を伴うリプレース)ではないでしょうか。ここではリプレースを前提に、導入時の注意点等を記します。
- データ移行
現行システムからの移行データに「暗号化したい情報」があれば、移行用バッチを作成せねばなりません。一般的には「業務系要件でのデータ移行と同時に暗号化する」方式だと思いますが「業務系移行要件が複雑な場合」「新規システムがパッケージをベースにしたシステムで、専用の移行ツールが準備されているが、移行ツール内でPDELを用いた暗号化が困難な場合」等は「業務系要件での移行完了後に、別途『暗号化パッチ』を実施する」という二段階の移行方式での対応が求められます。特に移行データが大量になる場合は、移行に要する時間等にも十分注意してください。
- トラフィック量
「現行システムはセッション変数を多用していたが、新システムではPDELを活用してセッション変数を極力控える」ような場合、トラフィック量が増大することになります。画像データや動画データ等に比べると微々たる量と思われますが、通信料金負担増をエンドユーザーに強いる可能性についても、必要に応じて注意してください。
- 稼動済みシステムへの導入
PDELを稼動済みシステムに導入し、それと同時にデータベース等で管理している重要な情報を暗号化する場合、様々な注意が必要です。メインとなる「アプリケーションの改修」「データ移行/データパッチ」以外に「現行システムへの影響調査」等も忘れずに行なってください。現行システムへの影響調査では、オンプレミスかつハード増強を行わない場合、例えば設計書に「当案件リリースに伴い、CPU使用率、メモリやディスクの使用量、ネットワークトラフィック、DBアクセス等が増大して、他のサービスや運用に悪影響を及ぼすことは無いと推測しています。その根拠として・・・(様々な調査結果に基づく仮説等)」と記すためには「どのような調査が必要か?」という視点で検討してください。(クラウドでは、現行システムの調査そのものが困難であったり、クラウドセンターの負荷がランダムになること等も予想されます。クラウドの制限としてユーザーの理解を求めることも、場合によっては検討してください。)
- MVCモデルへの導入
PDELをMVCモデルで実装されたシステムに導入する場合、暗号化・復号ともにMの機能としての実装を推奨します。暗号化については異論はないと思いますが「復号はVでも構わないのではないか?」という考えもできます。Mを推奨するのは「暗号化された情報を元の情報に復元したり、あるいはデータマスキングを行うという機能は、データに対する更新である」という考えからです。
MVCをMMVVCに細分化して考えてみます。MはSQL発行等のDBに直接アクセスする機能、Mは入力データチェックや入力値・DB情報等をもとに何らかの情報を算出するビジネスロジック、VはHTML等の固定部分を生成する機能、VはHTML等の可変部分を生成する機能です。ビューヘルパー等も含めVのプログラムは「前回ログイン日時をYYYY年MM月DD日 hh時mm分ss秒形式に編集する」「10桁の取引番号を1234-5678-90のように桁を区切って編集する」等のように、データの内容を変更することなく、適切な表示形式に変換する機能に限定すべきです。暗号化されたデータを復号したり、あるいはデータマスキングで置き換える、という機能をVに含めるべきではありません。DBから検索直後にMの機能として復号する方式を推奨します。(ORMを使用するフレームワークでは「モデルオブジェクトの暗号化されたデータの格納フィールド」を「復号で上書き」した後に「モデル保存を行う」と、DBまで更新されてしまうリスクに注意してください。ORMにバーチャルフィールド・バーチャルカラムの機能があれば、その活用を検討してください。)