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

適切なパスワード管理

（1）推測されにくいパスワード

アカウントを個人／役割ごとに割り当てたら、次に、推測されにくいパスワードを設定します。この時、推測されやすいパスワードを設定すると、辞書攻撃やブルート・フォース 攻撃などによってパスワードが解析され、不正にログインされてしまう可能性があります。

また、利用者が他人にパスワードを教えたり、付せん紙に書いてモニターに貼ったりしないよう、規則で定めたり、教育したりする必要があります。いくらDBMS側で適切なパスワード管理をしていても、利用者のモラルが低ければ意味がありません。

（2）デフォルト・パスワードは必ず変更

古いバージョンのDBMSには、デフォルト・アカウントにデフォルト・パスワードが設定されていることがあります。しかも、これらのデフォルト・アカウントやデフォルト・パスワードは、一般に知られています。このため、変更しないまま運用している場合、不正アクセスに利用されてしまう可能性が非常に高くなっています。デフォルト・パスワードは、必ず変更しなければなりません。

残念なことに、管理者権限のデフォルト・アカウントがデフォルト・パスワードのまま運用されているだけでなく、そのアカウントをアプリケーションからの接続に使用しているケースも見かけます。これでは、仮にSQLインジェクション攻撃を受けた場合、管理者権限を使用されてしまいます。被害が、より深刻になってしまいます。

（3）パスワード・ポリシーの適用

以下のようなパスワード・ポリシーを適用します。

• 英数字と記号を含む8文字以上のパスワードとする
• 3カ月ごとにパスワードを更新する
• 連続したログイン失敗はアカウントをロックする

これらのポリシーの施行により、推測されにくいパスワードの設定や、定期的なパスワードの変更などを強制できるようになります。システム的にパスワード管理を強化できます。

ただし、「連続したログイン失敗はアカウントをロックする」というルールは、パスワード・クラックによるなりすましを防止する反面、「業務妨害の目的で、故意にログイン失敗を繰り返してアカウントをロックさせる」という攻撃も考えられます。

「一定の時間を経過したらロックを自動的に解除する」のか「DB管理者がコマンドを発行してロックを解除する」のか、該当システムの性質や用途によって決めます。

表1: プロファイルで設定可能なパスワード・ポリシーのパラメータ［Oracle］

より強固な認証

DBMSで一般的に使用されている認証方式は、「パスワード認証」や「OS認証」です。適切な認証とするためには、先述した「適切なパスワード管理」が必要となります。

しかし、対象システムの特性や、取り扱っている情報の内容、企業のポリシー、業界・団体のガイドラインや基準などに応じて、一定水準以上の認証強度を求めらるなど、より強固な認証システムを採用しなければならない場合があります。

DBにおける「より強固な認証」の例として、以下のものが挙げられます。これらは、DBMSのオプションとして提供されていたり、サード・パーティ製のパッケージを購入する必要があったりすることから、導入目的や性能、環境、予算などを踏まえ、適したものを選択します。

外部認証:

生体認証や認証トークン、RADIUS、Kerberosなど、信頼される外部の認証パッケージを利用した認証

PKIを使った証明書ベースの認証:

PKI（公開鍵インフラストラクチャ）を利用した認証

冒頭でも述べましたが、「アカウント管理と認証」をしっかりやらないことには、いくら費用と手間をかけても、アクセス・コントロールやログなどといった、そのほかのセキュリティ対策の効果が期待できません。

「アカウント管理と認証」は、DBセキュリティの第1歩です。読者の皆さんが構築・運用しているDBを、もう一度、見直してみてはいかがでしょうか。

【参考文献】

• 『データベースセキュリティガイドライン（2.0 版）』
  （データベース・セキュリティ・コンソーシアム:DBSC）
• 『データベースセキュリティガイドライン英語版（2.0 版）』
  （データベース・セキュリティ・コンソーシアム:DBSC）
• 『データベースセキュリティ安全度セルフチェック統計データ Ver. 2.1』
  （データベース・セキュリティ・コンソーシアム:DBSC）