Требования к ПО

Требования к безопасности (Security Requirements)

📚 24 вопросовПройти тест →
Лекция

Требования к безопасности (Security Requirements)

Требования к ПО

Требования к безопасности (Security Requirements)

Введение: замки и ключи 🔐

Функция может работать идеально, но если дверь открыта — бизнес потеряет данные.
Безопасность — это не «опция», а базовая защита продукта.
Эта лекция про то, как описывать security‑требования так, чтобы их можно было проверить и внедрить.
💡 Совет: безопасность должна быть в требованиях, иначе её «забудут».
✅ Вывод: security‑требования защищают пользователей и репутацию компании.

Проблема: «уязвимость нашли после релиза» ❌

Без требований:
  • доступы размыты;
  • данные хранятся небезопасно;
  • инциденты происходят неожиданно.
С требованиями:
  • понятно, кто и что может делать;
  • есть стандарты шифрования;
  • QA может проверить требования.
✅ Вывод: безопасность без требований не работает.

Чем помогает и как работает

  • Помогает превратить безопасность из общего принципа в конкретные проверяемые требования к продукту.
  • Помогает снизить риск утечек и компрометации доступа за счёт формализации ролей, шифрования и контроля.
  • Помогает команде выпускать изменения без потери security-качества благодаря встроенным проверкам и incident-процессу.
Как это работает:
  • Шаг 1: определяем, какие активы и сценарии критичны по безопасности.
  • Шаг 2: фиксируем требования к доступу, данным и защитным механизмам.
  • Шаг 3: добавляем аудит, мониторинг и критерии приёмки.
  • Шаг 4: проверяем готовность команды к инцидентам и регулярным обновлениям угроз.
✅ Вывод: security-требования работают только тогда, когда их можно реализовать, проверить и сопровождать.

Ключевые термины (простыми словами)

  • Authentication (аутентификация) — проверка, кто пользователь.
  • Authorization (авторизация) — что пользователю разрешено.
  • RBAC (роль‑базированный доступ) — права через роли.
  • Least privilege (минимальные права) — доступ только к нужному.
  • Encryption (шифрование) — защита данных в хранении и передаче.
  • MFA (многофакторная аутентификация) — дополнительный фактор защиты.
  • PII (персональные данные) — информация о пользователях.
  • Audit log (журнал аудита) — запись критичных действий.
  • Incident response (реагирование на инциденты) — план действий при утечке.
✅ Вывод: это словарь, без которого security‑требования не описать.

Самое важное (must-know)

  • Security-требования должны быть измеримыми, иначе их нельзя принять или отклонить.
  • Доступы и роли без принципа минимальных прав почти всегда приводят к избыточным рискам.
  • Шифрование, аудит-логи и управление инцидентами обязательны для систем с PII.
  • Безопасность должна быть встроена в процесс разработки, а не добавляться в конце релиза.
  • Критерии приёмки security-требований должны проверяться так же строго, как функциональные.
✅ Вывод: зрелая безопасность — это системный процесс с чёткими требованиями и регулярной проверкой.

1. Аутентификация

Назначение: убедиться, что пользователь тот, за кого себя выдаёт.
Простыми словами: аутентификация подтверждает личность пользователя и снижает риск несанкционированного входа в систему.
Аналогия: паспорт на входе в здание.
Пример:
Логин по email + пароль, MFA для админов.
🔎 Как это происходит на практике:
  1. Команда определяет допустимые методы входа для разных ролей.
  2. Для привилегированных ролей включается MFA как обязательный фактор.
  3. Настраиваются ограничения сессий и политика восстановления доступа.
  4. QA проверяет корректность сценариев входа и отказа.
Характеристики:
  • ✅ надёжная проверка личности;
  • ✅ поддержка MFA;
  • ✅ защита от подбора.
Когда использовать: для всех систем с учётными записями.
✅ Вывод: без аутентификации безопасность невозможна.

2. Авторизация и роли

Назначение: ограничить доступ по ролям.
Простыми словами: авторизация определяет, какие действия разрешены пользователю после входа, чтобы исключить лишний доступ.
Аналогия: ключи от разных кабинетов.
Пример:
RBAC: админ видит все данные, поддержка — только email.
🔎 Как это происходит на практике:
  1. Формируется матрица ролей и прав по критичным операциям.
  2. Применяется принцип минимально необходимых прав для каждой роли.
  3. Проверяются сценарии эскалации привилегий и запрета доступа.
  4. Изменения прав фиксируются и проходят контроль через аудит.
Характеристики:
  • ✅ роли и права описаны;
  • ✅ принцип минимальных прав;
  • ✅ доступ проверяем.
Когда использовать: при работе с чувствительными данными.
✅ Вывод: роли защищают от лишнего доступа.

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

Назначение: защитить данные при хранении и передаче.
Простыми словами: шифрование защищает данные даже при частичной компрометации инфраструктуры или каналов передачи.
Аналогия: сейф для документов.
Пример:
PII шифруется в покое, все запросы только по TLS 1.2+
🔎 Как это происходит на практике:
  1. Определяются категории данных, требующие обязательного шифрования.
  2. Задаётся стандарт для защиты in-transit и at-rest.
  3. Ключи шифрования выносятся в отдельный защищённый контур.
  4. Проводится проверка, что шифрование реально включено в боевой среде.
Характеристики:
  • ✅ шифрование at‑rest и in‑transit;
  • ✅ фиксированный стандарт TLS;
  • ✅ ключи управляются отдельно.
Когда использовать: всегда, если есть PII или платежи.
✅ Вывод: шифрование — обязательная база security.

4. Логи и аудит

Назначение: иметь доказательства и расследовать инциденты.
Простыми словами: логи и аудит нужны, чтобы видеть критичные действия, расследовать инциденты и подтверждать соблюдение требований.
Аналогия: камеры наблюдения в офисе.
Пример:
Логи входа и изменений хранятся 12 месяцев.
🔎 Как это происходит на практике:
  1. Определяется обязательный список security-событий для логирования.
  2. Назначаются сроки хранения и правила доступа к логам.
  3. Проверяется полнота и неизменяемость журналов для расследования.
  4. Данные из логов используются для регулярного security-review.
Характеристики:
  • ✅ фиксируются критичные действия;
  • ✅ есть срок хранения;
  • ✅ доступ ограничен.
Когда использовать: в системах с доступом к PII и финансам.
✅ Вывод: без логов невозможно доказать соблюдение.

5. Защита от атак

Назначение: снизить риски типовых уязвимостей.
Простыми словами: защита от атак снижает вероятность успешной эксплуатации типовых уязвимостей и автоматизированных попыток взлома.
Аналогия: сигнализация против взлома.
Пример:
Защита от brute‑force: 5 попыток, затем блокировка на 15 минут.
🔎 Как это происходит на практике:
  1. Для критичных endpoint задаются rate limit и ограничения повторных попыток.
  2. Включаются блокировки/капча для сценариев brute-force.
  3. Валидация ввода и защитные практики покрывают типовые инъекции.
  4. Эффективность защиты периодически проверяется тестами и мониторингом.
Характеристики:
  • ✅ rate limit для логина;
  • ✅ блокировки/капча;
  • ✅ защита от SQL‑инъекций.
Когда использовать: во всех публичных системах.
✅ Вывод: защита от атак — часть требований.

6. Incident Response

Назначение: знать, что делать при утечке или атаке.
Простыми словами: incident response задаёт чёткий порядок действий при нарушениях, чтобы сократить ущерб и время реакции.
Аналогия: план эвакуации при пожаре.
Пример:
Инцидент P1: реакция 30 минут, уведомление DPO.
🔎 Как это происходит на практике:
  1. Определяются уровни инцидентов и критерии классификации.
  2. Для каждого уровня фиксируются SLA реакции и ответственные роли.
  3. Команда проводит тренировку сценариев реагирования.
  4. После инцидента выполняется разбор и обновление требований.
Характеристики:
  • ✅ описаны уровни инцидентов;
  • ✅ определены сроки реакции;
  • ✅ есть ответственные роли.
Когда использовать: при хранении PII или финансовых данных.
✅ Вывод: без плана инцидентов безопасность = иллюзия.

7. Безопасность в разработке

Назначение: внедрить security в процесс.
Простыми словами: безопасность в разработке означает, что security-проверки встроены в ежедневный процесс команды, а не выполняются разово.
Аналогия: проверка качества на каждом этапе производства.
Пример:
SAST + проверка зависимостей перед релизом.
🔎 Как это происходит на практике:
  1. В CI/CD добавляются статические проверки и контроль зависимостей.
  2. Код-ревью включает обязательные security-чекпойнты.
  3. Уязвимости приоритизируются и отслеживаются до закрытия.
  4. Регулярно обновляется security-бэклог по новым рискам и инцидентам.
Характеристики:
  • ✅ автоматические проверки;
  • ✅ код‑ревью;
  • ✅ регулярные проверки зависимостей.
Когда использовать: всегда, если продукт развивается.
✅ Вывод: security‑проверки должны быть частью CI/CD.

Сравнение: аутентификация vs авторизация

ПараметрАутентификацияАвторизация
Вопрос«кто ты?»«что тебе можно?»
Примерлогин + парольроль admin/agent

Часто спрашивают на собеседованиях

  • Чем отличается authentication от authorization? «кто ты» vs «что можно».
  • Зачем нужен RBAC? ограничить доступ по ролям.
  • Почему важен принцип least privilege? снижает риск утечек.
  • Что такое MFA? второй фактор для защиты аккаунта.
  • Зачем нужны audit logs? расследование и доказательства.
✅ Вывод: это базовые вопросы по security.

Типичные ошибки

Ошибка 1: все роли имеют полный доступ

❌ нет ограничений
✅ RBAC и least privilege

Ошибка 2: данные без шифрования

❌ PII в открытом виде
✅ шифрование at‑rest и TLS

Ошибка 3: нет логов

❌ инциденты нельзя расследовать
✅ аудит‑логи 12 месяцев

Ошибка 4: защита от brute‑force отсутствует

❌ подбор паролей
✅ rate limit и блокировки

Ошибка 5: нет плана инцидентов

❌ хаос при утечке
✅ incident response

Best Practices

  • Внедряйте MFA для админов и критичных ролей.
  • Описывайте RBAC и принцип минимальных прав.
  • Шифруйте PII в хранении и передаче.
  • Логируйте критичные действия и храните логи.
  • Регулярно проверяйте уязвимости (SAST, deps).

Заключение

Ключевые мысли

🎯 Security‑требования защищают данные и бизнес.
🎯 RBAC, шифрование и логи — база безопасности.
🎯 План инцидентов делает безопасность управляемой.
Теперь вы умеете формулировать требования безопасности так, чтобы их можно было проверить.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «Требования к безопасности (Security Requirements)»

Пройти тест →