2025-ig összesen globális adatalkotás eléri a 181 zettabájtot. A vállalatok számára ezek az adatok értéket jelentenek, lehetővé téve számukra, hogy különféle technológiai platformokat kihasználjanak, hogy személyre szabott ügyfélélményeket hozzanak létre, amelyek hűséget keltenek és új vállalkozásokat vonzanak. Ezek a tapasztalatok azonban a megosztott biztonsági módokat használó felhő-infrastruktúráktól függenek. Ebben rejlik a kockázat, és ez növekszik, ahogy a technológia növekszik, és a lakossági fejlesztők új hadseregét foglalja magában, alacsony kódú és kód nélküli platformokat használva.
Az öröklődési gondolkodásmód megértése és leküzdése
Gartner becslések szerint 2025-re a vállalati alkalmazások 70%-a alacsony kódú és kód nélküli platformokról készül, mint például a Salesforce és a ServiceNow. Az öröklés alapú gondolkodásmóddal való reagálás biztos módja annak, hogy a vállalati alkalmazások több mint kétharmadát kudarcra állítsa.
Az „öröklési gondolkodásmód” az infrastruktúrát sújtó problémák megfelelő leírója. Gazdag, elkényeztetett gyerekeket juttat eszünkbe, akik teljes mértékben az elvégzett munkától és az előttük álló emberektől függenek. Ez nem jó módja a hagyaték felépítésének, és ugyanolyan rossz módszer a rendszer felépítésére.
Ha örökölt gondolkodásmóddal rendelkezik, akkor feltételezi, hogy az infrastruktúra be van állítva. A platform biztonságos, és a biztonság be van építve. A bizalom egyszerűen azért feltételezhető, mert a technológia már a rendszergazda előtt megvolt.
Ez az öröklési gondolkodásmód sújtja az alacsony kódú és a kód nélküli platformokat. A felhasználók egy platform biztonságára támaszkodnak, hogy átvigyék őket a teljes vállalati infrastruktúrán. Ehelyett az adott platform biztonságának csak erre a platformra kell vonatkoznia.
Tegyük fel, hogy a Salesforce fejlesztői automatizált hozzárendelési programot hoznak létre az új potenciális ügyfelek számára. A Salesforce-on belül használják belső feladatokhoz, és ez rendben van. Bízhatnak a platform biztonságában. Úgy döntenek, hogy kibővítik az automatizálás javítása érdekében. A programot egy külső CRM-hez csatlakoztatják, például a ServiceNow-hoz, az SAP-hoz vagy az Oracle-hez. Az öröklési gondolkodásmód átveszi az uralmat: a Salesforce biztonságos. A ServiceNow, az SAP vagy a harmadik fél biztonságban van.
Tehát a Salesforce + harmadik fél = biztonságos.
De nagyon sok ismeretlen van ebben a pluszjelben. Hogyan lehet biztonságosan és megfelelő módon összekapcsolni a Salesforce-ban létrehozott belső programot a külső platformon létrehozott külső programmal? Nagyon sok hibalehetőség van abban az egyetlen karakterben.
És ez csak egy kapcsolat. A Salesforce-ban létrehozott számos program több száz másikat érint. Ez azt jelenti, hogy több száz ismeretlent kezelnek úgy, mint a fent leírt pluszjelet azok az emberek, akiknek nincs vagy alig rendelkeznek fejlesztési tapasztalattal.
Az egyetlen megoldás az, hogy ezt a fejlesztést a DevSecOps alapelveihez való visszatéréssel visszavezetjük a földre.
A DevSecOps Framework létrehozása
DevSecOps A keretrendszereket a koncepció megalkotása óta írták, írták át és írták újra. Nem szükséges újra feltalálni a kereket, amikor létrehozzák őket, különösen akkor, amikor SAFECOde és a Cloud Security Alliance hat pillért épített:
- Kollektív felelősség: A biztonság a vállalat minden tagja felelőssége – de az emberek nem tudnak megfelelni olyan szabványoknak, amelyeket nem ismernek. A potenciális ügyfeleket hozzá kell rendelni a kiberbiztonsági politika irányítása érdekében, és biztosítani kell, hogy az elterjedjen a vállalaton belül.
- Együttműködés és integráció: A tudást meg kell osztani és át kell adni. A vállalatok fele az öröklött gondolkodásmódba esnek, mert mindenki, aki ismerte a régi rendszert, eltűnt. A folyamatos tudásmegosztás segít kiküszöbölni ezt a problémát.
- Pragmatikus megvalósítás: A pragmatikus megvalósítás a fejlesztői élményhez kapcsolódik. A nehéz, hétköznapi és nehézkes folyamatokat nem követik sokáig. A biztonságot be kell építeni a fejlesztési gyakorlatokba – vagyis minden kódsorhoz egy tesztsor szükséges. Egy nagy teljesítményű vállalat ezt továbbvinné egy olyan eszköz használatával, amely automatizálja a tesztkód minden sorát.
- Megfelelés és fejlesztés: A megfelelőségi követelményeknek úgy kell irányítaniuk a fejlesztési folyamatot, hogy a fejlesztők ne térjenek el azoktól. Egy pénzintézet fejlesztője például olyan platformon dolgozna, amelyet úgy terveztek, hogy megfeleljen a Gramm-Leach-Bliley törvénynek. A fejlesztőnek nem kell ismernie az egyes csínját-bínját a cselekménynek ahhoz, hogy megfeleljen, mert azok be vannak építve a platformba.
- Automatizálás: A kiszámítható, megismételhető és nagy volumenű feladatokat lehetőség szerint automatizálni kell, hogy mentesüljenek a fejlesztők terhei, és csökkenjen az emberi hibák kockázata.
- Monitor: A modern felhő infrastruktúrák változnak és fejlődnek. Létfontosságú ennek nyomon követése – ideális esetben valamilyen hangszerelés révén, amely lehetővé teszi a különféle összefüggések egy pillantással történő áttekintését.
egy alacsony vagy nincs kód környezet, ezek a pillérek nem olyan egyszerűek, mint azt várnánk. Az ezeket az eszközöket használó emberek gyakran üzleti szakértők, akik kevéssé ismerik a DevSecOps alapjait.
Emberek, folyamatok és technológia összehozása
Az alacsony kódú és a kód nélküli platformok használata valóban segíthet megszüntetni ezt a készséghiányt. Az alkalmazottak új készségeket szeretnének elsajátítani. A vállalatok ezt támogathatják az emberekre, folyamatokra és technológiára összpontosító DevSecOps keretrendszer létrehozásával.
- folyamatok: Zéró bizalmi környezetben az alacsony kódú és kód nélküli fejlesztőknek nem kell attól tartaniuk, hogy olyan kapcsolatokat hoznak létre, amelyek veszélyeztetik a rendszer integritását, mert erre képtelenek. Nincs kiindulási tekintélyük az elszigetelt rendszerükön kívül.
- emberek: Az elszámoltathatóság kultúrája különbözik a hibáztatás kultúrájától. Az elszámoltathatóság azt jelenti, hogy az egyének jól érzik magukat, ha egy problémával vagy hibával lépnek elő, mert a hangsúly a problémán van, nem a személyen.
- Technológia: A technológia jelenti a legnagyobb akadályt a DevSecOps-elvek megfelelő megvalósítása előtt, mivel ez nem tartozik a fejlesztők kezébe. Fel kell használniuk azt, amit a szervezet ad nekik. Ha ez a technológia nem működik, a fejlesztők olyan megoldásokat dolgoznak ki, amelyek sem nem biztonságosak, sem nem biztonságosak. Lényegében a technológia egyetlen nagy árnyékinformatikai generátorrá válik.
A fejlődés izgalmas időszakát éljük. Egyre több embernek van lehetősége szoftverek készítésére, stratégiák tesztelésére és az üzleti érték növelésére. De ezzel együtt jár a kockázat is. Azok a vállalatok, amelyek azt keresik, hogyan tudják áthárítani ezt a kockázatot a technológiára, a földön maradnak, miközben teret engednek a felfedezésnek.
