Облачным провайдерам на заметку

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

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

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

Сразу оговорюсь, что под "облачным сервисом" я пониманию в данном случае только SaaS-сервисы.

1) Обеспечение бесперебойности функционирования. Если вы начинаете использовать облачный сервис (почту, CRM, систему управления проектами и пр.), то как правило, у вас отсутствует возможность забекапировать систему и вы, получается, целиком должны довериться системам бекапирования, которые реализует провайдер.  Честно говоря, схема выглядит как-то очень ненадежно.  Поэтому "правильный" провайдер должен обеспечить одну из следующих возможностей:

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

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

2) Расширенные схемы аутентификации.  В большинстве случаев сейчас можно встретить только обычные парольные схемы. А как быть если я хочу обеспечить аутентификацию по токену ? или одноразовому паролю ? По-хорошему провайдер должен либо предоставить специализированный API, либо готовые варианты аутентификации с использованием различных (в т.ч. многофакторных) схем.  Однако, конкретно в  данном вопросе как правило есть возможность "прикрутить" к облачному сервису собственный механизм аутентификации, который обеспечит реализацию более надежной аутентификации поверх имеющейся парольной. 

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

4) Логи, и еще раз логи.  Журналы работы системы - это один из важнейших источников для оперативного выявления событий, которые могут негативно отразиться на деятельности организации, а также сбора необходимой базы для проведения расследования и юридического преследования возможных виновников. Предоставляет ли ваш провайдер логи работы системы (пусть даже только применительно к вашему экземпляру системы) ? Есть ли возможность отправить эти логи в SIEM-систему, чтобы обеспечить централизованный мониторинг и хранение информации ?  Боюсь что в большинстве случаев ответ на эти вопросы будет - "нет".  А ведь без этого вы вообще никак не контролируете что происходит в системе.

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

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

Этот материал можно опубликовать: