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
99,99%, hogy valójában nem akarod tárolni a bankkártya adatot. :)
É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.
(toroltem mert nem ide akartam)
Ja megint neked valszoltam, de mi egyetertunk :D
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.
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.
Remek, teljesen máshogy állnék hozzá ehhez, mint mondjuk SMTP jelszavak tárolásához.
Nem feltétlenül. :)
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.
Nem mindegy.
Mi a konkrét feladat? Mert innnen nézve a gombhoz keresed a kabátot...
https://iotguru.cloud
Dehogy mindegy.
Ez általában nem jó ötlet.
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?
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. :)
A tokent third party rendszerhez generálod, ergó a másik rendszer adja hozzá a secretet amit használhatsz. Nem tudod hozzá felhasználni a user adatokat.
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.
De technikailag nincs olyan, hogy user kérdez be.
Webes rendszernél a user csak egy adat a session-ben. Ne mobilalkalmazásban gondolkodj, hanem egy weboldalban.
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?
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.
"Ez mitol jo kmment? Mit ved es mitol?"
Ha ezt kérdezned kell....
SSH rossz példa, mert ott a usernél van távol egy jelszó vagy privát kulcs.
Pedig nagyon is jogos volt a kérdése :)
Mi akadályoz meg abban, hogy a te klienseidnél is legyen?
Kliens == Szerver aki egy api végpontot, azaz egy másik szervert hív
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.
De miért kéne? Egyszer kell, amíg megkapod a tokent, vagy akármi.
Mi a feladat pontosan? :D
Ez általában így van, igen.
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ó.
Ha másodpercenként küldesz 200 levelet (most mondtam valamit), akkor másidpercenként 200x fogod lekérni a vaultból a key-t a mailgunhoz?
Amíg él a konténer/app/akármi, és nem változik meg az API key, addig nem kell többször lekérni.
És hol tárolod? Env változóban? PHP esetében csak ott tudod, ha nem akarod fájlban.
Memóriában. A PHP-hoz nem értek. :)
Gépi kóddal becímzed és befoglalod neki a helyet? Hát azért csak nem :)
Környezeti változóban?
Milyen nyelvben dolgozol? (Nodejs-ben meg Javaban is környezeti változóval toltuk, azok alatt csak DevOps szintig mentem, fejleszteni php-ban szoktam)
Nem vagyok benne biztos, hogy értem a kérdést. :)
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?
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
Lazán kapcsolódik: https://www.cloudflare.com/learning/security/glossary/what-is-zero-trus…
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.
+1, nagyon hiányzik nekem egy Móricka-ábra, hogy pontosan hogy néz ki a rendszer, mi akar mit elérni, mi hol fut, stb. Ettől függően lehet a megoldás az egészen triviálistól (pl. Azure ACA + KV) az egészen bonyolultig bármi.
Hogyan generalja? Sajat magatol? Ha a kliensed mindenfele egyeb beavatkozas nelkul csak szimplan egy futtatasra kepes tokent generalni, az mar regen rossz.
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. :)
Ez egy sima, mezítlábas tűzfal feature, ahol nincs ilyen, az nem komoly szolgáltató. :)
Nem fognak neked publikusan elérhető api végpontokat tűzfalazni. Pl a fent említett pénzügyi szolg, vagy stripe, vagy mailgun se ad ilyet. És még ezer ilyet lehet sorolni. Ahol te regisztrálhatsz, előfizethetsz, ott nem lesz ilyen.
Nem?! Meg az itthoni wifi routeremben is van tuzfal egy szep deny all szaballyal.
Ha megis kiderulne, hogy nincs egy nyomorult tuzfal az egesz elott, akkor annak a kozelebe se menj!
Már hogyne lenne ilyen, teljesen alap feature kéne, hogy legyen mindenhol.
https://docs.stripe.com/keys#limit-api-secret-keys-ip-address
https://help.mailgun.com/hc/en-us/articles/360012244474-IP-Allowlist
Oké, elismerem, ebben tévedtem, még rémlik is talán mailgunból ilyesmi. Megkövetem magamat, Ez speciel akkor abban véd, hogy az ellopott key-eket ne lehessen használni a kliens rendszeren kívül.
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