Share via


De DevOps-platformomgeving beveiligen voor Zero Trust

Dit artikel helpt u als DevOps-teamlid bij het implementeren van het Zero Trust-principe van minimale bevoegdheden en het beveiligen van de DevOps-platformomgeving. Het bevat inhoud uit ons eBook Enterprise DevOps Environments beveiligen en markeert aanbevolen procedures voor geheim- en certificaatbeheer.

Moderne ondernemingen zijn afhankelijk van DevOps-platforms voor implementatie, waaronder pijplijnen en productieomgevingen die ontwikkelaars nodig hebben om productief te zijn. In het verleden hebben toepassingsbeveiligingsmethoden niet rekening gehouden met de toegenomen kwetsbaarheid voor aanvallen die tegenwoordig pijplijnen en productieomgevingen beschikbaar maken. Naarmate hackers overschakelen en upstream-hulpprogramma's richten, hebt u innovatieve benaderingen nodig om uw DevOps-platformomgevingen te beveiligen.

In het volgende diagram ziet u dat de DevOps-platformomgeving verbinding maakt met de toepassingsomgeving en met pijplijnextensies voor continue integratie en continue levering (CI/CD).

Diagram illustreert DevOps-platformomgevingen en beveiligingsrisico's zoals beschreven in hierboven gekoppeld eBook en samengevat in gerelateerde artikelen die hier zijn gekoppeld.

CI/CD-pijplijnextensies bieden hackers de mogelijkheid om bevoegdheden te escaleren vanuit de toepassingsomgeving. Extensies en integraties verhogen kwetsbaarheid voor aanvallen. Het is essentieel om zich te beschermen tegen bedreigingen voor indringing van malware.

Hoe en waarom aanvallers zich richten op pijplijnen

Pijplijnen en productieomgevingen kunnen onafhankelijk zijn van standaardprocedures en processen voor toepassingsbeveiliging. Ze hebben doorgaans toegangsreferenties op hoog niveau nodig die uitgebreide en zinvolle toegang tot aanvallers kunnen bieden.

Hoewel aanvallers nieuwe manieren vinden om systemen te misbruiken, zijn de meest voorkomende aanvalsvectoren voor pijplijnen:

  • Runtimevariabelen en argumentinjectie extraheren.
  • Scripts die serviceprincipes of referenties ophalen uit pijplijnen.
  • Onjuist geconfigureerde persoonlijke toegangstokens waarmee iedereen met de sleutel toegang heeft tot de DevOps-platformomgeving.
  • Beveiligingsproblemen en onjuiste configuraties in geïntegreerde hulpprogramma's waarvoor toegang tot de code is vereist (vaak alleen-lezen, maar soms schrijftoegang). Geïntegreerde hulpprogramma's kunnen testframeworks, SAST (Static Application Security Testing) en DYNAMISCHE DAST (Application Security Testing) omvatten.

Aanbevolen procedures voor geheim- en certificaatbeheer

Het vermijden van een catastrofale inbreuk kan net zo eenvoudig zijn als effectief geheimbeheer. In het volgende diagram ziet u een voorbeeld van effectief geheim, wachtwoord, toegangstoken en certificaatbeheer.

Diagram illustreert geheim- en certificaatbeheer.

Zoals in het bovenstaande diagram wordt weergegeven, start de ontwikkelaar een build voor een klantaanvraag. GitHub start vervolgens een runner met de rol-id en geheime id van een kluis-app. De vertrouwde entiteit vraagt periodiek een nieuwe geheime id van de kluis aan en haalt de geheime GitHub-id op van GitHub. De kluis gebruikt de rol-id en geheime id van GitHub Secrets om zich aan te melden en assets voor ondertekening van programmacode op te halen. De Runner past de mobiele app aan en ondertekent deze code.

De volgende aanbevolen procedures helpen u bij het bouwen van een beveiligde installatie waarmee geheim en parameterblootstelling wordt geminimaliseerd.

  • Veilige opslag bieden voor geheimen en certificaten in elke levenscyclusfase van de toepassing. Ontwikkel altijd alsof het een opensource-project is. Zorg ervoor dat teams geheimen opslaan in sleutelkluizen in plaats van in de code of in teamomgevingen. Gebruik de Azure Key Vault-cloudservice voor het veilig opslaan en openen van geheimen.
  • 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 Azure zonder dat u de Azure-referenties hoeft op te slaan als GitHub-geheimen met een lange levensduur.

Meer aanbevolen procedures voor DevOps-omgevingsbeveiliging

Bekijk de volgende aanbevolen procedures om uw DevOps-platformomgevingen te versterken om u te beschermen tegen beveiligingsincidenten. Bekijk een gedetailleerde bespreking van deze aanbevelingen in ons eBook Enterprise DevOps Environments beveiligen.

  • Elke DevOps-platformomgeving voorzien van audittrails.Controleer auditlogboeken om bij te houden wie toegang heeft verkregen, welke wijziging heeft plaatsgevonden en de datum/tijd voor elk actief systeem. Neem specifiek DevOps-platforms op met CI/CD-pijplijnen die in productie stromen. Audittrails voor DevOps-hulpprogramma's bieden robuuste manieren om bedreigingen sneller op te lossen, verdachte activiteiten te vinden en te waarschuwen voor mogelijke schendingen of beveiligingsproblemen, en potentiële gegevens of misbruik van bevoegdheden te vinden. Zorg ervoor dat gedetailleerde controle- en audittrails beschikbaar zijn in elke omgeving.
  • Beveilig de softwareleveringsketen. Met elke bibliotheek die u in uw codebase invoert, vouwt u de toeleveringsketen van de software uit en neemt u afhankelijkheden over van elk opensource-project of elk hulpprogramma. Verwijder met voorzichtigheid onnodige bibliotheken en opensource-onderdelen om de kwetsbaarheid voor aanvallen van uw software-toeleveringsketen te verminderen.
  • Automatiseer IaC-sjabloonscans (Infrastructure-as-Code). Met IaC-omgevingen kunt u eenvoudig scannen op onjuiste configuraties, nalevingscontroles en beleidsproblemen. Het implementeren van nalevingscontroles en toegangscontroles verhoogt de beveiligingspostuur van uw hele infrastructuur. Controleer de beveiliging van hulpprogramma-integraties die voldoen aan de systeemvereisten voor automatisering.
  • Goedkeuringswerkstromen automatiseren. Voor elke goedkeuringswerkstroom om code naar productie te pushen, moeten bepaalde automatische of handmatige controles de beveiliging, bedrijfswaarde, status en kwaliteit van elke aanvraag bevestigen. Deze controles fungeren als een poort tussen ontwikkeling en productie om denial-of-service-aanvallen te voorkomen en hackers code in productieomgevingen te injecteren zonder een vlag te markeren of een waarschuwing te activeren.
  • Alleen geverifieerde Integraties van DevOps-hulpprogramma's toestaan. Net als in ontwikkelomgevingen worden DevOps-hulpprogramma's geleverd met extensies en integraties om het DevOps-team efficiënt en veilig te maken. Controleer of geverifieerde integraties de minste bevoegdheid vereisen om hun werk uit te voeren. Implementeer zo mogelijk toegang met minimale bevoegdheden en zorg voor het juiste niveau van lees-/schrijfmachtigingen. Meer informatie over het uitschakelen of beperken van GitHub Actions voor uw organisatie.

Volgende stappen

  • Beveilig de ontwikkelomgeving om Zero Trust-principes in uw ontwikkelomgevingen te implementeren met aanbevolen procedures voor minimale bevoegdheden, vertakkingsbeveiliging en vertrouwende hulpprogramma's, extensies en integraties.
  • Door Zero Trust-beveiliging in te sluiten in uw werkstroom voor ontwikkelaars, kunt u snel en veilig innoveren.
  • 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.