Переименовать файл bash. Копирование, перемещение, создание и удаление файлов и каталогов. $ mv опции файл-источник файл-приемник
5.1. Методы обеспечения безопасности
В современных СУБД поддерживается один из двух широко распространенных подходов к вопросу обеспечения безопасности данных, а именно избирательный подход или обязательный подход. В обоих подходах единицей данных или "объектом данных", для которых должна быть создана система безопасности, может быть как вся база данных целиком или какой-либо набор отношений, так и некоторое значение данных для заданного атрибута внутри некоторого кортежа в определенном отношении. Эти подходы отличаются следующими свойствами:
1. В случае избирательного управления некий пользователь обладает различными правами (привилегиями или полномочиями) при работе с разными объектами. Более того, разные пользователи обычно обладают и разными правами доступа к одному и тому же объекту. Поэтому избирательные схемы характеризуются значительной гибкостью.
2. В случае обязательного управления, наоборот, каждому объекту данных присваивается некоторый классификационный уровень, а каждый пользователь обладает некоторым уровнем допуска. Следовательно, при таком подходе доступом к определенному объекту данных обладают только пользователи с соответствующим уровнем допуска. Поэтому обязательные схемы достаточно жестки и статичны.
Независимо от того, какие схемы используются – избирательные или обязательные, все решения относительно допуска пользователей к выполнению тех или иных операций принимаются на стратегическом, а не техническом уровне. Поэтому они находятся за пределами досягаемости самой СУБД, и все, что может в такой ситуации сделать СУБД, – это только привести в действие уже принятые ранее решения. Исходя из этого, можно отметить следующее:
Во-первых. Результаты стратегических решений должны быть известны системе (т.е. выполнены на основе утверждений, заданных с помощью некоторого подходящего языка) и сохраняться в ней (путем сохранения их в каталоге в виде правил безопасности, которые также называются полномочиями).
Во-вторых. Очевидно, должны быть некоторые средства регулирования запросов доступа по отношению к соответствующим правилам безопасности. (Здесь под "запросом, доступа" подразумевается комбинация запрашиваемой операции, запрашиваемого, объекта и запрашивающего пользователя.) Такая проверка выполняется подсистемой безопасности СУБД, которая также называется подсистемой полномочий.
В-третьих. Для того чтобы разобраться, какие правила безопасности к каким запросам доступа применяются, в системе должны быть предусмотрены способы опознания источника этого запроса, т.е. опознания запрашивающего пользователя. Поэтому в момент входа в систему от пользователя обычно требуется ввести не только его идентификатор (например, имя или должность), но также и пароль (чтобы подтвердить свои права на заявленные ранее идентификационные данные). Обычно предполагается, что пароль известен только системе и некоторым лицам с особыми правами.
В отношении последнего пункта стоит заметить, что разные пользователи могут обладать одним и тем же идентификатором некоторой группы. Таким образом, в системе могут поддерживаться группы пользователей и обеспечиваться одинаковые права доступа для пользователей одной группы, например для всех лиц из расчетного отдела. Кроме того, операции добавления отдельных пользователей в группу или их удаления из нее могут выполняться независимо от операции задания привилегий для этой группы. Обратите внимание, однако, что местом хранения информации о принадлежности к группе также является системный каталог (или, возможно, база данных).
Перечисленные выше методы управления доступом на самом деле являются частью более общей классификации уровней безопасности. Прежде всего в этих документах определяется четыре класса безопасности (security classes) – D, С, В и А. Среди них класс D наименее безопасный, класс С – более безопасный, чем класс D, и т.д. Класс D обеспечивает минимальную защиту, класс С – избирательную, класс В – обязательную, а класс А – проверенную защиту.
Избирательная защита. Класс С делится на два подкласса – С1 и С2 (где подкласс С1 менее безопасен, чем подкласс С2), которые поддерживают избирательное управление доступом в том смысле, что управление доступом осуществляется по усмотрению владельца данных.
Согласно требованиям класса С1 необходимо разделение данных и пользователя, т.е. наряду с поддержкой концепции взаимного доступа к данным здесь возможно также организовать раздельное использование данных пользователями.
Согласно требованиям класса С2 необходимо дополнительно организовать учет на основе процедур входа в систему, аудита и изоляции ресурсов.
Обязательная защита. Класс В содержит требования к методам обязательного управления доступом и делится на три подкласса – В1, В2 и В3 (где В1 является наименее, а В3 – наиболее безопасным подклассом).
Согласно требованиям класса В1 необходимо обеспечить "отмеченную защиту" (это значит, что каждый объект данных должен содержать отметку о его уровне классификации, например: секретно, для служебного пользования и т.д.), а также неформальное сообщение о действующей стратегии безопасности.
Согласно требованиям класса В2 необходимо дополнительно обеспечить формальное утверждение о действующей стратегии безопасности, а также обнаружить и исключить плохо защищенные каналы передачи информации.
Согласно требованиям класса В3 необходимо дополнительно обеспечить поддержку аудита и восстановления данных, а также назначение администратора режима безопасности.
Проверенная защита. Класс А является наиболее безопасным и согласно его требованиям необходимо математическое доказательство того, что данный метод обеспечения безопасности совместимый и адекватен заданной стратегии безопасности.
Хотя некоторые коммерческие СУБД обеспечивают обязательную защиту на уровне класса В1, обычно они обеспечивают избирательное управление на уровне класса С2.
5.2. Избирательное управление доступом
Избирательное управление доступом поддерживается многими СУБД. Избирательное управление доступом поддерживается в языке SQL.
В общем случае система безопасности таких СУБД базируется на трех компонентах:
1. Пользователи. СУБД выполняет любое действия с БД от имени какого-то пользователя. Каждому пользователю присваивается идентификатор – короткое имя, однозначно определяющее пользователя в СУБД. Для подтверждения того, что пользователь может работать с введенным идентификатором используется пароль. Таким образом, с помощью идентификатора и пароля производится идентификация и аутентификация пользователя. Большинство коммерческих СУБД позволяет объединять пользователей с одинаковыми привилегиями в группы – это позволяет упростить процесс администрирования.
2. Объекты БД. По стандарту SQL2 защищаемыми объектами в БД являются таблицы, представления, домены и определенные пользователем наборы символов. Большинство коммерческих СУБД расширяет список объектов, добавляя в него хранимые процедуры и др. объекты.
3. Привилегии. Привилегии показывают набор действий, которые возможно производить над тем или иным объектом. Например пользователь имеет привилегию для просмотра таблицы.
5.3. Обязательное управление доступом
Методы обязательного управления доступом применяются к базам данных, в которых данные имеют достаточно статичную или жесткую структуру, свойственную, например, правительственным или военным организациям. Как уже отмечалось, основная идея заключается в том, что каждый объект данных имеет некоторый уровень классификации, например: секретно, совершенно секретно, для служебного пользования и т.д., а каждый пользователь имеет уровень допуска с такими же градациями, что и в уровне классификации. Предполагается, что эти уровни образуют строгий иерархический порядок, например: совершенно секретно ® секретно ® для служебного пользования и т.д. Тогда на основе этих сведений можно сформулировать два очень простых правила безопасности:
1. пользователь имеет доступ к объекту, только если его уровень допуска больше или равен уровню классификации объекта.
2. пользователь может модифицировать объекту, только если его уровень допуска равен уровню классификации объекта.
Правило 1 достаточно очевидно, а правило 2 требует дополнительных разъяснений. Прежде всего следует отметить, что по-другому второе правило можно сформулировать так: любая информация, записанная некоторым пользователем, автоматически приобретает уровень, равный уровню классификации этого пользователя. Такое правило необходимо, например, для того, чтобы предотвратить запись секретных данных, выполняемую пользователем с уровнем допуска "секретно", в файл с меньшим уровнем классификации, что нарушает всю систему секретности.
В последнее время методы обязательного управления доступом получили широкое распространение. Требования к такому управлению доступом изложены в двух документах, которые неформально называются "оранжевой" книгой (Orange Book) и "розовой" книгой (Lavender Book). В "оранжевой" книге перечислен набор требований к безопасности для некой "надежной вычислительной базы" (Trusted Computing Base), а в "розовой" книге дается интерпретация этих требований для систем управления базами данных.
5.4. Шифрование данных
До сих пор в этой главе подразумевалось, что предполагаемый нелегальный пользователь пытается незаконно проникнуть в базу данных с помощью обычных средств доступа, имеющихся в системе. Теперь следует рассмотреть случай, когда такой пользователь пытается проникнуть в базу данных, минуя систему, т.е. физически перемещая часть базы данных или подключаясь к коммуникационному каналу. Наиболее эффективным методом борьбы с такими угрозами является шифрование данных, т.е. хранение и передача особо важных данных в зашифрованном виде.
Для обсуждения основных концепций кодирования данных следует ввести некоторые новые понятия. Исходные (незакодированные) данные называются открытым текстом. Открытый текст шифруется с помощью специального алгоритма шифрования. В качестве входных данных для такого алгоритма выступают открытый текст и ключ шифрования, а в качестве выходных – зашифрованная форма открытого текста, которая называется зашифрованным текстом. Если детали алгоритма шифрования могут быть опубликованы или, по крайней мере, могут не утаиваться, то ключ шифрования обязательно хранится в секрете. Именно зашифрованный текст, который непонятен тем, кто не обладает ключом шифрования, хранится в базе данных и передается по коммуникационному каналу.
5.5. Контрольный след выполняемых операций
Важно понимать, что не бывает неуязвимых систем безопасности, поскольку настойчивый потенциальный нарушитель всегда сможет найти способ преодоления всех систем контроля, особенно если за это будет предложено достаточно высокое вознаграждение. Поэтому при работе с очень важными данными или при выполнении критических операций возникает необходимость регистрации контрольного следа выполняемых операций. Если, например, противоречивость данных приводит к подозрению, что совершено несанкционированное вмешательство в базу данных, то контрольный след должен быть использован для прояснения ситуации и подтверждения того, что все процессы находятся под контролем. Если это не так, то контрольный след поможет, по крайней мере, обнаружить нарушителя.
Для сохранения контрольного следа обычно используется особый файл, в котором система автоматически записывает все выполненные пользователями операции при работе с обычной базой данных. Типичная запись в файле контрольного следа может содержать такую информацию:
2. терминал, с которого была вызвана операция;
3. пользователь, задавший операцию;
4. дата и время запуска операции;
5. вовлеченные в процесс исполнения операции базовые отношения, кортежи и атрибуты;
6. старые значения;
7. новые значения.
Как уже упоминалось ранее, даже констатация факта, что в данной системе поддерживается контрольное слежение, в некоторых случаях весьма существенна для предотвращения несанкционированного проникновения в систему.
5.6. Поддержка мер обеспечения безопасности в языке SQL
В действующем стандарте языка SQL предусматривается поддержка только избирательного управления доступом. Она основана на двух более или менее независимых частях SQL. Одна из них называется механизмом представлений, который (как говорилось выше) может быть использован для скрытия очень важных данных от несанкционированных пользователей. Другая называется подсистемой полномочий и наделяет одних пользователей правом избирательно и динамично задавать различные полномочия другим пользователям, а также отбирать такие полномочия в случае необходимости.
5.7. Директивы GRANT и REVOKE
Механизм представлений языка SQL позволяет различными способами разделить базу данных на части таким образом, чтобы некоторая информация была скрыта от пользователей, которые не имеют прав для доступа к ней. Однако этот режим задается не с помощью параметров операций, на основе которых санкционированные пользователи выполняют те или иные действия с заданной частью данных. Эта функция (как было показано выше) выполняется с помощью директивы GRANT.
Обратите внимание, что создателю любого объекта автоматически предоставляются все привилегии в отношении этого объекта.
Стандарт SQL1 определяет следующие привилегии для таблиц:
1. SELECT – позволяет считывать данные из таблицы или представления;
INSERT – позволяет вставлять новые записи в таблицу или представление;
UPDATE – позволяет модифицировать записи из таблицы или представления;
DELETE – позволяет удалять записи из таблицы или представления.
Стандарт SQL2 расширил список привилегий для таблиц и представлений:
1. INSERT для отдельных столбцов, подобно привилегии UPDATE;
2. REFERENCES – для поддержки внешнего ключа.
Помимо перечисленных выше добавлена привилегия USAGE – для других объектов базы данных.
Кроме того, большинство коммерческих СУБД поддерживает дополнительные привилегии, например:
1. ALTER – позволяет модифицировать структуру таблиц (DB2, Oracle);
2. EXECUTE – позволяет выполнять хранимые процедуры.
Создатель объекта также получает право предоставить привилегии доступа какому-нибудь другому пользователю с помощью оператора GRANT. Ниже приводится синтаксис утверждения GRANT:
GRANT {SELECT|INSERT|DELETE|(UPDATE столбец, …)}, …
ON таблица ТО {пользователь | PUBLIC}
Привилегии вставки (INSERT) и обновления (UPDATE) (но не привилегии выбора SELECT, что весьма странно) могут задаваться для специально заданных столбцов.
Если задана директива WITH GRANT OPTION, это значит, что указанные пользователи наделены особыми полномочиями для заданного объекта – правом предоставления полномочий. Это, в свою очередь, означает, что для работы с данным объектом они могут наделять полномочиями других пользователей
Например: предоставить пользователю Ivanov полномочия для осуществления выборки и модификации фамилий в таблице Students с правом предоставления полномочий.
GRANT SELECT, UPDATE StName
ON Students ТО Ivanov WITH GRANT OPTION
Если пользователь А наделяет некоторыми полномочиями другого пользователя В, то впоследствии он может отменить эти полномочия для пользователя В. Отмена полномочий выполняется с помощью директивы REVOKE с приведенным ниже синтаксисом.
REVOKE {{SELECT | INSERT | DELETE | UPDATE},…|ALL PRIVILEGES}
ON таблица,… FROM {пользователь | PUBLIC},… {CASCADE | RESTRICT}
Поскольку пользователь, с которого снимается привилегия, мог предоставить ее другому пользователю (если обладал правом предоставления полномочий), возможно возникновение ситуации покинутых привилегий. Основное предназначение параметров RESTRICT и CASCADE заключается в предотвращении ситуаций с возникновением покинутых привилегий. Благодаря заданию параметра RESTRICT не разрешается выполнять операцию отмены привилегии, если она приводит к появлению покинутой привилегии. Параметр CASCADE указывает на последовательную отмену всех привилегий, производных от данной.
Например: снять с пользователя Ivanov полномочия для осуществления модификации фамилий в таблице Students. Также снять эту привилегию со всех пользователей, которым она была предоставлена Ивановым.
ON Students FROM Ivanov CASCADE
При удалении домена, таблицы, столбца или представления автоматически будут удалены также и все привилегии в отношении этих объектов со стороны всех пользователей.
5.8. Представления и безопасность
Создавая представления, и давая пользователям разрешение на доступ к нему, а не к исходной таблице, можно тем самым ограничить доступ пользователя, разрешив его только к заданным столбцам или записям. Таким образом, представления позволяют осуществить полный контроль над тем, какие данные доступны тому или иному пользователю.
Заключение
Для минимизации риска потерь необходима реализация комплекса нормативных, организационных и технических защитных мер, в первую очередь: введение ролевого управления доступом, организация доступа пользователей по предъявлению цифрового сертификата, а в ближайшей перспективе – промышленное решение по выборочному шифрованию и применение алгоритмов ГОСТ для шифрования выбранных сегментов базы.
Для полного решения проблемы защиты данных администратор безопасности должен иметь возможность проводить мониторинг действий пользователей, в том числе с правами администратора. Поскольку штатная система аудита не имеет достаточных средств защиты, необходима независимая система, защищающая корпоративную сеть не только снаружи, но и изнутри. В будущем должны также появиться типовые методики комплексного решения задачи защиты баз данных для предприятий разного масштаба – от мелких до территориально распределенных.
Под безопасностью подразумевается, что некоторому пользователю разрешается выполнять некоторые действия.
СУБД должны соблюдать 3 основных аспекта информационной безопасности:
1. Конфиденциальность
2. Целостность
3. Доступность
В этом посте мы поговорим о конфиденциальности
А) Управление безопасностью
В современных СУБД поддерживается как избирательный, так и обязательный подходы к обеспечению безопасности данных.
В случае избирательного управления, некий пользователь обладает различными правами, или привилегиями, и полномочиями при работе с различными объектами. Поскольку разные пользователи могут обладать различными правами доступа к одному и тому же объекту, такие системы очень гибкие.
В случае обязательного управления, каждому объекту присваивается некий квалификационный уровень, ну а каждому пользователю предоставляются права доступа к тому или иному уровню; и соответственно, если у вас есть права доступа на какой-то уровень — все, что на этот уровень записано, ко всему у вас имеется доступ. Считается, что такие системы жесткие, статичные, но они проще в управлении: легко всем объектам дать какой-либо номер (1,2,3,4…) и пользователю потом присвоить доступ кому до 5-го, кому до 6-го, кому до 7-го уровня и т.д. в порядке повышения приоритета.
В обычных СУБД для идентификации и проверки подлинности пользователя применяется либо соответствующий механизм операционной системы, либо то, что имеется в SQL-операторе connect (там есть специальные параметры для доступа при подключении). В момент начала сеанса работы с сервером базы данных пользователь идентифицирует контакт, или логин, своим именем, а средством аутентификации служит пароль.
Идентификатор – это краткое имя, однозначно определяющее пользователя для СУБД. Является основой систем безопасности. Для пользователей создаются соответствующие учетные записи.
Идентификация позволяет субъекту (т.е. пользователю или процессу, действующему от имени пользователя) назвать себя, т.е. сообщить свое имя (логин).
По средствам аутентификации (т.е. проверки подлинности) вторая сторона (операционная система или собственно СУБД) убеждается, что субъект действительно тот, за кого он себя выдает.
Для особо уязвимых систем (например, банковским и т.п.) используются более сложные системы защиты. Так, например, известны системы с последовательным созданием нескольких вопросов личного характера, с ограничением времени на их ответ и количества попыток (как в любом мобильнике).
В стандарте ANSI ISO вместо термина «идентификатор пользователя» (user ID) используется термин «идентификатор прав доступа» (authorization ID).
Система безопасности на сервере может быть организована 3-мя способами:
1. стандартная безопасность: когда на сервер требуется отдельный доступ (т.е. в операционную систему вы входите с одним паролем, а на сервер базы данных с другим);
2. интегрированная безопасность (достаточно часто используют): входите в операционную систему с каким-то пользовательским паролем, и это же имя с этим же паролем зарегистрировано в СУБД. Второй раз входить не надо. Раз попал человек на сервер, ну да ладно, пусть пользуется всем, что есть.
3. смешанная система, которая позволяет входить и первым, и вторым способом.
Б) Управление доступом
Обычно в СУБД применяется произвольное управление доступом: когда владелец объекта (в крайнем случае, администратор базы данных, но чаще владелец) передает права доступа (permissions) кому-нибудь. При этом права могут передаваться отдельным пользователям, группам пользователей, или ролям.
1. Учетная запись создается для отдельных пользователей с логином и паролем. Как правило, это делает администратор базы данных.
2. Группа – именованная совокупность пользователей, чаще всего в группы объединяют на основе какой-либо организации (по отделам, по комнатам, по бригадам и т.п.). Формально говоря, пользователь может входить в разные группы и входить в систему с разной возможностью (должен указать от имени какой группы он входит).
3. Роль – некий, часто служебный, перечень возможностей. Например, бухгалтер, кладовщик и т.п. Приходит человек на работу, ему присваивают такие права доступа, и он с ними может входить. Такой вариант сейчас довольно хорошо используется, т.к. это достаточно удобно оговорить на предприятии. При желании можно пересмотреть эту роль, и она сразу всех потом поменяет. Как правило, считается, что привилегии роли имеют приоритет перед привилегиями групп.
Более высокие требования по безопасности в настоящее время мы рассматривать не будем. Такие многоуровневые системы безопасности были разработаны еще в 70х годах ХХ века. Известные фамилии: Bella, Lapadula.
B) Основные категории пользователей
В общем случае пользователи СУБД могут быть разбиты на 3 основные большие группы:
1. администратор сервера базы данных (и его помощники): ведают установкой, конфигурированием сервера, регистрацией пользователей, групп, ролей, и т.д. Обладает всеми правами базы данных.
2. администратор отдельной базы данных (сервер может обслуживать тысячи баз данных).
3. прочие конечные пользователи: программисты (создают программы для управления теми или иными процессами: бухгалтерскими, кадровыми…), работники фирм и т.д.
Как правило, для администраторов баз данных сделана первоначальная учетная запись, чтоб сделать первоначальный вход в систему. Например, в InterBase: SISDBA с masterkey. В SQL-server: SA и пустой пароль. В Oracle есть 3 изначальных учетных записи: SIS, SYSTEM и MANAGER.
Г) Виды привилегий
Фактически их две:
. привилегии безопасности: выделяются конкретному пользователю, создаются, как правило, команды типа create user. Но создать пользователя в базе данных – это не значит предоставить ему права на все. Просто он может войти в базу данных, но там ничего не увидеть. После создания ему еще надо дать права.
. привилегии доступа или права доступа (permissions): предоставляют созданному пользователю те или иные привилегии. Здесь используются другие 2 команды: Grant – предоставить право на что-то (чтение, добавление, удаление, изменение записи…), Revolce.
Каким образом реализуются или ограничиваются права доступа:
. есть операционные ограничения – право на выполнение тех или иных операторов. Чаше всего это select, insert, delete и update. Во многих СУБД (в том числе Oracle) порядка 25 разных операционных прав можно предоставлять.
. Ограничения по значениям, реализуемые с помощью механизма представлений (View).
. Ограничения на ресурсы, реализуемые за счет привилегий доступа к базам данных.
. Привилегии системного уровня (для Oracle). Когда пользователю разрешается выполнять до 80 различных операторов.
Совокупность всех привилегий, которыми можно обладать называется PUBLIC. Администратор базы данных по умолчанию имеет PUBLIC-права – права на все объекты и действия.
Д) Контрольные исследования
Поскольку абсолютно неуязвимых систем не бывает, или, по крайней мере, в определенном смысле неуязвимых, то при работе с очень важными данными или при выполнении очень серьезных критических операций используют регистрацию каких-то действий (т.е. при выполнении какого-то действия автоматически записывается lok-файл, обычно это текстовый файл, его легко сделать через триггеры). Таким образом, если в этом файле более подробно все написать, то можно следить, кто когда что делал.
Е) Протоколирование и аудит
Под протоколированием понимается сбор и накопление информации о событиях, происходящих в информационной системе. В том числе с помощью lok-файлов.
Под аудитом понимается анализ накопленной информации, проводимый либо оперативно (почти в реальном времени), либо периодически (раз в сутки, раз в неделю…).
Для чего используется протоколирование и аудит?
Тут есть несколько основных целей:
. Обеспечение подотчетности пользователей и администратора. За счет этого можно определить, кто куда обращался, и не появились ли у кого-нибудь непонятные права, не подглядел ли кто-нибудь пароль и т.д.
. Для того, чтоб иметь возможность реконструировать последовательность событий. Какие-то нежелательные изменения – можно вернуть назад.
. Обнаружение попыток нарушения информационной безопасности (взлома).
. Выявление различных проблем в работе информационной системы (например, кому-то мало дали данных для работы, кому-то много)
Если говорить о СУБД Oracle, как о флагмане базостроения, там ведется 3 контрольных журнала:
. Журнал привилегий (происходит отслеживание использования привилегий)
. Журнал операторов (отслеживает, какие операторы используются часто для объектов, потом можно что-то превращать в процедуры, улучшать быстродействие, важный журнал)
. Журнал объектного уровня (контролирует доступ к объектам)
Базы данных - это тоже файлы, но работа с ними отличается от работы с файлами других типов, создаваемых прочими приложениями. Выше мы говорили, что всю работу по обслуживанию файловой системы берет на себя операционная система.
Для баз данных предъявляются особые требования с точки зрения безопасности, поэтому в них реализован другой подход к сохранению данных.
При работе с обычными приложениями для сохранения данных мы задаем соответствующую команду, указываем имя файла и доверяемся операционной системе. Если мы закроем файл, не сохранив его, то вся работа по созданию или редактированию файла пропадет безвозвратно.
Базы данных - это особые структуры. Информация, которая в них содержится, очень часто имеет общественную ценность. Нередко с одной и той же базой (например, с базой регистрации автомобилей в ГИБДД) работают тысячи людей по всей стране. От информации, которая содержится в некоторых базах, может зависеть благополучие множества людей. Поэтому целостность содержимого базы не может и не должна зависеть ни от конкретных действий некоего пользователя, забывшего сохранить файл перед выключением компьютера, ни от перебоев в электросети.
Проблема безопасности баз данных решается тем, что в СУБД для сохранения информации используется двойной подход. В части операций, как обычно, участвует операционная система компьютера, но некоторые операции сохранения происходят в обход операционной системы.
Операции изменения структуры базы данных, создания новых таблиц или иных объектов происходят при сохранении файла базы данных. Об этих операциях СУБД предупреждает пользователя. Это, так сказать, глобальные операции. Их никогда не проводят с базой данных, находящейся в коммерческой эксплуатации, - только с ее копией. В этом случае любые сбои в работе вычислительных систем не страшны.
С другой стороны, операции по изменению содержания данных, не затрагивающие структуру базы, максимально автоматизированы и выполняются без предупреждения. Если, работая с таблицей данных, мы что-то в ней меняем в составе данных, то изменения сохраняются немедленно и автоматически.
Обычно, решив отказаться от изменений в документе, его просто закрывают без сохранения и вновь открывают предыдущую копию. Этот прием работает почти во всех приложениях, но только не в СУБД. Все изменения, вносимые в таблицы базы, сохраняются на диске без нашего ведома, поэтому попытка закрыть базу «без сохранения» ничего не даст, так как все уже сохранено. Таким образом, редактируя таблицы баз данных, создавая новые записи и удаляя старые, мы как бы работаем с жестким диском напрямую, минуя операционную систему.
По указанным выше причинам нельзя заниматься учебными экспериментами на базах данных, находящихся в эксплуатации. Для этого следует создавать специальные учебные базы или выполнять копии структуры реальных баз (без фактического наполнения данными).
Режимы работы с базами данных
Обычно с базами данных работают две категории исполнителей. Первая категория – проектировщики или разработчики . Их задача состоит в разработке структуры таблиц базы данных и согласовании ее с заказчиком. Кроме таблиц проектировщики разрабатывают и другие объекты базы данных, предназначенные, с одной стороны, для автоматизации работы с базой, а с другой стороны - для ограничения функциональных возможностей работы с базой (если это необходимо из соображений безопасности).
Проектировщики не наполняют базу конкретными данными (заказчик может считать их конфиденциальными и не предоставлять посторонним лицам). Исключение составляет экспериментальное наполнение тестовыми данными на этапе отладки объектов базы.
Вторая категория исполнителей, работающих с базами данных, - пользователи . Они получают исходную базу данных от проектировщиков и занимаются ее наполнением и обслуживанием. В общем случае пользователи не имеют средств доступа к управлению структурой базы - только к данным, да и то не ко всем, а к тем, работа с которыми предусмотрена на конкретном рабочем месте. Соответственно, система управления базами данных имеет два режима работы:проектировочный ипользовательский. Первый режим предназначен для создания или изменения структуры базы и создания ее объектов. Во втором режиме происходит использование ранее подготовленных объектов для наполнения базы или получения данных из нее.
Системы управления базами данных стали основным инструментом, обеспечивающим хранение больших массивов информации. Современные информационные приложения опираются в первую очередь на многопользовательские СУБД. В этой связи пристальное внимание в настоящее время уделяется проблемам обеспечения информационной безопасности, которая определяет степень безопасности организации, учреждения в целом.
Под информационной безопасностью понимают защищенность информации от случайных и преднамеренных воздействий естественного или искусственного характера, чреватых нанесением ущерба владельцам или пользователям информации.
В целях защиты информации в базах данных важнейшими являются следующие аспекты информационной безопасности (европейские критерии):
условия доступа (возможность получить некоторую требуемую информационную услугу);
целостность (непротиворечивость информации, ее защищенность от разрушения и несанкционированного изменения);
конфиденциальность (защита от несанкционированного прочтения).
Проблема обеспечения информационной безопасности - комплексная, поэтому ее решение должно рассматриваться на разных уровнях: законодательном, административном, процедурном и программно-техническом. В настоящее время особенно остро в России стоит проблема разработки законодательной базы, обеспечивающей безопасное использование информационных систем.
К основным программно-техническим мерам, применение которых позволит решить некоторые из вышеперечисленных проблем, относятся:
аутентификация пользователя и установление его идентичности;
управление доступом к базам данных;
поддержание целостности данных;
протоколирован ие и ау дит;
защита коммуникаций между клиентом и сервером;
отражение угроз, специфичных для СУБД.
Проверка подлинности пользователя приложений базы данных чаще всего осуществляется либо через соответствующие механизмы операционной системы, либо через определенный SQL-оператор: пользователь идентифицируется своим именем, а средством аутентификации служит пароль. Подобная система создает значительные сложности для повторных проверок и исключает подобные проверки перед каждой транзакацией.
Управление доступом к базам данных базируется на реализации следующего минимального набора действий:
произвольное управление доступом;
обеспечение безопасности повторного использования объектов;
использование меток безопасности;
принудительное управление доступом.
Произвольное управление доступом - метод ограничения доступа к объектам, основанный на учете личности субъекта или групп, в которую субъект входит. Эта технология обеспечивает владельцу объекта (представления, сервера базы данных, процедуры, таблице) передачу по своему усмотрению привилегий другому лицу. Этим лицом в данной ситуации может выступать субъект-пользователь, группа пользователей.
Главное достоинство произвольного управления доступом - гибкость. Однако такие сопутствующие характеристики, как рассредоточенность управления и сложность централизованного контроля, создают немало проблем для обеспечения безопасности данных.
Следует обратить внимание и на обеспечение безопасности повторного использования баз данных субъектами. Это означает лишение прав для входа в информационную систему всех пользователей, покинувших организацию.
Метка безопасности состоит из двух частей: уровня секретности и списка категорий. Первая составляющая зависит от приложения и в стандартном варианте может выглядеть как спектр значений от совершенно секретно до несекретно. Вторая составляющая позволяет описать предметную область, разделяя информацию по отсекам, что способствует лучшей защищенности. Механизм меток безопасности не отменяет, а дополняет произвольное управление доступом: пользователи по-прежнему могут оперировать с таблицами только в рамках своих привилегий, получать только часть данных. Основная проблема при использовании меток безопасности - поддержание их целостности. Это означает, что все объекты и субъекты должны быть помечены, и при любых операциях с данными метки должны оставаться правильными.
Принудительное управление доступом основано на сопоставлении меток безопасности субъекта и объекта. Для чтения информации объекта необходимо доминирование метки субъекта над меткой объекта. При выполнении операции записи информации в объект необходимо доминирование метки безопасности объекта над меткой субъекта. Этот способ управления доступом называется принудительным, т. к. не зависит от воли субъектов. Он нашел применение в СУБД, отличающихся повышенными мерами безопасности.
Обеспечение целостности данных не менее важная задана, чем управление доступом. С точки зрения пользователей СУБД, основными средствами поддержания целостности данных являются ограничения и правила. Ограничения могут содержаться непосредственно в реляционной модели данных, а могут задаваться в процессе создания таблицы. Табличные ограничения могут относиться к группе столбцов, отдельным атрибутам. Ссылочные ограничения отвечают за поддержание целостности связей между таблицами. Ограничения накладываются владельцем таблицы и влияют на результат последующих операций с данными. Правила позволяют выполнять заданные процедуры при определенных изменениях базы данных. В отличие от ограничений, которые обеспечивают контроль относительно простых условий, правила позволяют проверять и поддерживать соотношения любой сложности между элементами данных в базе. Однако при использовании правил как инструмента информационной безопасности ошибка в сложной системе правил чревата непредсказуемыми последствиями для всей базы данных.
Протоколирован ие и ау дит состоят в следующем:
обнаружение необычных и подозрительных действий пользователей и идентификация лиц, совершивших эти действия;
оценка возможных последствий состоявшегося нарушения;
оказание помощи;
организация пассивной защиты информации от нелегальных действий пользователя.
Проблема защиты коммуникаций между клиентом и сервером в информационных системах не является специфичной для СУБД. Для обеспечения защиты информации выделяется сервис безопасности, в функции которого входит аутентификация, шифрование и авторизация.
Однако главный источник угроз для СУБД лежит в самой природе баз данных. Нередко нужную, но недоступную по статусу информацию, можно получить путем логического вывода. Например, используя операцию добавления, а не выбора (на которую прав нет), можно анализировать коды завершения SQL-операторов. Для борьбы с подобными угрозами используется механизм размножения строк для СУБД, поддерживающий метки безопасности. Агрегирование - метод получения новой информации путем комбинирования данных, добытых легальным путем из различных таблиц базы данных. Бороться с агрегированием можно за счет тщательного проектирования модели данных и максимального ограничения доступа пользователя к информации.