※ 本記事は2016年11月24日に公開されたものです。
みなさんのデータベースにはどのようなアカウントが作成されていますか？
データベースアカウント一覧はたとえば下記のSQL文でリストできます。
select username from dba_users where account_status=’OPEN’;
SQL> select username from dba_users where account_status='OPEN'; USERNAME -------------------------------------------------------------------------------- APPUSER APP HR DBSNMP PUKU APPADMIN APP1 PDBADMIN APP2 SYSTEM SYS 11行が選択されました。
DBSATレポートでは「User Accounts」セクションの「User Accounts」から確認できます。
どんなタイプのアカウントがリストされていますか？
まず必ずあるのが、データベースが作成するアカウントです。
SYS、SYSTEMといったデータベースの管理アカウントや、DBSNMP、OUTLNといった特定の機能を利用する際に利用するアカウントもあるかもしれません。今回はOPEN状態のアカウントのみ表示していますので、使っていない機能のアカウントが表示される場合には、アカウントをロックすることも考慮して下さい。とくにHRやSCOTTなどのよく知られたサンプルスキーマのアカウントは攻撃の足がかりに利用される可能性があるので気をつけてください。
つぎにアプリケーションやプログラムが利用するアカウントがあります。データを格納するスキーマのアカウント、アプリケーションから接続するためのアカウントやバッチプログラムで利用するためのアカウントが分かれているケースもあるかもしれません。
そしてアプリケーション以外の管理者・運用担当者などの人間が利用するアカウントも分かれている事が多いと思います。APPADMINのように役割ごとにアカウントが作成されているケースや、個人用のアカウントが作成されているケースもあります。
では、どのようなアカウントがデータベースにあればよいのでしょうか？
アカウントは、アクセス制御のための基本の単位であり、監査をおこなう際に「誰が」おこなったかを確認する単位です。
アプリケーション以外の管理者・運用担当者などや、BIツールなどでデータベースに直接アクセス/認証するアプリケーションを利用している場合には、それぞれの個人にアカウントを発行することが理想的です。データベースの管理をおこなう人も、SYSやSYSTEMといったデータベース標準のアカウントを利用するのではなく、その人用の個人アカウントを作成するべきです。
個人にアカウントを発行することでそれぞれの個人の役割ごとに細かく権限を付与することができ、不要なデータにアクセスできないように設定できます。また、監査をおこなう際にも誰がその操作をおこなったのか、データにアクセスしたのかをきちんと把握することができます。
複数の人でデータベースアカウントを共有して利用した場合、その共有アカウントには個人が業務上必要以上の権限が設定されている可能性がありますので、本来アクセスできてはいけないデータにアクセスされてしまう可能性があります。また、監査をしても監査ログには実行者として共有のアカウントが記録されますので個人を特定できません。クライアントのIPアドレスやOSユーザーと組み合わせて個人を特定しようとしている場合でも、データベースサーバー直接、アプリケーションサーバーや他のサーバー経由など想定外の経路からアクセスされてしまうと誰がアクセスしたかの特定ができなくなります。また、ユーザーを共有している場合、パスワードをみんなが知っている状態ですので、部署移動などでその人が業務から外れた後もアクセスし続けることが可能となってしまいます。
アプリケーションやプログラムが利用するアカウントは、それ専用として人が直接データベースに接続するときには利用できないようにすべきです。この類のアカウントはパスワードを変更できないケースが多く、一度知られてしまうといつまでもアクセスし続けるができてしまいます。アプリケーションやプログラム用のアカウントは複雑なパスワードを設定して、そのアカウントは普段は利用しないように管理すべきです。
また、アプリケーションで利用するデータを格納するスキーマのアカウントと、アプリケーションから接続するアカウントは別にすべきです。データを格納するスキーマのアカウント、つまりデータを格納する表の所有者は基本的に自分が所有している表に対して全ての権限を持っています。マスター表やSOX関連の更新されてはいけないデータに対してアクセスを制限することができません。そのためアプリケーションやバッチプログラムでデータベースに接続する際にはそれぞれのアプリケーション、バッチで必要な権限のみを持つアカウントを個別に作成しそのアカウントでアクセスさせたほうが安全です。アカウントを細かく細分化することで、必要以上の権限を利用した不正な操作やミスによるデータ破壊・漏洩を防ぎ、監査をおこなう際にも、想定外の経路からの不正アクセスの兆候を検知しやすくなります。
アカウントは細分化すればするほど、厳密なアクセス制御や監査を適用することができるようになりますが、入社・異動・退職に伴うIDライフサイクル管理の運用・管理コストは高くなります。また、せっかく個人用のアカウントを作成し、各アプリケーション用にアカウントを細分化しても、すべてのアカウントにDBAロールやSELECT ANY TABLEといった全ての表にアクセスできるような強力な権限を与えてしまっては意味がありません。
きちんと運用がまわる範囲で「共有ユーザー利用などの匿名性を排除する」という考え方に従ったアカウント管理を計画して下さい。