Tópico 4.2 — Gestão de identidade e acesso

Na saúde e nos cuidados, controlar quem pode ver e fazer o quê com o prontuário de um paciente não é uma tarefa doméstica de TI, mas um determinante de linha de frente da segurança clínica, da confidencialidade e da confiança pública.

Por que isso importa na saúde e nos cuidados#

Toda decisão clínica repousa na suposição de que o prontuário diante do clínico é o prontuário certo, pertence ao paciente certo e foi acessado pela pessoa certa. A gestão de identidade e acesso (IAM) é a maquinaria que torna essas três suposições verdadeiras. Quando funciona, um paramédico vê uma alergia a tempo, uma anotação de proteção chega apenas a quem precisa e uma trilha de auditoria consegue responder à pergunta "quem viu este prontuário e por quê?". Quando falha, pacientes são prejudicados por prontuários abertos sob o nome errado, funcionários bisbilhotam parentes ou celebridades e a confiança em todo o empreendimento digital se corrói.

A saúde e os cuidados elevam o que está em jogo acima do caso corporativo comum de três maneiras. Primeiro, os dados estão entre os mais sensíveis que uma pessoa jamais gerará — saúde mental, saúde sexual, uso de substâncias, identidade de gênero, preocupações de proteção —, de modo que uma violação de confidencialidade não é um incômodo, mas um dano duradouro. Segundo, a força de trabalho é móvel, rotativa e multiorganizacional: médicos juniores rodam a cada poucos meses, equipes temporárias e substitutas chegam para um único plantão e o cuidado integrado significa que uma enfermeira distrital pode legitimamente precisar de um prontuário hospitalar. Terceiro, o dever de cuidado não perdoa o atrito: um controle de acesso lento demais às 3 da manhã na ressuscitação é, em si, um perigo para a segurança. A IAM neste setor é, portanto, uma negociação constante entre trancar os dados e deixar a pessoa certa entrar depressa.

Este tópico trata da profundidade de controle de acesso que fica por baixo dos deveres mais amplos tratados no Tópico 1.7 — Governança da informação, proteção de dados e cibersegurança. Onde aquele tópico define o quadro legal e organizacional — o Regulamento Geral sobre a Proteção de Dados do Reino Unido, o Data Security and Protection Toolkit, o dever de confidencialidade —, este trata da mecânica concreta de comprovar a identidade e conceder o menor acesso necessário para fazer o trabalho.

Conceitos centrais#

A gestão de identidade e acesso é a disciplina e o conjunto de tecnologias que garantem que as pessoas certas tenham o acesso certo aos recursos certos no momento certo e que isso possa ser comprovado depois. Repousa numa distinção fácil de borrar e perigosa de perder: a diferença entre autenticação e autorização.

A autenticação responde a "você é quem alega ser?". É comprovada com fatores: algo que você sabe (uma senha ou PIN), algo que você tem (um cartão inteligente, um telefone, um token de hardware) e algo que você é (uma impressão digital ou o rosto). A autorização responde a outra pergunta — "agora que sabemos quem você é, o que você pode ver e fazer?". Um consultor e um recepcionista podem ambos se autenticar perfeitamente, mas estão autorizados a partes muito diferentes de um prontuário. Confundir as duas leva a sistemas que verificam a identidade com rigor e depois deixam todos ver tudo.

A autorização na saúde e nos cuidados costuma ser organizada como controle de acesso baseado em papéis (RBAC), em que as permissões se ligam a papéis — "enfermeiro do pronto-socorro", "clínico geral", "secretário médico" — e as pessoas herdam permissões por ocuparem um papel, em vez de receberem direitos um a um. O RBAC é governado pelo princípio do menor privilégio: cada pessoa, e cada conta de sistema, deve deter o acesso mínimo necessário para fazer o trabalho e nada além. O menor privilégio limita tanto o erro acidental quanto o raio de alcance de uma conta comprometida.

A autenticação moderna reforça a etapa de "comprove quem é" com a autenticação multifator (MFA), combinando dois ou mais fatores para que uma senha roubada, sozinha, não baste. Reduz o atrito com o login único (SSO), em que uma sessão autenticada dá acesso a muitas aplicações sem logins repetidos — um benefício genuíno de segurança quando um clínico precisa circular por uma dúzia de sistemas em uma hora. O SSO entre fronteiras organizacionais depende da identidade federada: uma organização atesta um usuário para que outra possa confiar nele sem guardar suas credenciais.

A infraestrutura da federação e da autenticação moderna é construída sobre padrões abertos. O OAuth é um padrão de autorização delegada — que permite a uma aplicação agir em seu nome sem receber sua senha. O OpenID Connect acrescenta a autenticação sobre o OAuth para que uma aplicação saiba quem é o usuário, e a mais antiga Security Assertion Markup Language (SAML), baseada em XML, faz um trabalho semelhante para o SSO corporativo. O ciclo de vida de uma identidade — a concessão, a alteração e a revogação do acesso à medida que as pessoas entram, mudam e saem — é tratado por processos de provisionamento, comumente chamados de entradas/mudanças/saídas, ou JML (joiners/movers/leavers).

A direção estratégica é a arquitetura de confiança zero (zero trust): a suposição de que nenhum usuário ou dispositivo é confiável meramente por estar dentro da rede. Toda solicitação é autenticada, autorizada e confrontada com o contexto — saúde do dispositivo, localização, sensibilidade dos dados — em vez de depender de um perímetro endurecido. Num setor em que a equipe trabalha em clínicas, casas, ambulâncias e locais de parceiros, o perímetro efetivamente se dissolveu, e a confiança zero nomeia a resposta honesta a isso.

Boas práticas#

  1. Trate a autenticação e a autorização como decisões de projeto separadas. Decida primeiro com que força você precisa comprovar a identidade em um dado sistema e, separadamente, com que finura precisa controlar o que cada papel pode fazer depois. Um login forte num sistema que dá a todos acesso total é falso conforto, e permissões finas atrás de uma senha fraca são igualmente vazias. Documente explicitamente as duas decisões para cada sistema clínico e revisite-as quando a sensibilidade dos dados ou a população de usuários mudar.

  2. Faça o controle de acesso baseado em papéis espelhar os papéis clínicos reais e depois mantenha-o limpo. Projete os papéis em torno de como o cuidado é de fato prestado — e não em torno do organograma ou dos caprichos da configuração padrão de um fornecedor — e mapeie cada papel aos registros e funções mínimos de que precisa. Com o tempo, o RBAC decai em "explosão de papéis", em que centenas de papéis sobrepostos se acumulam e ninguém sabe dizer o que cada um concede. Agende racionalizações periódicas dos papéis e resista à tentação de resolver todo pedido de acesso criando um novo papel sob medida.

  3. Aplique o menor privilégio a pessoas e a contas de máquina por igual. O menor privilégio é rotineiramente aplicado aos clínicos e esquecido para as contas de serviço, os motores de integração e as ferramentas de relatório, que muitas vezes detêm o acesso mais amplo de todos. Uma interface automatizada que puxa dados para um painel raramente precisa de acesso de escrita ou de texto livre identificável, e, no entanto, com frequência os recebe. Inventariem as identidades não humanas, reduzam seu escopo e girem suas credenciais em cronograma.

  4. Torne obrigatória a autenticação multifator para o acesso remoto e privilegiado e escolha fatores adequados ao ambiente. As senhas sozinhas já não são defensáveis para nada que alcance dados de pacientes a partir de fora de um dispositivo confiável, e a MFA é hoje uma expectativa de base em todos os sistemas do NHS. Escolham fatores que sobrevivam ao ambiente clínico: tokens de hardware ou autenticadores de plataforma resistentes a phishing para o acesso privilegiado e remoto, e desconfiem de códigos por SMS em enfermarias onde o sinal é ruim e os telefones são compartilhados. Equilibrem o ganho de segurança com a realidade de que um clínico no meio de uma ressuscitação não pode ficar tateando por um segundo fator.

  5. Use o login único para remover o atrito que empurra a equipe a gambiarras inseguras. Quando a equipe precisa entrar separadamente em dez sistemas, anota senhas em post-its, compartilha cartões inteligentes e deixa sessões abertas — cada uma um risco de segurança e de confidencialidade. Um SSO bem implantado, idealmente combinado com crachás de proximidade "encostar para entrar, encostar para sair" em estações de trabalho clínicas compartilhadas, melhora a segurança e devolve tempo aos clínicos. Tratem o SSO como uma intervenção de segurança do paciente, e não apenas como conveniência, e meçam o tempo de login que vocês removem.

  6. Modernize a identidade do NHS além do cartão inteligente, sem quebrar o que funciona. O NHS Care Identity Service (antes Care Identity Service e, antes disso, o regime da Registration Authority construído sobre cartões inteligentes) autentica a equipe do NHS e conduz o acesso a sistemas nacionais como a Spine. A direção nacional agora é rumo a uma autenticação moderna e baseada em padrões — CIS2 com MFA e OpenID Connect —, reduzindo a dependência de cartões físicos e leitores que falham, são compartilhados ou bloqueiam o cuidado. Planejem a migração deliberadamente: mantenham o rigor de garantia e de registro do modelo de cartão inteligente enquanto adotam a flexibilidade dos tokens modernos.

  7. Conduza entradas/mudanças/saídas como um processo controlado e auditável — especialmente as saídas. A falha de IAM grave mais comum na saúde e nos cuidados é a conta que sobrevive à necessidade da pessoa: o médico júnior que rodou, a enfermeira temporária que saiu, o contratado cujo acesso nunca foi revogado. Automatizem o provisionamento a partir de uma fonte autoritativa (em geral, o registro eletrônico de pessoal), para que iniciar, mudar e encerrar um papel acione a mudança correspondente de acesso numa janela definida e curta. Tratem a revogação no mesmo dia para os que saem e para a equipe sob investigação como uma exigência dura, e não uma aspiração.

  8. Recertifique o acesso regularmente e responsabilize os gestores por isso. O acesso adequado no primeiro dia se desvia à medida que as pessoas mudam de equipe e acumulam direitos de que não precisam mais — a "fluência de privilégios" (privilege creep). Conduzam revisões periódicas de acesso (recertificação) em que o gestor ou dono do sistema responsável confirma ativamente que cada pessoa ainda precisa de cada direito, com o silêncio resultando em remoção e não em retenção. Tornem a revisão significativa apresentando-a em linguagem de papéis clínicos, e não em códigos brutos de permissão que nenhum gestor consegue interpretar.

  9. Governe o acesso privilegiado como uma categoria própria. Administradores, donos de bancos de dados e engenheiros de infraestrutura podem ler ou alterar qualquer registro e desativar os próprios controles que o protegem; assim, o acesso deles precisa de tratamento mais forte do que o de usuários comuns. Implementem a gestão de acesso privilegiado: separem as identidades de administração das contas do dia a dia, concedam direitos elevados na hora e com prazo limitado, em vez de permanentes, e gravem as sessões privilegiadas para revisão independente. Jamais deixem um fornecedor ou uma conta "quebra-vidro" virar uma chave-mestra permanente e não monitorada.

  10. Torne auditável toda decisão de acesso e leia de fato a auditoria. Um controle de acesso que não pode ser revisto depois é só meio controle; a capacidade de responder "quem acessou este prontuário, quando e com que base?" sustenta tanto as investigações de confidencialidade quanto a segurança do paciente. Configurem um registro de auditoria abrangente e à prova de adulteração e — de modo crucial — dotem de recursos uma auditoria proativa, incluindo alertas para consultas a si mesmo, consultas a colegas ou VIPs e volumes de acesso incomuns. Uma trilha de auditoria que ninguém examina não dissuade ninguém.

  11. Projete o acesso quebra-vidro para que as emergências sejam atendidas e o abuso seja pego. Os clínicos às vezes precisam legitimamente de um prontuário que não estão rotineiramente autorizados a ver — um paciente inconsciente, uma emergência entre organizações. Ofereçam uma via explícita de "quebra-vidro" que conceda acesso de emergência com motivo obrigatório, sinalização imediata e revisão posterior obrigatória, em vez de forçar a equipe a escolher entre as regras e o paciente. O objetivo é tornar fácil a ação de emergência segura e visível a injustificada.

  12. Adote a confiança zero como direção e sequencie-a de forma pragmática. Passe de "rede confiável, aberta por dentro" para verificar cada solicitação frente à identidade, à saúde do dispositivo e ao contexto, de modo que um notebook comprometido na LAN corporativa deixe de ser automaticamente confiável. É uma jornada de vários anos por identidade forte, conformidade de dispositivos, acesso condicional e microssegmentação — e não um produto que se compra. Sequenciem-na depois dos fundamentos (MFA, menor privilégio, JML limpo) e alinhem-na ao trabalho de parque do Tópico 4.0 — Arquitetura técnica, nuvem e sistemas legados.

Perguntas para discutir com a sua equipe#

  1. Onde estamos deliberadamente trocando atrito de acesso por segurança clínica, e quem decidiu o equilíbrio? Cada login adicional, segundo fator ou etapa de autorização protege a confidencialidade, mas custa segundos que, numa emergência, são em si um risco de segurança. Esta pergunta obriga a equipe a nomear os lugares específicos onde os controles de segurança poderiam atrasar o cuidado — o login da ressuscitação, a estação de trabalho compartilhada da enfermaria, o sistema fora do horário — e a perguntar se o equilíbrio atual foi escolhido por pessoas que entendem as consequências clínicas e de segurança ou ficou no padrão de um fornecedor. Debatam a tensão com honestidade: um controle apertado demais gera senhas em post-its e cartões inteligentes compartilhados, que são piores do que o risco que tratam, enquanto um frouxo demais convida à bisbilhotice e a violações. Procurem sinais concretos de um mau equilíbrio — equipe compartilhando credenciais, sessões deixadas abertas, quebra-vidro usado rotineiramente. Uma boa resposta identifica quem é dono de cada concessão, mostra que os clínicos estavam na sala quando ela foi definida e aponta tempos de login e taxas de gambiarra medidos, e não suposições. Também se compromete a revisitar o equilíbrio à medida que papéis, sistemas e ameaças mudam.

  2. Quão confiantes estamos de que quem sai ou muda perde o acesso certo, no prazo certo, todas as vezes? A conta que sobrevive à sua necessidade é a falha clássica de IAM, e numa força de trabalho de saúde rotativa e multiorganizacional o risco é agudo. Esta pergunta sonda se entradas/mudanças/saídas é um processo confiável e automatizado, conduzido por uma fonte autoritativa, ou um conjunto de e-mails manuais que falham em silêncio quando alguém está ocupado. Discutam os casos difíceis: o médico júnior que roda entre hospitais, a enfermeira temporária de um único plantão, o contratado, o membro da equipe suspenso à espera de investigação. Considerem o que significa "o prazo certo" para cada um — a revogação no mesmo dia é inegociável numa suspensão, mas pode ser mais branda numa mudança interna de rotina. Uma boa resposta consegue apontar evidências, e não intenções: os resultados da última auditoria de saídas, o número de contas dormentes encontradas e fechadas, o tempo entre alguém sair e o seu acesso terminar. É honesta sobre as lacunas e nomeia quem responde por fechá-las.

  3. Quando algo dá errado com um prontuário, conseguimos de fato reconstruir quem fez o quê — e notaríamos o mau uso sem que um incidente nos provocasse? A auditoria é o controle que torna a confidencialidade e a segurança exequíveis depois do fato, mas só funciona se os registros forem completos, protegidos e genuinamente revistos. Esta pergunta separa duas coisas que uma equipe costuma confundir: a capacidade de investigar reativamente quando chega uma reclamação e a de detectar proativamente o mau uso antes que alguém reclame. Explorem o que seus registros de fato captam, se podem ser alterados, por quanto tempo são guardados e — a pergunta mais difícil — quem os examina quando não há incidente. Considerem as ameaças realistas: um membro da equipe consultando um familiar, um colega ou uma figura pública; uma conta comprometida exfiltrando prontuários em escala. Uma boa resposta mostra que a auditoria é dotada de recursos como função ativa, com alertas, e não um arquivo dormente, e consegue citar um exemplo real de mau uso que a organização detectou e tratou. Também liga a auditoria à justiça, garantindo que as revisões não visem desproporcionalmente certos grupos da equipe.

  4. Quando um clínico precisa legitimamente de um prontuário que não está rotineiramente autorizado a ver, a nossa via quebra-vidro torna fácil a ação segura e visível a injustificada? A saúde e os cuidados diferem da TI corporativa comum justamente porque as regras às vezes precisam ceder ao paciente à sua frente — uma chegada inconsciente, uma emergência entre organizações, um clínico fora do horário cobrindo uma carga de pacientes desconhecida. Esta pergunta indaga se o acesso de emergência é projetado como uma via explícita, fundamentada e sinalizada, ou se a equipe é silenciosamente forçada a escolher entre a política de acesso e o bem-estar do paciente. Sondem os modos de falha nas duas pontas: uma rota quebra-vidro tão trabalhosa que os clínicos a evitam e compartilham credenciais, ou tão sem atrito e sem revisão que vira o caminho rotineiro de entrada e esvazia por completo o RBAC. Discutam quem revê os eventos de quebra-vidro, com que rapidez e que proporção se revela injustificada — uma taxa próxima de zero pode significar que o controle não é usado, e não que está limpo. Uma boa resposta consegue descrever os passos exatos que um clínico dá, a captura do motivo, a sinalização imediata à organização de origem do prontuário e a revisão posterior que fecha o ciclo e mostrar que as emergências são genuinamente atendidas e o abuso genuinamente pego. É honesta sobre se os volumes de quebra-vidro tendem numa direção que sugere uma lacuna de autorização mais profunda.

  5. Estamos governando o acesso privilegiado e o não humano tão rigorosamente quanto governamos os clínicos — ou é aí que está a exposição real? Os controles que protegem os dados dos pacientes são, eles próprios, administrados por alguém, e administradores, donos de bancos de dados, motores de integração e contas de relatório muitas vezes podem ler ou alterar qualquer registro e desligar as próprias salvaguardas que restringem todos os demais. Esta pergunta traz à luz o acesso que a disciplina de menor privilégio tem mais probabilidade de pular: contas de administração permanentes, logins de suporte remoto de fornecedores, contas de serviço com direitos de "modo deus" e a interface automatizada que puxa em silêncio texto livre identificável de que nunca precisou. Discutam se as identidades de administração são separadas das contas do dia a dia, se a elevação é na hora e com prazo limitado ou permanente e se as sessões privilegiadas são gravadas e revistas de forma independente. Considerem especificamente o parque não humano — quem é dono de cada conta de serviço, quando suas credenciais foram giradas pela última vez e se alguém conseguiria enumerá-las hoje. Uma boa resposta trata o acesso privilegiado como categoria própria, com responsáveis nomeados, evidência de elevação na hora e um inventário real de identidades de máquina, em vez de supor que os fundamentos aplicados aos clínicos cobrem também a retaguarda. É franca sobre os fornecedores e sobre qualquer conta que tenha virado uma chave-mestra permanente e não monitorada.

  6. Quanto da nossa identidade depende de partes fora do nosso controle, e somos deliberados quanto a essa dependência? A identidade moderna na saúde e nos cuidados é federada por concepção — um prontuário compartilhado confia em afirmações de cada organização parceira, serviços nacionais como o NHS Care Identity Service e o CIS2 atestam a equipe e o NHS login atesta os cidadãos —, o que significa que a força do seu controle de acesso é sempre tão boa quanto os provedores de identidade em que você se apoia e os padrões que o unem a eles. Esta pergunta pede à equipe que mapeie onde a confiança é delegada: que organizações autenticam quais usuários, o que acontece quando o processo de entradas/mudanças/saídas de um parceiro falha e como um login federado é revogado quando um membro da equipe de outro empregador sai. Pesem a migração em curso dos cartões inteligentes para a autenticação baseada em padrões (CIS2 com MFA e OpenID Connect) e a tensão entre adotar a direção nacional e manter os fluxos de trabalho locais funcionando às 3 da manhã. Considerem também o ângulo da resiliência: se um serviço nacional de identidade estiver indisponível, os clínicos ainda conseguem alcançar com segurança os prontuários de que precisam, ou a federação vira um ponto único de falha? Uma boa resposta mostra que a equipe sabe exatamente de quem é a garantia em que está se apoiando, acordou como a revogação entre organizações e os incidentes são tratados e está sequenciando deliberadamente a sua passagem à autenticação moderna do NHS, em vez de ser arrastada por ela. É realista sobre as partes do parque que ainda não conseguem federar e como são ligadas nesse meio-tempo.

Na prática: um exemplo de saúde e cuidados#

O Meadowvale Integrated Care System está lançando um prontuário de cuidados compartilhado para que a equipe de hospital, comunitária, de saúde mental, de clínica geral e de cuidados sociais para adultos veja uma visão unificada de cada pessoa. No início da descoberta, o programa percebe que seu risco real não é construir o prontuário, mas controlar o acesso a ele: uma única visão que atravessa cinco organizações multiplica tanto o benefício de segurança de o clínico certo ver a informação certa quanto o dano de a pessoa errada ver algo sensível.

A equipe faz do controle de acesso um fluxo de projeto de primeira ordem. Acordam um modelo de papéis expresso em linguagem clínica — "enfermeiro comunitário", "profissional aprovado de saúde mental", "gerente de casa de repouso" — e mapeiam cada papel aos dados mínimos de que precisa, com os prontuários de saúde mental e de saúde sexual sujeitos a acesso mais apertado e autorizado separadamente. A autenticação é federada: cada organização parceira autentica sua própria equipe pelo NHS Care Identity Service ou pelo seu provedor de identidade local usando OpenID Connect, e o prontuário compartilhado confia nessas afirmações em vez de emitir as próprias credenciais; assim, não há nova senha a gerir, e as entradas/mudanças/saídas ficam com a organização empregadora, onde vive o registro autoritativo da equipe.

Como um paramédico ou um clínico fora do horário às vezes precisará de um prontuário que não está rotineiramente autorizado a ver, a equipe constrói uma via quebra-vidro explícita: o acesso de emergência é concedido ao informar um motivo, sinalizado imediatamente à organização de origem do prontuário e revisto em até 48 horas. Montam uma pequena função conjunta de governança da informação e auditoria que revisa os eventos de quebra-vidro, executa alertas para consultas a si mesmo e a indivíduos sinalizados e reporta trimestralmente ao conselho do ICS.

Seis meses após a entrada em produção, um alerta sinaliza uma coordenadora de cuidados abrindo repetidamente o prontuário de alguém sem envolvimento ativo na sua carga de casos. A função de auditoria investiga, constata que o acesso foi pessoal, e não profissional, e a organização empregadora toma medida disciplinar. Não houve incidente de segurança do paciente, a violação foi pega proativamente e — como os controles demonstravelmente funcionaram — a confiança pública no prontuário compartilhado se manteve. O conselho observa que a mesma capacidade de auditoria agora serve também de evidência para a sua submissão do Data Security and Protection Toolkit (ver Tópico 1.7 — Governança da informação, proteção de dados e cibersegurança).

Perspectivas setoriais#

Startup#

Uma pequena empresa de saúde digital que construa, digamos, um aplicativo de monitoramento remoto tem a vantagem de não ter legado: pode adotar autenticação moderna, MFA e federação baseada em padrões desde o primeiro dia e integrar-se ao NHS login para cidadãos e ao CIS2 para clínicos, em vez de inventar o seu próprio sistema de identidade. O perigo é a velocidade ultrapassar a disciplina — credenciais de administração fixadas no código, uma conta de superusuário "do fundador" compartilhada, contas de serviço com acesso de "modo deus" e nenhum processo de saída porque "todo mundo se conhece". O menor privilégio e a auditoria parecem custo indireto com dez pessoas, mas viram dívida técnica irrecuperável com cem. A atitude pragmática é comprar a identidade como serviço gerenciado, impor MFA e RBAC desde o primeiro commit e tratar os requisitos do DTAC (Digital Technology Assessment Criteria) como a barra mínima para qualquer implantação no NHS.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso, uma agência de cuidados domiciliares, uma clínica de unidade única ou um pequeno fornecedor de tecnologia em saúde que já passou da fase pré-receita — carrega os mesmos deveres de confidencialidade e de controle de acesso de um grande hospital, mas tem pacientes reais nos registros, um punhado de funcionários e pouca ou nenhuma capacidade de TI dedicada para cumpri-los. O risco prático aqui não é exótico: é o login compartilhado na recepção, a senha do sistema clínico colada no monitor, o médico substituto que recebe o cartão inteligente de um colega porque registrar um novo leva tempo demais e o ex-funcionário cuja conta nunca é desativada porque ninguém é dono dessa tarefa. O caminho pragmático é apoiar-se nos recursos de identidade já embutidos nos sistemas que compram — impor MFA e contas por pessoa, ligar o registro de auditoria do fornecedor e usar o CIS2 e o NHS login do NHS em vez de credenciais caseiras — e escrever uma rotina simples de entradas/mudanças/saídas que nomeie uma pessoa responsável, mesmo que seja o gerente do consultório fazendo-a à mão. O menor privilégio e a revogação no mesmo dia para quem sai importam tanto com dez funcionários quanto com dez mil; a diferença é que aqui precisam ser alcançados com processo e configuração, e não com uma equipe de identidade dedicada.

Grande organização#

Um grande hospital do NHS ou ICS opera dezenas de sistemas clínicos de idades muito diversas, cada um com o próprio modelo de identidade, e seu desafio central é a integração e o ciclo de vida em escala. Cartões inteligentes, SSO, fluxos "encostar para entrar, encostar para sair" e uma esteira confiável de JML a partir do registro eletrônico de pessoal importam mais aqui do que qualquer controle engenhoso isolado, porque os modos de falha são falhas de volume: milhares de contas dormentes, explosão de papéis e registros de auditoria que ninguém tem capacidade de rever. A gestão de acesso privilegiado é crítica dado o número de administradores e fornecedores que tocam o parque. O progresso vem de uma estratégia de identidade que racionaliza papéis, federa entre sistemas e dota de recursos uma função permanente de auditoria — e não de soluções pontuais acrescentadas a cada aplicação.

Governo#

Um órgão nacional como o NHS England opera a identidade como infraestrutura compartilhada para todo o sistema: o NHS Care Identity Service e o CIS2 para a equipe, o NHS login para os cidadãos e os padrões e regimes de garantia que permitem a centenas de organizações confiar umas nas outras. Suas decisões fixam a direção do percurso — a passagem dos cartões inteligentes para a autenticação moderna, a adoção do OpenID Connect, o impulso rumo à confiança zero — e sua responsabilização é perante o Parlamento e o público quanto à segurança e ao acesso equitativo. A tensão está entre a padronização central e a flexibilidade local: imponha de forma rígida demais e você quebra os fluxos de trabalho locais; imponha de forma frouxa demais e a federação colapsa em inconsistência. A lente governamental trata, portanto, de definir padrões interoperáveis (ver Tópico 4.3 — Interoperabilidade e padrões de dados), oferecer serviços compartilhados confiáveis e assegurar a conformidade sem microgerenciar cada hospital.

Modos de falha comuns#

  • Contas órfãs e dormentes. Quem sai, equipe que rodou e antigos contratados mantêm acesso ativo porque o JML depende de notificação manual. A correção é a desativação automatizada a partir de uma fonte autoritativa, mais varreduras regulares de contas dormentes.
  • Explosão de papéis e fluência de privilégios. O RBAC decai em centenas de papéis sobrepostos e os indivíduos acumulam direitos que não usam mais. Combata com recertificação periódica e racionalização agendada de papéis.
  • Compartilhamento de credenciais e estações de trabalho compartilhadas. Logins lentos e cartões inteligentes desajeitados levam a equipe a compartilhar cartões e deixar sessões abertas. Ataquem a causa-raiz com SSO, crachás de proximidade e troca rápida, em vez de exortar a equipe a se comportar.
  • Acesso privilegiado permanente. Administradores e fornecedores detêm contas permanentes de "modo deus" que podem desativar os próprios controles. Passem à elevação na hora, com prazo limitado e gravada.
  • Auditoria como decoração. Os registros são coletados, mas nunca revistos, de modo que o mau uso só é encontrado reativamente. Dotem de recursos uma auditoria proativa, com alertas para consultas a si mesmo e a VIPs.
  • Quebra-vidro como brecha. O acesso de emergência existe, mas não é monitorado, e vira o caminho rotineiro de menor resistência. Exijam um motivo, sinalizem todo uso e revejam depois.
  • Teatro da MFA. A MFA está ligada, mas em fatores fracos e sujeitos a phishing, ou dispensada para os usuários privilegiados mais ocupados. Prefiram fatores resistentes a phishing onde o risco é maior.

Modelo de maturidade#

Dimensão Iniciar Desenvolver Padronizar Gerir Orquestrar
Autenticação Apenas senhas; compartilhamento comum MFA no acesso remoto; cartões inteligentes para sistemas nacionais MFA ampla; SSO implantado; autenticação moderna (CIS2/OIDC) adotada Cobertura da MFA e tempos de login acompanhados; migração do cartão inteligente à autenticação moderna gerida frente a metas; fatores fracos reportados e remediados Autenticação resistente a phishing e baseada em risco; sem senha onde seguro
Autorização (RBAC e menor privilégio) Ad hoc, todos veem quase tudo Papéis existem, mas amplos e sobrepostos Modelo limpo de papéis em linguagem clínica; menor privilégio imposto Recertificação e contagem de papéis medidas; fluência de privilégios acompanhada e reduzida; menor privilégio assegurado frente a metas Acesso ciente de atributos e de contexto; minimização contínua
Entradas/mudanças/saídas Manual, pouco confiável; contas dormentes comuns Processo documentado, parcialmente automatizado Automatizado a partir de fonte autoritativa; revogação no mesmo dia para quem sai Pontualidade da revogação medida frente a limites definidos; auditorias de saídas regulares; taxas de contas dormentes reportadas à gestão Provisionamento em tempo real; contas dormentes quase zero, evidenciadas
Acesso privilegiado Contas de administração compartilhadas e permanentes Identidades de administração separadas Na hora, com prazo limitado, sessões gravadas Eventos de elevação e sessões privilegiadas revistos e reportados; acesso de fornecedores assegurado e de prazo limitado frente à política Zero privilégio permanente; monitoramento contínuo
Auditoria e revisão Pouco registro; sem revisão Registros guardados, apenas reativos Registros abrangentes; recertificação e auditoria agendadas Cobertura da auditoria, resposta a alertas e taxas de detecção de mau uso acompanhadas; atrasos de revisão governados frente a metas Alertas e análises proativos; aplicação justa e evidenciada

Lista de verificação#

  • A força da autenticação e o escopo da autorização foram decididos e documentados separadamente para cada sistema clínico.
  • A MFA é imposta para todo acesso remoto e privilegiado, com fatores adequados ao ambiente clínico.
  • O login único e a troca rápida de estação de trabalho foram implantados para remover o atrito de login e o compartilhamento de credenciais.
  • O modelo de papéis é expresso em linguagem clínica, mapeado ao menor privilégio e racionalizado em cronograma.
  • Entradas/mudanças/saídas são automatizadas a partir de uma fonte autoritativa de pessoal, com revogação no mesmo dia para quem sai e para suspensões.
  • A recertificação periódica de acesso é conduzida por gestores responsáveis, com remoção por padrão para o acesso não confirmado.
  • O acesso privilegiado é gerido como categoria distinta: identidades separadas, elevação na hora, gravação de sessões.
  • As contas não humanas e de integração são inventariadas, reduzidas ao menor privilégio e têm credenciais giradas.
  • Um registro de auditoria abrangente e à prova de adulteração está em vigor, com alertas proativos para consultas a si mesmo, a colegas e a VIPs.
  • O acesso de emergência quebra-vidro é projetado com motivo obrigatório, sinalização imediata e revisão posterior.
  • A migração dos cartões inteligentes para a autenticação moderna do NHS (CIS2 / OpenID Connect) está planejada e sequenciada.
  • Um roteiro de confiança zero está acordado e alinhado à estratégia de arquitetura técnica.

Fontes-chave#

  • NHS England — orientações do NHS Care Identity Service e do Care Identity Service 2 (CIS2)
  • NHS England — Data Security and Protection Toolkit
  • National Cyber Security Centre (NCSC) — Zero Trust Architecture Design Principles
  • National Cyber Security Centre (NCSC) — orientações sobre autenticação multifator e gestão de identidade/acesso
  • NIST — Special Publication 800-207, Zero Trust Architecture
  • NIST — Special Publication 800-63, Digital Identity Guidelines
  • NHS England / NHS login — documentação do serviço de verificação de identidade do cidadão
  • DTAC — Digital Technology Assessment Criteria para saúde e cuidados sociais
  • Princípios de Caldicott e o dever de confidencialidade da common law (Reino Unido)

Referências#

  1. Identity management (identity and access management) — Wikipedia — https://en.wikipedia.org/wiki/Identity_management
  2. Authentication — Wikipedia — https://en.wikipedia.org/wiki/Authentication
  3. Authorization — Wikipedia — https://en.wikipedia.org/wiki/Authorization
  4. Role-based access control — Wikipedia — https://en.wikipedia.org/wiki/Role-based_access_control
  5. Principle of least privilege — Wikipedia — https://en.wikipedia.org/wiki/Principle_of_least_privilege
  6. Multi-factor authentication — Wikipedia — https://en.wikipedia.org/wiki/Multi-factor_authentication
  7. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
  8. Federated identity — Wikipedia — https://en.wikipedia.org/wiki/Federated_identity
  9. OAuth — Wikipedia — https://en.wikipedia.org/wiki/OAuth
  10. OpenID (and OpenID Connect) — Wikipedia — https://en.wikipedia.org/wiki/OpenID
  11. Security Assertion Markup Language (SAML) — Wikipedia — https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
  12. Provisioning (technology) — Wikipedia — https://en.wikipedia.org/wiki/Provisioning_(technology)
  13. Zero trust architecture — Wikipedia — https://en.wikipedia.org/wiki/Zero_trust_architecture
  14. NHS Care Identity Service 2 (CIS2) — NHS England — https://digital.nhs.uk/services/care-identity-service
  15. Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/
  16. Zero Trust Architecture Design Principles — National Cyber Security Centre — https://www.ncsc.gov.uk/collection/zero-trust-architecture
  17. Special Publication 800-207: Zero Trust Architecture — National Institute of Standards and Technology (NIST) — https://csrc.nist.gov/pubs/sp/800/207/final
  18. Special Publication 800-63: Digital Identity Guidelines — National Institute of Standards and Technology (NIST) — https://pages.nist.gov/800-63-3/
  19. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
  20. NHS login — NHS England — https://www.nhs.uk/nhs-services/online-services/nhs-login/

Editar esta página no GitHub — o livro é a fonte da verdade; este site apenas o exibe.