Санкции и уход западных провайдеров – далеко не единственная угроза облачным инфраструктурам и данным. Облака – такой же объект хакерских атак, как и собственный ИТ-ландшафт бизнеса. Кроме того, существуют риски технических проблем на стороне провайдера или в сетях передачи данных. Как защитить облачные сервисы, и куда в целом направлен ИБ-вектор облачного рынка – рассказывает Дмитрий Бородачев, исполнительный директор DатаРу Облако.
Разделенная ответственность
Облачный провайдер (или вендор облачного приложения) всегда несет ответственность за отказоустойчивость решения. Но это обстоятельство не снимает с компании-заказчика обязанности также заниматься ее обеспечением. То есть мы имеем дело с концепцией разделенной ответственности, когда за отказоустойчивость ИТ-системы одновременно отвечают и провайдер, и заказчик - в пределах, которые определяются особенностями использования облаков.
Например, провайдер, предоставляющий услуги IaaS, отвечает за безопасность своего облака до уровня виртуализации. А вот уровень операционной системы в составе виртуальной машины и выше – уже ответственность заказчика. Он должен контролировать безопасность данных, приложений, настроек безопасности операционки, управление доступом и права пользователей.
Отсюда берет начало перечень обязанностей заказчика. В него входит настройка и обновление приложений и сервисов, управление правами доступа и обеспечение безопасности учетных данных пользователей, регулярный бэкап и разработка планов действий в случае инцидентов.
Облачные риски
Риски, связанные с использованием облачных сервисов, зависят от того, как именно решения подобного класса используются.
Допустим, что в них размещены некритичные для компании системы, такие как файловый сервер с архивными документами. Отсутствие доступа к ним даже в течение нескольких дней скорее всего не вызовет проблем. В то же время неработоспособность продающего сайта способна принести компании многомиллионные убытки — такая проблема может характеризоваться как критическая.
Для того чтобы определить риски, связанные с облачными сервисами, нужно оценить требования к каждому их них. Делается это по формуле RTO/RPO. Здесь RPO – целевая точка восстановления, а RTO – целевое время восстановления. Их значения позволяют выделить объем допустимых потерь данных и диапазон времени, в которое сервис может быть недоступен.
Таким образом, мы получаем классический «треугольник принятия решения»: однозначного ответа на вопрос о том, какие именно риски возникают при потере соединения с облаком, не существует. Он зависит от того, насколько бюджет компании позволяет выполнить показатель RTO/RPO – требования к RTO/RPO возможно повышать или снижать путем балансировки показателей.
Особенности отказоустойчивости облака
Преимущества облачной инфраструктуры хорошо известны. Облака исключают капитальные затраты предприятий на содержание аппаратной инфраструктуры и ее обслуживание. Кроме того, их можно масштабировать (причем в любую сторону) по запросу. Использование собственных мощностей потребует для этого дополнительных капиталовложений.
Но переход на облачные решения не отменяет таких задач, как обеспечение отказоустойчивости систем и сохранение данных. При этом выбор в пользу облачной инфраструктуры диктует необходимость выполнения некоторых специальных мер. Дело в различиях между характером использования облачной и локальной инфраструктур.
Необходимость резервирования данных сегодня едва ли нуждается в пояснении. Резервные копии можно хранить и в облаке. Но для того чтобы гарантировать их сохранность, стоит выбирать хранилища другого провайдера. А еще лучше использовать мультиоблачные решения, когда копии данных размещаются у нескольких провайдеров. Это позволит всегда иметь доступ к бэкапам, даже в случае недоступности и «основного», и «резервного» облака.
Использование средств резервирования и постоянное обновление резервных копий не избавляет от необходимости обеспечения информационной безопасности. В случае с облачными системами это означает необходимость проведения их мониторинга.
Для этого применяются специальные программные инструменты – в том числе их предлагают и сами облачные провайдеры. Еще одна обязательная мера безопасности – наличие выстроенной системы управления правами доступа и строгая защита учетных записей пользователей, особенно тех, которые имеют доступ к облачным ресурсам.
Наконец, в компании должен быть разработан и принят план действий на случай сбоев. В нем прописывается состав и порядок действий в тех случаях, когда какая-либо система оказывается недоступной.
При этом будет логичным указать сроки выполнения предусмотренных мер в зависимости от показателей, прописанных в SLA провайдера. Этот план должен не только актуализироваться, но и периодически выполняться в рамках учений и тестирований системы обеспечения отказоустойчивости.
Немного о бэкапе
Резервное копирование сегодня – базовая обязательная мера для защиты данных. Но стоит понимать разницу между разными методами бэкапа. Выбор одного из них стоит делать исходя из требований бизнеса по RTO/RPO.
Резервное копирование, как правило, происходит в ежедневном режиме и позволяет сохранить все данные с постоянным добавлением в копию инкрементных, т.е. новых данных. Это – простой и бюджетный метод резервирования, который надежно защищает от проблем с шифровальщиками. Кроме того, резервирование легко организуется на стороне провайдера без доступа к самим данным. Правда, стоит учитывать, что восстановление займет достаточно много времени, а сами бэкапы необходимо постоянно проверять на возможность восстановления.
Для того, чтобы «глубина» бэкапа была небольшой, до 4 часов, применяется репликация. Она позволяет практически сразу перезапустить систему или откатиться на предыдущую ее версию, если она, к примеру, неудачно обновилась. Этот сервис тоже организуется на уровне провайдера. Но небольшая глубина по времени одновременно означает, что и точек восстановления данных при таком методе немного, и это снижает уровень защиты от тех же шифровальщиков, а ошибки или вредоносные файлы могут распространиться на всю резервную копию.
Самым взыскательным заказчикам подойдет так называемое гео-резервирование на уровне приложения. Оно предполагает создание двух «плеч» – отдельные копии данных в разных системах. Угроза потери данных при таком способе резервирования практически отсутствует, при этом при выходе из строя одной копии вторая сохраняет работоспособность. Но стоимость такой схемы резервирования высока, потому что она предусматривает дублирование мощностей.
До отказа
О тестировании облаков стоит сказать отдельно, поскольку эта задача не очевидна для многих заказчиков и требует известных технологических усилий и компетенций.
Прежде всего, облачные решения требуют периодического стресс-тестирования системы. Для этого необходимо создавать пиковые нагрузки на нее, чтобы убедиться, насколько уверенно та справляется с повышенным трафиком. Кроме того, во время стресс-тестирования анализируется поведение приложений и инфраструктуры.
Еще один вид проверки облака – имитация отказов, так называемый Chaos Engineering. Эта процедура предполагает искусственное отключение части системы или сервисов – так проверяется ее поведение при сбоях. Результат имитации отказа помогает понять, насколько система устойчива к неожиданным проблемам.
Тестироваться должны и планы восстановления. Делается это при помощи учений по плановому восстановлению. При этом в программу стоит включать и планы использования DRaaS-решений, чтобы проверить их работоспособность.
Помимо проверок планов восстановления, регулярным мероприятием должен быть аудит безопасности, который включает в себя проверки на наличие уязвимостей и соответствие стандартам безопасности. В ходе аудита проверяется и актуальность версий ПО.
Наконец, в регулярной проверке нуждаются и резервные копии, которые периодически нужно использовать для восстановления данных даже в тех случаях, когда инцидентов не происходило.
***
Как видим, универсального решения не существует. Поэтому стоит выбрать сочетание двух подходов к резервированию, например, копирование и репликацию. Искать такое сочетание необходимо исходя из требований бизнеса и в соответствии все с теми же показателями RTO/RPO. Кроме того, стоит помнить, что при любом варианте резервирования копии данных должны шифроваться, быть доступными ограниченному кругу пользователей и храниться в разных местах, у разных провайдеров.
Отказоустойчивость ИТ-инфраструктуры и систем – задача трудная и комплексная, поэтому один из оптимальных способов ее обеспечения это обратиться к облачным сервисам Подписка на облачный сервис не означает, что можно не уделять внимание проблеме безопасности. Несколько изменяются подходы к проблематике безопасности систем и данных, но не меняется принцип: компания всегда должна уделять максимум внимания «здоровью» своих цифровых активов.
