Cosa facciamo · Dati e web: Aggiornamenti PHP e patch di sicurezza su tutta la flotta
Un PHP a fine vita non riceve mai la correzione per la prossima vulnerabilità sfruttata. Portiamo le applicazioni su un PHP supportato senza romperle, e quando arriva una falla critica mettiamo la correzione su ogni server che gestiamo lo stesso giorno, un host alla volta, con un rollback pronto a ogni passo.
Cos'è
Due servizi che condividono una sola disciplina:
- Aggiornamenti pianificati: spostare un'applicazione da un vecchio ramo PHP a uno supportato, compreso il software commerciale protetto da encoder, su Linux puro, Plesk e cPanel con CloudLinux.
- Patch d'emergenza: quando viene resa pubblica una vulnerabilità PHP critica, una misura tampone davanti alla vostra applicazione entro l'ora, seguita dal PHP corretto distribuito su tutta la flotta non appena esiste.
Come lo costruiamo
Fianco a fianco, mai sopra. La nuova versione di PHP viene installata accanto alla vecchia. Il cutover è un singolo cambio reversibile del socket o del pool FastCGI, e la vecchia versione continua a girare come percorso di rollback finché non è trascorso un periodo di burn-in pulito.
Prova prima del salto. Prima di un aggiornamento maggiore compiliamo in verifica ogni file PHP dell'applicazione sotto la versione di destinazione, tracciamo quali file il traffico reale carica davvero (compresi i percorsi autenticati) e verifichiamo i file codificati leggendone le intestazioni invece di fidarci del banner di compatibilità di un vendor. I problemi emergono sul nostro banco, non sulla vostra pagina di checkout.
Prima una misura tampone. Quando viene resa pubblica una vulnerabilità critica, non aspettiamo i pacchetti. Disabilitiamo la funzionalità interessata nella configurazione dove è possibile, e distribuiamo una regola sul load balancer che rifiuta l'input scatenante nei corpi delle richieste, nelle query string e nei cookie.
Build nostre quando i mirror sono in ritardo. Se i repository delle distribuzioni sono più lenti della minaccia, compiliamo noi stessi il PHP corretto dal sorgente upstream, etichettato in modo che il pacchetto ufficiale lo sostituisca automaticamente quando arriva.
Lo stesso giorno, con voi informati. Le patch d'emergenza escono lo stesso giorno in cui la correzione esiste. Venite tenuti informati a ogni passo e, se una patch richiede downtime sul vostro servizio, lo concordiamo prima con voi. Gli aggiornamenti pianificati seguono la stessa regola: se un cambiamento potrebbe toccare il vostro traffico, concordiamo i tempi con voi prima di iniziare.
Un host alla volta. Le distribuzioni vanno server per server, con un health check prima e dopo ciascuno. Sulle flotte cPanel e Plesk, un timer sorveglia le build corrette del vendor e le distribuisce con un health gate su un campione di siti vivi di ogni server; qualsiasi regressione ferma la distribuzione.
Da cosa vi protegge
- Far girare una versione di PHP che non riceverà mai la patch contro una falla sfruttata attivamente.
- Un aggiornamento che rompe il sito senza una via di ritorno rapida.
- Una falla sfruttata attivamente lasciata aperta dopo che la sua correzione è stata pubblicata.
- Software commerciale codificato che si rifiuta di caricarsi dopo un aggiornamento.
- Una campagna di patch che si ferma a metà perché un server ha fatto i capricci e nessuno se n'è accorto.
In pratica
Risposta nello stesso giorno su tutta la flotta dei clienti. Quando una vulnerabilità PHP critica viene segnalata in circolazione, la nostra misura tampone su edge e configurazione va in produzione prima del rilascio upstream, e le nostre build corrette seguono entro ore. Cluster editoriali multi-blade, host applicativi sul ramo PHP più recente e singoli server Plesk, cPanel e Linux puro dei clienti vengono corretti uno per uno, con un solo riavvio graceful dei worker di circa un secondo e nessuna variazione del tempo di rendering non in cache.
Aggiornamenti che raggiungono i percorsi autenticati. Sulle applicazioni PHP commerciali testiamo non solo le pagine pubbliche ma anche i percorsi raggiunti solo da utenti autenticati e amministratori, perché è lì che si nascondono moduli dismessi e file stantii. Ogni passo dell'aggiornamento può essere annullato con un singolo cambio di configurazione.
Perché EuroVPS
- Una risposta nello stesso giorno alle falle PHP critiche su tutta la flotta gestita, con voi informati e qualsiasi downtime concordato prima.
- Compiliamo dal sorgente upstream quando i pacchetti sono in ritardo e lasciamo che i pacchetti ufficiali subentrino in modo pulito.
- Ogni aggiornamento ha un rollback in un passo, conservato fino alla fine del burn-in.
- Plesk, cPanel con CloudLinux e Linux puro, gestiti con lo stesso metodo.
- Una registrazione scritta di ogni server corretto, con i controlli prima e dopo.
Domande frequenti
- Quali versioni di PHP supportate? Qualsiasi ramo serva alla vostra applicazione durante la migrazione, con un piano per raggiungere un ramo supportato. Non lasceremo un server gestito su un ramo a fine vita senza dirvelo.
- Un aggiornamento romperà i nostri plugin o i moduli codificati? Lo scopriamo prima del cutover, compilando in verifica e tracciando il traffico reale. Tutto ciò che è incompatibile viene elencato con le opzioni prima dello switch.
- Avremo downtime durante le patch? Sugli stack multinodo, no: i nodi vengono corretti uno alla volta dietro il load balancer. Su un singolo server, un riavvio di PHP-FPM richiede circa un secondo e, se serve downtime, lo concordiamo prima con voi.
- Come sappiamo che è stato fatto? Ricevete una registrazione di che cosa è stato cambiato, quando, e degli health check prima e dopo.
Volete un PHP aggiornato, che resti tale? Parla con un ingegnere.
Il vostro prossimo partner per l'infrastruttura
Guardiamo la vostra infrastruttura.
Raccontateci cosa fate girare oggi e cosa deve migliorare. Un ingegnere esaminerà la vostra richiesta e vi aiuterà a pianificare il passo successivo.
+357 222 32280
Partiamo dalla vostra infrastruttura.
Un po' di contesto ci aiuta a iniziare la conversazione giusta.