Excel kumppanin SQL Serveriin ilman toimialueen luottamusta

Excel-työkirja, joka avaa taulun toisen organisaation SQL Serverissä, tarvitsee kolme asiaa, joista yleensä puhutaan yhtenä: identiteetin, jonka palvelin hyväksyy, siirtotien, jonka asiakas validoi, ja verkkopolun, jonka molemmat osapuolet sallivat. Toimialueen luottamus on yksi tapa täyttää ensimmäinen, ja laajin. TLS täyttää toisen eikä sano ensimmäisestä mitään. Polku täyttää kolmannen eikä suojaa itsessään mitään.

Kolmen erottaminen tekee laskentataulukosta pienen, tarkistettavan pyynnön hallinnollisen suhteen sijaan.

Kolme päätöstä, jotka kysymys kätkee

Identiteetti on se, kenen tietokanta uskoo sinun olevan: Windows-tili luotetusta toimialueesta, SQL-kirjautuminen omalla salasanallaan tai varmenneperusteinen identiteetti. Siirtotie on se, onko istunto salattu ja tarkistaako asiakas palvelimen varmenneketjun. Polku on se, miten paketit saavuttavat kuuntelijan, joka voi olla VPN, yksityinen yhteys tai julkinen päätepiste palomuurisäännöillä. Kukin asuu eri paikassa ja kukin voi epäonnistua yksin.

Metsän luottamus vastaa ensimmäiseen laajasti ja on organisaatioiden välinen suhde, ei yhden työkirjan asetus. Se ei myöskään salaa mitään, mikä yllättää ne, jotka olettivat luottamuksen olevan turvakontrolli.

Identiteetti ilman metsän luottamusta

Tarkoituksella hankittu tili kohdeympäristössä voi palvella kapeampaa vaatimusta ilman mitään luottamusta, edellyttäen että asiakkaan työnkulku voi käyttää sitä. SQL-todennus on toinen yleinen vastaus, kun käytäntö sallii: kirjautuminen kantaa oman tunnistetietojensa elinkaaren eikä liity toimialueisiin tai tuota Windowsin integroitua todennusta. Varmenne- tai token-pohjainen identiteetti on kolmas vaihtoehto uudemmilla alustoilla. Minkä tahansa valitset, myönnä vain ne tietokantaoikeudet, jotka työkirja todella tarvitsee.

Suosi erillistä tiliä jonkun henkilökohtaisen kirjautumisen sijaan. Jaettu tunnistetieto laskentataulukossa on tuki-ongelma, joka odottaa tapahtumistaan, ja nimetty tili mahdollistaa peruuttamisen, kun projekti päättyy.

Salaa kyllä, mutta luota silti varmenteeseen?

ODBC Driver 18:n kanssa Encrypt=Yes;TrustServerCertificate=No pyytää salattua istuntoa, jonka varmenne todella tarkistetaan. Yhteysmerkkijonon on silloin nimettävä palvelin, jonka varmenne kattaa, ja asiakkaan on luotettava sen ketjuun. Driver 18 salaa myös oletuksena, toisin kuin aiemmat versiot, joten vanha yhteysmerkkijono voi nyt neuvotella TLS:n sanomatta sitä. Selkeät asetukset tekevät aiotun käytännön näkyväksi kaikilla koneilla, millä on merkitystä, kun useat ihmiset ylläpitävät samaa työkirjaa.

TrustServerCertificate=Yes salaa ja ohittaa validoinnin, mikä ei ole vastaava korjaus nimen poikkeamaan tai epäluotettuun ketjuun. Se poistaa signaalin, joka olisi kertonut, että asiakas saavutti väärän päätepisteen, joten korjaa varmenne tai nimi.

Palvelinpuolen pakotus on erillinen kontrolli. Jos salauksen on koskettava jokaista asiakasta, määritä ja tarkista palvelimen pakotetun salauksen asetus, koska yksi yhteistyöhaluinen yhteysmerkkijono ei pakota mitään.

Verkkopolku ei ole suoja

VPN:n kautta saavutettava yksityinen kuuntelija vähentää altistusta, ja VPN:n on kuljetettava oikeat kohde- ja paluureitit, jotta se toimisi. Toimiva tunneli ei poista todennuksen tai varmenteen validoinnin tarvetta, eikä TLS rajoita, mitkä etäjärjestelmät voivat yrittää yhteyttä. Nämä ovat kolme erillistä havaintoa: TLS-kättely, VPN-kirjautuminen ja valtuutettu kysely. Vain kolmas todistaa, että työkirja luki tiedot, jotka sen oli lupa lukea.

Vastusta siis oikotietä vastata luottamuskysymykseen paljastamalla tietokanta internetiin. Kapea vastaus on yleensä erillinen tili, validoitu salaus ja yksi hyväksytty polku, tässä järjestyksessä.

Tarkista tavallisella Excel-työnkululla: hyväksytty identiteetti, tehokkaat oikeudet ja neuvoteltu salaus, kukin palvelimen oman istuntonäkymän kautta.