7 AWS sikkerhedsproblemer og Best practice

Hvor sikker er skyen?

Når man diskuterer AWS-sikkerhedsproblemer, er det naturligt at spørge om sikkerheden i skyen. For at være helt tydelig, så er det meget sikkert. AWS og andre store Cloud platformsudbydere gør en kæmpe indsats for at holde systemerne sikre og vedligeholde deres certificeringer og processer.

Sikkerhedsproblemer kan dog dukke op i løsninger og komponenter i AWS under implementeringsprocessen. For eksempel fandt en nylig rapport i 2018 og 2019, at 90% af de cloud-baserede sikkerhedsproblemer skyldtes forkert konfiguration.

Dette betyder, at problemet opstod i skyen, men synderen var menneskelig fejl ifm organisationens konfiguration af løsningen.

Heldigvis kan fokus og træning minimere mange af disse sikkerhedsproblemer.

Ikke at have nogen med ansvar for sikkerheden

Sikkerhed er et fælles ansvar, når du arbejder med AWS eller en hvilken som helst cloud-udbyder. Men mange administratorer er uvidende om, hvad AWS håndterer, og hvad de skal administrere på deres side.

Antag venligst ikke, at standardkonfigurationen passer til dine behov, når du implementerer og bruger AWS. Det er vigtigt at få en kyndig person til at kontrollere og administrere dine konfigurationsindstillinger.

AWS tilbyder desuden mange tjenester, som alle har forskellige grader af ansvar. Så det er vigtigt at forstå disse forskelle, når du vælger din tjeneste.

EC2, for eksempel, sætter din side ansvarlig for sikkerheden. Dit team skal konfigurere operativsystemet, administrere applikationer og beskytte data. Det er en stor opgave!

Overbrug af Public Subnet

Din virksomhed kan vælge standard Virtual Private Cloud i AWS uden at ændre konfigurationen. Men når de skal oprette en ny applikation, er det fristende at bruge det Public Subnet, der er indbygget i AWS som standard.

Denne tilgang er dog farlig. Public Subnet bruger internet gateways, og de kan tilgås via det tilgængelige internet. Det betyder, at alle nemt kan se private data, der er hostet på subnettet.

Hvis din applikation skal være tilgængelig for offentligheden, så prøv en blanding af private og offentlige emner, så kritiske databaser og funktionalitet ikke kan tilgås på det offentlige internet.

Giver for mange tilladelser

At give brede tilladelser er et almindeligt problem i mange organisationer. Det er trods alt nemmere at konfigurere brede tilladelser. Og det sikrer, at alle har den adgang, de skal bruge for at udføre deres arbejde.

Men ureguleret systemadgang kan gå galt. Brugere kan snart få adgang til områder, de ikke burde have, og foretage ændringer, de ikke bør foretage.

Men efter en måned glemmer du alle de personer, der fik administratoradgang. Sikkerhedsrisikoen her er, at en uærlig virksomhedsinsider kan trække private eller følsomme data ud til enhver tid. De kan også beskadige ressourcer, som systemet kører, og endda tilbagekalde adgang for andre medarbejdere.

Så, hvis du giver total administratoradgang til en tjeneste til én person, bør du kraftigt genoverveje. Af sikkerhedsmæssige årsager bør din politik tilbyde de færreste tilladelser, der er nødvendige for at få opgaven udført.

Udsatte rodkonti

Systemets root-konto kan gøre meget skade, hvis en uautoriseret person får adgang til dem. Desværre deaktiverer alt for mange administratorer ikke adgang til root API'er. Dette kan være en dyr fejl.

Husk, at ingen i organisationen bør få adgang til AWS root-kontoen det meste af tiden – dette inkluderer dine mest betroede administratorer. Så del dem ikke på tværs af applikationer og brugere, ellers kan der opstå problemer.

Dine root-konti skal beskyttes med to-faktor-godkendelse og bør bruges sjældent.

Kun stole på adgangskoder

Mange nylige databrud og efterfølgende angreb involverer cyberkriminelle, der stjæler login oplysninger for at hacke andre konti. Et eksempel involverede ét databrud hos Colonial Pipeline sidste år, og virksomheden måtte betale hackere 4,4 millioner dollars for at få adgang igen.

Dette problem bør afklares: Det er ikke længere nok at have brugernavne og "stærke adgangskoder".

Du skal gennemtvinge robuste adgangskoder på AWS-systemer og bruge to-faktor-godkendelse. Når du bruger et program, skal du aktivere multifaktorgodkendelse. Enhver, der ikke bruger multi-faktor-godkendelse, bør straks fjernes.

AWS tilbyder værktøjer til at implementere tokens, så som smartphones eller fysiske kort, for at bruge multifaktor godkendelse. Jo oftere dit team bruger multifaktor autentificering med AWS, jo bedre bliver din virksomheds cybersikkerhed.

Sæt sikkerhed før værktøjer og kontroller

Mange mennesker i AWS-sikkerhedsdebatten spørger, hvordan vi generelt skal se cloud-sikkerhed. Skal vi prioritere værktøjer og kontroller eller tage sikkerhedsstrategi som første skridt? Det lyder enkelt, men det er mere komplekst, end du måske tror.

Det meste af tiden siger teknologiprofessionelle, at strategi skal håndteres først. Det betyder, at når du vurderer værktøjer og kontroller, kan du måle, hvor godt det understøtter din sikkerhedsstrategi.

Prioriteringsstrategi giver dig også mulighed for at indbygge cybersikkerhed i enhver virksomhedsfunktion. Dette er især relevant med udviklingsteamet og driften.

Lad os sige, at din virksomhed vælger et konfigurationsstyringsværktøj, der automatiserer softwarerettelser og opdateringer. At have en robust cybersikkerhedsstrategi gennemtænkt på forhånd, hjælper dig med at opsætte passende sikkerhedskontroller fra den første dag.

Hold din AWS-implementering sikker

Da din organisation implementerer og bruger AWS, er sikkerhed afgørende. Dit team kan holde AWS sikkert i dit virksomhedsmiljø ved at have medarbejdere uddannet i bedste praksis for AWS-sikkerhed.

Du kan få denne vigtige træning med vores online AWS-sikkerhedscertificering i dag, så kontakt os nu.