Delen via

Aanbevelingen voor het beveiligen van een ontwikkelingslevenscyclus

  • Artikel

Van toepassing op deze aanbeveling voor de Well-Architected Security-checklist: Power Platform

ZOO:02 Zorgen voor een veilige ontwikkelingslevenscyclus door gebruik te maken van een versterkte, grotendeels geautomatiseerde en controleerbare softwaretoeleveringsketen. Integreer een veilig ontwerp door gebruik te maken van bedreigingsmodellering ter bescherming tegen implementaties die de veiligheid ondermijnen.

In deze guide vindt u de aanbevelingen voor het beveiligen van uw code en ontwikkelomgeving door best practices op het gebied van beveiliging toe te passen gedurende de gehele ontwikkelingscyclus.

De kern van een workload wordt gevormd door de onderdelen die de bedrijfslogica implementeren. Deze onderdelen kunnen een mix zijn van elementen met weinig code, zoals canvas-apps en stromen, en code-first-elementen zoals invoegtoepassingen. Alle onderdelen waaruit uw workload bestaat, moeten vrij zijn van beveiligingsfouten om de vertrouwelijkheid, integriteit en beschikbaarheid te garanderen.

Het beveiligen van het infrastructuurvlak met identiteits- en netwerkcontroles is belangrijk, maar niet voldoende. Voorkom een slechte implementatie van Power Platform-workloads en gecompromitteerde activiteiten in die workloads om uw algehele beveiligingsstatus te versterken. Het proces waarbij u beveiliging in uw ontwikkelingslevenscyclus integreert is in wezen een versterkingsproces. Net als het versterken van resources is het aanscherpen van de codeontwikkeling ook contextonafhankelijk. De focus ligt op het verbeteren van de beveiliging, niet op de functionele eisen van de toepassing.

Definities

Term Definitie
Security Development Lifecycle (SDL) Een reeks praktijken die worden aangeboden door Microsoft ter ondersteuning van beveiligingsgaranties en nalevingsvereisten.
Software Development Lifecycle (SDLC) Een uit meerdere fasen bestaand, systematisch proces voor het ontwikkelen van softwaresystemen.

Belangrijke ontwerpstrategieën

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

  • Ontwerpkeuzes leiden niet tot gaten in de beveiliging.
  • Onderdelen met weinig code en code-first onderdelen en configuratie creëren geen kwetsbaarheden vanwege exploiteerbare implementatie en onjuiste coderingspraktijken.
  • Er wordt niet geknoeid met onderdelen met weinig code en code-first-onderdelen en implementatieprocessen.
  • Kwetsbaarheden die door incidenten aan het licht komen, worden beperkt.
  • De nalevingsvereisten worden niet aangetast of verminderd.
  • Auditlogboekregistratie wordt in alle omgevingen geïmplementeerd.

In de volgende secties vindt u beveiligingsstrategieën voor de vaak toegepaste fasen van SDLC.

Vereistenfase

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

Denk bijvoorbeeld aan een workload waarbij gebruikers gegevens binnen een toepassing invoeren en wijzigen. De beveiligingsontwerpkeuzes moeten zekerheden omvatten voor de interactie van de gebruiker met de gegevens, zoals het verifiëren en autoriseren van de gebruikersidentiteit, en het toestaan van uitsluitend toegestane acties op de gegevens. Niet-functionele vereisten hebben betrekking op beschikbaarheid, bruikbaarheid en onderhoudbaarheid. Beveiligingskeuzes moeten segmentatiegrenzen, inkomend en uitgaand verkeer van de firewall en andere overstijgende beveiligingsproblemen omvatten.

Al deze beslissingen moeten leiden tot een goede definitie van de beveiligingsstatus van de workload. Documenteer de beveiligingseisen in een overeengekomen specificatie en geef deze weer in de backlog. In het document moeten de beveiligingsinvesteringen expliciet worden beschreven en de afwegingen en risico's die het bedrijf bereid is te nemen als de investeringen niet worden goedgekeurd door zakelijke belanghebbenden. U kunt bijvoorbeeld de noodzaak van het gebruik van een IP-firewall in Power Platform-omgevingen benoemen om uw organisatiegegevens te beschermen door Dataverse-toegang te beperken tot alleen toegestane IP-locaties. Als zakelijke belanghebbenden niet bereid zijn de extra kosten van het gebruik van een oplossing als Beheerde omgevingen te dragen, moeten ze bereid zijn het risico te aanvaarden dat organisatieresources toegankelijk zijn vanaf openbare locaties, zoals een koffietentje. Nog een voorbeeld: stelt u zich eens voor dat uw toepassing verbinding moet maken met een gegevensbron van een externe partij. Power Platform heeft hiervoor mogelijk een kant-en-klare connector, maar ondersteunt mogelijk niet de verificatievereisten die zijn goedgekeurd door uw beveiligingsteams. In dit geval zijn uw beveiligingsbelanghebbenden mogelijk bereid het risico te aanvaarden van het gebruik van een niet-goedgekeurde methode voor identiteitscontrole. Als alternatief kunt naar het gebruik van een aangepaste connector kijken, terwijl u de voordelen ervan afweegt tegen een langere ontwikkeltijd en potentiële projectvertraging.

Het verzamelen van beveiligingsvereisten is een cruciaal onderdeel van deze fase. Zonder deze inspanning zullen de ontwerp- en implementatiefasen gebaseerd zijn op onuitgesproken keuzes, wat kan leiden tot hiaten in de beveiliging of veranderende vereisten die de ontwikkelingstijd zullen verlengen. Mogelijk moet u de implementatie later wijzigen om de beveiliging te garanderen, wat kostbaar kan zijn.

Ontwerpfase

Tijdens deze fase worden de beveiligingsvereisten omgezet naar technische vereisten. Documenteer in uw technische specificatie alle ontwerpbeslissingen om onduidelijkheid tijdens de implementatie te voorkomen. Hieronder vindt u een aantal gebruikelijke taken:

  • De beveiligingsdimensie van de architectuur bepalen. De architectuur afdekken met beveiligingsmaatregelen. Denk hierbij aan controles die praktisch zijn op het gebied van de netwerkisolatiegrenzen, de soorten identiteiten en methoden voor identiteitscontrole die nodig zijn voor de onderdelen van de workload en het type versleutelingsmethoden dat moet worden gebruikt.

  • De door het platform geboden mogelijkheden evalueren. Het is belangrijk om de scheiding van verantwoordelijkheid tussen u en Power Platform te begrijpen. Vermijd overlap of duplicatie met de in Power Platform ingebouwde beveiligingsmaatregelen. U krijgt een betere beveiligingsdekking en kunt ontwikkelingsresources opnieuw toewijzen aan de behoeften van de toepassen.

    In plaats van aangepaste logica te maken die niet-goedgekeurde gebruikspatronen in apps en stromen reactief identificeert en waarschuwt, kunt u, bijvoorbeeld, beleid ter voorkoming van gegevensverlies gebruiken om te categoriseren hoe connectoren kunnen worden gebruikt.

    Kies alleen vertrouwde referentie-implementaties, sjablonen, codecomponenten, scripts en bibliotheken. Uw ontwerp moet ook beveiligd versiebeheer specificeren. Toepassingsafhankelijkheden moeten afkomstig zijn uit vertrouwde partijen. Externe leveranciers moeten aan uw beveiligingsvereisten kunnen voldoen en hun plan voor verantwoorde openbaarmaking naleven. Elk beveiligingsincident moet onmiddellijk worden gemeld, zodat u de nodige maatregelen kunt treffen. Ook zijn bepaalde bibliotheken of referentie-implementaties mogelijk verboden door uw organisatie. Zelfs als die bijvoorbeeld veilig is en vrij van kwetsbaarheden zijn, kunnen ze nog steeds niet worden toegestaan, omdat ze functies gebruiken die nog niet zijn goedgekeurd door uw organisatie, licentiebeperkingen of het ondersteuningsmodel van de referentie-implementatie.

    Om ervoor te zorgen dat deze richtlijnen worden gevolgd, houdt u een lijst bij van goedgekeurde en/of niet-goedgekeurde raamwerken, bibliotheken en leveranciers, en zorgt u ervoor dat uw makers deze lijst kennen. Breng indien nodig vangnetten aan in de ontwikkelingspijplijnen om de lijst te ondersteunen. Automatiseer zoveel mogelijk het gebruik van tools om afhankelijkheden op kwetsbaarheden te scannen.

  • Bewaar toepassingsgeheimen op een beveiligde manier. Implementeer het gebruik van toepassingsgeheimen en vooraf gedeelde sleutels die uw toepassing gebruikt op een veilige manier. Referenties en toepassingsgeheimen mogen nooit worden opgeslagen in de broncode van de workload (app of stroom). Gebruik externe bronnen zoals Azure Key Vault om ervoor te zorgen dat, als uw broncode beschikbaar komt voor een potentiële aanvaller, er geen verdere toegang kan worden verkregen.

  • Maak op een veilige wijze verbinding met uw gegevens. Gebruik de sterke beveiligingsfuncties die Microsoft Dataverse biedt om uw gegevens te beschermen, zoals op rollen gebaseerde beveiliging en op kolomniveau. Gebruik voor andere gegevensbronnen connectoren met veilige methoden voor identiteitscontrole. Vermijd zoekopdrachten waarbij gebruikersnaam en wachtwoord in platte tekst worden opgeslagen. Vermijd HTTP voor het maken van aangepaste connectoren.

  • Bepaal hoe eindgebruikers met de workload en gegevens kunnen werken. Bedenk of gebruikers directe toegang tot de gegevens krijgen, welk toegangsniveau ze nodig hebben en waar ze toegang krijgen tot de gegevens. Denk na over hoe toepassingen met eindgebruikers worden gedeeld. Zorg ervoor dat alleen de mensen die toegang nodig hebben tot de app en gegevens toegang hebben. Vermijd complexe beveiligingsmodellen die tijdelijke oplossingen aanmoedigen om beveiligingsblokkers te vermijden.

  • Vermijd harde codering. Vermijd harde codering van URL's en sleutels. Vermijd bijvoorbeeld harde codering van de URL of sleutel naar de backend-service in een Power Automate HTTP-actie. Gebruik in plaats daarvan een aangepaste connector of gebruik een omgevingsvariabele voor de URL en Azure Key Vault voor de API-sleutel.

  • Definieer testplannen. Definieer duidelijke testscenario's voor beveiligingsvereisten. Evalueer of u die tests in uw pijplijnen kunt automatiseren. Als uw team processen voor handmatig testen heeft, neem dan beveiligingsvereisten voor die tests op.

Opmerking

Voer tijdens deze fase bedreigingsmodellering uit. Met bedreigingsmodellering kunt u controleren of ontwerpkeuzes zijn afgestemd op de beveiligingsvereisten en hiaten blootleggen die u moet verhelpen. Als uw workload zeer gevoelige gegevens verwerkt, investeer dan in beveiligingsexperts die u kunnen helpen bij het uitvoeren van bedreigingsmodellering.

De eerste bedreigingsmodellering moet plaatsvinden tijdens de ontwerpfase, wanneer de architectuur van de software en het ontwerp op hoog niveau worden gedefinieerd. Als u dit tijdens die fase doet, kunt u potentiële beveiligingsproblemen identificeren voordat ze in de systeemstructuur worden opgenomen. Dit is echter geen eenmalige activiteit. Het is een doorlopend proces dat gedurende de hele evolutie van de software moet worden voortgezet.

Zie Aanbevelingen voor bedreigingsanalyse voor meer informatie.

Ontwikkelings- en testfase

Het doel tijdens deze fase is het voorkomen van beveiligingsfouten en knoeien met code, build en implementatiepijplijnen.

Wees goed getraind in veilige coderingspraktijken

Het ontwikkelingsteam zou training in veilige coderingspraktijken moeten hebben gevolgd. Ontwikkelaars moeten bijvoorbeeld bekend zijn met beveiligingsconcepten in Microsoft Dataverse voor het implementeren van een beveiligingsmodel met de minste bevoegdheden, inhoudsbeveiligingsbeleid voor modelgestuurde apps om insluiting in vertrouwde domeinen te beperken, en verificatiemethoden voor connectoren/on-premises gateways.

Ontwikkelaars moeten deze training voltooien voordat ze aan de slag gaan met Power Platform-workloads.

Voer interne peer-codebeoordelingen uit om continu leren te stimuleren.

Gebruik tools voor codeanalyse

Solution Checker moet worden gebruikt voor Power Platform-resources en de broncode van elke traditionele code kan worden gecontroleerd op mogelijke beveiligingsfouten, inclusief de aanwezigheid van referenties in de code. Identificeer mogelijke gevallen van blootstelling van referenties en geheimen in broncode en configuratiebestanden. Dit is een goed moment om te bekijken hoe verbindingsreferenties in productie worden verwerkt.

Fuzz-tests uitvoeren

Gebruik onjuiste en onverwachte gegevens om te controleren op kwetsbaarheden en om de foutafhandeling te valideren, wat vooral belangrijk is bij oplossingen die Power Pages bevatten.

Schrijf precies voldoende code

Wanneer u de codevoetafdruk verkleint, verkleint u ook de kans op beveiligingsfouten. Hergebruik code en bibliotheken die al in gebruik zijn en waarvan de beveiliging is gecontroleerd in plaats van code te dupliceren. Opensource-softwaredetectie en versiecontrole, kwetsbaarheid en wettelijke verplichtingen. Er zijn steeds meer opensource-Power Platform-resources, dus dit mag niet over het hoofd worden gezien. Indien mogelijk moet dit tijdens de ontwerpfase worden besproken om lastminute problemen te voorkomen.

Ontwikkelaarsomgevingen beschermen

Werkstations van ontwikkelaars moeten worden beschermd met krachtige netwerk- en identiteitscontroles om blootstelling te voorkomen. Zorg ervoor dat beveiligingsupdates zorgvuldig worden toegepast.

De broncodeopslagplaats moet ook worden beveiligd. Verleen toegang tot opslagplaatsen voor code op een 'need-to-know'-basis en verminder de blootstelling aan kwetsbaarheden zoveel mogelijk om aanvallen te vermijden. Zorg voor een grondig proces om code te controleren op beveiligingslekken. Gebruik daarvoor beveiligingsgroepen en implementeer een goedkeuringsproces dat is gebaseerd op zakelijke redenen.

Code-implementaties beveiligen

Het is niet voldoende om alleen de code te beveiligen. Als deze in exploiteerbare pijplijnen draait, zijn alle veiligheidsinspanningen nutteloos en onvolledig. Ook build- en release-omgevingen moeten worden beschermd, omdat u wilt voorkomen dat kwaadwillenden schadelijke code in uw pijplijn uitvoeren.

Houd een actuele inventaris bij van elk onderdeel dat in uw toepassing is geïntegreerd

Elk nieuw onderdeel dat in een toepassing wordt geïntegreerd, vergroot het aanvalsoppervlak. Om te zorgen voor een goede verantwoording en waarschuwingen wanneer nieuwe onderdelen worden toegevoegd of bijgewerkt, moet u een inventaris van deze onderdelen hebben. Controleer regelmatig of uw manifest overeenkomt met wat er in uw build-proces zit. Als u dit doet, zorgt u ervoor dat er niet onverwacht nieuwe onderdelen worden toegevoegd die backdoors of andere malware bevatten.

We raden u aan Pijplijnen voor Power Platform te gebruiken voor uw implementaties. Breid pijplijnen uit met GitHub Actions. Als u GitHub-workflows gebruikt, geef dan de voorkeur aan taken die door uzelf zijn gemaakt. Microsoft Valideer taken ook, omdat ze worden uitgevoerd in de beveiligingscontext van uw pijplijn.

Verken het gebruik van service-principals voor implementatie.

Productiefase

De productiefase biedt de laatste verantwoorde kans om hiaten in de beveiliging te dichten. Houd een overzicht bij van de gouden installatiekopie die in productie wordt genomen.

Bewaar artefacten voor versiebeheer

Houd een catalogus bij van alle geïmplementeerde assets en hun versies. Deze informatie is handig tijdens de beoordeling van incidenten, wanneer u problemen probeert te verhelpen en wanneer u het systeem weer in werkende staat wilt krijgen. Assets met versiebeheer kunnen ook worden vergeleken met gepubliceerde CVE-kennisgevingen (Common Vulnerabilities and Exposures). U moet automatisering gebruiken om deze vergelijkingen uit te voeren.

Noodoplossingen

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 wordt doorgaans geassocieerd met meerdere goedkeuringspoorten. Overweeg een noodproces in te stellen om beveiligingsoplossingen te versnellen. Voor dit proces is mogelijk communicatie tussen teams nodig. De pijplijn moet snelle vooruitdraai- en terugdraai-implementaties mogelijk maken, waarmee beveiligingsoplossingen, kritieke bugs en code-updates worden aangepakt die buiten de reguliere implementatielevenscyclus plaatsvinden.

Opmerking

Geef altijd voorrang aan beveiligingsoplossingen boven gemak. Een beveiligingsoplossing mag geen regressie of bug introduceren. Als u de oplossing via een noodpijplijn wilt versnellen, overweeg dan zorgvuldig welke geautomatiseerde tests kunnen worden omzeild. Evalueer de waarde van elke test ten opzichte van de uitvoeringstijd. Unit-tests worden bijvoorbeeld meestal snel voltooid. Integratie- of end-to-end-tests kunnen veel tijd in beslag nemen.

Houd verschillende omgevingen van elkaar gescheiden

Productiegegevens mogen niet worden gebruikt in lagere omgevingen,** omdat die omgevingen mogelijk niet over de strikte beveiligingscontroles beschikken die productie wel heeft. Vermijd het verbinden van een niet-productietoepassing met een productiedatabase en vermijd het verbinden van niet-productie-onderdelen met productienetwerken.

Gebruik progressieve blootstelling

Gebruik progressieve blootstelling om functies vrij te geven aan een subset van gebruikers op basis van gekozen criteria. Als er problemen zijn, blijft de impact voor die gebruikers tot een minimum beperkt. Deze aanpak is een veelgebruikte strategie voor risicobeperking, strategie omdat deze het oppervlak verkleint. Naarmate de functie verder wordt ontwikkeld en u meer vertrouwen krijgt in beveiligingsgaranties, kunt u deze geleidelijk vrijgeven aan een bredere groep gebruikers.

Onderhoudsfase

In deze fase is het doel om te zorgen dat de beveiligingsstatus in de loop van de tijd niet verslechtert. SDLC is een doorlopend agile proces. Concepten uit de voorgaande fasen zijn van toepassing op deze fase, omdat vereisten in de loop van de tijd veranderen.

Continue verbetering. Blijf de veiligheid van het softwareontwikkelingsproces voortdurend beoordelen en verbeteren door rekening te houden met codebeoordelingen, feedback, geleerde lessen en evoluerende bedreigingen, evenals met nieuwe functies die beschikbaar zijn gesteld door Power Platform.

Maak een einde aan verouderde activa die verouderd zijn of niet meer in gebruik zijn. Hierdoor wordt het oppervlak van de toepassing kleiner.

Onderhoud omvat ook het oplossen van incidenten. Als er problemen worden aangetroffen tijdens productie, moeten deze onmiddellijk weer in het proces worden geïntegreerd, zodat ze zich niet herhalen.

Blijf uw veilige coderingspraktijken voortdurend verbeteren om gelijke tred te houden met het bedreigingslandschap.

SDL in Microsoft Power Platform

Power Platform is gebouwd op een cultuur en methodologie van veilig ontwerp. Zowel de cultuur als de methodologie worden voortdurend versterkt door toonaangevende Security Development Lifecycle- (SDL) en Threat Modeling-praktijken van Microsoft.

Het robuuste beoordelingsproces van Threat Modeling zorgt ervoor dat bedreigingen tijdens de ontwerpfase worden vastgesteld, de gevolgen worden beperkt en er validatie plaatsvindt om er zeker van te zijn dat de bedreigingen onschadelijk zijn gemaakt.

Threat Modeling houdt ook rekening met alle wijzigingen aan services die al live zijn door middel van continue regelmatige beoordelingen. Gebruik van het STRIDE-model helpt om de meest voorkomende problemen met onveilig ontwerp aan te pakken.

MicrosoftDe SDL van is gelijkwaardig aan het OWASP Software Assurance Maturity Model (SAMM). ... Beide zijn gebaseerd op het uitgangspunt dat een veilig ontwerp een integraal onderdeel is van de beveiliging van webtoepassingen. Zie OWASP top 10-risico's: beperkingen in Power Platform voor meer informatie.

Power Platform-facilitering

Microsoft Security Development Lifecycle (SDL) beveelt veilige werkwijzen aan die u kunt toepassen op uw ontwikkelingscyclus. Voor meer informatie, zie Microsoft Security Development Lifecycle.

Defender voor DevOps en de SAST-tools (Static Application Security Testing) zijn opgenomen als onderdeel van GitHub Advanced Security en Azure DevOps. Met deze tools kunt u een beveiligingsscore voor uw organisatie bijhouden.

Met de oplossingscontrolefunctie kunt u een uitgebreide statische analysecontrole op uw oplossingen uitvoeren waarbij een set regels voor best practices wordt toegepast, en deze problematische patronen snel vaststellen. Zie Oplossingscontrole gebruiken om uw oplossingen te valideren.

Controlelijst voor beveiliging

Raadpleeg de volledige reeks aanbevelingen.

Veiligheidscontrolelijst