Aplikacje i usługi

Aplikacje i skojarzone z nimi dane ostatecznie działają jako podstawowy magazyn wartości biznesowej na platformie w chmurze. Chociaż składniki platformy, takie jak tożsamość i magazyn, są kluczowymi elementami środowiska zabezpieczeń, aplikacje odgrywają ważną rolę w ryzyku dla firmy, ponieważ:

  • Procesy biznesowe są hermetyzowane i wykonywane przez aplikacje i usługi muszą być dostępne i zapewniane wysoką integralność

  • Dane biznesowe są przechowywane i przetwarzane przez obciążenia aplikacji oraz wymagają wysokich gwarancji poufności, integralności i dostępności.

Ta sekcja koncentruje się na aplikacjach napisanych przez twoją organizację lub przez inne osoby w imieniu organizacji, a aplikacje saaS lub aplikacje dostępne komercyjnie zainstalowane na maszynach wirtualnych IaaS.

Diagram of Application Models

Nowoczesne platformy w chmurze, takie jak Platforma Azure, mogą hostować zarówno starsze, jak i nowoczesne generacje aplikacji

  • Starsze aplikacje są hostowane na maszynach wirtualnych infrastruktury jako usługi (IaaS), które zwykle obejmują wszystkie zależności, w tym system operacyjny, oprogramowanie pośredniczące i inne składniki.

  • Nowoczesne Aplikacje platformy jako usługi (PaaS) nie wymagają od właściciela aplikacji zarządzania podstawowymi systemami operacyjnymi (OS) serwera i czasami są w pełni "bezserwerowe" i tworzone głównie przy użyciu funkcji jako usługi.

    Notatki: Popularne formy nowoczesnych aplikacji to kod aplikacji hostowany w usługach Azure App Services i aplikacje konteneryzowane (choć kontenery mogą być również hostowane na maszynach wirtualnych IaaS lub lokalnie).

  • Hybrydowe — chociaż aplikacje hybrydowe mogą przyjmować wiele formularzy, najczęściej jest to stan "IaaS plus", w którym starsze aplikacje przechodzą do nowoczesnej architektury z nowoczesnymi usługami zastępującymi starsze składniki lub dodaną starszą aplikacją.

Zabezpieczanie aplikacji wymaga gwarancji zabezpieczeń dla trzech różnych typów składników:

  • Kod aplikacji — jest to logika, która definiuje napisaną aplikację niestandardową. Bezpieczeństwo tego kodu jest obowiązkiem właścicieli aplikacji we wszystkich generacjach architektury aplikacji, w tym wszystkich fragmentów kodu typu open source lub składników zawartych w kodzie. Zabezpieczenie kodu wymaga zidentyfikowania i ograniczenia ryzyka związanego z projektem i implementacją aplikacji, a także oceny ryzyka łańcucha dostaw uwzględnionych składników. Należy pamiętać, że ewolucja aplikacji w architektury mikrousług spowoduje podzielenie różnych aspektów kodu aplikacji na mniejsze usługi w porównaniu z pojedynczą monolityczną bazą kodu.

  • Application Services — są to różne standardowe składniki używane przez aplikację, takie jak bazy danych, dostawcy tożsamości, centra zdarzeń, zarządzanie urządzeniami IoT itd. W przypadku usług w chmurze jest to wspólna odpowiedzialność:

    • Dostawca usług w chmurze — Bezpieczeństwo usługi bazowej jest obowiązkiem dostawcy usług w chmurze

    • Właściciel aplikacji — właściciel aplikacji jest odpowiedzialny za wpływ na bezpieczeństwo konfiguracji i działania wystąpień usługi używanych przez aplikację, w tym wszelkich danych przechowywanych i przetwarzanych w usłudze.

  • Platforma hostingu aplikacji — jest to środowisko obliczeniowe, w którym aplikacja faktycznie wykonuje i uruchamia. W przedsiębiorstwie z aplikacjami hostowanymi lokalnie na platformie Azure i w chmurach innych firm, takich jak Amazon Web Services (AWS), może to mieć wiele form ze znaczącymi różnicami w zakresie tego, kto jest odpowiedzialny za bezpieczeństwo:

    • Starsze aplikacje zwykle wymagają pełnego systemu operacyjnego (i dowolnego oprogramowania pośredniczącego) hostowanego na sprzęcie fizycznym lub zwirtualizowanym. Sprzęt wirtualny może być hostowany lokalnie lub na maszynach wirtualnych infrastruktury jako usługi (IaaS). Ten system operacyjny i zainstalowane oprogramowanie pośredniczące/inne składniki są obsługiwane i zabezpieczone przez właściciela aplikacji lub ich zespoły infrastruktury.
      Odpowiedzialność za składniki wirtualizacji sprzętu fizycznego i systemu operacyjnego (hosty wirtualizacji, systemy operacyjne i usługi zarządzania) różni się w zależności od tego:

      • Lokalnie — właściciel aplikacji lub jego organizacja jest odpowiedzialna za konserwację i bezpieczeństwo.

      • IaaS — dostawca usług w chmurze jest odpowiedzialny za konserwację i bezpieczeństwo podstawowej infrastruktury, a organizacja właściciela aplikacji jest odpowiedzialna za konfigurację maszyny wirtualnej, system operacyjny i wszystkie zainstalowane na nim składniki.

    • Nowoczesne aplikacje są hostowane w środowiskach platformy jako usługi (PaaS), takich jak usługa aplikacji platformy Azure. W większości typów usług aplikacji podstawowy system operacyjny jest abstrahowany od właściciela aplikacji i zabezpieczony przez dostawcę usług w chmurze. Właściciele aplikacji są odpowiedzialni za zabezpieczenia konfiguracji usługi aplikacji, które są im udostępniane.

    • Kontenery to mechanizm tworzenia pakietów aplikacji, w którym aplikacje są abstrahowane od środowiska, w którym są uruchamiane. Te konteneryzowane aplikacje mieszczą się w starszych lub nowoczesnych modelach powyżej w zależności od tego, czy są uruchamiane w usłudze kontenera przez dostawcę chmury (nowoczesne aplikacje) lub na serwerze zarządzanym przez organizację (lokalnie lub w usłudze IaaS). Aby uzyskać więcej informacji, zobacz sekcję zabezpieczeń kontenera poniżej.

Identyfikowanie i klasyfikowanie aplikacji krytycznych dla działania firmy

Upewnij się, że zidentyfikowano i sklasyfikowano aplikacje w portfolio, które mają kluczowe znaczenie dla funkcji biznesowych.

Organizacje w przedsiębiorstwie zwykle mają duże portfolio aplikacji, dlatego ustalanie priorytetów, gdzie należy zainwestować czas i nakład pracy w zadania ręczne i intensywnie korzystające z zasobów, takie jak modelowanie zagrożeń, może zwiększyć efektywność programu zabezpieczeń.

Zidentyfikuj aplikacje, które mają duży potencjalny wpływ i/lub wysokie potencjalne narażenie na ryzyko.

  • Duży potencjalny wpływ — zidentyfikuj aplikację, która będzie miała znaczący wpływ na firmę w przypadku naruszenia zabezpieczeń. Może to mieć formę co najmniej jednej z następujących wartości:

    • Dane krytyczne dla działania firmy — aplikacje, które przetwarzają lub przechowują informacje, co spowodowałoby znaczny negatywny wpływ na działalność biznesową lub misję w przypadku utraty poufności, integralności lub dostępności.

    • Dane regulowane — aplikacje obsługujące instrumenty pieniężne i poufne informacje osobowe regulowane przez standardy. Na przykład, payment card industry (PCI) i Health Information Portability and Accountability Act (HIPAA).

    • Dostępność krytyczna dla działania firmy — aplikacje, których funkcjonalność ma kluczowe znaczenie dla misji biznesowych organizacji, takich jak linie produkcyjne generujące przychody, urządzenia lub usługi krytyczne dla życia i bezpieczeństwa oraz inne krytyczne funkcje.

    • Znaczący dostęp — aplikacje, które mają dostęp do systemów o dużym potencjalnym wpływie poprzez środki techniczne, takie jak

      • Przechowywane poświadczenia lub klucze/certyfikaty, które udzielają dostępu do danych/usługi

      • Uprawnienia przyznane za pośrednictwem list kontroli dostępu lub innych środków

  • Wysoka ekspozycja na ataki — aplikacje, które są łatwo dostępne dla osób atakujących, takich jak aplikacje internetowe w otwartym Internecie. Starsze aplikacje mogą być również bardziej narażeni na ataki, ponieważ osoby atakujące i testerzy penetracyjnych często je atakują, ponieważ wiedzą, że starsze aplikacje często mają luki w zabezpieczeniach, które są trudne do naprawienia.

Wdrażanie metodyki DevOps

Organizacje powinny przejść od cyklu programowania "Kaskadowy" do cyklu projektowania metodyki DevOps ciągłej integracji, ciągłego dostarczania (CI/CD) dla aplikacji tak szybko, jak jest to praktyczne. DevOps to związek osób, procesów i narzędzi, które umożliwiają ciągłe dostarczanie wartości użytkownikom końcowym. Kontrakt dev and Ops odnosi się do łączenia dyscyplin programistycznych i operacyjnych w zespoły wielodyscyplinarne, które współpracują ze wspólnymi i wydajnymi praktykami i narzędziami.

Model DevOps zwiększa zdolność organizacji do szybkiego rozwiązywania problemów z zabezpieczeniami bez oczekiwania na dłuższy cykl planowania i testowania modelu kaskadowego.

Postępuj zgodnie ze wskazówkami dotyczącymi zabezpieczeń metodyki DevOps

Organizacje powinny korzystać ze wskazówek i automatyzacji w celu zabezpieczania aplikacji w chmurze, a nie od zera.

Korzystanie z zasobów i lekcji poznanych przez organizacje zewnętrzne, które są wczesnymi użytkownikami tych modeli, może przyspieszyć poprawę stanu zabezpieczeń organizacji przy mniejszym wydatkach na nakład pracy i zasobów.

Używanie usług w chmurze zamiast implementacji niestandardowych

Deweloperzy powinni korzystać z usług dostępnych u dostawcy usług w chmurze dla dobrze ustalonych funkcji, takich jak bazy danych, szyfrowanie, katalog tożsamości i uwierzytelnianie, zamiast pisać niestandardowe wersje tych usług.

Te usługi zapewniają lepsze zabezpieczenia, niezawodność i wydajność, ponieważ dostawcy usług w chmurze działają i zabezpieczają je za pomocą dedykowanych zespołów z głęboką wiedzą w tych obszarach. Korzystanie z tych usług pozwala również uwolnić zasoby deweloperów od ponownego wynalezienia przysłowiowego koła, dzięki czemu mogą skupić się na czasie programowania na unikatowych wymaganiach firmy. Należy przestrzegać tej praktyki, aby uniknąć ryzyka podczas tworzenia nowych aplikacji, a także zmniejszyć ryzyko w istniejących aplikacjach podczas planowanego cyklu aktualizacji lub aktualizacji aplikacji skoncentrowanej na zabezpieczeniach.

Kilka możliwości, które powinny być priorytetowe w pierwszej kolejności z powodu potencjalnego wpływu na zabezpieczenia:

  • Tożsamość — katalogi użytkowników i inne funkcje uwierzytelniania są złożone w celu opracowania i krytycznego znaczenia dla gwarancji zabezpieczeń. Unikaj używania rozwiązań do uwierzytelniania macierzystego i faworyzuj dojrzałe możliwości, takie jak usługa Azure Active Directory (Azure AD), usługa Azure AD B2B, usługa Azure AD B2C lub rozwiązania innych firm do uwierzytelniania i udzielania uprawnień użytkownikom, partnerom, klientom, aplikacjom, usługom i innym podmiotom.

  • Ochrona danych — deweloperzy powinni używać ustalonych funkcji od dostawców chmury, takich jak szyfrowanie natywne w usługach w chmurze, w celu szyfrowania i ochrony danych. Świat zabezpieczeń jest zaśmiecony przykładami nieudanych prób ochrony danych lub haseł, które nie stanął w obronie rzeczywistych ataków. Jeśli wymagane jest bezpośrednie użycie kryptografii, deweloperzy powinni wywołać dobrze ustalone algorytmy kryptograficzne i nie próbować wymyślić własnych.

  • Zarządzanie kluczami — najlepiej używać tożsamości do uwierzytelniania zamiast bezpośredniego obsługiwania kluczy (zobacz Preferuj uwierzytelnianie tożsamości za pośrednictwem kluczy). W sytuacjach, w których uzyskiwanie dostępu do usług, które wymagają dostępu do kluczy, skorzystaj z usługi zarządzania kluczami, takiej jak Azure Key Vault lub AWS Key Management Service , aby zarządzać tymi kluczami i zabezpieczać je zamiast próbować bezpiecznie obsługiwać klucze w kodzie aplikacji. Możesz użyć narzędzia CredScan , aby odnaleźć potencjalnie uwidocznione klucze w kodzie aplikacji.

  • Konfiguracje aplikacji — niespójne konfiguracje dla aplikacji mogą tworzyć zagrożenia bezpieczeństwa. Usługa Azure App Configuration udostępnia usługę do centralnego zarządzania ustawieniami aplikacji i flagami funkcji, co pomaga ograniczyć to ryzyko.

Korzystanie z funkcji natywnego zabezpieczeń w usługach aplikacji

Używaj natywnych funkcji zabezpieczeń wbudowanych w usługi w chmurze zamiast dodawania zewnętrznych składników zabezpieczeń (na potrzeby szyfrowania danych, filtrowania ruchu sieciowego, wykrywania zagrożeń i innych funkcji).

Natywne mechanizmy kontroli zabezpieczeń są utrzymywane i obsługiwane przez dostawcę usług, eliminując lub zmniejszając nakład pracy wymagany do integracji zewnętrznych narzędzi zabezpieczeń i aktualizując te integracje w czasie. Usługi w chmurze szybko ewoluują, co znacznie zwiększa obciążenie utrzymania zewnętrznego narzędzia i zwiększa ryzyko utraty widoczności i ochrony zabezpieczeń z tych narzędzi, jeśli narzędzie nie nadąża za usługą w chmurze.

Preferuj uwierzytelnianie tożsamości za pośrednictwem kluczy

Zawsze uwierzytelniaj się za pomocą usług tożsamości, a nie kluczy kryptograficznych, jeśli są dostępne.

Bezpieczne zarządzanie kluczami za pomocą kodu aplikacji jest trudne i regularnie prowadzi do błędów, takich jak przypadkowe publikowanie poufnych kluczy dostępu do repozytoriów kodu, takich jak GitHub. Systemy tożsamości oferują bezpieczne i użyteczne środowisko kontroli dostępu z wbudowanymi zaawansowanymi mechanizmami rotacji kluczy, monitorowaniem anomalii i nie tylko. Większość organizacji ma również wykwalifikowanych zespołów zajmujących się zarządzaniem systemami tożsamości i kilkoma osobami aktywnie zarządzającymi kluczowymi systemami zabezpieczeń.

W przypadku usług, które oferują uwierzytelnianie usługi Azure AD, takie jak Azure Storage, Azure App Service, Azure Backup, użyj jej do uwierzytelniania i autoryzacji. Aby jeszcze bardziej uprościć korzystanie z tożsamości dla deweloperów, możesz również skorzystać z tożsamości zarządzanych w celu przypisania tożsamości do zasobów, takich jak maszyny wirtualne i usługi App Services, aby deweloperzy nie musieli zarządzać tożsamościami w aplikacji.

Podejście oddolne w celu zmniejszenia liczby usterek zabezpieczeń i wpływu na nie

image showing bottom-up approach to reduce security bug volume and impact

Zmniejsz liczbę i potencjalną ważność usterek zabezpieczeń w aplikacji, implementując praktyki zabezpieczeń i narzędzia podczas cyklu projektowania.

Usterki zabezpieczeń mogą spowodować ujawnienie poufnych danych przez aplikację, zezwolenie przestępcom na zmianę danych/rekordów lub niedostępności danych/aplikacji do użytku przez klientów i pracowników. Aplikacje zawsze będą mieć pewne błędy logiki, które mogą spowodować zagrożenie bezpieczeństwa, dlatego ważne jest, aby odkryć, ocenić i poprawić je, aby uniknąć szkód w reputacji, przychodach lub marżach organizacji. Rozwiązanie tych problemów jest łatwiejsze i tańsze we wcześniejszej części cyklu projektowania, niż jest korygowanie ich po zakończeniu testowania aplikacji, jest w użyciu w środowisku produkcyjnym lub zostało naruszone często nazywane "shift left" lub "push left" zasada.

Ograniczenie ryzyka związanego z aplikacją jest osiągane przez zintegrowanie praktyk zabezpieczeń i narzędzi w cyklu projektowania, często nazywanym bezpiecznym cyklem życia programowania (SDL lub SDLC). Firma Microsoft opublikowała szereg zaleceń w oficjalnym dokumencie zatytułowanym Develop Secure Apps on Azure based on Azure based on Microsoft's Security Development Lifecycle (Opracowywanie bezpiecznych aplikacji na platformie Azure na podstawie cyklu tworzenia zabezpieczeń firmy Microsoft) w celu ograniczenia typowych zagrożeń związanych z weryfikacją danych wejściowych i wyjściowych, przeprowadzania testowania rozmytego, przeglądów powierzchni ataków i nie tylko.

Podejście odgórne poprzez modelowanie zagrożeń

image showing top-down approach through threat modeling

Wykonaj modelowanie zagrożeń w aplikacjach krytycznych dla działania firmy, aby odkryć i ograniczyć potencjalne zagrożenia dla organizacji.

Modelowanie zagrożeń identyfikuje zagrożenia dla samej aplikacji, a także zagrożenia, które aplikacja może stanowić dla przedsiębiorstwa, szczególnie podczas oceniania poszczególnych aplikacji w większym systemie.

Modelowanie zagrożeń może być używane na dowolnym etapie tworzenia aplikacji lub produkcji, ale jest unikatowo skuteczne dla etapów projektowania nowych funkcji, ponieważ nie istnieją jeszcze żadne rzeczywiste dane dla tej aplikacji.

Ponieważ modelowanie zagrożeń to ćwiczenie intensywnie korzystające z umiejętności, zalecamy podjęcie działań w celu zminimalizowania inwestycji w czas przy jednoczesnym maksymalizacji wartości zabezpieczeń:

  1. Określanie priorytetów według ryzyka — najpierw zastosuj modelowanie zagrożeń do aplikacji o znaczeniu krytycznym dla działania firmy, które mogłyby mieć wpływ na firmę w przypadku naruszenia zabezpieczeń

  2. Zakres limitu — Wykonaj modelowanie zagrożeń na progresywnych etapach szczegółowości, aby szybko zidentyfikować szybkie zwycięstwa i środki zaradcze z możliwością działania, zanim wydasz dużo wysiłku ręcznego:

    1. Rozpocznij od prostej metody pytań (zobacz prostą metodę pytań) udokumentowaną poniżej, aby szybko uzyskać wgląd w zagrożenia i sprawdzić, czy są stosowane podstawowe zabezpieczenia

    2. Stopniowo oceniaj projekt aplikacji — w miarę dostępności zasobów i wiedzy przejdź do bardziej zaawansowanej analizy przy użyciu metody STRIDE Zaawansowane techniki modelowania zagrożeń lub innej podobnej już używanej przez twój zespół. Zacznij od projektu na poziomie architektury i stopniowo zwiększaj szczegóły w miarę zezwalania na czas i zasoby:

      1. Projektowanie na poziomie systemu — obejmuje aplikacje i sposób interakcji ze sobą

      2. Poziom aplikacji — obejmuje składniki aplikacji i sposób interakcji ze sobą

      3. Poziom składników — obejmuje sposób komponowania poszczególnych składników i interakcji poszczególnych elementów ze sobą

  3. Dopasowanie do cyklu życia programowania — Zoptymalizuj swoje wysiłki, dostosowując działania modelowania zagrożeń do cyklów życia tworzenia aplikacji.

    1. Kaskadowy — upewnij się, że główne projekty powinny uwzględniać modelowanie zagrożeń podczas procesu projektowania i podczas istotnych aktualizacji aplikacji.

    2. DevOps — wyzwalanie działań modelowania zagrożeń z częstotliwością, które zwiększa wartość zabezpieczeń bez nadmiernego obciążenia zespołów programistycznych. Dobre punkty integracji są w trakcie wprowadzania znaczących funkcji lub zmian w aplikacji oraz regularnego harmonogramu kalendarzy cyklicznych, na przykład co kwartał dla aplikacji krytycznych dla działania firmy.

    3. Starsze aplikacje — Te aplikacje zwykle nie mają pomocy technicznej, dostępu do kodu źródłowego i/lub wiedzy w organizacji, dlatego najlepiej wykonują modelowanie zagrożeń na podstawie posiadanej wiedzy/wiedzy dotyczącej aplikacji.

Prosta metoda pytań

Ta prosta metoda przesłuchania została zaprojektowana w celu rozpoczęcia modelowania zagrożeń przez specjalistów ds. zabezpieczeń i deweloperów przed przejściem do bardziej zaawansowanej metody, takiej jak STRIDE lub OWASP (zobacz podejście top-down poprzez modelowanie zagrożeń).

Dla każdej aplikacji lub składnika zadawaj i odpowiadaj na te pytania

  • Czy uwierzytelnianie połączeń jest możliwe przy użyciu usługi Azure AD, protokołu TLS (z uwierzytelnianiem wzajemnym) lub innego nowoczesnego protokołu zabezpieczeń zatwierdzonego przez zespół ds. zabezpieczeń? Chroni to przed nieautoryzowanym dostępem do aplikacji i danych

    • Między użytkownikami a aplikacją (jeśli dotyczy)

    • Między różnymi składnikami aplikacji i usługami (jeśli dotyczy)

  • Czy ograniczasz, które konta mają dostęp do zapisu lub modyfikowania danych w aplikacji tylko do tych, które są do tego wymagane? Zmniejsza to ryzyko nieautoryzowanego manipulowania/modyfikowania danych

  • Czy działanie aplikacji jest rejestrowane i przekazywane do zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM) za pośrednictwem usługi Azure Monitor lub podobnego rozwiązania? Pomaga to zespołowi ds. zabezpieczeń wykrywać ataki i szybko je badać.

  • Czy dane krytyczne dla działania firmy są chronione za pomocą szyfrowania zatwierdzonego przez zespół ds. zabezpieczeń? Pomaga to chronić przed nieautoryzowanym kopiowaniem danych przechowywanych.

  • Czy ruch sieciowy przychodzący i wychodzący jest szyfrowany przy użyciu protokołu TLS? Pomaga to chronić przed nieautoryzowanym kopiowaniem danych podczas przesyłania.

  • Czy aplikacja jest chroniona przed atakami DDoS (Distributed Denial of Service) przy użyciu usług, takich jak ochrona przed atakami DDoS, Akamai czy podobna? Chroni to przed atakami zaprojektowanymi pod kątem przeciążenia aplikacji, aby nie można było jej używać

  • Czy aplikacja przechowuje poświadczenia logowania lub klucze w celu uzyskania dostępu do innych aplikacji, baz danych lub usług? Pomaga to określić, czy atak może użyć aplikacji do ataku na inne systemy.

  • Czy mechanizmy kontroli aplikacji umożliwiają spełnienie wymagań dotyczących zabezpieczeń i prywatności dla lokalnych lokalizacji, w których działasz? (Pomaga to chronić dane prywatne użytkownika i unikać grzywny w zakresie zgodności)

Ważne: Bezpieczeństwo jest złożonym tematem, a potencjalne zagrożenia są ograniczone tylko przez wyobraźnię inteligentnych zmotywowanych atakujących. Te pytania mają na celu ułatwienie identyfikowania łatwo wykrywalnych luk, które można łatwo wykorzystać przez osoby atakujące. W miarę rozwoju komfortu i kompetencji przy użyciu tej metody możesz zwiększyć zdolność do modelowania zagrożeń, przechodząc do zaawansowanych technik modelowania zagrożeń.

Zaawansowane techniki modelowania zagrożeń

Bardziej kompleksowy model zagrożeń może identyfikować więcej potencjalnych zagrożeń. Dwie popularne techniki to STRIDE i OWASP

  • Microsoft Cykl projektowania zabezpieczeń udokumentował proces modelowania zagrożeń w systemie i wydał bezpłatne narzędzie ułatwiające ten proces

    • Ta metoda ocenia składniki aplikacji i połączenia/relacje z potencjalnymi zagrożeniami, które są mapowe na mnemonic STRIDE:

      • Spoofing (fałszowanie)

      • Tampering (manipulowanie)

      • Repudiation (wypieranie się)

      • Information Disclosure (ujawnienie informacji)

      • Denial of Service (odmowa usługi)

      • Podniesienie uprawnień

    • Tę metodę można zastosować do dowolnego poziomu projektu z poziomu składników aplikacji specyficznych dla architektury wysokiego poziomu.

  • OWASP – Projekt Open Web Application Security Project (OWASP) udokumentował podejście do modelowania zagrożeń dla aplikacji, które odnosi się do metody STRIDE i innych metod https://www.owasp.org/index.php/Application_Threat_Modeling

Korzystanie z zapór aplikacji internetowych

Zapory aplikacji internetowych (WAFs) ograniczają ryzyko wykorzystania przez osobę atakującą często spotykanych luk w zabezpieczeniach aplikacji. Chociaż nie jest doskonały, funkcje WAFs zapewniają podstawowy minimalny poziom zabezpieczeń dla aplikacji internetowych.

Funkcje WAFs są ważnym ograniczeniem ryzyka, ponieważ osoby atakujące kierują aplikacje internetowe do punktu przychodzącego do organizacji podobnej do punktu końcowego klienta. Funkcje WAFs są odpowiednie dla obu

  • Organizacje bez silnego programu zabezpieczeń aplikacji, ponieważ jest to krytyczny środek bezpieczeństwa (podobnie jak spadochron w samolocie. Należy pamiętać, że nie powinien to być jedyny planowany mechanizm bezpieczeństwa, aby zmniejszyć ilość i ważność usterek zabezpieczeń w aplikacjach. Aby uzyskać szczegółowe informacje, zobacz Zmniejszenie liczby usterek zabezpieczeń i ich wpływu.

  • Organizacje, które zainwestowały w zabezpieczenia aplikacji jako funkcje WAFs, zapewniają cenną dodatkową ochronę w głębi systemu. W tym przypadku systemy WAF działają jako ostateczny mechanizm bezpieczeństwa w przypadku, gdy usterka zabezpieczeń została pominięta przez praktyki zabezpieczeń w cyklu projektowania.

Firma Microsoft oferuje funkcje zapory aplikacji internetowej w usłudze Azure Application Gateway , a wielu dostawców oferuje te możliwości jako autonomiczne urządzenia zabezpieczeń lub jako część zapór nowej generacji.

Postępuj zgodnie z najlepszymi rozwiązaniami dotyczącymi zabezpieczeń kontenerów

Aplikacje hostowane w kontenerach powinny być zgodne z ogólnymi najlepszymi rozwiązaniami dotyczącymi aplikacji, a także określonymi wytycznymi dotyczącymi zarządzania tym nowym typem architektury aplikacji

Konteneryzowane aplikacje mają takie same zagrożenia jak każda aplikacja, a także dodaje nowe wymagania w celu bezpiecznego hostowania i zarządzania konteneryzowanymi aplikacjami.

Architektury kontenerów aplikacji wprowadziły nową warstwę narzędzi abstrakcji i zarządzania (zazwyczaj Kubernetes), które zwiększyły produktywność deweloperów i wdrożły zasady Metodyki DevOps.

Chociaż jest to nowa przestrzeń, która szybko ewoluuje, kilka kluczowych wniosków i najlepszych rozwiązań stało się jasne:

  • Używanie usługi zarządzanej Kubernetes zamiast instalowania platformy Kubernetes i zarządzania nią
    Platforma Kubernetes jest bardzo złożonym systemem i nadal ma wiele ustawień domyślnych, które nie są bezpieczne i niewielu ekspertów ds. zabezpieczeń platformy Kubernetes na platformie handlowej. Chociaż w ostatnich latach poprawia się to wraz z poszczególnymi wersjami, nadal istnieje wiele zagrożeń, które muszą zostać złagodzone.

  • Weryfikowanie łańcucha dostaw kontenera i kontenera
    Tak jak należy zweryfikować zabezpieczenia dowolnego kodu open source dodanego do aplikacji, należy również zweryfikować kontenery dodawane do aplikacji.

    • Upewnij się, że praktyki stosowane do tworzenia kontenera są weryfikowane pod kątem standardów zabezpieczeń, takich jak stosowanie aktualizacji zabezpieczeń, skanowanie pod kątem niechcianych kodów, takich jak backdoors i nielegalnych górników monet kryptograficznych, skanowanie pod kątem luk w zabezpieczeniach i stosowanie bezpiecznych praktyk programistycznych.

    • Regularnie skanuj kontenery pod kątem znanych zagrożeń w rejestrze kontenerów, przed użyciem lub podczas ich używania.

  • Konfigurowanie rejestru znanych dobrych kontenerów
    Dzięki temu deweloperzy w organizacji mogą szybko korzystać z kontenerów zweryfikowanych przez zabezpieczenia z niskimi tarciami. Ponadto utwórz proces, aby deweloper zażądał i szybko uzyskać weryfikację zabezpieczeń nowych kontenerów, aby zachęcić deweloperów do korzystania z tego procesu w porównaniu z jego obejściem.

  • Nie uruchamiaj kontenerów jako użytkownik główny lub administrator, chyba że jest to wymagane jawnie
    Wczesne wersje kontenerów wymagały uprawnień administratora (co ułatwia ataki), ale nie jest to już wymagane w przypadku bieżących wersji.

  • Monitorowanie kontenerów
    Upewnij się, że wdrażasz narzędzia do monitorowania zabezpieczeń, które są świadome kontenerów, aby monitorować nietypowe zachowanie i włączyć badanie zdarzeń.

Następne kroki

Aby uzyskać dodatkowe wskazówki dotyczące zabezpieczeń firmy Microsoft, zobacz dokumentację zabezpieczeń firmy Microsoft.