Skip to main content

Data Recovery e a Matriz BIA na Gestão de Crises em Banco de Dados

By Artigos, Operação No Comments

A base essencial de qualquer empresa reside em seus dados. Desde informações cruciais de clientes, fornecedores e credores até a gestão de estoque, registros financeiros e análise em tempo real, tudo está ligado a um sistema de bancos de dados. Perder informações ou encontrar dificuldades para acessá-las em tempo hábil pode causar grandes dores de cabeça para quem se preocupa com a saúde financeira da empresa.

Neste post, discutiremos sobre Data Recovery e a importância de as empresas adotarem uma política sólida para momentos de crise no banco de dados. Também abordaremos o conceito de Análise de Impacto no Negócio (BIA), uma metodologia de análise e gestão para reduzir riscos nos negócios.

O que é Data Recovery?

Para começar, é importante entender que a recuperação de dados, também conhecida como data recovery, consiste na restauração de informações a partir de cópias de segurança (backups), após a ocorrência de um incidente como erro humano, desastre natural, falha de hardware ou ataques cibernéticos.

Por exemplo, imagine um HD de computador pessoal que caiu no chão. Neste HD estavam todos os trabalhos de conclusão de curso de uma pessoa que, por descuido, não fez uma cópia. A solução neste caso seria chamar um especialista para tentar recuperar esses dados, um trabalho que na melhor das hipóteses levará tempo, trazendo uma enorme dor de cabeça para essa pessoa que pode perder o prazo de entrega do trabalho e na pior das hipóteses precisará começar o trabalho do zero, pois pode ser impossível recuperá-lo. No ambiente corporativo não é diferente, incidentes ocorrem por diversos fatores e o processo de recuperação de dados deve estar inserido dentro de uma política de backup, alinhado com os objetivos do negócio e deve ser validado periodicamente.

BIA (Business Impact Analysis)

Independentemente da origem do problema, esses incidentes resultam em prejuízos para os negócios. Para diminuir o risco e evitar o problema, é possível desenvolver uma análise de riscos do negócio na cadeia produtiva da empresa. Essa análise de riscos é conhecida como BIA (Business Impact Analysis). Trata-se de uma metodologia de gestão que ajuda a identificar e avaliar os processos e sistemas críticos para o funcionamento da empresa, bem como avaliar o impacto financeiro, operacional e de recuperação que poderia resultar na interrupção de negócios.

Ao identificar os impactos que eventos adversos causam, as organizações podem se preparar de forma adequada, minimizando perdas e interrupções nas operações. Além disso, o BIA traz diversos benefícios, como a identificação de processos críticos, o estabelecimento de planos de contingência e a melhoria da tomada de decisão.

Observa-se que um dos pressupostos da Análise de Impacto no Negócio é a existência de dependência entre os processos de uma empresa ou organização. É evidente que alguns processos têm maior relevância do que outros. Portanto, é crucial ter clareza sobre quais são vitais e prioritários durante uma situação emergencial.

Cinco ações que vão te ajudar na construção de uma matriz BIA eficiente

  1. Identificação de processos críticos de negócios: identificar e priorizar os processos de negócios essenciais para a operação da organização.
  2. Avaliação de impacto: envolve uma avaliação dos impactos financeiros, operacionais e de negociação que podem resultar de intermediários nos processos de negócios identificados.
  3. Identificação de requisitos de recuperação: determinar os requisitos de tempo e recursos necessários para recuperar os processos de negócios após uma interrupção.
  4. Desenvolvimento de planos de continuidade de negócios: com base na análise realizada, desenvolva um plano de continuidade de negócios que detalham as ações a serem tomadas para recuperar os processos críticos em diferentes cenários de interrupção.
  5. Teste e revisão: teste regularmente os planos de continuidade de negócios para garantir que eles estejam atualizados e sejam eficazes. Faça revisões periódicas da análise de impacto no negócio para garantir que ela reflita as mudanças na empresa.

Duas métricas importantes que devem ser consideradas

A primeira delas é o Recovery Time Objective (RTO), que se refere ao tempo máximo permitido para restaurar os sistemas, aplicativos e dados após um incidente. Em outras palavras, é o intervalo de tempo que uma organização determina como aceitável para recuperar seus serviços operacionais após uma interrupção. Isso significa que se uma empresa definir um tempo de 4 horas de um RTO, ela se compromete a restaurar suas operações normais dentro desse período após um incidente.

A segunda métrica, o Recovery Point Objective (RPO), está relacionada com a quantidade máxima de dados que uma organização está disposta a perder em caso de interrupção. Ele representa o ponto no tempo até o qual os dados devem ser recuperados após um incidente, indicando a máxima tolerância à perda de dados. Se assim, se uma organização tem um RPO de uma hora, isso implica que está disposta a perder no máximo uma hora de dados em caso de uma interrupção. Ambos RTO e RPO são partes críticas do planejamento de recuperação de desastres e são usados para determinar as estratégias e tecnologias necessárias para garantir a continuidade dos negócios.

Planejamento é essencial

Cada modelo de negócio tem suas particularidades e a maioria dos incidentes de dados tem o potencial de serem evitados. É importante que os gestores do negócio percebam o quanto valem os seus dados e invistam em políticas e abordagens concretas para diminuir uma possível perda de dados. O desenvolvimento de Handbooks discriminando os processos de cada setor, o passo a passo, treinamento da equipe técnica, assim como uma Matriz “viva” da análise de riscos, sempre em desenvolvimento, ajudam na organização interna dos squads e na tomada de decisão do time em momento de crise.

Para equipes que não possuem DBAs experientes e desejam estar preparadas para emergências, além das dicas mencionadas, vale a pena pensar na contratação de uma consultoria especializada em banco de dados para esses momentos críticos.

Investir no planejamento é fundamental, pois um incidente de dados sem backup pode ser irreversível, dependendo da gravidade. É importante que os gestores de negócio disponibilizem recursos para iniciativas relacionadas à recuperação de dados. Em muitos casos, a prevenção e o investimento contínuo revelam-se menos dispendiosos quando comparados às ações reativas. Priorizar a implementação de medidas preventivas não apenas resguarda contra possíveis perdas de dados, mas também se revela uma abordagem financeiramente mais vantajosa no longo prazo.

Conte conosco!

Se você sente que está deixando seus dados em risco e precisa de ajuda para definir uma política de recuperação de desastres para o seu negócio, mande uma mensagem para nós. Temos um time experiente que irá desenvolver um plano específico para o modelo de dados do seu negócio.

[>> Fale com a Timbira!]

PostgreSQL: Versão 11 não receberá mais atualizações!

By Institucional No Comments

No dia 09 de novembro de 2023, o PostgreSQL 11 chegou ao fim de sua vida útil e não receberá mais correções de bugs e atualizações de segurança.
Lançada em 18 de outubro de 2018, a versão 11 nos trouxe algumas melhorias significativas, que nos permitiram extrair resultados aprimorados no PostgreSQL. Entre essas melhorias, destacamos algumas:

  • Particionamento
    Possibilidade de criar um particionamento por uma chave hash;
    Suporte à criação de uma partição padrão, que permitiu armazenar o dado que não corresponde com a regra das partições existentes;
    Melhoria no planejamento de consultas que utilizam tabelas particionadas, possibilitando a eliminação de partições desnecessárias durante a execução;
  • Paralelismo
    Possibilidade de criação de um índice btree de forma paralelizada;
    Melhoria de desempenho nos hash joins e varreduras sequenciais;
  • Procedures
    Foi adicionado o suporte a procedures, garantindo maior compatibilidade com outros banco de dados de mercado;
  • Índices
    Adicionado a cláusula INCLUDE, que permite especificar uma lista de colunas que serão incluídas no índice;
  • Desempenho
    Foi aprimorado com a capacidade de evitar a reescrita de uma tabela para um ALTER TABLE … ADD COLUMN com um default de coluna non-null;
  • Just-in-time Compilation (JIT)
    Adição do parâmetro JIT, , que determina se a compilação JIT pode ser usada pelo PostgreSQL para acelerar a avaliação de expressões.

Atualmente, o PostgreSQL adota uma política de versionamento, lançando uma nova versão a cada ano, geralmente entre os meses de Agosto e Novembro. Após o lançamento, cada versão é suportada por cinco anos, o que significa que ela não receberá novos recursos, apenas correções de bugs e atualizações de segurança. Caso queira saber mais sobre esse ponto, você pode acompanhar a política de versionamento neste link.

Diante dessa informação, nossa recomendação para a maioria dos casos é a migração para uma versão mais recente do PostgreSQL. No entanto, surge uma pergunta importante: quando é o momento adequado para realizar essa atualização? Sabemos que uma migração envolve diversas variáveis, incluindo esforço financeiro e humano. No intuito de auxiliar nessa tomada de decisão, elencamos alguns pontos importantes a serem considerados para escolha do momento ideal para implementar esse processo nos seus ambientes PostgreSQL.

Fim do suporte da sua versão atual

Seguindo a política de versionamento, uma versão, após ser lançada, recebe aproximadamente cinco anos de suporte pela comunidade. Nesse sentido, as atualizações de segurança ou correções de bugs, vitais para manter seu ambiente sustentável, têm uma data prevista para serem encerradas, a partir da expiração desse prazo.

Crescimento da demanda do seu banco de dados

Com o crescimento do seu negócio, o seu ambiente postgreSQL pode demandar melhores tempos de resposta e esse pode ser um ponto importante na decisão de migrar. A cada versão o PostgreSQL adiciona novos recursos, mas também aperfeiçoa recursos existentes. Com isso, manter seu ambiente atualizado garantirá uma melhor utilização dos recursos computacionais e, consequentemente, isso se refletirá no usuário final.

Necessidade de novas funcionalidades em seu negócio

A cada nova versão, são lançados novos recursos que têm o potencial de aprimorar a eficiência operacional. Portanto, ao planejar uma migração, você estará incorporando essas funcionalidades ao seu ambiente, garantindo melhores resultados para o seu negócio.

Aprimoramento da eficiência operacional

Novas versões trazem melhorias nas ferramentas de administração e manutenção do PostgreSQL. Se você busca melhorar a sua eficiência operacional, é um ponto a se considerar na decisão de migrar para uma versão mais recente.

Segurança é um ponto chave para o seu negócio

A cada nova versão, são incorporados novos recursos de segurança. Nos dias de hoje, considerando que os dados são vistos como o “novo petróleo”, é crucial manter a máxima precaução nesse aspecto. Manter-se sempre atualizado ajudará a evitar possíveis problemas e vulnerabilidades, uma vez que questões já identificadas e corrigidas estão presentes nas versões mais recentes.

A utilização de novas tecnologias é um destaque em relação aos seus concorrentes

Constantemente, novas ferramentas são desenvolvidas, drivers de conexão são atualizados e bibliotecas emergem. Manter uma versão desatualizada do PostgreSQL pode limitar o acesso a esses recursos inovadores. Por essa razão, consideramos este um ponto fundamental e estratégico para o seu negócio. Manter-se alinhado com as últimas tecnologias potencializará sua posição em relação aos concorrentes.
Além disso, migrar para uma versão mais recente pode proporcionar uma série de benefícios, incluindo melhoria de desempenho, suporte estendido, melhor gerenciamento de recursos, segurança aprimorada e a incorporação de novos recursos. Em uma próxima oportunidade, compartilharemos mais dicas e sugestões sobre como planejar essa atualização.

PostgreSQL 16

No dia 14 de setembro de 2023, foi anunciado o PostgreSQL 16, a versão mais recente do PostgreSQL. Nessa atualização, houve aprimoramentos significativos no desempenho, destacando melhorias notáveis em paralelismo de consultas, carregamento em massa e replicação lógica.
Entre os destaques estão a expansão da sintaxe SQL/JSON, estatísticas de monitoramento aprimoradas, flexibilidade no controle de acesso e políticas de segurança, melhorias de desempenho, replicação lógica a partir de instâncias standby e suporte a balanceamento de carga. O PostgreSQL 16 também traz melhorias na experiência das pessoas de desenvolvimento, introduzindo novos comandos no psql, suporte a agrupamentos de texto e a adição de métricas de E/S. Para mais detalhes, confira o link.

Processo de Migração

O processo de migração deve ser tratado como um projeto, dividido em várias fases, sendo a fase de homologação de suma importância e necessitando de cuidados especiais. Durante esse projeto, é crucial analisar todas as mudanças que ocorreram desde a versão atual até a versão alvo da migração. Essa atividade é fundamental para mapear os principais pontos de impacto do projeto. Recomenda-se sempre migrar para uma versão mais recente, e essas migrações devem ser incorporadas ao roadmap. Isso garante que as migrações ocorram em intervalos menores e com menor impacto de mudanças, facilitando a transição.

Atualmente, existem diversas estratégias para realizar a migração, como, por exemplo, o dump/restore, pg_upgrade ou até mesmo usando replicação lógica. A escolha desta estratégia dependerá de alguns fatores, como o tempo disponível para a janela de manutenção (downtime) e a estratégia de rollback.
Caso a decisão seja migrar para a última versão disponível do PostgreSQL, uma boa prática é aguardar pelo menos a primeira release de minor version (ex.: 16.1). Isso ajuda a prevenir possíveis riscos no ambiente causados por bugs na versão inicial.

Dica Importante!

Se você estiver executando o PostgreSQL 11 em um ambiente de produção, sugerimos que você faça planos para atualizar para uma versão mais recente e compatível do PostgreSQL. A migração para uma versão recente do PostgreSQL não é apenas uma atualização técnica, mas uma estratégia proativa para otimizar seu ambiente de banco de dados, melhorar a segurança, e se manter competitivo em um cenário tecnológico em constante evolução.

Se você precisa de ajuda no processo de planejamento, organização e implementação de uma migração no seu ambiente PostgreSQL, entre em contato com nosso time de atendimento. O futuro da sua empresa pode depender disso.

[>> Quero falar com a Timbira!]

Como o VACUUM pode influenciar o desempenho do seu PostgreSQL?

By Institucional No Comments

Uma característica importante do PostgreSQL é o isolamento de suas transações. Esse mecanismo utiliza o método MVCC (Multiversion Concurrency Control), ou Controle de Concorrência Multiversão. Este método apresenta vantagens e possibilidades a partir de seus mecanismos implementados, como, por exemplo, a redução de bloqueios ao permitir que várias transações simultâneas acessem os mesmos registros. Isso resulta em um cenário em que leituras não bloqueiam escritas e vice-versa. Por outro lado, uma desvantagem dessa arquitetura é o versionamento das linhas que não serão mais utilizadas (também conhecidas como tuplas mortas), exigindo algum mecanismo de limpeza.

Para solucionar esse problema, o PostgreSQL utiliza um recurso chamado VACUUM, que é responsável por efetuar essa limpeza. Esse recurso pode ser acionado manualmente por comandos simples ou de forma automática através do Autovacuum.

Neste texto, você poderá entender um pouco mais sobre o VACUUM e também sobre as melhorias implementadas na versão 16 do PostgreSQL, que foi lançada no dia 31 de agosto de 2023.

Quais são os tipos de Vacuum?

Antes de tudo é preciso compreender que o Vacuum no PostgreSQL apresenta algumas variações básicas. Aqui estão as principais:

VACUUM

De maneira simplificada, o VACUUM é uma ferramenta muito útil para identificar registros não utilizados no banco de dados, permitindo a recuperação de espaço em disco e melhorando o desempenho das consultas. Este comando pode operar em paralelo com a leitura e escrita normais da tabela, pois o Postgres não obtém um bloqueio exclusivo das tuplas desta tabela que sofre o VACUUM. Contudo, na maioria dos casos, o espaço extra não é devolvido ao sistema operacional; ele permanece disponível para reutilização na mesma tabela.

No PostgreSQL, os registros não são deletados fisicamente, mas marcados como inúteis, prática comum em diversas aplicações. De maneira geral, a ideia é tornar as operações de update mais eficientes e evitar um crescimento desnecessário da tabela, por isso entender a dinâmica do modelo de negócio é importante, assim como optar pela técnica do VACUUM mais adequada para cada banco de dados.

VACUUM FULL

O VACUUM FULL faz uma recriação de toda a tabela (objeto), deixando-a somente com registros válidos, pois ele grava uma nova cópia da tabela e não libera a tabela antiga até concluir a operação. Este procedimento requer cautela, pois é invasivo, precisa de espaço em disco suficiente, causa bloqueio da tabela e gera indisponibilidade de acesso durante sua execução. Dessa forma, é recomendável sempre programar uma janela de manutenção para esse tipo de procedimento.

Algumas empresas executam esse procedimento em situações bem específicas, como quando a base de dados atinge um tamanho considerável, com muitas tabelas, e existe a necessidade urgente de liberar espaço em disco, com a premissa de que downtime não prejudique os usuários. Uma dica importante: por questões de segurança, essa ação deve ser permitida apenas pelo superusuário do banco de dados e só pode ser executada de forma manual. Ou seja, nenhum processo do PostgreSQL executará um VACUUM FULL automático.

VACUUM FREEZE

O VACUUM FREEZE realiza um “congelamento” agressivo das linhas, essencialmente congelando o ID da transação para todas as páginas, independentemente de terem sido modificadas ou não. Isto faz com que todas as linhas atuais sejam vistas como antigas para todas as novas transações. Vale destacar que essa opção é sempre ativada ao usar o VACUUM FULL. Como citado anteriormente, o VACUUM FULL reescreve e corrige os dados, incluindo o VACUUM FREEZE. Embora sejam opções semelhantes, elas não são idênticas.

VACUUM VERBOSE

O VACUUM VERBOSE permite um acompanhamento de todas as ações que ocorrem durante o processo. Esse parâmetro possibilita a geração de um relatório detalhado de tudo o que está sendo executado pelo comando VACUUM.

O comando “VACUUM VERBOSE” é bastante útil para analisar possíveis falhas na execução do VACUUM ou até mesmo para conferir estatísticas após sua execução. Esse comando pode ser utilizado em conjunto com qualquer tipo de VACUUM. Exemplos: VACUUM VERBOSE FREEZE, VACUUM VERBOSE FULL.

VACUUM ANALYZE

Esta opção é responsável por atualizar as estatísticas usadas pelo planejador do plano de consultas. Embora possa ser acionada individualmente, quando em conjunto com o VACUUM traz uma excelente abordagem de otimização. Isso ocorre porque requer apenas o bloqueio de leitura da tabela, permitindo que as demais transações ocorram normalmente no banco de dados. E assim como o VACUUM VERBOSE, esse comando também pode ser utilizado em conjunto de qualquer tipo de VACUUM.

A execução coordenada do VACUUM e ANALYZE é essencial para manter atualizadas as estatísticas do banco de dados, possibilitando melhorar a performance nas pesquisas.

Autovacuum do PostgreSQL

Embora seja uma ferramenta opcional, é fortemente recomendado que esse processo nunca seja desativado em seu banco de dados. Essa funcionalidade, executada automaticamente pelo sistema gerenciador do PostgreSQL, realiza as operações de VACUUM e ANALYZE em segundo plano. O controle desse processo é realizado através dos valores definidos nos parâmetros de configuração.

O Autovacuum é nativo do PostgreSQL, permitindo a configuração para que o próprio banco execute o VACUUM simples (sem o FULL). É indicado para monitorar picos inesperados nas tabelas, devido às suas regras de verificação que determinam em quais tabelas as ações de limpeza devem ser executadas. Dessa forma se garante que todas tabelas (em todos os bancos de dados) que excedam estes valores sejam marcadas para o VACUUM. Esse processo conta com outros procedimentos integrados para seu funcionamento eficaz.

Existem outros tipos de VACUUM que você pode consultar aqui!

Entendendo as melhorias na atualização do PostgreSQL 16:

A partir desta versão, o VACUUM poderá ser utilizado ao fornecer apenas o nome do schema, possibilitando que a execução seja apenas nos objetos desse schema. Essa funcionalidade beneficia empresas que possuem uma organização de seus objetos agrupados por schema e têm a necessidade de realizar a manutenção desses objetos em conjunto.

Um exemplo desse cenário envolve clientes que usam o conceito de multi-tenancy baseado em schemas. Dessa forma, torna-se possível a execução da rotina de manutenção para clientes (schemas) de forma isolada, eliminando a necessidade de criação de recursos personalizados, como o uso de scripts ou blocos de código em pl/pgsql.

Outra implementação do VACUUM para a versão 16 é poder executar a rotina apenas para as tabelas TOAST. O comportamento padrão continua sendo a execução da rotina no objeto principal, o que é recomendado, mas agora há a opção de execução separada, caso necessário.

Dicas e Melhores Práticas

O VACUUM é um procedimento essencial para o desempenho ideal do PostgreSQL. Embora a configuração padrão do autovacuum venha habilitada seguindo métricas de valores globais, alguns cenários exigem que o seu uso seja ponderado ou que venha acompanhado da consultoria de um especialista DBA PostgreSQL. Alguns exemplos de cenários que exigem uma ação mais ponderada são: alto volume de alterações, cargas de dados, tamanho dos objetos, quantidade de tabelas, ou recursos disponíveis no servidor.

Não existe uma recomendação única de parametrização com valores exatos que atenda a todos os cenários. Cada caso é único, o que demanda um ajuste bem elaborado e contínuo. Nesse sentido, podemos ir de uma base com diversos problemas causados pela ausência do trabalho do autovacuum, causando impactos em todo o negócio, para uma situação que exige menos investimentos em infraestrutura e operações, aproveitando o melhor desempenho proporcionado por manutenções bem executadas.

Existem diversas estratégias para configuração e automatização da execução do VACUUM, mas a melhor abordagem é um ajuste customizado de autovacuum para cada tabela no seu banco de dados. Esses valores devem ser baseados em seu volume de alterações, tamanho da tabela, quantidade de recursos disponíveis, entre outras variáveis. Este é um trabalho contínuo que deve evoluir junto com o crescimento do banco de dados.

Como está o seu banco de dados? Já executou alguma operação de VACUUM? A Timbira pode te ajudar com uma consultoria especializada no PostgreSQL. Conte com o nosso time para ajudar o seu banco a performar e ser responsivo.

[Quero avaliar meu ambiente PostgreSQL]

[Quero falar com a Timbira]

A importância de ter uma versão do PostgreSQL atualizada

By Institucional No Comments

A necessidade de armazenar e gerenciar dados com segurança e de forma eficiente fomentou o surgimento dos bancos de dados relacionais. Esse é o caso do PostgreSQL, que surgiu nos anos 80 e vem ganhando espaço em diversas empresas de tamanhos e segmentos diferentes. Especialmente por ser um banco de dados open source e contar com uma comunidade bem ativa, que estuda, desenvolve, testa, corrige bugs e ainda ajuda fortemente a compartilhar versões atualizadas com frequência. Em setembro de 2023, o PostgreSQL Global Development Group anunciou a versão 16 que contou com diversas melhorias que você pode ver detalhadamente no site oficial postgresql.org.

Neste texto você poderá saber mais sobre a importância de manter um banco de dados atualizado. Falaremos sobre questões de segurança, alta disponibilidade, interação com outras aplicações e muito mais, confira.

Muitos gestores e profissionais de TI, às vezes por não estarem em contato direto com o banco, só percebem e entendem a importância dessa prática em situações de crise, que vão desde a perda de clientes por incompatibilidade de sistema, degradação dos dados, perda de performance ou uso excessivo de hardware, até a indisponibilidade da base de dados e ataques cibernéticos. Em suma, prejuízos financeiros e de imagem.

Vulnerabilidades de um Sistema Desatualizado

  • Processamento menos eficiente nas consultas dos dados
    As novas versões do PostgreSQL vêm com várias alterações para otimizar o motor de busca do banco de dados, podendo melhorar significativamente a performance de consultas de sua aplicação.
  • Problemas de compatibilidade
    Aplicações perdem a evolução de funcionalidades que permitiriam aumento de performance, correções de bugs e possibilidade de implementação de novas formas de acessar as informações dos bancos de dados.
  • Performance e brechas de segurança
    Constantemente lidamos com problemas de segurança e estar com uma versão desatualizada aumenta o risco de existirem bugs.

Portanto, questões de segurança, compatibilidade com demais aplicações, perda de performance e o uso excessivo de hardware (CPU) podem ser ocasionadas devido a um banco de dados desatualizado.

O Que Levar em Consideração Quando Buscar Atualizar a Versão do PostgreSQL

A partir do momento que o gestor percebe a necessidade de atualização da versão do seu banco de dados PostgreSQL, deve considerar:

  • No lado do cliente, a aplicação que irá consumir o banco de dados.
    Todos os softwares terão uma boa integração com o banco de dados? A consulta desses dados será performática nesse novo ambiente? Qual será o esforço humano diante das correções necessárias? Então, dependendo do modelo de negócio, esses fatores, somados ao custo benefício, devem ser pensados.
  • O servidor que irá hospedar o sistema, independente do sistema operacional.
    Durante o processo de migração, é crucial avaliar se o hardware atual pode acompanhar o crescimento do seu negócio, termo comumente referido no contexto de bancos de dados como “capacity planning”. O upgrade da versão do sistema operacional também desempenha um papel vital, trazendo consigo novas funcionalidades, melhorias de segurança e correções de bugs. Além disso, ajustes nas configurações do sistema operacional e do PostgreSQL são fundamentais para garantir o desempenho e a estabilidade do ambiente PostgreSQL.
  • A mudança de comportamento de alguns códigos, que pode alterar conforme a versão atualizada.
    Com a atualização de versão, alguns códigos já não produzem os mesmos efeitos de versões anteriores, podendo mudar a dinâmica do banco de dados.

5 motivos para você considerar uma migração para PostgreSQL 16

  1. Melhoria no controle de acesso e segurança
    O PostgreSQL 16 apresenta recursos avançados de segurança, incluindo atualizações nos protocolos de autenticação, controles de acesso (superusuário) e criptografia, assegurando dados seguros e íntegros.
  2. Melhorias de desempenho em consultas
    A última versão do PostgreSQL apresenta importantes melhorias no que tange desempenho, dando velocidade a consultas e operações de leitura. O desempenho aprimorado garante uma experiência fluida ao usuário.
  3. Melhoria no recurso de replicação lógica e monitoramento
    A partir do PostgreSQL 16, os usuários agora têm a capacidade de criar uma replicação lógica a partir de um servidor standby. Essa funcionalidade proporciona portabilidade na distribuição da carga de trabalho. Além disso, houve uma melhoria significativa no desempenho, possibilitando que os assinantes apliquem grandes transações em paralelo.
    Foi adicionada uma nova visão para o monitoramento de I/O, possibilitando um acompanhamento mais preciso da carga de trabalho e ajustes imediatos ao identificar pontos de gargalo. Também foi incluído um novo campo de data/hora na visão de estatísticas de tabela, permitindo verificar quando a tabela ou índice foi utilizado.
  4. Melhoria no suporte a JSON
    Os dados semi-estruturados continuam em uma crescente, e um bom exemplo é o JSON. A nova versão aprimora o suporte a esse formato, facilitando a integração e manipulação de dados complexos, facilitando assim o dia a dia do desenvolvedor que utiliza este recurso.
  5. Portabilidade e padronização
    A compatibilidade com os padrões SQL foram expandidas, com melhorias substanciais de desempenho. Nesse aspecto, os trabalhos de migrações são facilitados, assim como a promoção de operações conjuntas, possibilitando a portabilidade entre diferentes sistemas de gerenciamento de banco de dados.

Se você tiver curiosidade em saber sobre os bugs e alterações de uma versão para outra do PostgreSQL, acesse o site “Why upgrade PostgreSQL?”.Lá você pode inserir o número da versão anterior e comparar com uma versão atual, analisando as marcações em vermelho, que são bugs que foram corrigidos. Você vai notar que muita coisa mudou!

Todo processo de migração, especialmente em bancos em produção, é um trabalho delicado, que requer muita atenção e conhecimento. Se você precisa de ajuda no processo de planejamento, organização e implementação de uma migração segura, entre em contato com nosso time de atendimento. O futuro de sua empresa pode depender disso.

[Quero falar com a Timbira]

Computer Security Day: Você está protegendo seu Banco de Dados PostgreSQL?

By Institucional No Comments

Sistemas de gerenciamento de bancos de dados desempenham um papel muito importante em empresas e organizações. Para os usuários do PostgreSQL, a segurança dos dados é de suma importância. Em 30 de novembro, comemoramos o Computer Security Day, um lembrete de que a cibersegurança é um ponto fundamental em nossa jornada com o PostgreSQL. Neste artigo, vamos explorar a importância deste dia e discutiremos estratégias para proteger nossos dados ao usar o PostgreSQL.

Por que o Computer Security Day é importante para usuários do PostgreSQL?

Os usuários do PostgreSQL têm um motivo adicional para se dedicarem às melhores práticas de segurança. Este sistema de gerenciamento de banco de dados de código aberto é reconhecido por sua flexibilidade e robustez, o que o torna atrativo para uma variedade de  aplicações em organizações de todos os portes. No entanto, essa popularidade também o torna um alvo potencial para ameaças cibernéticas.

À medida que confiamos, informações importantes, sistemas essenciais e  dados críticos ao PostgreSQL, se torna muito importante garantir a segurança desses ativos, destacando a necessidade de medidas proativas para proteger nossos bancos de dados contra ameaças virtuais em constante evolução.

Dicas para Fortalecer a Segurança no PostgreSQL:

  • Senhas Fortes:  O PostgreSQL requer senhas sólidas para garantir o acesso seguro aos dados. Utilize senhas complexas e únicas para suas contas e, sempre que possível, implemente autenticação de dois fatores.
  • Atualização de segurança do sistema operacional: Mantenha o sistema operacional atualizado com as últimas correções de segurança para proteger o seu  ambiente do PostgreSQL.
  • Firewalls : Implemente firewalls e controle de acesso rigorosos para restringir quem pode se conectar ao banco de dados.
  • Controle de Acesso:  Evite  criar usuários com perfil de superusuário. Defina políticas de acesso com base no “princípio do privilégio mínimo”, garantindo que apenas usuários autorizados possam acessar e modificar os dados.
  • Conexões seguras: Utilize métodos seguros de conexão, como SSL/TLS, para estabelecer uma comunicação criptografada entre o cliente e o servidor.
  • Auditoria de Dados:  Ative auditorias de dados no PostgreSQL para monitorar atividades suspeitas e identificar evidências de acesso não autorizado.
  • Backup e Recuperação: Faça backups regulares de seus dados no PostgreSQL e tenha planos de recuperação em caso de incidentes de segurança. Teste constantemente seus planos de recuperação para garantir que eles funcionarão no momento em que precisarem ser aplicados.
  • Registros de eventos: Desenvolva constantemente o monitoramento dos registros do Postgres em busca de algo suspeito, fora do comum, e atue nessas correções o quanto antes. Busque identificar comportamentos fora do padrão, erros que começaram a ocorrer numa frequência fora do convencional.
  • Treine pessoas: Planeje treinamentos e mantenha seu time sempre atualizado, promovendo a conscientização sobre as práticas de segurança e destacando o valor dos dados para a sua empresa.

Responsabilidade Compartilhada:

Lembre-se de que a segurança cibernética é uma responsabilidade compartilhada. Tanto os administradores do PostgreSQL quanto os usuários finais desempenham um papel essencial na manutenção de um ambiente seguro. À medida que continuamos a utilizar o PostgreSQL como nossa escolha de sistema de gerenciamento de banco de dados, é essencial que também façamos da segurança cibernética uma prioridade

O Computer Security Day nos lembra que a segurança de nossos dados no PostgreSQL é uma tarefa constante. Proteger nosso mundo digital é um investimento valioso para o futuro de nossas operações de banco de dados. Nunca subestime o valor das medidas de segurança cibernética eficazes, pois elas podem ajudar a manter os dados seguros e a garantir o desempenho confiável do seu Banco de Dados PostgreSQL.

Se você precisar de ajuda para avaliar a segurança do seu ambiente e promover melhorias, conte conosco. Temos um time multidisciplinar preparado, incluindo uma engenharia dedicada com anos de experiência no uso do PostgreSQL.

Quero avaliar meu ambiente PostgreSQL

Quero falar com a Timbira

Meu PostgreSQL não conecta, Paulo Vitor Cabral – PGConf.Brasil 2022

By Eventos No Comments

É bastante comum que desenvolvedores, tanto iniciantes quanto alguns mais experientes, enfrentem desafios ao tentar conectar suas aplicações ao PostgreSQL. Durante sua apresentação no evento PGConf.Brasil 2022, o consultor da Timbira, Paulo Vitor Cabral, explorou as situações mais recorrentes de falhas de conexão no PostgreSQL e ofereceu soluções em sua palestra “Meu PostgreSQL não conecta”.

Nesta palestra, foram abordados os seguintes tópicos:

  1. Formas de conexão
  2. Casos comuns de falha de conexão
  3. O que verificar?
  4. Como verificar?
  5. Bônus

Transcrição:

É bem chato quando queremos aprender alguma nova tecnologia e nos deparamos com algumas barreiras que atrasam nossa evolução. Isso acontece porque geralmente não iniciamos nosso aprendizado buscando informações na documentação oficial, mas sim, testando na prática a utilização desta tecnologia. E com o PostgreSQL não é diferente.

1- Formas de conexão

Existem duas formas de conexão ao PostgreSQL:

1- Socket: É um arquivo Unix com uma porta associada a ele

2- Host: Uma conexão via protocolo TCP/IP

2- Casos comuns de falhas de conexão

Falha de conexão ao socket:

> $ psql -d pgconfbr2022 -U elefante

psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory

        Is the server running locally and accepting connections on that socket?

Falha de autenticação no pg_hba.conf

> $ psql -h 150.xxx.xxx.5 -d pgconfbr2022 -U elefante

psql: error: connection to server at "150.xxx.xxx.5", port 5432 failed: FATAL:  no pg_hba.conf entry for host "186.xxx.xxx.179", user "elefante", database "pgconfbr2022", SSL encryption

connection to server at "150.xxx.xxx.5", port 5432 failed: FATAL:  no pg_hba.conf entry for host "186.xxx.xxx.179", user "elefante", database "pgconfbr2022", no encryption

Falha de autenticação via peer

ubuntu@lab01:~$ psql -p 5432 -d postgres -U postgres

psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  Peer authentication failed for user "postgres"

3- O que devemos verificar?

Devemos fazer um “troubleshooting ” para identificar o possível ponto de falha na conexão ao cluster. Podemos fazer isso com algumas verificações:

– Serviço do PostgreSQL

– parâmetro listen_addresses

– Porta

– pg_hba.conf

4- Como devemos verificar?

Podemos verificar diretamente nos processos se o serviço do PostgreSQL está sendo executado.

Exemplos:

postgres@lab01:~$ pgrep postgres -fa

8125 /usr/lib/postgresql/14/bin/postgres -D /var/lib/postgresql/14/main -c config_file=/etc/postgresql/14/main/postgresql.conf

8126 postgres: 14/main: logger

8128 postgres: 14/main: checkpointer

8129 postgres: 14/main: background writer

8130 postgres: 14/main: walwriter

8131 postgres: 14/main: autovacuum launcher

8132 postgres: 14/main: stats collector

8133 postgres: 14/main: logical replication launcher


Gerenciador de tarefas do Windows:


Utilitário ps no linux:

>~$ ps -fax | grep postgres

    994 ?        Ss     0:04 /usr/lib/postgresql/14/bin/postgres -D /var/lib/postgresql/14/main -c config_file=/etc/postgresql/14/main/postgresql.conf

   1029 ?        Ss     0:00  \_ postgres: 14/main: logger

   1031 ?        Ss     0:00  \_ postgres: 14/main: checkpointer

   1032 ?        Ss     0:00  \_ postgres: 14/main: background writer

   1033 ?        Ss     0:00  \_ postgres: 14/main: walwriter

   1034 ?        Ss     0:00  \_ postgres: 14/main: autovacuum launcher

   1035 ?        Ss     0:01  \_ postgres: 14/main: stats collector

   1036 ?        Ss     0:00  \_ postgres: 14/main: logical replication launcher

Via systemctl:

>~$ systemctl status postgresql
  •  postgresql.service - PostgreSQL RDBMS
     Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)

     Active: active (exited) since Sat 2022-08-20 20:51:09 UTC; 17h ago

    Process: 1097 ExecStart=/bin/true (code=exited, status=0/SUCCESS)

   Main PID: 1097 (code=exited, status=0/SUCCESS)

        CPU: 3ms

Aug 20 20:51:09 lab01 systemd[1]: Starting PostgreSQL RDBMS...

Aug 20 20:51:09 lab01 systemd[1]: Finished PostgreSQL RDBMS. 

Parâmetro listen_addresses

É possível colocarmos um endereço IP ou uma faixa de endereços que o PostgreSQL “escutará” ao subirmos o serviço.

No `listen_addresses` podemos definir as seguintes opções:

– hostname

– IPv4/IPv6

– 0.0.0.0

– ::

– *

Obs.: se ele estiver vazio (default), somente conexões locais serão aceitas.

Exemplos:

- `listen_addresses = '*'`


[2022-08-20 08:28:43 UTC]    LOG:  00000: listening on IPv4 address "0.0.0.0", port 5432

[2022-08-20 08:28:43 UTC]    LOG:  00000: listening on IPv6 address "::", port 5432

[2022-08-20 08:28:43 UTC]    LOG:  00000: listening on Unix socket "/tmp/.s.PGSQL.5432"

[2022-08-20 08:28:43 UTC]    LOG:  00000: database system was shut down at 2022-08-20 08:28:43 UTC

[2022-08-20 08:28:43 UTC]    LOG:  00000: database system is ready to accept connections


- `listen_addresses = '127.0.0.1,*'`


[2022-08-20 09:13:42 UTC]    LOG:  00000: listening on IPv4 address "127.0.0.1", port 5432

[2022-08-20 09:13:42 UTC]    LOG:  XX000: could not bind IPv4 address "0.0.0.0": Address already in use

[2022-08-20 09:13:42 UTC]    HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.

[2022-08-20 09:13:42 UTC]    LOG:  00000: listening on IPv6 address "::", port 5432

[2022-08-20 09:13:42 UTC]    LOG:  00000: listening on Unix socket "/tmp/.s.PGSQL.5432"

[2022-08-20 09:13:42 UTC]    LOG:  00000: database system was shut down at 2022-08-20 09:13:42 UTC

[2022-08-20 09:13:42 UTC]    LOG:  00000: database system is ready to accept connections
  • Referências: https://pgpedia.info/l/listen_addresses.html, https://www.postgresql.org/docs/current/runtime-config-connection.html

Porta

Via host ou socket a conexão deve passar por uma porta. O padrão é 5432. Devemos investigar a porta em que o serviço do PostgreSQL estará em execução.

>~$ sudo ss -nltp | grep LISTEN

LISTEN   0        244            127.0.0.1:5432          0.0.0.0:*      users:(("postgres",pid=3466,fd=5))

pg_hba.conf

É um arquivo de configuração do PostgreSQL responsável por definir as regras de autenticação no cluster utilizando os filtros de:

– Usuário

– Database

– Host

– Forma de autenticação

Obs.: hba = host-based authentication

Cada linha no pg_hba.conf é um registro e é respeitada uma hierarquia do início para o fim do arquivo.

Exemplos:

  # TYPE  DATABASE        USER            ADDRESS                 METHOD

# Aceitar conexões locais do usuário elefante no database pgconfbr2022, sem senha

host    pgconfbr2022    elefante        127.0.0.1/32            trust

# Aceitar conexões para o grupo elefante e usuários com GRANT dele, de determinado IP em todos os databases, com senha

host    all       +elefante       187.131.242.37/32       md5

# Aceitar conexões para databases provenientes do arquivo $PGDATA/financeiro a partir do usuário postgres, de um certo domínio e com senha 

host    @financeiro     postgres        .elefante.com     scram-sha-256

No PostgreSQL

sql

SELECT * FROM pg_hba_file_rules;

5- Bônus

– Guia de troubleshooting: https://mydbanotebook.org/post/cant-connect/ 

– Seguir o diagrama com as orientações descritas ali

 

Referências:

Protegendo seu Patrimônio Digital: quanto custa não ter um backup?

By Institucional No Comments

No universo empresarial, a informação é poder. Cada dado, transação e histórico representam um capital valioso que impulsiona o sucesso dos negócios. Mas, imagine um cenário onde todo esse patrimônio digital, construído com esforço e dedicação, desaparece em um instante. Não é apenas uma hipótese distante, é uma realidade dura que empresas podem enfrentar quando não investem em uma estratégia de backup robusta.

Armazenamento, segurança de dados e backup são assuntos muito sérios. Seja qual for o tamanho da empresa, é necessário existir um plano para manter os dados seguros e diminuir o risco. Buscar hospedagens seguras e sigilosas e estar atento aos processos de backup são práticas que garantem a continuidade de um negócio em cenários de crise.

Neste artigo, vamos explorar os custos implícitos de não investir em backups adequados, desde a quebra de confiança com os clientes até as implicações legais. Mais importante ainda, oferecemos insights sobre como uma abordagem proativa pode resguardar sua empresa e proteger seu futuro digital. Vamos adentrar ao mundo vital da segurança de dados e entender por que o backup é mais do que uma precaução – é um alicerce essencial para um futuro empresarial próspero.

Consequências da Perda de Dados

O que acontece com a sua empresa se todos os seus dados forem perdidos? Todas as vendas em andamento, todos os cadastros de clientes, todos os produtos cadastrados… Perder dados e não ter backup é uma dor de cabeça que negócio algum quer passar.

Por aqui, já testemunhamos situações em que uma falha de hardware resultou na perda completa do banco de dados, sem a existência de um backup, o que culminou na perda de dados do cliente. Também enfrentamos problemas de corrupção de dados e estrutura no PostgreSQL, contando apenas com um backup em formato de dump. Felizmente, o dump era do dia anterior e a perda foi minimizada. Além disso, houve uma situação de atendimento emergencial às vésperas do Natal, quando o banco de dados estava corrompido e irreparável (o backup não pôde ser restaurado). Nesse caso, conseguimos recuperar os dados de alguns dias antes. Em todos esses cenários, uma política de backup e restauração eficaz teria feito uma diferença significativa.

A perda de dados vai além de uma simples ocorrência técnica; é uma potencial ameaça à reputação, à continuidade e, em última instância, à própria existência da empresa. A perda de informações importantes pode se transformar em um arriscado problema para gestores e líderes de equipes. Você consegue imaginar o custo desses cenários?

1) Custos Financeiros Diretos

Se informações importantes para o funcionamento da empresa se perdem, o risco é de parada total. Não estamos falando apenas de números no balanço. Estamos falando do pulso financeiro da sua empresa. E, nesse cenário, a perda de dados não é apenas uma questão de perder informações; é uma pancada nos seus lucros. Imagine a paralisação das operações, a perda de receita e até mesmo a falência em casos extremos. No mundo acelerado dos negócios, onde cada segundo conta, qualquer interrupção pode gerar um impacto significativo. Os custos diretos dessa falha podem ser devastadores.

2) Quebra de Confiança e Danos à Imagem

Imagine um baque forte na relação de confiança com seus clientes e parceiros comerciais. A perda de dados, mesmo sob esforços contínuos, pode abalar a confiança que sua empresa tão cuidadosamente cultivou. Não é apenas uma preocupação financeira, é uma questão de reputação. Afinal, no cenário competitivo atual, um deslize pode enviar seus clientes diretamente para as portas da concorrência, em busca de um abrigo mais seguro e confiável.

3) Questões Legais

A perda ou vazamento de informações sensíveis podem levar a implicações legais sérias. Dependendo da natureza dos dados perdidos, a empresa pode enfrentar ações judiciais e ser responsabilizada por danos financeiros. Se informações financeiras de clientes forem perdidas, a empresa pode enfrentar processos judiciais e multas regulatórias. Atualmente está em vigência no Brasil a Lei Geral de Proteção de Dados (LGPD), que estipula regramentos para o trato e finalidade dos dados coletados.  Descumprir essas normas pode resultar em processos judiciais e multas consideráveis. Proteger os dados não é apenas um imperativo ético, é uma necessidade legal.

4) Dificuldades na Recuperação

Recuperar dados perdidos é como tentar juntar os pedaços de um quebra-cabeça complexo. É uma corrida contra o tempo e a incerteza. Muitas vezes, pode ser necessário fazer a contratação emergencial de especialistas em recuperação de dados, compra de equipamentos especializados, além de um grande investimento de tempo. E mesmo que os dados possam ser recuperados, o processo pode levar dias ou semanas, deixando a empresa em tempo de inatividade e atrapalhando as operações. Cada momento perdido pode custar caro. A recuperação é uma batalha, e às vezes, infelizmente, pode não trazer de volta tudo o que se deseja. A precaução é a chave para evitar esse cenário desafiador.

A Importância do Backup Adequado

Em um mundo imperfeito, onde contratempos são inevitáveis, ter uma arquitetura robusta para a segurança de seus dados é essencial. Isso implica não apenas na capacidade de prevenir a perda de dados, mas de recuperar seu ambiente até o ponto de falha. Um dos métodos de backup mais utilizados é o backup com recuperação em um ponto no tempo, conhecido como PITR (point in time recovery), associado a uma estrutura de alta disponibilidade que garante a segurança de suas informações em níveis de serviço. Sabemos que manter uma arquitetura desse calibre envolve custos, mas vale a pergunta: quanto custaria perder tudo?

Backup com Recuperação em um Ponto no Tempo (PITR)

Imagine poder retroceder no tempo e resgatar seus dados até um momento específico. Essa capacidade é fundamental para minimizar perdas em caso de falha. Para situações em que um backup completo não é necessário e nem todas as informações são críticas para a continuidade do negócio, ferramentas como pg_dump (cópia lógica) podem ser utilizadas. Embora um backup completo possa ser dispendioso, o mínimo que se pode fazer para garantir a integridade do modelo de negócio e a saúde do banco de dados é possuir um PITR eficaz.

Estrutura de Alta Disponibilidade

A chave para manter suas operações em andamento, sem impactos negativos, mesmo diante de falhas, é uma infraestrutura de alta disponibilidade. Essa estrutura assegura um backup em nível de serviço, proporcionando flexibilidade e resiliência. Investir na Cloud para gerenciar sua base de dados pode ser uma opção econômica, reduzindo custos em energia elétrica e infraestrutura de equipamentos, além de oferecer planos mensais adaptáveis ao seu orçamento, pagando apenas pelo espaço utilizado.

O Custo de Não Investir em Backup

Seja sua base de dados híbrida ou on-premise, já vimos que negligenciar investimentos em sistemas de backup e manter cópias atualizadas dos dados pode resultar em custos exorbitantes. A perda de dados pode impactar a reputação da empresa, sua receita e, em última instância, sua própria existência.

Investir em sistemas de backup e manter uma estrutura de segurança de dados vai além de uma despesa; é um investimento vital para a continuidade dos negócios. A perda de dados não é apenas um contratempo técnico, mas sim uma ameaça real à integridade e sobrevivência da empresa. Portanto, a resposta à pergunta “Quanto custa não ter um backup?” é simples: pode custar tudo.

Se você precisa de ajuda no processo de planejamento, organização e implementação de um backup sólido e eficaz, entre em contato com nosso time de atendimento. O futuro de sua empresa pode depender disso.

Quero avaliar meu ambiente PostgreSQL

Entre em contato pelo WhatsApp

Seu ambiente PostgreSQL está preparado para datas comemorativas importantes?

By Institucional No Comments

Alguns eventos são ótimas oportunidades para empresas consolidarem sua marca e aumentarem seu ticket médio. A Black Friday e o Dia Sem Imposto são datas que movimentam o comércio, e, por isso, aumentam a quantidade de acessos a aplicações e a bases de dados. Seu ambiente Postgres está preparado?

Em um levantamento feito com os clientes da Timbira, foi constatado que, para a maioria das empresas, o evento mais importante do ano é a Black Friday, que ocorre ao final do mês de novembro. Algumas empresas aproveitam para fazer a promoção no mês inteiro, a chamada “Black November”. Em seguida na lista de eventos importantes também temos Natal, Ano Novo e Cyber Monday. 

Esses eventos aumentam as demandas de acessos no banco de dados e, por consequência, o volume de transações. Isso pode gerar grandes dores de cabeça para as equipes que não se preparam previamente. 

Separamos algumas situações comuns que podem acontecer durante estes períodos e sugerimos algumas ações que podem ajudar a diminuir riscos.

1) Backup: O backup da base de dados é essencial porque ajuda a prevenir a perda de dados no caso de uma falha no sistema, erro humano ou ataque cibernético. Um exemplo foi a situação que aconteceu em 11 de setembro de 2001, onde muitas empresas que atuavam nas Torres Gêmeas tinham site backup, entretanto estavam localizados na outra torre ou em áreas afetadas pela destruição nas proximidades. Essas organizações perderam os dois sites e toda sua informação. Do ponto de vista da informação, isso afetou não só a vida de inúmeros clientes que dependiam desses dados, como também a continuidade do negócio de muitas empresas. A partir desse evento, toda a política de segurança cibernética foi repensada e ganhou força o uso das clouds

Um backup bem-sucedido permite a recuperação e restauração rápida dos dados, minimizando assim o tempo de inatividade e a interrupção das atividades de negócios. Investir em sistemas de backup e manter cópias atualizadas dos dados é fundamental para proteger a integridade da empresa e garantir sua continuidade. Afinal, a perda de dados pode ter consequências graves, podendo impactar sua assistência, receita e até mesmo a sua existência. Já imaginou se amanhã seu banco de dados some? O que acontece com a sua empresa?

2) Resiliência: Um risco muito comum é o serviço de banco de dados não suportar um número excessivo de acessos simultâneos. E as causas que podem gerar indisponibilidade em situações como esta são inúmeras: podem ser ajustes finos que não foram feitos no PostgreSQL, uma query mal estruturada, um sistema operacional desatualizado (assim como o próprio PG) e até mesmo problemas de cluster. Para garantir que a sua base de dados tenha resiliência, vários aspectos devem ser analisados e alinhados, como o sistema de backup (pode ser cloud, híbrido, on-premise), questões de acesso à Internet (se o sistema for on-premise é indicado duas empresas de telefonia acessíveis, assim como um sistema de blackout e, se possível, uma cópia em nuvem), questões de infraestrutura de redes, entre outros.

Uma dica bacana para quem não sabe por onde começar é fazer um trabalho de análise e monitoramento do ambiente PostgreSQL. Assim será possível aplicar melhorias como  ajustes de configurações de banco, melhoria em consultas lentas, identificar necessidade de índices que ajudam no desempenho, entre outras situações que podem deixar seu banco rodando muito melhor.

3) Segurança: O fator segurança sempre deve ser levado em consideração, tanto em relação a acessos internos quanto externos. Os níveis de segurança devem ser tratados em camadas, conforme o modelo de negócio de cada cliente. Muitos centralizam o controle de quem acessa a base de dados através de um “superusuário administrador”. Não é incomum, no entanto, vazar informações e ocorrer a exposição de dados sensíveis. É importante avaliar quem deve ter acesso no seu time, o responsável em monitorar esses acessos e a possibilidade de rastrear os acessos para minimizar o risco de erros.

Independentemente da estratégia adotada, a Lei Geral de Proteção de Dados (LGPD), promulgada em 2018, defende vários aspectos da segurança e o trato com as informações coletadas de terceiros. O vazamento de dados confidenciais de clientes podem gerar multas milionárias, processos e desgaste da imagem e credibilidade da empresa. A maioria das empresas já exigem adequações à LGPD em seus contratos. Portanto, é fundamental se pensar na segurança da informação em vários níveis. 

4) Consultas Lentas: Um dos problemas mais comuns quando falamos em banco de dados é lentidão. Não é novidade que isso pode ser causado por uma série de fatores, desde mal configuração do PostgreSQL, um mal planejamento das ferramentas de extensão para uso de tabelas, falta de índices, consultas mal escritas, um cluster que não suporta o número de acessos, entre outros. Em muitos casos, torna-se desafiador encontrar e solucionar problemas de lentidão.

Existem algumas ferramentas e métodos de investigação que ajudam na análise e melhorias de consultas existentes ou mesmo no desenvolvimento de novas consultas. O primeiro passo nesse desafio é encontrar ferramentas que ajudem a apontar as piores consultas, aquelas que são as principais ofensoras do desempenho. 

Uma boa ferramenta é a extensão pg_stat_statements, que faz parte do conjunto de módulos adicionais que vem com o Postgres. Com uma simples instalação do pacote contrib do PostgreSQL e um CREATE EXTENSION, esta extensão já começa a apresentar seu valor. Você pode conferir uma lista das consultas que mais executam, o tempo de execução dessas consultas, quantas vezes cada uma executou e, em versões mais recentes, até mesmo o quanto cada uma consumiu de recursos de escrita e leitura. Acompanhar essas informações e avaliar de forma frequente as consultas listadas por essa ferramenta é uma boa abordagem para identificar e atuar na melhoria destas consultas.

5) Inchaço de tabelas: O inchaço de tabelas é outro problema que impacta diretamente na performance do banco de dados. Uma tabela inchada desperdiça espaço em disco, eleva o tempo de restore de um backup físico, consome mais memória  e torna as consultas mais lentas. 

Para controlar o inchaço e garantir melhor desempenho do seu banco de dados, o postgreSQL possui um processo chamado autovacuum. Ele é responsável por varrer todas as tabelas e, com base em parametrizações, identificar quais precisam ser limpas. Durante a limpeza, ele marca o registro “morto” como reutilizável e atualiza as estatísticas do objeto, tornando o planejador mais eficiente na hora de montar um plano para executar consultas. A configuração padrão atende de forma satisfatória a pequenos ambientes.

No entanto, em ambientes críticos e de alto volume transacional, é necessário otimizar essa configuração para que ele seja mais eficaz, garantindo um melhor desempenho para o seu ambiente. Em alguns casos, mesmo com o autovacuum otimizado, pode ocorrer inchaço das tabelas e índices. Para garantir que o ambiente esteja saudável, é necessário monitorar e identificar objetos que precisam de manutenção e, por fim, fazer uso do pg_repack para eliminar o inchaço dos objetos. O pg_repack é muito útil, pois possui o mínimo de bloqueio possível e garante a limpeza das tabelas e índices sem gerar indisponibilidade do banco de dados. 

O melhor conselho que podemos dar é que você invista em um planejamento prévio para o seu ambiente PostgreSQL, não só para datas importantes, mas com a visão de futuro de crescimento e de sustentabilidade do seu ambiente. Assim seu negócio, suas vendas e sua marca não sofrem com sobrecarga, instabilidades e gastos não previstos com atendimentos emergenciais. E, se precisar de ajuda, podemos ser seus parceiros para analisar seu ambiente e promover melhorias com nossa metodologia única de Health Check.

Quero avaliar meu ambiente PostgreSQL.
Fale com a gente pelo WhatsApp.

Qual a diferença entre Body Shop, Outsourcing e Consultoria?

By Institucional No Comments

Algumas empresas não possuem a expertise necessária para a resolução de determinados assuntos. Neste cenário onde falta mão de obra qualificada, pode ser vantajoso pensar na contratação de profissionais com conhecimento específico, para dar apoio à equipe. Algumas modalidades, como Outsourcing, Body Shop e Consultoria, são opções interessantes e que diferem do modelo convencional de contratação. Neste post você conhecerá um pouco mais sobre cada um desses modelos.  

O que é Body Shop?

O modelo Body Shop é conhecido na área da tecnologia como uma terceirização de profissionais externos ao time da empresa. Isso significa que os profissionais estarão sob a gestão e backlog da empresa contratante durante o tempo determinado em contrato. No entanto, não há vínculo empregatício com quem os contrata. Em outras palavras, é como um aluguel da mão de obra que a contratante necessita no momento.

É ideal para atividades pontuais, uma vez que os contratos possuem prazos bem definidos. Na prática, a empresa contrata apenas a mão de obra com habilidades específicas, mas não conta com toda a organização que uma área (ou time) precisa.

O que é Outsourcing?

O Outsourcing também é uma forma de terceirização de serviços. Dentro desta modalidade o foco é uma parceria da contratante com empresas terceirizadas e especializadas nos serviços que são ausentes dentro de casa. De forma simples, uma empresa contrata uma outra empresa para complementar seus serviços a um custo menor e podendo ter maior qualidade. 

Ao contrário do Body Shop, os contratos de outsourcing têm escopo de trabalho aberto. Nesta modalidade, todo um time é contratado, sendo da empresa contratada a responsabilidade pela gestão das pessoas envolvidas.

O que é Consultoria?

Nesta modalidade a empresa contratante também pode contar com empresas terceirizadas e especializadas, que além de fornecer mão de obra especializada, em determinados assuntos ausentes dentro de casa, farão a gestão de todos os processos.

A distinção da Consultoria se dá por ser um serviço prestado por especialistas, mas também pelo fato de existir um time envolvido em todo o projeto. Uma consultoria visa ajudar seus clientes a entender como usar recursos e serviços de maneira mais eficiente e eficaz, a fim de reduzir custos no futuro, aumentar a eficiência e permitir que a empresa se concentre em suas atividades-chave para atingir os objetivos do negócio da melhor forma possível. Isso pode incluir estratégias de segurança de dados, arquitetura de sistemas, otimização de desempenho de banco de dados e muito mais.

Uma vantagem do modelo de Consultoria é que os consultores contratados podem fornecer orientação estratégica, ajudar a desenvolver projetos específicos, treinar funcionários e também oferecer suporte técnico.

Qual modelo escolher?

Bom, agora que você já sabe resumidamente como cada modelo funciona, você deve estar se perguntando qual a melhor opção para o seu negócio, certo? 

Achamos importante frisar que cada caso é um caso, então a melhor opção depende muito do que a empresa contratante está efetivamente precisando no momento. Entendemos que optar por modelos de consultoria ou outsourcing acabam por ser as melhores alternativas para a  maioria dos cenários. 

Em ambos os modelos, cabe a você apenas contratar e passar as demandas, já que todo o resto fica por conta da empresa contratada. O outsourcing é mais voltado para a execução de tarefas específicas, ou seja o modo ‘’mão na massa’’. Enquanto a consultoria, além de colocar a mão na massa, vai ajudar uma empresa a entender como usar recursos de forma mais efetiva e pontuar formas de trabalho, para que no futuro essa empresa seja cada vez mais independente neste sentido. 

Já deu para ver que apesar de parecerem semelhantes, essas modalidades têm suas diferenças não é mesmo? Mas se se você analisar bem, com certeza saberá o que é melhor para a sua empresa!

Você pode contar com a Timbira!

A contratação de um time de apoio de forma remota, pode gerar uma certa insegurança, principalmente porque os maiores ativos de uma empresa são tempo e dados. Aqui na Timbira entendemos isto e temos todo o cuidado para que a parceria com nossos clientes seja sempre estável e sem surpresas. 

Procuramos manter uma comunicação clara e transparente, por isso os clientes sempre terão um ponto focal no nosso time de Engenharia, onde podem trazer suas demandas e fazer o plano de ações juntos. Mas também vão contar com a nossa Gerente de Sucesso do Cliente, que trabalha na área do Relacionamento com o Cliente para garantir que haja proximidade constante, sem barreiras de comunicação entre os times. Somos uma empresa de inteligência em PostgreSQL, nesse sentido você pode contar conosco para promover sustentabilidade ao seu ambiente, dando apoio estratégico, tático e operacional e mais autonomia para a visão do seu negócio. Como diz Steve Jobs, “Concentre-se naquilo que você é bom e delegue todo o resto”.

Se você está precisando de  profissionais especializados em PostgreSQL, entre em contato conosco!

>> Nos envie uma mensagem no Whatsapp! <<

Computer Security Day

By Institucional No Comments

Proteja o seu Banco de Dados PostgreSQL

Segurança é um tema que só quem tem experiência se preocupa. Neste caso, experiência significa que você já foi invadido um dia. E a pergunta nunca é se você será invadido, mas quando. Um cliente me pediu um resumo rápido das medidas de segurança para proteger o seu PostgreSQL. Comecei a enumerar e achei melhor escrever aqui, uma vez que é um assunto que está tirando o sono de muita gente.

RTFM

Saiba o que está fazendo, leia a documentação oficial e não apenas em blogs e vídeos no YouTube! Veja se a documentação que você está lendo se refere a versão correta do software que você está utilizando.

Proteja o seu servidor

Instalação do servidor: menos é mais

Instale somente o necessário. Crie um servidor dedicado apenas com o essencial. Tudo que não for absolutamente necessário deve ser removido. Isso inclui serviços de compartilhamento de arquivos, impressão e até a interface gráfica… mesmo que o seu servidor seja em Windows. Além de economizar um pouco de espaço em disco, economizar CPU e memória você abre um número menor de portas no seu servidor e tem menos softwares com possíveis falhas de segurança instalados.

Mantenha as atualizações de segurança em dia

Prefira sempre instalar o PostgreSQL empacotado ao invés de compilado. Se estiver utilizando uma distribuição Linux, use o repositório do PGDG. Se for uma distribuição que usa pacotes RPM, utilize o repositório YUM do PGDG, se for uma distribuição que utiliza pacotes DEB utilize o repositório APT do PGDG. Feito isso, faça atualizações de segurança do seu sistema operacional com frequência. Muitas invasões exploram falhas de segurança conhecidas e já corrigidas. Mas você precisa atualizar o seu Sistema Operacional (incluindo o PostgreSQL), senão o trabalho dos desenvolvedores para corrigir as falhas de segurança não adiantam nada.

Limite o acesso físico

Cuide do acesso físico ao servidor. Onde seu servidor fica? Lembre-se que qualquer pessoa que tenha acesso físico ao servidor pode para começar tirar ele da tomada… e pode até ser sem querer. Com um pouco de conhecimento a pessoa pode dar um boot num pen drive com um Linux qualquer e ter acesso TOTAL ao seu servidor e fazer o que ele quiser. Portanto, guarde seu servidor em um local seguro. E por mais que você tenha gastado muito dinheiro para compra-lo, não coloque ele numa vitrine para todos contemplarem ele. Servidores devem ficar numa sala escondida onde apenas quem precisa sabe onde fica e pode entrar lá. Trabalhei por anos na Itautec ao lado do CTO do Itaú. Ia jantar lá toda semana e nunca soube em que andar ficam os servidores.

Limite o acesso privilegiado remoto

Algumas pessoas provavelmente terão acesso remoto ao servidor. A primeira coisa a fazer é limitar o número de pessoas que vão ter acesso. Quem realmente precisa ter acesso à ele? A segunda é criar usuários únicos para cada uma delas no SO e dar uma senha diferente para cada uma delas. Rastreie a conexão das pessoas no servidor. Se cada um tiver um usuário diferente, você saberá quem se conectou quando. Não confie apenas em senhas para o acesso. Exija que os usuários tenham certificados para poder acessar o servidor.

Utilize conexões encriptadas com SSL

Se toda a informação da sua conexão trafegar pela rede pública sem encriptação…. toda a sua preocupação com segurança vai por água a baixo. Então se os seus dados não trafegam numa rede segura e isolada, configure no servidor e clientes para minimizar a chance ter seus dados roubados inadvertidamente, inclusive senhas. Veja na documentação como fazer isso e teste com calma antes de ativar conexões hostssl no pg_hba.conf

Proteja o IP do servidor

Seu servidor jamais deve ter um IP válido na Internet. Isso é um erro imperdoável. Para chegar ao servidor você deve primeiro acessar um servidor intermediário, através de um Firewall e ou uma VPN. Jamais deixe seu servidor exposto numa rede pública. O resultado é fatal.

Limite o acesso das aplicações

O PostgreSQL possui um mecanismo sofisticado e simples para filtrar as conexões antes de chegarem ao seu banco de dados. Ele se chama pg_hba.conf e possui um capítulo específico na documentação só sobre ele. LEIA. Se você utiliza alguns poucos servidores de aplicação, então você deve limitar o acesso a estes IPs específicos individualmente. Se você tem uma aplicação client/server, limite o acesso a uma faixa de IPs. Jamais libere tudo. Limite também qual usuário ou grupo pode utilizar qual base. Você pode utilizar também as opções sameuser se tiver uma base para cada cliente por exemplo. Se você tem uma aplicação client/server, pode optar também por utilizar uma autenticação via LDAP.

Cuide das suas senhas

Cuidar de senhas é uma baita dor de cabeça. O PostgreSQL oferece algumas ferramentas para te ajudar:

  • Senhas fáceis são um problema contra ataques de força bruta. O PostgreSQL possui o módulo do contrib chamado auth_delay para te ajudar a criar um atraso na autenticação, dificultando bastante ataques de força bruta. Não é algo muito elegante mas pode te ajudar se perceber que está sofrendo ataques desse tipo.
  • Outro módulo mais elegante é o uso do módulo passwordcheck. Este faz uma checagem automática toda vez que você criar um usuário com senha ou tentar alterar a senha. Se a senha for considerada fraca o comando dá erro e rejeita a senha. Ele tem um algorítimo próprio para definir as regras sobre o que é uma senha ruim. Você pode alterar o código fonte para mudar as regras se quiser.
  • Utilize outro método de autenticação que não MD5 ou SHA (o SCRAM-SHA-256 for introduzido no PostgreSQL a partir da versão 10). O PostgreSQL fornece varias alternativas como
    • GSSAPI
    • SSPI
    • Ident / Peer
    • LDAP
    • RADIU
    • Certificado SS

Privilégios: menos é mais

Você deve criar usuários separados para as suas aplicações e limitar o seu acesso:

  • Jamais, em hipótese alguma utilize um superusuário para a aplicação se conectar no banco de dados. Se alguém conseguir acesso ao banco de dados com um superusuário ele vai poder fazer qualquer coisa. E qualquer coisa não é algo nada divertido aqui.
  • Um usuário deve ser o dono dos seus objetos. Você vai utilizar este usuário apenas para o deploy. A aplicação jamais deve utilizar este usuário. O dono (owner) dos objetos pode criar e destruir qualquer objeto no banco de dados, logo, por uma questão de segurança, deve ficar protegido e longe da aplicação.
  • Se o usuário deve utilizar uma senha para entrar na aplicação e ele tiver uma senha no banco de dados, lembre-se que a senha do banco de dados não pode ser a mesma da aplicação. A coisa mais fácil que existe é o seu usuário instalar um client (pode até ser numa planilha via ODBC) e acessar diretamente o seu banco de dados com o usuário e senha dele. Adivinha o que pode acontecer se o seu usuário sair fazendo UPDATE e DELETE diretamente nas tabelas do sistema? Adicione um sufixo e um prefixo para o nome do usuário no banco de dados, faça a mesma coisa com a senha e depois embaralhe ela com um MD5 ou um SHA, depois crie o usuário no banco de dados. Quando for autenticar o usuário refaça a mesma operação todas as vezes. Não é um método muito seguro, mas ajuda a tirar os usuários comuns mal intencionados (como um funcionário comum que quer pedir demissão) de fazer um estrago.
  • Se todos os usuários da aplicação utilizam o mesmo usuário do banco de dados ou um pequeno grupo de usuários no banco de dados, você vai ter que guardar a senha deste usuário em algum lugar na máquina onde está a aplicação. Jamais guarde isso em um arquivo texto puro. Qualquer um que tiver acesso à máquina vai poder abrir este arquivo e fazer a festa no seu banco de dados. Você pode encriptar um arquivo com uma chave guardada dentro da aplicação. Também pode utilizar outros métodos de autenticação sem senha, utilizando certificados.
  • Como os usuários da aplicação no banco de dados não são donos dos objetos, você vai ter que conceder privilégios em cada tabela/função/visão/sequencia, etc individualmente. Antes de mais nada, dê uma olhada na documentação para aprender como isso funciona direito. Ajustar isso é um trabalho chato e tedioso. Ninguém gosta de fazer isso, mas precisa ser feito. E precisa ser feito no ambiente de desenvolvimento e homologação também. É terrível quando você faz um deploy na produção e a aplicação para de funcionar por falta de um simples GRANT. Isso acontece quando os testes foram feitos com um usuário com mais privilégios que o da produção. Tente dar apenas os privilégios extremamente necessários para cada usuário ou grupo de usuários (role). Se você nunca apaga registros de uma tabela, não dê um GRANT de DELETE nela. Fazer este ajuste fino em cada tabela pode levar muito tempo. As pessoas tendem a dar GRANT em tudo e apertar com bastante força o “botão do FODA-SE”! Resista a tentação. Se você tem centenas ou milhares de objetos para dar GRANT e não tem condições de revisar toda a sua aplicação para isso, revise pelo menos o acesso aos objetos mais sensíveis. A regra nesse caso é: “o cofre não pode ser mais caro que o ouro”. Então avalie o custo de acertar todos os privilégios um por um e avalie o custo de alguém apagar todos os dados em uma tabela com dados críticos.
  • Se você tem uma tabela com dados realmente importantes, você não deveria deixar a sua aplicação fazer SELECT, UPDATE, DELETE diretamente. Ao invés disso, crie visões (views) e funções que filtrem o acesso aos dados para você a sua aplicação. Assim você impede um UPDATE sem WHERE por exemplo ou o acesso à todas as linhas de uma tabela que tem restrições de privacidade.
  • Se você armazena dados realmente sensíveis como números de cartão de crédito (tenho medo de quem armazena esse tipo de coisa…) você deve encriptar as informações nestas colunas. O PostgreSQL tem um módulo do contrib chamado pgcrypto que faz isso. Não é algo trivial de se utilizar. Precisa gastar um tempo para entender como fazer isso. Mas é praticamente a única opção se você realmente precisa armazenar dados assim. Nem o seu DBA deve poder ver as informações nessas colunas!
  • Se você tem restrições severas a quais linhas de uma tabela o seu usuário pode acessar você pode utilizar o políticas de acesso em nível de linha. Não é algo tão complexo mas exige um pouco de planejamento para utilizar. A documentação tem alguns exemplos simples para lhe dar uma ideia de como funciona na prática.

Proteja a sua aplicação

O lado da aplicação é um lado frágil da corrente em termos de segurança. Você não pode evitar por exemplo que um servidor web fique exposto à uma rede pública como já fez com o banco de dados. Como está mais vulnerável você deve tomar uma serie de medidas para limitar o estrago o servidor onde a aplicação está seja comprometido. Então além de praticamente adotar os mesmos cuidados que utilizou no seu servidor de banco de dados, o lado da aplicação deve tomar cuidados adicionais.

Trilhas de auditoria

Uma forma importante de auditar quem mexeu no meu queijo e ter trilhas de auditoria em tabelas específicas. Saber quem alterou o que e quando é fácil e existem várias extensões prontas para fazer isso. Ou você também pode criar um gatilho para alimentar uma tabela de auditoria. Claro que você tem que proteger a tabela com os dados de auditoria e não dar GRANT para nenhum usuário dar DELETE ou UPDATE nela. Se o usuário da aplicação for o dono da tabela de auditoria então… melhor nem fazer.

SQL Injection

Este é um mal que afeta aplicações descuidadas, principalmente aquelas expostas na interntet. Existem zilhões de receitas prontas para invadir bancos de dados utilizando SQL Injection. E por incrível que pareça, as pessoas continuam caindo nisso! O assunto é um pouco extenso, mas tenho um artigo escrito especificamente sobre isso aqui. Veja que neste tipo de ataque, você não precisa explorar nenhuma vulnerabilidade do servidor, nem ter qualquer tipo de senha. O único elo frágil aqui é a sua aplicação. Então ou você aprende a escrever aplicações blindadas contra SQL Injection, ou você será invadido. Certeza.

Gere logs

Logs podem lhe ajudar a entender o que está acontecendo quando as coisas dão errado. Você pode sofrer uma invasão, perder dados e ser invadido novamente depois por não ter se protegido adequadamente. A única forma de entender o que aconteceu é gerar log no SO, na aplicação e no banco de dados. Gere logs sempre e aprenda a analisa-los de forma eficiente. Hoje temos uma infinidade de ferramentas para ajudar nisso. JUST DO IT!

Se tudo o mais falhar: Backup

Parece besteira, mas muita gente não tem a menor ideia de como fazer um backup direito num banco de dados e tem aplicações enormes rodando em produção sem jamais terem lido a documentação sobre isso. Só um detalhe importante: ter um standby não lhe protege contra perda de dados em caso de invasão. Se o invasor apagar os dados de uma tabela em produção, esta alteração vai ser propagada para o standby. Portanto, você NÃO PODE FICAR SEM BACKUP. E como eu já escrevi e repeti por aqui… Dump não é backup!!!

Fonte: https://www.savepoint.blog.br/2018/04/19/proteja-o-seu-banco-de-dados-postgresql/