Data er det nye guld for store virksomheder og organisationer. Det anses for at være livsnerven i de fleste moderne virksomheder, og der er en bonanza af muligheder for at sælge eller markedsføre til det store publikum på internettet. For de store e-handels- eller sociale medievirksomheder driver data deres kapacitet til at generere store indtægter og indtjening, for hvilke data er tæt sikret og har sofistikeret beskyttelse mod alle ondsindede angreb og indtrængen på nettet.
Så data som guld, dets værdifulde tilstand begynder, når de er behandlet. Dens råværdi er fuld af et rod, som om det er en gigantisk usorteret nibble Når først dens essens er struktureret, multipliceres datas værdi. Forestil dig, hvis du har et uddannelsessted, der giver brugerne mulighed for at betale. Når du har tonsvis af foredrag og moduler, som din målgruppe kan lære, udvikle og tjene en grad af produktivitet, har du fattet smagen af muligheder og succes, da du har døren til at regulere gebyrer, før de kan få de strukturerede data, de ønsker. . Selvom dette lyder som alles drøm om succes, når det kommer til big data og dens underliggende essens, er der tonsvis af komplikationer at behandle det, og vigtig bekymring er trusler mod din database.
Databasetrusler har generelt talrige og omfattende sektorer at se på og undersøge. Selvom de mest almindelige årsager er datatyveri og databrud. En anden almindelig trussel er omfattende privilegier eller adgang til databaser, der er forkert tildelt og/eller givet til en bruger. Beskyttelse af hele serverværten er et problem for enhver, der administrerer en database. Skærpet din sikkerhed og beskæftige dig med alle typer anvendelige angreb såsom aflytning, ændring, afspilning og lammelsesangreb (DDoS) ikke kun for databasen, men også for hele dens underliggende stak, der har adgang eller som grænseflader med din datalagring.
I denne blog vil vi diskutere omfanget af nødvendigheden af, hvorfor du skal forstå og have databaseadgangsprivilegier.
Farer ved forkerte adgangsrettigheder
Vi er uundgåeligt nødt til at dele eller i det mindste oprette en bruger enten på fysisk og teknisk niveau. Mens det at give adgang til en anden betyder, at du stoler på personen. Dette betyder også, at den autoriserede person skal forstå faren og faren ved at dele adgang og data fra omverdenen.
Det vigtigste punkt ved at sikre dine adgangsrettigheder er niveauet af forståelse for sikkerhed mellem dine teknikere, såsom en databaseadministrator, sikkerhedsingeniør eller serveradministrator. Hvis forståelsen er ringe eller mangler viden og erfaring især af de mest opdaterede sårbarheder og eksponeringer, kan det være et problem for organisationen eller virksomheden.
Der er grundlæggende ting, der skal forstås og tages i betragtning, så det er minimalt eller i det mindste ikke kan trænge ind eller afsløres. Ellers kan dette bringe dine data i fare fra omverdenen eller i det mindste for den eller de forkerte personer. Muligvis for at stjæle dine data og bruge dem for deres egen skyld for at vinde økonomisk, eller de kan løse dem fra dig og bede om penge til gengæld for din dårlige sikkerhedsimplementering.
Lad os i dette afsnit se nogle almindelige årsager til disse sikkerhedstrusler.
Deling af root-adgangsprivilegium
For et lokalt miljø afhænger et sædvanligt tilfælde af databasebrud for det meste på faren ved at give root-adgang enten på OS-niveau eller på et databasesoftwareniveau. Der er tilfælde, hvor root-adgangskoden distribueres og udsættes for flere personer, hvilket kun bør være begrænset til de administratorer, der udelukkende arbejder på systemet. Dette kan ske på grund af manglende sikkerhedstjekliste eller foranstaltninger i protokollen før implementering af adgangsrettigheder. At have en sikkerhedstjekliste hjælper med at spore for enhver adgang og privilegier, der kan udsætte risiko og fare, især når en specifik OS-bruger udsættes for en ubuden gæst. Tjeklisten hjælper dig også med at diskutere eller have et overblik over sikkerhedsforanstaltninger på plads og implementeret som en protokol for din organisation.
For eksempel kan en bruger, der har root-adgang, gøre meget skade, såsom at fjerne alle dine data fra dit fysiske lagerdrev, nulstille root-adgangskoden, oprette sin egen bruger/adgangskode, der ser ud som en legitim bruger (kan bruges i meget lang tid til at høste data, medmindre den bliver fanget tidligt), sudo til en anden OS-bruger såsom postgres-bruger, og mange flere skræmmende ting at nyde af den ubudne gæst.
Hvis du bruger MongoDB, kan en bruger med root-adgang logge ind på din databaseserver. Så længe den ubudne gæst kan finde din /etc/mongod.conf eller din mongodb-konfigurationsfil og finde stien til din nøgle, er det nemt at logge ind. Ved at bruge denne kommando kan du f.eks. logge ind,
[[email protected] ~]# mongo -u __system -p "$(tr -d '\011-\015\040' < /etc/mongo-cluster.key)" --authenticationDatabase local --eval "db.adminCommand( { listDatabases: 1, nameOnly:1 } )"
Overvej en MySQL normal installationsopsætning, en root-adgang kan efterlades uden en adgangskode til localhost-adgang. Det er nemt at få adgang, når du først er root. Filadgang såsom $HOME/.my.cnf eller visning af indholdet af /etc/my.cnf vil føre dig til nemt at få adgang.
Det anbefales på det kraftigste kun at begrænse eller bare give din root-adgang til det mindste antal personer, der arbejder direkte med serveren for at opdatere de pakker, sikkerhedsopdateringer og anvende patches, der kræves af udviklingsteamet.
Brug af sudoers korrekt
Mainstream open source-databasesoftware såsom PostgreSQL, MySQL/MariaDB, MongoDB kræver oprettelse af en specifik OS-bruger. OS-brugeren kræver en specifik rolle, der er begrænset for at tillade styring af sine muligheder inden for databasefunktionaliteten. Korrekte læse- og skrivetilladelser skal indstilles for den underliggende lagerenhedssti. Der er dog tilfælde, hvor nogle, der bruger disse specifikke brugere til databasesoftware, har sudo-privilegier, der også er i stand til at få adgang til den bruger, der udelukkende er udpeget til databaseadgang. Brugerrettigheder i operativsystemet skal begrænses, og det er bedst at begrænse dets adgang baseret på rolle. For eksempel, for Percona Server CVE-2016-6664, selvom dette er blevet rettet, er denne type sårbarhed et eksempel på et muligt angreb fra en specifik bruger, der har adgang til MySQL-kontoen og får root-adgang. Sudo-brugere skal gennemgås og gøres til at forstå, at rollen kun er begrænset til at udføre et specifikt job.
At aktivere Linux Auditing System såsom auditd kan hjælpe med at forbedre sikkerheden, da det øger oversete adgangsrettigheder på OS-niveau, der kan føre til sikkerhedssårbarheder i din database. SELinux og AppArmor er gode eksempler på sikkerhedsmoduler til dit Linux-miljø, der hoster dit databasesystem for at hjælpe med at forbedre din sikkerhed mod ubudne gæster eller brud, der ville føre til, at dine data bringes i fare.
Tildeling af databaseadgangsrettigheder
Mainstream open source-databaser tilbyder en detaljeret liste over privilegier, der kan tilpasses til kun at blive tildelt til en specifik handling for en bestemt bruger. Dette er en omfattende måde at hjælpe databaseadministratorer med sikkert at have dataadskillelse og målhandling baseret på specifikke privilegier.
Fælles adgangsrettigheder
Dine mest brugte rettigheder skal være baseret på disse tre kategorier:
-
Kan læse/finde såsom SELECT, SHOW VIEW, FIND
-
Kan indsætte/opdatere/slette såsom INSERT, UPDATE, DELETE, REMOVE
-
Kan udføre administrative handlinger såsom OPRET BRUGER, OPRET ROLLE, ÆNDRE, REPLIKATION, DROP BRUGER/TABELLER/ SCHEMA's, dræbe operationer osv.
Disse kategorier kan udvides til mere raffinerede privilegier baseret på din sikkerhedstjekliste. Det er godt at definere en specifik bruger, der skal oprettes med specifikke privilegier til en specifik opgave. For eksempel kan en applikation have flere brugere med sine egne udpegede privilegier tildelt. Selvom applikationen kan være så kompleks med denne type implementering. Der er tilfælde, hvor per-bruger-forbindelse kan være ressourcekrævende, såsom at bruge ORM som Hibernate, for eksempel. På den anden side afhænger det af det arkitektoniske design af din ansøgning. Formålet med en per-bruger-basis i en applikation kan hjælpe med at opretholde et mere raffineret databaseadgangsprivilegium og undgå at skade dine data fra uønskede sletninger, opdateringer eller en SQL-injektion, der angriber din database.
I de fleste tilfælde bruger en applikation én bruger til at oprette forbindelse til databasen, som kun er begrænset til dens handlinger specifikt for applikationen at køre. Det er bedst, at du designer dit applikationsbrugerprivilegium til kun at læse- og skriveadgang. Hvorimod hvis administrative handlinger er påkrævet, skal et specifikt script, dæmon eller modul i din applikationsadgang adskilles fra de normale brugere.-.
Databasedgang skal undgås
PostgreSQL og MySQL/MariaDB har denne mulighed for at give en bruger, der bruger ALLE privilegier. For PostgreSQL er det også bedst at have din bruger med NOSUPERUSER. Hvis det er muligt, skal dette undgås for enhver pris. Dette privilegium kan udføre det meste af enhver handling, der potentielt kan ødelægge eller skade dine værdifulde data. Du kan bruge ALLE privilegier til din administrator eller root-adgang, men er kun begrænset til brugere, der kræver superprivilegier til at udføre administrative opgaver og administrere dataene.
Adgang pr. tabel eller pr. skema
Det er en god praksis kun at give adgang til en bruger for kun de påkrævede tabeller. . Så selvom brugeren har nogle administrative rettigheder, er enhver skade kun på et begrænset sæt tabeller. Enten kan du indstille på et skema-dækkende; at give adgang til en begrænset tabel giver en detaljeret type privilegier, og det hjælper dig med at holde dine data ude af skade.
Adgang begrænset til kun vært
At oprette forbindelse via dens ressource IP-adresse hjælper med at begrænse adgangen til dine data. Undgå at bruge '%' som f.eks. i MySQL
GRANT SELECT, INSERT, DELETE ON mydb TO [email protected]'%' IDENTIFIED BY 'password';Omfanget af skade er udsat for enhver vært at oprette forbindelse til, og det er ikke det, du ønskede, der skulle ske. Det pålægger sårbarhed, og udfordringen ved at trænge ind i din database er meget lav.
For PostgreSQL, sørg for at du har indstillet din pg_hba.conf og brugeren til dens specifikke grænse for kun vært. Dette gælder også for MongoDB, som du kan indstille det til i din MongoDB-konfigurationsfil eller /etc/mongodb.conf. I MongoDB kan du lege med godkendelsesrestriktioner og angive henholdsvis klientkilde eller serveradresse, men kun som du kræver, at klienten eller brugeren skal oprette forbindelse til eller valideres til.
Rollebaseret adgangskontrol
Role-Based Access Control (RBAC) i databaser giver en bekvem måde at administrere brugeren på eller en nem måde at gruppere en bruger med dets udpegede privilegium knyttet til en liste over brugere eller en gruppe af brugere.
Selvom du skal være opmærksom på, at roller håndteres forskelligt i alle open source-databaser. For eksempel definerede MySQL rollerne som følgende,
En MySQL-rolle er en navngivet samling af privilegier. Ligesom brugerkonti kan roller have privilegier tildelt og tilbagekaldt fra dem.
En brugerkonto kan tildeles roller, som tildeler kontoen de privilegier, der er knyttet til hver rolle. Dette muliggør tildeling af sæt privilegier til konti og giver et bekvemt alternativ til at tildele individuelle privilegier, både til at konceptualisere ønskede privilegietildelinger og implementere dem.
MongoDB definerer rolle med RBAC som,
MongoDB anvender rollebaseret adgangskontrol (RBAC) til at styre adgangen til et MongoDB-system. En bruger tildeles en eller flere roller, der bestemmer brugerens adgang til databaseressourcer og operationer. Uden for rolletildelinger har brugeren ingen adgang til systemet.
I PostgreSQL,
PostgreSQL administrerer databaseadgangstilladelser ved hjælp af begrebet roller. En rolle kan opfattes som enten en databasebruger eller en gruppe af databasebrugere, afhængigt af hvordan rollen er sat op. Roller kan eje databaseobjekter (f.eks. tabeller og funktioner) og kan tildele privilegier på disse objekter til andre roller for at kontrollere, hvem der har adgang til hvilke objekter. Ydermere er det muligt at tildele medlemskab i en rolle til en anden rolle, hvilket giver medlemsrollen mulighed for at bruge privilegier, der er tildelt en anden rolle.
Begrebet roller optager begreberne "brugere" og "grupper". I PostgreSQL-versioner før 8.1 var brugere og grupper forskellige slags entiteter, men nu er der kun roller. Enhver rolle kan fungere som en bruger, en gruppe eller begge dele.
Selvom disse databaser implementerer de roller, der er specifikke for deres brug, deler de konceptet med at tildele roller til brugeren for bekvemt at tildele privilegier. Brug af roller giver databaseadministratorer mulighed for at administrere nødvendige brugere til at logge på eller få adgang til databasen.
Forestil dig, hvis du har en liste over brugere, som du skal administrere, eller en liste over brugere, der kan slettes eller tilbagekaldes, når de ikke længere er nødvendige. I nogle specifikke tilfælde, hvis en bestemt opgave kræver arbejde, kan databaseadministratorer oprette brugere med roller, der allerede er på plads. Disse oprettede brugere kan tildeles en specifik rolle i kun en kort periode og derefter tilbagekaldes, når det ikke er nødvendigt.
Revision hjælper også med at adskille brugere, der har en mistanke om sårbarheder eller dataeksponering, så i så fald hjælper det meget nemt med at administrere brugerne med roller.
Brugeradministrationssystem
Hvis din datasikkerhed håndteres og implementeres korrekt, baner det din vej til succes. Selvom der ikke er nogen perfekt løsning, da sårbarheder og indtrængen også altid udvikler sig. Det er som en orm, da det forsøger at lure hele tiden, indtil det er i stand til at nå sit mål om at bryde din sikkerhed og få adgang til dine data. Uden ordentlige værktøjer som advarselssystemer eller råd for eventuelle usikkerheder og sårbarheder ville det være svært at beskytte dine data.
ClusterControl hjælper dig med at administrere dine brugere og verificere eller kontrollere din brugers privilegier fra belastningsbalancere til hoveddatabasebrugerne. Det tilbyder også rådgivere og advarsler, så det giver dig besked om mulige sårbarheder eller indtrængen.
For eksempel ved at bruge en MySQL/MariaDB med en ProxySQL forhåndsfunktioner import og tilføjelse af brugere. For at importere brugere, indsamler den listen over brugere, der er til stede i din nuværende MySQL/MariaDB-klynge, og tilbyder dig at gennemgå dens nuværende privilegier. Se nedenfor,
Også i dette tilfælde kan en ProxySQL-bruger hurtigt deaktiveres, hvis en sådan sårbarhed har været kendt for den specifikke bruger.
ClusterControl giver dig også mulighed for direkte at administrere brugere fra din database, såsom MySQL/MariaDB eller PostgreSQL. For MySQL/MariaDB kan du gå til
For PostgreSQL,
Med ClusterControl kan du tilpasse dine advarsler ved at bruge rådgiverne. Rådgivere er script-baserede enheder, der kan ændres. For eksempel er dette i en MySQL/MariaDB-klynge som vist nedenfor, som kan tilgås via
Ved at klikke på knappen Rediger kan du tilpasse, hvordan ClusterControl ville reagere, hvis den finder brugere med en hvilken som helst vært eller '%' eller en bruger uden adgangskode. Se, hvordan scriptet vises, når du trykker på Redigeringsknap.
Når ClusterControl finder ud af, at nogen af disse rådgivere er udløst, vil en advarsel blive vist, og den vil også blive sendt til den e-mail, du har konfigureret, eller hvis nogen tredjepartsmeddelelser er integreret, vil den blive underrettet der også.
Konklusion
Databaseadgangsrettigheder er et af de vigtigste mål for bekymring for databrud og indtrængen. Hvis din databasebruger er afsløret, eller hvis der var en stor trussel mod den aktuelle databaseversion, som ikke blev rettet, er chancerne for at blive hacket eller målet for ransomware og tyveri meget høje. At forstå adgangsrettighederne og sætte de korrekte grænser hjælper dig med at afbøde farerne ved at afsløre dine værdifulde data.