データベース・セキュリティの実装 ... - oracle ·...

Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |

第144回夜な夜な! なにわオラクル塾

データベース・セキュリティの実装を全て解説、脅威への対応

日本オラクル株式会社データベース事業統括ソリューション本部中部・西日本SC部 2015年04月22日


Safe Harbor Statement

以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。 Oracleは、米国オラクル・コーポレーション及びその子会社、関連会社の米国及びその他の国における登録商標または商標です。他社名又は製品名は、それぞれ各社の商標である場合があります。

2


Agenda

1

2

3

4

情報セキュリティとは

マイナンバー制度とOracleデータベース

DBセキュリティ製品のご紹介 – Advanced Security

DBセキュリティ製品のご紹介 - Database Vault

DBセキュリティ製品のご紹介 - Audit Vault and Database Firewall

セキュリティ製品導入プロジェクト例

3

5

6


本日の目的とゴール

4

• 法制度とOracleデータベース機能の関連を理解する

• データベースセキュリティ関連機能を知る

• セキュリティ実装プロジェクトのポイントを知る

目的

益々重要となっているデータベースセキュリティ領域の機能を知り活用レベルをあげる

ゴール


昨今の情報セキュリティ問題発見と予防の重要性が高まっている

5

組織的

標的型

なりすましによる詐欺的行為フィッシングメールによるID盗難

アプリケーションの脆弱性を攻撃 SQLインジェクション

脆弱性を攻撃し、サーバへの侵入不正プログラム（rootkit） OS、データベースへの侵入

境界防御を迂回する攻撃標的型メール攻撃 USBメモリなどの外部媒体

権限者による内部不正行為管理者権限による情報窃取など

個人情報

技術情報

知的財産高度化

複雑化


セキュリティインシデントによる影響

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)

両ガイドラインにおいてデータへのセキュリティ対策が明記

日本における法制度の動き


情報セキュリティをどう考えるか？多層防御の考え方

8

・ •物理層、境界層での対策を行いつつも、侵入されることを前提に、アクセス層、エンドポイント層と、複数階層でセキュリティ対策を行う

階層 0：物理セキュリティデータセンター、サーバ、ネットワークへの物理アクセス制限、媒体管理等の物理的な防御

階層 1：境界セキュリティファイアウォール、ゲートウェイ、侵入検知／防止や等のネットワーク境界での防御

階層 2：アクセス・セキュリティ認証・アクセス制御、通信路の暗号化など、ネットワーク内部でのアクセス制御、情報漏えい防止

階層 3：エンドポイント・セキュリティ情報の暗号化や情報への特権ユーザのアクセス制限等による、最後の砦である情報資産や監査証跡の保護


情報保護におけるデータベースセキュリティの重要性対策がされている場所を迂回する攻撃の増加

9

・

情報の中心である

データベースを保護すれば

様々な脅威に効果的に対応

98%の情報はデータベースから盗まれている

84%の情報は盗まれたID ・権限で侵害されている

71% は数分で陥落

92% は第3者からの指摘で発覚

出展： Verizon DBIR 2012


データベースセキュリティを強化する３つのポイント

10

◎

◎

◎

監査

アクセス制御

暗号化

データへのアクセスを漏れなく記録と保全

不正なアクセスの兆候を監視し見逃さずに通知

インシデントの原因究明の重要な手掛かり

データベースへの不正なアクセスを未然に遮断

特権ユーザに適切な権限とルールを付与

Audit Vault and Database Firewall

ユーザの接続情報やアプリの情報によってアクセスできる情報を制限

機密データの漏洩、持ち出し対策

安全なテストデータの作成、個人情報の匿名化

Database Vault

Advanced Security

Data Masking and Subsetting


Oracleが提供するデータベースセキュリティ・ソリューション

11

アプリケーション

ユーザー

③ Data Redaction 機密データ伏字化

② Data Masking データマスキング

④ Label Security

Virtual Private DB データアクセス制御

① Transparent

Data Encryption データ暗号化

⑤ Database Vault DB管理者職務分掌

OS & ストレージディレクトリデータベースカスタム

監査ログ & イベントログ

⑥ Database Firewall 不正SQL検知

レポート

アラート

⑥ Audit Vault 証跡管理

ポリシー

イベント

DB


Oracleが提供するデータベースセキュリティ・ソリューション

機能名 ①

Transparent Data Encryption

②

Data Masking Pack

③

Data Redaction

④

Label Security/ Virtual Private Database

⑤

Database Vault

⑥


脅威データファイル、バックアップデータの奪取

開発・テスト環境データの奪取

正規利用者の業務を逸脱した不適切アクセス

正規利用者の業務を逸脱した不適切アクセス

DB管理者によるデータ奪取内部不正の追跡、影響範囲の調査不可能

機能概要

既存のアプリケーションに変更なく、透過的に本番、バックアップデータを暗号化

開発・テスト環境の実データのマスキング（伏字化）ステージ環境を用意することなくExport時にマスキングデータを生成

特定の表への参照範囲を列レベルで制限。この機能は、データベース内で実施されるため、アプリケーション側からは透過的に利用可能。

特定の表への行・列レベルでのより厳密なアクセス制御を実現

DB管理者の業務データアクセスを制御。特定のDB設定やパスワード変更、業務データの閲覧等を制限する

DB、OSなどのログをもれなく取得。定常的なレポートと不正なアクセスを検知。証跡を改ざん・削除されないようログを保全

使途本番データ、バックアップファイルに含まれる情報を保護

テスト、開発環境の情報を保護

参照時における列レベルでの伏字化

参照、更新時における行・列レベルでのアクセス制御

データベース管理者の職務分掌業務データにアクセスさせない

DB、OSなど、網羅的な監査証跡の取得、管理

12

【予防的統制】【発見的統制】


マイナンバー制度とOracleデータベース

13


• 遵守すべき「特定個人情報の取扱い」の内容が具体的に記載

• 特定個人情報とは「個人番号をその内容に含む個人情報」

（個人番号に対応し、当該個人番号に代わって用いられる番号、記号その他の符号であって、住民票コード以外のものも含む。）

＊（例えば、個人番号の1, 2, 3・・・を、a, b, c ・・・と読み替えるという規則に従って個人番号を別の数字、記号又は符号に置き換えるなどした場合であっても、本条の規制の対象となる。（逐条解説第67条 4 ））

14

2014年12月11日「事業者用ガイドライン」が公開

引用：http://www.ppc.go.jp/index.html


業務的に発生するもの

• 関連書類の受領と管理

• 書類の不備、有無の確認

• 本人確認、申告内容確認

• 個人番号の入力

• 書類不備の場合の再手続き

• 法定調書の出力

システム的に発生するもの

• 個人番号が格納されると「特定個人情報」を取り扱うシステムとして厳格な管理が要求される

15

具体的な対応項目

システム管理者

関連書類 •申告書 •通知カード •身分証

口座名義人特定個人情報取り扱い事務者

特定個人情報取り扱い事務者

マイナンバー一般ユーザー運用ツール

安全な格納適切なアクセス制御


情報システムとしては「（別添）特定個人情報に関する安全管理措置（事業者編）」への対応が必須

引用： http://www.ppc.go.jp/files/pdf/261211guideline2.pdf


（別添）特定個人情報に関する安全管理措置（事業者編） 2015年4月18日時点

F 技術的安全管理措置

a アクセス制御情報システムを使用して個人番号関係事務又は個人番号利用事務を行う場合、事務取扱担当者及び当該事務で取り扱う特定個人情報ファイルの範囲を限定するために、適切なアクセス制御を行う。

＜＜手法の例示＞＞ • アクセス制御を行う方法としては、次に掲げるものが挙げられる。 –個人番号と紐付けてアクセスできる情報の範囲をアクセス制御により限定する。

–特定個人情報ファイルを取り扱う情報システムを、アクセス制御により限定する。

–ユーザーIDに付与するアクセス権により、特定個人情報ファイルを取り扱う情報システムを使用できる者を事務取扱い担当者に限定する。

Oracle製品で考えられる解決策 • 情報の範囲をアクセス制御により限定：データベースの権限管理 [Database Vault]

• 特定個人情報ファイルを取り扱う情報システムを使用できる者を事務取扱い担当者に限定する：データベースの権限管理 [Database Vault]

17

（赤下線箇所はオラクルが考える重要な箇所）


管理者権限の分離・最小化

18

対策を施していないケース

•DB管理者またはそのなりすましが、業務データを不正閲覧・改竄し、かつ監査証跡を削除可能

•業務データや監査証跡へのアクセス、ユーザアカウント作成も含め、DB管理者にDBに関する全権限を付与

DB管理者またはなりすましデータベース

業務データ（個人情報等）

監査証跡

不正閲覧・改竄

消去

構成変更・運用・監視（本来の業務）

権限を分離・最小化したケース

•DB管理者またはそのなりすましによる不正閲覧・改竄、監査証跡削除を防止

•管理者権限を分離（職務分掌）

•作業に必要最低限の権限のみを付与

DB管理者またはなりすましデータベース

業務データ（個人情報等）

監査証跡

構成変更・運用・監視（本来の業務）



E 物理的安全管理措置

C 電子媒体等を持ち出す場合の漏えい等の防止特定個人情報等が記録された電子媒体又は書類等を持ち出す場合、容易に個人番号が判明しない措置の実施、追跡可能な移送手段の利用等、安全な方策を講じる。（以下略）

＜＜手法の例示＞＞ • 特定個人情報等が記録された電子媒体を安全に持ち出す方法としては、持ち出しデータの暗号化、パスワードに寄る程、施錠できる搬送容器の使用等が考えられる。ただし、行政機関等に法定調書等をデータで提出するに当たっては、行政機関等が指定する提出方法に従う。

• 特定個人情報等が記載された書類等を安全に持ち出す方法としては、封緘（ふうかん）、目隠しシールの貼付を行うこと等が考えられる。

Oracle製品で考えられる解決策 – 持ち出しデータの暗号化：バックアップ等媒体の暗号化 [Advanced Security]

– 封緘(ふうかん)、目隠しシールの貼付：データの伏字（マスキング等）[Data Masking and Subsetting]

19



（続き） 2015年4月18日時点


d 情報漏えい等の防止特定個人情報等をインターネット等により外部に送信する場合、通信経路における情報漏えい等を防止するための措置を講じる

＜＜手法の例示＞＞ • 通信経路における情報漏えい等の防止策としては、通信経路の暗号化等が考えられる。

• 情報システム内に保存されている特定個人情報等の情報漏えい等の防止策としては、データの暗号化又はパスワードによる保護等が考えられる

Oracle製品で考えられる解決策 • データの暗号化：データベース上のデータ、バックアップ媒体、通信経路の暗号化

[Advanced Security, Oracle 標準機能]

20



Databaseの暗号化

21

対策を施していないケース

•サーバ／ネットワーク管理者による不正閲覧や盗聴

•バックアップ媒体の紛失・盗難による情報流出

•ストレージ上のデータベースファイル、媒体上のバックアップデータ、ネットワーク上のデータベース関連送受信データが暗号化されていない

暗号化したケース

•サーバ／ネットワーク管理者による不正閲覧や盗聴を防止

•バックアップ媒体の紛失・盗難時の情報流出を防止

•ストレージ上のデータベースファイル、媒体上のバックアップデータ、ネットワーク上のデータベース関連送受信データ等をすべて暗号化

佐藤良一佐藤良一佐藤良一

佐藤良一

個人情報が平文のまま伝送・格納されるため、不正閲覧・盗聴が可能

APサーバ DBサーバ

ストレージ

バックアップ

bD1##Ai aT3#_0Gk aT3#_0Gk

Pc#65qa

データベース関連のすべての情報を暗号化

APサーバ DBサーバ

ストレージ

バックアップ


Database暗号化の全体像

22

本番環境

DBサーバ

データファイル

索引ファイル

REDO ログ

アーカイブログ

バックアップファイル

ストレージ鍵管理

マスター暗号鍵

APサーバ

SQL文

データ書込

REDOログ災対環境

アプリケーションから透過的に暗号化（アプリ改修・チューニング不要）

ハードウェアによる暗号化/復号化処理の高速化暗号鍵を厳格に管理

データベースに関わるすべての通信を暗号化

データベース層ですべてのデータベース関連ファイルを暗号化

強力な標準共通鍵暗号方式を採用

DBレプリケーション



Ｃ組織的安全管理措置

ｅ取扱状況の把握及び安全管理措置の見直し

特定個人情報等の取扱状況を把握し、安全管理措置の評価、見直し及び改善に取り組む。

＜＜手法の例示＞＞ • 特定個人情報等の取扱状況について、定期的に自ら行う点検又は他部署等による監査を実施する。

• 外部の主体による他の監査活動と合わせて、監査を実施することも考えられる。

Oracle製品で考えられる解決策 • データベースへのアクセスを監視：データベースの監査・監視 [Audit Vault and Database Firewall]

23



（続き） 2015年4月18日時点


c 外部からの不正アクセス等の防止

情報システムを外部からの不正アクセス又は不正ソフトウェアから保護する仕組みを導入し、適切に運用する。

＜＜手法の例示＞＞ • 情報システムと外部ネットワークとの接続箇所に、ファイアウォール等を設置し、不正アクセスを遮断する。

• 情報システム及び機器にセキュリティ対策ソフトウェア等（ウイルス対策ソフトウェア等）を導入する。

• 導入したセキュリティ対策ソフトウェア等により、入出力データにおける不正ソフトウェアの有無を確認する。

• 機器やソフトウェア等に標準装備されている自動更新機能等の活用により、ソフトウェア等を最新状態とする。

• ログ等の分析を定期的に行い、不正アクセス等を検知する。

Oracle製品で考えられる解決策

• 監査・ログ分析・不正アクセス検知：データベースの監査・監視 [Audit Vault and Database Firewall]

24



DBセキュリティ製品のご紹介

25

Oracle Advanced Security


Oracle Advanced Securityが実現するセキュリティ対策

26

データの暗号化


リアルタイムアクセス制御

Data Redaction


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

カード番号の暗号化


TDE 表領域暗号化 • 表領域単位での暗号化

• 表領域内のオブジェクトはすべて暗号化される

• データブロックに対するI/Oで暗号化・復号化

• メモリ上は暗号化しない

• 暗号化してもデータサイズは変わらない

• Advanced Compressionとの併用可能

• ほとんどすべてのオブジェクトが暗号化可能 (BFILEのみ不可)

28

表領域暗号化

SGA

データベース

バッファキャッシュ

共有プール

REDOログ

バッファ

REDOログ UNDO表領域 TEMP表領域

表領域暗号化未設定

Disk I/Oで暗号化/復号

Oacle Keystore

(Oracle Wallet)

列暗号化マスター鍵

表領域暗号化マスター鍵

Walletをオープン


TDEの暗号鍵の仕組み • Oracle Keystore に、マスター暗号鍵が格納される (※11gR2まではOracle Wallet)

• マスター暗号鍵は、それぞれの列暗号鍵と表領域暗号鍵を暗号化する

• 表ごとの暗号鍵、表領域ごとの暗号鍵でそれぞれの実データを暗号化する

29

Oracle Keystore

パスワード認証

マスター暗号鍵

表暗号鍵

データ・ディクショナリ

表領域暗号鍵

表領域

Datafile

表領域暗号鍵

表領域

Datafile


マスタ暗号鍵の構成手順(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;


マスタ暗号鍵の構成手順(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


暗号化表領域の作成

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

• 表領域の作成時に列暗号化を指定

• 以降は、従来通り表を作成を作成する際の表領域として指定する


Oracle Data Redaction

33

• ユーザーの権限やクライアント情報に応じてリアルタイムにデータをリダクション

• アプリケーションのコード修正が必要のないデータベース内で完結する列アクセス制御

• コールセンターやサポート業務などの職責に応じた顧客情報へのアクセス制御の実現や PCIDSSに対応したクレジットカード番号の表示、アプリ開発者の直接アクセスも制御

クレジットカード番号

4451-2172-9841-4368 5106-6342-4881-5211 4891-3311-0090-5055

Policy データ

責任者

業務

オペレーター


サポートされるリダクションの種類

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


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


リダクション・ポリシーの作成 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


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ロールを持っていなかった場合


ユーザ識別子(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

ユーザ識別子を取得


各バージョンで使用できる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のみ



40

Oracle Database Vault


Oracle Database Vault 特権ユーザのための強制アクセス・コントロール

41


select * from finance.customers

職務分掌特権ユーザ（SYS, DBA権限）であっても情報にはアクセスさせない

透過的既存アプリケーションの変更不要、どの経路からのアクセスも一律に制御

厳密ユーザー、クライアント情報（IPアドレス、アプリ名）、時間を組み合わせたポリシー設定

管理者（特権ユーザ）

人事情報

顧客情報

財務情報


Oracle Database Vaultについて製品概要 • データベースのアクセス制御 –データベース接続やデータアクセスにルールを設定し、

DB管理者であっても操作を制限することが出来る

• DB管理者の権限を職務分掌 –一つのユーザに多くの権限を持たせず、必要な権限のみを持たせる

42

「職務分掌」とは、組織においてそれぞれの職務が果たすべき責任（職責）や職責を果たす上で必要な権限（職権）を明確にするために、職務ごとの役割を整理・配分すること。


Oracle Database Vault(DBV)について製品概要

43

業務データ

従来環境 DBV環境

データディクショナリ

DB管理者

データ参照

バックドアユーザ

ユーザ作成

権限付与

不正アクセス

業務データデータディクショナリ

DB管理者

データ参照

ユーザ作成

不正アクセス

セキュリティ管理者

ユーザ管理者

バックドアユーザ

権限付与

ルール適用

・DB管理者はシステム権限により

業務データにアクセス可能・DB管理者はユーザ作成/権限付与の両方が

可能であり、バックドアの作成が容易

・DB管理者は業務データにアクセス出来なくなる

・”ユーザ管理者”と”セキュリティ管理者”を作成される・悪意のあるユーザが2人以上いないとセキュリティインシデントにならない


Oracle Database Vaultについて

44

主な機能― レルム―

• 任意のスキーマ・オブジェクトのセットを保護・管理するための論理的な領域

• 不認可アクセスや DDL は、レルム違反エラーとなり、監査ログとして保存される

• レルムごとにデータの責任を持つオブジェクト管理者を作成することができる

HRテーブルデータディクショナリ

DB管理者

HR管理者ポイント： HR管理者の持っているオブジェクトをすべてレルムで保護すれば、DB管理者であったとしてもHRオブジェクトへのアクセスは許可されない。

DBV環境でもアクセスには通常のDB権限(オブジェクト、システム権限)が必要となります。


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のルールをそれぞれ作成し、ルール・セットに組み込む。


Oracle Database Vaultについて主な機能― コマンドルール― • SQLコマンドの発行を、ルール・セットに基いて制限するためのもの

• SQLコマンドに特定のルール・セットを紐付けておくと、ルール・セットがtrue となった場合のみ、そのSQLコマンドを発行する許可が与えられる。

– SQLコマンドの実行権限(システム権限やオブジェクト権限)は別途必要

46

ポイント： HRユーザを許可するルール・セットに

”CONNECT”コマンド”を紐付ける。

CONNECT

ルール・セット

ルール

ルールルール

HRユーザ

接続許可

HRテーブル


参考：コマンドルールで制御できる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表 +


厳密な権限＆ルールの設定により不正アクセスを遮断

48

ルール１(アクセス元)

IP Address: 192.168.1.XXX

APP Name: JDBC

アプリケーション用ルール

ルール１(アクセス元)

IP Address: 192.168.1.201

DB User: ADMIN01

ルール2 (時間)

09:00～19:00

開発者用ルール

select * from crm.customer

09:00～19:00の間

開発者

ユーザ・オブジェクト

表 - Customer - Order 索引プロシージャ

アプリケーションユーザー

ユーザオブジェクト:

認可


認可


非認可



19:00～9:00の間


管理者


Database Vaultによる権限分掌と相互監視

49

従来

特権ユーザ

HRユーザ

・ユーザ作成

・権限付与

・HR表への直接アクセス

・HR表への監査

SCOTT ユーザ

・HR表へのオブジェクト権限を付与

Database Vault 環境

リソース管理者（特権ユーザ）


オブジェクト管理者（ HRユーザ）

ユーザ作成

レルム所有者に任命

システム権限付与アクションを監査

オブジェクト権限付与

ユーザ作成

レルム参加者に任命

SCOTT ユーザ

システム権限付与


DBセキュリティ製品導入 Tips

50

Oracle Database Vault


推奨されるコマンドルール

• GRANT/REVOKE文 –権限付与のコマンドは特定ユーザのみに制限する

–不要な権限付与を制限し、不正な操作を抑止する

• NOAUDIT文 – NOAUDIT文を全ユーザで実行させない

※AVDF導入環境ではAVDF管理者のみ付与する

– DBで監査(AUDIT文)を使用していない環境下でも有効にすることを推奨

51


Database Vaultの監査証跡の管理とメンテナンス

• DBとDBVの監査証跡と別管理 – DBとDBVの監査証跡の管理は別ユーザで行う

– DBVの監査証跡は表領域に作成する必要がある

• DBVの監査証跡メンテユーザの作成 – DBV監査証跡をバックアップするためのユーザ

– Datapumpに必要な権限のみ付与する

※メンテユーザの監査証跡の改竄は不可

–バックアップファイルの管理は別で行う必要がある

52

DB 監査証跡

DBV 監査証跡

DB管理者セキュリティ管理者

DBV監査証跡メンテナンスユーザ

バックアップ

Datapump


DBV環境下での緊急対応時の運用案

1. DB管理者＋DBV管理者相当のユーザ作成 – DBのすべての業務が出来るユーザの作成し、緊急時の対応に備える

–通常運用では使用しない

–権限の強さはSYSDBAやroot(OS)ユーザ相当のため厳重に管理する

2. 緊急時の無効化スクリプトの準備 – DBVのコマンドルール/レルムを無効化ジョブするジョブを用意

– DBV機能のためにデプロイしたコンポーネントを削除するわけではない

※但し、通常DBA権限の一部が付与されていない点に注意が必要

53



54

Oracle Audit Vault and Database Firewall


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にも対応


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間に配置するインライン方式、ミラーポートを利用したアウトオブバンド方式、プロキシ方式の３種類

– Oracle Audit Vault Server

• Database Firewall Server、Audit Vault Agentから転送されるログを集約するリポジトリ・サーバ

• すべてのDatabase Firewall Server、 Audit Vault Agentの管理・監視を一元的に管理し、ログの分析やアラート、レポーティングを行う

– Audit Vault Agent

• 監査対象上で動作するJAVAアプリケーション。監査対象が出力した監査ログを収集し、定期的にAudit Vault Serverへ送信する


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)


エージェント方式

(Audit Vault)

User


Audit Vault Server

Database Server, OS等

Audit Vault

Agent


Oracle Audit Vault and Database Firewall(AVDF)について AVDFの機能概要 - ブロッキング • 搭載されたSQL文法解析エンジンが誤検出のない正確なブロッキングを実現

• アプリケーション、データベースの変更が必要のない透過的な構成 (インライン方式）

• 数万を超えるトランザクションでもオーバヘッドを感じさせない高速なマッチング処理を実現

58

インライン方式

(Database Firewall)

Database Server

User


Audit Vault Server

プロキシ方式

(Database Firewall)


Database Server

User

Audit Vault Server

Network Switch


リアルタイムアラートアラート条件に基づいて管理者に即座に通知 •Database Firewallがブロッキング、アラート検知した場合

•アラート条件としきい値を超えた場合、指定されたメールアドレスにアラートメール、SYSLOGで送信

59

Application Database Database Firewall

管理者

Alerts

Audit Vault Server

条件：

イベント時間

IPアドレス, ホスト名

エラーコード

ユーザ名

SQLコマンドなど


DBセキュリティ製品導入 Tips

60



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



AVDFの冗長化構成 Database Firewallの冗長化構成について

• AVDFを導入頂いている多くのお客様に、 Database Firewall障害による監査ログの取り漏れを防ぐため冗長化構成の採用頂いています。

– スイッチのミラーポートからデータベースの送受信アクセスを取得し、 Audit Vault へ送信

– 冗長化されたスイッチに対して２台のDatabase Firewallで接続し、ログの重複はペアリング機能で制御

– Database Firewallの障害時でも、片側のDatabase Firewallでログを収集する

– ローカルアクセスは取得できない

62

Database Firewall Server Audit Vault

Server

Application Database


セカンダリ・ルート (Standby)


SQL①

SQL②

SQL③

SQL①

SQL②

SQL③

SQL①

SQL②

SQL③

プライマリ

セカンダリ

監査ログ

ログの取得漏れを防ぐため SW-Database Firewall間のたすき

掛けが必須


AVDFの冗長化構成 Database Firewallの冗長化構成について – プライマリDatabase Firewall障害

1. プライマリDatabase Firewallに障害が発生

2. Audit Vault Serverが障害を検知

3. セカンダリDatabase Firewallがプライマリに昇格

4. Audit Vault Serverは新プライマリ(旧セカンダリ)を正とし監査ログを収集

63






SQL①

SQL②

SQL③

SQL①

SQL②

SQL③

プライマリ

セカンダリプライマリ昇格

L3SW#1

L3SW#2

監査ログ

Audit Vault Server


AVDFの冗長化構成 Database Firewallの冗長化構成について – SW-プライマリDatabase Firewall間ネットワーク障害 1. プライマリのSW-Database Firewall間のネットワーク障害が発生

2. ネットワーク監視による検知

3. 手動でセカンダリDatabase Firewallをプライマリに昇格

4. Audit Vault Serverは新プライマリ(旧セカンダリ)を正とし監査ログを収集

64






SQL①

SQL②

SQL③

SQL①

SQL②

SQL③

プライマリ

セカンダリプライマリ昇格

L3SW#1

L3SW#2

監査ログ

Audit Vault Server


AVDFの導入メリット監査証跡の運用時におけるメリット

• 冗長化構成によるセキュリティレベルの保持

• 監査証跡の完全性担保

– Audit Vault ServerにはDBVが標準インストール済み(監査証跡データへの不正アクセスや改ざんを防ぐ仕組み)

• 監査証跡の定期的な分析

– 取得した監査証跡はレポーティング機能を使い定期な分析を実施することで、不正アクセスや異常な行動を検知

– アラート機能を利用することで、緊急性の高いイベントに対してアラート通知が可能

• 監査証跡の保存ポリシー

– 監査証跡のオンライン、アーカイブ、バックアップ管理機能を標準機能として提供

• 複数DBの監査証跡を一元管理

– 複数DBの監査証跡をAudit Vault Serverで一元的に管理できる

65


セキュリティ製品導入プロジェクトのご紹介

66


データベース・セキュリティ対策項目の検討～よくある３要件８項目による検討例 • データベース・セキュリティの基本対策項目と想定機能の対応を以下に示します。

67

データベースセキュリティ対策

伏字化

アクセス制御

アクセスログ

領域分類

通信経路の暗号化

格納データの暗号化

テストデータのマスキング

DB接続／SQL実行の制限

機微データ（列）アクセスの制限

特権の制限

DB接続／SQL実行の証跡取得

不正識別／報告レポート

SSL/TLS

-

-

権限/ロール

-

-

監査ログ

-

-


Data Masking Pack

-

Data Redaction

Database Vault

-


Oracle Advanced Security （ASO）

Oracle Database Vault （DBV）


（AVDF）

Oracle Data Masking and Subsetting Pack

（DM）

セキュリティ対策項目識別１

（既存対策） DB標準機能オプション機能

識別2 （Oracle DB Security） DBセキュリティ用ライセンス名称


（参考）データベース保護のセキュリティモデル • 多階層防御と責任分解による多重的なデータ保護を推奨します。

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プロセス統制


セキュリティ製品導入プロジェクトのご紹介用語の解説

【発見的統制】・「悪いことが起きたことを見つける」仕組みのこと。

・監査証跡、ログ分析などの誰が何をやったかが追跡できる状態（責任追跡性）

【予防的統制】・「悪いことをさせない」仕組みのこと。

・ブロッキング、アクセスコントロールなどの強制力を伴うもの。

69

Oracleコンサルが考えるDBセキュリティ

•攻め ⇒ プロアクティブに抑止する … 【予防的統制】 •守り ⇒ 最終防衛としての監査証跡 … 【発見的統制】


要件 • セキュリティ要件：「何」を「誰」から守るかの整理・定義・ユースケース

設計 • セキュリティ設計：「何」を「誰」から「どのように」守るかの設計

実装 • セキュリティ実装：「何」を「誰」から「どのように」守るかの施行

運用 • セキュリティ運用：「何」を「誰」から「どのように」守り続けるかの確立

セキュリティ製品導入プロジェクトのご紹介セキュリティ実装までの流れ

70


セキュリティ製品導入プロジェクトのご紹介本プロジェクトの目的

71

A-DB C-DB D-DB B-DB DB統合 B C D A

現行環境

次期環境

•現行DBではDBAロールを使用するアプリが存在。

• セキュリティ強化に伴い、監査も強化したい。


お客様課題

DBAロールを保有ユーザは全業務データにアクセス出来てしまう



72

A-DB C-DB D-DB B-DB DB統合 B C D

DBAロール保有しているが範囲は限定

A



監査

監査 DB管理者

DB管理者

• DBAからアクセス権剥奪⇒DBV導入し解決

•監査強化⇒AVDF導入し解決

解決案


A-DB C-DB D-DB B-DB

DBV導入：・特権ユーザの業務データアクセスの制御・DBAロール保有ユーザによるバックドア作成の抑止

DB統合 B C D

DBAロール保有しているが範囲は限定

A



監査

監査

DB管理者

DB管理者

AVDF導入：・監査証跡の一元管理・AVDF標準機能による証跡の改ざん防止・レポーティング機能による監査証跡の定期的な分析

導入効果



1ヶ月 2ヶ月 3ヶ月 4ヶ月 5ヶ月 6ヶ月 7ヶ月 8ヶ月 9ヶ月

セキュリティ製品導入プロジェクトのご紹介スケジュール

要件定義

標準設計

詳細設計

運用設計

テスト

74

標準設計

詳細設計

運用設計

テスト

AVDF作業

DBV作業

DBV&AVDF作業

スケジュール初期の要件定義では予防的統制と発見的統制の2点を考慮したセキュリティ設計を実施。


セキュリティ製品導入プロジェクトのご紹介プロジェクトの作業フロー

• 要件定義

– 監査部からの統制内容は抽象的であったため、システムとしての統制を導くため｢何｣、｢誰から｣守るか整理する。

– 整理した要件を基に統制を内容の案出しを実施する。

– 運用コストなどを考慮してシステムとしての統制内容を決定する。

• 設計 / 実装

– 実装は基本的にDBVとAVで「実現できること」「実現できないこと」を検討する。

– 必須でない統制は運用コストを考慮してAVDFによる発見的統制に振り分ける。

標準設計詳細設計運用設計テスト

統制内容システム化

統制案リストアップ

統制案の実装方法

75


セキュリティ製品導入プロジェクトのご紹介要件定義（統制内容システム化） • 要件定義

• 統制内容システム化（ユースケースづくり）

– お客様にはセキュリティ要件を決定する監査部門から提示された監査要件が存在した。

– ただし、セキュリティ要件はシステム観点ではざっくりとした内容であるため、下記を整理する。

守りたいデータは何か

守りたいデータに対するアクセス(誰を許容して、誰を許容しないのか)

その他管理オペレーションの権限分掌

例) DBAユーザの顧客情報アクセスは制限したい。権限付与のオペレーションは管理したい。

• 統制案リストアップ

• 統制案の実装方法

76





セキュリティ製品導入プロジェクトのご紹介要件定義（統制内容システム化）- 管理オペレーションの権限分掌

• ユーザ定義

– 職責とそれに対するユーザのマッピングを行う。

– それぞれの職責で担当する作業を簡潔に洗い出す。

77


セキュリティ製品導入プロジェクトのご紹介要件定義（統制内容システム化）- 管理オペレーションの権限分掌 • 権限セット

– 各利用者を想定した権限セットを定義する。

– 各権限セットでは利用者に必要とされる最低限の権限を付与する。

78


セキュリティ製品導入プロジェクトのご紹介要件定義（統制内容システム化）- 管理オペレーションの権限分掌 • ユースケース

– システムライフサイクルの中の各局面で想定されるユースケースと実行するユーザ、業務内容と利用する権限セットをマッピングする。

79


セキュリティ製品導入プロジェクトのご紹介要件定義（統制案リストアップ） • 要件定義




守りたいデータ、守りたいデータに対するアクセス、その他管理オペレーションの権限分掌



– システム化する統制項目を製品に落とし込み、具体的な統制に対する実装をリストアップする。

例) DBV機能で顧客情報表を保護する。権限管理の操作はすべて監査対象とする。


– 「統制案のリストアップ」フェーズで洗い出した案のうち、設計コスト/運用コストを考慮して実装する内容を決定する。

例) DBVのレルムで保護を行う。AVDFでGRANT文を発行した証跡は取得する。

80





セキュリティ製品導入プロジェクトのご紹介要件定義（統制案の実装方法） • 要件定義




守りたいデータ、守りたいデータに対するアクセス、その他管理オペレーションの権限分掌



– システム化する統制項目を製品に落とし込み、具体的な統制に対する実装をリストアップする。

例) DBV機能で顧客情報表を保護する。権限管理の操作はすべて監査対象とする。


– 「統制案のリストアップ」フェーズで洗い出した案のうち、設計コスト/運用コストを考慮して実装する内容を決定する。

例) DBVのレルムで保護を行う。AVDFでGRANT文を発行した証跡は取得する。

81





セキュリティ製品導入プロジェクトのご紹介要件定義（統制案の実装方法）

• 要件定義


1人(ユーザ)に権限が集中しないように(1人で悪事ができない)権限分掌する。

基本的には各ユーザは必要最低限の権限を保持する。

DBAの業務データへの不要な参照は監査したい。

ユーザ作成、権限付与はバックドア作成の危険性があるコマンドの監視する。

(検討結果の例) ・不正なユーザ作成の防止・不正な権限付与の防止・不要な業務データへのアクセスの抑制・不正管理作業の監査

⇒ 権限分掌で実現 ⇒ 権限分掌またはレルムで実現 ⇒ レルムで実現 ⇒ AVDFの機能で実現

– 各統制内容の実装案については「統制の強さ」、「統制実装」を鑑みてコストのバランスを考慮する。

82

シンプルに構成





バックアップサーバからのSYSユーザのアクセスを監査(AVDF)

セキュリティ製品導入プロジェクトのご紹介要件定義（統制案の実装方法例）

83

発見的統制

予防的統制

DB管理者(SYS)

バックアップサーバからのみSYSユーザの接続許可しバックアップ

ユーザ管理者

AVDF監査

参照

バックアップサーバ

セキュリティ要件- 特定のサーバからのみ

DBバックアップが行えること

レルム保護

セキュリティ要件-XXXXXXXXXXXXXXXX


…

…



• RMANを使用するにはSYSDBA権限が必要

• 通常SYSDBAユーザでDBA業務を行わない

RMAN

取得

DBアクセス

バックアップサーバ

考慮事項


セキュリティ製品導入プロジェクトのご紹介勘所 – セキュリティはトップダウン

• セキュリティ方針はお客様の役員層からトップダウンで決まる。その方針をもとに要件定義行う必要があるため、プロジェクトでは必ずお客様の中でセキュリティ担当者を立てセキュリティ要件の洗い出しを行う。

– 関係者・部署または各担当との連携が重要 • ユースケースなどシステム部門(業務担当者)にしか出せない情報があり、関係者を巻き込んで進めることが重要である。またはその連携体制を作成・維持できることも重要である。

– セキュリティ要件は都度見直す必要がある

• セキュリティの脅威は急速に進化する。常に一定のセキュリティレベルを保つため、定期的にセキュリティポリシーを見直すことが必要である。

– 統制内容に関する落とし所 • 最低ラインを明確にしておく必要がある（｢誰が何を実施したか｣を特定できる発見的統制など）

• 要件定義は作成するが、スモールスタートを目指す

84

システム部門 (業務担当者)

セキュリティ部門

SIer

セキュリティアセスメント


セキュリティ担当者

セキュリティ担当

実装案要件業界スタンダードのセキュリティポリシーでシステム化を行うことは比較的容易です。各社でサイバーセキュリティに精通しているセキュリティ担当者をアサインすることが重要です。しかし、担当者の不在やスキル不足ですとプロジェクトで大きな問題となりえます。

プロジェクト体制図例


まとめ Oracleが考えるDBセキュリティの攻めと守りとプロジェクトの勘所

•攻めとは

85

【予防的統制】 ⇒ アクセス制御、権限分掌

【発見的統制】 ⇒ 監査証跡取得、証跡のモニタリング

セキュリティ脅威に対するOracle製品

DBセキュリティ製品導入プロジェクトの勘所

•守りとは … …

関係者・部署または各担当との連携が重要

最低ラインを定めてスモールスタート

セキュリティはトップダウン

セキュリティ要件は都度見直す


Appendix

86


補足：PCI DSS(Payment Card Industry Data Security Standard)

• クレジットカードを扱う業者の業界スタンダード基準

–加盟店・決済代行事業者が取り扱うカード会員様のクレジットカード情報・取引情報を安全に守るために、JCB、アメリカンエキスプレス、Discover、マスターカード、VISAの国際ペイメントブランド5社が共同で策定した、クレジット業界におけるグローバルセキュリティ基準。

• 12の「要件」として規定 –ファイアウォールを導入し、最適な設定を維持すること。

ネットワーク資源およびカード会員データに対するすべてのアクセスを追跡し、監視すること。 …などが12の要件に分かれています。

– 12の要件をさらに詳細な約200項目にブレイクダウンされています。

87


補足：セキュリティ施策の分類/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

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

















Oracle Enterprise Managerによる暗号化表領域の設定例

90


暗号鍵の管理

92


マスター暗号鍵の変更

93


Data Redactionの設定例

95


リダクション対象

・SCOTTユーザ

・CUSTOMER表



・FIRSTNAME列

・ランダムリダクション



・CARDNO列 (部分リダクション)

・FISRTNAME列 (ランダムリダクション)

・LASTNAME列 (ランダムリダクション)

・VALIDATE列 (フルリダクション)


リダクション条件

・SCOTTユーザ以外はリダクションさせる


リダクション・ポリシー定義

・SCOTTユーザ

・CUSTOMER表

・CARDNO列 (部分リダクション)

・FISRTNAME列 (ランダムリダクション)

・LASTNAME列 (ランダムリダクション)

・VALIDATE列 (フルリダクション)

・条件

・SCOTTユーザ以外はリダクションさせる


Data Redactionの設定完了

101


レルム作成の手順

103



104

1 2

必須レルムを選択

HRユーザのすべてのオブジェクトを対象 (％．％)にする



105

HRユーザをレルムの所有者として認可する

3 4


HRレルムが動作しているかの確認

106

SYSユーザからのアクセスはできない

HR_Realm

- HRのすべてのオブジェクトが対象 - HRがレルム所有者

・SYSやSYSTEMユーザ、DBAロール、SELECT ANY TABLE等の権限を持っていたとしてもレルム認可されていなければ、左記のようにアクセスはできない

・HRユーザがレルム所有者なので、オブジェクト権限(DML)の付与などの管理者としての役割を担う

・レルムに対するアクセス・ルールを含める場合は、後述のルールを設定する

データベース・セキュリティの実装 ... - oracle ·...

Documents