Когда ключевая система в вашей компании выходит из строя, сложнее всего понять, что восстановить в первую очередь, у кого есть возможность получить доступ для этого, какая резервная копия является доверенной и как долго ваш бизнес может продолжать работу без этой системы.
Именно в этот момент многие предприятия малого и среднего бизнеса (МСБ) обнаруживают разницу между наличием резервных копий и наличием реального тарифа восстановления. Резервная копия может содержать необходимые вам данные, но она не определяет очередность восстановления, не распределяет обязанности, не проверяет, удается ли восстановить данные и не решает проблему отсутствия учетных данных администратора во время сбоя.
ИТ-тариф аварийного восстановления структурирует этот процесс еще до возникновения сбоя. Он определяет, какие системы наиболее важны, как быстро их необходимо восстановить, какой объем потери данных бизнес может допустить, какие стратегии предотвращения потери данных следует внедрить, кто отвечает за каждый шаг восстановления и как защищены критически важные учетные данные. Такая ясность может предотвратить перерастание ИТ-инцидента в длительный простой, потерю выручки или более масштабный операционный кризис.
Что такое ИТ-тариф аварийного восстановления?
Непрерывность бизнеса и аварийное восстановление ИТ-инфраструктуры
Что должен охватывать ваш ИТ-тариф аварийного восстановления
Что должен определять ваш ИТ-тариф аварийного восстановления
Восстановление учетных данных: упущенный из виду сценарий аварийного восстановления
Шаблон тарифа аварийного восстановления
Как протестировать ваш ИТ-тариф аварийного восстановления
Постройте процесс восстановления вокруг систем, данных и возможности получить доступ
Что такое ИТ-тариф аварийного восстановления?
ИТ-тариф аварийного восстановления — это задокументированный процесс, позволяющий восстановить технологические системы после сбоя. Он ориентирован на ИТ-инфраструктуру бизнеса: данные, приложения, устройства, инфраструктуру, облачные службы, возможность получить доступ для администратора, резервные копии и людей, ответственных за восстановление.
Практичный ИТ-тариф восстановления должен отвечать на такие вопросы, как:
- Какие системы необходимо восстановить в первую очередь?
- Какой период простоя может допустить бизнес?
- Какой объем потери данных является допустимым?
- Где сохранено резервные копии?
- Кто может восстановить системы?
- Какие учетные данные администратора необходимы?
- Как команда сможет подтвердить, что системы, которые удалось восстановить, безопасны и пригодны для использования?
- Как компания будет общаться с сотрудниками и клиентами, если основные каналы связи не работают?
Тариф аварийного восстановления должен выходить за рамки борьбы с кибератаками: он должен охватывать повседневные проблемы, такие как сбой оборудования, утерянные учетные данные и случайное удаление. Он также должен охватывать перебои во внешних службах, такие как сбои в работе облачной платформы или инструментов SaaS, неправильные настройки и увольнение ключевых сотрудников без передачи возможности получить доступ к критически важным ресурсам.
Восстановление — это не то, что нужно проектировать во время сбоя. Его необходимо спланировать, распределить обязанности, обсудить и протестировать до того, как вашему бизнесу придется от него зависеть.
Непрерывность бизнеса и аварийное восстановление ИТ-инфраструктуры
Непрерывность бизнеса и аварийное восстановление ИТ-инфраструктуры часто рассматривают как одно и то же, но они решают разные задачи.
Непрерывность бизнеса заключается в поддержании работы компании во время сбоя. Она охватывает общение с клиентами, временные рабочие процессы, обязанности персонала, координацию с поставщиками и решения о том, какие услуги должны предоставляться, даже если обычные системы недоступны.
Аварийное восстановление ИТ-инфраструктуры сосредоточено на технологиях, обеспечивающих эту работу. Оно определяет, как будут восстановлены системы, данные, приложения, резервные копии и возможность получить доступ для администратора, чтобы бизнес мог безопасно вернуться к нормальной деятельности.
В качестве примера рассмотрим сбой в работе CRM. Тариф обеспечения непрерывности бизнеса может объяснять, как отделы продаж или поддержки продолжают обслуживать клиентов во время простоя CRM. Тариф ИТ-восстановления объясняет, кто связывается с поставщиком, какие данные необходимо восстановить, какая резервная копия или возможность экспортировать доступна, какие учетные данные требуются и как команда сможет подтвердить, что систему снова безопасно использовать.
Для многих предприятий МСБ эта разница становится очевидной только во время инцидента. Сотрудники знают, кто будет связываться с клиентами, но не знают, кто может восстановить биллинговую систему. Они знают, что резервные копии существуют, но не знают, тестировалась ли когда-либо возможность восстановить данные. Они знают, что один сотрудник обычно отвечает за ИТ, но не знают, что произойдет, если этот человек окажется недоступен, или где сохранено пароли администратора, если с ним нет связи.
Что должен охватывать ваш ИТ-тариф аварийного восстановления
Эффективный ИТ-тариф аварийного восстановления не обязательно должен быть слишком длинным, но он должен быть достаточно конкретным, чтобы им можно было воспользоваться в стрессовой ситуации.
Целевое время восстановления
Целевое время восстановления, или RTO, определяет, как быстро необходимо восстановить систему. Платежная система должна возвращаться к работе в течение нескольких часов, в то время как внутренняя панель управления отчетностью может переносить более длительный простой.
Устанавливайте RTO исходя из влияния на бизнес, а не технических настроек, поскольку стоимость простоя — это одновременно и коммерческая, и техническая проблема. Спросите себя, какие системы влияют на выручку, обязательства перед клиентами, юридические обязательства, безопасность и продуктивность сотрудников.
Целевая точка восстановления
Целевая точка восстановления, или RPO, определяет допустимый объем потери данных, что помогает выбрать правильные стратегии предотвращения потери данных (DLP). Если RPO системы составляет один час, то резервные копии или репликация должны иметь поддержка восстановления примерно до этого момента.
Если RPO составляет один день, бизнес допускает более крупную потерю данных. RPO также помогает определить частоту создания резервных копий, так как чем меньше RPO, тем чаще необходимо создавать резервные копии. Следовательно, для критически важные систем требуется более частое создание резервных копий, чем для низкоприоритетных систем.
Уровни приоритета систем
Не все системы следует восстановить одновременно. Тариф аварийного восстановления для малого бизнеса должен разделять системы на уровни приоритета.
- Уровень 1: системы, необходимые для основных операций, безопасности, связи или получения выручки.
- Уровень 2: важные системы, которые могут переносить кратковременный простой.
- Уровень 3: менее приоритетные системы, которые можно восстановить после стабилизации бизнеса.
К типичным системам уровня 1 могут относиться электронное письмо, провайдер личные данные, менеджер паролей, финансовые системы, база данных клиентов, хранение в облаке и коммуникационные платформы.
Стратегия создания резервных копий
Ваша стратегия создания резервных копий должна определять:
- Для чего и как часто нужно создать резервную копию
- Где сохранено резервные копии
- Кто может получить доступ к ним
- Как тестируется восстановление
NCSC также опубликовал(новое окно) принципы создания резервных копий, устойчивых к программам-вымогателям, для облачных и локальных решений резервного копирования, отметив, что резервные копии данных по умолчанию не устойчивы к программам-вымогателям и должны оцениваться на предмет угрозы таких программ.
Надежная стратегия резервного копирования обычно включает в себя офлайн или неизменяемые резервные копии для критически важных данных, регулярное тестирование, задокументированные шаги, чтобы восстановить систему, и отдельные учетные данные для администрирования резервного копирования.
Должности и обязанности
Тариф аварийного восстановления должен указывать ответственных лиц, а не просто задачи. Если все знания о восстановлении сосредоточены у одного человека, бизнес подвергается как кадровому, так и ИТ-риску. Определите, кто:
- Руководит восстановлением
- Может восстановить системы
- Связывается с поставщиками
- Одобряет экстренную возможность получить доступ
- Отвечает за внутренние коммуникации
- Документирует решения
Что должен определять ваш ИТ-тариф аварийного восстановления
| Компонент | На какой вопрос отвечает |
| RTO | Как быстро необходимо восстановить каждую систему? |
| RPO | Какой объем данных бизнес может позволить себе потерять? |
| Уровни приоритета | Какие системы восстанавливаются в первую очередь, а какие могут подождать? |
| Стратегия создания резервных копий | Для каких данных создана резервная копия, где это сохранено и тестировалось ли восстановление? |
| Должности и обязанности | Кто руководит восстановлением, может восстановить системы, связывается с поставщиками и одобряет экстренные изменения? |
Восстановление учетных данных: упущенный из виду сценарий аварийного восстановления
Аварийное восстановление часто ориентировано на данные, серверы и резервные копии. Но на практике восстановление может завершиться сбоем, поскольку у команды нет возможности получить доступ к системам, необходимым для того, чтобы восстановить работу.
Восстановление учетных данных ставит вопросы:
- Кто имеет возможность получить доступ к аккаунтам администратора?
- Где сохранено учетные данные резервных копий?
- Какие аккаунты позволяют восстановить критически важные системы?
- Что произойдет, если пароль будет утерян, его удастся раскрыть посторонним лицам или он окажется у недоступного сотрудника?
- Защищены ли экстренные учетные данные и проверяются ли они?
- Можно ли быстро отозвать возможность получить доступ и переназначить её?
Если учетные данные резервной копии сохранено в браузере одного сотрудника, коды восстановления хранятся в конфиденциальной заметке или если пароли администратора, которыми решили поделиться, пересылаются в чате, бизнес может не суметь быстро восстановить работу во время инцидента.
Менеджер паролей для бизнеса помогает снизить этот риск за счет централизации критически важных учетных данных в зашифрованных хранилищах, предоставления доступа по должностям и упрощения отзыва или переназначения доступа при увольнении сотрудника или изменении обязанностей. Proton Pass for Business помогает командам генерировать надежные пароли, безопасно хранить учетные данные, использовать безопасный обмен и не допускать попадания конфиденциальных данных доступа в чаты и электронные таблицы.
Будучи менеджером паролей для ИТ-команд, Proton Pass обеспечивает поддержку централизованного управления учетными данными, политик паролей, безопасного обмена, отчетов и журналов, инициализации SCIM и интеграции SSO. Это делает восстановление учетных данных более управляемым, поскольку доступ к критически важным системам не зависит от одного человека, одного профиля браузера или одного незадокументированного пароля.
Шаблон тарифа аварийного восстановления
Тариф аварийного восстановления работает лучше всего, когда он достаточно конкретен, чтобы направлять действия во время сбоя, но при этом достаточно прост, чтобы команда могла использовать его в стрессовой ситуации. Для предприятий МСБ шаблон должен быть сосредоточен на главном: что необходимо восстановить, как быстро, из какой резервной копии, кем и с какими учетными данными.
1. Область применения
Определите, какие системы, службы, местоположения, устройства и данные охватывает тариф.
Текст шаблона: Этот ИТ-тариф аварийного восстановления охватывает системы, данные, службы, учетные данные и поставщиков, необходимых для того, чтобы восстановить критически важные операции [Название компании] после технологического сбоя.
2. Инвентаризация критически важных систем
Составьте список систем, от которых зависит ваш бизнес, и распределите их по уровням приоритета.
Текст шаблона: Критически важные системы будут распределены по группам Уровень 1, Уровень 2 и Уровень 3 на основе их влияния на бизнес, целевого времени восстановления, целевой точки восстановления и зависимости от других систем.
3. Цели восстановления
Определите RTO и RPO для каждой приоритетной системы.
Текст шаблона: Для каждой системы должны быть задокументированы целевое время восстановления и целевая точка восстановления. Эти показатели следует пересматривать не реже одного раза в год, а также после крупных изменений в системе.
4. Процесс создания резервных копий и возможность восстановить данные
Задокументируйте, где сохранено резервные копии, как часто они создаются, кто может получить доступ к ним и как работает тестирование возможности восстановить данные.
Текст шаблона: Резервные копии должны быть защищены от несанкционированной возможности получить доступ, сохранено отдельно от основных систем, где это применимо, и регулярно тестироваться. Процедуры, позволяющие восстановить данные, должны быть задокументированы для систем Уровня 1.
5. Восстановление учетных данных и возможности получить доступ
Определите, где сохранено критически важные учетные данные и кто может получить доступ к ним во время восстановления.
Текст шаблона: Учетные данные администратора, учетные данные резервной копии, коды восстановления и возможность получить доступ со стороны поставщиков, необходимые для аварийного восстановления, должны быть сохранено в утвержденном зашифрованном хранилище. Возможность получить доступ должна быть ограничена уполномоченными должностями и пересматриваться после смены должностей, увольнения сотрудников и тренировок по восстановлению.
6. Должности и эскалация
Определите лиц, ответственных за восстановление, их дублеров и пути эскалации.
Текст шаблона: Каждая восстановительная должность должна иметь основного ответственного и резервного ответственного. Тариф должен определять, кто руководит восстановлением, кто может восстановить системы, кто связывается с поставщиками, кто распространяет информацию, чтобы обновить сведения, и кто одобряет экстренные изменения.
7. Тариф коммуникации
Определите, как бизнес общается внутри компании и за её пределами во время сбоя в ИТ-системе.
Текст шаблона: Во время событие восстановления внутренними сведениями, чтобы обновить статус, будут делиться через [утвержденный канал]. Внешние коммуникации с клиентами, поставщиками, страховщиками или регулирующими органами должны быть утверждены лицом на должность/командой.
8. Периодичность тестирования и проверки
Определите, как часто тариф тестируется и насколько регулярно он обновлен.
Текст шаблона: Этот тариф аварийного восстановления будет тестироваться как минимум [ежегодно / два раза в год] и пересматриваться после крупных инцидентов, изменений в системах, смены поставщиков или неудачных тренировок по восстановлению.
Как протестировать ваш ИТ-тариф аварийного восстановления
Тариф аварийного восстановления становится полезным только тогда, когда он был протестирован в условиях, близких к реальному сбою. Резервная копия, которая существует, но ни разу не пробовали её восстановить, — это лишь предположение. Восстановительная должность, которую понимает только один человек, — это фактор зависимости. Учетные данные администратора, которые никто не может найти во время сбоя, — это блокирующий фактор.
На первых порах тестирование не должно быть сложным. Для большинства предприятий МСБ цель состоит в том, чтобы доказать, что компания может восстановить нужные системы силами нужных людей, используя правильные учетные данные и в реалистичные сроки.
1. Теоретическая тренировка
Выберите вероятный сценарий, например, атаку программы-вымогателя на общие файлы, которыми решили поделиться, сбой хранения в облаке, случайное удаление данных клиентов или внезапную потерю возможности получить доступ к аккаунту администратора. Разберите по шагам, что команда будет делать в первый час, кто возглавит процесс, с какими поставщиками свяжутся, какие системы будут приоритетными и какая информация будет отсутствовать.
2. Тестовое восстановление
Выберите критически важный файл, базу данных, почтовый ящик или экспорт системы и подтвердите, что их можно восстановить до работоспособного состояния. Проверьте, достаточно ли свежими являются восстановленные данные, работают ли разрешения и знает ли команда, где находится резервная копия.
3. Тестируйте регулярно
В качестве практического ориентира предприятиям МСБ следует тестировать тариф не реже одного раза в год в соответствии с руководством NIST в Special Publication 800-34 Revision 1(новое окно), и чаще — после крупных изменений в системах или у поставщиков.
4. Протестируйте восстановление учетных данных
Подтвердить, что уполномоченные лица могут получить доступ к аккаунтам администратора резервной копии, аккаунтам администратора облака, порталам поставщиков, кодам восстановления и экстренным учетным данным, не полагаясь на браузер одного сотрудника, его конфиденциальные заметки или память. Цель состоит не в том, чтобы без необходимости раскрывать конфиденциальные пароли. Она заключается в том, чтобы подтвердить, что модель получения доступа по-прежнему работает, когда бизнес находится под давлением.
После каждого теста документируйте, что пошло не так, что заняло слишком много времени, и назначайте конкретного ответственного и сроки для каждого исправления. Хороший тест — это не тот, в котором все проходит идеально. Это тот, который выявляет пробелы, пока у компании еще есть время их исправить.
Постройте восстановление вокруг систем, данных и возможности получить доступ
Полезный ИТ-тариф аварийного восстановления дает бизнесу очередность восстановления, круг ответственных лиц, реалистичное представление о допустимом времени простоя, а также способ поддерживать непрерывность бизнеса и восстановить возможность получить доступ к системам, обеспечивающим непрерывность рабочих процессов.
Для предприятий МСБ это может стать решающим фактором между кратковременным сбоем и длительным простоем. Если электронное письмо, финансовое программное обеспечение, хранение в облаке, клиентские системы или аккаунты администратора недоступны, команда должна знать, что восстановить в первую очередь, кто может действовать и какие учетные данные необходимы, чтобы безопасно восстановить возможность получить доступ.
Вот почему планирование восстановления должно охватывать системы, данные и возможность получить доступ в комплексе. Резервные копии могут восстановить файлы, но именно учетные данные позволяют команде вернуть контроль над системами, необходимыми для того, чтобы восстановить работу. Имена пользователей администратора, порталы поставщиков, аккаунты резервной копии, коды восстановления и операционные учетные данные, которыми решили поделиться, — все это должно быть защищено, систематизировано и доступно нужным людям в случае возникновения проблем.
Менеджер паролей для бизнеса помогает усилить эту часть тарифа. Когда критически важные учетные данные сохранены в зашифрованных хранилищах паролей и доступны только уполномоченным лицам, бизнес меньше зависит от браузера одного сотрудника, его конфиденциальных заметок или памяти во время события восстановления.
