Jeg trakk tilbake tilgangen, men de er fortsatt inne: en økt er ikke det samme som en rettighet
Du fjernet rettigheten, du stengte til og med kontoen, og likevel kan personen gjøre ting. Ingenting er ødelagt: å trekke tilbake tilgang og å avslutte en økt er to ulike handlinger.
AtlasPVE ·
Denne artikkelen svarer på
- proxmox slettet bruker kan fortsatt logge inn
- proxmox fjernet rettighet har fortsatt tilgang
- proxmox logger meg ut hele tiden
- hvor lenge varer en proxmox-økt
- proxmox tilbakekalle api-token
Du fjernet rettigheten til en bruker. Kanskje stengte du kontoen helt. Så merker du at personen fortsatt kan gjøre ting.
Ingenting er ødelagt. Å logge inn og å være berettiget er to ulike øyeblikk, og mellom dem ligger et gap.
Innloggingen skjer én gang, rettigheten spørres hver gang
Når du logger inn, rekker systemet deg en billett. Billetten sier: denne personen har bevist hvem hen er, og denne billetten gjelder til et bestemt tidspunkt.
Rettighet er et eget spørsmål som stilles på nytt ved hver forespørsel. Men i praksis tar mange systemer ved innlogging en kopi av rettighetskartet, av hensyn til farten, og bruker den kopien en stund.
Herav oppstår to forsinkelser.
Den første: når du fjerner en rettighet, kan en åpen økt fortsette å bære den kopien. Endringen når den først når økten fornyes.
Den andre, og viktigere: å slette eller stenge brukeren river ikke i stykker billetten hen holder. Billetten er selvstendig og gjelder til den utløper.
Regelen: å trekke tilbake tilgang er ikke å avslutte en økt
Dette er to ulike handlinger, og å gjøre bare den første lar et vindu stå åpent bak deg.
Vinduet er ikke uendelig; en billett gjelder ikke et døgn. Men det er heller ikke null, og i en hastesituasjon holder ikke svaret "det lukkes snart".
Når noen slutter, eller et passord er mistenkt
Gjør tre ting, i rekkefølge.
Fjern rettigheten. Steng kontoen også om det er berettiget.
Bytt passordet. Det stenger veien til å hente en fersk billett i stedet for den hen har. Å bare fjerne en rettighet gjør ikke det.
Fjern tilgangstokenene separat. Dette er steget som oftest hoppes over. Et token er ikke en økt: det utløper ikke av seg selv, det lever til du sletter det. Å bytte passordet til en bruker gjør ikke tokenene ugyldige. Når du fjerner en bruker, sjekk separat hva som ble av tokenene.
Og la oss rydde bort en misforståelse: tofaktorpålogging hjelper deg ikke her. Den beskytter selve påloggingsøyeblikket. Om en allerede åpen økt har den ingenting å si.
Motsatt retning: hvorfor logges jeg ut hele tiden
Det er den andre siden av den samme mekanismen.
Billetten har begrenset levetid, og grensesnittet fornyer den jevnlig så lenge du er på fanen. Lukk fanen og kom tilbake timer senere: ingen fornying har skjedd, billetten er død, og du blir bedt om å logge inn på nytt. Det er ikke en feil.
Den andre, mindre kjente årsaken er mer interessant: maskinens klokke. En billett bærer et tidsstempel. Om klokken på tjeneren driver, kan en nettopp utstedt billett se ut som om den kommer fra fremtiden eller for lengst er utløpt. Symptomet forvirrer: passordet er riktig, innloggingen ser ut til å bli godtatt, og rett etterpå faller økten. Å lete etter et klokkeproblem på identitetssiden faller ingen inn, men let.
Hva Atlas gjør
I Atlas er informasjonskapselen som går til nettleseren ikke den ekte billetten. Nettleseren bærer bare en meningsløs, tilfeldig identitet; selve billetten blir på tjeneren.
Forskjellen er konkret: selv om et nettleserhull leser kapselen, får det ikke tak i billetten selv, altså kan det ikke bære den et annet sted og bruke den der. Det eneste det kan gjøre er å handle fra den nettleseren så lenge den økten lever. Det er ikke null risiko, men det snevrer inn omfanget av trusselen.
Åpne økter skrives til disk, slik at ingen kastes ut når produktet oppdateres. Skrivingen gjøres bevisst i ett steg: hadde filen blitt halvskrevet, ville, selv om lesesiden tåler det, alle åpne økter ha falt.
Det som virkelig er verdt å fortelle, er en mangel som ble funnet her ved å måle.
Utløpte øktoppføringer ble ryddet bare fra minnet, ikke fra filen. En maskin i drift ble undersøkt: i filen lå fem utløpte oppføringer, hver med en billett inni. De ville blitt liggende der til neste innlogging, for ingenting annet skrev noen gang til den filen.
Kodens hensikt var allerede å ikke beholde dem. Det eneste som manglet, var skrivesteget.
Lærdommen gjelder alle som skriver sikkerhetskode: å glemme har to steder. Det som er fjernet fra minnet, er ikke fjernet fra disken, og av de to lever det på disken alltid lengst. Når du bestemmer at noe ikke skal oppbevares, er det andre spørsmålet alltid det samme: hvor oppbevares det?
Kilder
Proxmox sin egen dokumentasjon. På engelsk, og den har siste ord i denne saken.