Database Encryption and Key Management for PostgreSQL - Principles and Considerations

Copyright©2018 NTT Corp. All Rights Reserved.
Database Encryption and Key Management for
PostgreSQL - Principles and Considerations
NTT OSSセンタ
文仁誠・澤田雅彦
2018/11/22 PostgreSQL Conference Japan 2018

2Copyright©2018 NTT Corp. All Rights Reserved.
自己紹介
文仁誠 : Moon, Insung
PostgreSQL技術サポート
ツール開発
趣味 : ディズニー行くこと
澤田雅彦 : Masahiko Sawada
PostgreSQL本体開発
ツール開発
趣味：キーボード設計

• データベースを安全に扱う
• データベース暗号化
• 鍵管理
• PostgreSQLコミュニティの最新情報と
OSSセンタの取り組み
INDEX

• 本セッションは、PostgreSQLをよりセキュアに使用する
ためのノウハウを解説するものです
• 実際にセキュリティ機能をご検討の際は、セキュリティ
を専門とする会社、組織に必ずご相談ください
はじめに

• 権限のあるユーザの不正利用
• SQLインジェクション
• ストレージメディアの盗難
• クライアント⇔サーバ通信の盗聴
• DoS攻撃
など
システム全体におけるデータベースの脅威
DB管理者
システム
管理者
アプリケーション
データベース
通信の盗聴
SQL
インジェク
ション
ディスク
盗難
悪意のある
DB管理者
不正
アクセス

データベースの脅威
暗号化
機密性の高いデータ
を保護
アクセス制御
ユーザの適切な権限
を与える
監査
不正な操作を検知/通知

• データベース内からの不正参照
• 特権ユーザによる暗号鍵の不正使用
• データベース外からの不正参照
• 共有メモリの不正参照
• 更新ログの不正参照
• バックアップファイルの不正参照
• 物理的な盗難
• DBデータの盗難
• 更新ログの盗難
• バックアップの盗難
暗号化でデータベースを脅威から守る

• 暗号化と鍵管理は常にセットで考える必要がある
• ✖「暗号鍵をなくすといけないので、同じディスクに入
れてあります」
• 暗号化を行うときは、暗号鍵を安全かつ堅牢に管理する
必要がある
暗号化と鍵管理

データベース暗号化
脅威・性能・アプリケーション対応の要否

• 現在PostgreSQLのデータを暗号化する方法は色々ある
PostgreSQLのデータ暗号化
PostgreSQLが提供する暗号化ツール
OSが提供するハードディスクの暗号化
PostgreSQLのデータの暗号化には色々なものあり、
具体的に暗号化する方法が異なる。
PostgreSQLのデータを暗号化において、何を考えなければならないか？
PostgreSQLベンダが提供する暗号化ツール

データの暗号化のために考えること
脅威に対応
暗号化による性能のオーバーヘッド
アプリケーションの対応
調査した主な暗号化ツール
pgcrypto
dm-crypt
TDE for PG
PowerGres Plus

脅威への対応について

脅威のモデル化
• データベースの暗号化に関連する脅威は大きく３つ
• データベース内からの不正参照は、暗号鍵を守る必要があり、データベース
暗号化では防げない
• 「鍵管理」のところで説明します
• 暗号化処理を行う”層”で、対応できる脅威が異なる
脅威の種類想定される脅威
データベース内からの不正参照特権ユーザによる暗号鍵の不正使用
データベース外からの不正参照更新ログの不正参照
バックアップファイルの不正参照
共有メモリの不正参照
物理的な盗難
DBサーバ用ディスクの物理的な盗難
更新ログ用ディスクの物理的な盗難
バックアップ用ディスクの物理的な盗難

PostgreSQLのデータ処理層
エグゼキューター
共有バッファ
ストレージマネージャ
OS
ディスク
処理リソース凡例
ファイル
Postgre
SQL
OS
実行計画に従って処理する層。
テーブル等のデータは共有バッ
ファから取得する
共有バッファと、
ファイル間のデータのやりとり
を制御する層
ストレージマネージャから
呼ばれるOS以下のI/O処理の層
・・・・・・
・・・・・・
・・・・・・

• 下位の層へは暗号化されたデータが渡される
• 共有バッファ、ファイル、ディスクのデータは暗号化された状態
エグゼキューター層での暗号化処理
共有バッファ
OS
ディスク
ファイル暗号化済み
暗号化済み
暗号化済み
pgcrypto
TDE for PG
暗号化ツールの例
暗号化処理対応する脅威
脅威対応
データベース外からの不正参照
〇
物理的な盗難 ○

• ファイル、ディスクのデータは暗号化された状態
• 共有バッファのデータは暗号化されない(平文)
ストレージマネージャ層での暗号化処理
共有バッファ
OS
ディスク
ファイル暗号化済み
暗号化済み
平文
PowerGres Plus
暗号化処理
脅威対応
データベース外からの不正参照 △
メモリダンプによる
情報漏洩は防げない
対応する脅威

• ディスク上のデータのみが暗号化された状態
• ファイルと共有バッファのデータは暗号化されない
OS層での暗号化処理
共有バッファ
OS
ディスク
ファイル
暗号化状態
平文
平文
dm-crypt暗号化処理
対応する脅威
脅威対応
データベース外からの不正参照
✖

暗号化処理層と脅威に対応するモデル
暗号化ツール
pgcrypto TDEforPG PowerGres Plus dm-crypt
暗号化処理層エクゼキューターストレージマ
ネージャ
OS
脅
威
の
種
類
データベース外
からの不正参照
○ ○ △
メモリダンプによる情報
漏洩は防げない
✖
物理的な盗難 ○ ○ ○ ○
• 暗号化処理層によって脅威への対応が異なる
• 上位層で処理するほど脅威への抵抗力がある

性能との関係

• データを取得する際に、最小限の範囲で暗号化処理を
実行すると、無駄な部分の暗号化処理が少なくなる
暗号化と性能の関係ー暗号化範囲
user_num user_name card_num card_valid_thru
001 佐藤 1234-2345-3456-4567 02/21
002 鈴木 2345-3456-4567-5678 08/20
003 高橋 3456-4567-5678-6789 12/19
004 田中 4567-5678-6789-7980 09/22
005 渡辺 5678-6789-7890-8901 06/20
暗号化が必要な部分
暗号化が必要ではない部分
クレジットカード番号を持つテーブル

• 暗号化が必要なデータだけを暗号化すべき
• なるべく小さい単位で暗号化を指定できると良い
• PostgreSQLでは5つの階層に分けられる
暗号化範囲と性能の関係
データベースクラスタ
データベース
表空間
表
列

• PostgreSQLでは、ファイルから読み込んだデータを共有バッファに記
録した後、エグゼキューターが共有バッファのデータを使用する
• 共有バッファにデータがある場合、共有バッファとエグゼキューターの間
のみで処理する
⇒同一の暗号化データに何度もアクセスする場合、共有バッファが復号さ
れていれば復号処理は1度で済む
暗号化の処理層と性能の関係
共有バッファ
OS
ディスク
ファイル
発生頻度多
発生頻度少

• 暗号化範囲と暗号化の処理層に応じて、暗号化処理の性
能への影響が異なる
暗号化の処理層と性能の関係
暗号化範囲暗号化を行う処理層
暗
号
化
/
復
号
処
理
の
回
数
が
少
な
く
な
る
データベースクラスタ
データベース
表空間
表
列
共有バッファ
OS
ディスク
ファイル

• オーバーヘッドを最も小さくする組み合わせは、
• 暗号化範囲 = 列
• 暗号化処理層 = OS
である。
• しかし、実現性やPostgreSQLのアーキテクチャを考慮し、既存製品は
• 暗号化範囲 = 列
• 暗号化処理層 = エグゼキューター
あるいは
• 暗号化範囲 = 表・表空間・データベース・データベースクラスタ
• 暗号化処理層 = ストレージマネージャ
で開発されている
暗号化性能の組み合わせ

• 暗号化処理層と暗号化範囲によって性能特性が異なる
暗号化処理層と性能のまとめ
暗号化範囲
列表表空間データベースデータベース
クラスタ
暗号化の処理層エグゼキュータストレージ
マネージャ
ストレージ
マネージャ
ストレージ
マネージャ
OS
暗号化ツール・pgcrypto
・TDEforPG
ー
PowerGres Plus
ー
dm-crypt
性能オーバー
ヘッド
大中中中小
※性能オーバーヘッドは暗号化処理層をベースに相対的に評価しています
暗号化の必要がないデータへアクセスする場合は、評価が逆転します。

• 暗号化処理層と暗号化範囲によって性能特性が異なる
• 「性能」と「脅威への対応」のトレードオフがある
性能と脅威
暗号化範囲
クラスタ
マネージャ
ストレージ
マネージャ
ストレージ
マネージャ
OS
・TDEforPG
ー
PowerGres Plus
ー
dm-crypt
性能オーバー
ヘッド
大中中中小
からの不正参照 ○
△
△
△
✖
物理的な盗難 ○ ○ ○ ○ ○

アプリケーション対応の要否

• 暗号化に対応するためアプリケーションで対応する必要
がある場合
• 例えばpgcryptoではクエリの修正が必要となる
アプリケーションでの対応
SELECT card_number FROM users;
SELECT pg_decrypt (card_number, ‘secret key’) FROM users;

• 既存のアプリケーションコードに記述されたクエリの中で暗
号化対応する必要があるクエリを探す
• 巨大なアプリケーションである場合、暗号化対応する必要があ
るクエリを探すことに時間とコストがかかる
• 暗号化対応する必要があるクエリを探した後、クエリを変更
する
• 多くのクエリを変更することは時間とコストがかかる
• アプリケーションのコードを変更した後、修正による影響を
確認する回帰テストを行う
• テストの実行、確認に時間とコストがかかる
アプリケーション対応の難しさ
これを解決できる方法はTransparent Data Encryption(TDE)

• 透過的データ暗号化（TDE）とは？
• ユーザが暗号化を意識せずに暗号化が出来る機能
• アプリケーションの修正を最小限に抑えることができる
透過的データ暗号化（TDE）
データベース
lai1o71;&
61%k17yb
17rkhaai6b
INSERT INTO hoge
VALUES(‘Hello World’);
データベース”内”で
暗号化/復号

• 暗号化によるアプリケーション対応は時間とコストがか
かる
• TDEを利用することでコストを削減できる
• 現在使用可能なPostgreSQLのTDEに対応した暗号化
ツールの例
アプリケーション対応の関連まとめ
TDE for PG PowerGres Plus

まとめ

データベース暗号化まとめ
• 暗号化を行う処理層によって対応できる脅威が異なる
• 暗号化の範囲と処理層には関連性がある（実現性など）
• TDEを利用すると、アプリケーションの暗号化対応のコストが小さ
くなる
暗号化範囲
クラスタ
マネージャ
ストレージ
マネージャ
ストレージ
マネージャ
OS
・TDEforPG(TDE) ー
PowerGres Plus
(TDE)
ー
dm-crypt
(TDE)
性能オーバー
ヘッド
大中中中小
からの不正参照 ○
△
△
△
✖
物理的な盗難 ○ ○ ○ ○ ○

鍵管理

• データを暗号化する際に使用する鍵を管理すること
• 鍵が漏れてしまうと、暗号化された情報も一緒に漏れる
• 鍵管理をきちんとしていない場合に発生する脅威は何か
鍵管理とは
脅威対応策
鍵の漏洩
鍵管理サーバの利用
鍵の紛失
同一の暗号鍵を適切な利用期間を超えて使用し続
ける鍵ローテーション
漏えい等の問題が疑われる暗号鍵を使い続ける
鍵管理に関する脅威と対応策

• PCI-DSS(クレジットカード業者のセキュリティ規約)
では鍵管理についても規定
鍵管理についての要件
3.5（鍵管理について)
・鍵暗号化鍵がデータ暗号化鍵とは別に保存されている
・鍵の保存場所と形式を最小限にし、安全に保存する
3.6.5（鍵の取り換えについて)
・鍵の整合性が脆弱になったときの鍵の破棄または取り替え
・侵害されたことがわかっているまたは疑われる鍵の取り替え

• 鍵をデータベースと別の場所で管理
• 鍵を暗号化して同じ場所で保管する場合
→鍵の暗号化に使った鍵も安全に管理する必要がある
鍵の漏洩、紛失を防ぐ
データベースデータベース
とは別の場所
鍵のやり取り

• データベースとは別の場所で暗号化に使用する鍵を管理するシス
テム
• 鍵の管理、鍵の作成、鍵の有効化、鍵の無効化を担当する
• クラウドサービスやハードウェアの形式で提供される
鍵管理システム(KMS)とは
データベース KMS

• ナイーブな鍵ローテーション(取り換え)
• 問題点
データのサイズに応じて時間がかかる→運用上の制約になる
鍵ローテーションの方法
データベース
（暗号化済）
既存の鍵
全てのデータを復号
データ量に応じて時間がかかる
↓
２層の鍵管理で解決
データベース
（平文）
データベース
（平文）
新しい鍵
全てのデータを暗号化
データベース
（新しい鍵で暗号化済）
Step1) 既存の鍵を使用してデータを復号
Step2) 新しい鍵を使用してデータを暗号化

• 暗号化に使用する鍵を２つに分離
１）データを暗号化する「データ鍵」
２）データ鍵を暗号化する「マスター鍵」
• マスター鍵でデータ鍵を復号して、そのデータ鍵でデータベースのデータ
を復号する(2層化する)
２層の鍵管理とは
データベース全体を再暗号化することなく、
新しいマスタ鍵でデータ鍵のみを再暗号化することで、鍵ローテーションの時間を短縮できる
データ
マスター鍵
データ鍵(平文)
データ鍵(暗号化)
データ鍵復号
データ暗号化/復号
鍵管理サーバ
データベースサーバ

• 鍵に対する脅威に対策する
• DBとは別の場所で厳重に管理→KMSを使用
• 鍵は定期的に交換（ローテーション）する
• 鍵ローテーションを考慮して暗号化方式を選択する
• 1層の暗号化は構造が単純だがローテーションに時間がかかる
• 2層の鍵管理は複雑になるがローテーション時間は短い
鍵管理まとめ

PostgreSQLコミュニティの状況と
OSSセンタでの取り組み

• PostgreSQL 9.5
• 行レベルセキュリティ（RLS）
• PostgreSQL 9.6
• デフォルトロール
• PostgreSQL 10
• SCRAM
• PostgreSQL 11
• SCRAM、デフォルトロールの強化
暗号化機能については、
データベースクラスタ全体の
透過的暗号化機能が提案されているが、
あまり進展がない
セキュリティ機能強化はトレンドの一つ

NTT OSSセンタでは、
透過的暗号化機能のPostgreSQL本体導入に向けて開発を進めています
暗号化機能導入に向けて
PGCon 2018 Unconferenceにて (文)
開発コミュニティへの提案
[Proposal] Transparent Data Encryption
and Key Management Service

作成中の透過的暗号化機能
テーブル
スペース単位
の暗号化
ストレージ
マネージャ
での暗号化
×
KMS-A
KMS-B
■暗号化方式
■鍵管理サーバとの連携
×
※
様々な鍵管理サー
ビス/サーバと連
携するために、汎
用的なインタフェ
ースを用意
透過的
暗号化の対応

まとめ

• ”データベース暗号化”でも様々な方式(製品)がある
• 対応出来る脅威
• 性能特性
• TDE対応の有無
• 特性を見極めた上で方式(製品)を選択する
• 暗号化だけでは全てを守れない
• 暗号化と鍵管理はセットで考える
• 鍵は専用のサーバ、サービスで管理することが理想
暗号化と鍵管理

• PowerGres 公式マニュアル
• https://powergres.sraoss.co.jp/manual/V96/linux/
• 富士通の技術者に聞く!PostgreSQL最新技術
情報漏えいに備えよ！PostgreSQLで透過的暗号化を実現
• http://www.fujitsu.com/jp/products/software/resources/feature-
stories/201510encryption/index.html
• tdeforpg (github)
• https://github.com/nec-postgres/tdeforpg
• Transparent Data Encryption for PostgreSQL
• https://jpn.nec.com/tdeforpg/index.html
参考資料

THANK YOU

Database Encryption and Key Management for PostgreSQL - Principles and Considerations

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Database Encryption and Key Management for PostgreSQL - Principles and Considerations

Similar to Database Encryption and Key Management for PostgreSQL - Principles and Considerations (20)

More from Masahiko Sawada

More from Masahiko Sawada (20)

Database Encryption and Key Management for PostgreSQL - Principles and Considerations