De toekomst van (Privileged) Access Management

In IT-omgevingen worden sommige geheimen goed beheerd en sommige blijven onder de radar. Hier is een snelle checklist van welke soorten geheimen bedrijven doorgaans beheren, inclusief één type dat ze zouden moeten beheren:

  • Wachtwoorden (x)
  • TLS-certificaten (x)
  • Rekeningen (x)
  • SSH-sleutels ???

De hierboven genoemde geheimen worden doorgaans beveiligd met privileged access management (PAM)-oplossingen of iets dergelijks. Toch praten de meeste traditionele PAM-leveranciers nauwelijks over SSH-sleutelbeheer. De reden is simpel: ze hebben niet de technologie om het goed te doen.

We kunnen het bewijzen. Al onze SSH-keymanagementklanten hebben een traditionele PAM geïmplementeerd, maar ze realiseerden zich dat ze er geen SSH-sleutels mee konden beheren. Traditionele PAM’s kunnen hooguit 20% van alle sleutels ontdekken, laat staan ​​beheren.

Wat is er zo bijzonder aan SSH-sleutels?

SSH-sleutels zijn toegangsreferenties in het Secure Shell (SSH)-protocol. In veel opzichten lijken ze op wachtwoorden, maar functioneel gezien verschillen ze. Bovendien zijn sleutels vaak talrijker dan wachtwoorden, vooral in IT-omgevingen die al lang bestaan, in een verhouding van 10:1. Hoewel slechts enkele wachtwoorden geprivilegieerd zijn, bijna alle SSH-sleutels deuren openen naar iets waardevols.

Eén sleutel kan ook deuren openen naar meerdere servers, net als een loper in oude landhuizen. Een root-sleutel geeft beheerders toegang tot één server of meerdere servers. Nadat we een risicobeoordeling hadden uitgevoerd, ontdekte een van onze klanten een root-sleutel die toegang gaf tot AL hun servers.

Een ander risico is dat iedereen zelf SSH-sleutels kan voorzien. Ze worden niet centraal beheerd en dat is zo ontworpen. Daarom is sleutelproliferatie een hardnekkig probleem in grootschalige IT-omgevingen.

En er is nog meer: ​​sleutels hebben standaard geen identiteit, dus ze delen of dupliceren is heel eenvoudig. En ook met derden. Standaard verlopen sleutels nooit.

Bovendien zijn er interactieve en geautomatiseerde verbindingen, waarvan de laatste het meest voorkomen. Miljoenen geautomatiseerde application-to-application, server-to-server en machine-to-machine verbindingen worden elke dag uitgevoerd met behulp van SSH, maar niet genoeg organisaties (de meeste van hen zijn onze klanten) hebben controle over machine SSH-referenties.

Ik denk dat u het punt wel begrijpt: uw IT-omgeving staat misschien vol met sleutels tot uw koninkrijk, maar u weet niet hoeveel er zijn, wie ze gebruikt, welke legitiem zijn en welke u moet verwijderen. De sleutels hebben geen houdbaarheidsdatum en er kunnen er naar believen meer worden aangemaakt zonder dat u daar goed toezicht op hebt.

Het kernprobleem is uw kernprobleem.

Waarom kunnen traditionele PAM’s niet met SSH-sleutels overweg??

Omdat SSH-sleutels functioneel verschillen van wachtwoorden, beheren traditionele PAM’s ze niet zo goed. Legacy PAM’s zijn gebouwd om wachtwoorden te bewaren en ze proberen hetzelfde te doen met sleutels. Zonder al te veel in detail te treden over de functionaliteit van sleutels (zoals openbare en privésleutels), werkt het bewaren van privésleutels en het op verzoek uitdelen ervan gewoonweg niet. Sleutels moeten aan de serverzijde worden beveiligd, anders is het zinloos om ze onder controle te houden.

Bovendien moet uw oplossing eerst sleutels ontdekken om ze te beheren. De meeste PAM’s kunnen dat niet. Er zijn ook belangrijke configuratiebestanden en andere belangrijke(!) elementen bij betrokken die traditionele PAM’s missen. Lees meer in het volgende document:

SSH-sleutelbeheer: waarom falen PAM-tools bij het beheren van SSH-sleutels?

Uw PAM is niet compleet zonder SSH-sleutelbeheer

Zelfs als uw organisatie 100% van uw wachtwoorden beheert, is de kans groot dat u nog steeds 80% van uw kritieke inloggegevens mist als u geen SSH-sleutels beheert. Als de uitvinders van het Secure Shell (SSH)-protocol zijn wij bij SSH Communications Security de oorspronkelijke bron van de toegangsreferentie die de SSH-sleutel wordt genoemd. Wij kennen de ins en outs van hun beheer.

Uw PAM is niet toekomstbestendig zonder toegang zonder inloggegevens

Laten we terugkeren naar het onderwerp wachtwoorden. Zelfs als u ze hebt opgeslagen, beheert u ze niet op de best mogelijke manier. Moderne, dynamische omgevingen – met behulp van interne of gehoste cloudservers, containers of Kubernetes-orkestratie – werken niet goed met kluizen of met PAM’s die 20 jaar geleden zijn gebouwd.

Daarom bieden we moderne ephemeral access aan, waarbij de geheimen die nodig zijn om toegang te krijgen tot een doel just-in-time voor de sessie worden verleend en automatisch verlopen zodra de authenticatie is voltooid. Dit laat geen wachtwoorden of sleutels over om te beheren – helemaal niet. Onze oplossing is ook niet-intrusief: de implementatie ervan vereist minimale wijzigingen in uw productieomgeving.

Hoe is dat voor het verkleinen van het aanvalsoppervlak, het elimineren van complexiteit, het besparen op kosten en het minimaliseren van risico’s? Lees hier meer:

De toekomst van cyberbeveiliging is wachtwoordloos en sleutelloos

De beste manier om wachtwoorden EN sleutels te beheren is dus: om ze helemaal niet te hoeven beheren en in plaats daarvan overstappen op het beheer van vluchtige geheimen. Zoals dit:

“Ik wou dat ik nog steeds wachtwoorden en sleutels wisselde.” Dat heeft nog nooit een klant gezegd!

Als je eenmaal credential-less bent, ga je niet meer terug. Neem het van onze klanten aan die onze oplossing hebben beoordeeld met een NPS-score van 71 – wat astronomisch is in het cybersecurityveld.

Traditionele PAM’s hebben tot nu toe goed gewerkt, maar het is tijd om uw omgeving toekomstbestendig te maken met een moderne oplossing waarmee u wachtwoordloos en sleutelloos kunt gaan. In een tempo dat voor u comfortabel is.

Ontdek onze PrivX Zero Trust Suite en leer hoe u op een uitgebreide manier toegang en geheimen kunt beheren.

Thijs Van der Does