Por que a segurança na nuvem no setor da saúde não pode ser tratada da mesma forma que a segurança padrão na nuvem corporativa?

O que diferencia a segurança de dados na área da saúde da segurança de dados corporativa padrão?

A segurança de dados na área da saúde está sujeita a um conjunto de considerações de segurança que raramente surgem em discussões típicas sobre privacidade e segurança corporativa. Uma série de requisitos regulatórios rigorosos, dados pessoais que não podem ser duplicados ou substituídos e a saúde do paciente como resultado direto — tudo isso contribui para que as obrigações de proteger os dados de saúde sejam diferentes de qualquer outro quadro de segurança genérica na nuvem.

De que forma as Informações de Saúde Protegidas (PHI) são excepcionalmente sensíveis?

As Informações de Saúde Protegidas (PHI) apresentam um nível de sensibilidade diferente do restante dos dados corporativos de uma organização. O Departamento de Saúde e Serviços Humanos (DHHS) define PHI como informações de saúde individualmente identificáveis relacionadas à condição de saúde física ou mental passada, presente ou futura de uma pessoa, à prestação de cuidados de saúde ou ao pagamento por esses cuidados.

Um cartão de crédito pode ser invalidado assim que a invasão for revelada, com a emissão subsequente de um novo cartão. Esse não é o caso de doenças, fatores genéticos ou diagnósticos de saúde mental — esses fatos são verdadeiramente permanentes.

Sempre que as PHI são comprometidas, os riscos que essas violações representam vão muito além do simples roubo de identidade. Os prontuários médicos podem ser usados para excluir pacientes da cobertura de seguro, interferir em oportunidades de emprego e cometer fraudes direcionadas contra idosos e pessoas com deficiência. A confidencialidade das PHI torna-se ainda mais crítica devido à amplitude das informações que podem ser qualificadas como PHI.

Aqui estão os exemplos mais proeminentes:

• Nome completo e informações de contato vinculadas a uma condição ou tratamento
• Datas de nascimento, admissão, alta ou óbito
• Dados geográficos em escala inferior à de um estado
• Identificadores biométricos, como impressões digitais ou impressões de voz
• Qualquer outro número ou código de identificação exclusivo associado ao atendimento

Por que a confidencialidade, a integridade e a disponibilidade têm pesos diferentes na área da saúde?

Confidencialidade, integridade e disponibilidade (às vezes chamadas de “tríade CIA”) são aplicadas a todos os protocolos de segurança. No entanto, os ambientes de nuvem na área da saúde tendem a considerar esses pilares de maneira diferente das implantações corporativas habituais.

Por exemplo, a disponibilidade acarreta consequências clínicas significativas a partir de nada mais do que simples interrupções de serviço que não têm paralelo em nenhum outro setor. A perda de serviço não é simplesmente perda de produtividade em ambientes de saúde — é o bloqueio da solicitação de medicamentos, ou o bloqueio do acesso a resultados de exames de imagem, ou a impossibilidade de os paramédicos consultarem o prontuário do paciente.

Informações mais gerais sobre os três pilares acima mencionados são abordadas a seguir:

De que forma a necessidade de retenção de longo prazo e de auditabilidade altera os requisitos de segurança?

Os prontuários médicos e a documentação de segurança associada devem ser retidos por um período muito mais longo do que os cronogramas típicos de retenção de dados corporativos.

HIPAA (Lei de Portabilidade e Responsabilidade do Seguro Saúde) estabelece que as entidades abrangidas devem reter suas políticas, procedimentos e registros relacionados por 6 anos a partir da data de criação ou da última data de vigência. Esse prazo pode ser ainda mais longo em determinados estados no que diz respeito a tipos específicos de registros.

Os controles de segurança na nuvem que dão suporte e protegem esses dados também devem ser mantidos durante esse mesmo período. Esses controles devem ser aplicáveis, auditáveis e restauráveis durante todo o prazo de 6 anos.

Tais requisitos influenciam o projeto mais amplo da arquitetura de segurança em nuvem para o setor de saúde. O gerenciamento de chaves para criptografia, os registros de acesso e a integridade dos backups — nenhum desses aspectos pode ser tratado simplesmente como uma preocupação operacional de curto prazo. Uma trilha de auditoria que auxilie na investigação de uma violação de segurança, ou uma investigação regulatória daqui a cinco anos, dependerá dos controles que forem implementados e operados atualmente.

Como a conformidade e as regulamentações da área da saúde alteram os requisitos de segurança na nuvem?

As obrigações regulatórias no setor da saúde não são apenas uma estrutura adicional à segurança na nuvem. Essas obrigações também implicam mudanças nos controles exigidos, na responsabilização por eles e nas consequências em caso de falha. A HIPAA, o GDPR, a HITECH e uma lista crescente de regulamentações estaduais impõem, cada uma, suas próprias exigências (técnicas e contratuais) aos ambientes em nuvem, com as quais as estruturas padrão de conformidade empresarial não foram projetadas para lidar.

Quais obrigações específicas a HIPAA, o GDPR e outras regulamentações da área da saúde impõem ao uso da nuvem?

Cada grande estrutura regulatória tem sua própria perspectiva no que diz respeito à segurança na nuvem:

• HIPAA abrange as Informações de Saúde Protegidas (PHI) armazenadas em entidades abrangidas sediadas nos EUA e em seus parceiros comerciais; isso também inclui soluções em nuvem que armazenam, processam e transmitem dados confidenciais de pacientes em nome dessas entidades.
• GDPR é aplicado a situações em que estão envolvidos dados de saúde de residentes da UE, mesmo que a infraestrutura de armazenamento em nuvem esteja localizada em outro lugar.
• HITECH amplia e reforça as capacidades de fiscalização da HIPAA, aumentando os níveis de penalidades e, ao mesmo tempo, ampliando os requisitos para a notificação obrigatória de violações.

As obrigações impostas por cada estrutura ao ambiente de nuvem diferem significativamente entre si em termos de escopo, mecanismo e consequências:

De que forma o prazo e o escopo da notificação de violação diferem para as organizações da área da saúde?

As notificações de violação de dados, quando se trata de informações de saúde, também são muito mais prescritivas (e com riscos maiores) do que aquelas utilizadas na maioria dos setores empresariais. Os prazos são fixos, o público-alvo das notificações é diversificado e os limites que acionam diferentes requisitos de notificação são altamente específicos:

• 60 dias – prazo máximo que uma entidade abrangida pela HIPAA tem para notificar as pessoas afetadas após a descoberta de uma violação
• 60 dias – o mesmo prazo se aplica à notificação ao Departamento de Saúde e Serviços Humanos dos EUA (HHS)
• Mais de 500 pessoas afetadas – aciona a obrigação de notificar os principais veículos de comunicação do estado ou jurisdição afetada
• Menos de 500 indivíduos – podem ser registrados e relatados ao HHS anualmente, mas a notificação individual ainda deve ser feita no prazo de 60 dias
• GDPR – exige a notificação à autoridade supervisora competente no prazo de 72 horas após tomar conhecimento de uma violação, e aos indivíduos afetados sem demora injustificada quando houver probabilidade de alto risco
• Leis estaduais – vários estados impõem prazos mais curtos do que os 60 dias da HIPAA; alguns exigem notificação no prazo de 30 dias ou menos

Todos esses prazos se tornam ainda mais complexos quando se trata de ambientes em nuvem. Sempre que as PHIs são distribuídas entre diferentes provedores de nuvem, regiões ou serviços de terceiros – identificar o escopo total de uma violação (para uma notificação precisa) leva muito mais tempo do que em ambientes locais isolados.

Por que o setor de saúde exige uma validação mais rigorosa da conformidade na nuvem?

A maior fraqueza na validação rigorosa da conformidade na nuvem no setor de saúde é que nenhuma certificação de conformidade existente se alinha diretamente aos requisitos regulatórios específicos da área, e a suposição de equivalência está potencialmente deixando sua organização exposta a um risco significativo de lacuna.

Por exemplo, sempre que um provedor de nuvem possui uma certificação SOC 2 Tipo II ou acreditação ISO 27001 – ele atende a um padrão básico de segurança reconhecido. Ao mesmo tempo, nenhuma dessas estruturas foi criada tendo em mente as Informações de Saúde Protegidas (PHI), a necessidade de acessibilidade clínica ou as salvaguardas técnicas da HIPAA.

Uma validação mais rigorosa em ambientes de nuvem do setor de saúde significa ir além das revisões regulares de certificação. Isso inclui:

• Verificar se os Acordos de Prestação de Serviços (BAAs) refletem com precisão as práticas reais de tratamento de dados do provedor
• Garantir que as configurações dos registros de auditoria atendam tanto aos requisitos de retenção da HIPAA quanto aos de nível estadual
• Verificar se as implementações de criptografia abrangem as PHI em repouso, em trânsito e, especialmente, durante o processamento

Por que a segurança do paciente é uma preocupação de segurança que a TI frequentemente negligencia?

A maioria dos setores sofre perdas financeiras, perda de dados ou danos à reputação devido a uma violação de segurança. No entanto, problemas de segurança no setor da saúde podem causar danos diretos ao paciente. Essa distinção, por si só, altera fundamentalmente a forma como as decisões de segurança na nuvem são priorizadas e governadas.

Por que as organizações de saúde devem proteger os dados dos pacientes para garantir um atendimento seguro?

A disponibilidade constante dos dados dos pacientes é indispensável para o atendimento clínico. As ramificações de qualquer problema em um ambiente de nuvem (uma violação, uma interrupção, um evento de corrupção de dados) se espalham imediatamente muito além do departamento de TI. Isso inclui:

• Médicos perdendo acesso aos históricos de medicação
• Enfermeiros não conseguindo mais acessar planos de cuidados ativos
• Equipes de emergência sendo forçadas a tomar decisões sem ter em mente o contexto diagnóstico essencial

A possibilidade de acessar os dados dos pacientes e a validade desses dados não são medidas de desempenho de TI – são medidas de segurança do paciente. A entidade de saúde que considera a segurança na nuvem uma questão de “back office” cria risco para o paciente sempre que seu sistema fica fora do ar ou o registro de dados do paciente é alterado sem comprovação.

Por que os SLAs de disponibilidade devem ser tratados como controles de risco clínico?

A proteção da continuidade dos negócios é, sem dúvida, um dos temas centrais de um SLA empresarial comum. Nos ambientes de nuvem da área da saúde, este documento precisa funcionar como um controle de risco clínico, levando em consideração o que os efeitos de uma interrupção significariam no contexto dos pacientes.

Garantias genéricas de tempo de atividade são incapazes de atender às realidades operacionais dos ambientes clínicos. Um SLA que rege uma implantação de nuvem na área da saúde deve especificar:

• Objetivo de Tempo de Recuperação (RTO) alinhado à criticidade do fluxo de trabalho clínico – o acesso ao prontuário eletrônico, por exemplo, requer um RTO muito mais curto do que os sistemas de faturamento
• Objetivo de Ponto de Recuperação (RPO) suficientemente restrito para evitar a perda de dados clinicamente significativos entre o último backup e o momento da falha
• Janelas de manutenção planejada agendadas para períodos de baixa demanda, e não para horários padrão fora do pico de atendimento
• Procedimentos de escalonamento que encaminhem notificações críticas de interrupção diretamente à liderança das operações clínicas, e não apenas à TI
• Suporte a procedimentos em caso de inatividade – documentação ou ferramentas que possibilitem fluxos de trabalho clínicos manuais quando os sistemas em nuvem estiverem indisponíveis

De que forma as equipes de segurança e proteção devem colaborar de maneira diferente das equipes padrão de TI e segurança?

Um ambiente corporativo típico permite que a equipe de segurança defina controles, enquanto as equipes de TI os implementam. A contribuição clínica raramente é envolvida em qualquer um desses processos.

Operar com as tecnologias de nuvem na área da saúde exige um modelo operacional completamente novo, que transfira o papel dos responsáveis pela segurança do paciente, das equipes de informática clínica e dos engenheiros biomédicos de meros destinatários do fluxo de trabalho de decisões de segurança para participantes de pleno direito nesse mesmo fluxo de trabalho.

Esse modelo também altera a forma como o risco é considerado em sua totalidade. Uma equipe de segurança responsável por decidir se é necessária autenticação adicional precisará de contribuições clínicas sobre como controles mais rigorosos afetam o fluxo de trabalho de emergência. Um engenheiro biomédico que busca gerenciar a integração de conectividade precisa ter visibilidade de toda a segmentação da nuvem que afeta a comunicação entre dispositivos.

Políticas de segurança que foram elaboradas sem considerações clínicas tendem a ser contornadas (não porque haja negligência, mas porque introduzem atritos que impedem o atendimento direto de funcionar adequadamente). A colaboração adequada entre segurança e proteção no contexto da saúde é um requisito estruturado, não uma prática recomendada opcional.

Como a segurança na nuvem na área da saúde altera o modelo de responsabilidade compartilhada?

O modelo de responsabilidade compartilhada geralmente detalha como e onde o ônus da segurança é distribuído entre o provedor de nuvem e o cliente. Essa divisão é muito mais complexa em ambientes de saúde, pois o simples fato de hospedar Informações de Saúde Protegidas (PHI) não isenta a organização da responsabilidade regulatória. Ao mesmo tempo, os mecanismos contratuais que regem essa responsabilidade precisam ser muito mais precisos do que aqueles utilizados em contratos empresariais padrão.

Quais são as responsabilidades do provedor de serviços em nuvem em comparação com as da organização de saúde?

O modelo padrão de responsabilidade compartilhada atribui a segurança da infraestrutura ao provedor, enquanto a segurança dos dados é atribuída ao cliente. Essa separação se mantém nos ambientes de nuvem da área da saúde, mas o escopo das obrigações de cada parte é ampliado substancialmente quando se trata de informações de saúde protegidas (PHI):

Por que suposições sobre proteções gerenciadas pelo provedor podem expor dados confidenciais e informações de saúde protegidas (PHI)?

Surpreendentemente, os ataques complexos não são a principal fonte de exposição na nuvem do setor de saúde. Esse título cabe às questões relacionadas a um ambiente mal configurado, construído com base em suposições não verificadas.

Não é incomum que organizações da área da saúde presumam que um provedor de nuvem em conformidade com a HIPAA também signifique que o ambiente construído nele seja, por padrão, compatível com a HIPAA. Essa suposição está incorreta. O que os provedores podem fazer é oferecer todos os recursos técnicos necessários para garantir os requisitos de conformidade, mas a questão de configurar, aplicar e verificar os resultados desses recursos é de responsabilidade do cliente.

Podemos tomar a criptografia em repouso como primeiro exemplo. Ela pode estar habilitada por padrão no armazenamento primário – mas não em camadas de backup, exportações de registros ou ambientes de processamento temporários por onde as PHI transitam durante fluxos de trabalho analíticos. O registro de auditoria pode estar ativado por padrão, mas não no nível de granularidade necessário. Buckets de armazenamento de objetos que contêm PHI podem ter sido criados com políticas de acesso menos restritas durante uma migração e nunca terem sido reforçadas posteriormente.

Cada uma dessas lacunas seria praticamente invisível durante as operações de rotina, mas se destacaria enormemente durante uma auditoria regulatória ou uma investigação de violação.

Que medidas de segurança os contratos e SLAs devem incluir para ambientes de saúde na nuvem?

Um Acordo de Parceria Comercial (BAA) assinado é o requisito contratual mínimo para qualquer ambiente de nuvem que interaja com PHI – e, mesmo assim, o BAA por si só não é suficiente. Os contratos de nuvem na área da saúde devem abordar obrigações de segurança que vão significativamente além de quaisquer termos comerciais padrão:

• Escopo do BAA e cobertura de subprocessadores – o acordo deve nomear explicitamente ou abranger categoricamente todos os subprocessadores que possam ter acesso a PHI
• Direitos de auditoria – a organização de saúde deve manter o direito de conduzir ou encomendar avaliações de segurança do ambiente do provedor
• Prazos para notificação de incidentes – os contratos devem especificar prazos de notificação do provedor ao cliente mais curtos do que o limite máximo de 60 dias previsto pela HIPAA, permitindo tempo para que a organização de saúde cumpra suas próprias obrigações de notificação
• Propriedade das chaves de criptografia – os acordos devem esclarecer se a organização de saúde controla suas próprias chaves de criptografia ou se depende de chaves gerenciadas pelo provedor, e qual o nível de acesso que o provedor mantém
• Residência e soberania dos dados – os contratos devem especificar limites geográficos para o armazenamento e o processamento de PHI, particularmente quando se aplicam os requisitos de localização de dados do GDPR ou em nível estadual
• Exclusão verificada de dados – as cláusulas de rescisão devem exigir confirmação por escrito da exclusão das PHI de todos os níveis de armazenamento, incluindo backups e ambientes de recuperação de desastres
• Compromissos de tempo de atividade e RTO – as garantias de disponibilidade devem ser calibradas clinicamente, e não genéricas

Como a interoperabilidade e a troca de dados alteram o modelo de ameaças?

Os ambientes de nuvem na área da saúde não podem ser sistemas fechados devido à sua própria natureza. Exigências regulatórias, requisitos de coordenação de cuidados e obrigações de acesso dos pacientes exigem que os dados sejam transferíveis – entre prestadores, pacientes, pagadores e aplicativos de terceiros.

Essa natureza aberta não é sequer uma falha de segurança, mas um requisito de projeto. Infelizmente, esse requisito é também o que contribui para a expansão maciça da superfície de ataque que os programas de segurança na área da saúde precisam levar em conta.

Por que as APIs, as integrações FHIR e a conectividade dos prontuários eletrônicos aumentam os riscos de segurança na nuvem?

A Lei 21st Century Cures, juntamente com as regras de interoperabilidade subsequentes do CMS, exige que as organizações de saúde exponham os dados dos pacientes por meio de APIs FHIR (Fast Healthcare Interoperability Resources) padronizadas. Isso transforma a troca de dados externos em uma obrigação legal, em vez de ser uma mera escolha arquitetônica.

Cada ponto de extremidade de API que fornece Informações de Saúde Protegidas (PHI) a um consumidor autorizado também pode ser um ponto de entrada potencial para consumidores não autorizados. A superfície de ataque criada pela interoperabilidade não é incidental, mas estrutural — e cresce a cada nova integração habilitada pelas organizações de saúde.

A conectividade com sistemas de prontuários eletrônicos (EHR) apenas agrava ainda mais essa questão. As plataformas modernas de EHR integram-se regularmente a ambientes de análise hospedados na nuvem, portais de engajamento de pacientes, ferramentas de saúde populacional e sistemas de pagadores. Cada uma dessas conexões representa um fluxo de dados que precisa ser autenticado, criptografado, monitorado e revisado periodicamente.

O modelo de ameaças dos ambientes de saúde não é estático; ele se expande a cada nova integração aprovada – mas raramente se contrai quando as integrações são substituídas ou descontinuadas.

Como a autenticação, as trocas de tokens e a criptografia de dados devem ser protegidas para os fluxos de trabalho clínicos?

Os modelos típicos de autenticação corporativa funcionam em ambientes controlados, nos quais os usuários fazem login a partir de dispositivos conhecidos dentro de redes gerenciadas. Os fluxos de trabalho clínicos não funcionam assim. Os médicos precisam acessar sistemas hospedados na nuvem a partir de estações de trabalho compartilhadas, dispositivos pessoais e locais remotos – muitas vezes sob pressão de tempo, o que torna a autenticação complicada um risco real ao atendimento.

SMART (Substitutable Medical Applications, Reusable Technologies) no FHIR é uma estrutura de autorização baseada em OAuth 2.0 projetada especificamente para contextos de aplicações clínicas, representando a base atual para garantir o acesso baseado em tokens às APIs FHIR.

No entanto, a qualidade de sua implementação varia entre fornecedores e implantações. Os prazos de validade dos tokens, as limitações de escopo e o tratamento dos tokens de atualização exigem configuração explícita, uma vez que as configurações padrão costumam priorizar a conveniência em detrimento da segurança.

Além da autenticação, a aplicação do TLS em todos os fluxos de dados de PHI é obrigatória, e a criptografia deve se estender aos dados em repouso em qualquer sistema em nuvem que receba informações de um EHR ou de uma integração de API.

As principais áreas que exigem atenção explícita, em vez de padrões presumidos:

• Escopo do token limitado ao acesso mínimo necessário aos dados
• Tokens de acesso de curta duração com políticas de atualização controladas
• TLS mútuo para conexões de API servidor a servidor
• Criptografia verificada em todos os níveis de armazenamento que recebem PHI proveniente de APIs

Como a conectividade de aplicativos de terceiros aumenta os riscos à cadeia de suprimentos e de movimentação lateral?

Empresas do setor de saúde que conectam aplicativos de terceiros aos seus ambientes em nuvem herdam uma parte da postura de segurança de cada fornecedor – independentemente de terem avaliado tal postura ou não.

Um aplicativo voltado para pacientes com acesso de gravação ao EHR, uma ferramenta de análise de saúde populacional com amplas permissões de consulta de dados ou uma integração de faturamento com acesso a dados de pedidos de reembolso e demográficos representam, cada um, um ponto de entrada potencial na cadeia de suprimentos. Se um aplicativo de terceiros for comprometido, um invasor pode herdar todo o acesso que esse aplicativo possui. Em ambientes de nuvem da área da saúde, esse acesso frequentemente inclui caminhos de acesso a sistemas que contêm PHI em grande escala.

Questionários regulares de segurança dos fornecedores raramente são suficientes para identificar os riscos específicos que as integrações de APIs clínicas introduzem, e o monitoramento contínuo do comportamento das conexões de terceiros ainda não é uma prática consistente em todo o setor.

Por que os controles de identidade e acesso são essenciais para a segurança da nuvem na área da saúde?

Controlar quem pode acessar o quê e em quais circunstâncias é um dos maiores desafios de segurança para qualquer ambiente de nuvem. No que diz respeito ao setor de saúde, esse mesmo desafio é ampliado ainda mais pela enorme variedade de pessoas que precisam de acesso a sistemas confidenciais, pela urgência com que esse acesso às vezes é necessário e pelas graves consequências tanto da restrição excessiva quanto da restrição insuficiente do acesso.

Como as necessidades de acesso baseadas em funções e em atributos variam entre usuários clínicos e administrativos?

Controles de acesso baseados em funções (RBAC) consistem na ideia de atribuir permissões de sistema de acordo com a função do usuário, em vez de sua identidade individual. Um coordenador de faturamento tem acesso a registros financeiros. Um radiologista tem acesso a sistemas de imagem. Uma enfermeira de enfermaria tem acesso aos registros de administração de medicamentos da ala a que está designada.

O RBAC é a base do gerenciamento de acesso à nuvem na área da saúde e minimiza significativamente a possibilidade de os usuários terem que visualizar informações que não lhes dizem respeito do ponto de vista clínico ou operacional (se implementado corretamente).

A principal questão aqui é que as funções na área da saúde raramente podem ser separadas em categorias bem definidas. Os controles de acesso baseados em atributos (ABAC) ampliam o RBAC ao adicionar vários fatores contextuais: o departamento em que o usuário está trabalhando no momento, a hora do dia, o paciente específico que está tratando ou se está acessando o sistema a partir de um dispositivo aprovado em uma rede interna.

Um médico que atende a vários departamentos, uma enfermeira com privilégios em duas unidades ou um coordenador de cuidados que atua tanto em ambientes de internação quanto em ambulatório têm, todos, necessidades complexas de acesso que uma definição estática de função teria dificuldade em acomodar de forma clara. O ABAC permite que nuances como essas sejam expressas como uma política, em vez de serem tratadas como exceções.

Por que o acesso sensível ao contexto e com o mínimo de privilégios é fundamental para cenários de atendimento ao leito e de emergência?

O acesso com o mínimo de privilégios é uma prática de segurança bem estabelecida — o princípio de que qualquer usuário deve ter acesso apenas ao mínimo necessário de dados e sistemas exigidos para sua tarefa atual. Na maioria dos ambientes corporativos, a aplicação dessa prática é, em grande parte, um exercício técnico e administrativo. Na área da saúde, no entanto, essa prática contradiz significativamente as realidades do atendimento de emergência.

Um médico traumatologista que atende um paciente inconsciente que chega sem identificação precisa de acesso imediato a todos os prontuários médicos do paciente (seu histórico de alergias, medicamentos atuais e diagnósticos anteriores). O fato de que tal médico possa não ter tido nenhum relacionamento prévio de tratamento com o paciente significa que a aplicação estrita do modelo de privilégios mínimos bloqueará exatamente o acesso que o atendimento médico exige.

É aqui que surge o modelo de acesso de emergência. Trata-se de um mecanismo controlado de derrogacão que permite aos profissionais de saúde contornar as restrições padrão de acesso em emergências reais, ao mesmo tempo em que registra todas as ações realizadas durante essa sessão para análise posterior.

O acesso de emergência não é uma falha de segurança, mas uma válvula de segurança deliberada e auditável. No entanto, ele pode se tornar um problema de segurança quando seu escopo é mal definido, seu registro é inconsistente ou é utilizado com frequência suficiente para perder qualquer significado como exceção.

É por isso que são necessárias políticas de acesso sensíveis ao contexto. Elas levam em consideração a localização do paciente, a atribuição da equipe de atendimento e a urgência clínica para reduzir a frequência do uso do modelo de acesso de emergência, sem eliminá-lo como opção.

Como o acesso temporário, contingente e de fornecedores deve ser governado e auditado?

Os ambientes de nuvem na área da saúde frequentemente acomodam usuários cujas necessidades de acesso são, por padrão, limitadas no tempo. Isso inclui enfermeiros itinerantes e médicos substitutos que cobrem lacunas de curto prazo, fornecedores terceirizados que realizam manutenção de sistemas, consultores de implementação com privilégios administrativos temporários e auditores externos que analisam a documentação de conformidade. Conceder acesso a qualquer um desses usuários é um risco que continua a se expandir sempre que não é gerenciado ativamente.

Os requisitos essenciais são simples, mesmo que a execução consistente não seja:

• As concessões de acesso para usuários temporários devem conter datas de validade explícitas, definidas no momento do provisionamento
• O acesso de fornecedores e terceiros deve ser restrito aos sistemas e dados específicos necessários para o contrato — nada além disso
• Todas as sessões de acesso temporário devem ser registradas com detalhes suficientes para permitir uma trilha de auditoria completa
• As revisões de acesso devem ser agendadas de forma proativa, em vez de serem acionadas apenas por eventos de desligamento

A situação de falha mais comum nem sequer é maliciosa, mas sim administrativa. Isso inclui credenciais temporárias que nunca foram revogadas, contas de fornecedores que permaneceram ativas após o término do contrato e acesso de prestadores de serviços que se expandiu gradualmente sem revisão formal.

Como os dispositivos médicos e a IoT alteram os requisitos de segurança na nuvem?

Os dispositivos médicos e os equipamentos clínicos conectados possuem sua própria categoria de risco que não pode ser adequadamente abordada pelas orientações padrão de IoT. Tais dispositivos não são meros sensores prediais ou termostatos inteligentes, mas sistemas críticos para a segurança com impacto direto sobre o paciente – razão pela qual as restrições de segurança sob as quais operam diferem substancialmente de tudo o mais em um ambiente típico de nuvem.

Por que as restrições dos dispositivos (sistemas operacionais legados, aplicação limitada de patches) são importantes para a integração na nuvem?

Muitos dispositivos médicos (bombas de infusão, sistemas de imagem, monitores de pacientes, ventiladores) utilizam sistemas operacionais desatualizados. O Windows 7, o Windows XP e até mesmo plataformas mais antigas continuam em uso clínico ativo até hoje. Isso geralmente ocorre quando os fabricantes de dispositivos desenvolvem e certificam seus softwares para uma versão específica do sistema operacional, o que significa que substituir ou atualizar esse software exigiria passar por toda a revisão regulatória da FDA mais uma vez.

Essa é a principal razão pela qual a aplicação de patches – o mecanismo mais básico para lidar com vulnerabilidades de software – não está disponível para grande parte dos dispositivos conectados a ambientes de nuvem na área da saúde.

Um dispositivo que não pode receber patches também não pode ser considerado seguro no sentido convencional. Sempre que esses dispositivos precisam transmitir algum tipo de telemetria para plataformas em nuvem ou receber atualizações de configuração de sistemas de gerenciamento hospedados na nuvem, a segurança dessa conexão precisa ser tratada exclusivamente no lado da rede/nuvem, já que o próprio dispositivo mal pode oferecer qualquer proteção nesse sentido.

Como a telemetria, a identidade do dispositivo e a segmentação devem ser projetadas para dispositivos críticos para a segurança?

A segmentação de rede é a primeira linha de defesa em ambientes relacionados à área da saúde. Os dispositivos médicos devem ser mantidos em segmentos de rede isolados, com acesso apenas aos sistemas em nuvem específicos de que necessitam. Um monitor de pacientes não deve ser capaz de estabelecer conexão com armazenamento em nuvem, servidores de administração, rede externa ou qualquer outra coisa, exceto aquele sistema específico na nuvem. A segmentação não corrige a vulnerabilidade do próprio dispositivo, mas pode, pelo menos, limitar o “raio de ação” de uma das vulnerabilidades que estiver sendo explorada.

A identidade do dispositivo é igualmente importante. Cada dispositivo que se conecta a um ambiente em nuvem deve comprovar sua identidade por meio de uma credencial exclusiva (idealmente, um certificado vinculado ao dispositivo, e não apenas dados básicos de login). Dessa forma, quaisquer dispositivos com padrões de comportamento inesperados podem ser identificados e tratados sem afetar outros dispositivos na mesma rede. Ser capaz de manter um inventário preciso dos dispositivos conectados a qualquer momento também é uma vantagem.

Os fluxos de telemetria provenientes de dispositivos médicos também devem ser monitorados quanto a anomalias. Qualquer tipo de padrão incomum pode ser um fator identificador de comprometimento ou configuração incorreta (seja volumes incomuns de dados, destinos de conexão inesperados ou padrões de comunicação que se desvio do comportamento normal de um dispositivo).

Como a análise no lado da nuvem pode introduzir riscos à privacidade para dados gerados por dispositivos?

Existe uma suposição comum em torno da telemetria de dispositivos que considera que tais dados sejam, por natureza, de baixa sensibilidade, assemelhando-se mais à saída de uma máquina do que a Informações de Saúde Protegidas (PHI). Esse tipo de suposição costuma estar errado.

Fluxos contínuos de dados provenientes de dispositivos como medidores de glicose, unidades de telemetria cardíaca ou monitores respiratórios podem conter informações suficientes para identificar pacientes específicos, inferir diagnósticos e reconstruir cronogramas de atendimento (mesmo após a remoção de identificadores óbvios). Sempre que tais dados são transferidos para plataformas de análise baseadas na nuvem, eles podem ser agregados, retidos, compartilhados com fornecedores terceirizados de análise ou até mesmo utilizados para treinar modelos de maneiras incomuns.

O risco de reidentificação para dados de saúde gerados por dispositivos é significativo e frequentemente subestimado. A importância crítica dessas informações significa que elas merecem, no mínimo, o mesmo tratamento de manuseio de PHI que qualquer dado classificado como prontuário médico.

O que as organizações de saúde geralmente percebem tarde demais após transferir dados confidenciais para a nuvem?

Na área da saúde, a adoção da nuvem frequentemente ultrapassa o desenvolvimento de programas de segurança projetados para apoiá-la. As lacunas de segurança que surgem como resultado dessa questão muitas vezes passam despercebidas até que algo dê errado.

Por que ambientes de nuvem tecnicamente em conformidade ainda sofrem violações de dados de saúde?

As avaliações de conformidade regulatória só podem medir se os controles de segurança necessários existem em um determinado momento. Esses testes são incapazes de determinar se esses controles ainda funcionarão corretamente meses depois, quando o ambiente ao seu redor tiver mudado.

A própria infraestrutura em nuvem raramente é estática e inativa. Os desenvolvedores criam novos recursos de armazenamento, integrações entre sistemas são adicionadas regularmente e as permissões são frequentemente ajustadas para resolver rapidamente problemas de acesso (e nunca revisadas posteriormente). Nenhuma dessas mudanças, por si só, desencadeará uma revisão de conformidade, mas cada uma delas ainda pode ser considerada uma oportunidade para que o ambiente se afaste do estado que permitiu a aprovação na última auditoria.

Temas como esses precisam ser mencionados porque a configuração incorreta continua sendo a principal causa de violações de dados na nuvem até hoje — nenhum dos sofisticados ataques de Estados-nação ou explorações de dia zero chega nem perto disso. Uma parte substancial dos incidentes na nuvem no setor de saúde é resultado de:

• Buckets de armazenamento expostos
• Políticas de acesso excessivamente permissivas
• Registro de eventos desativado

É relativamente comum que uma organização da área da saúde seja aprovada em uma auditoria da HIPAA e, poucos meses depois, sofra uma violação que poderia ter sido evitada. Não havia nada de errado com o ambiente da organização no momento da auditoria, mas o próprio ambiente mudou. É por isso que a conformidade é um status, não uma garantia.

Como as suposições sobre a migração para a nuvem enfraquecem silenciosamente a segurança na nuvem no setor da saúde?

O pior erro de migração que se pode cometer é presumir que os controles de segurança locais funcionarão exatamente da mesma maneira depois de serem transferidos para a nuvem. Essa abordagem é às vezes chamada de lift-and-shift – pegar cargas de trabalho pré-existentes e transferi-las para a infraestrutura em nuvem sem fazer nenhuma alteração para se adaptar ao novo ambiente. É uma solução rápida para alguns problemas, mas também é extremamente arriscada.

• As regras de firewall que protegiam um data center não se aplicam aos buckets de armazenamento na nuvem
• Os perímetros de rede que continham o movimento lateral no ambiente local não existem da mesma forma em um ambiente de nuvem
• Os controles de acesso que uma equipe de TI local gerenciava manualmente não são migrados junto com os dados e precisam ser deliberadamente reconstruídos na nuvem

A causa principal de quase todas as vulnerabilidades relacionadas à migração resume-se à confusão em torno do modelo de responsabilidade compartilhada. As empresas que migram seus dados para um provedor de nuvem presumem que as configurações padrão de segurança do provedor irão cobrir o que sua equipe interna costumava fazer no local – o que não ocorre.

Uma das constatações mais consistentemente documentadas após a migração diz respeito às funções de Gerenciamento de Identidade e Acesso (IAM) com permissões excessivas: configurações criadas com amplos direitos de acesso durante a migração para evitar atritos, marcadas como temporárias e que nunca foram removidas posteriormente. Essas funções podem permanecer passivamente no ambiente por um longo tempo, proporcionando aos invasores que conseguirem acessá-las muito mais permissão do que jamais deveria ser concedida a um único usuário.

Problemas como esses nunca são dramáticos ou óbvios, já que os sistemas continuam funcionando, os logs continuam sendo gerados e assim por diante. Os problemas começam a aparecer durante um incidente, quando se descobre que o bucket mal configurado estava acessível há meses, ou que a função com permissões excessivas tem acesso de leitura a todos os conjuntos de dados de Informações de Saúde Protegidas (PHI) no ambiente.

Por que as falhas de backup e recuperação costumam ser mais prejudiciais do que o ataque original à nuvem?

Muitos ataques à nuvem podem apenas interromper as operações no momento. Um evento de recuperação malsucedido, por outro lado, ameaça prolongar essa interrupção indefinidamente.

Não é incomum que organizações da área da saúde descubram problemas críticos em seus backups na nuvem durante ataques de ransomware — justamente quando menos podem se dar ao luxo de enfrentá-los. Isso inclui:

• Os backups estavam armazenados no mesmo ambiente que os sistemas primários e foram criptografados junto com eles
• As tarefas de backup estavam sendo concluídas com sucesso no painel — mas os dados restaurados estavam incompletos ou corrompidos
• A recuperação nunca havia sido testada de ponta a ponta em um cenário realista
• As políticas de retenção foram definidas incorretamente, deixando os pontos de restauração muito antigos para serem clinicamente úteis

O segundo ponto sobre os relatórios de backup merece atenção especial. Os painéis de backup, devido à sua natureza, relatam a conclusão da tarefa, não o sucesso da restauração. É perfeitamente possível que uma tarefa seja concluída sem erros, mas crie um backup que não possa ser usado para recuperar um sistema em funcionamento. A única maneira de saber se um backup funciona é testá-lo – mas o teste é algo que muitas empresas deixam de fazer regularmente.

Backups imutáveis são a contramedida direta para os riscos de backup na era do ransomware. Trata-se de cópias que só podem ser gravadas uma vez, sem a possibilidade de serem modificadas, excluídas ou criptografadas posteriormente. A imutabilidade não impede que um ataque ocorra, mas pode garantir que a recuperação continue sendo possível após a ocorrência de um ataque.

A ausência de backups imutáveis é uma questão crítica, uma vez que muitos autores de ransomware com acesso suficiente aos sistemas primários frequentemente também têm acesso aos backups, com o potencial de arruinar qualquer plano de backup em sua essência.

Como geralmente ocorre uma violação de dados na nuvem no setor de saúde?

As violações em ambientes de nuvem do setor de saúde raramente começam com uma exploração técnica complexa. Esses eventos começam com uma pessoa e se agravam rapidamente a partir daí.

Como os invasores passam do phishing para o comprometimento de sistemas de saúde baseados na nuvem?

Um único e-mail geralmente é suficiente para iniciar toda a cadeia. Qualquer membro da equipe pode clicar em um link que pareça uma identificação de TI de rotina ou uma atualização do portal do paciente. Assim que inserem suas credenciais, o ataque passa para uma fase diferente.

O caminho do phishing até o acesso ao ambiente de nuvem é muito mais curto do que a maioria das empresas imagina, já que muitos profissionais da área da saúde ainda utilizam o mesmo conjunto de credenciais em diferentes sistemas (enquanto os consoles de gerenciamento da nuvem são acessíveis a partir de qualquer navegador).

Não há necessidade de um invasor violar um perímetro quando possui uma combinação válida de nome de usuário e senha – ele pode simplesmente fazer login como qualquer outra pessoa.

Após a entrada, o foco muda para a expansão e a persistência. O invasor tenta localizar ambientes de armazenamento em nuvem que contenham o maior volume de dados, contas de serviço com as permissões mais amplas e sistemas conectados que possam ser usados para obter PHI adicional.

A maioria dos ataques à nuvem no setor de saúde chega ao estágio de exfiltração de PHI poucos dias após a entrada inicial. Quando o comportamento anômalo é detectado, é altamente provável que o invasor já tenha alcançado seu objetivo.

Por que as plataformas de armazenamento em nuvem e as APIs do setor de saúde estão cada vez mais na mira dos invasores?

Tanto as APIs do setor de saúde quanto as plataformas de armazenamento em nuvem são alvo principalmente devido ao seu enorme retorno sobre o investimento.

Um único bucket de armazenamento em nuvem mal configurado em um ambiente de saúde é suficiente para expor milhões de registros de pacientes. Enquanto isso, credenciais de API comprometidas seriam capazes de oferecer acesso contínuo e autenticado a um fluxo de dados atualizado em tempo real.

Dados da área da saúde são uma mercadoria muito mais valiosa nos mercados criminosos do que dados financeiros. Um prontuário médico completo vale muitas vezes mais do que um número de cartão de crédito, pois contém dados que são imutáveis e podem ser aproveitados de várias maneiras por um período prolongado.

A natureza acessível das APIs também as torna alvos atraentes. Uma API é necessária para transferir informações entre sistemas de maneira integrada, o que as torna acessíveis, funcionais e consultáveis em grande escala sem acionar muitos alarmes no ambiente.

Que interrupções operacionais ocorrem após os invasores acessarem ambientes de nuvem da área da saúde?

Uma violação na nuvem da área da saúde tem um impacto clínico e operacional de longo alcance que se estende além dos próprios sistemas comprometidos. Entre as interrupções comuns estão:

• Indisponibilidade do prontuário eletrônico (EHR) – os profissionais de saúde perdem o acesso a históricos de medicação, planos de tratamento e resultados de diagnósticos, sendo forçados a recorrer a processos manuais baseados em papel
• Desvio de ambulâncias – hospitais operando com procedimentos de contingência podem declarar emergências internas que redirecionam pacientes que chegam para outras unidades
• Procedimentos cancelados – cirurgias eletivas e não urgentes, consultas de exames de imagem e atendimentos ambulatoriais são adiados quando os sistemas que suportam as verificações pré-procedimento estão offline
• Atrasos na farmácia e na medicação – os sistemas de prescrição eletrônica ficam fora do ar, introduzindo riscos no momento da administração de medicamentos
• Paralisia no faturamento e nos pedidos de reembolso – os sistemas do ciclo de receita que dependem da infraestrutura em nuvem param de processar, criando atrasos financeiros que persistem muito tempo após a restauração dos sistemas clínicos
• Exposição regulatória e jurídica – as obrigações de notificação de violação são acionadas imediatamente, aumentando a carga de trabalho de conformidade ao mesmo tempo em que a recuperação operacional consome o máximo da capacidade organizacional

As interrupções clínicas podem ser resolvidas em questão de dias ou semanas, mas as consequências regulatórias, legais e de reputação de um único ataque tendem a durar muito mais tempo do que isso.

Por que a resposta a incidentes e a análise forense devem ser adaptadas para as nuvens do setor de saúde?

O objetivo principal da resposta a incidentes para a maioria dos setores é conter a ameaça e recuperar o ambiente. O setor de saúde acrescenta outro objetivo a isso: manter os pacientes seguros durante o processo. Essas duas metas nem sempre apontam na mesma direção.

Como a necessidade de continuidade clínica rápida altera as estratégias de contenção de incidentes?

As doutrinas padrão de resposta a incidentes dependem fortemente do isolamento. Sempre que um sistema é comprometido, ele é colocado offline e desconectado da rede para impedir que o ataque se espalhe. É uma boa abordagem para a maioria dos sistemas que dão suporte às operações comerciais. Infelizmente, o mesmo não pode ser dito dos sistemas que dão suporte ao atendimento ativo ao paciente.

Desligar um prontuário eletrônico do paciente (EHR) durante um incidente ativo interrompe o acesso dos profissionais de saúde aos registros de medicação, históricos de alergias e dados de monitoramento em tempo real. Tentar isolar um ambiente em nuvem que suporta a telemetria da UTI ou a dispensação de medicamentos cria um risco clínico direto. A própria ação de contenção pode causar danos, e é por isso que as equipes de resposta a incidentes em ambientes de saúde não podem simplesmente seguir o manual padrão com o qual todos trabalham.

É necessária aqui uma abordagem mais cirúrgica. Em vez de realizar um isolamento amplo, as equipes de resposta a incidentes (IR) da área da saúde precisam ter estratégias de contenção predefinidas, capazes de distinguir entre sistemas que podem ser colocados offline e ambientes que devem permanecer disponíveis a qualquer custo. Todas essas decisões devem ser tomadas bem antes da ocorrência de um incidente, pois tomar decisões em tempo real sobre quais sistemas clínicos podem ser interrompidos com segurança durante uma violação de segurança é uma prática de alto risco.

Quais controles forenses e registros são necessários para apoiar tanto as investigações jurídicas quanto as clínicas?

A maioria das violações típicas na nuvem do setor de saúde exige pelo menos duas investigações simultâneas:

1. A análise de conformidade e contencioso
2. A análise do comprometimento dos dados clínicos e do impacto nas decisões de atendimento ao paciente

O elemento crítico que cada investigação buscará basear-se-á exatamente nas mesmas evidências: os registros. Praticamente todo o valor forense de um ambiente em nuvem é determinado pelas decisões de registro tomadas bem antes do incidente. As evidências que não foram capturadas também não podem ser recuperadas posteriormente.

Os principais requisitos de registro para ambientes de nuvem na área da saúde incluem:

• Registros de acesso cobrindo todas as interações com PHI — quem acessou, quando, de onde e quais ações foram realizadas
• Registros de autenticação, incluindo tentativas de login malsucedidas, eventos de contorno de MFA e escalonamento de privilégios
• Registros de chamadas de API capturando todas as solicitações às interfaces de gerenciamento da nuvem e às APIs de dados de saúde
• Registros de fluxo de rede suficientes para reconstruir movimentos laterais e caminhos de exfiltração de dados
• Registros de alterações de configuração que rastreiam modificações nas permissões de armazenamento, funções do IAM e regras de grupos de segurança

Os períodos de retenção desses registros devem estar alinhados tanto com a exigência de documentação de seis anos da HIPAA quanto com quaisquer regulamentações estaduais aplicáveis. Os registros devem ser armazenados separadamente dos sistemas que monitoram, a fim de impedir que o invasor que obteve acesso à infraestrutura primária altere ou exclua as evidências.

Como os exercícios de simulação e os manuais de procedimentos devem diferir dos cenários exclusivos para empresas?

A maioria dos exercícios simulados de resposta a incidentes (IR) corporativos envolve, normalmente, as equipes de TI e de segurança (as equipes jurídica e de comunicação também participam, por vezes). Os exercícios simulados na área da saúde exigem um escopo significativamente mais amplo — e cenários significativamente diferentes.

A liderança das operações clínicas deve estar presente, uma vez que as decisões sobre quais sistemas devem ser colocados offline precisam ser tomadas sob autoridade clínica. A engenharia biomédica deve estar envolvida sempre que os cenários envolverem dispositivos conectados. Os responsáveis pela privacidade devem participar das árvores de decisão relativas à notificação de violações.

Os próprios cenários devem refletir ameaças específicas do setor de saúde:

• Ransomware que criptografa simultaneamente tanto os sistemas primários de prontuários eletrônicos (EHR) quanto os backups na nuvem
• Uma credencial de API comprometida que proporciona acesso silencioso aos dados dos pacientes por um período prolongado
• Uma configuração incorreta na nuvem que expôs informações de saúde protegidas (PHI) publicamente por um período indeterminado
• Uma violação de segurança em um fornecedor terceirizado que se propaga para o ambiente de nuvem da organização de saúde por meio de uma integração ativa

Um manual de procedimentos não pode ser considerado suficiente para o contexto da saúde se não incluir a ativação do procedimento de tempo de inatividade (fluxos de trabalho manuais aos quais a equipe clínica recorre quando os sistemas estão indisponíveis). Essa seção da resposta apresenta o maior risco à segurança do paciente e, na maioria das vezes, está ausente dos planos que foram adaptados de setores não clínicos.

Por que a segurança na nuvem na área da saúde é mais difícil do que a segurança tradicional na nuvem corporativa?

Todos os setores lidam, em certa medida, com desafios de segurança na nuvem, e a área da saúde não é exceção — ela ainda traz um conjunto de restrições que não se aplicam a nenhum outro setor. A dificuldade da segurança na nuvem na área da saúde é estrutural, não técnica.

Por que os prestadores de serviços de saúde não podem simplesmente restringir todo o acesso à nuvem?

A área da saúde já ultrapassou o ponto em que a restrição seria uma estratégia viável. Muitos dos elementos atuais de um ambiente de saúde são praticamente impossíveis sem o armazenamento em nuvem. Por exemplo:

• Os fluxos de trabalho clínicos dependem de plataformas de prontuários eletrônicos (EHR) hospedadas na nuvem
• Os pacientes esperam ter acesso aos seus prontuários por meio de portais on-line
• A telessaúde opera em infraestrutura de nuvem
• Imagens diagnósticas são armazenadas e transmitidas pela nuvem, pois os tamanhos dos arquivos envolvidos tornam o armazenamento local impraticável em grande escala

Restringir o acesso à nuvem na área da saúde de forma significativa não tornará o sistema mais seguro, mas o tornaria incapaz de funcionar. A questão nunca é permitir ou negar o acesso à nuvem – trata-se de tornar esse acesso o mais seguro possível sem prejudicar os cuidados de saúde que ele viabiliza.

Como os fluxos de trabalho dos atendimentos de emergência criam compromissos inevitáveis em relação à segurança na nuvem?

A política de segurança não segue o mesmo cronograma dos atendimentos de emergência. Uma equipe de trauma que lida com um paciente em estado crítico não esperaria enquanto o processo de autenticação em várias etapas é realizado. Um médico que está substituindo em uma ala desconhecida às 3h da manhã não esperará que uma solicitação de acesso seja aprovada enquanto analisa o histórico médico de um paciente cujo quadro está se deteriorando.

A própria natureza dos cuidados de emergência significa que quaisquer controles de segurança que introduzam atritos acabam sendo contornados, e não seguidos. Na área da saúde, esses contornos também costumam ser justificados clinicamente, tornando-os extremamente difíceis de prevenir apenas com políticas.

Controles de segurança mais rígidos podem reduzir o risco em condições estáveis, mas também aumentam esse risco em situações de emergência. O compromisso é real e completamente inevitável. A segurança de uma unidade de saúde deve ser abordada não como um meio para atingir um fim, mas como uma lista de escolhas fundamentadas e documentadas sobre onde esses riscos podem ser aceitos (levando em conta o parecer clínico, não apenas a segurança).

Por que o acesso contínuo aos dados cria riscos únicos de cibersegurança nos sistemas de saúde?

A maioria dos sistemas corporativos tende a ter ritmos naturais que incluem:

• Pico de uso durante o horário comercial
• Atividade reduzida durante a madrugada
• Janelas de manutenção nos finais de semana

Isso não se aplica aos sistemas de saúde. Plataformas de prontuários eletrônicos (EHR), sistemas farmacêuticos hospedados na nuvem e ambientes de monitoramento de pacientes operam em plena capacidade 24 horas por dia, todos os dias do ano.

A disponibilidade contínua exclui certas opções nas quais as equipes de segurança corporativas costumam se basear. Programar tempo de inatividade para o gerenciamento de patches torna-se, essencialmente, uma discussão sobre o gerenciamento de riscos clínicos. Sistemas projetados para detectar anomalias no tráfego normal da rede devem levar em conta que, na área da saúde, há muito poucos períodos fora do pico no sentido convencional.

Um sistema sempre ativo é um sistema constantemente exposto. Construir segurança em torno dessa realidade exige uma abordagem completamente diferente daquela utilizada para proteger a maioria das outras infraestruturas em diversos setores.

Como a arquitetura nativa da nuvem altera a segurança na nuvem em ambientes de saúde?

Os ambientes tradicionais de TI na área da saúde foram construídos em torno de grandes aplicativos centralizados, nos quais os dados residiam em locais previsíveis e os limites de segurança eram fáceis de definir. O advento da arquitetura nativa da nuvem alterou esses dois fatores simultaneamente.

Por que os microsserviços, contêineres e arquitetura sem servidor exigem uma nova modelagem de ameaças para as PHI?

Em um aplicativo monolítico tradicional, a maior parte da funcionalidade ocorre dentro do mesmo sistema. O fluxo é simples: as PHI chegam, são processadas e armazenadas. Tudo isso ocorre dentro de um único sistema com limites de segurança bastante bem compreendidos.

Aplicativos nativos da nuvem se comportam de maneira diferente. Uma arquitetura de microsserviços transforma esse único aplicativo em dezenas ou centenas de serviços menores, que são independentes, mas podem se comunicar entre si por meio da rede. Cada um desses serviços pode lidar com PHI brevemente (recebendo-as, transformando-as, repassando-as) sem armazená-las permanentemente.

Embora essa abordagem moderna seja extremamente eficiente, ela também significa que as PHIs estão constantemente transitando por um grande número de componentes, sendo que cada componente representa um ponto potencial de exposição.

Contêineres – pequenos pacotes portáteis que executam serviços individuais – são efêmeros por natureza, de modo que podem surgir, realizar sua função e, em seguida, desaparecer. A própria natureza dos contêineres os torna particularmente problemáticos quando se trata de monitoramento consistente e aplicação de patches de segurança no sentido convencional.

Funções sem servidor levam essa abordagem um passo adiante, com o código sendo executado em resposta a um gatilho, operando brevemente e, em seguida, sendo interrompido. Dessa forma, não há um servidor persistente para monitorar ou proteger, pelo menos da maneira tradicional. Sempre que as PHI passam por uma função sem servidor, a janela de oportunidade para observá-las e registrá-las permanece muito pequena.

Todas essas características e abordagens exigem um modelo de ameaças que é drasticamente mais distribuído do que qualquer coisa com a qual a segurança de TI tradicional na área da saúde foi criada para lidar.

Como os pipelines de CI/CD e o DevSecOps devem ser adaptados para a conformidade na área da saúde?

Um pipeline de CI/CD (Integração Contínua e Implantação Contínua) é um mecanismo automatizado que recebe o código escrito pelos desenvolvedores, o testa e o envia para produção. Esse processo pode ser muito rápido no contexto de ambientes nativos da nuvem. Novas configurações, serviços atualizados e políticas de acesso modificadas podem entrar em operação em questão de minutos.

Se as verificações de segurança não forem incorporadas ao pipeline desde o início, esse tipo de velocidade torna-se um risco à conformidade. DevSecOps é a prática de incorporar etapas de validação de segurança ao processo de desenvolvimento e implantação, em vez de revisá-las separadamente posteriormente.

O que isso significa no contexto da área da saúde:

• Verificar automaticamente o código da infraestrutura em busca de configurações incorretas antes da implantação
• Sinalizar recursos de armazenamento ou pontos de extremidade de API que exporiam Informações de Saúde Protegidas (PHI) sem criptografia
• Bloquear implantações que removeriam os registros de auditoria obrigatórios
• Validar se os novos serviços atendem aos requisitos de segurança relevantes para o BAA antes de entrarem em produção

Identificar lacunas de conformidade quando sua correção é mais econômica (antes que o código entre em operação) é o objetivo principal dessa abordagem, que é significativamente mais eficaz do que descobrir todos os problemas após um incidente ou durante uma auditoria.

Quais controles automatizados protegem a infraestrutura de nuvem da área da saúde contra configurações incorretas?

A revisão manual da configuração é claramente insuficiente, dada a velocidade com que os ambientes nativos da nuvem se alteram. Controles automatizados são praticamente necessários para monitorar continuamente o ambiente e detectar desvios à medida que ocorrem.

As principais categorias de controles que vale a pena ter em mente incluem:

• Gerenciamento da Postura de Segurança na Nuvem (CSPM) — ferramentas que verificam continuamente os ambientes de nuvem em busca de configurações incorretas, comparando as configurações atuais com padrões de segurança e estruturas de conformidade em tempo real
• Verificação de Infraestrutura como Código (IaC) — análise automatizada do código utilizado para definir a infraestrutura em nuvem, detectando configurações inseguras antes mesmo de serem implantadas
• Detecção de desvios — monitoramento que identifica quando um ambiente de nuvem em operação se desvia de sua configuração de referência aprovada, sinalizando alterações não autorizadas ou acidentais à medida que ocorrem
• Aplicação de políticas como código — regras de segurança escritas como políticas legíveis por máquina que são automaticamente aplicadas e impostas em todos os recursos em nuvem, eliminando a dependência da revisão manual

É importante mencionar que nenhum desses controles elimina completamente a necessidade de supervisão humana, mas eles buscam garantir que o volume e o ritmo das mudanças em ambientes nativos da nuvem não sejam capazes de superar a capacidade da equipe de segurança de acompanhá-las.

Como as organizações da área da saúde podem melhorar a segurança na nuvem durante a adoção da nuvem?

Simplesmente compreender por que a segurança na nuvem na área da saúde é tão desafiadora representa apenas metade do trabalho. A outra metade consiste em criar programas que sejam práticos o suficiente para serem efetivamente seguidos pela equipe clínica, pelas equipes de segurança e pela liderança ao mesmo tempo.

Quais riscos da computação em nuvem as organizações da área da saúde devem abordar durante a migração?

A fase de maior risco na jornada de adoção da nuvem é a migração — a tomada rápida de decisões sob a pressão do projeto resulta em anos de dívida de segurança. Antes que as Informações de Saúde Protegidas (PHI) sejam transferidas para qualquer ambiente de nuvem, as organizações devem abordar:

• Classificação de dados — identificar quais dados constituem PHI, onde estão armazenados atualmente e quais serviços em nuvem terão acesso a eles
• Cobertura do BAA — confirmar que os Acordos de Parceria Comercial (BAA) assinados estejam em vigor com todos os provedores e subprocessadores que lidarão com PHI
• Projeto de controle de acesso — definir políticas de acesso baseadas em funções para o ambiente em nuvem antes da migração, e não depois
• Configuração de registros — estabelecer o escopo dos registros de auditoria, os períodos de retenção e o isolamento do armazenamento como parte da implantação inicial
• Verificação da criptografia — confirmar que a criptografia abrange todos os níveis de armazenamento, caminhos de trânsito e ambientes de processamento que lidarão com PHI
• Testes de backup e recuperação — validar se os processos de backup funcionam corretamente no ambiente de nuvem antes que os sistemas primários sejam migrados
• Mapeamento de responsabilidades compartilhadas — documentar explicitamente quais obrigações de segurança cabem ao provedor e quais cabem à organização

Como as organizações de saúde podem reduzir riscos em um ambiente de nuvem durante a adoção em fases?

Mudar tudo para a nuvem de uma só vez maximiza tanto a velocidade quanto o risco. Uma abordagem gradual, passo a passo, permite verificar os controles de segurança em cada etapa antes do início da próxima.

Um ponto de partida razoável é testar a adoção da nuvem com cargas de trabalho de menor sensibilidade — sistemas administrativos, ferramentas de colaboração não clínicas ou ambientes de análise anonimizados. Isso dá às equipes de segurança e de TI tempo para compreender como os controles do provedor de nuvem realmente se comportam na prática, identificar lacunas entre as configurações padrão de segurança presumidas e as reais e adquirir familiaridade operacional antes que as Informações de Saúde Protegidas (PHI) sejam envolvidas.

Cada fase deve incluir um ponto de verificação de validação formal antes da expansão. Isso significa testar o backup e a recuperação, revisar os registros de acesso em busca de comportamentos inesperados, confirmar se o registro está capturando o que deveria e verificar se os limites de responsabilidade compartilhada estão sendo mantidos na prática.

A adoção em fases não significa uma adoção mais lenta da nuvem. Trata-se de uma adoção da nuvem que não gera atrasos nas correções que acompanham a organização por anos.

Quais métricas e KPIs os líderes do setor de saúde devem acompanhar para medir a maturidade da segurança na nuvem?

Determinar a maturidade da segurança é um verdadeiro desafio sem medições específicas. As métricas descritas abaixo têm como objetivo ajudar os líderes do setor de saúde a verificar se as medidas de segurança na nuvem estão operacionais e não apenas implementadas.

Como a Bacula Systems pode melhorar a segurança na nuvem em ambientes de saúde?

Proteger as Informações de Saúde Protegidas (PHI) na nuvem exige mais do que controles preventivos — é também necessário ter a certeza de que a recuperação é possível quando esses controles são testados adequadamente. A Bacula Systems oferece recursos de backup de nível empresarial, bem como recuperação e gerenciamento de dados, criados levando em conta a complexidade dos ambientes modernos de nuvem no setor de saúde.

Onde a Bacula Systems faz a diferença diretamente:

• Backups imutáveis — cópias de backup que não podem ser modificadas, excluídas ou criptografadas por um invasor, mesmo que este tenha acesso administrativo aos sistemas primários
• Recuperação granular — restaure arquivos individuais, bancos de dados ou sistemas inteiros sem a necessidade de recuperar tudo de uma só vez, reduzindo o tempo de inatividade clínica durante um incidente
• Controle de chaves de criptografia — as organizações mantêm a propriedade de suas próprias chaves de criptografia, em vez de delegar essa responsabilidade às configurações padrão de um provedor de nuvem
• Registros prontos para auditoria — registros detalhados de backup e recuperação que atendem aos requisitos de documentação da HIPAA e atendem às necessidades de investigação forense
• Suporte híbrido e multicloud — proteção consistente de dados em ambientes locais, de nuvem privada e de nuvem pública a partir de uma única interface de gerenciamento
• Implantação flexível — a arquitetura do Bacula se adapta à infraestrutura de saúde existente, em vez de exigir uma abordagem de substituição total

Em última análise, todos os programas de segurança em nuvem para o setor de saúde podem ser avaliados com uma única pergunta: quando algo dá errado, com que rapidez e com que rigor as operações podem ser restauradas? O Bacula Systems foi projetado para fornecer uma resposta definitiva — em ambientes de TI de saúde reais, híbridos, multicloud e legados.

Perguntas frequentes

Por que as organizações de saúde enfrentam dificuldades para manter políticas consistentes de segurança em nuvem em ambientes de saúde multicloud e híbridos?

Os ambientes de nuvem utilizados pelas organizações de saúde raramente são construídos do zero. Frequentemente, eles são acumulados ao longo de anos de compras independentes, fusões, aquisições e contratos com fornecedores. Cada ambiente possui seu próprio modelo de controle de acesso, seu próprio mecanismo de registro de logs e seu próprio conjunto de ferramentas para monitoramento de segurança. A aplicação de uma política para a proteção de Informações de Saúde Protegidas (PHI) exigirá uma camada de gerenciamento centralizada que, até o momento, não foi implementada pela maioria das organizações.

Como as organizações da área da saúde devem investigar violações na nuvem quando os registros e as evidências estão distribuídos entre vários provedores?

A investigação de uma violação só será completa na medida em que os registros que a sustentam forem completos. Ambientes multicloud raramente armazenam registros em um único local ou em um formato consistente. Os registros devem ser transmitidos de cada ambiente de nuvem para um repositório seguro, centralizado e separado, em tempo real, em vez de serem extraídos de forma reativa após a descoberta de uma violação. A análise forense para cada provedor, incluindo como obter evidências preservadas, deve ser predefinida antes de uma violação, em vez de ser desenvolvida durante a mesma.

Por que a automação nativa da nuvem e os pipelines de DevSecOps podem expor acidentalmente dados confidenciais da área da saúde em grande escala?

Se uma configuração incorreta for incorporada a um pipeline automatizado, ela não afetará apenas um sistema. Ela se espalhará por todos os ambientes com os quais o pipeline interage. Um sistema de implantação automatizado projetado para criar um recurso de armazenamento que conceda permissões de acesso aberto como configuração padrão pode reproduzir esse erro centenas de vezes antes mesmo que um ser humano perceba sua existência. Na área da saúde, uma verificação de segurança codificada em um pipeline automatizado não é uma conveniência de engenharia; é uma obrigação em relação à privacidade do paciente.