В современных СУБД поддерживается один из двух наиболее общих подходов к вопросу обеспечения безопасности данных: избирательный подход и обязательный подход. В обоих подходах единицей данных или «объектом данных», для которых должна быть создана система безопасности, может быть как вся база данных целиком, так и любой объект внутри базы данных.
Эти два подхода отличаются следующими свойствами:
В случае избирательного управления некоторый пользователь обладает различными правами (привилегиями или полномочиями) при работе с данными объектами. Разные пользователи могут обладать разными правами доступа к одному и тому же объекту. Избирательные права характеризуются значительной гибкостью.
В случае избирательного управления, наоборот, каждому объекту данных присваивается некоторый классификационный уровень, а каждый пользователь обладает некоторым уровнем допуска. При таком подходе доступом к определенному объекту данных обладают только пользователи с соответствующим уровнем допуска.
Для реализации избирательного принципа предусмотрены следующие методы. В базу данных вводится новый тип объектов БД -- это пользователи. Каждому пользователю в БД присваивается уникальный идентификатор. Для дополнительной защиты каждый пользователь кроме уникального идентификатора снабжается уникальным паролем, причем если идентификаторы пользователей в системе доступны системному администратору, то пароли пользователей хранятся чаще всего в специальном кодированном виде и известны только самим пользователям.
Пользователи могут быть объединены в специальные группы пользователей. Один пользователь может входить в несколько групп. В стандарте вводится понятие группы 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 требует хорошего знания как семантики принципов поддержки прав доступа, так и физической реализации этих возможностей.
База данных является ценным корпоративным ресурсом. Возможность доступа к данным, хранимым в ней, является необходимым условием для выполнения бизнес-процессов практически во всех сферах деятельности. Безвозвратная потеря данных подвергает бизнес серьезной опасности. Утраченные вычислительные ресурсы можно восстановить, а при отсутствии мер по защите и восстановлению утраченных данных, восстановить их невозможно. По оценкам некоторых исследователей технологий баз данных, среди компаний, пострадавших от катастроф и переживших крупную необратимую потерю корпоративных данных, около половины не смогли продолжить свою деятельность.
Разрушение и потеря данных в базе могут быть вызваны рядом причин:
· сбои оборудования;
· физические воздействия на аппаратные средства базы данных;
· стихийные бедствия;
· ошибки санкционированных пользователей;
· умышленные вредоносные действия несанкционированных пользователей или программ;
· программные ошибки СУБД или операционной системы;
· ошибки в прикладных программах;
· совместное выполнение конфликтных запросов пользователей и др.
Для обеспечения безопасности баз данных существуют следующие меры следующего уровня:
Меры законодательного уровня очень важны для обеспечения безопасности баз данных. К этому уровню можно отнести весь комплекс мер, направленных на создание и поддержание в обществе негативного (в том числе карательного) отношения к нарушениям и нарушителям безопасности.
Большинство людей не совершают противоправных действий потому, что это осуждается и/или наказывается обществом, и потому, что так поступать не принято.
Поскольку информационная безопасность вообще и безопасность баз данных в частности - это новая область деятельности, здесь важно не только запрещать и наказывать, но и научить, разъяснить, помочь. Общество должно осознать важность данной проблематики, понять основные пути решения соответствующих проблем. Государство может сделать это оптимальным образом. Здесь не нужно больших материальных затрат, требуются интеллектуальные вложения.
Базы данных, также как и компьютерные программы, приравниваются к литературным произведениям и при соблюдении ряда условий могут являться объектами авторского права, что предусмотрено в статье 7 «Закона об авторском праве Республики Беларусь». Если база данных признается объектом авторского права, то это означает, что ей предоставляется охрана гражданским, административным и уголовным законодательством, как и любому другому объекту авторского права. Авторское право на базу данных не связано с авторским правом на компьютерную программу, с помощью которой осуществлялся доступ к данным и их обработка.
Меры администратпивно- организационного уровня. Администрация организации должна сознавать необходимость поддержания режима безопасности и выделения на эти цели соответствующих ресурсов. Основой мер защиты административно-организационного уровня является политика безопасности и комплекс организационных мер.
К комплексу организационных мер относятся меры безопасности, реализуемые людьми. Можно выделить следующие группы организационных мер:
· управление персоналом;
· физическая защита;
· поддержание работоспособности;
· реагирование на нарушения режима безопасности;
· планирование восстановительных работ.
К мерам административно- организационного уровня относят инструкции и правила, которые должны учитываться при проектировании и эксплуатации базы данных. К таким средствам относятся, например, порядок регистрации персоны в качестве пользователя базы данных, правила запуска и останова СУБД, инструкции по использованию каждого инструмента СУБД или приложения и т.п. Для успешного использования СУБД всем пользователям необходимо предоставить документацию, регламентирующую их действия по работе с базой данных.
Программно-технический уровень обеспечивает в современных СУБД специальные средства для защиты баз данных, такие как защита паролем, шифрование данных, разграничение прав доступа. Во многих случаях этих средств оказывается недостаточно, и тогда используются разнообразные методы защиты, начиная от проектирования СУБД со встроенными механизмами защиты и заканчивая интеграцией СУБД со специальными программными продуктами по защите информации.
На практике же всегда нужно быть уверенным, что за компьютером находится пользователь, подлинность которого гарантирована.
Для подтверждения подлинности пользователя существуют три последовательные процессы:
· Идентификация -это процесс распознавания пользователя по его идентификатору (логин и пароль).
· Аутентификация - это процесс подтверждения достоверности идентификатора пользователя. Процесс может быть, например, реализована секретным выражением.
· Авторизация - предоставление пользователю только тех данных, на которые он имеет право, т. е. разграничение прав доступа.
Главное достоинство защиты с помощью логина и пароля – простота и привычность. Надежность парольной защиты основывается на хранении их в тайне. При использовании пароля желательно соблюдать следующие требования:
· пароль должен состоять из комбинации букв и цифр или специальных знаков;
· длина пароля должна быть не менее шести символов, пароль не должен содержать пробелы
· пароли должны часто изменяться.
При правильном использовании пароли могут обеспечить приемлемый для многих организаций уровень безопасности. Тем не менее, из-за уязвимости сохранения паролей в тайне в ряде случаев такой защиты оказывается недостаточно.
Разграничение прав доступа является необходимой функцией любой многопользовательской СУБД. Это достаточно гибкая и развитая система, позволяющая администратору баз данных настраивать права доступа пользователей в соответствии с их служебными обязанностями. Определение прав пользователя при доступе к базе данных должно производиться, исходя из принципа минимальных полномочий, необходимых для выполнения прямых должностных обязанностей. Практически все современные СУБД предоставляют набор базовых средств по управлению правами доступа. Как правило, поддерживаются такие концепции, как пользователи и группы, а также возможность предоставить этим пользователям и группам права доступа к определенным объектам базы данных. При этом многие СУБД имеют возможности не только предоставить доступ тому или иному пользователю, но и указать разрешенный тип доступа: что именно может делать конкретный пользователь с конкретными данными – от только чтения вплоть до реорганизации всей базы данных. Основными объектами безопасности в реляционной СУБД являются таблицы, представления и хранимые процедуры. В зависимости от типа объекта можно управлять правами на конкретные действия с ним. Например, в случае таблиц можно независимо управлять правами на чтение, добавление, удаление и изменение записей. В некоторых СУБД можно управлять доступом на уровне отдельного столбца представления или таблицы.
База данных может быть зашифрована и храниться на диске в зашифрованном виде.
Шифрование – это преобразование исходных данных по специальным алгоритмам в новое представление, скрывающее содержание исходной информации.
Дешифрование – это обратный шифрованию процесс. При шифровании базы данных ее файл кодируется и становится недоступным для просмотра информации с помощью служебных программ.
Возможны два режима работы с зашифрованными базами данных. Наиболее простым является режим, при котором информация дешифруется на внешнем носителе, с ней производятся необходимые действия, после чего для записи на внешней носитель информация снова зашифровывается. Достоинством такого режима является независимость функционирования средств шифрования и СУБД, которые работают последовательно друг за другом. В то же время сбой или отказ в системе может привести к тому, что на внешнем носителе часть базы данных останется записанной в незашифрованном виде.
Второй режим предполагает возможность выполнения СУБД запросов пользователей без дешифрования информации на внешнем носителе. Дешифрование производится в оперативной памяти непосредственно перед выполнением конкретных действий с данными. Такой режим возможен, если процедуры шифрования встроены в СУБД. При этом достигается высокий уровень защиты от несанкционированного доступа, но реализация режима связана с усложнением СУБД. Любое шифрование снижает уровень производительности СУБД.
данные в любой таблице для выборки и изменения должны быть доступны ограниченному кругу пользователей;
для некоторых таблицы необходимо обеспечить выборочный доступ к ее столбцам;
некоторым пользователя должен быть запрещен непосредственный (через запросы) доступ к таблицам, но разрешен доступ к этим же таблицам в диалоге с прикладной программой.
Схема доступа к данным в реляционных СУБД базируется на принципах:
СУБД от имени конкретного пользователя выполняет операции над базой данных в зависимости от того, обладает ли конкретный пользователь правами на выполнение конкретных операций над конкретным объектом БД.
Объекты доступа – это элементы БД, доступом к которым можно управлять (разрешать или запрещать). Конкретный пользователь обладает конкретными правами доступа к конкретному объекту.
Привилегии (priveleges) – это операции, которые разрешено выполнять пользователю над конкретными объектами.
2.5.4.2. Механизм ролей в СУБД
Способы определения групп пользователей:
один и тот же идентификатор используется для доступа к БД целой группы физических лиц (например, сотрудников одного отдела);
конкретному физическому лицу присваивается уникальный идеентификатор.
Применяется также смешанный способ, при котором хранится идентификатор группы и уникальный идентификатор пользователя. Чаще всего группа пользователей соответствует структурному подразделению организации. Привилегии устанавливаются не только для отдельных пользователей, но и для их групп.
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. Архитектура механизмов защиты информации в сетях ЭВМ
В модели ВОС различают следующие основные активные способы несанкционированного доступа к информации:
маскировка одного логического объекта под другой, обладающий большими полномочиями (ложная аутентификация абонента);
переадресация сообщений (преднамеренное искажение адресных реквизитов);
модификация сообщений (преднамеренное искажение информационной части сообщения);
блокировка логического объекта с целью подавления некоторых типов сообщений (выборочный или сплошной перехват сообщений определенного абонента, нарушение управляющих последовательностей и т. п.).
Перечень видов услуг, предоставляемых по защите информации, которые обеспечиваются с помощью специальных механизмов защиты:
Аутентификация равнозначного логического объекта (удостоверение подлинности удаленного абонента-получателя). Для аутентификации требуется, чтобы лежащий ниже уровень обеспечивал услуги с установлением соединения.
Аутентификация источника данных - подтверждение подлинности источника (абонента-отправителя) сообщения.
Управление доступом (разграничение доступа) - обеспечивает защиту от несанкционированного доступа к ресурсам, потенциально доступным посредством ВОС.
Засекречивание соединения - обеспечивает конфиденциальность всех сообщений, передаваемых пользователями в рамках данного соединения.
Засекречивание в режиме без установления соединения - обеспечивает конфиденциальность всех данных пользователя в сообщении (единственном сервисном блоке данных), передаваемом в режиме без установления соединения.
Засекречивание поля данных - обеспечивает конфиденциальность отдельных полей данных пользователя на всем соединении или в отдельном сервисном блоке данных.
Засекречивание трафика - препятствует возможности извлечения информации из наблюдаемого графика.
Целостность соединения с восстановлением - позволяет обнаружить попытки вставки, удаления, модификации или переадресации в последовательности сервисных блоков данных. При нарушении целостности предпринимается попытка ее восстановления.
Целостность соединения без восстановления.
Целостность поля данных в режиме с установлением соединения - обеспечивает целостность отдельного поля данных пользователя во всем потоке сервисных блоков данных.
Целостность поля данных в режиме без установления соединения - позволяет обнаружить модификацию выбранного поля в единственном сервисном блоке данных.
Целостность блока данных в режиме без установления соединения - обеспечивает целостность единственного сервисного блока данных при работе без установления соединения и позволяет обнаружить модификацию и некоторые формы вставки и переадресации.
Информирование об отправке данных – позволяет идентифицировать отправителя информации на стороне ее получателя.
Информирование о доставке – предоставляет отправителю информацию о факте получения данных адресатом.
Теоретически доказано, а практика защиты сетей подтвердила, что все перечисленные услуги могут быть обеспечены криптографическими средствами защиты, в силу чего эти средства и составляют основу всех механизмов защиты информации в ВС. Центральными при этом являются следующие задачи:
взаимное опознавание (аутентификация) вступающих в связь абонентов сети;
обеспечение конфиденциальности циркулирующих в сети данных;
обеспечение юридической ответственности абонентов за передаваемые и принимаемые данные.
Решение последней из названных задач обеспечивается с помощью так называемой цифровой (электронной) подписи.
Но пока наши законодатели спорят о проектах законов о коммерческой тайне и электронной торговле, в общественных местах - в переходах метро и даже на автостоянках, не говоря уж об Интернете, продолжают продаваться компакт-диски с разнообразными базами данных (БД). Выбор необычайно широк: за 40-60 долл. вам предложат БД МГТС (актуализация - январь 2003 г.), Единой государственной регистрации предприятий (полная информация о предприятиях, зарегистрированных в России в 2003 г.), сведения о прописке в Москве и Московской области, а подороже, за 110 долл., можно купить БД ВЭД и т. д. Слегка "залежалый товар", например, немного устаревшие данные об абонентах МТС (по состоянию на ноябрь 2002 г.), идет всего за 40 "у. е".
Вряд ли любому честному гражданину будет приятно обнаружить свои персональные данные на приобретенном таким способом компакт-диске. Ведь такой диск может легко купить не только "любознательный товарищ", но и так называемые криминальные структуры. Однако самое страшное, что реальных механизмов предотвращения кражи информации и доказательства преступления для наказания злоумышленников до настоящего времени практически не существовало. По данным авторов, на момент написания статьи решение, реализующее защиту данных под управлением СУБД Oracle 9i с помощью электронных ключей еToken, не имеет аналогов на мировом рынке защиты информации.
Суть метода состоит в применении штатных механизмов инфраструктуры открытых ключей и организации доступа пользователей к информации по предъявлению цифровых сертификатов Х.509, поддерживаемых средствами Oracle Advanced Security, в двух уровнях: для аутентификации в корпоративной сети (например, под управлением Microsoft Windows Server 2000/2003) и для доступа к конфиденциальным данным, которые обрабатываются и хранятся на серверах Oracle. Оба сертификата хранятся в персональном идентификаторе в виде USB-ключа или смарт-карты eToken.
Этот метод позволяет значительно снизить риски от потерь, связанных с человеческим фактором, и однозначно персонифицировать действия пользователей информационной системы, работающих с СУБД Oracle 9i.
Почему кражи информации случаются в самых разных организациях, даже в силовых ведомствах? Каковы предпосылки утечки данных, и надо ли обладать обширными знаниями и умением взломщика, чтобы преодолеть существующую защиту? Существуют ли способы построения систем защиты информации (СЗИ), позволяющие свести к минимуму риски потери данных? Можно ли защитить корпоративные данные от собственного системного администратора?
Все эти вопросы, связанные с защитой конфиденциальных данных на уровне СУБД, следует рассматривать с разных позиций, учитывая не только архитектуру баз данных и встроенные средства защиты, но и конфигурацию сети предприятия, его систему защиты, а также особенности работы клиентских станций.
Типовая модель защиты доступа пользователя к корпоративным данным и приложениям включает в себя четыре элемента:
Поскольку организационные меры и механизмы ограничения доступа к корпоративной сети подробно описаны с точки зрения как методологии , так и практической реализации, стоит подробнее остановиться на задачах защиты доступа к СУБД и ограничениях на использование прикладного ПО. Но сначала поговорим о том, какие условия "благоприятствуют" похищению информации.
Попробуем проанализировать возможные причины успешных попыток краж информации, хранящейся в корпоративных базах данных.
Причина первая и главная - отсутствие системного подхода к оценке угроз. К сожалению, в настоящее время лишь малая часть предприятий применяет на практике международный опыт и подробно описанный в работах Гостехкомиссии общий подход к оценке угроз , а также рекомендации по применению адекватных средств защиты информации.
В общем случае для корпоративных БД как объекта защиты от несанкционированного доступа угрозы принято классифицировать по источнику, деля их на внутренние и внешние. Источником внутренней угрозы могут быть легальные пользователи БД или внутренние хакеры, источником внешней - легальные пользователи корпоративной сети либо внешние хакеры.
Кражи информации из БД связаны, как правило, с неправомерными действиями пользователей сети предприятия, т. е. с реализацией внутренних угроз. По данным из разных источников, до 85% краж и компрометации информации совершают легальные пользователи информационной системы предприятия и, что особенно неприятно, администраторы СУБД или прикладной системы. На долю внутренних (т. е. зарегистрированных в корпоративной сети) хакеров, пытающихся получить несанкционированный доступ к информации, по разным оценкам, приходится соответственно до 15% угроз.
Внешние угрозы неправомерного доступа к корпоративным данным также подразделяются на два подкласса, из которых на долю внешних хакеров приходится до 20%, а на долю легальных пользователей корпоративной сети - до 100%.
Причина вторая - несостоятельность парольной защиты. Несмотря на огромное количество публикаций о том, что пароли не обеспечивают должную защиту данных и приложений, этот способ до сих пор наиболее широко распространен, прежде всего из-за своей нулевой стоимости. Достаточно подробно вопрос о несостоятельности парольной защиты рассмотрен, например, в работах .
Самое неприятное, что такой подход зачастую применяется и в далеко не мелких организациях. А доступ к ресурсам системы нескольких разных пользователей под одной и той же учетной записью - весьма распространенная и прочно укоренившаяся практика. Например, если в организации работают пять системных администраторов, то все они могут иметь доступ по одному паролю. Хорошо иллюстрирует порочность такой организации доступа аналогия с ездой по улицам крупного города на автомобилях без номеров. Никакой сотрудник ГАИ не сможет четко идентифицировать автомобиль, превышающий дозволенную скорость, в потоке "анонимов", если все едут без номерных знаков.
Причина третья - не полностью задействованные встроенные в СУБД средства защиты информации и мониторинга действий пользователей, а также неоправданные надежды на квалификацию разработчиков прикладного ПО в части организации системы управления правами доступа. На ком реально лежит ответственность за применение/неприменение встроенных в СУБД средств защиты информации? Скорее всего, на разработчиках прикладного ПО, которые внедряют свои системы у заказчиков. Но парадокс заключается в том, что разработчики в подавляющем большинстве не имеют в своем штате специалиста по СЗИ и не знают о штатных возможностях организации защиты СУБД. По самым скромным оценкам, на российском рынке работает несколько тысяч прикладных систем и программных продуктов, базирующихся на использовании промышленных СУБД. При этом в подавляющем большинстве случаев считается, что все вопросы, связанные с безопасностью данных, выполняет сама СУБД , а доступ в ИС происходит по паролю.
Таким образом, из-за недостаточного внимания к вопросам безопасности со стороны разработчиков прикладного ПО механизмы защиты информации, реализованные собственно в СУБД, приобретают чрезвычайно большое значение. Более того, как говорилось выше, несколько человек могут иметь доступ в систему с максимальными (администраторскими) правами. Отследить действия конкретного лица (иначе говоря, персонифицировать эти действия) в таких условиях не представляется возможным. Даже если удается локализовать канал утечки, пользователь не подлежит никаким, хотя бы административным мерам наказания. Стандартный аргумент нарушителя - ссылка на то, что пароль у него подсмотрели и кто-то под его именем совершил неправомерные действия.
Наконец, последняя, но существенная причина - устойчивое ощущение безнаказанности у злоумышленника. Увы, практика введения строгих регламентов и административных мер без строжайшего документированного контроля не приводит к заметному снижению числа нарушений. Практически все пойманные за руку недобросовестные сотрудники признавались, что не совершили бы подобных действий, если бы знали, что эти действия будут отслежены и самое главное - персонифицированы. Поэтому только сочетание административных и технических мер, подкрепленных программными средствами контроля и мониторинга, позволяет добиться должного уровня защиты конфиденциальных данных.
Если рассматривать средства обеспечения безопасности в части доступа к БД, хранения информации и передачи по сети, то сегодня явный лидер рынка систем управления базами данных - СУБД Oracle. Она предоставляет разработчикам ПО и администраторам прикладных систем полный спектр средств и инструментов, необходимых для построения защищенных систем. Среди них стоит выделить следующие:
Virtual Private Database (VPD) - средства разграничения доступа к данным на уровне строк (в версии 10g - и на уровне колонок) и возможность организации работы пользователя только с виртуальной регламентированной частью данных, а не с реальной базой данных;
Oracle Advanced Security - комплекс средств аутентификации и обеспечения сетевой безопасности, включающий в себя поддержку защищенных протоколов передачи данных, в том числе SSL;
Oracle Label Security (OLS) - средства, аналогичные VPD, но с возможностью проверки уровня доступа пользователя;
Fine Grained Audit Control (FGAC) - инструмент подробного аудита.
Кардинально повысить безопасность работы приложений БД позволяет защита клиентского ПО СУБД Oracle 9i с помощью электронных ключей еToken. Существенно усилить защиту удалось благодаря применению нескольких технологических решений.
Прежде всего метод аутентификации пользователей по имени и паролю был заменен более надежной - двухфакторной аутентификацией с использованием цифровых сертификатов стандарта X.509. И хотя встроенные средства Oracle Advanced Security поддерживают аутентификацию по цифровым сертификатам, вопрос о хранении сертификатов и личных ключей остается открытым. Предлагаемые Oracle способы хранения сертификатов в виде файлов-контейнеров формата PKCS#12 или реестра ОС Windows имеют ряд существенных недостатков. Суть встроенных в Advanced Security возможностей иллюстрирует схема хранения сертификатов (рис. 1).
Рис. 1. Схема хранения цифровых сертификатов Oracle в архитектуре Oracle Advanced Security с использованием eToken.
Файл-контейнер, например, может быть похищен злоумышленником, имеющим права на чтение соответствующего ключа реестра или файла-контейнера. В то же время работа с СУБД разрешена только пользователю, для которого сформирован соответствующий контейнер и, более того, он "привязан" к определенной рабочей станции (где находится файл-контейнер). Чтобы избежать этих "неприятностей", необходимо хранить цифровые сертификаты непосредственно в памяти электронного ключа eToken, а для выполнения криптографических операций с закрытым ключом использовать встроенный в него криптопроцессор с дополнительной PIN-авторизацией пользователя.
Очевидно, что, помимо повышения надежности, аутентификация с использованием eToken дает ряд преимуществ по сравнению с традиционным (логин/пароль) методом. Прежде всего электронный ключ дает возможность пользователю различных приложений не хранить "где попало" и не запоминать необходимые имена и пароли. Зная один PIN-код и выбрав сертификат из предложенного списка, можно, имея соответствующие права и привилегии, обращаться к конкретной БД, причем c любой рабочей станции.
Администратор безопасности получает при этом дополнительные удобства в виде централизованного управления доступом и контроля работы системных администраторов. Все эти возможности управления обеспечивает единый инструмент - служба каталогов Oracle Internet Directory. Существующие приложения получают "в лице" службы каталогов единую точку входа - своего рода портал архитектуры клиент-сервер. При этом в большинстве случаев изменений в прикладном ПО не требуется.
Предложенное решение базируется на использовании цифровых сертификатов стандарта X.509 и протокола Secure Sockets Layer (SSL), поддерживающего строгую двухфакторную аутентификацию пользователей СУБД Oracle, а также шифрование информации, передаваемой по сети между сервером БД и клиентской рабочей станцией (рис. 2). При этом задействованы лишь штатные настройки СУБД и клиента Oracle, описанные в документации по Oracle Advanced Security . Установка на рабочей станции сервисов eToken дает возможность применять имеющиеся на ключе сертификаты для аутентификации в СУБД Oracle (cм. врезку "Процедура аутентификации в СУБД Oracle с использованием eToken").
Рис. 2. Архитектура предоставления доступа.
| Процедура аутентификации в СУБД Oracle с использованием eToken | |
Этап 1. Установление соединения клиент-сервер
| Этап 2. Авторизация пользователя сетевыми службами Oracle в БД
|
Сертификаты и связанные с ними закрытые ключи хранятся в защищенной памяти eToken (она доступна только встроенному в него криптопроцессору). Чтобы выполнить криптографические операции с закрытым ключом, пользователь должен ввести PIN-код. Такой подход позволяет на практике реализовать модель организации защищенного доступа пользователя к данным (СУБД) с использованием цифровых сертификатов Х.509, установленных в eToken, в двух уровнях. Легальные пользователи корпоративной сети (например, под управлением контроллера домена Windows 2000/2003) могут авторизоваться в сети (рис. 3) только после успешного завершения процесса аутентификации по смарт-карте, включающего предъявление соответствующего сертификата (первый уровень). На втором уровне защиты доступ авторизованных пользователей корпоративной сети к защищенным данным СУБД возможен только при предъявлении соответствующего сертификата Oracle.
Рис. 3. Двухуровневая модель доступа к защищенным данным с помощью цифровых сертификатов Х.509.
Подведем итоги. Предложенный метод защиты данных существенно ограничивает возможности кражи информации. А в случае совершения преступления он предоставляет обоснованные свидетельства для применения наказания, поскольку владелец электронного ключа и хранимых в нем сертификатов всегда известен.
1 - Обычно промышленные СУБД класса DB2 и Oracle сертифицированы как минимум по классу защищенности С2.
2 - По данным ряда источников, в том числе IDC. - Прим. ред.
В работе рассмотрены некоторые наиболее существенные требования законодательства по защите персональных данных (ПД). Представлены общие подходы к защите баз данных под управлением СУБД. Показан пример защиты ПД с учетом требований законодательства для платформы Oracle - одной из самых широко применяемых в средних и крупных информационных системах.
Для начала, вспомним некоторые положения №152-Федерального Закона "О персональных данных" .
Согласно статье 3 закона "оператор - государственный орган, муниципальный орган, юридическое или физическое лицо, организующие и (или) осуществляющие обработку персональных данных, а также определяющие цели и содержание обработки персональных данных". Таким образом, мы приходим к выводу, от которого и будем отталкиваться: практически все юридические лица РФ являются потенциальными операторами ПД.
В законе также прямо указано, что под обработкой ПД понимается практически все, что с ними можно сделать, начиная с получения данных и заканчивая их обезличиванием и уничтожением: "обработка персональных данных - действия (операции) с персональными данными, включая сбор, систематизацию, накопление, хранение, уточнение (обновление, изменение), использование, распространение (в том числе передачу), обезличивание, блокирование, уничтожение персональных данных".
Кроме этого, в требованиях закона "О защите персональных данных" №152-ФЗ содержатся некоторые, мягко говоря, непривычные для российских организаций процедуры, такие как:
Заметим, что практики выполнения таковых требований у подавляющей части российских организаций нет. Нет и установившихся правил взаимных доверительных отношений, например, исключительно редко оформляется договор оферты на согласие использовать личные данные граждан. А ведь такой подход уже достаточно давно и успешно практикуется в развитых странах. И ещё: даже если таким договором было бы четко определено, какие именно виды обработки персональных данных разрешаются конкретной организации, а также кто конкретно будет нести ответственность за нарушение оговоренных видов обработки и компрометацию личных данных, немногие граждане решились бы на заключение подобного договора. В условиях расплывчатости формулировок законодательства, очевидно, что даже если бы гражданин дал своё согласие на обработку его персональных данных, то в любом случае он оказался бы в полной зависимости от того, насколько разумно и добросовестно будет трактовать нормы закона оператор.
Стоит добавить, что по некоторым данным, упомянутая классификация и соответствующие каждому классу требования, согласно постановлению Правительства №781, уже разработаны ФСТЭК, ФСБ и Мининформсвязи России и в ближайшее время будут опубликованы. Этот долгожданный во многом документ прольет свет на эти и другие аспекты практического применения ФЗ-152. Но основные надежды, которые с ним связаны, заключаются в получении практических инструкции по реализации требований закона для государственных организаций, обрабатывающих ПД граждан.
По большому счету, коммерческие структуры давно уже защищают критичные для бизнеса данные (например, реестр акционеров и другую коммерческую информацию), в том числе и ПД. Однако немногие организации при этом выполняют требования федерального закона о коммерческой тайне, но эта обширная тема выходит за рамки данной статьи.
В свою очередь госорганизации ждут конкретных указаний и методик по построению систем защиты в зависимости от класса информационной системы и характера данных, обрабатываемых данной системой. Хочется надеяться, что в ближайшее время все необходимые документы будут доработаны и опубликованы, и это даст толчок к началу реальной работы по защите персональных данных.
Не менее интересно и то, какие возможности предусматривает закон для самих граждан - субъектов персональных данных. В дополнение к вышесказанному вспомним другие положения закона. Согласно части 4 статьи 14 ФЗ-152 субъект персональных данных имеет право на получение при обращении или при получении запроса информации, касающейся обработки его ПД, в том числе содержащей: подтверждение факта обработки персональных данных оператором, а также цель такой обработки; способы обработки ПД, применяемые оператором; сведения о лицах, которые имеют доступ к ПД; перечень обрабатываемых персональных данных и источник их получения; сроки обработки ПД, в том числе сроки их хранения; сведения о том, какие юридические последствия для субъекта персональных данных может повлечь за собой обработка его ПД. По сути, это тоже трудновыполнимая задача для оператора, ведь никто не отменял ст.137 УК РФ "Нарушение неприкосновенности частной жизни" от 13 июня 1996г. В статье, в частности, говорится, что уголовную ответственность влечет: незаконное собирание или распространение сведений о частной жизни лица, составляющих его личную или семейную тайну, без его согласия либо распространение этих сведений в публичном выступлении, публично демонстрирующемся произведении или средствах массовой информации, если эти деяния совершены из корыстной или иной личной заинтересованности и причинили вред правам и законным интересам граждан.
Согласно статье 17 ФЗ-152 в случае, если субъект ПД считает, что оператор осуществляет обработку его ПД с нарушением требований настоящего Федерального закона или иным образом нарушает его права и свободы, субъект ПД вправе обжаловать действия или бездействие оператора в уполномоченный орган по защите прав субъектов ПД или в судебном порядке. При этом лица, виновные в нарушении требований, несут административную, гражданскую, уголовную и иную, предусмотренную законодательством, ответственность.
Весьма существенным представляется то, что за реализацию требований по безопасности в системах защиты информации отвечают разработчики.
Вот основные составляющие системы госконтроля и надзора за обеспечением безопасности ПД при их обработке в ИС:
Таким образом, создается продуманная система государственного контроля операторов, обрабатывающих персональные данные.
Мероприятия по защите ПД немногим отличаются от общепринятого подхода по защите информации, ограниченного доступа. Итак, комплексный подход к защите БД состоит из последовательных этапов, среди них:
При этом традиционно применяют две составляющих построения системы защиты информации: провести инвентаризацию информационных ресурсов, определить их владельцев, категоризировать информацию (в том числе ограниченного доступа, при необходимости ввести режим коммерческой тайны), подготовить и подписать приказ о выполнении разработанных организационных мер защиты, обосновать и получить бюджет, подобрать и подготовить кадры, обучить их, организовать переподготовку, и… это далеко не всё.
Все эти мероприятия следует описать и утвердить в нормативно-распорядительной документации. При этом очень важна поддержка руководства для последовательного проведения в жизнь выработанной политики безопасности. Очевидно, что лучшей практикой является подписание каждым сотрудником отдельного соглашения по работе с информацией ограниченного доступа. В крайнем случае, в обязательном порядке сотрудники должны быть проинструктированы, что, в свою очередь, должно быть подтверждено подписью "ознакомлен" с указанием ФИО, должности сотрудника во всех приказах и распоряжениях.
Перейдем к рассмотрению технических средств защиты БД, содержащей персональные данные, более подробно.
Классическая схема защиты баз данных (БД) подразделяется на следующие обязательные процедуры:
Всеми перечисленными функциями безопасности в той или иной мере оснащены СУБД и приложения Oracle, что выгодно отличает их от продуктов конкурентов. Рассмотрим указанные процедуры подробнее.
Преследуя цель защиты БД от инсайдерских угроз, для обеспечения разграничения доступа в версии СУБД 10g Release 3 компания Oracle выпустила новый продукт Database Vault , предназначенный для предотвращения несанкционированного доступа к информации пользователей, в том числе наделенных особыми полномочиями, например, администраторов базы данных. Набор правил в Database Vault , разграничивающих доступ, достаточно широк. Например, руководство организации может определить правила, согласно которым для решения задач, предполагающих доступ к критичной информации, потребуется одновременное присутствие двух сотрудников. Таким образом, Database Vault решает следующие проблемы:
Аутентификация в контексте Oracle означает проверку подлинности кого-либо или чего-либо - пользователя, приложения, устройства, кому или чему требуется доступ к данным, ресурсам или приложениям. После успешной процедуры аутентификации следует процесс авторизации, предполагающий назначение определенных прав, ролей и привилегий для субъекта аутентификации.
Oracle предоставляет разнообразные способы аутентификации и позволяет применять один или несколько из них одновременно. Общим для всех этих способов является то, что качестве субъекта аутентификации используется имя пользователя. Для подтверждения его подлинности может запрашиваться некоторая дополнительная информация, например, пароль. Аутентификация администраторов СУБД Oracle требует специальной процедуры, что обусловлено спецификой должностных обязанностей и степенью ответственности этого сотрудника. Программное обеспечение Oracle также зашифровывает пароли пользователей для безопасной передачи по сети.
Итак, рассмотрим подробнее способы аутентификации в СУБД Oracle .
Ряд операционных систем позволяют СУБД Oracle использовать информацию о пользователях, которыми управляет собственно ОС. В этом случае пользователь компьютера имеет доступ к ресурсам БД без дополнительного указания имени и пароля - используются его сетевые учетные данные. Данный вид аутентификации считается небезопасным и используется, в основном, для аутентификации администратора СУБД.
Данный вид аутентификации обеспечивает опция сервера Oracle Advanced Security . Она предоставляет следующие службы:
1. SSL - аутентификация использует протокол SSL (Secure Socket Layer) - протокол уровня приложений. Он может использоваться для аутентификации в БД и в общем случае (если далее используется аутентификация пользователя средствами СУБД) не зависит от системы глобального управления пользователями, обеспечиваемой службой каталога Oracle - Oracle Internet Directory .
2. Аутентификация службами третьих сторон.
На основе Kerberos . Применение Kerberos как системы аутентификации с доверенной третьей стороной, основано на использовании, т.н. общего секрета. Это предопределяет безопасность и надежность доверенной стороны и дает возможность использования Single Sign - On , централизованного хранения паролей, прозрачной аутентификации через связи БД (database links), а также средств усиленной безопасности на рабочих станциях.
На основе PKI . Применение PKI для аутентификации предполагает издание цифровых сертификатов для пользователей (приложений), которые используются для непосредственной аутентификации на серверах БД в рамках одной организации. При этом не требуется использование дополнительного сервера аутентификации. Oracle определяет следующие компоненты для использования PKI:
На основе RADIUS . СУБД Oracle поддерживает протокол RADIUS (Remote Authentication Dial - In User Service) - стандартный протокол для аутентификации удаленных пользователей. При этом становятся доступны службы и устройства аутентификации третьих производителей, с которыми может взаимодействовать сервер RADIUS (например, устройства генерации одноразовых паролей, биометрические устройства и т.п.).
На основе службы LDAP -каталога. Использование службы LDAP -каталога делает управление аутентификацией и управление учетными записями пользователей (приложений) очень эффективным. В инфраструктуре СУБД Oracle служба каталога представлена следующими компонентами:
Приведенные выше методы аутентификации также могут быть применены и в многоуровневых приложениях. Как правило, для доступа к приложениям из сети Интернет используется аутентификация по имени и паролю (в том числе с использованием протокола RADIUS), либо по протоколу SSL. Прочие методы используются для работы пользователей в локальной сети.
Для защиты данных, передаваемых в сети, в СУБД Oracle, начиная с версии 8i, используется возможности опции Oracle Advanced Security , в которой предусмотрена функция Network encryption , позволяющая шифровать весь поток данных. Безопасность информации обеспечивается секретностью ключа, которым шифруются данные.
Network encryption позволяет добиться высокого уровня безопасности. Поддерживаются следующие алгоритмы шифрования AES (только 10 g /11g). DES , 3 DES , RC 4(только 10 g /11g).
Защита передаваемых в сети данных в приложениях Oracle обеспечивается протоколом SSL по алгоритмам, которые поддерживается сервером приложений, как правило, это WEB -сервер Oracle.
Защиту данных на носителе обеспечивают два компонента СУБД Oracle - пакеты, реализующие алгоритмы шифрования и опция Transparen t Data Encryption (T DE). Начиная с версии 8i, СУБД Oracle предоставляет для разработчиков приложений пакеты хранимых процедур, реализующих алгоритмы: DES с длиной ключа 56 бит, Triple DES с длиной ключа 112 и 168 бит , A ES с длиной ключа 128, 192 и 256 бит RC 4 (только 10 g /11g).
Опция T DE появилась в версии СУБД Oracle 10g Release 2 как составная часть Advanced Security. Она позволяет выборочно шифровать колонки таблиц с применением алгоритмов Triple DES (c длиной ключа 168 бит), AES (c длиной ключа 128, 192 или 256 бит). Управление ключами шифрования берет на себя ядро БД, а применение такого шифрования не требует переделки клиентского и серверного прикладного ПО. В версии СУБД 11g и выше появилась возможность зашифрования табличного пространства целиком.
СУБД Oracle имеет мощные средства аудита действий пользователей, включающих как доступ к данным, так и события регистрации/выхода и изменения структуры БД. Начиная с версии 9i, СУБД оснащается опцией подробного аудита (Fine Grained Audit Control), которая позволяет проводить аудит доступа по условиям, определяемым достаточно гибкими настраиваемыми правилами. Однако, данные средства аудита не позволяет проследить за действиями, которые совершаются администратором базы данных, а также не мешают ему изменять журнал аудита, удаляя любые строки и не оставляя следов подобных действий. Возникшая необходимость аудита деятельности и защиты данных аудита от привилегированных пользователей, включая администраторов БД, побудило Oracle разработать новую концепцию аудита. В её основу положена идея, на которой базируется функционал Database Vault : администратор БД изолирован от управления аудитом, что по поянтным причинам обеспечивает более высокий уровень безопасности БД. Как и в случае Database Vault правила назначения аудита в Audit Vault очень гибкие.
Приведённый нами краткий обзор средств защиты информации, которые корпорация Oracle встроила в свои продукты и технологии, демонстрирует солидный задел для построения ИС с различным уровнем защищенности, отвечающих самым современным требованиям по безопасности. Однако, даже поверхностный взгляд на системы защиты различного ПО, использующего СУБД или сервер приложения Oracle , покажет, что за редким исключением, встроенные средства обеспечения безопасности либо не используются вовсе, либо их заменяют аналогичные по функционалу собственные разработки или готовые разработки, предлагаемые на рынке, либо встроенные средства дополняются ПО сторонних разработчиков.
По сути, мы имеем дело с тремя подходами отечественных компаний к вопросу информационной безопасности вообще и к защите баз данных от постоянно растущих угроз, в частности.
К сожалению, стоит признать, что первый подход наиболее распространен и подразумевает использование простейшей парольной аутентификации, авторизации и шифрования данных.
От сторонников такого подхода при разработке и эксплуатации ИС чаще всего можно услышать следующие аргументы:
Конечно, парольная защита не требует дополнительных затрат ни на стадии разработки, ни на стадии эксплуатации ИС - все "заботы" по обслуживанию пользователей и их паролей берет на себя СУБД или сервер приложений. Также отсутствуют затраты на дополнительное оборудование (серверы аутентификации, службы каталогов, устройства хранения ключевой информации и т.д.) и программное обеспечение (лицензии, ПО сторонних производителей и т.д.). Немаловажно, что и требования к квалификации администраторов БД и администраторов безопасности в данном случае значительно ниже, а это - также вопрос экономии. Третий аргумент, видимо, исторически сохраняется с тех времен, когда вопросами безопасности серьезно не занимались.
Системы защиты, построенные согласно второму подходу распространены чуть менее. Отчасти в них переходят системы из первого варианта, когда, например, заказчики такой системы, уставшие от "низкой" стоимости владения парольной защитой, заказывают разработчикам или покупают готовую систему управления паролями. Бывает, что периодические скандалы с кражами данных заставляют делать программные "нашлепки" на готовой системе для реализации шифрования, зачастую по собственным "суперстойким" алгоритмам.
Доводы для такого подхода, примерно, следующие:встроенные средства защиты явно недостаточны и изобилуют уязвимостями;
Рассмотренные выше два варианта использования средств защиты характерны для ИС, разработанных и внедренных преимущественно в конце 90-х годов прошлого века. Характерный пример - биллинговые системы, самостоятельной разработкой которых занимаются десятки компаний. Не менее яркими примерами являются базы данных здравоохранения и силовых структур. А ведь они содержат внушительные объемы конфиденциальной информации и, в частности, персональных данных, которые обязывает надежно защищать российское законодательство. Является ли такое халатное отношение к защите БД с персональными данными граждан причиной постоянного появления среди пиратских копий фильмов сборников баз данных по физическим и юридическим лицам? Ответ на этот вопрос следует искать, прежде всего, опираясь на недостатки описанных подходов. Предпримем попытку анализа сторонников указанных подходов.
Действительно, простота использования парольной защиты не вызывает сомнений. Но простота и надёжность защиты в данном случае малосовместимы. В безопасности и удобстве эксплуатации такая технология себя изживает. Надежность пароля и, следовательно, безопасность его использования, напрямую зависит от его качества (применяемые символы, их регистр, отличие от осмысленных слов). А удобство использования стремительно падает даже при незначительном усилении "безопасности" пароля, ведь запомнить нечитаемую комбинацию символов довольно сложно. Обратимся к цифрам и фактам. Пароли пользователей хранятся в СУБД Oracle в виде хеш-значений и доступны для чтения привилегированным пользователям. Алгоритм вычисления хеша пароля давно известен. Наиболее полное исследование стойкости паролей в Oracle проведено компанией Red - Database - Security GmbH - ведущего мирового эксперта в области безопасности продуктов Oracle. Вот некоторые данные по стойкости паролей для версий СУБД 7-10g:
На компьютере с Pentium 4 3 GHz требуемое время составляет (атака простым перебором):
И это при использовании далеко не самого мощного компьютера. При наращивании производительности атака по словарю проводится ещё быстрее. Нельзя сказать, что Oracle не реагирует на подобное положение дел - в версии СУБД 11g положение значительно улучшилось. Был усилен алгоритм выработки хеша и качество формирования паролей. В результате приведенные выше цифры выросли в 2.5-3 раза. Но, несмотря на такие улучшения, Oracle рекомендует использовать средства усиленной аутентификации, которые также были доработаны в лучшую сторону, например, стало возможно использовать HSM (Hardware Security Module) для аутентификации и хранения ключей шифрования.
Таким образом, делаем вывод: надежность и безопасность использования паролей для защиты ИС в настоящее время перестала отвечать требованиям компаний, которые, с одной, стороны заботятся о своей репутации, а с другой - обязаны выполнять требования текущего законодательства.
Широко распространенное заблуждение. Статистика подтверждает факты значительных затрат на обслуживание, скажем, забытых паролей. Еще более ощутимые потери несут компании из-за низкой надежности и безопасности парольной защиты.
И в этом вопросе мы вновь сталкиваемся с расхожим мнением о том, что штатные средства безопасности недостаточны. Как объяснить возникновение такого мнения, особенно при учёте того, что и встроенные средства защиты чаще всего используется далеко не на 100%. Т
Что же касается уязвимостей встроенных средств защиты в Oracle, то ситуация здесь ровно такая же как и в других сложных системах. Корпорация Oracle традиционно ответственно относится к обнаружению и устранению найденных уязвимостей. Регулярно (4 раза в год) выпускаются обновления CPU (Critical Patch Update), устраняющие бреши, обнаруженные как самой корпорацией Oracle, так и десятками других компаний, наиболее известная из которых - уже упоминавшаяся Red - Database - Security GmbH . Так, например, в CPU за октябрь 2007 г. были устранены 27 уязвимостей в СУБД, 11 - в сервере приложений, 13 - в различных приложениях. Учитывая число продуктов Oracle , их версий и программно-аппаратных платформ для них, это не так уж и много.
По данному вопросу существует много мнений. Некоторые организации предпочитают иметь собственные подразделения разработчиков, некоторые - нет. Пожалуй, самым веским аргументом в пользу поддержки вендора можно считать то, что не всякая компания может позволить себе иметь в подразделении разработки специалистов по информационной безопасности.
Однако даже если такие ресурсы есть, стоит иметь в виду, что "самописная" система в значительной степени зависит от команды разработчиков, принимавших участие в её проектировании и создании. А значит их уровень профессионализма, их квалификация являются определяющими с точки зрения качества разработки, отсутствия встроенных в ПО закладок, уязвимостей, которыми могут воспользоваться внешние злоумышленники. Кроме того "самописные" решения чреваты тем, что уход одного или нескольких ключевых "авторов" этих решений, может повлечь за собой риски, связанные с корректной поддержкой и развитием ранее созданной инфраструктуры новыми специалистами.
Итак, подведем промежуточные итоги. Основные аргументы, приводимые апологетами перечисленных нами подходов - встроенные средства защиты не используются и "самописные" средства надёжнее штатных - на самом деле не имеют под собой серьёзных оснований. И компании, придерживающиеся этих вариантов для защиты своих баз данных, фактически подвергают конфиденциальную информацию, содержащуюся в БД, риску хищения и утечки.
Приведенный нами выше пример о защите баз данных различных социальных учреждений на самом деле очень показателен. Ведь речь идёт о государственном предприятии, что напрямую связано с соблюдением, с одной стороны, интересов государства, с другой - интересов граждан. Соответственно вопрос защиты хранящихся и обрабатываемых данных, циркулирующих в информационной инфраструктуре этого учреждения, становится приоритетом номер один. И в этом случае максимальное использование возможностей штатных средств защиты в решениях надёжных поставщиков всё же может оказаться недостаточным. Требование усиления защиты для госпредприятий связано, с одной стороны, с внедрением технологий более высокого уровня безопасности, а с другой - с выполнением требований закона, в частности, по использованию исключительно сертифицированных средств защиты.
Именно поэтому в последнее время начал набирать обороты третий "смешанный" подход к защите информационных систем. Если проанализировать типичные требования по защите ИС и те возможности, которые могут быть реализованы с помощью встроенных средств Oracle, то сразу можно выделить то, что должно быть дополнено:
Алгоритмы российской криптографии (PKI, ЭЦП, шифрование в сети и на носителе)
Реализация шифрования при записи на носитель без использования TDE
Хранение ключевого материала.
По очевидным причинам разработчики Oracle не предусматривали универсальную реализацию этих двух моментов, хотя и предусмотрели некоторые общие подходы.
Криптографические алгоритмы могут использоваться в процессе аутентификации, выработки ЭЦП (ГОСТ Р 34.10-2001), для защиты канала связи (ГОСТ 28147-89, ГОСТ Р 34.11-94) и шифрования данных (ГОСТ 28147-89). Встроенные средства Oracle не реализуют данные алгоритмы ни в СУБД, ни в сервере приложений, ни в приложениях. Реализацию криптографии в виде библиотек, стандартных поставщиков криптографии (CSP), комплектов разработчика (SDK) предлагают несколько российских производителей - КриптоПро, Сигнал-Ком, Инфотекс, Лисси, КриптоКом, КриптоЭкс и др. Однако, заставить продукты Oracle работать с предлагаемыми библиотеками достаточно проблематично. Дело даже не в том, что данные средства не совместимы на уровне программно-аппаратного обеспечения - встраивание криптографии в продукты Oracle не должно нарушать лицензионного соглашения вендора относительно целостности ПО. Если с ИС, построенными на основе сервера приложений Ora cle или всего множества приложений Oracle, проблем со встраиванием, как правило, не возникает, то с СУБД дело обстоит сложнее. Вследствие того, что ядро СУБД не имеет программного интерфейса к криптооперациям (аутентификация, шифрование), приходится применять обходные пути. Например, использовать протокол аутентификации Kerberos или генераторы одноразовых паролей с протоколом RADIUS, а защиту канала связи осуществлять с помощью сертифицированных программных средств.
Несмотря на чрезвычайную простоту опции Oracle TDE, от ее использования часто приходится отказываться. Основных причин две:
Не поддерживаются некоторые типы данных
Нет возможности штатно применить российские криптоалгоритмы
Нет реальной защиты от привилегированных пользователей.
Первая проблема в принципе решается с помощью продуктов сторонних разработчиков - DbEncrypt for Oracle (Application Security, Inc.), eToken SafeData (Aladdin Software Security R . D .), The Encryption Wizard for Oracle (Relational Database Consultants , Inc .). Вторая проблема принципиально решается таким же образом, но здесь вариантов меньше - eToken SafeData или The Encryption Wizard for Oracle . Причем для первого продукта требуется дополнительная сборка версии (в зависимости от применяемого производителя сертифицированной криптографии), а по второму продукту, просто не удалось найти нужную информацию. Третья проблема, в принципе, могла бы быть решена с помощью совместного использования опций TDE и Oracle Database Vault , но в этом случае полномочия администратора СУБД плавно перетекают к администратору Database Va u lt, т.е. проблема защиты от привилегированных пользователей сохраняется.
Ключевой материал (сертификаты, закрытые ключи, ключи шифрования), используемые встроенными средствами обеспечения безопасности Oracle для аутентификации или шифрования данных, хранятся в ключевых контейнерах, (т.н. бумажниках - wallets) как обычные файлы. Для доступа к информации в бумажнике требуется пароль. Часто такой способ хранения не отвечает требования по безопасности, особенно на рабочих станциях клиентов. СУБД Oracle , начиная с версии 10g, позволяет хранить закрытые ключи на аппаратных устройствах, поддерживающих стандарт PKCS#11. В то же время Oracle никак не гарантирует работу аппаратных устройств, отличных от устройств производства nCipher (nCipher Corporation Ltd.). Это не всегда приемлемо, например, если предполагается использование только сертифицированных аппаратных средств. И в этом случае проблема хранения ключей и сертификатов может быть решена с помощью решений сторонних производителей. На российском рынке, пожалуй, единственным в своем классе продуктом является eToken SecurLogon для Oracle (Aladdin Software Security R.D.) .
Несмотря на осознанное понимание поднятой проблемы как законодателями, так государственными и коммерческими организациями, персональные данные всё же подвержены утечкам информации, ущерб от которых подчас оценивается весьма впечатляющими цифрами. Отсутствие громких прецедентов может быть объяснено латентностью преступлений в этой области. Однако утечки происходят постоянно и рано или поздно с кражами баз данных будет развернута полномасштабная борьба на госуровне. Конечно, можно использовать несертифицированные решения, можно использовать нелицензионное ПО и самостоятельно изобретать велосипед, игнорируя проверенные промышленные решения… Но только в этом случае организации должны отдавать себе отчет в том, что и все дополнительные риски - от финансовых до репутационных - связанные с применением таких продуктов, они тоже полностью берут на себя. Есть угрозы, и есть последствия. Принимая тот или иной подход к обеспечению безопасности информационных ресурсов, организации либо идут на риски, либо создают для себя максимально безопасные условия.
В настоящее время требования к безопасности со стороны потребителей достаточно высоки, и оптимальное решение состоит в полноценном использовании встроенных средств безопасности и разумным их дополнением продуктами и решениями сторонних разработчиков. Однако часто стремление построить надежную защиту ИС упирается в банальную нехватку квалифицированных кадров - разработчиков, аналитиков, инженеров техподдержки, консультантов. Следствием этого являются слабое владение информацией о возможностях встроенных средств защиты Oracle и других систем и их корректного использования. Другим следствием является та же ситуация, но уже по отношению к продукции других производителей программно-аппаратных средств защиты информации и их использованию совместно с технологиями и продуктами Oracle. Как итог - существующие системы продолжают использовать устаревшие парольные системы защиты, обрастая ненужными доработками и ворохами дополнительных регламентов, и, что еще хуже, разрабатываются новые ИС со старыми технологиями защиты. Выход из такой ситуации, прежде всего, в подготовке кадров, обладающих экспертными знаниями в собственно информационной безопасности, в линейке продуктов Oracle и умеющих интегрировать разработки российских компаний со встроенными средствами защиты. Подобное обучение должно начинаться уже в профильных Вузах, и специалисты в данной области должны иметь возможность наращивать опыт и навыки в обучающих центрах. Хотелось бы видеть поддержку в данном вопросе как со стороны Oracle , так и со стороны других производителей, работающих на рынке информационной безопасности России.
В этой связи, очень обнадеживающей тенденцией, на наш взгляд, является, появление реальных решений, методов и подходов к организации систем ИБ, разработанных отечественными компаниями совместно с российскими представительствами западных корпораций. Такое сотрудничество позволяет обеспечить не только устойчивую работоспособность механизмов защиты в составе информационной системы, но и соответствие этих решений требованиям российского законодательства.
