Konfigurations- og sikkerhedsstyring til DevOps

Konfigurationstest bør ikke kun være et vigtigt skridt i den overordnede udviklingsproces, men også vigtigt i processen med installation af nye apps til brug på web- og applikationsservere. Uden ordentlig test kan apps ofte fejle eller være åbne for sårbarheder. Eksponering for angreb fra hackere eller vira kan føre til unødvendige udgifter og overdreven tid brugt på at rette op på disse problemer. Det er ikke usædvanligt, at app-udviklere overser behovet for konfigurationstest, fordi de tror, at det vil fungere fint at bruge automatiserede metoder som Chef, Puppet eller andre systemer til at teste implementeringen af deres produkter. De føler, at de ved at bruge disse fuldautomatiske processer kan teste konsistens, reproducere output tilstrækkeligt og afgøre, om tingene fungerer som forudsagt eller ej. Denne form for tænkning kan forsinke en rettidig produktlevering, producere unødvendige omkostninger og skabe yderligere arbejdsbyrder for at løse sårbarheder, der kan opstå senere i produktionen.

Hvorfor automatiseret testning ikke er nok

Automatiserede testsuiter er netop det - automatiserede. Disse værktøjer er generiske og er ikke designet til virkelig at kende dit produkt eller faktisk være i stand til at opdage fejl baseret på eventuelle problemer, der måtte opstå. Disse automatiserede testmetoder mangler evnen til at efterligne forskellige ændringer, der kan dukke op, som er relevante for din specifikke app og konfiguration. Problemer kan opstå på grund af firewallændringer, ændringer i sikkerhedskonfigurationen eller fra ændringer af patchkode, der implementeres som en hurtig løsning på et problem.

Hele processen med at udvikle en softwareapp kræver komplekse og tidskrævende processer som planlægning, opbygning, test og implementering af dit produkt. Et af de vigtigste aspekter af udviklingen er sikkerhedstest i implementeringsfasen. Der findes traditionelle metoder til at teste godkendelses- og autorisationsteknikker sammen med adgangskodebeskyttelse på frontend. Udviklere kan have viden om, hvilken sikkerhed der skal implementeres og testes på den oprindelige kildekode til applikationen, men de har muligvis ikke den nødvendige viden til at teste applikationen under et komplet integreret system eller driftsmiljø. De har f.eks. muligvis ikke viden om en server, der er vært for webapplikationen, eller om et gyldigt SSL-certifikat er påkrævet for en sikker konfiguration, eller hvordan en ændring af firewallen kan påvirke sikkerhedsproblemer. Test af konfigurationsproblemer er et vigtigt kendetegn ved sikkerhedstest og bør implementeres for at forhindre potentielle angreb.

Sag for alle at være en del af processen

Selv de mest sofistikerede sikkerhedsværktøjer kan ikke konkurrere mod en erfaren sikkerhedstester, en person, der kender sikkerhedsproblemerne for systemet, herunder årsagen til sikkerhedsbruddet, testteknik for at finde årsagen, afhjælpende foranstaltninger eller modforanstaltninger, der er nødvendige for at løse det. Brug af nogen eller en metode, der ikke tester eller kender dine sikkerhedsproblemer, vil kun resultere i at give dig en falsk følelse af sikkerhed.

For eksempel, når en udvikler udsteder en patch for at løse et kodningsproblem, hvordan ved du, at det er klart, hvordan patchen skal bruges, om patchen er let tilgængelig til at blive implementeret, eller hvordan patchen påvirker andre komponenter? Ofte foretages disse patches eller ændringer og bliver ikke let kommunikeret til andre eller aldrig implementeret med succes. Konfigurationstest sikrer, at alle ændringer er let tilgængelige, let at integrere med aktuelle systemer og krav, og at alle involverede i processen til enhver tid holdes opdateret.

Hvert hold har sin plads i processen

Dine teams bør arbejde selvstændigt og bruge deres færdigheder i de forskellige faser ved at komme med input om, hvad de ved bedst. Udviklingsteamet bør koncentrere sig om opbygningen til applikationen; mens sikkerhedsteamet bør fokusere på sikkerhedstest, og dine driftsteams bør være ansvarlige for overholdelse og valideringsproces. Ved at implementere testmetoder, hvor alle har indflydelse på den proces, de har fuld adgang til, kan fejl elimineres, og ændringer kan implementeres problemfrit for deres særlige ansvarsområde. Når der opstår konfigurations- og sikkerhedsproblemer, bør udviklingsteamet ikke være forpligtet til at lære ny kode eller teste nye strukturer. Sikkerhedsteamet kan spille en vigtig rolle i at beskytte indholdet på webstedet og kan være ansvarlig for krav til webserveren eller applikationsserverkonfigurationen. Systemadministratoren har den nødvendige viden til at vide, hvordan en server skal konfigureres, og de fælles retningslinjer, der skal tages i betragtning. Når denne viden anvendes tidligt i processen, kan problemer og sårbarheder løses tidligt og kan ofte koste mindre at implementere.

Sidst men ikke mindst: Behov for at dele

Teams vil være i stand til at samarbejde om deres ideer til konfigurationstest og dele det individuelle og overordnede ansvar for konfigurationstest. Alle vil få gavn af det; Dobbeltarbejde elimineres, systemkonfiguration defineres og information dokumenteres let, kommunikation og samarbejde forbedres let, og tid og penge bruges for at opnå effektive resultater med hver ændring, der implementeres. Brug af konfigurationstest sikrer, at tilstrækkelig kommunikation, overvågning og dokumentation af appudviklingen er let tilgængelig for alle teammedlemmer. Kommunikation mellem teams vil fremme tænkning "ud af boksen". Normalt ville use cases for god sikkerhed kun teste, hvad man kunne forvente ville ske. Sjældent ville en automatiseret metode virkelig teste usædvanlige tilfælde, der ville ødelægge applikationen eller få en app til at fejle på en usikker måde. Da automatiserede metoder ofte ikke fanger disse ud af de almindelige tilfælde, er det bydende nødvendigt, at organisationer overvejer andre tilfælde, der opstår ved at bruge kreative tænketeknikker. Kreativ tænkning kan ofte hjælpe med at afgøre, hvad der kan få en applikation til at mislykkes, og hvordan man kan hjælpe med at undgå eller løse eventuelle problemer på forhånd.

Ved at bruge UpGuard vil du være sikker på, at dine teams vil være i stand til at definere, dele og køre de korrekte konfigurationstests for at sikre kvaliteten til at opfylde din virksomheds mål. Brug af den korrekte konfigurationstest kan praktisk talt lukke hullet i fremtidige sikkerhedsrisikoomkostninger ved at løse dem, før der opstår et problem. Du kan fremskynde tiden til udgivelse af dine produkter uden at ofre kvalitet eller ydeevne ved at bruge konfigurationstest og implementere kontinuerlig integration som en del af dit teams udgivelsesstyringsstrategi.