In Part 2 of this series, I explained why I went about setting up my personal cloud server as the first step to freeing myself from dependence on Big Tech. The first comment on this was by Suhan Saha (this comment has apparently disappeared from Facebook now):
The biggest disadvantage of private cloud is IT-Security and DR. Btw, are you trying to build private cloud for storing data(e.g. dropbox) or SaaS(e.g. Gmail)?
This is a valid point. Big Tech is like the local bully whom you hate, but who does protect you from other bullies from neighbouring localities (because he does not want any competition in his bullying). Big Tech will monetize your data to the hilt, but it will protect your data from other people who might want to steal it. It is pretty good at keeping criminal gangs from grabbing your data. If you are a dissident in a relatively small and weak country, Big Tech might also give you some protection against your own government. If your country is large enough to be commercially very important to Big Tech’s business, then you should not count on this too much.
When you go for your own cloud, security becomes your own responsibility. You have one and only one friend – mathematics (encryption). Ideally, everything in the server should be encrypted. As Suha hints at in his comment, how easily you can do this (and whether you can do this at all) depends on what you are running on the server. At some point, I would be running pretty much everything there and so security is a major challenge that I will address while discussing each application. In this post, I give only a few general comments.
- I try to keep the attack surface as small as possible by running most things over one of two ports: the
httpsport for web based services, and
sshfor almost everything else. Port forwarding over
sshis a very powerful method of running lots of stuff without worrying too much about securing each of them.
- Another advantage of
sshis that I can use public key authentication so that the server does not know/store my password. Also, the private key has more entropy than any password that you can realistically use on a routine basis. Furthermore, each application can run as a separate user (potentially in a
chrootedjail) with its own public key, providing some degree of insulation between different applications.
- Some data on the server (
dropboxlike applications, for example) can be encrypted with symmetric keys because the server only receives content, it does not create or modify content. Encryption and decryption happen at the client. This is perhaps the most secure setup, but, in some situations, public key encryption is more convenient. For example, when content is shared between different people, it is easier to encrypt to multiple keys than to share the password.
Where the server creates or modifies content, it is necessary to use public key encryption. The protection here is not complete because while the data is encrypted at rest, it will be available in the clear during the processing. A good example is an email server set up so that incoming emails are automatically encrypted before being saved to the disk. If the server gets compromised, the hacker will not be able to read old mails, but would have access to mails that arrive while he has control of the machine.
The only material that can be left unencrypted on the server is stuff downloaded from the public web. By keeping it on the server in the clear, you risk giving the hacker some metadata (related to your browsing history), but no other information that he could not have got directly from the web.
Implementing all this security is hard work, but since this is a multi-year project, I do not have to do everything immediately. I hope that I will be able to accomplish most of my goals in due course unless Big Tech implodes much faster than I expect.