Skip to main content
Uma versão mais recente deste produto está disponível.
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Diretrizes de reforço para TLS e SSH no StorageGRID

PDFs

Você deve controlar o acesso SSH, substituir os certificados TLS padrão e selecionar a política de segurança apropriada para conexões TLS e SSH.

Diretrizes de reforço para certificados

Você deve substituir os certificados padrão criados durante a instalação por seus próprios certificados personalizados.

Para muitas organizações, o certificado digital autoassinado para acesso à Web do StorageGRID não está em conformidade com suas políticas de segurança da informação. Em sistemas de produção, você deve instalar um certificado digital assinado por uma CA para uso na autenticação do StorageGRID.

Especificamente, você deve usar certificados de servidor personalizados em vez destes certificados padrão:

  • Certificado da interface de gerenciamento: Usado para proteger o acesso ao Grid Manager, ao Tenant Manager, à Grid Management API e à Tenant Management API.

  • Certificado da API S3: Usado para proteger o acesso aos nós de armazenamento e nós de gateway, que os aplicativos cliente S3 utilizam para carregar e baixar dados de objetos.

Veja "Gerenciar certificados de segurança" para obter detalhes e instruções.

Observação StorageGRID gerencia os certificados usados para os endpoints do balanceador de carga separadamente. Para configurar os certificados do balanceador de carga, consulte "Configurar pontos de extremidade do balanceador de carga".

Ao usar certificados de servidor personalizados, siga estas diretrizes:

  • Os certificados devem ter um subjectAltName que corresponda às entradas DNS para StorageGRID. Para obter detalhes, consulte a seção 4.2.1.6, "Subject Alternative Name", em "RFC 5280: Perfil de Certificado e CRL PKIX".

  • Sempre que possível, evite o uso de certificados curinga. Uma exceção a essa diretriz é o certificado para um endpoint virtual hospedado no S3, que exige o uso de um certificado curinga caso os nomes dos buckets não sejam conhecidos antecipadamente.

  • Quando for necessário usar curingas em certificados, você deve tomar medidas adicionais para reduzir os riscos. Use um padrão de curinga como *.s3.example.com, e não use o sufixo s3.example.com para outros aplicativos. Esse padrão também funciona com acesso ao S3 no estilo de caminho, como dc1-s1.s3.example.com/mybucket.

  • Defina os prazos de expiração dos certificados para valores curtos (por exemplo, 2 meses) e use a API de Gerenciamento de Grid para automatizar a rotação de certificados. Isso é especialmente importante para certificados curinga.

Além disso, os clientes devem usar verificação rigorosa de nome de host ao se comunicarem com StorageGRID.

Diretrizes de reforço para políticas de TLS e SSH

Você pode selecionar uma política de segurança para determinar quais protocolos e cifras são usados para estabelecer conexões TLS seguras com aplicativos cliente e conexões SSH seguras com serviços internos do StorageGRID.

A política de segurança controla como o TLS e o SSH criptografam os dados em trânsito. Como prática recomendada, você deve desativar as opções de criptografia que não são necessárias para a compatibilidade do aplicativo. Use a política Modern padrão, a menos que seu sistema precise estar em conformidade com Common Criteria, FIPS 140-2 ou que você precise usar outras cifras.

Veja "Gerencie a política de TLS e SSH" para obter detalhes e instruções.

Gerenciar acesso SSH externo

Para aumentar a segurança do sistema, o acesso SSH externo é bloqueado por padrão. Habilite o acesso SSH somente quando você precisar executar tarefas que exijam acesso SSH de entrada, como solução de problemas. Consulte "Gerenciar acesso SSH externo" para obter detalhes e instruções.