e96517f9c3b7c698e193f23493ef9abe.ppt
- Количество слайдов: 24
Retele de POS-uri si schema cu backoffice la banca Raduta Andrei Valentin Disciplina RCI - Master IISC anul II
Informatii generale despre POS-uri Terminalele de tip POS (Point of Sale) sunt dispozitive electronice utilizate, de obicei, in scopul efectuarii de tranzactii financiare folosind carduri bancare. O tranzactie financiara efectuata la un terminal POS are ca scop operatiunea de transfer de fonduri din contul bancar al posesorului de card in contul bancar al comerciantului, autentificarea posesorului in sistemul bancar fiind efectuata prin intermediul cardului bancar al acestuia. O tranzactie financiara de acest tip contine cateva etape specifice, incepand de la setarea sumei de tranzactie, citirea datelor, validarea posesorului de card, si pana la schimbul de pachete intre terminal si un server de autorizare, iar, in cele din urma, decontarea fondurilor la nivel interbancar.
Modalitati de citire a datelor de card In prezent, exista patru modalitati prin care datele de autentificare (la nivel bancar), ale posesorului de card, pot fi transmise catre terminal in cadrul unei tranzactii de plata cu cardul: - prin introducerea chip-ului integrat al cardului in cititorul de chip al terminalului - prin apropierea cardului in mod Contactless (CTLS) de cititorul CTLS de la POS - prin citirea bandei magnetice folosind fanta de citire din POS - prin introducerea manuala (folosind tastatura terminalului) a datelor de card minime necesare identificarii posesorului in sistemul bancar (PAN-ul si data de expirare a cardului)
Aspecte de securitate in cadrul unei tranzactii cu card bancar In prezent, modalitatile de citire in mod contact-chip si in mod CTLS-chip aduc cea mai multa siguranta privind protectia datelor posesorului de card si a minimizarii riscurilor de frauda ce pot sa apara in acest domeniu. In momentul in care se efectueaza o tranzactie prin oricare din cele doua moduri, fluxul tranzactiei (si toate etapele din acesta) trebuie sa respecte anumite norme si standarde de securitate, bine reglementate de entitatile care emit carduri bancare certificate. Cel mai frecvent, aceste entitati sunt Visa, Master. Card si Euroline (dar nu numai). Reuniunea tuturor regulilor si normelor implicate la tranzactii financiare efectuate cu card bancar constituie standardele EMV (Euroline/Master/Visa). Ele trebuiesc respectate de: aplicatia software ce ruleaza de POS, de bancile emitente (cand emit carduri) si de server-ele ce proceseaza tranzactiile.
Administrarea aplicatiilor si parametrilor prezenti pe terminale POS In mod specific, o aplicatie POS contine relativ putine functionalitati de baza. Insa comportamentul aplicatiei, cel mai frecvent, difera destul de mult de la un Comerciant la altul (prin “Comerciant” ne referim la vanzatorul care utilizeaza POS-ul, in scopul incasarii de plati financiare cu cardul). Aceste diferente apar datorita faptului ca tranzactiile trebuie sa aiba un comportament specific locatiei Comerciantului respectiv: in special, in functie de profilul de activitate (1) si de profilul de risc al Comerciantului (2). (1) Astfel, la unele locatii de Comercianti vor fi active anumite functionalitati (tipuri de tranzactii) relevante pentru locatia lui (cum ar prezenta tranzactiei de tip “Vanzare” cu/fara “Cashback” la Vanzatorii din magazine, raportata la prezenta tranzactiilor de tip “Preautorizare” si “Completare” la receptiile de Hotel-uri sau agentii de tip “Rent-a-Car”)
Administrarea aplicatiilor si parametrilor prezenti pe terminale POS (2) Prin “profil de risc”, se poate exemplifica faptul ca se asteapta din partea aplicatiei POS o anumita flexibilitate de a oferi posibilitatea configurarii unor caracteristici specifice ale terminalului din punct de vedere al unor aspecte de securitate, cum ar fi: - posibilitatea de a inhiba/permite in mod controlat utilizarea unor metode de citire a datelor de card (cum ar fi introducere manuala a PAN-ului si a datei de expirare a cardului sau citirea bandei magnetice); - posibilitatea de a inhiba/permite in mod controlat efectuarea unor tipuri de tranzactii ce permit vulnerabilitati de frauda – prin utilizarea abuziva (tranzactii de tip “Returnare”, “Vanzare cu Cashback”, asociate cu configurari ale terminalului ce permit aprobari in mod offline ale unor tranzactii cu sume mai mari decat cele recomandate in mod obisnuit pentru acest mod de autorizare). In aceste cazuri, cel mai frecvent sunt expusi comerciantii. Insa acest nivel de customizare nu se aplica si pentru aspectele de securitate “critice”, reglementate de EMV; acestea sunt bine stabilite si respectate pe parcursul tranzactiei, fiind impuse de POS. In mod standard, ele sunt verificate si validate in timpul certificarii EMV, de entitatile reprezentante (Visa, Master. Card, Euroline, etc).
Administrarea aplicatiilor si parametrilor prezenti pe terminale POS Asadar, gradul de customizare al comportamentului POS-ului trebuie sa fie unul mare, conform cerintelor din piata. Acest lucru se poate face doar prin posibilitatea configurarii a unui numar mare de parametri (in mod uzual depasesc numarul de 400, referindu-ne strict la parametrii ce pot fi schimbati, nu la valori posibile), care trebuiesc administrati intr-un mod cat mai eficient, in special atunci cand reteaua respectiva de terminale POS ajunge sa depaseasca 5 000 -6 000 de terminale, ceea ce se intampla in mod frecvent si in tara noastra. Un exemplu de solutie pentru a administra flote de terminale este un “Terminal Management System” (TMS).
Schema descriptiva pentru traseul datelor privind conexiunea dintre POS-uri si Sistemul de Gestiune a Terminalelor
TMS este o aplicatie de tip „web”, care: - prin intermediul unei baze de date (implementata, de exemplu, prin SGBD-uri precum „SQL Server”) stocheaza, modifica si actualizeaza (efectueaza “updateuri” - transmite in mod „remote”) parametrii sau aplicatia POS ce vor fi folositi/ va rula pe terminalele din diverse retele de POS-uri; - are posibilitatea de a genera rapoarte de update (actualizare) a versiunilor de aplicatie/parametrii ce ruleaza pe fiecare terminal in parte, sau a modului in care acestia au fost actualizati, sau ce erori au aparut in trecut la incercarea de a modifica sau transmite noua versiune de aplicatie POS sau de parametri la terminal; - permite conectarea la terminalele din productie in mod: Ethernet, Gprs, Dial Up; - asigura multiple norme de securizare a informatiilor specifice fiecarui terminal din retea (criptarea bazei de date, mecanisme de acces - la interfata de vizualizare/schimbare a configuratiilor terminalelor – doar pe baza de autentificare de tipul “utilizator/parola”, mecanisme de constrangeri de drepturi per utilizator, declansarea unor anumite actiuni de semnalizare/alarme la efectuarea unor anumite actiuni efectuate de utilizatori); - permite o comunicare criptata (sau beneficiaza de criptarea comunicatiei) cu terminalele POS pe care le gestioneaza: de exemplu prin protocolul SSL sau TLS, sau implementari particulare de criptare/decriptare folosind algoritmi cum ar fi 3 DES; - asigura si alte servicii si mijloace specifice tipului si scopului sau de aplicatie.
Schema descriptiva pentru traseul datelor privind conexiunea dintre POS-uri si entitatile implicate in procesul de autorizare a tranzactiilor financiare
Sunt mai multi factori (ce variaza de la tranzactie) ce influenteaza procesele care se efectueaza in fiecare din nodurile prezente in schema anterioara. De exemplu, prezenta unui Concentrator de pachete nu este in mod obligatoriu necesara, cum ar fi cazul in care terminalele POS utilizeaza comunicatie Ethernet sau GPRS si nu efectueaza criptare SSL a comunicatiei. In acest caz, pachetele sunt transmise direct la procesatorul de pachete de tranzactii, care va determina banca emitenta a cardului (pe baza unor informatii din pachetul receptionat de la terminal) si, dupa o anumita reformatare a pachetului, il va trimite la aceasta. In cazul in care terminalul POS utilizeaza comunicatie Dial Up, este necesara conectarea mai intai la un Concentrator (deoarece acesta asigura interfata de receptionare specifica Dial Up si este capabil sa interpreteze Header-ul TPDU din pachet si sa determine in mod corect catre ce entitate sa ruteze, in continuare, pachetul de date receptionat prin Dial Up) De asemenea, daca terminalele utilizeaza crptare SSL (transmit pachetele de date deja criptate prin SSL sau TLS), acesta este un alt caz ce implica interconectarea lor mai intai la un Concentrator (ce gestioneaza si un server de criptare/decriptare SSL, iar terminalul efectueaza Handshake-ul SSL cu acesta) in scopul decriptarii pachetelor, dupa care pachetele sunt transmise catre Procesatorul de pachete de tranzactii, de obicei printr-o conexiune de tip „vpn”
Un exemplu de flux de autorizare a unei tranzactii financiare efectuata cu card bancar la un terminal POS 1) Introducerea sau preluarea de la casa de marcat(sau de la telefonul mobil - prin intermediul unei aplicatii specifice) a sumei tranzactiei. 2) Citirea datelor de card ale clientului (fie in mod CTLS, fie prin citirea chip - ului, fie prin citirea bandei magnetice, fie prin introducerea manuala a unor date de card). 3) Aplicarea eventualelor restrictii, preconfigurate pe terminal, la nivel de BIN (Bank Identification Number – primele 6 caractere din PAN) pentru PAN-ul cardului respectiv. 4) Daca a fost citit chip-ul cardului in mod CTLS sau contact, se aplica normele de securitate ce implica autentificare mutuala conform normelor EMV: verificare mutuala intre chip-ul CTLS sau chip-ul contact al cardului si terminal prin schimb de certificate si criptari/decriptari (in mod asemanator Handshake-ului SSL), la care, in functie de situtatie si de anumiti factori variabili, se mai pot adauga si metodele CVM (Cardholder Verification Methods), cum ar fi introducerea PIN-ului cardului; Cel mai frecvent, aceasta etapa se finalizeaza cu solicitarea introducerii PIN-ului de catre posesorul de card.
Un exemplu de flux de autorizare a unei tranzactii financiare efectuata cu card bancar la un terminal POS 5) Impachetarea tuturor datelor specifice acelei tranzactii intr-un pachet ce respecta protocolul ISO 8583 (standard ce descrie un format des intalnit de pachete si fluxuri specifice tranzactiilor financiare cu card bancar). 6) Conectarea la retea (GPRS, Ethernet sau Dial Up): fie prin DHCP, fie prin folosirea unui IP static, fie prin apel telefonic catre un modem sau p centrala Dial Up (in mod sincron sau asincron). 7) Daca se foloseste criptare SSL/TLS, terminalul se conecteaza la Concentrator (moment in care loc Handshake-ul SSL/TLS). Daca nu se foloseste criptare SSL/TLS, terminalul se conecteaza direct la Procesatorul de tranzactii. De cele mai multe ori, aceasta conectare reprezinta stabilirea unei conexiuni prin socket, pe baza unor parametri de “Host” deja cunoscuti de terminal : Host IP si Host Port.
Un exemplu de flux de autorizare a unei tranzactii financiare efectuata cu card bancar la un terminal POS 8) Trimiterea pachetului catre Concentrator (iar acesta il ruteaza catre Procesator – prin “tunele” vpn private si folosind criptare SSL/TLS cu alta pereche de certificate SSL/TLS, insa fara a-i altera continutul de informatie utila) sau direct catre Procesator. 9) Procesatorul de pachete de tranzactii determina banca emitenta a cardului utilizat (pe baza unor informatii din pachet), verifica anumite restrictii (dictate de banca acceptatoare a platii – Acquirer - la care este inregistrat contul bancar al Comerciantului), iar daca acestea sunt indeplinite - adauga anumite informatii suplimentare (anumite campuri noi) in pachet, tot conform protocolului ISO 8583, si transmite pachetul catre banca emitenta. 10) Banca emitenta verifica integritatea pachetului si validitatea cardului, precum si daca in contul clientului (posesorului de card) exista suma solicitata in pachetul de tranzactie; in caz negativ la oricare din verificari, respinge tranzactia si trimite un pachet specific (conform protocolului ISO 8583) catre terminal, pe aceeasi ruta pe care a primit pachetul (adica prin Procesator si, eventual, prin Concentrator).
Un exemplu de flux de autorizare a unei tranzactii financiare efectuata cu card bancar la un terminal POS 11) Banca emitenta reimpacheteaza o parte din datele provenite din pachetul de la POS si anumite date noi intr-un nou pachet (conform protocolului ISO 8583) pe care il trimite catre entitati precum Visa, Mastercard, Euroline, in functie de tipul cardului emis. 12) Entitatile Visa sau Mastercard sau Amex (in functie de cardul folosit) transmit catre banca emitenta un raspuns privind aprobarea sau respingerea tranzactiei. 13) Banca emitenta trimite catre Procesatorul de pachete de tranzactii raspunsul. 14) Procesatorul de pachete de tranzactii trimite catre banca Acquirer un pachet care sa indice aprobarea/respingerea tranzactiei; in cazul in care tranzactia a fost aprobata, banca Acquirer inregistreaza contul terminalului implicat, suma tranzactiei, si PAN-ul cardului utilizat in scopul decontarii ulterioare.
Un exemplu de flux de autorizare a unei tranzactii financiare efectuata cu card bancar la un terminal POS 15) Banca Acquirer trimite catre Procesator, la randul ei, raspunsul de aprobare sau respingere a tranzactiei. 16) Procesatorul de pachete de tranzactii trimite catre terminal pachetul (de raspuns) al tranzactiei (daca a fost implicat si un Concentrator pentru conectarea la terminal, pachetul va fi trimis mai intai la Concentrator si acesta il va trimite la terminal. 17) Terminalul analizeaza pachetul de raspuns, trimite informatii relevante despre statusul aprobarii tranzactiei si catre chip-ul cardului (daca tranzactia s-a efectuat prin citirea contact a chip-ului) si asteapta primirea de la chip a aprobarii finale a tranzactiei (chip-ul cardului are un rol important in aprobarea finala a tranzactiei). In acest punct, chip-ul foloseste o parte din datele din pachet, provenite de la banca emitenta, in scopul de a stabili autenticitatea acesteia (pe baza unor informatii - cunoscute de chip si de banca emitenta, care sunt criptate de banca emitenta cu o anumita cheie privata asimetrica si, daca este cazul, de a executa anumite scripturi trimise de banca emitenta specifice tranzactiei respective (deblocare contor pin, resetare contori, etc).
Un exemplu de flux de autorizare a unei tranzactii financiare efectuata cu card bancar la un terminal POS 18) Daca tranzactia este aprobata, terminalul printeaza 2 chitante specifica de aprobare (una pentru client si una pentru comerciant); Daca tranzactia este respinsa (desi a fost aprobata de Host), terminalul printeaza o chitanta specifica de respingere, ce va fi predata catre posesorul de card. Tot in acest caz, formeaza un pachet specific de „anulare automata” („Automatic Reversal”) pe care il trimite la banca emitenta a cardului (Issuer) in scopul anularii decontarii banilor clientului pentru tranzactia curenta.
Concentratoare de pachete de date si Servere SSL Concentratoarele de pachete de date au multiple roluri in cadrul retelelor de terminale POS (de rutare, criptare/decriptare SSL, prelevare de loguri). Ele constituie „noduri” de rutare a pachetelor spre destinatii diferite, in functie de tipul de pachet de date primit de la terminal. Rutarea pachetelor catre destinatii distincte se poate face prin mai multe moduri, printre care si: - Parsarea pachetului primit de la terminal, analiza Header-ului TPDU („Transfer Protocol Data Unit”), identificarea valorii „NII” (Network International Identifier) pentru destinatie, si determinarea urmatorului nod catre care va trimite pachetul, pe baza unor setari efectuate in prealabil (setarea ca pentru anumite valori de „NII” – destinatie primite de la terminal sa ruteze pachetele catre anumite adrese, cum ar fi anumite IP-uri; - Analiza canalului pe care a primit pachetul de date (canal de intrare, de tip „Inbound”) si in functie de acesta - de exemplu in functie de port-ul pe care a receptionat pachetul - determinarea urmatoarei adrese (IP: port) la care va trimite pachetul, pe baza unor setari efectuate in prealabil (la receptionarea pachetelor pe anumite canale de „Inbound”, va ruta aceste pachete pe anumite canale de iesire, adica de tip „Outbond”)
Procesatoare de tranzactii Spre deosebire de Concentratoare, acestea nu doar ruteaza pachetele catre o alta entitate implicata in procesul de autorizare, ci efectueaza operatiuni precum: parsarea integrala a pachetului, analiza si verificarea campurilor componente, validarea formatului si a continutului campurilor pe baza protocolului de comunicatie ISO 8583, schimbarea anumitor campuri sau adaugarea de campuri noi in pachet, etc. - pot fi implicate si in sistemul de gestiune a cheilor utilizate de terminalele POS la criptarea unor date sensibile continute in pachet, specifice posesorului de card. - trebuie sa satisfaca cerintele normelor „PCI DSS” (Payment Card Industry Data Security Standard) in ceea ce priveste nivelul de securitate oferit pentru datele sensibile receptionate de la terminalul POS, despre posesorul de card ce efectueaza tranzactia.
Probleme frecvente de comunicatie intre POS si Host si solutiile de prevenire a duplicarii tranzactiilor In functie de tipul de comunicatie utilizat de un terminal pentru conectarea la reteaua de autorizare, problemele de conectivitate si cauzele lor pot fi foarte variate. - La terminalele cu comunicatie GPRS, de multe ori, datorita gradului de incarcare a retelei, se poate intampla ca pachetele de date sa ajunga greu la destinatie sau chiar sa nu mai ajunga. O alta problema o constituie semnalul slab, cauzat fie de plasarea terminalului intr-o locatie situata la distanta mare de antenele GSM, fie de aparitia problemelor la echipamentele ce asigura conectivitatea GPRS a terminalului la retea. - La terminalele cu comunicatie Dial Up, se intampla frecvent sa apara probleme de comunicatiei atat datorita calitatii slabe a liniei telefonice, dar si a schimbarilor aduse de furnizorii de servicii Dial Up asupra liniilor si echipamentelor (anumite reconfigurari aduse de provideri in scopul altor clienti ce folosesc linia, insa care nu sunt compatibile cu modul de configurare a terminalelor: schimbarea functionarii liniei din SDLC in ASYNC, modificarea ratelor suportate, a formatelor de date, etc)
Probleme frecvente de comunicatie intre POS si Host si solutiile de prevenire a duplicarii tranzactiilor - La terminalele cu comunicatie Ethernet ( LAN), apar probleme cum ar fi pierdere de pachete, esuarea „Handshake” - ului SSL (cauzata de desincronizarea certificatelor si cheilor SSL), receptionarea pachetelor in ordinea gresita sau receptionarea mai multor pachete de date concatenate intr-unul singur, ultima ducand la esuarea verificarii integritatii pachetului receptionat - pe baza algoritmilor de tip „verificare CRC” („Cyclic redundancy check”). O problema specifica la retelele de terminale POS este riscul de „dublare” a unei tranzactii financiare efectuata cu cardul bancar. Aceasta problema este corelata in special cu anumite probleme de comunicatie, de diverse tipuri si cauze, ce apar intr-un moment critic al procesarii tranzactiei: cel mai frecvent scenariu consta in faptul ca se intampla ca terminalul sa trimita pachetul de tranzactie (pachetul de „Request”), acesta ajunge cu succes la Host-ul de autorizare, Host-ul o aproba si trimite catre terminal raspunsul de aprobare al tranzactiei, insa, pe traseul pachetului - intre primul nod (la care Host-ul l-a trimis cu succes) si pana la destinatia finala a pachetului (terminalul POS), comunicatia este intrerupta. in acest caz, POS-ul are obligatia de a trimite catre Host un pachet de “Anulare Automata”.
Schema descriptiva pentru tratarea unei probleme de comunicatie cauzata de lipsa raspunsului de la Host in cadrul efectuarii unei tranzactii
In mod specific acestui tip de speta privind gestionarea problemelor de comunicatie, sagetile „ 8” si „ 9” sunt punctele in care cel mai frecvent apare riscul de dublare a tranzactiei. In absenta unui mecanism de confirmare a receptiei pe baza de “ACK” (Acknowledgment) implementat la nivelul intregii scheme de plata, daca in aplicatia ce ruleaza pe POS nu ar fi implementate mecanisme de prevenire a dublarii, Host-ul nu ar avea cum sa “stie” faptul ca POS-ul nu a mai primit raspunsul si a respins offline traznactia. Un astfel de mecanism (implementat pe POS) este informarea Host-ului de catre POS, prin transmiterea unui pachet special de „Anulare Automata”, reglementat tot prin standardul ISO 8583 („Automatic Reversal” - initiat de terminal), prin care Host-ul este anuntat ca POS-ul a respins tranzactia anterioara in lipsa raspunsului. In concluzie, in momentul receptionarii anularii automate de la POS, Host-ul va fi, de asemenea, obligat sa asigure anularea tranzactiei la nivel contabil, in special in cazul in care ar fi aprobat-o anterior. Important este ca, in cazul respingerii tranzactiei de catre POS, sa ajunga aceasta informatie la toate celelalte entitati implicate in schema de plata. De obicei, este suficienta informarea procesatorului privind respingerea de POS, iar procesatorul se ocupa mai departe de transmiterea pachetului de „Anulare Automata” catre restul de entitati.
Bibliografie 1. http: //www. 3 gpp. org/technologies/keywords-acronyms/102 -gprs-edge 2. http: //www. iso. org/iso/home/store/catalogue_tc/catalogue_detail. htm? csnumb er=68307 3. https: //www. pcisecuritystandards. org/documents/PCI_DSS_v 3 -1. pdf 4. http: //www. iso. org/iso/home/store/catalogue_ics/catalogue_detail_ics. htm? csn umber=54550 5. http: //www. iso. org/iso/home/store/catalogue_tc/catalogue_detail. htm? csnumb er=50941 6. https: //sites. google. com/site/paymentsystemsblog/iso 8583 -financialtransaction-message-format 7. http: //www. iso. org/iso_catalogue/catalogue_ics/catalogue_detail_ics. htm? c snumber=15871
e96517f9c3b7c698e193f23493ef9abe.ppt