Bedrijven houden IT en OT liefst zo strikt mogelijk gescheiden. Uit veiligheidsoverwegingen, dat spreekt voor zich. Maar tegelijk is die scheiding een utopie. IT en OT hebben meer en meer raakvlakken. Tussen beide een nieuwe drempel opwerpen, vraagt niet alleen tijd en budget. Het ondermijnt ook de beveiliging, omdat gebruikers onvermijdelijk naar achterpoortjes zoeken. Dat kan dus beter, denken we bij BRYXX.
In voorbije bijdragen op onze blog hebben we de tijd voor rework en busy work teruggedrongen en die vrijgekomen tijd geïnvesteerd om de kwaliteit van code te verhogen. We lanceerden ook een controversieel idee, waarbij we niet alleen een internal development platform bouwden voor makkelijkere, goedkopere en veiligere ontwikkeling, maar er ook de resource plane mee automatiseerden en beveiligden, op een zodanige manier dat de veilige weg meteen ook de makkelijkste is.
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.