Banco de Dados

15 dez, 2016

Considerações sobre um blockchain seguro para empresas: infraestrutura, middleware e consenso

Publicidade

Neste artigo, eu trago um foco técnico sobre considerações de segurança para as aplicações corporativas de blockchain e redes corporativas. Eu também busco introduzir uma abordagem que desenvolva a doutrina de implementação de defesa em camadas, que tem sido empregada como uma prática de combinar múltiplos controles de segurança para proteger os recursos (ativos digitais/smart contracts, no contexto do blockchain) e dados (dados contábeis, no contexto do blockchain).

A promessa do blockchain tem origem na visão de uma Internet de Valor ou, em alguns casos, Internet de Transações, com uma fundação na troca de dados sistêmica e segura, levando à negociação e à transferência de valores através dos smart contracts como intermediários de negócios. Esses elementos fundamentais trazem a possibilidade de permitir movimentações seguras de coisas de valor com não repudio – ou, pelo menos, essa é a intenção.

Em minha discussão anterior sobre blockchain e as redes de valores, eu enfatizei a importância de um sistema de confiança no blockchain que vise a eliminar os intermediários de confiança e a habilitar a simetria de informações para participantes de redes corporativas. Esse nível de eliminação de intermediários conta com a provisão de uma estrutura que possa garantir o poder computacional e algoritmos comprovados que possam prover um sistema de confiança robusto, substituindo os intermediários.

Empresas significativamente percebem as promessas do blockchain, que são:

 a) Modelos de custo de transformação: – Custos de TI: sistemas redundantes e duplicados e/ou custos de oportunidades, incluindo custos de liquidez e de capital, resultantes de operações ineficientes no mercado devido a fluxos de informação assimétricos.

Ou

b) Modelos de custos disruptivos: Novos modelos de negócios, como plataformas de troca de valores P2P e modelos financiados por crowd.

A adoção do blockchain é um ato de balanceamento para as empresas, pois elas não têm que somente executar, gerenciar e manter a infraestrutura existente, mas também preparar o caminho para esse novo modelo computacional que promete fundamentalmente mudar as empresas e até mesmo indústrias inteiras. Para indústrias regulamentadas, isso significa um impacto duplo no custo de conformidade, pois mesmo uma plataforma de uma nova tecnologia deve se adaptar às estruturas regulatórias bem conhecidas e a arquitetura e design provados devem passar pelo teste do sistema regulatório.

Com base na abordagem por camadas e com fonte em várias sessões de design, eu gostaria de passar para as considerações sobre o blockchain para empresas, em que os objetivos são essencialmente:

  1. Infraestrutura
  2. Middleware
  3. Sistemas de certificação (ex.: Consensus)

Considerações para aplicações de blockchain empresarial com uma abordagem em 3 camadas

I – Física: Camada da infraestrutura de TI

Essa camada trata da infraestrutura essencial de TI e de seus elementos de segurança, tais como rede e instâncias, isolamento de hardware, módulos de segurança de hardware (HSM, em inglês) para gerenciamento e armazenamento de segurança, aceleradores de criptografia para descarregadores de processos de criptografia. A ideia é não somente abordar a construção dos blocos básicos e elementos fundamentais de segurança, mas fornecer suporte para os níveis mais altos de protocolos e camadas, e também assegurar que estamos abordando os requisitos de escalabilidade de uma rede de blockchain, que é uma importante consideração para aplicações de blockchain, redes e aplicações distribuídas.

Outras considerações sobre escalabilidade da infraestrutura

1) Blockchain – Consensus, propriedades ACID e CAP

Quando NoSQL e modelos distribuídos baseados em dados se tornam a norma, vários modelos em que um sistema NoSQL resolveu seu problema particular entendendo o teorema CAP com a comunidade empresarial RDBMS se mantiveram firmes à suas propriedades ACID. Existem várias razões pelas quais o blockchain poderia muito bem habilitar os mais básicos a quebrar o CAP e manter o ACID. Aqui estão algumas considerações.

CAP

C (Consistency) consistência: O consenso garante que existe somente uma verdade do que aconteceu e a ordem em que aconteceu.

A (Availability) disponibilidade: O fato de todas as chamadas ao blockchain serem assíncronas permite que as chamadas da aplicação progridam enquanto o consenso e a durabilidade (colocar em cadeia também garante isso) estão sendo realizados.

P (Network Partition) partição de rede: O consenso novamente nos previne de dividir o cérebro com conflitos quando as coisas se juntam após a partição de rede.

As propriedades ACID de uma transação

A (Atomicity) atomicidade: O modelo de programação por cadeia de código tem um comportamento tudo ou nada, o que permite que alguém agrupe todas as atividades – ou acontece tudo ou nada.

C (Consistency) consistência: Uma consideração significativa em DAPP – Aplicações distribuídas e em muitos casos a escolha do consenso é orientada para alcançar a consistência, e isso significa o mesmo que o “C” do CAP.

I (Isolation) isolamento: Significa que duas transações serão serializadas, o que é exatamente o que a construção em blocos e cadeias faz.

D (Durability) durabilidade: A cadeia e a replicação por toda a rede garantem que se um ou mais nós caírem, nós não perderemos os dados; é por isso que todos querem trazer um nó, e é por isso que nós queremos ter certeza de que nem todos os nós não estejam co-localizados.

2) Atestado – Certificados auto assinados – SSC (em inglês) são assinados e criptografados.

As imagens do software, sistema operacional, hipervisores e containers do Docker não podem ser alteradas. Os certificados podem ser incluídos dentro do SSC para que ele prove que é genuíno para uma parte remota. Por exemplo, podemos incluir um certificado SSL quando construímos um SSC para que, mais tarde, possamos ter certeza de que estamos conversando com uma instância genuína, pois o certificado SSL sempre estará protegido (criptografado) dentro do SSC.

3) Utilização do HSM

Um HSM é um aparelho computacional físico que protege e gerencia as chaves digitais para uma autenticação forte e providencia o processamento das criptografias. Esses módulos, normalmente vem na forma de um cartão ou outro aparelho externo que é conectado ao computador ou servidor de rede. Wikipedia: ” O hardware do módulo de segurança administrando um aparelho de alta segurança como o HSM é difícil de ser realizado com a segurança e os controles adequados. De fato, os padrões de hoje ditam alguns métodos e níveis de segurança para os administradores dos sistemas HSM(e gerenciamento chave).

II – Camada do middleware de blockchain – essa camada inclui considerações sobre a razão dos dados de armazenamento, algoritmo de cifra simétrica, tamanho da chave, algoritmos de chave pública, escolha da razão de armazenamento e replicação, nível de criptografia, criptografia no armazenamento dos dados, transferência e dados em rest, e visibilidade dos dados para os participantes da rede (veja as sub razões abaixo). Essas camadas também incluem a escolha do “material” do blockchain, infraestrutura e módulos suportados, e todos os aspectos da integração corporativa.

Nota sobre multicanais/Sub-razões – um conceito de design de hiper-razões

A teoria original por trás dos multicanais e sub-razões foi promover um nível de isolamento para as cadeias/redes por consenso com um serviço. A separação seria alcançada utilizando diferentes canais para as razões simples (na época da ideia original, só existia uma razão disponível).

III – Consenso no blockchain (ex.: camada de sistema de confiança) – eu sempre acreditei que esse é o coração do blockchain. O consenso no blockchain é requerido para garantir propriedades muito básicas de armazenamento de dados. Quanto mais jogadores estiverem na rede, somente os escalaremos se eles trouxerem equidade computacional. Isso está relacionado à construção de um “armazenamento de dados compartilhado” que a empresa qualifique que eles obtenham internamente – com uma menor barreira para a entrada. Consenso, ou o mínimo de consenso, é requerido para garantir isso na arquitetura utilizada.

Uma divisão emergiu entre os sistemas de confiança baseados na criptografia e em moeda corrente e os não baseados na criptografia e em moeda corrente. Basicamente, os sistemas de confiança com a criptografia baseada na moeda corrente, como POW/PoS, levam a um modelo que é insustentável para casos de uso em empresas que desejam ter o blockchain. Isso é um tópico que merece um artigo dedicado somente a ele.

Em um dos meus artigos anteriores, eu discuti os princípios do blockchain para o permissionamento de uma rede buscado por indústrias regulamentadas, as regras de combinação mudam, e a moeda radicalizada deve ser transformada em um sistema viável e de confiança que pode escolher ignorar ou adotar como fundamento de partes de um incentivo econômico baseado no sistema de confiança e nos modelos de consenso. Conforme discutido mais cedo, muito trabalho precisa ser realizado nesse campo, pois não existe um modelo de consenso que tratará todos os casos (existem Byzantine Fault Tolerant [BFT], PoW, PoS ou Practical Byzantine Fault Tolerant [pBFT], RAFT, Paxos etc.). Uma empresa precisa entendê-los. Eles também precisam de investimentos nos recursos (pessoas, energia e tempo).

Conclusão

A adoção do blackchain será um ato de balanceamento para a empresa, que não terá que somente executar, gerenciar e manter a infraestrutura atual, como também preparar o caminho para um novo modelo computacional que promete, fundamentalmente, mudar as empresas e até indústrias inteiras. Para as indústrias regulamentadas, isso significa um impacto duplo nos custos de conformidade, porque mesmo uma plataforma de nova tecnologia tem que aderir às estruturas e arquiteturas de tecnologia comprovadas e passar pelos testes regulamentares. As empresas podem ter uma abordagem pragmática para considerações empresariais com blockchain a adotar uma defesa em camadas, que envolve a combinação de múltiplos sistemas de controle para proteger os recursos (bens digitais, smart contracts no contexto do blockchain) e dados.

***

Nitin Gaur faz parte do time de colunistas internacionais do iMasters. A tradução do artigo foi feita pela Redação iMasters, e você pode acompanhar o artigo em inglês no link: https://www.linkedin.com/pulse/secure-blockchain-considerations-enterprise-middleware-nitin-gaur.