Ingen stående adgangsveje
Den anbefalede udrulning er en pull-agent-tjeneste på serveren, til både Windows og Linux. Tjenesten forbinder selv udad til sslbrain via HTTPS og henter sine opgaver. Appliancen har derfor ingen SSH-nøgle, ingen adgangskode og ingen sudo-rettighed til serveren, og der åbnes ingen porte indad. Der findes ganske enkelt ikke en stående adgangsvej at stjæle.
Sikkerhedsgrænsen er signaturen, ikke netværket
Agenten udfører kun opgavepakker, der er signeret og verificeret mod en fastlåst trust anchor. En opgave uden gyldig signatur fra en nøgle, du har valgt at stole på, bliver afvist, uanset hvor den kommer fra. Det flytter sikkerhedsgrænsen fra netværksvejen til signaturen: Det afgørende er ikke, hvem der kan nå serveren, men hvilken kode du har godkendt.
Der er en præcis grænse for garantien, og den siger vi ligeud. En kompromitteret appliance kan stadig få dine agenter til at køre FairSSL-signerede scripts med input valgt af en angriber, herunder installere et certifikat fra en angriber, og kun med de rettigheder, du selv har givet agenten. Det, den ikke kan, er at indføre ny eller usigneret kode.
Du vælger rettighedsniveauet
Hvor mange rettigheder tjenesten kører med, bestemmer du lokalt på serveren. Kør den som root eller LocalSystem, hvis enkelhed vejer tungest. Eller kør den som en afgrænset servicebruger, der kun har skriveadgang til én tjenestes certifikatfiler og lov til at køre én reload-kommando. sslbrain fungerer i begge modeller og kræver aldrig mere, end opgaven skal bruge.
Push som fallback, også med least privilege
Udstyr, der ikke kan køre en tjeneste, for eksempel netværksudstyr og appliances, håndteres via push over SSH eller API. Også her kan kontoen afgrænses: en dedikeret bruger med adgang til certifikatstierne og, hvor det kræves, en snævert afgrænset sudo-regel for præcis de kommandoer, installationen skal bruge. Se principperne bag signering og godkendelse under politikstyring.