IaC-skannaus: upea, huomiotta jätetty oppimismahdollisuus

Kaikki, mitä luet infrastruktuurista koodina (IaC), keskittyy siihen, miten se toimii tai miksi haluat varmistaa, että se todella rakentaa haluamallasi tavalla.

Nämä ovat kriittisiä alueita. Mutta mietimmekö tarpeeksi, kuinka käytämme tätä lähestymistapaa organisaatiossamme?

As Melinda Marks ESG toteaa yhtiön raportissa, että "83% organisaatioista koki lisääntyneen IaC-mallien virheelliset konfiguraatiot" jatkaessaan tekniikan käyttöönottoa.

Tiedämme Cloud Security Alliancen työstä ("Pilvitietotekniikan suurimmat uhat: Egregious Eleven") ja muut, virheelliset asetukset ovat edelleen suurin riski pilvessä.

IaC on tuettu vähentää
virheelliset kokoonpanot systematisoimalla infrastruktuurin luomisen, lisäämällä kurinalaisuutta ja prosessia, joka varmistaa, että tiimit rakentavat mitä haluavat ja vain mitä haluavat. Jos ~83 % joukkueista ei näe sitä, kyseessä on syvempi ongelma.

Pienemmissä tiimeissä, joissa DevOps-filosofian Dev ja Ops ovat yhdessä, se on järkevää. IaC sallii näiden pienten tiimien käyttää samaa kieltä - koodia - kuvaamaan kaikkea, mitä he tekevät.

Tästä syystä näemme jopa korkeamman tason abstraktioita kuin työkalut, kuten Terraform tai AWS CloudFormation. AWS CDK ja vastaavia projekteja cdk8s. Nämä korkean tason abstraktiot ovat kehittäjille mukavampia.

Pilvipalvelun ops/SRE/platform-näkökulma eroaa hurjasti saman palvelun kehittäjän näkökulmasta. Kehittäjä tarkastelee jonopalvelua ja sukeltaa sen käyttöliittymään – yksinkertainen päätepiste lisättäväksi ja yksi luettavaksi? myyty. Se on helppo integrointi.

Tämä toimintanäkökulma pyrkii löytämään reunat. Joten milloin tämä jono saavuttaa rajansa? Onko suorituskyky vakio vai muuttuuko se radikaalisti kuormituksen alaisena?

Kyllä, on päällekkäisiä huolia. Ja kyllä, tämä on yksinkertaistettu näkemys. Mutta ajatus kestää. IaC ratkaisee monia ongelmia, mutta se voi myös luoda ja vahvistaa tiimien välistä katkeamista. Vielä tärkeämpää on, että se voi korostaa kuilua sen aikomuksen, mitä yrität rakentaa, ja rakentamasi todellisuuden välillä.

Tämän seurauksena turvallisuushuolet usein kärjistyvät.

Useimmat työkalut – kaupalliset tai avoimen lähdekoodin – keskittyvät tunnistamaan asioita, jotka ovat viallisia infrastruktuurimalleissa. Tämä
on hyvä rakennelma. Tehdä tätä
olisi huono. Nämä työkalut pyrkivät tuottamaan nämä tulokset osana jatkuvan integroinnin/jatkuvan toimituksen (CI/CD) putkilinjaa.

Se on hieno alku. Mutta se toistaa samaa kieliongelmaa.

Kuka puhuu ja kuka kuuntelee?

Kun IaC-työkalu korostaa ongelmaa, kuka ratkaisee sen? Jos kyseessä on kehitystiimi, onko sillä tarpeeksi tietoa tietääkseen, miksi tämä merkittiin ongelmaksi? Jos kyseessä on toimintaryhmä, onko ongelman seuraukset esitetty raportissa?

Kehittäjille tapahtuu usein niin, että he yksinkertaisesti säätävät kokoonpanoa, jotta IaC-testaus läpäisi.

Toiminnassa on yleensä kyse siitä, onnistuvatko testit. Jos ovat, siirry seuraavaan tehtävään. Se ei ole kolhu kummallekaan joukkueelle; pikemminkin se korostaa odotusten ja todellisuuden välistä kuilua.

Se mitä tarvitaan, on konteksti. IaC-suojaustyökalut tarjoavat näkyvyyttä siihen, mitä (toivottavasti) rakennetaan. Tavoitteena on lopettaa ongelmat ennen ne pääsevät tuotantoon.

Tämän päivän IaC-suojaustyökalut korostavat todellisia ongelmia, joihin on puututtava. Näiden työkalujen tuotos ja sen rikastaminen lisäkontekstilla, joka on ominaista koodista vastaavalle tiimille, on täydellinen tilaisuus mukautettuun automaatioon.

Tämä auttaa myös kuromaan umpeen kielikuilun. Työkalujen tuotos on pääosin kolmannella kielellä - vain tehdäkseen asioita monimutkaisemmiksi - ja se on viestittävä tavalla, joka on järkevää joko kehitys- tai operaatioyleisölle. Usein molempia.

Esimerkiksi kun tarkistus ilmoittaa, että suojausryhmäsäännöllä ei ole kuvausta, miksi sillä on väliä? Pelkästään "Lisää kontekstin kuvaus" -ilmoituksen saaminen ei auta ketään rakentamaan paremmin.

Tämäntyyppinen lippu on loistava tilaisuus kouluttaa pilvessä rakentavia tiimejä. Selityksen lisääminen, että suojausryhmän sääntöjen tulee olla mahdollisimman tarkkoja, vähentää haitallisten hyökkäysten mahdollisuutta. Anna viittauksia esimerkkeihin vahvoista säännöistä. Soita se tietämättä aikomusta, eivätkä muut tiimit voi testata suojausvahvistuksen oikeellisuutta.

Tietoturva on jokaisen vastuulla, joten kehittäjien ja toimintojen välisen kielikuilun tunnustaminen korostaa tämän kaltaisia ​​mahdollisuuksia lisätä yksinkertaisia ​​automaatioita, jotka tarjoavat oivalluksia tiimeillesi. Tämä auttaa parantamaan sitä, mitä he rakentavat, ja sen seurauksena parantaa tietoturvatuloksia.

kirjailijasta

Olen oikeuslääketieteellinen tutkija, puhuja ja teknologia-analyytikko, joka yrittää auttaa sinua ymmärtämään digitaalista maailmaa ja sen vaikutuksia meihin. Työni auttaa jokapäiväisille käyttäjille selittämään digitaalisen maailman haasteita. Kuinka paljon sosiaalisen median käytöllä on yksityisyytesi vaikutusta? Mitä tarkoittaa, kun kasvojentunnistuksen kaltaisia ​​teknologioita aletaan käyttää yhteisöissämme? Autan vastaamaan tällaisiin ja muihin kysymyksiin. Teknologiaa rakentavia ihmisiä autan käyttämään tietoturva- ja yksityisyyslinssiä työhönsä, jotta käyttäjät voivat tehdä selkeämpiä päätöksiä tiedoistaan ​​ja käyttäytymisestään. Yksityisyyden ja turvallisuuden suhteen vallitsee suuri hämmennys. Ei pitäisi olla. Teen turvallisuuden ja yksityisyyden ymmärtämisen helpommin.