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

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

1. Физический доступ

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

2. Кризис идентификации

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

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

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

3. Шифрование

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

4. Предотвращение утечек информации

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

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

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

5. Конфиденциальность

В зависимости от конкретной отрасли и географии вашего бизнеса есть целый ряд аббревиатур, с которыми вам следует познакомиться: PCI, GLBA, CA1386, HIPAA, FERPA, Directive 95/46/EC. Этот список можно продолжать. Первым делом бизнесу необходимо инициировать создание системы предотвращения утечек информации и потерь данных.

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

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

6. Аудит

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

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

7. DoS-атаки

Атаки, направленные на отказ в обслуживании (Denial of Service, DoS), как правило, имеют сходную природу. Вероятность того, что они направлены именно на вашу организацию, довольно мала. Но когда атаке подвергается провайдер облачных сервисов, это может отразиться на всем бизнес-сообществе его клиентов. Как и в случае восстановления после сбоев, вам нужно знать, какую стратегию противодействия проводят поставщики, а время возобновления обслуживания должно оговариваться в соглашениях об уровне обслуживания (Service Level Agreement, SLA).