PCI DSS: დონე და შესაბამისობა

1) რა არის PCI DSS და ვის სჭირდება იგი

• მიიღეთ გადახდა ბარათებზე (პირდაპირ ან PSP/კარიბჭის საშუალებით),
• დამუშავება/შენახვა/გადაცემა ბარათის მონაცემები (PAN, ვადა, CVV) ან მათი შემცირებული/დაშიფრული ფორმები,
• თქვენ სხვა მეწარმეებისთვის მომსახურების მიმწოდებელი ხართ (ჰოსტინგი, დამუშავება, ანტი-ფროიდი, გადახდის ორკესტრი და ა.შ.), თუ შეგიძლიათ გავლენა მოახდინოთ ამ ბარათების უსაფრთხოებაზე.

ვერსია და ვადები: მიმდინარე ვერსია - PCI DSS v4. 0. მოთხოვნები v3. 2. 1 ამოღებულია; „მომავალი მონაცემთა ბაზა“ პუნქტები v4. 0 ახლა მოქმედებს. ახალი v4-ში. 0: გაძლიერებული MFA, Customized Approach, მიზნობრივი რისკის ანალიზი პროცედურების სიხშირეზე, სეგმენტაციისა და დაშიფვრის დაზუსტება.

2) შესაბამისობის დონე: მერჩანტები და მომსახურების პროვაიდერები

2. 1 მერჩანტები (ვაჭრები)

• მარცხენა 1:> 6 მილიონი გარიგება/წელი ან მოხდა კომპრომისი. საჭიროა წლიური ROC (ანგარიში კომპლექსზე) QSA- სგან ან შიდა ISA- სგან, კოორდინაციის დროს, + კვარტალური ASV სკანერები.
• დონე 2: ~ 1-6 მილიონი/წელი. ჩვეულებრივ - SAQ (თვითშეფასება) + ASV სკანები; ზოგიერთ სქემას/შემქმნელს შეუძლია მოითხოვოს ROC.
• Level 3: ~ 20k-1 მილიონი e-commerce/წელი. ჩვეულებრივ - SAQ + ASV სკანები.
• Level 4: L3 ბარიერების ქვემოთ. SAQ; მოთხოვნები შეიძლება განსხვავდებოდეს შეძენის ბანკისგან.

2. 2 მომსახურების პროვაიდერები

ჩვეულებრივ, 2 დონე; Level 1- ისთვის (დიდი მოცულობა/კრიტიკული როლი ჯაჭვში), იგი ვალდებულია QSA- სგან ROC, ხოლო Level 2 - SAQ-D SP (ზოგჯერ ROC კონტრარგუმენტების/სქემების მოთხოვნით). IGaming- ს აქვს მრავალი PSP/კარიბჭე/მასპინძელი პარტნიორი - SP Level 1.

3) SAQ vs ROC: როგორ ავირჩიოთ

• SAQ A - მხოლოდ redirect/iframe/hosted fields; თქვენ არ გაქვთ ბარათების დამუშავება/გადაცემა/შენახვა.
• SAQ A-EP არის ელექტრონული კომერცია, სადაც თქვენი საიტი გავლენას ახდენს გადახდის გვერდის უსაფრთხოებაზე (მაგალითად, სკრიპტების მასპინძლობა), მაგრამ PAN შედის პროვაიდერში.
• SAQ B/B-IP - ტერმინალები/ანაბეჭდები ელექტრონული შენახვის გარეშე; B-IP არის დაკავშირებული ტერმინალები.
• SAQ C-VT/C - ვირტუალური ტერმინალები/მცირე დამუშავების გარემო, შენახვის გარეშე.
• SAQ P2PE მხოლოდ PCI სერტიფიცირებული P2PE გადაწყვეტილებაა.
• SAQ D (Merchant/Service Provider) - „ფართო“ ვარიანტი ნებისმიერი დამუშავების/გადაცემის/შენახვის, კასტომიური ინტეგრაციის, ორკესტრების და ა.შ.

პრაქტიკა iGaming- ისთვის: სამიზნე გზა - SAQ A/A-EP PAN-safe ნაკადების, ტოკენიზაციისა და მასპინძელი სფეროების გამო. თუ თქვენ გაქვთ საკუთარი გადახდის მომსახურება/ვალტი - ჩვეულებრივ SAQ D ან ROC.

4) სკოპინგი: რა შედის CDE- ში და როგორ უნდა შეამციროს იგი

CDE (Cardholder Data Environment) არის სისტემები, სადაც დამუშავებულია/ინახება/გადადის ბარათის მონაცემები და ყველა დაკავშირებული/გავლენიანი სეგმენტი.

• Hosted fields/iframe/TSP: PAN- ის შეყვანა თქვენი დომენის გარეთ.
• ტოკენიზაცია და ქსელის ტოკენსი: თქვენი სერვისები მოქმედებენ ნიშნებით და არა PAN.
• P2PE: საბოლოო დაშიფვრა სერთიფიცირებული გადაწყვეტილებით.
• ქსელის სეგმენტი: მკაცრი ACL, CDE იზოლაცია დანარჩენი გარემოდან.
• სავალდებულო DLP და ლოგების შენიღბვა, PAN/CVV- ით დამპების აკრძალვა.

V4. 0 დაემატა მიზნების მისაღწევად მეთოდების მოქნილობა, მაგრამ ეფექტურობის მტკიცებულება და მიზნობრივი რისკის ანალიზი სავალდებულოა.

5) PCI DSS v4 „12 მოთხოვნა“. 0 (სემანტიკური ბლოკები)

1. ქსელის დაცვა და სეგმენტი (firevols, ACL, CDE იზოლაცია).
2. მასპინძელთა/მოწყობილობების უსაფრთხო კონფიგურაცია (მძიმე, ძირითადი ხაზები).
3. ბარათის მფლობელთა მონაცემების დაცვა (PAN- ის შენახვა - მხოლოდ საჭიროების შემთხვევაში, ძლიერი კრიპტოგრაფია).
4. მონაცემთა დაცვა გადაცემის დროს (TLS 1. 2 + და ეკვივალენტები).
5. ანტივირუსული/anti-malware და მთლიანობის კონტროლი.
6. უსაფრთხო განვითარება და ცვლილება (SDLC, SAST/DAST, ბიბლიოთეკების კონტროლი).
7. დაშვება საჭიროებისამებრ (Last privilege, RBAC).
8. იდენტიფიკაცია და ავთენტიფიკაცია (MFA დისტანციური წვდომისთვის, პაროლები v4. 0).
9. ფიზიკური უსაფრთხოება (მონაცემთა ცენტრები, ოფისები, ტერმინალები).
10. ლოგიკა და მონიტორინგი (ლოგოების ცენტრალიზაცია, უცვლელი, ალერტები).
11. უსაფრთხოების ტესტირება (ASV სკანერები კვარტალურად, პენტესტები ყოველწლიურად და ცვლილებების შემდეგ, სეგმენტის ტესტი).
12. პოლიტიკოსებისა და რისკების მართვა (პროცედურები, ტრენინგი, რესპირატორული ინციდენტი, რისკების შეფასება, „სტატისტიკური Approach“ დოკუმენტები).

6) სავალდებულო საქმიანობა და სიხშირე

ASV სკანები (გარე) - კვარტალურად და მნიშვნელოვანი ცვლილებების შემდეგ.
დაუცველობა/პატჩინგი - რეგულარული ციკლები (სიხშირეები დასაბუთებულია TRA - targeted risk analysis).
პენტესტები (შიდა/მიმოქცევა.) - ყოველწლიურად და მნიშვნელოვანი ცვლილებების შემდეგ; სეგმენტის შემოწმება აუცილებელია.
ჟურნალები და მონიტორინგი - მუდმივად, რეტენციით და ცვლილებებისგან დაცვით.
პერსონალის ტრენინგი - დაქირავებისას და შემდეგ რეგულარულად.
IFA - CDE- ს მთელი ადმისა და დისტანციური წვდომისთვის.
მონაცემთა სისტემების/ნაკადების ინვენტარი მუდმივად განახლებაა.

7) SAQ არჩევანის მატრიცა (მოკლედ)

მხოლოდ iframe/redirect, PAN- ის გარეშე თქვენ გაქვთ SAQ A.
E-commerce, თქვენი საიტი გავლენას ახდენს SAQ A-EP გადახდის გვერდზე.
ტერმინალები/მიმღები - SAQ B/B-IP.
ვირტუალური ტერმინალი - SAQ C-VT.
მცირე „ბარათის“ ქსელი SAQ C.
P2PE გამოსავალი - SAQ P2PE.
სხვა/რთული/შენახვა/დამუშავება SAQ D (ან ROC).

8) არტეფაქტები და აუდიტის მტკიცებულებები

• ქსელის და მონაცემთა ნაკადების დიაგრამები, აქტივების რეესტრი, მომწოდებლების რეესტრი, ანგარიშების/წვდომის რეესტრი.
• პოლიტიკა/პროცედურები: უსაფრთხო განვითარება, ცვლილების მენეჯმენტი, ლოჯიკაცია, ინციდენტები, დაუცველობა, გასაღებები/კრიპტო, დისტანციური წვდომა, სარეზერვო ასლები.
• მოხსენებები: ASV, პენტესტები (ინკლუზიური სეგმენტი), დაუცველების სკანერები, ცვლილებების შედეგები.
• ჟურნალები/ალერტები: ცენტრალიზებული სისტემა, უცვლელი, ინციდენტების ანალიზი.
• კრიპტო მენეჯმენტი: KMS/HSM პროცედურები, როტაცია, საკვანძო/სერთიფიკატი.
• მტკიცებულებები „Customized Approach“ (თუ გამოიყენება): კონტროლის მიზნები, მეთოდი, ეფექტურობის მეტრიკა, TRA.
• მესამე მხარის პასუხისმგებლობის კონტურები: AoC პარტნიორები (PSP, ჰოსტინგი, CDN, ანტი-ფროიდი), Shared Responsibility მატრიცა.

9) შესაბამისობის მიღწევის პროექტი (ეტაპობრივი)

1. სკოპინგი და GAP ანალიზი: განსაზღვროთ CDE, მიმდებარე სეგმენტები, მიმდინარე ხარვეზები.
2. სწრაფი მოგება: PAN-safe Stream (iframe/hosted fields), tockenization, PAN- ის აკრძალვა Logs- ში, დახურეთ „გარე“ კრეტა დაუცველები.
3. სეგმენტი და ქსელი: იზოლირება CDE, mTLS, firewall-ACL, წვდომა least-privilege, MFA.
4. დაკვირვება: ცენტრალიზებული ლოჯისტიკა, რეტენსია/უსაფრთხოების ჯაჭვი, ალერტები.
5. დაუცველობისა და კოდის მენეჯმენტი: SAST/DAST, patchi, SBOM, დამოკიდებულების კონტროლი.
6. ტესტები: ASV სკანები, შიდა/გარე პენტესტები, სეგმენტის შემოწმება.
7. დოკუმენტები და ტრენინგი: პროცედურები, IR ფლეიბუკები, ტრენინგები, ტრენინგის ჩანაწერები.
8. სერთიფიკაციის ფორმის არჩევა: SAQ (ტიპი) ან ROC; მოლაპარაკება შეძენის/ბრენდთან.
9. წლიური ციკლი: მხარდაჭერა, მტკიცებულებები, რისკების/სიხშირეების გადასინჯვა, გადასვლა.

10) ინტეგრაცია iGaming არქიტექტურასთან

გადახდის ორკესტრი მუშაობს მხოლოდ ნიშნებით; PAN ვერ ხედავს.
Multi-PSP: health-checks, smart-routing, idempotency, ретраи; AoC თითოეული PSP- დან.
ღონისძიების წამყვანი საბურავი/DWH: არა PAN/CVV; ბოლო 4 ციფრის შენიღბვა; DLP კარიბჭეები CI/CD- ში.
3DS/SCA ჩეკები: შეინახეთ მხოლოდ საჭირო ნივთები (გარიგების იდენტიფიკატორები), მგრძნობიარე მონაცემების გარეშე.

11) ხშირი შეცდომები

PAN/CVV- ის ლოგიკა და არასასურველი ნიღბები.
PAN- ის „დროებითი“ განლაგება შიდა API/საბურავების საშუალებით.
პენტესტის დროს სეგმენტის ტესტის არარსებობა.
პროცედურების დაუსაბუთებელი სიხშირე (არა TRA v4). 0).
დამოკიდებულება ერთ PSP- ზე AoC- ის გარეშე და fallback- ის გარეშე.
მიუწვდომელი „გავლენიანი“ სეგმენტები (admin-jump-hosts, მონიტორინგი, ზურგჩანთები).

12) სწრაფი დაწყების სია (iGaming)

• გადასვლა hosted fields/iframe; ამოიღეთ PAN- ის შეყვანა თქვენი ფორმებიდან.
• ჩართეთ ტოკენიზაცია/ქსელის ნიშნები; გამორიცხეთ PAN მოვლენებიდან/ლოგოებიდან.
• ჩაატარეთ CDE სკოპინგი და სეგმენტის იზოლაცია (MFA, RBAC, mTLS).
• ცენტრალიზებული ლოგებისა და ალერტების კონფიგურაცია (უცვლელი, რეტენსია).
• ASV სკანების გაშვება, კრიტიკული/მაღალი აღმოფხვრა.
• ჩაატარეთ პენტესტები (შიდა/კონტეინერი). + სეგმენტაციის ტესტი.
• მოამზადეთ პოლიტიკოსები/პროცედურები და შესრულების მტკიცებულებები.
• კოორდინაცია გაუწიოს სერთიფიკატის ფორმას შეძენის ტიპთან (SAQ ტიპი/ROC).
• AoC- ის ყველა მიმწოდებლის მიღება და შენახვა.
• ჩამონტაჟეთ PCI კონტროლერი გამოშვების ციკლში (SDLC, IaC-hardning, DLP CI/CD).

13) FAQ მოკლედ

საჭიროა QSA? ROC- ისთვის - დიახ. SAQ- სთვის ხშირად საკმარისია თვითდაჯერებულობა, მაგრამ ბევრ შეძენას/ბრენდს შეუძლია მოითხოვოს QSA/ASV პარტნიორი.
თუ ჩვენ არ ვიცავთ PAN? ერთი და იგივე, თქვენ მოხვდებით PCI DSS- ს ქვეშ, თუ მიიღებთ ბარათებს. შეეცადეთ მიაღწიოთ SAQ A/A-EP.
3DS წყვეტს PCI? არა. 3DS - ავთენტიფიკაციის შესახებ; PCI - მონაცემთა დაცვის შესახებ.
საკმარისია TLS? არა. ჩვენ გვჭირდება ყველა შესაბამისი მოთხოვნა v4. 0, მათ შორის პროცესები და მტკიცებულებები.

14) რეზიუმე

IGaming- ისთვის, ოპტიმალური სტრატეგია არის შეკუმშვის შემცირება (PAN-safe, ტოკენიზაცია, მასპინძელი fields, P2PE, სადაც შესაძლებელია), CDE მკაცრად სეგმენტირება, ავტომატიზაცია/დაუცველობა/პენტესტები, შეაგროვოს არტეფაქტების სრული პაკეტი და შეარჩიეთ დადასტურების სწორი ფორმა (SAQ Q Q Q ან RC C C C C C C C C) თქვენი დონე. ეს ამცირებს რისკს, აჩქარებს ინტეგრაციას PSP- სთან და მხარს უჭერს სტაბილურ კონვერტაციას და მონეტიზაციას ბარათების ბრენდების მოთხოვნების შესაბამისად.