Beveiligde toepassingen ontwikkelen in Azure

In dit artikel presenteren we beveiligingsactiviteiten en besturingselementen die u kunt overwegen wanneer u toepassingen voor de cloud ontwikkelt. Beveiligingsvragen en concepten die u moet overwegen tijdens de implementatie- en verificatiefasen van de Microsoft Security Development Lifecycle (SDL) worden behandeld. Het doel is om u te helpen bij het definiëren van activiteiten en Azure-services die u kunt gebruiken om een veiligere toepassing te ontwikkelen.

In dit artikel worden de volgende SDL-fasen behandeld:

  • Implementatie
  • Verificatie

Implementatie

De focus van de implementatiefase is het vaststellen van best practices voor vroegtijdige preventie en het detecteren en verwijderen van beveiligingsproblemen uit de code. Stel dat uw toepassing wordt gebruikt op manieren waarop u deze niet wilde gebruiken. Dit helpt u te beschermen tegen onbedoeld of opzettelijk misbruik van uw toepassing.

Codebeoordelingen uitvoeren

Voordat u code incheckt, voert u codebeoordelingen uit om de algehele kwaliteit van de code te verhogen en het risico op het maken van fouten te verminderen. U kunt Visual Studio gebruiken om het codebeoordelingsproces te beheren.

Statische codeanalyse uitvoeren

Statische codeanalyse (ook wel broncodeanalyse genoemd) wordt meestal uitgevoerd als onderdeel van een codebeoordeling. Statische codeanalyse verwijst meestal naar het uitvoeren van hulpprogramma's voor statische codeanalyse om potentiële beveiligingsproblemen in niet-actieve code te vinden met behulp van technieken zoals taintcontrole en gegevensstroomanalyse.

Azure Marketplace biedt ontwikkelhulpprogramma's die statische codeanalyses uitvoeren en helpen met codebeoordelingen.

Elke invoer voor uw toepassing valideren en opschonen

Alle invoer behandelen als niet-vertrouwd om uw toepassing te beschermen tegen de meest voorkomende beveiligingsproblemen met webtoepassingen. Niet-vertrouwde gegevens zijn een voertuig voor injectieaanvallen. Invoer voor uw toepassing bevat parameters in de URL, invoer van de gebruiker, gegevens uit de database of van een API, en alles wat wordt doorgegeven door een gebruiker die mogelijk kan worden gemanipuleerd. Een toepassing moet valideren dat gegevens syntactisch en semantisch geldig zijn voordat de toepassing de gegevens op enigerlei wijze gebruikt (inclusief het weergeven van de gegevens naar de gebruiker).

Valideer de invoer vroeg in de gegevensstroom om ervoor te zorgen dat alleen correct gevormde gegevens de werkstroom invoeren. U wilt geen onjuiste gegevens behouden in uw database of een storing veroorzaken in een downstreamonderdeel.

Blokkeren en acceptatielijsten zijn twee algemene benaderingen voor het uitvoeren van validatie van de invoersyntaxis:

  • Het blokkeren van pogingen om te controleren of een bepaalde gebruikersinvoer geen inhoud bevat die 'schadelijk' is.

  • Toestaan van pogingen om te controleren of een bepaalde gebruikersinvoer overeenkomt met een set 'bekende goede' invoer. Toestaan op basis van tekens is een vorm van acceptatielijst waarbij een toepassing controleert of gebruikersinvoer alleen 'bekende goede' tekens bevat of die invoer overeenkomt met een bekende indeling.

    Dit kan bijvoorbeeld betekenen dat een gebruikersnaam alleen alfanumerieke tekens bevat of dat deze exact twee getallen bevat.

Allowlisting is de voorkeursbenadering voor het bouwen van beveiligde software. Blokkeren is gevoelig voor fouten omdat het onmogelijk is om een volledige lijst met mogelijk slechte invoer te zien.

Doe dit op de server, niet aan de clientzijde (of op de server en aan de clientzijde).

De uitvoer van uw toepassing controleren

Uitvoer die u visueel of in een document presenteert, moet altijd worden gecodeerd en ontsnapt. Ontsnappen, ook wel uitvoercodering genoemd, wordt gebruikt om ervoor te zorgen dat niet-vertrouwde gegevens geen voertuig zijn voor een injectieaanval. Ontsnappen, gecombineerd met gegevensvalidatie, biedt gelaagde verdediging om de beveiliging van het systeem als geheel te verbeteren.

Escapeing zorgt ervoor dat alles wordt weergegeven als uitvoer. Met escapen kan de interpreter ook weten dat de gegevens niet zijn bedoeld om te worden uitgevoerd en dat hiermee wordt voorkomen dat aanvallen werken. Dit is een andere veelgebruikte aanvalstechniek genaamd cross-site scripting (XSS).

Als u een webframework van een derde partij gebruikt, kunt u uw opties voor uitvoercodering op websites controleren met behulp van het cheatsheet voor OWASP XSS-preventie.

Geparameteriseerde query's gebruiken wanneer u contact op neemt met de database

Maak nooit 'direct' een inline-databasequery in uw code en verzend deze rechtstreeks naar de database. Schadelijke code die in uw toepassing is ingevoegd, kan ertoe leiden dat uw database wordt gestolen, gewist of gewijzigd. Uw toepassing kan ook worden gebruikt om schadelijke besturingssysteemopdrachten uit te voeren op het besturingssysteem dat als host fungeert voor uw database.

Gebruik in plaats daarvan geparameteriseerde query's of opgeslagen procedures. Wanneer u geparameteriseerde query's gebruikt, kunt u de procedure veilig aanroepen vanuit uw code en deze doorgeven zonder dat u zich zorgen hoeft te maken dat deze wordt behandeld als onderdeel van de query-instructie.

Standaardserverheaders verwijderen

Headers zoals Server, X-Powered-By en X-AspNet-version onthullen informatie over de server en onderliggende technologieën. U wordt aangeraden deze headers te onderdrukken om te voorkomen dat de toepassing wordt geprint. Zie het verwijderen van standaardserverheaders op Azure-websites.

Uw productiegegevens scheiden

Uw productiegegevens, of 'echte' gegevens, mogen niet worden gebruikt voor ontwikkeling, testen of een ander doel dan de bedoeling van het bedrijf. Er moet een gemaskeerde (geanonimiseerde) gegevensset worden gebruikt voor alle ontwikkeling en tests.

Dit betekent dat minder mensen toegang hebben tot uw echte gegevens, waardoor uw kwetsbaarheid voor aanvallen wordt verminderd. Het betekent ook dat minder werknemers persoonsgegevens zien, waardoor een mogelijke inbreuk op vertrouwelijkheid wordt geëlimineerd.

Een sterk wachtwoordbeleid implementeren

Als u zich wilt beschermen tegen brute-force en op woordenlijst gebaseerde schattingen, moet u een sterk wachtwoordbeleid implementeren om ervoor te zorgen dat gebruikers een complex wachtwoord maken (bijvoorbeeld de minimale lengte van 12 tekens en het vereisen van alfanumerieke en speciale tekens).

Azure Active Directory B2C helpt u bij wachtwoordbeheer door selfservice voor wachtwoordherstel te bieden, wachtwoordherstel af te dwingen en meer.

Als u zich wilt beschermen tegen aanvallen op standaardaccounts, controleert u of alle sleutels en wachtwoorden kunnen worden vervangen en of ze worden gegenereerd of vervangen nadat u resources hebt geïnstalleerd.

Als de toepassing wachtwoorden automatisch moet genereren, moet u ervoor zorgen dat de gegenereerde wachtwoorden willekeurig zijn en dat ze een hoge entropie hebben.

Bestandsuploads valideren

Als uw toepassing bestandsuploads toestaat, kunt u voorzorgsmaatregelen nemen voor deze riskante activiteit. De eerste stap bij veel aanvallen is het ophalen van schadelijke code in een systeem dat wordt aangevallen. Door een bestandsupload te gebruiken, kan de aanvaller dit doen. OWASP biedt oplossingen voor het valideren van een bestand om ervoor te zorgen dat het bestand dat u uploadt veilig is.

Antimalwarebeveiliging helpt virussen, spyware en andere schadelijke software te identificeren en te verwijderen. U kunt Microsoft Antimalware of de endpoint protection-oplossing van een Microsoft-partner (Trend Micro, Broadcom, McAfee, Windows Defender en Endpoint Protection) installeren.

Microsoft Antimalware bevat functies zoals realtime-beveiliging, gepland scannen, malwareherstel, handtekeningupdates, engine-updates, voorbeeldenrapportage en het verzamelen van uitsluitingsgebeurtenissen. U kunt Microsoft Antimalware en partneroplossingen integreren met Microsoft Defender for Cloud voor een eenvoudige implementatie en ingebouwde detecties (waarschuwingen en incidenten).

Gevoelige inhoud niet in de cache opslaan

Sla gevoelige inhoud niet op in de browser. Browsers kunnen informatie opslaan voor caching en geschiedenis. Bestanden in de cache worden opgeslagen in een map zoals de map Tijdelijke internetbestanden, in het geval van Internet Explorer. Wanneer deze pagina's opnieuw worden verwezen, worden de pagina's uit de cache weergegeven in de browser. Als gevoelige informatie (adres, creditcardgegevens, burgerservicenummer, gebruikersnaam) wordt weergegeven aan de gebruiker, worden de gegevens mogelijk opgeslagen in de cache van de browser en kunnen ze worden opgehaald door de cache van de browser te bekijken of door gewoon op de knop Terug van de browser te drukken.

Verificatie

De verificatiefase omvat een uitgebreide inspanning om ervoor te zorgen dat de code voldoet aan de beveiligings- en privacy-tenets die in de voorgaande fasen zijn vastgesteld.

Beveiligingsproblemen in uw toepassingsafhankelijkheden zoeken en oplossen

U scant uw toepassing en de afhankelijke bibliotheken om bekende kwetsbare onderdelen te identificeren. Producten die beschikbaar zijn om deze scan uit te voeren, zijn OWASP Dependency Check, Snyk en Black Duck.

Uw toepassing testen in een operationele status

DAST (Dynamic Application Security Testing) is een proces voor het testen van een toepassing in een operationele status om beveiligingsproblemen te vinden. DAST-hulpprogramma's analyseren programma's terwijl ze worden uitgevoerd om beveiligingsproblemen te vinden, zoals geheugenbeschadiging, onveilige serverconfiguratie, scripting op meerdere sites, problemen met gebruikersbevoegdheden, SQL-injectie en andere kritieke beveiligingsproblemen.

DAST verschilt van statische SAST (Application Security Testing). SAST-hulpprogramma's analyseren broncode of gecompileerde versies van code wanneer de code niet wordt uitgevoerd om beveiligingsfouten te vinden.

Voer DAST uit, bij voorkeur met hulp van een beveiligingsprofessional (een penetratietester of evaluatie van beveiligingsproblemen). Als een beveiligingsprofessional niet beschikbaar is, kunt u DAST zelf uitvoeren met een webproxyscanner en een training. Sluit vroeg een DAST-scanner aan om ervoor te zorgen dat u geen duidelijke beveiligingsproblemen in uw code introduceert. Zie de OWASP-site voor een lijst met scanners voor beveiligingsproblemen van webtoepassingen.

Fuzz-tests uitvoeren

Bij fuzz-tests veroorzaakt u een programmafout door opzettelijk onjuiste of willekeurige gegevens in een toepassing in te voeren. Het veroorzaken van een programmafout helpt potentiële beveiligingsproblemen te onthullen voordat de toepassing wordt uitgebracht.

Detectie van beveiligingsrisico's is de unieke fuzz-testservice van Microsoft voor het vinden van beveiligingskritieke fouten in software.

Beoordeling van kwetsbaarheid voor aanvallen uitvoeren

Door het kwetsbaarheid voor aanvallen te controleren nadat de code is voltooid, kunt u ervoor zorgen dat wijzigingen in het ontwerp of de implementatie van een toepassing of systeem worden overwogen. Het helpt ervoor te zorgen dat nieuwe aanvalsvectoren die zijn gemaakt als gevolg van de wijzigingen, inclusief bedreigingsmodellen, zijn beoordeeld en beperkt.

U kunt een afbeelding maken van het kwetsbaarheid voor aanvallen door de toepassing te scannen. Microsoft biedt een hulpprogramma voor analyse van kwetsbaarheid voor aanvallen met de naam Attack Surface Analyzer. U kunt kiezen uit veel commerciële dynamische tests en hulpprogramma's of services voor het scannen van beveiligingsproblemen, waaronder OWASP Zed Attack Proxy Project, Arachni, Skipfish en w3af. Met deze scanhulpprogramma's wordt uw app verkend en worden de onderdelen van de toepassing toegewezen die toegankelijk zijn via het web. U kunt ook de Azure Marketplace zoeken naar vergelijkbare ontwikkelhulpprogramma's.

Beveiligingspenetratietests uitvoeren

Ervoor zorgen dat uw toepassing veilig is, is net zo belangrijk als het testen van andere functies. Maak penetratietests een standaardonderdeel van het build- en implementatieproces. Plan regelmatige beveiligingstests en scannen op beveiligingsproblemen op geïmplementeerde toepassingen en controleer op open poorten, eindpunten en aanvallen.

Beveiligingsverificatietests uitvoeren

Secure DevOps Kit voor Azure (AzSK) bevat SVT's voor meerdere services van het Azure-platform. U voert deze SVT's periodiek uit om ervoor te zorgen dat uw Azure-abonnement en de verschillende resources die bestaan uit uw toepassing, zich in een veilige status bevinden. U kunt deze tests ook automatiseren met behulp van de functie voor ci/cd-extensies (continue integratie/continue implementatie) van AzSK, waardoor SVT's beschikbaar worden gemaakt als visual Studio-extensie.

Volgende stappen

In de volgende artikelen raden we beveiligingscontroles en activiteiten aan waarmee u veilige toepassingen kunt ontwerpen en implementeren.