# Praktyczny model zagrożeń dla Twojego hostowanego projektu | SwissOctet Insights https://swissoctet.com/pl/insights/threat-model-a-hosted-project/ SwissOctet / Spostrzeżenia / Operacje dnia drugiego Operacje dnia drugiego Zastosowane · 6 min czytania Praktyczny model zagrożeń dla hostowanego projektu Zmapuj zasoby i granice zaufania, wybierz kilka realistycznych scenariuszy awarii i przekształć je w mechanizmy kontrolne, które możesz przetestować. Autor: SwissOctet Editorial Zapisz przewodnik Kopiuj link NA TEJ STRONIE 01 Zdefiniuj zakres wystarczająco mały, by można było o nim rozumować 02 Narysuj miejsca, w których zmienia się zaufanie 03 Wybierz konkretne scenariusze awarii 04 Ustal priorytety według wpływu i wiarygodnej ścieżki 05 Przetestuj kontrole w autoryzowanym środowisku 06 Utrzymuj model w powiązaniu ze zmianami Twoja praktyczna lista kontrolna Źródła i dalsza lektura Powrót do biblioteki BEZPOŚREDNIA ODPOWIEDŹ Użyteczny model zagrożeń wyjaśnia, co chronisz, kto lub co może na to wpływać, gdzie zmienia się zaufanie oraz jak ograniczysz i przetestujesz najważniejsze ryzyka. Zacznij od rzeczywistego projektu, a nie od ogólnej listy narzędzi. 01 Zdefiniuj zakres wystarczająco mały, by można było o nim rozumować Zacznij od jednej działającej usługi: portalu klienta, serwisu publikacyjnego lub aplikacji wewnętrznej. Zapisz komponenty, którymi zarządzasz, i systemy zewnętrzne, od których zależysz. Model zagrożeń powinien uwidaczniać założenia, a nie sugerować, że rozwiązano każdy możliwy atak. Utrzymaj pierwszą wersję na tyle małą, by osoby wdrażające aplikację mogły ją wyjaśnić bez osobnego konsultanta interpretującego diagram. Wymień cenne rezultaty i zasoby. Mogą one obejmować dane klientów, dostęp administracyjny, stan płatności, publikowane treści i możliwość przywrócenia usługi. Dostępność może być zasobem, nawet gdy informacje są publiczne. Zdecyduj, które awarie byłyby uciążliwe, a które zaszkodziłyby ludziom lub organizacji. To rozróżnienie pomaga ustalić priorytety kontroli, zamiast traktować każde ostrzeżenie jednakowo. 02 Narysuj miejsca, w których zmienia się zaufanie Wytyczne OWASP dotyczące modelowania zagrożeń wykorzystują przepływy danych i granice zaufania, aby uczynić projekt zrozumiałym. W przypadku małej hostowanej aplikacji narysuj przeglądarkę, proces webowy, bazę danych, administratora, miejsce docelowe kopii zapasowych i integracje zewnętrzne. Zaznacz informacje przemieszczające się między nimi. Żądanie przechodzące od niezaufanego klienta do uprzywilejowanej operacji serwera zasługuje na wyraźną walidację i autoryzację. Nie zakładaj, że samo znajdowanie się na tej samej maszynie czyni każdy komponent równie zaufanym. Publiczny proces przesyłania plików nie powinien mieć tych samych uprawnień co administracja bazą danych. Zadanie tworzenia kopii zapasowej może potrzebować dostępu do odczytu bez możliwości modyfikowania aktywnych rekordów aplikacji. Rozdzielenie tych ról ułatwia ograniczenie skutków przejęcia komponentu i przegląd wymaganych uprawnień. 03 Wybierz konkretne scenariusze awarii Użyj kilku prawdopodobnych zdarzeń, aby zakwestionować projekt. Atakujący kradnie hasło administratora; użytkownik żąda rekordu innego użytkownika; przesłany plik zapełnia dysk; wdrożenie ujawnia plik konfiguracyjny; kopia odzyskiwania nie daje się odtworzyć. Opisz warunek początkowy, dotknięty komponent i konsekwencję. Konkretny scenariusz łatwiej przetestować niż ogólną instrukcję poprawy bezpieczeństwa. Uwzględnij błędy i nadużycia zgodnych z przepisami procesów, a także wtargnięcie z zewnątrz. Ponowna próba może utworzyć dwie wartościowe operacje albo dwa żądania mogą wyścignąć się o zmianę tego samego obiektu. Wytyczne OWASP dotyczące logiki biznesowej podkreślają te założenia procesu. Sprawdź, kto może przenieść proces do następnego stanu i czy powtórzenie lub zmiana kolejności żądania nieoczekiwanie zmienia wynik. Scenariusz Kontrola do zbadania Dowody do zebrania Skradzione dane uwierzytelniające administratora Ograniczony dostęp i drugi czynnik, jeśli jest obsługiwany Nieautoryzowane logowanie nie może się zakończyć Zażądano obiektu innego użytkownika Autoryzacja obiektu po stronie serwera Izolowany test zwraca wynik odmowy Dysk zapełniony przez przesłane pliki Kontrole rozmiaru, limitów i przechowywania Limit jest egzekwowany przed awarią usługi Zduplikowane żądanie procesu Idempotencja i granice transakcji Powtórzone żądanie tworzy jeden wynik 04 Ustal priorytety według wpływu i wiarygodnej ścieżki Dla każdego scenariusza zapisz jego potencjalny wpływ i warunki wymagane do jego wystąpienia. Nie udawaj, że zgadnięta ocena liczbowa jest dokładnym prawdopodobieństwem. Nadal możesz odróżnić słabe hasło wystawione na internet od wysoce warunkowego zdarzenia lokalnego. Przypisz właściciela i praktyczny następny krok do ważnych ryzyk, aby model tworzył pracę, którą ktoś może faktycznie wykonać. Rozważ cykl życia informacji, a także przejęcie aplikacji. Eksport diagnostyczny może ujawnić niepotrzebne dane podczas skądinąd normalnego działania. Zachowane pole konta może tworzyć narażenie długo po zakończeniu jego celu. Przegląd prywatności może zatem usunąć informacje lub skrócić okres przechowywania, a przegląd bezpieczeństwa ograniczyć dostęp do tego, co pozostaje. Obie zmiany należą do modelu, gdy chronią projekt. 05 Przetestuj kontrole w autoryzowanym środowisku Utwórz środowisko testowe z reprezentatywnymi uprawnieniami i fikcyjnymi rekordami. Przetestuj odmowę dostępu, limity żądań, ponowienia procesów i odzyskiwanie. Nie używaj prawdziwych danych klientów, gdy dane syntetyczne mogą wykazać zachowanie. Celem jest zweryfikowanie kontroli, a nie wygenerowanie imponującego ruchu atakującego. Pozostań w systemach, które posiadasz lub do oceny których masz wyraźną autoryzację. Zapisz, co się powiodło, co nie i co pozostaje nieznane. Wynik skanera może dostarczyć dowodów, ale nie zastępuje testu reguł biznesowych aplikacji. Podobnie opcja ochrony sieci nie weryfikuje autoryzacji obiektów ani obsługi plików z sekretami. Dołącz przydatne wyniki do scenariusza, aby przyszli opiekunowie rozumieli, dlaczego dana kontrola istnieje. 06 Utrzymuj model w powiązaniu ze zmianami Przejrzyj odpowiednie części, gdy dodajesz integrację, udostępniasz nowy punkt końcowy, zmieniasz uprawnienia lub przenosisz dane do innego miejsca docelowego. Nie musisz przerysowywać całej architektury z powodu drobnej edycji tekstu. Wyzwalaczem jest zmienione założenie dotyczące dostępu, informacji lub zachowania systemu. Trzymaj model obok dokumentacji wdrożeniowej i odzyskiwania, zamiast pozostawiać go jako jednorazowy wynik warsztatów. SwissOctet dostarcza katalog wyborów infrastrukturalnych, a nie gotowy model zagrożeń aplikacji. Wybierz konfigurację i opcje, które wspierają Twoje kontrole, a następnie zweryfikuj wdrożenie, które budujesz. Mały, utrzymywany model z przetestowanymi działaniami jest bardziej przydatny niż duży zbiór produktów bezpieczeństwa bez jasnego wyjaśnienia ryzyk, które adresują. ZAMIEŃ TO W DZIAŁANIE Twoja praktyczna lista kontrolna. ✓ Wymień zasoby i konsekwencje awarii. ✓ Narysuj przepływy danych i granice zaufania. ✓ Wybierz konkretne scenariusze włamania, błędu i przepływu pracy. ✓ Przypisz kontrole i właścicieli do ważnych ryzyk. ✓ Testuj z danymi syntetycznymi w autoryzowanym środowisku. ✓ Przejrzyj model, gdy zmieni się istotne założenie. Pobierz listę kontrolną CZĘSTE PYTANIA Szczegóły, które mają znaczenie. Czy potrzebuję formalnych ram, aby zacząć? + Nie. Mały diagram i udokumentowany zestaw scenariuszy mogą być przydatne. Ramy pomagają zapewnić spójny przegląd ryzyk. Czy skaner podatności zastępuje modelowanie zagrożeń? + Nie. Skanery mogą znaleźć słabości techniczne, podczas gdy model zagrożeń bada również założenia projektowe, uprawnienia i przepływy pracy biznesowej. Jak często aktualizować model? + Aktualizuj odpowiednie części, gdy zmieniają się przepływy danych, integracje, uprawnienia lub udostępniona funkcjonalność, i regularnie przeglądaj nierozwiązane ryzyka. GŁÓWNE ŹRÓDŁA Przejdź do źródła. Te źródła wspierają koncepcje techniczne w tym przewodniku. Przed zmianą systemu produkcyjnego zapoznaj się z aktualną dokumentacją. OWASP: Ściągawka dotycząca modelowania zagrożeń cheatsheetseries.owasp.org OWASP: Modelowanie zagrożeń w praktyce devguide.owasp.org OWASP: Bezpieczeństwo logiki biznesowej cheatsheetseries.owasp.org Wskazówki redakcyjne SwissOctet. Przykłady są ilustracyjne. Specyfikacje usług, dostępne opcje i warunki umowne należy zweryfikować osobno. POŁĄCZ WIEDZĘ Powiązana infrastruktura. Vector VPS Szwajcaria Metal Atlas Szwajcaria Canvas Web Szwajcaria ZACHOWAJ WĄTEK Twoje następne notatki z terenu. Poznaj wszystkie przewodniki NOTATKA Z TERENU / 01 + Operacje dnia drugiego Praktyczne Zbuduj kopię zapasową, którą naprawdę możesz przywrócić Wybierz cel odzyskiwania, zabezpiecz niezależną kopię i przećwicz przywracanie, zanim incydent wymusi działanie. 4 min czytania Przeczytaj przewodnik NOTATKA Z TERENU / 02 + Operacje dnia drugiego Praktyczne Bezpieczne administrowanie Windows RDP bez utraty dostępu Oddziel osiągalność sieciową, uwierzytelnianie i uprawnienia, a następnie zweryfikuj ścieżkę odzyskiwania, zanim ograniczysz dostęp zdalny. 6 min czytania Przeczytaj przewodnik NOTATKA Z TERENU / 03 + Operacje dnia drugiego Praktyczne Bazowy poziom utwardzenia Linux VPS, który możesz utrzymywać Zabezpiecz administrację, udostępniaj tylko wymagane usługi i ustanów aktualizacje oraz odzyskiwanie, nie blokując sobie dostępu. 6 min czytania Przeczytaj przewodnik