Oracle ユーザ管理ベストプラクティス
この記事は、筆者が独自に調査、検証したものであり、内容を保証するものではありません。
記事の内容を利用する場合は、個人・業務を問わず自己責任でお願いします。
Oracle ユーザ管理ベストプラクティス
俺的ベストプラクティスシリーズw
開発環境等、個人で利用するものに関してはここでは触れません。
特にプロダクション環境 ( 及び、複数人で利用するステージング環境 ) におけるベストプラクティス。
※ Oracle マスターではないので、誤った情報を含んでいる可能性があるかも。ご了承下さい。
※ プロダクション環境の DB にアクセスユーザをどのように管理すればよいかに関して、ベストプラクティス的なものを書きなぐってます。
※ DB に限らず、アプリケーションや OS の権限管理にも通じるものもあると思う。
※ 誰かがやらかしたときに勢いで書いたネタ...
※ かつての記事のリライトのため、現状の Oracle の仕様・UI とはズレがある可能性があります。
用語
用語をいくつか定義しておきます。
- DBA
Database Administrator の略。データベース管理者。データベースに対してなんでもできる(すべての権限を有する)人/アカウント - デフォルトユーザ
[第21回] デフォルトで最初から作成されているユーザー - プロダクション環境
本番/運用環境のこと - ステージング環境
検証等を行うための環境。本番適用前の事前検証やテストに利用される。個々の開発者の開発環境とは異なり複数人で利用される。
ベストプラクティス
ユーザではなくロールに権限を付与する
オラクルには ロール(ROLE) を扱う仕組みがあるので、 個別ユーザに権限を与えるのではなく ROLE に権限を割当て、個々のユーザはロールに属するよう設定を行います。
ユーザには必要最小限のアクセス権を与える。
管理を緩めにしたい場合、ユーザに多くの権限を割り振りたくなりますが、これによってセキュリティリスクをもたらす可能性があります。
重要なシステムの場合には、そのユーザが作業を行う上で必要最小限の権限のみ与えるようにしましょう。
監査を行う
オラクルにはログインの試行や作業内容を監査するための仕組みが存在します。
監査が無効な場合には、必要十分な監査が行えるように監査を有効にしましょう。
デフォルトユーザは可能であればロックする。
[第21回] デフォルトで最初から作成されているユーザー は攻撃者にとっては最も狙いやすいアカウントであるため、 可能であればロックするのが望ましいです。 ロックできないアカウントに関しては、十分な強度のパスワードを設定しましょう。
デフォルトユーザをDBAにしない
SYS/SYSTEM等のデフォルトユーザをDBAユーザにする事は簡単ですが、DBA操作を行う個人に対してDBAユーザを作成しましょう。これは以下の理由からです。
- 監査
共有の特権アカウントを利用している場合、どの利用者がDBA作業を行ったのか監査追跡を行うのは面倒です。個別のユーザを用意しておけば監査はより簡単に行えます。 - パスワード管理
DBAユーザでも自分以外のパスワードは知らない状態にすることで、離職時のパスワード管理が簡単になります。セキュリティや監査の面でも有効です。
DBAロールと開発者ロールを分ける
アプリケーションの開発中、特に開発環境においてはDBAと開発者は同一である事が多いですが、
プロダクション環境ではDBAと開発者は別の事が殆どです。
これら二つの役割(ジョブ)に対しては異なるロールを作成し、別々に権限を割り当てるようにしましょう。
アプリケーション/DBA用のユーザは匿名性を排除する
アプリケーションが利用するユーザは、どうしても代表ユーザになってしまうことがあります。
アプリケーション用の代表ユーザは強力な権限を持っており、アカウント情報が流出してしまった場合でもパスワードを変更することは難しい事も多いです。
しかし、運用担当者が離職した後でも、昔使っていたパスワードでシステムにアクセスできてしまうかもしれません。
データベースに直接アクセスするアプリケーションおよびデータベースの管理運用担当者用には、匿名性を排除して厳密なアクセス制御を行うために、個別のアカウントを作成するのが望ましいです。
ロールを入れ子にする
Oracle のロールはネストする事が可能です。
個人的に設定した事はないのですが、以下のような設定を行っているのを見たことがあります。
- 開発者用の
DEVELOPERロール - DBメンテナンス者用の
MAINTAINERロール DEVELOPERとMAINTAINERの両方の権限を有するMANAGERロール
DEVELOPER の権限が更新されると、MANAGERのロールも更新されます。 複数のタスクを行うジョブ(利用者)が存在する場合には、ロールをネストする事で管理を柔軟にし、管理コストを減らせる可能性があります。
CONNECT/RESOURCE ロールは利用しない。
CONNECTロール等の一部ロールは Oracle に組み込まれていますが、これらロールは利用しないようにしましょう。
10g R2 から「最低限の権限」原則により CONNECT および RESOURCE ロールは非推奨 になっています。
Oracle CONNECTおよびRESOURCEロールのまとめ
※ バージョンによって権限内容などが異なるようであるため、理解せずに利用するのは危険。
PUBLIC に注意する
PUBLIC に権限を付与すると、誰でもその権限を使用できるようになります。
ユースケースを元にロールを決める
運用を踏まえて以下を検討しましょう。
可能な範囲でよいので、アクセスマトリクスを作成する等して、権限をまとめ、可視化しましょう。
- 利用者
DBを利用するユーザは誰か。どんな利用者がいるか。 - 権限
利用者の種類(アクター)毎にどんな権限が必要か。
まとめ
開発段階にある場合など全て決めるのが難しい場合もあると思いますが、できる範囲でユーザ/ロールを策定しましょう。
新たなアプリケーションの追加や新機能の追加といったタイミング等、適当なインターバルで見直しを行いましょう。
問題発生時も見直すためのよい機会です。