Hur Ska Du Säkra Din Databas?

0
230
Shutterstock/hywards

Din databas-server innehåller ofta dina mest känsliga uppgifter, såsom konfidentiell information till användare. Det är viktigt att implementera säkerhet för bästa praxis för att minimera risken för en angripare att få åtkomst till din databas.

Denna guide kommer att vara för MySQL i synnerhet, eftersom det är den vanligaste databasen, men de flesta av dessa begrepp kommer att gälla för varje typ av databas—du kommer bara att kräva olika konfigurationer för att uppnå samma effekter.

Se till att Köra mysql_secure_installation

MySQL har ett inbyggt verktyg som kan hantera några grundläggande trygghet uppgifter. Efter att du installerat MySQL genom att köra följande kommando i terminalen:

mysql_secure_installation

Detta kommer att gå igenom några uppgifter—ange ett nytt lösenord, ta bort anonyma användare och testa databaser och inaktivera root-inloggning. Efteråt, det kommer att ladda MySQL config för dig, så du bör kunna se ändringarna omedelbart.

Lås SSH

Om detta inte är tekniskt har något att göra med själva databasen, men din databas är bara så säker som din server är det körs på, så du vill att vidta nödvändiga åtgärder för att låsa SSH och förhindra att de flesta av de vanligaste angreppsvägarna.

Du kan läsa vår kompletta guide om SSH-säkerhet för att lära sig mer, men kontentan av det är ett par steg:

  • Inaktivera lösenordet för inloggning, använd SSH-nycklar bara.
  • Gräns misslyckade inloggningsförsök med denyhosts för att förhindra våld.
  • Vitlista tillgång till betrodda IP-adresser.
  • Inaktivera root-inloggning via SSH—på det här sättet, anfallare behöver veta ditt användarnamn.
  • Ställa in Multi-Faktor Autentisering för SSH om du är riktigt paranoid.

Kör en Fristående Databas i ett Privat Subnät

Snarare än att köra en lokal databas på samma server som nginx är att köra på, det är bättre för säkerhet att köra din databas i ett privat subnät som endast är tillgänglig genom andra servrar i ditt privata moln. Många moln-leverantörer, inklusive AWS, erbjuder dessa funktioner.

Setup ser ut så här:

Din Virtual Private Cloud (VPC) är helt enkelt den behållare som alla dina AWS resurser köra på. Saker i detta moln kan prata med varandra om sina privata IP-adresser precis som enheter i ditt hem skulle interagera.

Servrar i den offentliga subnet kommer att få publika IP-adresser, och kommer att vara direkt tillgänglig för vem som helst. Servrar i privat subnät inte har den offentliga IP-adresser—bara en privat och en. De kan fortfarande få åtkomst till internet, genom att använda Network Address Translation, samma metod som ger er tillgång till dator bakom en router.

Detta innebär att alla servrar som lanserades i privat subnät kommer att vara helt otillgängliga från yttre angripare. Det enda sättet din databas kan nås om webbservern är nedsatt, och även då är det fortfarande skulle kräva en utökning av privilegier.

På toppen av förmåner, denna konfiguration är också mycket lättare att skala. Du kan till exempel ha fyra webbservrar som kör WordPress som alla ansluta till en enda officiell databas-server. På detta sätt, alla fyra webbservrar är i synk, och du kan lätt skala upp och ner för att möta efterfrågan, utan att behöva oroa databasen. Detta kan orsaka vissa prestandaproblem på grund av nätverk overhead, men med rätt multilayer caching, problemet är minimal i förhållande till den arkitektoniska fördelar.

Att MySQL bara acceptera anslutningar från privata anslutningar, kommer du vill använda en nätmask i din GRANT uttalande. Det fungerar inte med CIDR-notation—bara fullt nätmask.

GE ALLA PÅ databasen.* TILL “användare” @ “10.0.1.0/255.255.255.0” IDENTIFIERAS MED “lösenord”

Om du kommer att bara köra en server, bör du åtminstone binda din databas till localhost så att det inte är tillgängligt från det öppna internet i alla fall.

Binder till Localhost om det är Möjligt (eller Åtminstone en Annan Port)

Om du inte komma åt din databas-server från något annat än andra processer som körs på den maskinen själv, du kan låsa ner det så att det inte är tillgängligt över nätverket. Naturligtvis fungerar detta bara om du har en server som kör allt, och det är inte den bästa konfigurationen i första hand.

Om du inte kan binda till localhost, det är en bra idé att ändra den förvalda porten till något annat.

Antingen sätt, detta kan du göra ganska enkelt genom bindande MySQL till localhost, vilket innebär att det endast kommer att lyssna på loopback-adress, och inte på eventuella öppna portar. Öppna /etc/mysql/min.conf i din favorit textredigerare och lägg till följande rad under [mysqld] avsnitt:

bind-adress = 127.0.0.1

Du kan också ändra standard port från samma avsnitt:

Port=5000

Starta om MySQL, och du bör kunna se ändringarna.

Titta På Ditt Skal Historia

De flesta saker du gör i Linux är inloggad. Om en angripare lyckas att få tillgång till dessa loggfiler, de kunde eskalera sina privilegier genom att hitta lösenord som lagras i dem.

Detta kan ske på två huvudsakliga sätt för MySQL, som båda är lätt att förebygga. Den första är när du loggar in på MySQL-skal—du vill aldrig att ange de lösenord som argument på kommandoraden. Alltid lämna det tomt, och låt MySQL be om det.

mysql -u root -p

Annars är det synliga med hjälp av history-kommandot.

MySQL har också sin egen historia-fil, lagrad på ~/.mysql_history. Detta gäller naturligtvis inte logga in med det lösenord du använder för att logga in, men om du skapat en ny användare från MySQL-kommandot line, det uttalandet kommer att loggas—lösenord och allt. Du vill rensa denna fil som en försiktighetsåtgärd om du någonsin har för att ändra användarkonton.

# cat /dev/null > ~/.mysql_history

Om Du är på AWS, Överväga att Använda RDS –

AWS är Relational Database Service (RDS)är ett helt lyckats databas i molnet. Om du inte vill oroa dig för databasen säkerhet, och bara vill ha en gångbar lösning, RDS (och alla AWS andra lyckades databas tjänster) kommer att ta bort huvudvärk.

RDS använder AWS egen Identitet och åtkomsthantering (IAM) system. IAM hanterar behörigheter för allt du gör på AWS. Varje handling i den webbaserade hanteringskonsolen, CLI-kommandon, och API-förfrågningar måste alla gå igenom IAM. Alla åtgärder kommer att blockeras om användare eller en enhet som utför inte har uttryckligt tillstånd att komma åt viss resurs. På toppen av det, om det är en RDS privata som standard, så du behöver inte oroa dig för attacker från det öppna internet.

Du kommer ändå att sluta med standard MySQL användarnamn och lösenord för att ansluta till databasen sig om—IAM helt enkelt säkrar allt annat om databasen, såsom konfiguration. Du kan dock använda AWS Hemligheter Manager, som gör att du ständigt rotera nycklar säkerhet utan kod omfördelningar, och har inbyggd integration för RDS för att starta.

Om du vill kan du också vända på IAM Databas Autentisering, vilket gör att du kan kringgå lösenordet auth helt och hållet och bara använda IAM. Men det lägger till en del overhead, och som sådan, är hastigheten begränsad till 200 nya anslutningar per sekund för MySQL.