Ciężko poszukiwałem rozwiązania problemów związanych z bezpieczeństwem w SQL Server. Opracowujemy aplikację .NET, która jest ukierunkowana na SQL Server 2008 i chcemy używać FileStream.

Teraz dowiedziałem się, że SQL Server zezwala tylko na FileStream poprzez Win32 API, jeśli używasz Integrated Security. Problem polega na tym, że mamy około 80% naszej aplikacji zakończonej, ale jest ona całkowicie oparta na uwierzytelnianiu SQL. Robimy więc prosto z naszej aplikacji INSERT i nie stosujemy procedur przechowywanych dla każdej operacji CRUD.

Jest to stosunkowo bezpieczne, ponieważ mogę przechowywać nazwę użytkownika SQL i hasło w postaci zaszyfrowanej. Wiem, że hasło jest przewożone w czystym tekście, ale jestem gotów to zaakceptować.

Chcemy, aby użytkownicy końcowi mogli łączyć się z bazą danych za pomocą narzędzi, takich jak Crystal Reports, i dlatego mamy dodatkowe logowanie SQL, które ma tylko uprawnienia SELECT.

Teraz, jeśli zmienimy na Integrated Security, będziemy musieli dać poszczególnym użytkownikom (za pośrednictwem grup AD itp.) Prawa do robienia rzeczy, które aplikacja może zrobić. W przeciwnym razie aplikacja nie będzie w stanie wykonać tej pracy. Ale wtedy użytkownik końcowy będzie miał te prawa, gdy połączy się bezpośrednio z bazą danych.

Widzę, jak ludzie mówią, że należy używać procedur przechowywanych dla każdej operacji CRUD i przyznawać prawa EXEC tylko grupie AD, ale jak mam to zrobić? Nie widzę, w jaki sposób użytkownik miałby różne uprawnienia, gdy łączy się bezpośrednio lub za pośrednictwem aplikacji ... Czy ktoś może mnie o tym oświecić.

Dodatkowe pytanie dotyczące punktów bonusowych: Intergrated Security nie będzie działał w grupie roboczej tak dalece, jak rozumiem. W jaki sposób ludzie mogą wtedy uruchomić FileStream w grupie roboczej? Czy jest to uważane za niemożliwe?