I’m going to ask what seems like a really basic question, but it’s not one I think I’ll get a clear answer from Google on. If you’re a company considering some form of cloud based email, storage or other services (e.g., database servers), what sort of protections are in place for your data? Not necessarily from third party hackers or criminals, but from the provider itself?
It doesn’t take much imagination to come up with a scenario where Microsoft or Google uses a company’s cloud data to take advantage. It doesn’t even have to be a decision at the institutional level. All it takes is a rogue sysadmin at the provider to access company XYZ’s data to conduct a little industrial espionage or insider trading.
I know some providers (Proton Mail comes to mind) claim that they encrypt client’s data in such a way that they can never access a client’s information. How transparent and verifiable are those claims? Do Google, Microsoft, et al offer this kind of encryption by default? Is it available as a “value added” service? If it is offered, is there any way to verify they’re telling the truth?
A million pardons if this topic is already widely known and discussed. It just seems kind of obvious, but I’m not sure how straight an answer I’d get from Google…
A little off-topic, but what about end-to-end email encryption? I know ProtonMail offers this (see below). Gmail offers a version of this, but in their case only encrypts the email as it transits between servers/providers. The final destination is still your Gmail Inbox, which Google has carte blanche access to.
And to the best of my knowledge, even with o365 and AD, you cannot enforce use of it.
So it depends. I dont know the inner workings of gmails offering, but protonmail basically provides a wrapper for GPG and s/mime.
Which is great as a stopgap, but it still exposes a lot of metadata. The subject line, for example, is not encrypted, nor are the sender/recipient addresses.
While these things are great, they need to be better.
Proton is ok. Can they be 100% trusted… don’t trust anyone 100% otherwise you will get burned.
If you want to actually have a separation between the private body and the service provider, then in the case of mail it is gpg. But this only makes sense if you and everyone you correspond with will always use gpg. Otherwise, the bare data will always lie with the service provider somewhere.
Modern solutions are still a hundred times better in terms of confidentiality than it was even 20 years ago.
The times of darkness and the terrible middle ages where there was no https, and unencrypted pop3 / smtp…
Communication on irc without encryption, ssh present but still telnet could be found. Hub-based lan networks pushing packets to all ports for sniffers a paradise on earth.
It would help if you also remembered for Proton Email to be as secure as it can be, all parties involved in the email must be members of Proton mail. So, for example, if John wants to send Aaron an encrypted email, both John and Aaron need to use Proton Mail. The email can’t be encrypted if either party doesn’t use Proton Mail. I hope that answers some of @imrazor questions.
@imrazor you’re curious about insider risk mitigation for Google Cloud services?
Internally any cloud service is composed from dozens of microservices.
Individuals who don’t work on a service have zero access to the service.
Individuals who do work on a service, don’t have “ambient” or “unilateral” access, if they happen to e.g. be an SRE and oncall at the time, there’s tooling they can use to repair the service and some of it require multi-party approvals. (i.e. you need a second person, and there’s special tooling, not generic SSH and do whatever access).
All data is encrypted at rest and in flight, libraries for crypto will generally overwrite cryptographic material in ram as soon as they’re done with it - just in case.
If you lookup the “macaroons” paper from 2014, the mechanisms described there are similar to the ones actually in use, i.e. microservices themselves generally need to provide context for what they’re doing on behalf of the user, and user data storage systems generally can’t read any data (it’s encrypted) without valid contextual attributing the action to a user request.
I can’t go into too much detail, but if you have a specific question in mind, ask.
