Инструменты методики АЦТ, часть 46: облачная безопасность (Cloud Security), анализ угроз (Threat Intelligence), «Управление кибер-рисками» (Risk Management) и архитектура нулевого доверия (Zero Trust Architecture)

Это сорок шестая статья цикла по инструментам методики «Аккордная цифровая трансформация». Продолжаем группу I «Кибербезопасность и управление рисками» подгруппой I2 «Продвинутые инструменты защиты» — инструменты I2-01, I2-02, I2-03 и I2-04.

Четыре инструмента этой статьи развивают основание, заложенное в предыдущей статье цикла, применительно к более сложным и специфическим угрозам. Облачная безопасность (I2-01) защищает данные и сервисы там, где инфраструктура принадлежит внешнему поставщику, а не самому предприятию. Анализ угроз (I2-02) собирает и интерпретирует сведения о конкретных атакующих, а не об угрозах в общем виде. Инструмент, названный в методике «Управление кибер-рисками», по своему фактическому содержанию посвящен постквантовой криптографии — защите данных от атак, которые пока не может провести ни один существующий компьютер, но для которых уже сегодня похищаются зашифрованные данные (I2-03). Архитектура нулевого доверия (I2-04) заменяет доверие к внутренней сети постоянной проверкой каждого запроса независимо от его источника. Трудоемкость составляет 30 часов у облачной безопасности, 34 часа у анализа угроз, 36 часов у постквантовой криптографии и 40 часов у архитектуры нулевого доверия. Все четыре инструмента отнесены методикой к сложным. В сумме 140 часов.

I2-01 — Облачная безопасность (Cloud Security)

Откуда появился инструмент. По мере того как предприятия в конце 2000-х годов начали переносить инфраструктуру к облачным провайдерам, встал вопрос о границах ответственности: если данные хранятся не на собственном сервере компании, а на оборудовании стороннего поставщика, кто отвечает за их защиту. В 2011 году компания Amazon Web Services формализовала ответ в виде модели разделенной ответственности: поставщик отвечает за безопасность самой облачной инфраструктуры — оборудования, сети, физических дата-центров, — тогда как заказчик отвечает за безопасность того, что он размещает в облаке: настройку доступа, шифрование, конфигурацию сервисов. Эта граница выглядит понятной на бумаге и оказывается источником путаницы на практике, когда обе стороны считают ответственной друг друга.

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

Цену размытой границы ответственности между поставщиком облака и его клиентом видно на одной из крупнейших утечек в истории банковского сектора.

Модель разделенной ответственности сама по себе ничего не защищает: она лишь называет сторону, которой предстоит объяснять произошедшее, если защита не сработала на ее половине границы.

Границы применимости. Инструмент применим на любом предприятии, размещающем данные, приложения или инфраструктуру в публичном, частном или гибридном облаке. По методике это сложный инструмент. Первое ограничение касается понимания границы ответственности: заказчик облака нередко предполагает, что провайдер защищает больше, чем указано в договоре, и это предположение обнаруживает свою ошибочность уже после инцидента. Второе — множественность настроек: современные облачные платформы предоставляют десятки параметров конфигурации безопасности, и упущенная настройка создает уязвимость, не связанную с самой платформой. Третье — видимость происходящего: данные и процессы, вынесенные за пределы собственной инфраструктуры предприятия, труднее отслеживать традиционными средствами мониторинга, рассчитанными на локальную сеть. Облачная безопасность опирается на осведомленность о безопасности (I1-01) и управление рисками качества (I1-02) как на источники сведений об уязвимостях конфигурации и связана с архитектурой нулевого доверия (I2-04) как со смежным подходом к контролю доступа.

Чек-лист перед внедрением облачной безопасности:

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

Типовые ошибки:

• Ошибочное предположение об ответственности провайдера. Заказчик полагает, что поставщик облака защищает больше, чем предусмотрено договором. → Точно определять и документировать границу ответственности до размещения данных в облаке.
• Отсутствие регулярного аудита конфигурации. Настройки доступа проверяются только при первоначальном развертывании. → Устанавливать периодическую проверку конфигурации на протяжении всего срока эксплуатации.
• Слепая зона мониторинга. Облачная инфраструктура остается вне охвата средств обнаружения угроз, рассчитанных на локальную сеть. → Распространять мониторинг и обнаружение угроз на облачную среду наравне с локальной.
• Избыточные права доступа. Учетным записям и сервисам предоставляются более широкие полномочия, чем требуется для их задач. → Применять принцип минимально необходимых привилегий при настройке доступа.

I2-02 — Анализ угроз (Threat Intelligence)

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

Суть и механика. Анализ угроз — методика сбора, анализа и интерпретации данных об угрозах информационной безопасности. Это комплексный подход к изучению целей, тактики и инструментов злоумышленников, который позволяет организациям выстроить эффективную стратегию защиты от атак. Основная цель Threat Intelligence — обеспечить организации актуальной информацией, которая позволит предугадывать потенциальные атаки до их реализации, распознавать угрозы на ранних стадиях, принимать обоснованные решения по защите информационных активов, минимизировать риски и потенциальный ущерб от кибератак. Threat Intelligence объединяет три взаимосвязанных элемента: контекст — информацию о злоумышленниках, их мотивах, целях и методах; индикаторы компрометации — технические маркеры, указывающие на потенциальную угрозу; взаимосвязи и обогащения — дополнительную информацию, связывающую различные аспекты угрозы.

Переход от анонимной угрозы к описанному, отслеживаемому противнику виден на самом отчете, с которого отрасль ведет свой отсчет.

Ценность анализа угроз в том, что он переводит защиту с реакции на изолированный инцидент на работу против конкретного, изученного и предсказуемого в своих методах противника.

Границы применимости. Инструмент применим на предприятиях, обладающих собственной службой безопасности или пользующихся услугами внешнего поставщика такого анализа, поскольку сведения об угрозах нуждаются в интерпретации применительно к конкретной инфраструктуре. По методике это сложный инструмент. Первое ограничение относится к актуальности сведений: тактика атакующих меняется, и индикаторы компрометации, актуальные вчера, устаревают по мере того, как противник меняет инфраструктуру. Второе — избыток данных без приоритизации: поток сведений об угрозах способен превысить возможности службы безопасности его обработать, если заранее не определено, какие угрозы значимы именно для этого предприятия. Третье — атрибуция как вероятностная, а не точная оценка: связь атаки с конкретной группой строится на совокупности косвенных признаков и может пересматриваться по мере поступления новых данных. Анализ угроз опирается на управление рисками качества (I1-02) как на источник приоритетов и служит основанием для управления информационной безопасностью (I1-04) в части настройки матрицы MITRE ATT&CK под конкретных, актуальных для предприятия противников.

Чек-лист перед внедрением анализа угроз:

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

Типовые ошибки:

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

I2-03 — «Управление кибер-рисками» (Risk Management)

Откуда появился инструмент. В 1994 году математик Питер Шор предложил алгоритм, который позволяет достаточно мощному квантовому компьютеру раскладывать большие числа на множители и вычислять дискретные логарифмы за практически приемлемое время. Именно на неразрешимости этих задач за разумный срок классическими компьютерами держится защищенность почти всей современной криптографии с открытым ключом, включая алгоритмы RSA и эллиптическую криптографию. В 2001 году компания IBM продемонстрировала алгоритм Шора практически, разложив число 15 на множители 3 и 5 на семикубитном квантовом компьютере — доказательство принципа на игрушечном примере, не представлявшее угрозы ни одной реальной системе, но подтвердившее, что математика работает. Национальный институт стандартов и технологий США начал в 2016 году открытый конкурс по отбору алгоритмов шифрования, устойчивых к атакам квантовых компьютеров, и в августе 2024 года утвердил первые три таких стандарта.

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

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

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

Границы применимости. Инструмент применим на предприятиях, работающих с данными, сохраняющими ценность на протяжении многих лет: в государственном управлении, оборонной промышленности, здравоохранении, долгосрочном финансовом планировании. По методике это сложный инструмент. Первое ограничение связано с неопределенностью сроков реальной угрозы: никто не знает точно, когда появится квантовый компьютер, способный взломать современное шифрование, что затрудняет обоснование инвестиций перед руководством, не видящим угрозы вживую. Второе — производительность новых алгоритмов: постквантовые схемы шифрования зачастую требуют больше вычислительных ресурсов и создают более объемные ключи и подписи, чем классические аналоги. Третье — совместимость с существующей инфраструктурой: переход на новые алгоритмы шифрования требует обновления оборудования и программного обеспечения, взаимодействующего по всей цепочке передачи данных, а не только на одном узле. Этот инструмент применяет принципы, изученные при управлении рисками качества (I1-02), к специфической категории долгосрочных угроз и опирается на облачную безопасность (I2-01) в части защиты данных, хранящихся у внешних провайдеров.

Чек-лист перед внедрением постквантовой криптографии:

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

Типовые ошибки:

• Отсутствие плана из-за неопределенности сроков. Переход откладывается, поскольку точный момент появления квантовой угрозы неизвестен. → Начинать переход для наиболее долгоживущих данных заранее, не дожидаясь появления угрозы.
• Игнорирование стратегии «собери сейчас, расшифруй позже». Данные, чувствительные в долгосрочной перспективе, продолжают защищаться уязвимыми алгоритмами. → Приоритизировать переход именно для данных с долгим сроком актуальности.
• Недооценка требований к производительности. Постквантовые алгоритмы внедряются без учета возросшей нагрузки на инфраструктуру. → Оценивать влияние на производительность до полномасштабного внедрения.
• Частичный переход без учета всей цепочки. Алгоритм обновляется на одном узле, тогда как связанные системы остаются несовместимыми. → Проверять совместимость по всей цепочке передачи данных.

I2-04 — Архитектура нулевого доверия (Zero Trust Architecture)

Откуда появился инструмент. Термин предложил в 2010 году Джон Киндерваг, аналитик исследовательской компании Forrester, в докладе, утверждавшем, что традиционные межсетевые экраны недостаточны против современных атак, а доверие к трафику внутри периметра сети — фундаментальная уязвимость сама по себе. По собственному признанию автора, само название отчасти было шуткой в адрес коллег по отрасли: оно отсылало к пословице «доверяй, но проверяй», которую в разговорах с Михаилом Горбачевым любил повторять Рональд Рейган, хотя ни США, ни СССР друг другу не доверяли. Компания Форрестер обнаружила, что специалисты по безопасности точно так же охотно доверяют многому и проверяют слишком мало. Практическим воплощением идеи стала внутренняя инициатива Google под названием BeyondCorp, запущенная в 2009 году в ответ на масштабную атаку на компанию и опубликованная в 2014 году. Доступ к корпоративным ресурсам предоставлялся по проверке личности пользователя и состояния устройства, а не по признаку нахождения в защищенной сети, что позволило сотрудникам работать без корпоративной сети VPN.

Суть и механика. Архитектура нулевого доверия строится на принципе «никому не доверяй, проверяй всех» для защиты периметра. Суть методики — каждый запрос проверяется, даже если он из внутренней сети. Это помогает предотвратить утечки данных, взломы облачных сервисов и другие угрозы кибербезопасности. Некоторые элементы Zero Trust Architecture: многофакторная аутентификация для административных панелей и минимальные привилегии, при которых пользователю и системе предоставляется ровно тот объем доступа, который необходим для конкретной задачи, и не более того.

Разницу между защитой периметра и постоянной проверкой каждого запроса видно на переходе одной из крупнейших технологических компаний от корпоративной сети к архитектуре без границ.

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

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

Чек-лист перед внедрением архитектуры нулевого доверия:

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

Типовые ошибки:

• Единовременный переход без поэтапности. Архитектуру доступа пытаются полностью заменить одним проектом. → Внедрять архитектуру нулевого доверия поэтапно, начиная с наиболее критичных ресурсов.
• Игнорирование удобства пользователей. Дополнительные проверки внедряются без учета повседневных рабочих сценариев. → Проектировать проверки с учетом реального опыта использования сотрудниками.
• Опора на недостоверные данные о пользователях. Решения о доступе принимаются на основе неактуальных сведений о личности или устройстве. → Обеспечивать точность и актуальность данных, на которых строятся решения о доступе.
• Частичное внедрение с сохранением доверенного периметра. Новая модель доступа сосуществует с прежним доверием к внутренней сети. → Последовательно устранять доверие к сетевому расположению как таковому.

Резюме

Четыре инструмента этой статьи продолжают группу I и отвечают на угрозы, для которых базовых систем безопасности недостаточно. Облачная безопасность защищает инфраструктуру, которая больше не находится под прямым контролем предприятия. Анализ угроз переводит защиту с реакции на абстрактную опасность на работу против конкретного, изученного противника. Постквантовая криптография готовит защиту к угрозе, которая пока не существует технически, но уже действует экономически через накопление похищенных данных. Архитектура нулевого доверия отказывается от самой идеи защищенного периметра, внутри которого можно было бы доверять по умолчанию. Отчет Mandiant об APT1 и проект Google BeyondCorp разделены годом и разными задачами, но объединены одной логикой: оба показывают, что защита становится эффективной в тот момент, когда абстрактная угроза превращается в конкретно описанного противника или конкретно проверяемый запрос. Защита перестает быть общим утверждением о необходимости быть осторожнее. Суммарная трудоемкость в 140 часов выше, чем в предыдущей статье о базовых системах безопасности, и это отражает характер задач: здесь каждый инструмент нацелен на конкретную, технически сложную категорию угроз, а не на общее укрепление защиты. Продвинутые инструменты защиты имеют смысл только поверх основания, заложенного базовыми системами безопасности, а не вместо него.

В следующей статье цикла продолжим группу I подгруппой I3 «Промышленные и IoT-решения»: разберем безопасную разработку промышленных систем управления, защиту устройств интернета вещей и безопасность операционных технологий.