Aanbevelingen voor het beveiligen van een ontwikkelingslevenscyclus

  • Artikel

Is van toepassing op deze aanbeveling voor de controlelijst voor beveiliging van Azure Well-Architected Framework:

SE:02 Een veilige ontwikkelingslevenscyclus onderhouden met behulp van een beveiligde, meestal geautomatiseerde en controleerbare softwareleveringsketen. Neem een veilig ontwerp op door bedreigingsmodellering te gebruiken om te beschermen tegen implementaties die de beveiliging verslaan.

Gerelateerde handleiding: Bedreigingsanalyse

In deze handleiding worden de aanbevelingen beschreven voor het beveiligen van uw code, ontwikkelomgeving en softwareleveringsketen door best practices voor beveiliging toe te passen gedurende de hele ontwikkelingscyclus. Als u deze richtlijnen wilt begrijpen, moet u kennis hebben van DevSecOps.

Een diagram van de beveiligingscyclus.

DevSecOps integreert beveiliging in DevOps-processen door:

  • Het automatiseren van beveiligingstests en -validatie.

  • Hulpprogramma's zoals beveiligingspijplijnen implementeren om code en infrastructuur als code (IaC) te scannen op beveiligingsproblemen.

De kern van een workload is de toepassingscode waarmee bedrijfslogica wordt geïmplementeerd. De code en het proces voor het ontwikkelen van code moeten vrij zijn van beveiligingsfouten om vertrouwelijkheid, integriteit en beschikbaarheid te garanderen.

Het is niet voldoende om alleen het infrastructuurvlak te beveiligen met behulp van besturingselementen voor identiteit en netwerken en andere metingen. Voorkom een slechte implementatie van code of een gecompromitteerd codeblok om uw algehele beveiligingspostuur te versterken. Het gebruiksvlak, de toepassingscode, moet ook worden beveiligd. Het proces van het integreren van beveiliging in uw ontwikkelingslevenscyclus is in feite een proces van beveiliging. Net als resourcebeveiliging is het aanscherpen van codeontwikkeling ook contextneutraal. De focus ligt op het verbeteren van de beveiliging en niet op de functionele vereisten van de toepassing. Zie Aanbevelingen voor het beveiligen van resources voor meer informatie over beveiliging.

Definities

Termijn Definitie
Security Development Lifecycle (SDL) Een set procedures van Microsoft die ondersteuning biedt voor vereisten voor beveiligingscontrole en naleving.
Levenscyclus van softwareontwikkeling (SDLC) Een meertraps, systematisch proces voor het ontwikkelen van softwaresystemen.

Belangrijke ontwerpstrategieën

Beveiligingsmaatregelen moeten op meerdere punten worden geïntegreerd in uw bestaande softwareontwikkelingslevenscyclus (SDLC) om ervoor te zorgen dat:

  • Ontwerpkeuzen leiden niet tot beveiligingsproblemen.

  • Toepassingscode en configuratie creëren geen beveiligingsproblemen vanwege misbruikbare implementatie en onjuiste coderingsprocedures.

  • Software die via de toeleveringsketen wordt verkregen, introduceert geen beveiligingsrisico's.

  • Er wordt niet geknoeid met toepassingscode, build en implementatieprocessen.

  • Beveiligingsproblemen die aan het licht komen via incidenten, worden verzacht.

  • Ongebruikte assets worden correct buiten gebruik gesteld.

  • Nalevingsvereisten worden niet aangetast of verlaagd.

  • Auditlogboekregistratie wordt geïmplementeerd in ontwikkelomgevingen.

De volgende secties bevatten beveiligingsstrategieën voor de veelgebruikte fasen van SDLC.

Vereistenfase

Het doel van de fase met vereisten is het verzamelen en analyseren van de functionele en niet-functionele vereisten voor een toepassing of een nieuwe functie van een toepassing. Deze fase is belangrijk omdat hiermee het creëren van kaders wordt vergemakkelijkt die zijn afgestemd op de doelstellingen van de toepassing. Het beschermen van de gegevens en integriteit van uw toepassing moet een kernvereiste zijn in elke fase van de ontwikkelingslevenscyclus.

Denk bijvoorbeeld aan een toepassing die essentiële gebruikersstromen moet ondersteunen waarmee de gebruiker gegevens kan uploaden en bewerken. De beveiligingsontwerpopties moeten betrekking hebben op garanties voor de interactie van de gebruiker met de toepassing, zoals het verifiëren en autoriseren van de gebruikersidentiteit, het toestaan van alleen toegestane acties voor de gegevens en het voorkomen van SQL-injectie. Op dezelfde manier worden niet-functionele vereisten behandeld, zoals beschikbaarheid, schaalbaarheid en onderhoudbaarheid. Beveiligingsopties moeten segmentatiegrenzen, inkomend en uitgaand verkeer van firewalls en andere horizontale beveiligingsproblemen omvatten.

Al deze beslissingen moeten leiden tot een goede definitie van de beveiligingspostuur van de toepassing. Documenteer de beveiligingsvereisten in een overeengekomen specificatie en geef deze weer in de achterstand. Hierin moeten expliciet de beveiligingsinvesteringen en de afwegingen en risico's worden vermeld die het bedrijf bereid is te nemen als de investeringen niet worden goedgekeurd door zakelijke belanghebbenden. U kunt bijvoorbeeld documenteer dat u een Web Application Firewall (WAF) voor uw toepassing moet gebruiken, zoals Azure Front Door of Azure Application Gateway. Als zakelijke belanghebbenden niet bereid zijn om de extra kosten van het uitvoeren van een WAF te accepteren, moeten ze het risico accepteren dat aanvallen op de toepassingslaag worden gericht op de toepassing.

Het verzamelen van beveiligingsvereisten is een essentieel onderdeel van deze fase. Zonder deze inspanning worden de ontwerp- en implementatiefasen gebaseerd op niet-vermelde keuzes, wat kan leiden tot hiaten in de beveiliging. Mogelijk moet u de implementatie later wijzigen om de beveiliging mogelijk te maken. Dit kan duur zijn.

Ontwerpfase

Tijdens deze fase worden de beveiligingsvereisten geconverteerd naar technische vereisten. Documenteer in uw technische specificatie alle ontwerpbeslissingen om dubbelzinnigheid tijdens de implementatie te voorkomen. Hier volgen enkele typische taken:

De beveiligingsdimensie van de systeemarchitectuur definiëren

Overlay van de architectuur met beveiligingsbesturingselementen. Bijvoorbeeld besturingselementen die praktisch zijn voor de isolatiegrenzen volgens uw segmentatiestrategie, de typen identiteiten die nodig zijn voor de onderdelen van de toepassing en het type versleutelingsmethoden dat moet worden gebruikt. Zie de illustraties in de secties Voorbeeld van de artikelen Identiteits- en toegangsbeheer en Netwerken voor enkele voorbeeldarchitecturen.

Door het platform geleverde betaalbaarheid evalueren

Het is belangrijk om inzicht te hebben in de verdeling van verantwoordelijkheid tussen u en de cloudprovider. Vermijd bijvoorbeeld overlapping met systeemeigen azure-besturingselementen voor beveiliging. U krijgt een betere beveiligingsdekking en kunt ontwikkelingsresources opnieuw toewijzen aan de behoeften van de toepassing.

Als uw ontwerp bijvoorbeeld een webtoepassingsfirewall voor inkomend verkeer aanroept, kunt u die verantwoordelijkheid overdragen aan een load balancer zoals Application Gateway of Azure Front Door. Vermijd het repliceren van functies als aangepaste code in uw toepassing.

Kies alleen vertrouwde frameworks, bibliotheken en toeleveringsketensoftware. In uw ontwerp moet ook beveiligd versiebeheer worden opgegeven. Toepassingsafhankelijkheden moeten afkomstig zijn van vertrouwde partijen. Externe leveranciers moeten kunnen voldoen aan uw beveiligingsvereisten en hun plan voor verantwoorde openbaarmaking delen. Elk beveiligingsincident moet onmiddellijk worden gerapporteerd, zodat u de benodigde acties kunt ondernemen. Bovendien zijn bepaalde bibliotheken mogelijk verboden door uw organisatie. Software is bijvoorbeeld mogelijk beveiligd tegen beveiligingsproblemen, maar is nog steeds niet toegestaan vanwege licentiebeperkingen.

Houd een lijst bij met goedgekeurde en/of niet-goedgekeurde frameworks, bibliotheken en leveranciers om ervoor te zorgen dat deze richtlijnen worden gevolgd door alle inzenders van de software. Plaats waar mogelijk kaders in de ontwikkelingspijplijnen om de lijst te ondersteunen. Automatiseer het gebruik van hulpprogramma's voor het scannen van afhankelijkheden op beveiligingsproblemen zoveel mogelijk.

Bepaal de beveiligingsontwerppatronen die de toepassingscode moet implementeren.

Patronen kunnen beveiligingsproblemen ondersteunen, zoals segmentatie en isolatie, sterke autorisatie, uniforme toepassingsbeveiliging en moderne protocollen. Sommige operationele patronen, zoals het quarantainepatroon, kunnen helpen bij het controleren en blokkeren van het gebruik van software die mogelijk beveiligingsproblemen kan veroorzaken.

Zie Cloudontwerppatronen die ondersteuning bieden voor beveiliging voor meer informatie.

Toepassingsgeheimen veilig opslaan

Implementeer veilig het gebruik van toepassingsgeheimen en vooraf gedeelde sleutels die uw toepassing gebruikt. Referenties en toepassingsgeheimen mogen nooit worden opgeslagen in de broncodestructuur. Gebruik externe resources zoals Azure Key Vault om ervoor te zorgen dat, als uw broncode beschikbaar komt voor een potentiële aanvaller, er geen verdere toegang meer kan worden verkregen. Over het algemeen moet u manieren vinden om geheimen te vermijden. Het gebruik van beheerde identiteiten, indien mogelijk, is een van de manieren om dat doel te bereiken. Zie Aanbevelingen voor het beheren van toepassingsgeheimen voor meer informatie.

Testplannen definiëren

Definieer duidelijke testcases voor beveiligingsvereisten. Evalueer of u deze tests in uw pijplijnen kunt automatiseren. Als uw team processen voor handmatig testen heeft, moet u de beveiligingsvereisten voor die tests opnemen.

Notitie

Bedreigingsmodellering uitvoeren tijdens deze fase. Bedreigingsmodellering kan bevestigen dat ontwerpkeuzen zijn afgestemd op de beveiligingsvereisten en hiaten blootleggen die u moet verhelpen. Als uw workload zeer gevoelige gegevens verwerkt, investeert u in beveiligingsexperts die u kunnen helpen bij het uitvoeren van bedreigingsmodellen.

De eerste bedreigingsmodelleringsoefening moet plaatsvinden tijdens de ontwerpfase wanneer de architectuur en het ontwerp op hoog niveau van de software worden gedefinieerd. Als u dit doet tijdens die fase, kunt u potentiële beveiligingsproblemen identificeren voordat ze worden opgenomen in de structuur van het systeem. Deze oefening is echter geen eenmalige activiteit. Het is een continu proces dat tijdens de ontwikkeling van de software moet worden voortgezet.

Zie Aanbevelingen voor bedreigingsanalyse voor meer informatie.

Ontwikkeling en testfase

Tijdens deze fase is het doel om beveiligingsfouten en manipulatie in code-, build- en implementatiepijplijnen te voorkomen.

Goed getraind zijn in veilige codeprocedures

Het ontwikkelteam moet formele en gespecialiseerde training hebben in veilige coderingsprocedures. Web- en API-ontwikkelaars hebben bijvoorbeeld specifieke training nodig om te beschermen tegen aanvallen op meerdere sites en back-endontwikkelaars kunnen profiteren van diepgaande training om aanvallen op databaseniveau, zoals SQL-injectieaanvallen, te voorkomen.

Ontwikkelaars moeten deze training voltooien voordat ze toegang kunnen krijgen tot de broncode van de productie.

U moet ook interne peercodebeoordelingen uitvoeren om continu leren te bevorderen.

Hulpprogramma's voor beveiligingstests gebruiken

Threat Modeling uitvoeren om de beveiliging van de architectuur van de toepassing te evalueren.

Gebruik statische toepassingsbeveiligingstests (SAST) om code te analyseren op beveiligingsproblemen. Integreer deze methodologie in de ontwikkelomgeving om beveiligingsproblemen in realtime te detecteren.

Gebruik dynamic application security testing (DAST) tijdens runtime. Deze hulpprogrammaketen kan controleren op fouten in beveiligingsdomeinen en een set aanvallen simuleren om de beveiligingstolerantie van de toepassing te testen. Integreer dit hulpprogramma indien mogelijk in uw build-pijplijnen.

Volg de industriestandaarden voor veilige coderingsprocedures. Zie de sectie Community-resources van dit artikel voor meer informatie.

Gebruik linters en codeanalyses om te voorkomen dat referenties naar de broncodeopslagplaats worden gepusht. Zo inspecteren .NET Compiler Platform (Roslyn) Analyzers uw toepassingscode.

Gebruik tijdens het buildproces pijplijninvoegtoepassingen om referenties in de broncode te onderscheppen. Scan alle afhankelijkheden, zoals bibliotheken van derden en frameworkonderdelen, als onderdeel van het continue integratieproces. Onderzoek kwetsbare onderdelen die zijn gemarkeerd door het hulpprogramma. Combineer deze taak met andere codescantaken die codeverloop, testresultaten en dekking inspecteren.

Gebruik een combinatie van tests. Zie Aanbevelingen voor beveiligingstests voor meer informatie over beveiligingstests in het algemeen.

Net genoeg code schrijven

Wanneer u uw codevoetafdruk verkleint, verkleint u ook de kans op beveiligingsfouten. Code en bibliotheken die al in gebruik zijn en beveiligingsvalidaties hebben doorlopen, opnieuw gebruiken in plaats van code te dupliceren.

Profiteren van Azure-functies is een andere manier om onnodige code te voorkomen. Eén manier is om beheerde services te gebruiken. Zie PaaS-opties (Platform as a Service) gebruiken voor meer informatie.

Schrijf standaard code met een weigeringsbenadering. Maak alleen acceptatielijsten voor entiteiten die toegang nodig hebben. Als u bijvoorbeeld code hebt die moet bepalen of een geprivilegieerde bewerking moet worden toegestaan, moet u deze zo schrijven dat het weigeringsresultaat het standaardscenario is en het resultaat toestaan alleen optreedt wanneer dit specifiek is toegestaan door code.

Ontwikkelaarsomgevingen beveiligen

Werkstations voor ontwikkelaars moeten worden beveiligd met sterke netwerk- en identiteitscontroles om blootstelling te voorkomen. Zorg ervoor dat beveiligingsupdates zorgvuldig worden toegepast.

Build-agents zijn zeer bevoegd en hebben toegang tot de buildserver en de code. Ze moeten met dezelfde strengheid worden beveiligd als uw workloadonderdelen. Dit betekent dat de toegang tot buildagents moet worden geverifieerd en geautoriseerd, dat ze netwerkgesegmenteerd moeten zijn met firewallbesturingselementen, dat ze moeten worden gescand op beveiligingsproblemen, enzovoort. Door Microsoft gehoste buildagents hebben de voorkeur boven zelf-hostende buildagents. Door Microsoft gehoste agents bieden voordelen zoals schone virtuele machines voor elke uitvoering van een pijplijn.

Aangepaste buildagents voegen beheercomplexiteit toe en kunnen een aanvalsvector worden. Referenties voor buildcomputers moeten veilig worden opgeslagen en u moet regelmatig tijdelijke buildartefacten uit het bestandssysteem verwijderen. U kunt netwerkisolatie bereiken door alleen uitgaand verkeer van de buildagent toe te staan, omdat deze gebruikmaakt van het pull-communicatiemodel met Azure DevOps.

De opslagplaats voor broncode moet ook worden beveiligd . Ververleent toegang tot codeopslagplaatsen op een need-to-know-basis en verminder de blootstelling van beveiligingsproblemen zoveel mogelijk om aanvallen te voorkomen. Zorg voor een grondig proces om code te controleren op beveiligingsproblemen. Gebruik beveiligingsgroepen voor dat doel en implementeer een goedkeuringsproces dat is gebaseerd op zakelijke redenen.

Beveiligde code-implementaties

Het is niet voldoende om alleen code te beveiligen. Als deze wordt uitgevoerd in pijplijnen die kunnen worden misbruikt, zijn alle beveiligingsinspanningen zinloos en onvolledig. Build- en releaseomgevingen moeten ook worden beveiligd , omdat u wilt voorkomen dat kwaadwillende actoren schadelijke code in uw pijplijn uitvoeren.

Een up-to-date inventaris bijhouden van elk onderdeel dat in uw toepassing is geïntegreerd

Elk nieuw onderdeel dat in een toepassing is geïntegreerd, vergroot de kwetsbaarheid voor aanvallen. U moet een inventaris van deze onderdelen hebben om de juiste aansprakelijkheid en waarschuwingen te garanderen wanneer nieuwe onderdelen worden toegevoegd of bijgewerkt. Sla het buiten de build-omgeving op. Controleer regelmatig of uw manifest overeenkomt met wat zich in het buildproces bevindt. Dit zorgt ervoor dat er onverwacht geen nieuwe onderdelen met achterdeuren of andere malware worden toegevoegd.

Pijplijntaken

  • Haal taken in uw pijplijn op uit vertrouwde bronnen, zoals Azure Marketplace. Taken uitvoeren die zijn geschreven door uw pijplijnleverancier. We raden GitHub-taken of GitHub Actions aan. Als u GitHub-werkstromen gebruikt, geeft u de voorkeur aan door Microsoft geschreven taken. Valideer ook taken omdat ze worden uitgevoerd in de beveiligingscontext van uw pijplijn.

  • Pijplijngeheimen. Implementatieassets die in een pijplijn worden uitgevoerd, hebben toegang tot alle geheimen in die pijplijn. Zorg voor de juiste segmentatie voor verschillende fasen van de pijplijn om onnodige blootstelling te voorkomen. Gebruik geheime archieven die zijn ingebouwd in de pijplijn. Houd er rekening mee dat u in sommige situaties het gebruik van geheimen kunt vermijden. Verken het gebruik van workloadidentiteiten (voor pijplijnverificatie) en beheerde identiteiten (voor service-naar-service-verificatie).

Verschillende omgevingen gescheiden houden

Gegevens die in verschillende omgevingen worden gebruikt, moeten gescheiden worden gehouden. Productiegegevens mogen niet worden gebruikt in lagere omgevingen , omdat deze omgevingen mogelijk niet de strikte beveiligingscontroles hebben die de productie heeft. Vermijd verbinding maken vanuit een niet-productietoepassing met een productiedatabase en vermijd het verbinden van niet-productieonderdelen met productienetwerken.

Progressieve blootstelling

Gebruik progressieve blootstelling om functies vrij te geven aan een subset van gebruikers op basis van gekozen criteria. Als er problemen zijn, wordt de impact voor deze gebruikers geminimaliseerd. Deze aanpak is een veelvoorkomende strategie voor risicobeperking, omdat deze de oppervlakte verkleint. Naarmate de functie volwassener wordt en u meer vertrouwen hebt in beveiligingsgaranties, kunt u deze geleidelijk vrijgeven aan een bredere groep gebruikers.

Productiefase

De productiefase is de laatste verantwoordelijke kans om hiaten in de beveiliging op te lossen. Houd een record bij van de gouden afbeelding die in productie is vrijgegeven.

Versie-artefacten behouden

Bewaar een catalogus met alle geïmplementeerde assets en hun versies. Deze informatie is nuttig tijdens het sorteren van incidenten, wanneer u problemen wilt oplossen en wanneer u het systeem weer in werking stelt. Versie-assets kunnen ook worden vergeleken met gepubliceerde cve-meldingen (Common Vulnerabilities and Exposures). U moet automatisering gebruiken om deze vergelijkingen uit te voeren.

Oplossingen voor noodgevallen

Uw geautomatiseerde pijplijnontwerp moet de flexibiliteit hebben om zowel reguliere als noodimplementaties te ondersteunen. Deze flexibiliteit is belangrijk om snelle en verantwoorde beveiligingsoplossingen te ondersteunen.

Een release is doorgaans gekoppeld aan meerdere goedkeuringspoorten. Overweeg een noodproces te maken om beveiligingspatches te versnellen. Het proces kan communicatie tussen teams omvatten. De pijplijn moet snelle roll-forward- en rollback-implementaties mogelijk maken die betrekking hebben op beveiligingspatches, kritieke fouten en code-updates die zich buiten de normale levenscyclus van de implementatie voordoen.

Notitie

Geef altijd prioriteit aan beveiligingsoplossingen boven gemak. Een beveiligingsoplossing mag geen regressie of fout veroorzaken. Als u de oplossing via een pijplijn voor noodgevallen wilt versnellen, moet u zorgvuldig overwegen welke geautomatiseerde tests kunnen worden overgeslagen. Evalueer de waarde van elke test op basis van de uitvoeringstijd. Eenheidstests worden bijvoorbeeld meestal snel voltooid. Integratie- of end-to-end-tests kunnen lange tijd worden uitgevoerd.

Onderhoudsfase

Het doel van deze fase is ervoor te zorgen dat de beveiligingspostuur na verloop van tijd niet vervalt. SDLC is een doorlopend agile proces. Concepten die in de voorgaande fasen zijn behandeld, zijn van toepassing op deze fase omdat de vereisten na verloop van tijd veranderen.

Patchbeheer. Houd software, bibliotheken en infrastructuuronderdelen up-to-date met beveiligingspatches en updates.

Continue verbetering. Evalueer en verbeter continu de beveiliging van het softwareontwikkelingsproces door rekening te houden met codebeoordelingen, feedback, geleerde lessen en veranderende bedreigingen.

Verouderde assets uit bedrijf nemen die verouderd zijn of niet meer in gebruik zijn. Als u dit doet, verkleint u de oppervlakte van de toepassing.

Onderhoud omvat ook oplossingen voor incidenten. Als er problemen worden gevonden in de productieomgeving, moeten ze onmiddellijk weer in het proces worden geïntegreerd, zodat ze niet opnieuw worden uitgevoerd.

Verbeter uw veilige coderingsmethoden continu om bij te blijven met het bedreigingslandschap.

Azure-facilitering

Microsoft Security Development Lifecycle (SDL) raadt veilige procedures aan die u kunt toepassen op uw ontwikkelingslevenscyclus. Zie Microsoft Security Development Lifecycle (Levenscyclus van Microsoft Security Development) voor meer informatie.

Defender voor DevOps en de SAST-hulpprogramma's zijn opgenomen als onderdeel van GitHub Advanced Security of Azure DevOps. Deze hulpprogramma's kunnen u helpen bij het bijhouden van een beveiligingsscore voor uw organisatie.

Volg de azure-beveiligingsaanbeveling die in deze resources worden beschreven:

Als u referenties in broncode wilt vinden, kunt u hulpprogramma's zoals GitHub Advanced Security en hulpprogramma's voor broncodeanalyse van OWASP gebruiken.

Valideer de beveiliging van alle opensource-code in uw toepassing. Deze gratis hulpprogramma's en resources kunnen u helpen bij uw evaluatie:

Controlelijst voor beveiliging

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor beveiliging