第２回データベース・セキュリティ・コンソーシアム セミナー

<写真欄>

内部統制時代のデータベース・セキュリティ
日本オラクル株式会社
システム製品統括本部 北野晴人
2006年11月7日

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

財務諸表・IT業務処理統制・IT全般統制
財務諸表上の重要な勘定科目（ビジネスプロセス）
貸借対照表 損益計算書 資金計算書

注記

その他

業務プロセス・取引のクラス（ビジネスプロセス・行動規範）
プロセスA
プロセスB
プロセスC

IT業務処理統制
• 網羅性
• 正確性
• 妥当性
• 承認
• 職務の分離財務アプリケーション（統制の自動化）
アプリケーションA
アプリケーションB
アプリケーションC

ID・権限管理のための基盤
データベース
オペレーティングシステム
ネットワークCopyright© 2006, Oracle. All rights reserved.

IT全般統制• プログラム開発• プログラム変更• コンピュータ運用• プログラムとデー
タへのアクセス管理• 統制環境3

データベース・セキュリティに求められるもの
IT全般統制の中で「情報の正しさ」を保証することで業務処理統制上の統制活動の正当性を担保しなければならない。
–業務アプリケーションにおける統制活動が有効に機能することをインフラ側で保証する必要がある。
–全てのセキュリティ対策はこの点に貢献している。

「情報が正しい」という証明ができなければならない。
–情報にかかわる変更履歴の保持と保全が必要となる。
–データベースの管理操作についても履歴が必要になる。
–権限の付与プロセスについても統制と履歴の保持が必要になる。

Copyright© 2006, Oracle. All rights reserved.

4

①情報の正しさを保証する -職務分掌一般的な職務分掌（予防的統制）–職務を分離し相互監視、ダブルチェックの仕組みをつくる。
（例：支払いの実行者と承認者を分離する）

支払いの実施支払いの申請者

支払いの承認者支払いの実行者

データベースにおける職務分掌––データベース管理者と開発者・一般ユーザ利用できる権限・操作と職務の一致

職務分掌＝データベース内での最小権限
Copyright© 2006, Oracle. All rights reserved.

5

①情報の正しさを保証する -職務分掌最小権限を実現できる設計と実装が必要。
––––

スキーマ構造の検討
オブジェクトに対するアクセス権限（DML)の最小化
ビュー、その他を利用したアクセスコントロール
管理操作（DDL文など）の最小化

データベース管理者（DBA)に対する抑止策を実装する。
––

仮想的に分割して管理者を分離するデータベース
管理者権限を制限できるデータベースの利用（事実上のデュアルロック機能が必要）※デュアルロック：「政府機関の情報セキュリティ対策のための統一基準」にある強化遵守事項の一つ

Copyright© 2006, Oracle. All rights reserved.

6

職務分掌の観点からはDBAが課題
DBAが本来すべき作業
運用–
–

–

•データの盗み見、不正持出し
バックアップ、リカバリ
インスタンス管理
起動、停止、Table Space、データファイルの拡大

チューニング作業––

DBAができてしまう作業–全従業員の給料、個人情報–決算発表前の会計データ–全顧客データ•不正なコマンド発行–全ビジネスデータの削除、SGAメモリのサイズ変更、
Redoログバッファのサイズ調整–不当なデータのUpdate–アプリケーションへの不要なユーザーの作成

Copyright© 2006, Oracle. All rights reserved.

7

職務分掌の観点からはDBAが課題
DBAが本来すべき作業
運用–––DBAができてしまう作業

データベース利用者
データベース利用者•データの盗み見、不正持出し

バックアップ、リカバリ–全従業員の給料、個人情報インスタンス管理
明確な職務分掌が必要–決算発表前の会計データ起動、停止、–全顧客データ
Table Space、データファイルの拡大•不正なコマンド発行

データベース管理者
データベース管理者

チューニング作業–全ビジネスデータの削除、SGAメモリのサイズ変更、–不当なデータのUpdate
内部統制上、「データベース利用者」と「データベース管理者」– Redoログバッファのサイ–アプリケーションへのは明確に区分されるべきズ調整
不要なユーザーの作成–

相互に監視できる仕組みを確立することが重要Copyright© 2006, Oracle. All rights reserved.

8

内部統制の強化のための職務分掌イメージ
可：セキュリティポリシーの決定、適用
不可：ビジネスデータの操作、DBA業務

セキュリティ管理責任者 Aさん

DBA業務

情報システム部
データベース管理者
Bさん

可：DBA業務不可：ビジネスデータの操作

人事部給与担当 Cさん

可：給与データの管理

Copyright© 2006, Oracle. All rights reserved.

9ご参考：Oracle Database Vault でできること
データベース管理者の権限を制限 〜権限の分割〜〜 今までの Oracle Database 〜
データベース管理者に管理権限が一極集中
データベース管理
データベース管理者〜 Oracle Database Vault 〜
複数の管理者に管理権限を分割、分担
データベース管理

ユーザー・アカウント管理
セキュリティ・ポリシー管理
アプリケーション・データの管理

データベースの起動停止から、全スキーマ・オブジェクトの操作やセキュリティの設定まで、あらゆるシステム権限の実行が可能
データベース管理者自身による、不正なデータの操作や情報漏えいのリスク！

管理権限の一極集中によるリスクを回避し、各役割に応じた権限のみを持つ 複数の管理者によって、データベースを安全に管理
日本版SOX法などの法規制に備えた、内部日本版SOX法などの法規制に備えた、内部統制の基盤作りが可能

データベースの起動/停止 など※実データへのアクセス不可！

データベース
管理者

ユーザー・アカウント管理
ユーザの作成・変更、プロファイルの作成・変更、接続の許可※実データへのアクセス不可！

アカウント管理者

セキュリティ・ポリシー管理
セキュリティポリシーに基くアクセス制御の設定、管理※実データへのアクセス不可！

セキュリティ
管理者

アプリケーション・データの管理
アプリケーションに紐付く実データの管理、アクセス権限の付与

Copyright© 2006, Oracle. All rights reserved.

アプリケーション
管理者

10

ご参考： Oracle Database Vault でできること
様々な条件に基く強靭かつ柔軟なアクセス制御〜 今までの Oracle Database 〜
権限さえあればデータへのアクセスが可能〜 Oracle Database Vault 〜
権限に加え、複数の条件を満たす場合のみデータへのアクセスが可能

SELECT権限
一般ユーザ INSERT権限
UPDATE権限
DELETE権限
・・・etc.
ロール

SELECT権限
INSERT権限 一般ユーザ
UPDATE権限
DELETE権限
・・・etc.
ロール

アクセス制御条件

セキュリティポリシーに則った複合条件に基くアクセス制御が可能
様々な条件を柔軟に設定可能

条件を満たす場合はアクセス可能
条件を満たさない場合はアクセス不可能

OSユーザ
ホスト
クライアントのIP
時間帯
曜日･･･etc

ロールを有効化するための条件を評価※上記はあくまでも一例です。要件に合わせ、複雑な条件設定も可能です。

Copyright© 2006, Oracle. All rights reserved.

11ご参考： Oracle Database Vault でできること
Realm や Command Rule によるデータの保護
Realm (レルム)

Command Rule (コマンド・ルール)

スキーマあるいは一部オブジェクトのセットを保護・管理するための論理的な単位。
– レルム所有者はDBAの権限と役割を持ち、システム権限の行使やオブジェクト権限の付与等を行うことが可能。ただしその権限はレルム内に閉じるため、他レルムに対する操作は実行不可能。
–

HRシステム

各SQLコマンドの実行をアクセス制御条件に基いて制限するためのもの。
– 紐付くアクセス制御条件を満たす場合にのみ、その SQLコマンドを発行する許可が与えられる。
※注：各コマンドの実行権限は別途必要。
–【例】CREATE TABLE emp….

レルム
許可

アクセス制御条件

HRシステム管理者

データディクショナリ
レルム

OSユーザ
ホスト
クライアントのIP
時間帯
曜日･･･etc

データベース
管理者

Copyright© 2006, Oracle. All rights reserved.

False

禁止12

②情報が正しいと証明する
各種監査ログの取得と保全が必要。
––

ログを取っておくだけではなく活用するフェーズへ
定期的な傾向分析による不正の早期発見

ユーザのID・権限・ロールの付与プロセスやポリシーを管理する必要がある。
–––「権限を与えて良い」と誰が承認するのか？
承認のポリシーとプロセスは可視化されているか？
IDの生成・変更・削除とそれにともなう承認プロセスは履歴を保持しているか？

Copyright© 2006, Oracle. All rights reserved.

13

②情報が正しいと証明する
監査ログの取得と保全から分析・活用へ

監査対象のデータベース

監査ログ

Business Intelligenceによる多次元分析
フラットファイル等別形式のログ・リスナーのログ・ファイア・ウォール・IDS・OS・Apache・その他

監査ログ

監査ログ分析用
データベースに集約・保全する

別形式のログはツール等で変換しRDBMSに取り込むことで一元的な分析を可能にする

取り込み

蓄積

Copyright© 2006, Oracle. All rights reserved.

分析

ブラウザ

セキュリティ管理者
内部・外部監査人
追跡・証拠保全14

②情報が正しいと証明する
ＩＤ管理基盤（アイデンティティ・マネジメント）によるユーザ・権限・ロールの一元管理と履歴の取得–

ＯＳ・アプリケーションなど様々なＩＤを一元的に管理する必要があるためデータベースもここに取り込む。
管理者
承認・権限設定等
ID・権限の設定

IDの取得申請
付与プロセスの履歴
ユーザ（開発者・管理者など）

レポートとして内部統制
評価・監査に利用

Copyright© 2006, Oracle. All rights reserved.

15

ご参考：Oracle Identity Managerを使ったID管理
Oracle IdentityManager
ユーザ

承認
RequestEngine

セルフサービスによるID取得申請

ユーザ（派遣社員）

承認
ワークフロー

承認 1

プロビジョニング
ワークフロー

データベースへのユーザ・ロール等作成

承認 2

Copyright© 2006, Oracle. All rights reserved.

16

日本オラクル株式会社 無断転載を禁ず
この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。
日本オラクル社は本書の内容に関していかなる保証もいたしません。また、本書の内容に関連したいかなる損害についても責任を負いかねます。
Oracle、PeopleSoft、JD Edwards、及びSiebelは、米国オラクル・コーポレーション及びその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標の可能性があります。