Preskoči na sadržaj

40% popusta na cenu rešenjaRezervišite ranu prijavu

NG One
Bezbednost

Bezbednost se ne tvrdi. Ona se dokazuje

Ova stranica ne nabraja principe nego mere, i uz svaku piše gde je sprovedena i šta je dokazuje. Izolacija klijenata stoji u samoj bazi i drže je testovi koji obaraju build. Granica prema poslovnim podacima važi i za nas, jer je postavljena na nivou prava u bazi, a ne na nivou obećanja. Ne posedujemo ISO 27001 sertifikat i nigde na ovom sajtu nećete pročitati da posedujemo — sve ostalo na ovoj stranici možemo da vam pokažemo.

  • Izolacija u bazi (RLS)
  • Control/Data Plane granica
  • Nepromenljiv dnevnik
  • SoD i maker-checker
  • Backup, PITR i restore drill
  • Pristup podrške uz odobrenje

Šta bezbednost ERP-a zapravo znači

Poslovni sistem retko padne zbog napadača spolja. Mnogo češće se pokvari iznutra — kroz nalog koji je video previše, izmenu koju niko nije zabeležio ili backup koji nikad nije vraćen.

Zato NG One bezbednost ne rešava kao sloj oko aplikacije nego kao osobinu modela. Izolacija podataka između klijenata stoji u samoj bazi: politika Row Level Security u režimu FORCE važi za svaki red, a nalog pod kojim aplikacija radi nema pravo da je zaobiđe. To nije filter koji programer sme da izostavi iz upita — to je pravilo koje baza sprovodi i kad je upit pogrešan. Dva testa obaraju build ako se od toga odstupi: jedan proverava da nijedna tabela sa podacima klijenta nije ostala bez politike, drugi pokušava da iz konteksta jednog klijenta pročita i izmeni podatke drugog i traži da ne uspe.

Druga granica je unutrašnja. Upravljanje platformom je zaseban proizvod sa sopstvenom šemom i sopstvenim rolama, a ne najveći nalog u sistemu: platformsko osoblje podrazumevano nema nikakav pristup poslovnim podacima klijenta — ne zato što se uzdržava, nego zato što nad tim tabelama nema pravo u bazi. Kad je pristup zaista potreban, ide kroz jedan jedini put: zahtev sa razlogom, obimom i rokom, odobrenje klijentovog administratora u njegovom sistemu, sesija sa vidljivim banerom koja ističe sama, i zapis u dva dnevnika. Klijent posle dobija izveštaj šta je rađeno.

Treći sloj je dokaz. ERP nije bezbedan dok se restore ne izvede, pa vraćanje iz backup-a kod nas nije stavka u ponudi nego automatizovan mesečni drill — datum njegovog poslednjeg uspeha je vidljiv podatak u pregledu zdravlja klijenta, a ne rečenica koju vam neko izgovori na sastanku. Isti princip važi za autorizaciju: pravilo bez zapisa nije pravilo, pa svaka radnja, svaka izmena konfiguracije i svaki izvoz podataka ostaju u dnevniku koji se ne prepisuje unazad.

Šest principa

Principi nisu parole — svaki je zapisana arhitektonska odluka iz koje sledi bar jedna mera niže na stranici. Ako princip nema meru, on je ukras; ako mera nema princip, ona je slučajnost.

  • Izolacija je osobina baze, ne aplikacije

    Podaci klijenata dele bazu, ali ne dele red. Row Level Security u režimu FORCE, runtime nalog bez prava da je zaobiđe, kontekst klijenta postavljen na početku svake transakcije, i meta-test koji obara build za svako odstupanje. Aplikacija ne može da napravi grešku koju baza ne zaustavi.

  • Fail-closed, ne fail-open

    Kad kontekst nedostaje, kad pravo nije izričito dodeljeno, kad politika nije definisana — odgovor je odbijanje, ne prolaz. Autorizacija se sprovodi na serveru od prvog use-case-a; frontend prikazuje dozvole, ali nikad ne odlučuje po njima.

  • Najmanje pravo, uključujući nas

    Platformsko osoblje nema podrazumevani pristup poslovnim podacima — granica je postavljena na nivou prava u bazi, ne na nivou politike ponašanja. Isto pravilo važi unutar klijenta: opseg podataka je deo autorizacione odluke, a zabrane pristupa zaradama i maržama su posebna dimenzija nezavisna od uloge.

  • Pravilo bez zapisa nije pravilo

    Nepromenljiv dnevnik poslovnih radnji, change log konfiguracije, istorija stanja svakog dokumenta, zapis odluke u svakom odobrenju i evidencija svakog izvoza. Kad se posle godinu dana postavi pitanje ko je šta uradio i pod kojim podešavanjem, odgovor se čita, a ne rekonstruiše.

  • Kritične radnje traže dva čoveka

    Razdvajanje dužnosti sprečava da se nespojiva ovlašćenja skupe kod jednog naloga, a maker-checker traži drugi par očiju tamo gde greška ili zloupotreba najviše koštaju. Na platformskoj strani je to obavezno za suspenziju, gašenje, izuzetak od prava i svako brisanje.

  • Oporavak se dokazuje, ne obećava

    Backup bez izvedenog restore-a je pretpostavka. Kod nas je vraćanje iz backup-a automatizovan drill sa datumom poslednjeg uspeha vidljivim u pregledu zdravlja — merljiv podatak koji možete da tražite kad god poželite, a ne tvrdnja koju proveravate onog dana kad je najgore vreme za to.

Zaštita podataka

Mere koje se odnose na same podatke: gde stoje, ko ih vidi, kako se čuvaju i šta se dešava kad ih tražite nazad.

  • Izolacija klijenta u bazi (RLS)

    Svaka tabela sa podacima klijenta nosi identifikator klijenta i politiku Row Level Security u režimu FORCE. Runtime rola nema pravo zaobilaženja; kontekst se postavlja po transakciji. Meta-test nad šemom obara build ako tabela ostane bez politike ili bez indeksa, a izolacioni test pokušava pristup preko granice i traži da ne uspe. Oba testa prolaze pri svakoj izmeni koda, a njihov rezultat je artefakt u repozitorijumu.

  • Control/Data Plane granica

    Upravljanje platformom živi u zasebnoj šemi sa zasebnim rolama i obaveznom dvofaktorskom prijavom. Platformsko osoblje nema podrazumevani pristup poslovnim tabelama — pravo ne postoji, pa ni upit ne uspeva. Sve što platforma zna o radu klijenta je agregirana i anonimizovana metrika, a dimenzije koje bi otkrile poslovni podatak se hešuju pre nego što napuste klijentov kontekst.

  • Šest slojeva autorizacije

    Uloge i dozvole, opseg podataka, limiti odobravanja, razdvajanje dužnosti, maker-checker i delegacije sa zamenama — svih šest postoji i svih šest se sprovodi na serveru. Sloj koji ne postoji od prvog use-case-a znači da su svi dotad napisani use-case-ovi pisani bez njega; zato NG One nosi svih šest od prve linije, a ne kao sloj koji se naknadno navlači preko gotovog sistema.

  • Razdvajanje dužnosti i maker-checker

    Matrica nespojivih ovlašćenja se proverava i pri dodeli uloge i pri samoj radnji, pa se sukob ne može sastaviti od privremenih prava. Maker-checker traži drugog čoveka na kritičnim radnjama, a šta je kritično određuje klijent konfiguracijom — osim na platformskoj strani, gde je spisak fiksan.

  • Enkripcija osetljivih podataka

    Kolonska enkripcija u mirovanju za lozinke, tajne i lične podatke iz obračuna zarada, uz upravljanje ključevima: rotacija i envelope enkripcija, tako da promena ključa ne znači ponovno šifrovanje svega. Lozinke idu kroz Argon2id. Šta je tačno osetljivo određuje se pri threat modelingu modula, a ne posle isporuke.

  • Nepromenljiv dnevnik

    Append-only zapis poslovnih radnji (ko, šta, kada, nad čime, iz kog konteksta), change log konfiguracije sa starom i novom vrednošću, istorija stanja dokumenta sa uslovom koji je prelaz dozvolio, i zapis odluke u odobrenju — šta je odobravalac video u tom trenutku, a ne šta dokument sadrži danas. Ništa od toga se ne prepisuje unazad.

  • Pristup podrške uz odobrenje klijenta

    Jedini put do poslovnih podataka spolja. Inženjer traži pristup sa razlogom, obimom (po pravilu samo pregled, po modulima) i trajanjem do osam sati; odobrava klijentov administrator u svom sistemu. Sesija radi sa ograničenim opsegom, nosi vidljiv baner, ističe sama i beleži se u oba dnevnika. Klijent dobija kompletan izveštaj. Pre svakog zahteva stoji dijagnostički paket bez ličnih podataka, koji rešava većinu slučajeva bez ulaska u podatke.

  • Antivirusno skeniranje priloga

    Prilozi idu u objektno skladište kompatibilno sa S3, a skeniraju se pre nego što ih sistem prihvati — ne posle. Uz to ide politika zadržavanja po kategoriji dokumenta, usklađena sa arhivskim rokovima.

  • Anonimizacija podataka za test i demo

    Produkcioni podaci se ne kopiraju u test okruženje takvi kakvi jesu. Lični podaci se maskiraju po pravilima zaštite podataka o ličnosti, tako da testno okruženje ima realan oblik podataka bez njihovog sadržaja.

Svaka mera na ovoj listi ima mesto sprovođenja: baza, server ili CI. Nijedna se ne oslanja na to da će interfejs sakriti dugme — autorizaciona odluka koja se donosi u pregledaču nije autorizaciona odluka nego predlog, i tako je i tretiramo.

Produkciona operativa i bezbednosni program

Ovo je deo koji se u ponudama najčešće preskoči, a u incidentu jedini vredi: kako kod stiže u produkciju, šta se vidi dok sistem radi i šta se dešava onog dana kad nešto pukne.

  • Backup, PITR i dokazan restore drill

    Automatski backup uz arhiviranje WAL-a, dakle oporavak do tačke u vremenu, a ne samo do sinoć. Restore se testira automatizovanim mesečnim drilom, a datum poslednjeg uspešnog vraćanja je vidljiv podatak u pregledu zdravlja klijenta. RPO i RTO se definišu po planu isporuke i pišu u ugovor. Backup koji nikad nije vraćen je pretpostavka — zato se restore izvodi po rasporedu, a ne prvi put onog dana kad zatreba.

  • Observability na OpenTelemetry

    Strukturirani logovi sa identifikatorom traga, metrike i tracing kroz OpenTelemetry ka Prometheus, Grafana, Loki i Tempo. Health, readiness i liveness probe, alarmi na odstupanja. Kad nešto krene po zlu, pitanje nije da li imamo logove nego koji red da otvorimo.

  • Feature flags po klijentu

    Isporuka i objavljivanje su razdvojeni: kod ide u produkciju ugašen i pali se po klijentu ili po procentu. Praktična posledica je da rizična funkcionalnost ne stiže svima istovremeno i da se gasi bez novog izdanja.

  • Migracije bez zastoja i povratak verzije

    Izmene baze idu po obrascu expand–contract: nikad destruktivna izmena u istom izdanju sa kodom koji je koristi, pa se stara i nova verzija aplikacije preklapaju bez prekida. Provera u CI-ju traži destruktivne izmene, a povratak na prethodnu verziju aplikacije je deo procedure, ne improvizacija.

  • Upravljanje tajnama

    Tajne žive u okruženju ili u secret store-u, sa rotacijom, i nikad u kodu, u repou ili u logovima. Aplikacija pada odmah ako tajna nedostaje, umesto da radi sa podrazumevanom vrednošću — tiho pokrenut sistem sa praznim ključem je gora varijanta od zaustavljenog.

  • gitleaks u CI-ju i pre push-a

    Skener tajni radi kao hook pre push-a i kao obavezna kapija u CI-ju, pa kredencijal ne stigne ni do grane, a kamoli do izdanja. Ovo nije teorijska mera — u sistemima iz kojih klijenti prelaze commit-ovani token je najčešći nalaz.

  • Threat modeling po modulu

    Model pretnji se pravi pri dizajnu modula, a ne posle isporuke — pitanje šta ovde može da krene naopako postavlja se dok je odgovor još jeftin. Rezultat je konkretan spisak kontrola za taj modul, a ne dokument koji stoji u fascikli.

  • OWASP ASVS kao kriterijum prijema

    ASVS baseline je stavka u Definition of Done svakog koraka, dakle uslov da se korak uopšte zatvori. To je razlika između bezbednosti kao kulture i bezbednosti kao provere pred puštanje u rad, koja uvek stigne prekasno.

  • Nosi AI ili automatizaciju

    Testovi na prompt injection u CI-ju

    AI sloj čita poslovne podatke, pa se prema sadržaju dokumenta ponaša kao prema unosu iz nepoverljivog izvora: tekst u prilogu, e-pošti ili opisu stavke ne može da postane instrukcija. Skup napadačkih upita radi kao kapija u CI-ju, a AI radi pod dozvolama i opsegom podataka korisnika koji ga je pozvao — model nema prava koja korisnik nema.

  • Legal hold i politika zadržavanja

    Zadržavanje podataka je politika po kategoriji dokumenta, usklađena sa zakonskim rokovima čuvanja. Legal hold zamrzava brisanje za obim koji je predmet spora ili kontrole, bez obzira na politiku — i sam se beleži, jer je i zamrzavanje radnja o kojoj neko odlučuje.

  • Izvoz i kontrolisano gašenje

    Klijent u svakom trenutku može da dobije kompletan izvoz svojih podataka; izvoz radi i dok je nalog suspendovan zbog neplaćanja. Gašenje je procedura sa redosledom: izvoz se uručuje pre nego što se bilo šta obriše, brisanje se izvodi kontrolisano i ostavlja dokaz. Svaki izvoz se beleži — ko, šta, kada i u kom obimu.

  • Eksterno penetraciono testiranje

    Eksterni penetracioni test ide po rasporedu: pre svakog talasa puštanja u rad i zatim jednom godišnje. Nalazi ulaze u isti tok rada kao i sve ostalo — vlasnik, rok i test koji sprečava da se ista greška vrati. Rezultat penetracionog testa nije značka za sajt nego ulaz u backlog; pokazuje se vašem timu za bezbednost pod NDA, a ne posetiocima.

Brojevi koji bi ovde delovali ubedljivo — procenti dostupnosti, ocene skenova, broj incidenata — ne stoje na ovoj stranici, jer se sa druge strane ekrana ne mogu proveriti, a neproverljiv broj je marketing, ne podatak. Ono što se proverava su procedure, kriterijumi prijema i testovi u CI-ju. Kroz njih prolazimo sa vašim timom, red po red.

Usklađenost sa propisima o ličnim podacima

Zakon o zaštiti podataka o ličnosti i Opšta uredba (GDPR) traže alate, ne izjave. Evo alata i gde stoje u sistemu.

NG One je napravljen tako da klijent može da ispuni svoje obaveze rukovaoca: da zna koje lične podatke drži, da odgovori na zahtev lica, da dokaže ko im je pristupao i da ih obriše kad rok istekne — osim kad brisanje zabranjuje drugi propis ili legal hold. Naša uloga u tom odnosu je uloga obrađivača, i ona se uređuje ugovorom, ne rečenicom na sajtu.

Ono što platforma nosi kao ugrađenu meru je granica: podaci klijenta su izolovani u bazi, platformsko osoblje ih podrazumevano ne vidi, a svaki pristup podrške se odobrava, ograničava rokom i beleži u dva dnevnika. Anonimizacija za test okruženja postoji upravo zato što je kopiranje produkcije u test najčešći način na koji lični podaci procure iz sistema koji su formalno usklađeni.

Ovde ne tvrdimo ništa što ne možemo da pokažemo. NG One nema ISO 27001 ni SOC 2 sertifikat i ova stranica neće tvrditi suprotno. Sertifikat je uostalom dokument o procesu, a ne o proizvodu — mi radije pokazujemo sam proizvod: model izolacije, šest slojeva autorizacije, dnevnike, kriterijume prijema i testove koji ih obaraju kad neko odstupi. Spremni smo da kroz sve to prođemo sa vašim timom za bezbednost pre nego što potpišete bilo šta.

  • Prava lica na koje se podaci odnose

    Alati za odgovor na zahtev: pregled podataka o jednom licu kroz module, ispravka, ograničenje obrade i brisanje uz proveru zakonskih rokova čuvanja. Zahtev i ishod ostaju u dnevniku, jer se i odgovor na zahtev dokazuje.

  • Evidencija radnji obrade

    Podrška za vođenje evidencije obrada koju rukovalac ima obavezu da održava: koja kategorija podataka, po kom osnovu, koliko dugo i ko joj pristupa. Evidencija se izvodi iz konfiguracije sistema, a ne održava paralelno u tabeli.

  • Maskiranje ličnih podataka van produkcije

    Test i demo okruženja dobijaju podatke sa maskiranim ličnim sadržajem. Oblik podataka ostaje realan, sadržaj ne postoji — pa test okruženje prestaje da bude najslabija karika u zaštiti.

  • Zadržavanje, legal hold i brisanje sa dokazom

    Rok čuvanja je politika po kategoriji, legal hold ga nadjačava dok traje spor ili kontrola, a brisanje pri gašenju je kontrolisan postupak koji ostavlja dokaz da je izvršen. Redosled je uvek isti: izvoz klijentu, pa brisanje.

  • Evidencija izvoza podataka

    Svaki izvoz — iz liste, kroz API ili kao kompletan izvoz klijenta — beleži ko je izvezao, šta, kada i u kom obimu. Bez ovoga izvoz je rupa u tragu kroz koju prođe sve što je dnevnik dotad pažljivo zabeležio.

Konis Software ne poseduje ISO 27001 ni SOC 2 sertifikat i NG One se ne oglašava kao sertifikovan. Ova stranica opisuje mere ugrađene u proizvod i mesto na kome se svaka sprovodi. Uloge rukovaoca i obrađivača, mesto obrade, rokovi obaveštavanja o incidentu i podobrađivači uređuju se ugovorom o obradi podataka o ličnosti.

Kako su podaci jednog klijenta odvojeni od podataka drugog?

Politikom u samoj bazi. Svaka tabela sa podacima klijenta nosi identifikator klijenta i politiku Row Level Security u režimu FORCE, a nalog pod kojim aplikacija radi nema pravo da je zaobiđe — dakle nije reč o uslovu u upitu koji programer sme da zaboravi, nego o pravilu koje PostgreSQL primenjuje na svaki red bez obzira na to kako je upit napisan. Kontekst klijenta se postavlja na početku svake transakcije. Dva testa obaraju build ako se od toga odstupi: jedan proverava da nijedna tabela sa podacima klijenta nije ostala bez politike i bez odgovarajućeg indeksa, drugi iz konteksta jednog klijenta pokušava da pročita, upiše, izmeni i obriše podatke drugog i zahteva da svaki od tih pokušaja padne. Oba prolaze pri svakoj izmeni koda i njihov rezultat je artefakt u repozitorijumu — možemo da vam ga pokažemo.

Može li neko iz Konisa da vidi naše podatke?

Ne podrazumevano, i to nije stvar politike ponašanja nego prava u bazi. Upravljanje platformom je zaseban proizvod sa sopstvenom šemom i sopstvenim rolama; te role nemaju pravo nad poslovnim tabelama, pa upit koji bi ih pročitao ne uspeva ni ako ga neko napiše. Postoji i test koji to dokazuje: pokušaj platform administratora da otvori poslovni podatak mora da vrati odbijanje i da ostavi zapis. Kad je pristup zaista potreban zbog podrške, ide isključivo kroz Support Access — zahtev sa razlogom i rokom, vaše odobrenje u vašem sistemu, sesija sa vidljivim banerom koja sama ističe, zapis u oba dnevnika i izveštaj koji dobijate posle. Pre toga uvek ide dijagnostički paket bez ličnih podataka, koji rešava većinu slučajeva bez ulaska u podatke.

Imate li ISO 27001 ili SOC 2?

Ne. Nemamo nijedan od ta dva sertifikata i nećemo tvrditi ono što ne možemo da pokažemo — ova stranica bi bila ubedljivija sa dve značke, ali bi bila netačna. Ono što imamo je bezbednosni program koji stoji iza svake mere na ovoj stranici: threat modeling pri dizajnu svakog modula, ASVS baseline kao uslov da se korak uopšte zatvori, izolaciju koju drže testovi u CI-ju, enkripciju osetljivih podataka sa rotacijom ključeva, restore koji se dokazuje drilom, pristup podrške isključivo uz vaše odobrenje i eksterno penetraciono testiranje pre svakog talasa puštanja u rad. Ako je sertifikat uslov vaše nabavke, recite nam to na početku razgovora — bolje da to znate sada nego posle šest meseci. Ako je uslov bezbedan sistem, uzmite ovu stranicu i tražite dokaz za svaku stavku; imamo ga za svaku.

Šta se dešava ako izgubimo podatke — koliko se vraća unazad?

Backup je automatski, uz arhiviranje transakcionog loga, što znači oporavak do tačke u vremenu, a ne samo do poslednje noćne kopije. Konkretni RPO i RTO se definišu po planu isporuke i ulaze u ugovor, jer zavise od načina rada i toga koliko izgubljenih minuta vaš posao podnosi. Važnije od brojke je da se restore kod nas dokazuje: vraćanje je automatizovan mesečni drill, a datum poslednjeg uspešnog vraćanja je vidljiv podatak u pregledu zdravlja vašeg naloga — ne morate da nam verujete na reč, pogledajte datum. Backup koji nikad nije vraćen nije backup nego pretpostavka, i pretpostavke se raspadaju upravo onog dana kad na njih računate.

Kako sprečavate zloupotrebu iznutra?

Sa četiri mere koje rade zajedno. Opseg podataka ograničava šta korisnik uopšte vidi, po pravnom licu, magacinu, sektoru ili mestu troška, i to je odluka servera, ne filter u interfejsu. Razdvajanje dužnosti sprečava da se nespojiva ovlašćenja skupe kod jednog naloga, i proverava se i pri dodeli uloge i pri samoj radnji, da se sukob ne sastavi od privremenih prava. Maker-checker traži drugog čoveka na kritičnim radnjama. I nepromenljiv dnevnik čini svaku radnju vidljivom unazad, uključujući izmene konfiguracije i svaki izvoz podataka. Nijedna od te četiri mere sama nije dovoljna; zajedno pokrivaju scenario u kome jedan nalog polako širi svoja prava.

Da li koristite naše podatke za treniranje AI modela?

Ne. AI sloj radi nad vašim podacima da bi odgovorio na vaše pitanje, u vašem kontekstu i uz vaše dozvole i opseg podataka — ali podaci klijenata nisu izvor za treniranje modela. Model gateway ima zamenljivog provajdera, budžet i kvotu po klijentu, vidljiv trošak, redakciju ličnih podataka pre slanja i AI dnevnik u kom stoji koji model i koja verzija upita su korišćeni. Sve što AI odgovori vodi do izvornog dokumenta, jer odgovor bez traga do podatka u ERP-u nije upotrebljiv. A ono što AI predloži ulazi kao nacrt koji čovek potvrđuje — model ne knjiži, model priprema.

Gde se podaci fizički nalaze?

Mesto obrade se dogovara i upisuje u ugovor — to nije formalnost nego ulaz u arhitekturu vaše instalacije. Podržana je i on-prem instalacija sa potpisanom offline licencom, bez potrebe da sistem povremeno proverava licencu preko interneta; za deo klijenata je to uslov, a ne preferencija, i zato je rešeno u licencnom modelu, a ne izuzetkom. Prilozi idu u objektno skladište kompatibilno sa S3, koje može biti i self-hosted. Ako imate zahtev vezan za lokaciju podataka — jurisdikciju, pravno lice koje drži infrastrukturu ili fizičku lokaciju servera — iznesite ga pre potpisa: takav zahtev se ugrađuje u instalaciju, a ne rešava posle nje.

Pozovite svoj tim za bezbednost na ovaj razgovor

Prolazimo kroz model izolacije, autorizaciju, dnevnike, plan oporavka i granicu prema vašim podacima — sa dokumentacijom i testovima na stolu. Radije odgovaramo na teška pitanja sada nego na laka posle potpisa.