Kun jättiläiset kompastuvat: Miksi GitHubin, Salesforcen ja SharePointin käyttökatkot eivät aina johdu hakkereista

Kyberturvallisuusala on onnistunut tehtävässään: olemme tottuneet pelkäämään ulkoisia hyökkääjiä. Elokuvat dramatisoi tietomurtoja, uutisotsikot huutavat tietovuodoista, ja jokainen IT-osasto painiskelee tunkeutumisenestojen kanssa. Mutta viimeaikaiset laajat alustakatkokset ovat tuoneet kiusallisen totuuden karvaasti esiin: joskus vaarallisimmat uhat tulevat omasta takaa.

Viikko täynnä väristyksiä

Neljän päivän aikana kolme teknologian ekosysteemin luotetuinta alustaa koki merkittäviä häiriöitä. GitHub, versionhallinnan tukipilari miljoonille kehittäjille ympäri maailman, kohtasi palvelukatkoksia. Salesforce, joka käsittelee päivittäin miljardien arvosta liiketoimintaa, joutui alasajoihin. SharePoint, lukemattomien yritysten yhteistyön selkäranka, meni hetkeksi offline-tilaan.

Yhdistävä tekijä? Mikään näistä tapauksista ei johtunut pahantahtoisista toimijoista, kehittyneistä hyökkäyksistä tai kyberrikollisten kampanjoista. Sen sijaan syylliset olivat paljon arkisempia — ja siksi paljon petollisempia.

Tutut syylliset: Vanhat järjestelmät ja konfiguraatiomuutokset

Tapausten yksityiskohdat paljastivat tuttuja kaavoja. Vanhat kirjautumispalvelut, jotka olivat kantaneet teknistä velkaa vuosikausia, lopulta pettivät. Yhdessä ympäristössä tehdyt konfiguraatiomuutokset saivat aikaan odottamattomia sivuvaikutuksia tuotannossa. Siivousoperaatiot, joiden tarkoitus oli parantaa järjestelmiä, loivat sen sijaan uutta epävakautta.

Tämä on todellisuutta, jonka monet kehittäjät ja DevOps-insinöörit tuntevat sisältäpäin mutta harvoin puhuvat ääneen: vaarallisin hetki mille tahansa järjestelmälle on se, kun yrität korjata sitä.

Konfiguraatiokatastrofi

Konfiguraatiodriftaus — asteittainen poikkeama sen välillä, miten järjestelmät on konfiguroitu ja miten niiden pitäisi olla konfiguroitu — pysyy yhtenä aliarvostetuimmista riskeistä teknologiatehtävissä. Kiireessä tehty pieni muutos, väliaikainen korjaus joka jäi koskaan perumattomaksi, väärin asetettu ympäristömuuttuja staging-ympäristössä joka jotenkin päätyi tuotantoon: nämä näkymättömät ongelmat kasaantuvat kunnes ne luovat täydellisen myrskyn.

Perintö: Nukkuva jättiläinen

Vanhat järjestelmät kantavat näkymätöntä taakkaa. Ne rakennettiin eri aikakausiin, eri mittakaavaan ja erilaisiin uhkamalleihin. Ajan myötä ihmiset, jotka ymmärsivät niitä, jäävät eläkkeelle tai siirtyvät muualle. Dokumentaatio vanhenee. Riippuvuudet jäävät ylläpitämättä. Ja sitten eräänä päivänä jotain, mikä toimi viisitoista vuotta, yhtäkkiä ei toimikaan.

Mitä tämä tarkoittaa sinun liiketoiminnallesi

Jos rakennat tällaisten alustojen päälle — ja rehellisesti sanottuna useimmat yritykset tekevät niin — sinun täytyy hyväksyä kiusallinen totuus: saatavuutesi on yhtä vahva kuin toimittajiesi ja omien käytäntöjesi operatiivinen kurinalaisuus.

Operatiivinen resilienssi ei ole valinnaista

Viime viikon tapahtumat toimivat herätyksenä organisaatioille, jotka ovat keskittyneet riskienhallinnassaan ensisijaisesti ulkoisiin uhkiin. Vaikka tietoturva pysyy kriittisen tärkeänä, operatiivinen resilienssi — kyky ylläpitää palvelun jatkuvuutta huolimatta vikaantumistavasta — ansaitsee yhtä suuren huomion.

Tämä tarkoittaa:

• Kriittisten riippuvuuksien hajauttamista: Pystyykö yrityksesi selviytymään kuuden tunnin GitHub-katkosta? Entä Salesforcen? Jos vastaus on ei, tarvitset varasuunnitelmia.
• Toimittajasi operatiivisten käytäntöjen ymmärtämistä: Onko heillä vahva muutostenhallinta? Mitkä ovat heidän incidenttivasteenkäytäntönsä? Nämä kysymykset merkitsevät.
• Epäonnistumisen huomioimista suunnittelussa: Toteuta circuit breakereita, välimuistitasoja ja fallback-mekanismeja. Olettaen, että mikä tahansa kolmannen osapuolen palvelu lopulta pettää.

Ihmisen tekijä

Jokaisen konfiguraatiomuutoksen, jokaisen vanhan palvelun ja jokaisen siivousoperaation takana on ihminen (tai joukko heitä). Kiire edetä nopeasti, päivystäjien väsymys, institutionaalinen tietämys joka kulkee eläkkeelle jäävien insinöörien mukana — nämä inhimilliset tekijät ovat useimpien käyttökatkosten todellinen alkuperä.

Yritykset, jotka investoivat kestäviin teknisiin käytäntöihin, riittävään henkilöstöön ja tiedonsiirtoon, investoivat todellisuudessa luotettavuuteen. Tämä ei ole glamourista, mutta se on perustavanlaatuista.

Katsotaan eteenpäin: Opit jotka kannattaa kantaa mukana

GitHubia, Salesforcea ja SharePointia koskevat tapaukset toimivat yhteisenä muistutuksena: infrastruktuurin luotettavuus on käsityötä, ei jälkikäteen ajattelua. Kehittäjinä ja teknologiajohtajina meidän täytyy puolustaa aikaa, resursseja ja kulttuuria jotka mahdollistavat operatiivisen huippuosaamisen.

Yrityksille tämä tarkoittaa sen tunnustamista, että teknologiapartnereidesi operatiivinen terveys vaikuttaa suoraan omaasi. Toimittajien arviointi ei saa koskea vain heidän tietoturva-asemaansa — kysy vaikeita kysymyksiä heidän käyttöönottokäytännöistään, heidän incidenttihistoriastaan ja heidän teknologisista investoinneistaan.

Hyökkääjät voivat odottaa. Konfiguraatiotiedosto ei.

NameOceanilla ymmärrämme, että saatavuus merkitsee. Infrastruktuurimme on rakennettu resilienssillä ytimessä, koska tiedämme että paras hyökkäys on vahva puolustus — sekä ulkoisia uhkia että sisäisiä operatiivisia riskejä vastaan.