Adatok titkosítása adatbázisban

Sziasztok!

Kicsit felszínesen érdekelne a téma, elméleti szinten, bocs ha butaságokat írok.

Adat titkosítás a téma.

- Jelszót belépéshez, itt eléggé egyértelmű a dolog, hasheléssel, hisz nem kell visszakapni az eredeti plain text-et, belépésnél hasheli a rendszer a beírt jelszót és összehasonlítja.

- Szeretném visszakapni az eredeti plain text-et, erős példa pl erre a bankkártya adat, de inkább mondjuk, hogy egy külső szolgáltatást szeretnék elérni plain text jelszó átadásával, pl api key, smtp jelszó, stb

Ezeket a jelszavakat egy eljárással titkosítom és letárolom adatbázisban. Ha jól tudom, akkor erre jó megoldás a kulcs pár, pl nálam mint kliensnél van a privát kulcs, odaát a szerveren a publikus. Az adatok visszafejtése nálam történik. Ha feltörik a szervert, akkor a kulcsom nélkül nem tudják feltörni az adatokat (elvileg, mert minden törhető egy idő után ugyebár).

Mi van amikor a szerver tárolja az adatokat és ő is akarja felhasználni? Tehát pl egy api key-t tárolok a szerveren és ő is akar beautentikálni a külső rendszerbe vele? Ha feltörik a rendszert, akkor ott van az kódolási meg dekódolási megoldás is. Ha csak az adatbázist törik fel, akkor ott talán védhető, hogy csak kódolt adatokat tudnak elvinni, ha viszont a kliens rendszert törik fel ami használja az adatokat, dekódolja, akkor elérik az adatbázis belőle és ott van  az algoritmus is, a kulcs, stb.

Van erre megoldás, vagy itt tényleg az a mondás,hogy el legyenek szeparálva a rendszerek egymástól?

Hozzászólások

Szeretném visszakapni az eredeti plain text-et, erős példa pl erre a bankkártya adat

99,99%, hogy valójában nem akarod tárolni a bankkártya adatot. :)

egy külső szolgáltatást szeretnék elérni plain text jelszó átadásával, pl api key, smtp jelszó, stb

Én átgondolnám ezt az egész architektúrát. Miért kell a kliensnek SMTP jelszó, meg mittudomén? A kliens authentikálja magát egy API-n keresztül valahogyan, és az API-t hívogatva csinálhasson olyan dolgokat, amikre van érvényes authz. Majdnem biztos vagyok benne, hogy nem akarsz SMTP jelszót adni az unmanaged klienseknek.

Már eleve a szerveroldalon sem kell adatbázisban tárolgatni ezeket, megkaphatja máshonnan is, pl. valamilyen vaultból.

Nem akarok bankkártya adatokat tárolni, példának írtam. Nem is használok 2 szereplős fizetést, életemben egyszer volt vele dolgom, azt is elleneztem.

- Ha smtp van, akkor az van, ha api key, akkor az, ez most tök mind1, az van amit tud adni a megrendelő/munkaadó. De itt megint a példa volt, miért kell a részletekbe belekötni? Azt is mondhattam volna, hogy péniszekről készült fotókat szeretnék tárolni és az ahhoz tartozó adatokat :)

- Vault sincs mindenhol managed, de ha van is vagy csinálsz IaaS-t, akkor is ugyanaz a sztori, hogy a klienset feltörve hozzáférnek a vaulthoz is és minden tartalmához.

De itt megint a példa volt, miért kell a részletekbe belekötni?

A security jórészt a részleteken múlik, és mivel a fenti példákon kívül nem írtál ~semmit a megoldandó feladatról, így ezekről tudunk csak beszélni egyelőre.

Azt is mondhattam volna, hogy péniszekről készült fotókat szeretnék tárolni és az ahhoz tartozó adatokat :)

Remek, teljesen máshogy állnék hozzá ehhez, mint mondjuk SMTP jelszavak tárolásához.

a klienset feltörve hozzáférnek a vaulthoz is és minden tartalmához.

Nem feltétlenül. :)

Szerkesztve: 2024. 10. 14., h – 11:00

Ahogy gelei kollega is irta, az egesz elgondolassal baj van.

Lehetseges hogy mikroservice-ek kommunikaljanak egymassal short lived tokenekkel, de ilyenkor sem tarolunk semmit sem sehol, max egy vaultban, ami general nekunk egy 5 perces tokent (aztan invalidalja is). Adatbazisba tuti nem kell rakni (nem is szabad). Meg titkositva sem

Ha meg arra vagy inkabb kivancsi hogyan tarolunk sensitive adatokat adatbazisban arra megint nem biztos hogy a titkositas a megoldas, hanem az entry/field level szintu RBAC. Azaz adott csoport kepes olvasdni a fizetesi adatokat, de pledaul mar a lakcim adatokat nem. Es mellesleg a sensitive adatok lekerdezeset meg akkor is auditaljuk, ha az engedelyezve van RBAC-bol. Ez a minimum.

Teljesen mind1, hogy hol a tárolás, megint a részleteken lovagoltok. Tök mind1, hogy mysql-ben tárolom, mongoban, redisben stb vagy vaultban vagy akárhol máshol. Mind2-t el lehet érni a kliensből, autentikációval. Teljesen mind1, hogy jelszóval autentikálok be a db-be vagy key-el vagy tokennel, a kliens alkalmazásból el lehet oda jutni és letölteni a tartalmát.

 

Eddig akkor az az álláspont, hogy a kliens programot feltörve nem sokat számít a titkosítás, csak akkor ha a db-t / vaultot törik fel.

Tök mind1, hogy mysql-ben tárolom, mongoban, redisben stb vagy vaultban vagy akárhol máshol.

Nem mindegy.

Mind2-t el lehet érni a kliensből, autentikációval. Teljesen mind1, hogy jelszóval autentikálok be a db-be vagy key-el vagy tokennel, a kliens alkalmazásból el lehet oda jutni és letölteni a tartalmát.

Mi a konkrét feladat? Mert innnen nézve a gombhoz keresed a kabátot...

Teljesen mind1, hogy hol a tárolás, megint a részleteken lovagoltok.

Dehogy mindegy.

Mind2-t el lehet érni a kliensből, autentikációval.

Ez általában nem jó ötlet.

Teljesen mind1, hogy jelszóval autentikálok be a db-be vagy key-el vagy tokennel, a kliens alkalmazásból el lehet oda jutni és letölteni a tartalmát.

Nem, ez sem mindegy! Nem mindegy, hogy van a kliensnek mondjuk egy rövidlejáratú tokenje, amivel utána egy API-n keresztül tud bizonyos címekre, bizonyos tartalommal emailt küldeni, vagy megkapja a kliens az SMTP jelszót, aztán a te relay-eden ekresztül spammelheti tele a világot. Végülis mindkettőt el lehet lopni, de egyáltalán nem mindegy, melyiket tudják elvinni. :)

A rövid lejáratú tokenhez is tárolsz egy key-t amivel meghívod a végpontot amivel tokent generálhatsz, vagy helyben generálod, mind1, de az adat ott van nálad. A username/password-al szemben annyi az előnye, hogy a script kiddiek nem tudják 1 kattintásra kiolvasni.

Hol és hogy tárolod el a key-t amivel a tokent fogod kigenerálni?

Hol és hogy tárolod el a key-t amivel a tokent fogod kigenerálni?

Erre nem lesz univerzális válasz.

Ha mondjuk a kliensbe interaktívan be kell jelentkeznie a usernek, akkor a usernév+pass kombóra kaphat vissza tokent, amivel utána hívhatja a többi endpointot. Ha valamilyen managed környezetben fut a kliens, akkor service identity alapján kérhet egyet egy vaultból. Lehet a kulcs HSM-ben. Stb.

Ezért lenne érdekes, hogy mi a feladat pontosan. :)

Olyat viszont tudok csinálni, hogy a user ne kérdezhessen be közvetlenül a "másik rendszerbe", hanem legyen előtte egy API gateway, ami megvalósítja a saját usereimhez a RBAC és egyéb rétegeket, aztán ha minden pké, akkor megnézem a vaultban, mi az aktuális kulcs a külső rendszerhez, és megcsinálom neki azt a query-t, amire szükség van.

a kliens alkalmazásból el lehet oda jutni és letölteni a tartalmát

a kliens programot feltörve nem sokat számít a titkosítás

De, szamit (*). Illetve, jelen esetben (meg mindig nem tudjuk, hogy mi az) nem a titkositas tenye maga, hanem a hozzaferes modja es korlatozasa. Ha jol ertem, a fontos az, hogy az adataidat hogyan ered el. Ha a klienst feltorve vegtelen ideig es/vagy teljes hozzaferest kapsz az adatbazishoz, akkor ott valami nagyon nem jol van. RBAC, ABAC, ReBAC stb. kulcsszaval korul nezelodj.

(*) A titkositas sem szimplan "a titkositas". Nem feltetlenul hasznalod ugyanazt a megoldast a szerveren ucsorgo adatokra, es a kliens fele a kommunikacio soran. Az elobbi lehet egy doberman a masik meg TLS 1.3. Kozuk nincs egymashoz..

A klienst feltörés alatt arra gondolok, hogy be tud lépni a hacker a szerverre, tudja futtatni a scripteket. Jó esetben fájlokat nem tud módosítani, újakat nem tud létrehozni, de tegyük fel, hogy fel tudja paraméterezni a scriptet amit futtat, tehát bele tud szerkeszteni a fájba. (tudom, az nem jó, de tegyük fel)

Azt a scriptet írja át, ami lekér automatikusan adatokat példának okáért mondjuk vault-ból.

Nem arra gondolok hogy megszerzi az odatartozó eléréseket és szabadon garázdálkodik, hanem a szoftver részeit használja fel az adateléréshez.

Példának okáért ha már feljebb elkezdtem:

Politikusok pénisz fotóit és méreteit tárolom le valahol, titkosítva, legyen vault.

A scriptem kigenerálja a rövid lejáratú tokent (ha már más ezt a pékdát hozta fel), amivel csak a baloldali politikusok adataihoz fér hozzá, a többihez nem. Meghívja a végpontot ahonnan kiéri az adatokat.

A hacker nem közvetlenül fér hozzá a vaulthoz, hanem a scriptet paraméterezi fel, hogy neki melyik politikus péniszére fáj a foga. Innentől kezdve teljesen mind1, hogy milyen tokent és hogy generálod, mert a saját scripted fogja megcsinálni neki. De ha megszerzi azokat az adatokkal amivel a tokent generálod, akkor azzal akár a rendszereden kívülről is hozzáférhet az adatokhoz, kivéve ha a túloldalon van valami egyéb korlátozás, pl ip cím szűrés. A legtöbb publikus szolgáltatónál nincs ilyen.

Ha még mindig nem elég a képzelőerőtök, akkor írok egy másik példát konkrét szolgáltatással ami szintén fiktív mert nem akarok most vele csinálni semmit, de teljesen valós rendszerről van szó.

na most ha egy hacker belepett a gepedre es full root joga van, akkor korulbelul mindegy is mit es hol titkositasz. Hiszen akkor arrol beszelunk, hogy akar egy adminisztrator mit tud csinalni. Na most akkor erre egyszeru a megoldas, senki sem ferhet hozza a gephez, a release stb minden kodbol megy. Persze feltorhetik a gitlab-otokat is es akkor a hacker indihta egy release-t a sajat verziojaval. :D

Azt modod, hogy ha az adatot tikositod a DB-ben, akkor ahhoz a hacker nem fer hozza, ha feltori a kliens oldalon a gepet es mindent lekerdezhet/megszerezhet? Miert is nem?  

Szoval eljuthatunk odaig, hogy a legjobb, ha kihuzod az arambol es leontod gyrsan szarado betonnal az egeszet.

Amit itt tudni kellene, hogy mi is a cel es mit hol lehet auditalni es azonnal lecsapni, ha valami baj van.

Peldaul a fenti peldaban ha az alkalmazas fer csak hozza a DB-hez es egyikhez sem fer hozza elo ember (ami alegge nehezitheti a munkat, hiszen tuti hogy a DBA-knak azert ezt azt varazsolniuk kell, szoval lehet time-limit hozzaferes esetleg nekik audittal es alerttel), akkor biozny egy csomo vektort meg is szuntettunk.

Masreszt nem valami scriptben tarolod el a tokenhez szukseges adatot, hanem jon az magatol protokollokon. Pl.: az appod egy API-t hiv meg OIDC-vel (oke meg mindig kell a client secret, plusz magahoz az apphoz is kell a felhsznalonak autholnia magat) de az API kizarolag a GET_TOKEN-t engedi ennek a client-nek es semmi mast. Amire visszadob egy tokent, amivel az tud authenticalni a DB-hez kb 5 percig. A DB-ben RBAC alapon engedjuk csak a kliensnek azt lekerdezni amit o lekerdezhet (a penisz meretet mondjuk pont nem) auditaljuk a query-ket es monitorizzuk ki mit szeretne, es alertelunk, esetleg azonnal lecsapjuk a klienst/kitiltjuk a felhasznalot (nem loginolhat be az app-ba).

A fenti esetben a geprol nem tud a hacker semmit sem inditani, csak is az alkalmazas kepes arra, hogy barmilyen muveletet vegezzen, ahhoz meg a hackernek authentikalnia kell magat. Szoval itt ket dolgora is szuksege van. Hiaba van bent root-kent a gepen, kell neki egy munkatars username/jelszava es az MFA push uzenet elkapasa is

A rövid lejratú tokenek nem téged véd, hanem az api-t amit hvni akarsz, ezért se ezt a pékdát hoztam, mert ilyen szempontból lehet user/password is. Lehet full hozzáférés, minden. A lényeg, hogy a te oldaladról mit tudsz megtenni a védekezéshez. Engem most az érdekel.

Erre jó komment lett volna az, hogy readonly minden script, ne lehessen új scriptet létrehozni, tmp mappában ne legyen lehetőség futtatni, stb...

Írok konkrét példát tényleg. Itt egy pénzügyi szolgáltató aki open bankingban is szolgáltat adatokat:

https://developer.gocardless.com/bank-account-data/overview

Az api-n keresztül létrehozhatsz kapcsolatot a bankoddal, vagy ha több useres a rendszered, akkor több user is megteheti ezt, tehát belép a rendszeredbe, regisztrál és regisztrálja a bankjánál a hozzáférést. Utána a te rendszered eléri a bankján az engedélyezett számlák adatait, tranzakcióit. Csak olvasásról van szó, pl napi 4x. Oké? Tehát nem utal meg semmi, ezzel teljesült az az igény, hogy nem éri el full root-ként a banki accountodat, de ez nem is volt kérdés alapvetően.

Pontosan úgy meg az adatok lekérése api-n amit mind írtok, de ez se volt részemről téma. Generálsz egy secret id-t és key-t az admin felületen, és azzal tudsz tokent generálni ami x percig érvényes, azzal pedig lekérheted a nálad regisztrált bankszámlák listáját, és bekérdezhetsz hozzájuk.

Nyilván a szolgáltatónál titkosítva vannak az adatok egyébként.

Nálad egy érzékeny adat szerepel, az pedig a secret id és key. Hol és hogy tárolod el ezt a 2 adatot úgy, hogy az valóban biztonságos legyen? Hogy használod fel, hogy törésnél ne kerülhessen illetéktelen kezekbe?

Erre jó komment lett volna az, hogy readonly minden script, ne lehessen új scriptet létrehozni, tmp mappában ne legyen lehetőség futtatni, stb...

Ez mitol jo kmment? Mit ved es mitol?

 

Nezz meg pl. egy SSH kliens implementaciot, hogy hogyan fer hozza a kulcsokhoz, jelszavakhoz, HW tokenekhez stb., hogyan dolgozik veluk, es hogyan tarolja (vagy nem) oket a memoriaban. Ha az nem elegseges, akkor valamiert tobbre van szukseged, mint az esetek 99%-aban a nepeknek. Olyat is lehet, de az draga lesz.

na megneztem. A fenti peldaban ha irsz egy APP-ot, akkor annak rendeleznie kell egy "access_token"-nel, amit bezony bele kell egetni az app-ba vagy env varkent atadni, stb, stb. 

Na err lenne az a megoldas, hogy az app ezt az "access_token"-t vault-bol olvassa. Igy nem kerul be az app forraskodjaba sem fent a git-ben sem pedig ahol fut. Persze akkor meg mindig az app-nak el kell ernie a Vault-ot, amihez kell egy client auth es a key ID-ja, hogy kiszedjuk a value-t. 

Itt jon a kerdes, hogy az app indulaskor kerje le egyszer vagy adott felhasznalonak adja csak ki?

En azt mondom, hogy ha van SSO, akkor a felhasznalo jogosultsagaval kerjuk le az adatot ad-hoc, azaz soha nem lesz jelen az access_token csakis amikor a falhasznalo ranyom egy gombra/linkre/submit-ra akarmire (akkor jon letre a gocardless client object). Azaz ha belep a hacker a gepre es belenez a forraskodba nem fog latni semmit sem. Ahhoz hogy barmit is csinaljon kell neki egy felhasznalo neve a passwordje es a telefonja. Azt persze latni fogja, hogy kerd le ezt a key_id-t errol az URL-rol (ahol a vault van), de ezzel nem sokat fog kezdeni.

Maradjunk böngészőből elérhető webes alkalmazásoknál, te valamiért telefonos appban gondolkodsz. (én amúgy php-s vagyok, de nem releváns, hogy mondjuk nodejs-ben menne a cucc)

A user belépés itt csak annyit jelent, hogy van olyan script amit csak adott felhasználó ér el, de ez se jelent teljes elzárást. A keretrendszer nem fog futtatni bizonyos kódrészeket ha a user nincs belépve, nem rendelkezik role-kkal, stb.

Performanciában eléggé komoly lassulást okozhat ha minden adott oldallekérésnél be kell kérdezni a keyvault-ba. Ha az első futásnál kéred le és cacheled, akkor ugyanúgy kiolvasható, pl env változókból.

A keyvaulthoz ahogy írtad, kell hozzáférés szintén. Nem tudod elrejteni.

- Azureban olyanokat csináltunk, hogy deploy-nál kértük le annó az adatot és az ment env változóba.

- AKS volt megoldása rá, hogy keyvaultból olvassa ki a secretet, a vége ugyanúgy env változó lesz.

- Azure app servicenél van összekapcsolás, meg Digital Ocean app platformon van olyan, hogy az adott env változó encrypt-ed, valszeg a háttérben titkosítva van, de ugyanúgy env változó lesz ott is.

Tehát 2 gondom van, a sebességet rontja a sok vault lekérés, illetve valahol kell a vault elérése is.

Azure alatt volt lehetőség elvileg arra, hogy AKS mindenféle key-el lépjen be a kódból vagy bárhonnan, elvielg össze lehetett volna lőni erőforrás szinten jogosultságokkal, hogy elérje, de a vége ugyanőgy secret lesz env-el. Bár ez a módszer nem működött akkor még, valami nem klappolt MS-nél.

 

Nagyobb cégnél voltunk többen is DevOps-ok és a CTO-nak volt ez az álma, hogy ne legyen beégetve fájlokba a mysql jelszó, ne lehessen sehogyan se kikérni, kiolvasni. Mindannyian elmondtuk, ezerszer, hogy tökmind1 hogyan és honnan kéred ki, a végén ott lesz a memóriában valamilyen szinten, amit el kell érnie a php-nak és akkor php-ból kiolvasható ugyanúgy, vagy a gépről env változóból. Ugyanígy az se volt megoldás, hogy KeyVaultból olvassuk be minden oldalletöltésnál mert rettenetesen belassult volna tőle a rendszer. Itt pedig már arról se beszélhetünk, hogy levédjük  felhasználóvan az adatot, hisz publikus részekről van szó, ahogy pl egy mailgun hívás se kerülhet autentikált oldal mögé, pl egy rendelés végén küldendő levélnél.

Performanciában eléggé komoly lassulást okozhat ha minden adott oldallekérésnél be kell kérdezni a keyvault-ba.

De miért kéne? Egyszer kell, amíg megkapod a tokent, vagy akármi.

Mi a feladat pontosan? :D

a végén ott lesz a memóriában valamilyen szinten

Ez általában így van, igen.

Itt pedig már arról se beszélhetünk, hogy levédjük  felhasználóvan az adatot, hisz publikus részekről van szó, ahogy pl egy mailgun hívás se kerülhet autentikált oldal mögé, pl egy rendelés végén küldendő levélnél.

De nem is érdekes, a user végigkattintgatja a megrendelést, a backend pedig majd küld egy emailt, ahogy akar. Akár Mailgunon keresztül, tökmindegy. Amikor a backend app elindul, akkor egyszer kiszeded a mailgunos API keyt a vaultból, az authentikálatlan usernek erről nem kell tudnia semmit, nem megy kliensoldalra az infó.

Gépi kóddal becímzed és befoglalod neki a helyet? Hát azért csak nem :)

Nem vagyok benne biztos, hogy értem a kérdést. :)

Környezeti változóban?

Nem. Fut egy processz (vagy több, most mindegy), ami kiszolgálja a kéréseket. Egy csomó paramétert, feature flaget, stb. már úgyis a memóriában tartasz, nem? Vagy mindent kipakolsz környezeti változóba? Nem túlzás az?

Milyen nyelvben dolgozol?

C#, Python

C#-al nagyon rég dolgoztam már, annak szerver oldali részéhez most nem tudok hozzászólni, ott csak desktop-on volt tapasztalatom.

Python-t néha szoktam, ha nagyon minimált akarok írni és túlzásnak tartom hozzá a php-t.

Env variable ott is akkor játszik nálam ha kívülről indulásnak akarom átadni, deploy folyamán.

Az memóriában lesz. Ha a python script futása közben hozok létre egy változót a scripten belül, az is memóriában lesz.

Éppen futó python scriptnek memóriában valami változót átadni on the fly, nah erre nincs jelenleg ismeretem, majd utánanézek, de ha mondasz 1-2 kisebb konkrétumot, akkor megköszönöm, kíváncsi vagyok.

PHP esetében ha nem akarsz fájltan tartani valamit, akkor az env változó játszik, az kvázi megelőzi a fájlban tárolást. Mivel jellemzően konténerekben dolgozom, így itt nem számít, hogy a full konténer látja, pl bash-ban is, hisz csak azt a service-t szolgálja ki.

Milyen telefonos appokban? Az SSO es OIDC miota nem mukodik egy sima webes app-nal?

de figyelj ha hozzafer egy hacker valamihez teljes joggal, akkor mindent is ki tud olvasni, pont a memoriabol. Azellen semmi sem ved, hogy ha valaki mar bent van es ki tudja dumpolni egy process memoriajat. Akkor a titkositott DB adatod is cseszheted?

Miert kellene env varnak lennie egy secretnek? Miert ne lehetne felmountolni? De akarhogy is, ha egy hacker bejut egy K8S-be es admin jogosultsagot szerez secret:read, ott mar komoly bajok vannak. Nalunk azert RBAC-al meg van mondva, hogy adott namespace secretjeit csak az app serviceaccounbtja tudja olvasni. Szoval vannak ott bajok, ha nem private a cluster es igy jut be egy hacker es mindent is megszerez. Akkor kb a legkisebb baj, hogy kilvas barmit is a DB-bol.

Szoval tovabbra sincs azellen megoldas ha tarvahagyjuk a kaput es a hacker-nek minden jogot megadunk es emellett meg nem is auditalunk es riasztunk, ha valami suspicious tortenik. Ez ellen a DB teljes titkositasa sem ved. :D

(workload identity-nek hivjak ujabban az Azure-ban mikor federalod az odic-t es a pod serviceaccount-jat)

A CTO-nak meg igaza volt. Nem mindegy, hogy siman kiolvasod egy kodbol/file-bol, vagy be kell tornod valahova es ugy megszerezni (kubernetes full admin jogosultsag, amit sosem adunk ki amugy sem senkinek)

Termeszetesen ha egy oldal publikus ott nem tudod levedeni, de ilynkor jon be a multitier app, ahol van pubikus resz es van a backend es ezek API-n keresztul beszelnek, ahol csakis a public app-tol fogad el barmit, tehat nem lehet akarhonnan megszolitani. (fent irta is gelei)

"de figyelj ha hozzafer egy hacker valamihez teljes joggal, akkor mindent is ki tud olvasni, pont a memoriabol. Azellen semmi sem ved, hogy ha valaki mar bent van es ki tudja dumpolni egy process memoriajat. Akkor a titkositott DB adatod is cseszheted?"

És ennyi volt a lényeg, köszönöm, ezt akartam igazából hallani, erről szólt kb az egész post. Tudom rohadjak meg meg minden de akkor is. Ezt akartam kihozni belőle, ha megtörik a szoftvert, akkor baxhatod a titkosítást és tárolást, bármennyire is le van védve az infra, bárhol is tárolod a jelszavakat, secreteket.

 

Alapvetően nem az infrát féltem, pl a kubernetest, hanem a szoftvert. Tapasztalataim szerint a szoftver az sokkal sebezhetőbb mint az infra. Felmountolás alatt ha fájlra gondolsz, akkor az szintén beolvasható, ha bejutsz a szoftverbe, akkor azon keresztül be is olvashatod. Bezárhatsz minden kaput meg letűzfalazhatsz mindent, ha a szoftverben van egy rés. Azt se mondhatjuk, hogy a világ bénája aki hibázik, hisz mindneki hibázik. Szerencsére nekem szoftveremet még nem törték meg eddig, igaz, már régóta nem írok saját keretrendszert, hanem symfony-t használok, lehetőleg mindig a legfrissebbet.

CTO esetében nem az infra volt a kérdés, hanem a szoftver, csak infra megoldáson ment az agyalás. Ezen oldalról pedig ugyanarról volt szó. Mind1, hogy egy config.php-ban volt beégetve vagy env változóban volt, mert az env változót is be lehet olvasni a php-ból, be lehet olvasni bash-ból, a keyvaultot is el lehet érni ha bent vagy a szoftverben, stb...

igen es ehhez kell a hozzaertes hogy ez ne tlortenhessen meg. De ehhez bezony erteni kell a dolgokhoz vagy olyanokra bizni akik ertenek hozza. 

Azt mondod, hogy megnezed a secretet? Megis hogyan?

* Sectret: Nalunk senki sem tudja megnezni a secretet a kubernetesen belul csak az app serviceaccountja (rbac). Keptelenseg. En is csak onnan tudom, hogy van jogosultsagom a key-vault-ba egy par secretre es meg csak nem is az osszesre. Amugy meg random generalodik minden alkalommal minden deploynal az osszes secret. Szoval fingom since most eppen mi az erteke :D

* Env var: Senki sem tud exec-elni az APP podba. Igen a "describe" meg a "get" mukodik nekem(!!!) meg meg ket embernek, senki masnak. De nekem is csak ugy, ha elotte MFA-zok egy jot es a PIM-ben megkerem a jogosultsagot (1 orara meg is tarthatom), majd authentikalom magam egy jumphoston a client certemmel (ez mar ugye harom reteg) amit ki tudok szedni a keyvaultbol, mert az is rotalodik folyton (de ilyenkor mar ugye van sessionom az MFA utan)

* A frontendunk kb semmit sem tud semmirol. Indulaskor lekeri a backend-hez valo kapcsolodashoz a tokent egy API-tol, ami general egyet neki a keyvaultban (igen ez csak minden indulaskor tortenik meg, azaz ha valaki ki tudja olvasni a secretet a fentiek alapjan, akkor az tud a frontend IP cimerol kereseket kuldeni a backendnek, mar hogy a picsaban tudna, he ra sem tud lepni?)

* Backend workload identity-vel fut, nincsenek kulcsok IAM-mal van beallitva, hogy mihez van joga (key vault, storage account, stb' Pl. a keyvaultbol keri le indulaskor az adatbazishoz szukseges kapcsolodasi adatokat, igy nincs env var vagy secret sem, csak a memoriajaban letezik), de mint irtam ember legyen a talpan aki be tud exec-elni miutan az egy az egyben titltott, a node-ok meg privatek szoval nem tudsz rajuk lepni (nincs SSH) hogy azok memoriajabol szedd ki a container memoriajanak ytartalmat)

az adatbazis titkositasa sem ved semmi ellen sem, ha a fentiek nincsenek meg. Ennyi

Én most Digital Ocean kubernetesben ügyködök, ott simán bele lehet nézni a secretbe ha bent vagy a clusterben (certekkel pl).  A secreteken belül simán base64-el van dekódolva a string, semmi extra.

Azure AKS-ben is simán bele lehetett ugyanígy nézni, csak ott mellette az Azure portal-on is lehet böngészni, természetesen jogosultság kell hozzá, nem állítottam, hogy egy mezei user minden jog nélkül beleláthatna a kubernetesbe. A lényeg, hogy base64-en kívül semmi titkosítás nincs egy kubernetes secretbe felhasználói szempontból, kb ugyanaz mint a configset csak más objektum.

Ha Azure KeyVault-ból van bekötve egy secret, akkor ha jól emlékszem ugyanúgy sima secret lesz belőle, csak mellette még fel is mountolja fájlként (de ebben nem vagyok biztos, 1 éve nem jártam Azure felé). Az viszont tuti, hogy a végén jellemzően ugyanúgy minden secretet Environment variable-ba tolunk be, ami a konténeren belül egy mezei változó. Bash scriptben echo és látod is.

Describe pod esetében valóban nem látszik a secret értéke. A kódban viszont már ki tudod iratni a változót. PHP-ban pl getenv('variable'); és ki is írja. Erre írtam, ha valaki bejut a szoftverbe valahogy és bele tud módosítani, vagy tud akár a háttérben futtatni 1-2 parancsot a konténerből/szerverből, akkor már ki tudja így nyerni a plain értékeket.

A legtöbben frameworkoket használunk amit folyamatosan foltoznak. Jellemzőjük, hogy tele van nagyon sok hasznos tool-al. Ekkora mennyiségben előfordulhatnak hibák és belefuthatsz egy olyan bug-ba ahol a user valami résen le tudja futtatni pl a php-s getenv-et és már látja is a jelszót. Persze alapvetően nem ér vele semmit ha csak ennyi van meg neki, hisz ahogy beszéltük, tűzfalazva van minden, akkor a jelszóval kívülről nem éri el az adott cuccot.

Nem kötekedni akarok, mert nyilván sok dologtól függ itt minden. Sok hozzászüólásbül azt vettem le, hogy arra utaltok, igenis el lehet rejteni ezeket a plain dekódolt értékeket (valaki írta, hogy még a memóriából is kipucoljátok, közben meg már ott vagyunk, hogy a memóriában van mindenkinek a plain text secret meg egyebek). Ezért voltam kíváncsi rá, hogy ki mit hogy old meg, de ezek szerint nincs új a nap alatt.

Amúgy ezek szerint nektek sikerült összelőni az AKS-t a keyvault-al principal meg minden lószar nélkül. Nekünk annó nem ment, a leírásokat 100%-osan végigvezetve se működött. Ma már lehet rendesen megy.

Ok tehat:

* Nem allitottatok be "encryption at rest"-et, hogy ne base64-el legyenek elkodolva csak (tehat a kubernetes a hibas)

* Nem allitottatok be RBAC-ot, hogy ne tudj belenezni (thet a kubernetes a hibas)

* Nem private AKS clustert csinaltatok, ezert a UI-n is tudjatok nezni, private cluster eseten nem tudnatok (tehat az AKS szar)

* "A lényeg, hogy base64-en kívül semmi titkosítás nincs egy kubernetes secretbe felhasználói szempontból, kb ugyanaz mint a configset csak más objektum" -ok nem tudod hogy ez nem igy van :D

* "Ha Azure KeyVault-ból van bekötve egy secret, akkor ha jól emlékszem ugyanúgy sima secret lesz belőle, csak mellette még fel is mountolja fájlként " - nem, nem igy van

* " Bash scriptben echo és látod is." - miert is tudott barki "exec"-elni a podba???? Mi a pek nathas faszaert volt ez engedve?

* Tehat hogy a faszba tud valaki bejutni egy podon belulre, amikor eloszor is MFA-val authentikalnia kell magat (3 adat: username/password/totp), majd meg kell kernie a jogosultsagot PIM-en (jo ez mondjuk automatikusan is mehet, de ezt is monitorozzuk), majd egy private clustert elerni egy jumphoston keresztul ( username, client cert ami rotalodik orankent = 2 ujabb adat). majd ugye RBAC miatt joga sincs se "exec"-re, sem pedig read-je nincs secret-re. Azutan meg az is itt van, hogy maga a secret sem base64-elve van hanem mondjuk AES-elve amihez a kulcs a kubelet konfigban van, de ugye ahhoz meg ra kellene lepnie a private cluster private node-jaira, amit meg nem tud, mert nincs ra lehetosege, nincs user, nincs kulcs, nincs semmi se)

Nem kotekedni akarok, de erdemes erteni a kuberneteshez es cloud biztonsaghoz vagy olyat keresni aki ert hozza.

A pod identiy-vel is ment, de az kozel sem volt olyan biztosnagos mint az uj workload identity. A wokrload identity eseten sehol semmilyen titkos adatra nincs szukseg, mivel maga a kubelet van oidc federation-ben az azure-ral, igy az azure-ban mondod meg hogy mit ud az adott federated client (azaz a namespace:serviceaccount kepes mondjuk a mysql-passwd keyt olvasni a keyvaultbol, es mivel a pod abban a namespace-ben fut azzal a serviceaccounttal, az egyetlen amit csinalni kell, hogy a megfelelo azure keyvault library-val DefaultAzureCredential-lal kiolvasod es kesz. Sehol egy clientid vagy secretid vagy akarmi. Na most ez nem csak Azure-on van igy hanem AWS-en es GCP-n is, Ha valami olyat hasznalsz ami nem tudja, akkor meg ott a SPIFFE/SPIRE es maris rendelkezesedre all ugyanez.

Alapvetoen soha semmikor nem kell senkinek sem belepnie egy kontenerbe. Arra van a logolas az APM, ha latni akarod mit csinal. Jo a DEV envben lehessen, de mar az UAT-ban sem, nemhogy a PROD-ban. De a legjobb, ha mar a DEV-ben sem lehet es akkor a programozok is ra vannak kenyszeritve hogy helyes modon implementaljanak valamit.

"igenis el lehet rejteni ezeket a plain dekódolt értékeket" - workload idenity eseten sehol sincs semmilyen adat, hozzateszem, hogy a kekerdezest az alkalmazasban implementalni kell es persze a memoriaban ott lesz, de nem env varban amit ki lehet iratni. Azt meg mar leirtam hogy a pod memoriajahoz hogy ne lehessen hozzaferni. Ha meg valaki megis hozzafer akkor a legkisebb az ha meg tudja nezni azt a jelszavat. Mert akkor az azt jelenti hogy a teljes infrastrukturatok mindenestol komrpomittalodott. 

* " Bash scriptben echo és látod is." - miert is tudott barki "exec"-elni a podba???? Mi a pek nathas faszaert volt ez engedve?

Az OP itt talán arra gondolhat ha a konténerben futó szoftver portja elérhető kintről és a szoftverben lévő RCE-n keresztül remote injektált shellel "beesik" Ivan/Vang a konténerbe, akkor amihez a konténer azzal a júzerrel hozzáfér ahhoz Ivan/Vang is hozzáfér.

A védekezés nehezebb része itt kezdődik. Első lépésként ott például egy SQL kliens fut, lehet használni SQL oldalon RLS-t is ha tudja a szerver, de azért eléggé nagy meló ilyen apró least privilege buborékokra szétszálazni az appot meg az architektúrát, ez tény.

Nekem a bash script azt mondta hogy ha belepa shellbe. De nem ertek a PHP-hez, szoval nem tudom mire gondolt. De ugye ez ellen csomo dologgal lehet vedekezni mar a szoftvertervezes elejen atgondolva. Multi-tier app, API-k vedelme es mondjuk vulnerability scannerek hasznalata (ami persze a 0 day-eket nem biztos hogy tudja) meg mielott barhova kirakom. 

De igazabol vonatkoztassunk most el a kontenertol. Minden esetben fennal a veszeje annak, hogy egy RCE-t kihasznalva valaki beesik valahova. Ezt csomo esetben meg lehet akadalyozni, de ha nem lehet megakadalyozni, akkor az observality tool-ok segithetnek benne. Azert a fura dolgokrol azonnal kuldhetunk riasztast, egy jo ML meg par masodperc utan kiszurja a dolgot meg lehet azelott hogy sikerulne neki tenylegesen belepni es injectalnia barmit. Persze ez koltseg. Nem veletlenul beszeltunk itt errol tobben is, hogy a vegtelen penzert vegtelen biztosnagot lehetne venni, de olcsobb kihuzni a falbol es betont onteni ra :D

Lazán kapcsolódik: https://www.cloudflare.com/learning/security/glossary/what-is-zero-trus…

Nálad egy érzékeny adat szerepel, az pedig a secret id és key. Hol és hogy tárolod el ezt a 2 adatot úgy, hogy az valóban biztonságos legyen?

De mit lehet tudni arról, hogy "nálam"? Ez a millió dolláros kérdés :)

Ez egy nyilvános webapp? Vagy egy belsős LOB alkalmazás? Vagy egy ERP rendszer, ami szintén delegálja valahogy a hozzáférést másoknak?

Nálam == Alkalmazás, szerver. Webapp, nem desktop. Nincs konkrétum amúgy, hisz elméleti síkon indult a kérdés, ezért nem teljesen korrekt az "Ez" megnevezés. De legyen webes alkalamzás bönfészőben futtatható, publikusan elérhető, bizonyos funkciók belépés után. Sőt, írtam máshol is, hogy php-s vagyok, de egyébként irreleváns a script nyelv meg a keretrendszer is.

A scriptem kigenerálja a rövid lejáratú tokent

Hogyan generalja? Sajat magatol? Ha a kliensed mindenfele egyeb beavatkozas nelkul csak szimplan egy futtatasra kepes tokent generalni, az mar regen rossz.

azokat az adatokkal amivel a tokent generálod, akkor azzal akár a rendszereden kívülről is hozzáférhet az adatokhoz, kivéve ha a túloldalon van valami egyéb korlátozás, pl ip cím szűrés.

1) Ne szerezhesse meg konnyen! Legyen jelszo/OTP, HSM, akarmi, illetve minden _is_.

2) A szerver oldalon ellenorizni kell a klienst. Lehetoleg magat a HW-t _es_ a szemelyt is. Erre ra lehet dobalni egyeb parametereket. Elolvastad a fenti RBAC, ABAC, ReBAC linkeket?

3) A kliens nem egy shell script, remelem. Ha van egy tokened, amellyel hozzafersz az adatokhoz (a fentiek utan), akkor azt sem mented le a /tmp/nagyontitkos.neolvassel fileba. Arra is megvannak a bejaratott megoldasok, hogy hogyan tarolunk ilyen tokeneket, illetve hogyan pucoljuk ki oket meg a memoriabol is.

pontosan, a DB-hez csak az APP ferhet hozza (legyen nodejs, mert azt mindneki szereti :D), ahhoz hogy hsznalja valaki kell az auth (MFA-val), ha belepett akkor futtahat valamit, amire maga az app ker tokent a Vaultbol, nem a falhasznalo, na most akkor mar le is tud futni a query, de csak az jon vissza amit az RBAC/ABAC/ReBAC enged.

Es az egesz hobelebancot monitorozzuk es auditaljuk (mehet ra az anomaly detection is :D)

A fentiek alapjan hiaba van root joga a hackernek, meg az app forraskodjat is haiaba latja, nem tud mit kezdeni vele.

Ha a user péniszfotókat akar nézegetni, akkor a folyamatban mindenképpen lesz olyan pont, amikor a péniszfotó titkosítatlanul megjelenik valahol. Ezt sajnos nem lehet megkerülni, ebben igazad van.

A blue team feladata az, hogy a támadó minél drágábban (pénz, idő, stb.) férhessen csak hozzá az őt érdeklő tartalomhoz. És ezért írom, hogy nincs univerzális megoldás, mert támadási vektorból is sokféle van. Fizikai hozzáférés ellen pl. storage encryption. A manipulált kliensek ellen RBAC, rövidlejáratú tokenek, stb.

Ha ay a forgatókönyv, hogy a támadó hozzáfér a kliensekhez, a szerverhez, az adatbázishoz, ráadásul fizikailag is meg tudja szerezni, akkor inkább adjátok oda neki egyből az adatbázis dumpot, akkor már úgyis mindegy kb. :)

kivéve ha a túloldalon van valami egyéb korlátozás, pl ip cím szűrés. A legtöbb publikus szolgáltatónál nincs ilyen.

Ez egy sima, mezítlábas tűzfal feature, ahol nincs ilyen, az nem komoly szolgáltató. :)

Jol mondod, itt beszelhetunk a csatorna titkositasarol es az adat titkositasarol is, plusz az adat hozzafereserol is, ami nem titkositas, de eppen olyan fontos

es meg szamos masik helyen is titkosithatunk, hiszen mar maga a disk is lehet titkositott, de mivel ugye azt mar a boot soran kinyitjuk, hogy elindulhasson az OS, az csak attol vedi az adatbazis adatait, ha kikapjak a diszket. :D

Szoval van itt eleg layer amit tikosithatunk ha nagyon muszaj :D

Szerkesztve: 2024. 10. 14., h – 19:10

Mi van amikor a szerver tárolja az adatokat és ő is akarja felhasználni?

Lényegében az app rétegben akarsz titkosítani, a db / file csak tárol. Teljesen rutin, minden CGI nyújt ilyent, és minden programozási nyelven vannak ehhez függvénykönyvtárak. Az lényegtelen, hogy szerver alkalmazásról vagy kliens alkalmazásról van-e szó.

Pl. PHP esetén:
- jelszóra (csak oda salt-tal): password_hash
- adatra (oda-vissza): openssl_encrypt / openssl_decrypt

Vagy Python esetén:
- jelszóra (csak oda salt-tal): bcrypt
- adatra (oda-vissza): AES-Python vagy pycrypto

Vagy C# esetén:
- jelszóra (csak oda salt-tal): KeyDerivation.Pbkdf2
- adatra (oda-vissza): System.Security.Cryptography.Aes

Vagy Java esetén:
- jelszóra (csak oda salt-tal): javax.crypto.spec.PBEKeySpec
- adatra (oda-vissza): javax.crypto.Cipher (tud AES-t)

Vagy C/C++ esetén simán bcrypt / openssl library vagy tiny-AES-c, stb.

...stb. Tényleg mindenhol léteznek ezekhez wrapperek és / vagy függvénykönyvtárak. Aztán már csak annyi a dolgod, hogy a bináris bitkolbászt rakod / olvasod a db-be/ből, file-ba/ból.

Ha feltörik a rendszert, akkor ott van az kódolási meg dekódolási megoldás is.

Ezt nem úszhatod meg sehogy sem. Túlbonyolíthatod a végtelenségig, tárolhatod a titkosítási kulcsot magát is titkosítva, de a lényegen nem változtat: az alkalmazásnak rendelkeznie kell a memóriában a plaintext kulccsal, hogy használni tudja.

Ha feltörik a rendszert, és hozzáférnek mondjuk az RSA kulcsaidhoz, az is szopó, még akkor is, ha jelszóval védve tárolod. Ezzel csak nehezíted a betörő dolgát, de meg nem oldja a problémát. (Persze meg lehet annyira nehezíteni a dolgot, hogy előbb legyen tele a töke, semmint hogy megtalálná a megoldást, de ezt nehéz előre látatlanba megsaccolni, mert nagyon betörőfüggő az a türelmi határ.) Maga a titkosítási megoldás meg egyébként is nyilvános (az már régesrég rossz, ha valami saját security by obscurity cuccot akarsz használni a jól bevált NIST hitelesített helyett).

Ha nem akarsz sokat szívni, akkor az Sqlite-ból van fizetős változat, ami alapból tudja a transzparens titkosítást. Mivel én fizetni nem akarok ilyesmiért, ezért megírtam magamnak sqlite3aes (sajnos azóta eltávolították az ezt lehetővé tévő API-t, így sqlite3-3.31.1 a legfrissebb, amivel még működik). Ennek az a nagy előnye, hogy a titkosítás az alkalmazás szempontjából transzparensen történik, azaz Másvalaki Problémája (TM).

Köszi ezek mind meg is voltak, csak többen úgy írták, hogy nem lesz a végén plain text sehol, de aztán kiderült, hogy mégis. Ennyi.

Nyilván a szoftver és infra oldaláról kell védeni, hogy ne jussanak el addig, viszont ilyen szempontból tényleg teljesen mind1 a szoftver oldaláról, hogy egy secret-et most keyvaultban vagy mysql-ben tárolunk el minden titkosítás nélkül. Utóbbi esetén abban van a gyenge pont, hogy ellopják az adatbázist, akkor hozzáférnek az adatokhoz azonnal.

Erre szokott az lenni, hogy jelentik az adatszivárgást egy nagy cégnél, azaz, hogy elloptak bankkártya adatokat, de don't worry, csak titkosított adatokat vittek el. Ennyiből látom max értelmét vaultban tárolni az adatokat, esetleg annak az automatizáló funkcióit tartom még jónak, pl cert,kulcs kezelést, generálást, stb.

többen úgy írták, hogy nem lesz a végén plain text sehol

Ilyet nem rémlik, hogy bárki írt volna. :)

Eleve értelmezhetetlen a dolog, mert a sor végén általában ül egy hús-vér felhasználó, aki csak a plaintext szöveget tudja elolvasni, tehát valahol kell lennie egy olyan rétegnek, ahol ez létrejön a titkosított adatból. Az a kérdés, hogy hol.

az alkalmazásnak rendelkeznie kell a memóriában a plaintext kulccsal, hogy használni tudja.

Altalanossagban igaz, de nem feltetlenul.

Ma mar (kb. 5-10 eve) vannak a secure enclave chipek mindenben. Az pedig pont ezt csinalja, hogy eltarolhatod benne a kulcsot (ez egyiranyu, kiszedni talan a CIA tudja, $millios koltseggel), es a teljes de/crypt -et intezi, a te altalad irt forrasban a kulcs nincs meg.

Persze ettol meg ha feltorik a gepet, akkor tudnak de/crypt-elni, DE: atvinni masik gepre nem tudjak.

Ha tenyleg komolyabban erdekel a tema, nezz utana batran.

Illetve vannak (cel)hardveres kutyuk is, amik netre kothetoek, kulcsot fizikailag belejuk toltod, es adott klienseknek adott dolgokat de/cryptel-nek. Itt ugye lehet komolyabb szabalyokat is szabni, hogy mit lehet, gyakorisag/hanyszor, es minek kell megfelelnie hozza. Gyanus pattern-re lehet riadoztatni.

De mi ellen akarsz védekezni a titkosítással?

Ki az, akinek nem kéne elolvasnia ezeket a dolgokat, és hol van ő?

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

De, pont, hogy az alapoktól kellene kezdeni, mert van olyan adatbázisban titkosított adat, ami egyféle támadás ellen véd, másféle ellen meg nem.

Vagy most csak vicceltél és nem vettem a lapot?

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ó nem. A thread túl hosszúra nőtt már, egy ideje már nem olvasom az új hozzászólásokat (kivéve akik nekem válaszolnak).

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Lépjünk vissza. Mi az asset amit védeni akarsz. Mi a threat ami ellen védekezni akarsz? Mi az assumption amit feltételezel? Kellene egy normális threat modelling mert a nélkül mindenre is kaphatsz választ, csak nem biztos hogy megoldja a problémádat.

Kb az application key/secret management a fogalomkör a felvázolt problémára, egy termék/szolgáltatás pl. a Hashicorp Vault.

A kerdezo szerint ha kell adnod a secret-id-t amivel kapcsolodnod kell a vaulthoz az mar rossz, mert akkor mar nyoma van. Mondjuk szerintem ettol meg nem breach-eltuk a rendszert. Erre irtam, hogy akkor menjen workload identity-vel minden, mert akkor nem kell megadni semmilyen adatot, hiszen a federation miatt megmondjuk, hogy adott app/ember mihez ferhet hozza. Igy peldaul ha implementaljuk a secret-get-et nem kell semmit megadni hiszen maga a workload identity azonositja ot es a masik oldalon IAM-mal megmondjuk hogy kiveheti vagy sem. De ez sem jo neki, mert mi van ha valaki etszalad az MFA-n, a client certeken, az RBAC-on es mindenen is mint kes a vajban es kiolvassa a gep/kontener memoriajat????

Szoval nincs megoldas :D