Delen via


De ontwikkelomgeving beveiligen voor Zero Trust

Dit artikel helpt u, als ontwikkelaar, om uw ontwikkelomgeving te beveiligen, zodat u Zero Trust-principes kunt implementeren (expliciet verifiëren, minimale toegang tot bevoegdheden gebruiken, inbreuk aannemen). Het bevat inhoud uit ons eBook Enterprise DevOps Environments beveiligen en markeert aanbevolen procedures voor vertakkingsbeveiliging en vertrouwde hulpprogramma's, extensies en integraties.

De snelheid van ontwikkelaars is afhankelijk van uw vermogen om te werken hoe en waar u bedrijfsresultaten wilt maximaliseren. U wilt krachtige, aanpasbare machines met hoofd- of beheerderstoegang. De vraag van ontwikkelaars kan echter in strijd zijn met nalevingsvoorschriften en de noodzaak om de toegang en opslag van privéwerknemers te controleren en te beheren.

Niet-beheerde machines die verbinding maken met het netwerk van de organisatie, uitdaging beveiligingsteams, inkoop en de governance board. Het beste scenario van het bieden van ontwikkelaars aan standaard- en beperkte werknemersomgevingen maakt minachting aan beide zijden. Wanneer werknemers vanaf elke locatie verbinding maken, zijn kwetsbare Wi-Fi-netwerken een open deur voor cyberaanvallen. Hardwarediefstal en -verlies zijn grote zorgen.

Beveiligingsproblemen worden uitgebreid tot integraties van ontwikkelomgevingen. Ontwikkelhulpprogramma's met uitgebreide uitbreidbaarheid kunnen niet-ingesloten integraties hebben in hun marketplaces. Schadelijke extensies kunnen ontwikkelhulpprogramma's in gevaar brengen en inbreuk op het hele bedrijf veroorzaken.

In het onderstaande diagram ziet u hoe de ontwikkelomgeving verbinding maakt met de DevOps Tools-omgeving om invloed te hebben op Git-vertakkingen. Het vergroot het omgevingsoppervlak via verbinding met opensource-pakketten en toepassingsextensies. Extensies presenteren aanvalsvectoren in beveiligingsproblemen met afhankelijkheids- en extensietoepassingen.

Diagram illustreert ontwikkelomgevingen en beveiligingsrisico's zoals beschreven in het vorige eBook en samengevat in gerelateerde artikelen die hier zijn gekoppeld.

Het bieden van DevOps-teamleden flexibiliteit en controle terwijl schadelijke aanvallen voorkomen, is een fundamentele uitdaging voor beveiligingskantoren. DevOps kan de ontwikkelomgeving beheren met een cloudomgeving (zie Vertrouwde lancering voor Azure-VM's en GitHub Enterprise Cloud Docs) en beveilig de ontwikkelomgeving met containers (zie documentatie voor GitHub Codespaces).

Daarnaast kunnen ontwikkelaars deze Zero Trust-maatregelen implementeren om de ontwikkelomgeving te beveiligen:

  • Minimale bevoegdheden configureren.
  • Beperken wie code kan wijzigen en goedkeuren met vertakkingsbeveiliging.
  • Gebruik alleen vertrouwde hulpprogramma's, extensies en integraties.

Aanbevolen procedures voor minimale bevoegdheden

Ontwikkelaars geloven vaak dat ze malware, phishing en schendingen in hun omgeving kunnen ondervangen. Grote bedreigingsoppervlakken voor ontwikkelaarsomgevingen maken het onrealistisch voor ontwikkelaars om alomtegenwoordige systeemkennis te behouden. Een organisatie verliest kostbare hersteltijd wanneer een inbreuk wordt gedetecteerd na een aanval, waardoor een ontwikkelomgeving met beheerderstoegang tot alle systemen wordt aangetast.

Als u potentiële toegangsmogelijkheden wilt herstellen die ervoor zorgen dat hackers zich richten op de rol van softwareontwikkelaar, moet u de volgende best practices voor beveiliging met minimale bevoegdheden van Zero Trust voor apps overwegen.

  • Implementeer minimale bevoegdheden en Just-In-Time-toegang voor DevOps. Zorg ervoor dat teamleden slechts minimale toegang tot omgevingen behouden voor de kortste vereiste tijd. Beleid instellen om beheerderstoegangsrechten te dekken op hoofdapparaten, DevOps-hulpprogramma's, releasepijplijnen, codeopslagplaatsen, omgevingen, geheime archieven en databases. Voor DevOps-teams is de basisvereiste een verbinding met het identiteitsarchief van de organisatie. Gebruik identiteitsfederatie voor integratie met SaaS-omgevingen om duplicatie van identiteiten op platforms van derden te voorkomen en blootstellingsrisico's te verminderen.
  • Gebruik geen persoonlijke toegangstokens voor broncodetoegang. Beveiligde procedures voor DevOps-teams omvatten toegang tot DevOps-hulpprogramma's op basis van SaaS, codeopslagplaatsen (via SSH, HTTPS of persoonlijk toegangstoken). Voor toegang tot op SaaS gebaseerde omgevingen hebt u duidelijke instructies voor de wijze waarop toegangsprincipes bepalen wie code-opslagplaatsen van systemen kan downloaden (klonen) en vanaf welke apparaten (lokaal, cloud en container). OneDrive kan bijvoorbeeld de toegang tot onbeheerde apparaten blokkeren of beperken.
  • GitHub Enterprise Managed User-gebruikersaccounts (EMU) standaardiseren en synchroniseren met zakelijke identiteiten. Met beheerde ondernemingsgebruikers kunt u de gebruikersaccounts van uw enterprise-leden beheren via uw id-provider (IdP). Definieer in het identiteitsarchief van uw organisatie expliciet GitHub-gebruikersnamen, e-mailberichten en weergavenamen. Gebruikers identificeren vervolgens eenvoudig samenwerkers.
  • Voor de drie manieren waarop een ontwikkelaar verbinding kan maken met een SaaS-omgeving (HTTPS met een identiteit, persoonlijk toegangstoken, verbinding maken met SSH-sleutel), maakt u verbindingen met het identiteitsarchief van de organisatie. Met GitHub (met uitzondering van GitHub EMU-accounts) is uw identiteit altijd uw openbare identiteit. Gecontroleerde toegang via eenmalige aanmelding (SSO) vereist verbinding met het identiteitsarchief van de organisatie.
  • Gebruik een SSH-certificeringsinstantie (CA) om ondertekende SSH-certificaten te bieden voor leden om veilig toegang te krijgen tot resources met Git. Een SSH-certificaat is een mechanisme voor één SSH-sleutel om een andere SSH-sleutel te ondertekenen. GitHub Enterprise Cloud ondersteunt SSH-certificaten om organisaties meer controle te geven over hoe leden toegang hebben tot opslagplaatsen. Beheer s kunnen hun openbare SSH-CA-sleutel uploaden en certificaten verlenen voor leden die voor Git-verificatie moeten worden gebruikt. Certificaten hebben alleen toegang tot opslagplaatsen die deel uitmaken van de organisatie. Beheer kunnen vereisen dat leden certificaten gebruiken bij het openen van hun opslagplaatsen.
  • Gebruik een Git-referentiebeheer om de toegang tot uw code te beperken. Hulpprogramma's zoals Visual Studio (VS) bieden ingebouwde ondersteuning voor identiteiten. VS Code wordt uitgesteld naar een Git-referentiebeheerder.

Aanbevolen procedures voor vertakkingsbeveiliging

Wanneer hackers toegang krijgen tot de codeopslagplaats, kunnen ze de systeembeveiliging bestuderen en code wijzigen zonder dat teams dat hoeven te doen. Implementeer een vertakkingsstrategie om toegang tot niet-geautoriseerde codeopslagplaats te voorkomen om controle over codewijzigingen tot stand te brengen (zie het voorbeeld in het volgende diagram).

Diagram illustreert een voorbeeld van een vertakkingsstrategie die de hoofdopslagplaats beveiligt.

Als u potentiële toegangsmogelijkheden voor opslagplaatsen wilt herstellen, moet u de volgende aanbevolen procedures voor vertakkingsbeveiliging overwegen.

  • Beveilig vertakkingen met codebeoordelingen om DevOps-teams controle te geven over codewijzigingen en controlevoorschotten. De vertakkingsstrategie in het voorgaande diagram geeft een gecontroleerde stroom van wijzigingen weer die een duidelijke reeks opdrachten en blauwdrukken biedt voor het oplossen van codewijzigingen. Een van de verschillende benaderingen voor de vertakkingsstrategie is dat beveiligde vertakkingen fungeren als de bron voor nieuwe releases naar productie.
  • Beheerders van Git-opslagplaatsen kunnen goedkeuringsautorisaties beheren. Het controlemechanisme van vertakkingsstrategieën bevindt zich in de goedkeuringswerkstroom. Beveiligde vertakkingen vereisen validaties, beoordelingen en goedkeuringen voordat u wijzigingen accepteert. Een optie is het maken van een vertakkingsbeveiligingsregel om werkstromen af te dwingen. U moet bijvoorbeeld een goedkeuringsbeoordeling of statuscontrolepas vereisen voor alle pull-aanvragen die zijn samengevoegd in de beveiligde vertakking. Met vertakkingsbeleid kunnen teams belangrijke takken van ontwikkeling beschermen. Beleidsregels dwingen de codekwaliteits- en wijzigingsbeheerstandaarden van uw team af.

Aanbevolen procedures voor het vertrouwen van hulpprogramma's, extensies en integraties

Uitbreidbaarheid in geïntegreerde ontwikkelomgevingen (IDE) is zo productief dat het in feite een verplichte functie is. U vertrouwt op de mogelijkheid om extensies toe te passen en te cureren binnen de marketplace van een specifieke IDE om uw optimale werkomgeving te ontwerpen.

Als u beveiligde IDE's wilt herstellen, kunt u de volgende aanbevolen procedures voor hulpprogramma's, extensies en integratie overwegen.

  • Zorg ervoor dat u alleen hulpprogramma's van vertrouwde marketplaces en uitgevers integreert. De VS Code Marketplace heeft bijvoorbeeld duizenden extensies om uw leven gemakkelijker te maken. Wanneer uw teams echter nieuwe hulpprogramma's of extensies aannemen, kan het belangrijkste aspect de betrouwbaarheid van een uitgever verifiëren.
  • Stel veilige procedures in om het gebruik van extensies te beheren om de kwetsbaarheid voor aanvallen van ontwikkelomgevingen te beperken. Voor de meeste IDE-extensies moeten bepaalde bevoegdheden worden goedgekeurd, vaak als een bestand met leesmachtigingen voor het systeem om code te analyseren. Extensies vereisen verbindingen met cloudomgevingen om te kunnen functioneren (algemeen in metrische hulpprogramma's). Het goedkeuren van extra functies boven op de IDE opent organisaties tot meer bedreigingen.
  • Houd op ontwikkelcomputers het aantal en de volwassenheid van gebruikte extensies bij om inzicht te krijgen in het potentiële kwetsbaarheid voor aanvallen. Alleen VS Code Marketplace-extensies van geverifieerde uitgevers opnemen. Wanneer u toepassingsextensies installeert met VS Code, controleert u regelmatig de extensies die u uitvoert met de opdrachtregel, code --list-extensions --show-versions. Zorg voor een goed begrip van uitbreidbare onderdelen die u uitvoert in uw ontwikkelomgeving.

Volgende stappen

  • Door Zero Trust-beveiliging in te sluiten in uw werkstroom voor ontwikkelaars, kunt u snel en veilig innoveren.
  • Beveilig de DevOps-platformomgeving om Zero Trust-principes te implementeren in uw DevOps-platformomgeving en markeert aanbevolen procedures voor geheim- en certificaatbeheer.
  • Veilige DevOps-omgevingen voor Zero Trust beschrijven aanbevolen procedures voor het beveiligen van uw DevOps-omgevingen met een Zero Trust-benadering om te voorkomen dat hackers in gevaar komen voor ontwikkelaarsvakken, releasepijplijnen infecteren met schadelijke scripts en toegang krijgen tot productiegegevens via testomgevingen.
  • Implementeer Zero Trust-principes zoals beschreven in memorandum 22-09 (ter ondersteuning van de Amerikaanse executive order 14028, Verbetering van de Cyber Security van de natie) met behulp van Microsoft Entra ID als gecentraliseerd identiteitsbeheersysteem.
  • Versnel en beveilig uw code met Azure DevOps met hulpprogramma's die ontwikkelaars de snelste en veiligste code bieden voor cloudervaring.
  • Configureer Azure om de OIDC van GitHub te vertrouwen als een federatieve identiteit. Met OpenID Verbinding maken (OIDC) hebben uw GitHub Actions-werkstromen toegang tot resources in Azurezonder dat u de Azure-referenties hoeft op te slaan als GitHub-geheimen met een lange levensduur.