IaC skannimine: fantastiline, tähelepanuta jäetud õppimisvõimalus

Kõik, mida loete infrastruktuuri kui koodi (IaC) kohta, keskendub sellele, kuidas see töötab või miks soovite veenduda, et see tegelikult ehitatakse nii, nagu soovite.

Need on kriitilised valdkonnad. Kuid kas me mõtleme piisavalt sellele, kuidas me seda lähenemist oma organisatsioonis kasutame?

As Melinda Marks ESG väidab ettevõtte aruandes: „83% organisatsioonidest koges IaC malli valede konfiguratsioonide sagenemist”, kui nad jätkavad tehnoloogia kasutuselevõttu.

Teame Cloud Security Alliance'i tehtud tööst (“Peamised ohud pilvandmetöötlusele: Egregious Eleven“) ja teised, on valesti seadistamine pilves jätkuvalt suurim oht.

IaC on toetatud vähendama
väärkonfiguratsioonid, süstematiseerides infrastruktuuri loomise, lisades ranguse ja protsessi, mis tagab, et meeskonnad ehitavad seda, mida nad tahavad ja ainult seda, mida nad tahavad. Kui ~83% meeskondadest seda ei näe, on mängus sügavam probleem.

Väiksematel meeskondadel, kus DevOpsi filosoofia Dev ja Ops osad on koos, on see mõistlik. IaC võimaldab neil väikestel meeskondadel kasutada sama keelt – koodi – kirjeldamaks kõike, mida nad teevad.

See on põhjus, miks me näeme isegi kõrgema taseme abstraktsioone kui sellised tööriistad nagu Terraform või AWS CloudFormation. AWS CDK ja projekte nagu cdk8s. Need kõrgetasemelised abstraktsioonid on arendajatele mugavamad.

Pilveteenuse ops/SRE/platvormi vaatenurk erineb sama teenuse arendaja vaatenurgast metsikult. Arendaja vaatab järjekorrateenust ja sukeldub selle liidesesse – lihtne lõpp-punkt, mida lisada ja üks, mida lugeda? Müüdud. See on lihtne integreerimine.

Selle tööperspektiivi eesmärk on leida servad. Niisiis, millal jõuab see järjekord oma piirini? Kas jõudlus on konstantne või muutub see koormuse all radikaalselt?

Jah, mured kattuvad. Ja jah, see on lihtsustatud vaade. Aga mõte peab vastu. IaC lahendab palju probleeme, kuid see võib ka tekitada ja võimendada meeskondade vahelisi katkestusi. Veelgi olulisem on see, et see võib rõhutada lõhet selle vahel, mida proovite ehitada, ja selle vahel, mida olete ehitanud.

Seetõttu on turvaprobleemid sageli eskaleeruvad.

Enamik tööriistu - kommerts- või avatud lähtekoodiga - on keskendunud infrastruktuuri mallides valesti olevate asjade tuvastamisele. see
on hea konstruktsioon. Valmistamine see
oleks halb. Nende tööriistade eesmärk on genereerida need tulemused pideva integreerimise/pideva edastamise (CI/CD) torustiku osana.

See on suurepärane algus. Kuid see kajastab sama keeleprobleemi.

Kes räägib ja kes kuulab?

Kui IaC-tööriist tõstab probleemi esile, siis kes sellega tegeleb? Kui see on arendusmeeskond, kas tal on piisavalt teavet, et teada saada, miks see probleemina märgiti? Kui see on operatiivmeeskond, siis kas probleemi tagajärjed on aruandes välja toodud?

Arendajate jaoks juhtub sageli see, et nad lihtsalt kohandavad konfiguratsiooni, et IaC testimine läbiks.

Operatsioonide puhul on tavaliselt asi selles, kas testid läbivad. Kui on, siis järgmise ülesande juurde. See pole kummagi meeskonna jaoks koputus; pigem toob see esile lõhe ootuste ja tegelikkuse vahel.

Vaja on konteksti. IaC turbetööriistad annavad ülevaate sellest, mida (loodetavasti) ehitatakse. Eesmärk on probleemid peatada enne nad jõuavad tootmisse.

Tänased IaC turbetööriistad tõstavad esile tõelised probleemid, millega tuleb tegeleda. Nende tööriistade väljundi kasutamine ja selle rikastamine täiendava kontekstiga, mis on spetsiifiline koodi eest vastutava meeskonna jaoks, on suurepärane võimalus kohandatud automatiseerimiseks.

See aitab ületada ka keelelõhet. Teie tööriistade väljund on sisuliselt kolmandas keeles – lihtsalt selleks, et asju keerulisemaks muuta – ja seda tuleb edastada viisil, mis on mõistlik kas arendus- või operatsioonide vaatajaskonnale. Sageli mõlemad.

Näiteks kui skannimisel märgitakse, et turberühma reeglil pole kirjeldust, siis miks see oluline on? Ainuüksi märguande „Lisa konteksti kirjeldus” saamine ei aita kellelgi paremaks luua.

Seda tüüpi lipp on suurepärane võimalus harida pilves ehitavaid meeskondi. Selgituse lisamine, et turvagrupi reeglid peaksid olema võimalikult täpsed, vähendab pahatahtlike rünnakute võimalust. Tooge viiteid tugevate reeglite näidetele. Helistage sellele kavatsust teadmata ja teised meeskonnad ei saa turvakinnituse kehtivust testida.

Turvalisus on igaühe vastutus, nii et arendajate ja operatsioonide vahelise keelelõhe teadvustamine tõstab esile sellised võimalused nagu see, et lisada lihtsaid automatiseerimisi, mis pakuvad teie meeskondadele teadmisi. See aitab täiustada seda, mida nad ehitavad, ja selle tulemusel paremaid turvatulemusi.

Teave Autor

Olen kohtuekspertiisi teadlane, kõneleja ja tehnoloogiaanalüütik, kes püüab aidata teil mõista digitaalset maailma ja selle mõju meile. Igapäevakasutajatele aitab minu töö selgitada, millised on digimaailma väljakutsed. Kui suurt mõju avaldab sotsiaalmeedia kasutamine teie privaatsusele? Mida see tähendab, kui meie kogukondades hakatakse kasutama selliseid tehnoloogiaid nagu näotuvastus? Aitan vastata sellistele ja muudele küsimustele. Tehnoloogiat ehitavatel inimestel aitan neil rakendada oma töös turva- ja privaatsusobjekti, et nad saaksid kasutajatel oma teabe ja käitumise kohta selgemaid otsuseid teha. Privaatsuse ja turvalisuse osas valitseb segaduse mägi. Ei tohiks olla. Muudan turvalisuse ja privaatsuse lihtsamini mõistetavaks.