Vpogled v bančni račun

Utk je 16. jan 2024 ob 12:45 izjavil:

Dela se samo preko klientov

Razen ko se ne.

Kdaj se pa ne? Uslužbenka na okencu zalaufa database management aplikacijo in ročno napiše SQL za prenos denarja?

nosiyo je 16. jan 2024 ob 12:45 izjavil:

Vse kar implementiraš nič ne pomaga, ker imajo nekateri preveč pooblastil. Ker je to veliko enostavneje in ceneje za implementirat, kot pa če bi res zavarovali stvari. Npr. da mora stranka s podpisom (recimo cert na novi osebni) najprej avtorizirat operacijo (npr. vlogo za kredit) in šele potem odločevalci dobijo vpogled v njegovo kreditno sposobnost. In hkrati da ima vsak vpogled (npr. v spletni banki) v to, kaj je kdo o njem brskal in ni treba pošiljat zahteve o izpisu (po GDPR) in s tem sprožat nekega postopka, ko se 10 ljudi čudi kaj mu je treba odgovorit. To bi recimo bil pomik k višji stopnji varnosti. Ampak je preveč dela oz. denarja. Lažje je pač rečt, da vsak na šalterju vidi vse, ker 1x na leto pa res rabi ta podatek o 1 stranki, zato ga kar pooblastimo da lahko nonstop gleda to za vse stranke.

Spet blebetaš, al pa v vaških firmah, kjer delaš, recimo da delate na tak način (pa ne verjamem), ker vam je lažje.

Utk je 16. jan 2024 ob 12:49 izjavil:

Sej pravim, očitno imaš zelo omejeno iznajdljivost.

Omejen si tukaj samo ti.

Tody je 16. jan 2024 ob 12:54 izjavil:

Mislim katere pravljice nekateri govorite, vsak ERP ima logiranje, 15 let nazaj so imele oraclove baze logiranje, vsak SQL se je beležil itd... Mimo avdita, ki jo dela baza ne more noben account niti sysadmin. Če kdo te avdite pregleduje je druga stvar.

Domet jim je tam do izdelave web strani, potem pa zmanjka.

Ko bo tvoja kolegice pogledala na račun tvojega sodelavca, se bo sprožil alarm, ker za to nima pooblastila.

In jo bodo vrgli iz službe.

Kako to ugotovijo? Tako, da tvoj sodelavec ni bil na banki, kjer bi se identificiral.

Sem opisal, kako so me na banki 'identificirali', tako da praksa je zopet drugačna in ni dovolj zanesljive evidence za preverjanje ali se je res nekdo identificiral ali ne.

WizzardOfOZ je 16. jan 2024 ob 13:03 izjavil:

Domet jim je tam do izdelave web strani, potem pa zmanjka.

V mojem primeru res, zato resno vprašam: kako se debugira take sisteme? Za debug moraš znati ponoviti napako, zato moraš v dev okolju imeti identično stanje (replikacijo podatkov), da lahko to narediš. Kako pridobiš to stanje? Sem zelo skeptičen, da gre to zgolj iz opisa akcij bančne uslužbenke.

Npr. enkrat se mi je pri večji slo. banki zgodilo, da se na računih ni izpisoval naslov v celoti in je manjkal izpis države. Jaz sem to javil. Kako bi odpravil to, če se to dogaja samo pri eni stranki samo pri nekaterih računih?

JanBrezov je 16. jan 2024 ob 13:33 izjavil:

Resno sprašujem: SQL log je feature, ki se ga lahko izklopi, ali ne? Če da, kdo lahko to počne? Ali obstajajo neuradna orodja za manipulacijo loga?

Mogoče to delajo v kaki vaški majhni firmi, da malo prišparajo. Banka si kaj takega ne more privoščit.
Iz teh logov se da namreč restavrirat vse ukaze in jih ponoviti, če bi slučajno prišlo do izgube podatkov na bazi ali kake druge napake.

In da se ni identificiral veš ti, ali pa kdorkoli drugi, kako?

Invictus je 16. jan 2024 ob 14:19 izjavil:

JanBrezov je 16. jan 2024 ob 13:33 izjavil:

Razen, če sva slučajno oba stranki iste banke, ki ima slučajno dodeljenega istega dodeljenega bančnika. Koliko vem, vsake toliko preverijo stanje računa in če imaš "preveč" denarja, ti pričnejno gnjaviti s skladi, varčevalnimi računi in zavarovanji. Vem, ker se mi dogaja to.

Kaj ima isti bančnik tu veze.

Tvoj sodelavec se ni identificiral, do podatkov se je pa dostopalo. Alarm, in leti bančnik iz službe.

Tebi res ni jasno, kako veliki sistemi delujejo.

Ker ona ni šla narediti vpogleda zaradi mene, ampak takrat, ko se sodelavec JE identificiral. Pri tem je bežno videla, da ima oni 3k prihodkov mesečno, nato je kasneje na zabavi povedala meni, kar je videla. Hipotetično govorim, ni se to res zgodilo.

Tebi ni jasno, kako ljudje delujejo.

Invictus je 16. jan 2024 ob 14:22 izjavil:

JanBrezov je 16. jan 2024 ob 13:50 izjavil:

Za debug moraš znati ponoviti napako, zato moraš v dev okolju imeti identično stanje (replikacijo podatkov).

Imaš testne podatke z enako strukturo. Tako se to debugira...

Replikacijo produkcijskih podatkov v dev okolje? Jao bože... Jebeš tak Slo-Tech, ko še osnove niso folku jasne.

Ampak včasih to ni dovolj, enostavno rabiš podatke s produkcije. Ne govorim ravno o replikaciji celotne baze, a neke podatke pa vseeno rabiš. Če ne drugega, vpogled v le-te. V testu si probal največ 50 računov, jaz jih imam 5000. V testu morda noben ni probal vsebine z 4 bajtnimi znaki UTF8 (UTF8MB4) v polju za naslov prebivališča, v produkciji pa je. Mogoče to odkrije tvoj kolega, ki popravlja vsebine, mogoče ne.

Čaki, ta tvoj kolega je imel bulk dostop do podatkov klientov in jih popravljal? Ziher je ob piru povedal nekaj, kar ne bi smel.

Ker mora uslužbenka vpisat s čim si se identificiral.

Case closed, ne more pogledat računa, če ni stranke tam.

nosiyo je 16. jan 2024 ob 14:56 izjavil:

Zanimivo, da se majo eni za jake programerje, potem pa klobasajo take neumnosti kot 'bug v produkciji ne obstaja' Takim domet ne nese dlje od dev in test okolja, ker še v življenju niso nič laufali v produkciji. 30 let na bančnih sistemih my ass.

Vaški tepčki v akciji!!! Noben videl dlje od dveh okolij (dev pa prod) in pametujejo o zadevah o katerih pojma nimajo.

Ne more biti bugov v produkciji. A feature, not a bug!

JanBrezov je 16. jan 2024 ob 14:38 izjavil:

Ampak včasih to ni dovolj, enostavno rabiš podatke s produkcije. Ne govorim ravno o replikaciji celotne baze, a neke podatke pa vseeno rabiš. Če ne drugega, vpogled v le-te. V testu si probal največ 50 računov, jaz jih imam 5000. V testu morda noben ni probal vsebine z 4 bajtnimi znaki UTF8 (UTF8MB4) v polju za naslov prebivališča, v produkciji pa je. Mogoče to odkrije tvoj kolega, ki popravlja vsebine, mogoče ne.

To samo pomeni, da imaš zanič testne podatke...

WizzardOfOZ je 16. jan 2024 ob 14:50 izjavil:

Ker mora uslužbenka vpisat s čim si se identificiral.

Točno to. Meni niso hoteli dati denarja, ker je bila v bazi stara osebna, jaz sem pa prišel z novo.

Če so težava podatki, pomeni, da imaš v osnovi zanič klient program, ki ne preverja vnešenih podatkov.

Ko uvažaš v bazo, pač prej preveriš podatke. Nimaš več kot 1 dan dela da napišeš skripto.

Skratka, z vsakim postoim se kažeš za še večjega amaterja.

Iščeš dlako v jajcu.

Ni softwara brez napak.

Sam za reševanje ne rabiš kopije produkcijske baze.

Pri takem bizarnem primeru je dovolj, da preveriš, če je vstopni podatek unsigned int. Mogoče celo v pravem razopnu...

Ampak verjamem, da danes javaskriptaši tega ne delate, vprašanje je tudi, če sploh znate .

Nikonja je 17. jan 2024 ob 11:27 izjavil:

Pa še dodatek, če bi slučajno dobili "gospo iz šalterja" kako je komunicirala zasebne podatke nepooblaščenim osebam, nebi dobila samo odpoved ampak bi bila kazensko odgovorna. Potem se poraja vprašanje ali bi res rizkiral svojo celotno karijero, zapor i ogromno kazen... samo zaradi tega da prijatelju poveš kolk sodelovec ima plače??? Za to moraš res bit debil!

Meni je sestra delala na banki in je rekla da ni šanse da rizkira svojo trenutno in bodočo karijero (ker nove normalne službe z "računom" na policiji ne bo nikoli dobila) zaradi ene butaste cifre. Celo meni ni hotla poveda nebenega podatka.

To bi naredila pametna in poštena oseba. A niso vsi taki. Obstaja majhen delež ljudi, ki so neumni/škodoželjni/podkupljeni/prisiljeni, da vseeno izdajo podatek. Moja poanta je, da zaradi takih oseb najbolj varnostno dovršen sistem z najboljšim IT-jem pade in moj odgovor OP-ju je, da vpogleda v bančne podatke ni mogoče 100% preprečiti. Mogoče 99%, 100% pa nikakor.

Primer je afera z vpogledi v bančne račune škofa s strani člana SDS. Zakaj je to počel? Je neumen?

Moja druga poanta je, da IT oseba lažje izvede ilegalen vpogled in izdajo podatkov brez kazni.

Invictus, hvala ti, da si umetno inteligenco natreniral toliko, da sedaj postavlja pametna vprašanja. Fajn sta te ponucala.

Invictus je 17. jan 2024 ob 11:24 izjavil:

Pri takem bizarnem primeru je dovolj, da preveriš, če je vstopni podatek unsigned int. Mogoče celo v pravem razopnu...

Ampak verjamem, da danes javaskriptaši tega ne delate, vprašanje je tudi, če sploh znate .

Maš premalo domišljije, da iz tega izpelješ kompleksnejši primer, ki ga ne moreš rešit z parse int? Verjetno še nisi videl znakov, ki jih ni na tipkovnici.

In kaj če pride do napake pri agregaciji podatkov iz transakcijskih sistemov v ta podatkovna središča?

nosiyo je 17. jan 2024 ob 18:05 izjavil:

In kaj če pride do napake pri agregaciji podatkov iz transakcijskih sistemov v ta podatkovna središča?

Pooblaščeni za te podatke (skrbniki podatkov s pooblastili) povedo, kje in kakšna je napaka, program se potegne iz produkcije nazaj v dev okolje, programer ga pa popravi. Potem se opravijo testi (na milijonih in milijonih podatkov). Ko je potrjeno da deluje pravilno, se ga prenese na produkcijsko okolje in se ponovi izdelava agregacije.

JanBrezov je 17. jan 2024 ob 22:08 izjavil:

WizzardOfOZ je 17. jan 2024 ob 20:25 izjavil:

nosiyo je 17. jan 2024 ob 18:05 izjavil:

In kaj če pride do napake pri agregaciji podatkov iz transakcijskih sistemov v ta podatkovna središča?

Pooblaščeni za te podatke (skrbniki podatkov s pooblastili) povedo, kje in kakšna je napaka, program se potegne iz produkcije nazaj v dev okolje, programer ga pa popravi. Potem se opravijo testi (na milijonih in milijonih podatkov). Ko je potrjeno da deluje pravilno, se ga prenese na produkcijsko okolje in se ponovi izdelava agregacije.

No, in ta oseba mora biti usposobljena, da na miljonih podatkov zna odkriti napako. In kdo bi to znal? Verjetno samo razvijalci. Pa ne kar random razvijalec, ampak eden boljših poznavalcev sistema. V tem primeru ni potrebe po prenosu dejanskih produkcijskih podatkov v dev/test okolje, zadostuje, da ta oseba ugotovi scenarij napake, da lahko ostali razvijalci replicirajo enak scenarij z namišljenimi podatki v dev/test okolju.

To pa je tudi oseba, ki jo jaz iščem. Nekdo, ki lahko vidi podatke in ni sumljivo.

Daj daj, preveč ameriških filmov gledaš.
Še odkar sem delal v Sloveniji, developerji NIKOLI niso delali z živimi podatki.
Še baza podatkov se kriptira na backupu.

To se naredi tako, da se naredi skripta za anonimizacijo. Priimki se zamenjajo z drugimi, naslovi, ostali osebni podatki. Transakcijski podatki (npr. promet na računu) se flipajo (zamenjajo) med sabo.

To potem developer dobi v roke, če že mora. V pa sistemih, kjer delam jaz, je bom rekel velikostni razred podatkov nekaj 1000 TB. To sploh ni možno dati na laptop.

Potem so še ponavadi neke redukcijske skripte, da se glede na parametre izvozi samo določeni zanimivi del podatkov tja do 10 GB. Seveda že prej anonimiziran.

Če bi bil na kakšnem koli varnostnem usposabljanju, bi ti tam rekli, da developerji in administratorji uporabljajo double-lock mehanizem.

Za backup administrator požene/naredi konfiguracijo, ključ za kriptiranje je na TPM 2.0, dejansko ljudje delajo s podatki, do katerih sami osebno ne morejo.

Dopuščam možnost, da šalabajzerji v slovenskih firmah nimajo tako visoko razvite kulture poslovanja in razvoja softvera. Samo praktično ni mogoče, da bi nekdo leakal podatke.

Seveda je možno, da nekdo namerNo zlorablja sistem, vendar tudi to praktično ni mogoče, ne da bi pustil sled v AUDIT logih.

Govorim pa o visoko sofisticiranih sistemih. Baza na eni SPAR blagajni zadaj verjetno ni kriptirana.

Pri varnosti je vedno tako, da dosti stane, le redki so pripravljeni (v Sloveniji) dajati dosti denarja za to.

bbbbbb2015 je 17. jan 2024 ob 22:44 izjavil:

JanBrezov je 17. jan 2024 ob 22:08 izjavil:

WizzardOfOZ je 17. jan 2024 ob 20:25 izjavil:

nosiyo je 17. jan 2024 ob 18:05 izjavil:

In kaj če pride do napake pri agregaciji podatkov iz transakcijskih sistemov v ta podatkovna središča?

Pooblaščeni za te podatke (skrbniki podatkov s pooblastili) povedo, kje in kakšna je napaka, program se potegne iz produkcije nazaj v dev okolje, programer ga pa popravi. Potem se opravijo testi (na milijonih in milijonih podatkov). Ko je potrjeno da deluje pravilno, se ga prenese na produkcijsko okolje in se ponovi izdelava agregacije.

No, in ta oseba mora biti usposobljena, da na miljonih podatkov zna odkriti napako. In kdo bi to znal? Verjetno samo razvijalci. Pa ne kar random razvijalec, ampak eden boljših poznavalcev sistema. V tem primeru ni potrebe po prenosu dejanskih produkcijskih podatkov v dev/test okolje, zadostuje, da ta oseba ugotovi scenarij napake, da lahko ostali razvijalci replicirajo enak scenarij z namišljenimi podatki v dev/test okolju.

To pa je tudi oseba, ki jo jaz iščem. Nekdo, ki lahko vidi podatke in ni sumljivo.

Daj daj, preveč ameriških filmov gledaš.

Si slišal kdaj za izraz "truth is stranger than fiction"? Nekateri filmi so po resničnih dogodkih. Nekateri resnični dogodki so neverjetni.

bbbbbb2015 je 17. jan 2024 ob 22:44 izjavil:

Še odkar sem delal v Sloveniji, developerji NIKOLI niso delali z živimi podatki.

A nekdo včasih mora. In mora biti ekspert. Si predstavljam, da so to ex-developerji, ki so napredovali v drugačne nazive, npr. "analitik", "strokovnjak za varnost" itd, verjetno boš ti bolje vedel. Pa v tej moji zgodbi sploh ni važno, kaj oseba je. Bolj važno je, kakšen dostop ima.

bbbbbb2015 je 17. jan 2024 ob 22:44 izjavil:

To se naredi tako, da se naredi skripta za anonimizacijo. Priimki se zamenjajo z drugimi, naslovi, ostali osebni podatki. Transakcijski podatki (npr. promet na računu) se flipajo (zamenjajo) med sabo.

Verjamem, da se. Pa se ti zdi možno, da lahko takšna anonimizacija potencialno "pokvari" bug? Meni se zdi zelo verjetno. Banalen primer: imamo dva komitenta, prvi ima kot naslov prebivališča vrednost null, ki je vir napake. Naredimo omenjeno anonimizacijo in flipamo naslov prebivališča in s tem null pripišemo drugemo komitentu. Zaradi narave poizvedbe test izvedemo samo na prvem komitentu in napake več ni. Če je govora o 1000 TB podatkov in narediš tak mixup, je zelo verjetno, da si problematičen zapis izločil iz procesiranja in napake ni (ker delamo statistiko za 2024, mixup pa problematičnemu zapisu dodeli leto 2018). Ni šans, da napako najdejo na anonimiziranih podatkih.

bbbbbb2015 je 17. jan 2024 ob 22:44 izjavil:

Samo praktično ni mogoče, da bi nekdo leakal podatke.

A se vseeno dogaja. Prilepim še enkrat: Suisse Secrets. Pa ne gre za slovensko banko, gre za Credit Suisse, ki je, citiram z Wikipedije "It is known for strict bank–client confidentiality and banking secrecy. The Financial Stability Board considers it to be a global systemically important bank.". Drugi primer so vpogledi v finančne podatke s strani SDS. Tretji primer je prodaja podatkov iz klicnega centra UKC LJ (ok, to ni banka, je pa isti modus operandi). Za četrti primer ti lahko prilepim video John Oliver-ja o prodaji dolgov, pri čemer banka v bistvu proda excel fajl s podatki komitenta in to zelo žalabajzerskim firmam.

bbbbbb2015 je 17. jan 2024 ob 22:44 izjavil:

Dopuščam možnost, da šalabajzerji v slovenskih firmah nimajo tako visoko razvite kulture poslovanja in razvoja softvera. Samo praktično ni mogoče, da bi nekdo leakal podatke.
Seveda je možno, da nekdo namerNo zlorablja sistem, vendar tudi to praktično ni mogoče, ne da bi pustil sled v AUDIT logih. Pri varnosti je vedno tako, da dosti stane, le redki so pripravljeni (v Sloveniji) dajati dosti denarja za to.

Ravno to je moj argument glede vprašanja OP-ja. Mi smo v Sloveniji, pri nas velikih firm/bank v bistvu ni. Najboljših strokovnjakov nimamo, si jih ne moremo privoščiti, najboljših standardov si tudi ne moremo privoščiti.

Za to ne rabiš sestrične v banki. Ljudje tudi sami povedo. "Halo, Bing! Nekaj drobiža bi rad plasiral, un mi je predčasno vrnil..."

Utk je 16. jan 2024 ob 13:48 izjavil:

Vprašajte državljana R. Goloba, njemu so račun odprli v Romuniji pa sploh ni vedel, in še zmeraj ne vejo kako

Seveda, saj ne more vedeti, ker gre spet za eno navadno SDSovsko laž. Pač SDSovci ves čas lažejo.