Gmail voor scholen en bedrijven krijgt optie voor encryptie

Google geeft Gmail voor scholen en het duurdere abonnement voor bedrijven de optie om aan de kant van de client mails te versleutelen. Daardoor kunnen de servers van Google niet langer zien wat er in de mails staat.

Google Client Side Encryption in Gmail

Gebruikers kunnen zich in de komende maand opgeven voor de bèta, zegt Google. De functie heet CSE, Client Side Encryption. Het is voor het eerst dat er een optie komt om mails te versleutelen in Gmail, een dienst die inmiddels meer dan achttien jaar bestaat. Calender, Meet en Drive hadden al wel opties voor versleuteling aan de zijde van de client.

De bèta gaat functioneren op Workspace Enterprise Plus, Education Plus en Education Standard. Voor Enterprise-gebruikers komt de functie er voorlopig dus niet, evenmin als voor particuliere gebruikers van Workspace. Ook reguliere gebruikers van de gratis maildienst krijgen de optie voorlopig niet.

Het valt te bezien of die ooit zal komen, want relevante advertenties tonen op basis van de inhoud van mails is een verdienmodel van Google voor Gmail. Bij abonnementen komt het geld binnen via de abonnees en in die versie van de dienst zitten geen advertenties. Google zegt dat versleuteling voor andere Google-diensten er ook aan komt.

Reacties (48)

[amigob2]

Hoe werkt dit, die email is verstuurd en dat kan niet encripted naar iedereen. Dus de SMTP server ziet de mail nog steeds.
Daarnaast, als het clientside encripted wordt, hoe werk webmail dan ? ( of werkt dat niet meer )

[kuurtjes]

Het werkt alleen tussen Gmail adressen die de functie hebben aanstaan.

Het is waarschijnlijk gewoon een public/private key encryptie. De private key blijft in je browser, public key gaat naar Gmail. Andere gebruikers vragen de public key op en encrypteren hun bericht naar jou toe.

[latka]

Het is S/MIME blijkbaar, maar dan met een Google naam.

[Verwijderd]

Dit S/MIME noemen is als zeggen dat Netscape Navigator hetzelfde is als Google Chrome

[Verwijderd]

Dit heeft niets specifiek met e-mail (versturen) te maken maar voornamelijk key-management en dataversleuteling op Google servers. Het zorgt ervoor dat Google Workspace data niet meer gelezen kan worden door Google en dat 'jij' je eigen sleutels beheerd.

Als je dit allemaal niets zegt, dan ben je niet de doelgroep van deze functionaliteit. Dit is vrij complexe materie en voornamelijk voor grote organisaties bedoelt.
Mocht je dit interessant vinden, dan raad ik deze video aan:
Cloud HSM and Customer Managed Encryption Keys: Securing Your Data in the Cloud (Cloud Next '19)
En deze sites:
Google Workspace delivers new levels of trusted collaboration for a hybrid work world
About client-side encryption
How Google Workspace uses encryption to protect your data

[Superstoned]

… en daar ik vermoed dat de encryptie in de browser plaatsvind door JavaScript code geleverd door de Google server is het ook niet echt een oplossing als je Google niet (kan/wil) vertrouwen. Want die code kan natuurlijk ook ff je private key naar de NSA sturen. Beetje wassen neus dus maar ze voelen kennelijk de druk van de markt en zeker de privacy wetgeving…

[Verwijderd]

en daar ik vermoed dat de encryptie in de browser plaatsvind door JavaScript code geleverd door de Google server is het ook niet echt een oplossing als je Google niet (kan/wil) vertrouwen.
Eens hoor maar je plaatst natuurlijk niet je data bij Google als je die al niet kan of wil vertrouwen... Maar goed, anders staat het op een apparaat wat geleverd wordt met code geschreven door een andere amerikaanse megacorp gemaakt. En die maakt ook verbindingen naar alle kanten.... En daar draai je ook weer software van andere leveranciers op... Je kan letterlijk niet werken zonder ergens vertrouwen in te hebben.

Beetje wassen neus dus maar ze voelen kennelijk de druk van de markt en zeker de privacy wetgeving…
Voor zover ik het kan zien heeft dit niets met privacy wetgeving te maken? Het is een feature gemaakt voor de high-end klanten die een extra beveiligingslaag willen.

Zie het als eigen sleutelbeheer... Ja, de slotenmaker kan een extra sleutel hebben gemaakt (al wordt hij daar op gecontroleerd) maar je moet wel een slotenmaker vertrouwen... Anders heb je simpelweg geen slot...Diverse instellingen controleren daar weer op door middel van audits....
Dat kan je natuurlijk allemaal niets vinden maar een open deur is helemaal niet wat....

[mojo80]

Het valt te bezien of die ooit zal komen, want relevante advertenties tonen op basis van de inhoud van mails is een verdienmodel van Google voor Gmail.

Workspace (vroegere G Suite) en consumer e-mails worden sinds 2017 niet meer gescand op inhoud voor reclame-doeleinden.

Bron: https://www.blog.google/products/gmail/g-suite-gains-traction-in-the-enterprise-g-suites-gmail-and-consumer-gmail-to-more-closely-align/

[Antitech]

Weet je zeker dat ze dat niet doen? Als ik Google was dan zou ik hetzelfde beweren van anders krijg je gezeur.

[oef!]

Als ze beweren iets niet te doen maar dat toch stiekem doen én dit bekend wordt is het open seizoen qua rechtzaken en vertrekkende klanten. Google is te groot om te klootviolen.

[ronaldvr]

Oh net zoals met dat GPS tracken bedoel je? https://www.theguardian.c...es-user-location-tracking

Google has agreed to a $391.5m settlement with 40 states to resolve an investigation into how the company tracked users’ locations, state attorneys general announced on Monday.

The states’ investigation was sparked by a 2018 Associated Press story, which found that Google continued to track people’s location data even after they opted out of such tracking by disabling a feature the company called “location history”

[gooos]

Inderdaad, maar het zou wel fijn zijn als de encryptie mogelijkheid tzt ook zijn weg weet te vinden naar de betaalde Google Workspace Business edities.

[obimk1]

Heb een plugin voor FF die dit voor Gmail webmail al doet.

OT, Apple gaat ook end-to-end encryptie aanbieden voor al hun iCloud diensten (nog niet beschikbaar in alle landen). FBI is niet blij met dit.

[Reactie gewijzigd door obimk1 op 25 juli 2024 04:58]

[Dark Angel 58]

Nou... ik snap eigenlijk niet waarom FBI hiermee niet echt blij mee is.... Ik vind het wel hypocriet omdat ze hun gegevens ook hebben versleuteld

[Antitech]

Hoezo versleuteld?
Als de FBI de data wil hebben dan kunnen ze die krijgen, ongecrypt.
Google (Apple, FB, ...) zijn Amerikaanse bedrijfven en moet gewoon aan Amerikaanse wetten voldoen. Zelfs als de data in Europa staat, en zelfs als de data is 'gecrypt' .

Doen ze dat niet? Dan hebben ze een groot probleem. Dus als ze geen probleem met de wetgever willen dan moet er ergens een achterdeur in zitten.

[Reactie gewijzigd door Antitech op 25 juli 2024 04:58]

[obimk1]

Waarom wordt niet correcte informatie omhoog gemodereerd?

Apple en FBI hebben al rechtzaak gehad over encrypted data op een oude iphone. Als die data unencrypted was, was de rechtzaak niet nodig geweest.

https://en.wikipedia.org/...3Apple_encryption_dispute

[obimk1]

Mensenrechten organisaties hebben Apple al geprezen voor dit.

Met deze encryptie kan NIEMAND dit lezen of gebruiken.

Leg AUB uit waarom dit "hypocriet" is?

En er zijn hier ook rechtzaken over geweest.

https://en.wikipedia.org/...3Apple_encryption_dispute

[Verwijderd]

https://www.apple.com/pri...ent-information-requests/ of https://www.apple.com/leg...guidelines-outside-us.pdf voor in ons geval in de EU.

Zolang jij data bij apple of wie dan ook stalt, is dat opvraagbaar en beschikbaar voor authoriteiten. Een lijstje met wat apple beschikbaar heeft:

A. Device Registration
B. Customer Service Records
C. Apple Media Services
D. Apple Store Transactions
E. Apple.com Orders
F. Gift Cards
G. Apple Pay
H. iCloud
I. Find My
J. AirTag and Find My Network Accessory Program
K. Extracting Data from Passcode Locked iOS Devices
L. Other Available Device Information
M. Requests for Apple Store CCTV Data
N. Game Center
O. iOS Device Activation
P. Connection Logs
Q. My Apple ID and iForgot Logs
R. FaceTime
S. iMessage
T. Apple TV app
U. Sign in with Apple

Feitelijk kunnen ze remote in je hele toestel komen. Dus ja, end 2 end mag dan wel safe zijn, maar iedere boer zoals FB, Apple, Meta en toestanden hebben feitelijk toegang tot al je data. Is gewoon zo. En als third party zoals een politieagent erbij kan kan het bedrijf dat helemaal. In mijn optiek luisterd altijd iemand mee over de lijn. Simpel zat.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 04:58]

[Earry]

Als je dat document daadwerkelijk leest, wordt er een ietwat ander beeld geschetst. Voorbeeld:

For all devices running iOS 8.0 and later versions, Apple is unable to perform an iOS device data extraction as the data typically sought by law enforcement is encrypted, and Apple does not possess the encryption key. All iPhone 6 and later device models are manufactured running iOS 8.0 or a later version of iOS.

Enkele andere diensten zijn dubieus: encryption sleutels staan in de US datacenters. Verzoeken moeten voldoen aan eisen van het land waarin data staat. Betekent dit dat alle sleutels in de US staan, of enkel de sleutels van data die in de US staan?

[obimk1]

https://support.apple.com/en-us/HT202303

Op termijn wordt alles beschermd wat jij genoemd hebt, Apple heeft een paar maanden nodig omdit globaal uit te rollen. En deze informatie wordt ook door FB trackers opgesnord. FBI en overheden zullen niet blij zijn.

En Apple heeft vorig jaar een "antitrack" feature aan IOS toegevoegd. FB / Meta was daar niet blij mee, hadden zelfs advertenties in VS kranten gezet. FFB / Meta hebben $10 miljard aan advertentie inkomsten gemist.

https://www.imore.com/app...-facebook-10-billion-2022

[lenwar]

Nou ja... Versleutelen dan misschien wel, maar vast geen centraal beheer sleutels erbij, wat dit wel is. Dit is echt puur bedoeld voor interne e-mails binnen een organisatie. Dit is echt heel wat anders dan bijvoorbeeld S/MIME certificaten

[SunnieNL]

In hoeverre is Google dan al compliant dat scholen het uberhaupt mogen gebruiken? Zover ik weet zou een compliant versie pas in de zomer van 2023 komen.
Kan mij niet voorstellen dat dit het enige is wat ze zouden moeten doen?

nieuws: Waar blijft de aangepaste Google-software voor het Nederlandse onderw...

[CAPSLOCK2000]

In hoeverre is Google dan al compliant dat scholen het uberhaupt mogen gebruiken? Zover ik weet zou een compliant versie pas in de zomer van 2023 komen.
Kan mij niet voorstellen dat dit het enige is wat ze zouden moeten doen?

Mijn beeld is dat het in theorie compliant zou kunnen zijn maar in praktijk niet is.

Het probleem is dat je alleen compliant bent als je systeembeheerder bepaalde instellingen doet en bepaalde onderdelen helemaal uitschakeld of de gebruikers verbiedt om ze te gebruiken.

Dat moet je wel even zelf doen en dat beseffen de meesten niet want de mensen die het contract afsluiten houden zich niet bezig met het dagelijks beheer en gaan er vanuit dat de beheerders het wel allemaal even regelen. Die beheerders hebben daar echter geen besef van, dat zijn geen privacy experts die met een stofkam iedere setting gaan controleren en nadenken wat de gevolgen zijn. Een kant en klare set instructies is niet te krijgen want de cloud diensten veranderen te snel.
Daarbij accepteren gebruikers het niet dat er kunstmatige grenzen zijn. Ze willen de software "gewoon" gebruiken. Zodra iets wordt uitgeschakeld komt er een verzoek om het toch maar in te schakelen zodat gebruikers hun ding kunnen doen.

Het grote bedrijf zegt "Wij zijn compliant, dat kunnen jullie zelf configureren!". De inkoopmanager zegt "De leverancier zegt dat ze compliant zijn, ik ben klaar!". De systeembeheerder zegt "Ok, volgens de regels mogen jullie deze software alleen op maandagochtend gebruiken maar dan moet je op één been op stoep gaan staan met een vis op je hoofd en bokshandschoenen dragen tijdens het typen". De gebruiker zegt "Ben je helemaal mal? Ik gebruik mijn prive account wel even want daar werkt alles gewoon".

Het voelt allemaal als een groot toneelspel. We zijn enorm afhankelijk van een paar grote leveranciers zoals Google en Microsoft. Zo afhankelijk dat er mee stoppen voor de meeste organisaties onvoorstelbaar is en zo kostbaar dat het onmogelijk is. Veel alternatieven zijn er ook niet meer want die zijn van de markt gedrukt.
We móeten er dus wel gebruik van maken en dat weten ze. Aan beide kanten van de onderhandelingstafel staat vantevoren vast dat de uitkomst gaat zijn dat we de software blijven gebruiken. We kunnen een beetje rommelen in de marge maar helemaal stoppen is in de ogen van velen geen optie. Het resultaat van zo'n onderhandeling is ligt dan eigenlijk wel vast.

[Reactie gewijzigd door CAPSLOCK2000 op 25 juli 2024 04:58]

[SunnieNL]

Weet niet of het toneelspel is. Google Education is niet afgekeurd vanwege zaken die makkelijk te configureren zijn. Daar valt de Privacy Company juist over. Google kan zeggen dat ze A doen, maar juridisch staat het niet op papier.
Voorbeeld:

Onmogelijkheid om historische diagnostische gegevens te verwijderen: verhoogd risico op heridentificatie van gepseudonimiseerde gegevens en onrechtmatige (verdere) verwerking

en

Inhoudelijke gegevens (geen beperking verwerking tot het strikt noodzakelijke)

en

Diagnostische gegevens (toezegging dat er informatie komt over de inhoud van telemetrie in eind 2021, maar geen informatie over bewaartermijnen en verwerkers/derde partijen)

Dat is iets wat Google zo dicht kan timmeren als wat zij zeggen ook op waarheid berust. Echter, als je het op papier zet moet het ook wel kloppen. Als er controle komt en je doet niet wat je zegt, dan heb je een groot probleem. Dat Google nu zegt dat ze dit waarschijnlijk pas in zomer 2023 kunnen leveren geeft aan dat er toch echt wel een paar dingen niet goed staan vanaf de kant van Google of gewoon domweg zelf niet weten wat ze verzamelen.

Daarnaast kun je ook zorgen dat je by default compliant bent. Waarom moet ik als beheerder vanalles zelf configureren als je ook kunt zorgen dat by default de boel compliant is en ik alleen een afwijking kan maken daarin (waardoor ik niet compliant meer ben). Die configuratie kun je eventueel nog aan een notificatie hangen.

Het bedrijf waar ik voor werk hebben default de zaken compliant staan voor GDPR. Als je daar vanaf wijkt krijg je een waarschuwing te zien en moet je een checkbox zetten. Daarnaast hebben wij op onze website een heel document staan over wat er verzameld wordt, wie er toegang heeft, hoelang de retentie is van zaken, etc. Wil je meer weten, dan kunnen we een account geven met nog meer info zoals welke gegevens verzameld worden in de diagnostische gegevens met approval van onze DPO en legal team.

Diagnostische gegevens kun je altijd zelf verwijderen uit een supportcase en zo niet dan hebben wij op papier staan hoe lang wij het bewaren.

Die dingen hoor je als cloud bedrijf gewoon te hebben liggen. Het feit dat Google die niet kan aanleveren aan de Privacy Company is serieus een probleem.

[Reactie gewijzigd door SunnieNL op 25 juli 2024 04:58]

[CAPSLOCK2000]

Weet niet of het toneelspel is. Google Education is niet afgekeurd vanwege zaken die makkelijk te configureren zijn. Daar valt de Privacy Company juist over. Google kan zeggen dat ze A doen, maar juridisch staat het niet op papier.

Dat klopt en het hele flauwe antwoord dat je dan krijgt van de juristen is dat je Google dan wél mag gebruiken behálve voor activiteiten waarbij "er een risico op heridentificatie van gepseudonimiseerde gegevens en onrechtmatige (verdere) verwerking" is. Wat dat in praktijk betekent weet geen mens. De gebuiker/opdrachtgever hoort alleen "ja, het mag". De gebruiker op de werkvloer wordt dan geacht om per activiteit na te denken of dat mag op het platform van Google. Dat kan en wil de gebruiker niet.
De olifant in de kamer is dat als je bepaalde dingen niet met Google mag je dus ook nog een ander systeem nodig hebt waar die dingen wel mogen. Als je dat platform toch hebt dan kun je dat beter voor alles gebruiken want het is vragen of verwarring en vergissingen als je twee systemen naast elkaar gebruikt. In praktijk heeft niemand een tweede systeem naast Google.

Als er controle komt en je doet niet wat je zegt, dan heb je een groot probleem.

Die controle is ook een ding hoor. Als klant heb geen enkele mogelijkheid om wat dan ook te controleren. Als je er om vraagt wordt er wel gewapperd met een ISO-certificering of zo iets maar die omgevingen zijn zo groot en uitgebreid dat je nooit een goed beeld kan krijgen.

Dat Google nu zegt dat ze dit waarschijnlijk pas in zomer 2023 kunnen leveren geeft aan dat er toch echt wel een paar dingen niet goed staan vanaf de kant van Google of gewoon domweg zelf niet weten wat ze verzamelen.

Het rottige is dat de gebruikers moeilijk kunnen besluiten om een half jaar te stoppen met Google want ze kunnen in de tussentijd niet stoppen met werken/studeren. Een migratietraject kost al snel langer dan dat half jaar. Rationeel gezien kun je dus eigenlijk niks anders dan wachten en hopen dat het over een half jaar wel goed is. Als dan blijkt dat het niet goed is gaan we weer met z'n allen in gesprek en maken we nieuwe afspraken die na een jaar weer waardeloos blijken te zijn.

Daarnaast kun je ook zorgen dat je by default compliant bent. Waarom moet ik als beheerder vanalles zelf configureren als je ook kunt zorgen dat by default de boel compliant is en ik alleen een afwijking kan maken daarin (waardoor ik niet compliant meer ben). Die configuratie kun je eventueel nog aan een notificatie hangen.

Omdat het niet in het belang van Google is en het onmogelijk is om echt helemaal compliant te zijn zonder functionaliteit uit te schakelen waardoor hun product minder aantrekkelijk wordt. Daarom laten ze het liever een beetje er tussen in zweven.

[SunnieNL]

Het probleem wat kan ontstaan is dat er via het gerecht wordt gezegd dat scholen het niet mogen gebruiken op het moment dat een ouder dit aanhangig maakt. De uitspraak van de AP en Privacy Company is al geweest en de rechter zal daar vermoedelijk wel in mee gaan.

En er is zeker wel een mogelijkheid om het te controleren. Alleen het recht op inzage in je eigen informatie is er al eentje net als het recht op vergeten. Als een ouder dat opvraagt en de school dat weer doorzet naar Google als gegevensverwerker, dan kom je als school zijnde ook in problemen als Google niet aanlevert.

De vraag is dus, hoe groot schat de school de kans in dat een ouder dat doet, hoeveel gaat de school dat dan kosten? En weegt dat op tegen de kosten van een migratie naar een product wat wel voldoet.

Google heeft er alle belang bij om compliant te worden, omdat ze anders alle scholen in de EU kunnen verliezen als klant.

[Reactie gewijzigd door SunnieNL op 25 juli 2024 04:58]

[DutchHammer]

Dat is wel een heel ongenuanceerd beeld van de huidige generatie beheerders. Ik ben vanuit technisch beheer naar Dev Ops engineer gerold en ik beide vakgebieden was er juist veel aandacht voor privacy en het beschermen daarvan.

[CAPSLOCK2000]

Dat is wel een heel ongenuanceerd beeld van de huidige generatie beheerders. Ik ben vanuit technisch beheer naar Dev Ops engineer gerold en ik beide vakgebieden was er juist veel aandacht voor privacy en het beschermen daarvan.

Begrijp me niet verkeerd, ik zeg niet dat systeembeheerders het niet belangrijk vinden want het is precies omgekeerd. Systeembeheerders beseffen in ieder geval dat privacy belangrijk is. Maar de middelen waarmee en de omstandigheden waaronder ze werken maken het erg moeilijk om dat goed te doen.

Een voorbeeld is dat internet/cloud diensten veranderen wanneer de levernacier dat wil en als beheerder moet je er maar achteraan rennen. Ik heb recent nog een heel vervelende case gehad waarbij bleek dat we belangrijke data van gebruikers hadden omdat MS een nieuwe feature had toegevoegd die data begon te verzamelen en in de cloud opsloeg. Uitzetten blijkt niet mogelijk te zijn. De enige manier om aan de regels te voldoen is tegen mensen zeggen dat ze even 3 maanden geen Windows mogen gebruiken en hopen dat MS het dan heeft aangepast. Dat gaat niemand accepteren en dan gaan andere belangen voor.
Terecht hoor, maar de situatie is niet onze keuze en er is niks wat we hadden kunnen doen om het te voorkomen. De feature is vast aangekondigd in een of andere nieuwsbrief maar MS verstuurt zo'n 1500 nieuwsbulletins per maand, die kan geen mens echt allemaal bijhouden.

Het is niet eens uitzonderlijk want ik heb 2 van die zaken lopen, er zijn er waarschijnlijk nog meer waarvan ik nog niet weet dat ze er zijn.

Vandaar dat ik zeg dat het onmogelijk is voor systeembeheerders om het echt goed te doen. De wereld verandert onder hun voeten en de gebruikers accepteren de gevolgen daarvan niet want die zijn al helemaal niet in staat om er mee om te gaan. Ze gaan er van uit dat de systeembeheerder ze beschermd. Ik kan onmogelijk vragen om iedere dag de hele registry na te lopen op zoek naar nieuwe controls en zelfs als we die zouden vinden kunnen we ze niet altijd accepteren. Als het niet uit te zetten is dan voldoet het misschien niet aan de wet maar er is geen enkele manier waarop ik de organisatie kan vertellen dat ze helemaal geen software van MS meer mogen gebruiken (en ook geen Google of Apple).

Het wordt al snel een subtiel touwtrekwedstrijd over wat wel en niet mag en dan wordt IT in de rol van jurist gedwongen. Maar de gemiddelde systeembeheerder is geen jurist die een genuanceerde afweging kan maken over alle randgevallen en uitzonderingen van de GDPR, dat is echt een beroep op zich. Het heeft allemaal niks meer met techniek te maken maar is meer een "comliance"-spelletje geworden. ("Compliance" is, voor cynici, het vakgebied van mensen die beslissen welke wetten je overtreedt en welke boetes je accepteert omdat je organisatie, om wat voor reden dan ook, niet aan alle regels voldoet).

[ichnaton]

Waarom zou de afgelopen maanden zowel in Frankrijk als in Denemarken google suite gebanned zijn voor het onderwijs, op last van de rechter, wegens Europese regels...

[karelvandongen]

"France bans Office 365 and Google Workspace in schools" Dus ook Microsoft !.... Dat geeft wel aan hoe lastig het is om aan die regels te voldoen.

[karelvandongen]

Je hebt al een op https://sivon.nl/2021/10/alles-over-dpia-google-workspace/ al een prima lijst, die er voor zorgt dat je aan de huidige interpretatie van de wet kunt voldoen, ook met Microsoft office 365 zit je trouwens met het zelfde.

[SunnieNL]

Dat is niet helemaal waar. Want als je het document van juli dit jaar leest op https://sivon.nl/wp-conte...kspace-for-education.docx , dan zie je dat Google nog heel veel moest regelen voor 31 december dit jaar. Geen idee of ze dat ondertussen al gedaan hebben, gezien dit document niet is bijgewerkt. Maar mocht dat niet het geval zijn dan vervallen alle dpia die gebaseerd zijn op dit document over 2 weken.

[karelvandongen]

Op https://sivon.nl/dpia-google-workspace/ kun je lezen, dat ze in principe op schema liggen. En zoals gezegd Microsoft heeft ook genoeg te doen.

[Iblies]

Voor Enterprise-gebruikers komt de functie er voorlopig dus niet, evenmin als voor particuliere gebruikers van Workspace. Ook reguliere gebruikers van de gratis maildienst krijgen de optie voorlopig niet.

Het valt te bezien of die ooit zal komen, want relevante advertenties tonen op basis van de inhoud van mails is een verdienmodel van Google voor Gmail.

Voor Essentials

Not available to Google Workspace Essentials, Business Starter, Business Standard, Business Plus, Enterprise Essentials, Education Fundamentals, Frontline, and Nonprofits, as well as legacy G Suite Basic and Business customers

Wat nog steeds creepy is,
Met name MKB gebruiken de essentials ivm kosten,
wat betekent dat je e-mails niet versleuteld zijn.


Kleinere onderaannemers zijn hierdoor per definitie een groter risico in bepaalde sectoren en daardoor per definitie verbieden daar gebruik van te maken.

[latka]

Het is S/MIME, dat kost niets. Tijd om uit de cloud te gaan om de kosten weer te drukken.

[Verwijderd]

Wat nog steeds creepy is,
Met name MKB gebruiken de essentials ivm kosten,
wat betekent dat je e-mails niet versleuteld zijn.

No offense maar als je dat 'creepy' vindt, dan weet je waarschijnlijk niet hoe e-mail werkt.
E-mail werkt via een store and forward principe en wordt al sinds jaar en dag 'niet versleuteld'. Dat wil zeggen, meestal is de communicatie tussen mail servers wel versleuteld (TLS) maar tussendoor dus niet. Dat wil je ook niet want je moet de inhoud scannen op malafide zaken. Dit geld niet enkel voor e-mail, maar iedere vorm van communicatie waar bestandsoverdracht mogelijk is.

Wat betreft deze feature en kosten... Tja, het is een 'enterprise' feature en daar betaal je meer voor. Ik zie niet waarom dit anders is dan alle andere software of diensten. Je betaald meer voor geavanceerdere functies.. Zo werkt dat nu eenmaal...

Kleinere onderaannemers zijn hierdoor per definitie een groter risico in bepaalde sectoren en daardoor per definitie verbieden daar gebruik van te maken.
Kleine ondernemers lopen inderdaad een groter risico maar deze feature doet helemaal niets om dat 'risico' groter of kleiner te maken.

[CAPSLOCK2000]

Ik heb twee vragen.

1. Werkt dit ook buiten het Google ecosysteem of werkt het alleen voor gmail-gebruikers onderling?

2. Wie bouwt en implementeert "Client Side Encryption" en hoe komt die code op mijn computer?
Ik ben een beetje bang dat het antwoord is dat het Google zelf is die de code schrijft en dat de code ook door Google wordt uitgeleverd via javascript (of door een hacker die zich voor Google uitgeeft). Dat betekent dat die code op ieder moment vervangen kan worden door andere code die niet veilig is.

Lees dit aub niet als bezwaar tegen het principe van client side encryption want dat is goed. Ik vraag me alleen af hoezeer het echt onafhankelijk van Google is. Waar het echt om gaat is niet de vraag wiens apparaat de encryptie doet maar wie er de mogelijkheid heeft om mee te kijken en/of de encryptie uit te schakelen of te omzeilen.

[Verwijderd]

1. Werkt dit ook buiten het Google ecosysteem of werkt het alleen voor gmail-gebruikers onderling?
Nee, dit werkt niet buiten het ecosysteem (en ook niet onderling). Dit is (browser) client encryptie voor data die opgeslagen wordt bij Google. De key zit bij de cliënt en Google kan de data verder niet inzien. Dit was al een tijdje mogelijk, zie hier een voorbeeld als je bijvoorbeeld een sleutel manager gebruikt bij Thales:
https://cpl.thalesgroup.c...ce-client-side-encryption

Google's uitleg:
With client-side encryption (CSE), encryption and decryption also always occur on the source and destination devices, which in this case are the clients' browsers. However, with CSE, clients use encryption keys that are generated and stored in a cloud-based key management service, so you can control the keys and who has access to them. For example, you can revoke a user's access to keys, even if that user generated them. Also, with CSE, you can monitor users' encrypted files.
https://support.google.com/a/answer/10741897

2. Wie bouwt en implementeert "Client Side Encryption" en hoe komt die code op mijn computer?
Gezien er een browser client en server component is, Google. Ik denk dat je nog niet veel met Workspace gewerkt hebt? Maar alle componenten van Workspace draaien in de browser (met een aantal apps voor mobiel).

Ik ben een beetje bang dat het antwoord is dat het Google zelf is die de code schrijft en dat de code ook door Google wordt uitgeleverd via javascript (of door een hacker die zich voor Google uitgeeft). Dat betekent dat die code op ieder moment vervangen kan worden door andere code die niet veilig is.
Tja, iemand moet het schrijven? Het is een commercieel product dus niemand anders gaat het voor ze doen. Verder is het niet echt belangrijk of de code veilig is? Zodra je data download naar je computer wordt het weer ontsleuteld. Dat zal dus meer een doelwit zijn voor mensen die data willen stelen?

Ik vraag me alleen af hoezeer het echt onafhankelijk van Google is. Waar het echt om gaat is niet de vraag wiens apparaat de encryptie doet maar wie er de mogelijkheid heeft om mee te kijken en/of de encryptie uit te schakelen of te omzeilen.

Zoals aangegeven is een 'Enterprise' feature van Google Workspace (de werkplek van Google). De doelstelling is dat alle data van de klant volledig versleuteld en onleesbaar is. Klanten kunnen zelf hun Key Management doen om zo zelf de sleutels in eigen handen te houden. Vrijwel alle data is dan ontoegankelijk en onherstelbaar mocht er iets gebeuren met de KMS vandaar dat het niet zomaar iets is om te gebruiken. Een beheerder zal dit ook enkel inschakelen voor gebruikers die dit echt nodig hebben (zoals journalisten).

[CAPSLOCK2000]

Nee, dit werkt niet buiten het ecosysteem (en ook niet onderling).

Niet erg handig voor een communicatiesysteem. Dat maakt het wat mij betreft volkomen ongeschikt. E-mail moet niet gebonden worden aan één leverancier, het is het zo'n beetje enige communicatiemiddel dat we hebben waar iedereen met iedereen mag communiceren.

Dit is (browser) client encryptie voor data die opgeslagen wordt bij Google. De key zit bij de cliënt en Google kan de data verder niet inzien.

Hoe weet ik dat dat de key op de client blijft? Wat houdt Google tegen om een kopie te maken? Hoe weet je zeker dat ze netjes een keymanager gebruiken en niet zelf een kopietje van de key maken? Nu of in de toekomst?

However, with CSE, clients use encryption keys that are generated and stored in a cloud-based key management service, so you can control the keys and who has access to them. For example, you can revoke a user's access to keys, even if that user generated them.

Dit maakt duidelijk dat de gebruiker niet de baas is over de eigen keys. De keys zijn "cloud based" (aka "staan op iemand anders z'n computer") en de beheerder kan toegang tot die keys geven en ontnemen.

2. Wie bouwt en implementeert "Client Side Encryption" en hoe komt die code op mijn computer?
Gezien er een browser client en server component is, Google. Ik denk dat je nog niet veel met Workspace gewerkt hebt? Maar alle componenten van Workspace draaien in de browser (met een aantal apps voor mobiel).

Ik weet dat Google vooral via de browser werkt, vandaar mijn vraag, want zo beheerst Google de hele stack.

Tja, iemand moet het schrijven?

Net zoals dat iemand de sleutel van de gevangenis moet bewaken en iemand recht moet spreken, maar dat laat je typisch niet doen door direct betrokkenen.

Het is een commercieel product dus niemand anders gaat het voor ze doen.

Ze hadden het met anderen samen kunnen doen in plaats van alleen, zo'n beetje iedere leverancier van e-mail zou geinteresseerd zijn. Of ze zouden het onder een vrije licentie uit kunnen brengen zodat anderen het zelf kunnen bouwen en implementeren.

Verder is het niet echt belangrijk of de code veilig is? Zodra je data download naar je computer wordt het weer ontsleuteld. Dat zal dus meer een doelwit zijn voor mensen die data willen stelen?

Ik snap je niet. Je probeert vast niet echt te zeggen dat het niet belangrijk is of encryptie veilig is.

De doelstelling is dat alle data van de klant volledig versleuteld en onleesbaar is. Klanten kunnen zelf hun Key Management doen om zo zelf de sleutels in eigen handen te houden.

Dat kan Google wel zeggen maar hoe kan ik dat controleren?

Vrijwel alle data is dan ontoegankelijk en onherstelbaar mocht er iets gebeuren met de KMS vandaar dat het niet zomaar iets is om te gebruiken. Een beheerder zal dit ook enkel inschakelen voor gebruikers die dit echt nodig hebben (zoals journalisten).

Dat geldt voor álle encryptie. Sleutel weg = data weg. Toch is tegenwoordig het advies om al je schijven te versleutelen, ook thuis. Wachten met encryptie tot je denkt dat je het nodig hebt is de verkeerde aanpak, dan zou het wel eens te laat kunnen zijn.
Maar daar gaat het mij niet om. Ik heb nog niks gelezen dat mij het vertrouwen geeft dat Google (of de overheid) niet bij je data kan wanneer ze dat willen. Ze beheersen de hele stack van voor tot onderen. De enige die het werk van Google controleert is Google zelf. Dat is fundamenteel een slecht idee, of je Google nu vertrouwt of niet.

Lees dit aub niet als anti-Google rant. Het is een rant tegen ontransparante mono-cultuur waardoor de hele software stack in de handen van een enkele partij komen. Ik heb precies hetzelfde probleem met MS en Apple.
Het is allemaal te belangrijk om blind te vertrouwen op de goede wil van een enkel bedrijf. We moeten kunnen controleren of software en encryptie veilig zijn en blijven. Dat gaat niet als alle onderdelen die elkaar zouden kunnen controleren in dezelfde handen zijn.

[Verwijderd]

Niet erg handig voor een communicatiesysteem. Dat maakt het wat mij betreft volkomen ongeschikt. E-mail moet niet gebonden worden aan één leverancier,
Ik denk dat je een beetje op de verkeerde gedachtegang zit. Dit 'doet' niets met emailcommunicatie... Het gaat hier enkel om hoe de data (in dit geval Gmail) is opgeslagen bij Google zelf:

You can use your own encryption keys to encrypt your organization's data, in addition to using the default encryption that Google Workspace provides. With Google Workspace Client-side encryption (CSE), content encryption is handled in the client's browser before any data is transmitted or stored in Google's cloud-based storage. That way, Google servers can't access your encryption keys and decrypt your data.

In principe is dit bijna hetzelfde als waar Apple nu mee bezig is (volledige End-to-End encryptie) alleen dan geintegreerd in de applicatie (Docs, Sheets, Drive, etc).

Hoe weet ik dat dat de key op de client blijft? Wat houdt Google tegen om een kopie te maken? Hoe weet je zeker dat ze netjes een keymanager gebruiken en niet zelf een kopietje van de key maken? Nu of in de toekomst?
Niet houdt Google tegen anders dan hun toekomst binnen commerciële instellingen. De organisaties die hier geïnteresseerd in zijn zullen dit auditen (en er zullen vast ook externe audits plaatsvinden). Er is niet echt een reden voor Google om hierin te liegen gezien het punt dat ze dit helemaal niet hoeven te doen en het een commercieel product is. Als er niet geleverd wordt waar men voor betaald, dan heeft Google ook een enorm juridisch probleem.

Dit maakt duidelijk dat de gebruiker niet de baas is over de eigen keys. De keys zijn "cloud based" (aka "staan op iemand anders z'n computer") en de beheerder kan toegang tot die keys geven en ontnemen.
Er zijn verschillende systemen. De meeste organisaties zullen kiezen voor cloud-based, zo'n infrastructuur is niet immers goedkoop of eenvoudig te onderhouden en je wilt ook centrale keymanagement zodat beheerders bijvoorbeeld ook recovery zaken kunnen uitvoeren en backups kunnen maken.
Als je zo'n oplossing gaat implementeren dan laat je Google deze keymanagement niet doen maar vertrouw je over het algemeen op een partner (zoals Thales) of je draait je eigen:

Can I use Google as my key management service?
No, you'll need to use an external key management service to set up Google Workspace Client-side encryption. With CSE, you control your own encryption keys, and Google can't access them to decrypt your data.

Ik weet dat Google vooral via de browser werkt, vandaar mijn vraag, want zo beheerst Google de hele stack.
Google werkt inderdaad exclusief via de browser (bij normaal gebruik van Google Workspace) en al je data staat bij Google. Als je kiest voor Google Workspace dan wordt alles al versleuteld en beheerd door Google. Dit is bij Microsoft (Office 365) of een andere cloud dienst niet anders. Met deze optie kun je er een extra encryptie laag eroverheen zetten met je eigen sleutels beheer. Hierdoor garandeer je dat de data niet meer gelezen kan worden door Google (naast hun eigen belofte).
Je data staat dus onleesbaar bij Google en wordt door de browser opgevraagd en ontsleuteld op jouw lokale machine. Key management wordt door een externe partij afgehandeld.

Ze hadden het met anderen samen kunnen doen in plaats van alleen, zo'n beetje iedere leverancier van e-mail zou geinteresseerd zijn. Of ze zouden het onder een vrije licentie uit kunnen brengen zodat anderen het zelf kunnen bouwen en implementeren.
Daar ben ik het wel mee eens maar tevens denk ik niet dat er hier echt al standaarden voor bestaan.
Verder laten ze het keymanagement juist enkel aan partners over dus doen ze dus wat je wil? De boel verloopt in iedergeval via een open REST API.

Ik snap je niet. Je probeert vast niet echt te zeggen dat het niet belangrijk is of encryptie veilig is.
Nee, inderdaad. Ik bedoel te stellen dat deze functie niet echt relevant is voor andere 'criminelen'. Dit is echt bedoelt als 'Ik kies Google als leverancier maar wil een extra garantie dat Google (of mogelijk, een of andere overheid) niet inhoudelijk mijn data kan lezen of exporteren.

Dat kan Google wel zeggen maar hoe kan ik dat controleren?
Uiteindelijk is het altijd een kwestie van vertrouwen. Je gaat niet de boel bij Google neerzetten als je ze niet vertrouwt dat ze je data veilig houden. Deze optie zorgt ervoor dat je daarbovenop nog wat extra garanties afdwingt. Ik verwacht dat deze zaken (zodra volledig ontwikkeld, dit is beta voor gmail) onafhankelijk geaudit wordt. Het zou ook niet moeilijk moeten zijn om te detecteren dat de data versleuteld afgeleverd worden en ontsleuteld met een 'jouw' sleutel. Maar zoals gezegd is dit een 'dure' enterprise feature waar je voor betaald. En als die niet werkt zoals belooft klagen ze, alleen al in de verenigde staten, Google aan.

Lees dit aub niet als anti-Google rant. Het is een rant tegen ontransparante mono-cultuur waardoor de hele software stack in de handen van een enkele partij komen. Ik heb precies hetzelfde probleem met MS en Apple.
Zo lees ik het ook niet hoor en ik sta er zelf net zo sceptisch in. Ik ben echter voornamelijk geïnteresseerd in techniek en hoe dit dan zou kunnen werken.

Persoonlijk vind ik het een goede stap om de gebruiker weer eigenaar te laten zijn van zijn/haar data. Er zitten echter ook veel haken en ogen aan zoals hoe je omgaat met gedeelde data en metadata. Daar zijn momenteel nog geen oplossingen voor (anders dan beloften van Google). Dus een kleine maar goede stap, hopelijk volgen er meer.

TLDR:
Het is allemaal te belangrijk om blind te vertrouwen op de goede wil van een enkel bedrijf.
En dat is dus juist waar dit hele gebeuren voor bedoelt is. Google doet je applicaties / data en een externe partij van je kiezen (of jezelf) doet het sleutelbeheer om de data te kunnen ontcijferen.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 04:58]

[CAPSLOCK2000]

Niet erg handig voor een communicatiesysteem. Dat maakt het wat mij betreft volkomen ongeschikt. E-mail moet niet gebonden worden aan één leverancier,
Ik denk dat je een beetje op de verkeerde gedachtegang zit. Dit 'doet' niets met emailcommunicatie... Het gaat hier enkel om hoe de data (in dit geval Gmail) is opgeslagen bij Google zelf:

Teleurstellend.

With Google Workspace Client-side encryption (CSE), content encryption is handled in the client's browser
before any data is transmitted or stored in Google's cloud-based storage. That way, Google servers can't access your encryption keys and decrypt your data.[/i]

Dat zeggen ze wel en misschien is het wel zo maar het kan morgen anders zijn. Google beheert zelf de updater die het kan veranderen.

Hoe weet ik dat dat de key op de client blijft? Wat houdt Google tegen om een kopie te maken? Hoe weet je zeker dat ze netjes een keymanager gebruiken en niet zelf een kopietje van de key maken? Nu of in de toekomst?
Niet houdt Google tegen anders dan hun toekomst binnen commerciële instellingen.

Aangezien de concurrentie grotendeels van de markt gevaagd is vind ik dat geen sterke garantie.

De organisaties die hier geïnteresseerd in zijn zullen dit auditen (en er zullen vast ook externe audits plaatsvinden).

Hier moet ik hard protesteren. Iedereen denkt dat "de anderen" het wel doen. Dat is niet zo. Niemand controleert het zelf want dat kan niet. Je krijgt de broncode niet te zien, je mag niet in het datacenter, etc...
Er wordt inderdaad overal flink op losgeaudit maar het is een misverstand om te denken dat het iets zegt over kwaliteit of veiligheid. Audits gaan vrijwel allemaal over organisatorische aspecten en beleid. Op papier kan het allemaal perfect geregeld zijn maar niemand gaat controleren of de deur ook echt op slot is, zoals op papier staat (daar heb je een pentest voor nodig).
Als klant/gebruiker krijg je ook geen enkel inzicht. Als je er om vraagt kun je een stuk papier krijgen waarop staat dat ze "voldoen" zonder dat je maar enige idee hebt wat er gecontroleerd is en of dat voldoende is.

(Mensen denken soms dat ik tegen audits ben maar dat is niet zo. Ik ben tegen het idee dat een audit doorstaan genoeg is om een veilig product te levereren).

Er is niet echt een reden voor Google om hierin te liegen gezien het punt dat ze dit helemaal niet hoeven te doen en het een commercieel product is. Als er niet geleverd wordt waar men voor betaald, dan heeft Google ook een enorm juridisch probleem.

Dat klopt maar houdt geen rekening met spionage of dictators die een bedrijf in het geheim dingen kunnen laten doen die niemand wil. Of natuurlijk gewone menselijke vergissingen.

Het gaat me er niet om of Google een goed of slecht bedrijf is maar dat geen goed ontwerp is om alle security in dezelfde handen te leggen. Het is beter om gescheiden organisaties te hebben zodat een problemen bij de een kunnen worden opgevangen of afgedekt door een ander.
Blind vertrouwen is mooi, maar harde grenzen zijn beter.

Can I use Google as my key management service?
No, you'll need to use an external key management service to set up Google Workspace Client-side encryption. With CSE, you control your own encryption keys, and Google can't access them to decrypt your data.

Dat kan ik waarderen, goede informatie die ik op andere plekken mis. Tnx.

Als je kiest voor Google Workspace dan wordt alles al versleuteld en beheerd door Google. Dit is bij Microsoft (Office 365) of een andere cloud dienst niet anders.

Ik ben niet anti-Google. Dat MS het ook doet maakt geen verschil. Dat bedrijf heeft precies hetzelfde probleem.

Je data staat dus onleesbaar bij Google en wordt door de browser opgevraagd en ontsleuteld op jouw lokale machine. Key management wordt door een externe partij afgehandeld.

Dat klinkt goed tot je beseft dat het OS ook door Google geschreven is (als je Android gebruikt). Het hele systeem kan prachtig werken maar op enig moment staat de data toch onversleuteld op je HD en kan Android die lezen. Ook op Windows is het niet genoeg als je een door Google geschreven webbrowser gebruikt. Want het is die browser die data naar de encryptie-laag toestuurt en de ontsleutelde data weergeeft op het scherm. De browser kan op dat moment alsnog een kopie maken van die data en doorsturen.
Ik probeer niet te suggereren dat dit echt gebeurt. Het gaat mij er om dat het ontwerp niet goed is.

Daar ben ik het wel mee eens maar tevens denk ik niet dat er hier echt al standaarden voor bestaan.
Verder laten ze het keymanagement juist enkel aan partners over dus doen ze dus wat je wil? De boel verloopt in iedergeval via een open REST API.

Dat helpt inderdaad heel veel, tnx.

Ik snap je niet. Je probeert vast niet echt te zeggen dat het niet belangrijk is of encryptie veilig is.
Nee, inderdaad. Ik bedoel te stellen dat deze functie niet echt relevant is voor andere 'criminelen'. Dit is echt bedoelt als 'Ik kies Google als leverancier maar wil een extra garantie dat Google (of mogelijk, een of andere overheid) niet inhoudelijk mijn data kan lezen of exporteren.

Ik wil het liefst systemen waarin die vraag niet eens hoeft te bestaan.

Dat kan Google wel zeggen maar hoe kan ik dat controleren?
Uiteindelijk is het altijd een kwestie van vertrouwen. Je gaat niet de boel bij Google neerzetten als je ze niet vertrouwt dat ze je data veilig houden.

Zo zou het moeten werken maar dat is niet de praktijk. De praktijk is dat je niet om Google en MS heen kan in deze wereld. Vrijwel iedere organisatie in de wereld zit bij een van die twee, of allebij. Je kan haast niet anders.

Deze optie zorgt ervoor dat je daarbovenop nog wat extra garanties afdwingt. Ik verwacht dat deze zaken (zodra volledig ontwikkeld, dit is beta voor gmail) onafhankelijk geaudit wordt.

Vast, maar de uitkomsten zijn geheim. Als je er om vraagt mag je na het tekenen van een geheimhoudingsverklaring de samenvatting zien. Zo'n samenvatting bevat nooit concrete informatie maar hooguit "we hebben 2 high en 4 medium fouten gevonden en die zijn opgelost".

Persoonlijk vind ik het een goede stap om de gebruiker weer eigenaar te laten zijn van zijn/haar data. Er zitten echter ook veel haken en ogen aan zoals hoe je omgaat met gedeelde data en metadata. Daar zijn momenteel nog geen oplossingen voor (anders dan beloften van Google). Dus een kleine maar goede stap, hopelijk volgen er meer.

Eens

Het is allemaal te belangrijk om blind te vertrouwen op de goede wil van een enkel bedrijf.
En dat is dus juist waar dit hele gebeuren voor bedoelt is. Google doet je applicaties / data en een externe partij van je kiezen (of jezelf) doet het sleutelbeheer om de data te kunnen ontcijferen.

Ik ben niet tegen hoor maar het is niet voldoende. Ik bedoel het niet als verwijt aan Google dat ze het beste van de situatie proberen te maken waarin ze zo'n beetje de hele stack onder controle hebben (ik kan ze wel verwijten dat ze die situatie op oneerlijke wijze hebben verkregen maar dat is een andere discussie).

[Verwijderd]

Dat zeggen ze wel en misschien is het wel zo maar het kan morgen anders zijn. Google beheert zelf de updater die het kan veranderen.
Euum, ja Google kan het veranderen en updaten. Maar dit is iets waar ze al jaren mee bezig zijn dus ik denk niet dat ze zomaar hier iets in veranderen... We praten hier niet over consumentensoftware...

Aangezien de concurrentie grotendeels van de markt gevaagd is vind ik dat geen sterke garantie.
Hoe bedoel je 'gevaagd'? En wie is die concurrentie dan? Je hebt leveranciers voor Azure, AWS en GCP. Concurrentie genoeg? Je kan je eigen aanbieder kiezen...

Als je er om vraagt kun je een stuk papier krijgen waarop staat dat ze "voldoen" zonder dat je maar enige idee hebt wat er gecontroleerd is en of dat voldoende is.
Ik denk dat je niet helemaal begrijpt hoe audits dan werken? Je kan prima vragen hoe zaken zijn vastgesteld bij audits? En ik kijk uit naar een oplossing hoe je het wil doen zonder audits? Dus wat zie jij dan als alternatief?

Dat klopt maar houdt geen rekening met spionage of dictators die een bedrijf in het geheim dingen kunnen laten doen die niemand wil. Of natuurlijk gewone menselijke vergissingen.
Het gaat me er niet om of Google een goed of slecht bedrijf is maar dat geen goed ontwerp is om alle security in dezelfde handen te leggen.
Tja, dat is discutabel (met goede argumenten voor en tegen). Ik zie zelf heel veel fragmentatie in IT en daar komen juist de problemen uit (Viel dat er ook onder? Wat doet die server eigenlijk? Valt niet onder mijn beheer!). Dat en kennisgebrek van de vele complexe IT die we tegenwoordig voeren. Ik kan oude (on-premise) IT niet eens uitleggen aan de jonge IT-ers. Die geloven mij soms niet eens als ik bijvoorbeeld vertel dat Windows standaard niet versleuteld is.... Ik ben ze helemaal kwijt als ik uitleg wat een Domain Controller is. Dan vragen ze waarom dat dan een server moet zijn.. En dan heb ik eigenlijk ook geen goed antwoord...

Ik probeer niet te suggereren dat dit echt gebeurt. Het gaat mij er om dat het ontwerp niet goed is.
Dat komt omdat je niet het gehele plaatje ziet. Dit is onderdeel van Google Workspace en als je wilt, kan je alle downloads zo uitschakelen. Alle data zit dan enkel nog in je browser. MDM is inbegrepen dus versleuteling afdwingen op client apparaten is ook simpel in te stellen.
Dit hele ding is simpelweg een tandwiel in het gehele systeem genaamd Google Workspace.

Ik wil het liefst systemen waarin die vraag niet eens hoeft te bestaan.
Ik ook maar in Europa is simpelweg geen innovatie en/of alternatief. En dan nog, zul je de vraag alsnog moeten stellen. Als ik zie hoe het in lokale datacenters er aan toe gaat.... En dan ook nog voor een veel hogere prijs...

De praktijk is dat je niet om Google en MS heen kan in deze wereld. Vrijwel iedere organisatie in de wereld zit bij een van die twee, of allebij. Je kan haast niet anders.
Yep, dat klopt. Daarom is regelgeving ook zo belangrijk. Maar ik moet er ook bijzeggen dat beide spelers er ook heftig op inspringen en echt wel willen voldoen aan de afspraken. Meer zelfs dan onze overheid met de data omgaat...

Vast, maar de uitkomsten zijn geheim. Als je er om vraagt mag je na het tekenen van een geheimhoudingsverklaring de samenvatting zien.
Tja, zo werkt het nu eenmaal en daarom heb je dus externe audits. Je moet simpelweg wel ergens in vertrouwen, of het nu de leverancier van te installeren software is of software die ergens anders draait. De vraag van vertrouwen zal nooit weg gaan. Ook niet met open-source waar ik zelf een groot fan van ben.

Ik ben niet tegen hoor maar het is niet voldoende. Ik bedoel het niet als verwijt aan Google dat ze het beste van de situatie proberen te maken waarin ze zo'n beetje de hele stack onder controle hebben
We willen allemaal veel beter maar als je de IT puinhopen ziet van bedrijven is het juist een hele grote verbetering, hoe jammer dat ook klinkt. De meeste on-premise IT kan tegenwoordig gewoon helemaal niet meer meekomen en wanneer de crypto malware toeslaat, is men het ook helemaal zat... Ik help met beheer van diverse Google Workspace omgevingen maar ook Microsoft omgeving. In de 3 jaar dat ik met Google Workspace werk hebben we nog niet 1 incident gehad. Probeer maar een virus te draaien op een chromebook... Laptop in de trein laten liggen? Geen probleem, stond toch geen data op... ga zo maar door. En we praten hier over 10K+ gebruikers....

Dat kan ik niet nabootsen in de Microsoft omgevingen.... Dus ja, ik zie het voordeel er wel van in...
Ik snap echter ook jouw instelling heel goed. Ik was niet minder sceptisch en zou nog steeds graag alternatieven willen zien van europese bodem. Maar die zijn er niet en we moeten wel verder. En deze platformen zijn zo veel beter en veiliger dan ik ooit heb gezien bij een on-premise omgeving...

[CAPSLOCK2000]

Dat zeggen ze wel en misschien is het wel zo maar het kan morgen anders zijn. Google beheert zelf de updater die het kan veranderen.
Euum, ja Google kan het veranderen en updaten. Maar dit is iets waar ze al jaren mee bezig zijn dus ik denk niet dat ze zomaar hier iets in veranderen... We praten hier niet over consumentensoftware...

Dat is voor mij dus fundamenteel.

Aangezien de concurrentie grotendeels van de markt gevaagd is vind ik dat geen sterke garantie.
Hoe bedoel je 'gevaagd'? En wie is die concurrentie dan? Je hebt leveranciers voor Azure, AWS en GCP. Concurrentie genoeg? Je kan je eigen aanbieder kiezen...

AWS doet geen e-mail en GCP is ook Google zelf. Dat is geen concurrentie.

Als je er om vraagt kun je een stuk papier krijgen waarop staat dat ze "voldoen" zonder dat je maar enige idee hebt wat er gecontroleerd is en of dat voldoende is.
Ik denk dat je niet helemaal begrijpt hoe audits dan werken? Je kan prima vragen hoe zaken zijn vastgesteld bij audits?

Dat kun je wel vragen maar je krijgt nooit een goed antwoord. Als je wel eerlijk antwoord krijgt is dat imho zeer teleurstellend "de beheerder heeft verklaar dat encryptie gebruikt wordt" of zo iets.

En ik kijk uit naar een oplossing hoe je het wil doen zonder audits? Dus wat zie jij dan als alternatief?

Ik wil niet zonder audits. Audits zijn nuttige en belangrijk maar het is niet genoeg.
1. Ik wil direct inzicht in de resultaten en methodes van een audit. Niet alleen de management summary waar nooit meer in staat dan "alles is goed".
2. Ik wil dat er een penetration test wordt gedaan waarbij actief wordt onderzocht hoe systemen in praktijk werken.

Dat klopt maar houdt geen rekening met spionage of dictators die een bedrijf in het geheim dingen kunnen laten doen die niemand wil. Of natuurlijk gewone menselijke vergissingen.
Het gaat me er niet om of Google een goed of slecht bedrijf is maar dat geen goed ontwerp is om alle security in dezelfde handen te leggen.
Tja, dat is discutabel (met goede argumenten voor en tegen). Ik zie zelf heel veel fragmentatie in IT en daar komen juist de problemen uit (Viel dat er ook onder? Wat doet die server eigenlijk? Valt niet onder mijn beheer!). Dat en kennisgebrek van de vele complexe IT die we tegenwoordig voeren.

Dat zijn geen fundamentele problemen, die zijn oplosbaar door je beter te organiseren, betere afspraken te maken, beter personeel in te huren, meer opleiding te doen, etc.
Het is makkelijk en dus begrijpelijk om de situatie te vereenvoudigen met een monocultuur maar zo'n monocultuur brengt z'n eigen risico's en nadelen met zich mee (zoals dat een enkele fout je hele omgeving kan plat leggen omdat alle systemen hetzelfde zijn). Naast die problemen krijg je ook nog het risico van vendor-lockin er bij.

Ik probeer niet te suggereren dat dit echt gebeurt. Het gaat mij er om dat het ontwerp niet goed is.
Dat komt omdat je niet het gehele plaatje ziet. Dit is onderdeel van Google Workspace en als je wilt, kan je alle downloads zo uitschakelen. Alle data zit dan enkel nog in je browser. MDM is inbegrepen dus versleuteling afdwingen op client apparaten is ook simpel in te stellen.

Die browser wordt toch ook door Google gemaakt? Dat is mijn probleem. De aangebrachte scheidingen zijn op zich goed maar het heeft geen zin als de software aan beide kanten van de scheiding door dezelfde partij wordt geschreven en beheerd.

Ik wil het liefst systemen waarin die vraag niet eens hoeft te bestaan.
Ik ook maar in Europa is simpelweg geen innovatie en/of alternatief. En dan nog, zul je de vraag alsnog moeten stellen. Als ik zie hoe het in lokale datacenters er aan toe gaat.... En dan ook nog voor een veel hogere prijs...

Het is een kip-ei situatie maar de markt is nu een race naar de bodem aan het worden. Europese bedrijven kunnen niet concurreren met de Amerikaanse reuzen die een enorm schaalvoordeel hebben weten op te bouwen en het niet zo nauw nemen met Europese regels.

De praktijk is dat je niet om Google en MS heen kan in deze wereld. Vrijwel iedere organisatie in de wereld zit bij een van die twee, of allebij. Je kan haast niet anders.
Yep, dat klopt. Daarom is regelgeving ook zo belangrijk. Maar ik moet er ook bijzeggen dat beide spelers er ook heftig op inspringen en echt wel willen voldoen aan de afspraken. Meer zelfs dan onze overheid met de data omgaat...

Uit de onderzoeken die Privacy Company heeft gedaan in opdracht van onze overheid blijkt dat er toch nog wel het een en andere tekort schoot en schiet. Deze bedrijven hadden dat ook zelf kunnen onderzoeken maar om begrijpelijke redenen staan ze daar niet om te springen. Ze hebben het ook niet op zichzelf genomen om iets met de uitslagen te doen.

Vast, maar de uitkomsten zijn geheim. Als je er om vraagt mag je na het tekenen van een geheimhoudingsverklaring de samenvatting zien.
Tja, zo werkt het nu eenmaal en daarom heb je dus externe audits. Je moet simpelweg wel ergens in vertrouwen, of het nu de leverancier van te installeren software is of software die ergens anders draait. De vraag van vertrouwen zal nooit weg gaan. Ook niet met open-source waar ik zelf een groot fan van ben.

"Trust but verify". Vertrouwen is goed, blind vertrouwen niet. Blind vertrouwen is geloof.
Zoals eerder aangegeven ben ik niet tegen audits en controles, maar je moet ze niet gebruiken als rookgordijn en zo voelt het nu vaak wel. Er wordt heel geheimzinnig gedaan en als je doorvraagt blijkt dat ze aan de andere kant van de tafel eigenlijk ook niet weten wat de auditor nou precies gevraagd heeft en wat dat nu concreet betekent. Een goed begin is om te vragen wat er nu precies geaudit is. Meestal brengen bedrijven het namelijk als "we zijn geaudit" alsof daarmee ieder aspect van het hele bedrijf is doorgelicht. In praktijk zijn audits vaak nogal gericht op procedures, beleid en ander papierwerk. Heel mooi en nuttig maar niet genoeg.

De vraag van vertrouwen zal nooit weg gaan. Ook niet met open-source waar ik zelf een groot fan van ben.

Bij open source kun je veel verder gaan in zelf (laten) controleren in plaats van afhankelijk te zijn van de controles/audits die het bedrijf achter de software zelf laat doen. Want je weet gewoon dat de resultaten van een slechte audit niet gepubliceerd worden. Als ze denken dat ze niet door een audit heen komen dan zoeken ze wel een andere audit waar ze wel aan voldoen.

Ik ben niet tegen hoor maar het is niet voldoende. Ik bedoel het niet als verwijt aan Google dat ze het beste van de situatie proberen te maken waarin ze zo'n beetje de hele stack onder controle hebben
We willen allemaal veel beter maar als je de IT puinhopen ziet van bedrijven is het juist een hele grote verbetering, hoe jammer dat ook klinkt.

Dat hoor ik mijn hele leven al. IBM, Microsoft, Google. Allemaal beloven ze de wereld simpel te maken als je alles aan hun overgeeft. Bij iedere stap wordt het probleem groter omdat eigen kennis verdwijnt waardoor we steeds afhankelijker worden van een paar grote bedrijven. Ik bedoel daarmee niet dat je alles zelf of lokaal moet doen maar dat IT afnemen nog moeilijker is dan zelf iets installeren. Eigen kennis en inzicht is enorm belangrijker. Als je die niet hebt kun je geen IT inkopen zonder in de problemen te komen. Eenmaal in de problemen kan alleen de leverancier helpen.
Sorry voor de rant, mijn punt is dat monocultuur geen oplossing is voor gebrek aan kennis. Monocultuur is het probleem verplaatsen en verbergen en gebrek aan kennis komt later terug om je te bijten. Het is het ene gat vullen met het andere gat. Op korte termijn lijkt dat een goed idee maar op lange termijn is het dat niet.

Het is nogal out-of-context, maar ik moet denken aan het veel misbruikte citaat "They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.". In dat licht zie ik het vertrouwen op Google/MS/techreus als tijdelijke veiligheid. Fijn voor de korte termijn maar problematisch op lange termijn.

De meeste on-premise IT kan tegenwoordig gewoon helemaal niet meer meekomen en wanneer de crypto malware toeslaat, is men het ook helemaal zat... Ik help met beheer van diverse Google Workspace omgevingen maar ook Microsoft omgeving. In de 3 jaar dat ik met Google Workspace werk hebben we nog niet 1 incident gehad. Probeer maar een virus te draaien op een chromebook... Laptop in de trein laten liggen? Geen probleem, stond toch geen data op... ga zo maar door. En we praten hier over 10K+ gebruikers....

Alle goede kanten die daar aan zitten ten spijt vind ik het probleem van monocultuur, afhankelijke en vendor-lockin groter en fundamenteler.

Dat kan ik niet nabootsen in de Microsoft omgevingen.... Dus ja, ik zie het voordeel er wel van in...

Ik ben niet echt een MS expert maar de dingen die je hierboven noemt kunnen ook met MS, denk ik. Maar dat is een heel andere discussie. Alles MS is net zo onwenselijk als alles Google, dat is lood om oud ijzer.

En deze platformen zijn zo veel beter en veiliger dan ik ooit heb gezien bij een on-premise omgeving...

Vast, maar voor echte veiligheid moet je er ook verstandig mee om gaan. Ieder veilig syteem kan onveilig worden gemaakt door slecht beheer. Goede beheerders hebben inzicht, informatie en gereedschap nodig. Ik heb te vaak gezien dat een lokaal IT-systeem wordt vervangen door iets externs omdat het beter en goedkoper zou zijn. Vervolgens blijkt het echter geen totaalprijs te zijn omdat je nog steeds zelf mensen nodig hebt om het goed in te stellen, maar die zijn net wegbezuinigd want niet meer nodig met de nieuwe software. De softare blijft dus in de default configuratie draaien en af en toe wordt een IT'er onder druk gezet om ergens een instelling te veranderen terwijl de IT-afdeling eigenlijk niet weet wat de gevolgen zijn waardoor er allerlei gaten ontstaan. De leverancier komt niet verder dan "eigen verantwoordelijkheid om onze best practices te volgen, dat stond in het contract". Maar ja, dat contract heeft niemand echt gelezen want IT'ers houden niet van contracten en juristen snappen niks van IT.

[Reactie gewijzigd door CAPSLOCK2000 op 25 juli 2024 04:58]

[Sebazzz]

Ik neem aan dat de spamfilter dan ook enkel en alleen nog maar op de bronaddressen werkt, en niet meer op inhoud - of dat de spamfilter nog vóór de versleutelde opslag wordt gedaan.

[lenwar]

Dat is inkomende e-mail van buitenaf. Die is 'uiteraard' niet versleuteld. Tenzij de interne medewerkers/scholieren natuurlijk spam aan het versturen zijn naar collega's/schoolgenoten ;-), maar dat lijkt me nou typisch niet gangbaar.

Dit gaat echt om een centraal beheerde versleuteling. De 'mailbeheerder' kan sleutels genereren, toekennen, weigeren enzovoorts. (de beheerder kan dus kiezen wie er versleutelde berichten kan versturen en ontvangen en waarschijnlijk ook nog van wie naar wie binnen de organisatie. Zo kan het bijvoorbeeld zijn dat de directie onderling en de marketingmensen het wel kunnen, maar de helpdeskmedewerkers en de catering bijvoorbeeld niet. Ik noem maar een zijstraat natuurlijk)

[ocf81]

Voor Enterprise-gebruikers komt de functie er voorlopig dus niet, evenmin als voor particuliere gebruikers van Workspace. Ook reguliere gebruikers van de gratis maildienst krijgen de optie voorlopig niet.

Daar valt wel omheen te werken, mits je een mailclient voor de desktop gebruikt. Dat is sowieso wel een goed idee. Dan heb je een tevens een off-line kopie. (althans, bij de standaardinstellingen van thunderbird of vergelijkbare mailprogramma's)

[FrostyPeet]

Benieuwd hoe Gmail dat gaat regelen met archief. Soms moet je jaren terug nog kunnen zoeken naar een bepaalde e-mail. Als ze elke keer dezelfde sleutel gebruiken lijkt me dat onveilig. Wijzigen ze de sleutel bijvoorbeeld elk jaar, dan krijg je als gebruiker een reeks sleutels. Net als bijvoorbeeld Actalis, in mijn sleutelbeheer staan er ook een stel met een bepaalde looptijd.

Verder geen idee hoe goed de "kwaliteit" van hun sleutels zijn. Brakke randomgenerator? De eerste 64 bits van de 256 bits zijn altijd nul? Duplicaat sleutel maken (klantvriendelijke recovery)?

Verder blijf ik e-mail de meest onveilige manier vinden om gevoelige informatie te versturen. Geen flauw idee waar mijn e-mail allemaal doorheen gaat. Centraal of lokaal spamfilter, mailservers, online of lokale antivirus scanner, on- en offline backup of auto e-mail forwarders om wat voorbeelden te geven.

[dimdek]

Google heeft al lang door dat de meeste gebruikers wel de spellingscontrole aan hebben staan en ook graag suggusties zien in hun browser. Zo krijgen ze al veel eerder de informatie die ze graag verzamelen. Met deze test kunnen ze natuurlijk mooi vergelijken hoeveel gegevens ze zouden missen en of het verlies relevant is.