Guia de Implementação da SES GO - Segurança - Local Development build (v0.0.2) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Política de Assinatura Digital Avançada

Esta política estabelece os requisitos, procedimentos e padrões técnicos para a criação e validação de assinaturas digitais avançadas para dados de saúde registrados como instâncias de recursos FHIR (Fast Healthcare Interoperability Resources) no âmbito da SES-GO. Seu objetivo é garantir a autenticidade, integridade, não-repúdio e validade jurídica das informações assinadas digitalmente, em conformidade com as melhores práticas e normas nacionais e internacionais, incluindo ICP-Brasil, JWS (RFC 7515) e JAdES-B (ETSI TS 119 182-1).

O que está incluído na política

Esta política se aplica a todos os processos de assinatura digital de recursos FHIR R4, abrangendo:

• Preparação do conteúdo: identificação e organização do conteúdo a ser assinado, incluindo recursos FHIR individuais ou conjuntos de recursos.
• Criação de assinaturas: processo completo de geração de assinaturas digitais conforme padrões JWS e JAdES-B.
• Validação de assinaturas: processo completo de verificação e validação de assinaturas digitais existentes.
• Auditoria: conforme caso de uso registro de auditoria a ser utilizado durante os processos de criação e validação de assinatura digital.
• Disponibilização do cache de consulta de certificados: conforme o caso de uso montagem do cache de consulta de certificados.
• Montagem da cadeia de certificados: conforme o caso de uso gerar cadeia de certificados.

O que não está incluído na política

Os seguintes aspectos não fazem parte desta política:

• Gestão de chaves e certificados:
  • Proteção e armazenamento seguro de chaves privadas
  • Renovação, rotação e revogação de certificados e chaves
  • Backup e recuperação de material criptográfico
• Infraestrutura operacional:
  • Configuração de Autoridades de Carimbo de Tempo (TSA)
  • Conectividade e credenciais de acesso a serviços externos
  • Seleção de provedores de serviços criptográficos
• Governança organizacional:
  • Evolução e manutenção desta política
  • Monitoramento de obsolescência algorítmica
  • Migração para novos algoritmos criptográficos
  • Revisões periódicas e publicação de novas versões

Identificação

C0 A identificação da política em uma versão específica é feita pela combinação do identificador da política (URI) com aquele da versão.

O formato da URI de identificação segue a estrutura:

• Base URI: https://fhir.saude.go.gov.br/r4/seguranca/ImplementationGuide/br.go.ses.seguranca
• Separador: | (pipe character)
• Versão: string no formato semântico MAJOR.MINOR.PATH (ex: 0.0.2)
• URI completa: {baseUri}|{versão}

Abaixo segue a identificação única da política na versão aqui descrita:

https://fhir.saude.go.gov.br/r4/seguranca/ImplementationGuide/br.go.ses.seguranca|0.0.2

O versionamento segue a estratégia Semantic Versioning (SemVer) no formato MAJOR.MINOR.PATCH, onde:

• MAJOR: incrementado para mudanças incompatíveis que quebram implementações existentes
• MINOR: incrementado para adições de funcionalidade mantendo compatibilidade
• PATCH: incrementado para correções de bugs mantendo compatibilidade

Conteúdo a ser assinado e restrições

C1 O conteúdo a ser assinado é composto por uma ou mais instâncias de recursos FHIR (versão 4.0.1).

Nota 1
Consulte conteúdos assinados para detalhes e exemplos. Observe que não é necessário que seja um documento FHIR, por exemplo.

C2 O conteúdo a ser assinado deve estar reunido em uma instância do recurso Bundle. Esta instância do recurso Bundle é utilizada apenas para efeito da criação e da validação da assinatura, não sendo necessária a sua persistência.

C3 Toda instância que faz parte do conteúdo a ser assinado é identificada no Bundle pelo elemento entry.fullUrl correspondente. Este identificador deve ser obrigatoriamente um valor do tipo uuid.

C4 Uma instância do recurso Provenance referencia e estabelece a ordem de todas as instâncias que fazem parte do conteúdo a ser assinado por meio do elemento Provenance.target. Cada referência em Provenance.target usa o uuid que identifica a instância em questão no Bundle, conforme o item anterior.

C5 Todo elemento do tipo de dados Reference contido em qualquer instância que faz parte do conteúdo assinado deve utilizar exatamente uma das seguintes opções mutuamente exclusivas:

• Identificador lógico (Reference.identifier) — sem utilizar Reference.reference.
• Referência UUID (Reference.reference no formato urn:uuid: seguido de UUID válido) — sem utilizar Reference.identifier.
• Referência contained (Reference.reference com fragmento #id) para recurso incorporado na mesma instância — sem utilizar Reference.identifier.
• Referência para a instância que contém o recurso referenciado (Reference.reference com valor #) — usado quando uma instância contida referencia sua instância container — sem utilizar Reference.identifier.
• A assinatura não está definida para um conteúdo assinado que inclui o tipo de dados Reference que não atende a uma destas quatro opções acima.

Nota 2
Consulte referências para detalhes acerca de questões pertinentes ao registro de relações entre instâncias.

C6 A assinatura produzida não inclui a instância do Bundle, nem a instância de Provenance, mas apenas as instâncias de recursos FHIR referenciadas pela instância de Provenance.

Nota 3
Cada valor em Provenance.target deve coincidir exatamente com o valor do campo entry.fullUrl da entrada correspondente no Bundle. Por exemplo, se existe uma entrada em Provenance.target com o valor urn:uuid:3fa85f64-5717-4562-b3fc-2c963f66afa6, então deve haver uma única entrada no Bundle cujo fullUrl seja urn:uuid:3fa85f64-5717-4562-b3fc-2c963f66afa6.

Serialização e canonicalização

C7 Cada instância FHIR a ser assinada deve estar representada em JSON, assim como a instância de Bundle que as reúne e a instância de Provenance que as identifica na instância do Bundle.

C8 Cada instância FHIR a ser assinada deve ser canonicalizada conforme a RFC 8785. Esta canonicalização garante que tanto quem assina quanto quem valida obtenham exatamente a mesma representação determinística para uma determinada instância.

Nota 4
O padrão FHIR define uma estratégia própria para JSON canônico. A presente política adota a RFC 8785, conforme identificado acima.

Padrões e outras especificações observados

C9 JWS (JSON Web Signature) — RFC 7515. Usado para definição da estrutura e do formato da assinatura digital.

C10 JAdES-B — ETSI TS 119 182-1. Padrão europeu para assinaturas digitais avançadas baseadas em JWS, define os atributos e metadados necessários para conformidade com o nível de assinatura baseline (B-level).

C11 Guia Da Vinci CDex. Guia de implementação para troca de dados clínicos que estabelece padrões para solicitação e transmissão segura de informações de saúde, incluindo requisitos para assinatura digital de documentos em contextos de interoperabilidade.

C12 Regras do FHIR para assinatura de instâncias serializadas em JSON (FHIR JSON Signature), especificamente o algoritmo de hash e a especificação do propósito da assinatura.

Registro da assinatura

C13 A assinatura é registrada em uma instância do recurso Provenance conforme o perfil Conteúdo Assinado. O elemento Provenance.signature utiliza o tipo de dados Signature em conformidade com o perfil Assinatura Digital Avançada.

C14 O JWS deve ser representado na serialização JSON, permitindo a inclusão de carimbo de tempo fornecido por Autoridade de Carimbo de Tempo (TSA), quando for o caso.

C15 O JWS produzido inclui um payload definido pela impressão digital (hash) das instâncias assinadas. A assinatura não é do tipo detached conforme a definição da RFC 7515, pois o JWS contém payload, mesmo que este seja apenas a impressão digital e não o conteúdo original das instâncias FHIR.

Certificados e cadeia de confiança

C16 A assinatura digital deve ser baseada exclusivamente em chaves privadas associadas a certificados ICP-Brasil.

C17 O JWS deve contemplar a cadeia completa de certificados, iniciando no certificado do signatário e terminando em uma Autoridade Certificadora (AC) raiz da ICP-Brasil, incluindo as autoridades certificadoras intermediárias, sem lacunas.

C18 Para certificados baseados em RSA, o tamanho mínimo da chave deve ser de 2048 bits, conforme normas da ICP-Brasil.

C19 Para certificados baseados em ECDSA, deve ser utilizada a curva P-256 (secp256r1) com algoritmo sha256WithECDSAEncryption.

Nota 5
Os algoritmos, curvas e tamanhos de chave aceitos para certificados digitais devem sempre estar em conformidade com as normas técnicas vigentes da ICP-Brasil.

C20 Os períodos de validade de todos os certificados da cadeia devem ser verificados, garantindo que o instante atribuído à criação da assinatura esteja compreendido no período de validade de cada certificado.

C21 Todas as assinaturas digitais dos certificados da cadeia devem ser verificadas, inclusive a do certificado raiz autoassinado.

C22 Para cada certificado da cadeia (exceto o da AC raiz), deve ser verificado o status de revogação por meio de CRL (Certificate Revocation List) ou OCSP (Online Certificate Status Protocol) para o instante declarado da criação da assinatura. Quando não for possível obter o status de revogação devido à indisponibilidade dos serviços, conectividade limitada ou outras falhas técnicas, a validação da cadeia é interrompida. Esta interrupção impede a validação da assinatura nesse instente, pois não há resposta definitiva, contudo, permite que seja reiniciada posteriormente, conforrme registro detalhado da situação excepcional nos logs de auditoria.

C23 As evidências da checagem de revogação (CRL/OCSP) devem ser armazenadas para fins de validação futura (Long Term Validation — LTV).

Escopo da validação (limitação)

C24 A validação definida neste guia não inclui a verificação da autoridade do signatário para assinar o conteúdo em questão, nem outras validações contextuais. Tais verificações adicionais devem ser realizadas, se necessário, por outros componentes tecnológicos.

Requisitos de auditoria e rastreabilidade

Tanto o caso de uso criar quanto o caso de uso validar devem registrar informações pertinentes à auditoria, conforme os requisitos definidos nesta seção.

C25 O registro é feito por meio de instâncias do recurso AuditEvent.

C26 O banco de dados empregado deve ser append only.

C27 Os seguintes eventos devem ser obrigatoriamente registrados:

• Início do processo: registro do início da operação de assinatura com identificação do usuário, timestamp e política utilizada
• Validação de certificados: resultado da validação da cadeia (sucesso/falha), incluindo dados dos certificados validados
• Operações criptográficas: execução das operações de hash, assinatura digital e verificações, com indicação de sucesso/falha
• Acesso a chaves privadas: tentativas de acesso a dispositivos seguros (smartcard/token), incluindo autenticação PIN
• Finalização: conclusão do processo com indicação de sucesso ou detalhes da falha

C28 Os logs de auditoria devem ser protegidos conforme os seguintes requisitos:

• Integridade: logs devem ser protegidos contra alteração através de mecanismos como assinatura digital ou armazenamento append-only
• Confidencialidade: informações sensíveis (como PINs) não devem ser registradas nos logs
• Disponibilidade: logs devem ser armazenados com redundância adequada e backup regular
• Retenção: período mínimo de retenção conforme requisitos regulatórios aplicáveis (expurgo apenas após 5 anos)

C29 As instâncias de AuditEvent devem seguir os seguintes padrões:

• Use AuditEvent.type com código apropriado do ValueSet audit-event-type
• Inclua detalhes da operação em AuditEvent.entity referenciando os recursos assinados
• Para correlação de eventos da mesma operação de assinatura, inclua um identificador único (UUID) de sessão em AuditEvent.entity.what.identifier.value com tipo "session"
• Para falhas, incorpore a instância de OperationOutcome em AuditEvent.entity conforme orientação do padrão FHIR
• Registre informações do signatário em AuditEvent.agent com identificação por certificado digital

C30 A tabela a seguir especifica os elementos obrigatórios e seus valores esperados:

Elemento	Descrição e Valores Esperados
type	Atividade de auditoria: definida pelo código verify do CodeSystem http://terminology.hl7.org/CodeSystem/iso-21089-lifecycle.
action	Trata-se da execução de operação de validação, ou seja, código E.
recorded	O momento em que a validação foi realizada.
outcome	Resultado da operação de validação da assinatura. Os valores podem ser 0 (sucesso) ou 8 (falha séria). Caso a validação não seja concluída de forma satisfatória, o valor 0 não é permitido para outcome.
outcomeDesc	O valor SUCESSO para indicar assinatura verificada satisfatoriamente ou FALHA, caso contrário.
purposeOfEvent	Atender exigência legal (HLEGAL).
agent	Identificador do remetente, ou seja, o estabelecimento de saúde que envia a informação assinada.
source	O estabelecimento de saúde que é o remetente da informação cuja assinatura é validada (source.observer).
entity	Tipo de documento (entity.type) da instância validada e armazenada localmente. O identificador único (identificador lógico) estabelecido pelo estabelecimento que envia a informação para identificar qual a entidade cuja assinatura é validada (entity.what). Para correlação de eventos da mesma operação, inclua uma entidade adicional com tipo "session" e identificador único da sessão de assinatura.
identifier	Identificador lógico (id) atribuído pela SES-GO. A partir deste valor e do tipo do documento pode-se localizar o que foi submetido e, naturalmente, a assinatura correspondente, onde outras informações podem ser obtidas como o valor x5t, dentre outras. O identificador lógico não será fornecido se a validação do conteúdo da instância falhar.
location	Não aplicável para este contexto.
reason	O propósito do evento é atender aspectos legais, ou seja, código HLEGAL do CodeSystem http://terminology.hl7.org/ValueSet/v3-PurposeOfUse.

Conformidade com a política de assinatura

Exige aderência ao conteúdo da política (texto desta página) acrescido dos casos de uso abaixo:

• Consulte o caso de uso que detalha o processo de geração de uma assinatura digital.

• Consulte o caso de uso que detalha o processo de validação de uma assinatura digital.

• Consulte o caso de uso que detalha o processo de registro de auditoria para operações de assinatura digital.

Estes casos de uso podem resultar em situações excepcionais identificadas por meio de códigos específicos padronizados.