3.1 Criptografia simétrica: a base do volume

A criptografia simétrica permanece como a principal solução para proteção 
de grandes massas de dados. Sabe-se da alta performance e sua adequação para 
volumes extensos, mensagens longas e armazenamento persistente. 

Em saúde, isso significa seu emprego natural em bancos de dados clínicos, arquivos de 
imagem, backups, discos de estações de trabalho, repositórios em nuvem e outros 
contextos em que o dado precisa ser protegido em escala e com eficiência.

3.2 Criptografia assimétrica: a base da identidade e da confiança

A criptografia assimétrica introduz outra lógica. Em vez de uma única chave compartilhada, 
trabalham-se duas chaves distintas: uma pública e outra privada. Quando se cifra com a 
chave pública do destinatário, garante-se confidencialidade; quando se utiliza a chave 
privada do emissor em um mecanismo de assinatura, garante-se autenticidade e se 
estabelece a base para o não repúdio. 

Relevante é exatamente demonstrar  como a chave pública pode ser amplamente compartilhada, 
enquanto a chave privada precisa permanecer protegida.

Em termos arquiteturais, isso significa que a criptografia assimétrica não é o motor do
grande volume de dados, mas sim da identidade, da assinatura, dos certificados, do 
estabelecimento inicial de confiança e da troca segura de segredos.

3.3 RSA, ECC e Diffie-Hellman

A literatura descreve o RSA como paradigma clássico baseado na dificuldade computacional 
de fatorar grandes números, apresenta as curvas elípticas como alternativa mais eficiente em 
processamento e tamanho de chave, e situa o Diffie-Hellman como mecanismo de estabelecimento 
de segredo compartilhado sem transmissão direta da chave simétrica. 

Esses três elementos não competem entre si de forma simplista; eles cumprem funções distintas
dentro da arquitetura.

O RSA historicamente ocupa lugar importante em cenários de confidencialidade e certificação. 

O ECC ganha relevância onde há restrição de processamento, energia e largura de banda, como 
em DMIA e sistemas embarcados. 

O Diffie-Hellman, sobretudo em versões com curvas elípticas, torna-se peça crucial para negociação 
segura de chaves de sessão em comunicações modernas.

4. Por que a arquitetura importa mais do que o algoritmo isolado

Um dos erros mais comuns em segurança é imaginar que a simples presença de um algoritmo “forte” 
resolve o problema. Não resolve.
Um algoritmo excelente, mal posicionado, mal governado ou aplicado ao contexto errado produz uma falsa 
sensação de proteção.

Em saúde, esse erro se agrava porque o impacto não se limita ao plano informacional. Uma falha arquitetural 
pode resultar em:
1.	vazamento de dados sensíveis;

2.	adulteração silenciosa de parâmetros clínicos;

3.	perda de validade documental;

4.	contestação jurídica de um ato profissional;

5.	indisponibilidade de sistemas em momento crítico;

6.	e contaminação de fluxos decisórios baseados em IA.

O foco deste artigo é demonstrar como cada um deles deve ser alocado 
no lugar correto dentro da cadeia assistencial.

5. Arquitetura criptográfica aplicada aos principais domínios clínicos

5.1 Prontuário Eletrônico do Paciente

O prontuário eletrônico exige proteção em múltiplas camadas. 

O dado precisa estar cifrado em repouso, protegido em trânsito entre módulos, submetido
a controle rigoroso de acesso, vinculado a identidade profissional legítima e acompanhado 
de trilhas de auditoria confiáveis.

A arquitetura ideal, nesse caso, não se apoia em uma única técnica. Ela combina:
1.	criptografia simétrica para o volume de dados armazenados;

2.	criptografia assimétrica para certificados, assinatura digital e autenticação;

3.	negociação segura de sessão para comunicação entre componentes;

4.	políticas de gestão de chaves compatíveis com a criticidade do ambiente.

Assim, o prontuário não é apenas um banco de dados “criptografado”; ele se torna um 
repositório clinicamente confiável.

5.2 Telemedicina

A telemedicina reúne desafios particulares porque o fluxo ocorre em tempo real e envolve 
múltiplos artefatos simultâneos: 
1. voz
2. vídeo
3. mensagen
4. anexos
5. documentos
6. prescrições
7. autenticação profissional 

A arquitetura precisa:
1. priorizar confidencialidade do canal
2. autenticidade das pontas
3. integridade do conteúdo
4. validade documental posterior
 
Destaca-se o papel do TLS 1.3 como evolução mais eficiente e recomendada dos 
protocolos anteriores, com handshake mais rápido e menor número de fases. 

Em contexto de telemedicina, isso significa:
1. menor sobrecarga, 
2. melhor desempenho 
3. maior adequação a sessões interativas. 

Já o mTLS ganha relevância quando ambos os lados precisam provar sua identidade, o que é 
altamente pertinente em cenários institucionais sensíveis.

5.3 PACS/RIS e imagem médica

Exames de imagem circulam entre setores, servidores, estações de laudo, especialistas 
externos e, em muitos casos, ambientes híbridos ou em nuvem. 

Isso exige não apenas sigilo, mas também garantia de integridade e autenticidade dos artefatos. 
A imagem médica, em certos cenários, possui valor diagnóstico, documental e até pericial. 

Por isso, uma arquitetura criptográfica madura para PACS/RIS deve contemplar:
1.	cifragem em repouso dos repositórios;

2.	canais protegidos de transmissão;

3.	autenticação forte entre sistemas;

4.	preservação da integridade de exames e metadados;

5.	auditoria das operações críticas.

5.4 DMIA, IoMT e sistemas embarcados

Os DMIA introduzem outra camada de complexidade. Muitos operam com restrições severas 
de energia, memória, latência e processamento. 

Nesse contexto, se destaca a vantagem das curvas elípticas, especialmente pela possibilidade 
de usar chaves menores com boa segurança e melhor eficiência computacional.

Essa observação tem enorme relevância para monitores, bombas de infusão, gateways clínicos,
wearables, sistemas embarcados e edge devices hospitalares. 

Nesses ecossistemas, o ECC e variantes modernas de troca de segredo oferecem desempenho 
mais compatível com a realidade operacional, sem que se abdique da proteção necessária.

5.5 Integração hospitalar, APIs e nuvem

À medida que os hospitais se tornam ambientes conectados por APIs, microsserviços, plataformas 
em nuvem e barramentos de interoperabilidade, a criptografia precisa sair da borda e entrar na 
própria malha de comunicação interna e externa. 

Não basta proteger o portal visível ao usuário; é necessário proteger também a conversa entre 
sistemas.

Nesses cenários, o mTLS merece destaque, pois ao contrário do TLS tradicional, ele exige que ambos 
os lados apresentem e validem seus certificados, tornando-se especialmente interessante quando 
duas soluções precisam provar mutuamente sua legitimidade. 

Em fluxos que envolvem dados clínicos, financeiros, regulatórios ou assistenciais sensíveis, essa proteção 
adicional deixa de ser luxo e passa a ser uma exigência de maturidade.

6. Protocolos e sua leitura técnico-clínica

# 6.1 SSH
É um protocolo que estabelece uma conexão segura a partir de: 

1. negociação de versão,

2. algoritmos suportados, 

3. geração de par de chaves,

4. derivação de chave de sessão para a comunicação subsequente. 

Em termos hospitalares, isso se traduz em:

1. administração segura de servidores, 

2. acesso controlado a ambientes críticos, 

3. manutenção técnica de infraestruturas sensíveis,

4. operações de engenharia clínica ou de TI que não podem trafegar em texto puro.

# 6.2 GPG/PGP
O GPG/PGP combina: 

1. criptografia simétrica para o conteúdo, 

2. criptografia assimétrica para proteger a chave simétrica,

3. assinatura digital para garantir autenticidade. 

Essa arquitetura híbrida é extremamente elegante e ajuda a compreender como proteger:

1. documentos clínicos, 

2. pareceres, 

3. artefatos de pesquisa, 

4. evidências técnicas,

5. comunicações sensíveis entre profissionais ou instituições.

# 6.3 TLS 1.3
O TLS 1.3 é hoje uma das peças mais relevantes da segurança em trânsito.  
A versão atual superou as anteriores ao:

1. integrar handshake mais enxuto, 

2. ter maior eficiência ,

3. possuir suporte a mecanismos modernos. 

Em saúde, ele se aplica a:

1. portais clínicos, 

2. prontuários web, 

3. telemedicina, 

4. integrações HTTPS, 

5. APIs

6. diversos canais de comunicação entre aplicações.

# 6.4 mTLS
Quando ambas as partes precisam provar identidade de forma explícita, o mTLS se torna 
particularmente valioso. 
A lógica é simples, mas poderosa: o cliente valida o servidor, e o servidor também valida o 
cliente. 
Em ecossistemas hospitalares distribuídos, esse modelo eleva significativamente a confiança 
das integrações entre serviços críticos. 
Ele esta sendo particularmente indicado para contextos de alta sensibilidade, o que se aplica 
diretamente à saúde digital.

7.1 Cenário – Teleconsulta com emissão de prescrição digital

Um médico realiza atendimento remoto, acessa exames prévios, revisa o prontuário 
e emite prescrição eletrônica ao final da consulta. 
O canal deverá estar protegido por:

1. validação adequada de certificados,

2. autenticação robusta das partes,

3. assinatura digital do documento.

Sem estas camadas de proteção o canal esta protegido apenas superficialmente, 
e o problema não será apenas um possível vazamento. Poderá haver: 

1. contestação da autoria,

2. fragilidade jurídica do ato,

3. comprometimento da confiança institucional.

7.2 Cenário – UTI conectada a gateway clínico

Monitores multiparamétricos, ventiladores e bombas de infusão enviam dados 
continuamente a um gateway que consolida informações e as remete ao prontuário e 
a painéis de apoio à decisão. Nesse cenário, a arquitetura criptográfica precisa:

1. impedir falsificação de identidade de dispositivo,

2. interceptação de parâmetros,

3. adulteração de dados em trânsito,

4. aceitação de conexões indevidas.

O valor assistencial do sistema depende diretamente da confiabilidade do 
fluxo criptográfico.

7.3 Cenário – PACS em nuvem híbrida

Exames são:

1. adquiridos localmente, 

2. armazenados em ambiente híbrido,

3. acessados por equipes remotas ou especialistas externos. 

Para ser considerada estruturalmente completa a arquitetura deverá proteger:

1. o armazenamento,

2. a autenticidade das integrações,

3. a integridade dos artefatos.

Imagem médica não pode ser apenas sigilosa; precisa ser confiável.

7.4 Cenário – API clínica com motor de IA

Um sistema hospitalar envia variáveis clínicas para um serviço de IA que retorna 
score de risco, categorização ou priorização. A API deverá :

1. trafegar por um canal tecnicamente funcional, 

2. ter autenticação forte mútua, 

3. possibilitar rotação de certificados,

4. utilizar trilhas adequadas.

Do contrário o risco será aceitar respostas oriundas de contexto não plenamente 
legítimo ou tornar impossível a reconstrução posterior da cadeia decisória.

8. Representações em linguagem de computação

Os exemplos a seguir são didáticos. Não substituem hardening real, PKI institucional, 
HSM/KMS, gestão de ciclo de vida de certificados ou revisão de segurança em produção.

8.1 Política mínima para API clínica com autenticação mútua

JSON
{
  "servico": "api_painel_risco_clinico",
  "classificacao": "dado_clinico_sensivel",
  "transporte": {
    "protocolo": "TLS_1_3",
    "mtls": true,
    "certificados_validos_em_ambas_as_partes": true
  },
  "negociacao_de_segredo": {
    "metodo": "ECDHE",
    "chaves_efemeras": true
  },
  "protecao_em_repouso": {
    "algoritmo": "AES-256",
    "gestao_de_chaves": "KMS_ou_HSM"
  },
  "controles_complementares": {
    "rotacao_de_certificados": true,
    "logs_integros": true,
    "auditoria": true
  }
}

8.2 Validador conceitual de confiança documental

Python
def validar_documento_clinico(certificado_valido,
                              assinatura_valida,
                              integridade_ok,
                              emissor_autorizado,
                              trilha_auditoria_ok):
    if not certificado_valido:
        return "BLOQUEAR: certificado não confiável."
    if not assinatura_valida:
        return "BLOQUEAR: assinatura digital inválida."
    if not integridade_ok:
        return "BLOQUEAR: documento alterado."
    if not emissor_autorizado:
        return "BLOQUEAR: emissor sem privilégio compatível."
    if not trilha_auditoria_ok:
        return "RETER: documento sem rastreabilidade adequada."
    return "ACEITAR: documento íntegro, autêntico e auditável."

8.3 Fluxo arquitetural resumido para telemedicina segura

profissional_autenticado
    -> validacao_de_certificados
    -> estabelecimento_tls_1_3
    -> negociacao_de_segredo_efemero
    -> sessao_simetrica
    -> acesso_controlado_ao_prontuario
    -> emissao_de_documento_assinado
    -> armazenamento_cifrado
    -> trilha_de_auditoria

8.4 Estrutura conceitual para DMIA com restrição de recursos

JSON
{
  "dispositivo": "gateway_monitorizacao_uti",
  "restricoes_operacionais": {
    "memoria_limitada": true,
    "energia_limitada": true,
    "latencia_critica": true
  },
  "arquitetura_criptografica": {
    "identidade": "certificado_com_chave_ecc",
    "troca_de_segredo": "ECDHE",
    "sessao_de_dados": "AES-GCM",
    "assinatura_de_update": "ECDSA"
  },
  "politicas": {
    "boot_confiavel": true,
    "verificacao_de_firmware": true,
    "rotacao_de_chaves": true
  }
}

9. Matriz

|Ameaça arquitetural|Impacto clínico possível|Controle recomendado|

|Certificado inválido ou mal validado|conexão com parte não legítima|validação rigorosa da 
cadeia de confiança, rotação e monitoramento|

|TLS sem autenticação robusta em integração sensível|confiança parcial e risco de comunicação
insegura|mTLS entre serviços críticos|

|Exposição de chave privada|perda de confidencialidade, autenticidade e não repúdio|HSM/KMS,
segregação, proteção física e lógica, rotação|

|Uso inadequado de assimetria para grandes volumes|degradação de desempenho e arquitetura
ineficiente|assimetria para identidade e troca de segredo; simetria para massa de dados|

|DM restrito usando mecanismo pesado|latência, falha operacional, consumo excessivo|ECC e
mecanismos eficientes compatíveis com edge e IoMT|

|Ausência de logs íntegros|dificuldade de auditoria, investigação e correção|retenção segura, 
correlação de eventos e trilha confiável|

|Ausência de estratégia pós-quântica|exposição futura e obsolescência|criptográfica	inventário
criptográfico e plano de transição|

10. O papel estratégico do médico

O profissional de saúde não precisa se transformar em matemático, criptógrafo ou administrador 
de chaves para exercer medicina de excelência. Precisa, entretanto, alcançar um grau mínimo de 
letramento tecnológico que lhe permita entender o suficiente para não ser refém de sistemas que 
condicionam a validade do próprio cuidado.

Esse ponto é coerente com a trajetória já consolidada nos artigos anteriores, especialmente quando 
se reconhece que Linux, cibersegurança, governança, criptografia e IA não podem mais ser tratados 
como assuntos estranhos à responsabilidade clínica contemporânea. 

O médico que compreende a função arquitetural de cada peça deixa de enxergar a tecnologia como 
“caixa-preta funcional” e passa a avaliá-la como infraestrutura crítica do ato assistencial.

Em outras palavras: a boa prática médica na era digital não exige onisciência técnica, mas sim
maturidade suficiente para reconhecer:

1. dependências,

2. limites,

3. riscos, 

4. fragilidades,

5. implicações éticas dos sistemas utilizados.

11. A questão pós-quântica: leitura técnica sem alarmismo

Foi bem destacado a criptografia pós-quântica e o impacto potencial da computação quântica sobre 
algoritmos assimétricos baseados em problemas matemáticos atualmente difíceis, como a fatoração 
do RSA e o logaritmo discreto em curvas elípticas. 

O ponto mais maduro dessa abordagem é justamente evitar o sensacionalismo: não se trata de um 
colapso instantâneo e universal, mas de um tema de governança, planejamento e transição.

Para o setor da saúde, essa reflexão possui valor especial, porque muitos dados clínicos mantêm 
sensibilidade prolongada. Isso significa que a discussão pós-quântica interessa não apenas à 
segurança do presente, mas também à durabilidade da confidencialidade e da confiança documental 
ao longo do tempo.

A resposta madura, portanto, não é pânico, mas estratégia:

1.	inventariar dependências criptográficas; 

2.	identificar sistemas mais expostos;

3.	adotar chaves robustas quando cabível;

4.	preparar rotas de migração;

5.	acompanhar a maturação dos algoritmos resistentes ao cenário pós-quântico.

12. Considerações Finais

A grande tese deste artigo pode ser formulada de maneira objetiva: em saúde digital, a 
segurança não depende apenas da existência de criptografia, mas da qualidade do seu 
posicionamento arquitetural ao longo do fluxo clínico-tecnológico.

Prontuários eletrônicos, telemedicina, PACS, APIs, nuvem, integrações hospitalares e 
DMIA não exigem um algoritmo isolado milagroso. Exigem combinação coerente entre:
1.	criptografia simétrica para o volume de dados;

2.	criptografia assimétrica para identidade, troca segura de segredos e assinatura;

3.	protocolos modernos para o canal;

4.	certificados para confiança;

5.	governança para sustentação do sistema ao longo do tempo.

Se o primeiro artigo desta série demonstrou que a criptografia é fundamento da segurança 
assistencial, este segundo artigo estabelece o passo seguinte: a assistência moderna só é realmente 
protegida quando a criptografia deixa de ser conceito e se transforma em arquitetura.

13. Perspectiva para o Artigo 3 de 4

O próximo artigo da série poderá aprofundar um eixo particularmente estratégico: 

1. criptografia em DMIA, 

2. firmware, 

3. atualização segura, 

4. cadeia de confiança,

5. edge computing,

6. identidade do dispositivo

7. segurança operacional no ecossistema IoMT hospitalar. 

Essa sequência mantém plena coerência com a trajetória anunciada 
no Artigo 1 e com o eixo técnico consolidado pelo conteúdo deste módulo.

Oii, Ricardo! Tudo bem?

É impressionante como você elevou o nível desta série. Se no primeiro artigo você estabeleceu a criptografia como um pilar ético, neste segundo você apresentou a Planta Baixa dessa segurança. Você não está apenas estudando algoritmos; você está desenhando como a confiança é distribuída em um organismo hospitalar complexo.

Sua distinção entre o papel da Criptografia Simétrica (o "músculo" que processa o grande volume de dados do PACS) e a Criptografia Assimétrica (o "sistema de identidade" que valida quem é o médico e quem é o paciente) é a base de qualquer arquitetura de nuvem moderna.

Parabéns pela profundidade técnica e pelo rigor na declaração de autoria e conformidade. Você está construindo uma referência de como o letramento tecnológico pode transformar a segurança do paciente.

Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!

Olá, Lorena.
Agradeço pela análise e pela sugestão, ambas estão ótimas.
Ricardo