Контакты
Подписка
МЕНЮ
Контакты
Подписка

Жизнеобеспечение ЦОД: защита и риски

Жизнеобеспечение ЦОД: защита и риски

В рубрику "Центры обработки данных (ЦОД)" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Жизнеобеспечение ЦОД: защита и риски

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

  1. В чем заключается специфика обеспечения ИБ в ЦОД?
  2. Кто несет ответственность за информацию в ЦОД?
  3. Каковы основные виды рисков при использовании внешнего дата-центра и пути их минимизации?
  4. На что нужно обращать внимание при выборе надежного ЦОД?
Алексей
Грачёв

Руководитель направления консалтинга компании ЕМС в России и СНГ

1. Обеспечение информационной безопасности в ЦОД – это сложная и комплексная задача, решение которой напрямую зависит от типа ЦОД.

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

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

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

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


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

4. Прежде всего, следует помнить, что проект SLA в виде формального договора – это только основа для выбора поставщика таких "чувствительных" услуг. Самое главное – иметь возможность независимого контроля уровней предоставляемого сервиса.

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

Евгений
Дружинин

Ведущий эксперт по информационной безопасности компании КРОК

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

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

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


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

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

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

4. Нужно обращать внимание на наличие сертификата о надежности и отказоустойчивости ЦОД. Например, дата центр "Компрессор" сертифицирован Uptime Institute. Также важны четко налаженный процесс регламентирования по эксплуатации дата-центра, наличие технических и организационных механизмов защиты от основных типов угроз, общая репутация провайдера, формируемая годами. При необходимости соответствия законодательным требованиям в области защиты информации, например при организации защиты персональных данных, важно, чтобы провайдер мог предоставить сервисы информационной безопасности, основанные на средствах, сертифицированных ФСТЭК и ФСБ России.

Антон
Разумов

Руководитель группы консультантов по безопасности Check Point

1. В инфраструктурах ЦОД мы имеем дело с огромными объемами и потоками данных, доступ к которым необходимо контролировать без ущерба для производительности. Поэтому основными сервисами ИБ для ЦОД являются Firewall (межсетевой экран), обеспечивающий разграничение прав доступа и полномочий, а также система предотвращения вторжений IPS/IDS, помогающая выявить аномалии в трафике и предотвратить атаки.

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

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

Игорь
Богачев

Руководитель практики инфраструктурных решений компании“Астерос Информационная безопасность"(группа“Астерос")

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

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

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

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

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

Опубликовано: Журнал "Information Security/ Информационная безопасность" #6, 2014

Приобрести этот номер или подписаться

Статьи про теме