| Camada | Exemplo | Relevância de Segurança|

| Pessoa	| Médico, enfermeiro, recepcionista, analista	| Perfil funcional, 
vínculo e responsabilidade| 

| Dispositivo| 	Estação clínica, tablet institucional, notebook	| Equipamento conhecido,
íntegro e homologado| 

| Aplicação	| PEP, PACS, portal de resultados, telemedicina	| Controle do que pode 
ser lido, alterado ou exportado| 

3. Controle de acesso: grupos, papéis e privilégio mínimo

Em instituições maduras, permissões não devem ser distribuídas aleatoriamente nem herdadas 
por conveniência pessoal. 

O modelo mais sólido parte da noção de grupos e papéis, aproximando-se do RBAC (Role-Based 
Access Control). 

# 3.1 Grupos e papeis
Nele, a pessoa recebe um papel aderente à sua função — e não um conjunto artesanal de privilégios 
desconexos. Isso produz benefício duplo. 

1.	Primeiro: 
•	reduz o risco de excesso de acesso. 

2.	Segundo, facilita: 
•	revisão periódica, 
•	substituição de pessoal, 
•	desligamentos, 
•	cobertura de plantão,
•	auditoria institucional.

# 3.2 Política dos Privilégios Mínimos
1. Privilégio mínimo: 
•	cada usuário deve receber apenas o acesso estritamente necessário para executar sua atividade.

2. Segregação de funções:
•	quem cadastra não deve necessariamente aprovar; 
•	quem aprova não deve necessariamente excluir rastros.

3. Revisão cíclica:
    Deve assegurar repercussão correta no acesso quando ocorrer:
•	transferências internas, 
•	afastamentos, 
•	trocas de setor,
•	desligamentos.

4. Papéis clínicos não equivalem a acesso ilimitado: 
•	senioridade médica não justifica visualização irrestrita de tudo.

Cenário ilustrativo 1

Se uma pessoa responsável apenas por agendar exames consegue ler laudos, editar dados 
clínicos ou exportar listas de pacientes, a instituição não possui apenas um problema tecnológico; 
ela possui um problema de governança assistencial e jurídica.

4. Login seguro e autenticação forte

O login contemporâneo deve ser entendido como um processo de comprovação graduada, e não como 
um único campo de senha. A autenticação forte combina evidências distintas: 
1.	algo que a pessoa sabe,

2.	algo que possui,

3.	algo que é (quando apropriado).

Isso significa que diferentes ações podem exigir diferentes níveis de prova. Por exemplo:
1.	Autenticação basal:
•	consultar uma agenda. 

2.	Autenticação multifator (MFA), biometria ou chave física:
•	liberar resultado crítico, 
•	redefinir senha, 
•	acessar dados altamente sensíveis,
•	validar condutas administrativas relevantes 

|Fator|	Exemplo	|Observação|

|Algo que sabe|	Senha, frase-senha	|Mais simples, porém mais exposto a vazamento e reutilização|

|Algo que possui|Token OTP, chave física, dispositivo confiável	|Aumenta proteção contra roubo remoto 
de credenciais |

|Algo que é	|Biometria facial, digital, voz	|Útil como reforço, mas deve ser implementado com cautela|

Cenário ilustrativo 2

Um médico autentica-se corretamente em estação clínica institucional, mas afasta-se por alguns
minutos e mantém a sessão aberta enquanto conversa ao celular. 

Nesse intervalo, um terceiro visualiza dados da tela, anota identificadores e utiliza a sessão já 
autenticada. Aqui, a falha não foi de senha apenas, mas sim de:
1. contexto, 
2. bloqueio de estação, 
3. cultura operacional,
4. disciplina de sessão,
5. negligência ás normas de segurança institucional.

5. Senhas: limites, evolução e uso responsável

A senha permanece importante, mas deixou de ser suficiente como único eixo de proteção. 
A visão madura sobre senhas abandona o teatro da complexidade inútil e privilegia comprimento 
adequado, exclusividade, proteção contra vazamentos e armazenamento robusto no servidor.

Do ponto de vista institucional, a senha não deve ser pensada apenas como hábito do usuário, mas 
como parte de uma arquitetura. Isso inclui:
1.	hash seguro, 

2.	uso de salt, 

3.	derivação resistente,

4.	mecanismos que reduzam o valor de bancos vazados para atacantes.

# 5.1 Do Uso Responsável
1.	Evitar reutilização de senha entre sistemas pessoais e institucionais.

2.	Preferir frases-senha longas a combinações curtas e previsivelmente complexas.

3.	Jamais compartilhar login, token, crachá ou sessão aberta com terceiros.

4.	Associar senha a MFA sempre que o risco da ação justificar.

5.	Bloquear a estação ao se afastar, ainda que por pouco tempo.

# 5.2 Rainbow tables e o erro conceitual clássico
Quando o sistema armazena apenas hashes fracos e sem salt, um vazamento pode ser explorado 
por tabelas pré-computadas. Em termos simples: o atacante não precisa adivinhar sua senha do 
zero; ele consulta correspondências já conhecidas.

6. Boas práticas operacionais para equipes de saúde

Segurança em saúde depende tanto de desenho técnico quanto de comportamento humano. 
Em muitos casos, o elo mais perigoso não é um algoritmo fraco, mas uma rotina improvisada.

|Má prática	|Impacto clínico-administrativo|	Controle recomendado |

|Compartilhar credenciais| 	Perda de autoria, rastreabilidade e responsabilização| 	Uso individual e 
intransferível de contas

|Deixar sessão aberta |Visualização indevida, assinatura errada, uso oportunista|	Bloqueio automático 
e bloqueio manual imediato |

|Usar rede ou dispositivo não homologado|	Sequestro de sessão, malware, perda de integridade|	Ambientes 
validados  e segmentados |

|Manter acesso após troca de função	| Excesso de privilégio e abuso interno	|Recertificação periódica 
de acessos|

|Ignorar sinais anormais do sistema	|Persistência silenciosa de incidente|	Registro, escalonamento 
e contingência|

Cenário ilustrativo 3

Em uma unidade de apoio diagnóstico, um residente passa a semana inteira utilizando a estação já 
aberta por outro profissional porque o fluxo está intenso. O atalho parece produtivo, mas compromete 
seriamente:
1.	autoria, 

2.	auditabilidade, 

3.	legitimidade do laudo,

4.	integridade da trilha de responsabilidade. 

O ganho de minutos produz risco institucional de grandes proporções.

7. Representação em linguagem de computação

Abaixo, exemplos simplificados mostram como a lógica de acesso seguro pode ser representada 
em linguagem de computação sem perder aderência à realidade clínica.

# Nota: os códigos abaixo são exemplos meramente ilustrativos, com finalidade didática e 
conceitual. Eles não devem ser interpretados como implementação pronta para produção nem como 
recomendação operacional específica para sistemas reais.

Código 01 - Política simplificada de acesso em ambiente hospitalar

JSON
{
  "politica_acesso_clinico": {
    "usuario": "medico_assistente",
    "setor": "UTI",
    "mfa_ativo": true,
    "dispositivo_homologado": true,
    "sessao_integra": true,
    "acao_permitida": [
      "visualizar_paciente_do_setor",
      "registrar_evolucao",
      "solicitar_exame"
    ],
    "acao_negada": [
      "exportar_base_completa",
      "excluir_logs",
      "alterar_permissoes_globais"
    ],
    "reautenticacao_exigida_para": [
      "assinar_laudo_critico",
      "redefinir_senha",
      "acessar_dados_sensiveis_em_lote"
    ]
  }
}

Código 02 - Exemplo didático de derivação de senha e autorização contextual

Python
from hashlib import pbkdf2_hmac
from os import urandom
from typing import Dict, Tuple, Any

def gerar_hash_seguro(senha: str) -> Tuple[str, str]:
    """Exemplo didático: deriva uma chave a partir de uma senha usando PBKDF2-HMAC."""
    salt = urandom(16)
    derivacao = pbkdf2_hmac("sha256", senha.encode(), salt, 200_000)
    return salt.hex(), derivacao.hex()

def autorizar(usuario: Dict[str, Any], acao: str, contexto: Dict[str, Any]) -> bool:
    """Exemplo didático: autorização baseada em estado do usuário e contexto da sessão."""
    if not usuario.get("ativo", False):
        return False
    if contexto.get("sessao_bloqueada", False):
        return False
    if acao in usuario.get("acoes_sensiveis", []) and not contexto.get("mfa_ativo", False):
        return False
    if not contexto.get("dispositivo_homologado", False):
        return False
    return acao in usuario.get("permissoes", [])

Código 03 - Regra conceitual de autorização contextual

Pseudocódigo
SE usuário autenticado
   E dispositivo homologado
   E papel compatível com a ação
   E paciente dentro do escopo assistencial
   E sessão íntegra
   E (se ação sensível, MFA ativo)
ENTÃO permitir
SENÃO negar, registrar evento e reavaliar risco

8. Leitura clínica do problema

Para o profissional da saúde, o ponto decisivo é compreender que controle de acesso 
não pertence apenas ao domínio da TI. Ele participa da própria qualidade assistencial. 
Quem visualiza indevidamente um exame, altera um dado sem legitimidade, assina sob 
sessão alheia ou ignora a necessidade de bloqueio da estação não comete apenas uma 
infração técnica: compromete sigilo, confiança, cadeia de responsabilidade e potencialmente 
o cuidado.

Em ambientes progressivamente assistidos por IA, essa exigência se torna ainda maior. 
Sistemas inteligentes ampliam velocidade, capacidade de integração e volume de dados 
processados. Se a governança de identidade e acesso for fraca, a própria potência da 
infraestrutura passa a multiplicar o dano.

9. Considerações finais

O futuro seguro da medicina digital não será construído pela soma desordenada de senhas, telas 
e permissões improvisadas. Ele depende de identidade bem definida, autenticação forte, autorização 
granular, revisão contínua, treinamento institucional e cultura de responsabilidade.

Em síntese, o verdadeiro avanço não está em permitir que todos entrem rapidamente, mas em fazer 
com que cada pessoa acesse apenas o que deve, pelo tempo necessário, no contexto adequado e com 
plena possibilidade de auditoria. Em saúde, esse rigor não representa burocracia improdutiva: representa
proteção ao paciente, ao médico, à instituição e à legitimidade do ato clínico.

Mensagem de encerramento

Segurança não é obstáculo ao cuidado. Quando bem desenhada, é uma forma avançada de respeito clínico. 
Práticas que concedem acesso ilimitado com base em critérios fora das regras institucionais — muitas vezes 
para favorecer alguém — podem configurar condutas ilícitas e, sobretudo, fragilizam toda a infraestrutura 
de segurança da instituição. Por isso, não são aceitáveis nem para quem concede esse acesso, nem para quem 
o recebe. 

Oii, Ricardo! Meus parabéns por esse excelente artigo. É admirável ver um profissional com a sua trajetória na medicina mergulhando tão profundamente na segurança cibernética. O seu texto é um exemplo impecável de como a interdisciplinaridade entre saúde e tecnologia é o caminho para uma medicina digital ética e segura.

A sua abordagem demonstra um domínio técnico de alto nível sobre os pilares de IAM (Identity and Access Management). Ao tratar a segurança não apenas como uma barreira técnica, mas como uma extensão do zelo ético e clínico, o senhor eleva o debate para o campo da governança. O destaque dado à distinção entre autenticação e autorização é fundamental, pois, como bem pontuou, abrir a porta é apenas o primeiro passo; o controle real está no que a identidade pode executar dentro do sistema.

Referências para aprofundamento:

Para complementar essa jornada em Cloud Security e IA, aqui estão links para as documentações oficiais que detalham esses padrões de segurança:

• IAM e Segurança: O guia da Microsoft sobre os princípios de Zero Trust é uma leitura que dialoga perfeitamente com os seus blocos de autenticação e autorização.
  • Documentação Microsoft - Princípios Zero Trust
• Python e Segurança: Para aprofundar na implementação de hashes e criptografia que o senhor exemplificou.
  • Documentação Oficial Python - Módulo hashlib
• Segurança em Nuvem (AWS/Azure): Referências sobre como gerenciar identidades em larga escala.
  • AWS IAM Best Practices

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

Olá Lorena, agradeço sua análise e comentários. Além de didáticos são motivadores e assertivos de que este é o caminho correto:
disciplina para assistir as aulas,
dedicação nos estudos,
paciência ao longo do tempo.
Suas sugestões já foram adequadamente armazenadas e certamente serão lidas com a atenção e olhar daquele que desejar aprender.
Att,
Ricardo