Георгий Беляков
Руководитель отдела информационной безопасности компании Linxdatacenter
30.06.2021

Облачная броня

На что обратить внимание при защите систем и данных. Один из главных трендов информационной безопасности (ИБ) в облаках – стремление клиентов переложить как можно больше функций по ее обеспечению на провайдера. Также размывается понятие ИБ-периметра, растет роль услуг (MSSP-моделей) предоставления сервисов по IT-защите. Руководитель отдела информационной безопасности Linxdatacenter Георгий Беляков рассказал читателям RSpectr об определяющих тенденциях ИБ в облаках

Георгий Беляков,

руководитель отдела информационной безопасности компании Linxdatacenter

КЛИЕНТ VS ПРОВАЙДЕР

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

Второй базовый тренд: заказчики предпочитают выбирать облака, которые бы полностью закрывали их потребность в определенной области. Например, соответствующие требованиям тех или иных стандартов в информбезопасности, будь то норматив безопасности в сегменте платежных карт (PCI DSS) или законы о персональных данных (ПД).

Третий тренд – доверие клиентов к облачным провайдерам с каждым годом растет

Это обусловлено удобством с точки зрения эксплуатации IТ-систем. Не нужно думать об отказоустойчивости и жизненном цикле (end of life) оборудования, о масштабируемости, сроках истечения лицензий на средства защиты и многом другом. ИБ в облаке также серьезно снижает нагрузку на IТ-персонал заказчика.

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

ДВА ТИПИЧНЫХ ИБ-ЗАБЛУЖДЕНИЯ

Наиболее распространенный миф – это уверенность, что с арендой виртуальных ресурсов, отвечающих требованиям о ПД, клиент снимает с себя ответственность. Почему не работает установка: «Мы купили сервис виртуальной инфраструктуры (IaaS), который соответствует 152-ФЗ, и таким образом, закрываем все требования закона»?

Причина проста: в любом облачном сервисе по модели IaaS провайдер может нести ответственность только от уровня физической безопасности серверов до ПО для виртуализации ресурсов «железа» – то есть до гипервизора.

Все, что выше (виртуальные машины, ОС и приложения) – уже в компетенции клиента, поскольку облачный оператор не имеет доступа к IТ-системам заказчика.

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

Как бороться с этими заблуждениями?

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

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

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

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

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

АУТЕНТИФИКАЦИЯ В CLOUD-РЕСУРСАХ

Когда компания переносит информационную систему из внутренней структуры (on-premise) в облако, у него возникает проблема обеспечения защиты удаленного подключения.

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

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

«НУЛЕВОЕ ДОВЕРИЕ», ОТКАЗ ОТ ПЕРИМЕТРА

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

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

Также выбор технологии удаленного доступа во многом будет зависеть от архитектуры

Это может быть клиент-серверное соединение, remote VPN, когда пользователь подключается со своего рабочего места к какому-то серверу. Либо site-to-site VPN, когда соединение идет между двумя VPN-серверами, которые обеспечивают взаимодействие двух удаленных друг от друга подсетей.

Не стоит забывать и о требованиях к производительности и масштабируемости VPN. Сможет ли выбранная технология обеспечить быстрое добавление большого количества клиентов и увеличение нагрузки на VPN-каналы, если появится такая необходимость?

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

ШИФРОВАНИЕ НЕ ПАНАЦЕЯ

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

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

 КОМПЛЕКСНЫЙ ПОДХОД И MSSP

Часто словосочетания «комплексный подход» или «комплексная защита» воспринимаются как общее место, тривиальный и пустой ответ. Однако это единственная адекватная текущим ИБ-реалиям стратегия защиты IТ-систем в облаке. Если раньше межсетевой экран и антивирус рассматривались как отдельные классы средств ИБ, то сейчас актуальны UTM- (Unified Threat Management) и NGFW-решения (Next Generation Firewalls). Они сочетают функции межсетевого экранирования, защиты от вредоносного ПО и контентной фильтрации.

Каждое структурное подразделение в IТ-департаменте рассуждает об ИБ со «своей колокольни». Например, сетевой отдел хорошо разбирается в сетевых угрозах и решениях, но может не обратить внимание на другие проблемы, часто даже не связанные с информационными технологиями. Поэтому полагаться на одну точку зрения – ошибочный подход.

Сработает только общая оценка информсистем и применение комплекса решений

В определенной мере проблему комплексной защиты решает модель MSSP (управление сервисами по ИБ, Management Security Service Provider), когда оговоренный объем ИБ-мер из зоны ответственности заказчика переходит в область облачного провайдера. Как правило, эта услуга оформляется и тарифицируется отдельно от IaaS.

MSSP позволяет передать ИБ-сервис под управление провайдера, начиная от установки и первоначальной настройки инструмента защиты, и заканчивая его контролем, администрированием и мониторингом.

Здесь каждый клиент должен делать выбор для себя сам. У кого-то может не хватать персонала для мониторинга в режиме 24/7 или нет достаточных компетенций по распознаванию и анализу ИБ-инцидентов для выявления источника события. В каждом таком случае дефицит ресурсов информационной безопасности компенсируется MSSP.

Другие новости и публикации

Вас также могут заинтересовать

Linx Outsourcing
Аудит, модернизация и оптимизация ваших серверных мощностей
Подробнее
Аутсорсинг управления дата-центром
Linx Network
Обеспечьте отказоустойчивость и бесперебойную работу сети
Подробнее
Сетевые услуги
Linx DraaS
Аварийное восстановление ИТ-инфраструктуры. Защитите ИТ-системы уже сегодня!
Подробнее
Аварийное восстановление DRaaS

Напишите нам

Как мы оптимизировали управление ЦОДами клиента

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

Тарас Чирков, руководитель ЦОД Linxdatacenter в Санкт-Петербурге 

Константин Нагорный, главный инженер ЦОД Linxdatacenter в Санкт-Петербурге 

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

В главной роли – управление 

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

Роль надежных и производительных дата-центров в современной экономике постоянно растет вместе с требованиями к их бесперебойной работе. Однако на этом направлении существует большая системная проблема.  

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

Нет какого-то сводного канона с правилами, применимыми для любого дата-центра. Есть стандарты международной отраслевой организации Uptime Institute, но они устанавливают рамки и вектор развития, к каждому конкретному дата-центру они будут применяться по-разному.  

В масштабах страны  

На практике в России ситуация с эксплуатацией ЦОДов выглядит так.  

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

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

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

Все это выливается в ситуацию «кто во что горазд». «Разношерстный» состав команд эксплуатации из специалистов с разным бэкграундом, различные подходы к организации корпоративной архитектуры, взгляды и требования в отношении ИТ-департаментов.  

Факторов, приводящих к такому положению дел, много, один из главных – отсутствие систематизированной документации по выстраиванию эксплуатационных процессов. Есть пара вводных статей Uptime Institute, которые дают представление о проблеме и путях ее преодоления. Но дальше необходимо выстраивать систему своими силами. А на это ресурсов и компетенций хватит далеко не у каждого бизнеса.  

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

Кейс: через тернии к относительному порядку 

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

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

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

И здесь началось самое интересное.  

Познай себя 

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

Сразу же выяснилось – ИТ-департамент не знает, что именно хочет бизнес. Не было внутренних критериев качества сервиса, не было и понимания логики устройства собственной инфраструктуры.  

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

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

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

Улучшения в процессе 

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

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

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

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

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

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

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

Что сделано 

В процессе работ нам удалось решить несколько серьезных вопросов.  

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

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

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

Но нас удивило легкомысленное отношение компании к своей ИТ-инфраструктуре: от отсутствия резервирования критичных систем до хаоса в структуре и управлении.  

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

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

Выводы 

В целом перспективы консалтинга в сфере операционного управления дата-центрами, по нашему мнению, самые яркие.  

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

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

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

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

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

Облачная броня

БЭСТ, оператор системы денежных переводов и платежей.

Бизнес-вызов

Компания столкнулась с проблемой постоянного флага BGP-сессии с оборудованием Linxdatacenter. После изучения проблемы стало ясно, что на один из хостов в его сети происходила DDoS-атака.

Из-за распределенного характера атаки отфильтровать трафик было невозможно. Инженеры предложили решение, связанное с сокрытием хоста от внешней сети, но этот вариант не подходил заказчику. Атака прекратилась после внесения изменений в конфигурацию сервера, однако возобновилась на следующий день. Ее мощность достигла 5,5 Гбит/с, из-за чего перегружались «стыки» с интернет-провайдерами, что сказывалось на других пользователях облака Linxdatacenter. Чтобы обеспечить стабильную работу, было решено обратиться к надежному поставщику защиты от DDoS.

Решение

Чтобы обеспечить непрерывную доступность ресурсов, размещенных в облаке Linxdatacenter, весь трафик клиента был направлен через систему antiDDoS от StormWall. Атаку удалось погасить в течение получаса. Для предотвращения дальнейших кибератак все соединения сервисов клиента с интернетом были организованы через сеть StormWall.

Клиент:

БЭСТ, оператор системы денежных переводов и платежей.

Бизнес-вызов

Компания столкнулась с проблемой постоянного флага BGP-сессии с оборудованием Linxdatacenter. После изучения проблемы стало ясно, что на один из хостов в его сети происходила DDoS-атака.

Из-за распределенного характера атаки отфильтровать трафик было невозможно. Инженеры предложили решение, связанное с сокрытием хоста от внешней сети, но этот вариант не подходил заказчику. Атака прекратилась после внесения изменений в конфигурацию сервера, однако возобновилась на следующий день. Ее мощность достигла 5,5 Гбит/с, из-за чего перегружались «стыки» с интернет-провайдерами, что сказывалось на других пользователях облака Linxdatacenter. Чтобы обеспечить стабильную работу, было решено обратиться к надежному поставщику защиты от DDoS.

Решение

Чтобы обеспечить непрерывную доступность ресурсов, размещенных в облаке Linxdatacenter, весь трафик клиента был направлен через систему antiDDoS от StormWall. Атаку удалось погасить в течение получаса. Для предотвращения дальнейших кибератак все соединения сервисов клиента с интернетом были организованы через сеть StormWall.

Спасибо за ваш запрос, мы свяжемся с вами в ближайшее время!