3 sposoby, w jakie programiści No-Code mogą strzelać sobie w stopę

Kiedyś organizacje niechętne ryzyku mogły poważnie ograniczać zdolność swoich użytkowników biznesowych do popełniania kosztownych błędów. Przy ograniczonej wiedzy technicznej, ścisłych uprawnieniach i braku wiatru w żagle najgorszą rzeczą, jaką użytkownik biznesowy mógł zrobić, było pobranie złośliwego oprogramowania lub paść ofiarą kampanii phishingowej. Te dni już minęły.

Dzisiaj, każda większa platforma oprogramowania jako usługi (SaaS) jest dostarczana w pakiecie z funkcjami automatyzacji i tworzenia aplikacji, które są przeznaczone dla użytkowników biznesowych i są dla nich sprzedawane. Platformy SaaS, takie jak Microsoft 365, Salesforce i ServiceNow, są osadzane platformy no-code/low-code do swoich istniejących ofert, umieszczając je bezpośrednio w rękach użytkowników biznesowych bez pytania o zgodę korporacyjną. Możliwości, które kiedyś były dostępne tylko dla zespołów IT i programistów, są teraz dostępne w całej organizacji.

Power Platform, niskokodowa platforma firmy Microsoft, jest wbudowana w usługę Office 365 i jest doskonałym przykładem ze względu na silną pozycję firmy Microsoft w przedsiębiorstwach oraz tempo, w jakim jest wdrażana przez użytkowników biznesowych. Być może nie zdając sobie z tego sprawy, przedsiębiorstwa oddają władzę na poziomie programisty w ręce większej liczby osób niż kiedykolwiek wcześniej, przy znacznie mniejszym poziomie bezpieczeństwa lub wiedzy technicznej. Co może pójść nie tak?

Właściwie całkiem sporo. Przeanalizujmy kilka rzeczywistych przykładów z mojego doświadczenia. Informacje zostały zanonimizowane, a procesy specyficzne dla biznesu zostały pominięte.

Sytuacja 1: Nowy sprzedawca? Po prostu to zrób

Zespół obsługi klienta w międzynarodowej firmie zajmującej się handlem detalicznym chciał wzbogacić dane klientów o informacje o konsumentach. W szczególności mieli nadzieję znaleźć więcej informacji o nowych klientach, aby móc lepiej ich obsłużyć, nawet podczas pierwszego zakupu. Zespół obsługi klienta wybrał dostawcę, z którym chciałby współpracować. Sprzedawca wymagał przesłania danych do wzbogacenia, które następnie zostałyby wycofane przez jego usługi.

Zwykle w tym miejscu pojawia się IT. Dział IT musiałby zbudować jakąś integrację, aby uzyskać dane do i od dostawcy. Oczywiście zespół ds. bezpieczeństwa IT również musiałby być zaangażowany, aby upewnić się, że temu dostawcy można powierzyć dane klientów i zatwierdzić zakup. Zamówienia i kwestie prawne również odegrałyby kluczową rolę. W tym przypadku sprawy potoczyły się jednak w innym kierunku.

Ten konkretny zespół obsługi klienta składał się z ekspertów Microsoft Power Platform. Zamiast czekać na zasoby lub zatwierdzenie, po prostu sami zbudowali integrację: zbierali dane klientów z produkcyjnych serwerów SQL, przesyłali je wszystkie na serwer FTP dostarczony przez dostawcę i pobierali wzbogacone dane z serwera FTP do bazie danych produkcji. Cały proces wykonywał się automatycznie za każdym razem, gdy do bazy danych dodawany był nowy klient. Wszystko to odbywało się za pomocą interfejsów typu „przeciągnij i upuść”, hostowanych w usłudze Office 365 i przy użyciu ich kont osobistych. Licencja była opłacana z własnej kieszeni, co eliminowało zamówienia z obiegu.

Wyobraźcie sobie zdziwienie CISO, gdy znaleźli kilka automatyzacji biznesowych przenoszących dane klientów na zakodowany na stałe adres IP w AWS. Będąc klientem korzystającym wyłącznie z platformy Azure, wywołało to gigantyczną czerwoną flagę. Ponadto dane były wysyłane i odbierane przez niezabezpieczone połączenie FTP, co stwarzało zagrożenie dla bezpieczeństwa i zgodności. Kiedy zespół ds. bezpieczeństwa znalazł to dzięki dedykowanemu narzędziu bezpieczeństwa, dane przepływały do ​​i z organizacji przez prawie rok.

Sytuacja 2: Och, czy zbieranie kart kredytowych jest złe?

Zespół HR dużego dostawcy IT przygotowywał się do organizowanej raz w roku kampanii „Give Away”, w ramach której pracownicy są zachęcani do przekazywania darowizn na rzecz swojej ulubionej organizacji charytatywnej, a firma włącza się, przekazując każdego dolara przekazanego przez pracowników. Ubiegłoroczna kampania odniosła ogromny sukces, więc oczekiwania były ogromne. Aby wesprzeć kampanię i złagodzić procesy ręczne, kreatywny pracownik HR wykorzystał Power Platform firmy Microsoft do stworzenia aplikacji, która ułatwiła cały proces. Aby się zarejestrować, pracownik loguje się do aplikacji za pomocą swojego konta firmowego, przekazuje kwotę darowizny, wybiera organizację charytatywną i podaje dane karty kredytowej do zapłaty.

Akcja odniosła ogromny sukces, przy rekordowym udziale pracowników i niewielkim nakładzie pracy fizycznej ze strony pracowników HR. Jednak z jakiegoś powodu zespół ds. bezpieczeństwa nie był zadowolony z tego, jak sprawy się potoczyły. Podczas rejestracji do kampanii pracownik zespołu ds. bezpieczeństwa zorientował się, że pobieranie kart kredytowych odbywa się w aplikacji, która nie wygląda tak, jak powinna. Po dochodzeniu okazało się, że te dane karty kredytowej rzeczywiście były niewłaściwie obsługiwane. Dane kart kredytowych były przechowywane w domyślnym środowisku Power Platform, co oznacza, że ​​były dostępne dla całej dzierżawy usługi Azure AD, w tym dla wszystkich pracowników, dostawców i wykonawców. Ponadto były one przechowywane jako proste pola tekstowe.

Na szczęście naruszenie zasad przetwarzania danych zostało wykryte przez zespół ds. bezpieczeństwa, zanim wykryli je złośliwi aktorzy — lub audytorzy zgodności. Baza danych została oczyszczona, a aplikacja poprawiona, aby prawidłowo obsługiwała informacje finansowe zgodnie z rozporządzeniem.

Sytuacja 3: Dlaczego nie mogę po prostu korzystać z Gmaila?

Jako użytkownik nikt nie lubi kontroli zapobiegania utracie danych w przedsiębiorstwie. Nawet jeśli jest to konieczne, wprowadzają irytujące tarcia w codziennych operacjach. W rezultacie użytkownicy zawsze próbowali je obejść. Odwiecznym przeciąganiem liny między kreatywnymi użytkownikami biznesowymi a zespołem ds. bezpieczeństwa jest korporacyjna poczta e-mail. Synchronizowanie firmowej poczty e-mail z osobistym kontem e-mail lub firmowego kalendarza z osobistym kalendarzem: zespoły ds. bezpieczeństwa mają na to rozwiązanie. Mianowicie, wdrożyli zabezpieczenia poczty e-mail i rozwiązania DLP, aby zablokować przekazywanie wiadomości e-mail i zapewnić nadzór nad danymi. To rozwiązuje problem, prawda?

Więc nie. Powtarzające się odkrycie w dużych przedsiębiorstwach i małych firmach stwierdza, że ​​użytkownicy tworzą automatyzacje, które omijają kontrolę poczty e-mail, aby przekazywać firmową pocztę e-mail i kalendarze na konta osobiste. Zamiast przekazywać wiadomości e-mail, kopiują i wklejają dane z jednej usługi do drugiej. Logując się do każdej usługi przy użyciu oddzielnej tożsamości i automatyzując proces kopiowania i wklejania bez użycia kodu, użytkownicy biznesowi z łatwością obchodzą kontrole bezpieczeństwa — a zespoły ds. bezpieczeństwa nie mają łatwego sposobu, aby się o tym przekonać.

Społeczność Power Platform nawet się rozwinęła Szablony które każdy użytkownik Office 365 może pobrać i używać.

Z dużą mocą przychodzi duża odpowiedzialność

Wzmocnienie pozycji użytkowników biznesowych jest świetne. Linie biznesowe nie powinny czekać na IT ani walczyć o zasoby rozwojowe. Jednak nie możemy po prostu dać użytkownikom biznesowym uprawnień na poziomie programisty bez żadnych wskazówek ani barier i oczekiwać, że wszystko będzie w porządku.

Zespoły ds. bezpieczeństwa muszą edukować użytkowników biznesowych i uświadamiać im ich nowe obowiązki jako twórców aplikacji, nawet jeśli te aplikacje zostały zbudowane przy użyciu „bez kodu”. Zespoły ds. bezpieczeństwa powinny również wdrożyć bariery ochronne i monitorować, aby zapewnić, że gdy użytkownicy biznesowi popełnią błąd, tak jak my wszyscy, nie przełoży się to na pełne wycieki danych lub incydenty kontroli zgodności.