Skip to main content
Read this guide before you install and deploy Midaz. Security is critical. At Lerian, we work under a Security Shared Responsibility Model. We secure the application layer: Midaz and all Lerian plugins. You secure the infrastructure where they run. This guide helps your team build and keep a strong security posture across the Lerian ecosystem, from Midaz to every integrated plugin. These recommendations are not exhaustive. They complement your existing security practices, whether you run in the cloud or on-prem.

​
Infrastructure & network security

Midaz and all Lerian plugins are cloud-native. They run in containerized, distributed environments. To strengthen your infrastructure and network security:
  • Establish a patch management process that updates the OS and services with security patches on a regular schedule.
  • Apply hardening procedures to your operating system images before deployment.
  • Use the Midaz and plugin Docker images, which follow the least privilege principle. Reinforce this at the cluster level with the right controls.
  • For Kubernetes, enforce security baselines with policy-as-code tools such as Kyverno or OPA Gatekeeper.
  • Run routine vulnerability scans across all layers of your infrastructure, including the layers that host plugins.
  • Use network segmentation to restrict access to Midaz components and plugins to only the systems that need it.
  • Configure firewalls to manage traffic flow and prevent unauthorized access.
  • Where possible, implement Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) to analyze network behavior and block anomalies.
  • Adopt a Zero Trust Architecture for sensitive systems and data flows.
  • Enforce TLS 1.2 or higher for all communication across Midaz and plugin services.

​
General security configurations

You must protect secrets, storage, and data across all Lerian components, including Midaz and its plugins. Follow these practices:
  • Use trusted solutions such as AWS Secrets Manager, Azure Key Vault, Google Secret Manager, or HashiCorp Vault to store secrets and configuration data securely.
  • Rotate credentials and secrets on a regular schedule. Follow the principle of least privilege when you grant access.
  • Enable audit logging. Configure automated backups for all databases that Midaz and plugins use.
  • Apply encryption at rest to all persistent data, including the data that plugins such as Access Manager process.
  • Enforce access restrictions on sensitive data. Use tokenization, encryption, or anonymization where appropriate.
  • Update Midaz and all Lerian plugins to the latest releases, including patches and security improvements.

​
Identity & Access Management (IAM)

Apply a unified IAM approach across two layers — the environment where you deploy Midaz and plugins, and the services themselves. Follow these practices:
  • Implement a centralized IAM process to manage access to the infrastructure that hosts Lerian products.
  • Enforce multi-factor authentication (MFA) across all user and admin accounts.
  • Monitor and audit access to service accounts on a regular schedule, especially the accounts that plugins use.
  • Define access control models that follow the least privilege principle with RBAC, ABAC, or custom strategies.
  • Use temporary credentials and time-limited access for high-sensitivity operations.
  • Review all access privileges on a regular schedule, including access to Midaz, Access Manager, Reporter, and other products.

​
Monitoring & incident response

To build observability and incident readiness into how you deploy Midaz and plugins:
  • Deploy security monitoring tools to track behavior across all Lerian services, including plugin activity.
  • Enable logs and traces across your infrastructure and each component of Midaz and its plugins.
  • Integrate logs from Midaz and plugin services with fraud detection or anomaly monitoring tools.
  • Centralize logs in a SIEM platform for more efficient threat detection.
  • Maintain an updated incident response plan, with specific playbooks for services such as Access Manager or Fees Engine.

​
Additional protection layers

For production-critical or high-compliance environments, add these protective layers:
  • Apply OS and service hardening procedures across your entire stack.
  • Maintain regular patch cycles for all runtime environments, including third-party services and dependencies.
  • Conduct manual penetration tests to validate your defenses, including the defenses around plugins and integrations.
  • Deploy Web Application Firewalls (WAFs) to protect plugin APIs and Midaz endpoints from Layer 7 attacks.
  • Use Anti-DDoS services and bot mitigation tools to block automated or mass-scale attacks on exposed components.
Combine infrastructure-level protections with the built-in security validations of Midaz and its plugins. Together they create a compliant, scalable financial environment.

​
Midaz security configurations

Security starts with configuration. Review and adjust all credentials and certificates before you go live, whether you run Midaz locally or deploy it in a managed cluster.

​
Credentials and secrets

Each Midaz component has its own .env file for per-module configuration. This gives you flexibility and a shared responsibility.
Never deploy Midaz with default credentials. Update all secret values in your environment before you launch.
Review and update the following files to protect sensitive information: Store secrets such as database credentials, encryption keys, and API tokens securely. Rotate them on a regular schedule.

​
TLS Certificate configuration

When you expose Midaz services through ingress controllers, use valid TLS certificates. Valid certificates secure the communication between services and external clients. You can enable ingress for the following Midaz components:
  • Transaction
  • Onboarding
  • Console
To configure a custom TLS certificate:
1
Generate a valid certificate with a trusted provider (for example, Let’s Encrypt or GoDaddy).
2
Store the full certificate chain as a Kubernetes secret or in an external vault (for example, AWS Secrets Manager).
3
Reference the secret in your values.yaml file:
Always enforce TLS 1.2 or higher. For internal clusters, issue short-lived certificates automatically with a service mesh or cert manager.