Nextcloud solo via VPN: inventariate prima ogni accesso

Un piano Nextcloud solo via VPN fallisce quando protegge il browser e dimentica il client di sincronizzazione. La pagina web, il motore di sincronizzazione desktop, i caricamenti mobili, gli strumenti WebDAV e i destinatari dei link condivisi hanno tutti bisogno di un percorso verso lo stesso servizio, e ciascuno può esporre un ingresso diverso. Inventariateli prima di chiudere qualcosa. Quell’elenco è il perimetro reale.

Seguite la lista di controllo in ordine. Il primo punto definisce cosa significa privato per questa distribuzione; i punti successivi verificano se la distribuzione corrisponde davvero a quella definizione.

Definite il privato prima di cambiare il perimetro

Scrivete il requisito in una frase: ogni utente deve unirsi alla VPN prima di raggiungere l’applicazione, oppure l’applicazione può restare pubblica mentre la sua origine resta privata. Sono progetti diversi, e un proxy inverso pubblico che inoltra in un tunnel privato soddisfa solo il secondo.

Un indirizzo backend privato non rende privata l’applicazione. Se una mappatura pubblica, un secondo nome host o un listener IPv6 raggiungono ancora la stessa istanza Nextcloud, l’ingresso esiste indipendentemente da dove si trovi il backend. Testate ogni nome dall’esterno prima di dichiarare privato il servizio. Un record DNS mancante non è la stessa cosa di una porta chiusa.

Concordate anche il pubblico previsto: dipendenti, una famiglia, un’organizzazione partner o un sottoinsieme di account. La risposta decide se un link di condivisione pubblico è una funzionalità o una contraddizione. Scrivete quel pubblico nel piano di accesso. È la prova per ogni eccezione che segue.

Inventariate ogni ingresso e ogni nome

Elencate mappature di indirizzi pubblici, proxy inversi, nomi host alternativi, listener IPv6 e qualsiasi indirizzo di tunnel o mesh che raggiunge il servizio. Includete i nomi che risolvono verso quegli indirizzi, perché un record DNS dimenticato è un ingresso con un’etichetta amichevole.

Controllate la configurazione del proxy per header inoltrati e blocchi server alternativi. Un proxy aggiunto per un’altra applicazione può esporre lo stesso upstream tramite un percorso o un host virtuale rimasto. Leggete la configurazione reale invece del diagramma previsto. I due divergono più spesso dopo che un’applicazione è stata spostata.

Poi bloccate gli ingressi che non avete scelto. Un backend privato con un frontend pubblico non è un progetto solo VPN, e una regola del firewall che copre solo IPv4 lascia aperto il listener IPv6. Chiudete entrambe le famiglie ed entrambi i nomi nella stessa modifica.

Date a ogni client un solo nome di servizio

Puntate il DNS privato al servizio, instradate quel nome attraverso la VPN ed emettete il certificato per esso. Il nome deve risolversi tramite il percorso privato e validarsi senza avvisi. Un client che raggiunge direttamente l’IP ha comunque bisogno che il nome funzioni.

I client che si connettono tramite un indirizzo IP non correlato non dovrebbero dover ignorare errori di certificato perché il progetto funzioni. Un nome stabile impedisce anche ai client di sincronizzazione di creare voci server duplicate quando un indirizzo cambia. È la differenza tra un servizio privato e un IP privato.

Lasciate attiva la convalida dei certificati. Una rete privata riduce l’esposizione ma non rende accettabile una connessione TLS non convalidata, e un client abituato a ignorare gli avvisi li ignorerà anche su altre reti.

Limitate l’accesso alla rete, non l’intera LAN

Consentite agli utenti registrati di raggiungere il servizio Nextcloud e le sue dipendenze necessarie, e tenete l’amministrazione del server su un percorso separato. Una VPN che ammette un client nell’intera rete domestica o d’ufficio dà a quel client molto più di quanto richieda l’applicazione.

L’ammissione alla VPN non sostituisce gli account, i permessi o l’autenticazione aggiuntiva di Nextcloud. L’applicazione decide ancora quale utente può leggere quale file, e il livello di rete non dovrebbe essere l’unico controllo.

Annotate l’intervallo di origine approvato e le porte del servizio. Il proprietario della destinazione ha bisogno dell’origine osservata, e un NAT o un proxy possono riscriverla prima che la richiesta raggiunga l’applicazione.

Esaminate ogni flusso di lavoro fuori dal browser

La sincronizzazione desktop e i caricamenti mobili aprono le proprie connessioni nei propri momenti. Hanno bisogno del percorso privato approvato quando si connettono, e possono comportarsi diversamente quando la VPN manca: riprovare, sospendere o mostrare un errore. Testate ognuno, non solo il browser.

Gli strumenti WebDAV e i client di calendario o contatti sono integrazioni separate con la propria configurazione. Un client che memorizza nella cache un URL pubblico continua a provare quell’URL dopo il cambio di perimetro, e l’errore sembra un problema dell’applicazione.

I link condivisi meritano una decisione esplicita. Un link non concede al destinatario l’accesso alla VPN, quindi in un progetto davvero solo VPN un destinatario esterno non può usarlo anche se il link è valido. Se la condivisione verso l’esterno è necessaria, è un’eccezione deliberata con il proprio percorso di accesso, non una svista da scoprire più tardi.

La federazione e le integrazioni server-to-server richiedono lo stesso trattamento. Sono relazioni di raggiungibilità tra installazioni, e una distribuzione solo privata deve dire se sono supportate.

Accettate sia il caso consentito sia quello negato

Da un client approvato, controllate l’interfaccia web e un normale caricamento o download di file. Poi controllate un client di sincronizzazione e un flusso di lavoro fuori dal browser. Il successo solo nel browser non è accettazione.

Da un percorso non approvato, confermate che l’applicazione non è raggiungibile attraverso ogni ingresso dell’inventario. Testate il nome host alternativo e l’indirizzo IPv6, non solo l’URL principale.

Infine, esaminate le impostazioni dell’applicazione che è facile confondere con la politica di rete. trusted_domains elenca i nomi che l’istanza accetta; non è una lista di IP client consentite. Se un proxy inverso fornisce informazioni sull’indirizzo, trusted_proxies deve nominare il proxy reale, e gli header inoltrati dovrebbero essere accettati solo da esso.

Proseguite il normale lavoro di rafforzamento insieme al cambio di rete: tenete dati e backup fuori da percorsi web non previsti, applicate le patch all’applicazione, proteggete l’accesso amministratore e mantenete il ripristino utilizzabile. Una VPN rimuove una superficie d’ingresso; non rende affidabile un client registrato.