TPM арқылы қашықтан растау: жергілікті желідегі жүктеу тұтастығы

BIOS пен жүктегіштің подменаcы мәселесі қандай

BIOS/UEFI және жүктегішті подмена жасау — компьютердің ең ерте іске қосылу сатысына жасалатын шабуыл. Бұл Windows немесе Linux жүктелмей тұрып болады, сонда антивирус пен мониторинг агенттері әлі іске қосылмаған. Қаскөйлер дәл сол жерді пайдаланып тұрақтап қалуға тырысады, себебі дәстүрлі қорғау құралдары онша қарамайды.

Көбінесе шабуыл үш аймақта шоғырланады:

• UEFI прошивкасы: оған зиянды модуль енгізіп немесе параметрлерді өзгертіп, жүйені қажет емес компоненттерге сендіреді;
• жүктегіш пен жүктеу тізбегінің ерте компоненттері, олар ядроны іске қосады;
• Secure Boot параметрлері: оны сөндіріп, кілттерді ауыстырып немесе қолтаңбасыз компоненттердің жүруіне мүмкіндік береді.

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

Мұндай подменаның қауіптілігі — оның жасырын қалуы және өміршеңдігі. Егер зиянды код UEFI немесе ерте жүктеу кезеңінде тұрса, ол жүйені қайта орнатудан, дискіні ауыстырудан және кейбір қалпына келтіру процедураларынан кейін де сақталуы мүмкін. Ол қауіпсіздік құралдарының көрінісін бұрмалап, процестерді жасырып, тексерулерді өшіріп немесе «таза» журналдар көрсетіп қоюы ықтимал.

ИТ әдетте тек жанама белгілерді көреді, және олар да әрдайым бармайды:

• Secure Boot кенеттен өшірілген немесе UEFI параметрлері өзгерген;
• техникалық қызметтен кейін станцияда оғаш мінез пайда болған;
• жүктеу кезіндегі тұтастықсыздықтар, анық себепсіз тоқтап қалулар;
• эталондық конфигурациямен нұсқалар немесе чек-суммалардың сәйкессіздігі;
• саяси немесе жүктеу ережелеріндегі күдікті ерекшеліктер.

Ең қорқыныштысы — ИТ көрмейтін нәрсе: ОЖ жүктелуіне дейін болған подмена фактісі. Сондықтан жүктеу тұтастығын бақылау қажет, ал одан әрі — TPM арқылы қашықтықтан растауды (remote attestation) енгізу логикалық қадам.

Remote attestation және TPM жай сөйлемдермен

TPM (Trusted Platform Module) — компьютердегі қорғалған модуль, машина дұрыс жүктелгенін растауға көмектеседі. Оны сенім түбі деп атайды: ол кілттерді сақтайды және жүктеудің маңызды бөліктерінің өлшеулерін тіркейді, осылайша артынан бұрмалау қиынға соғады.

Құрылғы іске қосылған кезде компоненттер бір-бірін тізбектеп өлшеп (хэш есептеп) нәтижесін TPM-нің арнайы тіркеулеріне — PCR-ге (Platform Configuration Registers) жазады. PCR-дер файлдарды сақтамайды, олар күйдің «саусақ ізін» сақтайды және жазу жинақтаушы түрде жүреді. Бірнәрсе өзгерсе — соңғы «саусақ із» те өзгереді.

Көбінесе PCR-ге келетін өлшеулер:

• UEFI/BIOS прошивкасы және жүктеуге әсер ететін параметрлер;
• жүктегіш пен ерте ОЖ компоненттері;
• Secure Boot параметрлері (не рұқсат етілгенін көрсетеді);
• өте ерте жүктелетін драйверлер мен модульдер;
• кей жағдайда — ОЖ сенімді жүктеу бөлігі деп санайтын саясаттар мен конфигурациялар.

TPM арқылы қашықтан растау — осы өлшеулерді алыста тексеру. Идея қарапайым: белгілі бір модель мен ОЖ образына арналған «эталон» бар, ал жұмыс станциясы сұраныс бойынша нақты жүктелген кездегі PCR мәндерін ұсынады. Сервер мәндерді эталонмен салыстырып, құрылғыға сенуге болатынын шешеді: желіге қосылуына рұқсат беру, маңызды жүйелерге шығару немесе тексеруге жіберу сияқты.

Бұл антивирустың немесе файл тексерудің орнына емес, толықтырушы ретінде қажет. Антивирус жүктелген жүйеде жұмыс істейді, ал шабуылдаушы ерте деңгейде жасырын болуы мүмкін. Attestation — әдетті құралдар әлі іске қосылмаған ерте күйді тексеретіндіктен, BIOS/UEFI пен жүктегіштің подменасын жақсырақ анықтайды.

Практикалық мысал: жабық желіде техникалық қызметтен кейін әкімші тексеруді іске қосады. Егер PCR эталонмен сәйкес келмесе (мысалы, бухгалтерлік станцияға арналған эталон), құрылғы маңызды ресурстарға қол жеткізе алмайды, себептері анықталмайынша.

Жұмысты қалай дайындау керек

TPM арқылы қашықтықтан растау «тек рәсім үшін» айналмауы үшін алдымен нені қалыпты деп есептейтініңізді келісіп, бірдей бастапқы жағдайларды қамтамасыз ету керек.

Алғашқы және міндетті талап: TPM 2.0 BIOS/UEFI-де қосулы болуы және операциялық жүйеде көрінуі керек. Модульдің болуы ғана жеткіліксіз — ОЖ өлшеулерді оқу (measured boot) және оқиғалар журналын алу мүмкіндігі болуы маңызды. Практикада бұл көбінесе TPM өшілуі, ескі прошивка немесе қызметтен кейін «босатылған» параметрлер салдарынан бұзылады.

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

Үшінші блок — өзгерістерді басқару. Attestation өзгерістер бақылауда болғанда тиімді жұмыс істейді: BIOS/UEFI, микрокод, драйверлер, жүктегіш пен ОЖ образының жаңартулары бірыңғай тәртіп бойынша өтуі тиіс. Әйтпесе үнемі «қызыл» ескертулерге тап боласыз.

Алдын ала «эталонды» анықтаңыз: қандай құрылғы модельдері, прошивкалар және ОЖ образдары қабылданады. Жұмыс станциялар паркі үшін әдетте офис ПК-нің типтік конфигурациясына арналған эталон және кеңейтілген құқықтары бар машиналарға (әкімшілер, бухгалтерия, медициналық жүйелерге қатынасы барлар) бөлек эталондар жасалады.

Пилот алдында кемінде мына нәрселерді жинаңыз:

• құрылғылар инвентаризациясы (модель, BIOS/UEFI нұсқасы, TPM 2.0 статусы, UEFI режимі);
• келісілген прошивка параметрлері (TPM қосулы, Legacy/CSM ажыратылған, Secure Boot саясаты);
• негізгі эталондық ОЖ образы және рұқсат етілген жүктеу компоненттерінің тізімі;
• жаңартулар ережелері: кім, қашан және қалай BIOS/UEFI пен драйверлерді жаңартады;
• «норма» мен тексеру нәтижелерін сақтайтын орын (жабық желіде де қажет).

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

Нені тексеру керек: шекаралар мен қатаңдық деңгейі

TPM арқылы қашықтан растау шын мәнінде подменадан қауіпті азайтуы үшін алдын ала не өлшенетінін және қандай өзгерістер қалыпты саналатынын анықтау қажет. Әйтпесе жүйе немесе дыбыссыз хабарламалар пайда болады.

Біріншіден не өлшеу керек

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

Кәдімгі приоритеттер:

• UEFI/BIOS және қауіпсіз жүктеуге әсер ететін негізгі параметрлер (Secure Boot, жүктеу тәртібі, сыртқы носительдерді шектеу);
• жүктеуші менеджері және оның қолтаңбасы (Windows Boot Manager немесе баламасы);
• маңызды жүктеу файлдары мен ерте драйверлер;
• сенімді жүктеуге әсер ететін ОЖ компоненттері;
• тексерудің мағынасына әсер ететін саясаттар (мысалы, тест режимін қосу).

Бастапқы кезеңде UEFI мен жүктегішті бақылау жеткілікті болады. «Барлығын бірден» бақылау пилот үшін сирек пайдалы және қосымша шуды тудырады.

Шекаралар: не рұқсат етуге, не күдікті деп есептеуге

TPM өлшеулерді тіркейді, ал шешімді сіздің саясатыңыз қабылдайды. Ыңғайлы модель — әр құрылғы тобына арналған «рұқсат етілген күйлер» (baseline).

Рұқсат етілетін өзгерістер тек сіз түсіндіре алатын және қайталауға болатын нәрселер болуы тиіс:

• өндірушінің жоспарлы UEFI/BIOS жаңартулары;
• жүктеу компоненттерін өзгерте алатын ОЖ жаңартулары;
• санкцияланған Secure Boot параметрлері немесе кілттерді ауыстыру;
• ресми түрде рәсімделген диск немесе аналық платаны ауыстыру.

Әр патчтан кейін үнемі ескерту алмау үшін эталондарды жаңарту процесін жүргізіңіз: шағын топта тестілеу, жаңа «алтын» күйді бекіту, содан кейін жаппай енгізу.

Тағы бір маңызды жайт — әр түрлі модельдердің болуы. GSE L200 (ПК) және M200 (моноблок) сияқты желілер үшін әр түрлі профиль ұстау дұрыс: прошивка мен драйверлердегі айырмашылықтар бірдей ОЖ болғанымен әр түрлі өлшеулер береді. Бұл қалыпты, егер әр құрылғы «өз» эталонмен салыстырылса.

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

Қадам-қадам: күрделі жобасыз қалай енгізуге болады

Мақсат — жұмыс станциясының «әдеттегідей» жүктелгенін білу және BIOS/жүктегіш подменасын уақытында байқау болса, TPM арқылы қашықтықтан растауды 10–20 машинаға пилотпен бастауға болады. Пилоттың мәні — алдымен норманы тіркеу.

Енгізудің минималды жоспары

1. «Негізгі образды» сипаттаңыз: BIOS/UEFI нұсқасы, Secure Boot (қолдансаңыз), драйверлер жиынтығы, ОЖ нұсқасы және ерте жүктеуге әсер ететін негізгі саясаттар. Жабық желіде паркті 2–3 топқа бөліп алған ыңғайлы — бірдей модельдер мен образдары бар топтар, сонда ерекшеліктерге тонның ішінен шыға алмайсыз.

2. Өлшеулер жинауды қосыңыз. Әдетте бұл PCR мәндері мен өлшенген жүктеу журналы, сонымен бірге сізге маңызды сигналдар: Secure Boot статусы, UEFI параметрлеріндегі өзгерістер, микрокод нұсқасы, BitLocker немесе баламасының күйі.

3. «Таза» машиналардан эталон алыңыз. Әр топтан бірнеше жұмыс станциясын алып, оларды регламент бойынша толық жаңартып (BIOS, ОЖ, драйверлер) рұқсат етілген мәндерді тіркеңіз. Эталонды бірнеше сенімді профиль ретінде сақтау пайдалы: заңды жаңартулар кейбір өлшеулерді өзгертеді.

4. Тұрақты тексеруді қосыңыз. Бастау кезінде әр жүктеу кезінде және тәулігіне бір рет тексеру жеткілікті болады. Жабық желіде бұл локальды сервис немесе арнайы сервер арқылы орындалуы мүмкін, сыртқа тәуелділіксіз.

5. Отклонение кезінде реакцияны алдын ала анықтаңыз, әр оқиғаны қолмен қарастыруға мәжбүр етпеу үшін.

Қысқаша схема:

• пилот: 10–20 ПК, 2–3 бірдей конфигурация тобы;
• жинау: PCR + өлшенген жүктеу журналы + Secure Boot статусы және базалық саясаттар;
• эталон: әр топқа 3–5 «таза» машина, бірнеше рұқсат етілген профиль;
• кесте: жүктеу кезінде + күнделікті тексеру;
• реакция: ескерту, қолжетімдікті шектеу, карантин.

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

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

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

Бастапқыда «қызыл» туындататын жағдайлар

Төмендегі отклонениялар көбінесе назар аударуды қажет етеді:

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

Мұндай тәсіл жылдам нәтиже береді: норманы тіркеп, оны автоматты түрде тексеріп, бұзылған жағдайда нақты әрекеттерді іске қосасыз.

Жабық желіде тексеруді қалай ұйымдастыруға болады

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

ЛЖ желісі үшін практикалық нұсқа — аттестация серверін сол сегментте немесе қорғалған бөлек сегментте орналастыру, оған тек қажетті порттар бойынша рұқсат беріледі. Станциялар іске қосылғанда немесе кестеге сай өлшеулер (PCR мәндері, Secure Boot статусы және басқа сигналдар) жіберіп, сервер «сенуге» немесе «карантинге» шешім қабылдайды.

Эталондар мен журналдарды қайда сақтау

Эталондарды орталықтандырылған серверде сақтау тиімдірек — станцияларда емес. Тексеру журналдары да серверде жиналсын: жабық желіде журнал жиі өзгерістерді қашан және қандай машинада бастағанын анықтаудың жалғыз көзі болады.

Тарихты жоғалтпау және оның өшірілуіне жол бермеу үшін қарапайым ережелер көмектеседі:

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

Қол жеткізу алдында тексеру және эталондарды жаңарту

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

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

Жиі кездесетін проблема — жоспарлы патчтар өлшеулерді өзгертіп, «жақсы» машиналар кенет күдіктіге айналады. Шешім — эталондарды жаңарту процесін өзгерістер регламентіне қосу. Мысалы, BIOS-ты партия бойынша жаңартқанда алдымен 1–2 бақылау машинасында өзгерісті растап, жаңа эталон жасайсыз, содан кейін қалғанына енгізесіз.

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

Жиі қателіктер және олардан қалай сақтануға болады

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

Типтік қателіктер:

• Әртүрлі модельдер мен ревизияларға бір эталон жасайды. Тіпті ұқсас станциялардың UEFI нұсқалары, опциялар және өлшеулері әртүрлі болуы мүмкін. Шешім: эталондарды модельдер мен конфигурациялар бойынша бөліңіз. Үлкен парк болса, ең алдымен 2–3 ең көп тараған топтан бастаңыз.
• BIOS/UEFI жаңартылғаннан кейін эталонды қайта алуды ұмытып қояды. Жаңартудан кейін «саусақ іздер» өзгеруі қалыпты. Ережеге енгізіңіз: кез келген планды прошивка өзгерісі өзгерістер терезесі арқылы өтіп, эталон жаңартылып, жұп бақылау машиналарында тексеріледі.
• Ыңғайлылық үшін Secure Boot-ты өшіріп немесе Legacy режимге ауыстырып, тәуекелді тіркемейді. Егер Secure Boot-ты өшіру мүмкіндігі жоқ болса, бұл ерекшелік ретінде рәсімделіп, бөлек топ пен қаттырақ тексерулер болуы тиіс.
• Қызмет көрсету жұмыстарын елемейді: плата, SSD ауыстыру, прошивка қайта жазу, ОЖ қайта орнату. TPM үшін бұл әр түрлі оқиғалар және кейбіреулері өлшеулерді өзгертеді. Регламент: жұмыстардан кейін құрылғы «белгілі жақсы» күйге қайтарылса ғана жұмысқа жіберілсін немесе эталон қайта алынып, карантинге шықсын.
• «Қызыл» күйде не істеу керектігі көрсетілмеген. Содан кез келген ескерту «шабуыл ма әлде жалған позитив пе» деген дау тудырады.

«Қызыл» апталап ілініп қалмасын десеңіз, қысқа жауап беру тізбегін бекітіңіз:

1. Құрылғыны сезімтал сегменттерден оқшаулау (кем дегенде уақытша).
2. Өзгерістер терезесі немесе сервис жұмыстары болған-жоғына сәйкестендіру.
3. Қайта жүктеуден кейін тексеруді қайталау және күйдің тұрақтылығын растау.
4. Егер өзгеріс түсіндірілмесе, өз тобыңыздың эталонымен салыстырып, инцидент ашу.
5. Сенімді жүктеуді қалпына келтіргеннен (мысалы, UEFI/параметрлерді қайтару, жүктегішті қайта орнату) кейін ғана эксплуатацияға қайтару және жаңа күйді тіркеу.

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

Егер паркіңіз сериялық ұқсас модельдерден тұрса, эталон топтары мен өзгерістер терезесін ұстану ең жылдам нәтиже береді.

Іске қосудың алдында қысқа чеклист

Паркті түгелдей attestation-ды қосар алдында бірнеше негізі нәрсені тексеріңіз. Бұл кейбір компьютерлерде «өлшеулер сәйкес келмейді» деген проблеманың себебін іздеуге уақыт үнемдейді.

Міндетті минимум

Әр машинада TPM анықталып, параметрлерде қосулы екеніне көз жеткізіңіз. Арнайы тексеріп, бұл TPM 2.0 екеніне сеніңіз, ескі модуль немесе үйлесімділік режимі емес.

Жүктеу режимін тексеріңіз. Тұрақты тұтастық тексеруі үшін UEFI қажет. Secure Boot қосулы болуы міндетті емес, бірақ егер сіз оны қолданбасаңыз, онда қай нәрселер өлшенетінін және нені бақыламайтындығыңыз түсінікті болуы тиіс.

Эталонды ұйым бойынша емес, комбинация бойынша дайындаңыз: компьютер моделі, BIOS/UEFI нұсқасы, диск пен ОЖ конфигурациясы, маңызды драйверлер мен жүктеу саясаттарының жиынтығы. Тіпті бірдей модельдегі екі станция прошивка нұсқасы немесе контроллер режимдері әртүрлі болса, түрлі өлшеулер береді.

Операциялық сұрақтар, жоқ болса бәрі құртылуы мүмкін

• Әр модель мен типтік конфигурацияға эталон бар және оны жаңарту тәртібі айқын.
• Тексеру кестесі анықталған: қашан тексереміз (қосу кезінде, тәулігіне, жаңартудан кейін) және журналдарға кім қол жеткізеді.
• Журналдарды сақтау: қайда, қанша уақыт, нақты ПК бойынша тарихты қаншалықты тез алуға болатыны айқын.
• Несәйкестік жағдайында кім жауапты, шешім қанша уақытта қабылдануы тиіс, қолданушы мен құрылғымен не істелетіні анықталған.
• «Қауіпсіз сәтсіздік» ойластырылған: қандай жағдайды критикалық санау (BIOS/жүктегіш подменасы күдігі), ал қандай қателік қайта тексеруді талап етеді.

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

Мысал: сервистен кейін жұмыс станциясын тексеру

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

Сіз TPM арқылы қашықтан растауды іске қосып, нәтижені осы модель мен конфигурация үшін бұрын алынған эталонмен салыстырасыз. Аттестация тек «жалпы жақсы» немесе «жаман» емес, нақты өлшеулердегі өзгерістерді көрсетеді: прошивкаға, жүктеу тізбегіне және Secure Boot параметрлеріне қатысты мәндер өзгерген.

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

Практикалық әрекеттер тәртібі:

• Уақытша станцияны маңызды ресурстардан шектеу, себепті анықтағанша;
• Өзгерістерді сервис тапсырысына және уәделерде көрсетілген прошивка нұсқасына сай салыстыру;
• Күдіктілік болса, сенімді көзден BIOS-ты қайта жазып, жүктеу параметрлерін бекітіңіз;
• Аттестацияны қайталап өткізіңіз: мәндер бұрынғыға оралуы немесе күтілетін жаңартуға сәйкес тұрақталуы қажет;
• Егер жаңарту расталса, эталонды соған сәйкес жаңартып, регламентте тіркеңіз.

Осылайша бухгалтерия тез жұмысқа оралады, ал ақпараттық қауіпсіздік сервиске «сенуге» мәжбүр болмайды — шешімдер фактілерге негізделеді және BIOS/жүктегіштің жасырын подменасы қатты төмендейді.

Келесі қадамдар: пилот, регламенттер және қолдау

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

Пилот: кімді алу және нәтижені қалай бағалау

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

Табысты өлшеу критерийлерін алдын ала бекітіңіз:

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

Регламенттер және қолдау: күнделікті жұмыс істеуі үшін

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

Тексеруді екі процеске енгізген дұрыс.

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

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

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

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