Допустим, инцидент локализован, но система заказов не работает. Для бизнеса задача не завершена. Помимо уменьшения воздействия угрозы, защита должна планировать возврат к заслуживающему доверия сервису.
Статья предлагает основу планирования рядом с Sara Shield, а не объявляет готовые автоматические резервное копирование и восстановление во всех развёртываниях.
Подготовьтесь до инцидента
Предлагаем заранее определить ответственных за сервисы, необходимые данные и порядок восстановления компонентов. Работающий на вид сайт без подтверждённого доступа к правильным данным даёт неполную картину исправности.
В поясняющем случае возврат зависит от здоровья приложения, правильного доступа пользователей и достоверности данных. Определите критерии заранее, чтобы решения в кризисе не основывались на догадках.
Наличие копии отличается от проверки восстановления
Спрашивайте не только о наличии копии: какие данные она содержит, кто вправе пользоваться и что показало восстановление в испытательной среде? Старая копия может не включать недавние изменения; этот разрыв надо принять и описать в плане.
Само восстановление данных не устраняет причину инцидента. До полного возврата нужно проверить отсутствие проблемного слабого места или доступа. Это предложения к планированию, а не отчёт о конкретном событии или эксплуатационном результате.
Что менять после восстановления?
Предлагаем записывать причину, выполненные действия и нужные улучшения. Это может быть устранение лишних полномочий, изменение наблюдения или уточнение инструкций. Цель — превратить опыт инцидента в прослеживаемые изменения.
Для Sara Shield безопасность не является навсегда завершённым состоянием. Защита ценна, когда организация понимает объекты охраны, реакцию на сбои и повторное подтверждение исправности. У инфраструктурной команды и владельцев бизнеса в этом плане разные необходимые обязанности.
