Strategie architektury na potrzeby testowania zabezpieczeń

Dotyczy tego zalecenia listy kontrolnej dotyczącej zabezpieczeń platformy Azure Well-Architected Framework:

SE:11 Ustanów schemat testowania, który łączy podejścia w celu zapobiegania problemom z zabezpieczeniami, weryfikowaniu implementacji zapobiegania zagrożeniom i testowaniu mechanizmów wykrywania zagrożeń.

Rygorystyczne testowanie jest podstawą dobrego projektu zabezpieczeń. Testowanie to również proaktywny sposób wykrywania luk w zabezpieczeniach w systemie.

Zapewnij dokładność testowania poprzez regularność i weryfikację z różnych perspektyw. Uwzględnij perspektywy od wewnątrz, które testują platformę i infrastrukturę, oraz oceny z zewnątrz, które testują system tak, jak zrobiłby to atakujący z zewnątrz.

Kluczowe strategie przedstawione w tym artykule opierają się na podstawowych rozwiązaniach testowania opisanych w temacie Strategie architektury OE:09 na potrzeby testowania. Najpierw zapoznaj się z tym artykułem. Ten przewodnik zawiera zalecenia dotyczące testowania stanu zabezpieczeń obciążenia roboczego. Zaimplementuj te metody testowania, aby zwiększyć odporność obciążenia na ataki i zachować poufność, integralność i dostępność zasobów.

Terminology

Termin Definicja
Testowanie zabezpieczeń aplikacji (AST) Technika cyklu projektowania zabezpieczeń firmy Microsoft (SDL), która używa metodologii testowania białych i czarnych ramek w celu sprawdzenia luk w zabezpieczeniach w kodzie.
Testowanie metodą czarnej skrzynki (black-box) Metodologia testowania, która weryfikuje zewnętrznie widoczne zachowanie aplikacji bez znajomości wewnętrznych elementów systemu.
Testowanie białej skrzynki Metodologia testowania, w której struktura kodu jest znana praktykowi.
Czerwony zespół Zespół, który odgrywa rolę przeciwnika i próbuje zhakować system w ćwiczeniu gry wojennej.
Niebieski zespół Zespół, który broni przed atakami czerwonej drużyny w ćwiczeniu gry wojennej.
Testy penetracyjne Metodologia testowania, która wykorzystuje etyczne techniki hakerskie w celu zweryfikowania ochrony przed zabezpieczeniami systemu.
Cykl życia tworzenia zabezpieczeń (SDL) Zestaw rozwiązań oferowanych przez firmę Microsoft, który obsługuje wymagania dotyczące zapewniania zabezpieczeń i zgodności.

Współpraca z ekspertami ds. zabezpieczeń w celu projektowania testów

Zaangażuj się w planowanie testów. Często organizacja centralizuje to zadanie. Upewnij się, że twój zespół jest zaangażowany w ten proces projektowania, aby zapewnić bezpieczeństwo zgodne z funkcjonalnością aplikacji.

Przyjmij sposób myślenia zakładający naruszenie zabezpieczeń. Zaprojektuj przypadki testowe przy założeniu, że system jest atakowany, a osoba atakująca działa w środowisku. Symuluj testy tak, aby odzwierciedlały realistyczne scenariusze ataków, takie jak weryfikacja powstrzymywania ruchu bocznego w naruszonej maszynie wirtualnej aplikacji. Dzięki temu można wykryć potencjalne luki w zabezpieczeniach i odpowiednio określić priorytety testów.

Udostępnij diagramy architektoniczne, model zagrożeń i inną odpowiednią dokumentację, aby znacząco przetestować obciążenie.

Określanie priorytetów testów na podstawie modelowania zagrożeń i przepływów krytycznych

Modelowanie zagrożeń to kluczowa praktyka służąca do identyfikowania potencjalnych zagrożeń i luk w zabezpieczeniach w obciążeniu roboczym. Użyj ocen ważności z modelu zagrożeń, aby określić priorytety i określić zakres działań testowych. Najpoważniejsze zagrożenia dla najbardziej krytycznych przepływów zasługują na najszerszą ochronę.

Zabezpiecz całą powierzchnię ataku obciążenia roboczego. Oceń tożsamość, kod aplikacji, mechanizmy kontroli infrastruktury, składniki innych firm, biblioteki i usługi oraz zautomatyzowane i ludzkie procesy, takie jak przepływy pracy zatwierdzania i przeglądy dostępu.

Zacznij od kontroli tożsamości i dostępu, ponieważ naruszona tożsamość pomija większość ochrony podrzędnej. Następnie zweryfikuj granice sieci i na koniec zabezpieczenia warstwy aplikacji.

Określanie priorytetów przepływów obsługujących uwierzytelnianie, poufne dane lub transakcje finansowe. Dla każdego przepływu krytycznego zidentyfikuj zagrożenia o najwyższej ważności w modelu zagrożeń. Utwórz oparte na ryzyku przypadki testowe, które przyporządkowują każde zagrożenie do mechanizmu kontrolnego przeznaczonego do jego ograniczenia.

Dobre ćwiczenie modelowania zagrożeń wskazuje kluczowe obszary pokrycia i częstotliwości testów. Aby uzyskać zalecenia dotyczące modelowania zagrożeń, zobacz Zalecenia dotyczące zabezpieczania cyklu projektowania.

Ryzyko: Nieaktualne modele zagrożeń mogą prowadzić do niewłaściwie ukierunkowanych działań testowych. Regularne aktualizowanie modelu zagrożeń w celu odzwierciedlenia zmian obciążenia i zmieniającego się krajobrazu zagrożeń.

Skorzystaj z wiedzy innych firm

Zespoły wewnętrzne mogą nie dostrzegać pewnych kwestii. Zewnętrzni eksperci i badacze crowdsourcingowi widzą Twoje środowisko tak, jak widzi je atakujący. Zaangażuj wyspecjalizowanych ekspertów, aby przetestowali Twoje obciążenie robocze z perspektywy przeciwnika i dostarczyli informacji o najnowszych technikach i trendach w zakresie ataków.

Unikaj przyznawania swojemu obciążeniu roboczemu zbyt szerokich uprawnień dostępu. Przyznaj zewnętrznym testerom tylko taki dostęp, jakiego wymaga ich konkretne zadanie. Test penetracyjny typu black-box nie wymaga kodu ani dostępu wewnętrznego, podczas gdy przegląd typu white-box wymaga kodu źródłowego, dokumentów projektowych lub logów.

Przed uruchomieniem programu należy ocenić, czy zespół ma możliwość klasyfikacji raportów zewnętrznych. Następnie ustanów program nagród za zgłaszanie błędów lub mechanizm umożliwiający społeczności zgłaszanie luk w zabezpieczeniach. Przeanalizuj każde zgłoszone ustalenie, uwzględnij potwierdzone podatności ponownie w modelu zagrożeń i dodaj przypadek testowy, aby wykrywać ewentualne regresje.

Testowanie kontroli zgodności i generowanie dowodów gotowych do inspekcji

Zgodność nie jest jednorazowym przeglądem. Traktuj każdą kontrolę przepisów jako wymaganie z możliwością testowania, dzięki czemu zawsze masz nowe dowody dla audytorów.

Określ przepisy, które musi spełniać obciążenie robocze. Przypisz każdy mechanizm kontrolny do konkretnego przypadku testowego. Zaplanuj testy tak, aby były uruchamiane cyklicznie oraz przed każdym wdrożeniem produkcyjnym. Zapisz dane wyjściowe testu w lokalizacji z możliwością inspekcji, aby można było wygenerować dowody na żądanie.

Kompromis: Testy kontroli regulacyjnej mogą spowalniać operacje. Na przykład testy przed wdrożeniem zwiększają opóźnienie potoku przetwarzania. Istnieje również dodatkowy koszt uruchamiania tych operacji. Nadaj priorytet testom mechanizmów kontrolnych o największym wpływie na audyt i ryzyko.

Ryzyko: Dowody inspekcji są same w sobie wrażliwe. Bez ochrony integralności i rejestrowania dostępu magazyn dowodów staje się celem ataku i potencjalnym naruszeniem zgodności.

Ochrona zasobów testowych

Zasoby testowe same stanowią powierzchnię ataku. Chroń ich poufność, integralność i dostępność, aby testowanie nie ujawniało poufnych informacji ani nie otwierało nowych wektorów ataków.

  • Użyj oczyszczonych lub syntetycznych danych, które nie zawierają danych osobowych ani danych produkcyjnych.
  • Zachowaj dane testowe tylko tak długo, jak to konieczne i bezpiecznie je usuń.
  • Upewnij się, że reguły rezydencji danych transgranicznych są wymuszane w środowiskach testowych obejmujących regiony.
  • Generowanie dedykowanych poświadczeń testowych, kluczy interfejsu API i certyfikatów. Przechowuj je w oddzielnym magazynie kluczy z własnymi zasadami dostępu.
  • Skonfiguruj izolowane środowiska testowe, które odzwierciedlają produkcyjne mechanizmy zabezpieczeń, takie jak sieciowe grupy zabezpieczeń (NSG), zasady kontroli dostępu opartej na rolach (RBAC), zapora sieciowa oraz reguły ochrony przed utratą danych (DLP). Zastosuj te same wskazówki dotyczące segmentacji co produkcja. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące strategii segmentacji.

Przeprowadzanie regularnych skanowania luk w zabezpieczeniach na zasobach testowych

Skanuj zasoby testowe pod kątem luk w zabezpieczeniach z taką samą częstotliwością jak zasoby produkcyjne, w tym kod testowy, infrastrukturę jako kod (IaC), obrazy kontenerów i maszyn wirtualnych, repozytoria oraz potoki. Użyj narzędzi, które integrują się z przepływami pracy programowania i wdrażania, aby zautomatyzować te testy.

Ustal rytm ciągłego testowania obciążenia roboczego

Traktuj testowanie zabezpieczeń jako ciągłą aktywność, która utrzymuje stan zabezpieczeń obciążenia w miarę rozwoju zagrożeń, kodu i konfiguracji obciążenia. Uruchamianie testów zgodnie z harmonogramem, aby zmiany nie wprowadzały zagrożeń bezpieczeństwa ani regresji. Przygotuj się do weryfikacji zabezpieczeń organizacji, które mogą wystąpić w dowolnym momencie, oraz testów wyzwalanych przez zdarzenie zabezpieczeń. W poniższych sekcjach opisano cykle, które należy uwzględnić w planowaniu.

Testy rutynowe

Rutynowe testy wyznaczają poziom odniesienia dla poziomu bezpieczeństwa obciążenia roboczego. Przeprowadzaj je w regularnym tempie w ramach standardowych procedur operacyjnych i w celu spełnienia wymagań dotyczących zgodności. Możesz przeprowadzać różne testy z różną częstotliwością, ale najważniejsze jest, aby robić to regularnie i zgodnie z harmonogramem.

Zdywersyfikuj zestaw testów, aby zweryfikować zabezpieczenia tożsamości, magazynu danych i transmisji oraz kanałów komunikacyjnych. W miarę odnajdowania nowych problemów w tych samych punktach cyklu życia dodaj nowe przypadki testowe.

Nie polegaj tylko na testach automatycznych. Stosuj testy ręczne, aby wykrywać podatności, które może wykryć tylko człowiek dzięki swojej wiedzy specjalistycznej, oraz do eksploracyjnego badania nieznanych zagrożeń.

Improwizowane testy

Improwizowane testy zapewniają walidację zabezpieczeń w określonym momencie. Alerty zabezpieczeń, które mogą wpływać na obciążenie w tym czasie, wyzwalają te testy. Mandaty organizacyjne mogą wymagać wstrzymywania i testowania sposobu myślenia w celu zweryfikowania skuteczności strategii obrony, jeśli alert będzie eskalowany w nagłych wypadkach.

Korzyścią z improwizowanych testów jest gotowość do rzeczywistego incydentu. Te testy mogą być funkcją wymuszania wykonywania testów akceptacyjnych użytkowników (UAT).

Zespół ds. zabezpieczeń może przeprowadzać inspekcję wszystkich obciążeń i uruchamiać te testy zgodnie z potrzebami. Jako właściciel obciążenia musisz umożliwić współpracę z zespołami zajmującymi się bezpieczeństwem. Negocjuj wystarczająco dużo czasu realizacji z zespołami ds. zabezpieczeń, aby można było przygotować się. Potwierdź i przekaż swojemu zespołowi i uczestnikom projektu, że te zakłócenia są niezbędne.

W innych przypadkach może być wymagane uruchomienie testów i zgłoszenie stanu zabezpieczeń systemu przed potencjalnym zagrożeniem.

Kompromis: Ponieważ testy ad hoc zakłócają pracę, należy się spodziewać konieczności zmiany priorytetów zadań, co może opóźnić inne zaplanowane prace.

Ryzyko: Istnieje ryzyko nieznanego. Improwizowane testy mogą być jednorazowe bez ustalonych procesów lub narzędzi. Jednak dominującym ryzykiem jest potencjalna przerwa w rytmie działalności. Oceń te czynniki ryzyka w stosunku do korzyści.

Testy zdarzeń zabezpieczeń

Użyj testów, które wykrywają przyczynę incydentu bezpieczeństwa u źródła. Rozwiąż te luki w zabezpieczeniach, aby zapobiec cyklicznemu zdarzeniu.

Zdarzenia również poprawiają przypadki testowe z czasem, ujawniając istniejące luki. Zespół powinien zastosować wnioski wyciągnięte ze zdarzenia i rutynowo wprowadzać ulepszenia.

Uwaga / Notatka

Te wskazówki odróżniają testy i reagowanie na zdarzenia. Mimo że testowanie jest mechanizmem wykrywania, który idealnie rozwiązuje problemy przed produkcją, nie należy mylić go z korygowaniem ani badaniem wykonywanym w ramach reagowania na zdarzenia. Aspekt odzyskiwania po zdarzeniach zabezpieczeń został opisany w temacie Zalecenia dotyczące reagowania na zdarzenia.

Weryfikowanie mechanizmów kontroli zabezpieczeń na powierzchni ataków

Skorzystaj z różnych metodologii testowania, aby uzyskać pełne pokrycie i odkryć luki w mechanizmach kontroli zabezpieczeń, błędnych konfiguracji i słabych stronach w obserwowaniu i wykrywaniu. Większość testów opisanych w tej sekcji może być uruchamiana jako rutynowe testy. Jednak powtarzalność może spowodować koszty i spowodować zakłócenia. Należy dokładnie rozważyć te kompromisy.

Testowanie kontrolek szyfrowania. Błędy szyfrowania są dyskretne. Dane wyglądają na chronione, dopóki naruszenie nie zostanie ujawnione w inny sposób.

  • Sprawdź, czy szyfrowanie jest wymuszane, a nie tylko skonfigurowane.
  • Ponownie przetestuj po każdej rotacji kluczy, odnowieniu certyfikatu i zmianie infrastruktury.

Testowanie kontrolek sieci. Granice sieci to miejsce, w którym jest wymuszana segmentacja.

  • Przetestuj je po zmianie topologii sieci.
  • Sprawdź, czy reguły domyślnej odmowy obowiązują oraz czy dozwolone ścieżki ruchu są zgodne z założeniami architektury.

Testowanie kodu aplikacji. Zabezpieczenia warstwy aplikacji są ostatnią granicą, zanim osoba atakująca osiągnie dane.

  • Sprawdź, czy wdrożone aplikacje są odporne na typowe wzorce ataków, a nie tylko skanowanie kodu źródłowego w czasie kompilacji.
  • Uruchom techniki testowania zabezpieczeń aplikacji (AST) w kodzie źródłowym, aby potwierdzić bezpieczne praktyki kodowania i przechwycić błędy środowiska uruchomieniowego, takie jak uszkodzenie pamięci i problemy z uprawnieniami. Aby uzyskać szczegółowe informacje, zobacz Linki społeczności.

Symulowanie ataków opartych na tożsamościach i weryfikowanie wykrywania

Ataki oparte na tożsamościach są najczęstszym wektorem ataku początkowego. Zasymuluj te ataki, aby sprawdzić, czy mechanizmy kontroli tożsamości działają i czy monitorowanie przechwytuje zdarzenia.

Kontrola dostępu jest pierwszą linią obrony. Przetestuj je po każdej zmianie roli lub zasad i zgodnie z automatycznym harmonogramem. Symuluj typowe wzorce ataków i upewnij się, że kontrolki wymuszają najmniejsze uprawnienia i sprzeciwiają się próbom obejścia.

Podczas projektowania testów należy wziąć pod uwagę te wzorce ataków:

  • Obejście autoryzacji
  • Kradzież tokenu i powtórka
  • Ruch lateralny między kontami lub usługami
  • Eskalacja uprawnień

Zweryfikuj obie strony każdej kontrolki:

  • Przypadki pozytywne: autoryzowani użytkownicy odnoszą sukces.
  • Negatywne przypadki: nieautoryzowane próby są blokowane i rejestrowane.

Testowanie wykrywania zagrożeń i zgłaszania alertów

Wykrywanie, które nie wyzwala alertu, zapewnia niewielką wartość. Przetestuj monitorowanie i alerty w ramach każdej weryfikacji kontroli zabezpieczeń i sprawdź, czy mechanizmy przeznaczone do wykrywania ataków działają zgodnie z oczekiwaniami.

Przeprowadź pełne symulacje ataków, a następnie potwierdź każdy etap procesu wykrywania:

  • Sprawdź, czy zdarzenia zabezpieczeń, takie jak próby logowania, zmiany uprawnień i operacje tokenu, są rejestrowane z wystarczającą ilością szczegółów.
  • Sprawdź, czy platforma zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM) lub pulpit nawigacyjny operacji zabezpieczeń korelują powiązane zdarzenia.
  • Ustanów umowę SLA dla alertów i przetestuj, czy alerty wymagają podjęcia działania i pojawiają się w określonym czasie.
  • Sprawdź, czy dzienniki nie mogą być modyfikowane ani usuwane przez konta inne niż administracyjne.
  • Potwierdź, że mechanizm wykrywania uruchamia się dla każdego symulowanego ataku. Jeśli na przykład zasymulujesz atak typu "rozproszona odmowa usługi" (DDoS) z prawidłowymi wzorcami ruchu, upewnij się, że ograniczenie szybkości wykrywa i ogranicza je.

W przypadku dojrzałych obciążeń zweryfikuj zabezpieczenia ładu jako rutynowe testy. Celowo wprowadzaj niebezpieczne konfiguracje i sprawdź, czy potok przetwarzania je wykrywa i odpowiednio na nie reaguje. Upewnij się, że ograniczenia Azure Policy lub strefy docelowej wymuszają oczekiwane zabezpieczenia. Zespół ds. platformy lub zabezpieczeń zwykle wykonuje te testy, a nie zespół ds. obciążeń.

Wzmacnianie ochrony przy użyciu testów opartych na przeciwnikach

Użyj testów, które umożliwiają wyszukiwanie zagrożeń przez symulowanie rzeczywistych ataków. Te testy mogą identyfikować potencjalne podmioty zagrożeń, ich techniki i luki w zabezpieczeniach, które stanowią zagrożenie dla obciążenia. Uczyń ataki jak najbardziej realistycznymi. Użyj wszystkich potencjalnych wektorów zagrożeń, które można zidentyfikować podczas modelowania zagrożeń.

Oto kilka zalet testowania za pomocą rzeczywistych ataków:

  • Gdy te ataki są częścią rutynowego testowania, należy użyć perspektywy zewnętrznej, aby sprawdzić obciążenie i upewnić się, że obrona może wytrzymać atak.
  • Na podstawie lekcji, które uczą się, zespół uaktualnia swoją wiedzę i poziom umiejętności. Zespół zwiększa świadomość sytuacyjną i może samodzielnie ocenić gotowość do reagowania na zdarzenia.

Ryzyko: Testowanie ogólnie może mieć wpływ na wydajność. Testy destrukcyjne mogą usuwać lub uszkodzić dane i powodować problemy z ciągłością działania. Istnieją również zagrożenia związane z ujawnieniem informacji. Zachowaj poufność danych. Upewnij się, że po zakończeniu testowania została zachowana integralność danych.

Niektóre przykłady symulowanych testów obejmują testy black-box i white-box, testy penetracyjne i ćwiczenia wojenne.

Testy Black-box i White-box

Te typy testów oferują dwie różne perspektywy. W testach czarnej skrzynki wnętrze systemu nie jest widoczne. W testach białoskrzynkowych tester dobrze rozumie aplikację, a nawet ma dostęp do kodu, dzienników, topologii zasobów i konfiguracji, aby przeprowadzić eksperyment.

Ryzyko: Różnica między dwoma typami jest kosztem początkowym. Testowanie białych pól może być kosztowne pod względem czasu potrzebnego do zrozumienia systemu. W niektórych przypadkach testowanie white-box wymaga zakupu specjalistycznych narzędzi. Testowanie czarnoskrzynkowe nie wymaga czasu wdrożenia, ale może nie być tak skuteczne. Może być konieczne wprowadzenie dodatkowych starań, aby odkryć problemy. To decyzja o poświęceniu czasu na inwestycję.

Testy, które symulują ataki za pośrednictwem testów penetracyjnych

Eksperci ds. zabezpieczeń, którzy nie należą do zespołów IT lub aplikacji organizacji, przeprowadzają testy penetracyjne lub pentestowanie. Przyglądają się systemowi w taki sposób, w jaki złośliwi aktorzy określają obszar ataków. Ich celem jest znalezienie luk w zabezpieczeniach dzięki zbieraniu informacji, analizowaniu luk w zabezpieczeniach i raportowaniu wyników.

Kompromis: Testy penetracyjne są dostosowywane i mogą być kosztowne pod względem zakłóceń oraz inwestycji finansowych, ponieważ pentesting jest zazwyczaj płatną ofertą wykonywaną przez zewnętrznych specjalistów.

Ryzyko: Testy penetracyjne mogą wpływać na środowisko uruchomieniowe i zakłócać dostępność dla normalnego ruchu.

Praktycy mogą potrzebować dostępu do poufnych danych w całej organizacji. Postępuj zgodnie z zasadami postępowania, aby upewnić się, że dostęp nie będzie nadużywany. Zapoznaj się z zasobami wymienionymi w linkach pokrewnych.

Testy, które symulują ataki za pomocą ćwiczeń gry wojennej

W tej metodologii symulowanych ataków uczestniczą dwa zespoły:

  • Czerwony zespół działa jako przeciwnik i próbuje modelować rzeczywiste ataki. Jeśli się im uda, znajdziesz luki w projekcie zabezpieczeń i ocenisz ograniczenie zasięgu ich naruszeń.

  • niebieski zespół jest drużyną zadaniową, która broni przed atakami. Testują swoją zdolność do wykrywania, reagowania i korygowania ataków. Weryfikują zabezpieczenia chroniące zasoby obciążeń.

Jeśli przeprowadzasz te testy rutynowo, ćwiczenia gry wojennej mogą zapewnić ciągłą widoczność i pewność, że obrona działa zgodnie z projektem. Ćwiczenia gry wojennej mogą potencjalnie testować na różnych poziomach w ramach obciążeń.

Popularnym wyborem do symulowania realistycznych scenariuszy ataku jest szkolenie symulacji ataku w usłudze Microsoft Defender dla usługi Office 365.

Aby uzyskać więcej informacji, zobacz Szczegółowe informacje i raporty dotyczące trenowania symulacji ataku.

Aby uzyskać informacje na temat konfiguracji red-team i blue-team, zobacz Microsoft Cloud Red Teaming.

Ułatwienia platformy Azure

Microsoft Sentinel to natywna kontrolka, która łączy funkcje zarządzania zdarzeniami zabezpieczeń (SIEM) i automatycznego reagowania na zdarzenia zabezpieczeń (SOAR). Analizuje zdarzenia i dzienniki z różnych połączonych źródeł. Na podstawie źródeł danych i ich alertów usługa Microsoft Sentinel tworzy zdarzenia i przeprowadza analizę zagrożeń na potrzeby wczesnego wykrywania. Dzięki inteligentnej analizie i zapytaniom można aktywnie polować na problemy z zabezpieczeniami. Jeśli wystąpi zdarzenie, możesz zautomatyzować przepływy pracy. Ponadto przy użyciu szablonów skoroszytów można szybko uzyskać szczegółowe informacje za pomocą wizualizacji.

Aby uzyskać dokumentację produktu, zobacz stronę Możliwość polowania na zagrożenia w usłudze Microsoft Sentinel.

Usługa Microsoft Defender dla Chmury oferuje skanowanie luk w zabezpieczeniach dla różnych obszarów technologii. Aby uzyskać szczegółowe informacje, zobacz Włączanie skanowania luk w zabezpieczeniach za pomocą usługi Zarządzanie lukami w zabezpieczeniach w usłudze Microsoft Defender — Microsoft Defender dla Chmury.

Praktyka metodyki DevSecOps integruje testowanie zabezpieczeń w ramach ciągłego i ciągłego myślenia o ulepszaniu. Ćwiczenia gry wojennej to powszechna praktyka zintegrowana z rytmem działalności firmy Microsoft. Aby uzyskać więcej informacji, zobacz Zabezpieczenia w metodyce DevOps (DevSecOps).

Azure DevOps obsługuje narzędzia innych firm, które można zautomatyzować w ramach potoków ciągłej integracji/ciągłego wdrażania. Aby uzyskać szczegółowe informacje, zobacz Włączanie usługi DevSecOps za pomocą platformy Azure i usługi GitHub — Azure DevOps.

Postępuj zgodnie z zasadami współpracy, aby upewnić się, że dostęp nie jest nadużywany. Aby uzyskać wskazówki dotyczące planowania i wykonywania symulowanych ataków, zobacz następujące artykuły:

Możesz symulować ataki typu "odmowa usługi" (DoS) na platformie Azure. Pamiętaj, aby postępować zgodnie z zasadami określonymi w artykule Testowanie symulacji usługi Azure DDoS Protection.

Testowanie zabezpieczeń aplikacji: Narzędzia, typy i najlepsze rozwiązania — zasoby usługi GitHub opisują typy metodologii testowania, które mogą testować ochronę aplikacji w czasie kompilacji i czasie wykonywania.

Standard wykonywania testów penetracyjnych (PTES) zawiera wskazówki dotyczące typowych scenariuszy i działań wymaganych do ustanowienia punktu odniesienia.

OWASP Top Ten | OWASP Foundation zapewnia najlepsze rozwiązania w zakresie zabezpieczeń dla aplikacji i przypadków testowych, które obejmują typowe zagrożenia.

Lista kontrolna zabezpieczeń

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna zabezpieczeń

  • Last updated on