Delen via

Beveiligde toepassingen ontwikkelen in Azure

  • Artikel

In dit artikel worden beveiligingsactiviteiten en -besturingselementen beschreven waarmee u rekening moet houden wanneer u toepassingen voor de cloud ontwikkelt. Beveiligingsvragen en -concepten om rekening mee te houden 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 die u niet van plan was om te worden gebruikt. Dit helpt u te beschermen tegen onbedoeld of opzettelijk misbruik van uw toepassing.

Codebeoordelingen uitvoeren

Voordat u de code incheckt, voert u codebeoordelingen uit om de algehele kwaliteit van de code te verbeteren 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 uitgevoerd als onderdeel van een codebeoordeling. Analyse van statische code verwijst meestal naar het uitvoeren van hulpprogramma's voor het analyseren van statische code om potentiële beveiligingsproblemen in niet-actieve code te vinden. Statische codeanalyse maakt gebruik van technieken zoals taint-controle en gegevensstroomanalyse.

Azure Marketplace biedt ontwikkelhulpprogramma's die statische codeanalyse uitvoeren en helpen bij codebeoordelingen.

Elke invoer voor uw toepassing valideren en opschonen

Behandel alle invoer als niet-vertrouwd om uw toepassing te beschermen tegen de meest voorkomende beveiligingsproblemen in webtoepassingen. Niet-vertrouwde gegevens zijn een voertuig voor injectieaanvallen. Invoer voor uw toepassing omvat parameters in de URL, invoer van de gebruiker, gegevens uit de database of een API en alles wat wordt doorgegeven door een gebruiker. Een toepassing moet valideren dat gegevens syntactisch en semantisch geldig zijn voordat de toepassing de gegevens op welke manier dan ook gebruikt (inclusief het weergeven ervan aan de gebruiker).

Valideer invoer vroeg in de gegevensstroom om ervoor te zorgen dat alleen correct gevormde gegevens de werkstroom binnenkomen. U wilt niet dat onjuist ingedeelde gegevens in uw database blijven bestaan of een storing in een downstreamonderdeel activeren.

Blokkeren en toestaan zijn twee algemene benaderingen voor het uitvoeren van invoersyntaxisvalidatie:

  • Bij blokkeren wordt geprobeerd te controleren of een bepaalde gebruikersinvoer geen 'bekende schadelijke' inhoud bevat.

  • Met acceptatielijst wordt geprobeerd te controleren of een bepaalde gebruikersinvoer overeenkomt met een set 'bekende goede' invoerwaarden. Toestaan op basis van tekens is een vorm van acceptatielijst waarbij een toepassing controleert of gebruikersinvoer alleen 'bekende goede' tekens bevat of dat invoer overeenkomt met een bekende indeling.

    Dit kan bijvoorbeeld betekenen dat u controleert of een gebruikersnaam alleen alfanumerieke tekens bevat of dat deze precies 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 bedenken.

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 met een escape-code worden uitgevoerd. Escape, ook wel uitvoercodering genoemd, wordt gebruikt om ervoor te zorgen dat niet-vertrouwde gegevens geen middel zijn voor een injectieaanval. Escapeing, 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. Escape-bewerking laat de interpreter ook weten dat de gegevens niet bedoeld zijn om te worden uitgevoerd, waardoor aanvallen niet werken. Dit is een andere veelgebruikte aanvalstechniek, cross-site scripting (XSS) genoemd.

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 opneemt met de database

Maak nooit 'on-the-fly' een inlinedatabasequery in uw code en verzend deze rechtstreeks naar de database. Schadelijke code die in uw toepassing wordt 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 query's met parameters gebruikt, kunt u de procedure veilig aanroepen vanuit uw code en deze een tekenreeks 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. We raden u aan deze headers te onderdrukken om te voorkomen dat u vingerafdrukken van de toepassing moet maken. Zie Standaardserverheaders verwijderen op Azure-websites.

Uw productiegegevens scheiden

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

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

Een beleid voor sterk wachtwoord implementeren

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

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

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

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

Uploads van bestanden valideren

Als uw toepassing bestandsuploads toestaat, moet u de voorzorgsmaatregelen overwegen die u kunt nemen voor deze riskante activiteit. De eerste stap bij veel aanvallen is het binnenbrengen van schadelijke code in een systeem dat wordt aangevallen. Het gebruik van een bestandsupload helpt de aanvaller dit te bereiken. OWASP biedt oplossingen voor het valideren van een bestand om ervoor te zorgen dat het bestand dat u uploadt veilig is.

Antimalwarebeveiliging helpt bij het identificeren en verwijderen van virussen, spyware en andere schadelijke software. U kunt Microsoft Antimalware of de oplossing voor eindpuntbeveiliging van een Microsoft-partner (Trend Micro, Broadcom, McAfee, Microsoft Defender Antivirus in Windows en Endpoint Protection) installeren.

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

Gevoelige inhoud niet opslaan in de cache

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 naar deze pagina's opnieuw wordt verwezen, worden de pagina's uit de cache weergegeven in de browser. Als gevoelige informatie (adres, creditcardgegevens, burgerservicenummer, gebruikersnaam) wordt weergegeven voor de gebruiker, kan de informatie worden opgeslagen in de cache van de browser en kan deze worden opgehaald door de cache van de browser te bekijken of door op de knop Vorige van de browser te drukken.

Verificatie

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

Beveiligingsproblemen in uw toepassingsafhankelijkheden zoeken en oplossen

U scant uw toepassing en de bijbehorende 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

Dynamic Application Security Testing (DAST) is een proces voor het testen van een toepassing met 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, cross-site scripting, problemen met gebruikersbevoegdheden, SQL-injectie en andere kritieke beveiligingsproblemen.

DAST verschilt van statische toepassingsbeveiligingstests (SAST). 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 de hulp van een beveiligingsprofessional (een penetratietester of beoordelaar van beveiligingsproblemen). Als er geen beveiligingsprofessional beschikbaar is, kunt u DAST zelf uitvoeren met een webproxyscanner en enige training. Sluit in een vroeg stadium 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 in webtoepassingen.

Fuzz-tests uitvoeren

Bij fuzz-tests veroorzaakt u programmafouten door opzettelijk onjuiste of willekeurige gegevens in een toepassing te introduceren. Het veroorzaken van programmafouten helpt potentiële beveiligingsproblemen aan het licht te komen voordat de toepassing wordt uitgebracht.

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

Aanvalsoppervlakbeoordeling uitvoeren

Door de kwetsbaarheid voor aanvallen na het voltooien van de code te controleren, zorgt u ervoor dat eventuele ontwerp- of implementatiewijzigingen in een toepassing of systeem in overweging zijn genomen. Het helpt ervoor te zorgen dat eventuele nieuwe aanvalsvectoren die zijn gemaakt als gevolg van de wijzigingen, inclusief bedreigingsmodellen, zijn gecontroleerd en beperkt.

U kunt een afbeelding van het aanvalsoppervlak maken door de toepassing te scannen. Microsoft biedt een hulpprogramma voor analyse van aanvalsoppervlakken met de naam Attack Surface Analyzer. U kunt kiezen uit veel commerciële hulpprogramma's of services voor dynamisch testen en scannen van beveiligingsproblemen, waaronder OWASP Attack Surface Detector, Arachni en w3af. Met deze scanhulpprogramma's verkent u uw app en wijst u de onderdelen van de toepassing toe die toegankelijk zijn via het web. U kunt ook in 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 functionaliteit. Maak penetratietests een standaardonderdeel van het build- en implementatieproces. Plan regelmatige beveiligingstests en het scannen van beveiligingsproblemen op geïmplementeerde toepassingen en controleer op open poorten, eindpunten en aanvallen.

Beveiligingsverificatietests uitvoeren

Azure Tenant Security Solution (AzTS) uit de Secure DevOps Kit for Azure (AzSK) bevat SVT's voor meerdere services van het Azure-platform. U voert deze SVT's regelmatig uit om ervoor te zorgen dat uw Azure-abonnement en de verschillende resources waaruit uw toepassing bestaat, een veilige status hebben. U kunt deze tests ook automatiseren met behulp van de functie continue integratie/continue implementatie (CI/CD)-extensies van AzSK, waardoor SVT's beschikbaar zijn als een Visual Studio-extensie.

Volgende stappen

In de volgende artikelen raden we beveiligingscontroles en -activiteiten aan die u kunnen helpen bij het ontwerpen en implementeren van beveiligde toepassingen.