こんにちは。
株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（@moomooya）です。
ラクスの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「技術推進プロジェクト」というプロジェクトがあります。
このプロジェクトで「DBセキュリティ」にまつわる検証を進めているので、その中間報告を共有しようかと思います。
本記事における「DBセキュリティ」とは
カバーする範囲
本稿で扱う「DBセキュリティ」については入室管理、アカウント管理、権限管理、データ暗号化、アクセス監視といった部分を対象とし、中でも技術的な検証が必要になるデータ暗号化について検証を進めていきます。
これらは個人情報の保護に関する法律についてのガイドライン（通則編）にて10-6 技術的安全管理措置として記述されています。
カバーしない範囲
「DBセキュリティ」の範囲として定義した通り、ウェブアプリケーション経由のセキュリティは扱いません。 なのでDBMSへの通常アクセスによるセキュリティに関しては対象外とします。
DB暗号化方式は大きく分けて3つ
暗号化の強度としては以下の
- ディスク暗号化
- 透過的暗号化
- アプリケーションでの暗号化
の順に強くなっていきます。
OS機能によるディスク暗号化
こちらはDB内のデータを暗号化するのではなく、DBのデータを保持しているディスク自体を暗号化するものになります。
こちらはOSレベルで提供される機能を用いてディスクの暗号化を行います。
ディスク暗号化ではDBサーバーからのディスク窃取への対策となります。一方、DBサーバーのOSにログインを許してしまうと暗号化の効果はありません。
弊社ではRHEL系OSの利用が多いので、今回の検証ではLUKSを用いる予定です。
DB機能による暗号化（透過的暗号化）
DBMS自体もしくは、DBMSへのプラグインによってDB内にデータ格納時に暗号化する方式です。
透過的暗号化方式（TDE）が該当します。
透過的暗号化ではディスク窃取に加えて、DBMSが書き込むデータファイルの窃取にも対応します。ただし、DBMS自体へのログインを許すと復号されたデータが閲覧可能になってしまいます。
弊社ではPostgreSQLを利用することが多いのですが、PostgreSQLには標準で組み込まれた透過的暗号化機能はありません。そのため、NEC製のTransparent Data Encryption for PostgreSQL(TDEforPG)をPostgreSQLに組み込んで利用する予定です1。
アプリケーションによる暗号化
こちらはアプリケーションの機能として暗号化処理を実装する形式になります。そのためDBに渡されるのはすでに暗号化したデータであり、使用するDBに左右されない方式となります。
アプリケーションで暗号化した場合には、DBMSにログインされた場合でもデータは暗号化されたままなので閲覧できません。アプリケーションを経由したアクセスでなければ復号したデータは見れません。
PostgreSQLでは暗号化ライブラリとしてpgcryptoが用意されているのでこちらを利用して検証を行います。
これらの方式の詳細は少し古い記事になりますが、@ITにて連載されていたこちらのコラムの2ページ目の表がわかりやすくまとまっています。
「アプリケーションによる暗号化」が最も強いなら
暗号化の強度とカバー範囲だけを考えると、アプリケーションによる暗号化が最も強いですが、DBとのデータ入出力処理を実装する都度、暗号化／復号化の処理を通さなければなりません。
品質管理の観点からもアプリケーション機能の実装数は少ない方が品質維持が容易になるので、DBもしくはOSに任せられる処理は任せた方が無難です。
理想的なデータ暗号化の想定としては
- データ全体の暗号化はディスク暗号化もしくは透過的暗号化で対応
- マイナンバーやクレジットカード番号などの特に機微な情報に限ってアプリケーションでも暗号化
という組み合わせパターンが理想形だと想定しています。
DB暗号化を導入する際の懸念点
最大の懸念は性能面
今回の検証でデータ暗号化をテーマにした理由にもなりますが、データを暗号化する場合はDBにデータを格納するたびに暗号化処理が実行されます。そのためDBへのIO性能が確実に低下しますが、どの程度低下するかはサーバー性能やデータ特性などに影響を受けるため、一概に何%低下するとは単純に語れません。
また、列レベルで暗号化する場合には列によってはインデックスが効かなくなる、といった副作用も想像できますし、暗号化方式によってはdump/restore時に影響が出ないかも心配です。
そのため今回の検証では、影響がありそうだと想定される状況ごとに実際の性能劣化度合いがどの程度なのかを計測していくことを中心に計画しています。
もちろん理想の結果としては、処理性能の劣化が無視できる程度であることですがそれは実際に試さないとわかりません……。
検証する環境や条件
検証環境
各環境のベースにはAWSの定常パフォーマンス環境のm4.xlargeを用いる予定で、検証環境のバリエーションとしては以下を用意しようと考えています。
- 暗号化なし環境
- ディスク暗号化（LUKS）環境
- 透過的暗号化（TDEforPG）環境
- アプリ暗号化（pgcrypto）環境
- ディスク暗号化＋透過的暗号化（LUKS + TDEforPG）環境
また、検証スケジュールに余裕があればAWSのRDSにてTDEオプションがあるようなので、こちらのON/OFFの違いも参考値として計測したいと考えています。
検証内容
実際のアプリケーションの動作や、運用を想定した動作について計測予定です。
- ウェブアプリケーションを想定したクエリ
- SELECT
- JOINあり / なし
- サブクエリあり / なし
- インデックススキャン / フルスキャン
- INSERT
- DELETE
- UPDATE
- SELECT
- dump / restore速度
- DB同期速度
なおDB同期速度については、正攻法で検証するのであれば各検証環境を2台ずつ用意しないといけないと思うのですが、なんとかもう少し楽に検証できないか検討しています。
次回予告
さて今回はDBセキュリティの概要と、導入時に懸念される項目を検証するための計画を立てる話でした。
今後この計画に沿って環境の構築と検証を進めていきます。次回は計測結果をもとにした現実的なDB暗号化プランの検討をしていきたいと思います。
次回記事の投稿は少し先になりますが、2024年3月頃を予定しています。投稿する際には本記事からもリンクを張っておきます。
※追記：書きました
参考
- 商用ソフトウェアのためTDEforPGに関する具体的な性能測定結果は公開を差し控える可能性があります。↩
