※ 本記事は2018年3月28日に公開されたものです。
SYS、SYSTEMといったデータベースの事前定義の管理ユーザーやアプリケーションのユーザーを複数のデータベース管理者、アプリケーション管理者で共有しているシステムはまだまだ多いのが現状です。強力な権限を持ったユーザーを共有して利用することは、必要以上の操作をおこなうことができ、誰が操作したかを特定しにくくなるため、情報漏えいなどの不正アクセスのリスクを高め、その被害を増大させます。また、みんながパスワードを知っている状態にあるため、部署異動や退職などでその業務をおこなわなくなった後でもデータベースにアクセスするための認証情報を知っている状態になります。このような状態でも、特にアプリケーションのユーザーのパスワードは複数のプログラムやアプリケーションサーバーに埋め込まれていることが多いので変更することができないケースも多いです。
誰が操作したかを特定し、部署異動や退職でアクセスの必要がなくなった後に確実にアクセスできないようにするためには、データベースに直接アクセスする利用者には個人用のデータベースユーザーを作成して、利用者がデータベースにアクセスする必要がなくなった時にはそのユーザーを削除する仕組みが必要です。
ただし、既存システムで個人用のユーザーを作成するだけでは匿名性の排除することはできません。個人用のユーザーを利用するようにガイドしていても、共有していたアカウントがそのまま残っている場合、そのパスワードを知っていればそのアカウントも利用しつづけることができてしまいます。通常の運用は個人用のユーザーを利用していても、たとえばそのユーザーでは権限がなくてできない処理があった場合、パスワードを知っているSYSTEMユーザーで接続して作業をおこなってしまうかもしれません。また、データ盗難など悪いことをしようとした際には、犯人が特定されやすい個人用のユーザーではなく、個人を特定できない共有ユーザーを使おうとすることは想像しやすいです。
匿名性を排除するためには、個人用のIDの利用を徹底するだけではなく、共有IDを利用できないようにすることが重要です。
共有IDを利用できないようにするための根本的な解決方法はSYS、SYSTEMといった事前定義の管理ユーザーやアプリケーション、バッチ用などプログラムが利用するユーザーのパスワードを知られないようにすることです。新しくシステムを構築する場合には可能かもしれませんが、既存システムの場合、前述の通りパスワードを変更することができない場合もあります。
また、Oracle Databaseの場合、データベースサーバーのOSの特定の(例えばdba)グループに所属しているユーザーは、OSで認証されている場合、データベースで再度認証されることなくSYSユーザーとしてデータベースに接続できますので、OSユーザーの管理も重要となります。
このようにパスワードが知られていたりOSで代理認証されたりするなど個人用のID以外でデータベースに接続できてしまう場合、認証をさらに厳密にしたり、接続されてもデータにアクセスできないようにする仕組みが必要です。この対策は新規システムにおいても万が一のパスワードが攻撃者に知られてしまった場合でも情報漏えいしないようにするためにも活用できます。
具体的には「アクセス経路の限定」をおこないます。たとえばデータベースサーバーOSやデータベースサーバーに接続できる元を制限します。ネットワーク層でアプリケーションサーバーや運用端末以外からのアクセスを遮断する方法があります。ただし、ネットワーク層でのアクセス経路の制限では、IPアドレスレベルの対応は可能ですが、データベースユーザーごとの対応はできません。そのためアプリケーションサーバーからデータベース管理ユーザー(SYSやSYSTEM)での接続を制限することはできません。
データベースユーザーやアクセス元のIPアドレス、アプリケーション、OSユーザー、時間など詳細な条件を組み合わせて接続の許可・遮断やデータへのアクセスの許可・遮断を実施したい場合には、Oracle Database Vaultを利用する必要があります。Oracle Database Vaultを利用することで、データベース管理ユーザー(SYS、SYSTEM)を含めたすべてのデータベースユーザーに対してアクセス制御を実現することが可能となります。
また共有IDが不正に利用されていないことを確認するために「監査と監視」が重要になります。Oracle Databaseではリリースされた最初のバージョン(Oracle V2)から監査機能がついていました。Oracle Database 11gからはデフォルトの監査設定が変更され、ログイン成功および失敗の監査が自動的に有効化されています。Oracle Database 12cからは、ログイン失敗のみ監査するようデフォルト値が変更になっていますが、不正利用がなかったことを確認するためにはログイン成功も監査することが必要です。Oracle Database 12c以降の統合監査では、詳細な監査条件を指定できるためアプリケーション用のユーザーが想定されたアプリケーション(IPアドレス、OSユーザー、プログラム名など)以外からログインがあったときのみ監査するといった設定ができます。
取得した監査ログは、たとえばアプリケーション用のIDでアプリケーション以外から直接データベースに接続した形跡がないか、計画外のデータベース管理ユーザーでの接続がないかを定期的に確認することで、不正アクセスにいち早く気づくことができます。またこのような監視の仕組みを導入しているしていることを広く認知させることで、内部不正の抑止効果も期待できます。
コンプライアンス対応などのために、データベースに対しても個人用のIDを作成することが少しづつ一般化してきているように感じます。しかし、個人用のIDを作成するだけでなく、共有IDを利用できないようにしないと、個人用のIDを作成した意味が薄れてしまいますので注意が必要です。
この連載の第1回「はじめに ～ データベースセキュリティの基本的な考え方」では、データベースのセキュリティを担保するうえで重要なポイントとして以下の5つをあげています。
- 共有ユーザー利用などの匿名性を排除する
- 重要なデータは集中管理し、アクセス経路を限定する
- 最小権限の原則に則ったアクセス制御を強制する
- 暗号化したほうがよいか迷うものは、すべて暗号化する
- 監査するだけでなく、監視する
これらはすべて単体で考えるものではなく、今回「匿名性の排除」のために「アクセス経路を限定」したり、確認のために「監査と監視」をおこなう必要があると説明したように互いに補完しあいながら機能しています。既存のシステムに対してすべてを一度に実施することは難しいかもしれませんが、これらのポイントを気にかけながら運用改善、新規システムの構築をぜひ実施していってください。