Topp topp 10 AWS Cloud Security -risikoer og hvordan du kan løse dem
Denne artikkelen vil forklare de ti mulige sikkerhetssårbarhetene som kan føre til sikkerhetstrusler og også mulige løsninger i AWS -miljøet for å overvinne og løse disse sikkerhetsrisikoene.
1. Ubrukte tilgangsnøkler
En av de vanligste feilene mens du bruker en AWS -konto er å forlate ubrukte og ubrukelige tilgangsnøkler i IAM -konsollen. Uautorisert tilgang til tilgangsnøkler i IAM -konsollen kan føre til store skader, da det gir tilgang til alle tilkoblede tjenester og ressurser.
Løsning: Den beste praksisen å overvinne dette er å enten slette de ubrukelige eller ikke-brukte tilgangstastene eller rotere legitimasjonen til tilgangstastene som er nødvendige for bruk av IAM-brukerkontoer.
2. Offentlig amis
AMIS inneholder all informasjonen for å starte et skybasert system. Amis som blir offentliggjort kan nås av andre, og dette er en av de største sikkerhetsrisikoene i AWS. Når AMI deles mellom brukere, er det en mulighet for at det har viktige legitimasjoner igjen. Dette kan føre til tredjeparts tilgang til systemet som også bruker samme offentlige AMI.
Løsning: Det anbefales at AWS -brukere, spesielt store bedrifter, bør bruke private AMIS til å starte forekomster og utføre andre AWS -oppgaver.
3. Kompromittert S3 -sikkerhet
Noen ganger får S3 -bøttene med AWS tilgang i en lengre periode som kan føre til datalekkasjer. Å motta mange ukjente tilgangsforespørsler til S3 -bøttene er en annen sikkerhetsrisiko, da sensitive data kan lekkes på grunn av dette.
Dessuten er S3 -bøttene som er opprettet i AWS -kontoen, som standard, private, men kan offentliggjøres av noen av de tilkoblede brukerne. Fordi en offentlig S3 -bøtte kan nås av alle brukerne som er koblet til kontoen, forblir dataene til en offentlig S3 -bøtte ikke konfidensielle.
Løsning: En nyttig løsning på dette problemet er å generere tilgangslogger i S3 -bøtter. Tilgangslogger hjelper deg med å oppdage sikkerhetsrisiko ved å gi detaljer om innkommende tilgangsforespørsler, som forespørselstype, dato og ressurser som brukes til å sende forespørsler.
4. Usikker Wi-Fi-tilkobling
Å bruke en Wi-Fi-tilkobling som ikke er sikker eller har sårbarheter, er nok en årsak til kompromittert sikkerhet. Dette er et problem som folk vanligvis ignorerer. Likevel er det viktig å forstå koblingen mellom usikker Wi-Fi og kompromittert AWS-sikkerhet for å holde en sikker forbindelse mens du bruker AWS Cloud.
Løsning: Programvaren som brukes i ruteren må oppgraderes regelmessig, og en sikkerhetsgateway bør brukes. En sikkerhetskontroll må brukes for å bekrefte hvilke enheter som er tilkoblet.
5. Ufiltrert trafikk
Unfiltered og ubegrenset trafikk til EC2 -forekomster og elastiske belastningsbalanser kan føre til sikkerhetsrisiko. På grunn av en sårbarhet som dette, blir det mulig for angriperne å få tilgang til dataene fra applikasjonene som er lansert, hostet og distribuert gjennom forekomstene. Dette kan føre til DDoS (distribuert tjeneste for nektelse).
Løsning: En mulig løsning for å overvinne denne typen sårbarhet er å bruke riktig konfigurerte sikkerhetsgrupper i tilfellene for å bare tillate autoriserte brukere å få tilgang til forekomsten. AWS Shield er en tjeneste som beskytter AWS -infrastrukturen mot DDoS -angrep.
6. Legitimasjonstyveri
Uautorisert legitimasjonstilgang er hva alle online plattformer bekymrer seg for. Tilgang til IAM -legitimasjon kan forårsake store skader på ressursene som jeg har tilgang til. Den største skaden på grunn av legitimasjonstyveri til AWS -infrastrukturen er ulovlig tilgang til rotbrukeropplysning fordi rotbrukeren er nøkkelen til hver tjeneste og ressurs til AWS.
Løsning: For å beskytte AWS -kontoen mot denne typen sikkerhetsrisiko, er det løsninger som multifaktorautentisering for å gjenkjenne brukerne, ved å bruke AWS Secrets Manager for å rotere legitimasjon, og strengt overvåke aktivitetene som er utført på kontoen.
7. Dårlig styring av IAM -kontoer
Rotbrukeren må være forsiktig mens han oppretter IAM -brukere og gir dem tillatelser. Å gi brukere tillatelse til å få tilgang til ekstra ressurser de ikke trenger, kan forårsake problemer. Det er mulig i slike uvitende tilfeller at de inaktive ansatte i et selskap fremdeles har tilgang til ressursene gjennom den aktive IAM -brukerkontoen.
Løsning: Det er viktig å overvåke ressursutnyttelse gjennom AWS CloudWatch. Rotbrukeren må også holde kontoinfrastrukturen oppdatert ved å eliminere de inaktive brukerkontoer og gi tillatelser til de aktive brukerkontoer riktig.
8. Phishing angrep
Phishing -angrep er veldig vanlig på alle andre plattformer. Angriperen prøver å få tilgang til konfidensielle data ved å forvirre brukeren og late som om han er en autentisk og pålitelig person. Det er mulig for en ansatt i et selskap som bruker AWS -tjenester å motta og åpne en lenke i en melding eller en e -post som ser trygt ut, men som leder brukeren til et ondsinnet nettsted og ber om konfidensiell informasjon som passord og kredittkortnumre. Denne typen cyberangrep kan også føre til irreversibel skade på organisasjonen.
Løsning: Det er viktig å veilede alle de ansatte som jobber i organisasjonen for ikke å åpne ukjente e -postmeldinger eller lenker og umiddelbart rapportere til selskapet hvis dette skjer. Det anbefales at AWS -brukere ikke kobler rotbrukerkontoen til eksterne kontoer.
9. Feilkonfigurasjoner i å tillate ekstern tilgang
Noen feil fra uerfarne brukere mens de konfigurerer SSH -tilkoblingen kan føre til et stort tap. Å gi ekstern SSH -tilgang til tilfeldige brukere kan føre til store sikkerhetsproblemer som Nektelse av serviceangrep (DDoS).
Tilsvarende, når det er en feilkonfigurasjon når det. Feilkonfigurasjonen ved å sette opp en RDP -tilkobling kan forårsake irreversibel skade.
Løsning: For å unngå slike omstendigheter, må brukerne begrense tillatelsene til bare de statiske IP -adressene og tillater bare autoriserte brukere å koble seg til nettverket ved hjelp av TCP Port 22 som verter. Ved RDP -feilkonfigurasjon anbefales det å begrense tilgangen til RDP -protokollen og blokkere tilgangen til ukjente enheter i nettverket.
10. Ukrypterte ressurser
Behandling av dataene uten kryptering kan også forårsake sikkerhetsrisiko. Mange tjenester støtter kryptering og må dermed være riktig kryptert som AWS Elastic Block Store (EBS), Amazon S3, Amazon RDS, Amazon Redshift og AWS Lambda.
Løsning: For å forbedre skysikkerheten, må du sørge for at tjenestene som har sensitive data må krypteres. For eksempel, hvis EBS -volumet blir uenkryptert på opprettelsen, er det bedre å lage et nytt kryptert EBS -volum og lagre dataene i det volumet.
Konklusjon
Ingen online plattformer er helt sikre seg selv, og det er alltid brukeren som gjør den enten sikker eller sårbar for uetiske cyberangrep og andre sårbarheter. Det er mange muligheter for angripere å knekke AWSs infrastruktur og nettverkssikkerhet. Det er også forskjellige måter å beskytte AWS Cloud Infrastructure fra disse sikkerhetsrisikoene. Denne artikkelen gir en fullstendig forklaring av AWS -sikkerhetsrisiko så vel som deres mulige løsninger.