Gebruikers Edison Mail hadden toegang tot andermans postvakken

Gebruikers van Edison Mail konden kortstondig in de e-mailaccounts van andere gebruikers vanwege een bug. Accounts die aan anderen toebehoorden, waren toegevoegd aan de apps van de verkeerde gebruikers. De update is ongedaan gemaakt.

Volgens The Verge leek het probleem beperkt tot de iOS-versie van de app. Gebruikers die de kwestie aan de grote klok hingen, schreven dat ze zonder enige extra handelingen ineens de accounts van andere gebruikers in de Edison-app hadden staan, met vermoedelijk volledige toegang om mails te lezen en schrijven. Een gebruiker meldt dat een ander zijn mails heeft verwijderd. De update in kwestie zou de mogelijkheid toevoegen om appdata te synchroniseren op meerdere apparaten.

In een reactie tegenover The Verge schrijft Edison Software dat 'een klein percentage' met het probleem te maken had gekregen, dat de update is teruggehaald en dat de getroffen gebruikers gecontacteerd worden door het bedrijf. Op Twitter vragen de ontwikkelaars of getroffen gebruikers de appdata willen verwijderen en hun wachtwoord willen veranderen. Ook worden getroffen users uitgelogd.

Edison Mail heeft op de Play Store meer dan een miljoen installaties en staat op plek 115 in de ranglijst populairste productiviteitsapps in de App Store.

Reacties (63)

[Maurits van Baerle]

Ik begrijp niet zo goed wat er hier mis is gegaan. Ik begrijp dat Edison Mail een mail client is, niet een account. Hoe kan een client dan ineens toegang krijgen tot de accounts van anderen?

Moet je als gebruiker ergens centraal op een Server al je accounts invullen en wordt dat dan naar de Client gestuurd? Is er op die Server iets misgegaan?

[Blokker_1999]

Een mail client kan meerdere mailboxen beheren en moet dus van elke mailbox de login gegevens kennen. Heb je dan een app die multiplatform is, dan is het gebruiksvriendelijk als je gebruikers op een ander platform gewoon met hun Edison account kunnen inloggen en dan netjes al hun mail te zien krijgen in plaats van dat ze overal elke mailbox handmatig moeten gaan toevoegen.

Dan heb je dus inderdaad die credentials opgeslagen staan in een database op de server. Wat mij dan weer verbaasd is dat deze credentials, als ze al encrypted zijn opgeslagen, geen gebruikersspecifieke salt hebben voor die encryptie.

[Bert2000]

Hoe kunnen ze serverside push notificaties doen als er gebruikersspecifieke salt is ?

[kodak]

Zoals ik het artikel van The Verge lees heeft de client een update voor synchroniseren met andere apparaten gekregen. Dat synchroniseren werkt via een service van de Edison Mail ontwikkelaars. Dat synchroniseren bleek niet goed te werken. In plaats van synchroniseren met clients van het eigen account zou dat gedaan worden met clients van andere accounts. Als je wil synchroniseren met andere apparaten zul je dat waarschijnlijk in de clients van die apparaten moeten configureren. Wat Edison Mail daar precies voor gebruikt is jammer genoeg niet duidelijk maar hoe dan ook gebruikte ze die informatie over de accounts niet goed waardoor de clients blijkbaar gingen synchroniseren met verkeerde clients.

[Sjeefr]

Ik gebruik het niet, maar bij Spark zou dit theoretisch gezien wel kunnen. Je maakt daar, door in te loggen met een e-mail account, automatisch een spark account aan. Daaraan worden al je instellingen, inclusief e-mail credentials gekoppeld.

Als je op een nader apparaat Spark configureert, hoef je maar met 1 van alle e-mailadressen in te loggen, om vervolgens Spark het account te laten vinden en alles verder in te stellen. Heb je dus 5 e-mailadressen, dan hoef je er maar met eentje in te loggen om ze allemaal in te stellen.

Als een account dus aan de verkeerde accounts wordt gehangen, kan gebeuren wat hier dus is gebeurt..

[jurroen]

Spark net zo goed. Dit soort functionaliteit zou nóóit opt-out mogen zijn - met name op de manier hoe het gebeurd. Er is geen duidelijke aanwijzing wat deze clients op de achtergrond uitspoken - maar het zit weggemoffeld in een online pagina, waardoor je bewust op zoek moet gaan.

En Edison Mail had in januari niet in hun privacybeleid staan dat ze credentials of oauth sessies harvesten

[MASiR]

is er dan een opt out? ik vond Spark zo lekker werken maar dit is niet tof. Ga hem wel deinstalleren anders

[jurroen]

Ik ben van de meest populaire clients voor iOS door de privacy policies gegaan. Van Canary Mail weet ik dat die wel een opt-out hebben, je kunt met die client de fetch methode gebruiken in plaats van push. Dat het een opt-out is, in plaats van een opt-in vind ik niet netjes, maar daar valt beter mee te leven dan wat Edison Mail, Spark en anderen doen. Let wel, Canary is niet gratis en heeft vooral meerwaarde als je GPG gebruikt.

Zelf heb ik inmiddels mijn mail van mijn iPad verwijderd en het op PC en telefoon gehouden. Mijn telefoon is een Android, daar is FairEmail voor beschikbaar. K9 zag er destijds veel Spartaanser uit, maar het zat 'm voor mij vooral in de techniek; die crashte vrij regelmatig als de verwachte layout op de mailserver ineens anders was (ik download mijn mails met IMAP op de computer en verwijder ze na het ophalen van de server).

Ik denk dat de meest privacyvriendelijke oplossing voor iOS nog steeds de native client is. Maar die had een tijdje terug te maken met ook een nasty lek.

[MASiR]

gadver, ik blijf juist weg van anything Google en native Apple (Spark, Brave, Safari geblokkeerd van internet) omdat ik niet wil dat dergelijke jongens, die veel kunne weten en koppelen mijn gegevens hebben. Hoe handig ook, ik gebruik geen Apple pay - bankzaken houd ik verre van tech bedrijven.

[jurroen]

Helemaal eens. Ik draai dan ook een Google-loze en beter beveiligde Android versie

[Oon]

Het op een server opslaan van inloggegevens van je gebruikers waar dat overduidelijk niet nodig is gaat wel echt tegen alle veiligheidsstandaarden in. Zelfs dan zou je er voor zorgen dat deze versleuteld opgeslagen worden en dat de toegang afhankelijk is van een ingevuld wachtwoord oid, waarbij zelfs in het geval dat een ander account op de één of andere manier verbinding krijgt met de verkeerde gegevensopslag, er alleen maar nutteloze bytes terugkomen.

Maar we weten natuurlijk niet wat hun architectuur is. Ik hoop in ieder geval dat dit niet zomaar overwaait.

[Maurits van Baerle]

Ik zie op zich wel een scenario waar je dit centraal opslaat op een server. Je zou bijvoorbeeld de client zo simpel mogelijk willen houden en dus al het filteren, sorteren, labelen etc. centraal op een server willen doen. Die server haalt alle email van de verschillende accounts, filtert, sorteert, labelt alles en daarna haalt de client het pas op.

In zo'n geval is er een legitieme reden om alle credentials op de server te hebben én kunnen dit soort fouten optreden. Ik weet niet of Edison Mail zo werkt maar het zou een verklaring kunnen zijn.

[kodak]

Dat kan simpeler dan alle mails perse op de service van Edison Mail verwerken. Mail standaarden voorzien in mogelijkheid om mails van elkaar te kunnen onderscheiden via unieke kenmerken. Als je de service al iets wil laten doen dan kan je die kenmerken daarvoor gebruiken in plaats van de hele mail. Maar omdat mails clients die kenmerken zeer waarschijnlijk ook voor eigen sorteren gebruiken lijkt het makkelijker (minder opslag, minder resources, veiliger door zo min mogelijk gegevens) om de service alleen te gebruiken om de clients met elkaar in contact te brengen om onderling te synchroniseren. Dat gaat alleen niet zo prettig als de service de verkeerde clients met elkaar in contact brengt.

[Reactie gewijzigd door kodak op 24 juli 2024 13:36]

[WhatsappHack]

Vaak gaan ze er tussenzitten voor pushmeldingen (wat ik persoonlijk sowieso bullshit vind voor email, maar alé), aggregatie en custom filters. Vermijd dit soort diensten zelf als de pest.

[jahoorisieweer]

Zonder inhoudelijk zaken te kennen.

Maar sommige mail toegang is op gebruiker en gebruikersmappen enz, ga je in de "tree" een trapje/map/driectory hoger in structuur heb je daar ineens rechten en inzage enz kan ook het geval geweest zijn.

Zoiets komt vaker voor dan dat men denkt, bij van alles en nog wat in ICT.

Dan hangt het vaak geheel van de gebruikte clients en/of andere mogelijkheden af soms ook kennis van users of men dat misbruikt ja of neen

[t_captain]

Als de account van een bericht slechts een nummertje in een foreign key kolom van de database is (en de unit testen niet volledig coveren) is zo’n fout snel gemaakt.

Privacy by design omvat end to end encryptie. Dan had dit niet kunnen gebeuren.

[Reactie gewijzigd door t_captain op 24 juli 2024 13:36]

[svenslootweg]

Privacy by design omvat end to end encryptie. Dan had dit niet kunnen gebeuren.

Dat is natuurlijk wel heel kort door de bocht. End-to-end-encryptie vereist ondersteuning aan beide "ends" - laat e-mail nu net een protocol zijn waar dit in het algemeen een groot probleem is. Het lijkt me hier in ieder geval niet van toepassing.

Misschien bedoel je zero-knowledge encryption, maar daarbij is dan weer het probleem dat een hoop handige features niet implementeerbaar zijn wanneer je dat gebruikt.

Het is me overigens volkomen onduidelijk waarom je suggereert dat unit test coverage dit voorkomen zou hebben.

[t_captain]

Je kunt een unit test in je CI/CD straat bouwen die de database of (distributed) filesystem interactie mockt en checkt dat account x geen toegang krijgt tot berichten van account y.

Voor encryptie zou je eigenlijk S/MIME of PGP moeten inbouwen. Geen sleutel, geen content.

[jurroen]

Ik ben het volledig met je eens, hoewel ik wat verder zou willen gaan. Mails zouden op z'n minst versleuteld op de mailserver moeten staan, waarbij alleen de gebruiker bij de inhoud kan. Dat is wel "min of meer" wat partijen als Protonmail doen; echter vind ik OpenPGP.js geen fijne of geruststellende implementatie.

Gelukkig ben ik niet de enige met die mening. Ladar Levison, oprichter van Lavabit, heeft in het verleden de deuren van zijn bedrijf gesloten toen hij gedwongen werd om de encryptie keys (destijds de private TLS keys) te overhandigen aan de overheid - omdat Edward Snowden een klant was. Sindsdien heeft Lavabit een doorstart gemaakt en zijn ze bezig met de ontwikkeling van DIME. Het is geen extensie van de bestaande protocollen, maar een nieuw protocol, waarbij de server ook compatible is met de bestaande protocollen.

Er is een interessante presentatie over gegeven op DEFCON 22. Initieel was de bedoeling dat het er al was, maar door wat tegenslagen duurt dit langer. Het project is gelukkig nog levend en actief

[jahoorisieweer]

@jurroen
Over blijft altijd de zwakste schakel, je weet bijvoorbeeld maar zelden hoe goed en veilig de zaken aan de andere kant op orde zijn. (bij de ontvanger dus)
Zelf met end to end , weet jij ( altijd) wie er toegang tot die mailbox en device daar hebben of kunnen hebben?

Een soort goede AUDIT maar dan ook zelfs ontvanger kant , dus wanneer wie enz toegang / gelezen hebben kan ook helpen bij e.a. ( als men weet dat de verzender een bericht krijgt dan gaat men minder snel tot ongeoorloofde toegang over verwacht ik)

Wat betreft echt secure zijn en "verouderd" mail heeft men niet veel mogelijkheden dat klopt ook, en moet je je afvragen wat betreft gevoelige gegevens of je dat per mail wel wil.

Let wel mensen blijven mensen en veranderen in hun leven dus wat je op papier of mail ( is hetzelfde in weze) een ander toe laat komen is daarmee eigenlijk ook "gelekt" .

Mijn advies is altijd schrijf beter nooit ook niet in email wat je liever niet ergens anders bekend wil laten zijn of laten worden. ( data en stukken enz kunnen ook via andere wegen komen daar waar men ze werkelijk nodig heeft)

[Reactie gewijzigd door jahoorisieweer op 24 juli 2024 13:36]

[Q]

Ik zou dit bedrijf nooit meer vertrouwen.

Dit bedrijf heeft nooit maatregelen genomen om dit soort zeer ernstige security incidenten te voorkomen. De vraag is hoe dit komt, maar het antwoord op die vraag zal nooit bevredigend zijn.

Het kan zijn dat ze nooit een risico analyse hebben uitgevoerd om de meest ernstige situaties in kaart te brengen. Als je dat niet doet dan heb je ook geen helder beeld waar je focus qua security op moet liggen.

En als je dan al een risico analyse hebt gedaan dan moet je ook maatregelen identificeren en implementeren om die risico's zoveel mogelijk te mitigeren.

Het kan niet zo zijn dat 1 stomme fout door een developer tot dit soort ernstige security breaches kan leiden. Dan heb je geen enkele defence-in-depth geïmplementeerd, die dit soort fouten zouden moeten kunnen afvangen / detecteren.

Ergens zijn mijn verwachtingen van mensen misschien gewoon te hoog, maar dit is zo basic, het is gewoon te triest voor woorden.

Helaas zul jij als Tweaker misschien ook wel voorbeelden kennen van onafgedekte risico's binnen je eigen bedrijf, die ook nooit expliciet zijn benoemd. Een risico erkennen en bewust nemen* is één ding, maar er niet eens bij stil staan is echt van een andere orde.

• soms op het onethische af

[jurroen]

Los van de maatregelen, het bedrijf heeft in mijn inziens niets van doen met jouw credentials of oauth tokens. Helaas worden die wel door veel clients opgeslagen op de servers van de ontwikkelaar. Onder de noemer "dat is makkelijk", of "want push notificaties" - wat volstrekte onzin is, die mails kunnen ze prima fetchen op de client zelf.

Ironisch genoeg had Edison Mail toen ik dat onderzoek in januari uitvoerde dit (het opslaan van credentials) niet opgenomen in de privacy disclaimer. Anderen wel, maar alleen het feit al dat je zelf door een privacy disclaimer moet werken om te weten of een client dat doet vind ik uitermate kwalijk. Laat staan dat ze het gewoon doen, zonder het op te nemen in die disclaimer

[Q]

Ik denk dat je op een andere reactie reageerde

[kiddingguy]

Oops.... enorm groot foutje!
Kan je duur komen te staan als e-mail-clubje? Opdoeken tzt door dit soort taferelen?!

[Anoniem: 1350842]

Opdoeken lijkt me wel weer meteen van 0-100 in 0,1 seconde. Als we ieder bedrijf met een datalek zouden opdoeken kunnen we net zo goed het internet stoppen.
Moet er iets aan gebeuren? Zeker. Is die oplossing zeggen 'alle bedrijven met datalekken mogen niet meer bestaan', lijkt me een mooie uitspraak voor Reddit, maar niet helemaal hoe de echte wereld werkt.

[SED]

Het zou inderdaad een wat draconsiche maatregel zijn. Blijft staan dat een maildienst die al jouw mail op straat gooit wel een fikse deuk in het klantenvertrouwen zal oplopen en dat de markt zelf waarschijnlijk die conclusie zal afdwingen.
Ik zou in ieder geval meteen stoppen met deze onbetrouwbare dienst. Bugs kunnen elk bedrijf overkomen , maar sommige bugs moeten niet "kunnen" zonder gevolgen.
Dit is daar een goed voorbeeld van.

[kiddingguy]

Dan is de vraag natuurlijk hoe dit heeft kunnen gebeuren?

Wordt mail bij Edison op de eigen servers opgeslagen? Dan het is makkelijk(er) te verklaren? Of er is "gewoon" (naja, gewoon?!) een hele grote mix-up and mash-up van account-uitwisselingen geweest (incl. settings en wachtwoorden)? Maar dan nog moeten die gegevens van emailaccount i.c.m. ww 'ergens' opgeslagen zijn.

[kiddingguy]

Naja... bedoelde meer dat hierdoor er geen vertrouwen meer is door en bij de gebruikers, deze Groep een alternatief gaat , Edison gaan verlaten en er geen inkomsten meer voor hun zijn en Edison Mail het dan lastig gaat krijgen.

Hele snelle “jump to conclusion” zonder uitleg van mij

[Anoniem: 1075425]

Dit klinkt meer als damage control praatje.. In een wereld waar landen een AAA status krijgen als zijnde betrouwbaar en alles draait op vertrouwen. de realiteit zal zijn hoe zeer mensen dit nieuws lezen als zijn betrouwbaar of niet en dan gaat het vanzelf een weg in slaan. En dan zoon praatje / commentaar als wat jullie hier houden zal dat zeker beïnvloeden. Ik zeg niet dat het fout of goed is. ik vraag me alleen af hoe dit balletje gaat rollen in een wereld dat op vertrouwen draait.

[michielRB]

Ja, het is een beetje een alles-of-niets-show zo, maar in een niet zo ver verleden is iets dergelijks met Diginotar gebeurd. Nu was dat een hack/abuse door Iraanse (staats?)hackers en dit een foute update, maar het vertrouwen was weg. Diginotar had ook een veel grotere invloed, zeker in Nederland, maar als vertrouwen weg is, dan is het met een dergelijk bedrijf (terecht) gebeurd.

[Caelestis]

Op een begeven moment moet je ergens de streep trekken. Het is niet alsof ze aan iets bijzonder experimenteel werkten met onverwachte gevolgen die niemand had kunnen voorspellen.
Ze werken aan een standaard synchronisatie functie wat al jaren bestaat dus een foutje dat men gegevens van de verkeerde accounts binnen krijgt is te gek voor woorden.
Het hangt samen met dat achterlijke gedachte wijze dat de consument een prima kandidaat is om tests mee uit te voeren zodat je niet een uitgebreid test omgeving hoeft te hebben en onderhouden.
Het laat gewoon zien hoeveel zij geven om de veiligheid van jouw data.

Nou ben ik ermee eens dat je niet iedereen gelijk af moet schrijven met een datalek maar er moet een verschil zijn tussen een "bug" en "amateur programmeer praktijken".

[Blokker_1999]

Maar dat is toch exact hoe email over het internet gaat. Het hoeft zelfs geen database te zijn. Kan gewoon een losse bestandsstructuur zijn zoals de meeste mailservers het opslaan. Als ik naar mijn eigen mailserver kijk en ik kijk daar in mijn maildir, dan zie ik daar gewoon een directory structuur die overeen komt met de structuur in mijn mailbox en alle emails zijn hun eigen tekstbestand.

Email is oud en aan vervanging toe. Maar er is niemand die met een goed alternatief weet te komen dat ook nog eens een hoge adoptie heeft. Zeker in de bedrijfswereld blijft email koning.

[Jim80]

E-Mail is een protocol waar niks mis mee is, tegenwoordig wordt dat netjes via TLS versleutelt.

E-Mail zegt NIKS over hoe dat opgeslagen moet worden. Als dat op jouw server tekstbestandjes of een tekst database is, zegt dat iets over jouw server/software en niks over E-Mail.

Kijk maar eens naar Protonmail, die slaan alles end2end geëncrypteerd op, dus protonmail kan zelf de inhoud van hun gebruikersmails niet lezen. Bij hun had zoiets dus nooit kunnen gebeuren.

[jahoorisieweer]

Ja heb ook een voorkeur voor protonmail als externe dienst.

Nog liever gewoon eigen mailservers gebruiken.

Mail staat te vaak bij heel veel diensten hosters en isp gewoon in kale tekst opgeslagen waar dus jan en alleman ict stagaires admins enz kunnen meelezen en zelf met een tekst search vaak kunnen zoeken ook nog eens.

Laat staan wat met dergelijke backups hihi.

[Jim80]

Eigen mailserver is inderdaad te overwegen. Maar ook daar moet je goed opletten, want je server huur je meestal als VPS of als Dedicated server bij een provider.

Daar moet je dus full disk encryption gebruiken, anders kan je server provider alsnog meelezen.
En daar stopt het niet, want root- en encryptie wachtwoorden moet je meestal eerst via een web-console invullen, en ook daar kan je provider meelezen en zelf inloggen met het gecaptured paswoord.

De manier om het goed te doen is dan:
- installeer je server in de webconsole met tijdelijk root en disk-encryption paswoord
- log in via SSH en verander beide wachtwoorden

Zijn we nu safe?
Nee, helaas niet.... je provider zou nog altijd een memory dump kunnen doen van je server, en daar allerlei info uit halen.

[jahoorisieweer]

@Jim80 Eigen server virtueel in openstack zonder provider toegang, en diverse container oplossingen enz.

De benodigde keys kan jezelf wijzigen enz, maar dan nog bij bijv openstack oplossingen heeft de provider deze dus niet. ( dus juist niet inloggen met passwords, maar met een "key" en pasphrase. ) ( Of 2fa zaken inrichten kan ook met sommige gebruiken we daar niet.)

Denk niet dat ze daar niets met mem dump aan kunnen vangen , maar klopt daar heb ik niet naar gekeken wat dat betreft.

Buiten dat draaien we ofcourse lokaal een mailserver hier. EN ja niet die van MS hihi!

Maar dan nog alles is zo veilig als de zwakste schakel, mail aan de andere kant ( ontvangerkant) weet je best zelden hoe veilig dat daar in werkelijkheid is.

Dus gevoelige zaken per mail tja, denk dat bijv bij AIVD en co er weinig met "mail" verkeer gaat wat dat betreft.

[Reactie gewijzigd door jahoorisieweer op 24 juli 2024 13:36]

[Blokker_1999]

Een IT-er die mailboxen/folders/geschiedenis checkt zonder reden en zonder de nodige goedkeuring/procedures riskeert zijn baan te verliezen. En ik mag hopen dat de meeste zich daar ook bewust van zijn. Ook op je werk PC heb je recht op privacy. Je mag zelfs niet zomaar even gaan kijken in de logs van je proxy welke gebruiker naar welke site is gegaan. Je mag dat perfect loggen voor bepaalde doelen, maar om die logs te bekijken moet je weer goede redenen hebben.

[sspiff]

Dat is waar, maar ik kan mij voorstellen dat daar weinig toezicht op is in kleine en middengrote bedrijven, dus quasi geen pakkans.

Bovendien weet ik uit ervaring dat veel bedrijfsleiders van mening zijn dat zij hun werknemers op een dergelijke manier in de gaten mogen houden om te zien of ze hun job wel doen. Uiteraard totaal niet zo volgens de wet, maar heb je als werknemer bij een kleiner bedrijf weinig aan.

[Wim-Bart]

Ik nodig iedere werkgever uit om mail en home folders te checken en zonder toestemming informatie hieruit te verwerken... Wanneer je je pensioen veilig wil stellen is dat de meest fantastische methode van een werkgever om heel veel geld te verliezen wanneer een werknemen ontslagen wordt vanwege hieruit verkregen informatie. Onder de oude regels heb ik meegemaakt bij een klant (ergens tussen 2002-2006) dat een werknemer meer dan 1,5 ton netto mee kreeg, in een ander geval, in periode 2010-2014, bij een andere klant iets van 2 ton. Werkgevers zijn niet gek om dat te riskeren.

Daarom NOOIT je wachtwoord afgeven aan collega's. Wanneer ze toegang willen hebben dan moet dat via procedures.

[Reactie gewijzigd door Wim-Bart op 24 juli 2024 13:36]

[jahoorisieweer]

Hangt van afspraken en contract af, geen prive zaken in of per mail van je werk, wel toegang reeds in contract geregeld is mijn advies.
De meeste werknemers gaan namelijk ooit een keer stoppen met werken daar, dan maar ook bij ziekte, conflicten, sterfgevallen enz is het handig dit vooraf duidelijk en concreet op papier geregeld te hebben.

Indien nodig voor bedrijfsvoering en men kan dat hard maken mag men ook zonder toestemming in mailbox.
Indien men bij een mailbox wil en daaruit ook zelfs indien verboden, mails en informatie lezen en gaat gebruiken als bijv bewijs voor ontslag is dat zelfs ook al was het verboden nog steeds geldig als bewijs. ( bij ontslag en co hangt dan van de rechter af wat en hoe hij e.a laat mee wegen, waren er reeds bepaalde indicaties enz kan mail lezen dus zelfs legitiem geweest zijn beter wel vooraf informeren enz maar toch)

Per geval te bekijken, beter alles vooraf goed afspreken en procedures volgen yup

Let wel arbeids mail is er niet voor prive zaken maakt het gehele systeem extra onnodig insecure ook nog eens.

Wel beter dan te zorgen dat men of met eigen prive telefoon met internet toegang enz op werk mag en kan gebruiken, op eigen data verbruik Phone kaart of gast toegang internet bedrijfsnetwerk geheel gescheiden dus. ( of op andere wijze bij webmail enz. prive kan zoiets is in Duitsland meen ik bij wet geregeld )

Is niet zo moeilijk als men eenmaal die discipline heeft opgebouwd.
Ermee starten als men dat nooit gehad heeft of gewend is wel lastiger.

[Reactie gewijzigd door jahoorisieweer op 24 juli 2024 13:36]

[jahoorisieweer]

Goede reden om de logs wel te kunnen en mogen bekijken is als men vooraf een afspraak ( verbod) op bezoeken bepaalde sites heeft gemaakt.
Dan uit de logs ( of daarvoor gebruikte software ) dit via verwerking van die data naar voren kwam, ( dan heb je mogelijk niet expliciet in de logs gekeken.

Komt daar uit naar voren yup, kan het dus een goede reden zijn gericht in logs te mogen kijken wie wat wanneer, vooral als het sites betreffen die of de veiligheid in gevaar kunnen brengen of wat vaker voorkomt resources opsnoepen als bandbreedte van netwerk.

( mag ook zonder afspraken vooraf mochten er problemen zijn, maar afspreken vooraf wat wel of niet is veiliger en geeft ook meer duidelijkheid)

Je kan trouwens veel natuurlijk blokkeren en regelen wat bandbreedte enz , echter diverse social media en co en video sites heeft men steeds vaker ook voor het werk nodig.

Hoe je dat dan beter wel of niet vast kan leggen om video en dan vooral de BUMA achtige zaken en co goed geregeld te hebben. Weet ik niet maar best wel belangrijk.

Bij mail is logs filteren op fouten en co belangrijk voor goede algehele werking en functioneren van de IT en bereikbaarheid en blijven van bedrijf. (spam, virusmails idem enz , ziet men daar veel onregelmatigheden betreffende mailbox dan maar gauw toestemming vragen aan die gebruiker voordat je er verder induikt is wel handig ja.
Krijg je geen toestemming. als ICTer in overleg met leiding die box verder blokkeren dat mag namelijk altijd en heeft totaal niets met privacy en co te maken.

[Polydeukes]

de “meeste“ IT-ers checken wel wat je in je homefolder of mailbox bewaart...of browser history

Kun je dat staven met fatsoenlijk bewijs, of roep je maar wat op basis van onderbuikgevoel of anekdotisch bewijs? Het is nogal wat, wat je daar even stelt.

[NielsFL]

Zoals de waard is, vertrouwt hij zijn gasten.

[Wim-Bart]

Ik hoop het niet, want dat zou onze beroepsgroep heel erg slecht doen overkomen. Op het moment dat ik er achter kom dan is het snel einde verhaal van zo een https://www.watbenjedan.nl/

[Polydeukes]

Dat is een serieuze vertrouwensbreuk, en voor mij 'n reden om aangifte te doen. Absoluut onacceptabel gedrag.
Ook e-mail valt namelijk onder 't briefgeheim, ook je bedrijfsmail.

[gabba25]

Op je werk heb je net zo goed recht op privacy als persoonlijk. Dit is dus inderdaad wel een ernstige zaak.

[GoBieN-Be]

Kan in de arbeidsvoorwaarden opgenomen worden dat bedrijfs e-mail ingezien wordt door management en/of IT.

[Polydeukes]

Bedrijfsvoorwaarden staan niet boven de wet. Het Europese Hof voor de bescherming van de Rechten van de Mens heeft expliciet bepaald dat een e-mail bericht onder de reikwijdte valt van art. 8 EVRM.

[jahoorisieweer]

U neen (jein eigenlijk) want bedrijfs email geregeld in contract voor werk only heeft niets meer met avg van doen indien goed geregeld in contract.
Bedrijfs email is namelijk data van het bedrijf zelf, gegenereerd in werktijd tegen betaling enz, wel even goed vastleggen dus dan is het ok.
Let wel vooraf informeren van werknemer dus voor toegang en lezen is wel handig en alleen gebruik van te maken indien voor bedrijfs voering van belang enz.

Ook zakelijk brieven die aan iemand werknemen persoonlijk gericht zijn dat is namelijk ook normaal is schriftverkeer van het bedrijf en mag ieder die daar werkt en toestemming vanuit bedrijfs structuur heeft ten alle tijde bij indien nodig voor bedrijfsvoering en co.

Waarom simpel iemand kan ziek, worden, vertraging niet op tijd op werk, ongeluk en buiten westen of erger enz, dus regel dat vooraf goed anders zit je als bedrijf met gebakken peren want wat per mail en post plaatsvind is wel belangrijk voor jou bedrijf. ( is geheel niks persoonlijks aan die mailbox war afgesproken alleen voor werk, niet voor prive, en toegang hebben die en die personen en leiding enz. ) Best simpel dus. Wel vooraf goed regelen yup.

Als een werknemer maar wel vanaf zijn/haar/het werkplek / omgeving een mogelijkheid heeft prive te kunnen communiceren dus toestemming enz, maar daar kan gebruik maken van bedrijfsnetwerk expliciet uitgesloten zijn om gebruik van te maken.

Dan eigen smartphone en co toegelaten is ok, ( op locaties met gevoelige data dien je nog e.a. wel strak te regelen dan dat men daar niet even snel een foto van zaken papier of scherm enz kan maken, )

Je kan smartphone tablet van prive toegang via gescheiden gastnetwerk internet geven met beperkte bandbreedte enz. ook mogelijk.

Waar prive en zakelijk goed gescheiden en afspraken goed op papier betreft de zakelijk mailbox en toegang zou er dus geheel geen problemen dienen te zijn.

Is trouwens bij dat strikt scheiden ook nog eens een heel stuk veiliger.

Waar je wel op moet letten is dit!
Wet op de Ondernemingsraden

Nog handiger is alle zakelijke / professionele emails enz te archiveren document management enz. zoals het hoort dus te laten verwerken door die werknemer, waarna het gewoon zakelijke stukken enz zijn en niet meer persoonlijke (wel zakelijke) mailbox .

Ook handig te weten een werkgever kan en mag ten alle tijde een mailbox toegang blokkeren, dus als werknemer niet zo handig daar dan prive mail via dit mail adres te doen. ( is namelijk geen gegevens verwerking dat blokkeren en mag dus zelfs zonder dat er afspraken gemaakt zijn.)

IN veel meer gevallen mag men trouwens mailbox toegang blokkeren of hoeft men deze niet beschikbaar te geven/houden aan de mailbox "eigenaar" ( let daarop dus dat ieder vooral wat prive mails betreft zelf zorg dient te dragen voor backups en co, er is zelden ten alle tijde recht op je mailbox toegang en /of backups ook al is die van jou.


Let op is hier niet juridisch maar praktijk ervaringen en kennis hoe e.a. in nl en dld geregeld is of was.
Haal daar wel eens wat door elkaar , meen dat bij in DLD prive bellen en/of internet toegang mogelijk dient te zijn en mag. (niet persee over of met zakelijk netwerk en co maar prive bellen bereikbaar zijn kan men daar niet verbieden, in nl is dat wat anders geregeld toch? )

IN weze gaat het altijd over zo duidelijk mogelijk afspreken vooraf wat wel wanneer wie en niet enz, voorkomt men achteraf veel gedoe mee.
Want als je als bedrijf moet aantonen mail toegang was noodzakelijk voor bedrijfs voering en co achteraf is nooit handig.

Zelfs als mail toegang meelezen of kopieëren verboden is bij wet.
Dan nog kan men dit doen en zaken hieruit kunnen gewoon als bewijslast dienen om bijv. iemand te kunnen ontslaan.
Hou ook daar rekening mee, "een verbod op meelezen" is geen garantie dat jou mails dus niet gelezen of ergens gebruikt kunnen of mogen worden waar men dat nodig acht of wil!

[Reactie gewijzigd door jahoorisieweer op 24 juli 2024 13:36]

[Polydeukes]

Een werkgever die om juridisch correcte redenen (bijv om bewijslast te verzamelen voor ontslag) de zakelijke mail monitort is nog altijd wat anders dan een beheerder die zich uit verveling of nieuwsgierigheid toegang verschaft tot de mailboxen van collega's. Dat laatste is niet toegestaan.

[jahoorisieweer]

@Polydeukes Ja correct natuurlijk heb je daar gelijk, dat is overigens ook werkelijk van de gekke en onethisch enz.
Alles wat zomaar of uit nieuwsgierigheid of omdat men er geld voor krijgt om mailboxen enz te lezen, kopie maken enz is dat.

[RobIII]

Ik ben zelf IT-er en heb met dat soort gasten gewerkt. Van gemeente tot aan klein grote bedrijven heb je ze.

Dus nee ik zeg niet zomaar wat. Ik heb het zelf gezien

Als je dat al die keren niet aan de kaak hebt gesteld of aangekaart of gerapporteerd ben je zélf nét zo schuldig. Dus je zwetst of je bent medeplichtig. Which is it?

[Reactie gewijzigd door RobIII op 24 juli 2024 13:36]

[Nazlive]

Je mag er helaas van uitgaan dat als het kan, mensen het ook doen. Zo werkt deze wereld nou eenmaal.

[RobIII]

Het zal vast ergens, soms, wel eens voorkomen - dat heeft ook niemand beweerd. Maar wat @ThaddeusX hier insinueert is wel een totaal andere orde-grootte. Die doet het voorkomen alsof het aan de lopende band gebeurt en hij het bij talloze bedrijven/instellingen gezien heeft. Dat is nogal een verschil. En dan nog staat mijn punt: als je ziet dat 't gebeurt en je doet er niets mee dan ben je zelf nét zo schuldig.

[Oon]

We zijn inmiddels flink offtopic, maar het lijkt mij dat er toch wel heel veel systeembeheerders zullen zijn die bij het kopiëren van een mailbox of van een laptop het niet kunnen laten om snel een kijkje te nemen. Zo zitten mensen nou eenmaal in elkaar, je hebt toegang tot heel veel als systeembeheerder en als je het allemaal zelf ingesteld hebt is de kans groot dat er niemand ooit zal zien dat jij gebruik maakt van die toegang.

Dat het absoluut niet kan ben ik het helemaal mee eens, maar ik weet dat bijv. bij ons op de middelbare school vroeger de vrouw in de mediatheek altijd een scherm open had staan waar ze alle beeldschermen kon zien, en ik heb op Reddit (talesfromtechsupport o.a.) veel verhalen gelezen die er duidelijk op wijzen dat systeembeheerders meer zien dan ze volgens jou zouden moeten.

[Blokker_1999]

Een snelle verificatie of bijvoorbeeld een mailbox correct geëxporteerd is naar een PST file is nog iets anders dan gewoon jezelf toegang geven tot een mailbox om eens rond te gaan kijken. Ja, ik heb als helpdesk medewerker toegang gehad tot enorm veel mailboxen om mensen te helpen met het oplossen van problemen. Ik heb daar inderdaad ook private mails voorbij zien komen en ik heb gevloekt telkens ik mijn tijd moest verdoen voor iets wat achteraf een private materie bleek te zijn.

Maar mezelf zomaar toegang geven tot een mailbox van een gebruiker, puur uit nieuwsgierigheid? Ben je gek? En ja, er zullen er zeker tussen zitten die dat doen. Maar het zal een heel kleine hoeveelheid zijn en zeker niet de grote meerderheid. En zelfs sommige van dei verhalen op reddit kunnen ontstaan zijn zonder dat die persoon naar iets op zoek ging.

[jahoorisieweer]

@Blokker_1999 Blokker zo is het.
Dat het dus kan , zonder dat de betreffende gebruiker in kennis gesteld gaat worden is mijn probleem hiermee!

Een goed volledig toegangs beheer en audit is daar noodzakelijk.

Er zijn zoveel ( veel teveel) mensen die graag een centje bij willen verdienen namelijk!

[Reactie gewijzigd door jahoorisieweer op 24 juli 2024 13:36]

[jahoorisieweer]

Ik heb het gezien en lange geleden in opdracht gedaan toegang aan directie gegeven backup mailbox restored. ( verjaard dus hihi)
Komt echt vaak voor vooral bij mail ex medewerkers of ex ceo's en ook bij overnames en failisementen.

Is geen onzin dus en ja dat kan zo easy.

Ook stom dat alles in txt opgeslagen dan geen extra audit kent betreffende toegang, CPANEL kennen velen daar kan elke "admin" zo in alle mails even kieken.

Maar bij heel veel meer, even tekst search en je vind zelfs wachtwoorden terug in een backup van een mail archief. (Dat is dan klanten support geweest bij iemand die die mail en infos kwijt was ( ook dat mailaccount dus voor herinnering niet meer kon gebruiken , zelfs daar moet je oppassen dat je 100% zeker dat dus aan die werkelijk gebruiker / klant geeft en die met dat password nog wel actief bij e.a. mag , naja zou dan geblokt moeten zijn indien niet)

Zijn reeds tig jaren vele tekortkomingen in!

[Reactie gewijzigd door jahoorisieweer op 24 juli 2024 13:36]

[Fraaank]

Uiteraard heb jij natuurlijk de security/accesslogs hiervan doorgespeeld aan het hogere management toch?