Pro-tips der allerede nu kan skabe mere tryghed.
Hvis i ikke har en backup løsning, anerkender i at det ikke er vigtig data. Hvilket ofte ikke er tilfældet, derfor - brug tid på at finde gode backup løsninger der passer til jeres behov.
Hvis jeres backup løsning ikke er testet, hvordan ved i så om der reelt set er backup? Dyre backup løsninger der ikke bliver testet, kan hurtigt vise sig at blive en dårlig investering. Man får ikke altid det, man tror man betaler for.
Hvis i bare hurtigt sætter et nyt system i luften, med tanken om at tilføje IT-Sikkerhed bagefter, så har jeg en lille hemmelighed til jer – bagefter kommer aldrig. Desværre er det som et hus, hvor du har tænkt dig at bygge fundamentet efter huset er rejst.
Hvis i stadig manuelt opretter jeres servere eller deployer kode med ClickOps – så stop. Alt skal som minimum kunne versionstyres og genoprettes. Det tager unødig tid, og bidrager kun til unødig nedetid.
Vi har oplevet at flere firmaer, tror at Cloud kan erstatte deres IT-folk og bare kører videre automatisk. Desværre er virkeligheden sådan, at Cloud bare er en andens datacenter, du lejer dig ind. Du skal stadig stå for patching, vedlighold og vulnerability management. I slipper dog for fysisk hardware, vedligehold heraf og høje startomkostninger.
Mange teknikere har desværre misforstået koncepterne, og det gør det svært at skabe brugbar dialog medarbejdere imellem. Derfor er det vigtigt at oplyse sine medarbejdere, så der ikke sker misforståelser i DevOps afdelingen.
Det at have historik på metrics, og kunne følge med realtime på logning, er guld værd når man fejlsøger. Desværre er det nemt at "spare" penge på at droppe overvågning af kritiske systemer. Hvilket hurtigt kan blive dyrt, når første nedbrud melder sig.
Provisionering af resurser manuelt, er generelt en dårlig idé. Det er langsomt, ikke skalerbart, og garanterer fejl. Med IaC kan i sætte et POC op, og deploy det desired state i andre miljøer. Dette gør også, at man nemt kan genskabe miljøet, hvis der skulle opstå kriser. win-win.
Forkert IAM er årsag til de fleste sikkerhedshuller i cloud. Brug principper som least privilege og hold styr på service accounts og roller.
Cloududbyderen står for platformen, i har ansvaret for konfiguration af sikkerheden og data. Denne misforståelse kan koste jer dyrt, da Cloud er piv-åbent pr. standard. Alle kan altså få adgang til jeres data, hvis i ikke er obs herpå.
Medmindre det absolut ikke kan lade sig gøre, så lad hver med at flytte en VM 1:1, for at hoste services. Brug i stedet services som web apps, sql servers osv.
Design jeres netværk i Cloud med on-prem i mente, man ved nemlig aldrig hvornår, man får brug for at binde de 2 miljøer sammen. Derfor er det vigtigt med god ip-hygiene, så senere overlap undgåes.
I forbindelse med eksempelvis RPA (Robot Process Automation), er det muligt at kun bruge resurser, når de reelt bliver brugt. Cloud er skalerbar, hvilket er en kæmpe styrke. Det kan spare jer for mange penge, hvis det bliver brugt korrekt.
Selvom i har valgt at hoste i cloud, er i stadig selv ansvarlig for backup. Derfor er det vigtigt, at finde en god backup løsning, samt løbende at teste den.
Det er svært at vedligeholde yaml filer, hvis de ligger spredt ud på forskellige enheder. Derfor er det vigtigt, at man bruger GitOps, både til versionstyring og fremtidig vedligehold. Brug Flux, ArgoCD, Azure DevOps eller vælg en af de mange andre værktøjer som hjælper med dette.
Oprethold en patchcycle for jeres kubernetes miljø, det minimere risikoen for sikkerhedshuller. Del det desuden op i forskellige miljøer (test, staging og prod) for at sikre bedst og mest mulige oppetid.
Hvis i har de rette ressourcer, til at drifte jeres miljø. Så er der gode forudsætninger for god oppetid. Her er det en god ide, at benytte sig af de support aftaler der er til rådighed/kan tilkøbes, på/til det hardware og software man køber.
Sæt Prometheus og Grafana op fra start. Kombinér med Alertmanager. Logging? Brug fx Loki eller Elasticsearch. Uden observability aner du ikke hvad der sker, før det er for sent.
Lav en logisk opdeling, vha. navnet fra namespaces - feks - department-a-webservices. Det gør det nemmere at lave RBAC for specifikke applikationer.
Det er rigtigt nemt og hurtigt, at kører en container som root. Men det er en klar sikkerhedsbrist, som man lige har introduceret for sig selv. Hvis en container kører som root, og bliver komprimenteret, så er det game over.
Lad være med at give cluster-admin til alle. Brug fine-grained RBAC med Roles og RoleBindings. Begræns adgangen til det absolut nødvendige – principle of least privilege.