Toon posts:

[MS SQL] Gebruikers aan hosts koppelen ala MySQL

Pagina: 1
Acties:

Vraag


  • Keeper of the Keys
  • Registratie: Augustus 2002
  • Laatst online: 15-03 21:28
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!

Alle reacties


  • Brahiewahiewa
  • Registratie: Oktober 2001
  • Laatst online: 30-09-2022

Brahiewahiewa

boelkloedig

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

QnJhaGlld2FoaWV3YQ==


  • Keeper of the Keys
  • Registratie: Augustus 2002
  • Laatst online: 15-03 21:28
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
  • Registratie: Mei 2003
  • Laatst online: 03-02 15:30

MAX3400

XBL: OctagonQontrol

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.

Mijn advertenties!!! | Mijn antwoorden zijn vaak niet snowflake-proof


  • Keeper of the Keys
  • Registratie: Augustus 2002
  • Laatst online: 15-03 21:28
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
  • Registratie: Mei 2003
  • Laatst online: 03-02 15:30

MAX3400

XBL: OctagonQontrol

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?

Mijn advertenties!!! | Mijn antwoorden zijn vaak niet snowflake-proof


  • Brahiewahiewa
  • Registratie: Oktober 2001
  • Laatst online: 30-09-2022

Brahiewahiewa

boelkloedig

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

QnJhaGlld2FoaWV3YQ==


  • Brahiewahiewa
  • Registratie: Oktober 2001
  • Laatst online: 30-09-2022

Brahiewahiewa

boelkloedig

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

QnJhaGlld2FoaWV3YQ==


  • Luppie
  • Registratie: September 2001
  • Laatst online: 31-03 13:44

Luppie

www.msxinfo.net

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)

Heb je iets aan mijn antwoord ? Een thumbs-up wordt zeker op prijs gesteld.


  • Brahiewahiewa
  • Registratie: Oktober 2001
  • Laatst online: 30-09-2022

Brahiewahiewa

boelkloedig

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"

QnJhaGlld2FoaWV3YQ==


  • Keeper of the Keys
  • Registratie: Augustus 2002
  • Laatst online: 15-03 21:28
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. :X |:( :X |:( :X |:( :X

  • Brahiewahiewa
  • Registratie: Oktober 2001
  • Laatst online: 30-09-2022

Brahiewahiewa

boelkloedig

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? >:)

QnJhaGlld2FoaWV3YQ==

Pagina: 1


Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee