Excel do SQL Server partnera bez zaufania domeny

Skoroszyt Excel otwierający tabelę na SQL Server innej organizacji potrzebuje trzech rzeczy zwykle omawianych jako jedna: tożsamości, którą serwer akceptuje, transportu, który klient weryfikuje, oraz ścieżki sieciowej, którą dopuszczają obie strony. Zaufanie domeny to jeden sposób spełnienia pierwszego, i najszerszy. TLS spełnia drugie i nic nie mówi o pierwszym. Ścieżka spełnia trzecie i sama w sobie niczego nie chroni.

Rozdzielenie tych trzech zamienia arkusz w małe, możliwe do przejrzenia żądanie zamiast relacji administracyjnej.

Trzy decyzje, które pytanie ukrywa

Tożsamość to, za kogo baza danych uważa użytkownika: konto Windows z zaufanej domeny, login SQL z własnym hasłem albo tożsamość oparta na certyfikacie. Transport to, czy sesja jest szyfrowana i czy klient sprawdza łańcuch certyfikatów serwera. Ścieżka to, jak pakiety docierają do odbiornika, którym może być VPN, łącze prywatne lub publiczny punkt końcowy z regułami zapory. Każde mieszka w innym miejscu i każde może zawieść osobno.

Zaufanie lasu odpowiada na pierwsze szeroko i jest relacją między organizacjami, a nie ustawieniem dla jednego skoroszytu. Nie szyfruje też niczego, co dziwi tych, którzy zakładali, że zaufanie było kontrolą bezpieczeństwa.

Tożsamość bez zaufania lasu

Celowo przygotowane konto w środowisku docelowym może obsłużyć węższe wymaganie bez żadnego zaufania, pod warunkiem że przepływ pracy klienta potrafi go użyć. Uwierzytelnianie SQL to druga częsta odpowiedź, gdy polityka na to pozwala: login niesie własny cykl życia poświadczeń i nie dołącza do domen ani nie tworzy zintegrowanego uwierzytelniania Windows. Tożsamość oparta na certyfikacie lub tokenie to trzecia opcja na nowszych platformach. Cokolwiek wybierzesz, przyznaj tylko te uprawnienia do bazy, których skoroszyt naprawdę potrzebuje.

Preferuj konto dedykowane zamiast czyjegoś osobistego loginu. Współdzielone poświadczenie w arkuszu to problem wsparcia, który czeka, by się zdarzyć, a nazwane konto umożliwia odebranie uprawnień po zakończeniu projektu.

Szyfrować tak, ale ufać certyfikatowi?

Z ODBC Driver 18 Encrypt=Yes;TrustServerCertificate=No żąda szyfrowanej sesji, której certyfikat jest rzeczywiście sprawdzany. Ciąg połączenia musi wtedy wskazać serwer objęty certyfikatem, a klient musi ufać jego łańcuchowi. Driver 18 domyślnie też szyfruje, inaczej niż starsze wersje, więc stary ciąg połączenia może teraz negocjować TLS, nie mówiąc o tym. Jawne ustawienia czynią zamierzoną politykę widoczną na wszystkich maszynach, co ma znaczenie, gdy kilka osób utrzymuje ten sam skoroszyt.

TrustServerCertificate=Yes szyfruje i pomija walidację, co nie jest równoważną naprawą niezgodności nazwy ani niezaufanego łańcucha. Usuwa sygnał, który powiedziałby ci, że klient dotarł do niewłaściwego punktu końcowego, więc popraw certyfikat albo nazwę.

Wymuszanie po stronie serwera to osobna kontrola. Jeśli szyfrowanie ma obowiązywać każdego klienta, skonfiguruj i zweryfikuj ustawienie wymuszonego szyfrowania serwera, bo jeden ugodowy ciąg połączenia niczego nie wymusza.

Ścieżka sieciowa nie jest ochroną

Prywatny odbiornik osiągany przez VPN zmniejsza ekspozycję, a VPN musi przenosić właściwe trasy docelowe i powrotne, aby to działało. Działający tunel nie usuwa potrzeby uwierzytelniania ani weryfikacji certyfikatu, a TLS nie ogranicza, które systemy zdalne mogą próbować połączenia. To trzy osobne obserwacje: uścisk dłoni TLS, logowanie VPN i autoryzowane zapytanie. Tylko trzecia dowodzi, że skoroszyt odczytał dane, które wolno mu było czytać.

Dlatego opieraj się skrótowi odpowiadania na pytanie o zaufanie przez wystawienie bazy danych do internetu. Wąska odpowiedź to zwykle konto dedykowane, zweryfikowane szyfrowanie i jedna zatwierdzona ścieżka, w tej kolejności.

Zweryfikuj zwykłym przepływem pracy Excel: zaakceptowaną tożsamość, efektywne uprawnienia i wynegocjowane szyfrowanie, każde przez widok sesji samego serwera.