Hirdetés
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!
-
Mobilarena
Új hozzászólás Aktív témák
-
bambano
titán
a korszerű adatvédelemmel most ne foglalkozzunk, ha a gdpr megfelelés a kérdés
a gdpr konkrétan szinte semmit sem tilt. a gdpr egy iránymutató, ami megpróbál végigvezetni a rendszered minden aspektusán, és hozzásegít, hogy felismerd, mik a kockázatos elemek. ezek után eldöntheted, hogy azzal a kockázattal mit csinálsz:
- elfogadható a mértéke, ezért semmit
- magas a mértéke, ezért lépéseket teszel a csökkentésére
- túl sokba kerülne javítani, ezért felvállalod.tehát az a megoldás, hogy precízen kielemzed a rendszert, és utána azt mondod, hogy rövid távon a felfedezett kockázat nem javítható értékarányos módon, ezért felvállalod, megfelel a gdpr-nak. persze egy fokkal jobb azt mondani, hogy csak rövid távon vállalod fel, és indítasz egy projektet a kockázatok megoldására, ami x ideig tart.
egyébként szerintem pont emiatt magasak a büntetési tételek a gdpr-ban, hogy arra ösztökéljen, hogy minél kevesebb esetben vállald fel a kockázatot.
ettől függetlenül azért vannak eszközök a gdpr-ban, hogy egy auditáláskor is elfogadhatóbb legyen a helyzet:
- az egyik az, hogy az adatkezelő írásos utasítást ad az adatfeldolgozónak, hogy hogyan végezze az adatkezelést. ebben előírhatod például az smtps használatát
- a másik, hogyha nem ez a jogviszony derül ki, akkor lehet kötelező vállalati magatartási szabályokat írni. ugyan ezt eredetileg arra találták ki, hogy ha egy cégnél a leányvállalat/tagvállalat nem gdpr-os környezetben van, akkor is rá lehessen kényszeríteni az adatvédelemre, de szerintem nálatok is lehetne a módszert használni. -
bambano
titán
szóval ha tényleg úgy van, ahogy írtad, tehát a vevő a másik céggel van kapcsolatban, ti meg, mint egy nagyker, fogadjátok a kisker rendelését, akkor a másik cég az adatkezelő, ti adatfeldolgozók vagytok, akkor nem nektek kell eldönteni, hogy mi legyen. a vízválasztó az, hogy ki határozza meg az adatkezelés lépéseit.
ez kiváló példa arra, hogy egy olyan valakinek meg kellene nézni rendesen a működéseteket, aki alapvetően informatikus, de a gdpr-hoz is ért.
-
bambano
titán
"Ugyanis nagyon sokat figyeltek/költöttek az elmúlt időszakban is ilyenekre, a mi szerveroldalunkon ez meg is van csinálva, bármilyen igénylésre tudunk törléssel reagálni, és amúgy is törlődik a törvényben írt időszak után a személyes adat.": az utolsó fillérig kidobott pénz volt az egész.
most vagy tudsz törléssel reagálni, vagy törvényben írt időszak után törlődik. ha mind a két feltételnek egyszerre megfelelsz, akkor legalább egy törvényt megsértettél.
-
martonx
veterán
Jelzem: a GDPR törvény 2 éve elkészült, csak éppen adtak 2 év türelmi időt a bevezetésére
Az már egyéni szoc. probléma, ha valaki beleszart ebbe, és még az utolsó pillanatban se volt képes erre odafigyelni. Megértem én, hogy kínos az életbelépése után ráébredni ezekre a dolgokra, csak nem most illene ezekre ráébredni.
Félre ne érts ez nem neked szól, csak tipikus tulajdonosi hozzáállás, hogy szedjük ki a pénzt a szoftverünkből, a törvényi megfelelésekhez / naprakészséghez szükséges "ingyen" munkákat meg elsunnyogjuk. -
martonx
veterán
Egyrészt az adatkezelők ti vagytok, ez 99%. Másrészt nem feltétlenül rossz a programotok, csak megfelelően dokumentálni kell az adatvédelmi szabályzatba (és igazolnotok kell tudni, hogy minden ügyfeletek olvasta és jóváhagyta a frissített szabályzatot), hogy ez így működik és kész. Ha valaki ezzel nem ért egyet, akkor ne használja / használja majd a leendő webes felületet.
De persze szakértő nem vagyok, tényleg érdemes lenne felbérelnetek valakit, aki bambanonél és nálam megalapozottabb véleményt tud mondani (90%, hogy tőle is ugyanezt fogod hallani). -
bambano
titán
a gdpr semmilyen követelményt nem támaszt a vállalati folyamatok alapjaival szemben, követelmény a bizonyíthatósággal szemben van.
tehát a programod csak akkor rossz, ha a gdpr-ra való hivatkozással akarod mozgásba lendíteni a főnökeidet, egyébként semmi baja, rendesen kell dokumentálni.
-
bambano
titán
megnyugtató, hiteles választ úgy lehet adni gdpr-ral kapcsolatban, ha valaki helyszínen alapos interjúzás után átlátja a helyzetet.
az még beleférhetne, hogy itt ingyen kapsz egy-két választ, csak te ezzel nem leszel kisegítve, mert információ hiányában a válasz vagy jó, vagy nem, téged meg bíróság fenyeget.
rendes válaszhoz az kell, hogy valaki elutazik hozzád, rádáldoz az idejéből mondjuk két munkanapot, és mond valamit, ami már megalapozott.
-
-
kingabo
őstag
Nem az a kérdés, hogy mit akar a főnök / mit tart jónak, hanem mit szeretne az ügyfél.
Ha olyan új feature-ök kellenek amik egy külön "modulba" kerülnek és a meglévő rendszer nélkül is használhatóak, akkor akár egy kisebb szeleten lehet próbát tenni, hogy a zügyfelek mit gondolnak. (attól eltekintve, hogy nem egy rendszert kell használni, hanem 2-t). Ha tetszik az irány, akkor egyre több dolog mehet az újba és a régi szépen feledésbe merül.
Egyébként tényleg jó lenne tudni több dolgot is a jelenlegi rendszerről. Lehet nem is olyan vastag az a kliens mint hiszed és "könnyen" lehetne cserélni a UI-t.
szerk: nem vettem észre volt még 1 oldal, plusz infókkal.
-
Bevallom, nem astam bele magam melyen, de ebben az esetben hogy jon ide egyaltalan a GDPR?
Mert az alapjan, amit eddig leirtal, nekem nagyon ugy tunik, hogy ebbol a szempontbol, illetve ezzel a programmal kapcsolatban jelenleg konkretan nem vonatkozik ratok az egesz.
Egyreszt nem foglalkoztok senkinek az adataival.
Masreszt meg csak nem is rendelkeztek ilyennel.Az meg, hogy csatolmanykent kapod meg, hogy kell ket csavar, egy csomag koton meg egy raklap kartonpapir, az szinten olyan dolog, hogy ha nagyon erolkodsz se tudod semmilyen profilhoz kapcsolni, azon tul, hogy xy ceg rendelt yx termeket, nem tudsz semmit.
Szoval, lehet csak En vagyok messzemenoen tajekozatlan ezen a teren (ez esetben elnezest), de nem ertem, hogy egyaltalan miert merul ez fel itt most.
Szvsz pont egy online applikacio eseten lehetne ez kerdes, de ott is csak akkor, ha barmi olyan adatod van, amivel tudsz valamit/valakit profilozni. Nameg ott mar felmerulne az, hogy ugyfeladatokat tarolsz, de ez most nem igazan van igy. Az meg, hogy a sajat gepet melyik ceg hogy vedi, az mar szvsz reg nem rad/ratok tartozik.
Aztan max ha nagy hulyeseget mondtam, majd a kollegak lefejeznek gyengeden oszt kesz.
-
Ispy
nagyúr
Szerintem ez inkább gazdasági kérdés, hogy megéri-e váltani vagy sem. Van sok felhős megoldás és van sok lokálisan futó program is, vannak cégek, akik inkább a felhőt szeretik, de vannak akiket ez elriaszt, ez nem annyira fekete-fehér, hogy mi most itt megfejtsük és ez már nem is programozás témakör.
Annyit tudom mondani, hogy mi is bevezettük a portfóliónkba a felhős megoldást, de nem a lokálisan futó program helyett, hanem mellette, így aki nem akar/tud saját szervert fenntartani az mehet felhőbe, ahol viszont a céges policy ezt meg sem engedné, azoknak meg van saját szerverük.
-
bambano
titán
mert a gdpr egyik fontos alaptétele, hogy mindig tudd, hol vannak az adataid.
ha webes cuccot csinálsz, akkor az adat maga marad a szerveren, csak a képe jelenik meg az ügyfélnél. ha meg vastagklienst, akkor a kliens program magába tölti az adatokat, és akkor oda kell figyelni arra, hogy mit tud letölteni üzemszerű működés esetén, és mit betörési kísérlet esetén.
-
bambano
titán
Sztanozs kolléga rendesen beletenyerelt, előfordulhat, hogy az adatvédelmi rendelet önmagában elég kényszerítő erő a webes cuccra.
és akkor nem az lesz a kérdés, hogy kiad-e 2-3 millió forintot egy új webes rendszerre vagy tákolják tovább 200 ezerért a régit, hanem az, hogy 3 misiért új rendszer vagy 3000 misiért adatvédelmi bírság.
-
A vékonykliensnek egyértelműen előnye a könnybben (természetesebben) megvalósítható többrétegű model, melyben kevesebb kockázatot tolunk a kliensbe. Amennyiben fontos, hogy jobban vigyázzon a rendszer a hozzáférésekre (pl adatbázis jelszó) és kizárólag csak a hozzáférési joghoz való funkciókat tegye hozzáférhetővé, akkor ez a járandó út.
Vastagkliensnél gyakran helyeznek el üzleti logikát, hozzáférési adatokat (beégetett jelszót, tanusítványokatt). Ezek egy hozzáértő kezében a rendszer jelszavai nélkül is kinyerhetők. Másrészt sokszor a vastagkliens látja el az autorizáció feladatait is (csak a szükséges menüpontokat / lehetőségeket jeleníti meg), de a háttérben teljes joggal fut (admin, vagy dba jogokkal). Az ilyen kliens-oldali korlátozásokat könnyű kikerülni.
Ha a fentiek nem fontosak (és néhány éven belül nem is lesznek azok), akkor érdemes lehet vastagkliensre fejleszteni. Ha elképzelhető, hogy a rendszert vállalati környezetben is fogják használni, akkor irány a vékonykliens és három- (vagy több-) rétegű architektúra.
-
bambano
titán
én nem tudnék neked konkrét választ adni.
az ilyen témákban inkább valószínűségek vannak, amik megalapoznak vagy elvetnek egy döntést.van egy programod, nem tudjuk, miben írták, nem tudjuk, mik a függőségei, mennyibe kerül karbantartani.
pláne nem tudjuk, mekkora meló folyton azon erőlködni az ügyféllel, hogy töltse már le az újabb verziót. és különösen nem tudjuk, az ügyfeled belső szabályzatai szerint mekkora meló új verziót letölteni, letesztelni, feltenni, stb.de azért ilyen hüvelykujj szabályokat lehet mondani, amik támpontot adhatnak:
- a szoftver hajlamos kuplerájosodoni. szerencsés esetben elindul egy jól megtervezett, tiszta felület + kódbázis, amibe időnként apróságokat beleraknak, de azt már nem azzal a fegyelmezettséggel, mint az eredeti kódnál. eredmény: a kód egyre gyorsulva halad a karbantarthatatlanság felé.
- a cég nagyon változik, emiatt bármennyire is jó a program, a cég kifordult alóla.
- a platform, amire fejlesztették, elavult, akár csak verziószámban, akár teljesen. én jártam így: a woodstock kihalt alólam.és tipikusan előfordul az, hogy hirtelen sokat kellene belenyúlni.
szemből tolja a témát, hogy ez sokba fog kerülni, és nem két nap alatt lesz kész.
annak kell ezt érezni, aki rendesen ismeri a programot, hogy érzi-e már a viszketést, hogy ki kéne kukázni az egészet és újrakezdeni nulláról.
a magam részéről, tájékozatlanul, biztos azt mondanám, hogy a webes felület király, telepített szoftvert adni kliensnek rossz gondolat. de nem hiszek benne, hogy ennek itt döntő érvnek kell lennie.
-
Ispy
nagyúr
Szerintem itt 2 különböző dologról van szó:
1) vastag kliens vagy vékony kliens
2) a kliens gépeken használt technológia (.net vs. böngésző alapú vs. akármi más)De mivel még mindig semmit sem tudunk a meglévő rendszerről, mit csinál, hogyan csinálja, van-e adatbázis és ha igen milyen és hol stb. így tényleg nehéz bármit is mondani, hiszen rengetek a változó.
És igen lehet nyugodtan egy SQL adatbázisod, a kliens meg semmi mást nem csinál csak vezérli az inputot/outputot, pl. meghív egy tárolt eljárást ami a szerveren lefut az input paraméterekkel és visszakapja a végeredményt, amit megjelenít valahogyan.
Innentől kezdve a nagy számítási feladattal járó tranzakciókat a szerveren fogod kezelni és kliens szépen vár, amíg nem nincsen az eredmény.
-
"mert maholnap elhajtják az embert a potenciális ügyfelek, ha azt mondjuk, hogy hozzánk belépő feltétel a Windows vastagkliens telepítése.."
Ez azért nagyon erősen függ a konkrét szoftvertől. Ha olyan, akkor lehet, hogy tényleg komoly követelmény, hogy elfusson egy mobilon is, de ha mondjuk amúgy is egy irodában használják, ahol amúgy is ott a PC a dolgozó előtt, ott meg inkább a vastagkliens előnyei jönnek elő.
-
Ispy
nagyúr
Csak távolról, hunyorítva nézve a dolgot 2 dolog van, ami nekem szemet szúrt:
- A cégemnek van egy programja
- aki nagyon akarja a cégünk szolgáltatásait, úgyis kerít egy Windows gépetTehát van már egy meglévő programotok, és gondolom az ügyfeleknek is van egyébként már wines gépe, hiszen most is használják a rendszert valahogyan.
Ezek után én biztosan nem indulnék egy 0-ról egy webes alkalmazás felé, mert az egy vagyonba fog kerülni a meglévő rendszer fejlesztésével szemben, csak azért, hogy web browserben fusson, amihez egyébként is kell egy valamilyen gép, rengetek szopás, idő és addig is mennie kell az üzletnek, tehát mellette menne a wines rendszer is gondolom, amihez kell gép.
Persze így látatlanban (milyen funkciók, mennyire bonyi stb.) ennyit gondolok róla.
Szerintem...
Ja, és a .net-es programot is át lehet tenni szépen azure-ba SQL szerverre, az üzleti logika futhat szerver oldalon nyugodtan és akkor máris nem olyan vastag az a kliens, egy bármilyen alap irodai konfigon el fog futni.
Nekünk az update is úgy megy, hogy adatbázisba felnyomjuk a frontend fájlokat, a kliens meg induláskor ellenőrzi a frissítést, és ha van lerántja lokálba és kész.
-
Az már egyéni szoc. probléma, ha valaki beleszart ebbe, és még az utolsó pillanatban se volt képes erre odafigyelni. Megértem én, hogy kínos az életbelépése után ráébredni ezekre a dolgokra, csak nem most illene ezekre ráébredni.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Új! Targus - USB-C Dual HDMI 4K HUB - 2 HDMI-vel. Saját töltő nélkül 2 monitorral (120Hz)
- Telefon felvásárlás!! iPhone 12 Mini/iPhone 12/iPhone 12 Pro/iPhone 12 Pro Max
- HP Omen 80G8E9 - 27" IPS - UHD 4K - 144Hz 1ms - NVIDIA G-Sync - FreeSync - HDR 400 - USB Type-C
- DELL PowerEdge R630 rack szerver - 2xE5-2650v3 (20 mag / 40 szál, 2.3/3.0GHz), 32GB RAM, 55992Ft+ÁFA
- Bomba ár! Dell Latitude 5590 - i5-8GEN I 8GB I 256SSD I 15,6" FHD I HDMI I CAM I W11 I Gari!
Állásajánlatok
Cég: FOTC
Város: Budapest