Säkerhetsram: Auktorisering | Mitigations

• Se till att rätt ACL:er är konfigurerade för att begränsa obehörig åtkomst till data på enheten
• Se till att känsligt användarspecifikt programinnehåll lagras i användarprofilkatalogen
• Se till att de distribuerade programmen körs med minsta möjliga behörighet

• Framtvinga sekventiell stegordning vid bearbetning av affärslogikflöden
• Implementera hastighetsbegränsningsmekanism för att förhindra uppräkning
• Se till att rätt auktorisering finns på plats och att principen om lägsta behörighet följs
• Beslut om auktorisering av affärslogik och resursåtkomst bör inte baseras på parametrar för inkommande begäran
• Se till att innehåll och resurser inte kan räknas upp eller vara tillgängliga via kraftfull bläddring

• Se till att minst privilegierade konton används för att ansluta till databasservern
• Implementera säkerhet på radnivå RLS för att förhindra att klienter kommer åt varandras data
• Sysadmin-rollen bör endast ha giltiga nödvändiga användare

• Ansluta till Cloud Gateway med hjälp av token med minst privilegier

• Använda en SAS-nyckel för endast sändningsbehörigheter för att generera enhetstoken
• Använd inte åtkomsttoken som ger direkt åtkomst till händelsehubben
• Anslut till händelsehubben med hjälp av SAS-nycklar som har de minsta behörigheter som krävs

• Använd resurstoken för att ansluta till Azure Cosmos DB när det är möjligt

• Aktivera detaljerad åtkomsthantering till Azure-prenumeration med hjälp av Azure RBAC

• Begränsa klientens åtkomst till klusteråtgärder med hjälp av Azure RBAC

• Utför säkerhetsmodellering och använd säkerhet på fältnivå där det behövs

• Utför säkerhetsmodellering av portalkonton med tanke på att säkerhetsmodellen för portalen skiljer sig från resten av CRM

• Bevilja detaljerad behörighet för en rad entiteter i Azure Table Storage
• Aktivera rollbaserad åtkomstkontroll i Azure (Azure RBAC) för Azure Storage-konto med hjälp av Azure Resource Manager

• Implementera implicit jailbreak eller rooting-identifiering

• Svag klassreferens i WCF
• WCF-Implement Behörighetsstyrning

• Implementera rätt auktoriseringsmekanism i ASP.NET webb-API

• Utför auktoriseringskontroller i enheten om den stöder olika åtgärder som kräver olika behörighetsnivåer

• Utför auktoriseringskontroller i Field Gateway om den stöder olika åtgärder som kräver olika behörighetsnivåer

Principen innebär att ett användarkonto endast ges de privilegier som är nödvändiga för att användaren ska fungera. En användare av säkerhetskopior behöver till exempel inte installera programvara: därför har användaren endast behörighet att köra program för säkerhetskopiering och säkerhetskopiering. Alla andra privilegier, till exempel installation av ny programvara, blockeras. Principen gäller även för en persondatoranvändare som vanligtvis arbetar med ett vanligt användarkonto och öppnar ett privilegierat, lösenordsskyddat konto (det vill säga en superanvändare) endast när situationen absolut kräver det.

Denna princip kan också tillämpas på dina webbapplikationer. I stället för att enbart förlita oss på rollbaserade autentiseringsmetoder med hjälp av sessioner, vill vi snarare tilldela behörigheter till användare med hjälp av ett Database-Based autentiseringssystem. Vi använder fortfarande sessioner för att identifiera om användaren var korrekt inloggad, men nu istället för att tilldela den användaren en specifik roll tilldelar vi honom privilegier för att verifiera vilka åtgärder han har behörighet att utföra i systemet. En stor fördel med den här metoden är också att när en användare måste tilldelas färre privilegier kommer dina ändringar att tillämpas i farten eftersom tilldelningen inte beror på sessionen som annars måste löpa ut först.

Känsliga statiska filer och konfigurationsfiler bör inte sparas i webbroten. För innehåll som inte behöver vara offentligt bör antingen lämpliga åtkomstkontroller tillämpas eller själva innehållet tas bort.

Dessutom kombineras kraftfull surfning vanligtvis med Brute Force-tekniker för att samla in information genom att försöka komma åt så många webbadresser som möjligt för att räkna upp kataloger och filer på en server. Angripare kan söka efter alla varianter av vanligt förekommande filer. En lösenordsfilsökning skulle till exempel omfatta filer som innehåller psswd.txt, password.htm, password.dat och andra varianter.

För att åtgärda detta bör funktioner för identifiering av brute force-försök inkluderas.

Row-Level Security gör det möjligt för kunder att styra åtkomsten till rader i en databastabell baserat på egenskaperna hos den användare som kör en fråga (t.ex. gruppmedlemskap eller körningskontext).

Row-Level Security (RLS) förenklar design och kodning av säkerhet i din applikation. Med RLS kan du implementera begränsningar för dataradsåtkomst. Du kan till exempel se till att anställda endast kan komma åt de datarader som är relevanta för deras avdelning, eller begränsa en kunds dataåtkomst till endast de data som är relevanta för företaget.

Logiken för åtkomstbegränsning finns på databasnivån i stället för från data på en annan programnivå. Databassystemet tillämpar åtkomstbegränsningarna varje gång dataåtkomst görs från valfri nivå. Detta gör säkerhetssystemet mer tillförlitligt och robust genom att minska säkerhetssystemets yta.

Azure Service Fabric stöder två olika typer av åtkomstkontroll för klienter som är anslutna till ett Service Fabric-kluster: administratör och användare. Med åtkomstkontroll kan klusteradministratören begränsa åtkomsten till vissa klusteråtgärder för olika användargrupper, vilket gör klustret säkrare.

Administratörer har fullständig åtkomst till hanteringsfunktioner (inklusive läs-/skrivfunktioner). Användare har som standard bara läsbehörighet till hanteringsfunktioner (till exempel frågefunktioner) och möjlighet att matcha program och tjänster.

Du anger de två klientrollerna (administratör och klient) när klustret skapas genom att ange separata certifikat för var och en.

När du skapar ett nytt lagringskonto väljer du en distributionsmodell för klassisk eller Azure Resource Manager. Den klassiska modellen för att skapa resurser i Azure tillåter endast allt-eller-inget-åtkomst till prenumerationen och i sin tur lagringskontot.

Med Azure Resource Manager-modellen placerar du lagringskontot i en resursgrupp och styr åtkomsten till hanteringsplanet för det specifika lagringskontot med hjälp av Microsoft Entra-ID. Du kan till exempel ge specifika användare möjlighet att komma åt lagringskontonycklarna, medan andra användare kan visa information om lagringskontot, men inte komma åt lagringskontonycklarna.

Applikationen bör skydda sin egen konfiguration och användardata i händelse av att telefonen är rotad eller jailbreakad. Rooting/jail breaking innebär obehörig åtkomst, vilket vanliga användare inte gör på sina egna telefoner. Därför bör programmet ha implicit identifieringslogik vid programstart för att identifiera om telefonen har rotats.

Detekteringslogiken kan helt enkelt vara att komma åt filer som normalt bara root-användare kan komma åt, till exempel:

• /system/app/Superuser.apk
• /sbin/su
• /system/bin/su
• /system/xbin/su
• /data/lokal/xbin/su
• /data/lokal/bin/su
• /system/sd/xbin/su
• /system/bin/failsafe/su
• /data/lokalt/su

Om programmet kan komma åt någon av dessa filer anger det att programmet körs som root-användare.

Systemet använder en svag klassreferens, vilket kan göra det möjligt för en angripare att köra obehörig kod. Programmet refererar till en användardefinierad klass som inte är unikt identifierad. När .NET läser in den här svagt identifierade klassen söker CLR-typinläsaren efter klassen på följande platser i angiven ordning:

1. Om sammansättningen av typen är känd söker inläsaren igenom konfigurationsfilens omdirigeringsplatser, GAC, den aktuella sammansättningen med hjälp av konfigurationsinformation och programmets baskatalog
2. Om sammansättningen är okänd söker inläsaren igenom den aktuella sammansättningen, mscorlib och den plats som returneras av TypeResolve-händelsehanteraren
3. Den här CLR-sökordningen kan ändras med krokar som mekanismen för vidarebefordran av typ och händelsen AppDomain.TypeResolve

Om en angripare utnyttjar CLR-sökordningen genom att skapa en alternativ klass med samma namn och placera den på en alternativ plats som CLR kommer att läsa in först, kommer CLR oavsiktligt att köra den kod som angriparen tillhandahåller

Den här tjänsten använder inte en auktoriseringskontroll. När en klient anropar en viss WCF-tjänst tillhandahåller WCF olika auktoriseringsscheman som verifierar att anroparen har behörighet att köra tjänstmetoden på servern. Om auktoriseringskontroller inte är aktiverade för WCF-tjänster kan en autentiserad användare uppnå behörighetseskalering.

Rollinformation för programanvändare kan härledas från Microsoft Entra ID- eller ADFS-anspråk om programmet förlitar sig på dem som identitetsprovider eller om själva programmet kan tillhandahålla det. I något av dessa fall bör den anpassade auktoriseringsimplementeringen verifiera informationen om användarrollen.

Rollinformation för programanvändare kan härledas från Microsoft Entra ID- eller ADFS-anspråk om programmet förlitar sig på dem som identitetsprovider eller om själva programmet kan tillhandahålla det. I något av dessa fall bör den anpassade auktoriseringsimplementeringen verifiera informationen om användarrollen.

Enheten bör ge uppringaren behörighet att kontrollera om uppringaren har de behörigheter som krävs för att utföra den begärda åtgärden. Låt oss t.ex. säga att enheten är ett smart dörrlås som kan övervakas från molnet, plus att det tillhandahåller funktioner som fjärrlåsning av dörren.

Det smarta dörrlåset ger endast upplåsningsfunktion när någon fysiskt kommer nära dörren med ett kort. I det här fallet bör implementeringen av fjärrkommandot och kontrollen göras på ett sådant sätt att den inte tillhandahåller någon funktion för att låsa upp dörren eftersom molngatewayen inte har behörighet att skicka ett kommando för att låsa upp dörren.