Databasebeveiliging 101:Toegangsrechten voor databases begrijpen

Gegevens zijn het nieuwe goud voor grote bedrijven en organisaties Het wordt beschouwd als de levensader van de meeste moderne bedrijven en er is een overvloed aan mogelijkheden om te verkopen of op de markt te brengen aan het grote publiek van internet. Voor de grote e-commerce- of socialemediabedrijven stimuleren gegevens hun vermogen om grote inkomsten en inkomsten te genereren waarvoor gegevens streng zijn beveiligd en geavanceerde bescherming bieden tegen kwaadwillende en inbraakaanvallen online.

Dus gegevens zoals goud, hun waardevolle staat begint zodra ze zijn verwerkt. De ruwe waarde zit vol met een puinhoop alsof het een gigantische ongesorteerde knabbel is. Als de essentie eenmaal gestructureerd is, wordt de waarde van data veelvouden. Stelt u zich eens voor, als u een educatieve site heeft waarmee gebruikers kunnen betalen. Als je eenmaal tonnen lezingen en modules hebt die je doelgroep kan leren, ontwikkelen en een zekere mate van productiviteit kan verdienen, heb je de smaak van kansen en succes gegrepen, omdat je de deur hebt om vergoedingen te reguleren voordat ze de gestructureerde gegevens kunnen krijgen die ze willen . Hoewel dit klinkt als ieders droom van succes, als het gaat om big data en de onderliggende essentie ervan, zijn er tal van complicaties om het te verwerken en een belangrijk punt van zorg zijn bedreigingen voor uw database.

Databasebedreigingen hebben over het algemeen talrijke en uitgebreide sectoren om naar te kijken en te onderzoeken. De meest voorkomende oorzaken zijn echter datadiefstal en datalekken. Een andere veelvoorkomende bedreiging zijn uitgebreide privileges of toegang tot databases die onjuist zijn toegewezen en/of verstrekt aan een gebruiker. Het beschermen van de volledige serverhost is een zorg voor iedereen die een database beheert. Verhoog uw beveiliging en pak alle soorten van toepassing zijnde aanvallen aan, zoals afluisteren, wijzigen, afspelen en denial of service (DDoS), niet alleen voor de database, maar ook voor de gehele onderliggende stack die toegang heeft of die een interface heeft met uw gegevensopslag.

In deze blog bespreken we in hoeverre u toegang tot databases nodig heeft en waarom u deze moet begrijpen.

Gevaren van verkeerde toegangsrechten

Het is onvermijdelijk dat we een gebruiker moeten delen of op zijn minst een gebruiker moeten maken op fysiek en technisch niveau. Terwijl het verlenen van toegang aan iemand anders betekent dat u de persoon vertrouwt. Dit betekent ook dat de bevoegde persoon het gevaar en gevaar moet begrijpen van het delen van toegang en gegevens van de buitenwereld.

Het belangrijkste punt bij het beveiligen van uw toegangsprivileges is het niveau van begrip over beveiliging tussen uw technici, zoals een databasebeheerder, beveiligingstechnicus of serverbeheerder. Als het begrip slecht is of kennis en ervaring ontbreekt, met name van de meest actuele kwetsbaarheden en blootstellingen, kan dit een probleem zijn voor de organisatie of het bedrijf.

Er zijn basiszaken die moeten worden begrepen en waarmee rekening moet worden gehouden, zodat deze minimaal is of in ieder geval niet kan worden binnengedrongen of blootgelegd. Anders kan dit uw gegevens van de buitenwereld of in ieder geval voor de verkeerde persoon of personen in gevaar brengen. Mogelijk om uw gegevens te stelen en deze voor hun eigen bestwil te gebruiken om er financieel aan te verdienen of ze kunnen het van u losgelden en geld vragen in ruil voor uw slechte beveiligingsimplementatie.

Laten we in dit gedeelte enkele veelvoorkomende oorzaken van deze beveiligingsrisico's bekijken.

Roottoegangsrechten delen

Voor een on-premise-omgeving is een normaal geval van database-inbreuk meestal afhankelijk van het gevaar van het geven van root-toegang op OS-niveau of op databasesoftwareniveau. Er zijn gevallen waarin het root-wachtwoord wordt gedistribueerd en aan meerdere mensen wordt blootgesteld, wat alleen zou moeten worden beperkt tot de beheerders die alleen op het systeem werken. Dit kan gebeuren door het ontbreken van een veiligheidschecklist of maatregelen in het protocol voordat de toegangsrechten worden geïmplementeerd. Het hebben van een beveiligingschecklist helpt bij het opsporen van toegang en privileges die risico's en gevaren kunnen opleveren, vooral wanneer een specifieke OS-gebruiker wordt blootgesteld aan een indringer. De checklist helpt u ook bij het bespreken of hebben van een overzicht van beveiligingsmaatregelen die zijn getroffen en geïmplementeerd als een protocol voor uw organisatie.

Een gebruiker die root-toegang heeft, kan bijvoorbeeld veel schade aanrichten, zoals het verwijderen van al uw gegevens van uw fysieke opslagstation, het resetten van het root-wachtwoord, het maken van zijn/haar eigen gebruiker/wachtwoord dat eruitziet zoals een legitieme gebruiker (kan heel lang worden gebruikt om gegevens te verzamelen, tenzij vroeg ontdekt), sudo naar een andere OS-gebruiker zoals een postgres-gebruiker, en nog veel meer enge dingen om van te genieten door de indringer.

Als u MongoDB gebruikt, kan een gebruiker met root-toegang inloggen op uw databaseserver. Zolang de indringer uw /etc/mongod.conf of uw mongodb-configuratiebestand kan lokaliseren en het pad van uw sleutel kan vinden, is het gemakkelijk om in te loggen. Met dit commando kunt u bijvoorbeeld inloggen,

[[email protected] ~]# mongo -u __system -p "$(tr -d '\011-\015\040' < /etc/mongo-cluster.key)" --authenticationDatabase local --eval "db.adminCommand( { listDatabases: 1, nameOnly:1 } )"

Beschouw een MySQL normale installatie-setup, een root-toegang kan worden achtergelaten zonder een wachtwoord voor localhost-toegang. Het is gemakkelijk om toegang te krijgen als je eenmaal root bent. Bestandstoegang zoals $HOME/.my.cnf of het bekijken van de inhoud van /etc/my.cnf zorgt ervoor dat u gemakkelijk toegang krijgt.

Het wordt ten zeerste aanbevolen om uw root-toegang alleen of alleen te geven aan het minste aantal mensen dat rechtstreeks met de server werkt om de pakketten en beveiligingsupdates bij te werken en patches toe te passen die vereist zijn door het ontwikkelteam.

Sudoers op de juiste manier gebruiken

Mainstream open source databasesoftware zoals PostgreSQL, MySQL/MariaDB en MongoDB vereist het aanmaken van een specifieke OS-gebruiker. De OS-gebruiker heeft een specifieke rol nodig die beperkt is om het beheer van zijn mogelijkheden binnen de databasefunctionaliteit mogelijk te maken. De juiste lees- en schrijfrechten moeten worden ingesteld voor het onderliggende opslagapparaatpad. Er zijn echter gevallen dat sommigen die deze specifieke gebruikers gebruiken voor databasesoftware, sudo-rechten hebben die ook toegang hebben tot de gebruiker die uitsluitend is aangewezen voor databasetoegang. Gebruikersrechten in het besturingssysteem moeten worden beperkt en het is het beste om de toegang te beperken op basis van rol. Voor Percona Server CVE-2016-6664 is dit type kwetsbaarheid bijvoorbeeld, hoewel dit is opgelost, een voorbeeld van een mogelijke aanval van een specifieke gebruiker die toegang heeft tot het MySQL-account en root-toegang krijgt. Sudo-gebruikers moeten worden beoordeeld en duidelijk gemaakt dat de rol alleen beperkt is tot het uitvoeren van een specifieke taak.

Het inschakelen van een Linux-controlesysteem zoals auditd kan de beveiliging helpen verbeteren, aangezien het over het hoofd gezien toegangsrechten op OS-niveau doet ontstaan die tot beveiligingsproblemen van uw database kunnen leiden. SELinux en AppArmor zijn goede voorbeelden van beveiligingsmodules voor uw Linux-omgeving die uw databasesysteem hosten om uw beveiliging te helpen verbeteren tegen indringers of inbreuken die ertoe kunnen leiden dat uw gegevens in gevaar komen.

Toegangsrechten voor databases verlenen

Mainstream open source-databases bieden een gedetailleerde lijst met privileges die kunnen worden aangepast om alleen aan een specifieke actie voor een specifieke gebruiker te worden toegewezen. Dit is een uitgebreide manier om databasebeheerders te helpen veilig gegevens te scheiden en actie te ondernemen op basis van specifieke privileges.

Gemeenschappelijke toegangsrechten

Uw meest gebruikte privileges zijn gebaseerd op deze drie categorieën:

In staat om te lezen/vinden, zoals SELECTEREN, BEKIJKEN, VINDEN
Kan invoegen/bijwerken/verwijderen zoals INSERT, UPDATE, DELETE, REMOVE
In staat om administratieve acties uit te voeren zoals GEBRUIKER MAKEN, ROL MAKEN, WIJZIGEN, REPLICATIE, GEBRUIKER/TABELLEN DROPPEN SCHEMA's, kill-operaties, enz.

Deze categorieën kunnen worden uitgebreid tot meer verfijnde privileges op basis van uw beveiligingschecklist. Het is goed om een specifieke gebruiker te definiëren die moet worden aangemaakt met specifieke privileges voor een specifieke taak. Een toepassing kan bijvoorbeeld meerdere gebruikers hebben met eigen toegewezen bevoegdheden. Hoewel de applicatie een complex kan zijn met dit type implementatie. Er zijn gevallen dat connectiviteit per gebruiker veel bronnen kan vergen, zoals het gebruik van ORM zoals Hibernate, bijvoorbeeld. Aan de andere kant hangt het af van het architectonisch ontwerp van uw toepassing. Het doel van een per-gebruiker basis in een applicatie kan helpen om een verfijnder toegangsrecht tot de database te behouden en schade aan uw gegevens te voorkomen door ongewenste verwijderingen, updates of een SQL-injectie die uw database aanvalt.

In de meeste gevallen gebruikt een applicatie één gebruiker om verbinding te maken met de database, wat alleen beperkt is tot de acties die specifiek zijn om de applicatie te laten draaien. Het is het beste dat u de gebruikersrechten van uw toepassing zo instelt dat ze alleen lees-schrijftoegang hebben. Terwijl als administratieve acties vereist zijn, een specifiek script, daemon of module in uw toepassingstoegang moet worden gescheiden van de normale gebruikers.-.

Databasetoegang moet worden vermeden

PostgreSQL en MySQL/MariaDB hebben deze optie om een gebruiker ALLE rechten te geven. Voor PostgreSQL is het ook het beste om uw gebruiker bij NOSUPERUSER te hebben. Indien mogelijk moet dit koste wat kost worden vermeden. Dit privilege kan de meeste van elke actie uitvoeren die uw waardevolle gegevens mogelijk kan vernietigen of beschadigen. U kunt ALLE privileges gebruiken voor uw admin- of roottoegang, maar u bent alleen beperkt tot gebruikers die de superprivileges nodig hebben om administratieve taken uit te voeren en de gegevens te beheren.

Toegang op basis van per tabel of per schema

Het is een goede gewoonte om een gebruiker alleen toegang te geven tot de vereiste tabellen. . Dus zelfs als de gebruiker enige administratieve privileges heeft, is enige schade slechts aan een beperkte set tabellen. Ofwel kunt u een schema-breed instellen; het bieden van toegang tot een beperkte tabel biedt een gedetailleerd type privileges en het helpt u uw gegevens te beschermen tegen schade.

Toegang beperkt tot alleen host

Verbinding maken via het bron-IP-adres helpt de toegang tot uw gegevens te beperken. Vermijd het gebruik van '%' zodat in MySQL bijvoorbeeld

GRANT SELECT, INSERT, DELETE ON mydb TO [email protected]'%' IDENTIFIED BY 'password';

De omvang van de schade wordt blootgesteld aan elke host om verbinding mee te maken en dat is niet wat je wilde dat er gebeurde. Het legt kwetsbaarheid op en de uitdaging om uw database binnen te dringen is erg laag.

Voor PostgreSQL, zorg ervoor dat je pg_hba.conf en de gebruiker hebt ingesteld op de specifieke limiet van alleen host. Dit geldt ook voor MongoDB waarvoor u het kunt instellen in uw MongoDB-configuratiebestand of /etc/mongodb.conf. In MongoDB kun je spelen met authenticatiebeperkingen en respectievelijk clientSource of serverAddress instellen, maar alleen waarvoor je de client of gebruiker nodig hebt om verbinding mee te maken of waarmee je moet worden gevalideerd.

Op rollen gebaseerde toegangscontrole

Op rollen gebaseerde toegangscontrole (RBAC) in databases biedt een gemakkelijke manier om de gebruiker te beheren of een gemakkelijke manier om een gebruiker te groeperen met zijn toegewezen privilege, gekoppeld aan een lijst met gebruikers of een groep gebruikers.

Hoewel je er rekening mee moet houden dat rollen in open source databases anders worden behandeld. MySQL definieerde de rollen bijvoorbeeld als volgt,

Een MySQL-rol is een benoemde verzameling privileges. Net als aan gebruikersaccounts kunnen aan rollen privileges worden toegekend en ingetrokken.

Aan een gebruikersaccount kunnen rollen worden toegekend, waardoor het account de privileges krijgt die aan elke rol zijn gekoppeld. Dit maakt toewijzing van reeksen privileges aan accounts mogelijk en biedt een handig alternatief voor het verlenen van individuele privileges, zowel voor het conceptualiseren van gewenste privilegetoewijzingen als voor het implementeren ervan.

MongoDB definieert rol met RBAC als,

MongoDB gebruikt Role-Based Access Control (RBAC) om de toegang tot een MongoDB-systeem te regelen. Een gebruiker krijgt een of meer rollen die de toegang van de gebruiker tot databasebronnen en -bewerkingen bepalen. Buiten roltoewijzingen heeft de gebruiker geen toegang tot het systeem.

Terwijl in PostgreSQL,

PostgreSQL beheert machtigingen voor databasetoegang met behulp van het concept van rollen. Een rol kan worden gezien als een databasegebruiker of een groep databasegebruikers, afhankelijk van hoe de rol is ingesteld. Rollen kunnen eigenaar zijn van databaseobjecten (bijvoorbeeld tabellen en functies) en kunnen bevoegdheden voor die objecten toewijzen aan andere rollen om te bepalen wie toegang heeft tot welke objecten. Verder is het mogelijk om lidmaatschap van een rol toe te kennen aan een andere rol, waardoor de lidrol privileges kan gebruiken die aan een andere rol zijn toegewezen.

Het concept van rollen omvat de concepten "gebruikers" en "groepen". In PostgreSQL-versies vóór 8.1 waren gebruikers en groepen verschillende soorten entiteiten, maar nu zijn er alleen rollen. Elke rol kan optreden als gebruiker, groep of beide.

Hoewel deze databases de rollen implementeren die specifiek zijn voor hun gebruik, delen ze het concept van het toewijzen van rollen aan de gebruiker om gemakkelijk privileges toe te kennen. Door rollen te gebruiken, kunnen databasebeheerders de vereiste gebruikers beheren om in te loggen of toegang te krijgen tot de database.

Stel je voor dat je een lijst met gebruikers hebt die je moet beheren of een lijst met gebruikers die kan worden verwijderd of ingetrokken als ze niet meer nodig zijn. In sommige specifieke gevallen, als er aan een bepaalde taak moet worden gewerkt, kunnen databasebeheerders gebruikers maken met reeds bestaande rollen. Deze aangemaakte gebruiker(s) kunnen voor een korte periode aan een specifieke rol worden toegewezen en vervolgens worden ingetrokken zodra deze niet meer nodig is.

Audits helpen ook om gebruikers te scheiden die een vermoeden hebben van kwetsbaarheden of gegevensblootstelling, dus in dat geval helpt het de gebruikers met rollen heel gemakkelijk te beheren.

Gebruikersbeheersysteem

Als uw gegevensbeveiliging op de juiste manier wordt behandeld en geïmplementeerd, baant dit uw weg naar succes. Hoewel er geen perfecte oplossing is, omdat kwetsbaarheden en inbraak ook altijd evolueren. Het is als een worm die de hele tijd op de loer probeert te blijven totdat het zijn doel heeft bereikt om uw beveiliging te doorbreken en toegang te krijgen tot uw gegevens. Zonder de juiste tools zoals waarschuwingssystemen of adviezen voor eventuele onzekerheden en kwetsbaarheden, zou het moeilijk zijn om uw gegevens te beschermen.

ClusterControl helpt u bij het beheren van uw gebruikers en het verifiëren of controleren van uw gebruikersrechten van load balancers tot de belangrijkste databasegebruikers. Het biedt ook adviseurs en waarschuwingen, zodat het u op de hoogte stelt van mogelijke kwetsbaarheden of inbraken.

Bijvoorbeeld met behulp van een MySQL/MariaDB met vooraf een ProxySQL-functies voor het importeren en toevoegen van gebruikers. Voor het importeren van gebruikers verzamelt het de lijst met gebruikers die aanwezig zijn in uw huidige MySQL/MariaDB-cluster en biedt het u de mogelijkheid om de huidige privileges te bekijken. Zie hieronder,

Ook in dit geval kan een ProxySQL-gebruiker snel worden gedeactiveerd als een dergelijke kwetsbaarheid is bekend bij de specifieke gebruiker.

ClusterControl biedt u ook de mogelijkheid gebruikers rechtstreeks vanuit uw database te beheren, zoals voor MySQL/MariaDB of PostgreSQL. Voor MySQL/MariaDB gaat u naar → Beheren → Schema's en gebruikers.

Voor PostgreSQL, → Beheren → Gebruikersbeheer.

Met ClusterControl kunt u uw waarschuwingen aanpassen met behulp van de adviseurs. Adviseurs zijn op scripts gebaseerde entiteiten die kunnen worden gewijzigd. Dit bevindt zich bijvoorbeeld in een MySQL/MariaDB-cluster zoals hieronder weergegeven, dat toegankelijk is via