Dúvidas frequentes
Last updated
Was this helpful?
Last updated
Was this helpful?
O CESS é um motor de assinatura que fornece validade jurídica aos documentos assinados digitalmente, por meio do certificado ICP-Brasil.
Para utilizá-lo é necessário um prévio licenciamento da ferramenta. Ademais, o cliente final precisará de um certificado emitido na nuvem ou HSM local.
Nossa ferramenta funciona sobre um container docker, sendo possível ser gerenciada e escalada com o kubernets. Nossa imagem do sistema contém um redis e o motor de assinatura. Todavia, caso o cliente opte por utilize seu redis previante instalado, basta configurar a variável de ambiente redisHost e redisPort. Importante configurar regra de firewall para permitir acesso apenas do container, quando utilizado outro redis a não ser da imagem.
Para mais informações de requisitos, acesse
Depende. O padrão a ser utilizado provém da regra de negócio e finalidade do documento. Por exemplo, para um prescrição eletrônica é necessário uma assinatura PDF. No entanto, para outro fim, um simples CAdES é suficiente. Recomendamos caso tenha alguma dúvida em qual utilizar, contatar um dos nossos colaboradores para entedermos seu negócio e o auxiliar.
Não. Os arquivos assinados pelo motor de assinatura ficam disponíveis apenas enquanto durar o lifetime dos mesmos. Por isso, recomendamos que após a realização da assinatura, a aplicação do cliente realize o download do arquivo e o armazene em algum lugar persistente.
Há duas maneiras de escalá-lo:
Mantendo as instâncias sem compartilhamento de memória e disco (mais recomendada): Para isso, é necessário realizar o download de n imagens do sistema e colocá-las em portas distintas, por exemplo 8080, 8081, 8082 e etc. Após este processo, a aplicação do cliente precisará "manter" o estado daquela transação, ou seja, através de um proxy reverso ele precisa identificar qual foi o nó que recebeu a solicitação na criação da transação e nas requisições seguintes (upload arquivo, consulta transação e download do documento) enviar para o mesmo nó.
Mantendo compartilhamento de memória e disco: Desta forma o cliente não precisará manter o estado da transação. Todavia, é preciso mapear um volume compartilhado entre os nós e um cluster de redis. Apesar desse modelo ser mais simples e fácil de ser implementado, não recomendamos quando há um grande volume de assinaturas diárias (em torno de 80 ~100 mil). Porque a replicação do redis começa ter gargalo, afetando o desempenho da aplicação.
Observação: não provemos failover ou load balance nativamente. Este processo deverá ser realizado pelo cliente.
Sim. O arquivo original não sai da máquina local em nenhum momento. Para realizar a assinatura, apenas o hash do arquivo é enviado à nuvem.
Os casos do disco - da VM - encher são bem raros, pois temos garbage collector que apaga os arquivos assinados quando seu tempo de vida expirar. Todavia se o lifetime estiver configurado com um valor alto e os arquivos não forem apagados a tempo, o container pode travar por falta de espaço. Para resolver este problema, segue os passos abaixo:
Pare o serviço do docker: sudo systemctl stop docker
Remova pasta /var/lib/docker: sudo rm -rf /var/lib/docker/
Inicie o serviço do docker: sudo systemctl start docker
Inicie a aplicação: docker-compose -f <nome do arquivo.yml> up
Isto é uma decisão particular. O objetivo da coleta de informações para nosso monitoramento é auxiliar os clientes na prevenção e identificação de problemas relacionados ao motor de assinatura.
As informações coletadas são do container e não do servidor (físico ou virtual) que hospeda o CESS.
Caso o cliente opte pelo não monitoramento, deverá configurar a variável de ambiente sendMonitoring=false.
Caso seu documento seja uma prescrição eletrônica, deverá validar no site oficial do ITI: .
Caso seu documento não seja uma prescrição eletrônica, mas seja assinado utilizando certificado ICP-Brasil, deverá ser validado no verificador oficial do ITI: .
Para mais detalhes sobre o monitoramento, acesse .