Аудит надёжности и безопасности
Находим, где система может сломаться, потерять данные или дать лишний доступ и где обновления выходят без проверки. На выходе — схема системы, реестр рисков и план исправлений по приоритету.
Подходит, если система уже работает или готовится к запуску, но неясно, что может сломаться, у кого какие доступы и как восстановиться после сбоя.
Когда нужен аудит
Любой из этих признаков — повод проверить систему. Сам по себе он не значит, что система уязвима.
- Первая версия скоро выйдет к реальным пользователям или платящим клиентам.
- Система уже падала, теряла операции или выдаёт непонятные ошибки.
- Неясно, восстановятся ли данные из резервной копии.
- Доступы, пароли и ключи от рабочей системы разошлись по разным людям и сервисам.
- Выпустить или откатить обновление может только один разработчик.
- Об ошибках узнаёте от пользователей.
- Проект переходит от одного подрядчика к другому.
- Система начинает работать с персональными или другими конфиденциальными данными.
- ИИ-агенты или внешние модели получили доступ к данным, коду или действиям в системе.
- Корпоративный заказчик попросил описать устройство системы и меры защиты.
Что проверяем
Что именно и насколько глубоко проверять, зависит от системы. Не каждому проекту нужны все пункты.
Устройство системы
Из каких частей она состоит, от каких внешних сервисов зависит, как проходят данные, какая поломка останавливает всю работу и какие операции важнее всего для бизнеса.Данные и доступы
Какие данные хранятся, как пользователи входят в систему, кто что может делать, какие права у сервисов и администраторов. У каждого должно быть только то, что нужно для работы.Безопасность приложения и API
Проверка прав при каждом действии, проверка входящих данных, сессии, загрузка файлов, обработка ошибок, защита от злоупотреблений и важных операций.Серверы, настройки и ключи
Разделены ли рабочая и тестовая среды, что открыто в интернет, где хранятся пароли и ключи, как часто их меняют, безопасны ли настройки по умолчанию.Выпуск обновлений
Сторонние библиотеки, защита основной ветки кода, проверки перед выпуском, сборка, кто может выкатывать обновления, как откатить неудачное и не утекают ли ключи.Поведение при сбоях
Что будет, если внешний сервис не отвечает, не задвоится ли операция при повторной попытке, как работают очереди, что при перегрузке и как восстановить работу вручную.Мониторинг и разбор сбоев
Логи, показатели, история действий пользователей, оповещения, кто реагирует на сбой, есть ли инструкции и можно ли потом разобраться, что произошло.Резервные копии
Что копируется, как часто и где хранится, отделены ли копии от основной системы, проверялось ли восстановление, сколько данных можно потерять, за какое время всё восстановить и не зависит ли это от одного человека.
Что вы получите
- Схема системы и движения важных данных.
- Модель угроз: кто и как может навредить системе.
- Разбор возможных сбоев в важных операциях.
- Реестр рисков.
- Оценка доступов, выпуска обновлений, мониторинга и восстановления.
- Приоритеты: что исправлять срочно, что в ближайшее время, что потом, и почему.
- План исправлений на 30, 60 и 90 дней.
- Предварительный объём работ по исправлениям.
Как выглядят выводы
Что нашли, чем это грозит, как проверили и что делать. Без деталей конкретной системы.
Реестр рисковПример
- Резервные копии делаются, но восстановление из них ни разу не проверяли.
- После сбоя данные могут не восстановиться, или восстановление затянется дольше допустимого.
- Пробное восстановление на отдельном сервере: записываем, что восстановилось и за какое время.
- Известно, сколько данных можно потерять и сколько займёт восстановление. Есть инструкция и ответственный.
- Ключ от рабочей системы есть у сервера сборки и у нескольких исполнителей, права никак не разделены.
- Если взломают что-то одно, можно получить лишний доступ ко всей системе и данным.
- Составляем список: у кого и у каких сервисов какие права и ключи, как ключи меняются и записывается ли их использование.
- У каждого только нужные права, у сервисов свои учётные записи, есть порядок отзыва доступа.
- Ошибки записываются только в логи на самом сервере.
- О сбое команда узнаёт, только когда пожалуется пользователь.
- Проверяем, собираются ли ошибки и показатели в одном месте, настроены ли оповещения и доходят ли они до нужного человека.
- Понятно, какие события считать сбоем и кто на них реагирует. Есть инструкция на случай сбоя.
Вопросы и ответы
Расскажите о системе
Напишите, для чего она, на каком этапе и что вызывает сомнения. Для первого разговора не нужны ни доступы, ни полная документация.