Stop met serverwerk per klant met de hand. Draai het als plannen, met de vastlegging die elke klant krijgt.
Voor hosting- en managed-hostingteams. Het werk voor elke klant hangt niet langer af van de shell van één persoon: richt een nieuwe klant in vanuit een template, en laat iedereen in het team het routinewerk draaien, met een proefrun per host en een goedkeuring waar u die wilt. De vastlegging van elke run geeft u aan uw klanten, en ze ondersteunt uw eigen ISO 27001. Ansible en git draaien uw wijzigingen al. Opafra voegt de goedkeuring en de vastlegging toe waar uw klanten en de EU-regelgeving om vragen. De Cyberbeveiligingswet vraagt dat maatregelen aantoonbaar worden toegepast, en uw klanten vragen u dat te laten zien.
Toon aan wie bij welke klantserver kwam, met wiens akkoord en hoe lang.
Uw engineers en leveranciers vragen toegang aan met een reden. Een met naam genoemde goedkeurder zegt ja, de toekenning loopt voor het venster dat ze kreeg en eindigt zonder dat iemand eraan hoeft te denken, en elke verbinding eronder staat in de vastlegging.
Access record /grant #a91c on prod
- Requested
- Alex Moreau @alex at 13:58:12, for patch nginx across prod
- Approved
- Dana Okafor @dana at 14:02:40
- Window
- 14:05:00 to 16:05:00, 2h
- Ended
- Expired on its own
| Time | Server | Through | Certificate |
|---|---|---|---|
| 14:32:11 | web-01 | run #4f2a | 5 min |
| 14:32:11 | web-02 | run #4f2a | 5 min |
| 14:32:12 | web-03 | run #4f2a | 5 min |
De eis waarop dit antwoordtCyberbeveiligingsbesluit, artikel 10 en 15
Artikel 10 vraagt een schriftelijk leveranciersbeleid en een controle van uw rechtstreekse leveranciers. Artikel 15 vraagt een toegangsbeleid waarin autorisaties worden verleend, bewaakt, gebruikt, gewijzigd en ingetrokken. De toelichting herhaalt het steeds: schriftelijk vastgelegd en aantoonbaar toegepast.
Deze artikelen rusten op uw klant als entiteit onder de wet. Voor die klant bent u de leverancier, en dit is de vastlegging die u kunt tonen. Valt uw organisatie zelf onder Uitvoeringsverordening (EU) 2024/2690, dan vraagt punt 6.7.2(h) dat verbindingen van dienstverleners pas komen na een autorisatieverzoek en voor een bepaalde periode.
De servers, plannen, runs en vastleggingen van elke klant, per klant bekeken.
Werk voor alle klanten vanuit één plek. Een nieuwe klant begint vanuit een template, zodat u niet met de hand opnieuw opbouwt wat u voor de vorige klant bouwde.
84 servers across 4 clients, each with its own keys, members and record.
- Kessel Bank24 serversManaged Linux, regulatedPatch nginx across prod, Awaiting approval14:301 waiting on the client
- Halden Logistics41 serversManaged LinuxWeekly restore test, Completed03:04Nothing waiting
- Brightwater Clinics12 serversManaged Linux, regulatedRotate TLS certificates, Scheduled22:00Nothing waiting
- Orchard Media7 serversManaged web hostingPatch PHP across web, Completed11:12Nothing waiting
Verkoopt u een beheerd platform op de servers van uw klant?
Een platform draaien voor elke klant op zijn eigen servers is hetzelfde werk per klant. Het draait dus als dezelfde plannen, met dezelfde goedkeuring en dezelfde vastlegging.
Vijf vragen die elke klant uiteindelijk stelt. Elke vraag heeft een vastlegging.
Ze komen binnen als vragenlijst, contractclausule of steekproef van een auditor. De bewijspagina toont elke vastlegging, en het antwoordpakket toont de antwoorden op de vragenlijst.
- Wie had er toegang tot onze servers?
- Elke toekenning staat erin met wie vroeg, waarom, wie goedkeurde, het venster en elke verbinding die eronder is gemaakt.
- Met wiens goedkeuring, en hoe lang?
- Toegang begint pas na goedkeuring door een met naam genoemd persoon, en eindigt vanzelf op het ingestelde tijdstip.
- Wordt die toegang beoordeeld?
- De toegangsreview toont iedereen met toegang tot een omgeving, wat de beoordelaar besloot en wanneer het is ondertekend.
- Kunt u herstellen wat u host?
- Een hersteltest die volgens schema draait, legt bij elke run het resultaat vast en de tijd die het kostte.
- Wat is er gewijzigd op onze servers?
- Elke wijziging wordt vastgelegd met de keten van verzoek tot uitkomst, en de goedkeuring geldt voor de exacte revisie die draaide.
Uw klanten keuren de wijzigingen op hun servers goed.
Een wijziging aan de servers van een klant kan wachten op de eigen goedkeurder van die klant. De goedkeuring wordt vastgelegd met de naam van de goedkeurder en de revisie waarvoor ze geldt, zodat “de klant ging akkoord” een vastlegging is en geen e-mail die u moet zoeken. Kijkers en goedkeurders aan klantzijde zijn in elk plan inbegrepen, dus uw klanten betalen niet om goed te keuren (zie prijzen).
Ansible en git draaien uw wijzigingen al. Opafra voegt de goedkeuring en de vastlegging toe.
Houd de repository en de playbooks die u vertrouwt. Opafra synchroniseert plannen uit git, draait Ansible-playbooks als stap in een plan, toont de wijziging vooraf op elke host, houdt haar vast voor de goedkeuring van één exacte revisie en schrijft de vastlegging.
Wat Opafra niet vastlegt.
Opafra legt vast wat er via Opafra loopt. Werk dat op een klantserver langs een andere weg gebeurt, staat niet in deze vastleggingen, en accounts die op de servers zelf bestaan, beoordeelt u waar ze staan.
Een browserterminal die via Opafra wordt geopend, wordt gelogd als geopend, met wie hem opende en wanneer, maar de sessie wordt niet opgenomen. Opafra verbindt via SSH en is daarom bedoeld voor Linux-servers.
Laat uw klanten de vastlegging zien.
Vertel hoeveel servers u voor klanten beheert. U krijgt een demo en uw prijs schriftelijk binnen één werkdag, zonder gesprek.