Основы кибербезопасности

Введение: активы, угрозы, уязвимости и риски

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

Зачем нужны базовые определения

В любой организации (и даже в личной жизни) защита строится вокруг одних и тех же вопросов:

Что для нас ценно?

Что может пойти не так?

Где слабое место?

Насколько это опасно и что делать в первую очередь?

Эти вопросы помогают перейти от абстрактного «нужна безопасность» к управляемому процессу.

Активы

Актив — это всё, что имеет ценность и требует защиты.

Активами могут быть не только «компьютеры и файлы», но и любые ресурсы, влияющие на работу и репутацию.

Виды активов

Данные: персональные данные, коммерческая тайна, исходный код, финансовые отчёты.

Системы и сервисы: сайт, CRM, почта, облачные хранилища, API.

Инфраструктура: ноутбуки, серверы, сеть, Wi‑Fi, маршрутизаторы.

Учетные записи и секреты: пароли, ключи API, токены доступа, сертификаты.

Люди и процессы: сотрудники, подрядчики, процедуры согласования платежей.

Репутация и доверие: публичный имидж, отношения с клиентами и партнёрами.

Свойства информации: конфиденциальность, целостность, доступность

При защите информации чаще всего используют модель CIA:

Конфиденциальность: доступ только у тех, кому положено.

Целостность: данные не изменены несанкционированно и не испорчены.

Доступность: сервис/данные доступны тогда, когда нужны.

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

Угрозы

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

Угрозы бывают:

Преднамеренные: злоумышленник взламывает, крадёт, шифрует.

Случайные: сотрудник ошибся, удалил, отправил не туда.

Технические: сбой диска, ошибка обновления, отказ сервиса.

Природные и внешние: пожар, затопление, отключение электричества.

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

Уязвимости

Уязвимость — это слабое место, которое может быть использовано угрозой.

Уязвимости встречаются на разных уровнях:

Технические: неустановленные обновления, слабые настройки, открытые порты.

Процессные: отсутствие двухфакторной аутентификации, нет резервного копирования.

Человеческие: доверчивость, усталость, недостаток обучения.

Уязвимость сама по себе не наносит ущерб — она создаёт возможность.

Как связаны активы, угрозы и уязвимости

Риск появляется только тогда, когда одновременно есть:

актив, который нам важен;

угроза, которая может проявиться;

уязвимость, через которую угроза может сработать.

!Инфографика показывает причинно-следственную цепочку от ценного актива к риску через угрозу и уязвимость.

Пример цепочки

Представим интернет-магазин:

Актив: база клиентов и заказов.

Угроза: фишинговая атака на сотрудника.

Уязвимость: однофакторный вход в админку и отсутствие обучения.

Результат: злоумышленник получает доступ.

Риск: утечка данных, финансовые потери, репутационный ущерб.

Риски

Риск — это вероятность того, что угроза реализуется через уязвимость и нанесёт ущерб активу.

Риск удобно рассматривать как сочетание двух факторов:

насколько вероятно, что событие произойдёт;

насколько большой будет ущерб, если оно произойдёт.

Иногда это записывают формулой:

Где:

— риск (условная величина для сравнения рисков между собой);

— вероятность (насколько часто или насколько реально это может случиться);

— влияние/ущерб (финансовый, юридический, операционный, репутационный).

Эта формула не «вычисляет безопасность» в абсолютных единицах, но помогает ранжировать проблемы: что исправлять сначала.

Матрица рисков (качественная оценка)

На практике часто используют простую шкалу низкий/средний/высокий.

| Вероятность \ Влияние | Низкое | Среднее | Высокое | |---|---|---|---| | Низкая | Низкий риск | Низкий/средний | Средний | | Средняя | Низкий/средний | Средний | Высокий | | Высокая | Средний | Высокий | Критический |

Эта таблица помогает договориться о приоритетах между ИТ, безопасностью и бизнесом.

Контрмеры и управление рисками

Когда риск понятен, дальше выбирают стратегию обращения с ним:

Снижение: закрыть уязвимость или уменьшить вероятность (2FA, обновления, сегментация, обучение).

Избежание: отказаться от рискованного решения (например, не хранить лишние персональные данные).

Передача: частично переложить последствия (страхование, договорные обязательства подрядчика).

Принятие: осознанно оставить как есть (если ущерб мал или исправление дороже).

Важно: безопасность — это не «убрать все риски», а управлять ими в разумных пределах.

Мини-каталог типовых примеров

| Актив | Угроза | Уязвимость | Возможный ущерб | |---|---|---|---| | Почта сотрудника | Фишинг | Нет 2FA, нет обучения | Компрометация переписки, вход в другие сервисы | | Веб‑сайт | Взлом через уязвимость приложения | Устаревшие библиотеки | Дефейс, утечка данных, простой сервиса | | Финансовые платежи | Подмена реквизитов | Нет второго согласования | Прямая потеря денег | | Файлы компании | Шифровальщик | Нет резервных копий | Потеря данных, длительный простой |

На что опираться дальше

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

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

NIST SP 800-30 Rev.1: Guide for Conducting Risk Assessments

OWASP Top 10 (проект о наиболее критичных рисках веб-приложений)

Криптография и защита данных

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

Важно: криптография не «делает систему безопасной сама по себе». Она работает только как часть процесса: правильные алгоритмы, корректная настройка, управление ключами, обновления и контроль доступа.

Какие задачи решает криптография

Криптография помогает обеспечить свойства, близкие к модели CIA из прошлой статьи:

Конфиденциальность: чтобы данные не мог прочитать посторонний.

Целостность: чтобы нельзя было незаметно изменить данные.

Подлинность: чтобы можно было проверить, кто отправил сообщение/файл.

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

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

Шифрование: что это и где применяется

Шифрование — преобразование данных в вид, непонятный без секретного значения (ключа). Бывает два основных сценария:

Шифрование при передаче (data in transit): защищает данные в сети от перехвата и подмены (пример: HTTPS/TLS).

Шифрование при хранении (data at rest): защищает данные на диске/в облаке/в бэкапах, если носитель украдут или получат к нему доступ.

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

Симметричное и асимметричное шифрование

Симметричное шифрование

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

Плюсы:

- очень быстро, подходит для больших объёмов данных.

Минусы:

- нужно безопасно передать ключ второй стороне.

Пример применения: шифрование диска, шифрование базы данных, шифрование файлов/архивов.

Асимметричное шифрование

Асимметричное шифрование использует пару ключей:

публичный ключ можно раздавать всем;

приватный ключ должен храниться в секрете.

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

Плюсы:

- проще организовать безопасный обмен без заранее общего секрета.

Минусы:

- медленнее, чем симметричное; большие данные напрямую шифровать неудобно.

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

!Наглядное сравнение двух подходов и их ключевой разницы

Хэш-функции: проверка целостности и хранение паролей

Хэш-функция преобразует данные произвольной длины в строку фиксированной длины (хэш). Важные свойства криптографической хэш-функции:

сложно восстановить исходные данные по хэшу;

сложно подобрать другие данные с тем же хэшем;

малое изменение входа сильно меняет хэш.

Проверка целостности

Если у вас есть файл и его ожидаемый хэш, то вы можете пересчитать хэш и сравнить:

совпало — с большой вероятностью файл не меняли;

не совпало — файл изменён или повреждён.

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

Пароли нельзя хранить «как есть»

Пароль в базе данных нельзя хранить в открытом виде и нельзя хранить как «быстрый хэш» (например, просто SHA-256(password)). Вместо этого применяют специальные медленные алгоритмы хэширования паролей, которые сильно усложняют перебор.

Практическая норма:

хранить только хэши паролей;

использовать соль (случайную добавку для каждого пароля), чтобы одинаковые пароли не имели одинаковых хэшей;

использовать алгоритмы для паролей, например Argon2, bcrypt, scrypt.

Ориентир по практике можно посмотреть в руководстве: OWASP Password Storage Cheat Sheet.

MAC и HMAC: целостность и подлинность «с секретом»

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

MAC (message authentication code) — это код аутентичности сообщения: результат функции от сообщения и секретного ключа. Частый вариант — HMAC (строится на хэш-функции).

Что даёт HMAC:

если злоумышленник не знает ключ, он не сможет подделать корректный HMAC;

получатель, зная ключ, проверит и целостность, и подлинность.

Типовые применения:

подпись запросов к API «по секрету»;

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

Цифровая подпись: подлинность без общего секрета

Цифровая подпись использует асимметричную криптографию:

отправитель подписывает данные приватным ключом;

любой может проверить подпись по публичному ключу.

Подпись решает задачи:

подтверждает, что данные подписал владелец приватного ключа;

показывает, что данные не менялись после подписи.

Цифровые подписи применяются в:

подписи обновлений и установочных пакетов;

электронном документообороте;

протоколах защищённого соединения (аутентификация сервера).

Сертификаты и PKI: как понять, что публичный ключ «настоящий»

Проблема асимметрии проста: публичный ключ можно подменить. Тогда вы «проверите подпись» злоумышленника или зашифруете данные не тому.

Сертификат связывает публичный ключ с конкретным именем (например, доменом) и подписывается доверенным центром сертификации.

Упрощённая модель доверия в интернете:

браузеры и ОС содержат список доверенных центров сертификации;

центр сертификации выпускает сертификат для сайта;

браузер проверяет цепочку доверия и срок действия.

Практический пример: бесплатный центр сертификации Let’s Encrypt.

TLS и HTTPS: защита данных при передаче

Когда вы открываете сайт по HTTPS, обычно используется протокол TLS, который обеспечивает:

шифрование трафика (конфиденциальность);

контроль целостности;

аутентификацию сервера по сертификату.

В реальности TLS — сложный протокол, но полезно помнить логику:

браузер проверяет сертификат;

стороны договариваются о криптографических параметрах;

создаётся общий сеансовый ключ;

дальше данные шифруются и защищаются от подмены.

Техническая спецификация: RFC 8446 (TLS 1.3).

!Понимание, почему HTTPS шифрует и как появляется общий ключ

Управление ключами: самая частая причина провала

Во многих инцидентах «сломали не алгоритм, а процесс». Типовые ошибки:

ключи хранятся в коде или в репозитории;

один ключ используется годами и не ротируется;

ключи доступны слишком многим людям и сервисам;

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

Практические принципы управления ключами:

минимизация доступа: ключи доступны только тем компонентам, которым необходимо;

разделение сред: разные ключи для разработки, теста и продакшена;

ротация: плановая замена ключей и возможность экстренной замены;

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

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

Хороший ориентир по подходам: NIST SP 800-57 Part 1 (Key Management).

Как выбирать криптографические решения безопасно

В прикладной безопасности действует полезное правило:

> «Не пытайтесь изобретать собственную криптографию».

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

> "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break." (Schneier on Security)

Практические рекомендации:

используйте современные протоколы и библиотеки, а не самописные схемы;

включайте шифрование «по умолчанию» там, где есть чувствительные данные;

отключайте устаревшие протоколы и слабые наборы шифров (это обычно задача администрирования);

проверяйте настройки по руководствам (например, для веба): OWASP Transport Layer Protection Cheat Sheet.

Связь с рисками: короткие сценарии

Ниже — как криптография «встраивается» в цепочку активы → угрозы → уязвимости → риск.

| Актив | Угроза | Уязвимость | Криптографическая мера | Что снижается | |---|---|---|---|---| | Учетные записи пользователей | Утечка базы | Пароли в открытом виде или быстрые хэши | Argon2/bcrypt + соль | Ущерб от утечки (сложнее взломать пароли) | | Данные клиентов при передаче | Перехват в сети | HTTP без TLS | HTTPS/TLS + корректные сертификаты | Вероятность чтения/подмены | | Резервные копии | Кража/утечка | Бэкапы без шифрования | Шифрование бэкапов, контроль ключей | Ущерб от компрометации | | Обновления ПО | Подмена дистрибутива | Нет проверки подписи | Цифровая подпись пакетов | Вероятность внедрения вредоносного ПО |

Главное, что стоит запомнить

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

Хэш-функции помогают с целостностью и правильным хранением паролей, но «просто хэш» для паролей недостаточен.

HMAC даёт целостность и подлинность при общем секрете, цифровая подпись — подлинность без общего секрета.

Сертификаты и PKI позволяют понять, что публичный ключ действительно принадлежит нужной стороне.

В реальных рисках чаще ломается не «математика», а настройки и процессы.

Сетевая безопасность и архитектура защиты

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

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

Что именно защищают в сети

В контексте сети активами обычно становятся:

Данные в передаче: логины, токены, API-ключи, персональные данные, коммерческая информация.

Доступ к системам: админки, базы данных, панели управления облаком.

Доступность сервисов: сайт, API, VPN, корпоративные коммуникации.

Сама инфраструктура сети: маршрутизаторы, коммутаторы, Wi‑Fi, DNS, прокси.

Типовые сетевые угрозы:

Перехват и подмена трафика: в публичных Wi‑Fi, при компрометации маршрутизации, при ошибках TLS.

Несанкционированный доступ: сканирование портов, эксплуатация открытых сервисов, подбор паролей.

Боковое перемещение внутри сети: злоумышленник попал на один хост и пытается добраться до серверов/AD.

Вредоносный трафик: C2-каналы, эксфильтрация данных.

Отказ в обслуживании: перегрузка канала/сервисов, DDoS.

Сетевая безопасность отвечает на два главных вопроса:

Кто и откуда может обращаться к конкретному сервису?

Как мы обнаружим, что в сети происходит что-то подозрительное?

Базовая идея архитектуры защиты: зоны и минимизация доверия

Практически любая зрелая архитектура опирается на принципы:

Сегментация: разделить сеть на зоны и контролировать трафик между ними.

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

Глубина защиты (defense in depth): несколько независимых уровней контроля.

Наблюдаемость: логи и мониторинг, чтобы видеть атаки и ошибки.

!Пример зональной архитектуры и контролируемых потоков трафика

Зоны (сегменты) сети

Набор зон зависит от организации, но часто встречается:

Периметр/интернет-граница: место, где сеть организации соединяется с интернетом.

DMZ: зона для публичных сервисов (сайт, reverse proxy), максимально изолированная от внутренней сети.

Внутренняя пользовательская сеть: рабочие места.

Серверная зона: базы данных, внутренние API, файловые сервисы.

Зона администрирования: доступ к управляющим интерфейсам (SSH/RDP/консоли), обычно с усиленным контролем.

Гостевая сеть: Wi‑Fi для посетителей без доступа к внутренним ресурсам.

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

Контроль трафика: правила, фильтрация и проксирование

Межсетевой экран (firewall)

Межсетевой экран фильтрует сетевой трафик по правилам: источник, назначение, порт, протокол, направление, иногда — состояние соединения.

Полезные практики настройки:

Правило по умолчанию: запретить всё, что не разрешено явно.

Минимальные разрешения: открывать только нужные порты и только между нужными сегментами.

Документирование: у каждого правила должен быть владелец и цель.

Регулярная ревизия: удаление временных и устаревших правил.

Технический ориентир: NIST SP 800-41 Rev.1 (Guidelines on Firewalls and Firewall Policy).

ACL и сетевые политики

ACL (access control list) — списки контроля доступа на сетевых устройствах (маршрутизаторы/коммутаторы), которые ограничивают прохождение трафика. По смыслу это близко к firewall, но часто применяется «ближе к сети» для упрощения сегментации.

Важно не путать:

ACL и firewall решают задачу доступа на уровне сети.

Авторизация пользователей и ролей — это задача уровня приложений и IAM.

NAT: полезно, но не «защита сама по себе»

NAT скрывает внутренние адреса и позволяет многим устройствам выходить в интернет через один внешний адрес. Это может уменьшать «видимость» внутренних хостов снаружи, но:

NAT не заменяет firewall и не является полноценным механизмом контроля доступа.

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

Справочный RFC по приватным адресам: RFC 1918 (Address Allocation for Private Internets).

Прокси и reverse proxy

Forward proxy часто используют для контроля и журналирования выхода пользователей в интернет.

Reverse proxy ставят перед веб-сервисами, чтобы централизовать TLS, маршрутизацию, лимиты запросов и иногда базовую фильтрацию.

WAF для веб-приложений

WAF (web application firewall) защищает веб-приложения на уровне HTTP(S): пытается блокировать типовые атаки (например, инъекции, подозрительные паттерны запросов). Он полезен как дополнительный слой, но:

не исправляет уязвимости приложения;

требует настройки и понимания легитимного трафика.

Обнаружение атак: IDS/IPS и мониторинг

Сетевые средства обнаружения помогают заметить то, что firewall не обязан понимать.

IDS (intrusion detection system) — обнаруживает подозрительную активность и сигнализирует.

IPS (intrusion prevention system) — может автоматически блокировать часть трафика.

Что обычно ищут:

сканирование портов и перебор;

аномальные объёмы исходящего трафика (возможная эксфильтрация);

обращения к известным вредоносным доменам;

необычные соединения между сегментами.

Логи и корреляция событий

Сетевая безопасность без журналирования быстро превращается в ситуацию: «что-то случилось, но мы не знаем что». Минимальный набор источников:

firewall (разрешённые/запрещённые соединения, NAT);

VPN (кто подключался, откуда, куда ходил);

DNS-логи (какие домены запрашивались);

прокси/reverse proxy/WAF (HTTP-логи);

журналы систем аутентификации.

Дальше события обычно собирают централизованно (например, в SIEM), чтобы искать цепочки активности.

Удалённый доступ: VPN и современный подход Zero Trust

VPN

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

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

отсутствие многофакторной аутентификации;

слишком широкие права: «подключился — и видишь всю внутреннюю сеть»;

отсутствие ограничений по устройствам и проверок состояния (компрометированный ноутбук становится «входной дверью»).

Zero Trust: доверие не по месту в сети

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

Zero Trust — подход, в котором:

сеть сама по себе не считается признаком доверия;

доступ выдаётся на основе проверенной личности, устройства и контекста;

доступ делается более гранулярным (часто до уровня конкретного приложения).

Хорошая отправная точка: NIST SP 800-207 (Zero Trust Architecture).

Практически это выражается в:

обязательной MFA;

проверках устройства (управляемое/обновлённое/с дисковым шифрованием);

микросегментации;

короткоживущих токенах доступа;

тщательном логировании и оценке рисков доступа.

Сегментация и микросегментация

Зачем сегментировать

Сегментация уменьшает «радиус поражения»:

рабочие станции не должны напрямую ходить к базе данных;

публичный веб-сервер не должен иметь полный доступ во внутреннюю сеть;

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

Микросегментация

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

Простой критерий полезности: если компрометация одного сервера позволяет легко «дотянуться» до остальных — сегментации недостаточно.

Wi‑Fi и безопасность локальной сети

Wi‑Fi часто становится коротким путём к внутренним ресурсам, поэтому базовые меры особенно важны:

отдельная гостевая сеть без доступа к внутренним сегментам;

современная защита (актуальные режимы WPA2/WPA3 в зависимости от возможностей);

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

мониторинг подключений и попыток аутентификации;

минимизация «плоской сети», где все устройства видят друг друга.

Ориентир по рекомендациям: NIST SP 800-153 (Guidelines for Securing Wireless Local Area Networks).

DNS как элемент безопасности

DNS — критичный сетевой сервис: через него пользователи и системы находят домены. Типовые риски:

подмена ответов (перенаправление на вредоносные ресурсы);

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

Меры:

логирование DNS-запросов и поиск аномалий;

фильтрация известного вредоносного доменного пространства;

использование DNSSEC там, где это уместно.

Базовая спецификация DNSSEC: RFC 4033 (DNS Security Introduction and Requirements).

Архитектура защиты как «набор слоёв»

Удобно мыслить сеть как систему взаимодополняющих слоёв:

Граница сети: firewall, анти-DDoS (по необходимости), политика входящих портов.

Публичные сервисы: DMZ, reverse proxy, WAF, строгие исходящие правила.

Внутренние сегменты: разделение пользователей/серверов/админов, запрет лишних соединений.

Удалённый доступ: VPN или Zero Trust-доступ к приложениям, MFA.

Наблюдаемость: логи, IDS/IPS/детектирование аномалий, реагирование.

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

Практический пример: как разложить защиту по цепочке риск-ориентированно

Рассмотрим сервис с личным кабинетом клиентов.

Актив: персональные данные и заказы.

Угроза: взлом веб-приложения и доступ к базе.

Уязвимость: база данных доступна из DMZ и из пользовательской сети без ограничений.

Контрмеры в архитектуре:

- сегментация: база данных только в серверной зоне; - правила firewall: доступ к БД только от конкретного приложения на конкретном порту; - WAF и reverse proxy перед веб-приложением; - мониторинг исходящего трафика и DNS-аномалий; - TLS для трафика пользователей.

Результат: снижается вероятность проникновения и уменьшается радиус поражения при компрометации веб-сервера.

Главное, что стоит запомнить

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

Firewall и ACL ограничивают, кто с кем может говорить, но не заменяют безопасность приложений.

IDS/IPS, логи и мониторинг нужны, чтобы обнаруживать атаки и разбирать инциденты.

VPN и Zero Trust решают задачу безопасного удалённого доступа, но требуют MFA и минимизации прав.

Любую меру полезно привязывать к цепочке актив → угроза → уязвимость → риск и выбирать приоритеты по рискам.

Безопасность операционных систем и конечных устройств

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

активы: данные на устройстве, учётные записи, доступ к корпоративным системам;

угрозы: вредоносное ПО, кража устройства, перехват сессий, компрометация через уязвимости;

уязвимости: непропатченная ОС, слабые настройки, лишние права, отсутствие шифрования диска;

риски: утечки, простой, шифрование файлов вымогателем, боковое перемещение по сети.

Сетевые меры из прошлой статьи (сегментация, VPN, Zero Trust) ограничивают «радиус поражения», а криптография (TLS, шифрование диска, защищённое хранение секретов) уменьшает ущерб. Но базовая гигиена ОС и устройств — это фундамент, без которого архитектура и криптография часто не спасают.

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

> "Security is a process, not a product." (Bruce Schneier — Schneier on Security)

Модель угроз для конечных устройств

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

Компрометация через пользователя

фишинг и ввод пароля на поддельном сайте;

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

установка нежелательного ПО или расширений браузера.

Компрометация через уязвимости

удалённые уязвимости в сетевых службах и клиентах;

локальные уязвимости (повышение привилегий);

уязвимости в драйверах и стороннем софте.

Потеря устройства или физический доступ

кража ноутбука/телефона;

доступ к диску или съёмным носителям;

подмена загрузки или загрузочного окружения.

Использование устройства как точки входа в сеть

кража токенов и сессий, доступ к почте и облаку;

боковое перемещение к серверам (если сеть «плоская»);

эксфильтрация данных наружу.

Базовая стратегия: «стандартизировать и управлять»

Безопасность ОС на практике почти всегда упирается в управляемость. Поэтому две опоры:

стандартизация: известные модели устройств, известные версии ОС, единые политики;

управление: централизованные обновления, настройки, контроль соответствия.

Для ориентиров по «базовым конфигурациям» часто используют:

CIS Benchmarks — набор практических требований к настройкам ОС и ПО;

NIST SP 800-123 — Guide to General Server Security — принципы усиления (hardening) и управления безопасностью серверов (многие идеи применимы и к рабочим станциям).

Обновления и управление уязвимостями

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

Почему патчи важнее «антивируса как волшебной кнопки»

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

патчи уменьшают вероятность компрометации без изменения пользовательского поведения;

патчи критичны не только для ОС, но и для браузера, офисных пакетов, PDF-ридеров, VPN-клиентов.

Практика патч-менеджмента

Определите инвентаризацию: какие устройства и версии ОС есть.

Задайте классы обновлений: критические безопасности, обычные, функциональные.

Используйте кольца развёртывания: пилотная группа, затем массовое обновление.

Контролируйте SLA на установку: например, критические патчи в течение N дней.

Измеряйте факт соответствия: кто не обновился и почему.

Ориентир по организации процесса: NIST SP 800-40 Rev. 3 — Guide to Enterprise Patch Management Planning.

Учётные записи, привилегии и контроль доступа на устройстве

Даже идеально пропатченная ОС не спасает, если злоумышленник получает права администратора.

Принцип наименьших привилегий

пользователи работают без локального администратора;

админские операции выполняются отдельной учётной записью;

права выдаются на минимальный срок и для конкретной задачи.

Почему это снижает риск

вредоносному ПО сложнее закрепиться и отключить защиту;

уменьшается вероятность «тихой» установки драйверов/служб/перехватчиков;

снижается ущерб от ошибки пользователя.

MFA и защита входа

MFA относится к «идентичности», но напрямую защищает конечные устройства и их доступы:

снижает риск компрометации облачной почты и корпоративных порталов при утечке пароля;

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

Важно помнить связь с криптографией из прошлой статьи: MFA часто опирается на криптографические протоколы и токены, а значит критичны правильные настройки и управление.

Усиление (hardening) ОС: уменьшение площади атаки

Hardening — это настройка системы так, чтобы атаковать было «меньше чего».

Отключение лишнего

удаление ненужного ПО и компонентов;

отключение неиспользуемых сетевых сервисов;

запрет автозапуска с внешних носителей (где это уместно).

Локальный файрвол и правила

Даже при наличии сетевого firewall локальный файрвол полезен, потому что:

защищает устройство в «чужих» сетях (дом, кафе, гостиница);

ограничивает неожиданные входящие соединения;

поддерживает микросегментацию на уровне хоста.

Контроль приложений

Практика, которая сильно уменьшает риск заражений:

разрешать запуск только доверенного ПО (allowlisting), где это возможно;

ограничивать запуск из временных папок и профиля пользователя;

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

Защита данных на устройстве

Здесь криптография становится «прикладной».

Шифрование диска

Шифрование диска защищает данные при хранении и особенно полезно против:

кражи ноутбука;

изъятия/потери диска;

несанкционированного доступа при физическом контакте.

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

Защита секретов

Критичные данные на конечных устройствах:

токены доступа (почта, облако, VPN);

ключи разработчика (SSH, API-ключи);

пароли в браузере и менеджерах.

Практика:

использовать менеджер паролей и MFA;

не хранить секреты в файлах на рабочем столе и в чатах;

разделять рабочие и личные учётные записи.

Резервные копии

Для конечных устройств бэкап — это защита в первую очередь от:

шифровальщиков;

случайного удаления;

аппаратных поломок.

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

Антивирус, EDR и телеметрия: обнаружение и реагирование

Технические средства защиты на устройстве можно представить как две линии:

предотвращение: блокировка известного вредоносного ПО, подозрительных действий;

обнаружение и расследование: события, поведение, цепочки процессов, сетевые соединения.

EDR (Endpoint Detection and Response) обычно сильнее «классического антивируса», потому что ориентирован на поведение и помогает отвечать на вопросы расследования: что запускалось, что изменялось, куда подключалось.

Полезный контекст для понимания типовых техник атак на конечных устройствах: MITRE ATT&CK.

Мобильные устройства и удалённая работа

Телефон часто даёт доступ к самым ценным активам: почта, мессенджеры, MFA, облако.

Базовые меры для мобильных

блокировка экрана и биометрия/пин;

шифрование хранилища (обычно включено по умолчанию в современных ОС);

возможность удалённого стирания при утере;

запрет установки приложений из сомнительных источников (насколько это применимо к платформе и политике организации).

Удалённый доступ

Связь с прошлой статьёй про сеть:

VPN или Zero Trust-доступ должен быть с MFA;

не стоит давать «видимость всей сети» при подключении;

желательно проверять состояние устройства (обновления, шифрование, наличие защиты) перед выдачей доступа.

Логи на конечных устройствах: чтобы понимать, что произошло

Без логов безопасность превращается в догадки. Минимальная логика:

фиксировать события входа и повышения привилегий;

фиксировать установку ПО и изменения настроек безопасности;

собирать события в централизованное хранилище (чтобы их нельзя было легко стереть локально).

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

Практическая связка «угроза → уязвимость → мера» для ОС и устройств

| Угроза | Типовая уязвимость | Мера на устройстве | Что снижается | |---|---|---|---| | Вымогатель (шифрование файлов) | Нет бэкапов, пользователь — локальный админ | Резервные копии, наименьшие привилегии, EDR | Ущерб и вероятность успешного закрепления | | Кража ноутбука | Диск без шифрования, слабая блокировка экрана | Полное шифрование диска, сильная аутентификация | Ущерб от физической потери | | Кража пароля через фишинг | Только пароль, нет MFA | MFA, защита входа, обучение | Вероятность захвата аккаунтов | | Эксплуатация уязвимости | Неустановленные обновления | Патч-менеджмент ОС и приложений | Вероятность компрометации | | Боковое перемещение в сети | Устройство «видит» всё, нет локальных ограничений | Локальный файрвол, минимальные права, сегментация сети | Радиус поражения |

Главное, что стоит запомнить

Конечные устройства и ОС — ключевая точка риска: через них чаще всего начинается атака.

Самые эффективные основы: обновления, минимальные привилегии, шифрование диска, MFA, контроль приложений.

Средства защиты (антивирус/EDR) важны, но они не заменяют патчи и правильные права.

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

Безопасная разработка и безопасность веб-приложений

Веб-приложения часто становятся самым «видимым» и атакуемым компонентом ИТ: они доступны из интернета, обрабатывают пользовательский ввод, работают с данными клиентов и интегрируются с платежами, почтой, облаками и внутренними API. Поэтому безопасность веб-приложений — это не только про «защитить сервер», а про весь путь: проектирование → код → зависимости → конфигурация → эксплуатация → мониторинг.

Связь с предыдущими темами курса:

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

Из криптографии используем TLS/HTTPS, безопасное хранение паролей, подписи, управление ключами и секретами.

Из сетевой безопасности используем сегментацию, DMZ, reverse proxy, WAF, ограничение сетевого доступа к БД и админкам.

Из безопасности ОС и устройств используем патчи, минимальные привилегии, контроль доступа админов и сбор логов.

Модель угроз для веб-приложений

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

Атакующий из интернета пытается найти уязвимость в публичных эндпоинтах (формы, API, загрузка файлов).

Атакующий с учётной записью (обычный пользователь) пытается получить доступ к чужим данным или админ-функциям.

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

Ошибки конфигурации: открытый бакет, отладочный режим, лишние права у сервисного аккаунта.

Внутренний злоумышленник или утечка секретов: токены, ключи, доступы к БД.

В терминах первой статьи это выглядит так:

Активы: персональные данные, платежи, сессии пользователей, админ-доступ, репутация.

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

Уязвимости: ошибки авторизации, инъекции, неправильная криптография, слабые настройки.

Риск: вероятность успешной атаки и масштаб ущерба.

!Поток запроса и места, где обычно ставят ключевые меры защиты

OWASP Top 10 как «карта» типовых рисков

Один из самых практичных ориентиров для веб-безопасности — OWASP Top 10, список наиболее критичных категорий рисков для веб-приложений.

Источник: OWASP Top 10.

Ниже — что обычно стоит за этими категориями и как мыслить о защите.

Ошибки контроля доступа

Суть: приложение «забывает» проверить, имеет ли пользователь право на действие или доступ к конкретному объекту.

Типовые примеры:

доступ к чужому заказу по изменению id в URL или в теле запроса;

возможность вызвать админ-метод без админ-прав;

отсутствие проверки прав на уровне серверной логики (проверили только в интерфейсе).

Базовые меры:

проверять авторизацию на сервере для каждого действия;

применять модель прав (роли, политики, ACL) и тестировать её;

не доверять данным из клиента (включая userId в запросах).

Инъекции

Суть: пользовательский ввод попадает в интерпретатор (SQL, NoSQL, LDAP, шаблоны, команды ОС) так, что меняет смысл запроса.

Базовые меры:

параметризованные запросы (prepared statements) и безопасные ORM-паттерны;

запрет «склейки строк» для запросов;

минимальные права у учетной записи БД.

Слабая идентификация и аутентификация

Суть: можно подобрать/украсть учётку, обойти вход или захватить сессию.

Базовые меры:

MFA для админов и чувствительных операций;

безопасное хранение паролей (Argon2/bcrypt + соль) из статьи про криптографию;

защита от перебора (rate limiting, блокировки, капча по риску);

корректные настройки cookies сессии (см. ниже).

Криптографические ошибки

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

Базовые меры:

TLS везде, где есть аутентификация или чувствительные данные;

шифрование чувствительных данных при хранении там, где это оправдано угрозами;

управление ключами и секретами (ротация, секрет-хранилища).

Ошибки проектирования и небезопасный дизайн

Суть: проблема не в «баге в коде», а в том, что сценарий изначально допускает злоупотребление.

Примеры:

перевод денег без второго фактора на «опасные» операции;

отсутствие ограничений на количество попыток или частоту запросов;

отсутствие понятной модели прав.

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

Ошибки конфигурации

Суть: небезопасные настройки платформы, фреймворка, облака, прокси.

Примеры:

включённый debug/stack traces в продакшене;

открытые админки в интернет;

слишком широкие CORS-настройки;

неверные security headers.

Уязвимые и устаревшие компоненты

Суть: зависимости и платформы содержат известные уязвимости.

Базовые меры:

инвентаризация зависимостей и регулярные обновления;

сканирование зависимостей в CI/CD;

политика жизненного цикла (что поддерживаем, что обновляем, что выводим из эксплуатации).

Недостаточное логирование и мониторинг

Суть: атака происходит, но её не видно, либо невозможно расследовать.

Базовые меры:

логирование аутентификации, ошибок авторизации, критичных действий;

алерты на аномалии (перебор, всплеск ошибок, странные IP/география);

централизованный сбор логов.

SSRF и доступ к внутренним ресурсам

SSRF — сценарий, когда приложение по команде атакующего делает запрос «куда-то от своего имени» (например, во внутреннюю сеть или в метаданные облака).

Базовые меры:

строгие allowlist-списки разрешённых доменов/адресов для исходящих запросов;

запрет доступа приложения к чувствительным внутренним адресам на сетевом уровне;

таймауты, ограничения редиректов.

Ключевые принципы безопасной разработки

Не доверять входным данным

Любые данные, которые пришли извне (пользователь, партнёрский API, файл, вебхук), считаются недоверенными.

Практика:

валидация формата и ограничений (тип, длина, диапазон);

нормализация данных перед проверками (например, привести регистр или формат);

отказ по умолчанию, если формат не соответствует ожиданиям.

Разделять аутентификацию, авторизацию и учёт контекста

Три частые ошибки:

путать вход в систему с правом на действие;

проверять права только на уровне интерфейса;

не учитывать контекст (устройство, риск операции, чувствительность ресурса).

Минимальная логика:

аутентификация отвечает на вопрос: кто ты?

авторизация отвечает на вопрос: что тебе можно?

контекст отвечает на вопрос: можно ли это сейчас и таким способом? (например, MFA на перевод денег).

Наименьшие привилегии в коде и инфраструктуре

Применение принципа наименьших привилегий в вебе:

сервисный аккаунт БД не должен иметь права удалять таблицы, если приложению это не нужно;

фоновые задачи должны иметь отдельные ключи доступа и отдельные роли;

админ-функции должны быть отделены и защищены сильнее.

Это дополняет сетевую сегментацию из статьи про сеть: даже если приложение в DMZ скомпрометировали, доступ к БД должен быть минимальным и строго ограниченным.

Аутентификация и управление сессией

Пароли, хэши и MFA

Ключевые правила из криптографии:

пароли хранятся только в виде хэша для паролей (Argon2/bcrypt/scrypt) с солью;

MFA снижает риск компрометации при утечке пароля или фишинге;

нельзя «логировать пароли» и нельзя отправлять их по почте.

Ориентир: OWASP Password Storage Cheat Sheet.

Сессионные cookies

Если приложение использует cookies для сессии, важны настройки:

HttpOnly: уменьшает риск кражи cookie через XSS;

Secure: cookie уходит только по HTTPS;

SameSite: снижает риск CSRF (в зависимости от режима и сценария);

ограниченный срок жизни и корректная инвалидация при выходе.

Ориентир: OWASP Session Management Cheat Sheet.

CSRF: когда возникает и как защищаться

CSRF возникает, когда:

браузер автоматически прикрепляет cookies к запросу;

приложение доверяет этому факту и выполняет опасное действие;

атакующий может заставить браузер жертвы отправить запрос.

Типовые меры:

CSRF-токены для опасных операций;

SameSite-настройки cookies;

проверка Origin/Referer там, где это уместно.

Ориентир: OWASP CSRF Prevention Cheat Sheet.

Авторизация и контроль доступа к данным

Проверка прав на каждый объект

Классическая уязвимость IDOR выглядит так: пользователь меняет orderId и получает чужой заказ.

Практика:

авторизация должна учитывать владельца и контекст объекта;

идентификаторы объектов не должны быть единственным «барьером»;

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

Разделение ролей и усиление админ-доступа

Админ-доступ в вебе — один из самых критичных активов. Базовые меры:

отдельные админ-учётки, MFA обязательно;

ограничения по IP или доступ через VPN/Zero Trust (из сетевой темы);

отдельный аудит логов админ-действий.

Валидация ввода, вывод и XSS

XSS: почему опасно

XSS позволяет внедрить скрипт в страницу и выполнить его в браузере жертвы. Последствия:

кража сессии (если cookie не защищены);

подмена формы оплаты или реквизитов;

действия от имени пользователя.

Базовые меры:

экранирование вывода по контексту (HTML, атрибут, URL, JavaScript);

запрет небезопасных вставок HTML там, где это не нужно;

Content Security Policy как дополнительный слой.

Ориентир: OWASP XSS Prevention Cheat Sheet.

Безопасность API

Веб-приложение всё чаще состоит из API (REST/GraphQL) и фронтенда. Типовые риски:

отсутствие авторизации на методах;

утечки через слишком подробные ответы;

массовые операции без ограничений;

отсутствие rate limiting.

Базовые меры:

единый слой авторизации (middleware, политики доступа);

ограничение частоты запросов и защита от перебора;

схемы и валидация данных (ожидаемые поля, типы, размеры);

минимизация данных в ответах (не отдавать лишнее).

Зависимости, сборка и цепочка поставок

Современное приложение обычно зависит от десятков и сотен библиотек. Риск появляется, когда:

библиотека содержит известную уязвимость;

пакет подменён;

сборка не воспроизводима и не контролируется.

Практики:

обновления и политика поддержки версий;

сканирование зависимостей в CI;

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

подпись артефактов сборки там, где это применимо.

Секреты и конфигурация

Здесь напрямую применяется тема управления ключами из криптографии.

Антипаттерны:

ключи API и пароли БД в репозитории;

секреты в клиентском коде (в браузере их нельзя скрыть);

один и тот же ключ для dev и prod.

Практика:

секрет-хранилище или защищённые переменные окружения в CI/CD;

раздельные секреты для сред и сервисов;

ротация и быстрый отзыв;

минимальные права у токенов.

Логирование, мониторинг и реакция

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

Минимальный набор событий:

успешные и неуспешные входы, смена пароля, выдача токенов;

ошибки авторизации и попытки доступа к чужим объектам;

админ-действия;

аномалии: множество запросов, всплеск 4xx/5xx, необычные источники.

Важно: логи не должны содержать секреты (пароли, токены, приватные ключи) и должны быть защищены от изменения.

Процесс: как встроить безопасность в SDLC

Безопасная разработка работает лучше всего как процесс, а не как разовая проверка.

> "Security is a process, not a product." (Bruce Schneier — The Process of Security)

Практическая схема внедрения:

На этапе требований определить активы и риски: какие данные, какие операции критичны.

На этапе дизайна сделать краткую модель угроз и определить контрольные меры.

Во время разработки использовать код-ревью, линтеры, безопасные библиотеки и чеклисты.

В CI/CD добавить проверки: SAST, сканирование зависимостей, базовые DAST-проверки.

Перед релизом провести тестирование безопасности по критичным сценариям.

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

!Как безопасность распределяется по этапам жизненного цикла разработки

Ориентиры по практикам:

требования и проверки уровня приложения: OWASP ASVS

набор прикладных рекомендаций: OWASP Cheat Sheet Series

инженерные практики на уровне организации: NIST SP 800-218 (Secure Software Development Framework)

Главное, что стоит запомнить

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

HTTPS и криптография важны, но не заменяют авторизацию, валидацию и правильный дизайн.

Сетевые меры уменьшают радиус поражения, но уязвимость в приложении всё равно может привести к утечке, если доступы и права настроены широко.

Самый устойчивый подход — встроить безопасность в SDLC: от требований и дизайна до мониторинга и исправлений.

Мониторинг, обнаружение атак и реагирование на инциденты

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

мониторинг: сбор сигналов о том, что происходит;

обнаружение атак: превращение сигналов в понятные события и алерты;

реагирование на инциденты: быстрые и повторяемые действия, уменьшающие ущерб.

Связь с предыдущими статьями курса:

из темы про риски берём приоритизацию: мониторим прежде всего то, что снижает критические риски;

из криптографии берём идею доверия и целостности: логи должны быть защищены от подмены, а доступы к ним строго контролируются;

из сетевой безопасности берём источники телеметрии (firewall, DNS, прокси, VPN) и ограничения радиуса поражения;

из безопасности ОС и устройств берём логи эндпоинтов, EDR и контроль привилегий;

из безопасной разработки берём события приложения (аутентификация, авторизация, действия с данными) и требования к логированию.

Зачем нужен мониторинг

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

увидеть событие раньше, чем оно станет катастрофой;

сократить время, которое атакующий находится в системе незаметно;

понять масштаб: что затронуто, какие системы, какие данные;

восстановить причину и закрыть первичный путь атаки.

Практически мониторинг отвечает на два вопроса:

что у нас происходит прямо сейчас?

если что-то пошло не так — сможем ли мы это доказать и восстановить картину событий?

Что такое телеметрия и откуда берутся данные

Телеметрия — это технические сигналы о работе систем: логи, события, сетевые потоки, результаты проверок, метрики.

Типовые источники (их полезно связывать с архитектурой из сетевой темы):

сеть: firewall, IDS/IPS, VPN, прокси, DNS, WAF, балансировщики, reverse proxy;

серверы и ОС: системные события, аудит входов, журналы служб, события повышения привилегий;

конечные устройства: EDR/антивирус, события запуска процессов, изменения в реестре, подключения к сети;

приложения и API: входы, ошибки авторизации, операции с данными, изменения настроек, админ-действия;

облако: аудит действий (кто создал ключ, изменил IAM, открыл бакет), журналы доступа к объектам хранения.

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

Логирование как фундамент

Лог — это запись о событии: что произошло, когда, где и кем. Если логи неполные или им нельзя доверять, расследование превращается в предположения.

Руководство по организации лог-менеджмента: NIST SP 800-92 Guide to Computer Security Log Management.

Что важно логировать в первую очередь

Ниже — практический минимум, который почти всегда окупается.

аутентификация: успешные и неуспешные входы, MFA-события, сбросы пароля;

авторизация: отказ в доступе, попытки доступа к «чужим» объектам;

привилегированные действия: выдача ролей, вход админов, выполнение админ-команд;

изменения конфигурации: настройки сети, ACL, правила firewall, секреты, политики доступа;

операции с данными: экспорт, массовые выгрузки, скачивание больших объёмов, удаление;

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

Рекомендации по логированию для веба: OWASP Logging Cheat Sheet.

Как сделать логи пригодными для расследований

Практические требования к качеству логов:

единое время: синхронизация времени (иначе события невозможно выстроить в цепочку);

контекст: идентификатор пользователя, IP, user-agent, идентификатор запроса, идентификатор объекта;

структура: по возможности структурированные логи (например, JSON), чтобы искать и коррелировать;

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

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

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

От мониторинга к обнаружению: что такое детектирование

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

Подходы к детектированию обычно комбинируют.

сигнатурное: известные паттерны атак и вредоносного ПО;

поведенческое: подозрительные цепочки действий (например, запуск powershell с загрузкой из интернета);

аномальное: отклонения от нормального поведения (например, необычная география входов);

корреляционное: связывание событий из разных источников (например, фишинг → вход в почту → создание правила пересылки → выгрузка данных).

Полезный «словарь» тактик и техник атак: MITRE ATT&CK.

Ложные срабатывания и качество алертов

Плохой мониторинг не тот, который «ничего не видит», а тот, который создаёт шум и приводит к игнорированию алертов.

Практика улучшения качества:

начинать с небольшого набора критичных детектов (по самым важным активам);

вводить пороги и контекст (например, алерт только при серии неудачных входов и затем успешном);

подтверждать алерты дополнительными источниками (сеть + endpoint + приложение);

регулярно пересматривать правила по фактам инцидентов.

SIEM и SOAR: как это обычно собирают в систему

Термины встречаются часто, поэтому важно их понимать.

SIEM собирает события, нормализует, хранит, ищет корреляции и поднимает алерты.

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

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

!Схема показывает путь от телеметрии до действий реагирования и последующего улучшения

Триаж алертов: как не утонуть в событиях

Триаж — быстрая оценка алерта: насколько это похоже на реальную атаку и что делать прямо сейчас.

Удобная минимальная последовательность:

Подтвердить факт: это точно происходило или это ошибка логирования.

Определить актив: какой сервис, какие данные, какой пользователь затронут.

Определить тип: попытка входа, вредоносное ПО, утечка, изменения прав.

Оценить срочность: есть ли признаки активного развития (движение по сети, выгрузка данных).

Принять действие: блокировка, изоляция, эскалация, сбор артефактов.

Чтобы триаж работал, нужны заранее описанные правила «что считается критичным». Например:

вход администратора без MFA;

массовая выгрузка данных клиентов;

создание новых ключей доступа в облаке;

отключение EDR или попытка остановить службы безопасности;

соединения с известной вредоносной инфраструктурой.

Реагирование на инциденты: процесс важнее героизма

Инцидент — это событие, которое нарушает конфиденциальность, целостность или доступность (CIA) активов, либо создаёт высокий риск такого нарушения.

Классическое руководство: NIST SP 800-61 Rev.2 Computer Security Incident Handling Guide.

Жизненный цикл реагирования

Обычно выделяют четыре фазы.

подготовка: роли, контакты, доступы, плейбуки, резервные копии, обученные люди;

обнаружение и анализ: триаж, подтверждение, сбор артефактов, определение масштаба;

сдерживание, устранение и восстановление: ограничить ущерб, убрать причину, вернуть сервис;

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

!Иллюстрация показывает, что реагирование — это циклический процесс улучшения

Плейбуки: заранее прописанные сценарии

Плейбук — это пошаговый план действий для типового инцидента. Он снижает риск ошибок в стрессовой ситуации.

Примеры плейбуков, которые обычно нужны почти всем:

компрометация учётной записи (фишинг);

заражение конечного устройства;

утечка ключа API или токена;

подозрение на утечку данных из веб-приложения;

DDoS или деградация доступности.

Плейбук должен отвечать на вопросы:

кто принимает решение о блокировке доступа;

какие системы нужно проверить;

какие артефакты собрать;

как уведомлять (внутренне и внешне);

как восстановить работу.

Практический сценарий: компрометация учётной записи

Ниже — пример, как связать мониторинг и реагирование с темами курса.

Как выглядит атака

актив: корпоративная почта и доступ к внутренним системам;

угроза: фишинг;

уязвимость: отсутствие MFA или слабые проверки входа;

события: неудачные попытки входа → успешный вход с нового устройства → создание правила пересылки → рассылка фишинга внутри компании.

Что детектировать

вход с новой географии или нового устройства;

серия неудачных входов, за которой следует успешный;

создание правил пересылки на внешний адрес;

массовая отправка писем или скачивание вложений.

Как реагировать

Заблокировать или временно приостановить учётную запись.

Сбросить пароль и отозвать активные сессии.

Проверить, включена ли MFA, включить и потребовать повторную привязку.

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

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

Закрыть первопричину: обучение, политика MFA, детекты на будущее.

Связь с предыдущими статьями:

это снижает риск через уменьшение времени атаки и быстрое сдерживание;

MFA и токены относятся к криптографии и управлению доступом;

логи входов и правила почты — это прикладной мониторинг.

Минимальный набор контроля для небольших команд

Не у всех есть SIEM, SOC и круглосуточная смена. Ниже — реалистичный минимум, который всё равно даёт эффект.

централизованный сбор логов ключевых систем (почта, VPN, облако, reverse proxy, серверы);

алерты на критичные события (админ-входы, изменения прав, массовые выгрузки, отключение защиты);

инвентаризация активов и понятные владельцы систем;

базовые плейбуки и контакты на случай инцидента;

регулярные учения «что делаем, если…» хотя бы раз в квартал.

Хороший ориентир по приоритизации практик: CIS Critical Security Controls v8.

Важные организационные моменты

Хранение и доступ к логам

Логи — это тоже актив: в них могут быть персональные данные и технические детали инфраструктуры.

Практики:

минимальный доступ по ролям;

отдельные админ-учётки;

контроль изменений (кто менял правила сбора, кто удалял данные);

понятные сроки хранения, привязанные к рискам и требованиям.

Коммуникации и фиксация решений

Во время инцидента часто происходит хаос: кто-то блокирует доступ, кто-то перезапускает сервис, кто-то удаляет «подозрительный файл» и теряет артефакты.

Полезные правила:

один ответственный координатор;

единый канал коммуникации;

фиксация таймлайна: что сделали, когда, почему;

аккуратность с артефактами: сначала собрать данные, затем «чинить».

Главное, что стоит запомнить

Мониторинг и реагирование уменьшают ущерб, потому что сокращают время атаки и ускоряют восстановление.

Качественные логи, их централизация и защита — фундамент детектирования и расследований.

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

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

Управление доступом, политики, соответствие и культура безопасности

Технические меры из предыдущих статей (криптография, сегментация сети, hardening ОС, безопасная разработка, мониторинг и реагирование) работают предсказуемо только тогда, когда в организации есть ответ на четыре вопроса:

Кто имеет доступ к системам и данным?

На каких условиях и зачем этот доступ выдан?

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

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

Эта статья связывает «технику» курса с управлением: управление доступом (IAM), политики, соответствие требованиям и культура безопасности. В терминах первой статьи курса это способы снижать риск не только через закрытие уязвимостей, но и через управление человеческим фактором и процессами.

Управление доступом как система

Управление доступом обычно рассматривают как часть IAM (Identity and Access Management): управление цифровыми идентичностями и их правами.

Полезная простая модель называется AAA:

Аутентификация: кто ты? (проверка личности: пароль, MFA, сертификат)

Авторизация: что тебе можно? (проверка прав на действие/ресурс)

Аудит (учёт действий): что ты делал и когда? (логи и трассировка действий)

Для доступа к ресурсу почти всегда должны выполняться два условия:

Где:

— доступ разрешён

— пользователь (или сервис) успешно прошёл аутентификацию

— у пользователя (или сервиса) есть права на конкретное действие

— логическое «И»

Смысл формулы практический: если вы отлично настроили вход (MFA), но слабо настроили права (например, всем выдали админ-доступ), риск остаётся высоким. И наоборот: идеальная модель ролей не спасёт, если учётные записи легко угоняются.

Идентичности: люди, сервисы и «невидимые пользователи»

В современных системах «пользователь» — не всегда человек.

Человеческие учётные записи: сотрудники, подрядчики, временные пользователи.

Сервисные учётные записи: приложения, фоновые задачи, интеграции.

Машинные идентичности: ключи API, токены, сертификаты, роли облачных сервисов.

Связь с предыдущими темами курса:

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

Сетевая архитектура (сегментация, Zero Trust) определяет откуда вообще можно попытаться обратиться к ресурсу.

Безопасная разработка должна корректно применять авторизацию в приложении (например, защищаться от IDOR).

Мониторинг и реагирование требуют аудита действий и событий доступа.

Основные принципы управления доступом

Наименьшие привилегии

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

Типовые практики:

запрет «всем администраторам всего»

минимальные права у сервисных аккаунтов

отдельные роли для чтения и изменения

выдача временных прав для задач администрирования

Разделение обязанностей

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

Примеры:

один сотрудник создаёт платёж, другой подтверждает

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

админ, выдающий доступы, не должен быть тем же человеком, кто утверждает эти доступы

Запрет общих учётных записей

Общие учётки вида admin/admin2 для команды разрушают аудит: невозможно доказать, кто именно совершал действия. Это напрямую бьёт по фазам расследования из статьи про реагирование на инциденты.

Если общий доступ неизбежен (редкий случай), нужны компенсирующие меры:

персональные учётки + повышенные права через отдельный механизм

запись сессий администрирования

строгая ротация секретов и контроль выдачи

Аутентификация: как сделать вход устойчивым

MFA как базовый стандарт

MFA (Multi-Factor Authentication) снижает риск компрометации учётных записей при фишинге и утечке паролей (связь со статьёй про конечные устройства и фишинг-сценарии в реагировании).

Практические приоритеты внедрения MFA:

обязательно для администраторов и доступа к почте/облаку

обязательно для VPN/Zero Trust-доступа

включать для чувствительных операций (экспорт данных, изменения реквизитов)

Рекомендации по цифровой идентичности: NIST SP 800-63B Digital Identity Guidelines: Authentication and Lifecycle Management.

SSO: удобство и риск концентрации

SSO (Single Sign-On) упрощает доступ: один вход — много приложений. Это повышает управляемость (легче отключать доступ при увольнении), но создаёт критичную точку:

компрометация SSO-аккаунта даёт доступ сразу ко многим системам

Поэтому для SSO особенно важны:

MFA

строгая политика условного доступа (контекст: устройство, география, риск)

высокий уровень логирования и алертов

Пароли как неизбежный минимум

Даже если вы внедрили MFA, пароли остаются частью системы. Базовые правила:

уникальные длинные пароли, лучше через менеджер паролей

запрет повторного использования корпоративных паролей в личных сервисах

защита от перебора (rate limiting) и мониторинг аномалий

Про безопасное хранение паролей в приложениях см. в статье про криптографию и веб-безопасность (Argon2/bcrypt + соль).

Авторизация: как моделировать права

Авторизация отвечает на вопрос: можно ли этому субъекту выполнить это действие над этим объектом в этом контексте?

RBAC, ABAC и «политики»

На практике часто используют три подхода.

| Подход | Идея | Плюсы | Типовые риски | |---|---|---|---| | RBAC (Role-Based Access Control) | Права через роли (бухгалтер, оператор, админ) | Понятно бизнесу, удобно для типовых задач | Роли разрастаются, появляются «суперроли» | | ABAC (Attribute-Based Access Control) | Решение по атрибутам (департамент, тип данных, среда, устройство) | Гибко, хорошо для Zero Trust и облака | Сложно проектировать и отлаживать | | Списки доступа (ACL) | Права «к объекту» (у файла/ресурса список, кто может) | Точно для конкретных объектов | Плохо масштабируется без процессов |

Связь с веб-безопасностью: RBAC/ABAC не спасут, если разработчики забыли проверку прав на сервере для конкретного объекта (класс IDOR).

Контекстный доступ и Zero Trust

Идея Zero Trust из сетевой статьи применима и к авторизации: доступ может зависеть не только от роли, но и от условий.

Примеры контекста:

запрос идёт с управляемого устройства с включённым шифрованием диска

вход подтверждён MFA

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

операция «опасная» и требует дополнительного подтверждения

Ориентир по архитектуре: NIST SP 800-207 Zero Trust Architecture.

Жизненный цикл доступа: выдача, изменение, отзыв

Самая частая реальная проблема — не в выборе RBAC/ABAC, а в том, что доступы выдаются и остаются навсегда.

Полезная модель жизненного цикла — Joiner–Mover–Leaver:

Joiner: сотрудник пришёл — какие доступы нужны?

Mover: роль изменилась — какие права добавить и какие убрать?

Leaver: сотрудник ушёл — как быстро и полностью отозвать доступ?

!Визуально показывает, что доступ — это процесс со стадиями и контрольными точками

Практические требования к процессу:

Владелец ресурса (система/данные) должен утверждать доступ.

Доступ должен выдаваться через управляемый механизм (IAM/каталог/ITSM), а не «вручную по чату».

Должны быть сроки, условия и причина выдачи.

Должен быть аудит: кто запросил, кто согласовал, кто выдал, когда.

Должен быть быстрый отзыв: увольнение, инцидент, утечка.

Периодические ревизии доступа

Даже при хорошем онбординге доступ со временем «обрастает». Поэтому применяют access review:

регулярный пересмотр прав (например, раз в квартал для критичных систем)

подтверждение прав владельцами ресурсов

удаление неиспользуемых и избыточных доступов

Эта практика особенно важна для:

админ-прав

доступа к персональным данным

ключей API и сервисных аккаунтов

Привилегированный доступ: отдельный режим

Админ-доступ — один из самых критичных активов (в терминах первой статьи курса). Для него обычно вводят усиленные меры:

отдельные админ-учётки

MFA обязательно

доступ только из защищённого сегмента или через bastion/jump host

запись и аудит админ-сессий

минимизация постоянных прав и переход к временным (JIT)

Практики управления привилегиями часто объединяют термином PAM (Privileged Access Management).

Политики: как превратить требования в работающие правила

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

Хорошая структура обычно выглядит как три уровня:

Политика: принципиальные требования (например, «все админ-доступы только с MFA»)

Стандарты: конкретизация (например, «MFA через FIDO2 или приложение-аутентификатор»)

Процедуры/инструкции: пошагово как сделать (например, «как подключить MFA в конкретной системе»)

!Поясняет, чем политика отличается от стандарта и процедуры

Примеры тем политик, которые почти всегда нужны:

политика паролей и MFA

политика управления доступом (заявки, согласование, сроки, отзыв)

политика классификации данных и обращения с ними

политика обновлений и управления уязвимостями

политика реагирования на инциденты и коммуникаций

Соответствие требованиям: что это и чего оно не гарантирует

Соответствие (compliance) — это выполнение внешних или внутренних требований: законов, стандартов, договоров.

Важно различать:

Безопасность — снижение реального риска.

Соответствие — доказуемое выполнение набора требований.

Обычно соответствие помогает безопасности (особенно дисциплиной и проверками), но не является гарантией.

Типовые источники требований

Законодательные требования к данным (в разных странах разные режимы).

Договорные требования клиентов и партнёров.

Отраслевые практики и стандарты.

Примеры широко используемых ориентиров:

ISO/IEC 27001 — требования к системе менеджмента ИБ (ISMS).

NIST Cybersecurity Framework (CSF) — рамка для построения программы кибербезопасности.

CIS Critical Security Controls v8 — практичный перечень приоритетных контролей.

Что обычно проверяют аудиторы

Проверки часто фокусируются на двух вещах:

Дизайн контролей: есть ли политика, процесс и назначенные ответственные.

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

Сильная связь с темой мониторинга: аудит и расследования невозможны без корректных логов и защищённой телеметрии.

Культура безопасности: почему «бумага» не работает без людей

Даже идеальные политики не работают, если:

их невозможно выполнить в реальной работе

люди не понимают, зачем они нужны

нарушение «дешевле», чем соблюдение

Культура безопасности — это устойчивое поведение людей и команд, которое снижает риски по умолчанию.

Признаки здоровой культуры

безопасность встроена в процессы (доступы через заявки, секреты через хранилище, релизы через CI/CD)

у людей есть понятные каналы помощи (куда писать при подозрении на фишинг, как запросить доступ)

ошибки не скрывают, а быстро сообщают (важно для раннего реагирования)

решения принимаются по риску, а не по привычке

Практики, которые реально работают

Обучение, привязанное к ролям

1. разработчикам — про секреты, зависимости, авторизацию 2. администраторам — про привилегии, журналы, MFA 3. всем сотрудникам — про фишинг, пароли, работу с данными

Короткие правила “как поступить”

1. что делать при подозрении на фишинг 2. как передавать файлы безопасно 3. как хранить и запрашивать доступы

Фрикция там, где она оправдана риском

1. MFA и подтверждения на опасные операции 2. запрет публичного доступа к данным по умолчанию

Регулярные упражнения

1. учения по инцидентам (связь с плейбуками) 2. симуляции фишинга с последующим разбором

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

Как связать всё в единую картину курса

Риск-ориентированный подход задаёт приоритеты: какие доступы и данные критичны.

Криптография защищает каналы и секреты, но требует управления ключами и токенами.

Сеть и Zero Trust ограничивают, откуда возможен доступ.

ОС и конечные устройства обеспечивают базовую гигиену (патчи, шифрование, EDR), чтобы идентичности не угонялись так легко.

Безопасная разработка гарантирует, что авторизация действительно проверяется в коде.

Мониторинг и реагирование превращают аудит доступа в способность быстро сдерживать инциденты.

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