Automated infrastructure: Regulatory security through IaC

Infrastructure as Code (IaC) means that IT infrastructure (servers, networks, databases, etc.) is defined and managed using code rather than manually. The aim is to make infrastructure reproducible, versionable and automatable – similar to software development.

Config management systems have been around for much longer. They are used to configure and manage software and systems after the infrastructure already exists.

In the course of managing cloud systems, tools for Infrastructure as Code have become widely used and config management systems for IaC have been expanded. IaC means the provision and management of the infrastructure itself (servers, networks, databases, cloud resources).

The advantages of IaC are:

• Consistency and repeatability
• Faster deployment
• Version control (e.g. via Git)
• Scalability
• Reduction of human error
• Changes that can be audited for revision purposes

Infrastructure as Code is a central component of modern IT automation. Choosing the right tool depends heavily on the environment, requirements and personnel. Free open source tools offer a good introduction and are usually very mature, while enterprise versions offer additional features and support.

Before choosing an IaC system, you should consider the following:

• What infrastructure do you want to manage?
• Which tools provide support for the infrastructure?
• Should configuration management also be carried out with the same tool?
• Do you need a support contract?
• What is the technical background of the team?
• How complex is the environment?
• How good is the documentation and community?
• What language is used (YAML, DSL, real programming languages)?
• Is state management desired?
• How high are the licence and operating costs?

It is generally advisable to choose an IaC tool that is not cloud-specific. AWS CloudFormation, Azure ARM, and GCP Deployment Manager only work in their respective clouds.
Of course, creating a virtual Linux host is different in every cloud. So you have to use cloud-specific providers or modules, but the basic concept is the same for cloud-independent tools.

The three most important IoC tools

Terraform (HashiCorp)

• Declarative IaC tool.
• Multi-cloud and on-premises capable.
• Uses HCL (HashiCorp Configuration Language).
• State management for infrastructure.
• Provisioning of VMs, networks, databases in AWS, Azure, GCP, VMware, etc.
• Support available, otherwise free of charge.
• Open source option with OpenTofu.
• Custom providers are written in Go.
• In Terraform, environment-specific variables mean the use of additional products such as Terragrunt in larger environments.
• Very complex in large environments.

Pulumi

• Code-based IaC tool.
• Multi-cloud and Kubernetes-compatible.
• Uses programming languages such as Python, TypeScript, Go, C# instead of its own DSL.
• State management for infrastructure.
• Use: Ideal for teams that prefer to write ‘real code’ instead of declarative templates.
• Support available, otherwise free to use.
• Custom providers are written in Python, TypeScript, Go, C#.
• Stacks per environment are intuitive.

Ansible (RedHat)

• Automation & IaC (often seen as a hybrid between configuration management and IaC).
• Multi-cloud and on-premises.
• Uses YAML for playbooks.
• Can both provision infrastructure (via modules) and configure it.
• Use: Often for provisioning + configuration in one step.
• Support available, otherwise free of charge.
• Custom modules are written in Python.
• Environment-specific variables are easy to resolve using corresponding YAML files.
• Inventories for each environment are easy to understand and variables are highly scalable.

The state file is a central concept in tools such as Terraform and Pulumi. It stores the current state of the infrastructure so that the IaC tool knows what already exists and what needs to be changed. Loss or corruption of the state file means that the IaC tool ‘forgets’ the infrastructure. This means that the state file must be given special attention and must be protected from access, as it may contain sensitive data. It may also be necessary to work with multiple state files.

In contrast, Ansible has to compare the current state with the code each time, which takes a little more time. But you save yourself the effort of the state file.

CI/CD

The IaC tool should be integrated into CI/CD. Infrastructure changes are just as critical as software changes.

CI/CD provides:

• Versioning (via Git).
• Automated tests (e.g. policy checks, security checks).
• Approval processes (e.g. “View plan before applying”).
• Creation of a change request.
• Reproducibility (no manual clicking in the cloud console).

Continuous Integration (CI)

• Developers push code (or IaC) to a Git repository.
• A CI pipeline automatically checks:
o Syntax and formatting (e.g. terraform validate, ansible-lint).
o Tests (unit and integration tests).
o Planning (e.g. terraform plan shows changes without applying them).
• Goal: Detect errors early, ensure quality.

Continuous Delivery/Deployment (CD)

• After successful CI testing, the code is rolled out automatically:
o For IaC, this means that infrastructure changes are applied (terraform apply, pulumi up, ansible-playbook).
• Delivery = Changes are prepared but require manual approval.
• Deployment = Changes are implemented live fully automatically.

Crucial for the financial sector

In the financial sector, Infrastructure as Code (IaC) is particularly crucial from a regulatory perspective – here are the most important reasons why:

• With IaC, every infrastructure change is documented as code in the versioning system, including timestamp, author and change details. This greatly simplifies accountability and audit reporting.
• Guidelines on access restrictions, encryption or data retention can be stored directly in the IaC code as machine instructions.
• Violations of specifications are detected and blocked during the CI/CD pipeline – compliance is implemented proactively and in real time.
• Standardised IaC templates (templates, modules) prevent configuration deviations – human errors such as open ports or faulty encryption are greatly reduced.
• Uniform environments (Dev, Test, Prod) reduce risks and help to consistently comply with regulatory requirements.
• The Digital Operational Resilience Act (DORA) requires, among other things, automated ICT risk control, systematic incident management and testing of digital resilience. IaC provides the necessary structure for this.
• Infrastructure becomes reproducible and validly testable – a clear advantage in regulatory reviews.

If you want to make your infrastructure future-proof, automated and audit-compliant, we can support you from analysis to implementation of Infrastructure as Code. Our experts will guide you in selecting the right tools, setting up CI/CD pipelines and successfully introducing modern operating procedures.

About the author:

Andreas Dvorak works as a Senior Technical Analyst at Be Shaping The Future and brings with him many years of experience in the operation, automation and monitoring of on-premises and cloud environments.