Ko nam zaupate evidence svojih članov, računovodske dokumente in interno komunikacijo, pričakujete, da so vaši podatki varni. V tem prispevku brez tehničnega žargona razložimo, kako je platforma zgrajena in zakaj so vaši podatki v dobrih rokah.

Na kratko: kaj vas ščiti

• Zaščita datotek — datoteke shranjujemo pod naključno generiranimi oznakami, ne pod imeni, ki jih vnesejo uporabniki
• DDoS zaščita — Vercelova globalna omrežna infrastruktura absorbira napade, preden ti dosežejo našo kodo
• Visoka razpoložljivost — frontend, backend in baza podatkov se samodejno okrevajo in prilagajajo obremenitvi
• Brez SQL injekcij — MongoDB nima SQL razčlenjevalnika, zato te vrste napada preprosto niso mogoče
• Šifriranje — TLS/HTTPS na vsaki točki prenosa: brskalnik, API, baza podatkov, zunanji partnerji
• Nadzor dostopa — vsak administrator samostojno določa, katere zavihke in podatke smejo videti člani
• Vgrajena varnost baze — šifriranje v mirovanju in prenosu, obvezna avtentikacija in seznam dovoljenih IP-naslovov
• Varna gesla in seje — bcrypt razpršitev gesel, naključni žetoni za seje, httpOnly piškotki

1. Zakaj sploh pisati o varnosti?

Društva shranjujejo precej občutljivih podatkov: osebne podatke članov, finančne evidence, skenirane dokumente, interne komunikacije. InPerson Platforma je bila zasnovana z mislijo, da mora biti varnost vgrajena v vsako plast sistema — ne le "dodana" naknadno.

Hkrati zaupamo v moč preizkušenih rešitev. Namesto da bi varnostne mehanizme gradili sami od nič, stojimo na ramenih resnih ponudnikov (Vercel, AWS, MongoDB Atlas), ki svoje sisteme vzdržujejo s celimi ekipami varnostnih strokovnjakov.

2. Zaščita pred nepooblaščenim dostopom do datotek

Obstaja vrsta napada, pri kateri napadalec v ime naložene datoteke vstavi znake tipa ../../, s čimer skuša prebrati datoteke zunaj dovoljenega področja. Klasičen primer: namesto pogodba.pdf pošlje ../../etc/passwd.

InPerson to kategorijo napadov odpravlja z arhitekturno odločitvijo, ne z filtriranjem:

• Vsaka naložena datoteka (dokumenti, prejemki, slike objav) se v Amazon S3 shrani pod strežniško generiranim naključnim identifikatorjem — UUID — ne pod imenom, ki ga izbere uporabnik.
• Izvirno ime datoteke se shrani le kot metapodatek v bazi podatkov za prikaz — nikoli pa ne postane del poti do datoteke.
• Ker pot do datoteke ne vsebuje nobenih uporabniških vnosov, ni niza, v katerega bi napadalec sploh lahko vstavljal znake ../.

Enako velja za vse module — dokumente, računovodstvo, e-mail predloge in slike za objave.

3. Zaščita pred DoS napadi in prometnimi sunki

Frontend InPerson platforme teče na Vercelu, ki ima za sabo globalno robno omrežje (anycast infrastruktura). To nam daje DDoS zaščito podjetniške ravni brez lastnih varnostnih sistemov:

• Prometne poplave se absorbirajo na globalnem robnem omrežju, preden dosežejo naše strežnike.
• Vercel samodejno zaznava in blokira sumljive prometne vzorce in bote.
• Statična vsebina se streže iz predpomnilnikov v bližini končnega uporabnika — manj prometa sploh doseže računalniško infrastrukturo.

4. Zanesljivost: platforma, ki ne "pade"

Vsaka plast InPerson platforme teče na upravljani oblačni infrastrukturi, zasnovani za visoko razpoložljivost — ne na enem strežniku, ki ga upravljamo sami.

• Frontend (Vercel): Distribuirano robno omrežje s samodejnim preusmerjanjem v primeru regionalnih težav. Ni ene točke odpovedi.
• API (AWS App Runner): Samodejno skaliranje, pregledi stanja in samodejni ponovni zagon nezdravih instanc. Ni ročnega upravljanja strežnikov.
• Ozadni procesi (AWS Lambda): Generiranje e-mailov in slik teče ločeno od glavnega API-ja — sunki v ozadnih nalogah ne upočasnijo platforme.
• Baza podatkov (MongoDB Atlas): Replikacijski nabor s samodejnim prevzemom ob odpovedi enega od vozlišč. Samodejne varnostne kopije brez naše intervencije.

Ker se vsaka plast skalira in okreva neodvisno, ni ene komponente, katere odpoved bi podrla celoten sistem.

5. Zakaj SQL injekcije pri nas niso mogoče

Klasične SQL injekcije delujejo tako, da napadalec vstavi lastno SQL kodo v poizvedbo na bazo podatkov. InPerson te kategorije napadov ne preprečuje — preprosto ne rabi:

• Namesto SQL uporabljamo MongoDB — dokumentno bazo brez SQL razčlenjevalnika. Napadalcu ni česa "vstavljati".
• Vse poizvedbe v bazo so strukturirani Python slovarji prek Motorja (uradni MongoDB gonilnik) — ne ročno sestavljeni nizi.
• Vsaka zahteva se pred dostopom do baze preveri prek Pydantic sheme, ki zagotovi prave tipe in oblike polj.

Pošteno je dodati: MongoDB ima svojo kategorijo ranljivosti ("NoSQL injekcija"). InPerson to naslavlja z izogibanjem operatorjem za evalvacijo JavaScript kode ($where) in gradnjo filtrov iz validiranih, tipiziranih polj.

6. Vgrajena varnost baze podatkov

MongoDB Atlas — upravljana baza podatkov, ki jo uporabljamo — prihaja z varnostnimi nastavitvami, ki so privzeto vklopljene brez kakršnegakoli dodatnega dela z naše strani:

• Šifriranje med prenosom: vsaka povezava do baze podatkov uporablja TLS.
• Šifriranje v mirovanju: podatki na diskih so šifrirani samodejno.
• Obvezna avtentikacija: anonimnega dostopa ni — vsaka povezava se mora avtenticirati.
• Nadzor omrežnega dostopa: baza sprejema povezave le z izrecno odobrenih IP-naslovov. Celo z ukradenimi poverilnicami napadalec ne more dostopati iz nezaupljivega omrežja.
• Samodejne varnostne kopije: Atlas skrbi za zvezne varnostne kopije in možnost obnovitve na točko v času — brez lastne infrastrukture za varnostno kopiranje.

7. Kdo vidi vaše podatke — in kdo jih ne

InPerson Platforma za nadzor dostopa uporablja model diskrecijskega nadzora (DAC), skopiran na posamezno društvo. Administrator društva — in le on — odloča, kdo ima dostop in do česa.

Dostop je urejen na dveh ravneh:

• Raven 1 — Ali je ta oseba sploh član društva? Vsak račun nosi ekspliciten seznam društev, ki jim pripada. Brez povabila ali odobritve s strani administratorja ni dostopa do ničesar — niti do javnega seznama članov.
• Raven 2 — Katere zavihke smejo videti? Vsak član ima za vsak zavihek (Člani, Dogodki, Računovodstvo, Pošta…) nastavitev "si ogledati / ne sme si ogledat". Samo administratorji društva te nastavitve dodeljujejo ali odvzemajo.

8. Šifriranje od brskalnika do baze podatkov

Vsak "skok" vsake zahteve je šifriran — podatki ne potujejo v odprtem besedilu nikjer vzdolž poti:

• Brskalnik ↔ Vercel: HTTPS/TLS je obvezen; Vercel samodejno pridobi in obnavlja certifikate.
• Frontend ↔ Backend: Next.js strežniški proxy komunicira z AWS App Runner prek HTTPS.
• Backend ↔ MongoDB Atlas: Format mongodb+srv:// TLS uveljavi samodejno.
• Backend ↔ Zunanji partnerji (SendGrid, Google, Stripe…): Vsi klici gredo prek HTTPS z uradnimi SDK-ji posameznih ponudnikov.

9. Gesla in seje — varno shranjeni, varno obravnavani

Vaše geslo v naši bazi podatkov ni shranjeno v obliki, ki bi jo kdo bral. Enako velja za seje prijave:

• Gesla: Razpršena z bcrypt (prek knjižnice passlib) — počasen, soljen algoritem, zasnovan za odpornost na napade s surovo silo in mavričnimi tabelami. Celo popolna kopija baze podatkov ne razkrije gesel v uporabni obliki.
• Seje: Niso JWT-ji, ki jih stranka dekodira ali ponaredi. So naključni, kriptografsko varni žetoni (32 bajtov naključnih podatkov), ki identificirajo le vrstico v naši bazi sej. Žeton sam po sebi ne nosi nobenih informacij.
• Piškotki: Nastavljeni z httpOnly (nedostopni JavaScriptu), secure v produkciji (le HTTPS) in SameSite=Lax.
• Odjava takoj učinkuje: Seje potečejo samodejno in se pri vsaki zahtevi preverijo v bazi — odjava ali administrativni preklic seje učinkujeta takoj.

10. Zaključek: varnost ni obljuba, je arhitektura

Varnost InPerson Platforme ne temelji na eni magični rešitvi, temveč na skupku premišljenih arhitekturnih odločitev: preizkušeni ponudniki oblaka z lastnimi varnostnimi ekipami, vzorci, ki celotno kategorijo napadov izničijo (ne le filtrirajo), in nadzor dostopa, ki se uveljavi na strežniku — ne le v vmesniku.

Platforma se razvija in z njo tudi ta dokumentacija. Ob vsaki spremembi infrastrukture ali varnostnega modela pregled posodobimo.

Imate vprašanja glede varnosti? Pišite nam — radi jih naslovimo konkretno.