Postgre SQL security_20170412

データベースセキュリティの基礎
Kazuki Omo( 　面和毅 ): ka-omo@sios.com
SIOS Technology, Inc.

2
Who am I ?
- Security Researcher/Engineer (16 years)
- SELinux/MAC Evangelist (11 years)
- Antivirus Engineer (3 years)
- SIEM Engineer (3 years)
- Linux Engineer (16 years)
OSS セキュリティ技術の会 (3 月発足 )
http://www.secureoss.jp/

3
アジェンダ
1. データベースセキュリティのガイドライン
2. OSS での実装を考える
2. 1 OS レベルでのセキュリティ実装を考える
2. 2 DBMS でのセキュリティ実装を考える
2.3 監査の実装を考える
3. まとめ

1. データベースセキュリティのガイドライン

5
DB のセキュリティ標準
DataBase Security Consortium
スタンダードについて色々やってます。

6
DB ガイドラインをにする内部不正対策参考

7
DB ガイドライン内部不正対策
4. 管理者の抑制
4.1 アクセス制御
4.2 認証方式
4.3 管理者の分掌
4.4 暗号化・鍵管理
4.5 DB 周辺デバイスの
管理

8
DB ガイドライン内部不正対策
5.1 ポリシーの制定
5.2 保全
5.3 監査・監視体制
5.4 監査の実施
5. 運用の実施

9
　　システムで出来ること
アクセス制御
● OS上のファイル・ディレクトリへのきっちりしたアクセス
権の設定
● DBA権限のきっちりした取扱い
● 各DBアカウントへの必要なだけの権限付与
● 機密情報へのアクセスの制限
認証方式
● パスワードポリシー
● 二因子認証(多要素認証)

10
　　システムで出来ること
暗号化・鍵管理
● DB暗号化やデータマスキング
● クエリ発行通路の暗号化
周辺デバイス
● ネットワークセグメントへのアクセス制限（ACL等）
● 物理コンソールの制限
● DB暗号化やデータマスキング

11
5. 運用の実施
システムで出来ること
保全
● アクセスログの収集・保全
監査
● 監査証跡のレポート
● アラートの出力
● ポリシーから外れた操作・アクセス履歴のログ
● 管理者アカウントの操作・アクセス履歴のログ
● セキュリティ設定の変更の取得

12
2. OSS でのをえる実装考

13
2. 1 OS/Software レベルでの
セキュリティをえる実装考

14
DB サーバのセキュリティ担保
4.1.2 ファイル、ディレクトリ
等のアクセス制限
さあ、 SELinux だ！

15
4. RHEL 7 / CentOS 7 上での MySQL
[root@cent7 services]# getenforce
Enforcing
[root@cent7 services]# ps axZ |grep mysql
system_u:system_r:mysqld_safe_t:s0 11998 ? Ss 0:00 /bin/sh /usr/bin/mysqld_safe
--basedir=/usr
system_u:system_r:mysqld_t:s0 12203 ? Sl 0:00 /usr/libexec/mysqld –basedir=/usr
--datadir=/var/lib/mysql …..
[root@cent7 services]# ls -lZ /etc/my.cnf
-rw-r--r--. root root system_u:object_r:mysqld_etc_t:s0 /etc/my.cnf
[root@cent7 services]# ls -lZ /usr/libexec/mysqld
-rwxr-xr-x. root root system_u:object_r:mysqld_exec_t:s0 /usr/libexec/mysqld

16
4. RHEL 7 / CentOS 7 上での PostgreSQL
[root@cent7 ~]# getenforce
Enforcing
[root@cent7 ~]# ps axZ|grep -i postgre
system_u:system_r:postgresql_t:s0 3483 ? S 0:00 /usr/bin/postgres -D /var/lib/pgsql/data
-p 5432
system_u:system_r:postgresql_t:s0 3484 ? Ss 0:00 postgres: logger process
system_u:system_r:postgresql_t:s0 3486 ? Ss 0:00 postgres: checkpointer process
system_u:system_r:postgresql_t:s0 3487 ? Ss 0:00 postgres: writer process
system_u:system_r:postgresql_t:s0 3488 ? Ss 0:00 postgres: wal writer process
system_u:system_r:postgresql_t:s0 3489 ? Ss 0:00 postgres: autovacuum launcher process
system_u:system_r:postgresql_t:s0 3490 ? Ss 0:00 postgres: stats collector process
[root@cent7 ~]# ls -lZ /usr/bin/postgres
-rwxr-xr-x. root root system_u:object_r:postgresql_exec_t:s0 /usr/bin/postgres
[root@cent7 ~]# ls -lZ /var/lib/pgsql/
drwx------. postgres postgres system_u:object_r:postgresql_db_t:s0 backups
drwx------. postgres postgres system_u:object_r:postgresql_db_t:s0 data

17
PostgreSQL 自身のセキュリティに気をつける

18
CVE-2016-5424 (2016/08/11)
PostgreSQL 9.1.23 未満
PostgreSQL 9.2.18 未満の 9.2.x
PostgreSQL におけるスーパーユーザ権限を取得される脆弱性
CVE-2016-0773 (2016/02/11)
PostgreSQL 9.1.20 未満
リモートからのサービス運用妨害 (DoS)

19
定期的に PostgreSQL の
サイトをチェックする

20
ディストリビューション提供のものを使っている場合にはディストリビューシ
エラータ情報（メール）などをチェックする

21
2. 2 DBMS でのセキュリティをえる実装考

22
じゃあ、は次 DBMS のセキュリティだ

23
それぞれのと項目実装
項目対策 MySQL PostgreSQL
4.1.1 DBA 権限の適切な
付与
管理者以外にDB管理者権限を付与しない ○ ○
4.1.3 一般利用者アカウ
ントのアクセス制限
業務上必要なデータのみへのアクセス権 ○ ○
4.1.4 管理者アカウント
のアクセス制限
DB管理者は必要なデータ以外へのアクセス
を制限
○ ○
4.1.5 カラム、テーブル
へのアカウント制限
カラム、テーブルごとにアクセスできるア
カウントを制限
○ ○
4.1.6 カラム、テーブ
ルへの属性制限
カラム、テーブルごとにアクセスできる
時間帯を制限
DBFW DBFW
4.2.5 システム利用アカ
ウント等の管理
ビルトインで不要なアカウントのロックア
ウト
○ ○
4.4.1 暗号化及び権限
の管理
データの暗号化・匿名化 ○ ○

24
それぞれのと項目実装 ( で設定実現 )
付与
を制限
○ ○
○ ○
時間帯を制限
DBFW DBFW
ウト
○ ○
の管理

25
それぞれのとが項目実装（機能必要）
付与
を制限
○ ○
○ ○
時間帯を制限
DBFW DBFW
ウト
○ ○
の管理

26
DB のセキュリティ
キーコンポーネント
● データの暗号化・匿名化
● SQL の細かな制御 (DBFW)

27

28
DB サーバをっててもアプリがけがあると守抜
( 例 ) SQL インジェクション
作りが甘いと、最新のパッケージにしても
データが見られる・抜かれる

29
DB サーバをっててもアプリがけがあると守抜
外部ユーザ
アプリの作りが甘いと、最新のパッ
ケージにしてもデータが見られる・抜
かれる
172.16.148.130
Demo

30
DB Firewall (SQL のかな文実行細制御 )
App
外部ユーザ
AllowBlock
● ホワイト / ブラックリスト方式選択可
能
● SQL 文法の解析
● オーバーヘッドを極力抑える
OSS: PostgreSQL 用 SQL ファイアーウォール「 sql_firewall 」
Nginx などの WAF でも最近は防げる
172.16.148.130
172.16.148.128

31
アプリをしてものものにがつかると対策別脆弱性見
( 例 ) Struts2 の脆弱性 (CVE-2017-5638)
SQL インジェクション対策をしていても、
Struts2 のゼロデイ脆弱性で、直接 SQL を
実行されてデータが見られる・抜かれる
Demo
データは平文だと困る

32

33
DB の暗号化
製品名アルゴリズム鍵サイズ
Oracle Advanced Security 12g Rel1 DES 168bits
AES(表領域Default) 128bits
AES(列レベルDefault) 192bits
AES 256bits
pgcrypto with OpenSSL DES 168bits
AES 256bits

34
DB の暗号化 ( 理想 )
DBMS_CRYPTO
pgcrypto
App
データ盗難
内部の不正者
HSM
長所
● 安全性が高い
短所
● アプリケーションに改修が必要
● 移行性が低下する
● 性能劣化の懸念
メモリ

35
DB の暗号化 (Transparent Data Encryption: TDE)
App
暗号化あり
暗号化無し
メモリ
暗号化 / 復号化
見えるので DB Firewall で防ぐ
内部の不正者
触れるので ACL で防ぐ
ACL
長所
● アプリケーションは改修不要
● 移行性の高い SQL
● 性能劣化は最小限（ DB が担当 )
● 鍵は DB 側で管理
短所
● 安全性の低下
(DB Firewall, ACL, 特権管理など
その他の機能／製品を
組み合わせて補う )
DBFirewall
参考： Oracle TDE

36
DB の暗号化 (File System とのい暗号化違 )
メモリ
OS ユーザからも
暗号化で見えない
メモリ
OS のユーザからは
平文で見える
内部ユーザの脅威
への対応
Struts2 など直接
SQL を実行された
時の対応
参考： Oracle TDE( 例 ) Struts2 の脆弱性 (CVE-2017-5638)

37
じゃあ、 Struts2 のでしてた脆弱性暗号化場合
( 例 ) Struts2 の脆弱性 (CVE-2017-5638)
Struts2 のゼロデイ脆弱性で、直接 SQL を
実行されてデータが見られる・抜かれるが
暗号化していた場合にはどうなるか
Demo
結局、データは極力暗号化しといたほうが良

38
でも DB しててもアプリがけがあると暗号化抜
外部ユーザ
アプリの作りが甘いと、暗号化してて
もデータが見られる・抜かれる
172.16.148.130
Demo

39
は結局
・インジェクションなどの対策だけでもダメ
・暗号化だけでもダメ
両方を組み合わせることで意味がある

40
2. 3 のをえる監査実装考

41
じゃあ、は次 DB のだ監査

42
DB/OS の監査
SIEM やフォレンジック製品と連動させる
・監査ログが確実に出るようにする（ OS 側の実装・設定）
・ SQL の実行元・実行内容などを細かく保存する
・ログなどは改変不可なように別筐体に入れる
モニタリングツール（外だし）の必要性
● DAM(Database Activity Monitoring)

43
DAM(Database Access Monitoring)
リアルタイムに、 SQL での全ての操作を検出し記録
● 複数 DB プラットフォームを横断する DB 管理者の活動をとら
ポリシー違反に対して警告
● SQL インジェクション攻撃も警告
● エージェント／情報収集サーバ構成
「誰が」「いつ」「どこから」「何に」「何を」

44
DAM(Database Access Monitoring)
44
App
外部ユーザ
システム管理者
監査ログ
● Oracle Database Firewall and Audit Vault
● IMPREVA SecureSphere Database Activity Monitor
… etc.
DBMS は監査ログがきちんと
出力されるようにする
( パフォーマンスと兼ね合い）

45
じゃあ、 OSS はないの？
MySQL: McAfee MySQL Audit Plugin
(https://github.com/mcafee/mysql-audit)
{"msg-type":"activity","date":"1480477660581","thread-id":"1","query-id":"0",
"user":"sios","priv_user":"sios","host":"router","ip":"172.16.148.1","cmd":
"Connect","query":"Connect"}
"show_grants","query":"SHOW GRANTS"}
"select","query":"SELECT

46
MySQL の CVE-2016-6662 の攻撃例
--snip--
000000000098280000000000004e03000000000000000000000000000001000000000000000
000000000000000") INTO DUMPFILE '/var/lib/mysql/mysql_hookandroot_lib.so'"}
{"msg-type":"activity","date":"1480484785741","thread-id":"2","query-
id":"25","user":"attackertest","priv_user":"attackertest","host":"router","ip":"172.16.148.1","cmd
":"insert","objects":
[{"db":"poctestdb","name":"poctable","obj_type":"TABLE"}],"query":"INSERT INTO `poctable`
VALUES('execute the trigger!')"}
":"select","query":"select "nn# 0ldSQL_MySQL_RCE_exploit got
here :)nn[mysqld]nmalloc_lib='/var/lib/mysql/mysql_hookandroot_lib.so'nn[abyss]n" INTO
void"}
":"select","query":"SELECT load_file('/etc/my.cnf')"}

47
じゃあ、 OSS はないの？
PostgreSQL: PGAudit
(http://pgaudit.org/)
AUDIT: OBJECT,1,1,READ,SELECT,TABLE,public.account,select password
from account
AUDIT: OBJECT,2,1,WRITE,UPDATE,TABLE,public.account,update account
set password = 'HASH2'
AUDIT: OBJECT,3,1,READ,SELECT,TABLE,public.account,select account.password,
account_role_map.role_id
from account
inner join account_role_map
on account.id = account_role_map.account_id
AUDIT: OBJECT,3,1,READ,SELECT,TABLE,public.account_role_map,select account.password,
account_role_map.role_id
from account
inner join account_role_map
on account.id = account_role_map.account_id

48
ログをめたらどうするか集
一般的には SIEM などの予兆検知ツール等と連動
可視化して、きちんとログを役立てる
Splunk
Arcsight

50
まとめ
ネットワーク／ OS レベルでもセキュリティを保つ
● 適切な設計・制御を行う／通信の暗号化は必須 !!
● SELinux は有効化しましょう！！
● ( 難しいだろうけれど ) パッケージは最新にしましょう。
● 適切な設計・制御を行う
● DB Firewall の導入を検討（ DAM 製品と通常一体化）
● 可能ならば重要なデータは暗号化を検討。
● モニタリングのための監査ログも検討（パフォーマンスと兼ね合い）。
● ログは集めたら可視化・ SIEM 等とも連動。取りっぱなしでは勿体無い
。

Postgre SQL security_20170412

More Related Content

What's hot

Similar to Postgre SQL security_20170412

More from Kazuki Omo

Postgre SQL security_20170412

Editor's Notes