Eerst de vangrails, dan autonomie.
Opafra voert opdrachten uit op uw productieservers. Deze pagina legt uit hoe het ze bereikt, wat het bewaart en wie erop kan handelen.
Laatst bijgewerkt: 24 september 2026
Beveiligingsvragen en vragenlijsten gaan naar [email protected]. Wilt u een kwetsbaarheid melden, lees dan eerst hoe u dat doet.
Hoe Opafra uw servers bereikt
Opafra werkt zonder agent. Het opent SSH-verbindingen vanaf zijn eigen servers naar uw hosts, als de SSH-gebruiker die u per host instelt, om plannen uit te voeren, proefruns te draaien, verbindingen te testen en de browserterminal te openen. Het verbindt ook op een timer, om te controleren of elke host antwoordt en om basisgegevens van de host te lezen. Er wordt niets op de host geïnstalleerd, en na een run blijft er niets van Opafra draaien.
Elke organisatie heeft een eigen SSH-certificaatautoriteit. Op een host die voor certificaten is ingericht, verbindt elke run en elke sessie van de browserterminal met een nieuwe sleutel en een certificaat dat vijf minuten geldig is. Het certificaat bevat één principal voor uw organisatie, nooit een inloggebruiker, en de host koppelt die principal aan de gebruikers die u kiest, zodat een certificaat dat voor een andere organisatie is ondertekend, de host niet opent. De key-id noemt de organisatie en de server, zodat het eigen authlog van de host zegt wie er verbond. Een host kan ook een sleutel gebruiken die u aan Opafra geeft.
Opafra legt de SSH-sleutel van elke host vast bij de eerste verbinding en controleert die bij elke volgende, ook bij elke bastion onderweg. Een host die een andere sleutel toont, wordt geweigerd, de weigering wordt vastgelegd, en alleen een Admin of de Owner kan de nieuwe sleutel accepteren.
Een plan kan op een host alles doen wat die SSH-gebruiker kan. Opafra filtert geen opdrachten. Verbind als een gebruiker die op het werk is toegespitst en niet als root, dan blijven de eigen rechten van de host de buitengrens.
Wat Opafra bewaart, en wat niet
- Bewaard: uw inventaris (hostnamen, adressen, poorten en SSH-gebruikers), plannen en elke revisie ervan, scripts en configuratiesjablonen, de vastleggingen van runs en de uitvoer van runs met gemaskeerde geheimen, hostgegevens en het auditlog.
- Versleuteld bewaard: de inloggegevens die u aan Opafra zelf geeft, onder de eigen sleutel van uw organisatie (volgende sectie).
- Niet bewaard: de waarden in uw externe secretmanager. Een plan bevat een verwijzing zoals secret://prod/db-password. Opafra haalt de waarde op wanneer de stap die haar nodig heeft draait, en legt elke ophaalactie vast met de verwijzing. De vastlegging van de run bewaart de verwijzing, en in het runlog is de waarde gemaskeerd.
Inloggegevens en versleuteling
Inloggegevens die Opafra bewaart, worden per organisatie versleuteld. Een rootsleutel van 256 bits, die de service uit zijn omgeving krijgt en die nooit in de database wordt geschreven, omhult één willekeurige gegevenssleutel van 256 bits per organisatie. Elke waarde wordt met AES-256-GCM versleuteld onder de gegevenssleutel van haar organisatie, en de versleutelde tekst is aan die organisatie gebonden, zodat een waarde die naar de gegevens van een andere organisatie is gekopieerd, niet opent. Zonder de rootsleutel weigert de opslag iets te verzegelen of te openen.
Op deze manier versleuteld: geheimen in de ingebouwde opslag, geheime omgevingsvariabelen, serverwachtwoorden en privésleutels, beheerde SSH-sleutels, inloggegevens voor git en voor de GitHub App, inloggegevens van discoverybronnen, ondertekeningsgeheimen van webhooks, de privésleutel van de SSH-certificaatautoriteit van uw organisatie, en de instellingen waarmee Opafra uw secretmanager bereikt.
- Secretmanagers zijn integraties. Koppel HashiCorp Vault, Infisical, AWS Secrets Manager of GCP Secret Manager, of gebruik de ingebouwde versleutelde opslag. Bij een externe manager blijft de waarde daar tot een run haar nodig heeft.
- De uitvoer van een run wordt gemaskeerd voordat hij wordt getoond of bewaard. Twee lagen: de exacte waarden van de geheimen die een run ophaalde of als geheime invoer kreeg, en bekende vormen zoals blokken met privésleutels, bearer-tokens, wachtwoordtoewijzingen en gangbare provider-tokens. Een geheim korter dan vier tekens wordt geweigerd, omdat het niet betrouwbaar te maskeren is.
- Inloggen. Log in met Google, Microsoft, GitHub of GitLab, of met een e-mailadres en een wachtwoord, dat als bcrypt-hash wordt bewaard.
- API-tokens worden één keer getoond en als SHA-256-hash bewaard. Ze kunnen verlopen, en elk token werkt in één organisatie, met het lidmaatschap gecontroleerd bij elk verzoek.
Is Opafra multi-tenant?
Ja. Organisaties delen de service en de database. Elke query naar de gegevens van een organisatie is afgebakend tot de organisatie van de persoon of het token dat vraagt, en een verzoek om de gegevens van een andere organisatie wordt beantwoord alsof ze niet bestaan. Inloggegevens worden versleuteld onder de eigen gegevenssleutel van elke organisatie, en elke organisatie heeft haar eigen SSH-certificaatautoriteit, zoals hierboven. Een organisatie verwijderen verwijdert in één transactie alles wat ze bezit, haar geheimen en haar gegevenssleutel, en behoudt het auditlog.
Wie bij productie kan
Een omgeving kan worden beschermd. Dan handelt alleen de Owner er op grond van de rol alleen op. Alle anderen, ook Admins, hebben een toekenning voor die omgeving nodig, en een toekenning kan een einddatum hebben, zodat twee uur toegang tot productie na twee uur eindigt zonder dat iemand eraan hoeft te denken het ongedaan te maken.
prod
Protected: org role alone grants nothing here. Access comes from an explicit grant.
| Member | View | Run | Manage | Via |
|---|---|---|---|---|
| Ada LovelaceOwner | View allowed | Run allowed | Manage allowed | Org role (owner) |
| Bo ChenAdmin | View not allowed | Run not allowed | Manage not allowed | No access |
| Alex MoreauOperator | View allowed, expires in 2h | Run allowed, expires in 2h | Manage not allowed | Grant, expires in 2h |
| Dana OkaforOperator | View allowed | Run allowed | Manage not allowed | Grant, permanent |
| Eli NovakViewer | View not allowed | Run not allowed | Manage not allowed | No access |
- Approved by
- Dana Okafor, 14:02
- Window
- 14:05 to 16:05
- Connections
- 3, each on a 5 min certificate
- Vier rollen: Owner, Admin, Operator en Viewer.
- Goedkeuringspoorten. Een omgeving kan goedkeuring eisen. Een run die op haar hosts is gericht, wacht dan op een persoon. Een Operator, Admin of Owner kan hem afwijzen. Om een run naar een beschermde omgeving goed te keuren, moet de goedkeurder ook toegang tot die omgeving hebben: een geldige toekenning, of de Owner zijn. De goedkeuring legt vast wie besliste, wanneer, en welke revisie van het plan. Verandert het plan voordat de run start, dan vervalt de goedkeuring en is een nieuwe nodig.
- Toegangsverzoeken. Een persoon vraagt toegang tot een omgeving aan met een reden, en het verzoek kan niet worden goedgekeurd door wie het deed. Alleen de Owner kan zichzelf toegang geven. Een Admin die rechtstreeks toegang verleent, wordt daarbij vastgelegd.
- Zelf goedgekeurde runs zijn toegestaan, en gemarkeerd. Een klein team heeft vaak niemand anders om het te vragen, dus Opafra weigert het niet. De vastlegging en de lijst met goedkeuringen markeren elke run die is goedgekeurd door de persoon die hem startte, zodat een beoordelaar ze allemaal kan vinden.
- Proefruns. Een proefrun toont per host de opgeloste opdracht, het script of de argumenten die elke stap zou uitvoeren, met gemaskeerde geheimen. Voor configuratiesjablonen, pakketten, services, gebruikers, firewallregels, cron-items en nginx-reloads leest hij ook de host en meldt hij of er iets zou veranderen.
De vastlegging
Opafra schrijft de vastlegging terwijl het werk gebeurt. Het auditlog is append-only, en de database dwingt dat af: ze weigert een regel te wijzigen of te verwijderen. Regels blijven bestaan na de persoon die ze maakte, van wie het e-mailadres op elke regel blijft staan, en na de organisatie die ze bezat.
- Elke run: wie hem startte, wie hem goedkeurde en welke revisie van het plan, en wat er op elke host gebeurde. Voor een plan dat de composer opstelde, welk model het opstelde en wie erom vroeg. Een proefrun wordt als eigen run vastgelegd.
- Elke aanmelding, geslaagd of mislukt, met het IP-adres en de browser waarvan ze kwam.
- Toegang en inloggegevens: toekenningen, toegangsverzoeken, rolwijzigingen, verwijderde leden, wijzigingen aan servers en SSH-sleutels, vastgezette hostsleutels (geweigerd en geaccepteerd), koppelingen met secretmanagers, API-tokens, elke wijziging aan een geheim dat Opafra bewaart (op naam, zonder de waarde), elk geheim dat een run ophaalde en elke browserterminal die naar een host is geopend.
- Elke export van het log zelf.
Admins kunnen het doorzoeken en filteren, exporteren als CSV of NDJSON, en een SIEM het via de API met een token laten ophalen.
De AI-composer
De composer stelt plannen op en kan niets uitvoeren. Zijn tools bewerken het concept en niets anders. Een concept blijft een concept tot een persoon het bewaart, en gaat dan door dezelfde proefrun, toegangscontroles en goedkeuring als elk ander plan. Elk plan legt vast of de composer het opstelde, met welk model en wie erom vroeg.
| Vraag | Antwoord |
|---|---|
| Kan de AI zelf wijzigingen aanbrengen? | Nee. Hij stelt plannen op; mensen bekijken, keuren goed en voeren uit. |
| Wat ontvangt het model? | Uw verzoek, het plan dat wordt bewerkt, hostnamen en groepsnamen, en de namen en beschrijvingen van uw scripts, configuratiesjablonen en modules. |
| Ontvangt het inloggegevens of geheimen? | Nee. Inloggegevens, geheime waarden, scriptinhoud en hostuitvoer worden er niet naartoe gestuurd. Een planstap die een geheim gebruikt, bevat de verwijzing en niet de waarde. |
Hosting
Gehost in de EU. Werkt met uw servers, waar ze ook staan. Opafra draait op Hetzner in Duitsland en Finland, en bereikt uw hosts via SSH waar ze ook staan, bij elke cloud of in elk datacenter.
Op Enterprise draait door de klant gehoste uitvoering de uitvoeringslaag binnen uw eigen netwerk.
Back-ups en incidenten
Van de database wordt elke dag een back-up gemaakt. Raakt een incident uw organisatie, dan waarschuwen wij uw organisatie per e-mail.
Een kwetsbaarheid melden
Denkt u een beveiligingsprobleem in Opafra te hebben gevonden, mail dan [email protected]. Vermeld wat u vond, waar, hoe het te reproduceren is en wat een aanvaller ermee kan. Eén e-mail per probleem.
Wat er daarna gebeurt.
- We bevestigen uw melding binnen 2 werkdagen.
- We sturen binnen 7 werkdagen een eerste beoordeling: of de melding geldig is, hoe ernstig ze is en wat er daarna gebeurt.
- We houden u op de hoogte terwijl de oplossing vordert, en laten het u weten wanneer ze live gaat.
Binnen bereik: de Opafra-applicatie en haar API, en opafra.com. Buiten bereik: servers van klanten van Opafra, die u nooit mag testen; denial of service en belastingtests; social engineering; scanneruitvoer zonder aangetoonde impact; ontbrekende headers zonder exploit.
Regels. Test alleen binnen een organisatie die u zelf hebt aangemaakt. Komt u bij de gegevens van een andere organisatie, stop dan: bewaar, herhaal of deel ze niet, en meld het ene verzoek dat ze liet zien. Voer opdrachten alleen uit op hosts die u bezit, met testinloggegevens.
Veilige haven. Als u te goeder trouw uw best doet dit beleid te volgen tijdens uw beveiligingsonderzoek, beschouwen wij uw onderzoek als toegestaan, werken wij met u samen om het probleem snel te begrijpen en op te lossen, en zal Opafra geen juridische stappen met betrekking tot uw onderzoek aanbevelen of nemen. Start een derde partij juridische stappen tegen u voor activiteiten die in overeenstemming met dit beleid zijn uitgevoerd, dan maken wij bekend dat dit onderzoek was toegestaan.
Openbaarmaking. Houd het probleem alstublieft privé tot er een oplossing is uitgerold en we een datum met u hebben afgesproken.
Beloningen. Opafra heeft geen betaald bugbountyprogramma.
Hetzelfde contact, in machineleesbare vorm, staat op /.well-known/security.txt.
Stuur ons de vragenlijst.
Beveiligingsvragenlijsten worden per e-mail beantwoord. Schrijf naar [email protected].