Лекция на тему "Организация защиты данных в СУБД"

Организация защиты данных в MS Access. Установка защиты на уровне пользователей. Процесс установки защиты можно разделить на этапы: • создание файла рабочей группы и подключение к нему Access; • назначение владельца базы данных и ее объектов; • создание учетных записей групп и пользователей в рабочей группе; • назначение разрешений на доступ к объектам базы данных. Установить защиту можно с помощью Мастера защиты или самостоятельно средствами  Access. Мастер защиты. Мастер защиты создает новую защищенную базу данных и импортирует в нее все объекты  исходной базы данных, сохраняя резервную копию незащищенной базы данных. Владельцем защищенной базы данных и всех ее объектов становится пользователь, запустивший Мастер защиты. • Открыв базу данных, подлежащую защите, выбрать меню Сервис ­ Защита ­ Мастер; • под руководством Мастера создать файл рабочей группы или, если база данных  подключена не к файлу SYSTEM.MDW, внести изменения в существующую рабочую  группу; • создать ярлык для подключения к защищенной базе данных; • выбрать объекты базы данных, подлежащие защите; • создать при необходимости учетные записи новых групп, кроме Admins и Users, с  особыми разрешениями; • максимально ограничить разрешения группе Users; • создать учетные записи новых пользователей, кроме Admin, с назначением их паролей; • распределить пользователей по группам рабочей группы, оставив пользователя Admin  только в группе Users и введя вместо него в группу Admins нового пользователя; • создать резервную копию незащищенной базы данных. Группы, создаваемые Мастером защиты, могут быть наделены следующими разрешениями: • Admins ­ все разрешения; • Полные права ­ все, кроме изменения разрешений; • Разработчики проекта ­ изменение данных и объектов, кроме таблиц и связей; • Все права на данные ­ изменение данных, но не макетов; • Новые данные ­ чтение и добавление данных без удаления и изменения их; • Обновление данных ­ без удаления и добавления данных; • Только чтение ­ чтение данных; • Операторы архива ­ резервирование и сжатие без доступа к данным; • Users ­ без разрешений. По завершении работы Мастера защиты на экране отображается отчет о защите,  содержащий всю указанную в окнах Мастера информацию, необходимую для  восстановления файла рабочей группы. Этот отчет рекомендуется отпечатать или сохранить. Открытие защищенной базы данных выполняется только через помещенный на Рабочий  стол ярлык после идентификации пользователя и ввода пароля. При этом Access  запускается в новой рабочей группе, созданной Мастером защиты, а открытие базы данных  в стандартной рабочей группе невозможно. Если понадобится изменить параметры защиты, Мастер защиты может использоваться  неоднократно. Снятие защиты на уровне пользователей  • Открыть защищенную базу данных от имени члена группы Admins; • задать группе Users разрешения на доступ ко всем объектам; • закрыть базу данных; • запустить Access от имени пользователя Admin; • создать новую базу данных; • импортировать в нее все объекты защищенной базы данных. MS SQL Server Организация защиты В критических для бизнеса приложениях, когда сервер СУБД должен быть постоянно  доступен для клиентов, большинство профилактических работ по поддержке базы данных  приходится выполнять фактически в режиме on ­ line. MS SQL Server обладает  возможностями динамического резервного копирования данных, т. е. даже когда эти  данные используются и изменяются клиентами. В случае сбоя оборудования, отключения  питания и т. д. механизм автоматического восстановления MS SQL Server восстанавливает  все базы данных до их последнего целостного состояния без вмешательства  администратора. Все завершенные, но не отраженные в базе транзакции из журнала  транзакций применяются к базе данных (это фактически то, что происходит при событии  chekpoint), а незавершенные транзакции, т. е. те, которые были активными на момент сбоя,  вычищаются из журнала. Говоря о симметричной архитектуре, операции резервного копирования и восстановления  могут распараллеливаться на несколько потоков и выполняться одновременно, используя  преимущества асинхронного ввода/вывода. На каждое резервное устройство отводится свой поток. Параллельное резервное копирование поддерживает до 32 одновременных  резервных устройств (backup devices), что позволяет быстро создавать страховочные копии баз данных даже очень большой емкости. Возможность резервного копирования и  восстановления отдельных таблиц, о чем мы упоминали, рассматривая Transact­SQL,  позволяет экономить место и время, не выполняя копирование всей базы ради только  некоторых ее объектов. Однако резервное копирование отдельной таблицы требует  наложения на нее блокировки exclusive в отличие от резервного копирования всей базы или журнала транзакций, которые могут выполняться независимо от степени активности  пользователей. Резервным копиям может быть назначен предельный срок хранения или  дата утраты актуальности, до наступления которой место, занятое на устройстве этими  копиями, не может использоваться для размещения других резервных копий при  инициализации устройства. В качестве резервных устройств могут также применяться  временные устройства, не входящие в состав базы и не имеющие записей в системной  таблице sysdevices: DECLARE @tomorrow char(8) SELECT @tomorrow = CONVERT(char(8), DATEADD(dd, 1, GETDATE()) , 1) DUMP DATABASE pubs TO DISK = '\\ntalexeysh\disk_d\sql_experiments\pubs.dmp' WITH INIT, EXPIREDATE=@tomorrow, STATS Для небольшой базы данных ее журнал транзакций обычно хранится на том же устройстве,  что и сама база, и архивируется вместе с ней. Журналирование транзакций ведется по  принципу write­ahead, что означает, что любое изменение сначала отражается в журнале  транзакций и лишь потом попадает собственно в базу. В случае нахождения журнала  транзакций на отдельном устройстве существует возможность отдельного резервного  копирования журнала транзакций. Как правило, резервное копирование базы данных  организуется с меньшей частотой, чем журнала транзакций. Например, сохранение журнала транзакций выполняется ежедневно, а страховая копия всей базы может делаться раз в  неделю, так как архивирование журнала транзакций происходит значительно быстрее по  времени и занимает меньше места, чем дамп целой базы. В отличие от резервирования базы  данных дамп журнала транзакций очищает его неактивную часть, т. е. все завершившиеся  (зафиксированные или абортированные) с момента последнего дампа транзакции, если  только не использована опция NO_TRUNCATE. Команда DUMP TRANSACTION  TRUNCATE_ONLY, очищающая журнал транзакций, полезна в случае его переполнения,  которое можно контролировать, например, оператором DBCC SQLPERF (LOGSPACE).  Если степень переполнения журнала очень высока, можно при его очистке отказаться от  журналирования факта самого этого события: DUMP TRANSACTION NO_LOG. Если  резервное копирование транзакций не представляет интереса, можно включить опцию  очистки последних завершенных транзакций в базе по наступлению события checkpoint.  Cмысл механизма checkpoint состоит в периодической записи данных из кэша на диск,  чтобы не допускать грязных данных. Такого рода события постоянно генерируются MS  SQL Server или возникают по инициативе пользователя. Включенная опция truncate log on  checkpoint гарантирует выполнение с определенной частотой обработчиком события действий, приблизительно эквивалентных команде DUMP TRANSACTION  TRUNCATE_ONLY. Безопасность данных в Oracle 7 Ограничение доступа Если мы уверены, что подключаться к нашей базе данных могут лишь уполномоченные  пользователи и что они могут запускать только те модули, на выполнение которых им явно  предоставлено право, то нужно подумать о следующем уровне безопасности —  ограничении доступа этих пользователей к данным. Огромным шагом вперед в обеспечении безопасности данных стало введение ролей в  Oracle7. До Oracle7 каждому пользователю приходилось явно предоставлять права доступа к каждому объекту базы данных, который ему разрешено было использовать. Этот процесс  упрощается за счет того, что доступ к совокупности объектов предоставляется роли, а  затем право на использование этой роли предоставляется соответствующим лицам. С  помощью команды GRANT мы можем предоставить пользователям право выполнять над  объектами БД (например, над таблицами) операции SELECT, INSERT, UPDATE и  DELETE. Однако само по себе это не обеспечивает значительной гибкости. Мы можем  ограничить доступ пользователей частями таблицы, разделив ее по горизонтали (ограничив  пользователя определенными строками), по вертикали (ограничив его определенными  столбцами) или и по горизонтали, и по вертикали. Как это сделать? Вернемся к нашему примеру с таблицей PAYROLL. Мы не хотим, чтобы все пользователи  видели столбец SALARY, и желаем ограничить доступ пользователей так, чтобы они могли видеть только записи о сотрудниках их отдела. Таблица PAYROLL NAME I D DEF T PAYMENT_PERIODSALARY 1 JONES 10 WEEKLY 2 K1RKUP 10 MONTHLY 3 DAVIES 10 WEEKLY 4 ARMSTRONG20 MONTHLY 5 KEMP 20 MONTHLY 6 FISHER 30 WEEKLY 120 900 150 1030 1005 150 Мы можем определить представление и предоставить пользователям доступ к этому  представлению, а не к базовой таблице (PAYROLL). Они смогут запрашивать данные этой  таблицы лишь через представление, которое ограничивает их доступ. Определение такого  представления приведено ниже. CREATE VIEW vjpayroll AS SELECT id , name , dept , payment_period FROM payroll WHERE dept = (SELECT dept FROM mysys_users WHERE username = USER) WITH CHECK OPTION; Столбец SALARY в этом примере не включен в представление, поэтому зарплату в нем  увидеть нельзя, а фраза WHERE гарантирует, что пользователи смогут запрашивать данные из таблицы PAYROLL только по своему отделу. По поводу этого решения надо сказать следующее. Во­первых, мы должны сделать так,  чтобы пользователи не могли изменить свой отдел, обновив значение MYSYSJUSERS, и  затем запросить записи из другого отдела. Во­вторых, с помощью этого представления  пользователи могли бы обновлять, вставлять и удалять даже не относящиеся к их отделу  строки таблицы PAYROLL, если бы мы не отключили эту функцию с помощью фразы  WITH CHECK OPTION. Примечание Вряд ли представление V_PAYROLL будет обновляемым, потому что к столбцу SALARY  почти наверняка применено ограничение NOT NULL. Тем не менее, мы рекомендуем  использовать опцию WITH CHECK OPTION во всех ограничивающих представлениях, так  как в версии 7.3 значительно увеличилось число обновляемых представлений. Ограничение на просмотр данных с помощью представлений работает очень хорошо. Но  для большой таблицы со сложными требованиями к безопасности, возможно, придется  создать несколько представлений и заставить приложения решать, какое из них необходимо для конкретного пользователя. Реализовывать это внутри приложения нежелательно,  поэтому нужно исследовать другие решения. Мы можем инкапсулировать все операции над таблицей PAYROLL в хранимый пакет или же разработать несколько триггеров. Давайте  рассмотрим первое решение.