HnL416 - Adat szuverenitás és a kulcsos fiúk

Összefoglaló

A Hack és Lángos podcast 416. adásában a műsorvezetők, Antenna, Béla, Dev és Ninja a digitális szuverenitásról és a felhőben tárolt adatok védelméről beszélgetnek. A beszélgetés kiindulópontja, hogyan lehet úgy adatokat kezelni a felhőben, hogy azok ne kerüljenek harmadik fél…

Röviden

Műsor

Hack és Lángos

Megjelenés

2026. 01. 22.

Hossz

53 perc

Témák

adat szuverenitás, digitális szuverenitás, felhő alapú adatvédelem

Átirat

Az epizód beszélt szövege alapján indexelve

Ebben az epizódban

Sziasztok, ez itt a Hekes Lángos 416-os adása.

Itt van velem a stúdióban ABC sorrendben Bela.

Sziasztok, Béla vagyok. >> Itt van moduláris Dev.

Szia Dev! >> Sziasztok! >> És itt van a Nindzsa az elektronikus fajtából.

Nindzsa vagyok. >> A mai adásunkat is a Hogyan legyünk kedvesek a hosztársainkkal hangnemben ütjük meg.

Úgyhogy kezdjük is Venezuelával. >> Ne, nem akarok vezni.

Ez már múlt héten volt. >> Jaj, istenem!

De akkor miért nem veszed ki a listából?

Dur, >> de te raktad bele. >> Hát akkor vedd ki.

Kezdjük a kms-sel, mert én azért jöttem, >> még nem vagyok felkészülve lelkileg, >> de egyértván fölkészülve, de >> jó igazából e ez ez úgy volt kedves hallgatók, hogy hogy volt egy adás, amikor nem tudom emlékeztek-e, biztos emlékeztek, hiszen ti hallgatjátok, amikor alapvetően Béla megpróbálta a munkahelyi nyomorát ránk ültetni és tud segítséget kapni, de hát ugye azt azt mindenki tudja, hogy az újabb kábeld dugdos a laptopjába, >> mert neki vannak lukak rajta.

Ez a hülye fülhallgató. [nevetés] Nem tudjátok elképzelni, hogy már mennyi ideje elkéz a gyerek.

Gond van. >> Antenának lukirsége van, mert neki neki neki [nevetés] a notebookja csak egy van. >> Három.

Ez pontosan eggyel több, mint kéne. [nevetés] >> Ígyra.

Na, >> szóval igazából én meginspirálódtam, hogy hogy Béla így így használja ezt a ezt a közösséget.

És azért lássuk be, tehát hogy itt mi nem úgy kezeljük egymást meg az életünket, mint individuum, hanem mi egy közösség vagyunk, tehát hogy mi a a HVE mentalitás meg a meg a méhecskék. >> Ki az a Meggie?

És miért inspirálódtál rajta, vagy miért spirálódtál rajta? >> Ez annyira nem volt jó, hogy megálljak ebben a monológban. >> Majd kivágod >> ki majd legközelebb is 4:00-kor veszünk fel.

Tehát, hogy gondoltam, hogy itt itt a HV mentalitást kicsit használom, és behozom nektek témának, hogy beszéljünk arról, amiről nekem holnap elég erőteljesen standupolnom kéne [nevetés] munkahelyi környezetbe, és legalább annyira vagyok ebbe felkészült, mint amennyire indokolt a dev laptopján a cserélhetőség meg a modularitás.

Úgyhogy gondoltam, hogy feldobom nektek, hogy beszélgessünk arról, hogy hogy lehet szuverén módon a a felhőbe adatot kezelni.

Aztán annyira így így így megőltem ennek a gondolatnak, hogy én ezt elhozom hozzátok, és ti kiképeztek enny annyira megörültél a gondolatnak, >> hogy így mennyire jó, hogy nem kell utána olvassak, hanem ti majd ezt így elmondjátok, hiszen tietek hozzá.

Aztán rájöttem, hogy basszus, ezt még is tudom indokolni nektek, hogy hát manapság, hát ne viccelj, hát ott van Amerika, Geopolitika, hát hát féltjük az adatainkat.

Az EU egyébként is 1000er éve ugye privacy meg mit tudom én.

Tehát olyan szinteken meg tudom indokolni, hogy aztán ráíttem, hogy amúgy ez tök jó téma lenne adásban, hogy erről beszélgessük. >> Tanulunk és szórakoztunk. >> Nem. >> Mi történt? >> A hallgatók szórakoznak.

Remélhet. >> De a hallatók is tanulnak. >> De az a baj egyébként, hogy hogy időközben aztán utána gondoltam, hogy hogy sajnos tudom a választ, amit de adni fog, hogy ez miért nem lehet, meg még miért miért fog ez nekem holnap fájni, amikor ezt a a vendotoknak el kell mondjam, illetve hát közösen meg kell beszéljük.

Ö, szóval ja, tehát a lényeg az lenne, és az a felütésem, hogy adott egy mai modern cég, ahol felhőbe akarsz tárolni adatokat, de azt szeretnéd, hogy az itt tárolt adataid azok ne kerüljenek egy harmadik fél kezébe.

És itt a harmadik fél az lehet egy Amerikai Egyesült Államoknak a >> a harmadik fél az maga a Google, ami a maga a platformnak az üzemeltetője is, a cloud platformnak az üzemeltető. >> És ennél még bonyolultabb is a dolog, mert mert tegyük fel, igazából mondhatnánk termékeket, vagy beszélhetünk termékmentesen is, merthogy mindegyik ugyanezt csinálja, nem csinálja.

Tehát itt bármelyik felhőszolgáltató lehet a három nagy közül, ugye AVS, >> Google, >> Google, GCP, illetve a Microsoft, hát Microsoft az még az még az még még érdekesebb.

Ott különböző más állatfajok is léteznek, de de hogy ennél még keményebb a helyzet, mertogy mi úgy vagyunk ebben a szituációban jelen, hogy van egy tehát mi nem vagyunk közvetlen kapcsolatban a felhőszolgáltatóval, tehát hogy mi azt csináljuk, hogy eladunk terméket, vagy hát szolgáltatást egy bizonyos termékre alapozva.

Ez a term nevezzük ö nem tudom cloud strikak >> security security szolgáltatásnak >> tök mindegy.

Tehát hogy ő szerződésben van egy felhőszolgáltatóval és ő ott hostolja a dolgait és mi ezt a szoftvert használjuk a felhőben.

Tehát hogy mi nem konfigurálunk gépeket ott nem látjuk az egészet.

De ez azt jelenti, hogy ebben van, ha jól számolom, négy játékos.

Van egy ügyfél, aki aki az adat. vagyunk mi, akik játszunk az adattal, meg használjuk az adatot, meg az adatra alapozva kell döntést hozzunk, hogy security eleváns-e vagy sem. van a szolgáltató cég, ami a hát a detection engine-t vagy nem tudom, hogy lehet- ez szépen magyarul mondani, tehát azokat a a logikákat és detektáló módszereket alkalmazzák, amik az adat és az ő nagy-nagy machine learning, bla bla bla, deep learning satöbbi egyebekre alapozó logikájával jelzést ad, hogy történt-e behatolás vagy sem.

És hát van hát maga a platform, aki megadja a hátteret.

Na és ebből az lenne a lényeg, hogy ebből a sok játékosból két résztvevő láthatja a játékot, a könyveket vagy a bármit, hát a többi meg nem.

És ez a kettő, ez az ügyfél, meg mi lennénk, és se a security vendor nem láthatja azt, amit mi ott csinálunk, személyes adatok satöbbi.

Se a platform nem láthatja, amit mi ott csinálunk, se egy harmadik fél, akinek kiadhatják bírói végzésrel az adatokat. >> Mondjuk egy állam. >> Mondjuk egy állam.

Azért, mert Európában elég sok országban bizonyos területeken ezt előírják.

Hadipar, egészségügy, nem tudom, energia ipar satöbbi, ott ott nagyon-nagyon óvatosak azzal, hogy ki mit láthat az adatból.

És hát nem lenne jó, hogyha mondjuk hirtelen ne adj isten Európa elveszíteni az egyik országát, például Grönlandot, ami nem ország, hanem sziget.

Ö és hirtelen az oda vonatkozó adatok vagy az ottani eszközök azok amerikai nem tudom felhatóság alá kerülnének. vagy mondjuk a a Grönlandnak az energiaellátása vagy nem tudom bármilyen részéről vonatkozó adatokat azt mondaná az USA, hogy hát kedves Google Azure vagy vagy AVS, én úgy tudom, hogy a nem tudom, XY cég itt jaj nagyon csúnya dolgot csinált, úgyhogy kiírom az adatokat és hát mivel bírói végzés van, vagy hát nem is tudom, az lehet nem bírói, de lényeg az, hogy hogy neki ezt ki kell adnia, ezért ő ki is adja, és ez ezt nem szeretné se Grönland, se Dánia, se Németország, seá ne legyen megoldható az, hogy a kiadhassa a te adataidat. >> Így van.

És eh a legkézelfrefekvőbb megoldás ugye sok esetben az, hogy titkosítsunk, mert ami titkosítva vagyon, az hát ugye kivéve, hogyha nincs nem tudom kvantumszámítógépünk, akkor nem lehet visszafejteni. >> De az már nem működik.

Igen, lényeg. >> De hát ugye itt jön a kérdés, hogy akkor hogyan titkosítsunk, mert ugye titkosítunk, amiben én nagyon játos vagyok, hiszen nagyon jól tudok titkosítani, >> folyamatosan titkosítasz? >> Hát nem. [nevetés] Szóval erre milyen milyen elképzelésetek van nektek?

N >> to end. >> Mit jelent itt az end to end?

Meg hogyha N2 titkosítod, akkor igazából a játékost azt nem tudod használni, vagy a szolgáltozást nem tudod használni, hiszen ő nem lát bele. >> Aha. >> Tehát hogyha én titkosítom az adatot, amit beküldök a felhőbe, vagy hát a detection engineekbe, akkor ő nem tud detektálni, amíg nincs meg az a kulcsa, amivel ő kibontja.

De hogyha kibontja, akkor már ugye már lát mindent.

Ez egyébként nagyon érdekes, mert pont izét olvasok, kori doktorovot, a kis tesvót vagy kistestvért, és ott konkrétan van egy pároldalas rész, ahol elmagyarázza a nyilvános kulcsú titkosításokat, és ott a kulcscserét, illetve a a megegyezéseket abban, hogy hogy kinek bízol meg a kulcsában, és kinek nem, és hogyan hogyan tudsz megbízni valakiben úgy, hogy a hogy ahogy a ő és el tudja, tehát hogy biztos legyél abban, hogy azt ő titkosította, és hogy te teh te tehát nagyon Ő meg a tiedet.

Ezt nagyon érdekesen elmondja, és hát ott feltételezem, hogy ezt meg lehet csinálni, hogy ezt a titkosítást ezt olyan kulcsokkal generáljuk vagy csináljuk, amelyek amely egyemán több több többen hozzáférnek és akkor az fér hozzá a tehát a ugye a a a titkosítás úgy feltételez úgy történik, ez ilyen asszimmetrikus móka, hogy hogy én egy én a én egy nyilvános kulccsal mondjuk betitosítom az adatokat. azok azok ott utazás során meg a meg a tárolás során titkosítva vannak.

Viszont amikor dolgozni kell vele, akkor a vendornak van egy dekriptáló kulcsa, amivel ő azt meg tudja nézni, de a oprendszer vendor például már nem rendelkezik ezzel a kulcsal, tehát ő már ezt nem tudja megnézni.

Ő csak izét lát, titkosított junkot lát, feltételezem, de ti értetek hozzá, én én csak egy izé vagyok.

Én csak egy brutta hacker vagyok.

Aki [nevetés] még aki aki még mindig a szekézésnek a körívében gondolkozik.

A három három szekciót tudjunk elválasztani egymástól.

Van a data encryption at rest, az in transit és az in use.

Ez az a három, aminél lehet egy adatot itkosítani.

Az inest az azt jelenti, hogy amíg >> add >> rest amíg tölod van, létezik, vagy vagy ez mit csinál, >> ami ami amíg fekszik a diszken, ugye erre vannak olyan megoldások, amiket már egyszerű felhasználó, egy egyszerű customer, úgym vég felhasználó, vagy akár platformfejlesztő, alkalmazásfejlesztő cégnek nem kell ugyanúgy belemenni a dolgokba, mint egy egy üzemeltetőnek a cloud platformoknál.

Na na na na na kifejtem, hogy manuálisan amikor telepíti az operendszert, akkor luxot kell kézzel vagy valami mappaszerű titkosítást egyen egyénileg behúzni.

Most már nagyon jól szupportált hardveres titkosítások vannak business use casekre.

Ott van például a az Opá már nagyjából mindegyik új típus ONVM-e háttértár támogat, hardveres beépített titkol titkosítást.

Ezt a self encrypted drive-oknak hívják ezeket.

Tehát, hogy azt az az a lényeg, hogy volt valahol egy érzékeny adatunk, azt betitosítottuk valamilyen eljárással, és azt lehelyezzük valahova, hogy ha az le van oda helyezve, ha odamegy egy támadó, egy állam, egy bármilyen személy, és akár kiveszi a diszket, vagy a perzisztens adott árat abból a szekrényből, abból az eszközből, akkor sem tudja elolvasni, ne tudja értelmezni.

Az intranzit az a legegyszerűbb példája annak, amit látunk minden nap.

Tehát, hogy ez a https ez a kis zöld lakat még zöld lakat, ahol zöld lakat a böngészőben.

Tehát hogy két pont vagy több pont között van a titkosítás.

A ez ugyanúgy alkalmazható a VPN-nekre, tehát hogy nem csak a a a http https-es protokol TLS VPN-eknél.

És az inuse, az Inuse a legnehezebb, mivel tehát, hogy van egy adatod, tegyük fel a van egy érzékeny adatod, amit el szeretnél juttatni a-ból B-be, tehát te le akarod oda pakolni.

Szintén most ebben a példában nem fontos, hogy milyen titkosítást alkalmazol. betitosítod.

Az intranzit az ellen véd, hogyha valaki a kábelen ránéz valaki a hálózaton keresztül, nem a két pont, a két pont között valamilyen vagy passzív, vagy aktív támadást hajt végre az adat, illetve a fizikai layer ellen akár a ahhoz hozzán tudjon férni az adathoz.

És a végén, amikor megérkezik ez a már szinte duplán titkosított adat, az intranzit is lett titkosítva, akkor a végén ott kell lennie annak a kulcsnak vagy annak a megoldásnak, amivel a fél vissza tudja fejteni ezen adatcsomagot, hogy tudja használni.

Az inuse esetén ezt az inuse az az olyan, hogy hogy fogod az adatot titkosítod ö szintén különböző megoldásokkal és a végcélnak, aki például a vendorhoz, akihez megy ez az adat, őnek nem szükséges tudnia, hogy mi a szimmetrikus, aszimmetrikus homomorfikus kulcs, amit te, amivel te titkosítottad az adatot. ő tudja azon az adat, a titkosított adathalmazon dolgozni, és ő vissza tudja adni neked az eredményt, vagy esetleg az adatokat anélkül, hogy ő megismerné a titkosított adatban tárolt adatot.

Hát igen, mert ugye most tényleg a konkretizáljuk, hogy security megoldásokat nézünk, magyarul, te logokat küldesz be endpointról, egyebekről, tehát ott ott effektív adatokat küldesz be, amit neki értelmeznie kell.

Egy viselkedést, mondjuk egy EDR-nek a viselkedésén alapulva satöbbi, ott azért nem állt, hogyha tudja, hogy mi történik abban.

Tehát, hogy ugye nem arról van szó, hogy te mondjuk azt az adatot, nem tudom, feldarabolod és úgy tárolod, hanem arról van szó, hogy értelmezned kell különböző viselkedési mintákat, vagy nem tudom, támadási mintákat satöbbi.

Tehát, hogy az én megértésem szerint ahhoz, hogy ez a ez a detektálás létre tudjon jönni, ahhoz a feldolgozónak igenis pillanatnyilag látnia kell az adat. tudnia kell nemcsak a cer, hanem a PLX adatokat is.

A viszont több oldalról meg lehet közelíteni azt a azt az oldalát, hogy hogyan lehetne megvalósítani azt ideális esetben, hogy hogy működjön egy egyszerűbb detekció például különböző különböző nem specifikusan LDL rendszereknél, hanem inhouse LDL rendszereknél, merokat is fejlesztettem.

Ott ott is vannak szignatúrák. szignatúrának, ha nagyjából ismerjük a patterneket, például domain cím, domének, tehát IOC-k, domének, IP címek, fáloknak a hashei, esetleg kontextver hashek, ilyen SSD percepcionális hashek a képeknél.

Ezek ugye valamilyen adatot áttranszformálnak, vagy vagy már tartalmazzák ezen szignatúrát, hogyha lehesselek egy IP címet, lehesselek egy egy doményt, lehesselek valamit, azt utána a haseléssel úgymond megpróbálom biztosítani, mint egy vendor, hogy hogy ne lehessen könnyen ellopni.

Adok valamilyen más megoldást hozzá, hogy ügyfél specifikusan heselem. az ügyfélnek adok egy speciális kulcsot, és akkor kirakom úgymond ezeket a szignatúrákat az ügyféloldalra.

Én is védve vagyok, mert az ügyfél nem tudja…

Említett entitások

Témák

• adat szuverenitás
• digitális szuverenitás
• felhő alapú adatvédelem

Hallgasd meg

Gyakori kérdések erről az epizódról: „HnL416 - Adat szuverenitás és a kulcsos fiúk”

Több epizód a Hack és Lángos-ből

• HnL431 - Béla blokkolná 2026-05-07

  A Hack és Lángos 431. adásában Antana és Béla beszélgetnek. A srácok egy rövid szünetet tartanak, miközben mindenki szerez magának innivalót. Béla a rajzolásról mesél, majd a Wind…

• Logbook 431. 2026-05-06

  A "Hack és Lángos" podcast vendégei az adás rögzítésének UX buktatóiról, a spontaneitás fontosságáról és a hétköznapi rutinfeladatokról beszélgetnek. Kitérnek a tibeti homokképek…

• HnL430 - A szekuriti pénzbe kerül 2026-04-30

  Béla és Nindzsa Antenával beszélgetnek a Hack és Lángos 430. adásában. Két fő téma merül fel: a közelgő adóbevallási időszak kapcsán a NAV-os adathalász (scam) próbálkozások, vala…

• Logbook 430. 2026-04-29

  A Hack és Lángos podcast házigazdái, akik magukat Nindzsának és Heknek nevezik, egy rövid "logbook" epizódot készítettek. Fő témájuk egy okos konnektor (smart plug) bemutatása, am…

• HnL429 - Persona non secura 2026-04-23

  A Hacker és Lángos 429-es adásában a srácok a LinkedIn adatgyűjtési gyakorlatáról beszélgetnek. Kiderül, hogy a LinkedIn és a Microsoft közös adatgyűjtőként működik, és a LinkedIn…

• Logbook 429. 2026-04-22

  A műsorban a vendégek a bambusz és a merino gyapjú közötti különbségeket vitatják meg, különös tekintettel az etikai és tartóssági szempontokra. Az állatvédelem és a vegán életmód…

• HnL428 - Slack my b*tch up 2026-04-16

  Az adásban Antena, Nindzsa és Szabi beszélgetnek az iráni dróntámadásokról, amelyek Amazon adatközpontokat is érintettek. Kitérnek arra, hogy az ilyen globális infrastruktúrát ért…

• Logbook 428. 2026-04-15

  A Hack és Lángos podcast 428. adásában a technológiai és életmódbeli élményeket osztják meg a hallgatókkal. Az egyik műsorvezető arról mesél, hogyan énekelgetett véletlenül a mikr…

• HnL427 - Gundalf és a nagy AHa élmény 2026-04-09

  A Hack és Lángos podcast vendégei Antenna, Szenga és Nindzsa, virtuálisan pedig Béla is csatlakozik hozzájuk. A beszélgetés fő témája egy aktuális kibervédelmi jellegű ügy, amely…

• Logbook 427. 2026-04-08

  A "Hack és Lángos" podcast vendégei ezúttal az ultrafeldolgozott élelmiszerek világába kalauzolnak. Megvitatják az "Ultrafeldolgozott emberek" című könyvet, amely az élelmiszerek…