RDS CAL және VDI лицензиялау: IT үшін сұрақтар чек-листі

Неліктен RDS пен VDI алдында чек-лист керек

RDS CAL және VDI лицензиялау көбінесе қаржыға, деректерге қолжетімділік пен жауапкершілікке байланысты. Алдын ала келісілмеген чек-лист болмаған жағдайда артық лицензияға ақша жұмсап қоюға немесе керісінше — лицензия жетіспеушілігіне байланысты жұмыстың тоқтауына тап болуыңыз мүмкін, мысалы ішкі аудит кезінде немесе тексеруде.

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

Жоба әдетте үш жерде "сұйылып" кетеді: шешімнің иесі жоқ, пайдаланушылар мен құрылғылардың айқын есебі жоқ және кім қалай қолжетімдікті бақылайтыны туралы бір жауап жоқ. Нәтижесінде ИТ өнімділікті жоспарлайды, сатып алу бюджетті есептейді, ал ИБ тек іске қосқаннан кейін ғана бөлшектер туралы біледі.

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

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

Төменде жоба моделін таңбас бұрын, сатып алуды бастамас бұрын ИТ пен ИБ-ке қоюға болатын сұрақтар тізімі бар, сонда шешім заңды, басқарылатын және шығындар бойынша болжамды болады.

Негізгі түсініктер қарапайым тілмен

RDS (Remote Desktop Services) — Windows Server рөлі, ол адамдарға серверде қашықтан қосылып, қосымшалар мен жұмыс үстелімен жұмыс істеуге мүмкіндік береді.

RDP (Remote Desktop Protocol) — қосылу үшін қолданылатын протокол.

Терминал сессиясы — сервердегі жеке жұмыс сеансы: өз тіркелгіңізбен кіріп, қосымшаларды іске қосып, файлдарды сақтап, шығасыз.

CAL (Client Access License) жиі "Windows Server лицензиясымен" шатастырылады, бірақ бұл екі түрлі нәрсе. Windows Server лицензиясы серверді іске қосуға құқық береді. Ал RDS CAL пайдаланушыға немесе құрылғыға RDS арқылы қосылуға және терминал сессиясында жұмыс істеуге құқық береді. Сондықтан жоспарлағанда серверлермен бірге оларға қосылатындарды да есептеу маңызды.

VDI (Virtual Desktop Infrastructure) — әрбір пайдаланушыға жеке виртуалдық ПК (виртуалдық машина) берілетін тәсіл. RDS-та пайдаланушылар әдетте бір серверді бөліседі (әр түрлі сессиялар — бір аппарат пен ОС). VDI оқшаулануды және икемділікті ұсынады (әртүрлі бейнелер мен баптаулар), бірақ әдетте инфрақұрылым мен әкімшілендіру талаптары жоғары.

Практикада бірнеше типтік қолжетімділік нұсқалары жиі кездеседі, әрі одан кейінгі лицензиялау сұрақтары соларға байланысты:

• жалпы терминал сервер: көп пайдаланушы бір немесе бірнеше серверде сессияларда жұмыс істейді;
• VDI: бір пайдаланушы — бір ВМ;
• офис ПК/ноутбуктан қосылу: нақты қанша адам және қанша құрылғы қосылатыны маңызды;
• "жеңіл" жұмыс орындарынан (тонкий клиенттер, ескі ПК, мини-ПК) қосылу: көбіне құрылғы бойынша есептеледі және кіруді басқару алдын ала ойластырылуы керек.

Мысал: бухгалтерия 1С арқылы жалпы терминал серверде жұмыс істейді, ал кейбір бөлімдерге оқшауланған VDI қажет. Сырттан қарағанда бұл бірдей көрінуі мүмкін ("RDP арқылы қосылды"), бірақ ішкі жағынан қауіпсіздік, жүктеме және лицензиялар әр түрлі есептеледі.

Бастапқы деректерді жинау: қадамдық жоспар

Лицензиялауды болжамай, алдымен фактілер жинаңыз. Оңайырақ — барлығын бір кестеге түсіріп, кім қосылатынын, қайдан, қандай құрылғылардан және қандай ресурстарға қолжетімділік болатынын көрсету.

1. Қашықтан қолжетімді болатын нақты заттарды инвентаризациялаудан бастаңыз. Бұл "жалпы терминал сервер" емес, нақты қосымшалар (1С, МИС, CAD, браузерлік жүйелер), деректер түрлері (жеке, қаржылық, медициналық) және операциялар (тек қарау ма әлде басып шығару, файлды шығару, USB-пен жұмыс істеу) болуы керек.

2. Содан соң сандар мен рөлдерге келіңіз:

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

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

4. ИБ талаптары мен ішкі ережелерді келісіңіз: журналдау, логтарды сақтау, көшіруге тыйым салу, реттеуші талаптар мен аудит талаптары.

Кішкентай мысал: медициналық ұйымда 120 қызметкер 2 сменада жұмыс істейді, бірақ бір уақытта максимум 45 қосылады. Кейбір дәрігерлер бөлімшелерден ноутбуктармен қосылады, ал мердігер айына бір рет жаңарту жасайды. Егер мұның бәрін дереу жазып қоймасаңыз, per user/per device таңдауында және қолжетімділік ережелерінде қателесуге болады.

Егер сізде филиалдары таралған және аралас пайдаланушылар болса, жүйелік интегратор жиі дәл осындай "қолжетімділік картасынан" бастайды. Ол сатып алуды, қолжетімділік бақылауын баптауды және кейінгі аудитті жеңілдетеді. Қазақстанда осындай жобаларды, соның ішінде серверлер мен жұмыс орындарын таңдау, GSE.kz орындайды.

Per user немесе per device: дұрыс таңдау үшін сұрақтар

Per user және per device арасындағы таңдау қарапайым көрінуі мүмкін, бірақ адамдарды, құрылғыларды және нақты сценарийлерді есептей бастаған кезде күрделене түседі. Мұндағы қате әдетте артық шығынға немесе қолжетімділіктің "бар сияқты" болып, лицензиялау тұрғысынан мәселелі болуына әкеледі.

Алдымен масштабты анықтаңыз: әдетті ай ішінде терминал қолжетімділігіне қанша бірегей қызметкер қосылады және жылына қанша. Жылдық көрсеткіш көбіне маңызды, әсіресе уақытша жобалар, тағылымдамашылар немесе кезеңдік қосылымдар болса.

Содан кейін "құрылғылар картасын" қараңыз. Бір адам офис ПК-дан, ноутбуктан және үйден кез-келген уақытта қосыла алады. Мұндай жағдайда per user әдетте түсінікті әрі басқаруға оңай. Ал көпшілік ортада — сменалы орындар, регистратура, сынып, call-орталық — бір ПК-да бірнеше адам жұмыс істейтін болса, per device табиғи көрінеді.

Шешімді ойланбай қабылдамау үшін бірнеше нақты сұрақ қойыңыз:

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

Мысал: поликлиникада 40 қызметкер бар. 15 дәрігер кабинеттен және үйден қосылады, ал регистратурада 10 жұмыс орны 2 сменада (20 адам) жұмыс істейді. Көбінесе аралас картина шығады: дәрігерлерге per user ыңғайлы, регистратураға — per device. Бұл аралас тәсілге рұқсат бересіз бе және аудитте қалай есепке алатыныңызды алдын ала келісу керек екенін көрсетеді.

Сыртқы мердігерлер мен уақытша қолжетімділік

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

Бірінші шешім: мердігер өз есімімен жұмыс істейді ме әлде "қызметкер ретінде" ме? Практикалық шешім — мердігерге бөлек тіркелгі беру, ол нақты келісімге, жобаға және сіздің ішкі байланыс тұлғаңызға байланған болуы тиіс.

Содан кейін қолжетімділік шекарасын нақтылаңыз. Уақытша қолжетімділік тек мерзіммен шектелмейді, сонымен қатар қандай жүйелерге, қандай рөлдерге және қандай әрекеттерге рұқсат берілетінімен шектелуі керек. Егер мердігер серверлер мен жұмыс орындарын қызмет көрсетсе, оған көбінесе тек басқару консольдеріне немесе белгілі бір серверлер тобына қолжетімділік жеткілікті болады, "толық" терминал ортасына емес.

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

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

Мысал: мердігер айына бір рет бірнеше серверде бағдарламалық қамтамасыз етуді жаңартады. Оған осы серверлерге ғана 24 сағатқа берілетін бөлек тіркелгі беріледі, келісілген терезеде және әрекеттер журналға міндетті жазылады. Егер қосылу қажет болмаса, рұқсат мерзімі аяқталған соң автоматты түрде жабылады.

Терминал қолжетімділік сценарийлері және қайда VDI жиі таңдалады

RDS пен VDI арасындағы таңдау әдетте "әдеттен" емес, адамдардың қалай жұмыс істейтініне байланысты: пайдаланушылар саны, қосымшалар, рөлдердің өзгеруі және мәліметтерге қойылатын талаптар.

Сценарий 1: кеңсе тапсырмалары үшін жалпы терминал сервер

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

Басына қосылу тәртібін: per user ме әлде per device ме — алдын ала шешіңіз. Сондай-ақ жеке ноутбуктар мен тонкий клиенттерден кіруге рұқсат бар ма — оны да дереу бекітіңіз. Олай етпесеңіз, лицензиялар бойынша есептер шындықтан алшақ болады.

Сценарий 2: рөлдерге бөлінген бөлінген жұмыс үстелдері (VDI)

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

Тұрақты (persistent) және тұрақсыз (non-persistent) жұмыс үстелдері бар. Біріншісі жеке ПК-ға ұқсап, баптаулар сақталады, бірақ қолдау күрделірек. Екіншісі жаңартуға оңай, бірақ пайдаланушы деректері мен профильдерінің қайда сақталатынын ойластыру қажет.

Модель таңдамас бұрын бірнеше сұраққа жауап беріңіз:

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

Сценарий 3: толық жұмыс үстелі орнына бір қолданбаға қолжетімділік

Кейде толық жұмыс үстелі орнына бір қолданбаны жариялау тиімдірек. Бұл артық әрекеттерді шектеуге және буфер, локальді диск немесе принтер арқылы деректер ағуын азайтуға көмектеседі. Мұндай тәсіл 1С, CRM, медициналық немесе есеп жүйелері үшін жиі қолайлы.

Егер филиалдар мен тұрақсыз каналдар болса, үзілістер кезінде сеанстың қалай қалпына келетінін, уақытша файлдардың қайда қалатынын және қосылым нүктелерінің көбеюі архитектураны қайта қарауды талап етеді ме екенін тексеріңіз. Бұл кейде филиалдар үшін бөлек серверлер немесе орталықтандырылған кластер талап етеді, мысалы GSE S200 Series деңгейіндегі стоечный серверлермен және анық қолжетімділік пен резервтеу ережелерімен.

ИБ-ке арналған сұрақтар: қолжетімдікті бақылау, журналдау, деректер

RDS пен VDI-де қауіпсіздікті көбіне іске қосқаннан кейін "докручивать" бастайды, себебі пайдаланушылардың әдеттері мен баптаулар бекітіліп қалады. Оны алдын ала ИБ-пен келісу дұрыс: бұл жұмыс ыңғайлылығына, соңғы қолжетімділік схемасына және тексеруден өтуге әсер етеді.

Қол жетімділік пен аутентификация

Қандай кіру сенімді саналады — оны анықтаңыз. Әкімшілер мен қалыпты қашықтан пайдаланушыларға талаптар әртүрлі болуы мүмкін.

Тексеру керек:

• MFA барлыққа қажет пе, әлде тек сырттан және артық құқықтары бар рөлдерге ме;
• құрылғы мен желі бойынша шарттар болады ма: корпоративтік ноутбук, сенімді желі, саясатқа сәйкестігі (жаңартулар, диск шифрлау);
• құқықтар қалай беріледі: рөлдер бойынша топтар, қажетті минималды құқық принципі, жалпы есептерге тыйым;
• сыртқы мердігерлер қалай рәсімделеді: бөлек есептік жазбалар, мерзімдер, тек нақты қолданбаларға рұқсат;
• RDP-ға тікелей ашпайтын бөлек шлюз/делдал қажет пе.

Сегментация, журналдар және деректерді қорғау

Желі сегментациясы қателер мен инциденттердің салдарын шектеуге көмектеседі. RDS/VDI-ді пайдаланушылардың ПК-тарынан және әкімші жұмыс орындарынан бөлек сегментте сақтау қажет пе — нақтылаңыз. Қол жетімді компромисс: пайдаланушылар тек брокер мен шлюзді көріп, ішкі серверлерге тікелей жоқ.

Журналдар жөнінде маңыздысы — не журналдаймыз ғана емес, оны қалай пайдаланамыз. Міндетті минимумды бекітіңіз: кіру/шығу оқиғалары, сессия үзілуі, пароль таңу әрекеттері, құқық беру оқиғалары, әкімші әрекеттері. Логтардың қайда сақталатыны, кімнің қолы жететіні, қанша ай сақтау керектігі және сұрау бойынша оларды қаншалықты тез көрсетуге болатынын келісіңіз.

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

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

Кейбір типтік қателіктер, кейін қайта жасауға мәжбүр ететіндер

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

Көп тараған шатасу — сервер лицензиясын алып қойсаң бәрі шешілді деп ойлау. Шындығында сервер лицензиясы мен қолжетімділік (CAL) лицензиялары әртүрлі мәселелерді шешеді. Нәтижесі қарапайым: терминал сервері жұмыс істей береді, бірақ пайдаланушылардың лицензиялық құқықтары заңдық тұрғыдан жабылмаған болады, және тексеру не кеңейту кезінде шұғыл түрде лицензия сатып алу мен модельді қайта құруға тура келеді.

Тағы бір типтік оқиға — тек штаттық қызметкерлерді есепке алу. Шын мәнінде сыртқы мердігерлер, уақытша командалар, сервис тіркелгілер, мониторинг аккаунттары бар. Оларды алдын ала есепке алмай, қолжетімділік сұрауларын "қалаулы түрде" бере бастайды, және бірнеше айдан кейін кімге не үшін рұқсат берілгенін ешкім есте сақтамайды.

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

Тағы бір тәуекел — жеке құрылғылардан қосылуға нақты шарттарсыз рұқсат беру. Бұл ыңғайлы болғанымен, бақылауды жоғалтуға және инцидентті зерттеуді күрделендіруге әкеледі.

Қайта жасауға әкелетін белгілер:

• сервер лицензиясы мен қолжетімділік лицензиялары бөлінбеген;
• есепте мердігерлер мен техникалық тіркелгілер ескерілмеген;
• сменалар мен "жалпы" жұмыс орындары сипатталмаған;
• жеке құрылғылар рұқсат етілген, бірақ шарттар бекітілмеген;
• кімге, қай нәрсеге және қандай мерзімге қолжетімділік берілгені туралы реестр жоқ.

Жобаны сақтайтын практикалық минимум: қарапайым қолжетімділік пен мерзімдер реестрін жүргізіп, мердігерлер мен BYOD ережелерін бекітіңіз, және пайдаланушылар мен құрылғыларды қалай есептейтіндігіңізді жазып қойыңыз. Егер RDS/VDI-ні мемлекеттік секторда немесе ірі ұйымға енгізетін болсаңыз, ИБ мен сатып алуларды ертерек тартыңыз, қажет болса тәжірибесі бар жүйелік интеграторды шақырыңыз, мысалы GSE.kz.

Сатып алуға және аудитке дейінгі қысқа чек-лист

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

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

Сатып алудан бұрын мына 6 нәрсені тексеріңіз:

• есепке алу иесі тағайындалған: кім пайдаланушылар/құрылғылар реестрін жүргізеді, қандай дәлелдер сақталады, аудитор сұрақтарына кім жауап береді;
• пайдаланушылар топтары сипатталған: штаттық, сменалы, жалпы жұмыс орындары, қашықтан, филиалдар, тесттік есептер — әр топқа қолжетімділік сценарийі көрсетілген;
• per user немесе per device таңдалғаны сандармен негізделген: қанша уникалды адам, қанша нақты құрылғы, "ыстық" орындар бар ма және қызметкерлер қаншалықты жиі ауысады;
• мердігерлерге арналған қолжетімділік бөлек бөлінген: тіркелгілер қалай беріледі, мерзімі, шұғыл қолжетімділік қалай мақұлданады және қалай тез өшіру керек;
• ИБ талаптары жазбаша бекітілген: MFA, рөлдер, журналдау, қайта бағыттауды шектеу (буфер, дискілер, принтерлер), локалді сақтау тыйымы.

Сәйкестікті тексеруге бөлек ойлаңыз. Жақсы аудит жоспары үш сұраққа жауап беруі керек: қанша жиі тексересіз, кім нәтижені бекітеді, деректерді қайдан аламыз (мысалы AD тізімдері, RDS/VDI есептері, Service Desk сұраулары).

Мысал: колл-орталықта адамдар 40 ортақ ПК-да сменамен жұмыс істейді, ал бухгалтерия жеке ноутбуктардан қосылады. Бірінші жағдайда per device тиімдірек, екінші жағдайда per user — ыңғайлы. Бұл тек сменалар, құрылғылар саны және мердігерлер үшін ережелер құжаттармен және журналдармен расталған кезде ғана жұмыс істейді.

Нақты сценарий мысалы: аралас пайдаланушылар мен филиалдардан қолжетімділік

Бас офисі және 6 филиалы бар ұйымды елестетіңіз. Офисте 80 қызметкер бар, олардың кейбіреуі ноутбукпен және кейде үйден жұмыс істейді. Филиалдарда 25 жалпы жұмыс орны бар, олар 2 сменада пайдаланылады, бір ПК-да күн ішінде әртүрлі адамдар жұмыс істейді. Сонымен қатар шамамен 10 адам үнемі қашықтан қосылады.

Мұндай конфигурацияда екі сұрақ per device немесе per user қай жерде тиімді екенін анықтайды:

• бір нақты құрылғыда күн ішінде қанша адам жұмыс істейді;
• бір адам орташа түрде қанша құрылғы қолданады (офис ПК, ноутбук, үй ПК).

Сменалы посттар үшін per device логикалық: құрылғыларды лицензиялайсыз, ал уақытша сменадағы әр адамды емес. Мобильді қызметкерлер үшін per user ыңғайлы: бір адам түрлі құрылғылардан қосылады және әр құрылғыны жеке есепке алмау керек.

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

Ең аз шектеулер, жұмысты бұзбайтындар: алдан жоспарлаңыз — буфер алмасу, басып шығару, диск пен USB бағыттауды қажет пе. Егер қажет болмаса, оны өшіру қауіпсіз.

Осындай талқылаудан кейін қолыңызда қарапайым артефактілер қалады: пайдаланушылар мен құрылғылар реестрі, қолжетімділік матрицасы (кім қайда және қандай құқықпен қосылады) және офис, филиалдар, қашықтан жұмыс және мердігерлерге арналған сценарийлердің қысқаша сипаттамасы.

Келесі қадамдар: шешімді рәсімдеу және енгізуге кім көмектеседі

Шешімді бір беттік құжатта бекітіңіз. Оның мақсаты — ИТ, ИБ, сатып алу және жүйе иелері бірдей түсінуі керек: кім қалай қосылады, қандай шектеулер бар және не сатып алу қажет.

Осы беттің ыңғайлы құрылымы:

• қолжетімділік сценариілері (офис, филиалдар, қашықтан, мердігерлер) және қажетті қосымшалар;
• пайдаланушылар топтары мен құрылғы түрлері (жеке ПК, сменалы орындар, тонкий клиенттер);
• таңдалған лицензия моделі (per user немесе per device) және негіздемесі;
• ИБ талаптары: MFA, рөлдер, журналдау, деректер сақтау, логтарды сақтау мерзімі;
• шектеулер: жаңарту терезелері, тоқтаулар, қолжетімділік талаптары.

Одан кейін ағымдағы инфрақұрылымның таңдалған сценарийді көтере алатынын тексеріңіз. Кейде лицензиялар дұрыс таңдалғанымен, CPU, RAM, дискілік жүйе, желі немесе профильдік сақтау жетпей қалады.

Енгізуге дейінгі минималды техчек:

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

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

Егер командада тәжірибе немесе уақыт жетпесе, жүйелік интеграторды тартқан жөн. GSE.kz — Қазақстандағы серверлер мен жұмыс орындарын өндіруші және жүйелік интегратор ретінде RDS/VDI жобалауда, сервер мен жұмыс станцияларын таңдауда, енгізуде және 24/7 қолдауда көмектеседі, ИБ талаптары мен сатып алу шектеулерін ескере отырып.