Информационная безопасность

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

Обычно безопасность рассматривается через три основных свойства информации:

• Конфиденциальность - данные доступны только тем, кому разрешен доступ.
• Целостность - данные и системы нельзя незаметно изменить или подменить.
• Доступность - системы остаются работоспособными тогда, когда они необходимы пользователям и бизнесу.

Безопасность не ограничивается установкой антивируса, firewall или SSL-сертификата. Она охватывает весь жизненный цикл системы:

Проектирование
    ↓
Разработка
    ↓
Развертывание
    ↓
Эксплуатация
    ↓
Мониторинг
    ↓
Обновление
    ↓
Реагирование на инциденты

Что необходимо защищать

Данные

• Персональные данные пользователей.
• Платежные данные.
• Коммерческую информацию.
• Внутренние документы.
• Данные клиентов и партнеров.
• Резервные копии.

Учетные записи и доступы

• Пользовательские аккаунты.
• Административные панели.
• Учетные записи сотрудников.
• Сервисные аккаунты.
• API-ключи.
• Токены доступа.
• SSH-ключи.

Инфраструктура

• Серверы.
• Базы данных.
• Контейнеры.
• Облачные ресурсы.
• Сети.
• DNS.
• CDN.
• CI/CD.

Исходный код и цепочка поставки

• Репозитории.
• Зависимости.
• Container Images.
• Build-системы.
• Package Registries.

Основные классы угроз

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

• Компрометация учетных записей.
• Утечки данных.
• Уязвимости веб-приложения.
• Ошибки конфигурации.
• Использование устаревших зависимостей.
• Вредоносное программное обеспечение.
• Фишинг и социальная инженерия.
• DDoS-атаки.
• Компрометация подрядчика или внешнего сервиса.
• Ошибки сотрудников.
• Злоупотребление легитимными правами доступа.

Модель угроз

Защитить систему от всех возможных сценариев одинаково хорошо невозможно. Поэтому меры безопасности выбираются на основе реальных рисков.

Модель угроз помогает определить:

• Какие данные и функции наиболее критичны.
• Кто потенциально может атаковать систему.
• Какие точки входа существуют.
• Какие последствия может вызвать инцидент.
• Какие меры снижают наиболее существенные риски.

Упрощенная схема:

Актив
  ↓
Угроза
  ↓
Уязвимость
  ↓
Вероятность
  ↓
Последствия
  ↓
Риск
  ↓
Меры защиты

Defense in Depth

Информационная безопасность обычно строится по принципу многоуровневой защиты.

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

Например:

Internet
   ↓
CDN / DDoS Protection
   ↓
Firewall / WAF
   ↓
Application Authentication
   ↓
Authorization
   ↓
Application Logic
   ↓
Database Permissions
   ↓
Encrypted Data

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

Управление доступом

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

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

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

Например:

• Редактору контента не требуется доступ к инфраструктуре.
• Frontend-приложению не требуется административный доступ к базе данных.
• CI/CD pipeline не должен иметь больше production-прав, чем необходимо для deployment.
• Один микросервис не должен автоматически иметь доступ ко всем базам системы.

RBAC

Role-Based Access Control позволяет выдавать права через роли.

Например:

Administrator
Editor
Support
Analyst
User

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

MFA

Multi-Factor Authentication добавляет дополнительный фактор проверки личности.

MFA особенно важно для:

• Административных аккаунтов.
• Облачных панелей.
• Репозиториев.
• Корпоративной почты.
• VPN.
• Систем мониторинга.

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

Жизненный цикл доступа

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

Типовой жизненный цикл:

Создание доступа
      ↓
Назначение минимальных прав
      ↓
Периодический аудит
      ↓
Изменение роли
      ↓
Отзыв доступа

Особенно важно своевременно отзывать доступ:

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

Управление секретами

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

К секретам относятся:

• Пароли баз данных.
• API Tokens.
• SSH Keys.
• Private Keys.
• OAuth Client Secrets.
• Encryption Keys.

Для хранения могут использоваться:

• Secret Manager облачной платформы.
• HashiCorp Vault.
• Kubernetes Secrets в сочетании с дополнительными механизмами защиты.
• Другие специализированные Secret Storage.

Ротация секретов

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

Ротация особенно важна:

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

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

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

Валидация входных данных

Входные данные проверяются на соответствие ожидаемой структуре.

Например:

• Тип.
• Размер.
• Диапазон.
• Формат.
• Допустимые значения.

SQL Injection

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

Для этого применяются:

• Prepared Statements.
• Parameterized Queries.
• ORM и Query Builders с безопасной передачей параметров.

XSS

Cross-Site Scripting возникает, когда непроверенные данные становятся исполняемым кодом в браузере пользователя.

Для снижения риска используются:

• Контекстное экранирование вывода.
• Безопасные шаблонизаторы.
• Ограничение вставки произвольного HTML.
• Content Security Policy.

CSRF

Cross-Site Request Forgery связан с выполнением действия от имени уже авторизованного пользователя.

В соответствующих сценариях применяются:

• CSRF Tokens.
• SameSite Cookies.
• Проверка Origin и других параметров запроса там, где это оправдано.

Безопасная аутентификация

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

Могут использоваться:

• Rate Limiting.
• Ограничение количества попыток.
• MFA.
• Безопасное восстановление доступа.
• Контроль подозрительных входов.
• Управление активными сессиями.

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

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

Для хранения используются специализированные password hashing algorithms с солью и соответствующими параметрами вычислительной стоимости.

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

Сессии и Cookies

Для Cookies, связанных с аутентификацией, в зависимости от архитектуры используются параметры:

• Secure.
• HttpOnly.
• SameSite.

Также необходимо контролировать:

• Срок жизни сессии.
• Завершение сессии после logout.
• Отзыв сессии после изменения критических учетных данных.

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

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

При их проектировании учитываются:

• Authentication.
• Authorization.
• Валидация данных.
• Rate Limiting.
• Ограничение размера запросов.
• Безопасная обработка ошибок.
• Контроль доступа к отдельным объектам.

Broken Access Control

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

Например, наличие URL:

/orders/123

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

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

Загрузка файлов

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

Проверяются:

• Размер файла.
• Допустимый тип.
• Расширение.
• Фактическое содержимое при необходимости.
• Имя файла.
• Место хранения.

Файлы, которые не должны выполняться как код, желательно хранить отдельно от исполняемого web-root или использовать специализированное файловое или объектное хранилище.

Security Headers

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

В зависимости от проекта могут использоваться:

• Content-Security-Policy.
• Strict-Transport-Security.
• X-Content-Type-Options.
• Referrer-Policy.
• Permissions-Policy.

Конфигурация должна учитывать реальное поведение приложения и внешние интеграции.

TLS и HTTPS

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

TLS-конфигурация включает:

• Сертификаты.
• Доверенную цепочку.
• Поддерживаемые версии TLS.
• Криптографические параметры.
• HSTS в подходящих сценариях.

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

Защита инфраструктуры

Обновления

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

В инфраструктуре должен существовать процесс:

Обнаружение обновления
      ↓
Оценка риска
      ↓
Тестирование
      ↓
Deployment
      ↓
Контроль результата

Минимизация поверхности атаки

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

Поэтому рекомендуется:

• Отключать ненужные сервисы.
• Закрывать неиспользуемые порты.
• Ограничивать административный доступ.
• Минимизировать состав production-окружения.

Сетевая сегментация

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

Типовая схема может выглядеть так:

Internet
   ↓
Load Balancer / Web
   ↓
Application Network
   ↓
Database Network

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

Firewall и Security Groups

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

Например:

Internet → HTTPS → Web Server
Web Server → Application
Application → Database
Administrator → VPN → Internal Infrastructure

Административный доступ

Критические административные интерфейсы желательно дополнительно ограничивать.

В зависимости от инфраструктуры могут использоваться:

• VPN.
• IP Allowlist.
• Bastion Host.
• MFA.
• Отдельные административные учетные записи.

Контейнерная безопасность

Использование Docker или Kubernetes не делает приложение автоматически безопасным.

Необходимо учитывать:

• Происхождение Base Images.
• Уязвимости Container Images.
• Запуск без root там, где это возможно.
• Минимизацию состава образа.
• Управление Secrets.
• Network Policies.
• Ограничение ресурсов и привилегий контейнера.

Облачная безопасность

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

Необходимо контролировать:

• IAM.
• Публичный доступ к ресурсам.
• Security Groups.
• Object Storage Permissions.
• Secrets.
• Audit Logs.
• Encryption.

Логи и аудит

Без журналирования сложно определить, что произошло во время инцидента.

В зависимости от системы журналируются:

• Входы пользователей.
• Неуспешные попытки аутентификации.
• Изменение прав.
• Административные действия.
• Изменение критических данных.
• Ошибки приложения.
• Изменения инфраструктуры.

Что не следует писать в логи

Логи сами могут стать источником утечки.

Без необходимости не следует сохранять:

• Пароли.
• Полные Access Tokens.
• Приватные ключи.
• Полные платежные данные.
• Избыточные персональные данные.

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

Мониторинг и обнаружение аномалий

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

Контролироваться могут:

• Необычное количество попыток входа.
• Резкий рост ошибок.
• Нетипичный объем трафика.
• Массовое скачивание данных.
• Необычные административные действия.
• Изменение критических конфигураций.

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

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

Поэтому необходим постоянный процесс:

Inventory
   ↓
Vulnerability Detection
   ↓
Risk Assessment
   ↓
Prioritization
   ↓
Patch / Mitigation
   ↓
Verification

Dependency Scanning

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

Для контроля используются:

• Dependency Scanners.
• Security Advisories.
• Automated Update Tools.
• Software Composition Analysis.

Приоритет обновления определяется не только наличием CVE, но и реальной применимостью уязвимости к конкретной системе.

Supply Chain Security

Уязвимость может находиться не в собственном коде, а в зависимости, build-системе или процессе доставки приложения.

Поэтому защищаются:

• Репозитории.
• CI/CD.
• Package Registries.
• Container Registries.
• Учетные записи разработчиков.
• Signing Keys.

Secure SDLC

Secure Software Development Lifecycle предполагает учет безопасности на всех этапах разработки.

Упрощенно:

Requirements
   ↓
Threat Modeling
   ↓
Development
   ↓
Code Review
   ↓
Security Testing
   ↓
Deployment
   ↓
Monitoring
   ↓
Updates

Чем раньше обнаружена проблема, тем обычно дешевле ее исправить.

Code Review

Проверка изменений другим разработчиком помогает обнаруживать ошибки до попадания кода в production.

При review обращают внимание не только на функциональность, но и на:

• Проверки доступа.
• Валидацию данных.
• Работу с секретами.
• Логирование.
• Возможные Injection-сценарии.
• Изменение зависимостей.

Security Testing

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

В зависимости от проекта могут применяться:

• SAST.
• DAST.
• Dependency Scanning.
• Container Scanning.
• Configuration Audits.
• Penetration Testing.

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

OWASP

OWASP публикует материалы и классификации распространенных рисков безопасности веб-приложений и API.

Они могут использоваться как ориентир при:

• Проектировании.
• Code Review.
• Тестировании.
• Обучении разработчиков.

При этом OWASP Top 10 не является полным перечнем всех возможных угроз.

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

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

Резервироваться могут:

• Базы данных.
• Пользовательские файлы.
• Конфигурация.
• Критические документы.

Разделение backup и production

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

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

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

Наличие backup-файла не гарантирует возможность восстановить систему.

Периодически должен проверяться реальный процесс:

Backup
  ↓
Restore
  ↓
Application Start
  ↓
Data Verification
  ↓
Recovery Confirmed

RPO и RTO

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

• RPO - какой объем последних данных допустимо потерять.
• RTO - сколько времени система может оставаться недоступной.

Например, если RPO составляет 15 минут, backup или другая стратегия восстановления должна позволять ограничить потерю данных примерно этим интервалом.

Incident Response

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

Типовой процесс:

Detection
   ↓
Analysis
   ↓
Containment
   ↓
Eradication
   ↓
Recovery
   ↓
Post-Incident Review

Локализация инцидента

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

Например:

• Отозвать скомпрометированный ключ.
• Заблокировать учетную запись.
• Изолировать сервер.
• Отключить уязвимую интеграцию.
• Ограничить внешний трафик.

Восстановление после инцидента

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

При этом необходимо убедиться, что:

• Причина инцидента устранена.
• Скомпрометированные секреты заменены.
• Доступы проверены.
• Данные восстановлены корректно.
• Мониторинг не показывает повторных признаков атаки.

Post-Incident Review

После серьезного инцидента полезно определить:

• Что произошло.
• Почему существующие меры не предотвратили проблему.
• Как быстро удалось обнаружить инцидент.
• Что затрудняло восстановление.
• Какие изменения необходимо внести.

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

DDoS

DDoS-атака направлена на исчерпание доступных ресурсов системы или сетевого канала.

Защита может включать несколько уровней:

• CDN.
• Специализированную DDoS-защиту.
• Rate Limiting.
• WAF.
• Масштабирование.
• Ограничение ресурсоемких операций.

Конкретная стратегия зависит от типа атаки и архитектуры системы.

Социальная инженерия

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

Распространенные сценарии:

• Фишинговые письма.
• Поддельные страницы входа.
• Запросы на передачу пароля или кода MFA.
• Подмена отправителя.
• Мошеннические запросы от имени руководителя или партнера.

Обучение сотрудников

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

Обучение может включать:

• Распознавание фишинга.
• Использование MFA.
• Работу с Password Manager.
• Правила передачи файлов.
• Порядок сообщения о подозрительном событии.

Инвентаризация активов

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

Поэтому желательно иметь актуальную информацию о:

• Серверах.
• Доменах.
• Базах данных.
• Облачных ресурсах.
• Репозиториях.
• Внешних интеграциях.
• Ответственных сотрудниках.

Классификация данных

Не все данные требуют одинакового уровня защиты.

Может использоваться классификация:

Public
Internal
Confidential
Restricted

Чем выше критичность данных, тем строже могут быть требования к:

• Доступу.
• Шифрованию.
• Логированию.
• Хранению.
• Передаче.
• Удалению.

Шифрование данных

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

Обычно различают:

• Encryption in Transit - например TLS.
• Encryption at Rest - шифрование дисков, баз данных или отдельных данных.

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

Аудит изменений

Для критической инфраструктуры полезно понимать, кто, когда и что изменил.

Источниками аудита могут быть:

• Git.
• CI/CD.
• Cloud Audit Logs.
• CMS.
• Административные системы.
• IAM.

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

Один общий аккаунт

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

Отсутствие MFA

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

Секреты в репозитории

Удаление секретного ключа из последнего commit не обязательно удаляет его из истории Git.

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

Секреты в логах

Токены и пароли могут случайно попадать в debugging или request logging и затем распространяться через централизованные системы логирования.

Публичная административная инфраструктура

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

Отсутствие обновлений

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

Backup без проверки восстановления

Резервные копии могут оказаться поврежденными, неполными или несовместимыми с текущим процессом восстановления.

Избыточные права

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

Безопасность как постоянный процесс

Информационная безопасность не является одноразовой настройкой.

Система постоянно изменяется:

Новый код
+
Новые зависимости
+
Новые сотрудники
+
Новые интеграции
+
Новая инфраструктура
+
Новые уязвимости

Поэтому со временем должны пересматриваться:

• Права доступа.
• Секреты.
• Зависимости.
• Threat Model.
• Backup Strategy.
• Incident Response Plan.
• Мониторинг и алерты.

Базовый чек-лист

• Включена MFA для критических учетных записей.
• У каждого сотрудника есть персональная учетная запись.
• Права выдаются по принципу минимальных привилегий.
• Неиспользуемые доступы регулярно удаляются.
• Секреты не хранятся в исходном коде.
• Настроен процесс обновления зависимостей и инфраструктуры.
• Критические административные интерфейсы ограничены.
• Входные данные приложения валидируются.
• Используются безопасные механизмы работы с SQL.
• Настроены HTTPS и необходимые Security Headers.
• Ведутся аудит и централизованные логи.
• Чувствительные данные не попадают в логи без необходимости.
• Настроены резервные копии.
• Проверяется реальное восстановление из backup.
• Определены RPO и RTO для критических систем.
• Существует порядок реагирования на инциденты.

Комплексный подход к безопасности

Информационная безопасность объединяет несколько уровней:

Люди
  ↓
Процессы
  ↓
Приложение
  ↓
Инфраструктура
  ↓
Данные
  ↓
Мониторинг
  ↓
Реагирование
  ↓
Восстановление

Надежность системы определяется не одной защитной технологией, а сочетанием независимых мер.

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