Ordainketen segurtasuna: zer ez duzun inoiz gorde behar eta zergatik sinatzen diren webhook-ak

Txartelak onartzeak PCI DSS estandarra betetzera behartzen du. Berri ona da betetze horren zatirik handiena eskuordetu daitekeela: zure zerbitzariak inoiz txartel-zenbaki bat ikusten ez badu, lan ia guztia zure hornitzaileak eramaten du. Txarra da hori hondatzeko bi modu erraz daudela.

Gorde ezin dituzun datuak, ezta zifratuta ere

Estandarrak bereizten ditu babesarekin gorde daitezkeen datuak eta ordainketa baimendu ondoren inoiz gorde ezin direnak:

• Atzealdeko edo aurrealdeko hiru edo lau digituko egiaztapen-kodea.
• Banda magnetikoaren edo txiparen eduki osoa.
• PINa edo haren bloke zifratua.

Horiek zifratzeak ez du konpontzen: debekua biltegiratzeari buruzkoa da, ez formatuari. Txartel-zenbakia baldintza zorrotzetan gorde daiteke, baina galdera zuzena ia beti bestelakoa da: zertarako nahi duzu? Kobrantza errepikakorretarako bada, behar duzuna token bat da, ez zenbakia.

SAQ A: ia guztientzako helburu zentzuzkoa

Autoebaluazio-galdetegirik arinena, SAQ A izenez ezaguna, txartel-datuen jasotzea erabat kanpoan uzten duten merkataritzentzat dago pentsatuta: formularioa ordainketa-hornitzaileak zerbitzatzen du iframe baten barruan edo birbideratze bidez, eta zure orriak ez du inoiz zenbakia ukitzen.

Alde praktikoa itzela da: zure azpiegitura babestu, segmentatu eta auditatu behar izatetik galdetegi labur bat erantzutera pasatzen zara. Trukean, formularioa jada ez da zurea, horrek dakartzan diseinu-mugekin, eta edozein lasterbidek —zenbakia «une batez» jasotzea birbidaltzeko— erregimen horretatik ateratzen zaitu abisatu gabe.

Tokenak: izen bereko bi gauza desberdin

• Hornitzailearen token batek txartel-zenbakia ordezkatzen du zure sistemaren barruan. Txartela berriro eskatu gabe kobratzeko balio du, baina hornitzaile horrekin bakarrik funtzionatzen du.
• Sare-token bat, Apple Pay edo Google Pay atzean dagoena, txartel-sareak berak jaulkitzen du eta eragiketa bakoitzean aldatzen den kriptograma batekin dator. Norbaitek atzematen badu, ez dio ezertarako balio.

Bi kasuetan ideia bera da: datu sentikorrak zirkulatzeari uzten dio. Logika bera da sarbide-baimen bat zure zerbitzarian bizi behar dela eta ez mugikorrean dioena, aplikazioetako ordainketak artikuluan azaltzen den bezala.

Zergatik sinatzen diren webhook-ak

Ordainketa bat osatzen denean, bezeroaren nabigatzailea zure webera itzultzen da itzulera-URL batekin. URL hori ez da iturri fidagarria: bezeroak kontrolatzen du, eta edonork bisita dezake. Zure sistemak eskaera ordaindutzat markatzen badu nabigatzailea `/eskerrikasko` orrira itzuli delako, segurtasun-arazo bat duzu, ez inplementazio-xehetasun bat.

Iturri fidagarria webhook-a da: zerbitzaritik zerbitzarirako dei bat, zure ordainketa-hornitzailetik, sinatuta. Ohiko sinadura mezuaren gorputz zehatzaren HMAC-SHA256 bat da, partekatutako sekretu batekin, goiburu batean bidalia. Ondo egiaztatzeak lau arau ditu:

• Sinatu eta egiaztatu gorputz gordinaren gainean, JSONa parseatu aurretik. Gakoak berrantolatzeak sinadura aldatzen du.
• Alderatu denbora konstantean, ez kate-konparazio arrunt batekin.
• Egiaztatu mezuaren antzinatasuna denbora-markarekin badator, atzemandako eskaera batek hilabete beranduago balio ez dezan.
• Izan idenpotentea: gertaera bera hainbat aldiz iritsi daiteke. Bi aldiz prozesatzeak ez du bi aldiz sarbidea eman behar, ezta bi faktura egin ere.

Eta beste arau bat: sinadurak balio ez badu, erantzun zuzena errore bat da, ez «badaezpada ere prozesatzen dut» bat.

Zenbatekoa zerbitzariak erabakitzen du

Azken klasikoa: bezerotik datorren zenbatekoa onartzea. Formulario bat, URLko parametro bat edo ezkutuko eremu bat editagarriak dira. Kobratu beharreko zenbatekoak beti zerbitzariko katalogotik atera behar du; bezeroak bidaltzen duena, gehienez ere, produktuaren erreferentzia da. Kobrantzaren hiru faseak —eta balidazio bakoitza non kokatzen den— nola funtzionatzen duen txartel bidezko kobrantza batek artikuluan deskribatuta daude.

Erregistroak: gutxiago hobe

Ordainketa-sistemek erregistro asko sortzen dituzte, eta hor amaitzen dute datuek ustekabean isuritzen: sinadura-goiburu osoak, moztu gabeko webhook-gorputzak, posta elektronikoak eta helbideak testu lauan. Erregistratu identifikatzaileak eta egoerak, ez edukiak, eta zehaztu zenbat denbora gordetzen diren. Inork kontsultatzen ez duen eta inork ezabatzen ez duen erregistro bat eraso-azalera besterik ez da.

Laburbilduz

Kobrantza baten segurtasuna erabaki aspergarrietan jokatzen da: behar ez duzuna ez gordetzea, nabigatzailea ez sinestea, sinadurak behar bezala egiaztatzea eta idenpotentea izatea. Horietako ezer ez da bezeroarentzat ikusgai, eta dena nabaritzen da zerbait gaizki doan egunean. Segurtasunari eta araudiari buruzko gainerako artikuluak ikus ditzakezu, edo ordainketa baten egoerak nola irudikatzen diren demoan.