Recovery denial: почему backup без identity-drill не спасает

Проблема

Инциденты всё чаще показывают переход от простого encryption к recovery denial. Давление идет на backup systems, identity services и virtualization planes, потому что именно эти слои решают, сможет ли бизнес восстановиться.

Типовая слабость - красивый backup dashboard, который никогда не проверяли в hostile conditions: украденная admin session, заблокированный identity provider, отключенные логи, измененная backup policy и неизвестное restore time.

Решение

Проводите recovery-denial drill как техническую проверку, а не как созвон. Докажите immutable copies, separate administration, offline credentials, restore speed, preservation evidence и clean identity rotation.

Результатом должен быть recovery decision tree: какие системы восстанавливаются первыми, кто подтверждает identity reset, какое evidence должно сохраниться, какие ключи ротируются и как SOC наблюдает за восстановленной средой.

Что проверить руками

• Можно ли скомпрометировать backup administrators тем же identity path, что и domain administrators.
• Мониторятся ли backup deletion, reduction retention и policy edits как high-risk actions.
• Может ли команда восстановить critical service без повторного использования compromised secrets.
• Оставляет ли restore process evidence: timestamps, hashes, approvals и retest results.

Безопасный пример

Небольшой локальный scorer для tabletop. Он намеренно неинвазивный и должен получать sanitized internal answers.

controls = {
    "immutable_backup": True,
    "separate_backup_admin": False,
    "restore_test_under_4h": True,
    "identity_reset_runbook": False,
    "post_restore_monitoring": True,
}

score = sum(1 for enabled in controls.values() if enabled)
total = len(controls)
print(f"recovery_readiness={score}/{total}")

for name, enabled in controls.items():
    if not enabled:
        print(f"DRILL GAP: {name}")

Критерий ретеста

• Контрольное восстановление укладывается в согласованный бизнесом RTO и дает проверяемые hashes.
• Старые privileged sessions и backup credentials не работают после reset-плана.
• SOC получает alerts на backup-policy edits и restore-administration anomalies.