История вопроса:
Требования к информационной безопасности — важнейшая составляющая крупных ИТ-проектов ещё с тех времён, когда стали появляться первые стандарты аудита безопасности (например, ISO 27001 или требования ФЗ-152 в РФ). Без чёткого анализа и формализации требований безопасность системы рискует быть декларативной и неприменимой на практике.
Проблема:
Требования безопасности часто формулируются абстрактно ("всё должно быть защищено"), не учитывают реальные бизнес-процессы и архитектуру, нерасшифрованны по уровням: организационным, технологическим, пользовательским. Кроме того, заказчики и разработчики могут по-разному интерпретировать одни и те же требования — возникает несоответствие реализуемости и нормативности.
Решение:
Системный аналитик начинаeт с изучения корпоративных, государственных и отраслевых стандартов (например: ГОСТы, GDPR, PCI DSS, ISO 27001). Затем он совместно с архитектором и безопасниками выявляет бизнес-критичные процессы, точки хранения и передачи данных, возможные угрозы, определяет перечень соответствующих рисков. На их основе аналитик готовит подробную матрицу требований по доступу, хранению, логированию, шифрованию, а также сценарии инцидентов. После согласования формализует их в документах — так, чтобы каждое требование можно было проверить тестированием или в ходе аудита.
Ключевые особенности:
Почему нельзя доверять только техническим средствам обеспечения ИБ (антивирусам, межсетевым экранам, SIEM)?
Потому что ИБ — это процесс, а не просто набор систем. Важнейшую роль играют организационные процедуры, человеческий фактор, регулярные проверки, обучение пользователей.
Можно ли считать требования выполненными, если система прошла только внутреннее тестирование?
Нет — часто для соответствия нормативам требуется внешний аудит, сертификация, а иногда и стресс-тесты под контролем регулятора.
Достаточно ли просто передать в ТЗ требование "система должна быть защищена согласно 152-ФЗ"?
Недостаточно — нужно указать конкретные меры (контроль доступа, хранение журналов событий, шифрование данных), места их реализации, критерии верификации.
Негативный кейс: В проекте интернет-банкинга аналитик передал в ТЗ только общую фразу "должны выполняться требования 152-ФЗ". Подрядчики реализовали стандартную авторизацию и SSL-сертификат, а на этапе внешнего аудита выяснилось отсутствие контроля хранения данных и незащищённый лог аутентификации.
Плюсы:
Минусы:
Положительный кейс:
На старте проекта системный аналитик согласовал с безопасниками и заказчиком перечень угроз, разработал для каждого сценария детализированные требования по шифрованию и аудиту, определил ответственных. На выходе система прошла аудит без замещаний.
Плюсы:
Минусы: