Edb summit 2016_20160216.omo

© 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に入り込み内側から

美味しい時代!!

2015StagefrightXCodeGhost.....

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/)

事業者が基本的な要件を満たす情報セキュリティ対策を実施し、事業者がそのとおりに実施しているかを標準的な基準に基づきあらかじめ定められた要件を満たす監査で評価し、安全性が確保されていることを顧客に公開する。

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のセキュリティ状態をレポート


Software

Edb summit 2016_20160216.omo