Esistono tre approcci principalmente diversi:

1. Fai in modo che le applicazioni richiamino la configurazione ogni volta.
2. Avere uno strumento per inviare la configurazione alle applicazioni quando cambia.
3. Assicurati che la configurazione non cambi .

Nell'ordine crescente di preferenza. Quindi

3. Assicurati che la configurazione non cambi.

Questa è l'opzione preferita . Crea alias adatti per tutto ciò che non è necessario modificare.

Il nome di dominio per il server di posta non dovrebbe mai cambiare. L'host può, ma devi semplicemente reindirizzare mail.company.com o mail.inranet ¹ al nuovo host. Lo stesso vale per tutte le altre posizioni di rete. Basta creare nomi DNS adatti per loro. Lo stesso vale per database.company.com , ldap.company.com , self-service.company.com ecc. Ogni servizio web e applicazione web dovrebbe avere anche il proprio vhost, quindi puoi spostarli in modo indipendente senza dover modificare le applicazioni dipendenti.

L'unico caso in cui cambierebbero i nomi degli host è quando per esempio dividi il server del database su due database separati, ma poi devi configurare diverse applicazioni in modo diverso, quindi la configurazione centrale non ti aiuterà comunque.

Allo stesso modo, ogni applicazione dovrebbe avere un account separato per il database, denominato come l'applicazione e limitato alle sole operazioni richieste dall'applicazione. Questo è per motivi di sicurezza per ridurre al minimo il danno se alcune delle applicazioni sono compromesse. Come effetto collaterale, fornisce ad ogni applicazione il proprio nome utente e la propria password che non devono essere modificati spesso, quindi non c'è più motivo per la configurazione centrale. Piuttosto contrario; vuoi limitare il numero di posti in cui è presente ciascuna password, in modo che quando qualcuno ne crei uno, le altre applicazioni e i relativi account non siano compromessi.

In un certo senso, è una configurazione condivisa, ma memorizzata nel server DNS. E non dimenticare che DNS può memorizzare varie altre informazioni. Esiste il record SRV per registrare le porte in cui i servizi vengono eseguiti, i record per la memorizzazione di vari tipi di chiavi di crittografia ecc.

2. Avere uno strumento per spingere la configurazione alle applicazioni

Sono disponibili vari software di gestione della configurazione . Questi sono strumenti che si occupano dell'installazione del software e della distribuzione della configurazione tra le reti. Qualsiasi rete non banale dovrebbe usarne una per garantire l'installazione degli aggiornamenti di sicurezza.

Se ne hai uno, aggiungi le regole appropriate per distribuire il file delle proprietà su tutti i server che eseguono alcune applicazioni. Se non lo fai, scegli uno ² e fai lo stesso, inoltre configuralo per prenderti cura degli aggiornamenti di sicurezza.

Si noti che questi strumenti possono anche fare in modo di riavviare i server delle applicazioni quando distribuiscono la nuova configurazione o altrimenti notificano le applicazioni di cui hanno bisogno per ricaricare la configurazione.

Quindi questa è una buona opzione , perché tale strumento è molto utile per amministrare la rete in generale.

3. Chiedi alle applicazioni di eseguire la configurazione.

Ciò richiede in anticipo la modifica di ciascuna applicazione. E non risolverà completamente il problema in ogni caso, perché soffre del problema dell'uovo e della gallina. Devi ancora configurare la posizione da cui dovresti estrarre il resto della configurazione.

La condivisione dei file è ovviamente più semplice per quanto riguarda le dimensioni delle modifiche a ciascuna applicazione. Ricorda che dovrai riavviare anche le applicazioni o implementare un meccanismo per notificarle quando viene modificata la configurazione, il che riduce anche l'utilità della soluzione.

Quindi sicuramente non consiglio questo approccio di cui tutte le tue opzioni originali sono variazioni.

¹ _{È possibile utilizzare un dominio di primo livello arbitrario inesistente nella rete interna e presenta il vantaggio che non sarà necessario modificarlo anche se la società viene rinominata. Basta non usare .local , che è riservato per mDNS.}

² _{O chiedi all'amministratore di sistema di sceglierne uno; sono quelli che interagiranno maggiormente con esso.}

Relativo all'ultimo approccio, utilizzando un servizio web: potresti dare un'occhiata a Apache Zookeeper . Dalla sua documentazione:

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.

Hai ragione a temere le implicazioni di sicurezza di questo approccio. Si noti che Zookeeper proviene dall'ecosistema Hadoop, quindi la sua intenzione originale era quella di fornire la sincronizzazione della configurazione per i cluster Hadoop e altri servizi che interagiscono con Hadoop (come Hive, HBase, ecc ...).

IMHO, Hadoop non è mai stato molto attento alla sicurezza, dal momento che prevedeva che tutti questi servizi funzionassero in un ambiente fidato, ma sta migliorando e ZK potrebbe essere un'opzione da considerare. Puoi configurare ZK per eseguire autenticazione e autorizzazione prima di dare via tutti i tuoi segreti, ma queste opzioni sembra essere disabilitato per impostazione predefinita.