Обеспечение безопасности облачного сервиса — довольно сложная задача. Обязательства относительно доступности сервиса и защищенности данных в нем — неотъемлемая часть предложения и важный пункт SLA. Провайдеры облачных сервисов не скупятся на реализацию средств и мер информационной безопасности, поскольку защищенность обеспечивает им весомое конкурентное преимущество. Для этого используются антивирусные средства, межсетевые экраны различных уровней, системы противодействия DDoS и предотвращения вторжений, разнообразные «песочницы», SOC/SIEM и т. п. В хорошем облачном центре имеется круглосуточная служба мониторинга и отражения атак, состоящая из квалифицированных специалистов.

Однако обеспечение защиты становится куда более сложной задачей, когда облачный провайдер предоставляет своим пользователям возможность размещать их собственные сервисы по модели IaaS и PaaS. Тогда в защищаемой системе возникает слой клиентских приложений, контролировать качество которых провайдер не в состоянии. Уязвимое приложение может стать проблемой не только для тех, кто его написал, но и для других клиентов облачного провайдера. Неоднократно уже возникали ситуации, когда атаке подвергалось приложение, размещенное в центре обработки данных, но под ее воздействием оказывались недоступны все приложения. Кроме того, взломав одно приложение, например получив к нему привилегированный доступ, злоумышленник способен заразить и скомпрометировать другие в этом же облаке. Как бы ни были изолированы ресурсы, управление ими (или их частью) нередко осуществляется из одного центра.

Предоставляя клиентам API или просто ресурсы для облачного хостинга, его владельцы должны быть уверены в том, что размещенный в облаке код не снизит общую защищенность. Пока же в большинстве облачных сервисов клиентские приложения принимаются «как есть», а количество атак на уязвимые приложения только растет. Как разрешить эту проблему? Проводить пентесты? Организовывать независимую приемку приложений, как это делается при выпуске тиражируемых продуктов?

Но согласятся ли клиенты облачных сервисов на такие меры? Будут ли они оплачивать исследования своих приложений, размещенных в облачном сервисе? Вряд ли. В большинстве своем это бизнесмены, и скорость запуска сервисов для них важнее, чем их защищенность. Ресурсы, в том числе людские, у них тоже ограничены, и выбор между «добавить новые функции» и «исправлять уязвимости в старых» для них тоже очевиден — не исправлять. Им нет дела до рисков других клиентов, как и до рисков, исходящих от других клиентов сервиса, — они подписали SLA с конкретным сервисом и ожидают, что все проблемы с защищенностью будут решаться провайдером.

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

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

Наличия только требований и способов их контроля тоже недостаточно для решения проблемы некачественных приложений. Последним и самым трудным этапом внедрения жестких правил является реализация обратной связи: «Мы установили, что качество отправляемого в облако продукта неприемлемо. Что дальше?» Самым сложным для реализации этот элемент является потому, что при его внедрении возникает конфликт интересов бизнеса («Клиент хочет разместить свой продукт в нашем облачном сервисе, давайте скорее возьмем с него деньги!») и служб безопасности («Размещение такого продукта повышает риски атак на клиента, сервис в целом и других клиентов»). Каждый раз придется сопоставлять выгоду и риски.

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

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

Рустэм Хайретдинов, руководитель проекта Appercut, заместитель генерального директора ГК InfoWatch