Ponieważ technologia rozwija się w coraz szybszym tempie, programiści stają przed większym niż kiedykolwiek wyzwaniem, aby nadążyć kod zabezpieczać i łagodzić stale rosnące zagrożenia bezpieczeństwa cybernetycznego. Ale przykłady zebrane przez ponad 20 lat pracy w terenie pokazują, że zawsze istniały przeszkody do pokonania.
Komputer główny IBM
Kodowanie komputerów mainframe IBM polegało na pisaniu COBOL/PLI programy zaplanowane do uruchamiania jako nocne procesy wsadowe do odczytu/aktualizacji dużych, złożonych, hierarchicznych baz danych. Resource Access Control Facility (RACF) zarządzał dostępem użytkowników do krytycznych zasobów, z modelem bezpieczeństwa, który opierał się na zasada najmniejszego uprzywilejowania. Użycie konta z odpowiednim poziomem dostępu było niezbędne, aby zapobiec zatrzymaniu lub niepowodzeniu wykonywania zadań, ponieważ konto użytkownika nie miało odpowiedniego dostępu do odczytu lub zapisu w gałęzi bazy danych.
Serwer klienta
Następnym krokiem było tworzenie front-endu przy użyciu języka obiektowego Smalltalk-80 zbierać zamówienia zakupu przechowywane w bazie danych IBM DB2. Bez wbudowanych zabezpieczeń Smalltalk promował enkapsulację – obiekty hermetyzowały stan wewnętrzny, a bezpieczeństwo danych było chronione poprzez kontrolowanie przepływu danych między obiektami. Przepływ informacji wykorzystywał protokół do opracowywania poziomów bezpieczeństwa, w których znajdują się obiekty; informacje mogą być przekazywane do obiektu na bardziej bezpiecznym poziomie, ale nie do obiektu na mniej bezpiecznym poziomie.
SAP Dynapro
Towarzyszyło temu SAP Dynapro rozwój za pomocą ABAP. Kody transakcji i profile autoryzacji były na porządku dziennym, a programiści oczekiwali dodania odpowiednich kontroli w kodzie, aby sprawdzić, czy konto użytkownika ma prawidłowy profil autoryzacji dostępu do aplikacji, odczytu / zapisu do bazy danych itp. błąd spowodował, że użytkownik końcowy został skonfrontowany z monitami „Brak autoryzacji” lub otrzymał zbyt duży dostęp, aby jego aktywność nigdy nie była kwestionowana.
Rok 2017 był przełomowym momentem dla firm korzystających z SAP po głośnej sprawie sądowej która poruszyła koncepcję pośredniego dostępu do systemów SAP. Pojedyncze konto usługi (często z dostępem do SAP_ALL) było często używane do wszystkich zdalnych wywołań dostępu/zdalnych funkcji (RFC), a programiści znali hasła do tych kont. Przedsiębiorstwa szybko powróciły do indywidualnych kont dla każdej aplikacji.
tworzenie stron internetowych
The SAP Enterprise Portal (strony WebDynpro Java/Java Server) i Serwer aplikacji internetowych SAP (WebDynpro ABAP) otworzył drzwi do rozwoju opartego na przeglądarce w środowisku SAP. Tworzenie i wdrażanie kodu Java wymagało lokalnie zainstalowanej platformy programistycznej (Eclipse), a programiści musieli zapewnić bezpieczeństwo bazy kodu, z repozytoriami kodu przechowywanymi na bezpiecznych dyskach sieciowych z ograniczonym dostępem.
Za kulisami aplikacji internetowej jest złożoność i wielu użytkowników doświadczy komunikatów o błędach HTTP. Skuteczne rozwiązywanie problemów wymagało znajomości architektury oraz na poziomie sieci – Load Balancer, DNS, mapowanie portów, serwery reverse proxy, nawigacja w domenie, certyfikaty itp. Używanie protokołu HTTP było często używane jako domyślne, aby ułatwić tworzenie aplikacji, ale bezpieczeństwo było skompromitowany.
Najlepsze praktyki programistów powinny zapewniać, że port HTTPS jest zawsze używany do tworzenia stron internetowych, z zewnętrznie podpisanymi certyfikatami i standardowym w branży poziomem szyfrowania.
Jednokrotne logowanie (SSO) i uwierzytelnianie wieloskładnikowe (MFA)
Uwierzytelnianie podstawowe (identyfikator użytkownika i hasło) przekazuje szczegóły konta i hasła jako widoczne parametry w adresach URL do symulacji SSO, narażając go na wyzysk; przyjęcie tokenów logowania i certyfikatów umożliwiających logowanie do aplikacji było zatem przełomem.
Kerberos tokeny zawierające tożsamość użytkownika mogą być używane do logowania jednokrotnego w lokalnym systemie SAP, który przekazuje poświadczenia użytkownika jako plik cookie w celu wygenerowania biletu logowania SAP umożliwiającego logowanie do wielu innych systemów SAP. Ponieważ jednak pliki cookie są podatne na wykorzystanie, preferowane są bilety SAP Assertion Tickets, ponieważ są one ograniczone tylko do systemu docelowego i są przekazywane jako nagłówek HTTP, a nie jako plik cookie.
SAML 2.0 stał się otwartym standardem internetowego uwierzytelniania i autoryzacji. Dostawca tożsamości wystawia token logowania dopiero po potwierdzeniu tożsamości użytkownika, a ten token SAML 2.0 jest przekazywany do aplikacji hostującej usługodawcę. Korzystanie z protokołu SSL, szyfrowania, ograniczonej ważności tokena itp. ogranicza wykorzystanie exploitów.
Rozwój aplikacji mobilnych i API
API programowanie oznacza bezpieczne przesyłanie pakietów danych między systemami za pośrednictwem RFC między systemami lub usług sieciowych, a często za pośrednictwem dodatkowego oprogramowania pośredniczącego lub warstw pośredniczących w usługach.
Wymaga zrozumienia całej drogi API, często z pakietami danych, które są przekształcane z systemu źródłowego do innego formatu, który może być odbierany przez miejsce docelowe, a także wymiany tokenów tożsamości, takich jak SAML 2.0 do OAuth 2.0.
Dla ODPOCZYNEK (jednej z najpopularniejszych usług internetowych), OAuth 2.0 używa zakresów, aby umożliwić aplikacji dostęp do zasobów w innych systemach za pośrednictwem internetowego interfejsu API. Zakres ogranicza dostęp użytkownika do aplikacji, dlatego dobre zaprojektowanie zakresów w ramach modelu autoryzacji jest niezbędne do zapewnienia odpowiedniego poziomu dostępu.
Zgodność przeglądarki i różne urządzenia
Najnowsze przeglądarki mają coraz większe zabezpieczenia w celu złagodzenia zagrożeń bezpieczeństwa cybernetycznego. Firmy korzystające z trybu emulacji przeglądarki (tj. emulujące starsze wersje, takie jak IE 5) stwierdzają, że działające od lat aplikacje internetowe przestają działać w nowoczesnych przeglądarkach, takich jak Chromium czy Edge Chromium, co wymaga nieplanowanych prac rozwojowych w celu zabezpieczenia kodu.
Rozwój urządzeń mobilnych dodaje kolejny element z danymi offline przechowywanymi na urządzeniu, co umożliwia aplikacji kontynuację od miejsca, w którym została przerwana, w przypadku utraty połączenia sieciowego. „Offline OData” i podobne techniki umożliwiające osiągnięcie tego celu wymagają od programistów zapewnienia przechowywania na urządzeniu tylko minimalnej ilości danych (aby proces był jak najbardziej bezpieczny) oraz zarządzania „punktem synchronizacji”, tak aby po nawiązaniu połączenia przywrócone dane można bezpiecznie przesyłać / synchronizować z powrotem do ich źródła.
Ciągła integracja/dostarczanie/wdrażanie
Przedsiębiorstwa dążą do realizacji „zwinnych projektów”, które umożliwiają skrócenie cyklu życia oprogramowania bez uszczerbku dla jakości i bezpieczeństwa. Automatyzacja cyklu życia DevOps (poprzez potoki ciągłej integracji, dostarczania i wdrażania w celu przeglądania kodu, budowania, wdrażania, testowania, zatwierdzania, cykli życia migracji z rozwoju do produkcji) uruchamia się w momencie, gdy programista sprawdza kod w repozytorium kodu.
Narzędzia do skanowania kodu, takie jak Onapsis I SonarQube można zintegrować jako część potoku DevSecOps w celu skanowania kodu pod kątem najlepszych praktyk bezpiecznego kodowania, oznaczając luki w różnych bazach kodu, od ABAP po XML.
Istnieją jednak pułapki. Często skanowanie kodu jest optymalizowane pod kątem najnowszej wersji kodu, a linia starszego kodu może zostać oznaczona jako zagrożenie. Aby uniknąć dużej liczby fałszywych alarmów, progi muszą być skonfigurowane tak, aby ignorowały lub ustawiały ostrzeżenie dla kodu, który jest bezpieczny, ale napisany przy użyciu przestarzałej techniki. Alerty pomogą rozwinąć lepsze standardy kodowania w zespołach programistów, aby zminimalizować naruszenia DevSecOps.
Więcej tego samego
Zapewnienie bezpieczeństwa kodowania zawsze stanowiło wyzwanie. Większość z nich udało się przezwyciężyć dzięki połączeniu technologii i ludzkiej wiedzy – model, który należy kontynuować.