Utveckla säkra program på Azure

  • Artikel

I den här artikeln presenterar vi säkerhetsaktiviteter och kontroller att tänka på när du utvecklar program för molnet. Säkerhetsfrågor och begrepp att tänka på under implementerings- och verifieringsfaserna i Microsoft Security Development Lifecycle (SDL) beskrivs. Målet är att hjälpa dig att definiera aktiviteter och Azure-tjänster som du kan använda för att utveckla ett säkrare program.

Följande SDL-faser beskrivs i den här artikeln:

  • Implementering
  • Verifiering

Implementering

Fokus i implementeringsfasen är att upprätta metodtips för tidigt förebyggande och att identifiera och ta bort säkerhetsproblem från koden. Anta att ditt program används på sätt som du inte hade för avsikt att använda det. På så sätt kan du skydda dig mot oavsiktligt eller avsiktligt missbruk av ditt program.

Utföra kodgranskningar

Innan du checkar in kod ska du göra kodgranskningar för att öka den övergripande kodkvaliteten och minska risken för att skapa buggar. Du kan använda Visual Studio för att hantera kodgranskningsprocessen.

Utföra analys av statisk kod

Statisk kodanalys (kallas även källkodsanalys) utförs som en del av en kodgranskning. Analys av statisk kod syftar ofta på att köra analysverktyg för statisk kod för att hitta potentiella sårbarheter i kod som inte körs. Statisk kodanalys använder tekniker som taint-kontroll och dataflödesanalys.

Azure Marketplace erbjuder utvecklarverktyg som utför statisk kodanalys och hjälper till med kodgranskningar.

Verifiera och rensa alla indata för ditt program

Behandla alla indata som ej betrodda för att skydda ditt program från de vanligaste säkerhetsriskerna för webbprogram. Obetrodda data är ett verktyg för injektionsattacker. Indata för ditt program innehåller parametrar i URL:en, indata från användaren, data från databasen eller från ett API och allt som skickas in som en användare kan manipulera. Ett program bör verifiera att data är syntaktiskt och semantiskt giltiga innan programmet använder data på något sätt (inklusive att visa dem för användaren igen).

Verifiera indata tidigt i dataflödet för att säkerställa att endast korrekt utformade data kommer in i arbetsflödet. Du vill inte att felaktiga data ska bevaras i databasen eller utlösa fel i en underordnad komponent.

Blocklistning och allowlisting är två allmänna metoder för att utföra validering av indatasyntax:

  • Blocklistning försöker kontrollera att en viss användarindata inte innehåller "skadligt" innehåll.

  • Allowlisting försöker kontrollera att en viss användarindata matchar en uppsättning "kända bra" indata. Teckenbaserad allowlisting är en form av allowlisting där ett program kontrollerar att användarindata endast innehåller "kända bra" tecken eller att indata matchar ett känt format.

    Detta kan till exempel innebära att kontrollera att ett användarnamn endast innehåller alfanumeriska tecken eller att det innehåller exakt två tal.

Allowlisting är den bästa metoden för att skapa säker programvara. Blocklistning är felbenägen eftersom det är omöjligt att komma på en fullständig lista över potentiellt felaktiga indata.

Detta fungerar på servern, inte på klientsidan (eller på servern och på klientsidan).

Kontrollera programmets utdata

Alla utdata som du visar antingen visuellt eller i ett dokument ska alltid kodas och undantagas. Escapeing, även kallat utdatakodning, används för att säkerställa att ej betrodda data inte är ett fordon för en injektionsattack. Undantag, i kombination med dataverifiering, ger skydd på flera nivåer för att öka säkerheten för systemet som helhet.

Escapeing ser till att allt visas som utdata. Escapeing gör också att tolken vet att data inte är avsedda att köras, och detta förhindrar att attacker fungerar. Det här är en annan vanlig attackteknik som kallas XSS ( Cross-Site Scripting ).

Om du använder ett webbramverk från en tredje part kan du kontrollera dina alternativ för utdatakodning på webbplatser med hjälp av OWASP XSS-förebyggande lathund.

Använda parametriserade frågor när du kontaktar databasen

Skapa aldrig en infogad databasfråga "i farten" i koden och skicka den direkt till databasen. Skadlig kod som infogas i programmet kan göra att databasen blir stulen, rensad eller ändrad. Programmet kan också användas för att köra skadliga operativsystemkommandon på det operativsystem som är värd för databasen.

Använd i stället parametriserade frågor eller lagrade procedurer. När du använder parametriserade frågor kan du anropa proceduren från koden på ett säkert sätt och skicka en sträng utan att oroa dig för att den ska behandlas som en del av frågeinstrukeringen.

Ta bort standardserverhuvuden

Rubriker som Server, X-Powered-By och X-AspNet-Version visar information om servern och underliggande tekniker. Vi rekommenderar att du utelämnar dessa huvuden för att undvika att programmet får fingeravtryck. Se ta bort standardserverhuvuden på Azure-webbplatser.

Särskilja dina produktionsdata

Dina produktionsdata, eller "verkliga" data, bör inte användas för utveckling, testning eller något annat syfte än vad företaget avsåg. En maskerad (anonymiserad) datauppsättning ska användas för all utveckling och testning.

Det innebär att färre personer har åtkomst till dina verkliga data, vilket minskar din attackyta. Det innebär också att färre anställda ser personuppgifter, vilket eliminerar ett potentiellt intrång i konfidentialiteten.

Implementera en princip för starkt lösenord

För att skydda mot råstyrkeattacker och ordlistebaserade gissningar måste du implementera en stark lösenordsprincip för att säkerställa att användarna skapar ett komplext lösenord (till exempel 12 tecken med minsta längd och kräver alfanumeriska tecken och specialtecken).

Azure Active Directory B2C hjälper dig med lösenordshantering genom att tillhandahålla lösenordsåterställning via självbetjäning, framtvinga återställning av lösenord med mera.

Om du vill skydda dig mot attacker på standardkonton kontrollerar du att alla nycklar och lösenord kan ersättas och att de genereras eller ersätts när du har installerat resurserna.

Om programmet måste generera lösenord automatiskt kontrollerar du att de genererade lösenorden är slumpmässiga och att de har hög entropy.

Verifiera filuppladdningar

Om ditt program tillåter filuppladdningar bör du överväga försiktighetsåtgärder som du kan vidta för den här riskfyllda aktiviteten. Det första steget i många attacker är att få in skadlig kod i ett system som är under attack. Genom att använda en filuppladdning kan angriparen åstadkomma detta. OWASP erbjuder lösningar för att verifiera en fil för att säkerställa att filen du laddar upp är säker.

Skydd mot skadlig kod hjälper till att identifiera och ta bort virus, spionprogram och annan skadlig programvara. Du kan installera Microsoft Antimalware eller en Microsoft-partners slutpunktsskyddslösning (Trend Micro, Broadcom, McAfee, Microsoft Defender Antivirus i Windows och Endpoint Protection).

Microsoft Antimalware innehåller funktioner som realtidsskydd, schemalagd genomsökning, reparation av skadlig kod, signaturuppdateringar, motoruppdateringar, exempelrapportering och insamling av undantagshändelser. Du kan integrera Microsoft Antimalware- och partnerlösningar med Microsoft Defender för molnet för enkel distribution och inbyggda identifieringar (aviseringar och incidenter).

Cachelagrade inte känsligt innehåll

Cachelagrade inte känsligt innehåll i webbläsaren. Webbläsare kan lagra information för cachelagring och historik. Cachelagrade filer lagras i en mapp som mappen Temporära Internetfiler, när det gäller Internet Explorer. När dessa sidor refereras till igen visar webbläsaren sidorna från cacheminnet. Om känslig information (adress, kreditkortsinformation, personnummer, användarnamn) visas för användaren kan informationen lagras i webbläsarens cacheminne och kunna hämtas genom att undersöka webbläsarens cacheminne eller genom att trycka på webbläsarens bakåtknapp .

Verifiering

Verifieringsfasen omfattar ett omfattande arbete för att säkerställa att koden uppfyller de säkerhets- och sekretessinställningar som fastställdes i föregående faser.

Hitta och åtgärda sårbarheter i dina programberoenden

Du genomsöker ditt program och dess beroende bibliotek för att identifiera kända sårbara komponenter. Produkter som är tillgängliga för att utföra den här genomsökningen inkluderar OWASP Dependency Check, Snyk och Black Duck.

Testa programmet i ett driftstillstånd

DAST (Dynamic Application Security Testing) är en process för att testa ett program i ett driftstillstånd för att hitta säkerhetsrisker. DAST-verktyg analyserar program medan de körs för att hitta säkerhetsproblem som minnesskada, osäker serverkonfiguration, skriptkörning mellan webbplatser, problem med användarbehörigheter, SQL-inmatning och andra kritiska säkerhetsproblem.

DAST skiljer sig från säkerhetstestning av statiska program (SAST). SAST-verktyg analyserar källkod eller kompilerade versioner av kod när koden inte körs för att hitta säkerhetsbrister.

Utför DAST, helst med hjälp av en säkerhetspersonal (en intrångstestare eller sårbarhetsbedömare). Om en säkerhetstekniker inte är tillgänglig kan du utföra DAST själv med en webbproxyskanner och viss utbildning. Anslut en DAST-skanner tidigt för att säkerställa att du inte inför uppenbara säkerhetsproblem i koden. En lista över sårbarhetsskannrar för webbprogram finns på OWASP-webbplatsen .

Utföra fuzz-testning

Vid fuzz-testning inducerar du programfel genom att avsiktligt introducera felaktiga eller slumpmässiga data i ett program. Att inducera programfel hjälper till att avslöja potentiella säkerhetsproblem innan programmet släpps.

Säkerhetsriskidentifiering är Microsofts unika fuzz-testtjänst för att hitta säkerhetskritiska buggar i programvara.

Granska attackytan

Genom att granska attackytan efter att koden har slutförts kan du se till att eventuella design- eller implementeringsändringar i ett program eller system har övervägts. Det hjälper till att säkerställa att alla nya attackvektorer som har skapats till följd av ändringarna, inklusive hotmodeller, har granskats och åtgärdats.

Du kan skapa en bild av attackytan genom att skanna programmet. Microsoft erbjuder ett analysverktyg för attackytan som kallas Attack Surface Analyzer. Du kan välja bland många kommersiella verktyg eller tjänster för dynamisk testning och sårbarhetsskanning, inklusive OWASP Attack Surface Detector, Arachni och w3af. Dessa genomsökningsverktyg crawlar din app och mappar de delar av programmet som är tillgängliga via webben. Du kan också söka i Azure Marketplace efter liknande utvecklarverktyg.

Utföra intrångstester för säkerhet

Att se till att ditt program är säkert är lika viktigt som att testa andra funktioner. Gör intrångstestning till en standarddel av bygg- och distributionsprocessen. Schemalägg regelbundna säkerhetstester och sårbarhetsgenomsökning i distribuerade program och övervaka öppna portar, slutpunkter och attacker.

Köra säkerhetsverifieringstester

Azure Tenant Security Solution (AzTS) från Secure DevOps Kit for Azure (AzSK) innehåller SVT:er för flera tjänster på Azure-plattformen. Du kör dessa SVT:er regelbundet för att säkerställa att din Azure-prenumeration och de olika resurser som ingår i ditt program är i ett säkert tillstånd. Du kan också automatisera dessa tester med hjälp av ci/CD-tilläggsfunktionen (continuous integration/continuous deployment) i AzSK, vilket gör SVT:er tillgängliga som ett Visual Studio-tillägg.

Nästa steg

I följande artiklar rekommenderar vi säkerhetskontroller och aktiviteter som kan hjälpa dig att utforma och distribuera säkra program.