Ինչպես կատարել 152-FZ-ի պահանջները, պաշտպանել ձեր հաճախորդների անձնական տվյալները և չխոտորվել մեր փոցխի վրա  

Ռուսական օրենքների համաձայն՝ ցանկացած ընկերություն, որն աշխատում է Ռուսաստանում իր օգտատերերի անձնական տվյալների հետ, անկախ նրանից՝ ուզում է, թե ոչ, դառնում է անձնական տվյալների օպերատոր։ Սա նրան պարտադրում է մի շարք ֆորմալ և ընթացակարգային պարտավորություններ, որոնք ոչ ամեն մի բիզնես կարող է կամ ցանկանում է ինքնուրույն կրել:

Ինչպես ցույց է տալիս պրակտիկան, միանգամայն ճիշտ է, որ նա չի ցանկանում, քանի որ գիտելիքի այս ոլորտը դեռ այնքան նոր է և գործնականում փորձարկված չէ, որ դժվարություններ և հարցեր են ծագում նույնիսկ մասնագետների համար: Այսօր մենք կխոսենք այն մասին, թե ինչպես ենք իրականացրել մեր հաճախորդի համար անձնական տվյալների պահպանման նախագիծը և ինչ աննկատ դժվարությունների ենք հանդիպել:

Ինչպես մենք օգնեցինք պաշտպանել տվյալները 152-FZ-ի ներքո

2019 թվականի սկզբին մեզ հետ կապ հաստատեցին «Սմարթ-Սերվիս» ՍՊԸ-ն՝ ծառայությունների կառավարման հարթակի մշակող։ HubEx և կոնտակտների փոխանակման հավելվածներ myQRcards.
 
Առաջին լուծումը թույլ է տալիս ավտոմատացնել սարքավորումների սպասարկման գործընթացը տարբեր ոլորտներում` գրասենյակային տարածքներում սուրճի մեքենաների և օդորակիչների տեղադրումից մինչև գազատուրբինների վերանորոգում: Երկրորդը առցանց դիզայներ է՝ QR կոդերի հիման վրա էլեկտրոնային այցեքարտեր ստեղծելու համար։ 

Առցանց այցեքարտ myQRcards.

Երկու համակարգերն էլ պահպանում և մշակում են օգտագործողի տվյալները, որոնք պատկանում են «անձնական» դասակարգմանը` համաձայն 152-FZ-ի: Այս դեպքում օրենքը թելադրում է մի շարք սահմանափակումներ նման անձնական տվյալների պահպանման համակարգերի վրա՝ ապահովելու անվտանգության պահանջվող մակարդակը և բացառելու գողության կամ չարաշահման նպատակով չարտոնված մուտքի վտանգը:
 
Օրենքը պետք է պահպանվի, սակայն «Սմարթ Սերվիս»-ը չէր նախատեսում իր մեջ զարգացնել անձնական տվյալների պաշտպանության իրավասությունը։ Հետևաբար, նրանց օգտատերերի կողմից տրամադրված ծառայություններն ու տվյալները «տեղափոխվեցին» Linxdatacenter։ «Smart-Service»-ը փոխանցել է աշխատանքային միջավայրի սերվերի հզորությունը մեր տվյալների կենտրոնի առանձին պաշտպանված ցանցային գոտի, որը հավաստագրված է 152-FZ-ում նշված պահանջներին համապատասխան՝ այսպես կոչված «Ապահով ամպ»:
 

ԻՆՉՊԵ՞Ս Է ԿԱԶՄՎԱԾ ԱՆՎՏԱՆԳ ամպը:

Անձնական տվյալներ մշակող ցանկացած տեղեկատվական համակարգ պետք է համապատասխանի երեք հիմնական պահանջներին. 

• Տվյալների պահպանման և մշակման սերվերներին մուտքը պետք է իրականացվի VPN ալիքի միջոցով՝ ԳՕՍՏ-ի համաձայն կոդավորման միջոցով.
• տվյալների պահպանման և մշակման սերվերները պետք է մշտապես վերահսկվեն խոցելիության հակավիրուսային պաշտպանության միջոցով.
• Պահպանման համակարգը պետք է տեղակայված լինի մեկուսացված ցանցերում: 

Մենք տեղադրում ենք հաճախորդի սերվերի հզորությունները առանձին տարածքներում, որոնք համապատասխանում են 152-FZ-ի պահանջներին և օգնում են համապատասխանության վերաբերյալ եզրակացություն ստանալ:

Սմարթ Սերվիս ՍՊԸ-ի համար անվտանգ վիրտուալ ենթակառուցվածքի ճարտարապետություն.

Աշխատանքային առաջընթաց

Աշխատանքների նախնական հաստատումն իրականացվել է 2019 թվականի հունիսին, որը կարելի է համարել ծրագրի մեկնարկի ամսաթիվ։ Բոլոր աշխատանքները պետք է կատարվեն «կենդանի» միջավայրում՝ օրական հազարավոր խնդրանքներով: Բնականաբար, անհրաժեշտ էր նախագիծն ավարտին հասցնել՝ առանց երկու համակարգերի բնականոն գործունեությունը ընդհատելու։

Հետևաբար, կազմվել և համաձայնեցվել է գործողությունների հստակ ծրագիր՝ բաժանված 4 փուլերի.

• Նախապատրաստում,
• միգրացիան,
• փորձարկում և փորձարկում իրական պայմաններում,
• մոնիտորինգի համակարգերի և մուտքի սահմանափակումների հնարավորություն:

Ապահով լինելու համար մենք ներառել ենք Աղետների վերականգնման ընթացակարգ (DRP): Նախնական պլանի համաձայն՝ աշխատանքը շատ ժամանակ և ռեսուրսներ չի խլել և պետք է ավարտվեր 2019 թվականի հուլիսին։ Յուրաքանչյուր փուլ վերջում ներառում էր համակարգերի ցանցի հասանելիության և ֆունկցիոնալության ամբողջական փորձարկում։

Ամենադժվար փուլը, որտեղ «ինչ-որ բան կարող է սխալ լինել», միգրացիան էր: Սկզբում մենք նախատեսում էինք միգրացիան իրականացնել՝ փոխանցելով ամբողջ վիրտուալ մեքենաներ։ Սա ամենատրամաբանական տարբերակն էր, քանի որ այն չէր պահանջում լրացուցիչ ռեսուրսների ներգրավում վերակազմավորման համար: Թվում է, որ vMotion-ը կարող է ավելի պարզ լինել:
  

Անսպասելիորեն

Սակայն, ինչպես սովորաբար տեղի է ունենում համեմատաբար նոր ոլորտում նախագծերում, տեղի ունեցավ անսպասելի բան։

Քանի որ յուրաքանչյուր վիրտուալ մեքենա զբաղեցնում է 500 - 1 ԳԲ, նման ծավալների պատճենումը նույնիսկ մեկ տվյալների կենտրոնի ներսում տևում է մոտ 000-3 ժամ մեկ մեքենայի համար: Արդյունքում մենք չբավարարվեցինք հատկացված ժամանակային պատուհանին։ Դա տեղի է ունեցել vCloud-ին տվյալները փոխանցելիս սկավառակի ենթահամակարգի ֆիզիկական սահմանափակումների պատճառով:

Օգտագործված vCloud տարբերակի սխալը թույլ չի տվել Storage vMotion-ը կազմակերպել տարբեր տեսակի սկավառակներով վիրտուալ մեքենայի համար, ուստի սկավառակները պետք է փոխվեն: Արդյունքում հնարավոր եղավ փոխանցել վիրտուալ մեքենաները, սակայն նախատեսվածից ավելի երկար ժամանակ պահանջվեց։ 
 
Երկրորդ կետը, որը մենք չենք նախատեսել, տվյալների բազայի կլաստերի տեղափոխման սահմանափակումներն են (Failover Cluster MS SQLServer): Արդյունքում անհրաժեշտ եղավ կլաստերն անցնել մեկ հանգույցով աշխատելու և այն թողնել պահպանվող գոտուց դուրս։ 

Ուշագրավ է. դեռևս անհասկանալի պատճառով վիրտուալ մեքենաների տեղափոխման արդյունքում հավելվածների կլաստերը քանդվել է և ստիպված է եղել նորից հավաքել։

Առաջին փորձի արդյունքում մենք ստացանք համակարգերի անբավարար վիճակը և ստիպված եղանք նորից սկսել պլանավորել և մշակել տարբերակներ։
 

Փորձ թիվ 2

Սխալների վրա աշխատելուց հետո թիմը հասկացավ, որ ավելի ճիշտ կլինի կրկնօրինակել ենթակառուցվածքը պաշտպանված տարածքում և պատճենել միայն տվյալների ֆայլերը: Որոշվեց հաճախորդից չպահանջել հավելյալ վճարում սերվերի լրացուցիչ հզորության համար, որը պետք է տեղակայվեր միգրացիան ավարտելու համար:

Արդյունքում, երբ պահպանվող տարածքում գտնվող կլաստերներն ամբողջությամբ կրկնօրինակվեցին, միգրացիան անցավ առանց խնդիրների։

Հաջորդիվ անհրաժեշտ էր միայն առանձնացնել պահպանվող և անպաշտպան գոտիների ցանցերը։ Այստեղ մի քանի փոքր խափանումներ են եղել. Առանց որևէ պաշտպանության պաշտպանված տարածքում ամբողջ համակարգի փորձարկման փուլը կարողացավ սկսել նորմալ ռեժիմով։ Այս ռեժիմով համակարգի աշխատանքի վերաբերյալ դրական վիճակագրություն հավաքելով՝ մենք անցանք վերջին փուլին՝ պաշտպանական համակարգերի գործարկում և մուտքի սահմանափակում:
 

Արդյունավետ արդյունք և օգտակար դաս

 
Արդյունքում, հաճախորդի հետ համատեղ ջանքերով հնարավոր եղավ էական փոփոխություններ կատարել առկա սերվերային ենթակառուցվածքում, ինչը հնարավորություն տվեց բարձրացնել անձնական տվյալների պահպանման հուսալիությունն ու անվտանգությունը, զգալիորեն նվազեցնել դրանց չարտոնված մուտքի ռիսկերը և ձեռք բերեք պահեստավորման պահանջներին համապատասխանության վկայագիր. ձեռքբերում, որը ոչ բոլորն են դեռ հասել նմանատիպ ծրագրեր մշակողների համար:
 
Ներքևի տողն այն է, որ նախագծի աշխատանքային փաթեթն այսպիսի տեսք ուներ.
 

1. Կազմակերպվել է հատուկ ենթացանց;
2. Ընդհանուր առմամբ, տեղափոխվեցին երկու կլաստերներ՝ բաղկացած հինգ վիրտուալ մեքենաներից. Failover տվյալների բազայի կլաստեր (երկու վիրտուալ մեքենա), Service Fabric հավելվածների կլաստեր (երեք վիրտուալ մեքենաներ);
3. Տվյալների պաշտպանության և գաղտնագրման համակարգերը կազմաձևվել են:

Ամեն ինչ պարզ ու տրամաբանական է թվում։ Գործնականում ամեն ինչ մի փոքր ավելի բարդ է ստացվում։ Մենք ևս մեկ անգամ համոզվեցինք, որ նման պլանի յուրաքանչյուր առանձին առաջադրանքի հետ աշխատելիս անհրաժեշտ է ամենաբարձր ուշադրությունը «փոքր բաների» վրա, որոնք իրականում պարզվում են, որ ոչ թե փոքր բաներ են, այլ որոշիչ գործոնները հաջողության հասնելու համար: ամբողջ նախագիծը։ 

Source: www.habr.com