2025 ж. 20 жел.·1 мин

ПК сатып алудағы аппараттық қауіпсіздік: талаптарды дұрыс қалыптастыру

ПК сатып алудағы аппараттық қауіпсіздік: TPM, Secure Boot және паролдер туралы тексерілетін, нақты әрі артықша нақтылаусыз жазуға болатын формулировкалар.

ПК сатып алудағы аппараттық қауіпсіздік: талаптарды дұрыс қалыптастыру

Аппараттық қауіпсіздік талаптары не үшін қажет

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

ТЗ-де көбіне екі шет ұшы кездеседі:

  • «жоғары деңгейдегі қауіпсіздік» немесе «заманауи қорғаныс технологияларын қолдау» сияқты тым жалпы ұғымдар — қабылдауда тексерілмейді;
  • бренд пен чип моделін нақтылау: «TPM нұсқасы X.Y өндіруші Z» — мұндай талаптар оңай дауласады және практикалық пайда бермейді.

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

Тапсырыс беруші әдетте төрт нәрсені қорғауға тырысады: жүктеу тізбегі, кілттер мен есептік жазбалар, UEFI/BIOS баптауларына қолжетімділік және осы баптауларды басқару (ИТ қызметі саясат орната алуы және өкілеттілікті қалпына келтіру мүмкіндігі).

Мысалы, мектеп немесе клиника: ПК жалпы кабинеттерде тұрады, онда ондаған адам қол жеткізе алады. Secure Boot және UEFI паролдері болмаған жағдайда бір флешка мен бірнеше минут жеткілікті — сыртқы ортаны жүктеп көру, жергілікті парольдерді қалпына келтіру немесе қорғанысты өшіру мүмкін. Жақсы жазылған талаптар жұмысты қиындатпайды, бірақ мұндай «тез шабуылдарды» айтарлықтай азайтады және қабылдауды жеңілдетеді: функция бар немесе жоқ — айқын.

FAQ

ПК-ке арналған ТЗ-ге аппараттық қауіпсіздік бойынша минималды талаптар ретінде не енгізу керек?

Минимальды практикалық жиынтық әдетте TPM 2.0 (ОС үшін қолжетімді және UEFI арқылы қосуға болатын), UEFI Secure Boot қолдауы және UEFI/BIOS параметрлеріне әкімші паролімен қорғаныс кіреді. Ашық орындарда тұрған жұмыс орындары үшін сыртқы жүргізушілерден жүктеуді басқару мүмкіндігін қосқан жөн, сонда жүктеу тәртібін флешка арқылы оңай өзгерту мүмкін болмайды.

TPM туралы талапты қалай дұрыс жазу керек, ол қалай тексеріледі?

Нәтижені сипаттау дұрыс: TPM 2.0 UEFI-ден қосуға арналған болуы керек және операциялық жүйеде жұмыс істеуге дайын күйде көрінуі тиіс. Қабылдауда бұл UEFI орнатуларын қарап шығу және ОС-тің штатты құралдарымен TPM статусын тексеру арқылы расталуы тиіс — яғни функция тек «жарияланған» емес, іс жүзінде жұмыс істейтін болуы керек.

Сатып алуда TPM өндірушісін немесе типін (дискретті/интегралды) көрсету керек пе?

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

ТЗ-ге «Secure Boot әрқашан қосулы болу керек және оны өшіруге болмайды» деп жазуға бола ма?

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

BIOS/UEFI параметрлерін «галочка үшін» емес, сенімді қорғау үшін ТЗ-те қалай жазу керек?

Талап — әкімші паролі болуы тиіс, ол UEFI/BIOS параметрлеріне кіруге және оларды өзгертуді блоктауға тиіс. Қабылдауда паролі жоқ жағдайда Secure Boot, TPM немесе жүктеу тәртібін өзгерту әрекеттері сәтсіз болатыны тексеріледі және бұл факт журналға/актқа енгізіледі.

UEFI/BIOS паролін қалай дұрыс қалпына келтіру тәртібін ТЗ-ке енгізу керек, «мастер-парольдер» болмауы үшін?

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

Қабылдауда қанша құрылғыны тексеру керек және оны ТЗ-те қалай жазу керек?

Жұмыс істейді: модельге бір-екі сынақ үлгісі және партиядан белгіленген үлес бойынша таңдамалы тексеру. ТЗ-де UEFI мен ОС бойынша бірдей тексеру қадамдары көрсетілуі тиіс және бір сәйкессіздік табылғанда қандай әрекет болатыны анықталуы керек.

TPM/Secure Boot/UEFI талаптарын растайтын құжаттарды жеткізушіден не сұраған жөн?

Сұраңыз: паспорт/формуляр (модель, сериялық нөмір, жиынтығы), жеткізілетін конфигурацияға қатысты спецификация (TPM бар-жоғы және Secure Boot функциясы), қысқаша нұсқаулық — қалай TPM, Secure Boot пен UEFI/BIOS паролін тексеру және баптау керек. Қосымша ретінде жеткізушіден ТЗ талаптарына сәйкестігін растайтын хат пен қабылдау чек-листін сұраңыз.

USB-тен жүктеуді тыйған дұрыс па және оны теңшеуді қалай жазуға болады?

Егер физикалық қолжетімділік қаупі бар болса, USB-тан жүктеуді өшіру немесе басқару көп көмектеседі. ТЗ-те оны қатал түрде толық тыймастан: «сыртқы носительдерден жүктеуді шектеу немесе жүктеу басымдылығын тек әкімші паролін енгізгеннен кейін ғана өзгерту мүмкіндігі» деп жазған дұрыс — сонда ИТ топтары регламент бойынша ерекшеліктер енгізе алады.

Аппараттық қауіпсіздік талаптарындағы жиі қателіктер қандай және оларды қалай болдырмауға болады?

Ең көп кездесетін қателер — критерийсіз «жоғары қауіпсіздік» сұрау және UEFI мәзірінің нақты тармақтарын міндеттеу. Сондай-ақ «ечқашан өзгертуге болмайды» секілді шектеулер қызмет көрсету мен қалпына келтіруге кедергі келтіреді. Әр талапты үш сұрақ бойынша тексеріңіз: не қосылу/тыйым салынуы керек, қалай қабылдау кезінде тексеріледі және эксплуатацияда қалай жұмыс істейді.