3. Обеспечение информационной безопасности

В ОАО «ЮТК» уделяется огромное внимание вопросам обеспечения информационной безопасности, так с 2008 г. осуществляется сотрудничество с лабораторией Касперского, производителя систем защиты от вредоносного и нежелательного ПО, хакерских атак и спама, когда ОАО «ЮТК» подписало генеральное соглашение на поставку антивирусного программного обеспечения сроком на 3 года.

Генеральное соглашение позволит ОАО «ЮТК» и всем её филиалам приобретать антивирусное программное обеспечение Лаборатории Касперского по единым фиксированным ценам, независимо от объема разовой закупки и канала поставки (партнера, осуществляющего поставку, внедрение и сопровождение).

Предметом двустороннего соглашения являются бизнес-продукты комплекса Kaspersky Open Space Security: Kaspersky Total Space Security и Kaspersky Business Space Security, а также продукты для защиты почтового и интернет-трафика абонентов ОАО «ЮТК».

В соответствии с подписанным соглашением ОАО «ЮТК» закупает более 6 тыс. лицензий на продукты по обеспечению информационной безопасности Лаборатории Касперского. Дополнительно оператору будут поставлены лицензии для защиты почтового и интернет-трафика абонентов.

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

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

Технические способы защиты

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

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

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

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

• шифрование трафика между клиентской рабочей станцией и сервером БД, что предотвратит попытки кражи информации на сетевом уровне;

• криптографическое преобразование тех данных, которые необходимо защитить. Это значительно снизит риск потери информации;

• хранение аутентификационной информации и ключей шифрования на персонализированном съемном носителе, например, на смарт-карте или USB-ключе. Это позволит устранить проблему «забытых паролей» и повысить персональную ответственность сотрудника;

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

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

Использование «прозрачных» приложений

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

Рассмотрим это решение подробнее. Из всего разнообразия методов аутентификации, предоставляемых СУБД Oracle (имя/пароль, RADIUS, Kerberos, SSL), в 99% случаев используется аутентификация по имени пользователя и паролю. Безусловно, это самый простой метод. Однако его удобство и, что более важно, безопасность оставляют желать лучшего. Наиболее надежным методом сегодня считается аутентификация по сертификату X.509, которую поддерживает Oracle. Сертификаты пользователей и закрытые ключи могут храниться либо в файлах стандартного формата PKCS#12, размещенных на отчуждаемых носителях, либо в реестре Windows на рабочих станциях, при этом они защищены паролем. Однако парольная защита порождает проблемы безопасности – ключевые контейнеры могут быть скопированы и впоследствии «взломаны» методом простого перебора паролей. Определенные неудобства вызывает и привязка ключевого контейнера к конкретной рабочей станции.

Рассматриваемое решение снимает обе проблемы: сертификаты установлены непосредственно в чиповой (интеллектуальной) смарт-карте; секретный ключ находится в защищенной памяти и никогда оттуда не извлекается; сертификаты «мобильны» – работать с приложениями Oracle можно с любой рабочей станции и от имени любого пользователя корпоративной сети.

Необходимые настройки – указать, что ключевой контейнер помещен в хранилище сертификатов (Certificate Store) Microsoft. В момент запроса на соединение с БД служба смарт-карты RTX позволяет сетевым драйверам Oracle «видеть» все сертификаты, установленные на смарт-карте. Процесс аутентификации проходит в два этапа:

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

• запрос PIN-кода смарт-карты для авторизации на операции с закрытым ключом.

Когда клиенту требуется предъявить свой сертификат, служба смарт-карты «подсказывает» ему, что сертификат следует брать из смарт-карты. Для подтверждения подлинности сервера клиенту необходим личный ключ для расшифровки ответа сервера. Закрытый ключ находится в защищенной памяти смарт-карты, и все операции с ним выполняет встроенный в карту криптопроцессор. Для таких операций требуется дополнительная авторизация, то есть запрашивается PIN-код. Когда между клиентом и сервером установлены доверительные отношения, сервер проверяет наличие отличительного имени пользователя, для которого издан сертификат клиента, в LDAP-каталоге – Oracle Internet Directory. Если таковой найден, дополнительно определяются экземпляр БД, схема и набор прав для клиента. После этого сервером создается сессия пользователя с указанными параметрами. Сетевой обмен между клиентом и сервером происходит по соединению, защищенному определенным криптоалгоритмом.

Заказчик, настроивший сервер БД, клиентские рабочие станции и установивший сертификаты пользователей на смарт-карты, получает надежную аутентификацию, шифрованный трафик между рабочими станциями и сервером, и, самое главное, – строгую персонализацию доступа в БД. Все приложения, работающие с Oracle – от DOS-консоли до сложных ERP-систем, будут работать с рассмотренным методом аутентификации без каких-либо доработок.