Cégeteknél kiknek van root vagy azzal (könnyen) ekvivalens(sé tehető) SQL hozzáférése érzékeny (pl cím, tel, számlák) adatokhoz?

 ( carlcolt | 2018. március 8., csütörtök - 14:36 )
Csak tulajdonosoknak
7% (13 szavazat)
Csak tulajdonosoknak és munka törvénykönyve által nem védett speciális felelősséget vállaló beszámlázó vállalkozó fejlesztőknek
2% (3 szavazat)
Csak tulajdonosoknak és kiemelt, erősen megbízhatónak tűnő alkalmazott fejlesztőknek
9% (17 szavazat)
Tulajdonosoknak és akár nem feltétlen megbízható (próbaidőn lévő, ismeretlen előéletű, stb.) alkalmazott fejlesztőknek is
2% (4 szavazat)
Csak kiemelt, erősen megbízhatónak tűnő alkalmazott fejlesztőknek. Tulajdonosoknak tudás híján nincs access-e, se igénye rá
20% (39 szavazat)
Akár nem feltétlen megbízható (próbaidőn lévő, ismeretlen előéletű, stb.) fejlesztőknek is. Tulajdonosoknak tudás híján nincs
4% (8 szavazat)
Több kiemelt, erősen megbízhatónak tűnő fejlesztő szükséges a root account unlockolásához (pl. boríték HR-nél, tanúk, CCTV)
1% (1 szavazat)
Nem tudom van-e valakinek access-e, de ha van, már valószínűleg találkoztam az illetővel
2% (4 szavazat)
Nem tudom van-e valakinek access-e, és az is lehet, hogy csak olyannak van, akivel sosem találkozok
4% (7 szavazat)
Meggyőződésem, hogy senkinek nincs ilyen jellegű access-e
1% (2 szavazat)
Csak a megrendelőnek van (pl. hosting)
1% (2 szavazat)
Nincs se munkám, se cégem
10% (19 szavazat)
Egyéb, leírom hozzászólásban
6% (11 szavazat)
Egyéb, nem írhatom le hozzászólásban
33% (64 szavazat)
Összes szavazat: 194

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A legfontosabb gép teljesen air gapped (nincs benne hálózat), csak a rajta dolgozónak van user hozzáférése az adatbázishoz a programon keresztül. A fejlesztő csak a helyszínen fér hozzá, ha szükséges, rendszergazdai felügyelet alatt. A rendszergazdai jelszó / SQL "sa" jelszó borítékban lepecsételve, lezárva.

--
trey @ gépház

node mire jo az az adat, ha csak korulmenyesen hozzaferheto?

A legtriviálisabb egy céges root-ca...

ja de CA az egy nagyon specialis szitu.
es semmi koze a topic cimehez.

Én csak a sazerintem legtriviálisabbat emeltem ki, de lehet pénzügyi rendszer, lehet stratégiai tervezésnél hasnzált adatokat tartalazó gép, estébé...

Egyelore az arany jo, mivel az "Egyéb, nem írhatom le hozzászólásban" vezet ;)

Bár nekem gyanúm, hogy a "csak az eredmény érdekel" is oda szavazott...

Napokban szembesültem, hogy egy globális multi 2FA authentikációt használ a Microsoft alapú rendszereihez, a kollégák a privát telefonszámukat adják meg a tokenek küldéséhez.
A telefonszám publikus attribútumként szerepel az AD-jukban.

Ezt nem értem, miért gáz?

mert barmelyik user latja a tobbiek PRIVAT telszamat

nem mintha sokba fajna mostansag egy dual sim-es mobil meg egy prepaid kartya.

Ez most hogy jön ide?

Itt több százezer privát telefonszám (köztük a CEO-é) érhető el, GDPR hatályba lépése után ez egészen szép büntit vonhat maga után.

csak annyi, hogy nem muszaj a privat szamodat megadni.

ja mert annyira jellemzo Mo-n hogy a cegek es iskolak, kutatointezetek minden alkalmazottnak (es diaknak!) vesznek dualsim mobilt meg kartyat hozza...

Nem értem, miért kellene, hogy vegyenek.

Pl. a cégem vett nekem egy iphone SE-t, a benne levő egyetlen sim kártyához rendelt telefonszám van az összes céges rendszerben.

Mellette meg van a saját telefonom. Másik számmal.

mert nem mindenhol vesznek az alkalmazottaknak ceges telefont es sim-et (az most lenyegtelen hogy dual vagy nem), ugyanakkor az alkalmazott nem feltetlen szeretne MINDENKI szamara publikusan megadni a privat telszamat egy token miatt.

Hát akkor kérni kell egy hardveres tokent, vagy egy szoftveres tokent, vagy bekapcsolni pl Azure MFA-ban a push notification-ös 2FA-t. :)

Igen. És?

Arra válaszoltam, hogy szerinted dual sim készülék kellene.

Ha nincs céges telefonszáma az embernek, akkor se kell neki dual sim. Meg ha van, mint nekem, akkor se.

A konkrét példára visszatérve: ha egy tokenhez telefonszám kell, akkor a cégnek kell adnia telefonszámot. Ha nem ad, akkor fel kell készülniük arra az esetre, hogy vannak, akiknek nincs telefonszáma (mert van, akiknek nincs semmilyen mobilja és van aki nem akarja erre használni).

+1

Troll on (bár igaz): nekem volt. Root is, sysdba is, meg SYSTEM, amíg VMS-en dolgoztam.
:)

Akkoriban kezdődött ez a mizéria, hogy nem bízunk meg senkiben, mindenkitől elveszünk mindent...
Viszont kimaradt a komplett üzemeltetés a felsorolásból, ha jól látom.

Ez nem troll, ez történelem :-) Egyébként meg hozott megbízólevelet a kérdező? Nem? Akkor nincs válasz :-P

Lehet, hogy nem ertem a kerdest, de miert lenne a tulajdonosnak hozzaferese ezekhez? Vagy ha nincs, miert feltetelezzuk, hogy azert nincs, mert nem ertene hozza?

Ahol eddig dolgoztam, ott altalaban az eles rendszereken voltak ugyfel adatok, ezeknek a rendszereknek volt nehany uzemeltetoje, akik pl. biztonsagi mentest keszitettek, vagy uj szervereket telepitettek, stb.

Rajtuk kivul szerintem senkinek nem kellett, es ezert nem is volt hozzaferese.

Normalis esetben fejlesztok generalt vagy az elesbol kimasolt es atalakitott adatokkal dolgoztak.

Igen ritkan elofordulhatott, hogy fejleszto eles adatokbol kapott masolatot, es azon dolgozott (pl. o dolgozta ki az eles adatok atalakitasat a tobbi fejleszto szamara, vagy valami hiba kizarolag az eles adatokon jott elo). De ezekben az esetekben altalaban nem az osszes adathoz fertek hozza, es nem az eles rendszerhez.

Egyeb: uzemeltetesnek (lehet, hogy) van, fejlesztoknek, tulajdonosoknak nincs

+1
root miert kene a fejlesztoknek? csak az altaluk mokolt db-hez van. a tulajnak meg nem kell, ugyse tudna vele mit kezdeni

A fejlesztő a fejlesztői DB-hez fér hozzá, abban meg jobb helyen anonimizált/random adatok vannak...

Ja, erre termeszetesen mindenhol van ido, es a vezetoseg/tulajdonosok termeszetesen mindenhol tudjak, hogy milyen fontos, hogy valaki azon dolgozzon napokat, hogy a devek anonim adatokon dolgozzanak (nem, emiatt is a megalmodott feature-uk hatarideje tolodik kijjebb, ok igy gondolkodnak akar az elso GDPR buntiig).

Bele kellett volna írni, hogy kizárólag kkv a célközönség.

Nem tudom, milyen cégeknél dolgoztok, én utoljára a 90-es években dolgoztam 10 fős cégnél... és ott sem az éles rendszeren fejlesztettek a fejlesztők.

Tavaly dolgoztam egy startupnál (ami addigra már kb. 50 fősre nőtt), természetesen nagyon odafigyeltek erre: szerződést úgy kötöttek az ügyféllel, hogy az ügyfél számunkra anonimizált adatot állít elő, és azt kapjuk meg, hogy még véletlenül se legyen gond.

Meg "garazscegnel" sem fejlesztenek az eles rendszeren (talan nagyon ritkan ha nagyon dilettans a tulaj nagyon az elejen). Olyan viszont van, hogy az eles rendszerbol copy-znak par sort dev kornyezetnek, mert az a leggyorsabb. Meg hogy neha kell access a live db-hez mikor valami megy dev kornyezetben de maskepp viselkedik live.

Az eg vilagon senki nem emlitett eles DB-n fejlesztest (halistennek)

Bar nem egyertelmu a valaszlehetosegek szovegezesebol, de a fejleszto helyere az uzemelteto behelyettesitheto. Minel kisebb a ceg annal inkabb egybe is mosodik. Startupnal siman lehet hogy frontendezni vesznek fel CSS-ezni es ket evre ra te indexeled ujra a db-t. Leginkabb multiknal dolgozo hupuk ertettek felre, mert megvannak a maguk kis burkaban.

Azért ez nem egyértelmű. Egy üzemeltető, aki jogosult pl. adatbázis mentést készíteni, az ugye bármikor, bárhova tud mentést kéezíteni, amit aztán akár a saját gépére is visszatölthet (általam ismert rendszereken). Előle kb. nem tudsz adatot elrejteni titkosítás nélkül.
Fejlesztő meg sok esetben külsős, semmi köze a valós adatokhoz.

Bennem a kérdés elolvasása után pedig az merült fel (és akkor még a commentek elolvasása nélkül), hogy inkább te vagy a magad kis fejlesztői burkában (már ebben a commentben is csak a db indexelésig jutottál, és hol van még onnét az infra meg az OS level), mert nekem is egyből feltűnt, hogy ki van hagyva a komplett üzemeltetés, DBA-stul meg mindenestül. Ok kicsi cég, ott nincsenek ilyenek, értem. Nade akkor a HR miért van benne?

Nagyon kicsi garázscégnek kell lenni ahhoz, hogy a "fontendes/CSS-es" működtesse a vasat, az OS-t, és a DB-t (meg ugye akkor már hálózattal, monitoringgal, kutyafülével együtt). Ilyesmit eddig one man show-ban láttam csak, ahol az alapvetően fejlesztésből élő freelancer a saját projektjeit és devel környezetét jobb híján saját maga üzemeltette. Sokszor cloudbban, hogy legalább az infrával ne kelljen szopnia, de attól még ott van az OS, a backup, a DBA-skodas, meg még sorolhatnám.

Szóval azért ez a lépcső nem a multiknál kezdődik hálisten, arról nem is beszélve, hogy outsource is van a világon.

Szinte minden a felhőben van, én vagyok az admin és a tulaj is, kilépés esetén migrálom a user adatait... van ami tud sudo-t is. Menetközben nincs ránézve, max ha support kell, cserébe piszkálás van ha valami privát space-n marad holott hozzá kéne férnie valaki másnak is -akár nekem.

Pl az a szabály hogy privát drive folderben lévő fájlokat linkként megosztogatni tilos, annak a projektmappában kell lennie amit lát mindenki akinek köze lehet hozzá, a gDrive linkek kereshetetlenek.

Egyeb: nem olyan cegnel dolgozok ahol ilyen adatokat kezelni kene.
--
:wq

Mindenkinek.
és mielőtt mindenki szívbajt kapna: Egyéni cégben dolgozom

Csak a tulajdonosnak, azaz nekem, mert egyéni vállalkozó vagyok.
Beosztottak nincsenek is :)

Az egyéni vállalkozót nem nevezzük cégnek. :)

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Pedig az "egyéni cég" létező cégforma. :)

Létezik, de nem ugyanaz mint az E.V. :)

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Pedig azzal teljesen egyenértékű.
--
"Sose a gép a hülye."

A trabant és a ferrari is egyenértékű ha csak az érdekel minket hogy gurul-e az úton.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Jogilag semmi különbség nincs, sőt az egyéni vállalkozó komolyabb, mert teljes vagyonával felel, míg a cég csak az alaptőkéjéig.
--
"Sose a gép a hülye."

az nem vallalkozas, max onfoglalkoztatas....

Az igazan erzekeny adatok titkositva vannak, es senkinek nincs hozzaferese a cegen belul. Yeah.

----------------------
while (!sleep) sheep++;

kiveve azokat, akik programozzak/karbantartjak az alkalmazast, ami titkositva irkal.

Kivéve, ha a programozók nem az éles rendszeren fejlesztenek, hanem fejlesztői környezetben.

kiveve, amikor bugfix-hez tudni kell, hogy pontosan milyen allapotban volt a komplett rencer.
meg amikor tenylegesen ki is kell javitani az adatbazist egy randa bug utan.
meg amikor adatot banyasznak a data scientist-ek.
meg amikor adatmigracio van uj/reimplementalt rendszerekbe.

...

Az utolsó ponthoz jobb helyeken semmi köze a fejlesztőnek. (Konkrétan az utolsó munkám volt, hogy az egyik rendszeremet új környezetbe, új RDBMS verzióra stb. költöztessem és a fejlesztők csak a tesztrendszeren turkálhattak)

Az első kettőre kitaláltak pl. olyat, hogy ideiglenes hozzáférés felügyelettel, logolva stb.)

A harmadik meg felénk kb. azt jelentette, hogy olyanok turkáltak az adatbázisban, akik az adatokhoz egyébként is hozzáfértek a munkakörükből adódóan)

Uzemeltetoknek, fejlesztoknek van hozzaferese, tulajoknak csak "user" szinten, hisz sem szuksege, sem szaktudasa nincs hozza. (pl ber adatokhoz kozvetlen SQL-ben nem fernek hozza a konyvelok, csak a rendszergazda es a szoftver fejlesztoje)

Ilyen információ még egy auditor számára is csak a munkahelyi vezető írásos kérésére/rajta keresztül adható jobb helyen...

+1. Jol lehet tesztelni egy ilyen kerdessel, hogy mi a jelszavak gyenge pontja...:-)

Ja, de azt hogy hova ikszelsz csak Trey lathatja (jo esellyel meg se nezi). Illetve lehet bra meg a Pestis is lathatna ha nagyon akarna.

Ellenben az "egyeb leirom/nem irhatom le" mar tul publikus lenne leirva idonkent, es nem minden user anonim itt.

nem "garázscégnél" dolgozom.

--
zrubi.hu

SQL? Ahova mi megyunk, ott nincs szukseg SQL-re. :)

Ez szép volt, Doki! :D

aki aláírja a szükséges papírokat :)