Amazon vil stramme op for sikkerheden i skyen: »Udvikling og sikkerhed bør ikke adskilles«

Illustration: Sergey Nivens/Bigstockphoto.com
Amazon ønsker at gøre god sikkerhed i skyen let tilgængelig ved at tilbyde værktøjer og sikkerhedsløsninger, som er nemme at anvende for alle udviklere. Men et delt sikkerhedsansvar kan også føre udfordringer med sig.

»Vi forsøger at demokratisere sikkerheden ved at give udviklingsteams byggeklodser, værktøjer og vejledninger, så de kan sikre deres systemer i skyen bedst muligt.«

Amazons Chief Information Security Officer (CISO), Steve Schmidt har lige givet sin keynote til Amazons re:Inforce-konference i Boston, USA, da Version2 møder ham til et interview om sikkerhed i skyen.

Det er første gang Amazon holder en konference dedikeret til cloud security, og skal man dømme efter antallet af konferencedeltagere, er det en stor succes. Over 7000 deltagere fordelt over 2 dage i byen, hvor tea party-protesten i 1773 blev startskuddet på de amerikanske koloniers løsrivelse fra Storbritannien og etableringen af USAs demokrati.

Den såkaldte demokratisering af cloud security, som Steve Schmidt taler om, vil formentlig ikke føre til så voldsomme forandringer som tea party-protesterne, men der er afgjort brug for væsentlige forbedringer af sikkerhed i skyen, hvilket de mange læk af data fra cloudbaserede systemer bevidner.

Udviklerkultur skal omfatte sikkerhed

Amazon ønsker at gøre god sikkerhed i skyen let tilgængelig ved at tilbyde værktøjer og sikkerhedsløsninger, som er nemme at anvende for alle udviklere.

Det er blandt andet på den baggrund, at Amazon har besluttet at give sin årlige udviklerkonference re:Invent en søsterkonference i form af re:Inforce med fokus på sikkerhed. Men det handler ikke kun om værktøjer, det handler også om at ændre udviklerkulturen. Udviklere bør tænke lige så naturligt på sikkerhed som de tænker i Java, C# eller andre programmeringssprog.

»Vi gør vores bedste for at kunne vejlede og lære udviklere at tænke i sikkerhed. Der bør ikke være adskillelse mellem udvikling og sikkerhed. Vi bør ikke udvikle uden at tænke sikkerhed og ikke have noget i produktion uden sikkerhed,« siger Steve Schmidt.

Amazon stiller en række af sikkerhedsløsninger og -produkter til rådighed, ligesom partnere som Symantec, McAfee, Palo Alto Networks og andre leverandører står klar med deres løsninger til en sikker sky.

Men er det nok?

Eller rettere, er det for meget?

Machine Learning identificerer trusler

På en af Steve Schmidts keynote-slides er der listet 27 Amazon cloud-sikkerhedsservices og løsninger under titlen »Best Security building blocks in the cloud.«

En af dem er GuardDuty, der checker om der foregår ondsindet eller usædvanlig aktivitet ved at analysere data fra logfiler på tværs af AWS-økosystemet ved hjælp af Machine Learning og detektering af anomalier. Det rejser selvfølgelig spørgsmålet om, hvor mange falske positive – events, der klassificeres som ondsindede eller usædvanlige, men i realiteten er harmløse - GuardDuty genererer.

Ifølge Rudy Martin, der også er med på re:Inforce-konferencen, udgør problematikken med falske positive netop en ulempe i sikkerhedsløsningen. Han er CISO ved danske Trustpilot, og han afprøvede GuardDuty, efter servicen blev lanceret sent i efteråret 2017.

»GuardDuty gav os for meget information. Der var for mange falske positive,« siger Rudy Martin, og tilføjer dog, at han og hans team på det tidspunkt ikke havde nok tid til at se nærmere på sagen.

»Det kan være, at vi havde konfigureret det forkert. Efter 3 måneder slog vi det fra, da vi fik en alert på vores billing,« siger Rudy Martin, der dog har tænkt sig at se på GuardDuty igen.

Ifølge Steve Schmidt burde antallet af falske positive ikke være et problem.

»Andelen af falske positive er meget lav. Den feedback vi får fra vores kunder er, at den er lavere end fra andre systemer,« siger Steve Schmidt.

Den delte sikkerhedsmodel

AWS anvender en shared responsibility model, hvor AWS lover at tage sig af en del af sikkerheden, mens det er op til devops at sørge for, at den resterende del af sikkerheden håndteres korrekt.

Det kan give problemer, da adskillelsen mellem, hvad der er AWS' ansvar, og hvad der lægges på devops-skuldrene, varierer fra en AWS-service til en anden.

For EC2, Amazons sky-servere, tager AWS eksempelvis ansvaret for hypervisor-softwaren, der adskiller den fysiske hardware fra kundens virtuelle maskine. Alt, der ligger over hypervisor-laget er kundens ansvar i en standard EC2-instans.

For den relationelle database-service RDS tager AWS derimod ansvaret for den virtuelle maskine, styresystemet og selve databasen, så det kun er konfigurationen af database samt definition af firewall-regler, der overlades til devops.

Steve Schmidt er klar over, at den delte sikkerhedsmodel kan give anledning til misforståelser.

»Det er uheldigt, hvis kunderne tror at vi gør noget for dem, som vi reelt ikke gør,« siger Steve Schmidt og fremhæver i den forbindelse Amazons arbejde med at tydeliggøre fordelingen af sikkerhedsansvar.

Skal vænne sig til modellen

Hvis man har været vant til at få sine systemer hostet hos en traditionel hostingleverandør, så kan det være svært at vænne sig til den delte sikkerhedsmodel.

Det mener Kristoffer Hansen, AWS Solution Architect, fra det danske cloud consulting firma Keycore.

»Det, jeg ofte ser, er, at der ikke tænkes over compliance og shared responsibility model. Det forstår kunden ikke rigtigt, hvis de har været vant til en hostingleverandører, som traditionelt har sikkerhedsfolk og folk med juridisk indsigt til at sikre, at alting er i orden,« siger Kristoffer Hansen og uddyber:

»En udvikler tænker: Jeg skal have en database, en webserver og nogle lambda-funktioner. De tænker måske lidt applikationslogning, men sjældent compliance. Nu tager kunden og smider deres eksisterende infrastruktur op i AWS, hvor AWS tager hånd om al sikkerheden på deres side, men der hvor kunden selv skal kode, konfigurere, logge, sikre adgangskontrol og følge least privilege-princippet, kan det gå galt. Jeg vil ikke sige 80% af gangene, men over halvdelen af gangene er der ikke tænkt nok over det. Modenhedsgraden er ikke høj nok,« mener Kristoffer Hansen.

Sikkerhed som standardkonfiguration

Amazon forsøger derfor at bygge sikkerhed ind i standardkonfigurationerne for diverse services, så tingene er beskyttet så godt som muligt fra start.

Det gælder eksempelvis for EC2, hvor en firewall er med som standardkonfiguration.

»Firewallen er lukket ned, så kunderne skal selv lukke den op. Det er en god sikkerhedsregel,« siger Steve Schmidt.

Ubeskyttede S3-buckets har historisk været noget som data-jægere har kunnet finde interessante data i, men det burde også blive sværere fremover.

»Kunder har bedt os om at sikre at S3-buckets aldrig kan blive public, så vi har nyligt introduceret Block public access, som forhindrer S3-buckets i at blive offentligt tilgængelige,« siger Steve Schmidt.

Til at implementere Block Public Access har Amazon anvendt værktøjet Zelkova, der automatisk checker om brugerdefinerede adgangskontroller er i modstrid med god sikkerhedspraksis.

Zelkova er et værktøj, der anvender matematisk verifikation af sikkerheden, og det anvendes også i GuardDuty, Config, Trusted Advisor, Macie og IoT Device Defender.

Når de automatiske værktøjer ikke er nok, så er der andre muligheder for at etablere god sikkerhedspraksis i skyen. Det er, hvad Kristoffer Hansen og hans kollegaer blandt andet tilbyder via templates til deres kunder.

»Vi laver templates, design for infrastruktur. I stedet for blot at spinne en ny EC2-instans får de en cloudformation template for en sikker VPC Virtual Private Cloud, der blandt andet indeholder en EC2-instans. Vi indtænker sikkerhed, roller og policies i de templates,« siger Kristoffer Hansen, der oplever, at de fleste udviklingshuse kan se fordelene med den slags templates, når konceptet forklares, men at de sjældent selv har etableret praksissen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (0)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Log ind eller Opret konto for at kommentere