Det är ingen hemlighet att information får världen att gå runt just nu. Om ett företag tar hand om sina immateriella rättigheter och varje anställd enkelt kan få nödvändig information, kan företaget hoppas på tillväxt. Om det blir kaos i data kommer företaget att misslyckas trots lagandan.
I den här artikeln kommer vi att utforska grunderna för databassäkerhet och exempel på informationsskydd i Oracle. De teoretiska grunderna för att skydda information i databasen, som vi kommer att överväga i den här artikeln, kommer faktiskt också att vara användbara för personer som arbetar med andra databaser.
Åtkomstbehörigheter
I de flesta företag jag jobbade för hade alla administratörer och utvecklare full tillgång till databaser, liksom en anställd på IT-avdelningen var en gud och kunde göra vad de ville. Varför händer det? Det finns två anledningar till detta:
- Medan de arbetar på en avdelning kan anställda träffa varandra i 8 timmar varje dag och bli vänner. Hur kan de inte ge tillgång? Vänskap är en sak men affärer är affärer.
- Att bevilja vissa åtkomsträttigheter eller ändra någon konfiguration kan kräva vissa privilegier. Ibland tror administratörer att programmerare konfigurerar inställningar bättre. Således ger de programmerare onödiga åtkomsträttigheter. Istället får programmerare inte vara inblandade i administrationen och får inte ha några rättigheter för detta.
Enligt min erfarenhet är det andra problemet mycket vanligt, så vi kommer att analysera det i detalj.
När man utvecklar program för databaser känner programmerare till ett superanvändarlösenord eller har helt enkelt databasadministratörsrättigheter. Detta är onödigt och absolut osäkert. Endast databasadministratören måste ha fullständiga rättigheter. Även avdelningschefen, direktören och bästa vänner kan ha färre privilegier.
Till exempel när man utvecklar program räcker det att ha schemaägarrättigheterna i Oracle-databasen som lagrar arbetstabeller. Dessa rättigheter räcker för att skapa nya tabeller, paket, index och andra objekt, samt för att ge åtkomsträttigheter till schemaobjekt till andra användare. Du behöver inte systemrättigheterna för heltidsarbete.
Om det inte finns någon databasadministratör på heltid är det väldigt dåligt. Det är bättre när det finns någon som är ansvarig för databasprestanda, optimering och säkerhet. Åtminstone måste du utse en programmerare som kommer att ansvara för detta och som kommer att ha exklusiva rättigheter.
Enligt statistik orsakar anställda i företaget dataförlust oftast. Trots detta fortsätter de flesta företag att ignorera denna tråd och olika databaser lagrade på diskar med fri tillgång säljs även i tunnelbanan.
Användare och roller
Det finns två objekttyper för att ge åtkomsträttigheter i databaser:användare och roller. Roller är några grupper som kombinerar användare som måste ha liknande rättigheter. Till exempel kan alla revisorer kräva tillgång till ekonomiska dokument. För att förhindra att du beviljar rättigheter till varje revisor kan vi kombinera dem till en roll med nödvändig åtkomst.
Som du kan se liknar principen för roller grupper i Windows-operativsystemet. Ändå har det vissa skillnader. Inte utan anledning kan alla tre objekttyper som användare, grupper och roller implementeras i databasen. Det är dock bara användare och roller som implementeras i de flesta databaser. Det är nödvändigt att hantera och övervaka alla dessa objekt så att varje användare som erhåller rättigheterna som ges av rollerna kan få tillgång till den data som faktiskt krävs för att lösa uppgifter. Det är nödvändigt att använda åtkomsträttigheter som regler för en brandvägg. Genom att använda dessa rättigheter kan du lösa samma problem – att tillåta en användare att endast utföra vissa uppgifter och förhindra eventuell förlust eller korruption.
Med hjälp av roller är det ganska bekvämt att kontrollera åtkomst, ge behörigheter eller blockera hela användargruppen. En roll kan inkluderas i den andra och därmed ärver dess åtkomsträttigheter. Därför kan vi skapa en hierarkisk struktur av rättigheter.
Alla anställda med åtkomsträttigheter till en företagsdatabas kan inkluderas i en enda roll med minimirättigheter. Nu, om du behöver ytterligare privilegier, åtkomst till särskilda tabeller, måste du lägga till en användare till andra roller (om en grupp kräver samma åtkomst) eller tillhandahålla ett särskilt konto med rättigheterna.
I programmet, för att kontrollera åtkomsten till tabellerna, är det möjligt att kontrollera resultatet för fel efter varje försök att öppna datasetet. Om ett åtkomstfel uppstår blockeras åtkomsten till den angivna tabellen för en användare. Det finns alltså inget behov av att implementera åtkomsträttigheterna till klientapplikationen. Men om du vill implementera detta kommer det inte att ske någon skada. Jag ser åtminstone inget kritiskt i detta; det verkar ha motsatt effekt.
Säkerhetsrevision
Om varje användare arbetar under sitt eget konto i din databas kan du anropa användarvariabeln för att bestämma den aktuella användaren, till exempel:
SELECT user from dual
Denna fråga returnerar ett användarnamn under vilket anslutningen till servern öppnas. Om flera personer kan logga in med ett namn kommer denna fråga att returnera samma namn för båda och det skulle vara värdelöst för granskningen. Speciellt om lockoutkontroll sker på servernivå.
Om flera användare kan logga in med samma användarnamn är det komplicerat, men ändå möjligt, att identifiera vem som loggat in på kontot. Följande fråga låter dig få detaljerad information om sessionen:
select s.user#, s.username, s.osuser, s.terminal, s.program from sys.v_$session s WHERE username=user
Som du kan se returnerade frågan användarnamnet, kopplat till databasen, ett namn i operativsystemet, ett terminalanvändarnamn och ett program.
Här kan du komma åt v_$sessionsvyn från sys-systemschemat. Den här vyn returnerar viss information om anslutningarna till servern. I WHERE-satsen begränsar vi utmatningen till endast den aktuella användaren. Som ett resultat returnerar frågan användar-ID, namn, namn i operativsystemet, terminal och programmet från vilket anslutningen upprättades.
När du känner till ett användarnamn och ett terminalnamn kan du säkert identifiera en användare. För att veta vilka roller den aktuella användaren har lagts till kan du köra följande fråga:
SELECT GRANTED_ROLE FROM dba_role_privs WHERE grantee=user
Kontosäkerhet
Vi kommer inte att säga att det inte ska finnas standardlösenord. Vissa databaser, till exempel MySQL, gör fel när de skapar ett enkelt och välkänt systemlösenord efter installationen. Vi kommer inte heller att säga att lösenordet ska vara komplicerat. Denna regel gäller för alla IT-områden och bör vara känd även för en nybörjare. Vi kommer att prata om databasproblem.
Enligt min erfarenhet använder utvecklare samma konto för att komma åt en databas när de utvecklar företagsprogram. Parametrarna för detta konto registreras direkt i programmet, medan åtkomsten till särskilda moduler, inklusive redovisning, lager, personalavdelning etc. implementeras på ett programmatiskt sätt. Å ena sidan är denna metod bekväm, eftersom programmet kan ansluta till databasen med administratörsrättigheter och kommer inte att behöva ta hand om rollerna och åtkomsträttigheterna till tabellerna. Å andra sidan är denna metod långt ifrån säker. Nivån på användare växer, och vänner till ditt företags anställda kan utbildas inom området säkerhet och hacking. Efter att ha känt till namnet och lösenordet, under vilket programmet ansluter till databasen, kan en vanlig användare få fler möjligheter än du ville.
SQL-språket är inget hemligt och komplicerat språk. Det finns många program med vilka du enkelt kan se all data i databasen. Med användarnamnet och lösenordet kan vem som helst stjäla all din data. Således kommer den att säljas i vilket stall som helst som säljer diskar.
Ett användarnamn och lösenord får aldrig lagras i programmet. Tillgången till programmet måste också vara begränsad till och omöjlig för tredje part. Det är ganska logiskt att kombinera båda inloggningarna till en. Det är nödvändigt att skapa ett separat konto på databasservern med minsta nödvändiga rättigheter för varje användare i organisationen. Dessa namn och lösenord ska användas när du loggar in i programmet. Du kan använda en vanlig och mycket effektiv logik – om du kan logga in i databasen med de inmatade uppgifterna är åtkomsten tillåten; om inte måste du avbryta programmet. Denna process är enkel och effektiv eftersom vi använde databasauktorisering.
För att kontrollera att användare inte arbetar samtidigt från två olika datorer under samma namn, kan du utföra följande fråga:
select s.username, s.terminal, count(*) from sys.v_$session s WHERE username=user HAVING count(*)>1 GROUP BY s.username, s.terminal
Det får faktiskt inte returnera någon post.
Visningar
Vyer är ett mycket bekvämt sätt att stänga av datastrukturen och samtidigt bygga upp en extra skyddsnivå. Det är sant att åsikter har en negativ inverkan på produktiviteten, men de har en positiv inverkan på säkerheten. Vi kan ge deras egna åtkomsträttigheter, medan tabellerna från vilka data hämtas kan förbli otillgängliga för detta konto.
När är det bättre att använda vyer? Låt oss först definiera vad deras nackdelar är. En vy är en SELECT-sats för att hämta data. Den kan komma åt både, ett och flera bord. Om du bara väljer data från vyn blir det ingen prestandaförlust. Vi kan dock använda vyer i andra frågor för att välja data och hänvisa till dem när det gäller tabellerna. Till exempel:
SELECT list of fields FROM view, table_1, table_2 WHERE some parameters
I det här fallet hämtar frågan data från vyn och två tabeller. Dessutom kan vi se en relation mellan alla objekt och ett ytterligare villkor kan ställas in.
Låt oss nu titta på frågan som databasoptimeraren ser den:
SELECT list of fields FROM (SELECT ...), table1, table2 WHERE some parameters
I det här fallet ersatte jag vyn med en abstrakt SELECT-sats inom parentes som vyn består av. Det visar sig att servern ser en fråga med en underfråga. Om underfrågan returnerar dynamisk data, snarare än ett statiskt värde, kommer detta dataval att fungera långsammare än om vi skrev samma fråga utan underfrågan.
Datasäkerhet
Du bör aldrig ge full tillgång till föremål utan ett särskilt behov. Jag börjar alltid tillhandahålla rättigheter endast för att tillåta dataurval med SELECT-satsen. Om användaren verkligen behöver infoga nya poster och de inte kan utföra de uppgifter som tilldelats dem, lägg i det här fallet till behörigheten på INSERT-satsen för den angivna tabellen.
De farligaste operationerna för data är modifiering och radering, nämligen UPPDATERA respektive DELETE. Du måste ge dessa rättigheter noggrant. Se till att data kan ändras eller raderas. Endast i detta fall, välj lämpliga rättigheter. Vissa tabeller är förlängda endast av naturen.
Det är nödvändigt att vara säker på att uppgifterna kommer att påverkas ofta. Tabellen över anställda kan till exempel utökas och ändras, men en enda post ska aldrig raderas. Borttagningen kan påverka bakgrunden till anställdas arbete, rapportering och dataintegritet. Fallet när en personalansvarig av misstag lägger till en extra post och vill radera den är fortfarande möjligt. Sådana fall är dock sällsynta och felet kan åtgärdas av databasadministratören. Vi förstår att ingen vill överarbeta och att det är lättare att ge tillstånd, men säkerhet är mer värdefull.
Tilldelning av rättigheter utförs med hjälp av GRANT-operatören. I allmänhet ser det ut så här:
BEHANDLA det som ska ge rättigheter till ON-objekt TILL användare eller roller
Till exempel ger följande fråga rätt att infoga och visa TestTable-tabellen till User1:
GRANT Select, Insert ON TestTable TO User1
Främmande nycklar
Många användare är rädda för främmande nycklar eftersom de vanligtvis inte tillåter radering av data när det finns en yttre koppling. Problemet kan enkelt lösas om en kaskadradering etableras. Men de flesta specialister ogillar denna möjlighet. En löjlig handling kan korrumpera mycket viktig data utan några bekräftelseförfrågningar. Länkad data måste raderas explicit, och endast om användaren medvetet har bekräftat att data kan raderas.
Var inte rädd för främmande nycklar. De ger oss ett bekvämt sätt att kontrollera dataintegriteten från databasservern, så detta är säkerhet som aldrig skadar. Att det kan finnas problem med raderingen är bara en fördel. Det är bättre att inte radera data snarare än att förlora den för alltid. Den främmande nyckeln tillsammans med indexet minskar inte prestandan. Detta är bara en liten kontroll när du raderar data eller ändrar nyckelfältet som data är kopplade till i olika tabeller.
Säkerhetskopiering
Säkerhetskopiering är också en av säkerhetsfaktorerna vi ignorerar innan den första dataförlusten. Men personligen skulle jag ha tagit med det i de viktigaste. Dataförlusten kan orsakas inte bara av hackare och olämpliga användare utan också på grund av utrustningsfel. Fel i utrustningen kan leda till databasförlust, vars återställning kan ta timmar eller till och med dagar.
Det är nödvändigt att utveckla den mest effektiva säkerhetskopieringspolicyn i förväg. Vad menas med det? Driftstopp som orsakas av dataförlust och fram till ögonblicket för återställning av arbetskapaciteten bör vara minimal. Dataförlusten bör också vara minimal och säkerhetskopieringen bör inte påverka användarens arbete. Om det finns pengar och möjligheter är det bättre att använda sådana system som RAID, kluster eller till och med datareplikering.
Säkerhetskopiering och återställning är ett separat och intressant ämne. Vi kunde inte beröra det här, men vi kommer inte att överväga det i detalj.
Sammanfattning
Vi har övervägt säkerhetsgrunderna, särskilt för Oracle. Glöm inte att skyddet som tillhandahålls av databasen bara är en nivå, medan skyddet måste vara på flera nivåer. För att sova lite med ett klart sinne är det nödvändigt att implementera hela säkerhetsfunktionerna på nätverket, servrar och alla datorer, inklusive antivirus, antispionprogram, VPN, IDS, etc. Ju fler skyddsnivåer det finns, desto mer svårt kommer det att bli att övervinna dem.
Det bör finnas en tydlig säkerhetspolicy och kontroll. Om en anställd slutar raderas dennes konto. Om du har användare som arbetar med samma lösenord eller använder ett grupplösenord för att utföra några uppgifter, måste alla dessa lösenord ändras. Till exempel, om en administratör lämnar och du har alla administratörer som använder samma konto, måste du ändra lösenordet.
Säkerheten är nödvändig. Du måste skydda dig inte bara från hackare utan också från "nybörjare", som kan korrumpera data genom sin oerfarenhet. En bra säkerhetspolicy hjälper till att förhindra sådana fall och denna möjlighet kan inte uteslutas. Det är bättre att tillhandahålla möjligheten att säkra data från oerfarenhet i förväg än att förlora mycket tid för att återställa data och få onödig driftstopp.
Läs även:
Ställa in åtkomstbehörigheter för databas