Programinė įranga kaip paslauga kiekvieną dieną apdoroja didžiulį jautrios informacijos kiekį. Nuo klientų įrašų ir mokėjimo duomenų iki vidinių verslo operacijų – modernios SaaS platformos tapo patraukliais taikiniais užpuolikams. Vienas saugumo trūkumas gali atskleisti vartotojo duomenis, pakenkti klientų pasitikėjimui ir sukelti ilgalaikių verslo problemų.
Kūrėjams ir „SaaS“ įkūrėjams saugumas nebėra kažkas, ko galima pridėti vėliau. Nuo pat pradžių ji turi būti architektūros, kūrimo darbo eigos, diegimo proceso ir veiklos kultūros dalis.
Tuo pačiu metu įmonių klientai, prieš pirkdami bet kokį SaaS produktą, vis labiau rūpinasi saugumu. Daugelis įmonių dabar tikisi, kad pardavėjai laikysis tokių sistemų kaip SOC 2 reikalavimai, kad parodytų, jog jų sistemos ir inžineriniai procesai yra saugūs, patikimi ir tinkamai valdomi.
Geros naujienos yra tai, kad SaaS programos apsaugai ne visada reikia didžiulės įmonės lygio infrastruktūros. Daugeliu atvejų tvirtą saugumą užtikrina nuoseklus praktinės inžinerijos geriausios praktikos taikymas per visą kūrimo ciklą.
Šiame vadove apžvelgsime svarbiausias strategijas, kurias kūrėjai ir inžinierių komandos gali naudoti siekdami apsaugoti modernias SaaS programas.
Vienas iš labiausiai paplitusių klaidingų supratimų kuriant debesies pagrindu sukurtą SaaS yra prielaida, kad debesų paslaugų teikėjas prisiima visas saugumo pareigas.
Tokios platformos kaip AWS, Google Cloud ir Azure apsaugo pagrindinę infrastruktūrą, įskaitant fizinius serverius, tinklo aparatinę įrangą ir pagrindines debesies paslaugas. Tačiau pati programa lieka jūsų atsakomybė.
Tai apima apsaugą:
- programos kodas
- API
- autentifikavimo sistemos
- debesų konfigūracijos
- vartotojo leidimai
- duomenų bazės
- dislokavimo vamzdynai
Pavyzdžiui, neskelbtinų klientų duomenų saugojimas viešai prieinamame saugyklos segmente nėra debesijos paslaugų teikėjo klaida. Tai yra programos konfigūracijos problema.
„SaaS“ saugumo pagrindas yra supratimas, kur prasideda jūsų atsakomybė.
Autentifikavimo ir autorizacijos gedimai išlieka tarp labiausiai išnaudojamų SaaS platformų spragų.
Saugi autentifikavimo sistema turėtų apimti:
- Daugiafaktoris autentifikavimas (MFA)
- saugus slaptažodžio maišymas naudojant bcrypt arba Argon2
- seanso pasibaigimo valdikliai
- brutalios jėgos apsauga
- „OAuth“ arba „Single Sign-On“ (SSO) palaikymas, jei reikia
Silpna slaptažodžių saugykla vis dar stebėtinai paplitusi. Slaptažodžiai niekada neturėtų būti saugomi naudojant pasenusius maišos algoritmus, pvz., MD5 arba SHA1.
Leidimas yra vienodai svarbus.
Daugelis SaaS programų netyčia atskleidžia jautrias funkcijas, nes vartotojai gauna per daug leidimų. Vaidmenimis pagrįsta prieigos kontrolė (RBAC) padeda apriboti vartotojus tik tuos išteklius ir veiksmus, kurių jiems iš tikrųjų reikia.
Pavyzdžiui:
- palaikymo agentai neturėtų pasiekti atsiskaitymo sistemų
- įprasti vartotojai niekada neturėtų pasiekti administratoriaus API
- pastatymo aplinkos neturėtų atskleisti gamybos duomenų
Mažiausių privilegijų principas žymiai sumažina pažeistų paskyrų poveikį.
API yra šiuolaikinių SaaS programų pagrindas, todėl jos taip pat yra viena didžiausių atakų paviršių.
Kiekvienas viešas API galutinis taškas turėtų būti traktuojamas kaip potencialiai paveiktas užpuolikų.
Kai kurios esminės API saugos praktikos apima:
- patvirtina visą gaunamą įvestį
- normų ribojimo įgyvendinimas
- naudojant trumpalaikius autentifikavimo žetonus
- HTTPS vykdymas visur
- apriboti pernelyg didelį duomenų eksponavimą
- stebėti neįprastus eismo modelius
Kūrėjai taip pat turėtų vadovautis OWASP API saugos 10 geriausių rekomendacijų, kad sumažintų įprastas rizikas, tokias kaip:
- sugadintas autentifikavimas
- nesaugios objektų nuorodos
- injekcijos priepuoliai
- netinkamas turto valdymas
JWT autentifikavimas plačiai naudojamas SaaS programose, tačiau prastas JWT diegimas gali sukelti pažeidžiamumą. Žetonai turi turėti galiojimo laiką, saugų pasirašymo algoritmą ir tinkamus patvirtinimo patikrinimus.
Kita svarbi praktika yra vengti per daug išsamių API atsakymų. Vidinių ID, duomenų bazių struktūrų ar nereikalingų laukų atskleidimas gali padėti užpuolikams susieti jūsų sistemą.
Šifravimas turėtų būti laikomas privalomu šiuolaikinėse SaaS platformose.
Duomenys visada turi būti užšifruoti:
- siunčiamas naudojant HTTPS/TLS
- duomenų bazėse ir saugojimo sistemose
Neskelbtina informacija gali būti:
- klientų įrašus
- mokėjimo duomenis
- vidinius verslo dokumentus
- autentifikavimo kredencialus
- API raktai
Kūrėjai taip pat turėtų vengti kodavimo paslapčių tiesiai į šaltinio kodo saugyklas.
Vietoj to naudokite saugius paslapčių valdymo sprendimus, tokius kaip:
- AWS paslapčių vadybininkas
- HashiCorp saugykla
- Google Secret Manager
- užšifruoti aplinkos kintamieji
Įgaliojimų rotacijos politika dar labiau sumažina ilgalaikio poveikio riziką.
Netgi vidinės kūrimo priemonės turėtų atitikti saugią kredencialų valdymo praktiką.
Neteisinga debesų konfigūracija išlieka viena iš pagrindinių SaaS saugumo incidentų priežasčių.
Inžinierių komandos turėtų reguliariai peržiūrėti:
- ugniasienės taisyklės
- IAM leidimai
- viešasis tinklas
- saugyklos prieigos politika
- duomenų bazės konfigūracijos
Kai įmanoma, gamybos aplinka turėtų būti izoliuota nuo kūrimo sistemų.
Keletas svarbių infrastruktūros saugumo praktikų:
- nenaudojamų prievadų išjungimas
- SSH prieigos apribojimas
- privataus tinklo įgyvendinimas
- naudojant laikinus kredencialus
- įgalinti debesies audito žurnalus
Infrastruktūros kaip kodo (IaC) įrankiai, tokie kaip „Terraform“, padaro diegimą nuoseklesnį, tačiau nesaugūs šablonai taip pat gali atkartoti pažeidžiamumą dideliu mastu.
Saugumo peržiūros turėtų būti kiekvieno infrastruktūros pakeitimo dalis.
Šiuolaikinės SaaS programos labai priklauso nuo CI / CD vamzdynų, kad būtų galima greitai įdiegti. Tačiau nesaugūs vamzdynai gali tapti didelės vertės atakos taikiniais.
Saugi CI / CD darbo eiga turėtų apimti:
- saugomos šakos
- privalomos ištraukimo užklausos peržiūros
- automatizuotas testavimas
- priklausomybės nuskaitymas
- slaptas aptikimas
- artefaktų patikrinimas
Tiekimo grandinės atakų pastaraisiais metais labai padaugėjo, ypač dėl pažeistų atvirojo kodo priklausomybių.
Kūrėjai turėtų:
- reguliariai atnaujinti priklausomybes
- pašalinti nenaudojamas bibliotekas
- pin paketo versijos
- patikrinkite patikimus paketų šaltinius
Automatiniai saugos nuskaitymo įrankiai gali padėti nustatyti pažeidžiamumą prieš įdiegiant, tačiau žmogaus kodo peržiūra išlieka labai svarbi.
Saugumas turėtų tapti diegimo dujotiekio dalimi, o ne atskira pasekme.
Stiprus stebėjimas padeda inžinierių komandoms aptikti įtartiną elgesį, kol jis netampa dideliu incidentu.
Kiekviena SaaS programa turėtų palaikyti centralizuotą registravimą:
- autentifikavimo bandymai
- API prieiga
- infrastruktūros veikla
- diegimo pakeitimai
- administracinių veiksmų
Stebėjimo sistemos turėtų generuoti įspėjimus dėl:
- pakartotiniai nesėkmingi prisijungimai
- neįprasti eismo šuoliai
- privilegijų eskalavimo bandymai
- nenormalus API naudojimas
- neleistini konfigūracijos pakeitimai
Žurnalai taip pat tampa itin vertingi atliekant atitikties auditus ir tiriant incidentus.
Daugelis SaaS kompanijų neįvertina pasirengimo reaguoti į incidentus, kol iškyla tikra problema. Dokumentuotas reagavimo procesas padeda komandoms greitai veikti kritiniais atvejais.
Tai apima:
- apibrėžiant eskalavimo kelius
- paskirstant pareigas
- bendravimo procedūrų dokumentavimas
- išsaugant teismo medicinos įrodymus
Saugumo tikrinimas turėtų būti nuolatinis, o ne atsitiktinis.
Kai kurie svarbūs bandymo metodai:
- prasiskverbimo bandymas
- pažeidžiamumo nuskaitymas
- statinio kodo analizė
- dinaminis programų testavimas
- priklausomybės auditas
Net ir gerai suprojektuotose sistemose gali atsirasti pažeidžiamumų, kai programa vystosi.
Trečiųjų šalių bibliotekos nusipelno ypatingo dėmesio, nes pasenusios priklausomybės dažnai kelia saugumo pavojų gamybos aplinkoje.
Reguliarūs vidaus saugumo patikrinimai taip pat padeda komandoms nustatyti:
- pasenę prieigos leidimai
- nesaugios konfigūracijos
- nepanaudotų infrastruktūros išteklių
- silpni veiklos procesai
Klientų pasitikėjimas yra vienas vertingiausių bet kurio SaaS verslo turtų.
Kūrėjai turėtų aiškiai suprasti:
- kur saugomi klientų duomenys
- kas gali prieiti prie jo
- kaip jis užšifruotas
- kiek laiko jis saugomas
Prieiga prie jautrių duomenų visada turėtų būti registruojama ir stebima.
Atsarginės kopijos ir atkūrimo planavimas yra vienodai svarbūs. Netgi saugios programos gali nutrūkti, atsitiktinai ištryntos ar išpirkos reikalaujančios programos.
Patikimos atsarginės strategijos turėtų apimti:
- automatizuotos atsarginės kopijos
- atkūrimo bandymas
- geografinis perteklius
- saugus atsarginės kopijos šifravimas
„SaaS“ įmonėms augant, joms dažnai reikia pademonstruoti saugos brandą naudodamos atitikties sistemas. Čia tokios platformos kaip SOCLY.io tampa naudingos, nes padeda komandoms organizuoti kontrolę, rinkti įrodymus ir supaprastinti pasirengimą auditui, netrikdant inžinerinių darbų eigos.
Saugiausias SaaS programas kuria komandos, kurios saugą laiko inžinerijos dalimi, o ne atskiru skyriumi.
Saugumo suvokimas turėtų tapti kasdienės plėtros praktikos dalimi:
- saugaus kodavimo standartai
- kodo peržiūros procesai
- vidinis mokymas
- grėsmių modeliavimo diskusijos
- infrastruktūros peržiūros procedūros
Stipri saugumo kultūra skatina kūrėjus aktyviai nustatyti rizikas, o ne laukti audito ar incidentų.
Šis metodas „paslinkimas į kairę“ leidžia komandoms anksčiau kūrimo metu pastebėti pažeidžiamumus, kai juos žymiai lengviau ir pigiau ištaisyti.
Saugumas galiausiai turėtų palaikyti kūrimo greitį ir patikimumą, o ne jį blokuoti.
SaaS programos apsauga yra nuolatinis inžinerinis procesas, kuris vystosi kartu su pačiu produktu.
Stiprus SaaS saugumas pasiekiamas derinant:
- saugus autentifikavimas
- apsaugotos API
- užšifruoti duomenys
- debesų infrastruktūros saugumas
- stebėjimas
- pasirengimas incidentui
- saugios plėtros darbo eigos
Daugelis šių praktikų taip pat natūraliai palaiko šiuolaikinius atitikties lūkesčius ir padeda „SaaS“ įmonėms sustiprinti įmonių klientų pasitikėjimą.
Kai saugumas tampa kasdienio inžinerijos kultūros dalimi, komandos gali judėti greičiau su didesniu pasitikėjimu, kurdamos patikimas, keičiamo dydžio ir atsparias šiuolaikinėms grėsmėms programas.
