Op deze blog kon je eerder al lezen hoe je developers makkelijker, sneller, goedkoper en veiliger laat ontwikkelen via een internal development platform. Nu willen we ook rond security een volgende stap zetten: de resource plane van het platform automatiseren en beveiligen, zonder gebruik van SSH. Een controversieel idee? Misschien, maar wel één dat wat onmogelijk lijkt, toch mogelijk maakt.
Het idee kwam ter sprake tijdens een rondetafelgesprek met enkele CIO’s en CEO’s. Een klant van BRYXX merkte op dat hij het gebruik van SSH in combinatie met Ansible ronduit onveilig vond: hij moest immers vanaf één punt met admin-toegang SSH openzetten op alle servers. Zijn bedrijf was daarom al een tijd eerder overgestapt op Puppet — een oplossing die het gebruik van SSH volledig overbodig kan maken.
Laten we die denkoefening daarom eens maken. Hoe zet je zoiets op touw? Hoe schakel je rechtstreekse SSH-toegang tot je servers volledig uit? En waarom zou je dat in godsnaam willen? Omdat je er méér mee bereikt, met minder moeite en meer veiligheid, zo blijkt. Maar daar komen we straks op terug.
Hoe ga je te werk?
Met Puppet bouw je een internal development platform dat niet alleen een developer plane biedt, waarin ontwikkelaars snel en veilig werken, maar ook een resource plane, dat servers en andere infrastructuur ontsluit voor interne gebruikers. Het resultaat: alle interactie met de infrastructuur verloopt via dat platform, inclusief het centraal verzamelen en visualiseren van logs via een log aggregator zoals Splunk.
Niemand heeft zo nog rechtstreekse toegang nodig tot individuele servers om logs te raadplegen, commando’s uit te voeren of grote wijzigingen door te voeren. Al die acties verlopen voortaan via de Puppet master of via configuration management code — dus nooit handmatig. En ook die automatisch handelingen zijn te volgen via logs. Zo is van elke wijziging exact te traceren wie wat wanneer heeft gedaan.
Waarom zou je zo’n platform opzetten?
Stel dat je de logs van een binnenkomend pakketje wil volgen. Dan moet je vandaag misschien vier of vijf Remote Shells open hebben staan om toegang te krijgen tot evenveel servers. Met ons platform volstaat één blik in de log aggregator, waarin het hele traject in één keer zichtbaar is.
Dus ja, je geeft iets op: je kan niet meer handmatig op een server inloggen. Maar je hoeft dat ook niet meer te doen. Je bereikt méér met minder moeite, en met een veel kleinere aanvalsoppervlakte. Want we hebben de aanvalsroutes waarlangs hackers kunnen binnendringen en van server naar server hoppen, drastisch beperkt.
Is zo’n platform echt haalbaar?
Absoluut, met de juiste tooling. Je kunt het gebruik van SSH en RDP wel degelijk uitschakelen, zolang je in een goed alternatief voorziet. Zelfs op de Puppet-server hoef je dan geen SSH meer te activeren, ook niet om bijvoorbeeld de brug te slaan tussen IT en OT.
Creëer je dan een single point of failure bij Puppet? Niet noodzakelijk. Je kunt Puppet high available opzetten, met een failover. Natuurlijk verleg je het risico zo enigszins, maar met de juiste role-based access control beperk je dat risico meteen aanzienlijk: gebruikers krijgen alleen toegang tot wat ze echt nodig hebben. En het beheer van die rechten gebeurt in een afgeschermde Active Directory.
Zelfs als een hacker de credentials van een developer weet te bemachtigen, kan hij dus alleen doen waarvoor die developer rechten heeft. Inloggen op de Puppet master via SSH? Niet mogelijk. En zelfs áls de hacker daar wel in zou slagen, dan nog kan hij er niets uitvoeren zonder sporen na te laten.
Gaat het toch mis?
Dan is er nog altijd een break-the-glass procedure: een noodmechanisme om tijdelijk SSH-toegang in te schakelen en in te grijpen.