Externe bestandspartners aansluiten én veilig uitfaseren

Begin met de samenwerking en de eigenaar

Leg eerst vast waarvoor de verbinding bestaat. Welke gegevens worden uitgewisseld, welke organisatie ontvangt ze en welk bedrijfsproces is daarvan afhankelijk? Wijs vervolgens een zakelijke eigenaar aan die de toegang kan goedkeuren en een technisch contact dat wijzigingen uitvoert. Eén naam zonder vervanger is kwetsbaar wanneer iemand afwezig is of van functie verandert.

Dat sluit aan bij het NCSC-advies over toekennen en intrekken van toegang: rechten moeten passen bij de werkzaamheden en de benodigde periode. De vertaling naar bestandspartners vraagt ook aandacht voor technische accounts, die na het vertrek van een contactpersoon gewoon kunnen blijven functioneren.

Scheid mensen, systemen en serveridentiteit

Een medewerker die handmatig bestanden ophaalt heeft een andere rol dan een systeem dat iedere nacht een bestand aflevert. Gebruik daarom herkenbare identiteiten voor personen en technische koppelingen. Leg bij een technische identiteit vast welke toepassing haar gebruikt, wie verantwoordelijk is en voor welk doel toegang is toegestaan.

Maak daarnaast onderscheid tussen de sleutel waarmee een partner zich aanmeldt en de hostsleutel waarmee de server wordt herkend. Deze functies staan afzonderlijk beschreven in de SSH-architectuur van de IETF. Spreek af hoe een nieuwe serveridentiteit of gewijzigde sleutel wordt geverifieerd. Een onverwachte wijziging is een reden om de afgesproken contactpersoon te raadplegen, voordat vertrouwen wordt aangepast.

Test de rechten die de partner werkelijk heeft

Een handige openingsmap zegt weinig over de rest van de toegang. In Control-M MFT Enterprise 9.0.22 kan een gebruiker met een specifieke standaardmap ook andere geautoriseerde mappen bereiken. Controleer daarom de totale toekenning, inclusief groepen, en beperk handelingen afzonderlijk: uploaden, downloaden, hernoemen en verwijderen zijn verschillende bevoegdheden.

De BMC-documentatie over virtuele mappen maakt dat concreet. Bij een conflict tussen gebruikers- en groepsrechten gaat daar de ruimere autorisatie voor. Dit is productspecifiek gedrag. Een test moet dus niet alleen bewijzen dat de gewenste overdracht lukt, maar ook dat ongewenste toegang wordt geweigerd.

Een fictieve leverancier als voorbeeld

Stel: een leverancier levert dagelijks voorraadbestanden aan. De leverancier hoeft alleen te uploaden; een interne toepassing verwerkt de bestanden. Een aparte contactpersoon behandelt wijzigingen. De onderstaande afspraken vormen een eenvoudige partnerkaart. Dit is een fictief voorbeeld, geen beschrijving van een klantimplementatie.

Op een smal scherm kun je de tabel zijwaarts verschuiven. Met een toetsenbord: focus de tabel en gebruik de pijltjestoetsen.

Behandel wijzigingen en afscheid als vaste stappen

Plan een herbeoordeling wanneer de leverancier een andere toepassing gebruikt, een contactpersoon vertrekt of extra gegevens nodig heeft. Controleer dan ook bestaande rechten. Alleen nieuwe rechten toevoegen kan ertoe leiden dat oude bevoegdheden zonder reden blijven bestaan.

Bij beëindiging begin je met de vraag welke processen nog afhankelijk zijn van de verbinding. Spreek af wanneer nieuwe aanlevering stopt en wie eventuele restbestanden afhandelt. Trek daarna toegangsmiddelen en rechten volgens die afspraak in. Controleer expliciet wat er gebeurt met bestaande sessies en andere toegangspaden; het uitzetten van één account is geen bewijs dat alles is afgesloten.

Behandel opgeslagen bestanden afzonderlijk. Toegang intrekken betekent niet automatisch dat gegevens worden verwijderd. Leg vast welke bewaartermijn, overdracht of verwijderafspraak geldt en bewaar een bevestiging van de uitgevoerde afsluiting. Noteer wie de afsluiting goedkeurde en wie haar controleerde.

Wel doen en niet doen

Wel doen: controleer toegang vanuit de partnerrol en documenteer ook wat die rol niet mag. Maak een sleutelwissel onderdeel van een afgesproken wijzigingsproces.

Niet doen: vertrouw op een gedeelde gebruikersnaam, een herkenbare mapnaam of een oude contactlijst als bewijs dat toegang nog passend is. Laat een aflopende samenwerking niet automatisch doorlopen omdat de overdracht technisch blijft werken.

Actualiteit: componentversies blijven relevant

Gecontroleerd op 29 oktober 2026. OpenSSH 10.5, uitgebracht op 11 augustus 2026, bevat onder meer een correctie rond sleutelbeperkingen. Dit is een uitgebrachte upstreamversie, geen uitspraak over ieder MFT-product. Stel vast welke SSH-component jouw oplossing gebruikt en welke leveranciersupdates beschikbaar zijn. Gebruik dit als onderhoudscontext, niet als algemene waarschuwing over alle partnerverbindingen.

Korte vragen over partnertoegang

Moet iedere partner een eigen account hebben? Kies identiteiten waarmee doel, eigenaar en rechten afzonderlijk beheerd kunnen worden. Eén organisatie kan meerdere toepassingen en mensen hebben met verschillende behoeften.

Is een sleutel voldoende om toegang veilig te regelen? Een sleutel is een toegangsmiddel. Rechten, serververificatie, eigenaarschap en intrekking blijven afzonderlijke afspraken.

Wanneer is uitfasering afgerond? Wanneer de afgesproken toegang is beëindigd, afhankelijke processen zijn afgehandeld en de behandeling van achtergebleven gegevens is vastgelegd.

Lees meer over Managed File Transfer of gebruik een MFT Risk & Modernisation Scan als vertrekpunt om de huidige inrichting te bespreken.