Veilige 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:

  • Implementation
  • Verification

Implementation

De implementatiefase richt zich op het vaststellen van best practices voor vroege 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 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-uitgevoerde code te vinden. Statische codeanalyse maakt gebruik van technieken zoals taint-controle en gegevensstroomanalyse.

Azure Marketplace biedt ontwikkelhulpprogramma's die statische codeanalyses 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 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 dat een gebruiker mogelijk kan manipuleren. Een toepassing moet valideren dat gegevens syntactisch en semantisch geldig zijn voordat de toepassing de gegevens op elke manier gebruikt (inclusief het weergeven ervan aan de gebruiker).

Valideer de invoer vroeg in de gegevensstroom om ervoor te zorgen dat alleen correct gevormde gegevens de werkstroom binnenkomen. U wilt geen misvormde gegevens in uw database hebben of een storing veroorzaken in een onderliggend onderdeel.

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

  • Bij het blokkeren van een lijst wordt gecontroleerd of een bepaalde gebruikersinvoer geen 'bekende schadelijke' inhoud bevat.

  • Allowlist controleert of een bepaalde gebruikersinvoer overeenkomt met een set 'bekende, geldige' 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. Blokkeringslijsten zijn gevoelig voor fouten omdat het onmogelijk is een volledige lijst van mogelijk slechte invoer op te stellen.

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

De uitvoer van uw toepassing controleren

Alle uitvoer die u visueel of in een document presenteert, moet altijd worden gecodeerd en geëscaped. Escapen, ook wel uitvoercodering genoemd, wordt gebruikt om ervoor te zorgen dat niet-vertrouwde data niet wordt gebruikt voor een injectieaanval. Ontsnappen, gecombineerd met gegevensvalidatie, biedt gelaagde verdediging om de beveiliging van het systeem als geheel te verbeteren.

Escapen zorgt ervoor dat alles wordt weergegeven als uitvoer. Bij het escapen wordt de interpreter ook geïnformeerd dat de gegevens niet bedoeld zijn om te worden uitgevoerd, en dit voorkomt dat aanvallen slagen. Dit is een andere veelgebruikte aanvalstechniek, 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 'onderweg' 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 informatie over de server en onderliggende technologieën onthullen. Wij raden aan om deze headers te verbergen om vingerafdrukken van de toepassing te voorkomen. Zie het verwijderen van standaardserverheaders op Azure-websites.

Productiegegevens segmenteert

Uw productiegegevens, of echte gegevens, mogen niet worden gebruikt voor ontwikkeling, testen of een ander doel dan wat het bedrijf bedoelde. Een gemaskeerde (geanonimiseerde) gegevensset moet worden gebruikt voor alle ontwikkeling en testen.

Dit betekent dat minder mensen toegang hebben tot uw echte gegevens, waardoor uw kwetsbaarheid voor aanvallen wordt verminderd. Het betekent ook dat minder werknemers persoonlijke gegevens 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 minimaal 12 tekens en alfanumerieke en speciale tekens vereisen).

Externe identificatie van Microsoft Entra in externe tenants helpt u bij het beheer van wachtwoorden door zelfservices voor wachtwoordherstel en meer te bieden.

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 bereiken. OWASP biedt oplossingen voor het valideren van een bestand om ervoor te zorgen dat het bestand dat u uploadt veilig is.

Bescherming tegen malware helpt virussen, spyware en andere schadelijke software te identificeren en te verwijderen. U kunt Microsoft Antimalware of de eindpuntbeveiligingsoplossing van een Microsoft-partner installeren (Trend Micro, Broadcom, McAfee, Microsoft Defender Antivirus in Windows en Endpoint Protection).

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 voor Cloud voor eenvoudige implementatie en ingebouwde detecties (waarschuwingen en incidenten).

Gevoelige inhoud niet in de cache opslaan

Sla gevoelige inhoud niet in de cache 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 wordt verwezen, worden de pagina's uit de cache weergegeven in de browser. Als gevoelige informatie (adres, creditcardgegevens, burgerservicenummer, gebruikersnaam) wordt weergegeven aan de gebruiker, kunnen de gegevens worden opgeslagen in de cache van de browser en kunnen ze worden opgehaald door de cache van de browser te bekijken of door op de knop Terug van de browser te drukken.

Verification

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

Dynamic Application Security Testing (DAST) 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 beschadiging van het geheugen, onveilige serverconfiguratie, cross-site scripting, 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 een DAST-scanner vroeg 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 te introduceren. Het veroorzaken van een programmafout helpt potentiële beveiligingsproblemen bloot te leggen voordat de toepassing wordt uitgebracht.

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

Aanvalsoppervlak evalueren

Het controleren van het aanvalsoppervlak na de voltooiing van de code zorgt ervoor 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 beeld van het aanvalsoppervlak vormen door de toepassing te scannen. Microsoft biedt een hulpprogramma voor het analyseren 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 Attack Surface Detector, Arachni en w3af. nl-NL: Met deze scanhulpprogramma's doorzoekt u de app en brengt u de onderdelen van de toepassing in kaart die toegankelijk zijn via internet. U kunt ook in 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 functionaliteiten. 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

Azure Tenant Security Solution (AzTS) van de Secure DevOps Kit for 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 waaruit uw toepassing bestaat, zich in een veilige status bevinden. U kunt deze tests ook automatiseren met behulp van de functie voor continue integratie/continue implementatie (CI/CD) van AzSK, waardoor SVT's beschikbaar worden gemaakt als 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.

  • Last updated on