Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo

De Wiki BPF
Revisão de 19h58min de 5 de maio de 2020 por Leonardo.furtado (discussão | contribs)
Ir para: navegação, pesquisa

Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo

Autor: Leonardo Furtado

Introdução

Todos os engenheiros de redes sênior que atuam em ISPs, ou em qualquer empresa séria que possua um Sistema Autônomo, compreendem a importância em estudar corretamente a farta quantidade de informações referentes às tabelas BGP, e não apenas na perspectiva da tabela BGP de seus próprios e respectivos ASNs, e sim estendendo estes estudos e tratamentos de dados na perspectiva de vários pontos de monitoramento, os quais incluem coletores, route views, looking glasses, e afins, espalhados pela Internet. Ou seja, como você (ou, neste caso, o seu ASN) vê o mundo ao seu redor, e como as várias partes do mundo (ASNs em suas respectivas regiões) vêem o seu ASN.

Isto para sintetizar primariamente as iniciativas de prevenção dos dois principais tipos de incidentes envolvendo o roteamento de Internet, a saber: route leaks e prefix hijack. Só que as necessidades de um ASN no que tange ao monitoramento de seu BGP vão bem além do que somente (embora gravíssimos) incidentes com route leaks e prefix hijacks, para os quais, inclusive, já existem BCOPs específicas para prevenção e mitigação, como é o caso do RFC 7454 / BCP 194, BCP 38, BCP 185, e MANRS. Há muito mais coisas a serem observadas e tratadas com relação ao BGP do que apenas as questões de segurança.

Ou seja, em adição às questões de segurança, o Sistema Autônomo/ASN precisa monitorar constantemente, dentre dezenas de objetos e métricas gerenciáveis, e seus respectivos KPIs, e de uma magnitude grande de componentes, o seu BGP como um todo. Isto para que respostas possam ser fornecidas para sanear diversos desafios que vão além da segurança do roteamento daquele ASN (e estendendo-se para seu cone de clientes), tais como a escalabilidade, engenharia de tráfego com ênfase na redução inteligente de custos e com potencial aumento de qualidade de serviço (ex: fornecer conteúdo com menor latência ao mesmo tempo em que reduzindo custos com esta iniciativa); planejamento de capacidades, planejamento das métricas de confiabilidade, disponibilidade e resiliência da infraestrutura, os padrões de convergência da rede, plano diretor de investimentos, toda a parte financeira também, etc.

Falando especificamente do BGP, os modelos tradicionais de monitoramento possuem restrições: routeviews e looking glasses não mantém históricos de informações sobre rotas (seja pelo prefixo direto ou pela expressão regular do atributo AS_PATH), consequentemente não se sabe o que aconteceu, quando e por quem. Além disto, uma sessão BGP somente anuncia as suas melhores rotas (best path), e esta informação pode ser obtida de um roteador por CLI ou NETCONF, porém, novamente, sem dados históricos. O que algumas empresas fazem para compensar estas restrições dos modelos tradicionais com ferramentas vigentes é recorrer a soluções e sistemas que consigam manter estas informações numa base de dados que seja flexível, escalável e gerenciável, e que mantenha um histórico de mudanças sobre estes registros. Ou seja, construir e customizar sistemas específicos, ou adquirir um sistema comercial para este propósito. E que, preferencialmente, seja de fácil integração com outros sistemas (incluindo Sistemas de Suporte à Operação (OSS)).

O que estou propondo aqui é ampliar os conceitos de ferramentas para o monitoramento efetivo do BGP: além de manter seus looking glasses e consultar route views, onde aplicáveis, os ASN poderem manter as suas próprias bases de dados com históricos acerca de tudo o que ocorre com o BGP na perspectiva daquele ASN, de seu cone de clientes, além da sua relação com seus upstreams de trânsito IP, sessões de peering e afins. Ou seja, não apenas o "snapshot" do que está acontecendo na hora, mas obter informações sobre prefixos e ASNs através de uma linha temporal e para atender diversos casos e aplicações técnicas e de negócios. É o que chamamos de "telemetria orientada a modelos", que, nos projetos mais sofisticados e completos, combina ferramentas de "telemetria baseadas em eventos" (obtenção de dados por CLI, NETCONF com modelos Yang, SNMP, EEM/event scripts, RMON, etc.), e "telemetria de streaming periódica", com monitoramento de diversos objetos relacionados à capacidade e dados estatísticos de consumo (latência, throughput, processamento) por meios de diversas ferramentas e procedimentos. Interessante, não?

Em suma, este artigo está centrado na dissertação de propostas para o gerenciamento e monitoramento efetivo do protocolo BGP nos Sistemas Autônomos. Espero que você curta!

Observação importante:

Se você estiver aguardando uma solução "pronta" ou com uma expectativa de que eu vá fornecer aqui uma "receita de bolo", lamento muito, mas não é esta a intenção do artigo! Fornecerei aqui uma visão muito mais ampla deste contexto, e tentarei desmembrar este tópico empregando alguns conceitos de pesquisa aplicada e de desenvolvimento experimental. Entenda isto como um pontapé inicial para que você consiga adquirir os conhecimentos necessários para desenvolver seus próprios conceitos de adoção tecnológica, processual e instrumental, objetivando o gerenciamento e monitoramento do BGP de seu AS, e culminando na tomada de decisão de sua parte sobre uma ou mais das seguintes possibilidades:

  1. Investimentos em soluções comerciais existentes, com potencial de customizações e integração com outros sistemas para o atendimento de necessidades específicas do seu negócio.
  2. Desenvolvimento de sistemas com fábrica de software própria, atendendo a todos os modelos de gerenciamento desejados.
  3. Adoção de ferramentas específicas para o atendimento de necessidades igualmente específicas, tais como soluções de código aberto ou até mesmo de ordem comercial.

Um "abre-alas" sobre a importância e missão dos sistemas de gerenciamento no geral

Antes de começarmos, gostaria de comentar uma característica do meu trabalho e que afeta o meu julgamento por completo. Aqueles que me conhecem de longa data sabem que sou um tanto insistente em algumas das minhas análises, visões, conclusões e objeções. Para estas pessoas que me conhecem, quantas vezes já não ouviram o Leonardo Furtado citar a seguinte frase?

"Muitos profissionais de ISP (incluindo alguns perfis de gestores) pecam na hora de investir e de tomar decisões importantes para seus negócios: adquirem soluções tecnológicas focando apenas ou principalmente nas necessidades de curto prazo, muitas vezes adotando soluções minimalistas, e centradas no fator de menor custo"

A relação desta frase com o artigo em questão é óbvia, e você entenderá melhor logo a seguir: muitos profissionais de redes implementam ferramentas de gerenciamento em suas infraestruturas sem que haja um propósito bem definido para as áreas do negócio que realmente importam. Muitas vezes a necessidade é muito óbvia ou específica, tais como "monitorar o consumo de banda referente a uma interface conectada para um upstream de trânsito IP", o que é plenamente justificável, sem dúvidas, claro! No entanto, o maior problema não reside no objeto gerenciado em questão (monitoramento de banda, monitoramento de problemas de uma interface, processamento, etc.), e sim na ausência de analíticos associados aos objetos gerenciados pelas ferramentas em questão, as quais foram adquiridas pela organização (e seja lá quais tenham sido os critérios), e que foram implantadas pelo time de engenharia ou de operações. Em outras palavras: o software está "lá", implantado, e sendo (sub)utilizado pelos operadores. Mas.. quais são os reais objetivos? Quais são os indicadores desejados? Quais são os thresholds? Quais são as métricas gerenciáveis daquele componente, de cada componente? Como determinados thresholds e eventos associados àquele objeto impactam no meu negócio? Quais ações e tomadas de decisões executaremos para prevenir, mitigar e responder ao eventos fornecidos pelo gerenciamento acerca daquele objeto gerenciado? Como este objeto gerenciado participa do meu negócio e nas diversas áreas, centros de custo, e contextos, incluindo comercial, reputação, financeiro (capex, opex, fluxo de caixa, etc.), engenharia (capacidade, disponibilidade, resiliência, consumo de recursos, tráfego, etc.), operações, fornecedores, etc.? A lista é grande.

Com 25 anos de profissão, o que mais vi em toda a minha carreira e em muitas empresas que visitei foram soluções de gerenciamento inteiras praticamente "encalhadas", subutilizadas! Sistemas complexos e por muitas vezes interessantes que, de diversas funções e capacidades disponíveis, são extraídos apenas recursos pontuais e, mesmo assim, sem que analíticos e dados importantes pudessem ser coletados, tratados e consumidos pelas áreas relevantes do negócio para que pudessem aproveitar estas informações para algo realmente útil, seja algo visando aprimorar a parte técnica/tecnológica ou a parte do negócio propriamente dito.

Outra forma de sintetizar isto: em muitas empresas não há efetivamente um projeto prevendo a construção (ou adoção/contratação) de sistemas de gerenciamento. O gerenciamento efetivo ou adequado é frequentemente a parte mais negligenciada da infraestrutura.

Dissertar amplamente sobre isto está fora do escopo deste artigo, mas a mensagem que gostaria de deixar aqui é bem simples: tratando-se de sistemas de gerenciamento, e não importando para qual finalidade (desempenho, capacidade, incidentes/falhas, inventário, segurança/auditoria/compliance, engenharia de tráfego, etc.), procure conduzir um projeto técnico consistente e específico para este(s) sistema(s), e que vá identificar e documentar os seguintes:

  • Em alinhamento com o projeto de infraestrutura vigente, incluindo todo o parque tecnológico presente (hardware e software), quais são as necessidades da área técnica da empresa, assim como de possíveis outras áreas interessadas?
  • Quais problemas estamos sofrendo no momento e/ou que gostaríamos de evitar?
  • Como cada um destes problemas, incidentes ou circunstâncias impacta nos negócios da empresa? É possível quantificar os prejuízos, quaisquer que sejam (reputação, multas, reparação, cancelamento de contratos, perda de receitas, aumento de custos imprevistos, etc.)? E quais áreas internas do negócio são impactadas? É viável fazer esta associação?
  • Quais deverão ser os objetos gerenciados?
  • Quais são as facilidades de gerenciamento suportadas pelo meu parque tecnológico (HW e SW)? E quais são as capacidades demandadas sobre cada um destes recursos?
  • Das tecnologias ou recursos disponíveis e suportados pela infraestrutura, quais são as melhores e mais aderentes opções para o atendimento de cada objeto gerenciado identificado? (prós e contras, matriz funcional de qualidade, etc.)
  • Quais deverão ser os indicadores e métricas para estes objetos gerenciados quando utilizando-se dos recursos ou facilidades de gerenciamento identificados como mais aderentes para os meus propósitos?
  • Como as áreas internas do negócio, onde aplicáveis, consumirão estes analíticos, indicadores e métricas?
  • Quais processos deverão ser estabelecidos para ações de prevenção, mitigação e reação quanto aos thresholds dos objetos gerenciados?
  • Dentre muitas questões; encerrarei por aqui para não fugir por completo do escopo do artigo.

Somente após responder estas perguntas e planejar toda a iniciação do projeto de adoção de solução de gerenciamento é que você conseguirá encontrar a solução ideal, a(s) "ferramenta(s)", e fazendo isto com critérios consistentes nos requisitos de facilidades, recursos, integração, custos, etc. Entendo que esta deva ser a aderência a ser pensada e projetada, assim como entendo que você precisará instaurar os processos primeiro para depois chegar a estas conclusões. Dica: para o tema "processos", confira o artigo Frameworks de Indústria para a Reestruturação e Profissionalização do ISP!

A implantação e operação de sistemas de gerenciamento, quaisquer que sejam as finalidades, deve passar primeiro por um plano de projeto que vá identificar todas as questões envolvendo necessidades, desafios, métricas desejadas, capacidades e qualidades demandadas, os objetos a serem gerenciados, as facilidades e recursos necessários, como os dados serão coletadas, processados e armazenados, e como a organização como um todo deverá consumir e tirar proveito destes dados para aprimorar seus indicadores.

"Carroça não anda na frente de boi": exercite o planejamento antes de sair implantando ferramentas, e usufrua de melhores resultados!

Por que um ASN precisa investir no gerenciamento de seu ambiente BGP?

Ou quais problemas poderão ser resolvidos com o gerenciamento efetivo do BGP em seu ASN?

A sequência deste artigo estará centrada quase que integralmente no "BGP" e possivelmente citarei outros elementos que participam diretamente do funcionamento deste. Ou seja, não pretendo realmente dissertar sobre necessidades, objetivos e requisitos gerais envolvendo disciplinas e métricas de gerenciamento de toda uma infraestrutura. Quem sabe isto não fica para um futuro artigo aqui na Wiki do Brasil Peering Forum?

Suponhamos que as áreas de engenharia e operações de um ISP cheguem a um consenso de que é necessário ter ampla visibilidade e acesso à informações relevantes especificamente relacionadas ao BGP para que sejam discutidas formas de antecipar e mitigar riscos, e responder aos diversos tipos de incidentes relacionados às questões de segurança, disponibilidade, performance, ou seja, o SLA em geral, assim como o planejamento de capacidades e a engenharia financeira do negócio. Se tivéssemos que exercitar este consenso entre estas duas áreas, quais teriam sido alguns dos diversos critérios factíveis? Para este exercício hipotético, proponho que estes requisitos sejam devidamente categorizados da seguinte forma para melhor compreensão e dissertação de casos:

  • Segurança do roteamento BGP
  • Segurança do plano de controle da rede
  • Segurança contra negação de serviços
  • instabilidades do BGP
  • Engenharia de tráfego
  • Planejamento de capacidades
  • Reputação e conformidade

O seu trabalho, na condição de engenheiro de rede ou arquiteto de soluções, será buscar as respostas para iniciar este planejamento!

Brainstorming para o planejamento de uma solução de gerenciamento específica para o BGP

Dissertemos um pouco mais sobre estes caso hipotético:

Matriz de Necessidades, Requisitos e Desafios a serem Superados para a Demanda "BGP" do ISP
Categoria Necessidade Requisito Problemas ou desafios a serem resolvidos Partes interessadas
Gerenciamento da segurança do roteamento BGP Deteção e mitigação de vazamento de rotas e sequestro de prefixos do ASN Identificação e mitigação de route leaks
  • Evitar incidentes que promovam instabilidades na rede do ISP, redes do cone de clientes, e sistemas autônomos vizinhos
  • Assegurar que o ASN não crie ou gere route leaks, assim como assegurar que route leaks não sejam aceitos a partir de sessões de clientes, peering e trânsito
  • Evitar que a reputação do ASN seja afetada em decorrência destes eventos
  • Encurtar o tempo de deteção de incidentes envolvendo route leaks
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de route leaks
NOC, Engenharia
Identificação e mitigação de sequestro de prefixos (prefix hijacks)
  • Evitar incidentes que promovam instabilidades na rede do ISP, redes do cone de clientes, e sistemas autônomos vizinhos
  • Evitar que a reputação do ASN seja afetada em decorrência destes eventos
  • Evitar que o ASN não sequestre prefixos, assim como recusar o recebimento de quaisquer anúncios com ROA (RPKI) e/ou IRR inválidos
  • Encurtar o tempo e detecção de incidentes envolvendo o sequestro de prefixos
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de sequestro de prefixos
NOC, Engenharia
Deteção e mitigação de abusos contra recursos do BGP Controle de recebimento de anúncios de ASNs vizinhos
  • Evitar abusos e possíveis impactos relacionados à capacidades e escassez de recursos
  • Evitar que ASNs de clientes anunciem de forma acidental ou maliciosa uma quantidade de prefixos superior à estimada ou autorizada
  • Evitar abusos com a desagregação através de anúncios excessivamente específicos recebidos de clientes, peering e trânsito
  • Encurtar o tempo de detecção de incidentes desta natureza
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de abusos de anúncios
NOC, Engenharia
Controle de abuso de AS-Path Prepending
  • Evitar que o ASN do ISP, assim como ASNs vizinhos e o restante da Internet, sofram possíveis impactos e instabilidades quanto à prefixos com excesso de AS-Path Prepending atrelados aos anúncios
  • Evitar abusos quanto ao recebimento de rotas BGP que contenham AS-Path Prepending excessivos (uma forma de Self-Inflicted Vulnerability)
  • Encurtar o tempo de detecção de incidentes desta natureza.
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de abusos de anúncios
NOC, Engenharia
Gerenciamento da segurança do plano de controle da rede Detecção e mitigação de incidentes de segurança contra o próprio BGP Controle de vulnerabilidades sobre as mensagens do BGP
  • Evitar indisponibilidades e outros tipos de incidentes que possam ser provocados com a exploração das mensagens do BGP (conforme (3.1. Vulnerabilities in BGP Messages do RFC 4272)
  • Evitar a manipulação e injeção maliciosa de atributos sobre os anúncios por mensagens Update do BGP
  • Encurtar o tempo de detecção de incidentes desta natureza
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de exploração destas vulnerabilidades
SOC, NOC. Engenharia
Controle de incidentes de segurança lançados diretamente contra as sessões BGP
  • Evitar que as sessões BGP sejam atingidas diretamente por técnicas maliciosas que visam desde o downtime/indisponibilidade, sequestro de sessões, injeção de informações errôneas
  • Encurtar o tempo de detecção de incidentes desta natureza
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de ataques lançados contra os processos BGP
SOC, NOC, Engenharia
Gerenciamento da segurança contra negação de serviços Detecção e mitigação contra ataques DDoS Detecção de anomalias nos fluxos de tráfego e mitigação de ataques DDoS
  • Evitar ou atenuar efeitos adversos de indisponibilidades, instabilidades, impactos severos no SLA de clientes, prejuízos financeiros de grandes proporções, e danos na reputação da empresa
  • Evitar a injeção de informações maliciosas na tabela BGP que permitam livre comunicação entre hosts infectados em suas botnets
  • Encurtar o tempo de detecção e reação a estes tipos de incidentes
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e mitigação de DDoS
SOC, NOC, Engenharia
Gerenciamento de instabilidades do BGP Detecção e mitigação de instabilidades e outros problemas que podem afetar a disponibilidade e SLA Detecção de oscilações de sessões BGP
  • Evitar que ocorram instabilidades na prestação de serviços de acesso à Internet por conta de oscilações das sessões BGP
  • Encurtar o tempo de detecção e reação a estes tipos de incidentes
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e problemas com as sessões BGP
NOC
Detecção de oscilações de rotas (route flaps)
  • Evitar que ocorram indisponibilidades na comunicação com determinados serviços/destinos de Internet por conta de oscilações e intermitências quanto à convergência da tabela BGP
  • Encurtar o tempo de detecção e reação a estes tipos de incidentes
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e oscilações de rotas BGP
NOC
Detecção de rotas eventualmente suprimidas por Dampening
  • Evitar discrepâncias nas matrizes de tráfego e, de certa forma, atenuar a assimetria do roteamento IP, blackhole ou routing loops por conta da eventual supressão de rotas (dampening) executada no ASN local ou em vizinhos
  • Encurtar o tempo de detecção e reação a estes tipos de incidentes
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de supressão de rotas BGP e como estes eventos afetam o comportamento da rede e a disponibilidade de serviços
NOC
Detecção de problemas de convergência associados à escassez de recursos de processamento e enlaces
  • Evitar que determinados recursos tais como capacidade de enlaces, arquiteturas de roteadores (CPU, memória, FIB, etc.) fiquem subutilizados enquanto outros elementos fiquem sobrecarregados
  • Evitar gargalos nas operações e transações de rede, os quais podem provocar impactos no SLA
  • Encurtar o tempo de detecção e reação a estes tipos de incidentes
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção de gargalos e esgotamento de recursos
NOC, Engenharia
Planejamento e antecipação de cenários "what if"
  • Evitar que manobras de configurações, incluindo modificações nas políticas de roteamento e ações de engenharia de tráfego provoquem distúrbios não antecipados
  • Antecipar impactos na convergência e disponibiidade da rede através de uma análise preditiva envolvendo cenários de falhas
Engenharia
Gerenciamento da engenharia de tráfego Detecção e mitigação de impactos sobre os recursos de infraestrutura decorrentes de eventos pontuais na Internet Identificação, classificação e detalhamento da matriz de tráfego por diversos padrões de ordenamento
  • Superar as limitações operacionais da empresa em função da escassez de informações e a falta de visibilidade sobre os fluxos de tráfego
  • Aprimorar as ações de dimensionamento de recursos de infraestrutura, tais como plataformas de switches e roteadores, além de enlaces de comunicação de dados
  • Aprimorar os resultados das ações de engenharia tráfego para fins de acomodar melhor as conversações da rede sobre os recursos disponíveis
  • Atenuar ou eliminar os desafios que provocam impactos sobre o SLA de assinantes
  • Fornecer analíticos, dados históricos e baselines relacionados às matrizes de tráfego, com histórico de consumo por ASN, peer, prefixo, protocolo de transporte, tipo de aplicação, marcações, atributos, etc.
Engenharia
Estudos e análises de impactos sobre as matrizes de tráfego em eventos de falhas
  • Reduzir os indicadores de MTTR e MDT associados aos eventos de falhas relacionadas ao BGP
  • Reduzir os indicadores de reclamações por conta da violação de SLAs envolvendo indisponibilidades, latência, jitter, perda de pacotes, etc.
  • Reduzir os impactos provocados nas áreas internas do negócio que são destinadas ao interfaceamento com clientes, tais como comercial, atendimento a clientes, NOC, jurídico, etc.
  • Fornecer analíticos, dados históricos e baselines referentes aos impactos decorrentes de falhas para alimentar as tomadas de decisão e para nortear os investimentos e processos de mitigação
Engenharia
Aprimoramento de SLA Planejamento de engenharia de tráfego intra-AS e inter-AS por políticas de roteamento BGP
  • Reduzir impactos não antecipados sobre ações de engenharia de rede e de tráfego executadas pela área de engenharia ou de operações da empresa
  • Aprimorar as tomadas de decisão acerca das políticas de roteamento para o atendimento dos modelos de interconexão privado e público
  • Aprimorar as tomadas de decisão para as políticas de roteamento de acordo com os modelos de interesse de tráfego (hot potato, cold potato, e outras diretrizes) sobre os regimes de interconexão
  • Fomentar ações racionais de engenharia de tráfego para equilibrar as métricas de SLA (latência, jitter, disponibilidade) sobre os custos (opex) de cada enlace de transporte e de de cada acordo de troca de tráfego
Engenharia
Planejamento de engenharia de tráfego IP com auxílio de tecnologias periféricas ao BGP, tais como MPLS TE e SR-TE
  • Assegurar aderência quanto ao mapeamento do tráfego sobre os recursos locais do AS, prevendo simultaneamente as métricas de desempenho e a relação de custos de infraestrutura para a sustentação de SLAs
  • Promover a redução racional de custos através da associação de classes de tráfego ou de matrizes de conversação sobre os enlaces e sessões associadas às métricas de SLA de cada caso
Engenharia
Gerenciamento da planejamento de capacidades Planejamento de capacidades com foco na redução racional de custos operacionais Bilhetagem e tarifação de tráfego
  • Determinação da matriz de tráfego em combinação com iniciativas de bilhetagem e tarifação para determinar rateio de custos de infraestrutura nas áreas internas do negócio
  • Fornecer métricas de utilização dos fluxos de tráfego de interesse sobre os recursos de transporte para identificar áreas de otimização de custos
  • Viabilizar a compreensão da participação de cada centro de custo / área interna do negócio quanto aos padrões de consumo e contribuições orçamentárias
  • Viabilizar e fomentar a derivação da política de preços de produtos e serviços destinados a clientes em função das matrizes de tráfego, interesses de tráfego e modelos de interconexão
Engenharia
Dimensionamento de recursos de transporte e acordos de troca de tráfego
  • Planejamento de capacidades de conexões do ISP com os acordos de troca de tráfego nos regimes de peering e trânsito IP, incluindo 95th percentil
Engenharia
  • Dimensionamento de especificações, requisitos, recursos e capacidades das arquiteturas e demais componentes de infraestrutura a serem utilizados para a sustentação dos modelos de interconexão para os perfis de tráfego
Engenharia
Gerenciamento da reputação e conformidade Conquistar níveis de excelência em conformidade Deteção e mitigação de incidentes e situações não aderentes aos frameworks e boas práticas destinadas aos Sistemas Autônomos
  • Fornecer analíticos e dados históricos que classifiquem as ocorrências de incidentes provocados por eventos previstos e imprevistos pelas políticas internas da empresa
  • Fornecer métricas auditáveis quanto os incidentes de segurança associados ao BGP
NOC, SOC, Engenharia
Conquistar níveis de excelência na reputação do Sistema Autônomo Fornecimento de ferramentas para o compartilhamento de transparência e iniciativas de suporte com outros (demais) Sistemas Autônomos
  • Manutenção de sistemas e bases de informação que divulguem, dentre outros, a política de roteamento da empresa, plano de communities, "normas da casa", requisitos de segurança, requisitos de interconexão, modalidades de SLA, etc.
  • Manutenção de sistemas e bases de informação que forneçam os pontos de contato e suporte para as demandas associadas ao BGP e contextos periféricos do AS, tais como "Abuse", "Peering", "NOC", e outros
  • Disponibilização de ferramentas de autosserviço para a redução do tempo de diagnóstico e identificação de problemas por parte de NOCs de outros Sistemas Autônomos, tais como Looking Glass e outros.
  • Promover aderência quanto às boas práticas citadas pelos objetivos "Coordination" e "Global Validation" do Mutually Agreed Norms for Routing Security (MANRS)
  • Fornecer analíticos acerca da utilização das ferramentas de autosserviço para identificar necessidades de mercado, técnicas, perfil dos visitantes, áreas de interesse e geração de novas oportunidades
NOC
===== EM DESENVOLVIMENTO =====