• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    EXISGDPR - mýty, rady, konzultace
    GDPR - General Data Protection Regulation - Nová legislativa na ochranu osobních údajů, která začne platit od 25. 5. 2018!
    rozbalit záhlaví
    HARALD
    HARALD --- ---
    BLUERAVEN: Účel: nostalgické vzpomínání
    Zákonný titul: oprávněný zájem.

    :-D
    BLUERAVEN
    BLUERAVEN --- ---
    KASUMI: kdyz si spravne vymezis legitimni a legalni ucel tak by to nemel byt problem
    KASUMI
    KASUMI --- ---
    ot narek
    strasne me irituje povinnost osobni udaje mazat
    ja proste chci vedet, s kym jsem pred 10 lety jednala v nejake veci... grrrr
    konec ot narek
    ELWERINE
    ELWERINE --- ---
    BLUERAVEN: no big deal... Jestli se stane, ze mezi spravci existuje spoluprace, ktera vykazuje znaky spravce vs. zpracovatel, piseme dodatky tak, aby pro tyto pripady naplnovaly i cl. 28 odst. 3 GDPR. A ano stava se to pri smlouvach o spolupraci, ktere zahrhuji poskytovani ruznych sluzeb (zejmena pro zamestnance) z obou stran.
    BLUERAVEN
    BLUERAVEN --- ---
    KASUMI: jsem přesvědčený, že vztah pro předávání správce - správce GDPR určitě smlouvu nepředepisuje. Možná by se hodila v rámci obecných opatření k ochraně údajů, ale myslím, že by mohla nanejvýš pokrývat samotný přenos dat, protože za vlastní zpracování už bude zodpovídat každý správce sám. Ostatně odpovědnost za vlastní zpracování a tedy faktické rozhodování o něm určuje, kdo je správce.

    Někdy je ale podle méo názoru dost těžké odlišit, kdy jde o předání mezi správci a kdy mezi správcem a zpracovatelem. Docela dobrý příklad je třeba podnik, který vysílá zaměstnance na služební cestu a u cestovní kanceláře nechá zajistit pro zaměstnance letenku a hotel. Je cestovka spráce nebo zpracovatel? (já myslím, že zpracovatel). A co hotel a aerolinky a co když do vztahu vstoupí další zprostředkovatel :)
    ELWERINE
    ELWERINE --- ---
    KASUMI: jestli jsou to dva spravci a smlouvu chteji, tak jim piseme spravce vs. spravce - tedy vicemene ty zakladni pravidla ochrany osobnich udaju dame na papir. Jestli nechteji smlouvu a jsou spravce vs. spravce, tak jim to vysvetlime a staci.

    Zpracovatelske smlouvy dle cl. 28 GDPR ve vztahu spravce vs. spravce nedoporucujeme uzavirat - je to blbost.
    KASUMI
    KASUMI --- ---
    jsem trosku zmatena z jedne veci
    kdyz jsou dva obchodni subjekty, ktere si samozrejme nejake OU vymenuji, a to pro ucely plneni smlouvy, jsou to dva spravci a vzajemni prijemci.. ne? ne spravce a zpracovatel
    tze by nemuseli uzavirat zpracovatelskou smlouvou, ne?
    musi uzavirat jinou?

    dost subjektu posila smlouvy o zpracovani, ale podle me zbytecne
    nebo mi neco unika? to by bylo silene, mit s kazdym obchodnim partnerem smlouvu..
    CUTOR
    CUTOR --- ---
    BLUERAVEN: prectu. zpracovatel urcite nejsem. spise mi slo o ty formulace mlcenlivosti atd. Nesnasim papiry a nechce se mi to psat.
    BLUERAVEN
    BLUERAVEN --- ---
    CUTOR: než se pustíš do psaní, tak se ještě mrkni sem: https://gdpr.uoou.cz/caste-dotazy/

    Při své práci v IT se mohu k datům dostat. Jsem zpracovatelem?
    Pokud zajišťujete podporu, která nezahrnuje operace zpracování a ochrany osobních údajů (např. provádíte opravy zařízení a výpočetní techniky nebo jste dodavatelem služeb servisu PC), nejste zpracovatelem. Zpracovateli nejsou osoby, které se při provádění svých služeb, pouze nahodile dostávají do styku s osobními údaji. Náplň vaší činnosti byste měli mít jasně popsanou ve smlouvě, aby bylo zřejmé, že mezi vaše povinnosti nepatří osobní údaje zpracovávat. Současně lze doporučit, abyste se vůči objednateli smluvně zavázali k mlčení o veškerých bezpečnostních opatřeních a dále k tomu, že při jakémkoliv nahodilém přístupu k údajům budete tyto údaje chránit a zejména je nezpřístupníte a nepředáte nikomu dalšímu.
    CUTOR
    CUTOR --- ---
    Zdar nemáte někdo k nahlédnutí nějakou smlouvu (anonymní vzor) s externími IT? Jen že bych se inspiroval ohledně GDPR.
    Musíme upravit naše IT servismany co k nám chodí. Z principu mají velké pravomoci tak to potřebujeme aktualizovat.
    Předem děkuji
    RATTKIN
    RATTKIN --- ---
    moje první cookie hláška, která vypadá tak že bych s tím snad i souhlasil

    ZVIRATKO
    ZVIRATKO --- ---
    bozi, jasam...

    Some opt-outs may fail due to your browsers cookies settings. If you would like to set opt-out preferences using this tool you must allow third party cookies in your browser settings.

    CHOBOT
    CHOBOT --- ---
    EXIS: Jak už jsem psal níže, je to starej, na míru psanej eshop, kde všechny změny jdou přes outsourcovanou firmu, takže běh na dlouhou trať. Pracuju na tom, ale jde to bolestivě pomalu a ztuha. Navíc ten eshop dělali kdysi dávno lidi, který měli nějakou ochranu osobních údajů naprosto v prdeli, a to jak ze strany zadavatele, tak zpracovatele.

    Já pochopitelně vím, že to není dobře, a taky pracuju na nápravě, jen jsem potřeboval navést, co pisateli připomínky správně odepsat.

    Následná diskuze každopádně za mě docela přínosná :)
    EXIS
    EXIS --- ---
    CHOBOT: Z hlediska GDPR to asi není napadnutelné. Stejně jako GDPR říká (interpretuju), že i náklady na technické zásahy do IS by měly být přiměřené a odpovídající povaze. Nicméně bych být Tebou alespoň z toho mailu to heslo odebral. Tohle se dělalo dávno a dneska už to opravdu neodpovídá standardu zabezpečení. Pokud vezmu v potaz to, že banky do úprav nasypaly cca 150-300 mil Kč, tak pokud ty do úpravy dáš pár tisíc/desítek tisíc, tak je to odpovídající. Zkrátka a dobře, pokud Tě to, že máš eshop živí, tak by si měl přijmout vhodné technická a organizační opatření, aby si zamezil potenciálním problémům. Ale pochopitelně, můžeš se na to celé vysrat, ale pak se nediv. ;)
    MVEK
    MVEK --- ---
    CHOBOT: Posílání hesla zpět se často uvádí jako bezpečnostní nešvar, takže bez ohledu na GDPR to by fakt chtělo odstranit, mail je snadno napadnutelný. A přece jen v e-shopu jsou uložené informace o adrese, které může útočník zneužít, i pokud už tam nejsou údaje o platební kartě apod., aby mohl nákup provést.
    RATTKIN
    RATTKIN --- ---
    CHOBOT: posílat zákazníkům zpět nešifrované heslo je velmi nesociální. plno lidí ještě pořád používá stejné nebo podobné heslo na víc webů a takhle jim ho vyzradíš.

    nechápu smysl posílat lidem jejich informace zpět, jako kdyby zapomněli kde bydlí?

    některý weby pokud nedokážou 1 řádku kódu zakomentovat, by měli radši zkrachovat.
    KOC256
    KOC256 --- ---
    QUIP:
    uz trochu mimo, ale toco prijde jako zapomnel jsem heslo by melo byt jednorazove platne... Takze bych to uplne nesrovnaval... :)
    TRILOBYTE
    TRILOBYTE --- ---
    ZVIRATKO: Myslel jsem to na kdokoliv s pristupem k tomu mailu, ma automaticky pristup i tam co plati to heslo. To je fail.
    Jak uz tu padlo, muze to byt stylem vygenerovat, poslat, zahashovat a ulozit.
    ZVIRATKO
    ZVIRATKO --- ---
    TRILOBYTE: ano, muze, ale uz to neni soucast nejakeho dumpu.

    QUIP: ze je to blbost o tom zadna, ale pokud ten provozovatel neudela aspon to nutne minimum a nekdo ho hackne, tak to jde proste za nim. To same pokud to heslo posle emailem a nekdo se diky tomu k nemu dostane. Pokud se dostane na vic sluzeb se stejnou kombinaci user(email)/pass, tak si sice uzivatel muze rvat vlasy, ale vysetrovatel stejne da eshopu pokutu ze takhle ne.

    Je neco uplne jineho kdyz to heslo nekde lezi ve slozce "Archiv 2013" na mailserveru v plaintextu, nebo kdyz by nekdo musel kliknout na odkaz a resetovat ho, k te slozce muze mit realne pristup X lidi.
    QUIP
    QUIP --- ---
    ZVIRATKO: Nezatahuj do toho ukladani hesel v plaintextu a nebo unik hesel z databaze, to je jiny problem, nez ktery se tu ted resi.
    Pokud si uzivatel nastavuje stejne heslo na vice sluzeb, tak by ti zase kazdy z tvych odborniku, co by tam musel svedcit, rekl, ze je to blbost uzivatele. To opet nezkousej zamotavat do GDPR - nesouvisi to s tim.
    Taky se PIN k platebni karte posila v papirove obalce a pristup k ni ma vic lidi, nez kolik se potencialne dostane k nejakemu e-mailu po ceste. Stejne jako na zaklade GDPR nikdo nezakaze provoz e-shopu, ktere nepouzivaji HTTPS, i kdyz to znamena, ze prihlasovaci (a veskere ostatni) udaje od zakaznika do shopu a ze shopu k zakaznikovi putuji v nesifrovane podobne.

    Vubec se nechci prit o to, co je a neni fail, nebo best practice. Bezpecnosti webaplikaci a provozem serveru se zabyvam dlouhodobe a ty zminene nedostatky bych sam provozovatelum (ale i koncovym zakaznikum) vycital, ale porad si nemyslim, ze je to problem s ohledem na GDPR.
    A argumentovat "kdokoliv s pristupem k tomu mailu" je zcestny. K te e-mailove schrance nikdo jiny pristup mit nema. Pokud ma, je to chyba uzivatele. Me se zase nelibi, ze v dnesni dobe klesa uroven zabezpeceni internetoveho bankovnictvi, ktere se snizilo na uroven obycejneho webmailu - kdokoliv zna login a heslo, tak se tam prihlasi a projde si historii plateb atd.. Takze na to muzu rict, ze "kdokoliv s pristupem k tomu bankovnictvi..." oh wait, tam prece nikdo jiny pristup nema, nebo jo?
    Kliknutím sem můžete změnit nastavení reklam