Af Greg Nowak. Senest opdateret 2026-07-30.
Glemte staging-sites begynder sjældent som sikkerhedsfejl. En udvikler har brug for en preview-URL, et bureau skal have midlertidig adgang, eller en leverandør har brug for et administrationspanel i forbindelse med en lancering. Projektet går videre, men det offentlige hostname, den delte adgangskode eller firewall-undtagelsen bliver hængende.
Det gør eksponerede staging- og administrationsflader til et driftsproblem i lige så høj grad som et teknisk problem. Hvis ingen med sikkerhed kan sige, hvad der er online, hvem der ejer det, og hvilke personer eller systemer der stadig har brug for adgang, løser endnu en login-side ikke den underliggende knopskydning.
Cloudflare Access kan lægge et nyttigt identitetslag foran disse applikationer uden behov for en traditionel VPN. En vellykket implementering afhænger dog af en komplet oversigt, korrekt afgrænsning af applikationerne, beskyttelse af origin-serveren og en gennemtænkt plan for automatiseret trafik.
Begynd med en adgangsoversigt
Registrer alle staging-hostnames, kundepreviews, interne dashboards, partnerportaler, CMS-login og følsomme stier som /wp-admin. Medtag også endpoints, der betragtes som midlertidige; det er ofte dem, der med mindst sandsynlighed har en navngiven ejer.
Registrer for hvert endpoint den forretningsmæssige ejer, den tekniske ejer, de tiltænkte brugere, hostingplaceringen, origin-adressen, autentificeringsmetoden og eventuel maskintrafik. Kontrollér monitoreringssystemer, CI-pipelines, webhooks, planlagte jobs og leverandørintegrationer, før adgangen ændres. Ellers risikerer den første komplette oversigt at ankomme som en samling fejlmeldinger efter lanceringen.
| Endpoint eller workflow | Sandsynlig Access-model | Vigtig kontrol |
|---|---|---|
| Offentligt staging-hostname eller webadministration | Self-hosted applikation | Beskyt hostnamet eller den præcise sti, og valider tokens på origin-serveren |
| Internt webværktøj med privat routing | Privat self-hosted destination | Bekræft kravene til klienten og routing på det private netværk |
| Tredjepartsprodukt med understøttelse af SAML eller OIDC | SaaS-applikation | Bekræft leverandørens SSO-funktioner og sessionsadfærd |
| SSH-server med krav om styring af port eller brugernavn | Infrastrukturapplikation | Planlæg brugen af Cloudflare One Client og privat routing |
| Link vist i App Launcher | Bogmærke | Et bogmærke styrer feltets synlighed; det beskytter ikke destinationen |
| CI-, monitorerings- eller webhook-request | Service Auth-policy | Opbevar, rotér og tilbagekald legitimationsoplysningerne som enhver anden secret |
Vælg afgrænsningen med omhu
For de fleste browserbaserede staging-sites og administrationspaneler, som du selv kontrollerer, er en self-hosted applikation det naturlige udgangspunkt. Access kan beskytte et helt hostname eller en bestemt sti. Beskyttelse på stiniveau kan være nyttig for et administrationsområde, men undersøg først applikationen: login-callbacks, API'er, stier til assets, preview-links og baggrundsrequests kan krydse den grænse, du ønskede at etablere.
Mere specifikke applikationsstier har forrang og arver ikke automatisk alle regler fra den bredere sti. Dokumentér overlappende applikationer, så en senere policyændring ikke skaber et uventet hul.
Brug en SaaS-applikation, når Cloudflare skal indgå i en tredjepartstjenestes SAML- eller OIDC-login. Brug kun App Launcher som en praktisk oversigt. Dens policy bestemmer, hvem der kan åbne launcheren, mens hver underliggende applikation beholder sine egne tilladelser. En gennemarbejdet portal er ikke dokumentation for, at destinations-URL'erne er beskyttet.
Brug en sikker rækkefølge ved implementeringen
For en interneteksponeret applikation er den praktiske rækkefølge:
- Opret Access-applikationen til det ønskede hostname eller den ønskede sti.
- Tilføj snævre Allow-policies, og vælg den relevante identitetsudbyder.
- Angiv en sessionsvarighed, der passer til følsomheden og arbejdsmønstret.
- Test med en godkendt bruger og med en konto, der skal afvises.
- Udgiv origin-serveren via Cloudflare Tunnel, eller begræns adgangen til den eksisterende offentlige origin-server.
- Aktivér validering af Access-token på origin-serveren, og test requests direkte til den.
- Migrer automatiserede klienter, og fjern derefter forældede undtagelser og delte legitimationsoplysninger.
Cloudflare anbefaler, at Access-applikationen oprettes, før tunnelruten udgives. Uden applikationen kan den nyligt udgivne tjeneste være tilgængelig fra internettet. Access-applikationer afviser som standard adgang, men det hjælper først, når det korrekte hostname og de relevante stier er dækket af en policy.
Beskyt origin-serveren – ikke kun hoveddøren
Et Access-login ved Cloudflares edge er utilstrækkeligt, hvis origin-serveren stadig kan tilgås via sin IP-adresse, en gammel DNS-record eller et alternativt hostname. Cloudflare anbefaler at validere applikationens token på origin-serveren, så requests, der går uden om Access, bliver afvist.
Med Cloudflare Tunnel kan cloudflared udføre denne kontrol via indstillingen Protect with Access. Alternativt kan applikationen eller reverse proxyen validere tokenet. Hvis applikationen fortsat er offentligt routbar uden en tunnel, skal dens origin-IP også begrænses med passende netværkskontroller.
Adskil mennesker fra maskiner
Interaktive brugere skal autentificere sig som sig selv. Teknikere, der har brug for adgang fra kommandolinjen, kan bruge:
cloudflared access login https://staging.example.comHeadless jobs bør ikke være afhængige af en persons browsersession eller en delt medarbejderkonto. Opret et service-token, og match det med en Service Auth-policy:
curl -H "CF-Access-Client-Id: <CLIENT_ID>" \
-H "CF-Access-Client-Secret: <CLIENT_SECRET>" \
https://staging.example.com/healthCloudflare viser kun client secreten, når tokenet oprettes, så gem den med det samme i et godkendt secret store. Giv tokens genkendelige navne, ejere, udløbsdatoer og snævert afgrænsede applikationer. Cloudflare understøtter også, at begge værdier placeres i én konfigureret header, når en ekstern tjeneste kun accepterer én tilpasset header.
Undgå brede Bypass-regler til monitorering eller leverandørautomatisering. Bypass deaktiverer Access-håndhævelsen for matchende trafik, disse requests logges ikke af Access, og handlingerne Bypass og Service Auth evalueres før almindelige Allow- og Block-policies. En bekvem undtagelse kan derfor underminere den kontrol, du ønskede at indføre.
Gør oprydningen nem at vedligeholde
Før projektet afsluttes, skal hver beskyttet applikation have en ejer, formålet med dens policy skal dokumenteres, og der skal planlægges gennemgange af konsulenter, bureauer, service-tokens, DNS-records og inaktive endpoints. Indarbejd ændringer i Access i procedurerne for onboarding, offboarding og udfasning af miljøer.
Det værdifulde resultat er ikke blot »Cloudflare Access aktiveret«. Det er en lille og forståelig adgangsmodel, hvor hvert eksponeret værktøj har en ejer, hver bruger eller maskine har en passende autentificeringsvej, og origin-serveren ikke ubemærket kan omgå policyen.
Hvis jeres staging- og administrationsmiljø har bredt sig på tværs af Cloudflare, DNS, identitetsudbydere, CI-systemer og leverandørkonti, kan I tale med Greg om en fokuseret adgangsrevision og implementeringsplan. Målet er at lukke de glemte adgangsveje uden at afbryde de workflows, som teamet stadig har brug for.
Relateret indhold på GrN.dk
- AI-automatiseringer har brug for et forbrugsdashboard før den første løbske regning
- Den risikable del af pilotprojekter med AI-workflows er ofte OAuth-skærmen
- Styring af AI-crawlere på virksomhedswebsites: Beskyt indholdet uden at forsvinde fra søgeresultaterne
Har du brug for hjælp til denne type opgave?
Tal om jeres oprydning i Cloudflare Access med Greg. Kontakt Greg.
