Както беше отбелязано в първата статия от тази серия, стратегиите и процедурите за ИТ възстановяване след бедствие (DR) помагат на организациите да защитят своите инвестиции в ИТ системи и инфраструктури.
Основната мисия на DR е да върне ИТ операциите до приемливо ниво на производителност възможно най-бързо след разрушително събитие.
Така че, след завършване на оценка на риска (RA) и анализ на въздействието върху бизнеса (BIA), трябва да проучим критичните ИТ услуги, необходими за поддържане на критичните бизнес дейности на организацията.
В тази статия ще разгледаме как да зададем стратегия за възстановяване след бедствие и да разработим подробни планове за DR.
Вградете RPO и RTO в стратегия за DR
Преди да разгледаме подробно стратегията и планирането за DR, трябва да разгледаме два жизненоважни показателя, а именно целта за време за възстановяване (RTO) и целта за точка на възстановяване (RPO).
Съгласно ISO/IEC 27031:2011, глобалният стандарт за ИТ възстановяване след авария (наричан в стандарта информационна и комуникационна технология или ИКТ), RTO е „периодът от време, в рамките на който минималните нива на услуги и /или продуктите и поддържащите системи, приложения или функции трябва да бъдат възстановени след настъпване на прекъсване”.
Междувременно RPO е „точката във времето, до която данните трябва да бъдат възстановени след настъпило прекъсване“. И двата показателя са необходими за дефиниране на стратегии за DR.
RPO/RTO и облак
Имайте предвид, че тези два показателя се влияят от използването на базирани на облак услуги и съображения за киберсигурност.
Например, RTO за център за данни на място може да бъде по-лесен за изчисляване, тъй като всички операции са в рамките на собственото местоположение на организацията.
За разлика от това, когато ИТ операциите се прехвърлят към услуги, базирани на облак, RTO трябва да бъде осигурен от доставчика на облак, който може или не може да предложи приемлива стойност. Същото важи и когато данните се намират в облачна услуга.
Системите за съхранение на данни на място улесняват поддържането на RPO стойности, докато външните доставчици на облачно базирано съхранение може да не са в състояние да предложат надеждно RPO. И двете опасения правят солидно споразумение за ниво на обслужване (SLA) силно препоръчително, тъй като то определя договорени нива на ефективност, които третата страна трябва да поддържа.
Стратегия и подробни планове в процеса на планиране на DR
Фигура 1 изобразява етапите на жизнения цикъл на ИТ възстановяване след бедствие и е адаптирана от ISO 27031:2011. Фигурата показва, че в допълнение към разработването на стратегия трябва да се обмислят допълнителни дейности, преди да могат да бъдат разработени планове за DR.
Например политиката за ИТ възстановяване след авария е съществена част от цялостния процес на DR. По-специално това е важен елемент, който трябва да се проверява по време на одити, така че неговото развитие е от съществено значение.
Анализът на пропуските, който може да се извърши след оценка на риска и дейности по анализ на въздействието върху бизнеса, ако е необходимо, помага да се определят области за подобрение, които могат да подобрят цялостния процес на планиране на възстановяване след бедствие.
Критериите за ефективност на технологията могат да бъдат идентифицирани от BIA, RA и анализи на пропуски и ще бъдат включени в плановете за DR. Тези дейности могат също да идентифицират ресурсите, необходими за постигане на желаните нива на ефективност. BIAs и RAs също трябва да вземат предвид човешките ресурси в тях, не само по време на разрушително събитие, но и по време на нормални операции.
Дефиниране на стратегия
След като критичните системи и функции и RTO и RPO са установени и одобрени, следващата стъпка е да се дефинират стратегии за реагиране на разрушителни инциденти, когато възникнат .
ISO 27031 гласи: „Стратегиите трябва да определят подходите за прилагане на необходимата устойчивост, така че принципите за предотвратяване на инциденти, откриване, реагиране, възстановяване и възстановяване да бъдат въведени.“
Стратегиите определят „какво“ трябва да се направи, когато се реагира на инцидент, докато плановете описват „как“ ще се извършват действията по реагиране и възстановяване.
След като бъдат идентифицирани критични системи, данни, мрежи, елементи за киберсигурност и фирми за облачни услуги, използвайте примера в таблица 1 като отправна точка, за да помогнете за формулирането на стратегии, необходими за тяхната защита.
Факторите, които трябва да се имат предвид при разработването на такава таблица, могат да включват бюджети; вижданията на ръководството относно рисковете; въпроси на киберсигурността; наличие на ресурси, особено облачни услуги; разходи срещу ползи; човешки ограничения; технологични ограничения; и нормативни изисквания.
Ключови фактори при дефинирането на стратегия за DR
Следните въпроси са важни при разработването на стратегии за DR, особено когато се обмисля използването на услуги, базирани на облак.
Съображения за хората
Сред ключовите въпроси са наличието на персонал и/или изпълнители, нуждите от обучение на персонала и изпълнителите, дублиране на критични умения, така че да може да има първичен и поне един резервен, налична документация, която да се използва от персонала, и последващи за да се гарантира запазване на знанията на служителите и изпълнителите.
Използването на облачни услуги въвежда допълнителни съображения, като например сигурността на данните и системите, квалификацията на персонала на доставчиците на облаци, потенциала за нелоялни облачни служители да повредят или откраднат клиентски ресурси, желанието на представителите на облачните доставчици да отговарят вярно на въпросите и способност на персонала на облачните доставчици да се справят с изискванията на клиентите.
Физически съоръжения
Тук трябва да обмислим наличието на алтернативни работни зони в рамките на един и същи обект, на различно местоположение на фирмата, на място, предоставено от трета страна, в домовете на служителите и в транспортируемо работно съоръжение (като монтирано ремарке навън за работно пространство).
Важно е също така да се вземе предвид сигурността на сайта, процедурите за достъп на персонала, идентификационните значки и местоположението на алтернативно пространство спрямо основния офис сайт. Възможно е да не е възможно физически да посетите съоръженията на доставчиците на облак, а клиентските системи и данни могат да се съхраняват в множество центрове за данни, така че потребителите трябва да са подготвени да се доверят на доставчиците на облак, за да защитят своите активи в сигурни и безопасни за околната среда центрове за данни.
Технологични съображения
Това включва неща като достъп до пространство за оборудване, правилно конфигурирано за системи (например повдигнати подове), подходящо отопление, вентилация и климатизация (HVAC), достатъчно първично електрическо захранване, подходяща инфраструктура за глас и данни, разстояние до алтернативна технология зона от основния обект, осигуряване на персонал в алтернативен технологичен сайт, наличие на технологии за преход при срив (към резервна система) и за възстановяване (връщане към нормални операции) за улесняване на възстановяването, необходимост от поддръжка на наследени системи и възможности за физическа и информационна сигурност на алтернативния сайт.
Всеки от тези проблеми трябва да бъде внимателно разгледан, когато използвате доставчик на облачна услуга. Препоръчително е да ги включите в споразуменията за ниво на обслужване (SLA), ако е възможно.
Съображения за данните
Тук трябва да включим своевременно архивиране на критични данни в защитена зона за съхранение в съответствие с изискванията на RTO/RPO, метод(и) за съхранение на данни (например диск, лента, оптично), изисквания за свързаност и честотна лента, за да гарантираме всички критични данни могат да бъдат архивирани в съответствие с графиките на RTO/RPO, възможностите за защита на данните на алтернативно място за съхранение и наличието на техническа поддръжка от квалифицирани доставчици на услуги трети страни.
Тези съображения са от съществено значение, когато използвате доставчик на облачни услуги, особено неговите ресурси за съхранение и достъп до клиентски системи и данни, как защитават своите мрежови периметри от кибератаки, как отговарят на изискванията на клиентите за RTO/RPO и как тестват своите собствени планове за DR.
Съображения за доставчик
Тук трябва да идентифицираме и да сключим договор с основни и алтернативни доставчици за всички критични системи и процеси и дори за снабдяването с хора. Ключови области, в които алтернативните доставчици ще бъдат важни, включват хардуер (сървъри, шкафове), захранване (батерии, UPS, защита на захранването), мрежи (мрежови услуги за глас и данни), ремонт и подмяна на компоненти и множество фирми за доставка (Fedex и UPS) .
Много от тези проблеми могат да бъдат смекчени чрез използване на доставчик на облачни услуги, но все пак е разумно да поддържате резервни копия на критични данни и приложения и да разполагате с доставки на критични системни компоненти.
Политики и процедури
Ключовите стъпки тук включват дефиниране на политики за ИТ възстановяване след бедствие, одобрението им от висшето ръководство, дефиниране на процедури стъпка по стъпка (например за започване на архивиране на данни за осигуряване на алтернативни местоположения), преместване на операциите в алтернативно пространство , възстановяване на системи и данни на алтернативните сайтове и възобновяване на операциите на първоначалния сайт или на ново място. Когато използвате облачни услуги, не забравяйте да вземете предвид съображенията за облака във всички политики за DR и свързаните с тях процедурни документи.
Накрая, не забравяйте да получите одобрение от ръководството за планираните стратегии, политики и процедури. Бъдете готови да демонстрирате, че предложените стратегии са в съответствие с бизнес целите на организацията и стратегиите за непрекъснатост на бизнеса.
Превеждане на стратегии в планове за DR
Следващата стъпка след завършване на стратегиите за DR е да ги преведете в планове и процедури за възстановяване след бедствия. За да покаже как може да се направи това, таблица 1 е преработена в таблица 2, която следва.
Показва критични системи и свързаните с тях заплахи, стратегията за реакция и (новите) стъпки за действие за реакция, стратегията за възстановяване и (новите) стъпки за действие за възстановяване. Изпълнението на тази стъпка помага да се дефинират стъпки за действие на високо ниво, които са част от плана за DR.
Използвайте таблица 2, за да разширите стъпките за действие на високо ниво в подробни процедури стъпка по стъпка, ако е необходимо. Уверете се, че са свързани в правилната последователност.
Разработване на планове за DR
Плановете за възстановяване след бедствие предоставят стъпка по стъпка процес за реагиране на разрушително събитие.
Процедурите трябва да осигурят лесен за използване и повтарящ се процес за възстановяване на повредени ИТ активи и връщането им към нормална работа възможно най-бързо. Ако е необходимо преместване на персонала на горещ обект на трета страна или друго алтернативно пространство, трябва да се разработят процедури за тези дейности. Стъпките за използване на базирани в облак ресурси за архивиране трябва да бъдат разработени в координация с доставчика на облак, така че процедурите да се изпълняват в правилната последователност.
Помислете също така за преглед на глобалните стандарти ISO/IEC 24762 (Насоки за услуги за възстановяване след бедствия на информационните и комуникационните технологии) и ISO/IEC 27035 (Дейности за реакция при инциденти), когато разработвате планове за DR.
Реагиране при инциденти
В допълнение към използването на разработените по-рано стратегии, плановете за ИТ възстановяване след бедствие трябва също да включват процес за реагиране при инциденти (ISO/IEC 27035) за справяне с началните фази на инцидента и стъпките, които трябва да се предприемат.
Както е показано на Фигура 2, действията за реакция при инцидент трябва да предхождат действията за възстановяване след бедствие. Когато се използват облачни услуги, работете с доставчика, за да включите техните дейности за реакция при инцидент в плана за DR.
Забележка: Управлението при извънредни ситуации е включено във Фигура 2, тъй като представлява дейности, които може да са необходими за справяне със ситуации, при които хора са ранени, или ситуации като пожари, които трябва да бъдат решени от местните противопожарни екипи и други лица, реагиращи бързо.
Структурата на плана за DR
Следният раздел описва подробно рамката и компонентите за план за DR, базиран на ISO 27031 и ISO 24762.
Най-добрите в класа си планове за DR често започват със страница или две, които обобщават ключови стъпки за действие (например къде да се съберат служители, ако бъдат принудени да евакуират сградата) и списъци с ключови контакти (например облачни доставчици, алтернативни работни зони) и тяхната информация за контакт за по-лесно разрешаване и стартиране на плана.
Въведение
След първоначалните страници за спешни случаи плановете за DR имат въведение, което включва целта и обхвата на плана. Този раздел трябва да посочи кой е одобрил плана, кой е упълномощен да го активира и да включва списък с връзки към всички други подходящи планове и документи (например политики).
Роли и отговорности
Следващият раздел трябва да дефинира ролите и отговорностите на членовете на екипа за DR, техните данни за контакт, лимити на разходите (например, ако трябва да се закупи оборудване) и ограничения на техните правомощия в ситуация на бедствие. Когато се използват облачни услуги, същите тези параметри трябва да бъдат дефинирани за облачния доставчик.
Отговор при инцидент
Процесът за реакция при инцидент идентифицира внезапното присъствие на извъннормална ситуация (например, предупредена от различни аларми на системно ниво), бързо оценява ситуацията (и всички щети), за да направи ранно определяне на нейната тежест, опитва да ограничи инцидента и да го постави под контрол и уведомява ръководството, доставчиците на облачни услуги и други ключови заинтересовани страни.
Активиране на плана
Въз основа на констатациите от дейностите за реагиране при инциденти, следващата стъпка е да се определи дали трябва да бъдат стартирани планове за възстановяване след бедствие и кои от тях по-специално трябва да бъдат приложени. Тези дейности трябва да бъдат внимателно координирани с доставчиците на облачни услуги.
Ако трябва да се извикат планове за DR, дейностите за реакция при инцидент могат да бъдат намалени или прекратени, в зависимост от инцидента, което позволява стартирането на плановете за DR. Използването на облачен доставчик може също да помогне за намаляване на дейностите по реагиране на инциденти, тъй като облачният доставчик трябва да бъде активиран в началото на процеса.
Този раздел определя критериите за стартиране на плана, координиране с доставчика на облак, какви данни са необходими и кой взема решението.
В тази част от плана трябва да бъдат включени зони за събиране на персонала (основен и заместник), процедури за уведомяване и активиране на членовете на екипа за DR и доставчиците на облак и процедури за спиране на плана, ако ръководството определи, че отговорът на плана за DR не е необходими.
История на документа
Осигурете раздел, в който са изброени датите и ревизиите на документа на плана. Трябва да включва дати на ревизии, какво е ревизирано и кой е одобрил ревизиите. Намерете този раздел в предната част на плана.
Процедури
След като планът бъде стартиран и ако доставчиците на облак също са били уведомени, екипите за DR и екипите на доставчиците на облак продължават с дейностите по реагиране и възстановяване, както е посочено в плановете. Колкото по-подробен е планът, толкова по-вероятно е засегнатият ИТ актив да бъде възстановен и върнат към нормална работа.
От съществено значение е доставчикът(ите) на облак да знаят своите роли по време на инцидента. Подобрете плановете за DR със съответната информация за възстановяване и процедури, получени от доставчика(ите) на облак. Координирайте тясно с доставчиците на облак, докато разработвате планове за DR, за да сте сигурни, че имат документирани процедури за спешни случаи.
Приложения
Разположени в края на плана, те могат да включват системни инвентаризации, инвентаризации на приложения, инвентаризации на мрежови активи, договори и споразумения за ниво на услугата, данни за връзка с доставчика на облак (и друг доставчик) и всякаква допълнителна документация, която ще улесни възстановяването.
Следващи дейности
След като плановете за DR са завършени, те са готови за упражняване. Упражняването на планове за DR при използване на доставчик на облачна услуга е особено важно, тъй като доставчикът на облак ще носи отговорност за възстановяването на критични системи и данни. Този процес ще определи дали системите и данните могат да бъдат ефективно възстановени и върнати в експлоатация, както е планирано.
Успоредно с тези дейности има три допълнителни: повишаване на осведомеността на служителите, обучение на служителите и управление на записи. Те са от съществено значение, тъй като гарантират, че служителите са напълно запознати с плановете за DR и техните отговорности при бедствие, а членовете на екипа за DR и представителите на облачните услуги са обучени за техните роли и отговорности, както е определено в плановете.
И тъй като планирането на DR генерира значително количество документация, управлението на записите и дейностите по управление на промените също трябва да бъдат инициирани. Това е особено важно при използване на доставчик на облачни услуги и ще гарантира, че клиентите са напълно наясно какво трябва да прави доставчикът.
Получете възможно най-много документация на доставчика, за да сте в синхрон с техните дейности. Не забравяйте да координирате дейностите по управление на записите на компанията и управление на промените по време на планирането на DR.
Резюме
Тази статия демонстрира значението на разработването на стратегии за DR, особено когато се използват доставчици на облачни услуги, как да ги преведете в планове за DR и дейности за реагиране при инциденти и дефинира компонентите на план за DR и съдържанието, което всеки съдържа. Напълно дефинираните стратегии за DR, които се основават на множество фактори, особено когато работите с облачни доставчици, са от съществено значение при разработването на планове за възстановяване след бедствие.
