Дмитрий Костров:
А может не стоит с облаками-то связываться?

Дмитрий Костров, член Правления АРСИБ

Дмитрий Костров, член Правления АРСИБ

Как я уже писал, «облака» постепенно приходят в Россию, но не так мощно, как во всем мире. Одно из препятствий – доверие конечного клиента. Любой «безопасник» старой формации относится к публичным облакам как к личному врагу.

Это очень похоже на проблему внедрения HSM (Hardware Security Module – аппаратный модуль безопасности). Практически все специалисты, сталкивающиеся в своей работе с темой криптографической защиты, помнят, что злоумышленнику можно «отдать» все – сам шифратор, криптоалгоритм, криптомодуль и т. п., но НИКОГДА ключевой материал. А тут, понимаешь, устройство проводит внутри себя операции зашифровывания и расшифровывания поступающих данных, и, что самое «ужасное», криптографические ключи находятся там и не покидают устройства, в котором они же и были созданы.

Аналогичная ситуация с публичными облаками, особенно в виде облачных вычислений SaaS. Вспомним, что SaaS (Software as a Service – программное обеспечение как услуга) – это одна из форм облачных вычислений, модель обслуживания, при которой подписчикам предоставляется готовое прикладное программное обеспечение, полностью обслуживаемое провайдером. Основное преимущество модели SaaS по сравнению с другими (типа IaaS, PaaS) состоит в практически полном отсутствии затрат, связанных с установкой, обновлением и поддержкой работоспособности оборудования и работающего на нем программного обеспечения.

Недавно состоялась конференция «Эволюция облаков и ЦОД в эпоху цифровой трансформации», на которой выступали и известные поставщики решений, и провайдеры, тем не менее, понимания того, как убедить конечного пользователя, что публичные облака безопасны, не возникло. Клиенты часто задают вопросы, каким образом провайдер может доказать, что данные находятся на территории России. Наиболее продвинутые пользователи требуют, чтобы все файлы журналирования со всех инстансов и «железок» были направлены в SOC (Security Operation Center) клиента, причем они не понимают, что в модели SaaS нельзя выделить логи конкретного клиента, а высылать все логи – это уже слишком (нарушение политики безопасности провайдера). Единственный способ – доверие.

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

Зарубежные коллеги по информационной безопасности тоже готовят подобие модели угроз при создании информационных систем. Для них облака как часть их информационной системы является «черным ящиком». Они довольствуются предоставленными провайдером сертификатами типа ISO 27001, SOC 2 (аудит или аттестации), BS 10012 и т. п.

Изменить видение процесса обеспечения безопасности, особенно у любителей «кавалерийского прорыва времен Буденного»,  очень сложно, но это удается получением провайдером необходимых лицензий регулятора (ФСТЭК России), добровольной декларации, а лучше аттестации (аккредитованной компанией – независимой третьей стороной) «облачной структуры». Клиенту достаточно для понимания уровня защищенности показать аттестат соответствия информационной системы провайдера требованиям безопасности информации. Обычно аттестат удостоверяет, что объект информатизации, расположенный по определенному адресу, отвечает требованиям безопасности информации, предъявляемым к информационным системам персональных данных определенного уровня защищенности персональных данных (в соответствии с постановлением Правительства Российской Федерации от 1 ноября 2012 г. № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных») и информационным системам класса защищенности 1Г (в соответствии с руководящим документом «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации» Гостехкомиссии России, утвержденным решением Государственной технической комиссии при Президенте Российский Федерации от 30 марта 1992 г.).

Полагаю, что этого достаточно.

 

 

 

 

Добавить комментарий

Следите за нашими новостями в Телеграм-канале Connect


Поделиться:



Следите за нашими новостями в
Телеграм-канале Connect

Спецпроект

Медицинские задачи для ИИ

Подробнее
Спецпроект

Цифровой Росатом

Подробнее


Подпишитесь
на нашу рассылку