Опасности, подстерегающие владельцев традиционных и облачных сред, во многом одинаковы. Если взять, например, «грязную дюжину» — список главных угроз для облачных вычислений, который ежегодно публикует Cloud Security Alliance, то в большинстве своем они актуальны и для корпоративных ЦОДов. И все же с переходом в облако появляются дополнительные риски и новые виды угроз.
В этой связи очень важно понять, как именно разделяются задачи по обеспечению безопасности между пользователем и провайдером. Распределение обязанностей зависит от вида используемых услуг. Если это инфраструктура как сервис, то основная ответственность возлагается на пользователя, в частности, он сам отвечает за обновление программного обеспечения. А в случае услуг SaaS своевременное обновление ПО осуществляет провайдер.
Различные вопросы обеспечения информационной безопасности, в том числе требования к провайдеру, новые задачи по обеспечению ИБ при переходе в облако и совместная работа с провайдером по их решению, рассматривались на секции «Безопасность ЦОД и облака» форума «Мир ЦОД. Услуги. Облака», а также на завершающей сессию дискуссии «Безопасность ЦОД = безопасность облаков?».
ЗНАЙ СВОЕГО ПРОВАЙДЕРА
Провайдеры по-разному подходят к вопросу раскрытия информации о применяемых мерах безопасности. «Security by obscurity (закрытость информации как способ защиты. — Прим. ред.) — это неправильный подход к организации защиты, — заявил Денис Безкоровайный, генеральный директор ProtoSecurity. — В таком случае система не будет безопасной только потому, что никто не знает, что она собой представляет». Он считает, что провайдеру нет особого смысла сохранять секретность, чтобы не давать лишней информации потенциальным злоумышленникам: «С точки зрения обеспечения защиты абсолютно не важно, знает ли атакующий, какой именно межсетевой экран установлен. Главное, как он настроен, как часто обновляется, как администрируется и т. д.».
Между тем многие предубеждения могут быть сняты, если провайдер придерживается открытой политики в вопросах безопасности и предоставляет информацию о том, какие меры физической защиты он реализует, какие средства информационной безопасности использует, как осуществляется резервное копирование и восстановление, обрабатываются инциденты и т. д. Принятые меры станут дополнительным свидетельством надежности провайдера.
Вместе с тем проблема часто заключается в неспособности заказчика правильно оценить риски. Чтобы корректно это сделать, компании могут воспользоваться готовыми шаблонами — например Cloud Controls Matrix (CCM) от Cloud Security Alliance (CSA), где приводятся различные контрольные вопросы относительно кадровой политики, контроля доступа, физической защиты, процедур и т. д. В рамках программы добровольной сертификации альянс приводит на сайте перечень провайдеров, которые заполнили этот опросник по собственной инициативе; правда, российских компаний среди них немного.
Одним из показателей защищенности коммерческого ЦОДа является наличие у него сертификата на соответствие требованиям безопасности, например PCI DSS. Хотя этот стандарт касается только тех, кто занимается обработкой данных платежных карт, в нем сформулированы общие требования как к инфраструктуре, так и к организационным процедурам. По мнению Владимира Малиновского, руководителя продаж решений дата-центра Lattelecom, сертификация ЦОДов — стратегический вопрос. «Данная мера, — уверен он, — позволяет повысить конкурентную привлекательность предложения и качество предоставляемых услуг». В частности, Lattelecom сертифицировал один из своих ЦОДов на соответствие требованиям PCI DSS Level 1, что является самым высоким стандартом для инфраструктуры.
Для получения сертификата пришлось проделать большую работу, в которой участвовали более 20 человек. Для выявления любых аномалий во всех устройствах окружения ЦОДа была установлена система управлениями событиями и данными информационной безопасности IBM Qradar (наличие системы SIEM является обязательным требованием). Реализация данного проекта выявила 26 ошибок, в частности неотключенные устройства telnet, что позволило повысить уровень безопасности инфраструктуры Lattelecom.
Начиная с построения в 2013 году ЦОДа, на который был получен первый в Северной Европе сертификат Tier III Design и TIER III Facility от Uptime Institute, Lattelecom подходит к вопросу создания системы безопасности систематически: спустя год появился сертификат PCI DSS Level 2, в 2015-м реализована система защиты от DDoS-атак на базе решений Radware, в 2016-м развернута система RAPID7 для управления уязвимостями ИТ-систем, и, наконец, во втором квартале текущего года завершена сертификация на соответствие требованиям PCI DSS Level 1.
Как подчеркивает Владимир Малиновский, без компетентной команды экспертов все разговоры о безопасности не имели бы смысла: «Это основной капитал нашей компании — наличие экспертов по Linux, UNIX, Microsoft, Oracle, а также SAP и Cisco. Они позволяют сделать комплексные решения для любого запроса». Многолетний опыт работы по созданию безопасности собственных ЦОДов позволяет найти правильные и эффективные решения для защиты систем заказчика.
.png "Одним из показателей защищенности коммерческого ЦОДа является наличие у него сертификата на соответствие требованиям PCI DSS") |
| Одним из показателей защищенности коммерческого ЦОДа является наличие у него сертификата на соответствие требованиям PCI DSS |
ОДНА БЕЗОПАСНОСТЬ НА ДВОИХ
В облаке данные зачастую хранятся надежнее, чем в корпоративном ЦОДе. Персонал облачного провайдера имеет больше опыта в решении таких задач, как резервное копирование или обновление программного обеспечения. «Необходимо использовать компетентность сервис-провайдера. Вы как заказчик реализуете всего один проект, а мы параллельно ведем 10 проектов с разной спецификой, в реализации которых участвуют множество специалистов различного уровня», — говорит Владимир Малиновский. В конечном итоге ключевая задача технического персонала КЦОДа — защита данных клиентов.
Однако безопасность данных в облаке начинается с защиты ресурсов корпоративного ЦОДа. При компрометации сети компании хакеры могут использовать полученную информацию, например данные об учетных записях, для атаки на ее ресурсы, размещенные в облаке. Денис Безкоровайный советует: «Сначала каждый должен разобраться с тем, как у него обстоят дела с внутренней безопасностью, а уже потом беспокоиться, как она реализована где-то еще».
Безопасность и сохранность данных клиента в облаке зависят в первую очередь от него самого. Весьма показателен инцидент, произошедший с крупной производственной компанией, пользующейся услугами Lattelecom. В результате вирусной атаки на ее базы данных все файлы оказались зашифрованы. За резервирование отвечал сам клиент, но, как оказалось, имеющиеся копии были неактуальными. На запуск активных ВМ потребовалось три дня, на восстановление работоспособности Exchange и «1C» — около двух недель. А восстановление всех систем, включая виртуальные рабочие места, заняло почти месяц. Это оказало сильное негативное влияние на бизнес, поскольку задерживалась выписка счетов, накладных и прочих важных документов — бизнес фактически оказался парализованным.
Чтобы не допустить повторения подобной ситуации, специалисты Lattelecom предложили три возможных решения. Первое — установка системы хранения EMC Data Domain (затраты 200 тыс. евро), второе — организация второй площадки для аварийного восстановления (120 тыс. евро), третье — создание консистентных мгновенных снимков (10 тыс. евро). Выбор заказчика легко угадать, тем более что вся инфраструктура была перенесена в ЦОД провайдера.
Все, что потребовалось, — это приобрести дополнительный объем дискового места и необходимое программное обеспечение (если мгновенные снимки делать средствами хранилища, то они не будут консистентными, потому что эти изменения не отражаются в системах Microsoft). Преимущество такого решения — отсутствие необходимости останавливать ВМ и приложения для создания снимков, так как они делаются во время работы (процессов). Восстановление любого сервера занимает до 10 с, а снимки можно делать с частотой до четырех в час.
Как заключает Владимир Малиновский, во-первых, надо изменить свой подход к резервированию, а во-вторых, больше доверять провайдеру и обсуждать с ним возникающие проблемы. В описанном случае клиент сообщил о происходящем только на третий день после атаки. Если бы он не промедлил, системы можно было бы восстановить оперативно из имеющихся снимков платформы, которые делал провайдер.
БЕЗОПАСНОСТЬ ДОЛЖНА БЫТЬ ВСТРОЕННОЙ
Какой бы надежной ни была защита ЦОДа, этого недостаточно. При всеобщем присутствии в Интернете, основным объектом атаки становятся Web-приложения и сервисы. Согласно исследованию уязвимости данных компании Verizon (Data Breach Investigation Report, DBIR), слабым звеном являются именно Web-приложения: количество успешных атак на них, приведших к компрометации данных, с 2014 года выросло в четыре раза.
«Когда мы строим модели безопасности, то подразумеваем то, к чему привыкли, — безопасность инфраструктуры, — отмечает Рустэм Хайретдинов, генеральный директор компании Attack Killer и вице-президент InfoWatch. — Однако опора на мощную защищенную инфраструктуру ЦОДа не повод расслабляться и игнорировать защиту на уровне приложений». Соответствующие угрозы он разделяет на несколько уровней: процессы, архитектура, реализация, настройки, коммуникации, интерфейсы и профили.
Сервис может быть неправильно спроектирован, то есть в самой процедуре имеется какой-то изъян. Так, частая проблема интернет-магазинов — возможность получить товар, не оплатив его. В частности, на одном из сайтов можно было по прямой ссылке сразу перейти на страницу доставки оплаченного товара. Сама ссылка легко генерировалась по примеру аналогичных страниц (URL имели типовой формат), при этом контрольная точка для проверки факта оплаты товара отсутствовала. В результате злоумышленникам удалось похитить много дорогостоящей техники.
Когда процесс изначально построен с ошибкой, защитить его невозможно. Если же вдобавок он имеет неадекватную архитектуру, не рассчитанную на высокую нагрузку и не обеспечивающую необходимое распараллеливание процессов, никакие ресурсы и возможности ЦОДа не помогут: сервис в любой момент может оказаться под угрозой. Такие ситуации нельзя предотвратить внешними средствами, их можно устранить только изнутри. «Если на каждом этапе процесса не предусматриваются необходимые элементы безопасности, вряд ли их можно защитить «навесными» решениями», — предостерегает Рустэм Хайретдинов.
Даже при наличии хорошо спроектированной архитектуры программисты могут допустить ошибку. Их мотивация — быстро выпустить сервис по минимальной цене, особенно если заказ получен по итогам электронных закупок: кто меньше предложил, тот его и получил. К тому же с распространением принципов адаптивной разработки (agile) частота изменений увеличивается. Зачастую приложения меняются каждый день, и теперь никто не будет писать низкоуровневую документацию на код, как это было принято в стародавние времена, когда приложения менялись раз в квартал. В результате порой невозможно понять, ошибка ли это или задумка разработчика.
Случаются и проблемы в настройках: по недосмотру доступ может быть предоставлен не тому и не туда. В этой ситуации оператор ЦОДа тоже помочь не сможет, поскольку не знает, что была допущена ошибка. Соответственно, необходимо управлять и настройками. «Каждый раз надо не просто смотреть, что это за настройка, а выяснять, какие угрозы она в себе несет, — объясняет Рустэм Хайретдинов. — Если у человека есть доступ, надо проконтролировать, какие действия ему разрешены». Приложения обрабатывают данные, поступающие из разных источников, поэтому коммуникационные каналы и интерфейсы обмена должны контролироваться так же тщательно.
Однако, даже если все технические моменты учтены и необходимые меры защиты предусмотрены, есть еще одна опасность — человеческий фактор. Администратор, имеющий легальный доступ, может им злоупотребить: например, его могут шантажировать или у него может возникнуть обида на работодателя. Таким образом, необходимо профилирование действий пользователя. Примером плохо спланированного профиля может служить отсутствие ограничений на количество вводимых паролей, что делает возможным подбор нужного посредством перебора (brute force).
Таким образом, помимо защиты инфраструктуры, необходимо позаботиться и о защите самого сервиса. Если основной объем задач первой группы может взять на себя провайдер услуг ЦОДа, то о решении других задач клиенту придется позаботиться по большей части самому. Провайдер обеспечит защиту от атак DDoS, осуществит резервное копирование данных, поможет выявить уязвимости в системе, но он ничего не знает об архитектуре приложений, пользовательских сценариях, внутренних процессах и других особенностях инфраструктуры клиента.
К тому же, как подчеркивает Рустэм Хайретдинов, время «навесной» безопасности уходит — приложения и сервисы необходимо защищать не снаружи, а изнутри: «Защита должна быть встроенной — каждый процесс должен проверяться на безопасность. Это не навесной процесс, а отдельный слой в каждом процессе. Безопасность давно превратилась в некий иммунитет внутри процесса».
СТОИТ ЛИ ОБЛАКО РИСКА?
Переход в облако может дать компании целый ряд преимуществ. Некоторые возможности проще обеспечить на базе облачного ЦОДа — например, неограниченную масштабируемость, то есть возможность получать любые ресурсы как в случае динамического облачного ЦОДа. Кроме того, облачные провайдеры предлагают и уникальные сервисы. «Сервисы Lambda, Kinesis, DynamoDB, Redshift, — перечисляет Денис Безкоровайный, — вы не получите больше нигде, только у конкретного облачного провайдера. Реализовать же их самостоятельно вам вряд ли удастся». Однако переход в облако порой обрывается, так и не начавшись, если задачи по защите данных не решены.
В своем докладе Денис Безкоровайный выделил шесть стадий внедрения облачного подхода: экспериментирование, обеспечение безопасности, использование IaaS, PaaS, SaaS, подключение дополнительных сервисов, добавление уникальных сервисов и, наконец, полное принятие облака, когда вся деятельность компании построена с учетом его использования. Поэкспериментировав с облаком, многие организации этим и ограничиваются. «Очень многие на этом этапе в России просто останавливаются, потому что мало кто понимает, как управлять облачными сервисами и как защищать их, — говорит эксперт из ProtoSecurity. — Если этап обеспечения безопасности не пройден, никаких дальнейших внедрений и прогресса ожидать не приходится».
Что же меняется? Инструменты и технологии безопасности почти не отличаются. Одна из главных особенностей — изменение роли заказчика. «Если раньше вы защищали все сами, то теперь часть полномочий надо отдать третьей стороне и проверять, выполняются ли все договоренности», — объясняет Денис Безкоровайный. Мало кто из провайдеров готов предоставить полные данные о том, что он делает с точки зрения безопасности и как следует взаимодействовать с ним при расследовании какого-то происшествия. К тому же, указывает Владимир Малиновский, вы все равно не сможете узнать все нюансы защиты облачной инфраструктуры провайдера. Это уже не столько вопрос управления безопасностью, сколько вопрос выбора поставщика, но с точки зрения безопасности.
Вместе с тем безопасность не самоценность. Акцент все больше смещается в сторону экономических показателей, то есть эффективность системы безопасности характеризуется не числом инцидентов, а количеством сэкономленных средств в результате сокращения простоев, снижения ущерба и т. п. Соответственно, особое значение имеет соотношение возможностей и рисков. «Безопасность важна как обратная сторона возможностей. При переходе в облако лучше пробовать то, чего у вас нет, тогда больше внимания будете уделять возможностям, а не рискам», — советует Рустэм Хайретдинов.
Конечно, это не означает, что угрозы следует игнорировать (хотя потенциальная выгода иногда перевешивает любые риски). Меры по их снижению являются неотъемлемой частью процесса перехода в облако. Принимая решение о переходе в облако, необходимо учитывать чувствительность/критичность данных и предлагаемого провайдером уровня защиты, но в конечном итоге выбор будет зависеть от того, окажется ли польза для бизнеса более весомой, чем возможные риски.
Дмитрий Ганьжа, главный редактор «Журнала сетевых решений/LAN»