データベース・セキュリティの実装 ... - oracle ·...
TRANSCRIPT
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
第144回夜な夜な! なにわオラクル塾
データベース・セキュリティの実装を 全て解説、脅威への対応
日本オラクル株式会社 データベース事業統括ソリューション本部 中部・西日本SC部 2015年04月22日
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Safe Harbor Statement
以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント(確約)するものではないため、購買決定を行う際の判断材料になさらないで下さい。 オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。 Oracleは、米国オラクル・コーポレーション及びその子会社、関連会社の米国及びその他の国における登録商標または商標です。 他社名又は製品名は、それぞれ各社の商標である場合があります。
2
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Agenda
1
2
3
4
情報セキュリティとは
マイナンバー制度とOracleデータベース
DBセキュリティ製品のご紹介 – Advanced Security
DBセキュリティ製品のご紹介 - Database Vault
DBセキュリティ製品のご紹介 - Audit Vault and Database Firewall
セキュリティ製品導入プロジェクト例
3
5
6
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
本日の目的とゴール
4
• 法制度とOracleデータベース機能の関連を理解する
• データベースセキュリティ関連機能を知る
• セキュリティ実装プロジェクトのポイントを知る
目的
益々重要となっているデータベースセキュリティ領域の機能を知り活用レベルをあげる
ゴール
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
昨今の情報セキュリティ問題 発見と予防の重要性が高まっている
5
組織的
標的型
なりすましによる詐欺的行為 フィッシングメールによるID盗難
アプリケーションの脆弱性を攻撃 SQLインジェクション
脆弱性を攻撃し、サーバへの侵入 不正プログラム(rootkit) OS、データベースへの侵入
境界防御を迂回する攻撃 標的型メール攻撃 USBメモリなどの外部媒体
権限者による内部不正行為 管理者権限による情報窃取など
個人情報
技術情報
知的財産 高度化
複雑化
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
セキュリティインシデントによる影響
6
・
会社業績、さらには企業存続も左右する
ブランド
イメージ低下
行政指導
インシデント対応
罰金 または 罰則
顧客離れ 不必要経費の増加
各種対応の増加
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 7
時期 対応する主要なオラクル製品の機能
個人情報保護法
2003年 : 個人情報の保護に関する法律が成立 2008年 : 個人情報保護法ガイドラインが改定 2014年 : 個人情報保護ガイドラインが改定 2015年 : 個人情報の保護に関する法律が改定予定 (ビックデータ時代に対応した内容になる見込み)
暗号化(Advanced Security Option) 特権ユーザー管理 (Database Vault)
マイナンバー (番号制度)
2013年 : 「行政手続における特定の個人を識別するための 番号の利用等に関する法律(番号法)」が成立 2014年 : 民間事業者(金融はさらに別冊)向けの ガイドラインが公開 2015年 : 全国民に個人番号通知カードを配布 2016年 : 法令で定めた範囲で運用を開始
データ暗号化 (Advanced Security Option) データ伏字化 (Data Masking and Subsetting ) 特権ユーザー管理 (Database Vault)
両ガイドラインにおいてデータへのセキュリティ対策が明記
日本における法制度の動き
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
情報セキュリティをどう考えるか? 多層防御の考え方
8
・ •物理層、境界層での対策を行いつつも、侵入されることを前提に、 アクセス層、エンドポイント層と、複数階層でセキュリティ対策を行う
階層 0:物理セキュリティ データセンター、サーバ、ネットワークへの物理アクセス制限、媒体管理等の物理的な防御
階層 1:境界セキュリティ ファイアウォール、ゲートウェイ、侵入検知/防止や等のネットワーク境界での防御
階層 2:アクセス・セキュリティ 認証・アクセス制御、通信路の暗号化など、ネットワーク内部でのアクセス制御、情報漏えい防止
階層 3:エンドポイント・セキュリティ 情報の暗号化や情報への特権ユーザのアクセス制限等による、最後の砦である情報資産や監査証跡の保護
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
情報保護におけるデータベースセキュリティの重要性 対策がされている場所を迂回する攻撃の増加
9
・
情報の中心である
データベースを保護すれば
様々な脅威に効果的に 対応
98%の情報はデータ ベースから盗まれている
84%の情報は盗まれたID ・権限で侵害されている
71% は数分で陥落
92% は第3者からの指摘で発覚
出展: Verizon DBIR 2012
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
データベースセキュリティを強化する3つのポイント
10
◎
◎
◎
監査
アクセス制御
暗号化
データへのアクセスを漏れなく記録と保全
不正なアクセスの兆候を監視し見逃さずに通知
インシデントの原因究明の重要な手掛かり
データベースへの不正なアクセスを未然に遮断
特権ユーザに適切な権限とルールを付与
Audit Vault and Database Firewall
ユーザの接続情報やアプリの情報によって アクセスできる情報を制限
機密データの漏洩、持ち出し対策
安全なテストデータの作成、個人情報の匿名化
Database Vault
Advanced Security
Data Masking and Subsetting
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Oracleが提供するデータベースセキュリティ・ソリューション
11
アプリ ケーション
ユーザー
③ Data Redaction 機密データ伏字化
② Data Masking データマスキング
④ Label Security
Virtual Private DB データアクセス制御
① Transparent
Data Encryption データ暗号化
⑤ Database Vault DB管理者 職務分掌
OS & ストレージ ディレクトリ データベース カスタム
監査ログ & イベントログ
⑥ Database Firewall 不正SQL検知
レポート
アラート
⑥ Audit Vault 証跡管理
ポリシー
イベント
DB
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Oracleが提供するデータベースセキュリティ・ソリューション
機能名 ①
Transparent Data Encryption
②
Data Masking Pack
③
Data Redaction
④
Label Security/ Virtual Private Database
⑤
Database Vault
⑥
Audit Vault and Database Firewall
脅威 データファイル、バックアップデータの奪取
開発・テスト環境データの奪取
正規利用者の 業務を逸脱した不適切アクセス
正規利用者の業務を逸脱した不適切アクセス
DB管理者によるデータ奪取 内部不正の 追跡、影響範囲の調査不可能
機能 概要
既存のアプリケーションに変更なく、透過的に本番、バックアップデータを暗号化
開発・テスト環境の実データのマスキング(伏字化) ステージ環境を用意することなくExport時にマスキングデータを生成
特定の表への参照範囲を列レベルで制限。 この機能は、データベース内で実施されるため、アプリケーション側からは透過的に利用可能。
特定の表への行・列レベルでのより厳密なアクセス制御を実現
DB管理者の業務データアクセスを制御。 特定のDB設定やパスワード変更、業務データの閲覧等を制限する
DB、OSなどのログをもれなく取得。 定常的なレポートと不正なアクセスを検知。 証跡を改ざん・削除されないようログを保全
使途 本番データ、バックアップファイルに含まれる情報を保護
テスト、開発環境の情報を保護
参照時における 列レベルでの 伏字化
参照、更新時における行・列レベルでのアクセス制御
データベース管理者の職務分掌 業務データにアクセスさせない
DB、OSなど、 網羅的な監査証跡の取得、管理
12
【予防的統制】 【発見的統制】
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
マイナンバー制度とOracleデータベース
13
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
• 遵守すべき「特定個人情報の取扱い」の内容が具体的に記載
• 特定個人情報とは 「個人番号をその内容に含む個人情報」
(個人番号に対応し、当該個人番号に代わって用いられる番号、 記号その他の符号であって、住民票コード以外のものも含む。)
*(例えば、個人番号の1, 2, 3・・・を、a, b, c ・・・と読み替えるという規則に従って個人番号を別の数字、記号又は符号に置き換えるなどした場合であっても、本条の規制の対象となる。( 逐条解説 第67条 4 ))
14
2014年12月11日 「事業者用ガイドライン」が公開
引用:http://www.ppc.go.jp/index.html
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
業務的に発生するもの
• 関連書類の受領と管理
• 書類の不備、有無の確認
• 本人確認、申告内容確認
• 個人番号の入力
• 書類不備の場合の再手続き
• 法定調書の出力
システム的に発生するもの
• 個人番号が格納されると「特定個人情報」を取り扱うシステムとして厳格な管理が要求される
15
具体的な対応項目
システム管理者
関連書類 •申告書 •通知カード •身分証
口座名義人 特定個人情報取り扱い事務者
特定個人情報取り扱い事務者
マイナンバー 一般ユーザー 運用ツール
安全な格納 適切なアクセス制御
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 16
情報システムとしては「(別添)特定個人情報に関する 安全管理措置(事業者編)」への対応が必須
引用: http://www.ppc.go.jp/files/pdf/261211guideline2.pdf
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
(別添)特定個人情報に関する安全管理措置(事業者編) 2015年4月18日時点
F 技術的安全管理措置
a アクセス制御 情報システムを使用して個人番号関係事務又は個人番号利用事務を行う場合、事務取扱担当者及び当該事務で取り扱う特定個人情報ファイルの範囲を限定するために、適切なアクセス制御を行う。
<<手法の例示>> • アクセス制御を行う方法としては、次に掲げるものが挙げられる。 –個人番号と紐付けてアクセスできる情報の範囲をアクセス制御により限定する。
–特定個人情報ファイルを取り扱う情報システムを、アクセス制御により限定する。
–ユーザーIDに付与するアクセス権により、特定個人情報ファイルを取り扱う情報システムを使用できる者を事務取扱い担当者に限定する。
Oracle製品で考えられる解決策 • 情報の範囲をアクセス制御により限定:データベースの権限管理 [Database Vault]
• 特定個人情報ファイルを取り扱う情報システムを使用できる者を事務取扱い担当者に限定する :データベースの権限管理 [Database Vault]
17
(赤下線箇所はオラクルが考える重要な箇所)
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
管理者権限の分離・最小化
18
対策を 施していない ケース
•DB管理者またはそのなりすましが、業務データを不正閲覧・改竄し、かつ監査証跡を削除可能
•業務データや監査証跡へのアクセス、ユーザアカウント作成も含め、DB管理者にDBに関する全権限を付与
DB管理者 または なりすまし データベース
業務データ (個人情報等)
監査証跡
不正閲覧・改竄
消去
構成変更・運用・監視 (本来の業務)
権限を 分離・最小化したケース
•DB管理者またはそのなりすましによる不正閲覧・改竄、監査証跡削除を防止
•管理者権限を分離 (職務分掌)
•作業に必要最低限の権限のみを付与
DB管理者 または なりすまし データベース
業務データ (個人情報等)
監査証跡
構成変更・運用・監視 (本来の業務)
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
(別添)特定個人情報に関する安全管理措置(事業者編) 2015年4月18日時点
E 物理的安全管理措置
C 電子媒体等を持ち出す場合の漏えい等の防止 特定個人情報等が記録された電子媒体又は書類等を持ち出す場合、容易に個人番号が判明しない措置の実施、追跡可能な移送手段の利用等、安全な方策を講じる。(以下略)
<<手法の例示>> • 特定個人情報等が記録された電子媒体を安全に持ち出す方法としては、持ち出しデータの暗号化、パスワードに寄る程、施錠できる搬送容器の使用等が考えられる。ただし、行政機関等に法定調書等をデータで提出するに当たっては、行政機関等が指定する提出方法に従う。
• 特定個人情報等が記載された書類等を安全に持ち出す方法としては、封緘(ふうかん)、目隠しシールの貼付を行うこと等が考えられる。
Oracle製品で考えられる解決策 – 持ち出しデータの暗号化:バックアップ等媒体の暗号化 [Advanced Security]
– 封緘(ふうかん)、目隠しシールの貼付:データの伏字(マスキング等)[Data Masking and Subsetting]
19
(赤下線箇所はオラクルが考える重要な箇所)
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
(続き) 2015年4月18日時点
F 技術的安全管理措置
d 情報漏えい等の防止 特定個人情報等をインターネット等により外部に送信する場合、通信経路における情報漏えい等を防止するための措置を講じる
<<手法の例示>> • 通信経路における情報漏えい等の防止策としては、通信経路の暗号化等が考えられる。
• 情報システム内に保存されている特定個人情報等の情報漏えい等の防止策としては、データの暗号化又はパスワードによる保護等が考えられる
Oracle製品で考えられる解決策 • データの暗号化:データベース上のデータ、バックアップ媒体、通信経路の暗号化
[Advanced Security, Oracle 標準機能]
20
(赤下線箇所はオラクルが考える重要な箇所)
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Databaseの暗号化
21
対策を 施していない ケース
•サーバ/ネットワーク管理者による不正閲覧や盗聴
•バックアップ媒体の紛失・盗難による情報流出
•ストレージ上のデータベースファイル、媒体上のバックアップデータ、ネットワーク上のデータベース関連送受信データが暗号化されていない
暗号化した ケース
•サーバ/ネットワーク管理者による不正閲覧や盗聴を防止
•バックアップ媒体の紛失・盗難時の情報流出を防止
•ストレージ上のデータベースファイル、媒体上のバックアップデータ、ネットワーク上のデータベース関連送受信データ等をすべて暗号化
佐藤良一 佐藤良一 佐藤良一
佐藤良一
個人情報が平文のまま伝送・格納 されるため、不正閲覧・盗聴が可能
APサーバ DBサーバ
ストレージ
バックアップ
bD1##Ai aT3#_0Gk aT3#_0Gk
Pc#65qa
データベース関連のすべての情報を暗号化
APサーバ DBサーバ
ストレージ
バックアップ
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Database暗号化の全体像
22
本番環境
DBサーバ
データ ファイル
索引 ファイル
REDO ログ
アーカイブ ログ
バックアップファイル
ストレージ 鍵管理
マスター暗号鍵
APサーバ
SQL文
データ 書込
REDOログ 災対環境
アプリケーションから透過的に暗号化 (アプリ改修・チューニング不要)
ハードウェアによる暗号化/復号化処理の高速化 暗号鍵を厳格に管理
データベースに関わるすべての通信を暗号化
データベース層ですべてのデータベース関連ファイルを暗号化
強力な標準共通鍵 暗号方式を採用
DBレプリケーション
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
(別添)特定個人情報に関する安全管理措置(事業者編) 2015年4月18日時点
C 組織的安全管理措置
e 取扱状況の把握及び安全管理措置の見直し
特定個人情報等の取扱状況を把握し、安全管理措置の評価、見直し及び改善に取り組む。
<<手法の例示>> • 特定個人情報等の取扱状況について、定期的に自ら行う点検又は他部署等による監査を実施する。
• 外部の主体による他の監査活動と合わせて、監査を実施することも考えられる。
Oracle製品で考えられる解決策 • データベースへのアクセスを監視 :データベースの監査・監視 [Audit Vault and Database Firewall]
23
(赤下線箇所はオラクルが考える重要な箇所)
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
(続き) 2015年4月18日時点
F 技術的安全管理措置
c 外部からの不正アクセス等の防止
情報システムを外部からの不正アクセス又は不正ソフトウェアから保護する仕組みを導入し、 適切に運用する。
<<手法の例示>> • 情報システムと外部ネットワークとの接続箇所に、ファイアウォール等を設置し、不正アクセスを遮断する。
• 情報システム及び機器にセキュリティ対策ソフトウェア等(ウイルス対策ソフトウェア等)を導入する。
• 導入したセキュリティ対策ソフトウェア等により、入出力データにおける不正ソフトウェアの有無を確認する。
• 機器やソフトウェア等に標準装備されている自動更新機能等の活用により、ソフトウェア等を最新状態と する。
• ログ等の分析を定期的に行い、不正アクセス等を検知する。
Oracle製品で考えられる解決策
• 監査・ログ分析・不正アクセス検知 :データベースの監査・監視 [Audit Vault and Database Firewall]
24
(赤下線箇所はオラクルが考える重要な箇所)
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
DBセキュリティ製品のご紹介
25
Oracle Advanced Security
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Oracle Advanced Securityが実現するセキュリティ対策
26
データの暗号化
Transparent Data Encryption
リアルタイムアクセス制御
Data Redaction
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Transparent Data Encryption(TDE) • 強力な暗号アルゴリズムを利用した暗号化を実施
– NISTの標準共通鍵暗号方式 AES(128/192/256bit) に対応
• Oracle Wallet やHardware Security Moduleを利用した暗号鍵管理メカニズム
• アプリケーションからは透過的にデータの暗号化/復号
– 既存のアプリケーション(SQL)を改修する必要はなし
27
ディスク
バックアップ
ダンプファイル
外部委託先
アプリケーション
SELECT name,cardnumber FROM credit;
ヤマダタロウ 1234567812345678
ヤマダタロウ aG5#g&3f_g0R1Blg
カード番号の暗号化
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
TDE 表領域暗号化 • 表領域単位での暗号化
• 表領域内のオブジェクトはすべて暗号化される
• データブロックに対するI/Oで暗号化・復号化
• メモリ上は暗号化しない
• 暗号化してもデータサイズは変わらない
• Advanced Compressionとの併用可能
• ほとんどすべてのオブジェクトが暗号化可能 (BFILEのみ不可)
28
表領域 暗号化
SGA
データベース
バッファキャッシュ
共有プール
REDOログ
バッファ
REDOログ UNDO表領域 TEMP表領域
表領域 暗号化 未設定
Disk I/Oで 暗号化/復号
Oacle Keystore
(Oracle Wallet)
列暗号化 マスター鍵
表領域暗号化 マスター鍵
Walletを オープン
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
TDEの暗号鍵の仕組み • Oracle Keystore に、マスター暗号鍵が格納される (※11gR2まではOracle Wallet)
• マスター暗号鍵は、それぞれの列暗号鍵と表領域暗号鍵を暗号化する
• 表ごとの暗号鍵、表領域ごとの暗号鍵で それぞれの実データを暗号化する
29
Oracle Keystore
パスワード 認証
マスター暗号鍵
表暗号鍵
データ・ディクショナリ
表領域暗号鍵
表領域
Datafile
表領域暗号鍵
表領域
Datafile
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
マスタ暗号鍵の構成手順(12c)
30
• SQLNET.ORAにKeystoreを作成するロケーションを記述する
ENCRYPTION_WALLET_LOCATION=
(SOURCE=
(METHOD=FILE)
(METHOD_DATA=
(DIRECTORY=/opt/app/oracle/product/12c/dbhome_1/network/admin)))
• SYSKM権限(またはSYSユーザ)でSQL*PLUSにログインする
SQLPLUS / AS SYSKM
Enter password: password
Connected.
• Keystoreを作成する。成功すると指定のロケーションにewallet.p12ファイルが作成される
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/opt/app/oracle/product/12c/dbhome_1/network/admin' IDENTIFIED BY password;
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
マスタ暗号鍵の構成手順(12c)
31
• Keystoreをオープンする
• マスター暗号鍵を作成する。※変更・再作成の場合も同様
ADMINISTER KEY MANAGEMENT SET KEY USING TAG ‘tag名' IDENTIFIED BY password WITH BACKUP;
• Keystoreにマスター暗号鍵が生成され、Keystoreのあるロケーションにバックアップが作成される 以降は、通常通りの暗号表、暗号化表領域の作成手順へ
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY password;
SELECT KEY_ID,ACTIVATION_TIME FROM V$ENCRYPTION_KEYS; KEY_ID CREATION_TIME ------------------------------------------------------------------------------------------------ ---------------------------- AfrZm0w5EE9kv2NNme6cpwIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 13-02-07 06:59:41
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
暗号化表領域の作成
32
CREATE TABLESPACE securespace
DATAFILE '/opt/app/oracle/oradata/ora12c/enc.dbf' SIZE 100M ENCRYPTION USING 'AES256'
DEFAULT STORAGE (ENCRYPT);
※ 既存の表を暗号化された表領域に移動する場合
- 表のオンライン再定義 (DBMS_REDEFINITION)
- ALTER TABLE MOVE ~
- Oracle DataPump Export/Import
• 表領域の作成時に列暗号化を指定
• 以降は、従来通り表を作成を作成する際の表領域として指定する
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Oracle Data Redaction
33
• ユーザーの権限やクライアント情報に応じてリアルタイムにデータをリダクション
• アプリケーションのコード修正が必要のないデータベース内で完結する列アクセス制御
• コールセンターやサポート業務などの職責に応じた顧客情報へのアクセス制御の実現や PCIDSSに対応したクレジットカード番号の表示、アプリ開発者の直接アクセスも制御
クレジットカード番号
4451-2172-9841-4368 5106-6342-4881-5211 4891-3311-0090-5055
Policy データ
責任者
業務
オペレーター
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
サポートされるリダクションの種類
34
052-51-2147 XXX-XX-2147
格納されているデータ リダクション結果
10/09/1992
[email protected] [hidden]@acme.com
4451-2172-9841-4368 4943-6344-0547-0110
Full
Partial
Regular Expression
Random
01/01/2001
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Oracle Data Redactionのアーキテクチャ
• リダクション・ポリシーを表やビューに対してDBMS_REDACTプロシージャで定義
• 対象にできる列は、CHAR/VARCHAR2、 NUMBER、 DATE、 BLOB/CLOB型
• リダクション・ポリシーの条件に応じて、列の値を任意にリダクションする
35
Oracle Database
Customer
Redaction Policy
Applications
通常表 Product
ポリシーの条件となる要素 - IPアドレス
- DBユーザー - アプリケーションID等
929-55-2147
XXX-XX-2147
Users
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
リダクション・ポリシーの作成 DBMS_REDACT.ADD_POLICYプロシージャ
DBMS_REDACT.ADD_POLICY
object_schema リダクション・ポリシーを適用するスキーマ名
object_name リダクション・ポリシーを適用する表、またはビュー名
policy_name 作成するリダクション・ポリシー名
column_name リダクション・ポリシーを適用する列名 ※複数指定したい場合は、DBMS_REDACT.ADD_POLICYで別途追加する
function_type DBMS_REDACT.FULL DBMS_REDACT.RANDOM DBMS_REDACT.PARTIAL DBMS_REDACT.REGEXP
Expression SYS_CONTEXTの値に基づく、Boolean型の条件式を定義。 条件の結果値が“True”である場合のみ、リダクションが実行される
function_parameters DBMS_REDACT.PARTIALを使用する場合のデータのINとOUTの定義
regexp……. function_typeがDBMS_REDACT.REGEXPの場合のオプション群
36
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Expression(条件式)の作成方法 • SYS_CONTEXTでセッション情報を取り出し、比較する条件の値を取得する
• 結果がTRUE or FALSEで評価できるように作成し、TRUEの場合にリダクションが行われる
37
SYS_CONTEXT(’USERENV’,’IP_ADRESS’) IS NULL
SYS_CONTEXT(’USERENV’, CLIENT_IDENTIFIER’) not like ‘MGR%’
SYS_CONTEXT('USERENV’,’SESSION_USER’) = ‘SCOTT’
SYS_CONTEXT(‘SYS_SESSION_ROLES’,’MGR’) = FALSE
•DBユーザー名がSCOTTの場合
•IPアドレスがNULLの場合
•クライアント情報にMGRのユーザー名が含まれていなかった場合
•ユーザーがMGRロールを持っていなかった場合
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
ユーザ識別子(client_identifier)の設定方法 • データベースが知りうることができないアプリケーションの情報は、
(シングルサインオンのユーザ名や、使用されているアプリケーションの名前等) client_identifierを経由することでデータベースセッションの情報に格納し取り出せる
38
SQL*PLUSの場合、接続後に以下を実行
execute dbms_session.set_identifier(‘任意の値’)
Ex) execute dbms_session.set_identifier(‘user=tanaka id=001234‘)
DBへ接続オープン後、以下を追加
String metrics[] =
new String[OracleConnection.END_TO_END_STATE_INDEX_MAX];
metrics[OracleConnection.END_TO_END_CLIENTID_INDEX] = “任意の値“;
conn.setEndToEndMetrics(metrics, (short) 0);
SQL*PLUSの場合
JDBCの場合
.NETの場合
DBへ接続オープン後、以下を追加
conn.ClientId = “任意の値” ‘
EXECUTE DBMS_SESSION.SET_IDENTIFIER('APP001'); PL/SQLプロシージャが正常に完了しました。 SELECT SYS_CONTEXT('USERENV', 'CLIENT_IDENTIFIER') FROM DUAL; SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER') ------------------------------------------------------------------------ APP001
ユーザ識別子を取得
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
各バージョンで使用できるASOの機能
Oracle
Database 10g
Release 2
Oracle
Database 11g
Release 1
Oracle
Database 11g
Release 2
Oracle
Database 12c
Release1
TDE 列暗号化
TDE 表領域暗号化
TDE HSMサポート
TDE w/Intel AES-NI サポート (※1)
TDE w/SPARC サポート (※2)
Data Redaction (※3)
39
※1 対応プラットフォームは、Oracle Linux / Redhat (64bit), 11.2.0.2~ 注)Windows OSは、11.2.0.4~(対応予定)
※2 対応プラットフォームは、Solaris 11.1 (64bit), SPARC T4/5, 11.2.0.3~
※3 11.2.0.4のみ
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
DBセキュリティ製品のご紹介
40
Oracle Database Vault
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Oracle Database Vault 特権ユーザのための強制アクセス・コントロール
41
アプリケーション
select * from finance.customers
職務分掌 特権ユーザ(SYS, DBA権限)であっても情報にはアクセスさせない
透過的 既存アプリケーションの変更不要、どの経路からのアクセスも一律に制御
厳密 ユーザー、クライアント情報(IPアドレス、アプリ名)、時間を組み合わせたポリシー設定
管理者 (特権ユーザ)
人事情報
顧客情報
財務情報
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Oracle Database Vaultについて 製品概要 • データベースのアクセス制御 –データベース接続やデータアクセスにルールを設定し、
DB管理者であっても操作を制限することが出来る
• DB管理者の権限を職務分掌 –一つのユーザに多くの権限を持たせず、必要な権限のみを持たせる
42
「職務分掌」とは、組織においてそれぞれの職務が果たすべき 責任(職責)や職責を果たす上で必要な権限(職権)を明確にするために、 職務ごとの役割を整理・配分すること。
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Oracle Database Vault(DBV)について 製品概要
43
業務データ
従来環境 DBV環境
データ ディクショナリ
DB管理者
データ参照
バックドアユーザ
ユーザ 作成
権限 付与
不正アクセス
業務データ データ ディクショナリ
DB管理者
データ参照
ユーザ 作成
不正アクセス
セキュリティ 管理者
ユーザ管理者
バックドアユーザ
権限 付与
ルール適用
・DB管理者はシステム権限により
業務データにアクセス可能 ・DB管理者はユーザ作成/権限付与の両方が
可能 であり、バックドアの作成が容易
・DB管理者は業務データにアクセス出来なくなる
・”ユーザ管理者”と”セキュリティ管理者”を作成される ・悪意のあるユーザが2人以上いないと セキュリティインシデントにならない
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Oracle Database Vaultについて
44
主な機能― レルム―
• 任意のスキーマ・オブジェクトのセットを 保護・管理するための論理的な領域
• 不認可アクセスや DDL は、レルム違反 エラーとなり、監査ログとして保存される
• レルムごとにデータの責任を持つオブジェクト管理者を作成することができる
HRテーブル データ ディクショナリ
DB管理者
HR管理者 ポイント: HR管理者の持っているオブジェクトをすべてレルムで保護すれば、DB管理者であったとしてもHRオブジェクトへのアクセスは許可されない。
DBV環境でもアクセスには通常のDB権限(オブジェクト、システム 権限)が必要となります。
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Oracle Database Vaultについて
45
主な機能― ルール/ルール・セット―
• ルールはDBVで使用される式
• ルールはデータベースで取得できる情報で作成
– TRUE またはFALSEで評価される条件
• ルール・セットにルールを増やし条件を厳しくすることで、アクセス制御の条件を強化
TRUE FALSE
許 可
禁 止
ルール・セット
時刻 = “9:00~17:00”
曜日=“月曜~金曜“
クライアントIP = “192.168.100.1”
ルール ルール
ルール
ポイント: 時刻を9:00~17:00/曜日を月~金/IP アドレスを192.168.100.1のルールを それぞれ作成し、ルール・セットに組み込む。
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Oracle Database Vaultについて 主な機能― コマンドルール― • SQLコマンドの発行を、ルール・セットに基いて制限するためのもの
• SQLコマンドに特定のルール・セットを紐付けておくと、ルール・セットがtrue となった場合のみ、そのSQLコマンドを発行する許可が与えられる。
– SQLコマンドの実行権限(システム権限やオブジェクト権限)は別途必要
46
ポイント: HRユーザを許可するルール・セットに
”CONNECT”コマンド”を紐付ける。
CONNECT
ルール ・セット
ルール
ルール ルール
HRユーザ
接続許可
HRテーブル
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
参考:コマンドルールで制御できるSQL
47
ALTER/CREATE/DROP USER ALTER/CREATE/DROP FUNCTION ALTER/CREATE/DROP PROCEDURE
ALTER/CREATE/DROP TABLE ALTER/CREATE/DROP TABLESPACE
ALTER/CREATE/DROP VIEW
ALTER/CREATE/DROP ROLE ALTER/CREATE/DROP INDEX ALTER/CREATE/DROP PROFILE
CONNECT AUDIT NOAUDIT
CHANGE PASSWORD GRANT REVOKE
SELECT DELETE INSERT
UPDATE TRUNCATE TABLE RENAME
ルール:FALSE CONNECT SCOTTユーザからの接続を禁止 対象ユーザ:SCOTT +
ルール:SQL*PLUS SELECT
HRユーザがEmployee表をSQL*PLUSからSELECTすることを禁止
対象ユーザ:HR + 対象オブジェクト: HR.Employee表 +
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
厳密な権限&ルールの設定により不正アクセスを遮断
48
ルール1(アクセス元)
IP Address: 192.168.1.XXX
APP Name: JDBC
アプリケーション用ルール
ルール1(アクセス元)
IP Address: 192.168.1.201
DB User: ADMIN01
ルール2 (時間)
09:00~19:00
開発者用ルール
select * from crm.customer
09:00~19:00の間
開発者
ユーザ・オブジェクト
表 - Customer - Order 索引 プロシージャ
アプリケーション ユーザー
ユーザ オブジェクト:
認可
ユーザ オブジェクト:
認可
ユーザ オブジェクト:
非認可
select * from crm.customer
select * from crm.customer
19:00~9:00の間
select * from crm.customer
管理者
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Database Vaultによる権限分掌と相互監視
49
従来
特権ユーザ
HRユーザ
・ユーザ作成
・権限付与
・HR表への 直接アクセス
・HR表への監査
SCOTT ユーザ
・HR表への オブジェクト権限を付与
Database Vault 環境
リソース管理者 (特権ユーザ)
セキュリティ 管理者
オブジェクト管理者 ( HRユーザ)
ユーザ作成
レルム所有者に任命
システム権限付与 アクションを監査
オブジェクト 権限付与
ユーザ作成
レルム参加者 に任命
SCOTT ユーザ
システム 権限付与
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
DBセキュリティ製品導入 Tips
50
Oracle Database Vault
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
推奨されるコマンドルール
• GRANT/REVOKE文 –権限付与のコマンドは特定ユーザのみに制限する
–不要な権限付与を制限し、不正な操作を抑止する
• NOAUDIT文 – NOAUDIT文を全ユーザで実行させない
※AVDF導入環境ではAVDF管理者のみ付与する
– DBで監査(AUDIT文)を使用していない環境下でも有効にすることを推奨
51
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Database Vaultの監査証跡の管理とメンテナンス
• DBとDBVの監査証跡と別管理 – DBとDBVの監査証跡の管理は別ユーザで行う
– DBVの監査証跡は表領域に作成する必要がある
• DBVの監査証跡メンテユーザの作成 – DBV監査証跡をバックアップするためのユーザ
– Datapumpに必要な権限のみ付与する
※メンテユーザの監査証跡の改竄は不可
–バックアップファイルの管理は別で行う必要がある
52
DB 監査証跡
DBV 監査証跡
DB管理者 セキュリティ 管理者
DBV監査証跡メンテナンスユーザ
バックアップ
Datapump
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
DBV環境下での緊急対応時の運用案
1. DB管理者+DBV管理者相当のユーザ作成 – DBのすべての業務が出来るユーザの作成し、緊急時の対応に備える
–通常運用では使用しない
–権限の強さはSYSDBAやroot(OS)ユーザ相当のため厳重に管理する
2. 緊急時の無効化スクリプトの準備 – DBVのコマンドルール/レルムを無効化ジョブするジョブを用意
– DBV機能のためにデプロイしたコンポーネントを削除するわけではない
※但し、通常DBA権限の一部が付与されていない点に注意が必要
53
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
DBセキュリティ製品のご紹介
54
Oracle Audit Vault and Database Firewall
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Oracle Audit Vault and Database Firewall(AVDF)について
55
製品概要
文法解析による正確なブロッキング、DatabaseやOSの監査ログをモニタリング 迅速なセキュリティ対策を可能にするソフトウェア・アプライアンス
Audit Vault Server
Security Manager
Reports
! Alerts
Database Firewall Server
Fire
wal
l Ev
ents
Custom Server
OS, Directory & Custom Audit Logs
Auditor
Policies
不正アクセスを未然に遮断
データベース OS等の監査ログを収集
Users Allow
Log
Alert
Substitute
Block
Applications
自動化されたモニタリング
他社DBにも対応
他社OSにも対応
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Oracle Audit Vault and Database Firewall(AVDF)について
56
AVDFの各コンポネント
Application Audit Vault Server
Audit Vault Agent
Database Firewall Server 監査対象
- Database - OS - Directory - File System - Custom APP
– Oracle Database Firewall Server
• ネットワークトラフィックを受信し、ポリシーに応じたブロッキング・モニタリングを行うネットワーク・サーバ
• 配置方式は、AP~DB間に配置するインライン方式、ミラーポートを利用したアウトオブバンド方式、プロキシ方式の3種類
– Oracle Audit Vault Server
• Database Firewall Server、Audit Vault Agentから転送されるログを集約するリポジトリ・サーバ
• すべてのDatabase Firewall Server、 Audit Vault Agentの管理・監視を一元的に管理し、ログの分析やアラート、レポーティングを行う
– Audit Vault Agent
• 監査対象上で動作するJAVAアプリケーション。監査対象が出力した監査ログを収集し、定期的にAudit Vault Serverへ送信する
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Oracle Audit Vault and Database Firewall(AVDF)について AVDFの機能概要 – モニタリング • スイッチのミラーポートからSQLパケットをDatabase Firewall Serverが受信するオーバヘッドのないアウトオブバンド方式
• Databaseだけでなく、OSやユーザ独自のアプリなど幅広い監査ログの取得を実現するエージェント方式
• お客様のシステムや監査対象に応じて最適な方式を選択、また、組み合わせたハイブリッド方式も可能
57
アウトバウンド方式
(Database Firewall)
Network Traffic
Database Server
Audit Vault Server
User
Network Switch (Mirror Port)
Database Firewall Server
エージェント方式
(Audit Vault)
User
Database Firewall Server
Audit Vault Server
Database Server, OS等
Audit Vault
Agent
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Oracle Audit Vault and Database Firewall(AVDF)について AVDFの機能概要 - ブロッキング • 搭載されたSQL文法解析エンジンが誤検出のない正確なブロッキングを実現
• アプリケーション、データベースの変更が必要のない透過的な構成 (インライン方式)
• 数万を超えるトランザクションでもオーバヘッドを感じさせない高速なマッチング処理を実現
58
インライン方式
(Database Firewall)
Database Server
User
Database Firewall Server
Audit Vault Server
プロキシ方式
(Database Firewall)
Database Firewall Server
Database Server
User
Audit Vault Server
Network Switch
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
リアルタイムアラート アラート条件に基づいて管理者に即座に通知 •Database Firewallがブロッキング、アラート検知した場合
•アラート条件としきい値を超えた場合、 指定されたメールアドレスにアラートメール、SYSLOGで送信
59
Application Database Database Firewall
管理者
Alerts
Audit Vault Server
条件:
イベント時間
IPアドレス, ホスト名
エラーコード
ユーザ名
SQLコマンドなど
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
DBセキュリティ製品導入 Tips
60
Oracle Audit Vault and Database Firewall
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
AVDFの冗長化構成 • AVDFではDatabase Firewallのペア、Audit Vault Serverのペア、あるいは両方を構成することで、高可用性システム・アーキテクチャーを提供することができます。
• Database Firewall/Audit Vault Serverの障害時に、Database Firewall/Audit Vault Serverの処理がフェイルオーバーし、継続してモニタリングを行うことで障害時にもセキュリティレベルを落とすことなく処理を継続することができます。
61
Database Firewall Server Audit Vault
Server
Application
Database
プライマリルート
セカンダリ・ルート (Active or Standby)
Audit Vault Server
Database Firewall Server
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
AVDFの冗長化構成 Database Firewallの冗長化構成について
• AVDFを導入頂いている多くのお客様に、 Database Firewall障害による監査ログの取り漏れを防ぐため冗長化構成の採用頂いています。
– スイッチのミラーポートからデータベースの送受信アクセスを取得し、 Audit Vault へ送信
– 冗長化されたスイッチに対して2台のDatabase Firewallで接続し、ログの重複はペアリング機能で制御
– Database Firewallの障害時でも、片側のDatabase Firewallでログを収集する
– ローカルアクセスは取得できない
62
Database Firewall Server Audit Vault
Server
Application Database
プライマリルート
セカンダリ・ルート (Standby)
Database Firewall Server
SQL①
SQL②
SQL③
SQL①
SQL②
SQL③
SQL①
SQL②
SQL③
プライマリ
セカンダリ
監査ログ
ログの取得漏れを防ぐため SW-Database Firewall間のたすき
掛けが必須
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
AVDFの冗長化構成 Database Firewallの冗長化構成について – プライマリDatabase Firewall障害
1. プライマリDatabase Firewallに障害が発生
2. Audit Vault Serverが障害を検知
3. セカンダリDatabase Firewallがプライマリに昇格
4. Audit Vault Serverは新プライマリ(旧セカンダリ)を 正とし監査ログを収集
63
Database Firewall Server
Application Database
プライマリルート
セカンダリ・ルート (Standby)
Database Firewall Server
SQL①
SQL②
SQL③
SQL①
SQL②
SQL③
プライマリ
セカンダリ プライマリ 昇格
L3SW#1
L3SW#2
監査ログ
Audit Vault Server
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
AVDFの冗長化構成 Database Firewallの冗長化構成について – SW-プライマリDatabase Firewall間 ネットワーク障害 1. プライマリのSW-Database Firewall間のネットワーク障害が発生
2. ネットワーク監視による検知
3. 手動でセカンダリDatabase Firewallをプライマリに昇格
4. Audit Vault Serverは新プライマリ(旧セカンダリ)を 正とし監査ログを収集
64
Database Firewall Server
Application Database
プライマリルート
セカンダリ・ルート (Standby)
Database Firewall Server
SQL①
SQL②
SQL③
SQL①
SQL②
SQL③
プライマリ
セカンダリ プライマリ 昇格
L3SW#1
L3SW#2
監査ログ
Audit Vault Server
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
AVDFの導入メリット 監査証跡の運用時におけるメリット
• 冗長化構成によるセキュリティレベルの保持
• 監査証跡の完全性担保
– Audit Vault ServerにはDBVが標準インストール済み(監査証跡データへの不正アクセスや改ざんを防ぐ仕組み)
• 監査証跡の定期的な分析
– 取得した監査証跡はレポーティング機能を使い定期な分析を実施することで、不正アクセスや異常な行動を検知
– アラート機能を利用することで、緊急性の高いイベントに対してアラート通知が可能
• 監査証跡の保存ポリシー
– 監査証跡のオンライン、アーカイブ、バックアップ管理機能を標準機能として提供
• 複数DBの監査証跡を一元管理
– 複数DBの監査証跡をAudit Vault Serverで一元的に管理できる
65
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
セキュリティ製品導入プロジェクトのご紹介
66
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
データベース・セキュリティ対策項目の検討 ~ よくある3要件8項目による検討例 • データベース・セキュリティの基本対策項目と想定機能の対応を以下に示します。
67
データベースセキュリティ対策
伏字化
アクセス制御
アクセスログ
領域 分類
通信経路の暗号化
格納データの暗号化
テストデータのマスキング
DB接続/SQL実行の制限
機微データ(列)アクセスの制限
特権の制限
DB接続/SQL実行の証跡取得
不正識別/報告レポート
SSL/TLS
-
-
権限/ロール
-
-
監査ログ
-
-
Transparent Data Encryption
Data Masking Pack
-
Data Redaction
Database Vault
-
Audit Vault and Database Firewall
Oracle Advanced Security (ASO)
Oracle Database Vault (DBV)
Oracle Audit Vault and Database Firewall
(AVDF)
Oracle Data Masking and Subsetting Pack
(DM)
セキュリティ対策項目 識別1
(既存対策) DB標準機能 オプション機能
識別2 (Oracle DB Security) DBセキュリティ用 ライセンス名称
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
(参考)データベース保護のセキュリティモデル • 多階層防御と責任分解による多重的なデータ保護を推奨します。
68
建物・設備 (物理)
IT機器 (HW)
ネットワーク (回線)
サーバ、 ストレージ
ITサービス
(AP/MW)
OS
AP/ロジック
DB
重要データ 本体
(基盤部分の対応により補完)
標準サービス
(基盤部分の対応により補完)
スパム対策/ アンチウィルス
標準サービス
FW,IDS/IPS
AVDF (DB不正監視・監
査ツール)
スパム対策/ アンチウィルス
標準サービス
FW,IDS/IPS
AVDF
スパム対策/ アンチウィルス
標準サービス
FW,IDS/IPS
DBV ASO
ID管理
Level-1 Level-2 Level-3 Level-5
セキュリティ要件 少ない
想定顧客の特徴例 > 全体監視、外的な
脅威を想定 全体監視、外的および内的な脅威を想定
補足事項
標的型攻撃では、プロフェッショナルが長期的に潜伏して、諜報活動が行われる。 ⇒ 特に、「階層防御」と 「ログの精度」が重要 になる
ログの精度で求められることは、必要なログが取り漏れなく取得でき、必要なタイミングで調査・分析できること
定常的な監視では、誤検知の多さはコストに影響する。 ⇒ 誤検知の少ないこと は運用事業者の負 担を軽減する。
AVDF
スパム対策/ アンチウィルス
標準サービス
FW,IDS/IPS
DBV ASO
Level-4
モニタリング コントロール IDプロセス統制
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
セキュリティ製品導入プロジェクトのご紹介 用語の解説
【発見的統制】 ・「悪いことが起きたことを見つける」仕組みのこと。
・監査証跡、ログ分析などの誰が何をやったかが追跡できる状態(責任追跡性)
【予防的統制】 ・「悪いことをさせない」仕組みのこと。
・ブロッキング、アクセスコントロールなどの強制力を伴うもの。
69
Oracleコンサルが考えるDBセキュリティ
•攻め ⇒ プロアクティブに抑止する … 【予防的統制】 •守り ⇒ 最終防衛としての監査証跡 … 【発見的統制】
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
要件 • セキュリティ要件:「何」を「誰」から守るかの整理・定義・ユースケース
設計 • セキュリティ設計:「何」を「誰」から「どのように」守るかの設計
実装 • セキュリティ実装:「何」を「誰」から「どのように」守るかの施行
運用 • セキュリティ運用:「何」を「誰」から「どのように」守り続けるかの確立
セキュリティ製品導入プロジェクトのご紹介 セキュリティ実装までの流れ
70
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
セキュリティ製品導入プロジェクトのご紹介 本プロジェクトの目的
71
A-DB C-DB D-DB B-DB DB統合 B C D A
現行環境
次期環境
•現行DBではDBAロールを使用するアプリが存在。
• セキュリティ強化に伴い、監査も強化したい。
データ ディクショナリ
お客様課題
DBAロールを保有ユーザは全業務データにアクセス出来てしまう
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
セキュリティ製品導入プロジェクトのご紹介 本プロジェクトの目的
72
A-DB C-DB D-DB B-DB DB統合 B C D
DBAロール保有しているが範囲は限定
A
監査ログ & イベントログ
データ ディクショナリ
監査
監査 DB管理者
DB管理者
• DBAからアクセス権剥奪⇒DBV導入し解決
•監査強化⇒AVDF導入し解決
解決案
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 73
A-DB C-DB D-DB B-DB
DBV導入: ・特権ユーザの業務データアクセスの制御 ・DBAロール保有ユーザによるバックドア作成の抑止
DB統合 B C D
DBAロール保有しているが範囲は限定
A
監査ログ & イベントログ
データ ディクショナリ
監査
監査
DB管理者
DB管理者
AVDF導入: ・監査証跡の一元管理 ・AVDF標準機能による証跡の改ざん防止 ・レポーティング機能による監査証跡の定期的な分析
導入効果
セキュリティ製品導入プロジェクトのご紹介 本プロジェクトの目的
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
1ヶ月 2ヶ月 3ヶ月 4ヶ月 5ヶ月 6ヶ月 7ヶ月 8ヶ月 9ヶ月
セキュリティ製品導入プロジェクトのご紹介 スケジュール
要件定義
標準設計
詳細設計
運用設計
テスト
74
標準設計
詳細設計
運用設計
テスト
AVDF作業
DBV作業
DBV&AVDF作業
スケジュール初期の要件定義では 予防的統制と発見的統制の2点を 考慮したセキュリティ設計を実施。
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
セキュリティ製品導入プロジェクトのご紹介 プロジェクトの作業フロー
• 要件定義
– 監査部からの統制内容は抽象的であったため、システムとしての統制を導くため 「何」 、「誰から」 守るか整理する。
– 整理した要件を基に統制を内容の案出しを実施する。
– 運用コストなどを考慮してシステムとしての統制内容を決定する。
• 設計 / 実装
– 実装は基本的にDBVとAVで「実現できること」「実現できないこと」を検討する。
– 必須でない統制は運用コストを考慮してAVDFによる発見的統制に振り分ける。
標準設計 詳細設計 運用設計 テスト
統制内容 システム化
統制案 リストアップ
統制案の 実装方法
75
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
セキュリティ製品導入プロジェクトのご紹介 要件定義 (統制内容システム化) • 要件定義
• 統制内容システム化(ユースケースづくり)
– お客様にはセキュリティ要件を決定する監査部門から提示された監査要件が存在した。
– ただし、セキュリティ要件はシステム観点ではざっくりとした内容であるため、下記を整理する。
守りたいデータは何か
守りたいデータに対するアクセス(誰を許容して、誰を許容しないのか)
その他管理オペレーションの権限分掌
例) DBAユーザの顧客情報アクセスは制限したい。権限付与のオペレーションは管理したい。
• 統制案リストアップ
• 統制案の実装方法
76
統制内容 システム化
統制案 リストアップ
統制案の 実装方法
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
セキュリティ製品導入プロジェクトのご紹介 要件定義 (統制内容システム化)- 管理オペレーションの権限分掌
• ユーザ定義
– 職責とそれに対するユーザのマッピングを行う。
– それぞれの職責で担当する作業を簡潔に洗い出す。
77
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
セキュリティ製品導入プロジェクトのご紹介 要件定義 (統制内容システム化)- 管理オペレーションの権限分掌 • 権限セット
– 各利用者を想定した権限セットを定義する。
– 各権限セットでは利用者に必要とされる最低限の権限を付与する。
78
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
セキュリティ製品導入プロジェクトのご紹介 要件定義 (統制内容システム化)- 管理オペレーションの権限分掌 • ユースケース
– システムライフサイクルの中の各局面で想定されるユースケースと実行するユーザ、業務内容と利用する権限セットをマッピングする。
79
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
セキュリティ製品導入プロジェクトのご紹介 要件定義 (統制案リストアップ) • 要件定義
• 統制内容システム化(ユースケースづくり)
– お客様にはセキュリティ要件を決定する監査部門から提示された監査要件が存在した。
– ただし、セキュリティ要件はシステム観点ではざっくりとした内容であるため、下記を整理する。
守りたいデータ、守りたいデータに対するアクセス、その他管理オペレーションの権限分掌
例) DBAユーザの顧客情報アクセスは制限したい。権限付与のオペレーションは管理したい。
• 統制案リストアップ
– システム化する統制項目を製品に落とし込み、具体的な統制に対する実装をリストアップする。
例) DBV機能で顧客情報表を保護する。権限管理の操作はすべて監査対象とする。
• 統制案の実装方法
– 「統制案のリストアップ」フェーズで洗い出した案のうち、設計コスト/運用コストを考慮して実装する内容を決定する。
例) DBVのレルムで保護を行う。AVDFでGRANT文を発行した証跡は取得する。
80
統制内容 システム化
統制案 リストアップ
統制案の 実装方法
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
セキュリティ製品導入プロジェクトのご紹介 要件定義 (統制案の実装方法) • 要件定義
• 統制内容システム化(ユースケースづくり)
– お客様にはセキュリティ要件を決定する監査部門から提示された監査要件が存在した。
– ただし、セキュリティ要件はシステム観点ではざっくりとした内容であるため、下記を整理する。
守りたいデータ、守りたいデータに対するアクセス、その他管理オペレーションの権限分掌
例) DBAユーザの顧客情報アクセスは制限したい。権限付与のオペレーションは管理したい。
• 統制案リストアップ
– システム化する統制項目を製品に落とし込み、具体的な統制に対する実装をリストアップする。
例) DBV機能で顧客情報表を保護する。権限管理の操作はすべて監査対象とする。
• 統制案の実装方法
– 「統制案のリストアップ」フェーズで洗い出した案のうち、設計コスト/運用コストを考慮して実装する内容を決定する。
例) DBVのレルムで保護を行う。AVDFでGRANT文を発行した証跡は取得する。
81
統制内容 システム化
統制案 リストアップ
統制案の 実装方法
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
セキュリティ製品導入プロジェクトのご紹介 要件定義 (統制案の実装方法)
• 要件定義
• 統制案の実装方法
1人(ユーザ)に権限が集中しないように(1人で悪事ができない)権限分掌する。
基本的には各ユーザは必要最低限の権限を保持する。
DBAの業務データへの不要な参照は監査したい。
ユーザ作成、権限付与はバックドア作成の危険性があるコマンドの監視する。
(検討結果の例) ・不正なユーザ作成の防止 ・不正な権限付与の防止 ・不要な業務データへのアクセスの抑制 ・不正管理作業の監査
⇒ 権限分掌で実現 ⇒ 権限分掌またはレルムで実現 ⇒ レルムで実現 ⇒ AVDFの機能で実現
– 各統制内容の実装案については「統制の強さ」、「統制実装」を鑑みてコストのバランスを考慮する。
82
シンプルに構成
統制内容 システム化
統制案 リストアップ
統制案の 実装方法
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
バックアップサーバからのSYSユーザの アクセスを監査(AVDF)
セキュリティ製品導入プロジェクトのご紹介 要件定義 (統制案の実装方法例)
83
発見的統制
予防的統制
DB管理者(SYS)
バックアップサーバからのみSYSユーザの接続許可しバックアップ
ユーザ管理者
AVDF監査
参照
バックアップサーバ
セキュリティ要件- 特定のサーバからのみ
DBバックアップが行えること
レルム保護
セキュリティ要件-XXXXXXXXXXXXXXXX
セキュリティ要件-XXXXXXXXXXXXXXXX
…
…
セキュリティ要件-XXXXXXXXXXXXXXXX
セキュリティ要件-XXXXXXXXXXXXXXXX
• RMANを使用するにはSYSDBA権限が必要
• 通常SYSDBAユーザでDBA業務を行わない
RMAN
取得
DBアクセス
バックアップサーバ
考慮事項
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
セキュリティ製品導入プロジェクトのご紹介 勘所 – セキュリティはトップダウン
• セキュリティ方針はお客様の役員層からトップダウンで決まる。その方針をもとに要件定義行う必要があるため、プロジェクトでは必ずお客様の中でセキュリティ担当者を立てセキュリティ要件の洗い出しを行う。
– 関係者・部署または各担当との連携が重要 • ユースケースなどシステム部門(業務担当者)にしか出せない情報があり、関係者を巻き込んで進めることが重要である。 またはその連携体制を作成・維持できることも重要である。
– セキュリティ要件は都度見直す必要がある
• セキュリティの脅威は急速に進化する。常に一定のセキュリティレベルを保つため、定期的にセキュリティポリシーを見直すことが必要である。
– 統制内容に関する落とし所 • 最低ラインを明確にしておく必要がある ( 「誰が何を実施したか」を特定できる発見的統制など)
• 要件定義は作成するが、スモールスタートを目指す
84
システム部門 (業務担当者)
セキュリティ 部門
SIer
セキュリティ アセスメント
セキュリティ 管理者
セキュリティ担当者
セキュリティ担当
実装案 要件 業界スタンダードのセキュリティポリシーでシステム化を行うことは比較的容易です。各社でサイバーセキュリティに精通しているセキュリティ担当者をアサインすることが重要です。しかし、担当者の不在やスキル不足ですとプロジェクトで大きな問題となりえます。
プロジェクト体制図例
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
まとめ Oracleが考えるDBセキュリティの攻めと守りとプロジェクトの勘所
•攻めとは
85
【予防的統制】 ⇒ アクセス制御、権限分掌
【発見的統制】 ⇒ 監査証跡取得、証跡のモニタリング
セキュリティ脅威に対するOracle製品
DBセキュリティ製品導入プロジェクトの勘所
•守りとは … …
関係者・部署または各担当との連携が重要
最低ラインを定めてスモールスタート
セキュリティはトップダウン
セキュリティ要件は都度見直す
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Appendix
86
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
補足:PCI DSS(Payment Card Industry Data Security Standard)
• クレジットカードを扱う業者の業界スタンダード基準
–加盟店・決済代行事業者が取り扱うカード会員様のクレジットカード情報・取引情報を安全に守るために、JCB、アメリカンエキスプレス、Discover、マスターカード、VISAの国際ペイメントブランド5社が共同で策定した、クレジット業界におけるグローバルセキュリティ基準。
• 12の「要件」として規定 –ファイアウォールを導入し、最適な設定を維持すること。
ネットワーク資源およびカード会員データに対するすべてのアクセスを追跡し、監視すること。 …などが12の要件に分かれています。
– 12の要件をさらに詳細な約200項目にブレイクダウンされています。
87
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
補足:セキュリティ施策の分類/PCIDSS要件とOracleソリューション
88
• DBVとAVDFはPCDISSの要件にマッピングすることができます。
PCI DSS 3.0 詳細:https://ja.pcisecuritystandards.org/_onelink_/pcisecurity/en2ja/minisite/en/docs/PCI_DSS_v3.pdf “クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス”: http://www.oracle.com/jp/products/database/security/1006242-security-pci-dss-wp-078843-171764-ja.pdf
安全なネットワークの構築と維持
要件1:カード会員データを保護するために、ファイアウォールをインストールして構成を維持する
要件2:システムパスワードおよび他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない
カード会員データの保護
要件3:保存されるカード会員データを保護する
要件4:オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する
<中略>
強力なアクセス制御手法の導入
要件7:カード会員データへのアクセスを、業務上必要な範囲内に制限する
要件8:システムコンポーネントへのアクセスを確認・許可する
要件9:カード会員データへの物理アクセスを制限する
ネットワークの定期的な監視およびテスト
要件10:ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する
要件11:セキュリティシステムおよびプロセスを定期的にテストする
情報セキュリティポリシーの維持
要件12:すべての担当者の情報セキュリティに対応するポリシーを維持する
Database Vault
AVDF
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 89
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Oracle Enterprise Managerによる暗号化表領域の設定例
90
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 91
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
暗号鍵の管理
92
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
マスター暗号鍵の変更
93
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 94
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Data Redactionの設定例
95
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 96
リダクション対象
・SCOTTユーザ
・CUSTOMER表
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 97
リダクション対象
・FIRSTNAME列
・ランダムリダクション
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 98
リダクション対象
・CARDNO列 (部分リダクション)
・FISRTNAME列 (ランダムリダクション)
・LASTNAME列 (ランダムリダクション)
・VALIDATE列 (フルリダクション)
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 99
リダクション条件
・SCOTTユーザ以外は リダクションさせる
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 100
リダクション・ポリシー定義
・SCOTTユーザ
・CUSTOMER表
・CARDNO列 (部分リダクション)
・FISRTNAME列 (ランダムリダクション)
・LASTNAME列 (ランダムリダクション)
・VALIDATE列 (フルリダクション)
・条件
・SCOTTユーザ以外は リダクションさせる
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
Data Redactionの設定完了
101
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 102
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
レルム作成の手順
103
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
レルム作成の手順
104
1 2
必須レルムを 選択
HRユーザのすべての オブジェクトを対象 (%.%)にする
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
レルム作成の手順
105
HRユーザを レルムの所有者として 認可する
3 4
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |
HRレルムが動作しているかの確認
106
SYSユーザからの アクセスはできない
HR_Realm
- HRのすべてのオブジェクトが対象 - HRがレルム所有者
・SYSやSYSTEMユーザ、DBAロール、SELECT ANY TABLE等の権限を持っていたとしてもレルム認可されていなければ、左記のようにアクセスはできない
・HRユーザがレルム所有者なので、 オブジェクト権限(DML)の付与などの 管理者としての役割を担う
・レルムに対するアクセス・ルールを含める場合は、後述のルールを設定する
Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 107