Skocz do zawartości

Uprawnienia MSSQL

Polecane posty

Na pewno będzie działać jak dodamy role "db_owner" (tak jak ma to domyślny użytkownik "dbo"). Wiadomo jednak po to ma być user inny żeby miał mniejsze prawa.

Aktualnie także eksploruje zabezpieczenia baz InsERTa i na razie ciężko znaleźć jakieś konkretne źródła mówiące o czymkolwiek związanym z SQLem (właściwie czymkolwiek wyżej niż user interface programu).

Jakieś hinty może jak ograniczyć np. kasowanie tabel bazy danych (co db_owner może a jest ustawiony jako default dla InsERTa)?

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

Jakieś hinty może jak ograniczyć np. kasowanie tabel bazy danych (co db_owner może a jest ustawiony jako default dla InsERTa)?

Zalecane ustawienia uprawnień dla takich użytkowników są następujące: 

* na poziomie serwera: dla loginu ustawiona rola serwerowa 'public' 
(dodatkowo 'dbcreator', jeśli użytkownik ma tworzyć nowe bazy),

* na poziomie serwera: przyznane uprawnienie 'VIEW SERVER STATE',

* w bazie InsERT_Launcher i każdej bazie podmiotu, do której użytkownik 
ma mieć dostęp: włączone role 'db_datareader', 'db_datawriter',' 
db_ddladmin', 'public'; do tego nadane uprawnienie EXECUTE (można je 
nadawać na poszczególne schemy albo od razu całą bazę), a dla schemy 
InsLauncher w bazie podmiotu polecam dodać komplet (SELECT, INSERT, 
UPDATE, DELETE)

 

A odnośnie samego MSSQL'a

db_owner
Members of the db_owner fixed database role can perform all configuration and maintenance activities on the database, and can also drop the database.

db_securityadmin
Members of the db_securityadmin fixed database role can modify role membership and manage permissions. Adding principals to this role could enable unintended privilege escalation.

db_accessadmin
Members of the db_accessadmin fixed database role can add or remove access to the database for Windows logins, Windows groups, and SQL Server logins.

db_backupoperator
Members of the db_backupoperator fixed database role can back up the database.

db_ddladmin
Members of the db_ddladmin fixed database role can run any Data Definition Language (DDL) command in a database.

db_datawriter
Members of the db_datawriter fixed database role can add, delete, or change data in all user tables.

db_datareader
Members of the db_datareader fixed database role can read all data from all user tables.

db_denydatawriter
Members of the db_denydatawriter fixed database role cannot add, modify, or delete any data in the user tables within a database.

db_denydatareader
Members of the db_denydatareader fixed database role cannot read any data in the user tables within a database.

 

każdy powyżej db_datawriter może kasować dane, ale tylko DB_owner zrobi drop.

  • Dziękuję 1
Link to postu
  • 4 lata później...

Dzień dobry, 

Odkopię trochę temat. Instalator podczas instalacji nie proponuje założenia hasła do usera bazodanowego sa. IMHO to duże niedopatrzenie, a w przypadku pracy sieciowej to już poważna dziura w bezpieczeństwie. Dodatkowo Nexo korzysta z wbudowanych schem dbo co też nie jest najszczęśliwszym rozwiązaniem. Stworzyłem sobie usera z uprawnieniami jak sugeruje @Adam G do końcówek na stacjach roboczych. Do robienia backupów w programie serwisowymi tworzenia podmiotów są potrzebne dodatkowe role  bulkadmin, dbcreator, db_backupoperator więc mamy drugiego usera "administratora" .

Docelowo chcę zahasłować usera sa

Moje pytanie: czy jest wymagane wpisanie ustawionego hasła do usera sa gdzieś w samym nexo ? Czy wszystko zadziała "od strzała" ? O czymś ważnym jeszcze zapomniałem ?

 

Link to postu
3 minuty temu, IT DeMi Poland napisał:

Moje pytanie: czy jest wymagane wpisanie ustawionego hasła do usera sa gdzieś w samym nexo ? Czy wszystko zadziała "od strzała" ? O czymś ważnym jeszcze zapomniałem ?

Nie hasło dla sa założy sobie Pan spokojnie przez SSMS(Microsoft SQL Server Management Studio).

 

Jeśli gdzieś został użytkownik łączący się przez sa to nie będzie miał dostępu do czasu poprawienia user/password.

 

5 minut temu, IT DeMi Poland napisał:

Instalator podczas instalacji nie proponuje założenia hasła do usera bazodanowego sa. IMHO to duże niedopatrzenie, a w przypadku pracy sieciowej to już poważna dziura w bezpieczeństwie.

Niestety nie pamiętam dokładnie bo dawno nie instalowałem MS SQL, ale tak edycja Express która jest instalowana z programem nie tworzy hasła dla sa, ale nie jest to do końca złe rozwiązanie w przypadku firmy która prowadzonej przez jedną osobę(jeśli dobrze pamiętam MS SQL Express w standardowej komunikacji przyjmuje tylko połączenia na 127.0.0.1)
Jeśli instaluje się pełną wersję MS SQL to instancje tworzy się przed instalacją programu, więc tu byłoby niedopatrzenie osoby instalującej SQLa, że nie ustawiła hasła dla sa. 

PS: przez przypadek oznaczyłem Pana odpowiedz jako rozwiązanie czy ktoś z Insertu mógłby odpiąć to rozwiązanie?

 

Link to postu
20 minut temu, Adam G napisał:

Niestety nie pamiętam dokładnie bo dawno nie instalowałem MS SQL, ale tak edycja Express która jest instalowana z programem nie tworzy hasła dla sa, ale nie jest to do końca złe rozwiązanie w przypadku firmy która prowadzonej przez jedną osobę(jeśli dobrze pamiętam MS SQL Express w standardowej komunikacji przyjmuje tylko połączenia na 127.0.0.1)

Co nie zmienia faktu, że każdy bardziej ogarnięty user w sieci lub włamywacz może sobie odpalić SSMS lub tym podobne narzędzie i zalogować się pustym hasłem sa do bazy.... 

Link to postu
Godzinę temu, IT DeMi Poland napisał:

Moje pytanie: czy jest wymagane wpisanie ustawionego hasła do usera sa gdzieś w samym nexo ? Czy wszystko zadziała "od strzała" ? O czymś ważnym jeszcze zapomniałem ?

Niestety nie wiem co ma Pan na myśli pisząc "samym nexo". Dane logowania do bazy danych są zapamiętywane w plikach startowych, więc na każdym stanowisku do każdego programu będzie trzeba je wprowadzić lub przygotować pliki startowe za pomocą programu serwisowego i je skopiować na każdą stację.

 

Godzinę temu, Adam G napisał:

Niestety nie pamiętam dokładnie bo dawno nie instalowałem MS SQL, ale tak edycja Express która jest instalowana z programem nie tworzy hasła dla sa,

To nie jest w żaden sposób związane z edycją serwera SQL tylko konfiguracją jego instalacji wykonywaną przez InsERT.

 

Godzinę temu, Adam G napisał:

Jeśli instaluje się pełną wersję MS SQL to instancje tworzy się przed instalacją programu, więc tu byłoby niedopatrzenie osoby instalującej SQLa, że nie ustawiła hasła dla sa. 

Od bardzo dawna nie da się zainstalować serwera SQL bez hasła dla użytkownika sql.

 

55 minut temu, IT DeMi Poland napisał:

Co nie zmienia faktu, że każdy bardziej ogarnięty user w sieci lub włamywacz może sobie odpalić SSMS lub tym podobne narzędzie i zalogować się pustym hasłem sa do bazy....

No nie uda się bez otwarcia lub wyłączenia zapory... Nie mniej jeśli ktoś nie zna zagrożeń, nie wie co robi to i tak zrobi sobie krzywdę w inny sposób - na przykład utraci dane poprzez awarię sprzętu lub zaszyfrowanie danych bez posiadania bezpiecznych kopii bezpieczeństwa.

Link to postu
18 godzin temu, Daniel Kozłowski napisał:

Niestety nie wiem co ma Pan na myśli pisząc "samym nexo". Dane logowania do bazy danych są zapamiętywane w plikach startowych, więc na każdym stanowisku do każdego programu będzie trzeba je wprowadzić lub przygotować pliki startowe za pomocą programu serwisowego i je skopiować na każdą stację.

Miałem na myśli opcje konfiguracyjne w samym Nexo. Jeśli tylko w plikach startowych to wszystko jest jasne.

18 godzin temu, Daniel Kozłowski napisał:

No nie uda się bez otwarcia lub wyłączenia zapory... Nie mniej jeśli ktoś nie zna zagrożeń, nie wie co robi to i tak zrobi sobie krzywdę w inny sposób - na przykład utraci dane poprzez awarię sprzętu lub zaszyfrowanie danych bez posiadania bezpiecznych kopii bezpieczeństwa.

Pisałem o przypadku pracy sieciowej - baza na jednym komputerze (serwerze) i końcówki łączące się do tej bazy. W tym przypadku port tak czy tak musi być  (i jest otwarty). Więc domyślnie mamy dostęp do MS SQLa z bazami nexo z uprawnieniam superadministratora i pustym hasłem.....  

 

Edytowane przez IT DeMi Poland
Link to postu
15 minut temu, IT DeMi Poland napisał:
18 godzin temu, Daniel Kozłowski napisał:

Niestety nie wiem co ma Pan na myśli pisząc "samym nexo". Dane logowania do bazy danych są zapamiętywane w plikach startowych, więc na każdym stanowisku do każdego programu będzie trzeba je wprowadzić lub przygotować pliki startowe za pomocą programu serwisowego i je skopiować na każdą stację.

Miałem na myśli opcje konfiguracyjne w samym Nexo. Jeśli tylko w plikach startowych to wszystko jest jasne.

Ciągle nie wyjaśnił Pan co oznacza dla Pana stwierdzenie "samo Nexo". Program przechowuje dane w bazie danych serwera SQL, aby uzyskać dostęp do tych danych należy wcześniej podać dane logowania do tej bazy danych, więc nie da się zrobić inaczej, dane logowania muszą się znajdować poza bazą danych programu, w przypadku programów InsERT (nexo, GT) znajdują się one w plikach startowych.

 

18 minut temu, IT DeMi Poland napisał:
18 godzin temu, Daniel Kozłowski napisał:

No nie uda się bez otwarcia lub wyłączenia zapory... Nie mniej jeśli ktoś nie zna zagrożeń, nie wie co robi to i tak zrobi sobie krzywdę w inny sposób - na przykład utraci dane poprzez awarię sprzętu lub zaszyfrowanie danych bez posiadania bezpiecznych kopii bezpieczeństwa.

Pisałem o przypadku pracy sieciowej - baza na jednym komputerze (serwerze) i końcówki łączące się do tej bazy.

Napisał Pan tak:

19 godzin temu, IT DeMi Poland napisał:
20 godzin temu, Adam G napisał:

Niestety nie pamiętam dokładnie bo dawno nie instalowałem MS SQL, ale tak edycja Express która jest instalowana z programem nie tworzy hasła dla sa, ale nie jest to do końca złe rozwiązanie w przypadku firmy która prowadzonej przez jedną osobę(jeśli dobrze pamiętam MS SQL Express w standardowej komunikacji przyjmuje tylko połączenia na 127.0.0.1)

Co nie zmienia faktu, że każdy bardziej ogarnięty user w sieci lub włamywacz może sobie odpalić SSMS lub tym podobne narzędzie i zalogować się pustym hasłem sa do bazy.... 

 

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