Data är det nya guldet för stora företag och organisationer. Det anses vara livsnerven för de flesta moderna företag och det finns ett överflöd av möjligheter att sälja eller marknadsföra till den stora publiken på internet. För de stora e-handels- eller sociala medieföretagen driver data deras kapacitet att generera stora intäkter och intäkter för vilka data är väl säkrade och har sofistikerat skydd mot alla skadliga och intrångsattacker online.
Så data som guld, dess värdefulla tillstånd börjar när den har bearbetats. Dess råvärde är fullt av en röra som om det vore en gigantisk osorterad napp När dess väsen är strukturerad multipliceras datas värde. Tänk dig bara om du har en utbildningssajt som låter användare betala. När du har massor av föreläsningar och moduler som din målgrupp kan lära sig, utveckla och tjäna en viss grad av produktivitet, har du förstått smaken av möjligheter och framgång eftersom du har dörren att reglera avgifter innan de kan få den strukturerade data de vill ha . Även om detta låter som allas dröm om framgång, när det kommer till big data och dess underliggande väsen, finns det massor av komplikationer att bearbeta den och ett viktigt problem är hot mot din databas.
Databashot har i allmänhet många och omfattande sektorer att titta på och undersöka. Även om de vanligaste orsakerna är datastöld och dataintrång. Ett annat vanligt hot är omfattande privilegier eller tillgång till databaser som felaktigt tilldelas och/eller tillhandahålls en användare. Att skydda hela servervärden är ett problem för alla som hanterar en databas. Skärpt din säkerhet och hantera alla typer av tillämpliga attacker som avlyssning, ändring, uppspelning och DDoS (Denial of Service) inte bara för databasen utan också för hela dess underliggande stack som har åtkomst eller som gränssnitt mot din datalagring.
I den här bloggen kommer vi att diskutera omfattningen av nödvändigheten av varför du behöver förstå och ha databasåtkomstprivilegier.
Faror med felaktig åtkomsträttigheter
Vi måste oundvikligen dela eller åtminstone skapa en användare antingen på fysisk och teknisk nivå. Att ge tillgång till någon annan innebär att du litar på personen. Detta innebär också att den auktoriserade personen måste förstå faran och faran med att dela åtkomst och data från omvärlden.
Den viktigaste punkten med att säkra dina åtkomstprivilegier är nivån av förståelse för säkerhet mellan dina tekniker, såsom en databasadministratör, säkerhetsingenjör eller serveradministratör. Om förståelsen är dålig eller saknar kunskap och erfarenhet speciellt av de mest aktuella sårbarheterna och exponeringarna kan det vara ett problem för organisationen eller företaget.
Det finns grundläggande saker som måste förstås och tas i beaktande så att det har minimalt eller åtminstone inte kan inkräktas eller avslöjas. Annars kan detta sätta din data i fara från omvärlden eller åtminstone för fel person eller personer. Möjligen för att stjäla din data och använda den för sin egen skull för att tjäna ekonomiskt eller så kan de lösa ut den från dig och be om pengar i utbyte mot din dåliga säkerhetsimplementering.
I det här avsnittet, låt oss se några vanliga orsaker till dessa säkerhetshot.
Dela root-åtkomsträttigheter
För en lokal miljö beror ett vanligt fall av databasintrång mest på risken med att ge rotåtkomst antingen på OS-nivå eller på en databasprogramvarunivå. Det finns fall där root-lösenordet distribueras och exponeras för flera personer, vilket endast bör begränsas till administratörer som enbart arbetar på systemet. Detta kan hända på grund av avsaknad av en säkerhetschecklista eller åtgärder i protokollet innan åtkomstbehörigheterna implementeras. Att ha en säkerhetschecklista hjälper till att spåra åtkomst och privilegier som kan utsätta risker och fara, särskilt när en specifik OS-användare utsätts för en inkräktare. Checklistan hjälper dig också att diskutera eller ha en överblick över säkerhetsåtgärder på plats och implementerade som ett protokoll för din organisation.
Till exempel kan en användare som har root-åtkomst göra mycket skada som att ta bort all din data från din fysiska lagringsenhet, återställa root-lösenordet, skapa sin egen användare/lösenord som ser ut som en legitim användare (kan användas under mycket lång tid för att samla in data om den inte fångas tidigt), sudo till en annan OS-användare som postgres-användare och mycket mer skrämmande saker att njuta av av inkräktaren.
Om du använder MongoDB kan en användare med root-åtkomst logga in på din databasserver. Så länge som inkräktaren kan hitta din /etc/mongod.conf eller din mongodb-konfigurationsfil och hitta sökvägen till din nyckel, är det enkelt att logga in. Om du till exempel använder det här kommandot kan du logga in,
[[email protected] ~]# mongo -u __system -p "$(tr -d '\011-\015\040' < /etc/mongo-cluster.key)" --authenticationDatabase local --eval "db.adminCommand( { listDatabases: 1, nameOnly:1 } )"
Tänk på en normal MySQL-installation, en root-åtkomst kan lämnas utan lösenord för lokalvärdåtkomst. Det är lätt att få tillgång när du väl är root. Filåtkomst som $HOME/.my.cnf eller visning av innehållet i /etc/my.cnf leder till att du enkelt får åtkomst.
Det rekommenderas starkt att endast begränsa eller bara ge din root-åtkomst till det minsta antalet personer som arbetar direkt med servern för att uppdatera de paket, säkerhetsuppdateringar och applicera patchar som krävs av utvecklingsteamet.
Använda sudoers på rätt sätt
Mainstream databasprogramvara med öppen källkod som PostgreSQL, MySQL/MariaDB, MongoDB kräver att en specifik OS-användare skapas. OS-användaren kräver en specifik roll som är begränsad för att tillåta hantering av dess kapacitet inom databasfunktionaliteten. Korrekt läs- och skrivbehörighet måste ställas in för den underliggande lagringsenhetens sökväg. Det finns dock fall där vissa som använder dessa specifika användare för databasprogramvara har sudo-privilegier som också kan få åtkomst till användaren som endast är avsedd för databasåtkomst. Användarprivilegier i operativsystemet måste begränsas och det är bäst att begränsa dess åtkomst baserat på roll. Till exempel, för Percona Server CVE-2016-6664, även om detta har åtgärdats, är denna typ av sårbarhet ett exempel på en möjlig attack från en specifik användare som har tillgång till MySQL-kontot och får root-åtkomst. Sudo-användare måste granskas och göras för att förstå att rollen endast är begränsad till att utföra ett specifikt jobb.
Att aktivera Linux Auditing System som auditd kan hjälpa till att förbättra säkerheten eftersom det höjer förbisedda åtkomstprivilegier på OS-nivå som kan leda till säkerhetssårbarheter i din databas. SELinux och AppArmor är bra exempel på säkerhetsmoduler för din Linux-miljö som är värd för ditt databassystem för att förbättra din säkerhet mot inkräktare eller intrång som skulle leda till att dina data äventyras.
Bevilja databasåtkomsträttigheter
Mainstream databaser med öppen källkod erbjuder en detaljerad lista med privilegier som kan anpassas för att endast tilldelas en specifik åtgärd för en specifik användare. Detta är ett omfattande sätt att hjälpa databasadministratörer att säkert ha dataseparering och målåtgärder baserat på specifika privilegier.
Common Access Privileges
Dina mest använda privilegier ska baseras på dessa tre kategorier:
-
Kan läsa/hitta som SELECT, SHOW VIEW, FIND
-
Kan infoga/uppdatera/ta bort som INSERT, UPDATE, DELETE, REMOVE
-
Kan utföra administrativa åtgärder som SKAPA ANVÄNDARE, SKAPA ROLL, ÄNDRA, REPLIKATION, SLIPPA ANVÄNDARE/TABELL/ SCHEMA, döda operationer, etc.
Dessa kategorier kan utökas till mer förfinade privilegier baserat på din säkerhetschecklista. Det är bra att definiera en specifik användare som ska skapas med specifika privilegier för en specifik uppgift. Till exempel kan en applikation ha flera användare med sina egna tilldelade behörigheter. Även om applikationen kan vara lika komplex med denna typ av implementering. Det finns fall där anslutning per användare kan vara resurskrävande, som att använda ORM som Hibernate, till exempel. Å andra sidan beror det på den arkitektoniska utformningen av din applikation. Syftet med en per-användarbas i en applikation kan hjälpa till att upprätthålla en mer förfinad databasåtkomsträttighet och undvika att skada dina data från oönskade raderingar, uppdateringar eller en SQL-injektion som attackerar din databas.
I de flesta fall använder ett program en användare för att ansluta till databasen som endast är begränsad till dess åtgärder specifikt för att programmet ska köras. Det är bäst att du utformar din applikationsanvändarbehörighet så att den endast har läs- och skrivåtkomst. Om administrativa åtgärder krävs måste ett specifikt skript, demon eller modul i din applikationsåtkomst separeras från de vanliga användarna.-.
Databasåtkomst ska undvikas
PostgreSQL och MySQL/MariaDB har detta alternativ för att ge en användare som använder ALLA privilegier. För PostgreSQL är det också bäst att ha din användare med NOSUPERUSER. Om möjligt måste detta till varje pris undvikas. Denna behörighet kan göra det mesta av varje åtgärd som potentiellt kan förstöra eller skada din värdefulla data. Du kan använda ALLA privilegier för din administratörs- eller root-åtkomst men är bara begränsad till användare som kräver superprivilegier för att utföra administrativa uppgifter och hantera data.
Åtkomst per tabell eller per schema
Det är en god praxis att endast ge åtkomst till en användare för endast de tabeller som krävs. . Så även om användaren har vissa administrativa privilegier, är eventuell skada endast på en begränsad uppsättning tabeller. Antingen kan du ställa in på ett schematäckande; att ge tillgång till en begränsad tabell ger en detaljerad typ av privilegier och det hjälper dig att skydda dina data.
Åtkomst begränsad till endast värd
Anslutning via dess resurs IP-adress hjälper till att begränsa åtkomsten till dina data. Undvik att använda '%' som i MySQL till exempel,
GRANT SELECT, INSERT, DELETE ON mydb TO [email protected]'%' IDENTIFIED BY 'password';Omfattningen av skadan exponeras för vilken värd som helst att ansluta till och det är inte vad du ville ska hända. Det skapar sårbarhet och utmaningen att göra intrång i din databas är mycket liten.
För PostgreSQL, se till att du har ställt in din pg_hba.conf och användaren till dess specifika gräns för endast värd. Detta gäller även MongoDB som du kan ställa in det för i din MongoDB-konfigurationsfil eller /etc/mongodb.conf. I MongoDB kan du leka med autentiseringsbegränsningar och ställa in respektive klientkälla eller serveradress, men bara för vilka du kräver att klienten eller användaren ska ansluta till eller valideras till.
Rollbaserad åtkomstkontroll
Role-Based Access Control (RBAC) i databaser ger ett bekvämt sätt att hantera användaren eller ett enkelt sätt att gruppera en användare med dess angivna behörighet kopplad till en lista över användare eller grupp av användare.
Även om du måste notera att roller hanteras på olika sätt i alla databaser med öppen källkod. Till exempel definierade MySQL rollerna som följande,
En MySQL-roll är en namngiven samling privilegier. Liksom användarkonton kan roller ha privilegier beviljade och återkallade från dem.
Ett användarkonto kan tilldelas roller, vilket ger kontot de privilegier som är kopplade till varje roll. Detta möjliggör tilldelning av uppsättningar av privilegier till konton och ger ett bekvämt alternativ till att bevilja individuella privilegier, både för att konceptualisera önskade privilegietilldelningar och implementera dem.
MongoDB definierar roll med RBAC som,
MongoDB använder rollbaserad åtkomstkontroll (RBAC) för att styra åtkomst till ett MongoDB-system. En användare tilldelas en eller flera roller som bestämmer användarens åtkomst till databasresurser och operationer. Utanför rolltilldelningar har användaren ingen åtkomst till systemet.
Medan i PostgreSQL,
PostgreSQL hanterar databasåtkomstbehörigheter med hjälp av konceptet roller. En roll kan ses som antingen en databasanvändare eller en grupp databasanvändare, beroende på hur rollen är inställd. Roller kan äga databasobjekt (till exempel tabeller och funktioner) och kan tilldela privilegier på dessa objekt till andra roller för att kontrollera vem som har åtkomst till vilka objekt. Dessutom är det möjligt att ge medlemskap i en roll till en annan roll, vilket gör att medlemsrollen kan använda privilegier som tilldelats en annan roll.
Begreppet roller sammanfattar begreppen "användare" och "grupper". I PostgreSQL-versioner före 8.1 var användare och grupper distinkta typer av enheter, men nu finns det bara roller. Vilken roll som helst kan fungera som en användare, en grupp eller båda.
Även om dessa databaser implementerar roller som är specifika för deras användning, delar de konceptet att tilldela roller till användaren för att tilldela privilegier bekvämt. Genom att använda roller kan databasadministratörer hantera nödvändiga användare för att logga in eller komma åt databasen.
Föreställ dig om du har en lista med användare som du måste hantera eller en lista med användare som kan tas bort eller återkallas när de inte behövs längre. I vissa specifika fall, om en viss uppgift behöver arbete, kan databasadministratörer skapa användare med roller som redan finns på plats. Dessa användare som skapats kan tilldelas en specifik roll under bara en kort period och sedan återkallas när de inte behövs.
Revisioner hjälper också till att separera användare som har en misstanke om sårbarheter eller dataexponering, så i så fall hjälper det att hantera användarna med roller mycket enkelt.
Användarhanteringssystem
Om din datasäkerhet hanteras och implementeras på rätt sätt, banar det dig för framgång. Även om det inte finns någon perfekt lösning eftersom sårbarheter och intrång alltid utvecklas också. Det är som en mask då den försöker lura hela tiden tills den kan nå sitt mål att bryta mot din säkerhet och få tillgång till din data. Utan lämpliga verktyg som larmsystem eller råd för eventuella osäkerheter och sårbarheter skulle det vara svårt att skydda din data.
ClusterControl hjälper dig att hantera dina användare och verifiera eller kontrollera dina användares privilegier från lastbalanserare, till huvuddatabasanvändarna. Den erbjuder också rådgivare och varningar så att den kommer att meddela dig om möjliga sårbarheter eller intrång.
Till exempel kan du använda en MySQL/MariaDB med en ProxySQL i förväg, för att importera och lägga till användare. För att importera användare samlar den in listan över användare som finns i ditt nuvarande MySQL/MariaDB-kluster och erbjuder dig att granska dess nuvarande privilegier. Se nedan,
Också i det här fallet kan en ProxySQL-användare avaktiveras snabbt om en sådan sårbarhet har varit känd för den specifika användaren.
ClusterControl erbjuder dig också att direkt hantera användare från din databas som för MySQL/MariaDB eller PostgreSQL. För MySQL/MariaDB kan du gå till
För PostgreSQL,
Med ClusterControl kan du anpassa dina varningar genom att använda rådgivarna. Rådgivare är skriptbaserade enheter som är modifierbara. Detta är till exempel i ett MySQL/MariaDB-kluster som visas nedan, som kan nås via
Genom att klicka på knappen Redigera kan du anpassa hur ClusterControl skulle reagera om den hittar användare med någon värd eller '%' eller en användare utan lösenord. Se hur skriptet visas när du trycker på Redigera-knapp.
När ClusterControl får reda på att någon av dessa rådgivare har utlösts, kommer en varning att visas och kommer även att skickas till e-postmeddelandet du har konfigurerat eller om några aviseringar från tredje part är integrerade, kommer den att meddelas där också.
Slutsats
Behörighet till databasåtkomst är ett av de främsta målen för dataintrång och intrång. Om din databasanvändare avslöjas eller om det fanns ett stort hot mot den aktuella databasversionen som inte korrigerades, är chansen att bli hackad eller målet för ransomware och stöld mycket stor. Att förstå åtkomstprivilegierna och ställa in de korrekta gränserna hjälper dig att minska riskerna med att exponera dina värdefulla data.