DBA is de hoeder van de gegevens en er zijn twee aspecten aan hoeder zijn. De eerste is integriteit. Het omvat taken zoals het controleren van de databaseconsistentie, het maken van back-ups en, als er problemen optreden, het hebben van een goed ontworpen, uitgebreid databaseherstelplan.
Het tweede aspect is veiligheid. Het stelt voor om ervoor te zorgen dat alleen geautoriseerde gebruikers toegang hebben tot de gegevens, en alleen tot de gegevens die ze nodig hebben.
U kunt op internet talloze bronnen vinden die gewijd zijn aan beveiliging. Toch denk ik dat sommige belangrijke dingen de nodige aandacht missen. In dit artikel wil ik me op deze opties concentreren en aantonen waarom het belangrijk is om hiervan op de hoogte te zijn en er correct mee om te gaan.
Een missie om een SQL Server te compromitteren
Laten we een rollenspel spelen waarin je een geheim agent bent, en je missie, als je die accepteert, is het stelen van zeer belangrijke gegevens van de TargetDB database gehost door een SQL Server. U moet deze gegevens ophalen en verwijderen.
Het is mogelijk om een Login voor u te krijgen, maar elke login op de server heeft expliciete GEWEIGERD toestemmingen voor de doeldatabase en data. De enige informatie die onze agent u kan verstrekken, is de informatie die is gegenereerd voor verificatie door het beveiligingsprotocol tijdens het maken van uw login.
Database-informatie van de doelserver.
Serverrechten:
Databaserechten:
Laten we, zoals elke fatsoenlijke agent, het huiswerk doen en nagaan waar je mee te maken hebt.
U kunt niet zomaar inloggen en verbinding maken met TargetDB , aangezien elke afzonderlijke toestemming voor uw login wordt geweigerd, en de toegewezen gebruiker expliciet. U moet in een andere database komen.
Een gesloten deur
Acties tussen databases zijn niet eenvoudig. Beschouw het als een gesloten deur met twee sloten erop. We zullen ons hier niet concentreren op de technische details, maar u kunt verwijzen naar het artikel Database-imitatie uitbreiden door EXECUTE AS MSDN te gebruiken (ik raad u ten zeerste aan dit te doen).
Het eerste slot is De authenticator vertrouwen , en de tweede is De database vertrouwen .
Laten we beginnen met het eerste slot. Vertrouwen op de authenticator betekent dat voor toegang tot een andere database B, de eigenaar van database A (expliciet of impliciet) de AUTHENTICATE moet worden verleend toestemming in database B.
Wacht even! De authenticator op databaseniveau is de eigenaar van de database zelf (verwar dit niet met de db_owner databaserol!).
Controleer de database-eigenaren:
Ook al volgen ze behoorlijk goede praktijken door één account per server te gebruiken, wat niet SA . is , zo hebben ze het eerste slot zo vriendelijk voor je geopend.
Laten we ons concentreren op het tweede slot.
Op de een of andere manier moet je een database hebben aangemaakt op de server met de TRUSTWORTHY eigenschap AAN . De beste werkwijze hier is om de TRUSTWORTHY database-eigenschap in te stellen op OFF .
Dit is het moment waarop we zouden moeten zeggen:wat als je al zo'n database hebt?
Het is de MSDB-database.
Het tweede slot is klaar. Je hoefde niet eens een van de sloten te breken.
Het belang van de rol db_owner
Op dit moment heb je te maken met één uitdaging. Op de een of andere manier moet je in de MSDB-database komen met de db_owner databaserol omdat het impliciete, imitatierechten heeft.
Aangezien MSDB meestal niet de focus van de databasebeheerders is, is deze missie niet meer onmogelijk. Laten we eens kijken wat u kunt doen alleen omdat u een gebruiker heeft met de db_owner databaserol in de MSDB-database:
Probeer verbinding te maken met de TargetDB :
Dit is een verwachte fout. Onthoud het beveiligingsprotocol dat is toegepast op de opgegeven login. Laten we beginnen.
Probeer verbinding te maken met de TargetDB en om de doelgegevens te selecteren:
Het werkt! Laten we het aanpassen en daarna de actie verifiëren.
Dat is alles.
Missie volbracht.
Zoals je zag, heb ik me gericht op een bepaalde combinatie van beveiligingsdatabaseconfiguraties. Dat waren de eigenaar van de database en de TRUSTWORTHY database-optie met bijzondere aandacht voor MSDB. Het gepresenteerde scenario was er slechts één waarin gevoelige gegevens op dezelfde manier kunnen worden aangetast. Laten we nu een ander mogelijk scenario bekijken.
Database-eigenaar + TRUSTWORTHY
Laten we de achtergronddetails eens bekijken, te beginnen met het bekende probleem:database-eigendom. Welke inloggegevens moet de eigenaar van uw database(s) gebruiken? Veel mensen zeggen dat SA is een geschikte keuze.
Ik deed een snelle Google-zoekopdracht en vond antwoorden zoals de volgende:
“Ik kan me niet herinneren dat ik me hier ooit zorgen over heb gemaakt. Behalve dat het er vervelend uitziet in rapporten, of de gebruiker niet kan verwijderen als ze een database hebben, maar ik denk niet dat het de serveractiviteiten beïnvloedt. Je kunt gewoon sa . kiezen voor consistentie.”
Of
“Ik denk niet dat het bezit van een database door SA of een andere gebruiker een probleem zou moeten zijn. Het gaat erom wie ‘wat’ in uw database uitvoert. Het is dus een goed idee om gebruikers met geldige privileges aan te maken. Voor de eenvoud kun je de eigenaar specificeren als SA.”
De huidige situatie is dat het SA-account gebruiken als database-eigenaar de SLECHTSTE praktijk is . Persoonlijk vind ik dat dit op elke blog en in elke documentatie met betrekking tot dit onderwerp moet worden benadrukt.
Als we gebruikers maken met alleen geldige privileges, zou dat voldoende zijn, maar helaas werkt dit meestal niet. U moet voorbereid zijn op de 'mogelijk slechtste' scenario's. Bedenk eens wat we zouden kunnen doen in onze eerdere voorbeelden als de standaard database-eigenaar SA . was !
Laten we verder gaan met de tweede optie, de BETROUWBAAR database optie. De situatie is een beetje beter, maar het heeft nog steeds een veel voorkomend probleem. Zoals algemeen wordt aangenomen, is de beste werkwijze hier om De 'Betrouwbare' database-eigenschap in te stellen op Uit . We hebben zojuist gezien waarom deze optie slecht is .
Maar dit is niet alles. Als je scripts probeert te vinden om deze eigenschap te controleren, zul je waarschijnlijk een script vinden dat lijkt op dit:
SELECT name FROM sys.databases WHERE is_trustworthy_on = 1 AND name != 'msdb'De sp_Blitz script dat de status van de SQL Server controleert, controleert ook de standaardinstellingen van de databases (inclusief TRUSTWORTHY als standaardwaarde 0) en rapporteert elke database met niet-standaardinstellingen. Het script slaat echter de systeemdatabases over.
Verder is er een MS KB-artikel, waarin dit onderwerp centraal staat. Raadpleeg de richtlijnen voor het gebruik van de TRUSTWORTHY database-instellingen in SQL Server:
Er is een codevoorbeeld in het artikel met een lijst van de databases die het TRUSTWORTHY-bit AAN hebben en waarvan de database-eigenaren tot de sysadmin-serverrol behoren:
SELECT SUSER_SNAME(owner_sid) AS DBOWNER, d.name AS DATABASENAME
FROM sys.server_principals r
INNER JOIN sys.server_role_members m ON r.principal_id = m.role_principal_id
INNER JOIN sys.server_principals p ON
p.principal_id = m.member_principal_id
inner join sys.databases d on suser_sname(d.owner_sid) = p.name
WHERE is_trustworthy_on = 1 AND d.name NOT IN ('MSDB') and r.type = 'R' and r.name = N'sysadmin'
Wat is gebruikelijk in deze scripts? Elk script sluit de MSDB uit, maar zoals in het MS KB-artikel wordt opgemerkt, heb je het zojuist gezien in onze "missie":
Opmerking :Standaard is de instelling TRUSTWORTHY ingesteld op AAN voor de MSDB-database. Als u deze instelling wijzigt van de standaardwaarde, kan dit leiden tot onverwacht gedrag van SQL Server-componenten die de MSDB-database gebruiken.
Ik zou willen benadrukken dat de hoofdfocus van deze sectie noch de TRUSTWORTHY database-optie, noch de database-eigenaar-eigenschap zelf is, maar de combinatie van deze twee opties. Ik heb me vooral geconcentreerd op MSDB omdat de TRUSTWORTHY-instelling standaard is ingesteld op AAN voor de MSDB-database.
Conclusie
Dat is het voor nu. We hebben de praktische scenario's die betrekking hebben op SQL Server-beveiliging doorgenomen en gecontroleerd. We hebben ook zulke belangrijke database-opties bekeken, zoals de eigenaar van de database en de TRUSTWORTHY database-instelling.
Ik wilde deze opties gewoon in de schijnwerpers zetten omdat ze van cruciaal belang zijn, vooral als we er in combinatie over praten.