Jak DevSecOps wzmacnia pozycję deweloperów-obywateli

Łącznie do 2025 roku globalne tworzenie danych osiągnie 181 zettabajtów. Dla przedsiębiorstw te dane są atutem, umożliwiającym im wykorzystanie różnych platform technologicznych do tworzenia wysoce spersonalizowanych doświadczeń klientów, które budują lojalność i przyciągają nowe firmy. Jednak te doświadczenia zależą od infrastruktur chmurowych korzystających ze wspólnych trybów zabezpieczeń. W tym właśnie leży ryzyko, które rośnie wraz z rozwojem technologii i obejmuje nową armię programistów obywatelskich korzystających z platform o niskim i niskim kodzie.

Zrozumienie i przezwyciężenie sposobu myślenia o dziedziczeniu 

Gartner szacuje, że do 2025 r. 70% aplikacji dla przedsiębiorstw będzie zbudowanych z platform niskokodowych i bezkodowych, takich jak Salesforce i ServiceNow. Reagowanie z nastawieniem opartym na dziedziczeniu to pewny sposób na spowodowanie awarii ponad dwóch trzecich aplikacji dla przedsiębiorstw.   

„Sposób myślenia oparty na dziedziczeniu” jest trafnym deskryptorem problemów nękających infrastrukturę. Przywodzi na myśl bogate, rozpieszczone dzieci, które są całkowicie zależne od wykonanej pracy i ludzi, którzy byli przed nimi. To nie jest dobry sposób na budowanie dziedzictwa i jest to równie zły sposób na budowanie systemu.

Jeśli masz podejście oparte na tradycji, zakładasz, że infrastruktura jest gotowa. Platforma jest bezpieczna, a zabezpieczenia wbudowane. Zakłada się zaufanie po prostu dlatego, że technologia istniała przed administratorem.

Ten sposób myślenia o dziedziczeniu jest plagą platform z małą ilością kodu i bez kodu. Użytkownicy polegają na bezpieczeństwie platformy, która umożliwia ich transport przez całą infrastrukturę przedsiębiorstwa. Zamiast tego bezpieczeństwo tej platformy powinno dotyczyć tylko tej platformy.

Załóżmy, że programiści Salesforce tworzą zautomatyzowany program przypisania nowych potencjalnych klientów. Używają go w Salesforce do zadań wewnętrznych i jest w porządku. Mogą polegać na bezpieczeństwie platformy. Decydują się na jego rozbudowę, aby poprawić automatyzację. Łączą ten program z zewnętrznym systemem CRM, takim jak ServiceNow, SAP lub Oracle. Dominuje nastawienie na dziedziczenie: Salesforce jest bezpieczny. ServiceNow, SAP lub strona trzecia są bezpieczne.

Zatem Salesforce + strona trzecia = bezpiecznie.

Ale w tym znaku plus jest wiele niewiadomych. Jak bezpiecznie i zgodnie z przepisami połączyć program wewnętrzny stworzony w Salesforce z programem zewnętrznym stworzonym na platformie zewnętrznej? W tym pojedynczym znaku jest dużo miejsca na błędy.  

A to tylko jedno połączenie. Wiele programów stworzonych w Salesforce dotyka setek innych. Oznacza to, że setki niewiadomych są traktowane jak znak plus opisany powyżej przez osoby, które nie mają żadnego doświadczenia w programowaniu.  

Jedynym rozwiązaniem jest powrót na ziemię i powrót do zasad DevSecOps.

Ustanawianie platformy DevSecOps 

DevSecOps Frameworki były pisane, przepisywane i pisane od czasu stworzenia koncepcji. Przy ich zakładaniu nie ma potrzeby wymyślania koła na nowo, zwłaszcza gdy SAFECode i Cloud Security Alliance zbudował sześć filarów:

1. Wspólna odpowiedzialność: Bezpieczeństwo jest obowiązkiem każdej osoby w przedsiębiorstwie, ale ludzie nie są w stanie spełnić standardów, których nie znają. Należy przypisać potencjalnych klientów, którzy będą kierować polityką cyberbezpieczeństwa i zapewnić jej rozpowszechnianie w całym przedsiębiorstwie.  
2. Współpraca i integracja: Wiedzą trzeba się dzielić i przekazywać. Połową powodu, dla którego przedsiębiorstwa popadają w podejście oparte na dziedzictwie, jest to, że wszyscy, którzy znali stary system, już nie żyją. Ciągłe dzielenie się wiedzą pomaga wyeliminować ten problem.
3. Pragmatyczne wdrożenie: Pragmatyczne wdrożenie wiąże się z doświadczeniem programisty. Procesy trudne, przyziemne i nieporęczne nie są realizowane długo. Bezpieczeństwo powinno być wpisane w praktyki programistyczne — to znaczy, że każda linia kodu wymaga linii testowej. Wysokowydajne przedsiębiorstwo poszłoby dalej, używając narzędzia do automatyzacji każdej linii kodu testowego.
4. Zgodność i rozwój: Wymagania zgodności powinny kierować procesem rozwoju w sposób uniemożliwiający programistom odejście od nich. Na przykład programista instytucji finansowej będzie pracował na platformie zaprojektowanej tak, aby była zgodna z ustawą Gramm-Leach-Bliley. Deweloper nie musi znać poszczególnych tajników ustawy, aby zachować zgodność, ponieważ są one wbudowane w platformę.  
5. Automatyka: Zadania, które są przewidywalne, powtarzalne i wymagają dużej liczby zadań, należy w miarę możliwości zautomatyzować, aby odciążyć programistów i zmniejszyć ryzyko błędu ludzkiego.
6. Monitorowanie: Nowoczesne infrastruktury chmurowe zmieniają się i rozwijają. Ważne jest, aby to śledzić — najlepiej poprzez jakąś formę orkiestracji, która pozwala na szybki przegląd wszystkich różnych wzajemnych powiązań.

W z niskim kodem lub bez niego środowiska, filary te nie są tak proste, jak można by się spodziewać. Osoby korzystające z tych narzędzi to często eksperci biznesowi, którzy nie znają podstaw DevSecOps.

Łączenie ludzi, procesów i technologii

Korzystanie z platform o niskiej zawartości kodu i bez kodu może faktycznie pomóc w wypełnieniu tej luki w umiejętnościach. Pracownicy chcą zdobywać nowe umiejętności. Przedsiębiorstwa mogą to wspierać, ustanawiając środowisko DevSecOps skupiające się na ludziach, procesach i technologii. 

• Procesy: W środowisku o zerowym zaufaniu programiści korzystający z niewielkiej ilości kodu i nie korzystający z niego nie muszą się martwić tworzeniem połączeń, które zagrażają integralności systemu, ponieważ nie są do tego zdolni. Nie mają żadnych uprawnień bazowych poza izolowanym systemem.  
• Ludzie: Kultura odpowiedzialności różni się od kultury obwiniania. Odpowiedzialność oznacza, że ​​poszczególne osoby czują się komfortowo, zgłaszając problem lub błąd, ponieważ skupiają się na problemie, a nie na osobie.
• Technologia: Technologia jest największą pojedynczą barierą we właściwym wdrażaniu zasad DevSecOps, ponieważ jest poza zasięgiem programistów. Muszą korzystać z tego, co daje im organizacja. Jeśli ta technologia nie zadziała, programiści opracują obejścia, które nie będą ani bezpieczne, ani bezpieczne. Zasadniczo technologia staje się jednym wielkim generatorem cieni IT.

Żyjemy w ekscytujących czasach rozwoju. Coraz więcej osób ma możliwość tworzenia oprogramowania, testowania strategii i zwiększania wartości biznesowej. Ale z tym wiąże się ryzyko. Przedsiębiorstwa, które szukają sposobów na przeniesienie tego ryzyka na technologię, będą skupiać się na rozwoju, pozostawiając jednocześnie pole do eksploracji.