X

クラウド・セキュリティの考え方、コンプライアンス、製品・サービス(データベースセキュリティ・IDaaS・WAFなど)

[第16回] アプリケーション用のユーザー

データベースのアカウントの分類方法は様々ありますが、どのように利用されることを目的として作成されたかという観点からだと下記の3つに分類できます。

 

  • アプリケーション用のユーザー(人間が使わないアカウント)
  • 直接データベースにログインして利用するユーザー(人間が利用するアカウント)
  • デフォルトで最初から作成されているユーザー(運用フェーズでは誰も利用すべきでなないアカウント)

 

ここではまずアプリケーション用のユーザーの作り方の考え方を説明します。もちろん、これが唯一無二の方法ではありませんが、セキュリティを担保するためのデータベースユーザー作成の考え方のひとつとして参考にしていただければと思います。

まず、アプリケーションで利用するデータを格納するスキーマのアカウントと、アプリケーションから接続するアカウントは別にすべきです。データを格納するスキーマのアカウント、つまりデータを格納する表の所有者は基本的に自分が所有している表に対して全ての権限を持っています。マスター表やSOX関連の更新されてはいけないデータに対してアクセスを制限することができません。そのためアプリケーションやバッチプログラムでデータベースに接続する際には、故意もしくはミスによるデータ破壊を防ぐためにも、それぞれのアプリケーション、バッチで必要な権限のみを持つアカウントを個別に作成しそのアカウントでアクセスさせたほうが安全です。ただし、アカウントを細分化していくと管理が大変になるので、そのシステムや格納しているデータの重要度とシステム管理の容易性をはかりにかけてアカウントを分割して下さい。

作成したアカウントのパスワードは容易に想像できない複雑なものにして、人に知られない事が重要です。開発テスト環境をそのまま本番環境に移行する場合には、本番移行時にパスワードを変更するようにしましょう。開発やテストの担当者(委託された外部の業者の可能性もあります)が本番システムにアクセスできてしまう事になります。開発者自身がネットワーク的な制限などで本番データベースにアクセスできない状態でも、本番環境のパスワードが広く知られている状態なのは危険です。本番移行時にパスワードを変更するためには、どこにパスワード情報が設定されているかを把握しておくことが大切です。パスワードがどこに保存されているか分からないので、アプリケーション用のユーザーのパスワード変更ができない、というシステムを非常によく見かけます。パスワードに関してはもう1点、パスワードがバッチスクリプトや設定ファイルに平文で保存しないようにしてください。情報漏洩の原因の上位に認証情報の盗難があげられます。重要なデータへのアクセス権限を多く持つアプリケーション用のユーザーの認証情報は特に注意が必要です。アプリケーションやバッチは安全に認証情報を保管できるミドルウェアや運用監視ツールから実行するようにしてください。

最後にアプリケーションユーザーへの権限の付与に関してです。
一番の注意点は強力なシステム権限やロールを付与しないことです。たとえば、SELECT ANY TABLE、CREATE ANY TABLEなどの他ユーザーの全てのオブジェクトにアクセスできるANYシステム権限やそれを含むEXP_FULL_DATABASE、DBAなどのロールです。
基本的には必要なオブジェクトへのオブジェクト権限を付与するようにしてください。ユーザーに直接、オブジェクト権限を付与することもできますが、業務処理ごとに必要なオブジェクト権限をまとめたロールを作成して、それをユーザーに付与することもできます。
アプリケーション用のユーザーにデータベースに接続するためのCREATE SESSIONシステム権限とオブジェクト権限(をまとめたロール)以外を付与する場合には、その権限が本当に必要かどうか、その権限を付与することで不要な操作がされる可能性はないかどうかを確認するようにしてください。

アプリケーションが利用するユーザーは、多くのデータに対するアクセス権限を持っています。アカウント情報が漏洩してしまった場合の影響は大きいので、厳密に管理して下さい。

「もくじ」にもどる

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.