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

# Requisitos de deploy (BYOC)

> Configure os proxies confiáveis para que a lista de IPs permitidos seja aplicada no seu próprio deploy BYOC.

A [lista de IPs permitidos](https://docs.lerian.studio/pt/platform/access-manager/features/ip-allowlist/overview) compara o endereço de rede de quem chamou com a lista. Atrás de um load balancer ou de um ingress, o endereço que o serviço vê é o do proxy, não o de quem chamou. Esta página diz a um operador BYOC o que configurar para a plataforma descobrir o endereço real.

> [!NOTE]
>
> Esta página vale apenas para deploys BYOC. Na Lerian Cloud, a Lerian opera essa configuração para você. Você gerencia apenas a lista em si.

Para a visão de arquitetura, leia [Lista de IPs permitidos do tenant](https://docs.lerian.studio/pt/platform/access-manager/product-level-enforcement.md#tenant-ip-allowlist).

## Proxies confiáveis

***

Defina `TRUSTED_PROXIES` nestes serviços Lerian, não apenas no Access Manager:

* Os serviços **Auth** e **Identity** do Access Manager.
* Os produtos Midaz, Reporter, Lender e Streaming Hub.
* Os trilhos Pix via JD, Pix via BTG, Pix Lerian e Bank Transfer.

Cada um desses serviços resolve o endereço de quem chamou por conta própria e o encaminha ao serviço Auth do Access Manager. Um serviço sem a variável não encaminha endereço nenhum. O Auth usa um endereço encaminhado apenas de quem chama de dentro de `TRUSTED_PROXIES` ou `PLATFORM_INTERNAL_CIDRS` do Auth. No próprio Access Manager, a variável decide se a lista é aplicada ou não, como mostra a tabela abaixo.

O valor é uma lista de faixas CIDR separadas por vírgula. Liste apenas os proxies e as redes que se conectam diretamente àquele serviço. No Auth, inclua as redes a partir das quais os produtos e trilhos chamam o Auth.

```text Example theme={null}
TRUSTED_PROXIES=10.0.0.0/16,10.1.0.0/16
```

Regras que a plataforma aplica ao valor:

* Apenas faixas CIDR. Um endereço solto, sem prefixo, é recusado.
* Faixas muito amplas são recusadas: mais amplas que `/8` para IPv4 ou `/48` para IPv6. `0.0.0.0/0` nunca funciona.
* No Access Manager, um valor malformado interrompe o serviço na inicialização.

O Caradhras, o backend de identidade, lê o endereço do chamador somente de um par listado na própria configuração `trustedProxies`, uma lista separada por vírgulas de endereços ou intervalos CIDR. Liste cada proxy na frente do Caradhras e o serviço Identity do Access Manager. Sem ela, toda verificação de endereço do cliente no Caradhras vê o endereço do proxy.

O que acontece quando o valor está ausente:

| Onde não está definido | Efeito |
| - | - |
| Auth do Access Manager | A lista não é aplicada. Uma métrica e uma linha de log sinalizam a condição de proxy não confiável. |
| Um produto ou trilho listado, como o Midaz | O serviço não encaminha endereço de quem chamou. Se o serviço chama o Auth a partir de uma rede em `TRUSTED_PROXIES` ou `PLATFORM_INTERNAL_CIDRS` do Auth, o Auth permite a requisição sem verificar o endereço. |

Em uma requisição de produto (`POST /v1/authorize`) de quem chama de fora de `TRUSTED_PROXIES` e `PLATFORM_INTERNAL_CIDRS` do Auth, o Auth verifica o próprio endereço de quem chama quando esse endereço é público. Quando ele não é público, como um endereço privado ou CGNAT, o Auth permite a requisição sem verificação. Uma métrica e uma linha de log que nomeia o endereço sinalizam isso. Na entrada e na emissão de tokens, o Auth verifica o próprio endereço de quem chama, público ou não.

## Validar o deploy

***

Rode esta verificação uma vez depois de definir as variáveis, a partir de um workspace cuja lista você controla.

**1. Ative uma lista com o seu próprio endereço**

Envie a lista pela [API do Identity](https://docs.lerian.studio/pt/platform/access-manager/features/ip-allowlist/api.md) com `"scopes": ["console", "api"]`. Inclua o endereço de onde você se conecta e o endereço de onde o seu cliente de teste chama.

**2. Entre a partir de um endereço listado**

Entre a partir desse endereço. A entrada deve dar certo.

**3. Entre a partir de um endereço não listado**

Entre a partir de outra rede, como uma conexão móvel. Espere uma recusa.

**4. Chame um endpoint do Midaz a partir dos dois endereços**

Chame qualquer endpoint protegido do Midaz a partir do endereço listado e depois do não listado. Espere `200` e depois `403` com o código `AUT-0021`.

Se a plataforma aceita uma requisição do endereço não listado, ela não descobre o endereço real. Verifique `TRUSTED_PROXIES` no serviço que respondeu e no Auth, e `PLATFORM_INTERNAL_CIDRS` no Auth e no Identity.

## Páginas relacionadas

***

> [card] [Arquitetura da lista de IPs permitidos do tenant](https://docs.lerian.studio/pt/platform/access-manager/product-level-enforcement.md#tenant-ip-allowlist)
>
> Como o Auth, o Identity e cada produto compartilham a verificação.

> [card] [Gerencie a lista no Console](https://docs.lerian.studio/pt/platform/access-manager/features/ip-allowlist/console.md)
>
> O guia do administrador para a página Segurança.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.