Inleiding: een verkeerde verzending legt geen werknemersprobleem bloot, maar een rechtenprobleem
Een werkplaats voor additieve productie ontving een klacht van een klant: een modelbestand dat uitsluitend naar de verantwoordelijke van dat project mocht worden gestuurd, was door een medewerker die inmiddels van functie was veranderd via een persoonlijk e-mailadres doorgestuurd naar een externe branchegenoot. Bij de evaluatie ontdekte het bedrijf dat drie zaken tegelijk waar waren: de toegangsrechten van de medewerker tot het oude project waren na de functiewijziging nooit ingetrokken; voor het downloaden van bestanden was geen enkele goedkeuring vereist; en het systeem bevatte helemaal geen registratie van wie welk bestand op welk moment had gedownload. Samen maakten deze drie tekortkomingen van een handeling die had kunnen worden onderschept een gegevenslek dat niet meer aantoonbaar kon worden onderbouwd.
Dergelijke incidenten zijn bij 3D-printbedrijven niet ongewoon. De sector richt de aandacht vaak op encryptie, geheimhoudingsovereenkomsten en watermerken, maar wat de gegevensgrenzen werkelijk bepaalt, is het account- en rechtenstelsel: wie wat mag zien, wie toegang heeft goedgekeurd en welke sporen toegang heeft achtergelaten. Deze regels omzetten in een uitvoerbare engineeringaanpak is effectiever dan nog tien geheimhoudingsovereenkomsten ondertekenen.
I. Waarom rechtenbeheer bij 3D-printbedrijven moeilijker is dan in algemene productiescenario's
De gegevensvormen van 3D-printbedrijven verschillen van die van bedrijven voor seriematige productie, waardoor het ontwerpen van rechten extra complex is. Ten eerste is de gegevensgranulariteit hoog: één onderdeel kan tegelijkertijd bestaan uit zes soorten assets, namelijk een origineel 3D-model, een hersteld meshbestand, een slice-bestand, een pakket met procesparameters, een inspectierapport en foto's van het fysieke product. Hun gevoeligheidsniveaus zijn niet hetzelfde. Klanten geven vaak alleen toestemming om een model voor productie te gebruiken, maar niet om het model opnieuw te wijzigen of aan derden door te sturen.
Ten tweede zijn er veel betrokken partijen. Naast interne functies voor ontwerp, procesengineering, printen, nabewerking, kwaliteitscontrole en levering zijn er ook toeleveranciers, externe onderhoudsmedewerkers van apparatuurfabrikanten, medewerkers van de klant die tekeningen beoordelen en zelfs externe testinstanties die tijdelijk aan het project deelnemen. Elke externe rol heeft een andere gegevensreikwijdte, geldigheidsduur en toegestane handelingen; dit met één intern accountsysteem willen afdekken leidt onvermijdelijk tot verlies van controle.
Ten derde zijn systemen versnipperd. Modelbestanden staan op bestandsservers of in objectopslag, sliceparameters bevinden zich in lokale software van apparatuurfabrikanten, inspectiegegevens staan op afzonderlijke werkstations van meetapparatuur of CT-apparatuur, en orderinformatie staat in bedrijfssystemen. Rechten worden in vier systemen elk deels beheerd; bij een functiewijziging moeten ze op vier plaatsen worden aangepast, en het overslaan van één plaats laat al een kwetsbaarheid achter.
II. Roldefinitie: vertaal eerst de organisatiestructuur naar gegevensobjecten
De meest voorkomende fout bij een rechtenstelsel is het organisatieschema rechtstreeks overnemen. Een functie is een organisatieconcept, een recht is een gegevensconcept; tussen beide is een vertaallaag nodig. Een werkbare aanpak is eerst een inventaris van gegevensobjecten op te stellen, vervolgens rollen te definiëren en ten slotte functies aan rollen te koppelen.
Het is raadzaam gegevensobjecten per project te organiseren in plaats van per afdeling. Een projectmap bevat vier subruimten: model, proces, inspectie en levering. Per subruimte worden vervolgens vier soorten handelingen onderscheiden: alleen lezen, bewerken, downloaden en extern verzenden. Zo gedefinieerde rechten bevatten van nature projectgrenzen en voorkomen dat medewerkers die aan project A werken toevallig bestanden van project B kunnen zien.
Het aantal rollen moet beperkt blijven. Een praktische richtlijn is zes tot acht interne rollen: projectverantwoordelijke, ontwerper, procesingenieur, productieoperator, kwaliteitscontroleur, leveringsverantwoordelijke, systeembeheerder en auditor. Te veel rollen zorgen ervoor dat niemand nog weet wat elke rol mag doen, waarna iedereen uiteindelijk beheerdersrechten gaat aanvragen. De auditor moet een onafhankelijke rol zijn en mag geen enkele bevoegdheid hebben om gegevens te wijzigen, omdat logboeken anders door die persoon zelf kunnen worden verwijderd.
III. Het principe van minimale rechten: standaard weigeren, tijdelijk autoriseren op aanvraag
Minimale rechten zijn geen slogan; zij moeten worden ondersteund door drie controleerbare regels. De eerste regel is standaard weigeren: een nieuw account ziet geen enkel project voordat er expliciet autorisatie is verleend. Veel systemen staan standaard op "leesbaar voor alle medewerkers"; in een 3D-printomgeving betekent dit dat klantmodellen feitelijk semi-openbaar worden gemaakt.
De tweede regel is dat autorisaties een tijdslimiet hebben. Rechten voor reguliere functies worden per kwartaal beoordeeld, projectgebonden rechten worden gekoppeld aan de einddatum van het project en tijdelijke externe toegang wordt nauwkeurig per dag toegekend. Na afloop trekt het systeem de rechten automatisch in en stelt het de projectverantwoordelijke daarvan op de hoogte ter bevestiging, in plaats van te wachten tot iemand eraan denkt de toegang af te sluiten. De derde regel is scheiding van handelingen: downloaden en extern verzenden zijn twee afzonderlijke rechten. Een bestand mogen downloaden voor productie betekent niet dat het ook extern mag worden verzonden; externe verzending moet afzonderlijk worden goedgekeurd en geregistreerd.
Voor zeer gevoelige gegevens is dubbele autorisatie aan te bevelen. Voor drie handelingen is controle door een tweede persoon vereist: export van een origineel klantmodel, volledige export van een pakket met procesparameters en bulkdownloads boven een drempelwaarde. De waarde van de tweepersoonsregel ligt niet alleen in het voorkomen van kwaadwillend intern gedrag, maar ook in het verkleinen van de kans op fouten door één persoon en in het achterlaten van een tweede getuige achteraf.
IV. Accountlevenscyclus: beheer in drie fasen bij indiensttreding, functiewijziging en uitdiensttreding
Personeelswijzigingen zijn een veelvoorkomende bron van onbeheersbare rechten. Bij indiensttreding moeten rechtenaanvragen worden vastgelegd in een formulier: de projectverantwoordelijke specificeert de benodigde gegevensruimten en handelingen, waarna de beheerder deze na goedkeuring configureert en het configuratieresultaat als bewijs in het formulier terugschrijft. Mondelinge aanvragen voor rechten zijn verboden.
De fase van functiewijziging is het belangrijkst en wordt het gemakkelijkst over het hoofd gezien. De juiste volgorde is eerst de rechten van de oude functie intrekken en daarna die van de nieuwe functie toekennen, in plaats van ze op te stapelen. In de praktijk is het veiliger om op de dag van de functiewijziging alle projectrechten van het account te bevriezen en de verantwoordelijke van de nieuwe functie opnieuw een autorisatieaanvraag te laten indienen; ruimtes waarvoor geen aanvraag is gedaan, zijn zonder uitzondering niet langer zichtbaar. Als de medewerker nog aan historische projecten moet deelnemen, moet dit afzonderlijk als projectlid worden aangevraagd, met een einddatum.
Bij uitdiensttreding moeten drie zaken op dezelfde dag worden afgerond: het account uitschakelen in plaats van verwijderen, zodat de koppeling met logs behouden blijft; het projectlidmaatschap in bulk verwijderen; en alle rechten voor externe verzending en gedeelde links ongeldig maken. Een account verwijderen verbreekt de koppeling met de uitvoerder in logboeken en maakt tracing achteraf onmogelijk; veel bedrijven zijn al in deze val gelopen.
V. Traceerbare handelingen: logs moeten vijf vragen kunnen beantwoorden
Registratie van handelingen is niet bedoeld om simpelweg logs op te slaan, maar om achteraf de feiten te kunnen reconstrueren. Een bruikbaar toegangslog moet ten minste kunnen beantwoorden: wie, op welk moment, op welk gegevensobject, welke handeling heeft uitgevoerd en wat het resultaat was. Naast gebruikersidentificatie, tijdstempel, objectidentificatie, type handeling en resultaatstatus moet het ook het bronapparaat en de netwerklocatie registreren, zodat toegang vanaf een werkplek in de werkplaats kan worden onderscheiden van afwijkende toegang op afstand.
De logs zelf moeten fraudebestendig zijn. Na het schrijven mogen zij niet worden gewijzigd of verwijderd; ook beheerdersaccounts mogen geen verwijderrechten hebben. De bewaartermijn mag niet korter zijn dan de termijn voor geschillen die in het klantcontract is afgesproken; doorgaans wordt bewaring van meer dan twaalf maanden aanbevolen. Ook toegang tot logbestanden moet worden gecontroleerd: wie de logs heeft geraadpleegd, moet zelf eveneens worden geregistreerd.
Logs zonder controle zijn gelijk aan geen logs. Het is raadzaam drie soorten automatische waarschuwingen in te stellen: grootschalige downloads buiten werktijd, een dagelijkse downloadomvang van één account die driemaal de historische basislijn overschrijdt, en toegang door een extern account tot een niet-geautoriseerde projectruimte. Een waarschuwing hoeft niet onmiddellijk als overtreding te worden aangemerkt, maar moet wel binnen een werkdag door iemand worden afgehandeld, met een vastgelegd afhandelingsverslag.
VI. Grenzen voor externe accounts en gedeelde links
Klanten die tekeningen beoordelen, externe verwerkers en onderhoudsmedewerkers van apparatuurfabrikanten moeten externe accounts gebruiken met een afzonderlijke naamruimte en mogen niet met het interne accountsysteem worden vermengd. Externe accounts mogen standaard alleen expliciet gedeelde objecten openen, zien de structuur van projectmappen niet en kunnen evenmin via links andere bestandspaden raden. Gedeelde links moeten niet-opnoembare willekeurige identificaties gebruiken en gekoppeld zijn aan een geldigheidsduur en een maximumaantal toegangen.
Onderhoud op afstand door apparatuurfabrikanten is het kanaal dat het gemakkelijkst wordt doorgelaten. Onderhoudsaccounts hebben doorgaans hoge rechten in het besturingssysteem van apparatuur; als zij gekoppeld zijn aan het bestandssysteem van het productienetwerk, ontstaat er feitelijk een externe omweg rond het rechtenstelsel. De juiste aanpak is onderhoudstoegang via een afzonderlijk netwerkkanaal te laten verlopen en ook bestandsexport tijdens onderhoud op te nemen in het goedkeurings- en registratieproces.
VII. Checklist voor implementatie
Bedrijven kunnen aan de hand van de volgende punten een zelfcontrole uitvoeren: ziet een nieuw account standaard geen enkel project; kan binnen vijf minuten een volledig overzicht worden gemaakt van alle huidige rechten van een medewerker; hebben alle rechten een geldigheidsduur; bevat het proces bij functiewijziging gedrag waarbij eerst rechten worden toegekend en pas daarna ingetrokken; zijn downloaden en extern verzenden twee afzonderlijke rechten; bevatten logs een veld voor het bronapparaat en kunnen zij niet worden verwijderd; zijn externe accounts gescheiden van interne accounts; zijn gedeelde links gekoppeld aan een geldigheidsduur en een maximumaantal keren gebruik; worden externe links op de dag van uitdiensttreding ongeldig; en is er in het afgelopen kwartaal werkelijk een rechtencontrole uitgevoerd. Als op drie of meer van deze tien vragen geen antwoord mogelijk is, moet het rechtenstelsel opnieuw worden opgebouwd.
Samenvatting
De grens van gegevensassets bij 3D-printbedrijven wordt uiteindelijk bepaald door het account- en rechtenstelsel, niet door de sterkte van encryptie of geheimhoudingsovereenkomsten. Vertaal functies naar rollen, koppel rollen aan gegevensobjecten met een tijdslimiet, stel de standaardstrategie in op weigeren en leg iedere toegang vast als controleerbare registratie. Als deze vier stappen goed worden uitgevoerd, kunnen de meeste gegevenslekken vóór het incident worden onderschept of achteraf duidelijk worden bewezen. Rechtenbeheer is geen eenmalige beleidspublicatie, maar een engineeringmechanisme dat elk kwartaal moet worden beoordeeld en voortdurend moet worden aangescherpt naarmate projecten veranderen.
Dien een model, tekening, afbeelding of schriftelijke notities in. Ingenieurs beoordelen materiaal, proces, afwerking en levering op basis van daadwerkelijk gebruik.