С точки зрения информ безопасности, самое первое с чем стоит определится это что мы защищаем и от кого/от чего. Без этого особого смысла нет вообще чего-то городить.
Второе: «информбезопасность» это всегда комплекс как технических так и огранизационных мер. Одно без другого смысла не имеет.
Вот вам список вопросов:
1) Вы хотите защитится от DBA? А зачем вы тогда держите у себя такого «сферического DBA в вакууме» которому вы не доверяете? Или у вас администрирование осуществляет сторонняя компания которой вы не доверяете? Тогда зачем такая ком пания? Так может «информбезопасность» начать с того, что подписать с ней соответствующий договор об ответственности за возможные утечки?
2) Вы хотите защитится от нерадивых программистов, которые херачат все направо и налево данные и пакеты на production базе? Вопрос правильный, только стоит его переформулировать так: у вас все программисты такие безотвественные школьники или есть один-два «ведущих разработчика», которые обладают достаточной квалификацией и ответственностью?
3) Вы хотите защитится от некорректных изменений/некорректных действий пользователей БД? А также от всяческих сломанных/слетевших с катушек внешних скриптов имеющих коннект к базе?
4) Вы хотите защититься от злых дядечек которые спят и видят как поиметь вашу базу и утянуть из нее все ваши суперсекретные данные?
А вот теперь, после вступительных вопросов я могу поделится своей Best Practice организацией безопасности (и надежности также) в Oracle.
* ответ на 1)й вопрос — чисто организационные меры
* отучаемся держать все данные в общей схеме-помойке.
* разделяем схемы на бекендные и фронтендные
* бекендные схемы содержат бизнес-данные и пакеты с бизнес-логикой их обработки
* бекендные схемы разделены по задачам и зонам отвественности — за каждую бекендную схему есть свой ответственный ведущий программист и никто туда без его ведома не лазит.
* фронтендные схемы таблиц c данными не содержат (вообще на них просто нет такого гранта как create table). они содержат только вью и пакеты которые преобразуют бизнес-логику «внешнего потребителя» во внутреннюю логику, адресуемую бекендным пакетам. Собственно фронтенд-вью и фронтенд-пакеты в том числе несут на себе задачи безопасности (такие как например не показывать например паспортные данные клиентов-физиков тому кому их показывать низя, не давая менять определенные поля в определенных документах тому кому не надо, показывать в фронтенд-вьюшке для менеджера только его клиентов а не всю клиентсткую базу, и прочее и прочее… то есть задач тут может решатся дофига-дофига-дофига, самое главное составить список этих решаемых задач).
* т.е. обратите внимание, на разделение «бизнес-логики» (бекенд-схемы) и «security-логики»(фронтенд-схемы).
* Все остальные пользователи и внешние скрипты ходят под своим отдельным логином (юзер с грантом только на коннект). Работают только с теми фронтенд-обьектами которые им явно грантованны. О структуре, огранизации и существовании чего-то в бекенд-схемах они вообще не догадываются, что дает сразу +100% к безопасности и надежности.
Много раз применял данную огранизацию в разных местах и всегда она себя оправдывала «на ура».