O que fazemos · Dados e web: Upgrades de PHP e patching de segurança em toda a frota
Um PHP em fim de vida nunca recebe a correção para a próxima vulnerabilidade explorada. Movemos aplicações para PHP suportado sem as partir, e quando surge uma falha crítica colocamos a correção em todos os servidores que gerimos no próprio dia, um host de cada vez, com um rollback pronto em cada passo.
O que é
Dois serviços que partilham uma única disciplina:
- Upgrades planeados: mover uma aplicação de um ramo antigo do PHP para um suportado, incluindo software comercial protegido com encoders, em Linux simples, Plesk e cPanel com CloudLinux.
- Patching de emergência: quando é divulgada uma vulnerabilidade crítica do PHP, uma medida provisória à frente da sua aplicação dentro de uma hora, seguida do PHP corrigido distribuído por toda a frota assim que exista.
Como o construímos
Lado a lado, nunca por cima. A nova versão do PHP é instalada ao lado da antiga. O cutover é uma única alteração reversível do socket ou pool FastCGI, e a versão antiga continua a correr como caminho de rollback até passar um período de burn-in limpo.
Prova antes do salto. Antes de um upgrade maior, fazemos compile check a cada ficheiro PHP da aplicação com a versão de destino, rastreamos que ficheiros o tráfego real carrega de facto (incluindo os percursos de utilizadores autenticados) e verificamos os ficheiros codificados lendo os seus cabeçalhos em vez de confiar no banner de compatibilidade de um fornecedor. Os problemas aparecem na nossa bancada, não na sua página de checkout.
Primeiro uma medida provisória. Quando é divulgada uma vulnerabilidade crítica, não esperamos pelos pacotes. Desativamos a funcionalidade afetada na configuração onde isso é possível, e aplicamos uma regra no load balancer que rejeita o input que a despoleta em request bodies, query strings e cookies.
Builds nossos quando os mirrors atrasam. Se os repositórios da distribuição forem mais lentos do que a ameaça, construímos nós próprios o PHP corrigido a partir do código fonte upstream, etiquetado de forma a que o pacote oficial o substitua automaticamente quando chegar.
No próprio dia, com a sua equipa informada. As correções de emergência saem no próprio dia em que a correção existe. A sua equipa é mantida informada em cada passo e, se uma correção precisar de downtime no seu serviço, acordamo-lo primeiro consigo. Os upgrades planeados seguem a mesma regra: se uma alteração puder tocar no seu tráfego, acordamos o momento consigo antes de começar.
Um host de cada vez. As distribuições são feitas servidor a servidor, com um health check antes e depois de cada um. Em frotas cPanel e Plesk, um timer vigia os builds corrigidos do fabricante e distribui-os com uma barreira de saúde sobre uma amostra de sites em produção em cada servidor; qualquer regressão interrompe a distribuição.
Do que o protege
- Correr uma versão do PHP que nunca será corrigida contra uma falha ativamente explorada.
- Um upgrade que parte o site sem um caminho rápido de regresso.
- Uma falha ativamente explorada deixada em aberto depois de a sua correção ter sido publicada.
- Software comercial codificado que se recusa a carregar depois de um upgrade.
- Uma campanha de patching que para a meio porque um servidor se portou mal e ninguém reparou.
Na prática
Resposta no próprio dia em toda a frota de clientes. Quando é reportada uma vulnerabilidade crítica do PHP explorada no terreno, a nossa medida provisória no edge e na configuração entra em produção antes da release upstream, e os nossos builds corrigidos seguem-se em horas. Clusters de publicação com vários blades, hosts de aplicação no ramo mais recente do PHP e servidores individuais de clientes com Plesk, cPanel e Linux simples são corrigidos um a um, com um único reinício gracioso dos workers de cerca de um segundo e sem alteração no tempo de render sem cache.
Upgrades que chegam aos percursos autenticados. Em aplicações PHP comerciais testamos não só as páginas públicas mas também os percursos a que só chegam utilizadores autenticados e administradores, porque é aí que se escondem módulos retirados e ficheiros obsoletos. Cada passo do upgrade pode ser revertido com uma única alteração de configuração.
Porquê a EuroVPS
- Resposta no próprio dia a falhas críticas do PHP em toda a frota gerida, com a sua equipa informada e qualquer downtime acordado primeiro.
- Construímos a partir do código fonte upstream quando os pacotes se atrasam, e deixamos os pacotes oficiais assumir o lugar de forma limpa.
- Cada upgrade tem um rollback num passo, mantido até o burn-in terminar.
- Plesk, cPanel com CloudLinux e Linux simples, tratados com o mesmo método.
- Um registo escrito de cada servidor corrigido, com as verificações antes e depois.
Perguntas frequentes
Que versões do PHP suportam? Qualquer ramo de que a sua aplicação precise durante a migração, com um plano para chegar a um ramo suportado. Não deixamos um servidor gerido num ramo em fim de vida sem lho dizer.
Um upgrade vai partir os nossos plugins ou módulos codificados? Descobrimo-lo antes do cutover, com compile check e rastreio do tráfego real. Tudo o que for incompatível é listado com opções antes de mudarmos.
Temos downtime durante o patching? Em stacks com vários nós, não: os nós são corrigidos um de cada vez atrás do load balancer. Num servidor único, um reinício do PHP-FPM demora cerca de um segundo e, se for preciso algum downtime, acordamo-lo primeiro consigo.
Como sabemos que foi feito? Recebe um registo do que foi alterado, quando, e dos health checks antes e depois.
Quer um PHP atual, e que assim se mantenha? Fale com um engenheiro.
O seu próximo parceiro de infraestrutura
Vamos analisar a sua infraestrutura.
Diga-nos o que executa hoje e o que precisa de melhorar. Um engenheiro vai analisar o seu pedido e ajudar a planear o passo seguinte.
+357 222 32280
Comecemos pela sua infraestrutura.
Um pouco de contexto ajuda-nos a começar a conversa certa.