Ambiente com redundância

Procedimento para auxilio em ambientes com redundância para o MFA da CAFe versão 4.2.1

Informações importantes

Em instalações com redundância, existem alguns passos manuais adicionais que devem ser executados. Verifique atentamente cada um dos pontos apresentados.

Uma questão importante em relação a ambientes redundantes, é que a instalação é realizada de forma diferente nos servidores secundários. Ou seja, NÃO se deve clonar a instalação do servidor principal e achar que automaticamente o servidor clonado irá operar adequadamente como secundário.

Isso acontece porque os dados precisam estar sincronizados entre as base de dados. Para garantir a sincronização de forma segura, evitando qualquer inconsistência nos dados, somente a base de dados do servidor principal opera em modo escrita.

Figura 1 - Fluxo de comunicação MFA

A Figura apresenta ilustra o cenário. A base de dados no servidor secundário opera em modo somente leitura. Toda vez que o usuário está no servidor secundário e realiza alguma operação que envolve escrita na base de dados, o servidor secundário se comunica com o primário e pede para o primário realizar a escrita. Tudo que é escrito/alterado no banco de dados do servidor principal é então replicado para o banco de dados secundário.

Etapas Adicionais

Seguem etapas adicionais a serem realizadas após a execução dos procedimentos já descritos anteriormente.

Cópia de chaves de segurança

No servidor principal, em /opt/shibboleth-idp/credentials, copie os arquivos a seguir para a mesma pasta no servidor secundário (sobrescrevendo no secundário os arquivos existentes):

• cafesealer.kver

• cafesealer.jks

Acerto de /etc/hosts

Em ambientes redundantes, precisamos garantir que os componentes em cada servidor comuniquem entre si de forma adequada.

Como as configurações são realizadas através da definição do FQDN, caso o DNS resolva um IP diferente a cada vez, isso pode ser um problema.

Assim é necessário editar o arquivo /etc/hosts de cada servidor para forçar que o servidor sempre resolva para o próprio IP.

Exemplo: Suponha IDP redundante de FQDN idp.instituicao.br que tem o servidor principal com IP 1.1.1.1 e o IP do servidor secundário seja 2.2.2.2.

Para este caso hipotético, teremos:

Servidor principal - /etc/hosts terá uma entrada como:

1.1.1.1 idp.instituicao.br

Servidor secundário - /etc/hosts terá uma entrada como:

2.2.2.2 idp.instituicao.br

Certificado SSL

Nos casos em que o servidor secundário se comunica com o primário, excepcionalmente o apontamento é realizado diretamente via IP.

Por conta deste requisito, é necessário que o certificado do servidor IDP contenha no alternative names uma entrada para 1.1.1.1 (no exemplo que estamos considerando como cenário).

O exemplo a seguir como deveria ser o arquivo de configuração do certificado a ser gerado com a informação do IP no alternative names para o cenário que estamos considerando como exemplo.

[req]

distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no

[req_distinguished_name]

C = BR
ST = DF
L = DF
O = Instituicao
OU = Instituicao
CN = idp.instituicao.br

[ v3_req ]

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]

IP.1 = 1.1.1.1
DNS.1=idp.instituicao.br

Operando o MFA

Gerenciando o serviço do painel de segurança

• systemctl stop mfa.service: para o serviço

• systemctl status mfa.service: verifica o status do serviço

• systemctl start mfa.service: inicia o serviço

Verificando os logs

• Painel de segurança: /opt/dashboard/logs

• Shibboleth: /opt/shibboleth-idp/logs/mfa-plugins.log (onde são logados dados específicos associados ao MFA)

Dúvidas frequentes

1. Ocorreu um erro durante a execução do script, o que devo fazer?

Copie o texto de erro (copiar tudo que apareceu na tela) e encaminhe para o e-mail [e-mail] para análise do erro.