Armazenamento criptografado para o MySQL em cluster

Question

Eu tenho um requisito para fornecer um banco de dados MySQL altamente disponível com criptografia em repouso em um kernel linux 2.6.32. A parte 'altamente disponível' não é tão difícil, mas o 'com criptografia em repouso' está provando ser um desafio quando usado em combinação com HA.

O principal problema vem com a montagem do armazenamento criptografado. Em todos os nossos outros sistemas criptografados em repouso, há um comando que precisa ser executado por um ser humano, que é então solicitado a fornecer a chave de criptografia. Este modelo tem uma falha bastante óbvia quando se trata de um arranjo de cluster onde os serviços terão que iniciar automaticamente .

No momento, estou com uma perda sobre como fornecer criptografia em repouso em um ambiente de alta disponibilidade e também não armazenar senhas importantes no mesmo sistema.

Eu posso ver dois cenários possíveis, um dos quais funcionará com o meu ambiente, mas não tenho certeza dos detalhes para fazê-los funcionar. Ou mesmo que seja possível.

Cenário 1: CLVM & Cluster

• Um volume é compartilhado entre meus membros de cluster.
• Este volume está configurado aproximadamente:
  Material de cryptsetup
  • no dispositivo físico
  • Material do LVM no novo dispositivo de criptografia
• Os Serviços de cluster são configurados para não ingressarem no cluster automaticamente, contando com uma intervenção manual.
• Os Serviços de Cluster são iniciados por meio do comando executado por um humano, que fornece a chave de descriptografia, que, por sua vez, ativa o material do CLVM.

Desta forma, os nós em execução têm acesso ao volume do CLVM para que possam iniciar serviços quando instruídos pelo gerenciador do cluster. As reinicializações de nós ainda precisarão de um ser humano, e a frase secreta da cripta nunca é mantida no disco em lugar algum.

Cenário 2: DRBD & Cluster

• Um volume é criado em cada membro do cluster
Material de cryptsetup
• é executado no dispositivo físico
• o drbd é configurado na parte superior do dispositivo criptografado, para replicá-lo entre cada nó
• O LVM ou um sistema de arquivos é colocado no topo do volume drbd
• Os Serviços de cluster são configurados para não ingressarem no cluster automaticamente, contando com uma intervenção manual.
• Os serviços de cluster são iniciados por um ser humano que fornece a chave de descriptografia, que, por sua vez, torna o LVM (ou sistema de arquivos) visível, mas não montado.

Assim como na configuração do CLVM, os nós não entram no cluster até que tenham visibilidade do armazenamento presumivelmente compartilhado.

O problema é que não tenho certeza se algum dos itens acima funciona dessa maneira. Ambos supõem que é possível colocar em camadas um PV do LVM sobre um volume criptografado (por exemplo, pvcreate /dev/mapper/cryptmysql ). Isso pode não ser possível.

    

Answer 1

O principal desafio parece ser a intervenção humana para entrada de chave. Há alguma ajuda para isso: o dm-crypt tem suporte para o TPM que pode estar disponível em sua plataforma. Consulte este projeto IBM para detalhes de configuração . Também LUKS / cryptsetup suporta a leitura de uma chave de slot do arquivo / de stdin. Se você puder armazenar sua chave com segurança em algum lugar ( como em um cartão inteligente ), isso pode ser uma opção viável.

Quanto à sua pergunta se você pode ter um PV do LVM em um volume dm-crypt: você pode precisar de uma execução de pvscan / vgchange -a -y após o desbloqueio do slot. Nós rodamos esse tipo de configuração com Kernels muito mais antigos, alguns anos atrás. No final, nós o abandonamos em favor do uso de SEDs para aplicativos com requisitos de criptografia de dados em repouso devido a razões de desempenho (dm-crypt usado para empregar um único thread por dispositivo criptografado naquele momento, o que levou a um gargalo da CPU em nossa configuração).

    

Answer 2

Acontece que isso é totalmente factível com o LVM como syneticon-dj sugerido. Desde então, verifiquei que ele funciona nas configurações do cluster. No entanto, isso não é tão fácil quanto você pensa.

Antes que os grupos de volumes cLVM fiquem visíveis, ele deve ser descriptografado via cryptsetup luksOpen no dispositivo que precisa de criptografia. Isso, por necessidade, acontece depois que os serviços de cluster são iniciados, portanto, qualquer recurso baseado nele não deve ser membro de nada crítico, como um dispositivo stonith.

Configurar o cluster é o mesmo de sempre, mas algumas diferenças:

• É uma boa ideia ter um segundo dispositivo de armazenamento no cluster que NÃO esteja criptografado, o que poderia ser usado pelo stonith (external/sbd type ).
• Crie o recurso clvm quando todos os nós tiverem o volume criptografado aberto por meio do mesmo comando cryptsetup e mapeado para o mesmo nome de dispositivo (por exemplo, cryptsetup luksOpen /dev/sdd cryptmysql )
• Crie o grupo de volumes em cluster no dispositivo criado por cryptsetup (por exemplo, vgcreate ClusterMySQLVG /dev/mapper/cryptmysql )
• Crie um script bash simples para executar a descriptografia da mesma maneira todas as vezes, isso será usado por um operador após a reinicialização para obter o volume acessível.

Como um nó requer intervenção manual para ser elegível para failover, é uma boa ideia ter mais de dois nós no cluster de failover.

Uma vez que o volume do grupo e os volumes lógicos são criados normalmente, instale o MySQL. Neste ponto, a instalação é executada de acordo com as instalações normais de armazenamento em cluster.

Quando um nó é reiniciado:

1. Os serviços de cluster serão iniciados na inicialização e o nó ingressará no cluster. No entanto, como ele não tem visibilidade para o volume do MySQL, ele não será elegível para failover.
2. Um operador se conecta ao nó por meio do ssh e executa o script de decriptografia criado acima, que solicita a chave de descriptografia.
3. O script é executado e cria o mapeamento necessário em /dev/mapper , que o LVM então capta.
4. O serviço LVM deve atualizar automaticamente e ver os novos metadados do grupo de volumes.
5. Neste ponto, os serviços de cluster verão que o grupo de volumes MySQL está disponível e o nó será elegível para failover.