Zo kies je secure password sharing voor leveranciersbeheer
Samenwerking met externe leveranciers brengt onvermijdelijk credential-uitwisseling met zich mee. Een webbureau dat toegang nodig heeft tot uw CMS, een boekhouder die uw boekhoudpakket moet kunnen inzien, een marketingbureau dat uw advertentieaccount beheert — elk van deze relaties vereist op enig moment het veilig delen van inloggegevens.
Waarom leveranciersbeheer een apart geval is
Bij interne medewerkers kunt u werken met gedeelde kluizen, IAM-systemen of Active Directory. Maar leveranciers staan buiten uw infrastructuur. Ze hebben eigen tools, eigen beveiligingsbeleid en eigen voorkeursmethoden. U kunt hen niet dwingen een account aan te maken in uw interne systemen.
Tegelijkertijd draagt u verantwoordelijkheid voor de manier waarop u toegang verleent tot uw eigen systemen. Als u een wachtwoord via e-mail stuurt en dat wachtwoord later blijkt gelekt, kunt u moeilijk aantonen dat u de nodige zorg heeft betracht.
De risico's van de huidige praktijk
Veel organisaties geven leveranciers toegang op een manier die ze bij interne medewerkers nooit zouden accepteren:
- Wachtwoord gedeeld via e-mail of WhatsApp
- Hetzelfde wachtwoord gebruikt voor meerdere leveranciers of periodes
- Geen vervaldatum: de leverancier heeft jarenlang toegang, ook als de samenwerking allang voorbij is
- Geen registratie van wanneer en aan wie toegang is verleend
Elk van deze punten is een risico dat beperkt kan worden zonder grote investering in tijd of geld.
Wat u nodig heeft voor veilig leveranciersbeheer
Tijdgebonden toegang: Geef leveranciers toegang voor de duur van het project, niet permanent. Dat betekent: wachtwoorden die verlopen, of een proces om ze te rouleren bij einde van de samenwerking.
Gecontroleerde overdracht: Het moment waarop u een credential deelt, moet traceerbaar zijn. Niet omdat u leveranciers wantrouwt, maar omdat u bij een incident moet kunnen reconstrueren wat er is gebeurd.
Geen afhankelijkheid van de ontvangende partij: U kunt niet eisen dat alle leveranciers dezelfde tool installeren. De credential-overdracht moet werken ongeacht welke tools uw leverancier gebruikt.
Eenmalig gebruik: Als de credential eenmaal is opgehaald, moet hij niet blijven rondzwerven. One-time links bieden deze garantie automatisch.
Hoe u het praktisch aanpakt
Een workable aanpak voor leveranciersbeheer ziet er als volgt uit:
- Inventariseer welke leveranciers toegang hebben tot welke systemen. Dit overzicht ontbreekt in veel organisaties.
- Stel een beleid in: toegang wordt alleen verleend via de aangewezen tool, voor een specifieke periode.
- Gebruik een one-time link tool zoals PassTransfer voor het overdragen van credentials. De leverancier ontvangt een link, haalt de credentials op en de link verdwijnt.
- Noteer in uw projectadministratie wanneer toegang is verleend en voor welke periode.
- Roteer wachtwoorden bij einde van elke leveranciersrelatie; lees ook waarom u een wachtwoord roteert nadat u het heeft gedeeld.
Vergelijking van aanpakken
Gedeeld wachtwoord via e-mail: Goedkoop, maar geen controle over verspreiding of levensduur. Wachtwoord blijft in inbox staan.
Tijdelijke gebruikersaccount: Ideaal als het platform het ondersteunt. Vereist echter dat u administratortoegang heeft en dat het platform individuele accounts ondersteunt.
One-time link: Werkt altijd, ongeacht het platform. De ontvanger heeft geen account nodig, de link vervalt automatisch. Nadeel: u deelt het wachtwoord zelf, niet een tijdelijk account.
De meest pragmatische aanpak combineert beide: maak indien mogelijk tijdelijke accounts aan en gebruik one-time links zoals PassTransfer voor het veilig communiceren van de bijbehorende inloggegevens.
PassTransfer in leverancierscontext
PassTransfer is ontworpen voor precies deze situatie: u wilt iets veilig doorgeven aan iemand buiten uw organisatie, zonder dat die persoon iets hoeft te installeren of zich hoeft te registreren. U stelt een vervaldatum in die past bij uw project, kopieert de link en stuurt die via uw gebruikelijke communicatiekanaal. De credential zelf reist nooit via dat kanaal mee. Lees ook hoe u tijdelijke toegang deelt met leveranciers of implementatiepartners.
