Începe cu propriul audit
Munca a început cu o revizuire a întregii platforme, făcută de oamenii care o cunosc cel mai bine. Constatările au fost grupate după gravitate și reparate în modificări mici, ușor de revizuit, nu într-un singur release mare de securitate. Fiecare modificare putea fi oprită separat, astfel încât un fix care se purta greșit în producție să poată fi retras fără să fie retrase și celelalte.
Un fix de securitate nu are voie să strice un client
O regulă a guvernat munca. Un fix care schimbă ce poate face integrarea unui client plătitor este o decizie de produs, nu un fix de securitate. Acolo unde un fix ar fi schimbat contractul pe care construiesc clienții, am păstrat contractul și am restrâns ce stă în spatele lui. Un hardening care strică integrări este dat înapoi, iar atunci nimic nu mai este mai sigur.
Garduri care refuză implicit
Rezultatul de durată nu este o listă de patch-uri. Este un set de garduri care refuză implicit și permit doar ce a fost permis explicit. Orice lucru nou pornește închis și trebuie deschis intenționat. Când un pas este uitat, rezultatul este o eroare la testare, nu o expunere în producție.
Izolare între tenanți care nu poate fi uitată
Pe o platformă multi-tenant, întrebarea din spatele fiecărei cereri este ale cui sunt datele. Răspunsul se decide pe server, niciodată din ce trimite clientul. Accesul la date este scris astfel încât clientul căruia îi aparțin să trebuiască precizat, iar verificările de permisiuni se uită la înregistrarea concretă și la cine o deține, nu doar la rolul celui care întreabă. Clienții care au nevoie rulează într-un mediu dedicat, al lor.
Autentificare, sesiuni și chei
Single sign-on și autentificarea în doi pași au fost întărite împotriva reutilizării: o dovadă de identitate folosită o dată nu mai este acceptată a doua oară. Sesiunile se încheie când trebuie. Cheile folosite de integrări sunt ținute separat de sesiunile oamenilor și au puteri mai restrânse, astfel încât o cheie de integrare nu este o cale de intrare într-un cont.
Upload-uri și apeluri către exterior
Fiecare fișier încărcat trece prin aceleași verificări, în aceeași ordine, înainte ca ceva din platformă să încerce să-l citească, iar platforma decide ce este un fișier uitându-se la fișier, nu la numele lui. Refuzurile rămân neutre, astfel încât o eroare să nu explice cum poate fi ocolită. Apelurile pe care platforma le face către sistemele clienților sunt semnate, ca destinatarul să poată verifica de unde vin.
Date sensibile și secrete
Câmpurile sensibile sunt criptate chiar în baza de date, câmp cu câmp, iar secretele care aparțin unui client sunt criptate per client. Cheile de criptare sunt ținute separat de datele pe care le protejează, într-un vault dedicat, și niciodată în repository.
Verificat de unelte, nu de memorie
Mai multe dintre aceste reguli sunt verificate automat. Teste păzesc modelul de permisiuni și lista paginilor publice, astfel încât niciuna să nu se poată schimba din greșeală. Analiza statică interzice tiparele care produc probleme, dependențele sunt scanate pentru vulnerabilități cunoscute, iar un reviewer automat semnalează accesul la date care nu este legat de un client.
Două lucruri pe care le-am spune oricărei echipe
- Nu încărcați niciodată o înregistrare după un id trimis de client ca apoi să vă încredeți în ea pentru restul cererii. Legați fiecare cerere de contul celui care întreabă.
- Nu livrați niciodată un comutator de siguranță care refuză implicit fără să-i livrați și setarea. Primul deploy oprește funcționalitatea pentru toată lumea.