Oracle® 非公式 SQL, PL/SQL & DBA's リファレンス

セキュリティの管理と監視

個人情報保護法にともなって、情報漏えいは会社の経営に致命的なダメージを与える。 モールによる BtoC のクレジットカード情報の流出 … 客離れはおそらく致命的だろうと思う。 しかし、一様にウィルス対策ソフトのパターンファイルやファイアウォールばかりに気をとられている。 それらは企業では基本ソフトの一部であって個人でも使用されている。導入・メンテナンスしてない方がめずらしい。 データの漏洩対策と呼べるものではないといえる。

一方ではサーバーセンタへの入館に IDカード認証だけではなくバイオメトリック認証まで採用しサーバー本体は耐火、耐震、対電磁波装備の特殊なサーバーラックに格納しているところもある。
監視ツールや暗号化の技術を使用したオプションの使用やパッケージが必要なのである。稟議にそろそろ判子を押させるときがきている。一気に予算書を押し通すには良い頃合である。
(開発費 ソフトの代金 軽く超す、されど稟議は 毎回通らず(字余り)。詠み人知らず 心のさけび)

初期化パラメータ

• DICTIONARY アクセスの制限

データ・ディクショナリ を DBA 権限なしにアクセスできないようにする(8i以下で要対処)
「ANY」のシステム権限を持つユーザーをデータ・ディクショナリにアクセスさせない。

07_DICTIONARY_ACCESSIBILITY = FALSE

• リモート認証

リモート認証を行わないようにする。

REMOTE_OS_AUTHENTICATION = FALSE

ファイルアクセス

• UTL_FILE_DIR 初期化パラメータは使わない

UTL_FILE_DIRにはデータベースのユーザーを区別する概念がない。オラクルの全ユーザーがパーミッションが 666, EVERYBODY読み書き可みたいなもの。
10g には、より強力なサブプログラムが追加されているので、それ以上かもしれない。マニュアル上では UTL_FILE_DIR 形式では使用できないようではある。
また、UTL_FILE_DIR 初期化パラメータの変更はデータベースの再起動を伴うためメンテナンス性も悪い。
( Oracle 9i 以降の場合には、DIRECTORY 経由でアクセスを行うようにすることを強くお勧めします。)

なお Windows系で利用できるワイルドカード指定は情報漏えいに神経質な時代背景もあり、 セキュリティポリシー(業務設計)上でも大きな問題がある設定と見なされる箇所と判断される可能性が高い。
開発担当レベルで安易に設定すると後でクライアントに指摘されて信用低下する可能性が高い、新規案件では面倒でも使用は控えた方が無難。

要注意 UTL_FILE_DIR = '*' の指定は、さらに危険な状況である。これは監査を放棄しているとも取られかねない。なぜなら監査ファイルへの読み書きも許可しているため不正なアクセスの隠蔽と改ざんを許可していると同じである。この状況は、まるで SECOM などの警備会社と契約をしていながら、面倒だからといって勝手口を開け放ったまま近くのスーパーに買い物へ行くようなものである。

• 関連事項

  UTL_FILE の使い方 (UTL_FILE_DIR 編)
  UTL_FILE の使い方 (DIRECTORY 編)

LISTENER

• リスナーのセキュリティ

Oracle 9i から暗号化パスワードが導入されたのでリスナーにはパスワードを設定しておく。(以前は、パスワードが そのままテキスト格納)
注意 暗号化してないパスワードが設定されている場合は削除しておかないと設定できない。
listener.ora を確認する。 PASSWORDS_listener_name = (XXXXXXXXX) ← 暗号化された文字列

lsnrctl
> change_password
 Old password: …
 New password: …
> save_config
または
Net Manager(netmgr:Linux)を使用してパスワードを設定する。

リスナーの起動、停止と初期設定

• 外部プログラムとの接続の削除

  PLSEXTPROC の記述を削除する。(外部プロシージャを使用しない場合)
  過去に PLSEXTPROC には全バージョンで任意のプログラムが実行される脆弱性が指摘されている。念のためにも、利用しないのならば必ず無効化しておく。
  listener.ora の編集(以下の部分を削除)

SID_LIST_LISTENER =
 (SID_LIST =
   (SID_DESC =
     (SID_NAME = PLSExtProc)
     (ORACLE_HOME = ....10.1.0\db_1)
     (PROGRAM = extproc)
   )
 )

• 接続先の制限

  アプリケーションサーバーなどからの接続だけを許可する。
  sqlnet.ora を編集する。

TCP.VALIDNODE_CHECKING = YES
# 接続許可するホスト(IP アドレスが望ましい:hostsの改ざん、DNSの不正書換え)
TCP.INVITED_NODES=(localhost.localdomain, 192.168.0.1)
# 一部を排他したい場合
TCP.EXCLUDED_NODES=(192.168.1.1)

データベース接続ユーザー管理

デフォルトでインストールされるユーザーをロックする。
※ DBCAでDB作成時には自動で行われている。(手動作成時にはロックを行う)

Oracle 9i

SYS/SYSTEM/DBSNMP/OUTLN/
JSERV(AURORA$JIS$UTILITY$,AURORA$ORB$UNAUTHENTICATED,OSE$HTTP$ADMIN)
以外のユーザーはロック

Oracle 10g

SYS/SYSTEM/SYSMAN/DBMSNMP/MGMT_VIEW/
以外のユーザーはロック

• 接続可能なユーザー一覧

   SELECT USERNAME, ACCOUNT_STATUS
     FROM DBA_USERS
    WHERE ACCOUNT_STATUS = 'OPEN' ;

• 使用しないユーザーのLOCK & EXPIRE

  ALTER USER db_user ACCOUNT LOCK PASSWORD EXPIRE;

• 参考資料 Oracleにより自動で作成されるユーザーのリスト

権限に関するセキュリティ

PUBLIC ユーザーへの実行権限

⇒ PUBLIC に関するセキュリティ管理

要注意の権限のユーザーを抽出

ANY、DBLINK、BECOME USER、UNLIMITED、ADMIN OPTION 権限のユーザーを抽出

SELECT
	GRANTEE AS USERNAME, PRIVILEGE, ADMIN_OPTION
 FROM
	DBA_SYS_PRIVS 
WHERE
(
	PRIVILEGE LIKE '% ANY %'
	OR PRIVILEGE LIKE '%DATABASE LINK%'
	OR PRIVILEGE LIKE '%UNLIMITED%'
	OR PRIVILEGE = 'BECOME USER'
	OR ADMIN_OPTION = 'YES'
)
AND GRANTEE NOT IN (
	'SYS', 'SYSTEM', 'OUTLN', 'DBSNMP', 
	'DBA', 'CONNECT', 'RESOURCE', 
	'EXP_FULL_DATABASE', 'IMP_FULL_DATABASE',
	'AQ_ADMINISTRATOR_ROLE', 'OEM_MONITOR', 'CTXSYS', 'IFSSYS',
	'IFSSYS$CM', 'MDSYS', 'ORDPLUGINS', 'ORDSYS',
	'TIMESERIES_DBA', 'WKSYS', 'SYSMAN', 'OLAPSYS',
	'OLAP_DBA', 'EXFSYS', 'SCHEDULER_ADMIN', 'WMSYS',
	'SI_INFORMTN_SCHEMA', 'JAVADEBUGPRIV', 'MDDATA',
	'RECOVERY_CATALOG_OWNER'
)
AND GRANTEE NOT IN (
	SELECT USERNAME
	  FROM DBA_USERS
	 WHERE ACCOUNT_STATUS != 'OPEN'
)
ORDER BY 1, 2 ;

• 参考資料 Oracleが自動で作成してしまうユーザーとデフォルトパスワードのリスト

TRUNCATE TABLE を使用することで発生しそうな権限の問題

通常セキュリティ上の理由からオブジェクトのオーナとプロシージャの実行者(システム利用者)は異なる。 そのため TRUNCATE TABLE を実行させるためにマニュアル通り DROP ANY TABLE を付与してしまうケースが多い。
(詳細へ...)

ファイングレイン監査

Oracle 9i Enterprise からの行レベルの監査機能
監査の単位を 行の条件レベルの精度で行うことができる。 DML（INSERT / UPDATE / DELETE）は勿論 SELECT も監視対象にでき、実行したSQL文の内容も取得することが可能。
(ファイングレインの監査の例...)

PL/SQL による暗号化とソースコードの隠蔽

• 暗号化ツールキット(DBMS_CRYPTO、DBMS_OBFUSCATION_TOOLKIT)
• ソースコードの難読化（リバースエンジニアリング防止）

---