※ 本記事は2017年2月2日に公開されたものです。
データベースのアカウントの分類方法はいくつもありますが、どのように利用されることを目的として作成されたかという観点からだと下記の3つに分類できます。
- アプリケーション用のユーザー(人間が使わないアカウント)
- 直接データベースにログインして利用するユーザー(人間が利用するアカウント)
- デフォルトで最初から作成されているユーザー(運用フェーズでは誰も利用すべきでなないアカウント)
今回は直接データベースにログインして利用するユーザーの作り方の考え方を説明します。もちろん、これが唯一無二の方法ではありませんが、セキュリティを担保するためのデータベースユーザー作成の考え方のひとつとして参考にしていただければと思います。
今回説明する直接データベースにログインして利用するユーザーには、たとえばデータベースの管理や運用をおこなう担当者やアプリケーションデータのメンテナンスをおこなう担当者、データ分析やクライアントサーバー形式のアプリケーションを利用するためにデータベースに直接アクセスするエンドユーザーがいます。
アクセス制御で最小権限の原則を実現したり、監査を実施した際に監査証跡から実際に操作した人を特定するうえでも匿名性の排除は重要です。
各省庁が出している個人情報保護に関するガイドラインや政府機関等の情報セキュリティ対策のための統一基準などでも、個人の識別に言及されています。これらの基準を守る上でも個人用のアカウントの利用は重要です。
(個人情報の保護に関する法律の改正に伴い、個人情報保護に関するガイドラインもより厳格な方向に更新されていきますので、新しく出てくる個人情報保護に関するガイドラインにも注意が必要です)
作成したアカウントのパスワードは容易に想像できない複雑なものにして、本人以外は知らない状態に保つことが重要です。
パスワードの定期的な変更の強制も効果的ですが、頻繁なパスワード変更の強制は利用者が複雑なパスワードを思いつかない、覚えられない等の理由で逆に簡単なパスワードや推測されやすいパスワードを設定してしまう可能性がありますので、注意が必要です。ガイドラインなどではパスワードの定期的な変更を求めているものも多いですが、パスワードは定期的に変更しないほうが安全という意見もあります。詳しくは「パスワード 定期的 変更」などで検索してみてください。ただし、どちらにせよ設定するパスワードは推測できない複雑なものにして、パスワードが外部に漏れた可能性がある場合にはただちに変更しなくてはならないのには変わりはありません。
アプリケーションデータのメンテナンスをおこなう担当者のアカウント、およびデータ分析やアプリケーションを利用するためにデータベースに直接アクセスするエンドユーザー用のアカウントに付与するアクセス権限はアプリケーション用のアカウントと基本的に同じ考え方ができます。データベースに接続するためにCREATE SESSIONシステム権限と、必要な表へのオブジェクト権限(をまとめたロール)以外を付与する場合には、その権限が本当に必要かどうか、その権限を付与することで不要な操作がされる可能性はないかどうかを確認するようにしてください。SQL*Plusなどのツールを利用して自由にSQL文を発行できますので権限の付与には注意が必要です。たとえば表を作成するためのCREATE TABLEシステム権限が付与されていた場合、自分で新しい表を作成し、そこに他の表からデータをロードし、作成した表へのSELECT権限をPUBLICに付与するという一連の操作で、本来権限のない人でもデータにアクセスできるような状態としてしまう事ができます(WRITE DOWNとも呼びます)。
データベースの管理や運用をおこなう担当者用のアカウントに付与するアクセス権限で注意が必要なのがその人がデータにアクセスする必要があるかどうかという事です。データベースの運用を業務部門ではなくIT部門がおこなっていたり、外部の業者に委託している場合、その人たちはアプリケーションのデータを見る必要はないはずです。このような人たちにデータにアクセスする権限を与えることは最小権限の原則からはずれてしまいます。最小権限の原則を実現するためには、このような用途のアカウントには、表へのオブジェクト権限だけでなく、データにアクセスできるSELECT ANY TABLEなどのANY権限とそれを含むロール(DBA、EXP_FULL_DATABASEなど)に付与もおこなわないようにすべきです。
面倒にも感じますが、個人情報保護のガイドラインや政府機関等の情報セキュリティ対策のための統一基準などにも記載されている「管理者権限の分割」や「管理者アカウントの適正な権限管理」をおこなうためには必要なことです。
データベースに直接アクセスする利用者はSQL文を自由に発行できるという点だけでも、通常のアプリケーションから定形処理しかおこなわない利用者と比べると、特権ユーザー、パワーユーザーとなります。このようなアカウントを利用した不正や事故がおこらないように最小権限の原則を徹底させてください。
なお、SELECT ANY TABLEシステム権限やそれを含むロール(DBAなど)を付与していても実際のデータにアクセスできないようにするためにOracle Database Vaultが利用できます。この有償オプションを導入いただくことで既存のDBAロールなどを利用したアクセス設計を継承しつつ、管理者であってもアプリケーションデータにはアクセスできない環境を実現できます。ぜひご検討ください。