DBセキュリティの第1歩、アカウント管理と認証
![](https://thinkit.co.jp/sites/default/files/styles/main_image_730x/public/main_images/1713_main_7.png?itok=liNeP0I1)
適切なパスワード管理
(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を、もう一度、見直してみてはいかがでしょうか。
【参考文献】
- 『データベースセキュリティガイドライン(2.0 版)』
(データベース・セキュリティ・コンソーシアム:DBSC) - 『データベースセキュリティガイドライン英語版(2.0 版)』
(データベース・セキュリティ・コンソーシアム:DBSC) - 『データベースセキュリティ安全度セルフチェック統計データ Ver. 2.1』
(データベース・セキュリティ・コンソーシアム:DBSC)
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- 終わりなきデータベースのセキュリティ対策で押さえるべきポイントとは
- DBセキュリティの第2弾、アクセス・コントロールと権限管理
- 監査ログをいかに取得し活用するか
- 特権ユーザー・アカウントのID管理/アクセス管理
- WordPress コース 2nd Stage を攻略しよう(Linux 仮想マシン編)
- データベース・ファイアウォール導入への不安を解消する、5つの選定ポイントとは
- エンジニアが知っておくべき4つのデータベース攻撃シナリオ
- ownCloud導入はじめの一歩(仮想マシンイメージとCentOS 7のインストール手順)
- Adempiereのインストール
- パスキーでサインインの安全性と利便性の課題を同時に解決