11. Защита БД от несанкционированного доступа

Понятие защиты информации касаются не только данных, хранящихся в БД [4]. Уязвимость системы защиты может возникать и в других ее частях, что, в свою очередь, подвергает угрозе и БД. Таким образом, защита должна охватывать весь объект информационной деятельности (организации) в целом: оборудование, используемое программное обеспечение, персонал и данные [2, 4, 6, 7, 21].

Защита БД – это предотвращение любых преднамеренных или непреднамеренных угроз с помощью различных компьютерных и некомпьютерных средств [4].

Угроза - любые обстоятельства или события, которые могут быть причиной нарушения политики безопасности информации и (или) нанесение ущерба организации [22].

Угроза может быть вызвана ситуацией или событием способным принести вред организации, причиной которой может стать человек, явление или стечение обстоятельств. Умышленные угрозы всегда совершаются людьми, являющимися авторизованными или неавторизованными пользователями, которые могут и не быть сотрудниками организации. Любая угроза должна рассматриваться как потенциальная возможность нарушения системы защиты, которая в случае своей реализации может осуществить то или иное негативное влияние (табл. 11.1). Продолжительность периода бездействия и скорость восстановления БД зависят от ряда факторов:

1. Есть ли в системе резервное оборудование с развернутым программным обеспечением.
2. Когда в последний раз выполнялось резервное копирование системы.
3. Время, необходимое на обновление системы.
4. Существует ли возможность обновления и ввода в работу данных, которые были разрушены.

Таблица 11.1

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

1) похищения и фальсификация данных;

2) потеря конфиденциальности (нарушение тайны);

3) нарушение неприкосновенности личных данных;

4) потеря целостности;

5) потеря доступности.

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

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

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

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

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

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

11.2.1. Авторизация

Авторизация - это предоставление полномочий, позволяющих их владельцу иметь законный доступ к системе или к ее объектам [4]; установления соответствия между сообщением и его источником [22].

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

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

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

11.2.2. Аутентификация

Аутентификация - процедура проверки соответствия предоставленного идентификатора объекта компьютерной системы на предмет принадлежности его этому объекту, установление или подтверждение подлинности [22].

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

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

11.2.3. Механизм представления данных

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

11.2.4. Средства поддержки целостности данных

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

11.2.5. Резервное копирование

Резервное копирование - это процедура, которая периодически выполняется для получения копии БД, ее файла журнала и программ на носители, которые хранятся отдельно от системы [4].

Существуют следующие виды резервного копирования:

1) полное(full backup);

2) дифференцированное(differential backup);

3) дополнительное(incremental backup);

4) пофайловое(file-by-file backup);

5) блочное инкрементальное(block level incremental backup).

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

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

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

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

Ведение журнала - это процедура создания и обслуживания файла журнала, который содержит сведения о всех изменениях, внесенных в БД с момента записи последней резервной копии, и предназначен для обеспечения эффективного обновления системы в случае ее отказа [4].

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

Контрольная точка - это момент синхронизации между состоянием БД и состоянием журнала выполнения трансакций. В этот момент все буферы принудительно сбрасываются на устройства вторичной памяти [4].

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

11.2.6. Обновление

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

11.2.7. Шифрование

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

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

11.2.8. Вспомогательные процедуры

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

11.2.8.1. Аудит

Аудит - это вспомогательная процедура, которая предназначена для проверки полноты привлечения предусмотренных средств управления и соответствия уровня защищенности БД установленным требованиям [4].

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

1. Поддержка точности вводимых данных.
2. Поддержка точности процедур обработки данных.
3. Предотвращение появления и своевременное выявление ошибок в процессе выполнения программ.
4. Корректное тестирование, документирование и сопровождение разработанных программных средств.
5. Предупреждение несанкционированного изменения программ.
6. Предоставление прав доступа и контроль над использованием программ.
7. Поддержка документации в актуальном состоянии.

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

11.2.8.2. Установка нового прикладного програмного забезпечення

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

11.2.8.3. Установка и модернизация системного программного обеспечения

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

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

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

11.3.1. Классификация методов некомпьютерного контроля

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

- меры обеспечения безопасности и планирования защиты от непредвиденных обстоятельств;

- контроль за персоналом;

- защита помещений и хранилищ;

- контроль физического доступа;

- гарантийные соглашения;

- договоры на сопровождение.

11.3.2. Меры обеспечения безопасности и планирования защиты

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

В документе о мерах безопасности рекомендуется отражать:

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

- ответственность и обязанности отдельных работников;

- дисциплинарные меры, принятые в случае выявления нарушения установленных ограничений;

- процедуры, которые должны обязательно выполняться.

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

- сведения о том, кто является главным ответственным лицом и как можно установить с ним контакт;

- информацию о том, кто и на каком основании принимает решение относительно возникновения чрезвычайной ситуации;

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

В эти требования входят:

- сведения о расположении альтернативных сайтов;

- сведения о необходимом дополнительном оборудовании;

- сведения о необходимости дополнительных линий связи.

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

- сведения о наличии страховки на случай данной конкретной ситуации.

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

11.3.3. Защита помещений, хранилищ и контроль за работой персонала

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

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

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

11.3.4. Контроль физического доступа

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

Внутренний контроль используется внутри отдельных сооружений и предназначен для наблюдения за теми, кто будет иметь доступ в определенные помещения. Например, наиболее «ответственные» помещения (скажем, те, в которых установлены основные компьютеры) могут быть оборудованы системами входного контроля. В таких системах могут использоваться различные средства - например, специальные ключи, карточки, кодовые замки или способы указания пароля. Наиболее сложные комплексы предполагают использование отпечатков пальцев, снимков радужной оболочки глаза, фиксации особенностей голоса или почерка. Однако в настоящее время далеко не все коммерческие организации применяют столь изощренные методы контроля - в основном из-за их высокой стоимости.

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

11.3.5. Гарантийные договора

Гарантийные договора - это юридические соглашения относительно программного обеспечения, заключенные между разработчиками программ и клиентами, на основании которых некоторая третья фирма обеспечивает хранение исходного текста программ, разработанных для клиента. Это одна из форм страховки клиента на случай, если компания-разработчик отойдет от дел. В этом случае клиент получит право забрать исходные тексты программ у третьей фирмы, вместо того чтобы остаться с прикладной программой, лишеной всякого сопровождения. Данная область юриспруденции считается одной из тех, в которых очень часто допускаются ошибки и различные недооценки. По мнению некоторых авторов, 95% всех гарантийных договоров по программному обеспечению не достигает своей первоначальной цели. Чтобы избежать ошибок, при заключении подобных сделок необходимо тщательно продумывать следующее:

- тип материалов, помещаемых на хранение;

- процедуры обновления и поддержки актуальности этих материалов;

- сведения об использовании программного обеспечения от сторонних производителей;

- необходимость проведения верификации сберигаемых материалов;

- условия, при которых материалы могут быть переданы клиенту;

- четкая регламентация процесса передачи сберигаемых материалов.

11.3.6. Договора на сопровождение

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

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

1. Исключение выполнения запросов, работающих с незначительным количеством записей БД.
2. Случайное внесение дополнительных строк в основной набор данных, обработанный запросом. В результате ответ будет содержать определенную ошибку и позволит лишь оценить правильное значение.
3. Использование для ответов на запросы только случайных наборов исходных данных.
4. Хранение истории выполнения и отклонения любых запросов, использующих значительное количество исходных данных, обработанных предыдущим запросом.

11.5.1. Базовые модели управления доступом

11.5.1.1. Мандатная модель

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

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

Первое правило понятно. Второе правило дополняет первое. Оно предотвращает преднамеренное или непреднамеренное раскрытие тайн для пользователей с более низкими уровнями допуска.

Такая организация допуска к объектам имеет ряд недостатков:

1. Модель не имеет механизма ограничения допуска к объектам одного уровня секретности для случая, когда два пользователя с одноковимы уровнями допуска выполняют разные обязанности, но не должны знать о деятельности друг друга.
2. Существенное ограничение коммуникативных возможностей между пользователями, которые имеют разные уровни допуска. С одной стороны, пользователь не имеет обратной связи со своими коллегами, имеющими более высокий уровень допуска. Он никогда не узнает, получили его информацию, которую он изложил для них на своем уровне доступа. С другой стороны, комментарии пользователей никогда не дойдут до тех, кто имеет более низкий уровень доступа.

Поэтому на практике мандатную модель используют совместно с другими моделями.

11.5.1.2. Дискреционная модель

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

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

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

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

На практике, даже при уменьшении размерности матрицы доступа, продумать политику безопасности, то есть грамотно распределить полномочия между пользователями системы, очень сложно. Методы и средства, которые позволяют это сделать описаны в специальной литературе [1, 3, 4].

11.5.1.3. Ролевая модель

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

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

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

Из простоты организации ролевой модели вытекает ряд недостатков:

1. Принятие роли пользователя относительно всех объектов системы приводит к необходимости распределения сфер управления или к влиянию пользователей на бизнес-процессы путем образования ряда однотипных ролей, которые касаются административно самостоятельных единиц организации. Таким образом, ролей «руководитель подразделения» будет создано столько, сколько однотипных подразделений входит в структуру организации. А в пределах подразделения могут быть и другие роли. Одним из путей выхода из данной ситуации является разделение системы на домены и использование отдельной ролевой модели для каждого домена. Некоторые авторы такой подход считают более надежным.
2. Сужение границ применения ролевой модели к рамкам систем, в которых не предусмотрено использование авторских материалов в документах. Этот недостаток вытекает из отсутствия возможности определения «хозяина объекта».
3. Действия, которые могут выполнять пользователи, касаются без исключения всех объектов системы. Таким образом «изымать» из системы любой объект может любой, независимо от того, создавал, использовал он этот объект или нет. То же касается «создания» и «корректировки» объекта, которые могут стать неожиданными для коллег, сферу деятельности которых это затрагивает непосредственно. Выход из этой ситуации в рамках ролевой модели - дифференциация элементарных операций, в название которых прилагается добавлять необходимый идентификатор объекта. Например: «изъятие договора», «изъятие накладной» и так далее.

Иногда недостатки ролевой модели компенсируются внешними средствами. Например, предоставление объектам системы определенных свойств: «хозяин объекта», «уровень секретности» и тому подобное. В таком случае процедура проверки размещается в установленном месте приложения для подтверждения информации, предоставляемой как модулем ролевой безопасности, так и объектом, которому предложено выполнить текущие действия. Некоторые библиотеки ролевой безопасности предоставляют возможности написания сценариев проверки действий над объектами. Эти сценарии отличаются от приведенных процедур проверки местоположением (они хранятся в настройках библиотеки) и тем, что написаны на другом языке программирования.

11.5.2. Реализация дискреционной модели доступа к объектам БД

Стандарт языка SQL использует дискреционную модель доступа к объектам БД. Объекты защиты, как и механизм защиты встроены непосредственно в БД. СУБД позволяет настраивать этот механизм. Пользователи БД регистрируются на уровне СУБД, но информация о них отражена непосредственно в БД, где им предоставлены те или иные привилегии.

Привилегия доступа - это возможность выполнять определенный вид действий над конкретными объектами БД, которая предоставлена пользователю [4].

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

Привилегии доступа могут устанавливаться как системным администратором (например, по умолчанию в Interbase - это пользователь с именем SYSDBA), так и пользователем, которому системный администратор предоставил такое право. Например, для БД «БИБЛИОТЕКА» - это пользователь с именем S. Каждый объект, созданный в среде SQL, имеет своего владельца. Владелец объекта является единственной персоной, которая знает о его существовании и имеет право выполнять с ним любые операции. Предоставление и отмена пользователям привилегий в SQL реализуется операторамиGRANT и REVOKE соответственно [10, 14, 15 ]. Оператор GRANT имеет следующий формат:

После предложения GRANT определяются привилегии доступа из набора, установленного в стандарте ISO: SELECT - право выбирать данные из таблицы; INSERT - право вставлять в таблицу новые строки; UPDATE - право изменять данные в таблице; DELETE - право удалять строки из таблицы; REFERENCES - право ссылаться на столбцы указанной таблицы в описаниях требований поддержания целостности данных; USAGE - право использовать домены, проверки, наборы символов и трансляции. Если пользователю дается весь <список привилегий>, то вместо их перечисления указывается предложение ALL [PRIVILEGES].

После предложения ТО обязательно приводится список объектов или список пользователей, которым предоставляются привилегии доступа к таблице или представлению данных, имя которых указаны после предложения ON [TABLE], или разрешения на выполнение хранимых процедур (EXECUTE ON PROCEDURE Имя). Список пользователей формируется из имен, зарегистрированных в СУБД. Список объектов может содержать хранимые процедуры, триггеры и представления данных, которые определены внутри БД. Предложение PUBLIC предоставляет привилегии не только всем существующим пользователям, но и всем тем, которые будут определены в БД впоследствии.

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

Конструкция GROUP имя группы пользователей UNIX позволяет давать привилегии доступа к таблицам и представлениям данных пользователям, которые определены на уровне операционной системы UNIX. Эта опция добавлена исключительно для приложений-клиентов, работающих под управлением этой операционной системы. Она не является стандартной для SQL. Имя группы должно быть определено в /etc/group. С другими особенностями работы оператора GRANT можно ознакомиться в документации СУБД.

Оператор REVOKE имеет следующий формат:

Все параметры идентичны по содержанию параметрам оператора GRANT, кроме параметра GRANT OPTION FOR, который изымает право выдачи привилегий у пользователей из <список пользователей>. Привилегии может отозвать только тот, кто её предоставил. Если пользователь теряет привилегии определенного вида, то назначенные ему привилегии всех остальных видов остаются в силе.

Наличие операторов CREATE ROLE и DROP ROLE в СУБД не указывает на присутствие элементов ролевой модели доступа к объектам БД (см. <ролевые привилегии> синтаксиса оператора GRANT). Эти операторы используют для образования групп пользователей, имеющих одинаковые полномочия. Это полностью укладывается в рамки дискреционной модели. Формат операторов для выбранной СУБД нужно смотреть в соответствующей документации. Например в СУБД Interbase он такой:

CREATE ROLE <имя роли>;

DROP ROLE <имя роли>.

1. Какие возникают проблемы в случае ограничения механизмами защиты данных, которые встроены в СУБД?
2. От каких факторов зависит скорость восстановления БД после негативного вмешательства?
3. Какие потенциальные угрозы БД Вам известны?
4. Какие компьютерные средства контроля применяются для защиты БД?
5. Какие компьютерные средства контроля используются при предоставлении прав и определения пользователя?
6. С помощью какого механизма компьютерного контроля можно ограничить доступ пользователя к данным?
7. Какие механизмы защиты касаются непосредственно БД?
8. В чем заключается особенность применения вспомогательных процедур, которые отвечают за защиту БД?
9. Как классифицируются некомпьютерные средства контроля?
10. Какая существует разница между мерами безопасности и планированием защиты от непредвиденных обстоятельств?
11. Какие некомпьютерные средства защиты помещений и контроля за работой персонала Вам известны?
12. Какие Вам известны юридические меры, обеспечивающие защиту данных?
13. Какие особенности защиты информации статистических БД?
14. Дайте определение известных Вам базовых моделей управления доступом к данным.
15. Какие особенности защиты имеет мандатная модель управления доступом к данным?
16. В какой модели управления доступом к данным и каким образом применяется матрица доступа?
17. Какие приемы используются для сокращения размерности матрицы доступа?
18. Какие преимущества и недостатки ролевой модели доступа к данным Вам известны?
19. Каким образом компенсируются недостатки ролевой модели?
20. Какие возможности установки и отмены привилегий доступа на уровне СУБД Вам известны?