Блокируем средства разработки
Заметка №2.
Полезный скрипт нашелся в сети - позволяет ограничить использование пользователями БД различных инструментов для работы с данными: TOAD, PLSQL Developer и т.д. Можно добавить и свои приложения.
А то найдется, бывает, среди пользователей один любопытный и лазит напрямую в базу “чего-нить бы подровнять”, а потом ищи кто, что и когда сломал. Можно и нужно бороться с любопытными.
CONNECT / AS SYSDBA;
CREATE OR REPLACE TRIGGER block_tools_from_prod
AFTER LOGON ON DATABASE
DECLARE
v_prog sys.v_$session.program%TYPE;
BEGIN
SELECT program INTO v_prog
FROM sys.v_$session
WHERE audsid = USERENV(’SESSIONID’)
AND audsid != 0 — Don’t Check SYS Connections
AND rownum = 1; — Parallel processes will have the same AUDSID’sIF UPPER(v_prog) LIKE ‘%TOAD%’ OR UPPER(v_prog) LIKE ‘%T.O.A.D%’ OR — Toad
UPPER(v_prog) LIKE ‘%SQLNAV%’ OR — SQL Navigator
UPPER(v_prog) LIKE ‘%PLSQLDEV%’ OR — PLSQL Developer
UPPER(v_prog) LIKE ‘%BUSOBJ%’ OR — Business Objects
UPPER(v_prog) LIKE ‘%EXCEL%’ — MS-Excel plug-in
THEN
RAISE_APPLICATION_ERROR(-20000, ‘Development tools are not allowed on PROD DB!’);
END IF;
END;
/
SHOW ERRORS
вообще, надо проектировщика БД отправить улицы мести, если всякие любопытствующие субъекты могут что-то испортить
Вообще, если ввести такую практику, то улицы у нас будут сиять чистотой =)
Всяко ведь бывает =) Все учесть не всегда получается. Да и любопытствующие разные бывают
у меня плагин к idea
а зачем так извращаться - может доступ забрать вообще?
во вторых это тормоз будет работать для каждого коннекта
каждый раз дергать sys.v_$session
Плагин можно также выщемить и добавить.
Дергать будет один раз при попытке соединения.
у апп сервака пул коннектов
а почему просто доступ не забрать???
Да и не надо всё предусматривать. Либо изолировать БД за сервером приложений, который авторизирует юзерей и даёт им только те функции которые им нужны. Либо, на худой конец, авторизировать юзерей средствами БД, и тогда можно будет по логам провести разбор полётов, и дать кое кому по рукам или в репу, в зависимости от ущерба. =)
Ерунда, продвинутый и терпеливый пользватель при наличии прав всеравно влезет, т.к число [quote comment="1393"]различных инструментов для работы с данными[/quote] теоретически ограниченно только ленью последнего. Но гораздо вероятнее что если припрет - он просто войдет под логином (или с машины) права имеющего. Все таки - лучшее (из имеющихся) решение - read only на то что не надо
При наличии прав, будут наличествовать и вменяемые логи доступа… Так что будет понятно кому дать по рукам… Или в репу, в зависимости от ущерба
Большинство пользователей (проверено на практике) заводит себе пароли типа sveta/123 или ivan/ivan, а посему угнать пасс для вредных дел можно всегда. Толку с того, что будет известно кто нашкодил - лучше предотвратить!
ну опять же, предотвращение реализуется не запрещением различных инструментов, а правильной структурой БД. Изначально сиквел создавался как язык запросов который может освоить любой манагер и давать к базе непосредственные запросы =) Ых,.. Куды мир кОтится?