A GDPR szempontjából előnyt jelent, ha egy incidens során a kiszivárgó adatok mások számára nem értelmezhetőek.
Gondolok itt egy adatbázis feltörés, vagy ellopás esetére.
Vagyis miként tárolja a drupal az e-mail címeket, telefonszámokat, neveket, stb. ?
Van arra lehetőség, hogy ezek az adatok titkosítva tárolódjanak?
Így, ha az adatbázis kiszivárog az abban lévő adatokat nem lehet felhasználni és ez komoly büntetés mérséklési, vagy elengedési tényező adatszivárgási incidens esetén.
A témát lezárom, mert az eddig felmerült technikai kérdésekre született válasz, viszont más irányban a téma teljesen offtopic és személyeskedő lett. A további egyértelmű, technikai kérdéseket külön szálban kérem feltenni.
Köszönöm.
- NeverGone -
Drupal verzió:
Fórum:
Sima, mezei plain textként.
Sima, mezei plain textként.
Én egy webáruháznak csináltam AES migrációt, haat nem volt egyszerű, de ez egy jó start: https://www.drupal.org/project/encrypt
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
Hajaj ehhez shell is kell, ha jól látom :(
Egy olyan könyvtárra van szükség (php-encryption), amelyhez egy ilyen fájlt is tartozik:
Ugyanakkor shell hozzáférés nincs :(
MariaDB támogat esetleg valamilyen adatbázis szintű titkosítást, mint az Oracle?
https://mariadb.com/resources
https://mariadb.com/resources/blog/table-and-tablespace-encryption-maria...
https://mariadb.com/kb/en/library/data-at-rest-encryption/
--
Borsa Péter
https://peterborsa.eu
Valamit valamiért.
Valamit valamiért.
Db szintű titkosítást sem csinálnék shell nélkül, (meg anélkül sem) még ha lenne olyan jó fej a rendszergazda, hogy beállítja. Semmiféle titkosításnak nem állnék neki anélkül, hogy 100% kontrollom van a kulcsok felett.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
Valamilyen megoldást találnom kell
A GDPR kockázatai alól jó kibúvó, ha az érzékeny adatok titkosítva vannak tárolva az adatbázisban. A korábbi e-mail titkosító, már nem jó a 8-on. Az újhoz, aminek függőségi moduljai, amit ajánlottál szükség van olyan külső könyvtárra, amihez shell is kell.
Nagy könnyebbség, ha bármilyen hiba folytán egy támadó adatokhoz jutna az adatbázisból, akkor azok olvashatatlanok lennének. Ekkor ugyanis nem kell jelenteni az esetet a naih felé. Sajnos volt, már olyan eset egyes szolgáltatóknál, ahol mások hibája folytán történtek incidensek.
Mivel az e-mail cím egy fórum és egy blog esetén is szükséges a regisztrációhoz ez alap. Egy áruháznál a megrendelő adataiban név és cím, stb is lehet. A legjobb megoldás, ha ezek titkosítva tárolódnak, mert ekkor az adatbázis szivárgás kivédhető. A rendszerben pedig erősen korlátozható az adatokhoz való hozzáférés. Így minimalizálva annak az esélyét, hogy bárki hozzáférhessen személyes adatokhoz.
Mivel Amerikában is terveznek a GDPR-hez hasonló szabályozást, talán nem lenne rossz, ha mondjuk egyes mezőket ki lehetne választani a drupal-ban és azokat a rendszer alapból titkosítva tárolná. Szerintem ezt a funkciót érdemes lenne a maghoz adni, mert erősen az adatvédelem irányába halad a világ.
Szerintem nem lenne rossz, ha egy mező létrehozásakor ki lehetne választani, hogy az abba kerülő adat titkosítva tárolódjon. Illetve mondjuk a settings.php már alapból lehetőséget adna, hogy az alap titkosítás bekapcsolására, amikor mondjuk az e-mail címek titkosítva tárolódnának.
Úgy gondolom nem lenne haszontalan a drupal mag és a mező rendszer ilyen irányú bővítése.
Nem lenne rossz
csakhogy ez nem így működik. Egy titkosítás kicsit több annál, mint click-click + settings.php.
De tessék, egy barkácsmódszer: hook_entity_presave - encrypt email, hook_entity_load - decrypt email.
Igaz, hogy ezzel kb alapból kinyírod a levelezést.
Arról nem is beszélve, hogy db cache-nál értelme sincs a titkosításnak, mert a cache táblák titkosítatlanul tárolják az adatokat.
Amúgy nem értem ezt az egészet, megnéztem a php-encryption-t, semmi olyat nem láttam benne, ami miatt shell kellene, semmilyen faq, install leírás nem emlegeti.
Viszont:
1. A biztonságnak ára van, ha shell az, akkor a shell az. Van ezernyi szolgáltató, ahol van ssh access.
2. Egyáltalán nem vagyok benne biztos, hogy kell ssh. Egy file key-t simán fel lehet eftépézni webrooton kívülre, ennél több nem is nagyon kell az AES-hez.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
Nem értetted meg
Attól tartok, pont a lényegét nem érteted meg a GDRP-nek, ha úgy gondolod, hogy pusztán az adatok titkosított tárolásával kibújhatsz alóla.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Ez csak egy pontja a GDPR-nek. Az adatok biztonságos tárolása.
Nyilván, ha az adatok titkosítva vannak és úgy tulajdonítják el, akkor ez az opció, már védett.
A GDPR-nek számtalan biztonsági, jogosultságkezelési, kiszolgálási, adminisztratív és jogi pontja van.
Sajnos a tárhelyszolgáltató felett nincs hatalma a felhasználónak. Ezért, ha a személyes adat az adatbázisban titkosítva kerül tárolásra, akkor az adatbázist, már hiába tulajdonítja el valaki az érzékeny adatok értelmezhetetlenek számára.
Ilyen esetben az incidenst ugyan adminisztrálni kell, de nem kell jelenteni a hatóság felé és büntetés sincs!!!
Ettől még sok más pont van, aminek meg kell felelni, de a titkosítottan tárolt személyes adatok az adatbázisokat megvédik a közvetlen olvasástól idegenek számára!!!
Ugyan így, ha eltulajdonítanak egy laptopot és azon be volt kapcsolva a bitlocker, már védettnek számít, míg, ha csak egy belépési jelszó védte az adatokat, akkor nem!!!
Maga az oracle is kiáll a titkosítás mellett.
Ennyi erővel azt is mondhatnátok, hogy minek hash-eljük a jelszavakat, maradjunk a régi módszernél és tároljuk közvetlenül.
Ha valaki sima ftp használ az is rossz pont. Egy incidens esetén az új törvény szerint nekünk kell bizonyítani, hogy mindent megtettünk a biztonságért!
A titkosítás ennek egy fontos pontja!
Ilyen az adatok bekérésének minimalizálása is.
Szintén zenész a jogosultságkezelés, vagy a maszkolás!
Senki ne férjen hozzá a rendszeren belül egy adathoz, ha neki ahhoz nem feltétlenül muszáj hozzáférnie!
Egyes esetekben nincs is szükség a közvetlen adatra csak a struktúrára, stb.
Átnéztétek a GDPR teljes szabályozását?
Az adatbiztonság a legfontosabb! Ezért szabható ki a legmagasabb bírság!
Csak ez után jön a többi, mint az adatok hordozhatósága...
Fontos a dokumentáció is a jogalapok és a tájékoztatás, de az adatbiztonság és a gondos adatkezelés a legfontosabb!
Ezért kell mindent megtenni, hogy a legtöbb pontnak megfeleljen egy kis cég is, mert nincs mód idehaza a cégméret alapján történő kedvezményekre a biztonság terén! Bizonyítani kell, hogy a lehető legtöbbet megtette az adott cég! Az nem kifogás, hogy túl pici volt a költségvetése és nem telt rá!
Ezért a titkosítás az egyik legjobb pont, amit szinte mindenki megengedhet. A másik fontos pont a jogosultságkezelés és a kommunikációs csatornák védelme!
A GDPR igen összetett és kiterjedt szabályrendszer. Ahhoz azonban, hogy a bírság elkerülhető, vagy minimalizálható legyen igyekezni kell a minél jobb megfelelésnek.
Ne reménykedj, inkább nézz
Ne reménykedj, inkább nézz más szakma után. Már ha nem akarsz milliós bírságok árnyékában éjszakánként álmatlanul forgolódni. A GDPR egy inkompetensek által összehányt gumi jogszabály és sosem fogsz tudni és persze mások sem teljesen megfelelni neki. Főleg hogy az adatbiztonságnak kis része múlik csak a fejlesztőkön és az üzemeltetőkön.
Ha csak a CMS-ek valahogy technikailag nem reagálnak a helyzetre, viszlát netes biznisz az EU-ban(webáruházak, társkeresők, hirdetési platformok...stb.) és vele viszlát CMS rendszerek és persze webes fejlesztők, tárhely szolgáltatók és még egy csomó munkakör, amely szintén ebből a szakmából él. A bölcs EU ugyebár. Már az EU Fütyi Compliance is figyelmeztető jel volt, hogy itt hamarosan ámokfutásba kezdenek. Pár nagy szereplő megkockáztatja majd a rizikót, a sok milliós bírságokat, de a kicsiknek itt már nem osztanak lapot. Ha egy Facebook is viszi át az USA-ba amit vinni tud, az sok jót nem ígér. Szép volt ez a webes szakma. Élt húszon-valahány évet.
Béke poraira.
Egy CMS rendszer lényegében minden büntetendőt megvalósít. Személyes adatokat gyűjt a felhasználókról(jelszavakat, IP és email-címeket, felhasználói tevékenységeket naplóz..stb.) mind persze ezt adatbázisban tárolja, olyan 3rd party szolgáltatásokat integrál mint pl. a Google Analytics, vagy a Facebook, hírlevelekhez gyűjt felhasználókat és küld hírleveleket és még sorolhatnám a végtelenségig ami innentől igencsak kerülendő. Amit ez után biztonsággal össze lehet hozni, ahhoz elég a mezei HTML is. Forgó animált email gombbal és kockás abrosz háttérrel. Úgy is a '90-es évek féle retro divat jön vissza...
továbbra sem értelek
2018-ban ne legyen már gond biztonságosan elhelyezni egy file key-t egy serveren!
Szóval hol a probléma? Miért nem tudsz AES-t felrakni?
Ismét: A biztonságnak ára van. A cég meg eldönti, hogy hajlandó-e megfizetni az árat. Amúgy ebben semmi újdonság nincs, ugyanúgy az az alap, hogy egy entitás milyen kockázatot, milyen árért hajlandó felvállalni. A gdpr ezt a folyamatot annyiban befolyásolja, hogy a kockázat - az esetleges büntetések miatt - nagyobb.
Amúgy meg nem kell a pánik. Nem fognak május 25-étől gdpr crawlerek szaladgálni a neten, hogy a józskapistabt.hu-t majd jól megbüntessék, mert nincs kukielfogadó csekkbox a honlapján. És nem kell a 10-20 millió EUR büntetéssel sem ijesztgetni a népet. A közigazgatási bírság kiszabásának összetett feltételrendszere, az erre vonatkozó rész ráadásul tudtommal csak iránymutatás, ezt még a magyar jogszabályoknak is alkalmazni kell. De az egészen biztos, hogy nem kezdenek eurómilliós büntik röpködni a magyar kkv-nél május 25-től.
'Átnéztétek a GDPR teljes szabályozását?' - Minek? Én fejlesztő vagyok, nem jogász. Több helyen, akiknek dolgozok, komplett jogi csoport dolgozik rajta velünk és a vezetőséggel egyeztetve a gdpr megfelelőségen. Ehhez nekem nem kell értenem a egész gdpr-t, azért van a jog, hogy értelmezze, azért vagyok én, hogy kitaláljam, hogy kell megcsinálni amit a jog kér, és azért van a vezetőség, hogy eldöntse, hogy megéri-e megcsinálni, amit a jog kér.
És te hiába 'nézted át' a gdpr-t, az nem úgy megy, hogy majd jól átnézem, és mindent tudok. Ez egy olyan rendszer, hogy még a jogászoknak is komoly fejtörést okoz, mert hiába EU, attól még Mo-n a magyar jogszabályok érvényesek, a jogharmonizáció pedig a kormány feladata.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
félreértés
Sajnos attól tartok, néhány dolgot még mindig nem értesz.
Az adatok titkosításához kulcsot vagy jelszavat használsz. Biztonsági incidens esetén, amennyiben eltulajdonítják az adatbázist, amíg nem győződsz meg teljes bizonyossággal arról, hogy a titkosítást feloldó kulcs vagy jelszó nem került ki, addig úgy kell kezelned a helyzetet, hogy kikerült.
Szóval nem, ez továbbra sem fog téged megvédeni, de legalább rontja a teljesítményt és elveszítesz vele fontos funkciókat (pl. egy titkosított mezőben tárolt adatról hogyan készítesz SQL lekérdezést? Oh wait, a titkosított adat a keresőindexbe se kerülhet bele, szóval ez is ugrik).
Azért mész teljesen rossz irányba, mert abból indulsz ki, hogy az adatbázis tartalmát ellopják. Holott nem, abból kell kiindulni, hogy az adatbázis tartalmát nem lophatják el, a tárhelyhez nem férhetnek hozzá.
A titkosított adattárolást pedig csak azon a néhány mezőn érdemes használni, amely kifejezetten érzékeny adatot tárol és amivel nem akarsz komolyabb adatbázis-műveleteket végezni.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Részben igaz részben nem!
Szerintem az eleve rossz irány, hogy nem lopják el!
Ahol a magyar oldalak többsége van az fényévekre van egy Microsoft, Apple, Facebook, Google, vagy az Amerikai Védelmi Minisztérium rendszereitől!
Mivel ezeket a rendszereket is feltörték, így nem lehet arra hivatkozni, egy esetleges adatszivárgás kapcsán, -ahol az új törvény szerint önfeljelentést kell tenned -hogy arra gondoltam a rendszer feltörhetetlen így nem csináltam semmit.
Először úgy véltem a GDPR csak pár jelölőnégyzet, meg némi tájékoztatás. Aztán jobban átrágva a dolgot és egy jogásszal is társalogva, rájöttem, hogy ennél több.
A személyes adatokat nem is indexelheti a kereső az, már rég rossz! Szóval az új törvény szerint mindent dokumentálni kell és egy esetleges incidens esetén bizonyítani kell tudni, hogy mindent megtettem annak érdekében, hogy személyes adatok ne kerüljenek illetéktelen kezekbe.
Ha ekkor nem tudok mit felmutatni, akkor akár a 20 millió eurós bírságot is kiszabhatják, ami valljuk be a legtöbb magyar ember számára az öngyilkossággal egyenlő!
Tehát például, ha a tárhely szolgáltató azt jelzi, vagy én észreveszem, hogy hozzáfértek az adatbázishoz, de a jelek alapján csak ahhoz és abban a személyes adatok titkosítva tárolódtak, akkor, még csak jelentenem sem kell! Mindössze a saját nyilvántartásba kell feljegyezni.
Ha a kulcsok kiszivároghattak, akkor jelentenem kell és ekkor fel kell sorakoztatnom minden intézkedést, amit megtettem az adatok biztonságáért.
Ekkor, ha a hatóság úgy ítéli meg, hogy valóban igyekeztem mindent megtenni, akkor viszonylag csekély bírsággal is sújthat.
Az e-mail cím bekérése elkerülhetetlen, hisz szükséges a regisztrációhoz. Így ezt be kell kérnem és biztosítanom kell annak biztonságos tárolását. A név például nem ilyen, ha nem teszem kötelezővé. Ugyanis beírhatom az adatvédelmi szabályzatba, hogy az oldal működési logikája miatt a nevet minden regisztrált tag láthatja. Ekkor a regisztráló eldönti, hogy megadja a nevét, vagy nem.
A probléma a GDPR-el az, hogy mindent, de mindent a kisvállalkozásoknál is áthárít! Neked kell kockázatelemzést készítened, megállapítanod, hogy az adott folyamataidhoz milyen adatokra van feltétlen szükséged, ki kell jelölnöd azok élettartamát is, hogy mikor fogod megsemmisíteni őket. Biztosítanod kell az adatok biztonságos tárolását, az adatokhoz csak a jogosultak hozzáférését... Mindent dokumentálni kell.
Az is adatvédelmi incidens lehet, ha egy ügyfélszolgálaton az aktuális ügyfél mögött álló esetleg csak egy pillantást vet a monitorra, amin az előtte lévő adatai vannak. Tulajdonképpen ezt is jelenteni kell a hatóságnak, aki megállapítja a bírságot és örülhetsz.
Mivel a bejelentési kötelezettség is a vállalkozóé, így mindent jelenteni kell, mert, ha az előző esetben ha valaki az éppen távozó ügyfélnek azt mondja, hogy a mögötted álló belelesett az adataidba és az illető panaszt tesz, akkor sokkal durvább bírság kerül kiszabásra, hisz a vállalkozó nem jelentette az incidenst...
adok egy jó tanácsot
Adok egy jó tanácsot, mert szerintem kicsit túlpörgöd ezt a témát.
Arra törekedj, hogy az oldalad biztonságos és naprakész, tárhely rendben legyen. Jogosultságokat nézd át, ki mit ér el, legyen egyértelmű és érthető adatkezelési nyilatkozat, a látogatóknak az EU-s sütis modul legyen bekapcsolva.
Ne felejtsd el azt sem, hogy a GDPR nem csak a weboldalról szól, nézd meg, hogy a szervezetedben/cégedben milyen egyéb teendőid vannak.
Aztán figyelj. A GDPR kapcsán sok dolog nem egyértelmű még és bizony sokszor a jogi szakemberek sem értik, mellébeszélnek, félrevezetnek.
Nem kell attól tartanod, hogy máris az első nap bekopogtatnak hozzád, ez ugyanis nem arról szól, hogy bírságoljunk mindenkit szanaszét.
Aztán figyelj, mert úgyis menet közben, a gyakorlatban derül ki pontosan, hogy milyen teendőkre van szükség és azokat te hogyan tudod megtenni a saját rendszeredben.
Szerintem nem kell a felesleges hangulatkeltés és nem kell mindennek első szóra bedőlni. De ez az én személyes véleményem és te úgyis azt csinálsz, amit akarsz.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Felejtsd már el ezt a 20
Felejtsd már el ezt a 20 milliós bírságot! Nincs az a kkv itthon, aminek ilyen összegtől tartania kellene. Mondjuk egy Telekom méretű cégnél, akkor, ha egy scriptkiddie megszerzi a teljes ügyfélállományt + visszamenőleg 3 évre a hívásrekordokat is - esetleg.
Ne paráztassál már feleslegesen!
'a legtöbb magyar ember számára az öngyilkossággal egyenlő' - természetes személyről már ne is beszéljünk! Természetes személyre nem szabadható ki akkora közigazgatási bírság, ami ellehetetleníti.
Egyszerűen félinformációk alapján kelted a pánikot.
Nem, nem lesz lekapcsolva az Internet május 25-étől, és nem fognak csilliómillió eurós büntik röpködni.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
Nem a pánikkeltés a cél!
Nem a pánikkeltés a cél!
Ahol lehetőségem van ott meg is teszem, amit meg tudok tenni. Az, hogy a drupal és a hozzá tartozó modulok frissen legyenek tartva az alap dolog. Most jól jön a https és a biztonságos ftp is. Ez is alap dolog. Viszont én úgy érzem, hogy a titkosítás egy egyszerűen megvalósítható opció lenne. Maga a drupal is jobban meg tudna felelni ezzel a lehetőséggel a személyes adatok védelmének. Ha maga a mező rendszer támogatná a funkciót, akkor mindenki a saját esetében eldönthetné, hogy mely adatok minősülnek nála személyesnek és azokat titkosítva tárolva, már is tett egy lépést.
Ugyanakkor most én érzem úgy, hogy le akartok erről beszélni, hogy ez nem fontos.
Pedig véleményem szerint a drupal 8 magja jó lenne, ha tartalmazna erre a lehetőségre egy egységes megoldást. Ahogy idővel a média modul is integrálódott a magba. Így egy egységes média felületet biztosítva. Én úgy gondolom nem lenne értelmetlen, ha a drupal kapna egy mezőtitkosítási rendszer is. Mivel, ha a magba kerülne egy ilyen rendszer, akkor annak karbantartása is magasabb szintű lenne. Nagy előrelépés lenne a személyes adatok védelmében ez a drupal rendszerében a konkurens cms-ekkel szemben. Maga a drupal 8 amúgy is egy igen robusztus rendszer és, ha már a világ is a személyes adatok védelme felé halad talán nem lenne értelmetlen ez a megoldás. A testre szabhatóság miatt gondoltam a mezőrendszer kibővítésére. Így mindenki szabadon kijelölhetné a neki fontos mezőket.
Anno arra gondoltam, hogy egy ilyen rendszer, mint a drupal 8 megérdemelne egy egységes médiafelületet -nem csak a képkezelést kellene megoldania alapból -és belátták a fejlesztők is, hogy van értelme a dolognak. A mezőtitkosítás talán nem jár ilyen közvetlen előnyökkel, de továbbra is azt gondolom, hogy érdemes lenne ezzel a 8-as verziót felruházni.
A biztonságot alapból is szeretem ezért telepítem például a drupalt a szerver document root-ja mögé. Ez persze nem megoldás mindenre, de régebben is szerettem, ha a rendszer php fájljai nem elérhetők a közvetlenül a web-ről. Ez nem azt jelenti, hogy egy közvetlenül a web-root-ba telepített drupal rossz lenne.
Nem a pánikkeltés a cél, de a büntetés lehetősége valós és mivel nincsenek konkrétumok a hatóság lehetőségei igen tágak. Szerintem a titkosítási funkció nem ördögtől való és nem gondolom, hogy elvetendő ötlet lenne.
Sajnos a GDPR is egy olyan terület, ahol lehetnek problémák.
Van olyan autószerelő ismerősöm, ahol a konkurencia mindent elkövetett, hogy tönkretegye az oldalát. ehhez pedig igyekezett mindent lehetőséget kihasználni. Az illető vállalkozása mindennek megfelelt, de a rosszindulatú próbálkozások elhárításával töltött idő senkinek sem hiányzik.
Rendben
Rendben
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
Szerintem senki nem akar lebeszélni semmiről.
Szerintem senki nem akar lebeszélni semmiről. Csupán megjegyzés volt, hogy túlgondolod a dolgokat.
Az, hogy te mit gondolsz egy egyszerűen megvalósítható dolognak az egy. De ennek sok más aspektusa is létezik amit figyelembe kell venni. Van olyan, hogy egy-egy issue-ról évekig beszélnek, meg készülnek patchek hozzá mert bár egyszerűnek tűnt de mint kiderült mégsem az.
Mi van?! Nem tudom te hogyan üzemeltetsz, de lehet át kellene gondolnod pár dolgot. Ebből nekem úgy tűnik, hogy nem mozogsz elég biztosan ezen a területen és amit hallottál / olvastál itt-ott azokat alkalmazod. Az, hogy ezek mennyire jók vagy sem, az már egy másik kérdés.
Ahogy Szántó Gábor vagy nevergone is mondta, a GDPR-nak vannak jogi aspektusai is. Nem fekete és fehér ez, hogy ha adatbázis szinten titkosítok mindent akkor ha be is jutnak a rendszerembe, nem tudnak vele mit kezdeni. Én meg kipipálhatom ezt a checklist-emen.
Hidd el, ha valaki be akar jutni a rendszeredbe, akkor be is fog menni előbb-utóbb. Ha neki az érzékeny adatokra van szüksége, akkor nem csak az adatbázist fogja tőled ellopni, hanem a kulcsot is amivel dekódolni tudja az adatbázisodat. Sőt, megkockáztatom, hogy mindent vinni fog ami a kezei közé kerül.
Személyes véleményem az, hogy ha már kompromittálódott a rendszered, de te erről nem értesíted a felhasználókat, mert az adatbázis úgyis titkosítva volt és (szerinted) nem lopták el a mesterkulcsot, akkor morálisan az én szememben egy semmivé váltál.
Láttunk erre példát már a nagy világban, hogy feltörtek bizonyos rendszert / rendszereket, a cég meg próbálta eltussolni, kiderült aztán jött a nagy botrány. Mindenki írtózik attól, hogy feltörjék a rendszerét, ez természetes dolog. Inkább kiadnék egy közleményt amiben leírom a történteket, aztán leírom, hogy mit tettem azért, hogy ez a jövőben ne fordulhasson elő. Illetve javaslok a felhasználóimnak bizonyos lépéseket amivel ők is növelhetik a biztonságot, sokkal jobb hozzáállás. Mégegyszer mondom, hogy szerintem!
De, hogy ne csak a levegőbe beszéljek egy remek példa minderre, igaz ez nem külső támadás eredménye hanem egy belsős hiba: https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/
https://about.gitlab.com/2017/02/10/postmortem-of-database-outage-of-jan...
--
Borsa Péter
https://peterborsa.eu
Nem az etikával, inkább a joggal van a probléma!
A tárhely kapcsán persze, hogy ott a htaccess, de lehet index fájlokat is csinálni, de mit veszítek, ha a docroot mögött van a rendszer?! Nyerni lehet nem nyerek vele sokat, de, ha megtehetem, miért ne tenném. Az is ad némi pluszt, ha valami gond merülne fel a szolgáltatónál mondjuk a htaccess kapcsán.
Félreértetek. Még nem volt eddig személyesen részem incidensben és remélhetőleg a tárhelyeimen sem történt ilyen. (Vagy elhallgatták, de eddig csak szerverleállási hiba fordult elő egyszer hardverhiba miatt.) Minden esetre eddig nem volt ilyen gondom. Remélem a továbbiakban sem lesz.
Szóval nem azzal van a baj, hogy az ügyfeleket értesítsem, ha bármi problémát észlelnék. A kötelező hatósági bejelentés a problémásabb. Ráadásul, akik megítélik majd az óvintézkedések elégségességét vélhetően inkább jogászok, mint informatikusok. Őket kell meggyőzni, hogy körültekintően tesztelve, frissítve készült az adott rendszer. A folyamatos karbantartás megvolt és az adatok tárolása és kezelési is biztonságosan és körültekintően zajlott.
Nyilván a titkosítás sem tökéletes, mégis úgy döntött a törvény írója, hogy ekkor a hatóságot nem kell értesíteni és nem jár büntetés. Az iPhone titkosítását is fel lehetett törni, ha igazak a hírek, mégis a jogalkotó úgy döntött, hogy, ha a laptop titkosítva volt és úgy lopják el, akkor nem jár érte büntetés. Magát az incidenst ekkor is fel kell jegyezni és, ha szükséges értesíteni az érintetteket, de a hatóság ekkor nem büntet.
Más persze, ha magát a rendszert törik fel olyan jogosultsággal, hogy az érzékeny adatokat olvashassák. Itt is lehet olyan intézkedéseket tenni, hogy minél kevesebb embernek legyen jogköre olvasni egy adatot, stb.
Most biztos azt mondod, hogy, ha nem volt eddig problémám, akkor miért aggódok?
Attól, hogy eddig nem volt még lehet és az új szabályozásnak köszönhetően megbüntetik az embert, még, ha nem is 200 millió euróra, de, ha 10 ezerre, vagy ezerre az sem kevés.
Vegyünk egy példát:
Egy iskolában sok személyes adat található. Az adatokat, -mondjuk, még az informatikai korszak előtt -bezárva őrzik egy páncélszekrényben. Az ajtókat bezárják ám mondjuk valakik mégis feltörik és ellopják az adatokat.
Régen ekkor értesítette az iskola a rendőrséget ők lefojtatták a nyomozást és ennyi. szerencsés esetben előkerítve az elkövetőket.
Most viszont jön az információs hatóság, aki előtt nem lesz elég bizonyítani, hogy az ajtók be voltak-e zárva és az adatok zárt páncélszekrényben voltak, hanem a GDPR lehetőséget ad rá, hogy belekössenek, miért nem voltak jobb zárak, erősebb ajtók? Miért csak egy középkategóriás páncélszekrényt használtak... A végén pedig csak kiszabjanak valamilyen bírságot, ha akarnak.
Egy kis vállalkozásnál a kis bírság is sok. A fenti példában szerintem nem jár például bírság, hisz egy iskolaépületben általában normál ajtók vannak és a páncélszekrények sem a bankoknak megfelelő típusok.
Eddig a hatóságnak kellett bizonyítani, hogy hibáztak valahol, most a GDPR megfordítja az esetet és az adatkezelőnek kell bizonygatni, hogy márpedig nem!
Ráadásul közös felelősséget állapít meg, vagyis, ha több adatfeldolgozó is részt vesz a munkában és valahol náluk sérülnek a biztonsági feltételek, akkor nem csak a feldolgozót, hanem a kezelőt is megbírságolják, mondván nem auditálta jól a feldolgozókat.
Szóval igazából a bűnös vagy, míg nem bizonyítod, hogy mégis ártatlan vagy elv, ami nem tetszik a GDPR esetén.
Nagyon sok életszerűtlen dolgot tartalmaz a GDPR, amit nem lehet 100%-osan teljesíteni. Ami persze nem baj, de akkor ne bírságoljanak addig, míg ki nem alakul a pontos rendje, hogy hol, mi, hogyan elvárható. Tele van a jogszabály pontatlan kifejezésekkel. Hasonlókkal, mint a sok és kevés szavunk. Kinek mi a sok és mi a kevés?
Légyszi, engedd már el!
Iszonyat zöldségeket beszélsz..
De most komolyan! Küldj már be egy issue-t a dorgra!
https://www.drupal.org/node/add/project-issue/drupal
És írd be légyszi az issue linket, mert szeretném követni.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
Az utolsó bejegyzésem lett vona, ha nem írsz!
Viszont most, már elvárom, hogy részletezd tételesen a zöldségeket!
Elvárom, hogy indokold is meg! Kíváncsi vagyok rá és ha tévedtem, akkor elfogadom, de, ha képtelen vagy nyomós érvekkel tételesen indokolni állításaid, akkor állj ki egy hétvégére a piacra és árulj zöldséget, amiről várom a közvetítést a youtu-bra, vagy a facebook-ra, ha már a "hüleség" irányába vitted a témát.
Ahol igazad van ott elfogadom, mert egy vita lényege a probléma konstruktív megoldása. Aztán, ha sikerül megbékélnünk, akkor az issue nem rossz ötlet.
hozd létre
Szia!
Légyszives hozd létre a megfelelő issue-t az általad megfelelőnek gondolt megoldással. Addig ezt a témát hagyjuk, mert parttalanná vált. Mintha nem is egy nyelvet beszélnétek.
Szóval várom a linket.
Ellenkező esetben javaslom az egész téma lezárását.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Mikor írtam én bárkinek ilyen választ?
Szia!
: Iszonyat zöldségeket beszélsz! Nyugodtan vissza lehet nézni a korábbi hozzászólásaim, amikor mások bejegyzéseire reagáltam!
Most elvárom a részletezést! Egyrészt azért mert mindent, amit írtam nyomós érvekkel alá tudok támasztani, ugyanakkor lehet, hogy Ő jobb érveket tud felsorakoztatni. A saját érdekem is, ha az Ő érvei jobbak, hogy tanuljak tőle, hisz ezért regisztráltam erre a fórumra. Egyrészt, hogy tanuljak a nálam okosabbaktól, másrészt, hogy segítsek, akinek tudok. Soha nem illettem senkit ilyen bunkó megjegyzéssel. Ez a fajta gondolatmenet olyan mint az .nyád és a válasz rá a tied. Ez sehova sem vezet.
Azért van itt gondolom mindenki, hogy fejlődjön, ha pedig, már nagyon sokat tud, akkor, hogy segítsen!
Az ilyen hozzászólások azonban ebben nem segítenek. Most, hogy már megtette. Ezt nem lehet visszavonni. Ezért jogosan várom el, hogy aprólékosan részletezze és indokolja, hol és mi az iszonyat zöldség! Nem fogadom el, hogy visszavonja, mert, már megtette. Most már jogom van hozzá, hogy megismerjem az Ő álláspontját is. Nem érem be egy női "CSAK"-kal.
Bocsánat ezért, nem kívántam a témát folytatni, de nem hívhatom ki párbajozni, nem mellesleg az is a fent említett példával lenne egyenlő a probléma megoldását tekintve.
Ha informatikai hibákat vétettem, akkor feltétlen kíváncsi vagyok rájuk!
Ha a GDPR-t nem értelmeztem jól, akkor arra is. Végigolvasta egyáltalán az eddig kiadott szabályozást?
Sajnos több példát is fel tudok sorolni egyszerűbb eseteket tekintve, ahol apróságokon múlott anyagi veszteség.
Csak párat említve: Meg nem őrzött parkolási cédula miatt nem bizonyítható, hogy a sok évvel később kijött követelés alaptalan!
Egy ingatlanközvetítő szerződés apró betűs része miatt, amikor a közvetítő nem tudta eladni az ingatlant. A szerződés felbontása után, majd kicsivel később egy ismerősnek eladva a lakást, aki bizonyíthatóan nem a közvetítő közreműködésével szerzett tudomást az eladásról. A közvetítő egyszer csak megjelent és követelte a jutalékát!
Szóval érdemes vigyázni a jogi dolgokkal, mert ártatlanul is érhetnek kellemetlen meglepetések! A GDPR-t átolvasva pedig nagyon sok az olyan rész, ahol csak a hivatal, vagy az adott ügyintéző, vagy vizsgálatot folytató személytől függ, hogy miként jár el. Maga a titkosítási mizéria ebből indult.
Az issue valóban jó ötlet, ezt meg is írtam, de, mivel megbántott az illető az állításával, most, már várom, hogy alá is támassza azt. Amiből vagy az jön le, hogy az Ő bejegyzése volt megalapozatlan, vagy Én tanulok belőle. Netán részben ez, részben az.
lezárom
A témát lezárom, részletek a témaindító kérdésben.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Bocs, de én több energiát nem
Bocs, de én több energiát nem pazarlok erre, több hozzászólásban már leírtam/leírtuk, hogy mi van.
Ha megbántottalak, elnézést kérek! Ott van a leírásomban: időnként nyers vagyok és tapló.
Amennyi időt alatt megírtad ezt a hsz-t, beküldhetted volna a dorgra az issuet, aminek továbbra is várjuk szerettel a linkjét. Részemről kiszálltam.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.