Security in devops

Recently, the Pwn2Own 2024 competition took place, the results of which once again remind us of the main rule: absolutely secure systems almost do not exist, especially if we are talking about an application with several hundred thousand lines of code. Open source is far from a guarantee of reliability.

Our task as DevOps engineers is to reduce the likelihood of breaches.

To achieve this, there are several rules:

• It's problematic to break into something that doesn't have direct access. The safest option is to disconnect the server from the network, but this is not always a good option. Rule: only expose what is necessary. For example, if it's a website or a mobile application, then only open access to ports 80 and 443 for the browser and app. All kinds of service services should not only be closed by a firewall but ideally should sit entirely within the internal network.

• The backend and frontend should be designed in such a way that known hacking methods do not work, for example, SQL injections and other injections. This is not the task of DevOps, but understanding this attack vector is important.

• Denial of Service or DDOS. This is not about hacking but about the application crashing due to parasitic load, which is also undesirable. The solution can be traffic filtering by your own means or external ones, like Cloudflare.

• Proper access separation in the company: developers do not need (well, almost) access to user data, so there is no need to provoke them into it. If something needs to be changed in the database, let them write a migration that will be applied during the CI/CD process or through a special handler.

• Nothing that poses a security threat should be stored in git: passwords, keys, etc. The application should fetch all required credentials from a vault or equivalent at startup.

So, think about it: are there absolutely secure systems?