Modelo de segurança OPC UA

Traduzido por: Dalton Cézane Gomes Valadares
Instituto Federal de Pernambuco (IFPE)
Introdução
Esta especificação define o modelo de segurança e as funções de segurança da
Arquitetura Unificada OPC (UA). Serviços específicos, mapeamentos e perfis que
suportam estas funções de segurança são descritos nas respectivas seções que seguem neste
documento.
1 Escopo
Esta especificação descreve o modelo de segurança da Arquitetura Unificada OPC.
São descritas as ameaças de segurança nos ambientes “físico”, hardware e software nos
quais UA pode ser implementado. Descreve como UA utiliza outros padrões para
segurança. Apresenta uma visão de características de segurança que são especificadas em
outras partes da especificação OPC UA. Referencia serviços, mapeamentos e perfis que são
especificados em outras partes deste documento. Esta parte da especificação é informativa
ao invés de normativa. Qualquer ambigüidade entre esta parte e a parte normativa não
remove ou reduz os requisitos especificados na parte normativa.
Esta parte 2 é direcionada a leitores que desenvolverão aplicações cliente ou
servidor em OPC UA, ou implementam serviços de camadas OPC UA.
3 Termos, definições e abreviações
3.1 Termos do OPC UA – Parte 1
Os seguintes termos definidos em [UA Parte 1] são aplicados:
1) Certificado
2) Comando
3) Evento
4) Mensagem
5) Notificação
6) Subscrição
3.2 Objetivos de segurança
3.3 Termos de segurança OPC UA
3.3.1 Autenticação
Autenticação é o processo de verificação da identidade de uma entidade como
cliente, servidor ou usuário. Autenticação pode ser baseada em alguma coisa que a entidade
é, tem ou conhece.

3.3.2 Autorização
Uma “autorização” é um direito ou uma permissão que é garantida a uma entidade
para acessar um recurso de sistema [Glossário IS]. É fundamental à segurança assumir que
partidos podem apenas ver e mudar informação que eles estão autorizados a ver ou mudar.
Autorização pode ser tão grosseira como permitir ou impedir um cliente de acessar um
servidor (fazer alguma chamada), ou menos grosseira como permitir ações específicas em
itens de informação específicos por determinados usuários.
Autorização deve ser suportada por identificação e autenticação dos partidos.
3.3.3 Confidencialidade
Confidencialidade é a proteção de dados (em transmissão ou armazenados em
algum local) contra ataques passivos. Para prover confidencialidade, algoritmos de
encriptação de dados são utilizados.
3.3.4 Integridade
Integridade é o processo de assegurar que a mensagem é recebida como enviada, ou
seja, não foi modificada durante a transmissão. Integridade é a qualidade da informação tal
que o destinatário obtém a mesma informação que foi enviada pelo remetente. Integridade
de mensagem é ameaçada por spoofing de mensagens, alteração de mensagens e replay de
mensagens. Integridade de sessão é ameaçada por hijacking de sessão.
3.3.5 Auditoria
Auditoria examina a segurança do sistema em operação. Um sistema provê
informação valiosa em uma auditoria deixando logs de segurança que relatam eventos
como eles acontecem. Estes eventos incluem novas conexões e respostas a erros de
segurança para chamadas de serviços.
3.3.6 Não-repúdio
Não-repúdio previne qualquer remetente e destinatário da negação da mensagem
transmitida. Assim, o destinatário pode provar que a mensagem foi, de fato, enviada pelo
remetente alegado. Com o intuito de oferecer isto ao cliente, criptografia assimétrica é
necessária. Não-repúdio é particularmente importante em indústrias, como, por exemplo,
indústrias farmacêuticas que têm requisitos legais e regulares para chamar atenção de
clientes individuais para suas ações de processo.
3.3.7 Disponibilidade
Disponibilidade significa o tempo de execução do sistema sem qualquer
impedimento (sem interrupção na execução). Disponibilidade é “interrompida” quando a
execução do software que precisa rodar é parada ou quando o software ou o sistema de
comunicação está ocupado processando entrada improdutiva. Disponibilidade interrompida
em OPC UA pode aparecer como baixo retardo do desempenho de subscrição ou
inabilidade para adicionar sessões.

3.3.8 Aplicação OPC UA
Uma aplicação OPC UA é uma instância de um cliente ou servidor OPC UA
rodando em um computador individual, possivelmente concorrente com outras aplicações
OPC UA naquele computador.
3.3.9 Certificado de instância de aplicação
Um certificado de instância de aplicação é um certificado digital de uma instância
individual de uma aplicação que está instalada em um host individual. Diferentes
instalações de um software teriam diferentes certificados de aplicação.
3.3.10 Certificado X.509
Um certificado de chave pública X.509 é um certificado em um dos formatos
definidos pelo X.509 v1, 2 ou 3. Um certificado de chave pública X.509 contém uma
seqüência de dados (itens) e tem uma assinatura digital computada nesta seqüência.
3.3.11 Certificado digital
Certificado digital é uma estrutura que associa uma identidade a uma entidade tal
como um usuário ou uma instância de aplicação. O certificado tem um par de chaves
assimétricas que pode ser usado para autenticar a entidade que possui a chave privada.
3.3.12 Conjunto de chave de sessão
É uma chave simétrica que é usada para encriptar ou assinar mensagens em uma
sessão ou dois pares de chaves assimétricas que são usadas para o mesmo fim.
3.3.13 Símbolo de segurança
Um identificador para um conjunto de chaves de sessão usado para encriptar e
assinar mensagens trocadas entre cliente e servidor. Todos os símbolos de segurança
pertencem a um contexto de segurança.
3.3.14 Canal de segurança
Um canal de segurança em OPC UA é um caminho de comunicação estabelecido
entre um cliente OPC UA e um servidor, que estão autenticados um pelo outro usando
certos serviços OPC UA, e pelo qual parâmetros de segurança são negociados e aplicados.
3.3.15 Nonce
Um número pseudo-randômico que é usado apenas uma vez. Nonces são
freqüentemente usados em algoritmos que geram chaves de segurança ou em testes de
desafio/resposta.
3.3.16 Criptografia assimétrica
Uma moderna idéia de criptografia (também conhecida como “criptografia de chave
pública”) na qual os algoritmos empregam um par de chaves (uma chave pública e uma
chave privada) e usam um componente diferente do par para diferentes passos do
algoritmo.
Algoritmos assimétricos têm vantagens no gerenciamento de chaves sobre os fortes
algoritmos simétricos. Primeiro, uma chave do par não precisa ser conhecida por ninguém
além do dono; então, pode facilmente ser mantida em segredo. Segundo, embora a outra

chave do par seja compartilhada por todas as entidades que usam o algoritmo, a mesma não
precisa ser mantida em segredo; então, a parte de distribuição de chaves pode ser feita mais
facilmente.
Para encriptação: em um algoritmo de encriptação assimétrico (RSA, por exemplo),
quando Alice quer assegurar confidencialidade dos dados que ela envia a Bob, ela encripta
os dados com a chave pública provida por Bob. Somente Bob tem a chave privada que é
necessária para decriptar os dados.
Para assinatura: em um algoritmo de assinatura digital assimétrica (DAS, por
exemplo), quando Alice quer assegurar integridade dos dados ou prover autenticação aos
dados que ela envia a Bob, ela usa sua chave privada para assinar os dados (ou seja, cria
uma assinatura digital baseada nos dados). Para verificar a assinatura, Bob usa chave
pública respectiva que Alice disponibilizou.
Para chave de acordo: em um algoritmo de acordo de chave assimétrica (por
exemplo: Diffie-Hellman), Alice e Bob enviam, ambos, suas chaves públicas, um para o
outro. Então cada um usa sua própria chave privada e a chave pública do outro para
computar o novo valor de chave [Glossário IS].
3.3.17 Função Hash
O tipo de função hash necessário para aplicações de segurança é chamado “função
hash criptográfica”, um algoritmo tal que é computacionalmente impraticável (porque sem
ataque é significantemente mais eficiente que força bruta) encontrar qualquer outro objeto
que mapeie para um pré-especificado resultado hash (a propriedade “one-way”: não é
possível recuperar o valor original de um número que tenha sido obtido por uma função
hash) ou dois objetos que mapeiem a um mesmo resultado hash (propriedade “colision-
free”). [Glossário IS].
3.3.18 Infra-estrutura de chave pública
Um sistema de CAs (e, opcionalmente, RAs e outros servidores e agentes de
suporte) 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.
Uso PKIX: o conjunto de hardware, software, pessoas, políticas, e procedimentos
necessários para criar, gerenciar, armazenar, distribuir e revogar certificados digitais
baseados em criptografia assimétrica.
As funções PKI são para registrar usuários e publicar seus certificados de chave
pública, para revogar certificados quando requeridos e para arquivar dados necessários para
validar certificados depois de um certo tempo. Pares de chave para confidencialidade de
dados podem ser gerados por CAs ou RAs, mas requerem um cliente PKI para gerar seu
próprio par de assinaturas digitais que ajuda a manter a integridade do sistema, porque,
assim, só o cliente possui a chave privada. Também, uma autoridade pode ser estabelecida
para aprovar ou coordenar CPSs, que são políticas de segurança sob as quais componentes
de um PKI operam.
Um número de outros servidores e agentes podem suportar o núcleo PKI e clientes
PKI podem obter serviços deles. A lista completa de tais serviços ainda não é entendida e
evoluída, mas suportar funções pode incluir agente de arquivo, agente certificado de
entrega, agente de confirmação, diretório, agente de geração de chave, nomear agente que

assegura que assuntos têm únicos identificadores sem o PKI, repositório, e agente de time
stamp. [Glossário IS]
3.3.19 Criptografia simétrica
Uma parte da criptografia que envolve algoritmos que usam a mesma chave em dois
passos diferentes no mesmo (tanto para encriptar, quanto para decriptar, ou criar e verificar
assinatura).
Criptografia simétrica também é chamada “criptografia de chave privada (secreta)”
(ao contrário da criptografia de chave pública) porque as entidades que compartilham a
chave, entidade geradora e entidade de destino da mensagem, precisam manter a chave em
segredo. Por exemplo, quando Alice quer assegurar confidencialidade para dados que ela
envia a Bob, ela encripta os dados com a chave secreta e Bob usa a mesma chave para
decriptá-los. Manter a chave compartilhada segura envolve custo e riscos quando a chave é
distribuída para Alice e Bob. Assim, criptografia simétrica tem uma desvantagem no
gerenciamento de chaves comparada à criptografia assimétrica. [Glossário IS]
3.3.20 Chave pública
O componente de divulgação pública de um par de chaves criptográficas usado para
criptografia assimétrica. [Glossário IS]
3.3.21 Chave privada
O componente secreto de um par de chaves criptográficas usado por criptografia
assimétrica.
3.3.22 Símbolos e abreviações
A&E Eventos e alarmes
API Interface de programação de aplicação
COM Modelo de objetos componentes
DA Acesso de dados
DCOM COM distribuído
DSA Algoritmo de assinatura digital
DX Dados de troca
HDA Acesso a histórico de dados
PKI Infra-estrutura de chave pública
RSA Algoritmo de chave pública para assinatura ou encriptação (Rivest, Shamir e
Adleman)
SHA1 Algoritmo de hash seguro
SOAP Protocolo acesso a objetos simples
SSL Camada segura de soquetes
TLS Segurança da camada de transporte
UA Arquitetura unificada
UML Linguagem de modelagem unificada
WDSL Linguagem de definição de serviços web (web services)
XML Linguagem de marcação extensível

3.5 Convenções
3.5.1 Convenções para figuras de modelo de segurança
As figuras, neste documento, não usam quaisquer convenções especiais comuns.
Algumas convenções usadas em uma determinada figura são explicadas na mesma.
4 Ameaças de segurança
Algumas ameaças, dirigidas ao OPC UA, nos mecanismos de segurança são
descritos nesta seção. A fundação OPC recomenda que fabricantes atentem para
determinadas ameaças, como detalhado na seção de implementação do fabricante e na
seção de recomendações de segurança (site).
Tabela 1 - Ameaças
Ameaça Descrição Impacto
Enchente de
mensagem
(Flooding)
Um intruso pode enviar um grande
volume de mensagens (ou uma
mensagem simples que contém um
grande número de requisições) com
o objetivo de tentar “derrubar” o
servidor OPC ou componentes que o
servidor OPC pode depender em
operações de confiança como CPU,
pilha TCP/IP, Sistema Operacional,
sistema de arquivo.
Clientes mal comportados realizam
“flooding” no servidor com
requisições. Dois casos existem, um
no qual o cliente não tem uma sessão
com o servidor, e o outro no qual ele
tem.
Impossibilitado de
estabelecer sessões
OPC_UA. Ameaça a
disponibilidade.
Eavesdropping Se um intruso comprometeu o
sistema operacional subjacente ou a
infra-estrutura de rede, o mesmo
pode gravar e capturar mensagens.
Pode estar além da capacidade de
um servidor ou um cliente se
recuperar de um sistema operacional
comprometido.
Divulgação não autorizada
de informação sigilosa que
pode resultar em uma
ruptura crítica de segurança
ou pode ser usada para
ataques seguintes. Ameaça
confidencialidade,
diretamente, e ameaça todas
as outras qualidades de
segurança, indiretamente.
Mensagem
mascarada
Um intruso pode forjar mensagens
de um cliente ou servidor. O ato de
mascarar pode ocorrer em múltiplas
camadas na pilha de protocolo. Esta
ameaça não inclui examinar uma
sessão, o que é descrito como
“Hijacking de sessão”.
Através de mensagens
mascaradas, um intruso
pode realizar operações não
autorizadas ou impedir
detecção. Ameaças de
integridade, autorização e
não-repúdio.

Alteração de
mensagem
Mensagens na camada de aplicação e
de rede podem ser capturadas,
modificadas e reenviadas para
clientes e servidores OPC.
Acesso ilegítimo ao sistema.
Ameaça integridade,
autorização e não-repúdio.
Replay de
mensagens
Mensagens na camada válida de
aplicação e de rede podem ser
capturadas e enviadas a clientes e
servidores OPC.
Um intruso poderia informar
erroneamente o usuário ou
causar um comando
incorreto ao sistema de
controle. Ameaça
integridade e não-repúdio.
Mensagens mal
formatadas
Um intruso pode preencher uma
variedade de mensagens com
estruturas de mensagens inválidas
(XML mal formatado, SOAP,
codificações binárias maliciosas,
etc.) ou certos dados, e enviá-los ao
cliente ou servidor OPC-UA.
O cliente/servidor OPC pode
realizar operações não
autorizadas ou disponibilizar
informação desnecessária.
Ou pode resultar em
negação ou degradação do
serviço incluindo finalização
de aplicação (no caso de
dispositivos embutidos).
Ameaça integridade e não-
repúdio.
Perfilamento de
servidor
Um intruso envia mensagens com
formatação válida ou inválida ao
servidor OPC.
Descoberta do fabricante,
versão, ou outra informação
sobre OPC-UA que pode ser
usada em ataques seguintes.
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.
Ataque pode ganhar acesso
não autorizado a dados ou
autorizadas. Ameaça todos
os pontos de segurança.
Servidor rogue Um ataque gera um servidor OPC-
UA malicioso ou instala um servidor
original OPC-UA em um host
diferente.
O cliente OPC pode
disponibilizar informação
desnecessária. Ameaça todos
os pontos de segurança.
Cliente rogue Um intruso gera um cliente
malicioso OPC-UA ou obtém um
cliente OPC-UA genuíno e envia
mensagens com formatação válida
para o servidor OPC-UA de uma
fonte diferente.
Ataque pode ganhar acesso
não autorizado a dados ou
autorizadas. Ameaça todas
as características (todos os
pontos) de segurança.
Comprometimento
de credenciais de
usuário
Um intruso obtém credenciais de
usuário tais como nomes de usuário,
senhas, certificados, ou chaves, pela
Um usuário não autorizado
pode lançar e acessar o
sistema para obter toda a

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.
informação e fazer
alterações de controle e
dados que danifiquem as
operações ou informação.
Uma vez comprometidas as
credenciais que são usadas,
atividades subseqüentes
podem parecer legítimas.
Ameaça autorização.
Ameaças aos componentes de infra-estrutura que podem resultar no
comprometimento de sistemas operacionais de cliente e servidor não são endereçadas pelo
OPC-UA. Estes são interesses dos fabricantes ou usuários finais e a especificação não
provê contramedidas que se direcionem a este tipo de ameaça.
5 Arquitetura de segurança OPC UA
5.1 Ambiente de segurança OPC UA
OPC-UA é uma interface usada entre componentes na operação de uma facilidade
industrial em múltiplas camadas: do gerenciamento de empresa alto-nível ao processo
direto baixo-nível de controle de dispositivo. O uso de OPC-UA para gerenciamento de
empresa envolve acordos com consumidores e fornecedores. Pode ser alvo atrativo para
espionagem industrial ou sabotagem e pode, também, ser exposto a ameaças através
malware (como worms) circulando em redes públicas. Rompimento de comunicações no
processo de controle final causa, no mínimo, um custo econômico à empresa e pode ter
conseqüências no empregado e na segurança pública ou causar danos ambientais. Este pode
ser um alvo atrativo para aqueles que buscam prejudicar a empresa ou a sociedade.
OPC-UA será desdobrado em uma escala diversa de ambientes operacionais, com
suposições variando sobre ameaças e acessibilidade, e com uma variedade de políticas de
segurança e regimes reforçados. Deve, conseqüentemente, prover um conjunto flexível de
mecanismos de segurança. A figura 1 mostra uma combinação de cada ambiente. Alguns
clientes e servidores OPC UA estão no mesmo host e podem ser mais facilmente protegidos
de ataques externos. Alguns clientes e servidores estão 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. Outras aplicações
são embutidas em sistemas de controle que não têm conexão eletrônica direta com sistemas
externos.
Figura 1 – Modelo de rede OPC UA
OPC UA pode rodar em diferentes lugares nesta grande escala de ambientes. Cliente
e servidor podem comunicar dentro do mesmo host ou entre hosts dentro de uma rede de
controle altamente protegida. Alternativamente, clientes e servidores OPC UA podem se
comunicar no ambiente mais aberto da Internet. As atividades OPC UA são protegidas por
qualquer controle de segurança que o site possua para as partes do sistema dentro do qual o
OPC UA roda.

5.2 Relacionamento OPC UA com a segurança do site
A segurança OPC UA trabalha dentro do sistema de segurança total do site. Sites
freqüentemente têm um programa de segurança que dirige 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 na seção 4.
Eles também analisam os riscos de segurança e determinam que controles de segurança são
necessários.
Controles de segurança resultantes geralmente implementam uma estratégia de
“defesa em profundidade” que provê múltiplas camadas de proteção e reconhece que
nenhuma simples camada pode proteger contra todos os ataques. Limites de proteção, como
mostrados na figura 1, podem incluir firewalls, sistemas de detecção de intrusão, controles
em conexões dial-up, e controles em mídia e computadores que estão dentro do sistema.
Proteções em componentes do sistema podem incluir configuração mais complicada de
sistemas operacionais, gerenciamento de patches de segurança, programas antivírus, e a não
permissão de e-mails dentro da rede de controle. Padrões que devem ser seguidos por um
site incluem CIP 002-1 através de CIP 009-1 e IEC 62351 que são referenciados na seção 2.
Os requisitos de segurança de um site aplicam-se às interfaces OPC UA. Isto é, 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. Aqueles
que são responsáveis pela segurança do site determinam como reunir os requisitos do site
com os produtos OPC UA.
O sistema proprietário que instala clientes e servidores OPC UA deve analisar seus
riscos de segurança e prover mecanismos apropriados para minimizar os mesmos e alcançar
um nível de segurança apropriado. OPC UA deve reunir a grande variedade de necessidades
de segurança resultante de cada análise individual. Clientes e servidores OPC UA são
requisitados para serem implementados com certas características de segurança, que são
disponíveis para uso opcional do sistema proprietário. Cada sistema proprietário poderia
estar habilitado a construir uma solução que reúna seus requisitos de segurança e economia
usando uma combinação de mecanismos disponíveis dentro da especificação OPC UA e
externas ao OPC UA.
Os requisitos de segurança localizados em clientes e servidores OPC UA instalados
em um site são especificados pelo site, não pela especificação OPC UA. As especificações
de segurança OPC UA, entretanto, são requisitos localizados sobre produtos clientes e
servidores OPC UA e recomendações de como OPC UA pode ser instalado em um site de
modo a reunir os requisitos de segurança que são antecipados para estar em um site
especificado.
5.3 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. Dependendo dos diferentes mapeamentos descritos em [UA Parte 6] as
funcionalidades de segurança são direcionadas em diferentes níveis.

Produtos cliente e servidor são certificados contra perfis que são definidos em [UA
Parte 7]. Alguns dos perfis especificam funções de segurança e outros especificam outra
funcionalidade que não é relacionada à segurança. Os perfis impõem exigências sobre os
produtos certificados, mas eles não impõem exigências no modo como eles são usados. Um
mínimo nível consistente de segurança é exigido pelos vários perfis; entretanto, diferentes
perfis especificam diferentes detalhes tais como algoritmos de encriptação requeridos por
funções UA. Se um problema é encontrado em um algoritmo de encriptação então OPC
pode definir um novo perfil que é similar, mas que especifica um algoritmo diferente que
não tem um problema conhecido. [UA Parte 7], não [UA Parte 2], é a especificação
normativa dos perfis.
Cada mecanismo de segurança em OPC UA será provido em produtos cliente e
servidor de acordo com os perfis que o cliente ou servidor aceitam. No site, entretanto, os
mecanismos de segurança podem ser instalados opcionalmente. Neste caso, cada site
individual tem todas as funções de segurança disponíveis e pode escolher qual delas usar
para reunir seus requisitos de segurança.
A figura 2 mostra a arquitetura OPC UA de um ponto de vista de arquitetura de
segurança. Há a combinação das arquiteturas OPC UA cliente e servidor que são descritas e
ilustradas em [UA Parte 1]. 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.
Figura 2 – Arquitetura de segurança OPC UA
Os dois mapeamentos da pilha de protocolo de suporte alternativo são o
mapeamento nativo UA e o mapeamento de web services.
Se o mapeamento nativo UA está em uso, então encriptação e autenticação de
mensagem são feitos através de mensagens binárias UA como descrito em detalhes em [UA
Parte 6].
Se o mapeamento de web services estiver em uso, então a segurança WS provê a
integridade e a encriptação e troca de chaves, além de montar o canal seguro. Para mais
informações específicas, vê [UA Parte 6].
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 não confia em SSL para solução completa de segurança porque OPC UA
requer segurança fim a fim (necessita definição) considerando que SSL provê
apenas ponto a ponto. (OPC UA terá nós interinos que passam mensagens, mas que
não devem estar habilitados para entender o conteúdo destas mensagens)
 Também, OPC UA não confia completamente em SSL porque 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.
Entretanto, dependendo do mapeamento usado para implementar os serviços, as
bibliotecas de uma implementação TLS/SSL podem ser usadas para prover autenticação de
mensagem (integridade) e encriptação (confidencialidade).

5.4 Política de segurança
Políticas de segurança especificam quais mecanismos de segurança devem ser
usados. Políticas de segurança são usadas pelo servidor para anunciar quais políticas são
suportadas e para o cliente selecionar uma destas disponíveis a ser usada para a sessão que
o mesmo deseja abrir. 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.
Políticas se referem a muitas das mesmas alternativas de segurança como perfis,
entretanto a política especifica qual destas se deve usar na sessão. A política não especifica
a gama de alternativas que o produto deve oferecer como o perfil faz.
A escolha da política é normalmente feita pelo administrados 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. Isso é mostrado na Figura 2.
[UA Parte 7] especifica várias políticas. Produtos do servidor deveriam implementar
estas políticas de preferência para definir suas próprias de modo a melhorar a
interoperabilidade entre produtos de fabricantes.
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.
5.5 Serviços de segurança OPC UA
5.5.1 Canal seguro
Os serviços OPC UA (que são especificados em [UA Parte 4]) incluem dois
conjuntos de serviços para propósitos de segurança. O primeiro é o conjunto de serviço
“Canal Seguro” 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. O conjunto de serviço “Canal Seguro” também permite autenticação de cliente e
servidor. Uma vez o cliente e o servidor tendo concordado os parâmetros de segurança e
tendo sucesso na autenticação de cada, um canal seguro é criado, que assina e/ou encripta
mensagens trocadas entre cliente e servidor. As chaves usadas para as funcionalidades
criptográficas são computadas individualmente pelo cliente e o servidor baseado em dados
que são trocados usando o serviço “Canal Seguro”.
5.5.2 Sessão montada
Uma sessão é uma conexão entre um usuário e um servidor. A segurança da sessão
depende de um canal seguro e de autenticação do usuário. Uma vez que o canal seguro foi
estabelecido, como descrito na seção 5.5.1, então uma sessão segura é criada. O cliente e o

servidor usam a sessão segura para continuar suas comunicações normais sobre dados de
processo.
UA provê um mecanismo para troca de credenciais de usuário, mas não especifica
como as aplicações usam estas credenciais. Aplicações de cliente e servidor podem
determinar que dado está acessível e quais operações são autorizadas nestes próprios
modos.
5.6 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 serã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. O cliente
gera uma entrada no log para uma operação que inclua um pedido que ele envia ao servidor,
incluindo o identificador local da entrada do log no pedido. Os pedidos de log do servidor,
que foram recebidos, incluirão a identificação da entrada do cliente na entrada do log de
auditoria. OPC UA não especifica se as entradas da auditoria são gravadas no disco, mas
exige que elas estejam disponíveis. OPC UA provê a capacidade para servidores de gerar
notificações de evento que informam eventos de auditoria a clientes capazes de processá-
los e armazená-los. Desta maneira, se um problema de segurança relatado é detectado no
servidor, a entrada do log do cliente associado pode ser localizada e examinada.
Terceiro, OPC UA também define outros parâmetros de auditoria de segurança
padrão que estarão incluídos nos logs. Isto promove consistência nos logs. [UA Parte 5]
define os tipos de dados para estes parâmetros. [UA Parte 7] define perfis que incluem a
habilidade de escrever logs de auditoria e usar estes parâmetros, incluindo a identificação
do cliente registrado.
As cláusulas seguintes ilustram o componente dos servidores e clientes OPC UA
que suportam auditoria. Em adição a estas capacidades, [UA Parte 9] define eventos que
servidores podem gerar para notificar clientes de auditoria que um determinado evento
(relacionado à auditoria) ocorreu.
5.6.1 Cliente e servidor simples
A figura 3 ilustra o caso simples de um cliente se comunicando com um servidor.
Figura 3 – Servidores simples
Neste caso, o cliente “A” executa algumas operações de auditoria que inclui a
invocação de 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.
O servidor recebe o pedido e cria sua própria entrada (registro) no log para este.
Esta entrada é identificada por sua identificação de auditoria e contém sua própria
informação. Também inclui o nome do cliente que emitiu a requisição do serviço e a
identificação da entrada de auditoria do cliente recebida no pedido.
Usando esta informação, um auditor pode inspecionar a coleção de entradas de log
do servidor e relatá-los de volta a suas entradas de clientes associadas.

5.6.2 Servidor agregado
A figura 4 ilustra o caso de um cliente acessando serviços de um servidor agregado.
Um 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.
Figura 4 – Servidores agregados
Neste caso, cada servidor recebe requisições e cria suas próprias entradas no log
para elas. Cada entrada é identificada pela sua própria identificação e contém sua própria
informação de auditoria. Também é incluído o nome do cliente que emitiu a requisição de
serviço e a identificação de entrada de auditoria do cliente desta requisição. O servidor,
então, passa a identificação de auditoria, onde a entrada é criada apenas no próximo
servidor da camada.
Usando esta informação, um auditor pode inspecionar a coleção de entradas de log
do servidor e relatá-los de volta a suas entradas de cliente associadas.
5.6.3 Agregação através de um servidor sem auditoria
A figura 5 mostra o caso de um cliente acessando serviços de um servidor agregado
que não suporta auditoria.
Figura 5 – Agregação com um servidor sem auditoria
Neste caso, cada servidor recebe suas requisições e cria suas próprias entradas de
log de auditoria para elas, com exceção do servidor “B”, que não suporta auditoria. Neste
exemplo, o servidor “B” passa a identificação de auditoria recebida do cliente “A” para o
próximo servidor. Este cria a entrada de auditoria requerida. O servidor “B” não é listado
como servidor que suporta auditoria. Em um caso onde um servidor não suporta gravação
de entradas de auditoria, o sistema inteiro pode ser considerado como não suportando
auditoria.
5.6.4 Servidor agregado com distribuição de serviço
A figura 6 ilustra o caso de um cliente que submete uma requisição de serviço a um
servidor agregado, e o serviço agregado suporta aquele serviço pela submissão de vários
pedidos de serviço a seus servidores subjacentes.
Figura 6 – Servidor agregado com distribuição de serviço
6 Acordo do objetivo de segurança OPC UA
6.1 Introdução
Esta seção mostra como os objetivos são alcançados pela arquitura OPC UA.
6.2 Autenticação
Aplicações OPC UA suportam autenticação das entidades que se comunicam entre
si, bem como fornece as credenciais de autenticação necessárias para outras entidades.

6.2.1 Autenticação cliente/servidor
Aplicações cliente e servidor OPC UA se identificam e se autenticam com
certificados X.509.
6.2.2 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. O
software de aplicação servidor OPC UA autentica o símbolo do usuário. Softwares de
aplicação OPC UA aceitam símbolos em quaisquer das três seguintes formas: nome de
usuário/senha, X.509 v3 ou via web services. Clientes e servidores aceitam nomes de
usuário e senhas.
O símbolo de identidade do usuário é validado com um processo de desafio-resposta
usando a seqüência CreateSession (cria sessão) e AtivateSession (ativa sessão). O servidor
fornece um valor randômico (nonce) e um algoritmo de assinatura como desafio na resposta
do CreateSession. O cliente responde o desafio pela assinatura do valor randômico do
servidor e fornecendo como um argumento sua chamada ao ActivateSession.
6.3 Autorização
OPC UA não especifica como a autorização de usuário ou cliente é provida.
Aplicações cliente e servidor devem determinar autorizações em qualquer caso que eles
desejem, grosso modo garantindo todos os privilégios a qualquer usuário ou cliente
autenticado; ou garantindo, de uma forma mais amena, tipos específicos de privilégios a
conjuntos específicos de objetos para diferentes grupos de usuários. OPC UA suporta
autorização fornecida pelo usuário e pela autenticação e identificação da aplicação.
Identificação e autenticação de usuários são especificadas em OPC UA de modo que
aplicações cliente e servidor possam reconhecer o usuário de maneira a determinar as
autorizações do usuário.
6.4 Confidencialidade
Para proteger contra a divulgação de informação enviada entre cliente e servidor, o
cliente e o servidor devem estar configurados para usar encriptação oferecida pela camada
de transporte. Encriptação nesta camada deve ser ajustada pelo administrador do sistema.
Como descrito nas seções de autenticação e integridade, 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.
6.5 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 suficiente para determinar as chaves e limitar o
tempo que o intruso tem disponível para causar danos com o conjunto de chaves de sessão
dado. O cliente e o servidor protegem a negociação da chave de sessão com suas chaves de
instância de aplicação assimétrica.

6.5.1 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 timstamp. Serviços OPC
UA, quando especificados pela política de segurança negociada, assinam ou encriptam o
cabeçalho ou o corpo das mensagens. O serviço, quando especificado desta forma, assina
ou encripta os corpos inteiros de mensagens atualizadas. Um pedido ou resposta de
atualização é algum serviço que muda o estado do sistema subjacente. Estes serviços são:
Write, HistoryUpdate e Call.
Como timestamps são comparados entre diferentes hosts, as configurações de tempo
dos hosts devem estar sincronizadas com exatidão determinada pelo site. Uma exatidão de
um ou vários minutos pode ser considerada adequada para propósitos de segurança.
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.
6.6 Auditoria
OPC UA suporta log de auditoria fornecendo entradas de log em diferentes clientes
e servidores. Log de auditoria não é estritamente especificado em OPC UA, mas suportes
são especificados de modo que log OPC UA pode ser feito dentro do esquema de sistema
host.
6.7 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.
Alguns ataques em disponibilidade envolvem abrir mais sessões que um servidor
pode tratar e causam falha no mesmo ou lentidão no processo de operação. A documentação
do servidor indicará o número de sessões concorrentes que o mesmo pode tratar. Servidores
são implementados para rejeitar corretamente sessões que excedam o número permitido.
Testes de certificação observam este limite.
7 Considerações de implementação
O propósito desta seção é fornecer um direcionamento aos fabricantes que
implementam clientes e servidores OPC UA, já que muitas das contramedidas requeridas
para tratar as ameaças descritas fogem do escopo da especificação OPC UA...
Para cada uma das seguintes áreas, esta seção define a situação do problema,
identifica as conseqüências se contramedidas apropriadas não são implementadas e
recomenda melhores práticas.
7.1 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. Isto

permitirá o mesmo configure outras aplicações UA que necessitem comunicar com as novas
instâncias de aplicação UA. Estas aplicações devem, também, permitir substituir o
certificado autogerado por um emitido por um CA selecionado pelo administrador. A lista
de certificados verdadeiros deve estar protegida no site contra alteração não autorizada.
Também é recomendado que aplicações UA simplifiquem o processo de adicionar
novos certificados auto-assinados em sua lista de certificados verdadeiros. Se possível, a
aplicação UA deve gerar alguma ordem de notificação sempre que aplicações UA trocarem
certificados usando serviços UA pela primeira vez. O melhor processo depende da
aplicação; entretanto, poderia incluir um diálogo com usuário pedindo ao mesmo confirmar
que o certificado é aceitável. Aplicações de servidores ou aplicações sem uma interface de
usuário poderiam condicionalmente aceitar o certificado e reportar certificados para um
administrador via log de segurança ou e-mail. Aplicações UA nunca devem aceitar
certificados que são auto-assinados ou assinados por uma autoridade de certificação
desconhecida.
7.2 Intervalos de tempo (timeouts) apropriados
Intervalos de tempo (tempo que a implementação espera – usualmente para um
evento tal como a chegada de uma mensagem) têm um papel muito significativo em
influenciar a segurança de uma implementação. Conseqüências potenciais incluem:
 Negação de serviço: negação de condições de serviço pode existir quando um
cliente não reinicia a sessão, se os intervalos de tempo são muito grandes.
 Consumo de recurso: quando um cliente está inativo por longos períodos de tempo,
o servidor mantém a informação do cliente por aquele período, conduzindo à
exaustão do recurso.
Quem implementa deve usar intervalos de tempo razoáveis para cada estágio de
conexão como descrito abaixo: (o texto desta seção acaba aqui...).
7.3 Processamento de mensagem estrita
As especificações freqüentemente especificam o formato das mensagens válidas e
são flexíveis a respeito do que a implementação deve fazer para as mensagens que desviam
da especificação. Tipicamente, as implementações continuam a analisar tais pacotes,
conduzindo a vulnerabilidades.
 Quem implementa deve fazer checagem estrita do formato da mensagem e deve
deixar os pacotes se perderem ou enviar uma mensagem de erro como descrito
abaixo.
 Tratamento de erro usa código de erro, definido na parte 4 desta especificação, 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 (indicadores/arrays de
campo com campos de tamanhos variáveis).
7.4 Recuperação robusta de erros
Um erro (queda, entrada errada num estado do protocolo, etc.) no protocolo pode
ocorrer devido a várias razões tais como má especificação do protocolo ou cliente enviando

mensagens que estão fora do escopo da especificação. Boas práticas de recuperação de erro
devem ser implementadas de modo que a implementação se recupere do erro. Envio de
tipos corretos de mensagens de erro e recuperação de memória são exemplos destas
práticas.
7.5 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. As melhores práticas de implementação para geração
de um número são descritas a seguir.
Interpretação de pacotes especiais e reservados se: alguma especificação
freqüentemente reserva algum tipo de mensagem 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. O que se segue
são tipos de mensagem em OPC-UA e correspondem às melhores práticas de
implementação.
7.6 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.

Modelo de segurança OPC UA

Mais conteúdo relacionado

Semelhante a Modelo de segurança OPC UA

Mais de Dalton Valadares

Modelo de segurança OPC UA