As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Recomendações de segurança em nível de linha
<a name="rls"></a>

A segurança em nível de linha (RLS) é necessária para manter o isolamento dos dados do inquilino em um modelo agrupado com o PostgreSQL. O RLS centraliza a aplicação de políticas de isolamento no nível do banco de dados e elimina a carga de manter esse isolamento dos desenvolvedores de software. A forma mais comum de implementar o RLS é habilitar esse recurso no DBMS PostgreSQL. O RLS envolve filtrar o acesso às linhas de dados com base em um valor em uma coluna especificada. Você pode usar dois métodos para filtrar o acesso aos dados:
+ Uma coluna de dados especificada em uma tabela é comparada ao valor do usuário atual do PostgreSQL. Os valores na coluna que são equivalentes ao usuário PostgreSQL conectado podem ser acessados por esse usuário.
+ Uma coluna de dados especificada em uma tabela é comparada ao valor de uma variável de tempo de execução definida pelo aplicativo. Os valores na coluna que são equivalentes à variável de tempo de execução podem ser acessados durante essa sessão.

A segunda opção é preferida, pois a primeira requer a criação de um novo usuário do PostgreSQL para cada locatário. Em vez disso, um aplicativo SaaS que usa o PostgreSQL deve ser responsável por definir um contexto específico do inquilino em tempo de execução ao consultar o PostgreSQL. Isso terá o efeito de impor o RLS. Você também pode habilitar o RLS em uma table-by-table base. Como prática recomendada, você deve habilitar o RLS em todas as tabelas que contêm dados do inquilino. 

O exemplo a seguir cria duas tabelas e ativa o RLS. Este exemplo compara uma coluna de dados com o valor da variável `app.current_tenant` de tempo de execução.

```
-- Create a table for our tenants with indexes on the primary key and the tenant’s name
CREATE TABLE tenant (
    tenant_id UUID DEFAULT uuid_generate_v4() PRIMARY KEY,
    name VARCHAR(255) UNIQUE,
    status VARCHAR(64) CHECK (status IN ('active', 'suspended', 'disabled')),
    tier VARCHAR(64) CHECK (tier IN ('gold', 'silver', 'bronze'))
);
 
-- Create a table for users of a tenant
CREATE TABLE tenant_user (
    user_id UUID DEFAULT uuid_generate_v4() PRIMARY KEY,
    tenant_id UUID NOT NULL REFERENCES tenant (tenant_id) ON DELETE RESTRICT,
    email VARCHAR(255) NOT NULL UNIQUE,
    given_name VARCHAR(255) NOT NULL CHECK (given_name <> ''),
    family_name VARCHAR(255) NOT NULL CHECK (family_name <> '')
);
 
-- Turn on RLS
ALTER TABLE tenant ENABLE ROW LEVEL SECURITY;
 
-- Restrict read and write actions so tenants can only see their rows
-- Cast the UUID value in tenant_id to match the type current_setting
-- This policy implies a WITH CHECK that matches the USING clause
CREATE POLICY tenant_isolation_policy ON tenant
USING (tenant_id = current_setting('app.current_tenant')::UUID);
 
-- And do the same for the tenant users
ALTER TABLE tenant_user ENABLE ROW LEVEL SECURITY;
 
CREATE POLICY tenant_user_isolation_policy ON tenant_user
USING (tenant_id = current_setting('app.current_tenant')::UUID);
```

Para obter mais informações, consulte a postagem do blog [Isolamento de dados de vários locatários com a segurança em nível de linha do PostgreSQL](https://aws.amazon.com/blogs/database/multi-tenant-data-isolation-with-postgresql-row-level-security/). A equipe da AWS SaaS Factory também tem [alguns exemplos GitHub para auxiliar na](https://github.com/aws-samples/aws-saas-factory-postgresql-rls) implementação do RLS.