Защита информации в базах данных

Параметр <привилегия> представляет собой следующую конструкцию:

<привилегия>::=

{SELECT | DELETE | INSERT | UPDATE | EXECUTE | REFERENCES }

Параметр WITH GRANT OPTION поможет пользователю, которому вы предоставляете права, назначить права на доступ к объекту другим пользователям. Его использование требует особой осторожности, поскольку при этом владелец теряет контроль над предоставлением прав на доступ другим пользователям. Лучше всего ограничить круг пользователей, обладающих возможностью управлять назначением прав.

Необязательный  параметр AS {имя_группы | имя_роли} позволяет указать участие пользователя в роли, обеспечивающей предоставление прав другим пользователям.

Единственное  право доступа, которое может быть предоставлено для хранимой процедуры, - право на ее выполнение «EXECUTE». Естественно, кроме этого владелец хранимой процедуры может просматривать и изменять ее код.

Для функции  можно выдать право на ее выполнение, а кроме того, выдать право «REFERENCES», что обеспечит возможность связывания функции с объектами, на которые она ссылается. Такое связывание позволит запретить внесение изменений в структуру объектов, способных привести к нарушению работы функции.

Права на выполнение команд SQL

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

<предоставление_права_выполнения>::=

GRANT  {ALL   |   <команда>[,...n]}

ТО  {имя_пользователя   |   имя_группы   |   имя_роли}   [,...п]

Параметр <команда> представляет собой следующую конструкцию:

<команда>::=

{CREATE'DATABASE   |   CREATE TABLE   |   CREATE VIEW   | CREATE  DEFAULT   |   CREATE  RULE   |   CREATE   PROCEDURE |   BACKUP DATABASE   |

BACKUP LOG   |   ALL  )

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

Неявные права

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

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

Запрещение  доступа

Система безопасности SQL Server имеет иерархическую структуру, и поэтому роли базы данных включают в себя учетные записи и группы Windows 2003/ХР, пользователей и роли SQL Server. Пользователь же, в свою очередь, может участвовать в нескольких ролях и одновременно иметь разные права доступа для разных ролей. Когда одна из ролей, в которых состоит пользователь, имеет разрешение на доступ к данным, он автоматически имеет аналогичные права. Тем не менее, если возникает необходимость, пользователю можно запретить доступ к данным или командам, тогда аннулируются все разрешения на доступ, полученные им на любом уровне иерархии. При этом гарантируется, что доступ останется запрещенным независимо от разрешений, предоставленных на более высоком уровне. [4, 287]

Для запрещения доступа к объектам базы данных используется команда:

<запрещение_доступа>:: =

DENY   {ALL   [PRIVILEGES) |   |   <привилегия>   [,…n]}

{   ((имя_столбца  [,...n])] ON { имя_таблицы  |

имя_просмотра}

| ON {имя_таблицы  |  имя_просмотра  }

[имя_столбца  [, . . .n])]

|  ON {имя_хранимой_процедуры  |

имя_внешней_процедуры)}

TO {имя_пользователя  |  имя_группы | имя_роли}   [,...:.]

[CASCADE ]

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

Для запрещения выполнения команд SQL применяется оператор:

<запрещение_выполнения>: : =

DENY   {ALL   |   <команда>[,...n]}

ТО {имя_пользователя  |  имя_группы  |

имя_роли}   [,…n]

Неявное отклонение доступа

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

<неявное_отклонение_доступа>:: =

REVOKE  (GRANT OPTION FOR]

{ALL  |   PRIVILEGES) I   |   <привилегия>   [,…n]}

{   [(имя_столбца   [,…n])]  ON

{  имя_таблицы  |  имя_просмотра}

|  ON {имя_таблицы |  имя_просмотра }

[имя_столбца  [,…n])]

| ON {имя_хранимой_процедуры |

имя_внешней_процедуры}}

TO  |   FROM {имя_пользователя  |  имя_группы  |

имя_роли} [,...n]

[CASCADE ]

[AS  {имя_группы  |  имя_роли  }]

Для неявного отклонения разрешения на выполнение команд SQL используется следующая команда:

<неявное_отклонение_разрешения>::=

REVOKE {ALL  |   <команда>[,...n]}

FROM {имя_пользователя | имя_группы | имя_роли} [,…n]

Смысл параметров аналогичен параметрам команд «GRANT»  и «DENY». Параметр «GRANT OPTION FOR» используется, когда необходимо отозвать право, предоставленное параметром «WITH GRANT OPTION» команды «GRANT». Пользователь сохраняет разрешение на доступ к объекту, но теряет возможность предоставлять это разрешение другим пользователям.

Конфликты доступа

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

При разрешении конфликтов доступа SQL Server руководствуется  следующим принципом: разрешение на предоставление доступа имеет самый низкий приоритет, а на запрещение доступа — самый высокий. Это значит, что доступ к данным может быть получен только явным его предоставлением при отсутствии запрещения доступа на любом другом уровне иерархии системы безопасности. Если доступ явно не предоставлен, пользователь не сможет работать с данными [23, 78].

Выводы по третьей главе

Система безопасности SQL Server имеет несколько уровней  безопасности:

• операционная система; . SQL Server;
• база данных;
• объект базы данных.

Механизм безопасности предполагает существование четырех  типов пользователей:

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

Модель безопасности SQL Server включает следующие компоненты:

• тип подключения к SQL Server;
• пользователь базы данных;
• пользователь (guest);
• роли (roles).

Для создания пользователя в среде MS SQL Server следует предпринять следующие шаги:

1. Создать в базе данных учетную запись пользователя, указав для него пароль и принятое по умолчанию имя базы данных (процедура sp_addlogin).

2. Добавить этого пользователя во все необходимые базы данных (процедура sp_adduser).

3. Предоставить ему в каждой базе данных соответствующие привилегии (команда GRANT).

Система безопасности SQL Server имеет иерархическую структуру, и поэтому роли базы данных включают в себя учетные записи и группы Windows 2003/ХР, пользователей и роли SQL Server. Пользователь же, в свою очередь, может участвовать в нескольких ролях и одновременно иметь разные права доступа для разных ролей. Когда одна из ролей, в которых состоит пользователь, имеет разрешение на доступ к данным, он автоматически имеет аналогичные права. Тем не менее, если возникает необходимость, пользователю можно запретить доступ к данным или командам, тогда аннулируются все разрешения на доступ, полученные им на любом уровне иерархии. При этом гарантируется, что доступ останется запрещенным независимо от разрешений, предоставленных на более высоком уровне.

 

 

 

 

 

 

 

 

 

ЗАКЛЮЧЕНИЕ

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

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

Существует  много путей утечки информации, например визуальный контакт (видео/фото/аудиосъемка), банальный инсайд (подкуп сотрудников), утечки по техническим каналам передачи информации, на сменном носителе (флешке), сбор информации при помощи жучков и электромагнитных наводок. Кроме того, утечкой может считаться просто несанкционированный доступ к информации (ознакомление): сотрудник прочитал документ на принтере или на незалоченном компьютере коллеги, а потом рассказал другу по телефону из дома. [27]

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

Для решения  задач защиты от утечек многие компании используют традиционные способы:

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

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

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

перекрытие  компьютерных портов ввода-вывода информации;

установка на локальные  компьютеры программ, следящих за всеми  операциями пользователей (перехват клавиатуры, снятие скриншотов, контроль операций с буфером обмена);

физические  ограничения - обращение с защищаемой информацией в замкнутом сегменте сети (без интернета, без USB-портов и пр.).

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

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

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

• создание эксплуатация систем защиты информации является сложным и ответственным процессом;
• система защиты должна быть достаточной, надежной, эффективной и управляемой. Эффективность защиты информации достигается не количеством денег, потраченных на её организацию, а способностью её адекватно реагировать на все попытки несанкционированного доступа к информации;
• мероприятия по защите информации от несанкционированного доступа должны носить комплексный характер, т. е. объединять разнородные меры противодействия угрозам (правовые, организационные, программно-технические);
• основная угроза информационной безопасности компьютерных систем исходит непосредственно от сотрудников. С учетом этого необходимо максимально ограничивать круг сотрудников, допускаемых к конфиденциальной информации, так и круг информации, к которой они допускаются (в том числе и к информации по системе защиты). При этом каждый сотрудник должен иметь минимум полномочий по доступу к конфиденциальной информации.