Infrastructure as Code (IaC) is in korte tijd uitgegroeid tot een gamechanger in het moderne technologielandschap. Door infrastructuurprovisioning en beheerprocessen te vertalen naar code, krijgen ontwikkelaars versiebeheer en herhaalbaarheid, en worden potentiële kwetsbaarheden verminderd. Maar met de verspreiding ervan komen ook potentiële kwetsbaarheidsproblemen.
GitLab IaC Scanning onderscheidt zich als een effectief en efficiënt middel om verkeerde configuraties en beveiligingslacunes binnen IaC-opstellingen op te sporen en tegelijkertijd tegen deze te beschermen. Deze gids gaat dieper in op de waarde, het installatieproces en de best practices om IaC-configuraties te versterken.
Wat is Infrastructure as Code (IaC)?
Infrastructure as Code (IaC) is een benadering waarbij taken op het gebied van infrastructuurprovisioning, -beheer en -configuratie worden gespecificeerd als code in plaats van via handmatige processen of aangepaste scripts. In plaats van afhankelijk te zijn van handmatige processen voor het provisionen van servers, databases of netwerkinfrastructuurcomponenten, maakt IaC gebruik van standaardcodesjablonen.
De populariteit van IaC kan worden verklaard door de steeds grotere behoefte aan flexibiliteit bij het implementeren en schalen van applicaties. Traditioneel infrastructuurbeheer vereiste een tijdrovende installatie die vaak onderhevig was aan menselijke fouten. IaC biedt consistentie, herhaalbaarheid en snelle updateprocessen door infrastructuur te versioneren, net als softwarecode, waardoor versiebeheer van herhaalbare infrastructuur continu kan worden uitgevoerd zonder menselijk toezicht of fouten.
DevOps-praktijken werken ook goed samen met IaC-praktijken en helpen organisaties de kloof tussen ontwikkeling en operaties te overbruggen. Met IaC kunnen infrastructuurwijzigingen gelijktijdig met de ontwikkeling van applicaties worden geïmplementeerd, wat resulteert in snellere implementatietijden en soepeler pijplijnbeheer. Hun gezamenlijke inspanningen stuwen organisaties naar meer efficiëntie en betrouwbaarheid tijdens implementatieprocessen.
Waarom is IaC-scanning essentieel?
Infrastructure as Code heeft nieuwe mogelijkheden voor potentiële kwetsbaarheden gecreëerd. Ontwikkelaars die scripts schrijven om de implementatie van infrastructuur te automatiseren, kunnen onbedoeld aanzienlijke beveiligingslacunes in een infrastructuurimplementatieproces introduceren. IaC-scanning is essentieel om dergelijke beveiligingslekken op te sporen voordat ze de productieomgeving bereiken.
Moderne cloud-native infrastructuren kunnen behoorlijk dynamische en complexe omgevingen zijn; zelfs de meest oplettende ontwikkelaars kunnen configuratiefouten over het hoofd zien, zelfs zonder IaC-scantools die codedefinities doorzoeken om configuratiefouten op te sporen die in strijd zijn met de beste beveiligingspraktijken en datalekken en systeemcompromittering als gevolg van kwetsbaarheden in de infrastructuur. IaC-scantools maken gebruik van Artificial Intelligence-as-a-Consumption-technologie (AIC). Hierdoor verlagen ze aanzienlijk de risico's die verband houden met kwetsbaarheden in de infrastructuur die leiden tot datalekken of systeemcompromittering.
Nu de normen voor compliance en gegevensbescherming zijn aangescherpt, moeten bedrijven vanaf dag één een veilige infrastructuur implementeren om juridische of reputatieschade te voorkomen. IaC-scanning helpt bedrijven om aan deze norm te voldoen door te garanderen dat hun infrastructuur voldoet aan de branchevoorschriften, waardoor ze zichzelf beschermen tegen juridische gevolgen.
Inzicht in GitLab IaC-scanning
De Infrastructure as Code (IaC)-scanningfunctie van GitLab biedt een systematische aanpak om IaC-configuratiebestanden te controleren op mogelijke kwetsbaarheden. Dit zorgt ervoor dat de configuraties voor het inrichten en beheren van de infrastructuur robuust, veilig en compliant zijn. De ondersteuning strekt zich uit tot verschillende IaC-configuratiebestanden, waaronder populaire bestanden zoals Terraform, Ansible, AWS CloudFormation en Kubernetes.
- Vereisten en compatibiliteit
- Ondersteunde bestanden en aanpassing
- Configuratie en aanpassing van regels
- Automatische oplossing van kwetsbaarheden
1. Vereisten en compatibiliteit
Effectieve IaC-scanning vereist dat er binnen de testfase wordt gewerkt, aangezien het moet worden opgenomen in het .gitlab-ci.yml-bestand van deze fase.
- De minimale RAM-vereisten moeten 4 GB zijn om de prestaties te maximaliseren.
- Standaard is GitLab Runner met Docker- of Kubernetes-executor verplicht (en automatisch ingeschakeld voor GitLab.com-gebruikers). IaC-scanninganalysatoren zijn echter mogelijk niet compatibel met niet-amd64 CPU-architecturen en het wordt aanbevolen om Docker-versie 19.03.0 te vermijden voor deze taken.
2. Ondersteunde bestanden en aanpassingen
GitLab IaC Scanning biedt uitgebreide ondersteuning, mogelijk gemaakt door de KICS-tool. Configuratiebestanden van Ansible, AWS CloudFormation, Azure Resource Manager Dockerfile, Google Deployment Manager Kubernetes OpenAPI Terraform behoren tot de ondersteunde bestanden; bij het beoordelen van de resultaten moet ook rekening worden gehouden met specifieke vereisten, zoals de noodzaak van JSON-geformatteerde Azure Resource Manager-sjablonen en het ontbreken van ondersteuning voor aangepaste Terraform-modules.
GitLab blijft zich inzetten voor openheid met deze functie door alle open-source (OSS) analysers beschikbaar te stellen via GitLab Free tier. Door de variabele SAST_IMAGE_SUFFIX te manipuleren, kunt u schakelen tussen standaard- en FIPS-versies van afbeeldingen.
3. Configuratie en aanpassing van regels
Het instellen van IaC-scanning in uw project is relatief eenvoudig. U kunt dit handmatig instellen door de sjabloon SAST-IaC.gitlab-ci.yml toe te voegen, die, eenmaal toegevoegd, IaC-scantaken genereert binnen uw CI/CD-pijplijn, of automatisch via samenvoegingsverzoeken – de resultaten van IaC-scantaken worden na voltooiing van het scannen opgeslagen als SAST-rapportartefacten.
Teams die het scanproces willen verbeteren, hebben de mogelijkheid om standaardregels aan te passen. Deze functie omvat de mogelijkheid om:
- Vooraf gedefinieerde regels uit te schakelen.
- Bestaande regels overschrijven met aangepaste definities die van invloed zijn op aspecten zoals ernst of rechtstreeks koppelen aan persoonlijke documentatie.
Het is ook mogelijk om scanprocessen te koppelen aan specifieke analyserversies, ter bescherming in het geval dat updates regressies of ongewenste wijzigingen met zich meebrengen.
4. Automatische oplossing van kwetsbaarheden
GitLab IaC Scanning legt de nadruk op het elimineren van onnodige ruis in rapporten. Om de relevantie te behouden en de focus op actuele kwetsbaarheden te houden, voert het systeem bepaalde automatische acties uit:
1. Regels uitschakelen: Zodra u besluit dat een of meer regels niet langer relevant zijn voor uw project en u deze expliciet hebt uitgeschakeld, worden eerdere rapporten over kwetsbaarheden automatisch opgelost.
2. Regels verwijderen: Als GitLab besluit dat een of meer standaardregels verouderd zijn of te veel valse positieven opleveren, worden ze waarschijnlijk verwijderd en worden alle kwetsbaarheden die door dergelijke regels zijn gemarkeerd automatisch opgelost.
3. Historische gegevens: Het bijhouden van een audittrail is van cruciaal belang. Het kwetsbaarheidsbeheersysteem van GitLab voegt opmerkingen toe, zodat u op de hoogte blijft van eerdere kwetsbaarheden die automatisch zijn opgelost.
4. Regels opnieuw activeren: Door eerder uitgeschakelde regels opnieuw in te schakelen, worden automatisch opgeloste bevindingen opnieuw geopend voor triage, zodat kwetsbaarheden uit het verleden niet onopgemerkt blijven.
Rapportage: inzicht in het JSON-formaat
De IaC-scantool van GitLab geeft de bevindingen weer in gestructureerde JSON-rapporten die voldoen aan de SAST-rapportformaten, waardoor gebruikers uitgebreide resultaten krijgen:
1. Standaardisatie: Dit formaat vergemakkelijkt de integratie en vergelijking tussen verschillende projecten of scans.
2. Toegankelijkheid: Gebruikers kunnen rapporten snel en eenvoudig rechtstreeks downloaden van CI-pijplijnpagina's of pijplijnen voor samenvoegingsverzoeken met behulp van de artefacten: padenrichtlijn naar “gl-sast-report.json”. Om dit te vergemakkelijken, stelt u uw artifacts: paths-richtlijn in op “gl-sast-report.json”.
3. Schemareferentie: GitLab biedt gedetailleerde schemadocumentatie zodat geïnteresseerden die zich hierin willen verdiepen of dit rapport met andere systemen willen integreren, gemakkelijk en volledig toegang hebben tot alle onderdelen ervan.
GitLab IaC-scanning instellen
Laten we eens kijken hoe u GitLab IaC-scanning voor uw projecten kunt instellen.
De stappen voor het instellen van GitLab IaC Scanning zijn –
- Vereisten
- GitLab CI/CD integreren
- Aangepaste configuratie (optioneel)
- De scan uitvoeren
- Resultaten bekijken
1. Vereisten
- GitLab-versie: zorg ervoor dat u versie 12.10 of hoger van GitLab gebruikt.
- Repository instellen: uw Infrastructure as Code-bestanden (zoals Terraform-, CloudFormation- en Kubernetes-configuratiebestanden) moeten deel uitmaken van uw repository.
2. GitLab CI/CD integreren
Om IaC-scanning in te stellen, moet u deze integreren met de GitLab CI/CD-pijplijn.
Maak of update .gitlab-ci.yml in de root van uw repository.
Voeg de volgende configuratie toe:
Include:
template: Security/Infrastructure-Scanning.gitlab-ci.yml
Deze toevoeging activeert de IaC-scantaken binnen uw CI/CD-pijplijn.
3. Aangepaste configuratie (optioneel)
Voor projecten met specifieke vereisten kan het scanproces worden aangepast:
- Aangepaste regels: Met GitLab IaC Scanning kunnen gebruikers aangepaste regels definiëren of bestaande regels wijzigen. Deze kunnen worden toegevoegd aan een .iac-custom-rules-map in de root van uw repository.
- Mappen negeren: als u wilt dat de scanner bepaalde mappen overslaat, kunt u deze definiëren in de CI/CD-configuratie onder variabelen:
Variabelen:
IAC_PATHS: “infrastructure/*,!infrastructure/legacy/”
In het bovenstaande voorbeeld analyseert de scanner alleen bestanden in de map infrastructure en sluit hij de submap legacy uit.
4. De scan uitvoeren
Zodra de configuratie is ingesteld, start u een CI/CD-pijplijnrun. De IaC-scantaken analyseert uw Infrastructure as Code-bestanden en geeft inzicht in mogelijke kwetsbaarheden.
5. Resultaten bekijken
Na de analyse worden de kwetsbaarheden (indien aanwezig) zichtbaar:
- In het samenvoegingsverzoek (als de scan daardoor is geactiveerd).
- In het gedeelte Beveiliging en naleving van uw project.
Hier kunt u:
- Details van de kwetsbaarheid bekijken.
- Deze markeren als opgelost of een issue aanmaken om deze bij te houden.
- Optioneel: automatische acties instellen op basis van de ernst of het type kwetsbaarheid.
Best practices voor veilige IaC (Infrastructure as Code) configuratie
Best practices voor veilige IaC (Infrastructure as Code)-configuratie zijn –
- PoLP-principe (het principe van minimale rechten)
- Versiebeheer en wijzigingen bijhouden
- Afhankelijkheden regelmatig scannen en bijwerken
- Geheimen beschermen
- Configuraties efficiënt valideren en evalueren
1. PoLP-principe (het principe van minimale rechten)
Het Principe van minimale rechten is een essentieel beveiligingsconcept dat ervoor zorgt dat entiteiten (gebruikers, systemen of processen) alleen de rechten krijgen die nodig zijn om hun taken uit te voeren, en niets meer. Dit principe wordt nog belangrijker in IaC-omgevingen met machtigingen die programmatisch kunnen worden toegewezen; wanneer deze onjuist of te ruim worden toegekend, kunnen ze resources blootstellen aan onnodige risico's.
Om te voldoen aan de PoLP-vereisten binnen IaC moeten machtigingen zorgvuldig worden gescript, zodat elke service of functie alleen toegang heeft tot de resources die ze nodig hebben – voor cloudinfrastructuren zoals AWS kan dit betekenen dat alleen-lezenrechten worden toegekend voor S3-buckets in plaats van algemene rechten voor alle opslagbronnen; voortdurende beoordeling van IaC-scripts om ervoor te zorgen dat de rechten strikt blijven naarmate de infrastructuur zich ontwikkelt.
2. Versiebeheer en wijzigingen bijhouden
Versiebeheer is niet alleen nodig bij traditionele softwareontwikkeling, maar speelt ook een essentiële rol bij infrastructuurbeheer in een IaC-omgeving. Het bijhouden van wijzigingen, het terugdraaien van configuraties en het begrijpen van infrastructuuraanpassingen is van cruciaal belang voor het handhaven van een veilige en stabiele omgeving voor IaC-infrastructuurbeheer.
GitLab- en GitHub-platforms voor IaC-configuratie bieden niet alleen tools voor het bijhouden van wijzigingen, maar ook samenwerkingsfuncties om voorgestelde wijzigingen met teamleden te beoordelen voordat ze in productieomgevingen worden geïmplementeerd. Dit peer review-proces zorgt ervoor dat er rekening wordt gehouden met veiligheidskwesties en dat best practices worden nageleefd voordat er belangrijke wijzigingen in IaC-omgevingen worden doorgevoerd.
3. Regelmatig scannen en bijwerken van afhankelijkheden
Net als bij softwareontwikkeling zijn Infrastructure as Code (IaC)-configuraties vaak afhankelijk van sjablonen en modules van derden om de implementatie van infrastructuur te stroomlijnen. Hoewel dergelijke afhankelijkheden de implementatie eenvoudiger kunnen maken, vormen ze ook potentiële kwetsbaarheden als ze verouderd of gecompromitteerd zijn.
Door afhankelijkheden voortdurend te scannen, wordt ervoor gezorgd dat er geen bekende beveiligingskwetsbaarheden in de infrastructuur worden geïntroduceerd. Speciale tools die voor deze taak zijn ontworpen, markeren automatisch verouderde of kwetsbare modules en vragen teams om deze indien nodig bij te werken, net als bij software patchbeheer maar dan specifiek toegepast op infrastructuurmodules om maximale bescherming en veerkracht te bereiken.
4. Bescherm geheimen
De digitale wereld staat vol met waarschuwende verhalen over geheimen die worden onthuld en tot ernstige inbreuken leiden. Door het programmatische karakter van IaC zijn programmeurs geneigd om gevoelige informatie rechtstreeks in scripts te coderen – een onverantwoordelijke praktijk die altijd moet worden vermeden.
Organisaties moeten vermijden om geheimen rechtstreeks in IaC-scripts in te bedden. In plaats daarvan moeten ze speciale oplossingen voor geheimenbeheer gebruiken, zoals HashiCorp Vault of AWS Secrets Manager, om geheimen te beveiligen terwijl ze versleuteld blijven, zodat ze zelfs als configuratiebestanden openbaar worden gemaakt, toch beschermd blijven.
5. Configuraties efficiënt valideren en evalueren
Ervoor zorgen dat IaC-scripts zowel functioneel als veilig zijn, is een voortdurende inspanning die regelmatige beoordeling vereist. Naarmate configuraties veranderen of het IT-landschap verschuift, ontstaan er nieuwe kwetsbaarheden die ervoor kunnen zorgen dat voorheen functionele scripts niet meer werken of zelfs helemaal kapot gaan.
Organisaties moeten ervoor zorgen dat hun IaC-configuraties regelmatig voldoen aan de benchmarks en best practices van de sector om dit scenario te voorkomen. Hiervoor kunnen ze geautomatiseerde testtools gebruiken voor regelmatige controles zonder handmatige tussenkomst. Voordat wijzigingen in productieomgevingen worden doorgevoerd, zijn staging- of testomgevingen van onschatbare waarde om vroegtijdig te waarschuwen voor onverwachte problemen, waardoor veilige en toch operationele infrastructuren in productieomgevingen worden gewaarborgd.
Veelvoorkomende valkuilen in IaC en hoe deze te vermijden
Veelvoorkomende valkuilen bij GitLab IaC-scanning en hoe deze te vermijden?
- Infrastructuurcode behandelen als een eenmalig script
- Het negeren van testen
- Geheimen en inloggegevens hardcoderen
- IaC-scripts te ingewikkeld maken
- Verouderde tools of bibliotheken omzeilen
1. Infrastructuurcode behandelen als een eenmalig script
Een veel voorkomende misvatting over infrastructuurcode (IaC) is dat deze wordt behandeld als een eenmalig script dat één keer wordt geschreven en daarna zelden opnieuw wordt bekeken. In tegenstelling tot eenmalige scripts vereist IaC echter periodieke onderhoudsupdates, herzieningen en revisies, net als elke andere softwarecode.
Hoe te voorkomen: Voer regelmatig codebeoordelingen en updates uit met behulp van tools zoals GitLab IaC Scanning om IaC-configuraties continu te scannen. Zo blijft uw code up-to-date, relevant en vrij van mogelijke kwetsbaarheden.
2. Verwaarlozing van testen
Sommige teams die haast hebben met de implementatie, slaan grondige IaC-scripttests over om snel te kunnen werken – in de veronderstelling dat als iets werkt, alles in orde is – wat kan leiden tot onverwacht gedrag of beveiligingskwetsbaarheden in hun geprovisioneerde infrastructuur. Door deze nalatigheid kunnen onverwacht gedrag onopgemerkt blijven of beveiligingslekken ontstaan die onmiddellijk moeten worden gepatcht bij de implementatie.
Hoe te voorkomen: Net als bij applicatiecode is het testen van IaC-configuraties in niet-productieomgevingen, zoals staging, essentieel om verkeerde configuraties en mogelijke valkuilen in de productieomgeving te voorkomen. GitLab IaC Scanning biedt hier een essentiële service waarmee teams verkeerde configuraties kunnen identificeren voordat deze direct invloed hebben op productieomgevingen.
3. Hardcoding van geheimen en inloggegevens
Hardcoding kan een voor de hand liggende valkuil zijn in IaC-scripts en moet altijd worden vermeden om de gegevensbeveiliging te beschermen. Door geheimen of inloggegevens rechtstreeks in hun code in te bedden, kunnen hardgecodeerde geheimen of inloggegevens aanzienlijke veiligheidsrisico's opleveren die niet mogen worden verwaarloosd.
Hoe te voorkomen: Gebruik speciale tools voor geheimenbeheer in plaats van geheimen rechtstreeks in scripts op te nemen. GitLab IaC-scantools kunnen dergelijke praktijken detecteren door ernaar te scannen als onderdeel van hun scanproces, bijvoorbeeld door ontwikkelaars te waarschuwen voor hardgecodeerde inloggegevens in hun configuratiebestanden.
4. IaC-scripts te ingewikkeld maken
Bij hun pogingen om één oplossing te ontwikkelen die elk mogelijk scenario dekt, maken sommige engineers IaC-scripts te ingewikkeld. Hoewel dit verschillende situaties efficiënter kan dekken, creëert het ook onnodige complicaties en potentiële zwakke punten in hun IaC-oplossingen.
Hoe te voorkomen: Geef prioriteit aan eenvoud en duidelijkheid door complexe configuraties op te splitsen in beheersbare modules met behulp van GitLab IaC Scanning; inspecteer deze modules regelmatig met GitLab IaC Scanning, zodat ze effectief, veilig en functioneel blijven.
5. Vermijd verouderde tools of bibliotheken
IaC is vaak afhankelijk van tools of bibliotheken van derden, maar naarmate deze externe bronnen zich ontwikkelen, kunnen bepaalde functies of mogelijkheden verouderd raken. Het gebruik van verouderde methoden kan zowel functionele als beveiligingsrisico's met zich meebrengen.
Hoe te voorkomen: Houd actief toezicht op alle tools of bibliotheken van derden waarvan uw IaC-configuraties afhankelijk zijn, werk scripts regelmatig bij om rekening te houden met bijgewerkte versies en aanbevelingen, en gebruik scantools zoals GitLab IaC Scanning die verouderde functies of afhankelijkheden markeren.
SentinelOne in actie zien
Ontdek hoe AI-gestuurde cloudbeveiliging uw organisatie kan beschermen in een één-op-één demo met een SentinelOne productexpert.
Vraag een demo aanConclusie
GitLab IaC-scanning kan beveiligingslekken detecteren en afhankelijkheden afhandelen. U kunt valse positieven elimineren, aangepaste regels instellen en audittrails bijhouden. Het maakt rapportage ook een stuk gemakkelijker en u kunt GitLab IaC-scanning eenvoudig integreren in uw CI/CD-pijplijn voor de beste resultaten. Bescherm geheimen, houd versiebeheer en wijzigingstracking bij en pas het principe van minimale toegangsrechten toe met de GitLab IaC-scanner. Het helpt u bij het efficiënt evalueren en beheren van uw configuraties voor een soepel infrastructuurbeheer.
Veelgestelde vragen over GitLab IaC-scannen
GitLab IaC Scanning is een ingebouwde CI/CD-functie die uw Infrastructure as Code-bestanden, zoals Terraform, CloudFormation, Ansible, Dockerfiles en Kubernetes-manifesten, controleert op verkeerde configuraties en bekende kwetsbaarheden. Het wordt uitgevoerd tijdens de testfase van uw pijplijn, produceert SAST-rapporten in JSON-formaat en markeert problemen in samenvoegverzoeken, zodat u risicovolle instellingen kunt corrigeren voordat u ze implementeert.
IaC-scanning werd geïntroduceerd in GitLab 14.5, uitgebracht in juni 2021. Vanaf die versie activeren alle ondersteunde IaC-configuratiebestanden in een project automatisch de juiste KICS-gebaseerde analysers tijdens CI-pijplijnen, op voorwaarde dat u de IaC-sjabloon opneemt in uw .gitlab-ci.yml
GitLab's IaC-scanning ondersteunt een breed scala aan configuratiebestanden, allemaal aangedreven door KICS:
- Ansible-playbooks
- AWS CloudFormation (YAML/JSON)
- Azure Resource Manager (JSON)
- Dockerfiles
- Google Deployment Manager
- Kubernetes-manifesten
- OpenAPI-definities
Terraform HCLAls u Bicep gebruikt, compileer dan naar JSON voordat u scant, en houd er rekening mee dat aangepaste Terraform-modules nog niet worden gescand .
Alle IaC-scananalysers in GitLab zijn gebaseerd op KICS (Keep It Configuration Scanner), een open-source-engine die uw IaC-bestanden controleert aan de hand van een uitgebreide set regels. KICS detecteert automatisch ondersteunde formaten en past de juiste controles toe. U kunt regelversies aanpassen, uitschakelen of vastzetten via CI-variabelen of aangepaste regelgidsen .
Om IaC-scannen in te schakelen, voegt u de officiële sjabloon toe aan het bestand .gitlab-ci.yml van uw project, bovenaan:
voeg de volgende regel toe:
- template: Jobs/SAST-IaC.gitlab-ci.yml
Hiermee wordt een iacs-taak in de testfase geïnjecteerd. Op GitLab.com of zelf beheerd met gedeelde runners is geen extra runner-configuratie nodig. Nadat een pijplijn is uitgevoerd, verschijnen de scanresultaten als taakartefacten, in samenvoegverzoeken en onder Beveiliging en naleving .
