REDES DE SDN, NFV, CLOUD E BLOCKCHAIN

1
 NOSSA HISTÓRIA

A nossa história inicia com a realização do sonho de um grupo de empre-

sários, em atender à crescente demanda de alunos para cursos de Graduação
e Pós-Graduação. Com isso foi criado a nossa instituição, como entidade ofere-
cendo serviços educacionais em nível superior.

A instituição tem por objetivo formar diplomados nas diferentes áreas de

conhecimento, aptos para a inserção em setores profissionais e para a partici-
pação no desenvolvimento da sociedade brasileira, e colaborar na sua formação
contínua. Além de promover a divulgação de conhecimentos culturais, científicos
e técnicos que constituem patrimônio da humanidade e comunicar o saber atra-
vés do ensino, de publicação ou outras normas de comunicação.

A nossa missão é oferecer qualidade em conhecimento e cultura de forma

confiável e eficiente para que o aluno tenha oportunidade de construir uma base
profissional e ética. Dessa forma, conquistando o espaço de uma das instituições
modelo no país na oferta de cursos, primando sempre pela inovação tecnológica,
excelência no atendimento e valor do serviço oferecido.

2
 Sumário
Redes de SDN, NFV, CLoud e Blockchain ..................................................................... 1
NOSSA HISTÓRIA ......................................................................................................... 2
Redes de SDN, NFV, CLoud e Blockchain ..................................................................... 4
Introdução ......................................................................................................................... 4
A arquitetura SND ............................................................................................................ 5
MOTIVAÇÃO .................................................................................................................. 6
REDES DEFINIDAS POR SOFTWARE ........................................................................ 7
Controlador SDN ............................................................................................................ 10
NFV ................................................................................................................................ 15
Virtualização de Funções de Rede.................................................................................. 15
Arquitetura NFV ............................................................................................................. 16
A REALIDADE BRASILEIRA ..................................................................................... 22
Blockchain ...................................................................................................................... 22
Funcionamento de sistemas Blockchain ......................................................................... 23
Identidade e Privacidade ................................................................................................. 23
Transações de informações ............................................................................................. 24
FUNCIONAMENTO DE SISTEMAS........................................................................... 25
Provendo uma Infraestrutura de Software ...................................................................... 28
Fatiamento Seguro de Redes através de Corrente de Blocos ......................................... 30
Modelo de Atacante ........................................................................................................ 31
Referências ..................................................................................................................... 33

3
 Redes de SDN, NFV, CLoud e Blockchain

Introdução
Nas últimas décadas, as redes de computadores vêm se tornando pro-
gressivamente onipresentes, ou ubíquas, sendo utilizadas de forma cada vez
mais intensa e diversificada.
Serviços avançados de rede são essenciais para viabilizar os mais varia-
dos e dominantes tópicos da atualidade, como a computação em nuvem, internet
móvel (5G), a internet das coisas (IoT), o processamento de fluxos (streams)
complexos, serviços multimídias de alta definição – particularmente, serviços de
video streaming, entre muitos outros.
Neste sentido, os requisitos de gerência de redes são cada vez mais altos
e erros humanos se tornam mais frequentes na tomada de decisão.
O gerenciamento de rede, na maioria dos casos, ainda é feito de forma
tradicional utilizando o protocolo simples de gerenciamento de rede (Simple
Network Management Protocol, SNMP), o que dificulta a implementação de no-
vos paradigmas de infraestruturas e novos dispositivos.
A utilização do protocolo SNMP é apenas utilizado no auxílio da gerência
de redes. Sua arquitetura simples não possibilita que seja enviado comandos de
modificações de configuração, não permitindo que seja feita uma interação maior
com os dispositivos de rede.
Redes de computadores são estruturas complexas e dinâmicas que estão
em constantes mudanças de infraestruturas.
Essas estruturas implicam em vários tipos de dispositivos, como switches,
roteadores, firewalls etc.
Novas tecnologias estão constantemente se conectando à rede. Impulsi-
onados pela tecnologia de internet das coisas, computação em nuvem e o aque-
cimento do mercado 5G da tecnologia móvel, o volume de tráfego e o número
de dispositivos e data centers podem dificultar a administração e gerência des-
sas tecnologias.

4
 De acordo com gerentes de TI, a automação de redes (25%) e a arquite-
tura de redes definidas por software (Software Defined Networking, SDN) (23%)
estão entre as tecnologias que terão maior impacto na rede nos próximos cinco
anos (CISCO, 2020).
De acordo com algumas pesquisas, aproximadamente 70% das ativida-
des de rede de um data center são feitas manualmente, o que aumenta o tempo,
o custo, a probabilidade de erros e reduz a flexibilidade (FOREST; RICKARD,
2019).
Essas e outras razões exigem menos intervenção humana e mais auto-
mação. Diversas tecnologias têm surgido para possibilitar o gerenciamento inte-
ligente de redes (“Smart Management”), como por exemplo, a arquitetura SDN
(KIM; FEAMSTER, 2013).

A arquitetura SND
SDN e tecnologias como Virtualização de Função de Redes (Network
Function Virtualization, NFV) estão introduzindo o próximo modelo para o geren-
ciamento de redes.
A arquitetura SDN propõe a separação do plano de controle do plano de
dados (encaminhamento).
Esta separação permite que um único software tenha uma visão geral da
rede, permitindo também o seu controle. Este tipo de separação permite a pro-
gramabilidade direta do plano de controle.
Com o paradigma SDN, a adaptação dinâmica da rede, de acordo com a
demanda atual e os requisitos de serviço, pode ser automatizada com orques-
tração.
Algumas tecnologias como Aprendizagem de Máquina (Machine Lear-
ning, ML) e Sensibilidade a Contexto (Context-Awareness) podem ser usadas
para automatização da operação e do gerenciamento de redes.
Devido à programabilidade oferecida pela arquitetura SDN, ML possibilita
o auto-gerenciamento ou o gerenciamento autônomo de redes, porém pode au-
mentar a complexidade computacional envolvida em treinar modelos de algorit-
mos.

5
 Com a programabilidade disponível na camada de controle, fica possível
implementar políticas e regras simples de sensibilidade a contexto que possam
ajudar a tornar a rede mais adaptativa (AYOUBI et al., 2018), (BUI et al., 2017).
No entanto, de acordo com (AYOUBI et al., 2018), a automação de muitas
tarefas de gerenciamento de redes ainda não foi suficientemente explorada, e,
portanto, há diversas oportunidades e desafios de pesquisa em aberto.
Para Rojas (2018) o paradigma da arquitetura SDN ainda está no início
do seu desenvolvimento e, considerando a automação total e o gerenciamento
sem esforço (effortless) como os principais objetivos destas redes, diversos de-
safios precisam ser enfrentados.
Portanto, ainda é longo o caminho para realizar uma visão de gerencia-
mento de rede totalmente autônomo (KHAN et al., 2018).

MOTIVAÇÃO
Há muitos anos, o uso do protocolo SNMP tem sido usado para gerenci-
amento de dispositivos. Embora o SNMP tenha tido êxito em atividades de ge-
renciamento de dispositivos de rede, ele falha em atividades de configuração e
alterações da rede.
Com o passar do tempo, fica claro que atividades envolvendo SNMP se
tornaram insustentáveis para gerenciar de forma adequada a enorme quantidade
de dispositivos e tecnologias emergentes.
A arquitetura SDN oferece um grande passo para o uso definitivo da au-
tomação de rede, permitindo que as equipes de rede gerenciem com mais efici-
ência e flexibilidade, separando o plano de controle e o plano de encaminha-
mento.
Dessa maneira, o plano de controle se torna diretamente programável tor-
nando a inteligência de rede logicamente centralizada.
Hoje, é amplamente reconhecido que a automação de redes é crucial para
a eficácia e o sucesso das futuras gerações da operação de redes.
A automação pode melhorar a gerência de redes permitindo a adaptabili-
dade, a disponibilidade, a confiabilidade da operação de redes, poupando os
administradores e analistas de rede de atividades diárias e demoradas.

6
 Com isso, permite que os engenheiros e administradores de redes con-
centrem suas energias em outros níveis de serviços de redes.
Alguns conceitos como sensibilidade a contexto ou aprendizagem de má-
quina (Machine Learning, ML), podem impulsionar a automação de redes, tor-
nando-a mais adaptativa. No entanto, técnicas de ML podem implicar em um
peso maior quanto à técnicas de complexidade computacional envolvida.
O que não justificaria o uso de uma técnica tão complexa para resolver
um problema simples de rede. Por outro lado, a sensibilidade a contexto em
uma rede de computadores pode adicionar a adaptabilidade necessária para o
gerenciamento de dispositivos de rede para resolver problemas simples e corri-
queiros de uma rede de computadores.
A programabilidade oferecida pela arquitetura SDN permite a coleta de
alguns dados diretamente do plano de encaminhamento e com isso, fica possível
estabelecer regras e políticas simples para caracterizar uma situação contextual
(ex. congestionamento de rede).
Em geral, tais regras simples devem ser suficientes para lidar com proble-
mas diários ou simples (queda de enlace ou congestionamento), para que então
técnicas mais complexas, como ML, possam ser reservadas para um uso mais
adequado como classificação de pacotes e melhorar a detecção de ataques de
rede.
A Rede Nacional de Ensino e Pesquisa (RNP) possui algumas pesquisas
no campo de SDN envolvendo também sua própria infraestrutura (RNP, 2017),
(RNP, 2016), (RNP, 2015).
A RNP possui vários projetos de infraestruturas de rede para atender a
instituições de ensino, pesquisa e saúde.

REDES DEFINIDAS POR SOFTWARE

Nas últimas décadas novas tecnologias como IoT, BlockChain, Inteligên-
cia Artificial, Computação em Nuvem (Cloud Computing) e computação móvel
vem modelando e transformando a maneira em que se troca informações.
Com isso, surgiu a necessidade de inovar em tecnologias de redes. Rede
de computadores tradicionais consistem em várias redes interconectadas entre

7
si possuindo vários tipos de dispositivos desde switches e roteadores até mid-
dleboxes como firewalls, balanceadores de carga (load balancers) e sistemas de
detecção de intrusos (Intrusion Detection System, IDS).
Os roteadores e switches executam protocolos complexos e normalmente
são fechados e proprietários. Operadores e administradores de rede constante-
mente implementam políticas cada vez mais sofisticadas e tarefas complexas
com um conjunto limitado e altamente restrito de comandos de configuração de
dispositivos de baixo nível utilizando linhas de comandos (Command Line Inter-
face, CLI).
Sendo assim, redes tradicionais são centradas no hardware impedindo a
inovação e pesquisas na área de redes e restringindo a inserção de novos pro-
tocolos .
A SDN, vêm propondo uma mudança em relação às limitações da arqui-
tetura tradicional.
Como mudança, a SDN propõe a separação do plano de controle e do
plano de encaminhamento ou plano de dados. Este tipo de separação permite a
programabilidade direta do plano de controle.
Consolidando esta separação, o plano de controle é representado por um
único software um controlador capaz de administrar múltiplos dispositivos no
plano de dados (switches, roteadores).
O controlador SDN assume o papel de Sistema Operacional de Rede
(Network Operating System, NOS).
Dispositivos localizados no plano de dados são representados por swit-
ches e consistem de uma ou várias tabelas de encaminhamento que são preen-
chidas pela a ação do controlador SDN (KIM; FEAMSTER, 2013), (FEAMSTER;
REXFORD; ZEGURA, 2014), (MASOUDI; GHAFFARI, 2016), (COX et al., 2017).
A comunicação entre os plano de controle e o plano de dados é estabe-
lecida através de interfaces.
Essas interfaces são divididas em: Interface Sul (SouthBound Interface,
SBI), Interface Norte (NorthBound Interface, NBI) e em algumas abordagens
para controladores distribuídos, EastBound Interface e WestBound Interface
(LATIF et al., 2019).
A Figura 2 ilustra as 3 camadas que compõe uma arquitetura SDN, sendo
a camada de infraestrutura (Infrastructure Layer) a responsável por representar

8
o plano de dados e a camada de controle (Control Layer), a responsável pelo
plano de controle ligadas por uma interface sul (Control Data Plane Interface).
A camada de aplicação (Application Layer) é responsável por representar
aplicações SDN ou simples aplicações que se comunicam com o controlador
SDN (LATIF et al., 2019).

A separação do plano de controle do plano de dados levantam questões

que podem trazer benefícios. A seguir, seguem as principais características de
um modelo SDN (COX et al., 2017), (FEAMSTER; REXFORD; ZEGURA, 2014):
• Permite a separação do plano de controle (Control Layer) e o plano de
dados (Infrastructure Layer).
• Permite o uso de um protocolo padronizado para troca de informações
entre o controlador e os dispositivos de rede.
• Fornecer programabilidade de rede através de uma Interface de Progra-
mação de Aplicativos (Application Programming Interface, API) moderna e ex-
tensível.
• Redução de despesas de capital e operacional (CAPEX e OPEX).

9
 Controlador SDN
Redes definidas por software foram um dos tópicos mais discutidos nas
ultimas décadas, trazendo novas visões e recursos permitindo resolver muitos
problemas herdados da arquitetura de rede tradicional.
Enquanto em redes tradicionais os planos de controle e o plano de dados
residem em um mesmo switch, em uma rede SDN o plano de controle é movido
para fora do switch.
O controlador é um elemento de rede que faz parte da arquitetura SDN
que pode fornecer uma interface programável para rede. Ele pode ser usado
para implementação de novas atividade de gerenciamento, roteamento, dentre
outras funcionalidades (SHALIMOV et al., 2013), (NUNES et al., 2014a).
O controlador é um NOS que visa a oferecer um controle centralizado com
interface aberta e API bem definida para proporcionar um ambiente ideal para
desenvolvimento de aplicações SDN.
Aplicações SDN são construídas utilizando o ambiente fornecido por con-
troladores.
Toda inteligência da rede está alocada no controlador que, por conta
disto, possui uma visão geral da rede.
Deste modo, o controlador pode aplicar políticas de decisão e controle
para todos os dispositivos de uma rede SDN. Alguns dos principais controladores
podem ser vistos no quadro 1 (GÖRANSSON; BLACK; CULVER, 2017b), (NU-
NES et al., 2014a).

10
 Os controladores SDN apesar de fornecerem uma forma inovadora para
gerenciar dispositivos, seu modelo de implementação centralizado para tratar
tais atividades, pode afetar em sua escalabilidade.
Dependendo da extensão da rede, esse fator pode afetar seu desempe-
nho. O controlador por si só representa um único ponto vulnerável de falha para
toda a rede e por isso, novos modelos de implementação podem ser necessá-
rios.
Apesar de protocolos como o OpenFlow especificarem que apenas swit-
ches deve ser controlados por controladores, a arquitetura SDN permite um mo-
delo de implantação distribuída de controladores.
Embora a comunicação controlador-controlador não seja definida pelo
OpenFlow, ela é necessária para qualquer tipo de distribuição ou redundância.
Embora o OpenFlow não aceite conexões do tipo “controlador-controla-
dor”, ele permite que vários controladores se conectem a um único switch, pos-
sibilitando que controladores de backup assumam o controle em caso de falhas
(NUNES et al., 2014a).
A dinâmica de funcionamento do controlador Ryu é caracterizada pelo
padrão de programação orientada a eventos. Os eventos podem ser gerados por
acontecimentos na rede e capturados por decorators em Python. Alguns eventos
podem ser gerados por classes dentro do código do controlador que por sinal
podem gerar outros eventos.
O controlador Ryu possui classes responsáveis por enviar mensagens de
requisições (Request) e classes para tratar as respostas (Reply). As mensagens
de requisições são enviadas através das classes específicas para este tipo ati-
vidade.
Em seguida, esses eventos gerados por classes de requisições são cap-
turados por decorators definidos pela classe @set_ev_cls e especificando como
parâmetro uma classe de resposta (Reply).
Estas respostas por sinal retornam mensagens de contadores estatísti-
cos, status de porta entre outros valores, seguindo assim um desencadeamento
de funções e métodos (RYU, 2014).
A programação orientada a eventos é caracterizada por um laço de repe-
tição responsável por gerar eventos que por sinal podem acionar eventos secun-
dários.

11
 O controlador Ryu possui várias classes de eventos bem definidas refe-
rentes a eventos específicos. Cada classe é responsável por um tipo de evento
mensagem que pode ser gerada ou capturada por decorators. A classe base
responsável pelas mensagens de eventos é EventOFPMsgBase.
Uma aplicação SDN pode utilizar OpenFlow para ter uma ação reativa ou
proativa.
A forma reativa de aplicações SDN recebe pacotes encaminhados pelos
dispositivos de rede para o componete Packet Listener dentro do controlador
geralmente representado pela função packet_in em python.
Em abordagens reativas a aplicação envia instruções de volta ao switch
que prescreve como lidar com esse pacote.
Em aplicações reativas a comunicação entre o switch OpenFlow e o con-
trolador normalmente será dimensionada com novos pacotes injetados na rede.
Na forma de aplicação proativa se difere por:
(a) Definir o comportamento de encaminhamento a priori, em vez de es-
perar que os pacotes sejam encaminhados;
(b) pouco dinamismo é alcançado ao responder eventos externos em re-
lação a aplicações reativas; e
(c) permite a escrita de aplicações que residem externo ao controlador
podendo ser programada em qualquer linguagem de programação desde que
utilizem APIs REST do controlador (GÖRANSSON; BLACK; CULVER, 2017a).
De acordo com Lee e Shin (LEE; SHIN, 2018), a zero-touch network
(KOLEY, 2016) é uma rede que minimiza o tempo de inatividade do serviço e os
custos operacionais, graças à remoção da intervenção humana.
A rede é construída usando tecnologias de nuvem e SDN (ROSSEM et
al., 2017).
Para Samba (SAMBA, 2018), é enfatizado como o gerenciamento de rede
é importante ao introduzir uma nova estrutura para gerenciar arquiteturas SDN,
onde foi proposto usar módulos específicos definidos nas funções alocadas no
controlador.
Tais funções podem fazer parte da própria API do controlador para facilitar
o gerenciamento do mesmo. No entanto, foi informado que mesmo que o con-

12
trolador possa desempenhar o papel de gerente, essa ação poderá sobrecar-
regá-lo, pois esse mesmo controlador já está encarregado de administrar todos
os serviços de rede.
Da mesma forma, é mencionado que existem áreas ativas de pesquisas
envolvendo a separação do gerenciamento SDN do controlador.
Para Megyesi (MEGYESI et al., 2017), a arquitetura SDN já permite a ex-
tração de métricas diretamente da rede por meio de parâmetros de largura de
banda, perda de pacotes e atraso.
No entanto, destaca-se o desafio de calcular a largura de banda disponí-
vel em ambientes dinâmicos.
O artigo utiliza o Mininet como emulador para propor o uso de técnicas
passivas para estimar a medição do ABW com base nas mensagens da API
northbound do controlador, para então descobrir a topologia e monitorar os links
pela extensão do protocolo OpenFlow.
Eles consideraram apenas expandir a proposta usando a funcionalidade
do OpenFlows 1.3, além de restringir os testes aos controladores OpenDayLight,
ONOS e FloodLight. Nesta pesquisa, não é feita uma abordagem adaptativa para
fazer com que a rede reaja a determinada sobrecarga de tráfego.
Martini et al. (2015) apresentaram um Controlador SDN baseado em ser-
viço, explorando os recursos SDN e NFV para executar a distribuição de dados
com reconhecimento de contexto (entrega diferenciada), criando redes de ca-
deias de serviço.
Eles realizaram a composição dinâmica dos serviços por meio das fun-
ções virtuais e a abordagem trouxe vantagens em termos de escalabilidade. Po-
rém, esta pesquisa se limita à versão 1.0 do OpenFlow. Do mesmo modo, como
em (LANGE et al., 2018), testou-se um sistema de gerenciamento de rede
(NMS), no qual faziam solicitações constantes ao controlador ONOS para teste
de desempenho.
Para isso, eles testaram e ampliaram três técnicas de interação com o
controlador usando a interface REST. Foi testada a capacidade de receber e
usar medições com base no gerenciamento de rede e na largura de banda dos
links e no consumo da largura de banda em fluxos individuais.

13
 A topologia do experimento usada no Mininet demonstra semelhança com
a desta pesquisa, no entanto, o experimento se resume à utilização e avaliação
de desempenho de 3 versões do controlador ONOS (Java).
Também baseado em SDN, Ghannami e Shao (2016) analisam um ambi-
ente de rede de caminhos múltiplos, concentrando-se no processo de recupera-
ção rápida de falhas usando o OpenFlow. A proposta visa monitorar caminhos
de rede, identificar rapidamente falhas e redirecionar o tráfego para o melhor
caminho alternativo utilizando o controlador SDN FloodLight (Java).
Na proposta, eles usaram as tabelas de grupo do OpenFlow para enviar
os fluxos, utilizando outra rota em caso de falha nos links. Para o caso de falhas,
foi utilizado o protocolo para detecção de encaminhamento bidirecional para uti-
lizar tanto o link principal quanto o de backup.
O artigo mencionou um interesse futuro em investigar situações de cená-
rios de congestionamento de rede.
Em (SILVA, 2016), é proposto um serviço de monitoramento de tráfego
utilizando arquitetura SDN com o objetivo de fornecer uma visão do tráfego em
três níveis de granularidade.
Foi proposto também um serviço de balanceamento de carga utilizando
os algoritmos Round-Robin e o Bandwidth-Based utilizando o controlador Open-
DayLight (Java).
A topologia em anel em um dos cenários propostos se assemelha ao
desta pesquisa. Porém, o serviço de monitoramento apenas apresenta os resul-
tados. O balanceamento não é feito de forma automática, deste modo, não foi
feita qualquer gerência adaptativa baseada nas informações contextuais de
banda.
Em (ZHOU et al., 2019), foi proposto um modelo adaptativo de coleta de
dados baseado 45 em vários módulos em uma rede definida por software.
Esta proposta visa o modelo de classificação 5W + 1H com o objetivo de
responder as perguntas: quais dados, onde, como e quando coletá-los por meio
de avaliação do status da rede.
O sistema seleciona adaptativamente os nós de coleta adequados com o
objetivo de reduzir a redundância dos dados, ao mesmo tempo que garante a
percepção completa do tráfego.

14
 Durante a coleta, emprega a geração dinâmica de probabilidade e amos-
tragem para determinar as regras de amostragens para reduzir ainda mais a re-
dundância dos dados.
Porém, este modelo foi implementado para garantir a precisão da detec-
ção de ataques de negação distribuída de serviço (Distributed Deny of Service –
DDoS).

NFV
Conceitos fundamentais ao entendimento do trabalho proposto. Primeiro,
apresenta-se o paradigma de virtualização de funções de rede, a arquitetura
NFV e a definição de encadeamento de funções de serviço.
Em seguida, aborda-se aspectos importantes de visualização de informa-
ções utilizados na solução proposta. Por fim, expõe-se uma síntese do estado-
da-arte no que diz respeito à visualização de informações aplicada à área de
gerência de redes e serviços.

Virtualização de Funções de Rede

Tradicionalmente, funções de rede como firewall, load balancer e Network
Address Translation (NAT) são comercializadas por fabricantes de dispositivos
de rede, em equipamentos proprietários. Via de regra, cada uma dessas funções
é implementada em um dispositivo dedicado.
Esse modelo de implantação resulta em uma rede em que o posiciona-
mento das funções é definido em razão das necessidades de cabeamento, com
pouca margem à adaptação da infraestrutura a flutuações dinâmicas de tráfego.
Nesse contexto, a implantação de encadeamentos de funções de serviço (Ser-
vice Functions Chaining, SFCs) torna-se uma tarefa particularmente desafiadora
e custosa (OPEX e CAPEX).
Diante desse cenário, em outubro de 2012, o European Telecommunica-
tions Standards Institute (ETSI) definiu o paradigma de Virtualização de Funções
de Rede (NFV).
O principal objetivo desse paradigma é desacoplar as funções de rede
dos equipamentos físicos, tornando-as instâncias de software que podem ser
executadas virtualmente em hardware de prateleira.

15
 Com isso, passa a ser possível implantar e (re)posicionar funções sob
demanda, bem como encadeá-las por software (potencialmente via Redes Defi-
nidas por Software, VLANs, MPLS ou outra tecnologia). Retomando os benefí-
cios potenciais de NFV, em adição a custos reduzidos de aquisição e operação,
destacam-se três.
O primeiro consiste em uma maior escalabilidade, posto que é possível
instanciar funções de rede remotamente à medida que a demanda pelos seus
serviços aumenta.
O segundo é a possibilidade de realizar migrações espaciais das funções,
possibilitando uma maior flexibilidade a flutuações de tráfego com uma baixa
interrupção de serviços, visto que pode-se reduzir o tempo de implantação e
configuração de VNFs.
Por fim, abre-se espaço para um mercado mais aberto, em que VNFs de
código aberto ou fechado podem ser comercializadas através de lojas virtuais.
A seguir, apresenta-se a arquitetura NFV definida no âmbito dos esforços
de padronização que vêm sendo realizados pelo ETSI.

Arquitetura NFV
A arquitetura NFV proposta pelo ETSI é composta por três componentes
principais: Infraestrutura de Virtualização de Funções de Rede (Network Func-
tion Virtualization Infrastructure, NFVI), Funções de Rede Virtualizadas e Gerên-
cia e Orquestração NFV (NFV Management and Orchestration, NFV MANO). Es-
ses componentes são ilustrados na Figura 2.1.

16
 Cloud
Segundo especialistas na área de tecnologia, importantes mudanças tec-
nológicas surgem a cada 20 anos, e uma delas é a Cloud Computing ou Com-
putação em Nuvem. Cada vez mais dominante no mundo de Tecnologia da In-
formação (TI), esta nova tecnologia vem para desafiar o setor de telecomunica-
ções e surge em meio a um mantra formado pelas organizações da área que
visam principalmente à redução de custos.
Esta arquitetura em nuvem refere-se como um modelo no qual a compu-
tação (processamento, armazenamento e softwares) está em algum lugar da
rede e é acessada remotamente, por exemplo: uma empresa ou pessoa não
precisar ter mais nenhum software instalado em sua máquina, pois o acesso a
todo e qualquer recurso será via internet (nuvem), num sistema operacional a
partir de qualquer computador e em qualquer lugar, pode-se ter acesso a infor-
mações, arquivos e programas num sistema único, independente de plataforma.

17
 Por esta constante evolução, a Cloud Computing nos obriga a estar cons-
tantemente em atenção à suas mudanças, ascensões e possíveis declínios, se-
jam os mesmos tecnológicos, ou apenas conceituais.
No Brasil a tecnologia de computação em nuvem está fora da realidade
na maioria das organizações, pois a infraestrutura de telecomunicações do país
é deficiente.
A questão de segurança é de extrema importância para a Cloud Compu-
ting se tornar viável e é considerada prioridade na implementação deste serviço.
Mas como esta virtualização permitirá que haja segurança em grande es-
cala e significativa redução de custos para as organizações? Este é o cenário da
Cloud Computing e o seu crescimento será muito mais rápido e intenso que os
analistas dizem e mesmo que muitos dos atores atuais da indústria de TI gosta-
riam que fosse.
Cloud Computing na visão de segurança é colocar em questão a essência
desta tão recente tecnologia.
O conceito, apesar de simples, tem provocado revoluções e se tornado
cada vez mais conhecido devido à popularização da banda larga. Depois de uma
era tecnológica caracterizada pela ascensão do computador pessoal (PC), esta-
mos vendo o ressurgimento da centralização.
Esta centralização e virtualização de arquiteturas através de redes que
antes eram acessadas localmente na própria empresa por seus usuários torna o
quesito segurança como prioritário e fundamental para que a Computação em
Nuvem continue sendo a plataforma do futuro pela qual empresas de todo o
mundo possam aderir, deixando de lado seus servidores e sistemas, reduzindo
custos e gastos com manutenção.
A empresa ou organização precisa confiar que seu trabalho e seus dados
estarão tão seguros na nuvem quanto em seu próprio computador ou servidor,
para isso este momento de auge em Cloud Computing é a melhor ocasião para
se estudar e pôr em prática modelos de segurança robustos que atendam a ne-
cessidade e tragam mais confiança a estas organizações.
No ano de 1981 a IBM lançou nos Estados Unidos o seu primeiro compu-
tador pessoal. Mesmo possuindo configuração inúmeras vezes inferiores aos
computadores domésticos atuais, o IBM PC 5150 iniciou a mudança do modelo
computacional da época que era baseado em mainframes. Neste antigo modelo,

18
um computador central trabalhava atendendo às solicitações de vários terminais,
que tinham como finalidade efetuar a conexão entre dispositivos de entrada e
saída do cliente e o servidor.
Todo o processamento e armazenamento de dados era efetuado remota-
mente. Os computadores pessoais iniciaram um novo modelo descentralizado,
onde cada estação possui seu próprio poder computacional e trabalha de forma
independente. A evolução no hardware e software dos computadores pessoais
atingiu patamares quase inimagináveis há algumas décadas.
Enquanto a versão inicial do IBM PC 5150 possuía um processador Intel
8088 de 4,77 MHz, 16 KB de memória RAM e utilizava fitas cassete como mídia
de armazenamento, o smartphone Nexus S, anunciado pelo Google, possui pro-
cessador de 1GHz, 512MB de memória RAM e 16GB de armazenamento in-
terno, pesando apenas 129 gramas.
Com o crescimento da demanda, os preços dos microcomputadores caí-
ram de maneira acentuada, permitindo o aumento da presença em micro e pe-
quenas empresas e residências de diversas classes sociais. (ALECRIM, 2008)
A popularização do acesso à Internet começou a reconectar os computadores.
A evolução constante da tecnologia computacional e das telecomunica-
ções está fazendo com que o acesso à internet se torne cada vez mais amplo e
cada vez mais rápido.
Habitualmente, utilizamos aplicações instaladas em nossos próprios com-
putadores, assim como armazenamos arquivos e dados dos mais variados tipos
nos mesmos.
No ambiente corporativo, este modelo é um pouco diferente, já que nele
é muito mais fácil encontrar aplicações disponíveis em servidores e que podem
ser acessadas por qualquer terminal com níveis de acesso através de uma rede.
Esse cenário cria a situação perfeita para a popularização da Cloud Com-
puting, uma tecnologia recente que faz com que muitos aplicativos, assim como
arquivos e outros dados relacionados, não precisam mais estar instalados ou
armazenados no computador do usuário.
Em 2007, Eric Schmidt, então CEO do Google, utilizou pela primeira vez
o termo Cloud Computing (computação em nuvem) para referenciar a maneira
de como a empresa gerenciava seus Data Centers.

19
 A palavra cloud (nuvem) pode ser definida como toda a estrutura de ser-
vidores presentes na Internet que não só armazenam, mas também processam
informações e fornecem diversos serviços, como backup e até utilização de um
servidor virtual. “Embora possa parecer revolucionário, o conceito de Computa-
ção em Nuvem é um passo evolutivo na eterna busca pelo compartilhamento e
consequentemente maior aproveitamento dos recursos computacionais”. (TAU-
RION, 2009, p. 24)
Esta tecnologia pode ser vista por muitos como algo não tão complexo e
com recursos semelhantes aos que já habitualmente são utilizados, como é o
caso de alguns profissionais de TI que citam a Cloud Computing como uma sim-
ples arquitetura em nuvem repleta de servidores se comunicando entre si com o
foco inicial em hardware.
Porém, este modelo de virtualização vai muito além disso, e é disso que
se refere o autor ao dizer que “a computação em nuvem sinaliza um novo para-
digma computacional transformando toda a indústria de computação, como a
energia elétrica transformou a nossa sociedade” (TAURION, 2009, p. 12).
Em alguns aspectos, o mercado de Cloud Computing ganhou corpo em
2008 quando empresas como a Amazon, IBM, Google, Microsoft e outras deze-
nas de grandes organizações tecnológicas lançaram produtos e serviços on-de-
mand. Por outro lado, há quem veja esta tecnologia em nuvem como uma evo-
lução natural da convergência de várias tecnologias e conceitos, como o próprio
Grid, mais o conceito Utility Computing (que são serviços computacionais comer-
cializados como os serviços utilitários, como energia elétrica), virtualização e au-
tomatic computing, que são sistemas capazes de auto gerenciar e corrigir pro-
blemas e falhas, acrescidos de tecnologias e tendências como Web 2.0, SOA e
o modelo de Software como Serviço (SaaS). A Figura 1 mostra o conceito do
modelo de Cloud Computing de acordo com as grandes empresas do ramo.

20
 Segundo Laudon e Laudon (p.145, 1999), no atual Século XXI, os gigan-
tes da comunicação estão envolvidos na maior competição empresarial de todos
os tempos, onde o principal objetivo é construir e controlar com segurança a
vasta teia de redes e serviços eletrônicos que fornecem informação, educação e
serviços a empresas e residências de todo o mundo.
A empresa Google como exemplo vem, ao longo do tempo, se desta-
cando no que diz respeito a plataformas de Cloud Computing.
Uma arquitetura chamada “Google Docs”, permite que seus usuários pos-
sam criar planilhas, editar textos e elaborar apresentações de slides pela inter-
net, sem necessidade de ter softwares instalados em seus computadores, as
informações inseridas e alteradas ficam ali gravadas e distribuídas em inúmeros
servidores da empresa. A praticidade é tanta que o acesso a plataforma se dá
através de um navegador de internet qualquer onde basta o acesso do usuário
a página do Google Docs para começar a trabalhar, não importando o computa-
dor utilizado nem o sistema operacional instalado.
A plataforma vai muito além disso e a sua capacidade de integração com
outros serviços e plataformas do próprio Google torna possível criar uma estru-
tura parruda e organizada de trabalhar com documentos tanto pessoais quanto
corporativos. Outro desafio recente do Google, é o seu sistema operacional “nas
nuvens” Chrome OS.

21
 A REALIDADE BRASILEIRA
A Cloud Computing no Brasil é vista ainda como fora da realidade para as
grandes empresas que investem em tecnologia. Os primeiros testes deste mo-
delo foram implementados em 2007, sendo que somente em 2008 começou a
ser oferecido e comercializado.
O grande problema enfrentado atualmente refere-se no que diz respeito
a como este serviço é oferecido e distribuído. Hoje, a computação em nuvem
brasileira muito é tratada apenas como hospedagem, ou seja, você paga uma
mensalidade por um pacote que às vezes pode ser personalizado, porém com
funcionalidades ainda restritas e um valor um pouco excessivo.
Para Corrêa (2010), diferentemente da visão brasileira, o modelo estran-
geiro de Cloud Computing tem desempenho dinâmico, ou seja, se você por
acaso tiver uma demanda inesperada na sua aplicação, em 10 minutos você terá
quantos 24 servidores quiser à disposição e funcionando para suportar a nova
demanda.
No modelo brasileiro, você abre um chamado e aguarda pacientemente
ou liga na central de atendimento reclamando virtualmente com o primeiro aten-
dente e implorando por uma solução mais rápida.
A realidade é que o Brasil é um país com uma imensa capacidade tecno-
lógica, basta organização e desenvolvimento para que possa sair desta estaca
inicial e assim comercializar a verdadeira Cloud Computing

Blockchain
Blockchain foi o termo empregado para um sistema de blocos encadea-
dos criptograficamente de maneira segura.
Esta tecnologia pode ser considerada a base para o funcionamento do
Bitcoin e outras criptomoedas existentes atualmente. No contexto do protocolo
do Bitcoin, a utilização de Blockchain tem como objetivo final propor uma rede
peer-to-peer de pagamentos onde não fosse necessária a validação de transa-
ções por uma entidade confiável e centralizada .
Desta forma, as validações deixam de ser feitas a partir de confiança e
são substituídas por provas criptográficas que possibilitam a transações entre

22
duas partes sem a necessidade de que uma terceira parte confiável esteja en-
volvida.

Funcionamento de sistemas Blockchain

Apesar de muitas vezes ser associado puramente à criptomoeda Bitcoin,
o sistema de Blockchain pode ser utilizado em diversas áreas de aplicação com
algumas variações em sua implementação.
Como o protocolo do Bitcoin foi desenvolvido com o intuito de criar uma
rede de pagamentos descentralizados, há algumas características associadas a
ele que não são imprescindíveis para sistemas Blockchain, entretanto foram adi-
cionadas para aumentar a robustez da rede monetária.

Identidade e Privacidade
Os usuários da rede Blockchain são definidos por um par de chaves crip-
tográficas: uma pública e uma privada. A chave pública é a que representa a
carteira do usuário, enquanto a chave privada é a que possibilita a assinatura de
transações desta carteira para uma carteira nova.
O uso dessas chaves é baseado no conceito de criptografia assimétrica,
onde a chave privada de um usuário pode ser utilizada para assinar digitalmente
algum dado - que pode ser facilmente verificado com chave pública - ou decifrar
informações que foram cifradas com a chave pública do usuário .
Desta forma, a chave privada age como uma identidade do usuário de
modo que qualquer dispositivo que possua a chave pública associada ao usuário
pode verificar as assinaturas geradas por ele e pode cifrar informações para ele.
Do ponto de vista de identidade e privacidade, usuários são anônimos aos
olhos do sistema, haja vista que um novo par de chaves pode ser criado a qual-
quer momento para qualquer usuário.
Entretanto, como todas as transações da rede podem ser consultadas, ao
conhecer a chave pública de um usuário, é possível visualizar todo o histórico
de transações registradas daquela carteira específica.

23
 Transações de informações
Antes de explicar como funcionam as transações, é importante definir o
que são as moedas que serão transacionadas. Uma moeda pode ser definida
como um conjunto de informações digitalmente assinadas por um usuário com
sua chave privada representando que este é o dono daquela moeda no momento
de sua criação.
No caso do Bitcoin, esta informação representa uma quantidade. As tran-
sações são definidas como uma cadeia de assinaturas digitais. Cada dono de
moeda a transmite para outro usuário através da assinatura digital do hash da
transação anterior desta moeda e da chave pública do usuário para quem a mo-
eda está sendo enviada (Figura 3.1).

Qualquer usuário com acesso à Internet pode verificar as assinaturas pre-

sentes na transação para validar se a moeda foi de fato transferida. Especifica-
mente para o caso de dinheiro digital, como em criptomoedas, é impraticável que
as transações sejam feitas através da menor unidade de moeda para possibilitar
a maleabilidade nos valores transferidos. Desta forma, as transações.

24
 FUNCIONAMENTO DE SISTEMAS
BLOCKCHAIN têm como entrada a quantidade total de moedas de um
usuário e como saída dois valores: a quantidade de moedas que serão transfe-
ridas e a quantidade de moedas que serão retornadas para o usuário que está
realizando a transação. Por fim, para realizar uma transação, o usuário deve
enviá-la para a rede para que esta seja propagada para todos os nós que deve-
rão validar e adicionar a transação à cadeia de blocos.
A tecnologia de corrente de blocos é originalmente proposta como uma
estrutura de dados distribuída e pública para processar transações de moedas
digitais entre usuários sem a necessidade de uma autoridade centralizada .
Hoje, as tecnologias de corrente de blocos de primeira geração, baseadas
no Bitcoin , e de segunda geração, baseadas nos contratos inteligentes do Ethe-
reum já revolucionaram o mundo atual ao criar uma camada de confiança para
transferências seguras de ativos e execução segura de contratos.
Esta tecnologia funciona como um livro-razão distribuído (Distributed Le-
dger Technology – DLT) envolvendo múltiplos participantes independentes e co-
nectados através de comunicações par-a-par (peer-to-peer – P2P).
A corrente de blocos em si provê como principais características
i) a desintermediação, através do uso de protocolos de con-
senso que eliminam a necessidade de uma autoridade centralizada;
ii) a imutabilidade dos dados registrados, através de técnicas
criptográficas de garantia de integridade e replicação dos dados; e
iii) o não-repúdio das transações registradas na corrente de
blocos, através do uso de assinaturas e criptografia de chaves assi-
métricas.

As diversas aplicações de correntes de blocos em criptomoedas e siste-

mas financeiros já atingiram um capital de mercado global de mais de 800 bi-
lhões de dólares em 2018 , que corresponde a metade do PIB brasileiro em 2018
[4].
No entanto, a corrente de blocos pode ser utilizada na Internet do Futuro
para prover confiança distribuída mesmo quando não há troca de moedas ou
valores.

25
 A Internet do Futuro interconectará bilhões de dispositivos através de sis-
temas construídos a partir de milhares de serviços distribuídos.
Aglomerados com um enorme número de máquinas físicas e virtuais ma-
nipularão grandes quantidades de dados gerados a partir de inúmeros sensores
e atuadores da Internet das Coisas (Internet of Things - IoT), gerando um volume
de informações jamais visto.
A Internet será constituída de fatias de rede (network slices) adaptadas a
cada tipo de aplicação, que serão criadas, alteradas e destruídas de maneira ágil
e escalável para oferecer alta disponibilidade com baixo custo de operação.
Esta Internet de nova geração, 1 baseada na tecnologia de Virtualização
de Funções de Rede (Network Function Virtualization - NFV) e Redes Definidas
por Software (Software-Defined Networking - SDN), será a essência das redes
móveis de quinta geração (5G) e das cidades inteligentes (smart cities).
No novo paradigma 5G, um dos desafios fundamentais de pesquisa é ga-
rantir o provisionamento seguro de serviços em um ambiente de nuvem onde
múltiplos inquilinos e usuários sem confiança mútua compartilham recursos com-
putacionais. Uma forma de garantir a confiança de forma distribuída e permitir a
análise forense para identificação dos responsáveis pelos problemas é através
do uso da tecnologia de corrente de blocos (blockchain).
A corrente de blocos, conhecida por suas aplicações em criptomoedas
como o Bitcoin e Ethereum , é uma tecnologia disruptiva que deve revolucionar
não somente a tecnologia da informação como também a economia e a socie-
dade, permitindo uma maior descentralização do mundo atual.
Pode-se prever um futuro no qual a computação e a Internet associadas
à tecnologia de livros-razão distribuídos permitirão uma computação planetária
distribuída que executa aplicações e contratos inteligentes através de um con-
senso entre computadores sem nenhuma entidade intermediária.
Esta confiança distribuída sem intermediários provida pela corrente de
blocos permitirá múltiplas ofertas de funções virtualizadas de rede e seleção cri-
teriosa entre diversos provedores de infraestrutura, produzindo uma concorrên-
cia sem precedentes na área de telecomunicações.

26
 Em especial, as correntes de blocos atenderão a diversas aplicações,
desde redes veiculares tolerantes a atraso até serviços críticos como saúde ele-
trônica (e-Health), cidades inteligentes (smart cities) e redes elétricas inteligen-
tes (smart grids).
Por estes motivos, as tecnologias baseadas em corrente de blocos são
consideradas tanto pela indústria como pela academia como a tecnologia mais
disruptiva dos últimos tempos .
A inovação fundamental das correntes de blocos é prover, de forma des-
centralizada e sem intermediários, confiança entre um grupo de participantes.
Para isso, o sistema deve ser capaz de obter consenso1 entre os partici-
pantes para incorporar novos blocos à corrente.
A proposta do Bitcoin, a primeira criptomoeda proposta por Satoshi Naka-
moto em 2008, resolve o problema do consenso através da prova de trabalho
(Proof-of-Work – PoW), um protocolo baseado em competição entre os partici-
pantes para definir o líder da rodada de consenso.
Todos os participantes tentam encontrar a solução para um desafio com-
putacional baseado em funções resumo (hash) e o primeiro participante que re-
solver o desafio adquire o direito de adicionar o próximo bloco à corrente.
No entanto, o crescimento do Bitcoin evidencia o Consenso é um tipo de
acordo produzido por consentimento entre todos os membros de um grupo.
O consenso se estabelece quando dois ou mais membros chegam a um
ponto comum de decisão durante uma negociação.
i) consumo de energia excessivo;
ii) baixa vazão de transações; e
iii) tendência de centralização em participantes com maior po-
der computacional.

A latência de consenso, de aproximadamente uma hora, e a vazão de

transações, de até transações por segundo, consistem em um desafio para
atender às necessidades dos sistemas atuais .
A baixa vazão do Bitcoin fica ainda mais evidente quando se compara
o número de transações por segundo processadas pelas grandes compa-
nhias de cartões de crédito, que chegam a 2.000 transações por segundo em

27
 média e até 56.000 transações em pico, com tempos de resposta da ordem
de segundos .
O processo de mineração da prova de trabalho no Bitcoin gera um
consumo insustentável de energia sem retorno proporcional, atingindo mais
de 70 TWh por ano.
Para se ter uma ideia, esse valor é mais de quatro vezes maior que os
cerca de 15TWh de energia gerada pelas usinas nucleares de Angra.
O gasto energético para processar uma única transação no Bitcoin é
suficiente para abastecer uma residência média brasileira durante três me-
ses.
Em resposta às limitações de desempenho do consenso baseado em
prova de trabalho, diversos protocolos de consenso foram propostos como
alternativas ao protocolo do Bitcoin.
Dentre eles, destacam-se:
i) protocolos alternativos baseados em prova, como a prova
de posse (Proof-of-Stake – PoS);
ii) protocolos baseados em quórum, como os protocolos clás-
sicos tolerantes a falhas de parada (e.g. RAFT e Paxos ) e protocolos
tolerantes a falhas bizantinas (e.g. PBFT [24] e BFT-Smart [25]);
iii) protocolos híbridos, como o Casper FFG [26] e Tendermint
; e protocolos baseados em grafos acíclicos direcionados (Directed
Acyclic Graph – DAG), como o IOTA .

Cada protocolo e cada categoria possui características específicas de de-

sempenho e escalabilidade que devem ser consideradas para cada caso de uso.

Provendo uma Infraestrutura de Software

Fatiada, Isolada e Segura de Funções Virtuais através da Tecnologia de
Corrente de Blocos As redes móveis de próxima geração fornecem um modelo
de conectividade com múltiplos serviços de rede adaptados para atender a de-
manda de cada segmento de cliente.
As redes definidas por software (Software-Defined Networking - SDN) e a
virtualização de funções de rede (Network Function Virtualization - NFV) são as

28
principais tecnologias que utilizam a virtualização para fornecer a capacidade de
programação da rede.
Assim, as tecnologias NFV e SDN criam uma cadeia de funções de rede
(Service Function Chain - SFC) fim-a-fim para fornecer serviços sob demanda e
adaptados a cada aplicação.
Apesar de a associação de NFV e SDN fornecer a agilidade e o baixo
custo desejados pelas telecomunicações, surgem novos desafios de segurança
.
Além disso, o impacto de possíveis ataques aumenta porque os ataques
aos hospedeiros de funções de rede podem comprometer simultaneamente mi-
lhares de usuários .
Portanto, é de grande importância reduzir os possíveis vetores de ataque
a funções virtuais de rede (Virtual Network Functions - VNF) e fornecer um ge-
renciamento de configuração seguro e confiável. Garantir o isolamento entre fa-
tias de rede é essencial para evitar ataques comuns em infraestruturas compar-
tilhadas.
Além disso, os inquilinos de cada fatia compartilham a mesma infraestru-
tura de nuvem, e as cadeias podem envolver funções virtualizadas instanciadas
em domínios de provedores concorrentes.
O ambiente multi-inquilino e multi-domínio aumenta a possibilidade de
ataques dentro da nuvem, ao mesmo tempo que dificulta a responsabilização
dos provedores de serviços quando ocorre uma falha. É necessário garantir que
a cadeia de serviços, formada por uma cadeia de funções virtuais de rede, seja
construída de maneira confiável em um ambiente sem confiança entre os pares.
Em um ambiente multi-inquilino formado por provedores concorrentes, é
vantajoso para um provedor criar uma ataque para prejudicar um concorrente.
Logo, a capacidade de auditoria é obrigatória para identificar uma configuração
de VNF defeituosa ou comprometida, e a tecnologia de corrente de blocos
atende a esta necessidade, pois fornece as características necessárias de não
repúdio e imutabilidade do histórico de configuração de uma função virtual.
Esta dissertação propõe utilizar a tecnologia de corrente de blocos para
registrar, como transações assinadas, todos os comandos que criam, modificam,
configuram, migram ou destroem as funções de rede de cada fatia da rede.

29
 Portanto, todos os problemas de funcionamento da rede podem ser veri-
ficados e um erro pode ser atribuído corretamente a um provedor de serviço em
um ambiente de concorrência, multi-inquilino, e sem confiança.
Fatias de rede suportam requisitos de serviço para atender redes veicu-
lares tolerantes a atraso, internet das coisas (Internet of Things - IoT), indústria
4.0 e serviços críticos como saúde eletrônica (e-Health), cidades inteligentes
(smart cities) e redes elétricas inteligentes (smart grids).
O cenário extraordinariamente diverso requer diferentes correntes de blo-
cos com características específicas adaptadas ao serviço requerido. Por isso,
este artigo propõe atender aos diferentes requisitos de cada fatia de rede através
de diferentes categorias de correntes de blocos.
A estrutura de dados, o protocolo de consenso e o protocolo de comuni-
cação das corrente de blocos são adaptados a cada funcionalidade de fatia de
rede específica.

Fatiamento Seguro de Redes através de Corrente de Blocos

A utilização de corrente de blocos é necessária em ambientes distribuídos
em que os participantes não conseguem chegar a um acordo sobre uma autori-
dade centralizada que governe todos os procedimentos sensíveis de rede.
Em centros de dados virtualizados nos quais vários serviços de nuvem
são orquestrados, a presença de uma VNF mal-intencionada em um serviço
pode afetar toda a cadeia pela qual os pacotes são roteados sem o conheci-
mento do administrador da nuvem.
Além disso, se um invasor tiver acesso ao orquestrador, o registro de ope-
rações pode ser manipulado para ocultar uma ameaça.
O uso de corrente de blocos, apesar de envolver uma quantidade maior
de processamento como um todo, permite gerenciar e atualizar VNFs de forma
distribuída e segura, onde as transações podem ser verificadas localmente por
cada nó com a garantia de não repúdio e integridade.

30
 Modelo de Atacante
O atacante pode se conectar passivamente à rede e capturar trocas de
mensagens ou injetar, reproduzir, filtrar e trocar informações ativamente.
Os ataques podem ter como alvo inquilinos, VNFs, a corrente de blocos
em si e a rede. Ataques à corrente de blocos objetivam impedir que uma transa-
ção ou bloco legítimo sejam adicionados à corrente de blocos.
Para que um ataque à corrente de blocos seja bem-sucedido, o atacante
deve controlar uma parcela significativa da rede para afetar o protocolo de con-
senso. Um protocolo de consenso tolerante a falhas mitiga esse tipo de ataque.
Os ataques que exigem corrupção ou adulteração de transações são im-
possíveis quando todas as transações incluem seu hash assinado correspon-
dente.
Ataques a inquilinos ou VNFs consistem em tentar obter informações de
configuração ou personificar o alvo.
Os ataques de personificação não são possíveis, pois todas as transa-
ções enviadas para a corrente de blocos são assinadas por seus emissores. A
encriptação de informações confidenciais mitiga ataques que buscam obter in-
formações de configuração, nos quais o atacante precisa obter a chave privada
da vítima. Este trabalho não aborda o caso em que um inquilino ou VNF é com-
prometido através de invasão de terminal ou sequestro de chave. A arquitetura
proposta, no entanto, elimina a necessidade de qualquer serviço de escuta ativo
em um VNF, e utiliza terminais em modo somente leitura para mitigar vetores de
ataque. Além 51 disso, a arquitetura proposta permite a auditoria de todas as
transações passadas. Portanto, se um invasor tentar modificar a corrente de blo-
cos usando pares de chaves roubados, a tentativa será registrada. Após a des-
coberta de um incidente, o inquilino ou provedor pode facilmente substituir os
pares de chaves roubados, restabelecendo a segurança e evitando mais danos.

31
 Ataques à rede representam a tentativa de isolar um único inquilino, um
grupo de inquilinos ou um grupo de VNFs da rede, impedindo assim que a rede
execute transações ou leia conteúdo da corrente de blocos.
Esta categoria de ataque contempla ataques clássicos de rede, que po-
dem ser mitigados através do estabelecimento de caminhos redundantes entre
a corrente de blocos e VNFs ou inquilinos.
Este trabalho assume uma rede pública redundante, como a Internet, que
interconecta todos os participantes. A suposição dificulta o isolamento de uma
única entidade se o invasor não estiver em sua rede adjacente. A mitigação com-
pleta de ataques de rede está fora do escopo deste trabalho. A arquitetura pro-
posta foca nos ataques à corrente de blocos e transações antecipadas. No en-
tanto, ao eliminar os serviços de escuta das VNFs, a arquitetura elimina os ata-
ques de negação de serviço da camada de aplicação, que são uma ameaça
comum em ambientes de nuvem compartilhados.

32
 Referências
[1] NAKAMOTO, S. “Bitcoin: A peer-to-peer electronic cash system”.
2008. Disponível em: . Acessado em 31 de agosto de 2019.
[2] WOOD, G. “Ethereum: A secure decentralised generalised transaction
ledger”. 2014. Disponível em: . Acessado em 31 de agosto de 2019.
[3] COIN MARKET. Cryptocurrency Global Charts: Total Market Capitali-
zation. Relatório técnico, Coin Market, 2019. Disponível em: . Acessado em 31
de agosto de 2019.
[4] INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATÍSTICA (IBGE).
“Produto Interno Bruto - PIB”. 2019. Disponível em: . Acessado em 31 de agosto
de 2019.
[5] ZHANG, P., SCHMIDT, D. C., WHITE, J., et al. “Chapter One - Block-
chain Technology Use Cases in Healthcare”. In: Raj, P., Deka, G. C. (Eds.),
Blockchain Technology: Platforms, Tools and Use Cases, v. 111, Advances in
Computers, Elsevier, pp. 1 – 41, 2018. doi: https://doi.org/10.1016/bs. ad-
com.2018.03.006. Disponível em: .
[6] ESPOSITO, C., DE SANTIS, A., TORTORA, G., et al. “Blockchain: A
Panacea for Healthcare Cloud-Based Data Security and Privacy?” IEEE Cloud
Computing, v. 5, n. 1, pp. 31–37, Jan 2018. ISSN: 2325-6095. doi: 10.
1109/MCC.2018.011791712.
[7] XIE, J., TANG, H., HUANG, T., et al. “A Survey of Blockchain Technol-
ogy Applied to Smart Cities: Research Issues and Challenges”, IEEE Communi-
cations Surveys Tutorials, 2019. ISSN: 1553-877X. doi: 10.1109/
COMST.2019.2899617. 70
[8] RAHMAN, M. A., RASHID, M. M., HOSSAIN, M. S., et al. “Blockchain
and IoT-Based Cognitive Edge Framework for Sharing Economy Services in a
Smart City”, IEEE Access, v. 7, pp. 18611–18621, 2019. ISSN: 2169-3536. doi:
10.1109/ACCESS.2019.2896065.
[9] MORA, O. B., RIVERA, R., LARIOS, V. M., et al. “A Use Case in Cy-
bersecurity based in Blockchain to deal with the security and privacy of citizens
and Smart Cities Cyberinfrastructures”. In: 2018 IEEE International Smart Cities
Conference (ISC2), pp. 1–4, Sep. 2018. doi: 10.1109/ISC2.2018. 8656694.
[10] PIERONI, A., SCARPATO, N., DI NUNZIO, L., et al. “Smarter City:
Smart Energy Grid Based on Blockchain Technology”, International Journal on

33
Advanced Science, Engineering and Information Technology, v. 8, n. 1, pp. 298–
306, 2018.
[11] GLASER, F. “Pervasive decentralisation of digital infrastructures: a
framework for blockchain enabled system and use case analysis”. In: 50th Hawaii
International Conference on System Sciences, 2017.
[12] CACHIN, C., VUKOLIĆ, M. “Blockchains Consensus Protocols in the
Wild”, arXiv preprint arXiv:1707.01873, 2017.
[13] XIAO, Y., ZHANG, N., LOU, W., et al. “A Survey of Distributed Con-
sensus Protocols for Blockchain Networks”, CoRR, v. abs/1904.04098, 2019.
Disponível em: .
[14] POPOV, S. “The tangle”. 2016. Disponível em: . Acessado em 31 de
agosto de 2019.
[15] EYAL, I., GENCER, A. E., SIRER, E. G., et al. “Bitcoin-ng: A scalable
blockchain protocol”. In: 13th USENIX Symposium on Networked Systems De-
sign and Implementation (NSDI 16), pp. 45–59, 2016.
[16] BITCOINWIKI. “Bitcoin Scalability”. 2019. Disponível em: . Acessado
em 31 de agosto de 2019.
[17] DIGICONOMIST. “Bitcoin Energy Consumption Index”. 2019. Dispo-
nível em: . Acessado em 31 de agosto de 2019.
[18] ELETROBRAS. Relatórios de Sustentabilidade Socioambiental. Re-
latório técnico, Eletrobras S.A., 2017. Disponível em: . Acessado em 31 de
agosto de 2019.
[19] MINISTÉRIO DE MINAS E ENERGIA. Anuário Estatístico de Energia
Elétrica 2017. Relatório técnico, Ministério de Minas e Energia do Brasil, 2017.
Disponível em: . Acessado em 31 de agosto de 2019.
[20] NXT COMMUNITY. “NXT whitepaper”. 2014. Disponível em: . Aces-
sado em 31 de agosto de 2019.
[21] KING, S., NADAL, S. “PPCoin: Peer-to-peer crypto-currency with
proof-ofstake”, self-published paper, August, v. 19, 2012.
[22] ONGARO, D., OUSTERHOUT, J. “In Search of an Understandable
Consensus Algorithm”. In: 2014 USENIX Annual Technical Conference (USENIX
ATC 14), pp. 305–319, Philadelphia, PA, 2014. USENIX Association. ISBN: 978-
1-931971-10-2.

34
 [23] LAMPORT, L. “The Part-Time Parliament”, ACM Transactions Com-
puter Systems, v. 16, n. 2, pp. 133–169, maio 1998. ISSN: 0734-2071.
[24] CASTRO, M., LISKOV, B. “Practical Byzantine Fault Tolerance”. In:
Proceedings of the Third Symposium on Operating Systems Design and Imple-
mentation, OSDI ’99, pp. 173–186, Berkeley, CA, USA, 1999. USENIX Associa-
tion. ISBN: 1-880446-39-1.
[25] BESSANI, A., SOUSA, J., ALCHIERI, E. “State machine replication
for the masses with BFT-SMaRt”. In: IEEE/IFIP International Conference on De-
pendable Systems and Networks (DSN), 2014.
[26] BUTERIN, V., GRIFFITH, V. “Casper the friendly finality gadget”,
arXiv preprint arXiv:1710.09437, 2017.
[27] KWON, J. “Tendermint: Consensus without mining”. 2014. Disponível
em: . Acessado em 31 de agosto de 2019.
[28] POPOV, S. “The Tangle”, cit. on, p. 131, 2017. Disponível em: . Aces-
sado em 31 de agosto de 2019. 72
[29] REBELLO, G. A. F., CAMILO, G. F., SILVA, L. G. C., et al. “Segurança
na Internet do Futuro: Provendo Confiança Distribuída através de Correntes de
Blocos na Virtualização de Funções de Rede”. In: Minicursos do SBRC’2019,
2019.
[30] GREVE, F., SAMPAIO, L., ABIJAUDE, J., et al. “Blockchain e a Re-
volução do Consenso sob Demanda”. In: Minicursos do SBRC’2018, v. 36, 2018.

35