Delen via

Aanbevelingen voor het beveiligen van een ontwikkelingslevenscyclus

  • Artikel

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

SE:02 Een veilige ontwikkelingslevenscyclus onderhouden met behulp van een beperkte, meestal geautomatiseerde en controleerbare software-toeleveringsketen. Neem een veilig ontwerp op door bedreigingsmodellering te gebruiken om te beschermen tegen beveiligingsverlagende implementaties.

Verwante handleiding: Bedreigingsanalyse

In deze handleiding worden de aanbevelingen beschreven voor het beveiligen van uw code, ontwikkelomgeving en softwareleveringsketen door aanbevolen beveiligingsprocedures toe te passen gedurende de 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:

  • Beveiliging testen en valideren automatiseren.

  • 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 van het ontwikkelen van code moeten vrij zijn van beveiligingsfouten om vertrouwelijkheid, integriteit en beschikbaarheid te waarborgen.

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, dat wil gezegd, de toepassingscode, moet ook worden beveiligd. Het proces voor het integreren van beveiliging in uw ontwikkelingslevenscyclus is in feite een hardingsproces. Net als bij het beperken van resources is het versterken 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 informatie over beveiliging.

Definities

Termijn Definitie
Security Development Lifecycle (SDL) Een reeks procedures van Microsoft die ondersteuning biedt voor beveiligingscontrole- en nalevingsvereisten.
Levenscyclus van softwareontwikkeling (SDLC) Een multistage, systematisch proces voor het ontwikkelen van softwaresystemen.

Belangrijke ontwerpstrategieën

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

  • Ontwerpkeuzen leiden niet tot beveiligingsproblemen.

  • Toepassingscode en -configuratie maken geen beveiligingsproblemen vanwege misbruikbare implementatie en onjuiste coderingsprocedures.

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

  • Met toepassingscode-, build- en implementatieprocessen wordt niet geknoeid.

  • Beveiligingsproblemen die worden ontdekt door incidenten, worden beperkt.

  • Ongebruikte assets worden correct buiten gebruik gesteld.

  • Nalevingsvereisten worden niet aangetast of verminderd.

  • Auditlogboekregistratie wordt geïmplementeerd in ontwikkelomgevingen.

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

De beveiligingsvereisten verzamelen en vastleggen

Het doel van de vereistenfase 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 het het creëren van kaders vergemakkelijkt die zijn afgestemd op de doelstellingen van de toepassing. Het beveiligen van de gegevens en integriteit van uw toepassing moet een kernvereiste zijn gedurende elke fase van de ontwikkelingslevenscyclus.

Denk bijvoorbeeld aan een toepassing die kritieke gebruikersstromen moet ondersteunen waarmee de gebruiker gegevens kan uploaden en bewerken. De beveiligingsontwerpkeuzes moeten betrekking hebben op de garanties voor de interactie van de gebruiker met de toepassing, zoals het verifiëren en autoriseren van de gebruikersidentiteit, waarbij alleen toegestane acties op de gegevens worden toegestaan en sql-injectie wordt voorkomen. Bedek op dezelfde manier niet-functionele vereisten, zoals beschikbaarheid, schaalbaarheid en onderhoudbaarheid. Beveiligingskeuzes moeten segmentatiegrenzen, inkomend en uitgaand verkeer van firewalls en andere grensoverschrijdende beveiligingsproblemen omvatten.

Al deze beslissingen moeten leiden tot een goede definitie van het beveiligingspostuur van de toepassing. Documenteer de beveiligingsvereisten in een overeengekomen specificatie en geef deze weer in de achterstand. Het moet expliciet de beveiligingsinvesteringen en de compromissen en risico's aangeven die het bedrijf wil overnemen als de investeringen niet worden goedgekeurd door belanghebbenden van het bedrijf. U kunt bijvoorbeeld documenteren dat u een WEB Application Firewall (WAF) moet gebruiken voor uw toepassing, zoals Azure Front Door of Azure-toepassing Gateway. Als zakelijke belanghebbenden niet bereid zijn om de extra kosten voor het uitvoeren van een WAF te accepteren, moeten ze het risico accepteren dat aanvallen op de toepassingslaag mogelijk naar de toepassing worden geleid.

Het verzamelen van beveiligingsvereisten is een essentieel onderdeel van deze fase. Zonder deze inspanning worden de ontwerp- en implementatiefasen gebaseerd op niet-benoemde keuzes, wat kan leiden tot beveiligingsproblemen. Mogelijk moet u de implementatie later wijzigen om ruimte te bieden voor beveiliging, wat duur kan zijn.

Beveiligingsvereisten vertalen naar technische vereisten

Tijdens de ontwerpfase worden de beveiligingsvereisten omgezet in 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. Besturingselementen die praktisch zijn voor de isolatiegrenzen per 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 voorbeelden van architecturen .

Door het platform geleverde betaalbaarheid evalueren

Het is belangrijk om inzicht te hebben in de verdeling van de verantwoordelijkheid tussen u en de cloudprovider. Vermijd overlapping met systeemeigen beveiligingsmaatregelen van Azure, bijvoorbeeld. U krijgt een betere beveiligingsdekking en kunt ontwikkelbronnen opnieuw toewijzen aan de behoeften van de toepassing.

Als uw ontwerp bijvoorbeeld aanroept naar een webtoepassingsfirewall voor inkomend verkeer, kunt u die verantwoordelijkheid offloaden naar 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 supply chain-software. Uw ontwerp moet ook beveiligd versiebeheer opgeven. Toepassingsafhankelijkheden moeten afkomstig zijn van vertrouwde partijen. Externe leveranciers moeten kunnen voldoen aan uw beveiligingsvereisten en hun verantwoordelijke openbaarmakingsplan delen. Elk beveiligingsincident moet onmiddellijk worden gerapporteerd, zodat u de benodigde acties kunt ondernemen. Bovendien zijn bepaalde bibliotheken mogelijk niet toegestaan door uw organisatie. Software kan bijvoorbeeld worden beveiligd tegen beveiligingsproblemen, maar is nog steeds niet toegestaan vanwege licentiebeperkingen.

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

Bepaal de beveiligingsontwerppatronen die door de toepassingscode moeten worden geïmplementeerd.

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 verifiëren 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 door uw toepassing worden 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, geen verdere toegang kan worden verkregen. Over het algemeen kunt u manieren vinden om geheimen te voorkomen. Het gebruik van beheerde identiteiten is, indien mogelijk, één manier 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 beveiligingsvereisten voor deze tests opnemen.

Notitie

Voer bedreigingsmodellering uit tijdens deze fase. Bedreigingsmodellering kan bevestigen dat ontwerpkeuzen zijn afgestemd op beveiligingsvereisten en hiaten blootstellen die u moet beperken. Als uw workload zeer gevoelige gegevens verwerkt, investeert u in beveiligingsexperts die u kunnen helpen bij het modelleren van bedreigingen.

De eerste threat modeling-oefening moet plaatsvinden tijdens de ontwerpfase wanneer de architectuur en het ontwerp op hoog niveau van de software worden gedefinieerd. Door dit in die fase te doen, 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 door moet gaan in de ontwikkeling van de software.

Zie Aanbevelingen voor bedreigingsanalyse voor meer informatie.

Veilige ontwikkel- en testprocedures

Tijdens de ontwikkelings- en testfase 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 te voorkomen, zoals SQL-injectieaanvallen.

Ontwikkelaars moeten deze training voltooien voordat ze toegang kunnen krijgen tot productiebroncode.

U moet ook interne peercodebeoordelingen uitvoeren om continue training te bevorderen.

Hulpprogramma's voor beveiligingstests gebruiken

Voer bedreigingsmodellering uit om de beveiliging van de architectuur van de toepassing te evalueren.

Gebruik SAST (Static Application Security Testing) om code te analyseren op beveiligingsproblemen. Integreer deze methodologie in de ontwikkelomgeving om beveiligingsproblemen in realtime te detecteren.

Gebruik DYNAMISCHE DAST (Application Security Testing) tijdens runtime. Deze toolketen kan controleren op fouten in beveiligingsdomeinen en een reeks aanvallen simuleren om de beveiligingstolerantie van de toepassing te testen. Integreer dit hulpprogramma indien mogelijk in uw build-pijplijnen.

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

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

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

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

Net genoeg code schrijven

Wanneer u uw codevoetafdruk vermindert, vermindert u ook de kans op beveiligingsfouten. Gebruik code en bibliotheken die al in gebruik zijn en die beveiligingsvalidaties hebben ondergaan in plaats van code te dupliceren.

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

Schrijf standaard code met een deny-all-benadering. Maak alleen allowlists voor entiteiten die toegang nodig hebben. Als u bijvoorbeeld code hebt die moet bepalen of een bevoegde bewerking moet worden toegestaan, moet u deze schrijven zodat het resultaat voor weigeren de standaardcase is en het resultaat voor toestaan alleen voorkomt wanneer dit specifiek is toegestaan door code.

Ontwikkelomgevingen beveiligen

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

Buildagents zijn zeer bevoegd en hebben toegang tot de buildserver en de code. Ze moeten worden beveiligd met dezelfde rigor als uw workloadonderdelen. Dit betekent dat toegang tot buildagents moet worden geverifieerd en geautoriseerd, dat ze netwerksegmenteren met firewallbesturingselementen, ze moeten worden gescand op beveiligingsproblemen, enzovoort. Door Microsoft gehoste buildagents moeten de voorkeur hebben 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 het gebruikmaakt van het pull-model voor communicatie met Azure DevOps.

De broncodeopslagplaats moet ook worden beveiligd . Ververleent toegang tot codeopslagplaatsen op basis van noodzaak tot kennis en verminder de blootstelling van beveiligingsproblemen zoveel mogelijk om aanvallen te voorkomen. Zorg voor een grondig proces om code te controleren op beveiligingsproblemen. Gebruik hiervoor beveiligingsgroepen en implementeer een goedkeuringsproces dat is gebaseerd op zakelijke redenen.

Code beveiligen in implementatiepijplijnen

Het is niet genoeg om alleen code te beveiligen. Als deze wordt uitgevoerd in exploiteerbare pijplijnen, zijn alle beveiligingsinspanningen nutteloos en onvolledig. Build- en releaseomgevingen moeten ook worden beveiligd omdat u wilt voorkomen dat slechte actoren schadelijke code uitvoeren in uw pijplijn.

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

Elk nieuw onderdeel dat is geïntegreerd in een toepassing verhoogt de kwetsbaarheid voor aanvallen. Als u de juiste verantwoordelijkheid en waarschuwingen wilt garanderen wanneer nieuwe onderdelen worden toegevoegd of bijgewerkt, moet u een inventaris van deze onderdelen hebben. Sla deze op buiten de buildomgeving. Controleer regelmatig of uw manifest overeenkomt met wat er in uw buildproces staat. Dit helpt ervoor te zorgen dat er geen nieuwe onderdelen die achterdeuren of andere malware bevatten onverwacht worden toegevoegd.

Pijplijntaken

  • Haal taken in uw pijplijn op uit vertrouwde bronnen, zoals Azure Marketplace. Voer taken uit die zijn geschreven door de leverancier van uw pijplijn. 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 een 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 het gebruik van geheimen in sommige situaties 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 beschikken over de strikte beveiligingscontroles die de productie heeft. Vermijd het maken van verbinding 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 geminimaliseerd voor deze gebruikers. Deze aanpak is een veelvoorkomende strategie voor risicobeperking, omdat dit het oppervlak vermindert. Naarmate de functie volwassener wordt en u meer vertrouwen hebt in beveiligingsgaranties, kunt u deze geleidelijk vrijgeven aan een bredere set gebruikers.

Code in productie beveiligen

De productiefase biedt de laatste verantwoordelijke kans om beveiligingsproblemen op te lossen. Houd een record bij van de gouden installatiekopieën die in productie zijn vrijgegeven.

Versie-artefacten behouden

Bewaar een catalogus met alle geïmplementeerde assets en hun versies. Deze informatie is nuttig tijdens het classificeren van incidenten, wanneer u problemen beperkt en wanneer u het systeem weer in de werkstatus krijgt. Versiebeheerassets kunnen ook worden vergeleken met gepubliceerde CVE-kennisgevingen (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 beveiligingsoplossingen te versnellen. Het proces kan communicatie tussen teams omvatten. De pijplijn moet snelle implementaties voor het doorsturen en terugdraaien van implementaties mogelijk maken die betrekking hebben op beveiligingsoplossingen, kritieke bugs en code-updates die buiten de normale levenscyclus van de implementatie plaatsvinden.

Notitie

Altijd prioriteit geven aan beveiligingsoplossingen ten opzichte van het gemak. Een beveiligingsoplossing mag geen regressie of bug introduceren. Als u de oplossing wilt versnellen via een pijplijn voor noodgevallen, 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.

Codebeveiliging gedurende de hele levenscyclus onderhouden

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

Patchbeheer. Software, bibliotheken en infrastructuuronderdelen up-to-date houden 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 buiten bedrijf stellen die verouderd of niet meer in gebruik zijn. Hierdoor vermindert u het oppervlak van de toepassing.

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

Verbeter continu uw beveiligingscoderingsprocedures om het bedreigingslandschap bij te houden.

Azure-facilitering

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

Defender for DevOps en de SAST-hulpprogramma's zijn opgenomen als onderdeel van GitHub Advanced Security of Azure DevOps. Met deze hulpprogramma's kunt u een beveiligingsscore voor uw organisatie bijhouden.

Volg de aanbevelingen voor Azure-beveiliging die in deze resources worden beschreven:

Als u referenties in de broncode wilt vinden, kunt u overwegen om hulpprogramma's zoals GitHub Advanced Security en OWASP-hulpprogramma's voor broncodeanalyse te gebruiken.

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

Controlelijst voor beveiliging

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor beveiliging