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

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

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

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

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

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

Внедрение SQL-кода — когда злоумышленник пытается заполучить контроль над сервером, внедряя свой код в работающее на нём приложение. Эту опасность можно предотвратить путем разработки хорошего кода приложения и тестирования его безопасности, что обычно не входит в контракт с провайдером облака.

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

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

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

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

Качество и реактивность

Качество и скорость реакции — ключевые компоненты любой системы безопасности. Меры реагирования на инциденты должны допускать возможность следующих действий:

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

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

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

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