Udostępnij za pośrednictwem

Tworzenie bezpiecznych aplikacji na platformie Azure

W tym artykule przedstawimy działania i mechanizmy kontroli zabezpieczeń, które należy wziąć pod uwagę podczas tworzenia aplikacji dla chmury. Omówiono pytania zabezpieczające i pojęcia, które należy wziąć pod uwagę podczas fazy implementacji i weryfikacji cyklu projektowania zabezpieczeń firmy Microsoft (SDL ). Celem jest ułatwienie definiowania działań i usług platformy Azure, których można użyć do opracowania bezpieczniejszej aplikacji.

W tym artykule opisano następujące fazy SDL:

  • Implementacja
  • Weryfikacja

Implementacja

Faza implementacji koncentruje się na ustanowieniu najlepszych rozwiązań dotyczących wczesnego zapobiegania oraz wykrywaniu i usuwaniu problemów z zabezpieczeniami z kodu. Przyjmijmy, że twoja aplikacja jest używana w sposób, w jaki nie zamierzałeś jej używać. Pomaga to chronić przed przypadkowym lub zamierzonym nieprawidłowym użyciem aplikacji.

Przeprowadzanie przeglądów kodu

Przed zaewidencjonowania kodu przeprowadź przeglądy kodu w celu zwiększenia ogólnej jakości kodu i zmniejszenia ryzyka tworzenia usterek. Za pomocą programu Visual Studio można zarządzać procesem przeglądu kodu.

Przeprowadzanie statycznej analizy kodu

Analiza kodu statycznego (nazywana również analizą kodu źródłowego) jest wykonywana w ramach przeglądu kodu. Statyczna analiza kodu zwykle oznacza użycie narzędzi do statycznej analizy kodu w celu znalezienia potencjalnych luk w zabezpieczeniach w kodzie nieuruchomionym. Analiza kodu statycznego używa technik, takich jak sprawdzanie defektów i analiza przepływu danych.

Witryna Azure Marketplace oferuje narzędzia deweloperskie , które wykonują analizę kodu statycznego i ułatwiają przeglądy kodu.

Weryfikowanie i oczyszczanie wszystkich danych wejściowych aplikacji

Traktuj wszystkie dane wejściowe jako niezaufane, aby chronić aplikację przed najczęstszymi lukami w zabezpieczeniach aplikacji internetowych. Niezaufane dane mogą być przyczyną ataków polegających na wstrzykiwaniu kodu. Dane wejściowe dla aplikacji obejmują parametry w adresie URL, dane od użytkownika, dane z bazy danych lub interfejsu API oraz wszelkie inne dane, które użytkownik może potencjalnie zmodyfikować. Aplikacja powinna sprawdzić , czy dane są składniowo i semantycznie prawidłowe, zanim aplikacja będzie używać danych w dowolny sposób (w tym wyświetlać je z powrotem do użytkownika).

Zweryfikuj dane wejściowe na wczesnym etapie przepływu danych, aby upewnić się, że tylko prawidłowo sformułowane dane wchodzą do przepływu pracy. Nie chcesz, aby źle sformułowane dane trwały w bazie danych ani powodowały awarię w dalszym komponencie.

Lista zablokowanych i lista dozwolonych to dwa ogólne podejścia do przeprowadzania walidacji składni danych wejściowych:

  • Blokowanie próby sprawdzenia, czy dane wejściowe danego użytkownika nie zawierają zawartości "znanej jako złośliwa".

  • Lista dozwolonych ma na celu sprawdzenie, czy dane wejściowe użytkownika są zgodne z zestawem "znanych dobrych" danych wejściowych. Lista dozwolonych opartych na znakach to forma listy dozwolonych, w której aplikacja sprawdza, czy dane wejściowe użytkownika zawierają tylko "znane dobre" znaki lub dane wejściowe pasują do znanego formatu.

    Może to na przykład obejmować sprawdzenie, czy nazwa użytkownika zawiera tylko znaki alfanumeryczne lub zawiera dokładnie dwie liczby.

Lista dozwolonych to preferowane podejście do tworzenia bezpiecznego oprogramowania. Blokowanie listy jest podatne na błąd, ponieważ nie można myśleć o pełnej liście potencjalnie nieprawidłowych danych wejściowych.

Wykonaj tę pracę na serwerze, a nie po stronie klienta (lub po stronie serwera i po stronie klienta).

Weryfikowanie danych wyjściowych aplikacji

Wszystkie dane wyjściowe przedstawione wizualnie lub w dokumencie powinny być zawsze kodowane i usuwane. Ucieczka, znana również jako kodowanie danych wyjściowych, służy do zapewnienia, że niezaufane dane nie są pojazdem do ataku iniekcyjnego. Ucieczka, w połączeniu z weryfikacją danych, zapewnia warstwowe zabezpieczenia w celu zwiększenia bezpieczeństwa systemu jako całości.

Ucieczka zapewnia, że wszystkie elementy są wyświetlane jako dane wyjściowe. Ucieczka informuje również interpretera, że dane nie mają być wykonywane, a to uniemożliwia działanie ataków. Jest to kolejna typowa technika ataku nazywana cross-site scripting (XSS).

Jeśli używasz frameworku internetowego od innej firmy, możesz zweryfikować opcje kodowania danych wyjściowych na stronach internetowych przy użyciu ściągawki zapobiegania OWASP XSS.

Używanie zapytań sparametryzowanych podczas kontaktów z bazą danych

Nigdy nie twórz wbudowanego zapytania bazy danych "na bieżąco" w kodzie i wysyłaj je bezpośrednio do bazy danych. Złośliwy kod wstawiony do aplikacji może potencjalnie spowodować kradzież, wyczyszczenie lub zmodyfikowanie bazy danych. Aplikacja może być również używana do uruchamiania złośliwych poleceń systemu operacyjnego w systemie operacyjnym, który hostuje bazę danych.

Zamiast tego należy użyć sparametryzowanych zapytań lub procedur składowanych. W przypadku korzystania z zapytań sparametryzowanych można bezpiecznie uruchomić procedurę z poziomu kodu i przekazać ją jako ciąg bez obaw, że zostanie potraktowany jako część zapytania.

Usuwanie standardowych nagłówków serwera

Nagłówki, takie jak Server, X-Powered-By i X-AspNet-Version ujawniają informacje o serwerze i podstawowych technologiach. Zalecamy pomijanie tych nagłówków, aby uniknąć odcisku palca aplikacji. Zobacz usuwanie standardowych nagłówków serwera w witrynach internetowych platformy Azure.

Segregowanie danych produkcyjnych

Dane produkcyjne lub "rzeczywiste" dane nie powinny być używane do rozwoju, testowania ani żadnego innego celu, poza zamierzonym zastosowaniem przez firmę. Do wszystkich testów i programowania należy użyć zamaskowanego (anonimowego) zestawu danych.

Oznacza to, że mniej osób ma dostęp do rzeczywistych danych, co zmniejsza obszar ataków. Oznacza to również, że mniej pracowników widzi dane osobowe, co eliminuje potencjalne naruszenie poufności.

Implementowanie silnych zasad haseł

Aby bronić przed atakami siłowymi i słownikowymi, należy zaimplementować silne zasady haseł, aby upewnić się, że użytkownicy tworzą złożone hasło (na przykład minimalną długość 12 znaków i wymagają znaków alfanumerycznych i specjalnych).

Microsoft Entra External ID w dzierżawach zewnętrznych ułatwia zarządzanie hasłami, zapewniając samoobsługowe resetowanie haseł i nie tylko.

Aby bronić się przed atakami na konta domyślne, sprawdź, czy wszystkie klucze i hasła są zastępowane i czy są generowane lub zastępowane po zainstalowaniu zasobów.

Jeśli aplikacja musi automatycznie wygenerować hasła, upewnij się, że wygenerowane hasła są losowe i że mają wysoką entropię.

Weryfikowanie przekazywania plików

Jeśli aplikacja zezwala na przekazywanie plików, rozważ środki ostrożności, które można podjąć w przypadku tego ryzykownych działań. Pierwszym krokiem w wielu atakach jest wprowadzenie złośliwego kodu do systemu, który jest atakowany. Użycie przesyłania plików pomaga atakującemu w osiągnięciu tego celu. Program OWASP oferuje rozwiązania do weryfikacji pliku, aby upewnić się, że przekazywany plik jest bezpieczny.

Ochrona przed złośliwym kodem pomaga identyfikować i usuwać wirusy, programy szpiegujące i inne złośliwe oprogramowanie. Możesz zainstalować oprogramowanie Microsoft Antimalware lub rozwiązanie ochrony punktu końcowego partnera firmy Microsoft (Trend Micro, Broadcom, McAfee, Microsoft Defender Antivirus w systemie Windows i Endpoint Protection).

Program Microsoft Antimalware zawiera funkcje, takie jak ochrona w czasie rzeczywistym, zaplanowane skanowanie, usuwanie złośliwego oprogramowania, aktualizacje sygnatur, aktualizacje silnika, raportowanie próbek i gromadzenie zdarzeń wykluczenia. Rozwiązania firmy Microsoft antimalware i rozwiązania partnerskie można zintegrować z Microsoft Defender dla Chmury w celu ułatwienia wdrażania i wbudowanych wykryć (alertów i zdarzeń).

Nie buforuj poufnej zawartości

Nie buforuj poufnej zawartości w przeglądarce. Przeglądarki mogą przechowywać informacje dotyczące buforowania i historii. Buforowane pliki są przechowywane w folderze, na przykład w folderze Tymczasowe pliki internetowe, w przypadku programu Internet Explorer. Po ponownym odwołyniu się do tych stron przeglądarka wyświetla strony z pamięci podręcznej. Jeśli informacje poufne (adres, szczegóły karty kredytowej, numer ubezpieczenia społecznego, nazwa użytkownika) są wyświetlane użytkownikowi, informacje mogą być przechowywane w pamięci podręcznej przeglądarki i można je pobrać, sprawdzając pamięć podręczną przeglądarki lub naciskając przycisk Wstecz przeglądarki.

Weryfikacja

Faza weryfikacji obejmuje kompleksowy wysiłek w celu zapewnienia, że kod spełnia założenia dotyczące zabezpieczeń i prywatności, które zostały ustanowione w poprzednich fazach.

Znajdowanie i naprawianie luk w zabezpieczeniach w zależnościach aplikacji

Przeskanujesz aplikację i jej biblioteki zależne, aby zidentyfikować wszystkie znane składniki podatne na zagrożenia. Produkty, które są dostępne do wykonania tego skanowania, obejmują OWASP Dependency Check, Snyk i Black Duck.

Testowanie aplikacji w stanie operacyjnym

Dynamiczne testowanie zabezpieczeń aplikacji (DAST) to proces testowania aplikacji w stanie operacyjnym w celu znalezienia luk w zabezpieczeniach. Narzędzia DAST analizują programy podczas ich wykonywania w celu znalezienia luk w zabezpieczeniach, takich jak uszkodzenie pamięci, niezabezpieczona konfiguracja serwera, wykonywanie skryptów między witrynami, problemy z uprawnieniami użytkownika, wstrzyknięcie kodu SQL i inne krytyczne problemy z zabezpieczeniami.

DAST różni się od statycznego testowania bezpieczeństwa aplikacji (SAST). Narzędzia SAST analizują kod źródłowy lub skompilowane wersje kodu, gdy kod nie jest wykonywany w celu znalezienia luk w zabezpieczeniach.

Wykonaj DAST, najlepiej z pomocą specjalisty ds. zabezpieczeń (tester penetracyjny lub audytor luk w zabezpieczeniach). Jeśli specjalista ds. zabezpieczeń nie jest dostępny, możesz wykonać proces DAST samodzielnie za pomocą skanera serwerów proxy sieci Web i niektórych szkoleń. Podłącz skaner DAST na wczesnym etapie, aby upewnić się, że nie wprowadzasz oczywistych problemów z zabezpieczeniami do kodu. Aby uzyskać listę skanerów luk w zabezpieczeniach aplikacji internetowych, zobacz witrynę OWASP .

Przeprowadzanie testów rozmytych

Podczas testowania rozmytego wywołujesz błąd programu, celowo wprowadzając źle sformułowane lub losowe dane do aplikacji. Wywoływanie awarii programu pomaga ujawnić potencjalne problemy z zabezpieczeniami, zanim aplikacja zostanie wydana.

Wykrywanie ryzyka zabezpieczeń to unikatowa usługa testowania rozmytego firmy Microsoft służąca do znajdowania usterek krytycznych pod względem zabezpieczeń w oprogramowaniu.

Przeprowadzanie przeglądu powierzchni ataków

Przegląd powierzchni ataków po zakończeniu kodu pomaga upewnić się, że wszelkie zmiany projektu lub implementacji aplikacji lub systemu zostały uwzględnione. Pomaga to zagwarantować, że wszystkie nowe wektory ataków, które zostały utworzone w wyniku zmian, w tym modeli zagrożeń, zostały przejrzyone i wyeliminowane.

Obraz powierzchni ataków można utworzyć, przeskanując aplikację. Firma Microsoft oferuje narzędzie do analizy powierzchni ataków o nazwie Attack Surface Analyzer. Możesz wybrać spośród wielu komercyjnych narzędzi do testowania dynamicznego i skanowania luk w zabezpieczeniach, w tym narzędzia do wykrywania powierzchni ataków OWASP, Arachni i w3af. Te narzędzia skanowania przeszukują aplikację i mapują części aplikacji, które są dostępne w Internecie. Możesz również wyszukać w witrynie Azure Marketplace podobne narzędzia deweloperskie.

Przeprowadzanie testów penetracyjnych zabezpieczeń

Zapewnienie bezpieczeństwa aplikacji jest tak ważne, jak testowanie innych funkcji. Przetestuj testy penetracyjne w standardowej części procesu kompilacji i wdrażania. Zaplanuj regularne testy zabezpieczeń i skanowanie luk w zabezpieczeniach na wdrożonych aplikacjach oraz monitoruj otwarte porty, punkty końcowe i ataki.

Uruchamianie testów weryfikacji zabezpieczeń

Rozwiązanie zabezpieczeń dzierżawy platformy Azure (AzTS) z zestawu Secure DevOps Kit for Azure (AzSK) zawiera SVT dla wielu usług platformy Azure. Te pliki SVTs są uruchamiane okresowo, aby upewnić się, że subskrypcja platformy Azure i różne zasoby składające się na aplikację są w stanie bezpiecznym. Te testy można również zautomatyzować przy użyciu funkcji rozszerzeń ciągłej integracji/ciągłego wdrażania (CI/CD) narzędzia AzSK, która udostępnia pliki SVTs jako rozszerzenie programu Visual Studio.

Dalsze kroki

W poniższych artykułach zalecamy mechanizmy kontroli zabezpieczeń i działania, które mogą pomóc w projektowaniu i wdrażaniu bezpiecznych aplikacji.