Architecture
Midaz uses a secure architecture. It applied security by design and threat modeling from the start. It still applies both to every new feature.
- Security by design: Midaz embeds security controls across the lifecycle, from design to deployment. It follows OWASP guidelines such as the OWASP Top 10 and the OWASP Application Security Verification Standard (ASVS).
- Threat Modeling: A structured process identifies, assesses, and reduces security risks before an attacker exploits them. Midaz uses the STRIDE methodology. STRIDE groups threats into six types:
- Spoofing (e.g., fake authentication in a banking API).
- Tampering (e.g., altering transaction data mid-request).
- Repudiation (e.g., lack of audit logs for transactions).
- Information Disclosure (e.g., leaking sensitive data via API responses).
- Denial of Service (e.g., overwhelming the API with fake requests).
- Elevation of Privilege (e.g., exploiting a bug to gain admin access).
Shared responsibility model
Security is a shared responsibility between Lerian and the customer. The exact split depends on your deployment model.
In the BYOC model
In BYOC (Bring Your Own Cloud), you deploy Lerian in your own infrastructure. Lerian secures the application layer. You secure the environment. What Lerian secures:- Secure-by-design services.
- Proactive vulnerability fixes.
- Security updates: dependency upgrades, security patches, and improvements.
- Infrastructure: Harden the OS and container images, manage patches, and apply secure configurations on the hosting platform.
- Network: Implement segmentation, firewalls, and IDS/IPS systems. Adopt Zero Trust principles to protect internal and external communication.
- Database: Set up backups and audit logging. Follow security best practices for data storage.
- Identity & Access Management: Control access to the environment. Use Midaz’s RBAC features to enforce least-privilege policies within the platform.
- Encryption: Encrypt sensitive data at rest and in transit. Consider tokenization or anonymization where appropriate.
- User Data: All user data that Midaz stores or processes stays under your control and responsibility.
- Monitoring: Establish monitoring tools that detect unusual access patterns or suspicious behavior.
- Additional Security Layers: Reinforce defenses with Web Application Firewalls (WAF), anti-DDoS mechanisms, and bot mitigation tools.
In the SaaS model
In SaaS, Lerian manages the full infrastructure. Lerian takes on more of the security responsibility. What Lerian secures:- Everything in the BYOC application layer, plus:
- Cloud infrastructure, networking, and compute environment.
- Database provisioning, encryption at rest, and automated backups.
- OS and container patching.
- Monitoring, alerting, and incident response.
- High availability and disaster recovery.
- Business-level access control: Manage users, roles, and permissions within the platform.
- API integration security: Secure the communication between your systems and the Lerian APIs.
- User Data governance: Define and enforce data-handling policies that meet your regulatory obligations.
- Compliance: Make sure your use of the platform aligns with your institution’s regulatory requirements.
Identity and Access Management
Midaz accepts a Bearer JWT issued by an OAuth 2.0 / OpenID Connect provider. Authentication is off unless you set
PLUGIN_AUTH_ENABLED=true — and Midaz refuses to start without it when ENV_NAME=production or multi-tenancy is enabled. You choose how to manage identity and access. You have two options:
- Use your own external IAM (Identity and Access Management) solution.
- Use Lerian’s native Access Manager Plugin — a good fit for customers without an existing IAM system, or those who want a fully integrated experience.
Option 1: External IAM
If you integrate your own IAM provider, make sure it follows modern security practices. To keep Midaz secure, we recommend that you:- Use proven protocols such as OAuth 2.0 and OpenID Connect.
- Require Multi-Factor Authentication (MFA).
- Apply strong password hashing algorithms such as bcrypt or argon2.
- Enforce fine-grained access controls with RBAC, ABAC, or similar models.
- Manage sessions securely, with expiration rules and refresh-token policies.
- Protect endpoints from brute-force and replay attacks.
- Enable and review access logs regularly.
Option 2: Access Manager Plugin
The Access Manager Plugin manages authentication and authorization inside Midaz. It is fully integrated, and it provides:- User lifecycle management
- Session token handling
- Refresh token rotation
- Application registration and management
Tenant isolation in multi-tenant deployments
On Lerian SaaS or BYOC Multi-Tenant, Midaz isolates all resources by tenant at the application layer. This covers organizations, ledgers, accounts, and transactions. Your JWT access token carries the tenant context. On every request, the platform middleware resolves the tenant from the
tenantId claim in the token. Your API calls never see data from other tenants. Other tenants never see your data.
This isolation works independently of the organization hierarchy. Two tenants can create similar organization structures, and their data stays completely separate. In DATABASE isolation mode, each tenant uses its own dedicated database. In SCHEMA mode, tenants share a database, but each tenant’s data stays isolated behind its own distinct credentials.
Credential isolation
Each tenant has its own credentials. Midaz never shares them between tenants, in bothDATABASE and SCHEMA isolation modes. Under SCHEMA mode, tenants share a database instance. Even so, each tenant’s access uses its own distinct credentials. One tenant can never authenticate into another tenant’s data.
Midaz generates credentials during automatic provisioning. It stores them in a credentials vault, not in configuration files or environment variables. You can rotate credentials on demand while the platform continues to serve requests. The rotation causes no downtime and no interruption to tenant operations.
Per-tenant resource limits
Multi-tenant deployments enforce resource limits so that no single tenant degrades others. This is the noisy neighbor problem:- Kubernetes resource limits — CPU and memory limits on each workload cap how much compute it can consume. This bounds the impact of a spike or a runaway workload.
- PostgreSQL statement timeout — Midaz does not set one itself. Configure
statement_timeouton your PostgreSQL roles or databases so no single query can hold resources indefinitely. - Connection pool per service — each service keeps its own connection pool, with one pool per active tenant. Per-tenant pool limits come from the connection settings each tenant carries in Tenant Manager, and idle tenant pools are evicted over time. This bounds connection capacity per tenant. One tenant cannot exhaust the database connections that others need.
These limits complement the data isolation above. Data isolation protects each tenant’s data from other tenants. Resource limits protect each tenant’s performance and availability from other tenants’ load.
Data protection
Midaz enforces double-entry principles by design. Every transaction must have balanced debits and credits. Midaz rejects any entry that fails this validation. This protects ledger integrity. It also protects the system against race condition vulnerabilities and posting discrepancies.
Built-in safeguards
Midaz applies strict validation across all transaction flows to keep data consistent and prevent logic errors:- Midaz blocks negative balances, unless you explicitly permit them.
- Midaz verifies account status before any operation.
- Midaz requires a registered, valid asset before it posts an entry.
Compliance with LGPD and GDPR
Midaz handles transaction validation and secure communication over TLS 1.2 and 1.3. You protect personally identifiable information (PII). To stay compliant with LGPD, GDPR, and similar data protection laws, we recommend that you:- Apply encryption to sensitive data, at rest and in transit.
- Use tokenization or anonymization when appropriate.
- Store and manage customer data under clearly defined security policies.
Responsible disclosure policy
Transparency builds trust. We share all known security improvements and fixes openly in our GitHub Discussions. This keeps the community informed about security patches and enhancements. If you find a security vulnerability in Midaz, report it directly to our team before you make it public. We support responsible disclosure. We investigate and resolve issues quickly and thoroughly.
Do not disclose any findings publicly until we review and address them.
1
Report
Email us at security@lerian.studio.
2
Acknowledgment
We respond within 24 hours.
3
Verification
Our team validates the report.
4
Impact Assessment
We determine the severity and impact.
5
Resolution
We fix the issue and notify the reporter.
6
Public Disclosure
We coordinate disclosure with the researcher.