Podsumowanie
Test penetracyjny aplikacji handlu elektronicznego firmy Contoso Retail ujawnił trzy luki: brak wymuszania uwierzytelniania na poziomie platformy, brak ograniczeń dotyczących miejsca, z którego może pochodzić ruch przychodzący, i brak Web Application Firewall (WAF) chroniący przed atakami w warstwie aplikacji. W tym module omówiono wszystkie trzy za pomocą mechanizmów kontroli, które można konfigurować, egzekwować na szeroką skalę i stale monitorować.
Przeglądanie skonfigurowanych ustawień
Pierwsza luka — brak egzekwowania uwierzytelniania — jest teraz rozwiązana na poziomie warstwy platformy. Skonfigurowano uwierzytelnianie EasyAuth w usłudze App Service przy użyciu Microsoft Entra ID jako dostawcy tożsamości i ustawiono akcję dla nieuwierzytelnionych żądań na „Wymagaj uwierzytelniania”. Żądania nieuwierzytelnione są blokowane przed dotarciem do kodu aplikacji. Włączona przez Ciebie tożsamość zarządzana eliminuje konieczność przechowywania poświadczeń w ustawieniach aplikacji, a odwołania do usługi Key Vault zapewniają, że wpisy tajne pozostają w magazynie, zamiast trafiać do artefaktów wdrożeniowych lub kart konfiguracji.
Druga luka — brak ograniczeń sieci dla ruchu przychodzącego — jest zamknięta za pośrednictwem ograniczeń dostępu i wdrożenia prywatnego punktu końcowego. Usługa App Service akceptuje teraz ruch przychodzący wyłącznie z bramy Application Gateway, uniemożliwiając atakującym ominięcie inspekcji WAF poprzez bezpośrednie kierowanie żądań do nazwy hosta usługi App Service. Integracja z siecią wirtualną zapewnia prywatny dostęp wychodzący do zasobów zaplecza, a ustawienie Tylko HTTPS z minimalną wersją protokołu Transport Layer Security (TLS) 1.2 eliminuje narażenie na poziomie protokołu.
Trzecia luka — brak ochrony warstwy brzegowej przed atakami na aplikacje — jest eliminowana za pomocą zasad WAF w usłudze Application Gateway. Wybrano zestaw reguł Core Rule Set (CRS) 3.2 jako zarządzany zestaw reguł do ochrony przed kategoriami ataków z listy OWASP Top 10, w tym atakami typu SQL injection, wdrożony początkowo w trybie wykrywania na potrzeby dostrajania oraz skonfigurowano ukierunkowane wykluczenia, aby ograniczyć liczbę fałszywych alarmów przed przełączeniem do trybu zapobiegania. Niestandardowe reguły i powiązania zasad dla poszczególnych witryn zapewniają elastyczność w dostosowaniu WAF do specyficznych wymagań aplikacji.
Te trzy warstwy działają jako system. WAF bez ograniczeń po stronie backendu może zostać ominięty. Ograniczenie dostępu do backendu bez WAF pozostawia ataki na warstwie aplikacji bez kontroli. Uwierzytelnianie platformy bez kontroli sieci nadal naraża aplikację na nieuwierzytelnione żądania z niepożądanych źródeł. Skuteczność zabezpieczeń wymaga razem wszystkich trzech warstw.