権限管理の原則を次に示します。

• 必要以上の権限を与えると，それがセキュリティ上の弱点となる可能性があります。したがって，決められた役割に従って必要最小限の権限を与えるようにしてください。
• 権限が不要になった場合は（組織内で人の異動があったときなど），すぐに権限を削除するか，または変更してください。そのHiRDBユーザがいなくなる場合はそのHiRDBユーザ（認可識別子）を削除してください。
• 必要のないHiRDBユーザを登録して権限を与えないでください。

HiRDBユーザの権限を管理する人にDBA権限を与えます。

DBA権限を与えるときの方針

DBA権限があると，権限を追加（削除および変更も含む）したり，ほかのHiRDBユーザが所有している表を削除したりできます。また，DBA権限はスキーマ定義権限およびCONNECT権限を包括しているため，表の定義もできます。このように大変利便性が良いため，多くのHiRDBユーザにDBA権限を与えてしまいがちです。しかし，DBA権限はほかのHiRDBユーザの表を削除したり，権限を削除したりできる強力な権限です。このため，悪意を持ったHiRDBユーザがこの権限を有するとセキュリティ上のリスクが非常に高くなります。したがって，DBA権限を与えるときは利便性を考えないで，セキュリティ面だけを考えて判断するようにしてください。

DBA権限を与える方法

DBA権限保持者が，定義系SQLのGRANTを実行してほかのHiRDBユーザにDBA権限を与えます。

ほかのHiRDBユーザのDBA権限を削除する場合は，定義系SQLのREVOKEを実行します。

表を定義し，所有・管理する人にスキーマ定義権限およびCONNECT権限を与えます。

参考

スキーマを定義するにはスキーマ定義権限とCONNECT権限の両方が必要になります。スキーマ定義権限およびCONNECT権限を与えてもらったあとにスキーマを定義し，表を定義すると，表の所有者になります。

なお，権限はCONNECT権限，スキーマ定義権限の順に与えてください。逆にした場合，SQLの実行時にエラーとなります。

スキーマ定義権限を与えるときの方針

表を定義し，所有・管理する人だけにスキーマ定義権限を与えてください。それ以外の人にはスキーマ定義権限を与えないでください。

スキーマ定義権限を与える方法

DBA権限保持者が，定義系SQLのGRANTを実行してほかのHiRDBユーザにスキーマ定義権限を与えます。

ほかのHiRDBユーザのスキーマ定義権限を削除する場合は，定義系SQLのREVOKEを実行します。

データの検索，更新，追加，および削除を行うデータベースの利用者にCONNECT権限を与えます。ただし，データベースの利用者がデータをアクセスするには，表の所有者に表のアクセス権限を与えてもらう必要があります。

CONNECT権限を与えるときの方針

データベースの利用者だけにCONNECT権限を与えてください。必要のないHiRDBユーザを登録し，CONNECT権限を与えないようにしてください。

CONNECT権限を与える方法

DBA権限保持者が，定義系SQLのGRANTを実行してほかのHiRDBユーザにCONNECT権限を与えます。

ほかのHiRDBユーザのCONNECT権限を削除する場合は，定義系SQLのREVOKEを実行します。REVOKE実行時の注意事項については，「7.9.1　CONNECT権限を取り消す場合」を参照してください。

監査を実施する人に監査権限を与えて監査人として登録します。

監査権限を与えるときの方針

• システムの利用者（管理者を含む）を監査人にしないでください。利用者を監査人にすると，監査の不正工作がやりやすくなるため，不正行為が行われるリスクが高くなります。
• 監査人には，監査証跡表以外の表のアクセス権限を極力与えないでください。

監査権限の制限

• DBA権限保持者（HiRDB管理者を含む）は監査人になれません。
• 監査人の監査権限は削除できません。
• 一度登録した監査人の認可識別子は変更できません。
  

  参考

  • DBA権限は最も強力な権限であるため，DBA権限と監査権限の両方を有する人が不正行為を行った場合，それをチェックすることが難しくなります。そのため，DBA権限保持者を監査人にはできない仕組みになっています。
  • 監査人を変更する場合，既存の監査人の認可識別子をそのまま引き継いで，パスワードを変更する運用としてください。このとき，すぐにパスワードを変更してください。

監査権限を与える方法

HiRDB管理者がデータベース構成変更ユティリティのcreate auditor文で監査人を登録します（監査権限を与えます）。