Ramka zabezpieczeń: autoryzacja | Czynniki

Produkt/usługa	Artykuł
Granica zaufania maszyny	Upewnij się, że odpowiednie listy ACL zostały skonfigurowane w celu ograniczenia nieautoryzowanego dostępu do danych na urządzeniu Upewnij się, że zawartość aplikacji specyficznej dla użytkownika jest przechowywana w katalogu profilu użytkownika Upewnij się, że wdrożone aplikacje są uruchamiane z najmniejszymi uprawnieniami
Aplikacja internetowa	Wymuszanie kolejności kroków sekwencyjnych podczas przetwarzania przepływów logiki biznesowej Implementowanie mechanizmu ograniczania szybkości w celu zapobiegania wyliczaniu Upewnij się, że obowiązuje właściwa autoryzacja, a przestrzegana jest zasada najmniejszych uprawnień Decyzje dotyczące autoryzacji dostępu do zasobów i logiki biznesowej nie powinny być oparte na parametrach żądania przychodzącego Upewnij się, że zawartość i zasoby nie są wyliczane ani dostępne za pośrednictwem wymuszonego przeglądania
Baza danych	Upewnij się, że konta z najniższymi uprawnieniami są używane do nawiązywania połączenia z serwerem bazy danych Zaimplementuj zabezpieczenia na poziomie wiersza, aby uniemożliwić dzierżawcom uzyskiwanie dostępu do danych nawzajem Rola administratora systemu powinna mieć tylko prawidłowych niezbędnych użytkowników
Brama chmury IoT	Nawiązywanie połączenia z usługą Cloud Gateway przy użyciu tokenów o najniższych uprawnieniach
Azure Event Hub	Używanie klucza sygnatury dostępu współdzielonego uprawnień tylko do wysyłania do generowania tokenów urządzeń Nie używaj tokenów dostępu, które zapewniają bezpośredni dostęp do centrum zdarzeń Nawiązywanie połączenia z centrum zdarzeń przy użyciu kluczy SAS, które mają wymagane minimalne uprawnienia
Azure Document DB	Używanie tokenów zasobów do nawiązywania połączenia z usługą Azure Cosmos DB zawsze, gdy jest to możliwe
Granica zaufania platformy Azure	Włączanie szczegółowego zarządzania dostępem do subskrypcji platformy Azure przy użyciu kontroli dostępu opartej na rolach platformy Azure
Granica zaufania usługi Service Fabric	Ograniczanie dostępu klienta do operacji klastra przy użyciu kontroli dostępu opartej na rolach platformy Azure
Dynamics CRM	Wykonywanie modelowania zabezpieczeń i używanie zabezpieczeń na poziomie pola, jeśli jest to wymagane
Dynamics CRM Portal	Należy pamiętać, że model zabezpieczeń kont portalu różni się od pozostałej części usługi CRM
Azure Storage	Udzielanie szczegółowego uprawnienia do zakresu jednostek w usłudze Azure Table Storage Włączanie kontroli dostępu opartej na rolach (RBAC) platformy Azure na koncie usługi Azure Storage przy użyciu usługi Azure Resource Manager
Klient mobilny	Implementowanie niejawnego wykrywania jailbreaku lub wykrywania rootingu
WCF	Słabe odwołanie do klas w programie WCF WCF-Implement kontrolka autoryzacji
Internetowy interfejs API	Implementowanie odpowiedniego mechanizmu autoryzacji w interfejsie API sieci Web ASP.NET
Urządzenie IoT	Przeprowadzanie kontroli autoryzacji na urządzeniu, jeśli obsługuje różne akcje wymagające różnych poziomów uprawnień
Brama pola IoT	Przeprowadzanie kontroli autoryzacji w bramie field gateway, jeśli obsługuje różne akcje wymagające różnych poziomów uprawnień

Upewnij się, że odpowiednie listy ACL zostały skonfigurowane w celu ograniczenia nieautoryzowanego dostępu do danych na urządzeniu

Tytuł	Szczegóły
Składnik	Granica zaufania maszyny
Faza SDL	Wdrożenie
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Nie dotyczy
Kroki	Upewnij się, że odpowiednie listy ACL zostały skonfigurowane w celu ograniczenia nieautoryzowanego dostępu do danych na urządzeniu

Upewnij się, że zawartość aplikacji specyficznej dla użytkownika jest przechowywana w katalogu profilu użytkownika

Tytuł	Szczegóły
Składnik	Granica zaufania maszyny
Faza SDL	Wdrożenie
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Nie dotyczy
Kroki	Upewnij się, że zawartość aplikacji specyficznej dla użytkownika jest przechowywana w katalogu profilu użytkownika. Ma to na celu uniemożliwienie wielu użytkownikom maszyny uzyskiwania dostępu do danych.

Upewnij się, że wdrożone aplikacje są uruchamiane z najmniejszymi uprawnieniami

Tytuł	Szczegóły
Składnik	Granica zaufania maszyny
Faza SDL	Wdrożenie
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Nie dotyczy
Kroki	Upewnij się, że wdrożona aplikacja jest uruchamiana z najmniejszymi uprawnieniami.

Wymuszanie kolejności kroków sekwencyjnych podczas przetwarzania przepływów logiki biznesowej

Tytuł	Szczegóły
Składnik	Aplikacja internetowa
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Nie dotyczy
Kroki	Aby sprawdzić, czy ten etap został uruchomiony przez prawdziwego użytkownika, który chce wymusić, aby aplikacja przetwarzała tylko przepływy logiki biznesowej w kolejności kroków sekwencyjnych, a wszystkie kroki są przetwarzane w realistycznym czasie ludzkim, a nie przetwarzać poza kolejnością, pomijane kroki, przetwarzane kroki od innego użytkownika lub zbyt szybko przesłane transakcje.

Implementowanie mechanizmu ograniczania szybkości w celu zapobiegania wyliczaniu

Tytuł	Szczegóły
Składnik	Aplikacja internetowa
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Nie dotyczy
Kroki	Upewnij się, że poufne identyfikatory są losowe. Zaimplementuj kontrolkę CAPTCHA na stronach anonimowych. Upewnij się, że błąd i wyjątek nie powinny ujawniać określonych danych

Upewnij się, że obowiązuje właściwa autoryzacja, a przestrzegana jest zasada najmniejszych uprawnień

Tytuł	Szczegóły
Składnik	Aplikacja internetowa
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Nie dotyczy
Kroki	Zasada oznacza przyznanie kontu użytkownika tylko tych uprawnień, które są niezbędne dla tych użytkowników. Na przykład użytkownik kopii zapasowej nie musi instalować oprogramowania: w związku z tym użytkownik kopii zapasowej ma uprawnienia tylko do uruchamiania aplikacji kopii zapasowych i tworzenia kopii zapasowych. Wszystkie inne uprawnienia, takie jak instalowanie nowego oprogramowania, są blokowane. Zasada ma zastosowanie również do użytkownika komputera osobistego, który zwykle działa na normalnym koncie użytkownika, i otwiera uprzywilejowane, chronione hasłem konto (czyli superużytkownik) tylko wtedy, gdy sytuacja absolutnie tego wymaga. Tę zasadę można również zastosować do aplikacji internetowych. Zamiast wyłącznie w zależności od metod uwierzytelniania opartych na rolach przy użyciu sesji, raczej chcemy przypisać uprawnienia użytkownikom za pomocą systemu uwierzytelniania opartego na bazie danych. Nadal używamy sesji, aby określić, czy użytkownik został poprawnie zalogowany, tylko teraz zamiast przypisywać tego użytkownika z określoną rolą przypisujemy mu uprawnienia, aby sprawdzić, które działania ma uprawnienia do wykonania w systemie. Również duży pro tej metody jest, gdy użytkownik musi mieć przypisane mniej uprawnień, zmiany zostaną zastosowane na bieżąco, ponieważ przypisanie nie zależy od sesji, która w przeciwnym razie musiała wygasnąć.

Decyzje dotyczące autoryzacji dostępu do zasobów i logiki biznesowej nie powinny być oparte na parametrach żądania przychodzącego

Tytuł	Szczegóły
Składnik	Aplikacja internetowa
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Nie dotyczy
Kroki	Za każdym razem, gdy sprawdzasz, czy użytkownik jest ograniczony do przeglądania określonych danych, ograniczenia dostępu powinny być przetwarzane po stronie serwera. Identyfikator użytkownika powinien być przechowywany w zmiennej sesji podczas logowania i powinien być używany do pobierania danych użytkownika z bazy danych

Przykład

SELECT data 
FROM personaldata 
WHERE userID=:id < - session var 

Teraz możliwe osoby atakujące nie mogą manipulować i zmieniać operacji aplikacji, ponieważ identyfikator pobierania danych jest obsługiwany po stronie serwera.

Upewnij się, że zawartość i zasoby nie są wyliczane ani dostępne za pośrednictwem wymuszonego przeglądania

Tytuł	Szczegóły
Składnik	Aplikacja internetowa
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Nie dotyczy
Kroki	Poufne pliki statyczne i konfiguracyjne nie powinny być przechowywane w katalogu głównym sieci Web. Aby zawartość nie musi być publiczna, należy zastosować odpowiednie mechanizmy kontroli dostępu lub usunąć samą zawartość. Ponadto wymuszane przeglądanie jest zwykle łączone z technikami siłowych w celu zebrania informacji przez próbę uzyskania dostępu do jak największej liczby adresów URL w celu wyliczenia katalogów i plików na serwerze. Osoby atakujące mogą sprawdzić wszystkie odmiany często istniejących plików. Na przykład wyszukiwanie plików haseł obejmuje pliki, w tym psswd.txt, password.htm, password.dat i inne odmiany. Aby temu zapobiec, należy uwzględnić możliwości wykrywania prób siłowych.

Upewnij się, że konta z najniższymi uprawnieniami są używane do nawiązywania połączenia z serwerem bazy danych

Tytuł	Szczegóły
Składnik	baza danych
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Hierarchia uprawnień SQL, zabezpieczanie bazy danych SQL
Kroki	Konta z najniższymi uprawnieniami powinny być używane do nawiązywania połączenia z bazą danych. Logowanie aplikacji powinno być ograniczone w bazie danych i powinno być wykonywane tylko wybrane procedury składowane. Logowanie aplikacji nie powinno mieć bezpośredniego dostępu do tabeli.

Zaimplementuj zabezpieczenia na poziomie wiersza, aby uniemożliwić dzierżawcom uzyskiwanie dostępu do danych nawzajem

Tytuł	Szczegóły
Składnik	baza danych
Faza SDL	Kompilacja
Odpowiednie technologie	Sql Azure, OnPrem
Atrybuty	Wersja SQL — wersja 12, wersja SQL — MsSQL2016
Dokumentacja	Zabezpieczenia na poziomie wiersza programu SQL Server (RLS)
Kroki	Zabezpieczenia na poziomie wiersza umożliwiają klientom kontrolowanie dostępu do wierszy w tabeli bazy danych na podstawie właściwości użytkownika wykonującego zapytanie (np. członkostwa w grupie lub kontekstu wykonania). Zabezpieczenia na poziomie wiersza upraszcza projektowanie i kodowanie zabezpieczeń w aplikacji. Zabezpieczenia na poziomie wiersza umożliwiają zaimplementowanie ograniczeń w dostępie do wiersza danych. Możliwe jest na przykład zapewnienie, że pracownicy mają dostęp tylko do tych wierszy danych, które są odpowiednie do ich działu, lub ograniczenie dostępu do danych klienta tylko do danych odpowiednich dla firmy. Logika ograniczeń dostępu znajduje się w warstwie bazy danych, a nie z dala od danych w innej warstwie aplikacji. System bazy danych stosuje ograniczenia dostępu za każdym razem, gdy jest podejmowana próba uzyskania dostępu do danych z dowolnej warstwy. Dzięki temu system zabezpieczeń jest bardziej niezawodny i niezawodny, zmniejszając obszar powierzchni systemu zabezpieczeń.

Należy pamiętać, że zabezpieczenia na poziomie wiersza jako wbudowana funkcja bazy danych mają zastosowanie tylko do programu SQL Server od 2016 r., usługi Azure SQL Database i wystąpienia zarządzanego SQL. Jeśli wbudowana funkcja zabezpieczeń na poziomie wiersza nie jest zaimplementowana, należy się upewnić, że dostęp do danych jest ograniczony przy użyciu widoków i procedur

Rola administratora systemu powinna mieć tylko prawidłowych niezbędnych użytkowników

Tytuł	Szczegóły
Składnik	baza danych
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Hierarchia uprawnień SQL, zabezpieczanie bazy danych SQL
Kroki	Członkowie stałej roli serwera SysAdmin powinny być bardzo ograniczone i nigdy nie zawierają kont używanych przez aplikacje. Przejrzyj listę użytkowników w roli i usuń wszystkie niepotrzebne konta

Nawiązywanie połączenia z usługą Cloud Gateway przy użyciu tokenów o najniższych uprawnieniach

Tytuł	Szczegóły
Składnik	Brama chmury IoT
Faza SDL	Wdrożenie
Odpowiednie technologie	Ogólna
Atrybuty	Wybór bramy — Azure IoT Hub
Dokumentacja	Kontrola dostępu do centrum Iot Hub
Kroki	Podaj uprawnienia najniższych uprawnień do różnych składników łączących się z usługą Cloud Gateway (IoT Hub). Typowy przykład: Składnik zarządzania urządzeniami/aprowizacji używa rejestruread/write, procesor zdarzeń (ASA) używa programu Service Connect. Poszczególne urządzenia łączą się przy użyciu poświadczeń urządzenia

Używanie klucza sygnatury dostępu współdzielonego uprawnień tylko do wysyłania do generowania tokenów urządzeń

Tytuł	Szczegóły
Składnik	Centrum zdarzeń Azure
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Omówienie uwierzytelniania i modelu zabezpieczeń usługi Event Hubs
Kroki	Klucz sygnatury dostępu współdzielonego służy do generowania poszczególnych tokenów urządzeń. Używanie klucza sygnatury dostępu współdzielonego uprawnień tylko do wysyłania podczas generowania tokenu urządzenia dla danego wydawcy

Nie używaj tokenów dostępu, które zapewniają bezpośredni dostęp do centrum zdarzeń

Tytuł	Szczegóły
Składnik	Centrum zdarzeń Azure
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Omówienie uwierzytelniania i modelu zabezpieczeń usługi Event Hubs
Kroki	Token, który udziela bezpośredniego dostępu do centrum zdarzeń, nie powinien być udzielany urządzeniu. Użycie tokenu o najniższych uprawnieniach dla urządzenia, które zapewnia dostęp tylko wydawcy, pomogłoby zidentyfikować go i uniemożliwić, jeśli okaże się, że jest to nieautoryzowane lub naruszone urządzenie.

Nawiązywanie połączenia z centrum zdarzeń przy użyciu kluczy SAS, które mają wymagane minimalne uprawnienia

Tytuł	Szczegóły
Składnik	Centrum zdarzeń Azure
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Omówienie uwierzytelniania i modelu zabezpieczeń usługi Event Hubs
Kroki	Zapewnienie najniższych uprawnień do różnych aplikacji zaplecza łączących się z centrum zdarzeń. Wygeneruj oddzielne klucze SYGNATURy dostępu współdzielonego dla każdej aplikacji zaplecza i podaj tylko wymagane uprawnienia — wyślij, odbierz lub zarządzaj do nich.

Używanie tokenów zasobów do nawiązywania połączenia z usługą Azure Cosmos DB zawsze, gdy jest to możliwe

Tytuł	Szczegóły
Składnik	Azure Document DB
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Nie dotyczy
Kroki	Token zasobu jest skojarzony z zasobem uprawnień usługi Azure Cosmos DB i przechwytuje relację między użytkownikiem bazy danych a uprawnieniem, które użytkownik ma dla określonego zasobu aplikacji usługi Azure Cosmos DB (np. kolekcji, dokumentu). Zawsze używaj tokenu zasobu, aby uzyskać dostęp do usługi Azure Cosmos DB, jeśli klient nie może być zaufany z obsługą kluczy głównych lub tylko do odczytu — na przykład aplikacji użytkownika końcowego, takiej jak klient mobilny lub stacjonarny. Użyj klucza głównego lub kluczy tylko do odczytu z aplikacji zaplecza, które mogą bezpiecznie przechowywać te klucze.

Włączanie szczegółowego zarządzania dostępem do subskrypcji platformy Azure przy użyciu kontroli dostępu opartej na rolach platformy Azure

Tytuł	Szczegóły
Składnik	Granica zaufania platformy Azure
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Przypisywanie ról platformy Azure do zarządzania dostępem do zasobów subskrypcji platformy Azure
Kroki	Kontrola dostępu oparta na rolach (RBAC) platformy Azure umożliwia szczegółowe zarządzanie dostępem na platformie Azure. Korzystając z kontroli dostępu opartej na rolach platformy Azure, można przyznać tylko dostęp, który użytkownicy muszą wykonywać swoje zadania.

Ograniczanie dostępu klienta do operacji klastra przy użyciu kontroli dostępu opartej na rolach usługi Service Fabric

Tytuł	Szczegóły
Składnik	Granica zaufania usługi Service Fabric
Faza SDL	Wdrożenie
Odpowiednie technologie	Ogólna
Atrybuty	Środowisko — Azure
Dokumentacja	Kontrola dostępu oparta na rolach usługi Service Fabric dla klientów usługi Service Fabric
Kroki	Usługa Azure Service Fabric obsługuje dwa różne typy kontroli dostępu dla klientów połączonych z klastrem usługi Service Fabric: administratorem i użytkownikiem. Kontrola dostępu umożliwia administratorowi klastra ograniczenie dostępu do niektórych operacji klastra dla różnych grup użytkowników, dzięki czemu klaster jest bezpieczniejszy. Administratorzy mają pełny dostęp do funkcji zarządzania (w tym możliwości odczytu/zapisu). Użytkownicy domyślnie mają tylko dostęp do odczytu do funkcji zarządzania (na przykład możliwości zapytań) oraz możliwość rozpoznawania aplikacji i usług. W momencie tworzenia klastra należy określić dwie role klienta (administrator i klient), podając oddzielne certyfikaty dla każdego z nich.

Wykonywanie modelowania zabezpieczeń i używanie zabezpieczeń na poziomie pola, jeśli jest to wymagane

Tytuł	Szczegóły
Składnik	Dynamics CRM
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Nie dotyczy
Kroki	Wykonywanie modelowania zabezpieczeń i używanie zabezpieczeń na poziomie pola, jeśli jest to wymagane

Należy pamiętać, że model zabezpieczeń kont portalu różni się od pozostałej części usługi CRM

Tytuł	Szczegóły
Składnik	Dynamics CRM Portal
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Nie dotyczy
Kroki	Należy pamiętać, że model zabezpieczeń kont portalu różni się od pozostałej części usługi CRM

Udzielanie szczegółowego uprawnienia do zakresu jednostek w usłudze Azure Table Storage

Tytuł	Szczegóły
Składnik	Azure Storage
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	StorageType — tabela
Dokumentacja	Jak delegować dostęp do obiektów na koncie usługi Azure Storage przy użyciu sygnatury dostępu współdzielonego
Kroki	W niektórych scenariuszach biznesowych usługa Azure Table Storage może być wymagana do przechowywania poufnych danych przeznaczonych dla różnych firm. Na przykład poufne dane dotyczące różnych krajów/regionów. W takich przypadkach sygnatury sygnatur sas można utworzyć, określając zakresy kluczy partycji i wierszy, tak aby użytkownik mógł uzyskać dostęp do danych specyficznych dla określonego kraju/regionu.

Włączanie kontroli dostępu opartej na rolach (RBAC) platformy Azure na koncie usługi Azure Storage przy użyciu usługi Azure Resource Manager

Tytuł	Szczegóły
Składnik	Azure Storage
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Jak zabezpieczyć konto magazynu przy użyciu kontroli dostępu opartej na rolach (RBAC) platformy Azure
Kroki	Podczas tworzenia nowego konta magazynu wybierasz model wdrażania klasycznego lub usługi Azure Resource Manager. Klasyczny model tworzenia zasobów na platformie Azure umożliwia tylko dostęp do całej subskrypcji, a z kolei konto magazynu. W modelu usługi Azure Resource Manager należy umieścić konto magazynu w grupie zasobów i kontrolować dostęp do płaszczyzny zarządzania tego określonego konta magazynu przy użyciu identyfikatora Microsoft Entra. Na przykład można przyznać określonym użytkownikom możliwość dostępu do kluczy konta magazynu, podczas gdy inni użytkownicy mogą wyświetlać informacje o koncie magazynu, ale nie mogą uzyskać dostępu do kluczy konta magazynu.

Implementowanie niejawnego wykrywania jailbreaku lub wykrywania rootingu

Tytuł	Szczegóły
Składnik	Klient mobilny
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Nie dotyczy
Kroki	Aplikacja powinna chronić własną konfigurację i dane użytkownika w przypadku, gdy telefon jest odblokowany lub złamany w więzieniu. Rooting/jail breaking oznacza nieautoryzowany dostęp, który normalny użytkownicy nie będą robić na własnych telefonach. W związku z tym aplikacja powinna mieć logikę wykrywania niejawnego podczas uruchamiania aplikacji, aby wykryć, czy telefon został zakorzeniony. Logika wykrywania może po prostu uzyskiwać dostęp do plików, do których zwykle tylko użytkownik główny może uzyskać dostęp, na przykład: /system/app/Superuser.apk /sbin/su /system/bin/su /system/xbin/su /data/local/xbin/su /data/local/bin/su /system/sd/xbin/su /system/bin/failsafe/su /data/local/su Jeśli aplikacja może uzyskać dostęp do dowolnego z tych plików, oznacza to, że aplikacja jest uruchomiona jako użytkownik główny.

Słabe odwołanie do klas w programie WCF

Tytuł	Szczegóły
Składnik	WCF
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólne, NET Framework 3
Atrybuty	Nie dotyczy
Dokumentacja	MSDN, Fortify Kingdom
Kroki	System używa słabego odwołania do klasy, co może umożliwić osobie atakującej wykonanie nieautoryzowanego kodu. Program odwołuje się do klasy zdefiniowanej przez użytkownika, która nie jest jednoznacznie identyfikowana. Gdy platforma .NET ładuje tę słabo zidentyfikowaną klasę, moduł ładujący CLR wyszukuje klasę w następujących lokalizacjach w określonej kolejności: Jeśli zestaw typu jest znany, moduł ładujący wyszukuje lokalizacje przekierowania pliku konfiguracji, GAC, bieżący zestaw przy użyciu informacji o konfiguracji i katalogu podstawowego aplikacji Jeśli zestaw jest nieznany, moduł ładujący wyszukuje bieżący zestaw, mscorlib i lokalizację zwracaną przez program obsługi zdarzeń TypeResolve Tę kolejność wyszukiwania CLR można modyfikować za pomocą punktów zaczepienia, takich jak mechanizm przekazywania typów i zdarzenie AppDomain.TypeResolve Jeśli osoba atakująca wykorzysta kolejność wyszukiwania CLR, tworząc alternatywną klasę o tej samej nazwie i umieszczając ją w alternatywnej lokalizacji, którą clR załaduje najpierw, clR przypadkowo wykona kod dostarczony przez osobę atakującą

Przykład

Element <behaviorExtensions/> poniższego pliku konfiguracji programu WCF instruuje program WCF, aby dodać niestandardową klasę zachowania do określonego rozszerzenia programu WCF.

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name=""myBehavior"" type=""MyBehavior"" />
        </behaviorExtensions>
    </extensions>
</system.serviceModel>

Użycie w pełni kwalifikowanych (silnych) nazw jednoznacznie identyfikuje typ i dodatkowo zwiększa bezpieczeństwo systemu. Użyj w pełni kwalifikowanych nazw zestawów podczas rejestrowania typów w plikach machine.config i app.config.

Przykład

Element <behaviorExtensions/> poniższego pliku konfiguracji programu WCF instruuje program WCF, aby dodać silnie przywołyną niestandardową klasę zachowania do określonego rozszerzenia WCF.

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name=""myBehavior"" type=""Microsoft.ServiceModel.Samples.MyBehaviorSection, MyBehavior,
            Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"" />
        </behaviorExtensions>
    </extensions>
</system.serviceModel>

WCF-Implement kontrolka autoryzacji

Tytuł	Szczegóły
Składnik	WCF
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólne, NET Framework 3
Atrybuty	Nie dotyczy
Dokumentacja	MSDN, Fortify Kingdom
Kroki	Ta usługa nie używa kontrolki autoryzacji. Gdy klient wywołuje określoną usługę WCF, program WCF udostępnia różne schematy autoryzacji, które sprawdzają, czy obiekt wywołujący ma uprawnienia do wykonywania metody usługi na serwerze. Jeśli kontrolki autoryzacji nie są włączone dla usług WCF, uwierzytelniony użytkownik może osiągnąć eskalację uprawnień.

Przykład

Poniższa konfiguracja powoduje, że program WCF nie sprawdza poziomu autoryzacji klienta podczas wykonywania usługi:

<behaviors>
    <serviceBehaviors>
        <behavior>
            ...
            <serviceAuthorization principalPermissionMode=""None"" />
        </behavior>
    </serviceBehaviors>
</behaviors>

Użyj schematu autoryzacji usługi, aby sprawdzić, czy obiekt wywołujący metody usługi jest autoryzowany do tego celu. Program WCF udostępnia dwa tryby i umożliwia definiowanie niestandardowego schematu autoryzacji. Tryb UseWindowsGroups używa ról systemu Windows i użytkowników, a tryb UseAspNetRoles używa dostawcy roli ASP.NET, takiego jak SQL Server, do uwierzytelniania.

Przykład

Poniższa konfiguracja instruuje usługę WCF, aby upewnić się, że klient jest częścią grupy Administratorzy przed wykonaniem polecenia Dodaj usługę:

<behaviors>
    <serviceBehaviors>
        <behavior>
            ...
            <serviceAuthorization principalPermissionMode=""UseWindowsGroups"" />
        </behavior>
    </serviceBehaviors>
</behaviors>

Usługa jest następnie zadeklarowana jako następująca:

[PrincipalPermission(SecurityAction.Demand,
Role = ""Builtin\\Administrators"")]
public double Add(double n1, double n2)
{
double result = n1 + n2;
return result;
}

Implementowanie odpowiedniego mechanizmu autoryzacji w interfejsie API sieci Web ASP.NET

Tytuł	Szczegóły
Składnik	Internetowy interfejs API
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólny, MVC5
Atrybuty	N/A, Dostawca tożsamości — ADFS, Dostawca tożsamości — Microsoft Entra ID
Dokumentacja	Uwierzytelnianie i autoryzacja w internetowym interfejsie API ASP.NET
Kroki	Informacje o rolach użytkowników aplikacji mogą pochodzić z oświadczeń microsoft Entra ID lub ADFS, jeśli aplikacja opiera się na nich jako dostawca tożsamości lub sama aplikacja może go dostarczyć. W każdym z tych przypadków implementacja autoryzacji niestandardowej powinna zweryfikować informacje o roli użytkownika. Informacje o rolach użytkowników aplikacji mogą pochodzić z oświadczeń microsoft Entra ID lub ADFS, jeśli aplikacja opiera się na nich jako dostawca tożsamości lub sama aplikacja może go dostarczyć. W każdym z tych przypadków implementacja autoryzacji niestandardowej powinna zweryfikować informacje o roli użytkownika.

Przykład

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple = true)]
public class ApiAuthorizeAttribute : System.Web.Http.AuthorizeAttribute
{
        public async override Task OnAuthorizationAsync(HttpActionContext actionContext, CancellationToken cancellationToken)
        {
            if (actionContext == null)
            {
                throw new Exception();
            }

            if (!string.IsNullOrEmpty(base.Roles))
            {
                bool isAuthorized = ValidateRoles(actionContext);
                if (!isAuthorized)
                {
                    HandleUnauthorizedRequest(actionContext);
                }
            }

            base.OnAuthorization(actionContext);
        }

public bool ValidateRoles(actionContext)
{
   //Authorization logic here; returns true or false
}

}

Wszystkie kontrolery i metody akcji, które muszą być chronione, powinny być ozdobione za pomocą powyższego atrybutu.

[ApiAuthorize]
public class CustomController : ApiController
{
     //Application code goes here
}

Przeprowadzanie kontroli autoryzacji na urządzeniu, jeśli obsługuje różne akcje wymagające różnych poziomów uprawnień

Tytuł	Szczegóły
Składnik	Urządzenie IoT
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Nie dotyczy
Kroki	Urządzenie powinno autoryzować obiekt wywołujący, aby sprawdzić, czy obiekt wywołujący ma wymagane uprawnienia do wykonania żądanej akcji. Załóżmy na przykład, że urządzenie jest blokadą smart door, którą można monitorować z chmury, a także udostępnia funkcje, takie jak zdalne blokowanie drzwi. Blokada smart door zapewnia funkcję odblokowywania tylko wtedy, gdy ktoś fizycznie przychodzi w pobliżu drzwi z kartą. W takim przypadku należy wykonać implementację zdalnego polecenia i kontroli w taki sposób, że nie zapewnia żadnych funkcji odblokowania drzwi, ponieważ brama w chmurze nie ma autoryzacji do wysyłania polecenia w celu odblokowania drzwi.

Przeprowadzanie kontroli autoryzacji w bramie field gateway, jeśli obsługuje różne akcje wymagające różnych poziomów uprawnień

Tytuł	Szczegóły
Składnik	Brama pola IoT
Faza SDL	Kompilacja
Odpowiednie technologie	Ogólna
Atrybuty	Nie dotyczy
Dokumentacja	Nie dotyczy
Kroki	Usługa Field Gateway powinna autoryzować obiekt wywołujący, aby sprawdzić, czy obiekt wywołujący ma wymagane uprawnienia do wykonania żądanej akcji. Na przykład powinny istnieć różne uprawnienia dla interfejsu użytkownika/interfejsu API administratora używanego do konfigurowania urządzeń bramy pola v/s, które się z nim łączą.