Revolut și cererile false de la autorități: de ce e-mailul verificat nu este suficient

• Confirmat de Revolut, prin declarațiile relatate: o cerere neautorizată a venit de pe un domeniu real al unei autorități, iar compania a transmis informații înainte de a identifica frauda.
• Raportat din notificarea către clienți: datele posibil afectate pot include date KYC și de contact, documente de identitate, selfie-uri de verificare, extrase sau istorice de tranzacții. Nu presupune că fiecare categorie a fost transmisă pentru fiecare client.
• Confirmat de companie: numărul persoanelor afectate nu a fost făcut public, iar Revolut spune că a contactat doar un număr limitat de clienți.
• Necunoscut public: identitatea persoanei care a controlat contul de e-mail, autoritatea implicată, piețele afectate, setul exact de date pentru fiecare persoană și efectul ulterior al divulgării.
• Nu există bază publică pentru a spune că infrastructura Revolut a fost compromisă sau că fondurile clienților au fost accesate.

SPF, DKIM și DMARC pot arăta că un mesaj a trecut prin infrastructura asociată unui domeniu. Ele nu confirmă că persoana care trimite cererea este autorizată, că există un dosar real sau că solicitarea are temeiul și scopul declarate. În acest caz, tocmai folosirea unui domeniu legitim a făcut cererea să pară credibilă.

Aceasta este o concluzie de control, nu o afirmație despre toate mecanismele Revolut: o cerere pentru date sensibile trebuie validată printr-un al doilea canal controlat, separat de mesajul inițial. Procesul trebuie să verifice identitatea instituției, persoana autorizată, referința de caz, baza cererii, aria temporală și aprobarea internă înainte de orice transfer.

• Centralizează cererile de la autorități într-o echipă mică, cu roluri separate pentru validare, aprobare și furnizarea materialului.
• Sună sau folosește un portal oficial cunoscut anterior, nu datele de contact sau linkurile primite în cerere. Documentează cine a confirmat, când și ce a verificat.
• Solicită numai datele strict necesare pentru scopul validat; o cerere largă trebuie escaladată, nu completată automat din comoditate.
• Livrează materialul printr-un canal aprobat, cu destinatar explicit, acces limitat în timp și evidență a fișierelor transmise. Nu atașa seturi sensibile într-un e-mail care poate fi redirecționat sau arhivat necontrolat.
• Păstrează un registru de divulgare: cererea, validarea, aprobatorii, setul de date, metoda de transfer, ora și eventualele excepții.

Testează procesul cu o cerere simulată care provine de pe un domeniu legitim, dar folosește un număr de dosar inexistent. Măsoară dacă echipa oprește cererea, apelează contactul oficial cunoscut și cere aprobarea potrivită înainte de a pregăti date. Exercițiul trebuie să includă juridic, privacy, securitate, operațiuni și proprietarul datelor.

Dacă există o divulgare suspectă reală, blochează cererile similare până la validare, stabilește exact ce s-a transmis și cui, păstrează dovezile și evaluează obligațiile de notificare cu responsabilii competenți. Pregătește comunicări pentru persoanele afectate care avertizează asupra phishingului țintit, fără să inventezi date neconfirmate despre atacator sau impact.

Secretus poate oferi un canal controlat pentru transferul temporar de material sensibil către destinatari autorizați, reducând expunerea prin atașamente și inbox-uri. Decizia de a divulga date, validarea juridică și verificarea autorității rămân responsabilitatea organizației.

Scenariu Awarely, nu un fapt despre Revolut: un furnizor public trimite urgent o solicitare pentru 200 de dosare. Echipa trebuie să afle în 30 de minute cine verifică autenticitatea, cine aprobă proporționalitatea, ce date sunt strict necesare și cum păstrează dovada transferului fără a crea încă o copie necontrolată.