Security in devops

The basics of security in devops

The Pwn2Own 2024 competition was recently held, and its results once again remind us of the main rule: there are almost no absolutely secure systems, especially when it comes to an application with several hundred thousand lines. Open source is far from a guarantee of reliability here.

Our job as devops engineers is to reduce the likelihood of breaches.

There are several rules for this:

• It's hard to break something there's no direct access to. The most reliable thing is to unplug the server from the network, but that's not always a good option. The rule: only what's necessary should be exposed to the outside. For example, if it's a website or a mobile app, you only need to open access to ports 80 and 443 for the browser and the app. All kinds of internal services should not only be closed off by a firewall but ideally sit entirely on an internal network.

• The backend and frontend should be designed so that known attack methods don't work, for example SQL injections and other injections. This isn't the devops team's job, but it's important to understand this attack vector.

• Denial of service or DDoS. This isn't about a breach but about the application going down under parasitic load, which is also pretty bad. A solution can be filtering traffic with your own tools or external ones, like cloudflare.

• Proper separation of access within the company: developers don't need (well, almost never) access to user data, so there's no reason to tempt them with it. If something needs to be changed in the database, let them write a migration that will be applied during CI/CD or via a special handler.

• Nothing that poses a security threat should be stored in git: passwords, keys, and so on. At startup, the application should reach out to Vault or an equivalent for all the credentials it needs to run.

So go ahead and ponder now whether absolutely secure systems exist.