Het aanmeldbeleid instellen

Op Instellingen → Platformbeveiliging staat wat het paneel van een inlog verwacht: welke tweede factor, hoe lang een wachtwoord moet zijn, en wanneer het paneel iemand na te veel mislukte pogingen even buiten laat staan. Deze pagina loopt die vier blokken langs, en zegt bij elk wat er níet kan en waarom.

Alles op deze pagina is beheerderswerk. Een reseller ziet het tabblad niet — de API weigert het, en een tabblad dat 403 antwoordt is erger dan geen tabblad.

Authenticatiebeleid: drie standen per niveau

De tabel bovenaan heeft één regel per factor × niveau. De factoren zijn een authenticator-app en een passkey; de niveaus zijn Global admin, Server-admin, Reseller en Klant. Elke regel staat in één van drie standen:

De overgangstermijn

Zet je een niveau op Afgedwongen, dan vraagt het paneel om een overgangstermijn in dagen. Dat werkt zoals het bij Google Workspace werkt:

• het paneel onthoudt de dag waarop je het besloot;
• iedereen die op dat moment al een inlog had, krijgt vanaf díe dag zoveel dagen als je invult. In die periode zien ze een melding met de datum erbij;
• daarna is het geen melding meer maar een muur: aanmelden komt uit op het inrichtscherm.

Een inlog die ná je besluit is aangemaakt krijgt géén overgangstermijn. Die heeft de wereld zonder de regel nooit gekend, en twee weken uitstel geven zou betekenen dat de regel pas ingaat twee weken nadat de laatste persoon die eromheen wil zich heeft aangemeld.

De kolom Gevolg nu rechts vertaalt de regel naar wat er vandaag gebeurt: wordt niet gevraagd, wordt aangeraden, verplicht vanaf 19-08-2026, of aanmelden vraagt eerst om inrichten.

Wat je niet kunt instellen, en waarom

Bij Global admin en Server-admin staat geen keuzelijst voor de authenticator-app: daar staat het woord Afgedwongen en een informatie-icoon. Die twee niveaus kunnen andermans servers wijzigen, dus voor hen ligt een tweede factor vast — en er is voor hen ook geen overgangstermijn, want een week waarin de sterkste inlog van het platform een wachtwoord is, is een week te veel.

Dit is geen schermregel. Het paneel dwingt hem af bij het lezen van de instelling, dus ook een regel die je met de hand in de database zou zetten komt er als Afgedwongen weer uit:

ssh root@panel1.corecp.dev
sudo -u postgres psql -d corecp_panel -c \
  "UPDATE setting SET value = '{\"totp\":{\"admin\":{\"stance\":\"off\"}}}'::jsonb
   WHERE key = 'security.auth_policy'"
curl -s -b jar http://127.0.0.1:8080/api/v1/security/policy | jq '.factors[0]'
# { "factor": "totp", "level": "admin", "stance": "enforced", "floor": "enforced", … }

De passkey-terugval

Onder de tabel staat één schakelaar: Code uit een app blijft geldig naast een passkey. Standaard uit. Zolang hij uit staat, geldt de regel van §B6: wie op een adres een passkey heeft geregistreerd, moet die daar ook gebruiken — een code uit een app wordt geweigerd.

Zet je hem aan, dan is dat een echte verzwakking. Een passkey die met een code te omzeilen is, beschermt niet meer tegen phishing, want dan hoeft een nepsite alleen nog om de code te vragen. corecp-panel doctor meldt het zolang hij aan staat.

Wachtwoordbeleid

Alleen lengte. Geen verplichte vernieuwing, geen eisen aan hoofdletters of leestekens: NIST SP 800-63B rev.4 (2025) raadt beide af, omdat ze mensen naar Zomer2026! duwen in plaats van naar iets langs.

• Minimum per niveau. Standaard 15 tekens, en 20 voor Global admin en Server-admin. Onder de 15 kun je niet: dat is de ondergrens die de norm noemt, en het paneel weigert hem.
• Maximum. Minstens 64, zodat een wachtwoordzin past. Hoger mag; lager niet.
• Alleen bij het instellen. Verhoog je het minimum, dan blijft ieders bestaande wachtwoord geldig. Het nieuwe getal geldt pas bij de volgende wijziging of bij een nieuw account. Anders zou het verschuiven van een schuifje een storing zijn met een beveiligingsverklaring eraan geniet.

De lekcontrole

De schakelaar Bekend gelekte wachtwoorden weigeren vraagt het bij Have I Been Pwned. Wat er van jouw server af gaat, zijn vijf tekens:

1. het paneel berekent de SHA-1 van het wachtwoord;
2. het stuurt de eerste vijf tekens van die hash — bij password123 is dat CBFDA — naar de range-API;
3. het krijgt alle hashes terug die met die vijf beginnen (zo'n achthonderd) en vergelijkt lokaal.

De dienst leert dus dat iemand op dit paneel een wachtwoord heeft gecontroleerd waarvan de hash met vijf bepaalde tekens begint. Dat is ongeveer één op de miljoen wachtwoorden, en het is geen feit over een persoon. Je kunt het in het logboek terugzien:

ssh root@panel1.corecp.dev 'journalctl -u corecp-panel -n 200 | grep breached-password'
# aug 16 11:04:12 panel1 corecp-panel[8812]: breached-password check prefix=CBFDA

Meer dan prefix= staat er niet, en dat is met opzet: die regel is het bewijs dat er niets anders weggaat.

Is de dienst onbereikbaar, dan gaat het wachtwoord door. Met een waarschuwing in het log, maar het gaat door. Dat is een besluit en geen vergetelheid: een derde partij die plat ligt mag niemand tegenhouden die zijn wachtwoord wil veranderen — juist op het moment dat je dat het hardst nodig hebt.

De verbinding loopt over dezelfde uitgaande poort als de rest van het paneel: alleen https, geen omleidingen, en een controle op het echte IP-adres vlak voor het verbinden. Naar een adres in je eigen netwerk verbindt het paneel niet.

Vergrendeling na mislukte pogingen

Drie getallen, samen op te slaan:

• Pogingen — hoeveel mislukte aanmeldingen een inlog op slot zetten (3-50);
• Venster — hoe lang een mislukte poging meetelt (1-1440 minuten);
• Duur — hoe lang het slot erop blijft (1-240 minuten).

Het venster is nieuw in 0.17.16 en lost een echt vervelend geval op: zonder venster telde de teller alleen terug bij een gelukte aanmelding, dus vijf typo's verspreid over een jaar zetten een account net zo hard op slot als vijf gokpogingen in tien seconden. Nu vervalt een mislukte poging die ouder is dan het venster.

Er is bewust geen permanente vergrendeling. Die kan iedereen uitlokken die een e-mailadres kent, en dan is de beveiligingsmaatregel zelf de storing.

Staat er een blauw kadertje "Deze waarden komen nu nog uit panel.yaml", dan heeft nog niemand ze hier opgeslagen en gebruikt het paneel de getallen uit het configuratiebestand. Eén keer opslaan en het paneel neemt ze over.

Vergrendelde logins

Daaronder staat wie het paneel op dit moment weigert, met het aantal mislukte pogingen, wanneer de laatste was, en tot wanneer het slot erop zit. Ontgrendelen zet de teller op nul en haalt het slot eraf. Er zit een herbevestiging voor — het is een handeling aan andermans account — en de eigenaar van het adres krijgt er een e-mail over, ook als die alle meldingen heeft uitgezet.

Alleen levende sloten staan in de lijst. Een slot dat al verlopen is, staat er niet: een ontgrendelknop ernaast zou een knop zijn die niets doet.

Op de opdrachtregel:

ssh root@panel1.corecp.dev
corecp-panel audit list --action security.unlock --limit 10

Ingesteld in panel.yaml

Onderaan staat een blok met beveiligingswaarden die het paneel wél gebruikt maar niet zelf kan wijzigen: hoe lang een sessie leeft, het harde plafond erop, de snelheidslimieten richting de servers, de mass-op-drempel en de proxy's waarvan het paneel X-Forwarded-For gelooft.

Ze staan er met opzet. Een instellingenscherm dat zes van de negen knoppen laat zien, leert een beheerder dat die andere drie niet bestaan. Ze staan er read-only bij, met de zin dat ze in /etc/corecp-panel/panel.yaml staan en pas na een herstart gelden — en er staat geen knop die doet alsof:

ssh root@panel1.corecp.dev
sed -n '/^security:/,/^[a-z]/p' /etc/corecp-panel/panel.yaml
systemctl restart corecp-panel

Sinds 0.18.0 staat de uitleg naast elke waarde in jouw taal. Die zinnen worden door de paneel-server geschreven, en die weet niet welke taal jij hebt staan — hij stuurt ze daarom als sleutel mét de Engelse zin erbij, zodat het paneel ze vertaalt en een commandoregel-client de zin krijgt die hij altijd kreeg. Tot 0.18.0 stond er hier zeven keer Engels op een Nederlands scherm.

ssh root@panel1.corecp.dev
curl -s -b jar http://127.0.0.1:8080/api/v1/security/policy | jq '.file_only[0]'
# { "key": "session_ttl", "value": "12h0m0s",
#   "what": "how long a session lives without being used",
#   "what_msg": { "key": "policy.fileOnly.sessionTTL", "text": "how long a session lives without being used" } }

Ingetrokken certificaten

Dit scherm gaat over mensen die inloggen. Machines loggen niet in: elke server in de vloot bewijst wie hij is met een certificaat van de certificaatautoriteit van dit paneel, negentig dagen geldig en automatisch verlengd.

Gaat er een sleutel de deur uit — hardware vervangen, een machine gestolen, een back-up op een verkeerde plek beland — dan trek je dat certificaat in. Beveiliging → Ingetrokken certificaten laat zien wat de vloot weigert: welke machine, waarom, wanneer en door wie. Meestal staat er niets, en dat is de gezonde toestand.

Intrekken doe je op de pagina van de server zelf, onder Gevarenzone → Server uit dienst nemen. Twee dingen gebeuren er tegelijk: de certificaatautoriteit verlengt het certificaat niet meer, en elke server die antwoordt krijgt te horen dat hij het moet weigeren. Machines die op dat moment uit stonden krijgen de lijst alsnog — het paneel herhaalt hem elk kwartier, en de knop op dit scherm doet het meteen.

Duikt zo'n ingetrokken certificaat daarna toch weer op, dan onthoudt de server dat en krijg je er bericht over. Dat is precies zo'n melding die je niet wilt missen: iemand gebruikt een sleutel waarvan besloten is dat hij niet meer deugt.

Zie ook Een server beheren voor de knop zelf.

De autoriteit zelf, en wanneer hij verloopt

Onderaan dit scherm, onder Noodgrepen, staan een paar feiten over het paneel. Twee daarvan gaan over certificaten en het is de moeite waard ze uit elkaar te houden:

De tweede rij is nieuw. Hij staat er alleen voor beheerders: het is een eigenschap van het besturingsvlak, en de rest van het paneel krijgt de datum niet te zien. Zie je hem niet, dan is dat het antwoord en niet een storing.

Het paneel waarschuwt ruim op tijd — een jaar van tevoren oranje, drie maanden van tevoren rood — en die melding lees je op Servers → Monitoring, in het blok Dit paneel. Zie Wat het paneel over zichzelf weet.

Alles wordt vastgelegd

Elke wijziging op deze pagina is een regel in het auditlog, met wát er veranderde en waarvan naar wat:

ssh root@panel1.corecp.dev
corecp-panel audit list --action security.policy.factor --limit 5

En elke wijziging vraagt om een verse factor. Ook als je al een uur bent aangemeld: het paneel zet er een venster voor dat je nog één keer om je passkey of je code vraagt, en voert je handeling daarna alsnog uit. Je hoeft daar niets voor in te stellen.

Wat je hier instelt gaat over iedereen op dit paneel. Wat jíj zelf hebt staan — je eigen passkeys, je eigen tweede factor, je eigen sessies — staat bij Je account beveiligen.