Beveiliging en governance

Elke applicatieomgeving draait op een eigen instance. Geen gedeelde runtime, geen proces dat meerdere klanten deelt. Ontwikkeling, staging en productie zijn aparte instances met aparte data.

Secrets van klanten zijn gescheiden per organisatie en applicatie. Communicatie tussen een node en het platform loopt via een wederzijds geauthenticeerde TLS-tunnel, met de identiteit van de node vastgelegd in het clientcertificaat. Een verbinding met een identiteit buiten die structuur wordt gesloten.

Alles draait in eu-central-1 (Frankfurt). Dat is vandaag de enige regio waarin we werken, dus je data blijft in de EU. Er is geen instelling die het verplaatst en geen regio die je verkeerd kunt kiezen. Voegen we een regio toe, dan melden we dat hier voordat hij beschikbaar is. Moet je data buiten de EU staan, dan kunnen we dat vandaag niet bieden.

Die garantie geldt voor het datavolume van je applicatie. Platformlogging, de output van builds bij een deploy en de toegang die we gebruiken om je te helpen draaien op dezelfde infrastructuur, in dezelfde regio: ook daarvan verlaat niets de EU.

Omdat de verwerking in de EU plaatsvindt, valt die onder de AVG: jij bent verwerkingsverantwoordelijke voor wat je applicatie verwerkt, en wij zijn verwerker, alleen op jouw instructies. Lees onze privacyverklaring voor die verhouding in detail.

Inloggen gaat met een eenmalige code per e-mail, met optionele TOTP als tweede factor. Sessies worden op de server bewaard: de browser krijgt nooit een token.

Autorisatie gaat per rol binnen een organisatie: beheerder, developer, kijker. Elk verzoek draagt een gecontroleerde identiteit, en bij elke aanroep wordt toegang tot een resource gecontroleerd tegen de organisatie die er eigenaar van is. Een onbekende rol wordt geweigerd in plaats van een standaardrol te krijgen.

Wat je coding agent namens jou mag doen, wordt apart geregeld. Acties die data kunnen vernietigen, een applicatie uit de lucht kunnen halen of kunnen veranderen wie bij de code kan, vragen standaard een token met de beheerdersrol, tenzij je organisatie een andere regel instelt. Kan de controle niet worden uitgevoerd, dan wordt de actie geweigerd. Een agent kan die regel lezen maar nooit wijzigen. Alleen een mens kan hem vanuit het dashboard ruimer of strenger maken.

Secrets zijn alleen-schrijven via de API. Eenmaal opgeslagen geeft geen enkele interface (web, agent of API) de waarde terug. In productie staan ze als versleutelde parameters in AWS Systems Manager Parameter Store, onder een pad per klant, en ze worden bij de deploy ingevoegd.

Een applicatie is pas nuttig als hij bij de systemen kan waar het werk echt in zit: een mailbox, SharePoint, Teams, Stripe, een SAP OData-service. Meestal plakt degene die het toevallig bij de hand had een wachtwoord in een repository. Dat werkt tot die persoon vertrekt, de sleutel verloopt of de klant vraagt wie hem kan zien en niemand het weet.

Dit platform heeft daar één regeling voor. Een beheerder registreert de inloggegevens van de organisatie één keer, bij connectors die wij schrijven en onderhouden. Vanaf dan wordt elk gebruik ervan aangevraagd, beoordeeld en vastgelegd, en een toestemming kan op elk moment worden ingetrokken zonder dat er iets anders stukgaat.

Vertrouwen in code die een agent schreef, hoort niet op ons woord te rusten. Syntica draait gewone code, dus de analysetools die je organisatie al vertrouwt, kunnen hem beoordelen. Koppel de SonarQube die je zelf draait, of het gratis plan van SonarQube Cloud, en na elke deploy kan er een scan volgen op je eigen server, beoordeeld door je eigen quality gate. Jij brengt het abonnement mee, en het oordeel komt van jouw infrastructuur, niet van de onze.

Het platform kan je server alleen lezen, het token dat je opgeeft wordt versleuteld en kan nooit worden uitgelezen, en een scan bouwt of draait de repository nooit. Aan onze kant komt geen AI aan je code of bevindingen. Hoe het precies werkt, lees je in de handleiding over codekwaliteit.

We lezen je broncode niet, en we trainen er nooit modellen op.

Wat we verzamelen is platformtelemetrie, gebruikspatronen en de vorm van een applicatie: welke base images, hoeveel services, of er een database is. Nooit de inhoud. De output van builds en deploys wordt bewaard voor support, zeven dagen lang. Inloggegevens worden uit git-foutmeldingen verwijderd.

De repository van een klant lezen we alleen met uitdrukkelijke, specifieke, schriftelijke toestemming, voor een benoemd doel. Dat valt niet onder het accepteren van onze voorwaarden.

Je code staat in een gewone git-repository. Je kunt hem op elk moment clonen, spiegelen of ergens anders heen brengen, zonder het ons te vragen.

Publiek verkeer komt binnen bij een ingress-laag die TLS afhandelt, met beheerde certificaten. Per applicatie zijn er limieten op het aantal verzoeken, limieten per IP, IP-allowlists, limieten op de grootte van verzoeken en een onderhoudsmodus. Uitgaand verkeer van applicaties wordt gemeten.

Van datavolumes van applicaties worden snapshots gemaakt volgens een schema dat hoort bij het niveau van de applicatie, met een bewaartermijn per niveau. Terugzetten overschrijft bewust de huidige data en is beveiligd: eerst wordt een veiligheidssnapshot gemaakt en gecontroleerd voordat er iets wordt vervangen, de applicatie moet eerst netjes gestopt zijn, en een mislukte wissel van het volume wordt teruggedraaid naar het origineel.

Er is geen exitproces om over te onderhandelen. Je applicatie is gewone code met een gewoon compose-bestand: clone hem en neem hem overal mee naartoe, zonder het ons te vragen. Een kant-en-klare overdracht, met een overzicht van secrets en een runbook, is in ontwikkeling.

• Single sign-on is nog niet beschikbaar. Het is in ontwikkeling. Vandaag log je in met een eenmalige code per e-mail met optionele TOTP.

• We hebben geen SOC 2, ISO 27001 of vergelijkbare certificering. Dat zeggen we gewoon, in plaats van iets anders te suggereren.

• We hebben nog geen verwerkersovereenkomst die klaar is om te tekenen. Die is in ontwikkeling. Heeft je organisatie er een nodig, mail dan info@syntica.io en we werken het samen met je uit.

• We bieden geen SLA voor beschikbaarheid. Vandaag is het platform gebouwd om applicaties te bouwen, te valideren en te bewijzen. Applicaties op grotere schaal laten draaien staat op onze roadmap.

• We scannen of reviewen je code niet zelf. Je kunt je eigen SonarQube koppelen en productie laten afhangen van het oordeel daarvan, maar de analyse draait op jouw abonnement, en de verantwoordelijkheid voor wat je agent schrijft blijft bij jou. Wij zijn verantwoordelijk voor het platform waarop het draait.

• Een deploy kan naar een eerdere commit worden teruggezet, dus terugdraaien is opnieuw deployen van de laatste goede build en geen restore. Wat we niet hebben is deployen zonder downtime: elke deploy, ook die, onderbreekt de draaiende applicatie even.