Архитектура безопасности европы и ее функционирование. CallBox-приватный мессенджер на блокчейне Основные компоненты системы безопасности Windows NT
4. Архитектура и средства обеспечения безопасности в информационных системах
Под архитектурой системы безопасности понимается интегрированная модель, включающая в себя службы, механизмы, объекты безопасности и функции управления, реализованная на различных программно-аппаратных платформах.
Обычно архитектура системы безопасности базируется на применении международных промышленных стандартов и решениях ведущих фирм-производителей соответствующего технического оборудования и программного обеспечения . Лидерами среди них являются компании IBM, Cisco systems, Oracle и др.
Архитектура системы безопасности включает в себя следующие компоненты (рис. 4.1): службы безопасности, механизмы безопасности, объекты безопасности, управление безопасностью (включая аудит). Архитектура может применяться для обеспечения безопасности на предприятиях различной организационной структуры и сферы деятельности. Информационную систему компании можно считать защищенной, если все операции выполняются ею в соответствии со строго определенными правилами, которые обеспечивают непосредственную защиту объектов, ресурсов и операций.
Основу для формирования требований к защите составляет список угроз, а процесс обеспечения безопасности представляет собой цепь действий, включающую управление рисками , определение политики безопасности, реализацию безопасности, администрирование безопасности и аудит.
Управление рисками - процесс исследования и анализа потенциальных дефектов защиты и определения приемлемого уровня средств управления безопасностью, издержек реализации, и принятия риска для тех дефектов, которые полностью не устранены.
Определение политики безопасности - процесс определения потребностей в безопасности, конечными целями которого являются создание стратегии управления защитой и руководящих принципов ее реализации.
Реализация средств безопасности - процесс обеспечения, установки и инициализации соответствующего оборудования и программ защиты. Он включает в себя: выбор механизмов защиты, установку аппаратных и программных средств защиты, определение системы управления безопасностью, классификацию пользователей, данных и ресурсов для обеспечения эффективного управления.
Администрирование безопасности - процесс применения политики обеспечения безопасности и действий на предприятии, который включает управление объектами защиты:
Идентификаторов пользователей и паролей;
Специальной системы привилегий пользователей (администратора, ревизора или оператора);
Типов наборов данных, правами доступа к приложениям, транзакциям и устройствам;
Ключей шифрования;
Файлов регистрации;
Данных аудита.
Аудит - процесс постоянного инспектирования средств управления и событий в системе, представляющих интерес с точки зрения безопасности. Контрольные результаты периодически сообщаются службам управления и используются для целей дальнейшего улучшения стратегии защиты и управления системой.
Все более расширяющееся использование локальных сетей, общедоступных (например, Internet) и фирменных глобальных сетей для подключения рабочих станций, терминалов и серверов предприятий в различных конфигурациях создало предпосылки для проектирования и развития новых средств администрирования и обеспечения безопасности в распределенной среде. При этом формулируются следующие требования к системам информационной безопасности :
Масштабируемости систем;
Способности к взаимодействию систем различных производителей;
Использования в системе доверенных и недоверенных компонентов;
Поддержки различных технологий аппаратных средств защиты (криптографических устройств, smart-карт и др.).
Таким образом, способность к взаимодействию служб безопасности одной системы с другой в составе гетерогенных вычислительных сред должна быть архитектурно заложена в систему безопасности каждого поставщика. Поэтому ведущей стратегией для поставщиков комплексных решений является участие в разработке стандартов безопасности открытых систем, что позволяет согласовывать стратегические направления развития механизмов защиты с международными стандартами.
Основными разработчиками открытых стандартов являются ISO и фонд открытых систем OSF(Open System Foundation). Цель OSF формулируется в виде разработки базового промышленного решения, которое в дальнейшем используется различными производителями в своих продуктах.
Наиболее известным открытым стандартом OSF является распределенная компьютерная среда DCE (Distributed Computing Environment). DCE - это сочетание распределенных компьютерных технологий, поддерживающих услуги безопасности для защиты и контроля доступа к данным, услуг именования, облегчающих поиск распределенных ресурсов, и масштабируемая модель организации пользователей, услуг и данных, распределенных на большой территории. Основные компоненты DCE: служба каталога, имен, времени и безопасности, - позволяет из набора отдельных систем создавать единую систему с единым временем, именованием и адресацией ресурсов и обеспечением безопасности.
DCE имеет модульную структуру и поддерживает процессы идентификации и авторизации . Идентификационная часть системы построена на технологии Kerberos, а авторизационная - работает так же, как Kerberos, но выполняется серверами привилегий и серверами регистрации.
Приведем краткое описание служб, механизмов и объектов архитектуры безопасности в соответствии с рис. 4.1.
Службы безопасности - это функции системы, которые служат для защиты ресурсов, гарантируя соблюдение определенной политики безопасности:
Идентификация и аутентификация - средства проверки тождества личностей, документов, программ или устройств;
Контроль доступа - защита критических ресурсов путем организации доступа к ним только аутентифицированных (опознанных) и авторизованных (уполномоченных) пользователей;
Конфиденциальность - защита важной информации от раскрытия; для локальных систем данные могут быть защищены с использованием механизмов шифрования или управления доступом; для защиты в сетевых средах важные данные должны обязательно шифроваться; криптозащита в продуктах зарубежных фирм, как правило, основываются на стандартах ISO определяющих использование криптографии для конфиденциальности и целостности данных;
Целостность данных - обеспечение обнаружения несанкционированной модификации данных; данные могут быть изменены в результате аппаратных ошибок и ошибок передачи данных, либо в случае отказа; для защиты аппаратных ошибок и ошибок передач используется механизм контрольных служб; для противодействия активным нападениям используют механизмы криптографии и верификации целостности данных.
Механизмы безопасности - это совокупность технических средств, методов и технологий, используемых для построения служб безопасности:
Аутентификация объекта - проверяет тождественность объекта путем сравнения идентификационной информации объекта с данными доверенного информационного архива;
Списки контроля доступа ACL (Access Control Lists) как форма информационного архива, который содержит данные относительно прав и разрешений доступа для каждого опознанного объекта к системе;
Шифрование/дешифрация (криптография) - механизм, используемый для обеспечения конфиденциальности, базирующейся на использовании ключей и алгоритмов преобразования данных;
Контрольные коды обеспечения целостности данных используют три основных метода построения - циклическим избыточным кодом CRC, кодами обнаружения модификации MDC и коды установления подлинности сообщений МАС; код CRC обычно используется для распознавания аппаратных отказов и ошибок передачи, MDC создаются с использованием средств криптографии, но без применения секретных ключей, МАС - наиболее совершенный код для обеспечения целостности данных на основе шифрования с использованием ключей;
Цифровая подпись, являющаяся доказательством того, кто был отправителем сообщения, в случае приема и того, кто получил, в случае передачи сообщения.
Объекты безопасности в соответствии с моделью включают: пользователей, группы, привилегии, права доступа к ресурсам, файлы аудита, программы, пароли, ключи шифрования и др.
Управление безопасностью - это администрирование, управление и контроль выполнения стратегии защиты предприятия. Все действия, связанные с использованием защищаемых в системе ресурсов, должны отражаться в специальных файлах регистрации событий (аудит системы).
Управление безопасностью осуществляется вне администрирования управления доступом. Основным является регистрация пользователей системы и их документов, управление программами, данными и информацией, связанной с безопасностью (например, криптографическими ключами). Файлы регистрации событий обрабатываются, таким образом, чтобы предоставлять удобочитаемую информацию для выполнения контрольных функций.
Функции управления безопасностью обеспечивают управление:
Защитой системы;
Службами безопасности;
Механизмами защиты.
Вопросы управления безопасностью связаны с обеспечением безопасности в среде открытых систем, управлением:
Стратегией безопасности (создание и сопровождение профилей безопасности пользователей и ресурсов, и спецификаций целостности безопасных систем);
Регистрацией объектов безопасности с соответствующими правами (домены безопасности, политики безопасности, метки защиты и криптографические алгоритмы);
Аудитом системы безопасности;
Восстановлением системы безопасности;
Предупреждениями (сообщениями) системы безопасности;
Взаимодействием с другими управляющими функциями системы.
Важным понятием, возникающим применительно к распределенной защите системы, является свойство доверенности . Система называется доверенной, если существуют гарантии того, что:
Службы и механизмы безопасности системы изолированы и их нельзя обойти обычным пользователям и прикладным программам;
Службы безопасности эффективно фиксируют угрозы безопасности, для преодоления которых они были разработаны;
Административный персонал, сопровождающий систему, обладает необходимыми навыками для работы с системой в безопасном режиме и ставит интересы корпорации выше своих собственных.
Для распределенной системы характерны следующие доверенные и недоверенные компоненты:
Недоверенные системы, к которым можно отнести персональные рабочие станции, так как они могут легко перемещаться пространственно, присоединяться к произвольным сетевым адресам, эксплуатироваться с неизвестной операционной системой;
Недоверенные коммуникационные средства, используемые для соединения различных вычислительных систем, например, коаксиальные кабели и линии спутниковой связи , соединяющие машины клиента и сервера; специальными средствами можно идентифицировать атаку на этом уровне, например, незаконное подключение, но предотвратить ее трудно;
Недоверенные промежуточные системы (шлюзы), в которых запрос системы защиты, например на аутентификацию, при своем следовании по коммуникационной среде может проходить через различные узлы, находящиеся в зоне ответственности различных предприятий и даже стран;
Недоверенные клиенты; клиентское программное обеспечение является подмножеством прикладного программного обеспечения и действует от его имени, при этом нет гарантии, что от имени приложения поступают только разрешенные запросы; при отсутствии постоянного физического контроля за рабочей станцией и специальной шифрованной подписи при старте ОС на ней нет гарантии, что на станции выполняется именно доверенная операционная система;
Доверенное тождество пользователя/клиента подразумевает, что клиент или приложение работают под уникальным идентификатором, распределенная система обладает средствами, обеспечивающими установления этого доверенного тождества; обычно доверенное тождество (идентификатор) устанавливается доверенной функцией аутентификации;
Доверенное тождество сервера, гарантирующее правильное выполение обслуживания; установление тождества сервера - двустороннее (устанавливается тождество сервера и клиента);
Доверенное администрирование; администрирование распределенной системы должно быть доверенной функцией; задачи, выполняемые администратором системы, ревизором и операторами системы безопасности реализуются набором приложений; приложения администрирования, системы, на которых они выполняются, и сетевое соединение с серверами должны быть доверенными с целью подтверждения целостности информации, связанной с безопасностью, на каждом сервере.
Системы с минимальным числом доверенных компонент называются открытыми. Примером такого рода систем может служить сетевая вычислительная среда университетов, Доверенными являются только объекты самого верхнего уровня - идентификаторы (тождества) распределенной системы, сервера и администрирование. Только доверенные сервера в такой системе нуждаются в службах аутентификации/сертификации. Все другие элементы системы (клиенты и сервера) сами отвечают за контроль за доступом.
Альтернативным является подход, когда доверенные элементы спускаются как можно ниже по сетевой иерархии - эти системы называются "закрытыми". Типичным примером является доверенная сеть, где контролируется доступ к системе и коммуникационной среде.
На практике закрытые и открытые системы часто используются совместно. В частности, распределенная система требует закрытой подсети для администрирования серверов и специальных клиентов, осуществляющих администрирование. Все связанные с безопасностью функции администрирования должны быть доверенными. С другой стороны, доверенные сети администрирования могут использовать для работы те же магистральные сети, что и другие клиенты и серверы. Но для доверенных компонент обязательно использование специальных функций, таких как аутентификационные сообщения, цифровая подпись и шифрование.
4.2. Использование механизмов защиты сетевых операционных систем Windows NT/2000
Для обеспечения информационной безопасности корпоративных сетей ФЖТ предусматривается задействовать встроенные механизмы защиты следующего программного обеспечения:
Операционных систем Windows NT 4.0 и Windows 2000;
Средств управления коммутаторами и других.
4.2.1. Основные компоненты системы безопасности Windows NT
В операционной системе Windows NT существует единая система для идентификации, проверки подлинности (аутентификации), контроля (разграничения) доступа и записи информации о событиях (аудита), связанных с безопасностью. В рамках данной архитектуры все объекты и все процессы Windows NT подчиняются требованиям системы безопасности, включающей в себя несколько основных компонентов (рис. 4.2).
Процессы входа в систему (logon processes) обрабатывают запросы пользователей о входе в систему. Сюда включается начальный интерактивный вход в систему (interactive logon), осуществляемый через диалоговое окно входа пользователя, и процессы удаленного входа (remote logon), открывающие доступ к серверу Windows NT с удаленных компьютеров. Вход в систему обязателен для работы с сервером или рабочей станцией Windows NT.
Центральная часть системы безопасности Windows NT - Локальный администратор безопасности (Local Security Authority, LSA) - проверяет, есть ли у пользователя необходимые полномочия для входа в систему. Этот компонент создает маркеры доступа, управляет локальными правилами безопасности (local security policy), обеспечивает службы интерактивной проверки подлинности. LSA также контролирует правила аудита и записывает в журнал аудита сообщения, полученные от Монитора безопасности.
Диспетчер учетных записей (Security Account Manager, SAM) поддерживает базу данных учетных записей (Security Account Database). В ней хранятся все учетные записи пользователей и групп. Эта база является частью реестра операционной системы и недоступна обычным пользователям в ходе нормальной работы. SAM обеспечивает службы подтверждения подлинности пользователя, используемые администратором локальной безопасности.
Монитор безопасности (Security Reference Monitor, SRM) проверяет, имеет ли пользователь достаточные права для доступа к объекту. В отличие от других компонентов системы безопасности он работает в режиме ядра. Компоненты ядра и пользовательские процессы обращаются к Монитору безопасности, чтобы выяснить, имеют ли право пользователи и процессы получить доступ к объекту. SRM хранит в себе весь код, ответственный за подтверждение доступа, и это единственная копия данного кода для любой системы Windows NT. Благодаря этому все проверки выполняются одинаково для всех объектов в системе.
Журнал аудита (Security log) содержит записи о событиях, связанных с работой системы безопасности. Сюда может заноситься информация о входах пользователей, изменениях в базе учетных записей и системной политике, событиях доступа пользователей к секретным файлам.
Пакет проверки подлинности (Authentication package) проверяет подлинность пользователя. Windows NT по умолчанию использует пакет проверки подлинности MSV1_0, однако эта операционная система может поддерживать несколько таких пакетов, выполненных как динамические библиотеки DLL. Благодаря этому независимые поставщики программного обеспечения могут включать в Windows NT свои модули проверки подлинности.
Пакет MSV1_0 обращается к Диспетчеру учетных записей, причем последний может находиться как на локальном, так и на удаленном компьютере. Технически это достигается разбиением пакета на две части. Одна выполняется на компьютере, где осуществляется вход пользователя, другая - на компьютере, который хранит базу учетных записей. Пакет MSV1_0 по имени домена определяет, где находится база данных учетных записей, и, если она расположена на удаленном компьютере, первая часть пакета передает запрос на удаленный компьютер, где вторая часть пакета MSV1_0 проверяет подлинность. Этот процесс называется сквозной проверкой подлинности (pass-through authentication).
4.2.2. Архитектуры системы безопасности Windows NT 5.0
В рамках архитектуры системы безопасности Windows NT 5.0 реализованы новые подходы к проверке подлинности пользователя и защиты данных :
Полное интегрирование с активным каталогом Windows NT 5.0 - для обеспечения масштабируемого управления учетными записями в больших доменах с гибким контролем доступа и распределением административных полномочий;
Протокол проверки подлинности Kerberos версии 5 - зрелый стандарт безопасности для Интернета, реализуемый как основной протокол проверки подлинности сетевого входа;
Усиленная проверка подлинности с применением сертификатов, основанных на открытых ключах;
Безопасные сетевые каналы, основанные на стандарте SSL;
Файловая система с шифрованием.
4 . 2 .2.1. Активный каталог
В версиях Windows NT до 4.0 информация о всех учетных записях хранится в реестре контроллеров домена. Доверительные отношения и сквозная проверка подлинности дают известную гибкость при управлении учетными записями и доступом к ресурсам. Однако внутри домена учетные записи образуют линейное одноранговое пространство имен, не позволяющее ввести внутреннюю иерархию.
Распределенные службы безопасности Windows NT 5.0 хранят сведения об учетных записях в активном каталоге (Active Directory). Последний существенно улучшает производительность и масштабируемость по сравнению с реализацией, основанной на реестре, и в то же время предоставляет гораздо более богатые возможности для администрирования.
Технически активный каталог основан на объединении двух стандартов:
Х.500 - принятой международной организацией по стандартам специикации на структуру и функционирование универсального каталога, и службы имен DNS - стандарта сети Интернет.
Достоинства активного каталога:
Учетные записи пользователей и групп можно распределить по контейнерам - подразделениям (Organization Unit, OU). Домен в рамках иерархического пространства имен может содержать любое количество подразделений. Это позволяет организациям добиться соответствия между используемыми в сети именами и структурой предприятия.
Активный каталог поддерживает гораздо большее (более 1 количество объектов и с более высокой производительностью, чем реестр. Дерево объединенных доменов Windows NT способно поддерживать существенно более сложные организационные структуры.
Администрирование учетных записей улучшено благодаря новым графическим средствам управления активным каталогом, а также за счет обращающихся к СОМ-объектам активного каталога сценариев.
Службы тиражирования каталога поддерживают множественные копии учетных записей. Теперь обновление информации можно выполнить для любой копии учетной записи (не требуется разделения контроллеров домена на главный и резервные). Протокол Lightweight Directory Access Protocol (LDAP) и службы тиражирования обеспечивают механизмы для связи каталога Windows NT 5.0 с другими, основанными на Х.500 и LDAP каталогами на предприятии.
4.2.2.2. Распределение административных полномочий
В активном каталоге пользователи и группы представлены объектами. Доступ на чтение и запись определяется списком разрешений и может быть предоставлен ко всему объекту целиком или только к некоторым его частям. Это позволяет администратору решить, кто и что может изменить для данной категории учетных записей.
Операционная система Windows NT определяет взаимодействие активного каталога и служб безопасности. В активном каталоге хранятся правила безопасности домена (например, ограничения на пароли) и учетные записи. Доступ к этой информации надежно защищен. При определении прав доступа активный каталог, как и другие процессы-серверы, использует процедуру олицетворения (авторизации). Это означает, что права доступа по запросам клиентов по протоколу LDAP проверяются операционной системой, а не самим активным каталогом. В свою очередь компоненты системы безопасности Windows NT доверяют информации, хранящейся в активном каталоге.
Для эффективного управления корпоративной сетью необходимо обеспечить распределение административных полномочий. Важно, чтобы локальный администратор небольшого коллектива , имея возможность самостоятельно решать все вопросы, связанные с предоставлением прав своим пользователям, не мог бы управлять учетными записями других частей предприятия.
Ответственность за создание новых пользователей и групп делегируется на уровень подразделений (т. е. на уровень контейнера), где и создаются учетные записи. Однако правила безопасности домена, определенные на более высоком уровне, могут действовать по всему дереву подразделений путем наследования прав доступа.
Административные полномочия можно распределить несколькими способами:
Разрешить изменять свойства данного контейнера, что позволит определять свои правила безопасности;
Разрешить создавать объекты внутри контейнера, такие как пользователи, группы и принтеры;
Разрешить изменять только определенные свойства объектов внутри контейнера, например, изменить пароль.
4.2.2.3. Поддержка множественных протоколов безопасности
Чтобы обеспечить совместимость с существующими клиентами, предоставить более эффективные механизмы безопасности и сделать возможным взаимодействие в гетерогенных сетях, в Windows NT поддерживаются несколько протоколов безопасности. Архитектура Windows NT не устанавливает ограничений на применение тех или иных протоколов безопасности. При использовании интерфейса программирования Win32-пpилoжeния изолированы от деталей реализации конкретного протокола.
Windows NT 5.0 поддерживает:
Протокол проверки подлинности Windows NT LAN Manager (NTLM), используемый в Windows NT 4.0 и в предыдущих версиях Windows NT;
Протокол проверки подлинности Kerberos Version 5, заменяющий NTLM в роли основного протокола для сетевого доступа к ресурсам доменов Windows NT 5.0; Kerberos можно рассматривать как «интернетовский» стандарт;
Протокол распределенной проверки подлинности паролей (Distributed Password Authentication, DPA) - популярный в организациях, оказывающих услуги в Интернете, таких как MSN и CompuServe;
Протоколы, основанные на открытых ключах и применяемые в основном для связи между программами просмотра и Web-серверами; стандартом de facto здесь стал протокол Secure Sockets Layer (SSL).
Для единообразного обращения к различным протоколам разработан новый интерфейс прикладного программирования Win32 - интерфейс поставщиков поддержки безопасности (Security Support Provider Interface, SSPI). SSPI позволяет изолировать проверку подлинности пользователя, которая может осуществляться применяющими ее службами и приложениями по разным протоколам.
Интерфейс SSPI представляет собой несколько наборов доступных прикладным программам процедур, выполняющих:
Управление мандатами (Credential Management) - работу с информацией о клиенте (пароль, билет и т. д.);
управление контекстом (Context Management) - создание контекста безопасности клиента;
поддержку передачи сообщений (Message Support) - проверку целостности переданной информации (работает в рамках контекста безопасности клиента);
управление пакетами (Package Management) - выбор протокола безопасности.
Процедуры управления контекстом пользователя позволяют серверу выполнить авторизацию клиента и, тем самым, предотвратить несанкционированный доступ к данным при выполнении запроса.
Таким образом, система безопасности Windows NT представляется довольно развитой и, при определенных условиях, может служить базисом для построения системы защиты КС от внутренних угроз.
Несмотря на довольно развитые встроенные средства обеспечения защиты информации , в ОС Windows NT существуют определенные проблемы, которые, в принципе, могут привести к возникновению различных угроз безопасности. К таким проблемам можно отнести:
Настройки Windows NT по «умолчанию» не обеспечивают должного уровня защиты. В качестве примера можно привести известную программу «Red Button», «ломающую» защиту Windows NT, благодаря наличию в реестре разрешения доступа для анонимного пользователя. При реализации плана мероприятий по защите КС должен быть определен подробный перечень настроек системных параметров, нуждающихся в корректировке;
Ошибки и недоработки в реализации программного кода системы, воспользовавшись которыми злоумышленник может создать угрозу безопасности. Данная проблема характерна практически для всех систем. Например, известна ошибка (получившая название «Land Attack»), приводящая к «зависанию» (отказу в обслуживании) систем Windows95 и NT, Unix и целого ряда маршрутизаторов. Здесь необходимо постоянно отслеживать информационные сообщения соответствующих организаций и вовремя проводить доработки систем;
Возможность получения полного неавторизованного доступа к файловой системе Windows NT при загрузке компьютера с системной дискеты (MS-DOS с драйвером NTFS). Это довольно серьезная "брешь" в системе безопасности NT и решить ее можно только полным исключением возможности загрузки компьютеров с ГМД на аппаратном уровне. Наилучшим вариантом решения такой проблемы может оказаться применение специальных аппаратных идентификаторов Touch Memory.
В результате разработки системы защиты информации КС от внутренних угроз должны быть проработаны все вопросы, касающиеся штатных средств защиты Windows NT, разработаны организационно-методические документы, касающиеся правил настройки системы и ее эксплуатации, а также, при необходимости, выбраны или разработаны дополнительные продукты, обеспечивающие необходимый уровень безопасности.
4.3. Средства защиты информации в базах данных
Системы управления базами данных, преимущественно реляционные СУБД, стали главным инструментом хранения больших массивов данных. Современные информационные приложения ориентированы не на файловые архитектуры операционных систем, а на многопользовательские СУБД, выполненные по технологии клиент-сервер. Поэтому обеспечение информационной безопасности СУБД (конфиденциальности, целостности и доступности) и, в первую очередь их серверных компонентов определяет безопасность корпорации в целом. В отличие от mainframes, где базы данных разделяют средства с операционной системой, в клиент-серверных приложениях пользователи получают возможность миновать процедуру загрузки в ОС и обращаться напрямую к базам данных, где средства защиты менее надежны.
В целом механизмы обеспечения безопасности, используемые в базах данных, делятся на две группы: базовые механизмы и средства обеспечения сетевой безопасности. Базовые средства предназначены, в первую очередь, для защиты ресурсов и объектов баз данных. Наличие таких средств обязательно для распределенных систем коллективного доступа, и в той или иной мере они реализованы в любой многопользовательской ОС или СУБД. Сетевые средства служат для защиты систем связи и устранения характерных угроз, возникающих в сетевых средах.
Общая идея защиты баз данных состоит в следовании рекомендациям, сформулированным для класса безопасности С2, хотя в принципе, некоторые СУБД предлагают дополнения, характерные для класса В1. Практическое применение таких решений оправдано только для случаев, когда все компоненты информационной структуры предприятия соответствуют категории безопасности В1.
В распределенной инфосреде обязательным является наличие следующих компонентов борьбы с потенциальными угрозами :
Идентификации и проверки подлинности (аутентификация) пользователей (применяются либо соответствующие механизмы ОС, либо SQL‑оператор CONNECT);
Управления доступом к данным, когда владелец объекта передает права доступа к нему (привилегии доступа) по своему усмотрению;
Механизма учета всех действий, влияющих на безопасность;
Защиты регистрационной информации от искажений.
СУБД имеют строгую внутреннюю организацию, а операции над элементами структур определены достаточно четко. Как правило, эти операции включают в себя четыре основных действия - поиск, вставку, удаление и замену элемента, а остальные носят вспомогательный характер и применяются достаточно редко. Это упрощает решение задачи защиты СУБД; в то же время, если используется СУБД с недостаточно надежными защитными механизмами или плохо протестированная версия СУБД, защита на уровне СУБД становится уязвимой со стороны внешних угроз.
Основным средством взаимодействия с реляционными СУБД является язык SQL (Structured Query Language) - непроцедурный инструмент определения и манипулирования данными. В самом стандарте SQL уже определены некоторые механизмы обеспечения безопасности. Так в соответствии с идеологией языка SQL контроль прав доступа пользователя к таблицам баз данных производится на основе механизма привилегий. Его смысл состоит в том, что для выполнения любого действия над таблицей пользователь должен обладать соответствующей привилегией (реально все возможные действия описываются фиксированным стандартным набором привилегий). Пользователь, создавший таблицу, автоматически становится владельцем всех возможных привилегий на выполнение операций над этой таблицей. В число этих привилегий входит привилегия на передачу всех или некоторых привилегий по отношению к данной таблице другому пользователю, включая привилегию на передачу привилегий.
В стандарте SQL/89 определяется упрощенная схема механизма привилегий. Во-первых, назначение привилегий возможно только при определении таблицы. Во-вторых, пользователь, получивший некоторые привилегии от других пользователей, может передать их дальше только при определении схемы.
В стандарте SQL/92 появилась возможность создавать хранимые и представляемые таблицы и задавать или удалять привилегии доступа (операторы CREATE TABLE, CREATE VIEW, GRANT, REVOKE) в любой момент времени, в любой транзакции вне оператора определения схемы. Появились операторы уничтожения таблиц (DROP TABLE и DROP VIEW), которые также можно выполнять внутри любой транзакции (при наличии соответствующих привилегий). Вообще, следует заметить, что в стандарте SQL/92 для любого оператора класса CREATE существует парный оператор класса DROP. Специфицирован также оператор ALTER TABLE, позволяющий динамически изменять характеристики ранее созданной таблицы (в частности добавлять к ней новые столбцы).
В добавление к возможностям SQL/89 определения ограничений целостности на уровне столбца и/или таблицы в SQL/92 допустимо отдельное определение ограничений, распространяющееся в общем случае на несколько таблиц. Появилась возможность определения отложенных (проверяемых при завершении транзакции) ограничений целостности. Расширены возможности определения ограничений внешнего ключа (ограничений ссылочной целостности). Введены средства определения (CREATE DOMAIN), изменения (ALTER DOMAIN) и отмены определения (DROP DOMAIN) домена (возможно множество значений некоторого типа данных).
Рассмотрим базовые механизмы обеспечения безопасности в сервере баз данных Oracle 8 корпорации Oracle, который находит широкое применение в корпоративных сетях ж. д. транспорта. Нужно сказать, что продукт Oracle 8 имеет существенные отличия от Oracle 7: наличие встроенного языка Java в качестве языка базы данных (совместим с SQL), встраивание Web-сервера и платформы разработки WebDB, секционирование (partitioning) как возможность разбиения на разделы таблиц и индексов, более производительная реализация типов данных LONG, расширение компонентов объектно-ориентированной технологии (объектные типы, представления, язык, объектный API-интерфейс и др.), новые возможности управления паролями, включение менеджера восстановления Recovery Manager и др..
Oracle 8 содержит большой набор новых возможностей по обеспечению безопасности в двух классах: защита баз данных и защита баз данных, используемых в Internet. Прежде чем пользователь получит доступ к базе данных, он должен быть идентифицирован СУБД. Идентификация может быть трех видов: идентификация в базе данных, внешняя идентификация и идентификация на уровне предприятия.
Идентификация в базе данных используется при первичной регистрации (создание учетной записи) пользователя и указании пароля. Система предоставляет возможность управления паролями. Это осуществляется методом установки параметров профиля и назначения этого профиля пользователю. Профиль - это элемент базы данных, в котором указываются ограничения на использование ресурсов. В профиле может быть ограничено количество сеансов, использование центрального процессора для одного сеанса, количество вызовов центрального процессора и др.
С помощью профиля можно применить правила управления паролями, которые могут быть выбраны как опции при настройке:
Блокировка учетной записи пользователя, если последний многократно допускает ошибку при регистрации;
Время жизни пароля и прекращение его действия по истечении срока;
Предыстория пароля - определения того, не используется ли пароль повторно на заданном интервале времени;
Контроль уровня сложности пароля (устойчивости к взлому);
Идентификация администратора базы данных, соответствующая привилегированному характеру их действий и др.
Внешняя идентификация предполагает использование средств операционной системы или сетевых средств идентификации Сетевая идентификация, выполняемая с помощью OAS (Oracle Advanced Security) может использоваться в следующих сетевых технологиях:
Нет аккаунта - нет отслеживания: российские разработчики создали мессенджер на блокчейнеРоссийские разработчики создали P2P-мессенджер CallBox на базе технологии блокчейн, который позволяет совершать звонки и вести переписку в условиях полной анонимности. О том, как новый проект способен изменить сферу коммуникаций, редакция ForkLog поговорила с создателем проекта Евгением Демидовым.
По его словам, CallBox появился на волне популяризации Telegram и других мессенджеров, позиционирующих себя в качестве средств коммуникации с повышенной безопасностью.
«Архитектура этих мессенджеров не гарантирует пользователям, что их сообщения действительно могут быть просмотрены только ими. Более того, каждый пользователь является однозначно идентифицированным по номеру телефона. В результате компания-разработчик таких продуктов имеет базу всех пользователей, в добавок пропуская через себя все сообщения. И если контент сообщений для некоторых из них наверняка действительно недоступен, то они в любом случае имеют полную информацию, кто, с кем и когда коммуницировал», - отметил Евгений Демидов.
В свою очередь, команда CallBox при разработке своего приложения отказалась от аккаунтов и адресной книги в пользу безопасности.
«У нас нет сервера вообще, мы не пропускаем через себя ни звонки, ни сообщения пользователей, и не храним их аккаунты. Приложение при запуске не спрашивает у пользователя ничего: ни имени, ни телефонного номера, ни e-mail, ни кода доступа. Можно сразу нажимать кнопку создания чата или звонка», - объяснил Демидов.
При нажатии на кнопку генерируется специальная ссылка с уникальным временным идентификатором, содержащим данные для связи с этим устройством. Пользователь передает эти данные любым доступным способом: через почту или мессенджер. Адресат, переходя по ссылке, созванивается или переписывается с собеседником. Прямое P2P-соединение защищается сквозным шифрованием. Для следующего сеанса связи нужно отправить еще одну ссылку.
«Сейчас мы проводим тестирование нашей блокчейн-сети: начальная связь абонентов осуществляется через случайный экземпляр ноды. Ее владелец за каждый факт связи получает некоторое вознаграждение. После тестирования мы выпустим обновление приложения и начнем распространять ноды с открытым исходным кодом, а также откроем исходные коды самого приложения», - поделился планами автор мессенджера.
Создатель CallBox подчеркнул, что децентрализация способна повысить эффективность взаимодействия участников систем во многих отраслях.
«Мы не имеем огромной аудитории, поэтому в ближайшее время нет цели потеснить WhatsApp. Тем не менее, мы нацелены создать сильную конкуренцию таким продуктам как Threema и Wickr, полностью заняв их нишу», - резюмировал Евгений Демидов.
Приложение CallBox доступно для скачивания в Google Play .
Напомним, ранее ForkLog сообщал, что разработчик приватного мессенджера Wickr получил патент на использование блок.чейна в процессе переписки.
Напомним, проект Wickr был создан в 2011 году и на сегодняшний привлек около $73 млн в венчурных капиталах. В 2015 году мессенджер первым начал использовать «канареечные гарантии», то есть оповещать пользователей о том, связывались ли с ними представители государственной власти.«Канареечная гарантия» - это способ, которым онлайн-провайдеры услуг сообщают пользователям, что с ними не связывались власти . Также такое сообщение может использоваться для хранения даты и времени, если с провайдером связались чиновники. Такие гарантии имеют в США и большей части Великобритании юридическую силу, а в Австралии был издан закон против такого типа гарантий. В мире такие гарантии имеют сотни технологических фирм – среди них Adobe, Medium, CloudFlare и многие другие. Другие компании, такие как Apple, размещали такие гарантии прежде, однако впоследствии удалили их со своих сайтов, чем вызвали у некоторых тревогу.
Архитектура информационной безопасности помогает сопоставить текущее состояние обеспечения безопасности с желаемым и определить, как его достичь оптимальным образом. Отталкиваясь от утвержденной всеми заинтересованными сторонами этой архитектуры, можно тр
Архитектура информационной безопасности особенно важна в нестабильной экономической ситуации, когда денег на все, что «хочется», уже нет, и все проекты должны быть увязаны с выживанием бизнеса в условиях кризиса. Только четко выстроенная архитектура позволяет не сбиться с пути и достичь поставленных целей.
Как мы помогаем удовлетворять потребности бизнеса в информационной безопасности (ИБ) сейчас и как мы это будем делать через год? Для некоторых предприятий и пять лет - очень малый интервал времени, так как они привязывают свои планы к сроку жизни, например, гидротурбины или доменной печи, проектный срок службы которых может составлять пятьдесят лет. Учет достаточно длительных временных периодов - ключевое отличие хорошей архитектуры от плохой.
Можно выделить пять основных причин, по которым обращаются к архитектуре ИБ:
Надоело бороться с несогласованностью действий подразделений, участвующих в организации ИБ - ИТ департамента, юридического департамента, внутреннего контроля и т.п.
Растет неудовлетворенность пользователей и руководства текущим состоянием ИБ на предприятии.
Возникает непонимание путей развития ИБ в компании. Не определены приоритеты проектов и технологий.
Служба ИБ хочет вырваться из пут негативного отношения к себе, зажатости в узких рамках, не дающих продемонстрировать свою ценность бизнесу.
Видно, что, как правило, архитектура ИБ нужна крупным предприятиям - в малом бизнесе описанных проблем нет или они стоят не так остро. Крупным же компаниям архитектура не нужна только в условиях стабильности (которой сейчас нет).
Вот некоторые из следствий отсутствия архитектуры ИБ:
Финансирование по остаточному принципу. Если вы не знаете, куда движетесь и как влияете на бизнес компании, то зачем в вас вкладывать деньги?
Неудовлетворенность всех слоев пользователей тем, как защищается конфиденциальная информация и другие виды тайн, как обеспечивается защита при доступе в Internet, как обрабатывается электронная почта (читается сотрудниками службы ИБ или вообще не доходит до адресата по причине отнесения ее к спаму).
Потенциальные претензии со стороны регуляторов, чьи требования обычно не согласованы и противоречивы. Все либо мечутся, пытаясь удовлетворить всем требованиям, либо закрывают на них глаза до очередной проверки.
Неэффективность ИБ на предприятии в силу игнорирования отдельных аспектов деятельности (например, наличия удаленного подключения разработчиков систем АСУТП для поддержки через Internet), что приводит к неприятным инцидентам.
Несогласованность или даже прямое противодействие различных подразделений, на каждое из которых возложены (обычно неформально) отдельные обязанности по обеспечению информационной безопасности. Отсутствие четкого разделения зон ответственности, (которое обычно прописывается в архитектуре), которое приводит либо к перетягиванию одеяла на себя, либо к нежеланию брать на себя «чужой» фронт работ.
В пользу архитектуры можно привести еще один пример. Часто из уст производителей тех или иных технических средств можно услышать, что внедрение нового продукта сразу позволит решить все возникшие проблемы. А так как проблемы описываются вполне реальные, то покупатель верит. На практике на новинку тратятся громадные деньги, а эффективность этих инвестиций либо не измеряется, либо является отрицательной. Хотя быть среди первых иногда означает обогнать конкурентов, все же не стоит необдуманно покупать технологические новинки только потому, что их активно рекламирует производитель. Правильная архитектура позволит нам не поддаться на уговоры продавца и заниматься только теми проектами, которые направлены на достижение целей предприятия, а не разработчика.
Архитектура ИБ и другие
Архитектура ИБ не висит в воздухе - она является неотъемлемой частью архитектуры предприятия. Учитывая накопленный опыт в разработке ИТ-архитектуры, можно задать вопрос: почему архитектура ИБ не должна быть составной частью ИТ-архитектуры?
Информация сегодня ценна как никогда, и мы должны обезопасить ее от случайных и умышленных посягательств. Но… несмотря на ИТ поддержку всех аспектов бизнеса, сегодня огромный пласт информации представлен в бумажной форме, и она тоже подлежит защите. Видеоконференции и видеосессии, голосовые приложения и IP-телефония тоже содержат информацию, которая подлежит защите. Но часто ли об этом думают ИТ-подразделения? Традиционно это не их сфера ответственности. Именно поэтому архитектуры ИБ- и ИТ-поддержки бизнеса должны разрабатываться независимо друг от друга, но, разумеется, с перекрестными ссылками. Информационная безопасность на 70% основана на ИТ, а последние в свою очередь не могут не учитывать требования по безопасности.
Не менее важна связь архитектуры и стратегии ИБ со стратегией бизнеса (см. ). Как правило, видение служб ИБ не только будущего, но и текущей ситуации отличается от точки зрения бизнеса. Служба ИБ озабочена защитой периметра организации, а бизнес переходит на системы коллективной работы, активное использование унифицированных коммуникаций и вообще открывает границы для партнеров, поставщиков и клиентов. Точки продаж и доставки продукта сдвигаются как можно ближе к клиенту, расширяя периметр, делая его нечетким. Важные с точки зрения ИБ задачи совершенно выбиваются из канвы развития бизнеса, потому что действия службы информационной безопасности никак не согласуются с бизнес-стратегией.
Но даже если мы свяжем стратегии ИБ и бизнеса, то важно понимать, что безопасность существует для бизнеса, а не наоборот. Об этом часто забывают, перекрывая на межсетевом экране важные протоколы, блокируя доступ к сайтам, запрещая отдельным сотрудникам работу в Internet. Мотивация простая: «это не разрешено службой информационной безопасности». В результате службу ИБ часто называют «business prevention department», то есть препятствующей бизнесу, а не способствующей ему. Еще никогда изменение бизнес-процессов под существующую или закупаемую систему защиты не приводило к положительным результатам. Работа должна вестись в обратном порядке - система защиты разрабатывается или дорабатывается под принятые в компании правила бизнеса. Да, некоторая трансформация возможна, но не в глобальном масштабе. Ускорять, улучшать, облегчать бизнес-процессы? Да, это правильно. Но не блокировать, затруднять или полностью изменять их.
Правильный путь к архитектуре
Архитектура ИБ отражает ее состояние в определенный момент времени. И хотя сложно себе представить полностью застывшую систему, в которой не происходит никаких изменений, все же архитектура играет большую роль в деятельности любой службы ИБ. Как из текущего состояния перейти в новое, более совершенное и соответствующее целям бизнеса? Для этого существует стратегия, то есть направление движения для достижения поставленных целей (см. рис. 2).
Стратегия - это структурированный и взаимосвязанный набор действий, нацеленных на улучшение в долгосрочном плане благополучия предприятия. Имея перед собой цель в виде архитектуры ИБ, стратегия определяет оптимальный путь движения к ней.
Правда, оптимальность можно понимать по-разному. В одном случае в качестве критерия оптимальности выбирается время. В другом - может выступать цена вопроса и т.п. В «худшем» случае нам необходимо оптимально достичь сразу несколько целей. Однако известный закон Лермана гласит, что «любую задачу можно решить, имея достаточно времени и денег», а следствие Лермана уточняет: «Вам никогда не будет хватать либо времени, либо денег». Нельзя сделать одновременно быстро, дешево и хорошо. Лучше выбрать один критерий, которым и руководствоваться в работе.
У нас часто не разделяют понятия стратегии и архитектуры и разрабатывают ИТ-стратегию, которая включает в себя описание архитектуры. Это не совсем правильно, поскольку архитектура, то есть цели, у вас с течением времени могут и не меняться, а вот стратегия их достижения может претерпевать серьезные изменения в зависимости от внешних или внутренних условий и факторов. Объединяя стратегию и архитектуру в один документ, мы вынуждаем себя при изменении стратегии пересматривать и архитектуру. Хотя в конечном итоге все зависит от конкретной ситуации - если такое объединение помогает решить задачу, то зачем от него отказываться только по той причине, что обычно так не делают?
Что включать в архитектуру ИБ?
Архитектура, по мнению древнегреческого архитектора Витрувия, базируется на трех основных началах - прочность, польза и красота. В XV веке Альберти добавил четвертое начало - целесообразность. За сотни лет эти принципы не претерпели никаких изменений. Архитектура должна содержать взаимосвязанные компоненты, объединенные в единое целое (прочность). Архитектура должна активно использовать принцип «все гениальное - просто» и не использовать сложных и, как следствие, некрасивых решений и подходов. Кроме того, архитектура должна быть не только красивой, но и направленной на достижение поставленных целей, обладающих ценностью для собственников.
Информация . В данном разделе мы определяем классификацию информации с точки зрения ИБ, описываем виды ее представления и т.п. Это позволит не забыть, что информация может быть не только в виде файлов или электронных писем, но и в виде разговора по телефону, видеосессии, бумажного документа и даже устной речи (например, на заседании совета директоров).
Инфраструктура . Данный раздел помогает нам понять, где циркулирует информация, подлежащая защите. Это не только компьютеры, телекоммуникационное оборудование и системное ПО, но и оргтехника, архивы, канцелярия и другие места создания, обработки, хранения и передачи либо пересылки информации, подлежащей защите.
Информационные системы . Этот раздел позволяет понять, в каких прикладных системах обрабатываются, анализируются, консолидируются данные, нужные бизнесу. Это могут быть ERP-, CRM-, SCM-, SCADA-системы, биллинг и многие другие виды прикладного ПО. Если в компании внедрена сервисная методология (например, ITIL), то в этот раздел попадают и услуги, которые различные службы (ИТ, маркетинг и т.п.) предоставляют бизнесу.
Информационная безопасность
. Здесь определено, как информационная безопасность будет достигать поставленных целей. Никаких технических деталей тут не требуется -
скорее, это описание ключевых направлений деятельности и принципов обеспечения ИБ. В частности,
какова политика в области средств защиты? Разрабатываются они собственными силами или приобретаются в виде готовых решений? Как будут решаться задачи - своими силами или потребуется обращение к аутсорсингу? Будет ли использоваться соглашение об уровне обслуживания? И так далее.
ИБ-служба . Данный раздел описывает цели департамента информационной безопасности, его задачи, структуру, методы управления персоналом и другие аналогичные вопросы.
При разработке архитектуры должен быть проведен анализ текущего состояния ИБ на предприятии. Ответ на вопрос «как есть» поможет проложить мостик к ответу на вопрос «как должно быть» (см. ), поэтому каждый из описанных выше логических разделов архитектуры будет содержать два подраздела - «как есть» и «как будет».
Повторять в данной архитектуре бизнес-цели стоит, только если в компании отсутствует документированная бизнес-стратегия. В этом случае ключевые моменты стоит отразить в архитектуре ИБ, чтобы понимать те исходные данные, от которых мы отталкиваемся.
Являясь документом, отражающим долгосрочные цели, архитектура ИБ должна учитывать не только сиюминутные и внутренние, но и долговременные внешние воздействия бизнес-среды. К ним относятся:
Направления развития технологий (ИТ, ИБ и других). Например, если сегодня ПО активно приобретается и ставится на баланс предприятия, то через несколько лет не исключено, что даже ключевые процессы будут реализованы за счет модели «ПО как услуга» (Software-as-a-Service, SaaS).
Аналогичная ситуация и с безопасностью.
Сегодня многие устанавливают антивирусы как самостоятельные продукты, а через два - три года этот класс защитных средств может совсем уйти с рынка, будучи замененным встроенными в операционные системы или даже материнские платы антивирусами или UTM-решениями для ПК, которые, помимо антивирусной составляющей, будут включать в себя контроль утечек информации, отражение атак, контроль приложений, шифрование информации на диске и т.п.
Отраслевая специфика, экономическая и политическая ситуация в России и мире. Эти факторы не очень легко учитывать, поскольку они не всегда предсказуемы, но отдельные внешние процессы поддаются прогнозу. Например, процесс консолидации в отдельных сегментах рынка подскажет нам, что, возможно, наше предприятие скоро обзаведется новыми активами, которые должны быть учтены в архитектуре ИБ.
Планы регуляторов по выпуску новых нормативных актов. Появление нового нормативного акта (как это было с Федеральным законом «О персональных данных») может очень сильно изменить планы любой компании в области безопасности. Узнать о планах регуляторов не так сложно - о них постоянно говорят представители Госдумы, представители ФСТЭК, ФСБ и др.
Стратегия предполагает достижение заданных результатов деятельности. Как снизить риск неудачи и узнать, что мы достигли этих результатов или движемся в правильном направлении? Для этого существует стратегическая система измерений, которая отражает текущее состояние и тенденции развития. Примером ее является Security Balanced Scorecard, но возможно применение иных систем измерения информационной безопасности.
C чего начать?
Архитектура ИБ, как и многие другие архитектуры, должна разрабатываться сверху вниз, отталкиваясь от архитектуры и стратегии предприятия, в которых зафиксировано, что и как должно быть сделано в контексте всей компании. Архитектура и стратегия ИБ, в свою очередь, посвящены тому, как эти цели реализуются с точки зрения информационной безопасности.
Учет стратегии бизнеса позволяет нам понять в целом, на чем необходимо сконцентрироваться в архитектуре ИБ. Если, например, перед компанией стоит задача географической экспансии и серьезного роста, то и внедряемые решения в области информационной безопасности должны способствовать этой цели. В частности, большое внимание нужно уделить VPN-решениям, защищенному удаленному доступу и т.п. На этапе стабилизации бизнеса акцент смещается в сторону повышения качества обслуживания, роста лояльности клиентов, и информационная безопасность должна быть направлена именно на это. А вот в условиях нестабильной экономической ситуации и бизнес-решения коренным образом изменяются, и система безопасности уже решает совершенно иные задачи: защита от утечек и кражи информации со стороны увольняемых сотрудников, безопасность аутсорсинга и т.п.
Хотя теоретически грамотная разработка архитектуры и стратегии должна осуществляться сверху вниз (сначала определяем цели, затем способы их достижения и только затем начинаем приобретать различное ПО и аппаратуру, внедрять проекты и т.д.), на практике же все обычно происходит наоборот: сначала осуществляется закупка «нужных» средств защиты, которые у всех на слуху, потом начинается их эксплуатация, набиваются шишки при внедрении и поддержке, ведется поиск путей оптимизации имеющихся ресурсов и оценки эффективности используемых технологий и защитных мер и только после этого кто-то начинает (таких единицы) или начнет в будущем (таких большинство) задумываться о стратегии и архитектуре ИБ.
Вторым по распространенности после отсутствия архитектуры и стратегии является подход, заключающийся в выработке видения или плана применения технических решений или (в идеальном случае) организационных мероприятий:аудита безопасности, повышения осведомленности и т.п. И хотя это лучше, чем ничего, до разработки реальной архитектуры такой подход не дотягивает по двум причинам: отсутствуют целеполагание и привязка к бизнесу, и кроме того, отсутствуют метрики эффективности достижения заявленных целей.
Без этих двух пунктов вы никогда не сможете ответить на вопросы: куда мы стремимся, где сейчас находимся и далеко ли нам еще до цели?. Именно поэтому важно понимать, какая стратегия на уровне всего предприятия принята в компании. К счастью, таких стратегий (в чистом виде) не так уж и много и все они описаны в литературе по управлению бизнесом.
Один из вариантов разработки архитектуры и стратегии ИБ - начать с защиты критически важных бизнес-процессов, которые влияют на бизнес предприятия. Мы должны отталкиваться от критических факторов успеха. Если они известны (а еще лучше - задокументированы), то можно считать, что половина дела сделана - мы знаем, на чем концентрируется предприятие и его основные подразделения, и можем начать разработку архитектуры ИБ с проработки инструментов защиты ключевых бизнес-процессов. Основная сложность в данном подходе состоит в том, что не каждое предприятие в России в состоянии выделить не то что ключевые, а вообще какие-либо бизнес-процессы.
Если ключевые факторы успеха предприятия не выделены, то нам остается только одно - сделать это самостоятельно, привлекая все заинтересованные стороны. Лучше всего в данной ситуации создать комитет по ИБ, в который войдут представители ключевых подразделений компании. Именно они могут помочь прийти к консолидированному решению о целях и задачах бизнеса и на его основе строить информационную безопасность.
Алексей Лукацкий - бизнес-консультант по безопасности компании Cisco;
НЕОБХОДИМОСТЬ серьезного ремонта евроатлантической системы безопасности вполне очевидна. Министр иностранных дел России С.В.Лавров, выступая на Брюссельском форуме 21 марта этого года, прямо указал в этом контексте на живучесть менталитета и фобий холодной войны, мышление категориями "свой - чужой". По его словам, военные операции на Балканах, признание Косова, катастрофа в Закавказье в августе 2008 года, кризис ДОВСЕ, стагнация режимов укрепления доверия, рецидивы попыток изоляции России - далеко не полный ряд свидетельств слабости современной евроатлантической архитектуры. Путь к новой, отвечающей требованиям сегодняшнего дня евроархитектуре безопасности лежит через, как это предложил Президент Д.А.Медведев, разработку и заключение нового системообразующего для нашего общего пространства Евро-Атлантики документа - юридически обязывающего Договора о европейской безопасности (ДЕБ).
Идея российского президента нацелена прежде всего на совершенствование межгосударственных отношений в области "жесткой безопасности" ("hard security"). Именно здесь накопился большой массив вопросов, подрывающих взаимное доверие. В этом контексте нельзя не упомянуть и такие проблемы, как расширение НАТО, приближение военной инфраструктуры альянса к нашим границам, третьего позиционного района (ТПР) ПРО США, кризис ДОВСЕ.
Изложив свое видение опорных элементов будущих договоренностей, Россия сознательно не навязывает партнерам готовые рецепты. Наши предложения - это прежде всего приглашение к обстоятельному предметному диалогу, анализу причин функциональных сбоев нынешней системы, в последнее десятилетие ставших, к сожалению, регулярным явлением.
Многосторонний диалог по Договору о европейской безопасности активно набирает обороты на политическом уровне и по дипломатическим каналам. Сегодня можно с уверенностью утверждать, что тематика ДЕБ прочно заняла одно из приоритетных мест в евроатлантической повестке дня.
Приведу только несколько примеров: наше предложение вызвало заинтересованную реакцию и стало одним из главных предметов обсуждения на СМИД ОБСЕ в Хельсинки (декабрь 2008 г.), Мюнхенской конференции по безопасности (февраль 2009 г.), совместном заседании Форума по сотрудничеству в области безопасности и Постсовета ОБСЕ и на зимней сессии Парламентской ассамблеи ОБСЕ в Вене (февраль 2009 г.). Эта проблематика - постоянный элемент диалога в рамках Россия - Евросоюз. Возьмем и более экспертный уровень. В нашем департаменте практически ежедневно мы принимаем зарубежных коллег для консультаций по этой теме. Состоявшиеся дискуссии свидетельствуют, что большинство наших партнеров на евроатлантическом пространстве заинтересованы в использовании имеющегося сегодня "окна возможностей" для выхода на новое качество стратегического взаимодействия в "треугольнике" Россия - Европа - США, устранения накопившегося в Евро-Атлантике за последние годы отставания в сфере "жесткой безопасности". Налицо вызревающая готовность к совместной работе по поиску нового консенсуса по архитектуре европейской безопасности.
Разумеется, как и любая масштабная инициатива, продвижение идеи ДЕБ сопряжено с непростым процессом ее осмысления партнерами и даже скептицизмом со стороны некоторых из них.
Мы - реалисты. Существуют разные "школы мысли" и различная степень восприимчивости в том, что касается новых идей относительно панъевропейского ландшафта безопасности. Отсюда - понятная осторожность в реакции ряда государств.
В нашей идее договора нет ни двойного дна, ни скрытой повестки дня. Ее суть - желание договориться о понятных "правилах игры", шаг за шагом восстановить доверие, подрыв которого лежит в корне всех проблем. К осознанию необходимости перенастраивать или даже перестроить механизмы обеспечения евроатлантической безопасности подталкивает сама жизнь. В нашем регионе - именно там, где, казалось бы, действует наиболее плотная и всеобъемлющая сетка взаимных обязательств и межинституциональных связей, - объективная потребность в принципиально новых подходах к обеспечению безопасности не была в достаточной степени подкреплена реальными действиями по формированию подлинно коллективной системы безопасности. Такие структуры, как Евросоюз, НАТО, СНГ или ОДКБ, в силу их институциональной природы занимаются вопросами обеспечения по большей части автономно. Их повестки дня по-прежнему не скоординированы, они нередко взаимно накладываются. Возможности налаживания сотрудничества по конкретным аспектам безопасности зачастую не реализуются по идеологическим соображениям.
От наших западных партнеров мы нередко слышим, что главной опорой безопасности в регионе является НАТО. Несомненно, это важная международная организация. Однако события последних лет четко продемонстрировали, что возведенный в абсолют НАТО или любой другой "центризм", взращенный на почве так называемой региональной, исторической или цивилизационной "исключительности", не может стать и не будет "универсальным средством" укрепления евробезопасности. Напротив, он генерирует появление в Европе разделительных линий, усиливает напряженность, порождает разобщенность в отношениях и действиях членов евроатлантического сообщества. Более того, очевидно, что процесс расширения, по крайней мере в обозримом будущем, будет иметь свои пределы - значительное число стран нашего региона останется вне пространства НАТО. Кто-то, как и Россия, не имеет таких намерений, а кого-то НАТО просто не в состоянии поглотить, несмотря на их желание. Однако и те, и другие обладают правом на равную безопасность на основе согласованного на самом высоком межгосударственном уровне принципа неделимости евроатлантической безопасности, предусматривающего, что ни одна страна не должна укреплять свою безопасность за счет безопасности других.
Напомню, что эти нормы так называемого "мягкого" права вовсе не являются какой-то новацией, продвигаемой сегодня Россией, а закреплены в Парижской хартии для новой Европы (1990 г.), Хартии европейской безопасности (1999 г.), Римской декларации о создании Совета Россия - НАТО (2002 г.) и других международных документах. Однако эти обязательства, как и фундаментальные для евроатлантической безопасности ценности - следование нормам международного права, неприменение силы, уважение суверенитета, нерушимости границ и территориальной целостности, приверженность мирным средствам урегулирования конфликтов, контроль над вооружениями, - не только не получили своего законченного развития, но и в ряде случаев подверглись эрозии, ослабли в качестве реальных инструментов обеспечения безопасности.
Сошлюсь на один весьма симптоматичный эпизод: на проходившем в Бухаресте около года назад саммите Совета Россия - НАТО нам так и не удалось согласовать итоговую совместную декларацию из-за отказа некоторых партнеров включить в нее ссылку на закрепленный в основополагающих документах Совета Россия - НАТО принцип неделимости безопасности.
В сложившейся ситуации у нас возникает принципиальный и весьма тревожный вопрос: по-прежнему ли в евроатлантическом сообществе разделяют и поддерживают эти принципы? Если, как мы надеемся, разделяют и поддерживают, то что же мешает подтвердить в юридически обязывающей форме те политические обязательства, которые уже приняты, причем добровольно, без принуждения?
Инициатива Д.А.Медведева по ДЕБ нацелена и на устранение самой почвы для возникновения подобного рода озабоченностей, восполнение этого принципиального пробела: как на основе договоренностей всех 56 стран - участниц Евроатлантического региона обеспечить равную безопасность для всех стран - блоковых и неблоковых. Кстати, идея отнюдь не идеоматическая. Даже в условиях жесткого блокового противостояния холодной войны безопасность не входивших в них европейских государств (Австрии, Швейцарии, Финляндии, Швеции) была надежно, как показала история, обеспечена. Такую работу предстоит проделать и сейчас. При этом главное, наверное, зафиксировать как юридически обязывающий принцип неприменения силы в отношениях между государствами евроатлантического пространства. Причем закрепить таким образом, чтобы это служило примером и для других регионов планеты, не создавало впечатления, что в отношениях между собой силу применять не будем, а с другими можем.
Естественно, с учетом масштабности задачи согласования и подписания ДЕБ ее достижение - дело не завтрашнего дня, но она вполне осуществима. Если взять не менее сложную тему человеческого бытия - экономическую, то, как показывает нынешний глобальный финансово-экономический кризис, никто, даже самый радикальный, не предлагает решать его с помощью насилия, и тем более военного. Господствует философия - сообща, помогая друг другу, искать выход из нынешней тяжелой или даже крайне тяжелой ситуации. Такой выход должен быть найден и в выстраивании международных отношений в военно-политической сфере.
В нашем представлении процесс отнюдь не будет стремительным. Подключение к нему должно вызреть у государств евроатлантического пространства - только тогда удастся накопить необходимую для достижения искомого результата "критическую массу" политической воли.
Этот процесс должен быть инклюзивным, включать все международные факторы - как государства, так и международные организации и структуры, действующие в сфере "жесткой безопасности".
Предлагаем подтвердить в договоре согласованные ранее принципы межгосударственных отношений, разработать инструменты и механизмы обеспечения их универсального применения, согласовать единые критерии и механизмы предотвращения и мирного урегулирования конфликтов. В рамках этих усилий мы хотим также договориться о базовых "зонтичных" принципах контроля над вооружениями. Это не только не должно подменить усилий по возрождению режима ДОВСЕ, а, напротив, стимулировать оживление работы на данном направлении, содействовать ее выходу из узких рамок российско-американского диалога в более адекватный задаче контроля над вооружениями многосторонний формат с широким привлечением наших европейских партнеров. И, конечно, в ДЕБ могло бы также найти отражение новое качество сотрудничества в нераспространении оружия массового уничтожения, противодействии терроризму и другим угрозам и вызовам, с которыми все мы сталкиваемся в настоящее время.
В связи с ДЕБ нам нередко задают вопрос: почему нельзя добиться этого результата в рамках существующих структур?
Ответ очень прост. НАТО, ОДКБ, СНГ, Европейский союз с его европейской политикой безопасности и обороны - все эти структуры представляют собой клубы или организации для обеспечения безопасности исключительно своих членов.
Какая же площадка могла бы быть оптимальной для дискуссий и переговоров по ДЕБ? Формальный подход говорит в пользу ОБСЕ - она является хранительницей основных принципов и обязательств в области межгосударственных отношений на евроатлантическом пространстве, ее страновой состав покрывает весь регион. ОБСЕ является универсальной организацией, и никто не подвергает сомнению ее принципы. Однако в реальности в своем нынешнем состоянии ОБСЕ в одиночку вряд ли способна решить столь масштабную задачу. Причины очевидны, но о них почему-то не принято говорить. Главная из них - эгоизм отдельных стран или групп стран в отношении Организации, использование ее ресурса для решения исключительно национальных или блоковых задач.
Не секрет, что для США это дополнительные возможности приглядеть за постсоветским пространством, поприжать тех, кто своей политикой не устраивает Вашингтон. Брюссель использует ОБСЕ как своего рода предвступительный класс в контексте расширения Евросоюза: страны-кандидаты здесь дополнительно присягают на верность общееэсовским принципам, выполняют домашние задания, учатся работать в команде. Для части посткоммунистических стран ОБСЕ важна как международный механизм содействия разрешению локальных конфликтов, доставшихся в наследство от 90-х годов прошлого века (Косово, Нагорный Карабах, Приднестровье), в чем ОБСЕ отнюдь не преуспела. Ряд постсоветских стран пытается найти для себя пользу от Организации путем вовлечения ее в решение собственных социально-экономических и экологических проблем, хотя для этого она из-за отсутствия адекватного экспертного потенциала и достаточных финансовых ресурсов малоприспособлена.
Все эти реальные интересы сталкиваются друг с другом, политически перегревая Организацию. России, по большому счету, от такой разобщенной и импотентной ОБСЕ сегодня вообще вряд ли что-то нужно. Поэтому мы, платя за участие в ней, сейчас настойчиво ставим вопрос о реформе ОБСЕ - согласовании приемлемой для всех, адекватной сегодняшним вызовам повестке дня и фиксации общих правил игры.
Проблема также состоит в том, что ОБСЕ уже давно игнорирует вопросы "жесткой безопасности", хотя в рамках этой организации существуют Форум по сотрудничеству в области безопасности, Ежегодная конференция по обзору проблем в области безопасности в Европе, где эти вопросы должны обсуждаться.
Наконец, относительно юридических обязанностей и обязательств. ОБСЕ не является юридически обязывающей организацией и не обладает правоспособностью. В ней, как и в Совете Россия - НАТО, имеются только политические обязательства, но не юридические обязательства. Обязательства же в НАТО являются юридически обязывающими. Тем самым создаются различные уровни безопасности.
Отдавать целиком в таких условиях ДЕБ в ОБСЕ означает риск убить идею в самом зародыше. Впрочем, это не исключает задействование такого вполне адекватного на сегодняшний день инструмента ОБСЕ, как Форум по сотрудничеству в области безопасности, для дискуссий, скажем, по проблематике мер доверия. Да и организационно-интеллектуаьные возможности небольшого, но хорошо структурированного, консолидированного и энергичного секретариата ОБСЕ могли бы оказаться востребованы для технической организации переговорного процесса.
Полагали бы поэтому разумным подумать о том, чтобы разбить работу по обозначенным выше тематическим блокам эвентуального переговорного процесса по разным столицам под общим "зонтиком" ОБСЕ. Условно, с учетом истории, Хельсинки - принципы межгосударственных отношений, Женева - контроль за вооружениями, Белград - принципы урегулирования региональных конфликтов, Вена - механизмы мониторинга и меры доверия, Астана - новые вызовы и угрозы. Естественно, самим странам решать, как они могли бы способствовать реализации идеи укрепления безопасности на евроатлантическом пространстве. Поэтому предложение о разделе тематики носит абсолютно умозрительный характер.
Такая дисперсия могла бы дать и лучший кумулятивный результат через большее число заинтересованных в успехе стран.
Сегодня, конечно, еще рано предопределять конкретное содержание и характер будущего Договора о европейской безопасности. Сейчас необходимо перейти от этапа вопросов о форме к предметному проговору субстантивных проблем, накопившихся в евроатлантической "жесткой безопасности". Уже само начало такого крупномасштабного переговорного процесса по наиболее чувствительным вопросам евроатлантической безопасности с вовлечением экспертного сообщества, политического класса, руководства стран будет оздоровляющим в контексте восстановления доверия. Такой нацеленный на результат переговорный процесс, а его не было на евроатлантическом пространстве, пожалуй, с периода согласования адаптированного ДОВСЕ, то есть уже десять лет, заставит находить общий язык и договариваться по самым чувствительным проблемам. А именно это сегодня как раз и нужно.
Руководство по архитектуре безопасности детально определяет контрмеры против угроз, раскрытых при оценке рисков. Руководство описывает компоненты архитектуры безопасности сети, рекомендует конкретные продукты безопасности и дает инструкции, как их развернуть и управлять ими. В частности, это руководство может содержать рекомендации, где следует поставить межсетевые экраны, когда использовать шифрование, где разместить веб-серверы и как организовать управление коммуникациями с бизнес-партнерами и заказчиками. Руководство по архитектуре безопасности определяет также гарантии безопасности, аудит и средства контроля.
Физическая безопасность . Физическая защита ресурсов и активов организации достигается с помощью аппаратных средств и размещения соответствующих компьютерных и коммуникационных средств в физически защищенных помещениях или зонах.
Без обеспечения физической безопасности будут подвергаться серьезным угрозам такие важные аспекты информационной безопасности, как конфиденциальность, доступность и целостность информации. Реализация физической защиты заключается в определении тех компонентов компьютерной среды, которые должны быть физически защищены. К таким компонентам относятся:
¨ центральные процессоры и системные блоки;
¨ компоненты инфраструктуры локальной сети LAN (системы управления LAN, мосты, маршрутизаторы, коммутаторы, активные порты и др.);
¨ системы, связанные с LAN;
¨ медиа-память.
Затем устанавливают два или три типа областей с различными уровнями безопасности, такими как:
¨ открытые области – в них допускаться все сотрудники компьютерной среды;
¨ контролируемые области – они должны быть закрыты, когда находятся без присмотра;
¨ особо контролируемые области – области, куда ограничен доступ даже зарегистрированным авторизованным пользователям.
Логическая безопасность . Она характеризует уровень защиты ресурсов и активов в сети. Логическая безопасность включает средства безопасности, осуществляющие идентификацию и аутентификацию пользователей, управление доступом, межсетевое экранирование, аудит и мониторинг сети, управление удаленным доступом и т.д.
Защита ресурсов . Ресурсы (файлы, базы данных, программы, данные) делятся на две группы:
1. Ресурсы операционной системы – объекты данных, которые связаны с системными сервисами или функциями; они включают системные программы и файлы, подсистемы и программные продукты. Ресурсы операционной системы обычно находятся под управлением и ответственностью провайдера сервиса. Ресурсы операционной системы не всегда являются ограниченными для чтения, хотя список исключений должен быть установлен и соответственно защищен. Типичным примером такого исключения является база данных, в которой хранятся пароли и идентификаторы пользователей.
2. Ресурсы пользователей – объекты данных, которые связаны с отдельными пользователями или группами пользователей. Ресурсы пользователей должны быть защищены в соответствии с требованиями собственника данных.
Определение административных полномочий . Некоторые из пользователей, находящихся в сети, имеют особые полномочия. Такие полномочия нужны для управления компьютерными системами и безопасностью. Эти административные полномочия можно разделить на две категории:
¨ полномочия системного администратора;
¨ полномочия администратора безопасности.
Полномочия системного администратора позволяют администратору выполнить действия, необходимые для управления компьютерными системами. Эти полномочия могут дать возможность администратору обойти контроль безопасности, но это должно рассматриваться как злоупотребление полномочиями.
Полномочия администратора безопасности дают возможность администратору выполнять действия, необходимые для управления безопасностью. Эти полномочия позволяют администратору осуществлять изменение системных компонентов или считывать конфиденциальные данные. Однако, если считывание конфиденциальных данных выполнено администратором без соответствующей потребности бизнеса, это должно рассматриваться как злоупотребление своими полномочиями.
Полномочия системного администратора и администратора безопасности являются одинаково важными для безопасности. С учетом этого необходимо выполнить следующее:
¨ определить для каждой системной платформы или системы управления доступом те полномочия, которые могут быть признаны в указанных категориях;
¨ назначить полномочия администраторам в соответствии с индивидуальной ответственностью;
¨ периодически проверять назначение идентификаторов авторизованным пользователям.