Cloud Security in a Crypto World

The cloud is great for scaling and hosting infrastructure for web sites, staking nodes and just about anything else often times cheaper and faster than buying your own hardware and managing it yourself. It does come with the threat of censorship now as we’ve seen in the past couple years, but there’s a reason most companies are hosted on some cloud somewhere, whether it’s AWS, Azure, Google Cloud, Digital Ocean or otherwise: it just works.

However, there’s a few fundamental principles in security that you must understand and apply to keep the platform from getting easily compromised, the data safe and everything fully functioning so you can provide value to your users. The principle of least privilege, economy of mechanism, fail-safe defaults, separate of privilege and others are key among others when building a system resistant to successful attacks.

Before we get into it, note that we’ll be using a lot of AWS terms, but there are similar services and accounts across cloud providers so this information is generally applicable to all, just the technical details may vary. There’s also lots of good design notes in this blog on building exchanges as well.

1) Never use the root account

Always create an IAM users and roles to separate privileges and run things with the principle of least privilege in mind. That way, if a compromise ever does occur, they only have access to the specific account which controls a few things and not the root account which controls everything.

2) Use proper S3 permissions

Unless you have a very good reason (eg. static web content or file downloads), ensure there are no buckets or objects with publicly or “authenticated users” (eg. anybody with an AWS account) permissions. Most companies get hacked due to leak keys or weak S3 permissions, so make sure you get them correct. Generally the permissions should be the least permissive as possible while still allowing your business logic to fully function. Encrypt S3 data where it makes sense as well.

3) Never hardcode credentials in your code

Make sure to leverage services such as KMS, Secrets Manager and STS if you need to run scripts or services that have to authenticate to perform acts. Do not just put the access key and secret key in your code, as anyone who can read the code, has access to the server, or God forbid can read the source code to the website where it’s stored can use those credentials to assume privileges of whatever was using them.

Access key = username and secret key = password and without 2FA or additional security enabled, anyone in the world can get access to your servers (ec2) or files (s3) if you leak them. Be sure to not store secrets in docker containers either as once you distribute them on Dockerhub or other registries, anybody can analyze the container and find the secrets.

4) Turn on MFA (2FA)

AWS supports multi-factor authentication in a variety of ways and this is the killer feature that often saves companies from getting compromised when their keys leak. There are ways to steal 2FA tokens as well, so it’s not bullet-proof, but its often the difference in an attack resulting in a compromise and an attack that failed or got stopped before it went further.

5) Use frameworks when possible

And keep them up to date. If you’re setting up something that many others have did before, like a website, blog or even exchange, try and reuse code that’s been tested many times over and is supported with updates. Writing new code is expensive and comes with a lot of responsibility, you may even need to write the security code yourself which is hard to get “right” and keep bugs away that allow users to bypass authentication or steal tokens, etc.

6) Manage container risks

Docker containers are amazing and a game changer for quickly spinning up isolated environments and microservices, but if you’re running or distributing them, you want to take a few precautions. If distributing them, make sure you don’t leave secrets such as AWS credentials or API keys on them as anyone can inspect everything on the container and eventually find them.

If running containers, especially on behalf of customers, ensure you have the configuration locked down to the least privileges, run as rootless if possible, don’t ever run privileged containers as they allow an easy breakout to the host OS and don’t expose docker daemon to the local network or other containers.

7) Sanitize input that goes to your backend

This is a dev thing, but if you’re passing data that users can type in to run commands or change configuration with settings or backend components, rethink doing that. Does the framework you’re using support doing that already or need a small modification? Or if you must write custom code to enable the feature, heavy scrutinize and sanitize all input from users, another service or coming anywhere from outside the server itself. Avoid using blacklists as they can be infinite or at best incomplete, use whitelists to validate there’s no way to inject malformed data into the query or process. For example, if you know the string you’re passing is always supposed to be numbers and letters, at least run it through a regex to only accept those characters and nothing else. Sometimes you need users to have input on how you interact with the Blockchain, generate new keys for run wallets on the backend, send/receive transactions and other things which bugs like race conditions and logic bugs can occur. Most security bugs come from the lack of input validation, even when you can thwart many attacks by simply doing the basics.

8) Use SSH keys, not passwords

When enabling remote access, SSH is a sysadmin’s bread and butter. That’s because if you want to work from your laptop and develop on a cloud box or do a big change to the backend server configuration, you often need to open a port on the firewall to get a secure shell. Always manage using SSH keys with passphrases and not just passwords alone as passwords can be guessed or stolen much easier than key files. If you enable ssh for remote access, use security groups to restrict access to only your and your developers known IP ranges and again keep ssh keys and associated passphrases safe.

9) Turn on AWS logging

Turn on bucket logging for S3 as well as CloudWatch and CloudTrail for logging and alerts on suspicious activity. You want to know as soon as a compromise occurs, not weeks later after all the data is gone.

10) Regularly test your security

Before launching the new service or website and after, you need experts to try and find security issues so you can fix them before somebody else exploits them. This means hiring companies or individuals who are experienced in identifying and fixing security problems and having them “try to break in” on a regular basis, so you can continue iterating on the platform without wondering if you’re accidentally introducing new bugs or otherwise weakening it’s security. There’s also developer tools that can help catch security related bugs by fuzzing the APIs or analyzing the code and pointing out potential issues like Burp and Gosec. Security audits can reveal bugs such as CSRF, XSS, RCE for code execution in a hundred different ways, authentication issues, secret storage problems and many others. They can test both your frontend and backend security, and if you’re not testing it, somebody else will and if they’re working for you, they’re going to be more helpful.

So those are the basics, but they can take you pretty far on your journey through building cool stuff that won’t get hacked easily. Fundamentally, if there’s a way for the developers to do or access something, there’s a way for an attacker to do so as well. That’s why so much focus has been put in recent years on multi-factor authentication, encryption, code signing, all these different ways to try and prove that the person or script that is performing an action is authenticated or authorized to do it. This can be achieved through various means of proving who you are (biometrics), what you know (passwords, secrets), where you are (geolocation), what you have (hardware key fobs or authenticator apps), etc. Now go and protect your data in the cloud!