Excel verso un SQL Server partner senza trust di dominio

Una cartella di lavoro Excel che apre una tabella sul SQL Server di un’altra organizzazione ha bisogno di tre cose spesso discusse come una sola: un’identità che il server accetti, un trasporto che il client validi e un percorso di rete che entrambe le parti consentano. Il trust di dominio è un modo per soddisfare la prima, e il più ampio. TLS soddisfa la seconda e non dice nulla sulla prima. Il percorso soddisfa la terza e non protegge nulla da solo.

Separare le tre trasforma il foglio di calcolo in una richiesta piccola e verificabile invece che in una relazione amministrativa.

Tre decisioni che la domanda nasconde

L’identità è chi il database ritiene che voi siate: un account Windows di un dominio trusted, un login SQL con la propria password o un’identità basata su certificato. Il trasporto è se la sessione è cifrata e se il client controlla la catena di certificati del server. Il percorso è come i pacchetti raggiungono il listener, che può essere una VPN, un collegamento privato o un endpoint pubblico con regole di firewall. Ognuno vive in un posto diverso e ognuno può fallire da solo.

Un trust di foresta risponde ampiamente alla prima ed è una relazione tra organizzazioni, non un’impostazione per una cartella di lavoro. Non cifra nulla, il che sorprende chi dava per scontato che il trust fosse il controllo di sicurezza.

Identità senza trust di foresta

Un account appositamente predisposto nell’ambiente di destinazione può servire un requisito più ristretto senza alcun trust, purché il flusso di lavoro del client possa usarlo. L’autenticazione SQL è l’altra risposta comune quando la policy lo consente: il login porta con sé il proprio ciclo di vita delle credenziali e non si unisce ai domini né produce autenticazione integrata di Windows. L’identità basata su certificato o token è una terza opzione sulle piattaforme più recenti. Qualunque scegliate, concedete solo le autorizzazioni di database di cui la cartella di lavoro ha davvero bisogno.

Preferite un account dedicato al login personale di qualcuno. Una credenziale condivisa in un foglio di calcolo è un problema di supporto in attesa di accadere, e un account con un nome rende possibile la revoca alla fine del progetto.

Cifrare sì, ma fidarsi del certificato?

Con ODBC Driver 18, Encrypt=Yes;TrustServerCertificate=No richiede una sessione cifrata il cui certificato è davvero controllato. La stringa di connessione deve quindi indicare il server coperto dal certificato, e il client deve fidarsi della sua catena. Driver 18 cifra anche per impostazione predefinita, a differenza delle versioni precedenti, quindi una vecchia stringa di connessione può ora negoziare TLS senza dirlo. Impostazioni esplicite rendono visibile la policy voluta su tutte le macchine, il che conta quando più persone mantengono la stessa cartella di lavoro.

TrustServerCertificate=Yes cifra e salta la validazione, che non è una riparazione equivalente per una discrepanza di nome o una catena non attendibile. Rimuove il segnale che vi avrebbe detto che il client ha raggiunto l’endpoint sbagliato, quindi correggete il certificato o il nome.

L’applicazione lato server è un controllo separato. Se la cifratura deve valere per ogni client, configurate e verificate l’impostazione di cifratura forzata del server, perché una stringa di connessione collaborativa non impone nulla.

Il percorso di rete non è la protezione

Un listener privato raggiunto tramite VPN riduce l’esposizione, e la VPN deve trasportare le rotte di destinazione e di ritorno corrette perché funzioni. Un tunnel funzionante non elimina la necessità di autenticazione né la validazione del certificato, e TLS non limita quali sistemi remoti possano tentare una connessione. Sono tre osservazioni distinte: un handshake TLS, un login VPN e una query autorizzata. Solo la terza dimostra che la cartella di lavoro ha letto i dati che le era consentito leggere.

Resistete quindi alla scorciatoia di rispondere a una domanda di trust esponendo il database a internet. La risposta stretta è di solito un account dedicato, una cifratura validata e un percorso approvato, in quest’ordine.

Verificate con il normale flusso di lavoro Excel: l’identità accettata, le autorizzazioni effettive e la cifratura negoziata, ciascuna controllata tramite la vista di sessione del server stesso.