PR

DBセキュリティの第1歩、アカウント管理と認証

2010年11月2日(火)
須田 堅一

なぜアカウント管理と認証が大切なのか

個人情報保護法の施行や、内部統制におけるIT統制の要求、相変わらず多く発生している情報漏えいや改ざん事件などをきっかけに、データベース(DB)に保存されている重要な情報資産を保護するための、DBセキュリティ対策が求められています。

DBセキュリティ対策の1つとして、今回は「アカウント管理と認証」について解説します。なお、当記事では、DBにログインする際に使用するIDのことを「アカウント」と表記します。

システム管理部門において、DB管理業務に使用するアカウントを共有していたとしましょう。その部署に複数の人が所属していれば、管理職や実務担当など、それぞれの役割があります。このため、おのずと「やっていい操作」と「やってはいけない操作」が存在するはずです。

しかし、全員で同じアカウントを共有していた場合、不都合が生じてしまいます。個人の役割に沿った必要な権限のみを付与することができず、業務上必要のない権限まで所有することになってしまうからです。ログを取得していても、操作者を特定するための判断材料となるべきアカウントがすべて同じでは、「誰が操作したログなのか」を把握することはできません。

一方、利用者ごとにアカウントを割り振っていたとしても、「123」などといった脆弱(ぜいじゃく)なパスワードを設定していたのでは、誰でも他人になりすますことができてしまいます。これでは、権限設定もログも意味をなしません。

つまり、利用者を特定するアカウント管理や、アカウントを他人に悪用されないための適切な認証の仕組みが、重要となってきます。しかし、図1のグラフを見る限り、企業におけるセキュリティ対策の実施状況は、十分とは言えません。

【引用】『データベースセキュリティ安全度セルフチェック統計データ Ver. 2.1』(データベース・セキュリティ・コンソーシアム:DBSC)
図1: 重要な「アカウント管理」も、実施率は4割(クリックで拡大)


アカウントの作成基準

(1)利用者の整理

アカウントを作成する際には、まず初めに、DBへのアクセスが必要な利用者を整理したうえで、分類した役割ごとに要員を整理します。このとき、各利用者の職務が、「職務の分離(Separation of Duties)」の原則によって分離されている必要があります。

しかし、この職務の分離がされず「1人のDB管理者が、DBに対する全権を持ち、すべての作業を担当する」といったケースがあります。これは、非常に危険な状態です(実際、このように全権を持ったDB管理者は多いのではないでしょうか?)。

犯罪学では、不正を働く要素となる「動機、機会、正当化」を「不正のトライアングル」と呼び、これら3つの条件がすべて整うと、不正が行われるリスクが高まると言われています。先に述べたような、全権を持ったDB管理者は、「秘密裏に情報を盗み、その証拠を隠滅する」ことが容易にできるため、3要素のうちの1つ「機会」を持っていることになります。

しかし、職務の分離によって相互にけん制が働く体制を構築することで、DB管理者から「機会」を奪うことができます。このことは、情報資産を守るだけでなく、結果的にDB管理者も守ることにつながるかも知れません。

(2)アカウントは利用者ごと/用途ごとに作成

アカウントは、DBへのアクセスを許可された人物や機能(アプリケーション)を識別(Identification)するために使用します。先に実施した「利用者の整理」の結果をもとに、利用者ごと/用途ごとに、アカウントを作成します。

DB管理者に対しては、管理者権限を付与した「DB管理用アカウント」と、管理者権限がない「一般アカウント」の2種類を割り振ります。ここで、管理者権限が必要な作業の場合に限ってDB管理用アカウントを使用し、それ以外は権限の低い「一般アカウント」を使用するようにします。これにより、過剰な権限を持った状態で作業しないようにします。

また、テーブルやスクリプトといったオブジェクトの所有者や、バックアップ、DB稼働監視といったジョブごとに用意したアカウントは、それぞれの用途のみで使用します。

このように、利用者ごと/用途ごとにアカウントを作成することで、最小特権(Least Privilege)のみを付与することが可能になります。これにより、オペレーション・ミスを軽減するとともに、アカウントを不正利用された場合の被害を軽減することができます。

(3)本番環境と開発環境で、異なるアカウントを作成

開発の負担を減らすために(もしくは、意識していないために)、本番環境と開発環境で同一のアカウントを使用しているシステムが多く見られますが、これは良くないやり方です。開発者は、本番環境にアクセスできる必要はありません。本番環境と開発環境は、それぞれ異なるアカウントを使うべきです。

アプリケーションの都合などで、やむを得ず同一のアカウントを使わざるを得ない場合は、少なくともパスワードは、異なるものを設定するようにします。

データベース・セキュリティ・コンソーシアム(DBSC)

DBSCでは、「DBセキュリティ安全度セルフチェックWG」のリーダーを務め、他にも複数のWGに参加。
株式会社ラック データベースセキュリティ研究所に所属。システム開発を長年経験した後、2005年からデータベース・セキュリティの世界へ。雑誌やWebなど、データベース・セキュリティに関する執筆も行う。CISSP。情報セキュリティ・アドミニストレータ。

連載記事一覧

Think IT会員サービスのご案内

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスのご案内

関連記事