Delen via


Veelgestelde vragen over Power Platform-beveiliging

Veelgestelde vragen over Power Platform-beveiliging vallen in twee categorieën:

  • Op welke manier Power Platform is ontworpen om de top 10 van Open Web Application Security project® (OWASP)-risico's te helpen verminderen

  • Vragen die onze klanten stellen

Om het voor u gemakkelijker te maken om de laatste informatie te vinden, zijn aan het einde van dit artikel nieuwe vragen toegevoegd.

OWASP top 10-risico's: mitigaties in Power Platform

Het Open Web Application Security Project® (OWASP) is een stichting zonder winstoogmerk die zich inzet voor het verbeteren van softwarebeveiliging. Door middel van door de gemeenschap geleide opensource-softwareprojecten, honderden lokale afdelingen over de hele wereld, tienduizenden leden en toonaangevende onderwijs- en trainingsconferenties, is de OWASP Foundation de bron voor ontwikkelaars en technologen om het web te beveiligen.

De OWASP top 10 is een standaard bewustwordingsdocument voor ontwikkelaars en anderen die geïnteresseerd zijn in de beveiliging van webtoepassingen. Het vertegenwoordigt een brede consensus over de meest kritieke beveiligingsrisico's voor webtoepassingen. In dit gedeelte bespreken we hoe Power Platform helpt om deze risico's te beperken.

A01:2021 Niet-werkend toegangsbeheer

  • Het Power Platform-beveiligingsmodel is gebaseerd op Least Privileged Access (LPA). Met LPA kunnen klanten toepassingen bouwen met meer gedetailleerde toegangscontrole.
  • Power Platform gebruikt Microsoft Entra ID's (Microsoft Entra ID) Microsoft Identity-platform voor autorisatie van alle API-aanroepen met het industriestandaardprotocol OAuth 2.0.
  • Dataverse, dat de onderliggende gegevens levert voor Power Platform, heeft een uitgebreid beveiligingsmodel dat beveiliging op omgevingsniveau, op rollen gebaseerd en op record- en veldniveau omvat.

A02:2021 Cryptografische fouten

Gegevens in transit:

  • Power Platform gebruikt TLS om al het op HTTP gebaseerde netwerkverkeer te versleutelen. Het gebruikt andere mechanismen om niet-HTTP-netwerkverkeer te versleutelen dat klant- of vertrouwelijke gegevens bevat.
  • Power Platform maakt gebruik van een beveiligde TLS-configuratie die HTTP Strict Transport Security (HSTS) mogelijk maakt:
    • TLS 1.2 of hoger
    • Op ECDHE gebaseerde suites met coderingsmethoden en NIST-curven
    • Sterke sleutels

Data-at-rest:

  • Alle klantgegevens worden versleuteld voordat ze naar niet-vluchtige opslagmedia worden geschreven.

A03:2021 Injectie

Power Platform gebruikt industriestandaard aanbevolen procedures om injectieaanvallen te voorkomen, waaronder:

  • Veilige API's gebruiken met geparameteriseerde interfaces
  • Toepassen van de steeds veranderende mogelijkheden van front-endframeworks om invoer op te schonen
  • De uitvoer opschonen met validatie aan de serverzijde
  • Tools voor statische analyse gebruiken tijdens het bouwen
  • Elke zes maanden beoordelen van het dreigingsmodel van elke service, ongeacht of de code, het ontwerp of de infrastructuur is bijgewerkt of niet

A04:2021 Onveilig ontwerp

  • Power Platform is gebouwd op een cultuur en methodologie van veilig ontwerp. Zowel cultuur als methodologie worden voortdurend versterkt door de toonaangevende praktijken van Microsoft voor Security Development Lifecycle (SDL) en Threat Modeling.
  • 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.
  • Microsoft's SDL is gelijk 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.

A05:2021 Onjuiste configuratie van beveiliging

  • 'Standaard weigeren' is een van de fundamenten van Power Platform-ontwerpprincipes. Met 'Standaard weigeren' moeten klanten nieuwe functies en configuraties bekijken en zich aanmelden.
  • Eventuele onjuiste configuraties tijdens het maken worden opgevangen door geïntegreerde beveiligingsanalyse met behulp van veilige ontwikkelingstools
  • Daarnaast ondergaat Power Platform Dynamic Analysis Security Testing (DAST) door gebruik te maken van een interne service die is gebaseerd op de OWASP top 10-risico's.

A06:2021 Kwetsbare en verouderde componenten

  • Power Platform volgt de toonaangevende SDL-praktijken van Microsoft om opensource-componenten en componenten van derden te beheren. Deze praktijken omvatten de het bijhouden van een volledige inventaris, het uitvoeren van beveiligingsanalyses, het up-to-date houden van de componenten en het afstemmen ervan op een getest en beproefd responsproces voor beveiligingsincidenten.
  • In zeldzame gevallen kunnen sommige toepassingen kopieën van verouderde componenten bevatten vanwege externe afhankelijkheden. Nadat deze afhankelijkheden echter zijn aangepakt in overeenstemming met de eerder beschreven werkwijzen, worden de componenten bijgehouden en bijgewerkt.

A07:2021 Identificatie- en verificatiefouten

  • Power Platform is gebouwd op en afhankelijk van Microsoft Entra ID voor identificatie en verificatie.
  • Microsoft Entra helpt Power Platform beveiligde functies in te schakelen. Deze functies omvatten eenmalige aanmelding, meervoudige verificatie en één platform, in te schakelen om veiliger te kunnen communiceren met zowel interne als externe gebruikers.
  • Met Power Platform's aanstaande implementatie van Microsoft Entra ID Continuous Access Evaluation (CAE), zullen gebruikersidentificatie en verificatie nog veiliger en betrouwbaarder zijn.

A08:2021 Software- en gegevensintegriteitsfouten

  • Het proces voor componentbeheer van Power Platform dwingt de veilige configuratie van pakketbronbestanden af om software-integriteit te handhaven.
  • Het proces zorgt ervoor dat alleen intern aangekochte pakketten worden aangeboden om vervangingsaanvallen aan te pakken. Vervangingsaanval, ook wel afhankelijkheidsverwarring genoemd, is een techniek die kan worden gebruikt om het om het proces voor het maken van apps in beveiligde bedrijfsomgevingen te schaden.
  • Op alle versleutelde gegevens wordt integriteitsbescherming toegepast voordat ze worden verzonden. Alle metagegevens voor integriteitsbescherming die aanwezig zijn voor inkomende versleutelde gegevens worden gevalideerd.

OWASP top 10 Low Code/No Code-risico's: maatregelen in Power Platform

Zie dit document voor richtlijnen over het beperken van de top 10 Low Code/No Code-beveiligingsrisico's gepubliceerd door OWASP:

Power Platform - OWASP Low Code/No Code Top 10 risico's (april 2024)

Veelvoorkomende beveiligingsvragen van klanten

Hieronder volgen enkele van de beveiligingsvragen die onze klanten stellen.

Hoe beschermt Power Platform tegen clickjacking?

Clickjacking werkt onder andere met ingesloten iframes om de interactie van een gebruiker met een webpagina over te nemen. Het vormt met name een grote bedreiging voor aanmeldingspagina's. Power Platform voorkomt het gebruik van iframes op aanmeldingspagina's, waardoor het risico op clickjacking aanzienlijk wordt verminderd.

Daarnaast kunnen organisaties beleid voor beveiliging van inhoud gebruiken om insluiting te beperken tot vertrouwde domeinen.

Biedt Power Platform ondersteuning voor het beleid voor beveiliging van inhoud?

Power Platform ondersteunt beleid voor beveiliging van inhoud (CSP) voor modelgestuurde apps. We bieden geen ondersteuning voor de volgende headers die zijn vervangen door CSP:

  • X-XSS-Protection
  • X-Frame-Options

Hoe kunnen we veilig verbinding maken met SQL Server?

Zie Veilig Microsoft SQL Server gebruiken met Power Apps.

Welke coderingsmethoden worden ondersteund door Power Platform? Wat is de routekaart naar continu sterkere coderingsmethoden?

Alle Microsoft-services en -producten zijn geconfigureerd om de goedgekeurde suites met coderingsmethoden te gebruiken, in de exacte volgorde zoals aangegeven door de Microsoft Crypto Board. Zie voor de volledige lijst en exacte volgorde de Power Platform-documentatie.

Informatie over afschaffingen van suites met coderingsmethoden wordt gecommuniceerd via de Power Platform-documentatie Belangrijke wijzigingen.

Waarom biedt Power Platform nog steeds ondersteuning voor RSA-CBC-coderingsmethoden (TLS_ECDHE_RSA_with AES_128_CBC_SHA256 (0xC027) en TLS_ECDHE_RSA_with_AES_256_CBC_SHA384 (0xC028)) die als zwakker worden beschouwd?

Microsoft weegt het relatieve risico en de verstoring van klantbewerkingen af bij het kiezen van de ondersteuning voor suites met coderingsmethoden. De RSA-CBC-suites met coderingsmethoden zijn nog niet gecompromitteerd. We hebben ervoor gezorgd dat ze consistentie tussen onze services en producten garanderen en alle klantconfiguraties ondersteunen. Ze staan echter onder aan de prioriteitenlijst.

We zullen deze suites met coderingsmethoden op het juiste moment afgeschaffen, op basis van de doorlopende evaluatie door de Microsoft Crypto Board.

Waarom gebruikt Power Automate MD5-inhoudshashes in trigger-/actie-ingangen en -uitgangen?

Power Automate geeft de optionele inhoud-MD5-hashwaarde die door Azure Storage wordt geretourneerd, door aan de clients. Deze hash wordt door Azure Storage gebruikt om de integriteit van de pagina tijdens transport te verifiëren als een controlesomalgoritme en wordt niet gebruikt als een cryptografische hashfunctie voor beveiligingsdoeleinden in Power Automate. U kunt hier meer informatie over vinden in de Azure Storage-documentatie over het ophalen van blob-eigenschappen en het werken met aanvraagheaders.

Hoe beschermt Power Platform tegen DDoS-aanvallen (Distributed Denial of Service)?

Power Platform is gebouwd op Microsoft Azure en gebruikt Azure DDoS-beveiliging om te beschermen tegen DDoS-aanvallen.

Detecteert Power Platform jailbroken iOS-apparaten en geroote Android-apparaten om organisatiegegevens te beschermen?

We raden u aan Microsoft Intune te gebruiken. Intune is een beheeroplossing voor mobiele apparaten. Het kan helpen bij het beschermen van organisatiegegevens door van gebruikers en apparaten te eisen dat ze aan bepaalde vereisten voldoen. Zie voor meer informatie de instellingen voor nalevingsbeleid van Intune.

Waarom zijn sessiecookies gericht op het bovenliggende domein?

Power Platform richt sessiecookies op het bovenliggende domein om verificatie tussen organisaties mogelijk te maken. Subdomeinen worden niet gebruikt als beveiligingsgrenzen. Ze hosten ook geen klantinhoud.

Hoe kunnen we de toepassingssessie instellen op een time-out na bijvoorbeeld 15 minuten?

Power Platform gebruikt Microsoft Entra ID voor identiteits- en toegangsbeheer. Het volgt de aanbevolen configuratie van Microsoft Entra ID voor sessiebeheer voor een optimale gebruikerservaring.

U kunt omgevingen echter aanpassen om expliciete sessie- en/of activiteittime-outs te hebben. Zie Gebruikerssessie en toegangsbeheer voor meer informatie.

Met Power Platform's aanstaande implementatie van Microsoft Entra ID Continuous Access Evaluation (CAE), zullen gebruikersidentificatie en verificatie nog veiliger en betrouwbaarder zijn.

De toepassing geeft dezelfde gebruiker toegang via meerdere machines of browsers tegelijk. Hoe kunnen we dat voorkomen?

Toegang tot de toepassing via meerdere apparaten of browsers tegelijk is een gemak voor gebruikers. Power Platform's aanstaande implementatie van Microsoft Entra ID Continuous Access Evaluation helpt ervoor te zorgen dat de toegang vanaf geautoriseerde apparaten en browsers plaatsvindt en nog steeds geldig is.

Waarom geven sommige Power Platform-services serverheaders weer met uitgebreide informatie?

Om overbodige informatie in de serverheader te verwijderen, wordt gebruikgemaakt van Power Platform-services. Het doel is om het detailniveau in evenwicht te brengen met het risico van informatie vrijgeven die het algehele beveiligingspostuur zou kunnen verzwakken.

Hoe beïnvloeden Log4j-kwetsbaarheden Power Platform? Wat moeten klanten hierbij doen?

Microsoft heeft vastgesteld dat Log4j-kwetsbaarheden geen invloed hebben op Power Platform. Zie onze blogpost over het voorkomen, detecteren en zoeken naar misbruik van Log4j-kwetsbaarheden.

Hoe kunnen we ongeautoriseerde transacties vanwege browserextensies of Unified Interface Client-API's waardoor uitgeschakelde beveiligingsmechanismen kunnen worden ingeschakeld voorkomen?

Het beveiligingsmodel van Power Apps omvat niet het concept van uitgeschakelde beveiligingsmechanismen. Het uitschakelen van besturingselementen is een verbetering van de gebruikersinterface. U kunt voor de beveiliging beter niet vertrouwen op uitgeschakelde beveiligingsmechanismen. Gebruik liever Dataverse-beveiligingsmechanismen zoals beveiliging op veldniveau om ongeautoriseerde transacties te voorkomen.

Welke HTTP-beveiligingsheaders worden gebruikt om responsgegevens te beschermen?

Meting DETAILS
Strict-Transport-Security Dit wordt ingesteld op max-age=31536000; includeSubDomains voor alle reacties.
X-Frame-Options Dit is afgeschaft ten faveure van CSP.
X-Content-Type-Options Dit wordt ingesteld op nosniff voor alle activumreacties.
Content-Security-Policy Dit wordt ingesteld als de gebruiker CSP inschakelt.
X-XSS-Protection Dit is afgeschaft ten faveure van CSP.

Waar kan ik Power Platform- of Dynamics 365-penetratietests vinden?

De meest recente penetratietests en beveiligingsbeoordelingen zijn te vinden op de Microsoft Service Trust Portal.

Notitie

Als u toegang wilt tot bepaalde bronnen op de Service Trust Portal, moet u zich aanmelden als een geverifieerde gebruiker met uw Microsoft-cloudservicesaccount (Microsoft Entra-organisatieaccount) en de geheimhoudingsovereenkomst van Microsoft voor nalevingsmateriaal controleren en accepteren.

Beveiliging in Microsoft Power Platform
Verifiëren bij Power Platform-services
Verbinding maken met en verifiëren bij gegevensbronnen
Gegevensopslag in Power Platform

Zie ook