前編
データで分析するDBセキュリティの立ち遅れ原因
アシスト岸和田 隆
2006/6/15
 |
データベース・セキュリティに対するニーズは依然として高いが、実装率が低いのはなぜか？ |
では、データベースのセキュリティ対策がサーバ、ネットワーク、クライアントよりも実装率が低い原因はどこにあるのでしょうか。これまでのアンケート結果から次の3つの項目について考えてみます。
- データベース・セキュリティに必要性を感じていない
- ほかのセキュリティ対策を優先している
- データベース・セキュリティは実装し難く、影響範囲が広い
1．データベース・セキュリティに必要性を感じていない
本アンケートではデータベース・セキュリティ実施の有無を確認しています。ここで「必要性がない」と回答した5％のお客さまの中には、個人情報、機密情報が格納されていないデータベースを管理しているため、セキュリティ対策は必要ないと回答された方も含まれていると思われます。
また、アプリケーション、オペレーティングシステムのユーザー認証やアクセス制御、アカウント管理を実施すればデータベースへのアクセスは制限されます。そこでアプリケーション、オペレーティングシステムの操作ログを取得すれば、そこにはデータベースへのアクセスの有無が記録されています。そのため、あえてデータベースへのセキュリティ対策を行わなくてもよい、とする考え方もあると思われます。
しかし、過去に発生した情報漏えい事件の多くは、利用されていないアカウントを悪用し、データベースからデータを盗み出していることから、アカウント管理とデータベース・セキュリティは重要との認識が浸透していることはアンケート結果から読み取れます。重要であると考えられているが、実装までには至っていないケースが多いのだと思われます。
2．ほかのセキュリティ対策を優先している
図1〜3のアンケート結果から分かるように、外部からの脅威への対策としてネットワーク、オペレーティングシステムのセキュリティ対策が実施され、内部からの情報漏えい対策としてはユーザー認証、アカウント管理が優先的に実施されています。そのため、既存データベースのセキュリティ対策の優先度が相対的に低くなっているのではないでしょうか。
3．データベース・セキュリティは実装し難く、影響範囲が広い
データベースのセキュリティ対策は
- 導入、設定
- ユーザー認証
- 権限管理
- アクセス制御
- 監査ログ取得
- 通信、格納データの暗号化
に大別されます。例えば、Oracleデータベースの「導入、設定」では、必要最低限の機能だけを導入し、デフォルト設定を変更することで対処します。新しいシステムに導入する際に、適切な「導入、設定」を行うことは比較的簡単ですが、既存データベースに対して「必要最低限の機能だけを導入した状態に修正する、デフォルト設定を変更する」といった作業は難易度が高くなる場合が多いのです。
表1はOracleデータベースの「導入、設定」のセキュリティ項目と変更方法です。変更方法を確認すると、オンラインで変更作業ができる項目が少ないことが分かります。データベースの停止や再起動が必要になる変更は、システム計画停止など特定期間に限定されます。データベースはシステムの中核を構成しているため、停止を伴う変更作業は間単に行えないのが現実です。
| セキュリティ項目 | 変更方法 |
| 必要なモジュールのみインストール | Oracleデータベースを停止させOracle Universal Installerで削除 |
| デフォルト・ユーザーのアカウントをロックおよび期限切れに設定 | SQLにてオンラインで変更可能 |
| デフォルトのユーザー・パスワードを変更 | オンラインで変更可能だが、パスワードを必要とする管理用スクリプトが存在する場合、スクリプトの修正も必要 |
| プロファイルによるパスワード管理 | オンラインでプロファイルの定義、変更は可能だが、プロファイル設定によってクライアントに返されるメッセージに対応したアプリケーションの修正が必要 |
| データ・ディクショナリ保護 | 初期化パラメータ値の変更のため、データベース・インスタンスの再起動が必要 |
| PUBLICからの不要な権限を取り消し | オンラインで権限の取り消しを行うことが可能だが、事前にPL/SQLパッケージの実行ユーザーの洗い出しが必要 |
| 管理者権限の付与制限 | SQLにてオンラインで権限の取り消しを行うことが可能だが、ユーザーの洗い出しが必要 |
| PL/SQLのアクセス可能ディレクトリ制限 | 初期化パラメータ値の変更のため、データベース・インスタンスの再起動が必要 |
| リモート認証の使用制限 | 初期化パラメータ値の変更のため、データベース・インスタンスの再起動が必要 |
| リスナーによる外部プロシージャの実行制限 | リスナーの再起動が必要 |
| パスワードによりリスナー保護 | lsnrctlコマンドにてオンライン変更可能 |
| リスナーに接続できるIPアドレスの制限 | リスナーの再起動が必要 |
| SQL*Plusの使用可能コマンド制限 | オンラインで修正可能 |
| セキュリティ・パッチの適用 | Oracleを停止させセキュリティパッチを適用 |
| 表1 「導入、設定」に関連するセキュリティ項目とOracleでの変更方法 | |
 |
2/3 |  |
| Index | |
| 特集：日本版SOX法時代のOracleセキュリティ（前編） データで分析するDBセキュリティの立ち遅れ原因 |
|
| Page
1 ・個人情報保護法施行に伴い、データベース・セキュリティへの関心が高まる |
|
 |
Page 2 ・データベース・セキュリティに対するニーズは依然として高いが、実装率が低いのはなぜか？ |
| Page 3 ・今後は「内部統制」という観点でデータベース・セキュリティは再度注目される |
|
 |
日本版SOX法時代のOracleセキュリティ |
- 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」などを紹介していきます。今回は、「各種ガイドラインが示すコンプライアンス要件に、データベースのセキュリティはどのように記載されているのか」を解説します
 |
|
|
|
|
