Aastaks 2025 kokku globaalsete andmete loomine jõuab 181 zetabaidini. Ettevõtete jaoks on need andmed vara, mis võimaldab neil kasutada erinevaid tehnoloogiaplatvorme, et luua väga isikupärastatud kliendikogemusi, mis tekitavad lojaalsust ja meelitavad ligi uusi ettevõtteid. Need kogemused sõltuvad aga jagatud turberežiime kasutavatest pilveinfrastruktuuridest. Siin peitubki risk ja see suureneb, kui tehnoloogia kasvab, et kaasata uus armee kodanikest arendajaid, kes kasutavad madala koodi ja koodita platvorme.
Pärimise mõtteviisi mõistmine ja ületamine
Gartner prognoosib, et 2025. aastaks ehitatakse 70% ettevõtete rakendustest madala koodi ja koodita platvormidel, nagu Salesforce ja ServiceNow. Pärandipõhise mõtteviisiga reageerimine on kindel viis enam kui kahe kolmandiku ettevõtterakenduste ebaõnnestumiseks ette valmistada.
"Pärimise mõtteviis" on sobiv kirjeldus infrastruktuuriga seotud probleemidele. See toob meelde rikkad, ärahellitatud lapsed, kes sõltuvad täielikult tehtud tööst ja inimestest, kes olid enne neid. See ei ole hea viis pärandi loomiseks ja sama halb viis süsteemi loomiseks.
Kui teil on pärand mõtteviis, eeldate, et infrastruktuur on paika pandud. Platvorm on turvaline ja turvalisus on sisse ehitatud. Usaldust eeldatakse lihtsalt seetõttu, et tehnoloogia oli olemas enne administraatorit.
See pärimise mõtteviis vaevab madala koodi ja koodita platvorme. Kasutajad loodavad platvormi turvalisusele, et neid läbi kogu ettevõtte infrastruktuuri kanda. Selle asemel peaks selle platvormi turvalisus kehtima ainult sellele platvormile.
Oletame, et Salesforce'i arendajad loovad uute müügivihjete jaoks automatiseeritud määramisprogrammi. Nad kasutavad seda Salesforce'is sisemiste ülesannete jaoks ja see on hea. Nad võivad loota platvormi ohutusele. Nad otsustavad seda automatiseerimise parandamiseks laiendada. Nad ühendavad selle programmi välise CRM-iga, nagu ServiceNow, SAP või Oracle. Pärimise mõtteviis võtab võimust: Salesforce on ohutu. ServiceNow, SAP või kolmas osapool on ohutu.
Niisiis, Salesforce + kolmas osapool = turvaline.
Kuid selles plussmärgis on palju tundmatut. Kuidas ühendada Salesforce'is loodud siseprogramm turvaliselt ja nõuetele vastavalt kolmanda osapoole platvormil loodud välisprogrammiga? Selles ühes tegelases on palju eksimisruumi.
Ja see on ainult üks seos. Paljud Salesforce'is loodud programmid puudutavad sadu teisi. See tähendab, et sadu tundmatuid koheldakse ülalkirjeldatud plussmärgina inimeste poolt, kellel on vähe arenduskogemust või pole üldse.
Ainus lahendus on viia see arendus tagasi maa peale tagasi DevSecOpsi põhimõtete juurde.
DevSecOpsi raamistiku loomine
DevSecOps raamistikke on kirjutatud, ümber kirjutatud ja uuesti kirjutatud alates kontseptsiooni loomisest. Nende loomisel pole vaja jalgratast uuesti leiutada, eriti kui SAFECOde ja Cloud Security Alliance on ehitanud kuus sammast:
- Kollektiivne vastutus: Turvalisus on ettevõttes iga inimese vastutus, kuid inimesed ei saa täita standardeid, mida nad ei tunne. Küberjulgeolekupoliitika juhtimiseks ja selle levitamiseks kogu ettevõttes tuleks määrata müügivihjed.
- Koostöö ja integratsioon: Teadmisi tuleb jagada ja edasi kanda. Pool põhjust, miks ettevõtted langevad pärandisse, on see, et kõik, kes teadsid vana süsteemi, on kadunud. Pidev teadmiste jagamine aitab selle probleemi lahendada.
- Pragmaatiline rakendamine: Pragmaatiline juurutamine seostub arendaja kogemusega. Raskeid, igapäevaseid ja kohmakaid protsesse ei jälgita kaua. Turvalisus tuleks sisse lülitada arenduspraktikatesse – see tähendab, et iga koodirida nõuab testirida. Suure jõudlusega ettevõte viiks selle edasi, kasutades iga testkoodirea automatiseerimiseks tööriista.
- Vastavus ja areng: Vastavusnõuded peaksid arendusprotsessi suunama viisil, mis ei võimalda arendajatel neist kõrvale kalduda. Näiteks finantsasutuse arendaja töötaks platvormil, mis on loodud Gramm-Leach-Bliley seadusega vastavusse viima. Arendaja ei pea nõuete täitmiseks teadma toimingu üksikasju, sest need on platvormi sisse ehitatud.
- Automatiseerimine: Prognoositavad, korratavad ja suure mahuga ülesanded tuleks võimaluse korral automatiseerida, et vabastada arendajatelt koormus ja vähendada inimlike vigade ohtu.
- Monitor: Kaasaegsed pilveinfrastruktuurid muutuvad ja kasvavad. Selle jälgimine on ülioluline – ideaaljuhul mingi orkestratsiooni abil, mis võimaldab lühidalt näha kõiki erinevaid seoseid.
Aastal madal või puudub kood keskkonda ei ole need sambad nii lihtsad, kui võiks eeldada. Neid tööriistu kasutavad inimesed on sageli ärieksperdid, kes ei tunne DevSecOpsi põhialuseid.
Inimeste, protsesside ja tehnoloogia kokkuviimine
Madala koodi ja koodita platvormide kasutamine võib tegelikult aidata seda oskuste puudujääki täita. Töötajad soovivad õppida uusi oskusi. Ettevõtted saavad seda toetada, luues inimestele, protsessidele ja tehnoloogiale keskenduva DevSecOpsi raamistiku.
- Protsessid: Null-usalduskeskkonnas ei pea madala koodi ja koodita arendajad muretsema selliste ühenduste loomise pärast, mis ohustavad süsteemi terviklikkust, kuna nad ei ole selleks võimelised. Neil ei ole väljaspool isoleeritud süsteemi lähtevolitusi.
- inimesed: Vastutuse kultuur erineb süüdistamise kultuurist. Vastutus tähendab, et inimesed tunnevad end mugavalt probleemi või veaga esile kerkides, kuna keskendutakse probleemile, mitte inimesele.
- Tehnoloogia: Tehnoloogia on suurim takistus DevSecOpsi põhimõtete õigel rakendamisel, kuna see on arendajate käest väljas. Nad peavad kasutama seda, mida organisatsioon neile annab. Kui see tehnoloogia ei tööta, pakuvad arendajad lahendusi, mis ei ole turvalised ega ohutud. Põhimõtteliselt saab tehnoloogiast üks suur vari-IT-generaator.
Elame põneval arenguajal. Üha enamatel inimestel on võimalus luua tarkvara, testida strateegiaid ja parandada äriväärtust. Kuid sellega kaasneb risk. Ettevõtted, kes otsivad võimalusi selle riski tehnoloogiale ülekandmiseks, jätkavad oma arengut maalähedaselt, jättes samas ruumi uurimiseks.
