狠狠撸

? 2016 SIOS Technology, Inc. All rights Reserved.
2016年～2020年を見据えたデータセキュリティ
1
SIOS Technology
OSS エヴァンジェリスト
面　和毅

Agenda
1. クラウドサービスの普及
2. 2016年の脅威トレンドと分析
3. 求められるセキュリティ実装
4. データのセキュリティ
5. まとめ
Appendix. Red Hat Satellite

1. クラウドサービスの普及
3

クラウドサービスの普及
4
? 企業の基盤がクラウドサービスへと移行
国内PaaS市場セグメント別売上額予測、2014年～2019年
(参考) : IDC Japan, 12/2015
3. クラウドコア：
2016年には、国内企業のITインフラストラクチャおよび
ソフトウェア投資額の20％以上がクラウドベースになり、
2020年には30～40％に達すると予測される。
クラウドのIT基盤を欠いたままDXイニシアティブを
追求することは、まったく不可能になる。
(参考) IDC FutureScape：世界と国内のIT市場
2016 Predictions―デジタルトランスフォーメーションの規模拡大を牽引せよ

5
? クラウドサービスに企業の基盤が移行
クラウド完全移行／ハイブリッドクラウド
VM VM VM

6
? IoTがクラウドへの移行を後押し
VM VM VM

7
? 医療データもクラウドに
– 米国
●
2015年から、クラウド事業者が「HIPAA BAA（business
associate agreement）」に対して積極的に
– 発展途上国の医療活動 (Partners in Health)
●
Azure + Office365 (MS)
●
「組織を一体化して、現場の臨床医がテクノロジーにつ
いて心配しなくて済むよう、プラットフォームを1つに
する必要があった」
– 日本
●
医知の蔵(GEヘルスケア)

8
クラウドへのデータ移行がどんどん進む
セキュリティは大丈夫？

2. 2016年の脅威トレンドと分析
9

今後の脅威
10
? クラウドサービスに企業の基盤が移行していくと。。。
VM
1. 攻撃対象の均質化(FWはCloudベンダのみ)
2. ユーザの簡単な作成
3. VM層の脆弱性を通した他社への侵入
(VENOM: 2015年5月)
美味しい時代!!
VM VM
VM
VM VM

今後の脅威
? IoTの脆弱性利用
1. 踏み台が多くなる
2. DDoS攻撃なども簡単に
3. むしろこっそりIDを使ってCloudに入り込み内側から
美味しい時代!!
2015
Stagefright
XCodeGhost
.....
VM
VM VM
VM
VM VM

3. 求められるセキュリティ実装
12

求められるセキュリティ実装
13
守る側は
●
クラウドのタイプに合わせて対策を考える
1.SaaS
2.PaaS
3.IaaS
インフラ部分のセキュリティ設計?構築?運用は
自社の責任範疇
VM
VM VM
VM
VM VM

Cloud Security Alliance資料
クラウドコンピューティングのためのセキュリティガイダンス V3.0

クラウドベンダ選定
クラウド情報セキュリティ監査制度
JASA-クラウドセキュリティ推進協議会　(http://jcispa.jasa.jp/cloud_security/)
事業者が基本的な要件を満たす
情報セキュリティ対策を実施し、
事業者がそのとおりに実施して
いるかを標準的な基準に基づき
あらかじめ定められた要件を
満たす監査で評価し、
安全性が確保されていることを
顧客に公開する。

守る側は
●
クラウドのタイプに合わせて対策を考える
1.SaaS
2.PaaS
3.IaaS
インフラ部分のセキュリティ設計?構築?運用は
自社の責任範疇
VM
VM VM
VM
VM VM

情報管理とデータセキュリティアプリケーションセキュリティ
コンプライアンスと監査
インシデントレスポンス、
通知および復旧
暗号化と鍵管理
アイデンティティとアクセス管理
Security as a Service
VM
VM VM
VM
VM VM

4. データセキュリティ
18

利用できるサービス
IaaS
– Raw/ボリューム/オブジェクト　ストレージ
– ネットワーク
●
PaaS
– Database(Provider提供)
– オブジェクト/ファイル　ストレージ
– ボリュームストレージ
●
SaaS
– Database(Provider提供)
– オブジェクト/ファイル　ストレージ
– ボリュームストレージ
Providerによるセキュリティ確保

DBのセキュリティ
●
今までのIPS/FW/WAFなどは前提
– クラウドプロバイダで提供もある
– 資産管理?パッチ管理も重要(Red Hat Satellite等)
●
キーコンポーネント
– 暗号化
– モニタリング
●
DAM(Database Activity Monitoring)
●
FAM(File Activity Monitoring)

DBのセキュリティ
●
●
– 暗号化
●
●

DBの暗号化
22
? IaaS
– リスク
●
スナップショット悪用による複製
●
クラウドプロバイダの悪意のある管理者
●
物理ドライブ抜き取り
– ボリュームストレージ暗号化
– オブジェクトストレージ暗号化
– その他のレイヤでの暗号化（DBデータ暗号化)
通信の暗号化は大前提

DBの暗号化
23
? PaaS
– クライアント?アプリケーション暗号化
●
PaaSプラットフォームにアクセスする端末内で暗号化される
– データベース暗号化(プロバイダ提供)
●
暗号化機能がビルトインされたDB内で暗号化され、DBプラット
フォーム内でサポートを受ける
– プロキシ暗号化
●
PaaSに接続される前に暗号化プロキシで暗号化される
? SaaS
– プロバイダ管理暗号化
●
データはSaaSアプリケーション内で暗号化され、一般的にプロ
バイダによって管理される
IaaSで出たリスクは許容するしか無い

DBの暗号化
24
? DB内の暗号化が重要
●
標準のアルゴリズムを使用する
– 独自の暗号化アルゴリズムは簡単に破られる。
●
古い規格は避ける
– Data Encryption Standard (DES) 168 のような、安全でない規格は避ける。
●
オブジェクトセキュリティを使用する。
– 基本的なオブジェクトセキュリティ(SQL ステートメントの権限許可と取り消し)を使
用し、暗号化されたデータでさえもアクセスできないようにする。
●
主キーあるいは索引付きカラムを暗号化しない。
– もし主キーを暗号化すると、参照する外部キーもすべて暗号化しなければならない。
索引付きカラムを暗号化すれば、その値を使用する問合せ処理が遅くなる。

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

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

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

DBの暗号化
28
? File System暗号化との違い
メモリ
OSユーザからも
暗号化で見えない
メモリ
OSのユーザからは
平文で見える
内部ユーザの脅威
への対応
参考： Oracle TDE

DB Firewall
29
? DB Firewall
App
外部ユーザ
AllowBlock
● ホワイト/ブラックリスト方式選択可能
●
透過的に組み込み
● SQL文法の解析
●
オーバーヘッドを極力抑える
●
アクセスを全て受けるため、後述の
DAMと一緒になっている事が多い
● Oracle Database Firewall and Audit Vault
● IMPREVA SecureSphere Database Firewall
… etc.

データセキュリティ
●
●
– 暗号化
●
●

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

モニタリング
32
? DAM
App
外部ユーザ
● Oracle Database Firewall and Audit Vault
● IMPREVA SecureSphere Database Activity Monitor
… etc.
システム管理者
監査ログ

5. まとめ
33

2016年～2020年を見据えたデータセキュリティ
34
? クラウドにシステムが移行している事に留意
– クラウドプロバイダの選定に気をつける
– クラウドのタイプに合わせて対策を考える
? DBのセキュリティに気をつける
– 適切な設計?制御は必須
– 透過的暗号化
– DB Firewallでも制御
– DAM製品でDB管理者を含めたモニタリング
? 当然従来のセキュリティ製品を組み合わせることは必須！！
– Firewall/IPS/WAFなどを組み合わせた多層防御
– 各サーバのパッチ管理?運用管理(Red Hat Satellite等）

Appendix. Red Hat Satellite
35

36
適切なパッチ管理とリスク管理
? 脆弱性が公開されてから4時間程度で攻撃が増大
? パッチ適用が間に合わない（UTM製品?Reputation等で防ぐ）
? 再び脆弱性を探して利用する時代に戻ってきた
-> 日々のメンテナンス?パッチ管理が重要

37
『報告される脆弱性の大半は、修正策、回避方法、またはパッチが用意されています。
しかし、マルウェア作成者はこれらの更新を適用しない人が多くいることを知っています。
そのため、十分に立証された脆弱性であっても、攻撃に悪用することが可能です。』
（Symantec 「インターネットセキュリティ脅威レポート　2015年4月巻」)

38
脆弱性情報発見?報告日 RHEL対応日
OpenSSLの複数の脆弱
性
2015/12/05 2015/12/14
bind9の緊急の脆弱性 2015/12/16 2015/12/16
OpenSSHクライアントの
脆弱性
2016/01/14 2016/01/14
Linux kernelの脆弱性 2016/01/19 2016/01/25
? 緊急度合いに応じて、バグが報告されてから迅速に対応がされている
? 既存の脆弱性を塞ぐだけでも、かなりの攻撃が防げる
? 既存の脆弱性を塞いだ後に、APT攻撃(標的型攻撃)の対応を考える
? パッチ管理で根本を直しておき、UTMなどで短時間の脆弱性対応を行う

Red Hat Satellite
? WebUIでステータス監視

Red Hat Satellite
40
? OpenSCAPを利用し、各OSのセキュリティ状態をレポート

Red Hat Satellite
41
? OpenSCAPを利用し、各OSのセキュリティ状態をレポート

狠狠撸

Edb summit 2016_20160216.omo

More Related Content

Edb summit 2016_20160216.omo