Säkerhetschecklista innan första betalande kund

Inloggning och lösenord

• Lösenordshashning med en modern algoritm (argon2 eller bcrypt) via ramverket eller leverantören, plus begränsning av antal försök på inloggning och återställning.
• Sessioner som går ut, ogiltigförklaras vid utloggning och lösenordsbyte, och lagras i httpOnly-kakor i stället för local storage.
• Lösenordsåterställning som aldrig avslöjar om en e-postadress finns och vars länk går ut inom en timme.
• Tvåfaktorsinloggning tillgänglig för administratörer nu och för kunder när de frågar; B2B-köpare frågar tidigt.

Behörigheter och roller

Det vanligaste allvarliga felet i tidig SaaS är ingen listig attack utan en saknad kontroll: en användare ändrar ett id i adressen och ser ett annat företags faktura. Behörighet måste upprätthållas där datan läses, med organisationens id hämtat från sessionen och aldrig från anropet.

Hemligheter och miljöinställningar

Databaslösenord, nycklar till betalleverantören och signeringshemligheter läcker på förutsägbara sätt: incheckade i git, inklistrade i en chatt, inbakade i ett paket som skickas till webbläsaren. Vart och ett går att undvika med en regel och ett verktyg.

• Hemligheter ligger i driftplattformens miljökonfiguration eller en hemlighetshanterare, aldrig i kodförrådet, och en skanner före incheckning stoppar misstag.
• Separata nycklar för utveckling, test och produktion. En läckt testnyckel får inte röra riktiga pengar eller riktiga kunder.
• Betalhemligheter stannar på servern. Bara publicerbara nycklar når webbläsaren, och webhooks verifierar leverantörens signatur.
• Byt varje hemlighet som någonsin delats via chatt eller mejl, i dag, och skriv ned vem som får byta vad.

Säkerhetskopior och återställningstest

En säkerhetskopia ni inte återställt är en förhoppning, inte en kontroll. Hanterade databaser säkerhetskopierar automatiskt, men frågorna som spelar roll är om ni kan få tillbaka en viss kunds data till en viss tidpunkt, hur lång tid det tar och om fillagringen ingår.

Loggning och incidentplan

Enligt GDPR ska ni kunna bedöma en incident och, om det krävs, anmäla den till IMY inom 72 timmar från att ni upptäckt den. Det är omöjligt utan loggar som säger vem som kom åt vad, och en plan kort nog för att en stressad grundare ska följa den.

1. Logga inloggningar, adminåtgärder, dataexporter och nekade behörighetskontroller, med tidsstämplar och användar-id, sparade i minst nittio dagar.
2. Larma på avvikelser ni kan definiera i dag: många misslyckade inloggningar, export av en hel kund, en ny administratör skapad.
3. Skriv en incidentplan på en sida: vem som rings, hur åtkomst spärras, vilka kunder som informeras, vem som kontaktar IMY, var tidslinjen skrivs.
4. Lista era underbiträden och var data driftas; kunderna kommer att fråga i sitt första säkerhetsformulär.

Byggdes er första version snabbt och ni är osäkra på vilka punkter som håller täcker en skalnings- och härdningsinsats precis den här listan, och ett 15-minuterssamtal räcker för att säga vilka punkter som brådskar. Priser finns på prissidan.

När det här är mer än ni behöver

Är produkten gratis, lagrar inga personuppgifter utöver en e-postadress och används av folk ni känner, gör punkterna om inloggning och hemligheter och låt resten vänta tills pengar eller kunddata kommer. Säljer ni till ett reglerat storföretag är listan golvet, inte taket; de kommer att be om SOC 2- eller ISO 27001-underlag och det bör ni planera med en rådgivare, inte en checklista. Vår GDPR-guide för SaaS-grundare täcker pappersarbetet.

Vanliga frågor