Защита данных

обеспечения

ведение журналов
Обход системы защиты

и юридические меры .
Технические средства защиты .
Программные средства защиты .
Под

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

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

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

иных лиц – это означает зафиксировать по отношению к ним

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

доступа.
Идентификация и подтверждение подлинности.
Автоматическое ведение журналов.
Шифровка данных.

базе данных должен быть зарегистрирован в системе под определенным именем

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

CREATE USER user {UDENTIFIED BY password|EXTERNALLY};
DROP USER user [CASCADE];

которые могут предоставляться группам пользователей или другим ролям.
Роли введены для

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

CREATE ROLE role {UDENTIFIED BY password|EXTERNALLY};
DROP ROLE role;

может предоставляться ВСЕМ, конкретному пользователю или другой роли. Приписываемый роли

пользователь или другая роль может получить право на ее администрирование.

GRANT role_list TO {PUBLIC |{user | role}... } [WITH ADMIN OPTION]; REVOKE role_list FROM {PUBLIC |{user | role}... }

Примеры:

GRANT SpecialRole TO Smith WITH ADMIN OPTION; GRANT SpecialRole TO AccountGraoupRole; GRANT SpecialRole TO PUBLIC;

право выполнять определенные ОПЕРАЦИИ над ОБЪЕКТАМИ БД
А также возможность передачи

полученных прав другим

GRANT {ALL PRINILEGES | privileges_list } ON DB_object TO {PUBLIC | {user | role}...} [WITH GRANT OPTION];

Примеры:

GRANT SELECT, UPDATE ON TEACHER TO Smith, Jane; GRANT ALL PRIVILEGES ON ROOM TO Ann WITH GRANT OPTION; GRANT SELECT ON LECTURE TO PUBLIC; GRANT RERFERENCES(SBJNO), UPDATE ON SUBJECT TO Kate;

аналогичную REVOKE.
Многократно предоставленные привилегии должны быть отменены всеми.
Каскадный эффект при

отмене привилегий.

REVOKE {ALL PRINILEGES | privileges_list } ON DB_object FROM {PUBLIC | {user | role}...} [CASCADE | RESTRICT];

Пример:

REVOKE ALL PRIVILEGES ON ROOM FROM Smith, Jane CASCADE;

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

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

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

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

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

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

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

полной (кто подключался или пытался подключиться, с какого терминала или узла сети, в какое время и т.д.) ;
Регистрация действий пользователей по использованию ВСЕХ ресурсов системы, включая и данные, а также других действий и событий, которые тем или иным образом могут повлиять на защиту данных .
Предоставление администратору возможности просмотра ВСЕХ собранных данных и их анализа, выявления опасных с точки зрения системы защиты событий, установления их причины и пользователей, ответственных за нарушение политики безопасности.

можно получить доступ в обход системы защиты. неадекватно изменить их

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