Når en applikation kræver et stort geografisk område at udføre, er en organisation ofte tvunget til at gemme sine data i skyen. Applikationer bygget på MongoDB er ikke en undtagelse fra dette koncept. Manglende beskyttelse af følsomme data kan forårsage nogle alvorlige tilbageslag, herunder et ødelagt omdømme, datainkonsekvenser, økonomiske tab og nogle gange fuldstændigt datatab.
Data, der er gemt i skyen, er tilbøjelig til at blive interesseret fra kriminelle elementer. Personer med ondsindede hensigter kan lettere få adgang, når der ikke er fastlagt standardprocedurer for at sikre databasesikkerhed. Nogle af disse substandard procedurer omfatter...
- Dårlig adgangskodeadministration:nogle udviklere ender med at hårdkode adgangskoderne i projektets kildefiler, så hvis en hacker dekompilerer programmet, kan de nemt hente indholdet.
- Tvilsomhed eller manglende opdatering af databasen og gratis plugins. Nyere databaseversioner har nye funktioner, kan være med hensyn til sikkerhed eller rettere have nogle funktioner rettet fra forgængerne.
- Understandard databasekonfigurationer, som f.eks. ikke bruger krypterede dekrypteringsnøgler eller snarere slet ikke bruger nogen sikkerhedsprotokol.
Databaseangreb stiger dag ind, dag ind (og tendensen forventes at fortsætte), men du bliver muligvis ikke offer, medmindre du tager de relevante sikkerhedshensyn. I denne artikel vil vi diskutere nogle af de procedurer, man kan tjekke med MongoDB-installation i skyen. Du behøver ikke anvende dem alle, men prøv i det mindste bedst at vælge dem, der, hvis de undgås, kan bringe dine data i en katastrofal situation.
MongoDB Pre-Production Sikkerhedsovervejelser
Dette er overvejelser, man bør sikre sig, at de er godt konfigureret, når man skal implementere MongoDB i produktionsmiljøet. De omfatter:
- Aktivering og håndhævelse af godkendelse til adgangskontrol
- Konfigurer rollebaseret adgangskontrol
- Begræns netværkseksponering
- Kryptér kommunikation
- Krypter data
- Revision af systemaktiviteter
- Brug dedikeret bruger til at køre MongoDB
- Brug officielle og opdaterede MongoDB-pakker
- Deaktiver Javascript-kørsel, hvis det ikke er nødvendigt
- Bliv opdateret med MongoDB-sikkerhedsrettelser
1. Aktivering og håndhævelse af godkendelse til adgangskontrol
Adgangskontrol er ikke aktiveret i MongoDB som standard, men det betyder ikke, at du også implementerer din database uden denne mulighed aktiveret. Faktisk vil nogle databasepakker som Bitnami kræve, at du opsætter en vis adgangskontrol, før du bruger din database. I modsat fald kan enhver få adgang til databasen og dermed blive udsat for selv meget følsomme data. Angiv en godkendelsesmekanisme såsom SCRAM, så klienter, der vil blive forbundet, skal give nogle gyldige legitimationsoplysninger, før de kan oprette forbindelse til databasen.
Forbindelsesstrengen skal se nogenlunde sådan ud:
mongodb://[username:[email protected]]host[:port1][/[defaultauthdb]and not just
mongodb://host[:port1]/[defaultauthdb]2. Konfigurer rollebaseret adgangskontrol
Når du har tilføjet brugere med administrative tilladelser, skal du begrænse roller, der er tildelt disse brugere ved hjælp af rollebaseret adgangskontrol (RBAC). De roller, en bruger kan have, omfatter:læse, skrive eller begge dele til specifikke eller alle samlinger. Derfor kan en bruger ikke udføre en rolle, der ikke er tildelt dem, eller kan kun udføre handlinger til tildelte samlinger.
Brugeradministrator oprettes først og derefter yderligere brugere. Hvis en bruger har privilegier på tværs af forskellige databaser, kan du oprette en enkelt bruger med roller, der giver relevante databaseprivilegier i stedet for at oprette brugeren flere gange i forskellige databaser.
Det er tilrådeligt at have et lille antal brugere, der får adgang til databasen, hvorved brugerne kan være personer eller klientapplikationer.
For at oprette og give brugertilladelser til bestemte roller i MongoDB kan du bruge dette eksempel i mongo-skallen
use finance
db.createUser(
{
user: "manager",
pwd: passwordPrompt(), // or cleartext password
roles: [
{ role: "read", db: "loans" },
{ role: "read", db: "interests" },
{ role: "read", db: "useraccounts" },
{ role: "readWrite", db: "wages" }
]
}
)Vælg også eksterne godkendelsesmuligheder såsom LDAP og Kerberos.
3. Begræns netværkseksponering
Netværkstopologi, der er vært for databasen, skal sikres omfattende og vigtigst af alt kun at lytte til den lokale værtsgrænseflade. Dette er for at undgå eksponering fra eksterne forbindelser, som det var tilfældet for MongoDB ældre versioner. Sørg for, at MongoDB kører i et pålideligt netværksmiljø med sikkerhedsfirewall aktiveret. Styr indgående og udgående trafik med sikkerhedsgrupper, der ikke må bruges med andre forekomster. Brug IP-hvidliste til at tillade adgang fra betroede IP-adresser og tillad derfor forbindelser til MongoDB-instanser med netværksgrænseflader og porte kun fra betroede klienter.
Deaktiver desuden den direkte SSH-rodadgang.
4. Krypter kommunikation
MongoDB-konfiguration bør begrænse indgående og udgående forbindelser til kun TLS/SSL. TLS/SSL krypterer kommunikation mellem mongod- og mongos-komponenter i en MongoDB-implementering og alle applikationer, der er forbundet til den.
I produktionsmiljøet bør MongoDB-implementering bruge gyldige certifikater genereret og underskrevet af en enkelt certifikatmyndighed.
5. Krypter dataene
Databasedata har to former:Data i hvile og under transport. Data i transit kan sikres ved at bruge Client-Side Field Level Encryption, men er kun tilgængelig i version 4.2. TLS/SSL-krypteringen tager sig også af data i transit.
WiredTiger-lagringsmotoren fra version 3.2 Enterprise leverer data i lagerlagskryptering. Dette bekræfter, at kun godkendte brugere med dekrypteringsnøgler kan få adgang til dataene. Hvis du ikke bruger WiredTigers kryptering i hvile, skal du bruge filsystemkryptering. Data i hvile-kryptering afholder en fra at få adgang til indholdet af din database, hvis de får adgang til den fysiske server, og er derfor en afgørende del af sikringen af MongoDB.
6. Revidere systemaktiviteter
Dette er en virksomhedsindstilling, der tillader sporing af alle ændringer af data og databasekonfigurationer. Hændelserne skrives til en syslog-forbindelse eller en eller anden logfil. Logfilerne kan indeholde DB-godkendelsesforsøg, herunder kilde-IP-adresser, og oplysningerne kan hjælpe med at bestemme, hvilke værter der skal blokeres af firewallen fra at få adgang til databasen. Desuden kan man finde ud af, hvilke begivenheder der skal logges.
Disse revisionslogfiler vil generelt hjælpe administratoren med at udføre nogle retsmedicinske analyser og dermed sætte standard sikkerhedskontroller.
7. Brug dedikeret bruger til at køre MongoDB
MongoDB-processer bør køres med en dedikeret operativsystembrugerkonto, som bør have adgangstilladelser aktiveret.
8. Brug officielle og opdaterede MongoDB-pakker
Bestå ægthedstjek på dine pakker for at sikre, at de er de officielle MongoDB-pakker. Brug af de nyeste MongoDB-drivere og den nyeste version af selve databasen giver mere sikkerhedsstabilitet end forgængerne. For eksempel tilbyder version 4.2 kryptering af feltniveau på klientsiden. Sørg derfor for at migrere til den seneste version af MongoDB.
9. Deaktiver Javascript-udførelser, hvis det ikke er nødvendigt
mapReduce og $hvor er nogle af de eksekverbare JavaScript-koder i MongoDB, og hvis de ikke administreres godt, kan de resultere i uønsket datainkonsistens eller tillade en at få adgang til dataene indirekte og anvende nogle ændringer, hvis de ønsker at .
Generelt tillader denne JavaScript-kode eksterne indsprøjtninger, og derfor kommer uvaliderede data ind i din database. Du kan også vælge at bruge pakker såsom mongoose til at validere og oprette forbindelse til din database. Brug MongoDB-operatorer i stedet for JavaScript-udtryk.
10. Bliv opdateret med MongoDB-sikkerhedsrettelser
Sikkerhedsprotokoller kan blive brudt af angribere med tiden, og derfor skal en til at involvere avancerede procedurer. Det er meget vigtigt at holde sig ajour med de bedste sikkerhedsopdateringer og fejlrettelser fra MongoDB-udgivelsesnoterne. MongoDB-advarselssiden blev grundlæggende oprettet til dette formål.
Anmod om en sikkerhedsteknisk implementeringsvejledning, hvis det er muligt, og sørg for, at din implementering er i tråd med overholdelse af sikkerhedsstandarder.
Konklusion
Databaser i produktion er tilbøjelige til sikkerhedsangreb, og derfor skal man investere kraftigt i at beskytte følsomme data. Sikkerhedsprocedurerne spænder fra data-i-transit, data-at-rest og de tilsluttede klientapplikationer. Udover ovennævnte praksis vil serverhærdende virksomheder give endnu et lag af databeskyttelse.
Det er vigtigt at bruge de seneste versioner af MongoDB og plugins udover at holde sig opdateret med den seneste sikkerhed og fejlrettelser relateret til din version.