Dela via

Öka programsäkerheten med hjälp av Nulta pouzdanost principer

  • Artikel

En säker nätverksperimeter runt de program som utvecklas kan inte antas. Nästan alla utvecklade program kommer avsiktligt att nås utanför nätverksperimetern. Program kan inte garanteras vara säkra när de utvecklas eller förblir det när de har distribuerats. Det är programutvecklarens ansvar att inte bara maximera programmets säkerhet, utan även minimera den skada som programmet kan orsaka om det komprometteras.

Dessutom omfattar ansvaret att stödja kundernas och användarnas växande behov, som förväntar sig att programmet uppfyller Nulta pouzdanost säkerhetskrav. Lär dig principerna för Nulta pouzdanost modellen och anta metoderna. Genom att lära sig och anta principerna kan program utvecklas som är säkrare och som minimerar de skador de kan orsaka om säkerheten bryts.

Den Nulta pouzdanost modellen föreskriver en kultur av explicit verifiering snarare än implicit förtroende. Modellen är förankrad i tre viktiga vägledande principer:

  • Verifiera explicit
  • Använd minst privilegierad åtkomst
  • Anta intrång

Nulta pouzdanost bästa praxis

Följ dessa metodtips för att skapa Nulta pouzdanost-redo program med Microsoft platforma za identitete och dess verktyg.

Verifiera explicit

Microsoft platforma za identitete erbjuder autentiseringsmekanismer för att verifiera identiteten för den person eller tjänst som har åtkomst till en resurs. Använd de metodtips som beskrivs nedan för att uttryckligen verifiera alla entiteter som behöver komma åt data eller resurser.

Bästa metod Fördelar med programsäkerhet
Använd Microsoft Authentication Libraries (MSAL). MSAL är en uppsättning Microsoft-autentiseringsbibliotek för utvecklare. Med MSAL kan användare och program autentiseras och token kan hämtas för att få åtkomst till företagsresurser med bara några rader kod. MSAL använder moderna protokoll (OpenID Connect och OAuth 2.0) som tar bort behovet av att program någonsin hanterar en användares autentiseringsuppgifter direkt. Den här hanteringen av autentiseringsuppgifter förbättrar säkerheten för både användare och program avsevärt när identitetsprovidern blir säkerhetsperimetern. Dessutom utvecklas dessa protokoll kontinuerligt för att hantera nya paradigm, möjligheter och utmaningar inom identitetssäkerhet.
Anta utökade säkerhetstillägg som Utvärdering av kontinuerlig åtkomst (CAE) och autentiseringskontext för villkorsstyrd åtkomst när det är lämpligt. I Microsoft Entra-ID är några av de mest använda tilläggen villkorlig åtkomst, autentiseringskontext för villkorsstyrd åtkomst och CAE. Program som använder förbättrade säkerhetsfunktioner som CAE och autentiseringskontext för villkorsstyrd åtkomst måste kodas för att hantera anspråksutmaningar. Öppna protokoll gör att anspråksutmaningarna och anspråksbegäranden kan användas för att anropa extra klientfunktioner. Funktionerna kan vara att fortsätta interaktionen med Microsoft Entra-ID, till exempel när det fanns en avvikelse eller om användarautentiseringsvillkoren ändras. Dessa tillägg kan kodas till ett program utan att störa de primära kodflödena för autentisering.
Använd rätt autentiseringsflöde efter programtyp. Försök alltid använda konfidentiella klientflöden för webbprogram. För mobila program kan du försöka använda koordinatorer eller systemwebbläsaren för autentisering. Flöden för webbprogram som kan innehålla en hemlighet (konfidentiella klienter) anses vara säkrare än offentliga klienter (till exempel skrivbords- och konsolprogram). När systemwebbläsaren används för att autentisera ett mobilprogram möjliggör en säker enkel inloggning (SSO) användning av programskyddsprinciper.

Använd minst privilegierad åtkomst

En utvecklare använder Microsoft platforma za identitete för att bevilja behörigheter (omfång) och kontrollera att en anropare har beviljats rätt behörighet innan åtkomst tillåts. Framtvinga minst privilegierad åtkomst i program genom att aktivera detaljerade behörigheter som tillåter att den minsta mängd åtkomst som krävs beviljas. Tänk på följande metoder för att se till att principen om lägsta behörighet följs:

  • Utvärdera de behörigheter som begärs för att se till att det absolut minst privilegierade är inställt för att få jobbet gjort. Skapa inte "catch-all"-behörigheter med åtkomst till hela API-ytan.
  • När du utformar API:er ger du detaljerade behörigheter för att tillåta åtkomst med minst privilegier. Börja med att dela upp funktioner och dataåtkomst i avsnitt som kan styras med hjälp av omfång och approller. Lägg inte till API:er i befintliga behörigheter på ett sätt som ändrar behörighetens semantik.
  • Erbjud skrivskyddade behörigheter. Write åtkomst, innehåller behörigheter för att skapa, uppdatera och ta bort åtgärder. En klient ska aldrig kräva skrivåtkomst till endast läsdata.
  • Erbjud både delegerade behörigheter och programbehörigheter . Om du hoppar över programbehörigheter kan det skapa hårda krav för klienter att uppnå vanliga scenarier som automatisering, mikrotjänster med mera.
  • Överväg "standard" och "fullständig" åtkomstbehörighet om du arbetar med känsliga data. Begränsa de känsliga egenskaperna så att de inte kan nås med hjälp av en "standard"-åtkomstbehörighet, till exempel Resource.Read. Och implementera sedan en "fullständig" åtkomstbehörighet, till exempel Resource.ReadFull som returnerar alla tillgängliga egenskaper, inklusive känslig information.

Anta intrång

Den Microsoft platforma za identitete programregistreringsportalen är den primära startpunkten för program som tänker använda plattformen för autentisering och tillhörande behov. När du registrerar och konfigurerar program följer du de metoder som beskrivs nedan för att minimera den skada de kan orsaka om det uppstår en säkerhetsöverträdelse. Mer information finns i Metodtips för säkerhet för Microsoft Entra-programregistrering.

Överväg följande åtgärder för att förhindra säkerhetsöverträdelser:

  • Definiera omdirigerings-URI:er för programmet korrekt. Använd inte samma programregistrering för flera program.
  • Verifiera omdirigerings-URI:er som används i programregistreringen för ägarskap och för att undvika domänövertaganden. Skapa inte programmet som en multitenant om det inte är avsett att vara det. |
  • Kontrollera att ägare av program och tjänstens huvudnamn alltid har definierats och underhålls för de program som registrerats i klientorganisationen.

Se även