Domen etimadı olmadan Excel-i tərəfdaşın SQL Server-inə bağlamaq

Başqa bir təşkilatın SQL Server-ində cədvəl açan Excel iş kitabı adətən bir kimi müzakirə olunan üç şeyə ehtiyac duyur: serverin qəbul etdiyi kimlik, müştərinin təsdiqlədiyi nəqliyyat və hər iki tərəfin icazə verdiyi şəbəkə yolu. Domen etimadı birincini təmin etməyin bir yoludur və ən geniş olanıdır. TLS ikincini təmin edir və birinci barədə heç nə demir. Yol üçüncünü təmin edir və özlüyündə heç nəyi qorumur.

Üçünü ayırmaq cədvəli inzibati münasibət əvəzinə kiçik, nəzərdən keçirilə bilən bir sorğuya çevirir.

Sualın gizlətdiyi üç qərar

Kimlik verilənlər bazasının sizi kim hesab etdiyidir: etibarlı domendən Windows hesabı, öz parolu olan SQL girişi və ya sertifikata əsaslanan kimlik. Nəqliyyat sessiyanın şifrələnib-şifrələnmədiyi və müştərinin serverin sertifikat zəncirini yoxlayıb-yoxlamadığıdır. Yol paketlərin dinləyiciyə necə çatdığıdır; bu VPN, özəl keçid və ya firewall qaydaları olan ictimai son nöqtə ola bilər. Hər biri başqa yerdə yerləşir və hər biri təkbaşına uğursuz ola bilər.

Meşə etimadı birincini geniş şəkildə cavablandırır və bir iş kitabı üçün parametr deyil, təşkilatlar arasında münasibətdir. O, heç nəyi şifrələmir də, bu da etimadı təhlükəsizlik nəzarəti sayanları təəccübləndirir.

Meşə etimadı olmadan kimlik

Hədəf mühitdə qəsdən yaradılmış hesab, müştəri iş axını ondan istifadə edə bildiyi təqdirdə, heç bir etimad olmadan daha dar tələbi ödəyə bilər. SQL autentifikasiyası siyasət icazə verdikdə digər geniş yayılmış cavabdır: giriş öz etimadnamə həyat dövrünü daşıyır, domenlərə qoşulmur və Windows inteqrasiyalı autentifikasiya yaratmır. Sertifikat və ya token əsaslı kimlik daha yeni platformalarda üçüncü seçimdir. Hansını seçsəniz də, yalnız iş kitabının həqiqətən ehtiyac duyduğu verilənlər bazası icazələrini verin.

Kiminsə şəxsi girişi əvəzinə xüsusi hesaba üstünlük verin. Cədvəldə paylaşılan etimadnamə baş verməyi gözləyən dəstək problemidir və adlandırılmış hesab layihə bitdikdə ləğvi mümkün edir.

Şifrələmə bəli, sertifikata yenə də güvən?

ODBC Driver 18 ilə Encrypt=Yes;TrustServerCertificate=No sertifikatı həqiqətən yoxlanılan şifrəli sessiya tələb edir. Sonra qoşulma sətri sertifikatın əhatə etdiyi serveri adlandırmalı və müştəri onun zəncirinə güvənməlidir. Həmçinin Driver 18 əvvəlki versiyalardan fərqli olaraq standart olaraq şifrələmə tətbiq edir, ona görə köhnə qoşulma sətri bunu demədən TLS razılaşdıra bilər. Açıq ayarlar nəzərdə tutulan siyasəti maşınlar arasında görünən edir; bu, bir neçə nəfər eyni iş kitabını saxladıqda vacibdir.

TrustServerCertificate=Yes şifrələyir və yoxlamanı atlayır; bu, ad uyğunsuzluğu və ya etibarsız zəncir üçün bərabər düzəliş deyil. O, müştərinin səhv son nöqtəyə çatdığını sizə deyəcək siqnalı silir, ona görə sertifikatı və ya adı düzəldin.

Server tərəfində məcburetmə ayrı bir nəzarətdir. Şifrələmə hər müştəriyə tətbiq olunmalıdırsa, serverin şifrələməni məcburi edən parametrini qurub yoxlayın, çünki bir əməkdaş qoşulma sətri heç nəyi məcbur etmir.

Şəbəkə yolu qoruma deyil

VPN vasitəsilə əldə edilən özəl dinləyici məruz qalmanı azaldır və bunun işləməsi üçün VPN düzgün təyinat və geri dönüş marşrutlarını daşımalıdır. İşləyən tunel autentifikasiya ehtiyacını aradan qaldırmır və ya sertifikat yoxlamasını da; TLS isə hansı uzaq sistemlərin qoşulmağa cəhd edə biləcəyini məhdudlaşdırmır. Bunlar üç ayrı müşahidədir: TLS əl sıxışması, VPN girişi və icazəli sorğu. Yalnız üçüncüsü iş kitabının oxumağa icazəsi olan məlumatı oxuduğunu sübut edir.

Ona görə də etimad sualını verilənlər bazasını internetə çıxarmaqla cavablandırmaq qısa yoluna qarşı durun. Dar cavab adətən xüsusi hesab, təsdiqlənmiş şifrələmə və bir təsdiqlənmiş yoldur, bu sıra ilə.

Adi Excel iş axını ilə yoxlayın: qəbul edilən kimlik, faktiki icazələr və razılaşdırılmış şifrələmə, hər biri serverin öz sessiya görünüşü vasitəsilə.