How microgateways prepare the ground for security in software development
In an increasingly digital and software-driven world, a company's success is largely dependent on how quickly and securely it can develop and provide services. A key aspect of this is DevOps and, in particular, DevSecOps, which stands for a culture of cooperative collaboration across functions. However, implementing these structural and technical changes is by no means trivial. To be successful today, there is no way around microgateways. But this is just one building block - the full picture is far more complex.
Traditionally, software development and operation in a company have pursued different goals:
- Software development must be agile, creative and at the cutting edge of technology in order to constantly deliver new features
- IT Operations, on the other hand, is designed for stability, security and reliability.
DevOps unites this apparent contradiction between flexibility and stability. To this end, the entire value chain from software development to operation is to be combined in an interdisciplinary manner. This breaks down silo thinking by bridging the gaps between the silos and aligns the organization with the common goal of delivering new functions quickly in stable, secure steps.
From DevOps to DevSecOps - what's behind it?
Originally, security was a kind of "gatekeeper" at the end of the software development process, similar to Operations before the introduction of DevOps. The "Sec" in "DevSecOps" emphasizes and clarifies collaboration and the shift in responsibility. In a DevSecOps culture, each agile team has a security expert who takes care of non-functional requirements, such as classifying data and other aspects of risk analysis. This ensures that the product owner also takes security aspects into account during development.
This proactive approach allows teams to take overall responsibility for the scope of their services. Furthermore, if security is integrated asynchronously with product development, the product owner can manage both velocity and security without neglecting either. Agile development therefore also requires agile infrastructures and agile security.
The way in which software is protected against internal and external threats is evolving in response to the current threat landscape. The latest step in this evolution is the introduction of zero-trust architectures. In conventional perimeter security architectures, an insecure external network is separated from a secure internal network at the perimeter. Here, all data traffic is monitored and potentially dangerous traffic is blocked. With zero trust architectures, the monitoring and blocking of traffic is no longer carried out at the perimeter, but directly by the services themselves. In other words, each service checks its own traffic and only allows traffic that is recognized as secure. This reduces the complexity of the security system and makes it more manageable. Implementing a zero trust architecture requires technologies similar to those at the perimeter, but on a smaller and more resource-efficient scale. This requirement gave rise to the idea of microgateways.
Microgateways as an enabler for DevSecOps
The strength of Zero Trust lies in being able to distribute resources and security measures everywhere and adapt them to requirements. Security is therefore no longer concentrated in a single location. But this is also a major challenge, because not everything can simply be distributed everywhere. One such challenge concerns identity and access management (IAM): to provide users with a seamless single sign-on experience, it is best to use centralized authentication and identity management services.
In this context, the edge gateway acts as a kind of guardian for security policies. However, the actual decisions about who is allowed to access which resources are made by a central IAM service (as shown in a diagram). Checking the identity of users and authorizing what they are allowed to do is done by the individual services and resources themselves.
The central gateway remains important
Placing an edge gateway in front of the microgateways is not a technical necessity, but a decision made during the design process. This decision is based on the fact that certain tasks can be performed better on a so-called edge-oriented device, while others are closely linked to a specific service. The edge-oriented gateway therefore has a more generic configuration. This enables the easy and smooth integration of new services that are protected by the individual microgateway instances. In other words, it serves as a kind of central interface that makes it easier to add new services to the system and protect them effectively.
The Microgateway turns DevOps teams into DevSecOps teams
The task of integrating functions such as adding exceptions or redirecting URLs usually lies with the microgateway. This gateway is a lean security component that protects a specific service. In a zero trust architecture, each service instance not only provides its own protection against unwanted traffic, but also checks each request to ensure that only properly authenticated users have access to the relevant services and data. The decision as to whether a service or application is opened for external requests can still be made at the network perimeter.
The microgateway is managed by the DevOps team of the protected service and provides support in a variety of ways:
- Agility:Several independent development teams benefit from the existing infrastructure. As the configuration of the Microgateway is maintained by the development team, a new service version requires little or no coordination with the gateway administrator.
- Scalability and availability:Microgateways are set up directly with their services and scale with them. The functions of the microgateways ensure that session information is available regardless of which microgateway instance is processing the request.
- Time-to-Market:Microgateways enforce authentication before allowing access to the service. This eliminates the need to build these functions into each individual service. Since these critical security tasks are handled by the standardized infrastructure component, developers can invest more time in business features.
- Customized security: Microgateways have a very low resource consumption, allowing developers to use them throughout the development process. This ensures that the service works well with the Microgateway and allows developers to configure filtering rules for optimal security. Integration difficulties and security issues are detected much earlier in the development cycle, long before the service goes live.
Microgateways are therefore an important tool for supporting DevOps teams on their way to implementing zero-trust architectures and thus becoming DevSecOps teams.
Blognews directly in your mailbox
The Airlock Newsletter informs you continuously about new blog articles.