4.10 セキュリティ設計

4.10 セキュリティ設計

2.3.1 対象領域を明確にする

データベースを実装する際、セキュリティにも注意して1つ1つの作業を行う必要があります。

セキュリティ設計の難しいところは、1つでもセキュリティ上の抜け穴があれば、そこから悪意のユーザに侵入されて、たいへんな損害を受ける可能性がある点です。 セキュリティ上のチェック漏れが発覚したシステムは、企業イメージを著しく落とし、社会的な信用を失墜してしまう可能性があります。 十分な配慮を行って設計管理作業を行うようにしてください。

システムを構成する要素別のセキュリティ上の主な確認項目を示します。

ホストOSのセキュリティ

  • Oracleソフトウエア所有者のユーザ名やパスワードを管理する
  • データベースソフトウエアの種類ごとに異なるユーザを使用する
  • OracIeソフトウエアのアクセス権限を適切に設定する(Oracleソフトウェアの所有者以外はアクセスできない)
  • Oracleトレースファイルを削除する
  • ユーザ名とパスワードがハードコーディングされているスクリプトがないか確認する
  • OSの監査機能、Oracle監査機能を有効にする

ネットワークのセキュリティ

  • クライアントとサーバ間のNet8のセキュリテイ(Oracle Advanced Security)
  • Webアプリケーションサーバヘのアクセスのセキュリティ(SSL)

Oracleユーザの認証

  • SYS、SYSTEMのパスワードは必ず変更する
  • リモートホストベース認証は不可とする(外部認証の強化を検討)
  • パスワードの定期的な変更を強制させる

Oracleの権限管理

ロールの管理

  • デフォルトロールを使用しない
    本当に必要なシステム権限やオブジェクト権限を集めたロールを作成し、付与する
  • *_ CATALOG-ROLEをDBA(相当の)ロール以外に付与しない
  • ロールにパスワードを設定する

ビューの管理

  • ビューを作成し、直接表へのアクセスを制限する

PUBLIC権限が付与されたパッケージ

  • アカウントをのっとられる可能性があるため、一度削除して必要な権限のみを適用する

その他のセキュリティ

  • SYSTEM表領域の管理にはユーザオブジェクトを作成しない
    DoS攻撃によってSYSTEM表領域が拡張できなくなるとOracleがパンクしてしまう

< 前へ | 4.10 セキュリティ設計 | 次へ >

解説トレーナー

Oracle / 上流工程 担当 中村 才千代

データベース設計、システム構築の上流~下流工程全般のインストラクターです。SE時代の経験を生かし「業務を知るエンジニアこそDB設計に関わるべき」「DB設計に携わるエンジニアは業務を知る人に知恵を貸してもらう」ことを伝えたいと思っています。

■認定・受賞

2000年 Oracle University「Best Instructor of the Year」受賞
2002年 Oracle University「Best Instructor of the Year」受賞

Page Top