HN2new | past | comments | ask | show | jobs | submitlogin

"if you're a multi-national trying to rollout Office 365" ...if you're competent, you already issue your own certificates for other purposes and install them on the computers you own. Therefore maintaining additional keys would not even cause adding more manpower than what you already have.

If you are multi-national and not having your own certificates, I'd be happy to do some consulting for you.



That's not the issue. The issue is that now you have to maintain a solution for key distribution across thousands of laptops, tablets, and phones. For some orgs it isn't too hard and can be part of their existing solutions (as you note), for others it is. Remember that a lot of the reason that orgs are using solutions like Office 365 is remote working, BYOD, and explicity not having to maintain all that supporting infrastructure (I don't disagree with you through, and best practice is often different from widely-used practice)

Owning your own encryption keys also has other issues: Do you issue per-user keys, or an org-wide key? If you issue per-user keys, how do you share documents between users? If you have an org-wide key that gets compromised, how quickly can you re-key every device and re-encrypt every document (how do you even detect that it's been compromised?)? If you encrypt using your own keys, how does that impact any processing that happens 'in the cloud' (eg. search indexing, batch processing)? Do you need to run encryption endpoints locally that users can access all the data through?

All of these problems are solvable. All of these problems can become a nightmare depending on your org, rollout, users, existing environment, etc.

I guess the point I'm making is that 'encrypt all the things' is rarely the {best,easiest,possible} way to do things.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: