Har du hørt om multi-cloud sikkerhed? Hvis du tager en ny applikation eller ide med til dit DevOps team, hvad er så den mest almindelige respons? Formentlig tøven. Selv hvis de siger ja, er sikkerhedsteamet lige efter og de gør nok lidt mere modstand. Du kan dog ikke bebrejde dem!

Nye deployments introducerer ændringer og et potentielt knæk i koden, der kan få ting til at gå ned. For et InfoSec team, er deres største interesse sikkerheden for organisationen og her er din ide en potentiel trussel.

Desværre er måden, hvorpå udviklingsteams arbejder og måden DevOps og sikkerhedsteams arbejder på, ikke altid ens. Udviklere er klar til at deploye dagligt eller endda flere gange om dagen. DevOps foretrækker at deploye hver 2 – 4 uge. Sikkerhedteamet håndterer flere netværk, identiteter og teknologier end nogensinde før, hvilket gør sikkerhed kompliceret og tidskrævende.

Sikkerhed er en vej, ikke en destination. Dit team har brug for en alt-i-en rejse for at arbejde mere problemfrit og sikkert. De seks trin, jeg har listet op nedenfor er et fundament. Hvis det følges, kan det hjælpe dig med at rette din energi og ressourcer til det der er mest vigtigt.

Identitet

Identitet er den første del af fundamentet. Hvis nogen kan få root adgang, er der intet andet der hjælper. En centralt, omend svært, sted at starte er med en centraliseret identitetsudbyder, der kan fortælle hvem folk er og hvordan de skal autentificeres. Rollebaseret adgangskontrol bør administreres i grupper for at undgå det jeg kalder one-off adgange (adgange der gives og glemmes at de er givet)

En forholdsvis almindelig identitetstrussel er adgangskoder. Jeg har været administrator i forskellige Enterprise netværk og for at være helt ærlig, så er adgangskoder og mennesker to ting der er forfærdelige. Enten gør folk dem for simple, glemmer deres adgangskode eller skriver den ned på et stykke papir. Multi-faktor identifikation giver rigtig god mening, hvis man højen sikkerheden i multi-cloud systemer.

Endeligt – Lav en streng sikkerhedsstyring for at styrke privilegerede konti (admins). Tænk på din cloud administrator for Azure, Salesforce, AWS, GCP eller et active directory. Her vil jeg anbefale at opsætte multi-factor identifikation med en tidsbegrænsning for kontoen som samtidig ajourfører en log for aktiviteten.

Nu sidder du sikkert og tænker: “Det går min IT-administrator / supporter” aldrig med til.. Det kan godt være.. men jeg er ret sikker på at de vil forstå det, hvis du forklarer dem hvad konsekvensen kan være. Her taler jeg om at blive udsat for et hacker-angreb.

Data

Identitet bruges til at tilgå data. Når det kommer til datasikkerhed, er det vigtige at beskytte data end selve data opbevaringen. Kun data er portabelt. Chancen for at en med elefanthue over hovedet går ind i dit datacenter for, at stjæle en fysisk harddisk er nærmest ikke eksisterende.

Du bør altid kryptere data, når det ikke er i brug, i transit eller endda i hukommelsen (memory). Rigtig mange af cloud-tjenesterne har allerede denne type kryptering, hvilket tager hånd om mange problemer der opstår i forbindelse med datasikkerhed.

Der er dog lige det, at når det lander på en stationær eller bærbar computer, bliver det svært at beskytte. Et kæmpe problem mange ofte begår er klassificering. Gør din klassificering simpel (det kan hurtigt tage overhånd med navngivning).. Jeg vil næsten sige du skal have 3 – 5 forskellige niveauer og måske 1 – 2 klassificeringer til data der skal kunne udleveres til en kunde.

Infrastruktur

Best practice når vi taler sikkerhed og infrastruktur er at lagdele dit forsvar. Prøv at lagdele firewalls og anden infrastrukur. Som det er med data, skal du have fornuften med dig, når du gør det. Hvis noget går galt eller ned, skal du bruge mindre tid på at fejlsøge, hvis du ikke har overkompliceret det hele.

Overvej at lave skabeloner for din infrastruktur, hvis så nogen ønsker at deploye en app, er sikkerheden allerede “bagt” ind fra starten. En sidste ting – lyt til dine brugere. Hvis de ikke kan bruge systemet, går de uden om det! Som du nok kan regne ud, er det her der sker brud.

Automatisering

Ud af alle disse 6 grundlæggende elementer skal du være mest forsigtig med automatisering. En lille fejl på en server, kan ligge hele din virksomhed ned. Der hvor jeg vil anbefale automatiseringer er ved din compliance. Smid det direkte ind i systemet så pipelinen opdaterer deploy med sikkerhed for øje.

Uanset hvad du vælger at automatisere, skal du stadig indarbejde nogle kontroller og manuelle “porte” i processen. Det at få et par rigtige øjne på et deployment vil hjælpe dig med at fange store fejl, som din automatisering ville have overset. Stil altid dig selv spørgsmålet “Er det her virkelig den handling vi ønsker at udføre”?

Samarbejde

Den har bør være ret indlysende taget den aktuelle tilstand af multi-cloud i betragtning – forsøg at samarbejde på tværs af teams. Få dit InfoSec hold integreret i processerne for dit udviklingsteam. Ofte kommer sikkerhedsteamet ind for sent, hvilket betyder redesign og frustrationer hos udviklerne. Hvis du får DevOps og sikkerhed med ind i det samme rum, fra starten, kan i opsætte klare mål der vil styre hele processen.

Analyse

Cloud er en saksagelig fætter og i et multi-cloud miljø, kan man godt køre helt træt i logs. Forsøg at standardisere på en platform for nemmere at analysere dine logs. Selvfølgelig har hver cloud sin egen log, men en platform af tredjepart er ofte den bedste vej at gå med flere clouds. Det er heller ikke en dårlig ide at udlicitere analysedelen til en virksomhed udefra der specialiserer sig i at finde trusler og som kan forstå aktiviteten på tværs af dine clouds.

Kom i gang

Det er en nødvendighed at opretholde en stærk sikkerheds, når det kommer til multi-cloud arkitektur. Få dine DevOps, InfoSec og udviklingsteams til at arbejde rundt om disse principper. Det vil ikke kun sikre din egen organisation, men også dine kunders.

Leave a Reply