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

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

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

руководитель отдела информационной безопасности компании 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.

Другие новости и публикации
Статья
27.02.2024
Российские облака-2024: тост за рост?
Вас также могут заинтересовать
Linx NGFW
IS-18.png
Межсетевой экран следующего поколения
Nwtwork own PC
Разместите свое оборудование в дата-центрах с высоким уро...
Linx Backup
Backup copy
Автоматизированное управление резервными копиями виртуаль...
Outsourcing
Remote work
Аудит, модернизация и оптимизация ваших серверных мощностей
Network
Remote work
Обеспечьте отказоустойчивость и бесперебойную работу сети
Linx DRaaS
DraaS-023
Аварийное восстановление ИТ-инфраструктуры. Защитите ИТ-с...
Linx Private Cloud
Linxcloud
Готовая платформа для надежной работы бизнес-приложений
Linx IaaS
Iaas-02 copy
Отказоустойчивая и масштабируемая ИТ-инфраструктура для с...
Linx Kubernetes
Kubernetes
Автомасштабирование приложений с облачным Kubernetes от Linx
Linx DB
DB
Полностью управляемые и масштабируемые СУБД с гарантирова...
Что вас интересует?
Получить демо-доступ

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