Информационная безопасность
Информационная безопасность
Информационная безопасность работает как системная дисциплина, которая объединяет архитектуру, разработку, эксплуатацию и процессы реагирования. Для новичка тема выглядит абстрактной, поэтому полезно сразу держать в голове практический вопрос: "Какая конкретная мера снижает какой конкретный риск?".
В инженерной работе безопасность встроена в жизненный цикл:
- при проектировании определяются границы доверия и модели угроз;
- при разработке добавляются валидации, безопасная аутентификация и контроль доступа;
- при эксплуатации включаются мониторинг, резервирование и процедуры реагирования;
- при аудитах проверяются фактические логи, настройки и соответствие политикам.
Практическая карта "что делает атакующий по шагам" — в статье Жизненный цикл атаки.
Эшелонированная оборона и асимметрия
Атакующему достаточно одной уязвимости или одной удачной фишинговой рассылки. Защитнику нужно удерживать много независимых слоёв — патчи, MFA, сегментация сети, WAF, EDR, обучение, резервные копии. Если один контроль отказал, следующий всё ещё может остановить цепочку.
Голливудский образ "гениального хакера" вводит в заблуждение. Большинство реальных атак — повторение известных приёмов (непропатченное ПО, слабые пароли, фишинг, ошибки конфигурации). Сложность защиты в том, что систему нужно выдерживать постоянное давление, а не разовый "взлом с пистолетом у виска".
Ключевые определения
| Термин | Смысл |
|---|---|
| Угроза | Потенциальный источник вреда (атакующий, вредонос, ошибка персонала). |
| Уязвимость | Слабое место, которым можно воспользоваться (баг, слабый пароль, открытый порт). |
| Риск | Сочетание вероятности реализации угрозы и величины ущерба при наличии уязвимости. |
| Инцидент | Факт нарушения конфиденциальности, целостности или доступности. |
| Контроль | Мера защиты: техническая (MFA, WAF), организационная (политики), процессная (IRP). |
Упрощённо: без уязвимости или без мотивированной угрозы риск часто близок к нулю; на практике оценивают вероятность × impact и приоритизируют меры.
Информационная безопасность (Information Security, InfoSec) держится на "трёх китах":
- C – Confidentiality (Конфиденциальность)
- I – Integrity (Целостность)
- A – Availability (Доступность)
Это основа информационной безопасности, и на её основе строятся все политики, технологии и практики в этой области.
Все они взаимосвязаны. Если слишком усиливать конфиденциальность, нарушится доступность (слишком много проверок). Если игнорировать целостность, можно подставить конфиденциальность (подмена данных), а если нет доступности, то даже самые защищённые данные будут бесполезными.
Сеть должна использовать шифрование, проверять целостность пакетов, использовать балансировщики. Приложение должно шифровать и валидировать данные, выполнять мониторинг. База данных должна ограничивать права, контролировать изменения и использовать резервные копии. Пользовательский интерфейс должен не показывать лишнего, санитизировать ввод и использовать быстрые загрузки. Всё это - совокупность CIA.
Play ITЗагрузка интерактивного демо…
Конфиденциальность
Конфиденциальность отвечает на вопрос "Кто может видеть данные?".
| Метод | Описание |
|---|---|
| Шифрование данных (в покое и в движении) | Защита информации путём преобразования в нечитаемую форму. Даже при компрометации данных злоумышленник не сможет их расшифровать без соответствующего ключа. |
| Многофакторная аутентификация (MFA) | Процесс проверки личности пользователя на основе комбинации нескольких факторов: знания (пароль), владения (устройство, токен) и биометрии (отпечаток, лицо). |
| Управление доступом (RBAC, ABAC) | Механизмы разграничения прав доступа: ролевое (RBAC — на основе должности) или атрибутное (ABAC — на основе набора характеристик пользователя, ресурса и контекста). |
| Политики паролей | Требования к сложности паролей, регулярной смене и безопасному хранению (например, с использованием хеширования с солью). |
| DLP (Data Loss Prevention) | Системы и политики, направленные на предотвращение несанкционированной передачи или утечки конфиденциальных данных внутри и за пределами организации. |
| Обучение сотрудников | Повышение осведомлённости персонала о методах социальной инженерии, фишинга и правилах работы с конфиденциальной информацией. |
Нарушением конфиденциальности является утечка данных, перехват токенов авторизации, неправильное раскрытие информации в сети.
Цель конфиденциальности - убедиться, что информация доступна только тем, кто имеет на это право.
Целостность
Целостность данных должна обеспечиваться на протяжении всего их жизненного цикла. Она отвечает на вопрос "Кто может изменять данные?" и "Как мы знаем, что они не были изменены?"
| Метод | Описание |
|---|---|
| Хэши и цифровые подписи | Позволяют проверить целостность данных: любое изменение информации приводит к несоответствию хэша или недействительности подписи. |
| Контроль версий | Системы отслеживания изменений (например, Git) фиксируют все модификации кода и документов, обеспечивая возможность восстановления предыдущих состояний. |
| Разрешения на запись | Ограничение прав на редактирование данных только уполномоченным пользователям или системам. |
| Логирование и аудит | Фиксация всех операций с данными для последующего анализа, выявления инцидентов и установления ответственности. |
| Интеграционные проверки | Валидация данных при вводе или обновлении для обеспечения их корректности и соответствия заданным правилам. |
| Блокчейн (в некоторых системах) | Используется как неизменяемый журнал транзакций, где каждая запись связана с предыдущей, что делает подделку исторических данных вычислительно неосуществимой. |
Нарушением целостности является подмена данных в базе без разрешения, изменение файла без уведомления владельца, и модификация трафика.
Цель целостности - обеспечить неизменность и достоверность информации на всех этапах её жизни.
Доступность
Доступность определяет, что данные должны быть доступны тем, кому они нужны, когда они нужны.
| Метод | Описание |
|---|---|
| Резервное копирование и восстановление | Регулярное создание копий данных с возможностью их восстановления в случае потери из-за сбоя, ошибки или атаки. |
| Высокая доступность (HA) | Архитектурное решение с использованием резервных серверов и автоматическим переключением при отказе основного компонента. |
| Балансировка нагрузки | Распределение входящих запросов между несколькими серверами для повышения производительности и отказоустойчивости. |
| DDoS-защита | Средства фильтрации сетевого трафика, предотвращающие перегрузку сервисов за счёт массовых внешних запросов. |
| Мониторинг и оповещение | Непрерывный сбор метрик состояния систем и автоматическая отправка уведомлений при отклонениях от нормы. |
| SLA (Service Level Agreement) | Договорные обязательства по уровню доступности и времени реакции на инциденты, измеряемые в процентах (например, 99.9%). |
| Регулярное техническое обслуживание | Плановые работы: обновление ПО, установка патчей, очистка логов, дефрагментация и другие операции для поддержания стабильности системы. |
Нарушение доступности - это DDoS-атака, сбой оборудования, отказ диска/сервера, чрезмерная нагрузка на БД.
Цель - гарантировать, что авторизованные пользователи могут получить доступ к данным и ресурсам в нужный момент.
Опасности и безопасность
Опасности строятся на базе рисков, угроз и уязвимостей.
Риск - это вероятность возникновения угрозы, которая может привести к ущербу при наличии уязвимости. К примеру, риск утечки данных через слабые пароли.
Угроза - это потенциальный источник вреда или инцидента, способного нанести ущерб системе. Пример - хакерская атака, фишинг, внутренний злоумышленник.
Уязвимость - это слабое место в системе, которое можно использовать для совершения атаки. Пример - незапатченная библиотека, слабый пароль, открытое API.
Упрощённая схема связи понятий:
Риск ≈ Вероятность(угроза использует уязвимость) × Ущерб
Если уязвимости нет или угроза нереалистична, риск снижается; полного "нулевого риска" в живых системах не бывает.
Инциденты - это любые события, которые угрожают конфиденциальности, целостности или доступности информации.
В случае возникновения инцидентов, необходимо своевременно на него отреагировать в соответствии с планом.
План реагирования на инциденты (IRP - Incident Response Plan) включает в себя следующие этапы:
- Подготовка — обучение команды, инструменты, документация;
- Обнаружение — логи, SIEM, мониторинг;
- Ограничение ущерба — изоляция, отзыв токенов, блокировка IP;
- Расследование — кто, что, где, когда;
- Восстановление: восстановление из бэкапа, патчи;
- Уроки — анализ, улучшение, обновление процедур.
При утечке персональных данных в ЕС оператор по GDPR обязан уведомить надзорный орган в течение 72 часов (если утечка создаёт риск для прав субъектов); пользователей — когда риск высокий. Конкретные сроки зависят от юрисдикции и типа данных.
CERT (Computer Emergency Response Team) — организация, которая помогает в расследовании и реагировании на кибератаки. В РФ это RU-CERT, который осуществляет сбор, хранение и обработку статистических данных, связанных с распространением вредоносных программ и сетевых атак на территории РФ.
Эксплойт - конкретный код или метод, используемый для эксплуатации уязвимости. Пример - SQL-инъекция, XSS-эксплойт, RCE (Remote Code Execution).
Несанкционированный доступ подразумевает получение доступа к данным или системе без разрешения. От этого защититься можно при помощи ролевой модели, двухфакторной аутентификации и аудита активности. К примеру, это может быть взлом аккаунта через подбор пароля, использование чужого токена авторизации, получение прав администратора через IDOR, перехват сессии.
Безопасность приложений как раз рассчитана на защиту от несанкционированного доступа и эксплойтов.
OWASP (Open Web Application Security Project) — это некоммерческая организация, которая выпускает список TOP 10 самых опасных уязвимостей веб-приложений.
OWASP Top 10 — это международно признанный стандарт и рейтинг наиболее критичных уязвимостей веб-приложений. Документ обновляется каждые 3–4 года и служит основой для повышения осведомлённости разработчиков и специалистов по безопасности, а также для внедрения лучших практик защиты.
Play ITЗагрузка интерактивного демо…
Сейчас, среди таких проблем перечисляются:
- Нарушение контроля доступа (Broken Access Control) связаны с неправильным контролем;
- Сбои криптографии (Cryptographic Failures) связаны со слабым шифрованием или его отсутствием;
- Инъекции (Injection) предполагают внедрение вредоносного кода (SQLi, CMDi, XSS);
- Небезопасный дизайн (Insecure Design) - уязвимости на уровне архитектуры;
- Ошибки конфигурации безопасности (Security Misconfiguration) - неправильная настройка серверов или сервисов;
- Уязвимые и устаревшие компоненты (Vulnerable and Outdated Components) говорят об использовании устаревших библиотек;
- Ошибки идентификации и аутентификации (Identification and Authentication Failures) - это очевидные проблемы с логином и паролем;
- Нарушения целостности ПО и данных (Software and Data Integrity Failures) - это уязвимости при обновлении и версионировании;
- Ошибки логирования и мониторинга безопасности (Security Logging and Monitoring Failures) говорят об отсутствии логирования или оповещений или их неправильной настройке;
- Подделка запросов на стороне сервера (Server-Side Request Forgery) предполагает принуждение сервера к запросам от своего имени.
OWASP Top 10 — как применять на практике
Список OWASP полезен как рабочая карта для code review, тестирования и приоритизации доработок. Чтобы список не оставался теорией, для каждой категории фиксируют три пункта:
- Где риск проявляется в вашем продукте
Например, "Broken Access Control" чаще всего виден в API с идентификаторами ресурсов. - Как обнаружить
- негативные тесты на доступ к чужим данным;
- анализ логов 403/401 и попыток перебора;
- SAST/DAST и ручные сценарии.
- Как исправить
- централизованный middleware для авторизации;
- принцип минимально необходимых прав;
- unit/integration тесты на правила доступа.
Короткие примеры "проблема → защита":
- Injection → параметризованные запросы, запрет конкатенации SQL/команд.
- Cryptographic Failures → TLS, современные алгоритмы, управление ключами.
- Security Misconfiguration → hardening по baseline, отключение лишних сервисов.
- Logging and Monitoring Failures → централизованные логи, корреляция событий, алерты.
Такой формат помогает связывать OWASP с roadmap и бюджетом, а не воспринимать его как теоретический список.
Примеры инцидентов и правильной реакции
Практика безопасности начинается с качественного реагирования в первые часы.
Сценарий 1 — утечка токена доступа
- Что происходит: токен найден в публичном репозитории.
- Первое действие: немедленный отзыв токена и ротация ключей.
- Следующие шаги — поиск использования токена в логах, ограничение поверхности доступа, ретроспектива причины утечки.
Сценарий 2 — всплеск 500 ошибок и подозрение на атаку
- Что происходит: резкий рост ошибок на публичном API.
- Первое действие: включить режим ограничения трафика и дополнительное логирование.
- Следующие шаги — анализ запросов, блокировка источников, проверка WAF/Ingress, разбор кода проблемной ручки.
Сценарий 3 — компрометация учётной записи сотрудника
- Что происходит: подозрительный вход из необычной географии.
- Первое действие — блокировка сессий, сброс пароля, проверка MFA.
- Следующие шаги — аудит действий пользователя, поиск lateral movement, обучение команды.
Базовый security baseline для веб-сервисов
Минимальный набор мер, который закрывает значимую часть массовых атак:
- MFA для админских и инженерных учётных записей.
- Пароли только в виде медленного хеша с солью (Argon2/bcrypt/scrypt).
- TLS для внешнего и внутреннего трафика с автоматической ротацией сертификатов.
- RBAC и разделение ролей по принципу least privilege.
- Регулярные обновления зависимостей и инвентаризация библиотек.
- Логи безопасности, SIEM-корреляция и оповещения.
- Резервные копии и проверенные процедуры восстановления.
Для контейнерной платформы этот baseline дополняется controls на уровне кластера и манифестов. Практический контекст рассмотрен в статьях Docker Swarm и Kubernetes и Реализация Kubernetes.
Приоритизация рисков по простой матрице
Чтобы принимать решения быстрее, команде полезно фиксировать риск через две оси:
- вероятность реализации (низкая, средняя, высокая);
- влияние на бизнес (низкое, среднее, высокое).
| Вероятность \ Влияние | Низкое | Среднее | Высокое |
|---|---|---|---|
| Низкая | Наблюдать | Планировать улучшение | Включить в roadmap |
| Средняя | Планировать улучшение | Выполнить в ближайшем спринте | Срочный план устранения |
| Высокая | Выполнить в ближайшем спринте | Срочный план устранения | Немедленные меры + контроль руководства |
Пример:
- SQL-инъекция в публичной форме оплаты обычно попадает в ячейку "высокая вероятность + высокое влияние".
- Устаревшая библиотека в внутреннем сервисе без внешнего доступа чаще попадает в "средняя вероятность + среднее влияние".
Такой подход помогает обсуждать безопасность в терминах приоритета и бюджета, понятных и инженерам, и бизнесу.
Чек-лист безопасного релиза приложения
Перед выкладкой версии полезно пройти короткую проверку:
- Все критичные зависимости обновлены или имеют осознанные исключения.
- Секреты не попали в репозиторий и CI-логи.
- Проверены права доступа к новым endpoint и административным операциям.
- Включены логи безопасности для новых функций.
- Готов план отката и контакт дежурной команды.
Этот чек-лист хорошо работает вместе с инфраструктурным runbook из статьи Реализация Kubernetes.
Пароли в приложениях не хранят в открытом виде — только медленный хеш с солью (bcrypt, Argon2, scrypt):
from argon2 import PasswordHasher
ph = PasswordHasher()
password_hash = ph.hash("user_password") # сохраняем в БД
ph.verify(password_hash, "user_password") # True при входе
Подробнее о методах защиты — в статье Методы защиты информации; об атаках на код — в Безопасность приложений и Инъекции.