※ 本記事は2017年2月13日に公開されたものです。
Oracle DatabaseにはPUBLICという特別なロールがあります。ちなみに11g以降のマニュアルにはPUBLICロールと記載されていますが、10g以前ではPUBLICユーザー・グループと表記されており、DBA_ROLESにはリストされず、DBA_USERSにリストされているため、純粋なロールと言い切れないところが特別なロールと記載した理由です。DBA_USERSにリストされるので最新のマニュアルなどの資料でもユーザーと表記されている個所もあります。
このブログでも実はカテゴリ分類をおこなっていて、「ID管理・認証」というカテゴリと「アクセス制御」というカテゴリがあります。PUBLICがユーザーの場合は「ID管理・認証」に分類されますが、ロールの場合は「アクセス制御」に分類されます。ここではPUBLICはロールという事にして「アクセス制御」に分類します。まぁ、どうでもよい話ですが。
このPUBLICロールにシステム権限やオブジェクト権限を付与した場合、その権限はすべてのデータベースユーザーが利用可能になりますので注意が必要です。マスター表など他のユーザーにも見せたい表へのアクセス権限を面倒だからといってPUBLICロールに付与してしまっているシステムを見かけますが、他のシステムのデータも同じデータベースに格納されるようになったり、データベース統合をおこなったりすると、関係ない人からも見えてしまいますので注意が必要です。最小権限の原則の実現のためにも、PUBLICロールには追加で権限を付与しないようにしましょう。
また、デフォルトでPUBLICロールに付与されている権限にも注意が必要です。
このロールには下位互換のために必要以上に強力な権限が付与されています。
たとえば、Database Vaultを有効にすると、PUBLICロールからはUTL_FILEパッケージプロシージャへのEXECUTE権限が取り消されます。UTL_FILEパッケージプロシージャは外部OSファイルに入出力ができるようになるため、データベースの情報が外部ファイルに書き出される危険性を最小化するためです。この動作はマニュアルにも記載されています。
そのほかにもUTL_TCP、UTL_HTTP、UTL_SMTPといった様々なプロトコルで外部と通信するためのパッケージプロシージャもPUBLICに付与されていますので、データベースサーバーに対するインバウンドの通信を制限するだけでなく、アウトバウンドの通信の適切に制限しておくべきです。
PUBLICロールは昔からある機能で、古いシステムで利便性のために利用されたままになっていることもあります。PUBLICロールの気軽な利用は情報漏洩のリスクにもなり、またデータベース統合の妨げにもなります。新しく作成するシステムではPUBLICロールに権限を追加しないようにし、既存のデータベースでもPUBLICロールにアプリケーションデータへのアクセス権限やカスタムプログラムの実行権限が付与されていないかどうか棚卸してみてください。