Безопасность баз данных


Содержание

Методы защиты и безопасность базы данных

физико-математические науки

  • Дудкина Анастасия Сергеевна , бакалавр, студент
  • Баш­кирс­кий го­су­дарст­вен­ный аг­рар­ный уни­вер­си­тет
  • Похожие материалы

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

    К основным средствам защиты информации относят следующие:

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

    Защита БД производится на двух уровнях:

    • на уровне пароля;
    • на уровне пользователя (защита учетных записей пользователей и идентифицированных объектов).

    Безопасная система авторизации и регистрации является одним из важнейших элементов при создании проекта. Один из возможных способов — это создание системы регистрации с помощью PHP и MySQL.

    РhpMyAdmin — это программа написанная на PHP и предназначенная для управления сервером MySQL через всемирную сеть. phpMyAdmin поддерживает широкий набор операций над MySQL. Наиболее часто используемые операции поддерживаются с помощью пользовательского интерфейса (управление базами данных, таблицами, полями, связями, индексами, пользователями, правами, и т. д.), одновременно вы можете напрямую выполнить любой SQL запрос.

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

    Рисунок 1. Авторизация в системе «phpMyAdmin»

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

    Рисунок 2. Обзор учетных записей

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

    Таблица 1. Криптографические функции СУБД

    Зашифрование данных алгоритмом AES.

    Расшифрование данных алгоритмом AES.

    Зашифрование данных алгоритмом DES.

    Расшифрование данных алгоритмом DES.

    Зашифрование данных функцией crypt().

    Хэширование данных алгоритмом MD5.

    Хэширование данных алгоритмом SHA-1.

    Функции шифрования данных алгоритмом AES используют 128-битный ключ шифрования, т. е. шифрование ключами размером 192 и 256 бит, предусмотренными стандартом AES , в MySQL не реализовано. Ключ шифрования задается явным образом как один из параметров функции. В отличие от них, функции DES_ENCRYPT() и DES_DECRYPT(), которые шифруют алгоритмом TripleDES, помимо явного задания ключа шифрования, допускают простейший вариант управления ключами в виде ключевого файла, содержащего пронумерованные значения ключей. Однако, данные функции по умолчанию выключены, для их использования необходимо включить поддержку протокола SSL в конфигурации СУБД.

    Функция ENCRYPT() может быть использована только в операционных системах семейства Unix, поскольку она шифрует данные с помощью системного вызова crypt(). Что касается используемых функций хэширования, то в документации на MySQL содержится предупреждение о том, что лежащие в их основе алгоритмы взломаны (подробно об этом написано, в частности, в, поэтому использовать их следует с осторожностью. Однако, MySQL пока не предлагает более стойких функций хэширования взамен существующих. Перечисленные выше криптографические функции также весьма просты в использовании. Например, следующий запрос помещает в таблицу table значение “text”, зашифрованное на ключе “password” : INSERT INTO table VALUES ( 1, AES_ENCRYPT( ‘text’, ‘password’ ) ); Отметим, что формат поля, в которое записывается зашифрованное значение, должен соответствовать ограничениям, накладываемым используемым криптоалгоритмом — в данном случае, оно должно быть двоичным (например, типа VARBINARY) и предполагать выравнивание в соответствии со 128-битным размером блока алгоритма AES.

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

    Список литературы

    1. Мельников,В.П.Информационная безопасность и защита информации. / В.П.Мельников,
    2. С.А.Клейменов, А.М.Петраков // 3-е изд., стер. — М.: Академия, 2008. — 336 с.
    3. Панасенко С.П. Комплексная защита информации. // Информационные технологии. -2001 — № 3 — с. 14-16
    4. Рабочая программа дисциплины «Информационная безопасность» : направление подготовки 080500 Бизнес-информатика [Электронный ресурс] : профиль подготовки Информационные системы в бизнесе : квалификация (степень) выпускника Бакалавр / Башкирский ГАУ, [Каф. информатики и информационных технологий ; сост. А. Р. Басыров]. — Уфа : [б. и.], 2013. — 16 с. — Б. ц.
    5. Сайт PHP веб-приложения «phpMyAdmin» [Электронный ресурс]. – Режим доступа: http://www.phpmyadmin.net/home_page/ , свободный

    Электронное периодическое издание зарегистрировано в Федеральной службе по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор), свидетельство о регистрации СМИ — ЭЛ № ФС77-41429 от 23.07.2010 г.

    Соучредители СМИ: Долганов А.А., Майоров Е.В.

    Безопасность баз данных — Database security

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

    риски безопасности к системам баз данных включают в себя, например:

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

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

    Многие слои и виды контроля информационной безопасности являются подходящими для баз данных, в том числе:

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

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

    содержание

    привилегии

    Два типа привилегий имеют важное значение в отношении безопасности баз данных в среде базы данных: системные привилегии и привилегии объекта.

    Системные привилегии

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

    Привилегии объектов

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

    Принципал наименьших привилегий, и разделение обязанностей:

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

    Еще одна точка внутреннего контроля является соблюдение принципа предоставления наименьшее количество привилегий , особенно в производстве. Для того, чтобы позволить разработчикам больше доступа , чтобы получить их работу, это гораздо безопаснее использовать олицетворение для исключений , которые требуют повышенных привилегий (например EXECUTE AS или Sudo сделать это временно). Часто разработчики могут отклонить это как «накладные» время на их пути к славе кодированию. Пожалуйста, обратите внимание, однако, что АБД должны делать все , что считается ответственным , поскольку они являются де — факто стюарды данных организации и должны соблюдать правила и закона.

    Оценка уязвимости для управления рисками и соблюдения

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

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

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

    абстракция

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

    Мониторинг активности базы данных (DAM)

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

    Анализ может быть выполнен, чтобы идентифицировать известные эксплойты или политические нарушения, или исходные условия могут быть захвачены в течение долгого времени, чтобы построить нормальный шаблон, используемый для обнаружения аномальной активности, что может свидетельствовать о вторжении. Эти системы могут обеспечить комплексный журнал аудита базы данных в дополнение к механизмам обнаружения вторжений, а также некоторые системы могут также обеспечивать защиту от завершения сеансов пользователей и / или отфильтровывая пользователей демонстрирует подозрительное поведение. Некоторые системы предназначены для поддержки разделения обязанностей (SOD), который является типичным требованием аудиторов. SOD требует, чтобы администраторы баз данных, которые, как правило, отслеживаемые в рамках ОПМ, не быть в состоянии отключить или изменить функциональность РДА. Это требует DAM аудита должны быть надежно храниться в отдельной системе не под управлением группой администрирования базы данных.

    Native аудит

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

    Процесс и процедуры

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

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

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

    Безопасность систем баз данных

    Тематический план

    Общее

    Безопасность систем баз данных (БСБД)

    Лекции:

    Лабораторные работы:

    * — обязательные лабораторные работы для каждого студента, остальные должны быть у всех разные их можно выбирать .

    3 балла за лабораторную в 2 пары (14 лаб — 42 балла, 20 лаб — 60 балла).

    По плану 1 лабораторная в неделю.

    Если теория не сдана -1 бал.

    За досрочную сдачу +1 балл, позже на 1 неделю -1 балл!

    Отсутствие на каждой паре -1 бал (исключения — досрочно сдавшие лабораторные (с теорией))..

    Каждые 100 баллов полученные в олимпиадах CTF (не школьная)), засчитываются как 1 лабораторная работа по выбору, но не более 50% от всех лабораторных по выбору.

    Рекомендации по безопасности базы данных Oracle

    Распространенное заблуждение администраторов баз данных состоит в том, что защита базы данных Oracle брандмауэром обеспечивает абсолютную неуязвимость для атак. Естественно, при этом предполагается, что угрозы для безопасности всегда являются внешними, в то время как реальные статистические данные свидетельствуют, что большинство нарушений безопасности происходит изнутри. Именно поэтому следует соблюдать “железобетонную” политику аутентификации и оправданные политики доступа к данным.

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

    Автоматическая безопасная конфигурация

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

    • Параметры безопасности, связанные с паролем. База данных будет принудительно прекращать действие пароля и реализовывать другие политики, связанные с паролями, которые активизируют встроенную проверку сложности в используемом по умолчанию профиле пароля, назначаемом пользователям.
    • Аудит. База данных по умолчанию активизирует аудит определенных полномочий. Эти полномочия, вроде полномочий подключения к БД, считаются жизненно важными для безопасности базы данных. По умолчанию база данных хранит записи аудита в таблице AUD$
      и устанавливает параметр инициализации audit_trail в db .

    Применение функции автоматической безопасной конфигурации гарантирует соответствие базы данных характеристикам безопасности, рекомендуемым по результатам эталонных тестов центра Интернет-безопасности (Center for Internet Security — CIS).

    Учетные записи пользователей

    В Oracle рекомендуют блокировать и признавать утратившими силу все определенные по умолчанию учетные записи пользователей за исключением, естественно, учетных записей SYS и SYSTEM , а также других необходимых учетных записей наподобие DBSNMP , SYSMAN и MGMT_VIEW .

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

    Пароли

    Пароли пользователей Oracle не следует жестко кодировать в сценарии оболочки. В противном случае пароли пользователей можно выяснить, выдав простую команду ps -ef | grep во время выполнения процесса.

    Изменяйте пароли всех созданных по умолчанию учетных записях пользователей немедленно после создания базы данных. Пароли пользователей SYS и SYSTEM следует устанавливать во время создания базы данных, хотя это и не обязательно.

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

    Аутентификация операционной системой

    Два параметра инициализации открывают доступ к базе данных Oracle посредством аутентификации на уровне операционной системы. Один из них — хорошо известный параметр OS_AUTHENT_PREFIX , который многие применяют для создания учетной записи OPS$ , предназначенной для использования в сценариях оболочки и других местах. Разумеется, использование учетной записи OPS$ подразумевает зависимость от средств аутентификации и обеспечения безопасности операционной системы.

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

    Аудит базы данных

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

    Аудиту Oracle следует подвергать все неудачные попытки входа в базу данных. Кроме того, аудиту можно подвергать действия любого пользователя, подключившегося в качестве SYSDBA или SYSOPER . Чтобы активизировать аудит всех операций, выполняемых пользователями SYSDBA и SYSOPER , необходимо установить следующий параметр инициализации: AUDIT_SYS_OPERATIONS=TRUE


    На заметку! Установка параметра AUDIT_SYS_OPERATIONS = TRUE ведет к записи всех действий пользователей SYSDBA и SYSOPER в журнал аудита операционной системы, а не в журнал аудита базы данных. В результате журнал аудита не может быть искажен пользователями, обладающими большими полномочиями внутри базы данных.

    Предоставление прав

    Для уменьшения уязвимости базы данных Oracle настоятельно рекомендует избегать предоставления прав пользователям Oracle типа ANY , таких как права на удаление ANY (т.е. любой) таблицы. Этой проблемы можно вообще избежать, отказавшись от выдачи объектных прав непосредственно пользователям. Кроме того, следует избегать предоставлять полномочия WITH ADMIN OPTION . Полномочия WITH ADMIN OPTION означают, что пользователь, которому они выданы, может, в свою очередь, предоставлять полномочия другим пользователям. В результате администратор баз данных может очень быстро потерять контроль над тем, кому и какие полномочия выдавались.

    Непосредственно пользователям следует предоставлять роли, а не полномочия. Это значительно облегчает администрирование базы данных Oracle с большим количеством пользователей, в которой трудно проверить, какие полномочия были выданы непосредственно тому или иному пользователю. PUBLIC — это роль, используемая по умолчанию для каждого пользователя, созданного в базе данных. Удостоверьтесь, что этой роли не назначены никакие лишние роли или полномочия, поскольку каждый пользователь, в том числе такие создаваемые по молчанию пользователи, как DBSNMP и OUTLN , будет автоматически наследовать эти роли и полномочия.

    Следующий запрос показывает, что роль PUBLIC имеет более 12 000 полномочий объектного уровня:

    Из более чем 12 000 объектных полномочий, предоставленных роли PUBLIC , свыше 100 являются полномочиями на выполнение пакетов DBMS , таких как DBMS_JOB , DBMS_METADATA , DBMS_SNAPSHOT , DBMS_DDL , DBMS_SPACE и DBMS_OBFUSCATION_TOOLKIT . Отзовите все важные полномочия выполнения у роли PUBLIC . Выдавайте важные полномочия пользователям посредством продуманного использования ролей.

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

    Среды с несколькими администраторами баз данных

    Если вы — единственный администратор баз данных Oracle в организации, то должны обладать всеми системными полномочиями, чтобы управлять базой данных. Однако, при наличии группы администраторов БД Oracle, которые управляют множеством баз данных, не стоит предоставлять каждому из них один и тот же тип полномочий (такой как SYSDBA ) и один и тот же тип ролей (наподобие DBA). Следует создать собственные специализированные роли, каждая из которых должна содержать конкретный набор полномочий для решения определенных задач управления базой данных. В результате администратор БД, ответственный за оказание разработчикам помощи в создании новых объектов, не сможет выполнять определенные задачи, связанные с восстановлением, и наоборот. Затем эти роли можно назначить администраторам БД, тем самым обеспечив четкое разделение обязанностей.

    Защита словаря данных

    Пользователи, которым предоставлены системные полномочия ANY , могут удалять таблицы словаря данных. Чтобы защитить словарь данных, конфигурационный параметр 07_DICTIONARY_ACCESSIBILITY в файле параметров необходимо установить в FALSE. Это ограничит выдачу полномочий ANY только тем пользователям, которые регистрируются с полномочиями SYSDBA .

    Настройка разрешений

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

    Незамедлительно удаляйте SETUID из всех файлов Oracle. Некоторые файлы SETUID в системах UNIX могут разрешать выполнение сценариев от имени привилегированного пользователя.

    Пакет UTL_FILE позволяет осуществлять запись в файлы операционной системы из программы PL/SQL. При использовании параметра UTL_FILE_DIR никогда не применяйте в качестве его значения символ * , который означает, что пакет мог бы выводить файлы в любой каталог файловой системы ОС. Ограничьте множество таких каталогов некоторыми общеизвестными расположениями, которые полностью отделены от выходных файлов UTL_FILE .

    Удаляйте функциональную возможность EXTPROC в PL/SQL, если она не требуется. Вначале удалите ссылки на EXTPROC и в файле listener.ora на сервере, и в файле tnsnames.ora на клиенте. После этого исполняемые файлы EXTPROC можно удалить из каталога $ORACLE_HOME/bin .

    Как правило, система содержит пару исполняемых файлов — extproc и extproc0. Функция EXTPROC предоставляет взломщикам возможность проникновения в операционную систему без какой-либо аутентификации. Если функциональные возможности EXTPROC все же требуются, ознакомьтесь со статьей Note 175429.1 на сайте MetaLink компании Oracle.

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

    На заметку! Сайт Питера Финнегана (Peter Finnegan), посвященный вопросам безопасности Oracle, предлагает несколько интересных и полезных статей и сценариев, связанных с безопасностью Oracle, в том числе обсуждение способов обнаружения внедрения SQL-кода и множества других вопросов о безопасности Oracle. Всеобъемлющий список Oracle Database Checklist (Контрольный перечень базы данных Oracle), доступный на сайте Финнегана, предназначен для аудита инсталляций Oracle и достаточно полно отражает все аспекты безопасности базы данных Oracle.

    Сеть и служба слушателя

    Сеть и служба слушателя (TNS Listener) — уязвимые места системы безопасности Oracle. Существует множество возможностей неумышленного оставления открытых путей для атаки базы данных. Вначале рассмотрим способы укрепления службы слушателя.

    Защита слушателя

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

    Можно также запретить пользователю применять команду SET для вмешательства в функции слушателя. Для этого потребуется добавить следующую строку в файл конфигурации listener.ora :

    По умолчанию этот параметр установлен в значение false . Следует также избегать удаленного управления службой слушателя, поскольку ее пароль не шифруется при передаче по сети. Пароль слушателя хранится в файле listener.ora , поэтому нужно защитить этот файл.

    Защита сети

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

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

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

    Для исключения адресов необходимо добавить следующую строку:

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

    Запрет аутентификации удаленным клиентом

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

    Приведенная настройка будет стимулировать аутентификацию пользователей сервером, что безопаснее доверия этой задачи операционной системе клиентов.

    Установка параметров инициализации, связанных с безопасностью

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

    • Позволяет указывать действия, которые должна выполнять база данных (разрывать соединение или продолжать прием) при получении поврежденных пакетов от клиентов. При этом предполагается, что эти пакеты отправляются со злым умыслом.
    • Позволяет указывать вид действий, которые должны предприниматься для отслеживания ошибки. Например, можно выполнять трассировку ошибки или отправлять предупреждение об ошибке.
    • Позволяет задавать максимальное количество последовательных неудачных попыток подключения, которые может предпринять пользователей, оставаясь при этом действующим, даже при отключенном профиле пароля пользователя.
    • Активизирует строгую аутентификацию (использующую мандаты Kerberos или сертификаты через протокол защищенных сокетов (Secure Sockets Layer — SSL)).

    Детальный контроль сетевого доступа

    Связанные с сетью пакеты, такие как UTL_TCP , UTL_SMTP , UTL_MAIL , UTL_HTTP и UTL_INADDR , могут создавать бреши в безопасности, поскольку во всех этих пакетах пользователь PUBLIC обладает полномочиями выполнения. Через один из этих пакетов злоумышленник может легко проникнуть в базу данных. Для контроля доступа пользователей к базе данных через внешние сетевые службы можно применять функцию детального контроля сетевого доступа Oracle. Например, можно ограничить доступ пользователей к базам данных из определенных узлов.

    Пакеты DBMS_NETWORK_ACL_ADMIN и DBMS_NETWORK_ACL_UTILITY применяются для создания так называемых списков контроля доступа (access control list — ACL). Список контроля доступа — это список пользователей и выданных им полномочий. Списками ACL можно управлять посредством Oracle XML DB. База данных хранит списки ACL в форме XML-документа в папке /sys/acl в Oracle XML DB.

    Создание списка контроля доступа

    Для создания списка ACL используйте процедуру CREATE_ACL пакета DBMS_NETWORK_ADMIN , как показано в следующем примере:

    Процедура create_acl принимает описанные ниже параметры.

    • Указывает имя XML-файла, который содержит имена пользователей и полномочия, перечисленные в списке ACL.
    • Указывает имя пользователя и должен совпадать с именем пользователя сеанса.
    • Показывает, выдано или запрещено данное полномочие.
    • Указывает сетевые полномочия, которые требуется предоставить или запретить. В качестве значений параметра полномочий можно указывать CONNECT
      либо RESOLVE . Пользователю нужно выдать полномочия CONNECT , если ему необходимо подключаться к базе данных посредством любого сетевого пакета PL/SQL, такого как, например, UTL_MAIL . Полномочия RESOLVE помогают получать имя хоста по заданному IP-адресу и наоборот с помощью пакета UTL_INADDR .

    После создания списка ACL в него можно добавлять пользователей или полномочия, выполняя процедуру ADD_PRIVILEGE :

    Если список ACL, указанный в процедуре add_privilege , не существует, база данных создаст его.

    Назначение списка контроля доступа хосту

    Чтобы связать только что созданный список ACL с сетевым хостом, используйте процедуру ASSIGN_ACL , как показано в следующем примере:

    Списки ACL можно назначать хосту, домену или подсети IP. При этом в случае необходимости можно указывать диапазон портов TCP. При выполнении процедуры ASSIGN_ACL следует иметь в виду перечисленные ниже моменты.

    • Каждому хосту, домену или подсети IP можно присваивать только один список ACL.
    • При замене старого списка ACL новым база данных не удаляет старый список автоматически. Для удаления списка ACL понадобится выполнить процедуру DROP_ACL .
    • Назначение списка контроля доступа можно отменить с помощью процедуры UNASSIGN_ACL .

    Порядок следования хост-компьютеров

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

    • полностью определенные имена хостов с указанными портами;
    • полностью определенные имена хостов;
    • поддомены внутри домена.

    Аналогично, списки ACL, присвоенные отдельным IP-адресам, получают приоритет над ACL, присвоенными подсетям.

    Проверка полномочий и назначений хостов

    Для выяснения того, какие полномочия предоставлены пользователю в списке ACL, применяйте функцию CHECK_PRIVIELGE , как показано в следующем примере:

    Выполнение этой функции приведет к возврату значения 0 , если полномочие было запрещено, и значения 1 — если оно было предоставлено. Если полномочие не было ни предоставлено, ни запрещено, функция возвращает значение NULL .

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

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

    Ежеквартально Oracle выпускает обновления Critical Patch Updates (Критичные обновления и исправления ошибок), о чем клиенты Oracle ставятся в известность посредством MetaLink, страницы OTN Security Alerts (Предупреждения безопасности OTN) и Oracle Security RSS. Если вы уже являетесь подписчиком MetaLink, то автоматически подписались на получение обновлений Critical Patch Updates. Если заплата устраняет серьезную угрозу, Oracle не будет дожидаться квартального выпуска Critical Patch Update, чтобы прислать файлы заплаты. В подобных случаях Oracle через сайт MetaLink опубликует внеплановое предупреждение о безопасности и позволит немедленно загрузить заплату. Эта заплата будет включена также в следующий квартальный выпуск обновлений Critical Patch Update. Однако в большинстве случаев обновления Critical Patch Updates будут основным способом распространения большинства заплат компанией Oracle.

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

    Наряду с ежеквартальным обновлением Critical Patch Updates также представлена новая таблица рисков (Risk Matrix). Таблица Risk Matrix позволяет клиентам оценить область и серьезность каждой уязвимости, устраненной каждым обновлением Critical Patch Update. Матрица Risk Matrix указывает угрозу, существующую для конфиденциальности, целостности и доступности данных, и рассматривает условия, при которых система становится наиболее уязвимой. Это позволяет оценить риск, существующий для конкретных систем, и определить приоритет применения заплат к этим системам.

    Опция Advanced Security Oracle

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

    Ниже перечислены некоторые дополнительные функции безопасности, доступные при использовании опции Advanced Security Oracle.

    • Шифрование сетевого трафика между клиентами, серверами приложений и базами данных.
    • Развитые методы аутентификации пользователей.
    • Централизованное управление пользователями.
    • Поддержка инфраструктуры открытых ключей (Public Key Infrastructure — PKI).

    Безопасность приложения

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

    Предоставление полномочий посредством ролей

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

    Отключение ролей

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

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

    Ограничение использования SQL*Plus

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

    Полезные методики управления пользователями

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

    Изменение профилей

    Следующий код демонстрирует изменение профиля пользователя:

    Вывод информации о пользователе

    Для получения довольно большого объема информации о пользовательском “населении” базы данных можно обратиться к представлению DBA_USERS . Типичный запрос к представлению DBA_USERS выглядит следующим образом:

    Выяснение SQL-запроса, выполняемого пользователем в данный момент

    Запрос, приведенный в листинге ниже и соединяющий таблицы V$SESSION и V$SQLTEXT , можно использовать для получения текста SQL-кода, выполняемого пользователем в конкретный момент времени.

    Регистрация в качестве другого пользователя

    Иногда для выполнения определенных действий необходимо зарегистрироваться в качестве другого администратора БД. Однако даже пользователь DBA Oracle не имеет доступа к паролям пользователей, которые хранятся в зашифрованном виде. Можно было бы применить оператор ALTER USER , чтобы изменить пароль пользователя, но нежелательно создавать неудобства пользователю, изменяя пароль без нужды.

    В подобных случаях можно временно изменить пароль и воспользоваться новым паролем для входа в базу данных в качестве этого пользователя. Прежде чем изменять пароль, извлеките исходный шифрованный пароль, который затем можно будет применить для восстановления пароля пользователя. Шифрованные пароли всех пользователей можно извлечь из представления USER$ , например:

    Теперь измените пароль пользователя tester , чтобы можно было зарегистрироваться под именем этого пользователя:

    По завершении применения учетной записи пользователя tester снова введите оператор ALTER USER , чтобы вернуть пароль этого пользователя к исходному значению. Не забудьте заключить шифрованный пароль в одинарные кавычки.

    Прерывание сеанса пользователя

    Команда ALTER SYSTEM служит для прерывания сеанса любого пользователя. Вначале понадобится запросить представление V$SESSION на предмет значений SID (идентификатор сеанса) и serial# (последовательный номер) пользователя. Затем, имея полученные значения идентификатора сеанса и последовательного номера, можно прервать сеанс данного пользователя. Например:

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

    Прерывание UNIX-процесса пользователя, скорее всего, приведет и к прерыванию сеанса Oracle, но это — не самый изящный способ завершения сеанса. Если требуется прервать сеанс UNIX пользователя, а команда KILL SESSION Oracle не работает или занимает длительное время, можно достаточно быстро прервать сеанс, воспользовавшись командой kill из UNIX. Обратите внимание, что команду kill можно применять как саму по себе, так и с ключом -9 , но в большинстве случаев для прерывания сеанса UNIX пользователей Oracle достаточно простой команды kill :

    Следующий сценарий позволяет извлечь из динамического представления V$SESSION номер процесса (а также SID и порядковый номер):

    В системах Windows концепция процессов не используется, но все процессы пользователей являются потоками одного и того же процесса .exe Oracle. Для прерывания сеанса пользователя Oracle в системе Windows можно применить утилиту ORAKILL , которая завершит конкретный поток в процессе .exe Oracle.

    Предположим, что нужно прервать сеанс пользователя. Как же выяснить поток этого пользователя? В листинге ниже демонстрируется применение простого запроса для идентификации потока любого пользователя в системе Windows.

    Сценарий в листинге выше отображает номера потоков, связанные с каждым пользователем Oracle. Как только номера потоков получены, сеанс пользователя можно прервать, используя приведенную ниже команду (предполагается, что номером потока является 2948):

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

    Безопасность баз данных

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

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

    В целях повышения безопасности работы в Office Access 2007 и согласования с другими программами выпуска 2007 системы MS Office в Access 2007 включены новые улучшенные средства безопасности. Комплексные решения по обеспечению доверия интегрированы с центром доверия Office Trust Center. Наличие доверенных мест облегчает размещение всех БД в папках с повышенными параметрами безопасности. С другой стороны, пользователь может загрузить приложение Access 2007 с отключенным кодом макроса, чтобы способствовать обеспечению безопасности.

    Новые функции, реализованные в Access 2007, позволяют отслеживать записи и просматривать авторов создания, редактирования и удаления записей:

    • • проверка данных — без специальной ИТ-поддержки можно легко переносить данные из файла локальной базы на сервер с помощью Windows SharePoint Services, настроенной специалистами организации, с предварительной установкой параметров безопасности и осуществлением резервного копирования в порядке, принятом в данной организации;
    • • история ревизий — данная функция позволяет отслеживать, узнать, когда, кем информация была изменена, и при необходимости отменить внесенные правки;
    • • установка параметров разрешений — с помощью Windows SharePoint Services можно управлять доступом других пользователей к своим данным и назначать ограниченные права доступа только для чтения или полные права доступа с редактированием;
    • • корзина — доступно восстановление случайно удаленных данных с использованием возможности корзины в Windows SharePoint Services.

    Улучшенные функции безопасности в Office Access 2007 и интеграция со Службой Windows SharePoint Services помогают более эффективно управлять данными и повышают безопасность приложений учета данных. Хранение данных таких приложений в списках этой Службы позволяет проверять журнал изменений, восстанавливать удаленные данные и задавать разрешения на доступ к данным.

    ПРАКТИЧЕСКАЯ РАБОТА № 3. Создание таблиц, форм, запросов, отчетов в режимах СУБД Access 2007


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

    • 1. Выполнить:
      • • построение таблиц БД в разных режимах;
      • • создание запросов и вычисления в них;
      • • создание и редактирование форм в разных режимах;
      • • создание и редактирование отчетов в разных режимах.
    • 2. Ответить на контрольные вопросы.
    • 1. СУБД MS Access 2007 из MS Office 2007 является инструментом для работы с БД, состоящей из набора таблиц, форм, запросов и отчетов, используемых для представления и обработки данных.
    • 2. Запуск программы MS Access осуществляется активизацией ярлыка на панели Microsoft Office или из меню Пуск.
    • 3. После запуска MS Access 2007 на экране отобразится стартовое окно Приступая к работе (рис. 3.1), в котором имеются готовые шаблоны. Можно создать БД и самостоятельно, щелкнув мышью на иконке Новая база данных.

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

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

    Рис. 3.1. Стартовое окно

    Рис. 3.2. Интерфейс создания пустой новой таблицы

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

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

    Рис. 3.3. Окно в режиме создания таблицы

    • 6. Маркер таблицы находится в ее верхнем левом углу. Выделяет всю таблицу левый щелчок на маркере, а правый щелчок откроет контекстное меню. Переместить столбец можно, выделив его (левый щелчок на заголовке) и перетащив заголовок с помощью мыши на новое место. Размеры столбцов и строк меняют с помощью мыши.
    • 7. Работа в режиме Таблица аналогична описанной в разделе 3.2.
    • 8. В режиме Конструктор таблиц работа также аналогична описанной в разделе 3.2.
    • 9. Для удобства ввода информации в таблицы применяются формы. В версии Access 2007 можно воспользоваться заготовками форм — соответствующие кнопки расположены на ленте Создание. Первая заготовка (Форма) используется для создания формы, в которую можно будет вводить информацию только по одной строке соответствующей таблицы за один раз. Имеются другие заготовки. Предпочтительней форма, созданная с помощью заготовки Разделенная форма, позволяющая видеть на экране данные, уже введенные в таблицу, и поля для ввода.
    • 10. Для создания новых и изменения существующих форм можно использовать режим Конструктора. Из этого режима можно переходить в другие режимы, улучшать внешний вид и эффективность работы с формой.

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

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

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

    • 13. Обеспечение целостности БД выполняют аналогично описанному в разделе 3.2.
    • 14. Запросы — средство доступа к данным (см. раздел 3.2). Запросы можно выполнять с помощью Мастера запросов (рис. 3.4) и Конструктора запросов (рис. 3.5).

    Рис. 3.4. Окно Мастера запросов

    Рис. 3.5. Окно Конструктора запросов

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

    Бланк запроса имеет две панели: на верхней — списки полей тех таблиц, на которых основан запрос; на нижней — структура запроса, строки результирующей таблицы: Поле, Имя Таблицы, Сортировка, Вывод на экран, Условие отбора.

    Условие отбора — это ограничение, накладываемое на запрос или фильтр для отбора конкретных записей. Условия отбора создаются с использованием операторов сравнения (=, >, Изменить фильтр. В появившемся окне ввести условия поиска в соответствующих полях. Далее ввести команду Применить фильтр. Расширенный фильтр — простейший бланк запроса для вывода некоторого подмножества записей таблицы. Для его создания в окне таблицы следует ввести команды Фильтр —» Дополнительно —» Расширенный фильтр, в появившемся окне ввести в ячейки строки Условия отбора фильтр, который позволит ограничить записи вывода. Здесь же можно задать условия сортировки. Для получения результата — нажать кнопку Применить.

  • 17. Отчеты используются для распечатки данных БД. Целесообразно воспользоваться командой Мастер отчетов, расположенной на ленте Создать (рис. 3.6).

Мастер отчетов предложит выбрать из списка доступные поля. Используя передвижение стрелками влево и вправо, переносим в правую часть все доступные поля.

На следующем шаге можно выбрать способ сортировки информации в отчете (рис. 3.7).

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

  • 3.3. Создание БД в MS Access 2007
  • 121

Рис. 3.6. Создание отчетов с помощью Мастера отчетов

Рис. 3.7. Окно сортировки

Рис. 3.8. Окно выбора макета отчета

Рис. 3.9. Окно выбора стиля шаг Мастера отчетов предполагает выбор стиля, т. е. внешнего вида будущего отчета (рис. 3.9).

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

Ход и результаты работы:

1. Открыв Стартовое окно БД, создаем базу «Студенты», щелкнув мышью на иконке Новая база данных (рис. 3.10).

Рис. ЗЛО. Создание БД «Студенты»

В поле имени файла вводим имя файла. Нажав кнопку Создать, создадим новую БД. Одновременно она открывается в режиме Таблицы.

2. Первая таблица БД «Адрес_Специализация» создана для учета адресов студентов и их специализации (рис. 3.11), вторая (рис. 3.12) — «Список рассылки».

Для работы с таблицей переименовываем столбцы, для чего щелкаем мышью на наименовании и после включения текстового курсора вводим текст. Программа автоматически определяет тип данных. Сохраняем таблицу, нажав кнопку Сохранить в верхнем левом углу окна или комбинацию клавиш (Ctrl + S).

3. Третья таблица «Успеваемость» создана в режиме Конструктора (рис. 3.13, 3.14).

Рис. 3.11. Таблица «Адрес_Специализация»

Рис. 3.12. Таблица «Список рассылки»

  • 3.3. Создание БД в MS Access 2007
  • 125

Рис. 3.13. Создание полей таблицы «Успеваемость» в режиме Конструктора

Рис. 3.14. Таблица «Успеваемость»

Рис. 3.15. Форма таблицы «Успеваемость»

Рис. 3.16. Форма таблицы «Список рассылки»

Рис. 3.17. Форма таблицы «Адрес_Специализации»

  • 4. Для более удобного ввода данных созданы формы таблиц (рис. 3.15-3.18).
  • 5. С помощью инструмента Схема данных по ключевому полю Код связываем таблицы в БД (рис. 3.19).
  • 6. Запросы.
  • 6.1. Запрос на выборку выполнен с помощью Мастера запросов (простой запрос). В запросе участвуют все три таблицы. Запрос состоит из четырех полей: ФИО студента, Дата рождения, Успеваемость, Телефон. После выбора таблиц установлено условие на вывод значений: успеваемость хорошая (рис. 3.20).
  • 6.2. Запрос с параметром выполнен с помощью Конструктора запросов. В запросе участвуют три таблицы. Запрос состоит из пяти полей: Фамилия, Имя, Отчество, Успеваемость, Специализация. В поле Специализация введено условие отбора: Like [Ведите специализацию]

Рис. 3.18. Разделенная форма таблицы «Список рассылки»

Рис. 3.19. Схема данных БД «Студенты»

  • 3.3. Создание БД в MS Access 2007
  • 129

Рис. 3.20. Запрос (а) и результат (б) запроса на выборку

Рис. 3.21. Бланк запроса с параметром Специализация

Рис. 3.22. Окно для ввода специализации

Рис. 3.23. Результат запроса

  • (рис. 3.21). После запуска запроса открывается окно с просьбой ввести Специализацию. Например, вводим Судовождение (рис. 3.22) и получаем ответ на запрос (рис. 3.23).
  • 6.3. В итоговом запросе участвует одна таблица. Для его создания нажимаем на значок суммы на панели Конструктор запросов. Появляется дополнительная строка под названием Групповая операция. В этой строке в поле Балл устанавливаем функцию Avg (среднее арифметическое) для нахождения среднего балла успеваемости (рис. 3.24). После запуска получаем ответ на запрос.
  • 7. Используя простые и сложные условия отбора создаем фильтры: по выделенному фрагменту, обычный и расширенный.
  • 7.1. Фильтр по выделенному значению. Открываем таблицу «Ад- рес_Специализация», выделяем название улицы Судостроительная и нажимаем указателем мыши на пиктограмме Фильтр по выделенному. Результат представлен на рис. 3.25.

Рис. 3.24. Запрос и результат итогового запроса

  • 133
  • 3.3. Создание БД в MS Access 2007

Рис. 3.25. Фильтр по выделенному

  • 7.2. Фильтр обычный. Открываем таблицу «Список рассылки». Вводим команды Фильтр —» Дополнительно —» Изменить фильтр. В строке Андреев пишем: Андреевский. Вводим команду Применить фильтр. Получаем результат (рис. 3.26).
  • 7.3. Фильтр расширенный. Открываем таблицу «Успеваемость». Вводим команды Фильтр —> Дополнительно —> Расширенный фильтр. Установим поле Успеваемость и поставим условие отбора: неудовлетворительная; в поле Группа установим — 12. Бланк запроса и результат см. на рис. 3.27.
  • 8. Создание отчетов осуществляется с помощью Мастера отчетов (рис. 3.28-3.30).

Рис. 3.26. Обычный фильтр

Рис. 3.27. Бланк запроса и результат расширенного фильтра

Рис. 3.28. Отчет по запросу

Рис. 3.29. Отчет по таблице «Успеваемость»

Рис. 3.30. Отчет по таблице «Адрес_Специализация»

Записки ИТ-многостоночника

Архитектурный и технический консалтинг во внедрении и разработке ПО. Системный бизнес анализ и дизайн

Информационная безопасность баз данных

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

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

Даже последние нормативные документы от российских законотворцев в области ИБ показывают, что коллеги в Министерствах и Федеральных агентствах и службах постепенно отошли от ГБ-шной модели «все зашифровать, поставить гриф, трехметровый забор и расстреливать каждого, кто не назовет пароль» и стали под объектами защиты больше понимать не средства обработки информации, но саму информацию (в виде данных) и технологии ее обработки. Например, в требованиях к защите информации в Государственных информационных системах (утвержденных приказом ФСТЭК России №17) появился такой раздел, как защита потоков информации.

Поскольку данные как правило хранятся при обработке в базах данных, где могут быть объектом нападения злоумышленника с гораздо большей вероятностью, чем, например, в памяти (при кратковременном или относительном долговременном там нахождении — в случае In-Memory технологий), защита данных в базах данных — это первый шаг к обеспечению безопасности любой ИТ-системы. Совершенно удачно некоторое время назад мне на глаза попалась полу-академическая статья на эту тему, выдержки из которой, приправленные моим опытом и мнением, я далее привожу.

Основными задачами обеспечения безопасности информации, хранящейся в базах данных, являются следующие:

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

Частично эти свойства обеспечивается такими традиционно не ИБ-шными средствами «защиты» как например резервной копирование и восстановление после сбоев (о чем я писал, например, здесь, а здесь описывал требования, предъявляемые к этим процессам для автоматизированных банковских систем Банком России). Здесь подробно останавливаться на этом не буду, отмечу только, что традиционно требования к этому, а также соответствующие решения являются «вотчинной» специалистов по инфраструктуре.

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

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

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

Независимо от метода аутентификация и разграничение доступа — это базовые средства защиты данных, обрабатываемых в базе данных, от несанкционированных действий.

Основными угрозами/уязвимостями для данных, обрабатываемых в БД, являются:

  • Завышенные или неиспользуемые привилегии. Как правило, являются следствием лени или нежелания сформировать ролевую матрицу для пользователей в соответствии с широко известным принципом минимального знания. Может привести к тому, что в системе появляются учетные записи, доступ к данным которых неоправданно широкий, при этом защите этих учетных записей не уделяется достаточное внимание. В случае применение второго метода аутентификации и контроля доступа эта угроза будет относится не только к данным, обрабатываемым в базе, но на этом уровне она наиболее опасна.
  • Злоупотребление полномочиями. Является следствием предыдущей угрозы/уязвимости, а также следствием особенности большинства промышленных ИТ-систем — наличия суперпользователя. Данный неконтролируемый пользователь должен быть максимально ограничен, а полномочия его и ему подобных пользователей должны анализироваться и отслеживаться. Например, в большинстве рекомендаций по политикам безопасности для Microsoft говорится, что следует внимательнее относиться к пользователям группы «Продвинутые пользователи», так как это не пользователи с расширенными правами, а скорее администраторы с урезанными.
  • SQL-инъекции. Самая «популярная» угроза для RDBMS. Описывать ее не имеет смысла, гугл в помощь.
  • Вредоносное ПО, которое поможет злоумышленнику получить доступа непосредственно к СУБД. Основная «фишка» данной угрозы заключается в том, что системы, особенно построенные по n-Tier-принципам, как правило, не предусматривают прямого доступа кого-либо извне к СУБД как к СУБД, т.е. не через уровни (Tier), реализующие соответствующие архитектурные слои, лежащие над слоем данных. Даже при построения простейших систем на базе одной только СУБД (например, Oracle DB) рекомендуется использовать простейший слой сервисов и хотя бы презентационной логики (например, Oracle APEX). Однако, соответствующее вредоносное ПО может обеспечить доступ к СУБД как к ПО в составе ПО и КТС системы и, соответственно, неконтролируемый прикладной логикой доступ к данным. Это особенно опасно при реализации аутентификации и разграничения доступа первым методом.
  • Выводимые из эксплуатации носители данных. Есть старая ГБ-шная шутка, что самым лучшим источником информации для шпиона является мусорная корзина. По аналогии, выводимые из эксплуатации носители данных, которые раньше использовались БД, могут содержать защищаемую информацию с незначительными преобразованиями и потерей актуальности.
  • DoS и DDoS-атаки. Про этот тип угроз также можно найти любую информацию в открытом доступа.
  • Недостаток информации аудита («слабые» политики аудита). Регистрация событий безопасности (а в базе данных большинство событий можно отнести к таковым) является головной болью администраторов, так как логи занимают много места, как правило, негативно сказываются на производительности, и вообще «кто там будет что-то копать?». При проектировании системы следует избегать таких мыслей. При этом стоит стараться учитывать наличие привилегированных пользователей, которые могут отключать аудит определенных событий. В идеале система должна быть настроена таким образом, чтобы не позволять неконтролируемо совершать каких-либо действий любому пользователю.

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

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

Информационная безопасность систем управления базами данных

Н.И. Вьюкова, В.А. Галатенко
АО «Инфосистемы Джет», тел. (095) 972 -1182

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

Для СУБД важны все три основных аспекта информационной безопасности — конфиденциальность, целостность и доступность [6]. Общая идея защиты баз данных состоит в следовании рекомендациям, сформулированным для класса безопасности C2 в «Критериях оценки надежных компьютерных систем». В принципе некоторые СУБД, например INGRES, предлагают дополнения, характерные для класса B1, однако практическое применение подобных дополнений имеет смысл, только если все компоненты информационной структуры организации соответствуют категории безопасности B. Достичь этого непросто и с технической, и с финансовой точек зрения. Следует, кроме того, учитывать два обстоятельства. Во-первых, для подавляющего большинства коммерческих организаций класс безопасности C2 достаточен. Во-вторых, более защищенные версии отстают по содержательным возможностям от обычных «собратьев», так что поборники секретности по сути обречены на использование морально устаревших (хотя и тщательно проверенных) продуктов со всеми вытекающими последствиями в плане сопровождения.

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


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

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

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

Предполагается, что читатель знаком с основными понятиями СУБД. Их превосходное изложение можно найти в [1]. Там же подробно рассматриваются средства поддержания целостности данных: транзакции, правила, события. По этой причине мы затронем лишь некоторые аспекты контроля целостности.

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

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

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

Для иллюстрации излагаемых понятий и средств будут использоваться СУБД INGRES, Informix и Oracle.

Идентификация и проверка подлинности пользователей

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

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

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

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

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

Управление доступом в СУБД INGRES


Основные понятия

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

Обычно в СУБД применяется произвольное управление доступом, когда владелец объекта передает права доступа к нему (чаще говорят — привилегии) по своему усмотрению. Привилегии могут передаваться субъектам (отдельным пользователям), группам, ролям или всем пользователям.

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

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

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

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

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

Совокупность всех пользователей именуется как PUBLIC. Придание привилегий PUBLIC — удобный способ задать подразумеваемые права доступа.

Основные категории пользователей СУБД INGRES

Пользователей СУБД INGRES можно разбить на три категории:

  • администратор сервера баз данных . Он ведает установкой, конфигурированием сервера, регистрацией пользователей, групп, ролей и т.п. Администратор сервера имеет имя ingres. Прямо или косвенно он обладает всеми привилегиями, которые имеют или могут иметь другие пользователи;
  • администраторы базы данных . К этой категории относится любой пользователь, создавший базу данных, и, следовательно, являющийся ее владельцем. Он может предоставлять другим пользователям доступ к базе и к содержащимся в ней объектам. Администратор базы отвечает за ее сохранение и восстановление. В принципе в организации может быть много администраторов баз данных. Чтобы пользователь мог создать базу и стать ее администратором, он должен получить (вероятно, от администратора сервера) привилегию creatdb;
  • прочие (конечные) пользователи . Они оперируют данными, хранящимися в базах, в рамках выделенных им привилегий.

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

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

Можно провести аналогию между пользователем ingres и администраторами баз данных, с одной стороны, и суперпользователем операционной системы (root в случае ОС UNIX) и служебными пользователями (в ОС UNIX это могут быть bin, lp, uucp и т.д.), с другой стороны. Введение служебных пользователей позволяет администрировать функциональные подсистемы, не получая привилегий суперпользователя. Точно также информацию, хранящуюся на сервере баз данных, можно разделить на отсеки, так что компрометация администратора одного отсека не означает обязательной компрометации другого.

Виды привилегий в СУБД INGRES

Привилегии в СУБД INGRES можно подразделить на две категории: привилегии безопасности и привилегии доступа. Привилегии безопасности позволяют выполнять административные действия. Привилегии доступа, в соответствии с названием, определяют права доступа субъектов к определенным объектам.

Привилегии безопасности

Привилегии безопасности всегда выделяются конкретному пользователю (а не группе, роли или всем) во время его создания (оператором CREATE USER) или изменения характеристик (оператором ALTER USER). Таких привилегий пять:

  • security — право управлять безопасностью СУБД и отслеживать действия пользователей. Пользователь с этой привилегией может подключаться к любой базе данных, создавать, удалять и изменять характеристики пользователей, групп и ролей, передавать права на доступ к базам данным другим пользователям, управлять записью регистрационной информации, отслеживать запросы других пользователей и, наконец, запускать INGRES-команды от имени других пользователей. Привилегия security необходима администратору сервера баз данных, а также лицу, персонально отвечающему за информационную безопасность. Передача этой привилегии другим пользователям (например, администраторам баз данных) увеличивает число потенциально слабых мест в защите сервера баз данных;
  • createdb — право на создание и удаление баз данных. Этой привилегией, помимо администратора сервера, должны обладать пользователи, которым отводится роль администраторов отдельных баз данных;
  • operator — право на выполнение действий, которые традиционно относят к компетенции оператора. Имеются в виду запуск и остановка сервера, сохранение и восстановление информации. Помимо администраторов сервера и баз данных этой привилегией целесообразно наделить также администратора операционной системы;
  • maintain_locations — право на управление расположением баз данных на дисках. Этой привилегией должны обладать администраторы сервера баз данных и операционной системы;
  • trace — право на изменение состояния флагов отладочной трассировки INGRES. Данная привилегия полезна администратору сервера баз данных и другим знающим пользователям при анализе сложных, непонятных ситуаций.

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

Для пользователя можно определить подразумеваемую группу:

Последующее изменение привилегий безопасности для пользователя bill можно выполнять посредством оператора ALTER USER. Оператор DROP USER позволяет удалить пользователя. Примеры:

Привилегии доступа

Привилегии доступа выделяются пользователям, группам, ролям или всем посредством оператора GRANT и изымаются с помощью оператора REVOKE. Эти привилегии, как правило, присваивает владелец соответствующих объектов (он же — администратор базы данных) или обладатель привилегии security (обычно администратор сервера баз данных).

Прежде чем присваивать привилегии группам и ролям, их (группы и роли) необходимо создать с помощью операторов CREATE GROUP и CREATE ROLE. При создании группы задается список входящих в нее пользователей:

Для изменения состава группы служит оператор ALTER GROUP:

Оператор DROP GROUP позволяет удалять группы, правда, только после того, как опустошен список членов группы:

При создании ролей можно указать ассоциируемый с ними пароль, например:

Оператор ALTER ROLE служит для изменения паролей ролей, а DROP ROLE — для удаления ролей.

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

Привилегии доступа можно подразделить в соответствии с видами объектов, к которым они относятся. В СУБД INGRES таких видов пять:

  • таблицы и представления;
  • процедуры;
  • базы данных;
  • сервер баз данных;
  • события.

Присваивание привилегий доступа производится с помощью оператора GRANT. В самом общем виде оператор GRANT имеет следующий формат:

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

SELECT — право на выборку данных;

INSERT — право на добавление данных;

DELETE — право на удаление данных;

UPDATE — право на обновление данных (можно указать определенные столбцы, разрешенные для обновления);

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

По умолчанию пользователь не имеет никаких прав доступа к таблицам и представлениям — их необходимо передать с помощью операторов GRANT. Приведем несколько примеров:

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

Приведем пример предоставления права выполнения процедуры integ_check всем пользователям:

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

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

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

Параметр оператора GRANT

Предполагаемое максимальное число
операций ввода/вывода на запрос [NO]QUERY_IO_LIMIT [n] NOQUERY_IO_LIMIT
(нет ограничений) Предполагаемое максимальное число
строк, возвращаемых запросом [NO]QUERY_ROW_LIMIT [n] NOQUERY_ROW_LIMIT
(нет ограничений) Ограничение на использование
ресурсов процессора [NO]QUERY_CPU_LIMIT [n] [NO]QUERY_CPU_LIMIT
(нет ограничений) Ограничение на число
запрашиваемых страниц [NO]QUERY_PAGE_LIMIT [n] NOQUERY_PAGE_LIMIT
(нет ограничений) Управление доступом к базе данных [NO]ACCESS ACCESS для общих баз данных;
NOACCESS для личных Управление созданием таблиц [NO]CREATE_TABLE CREATE_TABLE Управление созданием процедур [NO]CREATE_PROCEDURE CREATE_PROCEDURE Управление использованием опции u
(подключение от имени другого
пользователя) [NO]DB_ADMIN DB_ADMIN для администратора
базы данных и администратора
сервера баз данных; NODB_ADMIN
для остальных пользователей

Таблица 1 .
Права доступа к базам данных и их подразумеваемые значения

Привилегии (которые в данном случае точнее было бы назвать ограничениями) QUERY_IO_LIMIT и QUERY_ROW_LIMIT проверяются на основании оценок, выданных оптимизатором запросов INGRES. Если оптимизатор предсказывает, что запрос превысит отведенный лимит числа операций ввода/вывода или возвращаемых строк, он (запрос) отвергается. Наложение подобных количественных ограничений препятствует монополизации сервера одним клиентом и может использоваться как один из инструментов поддержания высокой готовности.

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

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

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

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

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

Механизм событий подробно рассмотрен в [1]. Здесь мы отметим лишь, что по отношению к событиям имеются две привилегии — RAISE и REGISTER. Первая позволяет возбуждать события, вторая — регистрироваться для их получения.

Оператор GRANT может содержать необязательную часть, принципиально важную для защиты СУБД. Имеется в виду конструкция

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

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

Для отмены привилегий, выданных ранее (как разрешительных, так и запретительных), служит оператор REVOKE. Синтаксически он аналогичен GRANT с заменой слова TO на FROM. Например, следующий оператор

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

Получение информации о привилегиях

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

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

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

  • groupid — имя группы;
  • groupmem — имя члена группы;
  • reserve — резервный столбец.

Средствами SQL из этих таблиц можно извлечь необходимую информацию.

Использование представлений для управления доступом

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

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

Предоставим всем право на выборку из этого представления:

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

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

Иерархия прав доступа

Оператор GRANT и другие средства управления доступом СУБД INGRES позволяют реализовать следующие виды ограничения доступа:

  • операционные ограничения (за счет прав доступа SELECT, INSERT, UPDATE, DELETE, применимых ко всем или только некоторым столбцам таблицы);
  • ограничения по значениям (за счет механизма представлений);
  • ограничения на ресурсы (за счет привилегий доступа к базам данных).

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

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

Иерархия авторизации выглядит для СУБД INGRES следующим образом:

  • роль (высший приоритет);
  • пользователь;
  • группа;
  • PUBLIC (низший приоритет).

Для каждого объекта, к которому осуществляется доступ, INGRES пытается отыскать в иерархии привилегию, относящуюся к запрашиваемому виду доступа (SELECT, EXECUTE и т.п.). Например, при попытке доступа к таблице с целью обновления, INGRES проверяет привилегии роли, пользователя, группы и всех пользователей. Если хотя бы на одном уровне иерархии привилегия UPDATE имеется, запрос передается для дальнейшей обработки. В противном случае используется подразумеваемое право доступа, которое предписывает отвергнуть запрос.

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

Если пользователь в момент начала сеанса работы с СУБД INGRES задал и роль, и группу, будет использовано ограничение, накладываемое ролью (1700). Если бы привилегия QUERY_ROW_LIMIT для роли отсутствовала или пользователь не задал роль в начале сеанса работы с INGRES, пользователь смог бы получать результаты не более чем из 1500 строк и т.п. Если бы привилегия QUERY_ROW_LIMIT вообще не была специфицирована ни на одном уровне иерархии, СУБД INGRES воспользовалась бы подразумеваемым значением, которое в данном случае означает отсутствие ограничений на число результирующих строк.

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

Если опция -G отсутствует, применяется подразумеваемая группа пользователя, если таковая имеется. Наконец, если в командной строке sql задана опция -uпользователь, то в число проверяемых входят также привилегии указанного пользователя.

Соотношение прав доступа СУБД и операционной системы

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

Чтобы средствами ОС нельзя было скомпрометировать базу данных и сопутствующую информацию, например журналы транзакций, необходимо установить максимально жесткий режим доступа к соответствующим файлам и томам. Для UNIX-систем целесообразно предоставить право непосредственного доступа только пользователям root, ingres и, быть может, администраторам баз данных. Все прочие субъекты должны осуществлять доступ к базам с помощью программ со взведенным битом переустановки действующего идентификатора пользователя.

Приведем пример приложения на встроенном SQL, контролирующего действующий идентификатор пользователя.

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


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

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

Метки безопасности и принудительный контроль доступа

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

В «Критериях оценки надежных компьютерных систем» применительно к системам уровня безопасности B описан механизм меток безопасности, реализованный в версии INGRES/ Enhanced Security (INGRES с повышенной безопасностью). Применять эту версию на практике имеет смысл только в сочетании с операционной системой и другими программными компонентами того же уровня безопасности. Тем не менее рассмотрение реализации меточной безопасности в СУБД INGRES интересно с познавательной точки зрения, а сам подход, основанный на разделении данных по уровням секретности и категориям доступа, может оказаться полезным при проектировании системы привилегий многочисленных пользователей по отношению к большим массивам данных.

В СУБД INGRES/Enhanced Security к каждой реляционной таблице неявно добавляется столбец, содержащий метки безопасности строк таблицы. Метка безопасности состоит из трех компонентов:

· уровень секретности . Смысл этого компонента зависит от приложения. В частности, возможен традиционный спектр уровней от «совершенно секретно» до «несекретно»;

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

· области . Является дополнительным средством деления информации на отсеки. На практике компонент «область» может действительно иметь географический смысл, обозначая, например, страну, к которой относятся данные.

Каждый пользователь СУБД INGRES/ Enhanced Security характеризуется степенью благонадежности, которая также определяется меткой безопасности, присвоенной данному пользователю. Пользователь может получить доступ к данным, если степень его благонадежности удовлетворяет требованиям соответствующей метки безопасности. Более точно:

· уровень секретности пользователя должен быть не ниже уровня секретности данных;

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

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

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

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

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

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

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

Представляется естественным, что СУБД INGRES/Enhanced Security допускает не только скрытое, но и явное включение меток безопасности в реляционные таблицы. Появился новый тип данных, security label, поддерживающий соответствующие операции сравнения.

INGRES/Enhanced Security — первая СУБД, получившая сертификат, эквивалентный аттестации на класс безопасности B1. Вероятно, метки безопасности постепенно войдут в стандартный репертуар систем управления базами данных.

Поддержание целостности данных в СУБД INGRES

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

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

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

Ограничения

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

Здесь требуется, чтобы имя было непустым (обязательно задавалось), а значение возраста было больше 17. Так называемые ссылочные ограничения, использованные в определении столбца id, будут рассмотрены ниже.

Табличные ограничения относятся к группе столбцов и могут задаваться как при создании таблицы, так и позже, посредством оператора ALTER TABLE. Приведем пример табличного ограничения, заданного в операторе CREATE TABLE:

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

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

Приведем пример ссылочного ограничения:

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

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

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

Если требуется удалить ограничение dept_unique, можно воспользоваться следующим оператором:

Слово cascade означает, что следует удалить также все ограничения, прямо или косвенно зависящие от dept_unique. В данном случае будет изъято ограничение empref. Если вместо cascade указать restrict, то есть сделать попытку удалить только ограничение dept_unique, СУБД зафиксирует ошибку. Тем самым обеспечивается целостность системы ограничений.

Получить информацию об ограничениях, наложенных на таблицы, можно с помощью оператора

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

Правила

Правила позволяют вызывать выполнение заданных действий при определенных изменениях базы данных. Обычно действие — это вызов процедуры. Правила ассоциируются с таблицами и срабатывают при изменении этих таблиц.

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

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

Обратим внимание на несколько обстоятельств. Во-первых, процедура delete_children, выполняемая в результате срабатывания правила cascade_delete, вызывает рекурсивное обращение к этому правилу и, следовательно, к самой себе. Во-вторых, таблица person также является в некотором смысле рекурсивной, поскольку столбец parent представляет собой ссылку на столбец name. Целостность по этой ссылке и поддерживается правилом cascade_delete. В третьих, поскольку правило срабатывает в момент изменения таблицы, ему должны быть доступны оба состояния — старое (до изменения) и новое. Обычно они обозначаются именами OLD и NEW.

Рассмотрим еще один пример, показывающий, как средствами SQL можно контролировать уровень доступа к данным. Здесь предполагается, что в столбце sec_label хранятся текстовые обозначения уровня секретности строк. Строки, помеченные как «top secret», может удалять и изменять только пользователь с именем topgun.

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

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

Оператор SET RULES позволит затем восстановить работу механизма правил. По умолчанию этот механизм включен.

Для удаления правил служит оператор

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

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

Регистрация действий пользователей в СУБД Informix

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

Более точно, журнал регистрационной информации может использоваться для следующих целей:

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

Регистрируемые события

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

Мнемоника

ACTB
ALTB
CLDB
CRAM
CRDB
CRIX
CRSP
CRTB
CRTR
CRVW
DLRW
DNDM
DPAM
DRDB
DRIX
DRLG
DRSP
DRTB
DRTR
DRVW
EXSP
GRDB
GRTB
INRW
LGDB
OPDB
RDRW
RNTC
RVDB
RVTB
STCN
STSN
UPAM
UPDM
UPRW
Доступ к таблице
Изменение таблицы
Закрытие базы данных
Создание маски регистраруемых событий
Создание базы данных
Создание индекса
Создание хранимой процедуры
Создание таблицы
Создание триггера
Создание представления
Удаление строки
Выключение режима зеркалирования дисков
Удаление маски регистраруемых событий
Удаление базы данных
Удаление индекса
Удаление журнала транзакций
Удаление хранимой процедуры
Удаление таблицы
Удаление триггера
Удаление представления
Выполнение хранимой процедуры
Передача привелегий доступа к базе данных
Передача привелегий доступа к таблице
Вставка строки
Изменение режима ведения журнала базы данных
Открытие базы данных
Чтение строки
Переименование таблицы/столбца
Лишение привелегий доступа к базе данных
Лишение привелегий доступа к таблице
Установка ограничения
Начало нового сеанса работы
Изменение маски регистрируемых событий
Включение режима зеркалирования дисков
Изменение строки

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

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

Рекомендуется регистрировать по крайней мере следующие события:

  • передача привилегий доступа к базе данных (GRDB);
  • лишение привилегий доступа к базе данных (RVDB);
  • передача привилегий доступа к таблице (GRTB);
  • лишение привилегий доступа к таблице (RVTB);
  • открытие базы данных (OPDB).

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

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

Управление набором регистрируемых событий

Для управления набором регистрируемых событий в СУБД Informix используются маски событий. Три стандартные маски с именами _default, _require и _exclude формируют стандартное регистрационное окружение. Кроме того, для отдельных пользователей могут быть заданы персональные маски с именами, совпадающими с входными именами этих пользователей.

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

  1. Берется маска _default или маска пользователя, если таковая имеется.
  2. В число регистрируемых дополнительно включаются события, заданные маской _require.
  3. Из числа регистрируемых исключаются события, заданные маской _exclude, при условии, что они не были упомянуты в маске _require.

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

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

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

Анализ регистрационной информации

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

  • ONLN — фиксированное поле, обозначающее события, фиксируемые сервером Informix-OnLine;
  • дата и время события;
  • имя клиентского компьютера, инициировавшего событие;
  • идентификатор клиентского процесса, инициировавшего событие;
  • имя серверного компьютера;
  • имя пользователя;
  • код завершения действия, вызвавшего событие;
  • мнемоника события;
  • дополнительные поля, идентифицирующие базы данных, таблицы и другие объекты, вовлеченные в событие.

С помощью утилиты onshowaudit можно отобрать часть регистрационной информации и организовать ее просмотр или, воспользовавшись утилитой dbload, загрузить ее в базу данных и анализировать затем SQL-средствами. Регистрационная служба СУБД Informix является субъектно-ориентированной в том смысле, что можно задать свой набор отслеживаемых событий для каждого пользователя (субъекта), однако нет возможности указать имена объектов (таблиц, процедур и т.п.), операции с которыми отслеживались бы особым образом. Вместо этого предлагается полагаться на средства анализа регистрационной информации. Очевидно, после загрузки регистрационного журнала в базу данных можно отобрать сведения по сколь угодно сложному критерию и сгенерировать отчет, по существу, произвольного вида.

Регистрационные файлы и результат их загрузки в базу данных нуждаются в защите. В частности, для файлов рекомендуется установить в качестве владельца пользователя root, владеющей группой сделать informix, а режим доступа положить равным 0660 (доступ на чтение и запись только для владельца и группы).

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

Средства поддержания высокой готовности

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

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

Сохранение и восстановление баз данных

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

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

Основные понятия

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

Под архивированием баз данных понимается процесс их сохранения на ленточных или дисковых томах. Архив отражает состояние базы данных, соответствующее определенному моменту времени (времени начала архивирования).

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

В качестве собирательного названия для архивирования и резервного копирования будет использоваться термин «сохранение».

Сохранение выполняется на один или несколько логических томов. Логический том — это или ленточный том, или каталог на диске.

Тома объединяются в наборы. Каждый том должен входить в набор. В операциях сохранения задается именно набор томов, куда направляется копия. Оператор (если он отслеживает процесс сохранения) может в ответ на запросы выбирать конкретные тома по своему усмотрению.

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

При физическом восстановлении используется только архивная информация.

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

Обзор возможностей системы ON-Archive

Система ON-Archive предоставляет следующие основные возможности:

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

Система ON-Archive может работать в трех режимах:

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

Основные компоненты системы ON-Archive

Система ON-Archive включает в себя ряд специализированных утилит, а также таблицы, хранящиеся в базе данных sysmaster.

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

Команда


ARCHIVE
BACKUP
COPY
DEFINE
EXECUTE
LIST
MODIFY
RETRIEVE
Генерация запроса на создание архива
Генерация запроса на резервное копирование журналов транзакций
Копирование данных с одного набора томов на другой
Определение наборов (томов, баз данных) и их компонентов
Выполнение запросов, сгенерированных ранее
Получение информации из таблиц ON-Archive
Внесение изменений в таблицы ON-Archive
Генерация запроса на восстановление данных


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

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

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

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

Утилита ondatartr позволяет пользователям root и informix восстанавливать не только базы данных, но и саму конфигурацию системы ON-Archive после особенно тяжелых повреждений. Тем самым ondatartr поддерживает работу в аварийном режиме. Общение с утилитой ondatartr происходит на командном языке, аналогичном языку onarchive.

Программа oncatalgr является демоном, обслуживающим подключение к базе данных sysmaster, хранящей, в частности, таблицы системы ON-Archive. Запуск этой программы должен предшествовать всем прочим действиям в рамках системы ON-Archive.

Таблицы системы ON-Archive хранят:

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

Управление доступом к сохраненной информации

В конфигурационном файле системы ON-Archive задаются уровни привилегий, на которых она функционирует. Таких уровней три:

  • OPERATOR — на данном уровне операции сохранения и восстановления могут выполнять только пользователи root и informix;
  • GROUP — здесь право пользования системой ON-Archive получают все члены группы super_archive. Правда, они подвергаются контролю прав доступа.
  • OWNER — дает право на сохранение и восстановление всем пользователям, однако они подвергаются проверке прав доступа и могут контролировать только собственные запросы.

Конфигурация может включать в себя любую комбинацию этих трех уровней.

При определении наборов томов задается класс доступа к ним. Если набор объявлен как системный (SYSTEM), к томам, входящим в него, может обращаться любой пользователь. С личными (USER) наборами могут оперировать только те, кто перечислен в списке управления доступом, следующим за спецификатором USER. Если нужно, чтобы к личному набору имели доступ члены группы super_archive, их нужно включить в этот список. Пользователи root и informix могут оперировать со всеми наборами.

С томом или набором томов можно ассоциировать права доступа — на чтение, запись и удаление (последнее право позволяет удалить определение тома или набора из таблиц системы ON-Archive). Чтобы права принимались во внимание, набор должен быть системным или же пользователь должен входить в список управления доступом.

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

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

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

Кластерная организация сервера баз данных

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

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

В настоящем разделе будет рассмотрена разработка компании Sun Microsystems — SPARCcluster PDB Server (параллельный сервер баз данных на основе SPARC-кластера). Эту архитектуру на начало 1995 года поддерживал лишь сервер компании Oracle, однако ожидается, что компании Sybase и Informix также воспользуются преимуществами кластерной организации.

Аппаратная организация SPARCcluster PDB Server

В минимальной конфигурации SPARCcluster PDB Server состоит из двух узлов SPARCserver 1000, двух дисковых подсистем SPARCstorage Array и консоли кластера (SPARCclassic). Узлы-компьютеры соединяются между собой посредством быстрого Ethernet (100 Мбит/с), дисковые подсистемы подключаются через оптоволоконные каналы. В более мощной конфигурации вместо SPARCserver 1000 может использоваться SPARCcenter 2000, а число дисковых подсистем способно достигать 32 (до 1 Тбайта дискового пространства). Каждый узел кластера — это многопроцессорный компьютер, к которому, помимо прочих, подключены накопители на DAT-лентах (или автозагрузчики кассет с такими лентами). Все связи с компьютерами и дисковыми подсистемами продублированы.

Следующий рисунок поясняет аппаратную организацию SPARCcluster PDB Server.

Рисунок 1.
Аппаратная организация SPARCcluster PDB Server (на рисунке не показаны связи кластера с внешнем миром.)

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

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

Программная организация SPARCcluster PDB Server

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

Рисунок 2.
Программная организация SPARCcluster PDB Server (узлы кластера работают под управлением ОС Solaris версии 2.4 или выше)

Рассмотрим компоненты программного обеспечения SPARCcluster PDB Server.

Устойчивый к отказам распределенный менеджер блокировок (Fault Tolerant Distributed Lock Manager, FT-DLM) управляет параллельным доступом к базам данных, устанавливая и снимая блокировки. Кроме того, FT-DLM нейтрализует последствия отказов, снимая блокировки, установленные вышедшим из строя узлом. FT-DLM взаимодействует с сервером Oracle для поддержки неблокируемых операций чтения и для блокировки на уровне строк при записи в таблицы. В результате обеспечивается целостность и сериализация транзакций в сочетании с параллельной работой узлов кластера и параллельным доступом к нескольким дисковым подсистемам.

Распределенность менеджера блокировок означает, что на каждом узле кластера работает свой экземпляр FT-DLM и что FT-DLM умеет динамически реконфигурировать себя (как при выходе узлов из строя, так и при добавлении новых узлов). В результате выход из строя одного узла не означает краха всего сервера баз данных — сервер жив, пока работает хотя бы один менеджер блокировок.

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

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

Подсистема управления кластером состоит из трех инструментов с графическим интерфейсом: консоли кластера, менеджера томов и менеджера сервера Oracle. Их интеграция обеспечивает централизованное оперативное управление всеми ресурсами кластера.

Нейтрализация отказа узла

Рассмотрим, как в SPARCcluster PDB Server реализована нейтрализация самого неприятного из отказов — отказа узла. Программное обеспечение предпринимает при этом следующие действия:

  1. Подсистема обнаружения отказов выявляет вышедший из строя узел.
  2. Создается новая конфигурация кластера, без отказавшего узла. Этот процесс занимает 1-2 минуты, в течение которых обработка транзакций приостанавливается.
  3. Менеджер блокировок производит восстановление:
    • a) Подтвержденные транзакции от отказавшего узла (транзакции, об успешном завершении которых другие узлы кластера не успели узнать) накатываются вперед и деблокируются;
    • б) Неподтвержденные транзакции от отказавшего узла откатываются и также деблокируются.
  4. В этот период транзакции обрабатываются исправными узлами, но, вероятно, несколько медленнее, чем обычно.
  5. Монитор транзакций повторно направляет в кластер неподтвержденные транзакции.
  6. Вышедший из строя узел ремонтируется и вновь запускается.
  7. Создается новая конфигурация кластера, включающая в себя отремонтированный узел.

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

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

Informix OnLine-XPS — среда высокой доступности данных

Сервер Informix OnLine Extended Parallel Server (OnLine-XPS) предназначен для слабосвязанных (кластерных) систем и систем с массовым параллелизмом (MPP).

Подобно аппаратным платформам, на которые он рассчитан, Informix OnLine-XPS построен на принципах неразделения ресурсов (независимости узлов). Каждый из узлов кластера или MPP-системы выполняет свой экземпляр программного обеспечения СУБД, которое включает сервисы протоколирования, восстановления, управления блокировками и буферами. Узел, на котором выполняются эти сервисы, называется ко-сервером.

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

Рисунок 3.
Архитектура сервера Informix OnLine-XPS

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

  • аварийное переключение ко-серверов;
  • зеркалирование дисковых областей;
  • тиражирование данных;
  • игнорирование недоступных данных.

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

Аварийное переключение ко-серверов выполняется следующим образом. Каждый ко-сервер владеет некоторым набором дисков, на которых располагаются фрагменты базы данных. Диски, как правило, являются двухпортовыми, и каждый из них физически соединен еще с некоторым ко-сервером Informix OnLine-XPS. Если в результате аппаратного или программного сбоя узел выходит из строя, его диски автоматически передаются во владение альтернативным ко-серверам и доступность данных сохраняется. Рассмотрим, например, конфигурацию на рис. 4. Ко-сервер 2 владеет дисками данных 3 и 4. Диск 3 подключен к альтернативному ко-серверу 1, а диск 4 — к ко-серверу 3.

Рисунок 4.
Аврийное переключение узлов

Когда обнаруживается отказ узла, Informix OnLine-XPS автоматически выполняет восстановление путем аварийного переключения. Диски, журнал транзакций, рабочую загрузку отказавшего узла берут на себя остальные ко-серверы.

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

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

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

Рисунок 5.
Тиражирование данных с основного узла на вторичный.

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

Существенный фактор обеспечения непрерывной доступности данных — возможность выполнять основные административные действия без останова сервера. Informix OnLine-XPS позволяет в оперативном многопользовательском режиме выполнять такие процедуры, как рефрагментация таблиц, добавление и уничтожение столбцов, создание и уничтожение индексов, сохранение и восстановление данных, замена диска, изменение конфигурации узла.

Тиражирование данных

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

Развитые возможности тиражирования предоставляет СУБД INGRES. Им посвящена статья [2]. Здесь мы рассмотрим возможности другого популярного сервера СУБД — Informix OnLine Dynamic Server (OnLine-DS) 7.1. В отличие от предыдущего раздела, речь пойдет об обычных (а не кластерных) конфигурациях.

В Informix OnLine-DS 7.1 поддерживается модель тиражирования, состоящая в полном отображении данных с основного сервера на вторичные.

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

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

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

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

Угрозы, специфичные для СУБД

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

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

Получение информации путем логических выводов

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

Следуя [3], рассмотрим больничную базу данных, состоящую из двух таблиц. В первой хранится информация о пациентах (анкетные данные, диагноз, назначения и т.п.), во второй — сведения о докторах (расписание мероприятий, перечень пациентов и т.д.). Если пользователь имеет право доступа только к таблице докторов, он тем не менее может получить косвенную информацию о диагнозах пациентов, поскольку, как правило, врачи специализируются на лечении определенных болезней.

Еще один пример — выяснение набора первичных ключей таблицы при наличии только привилегии INSERT (без привилегии SELECT). Если набор возможных значений ключей примерно известен, можно пытаться вставлять новые строки с «интересными» ключами и анализировать коды завершения SQL-операторов. Как мы видели из предыдущего примера, сам факт присутствия определенного ключа в таблице может быть весьма информативным.

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

Основным средством борьбы с подобными угрозами, помимо тщательно проектирования модели данных, является механизм размножения строк. Суть его в том, что в состав первичного ключа, явно или неявно, включается метка безопасности, за счет чего появляется возможность хранить в таблице несколько экземпляров строк с одинаковыми значениями «содержательных» ключевых полей. Наиболее естественно размножение строк реализуется в СУБД, поддерживающих метки безопасности (например, в INGRES/Enhanced Security), однако и стандартными SQL-средствами можно получить удовлетворительное решение.

Продолжая медицинскую тематику, рассмотрим базу данных, состоящую из одной таблицы с двумя столбцами — имя пациента и диагноз. Предполагается, что имя является первичным ключом. Каждая из строк таблицы относится к одному из двух уровней секретности — высокому (HIGH) и низкому (LOW). Соответственно, и пользователи подразделяются на два уровня благонадежности, которые мы также будем называть высоким и низким.

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

Иванов
Петров
Сидоров
СПИД
Сифилис
Стреляная рана

Таблица 4.
Данные с высоким уровнем секретности.

Иванов
Ивлев
Ярцев
Суворов
Пневмония
Рак легких
Ожог второй степени
Микроинфаркт

Таблица 5.
Данные с низким уровнем секретности.

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

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

Иванов
Ивлев
Петров
Сидоров
Ярцев
Суворов СПИД
Рак легких
Сифилис
Стреляная рана
Ожог второй степени
Микроинфаркт

Таблица 6.
Данные, доступные пользователю с высоким уровнем секретности (обратим внимание, что строка «Иванов Пневмания» здесь отсутствует.).

Размножение строк, обеспечивающее необходимую дисциплину доступа, стандартными средствами SQL можно реализовать следующим образом:

Всем пользователям предоставляется доступ только к представлению PatientInfo. Пользователи с низким уровнем благонадежности увидят только информацию, выдаваемую первой конструкцией WHERE, поскольку для них поле SecurityLevel имеет значение «LOW» :

В формирование представления для благонадежных пользователей внесут вклад обе конструкции WHERE, причем в случае совпадения имен менее секретные записи будут заслонены более секретными (конструкция NOT EXISTS).

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

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

Агрегирование данных

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

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

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

Покушения на высокую готовность (доступность)

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

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

Защита коммуникаций между сервером и клиентами

Проблема защиты коммуникаций между сервером и клиентами не является специфичной для СУБД, она присуща всем распределенным системам. Вполне естественно, что и решения здесь ищутся общие, такие, например, как в распределенной вычислительной среде (Distributed Computing Environment, DCE) концерна OSF. Разработчикам СУБД остается «погрузить» свои программные продукты в эту среду, что и сделала компания Informix, реализовав Informix-DCE/Net [4].

Informix-DCE/Net открывает доступ к сервисам DCE для всех инструментальных средств Informix, а также любых приложений или инструментальных комплексов от независимых поставщиков, которые используют интерфейс ODBC (рис. 8).

Рис.8. Конфигурация прикладной или инструментальной среды клиент-сервер, использующий Informix-DCE/Net.

Ключевым компонентом в реализации взаимодействий клиент-сервер в среде DCE является сервис безопасности. Основные функции, предоставляемые этим сервисом, — аутентификация, реализуемая средствами Kerberos, авторизация (проверка полномочий) и шифрование.

Informix-DCE/Net использует все средства обеспечения безопасности, имеющиеся в DCE. Например, для каждого приложения клиент-сервер администратор может задать один из пяти уровней защиты:

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

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

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


Заключение

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

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

  1. Ошибки и упущения обслуживающего персонала и пользователей.
  2. Действия нечестных работников.
  3. Огонь.
  4. Действия обиженных работников.
  5. Вода.
  6. Действия посторонних лиц.

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

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

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

Защита от посторонних пользователей может строиться на основе использования сервера аутентификации (такого, например, как Kerberos) и брандмауэра (например, Firewall-1).

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

Литература


  1. Ладыженский Г.М. Системы управления базами данных — коротко о главном. — Jet Info, 1995, ## 3-5.
  2. Ладыженский Г.М. Тиражирование данных в СУБД INGRES. — Jet Info, 1994.
  3. Polk T.W., Bassham L.E. Security Issues in the Database Language SQL. — NIST Special Publication 800-8.
  4. G. Chung. Informix-DCE/NET Technical White Paper. — Informix Systems Journal, Vol. 1, Number 3, July-August 1995.
  5. Manola F.A. A Personal View on DBMS Security. — in DATABASE SECURITY: Status and Prospects. C.E. Landwehr (Editor). Elsevier science Publishers B.V. (North Holland). IFIP, 1988, p. 23-34.
  6. Castano S., Fugini M., Martella G., Samarati P. Database Security. — Addison-Wesley, 1995.

Поделитесь материалом с коллегами и друзьями

Кибербезопасность баз данных: основные риски и способы противостояния им

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

Автор: Юрий Бутузов, эксперт в области средств защиты информации компании «ICL Системные технологии»

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

ВОЗМОЖНЫЕ РИСКИ И ПРИМЕРЫ РЕАЛЬНЫХ ИНЦИДЕНТОВ

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

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

Пример атаки изнутри:

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

Пример атаки извне:

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

МЕТОДЫ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ БАЗ ДАННЫХ

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

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

Контроль доступа

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

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

Криптографическая защита

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

Аудит

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

Разделение компонент

Разделение баз данных на типы в зависимости от выполняемых на них задач – промышленная, тестовая, для разработки — является общепризнанной практикой устоявшейся в течении множества лет.

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

Безопасное конфигурирование

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

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

ТЕХНИЧЕСКИЕ СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ БАЗ ДАННЫХ

Обеспечение безопасности Web-приложений

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

В условиях работы в рамках требований Российского законодательства, одним из неотъемлемых требований является наличие действующего сертификата ФСТЭК.

На рынке РФ наиболее часто встречаются решения компании Imperva и Positive Technologies. Также можно выделить решения таких производителей как Код Безопасности, Radware и F5 (последние два решения не имеют сертификатов ФСТЭК).

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

Физическое разделение компонент БД, контроль доступа на сетевом уровне

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

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

Наличие наглядных средств администрирования и визуализации событий в межсетевых экранах, является несомненным плюсом ввиду прямого влияния на операционные расходы, связанные с расследованием инцидентов. В качестве возможных вариантов для решения данной задачи являются продукты компании Check Point Software Technologies, PaloAlto Networks, Cisco Systems, Инфотекс, Код Безопасности и т.п.

Контроль доступа и аудит действий пользователей и администраторов

Реализация функций по контролю доступа, разделению прав, и выполнению аудита всех действий, может быть выполнена встроенными средствами БД. Однако, следует отметить, что включение функций по встроенному аудиту, как того требуют задачи по обеспечению безопасности (т.е. не только базовый набор команд), приводит к возрастанию нагрузки на аппаратные ресурсы от 10 до 30% в зависимости от базы данных, что в свою очередь влечёт неэффективную растрату дорогих аппаратных ресурсов. Реализация функций аудита встроенными средствами БД, в любом случае оставляет возможность администратору отключить этот аудит.

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

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

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

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

Обычный межсетевой экран не позволяет работать с данными на уровне sql – запросов, разбирая их и выстраивая для них профиль защиты. Именно это и привело к появлению решений подобных решениям от компаний Imperva и МФИ Софт.

Разделение компонент

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

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

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

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

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

Для обнаружения и анализа уязвимостей в базах данных следует использовать сканеры безопасности (MaxPatrol от компании Positive Technologiees, Nessus от компании Tenable Network Security, Inc и пр.), при этом их применение должно выполняться в строго согласованные технологические “окна” c соблюдением требований по предварительному резервированию текущих конфигураций в базе данных.
Сканирование при помощи технического инструментария должно выполняться по заранее подготовленным профилям сканирования актуальным для выполняемой задачи. Результаты сканирования должны разбираться и интерпретироваться соответствующими специалистами, чтобы с одной стороны максимально точно настроить профиль сканирования, а с другой чётко обозначить выявленные недостатки в конфигурациях баз данных, уязвимости и недостающие обновления.

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

Выявление отклонений в поведении пользователей/администраторов

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

В качестве подобных решений могут применяться системы UBA (User Behavioral Analysis), принцип работы которых строиться на основании составления профиля поведения для каждого контролируемого субъекта при его операциях с объектами доступа. При этом следует учитывать факты срабатывания подобных систем в случаях появления дополнительных полномочий у субъектов доступа, изменения их прав и добавления новых объектов с которыми осуществляется работа.

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

ОПЕРАЦИОННЫЕ МЕРЫ ОБЕСПЕЧЕНИЯ ЗАЩИТЫ БАЗ ДАННЫХ И ИХ КОМПОНЕНТ

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

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

ЗАКЛЮЧЕНИЕ

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

Подписывайтесь на каналы «SecurityLab» в Telegram и Яндекс.Дзен, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

Будь умным!

Работа добавлена на сайт samzan.ru: 2020-03-13

Заказать написание уникльной работы

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Тема 8.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Безопасность баз данных. Механизмы защиты.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>8.1. Основные аспекты безопасности БД.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Основной формой организации информационных массивов в ИВС являются базы данных.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Базу данных ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> можно определить как совокупность взаимосвязанных хранящихся вместе данных при наличии такой минимальной избыточности, которая допускает их использование оптимальным образом для одною или нескольких приложений. В отличие от файловой системы организации и использования информации, БД существует независимо от конкретной программы и предназначена для совместного использования многими пользователями. Такая централизация и независимость данных в технологии БД потребовали создания соответствующих СУБД — сложных комплексов программ, которые обеспечивают выполнение операций корректного размещения данных, надежного их хранения, поиска, модификации и удаления.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> С точки зрения эталонной модели взаимодействия открытых систем любая система управления распределенными базами данных (РБД) есть компонента специального программного обеспечения информационно-вычислительной сети, использующая свои собственные протоколы только на прикладном уровне. В связи с этим обеспечение безопасности РБД косвенно реализуется сетевой ОС, а точнее, ее механизмами и средствами нижних уровней. Однако все указанные механизмы и средства инвариантны конкретным способам представления информации в БД (в конечном итоге, моделям данных), возможностям СУБД и их языковых средств по доступу к данным, а также возможностям, предоставляемым прикладным программам по работе с базами данных. Подобная инвариантность приводит к тому, что в случае непринятия специальных мер все пользователи СУБД имеют равные права по использованию и обновлению всей информации, имеющейся в базе данных. В то же время указанная информация, как и при ее неавтоматизированном накоплении и использовании, должна быть категорирована, как минимум, по грифу секретности, группам пользователей, которым она доступна, а также по операциям над нею, которые разрешены указанным группам. Реализация подобного категорирования требует разработки и включения в состав СУБД специальных механизмов, краткому рассмотрению которых и посвящен настоящий подраздел.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Считается, что принятие решения о доступе к той или иной информации, имеющейся в БД, может зависеть от следующих факторов:

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>1) времени и точки доступа;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>2) наличия в БД определенных сведений;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>3) текущего состояния СУБД;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>4) полномочий пользователя;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>5) предыстории обращения к данным.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>В первом случае доступ к БД с каждого терминала ИВС может быть ограничен некоторым фиксированным отрезком времени, за пределами которого любая попытка обращения к БД с этого терминала является запрещенной. Во втором случае пользователь может получить из БД интересующие его сведения только при условии, что база данных содержит некоторую взаимосвязанную с ними информацию определенного содержания. Например, можно установить ограничения, согласно которым сведения о заработной плате некоторого лица выдаются пользователю только тогда, когда это лицо состоит на государственной службе или, когда размер этой платы не превышает определенного значения. В третьем случае, например, обновление информации в некоторой БД может быть разрешено пользователю только в те моменты времени, когда она не обновляется другими пользователями. В четвертом случае для каждого пользователя прикладной программы устанавливаются индивидуальные права на доступ к различным элементам (разделам) базы данных. Эти права регламентируют операции, которые пользователь может выполнять над указанными элементами. Например, пользователю может быть разрешен отбор элементов БД, содержащих информацию о товарах, предлагаемых на бирже, но запрещено обновление этих сведений. В основе пятого из перечисленных факторов лежит то обстоятельство, что интересующую его информацию пользователь может получить не непосредственным отбором тех или иных элементов БД, а косвенным путем, то есть посредством анализа и сопоставления ответов СУБД на последовательно вводимые запросы (команды на обновление данных). В связи с этим для обеспечения безопасности информации в БД в общем случае необходимо учитывать предысторию обращения к данным.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Механизмы, обеспечивающие безопасность информации в БД на основе анализа перечисленных факторов, разрабатываются в рамках определенной политики безопасности, которая, в свою очередь, вырабатывается, исходя из соображений юридического характера, особенностей функционирования организационных структур, использующих базу данных, и т.п. При этом указанные механизмы должны быть, по возможности, достаточно гибкими с тем, чтобы их можно было эффективно использовать независимо от возможных изменений политики безопасности.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Существуют два в известном смысле противоположных подхода к ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>политике безопасности ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>. Первый, соответствующий так называемой ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>политике минимума привилегий ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>, состоит в том, чтобы в максимальной степени ограничить круг лиц, допущенных к информации в БД. При этом указанные лица получают доступ только к тем сведениям, которые необходимы им для выполнения служебных обязанностей. Существо второго подхода состоит в том, чтобы, наоборот, обеспечить ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>максимальное использование информации ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>, имеющейся в БД. При этом категорирование данных по грифу секретности по-прежнему имеет место, однако в остальном ограничения на доступ к информации таковы, что каждому пользователю доступен как можно более широкий круг сведений.

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

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Защищаемую информацию в БД принято делить на контекстно-зависимую (контекстно-чувствительную) и контекстно-независимую. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Контекстно-независимой считается информация ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>, принятие решений на доступ к которой определяется первыми тремя из перечисленных выше факторов и не связано с использованием полномочий пользователя и предыстории его обращений к базе данных. Всю остальную информацию принято относить к ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>контекстно-чувствительной.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Механизмы обеспечения безопасности контекстно-независимой информации реализуются достаточно просто и поэтому наиболее широко распространены в реальных СУБД. Из ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>них ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>представляют определенный интерес механизмы представлений и модификации запроса, обеспечивающие защиту информации с учетом конкретного содержимого БД. Для удобства изложения при рассмотрении существа этих механизмов мы будем придерживаться понятийного аппарата реляционной модели данных.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Механизм представлений, который был впервые реализован в одной из наиболее развитых реляционных СУБД ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>System ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>R ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ( ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>SQL ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>/ ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>DS ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>) [1], основывается на выделении каждому пользователю собственной подсхемы схемы базы данных и работе только с этой подсхемой. Так, если БД содержит отношения АНКЕТА и ЗАРПЛАТА со схемами АНКЕТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ДАТА-РОЖДЕНИЯ, ПОЛ, СЕМЕЙНОЕ-ПОЛОЖЕНИЕ, ДОЛЖНОСТЬ) и ЗАРПЛАТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ОКЛАД-ПО-ДОЛЖНОСТИ, НАДБАВКА-ЗА-ВЫСЛУГУ-ЛЕТ, ПРЕМИЯ, НАЛОГ, ОБЩАЯ-СУММА), то одной группе пользователей могут быть выделены подсхемы отношений АНКЕТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО.ДОЛЖНОСТЬ) и ЗАРПЛАТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ОКЛАД-ПО-ДОЛЖНОСТИ) а другой — только подсхема первого отношения АНКЕТА (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ДАТА-РОЖДЕНИЯ). Администрация БД работает с полными схемами обоих отношений. При этом, естественно, значения атрибутов, не входящих в выделенные подсхемы, соответствующим пользователям недоступны.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Механизм модификации запроса, поддерживаемый, в частности, другой эффективной реляционной СУБД ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>INGRES ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> [2,3], основывается на принудительном (невидимом пользователю) приформировывании к тексту запроса дополнительных условий отбора, исключающих возможность получения сведений, доступ к которым пользователю запрещен. СУБД обрабатывает модифицированный таким образом запрос и выдает пользователю ответ, в котором содержатся только разрешенные элементы информации. Указанные условия отбора могут быть установлены и, как правило, устанавливаются индивидуально для каждого пользователя. Так, применительно к БД, содержащей отношения с приведенными выше схемами, подобные условия могут иметь следующий вид: ДОЛЖНОСТЬ = (МНС,СНС,ЗАВЕДУЮЩИЙ СЕКТОРОМ) ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>& ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ДАТА-РОЖДЕНИЯ >31.12.1931 для отношения АНКЕТА и ОБЩАЯ СУММА ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>& ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ДОЛЖНОСТЬ = (ЗАВЕДУЮЩИЙ СЕКТОРОМ, ЗАВЕДУЮЩИЙ ОТДЕЛОМ) он будет преобразован в АНКЕТА: ДАТА-РОЖДЕНИЯ ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>& ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ДОЛЖНОСТЬ = (ЗАВЕДУЮЩИЙ СЕКТОРОМ, ЗАВЕДУЮЩИЙ ОТДЕЛОМ) ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>& ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ДОЛЖНОСТЬ = (МНС,СНС,ЗАВЕДУЮЩИЙ СЕКТОРОМ) ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>& ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>ДАТА-РОЖДЕНИЯ >31.12.1931. При этом пользователь получит анкетные данные только о заведующих секторами, родившихся в 1932-1962 г.г., тогда как затребованные им сведения о заведующих отделами, родившихся до 1962 г., а также о заведующих секторами, родившихся до 1932 г., не будут включены в ответ.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Описанные механизмы, вообще говоря, не делают различия между операциями, выполняемыми над защищаемой информацией: считается, что информационный объект либо доступен пользователю, либо недоступен, причем в первом случае пользователь может выполнять над объектом любые операции, а во втором — никакие. Более тонкие механизмы реализуют избирательную защиту информации, когда для каждой операции и каждого пользователя определяется свое множество информационных объектов, над которыми она может быть выполнена пользователем. Например, одному из пользователей могут быть разрешены внесение, удаление и отбор любых элементов отношения АНКЕТА и отбор любых элементов отношения ЗАРПЛАТА. В это же время другому пользователю может быть разрешено внесение и удаление элементов отношения АНКЕТА, значениями атрибута ДОЛЖНОСТЬ, в которых не являются ЗАВЕДУЮЩИЙ ОТДЕЛОМ и ЗАВЕДУЮЩИЙ СЕКТОРОМ, а также отбор элементов отношения ЗАРПЛАТА по сотрудникам, не занимающим указанные должности.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Механизмы обеспечения безопасности контекстно-чувствительной информации существенно сложнее и в настоящее время находятся в стадии теоретической проработки и экспериментальных программных реализаций [4].

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>8.2. Основные требования по безопасности в базах данных

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Основные требования по безопасности данных, предъявляемые к БД и СУБД, во многом совпадают с требованиями, предъявляемыми к безопасности данных в компьютерных системах. Поэтому некоторые из механизмов защиты БД (рис.8.1.) идентичны механизмам, используемым для защиты ОС.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Тем не менее, специфические особенности технологии БД определяют ряд требований по безопасности, характерных именно для БД. Основные требования можно разделить на требования по ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>управлению доступом ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> и требования ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> по управлению целостностью ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> данных.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Требования по управлению доступом в базах данных

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Под управлением доступом в БД ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> понимается защита данных в БД от НСД. Обычно выделяют следующие требования по безопасности, связанные с доступом в БД.


;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>1. Возможность контроля доступа. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> В СУБД должны быть предусмотрены механизмы установления субъекта, осуществляющего тот или иной доступ к конкретному элементу данных, а также тип осуществленного доступа.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>2. Доступность данных. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Пользователи, которые авторизованы для работы с БД, должны иметь гарантированный доступ к соответствующим данным.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>3. Управляемость доступом. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Пользователь должен иметь доступ только к тем данным, для работы с которыми он имеет полномочия. При этом пользователи могут быть ограничены различными типами доступа (чтение, модификация, добавление, удаление и т.п.) к одним и тем же данным.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Требования по управлению целостностью в базах данных

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Под ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> управлением целостностью в БД ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> понимается защита данных в БД от неверных (в отличие от несанкционированных) изменений и разрушений. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Поддержание целостности БД ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> состоит в том, чтобы обеспечить в каждый момент времени корректность (правильность) как самих значений всех элементов данных, так и взаимосвязей между элементами данных в БД.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>С поддержанием целостности связаны следующие основные требования.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> 1.Обеспечение достоверности. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> В каждый элемент данных информация заносится точно в соответствии с описанием этого элемента. Должны быть предусмотрены механизмы обеспечения устойчивости элементов данных и их логических взаимосвязей к ошибкам или неквалифицированным действиям пользователей.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>2. Управление параллелизмом. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Нарушение целостности БД может возникнуть при одновременном выполнении операций над данными, каждая из которых в отдельности не нарушает целостности БД. Поэтому должны быть предусмотрены механизмы управления данными, обеспечивающие поддержание целостности БД при одновременном выполнении нескольких операций.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>3. Восстановление. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Хранимые в БД данные должны быть устойчивы по отношению к неблагоприятным физическим воздействиям (аппаратные ошибки, сбои питания и т.п.) и ошибкам в программном обеспечении. Поэтому должны быть предусмотрены механизмы восстановления за предельно короткое время того состояния БД, которое было перед появлением неисправности.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Вопросы управления доступом и поддержания целостности БД тесно соприкасаются между собой, и во многих случаях для их решения используются одни и те же механизмы. Различие между этими аспектами обеспечения безопасности данных в БД состоит в том, что управление доступом связано с предотвращением преднамеренного разрушения БД, а управление целостностью — с предотвращением непреднамеренного внесения ошибки.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Рис. 8.1. Механизмы защиты баз данных

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>8.3. Управление доступом в базах данных. Способы управления.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Большинство систем БД представляют собой средство единого централизованного хранения данных. Это значительно сокращает избыточность данных, упрощает доступ к данным и позволяет более эффективно защищать данные. Однако в технологии БД возникает ряд проблем, связанных, например, с тем, что различные пользователи должны иметь доступ к одним данным и не иметь доступа к другим. Поэтому, не используя специальные средства и методы, обеспечить надежное разделение доступа в БД практически невозможно.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Большинство современных СУБД имеют встроенные средства, позволяющие администратору системы определять права пользователей по доступу к различным частям БД, вплоть до конкретного элемента. При этом имеется возможность не только предоставить доступ тому или иному пользователю, но и указать разрешенный тип доступа: что именно может делать конкретный пользователь с конкретными данными (читать, модифицировать, удалять и т.п.), вплоть до реорганизации всей БД.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Кратко охарактеризуем некоторые механизмы управления доступом, используемые в различных БД.

Использование замков и ключей доступа

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Рассмотрим сущность данного механизма доступа на примере сетевой модели КОДАСИЛ, которая была предложена в докладах и отчетах рабочей группы по БД ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>DBTG ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Ассоциации по языкам систем обработки данных ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>CODASIL ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> в 1969-78 годах [5].

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>В работах указанной группы, наряду с обоснованием основ ных требований и конструктивных решений по архитектуре БД, нашли отражение и вопросы обеспечения безопасности БД. В частности, был описан подход к управлению доступом в БД с использованием замков ( ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>ACCESS ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>CONTROL ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>LOCK ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>) и ключей управления ( ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>ACCESS ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>CONTROL ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>KEY ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>).

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Согласно предложенному подходу при определении данных указываются ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> наборы (виды) ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> операций над данными и ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> замки ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> управления доступом. Замок управления доступом представляет собой средство идентификации пользователя. В случае указания правильного ключа пользователь получает право выполнять над данными соответствующие операции. Пример задания замков управления доступом в модели КОДАСИЛ приведен на рис.8.2.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Использование рассмотренного способа позволяет осуществлять гибкое управление доступом в БД, однако его использование затрудняется по следующим основным причинам:

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>1) пользователь вынужден многократно предъявлять ключи управления доступом;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> 2) изменение замка управления доступом оказывает влияние на большое количество пользователей, причем степень этого влияния трудно оценить;

  1. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>замок управления доступом может устанавливать только лицо, осуществляющее определение данных (обычно администратор БД).

Таблицы управления доступом

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Таблицы (списки) управления доступом широко используются в компьютерных системах, например, в ОС для управления доступом к файлам. Особенность использования этого средства для защиты БД состоит в том, что в качестве объектов зашиты выступают не только отдельные файлы (области в сетевых БД, отношения в реляционных БД), но и другие структурные элементы БД: элемент, поле, запись, набор данных.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>По сравнению с использованием замков и ключей управление доступом на основе таблиц доступа (матриц доступа) имеет следующие достоинства:

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>1) возможность построения таблицы непосредственно пользователем БД;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>2) отсутствует необходимость указания ключей управления доступом;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>3) простота изменения таблицы доступа.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>ОБ ЪЯВЛЕНИЕ В ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>CX ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Е ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>M ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Е БАЗЫ ДАННЫХ ЗАМКА УПРАВЛЕНИЯ

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>ДОСТУПОМ

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>RECORD ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>NAME ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>IS

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>01 СЛУЖАЩИЙ

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> 10 ЛИЧНЫЙ НОМЕР Р1С 9(6)

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>ACCESS CONTROL LOCK

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> FOR MODIFY IS ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>АДМИНИСТРАТОР ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 10 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>ФАМИЛИЯ ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> Р1С X(12)

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ACCESS CONTROL LOCK

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> FOR ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>DELETE ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>IS ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> «КТО» (строка символов

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> . объявлена в качестве

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> . замка для удаления

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> . записи)

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>ПРЕДЪЯВЛЕНИЕ КЛЮЧА УПРАВЛЕНИЯ В ПРОГРАММЕ ПОЛЬЗОВАТЕЛЯ

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>PROCEDURE DIVISION

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>DECLERATIVES.

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>USE FOR ACCESS CONTROL ON ERASE FOR ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>СЛУЖАЩИЙ ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>.

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> .

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> .

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> .

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>MOVE » ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>КТО ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>» TO DB ACCESS CONTROL KEY

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> .

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> .

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> .

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>END DECLARATIVES.

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> .

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> .

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> .

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>ERASE S.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Рис ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>.8.2. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Пример использования замков и ключей управления доступом.

Динамическое управление доступом

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>При использовании динамического управления доступом пользователю предоставляется возможность управления доступом путем использования специальных команд. Такой механизм управления представляет собой расширение предыдущего способа в том смысле, что пользователь сам динамически формирует таблицы управления доступом.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Примером системы с механизмом защиты, реализующим динамическое управление доступом, является реляционная СУБД ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>DB ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>[6]. При создании нового отношения в БД владелец этого отношения имеет абсолютное право доступа к нему, включая право определять представления, основанные на этом отношении. Никто другой таких прав не имеет. У пользователя-владельца есть возможность предоставить право работы с отношением или его представлением другому пользователю. Это осуществляется командой ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>ORANT ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> (разрешение), имеющей следующий вид:

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>GRANT ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>ON ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ТО

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> [ ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>WITH ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>GRANT ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>OPTION ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>] ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> (передача права определения полномочий другим пользователям).

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Для отмены прав доступа другим пользователям пользователь владелец должен выдать команду ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>REVOKE ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>:

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>REVOKE ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>ON ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>FROM ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> .

Управление доступом с помощью внешней схемы

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>В ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>архитектуре ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> современных БД принято выделять ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>три основных уровня представления данных о предметной области ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> (см. рис. 8.3.) ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>[7] ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>:

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>- концептуальный (уровень администратора);

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>- внешний (уровень прикладных программистов, конечных пользователей);

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>- внутренний (уровень системных программистов).

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Одной из функций внешней схемы является управление доступом, так как она ограничивает поле зрения пользователя пределами некоторой области. На рис.8.4 представлен пример внешней схемы, заданной отношением реляционной модели данных. Из рисунка видно, что в отношении ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>RI ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> не содержится атрибут ЗАРПЛАТА, а в отношении ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>R ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>2 содержится информация о сотрудниках кафедры. Поэтому право доступа к БД со стороны пользователей, использующих отношения ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>R ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>1 и ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>R ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>2 в качестве внешних схем, автоматически (системой управления БД) ограничивается рамками соответствующих отношений.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Рис. 8.3. Отображение предметной области в схемах БД

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Рис. 8.4. Пример использования внешней схемы при управлении доступом

Проблема предположения в базах данных

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Заканчивая рассмотрение механизмов управления доступом в БД, следует особо выделить ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>проблему предположения ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> [8,9].

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Наличие такой проблемы обусловлено тем, что взаимосвязанность хранимых в БД данных, в отличие от файловых систем, приводит к возможности получения одних данных по значениям других. Действительно, читая какой-либо файл в среде ОС, пользователь, за редким исключением, не может определить содержимое других файлов. Иная ситуация в БД, где за счет санкционированного доступа к элементам данных пользователь имеет возможность определить значения других данных, к которым он доступа не имеет. Существует множество способов построения предположений в среде БД: по суммам, по счетчикам, по линейным зависимостям и т.п.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Борьба с предположениями достаточно сложна и разработка механизмов защиты от них зачастую требует привлечения развитых методов современной логики и информатики. Суть большинства механизмов защиты состоит в том, чтобы не дать пользователю накопить объем незащищенной информации, достаточный для построения предположений о содержании защищенной от него информации. Однако ограничение с этой целью доступа пользователя к БД может привести к нарушению требования доступности данных для санкционированного пользователя, то есть страдать от этого будут пользователи, не помышляющие о каких-либо предположениях.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Кроме того, постоянное накапливание информации о том, какие сведения известны каждому пользователю, не только является дорогостоящим и сложным, но зачастую и не позволяет своевременно обнаружить опасность построения предположений, если пользователи имеют возможность обмениваться информацией друг с другом.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>8.4. Управление целостностью данных

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Нарушение целостности данных может быть вызвано рядом причин:

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> -сбои оборудования, физические воздействия или стихийные бедствия;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> -ошибки санкционированных пользователей или умышленные действия несанкционированных пользователей;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> — программные ошибки СУБД или ОС;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> — ошибки в прикладных программах;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> — совместное выполнение конфликтных запросов пользователей и др.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Нарушение целостности данных возможно и в хорошо отлаженных системах. Поэтому важно не только не допустить нарушения целостности, но и своевременно обнаружить факт нарушения целостности и оперативно восстановить целостность после нарушения.

Ограничения целостности данных

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Составной частью лежащих в основе БД моделей данных являются ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ограничения — ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> набор правил выполнения операций, гарантирующих их корректность (правильность). Важнейшими из этих ограничений являются ограничения целостности.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>В теории реляционных запросов выделяют три основных типа ограничений целостности.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>1. Ограничения целостности объекта. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Значение ключа отношения, идентифицирующего объект либо его часть, не должно быть пустым (неопределенным) значением.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>2. Ограничения целостности ссылок. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Значение атрибута, отображающего связи между объектами и являющегося внешним ключом отношения, обязательно должно быть значением атрибута, описывающего соответствующий объект и являющегося ключом отношения.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>3. Ограничения целостности приложений. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> К этому типу относятся ограничения, связанные с конкретными приложениями и реальными данными. Примерами ограничений целостности приложений могут служить:

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>а) статические ограничения, ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> то есть ограничения на значения элементов данных, которые должны выполняться для каждого состояния БД;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>6) ограничения перехода — ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ограничения, накладываемые на диапазон изменения элементов данных;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>в) ограничения для кортежей (записей) ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ограничения, проверку которых можно осуществить, используя отдельные кортежи отношения (записи).

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> г) ограничения для множеств ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> — ограничения, относящиеся к итоговым и средним значениям, получаемым из множества кортежей (записей);

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>д) безотлагательные ограничения — ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ограничения, допускающие возможность проверки их правильности одновременно с изменением значений данных;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>е) отложенные ограничения ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> — ограничения, для которых проверка выполнения имеет смысл по окончании логически объединенных в одну транзакцию операций.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Многие современные СУБД имеют механизмы, позволяющие установить подобного рода ограничения на значения данных в процессе описания данных, и механизмы проверки соблюдения требований в процессе эксплуатации БД. Наличие таких механизмов существенно сокращает риск непреднамеренных ошибок пользователей при работе с данными. Если ограничения целостности нарушаются, то изменение или занесение данных в БД не производится.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Механизмы ограничения целостности элементов данных также служат серьезным препятствием для преднамеренного искажения значений данных.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>В качестве примера средств построения механизма ограничения целостности БД можно указать предложения ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>KEY ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> и ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>CHECK ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> языка описания данных модели КОДАСИЛ (см. рис.6.5.)

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>С помощью предложения ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>CHECK ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> можно объявить уникальный (системный) ключ для каждой записи в БД. С помощью предложения ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>CHECK ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> можно также записать различные ограничения статического типа. В приведенном примере этот тип ограничений специфицирован для атрибута ОКЛАД: значение этого атрибута не должно превышать 500000. Кроме того, для записи члена набора ПРИНАДЛЕЖНОСТЬ с помощью ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>CHECK ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> объявлено ограничение на целостность связей между элементами данных. Отметим, что ограничения последнего вида в модели применимы лишь к связям между владельцем и членами одного набора. Поэтому с помощью предложения ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>CHECK ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> записать ограничения целостности связей в общем случае, а также ограничения перехода и ограничения для множеств нельзя.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>ОПИСАНИЕ ЗАПИСИ С ДАННЫМИ О СЛУЖАЩЕМ

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> /. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>ОПИСАНИЕ ЗАПИСИ С ДАННЫМИ О СЛУЖАЩЕМ

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>RECORD NAME IS ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>СЛУЖАЩИЙ


;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> KEY SK IS NBCA ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Каждый ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>объект ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ( ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>запись ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>)

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> DUPLICATES NOT ALLOWED ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>идентифицируется ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 10 NBCA TYPE CHARACTER 8 ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>уникальным ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>ключом ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>N ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>ВСА ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 10 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>ФАМИЛИЯ ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> TYPE CHARACTER 25

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> .

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> .

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> .

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 10 N_ПРИH TYPE CHARACTER 12

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 10 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>ОКЛАД ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> TYPE DECIMAL

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> СHECK IS ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>ОКЛАД ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> NOT

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> .

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> .

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> 2.0ПИСАНИЕ НАБОРА ПРИНАДЛЕЖНОСТЬ

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>SET ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>NAME ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>IS ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ПРИНАДЛЕЖНОСТЬ

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>OWNER ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ПОДРАЗДЕЛЕНИЕ

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>MEMBER ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> СЛУЖАЩИЙ

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>CHECK ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>IS ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>N ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>_ПРИН

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>IS ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>= ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>N ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ПОДР ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>IN ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>OWNER ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ПОДРАЗДЕЛЕНИЕ

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Значение атрибута ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> N_ПРИН ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> в члене набора ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ПРИНАДЛЕЖНОСТЬ ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> должно равняться значению атрибута ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>N ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>_ ПОДР ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> в записи владельца данного члена.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Рис. 8.5. Ограничения целостности в модели КОДАСИЛ.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Более широкие возможности по заданию и проверке выполнения ограничений целостности существуют в реляционных системах, использующих язык структурированных запросов ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>SQL ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>, причем любой запрос пользователя на ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>SQL ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> перед его выполнением может быть модифицирован таким образом, чтобы не было возможности нарушить любые ограничения целостности [6,10].

Управление параллелизмом

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

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Важнейшим средством механизма защиты целостности БД выступает объединение совокупности операций, в результате которых БД из одного целостного состояния переходит в другое целостное состояние, в один логический элемент работы, называемый ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> транзакцией. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Суть ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>механизма ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>транзакций ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>состоит в том, что до завершения транзакции все манипуляции с данными проводятся вне БД, а занесение реальных изменений в БД производится лишь после нормального завершения транзакции.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Сточки зрения безопасности данных такой механизм отображения изменений в БД очень существенен. Если транзакция была прервана, то специальные встроенные средства СУБД осуществляют так называемый откат возврат БД в состояние, предшествующее началу выполнения транзакции (на самом деле откат обычно заключается просто в невыполнении изменений, обусловленных ходом транзакции, в физической БД).

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Если выполнение одной транзакции не нарушает целостности БД, то в результате одновременного выполнения нескольких транзакций целостность БД может быть нарушена. Представленный на рис. 8.6 пример иллюстрирует данное утверждение: в результате выполнения двух транзакций значение элемента данных должно увеличиться на 2, но если не предпринять никаких дополнительных мер по управлению выполнением транзакций, то их выполнение даст неверный результат.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Чтобы избежать подобного рода ошибок, СУБД должна поддерживать механизмы, обеспечивающие захват транзакциями модифицируемых элементов данных до момента завершения модификации, так называемые ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> блокировки. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> При этом гарантируется, что никто не получит доступа к модифицируемому элементу данных, пока транзакция не освободит его.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Применение механизма блокировок приводит к новым проблемам управления параллелизмом, в частности, к возникновению ситуаций клинча двух транзакций (аналогично клинчу двух процессов в ОС).

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Объектами блокировок могут быть значения отдельных атрибутов, кортежи отношений (записи), целые отношения (файлы), наборы данных БД. Причем, если некоторая транзакция пытается блокировать объект, который уже блокирован другой транзакцией, то ей придется ждать, пока не будет снята блокировка объекта транзакцией, установившей эту блокировку. Иными словами, блокировку объекта может выполнять только одна транзакция.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Транзакция ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>. называется ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> правильно оформленной, ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> если она удовлетворяет следующим условиям.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> 1. Перед обработкой объекта должна быть выполнена его блокировка.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> 2. После обработки объект должен быть обязательно разблокирован (освобожден).

  1. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Перед освобождением блокированного объекта не должна выполняться

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> повторная блокировка.

  1. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Неблокированный объект не должен освобождаться.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Для поддержания целостности БД необходимо соблюдать определенные правила выполнения блокировок.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Для совокупности транзакций ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>= ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>11 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>, а ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>12 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> , . а ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial’;vertical-align:sub» xml:lang=»en-US» lang=»en-US»>M ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> >,

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>2 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> = ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>2 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>, а ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>21 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>,…, а ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>2 ;font-family:’Arial’;vertical-align:sub» xml:lang=»en-US» lang=»en-US»>M ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>2 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>>, . ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»en-US» lang=»en-US»>N ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> = ;font-family:’Arial’;vertical-align:sub» xml:lang=»en-US» lang=»en-US»>N ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>, а ;font-family:’Arial’;vertical-align:sub» xml:lang=»en-US» lang=»en-US»>N ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>2 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>, …,а ;font-family:’Arial’;vertical-align:sub» xml:lang=»en-US» lang=»en-US»>NMN ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> порядок выполнения

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Symbol'» xml:lang=»en-US» lang=»en-US»>

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>элементарных операции ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> а ;font-family:’Arial’;vertical-align:sub» xml:lang=»en-US» lang=»en-US»>IJ ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ( ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>i ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>= ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> 1, ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>N ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>) ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> называют ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> расписанием выполнения

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>совокупности элементарных операций. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Элементарными операциями могут служить операции: изменить объект ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>х, ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> блокировать ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> х, ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> разблокировать ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>х ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> и др.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Значение

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> элемента в

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> БД

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 5

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 5

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 5

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 5

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 6

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 6

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Транзакция ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 1

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Чтение э ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>лемента

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Symbol'» xml:lang=»en-US» lang=»en-US»>

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Приба ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>в ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>ит ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>ь

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> 1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Symbol'» xml:lang=»en-US» lang=»en-US»>

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Запис ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>ь

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>элемента

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Транзакция ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 2

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Чтение элемента

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Symbol'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Приба ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>ви ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>ть

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> 1

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Symbol'» xml:lang=»en-US» lang=»en-US»>

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Запи ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>с ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>ь ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>элемента

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>3 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>начение

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>элемента для ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>тра ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>нзакции ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 1

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 5

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 5

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 6

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 6

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 6

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Зн ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>а ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>чен ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>и ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>е ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>элемента

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>для ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>транзакции ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 2

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 5

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 5

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 6

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 6

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> б

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Рис.8.6. Пример нарушения целостности при параллельном выполнении транзакций.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Если элементарные операции ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>а ;font-family:’Arial’;vertical-align:sub» xml:lang=»en-US» lang=»en-US»>IJ ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> обязательно являются смежными в расписании выполнения совокупности элементарных операций, то такое расписание называется ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> последовательным. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Последовательное расписание не нарушает целостности БД, однако такое расписание низкоэффективно.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Расписание, выполнение которого дает результаты, эквивалентные результатам последовательного расписания, называется ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>сериализуемым.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Расписание правильно оформленных транзакций, в котором повторная блокировка ранее блокированного объекта происходит после его разблокировки, называется ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> легальным расписанием. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Легальное расписание обеспечивает одновременное (параллельное) выполнение нескольких транзакций. Однако легальное расписание не всегда является сериализуемым, то есть целостность БД не гарантируется.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Совокупность транзакций, для которой все легальные расписания являются сериализуемыми, называется ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> надежной. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Конструктивное определение надежной совокупности транзакций связано с понятием двухфазной блокировки. Если интервалы блокирования всех объектов в транзакции накладываются друг на друга, то говорят, что такая транзакция подчиняется требованиям двухфазной блокировки. Таким образом, ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> двухфазная блокировка ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>представляет собой ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> требование, ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> согласно которому в каждой транзакции все операции блокирования объектов должны предшествовать всем операциям разблокирования.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Если транзакции ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>, ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>2 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>,…, ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»en-US» lang=»en-US»>N ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>являются правильно оформленными и для них выполняется двухфазная блокировка, то совокупность ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ( ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> , ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>2 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> . ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»en-US» lang=»en-US»>N ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>) ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> — надежная. Это является ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> достаточным условием ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> сериализуемости расписания.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Различные типы блокировок обеспечивают разные уровни целостности данных.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Очевидно, что не все операции, выполняемые в транзакции, изменяют значения объектов (например, операция записи изменяет значение объекта, а операция чтения — не изменяет). Это различие целесообразно учитывать при организации блокировок объектов.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Рассмотрим подробнее случаи, возникающие при одновременном выполнении двух транзакций ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> и ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>2 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>1. Транзакции ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> и ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>2 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> изменяют значение объекта. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>В рассматриваемом случае могут возникнуть следующие ситуации:

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>а) нарушение целостности, называемое ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> потерей обновления ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>и вызванное наложением изменяемых значений одинаковых объектов (пример на рис.8.6);

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>6) возникновение по какой-либо причине ошибки в значении объекта, изменяемого операцией в ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>, что может привести к ошибке выполнения ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>2 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>. В таком случае невозможно исключить только результат ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> (сделать откат ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>). Подобное нарушение целостности называют ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> взаимозависимостью восстановления.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>2. Транзакция ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> изменяет значение объекта,

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>транзакция ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>2 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> считывает значение объекта.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>В этом случае могут возникнуть следующие ситуации:

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>а) изменение транзакцией ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> значения объекта, уже считанного транзакцией ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>2 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> В такой ситуации говорят, что для ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>2 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> отсутствует ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> воспроизводимость считывания;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>б) возникновение отказа перед окончанием транзакции ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> , что полностью исключает изменения, обусловленные выполнением ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>. В этом случае возможен откат в состояние, которое было перед выполнением ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> . Взаимозависимость в этом случае отсутствует, но существует возможность считывания в транзакции ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>2 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>неправильных значений объекта. В такой ситуации говорят, что транзакция ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> загрязняет транзакцию ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»en-US» lang=»en-US»>2 ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>3. Транзакция ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> считывает значение объекта,

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>транзакция ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>2 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> изменяет значение объекта.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>В этом случае нет гарантии, что при повторном считывании значения объекта транзакцией ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> будет получено то же значение объекта, что и при первом считывании. В отличие от п.2(а), здесь ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>2 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> не гарантирует воспроизводимость считывания для ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>4. Транзакции ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> и ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>W ;font-family:’Arial’;vertical-align:sub» xml:lang=»ru-RU» lang=»ru-RU»>2 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> считывают значение объекта. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Рассмотренные случаи показывают необходимость нескольких уровней целостности, определяющих соответствующий вид и период блокировки:

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>а) при изменении значений объекта должна осуществляться монопольная блокировка. При такой блокировке никакие другие одновременно выполняемые транзакции не имеют возможности считать либо изменить значение объекта;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>б) при использовании монопольной блокировки целесообразно не освобождать объект до окончания данной транзакции.

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

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>в) при одновременном выполнении транзакций, в которых осуществляется только выборка значений объектов, используется ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> совместная блокировка. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> В этом случае одновременно выполняемые транзакции могут выполнять считывание значения объекта, но им запрещено выполнять изменение этого значения.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Таблица 8.1. иллюстрирует использование возможных вариантов блокировки одинаковых объектов при одновременном выполнении транзакций. Знаки «—» и «+» в таблице указывают, соответственно, допустима или нет следующая попытка блокировки объектов (знак «+» указывает на то, что требования блокировки по отношению к объекту конкурируют между собой).

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Можно указать три способа разрешения конфликтных ситуаций:


;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>1) перевести конкурирующую транзакцию в состояние ожидания разблокирования объекта;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>2) прекратить выполнение конкурирующей транзакции;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>3) прекратить выполнение предшествующей транзакции и продолжить выполнение конкурирующей транзакции.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Использование любого из перечисленных способов для организации параллельного выполнения совокупности правильно оформленных транзакций, удовлетворяющих ограничению двух фазной блокировки, гарантирует целостность БД.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Таблица ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>8 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>.1.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Вид ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>первоначальной

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> блокировки

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Вид

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>последующей

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>блокировки

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Нет

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Совместная блокировка

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Монопольная блокировка

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Нет

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ….

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> …

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> …

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Совместная ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>блокировка

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ….

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> …

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> +

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Монопольная ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>блокировка

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ….

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> +

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> +

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Известно, что при использовании первого способа (наиболее часто применяемого в СУБД) может возникнуть ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> тупиковая ситуация (клинч), ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> при которой каждая из одновременно выполняемых транзакций ожидает, когда ей будет предоставлена возможность заблокировать объект, в данный момент времени заблокированный какой-либо другой транзакцией. При этом ни одна из транзакций не может разблокировать объект, необходимый для продолжения другой транзакции.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Для предотвращения возникновения тупиковой ситуации необходимо, чтобы каждая транзакция единовременно запрашивала все нужные ей блокировки на начальной стадии своего выполнения. Другим простым способом обнаружения тупиковой ситуации является обнаружение совокупности транзакций, которые находятся в состоянии ожидания дольше определенного промежутка времени. Если при этом обнаруживается тупиковая ситуация, то она устраняется путем отката и рестарта какой-либо из попавших в эту ситуацию транзакций.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>8.5. Восстановление данных

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Как уже отмечалось, возникновение сбоев в аппаратном или программном обеспечении может вызвать необходимость восстановления и быстрого возвращения в состояние, по возможности близкое к тому, которое было перед возникновением сбоя (ошибки). К числу причин, вызывающих необходимость восстановления, зачастую относится и возникновение тупиковой ситуации.

Уровни восстановления

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Можно выделить три основных уровня восстановления.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>1. Оперативное восстановление, ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> которое характеризуется возможностью восстановления на уровне отдельных транзакций при ненормальном окончании ситуации манипулирования данными (например, при ошибке в программе).

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>2. Промежуточное восстановление. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Если возникают аномалии в работе системы (системно-программные ошибки, сбои программного обеспечения, не связанные с разрушением БД), то требуется восстановить состояние всех выполняемых на момент возникновения сбоя транзакций.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>3. Длительное восстановление. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> При разрушении БД в результате дефекта на диске восстановление осуществляется с помощью копии БД. Затем воспроизводят результаты выполненных с момента снятия копии транзакций и возвращают систему в состояние на момент разрушения.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Транзакция и восстановление

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Прекращение выполнения транзакции вследствие появления сбоя нарушает целостность БД. Если результаты такого выполнения транзакции потеряны, то имеется возможность их воспроизведения на момент возникновения сбоя. Таким образом, понятие транзакции играет важную роль при восстановлении (см. рис.8.7.).

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Для восстановления целостности БД транзакции должны удовлетворять следующим требованиям:

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>1) необходимо, чтобы транзакция или выполнялась полностью, или не выполнялась совсем;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>2) необходимо, чтобы транзакция допускала возможность возврата в первоначальное состояние, причем, для обеспечения независимого возврата транзакции в начальное состояние, монопольную блокировку необходимо осуществлять до момента завершения изменения всех объектов;

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>3) необходимо иметь возможность воспроизведения процесса выполнения транзакции, причем, для обеспечения этого требования, совместную блокировку необходимо осуществлять до момента завершения просмотра данных всеми транзакциями.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>В процессе выполнения любой транзакции наступает момент ее завершения. При этом все вычисления, сделанные транзакцией в ее рабочей области, должны быть закончены, копия результатов ее выполнения должна быть записана в системный журнал. Подобные действия называют ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> операцией фиксации.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>При появлении сбоя целесообразнее осуществлять возврат не в начало транзакции, а в некоторое промежуточное положение. Точку, куда происходит такой возврат, называют ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> точкой фиксации (контрольной точкой).

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Пользователь может установить в процессе выполнения транзакции произвольное количество таких точек- Если в ходе выполнения транзакции достигается точка фиксации, то СУБД автоматически осуществляет указанную

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>выше операцию.

Откат и раскрутка транзакции

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Основным средством, используемым при восстановлении, является системный журнал, в котором регистрируются все изменения, вносимые в БД каждой транзакцией. Возврат транзакции в начальное состояние состоит в аннулировании всех изменений, которые осуществлены в процессе выполнения транзакции. Такую операцию называют ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> откатом. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Для воспроизведения результатов выполнения транзакции можно, используя системный журнал, восстановить значения проведенных изменений в порядке их возникновения, либо выполнить транзакцию повторно.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Воспроизведение результатов выполнения транзакции с использованием системного журнала называется ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> раскруткой. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Раскрутка является достаточно сложной, но необходимой операцией механизмов восстановления современных БД. Кроме того, откат и раскрутка используются для устранения тупиковых ситуаций, когда необходимо произвести аннулирование изменений одной из конкурирующих транзакции.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Если появляется сбой из-за ошибки оператора или ОС (СУБД), то выполняемые в это время транзакции полностью исключаются и возникает необходимость в перезапуске системы с некоторого предыдущего момента времени. Для этого в системе организуются ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>контрольные точки. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Контрольная точка служит для осуществления отката транзакций и является границей, с которой перезапускают систему. Момент возникновения сбоя нельзя предугадать, следовательно, контрольные точки необходимо устанавливать периодически.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Рис. 8.7. Восстановление и транзакция

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Существует два типа контрольных точек.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>1. Контрольная точка, условием установления которой является отсутствие в данный момент времени выполняющихся транзакций- Если транзакция выполняется, то начало новых транзакций задерживается, и контрольная точка устанавливается после завершения выполняющейся транзакции. При появлении сбоя осуществляется откат в состояние, соответствующее последней установленной контрольной точке. Раскрутка транзакции, завершившейся между контрольной точкой и точкой появления сбоя, осуществляется с использованием системного журнала.

  1. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Контрольная точка устанавливается при наличии выполняющихся транзакций. В этом случае в контрольной точке фиксируют состояние рабочих областей всех выполняющихся транзакций. При появлении сбоя осуществляется откат в состояние контрольной точки. Для транзакции, которая выполнялась в момент установления контрольной точки, откат осуществляется до ее начального состояния (далее аналогично п.1).

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Длительное восстановление

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Если при возникновении сбоя внешнего запоминающего устройства БД разрушается, операция отката транзакций в начальное состояние становится бессмысленной. Для восстановления БД после такого сбоя периодически формируется ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>дамп ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> (точная копия физических файлов всей БД). С помощью дампа воспроизводится состояние БД на момент снятия копии, после чего осуществляется раскрутка до последней перед сбоем контрольной точки. Для раскрутки используется системный журнал.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>В некоторых случаях получение дампов БД реализуется средствами ОС. Однако более эффективной является ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>загрузка/выгрузка средствами СУБД. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> В процессе выгрузки данные извлекаются из БД и в строго определенном формате записываются в обычные файлы (запись данных в файлы может осуществляться в другом формате). При этом за счет описания и заполнения избыточных данных создается возможность восстановления связей между конкретными значениями данных в процессе проведения обратной операции — загрузки БД. Средства загрузки/выгрузки, помимо возможности создания резервных копий БД, выполняют еще одну важную функцию: в некоторых случаях они позволяют реструктурировать БД и улучшить эксплуатационные характеристики базы данных.

Упражнение к лекции 8

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>1 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>. ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> Какие механизмы защиты являются общими для ОС и БД (СУБД)?

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>2. Перечислите характерные для технологии БД требования по безопасности данных.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>3. Чем отличается управление доступом от управления целостностью БД?

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>4. Сформулируйте основные недостатки положений КОДАСИЛ по защите БД.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>5. В чем заключается сходство и различие механизмов управления доступом к БД, использующих таблицы (матрицы) доступа и внешнюю схему БД?

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>6. Предложите способы выявления косвенного предоставления права доступа для систем с динамическим управлением доступом (на примере СУБД ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>DB ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>).

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>7. Перечислите нарушения целостности БД, связанные с параллельным выполнением транзакций.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>8. Назовите достаточное условие сериализуемости расписания выполнения транзакций.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>9. Перечислите способы, позволяющие избежать тупиковых ситуаций. Перечислите способы выхода из состояния клинча транзакций.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>10. Перечислите уровни восстановления БД. В чем заключается сущность каждого уровня?

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>Литература

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>1. Blasgen ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>M.W., ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>Eswaran ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>К ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>.P. Storage and access in relational ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>, ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> data bases ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>// ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>IBM Systems Journal, Vol. 16 (1977), No.4. P.363-378.

;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>2. ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>Stonebraker ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> М. Performance enhancements to a relational database System ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>//ACM ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> TODS, Vol.8 (1983), No.2. P.167-185.

3. Rowe LA ., Stonebraker M.R. The Postgres datamodel // Very Large Data Bases: Proc. of the 13th Int. Conf. — Brighton. England, 1987. P. 83-96.

4. Denning D.E., Aki S.G., Morgenstern М ., Neumann P.G., Schell R.R., Heckmann M. Views for multilevel database security/ / Security and Privacy : Proc. jf the 1986 IEEE Symp. — Wash. : IEEE Comp. Society Press , 1986. P . 156-172.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>5. Олле Т.В. Предложения КОДАСИЛ по управлению базами данных.- М.: Финансы и статистика, 1981. 286 с.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>6. Дейт К. Руководство по реляционной СУБД ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>DB ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>-.- М.: Финансы и статистика , 1988.-320 с.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>7. ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>Ha ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>г ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>ao ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> М., Катаяма Т., Уэмура С. Структуры и базы данных.- М.: Мир, ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 1986.- 197 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> с.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>8. Голубев В.В-, Дубров П.А., Павлов Г.А- Механизмы защиты операционных систем и систем управления базами данных // Зарубежная радиоэлектроника, 1989.- ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>N ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>12.- С. 36-47.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>9. Моисеенков И.И. Безопасность компьютерных систем // Компьютер Пресс, 1991.- ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»>N ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>12.- С. 57-61.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>10. Дейт К. Введение в системы баз данных.- М.: Наука, 1980.-464 с.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>11. Бородаев В.А., Кустов В.Н. Банки и базы данных.-Л.: ВИКИ им. А.Ф.Можайского, ;font-family:’Arial'» xml:lang=»en-US» lang=»en-US»> 1989. 224 ;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»> с.

;font-family:’Arial'» xml:lang=»ru-RU» lang=»ru-RU»>12. Уэлдон Дж.Л. Администрирование баз данных.- М.: Финансы и статистика, 1984.- 207 с.

Безопасность баз данных

Система управления базами данных. База данных MS Access.

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

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

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

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

Свойства полей БД

Поля определяют структуру БД, а также групповые свойства данных, записываемых в ячейки данного поля:

· Имя поля – определяет, как следует обращаться к данным поля при автоматических операциях с БД (по умолчанию имена полей используются в качестве заголовков столбцов таблиц);

· Тип поля – определяет тип данных поля;

· Размер поля – определяет предельную длину (в символах) данных поля;

· Формат поля – определяет способ форматирования данных в поле;

· Маска ввода – определяет форму, в которой вводятся данные (является средством автоматизации ввода данных);

· Подпись – определяет заголовок столбца таблицы для поля (по умолчанию заголовком столбца будет свойство Имя поля);

· Значение по умолчанию – значение, вводимое в ячейки поля автоматически (средство автоматизации ввода данных);

· Условие на значение – ограничение для проверки правильности ввода данных (средство автоматизации ввода данных, например, числового, денежного типа, типа дата);

· Сообщение об ошибке – текст, автоматически выдаваемый при попытке ввода ошибочных данных (должно быть задано свойство Условие на значение);

· Обязательное поле – свойство, определяющее, что данное поле заполняется обязательно при наполнении базы данными;

· Пустые строки – свойство, разрешающее ввод пустых строковых данных;

· Индексированное поле – свойство, ускоряющее поиск, сортировку записей и другие операции в данном поле.

Типы данных

БД работают со следующими типами данных:

· Текстовый – тип данных, используемый для хранения обычного, неформатированного текста (до 255 символов);

· Поле MEMO – специальный тип данных для хранения больших объемов текста (до 65535 символов). Текст хранится в другом месте БД, поле хранит лишь указатель на него;

· Числовой – тип данных для хранения действительных чисел;

· Дата/время – тип данных для хранения календарных дат и текущего времени;

· Денежный – тип данных для хранения денежных сумм;

· Счетчик – специальный тип данных для уникальных натуральных чисел с автоматическим наращиванием (используется, например, для нумерации записей);

· Логический – тип для хранения логических данных (2 значения — Да, Нет);

· Поле объекта OLE – специальный тип данных для хранения объектов OLE, например, мультимедийных;

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

Безопасность баз данных

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

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

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

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

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

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

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

Режимы работы с БД

С БД работают две категории исполнителей:

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

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

БД имеет 2 режима работы: проектировочный (создание, изменение структуры БД, создание ее объектов) и пользовательский (использование ранее созданных объектов для наполнения базы, получения данных из нее).

Объекты БД

1) Таблицы – это основные объекты БД, хранят все данные базы, структуру базы (поля, их типы, свойства).

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

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

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

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

Дата добавления: 2020-06-13 ; просмотров: 775 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ

Илон Маск рекомендует:  Предопределённые константы session
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL