The enterprise transition to the cloud brought great things with it, including managed services you can use to save time and the ability to deliver software faster to production and to scale it more easily.
But as a wise comic-book character once said, “With great power comes great responsibility.” In the past, all that developers needed to care about was the code. Now they have to do a lot of other things that used to be the responsibility of others in IT—including security.
There are many things devs need to know about getting security right in the cloud, but here are five simple things any developer or DevOps engineer can do to make their cloud infrastructure and application more secure.
It’s the 80/20 rule: These five simple actions will help you mitigate most of the incidents that arise from misconfiguration.
1. Use groups to manage users and their privileges
Dev teams often have a team cloud account, and it feels like the right place to try out possible architectures or integrations with new services. Perhaps you feel that the team’s accounts pose no threats, or you feel uncomfortable about cutting privileges for some people, so you give everyone admin privileges.
Don’t do it. These accounts can cause a lot of damage. Instead, use groups and give each the option to provision or access only what’s needed. Create your groups based on usage and needs. And don’t hesitate to communicate this act to the rest of the team. It’s not that you don’t trust them; you just accept that at some point your company will be a victim, too.
2. Don’t use usernames, passwords, or tokens in your code
The good news is that there are lots of crawlers running around trying to find those credentials for you. The bad news is that the finder probably won’t let you know about it until it’s too late. If you intend to go to your code repository right now to delete those credentials, just don’t forget about the versioning, since those credentials will still exist in previous versions.
Go ahead and rotate any key and token you may have used in the code; you’ll be surprised to find valid tokens you did not know existed or that are still valid. Make sure you’re using authentication services and not the direct credentials.
3. Take advantage of a powerful IAM service
It’s one role to rule them all: Identity and access management (IAM) roles are the bread and butter of cloud security by enabling the connection among services, servers, and parties in the cloud. Each role has a set of permissions and is attached to a service.
Each should be crafted according to the needs of your application. Unfortunately, people usually use very broad and generic roles that are over-permissive, creating a wide attack surface.
This is what happened in the infamous CapitalOne hack. The solution is to take a minute while doing the design to figure out what permissions you need. Some people wait until the app’s deployed to production before tightening the configuration, but you really should do so by design.
If you want to do it in production, you can try free open-source tools such as Netflix’s repoKid. But you should always start with prevention rather than detection. Detection in production is your last line of defense. To leverage the power of IAM, you should push its design to the left and arrive to production when you’re already least-privileged.
4. Check the images you’re using
Everyone’s using open source code and Docker images. But very often these contain vulnerabilities. They can be exploited for lots of different things, including stealing data, running cryptominers, or allowing remote code execution. The best thing to do is have automation for vulnerability scanning, but that’s the easy part. Don’t forget to fix whatever the scanner found.
As an organization, you might also want to create golden images for different purposes. It’s a great thing to do, but remember two key things: First, the golden image must be accessible. If developers can’t get easy access that works well with their workflow, they won’t use it. Second, an image is just the starting point. You’ll experience drift from it, so make sure you can easily detect any crucial drifts.
5. Require multifactor authentication
This is not a misconfiguration, but there’s no reason why you shouldn’t activate it. Too many people—including developers—have lost their social media accounts, been locked out of their cloud account, or had their WhatsApp hijacked, just because they didn’t enable and use multifactor authentication. Yes, you need it in your cloud account, too. No, it doesn’t hurt. Just do it.
Learn the new art
Cloud security is not “remote IT security” but a new art that software developers, DevOps engineers, and security engineers need to master. Security is everyone’s job, and, to a certain extent, there is always something each of us can do to improve the entire security posture of the organization.
Security is a habit, but to make it such (if it isn’t already), start with these small steps. Create a calendar invite with yourselves, take one of the steps mentioned above, and make it a task. Within five weeks, you’ll be standing in a totally different place.
Want to know more? Come to my conference session at the DevOps World virtual conference, where I’ll speak on “Everything You Need to Know About App Security in the Cloud” as well as “How Empowering Your DevOps Teams Can Lead to Better Cloud Security.” The conference runs September 22-24, 2020.