Veel tools die uit devops zijn ontstaan hebben hun eigen systemen voor secrets-management gekregen. Wanneer je verschillende tools gebruikt voor het bouwen, uitrollen, configureren en beheren van applicaties, en daardoor te maken krijgt met elk zijn eigen mechanisme voor het beheer van security-policies en toegangscontrole, ontstaan er security-eilanden. En die eilanden maken het werk niet makkelijker, en de beveiliging niet sterker.
Door het ontstaan van security-eilanden hebben we te maken met geïsoleerde subsystemen die het security-beheer en het beheer van het hele systeem complexer maken.
Tool of platform
Een security-eiland is een tool of platform dat zijn eigen ingebouwde security-elementen heeft die het beheer van secrets, toegangscontrole, audit en compliance aansturen, maar niet samenwerken met andere tools of security-policies, -management en audit-data ondersteunen.
Security-eilanden zijn het resultaat van niet goed ontworpen security-features zoals nauwkeurige toegangscontrole of een gedetailleerde transactie-audit. Hierdoor moet het doorvoeren van security voor de hele suite aan tools behorend bij security-eilanden stuk voor stuk worden gedaan zonder centraal overzicht.
Wanneer de systemen zo zijn opgezet dat je niet ontkomt aan security-eilanden mis je een geconsolideerde audit- en toegangscontrole en ie het lastig om rechten over te dragen om subsystemen te beheren in een gestandaardiseerde manier. Bovendien heb je geen overzicht van het gehele security-landschap, waardoor het op grote schaal aansturen steeds lastiger wordt.
Een voorbeeld: Jenkins ci/cd-pipelines hebben een set credentials nodig om een applicatie uit te rollen die servers klaarmaakt en testruns draait, en een andere set credentials om de applicatie naar productie om te zetten. Zodra de applicaties zijn uitgerold heeft elke losse applicatie of service zijn credentials nodig om contact te maken met de database en api’s. De Jenkins-server kan ingesteld zijn op het opslaan van de test- en productie-credentials in Jenkins secrets of de credentials plugin. Wanneer de apps naar productie worden gebracht in AWS, kun je de AWS secrets manager gebruiken om de database secrets en api keys op te slaan. Dit zal allemaal werken, maar als het iets complexer wordt, zal het lastig blijken verder op te schalen en alle security via devops-tools te beheren. Het ontbreekt aan de mogelijkheid makkelijk te delegeren, beheren en te auditeren, maar het wordt ook moeilijker om de applicaties van de teams veilig te schalen. En dat is nog niet alles.
Stel dat een tweede team in eenzelfde proces zit met een eigen ci/cd. Hoe blijven de keys consistent bij de twee omgevingen? Hoe zorg je voor rotatie en weet je zeker dat alleen de mensen die de credentials daadwerkelijk moeten hebben toegang hebben? Het wordt nog interessanter wanneer de teams gaan ontwikkelen voor multi-cloud-omgevingen om de weerbaarheid en disaster recovery te versterken. Weer een nieuw security-eiland. Hoe succesvoller een team, hoe slechter de security ervoor komt te staan. En wanneer security complex wordt, gaan teams hun eigen tools kiezen: shaduw-it ofwel menselijk aangestuurde security-eilanden.
Security-eilanden voorkomen
De moderne pipelines die we hebben gemaakt, zijn gericht op snelheid en efficiëntie, en om code te transporteren, maar niet zozeer op beveiliging. De voordelen van deze onderling verbonden systemen zijn duidelijk en we ontkomen ook niet aan het hebben van meerdere tools. Maar we kunnen wel kijken naar technologie die ze verbindt om zo de aansturing te verbeteren en van de security-eilanden af te komen.
Als je kunt werken zonder security-eilanden profiteer je van gecentraliseerde audit, toegangscontrole en beheer. Het is makkelijk om rechten over te dragen en op grote schaal te beheren. Het is duidelijk hoe het security-landschap eruit ziet en hoe de losse machines en services met elkaar samenwerken. Om privileged access voor applicaties te beheren gedurende de software development lifecycle heb je een systeem nodig dat de hele infrastructuur overziet, kan bepalen wie en wat toegang krijgt tot welke resources, alle verbindingen kan auditen en ongewoon gedrag kan monitoren.
In de praktijk moet zo’n systeem vier zaken dus heel goed kunnen: het automatisch toekennen van machine-identiteiten aan applicaties en processen (zoals ci-servers); applicaties uitrollen die naadloos te authenticeren zijn met de resources die ze nodig hebben; centraal beheer van toegangscontrole, en het reduceren van complexiteit voor ontwikkelaars zodat shaduw-it niet nodig is.
