1) Visão geral
Sobre a norma FDA CFR 21 Part 11
Em 1991, membros da indústria farmacêutica americana realizaram um encontro com a FDA (Food and Drug Administration) para determinar como eles poderiam acomodar sistemas de registro eletrônico de documentos (sem o uso de papel) de acordo com as normas 210 e 211 da "Current Good Manufacturing Practice" (prática atual para a manufatura de bens). A FDA criou uma Força Tarefa para Assinatura/Identificação Eletrônica para desenvolver um conjunto de diretrizes uniforme para a agência aceitar registros e assinaturas eletrônicas em todas as áreas deste programa. O resultado final providenciaria um critério segundo qual a FDA iria considerar registros eletrônicos equivalentes a registros em papel, e assinaturas eletrônicas equivalentes às assinaturas manuscritas tradicionais.
A norma CFR 21 Part 11 aplica-se a qualquer registro em papel, exigido pelo estatuto ou pelo regulamento da agência, e substitui qualquer regra atual para estes, pois admite o uso de registros eletrônicos em lugar dos registros em papel. Assinaturas eletrônicas que atenderem à norma serão consideradas equivalentes a assinaturas manuscritas, rubricas ou quaisquer outras autenticações requeridos pelo regulamento da agência.
Resumo das exigências da norma FDA CFR 21 Part 11
As exigências mostram a necessidade de um sistema de controle seguro que inclua login de usuário, logout automático por inatividade e outros procedimentos para garantir que os usuários que estão operando o sistema são autorizados e não impostores. Um sistema fechado ou que permita apenas sua execução (e não edição) é um meio de proteger o sistema de controle pois permite somente usuários autorizados acessar e fazer mudanças no sistema.
Outra parte da norma envolve o rastreamento de registro de dados e mudanças no sistema. Quando um usuário realiza mudanças que exigem uma autenticação, os registros podem ser armazenados eletronicamente se o usuário entrar sua senha ou usar um equipamento biométrico adequado. O dado a ser registrado e armazenado deve uma data e hora de registro válida e ser seguro, o que envolve uma auditoria completa de quaisquer mudanças e um procedimento de backup e sua eventual restauração.
Objetivo deste documento
Este documento é um guia de como configurar o E3 para atender cada uma das exigências da norma CFR 21 Part 11. Note que o E3 pode ser implementado para prover os métodos necessários para atender a norma, mas não é o E3 em si que é validado, mas sim, o processo implementado com um todo. Assim, todas as partes do sistema devem atender as regras da FDA, o que inclui tanto documentação e como treinamento.
As diretrizes em como implementar o E3 para estar de acordo com a CFR 21 Part 11 são apresentadas a seguir. São instruções passo-a-passo para cada parte relevante das seções B e C da norma, seguidas de uma observação da Elipse (como nos exemplos abaixo) e, quando aplicável, uma sugestão de implementação.
Texto da norma CFR 21
Um texto nesta fonte representa um trecho relevante da norma CFR 21 Part 11, em tradução livre (não oficial).
Comentários
Textos sinalizados como a seguir representam observações da Elipse a respeito de um determinado assunto:
(Comandos) Este indicativo se refere a seções que tratam do envio de comandos operacionais.
(Registro de dados) Este indicativo se refere a seções que tratam do controle de dados que devem ser registrados.
(E3) Este indicativo se refere a seções que tratam do emprego do E3 como Server e/ou Viewer.
(ElipseX) Este indicativo se refere a áreas onde bibliotecas ElipseX do E3 podem ajudar no desenvolvimento da solução.
(FDA) A FDA tem exigências que dizem respeito a procedimentos que devem ser implementados para se obter a certificação "CFR 21 Part 11". Tais exigências não envolvem diretamente a implementação do E3.
(Segurança) Este indicativo se refere a seções sobre segurança do sistema, tanto no E3 como no Windows.
2) Apresentando a norma CFR 21 Part 11
Subparte B – Registros Eletrônicos
§ 11.10 Controle para sistemas fechados.
Pessoas que usam sistemas fechados para criar, modificar, manter ou transmitir registros eletrônicos devem empregar procedimentos e controles projetados para garantir a autenticidade, integridade e, quando apropriado, a confidencialidade de registros eletrônicos, e para assegurar que o assinante não pode prontamente rejeitar o registro assinado como não genuíno. Estes procedimentos e controles devem incluir o seguinte:
PS: Um sistema fechado é um ambiente em que o acesso ao sistema é controlado por pessoas que são responsáveis pelo conteúdo dos registros eletrônicos que estão no sistema.
(E3) Para a implementação de um sistema fechado, é recomendado utilizar uma licença E3Server somente (sem E3Studio) e utilizar a segurança do Windows NT/XP/2000/2003 para controlar o acesso aos arquivos da aplicação. É responsabilidade do cliente assegurar que existem procedimentos para controlar o acesso ao sistema e seus arquivos.
Apesar de uma pessoa só poder editar um arquivo do E3 (PRJ, LIB etc.) com uma autorização específica dentro da ferramenta de desenvolvimento E3Studio, estes arquivos não são protegidos por default. Assim, sempre que possível, deve-se aplicar a proteção contra edição dentro dos arquivos PRJ e LIB. (Veja a próxima seção para um exemplo de proteção dentro do E3Studio.)
(a) Validação de sistemas para assegurar a precisão, confiabilidade, consistência da performance pretendida e a habilidade para discernir registros inválidos ou alterados.
(FDA) É responsabilidade do cliente assegurar que o sistema irá passar pelo procedimento de validação específico da FDA.
(b) Habilidade para gerar cópias precisas e completas dos registros, legíveis por humanos ou em formato eletrônico adequado para inspeção, revisão e cópia pela agência. As pessoas deverão contatar a agência se houver alguma questão referente à habilidade da agência de executar esta revisão e cópia do registro eletrônico.
(Registro de dados) Os registros eletrônicos deverão ser gravados em uma base de dados relacional segura. O desenvolvedor nunca deve incluir rotinas ou declarações SQL na aplicação que podem apagar ou destruir registros, mas sim adicionar novos registros se uma mudança autorizada foi requerida. Todos os registros gravados devem incluir a identificação de segurança do usuário e serem seguros. Para isto, o desenvolvedor precisar incluir o campo ActorID na definição do banco de dados do E3 AlarmServer. Para outras informações de auditoria, o E3 faz o log de todas as operações automaticamente.
A fim de executar este processo, sugerimos escolher um dos SGBD suportados pelo E3 até o presente momento (MSDE, MS SQL Server ou Oracle) e usar os comandos do SGBD para dar permissão de acesso ao banco de dados e tabelas da aplicação somente para um usuário específico (um login/senha específico) que deverá ser informado nas propriedades do objeto Database Server do E3 (que é salvo dentro do arquivo PRJ do E3).
Não é recomendado o uso do formato MDB do MS Access, mas dependendo das circunstâncias, ele pode ser usado para testes, aplicando as diretivas de segurança para usuários e do próprio Access, dentro do Windows.
Relatórios legíveis por humanos deverão ser configurados para mostrar os dados registrados no banco de dados relacional seguro, e estar disponíveis para serem copiados pela FDA. Para criar relatórios e exportar os dados em formatos como HTML, PDF ou XLS, pode-se utilizar a ferramenta E3 Reports.
(c) Proteção de registros para habilitar sua precisão e pronta restauração durante o período de retenção dos registros.
(FDA) (E3) Os dados registrados no SGBD devem ser preservados durante um período de retenção apropriado e protegidos. Isto é definido no E3 dentro das configurações do AlarmServer, Histórico e Domínio. Como alternativa, procedimentos de backup de segurança adequados deverão ser utilizados.
(d) Acesso ao sistema limitado para indivíduos não-autorizados.
(Segurança) Diretivas de segurança do E3 devem ser utilizadas para limitar os usuários às áreas que eles possuem o nível de acesso apropriado. O E3 deve ser configurado para fazer o logout de um usuário depois de um tempo determinado de inatividade. Tentativas de login sem sucesso devem ser monitoradas.
(e) Uso de rastreamento e auditoria gerada por computador que seja segura e tenha registro de data/hora, para registrar de maneira independente os horários de entrada do operador e ações de criação, modificação ou remoção de registros eletrônicos. Mudanças em registros não deverão ocultar informações registradas anteriormente. Esta documentação de auditoria deverá ser guardada por um período pelo menos igual quanto o exigido para os registros eletrônicos do assunto e deverá estar disponível para a revisão e cópia da agência.
(Registro de dados) Todas as operações padrão de registro de dados do E3 sempre incluem estampa de tempo e nunca modificam ou apagam registros, a menos que seja inserido via programação pelo pessoal de desenvolvimento. Mesmo assim, se tal operação for exigida, uma seqüência de operações específica pode ser gerada para chamar uma assinatura eletrônica, armazenar a operação nos registros de auditoria, informar essencialmente quem fez o quê, o que escreveu e quando.
No caso de uso de múltiplas estações, um procedimento de "time broadcast" deverá ser usado para manter o sincronismo dos relógios de todas as estações.
(f) Uso de verificações do sistema operacional para reforçar o seqüenciamento permitido de passos e eventos, quando apropriado. A agência alerta que o propósito de executar verificações operacionais é assegurar que as operações (como passos para a produção de manufatura e sinais para indicar o início ou final destes passos) não são executados fora da ordem previamente estabelecida pela organização da operação.
(ElipseX) O E3 deverá ser configurado para assegurar que os usuários seguirão a seqüência de passos permitida quando estiverem operando o sistema. O uso de objetos ElipseX é recomendado para garantir que os usuários executarão os mesmos passos durante um processo sobre o sistema como um todo.
(g) Uso de verificações de autoria para garantir que apenas indivíduos autorizados poderão usar o sistema, assinar eletronicamente um registro, operar ou acessar equipamentos de entrada e saída do computador, alterar um registro ou executar a operação disponível mais próxima.
(Segurança) A segurança do E3 poderá ser usada para limitar os usuários a áreas que eles tem o nível de autorização adequado, incluindo operação e registro de dados. Instruções extras de segurança incluem:
(h) Uso de verificações dos equipamentos (ex., terminais) para determinar, quando apropriado, a validade da origem de uma entrada de dados ou instrução operacional.
(Comandos) Comandos operacionais deverão estar de acordo com o local do terminal E3 Viewer e a área do usuário, para verificar a sua validade.
(ElipseX) O uso de objetos ElipseX pode ser útil para adicionar aspectos extras de segurança a estas operações.
(i) Garantia que as pessoas que desenvolvem, mantém ou usam sistemas de assinatura eletrônica e registros eletrônicos têm a educação, treinamento e experiência para executar as tarefas a eles atribuídas.
(FDA) É responsabilidade do cliente fazer com que os usuários recebam o treinamento apropriado para garantir a operação correta do sistema.
(j) O estabelecimento e a adesão a políticas escritas que considerem que os indivíduos tenham obrigação sobre e sejam responsáveis por iniciadas sob suas assinaturas eletrônicas, a fim de desencorajar falsificações de registros e assinaturas. (FDA) É responsabilidade do cliente garantir que existem políticas adequadas a fim de permitir o uso de assinaturas eletrônicas pela FDA.
(k) Uso de controle apropriado sobre a documentação dos sistemas incluindo:
(1) Controles adequados sobre a distribuição, acesso e uso da documentação para operação e manutenção do sistema.
(2) Procedimentos de revisão e de controle de mudanças para manter uma auditoria que documente o desenvolvimento seqüencial e modificações na documentação dos sistemas.
(FDA) Os manuais do produto estão disponíveis no formato PDF no CD do E3. Toda a documentação deve ser controlada no que diz respeito à distribuição, acesso e utilização. Deverão existir procedimentos de controle de mudanças para documentação do sistema.
§ 11.30 Controle para sistemas abertos.
Pessoas que usam sistemas abertos para criar, modificar, manter ou transmitir registros eletrônicos, deverão empregar procedimentos e controles projetados para garantir a autenticidade, integridade e quando apropriado, a confidencialidade de registros eletrônicos, desde sua criação até seu recebimento.
Estes procedimentos e controles deverão incluir aqueles identificados em § 11.10, quando apropriado, e medidas adicionais como encriptação de documentos e o uso de padrões de assinatura digital apropriados para garantir, quando necessário sob as circunstâncias, a autenticidade integridade e confidencialidade dos registros.
(FDA) É responsabilidade do cliente implementar procedimentos e controles para garantir a segurança das aplicações e no manuseio de dados, em sistemas abertos.
§ 11.50 Demonstração de assinatura.
(a) Registros eletrônicos devem conter informações associadas à assinatura que indicam claramente tudo que segue:
(1) O nome impresso do assinante;
(2) A data e a hora quando a assinatura foi feita; e
(3) O significado (como visto, aprovação, responsabilidade ou autoria) associado à assinatura.
(b) Os itens idenficados nos parágrafos (a)(1), (a)(2) e (a)(3) desta seção devem ser objeto dos mesmos controles para registros eletrônicos e devem ser incluídos como parte de alguma forma de registro eletrônico inteligível a humanos (como um visor eletrônico ou uma impressão).
(Registro de dados) Para todo o dado eletrônico auditado, registrado ou qualquer outro, é exigido que contenha o nome real do usuário, data e hora, e o motivo da operação. Todos estes campos já são parte do banco de dados de auditoria e dos procedimentos de assinatura eletrônica do E3, mas eles deve ser incluídos explicitamente na lista de campos para o Servidor de Alarmes ou qualquer outro arquivo de Histórico.
Deve-se configurar relatórios legíveis por humanos para mostrar os dados registrados no banco de dados de segurança. Eles estão disponíveis para serem copiados pela FDA.
§ 11.70 Ligação assinatura/registro.
Assinaturas eletrônicas e assinaturas manuscritas feitas em registros eletrônicos deverão estar ligadas a seus respectivos registros eletrônicos para garantir que as assinaturas não poderão ser cortadas, copiadas ou transferidas de qualquer outro meio para falsificar um registro eletrônico por meios ordinários.
(Registro de dados) Todo o dado eletrônico auditado, registrado ou qualquer outro deve contar o nome do usuário (se o nome de usuário for único entre todos os usuários) ou o identificador de segurança que é ligado à operação executada.
A segurança do E3 deve ser usada para limitar os usuários às áreas que eles têm o nível de autorização apropriado para acessar, incluindo operação e registro de dados.
A agência admite que a palavra "ligação" pode oferecer às pessoas uma flexibilidade maior em implementar a intenção desta provisão e em associar os nomes dos indivíduos com seus códigos/senhas de identificação sem realmente gravar as próprias senhas em registros eletrônicos.
Subparte C – Assinaturas Eletrônicas
§ 11.100 Requisitos gerais.
(a) Cada assinatura eletrônica deve ser única para um indivíduo e não deve ser reutilizada por ou reatribuída para qualquer outro.
(Security) Esta é uma característica padrão do E3, não permitir que a mesma assinatura seja usada para mais de uma pessoa.
(b) Antes de uma organização estabelecer, atribuir, certificar ou fazer qualquer ratificação a uma assinatura eletrônica de um indivíduo, ou para qualquer elemento desta assinatura eletrônica, a organização deve verificar a indentidade do indivíduo. (FDA) É responsabilidade do cliente garantir que existem procedimentos para verificar a identidade de indivíduos dentro do sistema.
(c) Pessoas que usam assinaturas eletrônicas devem, antes ou na hora do seu uso, cerficar à agência que as assinaturas eletrônicas em seu sistema, usadas em ou depois de 20 de agosto de 1997, são destinadas a ser o equivalente legal das assinaturas manuscritas tradicionais.
(1) A certificação deve ser enviada em formulário de papel e assinada por uma assinatura manuscrita tradicional para o Escritório de Operações Regionais (HFC-100), 5600 Fishers Lane, Rockville, MD 20857.
(2) Pessoas que usam assinaturas eletrônicas devem, sob requisição da agência, prover certificação adicional ou testemunho que uma assinatura eletrônica específica é o equivalente legal de uma assinatura manuscrita do assinante.
(FDA) É responsabilidade do cliente garantir que os sistemas suportam o procedimento de validação da FDA apropriado.
§ 11.200 Componentes e controle de assinatura eletrônica.
(a) Assinaturas eletrônicas que não são baseadas em biometria devem:
(1) Empregar pelo menos dois componentes de identificação distintos, como um código de identificação e senha.
(i) Quando um indivíduo executa uma série de assinaturas durante um único período contínuo de acesso controlado ao sistema, a primeira assinatura deve ser executada usando todos os componentes eletrônicos; assinaturas subseqüentes devem ser executadas usando pelo menos um componente de assinatura eletrônica que só pode ser executado e que foi projetado para ser usado somente pelo indivíduo.
(ii) Quando um indivíduo faz uma ou mais assinaturas não executadas durante um único período contínuo de acesso controlado ao sistemas, cada assinatura deve ser executada usando todos os componentes de assinatura eletrônica.
(Security) A segurança do E3 deverá ser usada para prover um nome de usuário e uma senha para cada usuário. Para um usuário fazer um login no sistema, será exigido que ele use tanto seu nome de usuário como sua senha para obter acesso. Entrada de dados do sistema subseqüentes deverão requisitar apenas a senha entrada pelo usuário (este é o componente de assinatura que é conhecido pelo usuário e só pode ser usado por ele).
O E3 deverá ser configurado para fazer um logout do usuário após um tempo de inatividade e procedimentos deverão ser usados para garantir que os usuários não deixarão o seu terminal abandonado durante sua sessão.
(2) Ser usadas apenas pelos seus proprietários genuínos; e
(3) Ser administradas e executadas para garantir que a tentativa de uso de uma assinatura eletrônica de um indivíduo por qualquer outra pessoa que não seu proprietário genuíno vai exigir colaboração de dois ou mais indivíduos.
(b) Assinaturas eletrônicas baseadas em biometria deverão ser projetadas para garantir que elas não poderão ser usadas por qualquer um além de seus proprietários genuínos.
(FDA) É responsabilidade do cliente garantir que assinaturas eletrônicas são usadas apenas pelo proprietário da tal assinatura (login), isto é, o E3 não pode garantir que a pessoa que está digitando um nome de usuário e uma senha é exatamente a mesma pessoa.
A agência adverte que a intenção de provisão de colaboração é exigir que os componentes de uma assinatura eletrônica não-biométrica não possam ser usados por um indivíduo sem o prévio conhecimento de um segundo indivíduo. Um tipo de situação que a agência procura prevenir é o uso de um componente como um cartão ou crachá que uma pessoa pode ter deixado abandonado. Se um indivíduo tem que colaborar com outro indivíduo revelando uma senha, os riscos de denúncia e descoberta são aumentados consideravelmente e isso ajuda a desencorajar estas ações.
(FDA) Procedimentos são requeridos para garantir que a tentativa de uso de uma assinatura eletrônica de alguém exija a colaboração de duas ou mais pessoas. Se for usada biometria para assinaturas eletrônicas, então estes procedimentos deverão garantir que elas só serão usadas pelo proprietário de tais assinaturas.
§ 11.300 Controles para códigos de identificação e senhas.
Pessoas que usem assinaturas eletrônicas baseadas no uso de códigos de identificação combinados com senhas, deverão empregar controles para garantir sua segurança e integridade. Estes controles deverão incluir:
(a) A manutenção da unicidade de cada combinação de código de identificação e senha, de modo que dois indivíduos não tenham a mesma combinação de código de identificação e senha.
(Segurança) Esta é uma característica padrão no E3.
(b) A garantia de que a emissão deste código de identificação e senha seja periodicamente verificada, revalidada e revisada (por exemplo, para verificar o tempo de validade de uma senha).
(Segurança) Deve-se definir tempos de expiração de senhas no E3 para isto.
(c) A realização de procedimentos de gerência de perda para crachás, cartões ou outros dispositivos desautorizados eletronicamente, roubados, perdidos ou potencialmente comprometidos por qualquer outra circunstância que lembrem ou gerem informações de códigos de segurança ou senhas, e providenciar substitutos temporários ou permanentes usando controles rigorosos apropriados.
(FDA) É responsabilidade do cliente garantir a segurança do controle e manuseio de nomes de usuário e senhas.
(d) O uso de salvaguardas de transações para prevenir o uso não-autorizado de senhas e/ou de códigos de segurança, e detectar e reportar de maneira imediata e urgente quaisquer tentativas deste uso não-autorizado à unidade de segurança do sistema e, quando apropriado, à gerência organizacional.
(Segurança) Tentativas de login sem sucesso deverão ser monitoradas e procedimentos adequados deverão existir para alertar a gerência deste fato.
(e) Testes iniciais e periódicos de equipamentos, como crachás e cartões, que lembrem ou gerem informações de códigos de segurança e senhas, para garantir que eles funcionam corretamente e não foram alterados de maneira não-autorizada.
(FDA) É responsabilidade do cliente implementar procedimentos para garantir que os dispositivos estejam funcionando corretamente e que eles não foram alterados.
3) Detalhes de Implementação no E3
Protegendo Arquivos de Projetos e Bibliotecas
Esta operação é utilizada para proteger arquivos de aplicação (PRJ e LIB) contra acessos não autorizados. As restrições podem ser aplicadas à configuração (Proteção de Edição) ou para sua execução (Proteção de Execução).
Figura 1 – Configurando a proteção contra execução e edição
Definindo o uso de bancos de dados e segurança
O E3 utiliza uma ou mais bases de dados para guardar toda a informação e registro de dados. Para isto, deve-se configurar no domínio, pelo menos um objeto DBServer (servidor de banco de dados) que será ligado a algum SGBD compatível, como Oracle ou SQL Server, com um usuário e senha específico. Nestas bases de dados, o E3 irá armazenar diversas tabelas, incluindo: tabelas de alarmes, históricos, E3Storage, fórmulas, tabelas de usuário, auditoria e tabelas de backup.
Figura 2 – Configuração para o servidor de banco de dados
Ajustando tamanho de tabelas e políticas de backup
Na configuração de históricos, alarmes, armazenamento ou auditoria, deve-se definir o tamanho das tabelas e a política de backup de segurança como se vê abaixo.
Figura 3 – Configurando propriedades do AlarmServer
Definindo opções de segurança para domínios
Através da opção Domínio – Segurança, pode-se definir todas as políticas de segurança padrão para todos os usuários, como bloqueio de contas, tamanho mínimo e tipos de caracteres para as senhas entre outros.
Figura 4 – Definindo opções de segurança para um domínio
Criando usuários e grupos
Através da opção Domínio – Usuários, é possível definir usuários e grupos para o sistema. Para cada usuário ou grupo, pode-se definir ou aplicar políticas de segurança, como configurações de contas, tempo de validade de senhas e outros.
Figura 5 – Adicionando um novo usuário
Figura 6 – Adicionando políticas de segurança para grupos
Figura 7 – Configurando permissões de usuário para domínios
Figura 8 - Configurando permissões de usuário para alarmes
Figura 9 – Configurando permissões de usuário para telas
Definindo configurações de auditoria e mensagens de logs
É possível especificar e configurar o registro de eventos do sistema na Configuração do Domínio, opção Registro de Eventos.
Figura 10 – Habilitando o registro de eventos do sistema
Também é possível personalizar as mensagens de log, no editor de eventos.
Picture 11 – Customizing event messages
Assinaturas Eletrônicas
O diálogo a seguir aparece sempre que a função ESign é chamada, permitindo a autenticação de operações específicas.
Figura 12 – Diálogo da assinatura eletrônica
Exemplos de ElipseX usando os métodos ESign e TrackEvent
Exemplo genérico
| If Application.IsUserMemberOfGroup("OPERATORS") Then If Application.ESign(Param1, Param2, Param3) = True Then Do_Something Application.TrackEvent "Tag IO.Inputs.I001 changed to 1" End If End If |
| Sub Button1_Click() Dim Tag, User, Comment Set Tag = Application.GetObject("IO.Inputs.I001") If Application.ESign(Tag.PathName,, "Value Change", Tag.Value, 1, User, Comment) Then If Tag.WriteEx 1 Then Application.TrackEvent "Tag IO.Inputs.I001 changed to 1" End If End If End Sub |
| Sub Setpoint1_Validate(BOOL Cancel) Dim User, Comment Cancel = Application.ESign (Name, , "Value Change", Tag.Value,_ 1, User, Comment) If Cancel Then Application.TrackEvent "Tag X changed to " & Value End If End Sub |
| Sub Viewer_OnInactive() Logout(0) MsgBox "You were logged of due to inactivity timeout." End Sub |