Inventário de certificados VPN: o que o registo da CA pode provar
Uma pasta no servidor, um registo da CA, uma lista de revogação e uma tabela de sessões respondem a perguntas diferentes. Mantenha-os separados ao inventariar identidades VPN.
O seu gateway aceita um certificado de cliente que nunca viu, porque aquilo com que está configurado é um emissor de confiança, e o certificado chega durante o handshake. É assim que o protocolo deve funcionar, e é também por isso que uma listagem de diretório no servidor é um inventário fraco. O emissor sabe o que criou, o servidor sabe o que se ligou, e o estado de revogação sabe o que foi retirado. Um inventário que mistura estes três registos acaba por afirmar algo que nenhum deles disse.
O gateway confia num emissor, não numa listagem de ficheiros
A validação compara um certificado apresentado com uma âncora de confiança, pelo que uma identidade criada ontem pelo mesmo emissor se liga sem nunca ter existido no disco do servidor. Nada precisa de ser copiado para que isso aconteça, e ninguém tem de o aprovar à mão. Os registos do próprio servidor descrevem, portanto, chegadas e não a população de identidades que poderiam chegar.
A lacuna inversa é igualmente incómoda. Um diretório pode conter certificados expirados, revogados e identidades emitidas para dispositivos que nunca foram implementados. Contar ficheiros responde a quantos ficheiros existem, que é uma pergunta que ninguém fez. Comece antes pelos registos que têm significado.
Quatro perguntas, quatro registos diferentes
Cada tipo de registo responde bem a uma pergunta e mal às outras, por isso um relatório que os funde parece completo embora esteja errado de uma forma concreta. A tabela abaixo ordena-os pela pergunta que resolvem e não pelo sistema que os produz.
| Question you are answering | Where the answer lives | How quickly it changes | What it will never show |
|---|---|---|---|
| Was this identity ever created? | The issuer's issuance database | Only when something is issued | Whether the device still exists |
| Is a copy sitting on this host? | The paths you actually inspected | Whenever anyone copies files | Certificates that were never copied here |
| Has the issuer withdrawn it? | Published revocation state | When the issuer next publishes | Withdrawals that are not published yet |
| Is it connected right now? | The live session table | Continuously | Anything about past or future sessions |
Um arquivo de certificados públicos não é um segredo, uma vez que não contém chaves privadas, mas também não é partilhável. Os sujeitos e os nomes dos dispositivos revelam detalhes operacionais, e o relatório deve ficar com o público que precisa dele. As chaves privadas ficam completamente fora do inventário, porque o inventário precisa de metadados e não de credenciais.
Emissor e número de série são a única chave estável
Os sujeitos são reciclados e os nomes de ficheiro reutilizados, pelo que um nome que no ano passado identificava um dispositivo pode agora identificar outro. Nenhum deles é uma chave, e um relatório baseado em qualquer um deles acabará por fundir duas identidades numa só linha.
O par emissor e número de série identifica um certificado de forma única, e ambos os campos provêm do próprio certificado. Registe-os com o sujeito, as datas de validade, a fonte de onde veio a cópia e a pessoa ou dispositivo responsável. Acrescente o estado de revogação e de implementação como campos separados, com os seus próprios instantes de observação, porque um certificado dentro da sua janela de validade não fica automaticamente autorizado. Estes dois factos vivem em sistemas diferentes, e fundi-los oculta o caso em que uma identidade foi retirada enquanto o seu ficheiro ainda parece atual.
Leia um certificado de cada vez
Um curinga que se expande por um diretório não é uma interface por lotes, e oculta qual ficheiro produziu que saída. Leia os metadados certificado a certificado, e leia o lado da revogação a partir do seu próprio artefacto. A referência do OpenSSL x509 lista os campos que essas opções imprimem.
openssl x509 -in <cert>.pem -noout -issuer -serial -subject -dates -fingerprint -sha256
openssl crl -in <issuer>.crl -noout -text | head -n 40Para uma PKI Easy-RSA gerida, consulte a base de dados de emissão através do fluxo de trabalho suportado pela ferramenta em vez de presumir uma disposição de diretórios, e mantenha os originais só de leitura enquanto o inventário é montado. O formato do registo é suficientemente regular para contar as entradas válidas e listar as retiradas sem abrir a base de dados à mão.
grep -c '^V' pki/index.txt
grep '^R' pki/index.txt | cut -f4,5Um inventário que sobrevive à próxima emissão
Uma descarga pontual de um diretório fica obsoleta no momento em que o certificado seguinte é emitido, por isso construa o relatório a partir do fluxo de emissão e deixe que se atualize como parte do funcionamento normal. Isso também torna o relatório reproduzível, o que importa quando duas pessoas discordam sobre o que foi emitido.
Use o resultado para decisões de renovação e retirada e não como exercício de folha de cálculo. Apagar uma cópia local não invalida as cópias remotas que já existem. Retire a identidade pelo fluxo de revogação e autorização configurado, e depois registe a retirada com a sua data. Uma identidade que desapareceu do servidor mas em que o emissor ainda confia não foi retirada, e essa diferença separa um inventário exato de um que apenas tranquiliza.