Дмитрий Кузеванов, UserGate: ИБ распределённых систем в облаке выше, чем on-premise

Какие новые риски для безопасности возникают в обновлённых системах сейчас, когда к ним добавляются ещё и риски от перехода на российские системы сертификации. Об этом мы попросили рассказать Дмитрия Кузеванова, директора по информационной безопасности, руководителя центра мониторинга и реагирования (MRC) компании UserGate.

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

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

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

Какие риски ИБ возникают для корпоративных сетей с распределённой инфраструктурой?

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

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

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

У вас большой опыт работы в крупном отечественном ретейлере. Что происходит в реальной практике?

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

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

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

Важно отметить, что подход, когда головная организация продумывает не только ЧТО, нужно сделать, но и КАК это будет реализовываться, справедлив и эффективен не только для сферы ИБ.

Современные распределённые инфраструктуры отличаются высокой динамичностью из-за постоянного обновления элементов, появления IoT-устройств. Как удаётся справляться с рисками, если инфраструктура «уходит в облако»?

Д. К.: Многие ИТ-директоры до сих пор считают, что решения в формате on-premise безопасней, чем в облаке. Но практика показывает, что в 90 % случаев, если бизнес не связан с предоставлением ИТ-услуг, то в облаках всё же будет безопасней. Повышенный риск возникает именно в решениях on-premise.

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

Если ИТ не является для компании профильным бизнесом, то, как правило, она не может уделить вопросам ИБ столько же внимания, сколько организации, которые специализируются на предоставлении ИТ и ИБ-услуг. Следовательно, уровень защищённости их on-premise систем будет ниже, чем если бы использовалось облачное решение, где безопасность является частью предоставляемой услуги. 

Почему их поддержка лучше? Это их профильный бизнес и они жёстко регламентированы на исполнение требований законодательства: 152–ФЗ, PCI DSS, сертификация ЦОДов по уровням Tier и пр. Это заставляет поставщика облачных услуг обращать пристальное внимание на поддержку необходимого уровня безопасности, а клиенты получают от этого более высокий уровень защищённости. 

Надёжность работы в облаке обеспечивают резервные копии. Где их следует хранить?

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

На памяти инцидент 15 мая 2019 года с российским облачным провайдером. Тогда непреднамеренно (в результате человеческой ошибки) была удалена часть виртуальных машин в облаке, что сделало невозможным возврат данных.

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

Как оценить защищённости систем, работающих в распределённой инфраструктуре?

Д. К.: Проработка системы ИБ часто идёт параллельно с разработкой самой распределённой инфраструктурой. В этом случае уровень защищённости всегда получается высоким. Проблемы возникают, когда проектирование ИБ-системы выполняется без учёта реальных условий применения на распределённой инфраструктуре.

Достаточно рассмотреть ситуацию, когда теряется связь между инфраструктурой on-premise и облаком. С точки зрения проекта такая система должна продолжать работать вне зависимости от того, есть передача данных между облаком и «землёй» или нет. Система ИБ не должна деградировать. Это касается всех признаков: контроля недопустимых событий, временные задержки, снижение производительности и т.д.

Аналогичные подходы реализуются и в самом облаке. Облако — это по сути система, состоящая из распределенных ЦОДов, между которыми тоже может теряться связь. 

Как выстраивается сетевая безопасность в распределённой инфраструктуре?

Д. К.: Если говорить о сетевой аутентификации, то она выстраивается на работе инфраструктуры открытых ключей (PKI). Есть удостоверяющий центр (УЦ), который выдаёт удостоверение серверам — с их помощью подтверждается, что заявитель является тем, за кого себя выдаёт. Для этих целей может использоваться публичный УЦ, а в корпоративной инфраструктуре может применяться локальный УЦ. 

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

В целом, сетевая безопасность — это комплекс мер: использование безопасных соединений, аутентификация, цифровая подпись. За счёт применения этих инструментов риски снижаются до минимума. 

Как сказывается сейчас отказ от использования западных сертификатов?

Д. К.: Глобально с точки зрения УЦ ничего серьёзного не поменялось. Если мы используем сертификат, нормально полученный от УЦ, то в замене самого УЦ ничего страшного нет. Риски лежат в другой плоскости. 

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

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

Как следует распределять ответственность за безопасность между пользователем, службой ИБ, группой ИТ-поддержки и руководством компаний?

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

Самое уязвимое место — это человек. Уровень его ИБ-грамотности является определяющим для выстраивания надёжной системы безопасности.

Использование LLM (больших языковых моделей) создаёт риск появления непроверенных данных. Можно и нужно ли с этим бороться с точки зрения ИБ?

Д. К.: Проблема языковых моделей касается в первую очередь аргументированности получаемых данных. Сейчас языковая модель просто выдаёт ответ в заданной форме. Она не предоставляет аргументацию: на основании каких данных и правил ответ был сформирован, где была собрана исходная информация, на основании каких правил она была использована при генерации ответа.

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

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

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

Можно ли контролировать целостность данных, если она хранится частями в распределённых сетях?

Д. К.: Контроль неизменности и целостности данных позволяет, например, обеспечить применение технологии блокчейн. 

Остаются ли риски потери данных, если для них создаются облачные резервные копии?

Д. К.: Риски, конечно, остаются, но для их учёта следует принимать во внимание степень критичности данных. Важно понимать, что даже две резервные копии данных, каждая из которых может оказаться повреждённой, дают в итоге ненулевую вероятность (p1 x p2). 

Какие риски безопасности возникают при появлении IoT-устройств в распределённых сетях?

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

Но главная проблема IoT — это отсутствие регулярных обновлений прошивок. В заводских прошивках нередко обнаруживаются уязвимости. Но если обновления для обычных сетевых устройств более-менее налажены, то IoT-устройства «живут своей жизнью». 

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

Спасибо большое за интервью, Дмитрий! Удачи вам в реализации ваших планов.