PR

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

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

適切なパスワード管理

(1)推測されにくいパスワード

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

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

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

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

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

(3)パスワード・ポリシーの適用

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

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

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

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

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

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

パラメータ 内容
FAILED_LOGIN_ATTEMPTS ロックされるまでのログイン試行失敗回数
PASSWORD_LIFE_TIME パスワード有効期限(日数)
PASSWORD_GRACE_TIME パスワード期限切れ後の猶予期間(日数)
PASSWORD_LOCK_TIME ログインに指定回数失敗後、ロックされる日数
PASSWORD_REUSE_MAX 現行のパスワードを再利用できるようになるまでに必要なパスワード変更の回数
PASSWORD_REUSE_TIME パスワードを再利用できない日数
PASSWORD_VERIFY_FUNCTION パスワードの複雑度を検証するプロシージャ

図3: プロファイル設定例[Oracle](クリックで拡大)

図4: Windowsのパスワードポリシーを適用[SQLServer](クリックで拡大)


より強固な認証

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

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

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

外部認証:
生体認証や認証トークン、RADIUS、Kerberosなど、信頼される外部の認証パッケージを利用した認証
PKIを使った証明書ベースの認証:
PKI(公開鍵インフラストラクチャ)を利用した認証

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

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

【参考文献】

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

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

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています