Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Введение

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

обеспечивать получение общих и/или детализированных отчетов по итогам работы;

позволять легко определять тенденции изменения важнейших показателей;

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

выполнять точный и полный анализ данных.

Современные СУБД в основном являются приложениями Windows, так как данная среда позволяет более полно использовать возможности персональной ЭВМ, нежели среда DOS. Снижение стоимости высокопроизводительных ПК обусловил не только широкий переход к среде Windows, где разработчик программного обеспечения может в меньше степени заботиться о распределении ресурсов, но также сделал программное обеспечение ПК в целом и СУБД в частности менее критичными к аппаратным ресурсам ЭВМ. Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер».

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

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

Ограничение обновления определенных атрибутов с целью сохранения требуемых пропорций между их старыми и новыми значениями;

Ограничения, требующие сохранение значений поля показателя в некотором диапазоне;

Ограничения, связанные с заданными функциональными зависимостями.

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

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

Защита информации . Понятие защиты информации

защита информация несанкционированный доступ

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

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

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

Основными критериями оценки надежности являются: политика безопасности и гарантированность.

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

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

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

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

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

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

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

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

Защита ПК от несанкционированного доступа

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

1) подавляющая часть ПК располагается непосредственно в рабочих комнатах специалистов, что создает благоприятные условия для доступа к ним посторонних лиц;

2) многие ПК служат коллективным средством обработки информации, что обезличивает ответственность, в том числе и за защиту информации;

3) современные ПК оснащены несъемными накопителями на ЖМД очень большой емкости, причем информация на них сохраняется даже в обесточенном состоянии;

4) накопители на ГМД производятся в таком массовом количестве, что уже используются для распространения информации так же, как и бумажные носители;

5) первоначально ПК создавались именно как персональное средство автоматизации обработки информации, а потому и не оснащались специально средствами защиты от НСД.

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

Основные механизмы защиты ПК от НСД могут быть представлены следующим перечнем:

1) физическая защита ПК и носителей информации;

2) опознавание (аутентификация) пользователей и используемых компонентов обработки информации;

3) разграничение доступа к элементам защищаемой информации;

4) криптографическое закрытие защищаемой информации, хранимой на носителях (архивация данных);

5) криптографическое закрытие защищаемой информации в процессе непосредственной ее обработки;

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

Защита информации в базах данных

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

Эти два подхода отличаются следующими свойствами:

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

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

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

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

Привилегии или полномочия пользователей или групп -- это набор действий (операций), которые они могут выполнять над объектами БД.

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

Пользователю может быть назначена одна или несколько ролей.

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

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

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

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

СУБД в своих системных каталогах хранит как описание самих пользователей, так и описание их привилегий по отношению ко всем объектам.

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

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

В стандарте SQL определены два оператора: GRANT и REVOKE соответственно предоставления и отмены привилегий.

Оператор предоставления привилегий имеет следующий формат:

GRANT {<список действий | ALL PRIVILEGES }

ON <имя_объекта> ТО (<имя_пользователя> ] PUBLIC }

Здесь список действий определяет набор действий из общедопустимого перечня действий над объектом данного типа.

Параметр ALL PRIVILEGES указывает, что разрешены все действия из допустимых для объектов данного типа.

<имя_обьекта> -- задает имя конкретного объекта: таблицы, представления, хранимой процедуры, триггера.

<имя_пользователя> или PUBLIC определяет, кому предоставляются данные привилегии.

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

Рассмотрим пример, пусть у нас существуют три пользователя с абсолютно уникальными именами userl, user2 и user3. Все они являются пользователями одной БД.

User1 создал объект Таb1, он является владельцем этого объекта и может передать права на работу с эти объектом другим пользователям. Допустим, что пользователь user2 является оператором, который должен вводить данные в Таb1 (например, таблицу новых заказов), а пользователь user 3 является большим начальником (например, менеджером отдела), который должен регулярно просматривать введенные данные.

Для объекта типа таблица полным допустимым перечнем действий является набор из четырех операций: SELECT, INSERT, DELETE, UPDATE. При этом операция обновление может быть ограничена несколькими столбцами.

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

GRANT {[.INSERT][,DELETED[.UPDATE (<список столбцов>)]} ON <имя таблицы>

ТО {<имя_пользователя> PUBLIC }

Тогда резонно будет выполнить следующие назначения:

ТО user2 GRANT SELECT

Эти назначения означают, что пользователь user2 имеет право только вводить новые строки в отношение Таb1> а пользователь user3 имеет право просматривать все строки в таблице Таb1.

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

GRANT SELECT. UPDATE (COST) ON Tab1 TO user3

Если наш пользователь user1 предполагает, что пользователь user4 может его замещать в случае его отсутствия, то он может предоставить этому пользователю все права по работе с созданной таблицей Таb1.

GRANT ALL PRIVILEGES

TO user4 WITH GRANT OPTION

В этом случае пользователь user4 может сам назначать привилегии по работе с таблицей Таb1 в отсутствие владельца объекта пользователя user1. Поэтому в случае появления нового оператора пользователя user5 он может назначить ему права на ввод новых строк в таблицу командой

ON Tab1 TO user5

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

GRANT SELECT. UPDATE. DELETE

TO user4 WITH GRANT OPTION,

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

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

Так как представления могут соответствовать итоговым запросам, то для этих представлений недопустимы операции изменения, и, следовательно, для таких представлений набор допустимых действий ограничивается операцией SELECT. Если же представления соответствуют выборке из базовой таблицы, то для такого представления допустимыми будут все 4 операции: SELECT, INSERT, UPDATE и DELETE.

Для отмены ранее назначенных привилегий в стандарте SQL определен оператор REVOKE. Оператор отмены привилегий имеет следующий синтаксис:

REVOKE {<список операций | ALL PRIVILEGES} ON <имя_объекта>

FROM {<список пользователей | PUBLIC } {CASCADE | RESTRICT }

Параметры CASCADE или RESTRICT определяют, каким образом должна производиться отмена привилегий. Параметр CASCADE отменяет привилегии не только пользователя, который непосредственно упоминался в операторе GRANT при предоставлении ему привилегий, но и всем пользователям, которым этот пользователь присвоил привилегии, воспользовавшись параметром WITH GRANT OPTION.

Например, при использовании операции:

REVOKE ALL PRIVILEGES - ON Tab1 TO user4 CASCADE

будут отменены привилегии и пользователя user5, которому пользователь user4 успел присвоить привилегии.

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

REVOKE ALL PRIVILEGES ON Tab1 TO user4 RESTRICT

не будет выполнена, потому что пользователь user4 передал часть своих полномочий пользователю user5.

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

Поэтому корректным будет следующее использование оператора REVOKE:

REVOKE INSERT ON Tab! TO user2.user4 CASCADE

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

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

Если вы хотите изменить это условие, то после создания хранимой процедуры необходимо записать оператор REVOKE.

REVOKE EXECUTE ON COUNT_EX TO PUBLIC CASCADE И теперь мы можем назначить новые права пользователю user4.

GRANT EXECUTE ON COUNT_EX TO user4

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

GRANT CREATE TABLE. ALTER TABLE, DROP TABLE ON OB_LIB TO user1

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

В некоторых СУБД пользователь может получить права создавать БД. Например, в MS SQL Server системный администратор может предоставить пользователю main_user право на создание своей БД на данном сервере. Это может быть сделано следующей командой:

GRANT CREATE DATABASE

ON SERVERJ) TO main user

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

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

Реализация защиты в некоторых СУБД

Архитектура защиты Access. Если у вас имеется опыт работы с защитой, используемой на сервере или большой ЭВМ, структура защиты в Access покажется вам знакомой. Вы можете указать пользователей, которым предоставляется или, наоборот, не разрешается доступ к объектам базы данных. Кроме того, вы можете определить группы пользователей и назначить разрешения на уровне группы, чтобы облегчить построение защиты для большого числа пользователей. Пользователю достаточно быть членом группы, чтобы получить права доступа, установленные для неё.

Access хранит информацию о защите в двух местах. Во время установки программа Setup создаст в папке \Program Files\Microsoft Ofice\0ffice стандартный файл рабочей группы (System.mdw), который впоследствии используется по умолчанию при запуске Access. Этот файл содержит информацию обо всех пользователях и группах. При создании базы данных Access сохраняет сведения о правах, предоставляемых конкретным пользователям и группам, в файле базы данных.

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

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

Каждая рабочая группа имеет уникальный внутренний идентификатор, генерируемый Access при определении файла рабочих групп. Любая база данных, созданная пользователем рабочей группы, «принадлежит» как этому пользователю, так и рабочей группе. Каждый пользователь и группа также имеет уникальный внутренний идентификатор, но можно дублировать один и тот же код пользователя и группы в нескольких рабочих группах.

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

Организация защиты

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

Говоря о симметричной архитектуре, операции резервного копирования и восстановления могут распараллеливаться на несколько потоков и выполняться одновременно, используя преимущества асинхронного ввода/вывода. На каждое резервное устройство отводится свой поток. Параллельное резервное копирование поддерживает до 32 одновременных резервных устройств (backup devices), что позволяет быстро создавать страховочные копии баз данных даже очень большой емкости. Возможность резервного копирования и восстановления отдельных таблиц, о чем мы упоминали, рассматривая Transact-SQL, позволяет экономить место и время, не выполняя копирование всей базы ради только некоторых ее объектов. Однако резервное копирование отдельной таблицы требует наложения на нее блокировки exclusive в отличие от резервного копирования всей базы или журнала транзакций, которые могут выполняться независимо от степени активности пользователей. Резервным копиям может быть назначен предельный срок хранения или дата утраты актуальности, до наступления которой место, занятое на устройстве этими копиями, не может использоваться для размещения других резервных копий при инициализации устройства. В качестве резервных устройств могут также применяться временные устройства, не входящие в состав базы и не имеющие записей в системной таблице sysdevices:

DECLARE @tomorrow char(8)

SELECT @tomorrow = CONVERT(char(8), DATEADD(dd, 1, GETDATE()) , 1)

DUMP DATABASE pubs

TO DISK = "\\ntalexeysh\disk_d\sql_experiments\pubs.dmp"

WITH INIT, EXPIREDATE=@tomorrow, STATS

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

Как правило, резервное копирование базы данных организуется с меньшей частотой, чем журнала транзакций. Например, сохранение журнала транзакций выполняется ежедневно, а страховая копия всей базы может делаться раз в неделю, так как архивирование журнала транзакций происходит значительно быстрее по времени и занимает меньше места, чем дамп целой базы. В отличие от резервирования базы данных дамп журнала транзакций очищает его неактивную часть, т. е. все завершившиеся (зафиксированные или абортированные) с момента последнего дампа транзакции, если только не использована опция NO_TRUNCATE. Команда DUMP TRANSACTION TRUNCATE_ONLY, очищающая журнал транзакций, полезна в случае его переполнения, которое можно контролировать, например, оператором DBCC SQLPERF (LOGSPACE). Если степень переполнения журнала очень высока, можно при его очистке отказаться от журналирования факта самого этого события: DUMP TRANSACTION NO_LOG. Если резервное копирование транзакций не представляет интереса, можно включить опцию очистки последних завершенных транзакций в базе по наступлению события checkpoint. Cмысл механизма checkpoint состоит в периодической записи данных из кэша на диск, чтобы не допускать грязных данных. Такого рода события постоянно генерируются MS SQL Server или возникают по инициативе пользователя. Включенная опция truncate log on checkpoint гарантирует выполнение с определенной частотой обработчиком события действий, приблизительно эквивалентных команде DUMP TRANSACTION TRUNCATE_ONLY.

При восстановлении журнала транзакций соответствующие транзакции применяются к базе данных. Это означает, что если в начале недели была сделана резервная копия всей базы, а потом ежедневно архивировались транзакции за каждый день, то при необходимости восстановления поднимается состояние базы на начало недели и на него последовательно накатываются дампы журнала транзакций за все дни, предшествующие моменту восстановления. MS SQL Server 6.5 имеет возможность восстановления данных из журнала транзакций на произвольный момент времени (разумеется, отраженный в журнале) при помощи команды LOAD TRANSACTION STOPAT или в окне database backup and restore выбором опции until time. Все содержащиеся в этом дампе транзакции, отмеченные завершившимися после этого момента, будут откачены.

Возможность планирования задач резервного копирования во времени и отсылки сообщений по e-mail в случае успешного/неуспешного завершения рассматривалась нами при обсуждении SQL Executive.

MS SQL Server 6.5 предусматривает возможность зеркалирования устройств, переключения на зеркальные устройства в качестве основных, выключения зеркалирования и уничтожения зеркального устройства также "на лету", т. е. без остановки штатной работы сервера по обслуживанию пользовательских запросов. Зеркалирование и дуплексирование устройств для работы с MS SQL Server может быть также выполнено средствами Windows NT, а также на аппаратном уровне (поддержка различных RAID-систем и т. д.). По-видимому, следует предполагать, что реализация первого этапа кластерной технологии WolfPack будет поддерживать MS SQL Server 6.5 в отказоустойчивых кластерах из двух узлов. Появление следующей версии MS SQL Server должно обеспечить работу серверов в кластере как единого виртуального сервера.

Transfer Manager используется для экспорта/импорта объектов и данных БД на MS SQL Server между разными аппаратными платформами, например между процессорами Intel и Alpha, а также между разными версиями MS SQL Server, в частности из более ранних в более поздние или между равноценными (имеются в виду 4.х и 6.х). Очень часто проектирование объектов базы ведется с помощью различных графических средств, но проектная документация может требовать структуру объектов с точностью до операторов DDL. Для получения скриптов, описывающих создание отдельного объекта базы данных, можно использовать команду transfer из контекстного меню объекта или выбрать соответствующий класс и имя объекта в Transfer Manager. Кроме этого, содержимое данных может быть выгружено/загружено при помощи утилиты bcp (см. табл. 1).

Вопросы безопасности доступа

Говоря о преимуществах интеграции с операционной системой, MS SQL Server использует в своей работе сервисы безопасности Windows NT. Напомним, что Windows NT на сегодня сертифицирована по классам безопасности С2/Е3. MS SQL Server может быть настроен на работу в одном из трех режимах безопасности. Интегрированный режим предусматривает использование механизмов аутентификации Windows NT для обеспечения безопасности всех пользовательских соединений. В этом случае к серверу разрешаются только трастовые, или аутентифицирующие, соединения (named pipes и multiprotocol). Администратор имеет возможность отобразить группы пользователей Windows NT на соответствующие значения login id MS SQL Server при помощи утилиты SQL Security Manager. В этом случае при входе на MS SQL Server login name и пароль, переданные через DB-Library или ODBC, игнорируются. Стандартный режим безопасности предполагает, что на MS SQL Server будут заводиться самостоятельные login id и соответствующие им пароли. Смешанный режим использует интегрированную модель при установлении соединений по поименованным каналам или мультипротоколу и стандартную модель во всех остальных случаях.

MS SQL Server обеспечивает многоуровневую проверку привилегий при загрузке на сервер. Сначала идентифицируются права пользователя на установление соединения с выбранным сервером (login name и пароль) и выполнение административных функций: создание устройств и баз данных, назначение прав другим пользователям, изменение параметров настройки сервера и т.д. Максимальными правами обладает системный администратор. На уровне базы данных каждый пользователь, загрузившийся на сервер, может иметь имя пользователя (username) базы и права на доступ к объектам внутри нее. Имеется возможность отобразить нескольких login id на одного пользователя базы данных, а также объединять пользователей в группы для удобства администрирования и назначения сходных привилегий. По отношению к объектам базы данных пользователю могут быть назначены права на выполнение различных операций над ними: чтение, добавление, удаление, изменение, декларативная ссылочная целостность (DRI), выполнение хранимых процедур, а также права на доступ к отдельным полям. Если этого недостаточно, можно прибегнуть к представлениям (views), для которых сказанное остается справедливым. Наконец, можно вообще запретить пользователю непосредственный доступ к данным, оставив за ним лишь права на выполнение хранимых процедур, в которых будет прописан весь сценарий его доступа к базе. Хранимые процедуры могут создаваться с опцией WITH ENCRYPTION, которая шифрует непосредственный текст процедуры, хранящийся обычно в syscomments. Права на выполнение некоторых команд (создание баз, таблиц, умолчаний, правил, представлений, процедур, резервное копирование баз и журналов транзакций) не являются объектно-специфичными, поэтому они назначаются системным администратором сервера или владельцем (создателем) базы данных при редактировании базы данных. Администрирование пользовательских привилегий обычно ведется в SQL Enterprise Manager, тем не менее в Transact-SQL имеются хранимые процедуры (sp_addlogin, sp_password, sp_revokelogin, sp_addalias, sp_adduser) и операторы (GRANT, REVOKE), которые позволяют осуществлять действия по созданию пользователей, назначению и отмене прав при выполнении скриптов. Дополнительную возможность администрирования привилегий предоставляют рассмотренные нами выше SQL-DMO.

Управление доступом

Система безопасности SQL Server имеет несколько уровней безопасности:

* операционная система;

* база данных;

* объект базы данных.

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

* системный администратор, имеющий неограниченный доступ;

* владелец БД, имеющий полный доступ ко всем объектам БД;

* владелец объектов БД;

* другие пользователи, которые должны получать разрешение на доступ к объектам БД.

Модель безопасности SQL Server включает следующие компоненты:

* тип подключения к SQL Server;

* пользователь базы данных;

* пользователь (guest);

* роли (roles).

Тип подключения к SQL Server

При подключении (и в зависимости от типа подключения) SQL Server поддерживает два режима безопасности:

* режим аутентификации Windows NT;

* смешанный режим аутентификации.

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

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

Пользователи базы данных

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

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

Права доступа

Для управления правами доступа в SQL Server используются следующие команды:

* GRANT. Позволяет выполнять действия с объектом или, для команды -- выполнять ее;

* REVOKE. Аннулирует права доступа для объекта или, для команды -- не позволяет выполнить ее;

* DENY. He разрешает выполнять действия с объектом (в то время, как команда REVOKE просто удаляет эти права доступа).

Объектные права доступа позволяют контролировать доступ к объектам в SQL Server, предоставляя и аннулируя права доступа для таблиц, столбцов, представлений и хранимых процедур. Чтобы выполнить по отношению к некоторому объекту некоторое действие, пользователь должен иметь соответствующее право доступа. Например, если пользователь хочет выполнить оператор SELECT * FROM table, то он должен и меть права выполнения оператора SELECT для таблицы table.

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

CREATE DATABASE -- право создения базы данных;

CREATE DEFAULT -- право создшия стандартного значения для столбца таблицы;

CREATE PROCEDURE -- право содания хранимой процедуры.

CREATE ROLE -- право создания гоавила для столбца таблицы;

CREATE TABLE -- право создания таблицы;

CREATE VIEW -- право создания представления;

BACKUP DATABASE -- право создшия резервной копии;

BACKUP TRANSACTION -- праве создания резервной копии журнала транзакций.

Роли

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

* роли уровня сервера;

* роли уровня базы данных.

Роли уровня сервера

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

В SQL Server существуют следующие типы ролей уровня сервера:

Sysadmin -- дает право выполнить любое действие в SQL Server;

Serveradmin -- дает право изменить параметры SQL Server и завершить его работу;

Setupadmin -- дает право инсталлировать систему репликации и управлять выполнением расширенных хранимых процедур;

Securityadmin -- дает право контролировать параметры учетных записей для подключения к серверу и предоставлять права доступа к базам данных;

Processadmin -- дает право управлять ходом выполнения процессов в SQL Server;

Dbcreator -- дает право создавать и модифицировать базы данных;

Diskadmin -- дает право управлять файлами баз данных на диске.

Роли уровня базы данных

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

В SQL Server существует три типа ролей:

* заранее определенные роли;

* определяемые пользователем роли;

* неявные роли.

Заранее определенными являются стандартные роли уровня БД. Эти роли имеет каждая база данных SQL Server. Они позволяют легко и просто передавать обязанности.

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

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

db_accessadmin -- осуществляет контроль за доступом к базе данных путем добавления или удаления пользователей в режимах аутентификации;

db_datareader -- определяет полный доступ к выборке данных (с помощью оператора SELECT) из любой таблицы базы данных. Запрещает выполнение операторов INSERT, DELETE и UPDATE для любой таблицы БД;

db_datawriter -- разрешает выполнять операторы INSERT, DELETE и UPDATE для любой таблицы базы данных. Запрещает выполнение оператора SELECT для любой таблицы базы данных;

db_ddladmin -- дает возможность создавать, модифицировать и удалять объекты базы данных;

db_securityadmin -- управляет системой безопасности базы данных, а также назначением объектных и командных разрешений и ролей для базы данных;

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

db_denydatareader -- отказ в разрешении на выполнение оператора SELECT для всех таблиц базы данных. Позволяет пользователям изменять существующие структуры таблиц, но не позволяет создавать или удалять существующие таблицы;

db_denydatawriter -- отказ в разрешении на выполнение операторов модификации данных (INSERT, DELETE и UPDATE) для любых таблиц базы данных;

public -- автоматически назначаемая роль сразу после предоставления права доступа пользователя к БД.

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

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

* стандартная роль;

* роль уровня приложения.

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

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

Системный анализ - это применение системного подхода при обработке конкретной информации и принятию решений. Рассмотренные принципы системного подхода являются и принципами системного анализа.

Их дополняют следующие специфические принципы:

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

* необходимо рассматривать лишь те цели, вероятность достижения которых р>р0 за время t

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

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

Безопасность данных в Oracle 7

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

Огромным шагом вперед в обеспечении безопасности данных стало введение ролей в Oracle7. До Oracle7 каждому пользователю приходилось явно предоставлять права доступа к каждому объекту базы данных, который ему разрешено было использовать. Этот процесс упрощается за счет того, что доступ к совокупности объектов предоставляется роли, а затем право на использование этой роли предоставляется соответствующим лицам. С помощью команды GRANT мы можем предоставить пользователям право выполнять над объектами БД (например, над таблицами) операции SELECT, INSERT, UPDATE и DELETE. Однако само по себе это не обеспечивает значительной гибкости. Мы можем ограничить доступ пользователей частями таблицы, разделив ее по горизонтали (ограничив пользователя определенными строками), по вертикали (ограничив его определенными столбцами) или и по горизонтали, и по вертикали. Как это сделать?

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

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

CREATE VIEW vjpayroll AS SELECT id

Payment_period FROM payroll WHERE dept = (SELECT dept

FROM mysys_users WHERE username = USER) WITH CHECK OPTION;

Столбец SALARY в этом примере не включен в представление, поэтому зарплату в нем увидеть нельзя, а фраза WHERE гарантирует, что пользователи смогут запрашивать данные из таблицы PAYROLL только по своему отделу.

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

Примечание

Вряд ли представление V_PAYROLL будет обновляемым, потому что к столбцу SALARY почти наверняка применено ограничение NOT NULL. Тем не менее, мы рекомендуем использовать опцию WITH CHECK OPTION во всех ограничивающих представлениях, так как в версии 7.3 значительно увеличилось число обновляемых представлений.

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

Использование пакетов

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

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

Пример построения пакета для обеспечения безопасности доступа к данным

CREATE OR REPLACE PACKAGE k_payroll AS my_dept payroll.dept%TYPE; mgr BOOLEAN;

PROCEDURE del (p_emp_id INTEGER);

PROCEDURE ins (p_emp_id INTEGER, p_name VARCHAR2

P_dept INTEGER, p_payment_period VARCHAR2

P_salary INTEGER);

PROCEDURE upd (p_emp__id INTEGER, p_name VARCHAR2

P_payment_penod VARCHAR2 ,p_salary INTEGER);

/CREATE OR REPLACE PACKAGE BODY k_payroll AS

mgr_flag payroll.mgr_flag%TYPE;

FROM mysys_users

WHERE username = USER;

FUNCTION checkdept (p_emp_id INTEGER) RETURN BOOLEAN IS

dept payroll.dept%TYPE;

CURSOR cjpayroll IS

FROM payroll pay

WHERE id = p_emp_id;

OPEN c_payroll ;

FETCH cjpayroll INTO dept;

CLOSE c_payroll;

IF dept <> my_dept THEN

PROCEDURE del (p_emp_id INTEGER) IS

Удалять сотрудников могут только начальники их отделов

Записи таблицы Payroll

IF checkdept(p_emp_id) AND mgr THEN

WHERE id = p_emp_id;

raise_application_error (-20001, "Insufficient Privilege"); END IF;

Подобные документы

Необходимость и потребность в защите информации. Виды угроз безопасности информационных технологий и информации. Каналы утечки и несанкционированного доступа к информации. Принципы проектирования системы защиты. Внутренние и внешние нарушители АИТУ.

контрольная работа , добавлен 09.04.2011

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

презентация , добавлен 09.12.2015

Характеристика основных способов защиты от несанкционированного доступа. Разработка политики безопасности системы. Проектирование программного обеспечения применения некоторых средств защиты информации в ОС. Содержание основных разделов реестра.

лабораторная работа , добавлен 17.03.2017

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

реферат , добавлен 16.03.2014

Современное развитие АСУ и защита информации. Функция системы защиты с тремя регистрами. Выбор механизмов защиты и их особенности. Ответственность за нарушение безопасности методов. Методы защиты режима прямого доступа. Требования к защите информации.

реферат , добавлен 29.10.2010

Методы и средства защиты информационных данных. Защита от несанкционированного доступа к информации. Особенности защиты компьютерных систем методами криптографии. Критерии оценки безопасности информационных компьютерных технологий в европейских странах.

контрольная работа , добавлен 06.08.2010

Пути несанкционированного доступа, классификация способов и средств защиты информации. Каналы утечки информации. Основные направления защиты информации в СУП. Меры непосредственной защиты ПЭВМ. Анализ защищенности узлов локальной сети "Стройпроект".

дипломная работа , добавлен 05.06.2011

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

реферат , добавлен 23.10.2011

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

дипломная работа , добавлен 19.04.2011

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

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

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

Парольная защита;

Шифрование данных и программ;

Установление прав доступа к объектам БД;

Защита полей и записей таблиц БД.

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

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

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

По отношению к таблицам в общем случае могут предусматриваться следующие права доступа.

Просмотр (чтение) данных;

Изменение (редактирование) данных;

Добавление новых записей;

Добавление и удаление данных;

Все операции, в том числе изменение структуры таблицы.

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

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

Полный запрет доступа;

Только чтение;

Разрешение всех операций (просмотр, ввод новых значений, удаление и изменение).

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

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

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

К дополнительным средствам защиты БД можно отнести такие, которые нельзя прямо отнести к средствам защиты, но которые непосредственно влияют на безопасность данных. Это следующие средства:

Встроенные средства контроля значений данных в соответствии с типами;

Повышения достоверности вводимых данных;

Обеспечения целостности связей таблиц;

Организации совместного использования объектов БД в сети.

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

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

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

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

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

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

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

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

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

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

Эти два подхода отличаются следующими свойствами:

Пользователю может быть назначена одна или несколько ролей.

В стандарте SQL определены два оператора: GRANT и REVOKE соответственно предоставления и отмены привилегий.

Оператор предоставления привилегий имеет следующий формат:

GRANT {<список действий | ALL PRIVILEGES }

ON <имя_объекта> ТО (<имя_пользователя> ] PUBLIC }

Параметр ALL PRIVILEGES указывает, что разрешены все действия из допустимых для объектов данного типа.

<имя_обьекта> -- задает имя конкретного объекта: таблицы, представления, хранимой процедуры, триггера.

<имя_пользователя> или PUBLIC определяет, кому предоставляются данные привилегии.

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

GRANT {[.INSERT][,DELETED[.UPDATE (<список столбцов>)]} ON <имя таблицы>

ТО {<имя_пользователя> PUBLIC }

Тогда резонно будет выполнить следующие назначения:

ТО user2 GRANT SELECT

GRANT SELECT. UPDATE (COST) ON Tab1 TO user3

GRANT ALL PRIVILEGES

TO user4 WITH GRANT OPTION

ON Tab1 TO user5

GRANT SELECT. UPDATE. DELETE

TO user4 WITH GRANT OPTION,

REVOKE {<список операций | ALL PRIVILEGES} ON <имя_объекта>

FROM {<список пользователей | PUBLIC } {CASCADE | RESTRICT }

Например, при использовании операции:

REVOKE ALL PRIVILEGES - ON Tab1 TO user4 CASCADE

будут отменены привилегии и пользователя user5, которому пользователь user4 успел присвоить привилегии.

REVOKE ALL PRIVILEGES ON Tab1 TO user4 RESTRICT

не будет выполнена, потому что пользователь user4 передал часть своих полномочий пользователю user5.

Поэтому корректным будет следующее использование оператора REVOKE:

REVOKE INSERT ON Tab! TO user2.user4 CASCADE

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

Если вы хотите изменить это условие, то после создания хранимой процедуры необходимо записать оператор REVOKE.

REVOKE EXECUTE ON COUNT_EX TO PUBLIC CASCADE И теперь мы можем назначить новые права пользователю user4.

GRANT EXECUTE ON COUNT_EX TO user4

GRANT CREATE TABLE. ALTER TABLE, DROP TABLE ON OB_LIB TO user1

GRANT CREATE DATABASE

ON SERVERJ) TO main user

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

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

Управление доступом к данным (владелец объекта передает права доступа к нему по своему усмотрению);

Механизм подотчетности всех действий, влияющих на безопасность;

Защита регистрационной информации от искажений и ее анализ;

Очистка объектов перед их повторным использованием;

Защита информации, передаваемой по линиям связи.

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

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

Существуют два специфических сценария атаки на СУБД:

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

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

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

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

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

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

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

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

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

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

Для поддержки безопасности баз данных разрабатывается множество продуктов. Среди них известны продукты фирм DBSecure и BrainTree Security Software. SQL Auditor DBSecure оценивает риски в базе данных Microsoft SQL Server, выявляет слабые пароли, нарушения режимов эксплуатации, загрузочные атаки и другие формы несанкционированного доступа. В пакете SQL Secure фирмы BrainTree управление безопасностью сосредоточено на единой консоли. Компонент Password Manager анализирует пароли на слабость, управляет процессом присвоения паролей и сроками их действия. Компонент Policy Manager помогает пользователям оценивать свои базы данных на соответствие стандартам безопасности.

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

для некоторых таблицы необходимо обеспечить выборочный доступ к ее столбцам;

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

Схема доступа к данным в реляционных СУБД базируется на принципах:

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

Объекты доступа – это элементы БД, доступом к которым можно управлять (разрешать или запрещать). Конкретный пользователь обладает конкретными правами доступа к конкретному объекту.

Привилегии (priveleges) – это операции, которые разрешено выполнять пользователю над конкретными объектами.

2.5.4.2. Механизм ролей в СУБД

Способы определения групп пользователей:

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

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

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

2.5.5. Защита информации в сетях

2.5.5.1. Общая характеристика сетевых атак

Классификация удаленных атак выполняется по различным критериям:

1. По характеру воздействия:

Пассивные – внешние, никак не влияют на работу вычислительной системы и на передаваемые данные (например, простое прослушивание);

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

2. По цели воздействия:

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

Угроза целостности – несанкционированный доступ к информации и возможность ее модификации;

Угроза отказа в обслуживании – нарушение работоспособности системы.

3. По моменту начала атаки:

По запросу от атакуемого объекта (DNS,ARP– запросы);

По наступлению ожидаемого события на атакуемом объекте (например, разрыв TCPсоединения);

Безусловные атаки – осуществляются немедленно и безотносительно к состоянию системы и атакуемого объекта.

4. По наличию обратной связи:

С обратной связью (на некоторые запросы, переданные на атакуемый объект, атакующему требуется получить ответ);

Без обратной связи.

5. По расположению субъекта атаки (источника атаки):

Внутрисегментное расположение источника;

Межсегментное.

6. По уровню OSI(МВОС)

2.5.5.2. Типовые угрозы безопасности

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

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

1. Анализ сетевого трафика – внутрисегментные пассивные угрозы раскрытия без обратной связи, применяемые на физическом или канальном уровне.

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

3. Внедрение ложного объекта:

а) навязывание ложного маршрута, возможно из-за наличия протоколов, позволяющих удаленно изменять маршрутизацию в Интернет (протоколы RIP, OSPF, ICMP, SNMP);

б) использование недостатков алгоритмов удаленного доступа (протокол TCP, DNS-запрос).

4. Отказ в обслуживании (DoS) - активное воздействие; безусловная; межсегментное и внутрисегментное; на транспортном и прикладном уровнях.

2.5.5.3. Типовые атаки в сетях TCP/IP

Анализ трафика (sniffing)

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

Защита: шифрование данных; также можно шифровать файлы и обмениваться на файловом уровне; коммутация Ethernet (рисунок 7); выделенный канал связи между объектами РВС.

Ложный ARP сервер.

Связь между двумя удаленными хостами осуществляется путем передачи по сети сообщений, которые заключены в пакеты обмена. В поле данных помещаются либо непосредственно данные, либо другой пакет более высокого уровня OSI. Так, например, пакет транспортного уровня может быть вложен в пакет сетевого уровня, который, в свою очередь, вложен в пакет канального уровня. Спроецировав это утверждение на сетевую ОС, использующую протоколы TCP/IP, можно утверждать, что пакет TCP (транспортный уровень) вложен в пакет IP (сетевой уровень), который, в свою очередь, вложен в пакет Ethernet (канальный уровень). Таким образом, структура TCP-пакета выглядит так, как показано на рисунке 8.

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

а) ЭВМ посылает широковещательный (всем сразу) ARP-запрос с требуемымIP-адресом.

б) ЭВМ с затребованным адресом посылает на Ethernet-адрес автора запроса ответ с указанием своегоEthernet-адреса. Запрашиваемая ЭВМ получает ответ и записывает паруIPиEthernetадресов в свою локальнуюARPтаблицу.

Механизм атаки: hostатакующего посылает ложныйARPответ и в будущем будет получать все данные, адресованные на другой адрес (рисунок 9).

Ложный DNS-сервер

Ложный DNSработает следующим образом:

Hostпосылает запрос на определение адреса информационно поисковомуDNSсерверу.

Если домен локальный, то сервер сам отвечает на запрос, иначе отсылает запрос корневому DNSсерверу.

Корневой сервер определяет локальный сервер для домена и отсылает ответ ему.

На любом этапе ответы кэшируются сервером и клиентом.

Выделяют 3 сценария атаки:

1) Перехват запроса и попытка ложного ответа.

2) Шторм ложных DNS ответов от имени настоящего DNS сервера.

3) Шторм ложных DNS ответов на атакуемый DNS сервер.

Как видно из приведенных формулировок, идеи атак достаточно близки к идее ложного ARP-сервера. СлужбаDNSработает по протоколуUDP, который отличается отTCPтем, что не гарантирует установление соединения и доставку.

Первый сценарий проиллюстрирован рисунком 10. Атакующий должен находиться на пути основного трафика или в сегменте настоящего DNS сервера.

Рисунок 9. Атака путем использования ложного ARP-сервера

а – фаза ожидания ARP-запроса; б – фаза атаки; в – фаза приема, анализа, воздействия и передачи перехваченной информации на ложном ARP-сервере

Рисунок 10. Атака путем перехвата запроса к DNS-серверу

а – фаза ожидания DNS-запроса; б – фаза передачи атакующим ложного DNS-ответа; в – фаза приема, анализа, воздействия и передачи перехваченной информации на ложном DNS-сервере

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

Третий сценарий состоит в организации направленного потока ответов на DNS-сервер, в результате чего один из этих ответов сервер воспринимает как ответ на свой запрос и заносит его результаты, т.е.IP-адрес атакующего хоста, в свой кэш (рисунок 12).

использование файла hosts. (неудобный способ для большого количества машин);

использование протоколов ТСР вместо UDP;

для защищенности сети стараются избегать применения DNS – службы вообще.

Защита от Интернет-атак:

фильтры на входе и на выходе из сети, контроль маршрутов;

фиктивные адреса и шлюзы (socks,proxy);

использования TCP, а неUDP(named,NFS);

статические ARPиDNS;

шифрование трафика (IPSEC,SKIP,SSL,SSH);

туннелирование с шифрованием;

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

контроль за сообщениями CERTиCIAC(американские центры по компьютерной безопасности:www.cert.org иwww.ciac.org );

применение антивирусных средств (на почтовых серверах и в браузерах);

использование средств автоматизированного контроля безопасности (SATAN,SAFEsuite,RealSecure,JohnTheRipper,Orge).

Кроме того, для защиты от проникновения путем использования Web-приложений применяют следующие решения:

отключение Javaи всех видов языков сценариев, кромеJavaScript(не будут работать многие страницы);

применение онлайновых антивирусов (AVP);

выделение специальной ЭВМ для доступа в Интернет.

На сегодняшний день из технологий динамических страниц более-менее безопасными для клиентской ЭВМ в Интернете можно назвать только DHTML(HTML4.0) иJavaScript. Все остальное лучше отключить.

Рисунок 11. Атака путем организации шторма DNS-ответов от ложного сервера

а – фаза организации шторма ложных DNS-ответов; б – фаза получения атакуемым хостом DNS-ответа на свой запрос; в – фаза приема, анализа, воздействия и передачи перехваченной информации на ложном DNS-сервере

Рисунок 12. Атака путем организации шторма DNS-ответов на атакуемый DNS-сервер

а – фаза ожидания атакующим DNS-запроса от DNS-сервера (для ускорения атакующий генерирует необходимый DNS-запрос); б – фаза передачи атакующим ложного DNS-ответа на DNS-сервер; в – DNS-сервер выдает IP-адрес атакующего хоста в ответ на запросы

Стандарт Х.800 описывает основы безопасности в привязке к эталонной семиуровневой модели. Стандарт предусматривает следующие сервисы безопасности:

аутентификация (имеются в виду аутентификация партнеров по общению и аутентификация источника данных);

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

конфиденциальность данных - в Х.800 под этим названием объединены существенно разные вещи - от защиты отдельной порции данных до конфиденциальности трафика;

целостность данных – данный сервис подразделяется на подвиды в зависимости от того, что контролируется - целостность сообщений или потока данных, обеспечивается ли восстановление в случае нарушения целостности;

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

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

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

Базовые протоколы, наиболее полезные с точки зрения безопасности, включают в себя - Ipsec,DNSsec,S/MIME,X.509v3,TLSи ассоциированные с ними. Наиболее проработанными на сегодняшний день являются вопросы защиты наIP-уровне. Спецификации семействаIPsecрегламентируют следующие аспекты:

управление доступом;

контроль целостности на уровне пакетов;

аутентификация источника данных;

защита от воспроизведения;

конфиденциальность (включая частичную защиту от анализа трафика);

администрирование (управление криптографическими ключами).

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

Туннелирование может применяться как на сетевом, так и прикладном уровнях. Например, стандартизовано туннелирование для IР и двойное конвертование для почты Х.400.

На транспортном уровне аутентичность, конфиденциальность и целостность потоков данных обеспечиваются протоколом TLS(TransportLayerSecurity,RFC2246). Подчеркнем, что здесь объектом защиты являются не отдельные сетевые пакеты, а именно потоки данных (последовательности пакетов). Злоумышленник не сможет переупорядочить пакеты, удалить некоторые из них или вставить свои.

На основе TLSмогут строиться защищенные протоколы прикладного уровня. В частности, предложены спецификации для НТТР надTLS.

2.5.5.5. Архитектура механизмов защиты информации в сетях ЭВМ

В модели ВОС различают следующие основные активные способы несанкционированного доступа к информации:

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

переадресация сообщений (преднамеренное искажение адресных реквизитов);

модификация сообщений (преднамеренное искажение информационной части сообщения);

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

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

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

Аутентификация источника данных - подтверждение подлинности источника (абонента-отправителя) сообщения.

Управление доступом (разграничение доступа) - обеспечивает защиту от несанкционированного доступа к ресурсам, потенциально доступным посредством ВОС.

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

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

Засекречивание поля данных - обеспечивает конфиденциальность отдельных полей данных пользователя на всем соединении или в отдельном сервисном блоке данных.

Засекречивание трафика - препятствует возможности извлечения информации из наблюдаемого графика.

Целостность соединения с восстановлением - позволяет обнаружить попытки вставки, удаления, модификации или переадресации в последовательности сервисных блоков данных. При нарушении целостности предпринимается попытка ее восстановления.

Целостность соединения без восстановления.

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

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

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

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

Информирование о доставке – предоставляет отправителю информацию о факте получения данных адресатом.

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

взаимное опознавание (аутентификация) вступающих в связь абонентов сети;

обеспечение конфиденциальности циркулирующих в сети данных;

обеспечение юридической ответственности абонентов за передаваемые и принимаемые данные.

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