- •Варианты построения виртуальных защищенных каналов
- •2. Протоколы формирования защищенных каналов на канальном уровне
- •Протоколы формирования защищенных каналов на сеансовом уровне
- •Настройка сетевого интерфейса в CentOs
- •Настройке сети
- •Настройка dns
- •3.1.1. Функции межсетевых экранов
- •3.1.1.1. Фильтрация трафика
- •3.1.1.2. Выполнение функций посредничества
- •3.1.1.3. Дополнительные возможности межсетевых экранов
- •Коммутация пакетов
- •Достоинства коммутации пакетов
- •Недостатки коммутации пакетов
- •Протокол Spanning Tree Protocol (stp)
- •Протокол Rapid Spanning Tree Protocol (rstp)
- •2.Настройка ios
- •3. Настройка маршрутизации
- •Настройка dhcp pool на маршрутизаторе
- •Локальные учетные записи
- •Управление доменными учетными записями пользователей
- •Структуры распределенных систем управления
- •Понятие защищенной ос
- •Выполнить резервное копирование стандартными средствами ос Windows.
- •Технология преобразования сетевых адресов (nat)
- •Установка
- •Настройка сервера
- •1. Процедуры по обслуживанию ис
- •1.Резервное копирование данных
- •2.Ведение журналов регистрации событий
- •3.Слежение за окружающей средой
- •4.Оперирование с носителями информации и их защита
- •5.Обмен данными и программами
- •6.Рекомендации для аудита
- •7.Квотирование дискового пространства
- •Заголовок ah
- •Заголовок esp
- •Транспортный режим
- •Туннельный режим
- •Политика безопасности
- •1. Управление производительностью, безопасностью сети.
- •Типы резервного копирования
- •Разработка и реализация стратегии резервного копирования. Понятие плана архивации
- •Выбор архивных устройств и носителей
- •Особенности управления доступом
- •Функционирование системы управления доступом
- •1. Составляем список критичных пользовательских ит-сервисов
- •2. Определяем точки отказа пользовательских сервисов
- •3. Определяем зависимости точек отказа
- •2. Определяем необходимые ресурсы и условия для восстановления
- •3. Определяем минимальное гарантируемое время восстановления пользовательского сервиса
- •4. Определяем факторы риска процедуры аварийного восстановления и планируем мероприятия по их контролю
- •5. Определяем ситуации, выходящие за рамки планирования
- •Типы acl
- •Порядок просмотра acl
- •Применение acl
- •15.1.1. Классификация компьютерных вирусов
- •15.1.3. Основные каналы распространения вирусов и других вредоносных программ
2. Определяем необходимые ресурсы и условия для восстановления
В процессе аварийного восстановления можно выделить четыре этапа:
Пользовательский сервис не работает.
Пользовательский сервис работает с ограничениями (низкое качество или временное решение).
Пользовательский сервис восстановлен в полном объеме, но с деградацией одной или нескольких ИТ-систем и/или отсутствием необходимых резервов.
Все ИТ-системы восстановлены, необходимые резервы пополнены.
При планировании аварийного восстановления нас, в первую очередь, интересуют необходимые ресурсы и условия для достижения 3-го этапа, как необходимое и достаточное условие для полноценного восстановления конечного пользовательского сервиса. Обычно это:
резервные единицы оборудования с аналогичным функционалом и мощностью.
резервные копии данных/конфигураций и доступ к ним в момент аварии.
дистрибутивы программного обеспечения.
доступ к оборудованию и приложениям (как физический, так и информация по паролям).
специалист соответствующей квалификации.
В зависимости от точек отказа, может вноситься своя специфика: в случае электроснабжения требуется либо дизель, либо резервная площадка для запуска систем, в случае отказа ИБП требуется переключение на питание от сети, в случае отказа внешнего DNS-хостинга требуются контактные данные по договору с регистратором для перевода домена на новый хостинг и т.д. Записывайте все необходимые ресурсы, привязывайте их к точкам отказа и помечайте, какие из них уже есть у вас, а какие необходимо еще получить.
3. Определяем минимальное гарантируемое время восстановления пользовательского сервиса
амую большую сложность на данном этапе составляет определение гарантированного времени восстановления точки отказа. В процедуре восстановления есть только один маршрут с предсказуемым сроком — когда после небольшого, но достаточного исследования причин сбоя проводится полное восстановление точки отказа. Да, в большинстве случаев исправить ошибку быстрее, чем проводить полное восстановление, но гарантировать какие-либо сроки можно только по второму сценарию и по этой причине ориентироваться мы можем только на него. Однако восстановление одной точки отказа не всегда означает восстановление пользовательского сервиса, так как зависимые точки отказа могут также быть неисправными (см. схему зависимостей в первой статье). Определив, на основе данной схемы, самый долгий возможный сценарий, вы получите «минимальное время восстановления» пользовательского сервиса, который может гарантировать бизнесу ИТ-служба. Если же этот срок даже на ваш взгляд выходит за все разумные рамки, то это повод подумать над его оптимизацией:
Сделать предварительные заготовки для ускорения восстановления.
Сократить время на исследование инцидентов (увеличивая вероятность потери данных).
Изменить архитектуру точек отказа для увеличения скорости восстановления.
Собственно, ваши выводы касательно сроков восстановления и методов их сокращения стоит закрепить документально – они пригодятся в дальнейшем в диалоге с руководством. На этом можно было бы и заканчивать данный этап, если бы не пара неожиданностей, которые мы пока не учли: