Styring og sikkerhed i Self-Service arbejdsprocesser
I en hvilken som helst strategi for platformkonstruktion er det vigtigt at implementere selvbetjente arbejdsprocesser, der balancerer hastighed og autonomi med sikkerhed og overholdelse af angivne standarder. Selvom det er vigtigt at gøre udviklere i stand til at administrere deres ressourcer uafhængigt af hinanden for at øge effektiviteten, skal styring og sikkerhed være tæt integreret for at forhindre potentielle problemer, f.eks. uautoriseret adgang eller politikovertrædelser.
Styringsstrukturer sikrer, at udviklere kan arbejde inden for foruddefinerede grænser, mens sikkerhedsforanstaltninger beskytter mod sårbarheder og uautoriserede aktiviteter. Udviklere har brug for autonomien til at innovere og klargøre ressourcer efter behov, men organisationer skal også bevare kontrollen for at forhindre sikkerhedsrisici, undgå fejlkonfigurationer og sikre overholdelse af lovmæssige standarder. Nøglen til at opnå denne balance ligger i veldesignede styringsmodeller, effektiv brug af sikkerhedsforanstaltninger og en robust revisions- og overholdelsesstrategi, der kan spore aktiviteter i selvbetjeningsarbejdsprocesserne.
Valg af cloudtjeneste
I offentlige cloudmiljøer kan du vælge mellem SaaS, PaaS eller IaaS, som hver især tilbyder forskellige niveauer af kontrol og brugervenlighed. PaaS-tjenester leverer strømlinede udviklingsoplevelser, men er mere præskriptive, hvilket kræver en afvejninger mellem brugervenlighed og fleksibilitet. Når du designer din platform, er det vigtigt at evaluere organisationens tjenestebehov, f.eks. om du vil bruge Azure Kubernetes Service (AKS) til mere kontrol eller Azure Container Apps (ACA) for nemheds skyld. Nye appmodeller som OSS Radius inkubationsprojekt har til formål at finde en balance mellem de to, men er mindre modne end etablerede cloudtjenester. Det rigtige valg afhænger af dine tjenestekrav og dit teams eksisterende færdigheder.
Standardisering
IaC-værktøjer (Infrastructure as Code) og automatiseringsværktøjer kan kombineres med skabeloner for at strømline og standardisere udrulning af infrastruktur og programmer. Ved at indvinde platformspecifikke detaljer i kategorier, der kan oversættes (f.eks. størrelser som små, mellemstore og store), kan skabeloner forenkle processen for udviklingsteams, så de hurtigt kan komme i gang med minimal konfiguration. Der kan dog være situationer, hvor der er behov for brugerdefinerede konfigurationer, i hvilket tilfælde platform- eller driftsteams kan oprette engangskonfigurationer og beslutte, om de skal integreres i skabelonen.
Værktøjer som Terraform og cloudbaserede IaC-løsninger (f.eks. Cluster API, Crossplane) kan spore ændringer via registrering af drift med mulighed for automatisk at afhjælpe drift. Derudover kan cloudkonfigurationsværktøjer, f.eks. Azure Resource Graph, hjælpe med at overvåge og gennemse ændringer af ressourcer. For at sikre fleksibilitet kan tolerancer angives i udrulninger for at tillade foruddefinerede grænser, f.eks. ved hjælp af Azure Policy til at styre antallet af Kubernetes-noder i en installation.
Ressourcedeling
I en organisation kan deling af ressourcer som Kubernetes-klynger på tværs af flere programmer forbedre udnyttelsen og omkostningseffektiviteten, men det kræver nøje overvejelse. Nøglefaktorer omfatter:
- organisationsjustering: Deling af ressourcer inden for organisationens grænser sikrer bedre justering med retning, prioriteter og krav.
- Application Tenancy: Programmer har forskellige isolationsbehov (f.eks. sikkerhed, overholdelse af angivne standarder). Kubernetes bruger f.eks. navneområdeisolation, men blanding af miljøer som produktion og test på den samme klynge kan medføre risici. Det er vigtigt, at der er sammenhæng i tilgangen.
- ressourceforbrug: Hvert programs ressourceforbrug og kapacitetsprognoser skal evalueres for at undgå overbelastning af delte ressourcer. Overvågning og test er med til at sikre, at programmer ikke overskrider den tilgængelige kapacitet og forårsager tjenesteafbrydelser.
- Optimering af delte konfigurationer: Delte ressourcer kræver detaljeret konfiguration, herunder krydsopladning, ressourceallokering, tilladelser, administration af arbejdsbelastninger og koordinering af opgraderinger.
Styringsmodeller
En af de mest effektive måder at implementere styring på er ved hjælp af politikdrevet administration, hvor platformpolitikker automatiseres ved hjælp af værktøjer som og Azure Policy. Disse værktøjer gør det muligt for organisationer at gennemtvinge politikker på en ensartet måde på tværs af platformen, så alle handlinger til klargøring af ressourcer, der udføres af udviklere, er i overensstemmelse med foruddefinerede organisationsregler.
Etablering af gelændere og begrænsninger er et andet kritisk aspekt af styringen. Disse sikkerhedsforanstaltninger – f.eks. ressourcekvoter, geografiske begrænsninger eller mærkningskrav – hjælper udviklere med at klargøre ressourcer inden for acceptable parametre. Guardrails giver grænser, der hjælper med at beskytte mod sikkerhedssårbarheder, overholdelse af angivne standarder eller unødvendige omkostninger, samtidig med at den fleksibilitet, der kræves til innovation, bevares.
Organisationer skal også overveje valget mellem centraliserede i forhold til decentral styring modeller. Centraliseret styring sikrer bedre kontrol og ensartethed ved at give et dedikeret team, f.eks. platform engineering eller it-sikkerhed, mulighed for at administrere politikker og arbejdsprocesser. En decentraliseret tilgang uddelegerer beslutningstagningen til individuelle teams og fremmer fleksibilitet og autonomi. Den optimale model afhænger af faktorer som organisationens størrelse, kompleksitet og krav til overholdelse af angivne standarder.
Styringsstrategier
Fra et strategisk synspunkt kan styringen opdeles i to faser:
- for at sikre, at der kun installeres godkendte ressourcer og konfigurationer via standardiserede IaC-skabeloner, kataloger og politikker til administration af tilladelser.
- overholdelse af angivne standarder: Politikbaserede værktøjer hjælper med at overvåge og forhindre uautoriserede ressourceændringer. Disse værktøjer strækker sig ud over kerneinfrastrukturen og understøtter overholdelse af angivne standarder i ressourcer som Kubernetes, objektbeholdere eller VM'er og en række sikkerhedsværktøjer.
Værktøjerne til at opretholde overholdelse af angivne standarder bør levere funktioner til overvågning, rapportering og afhjælpning. Azure Policy tilbyder f.eks. denne support via forskellige tilstande, f.eks. Audit, Deny og DeployIfNotExists. Disse politikker kan dog nogle gange utilsigtet forstyrre programmer, hvilket gør overgangen til Politik som kode nyttig, især for store miljøer. PaC muliggør centralt administrerede standarder, versionsstyring af politikker, automatiseret test og validering og hurtigere udrulning med løbende udrulning, så der sikres en mere strømlinet og pålidelig tilgang til administration af overholdelse.
Sikkerhed
Sikring af sikkerhed i selvbetjening for udviklere til platformkonstruktion kræver en tilgang med flere lag, der dækker kode, objektbeholdere, klynger og cloudinfrastruktur. Vigtige anbefalinger omfatter fastholdelse af princippet om mindst mulige rettigheder, forening af DevOps-sikkerhedsstyring på tværs af pipelines, aktivering af kontekstafhængig indsigt i kritisk risikoidentifikation og vedligeholdelse af registrering af kørsel og svar på moderne trusler på tværs af cloudarbejdsbelastninger. Værktøjer som Microsoft Defender for Cloud kan hjælpe med at evaluere og løse disse sikkerhedsudfordringer på tværs af teknikersystemer, programmer og ressourcer.
I forbindelse med selvbetjening af udviklere betyder gennemtvingelse af adgang med færrest rettigheder, at udviklere kan få adgang til de ressourcer, de har brug for til at udføre deres opgaver uden at tildele for mange tilladelser. En udvikler kan f.eks. have fuld adgang til et udviklingsmiljø, men kun skrivebeskyttet adgang til produktionsmiljøet. Dette hjælper med at forhindre utilsigtede eller skadelige ændringer af produktionssystemer.
Ud over at gennemtvinge mindst mulige rettigheder skal organisationer også fokusere på adskillelse af opgaver, hvilket sikrer, at ingen enkeltperson eller rolle har umarkeret magt over kritiske processer. Denne praksis hjælper med at afhjælpe risici som f.eks. svindel, fejl og sikkerhedsbrud ved at sikre, at opgaver, der kræver forskellige ekspertisesæt, er fordelt på forskellige roller. Udviklere kan f.eks. være ansvarlige for at skrive kode, men udrulning til produktion kan kræve godkendelse fra et separat drifts- eller sikkerhedsteam. Ved hjælp af RBAC kan organisationer gennemtvinge disse grænser, der begrænser adgangen til følsomme miljøer (f.eks. produktion), samtidig med at udviklere får frihed til at arbejde autonomt i ikke-følsomme miljøer (f.eks. udvikling eller midlertidig lagring). Adskillelse af opgaver understøtter også overholdelse af sikkerhedsrammer og lovgivningsstandarder, f.eks. SOX (Sarbanes-Oxley) eller PCI DSS, hvilket ofte kræver klare roller og ansvar for systemadgang og dataadministration.
Ud over programsikkerhed bør organisationer fokusere på flere vigtige områder: administration af eksterne angrebsoverflader (f.eks. Microsoft Defender EASM), anvendelse af intelligente sikkerhedsanalyser (f.eks. Microsoft Sentinel) og sikker styring og administration af dataaktiver (f.eks. Microsoft Purview). Derudover er kodescanning efter sårbarheder og afhængighedsvurderinger med værktøjer som GitHub Advanced Security afgørende, og det samme gælder administration af softwareforsyningskæden med strukturer som Microsoft Containers Secure Supply Chain Framework.
Programmer kræver også sikker identitetsstyring for at få adgang til cloudressourcer. AKS-arbejdsbelastninger kan f.eks. bruge arbejdsbelastningsidentiteter, der er forbundet med Microsoft Entra ID, hvilket gør det muligt for programmer i objektbeholdere at godkende sikkert uden at integrere hemmeligheder i programkoden. Denne fremgangsmåde forbedrer sikkerheden og forenkler ressourceadgangen for oprindelige programmer i cloudmiljøet.
Korrekt hemmelig administration er dog stadig afgørende for at sikre selvbetjente arbejdsprocesser. Udviklere håndterer ofte følsomme data, f.eks. API-nøgler eller legitimationsoplysninger, som skal gemmes og tilgås sikkert. Microsoft-værktøjer som Azure Key Vault levere en centraliseret løsning til sikker lagring og roterende hemmeligheder. Disse værktøjer sikrer, at hemmeligheder er krypterede og kun tilgængelige for autoriserede personer eller tjenester.
Autorisation
Administration af autorisation kræver, at der defineres klare roller og politikker, der er i overensstemmelse med princippet om mindste rettigheder. Korrekt implementerede politikker for adgangskontrol, f.eks. RBAC, gør det muligt for organisationer at tildele relevante tilladelser til udviklere baseret på deres jobfunktioner, roller og ansvarsområder. Derudover øger dynamiske adgangskontrolmekanismer, f.eks. midlertidig adgang eller tidsbaserede kontrolelementer, fleksibiliteten yderligere uden at gå på kompromis med sikkerheden.
Når rollerne er defineret, er det næste trin at oprette og gennemtvinge rollepolitikker, der angiver, hvad hver rolle kan og ikke kan gøre. Roller kan f.eks. give tilladelse til at klargøre cloudressourcer, udrulle kode til en CI/CD-pipeline eller ændre konfigurationsindstillinger. Ved at tildele specifikke tilladelser til disse roller kan organisationer styre det adgangsniveau, som udviklere har til forskellige ressourcer. RBAC hjælper også med at reducere risikoen for krybning af rettigheder, hvor brugerne akkumulerer for mange tilladelser over tid. Ved tydeligt at definere roller og regelmæssigt gennemse tilladelser kan organisationer sikre, at udviklere kun har den adgang, de har brug for til at udføre deres opgaver.
Styring og sikkerhed i Azure Deployment Environments (ADE)
Azure Deployment Environments (ADE) forbedrer selvbetjeningsstyringen ved at levere forudkonfigurerede miljøer, der er tilpasset organisationens standarder. Styring opnås ved hjælp af skabeloner, der standardiserer udrulninger, sikrer, at ressourcer klargøres sikkert og i overensstemmelse med politikker.
I ADE styrer RBAC-politikker, hvem der kan klargøre miljøer, og hvilke konfigurationer de kan bruge, hvilket giver veldefinerede grænser. Sikkerhedsfunktioner som f.eks. Microsoft Entra ID-integration og administrerede identiteter muliggøre sikker adgang til ressourcer uden at kræve eksplicit administration af legitimationsoplysninger.
Med ADE kan organisationer definere politikker for adgangskontrol, der gennemtvinger RBAC-principper på miljøniveau. En udvikler kan f.eks. få adgang til at udrulle kode til et udviklings- eller testmiljø, men kan kræve andre tilladelser eller godkendelse for at kunne udrulle til produktion. RBAC kan anvendes på forskellige elementer i ADE, herunder miljøskabeloner, ressourcer og konfigurationer, for at sikre, at sikkerhedspolitikker gennemtvinges konsekvent.
Derudover understøtter ADE overvågning og logføring via Azure Monitor, hvilket hjælper med at spore klargøringsaktiviteter og ressourceforbrug. Organisationer kan bruge disse data til at gennemtvinge styring og registrere eventuelle overtrædelser af politikker for overholdelse af angivne standarder.
Styring og sikkerhed i Azure Dev Box
Azure Dev Box indeholder indbyggede kontrolelementer til konfiguration af RBAC, gennemtvingelse af ressourcegrænser og anvendelse af politikker for omkostningsstyring, der er i overensstemmelse med principperne for sikker selvbetjening. Sikkerhedsbestemmelser omfatter integration med værktøjer som Microsoft Entra ID til at administrere brugergodkendelse og godkendelse. Microsoft Entra ID sikrer, at kun godkendte personer kan få adgang til og klargøre udviklingsbokse, og RBAC-politikker begrænser brugernes egenskaber baseret på deres roller. Derudover hjælper integration med Microsoft Sentinel- med at forbedre overvågning og overvågning af klargøring og brug af dev box for at registrere uregelmæssigheder og gennemtvinge overholdelse.
Dev Box-miljøer kan tilpasses i høj grad, og RBAC kan sikre, at kun godkendte udviklere kan oprette eller ændre deres egne arbejdsstationer. En udvikler med en juniorrolle kan f.eks. kun have mulighed for at klargøre en udviklingsboks med begrænsede ressourcer, mens en seniorudvikler kan have bredere tilladelser til at justere konfigurationer eller installere anden software.
Azure Dev Box understøtter mærkningsstrategier og omkostningsstyring for at spore og optimere ressourceforbruget. Organisationer kan implementere Azure Policy- til at gennemtvinge styringsstandarder, f.eks. kræve visse konfigurationer for Udviklingsbokse, hvilket sikrer ensartethed og sikkerhed på tværs af miljøer.