Archive for December, 2007

Recovery Point Objective

RPO (Recovery Point Objective) é a métrica utilizada para identificar a disponibilização de dados que atendam os RTOs definidos para cada processo de negócio.

Não entendeu nada? Fique tranquilo, é o que eu mais vejo por aí!

Em poucas palavras o RTO é quanto o processo suporta de perda de dados. Não confunda isto com o último backup realizado, equívoco bastante comum entre os profissionais de contingência, infra-estrutura.

O último backup realizado pode servir como métrica para desenvolver uma estratégia para garantir a continuidade de processos de negócios, mas o RTO consiste em um objetivo, como o acrônimo RPO (Recovery Point Objective) deixa claro.

Vamos tentar clarear as coisas. Aconteceu um incidente, preciso restabelecer um processo dentro do objetivo de recuperação que eu identifiquei (RTO). Para restabelecer este processo eu preciso de dados, ai entra o RPO. Se eu preciso de dados de 2 horas (meu RPO) antes do incidente e meu último backup é de 24 horas atrás, tenho um problema sério.

Recovery Point Objective

Para atender o meu RPO de duas horas preciso alterar a minha estratégia de backup ou fazer uma reengenharia no processo.

Porque reengenharia no processo?

Porque não é sempre que o meu problema é apenas com dados digitalizados. Se o problema é backup, eu posso mudar minha solução de backup, alterar a estratégia. Agora se o processo depende de informações "não digitais"? Ai só uma reengenharia no processo pode resolver ou minimizar os impactos.

links for 2007-12-28

links for 2007-12-24

links for 2007-12-22

links for 2007-12-21

Recovery Time Objective

O termo RTO (Recovery Time Objective) é conhecido pela maioria dos profissionais que atuam direta ou indiretamente com Continuidade de Negócios.O RTO consiste no tempo em que determinado processo tem para que, uma solução de recuperação e/ou contingência seja executada/ativada antes que o processo venha causar impacto a organização.

Se já sabemos o que é o RTO, não existe dificuldade em identificar junto aos responsáveis pelo processo, qual o RTO de cada processo. Errado, boa parte dos RTOs identificados em trabalhos de Continuidade de Negócios não condizem com a realidade e acabam direcionando as organizações a tomar decisões precipitadas.

A primeira coisa que devemos nos ater é, o RTO é apenas o tempo que o processo tem disponível para ser suportado por uma solução alternativa que o mantenha a níveis satisfatórios sem causar impactos a organização. Neste tempo teremos apenas uma solução de contorno (Workaround), o que difere do tempo total que um processo pode ficar indisponível. O tempo total que um processo pode ficar indisponível é definido segundo a BS 25999-1 como MTPD (Maximum Tolerable Period of Disruption).

Então podemos identificar pelo diagrama abaixo que, eu preciso subtrair do tempo total que o processo pode ficar indisponível o RTO mais o tempo para reestabelecer a normalidade.
MTPD

Se não bastasse o equívoco cometido quanto aos tempos de RTO/MTPD, muitos generalizam o tempo assumindo que o MTPD é o RTO, ainda temos um problema mais sério. A maioria dos RTOs mapeados em projetos é muito mais baixo do que deveria. Na prática são raras as exceções onde um processo tem RTO menor que 1, 2 hora. O que quero dizer com isto? A maioria dos profissionais valorizam muito os RTOs sem medir ou conhecer as consequências. Um processo que pode ter até 24 horas de RTO é mapeado com um 1 hora como se não houvesse problema nisto.

O grande problema quando mapeamos RTOs relativamente baixos é a solução de estratégia. Sabemos que os RTOs e critícidades dos processos da organização são mapeados na BIA (Business Impact Analysis), fase esta que antecede e serve como tomada de decisão para a próxima fase, seleção de estratégia.

Na fase de Seleção de Estratégia vamos planejar e identificar soluções para atender os tempos mapeados como objetivo (RTO) na BIA. O que acontece quando os RTOs são muito baixo? As soluções para atender estes tempos serão soluções de alta disponibilidade e consequentemente terão um custo muito mais alto que qualquer plano de resposta. Ao contrário do que muita gente pensa, Se sabemos que são raras as exceções de RTO entre 1 e 2 horas, consequentemente são raras as exceções onde você necessita de Alta Disponibilidade para atender as necessidades da organização.

Resumindo, Planos para Continuidade do Negócio estão longe de ser soluções de contingência e a maioria das organizações estão gastando mais do que deviam com soluções de Alta Disponibilidade e Contingência.

No próximo post vou falar sobre o RPO (Recovery Point Objective).

links for 2007-12-18

links for 2007-12-17

links for 2007-12-15

USB Insecurity

Um assunto comum entre profissionais de segurança recentemente é a disponibilização ou não, de acesso a porta USB de computadores corporativos. Com acesso USB pode se conectar desde de dispositivos de mass storage (pendrive), até periféricos como impressoras.

O problema é que através deste recurso pode-se roubar informações, conectar dispositivos que possam comprometer a segurança do computador, até dar boot em sistemas operacionais.

Esta breve introdução é apenas para dizer que, se já era necessário atenção quando o acesso a porta era físico, imagine se o recurso for acessado via rede?

É exatamente o que o projeto USB/IP Project se propõe a implementar.

USB/IP Project

Next Page »


View Wagner Elias's profile on LinkedIn