O documento descreve os principais termos e conceitos de segurança da arquitetura OPC UA, incluindo autenticação, autorização, confidencialidade, integridade e ameaças à segurança. Ele também discute a estrutura de segurança da OPC UA e como ela implementa esses conceitos por meio de serviços, políticas e auditoria.

1. Modelo de segurança OPC
UA
Dalton Cézane
Instituto Federal de Pernambuco
(IFPE)

2. Escopo
• Descrição do modelo de segurança da
Arquitetura Unificada OPC UA;
• Descrição das ameaças de segurança;
• Visão das características de segurança;
• Como UA utiliza outros padrões para
segurança.

3. Alguns termos
• Certificado;
• Comando;
• Evento;
• Mensagem;
• Notificação;
• Subscrição.

4. Termos de segurança OPC
UA
• Autenticação: verificação da identidade
de uma entidade como cliente, servidor
ou usuário;
• Autorização: direito ou permissão
garantida a uma entidade para acessar
um recurso de sistema ;
• Confidencialidade: proteção de dados
(em transmissão ou armazenados em
algum local) contra ataques passivos;

5. Termos de segurança OPC
UA
• Integridade: busca assegurar que a
mensagem é recebida como enviada, ou seja,
não foi modificada durante a transmissão;
• Auditoria: examina a segurança do sistema
em operação e registra os eventos em logs;
• Não-repúdio: previne qualquer remetente e
destinatário da negação da mensagem
transmitida;
• Disponibilidade: significa o tempo de
execução do sistema sem qualquer
impedimento (sem interrupção na execução);

6. Termos de segurança OPC
UA
• Aplicação OPC UA: instância de um cliente ou
servidor OPC UA rodando em um computador
individual;
• Certificado de instância de aplicação:
certificado digital de uma instância individual
de uma aplicação que está instalada em um
host individual;
• Certificado X.509: certificado em um dos
formatos definidos pelo X.509 v1, 2 ou 3
(seqüência de dados e uma assinatura digital
computada nesta seqüência);

7. Termos de segurança OPC
UA
• Certificado digital: estrutura que associa
uma identidade a uma entidade, tal como
um usuário ou uma instância de
aplicação;
• Conjunto de chave de sessão: chave
simétrica usada para encriptar ou
assinar mensagens em uma sessão ou
dois pares de chaves assimétricas que
são usadas para este fim;

8. Termos de segurança OPC
UA
• Símbolo (token) de segurança: identificador
para um conjunto de chaves de sessão usado
para encriptar e assinar mensagens trocadas
entre cliente e servidor;
• Canal de segurança: caminho de
comunicação estabelecido entre um cliente
OPC UA e um servidor, autenticados um pelo
outro usando certos serviços OPC UA, e pelo
qual parâmetros de segurança são
negociados e aplicados;

9. Termos de segurança OPC UA
• Nonce: número pseudo-randômico que
é usado apenas uma vez (usados em
algoritmos que geram chaves de
segurança ou em testes de
desafio/resposta);
• Criptografia assimétrica: utiliza duas
chaves no processo de
encriptação/decriptação dos dados
(chave pública e chave privada);

10. Termos de segurança OPC UA
• Criptografia simétrica: utiliza apenas
uma chave no processo de
encriptação/decriptação dos dados
(esta chave deve ser mantida segura);
• Função Hash: calcula um valor tal que é
impraticável descobrir seu valor original
(antes de passar pela função);

11. Termos de segurança OPC UA
• Infra-estrutura de chave pública: sistema de CAs que
desempenha um conjunto de gerenciamento de
certificado, gerenciamento de arquivos, gerenciamento
de chaves, e funções de gerenciamento de símbolos
para uma comunidade de usuários em uma aplicação
de criptografia assimétrica;
• Chave pública: componente de divulgação pública de
um par de chaves criptográficas usado para
criptografia assimétrica;
• Chave privada: componente secreto de um par de
chaves criptográficas usado por criptografia
assimétrica.

12. Ameaças de segurança
• Flooding de mensagem: tem o objetivo de
derrubar o servidor ou seus componentes,
através de um grande volume de mensagens.
Ameaça disponibilidade;
• Eavesdropping: um intruso pode gravar e
capturar mensagens, caso tenha
comprometido um sistema subjacente.
Ameaça, principalmente, confidencialidade.

13. Ameaças de segurança
• Mensagem mascarada: um intruso pode
forjar mensagens de um cliente ou de
um servidor. Ameaça integridade,
autorização e não-repúdio;
• Alteração de mensagem: mensagens
podem ser capturadas, alteradas e
reenviadas. Ameaça integridade,
autorização e não-repúdio;

14. Ameaças de segurança
• Replay de mensagens: mensagens
podem ser capturadas e enviadas a
clientes e servidores OPC. Ameaça
integridade e não-repúdio;
• Mensagens mal formatadas: intrusos
podem preencher mensagens com
estruturas inválidas e enviá-las a
clientes e servidores OPC UA. Ameaça
integridade e não-repúdio;

15. Ameaças de segurança
• Perfilamento de servidor: um intruso envia
mensagens com formatação válida ou inválida
ao servidor OPC. Ameaça confidencialidade
diretamente e todas as outras qualidades
indiretamente;
• Sessão hijacking: Um intruso injeta
mensagens com formatação OPC-UA válida
dentro de uma sessão existente através da
observação de uma sessão. Ameaça todos os
pontos de segurança;

16. Ameaças de segurança
• Servidor rogue: um ataque pode gerar
um servidor malicioso ou instalar um
servidor original em um host diferente.
Ameaça todos os pontos de segurança;
• Cliente rogue: um intruso gera um
cliente malicioso ou um genuíno e envia
mensagens para o servidor de uma
forma diferente. Ameaça todos os
pontos de segurança;

17. Ameaças de segurança
• Comprometimento de credenciais de
usuário: intruso obtém credenciais de
usuário tais como nomes de usuário,
senhas, certificados, ou chaves, pela
observação dos mesmos em papéis,
telas, comunicações eletrônicas, ou
quebrando-os por suposição ou uso de
ferramentas automáticas como
“quebradores” de senhas. Ameaça
autorização.

18. Ambiente de segurança OPC UA
• O uso de OPC UA pode ser alvo atrativo para
espionagem industrial ou sabotagem;
• Pode ser exposto a ameaças através malware
(como worms) circulando em redes públicas;
• Alguns clientes e servidores OPC UA podem
ficar no mesmo host e serem mais facilmente
protegidos de ataques externos;

19. Ambiente de segurança OPC UA
• Alguns clientes e servidores ficam em
diferentes hosts na mesma rede de
operações e podem ser protegidos pelos
limites de segurança que separam a rede de
operações das conexões externas;
• Algumas aplicações OPC UA rodam em
ambientes relativamente abertos onde
usuários e aplicações são difíceis de
controlar, enquanto outras são embutidas em
sistemas de controle que não têm conexão
eletrônica direta com sistemas externos;

20. Ambiente de segurança OPC UA
• A segurança OPC UA trabalha dentro do
sistema de segurança total do site: programas
de segurança que dirigem políticas de
segurança e procedimentos, pessoal,
responsabilidades, auditoria, e segurança
física;
• Estes programas de segurança de sites
tipicamente tratam ameaças que incluem
aquelas descritas anteriormente.

21. Ambiente de segurança OPC UA
• Os requisitos de segurança das interfaces
OPC UA que estão instalados em um site são
especificados pelo mesmo, não pela
especificação OPC UA;
• OPC UA especifica características
pretendidas, de modo que produtos clientes e
servidores possam unificar requisitos de
segurança, que esperam ser feitas pelos sites
onde serão instalados.

22. Arquitetura de segurança OPC
UA
• A arquitetura de segurança OPC UA é uma
solução genérica que permite implementação
das características de segurança requeridas
em vários lugares na arquitetura OPC UA;
• Alguns perfis, definidos em UA, impõem
exigências sobre os produtos certificados,
mas eles não impõem exigências no modo
como eles são usados;
• Diferentes perfis especificam diferentes
detalhes tais como algoritmos de encriptação
requeridos por funções UA;

23. Arquitetura de segurança OPC
UA
• Na arquitetura OPC UA, do ponto de vista de
segurança, a camada de serviço implementa
os serviços que o cliente chama e que se
dirigem ao servidor;
• Os serviços mapeiam as comunicações
dentro de protocolos de suporte;
• Há uma escolha das pilhas de protocolo de
suporte em UA. As diferentes pilhas provêem
segurança de acordo com seus próprios
projetos;

24. Arquitetura de segurança OPC
UA
• OPC UA não confia no uso de TLS/SSL para
controlar a criação e manutenção de um canal
seguro. Há três razões principais para isto:
– OPC UA requer segurança fim a fim considerando
que SSL provê apenas ponto a ponto;
– OPC UA deve não ser ligado ao TCP;
– OPC UA exige que todas as mensagens sejam
unidas a um canal seguro no nível de aplicação,
mas que poderia não ser possível usando SSL.

25. Políticas de segurança
• Especificam quais mecanismos de
segurança devem ser usados;
• Os mecanismos especificados incluem o
seguinte:
– Quais mensagens serão assinadas (todas
as mensagens, apenas atualizar
mensagens, ou nenhuma mensagem);
– Se encripta todas as mensagens ou
nenhuma mensagem;
– Algoritmos para assinatura e encriptação;

26. Políticas de segurança
• A escolha da política é normalmente feita pelos
administradores do sistema de controle, tipicamente
quando os produtos cliente e servidor são instalados;
• Se um servidor serve múltiplos clientes, ele mantém
seleções de políticas separadas para clientes
diferentes de modo a permitir a um novo cliente
selecionar políticas sem nenhuma restrição baseada
em escolhas de políticas que outros clientes tenham
selecionado para suas sessões;
• A estrutura de política de segurança pode ser
estendida em versões OPC UA posteriores, assim
esta permite campos adicionais de forma que seja
compatível com servidores que conformam a versões
posteriores de OPC UA.

27. Serviços de segurança OPC UA
• Canal seguro: tipo de serviço OPC UA que é
usado para negociar os parâmetros de
segurança, isto é, os algoritmos de
encriptação e assinatura, para serem usados
para comunicações entre o cliente e o
servidor;
• Sessão montada: conexão entre um usuário e
um servidor, cuja segurança depende de um
canal seguro e da autenticação do usuário.
Com um canal seguro estabelecido, uma
sessão segura é criada.

28. Auditoria
• Tentativas de conexão realizadas com
sucesso ou sem sucesso, resultados de
negociações de opção de segurança, e
sessão rejeitada são registradas no log da
auditoria de clientes e servidores;
• OPC UA provê suporte para auditoria de
segurança através de dois mecanismos:
– Primeiro, é provido o log de auditoria para
rastreamento entre cliente e servidor;
– Segundo, OPC UA também define outros
parâmetros de auditoria de segurança padrão que
estarão incluídos nos logs.

29. Auditoria
• Cliente e servidor simples: o cliente “A”
executa algumas operações de auditoria,
invocando um serviço OPC UA no servidor
“D”. Ele grava seu próprio log de auditoria e
inclui o identificador da entrada no pedido de
serviço que é submetido ao servidor;
• Servidor agregado: um servidor que provê
seus serviços pelo acesso de serviços de
outros servidores OPC UA, que consulta
servidores das camadas mais baixas. Neste
caso, cada servidor recebe requisições e cria
suas próprias entradas no log para elas.

30. Auditoria
• Agregação através de um servidor sem auditoria:
cada servidor recebe suas requisições e cria suas
próprias entradas de log de auditoria para elas, com
exceção do servidor “X”, que não suporta auditoria.
Assim, “X” passa a identificação de auditoria recebida
do cliente “A” para o próximo servidor;
• Servidor agregado com distribuição de serviço: um
cliente submete uma requisição de serviço a um
servidor agregado, e o servidor agregado suporta
aquele serviço pela submissão de vários pedidos de
serviço a seus servidores subjacentes.

31. Acordo do objetivo de segurança
OPC UA
• Autenticação cliente/servidor:
Aplicações cliente e servidor OPC UA
se identificam e se autenticam com
certificados X.509;
• Autenticação de usuário: um software
de aplicação cliente OPC UA aceita um
símbolo (token) de identificação do
usuário, autentica este símbolo e o
passa para o servidor OPC UA.

32. Acordo do objetivo de segurança
OPC UA
• Autorização:
– Aplicações cliente e servidor devem determinar
autorizações garantindo todos os privilégios a
qualquer usuário ou cliente autenticado; ou
garantindo tipos específicos de privilégios a
conjuntos específicos de objetos para diferentes
grupos de usuários;
– Identificação e autenticação de usuários são
especificadas em OPC UA de maneira a
determinar as autorizações do usuário.

33. Acordo do objetivo de segurança
OPC UA
• Confidencialidade: a confidencialidade
do usuário, aplicação e credenciais de
software, e dos parâmetros, é
assegurada pelos mecanismos de
encriptação que podem ser
implementados em aplicações e
serviços OPC UA.

34. Acordo do objetivo de segurança
OPC UA
• Integridade/Autenticação de mensagem:
– Integridade é provida na aplicação e nas
camadas de serviço OPC UA usando “selos
de tempo” (time stamps), números de
seqüência, e chaves de sessão que o
cliente e o servidor usam para assinar ou
encriptar mensagens;
– O cliente e o servidor negociam as chaves
de sessão periodicamente para dificultar o
trabalho de um intruso de obter informação.

35. Acordo do objetivo de segurança
OPC UA
• Proteção de replay:
– OPC UA protege, contra replay, com assinaturas
de cabeçalhos de mensagens que contêm a
identificação (id) da sessão, número de seqüência
e o timestamp;
– Os serviços OPC UA ou o protocolo de suporte
pode assinar ou encriptar a mensagem;
– Assinar a mensagem inteira protege todos os seus
componentes contra modificação por um intruso;
– Encriptar a mensagem inteira protege a
confidencialidade de seus componentes.

36. Acordo do objetivo de segurança
OPC UA
• Auditoria: OPC UA suporta log de
auditoria fornecendo entradas de log em
diferentes clientes e servidores;
• Disponibilidade: não há mecanismos
específicos na especificação OPC UA
para proteger disponibilidade. Os
mecanismos de autenticação
contribuem para negação de partes não
autorizadas;

37. Considerações de
implementação
• Certificados auto-assinados: é
recomendado que todas as aplicações
UA criem um único certificado auto-
assinado sempre que uma nova
instância da aplicação é instalada. A
chave pública para este certificado
autogerado deve ser armazenada em
um local acessível ao administrador;

38. • Intervalos de tempo (timeouts)
apropriados: o tempo que a
implementação espera - usualmente
para um evento tal como a chegada de
uma mensagem - tem um papel muito
significativo em influenciar a segurança
de uma implementação; Tem como
conseqüências potenciais “negação de
serviço” e “consumo de recurso”;

39. Considerações de
implementação
• Processamento de mensagem estrita:
– Quem implementa deve fazer checagem estrita do
formato da mensagem e deve deixar os pacotes se
perderem ou enviar uma mensagem de erro;
– Tratamento de erro usa código de erro que mais
precisamente ajusta a condição;
– Algumas recomendações específicas consideram
codificação e decodificação de mensagens
XML/binárias ou específicos tipos de dados.

40. Considerações de
implementação
• Recuperação robusta a erros: um erro
(queda, entrada errada num estado do
protocolo, etc.) no protocolo pode
ocorrer devido a várias razões. Boas
práticas de recuperação de erro devem
ser implementadas de modo que a
implementação se recupere do erro.

41. Considerações de
implementação
• Geração de números randômicos:
especificações freqüentemente usam
“números randômicos ou não previstos”
descrevendo um item de mensagem.
Freqüentemente tipos de mensagem são
reservados como especial (como endereços
broadcast e multicast na especificação IP). A
não compreensão e interpretação da
implementação destes pacotes especiais
pode conduzir a vulnerabilidades.

42. Considerações de
implementação
• Controle de fluxo e taxa limite: OPC-
UA não fornece mecanismos de
controle de taxa, entretanto uma
implementação pode incorporar controle
de taxa.

43. Contato:
dalton.valadares@caruaru.ifpe.edu.br