> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Security

> See how Midaz protects financial operations with security by design, STRIDE threat modeling, OWASP-aligned controls, and a clear shared responsibility model.

Security is the foundation of any financial system.

Midaz builds in protections for data integrity, access control, and tenant isolation. It uses strong identity management, fine-grained permissions, and industry-standard practices.

This page describes the security architecture Midaz provides by default. It also shows how you run secure and compliant operations.

## 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:
  * **S**poofing (e.g., fake authentication in a banking API).
  * **T**ampering (e.g., altering transaction data mid-request).
  * **R**epudiation (e.g., lack of audit logs for transactions).
  * **I**nformation Disclosure (e.g., leaking sensitive data via API responses).
  * **D**enial of Service (e.g., overwhelming the API with fake requests).
  * **E**levation 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](/en/deployment-models).

| Lerian                       | Customer                     |
| ---------------------------- | ---------------------------- |
| Application Development      | Infrastructure               |
| Application Security Updates | Network                      |
|                              | Database                     |
|                              | Identity & Access Management |
|                              | Encryption                   |
|                              | User Data                    |
|                              | Monitoring                   |
|                              | Additional Security Layers   |

### 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.

**What the customer secures:**

* **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.

**What the customer secures:**

* **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.

<Tip>
  For step-by-step guidance, see [Security Recommendations](/en/midaz/security-recommendations) in the Installing & Deploying section.
</Tip>

## 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](/en/platform/access-manager/access-manager) 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

This option simplifies secure access control. It aligns with Midaz's native permission system (RBAC).

## 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](/en/multi-tenancy#isolation-modes), 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 both `DATABASE` and `SCHEMA` [isolation modes](/en/multi-tenancy#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](/en/multi-tenancy/auto-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_timeout` on 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.

<Note>
  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.
</Note>

<Tip>
  For a full overview of multi-tenancy, see [Multi-tenancy](/en/multi-tenancy).
</Tip>

## 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.

These checks reduce risk. They keep financial operations aligned with business rules and regulatory expectations.

### 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.

Data protection is a shared commitment, not a single layer. Midaz provides the foundation. You build the safeguards.

## Responsible disclosure policy

***

Transparency builds trust. We share all known security improvements and fixes openly in our [**GitHub Discussions**](https://github.com/LerianStudio/midaz/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.

<Danger>
  Do not disclose any findings publicly until we review and address them.
</Danger>

The steps to report a vulnerability:

<Steps>
  <Step title="Report">
    Email us at [security@lerian.studio](mailto:security@lerian.studio).
  </Step>

  <Step title="Acknowledgment">
    We respond within 24 hours.
  </Step>

  <Step title="Verification">
    Our team validates the report.
  </Step>

  <Step title="Impact Assessment">
    We determine the severity and impact.
  </Step>

  <Step title="Resolution">
    We fix the issue and notify the reporter.
  </Step>

  <Step title="Public Disclosure">
    We coordinate disclosure with the researcher.
  </Step>
</Steps>

<Warning>
  Use a PGP key for secure communication. We prioritize confidentiality and fast resolution of all security reports.
</Warning>