Спецкурс (10 семестр) Специальность «Экономическая кибернетика» 1 из 8 Лекция 4. Выборочный и обязательный подходы к созданию системы безопасности. Стандарти. Классы безопасности. «Розовая» книга. Поддержка безопасности в языке SQL. Реализация системы безопасности в современных СУБД. 4.1. Подходы к реализации системы секретности. Стандарты.............................................1 4.1.1 Избирательное управление доступом .............................................................................1 4.1.2 Обязательное управление доступом ...............................................................................2 4.1.3 Стандарты. Классы безопасности. ..................................................................................2 4.1.4 Шифрование данных ........................................................................................................3 4.2. Директивы SQL для обеспечения секретности...............................................................3 4.3. Реализация системы безопасности в современных СУБД.............................................4 4.3.1 Основные понятия системы безопасности .....................................................................4 4.3.2 Манипулирование элементами системы безопасности СУБД .....................................6 4.1. Подходы к реализации системы секретности. Стандарты. При реализации системы секретности в современных СУБД используется один из двух подходов к обеспечению секретности данных: 1. Избирательный подход, при котором пользователь обладает различными полномочиями при работе с разными объектами. 2. Обязательный подход, при котором каждому объекту присваивается некоторый классификационный уровень, а каждый пользователь обладает некоторым уровнем допуска. Совершенно очевидно, что СУБД лишь реализует принятые на этапе проектирования стратегические решения по обеспечению секретности, разграничению прав доступа. Для этого в СУБД должны присутствовать такие компоненты: 1. Компонент определения полномочий на некотором языке (возможно, на SQL); 2. Компонент регулирования доступа на основании определенных полномочий – подсистема полномочий. В самом простом случае, если пользователь обращается с запросом на использование объекта, не имея на то соответствующих полномочий, запрос отклоняется. В некоторых системах запрос может быть сужен до такого запроса, который будет находиться в рамках действующих полномочий пользователя (например, как в СУБД INGRES). 3. Компонент идентификации пользователя/группы. Современные СУБД позволяют задавать полномочия сразу группе пользователей. Набор полномочий, приписанный группе пользователей, часто называют ролью. При отслеживании транзакций. попыток несанкционированного доступа используется журнал 4.1.1 Избирательное управление доступом При избирательном подходе пользователю назначается набор полномочий в том случае, если эти полномочия отличаются от принятых в конкретной системе баз данных по умолчанию. Т.е. все пользователи обладают некоторым минимальным набором полномочий (возможно, пустым), и только некоторым назначаются дополнительные полномочия. Причем, одному пользователю могут быть назначены разные полномочия при работе с разными объектами. Избирательные схемы весьма гибки, и большинство СУБД придерживаются именно избирательного подхода. Спецкурс (10 семестр) Специальность «Экономическая кибернетика» 2 из 8 4.1.2 Обязательное управление доступом Обязательная схема жестче, по сравнению с избирательными схемами секретности, и применяется к базам данных, структура которых редко меняется. Классическим примером могут служить базы данных военных или правительственных организаций. Так, согласно требованиям Министерства обороны США, все используемые в этом ведомстве системы (в том числе базы данных, и программные системы) должны поддерживать обязательное управление доступом. Основная идея обязательной схемы состоит в том, что каждому объекту данных приписывается некоторый уровень допуска (например, «секретно», «совершенно секретно», и т.д.), а каждому пользователю назначается один уровень допуска, с теми же значениями, что и для объектов данных. Тогда правила безопасности формулируются так: 1. Пользователь имеет доступ к объекту (просмотр), если его уровень допуска больше или равен уровню допуска объекта. 2. Пользователь может модифицировать объект, только если его уровень допуска равен уровню допуска объекта. Это правило предотвращает ситуации, в которых пользователь с высоким уровнем допуска не может записать данные в файлы/таблицы, имеющие более низкий уровень допуска. Требования Минобороны США к обязательному управлению доступом изложены в двух документах, называемых “оранжевой книгой” и “розовой книгой”. В “оранжевой” книге перечислен набор требований к безопасности для “идеальной” вычислительной базы (Trusted Computing Base –TCB).В “розовой” книге эти требования уточняются для баз данных. СУБД, в которых поддерживаются методы обязательной защиты, называют системами с многоуровневой защитой или надежными системами. 4.1.3 Стандарты. Классы безопасности. В “оранжевой” книге определяется четыре класса безопасности (security classes) – D, C, B, A. Класс D обеспечивает минимальную защиту, класс С – избирательную, В – обязательную, а класс А – проверенную защиту. − Избирательная защита: класс С делится на два подкласса – С1 и С2 (более безопасный, чем С1). Согласно требованиям класса С1 необходимо разделение данных и пользователя, т.е. наряду с поддержкой концепции общего доступа к данным здесь возможна организация раздельного использования данных пользователями. Для систем класса С2 необходимо дополнительно организовать учет на основе процедур входа в систему, аудита (отслеживания обращений к ресурсам) и изоляции ресурсов. – Обязательная защита: класс В делится на три подкласса В1, В2 и В3 (В3 наиболее безопасный). Для класса В1 необходимо обеспечить «отмеченную защиту» (т.е. каждый объект должен содержать отметку о его уровне безопасности), а также неформальное сообщение о действующей системе безопасности. Для класса В2 необходимо дополнительно обеспечить формальное утверждение о действующей стратегии безопасности, а также обнаружить и исключить плохо защищенные каналы передачи информации. Для класса В3 необходимо дополнительно обеспечить поддержку аудита и восстановления данных, а также назначение администратора режима безопасности. – Проверенная защита: класс А является наиболее безопасным. Согласно его требованиям, необходимо математическое доказательство того, что данный метод безопасности совместим и адекватен заданной стратегии безопасности. Спецкурс (10 семестр) Специальность «Экономическая кибернетика» 3 из 8 4.1.4 Шифрование данных До сих пор предполагалось, что «нелегальный» пользователь будет пытаться проникнуть в систему баз данных с помощью средств доступа, имеющихся в системе, т.е. подбирая пароли и заменяя учетные записи пользователей. Возможны ситуации, когда пользователь пытается проникнуть в систему, минуя стандартные средства доступа, например, физически перемещая файлы данных или подключаясь к коммуникационным каналам, по которым идет передача данных между узлами распределенной СБД. В последнем случае в качестве метода обеспечения секретности выбирают шифрование данных. Первый стандарт шифрования был введен в 1977 году в США. Он получил название DES – Data Encryption Standard. Этим стандартом предусматривается, что алгоритм расшифровки идентичен алгоритму шифрования за исключением того, что ключи шифрования применяются в обратном порядке. Однако DES может быть взломан методом «грубой силы» перебором значений. Поэтому в последнее время используется шифрование на основе открытого ключа – RSA. 4.2. Директивы SQL для обеспечения секретности В стандарте SQL предусмотрена поддержка только избирательного управления доступом. Она включает в себя механизм представлений (views) и подсистему привилегий. В SQL2 существуют директивы для раздачи и отмены привилегий пользователям. Директива GRANT устанавливает привилегии пользователю. GRANT список_привилегий, разделенный запятыми ON объект TO список пользователей, разделенный запятыми [WITH GRANT OPTION]; Различают такие типы привилегий: USAGE - для использования некоторого домена SELECT – разрешена выборка INSERT – разрешено добавление записей UPDATE – разрешено обновление записей DELETE – разрешено удаление записей EXECUTE- разрешено выполнение хранимых процедур REFERENCES – разрешено обращение в ограничениях целостности к специальным объектам (если обращение происходит к таблице, имеющей ссылки на другие, подчиненные, таблицы, то, имея привилегию REFERENCES, можно обращаться и к подчиненным таблицам). Объект – домен или отношение. Опция WITH GRANT OPTION - присваивает пользователю полномочия предоставления полномочий другим пользователям. Директива REVOKE отменяет полномочия, выданные пользователем А пользователю В. Спецкурс (10 семестр) Специальность «Экономическая кибернетика» 4 из 8 REVOKE [GRANT OPTION FOR] список_привилегий, разделенный запятыми ON объект FROM список пользователей, разделенный запятыми option; Где option – одно из значений {CASCADE, RESTRICT}, CASCADE – отмена всех привилегий, производных от данной привилегии RESTRICT – запрет на отмену привилегии, если от нее есть производные привилегии. 4.3. Реализация системы безопасности в современных СУБД. 4.3.1 Основные понятия системы безопасности Система безопасности СУБД основывается на таких понятиях как учетная запись, роль, группа, пользователь. Каждый пользователь проходит два этапа проверки системы безопасности при попытке доступа к данным: - Этап 1 – аутентификация, - Этап 2 – получение доступа к данным Первый этап относится к уровню работы всего сервера СУБД. На первом этапе пользователь идентифицирует себя с помощью логического имени (login) и пароля (password). Логическое имя и пароль хранятся на сервере СУБД в виде учетной записи (account). Если данные были введены правильно, то считается, что процедура аутентификации пройдена, и данный сервер СУБД разрешает попытку доступа к конкретной базе данных. Однако сама по себе аутентификация не дает пользователю права доступа к каким бы то ни было данным. Для получения доступа к данным необходимо, чтобы учетной записи пользователя соответствовал некоторый пользователь базы данных (database user). Пользователь базы данных – совокупность разрешений и запретов на работу с данными в конкретной базе данных. На втором этапе учетная запись пользователя отображается в пользователя базы данных, и получает все привилегии, соответствующие этому пользователю базы данных. Второй этап задействует систему безопасности конкретной базы данных, а не всего сервера СУБД. В разных базах данных одной и той же учетной записи могут соответствовать одинаковые или разные имена пользователя базы данных с разными правами доступа. В том случае, когда учетная запись пользователя не отображается в пользователя базы данных, клиент все же может получить доступ к базе данных под гостевым именем guest (если оно не запрещено администратором БД). Гостевой вход позволяет минимальный доступ к данным только в режиме чтения. Пользователи баз данных могут объединяться в роли (иногда – группы) для упрощения управления системой безопасности. Роли базы данных объединяют нескольких пользователей в административную единицу и позволяют назначать права доступа к объектам базы данных для роли, наделяя этими правами всех участников этой роли. Спецкурс (10 семестр) Специальность «Экономическая кибернетика» 5 из 8 Различают пользовательские и встроенные роли. Встроенные роли создаются автоматически при установке сервера СУБД (и не могут меняться). Различают встроенные роли уровня СУБД и уровня конкретной базы данных. Так, например, в SQL Server 2000 есть такие роли сервера: Встроенная роль сервера Sysadmin Serveradmin Setupadmin Securityadmin Processadmin Dbcreator Diskadmin Bukladmin Назначение Может выполнять любые действия в SQL Server Выполняет конфигурирование и выключение сервера Управляет связанными серверами и процедурами, автоматически запускающимися при запуске SQL Server Управляет учетными записями и правами на создание базы данных, также может читать журнал ошибок. Управляет процессами, запущенными в SQL Server Может создавать и модифицировать базы данных Управляет файлами SQL Server Может вставлять данные с использованием средств массового копирования, не имея непосредственного доступа в таблицам. SQL Server 2000 поддерживает такие встроенные роли уровня базы данных: Встроенная роль сервера Db_owner Db_accessadmin Db_securityadmin Db_ddladmin Db_backupoperator Db_datareader Db_datawriter Db_denydatareader Db_denydatawriter Назначение Имеет все права в базе данных Может добавлять или удалять пользователей Управляет всеми разрешениями, объектами, ролями и членами ролей Может выполнять любые команды DDL, кроме GRANT, DENY, REVOKE Может выполнять команды DBCC, CHECKPOINT, BACKUP Может просматривать любые данные в любой таблице Может модифицировать любые данные в любой таблице Запрещается просматривать данные в любой таблице Запрещается модифицировать данные в любой таблице Кроме указанных ролей существует еще одна, неудаляемая роль – public. Участниками этой роли являются все пользователи, имеющие доступ к базе данных. Нельзя явно указать участников этой роли, т.к. все пользователи уже включены в нее. Спецкурс (10 семестр) Специальность «Экономическая кибернетика» 6 из 8 4.3.2 Манипулирование элементами системы безопасности СУБД 4.3.2.1 Создание учетной записи Для создания учетной записи в MS SQL Server 2000 используется системная хранимая процедура sp_addlogin: Ее формат таков: sp_addlogin [@loginname=] ‘login’ [, [@passwd=] ‘password’] [, [@defdb=] ‘database’] [, [@deflanguage=] ‘language’] [, [@sid=] ‘SID’] [, [@encryptopt=] ‘encryption_option’] где: login password database - логическое имя (login) - пароль, который будет ассоциироваться с данной учетной записью - база данных по умолчанию. Сразу же после установления соединения с сервером пользователь будет работать в этой базе данных language - язык сообщений, выдаваемых сервером СУБД пользователю SID - двоичное число, которое будет являться идентификатором безопасности создаваемой учетной записи. Используя эту возможность, можно создавать на разных серверах СУБД создавать учетные записи с одинаковыми идентификаторами безопасности encryption_option - определяет, будет ли шифроваться пароль данной учетной записи. По умолчанию пароль шифруется. Пример 1. Добавить учетную запись teacher к базе данных sk4. EXEC sp_addlogin ‘teacher’, ‘123’, ‘sk4’, ‘en’, ,’skip_encryption’ 4.3.2.2 Создание пользователя базы данных Для создания пользователя базы данных в MS SQL Server 2000 используется системная хранимая процедура sp_grantdbaccess (ранее - sp_adduser): Ее формат таков: sp_grantdbaccess [@loginame=] ‘login’ [,[@name_in_db=] ‘user’ [OUTPUT]] Использование параметра OUTPUT заставляет хранимую процедуру поместить значение параметра ‘user’ созданного пользователя в некоторую переменную, для дальнейшей обработки. Формат процедуры sp_adduser таков: sp_adduser [@loginname=] ‘login’ [, [@name_in_db=] ‘user’] [, [@grpname=] ‘role’] где: Спецкурс (10 семестр) Специальность «Экономическая кибернетика» login user role 7 из 8 - логическое имя (login)которое необходимо связать с создаваемым пользователем - имя создаваемого пользователя базы данных, с которым будет ассоциироваться данная учетная запись. В базе данных не должно быть пользователя с таким именем. - роль, в которую данный пользователь будет включен. Пример 2. Добавить нового пользователя teacher_adb к базе данных sk4. EXEC sp_adduser ‘teacher’, ‘teacher_adb’, ‘db_owner’ 4.3.2.3 Создание роли базы данных Для создания роли базы данных в MS SQL Server 2000 используется системная хранимая процедура sp_addrole: Ее формат таков: sp_addrole [@rolename=] ‘role’ [, [@ownername=] ‘owner’] где: role owner - имя создаваемой роли. Должно быть уникальным в пределах БД - имя владельца роли. Владельцем может быть только роль или пользователь из этой базы данных. По умолчанию, владелец - dbo Эта процедура не может быть запущена как часть транзакции, определенной пользователем. Исполнять эту процедуру могут только участники роли сервера sysadmin, либо участники ролей db_securityadmin, db_owner. Пример 3. Добавление роли Managers. EXEC sp_addrole 'Managers' 4.3.2.4 Добавление пользователя в роль Используется процедура sp_addrolemember вида: sp_addrolemember [@rolename=] ‘role’, [@membername=] ‘security_account’] где: role - имя роли в которую добавляется пользователь. security_account – пользователь базы данных, также – роль, что позволяет создавать иерархию ролей Пример 4. Добавление пользователя teacher_abd в роль Managers. EXEC sp_addrolemember ‘Managers’, ‘teacher_abd’ Спецкурс (10 семестр) Специальность «Экономическая кибернетика» 8 из 8 4.3.2.5 Удаление ролей, учетных записей. Перечислим в той очередности, которая разрешается в SQL Server 2000, процедуры удаления пользователей и ролей из базы данных. Процедура sp_droprolemember вычеркивает участника из роли: sp_droprolemember [@rolename = ] ‘role’ , [@membername = ] ‘security_account’ Процедура sp_droprole удаляет роль (в том случае, если предварительно из роли были удалены все участники): sp_droprole [@rolename=] ‘role’ Процедура sp_revokedbaccess (и ее устаревший аналог sp_dropuser) удаляет пользователя базы данных: sp_revokedbaccess [@name_in_db =] ‘name’ Процедура sp_droplogin удаляет учетную запись из реестра сервера СУБД: sp_droplogin [@loginame=] ‘login’ 4.3.2.6 Просмотр информации об учетных записях, ролях, привилегиях. Для просмотра информации о текущих назначениях пользователей, ролей используются хранимые процедуры sp_helpuser, sp_helplogins, sp_helprole, sp_helprolemember. Параметры их вызовов таковы: sp_helpuser [[@name_in_db=] ‘security_account’] sp_helplogins [[@LoginNamePattern=] ‘login’] sp_helprole [[@rolename=] ‘role’] sp_helprolemember [[@rolename=] ‘role’]