Өзгермейтін резервтік көшірмелер және WORM: қалпына келтіруді тексеру

Неліктен «қарапайым бэкап» көмектеспеуі мүмкін

Қарапайым бэкап жиі бір жорамалға негізделеді: деректер көшірілген болса, оларды қайтарып алуға болады. Шифрлаушы шабуылында бұл жорамал бұзылады. Қаскөйге қорғанысты «жеу» керек емес — қалпына келтіру мүмкін болмайтындай немесе тым баяу болатындай ету жеткілікті.

Шифрлаушы тек файлдарды шифрламайды. Жиі сценарий: ол әкімшілік құқықтарды алып, қорғаныс агенттерін өшіреді, журналдарды тазалайды, теневикті жояды, резервтік серверге жетіп, бэкаптарды шифрлайды немесе өшіреді. Кейде сақтау саясаттарын өзгертіп, ескі қалпына келтіру нүктелерінің ротациясын жылдамдатады. Көп жағдайларда бұл әрекеттер негізгі соққыдан бірнеше сағат немесе күн бұрын жасалады.

Мысал: бухгалтерия жалпы файл серверінде жұмыс істейді. Түнде желілік ресурска көшіру жасалады. Таңертең файлдар шифрланған, ал резервтік қалта да зиянданған, себебі ол сол есептік деректермен қолжетімді болған. Формальды түрде бэкап «бар», бірақ қалпына келтірер нәрсе жоқ.

Жоғалтулар тек тоқтамағандықтан ғана емес. Қалпына келтіру сәтсіз болғанда сіз «тірі» көшірмені іздеуге уақыт жоғалтасыз, авариялық жұмыстарға төлеу, мерзімдерді жылжыту және кейде деректердің ағуына байланысты шантажбен кездесесіз. Қалпына келтіруді жүйелі тексермейінше мәселені ең қолайсыз сәтте білесіз.

Тексеріңіз: сізде мынадай нақты жауаптар бар ма:

• көшірмелер қай жерде физикалық орналасқан және оларды кім өшіруі немесе қайта жазуы мүмкін;
• жазылғаннан кейін өзгертілмейтін көшірме бар ма (мысалы, иммутебелді);
• домен әкімшісінің есептік жазбасы бұзылғанда не болады;
• соңғы рет қашан тесттік көшірмені көтеріп, нақты файлдар мен дерекқорды ашқаныңыз;
• қалпына келтіру үшін қанша сағат күте аласыз және қанша деректі жоғалтуға дайынсыз.

Егер бұл сұрақтарға нақты жауаптар жоқ болса, «қарапайым бэкап» әдетте қорғаныс емес, жай ғана әдет болып қалады.

Иммутебелдік пен WORM: мәні неде

Иммутебелдік — бұл резервтік көшірмені алдын ала белгіленген мерзімге дейін өзгертуге немесе жоюға болмайтын қасиет. Әкімшілік есептер ұрланған жағдайда да шабуылшы архивті «тазалай» алмайды. Сондықтан иммутебелді көшірмелер шифрлаушы шабуылында соңғы қорғаныс қоры болуы жиі кездеседі.

WORM — Write Once, Read Many дегенді білдіреді: «бір рет жазып, көп рет оқисың». Негізінде бұл сақтау деңгейінде иммутебелдіктің практикалық формасы: деректер жазылады және оқуға ашық күйінде қалады, қайта жазуға болмайды. Маңызды: WORM — бренд атауы емес және «ерекше бэкап түрі» емес, сақтаудың қатал режимі.

Аралық түсінбеушілік көбінесе ұқсас терминдерден туындайды:

• Read-only (тек оқу) папка немесе желілік ресурс баптауы алынып тасталуы мүмкін. Егер шабуылшы құқықтарды алса, ол бұл шектеуді алып тастап, көшірмелерді жояды.
• Офлайн-көшірме (мысалы, сейфтегі диск) көмектеседі, бірақ бұл иммутебелдік емес. Оның әлсіз жағы — адам факторы: оны ажыратуды ұмыту, «бір минутқа» қосуды адам қатесі немесе сақтау орнының жақындығы.

Шынайы қорғаныс міндетті және тексерілетін кезде басталады: retention мерзімі қойылған, оны бөлек рөл немесе процедурасыз өзгертуге болмайды және жою әрекеттері тіркеледі.

Қарапайым мысал: бухгалтерия көшірмелерді 30 күн сақтайды. Иммутебел режимде тіпті әкімші, чья учеткіі ұрланған болса да, кеше жазылған архивті жоя алмайды. Ол тек күтуге мәжбүр болады, ал сізге әдетте қалпына келтіруге жеткілікті уақыт беріледі.

Шифрлаушылар бэкапты қалай айналып өтеді

Шифрлаушы әдетте екі кезеңмен әрекет етеді: алдымен ортаға бақылау алып, кейін сізді кері оралу мүмкіндігінен айырады. Сондықтан «қарапайым бэкап» жиі көмектеспейді, егер ол жұмыс деректерімен бірдей құқықтар мен жолдармен қолжетімді болса.

Қаскөйлер көбінесе қайда көшірмелер екенін «жасырмайды»: олар әдеттегідей әкімшілер секілді белгілі жолдар, желілік ресурс атаулары, орнатылған бэкап агенттері мен консольдегі қолжетімді сақтау орындарын іздейді. Мақсат — қалпына келтіру нүктелерін жою, бэкап қызметтерін тоқтату, репозиторийлерді шифрлау немесе каталогты бұзып, қалпына келтіруді ұзақ әрі ауыр ету.

Арнайы қауіп — әкімші құқықтары мен жалпы есептік жазбалар. Егер бэкап домендік әкімшіден жұмыс істесе немесе бір құпиясөз бәрі үшін қолданылса, бір тіркелгіні бұзу шабуылшыға деректерге да, бэкапқа да қолжетімділік береді.

Бэкаптарды сол домен ортасында сақтау мәселені күшейтеді. Қайта қалпына келтіру репозиторы, басқару сервері және есептік жазбалар бір доменге байланған кезде домен контроллеріне шабуыл көшірмелерді жоюға мүмкіндік береді.

Мұнда маңызды қорғаныс механизмі — сақтау мерзімі (retention). Бұл — көшірмені жою немесе өзгертуге болмайтын кезең, тіпті шабуылшы әкімші құқықтарына ие болса да. Иммутебелдік пен WORM «уақыттық құлып» қосады, ол жұқтырылған ортадан шыққан командалармен ашылмайды.

Тексеруге тұратын осалдық белгілері:

• бэкап-репозиторий кәдімгі желілік папка секілді көрінеді;
• қалпына келтіру нүктелерін домен әкімшілігінен өшіруге болады;
• бір аккаунт прод пен көшірмелерге бірдей қолжетімді;
• оқшауланған сақтау аймағы жоқ;
• retention қысқартуға немесе өшіруге «бір басу» жеткілікті.

Негізгі схема: 3-2-1-1-0 қарапайым тілде

3-2-1-1-0 ережесі — бұл деректерді сақтау жөніндегі есте сақтағыш: бұзылу, адам қатесі және шабуылға төтеп беру үшін көшірмелерді қалай ұстау керек.

• 3 көшірме: жұмыс және тағы екі резерв;
• 2 әртүрлі носитель/сақтау орны: мысалы, локалдық сақтау және бөлек репозиторий;
• 1 көшірме негізгі алаңнан тыс: өрт, су тасқыны немесе жалпы апат кезінде бәрін жоғалтпау үшін;
• 1 өзгермейтін көшірме: иммутебелді (WORM), оны сақтау мерзімі аяқталғанға дейін қайта жазуға немесе жоюға болмайды;
• 0 қалпына келтіру қателері: қалпына келтірудің жұмыс істейтінін жүйелі түрде тексеру.

Схемадағы өзгермейтін көшірме — соңғы шеп. Егер шифрлаушы кәдімгі бэкапқа жетсе, ол жиі оны да өшіруге немесе шифрлауға тырысады. WORM жазылған қалпына келтіру нүктелерін сақтау мерзімі аяқталғанша жоюға мүмкіндік бермейді.

Сонымен қатар желі мен есептік жазбалар бойынша «разрывты» ойластыру қажет. Бұл, егер шабуылшы доменге немесе бэкап әкімшісінің есептік жазбасына енсе, қосымша қорғаныс береді. Минимум — бэкап үшін бөлек есептік жазбалар және сақтау орындарына бөлек қолжетімділік.

Сақтау мерзімін міндетті түрде «барға қалдырып қоймаңыз»: оны кездейсоқ емес, қажеттікке қарай таңдаңыз — қанша «ескі» таза нұсқа қажет болуы мүмкін. Көбінесе иммутебелді көшірме үшін 14–30 күннен бастайды және тестілеу нәтижелері мен тәуекел бағалауынан кейін түзетеді.

WORM-хранилищалардың түрлері және қайда жарайды

WORM — Write Once Read Many — деректерді бір рет жазып, сақтау мерзіміне дейін өзгертуге немесе жоюға болмайтынын білдіреді. Бұл прод ортасымен бірдей күйде тұрған көшірмелер жағдайынан түбегейлі өзгеше: онда зиянды бағдарлама да солай өшіріп-жоя алады. WORM-тің мәні — шабуылшының «өткенді қайта жазу» техникалық мүмкіндігін жою.

Негізгі тәсілдер әдетте үш түрге бөлінеді:

• Объектілік сақтау immutability режимімен (Object Lock сияқты). Үлкен көлемдер мен ұзақ мерзімдер үшін ыңғайлы, таралған көшірмелер үшін қолайлы. Қауіп — баптауларда: кең құқықтар немесе «жұмсақ» режим қорғауды формальдық қана етеді.
• СХД деңгейіндегі WORM: өзгермейтін snapshot немесе СХД-де қорғалған аймақ. Қалпына келтіру жылдамдығы мен виртуализация үшін ыңғайлы. Минусы — қымбатырақ және нақты платформаға байланған.
• Лента (LTO, соның ішінде WORM-лента). Қол жетімі баяу, бірақ «ауа саңылауы» мен ұзақ мерзімді архив үшін өте тиімді. Кемшіліктері — логистика, көшіру терезелері және сақтау тәртібі.

Деректер көлемі мен өсімі тікелей әсер етеді. Деректер тез өссе, тек терабайт құны ғана емес, версияларды сақтау (retention), жазуға кететін трафик және қалпына келтіру уақытының құны да есептеледі. Үлкен дерекқорлар мен ВМ-ге жылдам қабат (СХД немесе объектілік) таңдап, лентаны ең «өшіру мүмкін емес» көшірмелер үшін қалдыру жиі кездеседі.

Қадағалау мен тексеру қажет ұйымдарда әдетте рөлдерді бөлу (саясатты орнататын кім, қалпына келтіруді орындайтын кім), әрекеттерді журналдау, неизменяемые retention саясаты және аудит мүмкіндігі қажет. Практикада WORM-пен қатар қолжетімділік ережелері мен тұрақты тексерулер қажет болады.

Иммутебелді көшірмелерді орнату: қадам-қадам

Иммутебелді көшірмелер қалыпты бэкаптан сол жағынан өзгеше — олар жазылып болғаннан кейін тыныш түрде қайта жазыла алмайды немесе жойыла алмайды, тіпті шабуылшы инфрақұрылымның бір бөлігін ұрласа да. Бірақ иммутебелдік рөлдер, құқықтар және retention дұрыс орнатылғанда ғана жұмыс істейді.

Бастысы — есептік жазбалардан бастаңыз. Бэкап әкімшісі домен әкімшісімен бір адам немесе бірдей аккаунт болмауы керек. Бэкап басқаруға және домен басқаруға бөлек есептік жазбалар жасаңыз, оларға минималды құқық беріңіз. Сонда бір рөлдің компрометациясы бәрін бірден ашпайды.

Сосын everywhere MFA қосыңыз: бэкап консоліне, сақтау қатынастарына, бұлттық кабинетке (бар болса). Сақтауға бөлек парольдер мен кілттер орнатыңыз, домендікпен сәйкес келмейтін. Көпші қатесі — барлық құпияларды бір жерде және бірдей құқықпен ұстау.

Келесі қадам — immutability қосып, retention мерзімін бекітіңіз және оны артқа қайтаруға болмайтын етіп орнатыңыз. Міндетті түрде тексеріңіз: бэкап әкімшісі көшірмені мерзімінен бұрын өшіре ала ма немесе саясатты өзгерте ала ма. Егер аласа, бұл шифрлаушылардан қорғаныс емес, жай ыңғайлы опция ғана.

Басқару нүктесін ойластырыңыз. Бэкап консолін бөлек желі сегментіне шығарып, рұқсат етілген құрылғылар тізімімен шектеңіз және артық протоколдарды алып тастаңыз. Егер жергілікті жерде орналастырып жатсаңыз, сенімді серверлер мен бөлек басқарылатын желілерді ескеріңіз.

Ақырында — есеп және бақылау. Саясаттар, retention, есептік жазбалар мен құқықтар өзгерістерін журналдаңыз. Тұрақты есептер орнатыңыз, ал критикалық өзгерістер үшін жеке хабарландырулар жасаңыз.

Қысқа өз-өзін тексеру тізімі:

• домен, бэкап және сақтау үшін бөлек аккаунттар бар ма;
• негізгі нүктелерде MFA қосылған ба;
• retention орнатылған және көшірмені мерзімінен бұрын жою мүмкін емес пе;
• бэкап консолі оқшауланған және шектеулі қолжетімді;
• саясаттар мен өзгерістердің журналдары шын мәнінде қаралып отыра ма.

Қалпына келтірудің шынайы тексерісі қалай жүргізіледі

Бэкапты сенімді ететін нәрсе — ол «сәтті аяқталды» деп емес, сіз деректерді қалпына келтіріп, оларды жұмыс істеп тұрғанын көрген кезде. Иммутебелдік жоюдан қорғайды, бірақ көшірме толық па, бүлінбеген бе және сіздің тапсырмаңызға сәйкес келіп пе — бұл басқа мәселе.

Тексеру кезінде нені қалпына келтіру керек

Тексеруді жеңілден күрделіге қарай өткізіңіз. Алдымен жылдам бөліктерден бастап, содан соң «тұрақты» сценарийлерге өтіңіз. Алдын ала бірнеше типтік объект таңдаған ыңғайлы:

• маңызды файлдар папкалары (шарттар, есептер, сканерлер) және олардың құқықтары;
• бір дерекқор: көтеріп, кіруді тексеріп, бірнеше сұрау орындаңыз;
• бір виртуалды машина: іске қосу, желі, кіру, негізгі қызметтер;
• «алған соңғы сәт» бойынша қалпына келтіру: қажетті уақыт нүктесіне дейін кері қайту мүмкіндігі.

«Жол бойында есімізге түсіріп аламыз» деп сенбеу. Қолжетімді есептік жазбалар, MFA, сақтау кілттері, шифрлау кілттері, лицензиялар мен нақты нұсқаулықтар болуын тексеріңіз. Инцидент кезінде жиі бір құпияны бір адам ғана біледі екені шыға келеді.

Қай жиілік пен кім қатысуы керек

Ұсыныс: ірі объектілер (ВМ, дерекқор) үшін тоқсанына бір рет, файлдар үшін айына бір рет. Маңызды: тек әкімшілер ғана емес, жүйенің иелері (мысалы, 1С үшін бухгалтерия, CRM үшін сату бөлімі) қатысуы тиіс. Олар «деректер ашылып, жұмыс істейді» деп растайды.

Әр тесттен кейін қысқа хаттама қалдырыңыз: қанша уақыт кеткен, тар жерлер қайда, қандай қателіктер шықты, не жетпеді, кім орындады және қандай нұсқаулық бойынша. Егер протоколда нақты сандар және қайталанатын жоспар болса, сізде қалпына келтірудің шын түрде мүмкін екеніне дәлел болады.

Қалпына келтіруге реалистік мақсаттар: RPO және RTO

RPO мен RTO — ИТ аббревиатурасы, мағынасы қарапайым: бизнес қанша ауыртпалықты көтере алады.

RPO (Recovery Point Objective) — қанша уақытқа дейінгі мәліметті жоғалтуды қабылдайсыз. Мысалы, RPO = 4 сағат болса, инциденттен кейін максимум 4 сағатқа дейінгі деректерді жоғалту рұқсат етіледі.

RTO (Recovery Time Objective) — сервис қанша уақытта қайта жұмыс істеуі тиіс. Мысалы, RTO = 2 сағат болса, тоқтау 2 сағаттан артық болмауы керек.

Мақсаттарды бизнеске қатысты зиянды талқылай отырып келісіңіз, технология емес. Бухгалтерия үшін төлемдерді бүгін жүргізу маңызды болуы мүмкін, ал ішкі оқу порталы ертең қалпына келсе де жарайды. Иммутебелдік деректерді жоюдан қорғайды, бірақ қалпына келтіру уақытын қысқартпайды — бұл ресурстар мен әрекет тәртібі туралы.

Сұрақтар:

• қай сервис тоқтаса бизнеске дереу шығын келтіреді (касса, төлемдер, пошта);
• қолмен қалпына келтіру арқылы қанша сағаттық деректі қалпына келтіруге болады;
• не маңыздырақ: тезірек қандай да бір түрде қалпына келтіру ме, әлде барлығын толық қайтара отырып кейінірек қалпына келтіру ме;
• мақсаттар орындалмаса кім шешім қабылдайды.

Егер тесттер тым ұзақ болса, тар жер жиі бэкап емес, оқу жылдамдығы, желі немесе есептеу қуатында болады. Қалпына келтірудің нақты жылдамдығын (ГБ/мин), авариялық желі өткізу қабілетін және жерді (CPU/RAM/IOPS) тексеріңіз.

Қалпына келтіру тәртібін алдын ала анықтаңыз, әйтпесе «темірді» көтеріп қойсаңыз да бизнес бұдан пайда көрмеуі мүмкін. Минималды тәртіп:

• есептік жазбалар және қолжетімділіктер (AD/LDAP, DNS);
• желі және виртуализация;
• дерекқорлар;
• қолданбалы сервисдер;
• жұмыс орындары және екінші деңгейлі жүйелер.

Осылайша RPO мен RTO уәде емес, тексерілетін жоспарға айналады.

Сенімді резервтік көшірмелер үшін жылдам чек-лист

Сенімді бэкап — «дискідегі файл» емес. Бұл қателіктен және шабуылдан аман қалатындай баптаулар мен әдеттер жиынтығы.

Тексеріңіз:

• иммутебелдік шынымен қосылған, retention алдын ала орнатылған (мысалы, 14–30 күн) және әдеттегі әкімші оны қысқарта алмайды;
• бэкап үшін бөлек есептік жазбалар бар: біреуі жазу үшін, екіншісі оқу мен қалпына келтіру үшін; құқықтар минималды, парольдер мен кілттер қайта қолданылмайды;
• кем дегенде бір көшірме физикалық немесе логикалық түрде негізгі желіден бөлінген (air gap): жоспарлы түрде алатын тасымалды сақтау немесе бөлек контур;
• тесттік қалпына келтіру тұрақты түрде (кемінде айына бір рет) өткізіліп, не қалпына келтіргеніңіз, қанша уақыт алғаныңыз, қандай мәселелер болғаны жазылады;
• мониторинг апат күні проблемалар туралы хабарлайды: сәтсіз іске қосу, өткізілу терезесінің өткізіп жіберілуі, деректер көлемінің күрт төмендеуі, оқу қатесі.

Минимальды практикалық тексеріс: бір маңызды сервис (мысалы, бухгалтерия немесе файл сервері) таңдап, оны бөлек папкаға не тесттік ВМ-ге қалпына келтіріп, бірнеше нақты құжат ашыңыз. Құқықтар да қалпына келді ме, уақыт шегінде бе — соны тексеріңіз.

Типтік қателіктер және тұзақтар

Ең көп кездесетіні — кез келген көшірме қорғаныс береді деп ойлау. «Қарапайым бэкап» көбіне прод ортасында өмір сүреді, сондықтан шифрлаушы оған да сол есептік жазбалар арқылы жетеді. Иммутебелдік тек қана айналма жолдар қалмайтындай етіп бапталған кезде ғана қорғайды.

Бірінші тұзақ — сол жүйедегі snapshot-тар. Snapshot жылдам кері оралу үшін ыңғайлы, бірақ егер шабуылшы сақтау жүйесін немесе гипервизорды басқарса, ол snapshot-тарды да өшіреді. Шифрлаушылардан қорғану үшін бөлек контур мен бөлек жою ережелері қажет.

Екінші — кілттер мен парольдердің «қолдау үстінде» болуы. Қашан бэкапқа қатынас токендері әкімшінің жұмысшы ПКсында болса, сол ПК жұқсатылғанда бэкап толықтай бұзыла алады.

Үшінші — « ыңғайлылық үшін өшіру ». Көшірмелерді бір батырмамен тазалау мүмкіндігі әдетте шабуылшыға да сол мүмкіндік береді. Иммутебелдік саясат болу керек, опция емес.

Төртінші — есептерге сену. Бэкап тапсырмасының «сәтті» аяқталуы қалпына келтіре алатыныңызды білдірмейді. Көшірме бүлінген, толық емес немесе бұрыннан шифрланған болуы мүмкін.

Бесінші — әкімшілікті бір жерде ұстау. Егер прод пен бэкап сервері бір доменнен және бір панельден басқарылса, бұл шабуылшыға бір ғана «шығу жолын» береді. Бөлек сервер немесе бөлек контур қауіптің дәрежесін төмендетеді.

Жылдам белгілер, бәрі дұрыс екенін көрсететіндер:

• бэкаптардың бөлек есептік жазбалары мен MFA, кілттер жұмыс десктоптарында сақталмайды;
• көшірмелерді retention мерзімінен бұрын интерфейс немесе API арқылы жоюға болмайды;
• бэкап пен прод әкімшілігі бөлек (әртүрлі рөлдер, түрлі есептік жазбалар, мүмкін болса түрлі домендер);
• аптасына немесе айына бір рет «таза ортада» тест қалпына келтіру өткізіледі;
• қандай нәрсені қалпына келтіру, кім орындайтыны және қанша уақыт алатыны құжатталған.

Қарапайым шабуыл сценариі және қалпына келтіру практикасында

Жұма, 18:40. Бухгалтерия айды жапты, барлық файлдар файл серверінде тұр. Қызметкер «есеп-жазба» хатындағы фишинг формасына есептік деректерін енгізіп, шабуылшы қолжетімділік алады. Бір сағат ішінде сервер мен бірнеше жұмыс станциясында шифрлаушы белсенді: құжаттар атауларын өзгертеді, тек ақшалай төлем арқылы ашылады.

Егер резервтік көшіру «қарапайым» болса, жағымсыз сюрприз жиі бэкаптардың да қауіп астында екенін көрсетеді. Әкімшінің тіркелгісі немесе қызметтік есептік жазба бұзылғанда шифрлаушы қалпына келтіру нүктелерін жоя алады, репозиторийді әдеттегі желілік папка сияқты шифрлай алады және сақтау саясатын өзгертіп, «тазалық» нұсқалардың жоғалуын тездетеді.

Иммутебелді көшірмелер мен WORM бұл сценарийді бұзады. Шабуылшы серверге жетсе де, жазылған көшірмелерді сақтау мерзімі аяқталғанша өшіруге немесе қайта жазуға мүмкіндік алмайды. Қосымша бөлінген құқықтар көмектеседі: бір есептік жазба бэкап жазады, басқа есептік жазба ( бөлек MFA пен жою құқығы жоқ) әкімшілік және қалпына келтіру үшін жауапты.

Қалпына келтірудің практикалық қадамдары:

1. Оқшаулау: жұқтырылған машиналарды желіден ажыратып, шифрлауды тоқтатады;
2. Нүктені таңдау: шабуылдан бұрынғы соңғы «таза» көшірмені табу (мысалы, жұма 16:00);
3. Ортаны құру: жаңа файл серверін (немесе таза ВМ) орналастырып, қолжетімділіктерді қосу;
4. Деректерді қалпына келтіру: бухгалтерия папкаларын, содан соң ортақ шерлерді қайтару;
5. Бақылау: файлдарды таңдап ашып, құқықтар мен журналдарды тексеру.

Уақыт бойынша бұл әдетте бірнеше сағатты алады, күндер емес: серверді көтеру 30–90 минут алуы мүмкін, ал деректер қайтару жылдамдығы көлемге байланысты. Маңыздысы — жоспар мен қолжетімділіктер алдын ала дайын болу; әйтпесе WORM берген артықшылық ұйымдық кідірістерде азаяды.

Келесі қадамдар: жоспар жинау және инфрақұрылым таңдау

Нені нақты қорғайтыныңызды бекітіңіз: критикалық сервистер (1С, пошта, файлдар, дерекқорлар), олар қайда орналасқан және қалпына келтіруге кім жауапты. Осы анықтама болмаса, иммутебелдік формальдық белгіше болып қалуы мүмкін.

Кішігірім міндеттер үшін жергілікті сервер мен дисктік стойка жеткілікті болуы мүмкін: тез қалпына келтіру, анық шығын және компания ішінде қолжетімді бақылау. Бірақ бір алаң өрт, ұрлық немесе әкімші құқықтары компрометацияланған жағдайда бәрінен сақтай алмайды.

Практикалық ереже: деректер маңызды және көлемі өссе — бэкапқа бөлек сервер және көшірмелерге бөлек сақтау орнын орнатыңыз. Бұл бір түйіннің компрометациясы бәрін «жұлмауын» азайтады.

Инфрақұрылымды таңдау жоспары әдетте мына қадамдардан тұрады: 2–3 негізгі жүйеге RPO/RTO анықтау, қай жерде «жылдам» қалпына келтіру болатынын (локал) және қай жерде «қозғалмайтын» көшірме (WORM) болатынын таңдау, есептік жазбалар мен құқықтарды бөлу, қалпына келтіру тесттері кестесін келісу және нәтижелерді тіркеу тәртібін белгілеу.

Системалық интегратор тек жабдық ұсынумен ғана емес, қолжетімділіктерді, сегментацияны, журналдауды жобалап, тұрақты тесттерді енгізіп, оларды кейінге қалдырмауға көмектеседі.

Егер осындай схемаға негіз керек болса, GSE.kz (gse.kz) S200 серверлерін ұсынып, жүйелік интеграция мен эксплуатация қолдауын қамтамасыз етеді. Бұл — жай ғана құрал сатып алу емес, қалпына келтіруді шын мәнінде тексерілген және қайталанатын күйге келтіру үшін шешімдер.