Cloud native applications are built and deployed differently, what presents a number of challenges that require new approaches and tools to prevent data breaches. Let’s see some of them.
Applications used to be big blocks that were deployed every few months, but now they are composed by dozens of small services deployed frequently. These services should be in a separate network and only expose the endpoints needed via an API gateway like Apigee, IBM API Connect or WSO2, and ideally have separate layers of protection for the services consumed by the frontend/mobile apps and for the ones that access directly to the data. All the services should be protected using some standard mechanisms like OAuth2, what can be done by using specific libraries for each technology or centralised components that can be configured in the gateways and can be integrated with different authentication mechanisms like LDAP.
Many applications are deployed in a new way that doesn’t require having servers running them constantly, what reduces their maintenance costs as it is only paid per usage. Some people think that it is not needed to think about security for them as the PaaS provider would take care of it. However, it is easy to add vulnerabilities importing a tampered dependency, and some of them have hacks specially focused on getting unauthorised access of the user account. Also, because it is paid per usage, it is important to monitor these endpoints, set usage limits on them and to contract an insurance policy offered by the PaaS supplier as some hackers may hit them multiple times per second like on a DDoS attack until the account runs out of money.
Applications are deployed in containers that allow to scale them better and ensure they are deployed consistently on every environment. There are multiple tools like Snyk or Clair to check that the container images don’t have vulnerabilities. It should also be checked that the images are not configured to run with a root user and that Docker and Kubernetes are updated to the latest versions. If possible use a SaaS version of Kubernetes as it is production-ready.
Every month are announced data breaches from companies that stored a copy of their data in unprotected versions of ElasticSearch, MongoDB, etc. that were initially set up to allow to search data faster. It is important to set up the their security modules (what is free for some of them but require a license for others) and to ask an expert to ensure that the database is in a hardened server.
Both backend and frontend applications pull dozens of dependencies that may contain vulnerabilities known by hackers. It is important to update them frequently and run tools in the pipeline like OWASP Dependency Check or Snyk that check that they are secure, and there are tools like Jfrog Xray that can be integrated with the artifact repositories.
It takes some time and effort to keep dozens of microservices updated, what can be improved by centralising the versions of the dependencies in a parent project. There are also some tools like Maven plugins that highlight when some dependencies are not needed anymore as the code using them may have been removed.
Some developers store credentials such as unencrypted database passwords in the source code repository without thinking that it can be compromised. There are a number of solutions to store credentials encrypted separately such as Spring Cloud Config or Vault.
Incorrect security configuration
Many applications are vulnerable due to a bad configuration of e.g. the CORS headers. There are tools like Burp or OWASP ZAP that do automatic analysis and detect this and other vulnerabilities such as SQL injections, XSS, etc.
If you want to learn more about security and how to automate it, please continue reading this previous post about it.