[MS SQL] Gebruikers aan hosts koppelen ala MySQL

[Keeper of the Keys]

Hey,
Ik ben meer een *nix beheerder maar nu moet ik een MSSQL database beschikbaar maken voor een ander systeem op het netwerk, tijdens het testen merkte ik dat ik vanaf het andere systeem met alle bestaande logins kan werken.

Ik heb een beetje gezocht en de meeste suggesties zijn firewall instellingen, maar dat is wat mij betreft niet wat ik nodig heb, als ik met een firewall toegang beperk maar iemand van het juiste adres nog steeds met bepaalde logins volledige rechten kan krijgen dan ben ik nog even ver van huis.

Het liefste zou ik dus de logins aan hosts binden zoals je in MySQL kan doen met gebruiker@host or gebruiker@ip, bestaat er zo'n mogelijkheid of heb ik pech.

MS SQL 2012, onderdeel van een vendor applicatie waar ik verder geen invloed op heb en die helaas standaard wachtwoorden gebruikt (wat het linken van de db naar andere systemen nog riskanter maakt).

Bedankt!

[Brahiewahiewa]

Keeper of the Keys schreef op maandag 27 december 2021 @ 23:04:
...tijdens het testen merkte ik dat ik vanaf het andere systeem met alle bestaande logins kan werken...

Vertel even wat jij onder "alle bestaande logins" verstaat.
Basically werkt MSSQL met windows-ACL's, alhoewel je 'm ook zo in kunt stellen dat-ie z'n eigen userdatabase er op na houdt. Maar je moet die userdatabase of windows-ACL's wel gebruiken natuurlijk. Lijkt er nu op dat je'm op "everyone - full control" hebt gezet

[Keeper of the Keys]

Hey @Brahiewahiewa, bedankt voor je antwoord.

Met bestaande logins bedoel ik dingen als "sa" en andere "lokale" mssql gebruikers die door de vendor voor hun applicatie zijn ingesteld.
Helaas heeft deze vendor ook het wachtwoord voor "sa" op hun support website staan en is het op dit moment onduidelijk of het aanpassen van dit wachtwoord zal leiden tot een non-functioneel systeem (omdat dit wachtwoord mogelijk hardcoded is in hardware).

Vandaar dat ik het liefste sa/andere lokale gebruikers zou beperken tot localhost/het lokale netwerk terwijl het externe systeem dat data moet lezen vanaf het systeem alleen met extern@externgw-hostname zou kunnen werken.

Voor zover ik weet staat hij niet op "everyone - full control" want ik kon bijvoorbeeld niet met mijn (domain admin account) bij de data in de database.

[MAX3400]

Je kan toch een Windows-integrated login op MSSQL definieren? Dus dan "moet" iemand met een "eigen" username & password verbinden naar de instance.

En als je het dan leuk(er) wil doen; IPSEC-policy op de OU van MSSQL (of op de computer account$) toepassen.

[Keeper of the Keys]

Er zijn geen windows identities voor het merendeel van de dingen die met deze db moeten praten en dat is verder ook niet mogelijk (simpele controllers die de database bevragen, "IoT") voor zover ik weet, de MS-SQL lokale logins zijn een gegeven waar ik niet omheen kan zonder dit systeem in alle waarschijnlijkheid te breken.

Met dat gegeven probeer ik te zien of ik toch wat veiligheid kan hebben als we een ander systeem data willen laten lezen uit de database, daarvoor hebben we al een SSH gateway opgezet die met SSH keys werkt, dus de client is vrijwel zeker de bedoelde client, maar omdat ik niet kan beperken dat alleen de specifieke read-only (beperkt op een specifieke view) gebruiker kan verbinden vanaf de gateway is er niets dat kan voorkomen dat de client "sa" of een andere lokale gebruiker zou gebruiken met meer rechten dan de gebruiker die hiervoor is gemaakt.

[MAX3400]

Kan je hier iets mee? https://www.mssqltips.com...ccount%20as%20the%20owner.

Maar, wat versta je precies onder lokale gebruikers? Want er zijn local accounts op de machine maar ook local accounts op de SQL instance.

En wat is er mis om per "IoT-device" een specifieke SQL-login te maken en dan per SQL-login de permissies op instance / database / tables te regelen?

[Brahiewahiewa]

Keeper of the Keys schreef op dinsdag 28 december 2021 @ 15:23:
Er zijn geen windows identities voor het merendeel van de dingen die met deze db moeten praten en dat is verder ook niet mogelijk (simpele controllers die de database bevragen, "IoT") voor zover ik weet, de MS-SQL lokale logins zijn een gegeven waar ik niet omheen kan zonder dit systeem in alle waarschijnlijkheid te breken...

Maar dat betekent dat het feit dat die server er staat, an sich al een beveiligingsrisico is. Nog zonder de clients die jij nog moet connecten. Je wilt eigenlijk die server isoleren binnen je netwerk

Met dat gegeven probeer ik te zien of ik toch wat veiligheid kan hebben als we een ander systeem data willen laten lezen uit de database, daarvoor hebben we al een SSH gateway opgezet die met SSH keys werkt, dus de client is vrijwel zeker de bedoelde client, maar omdat ik niet kan beperken dat alleen de specifieke read-only (beperkt op een specifieke view) gebruiker kan verbinden vanaf de gateway is er niets dat kan voorkomen dat de client "sa" of een andere lokale gebruiker zou gebruiken met meer rechten dan de gebruiker die hiervoor is gemaakt.

Dus de leverancier levert jou een lek bad en jij wilt nu gaan dweilen. Met de kraan open ;o) (nofi)
Ik zou toch eerst eens gaan praten met de leverancier van dat bad. Of dat niet anders kan
Het SA-wachtwoord publiceren op je website is nou niet direct iets wat je verwacht, in deze tijd van ransomware

[Brahiewahiewa]

MAX3400 schreef op dinsdag 28 december 2021 @ 15:26:
...
En wat is er mis om per "IoT-device" een specifieke SQL-login te maken en dan per SQL-login de permissies op instance / database / tables te regelen?

Dat er iemand kan inloggen (al dan niet legaal) en het SA account ook kan gebruiken, want het bijbehorende password staat op de website van de leverancier

[Luppie]

Ik zal eerst eens gaan zoeken naar SA account MS SQL Best Practice.

Wat je dan vindt zal ik delen met de leverancier met de mededeling dat je deze best practices gaat implementeren (Dus SA account hernoemen en disablen) en dat je van de leverancier verwacht dat zijn product qua security richtlijnen voldoet aan de best practices zoals Microsoft en de 'markt' ze implementeert.

Een actief SA account is 'not done' op MS SQL, deze activeer je alleen indien strikt noodzakelijk bij een verstoring of recovery. Laat staan dat het wachtwoord ergens anders bekend is dan in een kluis (bij voorkeur een fysieke kluis op papier met een verzegeling)

[Brahiewahiewa]

Luppie schreef op dinsdag 28 december 2021 @ 15:46:
...Wat je dan vindt zal ik delen met de leverancier met de mededeling dat je deze best practices gaat implementeren (Dus SA account hernoemen en disablen) en dat je van de leverancier verwacht dat zijn product qua security richtlijnen voldoet aan de best practices zoals Microsoft en de 'markt' ze implementeert...

Het kan natuurlijk ook zijn dat de leverancier desgevraagd ook met z'n oren zit te klapperen? "Wat? Hebt U het SA account geactiveerd? Da's niet zo handig"

[Keeper of the Keys]

Zoals @Brahiewahiewa zegt is het probleem dat willekeurig welk MSSQL login zich kan aanmelden vanaf elke locatie die met de SQL Server kan praten, de leverancier gaat er waarschijnlijk vanuit dat dit product in isolatie wordt gebruikt maar nu is er dus een vraag om data uit de applicatie op een andere plek in het bedrijf te gebruiken dus zit ik te kijken hoe we dat zo veilig mogelijk kunnen doen.

Op dit moment is wat mij betreft het beste antwoord dat een pull model gebruiken een onverantwoord risico met zich meebrengt en men in plaats daarvan een lokaal script oid moet ontwikkelen om te "pushen".

De leverancier is zich vermoed ik bewust van de limieten op veiligheid van zijn gebruik van sa, hun support artikel begint zelfs met een opmerking dat sa standaard uit staat op nieuwere versies van MS SQL en dus moet worden ingeschakeld, het aller triests in dit verhaal is dat hun product een fysiek beveiliging product is.

[Brahiewahiewa]

Keeper of the Keys schreef op dinsdag 28 december 2021 @ 16:27:
... het aller triests in dit verhaal is dat hun product een fysiek beveiliging product is...

Wordt het veel gebruikt?