Как разработать проект архитектуры безопасности

~ 25 минут

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

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

Что такое архитектура информационной безопасности

✏️ Архитектура информационной безопасности — это комплекс мер и решений, который определяет стратегию, технологии и процессы для защиты информационных активов организации.

В архитектуру ИБ входят такие элементы:

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

Потребность в проектировании архитектуры ИБ появляется тогда, когда команда начинает проектировать IT-инфраструктуру с нуля или собирается внести в готовое решение значительные изменения.

Архитектуру ИБ начинают разрабатывать после того, как провели анализ угроз, уязвимостей и рисков. Только на этом этапе становится понятно, какие аспекты требуют защиты.

Время разработки проекта зависит от масштаба компании и сложности её информационных систем. Обычно это занимает от нескольких недель до нескольких месяцев.

Остановимся подробнее на том, кто разрабатывает проект архитектуры ИБ. Тут есть несколько сценариев:

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

Как разработать проект архитектуры безопасности

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

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

В разработке проекта всего четыре шага.

Разберём их по порядку, а потом покажем пример поэтапной разработки стратегии.

Шаг 1. Анализ и приоритизация угроз

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

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

Шаг 2. Определение пороговых значений рисков

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

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

Пороговые значения определяют совместно с менеджментом. При этом обязательно учитывают потенциальные финансовые и репутационные потери.

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

Шаг 3. Формирование списка необходимых мер (roadmap)

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

Результат этого этапа — roadmap или, иначе говоря, «дорожная карта» развития архитектуры. Roadmap состоит из списка согласованных и приоритизированных технических и организационных мер безопасности. Для каждого шага дорожной карты указывают:

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

🔍 Изучите пример готового roadmap. Это поможет понять, как такой документ может выглядеть на практике.

Четвёртый этап стратегии в примере готового roadmap — это внедрение SOC. Кратко расскажем, что это такое.

SOC, или Security Operations Center, — это централизованное подразделение, которое занимается вопросами безопасности на организационном и техническом уровне. SOC состоит из SOC-аналитиков. Эти специалисты реагируют на атаки хакеров в режиме реального времени и анализируют инциденты безопасности. Они отвечают за мониторинг, обнаружение потенциальных угроз и реагирование на них, а также за атаки на информационную инфраструктуру.

SOC-аналитики в работе используют особый класс ПО, который называется SIEM (Security Information and Event Management). Эти программы позволяют собирать и анализировать информацию о событиях безопасности.

Внедрение механизмов мониторинга — это важный шаг стратегии. Рекомендуем воспринимать его как обязательный этап. Без мониторинга компания не сможет отследить, какой результат принесут принятые меры, и вовремя скорректировать стратегию.

Шаг 4. Мониторинг изменений

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

Фактически последний этап жизненного цикла стратегии — это постоянная адаптация под изменения.

Процесс адаптации невозможен без постоянного мониторинга изменений. Чтобы мониторинг был качественным, рекомендуем:

Внедрить систему мониторинга безопасности (SIEM) — настройте сбор и анализ логов, а также автоматические оповещения при обнаружении аномалий.
Использовать сканеры уязвимостей — регулярно сканируйте инфраструктуру на наличие уязвимостей и обновляйте план безопасности, основываясь на его результатах.
Мониторить сетевую активность — установите системы для выявления подозрительного сетевого трафика.
Контролировать изменения конфигураций — используйте инструменты для отслеживания изменений в ключевых системах и настройках.
Создать систему оповещений — настройте уведомления для ответственных лиц при выявлении инцидентов.
Регулярно проводить анализ и формировать отчётность — ежемесячно анализируйте результаты мониторинга и актуализируйте меры безопасности.

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

А теперь посмотрим, как разработка стратегии может выглядеть на практике.

Пример поэтапной подготовки проекта архитектуры

Организация CyberArena — это крупная киберспортивная платформа, которая организует турниры по популярным видеоиграм. Компания предоставляет пользователям услуги онлайн-регистрации и участия в турнирах, хранит личные данные участников и их результаты, организует прямые трансляции, а также выплачивает призовые за победу в турнирах.

Платформа состоит из веб-приложения и серверной инфраструктуры для хранения данных.

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

Шаг 1. Анализ и приоритизация угроз

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

Угроза	Описание	Оценка риска
Подмена данных при транзакциях	Возможность изменения данных во время транзакций призовых выплат. Это не только репутационные, но и прямые финансовые потери	Крайне высокая
Утечка личных данных	Возможна утечка данных участников через уязвимости в веб-приложении или серверной инфраструктуре	Высокая
Неавторизованный доступ к административной панели	Злоумышленник может получить несанкционированный доступ к панели управления. Возможно как изменение данных (о призах или результатах турниров), так и утечка конфиденциальных данных	Высокая
DDoS-атака	Потенциальна возможная атака во время проведения онлайн-турнира. Приведёт к временной недоступности сервиса	Средняя

Шаг 2. Определение пороговых значений рисков

В ходе обсуждения вероятных угроз с менеджментом команда безопасности приняла такие пороговые значения:

Угроза	Пороговое значение риска
Подмена данных при транзакциях	Совершенно недопустим — любые попытки подмены должны быть пресечены
Утечка личных данных	Недопустим — вероятность должна быть сведена к минимуму
Неавторизованный доступ к административной панели	Недопустим — вероятность должна быть сведена к минимуму
DDoS-атака	Допустим при условии быстрого восстановления — менее 10 минут

Шаг 3. Формирование списка мер безопасности (roadmap)

Не будем приводить roadmap целиком. Сосредоточимся на мерах безопасности, которые нужно реализовать.

Угроза 1. Утечка личных данных

Шифрование базы данных
Например, pgcrypto для Postgres DB или Transparent Data Encryption для Microsoft SQL Server.
Пентесты и анализ кода
Проводить регулярные тесты на проникновение и анализ кода веб-приложения для выявления уязвимостей.
Динамический анализ веб-трафика
Внедрить инструменты для мониторинга и анализа веб-трафика, выявляющие попытки различных атак.
Многофакторная аутентификация (MFA)
Внедрить MFA для доступа пользователей к личным аккаунтам и административной панели.

Угроза 2. DDoS-атака

DDoS-защита
Подключить сервис облачной защиты от DDoS-атак — Яндекс DDoS Protection, RT-Solar или другие альтернативы.
Мониторинг сети
Настроить мониторинг сетевой активности для быстрого обнаружения и оперативной реакции на аномальные потоки данных.

Угроза 3. Неавторизованный доступ к административной панели

Многофакторная аутентификация (MFA)
Контроль доступа на основе ролей (RBAC)
Логирование действий в административной панели

О том, как настроить MFA и RBAC, мы расскажем дальше в курсе.

Угроза 4. Подмена данных при транзакциях

Токенизация
Использовать токенизацию платёжных данных и шифрование транзакций.
Контроль целостности данных
Внедрить механизм контроля целостности транзакций с использованием хеширования — Hash-Based Message Authentication Code или HMAC и журналирования.
Уведомления
Настроить систему автоматического уведомления о подозрительных транзакциях.

Этого достаточно для начала работы. Но в нашей схеме проигнорирован один очень важный момент — законодательный.

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

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

Наступает момент, когда игрок выигрывает в турнире. CyberArena просит его указать реальные данные, чтобы организовать выплату приза. Данные пользователей хранятся на территории РФ, и законодательство не нарушается. Но для получения подтверждения о победе в турнире нужно, чтобы ФИО и телефон победителя совпали на двух платформах: игровой зарубежной и турнирной отечественной.

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

Это пример запроса:

JSX

POST /our-super-game/user/{nick}/check
Content-Type: application/json

{
  "FIO": "Иванов Иван Иванович",
  "tel": "+123456789"
}

Пример ответа:

JSON

{
  "check": true
}

Сам API:

YAML

openapi: 3.0.0
info:
  title: Our Super Game API
  version: "1.0.0"

paths:
  /our-super-game/user/{nick}/check:
    post:
      summary: Проверка данных пользователя
      parameters:
        - name: nick
          in: path
          description: Никнейм пользователя
          required: true
          schema:
            type: string
      requestBody:
        description: Данные пользователя для проверки
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                FIO:
                  type: string
                  description: Полное имя пользователя
                tel:
                  type: string
                  description: Номер телефона пользователя
      responses:
        '200':
          description: Результат проверки
          content:
            application/json:
              schema:
                type: object
                properties:
                  check:
                    type: boolean
                    description: Результат проверки (true/false)

Можем ли мы передать данные победителя в API зарубежной платформы? Или должны искать другие пути решения? Это мы обсудим уже в следующем уроке.

А сейчас — время практики. Выполните несколько заданий, чтобы закрепить новый материал, и подведём итоги урока.

Задание 1

Расположите шаги подготовки проекта архитектуры безопасности в правильной последовательности.

Определение пороговых значений рисков

Шаг 2

Определение пороговых значений рисков — это второй шаг.

Определение и приоритизация угроз

Шаг 1

Процесс разработки проекта безопасности начинается с определения угроз и их приоритизации.

Мониторинг и адаптация к изменениям

Шаг 4

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

Формирование мер безопасности

Шаг 3

Чтобы сформировать меры безопасности, нужно определить угрозы и пороговые значения угроз. Это третий шаг.

Задание 2

Выберите утверждения, которые правильно описывают процесс разработки проекта архитектуры безопасности.

На этапе анализа угроз достаточно выявить угрозы и уязвимости

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

Когда определяете пороговые значения рисков, важно учитывать бюджет компании

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

Пороговые значения рисков могут определить только сотрудники отдела ИБ

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

Список реализуемых мер безопасности должен включать угрозы как с высоким приоритетом, так и с более низким

Список реализуемых мер включает угрозы с разным уровнем приоритета. Просто меры для наиболее критичных угроз внедряются на ранних этапах реализации плана безопасности.

Мониторинг изменений позволяет оперативно находить и устранять причины реализованных угроз безопасности

Мониторинг изменений разработанного плана архитектуры безопасности позволяет поддерживать актуальность выработанных мер и быстро реагировать на появление новых угроз и изменений в информационной системе.

А теперь повысим сложность заданий — посмотрим, как теория работает для практических кейсов. Изучите кейс компании «Строим сами» и ответьте на несколько вопросов.

Кейс компании «Строим сами»

Компания «Строим сами» продаёт широкий спектр строительных материалов и оборудования. Она ориентирована на рынок DIY — «Do It Yourself», или «сделай сам». Компания небольшая: она работает в одном регионе, у неё 10 магазинов и центральный офис.

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

Руководитель IT-отдела решил, что, прежде чем расширять функциональность, необходимо провести внутренний аудит безопасности. Его беспокоит, что сейчас нет чёткого плана действий для обеспечения непрерывности бизнеса и соответствия бизнеса требованиям безопасности по мере роста.

Подытожим всю информацию. Компания «Строим сами»:

Владеет сетью супермаркетов в регионе — 10 магазинов.
Осуществляет продажи как в офлайн-магазинах, так и онлайн.
Имеет собственную программу лояльности.
Сотрудничает с более чем 50 поставщиками, чтобы продавать собственные товары в магазинах и онлайн. Процесс работы с поставщиками полностью проходит через IT-системы.
В краткосрочной перспективе планирует развивать онлайн-обслуживание покупателей. В долгосрочной перспективе хочет создать маркетплейс, чтобы продавать товары партнёров.
Разрабатывает основные IT-системы in-house. Ещё у компании много интеграций с партнёрами — платёжные шлюзы, документооборот и так далее.
Нет штатных специалистов по информационной безопасности и инженеров по эксплуатации.

Задание 3

Выберите риски безопасности, с которыми может столкнуться компания.

Утечка данных пользователей интернет-магазина

Утечка данных интернет-магазина может существенно подорвать доверие клиентов и нанести урон репутации.

Неавторизованный доступ к административной панели

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

Выход из строя вспомогательных систем, которые не связаны с онлайн-продажами, из-за технических неисправностей

Технические неисправности не связаны с безопасностью IT-системы.

Потеря данных из-за кибератак

Потеря данных в результате кибератак — это значительный риск для бизнеса, особенно при работе с онлайн-платформой.

Кража интеллектуальной собственности

Кража интеллектуальной собственности не так актуальна для компании. Она продаёт товары, а не инновационные разработки.

Получение доступа к БД компании из-за ошибок в настройке безопасности

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

Подмена данных клиентов, которые участвуют в программе лояльности

Подмена данных в программе лояльности может привести к нарушениям в работе программы и утрате доверия клиентов. Это негативно скажется на бизнесе.

Задание 4

Какие риски имеют наивысший приоритет для компании? Учтите, что критические риски должны быть проработаны в ближайшее время.

Утечка данных пользователей интернет-магазина

Утечка данных интернет-магазина может существенно подорвать доверие клиентов и нанести урон репутации компании. Этот риск требует быстрого реагирования.

Некорректная интеграция с платёжными шлюзами

Ошибки при интеграции с платёжными шлюзами могут привести к сбоям при проведении онлайн-платежей. Это критично для работы интернет-магазина.

Задержки в обновлении контента на веб-сайте

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

Отказ сервисов, которые не влияют на продажи

Сбои в работе второстепенных сервисов не окажут значительного влияния на бизнес.

Невозможность обновления ПО для внутренних систем

Поддерживать актуальность ПО важно. Но это не относится к срочным рискам, если сейчас системы работают стабильно.

Итоги

Архитектура информационной безопасности — это комплекс мер и решений, который определяет стратегию, технологии и процессы для защиты информационных активов организации. В архитектуру ИБ входят механизмы контроля доступа, системы мониторинга и управления угрозами, меры по защите данных, меры для соблюдения нормативных требований.
Разработка проекта архитектуры информационной безопасности состоит из четырёх этапов: определения и приоритизации угроз, определения пороговых значений рисков, формирования мер безопасности (roadmap) и постоянного мониторинга для адаптации к изменениям. Пороговые значения рисков — это границы, которые показывают, какой уровень риска компания готова принять без существенного ущерба для своей деятельности. Их определяют при участии менеджмента компании.
Анализ рисков — это не разовое действие, а регулярный процесс. Он должен учитывать изменения в информационной системе, в бизнес-процессах, инфраструктуре и окружающей среде. Для этого очень важен качественный мониторинг.
Чтобы мониторинг учитывал все возможные проблемы и изменения, рекомендуем: внедрять систему мониторинга безопасности (SIEM), использовать сканеры уязвимостей, мониторить сетевую активность, контролировать изменения конфигураций, создавать систему оповещений и регулярно проводить анализ и формировать отчётность.

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