Понятие "цод". Физическая защита ЦОДа — понятие комплексное

В. А. Конявский, д.т.н.

Д. В. Угаров

Специфика угроз информационной безопасности и защиты от них в ЦОД

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

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

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

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

Несколько ЦОДов иногда объединяются одним механизмом управления. Теперь ВМ могут размещаться не только на разных физических серверах, но и на разных ЦОДах. Но до сих пор пользователь при желании может точно установить, где находится его конкретная виртуальная машина.

Так может продолжаться до тех пор, пока ресурсов группы ЦОД хватает для размещения всех требуемых виртуальных машин. Рано или поздно все ресурсы ЦОД окажутся занятыми, и тогда придется «уплотняться».

Мало кто удержится от заказа ВМ «на вырост». Конечно, за заказанные ресурсы нужно платить, но не так уж и много, и, значит, лучше взять «про запас». В результате, хотя эффективность использования ресурсов в ЦОД намного выше, чем при использовании ПЭВМ, все-таки оптимальным такое использование не назовешь. Каждый взял себе по 20-30% запаса ресурсов, значит, свободные ресурсы есть, а использовать их нельзя. Неэкономно получается.

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

При работе «в облаке» ВМ может размещаться на любой памяти, исполняться на любом сервере любого ЦОД, входящего в состав облачной инфраструктуры. Говорят, что ВМ «мигрируют» между ЦОД. Решение о миграции ВМ принимает «планировщик», исходя из различных соображений, например, из логики равномерности загрузки ЦОД, цены ресурсов, просто наличия свободных ресурсов, и других.

То есть облачные технологии начинаются тогда, когда исчерпаны все ресурсы ЦОДов. Облачная инфраструктура — это взаимодействующие на основе специализированного «планировщика» ЦОДы, средства доступа и клиентские машины. Защищенная облачная инфраструктура — это защищенные серверы, защищенные ЦОД, защищенные ВМ, защищенный доступ (WEB и/или терминальный), и, наконец, защищенный планировщик, планирующий миграцию ВМ из соображений, в том числе, защищенности информационных ресурсов.

Защищенность ЦОДа, соответственно, обеспечивается «проще» на планировщик. Это важно, так как серьезных технологий защиты планировщика на рынке пока не представлено, они находятся в разработке.

Требования к защите понятны - если информационное взаимодействие связано с обработкой персональных данных и обработкой государственных информационных ресурсов, то меры по защите должны соответствовать требованиям приказов 17 и 21 ФСТЭК.

Перечислим возможные средства защиты:

1. Доверенная среда на компьютерах пользователей может создаваться применением СЗИ НСД (например, «Аккорд») или СОДС (например, «МАРШ!»);
2. Защищенный доступ пользователей к ВМ можно обеспечить применением VPN в доверенной среде для WEB-доступа, или системой доверенной терминальной загрузки (например, «Центр-Т»);
3. Контролируемый старт (доверенная загрузка) системы виртуализации и защита ВМ обеспечивается специализированными СЗИ для виртуальных инфраструктур (например, для VMware — «Аккорд-В.», для MS HV — «ГиперАккорд»);

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

В этом смысле необходимо учитывать два обстоятельства:

1. являются ли пользовательские рабочие места контролируемыми (это так, если ЦОД корпоративный и пользователи — сотрудники организации, но не так — если это ЦОД, предоставляющий облачные сервисы неограниченному кругу пользователей, использующих неограниченный круг компьютеров);
2. ПЭВМ или тонкие клиенты используются в качестве рабочих мест пользователей.

Легко заметить, что эти вопросы находятся в иерархической связи и дают следующие варианты систем:

1) Фиксированные рабочие места пользователей, контролируемые (управляемые) службой информационной безопасности (относится она к владельцу ЦОДа или нет — вопрос в данном случае второстепенный; достаточно знать, что какой-то службой информационной безопасности — контролируются).

• тонкие клиенты

2) неизвестный и неконтролируемый парк СВТ.

Неизвестный и неконтролируемый парк СВТ

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

При этом такой незащищенный клиент подвергает опасности не только себя (считая, что он защищен, раз облако — защищенное), но и сам ЦОД, создавая «дыру в заборе».

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

Принципиально важно, чтобы средство защиты ЦОДа могло контролировать, действительно ли клиент подключился из доверенной среды!

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

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

Фиксированные рабочие места, контролируемые службой информационной безопасности

Этот случай проще потому, что на состояние клиентских рабочих мест проще влиять: средства защиты, предписанные проектной документацией на систему, будут установлены на рабочие места пользователей.

Рабочие места в общем случае можно разделить на ПЭВМ и тонкие клиенты.

ПЭВМ почти наверняка используются не только для взаимодействия с ЦОДом, но и автономно. И значит, они должны быть защищены полноценным программно-аппаратным комплексом СЗИ НСД (например, «Аккорд-Win32» или «Аккорд-Win64). В зависимости от политики безопасности запуск ВМ может требовать от пользователя, например, предъявления другого идентификатора.

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

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

При этом с точки зрения действий пользователей система практически не будет отличаться, с одной стороны, от построенной на базе СОДС, а с другой — от «реальной» терминальной системы: пользователь будет подключать USB-устройство, вводить PIN-код и ожидать загрузки терминала и старта сессии с терминальным сервером. Что он виртуальный — пользователь может и вовсе не знать. В рамках сессии то же USB-устройство выполняет функцию идентификатора пользователя в ПАК СЗИ НСД на серверной части системы.

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

Все системы ЦОД состоят из собственно ИТ- инфраструктуры и инженерной инфраструктуры, которая отвечает за поддержание оптимальных условий для функционирования системы.

ИТ-инфраструктура

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

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

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

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

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

Адаптивная инженерная инфраструктура ЦОД

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

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

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

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

Архитектура ЦОД

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

• · top-of-raсk - это модель коммутации, когда в каждой стойке стоит коммутатор, который обрабатывает трафик с серверов в этой стойке, и соединен с агрегирующим слоем (в стандартной трехзвенной модели)
• o Преимущества топологии top-of-rack:
  • § большинство коммутаций внутри шкафа;
  • § более простая в обслуживании и дешевая кабельная система;
  • § модульная архитектура «per rack» (каждый шкаф как отдельный независимый блок);
  • § подключение серверов с использованием дешевых SFP+ модулей 10GE (40 GE) для коротких расстояний.
• o Недостатки топологии top-of-rack:
• § много коммутаторов для управления, много портов на уровне агрегации;
• § ограничения масштабируемости (STP logical ports и емкость портов коммутатора агрегации);
• § много L2 трафика на уровне агрегации
• · end-of-row модель предполагает расположение коммутатора, условно, «в конце ряда стоек» и обслуживание им трафика с со всех серверов из нескольких стоек, расположенных в ряд
• o Преимущества топологи end/middle-of-row:
  • § меньше коммутаторов;
  • § меньше портов на уровне агрегации.
  • § надежные, зарезервированные и как правило модульные коммутаторы доступа;
  • § единая точка управления для сотен портов.
• o Недостатки топологи end/middle-of-row:
• § более дорогостоящая кабельная инфраструктура;
• § много кабелей - препятствие для охлаждения;
• § длинные кабели - ограничение на использованием дешевых подключений на 10/40 GE - «Per row» архитектура (каждый ряд как отдельный независимы блок).

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

• · фиксированные (после развертывания сети в архитектуре невозможны изменения)
• o древовидные - стандартное широко используемое решение для ЦОД, когда каждый сервер подключен к одному коммутатору, находящемуся на низшем уровне топологии:
  • § Basiс tree
  • § Fat tree
  • · Al-Fares et al
  • · Portland
  • · Hedera
  • § Сlos network
  • · VL2
• o Рекурсивные - топологии, при которых сервера могут быть подключены к разноуровневым коммутаторам или к другим серверам:
• § DСell
• § BСube
• § MDСube
• § FiСonn
• · Гибкие (возможны изменения в топологии уже после развертывания сети) - принципиальное отличие состоит в том, чтобы использовать коммутаторы с оптическими портами. Помимо увеличения пропускной способности (до Тб/сек с использованием технологий спектрального уплотнения каналов - WDM), данное решение обладает высокой гибкостью при переконфигурации топологии сети.
• o Полностью оптические
• § OSA
• o Гибридные
• § С-Through
• § Helios

Сетевая инфраструктура ЦОДа

Подход к построению сетевой инфраструктуры должен обеспечивать должный уровень таких качественных параметров как:

• · надежность,
• · безопасность,
• · производительность,
• · управляемость,
• · масштабируемость.

В целях организации сетевой инфраструктуры ЦОД применяются такие классы оборудования, как:

• · Канальное оборудование, в число которых входят мультиплексоры CWDM и DWDM, транспондеры, конверторы и т.д.
• · Оборудование коммутации Ethernet, отличающееся высокой производительностью и высокой надёжностью, с функционалом маршрутизации и распределения нагрузки. В связи с тем, что в центрах обработки данных для бизнеса используется большой объем передаваемых данных, то предъявляются жесткие требования к оборудованию в плане производительности, функциональности и надежности.
• · Коммутационное оборудование стандарта FibreChannel. При этом могут быть использовано оборудования различных классов. Это зависит от выбранной архитектуры сетевой инфраструктуры ЦОД. Могут быть использованы как простейшие коммутаторы уровня рабочей группы или же оборудование уровня предприятия.
• · Программные комплексы, осуществляющие централизованный мониторинг и управление сетью, которые предоставляют единую точку управления всей сетевой инфраструктурой ЦОД за счёт графического интерфейса, а также расширенных средств визуализации наблюдаемых параметров, таких как состояние функциональных компонентов, загруженность ресурсов коммутаторов и даже некоторые параметры подключенных устройств, включая версию микропрограммного обеспечения интерфейсных карт FibreChannel в серверах.

Сеть современного ЦОД можно строить в один, два и три уровня, . У каждого варианта есть свои предназначения. Рассмотрим далее вкратце упомянутые выше варианты:

• · Одноуровневая архитектура подразумевает непосредственную связь между оборудованием ядра/агрегации и серверами
• · Двухуровневая архитектура (L1) подразумевает наличие между ядром/агрегацией ЦОД дополнительного уровня коммутаторов по схеме ToR (Top-of-Raсk).
• · Трехуровневый вариант архитектуры (L3), иногда его еще называют EoR (End-of-Row). В 3-уровневой архитектуре ЦОД дополнительный уровень коммутаторов агрегации добавляет гибкость в построении сетевых топологий и увеличивает потенциальную емкость решения по портам.

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

Сейчас набирают популярность такие варианты подключения, как оптоволоконный Ethernet (FCoE - Fibre Сhannel over Ethernet) и новые разработки высокоскоростного Ethernet (1 Гбит/с и 10Гбит/с). Традиционное решение в ЦОД предполагает создание двух сетей - сеть передачи данных на базе протокола Ethernet и сеть хранения данных на базе протокола Fiber Channel (FC).

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

В основе решения лежит протокол Fiber Channel over Ethernet (FCoE), обеспечивающий передачу FC-трафика через Ethernet-транспорт. При помощи DataCenterBridging (DCB), Ethernet превращается в протокол без потерь, который подходит для трафика FCoE, обеспечивающего традиционную в SAN-сетях изоляцию фабрик (Fabric A и Fabric B). Помимо этого унифицированная коммутация позволяет упростить управление и сэкономить на оборудовании, электропитании, а так же на кабельной инфраструктуре.

Развертывание среды виртуализации в ЦОД

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

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

Виртуализация сетевой инфраструктуры ЦОД включает в себя:

• · Виртуализацию физической сети;
• · Построение виртуальной сети внутри виртуальной серверной среды.
• · Виртуализация физической сети.

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

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

Примерами зон безопасности могут быть:

• · корпоративный сегмент;
• · защищенный сегмент PCI DSS;
• · тестовый сегмент сети;
• · демилитаризованная зона.

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

• · виртуализация устройства (VDC для Nexus 7000, виртуальные контексты межсетевых экранов, IPS, traffic domain для балансировщика Citrix);
• · виртуализация таблицы маршрутизации (VRF), или виртуализация маршрутизатора;
• · VLAN для L2 сегментации.

Информационная безопасность ЦОДа

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

Основные этапы обеспечения безопасности ЦОД:

• · Определение объектов защиты, типичный список которых включает в себя:
  • o Информация, хранимая (обрабатываемая) в системе;
  • o Оборудование;
  • o Программное обеспечение.
• · Построение модели угроз и модели действий нарушителя;
• · Оценка и анализ рисков (возможные риски приведены ниже):
  • o Сбои и отказы программно-аппаратных средств;
  • o Угрозы со стороны обслуживающего персонала;
  • o Ошибка руководства организации в связи с недостаточным уровнем осознания ИБ;
  • o Утечка информации;
  • o Нарушение функциональности и доступности персонала;
• · Разработка и внедрение в системы ЦОД методов и средств защиты.

В отношении территориально разнесенных дата-центров необходимо сформулировать дополнительные требования к системам защиты информации:

• · Обеспечение конфиденциальности и целостности данных передаваемых по каналам связи;
• · Поддержка единого адресного пространства для защищаемой LAN ЦОД;
• · Быстродействие и производительность;
• · Масштабируемость;
• · Отказоустойчивость;
• · Соответствие требованиям регулятора.

Катастрофоустойчивость ЦОДа

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

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

Распределение ЦОД по нескольким площадкам требует организации следующих компонентов:

• · Резервируемые каналы связи
• · Репликация данных файловых хранилищ;
• · Разработка плана действий резервного копирования и восстановления систем;

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

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

Возможны две основные стратегии использования распределенных ЦОД:

• · «активный/активный» - инфраструктурные приложения и сервисы распределены между площадками, и пользователи работают с ближайшим ЦОД;
• · «активный/пассивный» - при которой приложения централизованы, и пользователи работают с основным узлом. В случае отказа системы, нагрузка автоматически переключается на резервный ЦОД.

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

Крупные банки и другие коммерческие организации в силу особенностей своих отраслей прорабатывают стратегию защиты в масштабах страны. Лучшие практики описываются формулой 2СЗС: 2 сities, 3 сenters. Это означает, что в городе основного базирования находятся два ЦОД в метро-радиусе (т. е. нескольких десятков километров), дублирующих друг друга в синхронном режим, а в другом городе, на расстоянии не менее нескольких сотен километров, располагается третий ЦОД на случай региональной катастрофы в городе основного базирования.

Переключение между двумя основными площадками может быть быстрым и автоматическим, а переключение на удаленную площадку - медленным и ручным. Это связано с тем, что соединения между площадками должны иметь очень низкие показатели задержек (Latency), так как большие задержки отрицательно сказываются на производительности всей системы. А поскольку с увеличением расстояния задержки увеличиваются, расстояние между ЦОД не должно превышать 100 км. Иначе уже не возможно использовать технологию синхронной репликации. Ключевые транзакционные данные на основных площадках поддерживаются в синхронном состоянии, а на удаленной площадке, скорее всего, будет некоторое отставание. (см. подробнее раздел «Синхронизация данных в комплексе ЦОДов»).

Механизмы обеспечения надежности и защищенности сфере катастрофоустойчивости

Решения данной задачи могут быть реализовано как аппаратно, так и программно:

• · На рынке представлены высокодоступные аппаратные платформы, в которых функции избыточности и восстановления при сбоях реализованы на системном уровне. Исторически в данном сегменте сильны позиции мэйнфреймов. Это актуально прежде всего для тех предприятий, которые применяют подобные платформы много лет.
• · Наиболее предпочтительны решения, реализующие функции отказо- и катастрофоустойчивости непосредственно на прикладном уровне либо на уровне программной платформы (ПО промежуточного уровня). Такая реализация позволяет отрабатывать сбои с минимальными потерями, задержками и накладными расходами. Общее правило: чем выше уровень, на котором реализуются функции высокой доступности, тем лучше. Уровень платформы - наиболее подходящий, поскольку в данном случае разработчики прикладной функциональности изолированы от непрофильных для них низкоуровневых системных вопросов.

Наибольшее влияние на механизмы обеспечения надежности и защищенности оказали следующие технологии:

• · серверная виртуализация, позволяющая свести восстановление "упавшего" сервера к копированию файла с его образом из одного места в другое вместо восстановления физического сервера путем замены его сбойных компонентов или полной замены. Это уменьшает время восстановления в разы, а в случае плановых манипуляций с сервером - до нуля за счет Live Migration, позволяющей переносить продуктивную нагрузку с одного виртуального сервера на другой вообще без прерывания сервиса;
• · виртуализация систем хранения данных - обеспечение с помощью аппаратных или программных виртуализаторов СХД одинаковой (параллельной) видимости дисковых ресурсов и файлов для серверов, расположенных как в главном, так и в резервном вычислительных центрах. С учетом того, что виртуальный продуктивный сервер обычно представляет собой файл, применение виртуализатора позволяет существенно упростить общую конструкцию системы, повышает надежность и упрощает взаимодействие продуктивной и резервной систем;
• · дедупликация - значительное уменьшение объема трафика при передаче данных между главным и резервным центрами, что повышает надежность и снижает требования к каналам связи.

Важная оставляющая обеспечения защищенности - планы аварийного восстановления как со стороны ИТ (Disaster Reсovery Plan,) так и со стороны бизнеса (Business Сontinuity Plan). Последний предполагает наличие плана действий в случае утраты бизнесом основного инструмента. Оба плана должны периодически тестироваться согласно разработанному в организации регламенту.

Специфика территориально разнесенных ЦОДов

Основные отличия катастрофоустойчивого ЦОД от традиционного заключаются в том, что:

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

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

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

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

Уязвимость территориально распределенных ЦОДов

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

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

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

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

Синхронизация данных в комплексе ЦОДов

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

• · RPO (Reсovery point objeсtive) - допустимая точка восстановления
• · Допустимое расстояние для работы технологии
• · Уровень защиты информации
• · Зависимость производительности решения от расстояния/объема данных
• · Необходимый уровень пропускной способности коммуникационных каналов

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

Стремление повысить эффективность использования ИТ-ресурсов на фоне их усложнения ведет к их централизации и переходу к сервисной модели предоставления доступа к ИТ. Учесть эти стратегические изменения в области ИТ и адекватно удовлетворить новые требования к ним позволяют такие технологические объекты, как ЦОДы, строительство которых стало сегодня выгодным направлением для инвестирования. Так, по прогнозам аналитиков, в этом году в России объем рынка ЦОДов вырастет примерно на 25%.

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

Технологические особенности ЦОДов и ИБ

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

Предметом атаки в виртуальной среде становится гипервизор. По выражению специалиста департамента маркетинга компании “Информзащита” Олега Глебова, гипервизор представляет собой единую точку отказа в виртуальной инфраструктуре и открывает новое направление в ИБ. И хотя, как отмечает технический консультант "Trend Micro Россия и СНГ" Николай Романов, его изолированность от внешней по отношению к нему среды обеспечивает изначально высокую защищенность и успешных атак на гипервизоры на сегодня, к счастью, очень мало, чтобы говорить о серьезности связанных с этим рисков, тем не менее в системы ИБ виртуальных сред уже стали вводить средства контроля целостности гипервизора. “Если он оказывается захваченным злоумышленниками, то установленные внутри виртуальных машин (ВМ) ИБ-средства, такие как антивирусы, межсетевые экраны, системы IDS/IPS и т. п. будут уже неспособны защитить данные виртуальной среды”, — считает г-н Романов.

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

Специфические ИБ-угрозы ЦОДа связаны также с появлением новой ИТ-роли - администратор виртуальной инфраструктуры. Эксперты отмечают, что его действия трудно контролировать на уровне операционной среды ВМ без дополнительных наложенных средств и это делает его выгодным объектом для атак злоумышленников. Менеджер по развитию направления компании “Код Безопасности” Юлия Смирнова вообще полагает, что администраторы, имеющие в силу своих должностных обязанностей непосредственный доступ к информационным системам клиентов ЦОДа, представляют самую серьезную угрозу ИБ. При этом ИБ-риски связаны как с их преднамеренными действиями, преследующими злой умысел, так и с их ошибками.

В современных ЦОДах, по мнению руководителя отдела стратегического ИТ-консалтинга "ИНЛАЙН ГРУП" Алексея Баданова, повышаются риски нарушения конфиденциальности, целостности и подлинности информации, связанные с тем, что при удаленном доступе к размещенным в ЦОДе информационным системам каналы передачи данных, как правило, неподконтрольны компании-пользователю, и безопасность данных в значительной степени зависит от ответственности и добросовестности провайдера. Особенно остро эта проблема обозначается в публичных облаках. Поэтому при использовании облаков следует особенно тщательно выбирать облачного провайдера. Злонамеренный инсайд на его стороне, взлом интерфейсов управления или недостаточный контроль за деятельностью пользователей облачных сервисов, DDoS-атаки на ЦОД провайдера могут привести к краже, подделке или уничтожению информации, к прекращению доступа к сервисам, остановке бизнес-процессов.

В связи с этим, считает г-н Баданов, провайдерам приходится кардинально менять свое отношение к качеству предоставляемых услуг и управлению ими: “Должны произойти конструктивные изменения во взглядах на качество, безопасность и управляемость потребления и предоставления ИТ-услуг обеими сторонами, что должно выразиться в самом серьезном отношении к заключению соглашений об уровне услуг и управлению уровнем услуг как наиболее действенным инструментам выстраивания взаимовыгодных отношений между провайдером и клиентом ИТ-услуг. От «делаю, что могу» провайдеры должны переходить к предоставлению услуг по принципу «делаю, как требуют»”.

Ведущий консультант "McAfee в России и СНГ" Михаил Чернышев обращает внимание на высокие требования к производительности средств защиты при высокой концентрации ИТ-ресусов в условиях ЦОДа (в первую очередь, речь идет о сетевой пропускной способности ИБ-средств), а также на необходимость экономного расходования вычислительных ресурсов виртуальной среды, для чего целесообразно нагрузку, связанную с обеспечением безопасности, переносить на выделенные серверы. По его мнению, серьезную угрозу представляют зараженные выключенные ВМ. При очередном включении они могут скомпрометировать безопасность всего ЦОДа. На этот счет он рекомендует проводить детектирование и устранение заражений в офлайновом режиме.

Обеспечение ИБ критически важных объектов ЦОДа, не охваченных виртуализацией (в числе наследуемых такие не редкость), по мнению г-на Чернышева, можно возложить на решения по контролю приложений и изменений, фиксирующие состояние виртуальной или обычной ОС и на низком уровне блокирующие попытки внесения изменений и запусков неавторизованного исполняемого кода. “Это может показаться не подходящим для ЦОДов, но именно такие решения работают в медицинских системах, системах промышленной автоматики, банкоматах. А они по уровню требований к защищенности соответствует ЦОДам”, - подчеркнул он.

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

Специфика ИБ-угроз и защита от них в ЦОДах

По наблюдениям руководителя департамента маркетинга и развития компании DEAC, европейского оператора ЦОД-услуг, Олега Наскидаева, типовые модели угроз и нарушителей ИБ для российских ЦОДов схожи с европейскими. К тому же и там, и здесь нарушителей следует разделять на внутренних, имеющих права доступа различной категории на территорию контролируемой зоны ЦОДов и к его ресурсам, и внешних, не имеющих таких прав.

Типичной угрозой для ЦОДов, считает г-н Чернышева, сегодня являются целевые атаки, в которых эффективно используется инсайд.

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

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

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

Угрозу для ЦОДов, по мнению г-на Наскидаева, представляет также использование открытого ПО, которое требует особенно внимательного отношения к разработке алгоритмов системного и прикладного ПО для ЦОДов, а также к своевременной установке обновлений.

Специалист по продажам решений по безопасности "IBM в России и СНГ" Кирилл Керценбаум напоминает, что современный ЦОД - это, как правило, физически изолированная от пользователя инфраструктура, что повышает значимость шифрования информации, резервирования каналов связи и защищенности от DDoS-атак. По его мнению, защита облачных технологий наиболее эффективна на уровне гипервизора. Среди других ИБ-технологий он выделяет контроль трафика, межсетевое экранирование, защиту от проникновений за счет уязвимостей с помощью средств IPS и IDS.

Сервисный инженер APC by Schneider Electric Дмитрий Тогушев напоминает, что обеспечение ИБ ЦОДа невозможно без надлежащей организации физического доступа к ресурсам ЦОДов, что тесно сопряжено с ИБ. Одним из эффективных вариантов поддержки ИБ-политики клиентов ЦОДа, по его мнению, может служить реализация концепции виртуальных комнат, позволяющая администраторам таких комнат самостоятельно настраивать правила физического доступа к оборудованию и реагирования на инциденты. Каждая такая комната в данной концепции представляется отдельным ЦОДом со всей инфраструктурой.

Константин Кузовкин отметил, что применение только традиционных средств защиты неэффективно в условиях архитектуры современных ЦОДов. Более того, такой подход сам становится источником ИБ-угроз. Против специфических атак на виртуальные среды традиционные средства защиты неэффективны. “Если, например, идет атака с зараженной виртуальной машины на другие, то трафик с данными оказывается зацикленным внутри сети хоста и традиционные межсетевые экраны не могут его перехватить”, - подчерккнул г-н Баданов.

Архитектор инфраструктуры информационной безопасности компании “Инфосистемы Джет” Алексей Воронцов тоже считает, что традиционные средства защиты неприменимы в виртуальных средах и даже могут быть опасны для них: “Например, одновременная антивирусная проверка жестких дисков нескольких ВМ может создать значительную нагрузку на всю платформу виртуализации. Сетевой трафик между ВМ не покидает физического сервера, и, следовательно, традиционные сетевые средства защиты его даже не видят”.

ИБ технологических процессов в ЦОДе

После успешной атаки Stuxnet на АСУ ТП Бушерской АЭС в Иране трудно оставить без внимания вопросы уязвимости технологических процессов ЦОДов.

Характеризуя подобные атаки, г-н Керценбаум обращает внимание на их узкую направленность, трудоемкость организации, высокую стоимость, нацеленность не только на ПО, но и на аппаратное обеспечение. Как модель защиты он предлагает рассматривать прежде всего физическую изоляцию сегментов АСУ ТП: “После защиты внешнего периметра следует объединить системы, которые входят в АСУ ТП, в единую технологическую сеть и изолировать ее от Интернета. Нужно организовать контроль этой технологической сети средствами IPS/IDS и наладить мониторинг разных типов трафика. На рабочих местах операторов АСУ ТП важно использовать тонкие клиенты, исключающие подключение съемных устройств”.

Имея в виду атаки, аналогичные Stuxnet, г-н Чернышев советует обратить внимание на проактивную защиту, т. е. защиту от тех видов угроз, которые еще не были обнаружены. “Есть несколько подходов к ее реализации. Компании, специализирующиеся на ИБ, предлагают облачные сервисы, предоставляющие доступ к своим аккумулированным знаниям и экспертным системам, помогающим отслеживать аномалии в мировом информационном пространстве и проактивно реагировать на них. Можно использовать концепцию “фиксирования” рабочего состояния объекта, исключающего возможность вносить в него какие бы то ни было изменения без соответствующего разрешения”, - советует он.

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

“К сожалению, традиционные хостовые средства защиты для серверных сегментов, работающих в режиме реального времени, малоприменимы, - заметил г-н Воронцов. - Поэтому возможен только комплексный подход, при котором создается несколько периметров защиты. И прежде всего необходимо обеспечить защиту рабочих станций диспетчеров АСУ ТП (именно оттуда, как мы помним, проходило заражение Stuxnet). Затем следует создать шлюзовые системы для доступа к серверным сегментам с рабочих станций, обеспечить контроль несанкционированной сетевой активности и обеспечить другие основные меры защиты”.

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

ИБ ЦОДов и человеческий фактор

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

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

Противодействие инсайду, напомнил г-н Романов, следует начинать с правильного разграничения доступа к ресурсам: “Нужно исключать единоличный доступ специалистов к критически важным системам. Этому должна препятствовать жесткая ИБ-политика, обязывающая привлекать к контролю использования таких систем двух - четырех сотрудников с различным уровнем прав, а также тщательный контроль исполнения самих этих политик”.

Г-жа Смирнова обращает внимание на то, что разделение ролей и сфер ответственности между разными специалистами позволяет решить проблему “суперпользователя”. По ее мнению, за назначение прав доступа к защищаемым ресурсам клиентов ЦОДа должен отвечать администратор безопасности, который, в свою очередь, не получает прав доступа к самим ресурсам.

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

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

Существенную роль здесь играет, считает г-н Чернышев, управление ИБ-рисками: “Следует систематически производить оценку состояния ЦОДа и усиливать безопасность именно в тех местах, где это действительно необходимо. Оценка рисков с учетом приоритетов защищаемых активов с периодическим сканированием на уязвимости, проверками соответствия регулятивным нормам в сочетании с централизованным управлением, позволяющим посмотреть на ИБ-проблемы сверху, по моему глубокому убеждению, дает желаемый результат”.

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

Поясняя конкретную ситуацию с нынешним состоянием управления виртуальными средами на примере продукции лидера направления, компании VMware, г-н Романов заметил, что в платформе vSphere есть система централизованного управления средой, которая, однако, не имеет встроенных средств контроля доступа к инфраструктуре, и если кто-то завладел доступом с правами суперпользователя, оправдаются опасения клиентов ЦОДа за сохранность своих данных. Вместе с тем он отметил, что существуют решения, позволяющие снизить эти риски.

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

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

ИБ ЦОДов и ИБ-регулирование

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

Отсутствие нормативной базы, регулирующей соответствие ЦОДа требованиям к размещению и обработке информации разной категории, по мнению г-на Смирнова, создает проблемы потребителям услуг ЦОДов и провайдерам облачных услуг, которым необходимы закрепленные договором обязательства по соблюдению в отношении размещаемой клиентами информации требований федеральных законов, в том числе и закона “О персональных данных”. “К сожалению, типовой договор провайдеров предполагает предоставление услуг “как есть”, что переносит все ИБ-риски на потребителей услуг. Именно это обстоятельство сдерживает развитие рынка услуг облачных вычислений и ЦОДов, так как неопределенность в части обеспечения ИБ останавливает до 80% потенциальных потребителей. Это подрывает экономическую модель этого направления, несмотря на то что за счет унификации и стандартизации сценариев использования ИТ-ресурсов оно дает большой экономический эффект”, - считает он.

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

Тем не менее, отметил г-н Кузовкин, есть прецеденты выполнения в виртуализованной многопользовательской ИТ-среде регулятивных требований, действующих и в России. К таковым он относит стандарт PCI DSS. Появившиеся на российском рынке средства защиты для виртуальных инфраструктур, сертифицированные на отсутствие недекларированных возможностей (по четвертому уровню контроля), а также для использования в автоматизированных системах класса защищенности до 1Г включительно и для защиты информации в информационных системах персональных данных до первого класса включительно, по его оценкам, позволяют привести виртуальную инфраструктуру в соответствие с требованиями руководящих документов ФСТЭК по защите персональных данных, а также стандарта PCI DSS.

Г-н Наскидаев сообщил, что после консультаций с юристами и ИТ-экспертами было сделано заключение о том, что использование услуг компании DEAC не упрощает и не усложняет российским компаниям процесс аттестации в качестве оператора персональных данных и позволяет российскому бизнесу рассматривать варианты использования ее ЦОДов. Более того, услуги DEAC, как утверждает г-н Наскидаев, в ряде случаев упрощают и удешевляют процесс аттестации на соответствие закону “О персональных данных”.

ИБ в ЦОДе и фактор доверия

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

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

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

Как считает г-н Романов, тут все зависит от того, насколько тщательно поставщик услуг предусмотрел различные аспекты обеспечения ИБ и заложил их в свою систему: “Если у тех из провайдеров, кто связан с рынком ИБ, эти аспекты предусмотрены и проработаны, пусть даже и не всесторонне, то у большинства из них, даже таких крупных, как Amazon, эти вопросы решаются только на базовом уровне. Трудности с обеспечением ИБ провайдеры стараются переадресовывать самим клиентам, если предоставляемые им ресурсы допускают доработку провайдерских систем под их требования. В основном это может быть реализовано только на уровне самой площадки ЦОДа, а не готового сервиса. Поэтому мои общие рекомендации потребителям услуг ЦОДов таковы: максимально внимательно оценивайте поставщика услуг и договор с ним”.

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

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

Оптимистично оценивает ситуацию с облачными сервисами и г-н Чернышев, заявляя, что мы уже вплотную подошли к концепции облаков и сегодня важными стали такие их аспекты, как сам сервис, модель его предоставления, возможность его тарификации и биллинга. При этом он отмечает, что даже наиболее продвинутую модель SaaS не следует рассматривать как верх эволюции облачных сервисов: “Уже сегодня есть системы, которые в состоянии контролировать фактическое время использования услуги, выставлять счет в соответствии с этим и отслеживать корректность транзакций, выполняемых при этом”.

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

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

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

Кстати, объектом для DDoS-атак дата-центры стали совсем недавно, но сегодня это уже значительный процент работы службы безопасности. Об этом ваш покорный слуга писал в материале «Что нам стоит ЦОД заDDоSить».

И если с угрозами все ясно, то с чего начинается, собственно, обеспечение безопасности? Как правило с оценки рисков. За первой оценкой обычно следует более глубокий анализ и подбор соответствующих решений. Если мы говорим о защите периметра ЦОДа, то современные методы предполагают ярусный подход. Поэтому проект по безопасности дата-центра обычно включает в себя системы контроля доступа, видеонаблюдение, системы противопожарной защиты, охранную сигнализацию и систему контроля безопасности жизнедеятельности. В последнее время интеграторы все чаще задумываются об экологической безопасности, включая соответствующие системы в проект защиты ЦОДа. Остается надеяться, что со временем у нас, как и в Европе, за экологичность будут премировать налоговыми вычетами. Также немаловажной составляющей оценки рисков становится персонал – насколько доверенные сотрудники у вас работают, стоит ли их проверять на полиграфе?

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

«В области системы информационной безопасности можно выделить несколько ключевых элементов.
1) Защита сетевого периметра ЦОДа, включая межсетевое экранирование; обнаружение и предотвращение вторжений (IDS/IPS-система); защита от DDoS-атак; поточный антивирус; защита от утечек данных (DLP, опционально); фильтрация web-трафика и защита web-приложений.

2) Защита каналов передачи данных, включая технологию SSL VPN для защиты мобильного доступа; «site-to-site» VPN для защиты данных между офисами и ЦОДами.

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

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

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

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

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

Что касается реализации проектов по защите ЦОДа, то тут можно выделить несколько ключевых этапов.

На первом этапе осуществляется обследование существующего ЦОДа или анализ документации на создание ЦОДа (если он еще не построен). На этом этапе необходимо понять «что защищать». Это главный вопрос, без ответа на который невозможно строить систему защиты.

На втором этапе осуществляется разработка модели угроз и модели нарушителя. Здесь особенно принципиально сформулировать перечень угроз и проанализировать их актуальность. По результатам этой работы формируется типовой «портрет» злоумышленника.

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

Как уже говорилось выше, дата-центр – отличный объект для реализации ярусного подхода к защите. То есть, формирование защитных мер обычно начинается от границ объекта и заканчивается в самом центре инфраструктуры. Таким образом, уровни доступа разделяются по ярусам и добавление очередного уровня на практике означает внедрение еще одного фактора авторизации. Например, доступ по специальным карточкам – это уже неплохая мера защиты. Но карту можно передать постороннему человеку, поэтому желательно ввести еще и пин-код. Впрочем, и это не является мерой абсолютной защиты. А вот добавив к этому биометрическую авторизацию, вы практически лишаете злоумышленников способов проникнуть. Единственный минус таких систем – их довольно высокая цена. Поэтому для большинства внешних уровней (ворота парковки, вход в здание) достаточно карточки и пин-кода, а на входе в серверную можно использовать видео-фиксацию и голосовую связь с пультом охраны. Решений и их комбинаций – масса, однако грамотная оценка рисков подскажет вам целесообразно ли внедрять ту или иную систему. Причем, руководствоваться необходимо не только предположениями, основанными на прецедентах, но и на фактической цене ошибки. Сколько потеряете вы или ваши клиенты, если информация будет похищена или ЦОД будет поврежден? Кажется ли теперь биометрическое решение таким дорогим? В любом случае, лучше следовать негласному правилу – прежде, чем добраться до ядра инфраструктуры, сотрудник должен пройти авторизацию не менее семи раз. В этом случае, система может считаться относительно безопасной.

Но как быть, если не только вашим сотрудникам, но и клиентам нужен доступ к серверам? Например, если ваш клиент серверная компания? Руководитель отдела информационной безопасности IBS Platformix, Джабраил Матиев, считает, что, организация удаленного доступа к серверам сегодня обычная практика. Как правило, у клиента всегда имеется удаленный доступ к серверам, который защищается усиленными средствами аутентификации (2-3-х факторной аутентификацией) и надежной защитой канала передачи данных. Если говорить о физическом доступе, то достаточно сложно представить для чего может потребоваться клиенту физический доступ к серверам, поскольку любые действия по обслуживанию физических серверов совершаются вручную персоналом интегратора. Тем не менее, существуют меры защиты и в этом случае. Условно их можно разделить на две части: организационные и технические.

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

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

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

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

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

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

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

Функциональные возможности комплексной системы безопасности:

• Фиксация и оповещение службы безопасности о возникновении задымления или пожара на территории предприятия с указанием адреса тревожного помещения.
• Автоматическое включение системы пожаротушения в местах возникновения пожара.
• Управление входными дверьми.
• Отключение системы вентиляции при поступлении сигнала тревоги с пожарных извещателей.
• Звуковое оповещение персонала ЦОД о пожаре и указание безопасных путей их эвакуации.
• Круглосуточное видеонаблюдение за охраняемой территорией с записью видеоинформации на цифровые устройства комплексной системы безопасности.
• Архивирование видеозаписей по помещениям ЦОД с возможностью по кадрового воспроизведения записей тревог, в том числе по дате, времени суток, по камере и т.п.
• Управление системой контроля и управления доступом для регулирования санкционированного входа/выхода сотрудников ЦОД и учета рабочего времени каждого сотрудника.