Beveiligde toepassingen ontwerpen in Azure

In dit artikel presenteren we beveiligingsactiviteiten en besturingselementen die u kunt overwegen wanneer u toepassingen voor de cloud ontwerpt. Trainingsbronnen samen met beveiligingsvragen en concepten die u moet overwegen tijdens de vereisten en ontwerpfasen 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 ontwerpen.

In dit artikel worden de volgende SDL-fasen behandeld:

  • Training
  • Vereisten
  • Ontwerpen

Training

Voordat u begint met het ontwikkelen van uw cloudtoepassing, moet u de beveiliging en privacy van Azure begrijpen. Door deze stap uit te voeren, kunt u het aantal en de ernst van misbruikbare beveiligingsproblemen in uw toepassing verminderen. U bent meer voorbereid om op de juiste wijze te reageren op het steeds veranderende bedreigingslandschap.

Gebruik de volgende resources tijdens de trainingsfase om vertrouwd te raken met de Azure-services die beschikbaar zijn voor ontwikkelaars en met aanbevolen beveiligingsprocedures in Azure:

  • Ontwikkelaarshandleiding voor Azure laat zien hoe u aan de slag gaat met Azure. In de handleiding ziet u welke services u kunt gebruiken om uw toepassingen uit te voeren, uw gegevens op te slaan, intelligentie op te nemen, IoT-apps te bouwen en uw oplossingen op een efficiëntere en veiligere manier te implementeren.

  • Aan de slag-handleiding voor Azure-ontwikkelaars biedt essentiële informatie voor ontwikkelaars die aan de slag willen met het Azure-platform voor hun ontwikkelingsbehoeften.

  • SDK's en hulpprogramma's beschrijven de hulpprogramma's die beschikbaar zijn in Azure.

  • Azure DevOps Services biedt ontwikkelhulpprogramma's voor samenwerking. De hulpprogramma's omvatten krachtige pijplijnen, gratis Git-opslagplaatsen, configureerbare Kanbanborden en uitgebreide geautomatiseerde en cloudgebaseerde belastingstests. Het DevOps Resource Center combineert onze resources voor het leren van DevOps-procedures, Git-versiebeheer, agile-methoden, hoe we werken met DevOps bij Microsoft en hoe u uw eigen DevOps-voortgang kunt evalueren.

  • De vijf belangrijkste beveiligingsitems die u moet overwegen voordat u naar productie pusht, laat zien hoe u uw webtoepassingen in Azure kunt beveiligen en uw apps kunt beschermen tegen de meest voorkomende en gevaarlijke aanvallen van webtoepassingen.

  • Secure DevOps Kit voor Azure is een verzameling scripts, hulpprogramma's, extensies en automatiseringen die voldoen aan de uitgebreide Azure-abonnements- en resourcebeveiligingsbehoeften van DevOps-teams die gebruikmaken van uitgebreide automatisering. Met de Secure DevOps Kit voor Azure kunt u zien hoe u de beveiliging soepel kunt integreren in uw systeemeigen DevOps-werkstromen. De kit behandelt hulpprogramma's zoals beveiligingsverificatietests (SVT's), waarmee ontwikkelaars veilige code kunnen schrijven en de beveiligde configuratie van hun cloudtoepassingen kunnen testen in de coderings- en vroege ontwikkelingsfasen.

  • Best practices en patronen voor Azure-beveiliging: een verzameling aanbevolen beveiligingsprocedures die u kunt gebruiken wanneer u cloudoplossingen ontwerpt, implementeert en beheert met behulp van Azure. Richtlijnen zijn bedoeld als een resource voor IT-professionals. Dit kunnen ontwerpers, architecten, ontwikkelaars en testers zijn die veilige Azure-oplossingen bouwen en implementeren.

Vereisten

De definitiefase van de vereisten is een cruciale stap bij het definiëren van wat uw toepassing is en wat deze doet wanneer deze wordt uitgebracht. De fase vereisten is ook een tijd om na te denken over de beveiligingsmaatregelen die u in uw toepassing inbouwt. Tijdens deze fase begint u ook met de stappen die u in de SDL uitvoert om ervoor te zorgen dat u een beveiligde toepassing vrijgeeft en implementeert.

Beveiligings- en privacyproblemen overwegen

Deze fase is het beste moment om fundamentele beveiligings- en privacyproblemen te overwegen. Het definiëren van acceptabele beveiligings- en privacyniveaus aan het begin van een project helpt een team:

  • Inzicht in risico's die zijn gekoppeld aan beveiligingsproblemen.
  • Beveiligingsfouten identificeren en oplossen tijdens de ontwikkeling.
  • Pas in het hele project vastgestelde beveiligings- en privacyniveaus toe.

Wanneer u de vereisten voor uw toepassing schrijft, moet u rekening houden met beveiligingscontroles waarmee u uw toepassing en gegevens veilig kunt houden.

Beveiligingsvragen stellen

Stel beveiligingsvragen zoals:

  • Bevat mijn toepassing gevoelige gegevens?

  • Verzamelt of bewaart mijn toepassing gegevens waarvoor ik moet voldoen aan industriestandaarden en complianceprogramma's zoals de Federal Financial Institution Examination Council (FFIEC) of de Payment Card Industry Data Security Standards (PCI DSS)?

  • Verzamelt of bevat mijn toepassing gevoelige persoonlijke of klantgegevens die zelfstandig of met andere gegevens kunnen worden gebruikt om één persoon te identificeren, te contacteren of te vinden?

  • Verzamelt of bevat mijn toepassing gegevens die kunnen worden gebruikt voor toegang tot medische, educatieve, financiële of arbeidsinformatie van een persoon? Door de vertrouwelijkheid van uw gegevens tijdens de vereistenfase te identificeren, kunt u uw gegevens classificeren en de methode voor gegevensbescherming identificeren die u voor uw toepassing gebruikt.

  • Waar en hoe worden mijn gegevens opgeslagen? Overweeg hoe u de opslagservices bewaakt die door uw toepassing worden gebruikt voor onverwachte wijzigingen (zoals tragere reactietijden). Kunt u invloed hebben op logboekregistratie om gedetailleerdere gegevens te verzamelen en een probleem grondig te analyseren?

  • Is mijn toepassing alleen beschikbaar voor het publiek (op internet) of intern? Als uw toepassing beschikbaar is voor het publiek, hoe beveiligt u de gegevens die mogelijk op de verkeerde manier worden gebruikt? Als uw toepassing intern alleen beschikbaar is, moet u overwegen wie in uw organisatie toegang moet hebben tot de toepassing en hoe lang ze toegang moeten hebben.

  • Begrijpt u uw identiteitsmodel voordat u begint met het ontwerpen van uw toepassing? Kunt u bepalen of gebruikers zijn wie ze zeggen dat ze zijn en wat een gebruiker mag doen?

  • Voert mijn toepassing gevoelige of belangrijke taken uit (zoals het overdragen van geld, het ontgrendelen van deuren of het leveren van medicijnen)? Bedenk hoe u controleert of de gebruiker die een gevoelige taak uitvoert, gemachtigd is om de taak uit te voeren en hoe u verifieert dat de persoon is wie hij of zij zegt. Autorisatie (AuthZ) is de handeling van het verlenen van een geverifieerde beveiligingsprincipaalm om iets te doen. Verificatie (AuthN) is het uitdagen van een partij voor legitieme referenties.

  • Voert mijn toepassing riskante softwareactiviteiten uit, zoals gebruikers toestaan bestanden of andere gegevens te uploaden of te downloaden? Als uw toepassing riskante activiteiten uitvoert, kunt u overwegen hoe uw toepassing gebruikers beschermt tegen het verwerken van schadelijke bestanden of gegevens.

OWASP top 10 controleren

Overweeg de OWASP Top 10 Application Security-risico's te bekijken. De OWASP Top 10 behandelt kritieke beveiligingsrisico's voor webtoepassingen. Bewustzijn van deze beveiligingsrisico's kan u helpen bij het nemen van vereisten en ontwerpbeslissingen waarmee deze risico's in uw toepassing worden geminimaliseerd.

Het is belangrijk om na te denken over beveiligingscontroles om schendingen te voorkomen. U wilt echter ook aannemen dat er een inbreuk optreedt. Ervan uitgaande dat een inbreuk helpt bij het beantwoorden van enkele belangrijke vragen over beveiliging van tevoren, zodat ze niet in een noodgeval hoeven te worden beantwoord:

  • Hoe ga ik een aanval detecteren?
  • Wat moet ik doen als er een aanval of schending is?
  • Hoe ga ik herstellen van de aanval, zoals het lekken of knoeien van gegevens?

Ontwerpen

De ontwerpfase is essentieel voor het vaststellen van best practices voor ontwerp- en functionele specificaties. Het is ook essentieel voor het uitvoeren van risicoanalyses waarmee beveiligings- en privacyproblemen in een project worden beperkt.

Wanneer u beveiligingsvereisten hebt en veilige ontwerpconcepten gebruikt, kunt u kansen voor een beveiligingsfout vermijden of minimaliseren. Een beveiligingsfout is een overzicht van het ontwerp van de toepassing waarmee een gebruiker schadelijke of onverwachte acties kan uitvoeren nadat uw toepassing is vrijgegeven.

Denk tijdens de ontwerpfase ook na over hoe u beveiliging in lagen kunt toepassen; een verdedigingsniveau is niet noodzakelijkerwijs voldoende. Wat gebeurt er als een aanvaller voorbij uw WaF (Web Application Firewall) komt? U wilt dat er nog een beveiligingscontrole is ingesteld om u te beschermen tegen die aanval.

Met dit in gedachten bespreken we de volgende concepten voor veilig ontwerp en de beveiligingsmaatregelen die u moet aanpakken wanneer u beveiligde toepassingen ontwerpt:

  • Gebruik een beveiligde coderingsbibliotheek en een softwareframework.
  • Scannen op kwetsbare onderdelen.
  • Bedreigingsmodellering gebruiken tijdens het ontwerpen van toepassingen.
  • Verminder de kwetsbaarheid voor aanvallen.
  • Een identiteitsbeleid gebruiken als primaire beveiligingsperimeter.
  • Verificatie vereisen voor belangrijke transacties.
  • Gebruik een oplossing voor sleutelbeheer om sleutels, referenties en andere geheimen te beveiligen.
  • Bescherm gevoelige gegevens.
  • Implementeer fail-safe-maatregelen.
  • Profiteer van fout- en uitzonderingsafhandeling.
  • Gebruik logboekregistratie en waarschuwingen.

Een beveiligde coderingsbibliotheek en een softwareframework gebruiken

Gebruik voor ontwikkeling een beveiligde coderingsbibliotheek en een softwareframework met ingesloten beveiliging. Ontwikkelaars kunnen bestaande, bewezen functies gebruiken (versleuteling, invoersanering, uitvoercodering, sleutels of verbindingsreeks s, en alles wat als een beveiligingscontrole wordt beschouwd) in plaats van helemaal zelf beveiligingscontroles te ontwikkelen. Dit helpt bij het beschermen tegen beveiligingsgerelateerde ontwerp- en implementatiefouten.

Zorg ervoor dat u de nieuwste versie van uw framework en alle beveiligingsfuncties gebruikt die beschikbaar zijn in het framework. Microsoft biedt een uitgebreide set ontwikkelhulpprogramma's voor alle ontwikkelaars, die op elk platform of elke taal werken, om cloudtoepassingen te leveren. U kunt coderen met de taal van uw keuze door een keuze te maken uit verschillende SDK's. U kunt profiteren van volledige geïntegreerde ontwikkelomgevingen (IDE's) en editors met geavanceerde foutopsporingsmogelijkheden en ingebouwde ondersteuning voor Azure.

Microsoft biedt verschillende talen, frameworks en hulpprogramma's die u kunt gebruiken voor het ontwikkelen van toepassingen in Azure. Een voorbeeld hiervan is Azure voor .NET- en .NET Core-ontwikkelaars. Voor elke taal en elk framework dat we bieden, vindt u snelstartgidsen, zelfstudies en API-verwijzingen om snel aan de slag te gaan.

Azure biedt verschillende services die u kunt gebruiken om websites en webtoepassingen te hosten. Met deze services kunt u ontwikkelen in uw favoriete taal, ongeacht of dat .NET, .NET Core, Java, Ruby, Node.js, PHP of Python is. Azure-app Service Web Apps (Web Apps) is een van deze services.

Web Apps voegt de kracht van Microsoft Azure toe aan uw toepassing. Het omvat beveiliging, taakverdeling, automatisch schalen en geautomatiseerd beheer. U kunt ook profiteren van DevOps-mogelijkheden in Web Apps, zoals pakketbeheer, faseringsomgevingen, aangepaste domeinen, SSL/TLS-certificaten en continue implementatie vanuit Azure DevOps, GitHub, Docker Hub en andere bronnen.

Azure biedt andere services die u kunt gebruiken om websites en webtoepassingen te hosten. Voor de meeste scenario's is Web Apps de beste keuze. Overweeg Azure Service Fabric voor een microservicearchitectuur. Als u meer controle wilt over de virtuele machines waarop uw code wordt uitgevoerd, kunt u Azure Virtual Machines overwegen. Zie een vergelijking van Azure-app Service, Virtual Machines, Service Fabric en Cloud Services voor meer informatie over het kiezen tussen deze Azure-services.

Updates toepassen op onderdelen

Als u beveiligingsproblemen wilt voorkomen, moet u zowel de onderdelen aan de clientzijde als de serverzijde (bijvoorbeeld frameworks en bibliotheken) en de bijbehorende afhankelijkheden voor updates continu inventariseren. Nieuwe beveiligingsproblemen en bijgewerkte softwareversies worden continu uitgebracht. Zorg ervoor dat u een doorlopend plan hebt om updates of configuratiewijzigingen te controleren, te classificeren en toe te passen op de bibliotheken en onderdelen die u gebruikt.

Zie de pagina Open Web Application Security Project (OWASP) over het gebruik van onderdelen met bekende beveiligingsproblemen voor hulpprogrammasuggesties. U kunt zich ook abonneren op e-mailwaarschuwingen voor beveiligingsproblemen die betrekking hebben op onderdelen die u gebruikt.

Bedreigingsmodellering gebruiken tijdens het ontwerpen van toepassingen

Bedreigingsmodellering is het proces voor het identificeren van mogelijke beveiligingsrisico's voor uw bedrijf en toepassing, en vervolgens ervoor te zorgen dat er juiste oplossingen worden geïmplementeerd. De SDL geeft aan dat teams zich tijdens de ontwerpfase moeten bezighouden met threat modeling, wanneer het oplossen van potentiële problemen relatief eenvoudig en rendabel is. Het gebruik van bedreigingsmodellering in de ontwerpfase kan de totale ontwikkelingskosten aanzienlijk verminderen.

Om het threat modeling-proces te vergemakkelijken, hebben we het SDL Threat Modeling Tool ontworpen met niet-beveiligingsexperts in gedachten. Dit hulpprogramma maakt threat modeling eenvoudiger voor alle ontwikkelaars door duidelijke richtlijnen te bieden over het maken en analyseren van bedreigingsmodellen.

Modelleren van het toepassingsontwerp en het inventariseren van STRIDE-bedreigingen - Spoofing, Manipulatie, Repudiation, Information Disclosure, Denial of Service en Elevation of Privilege-over alle vertrouwensgrenzen heeft bewezen dat ontwerpfouten vroeg kunnen worden ondervangen. De volgende tabel bevat de STRIDE-bedreigingen en geeft enkele voorbeelden van oplossingen die gebruikmaken van functies van Azure. Deze oplossingen werken niet in elke situatie.

Bedreiging Beveiligingseigenschap Mogelijke risicobeperking voor Azure-platformen
Adresvervalsing (spoofing) Verificatie HTTPS-verbindingen vereisen.
Manipulatie Integriteit SSL/TLS-certificaten valideren. Toepassingen die gebruikmaken van SSL/TLS moeten de X.509-certificaten van de entiteiten waarmee ze verbinding maken, volledig verifiëren. Gebruik Azure Key Vault-certificaten om uw x509-certificaten te beheren.
Verwerping Niet-weerlegbaarheid Schakel Azure-bewaking en diagnostische gegevens in.
Openbaarmaking van informatie Vertrouwelijkheid Versleutel gevoelige data-at-rest en in transit.
Denial of Service Beschikbaarheid Bewaak metrische prestatiegegevens voor mogelijke Denial of Service-voorwaarden. Verbindingsfilters implementeren. Azure DDoS-beveiliging, gecombineerd met best practices voor het ontwerpen van toepassingen, biedt beveiliging tegen DDoS-aanvallen.
Verhoging van bevoegdheden Autorisatie Gebruik Microsoft Entra ID Privileged Identity Management.

Het kwetsbaarheid voor aanvallen verminderen

Een kwetsbaarheid voor aanvallen is de totale som van waar potentiële beveiligingsproblemen kunnen optreden. In dit artikel richten we ons op de kwetsbaarheid voor aanvallen van een toepassing. De focus ligt op het beveiligen van een toepassing tegen aanvallen. Een eenvoudige en snelle manier om uw kwetsbaarheid voor aanvallen te minimaliseren, is door ongebruikte resources en code uit uw toepassing te verwijderen. Hoe kleiner uw toepassing, hoe kleiner uw aanvalsoppervlak. Verwijder bijvoorbeeld:

  • Code voor functies die u nog niet hebt uitgebracht.
  • Ondersteuningscode voor foutopsporing.
  • Netwerkinterfaces en protocollen die niet worden gebruikt of die zijn afgeschaft.
  • Virtuele machines en andere resources die u niet gebruikt.

Regelmatig opschonen van uw resources en ervoor zorgen dat u ongebruikte code verwijdert, zijn geweldige manieren om ervoor te zorgen dat er minder mogelijkheden zijn om kwaadwillende actoren aan te vallen.

Een gedetailleerdere en uitgebreidere manier om uw kwetsbaarheid voor aanvallen te verminderen, is door een analyse van de kwetsbaarheid voor aanvallen te voltooien. Een analyse van kwetsbaarheid voor aanvallen helpt u bij het toewijzen van de onderdelen van een systeem dat moet worden gecontroleerd en getest op beveiligingsproblemen.

Het doel van een analyse van kwetsbaarheid voor aanvallen is om inzicht te krijgen in de risicogebieden in een toepassing, zodat ontwikkelaars en beveiligingsspecialisten zich bewust zijn van welke onderdelen van de toepassing open zijn voor aanvallen. Vervolgens kunt u manieren vinden om dit potentieel te minimaliseren, bij te houden wanneer en hoe de kwetsbaarheid voor aanvallen verandert en wat dit betekent vanuit een risicoperspectief.

Een analyse van kwetsbaarheid voor aanvallen helpt u bij het identificeren van:

  • Functies en onderdelen van het systeem die u moet controleren en testen op beveiligingsproblemen.
  • Gebieden met een hoog risico die diepgaande beveiliging vereisen (onderdelen van het systeem die u moet verdedigen).
  • Wanneer u de kwetsbaarheid voor aanvallen wijzigt en een bedreigingsevaluatie moet vernieuwen.

Voor het verminderen van mogelijkheden voor aanvallers om misbruik te maken van een potentiële zwakke plek of beveiligingsprobleem, moet u de algehele kwetsbaarheid voor aanvallen van uw toepassing grondig analyseren. Het omvat ook het uitschakelen of beperken van de toegang tot systeemservices, het toepassen van het principe van minimale bevoegdheden en het toepassen van gelaagde verdediging waar mogelijk.

We bespreken het uitvoeren van een aanvalsoppervlakbeoordeling tijdens de verificatiefase van de SDL.

Notitie

Wat is het verschil tussen bedreigingsmodellering en analyse van kwetsbaarheid voor aanvallen? Bedreigingsmodellering is het proces voor het identificeren van mogelijke beveiligingsrisico's voor uw toepassing en het waarborgen dat er juiste oplossingen voor de bedreigingen worden geïmplementeerd. Analyse van kwetsbaarheid voor aanvallen identificeert gebieden met een hoog risico van code die openstaan voor aanvallen. Het omvat het vinden van manieren om gebieden met een hoog risico van uw toepassing te verdedigen en deze gebieden met code te controleren en te testen voordat u de toepassing implementeert.

Een identiteitsbeleid gebruiken als primaire beveiligingsperimeter

Wanneer u cloudtoepassingen ontwerpt, is het belangrijk om uw beveiligingsperimeterfocus uit te breiden van een netwerkgerichte benadering naar een identiteitsgerichte benadering. In het verleden was de primaire on-premises beveiligingsperimeter het netwerk van een organisatie. De meeste on-premises beveiligingsontwerpen gebruiken het netwerk als primaire beveiligingspivot. Voor cloudtoepassingen kunt u beter gebruikmaken van identiteit als primaire beveiligingsperimeter.

Dingen die u kunt doen om een identiteitsgerichte benadering te ontwikkelen voor het ontwikkelen van webtoepassingen:

  • Meervoudige verificatie afdwingen voor gebruikers.
  • Gebruik krachtige verificatie- en autorisatieplatforms.
  • Pas het principe van minimale bevoegdheden toe.
  • Just-In-Time-toegang implementeren.

Meervoudige verificatie afdwingen voor gebruikers

Gebruik tweeledige verificatie. Tweeledige verificatie is de huidige standaard voor verificatie en autorisatie, omdat hiermee de zwakke plekken in de beveiliging worden vermeden die inherent zijn aan de verificatietypen gebruikersnaam en wachtwoord. Toegang tot de Azure-beheerinterfaces (Azure Portal/externe PowerShell) en de klantgerichte services moeten worden ontworpen en geconfigureerd voor het gebruik van Meervoudige Verificatie met Microsoft Entra.

Krachtige verificatie- en autorisatieplatforms gebruiken

Gebruik door het platform geleverde verificatie- en autorisatiemechanismen in plaats van aangepaste code. Dit komt doordat het ontwikkelen van aangepaste verificatiecode gevoelig kan zijn voor fouten. Commerciële code (bijvoorbeeld van Microsoft) wordt vaak uitgebreid gecontroleerd op beveiliging. Microsoft Entra ID (Microsoft Entra ID) is de Azure-oplossing voor identiteits- en toegangsbeheer. Deze Microsoft Entra-hulpprogramma's en -services helpen bij het veilig ontwikkelen:

  • Microsoft Identity Platform is een set onderdelen die ontwikkelaars gebruiken om apps te bouwen die gebruikers veilig aanmelden. Het platform helpt ontwikkelaars die lob-apps (line-of-business) met één tenant bouwen en ontwikkelaars die multitenant-apps willen ontwikkelen. Naast eenvoudige aanmelding kunnen apps die zijn gebouwd met het Microsoft Identity Platform, Microsoft API's en aangepaste API's aanroepen. Het Microsoft Identity Platform ondersteunt industriestandaard protocollen zoals OAuth 2.0 en OpenID Verbinding maken.

  • Azure Active Directory B2C (Azure AD B2C) is een identiteitsbeheerservice die u gebruikt om aan te passen en te bepalen hoe klanten zich registreren, aanmelden en hun profielen beheren wanneer ze uw toepassingen gebruiken. Dit omvat onder andere toepassingen die zijn ontwikkeld voor iOS, Android en .NET. Azure AD B2C maakt deze acties mogelijk tijdens het beveiligen van klantidentiteiten.

Het principe van minimale bevoegdheden toepassen

Het concept van minimale bevoegdheden betekent dat gebruikers het precieze toegangsniveau krijgen en beheren dat ze nodig hebben om hun taken uit te voeren en niets meer.

Heeft een softwareontwikkelaar domeinbeheerdersrechten nodig? Zou een administratieve assistent toegang nodig hebben tot beheercontroles op hun persoonlijke computer? Het evalueren van toegang tot software is niet anders. Als u op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) gebruikt om gebruikers verschillende mogelijkheden en autoriteit in uw toepassing te geven, geeft u niet iedereen toegang tot alles. Door de toegang te beperken tot wat vereist is voor elke rol, beperkt u het risico dat zich een beveiligingsprobleem voordoet.

Zorg ervoor dat uw toepassing minimale bevoegdheden afdwingt in de toegangspatronen.

Notitie

De regels van minimale bevoegdheden moeten van toepassing zijn op de software en op de personen die de software maken. Softwareontwikkelaars kunnen een enorm risico vormen voor IT-beveiliging als ze te veel toegang krijgen. De gevolgen kunnen ernstig zijn als een ontwikkelaar schadelijke bedoelingen heeft of te veel toegang krijgt. Het is raadzaam dat de regels met minimale bevoegdheden gedurende de gehele ontwikkelingslevenscyclus worden toegepast op ontwikkelaars.

Just-In-Time-toegang implementeren

Implementeer Just-In-Time-toegang (JIT) om de blootstellingstijd van bevoegdheden verder te verlagen. Gebruik Microsoft Entra Privileged Identity Management om:

  • Geef gebruikers de machtigingen die ze alleen nodig hebben voor JIT.
  • Wijs rollen toe voor een verkorte duur met het vertrouwen dat de bevoegdheden automatisch worden ingetrokken.

Verificatie vereisen voor belangrijke transacties

Aanvraagvervalsing op meerdere sites (ook wel XSRF of CSRF genoemd) is een aanval op web-gehoste apps waarin een schadelijke web-app invloed heeft op de interactie tussen een clientbrowser en een web-app die die browser vertrouwt. Aanvallen op aanvraagvervalsing op meerdere sites zijn mogelijk omdat webbrowsers automatisch bepaalde typen verificatietokens verzenden met elke aanvraag naar een website. Deze vorm van misbruik wordt ook wel een aanval met één klik of sessie rijden genoemd omdat de aanval gebruikmaakt van de eerder geverifieerde sessie van de gebruiker.

De beste manier om zich te beschermen tegen dit soort aanvallen is door de gebruiker te vragen om iets dat alleen de gebruiker kan bieden vóór elke belangrijke transactie, zoals een aankoop, accountdeactivatie of een wachtwoordwijziging. U kunt de gebruiker vragen om het wachtwoord opnieuw in te voeren, een captcha te voltooien of een geheim token in te dienen dat alleen de gebruiker zou hebben. De meest voorkomende benadering is het geheime token.

Een oplossing voor sleutelbeheer gebruiken om sleutels, referenties en andere geheimen te beveiligen

Het verliezen van sleutels en referenties is een veelvoorkomend probleem. Het enige wat erger is dan het verliezen van uw sleutels en referenties is dat een onbevoegde partij toegang tot hen krijgt. Aanvallers kunnen gebruikmaken van geautomatiseerde en handmatige technieken om sleutels en geheimen te vinden die zijn opgeslagen in codeopslagplaatsen zoals GitHub. Plaats geen sleutels en geheimen in deze openbare codeopslagplaatsen of op een andere server.

Plaats uw sleutels, certificaten, geheimen en verbindingsreeks s altijd in een oplossing voor sleutelbeheer. U kunt een gecentraliseerde oplossing gebruiken waarin sleutels en geheimen worden opgeslagen in HSM's (Hardware Security Modules). Azure biedt u een HSM in de cloud met Azure Key Vault.

Key Vault is een geheim archief: het is een gecentraliseerde cloudservice voor het opslaan van toepassingsgeheimen. Key Vault houdt uw vertrouwelijke gegevens veilig door toepassingsgeheimen op één centrale locatie te houden en veilige toegang, machtigingenbeheer en logboekregistratie van toegang te bieden.

Geheimen worden opgeslagen in afzonderlijke kluizen. Elke kluis heeft een eigen configuratie- en beveiligingsbeleid om de toegang te beheren. U krijgt toegang tot uw gegevens via een REST API of via een client-SDK die beschikbaar is voor de meeste programmeertalen.

Belangrijk

Azure Key Vault is ontworpen voor het opslaan van configuratiegeheimen voor servertoepassingen. Het is niet bedoeld voor het opslaan van gegevens die eigendom zijn van app-gebruikers. Dit wordt weerspiegeld in de prestatiekenmerken, de API en het kostenmodel.

Gebruikersgegevens moeten elders worden opgeslagen, zoals in een Azure SQL Database-exemplaar met Transparent Data Encryption (TDE) of in een opslagaccount dat gebruikmaakt van Azure Storage Service Encryption. Geheimen die door uw toepassing worden gebruikt voor toegang tot deze gegevensarchieven, kunnen worden bewaard in Azure Key Vault.

Gevoelige gegevens beveiligen

Het beveiligen van gegevens is een essentieel onderdeel van uw beveiligingsstrategie. Door uw gegevens te classificeren en uw behoeften voor gegevensbescherming te identificeren, kunt u uw app ontwerpen met gegevensbeveiliging in het achterhoofd. Door opgeslagen gegevens te classificeren (categoriseren) op basis van gevoeligheid en bedrijfsimpact, kunnen ontwikkelaars de risico's bepalen die zijn gekoppeld aan gegevens.

Label alle toepasselijke gegevens als gevoelig wanneer u uw gegevensindelingen ontwerpt. Zorg ervoor dat de toepassing de toepasselijke gegevens behandelt als gevoelig. Deze procedures kunnen u helpen bij het beveiligen van uw gevoelige gegevens:

  • Gebruik versleuteling.
  • Vermijd hardcoderingsgeheimen, zoals sleutels en wachtwoorden.
  • Zorg ervoor dat toegangsbeheer en controle zijn ingesteld.

Versleuteling gebruiken

Het beveiligen van gegevens moet een essentieel onderdeel zijn van uw beveiligingsstrategie. Als uw gegevens zijn opgeslagen in een database of tussen locaties heen en weer worden verplaatst, gebruikt u versleuteling van data-at-rest (in de database) en versleuteling van gegevens die onderweg zijn (onderweg naar en van de gebruiker, de database, een API of service-eindpunt). U wordt aangeraden altijd SSL/TLS-protocollen te gebruiken om gegevens uit te wisselen. Zorg ervoor dat u de nieuwste versie van TLS gebruikt voor versleuteling (momenteel is dit versie 1.2).

Hard-coding voorkomen

Sommige dingen moeten nooit in code worden vastgelegd in uw software. Enkele voorbeelden zijn hostnamen of IP-adressen, URL's, e-mailadressen, gebruikersnamen, wachtwoorden, opslagaccountsleutels en andere cryptografische sleutels. Overweeg om vereisten te implementeren omtrent wat wel of niet in code kan worden vastgelegd, inclusief in de opmerkingensecties van uw code.

Wanneer u opmerkingen in uw code plaatst, moet u ervoor zorgen dat u geen gevoelige informatie opslaat. Dit omvat uw e-mailadres, wachtwoorden, verbindingsreeks s, informatie over uw toepassing die alleen bekend zou zijn door iemand in uw organisatie en alles wat een aanvaller een voordeel kan geven bij het aanvallen van uw toepassing of organisatie.

In principe wordt ervan uitgegaan dat alles in uw ontwikkelingsproject openbare kennis is wanneer het wordt geïmplementeerd. Vermijd het opnemen van gevoelige gegevens van elk type in het project.

Eerder hebben we Azure Key Vault besproken. U kunt Key Vault gebruiken om geheimen, zoals sleutels en wachtwoorden, op te slaan in plaats van ze hard te coderen. Wanneer u Key Vault gebruikt in combinatie met beheerde identiteiten voor Azure-resources, heeft uw Azure-web-app eenvoudig en veilig toegang tot geheime configuratiewaarden zonder geheimen op te slaan in uw broncodebeheer of -configuratie. Zie Geheimen beheren in uw server-apps met Azure Key Vault voor meer informatie.

Fail-safe-maatregelen implementeren

Uw toepassing moet fouten kunnen afhandelen die optreden tijdens de uitvoering op een consistente manier. De toepassing moet alle fouten ondervangen en niet veilig of gesloten zijn.

U moet er ook voor zorgen dat fouten worden geregistreerd met voldoende gebruikerscontext om verdachte of schadelijke activiteiten te identificeren. Logboeken moeten gedurende voldoende tijd worden bewaard om vertraagde forensische analyse mogelijk te maken. Logboeken moeten een indeling hebben die eenvoudig kan worden gebruikt door een oplossing voor logboekbeheer. Zorg ervoor dat waarschuwingen voor fouten met betrekking tot beveiliging worden geactiveerd. Door onvoldoende logboekregistratie en bewaking kunnen aanvallers verdere aanvalssystemen uitvoeren en persistentie behouden.

Profiteren van fout- en uitzonderingsafhandeling

Het implementeren van de juiste fout- en uitzonderingsafhandeling is een belangrijk onderdeel van defensieve codering. Fout- en uitzonderingsafhandeling is essentieel om een systeem betrouwbaar en veilig te maken. Fouten bij foutafhandeling kunnen leiden tot verschillende soorten beveiligingsproblemen, zoals het lekken van informatie aan aanvallers en het helpen van aanvallers om meer inzicht te hebben in uw platform en ontwerp.

U moet het volgende hebben gedaan:

  • U verwerkt uitzonderingen op een gecentraliseerde manier om dubbele try/catch-blokken in de code te voorkomen.

  • Alle onverwachte gedragingen worden verwerkt in de toepassing.

  • Berichten die aan gebruikers worden weergegeven, lekken geen kritieke gegevens, maar bieden wel voldoende informatie om het probleem uit te leggen.

  • Uitzonderingen worden geregistreerd en bieden voldoende informatie voor forensische of incidentresponsteams om te onderzoeken.

Azure Logic Apps biedt een eersteklas ervaring voor het afhandelen van fouten en uitzonderingen die worden veroorzaakt door afhankelijke systemen. U kunt Logic Apps gebruiken om werkstromen te maken om taken en processen te automatiseren die apps, gegevens, systemen en services integreren in ondernemingen en organisaties.

Logboekregistratie en waarschuwingen gebruiken

Registreer uw beveiligingsproblemen voor beveiligingsonderzoeken en activeer waarschuwingen over problemen om ervoor te zorgen dat mensen tijdig op de hoogte zijn van problemen. Schakel controle en logboekregistratie in voor alle onderdelen. Auditlogboeken moeten gebruikerscontext vastleggen en alle belangrijke gebeurtenissen identificeren.

Controleer of u geen gevoelige gegevens aanmeldt die een gebruiker naar uw site verzendt. Voorbeelden van gevoelige gegevens zijn:

  • Gebruikersreferenties
  • Burgerservicenummers of andere identificatiegegevens
  • Creditcardnummers of andere financiële gegevens
  • Statusinformatie
  • Persoonlijke sleutels of andere gegevens die kunnen worden gebruikt om versleutelde gegevens te ontsleutelen
  • Systeem- of toepassingsgegevens die kunnen worden gebruikt om de toepassing effectiever aan te vallen

Zorg ervoor dat de toepassing gebruikersbeheergebeurtenissen controleert, zoals geslaagde en mislukte gebruikersaanmelding, wachtwoordherstel, wachtwoordwijzigingen, accountvergrendeling en gebruikersregistratie. Logboekregistratie voor deze gebeurtenissen helpt u bij het detecteren en reageren op mogelijk verdacht gedrag. Hiermee kunt u ook bewerkingsgegevens verzamelen, zoals wie toegang heeft tot de toepassing.

Volgende stappen

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