Midlertidige links til IP-tilladelseslister: hvad tilladelsen egentlig giver adgang til
Et link, der åbner en firewallport, tillader en adresse, ikke en person. Fastlæg omfanget, kræv bevidst bekræftelse, og test genafspilning, udløb og IPv6.
At gøre ét klik til en midlertidig firewallregel er bekvemt, og det bygger samtidig et autorisationssystem, der afgør, hvem der må nå en tjeneste. Det udsteder en adresse frem for en person, og den forskel betyder noget i det øjeblik, to personer deler en NAT. Afgræns tilladelsen, bekræft den bevidst, og giv udløbet mening, før linket bygges. Beslutningen foran dig er, hvor grænsen skal ligge, ikke om der bør findes en.
Afgør, hvilket spørgsmål tilladelsen besvarer
Start med kravet. Hvis en navngivet person skal nå tjenesten, og applikationen allerede autentificerer den person, holder en autentificeret gateway identiteten ved håndhævelsespunktet og har slet ikke brug for nogen adgangstilladelse på adresseniveau. Hvis målet er en build-agent, en administrativ jump-port eller en enhed, der ikke kan deltage i brugerlogin, kan en afgrænset adressetilladelse være den eneste praktiske kontrol.
At vælge adgangstilladelse på adresseniveau til en brugervendt applikation flytter det egentlige autorisationsproblem et andet sted hen, og portalen arver så skylden for et hul, den aldrig lukkede.
Afgræns anmodningen på serveren
Browseren må ikke vælge destinationen, porten eller præfikset. Portalen finder tjenesten i sine egne registreringer og kontrollerer rettigheden med en test på serversiden, hvilket er det samme princip, som OWASPs vejledning om autorisation anvender på hver anmodning. Adresseafledning hører også til ved den beskyttede grænse: når en omvendt proxy rapporterer klientadressen, accepter kun den konfigurerede proxykæde og dens dokumenterede headerhåndtering. En videresendelsesheader, som en besøgende leverer, er en påstand om oprindelse, ikke et bevis for den.
Kontrollér derefter, at portalen og tjenesten ser den samme kilde. Delt tunnelling, et proxyspring og IPv4 kontra IPv6 kan give to destinationer to forskellige adresser, så en tilladelse, der er aktiveret ad én vej, dækker måske ikke den følgende anmodning.
Vis tilladelsen, før den installeres
Åbning af et link bør vise den foreslåede tjeneste, den observerede kilde og varigheden og endnu ikke ændre noget. Det ene trin gør linket fra e-mailen fra en handling til et forslag, og det forhindrer en preview-bot eller en mailscanner i at give adgang blot ved at hente det.
Bekræftelsen bør være en anmodning, der ændrer tilstand, med de sædvanlige tværsites- og oprindelsesforsvar. Tokenet bør være engangs og forbruges atomisk i det øjeblik, reglen installeres, og registreringen bør fastholde ejer, tjeneste, adresse, tilladelses-id og udløb uden nogensinde at logge det rå token.
Levering af tokenet fortjener samme omhu som reglen selv. Et udløbet eller allerede forbrugt link, der stadig frembringer en regel, er en anden dør monteret med den samme nøgle.
Adressen deles, selv mens tilladelsen lever
Kontor-NAT, udbyder-NAT og en delt VPN-udgang sætter hver flere personer bag én adresse. At tillade den adresse tillader alle bag den — så vidt tjenestens næste grænse angår —, mens det ikke beviser noget om, hvem der har den konto, tjenesten forventer.
At fjerne reglen er heller ikke en universel afbrydelse. Etablerede forbindelser, cachelagrede applikationstokens og langlivede sessioner kan overleve reglen i minutter eller langt længere, så den levetid, du vælger, bør afspejle, hvad tjenesten gør efter adgang, og ikke kun hvor længe reglen findes.
Test fire tilfælde og begge adressefamilier
En tilladelse er kun så god som de fire tilfælde, den overlever: en ny tilladt anmodning, en ikke-godkendt anmoder, en genafspilning af det samme link og den samme anmodning efter udløb.
Test derefter hver familie særskilt, fordi den kildeadresse, tjenesten observerer, kan variere mellem dem.
dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
Det nyttige resultat er en midlertidig, reviderbar adgangsbeslutning under normal brugerautorisation, ikke en permanent åbning, der bærer navnet på den, der klikkede først.