Excel да SQL Server партнёра без даверу дамену

Кніга Excel, якая адкрывае табліцу на SQL Server іншай арганізацыі, патрабуе трох рэчаў, якія звычайна абмяркоўваюць як адно: ідэнтычнасці, якую сервер прымае, транспарту, які кліент правярае, і сеткавага шляху, які дапускаюць абодва бакі. Давер да дамена — адзін са спосабаў задаволіць першае, і самы шырокі. TLS задавальняе другое і нічога не кажа пра першае. Шлях задавальняе трэцяе і сам па сабе нічога не абараняе.

Раздзяленне гэтых трох ператварае табліцу ў невялікі запыт, які можна разгледзець, замест адміністрацыйных адносін.

Тры рашэнні, якія хавае пытанне

Ідэнтычнасць — гэта тое, кім база даных вас лічыць: уліковы запіс Windows з даверанага дамена, лагін SQL з уласным паролем або ідэнтычнасць на аснове сертыфіката. Транспарт — ці сеанс шыфруецца і ці кліент правярае ланцуг сертыфікатаў сервера. Шлях — гэта тое, як пакеты дасягаюць слухача, якім можа быць VPN, прыватнае злучэнне або публічная канцавая точка з правіламі файрвола. Кожнае жыве ў іншым месцы, і кожнае можа збавіць самастойна.

Давер да лесу адказвае на першае шырока і з’яўляецца адносінамі паміж арганізацыямі, а не наладай для адной кнігі. Ён таксама нічога не шыфруе, што здзіўляе тых, хто меркаваў, што давер і быў сродкам бяспекі.

Ідэнтычнасць без даверу да лесу

Наўмысна створаны ўліковы запіс у мэтавым асяроддзі можа задаволіць больш вузкую патрабу без якога-небудзь даверу, пры ўмове што працоўны працэс кліента можа яго выкарыстаць. Аўтэнтыфікацыя SQL — іншы распаўсюджаны адказ, калі палітыка дазваляе: лагін нясе ўласны жыццёвы цыкл уліковых даных, не далучаецца да даменаў і не стварае інтэграваную аўтэнтыфікацыю Windows. Ідэнтычнасць на аснове сертыфіката або токена — трэці варыянт на новых платформах. Што б вы ні выбралі, давайце толькі тыя правы ў базе даных, якія кніга сапраўды патрабуе.

Аддавайце перавагу выдзеленаму ўліковаму запісу перад чыімсьці асабістым лагінам. Агульныя ўліковыя даныя ў табліцы — гэта праблема падтрымкі, якая чакае свайго часу, а названы ўліковы запіс робіць магчымым адкліканне, калі праект скончыцца.

Шыфраванне — так, а сертыфікату ўсё ж давяраць?

З ODBC Driver 18 Encrypt=Yes;TrustServerCertificate=No запытвае шыфраваны сеанс, сертыфікат якога сапраўды правяраецца. Радок злучэння тады павінен называць сервер, які пакрывае сертыфікат, а кліент павінен давяраць яго ланцугу. Driver 18 таксама па змаўчанні ўжывае шыфраванне, у адрозненне ад ранейшых версій, таму стары радок злучэння можа цяпер узгадніць TLS, не кажучы пра гэта. Яўныя налады робяць меркаваную палітыку бачнай на ўсіх машынах, што важна, калі некалькі чалавек падтрымліваюць адну кнігу.

TrustServerCertificate=Yes шыфруе і прапускае праверку, што не з’яўляецца раўназначным выпраўленнем для няўзгодненасці імені або недаверанага ланцуга. Ён прыбірае сігнал, які сказаў бы вам, што кліент трапіў на няправільную канцавую точку, таму выпраўце сертыфікат або імя.

Прымус з боку сервера — асобны сродак. Калі шыфраванне павінна ўжывацца да кожнага кліента, наладзьце і праверце параметр прымусовага шыфравання сервера, бо адзін згодлівы радок злучэння нічога не прымушае.

Сеткавы шлях — не абарона

Прыватны слухач, дасягнуты праз VPN, паменшвае ўздзеянне, і каб гэта працавала, VPN павінен несці правільныя маршруты прызначэння і вяртання. Працуючы тунэль не здымае патрэбы ў аўтэнтыфікацыі або праверцы сертыфіката, а TLS не абмяжоўвае, якія аддаленыя сістэмы могуць спрабаваць злучэнне. Гэта тры асобныя назіранні: рукапоціск TLS, лагін VPN і аўтарызаваны запыт. Толькі трэцяе даказвае, што кніга прачытала даныя, якія ёй дазволена чытаць.

Таму супраціўляйцеся спакусе адказаць на пытанне даверу, выставіўшы базу даных у інтэрнэт. Вузкі адказ звычайна — выдзелены ўліковы запіс, праверанае шыфраванне і адзін ухвалены шлях, менавіта ў такім парадку.

Правярайце звычайным працоўным працэсам Excel: прынятую ідэнтычнасць, фактычныя правы і ўзгодненае шыфраванне, кожнае праз уласнае прадстаўленне сеанса сервера.