Alusta küsimusest: mida me kaitseme?

Kontaktvormiga landing ja kontosid, dokumente ning tellimusi hoidev teenus vajavad eri taseme kaitset. Baas on sama: minimaalne ligipääs, secrets privaatsena, sõltuvused uuendatud ja veasituatsioonid ette planeeritud.

1. Avalik sait ainult HTTPS-iga

Sisselogimisvormid, cookies ja isikuandmed ei tohiks liikuda avatekstina. Seadista TLS ning suuna HTTP HTTPS-i. Enamik kaasaegseid platvorme uuendab sertifikaate automaatselt.

2. Pikad unikaalsed paroolid ja adminidele MFA

Parooli korduvkasutus võib muuta ühe välise lekke ligipääsuks mitmele süsteemile. Admin-kontodel kasuta MFA-d ja tiimis paroolihaldurit, mitte ühist tabelit.

3. Secrets ei kuulu frontend’i ega Git’i

Andmebaasi võtmed, SMTP paroolid, session secrets ja privaatsed tokenid kuuluvad environment muutujatesse või secret storage’isse. Kõike brauserisse saadetut tuleb pidada avalikuks.

4. Kontrolli õigusi serveris

„Kustuta tellimus” nupu peitmine tavakasutaja eest on hea UX, kuid mitte turvalisus. Backend peab iga privilegeeritud päringu puhul rolli kontrollima.

5. Failide üleslaadimine vajab eraldi tähelepanu

  • Piira faili suurust.
  • Kontrolli sisu, mitte ainult laiendit.
  • Ära usalda algset failinime.
  • Hoia kasutajafaile rakenduse koodist eraldi.
  • Riskantsete formaatide puhul kasuta malware scan’i või karantiini.
  • Kontrolli iga privaatse allalaadimise õigust.

6. Valideeri vormid backend’is ja piira päringute sagedust

Frontend-validatsioon parandab kasutusmugavust, kuid seda saab mööda minna. Kontrolli serveris uuesti e-posti, pikkusi, kohustuslikke välju ja lubatud väärtusi. Sisselogimisel ja reset-vormidel kasuta ka rate limit’it.

7. Hoia süsteem uuendatud

Vananenud CMS, plugin või teadaoleva haavatavusega dependency on selge sisenemispunkt. Vaata regulaarselt uuendusi ja eemalda kasutamata sõltuvused.

8. Backup peab olemas olema enne intsidenti

Backup kaitseb mitte ainult ründe eest: vigane migratsioon ja juhuslik kustutamine on väga tavalised. Kopeeri andmebaas ja kasutajafailid ning testi taastamist.

9. Logid aitavad mõista, mis juhtus

Salvesta serverivead ja olulised admin-tegevused, kuid ära logi paroole, tooreid tokeneid ega tarbetuid isikuandmeid.

Minimaalne launch-eelne checklist

  • HTTPS ja turvalised cookies.
  • Secrets ainult environment/secret storage’is.
  • Admin endpoint’id kontrollivad rolle serveris.
  • Adminidele MFA.
  • Vormid ja failid valideeritakse backend’is.
  • Backup ja testitud taastamisprotsess.

10. Suhtu sessiooni nagu konto võtmesse

Brauserisessioon vajab turvalisi cookie seadeid, mõistlikku eluiga ning tühistamist pärast parooli muutmist. Admin-sessioon võib olla tavakliendist rangem.

11. Ära kogu andmeid „igaks juhuks”

Mida vähem tundlikke andmeid hoiad, seda väiksem on võimaliku lekke mõju. Kui sünnikuupäeva pole tellimuse jaoks vaja, ära küsi seda. Määra failidele säilitustähtaeg.

12. Otsusta ette, mida intsidendi ajal teha

Isegi lühike plaan aitab: kes saab teate, kuidas ohtlik funktsioon ajutiselt sulgeda, kus secrets vahetada, kuidas sessioonid tühistada, kust backup taastada ja millised logid alles hoida.

Turvalisus ei ole „üks kord seadistatud” olek. Uued integratsioonid ja rollid muudavad riskimudelit.

Vajad veebilehte, mis ei lõpe ilusa maketiga?

KAMERTON tegeleb disaini ja arendusega alates struktuurist ja kasutajaliidesest kuni production-launch’ini.

Vaata projekte →
Loe edasi
Veebilehe launch-checklist: 37 kontrolli ilma paanikata →Kuidas valida domeen ja hosting nii, et hiljem ei kahetseks →

KAMERTON: Loe teenuse kohta — Veebiteenuse arendus →