PCI DSS 4.0: to‘lov sahifalari skriptlariga qo‘yiladigan 6.4.3 va 11.6.1 talablari

PCI DSS’ning 6.4.3 va 11.6.1 talablari to‘lov veb-sahifalaridagi skriptlarga tegishli: har bir skript avtorizatsiyadan o‘tgan, yaxlitligi tekshirilgan va zarurligi asoslangan holda ro‘yxatga kiritilgan bo‘lishi, sahifa va HTTP-sarlavhalardagi ruxsatsiz o‘zgarishlar esa aniqlanishi kerak. Bular «future-dated» talablar: ular tavsiya edi, 2025-yil 31-martdan majburiy bo‘ldi. Kartalarni onlayn qabul qiladigan tashkilotlar uchun muddat allaqachon keldi.

Bu talablar nega paydo bo‘ldi

E-skimming (Magecart’ga o‘xshash) hujumlar to‘lov sahifasiga zararli JavaScript kiritishga asoslanadi: skript karta ma’lumotlarini xaridorning brauzerida, bevosita jim nusxalaydi. Manba saytning o‘zi buzilishi ham, uchinchi tomonning buzilgan kutubxonasi ham bo‘lishi mumkin — analitika, chat-vidjet, A/B-testlash, teg-menejer. Klassik server himoya vositalari bunday hujumni ko‘rmaydi: zararli kod mijoz tomonida bajariladi. PCI SSC kengashi talablar maqsadini e-skimming‘ning oldini olish deb ta’riflaydi: to‘lov sahifalari skriptlari tasdiqlangan, yaxlitligi tekshirilgan va monitoring ostida bo‘lishi kerak.

Muddatlar: «future-dated» nimani anglatadi

PCI DSS v4.0 chiqarilganda yangi talablarning bir qismi ma’lum sanagacha eng yaxshi amaliyot deb belgilangan edi. 6.4.3 va 11.6.1 talablari (hamda 12.3.1) uchun bunday sana 2025-yil 31-mart bo‘ldi — buni PCI SSC to‘g‘ridan-to‘g‘ri aytadi. Hozir v4.0.1 versiyasi amal qiladi, ammo bu talablar uchun sana o‘zgarmagan. Demak, muvofiqlikni baholashda (QSA-audit, o‘z-o‘zini baholash) ularning bajarilishi majburiy sifatida tekshiriladi.

6.4.3 talabi: skriptlarni boshqarish

Band to‘lov sahifalarida xaridor brauzerida yuklanadigan va bajariladigan skriptlarga tegishli. Mohiyatan u uchta narsani talab qiladi:

• Avtorizatsiya. Har bir skriptning bajarilishiga ruxsat berilganini tasdiqlovchi usul bo‘lishi kerak.
• Yaxlitlik. Skript mazmuni o‘zgartirilmaganini kafolatlovchi usul bo‘lishi kerak.
• Inventarizatsiya. Barcha skriptlar ro‘yxati, har birining nima uchun kerakligi haqidagi yozma biznes yoki texnik asos bilan yuritiladi.

Muhimi: ro‘yxatga ham o‘z domeningiz skriptlari, ham tashqi serverlardan yuklanadigan uchinchi tomon skriptlari, ham ikkinchi darajada tortiladiganlari (skript boshqa skriptni yuklaydi) kiradi.

11.6.1 talabi: o‘zgarishlarni aniqlash

Band xodimlarni xavfsizlikka ta’sir qiluvchi HTTP-sarlavhalardagi va to‘lov sahifalari mazmunidagi (iste’molchi brauzeri ularni qanday olsa, shunday) ruxsatsiz o‘zgarishlar haqida ogohlantiradigan mexanizmni talab qiladi. Tekshiruv davriy bajariladi; standart chastotani yoki belgilangan intervalga, yoki maqsadli xavflar tahlili natijalariga (12.3.1 talabi) bog‘laydi — aniq ifoda va ruxsat etilgan davriylikni pcisecuritystandards.org saytidagi PCI DSS v4.0.1 matni bo‘yicha tekshiring. Amalda auditorlar o‘zgarish e’tibordan chetda qolmasligini isbotlashingizni kutadi.

Bu kimga tegishli: to‘liq baholash va SAQ A

Talablar to‘lov sahifalari PCI DSS muvofiqlik doirasida bo‘lgan tashkilotlarga tatbiq etiladi. SAQ A o‘z-o‘zini baholashni to‘ldiradigan merchantlar uchun vaziyat alohida. PCI SSC FAQ’iga ko‘ra, 6.4.3 va 11.6.1 bandlari SAQ A’dan chiqarilgan, ammo standartda qolgan. Buning o‘rniga muvofiqlik mezoni paydo bo‘ldi: merchant o‘z sayti skriptlar orqali hujumlarga zaif emasligini tasdiqlashi kerak. Buni ikki yo‘l bilan qilish mumkin — 6.4.3 va 11.6.1 ga o‘xshash texnik choralarni qo‘llash (mustaqil yoki uchinchi tomon yordamida) yoki PCI bilan muvofiq to‘lov xizmatlari provayderidan (TPSP) uning yechimi to‘g‘ri joriy etilganda sahifani bunday hujumlardan himoya qilishini tasdiqlovchi hujjat olish. Mezon merchant sahifasiga provayderning to‘lov shakli o‘rnatilgan (masalan, iframe) holatlarga tegishli; protsessor sahifasiga yo‘naltirishda u qo‘llanilmaydi. Sizga o‘z-o‘zini baholashning qaysi shakli mos kelishini ekvayer va to‘lov tizimlaridan aniqlashtiring.

SAQ A-EP va to‘liq baholash (ROC) uchun 6.4.3 bandi bevosita qo‘llanilishda qoladi.

Talablarni qanday bajarish: amaliy reja

1. To‘lov sahifalarini aniqlang. Qaysi URL’lar karta ma’lumotlarini qabul qiladi va qayta ishlaydi, jumladan o‘rnatilgan shakllar va yo‘naltirishlar.
2. Skriptlar ro‘yxatini tuzing. Brauzerda haqiqatda yuklanadigan hamma narsani avtomatik yig‘ing (hujjatlarda yozilganini emas): o‘z fayllaringiz, uchinchi tomon domenlari, yuklash zanjirlari.
3. Har bir skript uchun asos oling. Egasi kim, nima uchun to‘lov sahifasida kerak. Asoslab bo‘lmaydigan hamma narsani olib tashlang.
4. Avtorizatsiya va yaxlitlikni ta’minlang. Tipik texnik vositalar: manbalarning oq ro‘yxatiga ega Content Security Policy (CSP); statik tashqi skriptlar uchun Subresource Integrity (SRI); muhim skriptlarni o‘zingizda joylashtirish. SRI vendor tez-tez va dinamik o‘zgartiradigan skriptlarga mos kelmasligini hisobga oling.
5. Monitoringni sozlang (11.6.1). Sahifalar va sarlavhalar mazmunini foydalanuvchi ko‘rgan holda avtomatik kuzating va etalondan chetlanishlarda ogohlantiring.
6. Jarayonni o‘rnating. To‘lov sahifasidagi yangi skript kelishuvdan o‘tadi, ro‘yxatni va monitoring etalonini yangilaydi. Bunsiz ro‘yxat bir oydan keyin eskiradi.
7. Dalillarni saqlang. Ro‘yxat, ogohlantirishlar jurnallari, o‘zgarishlar bo‘yicha qarorlar — auditorga davr bo‘yicha artefaktlar kerak bo‘ladi.

Tipik qiyinchiliklar

• Ko‘rinmas bog‘liqliklar. Uchinchi tomon skripti yana bir nechtasini yuklaydi. Manba kodini statik tahlil qilish ularni ko‘rsatmaydi — brauzerda haqiqatda nima bajarilayotganini tahlil qilish kerak.
• Vendorlarning dinamik o‘zgarishlari. Uchinchi tomon xizmatlari kodni ogohlantirmasdan yangilaydi, bu SRI’ni buzadi va yolg‘on signallarga olib keladi.
• Ko‘rsatish uchun CSP. Keng istisnolarga ega haddan tashqari yumshoq siyosat rasman bor, ammo himoya bermaydi.
• Egalari yo‘q. Marketing teglarni qo‘shadi, AT xavfsizligi bu haqda auditda bilib qoladi.

Qanday vositalar yordam beradi

Talablarni CSP, SRI va monitoringning o‘z skriptlari kombinatsiyasi bilan yopish mumkin, ammo bunday yechimni qo‘llab-quvvatlash mehnat talab qiladi. Mijoz qismi xavfsizligi uchun ixtisoslashgan yechimlar inventarizatsiya, yaxlitlik nazorati va ogohlantirishlarni avtomatlashtiradi. AST Cyber Lab portfelida buning uchun DPA Analytics’ning DPA FAST yechimi bor — frontend va JavaScript himoyasi uchun yechim. Imkoniyatlar tafsilotlari va to‘lov sxemangizga qo‘llanilishini mahsulot sahifasida yoki mutaxassislarimizdan aniqlashtiring.

Agar xavfsiz ishlab chiqish jarayonini endigina qurayotgan bo‘lsangiz, umumiy manzaradan boshlang: DevSecOps: qayerdan boshlash kerak va AppSec vositalari sinflari sharhi. Frontend bog‘liqliklarini (npm-paketlar) nazorat qilish — SCA vazifasi, PCI DSS 6-bo‘limning kengaytirilgan talablarini esa ilovalar himoyalanganligini baholash doirasida tekshirish mumkin.

Maqola axborot xarakteriga ega va yuridik maslahat hisoblanmaydi.

Auditorga nimani ko‘rsatish kerak

QSA baholovchisi niyatlarni emas, artefaktlarni baholaydi. 6.4.3 va 11.6.1 uchun oldindan tayyorlang:

• har bir to‘lov sahifasi skriptlarining asos va egasi ko‘rsatilgan dolzarb ro‘yxati;
• avtorizatsiya va yaxlitlik nazorati usulining tavsifi (CSP siyosati, SRI-xeshlar ro‘yxati, kelishuv tartibi);
• o‘zgarishlarni aniqlash mexanizmining tavsifi: aynan nima kuzatiladi, qanchalik tez-tez, ogohlantirishlarni kim oladi;
• baholash davri uchun ishga tushishlar va hodisalarni tahlil qilish jurnallari;
• yangi skript sahifaga kelishuvni chetlab o‘tib tushmasligini ko‘rsatuvchi o‘zgarishlar reglamenti.

Agar skriptlarning bir qismini to‘lov xizmatlari provayderi taqdim etsa, undan yozma tasdiqlar so‘rang va mas’uliyat bo‘linishini qayd eting: uning zonasi qayerda, sizniki qayerda.

Hoziroq nimadan boshlash kerak

Agar muddat allaqachon kelgan, jarayon esa qurilmagan bo‘lsa, quyidagi tartibda harakat qiling: bir-ikki hafta ichida to‘lov sahifalari skriptlarining haqiqiy ro‘yxatini yig‘ing; asoslab bo‘lmaydigan hamma narsani olib tashlang; dalillar to‘plashni boshlash uchun o‘zgarishlar monitoringini yoqing; bir vaqtning o‘zida CSP’ni qattiqlashtiring va yangi skriptlarni kelishish tartibini kiriting. Mukammal arxitekturani kutmang — shaffof rejali qisman bajarish nazoratlarning umuman yo‘qligidan yaxshiroq. Jadval va ruxsat etilgan kompensatsion choralarni o‘z QSA va ekvayeringiz bilan kelishib oling.

Ko‘p so‘raladigan savollar

Manbalar

• PCI SSC Blog: Guidance for PCI DSS E-commerce Requirements Effective After 31 March 2025
• PCI SSC FAQ 1588: SAQ A muvofiqlik mezoni va to‘lov sahifalari skriptlari
• PCI SSC Blog: FAQ Clarifies New SAQ A Eligibility Criteria