In a world where software is becoming increasingly important, the success of a company depends on how quickly services can be developed and rolled out. Therefore, the decisive factor today is how well a company understands its target group. Only this way can customer needs be better served and the company can be faster than its competitors. Of course, the security of the services offered must not be forgotten - all this calls for DevSecOps. In this blog post, we will show you how you can implement this in concrete terms.
In an increasingly digital and software-based world, the success of a company depends on how quickly (and securely) services can be developed and provided. We have shown you this in this blog post. DevOps plays an important element in this. DevOps stands for a culture of cross-functional and collaborative cooperation. What sounds so simple - is, however, a fundamental "mind shift", because traditionally development and operations have pursued different goals:
- Software development needs to be agile, creative and on the cutting edge of technology to constantly deliver new features.
- IT Operations, in contrast, is designed for stability, security and reliability.
DevOps combines this apparent contradiction between flexibility and stability. To achieve this, the entire value chain from software development to operations is to be combined in an interdisciplinary way. This breaks down silo thinking by bridging the gaps between silos and aligns the organisation towards the common goal of delivering new functionality quickly in stable, secure steps. In this article, we want to show you how this can be done.
From DevOps to DevSecOps - what's behind it?
But let's start at the very beginning. Traditionally, security was a gatekeeper at the end of software development, much like operations before DevOps. The "Sec" in "DevSecOps" makes the collaboration and shift in responsibility explicit. In a DevSecOps culture, every agile team has a security expert. He or she fulfils non-functional requirements (such as data classification and other parts of the risk analysis) so that the product owner also considers security in the development plan. This proactive approach allows teams to take overall responsibility for the scope of their services. Furthermore, when security is coupled asynchronously with product development, it allows the product owner to manage speed and security while sacrificing neither. Therefore, agile development also needs agile infrastructures and agile security.
The way software is protected against external and internal threats is evolving in response to the threat landscape we face. The latest step in this evolutionary chain is the move towards zero-trust architectures. The idea behind perimeter security architectures, as we know, is to separate an insecure external network from a secure internal network. At the perimeter, all traffic is inspected and the potentially dangerous part is blocked. With zero-trust architectures, inspection and blocking are moved from the perimeter directly to the services themselves. In other words, each service inspects its own traffic and only allows that which is recognised as safe. This naturally reduces the complexity of the security system and makes it more manageable. Implementing a zero-trust architecture therefore requires technologies similar to those at the perimeter, but in a smaller and more resource-efficient form. The idea of the microgateway was derived from this.
Microgateway as an enabler for DevSecOps
However, the change to a Zero Trust architecture does not happen overnight. This sounds much more complicated than it actually is. Because the path to Zero Trust can be taken gradually in simple steps.
The strength of Zero Trust is its ability to distribute and scale resource development, process flows and security. But this is also its weakness, because not everything can be distributed so easily. One of these features is identity and access management (IAM). A seamless single sign-on user experience can best be achieved with central authentication and identity management services. The edge gateway acts as a policy enforcement point, with the actual decisions being made by the IAM service (see diagram below). Verification of identity information and authorisation of users is performed by the individual services.
The central gateway remains important
Placing an edge gateway in front of the microgateways is not a technical requirement. It is a design decision due to the fact that some tasks can be better implemented on an edge-oriented device and others need to be closely linked to the service in question. The edge-oriented gateway therefore has a more generic configuration that enables the rapid and seamless integration of new services protected by microgateway instances.
Microgateway turns DevOps into DevSecOps teams
Typical integration tasks, such as adding rule exceptions or URL rewriting, on the other hand, are handled on the Microgateway. The gateway thereby represents a lean security component that protects a specific service. The zero-trust architecture also ensures that each service not only protects itself against unwanted traffic, but also validates each request to guarantee that only properly authenticated users have access to the services and data for which they are authorised. The decision itself whether to open a service or application to the outside world can still be made at the perimeter.
The microgateway is managed by the DevOps team of the protected service and supports in many ways:
- Agility: multiple independent development teams benefit from the existing infrastructure. Since the Microgateway configuration is maintained by the development team, a new service release requires little to no coordination with the gateway administrator.
- Scalability and availability: Microgateways deploy and scale directly with their services. Microgateway capabilities ensure that session information is available regardless of which microgateway instance is handling the request.
- Time-to-market: Microgateways enforce authentication before allowing access to the service. This eliminates the need to incorporate these functions into each individual service. Because these critical security tasks are handled by the standardised infrastructure component, developers can spend more time on business features.
- Tailored security: Microgateways have a very small footprint, so developers can use them throughout the development process. This ensures that the service works with the microgateway and allows the developer to configure filtering rules for optimal security. Integration errors and security issues are noticed much earlier in the development cycle, long before the service goes live.
Microgateways are thus an important tool to support the way DevOps teams implement zero-trust architectures and thus become DevSecOps teams.
Implement DevSecOps efficiently with Airlock
We have compiled the most important findings on how you can successfully and efficiently implement DevSecOps, which security components are needed for this and which advantages a Microgateway architecture brings in a detailed white paper.
Toward DevSecOps
In a DevSecOps culture, every agile team has a security expert. He fulfills non-functional requirements, so the product owner includes security in the development plan.
Read this whitepaper to learn key insights on how to successfully and efficiently implement DevSecOps, what security components are needed to make it happen, and the benefits of a microgateway architecture.
The Airlock portfolio includes both a Microgateway and an Edge Gateway, making it the ideal partner for transforming DevOps to DevSecOps teams. Contact our experts if you would like to learn more about DevSecOps, Zero Trust or Airlock's products - which, by the way, are also available as Managed WAF-as-a-Service from InfoGuard. We look forward to accompanying you on the road to DevSecOps!
This is a guest post from Infoguard.
Blognews directly to your inbox
The Airlock Newsletter informs you continuously about new blog articles.