Conceção de aplicações HMI/SCADA com foco na cibersegurança – princípios que reduzem o risco logo na fase de projeto

A segurança das aplicações HMI/SCADA define-se muito antes da fase de seleção dos mecanismos de proteção. A resistência do sistema a erros, utilizações indevidas e alterações não controladas do estado do processo depende, acima de tudo, dos pressupostos adotados no projeto: da divisão de funções, dos limites de confiança, do âmbito das funções disponíveis na interface e da forma como são organizados a assistência técnica e o acesso remoto. Quando estas questões são tratadas como secundárias, a aplicação passa a consolidar o risco em vez de o reduzir. Por isso, o projeto de HMI/SCADA com foco na cibersegurança deve ser conduzido como uma tarefa de engenharia: primeiro é preciso definir quais são as operações críticas, que consequências podem ter e quem deve realmente poder executá-las; só depois faz sentido desenvolver ecrãs, alarmes e a facilidade de utilização.

Cibersegurança começa no projeto

Nos sistemas HMI/SCADA, a cibersegurança não é um complemento acrescentado a uma visualização já pronta. Resulta de decisões tomadas antes: da arquitetura da aplicação, do modelo de permissões, da forma de comunicação com o controlo e dos pressupostos definidos para a assistência técnica. Isto é particularmente importante porque a aplicação HMI/SCADA é, ao mesmo tempo, o ponto de contacto entre a pessoa, o processo e a infraestrutura. Por isso, um erro de projeto não se limita ao risco informático. Pode também afetar a reação do operador, a segurança funcional, o risco operacional e a continuidade da produção.

Do ponto de vista do projeto, a questão fundamental não é que proteção acrescentar no fim, mas sim que decisões, tomadas logo no início, vão limitar a superfície de ataque. Em regra, os maiores problemas não resultam da ausência de um mecanismo isolado, mas do excesso de confiança incorporado na aplicação. Na prática, isso traduz-se em contas de utilizador partilhadas, acesso de assistência amplo e permanente, ausência de separação de funções entre o operador, a manutenção e o integrador, bem como numa comunicação demasiado livre entre a camada de operação e o controlo. Na fase de arranque, estas soluções parecem convenientes porque aceleram os trabalhos e facilitam o diagnóstico. Mais tarde, tornam-se uma característica permanente do ambiente e aumentam o risco de uso indevido, erro ou alteração não controlada do estado do processo.

Por isso, antes de projetar os ecrãs, vale a pena definir não apenas o que o utilizador deve ver, mas sobretudo onde se situam os limites de confiança, quais são as operações críticas e em que pontos a interface pode tornar-se uma fonte de erro ou uma forma de contornar o procedimento. Esta sequência ajuda a estruturar as decisões seguintes: se o HMI deve ser apenas uma camada de visualização ou também um local de configuração, diagnóstico e alteração de receitas; se as funções de assistência devem estar ativas permanentemente ou apenas após ativação consciente; se o operador deve ter acesso apenas à operação do processo ou também a operações que alteram parâmetros e o histórico de dados.

O custo prático destas falhas só costuma tornar-se evidente quando a aplicação já está ligada a receitas, alarmes, relatórios, arquivo e procedimentos de manutenção. Nessa altura, até uma correção aparentemente simples, como separar contas, alterar o fluxo de aprovação de uma operação crítica ou limitar o acesso remoto a um modo pontual, deixa de ser uma mera alteração nos ecrãs. Passa a exigir a reformulação da lógica, novos testes ao tratamento de alarmes, a definição de responsabilidades e, muitas vezes, também mudanças organizacionais na fábrica. Nestas situações, durante o SAT deve confirmar-se a limitação dos acessos e o funcionamento seguro das funções críticas.

Na prática, o ponto de partida mais sensato é um mapa de trabalho das funções dos utilizadores e das respetivas permissões para operações críticas, uma lista das funções que provocam alteração do estado do processo, da configuração ou das receitas, e ainda um levantamento das ligações externas que inclua assistência, relatórios, sistemas de nível superior e acesso remoto. Só com esta base é possível projetar de forma coerente a arquitetura de zonas e ligações e preparar a análise de risco posterior. Esta abordagem está alinhada tanto com a prática de engenharia como com a necessidade de organizar responsabilidades, separar funções e controlar a comunicação em ambientes industriais. Além disso, na fase de FAT vale a pena verificar funções, operações críticas e percursos de acesso.

Onde o custo e o risco realmente aumentam

O maior custo e risco numa aplicação HMI/SCADA não resultam apenas do simples facto de os sistemas estarem interligados, mas dos efeitos no processo e na organização que cada função da aplicação pode desencadear. Os pontos mais sensíveis são aqueles que permitem alterar rapidamente definições, introduzir um bypass, silenciar um alarme, mudar uma receita ou executar um comando manual sem o contexto tecnológico completo. Se o projeto permitir este tipo de operações a partir do ecrã de produção em modo rotineiro, o risco aumenta, porque uma única decisão do utilizador ou uma única sessão comprometida pode alterar diretamente o estado do processo.

Isto significa que o catálogo de operações críticas deve ser tratado como um elemento da arquitetura de segurança, e não apenas como uma questão de ergonomia da interface. O mesmo princípio aplica-se à responsabilização das ações. Logins partilhados, contas usadas por todo o turno, ausência de separação de permissões de leitura, comando, configuração e administração, bem como um registo de eventos insuficiente, fazem com que, após um incidente, seja difícil determinar com rigor se ocorreu um erro, um contorno do procedimento, um abuso de acesso de serviço ou uma ação não autorizada. O problema não se limita à investigação das causas. Sem um rasto fiável das ações do utilizador, também não é possível avaliar a eficácia dos procedimentos, gerir permissões de forma sensata nem sustentar decisões operacionais perante uma auditoria interna, requisitos do cliente ou políticas de segurança adotadas. Na prática, trata-se de responsabilização das ações e rastreabilidade, e não apenas do simples registo de eventos.

Outro erro de projeto muito dispendioso é transferir para o ambiente de produção ecrãs de serviço e diagnóstico extensos, inicialmente preparados para arranque ou apoio ao integrador. Estes ecrãs dão frequentemente acesso alargado a variáveis internas, forçagem de estados, eliminação de bloqueios e alteração de parâmetros, embora em operação normal sejam necessários, no máximo, de forma pontual. Se não forem abrangidos por restrições adicionais, tornam-se o caminho mais curto para interferir no processo fora do percurso normal do operador. Uma solução sensata passa por separar o diagnóstico necessário à manutenção das funções que permitem interferir na lógica de funcionamento, bem como decidir em separado se o diagnóstico do fabricante da máquina deve estar disponível localmente, remotamente ou apenas de forma condicionada, após ativação consciente e com registo integral da sessão.

De forma semelhante, deve ser tratada a integração com bases de dados, relatórios, suporte remoto e sistemas de escritório. Cada uma destas ligações melhora a comodidade de trabalho, mas ao mesmo tempo aumenta o número de dependências que podem tornar-se uma via de entrada, uma fonte de perturbações ou a causa da perda de clareza quanto às responsabilidades. A falha de um serviço intermédio, uma sincronização incorreta do tempo, uma troca de dados não controlada com o sistema de nível superior ou um canal de serviço deixado ativo podem afetar não só a disponibilidade dos relatórios, mas também as decisões tomadas pelo operador.

Por isso, logo na fase de projeto, vale a pena medir não apenas a disponibilidade dos ecrãs, mas também indicadores mais simples e mais úteis: o número de operações críticas possíveis a partir do HMI de produção, o número de ligações externas ativas, o número de contas privilegiadas e o âmbito dos eventos abrangidos pelo rasto de auditoria. Esta revisão ajuda depois a estruturar o registo de eventos, o controlo das alterações de parâmetros e as regras de acesso remoto. Na fase de FAT, vale a pena verificar funções, operações críticas e percursos de acesso.

O sistema de alarmes exige uma abordagem própria. Nesta área, uma aparente completude esconde muitas vezes uma falta real de controlo. Alarmes mal concebidos e um histórico de eventos inadequado não só sobrecarregam o operador, como também lhe retiram a capacidade de distinguir sinais críticos do ruído técnico. Se um alarme puder ser facilmente silenciado sem justificação, confirmado sem referência à causa ou perdido no meio de uma massa de mensagens de diagnóstico, a aplicação deixa de apoiar a segurança do processo. Por isso, as prioridades dos alarmes devem resultar do impacto real sobre as pessoas, a máquina e a qualidade da produção, mantendo-se ligadas às regras de registo de confirmações, contornos e alterações de ajustes. É precisamente neste momento que a análise de risco deixa de ser um documento formal e começa a moldar a interface.

Como projetar para limitar os efeitos do erro e do abuso

O ponto de partida é simples: a aplicação HMI/SCADA não pode partir do princípio de que todos os utilizadores atuam sempre corretamente e no contexto certo do processo. O projeto deve começar pela separação de funções, e não pelo desenho dos ecrãs. A equipa deve primeiro definir o que o operador apenas pode visualizar, o que pode confirmar, o que lhe é permitido alterar no decurso normal do trabalho e quais as ações que devem ser transferidas para o modo de serviço, sujeitas a autorização adicional ou totalmente separadas para uma ferramenta ou estação distinta. Estes requisitos devem ser considerados desde os trabalhos de projeto.

Esta decisão organiza toda a arquitetura de acesso: funções, âmbito das permissões, forma de registo das ações e condições do suporte remoto. Na prática, funciona bem uma matriz de funções baseada em responsabilidades reais, distinguindo operador, chefe de equipa, manutenção, tecnólogo, integrador e administrador. Isto não é uma formalidade. Se as funções de serviço permanecerem no mesmo ecrã e sob a mesma conta que a operação do processo, a própria aplicação cria um caminho para o erro, o contorno do procedimento ou o abuso de permissões.

Um bom HMI/SCADA limita a possibilidade de executar por engano uma operação perigosa, mas não atrasa desnecessariamente as tarefas de rotina. Isso exige um contexto de trabalho claro: o utilizador deve ver em que equipamento está a trabalhar, em que estado se encontra o processo, se está a atuar local ou remotamente e se o sistema está em modo automático, manual ou de serviço. As confirmações devem ser proporcionais ao risco, e não iguais para todas as ações. Quando o efeito do erro é reversível e limitado, normalmente basta uma única autorização. As operações críticas exigem controlo adicional: uma segunda confirmação, nova autenticação, dependência do estado do processo ou a passagem física para uma interface dedicada. Durante o SAT, é necessário confirmar as restrições de acesso e o funcionamento seguro das funções críticas.

Os bloqueios condicionais também são essenciais. Se a aplicação permitir alterar um ajuste, forçar um sinal ou entrar em modo manual independentemente do estado do equipamento, o risco deixa de ser tratado no projeto e passa para o operador. É precisamente aqui que se percebe que um bom desenho da interface não se resume à facilidade de utilização, mas à limitação das consequências do erro através de barreiras incorporadas. Em muitos casos, esta forma de pensar aproxima-se da lógica do Poka-Yoke nas linhas de produção.

O desenho do acesso por camadas deve abranger também a forma como as permissões são utilizadas ao longo do tempo. As contas individuais são indispensáveis sempre que se exige rastreabilidade das ações. Uma conta partilhada elimina a possibilidade de determinar quem tomou efetivamente a decisão. O princípio do menor privilégio significa que o utilizador recebe apenas as funções de que necessita para o trabalho corrente, e a elevação de permissões ocorre apenas de forma temporária e em condições controladas. Isto aplica-se em especial à manutenção, ao integrador e ao suporte remoto do fabricante. Um canal de serviço permanentemente aberto é apenas aparentemente conveniente, porque elimina a fronteira natural de confiança entre a operação e o serviço técnico. Um modelo mais seguro é o acesso ativado a pedido, limitado no tempo, atribuído a uma pessoa concreta e registado no histórico de eventos. Esta abordagem enquadra-se bem no princípio do menor privilégio e na segmentação de acessos.

No mesmo espírito, é necessário decidir se as funções de serviço devem estar disponíveis no HMI de operação ou apenas a partir de uma estação separada, e se devem ser permitidos suportes amovíveis e a importação ou exportação local de dados a partir do painel do operador. Estas decisões não são secundárias. Delas depende se a manutenção do sistema será realizada de forma controlada ou através de soluções improvisadas.

Na perspetiva de um incidente ou de um litígio operacional, a própria interface não basta. A aplicação tem de deixar registos que permitam reconstruir a sequência de decisões. O histórico de eventos, os registos do sistema e o registo de alterações devem, em conjunto, responder não só à pergunta sobre o que aconteceu, mas também quem executou a operação, quando, a partir de que local e em que estado do processo. O conjunto mínimo de eventos que normalmente vale a pena registar inclui o início de sessão, a alteração de permissões, a alteração de parâmetros, a entrada em modo manual, a confirmação de alarme e a importação de configuração. É fundamental associar o registo ao contexto tecnológico, porque a simples informação de que houve uma alteração, sem o estado do equipamento, pode revelar-se inútil.

Um bom exemplo, típico de muitas implementações, é o seguinte: a alteração do limiar de alarme por um tecnólogo pode ser permitida, mas apenas após entrada no modo previsto, com registo do utilizador, da estação, da hora, do valor anterior e do novo valor, bem como com confirmação de que o equipamento não se encontrava em estado crítico. Este tipo de rasto é importante tanto para a segurança como para a gestão da mudança em aplicações industriais.

A última camada é a manutenibilidade sem contornar as proteções. Se uma atualização, o restauro da configuração ou o diagnóstico exigirem a desativação do controlo de acessos, a utilização de uma palavra-passe partilhada ou trabalho sem rasto de auditoria, então o problema está no projeto e não na disciplina do pessoal. A aplicação deve prever um fluxo de alteração: pedido, avaliação de impacto, teste, implementação, confirmação e plano de reversão. Deve também separar o ambiente operacional do ambiente de serviço, pelo menos do ponto de vista lógico e, quando tal se justificar, também do ponto de vista organizacional e técnico. As cópias de configuração têm de poder ser realizadas e restauradas de forma controlada, sem exportações ocasionais “por precaução” a partir do painel. Esta abordagem é coerente com o princípio do menor privilégio em OT e com os requisitos de controlo de acessos, rastreabilidade das ações e gestão da mudança, sendo que o respetivo âmbito deve ser sempre relacionado com a arquitetura do sistema e com a repartição de responsabilidades adotada.

Prática de implementação e enquadramento nos requisitos

O que mais traz benefícios não é acrescentar novos mecanismos de proteção no fim do projeto, mas sim realizar uma revisão estruturada da aplicação antes da receção ou da modernização. É nesta fase que ainda é possível corrigir, com custos relativamente baixos, a forma de funcionamento do sistema, em vez de mais tarde tentar compensar pressupostos errados com procedimentos adicionais. Esta revisão deve ser conduzida por uma equipa mista: projeto, manutenção, operação, automação e pessoas responsáveis pela segurança.

O objeto da avaliação não é apenas a configuração técnica, mas também verificar se a aplicação realmente separa funções, protege operações críticas, limita o acesso remoto aos casos justificados, assegura um tratamento claro dos alarmes, preserva o histórico de alterações e permite executar cópias e procedimentos de emergência sem contornar as proteções. É precisamente desta revisão que deve resultar a lista para FAT/SAT, bem como os requisitos a incluir na receção, no plano de serviço e na documentação final.

Esta abordagem desloca o foco da discussão sobre as próprias proteções para as decisões de projeto que, mais tarde, determinam o comportamento das pessoas e dos equipamentos. Se, logo na fase de projeto, não ficar definido quem pode alterar os parâmetros das receitas, quem aprova o modo de serviço, como é registada a intervenção do integrador e em que condições é permitido o acesso a partir do exterior da fábrica, então, após a entrada em funcionamento, o sistema passará a assentar em exceções e em acordos verbais.

Pela mesma razão, vale a pena decidir se a avaliação da aplicação deve ser realizada no âmbito da modernização da máquina ou da linha, ou como uma revisão OT autónoma. A primeira abordagem relaciona melhor a segurança com a função do processo; a segunda facilita a identificação das dependências entre sistemas e a distribuição de responsabilidades pelas contas, permissões e registo das ações. Este é também o local natural para uma análise preliminar de risco: identificação de operações críticas, limites de confiança e consequências de erro do operador ou de utilização indevida. Na prática, uma auditoria de segurança de máquinas e linhas de produção também pode apoiar esta avaliação.

• funções e forma de autenticação dos utilizadores,
• operações críticas e regras para a sua confirmação,
• acesso remoto e funções de serviço,
• alarmes, registo de alterações e responsabilização pelas ações,
• cópias, recuperação e procedimentos de emergência.

Um bom resultado na fábrica raramente decorre da implementação simultânea de muitas ferramentas. Regra geral, é mais importante eliminar alguns riscos sistémicos que, durante anos, foram considerados práticos. A modernização da aplicação HMI/SCADA pode começar pela eliminação de contas partilhadas, pela separação das funções de serviço das funções de operação, pela limitação das ligações externas a percursos controlados e pela ativação do registo das alterações de parâmetros com atribuição a uma pessoa ou função específica. Esta mudança não tem de prejudicar o trabalho da manutenção nem do integrador, desde que, desde o início, tenham sido previstos o modo de serviço, as regras de autorização e um processo reprodutível para as modificações.

Na exploração, vale depois a pena medir não um nível abstrato de segurança, mas sim indicadores operacionalmente úteis: o número de contas partilhadas que ainda permanecem no sistema, o âmbito do acesso remoto ativo, a completude dos registos de alterações, o tempo de recuperação da configuração e o número de intervenções realizadas fora do procedimento formal. Estes indicadores permitem avaliar se o projeto reduziu efetivamente o risco ou se apenas o transferiu para a prática diária.

Na realidade polaca e europeia, é cada vez mais difícil defender uma abordagem em que a cibersegurança HMI/SCADA seja um assunto exclusivo do departamento de TI. A responsabilidade está distribuída entre projeto, exploração, manutenção, fornecedores e integradores, e os requisitos setoriais e contratuais só ganham relevância quando a organização consegue demonstrar aspetos concretos: que decisões de projeto foram tomadas, como são atribuídas as permissões, qual é o rasto das ações e quem controla as alterações. As simples referências a normas, políticas ou cláusulas contratuais não substituem a prova de que a aplicação foi concebida e aceite de forma a permitir uma exploração segura.

A conclusão mais importante é prática. O momento mais económico e mais eficaz para reduzir o risco continua a ser o projeto e a aceitação da aplicação. É nessa fase que, com o menor custo, se definem os limites de confiança, as funções, as condições de acesso, o rasto das ações e a forma de gerir as alterações. Se estes requisitos forem convertidos em critérios verificáveis para o fornecedor e o integrador, o HMI/SCADA deixa de ser uma interface cómoda, mas excessivamente permissiva, e passa a ser uma ferramenta para a exploração segura do processo.