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 onderstaande 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.

CICD-pijplijnextensies presenteren hackers met mogelijkheden 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 van derden die toegang tot de code vereisen (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 onderstaande diagram ziet u een voorbeeld van effectief geheim, wachtwoord, toegangstoken en certificaatbeheer.

Diagram illustreert geheim- en certificaatbeheer, zoals hieronder wordt beschreven.

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 veilige 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

Ter bescherming tegen beveiligingsincidenten zijn hieronder meer aanbevolen procedures om uw DevOps-platformomgevingen te versterken. 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 van derden 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

  • Door de ontwikkelomgeving te beveiligen, kunt u Zero Trust-principes implementeren in uw ontwikkelomgevingen 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.
  • Het beveiligen van DevOps-omgevingen voor Zero Trust beschrijft aanbevolen procedures voor het beveiligen van uw DevOps-omgevingen met een Zero Trust-benadering om te voorkomen dat hackers in gevaar komen voor ontwikkelaarsvakken, het infecteren van releasepijplijnen met schadelijke scripts en het verkrijgen van toegang 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.