- Факт
- Резервные копии создаются, но восстановление не проверялось.
- Риск
- После сбоя данные могут не восстановиться или восстановление займёт больше допустимого времени.
- Проверка
- Тестовое восстановление в изолированном окружении с фиксацией результата и времени.
- Результат
- Измеренные RPO/RTO, понятная процедура и ответственный.
Архитектура, надёжность и безопасность
Проверяем, готова ли система к безопасной и устойчивой эксплуатации
Находим подтверждённые точки отказа, избыточные доступы, риски потери данных и неконтролируемых релизов. На выходе — карта системы, реестр рисков и план исправлений по приоритету.
Без запугивания · выводы связаны с доказательствами · исправления согласуются отдельно
Когда нужен аудит готовности
Работающий функционал ещё не означает готовность к production
Эти признаки не доказывают наличие уязвимости сами по себе. Они показывают, где нужна предметная проверка фактов и сценариев отказа.
- 01
MVP готовится к реальным пользователям или платным клиентам.
- 02
Система уже падала, теряла операции или выдаёт необъяснимые ошибки.
- 03
Неясно, восстанавливаются ли данные из резервной копии.
- 04
Доступы, ключи и production-секреты распределены между людьми и сервисами.
- 05
Релиз и откат зависят от одного разработчика.
- 06
Ошибку обнаруживают только после сообщения пользователя.
- 07
Проект передаётся от одного подрядчика другому.
- 08
Система начинает работать с чувствительными или персональными данными.
- 09
AI-агенты или внешние модели получили доступ к данным, коду или действиям.
- 10
Корпоративный заказчик запросил описание архитектуры и технических мер.
Демонстрационный фрагмент · не клиентский кейс
Факт → риск → проверка → решение
Три примера показывают структуру вывода. Они не описывают конкретного клиента или обследованную систему.
- Факт
- Production-секрет доступен сборочному агенту или нескольким исполнителям без разделения ролей.
- Риск
- Компрометация одного контура может дать избыточный доступ к системе и данным.
- Проверка
- Карта identities, прав, secret scope, rotation и журналирования.
- Результат
- Минимально необходимые права, отдельные service identities и процедура отзыва доступа.
- Факт
- Ошибки остаются только в локальных логах приложения.
- Риск
- Команда узнаёт об инциденте после обращения пользователя.
- Проверка
- Централизованные события, метрики, алерты и проверка маршрута уведомления.
- Результат
- Определённые сигналы отказа, владелец реакции и incident runbook.
Контур проверки
Архитектура, безопасность и эксплуатация рассматриваются вместе
Переводим работающий функционал в управляемую эксплуатацию: проверяем архитектуру, доступы, релизы, наблюдаемость, резервное восстановление и технические риски.
Архитектура и критические сценарии
Компоненты, внешние зависимости, потоки данных, trust boundaries, единичные точки отказа и критичные бизнес-операции.
Данные, роли и доступы
Типы данных, authentication, authorization, RBAC, service accounts, административные действия и принцип минимальных полномочий.
Безопасность приложения и API
Контроль доступа, валидация, сессии, загрузка файлов, обработка ошибок, abuse cases и защита критичных операций.
Окружения, конфигурация и секреты
Разделение development, test и production, внешняя экспозиция, secret management, ротация и безопасные значения по умолчанию.
CI/CD и software supply chain
Зависимости, protected branches, проверки изменений, сборка артефактов, deployment permissions, rollback и утечки секретов.
Надёжность и сценарии отказа
Timeouts, retries, idempotency, очереди, повторная обработка, деградация внешних сервисов, перегрузка и ручное восстановление.
Наблюдаемость и инциденты
Логи, метрики, traces, audit events, алерты, владельцы реакции, runbooks и возможность расследовать событие.
Резервное копирование и восстановление
Состав копий, частота, хранение, изоляция, restore tests, RPO, RTO и зависимость от конкретного исполнителя.
Конкретный состав проверки определяется границами системы и критичными сценариями. Не каждый проект требует одинаковой глубины по всем направлениям.
Входные данные
Достаточно системы, ответственного и критичного сценария
- Описание назначения системы.
- Один-два критичных пользовательских или бизнес-сценария.
- Список основных компонентов и внешних сервисов.
- Известные типы данных и роли.
- Доступ к документации, коду и конфигурации в согласованном read-only или контролируемом режиме.
- Информация о релизах, мониторинге и резервных копиях.
- Технический или бизнес-ответственный, который может подтвердить факты.
Результат
Не список страшных терминов, а основание принимать решения
- Карта текущей архитектуры.
- Схема критичных потоков данных и trust boundaries.
- Список подтверждённых фактов и отдельно отмеченных допущений.
- Threat model для согласованного контура.
- Failure-mode analysis критичных сценариев.
- Реестр рисков.
- Оценка доступов, релизов, наблюдаемости и восстановления.
- Приоритеты P0, P1 и P2 с понятным объяснением.
- План исправлений на 30, 60 и 90 дней.
- Критерии повторной проверки.
- Границы и предварительный состав спринта исправлений.
Первый этап
Начинаем с ограниченного технического review
- 01
Фиксируем границу
Выбираем систему, критичный сценарий, допустимые методы проверки и перечень доступных доказательств.
- 02
Собираем факты
Изучаем архитектуру, конфигурацию, код, процессы релиза, эксплуатационные данные и существующую документацию.
- 03
Проверяем риски
Связываем обнаруженные факты со сценариями отказа, компрометации, потери данных и невозможности восстановления.
- 04
Передаём решение
Проводим совместный разбор, передаём артефакты и согласуем, какие риски принять, устранить или проверить отдельно.
Исправления не включаются автоматически. Их состав, стоимость и срок согласуются после подтверждения фактических рисков.
После первого review
Проверка, исправление и технический надзор разделены
Аудит готовности
Фиксируем архитектуру, подтверждённые риски, ограничения и приоритетный план действий.
Результат
Проверить системуОтчёт, risk register, архитектурные схемы и план исправлений.
Спринт исправлений
Закрываем согласованные критические риски, добавляем проверки и подтверждаем результат повторным review.
Результат
Обсудить исправленияРеализованные технические меры, тесты, документация и evidence повторной проверки.
Технический надзор
Проверяем архитектурные изменения, доступы, зависимости, восстановление, алерты и технический долг после запуска.
Результат
Обсудить сопровождениеРегулярная видимость рисков и управляемые изменения production-системы.
24/7 monitoring, on-call и формальный SLA не входят автоматически и доступны только при отдельном подтверждённом формате работы.
Проверяемые правила
Каждый существенный вывод должен иметь основание
- Факт связан с конфигурацией, кодом, логом, тестом, документом или подтверждением ответственного.
- Предположение явно обозначается как предположение.
- Уровень риска учитывает последствие и условия реализации, а не громкость формулировки.
- Автоматический scanner не заменяет архитектурный анализ.
- Исправление считается завершённым только после повторной проверки.
- Принятый риск фиксируется вместе с владельцем решения.
- Отсутствие найденной проблемы не считается доказательством абсолютной безопасности.
Открытые инженерные практики
Проверка опирается на признанные технические подходы
- OWASP ASVS 5.0.0требования к техническим security controls веб-приложенийИсточник
- OWASP Top 10:2025обзор распространённых классов рисков, но не полный checklistИсточник
- NIST SSDF SP 800-218secure software development lifecycleИсточник
- OWASP SAMMоценка зрелости процессов безопасной разработкиИсточник
- CISA Secure by Designбезопасность как свойство проектирования и эксплуатацииИсточник
- SRE practicesSLO, monitoring, incident response, recovery и надёжность релизовИсточник
Стандарты используются как источник проверяемых требований и вопросов. Их применение само по себе не означает сертификацию или юридическое соответствие.
Границы ответственности
Что технический аудит не подменяет
AITIS отвечает за согласованную инженерную проверку, архитектурные решения, реализацию технических мер и evidence результата. Формальный pentest, юридическая оценка и сертификация при необходимости выполняются отдельно профильными специалистами.
- Аудит ограничен согласованным scope и доступными доказательствами.
- Это не обещание отсутствия всех уязвимостей.
- Это не автоматический формальный pentest.
- Это не юридическое заключение о соответствии законодательству.
- Это не сертификационный аудит.
- Внешние сервисы сохраняют собственные риски и ограничения.
- Invasive testing production выполняется только после отдельного согласования.
- Независимая проверка может потребоваться после исправлений.
- Бизнес принимает решение о допустимом residual risk.
FAQ
Вопросы до технического review
Следующий шаг
Проверить готовность существующей системы
Опишите назначение системы, текущий этап и то, что вызывает сомнение. Для первого разбора не нужны пароли, ключи или полный комплект документации.
Проверить существующую систему