Проект

Общее

Профиль

Действия
История

Wiki » ISM »

Протоколирование, аудит и криптография

Введение

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

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

Эта тема логически продолжает 9. Управление доступом и закрывает связку «предупреждение → обнаружение → доказательство». Криптографические механизмы, описанные здесь, лежат в основе протоколов TLS, SSH, ЭЦП и PKI, применяемых во всех современных системах.

Протоколирование событий

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

Категории событий

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

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

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

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

Что регистрировать

Не все события одинаково важны с точки зрения безопасности. Избыточное протоколирование перегружает хранилища и делает анализ практически невозможным; недостаточное — оставляет слепые зоны. Баланс определяется политикой протоколирования.

Обязательные к регистрации события для большинства систем:

Категория События
Аутентификация Успешный вход, неудачная попытка входа, выход, блокировка учётной записи, изменение пароля
Управление учётными записями Создание, изменение, удаление учётных записей; изменение прав и групп членства
Привилегированные операции Любые действия с правами администратора, использование sudo/runas, доступ к привилегированным учётным записям
Доступ к ресурсам Открытие, изменение, удаление конфиденциальных файлов; экспорт данных; доступ к защищённым базам данных
Изменения конфигурации Изменения политик безопасности, правил межсетевого экрана, параметров аутентификации
Сетевая активность Установленные и отклонённые соединения, DNS-запросы, использование VPN
Работа процессов Запуск и завершение критичных процессов, загрузка DLL, создание дочерних процессов

Обязательные поля записи журнала

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

  • Метка времени — дата, время, часовой пояс и желательно миллисекунды. Без синхронизированного времени (NTP) невозможно сопоставить события из разных систем.
  • Идентификатор субъекта — уникальный идентификатор пользователя или процесса, инициировавшего событие.
  • Тип события — стандартизированный код (например, Windows Event ID 4625 — неудачный вход).
  • Результат — успех или отказ.
  • Источник — IP-адрес, имя хоста, идентификатор терминала.
  • Объект воздействия — имя файла, ресурса, учётной записи.
  • Описание изменений — состояние до и после для событий модификации.

Защита журналов

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

Немедленная отправка на централизованный сервер — syslog или агент SIEM передаёт события в реальном времени. Даже если скомпрометированная машина будет уничтожена, события уже сохранены.

Неизменяемое хранилище — WORM носители или объектные хранилища с блокировкой удаления (S3 Object Lock).

Контроль целостности — периодическое хеширование журналов и хранение хешей отдельно. Любое изменение записи изменит хеш и будет обнаружено.

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

Требование к защите журналов напрямую вытекает из стандарта ISO 27001 (контроль 8.15 «Logging») и является обязательным для систем, обрабатывающих персональные данные (152-ФЗ).

Аудит: пассивный и активный

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

Пассивный аудит — периодический (ежедневный, еженедельный) анализ журналов вручную или с помощью инструментов. Позволяет обнаружить нарушения постфактум — иногда с существенной задержкой. Именно благодаря пассивному аудиту в 1986 году системный администратор Клиффорд Столл из Национальной лаборатории имени Лоуренса в Беркли обнаружил немецких хакеров, работавших на КГБ, — по расхождению в 75 центов в ежедневном финансовом отчёте вычислительного центра.

Активный аудит — мониторинг в реальном времени с автоматическим реагированием. Система непрерывно анализирует поток событий и при выявлении подозрительной активности немедленно реагирует: блокирует учётную запись, изолирует хост, создаёт инцидент в SIEM. Именно так работают современные SIEM и EDR.

Методы обнаружения подозрительной активности

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

Статистический метод (обнаружение аномалий) — построение профиля нормального поведения пользователя или системы и выявление отклонений. Пользователь всегда входит с 9 до 18 из московского офиса — вход в 3 часа ночи из Бангкока является аномалией. Преимущества: потенциально обнаруживает неизвестные атаки. Недостатки: высокий уровень ложных срабатываний; плохо работает, когда нормальное поведение само по себе непредсказуемо.

Корреляционный метод — объединение событий из разных источников в единую цепочку. Одиночные события безобидны по отдельности, но их последовательность раскрывает атаку. Пример: разведка (множество DNS-запросов) → эксплуатация (запуск PowerShell из Word) → закрепление (создание новой службы) → эксфильтрация (большой исходящий поток данных). Ни одно из этих событий само по себе не является поводом для тревоги — их совокупность означает APT.

Ошибки первого и второго рода

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

Ошибка первого рода (FP) — система сигнализирует об атаке, которой нет. Слишком много ложных тревог перегружает аналитиков SOC и приводит к «усталости от оповещений» — когда реальная атака теряется среди сотен ложных инцидентов.

Ошибка второго рода (FN) — система не замечает реальной атаки. Это прямой риск компрометации.

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

Хеширование паролей

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

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

Почему простого хеша недостаточно

Если хранить просто MD5 или SHA-256(пароль), злоумышленник с базой хешей может применить атаку по радужным таблицам — предвычисленным таблицам соответствий «пароль → хеш» для миллиардов наиболее популярных паролей. Хеш «5f4dcc3b5aa765d61d8327deb882cf99» — это MD5 от слова «password», и любая радужная таблица немедленно это покажет.

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

Соль

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

хранимое_значение = HASH(пароль + соль)

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

Современные алгоритмы хеширования паролей

Обычные криптографические хеш-функции (SHA-256, SHA-3) спроектированы для скорости — они вычисляют миллиарды хешей в секунду на GPU, что делает брутфорс тривиальным. Для хранения паролей нужны специальные медленные алгоритмы, намеренно затратные по вычислениям.

Алгоритм Особенности Статус
bcrypt Регулируемый параметр стоимости (work factor), ограничение длины пароля 72 байта Надёжен, широко применяется
scrypt Затратен и по CPU, и по памяти — противодействует GPU-ускорению Надёжен
Argon2 Победитель Password Hashing Competition 2015; три варианта: Argon2d, Argon2i, Argon2id Текущий рекомендованный стандарт
PBKDF2 Множественные итерации HMAC; используется в стандартах NIST и в iOS Надёжен при достаточном числе итераций
MD5, SHA-1 Быстрые, без соли — небезопасны Категорически не применять для паролей

NIST SP 800-63B прямо указывает: «верификаторы должны хранить запомненные секреты в форме, устойчивой к офлайн-атакам. Запомненные секреты должны быть засолены и хешированы с использованием подходящей односторонней функции получения ключа».

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

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

Современный стандарт симметричного шифрования — AES, принятый NIST в 2001 году. AES работает с блоками по 128 бит и поддерживает ключи длиной 128, 192 и 256 бит. Для большинства задач достаточно AES-128; AES-256 применяется там, где требуется защита от квантовых компьютеров.

Симметричное шифрование крайне быстро — современные процессоры выполняют AES аппаратно через инструкцию AES-NI и шифруют данные со скоростью нескольких гигабайт в секунду. Это делает его практичным для шифрования дисков (BitLocker, dm-crypt), файлов, баз данных и сетевого трафика.

Режимы работы блочного шифра определяют, как шифруются данные, превышающие один блок. Небезопасный режим ECB шифрует каждый блок независимо — одинаковые блоки открытого текста дают одинаковые блоки шифртекста, что раскрывает паттерны данных. Безопасные режимы CBC, CTR и GCM связывают блоки между собой через вектор инициализации (IV), устраняя эту уязвимость. Режим GCM дополнительно обеспечивает аутентификацию — позволяет обнаружить модификацию шифртекста.

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

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

Асимметричное шифрование (криптография с открытым ключом) использует математически связанную пару ключей: открытый (public key) и закрытый (private key). Открытый ключ публикуется свободно, закрытый хранится в тайне.

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

Алгоритм RSA основан на сложности разложения произведения двух больших простых чисел на множители. Алгоритм ECDSA использует математику эллиптических кривых и обеспечивает эквивалентную стойкость при значительно меньшей длине ключа (256-битный ECDSA ≈ RSA-3072).

Гибридное шифрование объединяет преимущества обоих подходов: асимметричное шифрование (медленное) используется только для передачи симметричного ключа сессии, а симметричное (быстрое) — для шифрования самих данных. Именно так работает TLS: при установке соединения стороны согласуют симметричный ключ сессии через асимметричную криптографию, затем весь трафик шифруется AES.

Алгоритм Диффи–Хеллмана (DH) решает задачу выработки общего секрета двумя сторонами через открытый канал. Алиса и Боб обмениваются открытыми параметрами, из которых каждый независимо вычисляет одинаковый симметричный ключ — при этом перехватчик, видящий весь обмен, не может его воспроизвести. Вариант ECDH (на эллиптических кривых) используется в современных версиях TLS.

Хеш-функции и контроль целостности

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

Алгоритм SHA-256(Secure Hash Algorithm) даёт 256-битный дайджест. Является текущим стандартом для большинства задач. SHA-3 (Keccak) — алгоритм с принципиально иной архитектурой, устойчивой к атакам на SHA-2. MD5 и SHA-1 считаются криптографически скомпрометированными и не должны применяться в задачах безопасности.

Применения хеш-функций

Контроль целостности файлов — вычисление хеша эталонного файла и его сравнение с хешем проверяемого. Если хеши совпадают — файл не изменён. Дистрибутивы Linux публикуют SHA-256-суммы для проверки подлинности образов.

Хранение паролей — как описано выше: хранится хеш с солью, а не сам пароль.

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

Коды аутентификации сообщений или Имитовставка (MAC, HMAC) — хеш, вычисленный с применением общего секретного ключа. Позволяет одновременно проверить целостность и подлинность источника. HMAC-SHA256 используется в JWT, API-аутентификации, TOTP.

Электронная цифровая подпись

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

Как работает ЭП

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

Процесс проверки: получатель вычисляет хеш полученного документа → расшифровывает подпись открытым ключом отправителя → сравнивает два хеша. Совпадение означает: документ не изменён и подписан владельцем закрытого ключа.

Атаку MITM на ЭП можно реализовать через подмену открытого ключа: если Боб думает, что открытый ключ Алисы принадлежит ей, а на самом деле это ключ злоумышленника — подпись не обеспечит подлинность. Эту проблему решает PKI.

Инфраструктура открытых ключей (PKI)

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

Ответ PKI: третья доверенная сторона — Удостоверяющий центр (УЦ, Certificate Authority, CA) — выдаёт цифровые сертификаты, связывающие открытый ключ с идентичностью его владельца и заверяет эту связь своей ЭЦП.

Цифровой сертификат X.509

Стандарт X.509 определяет формат цифрового сертификата. Сертификат содержит: серийный номер, идентификатор алгоритма подписи, имя УЦ-издателя, срок действия (не ранее / не позднее), имя владельца (Subject), открытый ключ владельца, расширения (альтернативные имена, использование ключа, пути отзыва) и подпись УЦ над всеми перечисленными полями.

Подпись УЦ означает: «Удостоверяющий центр X проверил, что данный открытый ключ принадлежит данному субъекту». Любой, кто доверяет УЦ X, может доверять этому сертификату.

Иерархия PKI

PKI строится как иерархия доверия.

Корневой УЦ (Root CA) — вершина иерархии. Подписывает свой сертификат самостоятельно (самоподписанный сертификат). Хранится в строжайшей физической изоляции — в offline-режиме. Скомпрометация Root CA разрушает доверие ко всей инфраструктуре.

Промежуточный УЦ (Intermediate CA) — сертификат выдан Root CA. Используется для повседневной выдачи сертификатов конечным субъектам. Изоляция Root CA и промежуточного уровня — стандартная практика: даже при компрометации промежуточного CA Root CA остаётся нетронутым.

Конечные сертификаты (End-entity certificates) — сертификаты серверов (TLS), пользователей (S/MIME, ЭЦП), устройств (IoT, VPN-клиенты).

Браузеры и операционные системы поставляются со встроенным хранилищем доверенных Root CA (Mozilla NSS, Microsoft Root Store, Apple Root Store). Сертификат TLS веб-сайта признаётся доверенным, если цепочка от него до корневого УЦ прослеживается непрерывно.

Жизненный цикл сертификата

Выпуск — владелец генерирует пару ключей, создаёт CSR с открытым ключом и метаданными, отправляет в УЦ. УЦ проверяет личность заявителя (DV — проверка домена, OV — проверка организации, EV — расширенная проверка) и выдаёт подписанный сертификат.

Использование — сертификат предъявляется при установке TLS-соединения, подписании документов, аутентификации пользователей.

Отзыв — если закрытый ключ скомпрометирован или сертификат выдан ошибочно, УЦ отзывает его. Механизмы проверки отзыва: CRL — периодически обновляемый список отозванных сертификатов; OCSP — запрос актуального статуса конкретного сертификата в реальном времени.

Истечение срока — сертификаты имеют ограниченный срок действия. Для публичных TLS-сертификатов с 2023 года максимальный срок действия составляет 398 дней. Истечение срока без замены вызывает ошибки в браузерах — инцидент, несмотря на отсутствие атаки.

PKI в России

В России действует национальная инфраструктура PKI. Для КЭП(квалифицированной электронной подписи) используются сертификаты, выданные аккредитованными УЦ Минцифры. Алгоритмы подписи определяются ГОСТ Р 34.10-2012 (алгоритм подписи на эллиптических кривых) и ГОСТ Р 34.11-2012 (хеш-функция «Стрибог»). КЭП имеет юридическую силу, эквивалентную собственноручной подписи, и обязательна для взаимодействия с государственными информационными системами.

TLS — применение криптографии на практике

TLS — протокол, обеспечивающий конфиденциальность, целостность и аутентификацию для сетевых соединений. TLS используется везде, где в адресной строке браузера отображается HTTPS, — и в десятках других протоколов (SMTPS, IMAPS, LDAPS, FTPS).

Установка TLS-соединения (handshake) объединяет все рассмотренные механизмы. Клиент и сервер согласуют версию TLS и набор криптографических алгоритмов (cipher suite). Сервер предъявляет сертификат X.509; клиент проверяет цепочку доверия до Root CA и срок действия. Стороны выполняют обмен Диффи–Хеллмана для выработки общего симметричного ключа сессии. Все последующие данные шифруются AES-GCM, целостность защищается HMAC.

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

Что дальше

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

Обновлено С. Антошкин 16 дня назад · 5 изменени(я, ий)