YPCad
Nederlands
Demonstratie aanvragen

Beveiliging

Deze pagina vertelt zowel wat we beschermen als wat we niet kunnen beschermen. Een beveiligingsverhaal waaraan het tweede deel ontbreekt, verleidt de lezer ertoe een lijst met een garantie te verwarren.

Uitgangspunt

Een pakket publiceren betekent code draaien op de computer van elke ingenieur die het installeert. Elke beveiligingskeuze in dit product is eerst tegen één vraag afgewogen: maakt deze verandering een publicatie zonder recht gemakkelijker?

  • Pakketten worden ondertekend (ECDSA P-256)

    Het handtekeningbestand reist binnen het pakket mee. Het ondertekent een manifest met de afdrukken van de bestanden, het pakketkenmerk en de versie — niet een kale afdruk van het archief.

    Werd alleen de afdruk ondertekend, dan kon een oud, correct ondertekend archief onder een nieuw versienummer worden geschoven: de handtekening zou de controle doorstaan, en de gebruiker zou als “update” een tool met een bekende kwetsbaarheid installeren.

  • De privésleutel staat NIET op de server

    De server controleert alleen. Het ondertekenen gebeurt op de computer van degene die publiceert, met een apart hulpmiddel.

    Stond de sleutel op de server, dan kon wie hem overneemt een pakket wijzigen en opnieuw ondertekenen — waarmee de handtekening zinloos zou worden.

  • De client controleert ook

    De extensie op de computer van de ingenieur controleert de handtekening zelfstandig, en de lijst met vertrouwde sleutels die ze gebruikt komt niet van de server.

    De handtekening bestaat juist omdat de server niet op zijn woord geloofd kan worden. De vertrouwenslijst van diezelfde server halen zou de uitgangsaanname stilzwijgend tenietdoen.

  • Een auditlogboek dat niet gewist wordt

    Elke publicatie, elke rechtenwijziging en elk kanaalbesluit worden voorgoed vastgelegd. Er bestaat met opzet geen enkel pad om te wijzigen of te verwijderen, en het opschonen na de bewaartermijn raakt het niet aan.

    “Hoe is deze tool hier terechtgekomen” wordt doorgaans maanden later gevraagd. Die dag is een spoor dat gewist had kunnen worden een spoor dat nooit heeft bestaan.

  • Vierogenprincipe, optioneel

    Een versie naar een breder kanaal uitrollen kan de goedkeuring van een tweede beheerder vereisen, en wie het verzoek deed, kan zijn eigen verzoek niet goedkeuren. Terugdraaien vraagt nooit om goedkeuring.

    Standaard staat het uit. In een team van drie verandert de horde binnen enkele weken in een bericht dat zonder lezen wordt goedgekeurd; een controle waarvan men gelooft dat ze beschermt terwijl ze dat niet doet, is erger dan helemaal geen controle.

  • Een archief uitpakken is op zichzelf een aanvalsoppervlak

    Toegevoegde archieven worden gecontroleerd op ontsnapping uit de map (zip-slip) en op uitpakbommen, en de omvang na het uitpakken is begrensd.

    Een archief uitpakken lijkt onschuldig. Een speciaal geprepareerd archief kan bestanden buiten de doelmap schrijven of de schijf van de server volzetten.

  • Aanmelden zonder wachtwoord

    Gebruikers melden zich aan met een eenmalige code die naar hun adres wordt gestuurd. De sessie loopt op een kortlevend token; het vernieuwingstoken is nooit zichtbaar voor de code in de browser.

    Is er geen wachtwoordkluis om te beheren, dan is er ook geen wachtwoorddatabase die kan uitlekken. En het hergebruik van een reeds ingetrokken vernieuwingstoken wordt als teken van diefstal behandeld: de sessie wordt gesloten.

  • U ziet wat u installeert

    De installatiemap bevat een machineleesbare onderdelenlijst (SBOM CycloneDX) en migratiescripts voor beide databases.

    Uw IT-team moet kunnen controleren wat er op de server terechtkomt voordat het er terechtkomt. Wordt er een kwetsbaarheid in een afhankelijkheid bekendgemaakt, dan wordt “hebben wij die?” een zoekopdracht door bestanden.

Wat we niet kunnen beschermen

Dit zijn geen tekortkomingen, maar grenzen. Ze volgen uit de structuur, en het tegendeel beweren zou onwaar zijn.

  • Twee beheerders die samen optreden. Het vierogenprincipe stopt er één, geen twee.
  • De systeembeheerder van de server. Voor wie toegang heeft tot de database en het bestandssysteem is geen enkele controle op applicatieniveau een hindernis.
  • Het werkstation waar de ondertekeningssleutel staat. De sleutel staat niet op de server, maar hij staat ergens; valt die machine, dan valt de handtekening mee.
  • Opzettelijk verborgen kwaadaardig gedrag. Onze inspectie van pakketten is heuristisch en we beweren niet dat ze code zal vangen die zich probeert te verbergen.
  • Het weglekken van gegevens. Een geïnstalleerde tool werkt met de rechten van de ingenieur zelf en kan alles lezen wat die rechten bereiken. Dat wordt begrensd door de controles van het besturingssysteem en het netwerk, niet door dit product.
  • De beveiliging van uw back-ups. De kopie van de database ligt in uw handen, en alles daarin is precies zo veel waard als het levende systeem.

Een kwetsbaarheid melden

Hebt u er een gevonden, schrijf ons dan. We nemen meldingen serieus, sluiten de melder niet buiten het proces, en laten u weten wanneer de oplossing uitkomt.

security@ypcad.com