Oracle кто создал таблицу

Поиск пользователя в Oracle/PLSQL

Вы можете найти всех пользователей, созданных в Oracle, выполнив запрос из командной строки. Пользовательская информация хранится в различных системных таблицах — ALL_USERS и DBA_USERS, в зависимости от того, какую информацию пользователей вы хотите получить.

ALL_USERS

Если вам нужно найти всех пользователей, которые являются видимыми для текущих пользователей, вы можете запросить таблицу ALL_USERS.

Синтаксис

Синтаксис для извлечения пользовательской информации из таблицы ALL_USERS в Oracle/PLSQL:

SELECT *
FROM ALL_USERS;

Таблица ALL_USERS содержит следующие столбцы:

Столбец	Описание
USERNAME	Имя пользователя
USER_ID	Числовой идентификатор, присвоенный пользователю
CREATED	Дата, когда пользователь был создан

DBA_USERS

Если вам нужно найти всех пользователей, которые существуют в Oracle или требуется дополнительная информация о пользователе, то есть другая системная таблица под названием DBA_USERS.

Синтаксис для извлечения пользовательской информации из таблицы DBA_USERS в Oracle/PLSQL:

SELECT *
FROM DBA_USERS;

Таблица DBA_USERS содержит следующие столбцы:

Столбец	Описание
USERNAME	Имя пользователь
USER_ID	Числовой идентификатор, присвоенный пользователю
PASSWORD	Устаревший
ACCOUNT_STATUS	Статус пользователя:

• OPEN
• EXPIRED
• EXPIRED(GRACE)
• EXPIRED(TIMED)
• LOCKED
• EXPIRED & LOCKED(TIMED)
• EXPIRED(GRACE) & LOCKED(TIMED)
• EXPIRED & LOCKED
• EXPIRED(GRACE) & LOCKED

Как получить доступ к таблицам созданного мною нового пользователя?

Под пользователем system создал нового пользователя Admin и дал ему привилегии на ресурсы, dba и подключение к БД. После, от имени этого пользователя создал таблицу, для примера пусть это будет таблица T . От пользователя system я пытался получить доступ к таблице T , но её для пространства system не существует, зато у Admin доступ имеется. Как получить доступ к таблицам: изменению, редактированию и т.д., для созданного мною пользователя? Можно-ли установить этот доступ автоматически, чтобы для каждого созданного пользователя, пользователь, создавший его, мог получить доступ к его таблицам?

Отслеживать
51.6k 201 201 золотой знак 63 63 серебряных знака 245 245 бронзовых знаков
задан 5 мая 2021 в 9:50
AspiringToBeAJune AspiringToBeAJune
109 1 1 серебряный знак 8 8 бронзовых знаков

Уточните пожалуйста, как вы пытаетесь обратится к таблице «T»? И system, и вновь созданый пользователь «Admin», имеют достаточно привилегий для доступа ко всем таблицам БД, ничего делать не надо.

5 мая 2021 в 11:35

@0xdb, Да, конечно! Делаю следующее: в блоке кода pl/sql прописываю создание таблицы «T» через «create table», выполняю commit, в блоке pl/sql команд от пользователя system я прописываю команду «select * from T», чтобы проверить наличие доступа к таблице и получаю ошибку, которая говорит, что таблица отсутствует. Эта же команда («select * from T;) прекрасно работает у самого Admin’a. Но мне бы хотелось, как system пользователю, обладать доступом к таблицам созданных мною пользователей

5 мая 2021 в 13:22
select * from Admin.T;
5 мая 2021 в 13:28

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

пытался получить доступ к таблице «T», но её для пространства system не существует

Совершенно верно, этой таблицы в пространстве имён system (или правильней сакзать, в схеме) не существует. Без указания полного имени объекта БД, в данном случае — Admin.T , поиск будет только в текущей схеме. Подробней, о том, как осуществляется поиск имён в документации.

Как видите, привилигированные пользователи имеют полный контроль над объектами других пользователей:

create user u1 identified by u1 / User U1 created. create table u1.t (col1 int) / Table U1.T created. select * from u1.t / no rows selected alter table u1.t add col2 char(1) / Table U1.T altered. 

Для удобства можно создать синонимы, тогда можно обращяться без указания схемы. Но заметьте, синонимы действуют для DML, но не для DDL:

create public synonym t for u1.t / Synonym T created. select * from t / no rows selected drop table t purge / ORA-00942: table or view does not exist 

Не забудте прибраться:

drop user u1 cascade / User U1 dropped. 

Oracle кто создал таблицу

В данной статье читателю дается возможность получить представление об основах аудита баз данных Oracle. СУБД Oracle — функционально развитый продукт, и в нем существует несколько возможностей проведения аудита (доступных читателю). Но так как аудит Oracle это довольно широкая тема, и ее описание по праву заняло бы целую книгу, то мы затронем лишь основы того, как, зачем и когда использовать аудит. Далее будут показаны два примера, демонстрирующие, насколько может быть полезен аудит Oracle в вашей организации.

Все примеры SQL приведенные в этом документе могут быть скачены с авторского веб сайта по адресу http://www.petefinnigan.com/papers/audit.sql

Сложные вопросы

Существует несколько основных вопросов, на которые необходимо ответить, при принятии решения об использовании средств аудита Oracle. Такие как:

Зачем аудит нужен в Oracle?

Странный вопрос? Тем не менее, многие компании, в действительности, не используют средства внутреннего аудита Oracle. А когда и пытаются использовать, то заваливаются предложенным выбором. Они включают все подряд для полноты контроля, затем, видя, что в отчете слишком много информации для прочтения и изучения — быстро снова его выключают. Это типично для использования фаерволов, систем обнаружения вторжения (IDS) или других инструментов информационной безопасности, созданных для обнаружения нападений на сеть или операционную систему. Так почему бы не отслеживать то, что пользователи делают с «сокровищами короны» организации — данными. Аудит Oracle может помочь в определении неавторизованного доступа или внутреннего злоупотребления по отношению к информации содержащейся в базе данных.

Когда пользователям Oracle следует подвергаться аудиту?

Простой набор основных действий аудита должен быть активен все время. Необходимый минимум включает в себя отслеживание доступа пользователей, использование системных привилегий и изменение в структуре базы данных. Этот основной набор не покажет неудавшихся попыток доступа к специфическим данным, которые не должны быть доступны; тем не менее, он даст a достаточно простой обзор «некорректного» доступа или использования привилегий. Если служащий подозревается в недозволенных действиях или ожидается атака, тогда может быть применен более детализованный аудит для специфических таблиц. С точки зрения управления БД, аудит изменения данных для всех таблиц не так уж практичен и может повлиять на производительность системы в целом. Аудит доступа для изменения данных следует использовать для таблиц лишь имеющих особо важное значение (например, заработанная плата сотрудников в базе данных HR).

Как могут быть проконтролированы пользователи Oracle?

Стандартные команды аудита позволяют контролировать все системные, и объектные привилегии доступа к любым таблицам или представлениям базы данных на select, delete, insert or update. Аудит может быть запущен как для успешных, так и для неуспешных попыток или для тех и других сразу. Как индивидуально для каждого пользователя, так и для всех пользователей сразу, он может выполняться на сессионном уровне или на уровне действия (доступа). На уровне действия — одна запись создается для одного действия, а на сессионном — одна запись для всех контролируемых операций одной сессии.

Какие проблемы возникают с производительностью и сложностью?

Часто аудит воспринимается как сложный и медленный. Причина этому обычное невежество. Если большинство из всех опций включены, тогда получающийся в результате журнал аудита может быть большим и трудным для интерпретации и управления. Кроме того, если аудит задействован на всех таблицах и представлениях базы, то это может повлиять и на производительность. Всякий раз, когда выполняемое действие контролируется аудитом в журнал вносится запись; очевидно, что чем интенсивнее используется аудит, тем больше записей будет записано в системное табличное пространство исключительно для аудита. В некоторых случаях это может привести к удвоению количества записей в базу данных: оригинальная запись и выполняемая для нее запись аудита.

Основное правило настройки аудита это простота и предусмотрительность. Выполняйте аудит и детальный мониторинг только тех операций и объектов, информация о которых действительно необходима. Важно то, что с помощью простых отчетов можно выявить нарушения, среди действий, зафиксированных в журнале аудита. Отметим также, что при инсталляции Oracle, по умолчанию, аудит выключен, и Oracle не поставляется с какими-нибудь стандартными установками аудита по умолчанию или отчетами для анализа созданного журнала аудита. Все это, по моему мнению, является причиной восприятия аудита как сложного.

Стандартные команды аудита не разрешают контролировать операции на уровне строк. Так же невозможно отслеживать действия привилегированных пользователей, таких как SYS или «as sysdba» до версии Oracle 9iR2.

Возможности аудита Oracle

Задачу аудита базы данных Oracle не следует ограничивать только лишь использованием команд аудита; так же успешно могут быть применены и другие технологии. Приведем некоторые основные методы, которые могут быть использованы для аудита базы данных Oracle:

Аудит Oracle

Это основной тема данной статьи. Все привилегии, которые могут быть предоставлены пользователю или роли базы данных могут быть проконтролированы. Сюда включено доступ на чтение, запись и удаление объектов на табличном уровне. Для более детализованного аудита можно задействовать триггеры.

Системные триггеры

Эта возможность была представлена начиная с Oracle 8 и разрешает выполнение операций триггера, когда имеет место системное событие. Сюда включены запуск и останов базы данных, попытки входа и выхода, создание, изменение и удаление объектов схемы. С помощью автономных транзакций, можно записывать в журнал упомянутые системные события.

Update, delete и insert триггеры

Это “вторая линия обороны”, которая позволяет понять действия пользователей на более детальном уровне. Для того, что бы отслеживать изменения в базе на уровне столбца и строки, можно написать триггеры, которые позволят полностью сохранять данные, до или после выполненного действия. Использование этого типа контроля очень ресурсоемко, так как создается и хранится много дополнительных записей. Кроме того, что существует еще один недостаток, связанный с этим методом — доступ на чтение нельзя отследить с помощью обычных триггеров базы данных.

Детализированный (Fine-grained) аудит

Детализированный аудит решает проблему отслеживания доступа на чтение. Данная возможность основана на внутренних триггерах, срабатывающих, при разборе какой-нибудь части SQL-предложени я. Это очень эффективно, так как SQL-предложени е разбирается единожды для аудита и выполнения. Эта возможность использует предикаты, которые определены и проверяются каждый раз, когда происходит доступ к соответствующим объектам. Fine-grained аудит управляется PL/SQL пакетом который называется DBMS_FGA. Созданная PL/SQL процедура выполняется каждый раз, когда выполняется, соответствующее ей, действие с предикатом. Этот метод позволяет контролировать не только DML-операции на уровне строк и столбцов, но и предложения чтения. Следует предостеречь читателей, в том, что для использования этой возможности необходим некоторый опыт программирования.

Системные журналы

СУБД Oracle генерирует много журнальных файлов, и многие из них могут содержать полезную информацию для проведения аудита. Например, alert log используется для записи информации о запуске и останове базы, а также о вносимых структурных изменениях, таких как добавление файла данных в базу.

В этом документе планируется описать только стандартные встроенные команды аудита. Другие возможности будут отложены для будущих статей.

Некоторые примеры

Из-за большого количества возможностей, настройка аудита базы данных Oracle может показаться довольно обескураживающим мероприятием. В порядке упрощения и конкретизации цели, обозначим две задачи, которые нам предстоит исследовать и проработать.

Аудит доступа к базе данных

Контроль доступа к БД является фундаментальной задачей для того, что бы определить кто, когда и откуда имеет доступ к информации. Неудачные попытки, так же как и попытки входа в аномальное время в течение дня быть отслежены.

Аудит изменений в структуре базы данных

В производственной базе данных никому из пользователей никогда не следует изменять структуру схемы. Администраторам баз данных следует вносить изменения в специально отведенное для этого время. Какие-либо другие изменения следует рассматривать как подозрительные. Наблюдение за структурными изменениями может включить индикаторы некорректного использования базы данных.

Третья задача, которую можно было бы здесь привести, это аудит использования любых системных привилегий. Однако этот пример оставлен для самостоятельного изучения читателем.

Заключительная группа команд аудита, которая может быть задействована это организация контроля за любыми изменениями данных, при помощи самих объектов. Но, к сожалению, этот вопрос выходит из данного рассмотрения ввиду большой специфики инсталляции и приложения.

аудит таких выражений как CREATE TABLE или CREATE SESSION,

аудит привилегий ALTER USER и

аудит на объект на объектном уровне SELECT TABLE.

Основная конфигурация

Записи аудита могут помещаться либо в аудиторскую таблицу базы данных, либо в аудиторский журнал операционной системы. Запись аудита в журнал операционной системы в некоторых случаях более защищена, но эта возможность доступна не для всех платформ и ее специфика зависит от платформы. В этой статье в качестве места хранения для журнала аудита мы будем использовать базу данных.

Аудит включается для записи в базу данных добавлением следующей строки в файле init.ora. Символьная связь к нему обычно может быть найдена в $ORACLE_HOME/dbs

После этого базу данных необходимо перезапустить. Простая проверка покажет, что аудит действительно включен.

SQL> select name,value from v$parameter 2 where name like 'audit%'; NAME VALUE ------------------------------ ---------- audit_trail DB audit_file_dest ?/rdbms/audit SQL>

Но контролируемые действия не отслеживаются до тех пор, пока эти действия не заданы явно; это верно, кроме случаев привилегированного доступа к базе данных, запуска и останова базы данных, структурных изменений, таких как добавление файла данных. Эти действия отслеживаются в файле операционной системы в $ORACLE_HOME/rdbms/audit до тех пор пока audit_file_dest не переопределено в файле init.ora . В Windows эти события появляются в Event Viewer.

Для того, что бы проверить наличие того, что какие-нибудь привилегии или выражения уже используются для аудита, сделайте следующее:

SQL> select * from dba_stmt_audit_opts 2 union 3 select * from dba_priv_audit_opts; no rows selected SQL>

Что бы найти какие объекты уже контролируются аудитом, запросите представление dba_obj_audit_opts.

Рабочие примеры

Давайте сейчас проработаем два примера и посмотрим, что можно изучить. Для начала включите аудит для попыток доступа к базе данных:

SQL> audit create session; Audit succeeded. SQL>

Приведенная команда будет отслеживать доступ всех пользователей, независимо от того успешен он или нет. [by access] это действительное умолчание для данной команды.

Заметка: Формат всех команд аудита по документации Oracle выглядит следующим образом:

audit  
[by user] [by ] [ whenever 
]

Обязательными являются только лишь statement_option и privilege_option части выражения. Другие части являются опционными и их использование позволяет сделать аудит более специфичным.

Что бы пользователь мог задать команду аудита, необходимым условием для него является наличие привилегии «AUDIT SYSTEM». Найти пользователей, которые имеют эту привилегию, можно выполнив следующее:

SQL> select * 2 from dba_sys_privs

Выше приведенные результаты принадлежат базе данных Oracle 9i. Пользователи по умолчанию MDSYS, CTXSYS и WKSYS были бы неплохой мишенью для атакующего, так как любые действия аудита могут быть выключены любым из этих пользователей, что бы скрыть любые предпринятые действия.

Теперь аудит будет отслеживать все попытки доступа, и нам необходимо подождать, когда какие-нибудь пользователи войдут в систему что бы выполнить свою работу. И пока они будут делать это, давайте установим аудит, для контроля изменений в схеме. Для краткости, не все изменения объектов схемы будем отслеживать, в этом примере. Хотя в принципе, можно отслеживать изменения любых объектов БД: таблиц, индексов, кластеров, представлений, последовательностей, процедур, триггеров, библиотек и т.д. В этом примере аудит будет включен на выборочной группе объектов. Настройка аудита может быть выполнена за два этапа, создание команд аудита и запуск на исполнение, как показано ниже:

set head off set feed off set pages 0 spool aud.lis select 'audit '||name||';' from system_privilege_map where (name like 'CREATE%TABLE%' or name like 'CREATE%INDEX%' or name like 'CREATE%CLUSTER%' or name like 'CREATE%SEQUENCE%' or name like 'CREATE%PROCEDURE%' or name like 'CREATE%TRIGGER%' or name like 'CREATE%LIBRARY%') union select 'audit '||name||';' from system_privilege_map where (name like 'ALTER%TABLE%' or name like 'ALTER%INDEX%' or name like 'ALTER%CLUSTER%' or name like 'ALTER%SEQUENCE%' or name like 'ALTER%PROCEDURE%' or name like 'ALTER%TRIGGER%' or name like 'ALTER%LIBRARY%') union select 'audit '||name||';' from system_privilege_map where (name like 'DROP%TABLE%' or name like 'DROP%INDEX%' or name like 'DROP%CLUSTER%' or name like 'DROP%SEQUENCE%' or name like 'DROP%PROCEDURE%' or name like 'DROP%TRIGGER%' or name like 'DROP%LIBRARY%') union select 'audit '||name||';' from system_privilege_map where (name like 'EXECUTE%INDEX%' or name like 'EXECUTE%PROCEDURE%' or name like 'EXECUTE%LIBRARY%') / spool off @@aud.lis

Данный скрипт выведет набор команд аудита в спул файл, который затем запустится для выполнения команд аудита.

Для создания команд аудита можно было бы использовать другой способ, через представления базы данных dba_sys_privs , использующий действительные разрешения пользователей. Этот способ может показаться лучшим решением и включает в себя меньше команд, но потенциально это бы не сработало для случаев, когда новые разрешения предоставлены пользователям. В этом случае, пришлось бы выполнять новые команды аудита после предоставления новых привилегий.

Сейчас, когда все примеры аудита только что включены, установки могут быть просмотрены при помощи этого SQL:

1 select audit_option,success,failure 2 from dba_stmt_audit_opts 3 union 4 select privilege,success,failure 5* from dba_priv_audit_opts SQL> / AUDIT_OPTION SUCCESS FAILURE --------------------------- ---------- ---------- ALTER ANY CLUSTER BY ACCESS BY ACCESS ALTER ANY INDEX BY ACCESS BY ACCESS ALTER ANY INDEXTYPE BY ACCESS BY ACCESS ALTER ANY LIBRARY BY ACCESS BY ACCESS ? EXECUTE ANY LIBRARY BY SESSION BY SESSION EXECUTE ANY PROCEDURE BY SESSION BY SESSION 38 rows selected. SQL>

Каждый раз, когда пользователь пытается что-нибудь затронуть в базе данных, на что включен аудит, ядро Oracle проверяет действие и создает или обновляет (в случае одной записи для сессии) запись в таблице AUD$, владельцем которой является пользователь SYS. Эта таблица по умолчанию находится в табличном пространстве SYSTEM. Кстати говоря, это само по себе может стать причиной проблемы при атаке – отказ в обслуживании. Если табличное пространство SYSTEM заполнится, то база данных зависнет.

AUD$ — особенная таблица [словаря данных], так как только из нее пользователь SYS имеет право удалять из нее записи. Если журнал аудита включен и пишется в базу данных, то число записей в этой таблице необходимо внимательно контролировать что бы удостовериться что она не растет слишком быстро, и не заполнила все системное табличное пространство. Стратегия очистки нуждается в адаптации, что бы сохранять размер таблицы и если необходимо архивировать записи журнала аудита для будущего использования. Одна из тактик может состоять в том, что бы копировать записи в итоговую таблицу, созданную для выполнения спецпроверки с целью выявления злоупотреблений. Эти итоговые таблицы могут располагаться в отдельной базе данных для увеличения защищенности. После копирования таблица sys.aud$ может быть усечена.

Таблицу SYS.AUD$ можно передвинуть в табличное пространство, отличное от SYSTEM, но сначала, уточните это в технической поддержке Oracle, так как это действие может более не поддерживаться.

Только пользователи, которым предоставлен специальный доступ к таблице SYS.AUD$ могут читать, изменять и удалять данные из нее. По умолчанию этими правами владеет SYS, но эти действия может выполнять любой другой пользователь, наделенный необходимыми правами. Существуют две специальные роли, которым разрешен доступ к таблице SYS.AUD$ на select и delete, это роли DELETE_CATALOG_ROLE и SELECT_CATALOG_ROLE. Эти роли не следует предоставлять обычным пользователям.

Путем выборки записей из SYS.AUD$ — Это исходный журнал аудита

Путем выборки записей из dba_audit_trail – Это представление DBA показывающее исходный журнал аудита.

Путем выборки записей из dba_audit_session – Это представление показывает только лишь события входа и выхода.

Простое SQL-предложение может показать попытки соединения в деталях:

SQL> get check_create_session 1 -- 2 -- check_create_session.sql 3 -- 4 col username for a15 5 col terminal for a6 6 col timestamp for a15 7 col logoff_time for a15 8 col action_name for a8 9 col returncode for 9999 10 select username, 11 terminal, 12 action_name, 13 to_char(timestamp,'DDMMYYYY:HHMISS') timestamp, 14 to_char(logoff_time,'DDMMYYYY:HHMISS') logoff_time, 15 returncode 16* from dba_audit_session SQL> / USERNAME TERMIN ACTION_N TIMESTAMP LOGOFF_TIME RETURNCODE ----------- ------ -------- --------------- --------------- -------- SYS pts/1 LOGOFF 09042003:051046 09042003:051641 0 ZULIA pts/1 LOGON 09042003:051641 1017 SYS pts/1 LOGOFF 09042003:051649 09042003:053032 0 SYS pts/2 LOGOFF 09042003:052622 09042003:053408 0 ZULIA pts/1 LOGON 09042003:053032 1017

Существует несколько простых злоупотреблений, которые могут быть обнаружены при исследовании пользовательского доступа в базу данных. Для примера, взглянем на этот отчет и обнаружим следующее:

Неудачные попытки входа

Они могут означать попытки атакующего получить неавторизованный доступ в базу данных. Нижеследующий SQL ярко демонстрирует это:

SQL> select count(*),username,terminal,to_char
(timestamp,'DD-MON-YYYY') 2 from dba_audit_session 3 where returncode<>0 4 group by username,terminal,to_char
(timestamp,'DD-MON-YYYY'); COUNT(*) USERNAME TERMIN TO_CHAR(TIM ---------- --------------- ------ ----------- 1 BILL pts/3 09-APR-2003 3 FRED pts/3 09-APR-2003 4 ZULIA pts/1 09-APR-2003 SQL>

Здесь можно заметить два возможных злоупотребления, первое – это то, что пользователь Zulia пытается войти в систему и получает отказ четыре раза в один и тот же день. Возможно, пользователь забыл свой пароль или может быть кто-то пытается его угадать. Если изменить SQL, как показано ниже, то это даст более детальную информацию:

SQL> select count(*),username,terminal,to_char
(timestamp,'DD-MON-YYYY'),returncode 2 from dba_audit_session 3 group by username,terminal,to_char
(timestamp,'DD-MON-YYYY')
,returncode; COUNT(*) USERNAME TERMIN TO_CHAR(TIM RETURNCODE ---------- ------------ ------ ----------- ---------- 1 BILL pts/3 09-APR-2003 1017 1 EMIL pts/1 09-APR-2003 0 1 EMIL pts/2 09-APR-2003 0 1 EMIL pts/3 09-APR-2003 0 1 EMIL pts/4 09-APR-2003 0 3 FRED pts/3 09-APR-2003 1017 3 SYS pts/1 09-APR-2003 0 1 SYS pts/2 09-APR-2003 0 1 SYSTEM pts/5 09-APR-2003 0 4 ZULIA pts/1 09-APR-2003 1017 1 ZULIA pts/1 09-APR-2003 0 11 rows selected. SQL>

Отчет показывает, что пользователь успешно вошел в систему с этого же терминала, в этот же день. Проверяйте число неудачных попыток входа в систему каждый день. Те пользователи, для которых, число неудачных попыток входа превышает пороговое значение, должны быть изучены.

Попытки доступа несуществующих пользователей в базу данных

Одно интересное дополнение к приведенному выше SQL позволяет отыскать попытки входа в систему под несуществующим пользователем. В этом случае тоже будут созданы записи аудита. Следующий SQL иллюстрирует это:

SQL> select username,terminal,to_char
(timestamp,'DD-MON-YYYY HH24:MI:SS') 2 from dba_audit_session 3 where returncode<>0 4 and not exists (select 'x' 5 from dba_users 6 where dba_users.username=
dba_audit_session.username) SQL> / USERNAME TERMIN TO_CHAR(TIMESTAMP,'D --------------- ------ -------------------- FRED pts/3 09-APR-2003 17:31:47 FRED pts/3 09-APR-2003 17:32:02 FRED pts/3 09-APR-2003 17:32:15 BILL pts/3 09-APR-2003 17:33:01 SQL>

Возможно это тоже злонамеренные действия. Все попытки войти в систему под несуществующим пользователем следует проверять и расследовать каждый день.

Попытки доступа в базу данных в необычное время

Следует выполнять проверки попыток доступа в базу данных во внерабочие часы. Им может оказаться обычная сверхурочная работа, но также легко — неавторизованный доступ. Его можно проверить следующим выражением:

SQL> select username, 2 terminal, 3 action_name, 4 returncode, 5 to_char(timestamp,'DD-MON-YYYY 
HH24:MI:SS'), 6 to_char(logoff_time,'DD-MON-YYYY 
HH24:MI:SS') 7 from dba_audit_session 8 where to_date(to_char(timestamp,
'HH24:MI:SS'),'HH24:MI:SS') < to_date('08:00:00','HH24:MI:SS') 9 or to_date(to_char(timestamp,
'HH24:MI:SS'),'HH24:MI:SS') > to_date('19:30:00','HH24:MI:SS') SQL> / USERNAME TERMIN ACTION_N RETURNCODE TO_CHAR(TIMESTAMP,'D TO_CHAR(LOGOFF_TIME, -------- ------ -------- ---------- -------------------- -------------------- SYS pts/1 LOGOFF 0 09-APR-2003 20:10:46 09-APR-2003 20:16:41 SYSTEM pts/5 LOGOFF 0 09-APR-2003 21:49:20 09-APR-2003 21:49:50 ZULIA pts/5 LOGON 0 09-APR-2003 21:49:50 EMIL APOLLO LOGON 0 09-APR-2003 22:49:12 SQL>

Приведенные выше SQL показывает любые соединения до 8:00 утра и после 7:30 вечера. Любые соединения, особенно те, которые выполнены привилегированными пользователями, такими как SYS или SYSTEM, должны быть исследованы. Особенное внимание следует обратить на то, откуда был произведен доступ. Например, если привилегированный доступ выполнен с машины, которая не находится в отделе администратора, администратор должен выяснить зачем он производился.

Проверка пользователей, которые используют общую учетную запись в базе данных

Следующее выражение SQL ищет пользователей, которые потенциально могут использовать общую учетную запись в базе данных:

SQL> select count(distinct(terminal)),username 2 from dba_audit_session 3 having count(distinct(terminal))>1 4 group by username SQL> / COUNT(DISTINCT(TERMINAL)) USERNAME ------------------------- ---------- 4 EMIL 3 SYS 3 ZULIA SQL>

Здесь показано, что три пользователя входили в систему более чем с одного места. Дальнейшая проверка может показать время, что бы увидеть работали ли они одновременно. Установите временной интервал для данной проверки один день. Приведенный выше SQL показывает лишь направление исследования, без лишних сложностей. И вновь, обнаруженные учетные записи должны быть изучены дополнительно.

Множественные попытки доступа под различными учетными записями с одного и того же терминала

Заключительный пример применяется для нахождения места, откуда фиксировались попытки получения доступа под множеством учетных записей. Данное выражение SQL довольно таки простое и к нему может быть добавлена группировка по дню, а также выведены пользователи для каждого терминала. Рассмотрите простой пример для иллюстрации этой идеи:

SQL> select count(distinct(username)),terminal 2 from dba_audit_session 3 having count(distinct(username))>1 4 group by terminal SQL> / COUNT(DISTINCT(USERNAME)) TERMIN ------------------------- ------ 3 pts/1 2 pts/2 3 pts/3 3 pts/5 SQL>

Данный отчет показывает кого-либо пытающегося получить доступ перебором учетных записей и паролей, но сюда же могут попасть законопослушные пользователи, которые используют различные учетные записи для различных аспектов своей работы. В любом случае администратору следует выяснить это в дальнейшем.

Безусловно, существует множество других сценариев, которые могут отобразить возможные злонамеренные действия. Их проверка несложна, как и тех, что приведены выше. Оставим их читателю для самостоятельных экспериментов. Сообщите мне, если что-то найдете полезными.

В следующем примере, настройки аудита были установлены для определения изменений, выполняемых в схеме базы данных. Сюда можно отнести создание новых объектов или попытки изменения уже существующих.

Простой SQL, приведенный ниже, покажет любые сведения из журнала аудита, имеющие отношения к созданным или измененным объектам:

col username for a8 col priv_used for a16 col obj_name for a22 col timestamp for a17 col returncode for 9999 select username, priv_used, obj_name, to_char(timestamp,'DD-MON-YYYY HH24:MI') 
timestamp, returncode from dba_audit_trail where priv_used is not null and priv_used<>'CREATE SESSION' / SQL> @check_obj.sql ZULIA CREATE TABLE STEAL_SALARY 09-APR-2003 20:07 0 PETE CREATE PROCEDURE HACK 09-APR-2003 20:42 0

Этот пример показывает, что пользователь ZULIA создал таблицу, а пользователь PETE писал PL/SQL процедуру. Любые изменения такого рода, в производственной базе данных, должны быть исследованы. Намного более специфичные злодеяния могут быть обнаружены в отношении изменений объектов и схемы, но в целом, пользователи не должны иметь возможности менять что-либо в производственной базе данных. И как результат, проверка может остаться чисто символической.

Защита базы данных от рассмотренных злонамеренных действий

Рассмотренные примеры — всего лишь основа для использования возможностей аудита Oracle. Настройка аудита это один из первых шагов для обеспечения безопасности базы данных. Использование аудита должно быть частью общего плана безопасности организации, в который входит и Oracle. Следует регулярно контролировать базу данных на неправильность конфигурации или наличие вновь обнаруженных уязвимостей, которые могут стать брешью в информационной безопасности системы.

Из-за своей сложной природы и большого числа различных параметров, сервер Oracle может быть по-разному настроен, однако, что бы наилучшим образом обеспечить безопасность необходимо всегда следовать принципу наименьших привилегий. Как тока база данных станет частью общего плана безопасности и будет корректно сконфигурирована и регулярно проверяема, тогда аудит следует рассматривать как важную часть этой общей стратегии.

В основном, не представляйте какие-либо привилегии обычным пользователям в производственной базе данных, удалите большинство привилегий PUBLIC, удалите, заблокируйте или измените пароли всех учетных записей по умолчанию. Убедитесь в том, что пользователи придерживаются политики безопасности при работе с паролями и включена функция управления паролями.

Важно, чтобы настройки аудита планировались с точки зрения производительности и удобства использования. Журнал аудита также должен был управляем.

Не менее важно то, что данные журнала аудита можно описывать в категориях защиты информации.

Последняя книга автора выпущенная SANS Institute “Безопасность Oracle шаг за шагом- руководство выживания для службы безопасности Oracle ”(«Oracle security step- by-step — A survival guide for Oracle security» ) дает отличное руководство как сконфигурировать Oracle безопасным.

Заключение

Аудит Oracle очень мощное средство и иногда кажется довольно сложным. Как мы увидели во вступлении, существует более чем одна опция доступная для аудита базы данных Oracle. В СУБД Oracle существует возможность контролировать почти все с помощью стандартных команд, но не на строковом уровне. Если вам необходим высоко-уровневый аудит используйте стандартные функции что бы посмотреть общую активность, и затем рассмотреть исследуйте нужное в более мелких деталях.

Так как возможно контролировать почти все типы действий в базе данных Oracle, используя стандартные функции аудита, читателю следует поэкспериментировать, что бы выбрать наиболее полезные настройки аудита для их организации. Сохраняйте его простым и не старайтесь использовать все подряд. Кроме всего прочего, предопределите какие данные будут созданы в журнале аудита и какие злонамеренные действия с их помощью можно выявить. Напишите отчеты, что бы проверить журнал аудита и очищайте его регулярно. Анализируйте данные этих отчетов каждый день и предпринимайте соответствующие действия.

Для более детального аудита, используйте триггеры базы данных и мелко-уровневый(fine grained) аудит. Помните, что для использования и реализации этих методов необходим опыт программирования, так что они должны быть внимательно рассмотрены. Много полезной информации может быть собрано без аудита, на строковом уровне. Кроме всего прочего, внедрите принцип наименьших привилегий, что бы избегнуть изменений и чтений данных пользователями, для которых они не предназначены.

Ссылки

• Oracle security step-by-step -A survival guide for Oracle security, Pete Finnigan 2003, published by SANS Institute
• Oracle security handbook — Aaron Newman and Marlene Theriault, published by Oracle Press.

Oracle кто создал таблицу

← →
bissoft ( 2010-09-15 22:25 ) [0]

Итак, есть относительно большая система, состоящая из клиентских приложений и базы данных oracle 10. Стоит задача хранить историю изменения данных. То есть, у пользователей иногда возникают вопросы — вот неделю назад тут в документе стояло десять тысяч рублей, а теперь стоит двадцать тысяч, что за нафиг? Нужно разобраться кто и когда менял эти данные. Вполне вероятно, это в какой-то степени задача клиентского ПО — вести историю данных, но возможности реализовать это нету, было решено делать универсально со стороны базы данных. Наше решение:

1. Делается GUI-приложение, в котором имеется возможность на основе метаинформации о базе данных (информации о структуре базы) выбирать какие схемы / таблицы / поля отслеживать. Названия объектов за которыми происходит слежение заносится в некую таблицу (ну или список таблиц, неважно).
Также GUI включает в себя средство просмотра самой информации по изменению таблиц в удобном виде (фильтрация и прочее).

2. Существует скрипт БД. Что он делает — проходит по всей базе (по всем схемам или как вариант по некоторым схемам) и к каждой таблице добавляет триггер на insert, update, delete. При срабатывании этого тригера идет запрос к таблицам описания слежения и проверяется, нужно ли вести историю этой таблицы, полей этой таблицы. Если нужно — то старая информация скидывается в дублирующую таблицу (структура которой включает в себя полностью структуру таблицы за которой идет слежение). Таким образом в дублирующей таблице будет история изменения записей.
По прошествии времени, каких-то условий, информация из дублирующих таблиц будет скидываться в дамп и отправляться в архив.
Думаю, в целом принцип ясен, если что — задавайте вопросы.

Некоторые моменты. Почему ко всем таблицам прилепляются триггеры? Чтобы не мучатся с синхронизацией метаописания слежения и реальным положением в базе, не делать сверки и подобное. Что-то не так — бац, пересоздал триггер для всех таблиц, текст триггера однотипный достаточно, для всех таблиц может иметь одинаковое названия типа «__history_trigger». Да, мы понимаем, что это замедляет работу со вставкой, удалением и апдейтом данных, по нашим экспериментам в несколько раз, но это допустимо, железо перекрывает потребности в производительности, а задача такая стоит.

Но такое количество триггеров, конечно, в какой-то степени удручает (особенно, если слежение производится за 15 таблицами, а всего таблиц 500 и получается 500 триггеров). Возможно, есть какие-то триггеры на схему? Вроде бы есть триггер на всю БД, но он сильно системный и туда попадает множество лишней информации, типа создание таблиц, дропа, создание хранимок, триггеров ну и прочее.

Знаем, что в oracle есть трейс, куда скидывается в текстовом виде информация об изменении данных. Но информация текстовая, распарсивать оочень не хочется. И есть подозрение, что включать трейс на промышленной, боевой БД все таки не стоит.

Также есть подозрение, что задача не уникальная и встречались с ней многие. Возможно, есть выработанные стандартизированные методы подхода? На настоящее время с кем общались — все делали кто во что горазд. Зачастую это делается системной вещью, типа налепить триггеров и они будут скидывать информацию об обновлении. Когда потребуется разборка — в руки любимый софт для работы с БД и вручную разбираться что и когда. У нас, к сожалению, стоит задача сделать немного в более удобном виде, с управлением через GUI и просмотром истории там же.

Таким образом принимается любая критика по описанному подходу, какие подводные камни могут встретиться, опыт по созданию такой системы мониторинга может у кого есть? Какие места будут сложные в реализации, что стоит учесть в самом начале? Возможно, существуют совершенно другие подходы к реализации этой задачи, возможно основанные на специфике оракла, возможно там даже с написанием каких-то системных плагинов расширения (DLL, so или подобное). Любые мысли, пожалуйста 🙂

P.S. Фактически, такая система слежения будет достаточно универсальна и не завязана на какой-то конкретный проект. Это просто система, позволяющая отслеживать изменение данных в базе данных oracle. У нас из специфики будет только одно — хранение ID»шки пользователя, который меняет данные, мы будем это получать своим способом, поскольку у нас есть своя система аутентификации (на самом деле там еще звено в виде сервера приложение, но это уже лирика. ) и сохранение аккаунта входа в oracle ничего не скажет, сотни пользователей могут работать под одним Oracle-аккаунтом.
В связи с этим вполне возможно на рынке есть готовые приложения, которые осуществляют данную задачу. Было бы интересно посмотреть.

← →
bissoft ( 2010-09-15 22:25 ) [1]

Допустим, что мы видим из подводных камней:

1) поскольку триггеры создаются ко всем таблицам — исчезает проблема синхронизации. Но остается проблема создания и поддержания в актуальном виде дублирующих таблиц. Конечно, можно КАЖДОЙ таблице делать дублирующую историческую таблицу (даже если нет слежения за этой таблицей), но это, наверное, уже перебор. Но иначе нужно как-то следить. Тут стоить представить процесс разработки. Допустим, перерисовали таблицу под измененные бизнес-требования в каком-нибудь редакторе структуры таблиц. Внесли изменение в таблицу, внесли изменение в клиентское ПО, сделали скрипт обновления структуры для обновления до новой версии ПО.
А вот дублирующую таблицу изменить забыли. В результате триггер исторический может начать плеваться exception и застопорить вставку, обновление и удаление данных. И пятая точка чует, что таких косячков будет немало. Очень интересен опыт тех, кто внедрял подобную систему, с чем больше всего намучались, насколько это усложнило разработку и главное ПОДДЕРЖКУ систем?

2) чисто техническая фишка. По идее триггер должен сработать САМЫМ первым, чтобы унести в историческую дублирующую таблицу старые данные. Ибо если перед ним сработает другой триггер, то там уже могут оказаться не реальные старые данные, а какие-нибудь данные сформированные триггером, сработавшим раньше. ну или что-то в этом роде.

Конечно, хочется предусмотреть как можно больше, чтобы потом потом в процессе реализации не столкнуться с «Ой блин, е-мое, а ведь тут же. как же теперь. «

← →
Дмитрий Тимохов ( 2010-09-15 23:54 ) [2]

Зачем возлагать это на СУБД, если есть сервер приложений?
Напрямую же клиенты с БД не работают, только через СП? Или работают напрямую?

← →
bissoft ( 2010-09-16 08:47 ) [3]

> Зачем возлагать это на СУБД, если есть сервер приложений?

каким образом это можно возложить на сервер приложений?

Распарсивать передаваемый ему текст SQL-запроса. А откуда узнать старые данные для сохранения? Вытаскивать из текста SQL-запроса новые данные? Это как раз чересчур сложная, имхо, задача.

← →
12 © ( 2010-09-16 09:03 ) [4]

велосипед, конечно

не dba, но на его месте начал бы с
http://www.google.ru/webhp?rls=ig#num=20&hl=ru&newwindow=1&rls=ig&q=oracle+%D0%B0%D1%83%D0%B4%D0%B8%D1%82&aq=f&aqi=g1&aql=&oq=&gs_rfai=&fp=67bc4258aacbfe4d

← →
Дмитрий Тимохов ( 2010-09-16 09:22 ) [5]

> bissoft (16.09.10 08:47) [3]
>
>
> > Зачем возлагать это на СУБД, если есть сервер приложений?
>
>
> каким образом это можно возложить на сервер приложений?

ну понял, он просто транслирует запросы от клиентов к БД, а не генерит их сам на основе команд клиентов (удаленных вызовов).
тогда да, СП не подойдет.
тады не знаю )

← →
Sergey13 © ( 2010-09-16 10:03 ) [6]

> [0] bissoft (15.09.10 22:25)

Сугубо ИМХО все.
Вместо нормальной работы по контролю доступа, разграничению прав и проработки бизнес логики предлагается глобальная шняга, которая, если заработает, будет жрать диски и другие ресурсы со скоростью на порядки превышающей нормальную.

Для простейшего контроля достаточно добавить в критические таблицы 2 поля — временнУю метку и юзернейм последнего редактирования записи.

В Оракле помнится был ЛогМайнер и вроде еще какая то СТАНДАРТНАЯ штука (вспоминая прошлые обсуждения этого вопроса, вроде даже ИШ про это рассказывал) с помощью которых можно докопаться практически до любых хронологий изменений. Так что городить свои смысла, по моему, нет.

← →
Kerk © ( 2010-09-16 10:10 ) [7]

> bissoft (15.09.10 22:25) [1]
> Внесли изменение в таблицу, внесли изменение в клиентское
> ПО, сделали скрипт обновления структуры для обновления до
> новой версии ПО.
> А вот дублирующую таблицу изменить забыли. В результате
> триггер исторический может начать плеваться exception и
> застопорить вставку, обновление и удаление данных.

А в чем проблема? Такое заметит сам программист, оно даже до тестеров скорее всего не дойдет.

← →
Игорь Шевченко © ( 2010-09-16 11:12 ) [8]

RTFM: Oracle workspace management

← →
Игорь Шевченко © ( 2010-09-16 11:13 ) [9]

> вот неделю назад тут в документе стояло десять тысяч рублей,
> а теперь стоит двадцать тысяч, что за нафиг? Нужно разобраться
> кто и когда менял эти данные

для дешевых применений написать триггер, который записывает значения в сделанные руками таблицу аудита.

← →
bissoft ( 2010-09-16 16:14 ) [10]

> А в чем проблема? Такое заметит сам программист, оно даже
> до тестеров скорее всего не дойдет.

ну тут да, согласен. Просто для примера. Хочется обозначить подводные камни.

> Вместо нормальной работы по контролю доступа, разграничению
> прав и проработки бизнес логики предлагается глобальная
> шняга

это имеет крайне посредственное отношение к разграничению доступа и правам. Человек вполне может иметь права сделать ДЕЙСТВИЕ, но это не отменяет задачи при наличии желания узнать КТО конкретно сделал этот действие.

> для дешевых применений написать триггер, который записывает
> значения в сделанные руками таблицу аудита.

а можете покритиковать описанный подход в сабже (понимаю, что много букв. )

← →
Sergey13 © ( 2010-09-16 16:32 ) [11]

> [10] bissoft (16.09.10 16:14)
> > Вместо нормальной работы по контролю доступа, разграничению
> > прав и проработки бизнес логики предлагается глобальная шняга
>
> это имеет крайне посредственное отношение к разграничению
> доступа и правам. Человек вполне может иметь права сделать
> ДЕЙСТВИЕ, но это не отменяет задачи при наличии желания
> узнать КТО конкретно сделал этот действие.

Зато имеет непосредственное отношение к бизнес логике, а уже на этом фоне и к правам.
Если КТО УГОДНО может ЧТО УГОДНО менять в ПОДПИСАННОМ документе, то этот бардак логами не спасешь. Если все нормально, но нужна история изменения — значит система просто недоработана. Причем именно в этом месте, а не вообще. Если это криминал и все заменили не просто так, то скорее всего подобные логи можно обойти всякими програмистско-ДБАшными штучками.
ИМХО.

← →
Игорь Шевченко © ( 2010-09-16 18:01 ) [12]

> Если это криминал и все заменили не просто так, то скорее
> всего подобные логи можно обойти всякими програмистско-ДБАшными
> штучками.

Можно сделать так, что факт обхода будет зафиксирован. Иногда и этого достаточно

← →
bissoft ( 2010-09-16 20:49 ) [13]

> Если КТО УГОДНО может ЧТО УГОДНО менять в ПОДПИСАННОМ документе,
> то этот бардак логами не спасешь

ты придумываешь ситуацию, а потом ее критикуешь. Почему кто угодно что угодно?

Нет, есть определенный круг лиц, кто имеет доступ. Они ДОЛЖНЫ иметь доступ. Но это КРУГ лиц. Реальность такова, что потом весь этот допущенный круг лиц утверждает, что они ничего не меняли. Ооочень часто это бывает в виде «Мы ничего не меняли, это программисты программу плохую сделали». Потом приходится тыкать пальцем, что вот конкретно этот человек в это время изменил эти данные, это практика.

← →
Игорь Шевченко © ( 2010-09-16 21:40 ) [14]

bissoft (16.09.10 20:49) [13]

вроде ссылок надавали.
Кайта еще читать не повредит

А вы могли бы навскидку перечислить основные минусы, плюсы подходов:

Аудит с помощью Oracle workspace management VS ручной аудит на триггерах?
Для какой системы чтобы лучше подошло, из опыта?

← →
Игорь Шевченко © ( 2010-09-17 00:16 ) [16]

> Аудит с помощью Oracle workspace management VS ручной аудит
> на триггерах?

навскидку workspace manager недоступен на oracle standard edition, а триггеры доступны везде. С другой стороны workspace manager подерживает реальную версионность данных, а триггеры — только аудит. Триггеры таки можно отключить, если очень постараться, даже с защитой от отключения (на триггерах системных событий). Но следы при этом останутся, так что будет кого спрашивать.

← →
старый маразматик ( 2010-09-17 02:24 ) [17]

> Игорь Шевченко © (17.09.10 00:16) [16]


> Триггеры таки можно отключить, если очень постараться

без админских прав? шо, серьезно? не, ну тогда ораклу надо выкрасить и быбросить.
зы. не верю.

> bissoft (15.09.10 22:25)

у нас на триггерах реализованно. и ничего, пыхтит. а вот аудит стоит на пакетах и прочей критичной лабуде. а то есть товарисчи с шаловливыми ручками. и делаются срезы за день, если состояние пакетов менялось. и с рассылкой по почте с просьбой аргументировать изменения. откат назад в любой момент можно сделать. типа, версионность. весьма удобно.

← →
Рамиль © ( 2010-09-17 09:41 ) [18]

В нашей ERP (в смысле работаем в ней, а не разрабатываем), например, сделана одна таблица. Насколько помню, туда записывается время, таблица в которой произошло изменение, пользователь, тип операции (upd, del, ins) и в блоб вся запись перед изменением в каком то своем формате.
+ одна таблица, ничего менять не надо.
— наверное, медленнее.

← →
bissoft ( 2010-09-17 10:22 ) [19]

> + одна таблица, ничего менять не надо.
> — наверное, медленнее.

основной недостаток такого подхода — нет возможности грамотной выборки, фильтрации и сортировки.

← →
Рамиль © ( 2010-09-17 10:33 ) [20]

> основной недостаток такого подхода — нет возможности грамотной
> выборки, фильтрации и сортировки.

А это так часто и быстро нужно? Таблица и примерная дата обычно известна.
Зато откат изменений удобно делать.

← →
Игорь Шевченко © ( 2010-09-17 10:40 ) [21]

старый маразматик (17.09.10 02:24) [17]

> без админских прав? шо, серьезно?

Без админских, а что ? Прав владельца хватает.

> ну тогда ораклу надо выкрасить и быбросить.

Можешь сам покраситься и выброситься, а можешь матчасть почитать — трындежа всяко меньше будет

← →
Sergey13 © ( 2010-09-17 12:13 ) [22]

> [13] bissoft (16.09.10 20:49)
> ты придумываешь ситуацию, а потом ее критикуешь. Почему кто угодно что угодно?

Я ничего не придумываю. Я описываю варианты. Твое описание подходит под «мой» вариант №2
> Если все нормально, но нужна история изменения — значит система просто недоработана. Причем именно в этом месте, а не вообще.

Охота вместо фиксации юзера/времени в критической таблице делать систему глобального аудита — флаг в руки. Я сразу заявил, что

> Сугубо ИМХО все.

Ты же за имхами сюда пришел? Вот и пользуйся. 😎

Я делал подобный аудит на тригерах. После полугода эксплуатации объем данных аудита на порядок превзошел объем собственно данных. Тормозов особых не было, но думаю, что до них просто не дошло. За это время было одно или два «разбирательства» по поводу «там вчера другое было», которые закончились словами «внимательнее, Маша, надо быть». И фсе. Подумал я про это на досуге — и отключил нахрен. 😎
Это не аргумент для делать/не делать. Это просто иллюстрация моей имхи.

← →
bissoft ( 2010-09-17 12:54 ) [23]

мы софтверная фирма. Заказчик хочет это и платит за это деньги. Может быть, он и не будет это использовать, я не знаю.

Насчет объема — да, предусматриваем систему скидывания данных в дамп, архивация и на полку.

← →
Sergey13 © ( 2010-09-17 13:05 ) [24]

> [23] bissoft (17.09.10 12:54)
> мы софтверная фирма. Заказчик хочет это и платит за это деньги.

С этого бы и начал. Тогда разумеется надо делать! 😎

← →
старый маразматик ( 2010-09-18 04:41 ) [25]

> Игорь Шевченко © (17.09.10 10:40) [21]

да? ну, в понедельник попробую. раньше как-то руки не доходили. насчет отключить без админа (хотя, действительно, я неправильно выразился, админ тут не при чем, эт ты верно заметил, я вумные слова плохо помню, прошу простить, а «админ» — оно как-то короче и легче запоминаетЪся).

так вот, без всякого трындежа, залезу под юзером безправным, который пользует одну табличку по чтению/записи, и у котрой есть триггер. и убЪю гада! без трындежа? так таки убью? или не стоит руки марать?

> а можешь матчасть почитать

могу. я много чего могу. теоретически. даже в космос летать. если мне это действительно надо, или за это платят. а так — многа букав, ниасилю. и потом, методом научного тыка — тоже неплохо получается.

> Sergey13 © (17.09.10 12:13) [22]


> объем данных аудита на порядок превзошел объем

а почему стандартный ораклевый аудит не включили? да, некоторый гемморой со сборкой исходной записи имеется, но зато объем будет не такой огромный. хотя, не помню, фиксируется ли там пользователь, который менял данные. по-идее, должен.

← →
Sergey13 © ( 2010-09-20 11:52 ) [26]

> [25] старый маразматик (18.09.10 04:41)
> а почему стандартный ораклевый аудит не включили?

Во первых потому, что не знали как это готовить. Во вторых, это было 10+ лет назад и интернета, где бы все это можно почитать у нас не было ( или почти или совсем — уже и не помню). В третьих (а может это во первых) хотелось простоты и красивости, что бы прямо из программы можно было посмотреть историю изменения сущности.

← →
Игорь Шевченко © ( 2010-09-20 17:53 ) [27]

старый маразматик (18.09.10 04:41) [25]

> я много чего могу. теоретически. даже в космос летать. если
> мне это действительно надо, или за это платят. а так — многа
> букав, ниасилю. и потом, методом научного тыка — тоже неплохо
> получается.

Ты даже мой пост не хочешь читать.

← →
старый маразматик ( 2010-09-21 21:56 ) [28]

> Игорь Шевченко © (20.09.10 17:53) [27]

дык, я таки почитал. и даже извинился, за некоторую (в данном случае несущественную) неточность, насчет админа. ибо, ежели права владельца раздавать всем, кому не попадя, то кто кому доктор? а мы, таки, говорили об администрировании базы, в коем я постоку-поскоку (хотя хожу под владельцем (да, не под админом, хотя, в моем случае разницы особой нет). ну так, логики не вижу — если владелец чам себя почикает — молодец, это его естественное и неприемлемое право.
или я опять не туды?

зы. а юзер таки нифига не видит. и это правильно.

> Sergey13 © (20.09.10 11:52) [26]

10 лет назад уже тырнета была, ну, хотя и тормознутая. но была. 2000 году. вот, ежели 20 лет назад(или немного меньше). там тоже чего-то было, как оно называлось не помню, но, увы, приобщится не удалось.

> хотелось простоты и красивости

думается, исходную запись собрать можно, причем, они правильно сделали, фиксятся только изменения полей. долго запрос нарисовать, чтобы было всю сущность посмотреть со всей историей?

вот у нас трабла была с изменением пакетов, ну и прочая. непонятно, кто ковырял, и что делал. сейчаз все пишется в табличку, срез на день изменившихся, с рассылкой, и шоб писали, чего меняли и зачем. и в случае чего откатится можно в момент, удобно. и локально код сохранять не надо, хотя я, по-старинке, держу у себя.

← →
Игорь Шевченко © ( 2010-09-21 23:01 ) [29]

старый маразматик (21.09.10 21:56) [28]

Владелец — это тот, кто создал объект (таблицу, триггер, еще что-нибудь).
Владелец же может дать права на таблицу, триггер, еще что-нибудь, кому угодно. Причем, права разные — от чтения до модификации и выполнения.

> ежели права владельца раздавать всем, кому не попадя, то
> кто кому доктор?

Права владельца не раздаются, они существуют и раздать их нельзя, насколько мне известно.

Существуют права, которое плюют на владельца, в их названии присутствует слово ANY (например, DROP ANY TRIGGER), такие права тоже могут быть даны кому угодно (но даются редко)

Кто такой юзер в этом контексте — я не понимаю. Если просто посторонний по отношению к владельцу объекта, так он объекта даже не увидит, не говоря о том, чтобы изменить, удалить и прочее, опять же, если владелец не предоставил права любому (PUBLIC)

Впрочем, все это можно в доке по ораклу прочитать, там более подробно и с картинками написано.

← →
старый маразматик ( 2010-09-21 23:47 ) [30]

> Игорь Шевченко © (21.09.10 23:01) [29]


> Владелец — это тот, кто создал объект

угу. в пределах этого мне и достаточно. вот если поближе к практике? обычному пользователю даются права на таблицы, представления с правом чтения/записи. ф-ции/процедуры/пакеты с правом выполнения. и все. вот с какого бодуна ему(пользователю) давать права на триггеры? если я не совсем уже того, чего бы я давал ANY товарищу, которого я таки хотел поймать на горячем и коварные действия которого я хотел отловить (насколько я понял из сабжа, вопрос именно в этом).

> Существуют права, которое плюют на владельца

видимо, что-то типа SYSDBA, правда, я под ним не ходил(и аудит из-под него-же, наскоько я понимаю). Игорь, согласись, глупо отлавливать тех, кто наделен полными полномочиями по отношению к объекту (подразумеваются данные в таблицах, опять же). ну, как правило. я так понимаю, что такими правами наделяют людей вполне адекватных? хотя, их тоже можно ловить, но это уже именно из админа.

> Если просто посторонний по отношению к владельцу объекта,
> так он объекта даже не увидит, не говоря о том, чтобы изменить,
> удалить и прочее, опять же, если владелец не предоставил
> права любому (PUBLIC)

ну нет, зачем же тогда вся эта система предусмотрена? естественно ничего не увидит и не сможет. почему я и как-то твою первую цидулину странно понял.

хотя. читал я краем глаза, что есть там дырки, и можно там пошалить по-крупному. но, меня это как-то особо не интересует, а вопросами безопасности пусть занимаются те, кому за это платят.

← →
Sergey13 © ( 2010-09-22 10:30 ) [31]

> [28] старый маразматик (21.09.10 21:56)
> 10 лет назад уже тырнета была

А я и не говорю, что его не было как класса. Я говорю, что у меня (у нас в конторе) 10+ (+ это значит больше) лет назад его или не было совсем или был дайлап 28к деленный человек на 10-12 по 2-3 часа в день. Конкретнее не помню.

← →
Думкин © ( 2010-09-22 10:36 ) [32]

> вот неделю назад тут в документе стояло десять тысяч рублей,
> а теперь стоит двадцать тысяч, что за нафиг?

а почему вообще возможна правка в документе, а не черновике? Если документ разнесен, то правок допускать нельзя. И если вдруг в платеже вместо 10 появилось 20, то смотреть разноски и кто их сделал.

← →
старый маразматик ( 2010-09-22 22:02 ) [33]

> Sergey13 © (22.09.10 10:30) [31]


> был дайлап

угу, таки восемь метров инсталяхи скачать. как сейчаз помню. особливо, когда, прождав часа два, на 90% — обрыв.
но, шоб почитать доку — так проблем особливых не было.

> Думкин © (22.09.10 10:36) [32

> а почему вообще возможна правка в документе

и даже необходима. ибо, криворукая криволапость такого иногда туда наваляет. я вот сегегодня нарвался в очередной раз. поэтому правка — существенно необходимый элемент, даже в глубоко забытых периодах деятельности фирмы. ты уж поверь мне, на-слово.

> то смотреть разноски и кто их сделал

дык, к тому в оракле и есть система аудита(а вот на кого напускать — это админ таки решает). и никто не уйдет обиженным(с)тыренно

← →
Думкин © ( 2010-09-23 08:14 ) [34]

> даже в глубоко забытых периодах деятельности фирмы. ты уж
> поверь мне, на-слово.
>

Это я понимаю, но англичане ружья кирпичом не чистят. Это статья есть такая, по поводу правок в отработанном. 🙂

← →
старый маразматик ( 2010-09-23 22:05 ) [35]

Удалено модератором

← →
Юрий Зотов © ( 2010-09-24 13:59 ) [36]

Насчет прав и владельцев встречал такой подход. В БД есть 3 схемы — девелоперская, тестовая и боевая. В девелоперской схеме разработчик — владелец всего и творит все, что ему нужно (иначе как разрабатывать?). Естественно, никто не запрещает ввести для отдельных разработчиков и какие-то ограничения, поскольку разработчики в команде бывают разные.

Когда задача решена, все изменения в БД переносятся из девелоперской схемы в тестовую, но при этом раздаются нужные права, а владельцем новых объектов БД становится админ. В тестовой схеме разработчик имеет ограниченные права — лишь те, что нужны ему для тестирования (например, права конечного юзера плюс права на просмотр чего-то). Тем самым, в процессе тестирования проверяется как новый функционал, так и правильность скриптов переноса из схемы в схему и раздачи прав.

После завершения тестирования запускаются те же скрипты (уже проверенные) и происходит перенос в боевую схему — с которой и работают конечные юзеры.

← →
Думкин © ( 2010-09-24 14:11 ) [37]

> В БД есть 3 схемы — девелоперская, тестовая и боевая.

У нас так и для кода и для БД. Сама структура приложения такая, что это все идет одной связкой.