Skocz do zawartości

Minimalne uprawnienia SQL dla działania pakietu InsERT GT (Subiekt, Rachmistrz).

Polecane posty

Dla pracy zdalnej tworzymy dla każdego użytkownika login serwera SQL i użytkownika bazy z nim powiązanego.

 

W przypadku NEXO udało mi się +/- ograniczyć uprawnienia do:

  • Baza InsERT_Launcher:
    • db_datareader
    • db_datawriter
  • Baza NEXO:
    • db_datareader
    • db_datawriter
    • Oraz dodatkowo ALTER na poniższe, (bez czego się nie da zalogować - zakładam, że są to jakieś funkcje odp. za licencję itp.):
    • obraz.png.92a608607a72f41f5eb7d54828549b1d.png

 

W przypadku GT:

  • db_datareader
  • db_datawriter

...nie wystarczają, ale niestety program nie daje wystarczających raportów żeby wiedzieć, które query nie przechodzą (tak jak to znalazłem dla NEXO). Czy jest dostępna jakaś lista lub ktoś wie od ręki?

Pozostaje ręczna analiza SQL profilerem, ale wstępnie mogę powiedzieć, że nie idzie to za dobrze, bo na razie nic nie byłem w stanie odszukać.

Czy do działania GT trzeba dawać uprawnienia 'db_owner'?

obraz.png.29e520409dcb3f267c38ae63be8f8951.png

 

Dziękuję!

Edytowane przez Ernest Sadowski
Link to postu

Z poziomu oprogramowania (InsERT) ograniczenia są nakładane z uprawnień personelu.

Jednak do bazy podmiotu, z której program korzysta połączyć się przecież można nie z oprogramowania, a więc podstawowa wiedza o SQL pozwoli obejść powyższe (można przecież pisać własne query).

 

Powyższe piszę tylko po to żeby napisać, że NIE jest to problem, który chcę rozwiązać. Jestem świadomy, że InsERT nie wspiera granularnej kontroli dostępu a taka zabawa samemu, mimo że możliwa (można by poklei na każdą tabelę [securable] bazy podmiotu nakładać osobne uprawnienia na samym serwerze SQL) - nie ma absolutnie sensu.

 

Co chcę rozwiązać to ograniczyć nie-administracyjnym użytkownikom programu możliwość zalogowania się do Serwera SQL i wykonaniu komend typu DROP, wykonywania backupu i innych spraw, których nie powinni móc robić.

Nadanie 'db_owner' każdemu pracownikowi tylko po to żeby mogli pracować na bazie wydaje się trochę przesadne - stąd pytanie czy da się jakoś wyśledzić (lub jest spis) z jakich powodów konkretnie GT daje "Dostęp zabroniony" gdy ktoś nie ma 'db_owner'. Podejrzewam, że tak w przykładzie NEXO (który dałem jako porównanie) - do uruchomienia podmiotu wystarczy tylko kilka konkretnych ALTERów, a nie cały 'db_owner'.

 

Oczywiście będę próbował sam wyśledzić, ale pytam o pomoc. :)

Edytowane przez Ernest Sadowski
Link to postu

Niestety w żaden sposób nie uzasadnił Pan celowości takich działań...

 

32 minuty temu, Ernest Sadowski napisał:

Co chcę rozwiązać to ograniczyć nie-administracyjnym użytkownikom programu możliwość zalogowania się do Serwera SQL i wykonaniu komend typu DROP

Jak wyżej - co to niby ma zmienić ? Przecież struktura bazy danych jest bezwartościowa, zawsze można ją odtworzyć na podstawie podmiotu demo założonego przez wersję demo programu, która jest dostępna publicznie dla każdego. Ważne są tylko dane programu zawarte w tabelach, a te - jak wyżej wskazałem pogrubioną czcionką - program musi móc edytować.

 

To analogia do zagrożeń typu cryptolockery, które nie uszkadzają systemu operacyjnego czy programów, tylko dane programów. Nie da się przed tym zabezpieczyć w inny sposób jak ograniczać dostęp i wykonywać regularnie kopie.

 

32 minuty temu, Ernest Sadowski napisał:

wykonywania backupu

To powinna dać się ograniczyć podstawowymi rolami jak również brakiem dostępu do maszyny, na której znajdują się dane i lokalizacji do której mogą zostać wykonane backupy.

 

Ale to też tylko pozory bezpieczeństwa danych - jeśli ktoś będzie już tak zaawansowany to po prostu zamiast backupu bazy danych będzie mógł pobrać sobie wszystkie dane, umieść w innej bazie danych i uruchomić program z danymi. Znowu wszystko sprowadza się dostępu do danych i to tak minimalnego jakim jest sam odczyt, którego odebrać nie możemy.

 

32 minuty temu, Ernest Sadowski napisał:

i innych spraw, których nie powinni móc robić

Konkretnie jakich ?

 

32 minuty temu, Ernest Sadowski napisał:

Nadanie 'db_owner' każdemu pracownikowi tylko po to żeby mogli pracować na bazie wydaje się trochę przesadne - stąd pytanie czy da się jakoś wyśledzić (lub jest spis) z jakich powodów konkretnie GT daje "Dostęp zabroniony" gdy ktoś nie ma 'db_owner'. Podejrzewam, że tak w przykładzie NEXO (który dałem jako porównanie) - do uruchomienia podmiotu wystarczy tylko kilka konkretnych ALTERów, a nie cały 'db_owner'.

Zaglądałem do tego jakieś 10 la temu przy poznawaniu programów Insertu, ale od tamtej pory sporo się zmieniło, widziałem jakieś próby innych serwisantów, ale się tym nie interesowałem z opisywanych tutaj powodów, nie ma oficjalnego dokumentu opisującego takie aspekty, pozostaje dokładniej przyjrzeć się profilerowi lub dopytać swojego serwisanta.

 

32 minuty temu, Ernest Sadowski napisał:

Oczywiście będę próbował sam wyśledzić, ale pytam o pomoc. :)

Jak wyżej - nie widzę sensu w takich działaniach, nie tędy droga, należy się skupić na ograniczaniu dostępu do bazy danych, czyli głównie zabezpieczenia po stronie systemu operacyjnego stacji klienckiej.

 

ps.

Proszę pamiętać, że w GT poprzez zestawienia SQL można zrobić praktycznie wszystko to, co może program, nie sprawdzałem jak jest w nexo.

Edytowane przez Daniel Kozłowski
  • Dziękuję 1
Link to postu
23 godziny temu, Daniel Kozłowski napisał:

Niestety w żaden sposób nie uzasadnił Pan celowości takich działań...

 

W dniu 15.09.2021 o 12:25, Ernest Sadowski napisał:

Co chcę rozwiązać to ograniczyć nie-administracyjnym użytkownikom programu możliwość zalogowania się do Serwera SQL i wykonaniu komend typu DROP

Jak wyżej - co to niby ma zmienić ? Przecież struktura bazy danych jest bezwartościowa, zawsze można ją odtworzyć na podstawie podmiotu demo założonego przez wersję demo programu, która jest dostępna publicznie dla każdego. Ważne są tylko dane programu zawarte w tabelach, a te - jak wyżej wskazałem pogrubioną czcionką - program musi móc edytować.

 

To analogia do zagrożeń typu cryptolockery, które nie uszkadzają systemu operacyjnego czy programów, tylko dane programów. Nie da się przed tym zabezpieczyć w inny sposób jak ograniczać dostęp i wykonywać regularnie kopie.

 

W dniu 15.09.2021 o 12:25, Ernest Sadowski napisał:

wykonywania backupu

To powinna dać się ograniczyć podstawowymi rolami jak również brakiem dostępu do maszyny, na której znajdują się dane i lokalizacji do której mogą zostać wykonane backupy.

 

Ale to też tylko pozory bezpieczeństwa danych - jeśli ktoś będzie już tak zaawansowany to po prostu zamiast backupu bazy danych będzie mógł pobrać sobie wszystkie dane, umieść w innej bazie danych i uruchomić program z danymi. Znowu wszystko sprowadza się dostępu do danych i to tak minimalnego jakim jest sam odczyt, którego odebrać nie możemy.

 

W dniu 15.09.2021 o 12:25, Ernest Sadowski napisał:

i innych spraw, których nie powinni móc robić

Konkretnie jakich ?

 

W dniu 15.09.2021 o 12:25, Ernest Sadowski napisał:

Nadanie 'db_owner' każdemu pracownikowi tylko po to żeby mogli pracować na bazie wydaje się trochę przesadne - stąd pytanie czy da się jakoś wyśledzić (lub jest spis) z jakich powodów konkretnie GT daje "Dostęp zabroniony" gdy ktoś nie ma 'db_owner'. Podejrzewam, że tak w przykładzie NEXO (który dałem jako porównanie) - do uruchomienia podmiotu wystarczy tylko kilka konkretnych ALTERów, a nie cały 'db_owner'.

Zaglądałem do tego jakieś 10 la temu przy poznawaniu programów Insertu, ale od tamtej pory sporo się zmieniło, widziałem jakieś próby innych serwisantów, ale się tym nie interesowałem z opisywanych tutaj powodów, nie ma oficjalnego dokumentu opisującego takie aspekty, pozostaje dokładniej przyjrzeć się profilerowi lub dopytać swojego serwisanta.

 

W dniu 15.09.2021 o 12:25, Ernest Sadowski napisał:

Oczywiście będę próbował sam wyśledzić, ale pytam o pomoc. :)

Jak wyżej - nie widzę sensu w takich działaniach, nie tędy droga, należy się skupić na ograniczaniu dostępu do bazy danych, czyli głównie zabezpieczenia po stronie systemu operacyjnego stacji klienckiej.

 

ps.

Proszę pamiętać, że w GT poprzez zestawienia SQL można zrobić praktycznie wszystko to, co może program, nie sprawdzałem jak jest w nexo.

Edytowane 23 godziny temu przez Daniel Kozłowski

Dziękuję bardzo za odpowiedzi!

Link to postu

Również dziękuję.

 

Osobiście, jako fullstack, mam po prostu wpojone przez lata i na każdym kroku, że klientom nie można ufać, a z racji że InsERT niestety nie ma serwera pośredniego, który by serwował dane poprzez jakieś API (m.in. przez co jest strasznie wolny dla pracy zdalnej, bo nie ma choćby jakiegoś cache), a jedynie dostęp kliencki wprost do bazy to takie rzeczy jak 'db_owner' mnie po prostu rażą w oczy.

 

Zgodzę się jednak, że przecież hasła do serwera na stanowisku można zaszyfrować w programie serwisowym (i użytkownik nawet ich nie będzie znać), a do folderów backupowych i tak nikt nie wejdzie. Bardziej chodziło o to żeby spełniać zasadę "Jeżeli tego nie masz robić, to po co Ci uprawnienia?" (ergo: nie dawać wszędzie 'db_owner').

 

Na razie temat, wg zaleceń, zostawiam.

Może kiedyś wrócę jak ktoś coś u nas kliknie tam gdzie nie powinien i będę faktycznie musiał wdrożyć coś bardziej stricte.

 

Pozdrawiam :)

Link to postu
38 minut temu, Ernest Sadowski napisał:

Osobiście, jako fullstack, mam po prostu wpojone przez lata i na każdym kroku, że klientom nie można ufać, a z racji że InsERT niestety nie ma serwera pośredniego, który by serwował dane poprzez jakieś API

Dawno temu pracowałem w firmie, która tworzyła własny system ERP, pierwsza implementacja została zrealizowana z wykorzystaniem "serwera aplikacji", ale bardzo szybko został wyrzucony ze względu na wydajność.

 

39 minut temu, Ernest Sadowski napisał:

(m.in. przez co jest strasznie wolny dla pracy zdalnej, bo nie ma choćby jakiegoś cache), a jedynie dostęp kliencki wprost do bazy to takie rzeczy jak 'db_owner' mnie po prostu rażą w oczy.

Dlatego tak NIE należy nawet próbować pracować, praca zdalna tylko poprzez RDP/RemoteApp, nawet jeśli mamy dobre łącza to utrzymanie systemu jak aktualizacja to nieporozumienie.  

Link to postu
  • 2 miesiące temu...

Ja kiedyś się tym bawiłem i tak to rozwiązałem.

Stworzyłem nowego użytkownika dla MSSQL  i ustawiłem uprawnienia:
Serwer Roles: public
User Mapping: db_datareader; db_datawriter; db_dlladmin; public (uprawnienia tylko dla baz INSERTU)

We właściwościach serwera sql zakładka Permissions: Conect SQL; View Any Definition; View Server State

We właściwościach bazy danych zakładka Permissions: Execute (uprawnienia tylko dla baz INSERTU)

W efekcie mogłem się zalogować do programu, próba utworzenia kopii wywalała błąd, próba założenia nowej bazy wywalała z programu, próba odłączenia bazy zwracała informację że podmiot nie został odłączony. Nie wdrożyłem tego u klienta ale może się przydać.

Link to postu
×
×
  • Dodaj nową pozycję...