PCI DSS 4.0: төлем беттерінің скрипттеріне қойылатын 6.4.3 және 11.6.1 талаптары

PCI DSS-тің 6.4.3 және 11.6.1 талаптары төлем веб-беттеріндегі скрипттерге қатысты: әр скрипт авторизацияланған, тұтастығы тексерілген және негіздемесімен бірге тізімге енгізілген болуы тиіс, ал беттің және HTTP-тақырыптарының рұқсатсыз өзгерістері анықталуы керек. Бұл «future-dated» талаптар: олар ұсыныс болатын және 2025 жылғы 31 наурыздан міндетті болды. Карталарды онлайн қабылдайтын ұйымдар үшін мерзім келіп қойды.

Бұл талаптар неге пайда болды

E-skimming (Magecart тәрізді) шабуылдары төлем бетіне зиянды JavaScript енгізуге негізделеді: скрипт карта деректерін сатып алушының браузерінің өзінде үнсіз көшіріп алады. Көзі сайттың өзін бұзу да, үшінші тарап кітапханасының бұзылуы да болуы мүмкін — аналитика, чат-виджет, A/B-тестілеу, тег-менеджер. Классикалық серверлік қорғаныс құралдары мұндай шабуылды көрмейді: зиянды код клиент жағында орындалады. PCI SSC кеңесі талаптардың мақсатын e-skimming-тің алдын алу деп сипаттайды: төлем беттерінің скрипттері бекітілген, тұтастығы тексерілген және мониторингте болады.

Мерзімдер: «future-dated» нені білдіреді

PCI DSS v4.0 шыққан кезде жаңа талаптардың бір бөлігі белгілі бір күнге дейін үздік практика ретінде белгіленді. 6.4.3 және 11.6.1 (сондай-ақ 12.3.1) талаптары үшін мұндай күн 2025 жылғы 31 наурыз болды — бұл туралы PCI SSC тікелей айтады. Қазір v4.0.1 нұсқасы қолданыста, бірақ бұл талаптар үшін күн өзгерген жоқ. Яғни сәйкестікті бағалау кезінде (QSA-аудит, өзін-өзі бағалау) олардың орындалуы міндетті ретінде тексеріледі.

6.4.3 талабы: скрипттерді басқару

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

• Авторизация. Әр скриптті орындауға рұқсат етілгенін растайтын әдіс болуы тиіс.
• Тұтастық. Скрипттің мазмұны өзгермегеніне кепілдік беретін әдіс болуы тиіс.
• Түгендеу. Әрқайсысы не үшін қажет екенін көрсететін жазбаша бизнес- немесе техникалық негіздемесі бар барлық скрипттер тізімі жүргізіледі.

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

11.6.1 талабы: өзгерістерді анықтау

Тармақ қауіпсіздікке әсер ететін HTTP-тақырыптарындағы және төлем беттерінің тұтынушы браузері алатын мазмұнындағы рұқсатсыз өзгерістер туралы персоналды хабардар ететін тетікті талап етеді. Тексеру мерзімдік түрде орындалады; стандарт жиілікті не белгіленген аралықпен, не мақсатты тәуекел талдауының нәтижелерімен (12.3.1 талабы) байланыстырады — нақты тұжырымды және рұқсат етілген мерзімділікті pcisecuritystandards.org сайтындағы PCI DSS v4.0.1 мәтіні бойынша тексеріңіз. Іс жүзінде аудиторлар өзгерістің назардан тыс қалмайтынын дәлелдейтініңізді күтеді.

Бұл кімге қатысты: толық бағалау және SAQ A

Талаптар төлем беттері PCI DSS сәйкестік аймағында болатын ұйымдарға қолданылады. SAQ A өзін-өзі бағалауын толтыратын мерчанттар үшін жағдай ерекше. PCI SSC FAQ бойынша, 6.4.3 және 11.6.1 тармақтары SAQ A-дан алынып тасталған, бірақ стандартта қалды. Оның орнына жарамдылық өлшемшарты пайда болды: мерчант сайтының скрипттер арқылы жасалатын шабуылдарға осал емес екенін растауы тиіс. Мұны екі жолмен жасауға болады — 6.4.3 және 11.6.1-ге ұқсас техникалық шараларды қолдану (өз бетінше немесе үшінші тараптың көмегімен), не PCI-үйлесімді төлем қызметтерін жеткізушіден (TPSP) оның шешімі дұрыс енгізілгенде бетті мұндай шабуылдардан қорғайтыны туралы растама алу. Өлшемшарт мерчант бетіне жеткізушінің төлем формасы енгізілген жағдайларға (мысалы, iframe) қатысты; процессор бетіне бағыттағанда ол қолданылмайды. Өзін-өзі бағалаудың қай формасы сізге сәйкес келетінін эквайерден және төлем жүйелерінен нақтылаңыз.

SAQ A-EP және толық бағалау (ROC) үшін 6.4.3 тармағы тікелей қолданылады.

Талаптарды қалай орындау керек: практикалық жоспар

1. Төлем беттерін анықтаңыз. Қандай URL-дер карта деректерін қабылдайды және өңдейді, енгізілген формалар мен редиректтерді қоса.
2. Скрипттер тізімін жасаңыз. Браузерде шын мәнінде жүктелетіннің бәрін (құжаттамада жазылғанды емес) автоматты түрде жинаңыз: өз файлдарыңыз, сыртқы домендер, жүктеу тізбектері.
3. Әр скрипт үшін негіздеме алыңыз. Иесі кім, төлем бетінде не үшін қажет. Негіздеуге болмайтынның бәрін жойыңыз.
4. Авторизация мен тұтастықты қамтамасыз етіңіз. Әдеттегі техникалық құралдар: көздердің ақ тізімі бар Content Security Policy (CSP); статикалық сыртқы скрипттер үшін Subresource Integrity (SRI); маңызды скрипттерді өзіңізде орналастыру. SRI вендор жиі және динамикалық түрде өзгертетін скрипттерге жарамайтынын ескеріңіз.
5. Мониторингті баптаңыз (11.6.1). Беттер мен тақырыптардың мазмұнын пайдаланушы көретіндей автоматты түрде бақылап, эталоннан ауытқу болса хабарлаңыз.
6. Үдерісті енгізіңіз. Төлем бетіндегі жаңа скрипт келісуден өтеді, тізім мен мониторинг эталонын жаңартады. Онсыз тізім бір айдан кейін ескіреді.
7. Дәлелдемелерді сақтаңыз. Тізім, хабарламалар журналдары, өзгерістер бойынша шешімдер — аудиторға кезең бойынша артефакттар қажет болады.

Типтік қиындықтар

• Көрінбейтін тәуелділіктер. Үшінші тарап скрипті тағы бірнешеуін жүктейді. Бастапқы кодты статикалық талдау оларды көрсетпейді — браузерде шын мәнінде орындалатынды талдау керек.
• Вендорлардың динамикалық өзгерістері. Үшінші тарап сервистері кодты ескертусіз жаңартады, бұл SRI-ды бұзып, жалған дабылдар тудырады.
• Көрсету үшін ғана CSP. Кең ерекшеліктері бар тым жұмсақ саясат формальді түрде бар, бірақ қорғаныс бермейді.
• Иелері жоқ. Маркетинг тегтер қосады, АҚ бұл туралы аудит кезінде біледі.

Қандай құралдар көмектеседі

Талаптарды CSP, SRI және өз мониторинг скрипттерінің үйлесімімен жабуға болады, бірақ мұндай шешімді қолдау еңбекті көп қажет етеді. Клиент бөлігінің қауіпсіздігіне арналған мамандандырылған шешімдер түгендеуді, тұтастық бақылауын және хабарландыруларды автоматтандырады. AST Cyber Lab портфелінде бұл үшін DPA Analytics компаниясының DPA FAST шешімі бар — фронтендті және JavaScript-ті қорғауға арналған шешім. Мүмкіндіктердің егжей-тегжейін және оның сіздің төлем схемаңызға қолданылуын өнім бетінде немесе біздің мамандардан нақтылаңыз.

Қауіпсіз әзірлеу үдерісін енді ғана құрып жатсаңыз, жалпы көріністен бастаңыз: DevSecOps: неден бастау керек және AppSec құралдары кластарына шолу. Фронтенд тәуелділіктерін бақылау (npm-пакеттер) — SCA міндеті, ал PCI DSS 6-бөлімінің кеңейтілген талаптарын қолданбалардың қорғалғандығын бағалау аясында тексеруге болады.

Мақала ақпараттық сипатта және заңгерлік консультация болып табылмайды.

Аудиторға нені көрсету керек

QSA бағалаушысы ниетті емес, артефакттарды бағалайды. 6.4.3 және 11.6.1 үшін алдын ала дайындаңыз:

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

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

Дәл қазір неден бастау керек

Мерзім келіп қалып, үдеріс құрылмаған болса, мына ретпен әрекет етіңіз: бір-екі апта ішінде төлем беттері скрипттерінің нақты тізімін жинаңыз; негіздеуге болмайтынның бәрін жойыңыз; дәлелдер жинай бастау үшін өзгерістер мониторингін қосыңыз; параллель түрде CSP-ді қатаңдатып, жаңа скрипттерді келісу рәсімін енгізіңіз. Мінсіз архитектураны күтпеңіз — ашық жоспары бар ішінара орындау бақылаудың болмауынан жақсы. Кестені және рұқсат етілген өтемдік шараларды өз QSA-ңызбен және эквайеріңізбен келісіңіз.

Жиі қойылатын сұрақтар

Дереккөздер

• PCI SSC Blog: Guidance for PCI DSS E-commerce Requirements Effective After 31 March 2025
• PCI SSC FAQ 1588: SAQ A жарамдылық өлшемшарты және төлем беттерінің скрипттері
• PCI SSC Blog: FAQ Clarifies New SAQ A Eligibility Criteria