auditd är ett område där små designval ofta avgör om kontrollen blir robust eller bara ser bra ut på papper. auditd är användbart när frågan är exakt vilken säkerhetsrelevant operation som utfördes, av vilken identitet och mot vilket objekt.
auditd i praktiken
Första byggstenen: Audit rules kan följa känsliga filer eller specifika systemanrop. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: Auid kan bevara den ursprungliga inloggade identiteten genom sudo. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Nycklar på regler gör senare sökning enklare. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: För bred syscall-loggning kan skapa stora mängder data. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Praktisk införandeordning
- Definiera först vilka handlingar som måste vara spårbara.
- Lägg få, namngivna regler på kritiska objekt.
- Generera en kontrollerad testhändelse.
- Sök tillbaka händelsen med ausearch eller rapportverktyg.
- Mät loggvolym och justera innan bred utrullning.
För auditd håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Så kan det se ut
Om /etc/sudoers.d är särskilt känslig kan en filregel ge en tydlig spårpunkt när någon ändrar behörighetspolicyn. Jag kan då korrelera tid, auid och den process som gjorde ändringen.
Tre risker i implementationen
- Att logga allt och sedan inte kunna hitta något viktigt.
- Att sakna en retentionplan för audit-loggar.
- Att aldrig testa att den regel man skrev faktiskt fångar den tänkta operationen.
När jag anser ändringen färdig
För auditd vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- En teständring syns med rätt identitet.
- Loggrotation behåller tillräcklig historik.
- Reglerna laddas efter reboot.
Ett negativt test hör också till auditd: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
auditd – spåra säkerhetsrelevanta händelser i Linux utan att drunkna i loggar handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.