Jeg er for tiden utfører en Unix tilsyn og ønsker veiledning om beste praksis for håndtering av root brukeren tilgang.

Organisasjonen er liten, med en IT-gruppe på ca 25.

Gi pass bare til dem som du stoler på. Logging roten handlinger som kan leses av alle brukere er bra også.

Jeg har aldri sett beste praksis gjennomføres. Men i en ideell verden ... Root-kontoen kan ikke brukes til å åpne boksen. Du logger deg på som bob, eller George, eller hva. Deretter su til root, forlate en revisjonsspor. Unntaket fra dette systemet konsoll port ... du kan logge på som root der, reboot maskinen etc. konsoll port kan nås bare fra datamaskinen rom. Eller, hvis det er for restriktive, konsollen porten åpnes fra en ekstern konsollen server. Du må registrere til konsollen server som deg selv og etterlater et revisjonsspor.

Root passord er et sterkt passord. Det er bare tilgjengelig for noen eksperter. Kan du gjenopprette fra en katastrofe? Hvis ikke, ingen root passord for deg. (Muligens en leder har, men ikke personlig bruk, passord.) Når en av disse ekspertene forlater du deaktivere kontoen sin. Og du endre root-passordet.

Andre mennesker bruker sudo hvis de trenger root for noe ... dette også forlater et revisjonsspor. Dette betyr ikke ALLE i sudoers imidlertid. Bare noen få begrenset kommandoer.

Noe sånt som dette er vår offisielle politikk. Men ulike bigshots ofte ordne unntak.

Jeg måtte holde fast i min 2-cent her. Et problem jeg har sett er en mangel på 'terminalservere med SSH (2) bare tilgang. Mye fortsatt bruke telnet. Telnet og BSD 'R'-kommandoer bør være forbudt. En annen er at ingen setter seg ned med CEO (president, eier etc.) og har en diskusjon om hva som er den sanne verdien av "ting" på sine datasystemer. Eller kostnadene til ham når disse systemene er ikke lenger tilgjengelig. Målet er å tvinge ham / henne inn i en sikkerhetspolitikk. Som burde virkelig begrense "bigshot" access.
Den endelige ting er noe en 'gamle' sysadmin gang fortalte meg. Vi var innstillingen root passord. Han grep en UNIX bok av sokkelen, fant et kapittel eller sub-kapittelet tittel med seks eller syv ord på det, tok den første bokstaven i hvert ord, 'munged' disse tegnene (a \u003d @; l \u003d | E \u003d 3, osv.) og stakk det første tegnet i hostname foran denne strengen, og det siste tegnet i vertsnavnet på slutten. Han hadde laget "samme" root-passordet på alle maskiner (lett å huske, spesielt hvis du skrev ned kapittelet tittel), og samtidig en annen root passord for hver maskin. Jeg har brukt denne (eller en variant) siden.

root kan bare få tilgang til noen boksen gjennom den konsollen, og bare SA-teamet har rot.
Hver av boksene har det egne pwd, ganske reassures du der boksen vår på
Alle passord utløper, unntatt root ... som jeg føler vi ikke endres ofte nok.

Vår butikk er en stor talsmann for sudo.
Vi har tatt menyene (som bruker sudo) på plass på alle systemer for Datactr personell for følgende tiltak:
Opprett unix kontoer (IS og bruker)
Endre passord (alle unntatt root)
Deaktiver IS og fjerne brukerkontoer.

Som nevnt før, alle disse aktivitetene vil forlate et revisjonsspor ... og I vårt tilfelle vil de også ha en tilhørende HelpDesk forespørselen #.
Husk når du måtte gjøre alle disse oppgavene ... sudo er din venn

Vi kan også bruke e-post (end-of-day) for å hjelpe oss å administrere andre overvåkingspolicyer, som følgende:
ugyldig forsøk på sudo (ikke gyldig sudo bruker)
ugyldig forsøk på su (ikke en del av SA team)
ugyldig pålogging forsøk 3 eller> ... disse er Timebaserte.
(Dette er bare et eksempel på hva som kan gjennomføres, denne listen kan gå-og-på)

fikk Sox?
I dagens Sox klima, jeg synes at alle disse retningslinjene og tilhørende tilsynet løyper er nødvendig.

Hvis du ikke har noe som ligner på plass, bør du tenke gjennom hvordan noen av dem kunne gi noen fordel til konv ..

Perderabo,

Jobben før min nåværende var sikkerheten ideelt. Alt som bodde i DMZ eller neste sonen var Trusted Solaris. Root kontoen var en "rolle", ikke en bruker - og dermed ingen direkte login overalt. RBAC styrte dagen og hadde blitt utvidet til å gi hva sudo kan og mer. Ingen tilgang som var ukryptert ble tillatt. Alle andre lag - app, transport, kunde-og database, trodde ikke TS ble oppsettet på en lignende måte. Omfattende revisjon eksistert og vedlikeholdes tilsynet logs lokale og aa ekstern plassering, slik at du kan checksum å sikre at revisjonsspor var uforandret.

Sikkerhet var stramt, men organiseres godt nok til å aldri bli et hinder for virksomheten.

Skål,

Keith