脆弱性評価ツールの有効性を知る
幽霊アカウントや設定ミスを撲滅する
データベース運用を開始する際にはアカウントやパスワード設定、権限設定などを行いますが、インストール時の設定のまま運用を続けるというケースがいまだに見受けられます。特に、部門で運用されているサブシステムなどでは、自分たちで利用する部分だけ設定変更を行い、それ以外はデフォルトのまま使用していることも多いのではないでしょうか。
川口洋のセキュリティ・プライベート・アイズ(25)
実録・4大データベースへの直接攻撃(@IT Security&Trust)
http://www.atmarkit.co.jp/fsecurity/column/kawaguchi/025.html
取りあえず部門全員のアカウントを登録したものの、ほとんどのアカウントが使用されないままの状態だったり、あるいは人事異動や退職者があってもアカウントがそのまま残っていたり、ログインに失敗してアカウントがロックされた状態で長期間放置されているものもあるでしょう。このような“幽霊アカウント”が存在することは、セキュリティ上の大きなリスクといえます。
データベースからの情報漏えい事件は、発生プロセスに“人間”が介在していることがほとんどです。データにアクセスする際の接点はデータベースアカウントであり、アカウントの不正利用によって情報漏えい事件が引き起こされています。それゆえ、アカウント設定や権限設定、認証設定は定期的に棚卸しをして、再評価する必要があります。
脆弱性評価ツールを利用すると、各アカウント、職務、グループによってどのような権限を保持しているのかがすべてリストアップされ、セキュリティ上のリスクになる設定になっている個所があれば、それらもすべてピックアップして警告を発します。長期間使われていない状態のアカウントやロックされたままのアカウントの有無をチェックするなど、不必要なアカウントが登録されたままの状態になってしまう問題をなくすことができます。
データベースアカウントやロールの設定などは業務の状況によって随時変更されるものです。従って、ツールによる定期的なチェックを実施して常にセキュリティコントロール下に置くことが重要です。こうしたアカウント管理は、内部統制や法制的にも必要であり、その視点でも脆弱性評価ツールの有効性は高いといえます。
権限設定・認証設定が 不十分な場合のリスク |
脆弱性評価ツールによる解決 |
---|---|
|
|
マルチデータベース環境で統一したセキュリティ基準を維持する
企業では、多種多様なデータベースを用途に合わせて運用しているでしょう。例えば、基幹系はオラクル、大量のデータを扱う分析系はTeradata、外向けWebシステム用はSQL ServerやMySQLなど、それぞれデータの種類や用途によって使い分けています。
こうしたマルチデータベース環境では、各データベースベンダやサポートしているSIパートナーごとに管理基準に違いがあったり、社内の管理担当者の意識やスキルの違いによって、データベースごとにセキュリティの実施状況がばらばらな状況になってしまいます。ある1カ所のデータベースに脆弱ポイントによって、全社的なセキュリティレベルが低下しないよう、すべてのデータベースで企業としてクリアすべき、一定のセキュリティ基準を常に維持する必要があります。
脆弱性評価ツールには、データベース製品ごと、あるいはバージョンごとの最善のセキュリティ診断ポリシーが事前に備わっています。それぞれのデータベースに関して技術的に深く精通した専門エンジニアによるポリシーデザインをすることなく、脆弱性評価ツールによって、各データベースの現状がどのような状態であるのか走査でき、検出されたリスクにどう対処すべきか容易に知ることができます。
セキュリティレベルが 統一できない問題 |
脆弱性評価ツールによる解決 |
---|---|
|
|
DBセキュリティの維持管理がしっかりできていることを証明する
データべースのセキュリティ管理がしっかりとなされているかどうかは、保持されているデータにかかわるすべての人々にとって非常に重要な問題です。データの所有者・管理者・利用者・監査人などのそれぞれの立場から、データの管理状況を利害関係者に説明、証明する必要があります。主に説明、証明する立場にあるのは、データの所有者かつ管理責任者である「企業」ですが、企業は利用者・監査人・株主などに対してデータベースセキュリティの対応状況を、迅速かつ明確に証明する方法を用意しておくことが求められています。
また、データベースの設定は運用していく中で、いろいろな状況に応じて変更が繰り返されたり、パッチを適用したり、バージョンアップを行ったりと、環境は絶えず変化します。バージョンアップによって機能が追加された場合には設定項目も増え、これまでになかった新たなリスクが発生することもあります。
脆弱性評価ツールは、こうした状況に対応するために、定期的に自動で実施した脆弱性評価の結果を履歴として保持することが可能です。現在稼働中のデータベースにおけるセキュリティコントロールがどのように推移したか記録・保持されており、必要に応じてレポート出力することができます。それを利用して、利害関係者に対してセキュリティの取り組み状況を説明する必要が生じた場合、あるいは確実に管理されていることを証明する必要があるときは、すぐに対応することが可能になります。
セキュリティ管理状況の説明、 証明責任の問題 |
脆弱性評価ツールによる解決 |
---|---|
|
|
2/3 |
Index | |
脆弱性評価ツールの有効性を知る | |
Page 1 DBをセキュアに保つための管理プロセスを確立せよ 社内のすべてのデータベースを確実に掌握する |
|
Page 2 幽霊アカウントや設定ミスを撲滅する マルチデータベース環境で統一したセキュリティ基準を維持する DBセキュリティの維持管理がしっかりできていることを証明する |
|
Page 3 セキュリティサービスとしてのビジネス展開も可能 |
ここがポイント! DBセキュリティの実装 |
- Oracleライセンス「SE2」検証 CPUスレッド数制限はどんな仕組みで制御されるのか (2017/7/26)
データベース管理システムの運用でトラブルが発生したらどうするか。DBサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は、Oracle SE2の「CPUスレッド数制限」がどんな仕組みで行われるのかを検証します - ドメイン参加後、SQL Serverが起動しなくなった (2017/7/24)
本連載では、「SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は、「ドメイン参加後にSQL Serverが起動しなくなった場合の対処方法」を解説します - さらに高度なSQL実行計画の取得」のために理解しておくべきこと (2017/7/21)
日本オラクルのデータベーススペシャリストが「DBAがすぐ実践できる即効テクニック」を紹介する本連載。今回は「より高度なSQL実行計画を取得するために、理解しておいてほしいこと」を解説します - データベースセキュリティが「各種ガイドライン」に記載され始めている事実 (2017/7/20)
本連載では、「データベースセキュリティに必要な対策」を学び、DBMSでの「具体的な実装方法」や「Tips」などを紹介していきます。今回は、「各種ガイドラインが示すコンプライアンス要件に、データベースのセキュリティはどのように記載されているのか」を解説します
|
|