Построение защищенной базы данных предприятия
Угрозы безопасности баз данных. Политика информационной безопасности предприятия в области использования сетевых ресурсов. Разработка и введение в эксплуатацию защищенного клиент-серверного приложения. Средства аутентификации объектов базы данных.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 21.02.2013 |
| Размер файла | 4,6 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
3.5 Поддержание доступности
Информационная система предоставляет своим пользователям определенный набор услуг (сервисов). Говорят, что обеспечен нужный уровень доступности этих сервисов, если следующие показатели находятся в заданных пределах:
· эффективность услуг, которая определяется в терминах максимального времени обслуживания запроса, количества поддерживаемых пользователей, эффективность не должна опускаться ниже заранее установленного порога;
· время недоступности, если эффективность информационной услуги не удовлетворяет наложенным ограничениям, услуга считается недоступной, максимальная продолжительность периода недоступности и суммарное время недоступности за некоторой период не превышали заранее заданных пределов.
То есть, доступность - это возможность за приемлемое время получить требуемую информационную услугу.
В сущности, требуется, чтобы информационная система почти всегда работала с нужной эффективностью. Для некоторых критически важных систем (например, систем управления) время недоступности должно быть нулевым. В таком случае говорят о вероятности возникновения ситуации недоступности и требуют, чтобы эта вероятность не превышала заданной величины[7,c.24]. Это является одной из основных задач защиты.
3.5.1 Обеспечение отказоустойчивости
Отказоустойчивость - это способность системы работать в нормальном режиме и после сбоя. Средством обеспечения отказоустойчивости является резервное копирование и восстановление (рисунок 3.3). Резервирование повышает уровень надежности, который ожидается от созданной системы. Никакие RAID-массивы и кластеры не уберегут от ошибки пользователя, если тот удалил важные данные или присланное разработчикам обновление привело базу в неработоспособное состояние. Резервное копирование производится для того, чтобы в случае сбоя можно было провести восстановление. Поэтому вопрос о резервном копировании на предприятии не стоит, стоит вопрос о том, как лучше всего это сделать.
Для решения данной задачи применяются подходы так называемого горячего резервирования данных, когда база данных постоянно находится в виде двух идентичных (зеркальных) и параллельно функционирующих копий, размещаемых на двух раздельных системах дисковой памяти. Другими способами обеспечения сохранности данных являются операции архивирования и резервирования данных. В большинстве случаев архивирование производится обычными средствами архивации файлов для их компактного долговременного хранения, как правило, на внешних съемных носителях. Функции архивирования данных иногда могут входить и в перечень внутренних функций самих СУБД. Резервирование данных, как правило, не предусматривает специального сжатия данных, а производится через создание специальных копий файлов данных в технологических или иных целях[24, c.179].
Размещено на http://www.allbest.ru/
Рисунок 3.3 - Процесс резервного копирования и восстановления данных
И архивирование, и резервирование, помимо технологических целей, преследуют также профилактические цели по еще одной чрезвычайно важной операции - восстановлению данных после сбоев и повреждений. Наличие резервной или архивной копии базы данных позволяет восстановить работоспособность системы при выходе из строя основного файла (файлов) данных. При этом, однако, часть данных, или их изменений, произведенные за время, прошедшее с момента последнего архивирования или резервирования, могут быть потеряны. Такие ситуации особенно критичны при коллективной обработке общих данных, реализуемых клиент-серверными системами. Поэтому в промышленных СУБД, реализующих технологии «клиент-сервер», в большинстве случаев предусматривается ведение специального журнала текущих изменений базы данных, размещаемого отдельно от основных данных и, как правило, на отдельном носителе. Такой подход называется журнализацией. В журнале изменений осуществляются непрерывная фиксация и протоколирование всех манипуляций пользователей с базой данных. В результате при любом сбое с помощью архивной копии и журнала изменений администратор системы может полностью восстановить данные до момента сбоя.
Существует множество факторов, которые нужно учитывать при принятии решения о конкретном способе реализации - это и размер базы данных, и скорость восстановления, и бюджет, который можно на это потратить[24, c.180].
Самый первый вопрос - куда размещать резервные копии. Существует три варианта:
1. самый с технической точки зрения лучший, но при этом и самый дорогой- использование ленточных библиотек. Лучший, потому что обеспечивается высокая скорость и надежность, обычно вместе с ними поставляется и программный продукт для резервного копирования, но стоимость такого устройства велика - десятки тысяч долларов.
2. использование стримера, подключенного локально к компьютеру, на котором работает SQl Server. При создании резервной копии SQL Server позволяет использовать несколько устройств резервного копирования одновременно, при этом резервная копия распределяется среди нескольких носителей, которые должны быть одного типа. Распараллеливание процесса копирования позволяет увеличить скорость копирования и тем самым уменьшить время на создание резервных копий.
3. проведение резервного копирования на жесткий д3иск или RAID-массив, подключенного локально или по сети на другой компьютер. Главный плюс-скорость работы, можно поместить больший объем информации.
4. использование магнитооптики (MS SQL Server не поддерживает)
Первый вариант не подходит, так это будет слишком затратным для предприятия. Второй вариант более подходящий, в его пользу говорит дешевизна, простота и надежность, но это устройство последовательного доступа (нужно перематывать) и скорость восстановления в случае необходимость значительно ниже, чем с жесткого диска. Да и хранение на стриммерной ленте влечет за собой увеличение числа носителей, складирование их в определенных местах, где нет доступа ни для кого кроме администратора баз данных, захламление. Кроме того, на жесткий диск можно поместить больше информации, да и цена у него вполне доступная, поэтому выбор будет за помещением резервной копии на жесткий диск компьютера, находящегося в другом здании на удаленном расстоянии. Резервная копия передается по сети.
Резервное копирование можно проводить, используя:
1. стандартные средства MS SQL Server позволяют проводить резервное копирование с применением пароля
BACKUP DATABASE PVM
TO disk='\\o44-08171\backup\PVM'
WITH PASSWORD = @password
Если при восстановлении базы данных был введен неправильный пароль, то выведется сообщение об ошибке и база не будет восстановлена.
RESTORE DATABASE PVM
FROM disk='\\o44-08171\backup\PVM'
WITH PASSWORD = 'пароль'
Использование пароля для резервной копии не является сильной защитой. Более надежным механизмом защиты от вскрытия с помощью ПО третьих фирм, будет EFS для их шифрации.
2. коммерческие программные продукты (Veritas NetBackup, ArcServer, Legato).
Проблема резервного копирования в том, что надо защищать резервные копии:
1. вопрос службы безопасности - ограничение доступа на сервер, доступ дается только администратору и только через консоль или терминал сервер.
2. шифрование резервной копии, но тогда пароль (ключ, сертификат EFS) надо тоже где-то хранить либо создание резервной копии с паролем
3. создавать историю копий
Применение паролей может помочь защитить содержимое носителя от несанкционированного использования, использующего инструментальные средства SQL Server, но пароль не защитит от уничтожения, к тому же постоянно появляются все более «умные» программы-шпионы, созданные специально с целью подбора пароля. Прежде всего, необходимо ограничить доступ к носителю резервной копии.
Страховое копирование всей информации [41, c.56] в архив на предназначенные для этого соответствующие технические устройства резервирования и хранения данных. Администратор домена выполняет настройку и сопровождение работы задачи «Страховое копирование» для всех сетевых ЭВМ домена, отвечает за сохранность архива и обеспечение конфиденциальности доступа к архиву.
3.5.2 Принципы восстановления после мягкого и жесткого сбоя
Состояние внешней памяти базы данных называется физически согласованным, если наборы страниц всех объектов согласованы, т.е. соответствуют состоянию объекта либо после его изменения, либо до изменения.
К числу основных проблем восстановление после мягкого сбоя относится то, что одна логическая операция изменения базы данных может изменять несколько физических блоков базы данных, например, страницу данных и несколько страниц индексов. Страницы базы данных буферизуются в оперативной памяти и выталкиваются независимо. После мягкого сбоя набор страниц внешней памяти базы данных может оказаться несогласованным, т.е. часть страниц внешней памяти соответствует объекту до изменения, часть - после изменения. К такому состоянию объекта не применимы операции логического уровня. В качестве решения данной проблемы применяют журналы изменения базы данных[39, c.157].
Понятно, что для восстановления последнего согласованного состояния базы данных после жесткого сбоя журнала изменений базы данных явно недостаточно. Основой восстановления в этом случае являются журнал и архивная копия базы данных. Восстановление начинается с обратного копирования базы данных из архивной копии. Затем для всех закончившихся транзакций выполняется redo, т.е. операции повторно выполняются в прямом смысле. Более точно, происходит следующее:
* по журналу в прямом направлении выполняются все операции;
* для транзакций, которые не закончились к моменту сбоя, выполняется откат.
На самом деле, поскольку жесткий сбой не сопровождается утратой буферов оперативной памяти, можно восстановить базу данных до такого уровня, чтобы можно было продолжить даже выполнение незаконченных транзакций. Но обычно это не делается, потому что восстановление после жесткого сбоя - это достаточно длительный процесс. Хотя к ведению журнала предъявляются особые требования по части надежности, в принципе возможна и его утрата. Тогда единственным способом восстановления базы данных является возврат к архивной копии. Конечно, в этом случае не удастся получить последнее согласованное состояние базы данных, но это лучше, чем ничего[39,c.158].
Самый простой создать архивную копию - архивировать базу данных при переполнении журнала. В журнале вводится так называемая "желтая зона", при достижении которой образование новых транзакций временно блокируется. Когда все транзакции закончатся, и, следовательно, база данных придет в согласованное состояние, можно производить ее архивацию, после чего начинать заполнять журнал заново. Можно выполнять архивацию базы данных реже, чем переполняется журнал. При переполнении журнала и окончании всех начатых транзакций можно архивировать сам журнал. Поскольку такой архивированный журнал, по сути дела, требуется только для воссоздания архивной копии базы данных, журнальная информация при архивации может быть существенно сжата.
3.6 Пользователи базы данных
Пользователи базы данных - это категория пользователей в интересах которых и создается база данных. Это могут быть случайные пользователи обращающиеся к базе данных время от времени, за получение некоторой информации, а могут быть регулярные пользователи. Пользователей можно разделить на три группы[18, c.16]:
1. прикладные программисты - отвечают за создание программ, использующих базу данных; в смысле защиты данных программист может быть как пользователем, имеющим привилегии создания объектов данных и манипулирования ими, так и пользователем, имеющим привилегии только по модификации данными;
2. конечные пользователи базы данных - работают с базой данных непосредственно через приложение; имеют строго ограниченный набор привилегий манипулирования данными. Этот набор может определяться при создании интерфейса конечного пользователя и не изменяться. Политику безопасности в данном случае определяет администратор безопасности или администратор базы данных (если это одно и то же должностное лицо);
3. администраторы баз данных - образуют особую категорию пользователей СУБД; они создают сами базы данных, осуществляют технический контроль функционирования БД, обеспечивают необходимое быстродействие системы. В обязанности администратора, кроме того, входит обеспечение пользователям доступа к необходимым им данным, а также написание (или оказание помощи в определении) необходимых пользователю внешних представлений данных. Администратор определяет правила безопасности и целостности данных.
В SQL Server есть список встроенных ролей и пользователей, поэтому необходимо уделять внимание и им.
Первое, существует логин системного администратора SA , по умолчанию у него пустой пароль, он не может быть удален и не может потерять права sysadmin для всех баз данных, поэтому следует:
1. Никогда не запускайте под SA выполнение DTS пакета в задании по расписанию.
2. Регулярно меняйте пароль.
3. Храните пароль в секрете.
4. В аварийном плане чётко опишите, где можно получить этот пароль.
Второе, так как никто кроме DBA иметь права уровня sysadmins в SQL Server не должен, то следует удалить логин BUILTIN\Administrator.
Паролями пользователей необходимо управлять. Логин SA всегда должен иметь пароль, особенно если для получения привилегий sysadmin не возможно использовать Windows Authentication. Однако, проблема пустого пароля относится не только к SA. DBA должен очень строго следить за паролями пользователей в смешанном режиме безопасности, контролировать их сложность и длину. Если есть возможность влиять на логику прикладных программ, работающих с сервером баз данных, можно организовать проверку минимальных требований к паролю на клиенте. Хорошим решением является использование Active Directory и Windows-аутентификации в связке с COM+.
3.7 Использование хранимых процедур как средства повышения безопасности
При создании интегрированного с SQL приложения, встает вопрос о программном взаимодействии с базой данных. Есть две возможности:
· формировать команды SQl на стороне клиента, а после этого посылать их на сервер для исполнения
· перенести часть кода на сторону сервера
Понятно, что использование последнего подхода предпочтительнее, так как это позволит отделить интерфейс пользователя от интерфейса данных, чем уменьшится вероятность ошибок и разгрузится сеть от передачи промежуточной информации
Хранимые процедуры - это некоторый набор хранимых инструкций для того, чтобы каждый раз не вводить, а вызывать какие-то действия, то есть они являются средством автоматизации часто выполняемых процессов. Хранимые процедуры являются неотъемлемой частью работы с реляционной БД. Хранимые процедуры чаще всего используются в качестве программных модулей на стороне сервера.
Преимущества использования хранимых процедур:
· упрощают внешний вид инструкций и действия, производимые с ними
· скрывает детали о базе данных (например, связи между таблицами, названия таблиц)
· ограничение доступа, можно ограничить доступ к базе данных, давая пользователям доступ только через хранимые процедуры и только на их исполнение, не давая прав на доступ к самим таблицам; пользователь имеет доступ к данным, но только в пределах хранимой процедуры, иначе доступа у пользователя нет;
· целостность данных, создают гарантии правильного ввода и сохранности информации; так как происходит автоматизация сложных транзакций, уменьшается возможность возникновения ошибок по вине пользователя;
· эффективность, хранимая процедура компилируется всего один раз - при выполнении впервые, последующие выполнения проходят быстрее, поскольку этап компиляции пропускается, что в свою очередь уменьшает нагрузку на сет и снижает трафик, так как код хранимой процедуры загружается только один раз.
Использование хранимых процедур позволяет снизить сетевой трафик, стоимость сопровождения системы и дает возможность избавиться от необходимости постоянно изменять клиентские приложения. Если понадобится изменить логику обработки данных, то достаточно будет изменить только хранимую процедуру.
Кроме того, использование хранимых процедур также позволяет значительно повысить безопасность данных. Приложение или пользователь получает лишь специальное право на выполнение хранимой процедуры, которая и будет обращаться к данным. Все эти плюсы хранимых процедур позволяют обеспечить логическую целостность данных.
Возможность применения хранимых процедур и представлений для абстрагирования пользователя от находящихся в таблицах данных определяется следующими факторами[2, c.21]:
· Дополнительная утилизация ресурсов.
· Набор необходимых требований по поддержке безопасности для такого доступа.
· Архитектура приложения.
· Уровень приемлемой сложности.
· Навыки использования.
· Простота поддержки.
Безопасность CRUD (Create Read Update Delete) (рисунок 3.4) операций может осуществляться непосредственно представлениями, хранимыми процедурами, ролями и таблицами привилегий, instead-of триггерами другими объектного средствами разграничения доступа на уровне объектов и столбцов. Кроме того, доступ через хранимые процедуры позволяет воспользоваться преимуществами кэширования планов выполнения процедур[30, c.203].
Рисунок 3.4 - CRUD операции
Особое внимание заслуживают расширенные(extended) хранимые процедуры. Расширенные, в отличие от остальных ранимых процедур, всегда выполняются в контексте безопасности учетной записи операционной системы, под которой запущена служба MSSQLSERVER. Это означает, что любая ошибка в коде расширенной хранимой процедуры может обернуться аварийным завершением работы сервера или исполнением произвольного кода. Самые распространенные ошибки при написании расширенных хранимых процедур:
1. переполнение (буфера, кучи)
2. утечка памяти
3. ошибки форматирования (format string errors)
Ошибки первого типа могут привести к исполнению кода злоумышленника. Ошибки второго типа чреваты аварийным остановом сервера и отказом в обслуживании. Ошибки форматирования могут привести к чтению информации, которая не должна быть доступна. Причем во всех трех случаях возможна потеря информации.
Если злоумышленник будет использовать Extended Stored Procedure, он легко сможет получить доступ и к командной строке. Например, имея права на исполнение, он может запустить процедуру доступа к командной строке:
EXEC XP_CMDSHELL `at 12:06 /interactivecmd' - доступ к командной строке
А дальше, все зависит от цели злоумышленника: он может и в реестре исправить какие-то параметры, и запустить вредоносную программу и т.д.
Если нет необходимости использовать эту расширенную процедуру, её. Стоит заблокировать Иначе, для запуска этой процедуры пользователем, не являющимся системным администратором, нужно обеспечить контекст безопасности с минимально необходимым набором прав для исполнения команд на сервере. Для этого будет задействован контекст безопасности SQL Server Agent proxy account, которому можно сопоставить учётную запись с ограниченными правами. Изменения можно внести с помощью xp_sqlagent_proxy_account.
В качестве рекомендаций по защите можно сделать такие выводы:
· не давать прав пользователям вносить изменения в код процедуры
· использовать инструкцию WITH ENCRYPTION при создании хранимой процедуры, которая скроет код процедуры, но выполнять заложенные в ней действия будет
· не использовать и не давать прав на использование Extended Stored Procedure.
· после написания код Extended Stored Procedure тщательно перепроверить.
Но с инструкцией WITH ENCRYPTION есть свои проблемы. Не стоит полагаться на то, что зашифрованные хранимые процедуры не будут кем-то прочитаны. Для того, что бы максимально осложнить возможность подсматривания текстов процедур, можно установить Deny на SELECT в syscomments для public и на команды по созданию и удалению процедур. Подробный список хранимых процедур, которые рекомендуется заблокировать приведен в приложении Е.
3.8 Курсоры как механизм обеспечения безопасности
Механизм обеспечения безопасности в большинстве систем управления реляционными базами данных связан с использованием курсоров в сочетании с командами GRANT и REVOKE. Разрешение на доступ к подмножеству данных в курсоре должно быть предоставлено или аннулировано явным образом, независимо от действующей совокупности полномочий, относящихся к таблице (или таблицам), на которой основан данный курсор.
С помощью курсора пользователи могут запрашивать и модифицировать только те данные, которые они могут видеть. Остальная часть базы данных является для них невидимой и недоступной.
REVOKE ALL ON devices TO User1
GRANT SELECT ON devices TO User1
GRANT SELECT ON devices TO User1, User2, User3
Определяя различные курсоры и выборочно предоставляя права на них, можно ограничить доступ пользователя (группу пользователей) к различным подмножествам данных:
· доступ может быть ограничен некоторым подмножеством строк таблицы базы;
· доступ может быть ограничен некоторым подмножеством столбцов таблицы базы;
· доступ может быть ограничен некоторым подмножеством строк и столбцов таблицы базы;
· доступ может быть ограничен строками, которые удовлетворяют условию объединения нескольких таблиц базы;
· доступ может быть ограничен статистическими итоговыми данными;
· доступ может быть ограничен некоторым подмножеством другого курсора или определенного сочетания курсоров и таблиц базы.
Создание курсоров и реализация с их помощью (а также с помощью таблиц базы) системы доступа нередко является частью процесса определения данных. Однако ничто не мешает в любой момент изменить эту схему санкционирования, определив новые курсоры и написав новые операторы GRANT и REVOKE[39, c.161].
3.9 Аудит и мониторинг базы данных
Аудит - это анализ накопленной информации, проводимый оперативно, почти в реальном времени, или периодически. Аудит используется для протоколирования событий, происходящих в СУБД за время ее работы.
В СУБД такой подход хорошо вписывается в событийно-процедурную технологию с использованием техники журнализации. При этом доступ к журналу событий имеет только администратор безопасности, который при обнаружении фактов или признаков нарушений безопасности имеет возможность восстановления хода событий, анализа и устранения источников и причин нарушения безопасности системы. В этом отношении журнал событий безопасности является необходимым средством аудита безопасности.
Аудит безопасности заключается в контроле и отслеживании событий в системе с целью выявления, своевременного обнаружения проблем или нарушений безопасности и сигнализации об этом администратору безопасности. Разработка аналитических автоматизированных процедур обнаружения фактов и признаков нарушений информационной безопасности является чрезвычайно сложной и неопределенной задачей. Набор технологических задач, подходов, средств и инструментов, обеспечивающих практическую реализацию принципов, моделей и политик безопасности чрезвычайно широк, что объективно требует некоторой единой шкалы требований, методик разработки и оценки защищенных систем по вопросам безопасности.
Реализация аудита преследует следующие главные цели:
· обеспечение подотчетности пользователей и администраторов;
· обеспечение возможности реконструкции последовательности событий;
· обнаружение попыток нарушений информационной безопасности;
· предоставление информации для выявления и анализа проблем.
Обеспечение подотчетности важно в первую очередь как средство сдерживания. Если пользователи и администраторы знают, что все их действия фиксируются, они, возможно, воздержатся от незаконных операций. Если есть основания подозревать какого-либо пользователя в нечестности, можно регистрировать его действия особенно детально, вплоть до каждого нажатия клавиши.
При этом обеспечивается не только возможность расследования случаев нарушения режима безопасности, но и откат некорректных изменений.
Тем самым обеспечивается целостность информации.
Восстановление последовательности событий позволяет выявить слабости в защите сервисов, найти виновника вторжения, оценить масштабы причиненного ущерба и вернуться к нормальной работе.
Выявление и анализ проблем позволяют помочь улучшить такой параметр безопасности, как доступность.
Обнаружив узкие места, можно попытаться переконфигурировать или перенастроить систему, снова измерить производительность и т.д.
Т.о., это необходимый шаг для регистрации изменений в базе данных, а также в процессе разработки, сопровождения, администрирования, документирования и распространения программных продуктов или систем, использующих эту базу данных. Решаемые задачи:
1) восстановление реальной картины событий в базе данных в случае искажения (не важно, намеренного или нет), утери или, при не правомерном использовании ресурсов, порчи информации.
2) ведение истории изменения данных, когда большое значение имеет информация о том, какие именно данные изменялись, их старые и новые значение, создание архива данных. Используется, когда нужна полная история изменения данных. История хранится достаточно долго, возможно, на протяжении всей жизни данных. В некоторых случаях история хранится и после того, как данные были удалены.
3) уведомление об изменениях данных. Приложение может хранить на промежуточном или клиентском уровне некоторый объем данных, которые необходимо своевременно обновлять при изменениях в базе. Например, это может быть некий кэш, используемый для ускорения работы, или данные, выводимые на пользовательском интерфейсе. Реализация может сильно различаться в зависимости от решаемой задачи. В некоторых случаях достаточно фиксировать лишь факт операции, в некоторых журнал должен содержать все сведения, вплоть до старых и/или новых значений. Характерным признаком данного класса задач является короткая продолжительность хранения данных в журнале.
4) Типичная ситуация: с некоторой периодичностью запускается процесс, который считывает все изменения из журнала, рассылает уведомления, очищает журнал и отключается.
5) нестандартная репликация используется для синхронизации данных на разных серверах.
Мониторинг - растянутый во времени процесс наблюдения, измерения, сопоставления, записи, оценки, прогнозирования принятия решения о потенциально возможных изменениях состояния системы.
В MS SQL есть средства для мониторинга событий SQL-сервера, одно из таких средств- SQL Prifiler.
Используя SQL Profiler, фиксируем все операции успешные или нет, проводимые с базой. SQL Profiler - универсальный инструмент, который подходит для решения целого ряда административных задач: регистрация удачных или неудачных соединений с сервером, добавлении новых пользователей, смена пароля, отслеживание ошибок и т.д., повышение производительности, обнаружения блокировок, мониторинг изменений в структуре базы и изменений в данных, тестирование приложений и т.д.
Есть сведения о базе, в которой происходит создание или удаление, есть имя объекта, класс события (создание или удаление) и вся необходимая системная информация - имя машины, имя SQL-сервера, приложение, имя пользователя, время и т.д.
Аудит устанавливается в свойствах сервера через Enterprise Manager, закладка Security:
1) None (default) - audit level 0
2) Success - audit level 1
3) Failure - audit level 2
4) All - audit level 3
То же самое можно сделать с помощью расширенной хранимой процедуры:
xp_instance_regwrite
N'HKEY_LOCAL_MACHINE',
N'SOFTWARE\Microsoft\MSSQLServer\MSSQLServer',
N'AuditLevel', REG_DWORD,2
Сообщения аудита будут записаны в журналы ошибок NT и SQL Server.
Для организации аудита работы пользователей с данными, обычно, на уровне базы данных, встраивают специальные триггеры, с помощью которых отслеживаются команды вставки, удаления и обновления данных для пользовательских таблиц. При разработке триггеров стоит проанализировать следующее[20]:
1. Таблицы и представления, которым нужен аудит.
2. Минимальный набор данных, который стоит хранить в таблицах аудита.
3. Ожидаемая хронология данных аудита.
4. Величина дополнительной утилизации ресурсов вашей OLTP системы, вызванная внедрением аудита.
5. Дизайн индексов, представлений и ограничений для таблиц аудита.
6. Учёт каскадных операций.
В случае же когда необходимо фиксировать события, затрагивающие только существующие записи, либо только некоторых полей таблиц, либо нужна информация не столько о факте изменения, сколько о самих измененных данных, используется журналирование с помощью триггеров.
Необходимая информация:
· факт операции(успешная или неуспешная попытка)
· ее вид (INSERT/UPDATE/DELETE)
· имя сервера
· имя пользователя, который модифицировал данные
· имя машины, с которой оно проводилось
· дата/время модификации
· название приложения, через которое проводилось данное изменение
· название таблицы, которую модифицировал пользователь
Создаем таблицу, в которую будем заносить информацию о проделанных пользователем действиях. Создаем хранимую процедуру, через которую будем заносить информацию. Для реализации используем три триггера, по одному на INSERT, DELETE и UPDATE, чтобы дать запас, так как с течением времени требования к журналу могут измениться, их станет все больше, и, чтобы было проще ориентироваться в коде. Реализация на языке SQL приведена в приложении З.
Для сложных представлений, к которым не применим стандартный CRUD доступ, можно вместо обычных триггеров использовать instead-of триггеры, которые позволяют прервать и исследовать на предмет аудита любую CRUD команду на представлении или выполнить другие бизнес - требований.
MS SQL позволяет назначать одной таблице несколько триггеров одного типа. В идеале они должны быть независимы друг от друга, тогда порядок их срабатывания не имеет значения. Но в действительности это не всегда так. Например, может использоваться триггер, который меняет значения некоторых полей у тех же самых записей, на которые делается UPDATE. Если триггер журналирования выполнится перед данным триггером, то в журнал пойдут неизмененные значения, если после него - то измененные. Таким образом, надо следить за порядком срабатывания триггеров, если он имеет значение, для этого используется процедура sp_settriggerorder, которая позволяет назначать первый и последний триггер одного типа.
sp_settriggerorder @triggername= 'update_model_value', @order='last', @stmttype = 'UPDATE'
3.10 Репликация данных
Репликация (replication) - это процесс автоматического распределения копий данных и объектов БД между экземплярами SQL Server с одновременной синхронизацией всей распространяемой информации. Репликация используется в следующих случаях[8]:
· распространения информации с одного сервера на несколько серверов;
· сбор информации с нескольких серверов на один сервер;
· снижение нагрузки с рабочего сервера, снижение сетевого трафика между удаленными серверами;
· повышение отказоустойчивости, реализация избыточности данных; данные могут быть реплицированы на резервный сервер, который может использоваться для запросов, выполняемых с помощью средств поддержки принятия решений, и предоставлять копию данных при отказе основного сервера;
· расширение системы за пределы ЛВС; данные, для доступа к которым используется Интернет, могут быть реплицированы на различные серверы в разных географических регионах для равномерного распределения нагрузки между серверами;
В репликации предусмотрены три роли для серверов: распространитель, с помощью которого происходит перекачка данных из одного места в другое; издатель- источник для репликации; подписчик - сервер, который принимает данные от издателя.
SQL Server поддерживает три типа. Репликация моментальных снимков это периодическая репликация целостного набора данных, зафиксированного по состоянию на определенный момент времени, с локального сервера на удаленные сервера. Никакого отслеживания происходящих изменений нет. Самый простой и надежный способ, который не всегда может быть эффективным. Лучше использовать этот тип репликации, где количество реплицируемых данных невелико, а источник данных статичен.
Репликация транзакций - это репликация начального моментального снимка данных на удаленные серверы, а также репликация отдельных транзакций, работающих на локальном сервере и выполняющих последовательные изменения данных в начальном моментальном снимке. Эти реплицированные транзакции выполняются над реплицируемыми данными на каждом удаленном сервере для синхронизации данных на удаленном сервере с данными локального сервера. Репликация слиянием- это репликация начального моментального снимка данных на удаленные серверы, а также репликация изменений, происходящих на каком/либо удаленном сервере, обратно на локальный сервер с целью синхронизации, разрешения конфликтов и повторной репликации на удаленные серверы.
Процесс репликации достаточно сложный и он нуждается в защите. Защита процесса репликации реализована на нескольких уровнях. Прежде всего, только члены роли сервера sysadmin, могут конфигурировать и администрировать распространителей, издателей и подписчиков. На уровне базы данных только члены роли сервера sysadmin и фиксированной роли db_owner опубликованной базы могут создавать и конфигурировать публикации и подписки. Только члены роли сервера sysadmin и replmonitor базы распространения могут отслеживать активность процесса репликации. Если используется удаленный распространитель, лучше организовать защищенное соединение между ним и издателем. При соединении используется учетная запись distributor_admin SQL Server.
На втором уровне в целях защиты информации и повышения производительности системы, применять следует фильтрацию публикуемых данных. Фильтровать данные можно по горизонтали или по вертикали. Например, можно исключить из репликации столбцы, содержащие важную информацию или двоичные данные изображений. Фильтры могут быть статическими или динамическими.
Статические фильтры вводят ограничения на публикацию определенных строк или столбцов, и все подписчики получают одинаковые данные (за исключением трансформируемой подписки). С помощью динамических фильтров можно предоставлять разным подписчикам разные наборы данных, основываясь на функциях MS SQL Server (имя пользователя, имя узла).
Выводы
Таким образом, в главе рассмотрены вопросы несанкционированного проникновения в базы данных, угрозы нарушения состояния защищенности, а также способы и средства защиты базы данных на уровне СУБД Microsoft SQL Server, которые были применены на практике. Построенное таким образом необходимое звено защиты применено к производственной базе данных предприятия-заказчика.
4. Программный комплекс
Вторым уровнем, защиту которого необходимо реализовать является защита базы данных на уровне приложения, посредством которого организовано взаимодействие пользователя с базой данных (рисунок 4.1).
Рисунок 4.1 - Уровни защиты базы данных
В области прикладных систем политика информационной безопасности (далее ПИБ) предприятия предусматривает правила работы и реализации программного кода: пользователи прикладных систем, включая технический персонал, должны получать доступ к информационным ресурсам и функциям прикладных систем только в соответствии с принятой политикой контроля доступа, основанной на требованиях по доступу к информационным ресурсам и функциям и соответствующей общей политике контроля доступа. Для обеспечения контроля доступа к прикладным системам и информационным ресурсам в отношении прикладных систем должны быть выполнены требования[29,c.54]:
- должен присутствовать набор команд по контролю доступа к функциям прикладных систем;
- документация, представляемая пользователям должны содержать объем информации, необходимый пользователю для выполнения своих функций, без подробного описания всех функций прикладной системы;
- должен быть реализован контроль прав пользователей на уровне чтения, записи, уничтожения, исполнения;
- должно быть обеспечено, чтобы вывод конфиденциальной информации осуществлялся бы на соответствующем оборудовании вывода, и доступ к результатам вывода, например, распечатке, был разрешен только авторизованному на работу с данной информацией пользователю, вывод бы осуществлялся только на авторизованные терминалы. При этом периодически необходимо осуществлять контроль за выводимой информацией и ее последующем уничтожением.
Прикладные системы должны:
- Контролировать доступ пользователей к информации и функциям приложений с соответствиями с требованиями бизнеса и общей политикой контроля доступа;
- Обеспечивать защиту от несанкционированного доступа со стороны системных средств и утилит, которые могут быть использованы для обходя средств контроля доступа приложений;
- Не компрометировать прочие системы при совместном использовании информационных ресурсов;
Обеспечивать доступ к информации только для владельцев, других персонифицированных авторизованных пользователей или групп пользователей.
Если прикладная система не обеспечивает выполнение этих требований необходимо обеспечить контроль доступа к самой прикладной системе и ее ресурсам с использованием утилит СЗИ НСД и системных средств.
В соответствии с предъявляемыми требованиями был разработан программный комплекс «Корпоративный учет средств вычислительной техники».
4.1 Назначение программного комплекса
Приложение “Корпоративный учет средств вычислительной техники на предприятии” написано для интрасети и предназначено для ограниченного числа пользователей (только для сотрудников компании, имеющих непосредственное отношение к средствам вычислительной техники). При проектировании программного комплекса “Корпоративный учет средств вычислительной техники” акцент ставился именно на корпоративный принцип реализации задачи с учетом потребности в информации разных служб, задействованных в эксплуатации вычислительной техники. Сгруппирована информация как для материального и инвентарного учета, ремонтно-эксплуатационных технических служб, административная информация, а также справочные данные по основным техническим характеристикам средств ВТ.
Использование вышеуказанных технологий имеет низкие требования, как к автоматизированному рабочему месту клиента, так и к характеристикам сетевого подключения (скорость и устойчивость соединения). При этом вычислительная нагрузка распределяется между сервером приложений и сервером баз данных, а функцией клиентского компьютера является лишь отображение уже сформированных страниц интерфейса задачи.
В большинстве случаев для работы с задачей АРМ клиента не требует никаких предварительных инсталляций и настроек. Ниже приведены минимальные программно-технические требования к персональному компьютеру, исполняющему роль web-клиента (таблица 4.1).
Таблица 4.1 - Минимальные технические требования и программное обеспечение
|
Минимальные технические требования |
||
|
Процессор |
Pentium - 200 |
|
|
ОЗУ |
32 Mb - для Windows 9x и 64 Mb - для Windows NT, 2k, XP |
|
|
Винчестер |
800 Mb |
|
|
Монитор |
диагональ -15” / разрешение - 800 x 600 |
|
|
Сетевое / модемное подключение |
33 kb/s |
|
|
Требуемое программное обеспечение |
||
|
Операционная система |
MS Windows 9x, NT, 2k, XP |
|
|
Интернет обозреватель |
Internet Explorer версии 6.0 и выше (поставляется в составе Windows XP) |
|
|
Построитель отчетов |
Crystal Reports View версии 8.0 и выше (требуется только для формирования отчетов) |
Отличительные особенности определяемые выбранными средствами разработки:
· Авторизация при запуске задачи или при регистрации в Windows (Active Directory Windows);
· Организация гибкого управления правами доступа на уровне СУБД;
· Тонкий клиент (минимальные требования к техническим характеристикам ПК АРМ, операционной системе, не требует установки);
· Минимальные требования к скоростным характеристикам сети (возможность работы через модем);
· Соответствие стандартам SQL 92 и SQL 98 (можно использовать другие СУБД Oracle, InterBase, SyBase);
· Тюнинг многопроцессорных серверов - оптимальное распределение нагрузки на процессоры при работе с большими объемами информации;
· Масштабируемость - возможность изменять количество серверов в зависимости от загрузки.
Программный комплекс “Корпоративный учет средств вычислительной техники на предприятии” удовлетворяет следующим требованиям:
· целостности;
· конфиденциальности;
· доступности.
Решение же этих задач достигается за счет использования на прикладном уровне:
1. Ролевой доступ к данным. Пользователей задачи в зависимости от выполняемых функций можно разделить на группы определяющие права доступа к данным. Такие группы принято называть ролями. Пользователь может входить в несколько таких групп (выполнять несколько ролей). Администраторам задач предоставлены все права доступа к данным (просмотр, добавление, редактирование и удаление), кроме прав на работу(модификацию справочников) со справочниками типов устройств и технических характеристик. Остальные пользователи имеют права в соответствии с выполняемыми должностными обязанностями.
2. Централизованный материальный учет ВТ предприятия, в том числе и инвентарный, с возможностью предоставления необходимых исходных данных для соответствующего бухгалтерского учета.
3. Контроль целостности и сохранности данных.
4. Информационное отслеживание полного жизненного цикла средств ВТ:
· регистрация документов на приобретение и гарантийных данных;
· автоматизированный инвентарный учет с учетом требований СТП 525.585-2003;
· подробное описание технических характеристик (ТХ) моделей устройств различных типов;
· ведение истории перемещения единиц ВТ между структурными подразделениями предприятия и АРМ, а так же истории изменения атрибутов АРМ;
· регистрацией ремонтно-эксплуатационных событий (модернизация и списание);
· хранение информации о списанных устройствах в течение 5 лет (по умолчанию);
5. Предоставление информационно-справочной системы, позволяющей анализировать информацию по различным критериям.
6. Протоколирование действий пользователей и аудит состояния базы данных.
Это приложение требует защиты на прикладном уровне для идентификации авторизованных пользователей, предотвращения несанкционированного доступа, и соблюдения целостности данных. ASP.NET обеспечивает такую защиту, работая совместно со средствами IIS и подсистемой безопасности Windows, оно предоставляет надежный фундамент для построения защищенных приложений, при этом используются возможности IIS для того, чтобы максимально упростить создание и поддержку работы приложения [31, с.423].
4.2 Интерфейс пользователя
4.2.1 Авторизация пользователей
Стартовой страницей проекта является страница авторизации пользователей (рисунок 4.2), после прохождения которой, пользователь имеет допуск к данным в соответствии со своими правами доступа.
Рисунок 4.2 - Скриншот формы “Авторизация пользователя”
4.2.2 Главное меню
После успешного прохождения регистрации, пользователь наделен определенными правами доступа. Пользователь направляется на страницу «Главное меню» (рисунок 3).
Все режимы работы можно разделить на основные категории:
· авторизация необходима для определения прав доступа пользователя к определенным данным, в соответствии с ролевыми функциями пользователя в системе;
· ведение основных баз данных предоставляет возможность повседневного отслеживания информации по текущему состоянию парка ВТ и атрибутов АРМ, а также оперативно получать интерактивные справки с использованием заданных критериев выбора;
· ведение справочников - эта категория форм предоставляет возможность работать с относительно-постоянной информацией, используемой при формировании основных баз данных;
· журналы позволяют отследить хронологию жизненного цикла средств ВТ, а также изменения атрибутов автоматизированных рабочих мест;
· управление позволяет пользователям с соответствующим статусом изменять некоторые глобальные параметры задачи: такие как срок хранения информации по списанным устройствам; изменение паролей служебных учетных записей; задание ролевого доступа к данным пользователям с Windows-аутентификацией и т. д.;
· отчеты реализуются посредством использования Visual FoxPro, профессионального пакета для формирования отчетов Crystal Reports. Для формирования унифицированных отчетов используется также Microsoft Excel;
· выход из задачи завершает текущую сессию пользователя на сервере. Его необходимо выполнять в случае завершения работы с задачей или при необходимости зарегистрироваться с другими правами доступа к данным. Следует обратить внимание, что при обычном закрытии окна браузера этого не происходит и остается возможность несанкционированного доступа к данным, кроме того, закрытие сессии освобождает ресурсы сервера.
Группировка по указанным категориям прослеживается в главном меню задачи (рисунок 4.3).
Рисунок 4.3 - Скриншот формы “Главное меню”
4.2.3 Ведение БД перечня устройств средств ВТ
Ведение баз данных средств вычислительной техники является основной формой отображающей текущее состояние парка средств ВТ. Эта форма используется как для получения интерактивных справок, так и для внесения изменений в соответствующую БД (рисунок 4.4).
Заданием комбинаций условий определенных в режиме поиск-фильтр можно локализовать отображение перечня устройств по заданным критериям. Будут отображены только те записи, которые удовлетворяют всем заданным условиям. В форме всегда отображается не более 100 первых записей, даже если количество выбранных записей превышает это число.
Сортировка при отображении в форме выполняется по атрибутам “Тип устройства” и “Инвентарный номер”.
В правой части таблицы напротив каждой записи расположены пиктографические элементы управления, предназначенные для работы с выбранной записью. Краткое описание назначения каждой из пиктограмм определено в заголовке таблицы, но более подробно о выполняемых действиях при выборе элемента управления будет рассказано ниже.
Рисунок 4.4 - Скриншот формы “Ведение БД перечня устройств средств ВТ”
4.2.3.1 Информационные формы
Первые три столбца с пиктографическими элементами управления предназначены для вызова информационных форм. Это, соответственно, “Технические характеристики модели устройства”, “Дополнительной информации об устройстве”, журналы: “Использование в операциях по актам модернизации системных блоков” - для комплектующих и “Перемещения единиц ВТ” - для единиц ВТ.
- вызов формы отображающей технические характеристики модели соответствующего устройства (рисунок 4.5). Следует отметить, что перечень характеристик определяется типом устройства (HDD, FDD, CD и т. д.), а значения характеристик соответствуют модели выбранного устройства. Перечень характеристик для заданного типа устройств не является фиксированным и, в процессе эксплуатации задачи предусмотрена возможность расширять его, или же наоборот - удалять из перечня малоинтересные характеристики моделей.
Рисунок 4.5 - Скриншот формы технических характеристик модели выбранного устройства
- посредством этого элемента управления в зависимости от того, является ли выбранное устройство единицей ВТ или же комплектующим, вызываются соответственно формы журналов “Перемещения единицы ВТ” или же “Использование в операциях по актам модернизации системных блоков” (рисунок 4.6). В этих журналах отслеживается история использования выбранного устройства, по которой можно определить, где, кем и в какой момент использовалось соответствующее устройство.
При ведении журналов в рассматриваемой задаче квантом времени являются календарные сутки. Если какое-либо устройство было установлено, а затем изъято в течение одних и тех же суток, то операция изъятия будет считаться исправлением ошибочной установки и ни одной записи в журнале не появится. То же самое касается обратной последовательности - “изъятие / установка”.
Рисунок 4.6 - Скриншот формы “Журнал перемещений единицы ВТ”
- отображение формы дополнительной информации по выбранному устройству. Эта форма содержит практически всю доп. информацию, которая определена для конкретного экземпляра устройства. В случае если рассматриваемым устройством является системный блок, то здесь же отображается перечень комплектующих входящих в его состав (рисунок 4.7).
Рисунок 4.7- Скриншот формы «Дополнительная информации по экземпляру устройства»
4.2.3.2 Модификационные формы
К модификационным формам относятся формы добавления, редактирования, дублирования, удаления и списание устройств и форма компоновки системного блока.
Добавление нового устройства.
Вызов формы “Добавление нового устройства” выполняется посредством клавиши “Добавить устройство” расположенной в шапочной части формы “Ведение БД средств ВТ” (рисунок 4.4). Форма представлена на рисунке 4.8. Заполнение реквизитов рекомендуется выполнять в той последовательности, в которой они следуют в форме (сверху вниз) так как имеются иерархически-взаимосвязанные поля это “Тип устройства”, “Фирма-производитель” и “Модель устройства”. Эти атрибуты и атрибут “Фирма-поставщик” выбираются только из соответствующих справочников. При отсутствии в предложенных списках необходимых данных требуется занести информацию в соответствующие справочники. После этого они появятся в списках и могут быть использованы также и для добавления других экземпляров устройств.
Следует обратить внимание, что модификация справочника типов устройств является очень редким событием и в тоже время ответственным, так как определяет такие параметры устройства как “Перечень технических характеристик” и является базовым для перечня моделей устройств соответствующего типа. На использовании этих данных строятся отчеты, которые могут быть нарушены при удалении каких-либо важных параметров, например, таких как “частота процессора” или “Объем ОЗУ”. По этой причине разработчик задачи оставляет только за собой право модифицировать справочники типов устройств и перечня технических характеристик по первому требованию администратора базы данных.
Подобные документы
- Создание защищенного приложения для ведения учета продаж и закупок, ориентированного на малый бизнес
Проектирование модели базы данных в соответствии с предметной областью "Торговля". Разработка архитектуры системы безопасности приложения по ведению базы данных. Реализация приложения, обеспечивающего учет продаж и закупок предприятия. Способы его защиты.
дипломная работа [2,5 M], добавлен 05.02.2017 Проектирование и создание информационной базы данных для управления предприятием "Завод металлоизделий". Данные для базы, предметная область, атрибуты объектов базы данных. Объектные отношения, их ключи, связи объектов и отношений базы данных предприятия.
реферат [26,9 K], добавлен 04.12.2009Схема взаимодействия подразделений предприятия. Выбор и обоснование технологии проектирования базы данных. Описание объектов базы данных. Разработка запросов на выборку, изменение, обновление и удаление данных. Интерфейсы взаимодействия с базой данных.
курсовая работа [1,4 M], добавлен 25.05.2023Предпосылки создания системы безопасности персональных данных. Угрозы информационной безопасности. Источники несанкционированного доступа в ИСПДн. Устройство информационных систем персональных данных. Средства защиты информации. Политика безопасности.
курсовая работа [319,1 K], добавлен 07.10.2016Законодательные основы защиты персональных данных. Классификация угроз информационной безопасности. База персональных данных. Устройство и угрозы ЛВС предприятия. Основные программные и аппаратные средства защиты ПЭВМ. Базовая политика безопасности.
дипломная работа [2,5 M], добавлен 10.06.2011Разработка базы данных для информационной поддержки деятельности аптеки с целью автоматизированного ведения данных о лекарствах аптеки. Проектирование схемы базы данных с помощью средства разработки структуры базы данных Microsoft SQL Server 2008.
курсовая работа [3,6 M], добавлен 18.06.2012Разработка приложения, позволяющего автоматизировать документооборот предприятия по списанию основных средств. Мероприятия по защите и обеспечению целостности базы данных. Разработка клиентского приложения. Запросы к базе данных, руководство пользователя.
курсовая работа [700,0 K], добавлен 14.01.2015Определение понятия и общее описание базы данных как упорядоченной информационной системы на носителе информации. Описание предметной области и разработка приложения базы данных, содержащей информацию о расписании занятий, для преподавателей кафедры.
курсовая работа [1,3 M], добавлен 08.08.2012Создание базы данных для небольшого предприятия, занимающегося ремонтом бытовой техники. Анализ и характеристика предметной области, входных и выходных данных. Разработка конфигурации в системе "1С:Предприятие 8.2" и функциональной части приложения.
контрольная работа [2,4 M], добавлен 26.05.2014Описание предметной области разрабатываемой базы данных для теннисного клуба. Обоснование выбора CASE-средства Erwin 8 и MS Access для проектирования базы данных. Построение инфологической модели и логической структуры базы данных, разработка интерфейса.
курсовая работа [3,8 M], добавлен 02.02.2014
