Access

Access nedir?

“Cloudflare Access is a zero trust network access (ZTNA) solution designed to secure access for employees and contractors across self-hosted, SaaS, and non-web applications, eliminating the need for a traditional VPN.”

Klasik VPN modelinde kullanıcı ağa girer, sonra ağdaki her şeye erişir. Access’te ağ diye bir şey yok: her uygulama tek tek korunuyor ve her istekte kimlik, cihaz ve bağlam yeniden değerlendiriliyor.

Temel kural tek cümlede:

“All Access applications are deny by default — a user must match an Allow policy before they are granted access.”

Tunnel ile sınır tam olarak nerede

Bu, en çok karıştırılan ayrım:

Tek cümlelik özet: Tunnel paketi gelen port açmadan Cloudflare’e taşır; Access isteğin geçip geçmeyeceğine karar verir. Genel erişime açık uygulamada Access tek başına çalışır ama origin IP’n açıkta kalır. Özel ağ veya altyapı hedefinde Tunnel (ya da Mesh, ya da Cloudflare WAN) zorunludur.

Nasıl çalışır?

Dört uygulama tipi

Self-hosted dört ayrı biçimde kurulabiliyor: genel hostname, özel IP/hostname/CIDR + port, doğrudan bir Cloudflare Worker’ı adıyla, ve cloudflared access login ile CLI üzerinden.

Infrastructure yalnızca SSH. Birebir: “Access for Infrastructure currently supports SSH. To connect using other protocols, add a self-hosted private application. For browser-based SSH, RDP, or VNC, refer to browser-rendered terminal.” Ve “Cloudflare will not create new users on the target. UNIX users must already be present on the server.”

Policy’ler — dört yapı taşı

Aksiyonlar: Allow, Block, Bypass, Service Auth. “You can set only one action per policy.”

Kural tipleri ve mantık karşılıkları:

Değerlendirme sırası listedeki sıra değil, aksiyon tipine göre:

“Bypass and Service Auth policies are evaluated first, from top to bottom as shown in the UI. Then, Block and Allow policies are evaluated based on their order from top to bottom.”

Cloudflare’in örneği: listede Allow A · Block B · Service Auth C · Bypass D · Allow E varsa çalışma sırası Service Auth C → Bypass D → Allow A → Block B → Allow E. Ve “Once a user matches an Allow or Block policy, evaluation stops.” Yayılma ~60 saniye.

Seçicilerin sürekli değerlendirilip değerlendirilmediği de önemli: “Non-identity attributes are polled continuously, meaning they are evaluated with each new HTTP request.” Kimlik temelli seçiciler (e-posta, IdP grubu, login yöntemi) yalnızca giriş anında; IP, ülke, sertifika, service token, cihaz duruşu ve WARP/Gateway sürekli.

İki token, dört süre katmanı

Süreler en özelden en genele: Client session (varsa hepsini eziyor) → Policy session → Application session → Global session. Aralık 15 dakika – 1 ay, varsayılan 24 saat.

Yenilenme mantığı: “When the application token expires, Cloudflare will automatically issue a new application token if the global token is still valid… If the global token has also expired, the user will be prompted to re-authenticate with the IdP.”

Global token’ı daha uzun tutmanın gerekçesi: “the global token cannot be used to directly access an application.”

JWT’nin içi

{
  "aud": ["32eafc7626e974616deaf0dc3ce63d7bcbed58a2731e84d06bc3cdf1b53c4228"],
  "email": "kullanici@sirket.com",
  "exp": 1659474457, "iat": 1659474397, "nbf": 1659474397,
  "iss": "https://takim.cloudflareaccess.com",
  "type": "app",
  "sub": "7335d417-61da-459d-899c-0a01c76a2f94",
  "country": "TR"
}

type değeri app (uygulama token’ı) veya org (global oturum). Service token ile gelen isteklerde common_name doluyor ve "sub": "" boş kalıyor.

Origin’de doğrulama — ve atlatma riski

Bu sayfadaki en önemli bölüm. Doküman aynı şeyi iki ayrı yerde söylüyor:

“Unless your application is connected to Access through Cloudflare Tunnel, your application must validate the token to ensure the security of your origin. Validation of the header alone is not sufficient — the JWT and signature must be confirmed to avoid identity spoofing.”

“The external API should validate the application token issued by Cloudflare Access to ensure that any requests which bypass Access (for example, due to a network misconfiguration) are rejected.”

Tehdit modeli basit: Access Cloudflare kenarında çalışıyor. Origin IP’ni öğrenen biri doğrudan bağlanırsa giriş ekranı hiç devreye girmiyor. Bir DNS kaydı gri buluta alınırsa, bir firewall kuralı gevşerse de aynı şey oluyor.

Doğrulanacak üç şey: imza (RS256, JWKS’e karşı), iss (takım alan adın), aud (uygulamanın AUD etiketi).

const JWKS = jose.createRemoteJWKSet(
  new URL(`${TAKIM_ALAN_ADI}/cdn-cgi/access/certs`),
);
const token = request.headers.get("cf-access-jwt-assertion");
if (!token) return new Response("token yok", { status: 403 });
const { payload } = await jose.jwtVerify(token, JWKS, {
  issuer: TAKIM_ALAN_ADI,
  audience: AUD,
});

Cloudflare Workers, Go, Python (Flask) ve Node.js (Express) için çalışan örnek yayımlıyor. nginx için native bir doğrulayıcı yok — doküman gövdesinde nginx 18 kez geçiyor ve hiçbiri bu bağlamda değil (pozitif kontrol: apache 43 eşleşme). Pratik yol nginx’in auth_request direktifiyle bu örneklerden birine delege etmek.

Cihaz duruşu

Üç aile var ve ayrım kritik:

İstemcisiz çalışan iki kontrol: Microsoft Entra ID Conditional Access ve Mutual TLS. Ve bunlar “cannot be used in Gateway network policies” — yalnızca Access’te.

Hiçbiri Enterprise gerektirmiyor. Doküman gövdesinde /posture-checks/ bloğunda plan kısıtı ifadesi yok; tek “Feature availability” tablosu “All plans” diyor. Pozitif kontrol olarak aynı gövdede enterprise plan 56 eşleşme veriyor — yani Cloudflare bu kapıyı gerektiğinde açıkça yazıyor.

Zamanlama: Client varsayılan olarak beş dakikada bir yokluyor. Access aynı hızda algılıyor, Gateway ise beş dakika daha gecikiyor — 10 dakikalık yoklamada toplam 15 dakikaya kadar. Ve “Gateway does not terminate an active session even if a subsequent posture check fails during that session.”

Ne zaman kullanılır, ne zaman kullanılmaz

Uygun olduğu işler

• İç web uygulamalarını VPN olmadan açmak — wiki, Jenkins, Grafana, ERP
• Yüklenici ve dış ekiplere süreli, dar kapsamlı erişim vermek
• SaaS uygulamalarının önüne tek bir SSO katmanı koymak (35 hazır entegrasyon + generic SAML/OIDC)
• SSH erişimini port açmadan, komut kaydıyla vermek
• Bu sitenin /yonetim/ paneli gibi tek kişilik yönetim arayüzlerini kapatmak

Uygun olmadığı işler

• Origin’de doğrulama yapmadan, Tunnel’sız kurulum. Access atlanabilir hâle geliyor.
• RDP’yi altyapı uygulaması sanmak. Access for Infrastructure yalnızca SSH; RDP için browser-rendered terminal var ve o da yalnızca genel hostname’lerde çalışıyor.
• Bypass ile hızlı çözüm. Hiçbir kontrol uygulamıyor, hiçbir şey loglamıyor.
• groups claim’ine dayalı yetkilendirme. 1 KB sınırında sessizce kırpılıyor.
• SaaS uygulamasında oturumu kontrol etmek. “Access does not control how long the user can stay in the SaaS app itself.”
• Tarayıcıdan RDP’de sertifika zinciri doğrulaması beklemek. “We do not currently validate the chain of trust.”

Somut örnekler

1. Bu sitenin yönetim paneli

/yonetim/ yolu bir self-hosted Access uygulamasıyla korunuyor, policy’si tek satır:

Allow │ Include │ Emails │ samet.canturk@tdsynnex.com

Ama Access tek katman değil — Worker gelen Cf-Access-Jwt-Assertion başlığını yeniden doğruluyor: JWKS’ten kid eşleştiriyor, iss ve aud kontrol ediyor, sonra e-postayı listeyle karşılaştırıyor. Bu sayede *.workers.dev adresi üzerinden dolaşmak da işe yaramıyor — o adres Access’in kapsamında değil ama Worker’ın kapsamında.

2. Rule group ile Require tuzağından kaçmak

Yanlış:

Allow │ Require │ Country │ Türkiye, Almanya       ← ikisi birden olmak zorunda

Doğru:

Rule group "Ülke kuralları":
  Include │ Country │ Türkiye
  Include │ Country │ Almanya

Allow │ Require │ Rule group      │ Ülke kuralları
      │ Include │ Emails ending in│ @sirket.com

3. Service token ile makineye erişim

CI/CD veya bir izleme sistemi için, koltuk tüketmeden:

Service Auth │ Include │ Service Token │ ci-deploy-token

İstemci iki başlık gönderiyor: CF-Access-Client-Id ve CF-Access-Client-Secret. JWT’de common_name doluyor, sub boş kalıyor.

4. Kimliği origin’e taşımak

curl -H "cookie: CF_Authorization=<token>" \
  https://<takim>.cloudflareaccess.com/cdn-cgi/access/get-identity

Dönen alanlar: email, idp, geo, user_uuid, devicePosture, ip, auth_status, common_name, is_warp, is_gateway, device_id, device_sessions.

5. SPA’de oturum bitişini yakalamak

fetch("/api/veri", { headers: { "X-Requested-With": "XMLHttpRequest" } })
  .then((y) => {
    if (y.status === 401) location.reload();   // Access oturumu bitti
    return y.json();
  });

Bu başlık olmadan Access yönlendirme döndürüyor ve fetch sessizce giriş sayfasının HTML’ini alıyor.

Demo 1: Access’i atlat, sonra atlatılamaz hâle getir

Bu demonun tamamı tek bir cümleyi kanıtlamak için: “Unless your application is connected to Access through Cloudflare Tunnel, your application must validate the token.”

Ön koşullar: Ubuntu sunucu (public IP), ornek.com Cloudflare’de aktif, Zero Trust hesabı.

export ZONE=ornek.com
export HOST=ic-panel.$ZONE
export ORIGIN_IP=203.0.113.10

Adım 1 — Korunacak servisi kur

sudo apt update && sudo apt install -y nginx python3-pip
sudo mkdir -p /var/www/ic-panel
echo '<h1>Gizli iç panel</h1><p>Bu sayfayı yalnızca yetkili kişiler görmeli.</p>' \
  | sudo tee /var/www/ic-panel/index.html

sudo tee /etc/nginx/sites-available/ic-panel.conf >/dev/null <<'EOF'
server {
    listen 80;
    server_name ic-panel.ornek.com;
    root /var/www/ic-panel;
    index index.html;
}
EOF
sudo ln -sf /etc/nginx/sites-available/ic-panel.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

ic-panel.ornek.com için proxied (turuncu bulut) bir A kaydı oluştur.

Terminal — nginx -t başarı çıktısı ve panelde ic-panel kaydının turuncu bulutlu görünmesi; ikisi yan yana

Adım 2 — Access uygulamasını oluştur

Panel: Zero Trust → Access → Applications → Add an application → Self-hosted

• Application domain: ic-panel.ornek.com
• Policy: Allow · Include · Emails · kendi e-postan

Panel — uygulama yapılandırma ekranı ve policy tanımı; Include/Emails satırı görünür durumda

Adım 3 — Access’in çalıştığını doğrula

curl -sI https://$HOST/ | head -3

302 ve location: https://<takim>.cloudflareaccess.com/cdn-cgi/access/login/... görmelisin. Tarayıcıdan açınca giriş ekranı geliyor.

İki bölmeli görüntü — solda curl çıktısında 302 ve cloudflareaccess.com'a giden location başlığı, sağda tarayıcıda Access giriş ekranı

Adım 4 — Access’i ATLAT

Şimdi origin IP’sine doğrudan bağlan. --resolve DNS’i atlıyor:

curl -s --resolve $HOST:80:$ORIGIN_IP http://$HOST/ | head -5

Gizli sayfa açılıyor. Giriş ekranı yok, JWT yok, log yok.

Terminal — curl --resolve çıktısında 'Gizli iç panel' başlığının HTML'i; Access'in hiç devreye girmediği net görünsün

Adım 5 — JWT doğrulayıcısını kur

AUD etiketini panelden al: Access → Applications → Configure → Additional settings → Application Audience (AUD) Tag.

sudo pip3 install --break-system-packages flask PyJWT cryptography requests

sudo tee /opt/access-dogrula.py >/dev/null <<'PY'
import os, jwt, requests
from flask import Flask, request
from cryptography.hazmat.primitives import serialization

TAKIM = os.environ["TEAM_DOMAIN"]          # https://<takim>.cloudflareaccess.com
AUD   = os.environ["POLICY_AUD"]
CERTS = f"{TAKIM}/cdn-cgi/access/certs"

app = Flask(__name__)

def anahtar(kid):
    # public_cert DEGIL: kid eslestirmesi. Rotasyonda eski deger okunmasin diye.
    for k in requests.get(CERTS, timeout=5).json()["keys"]:
        if k["kid"] == kid:
            return jwt.algorithms.RSAAlgorithm.from_jwk(k)
    return None

@app.route("/dogrula")
def dogrula():
    token = request.headers.get("Cf-Access-Jwt-Assertion")
    if not token:
        return "token yok", 403
    try:
        kid = jwt.get_unverified_header(token)["kid"]
        pk = anahtar(kid)
        if pk is None:
            return "anahtar eslesmedi", 403
        jwt.decode(token, pk, algorithms=["RS256"], audience=AUD, issuer=TAKIM)
    except Exception as e:
        return f"gecersiz: {e}", 403
    return "", 200

app.run(host="127.0.0.1", port=8099)
PY

TEAM_DOMAIN="https://<takim>.cloudflareaccess.com" \
POLICY_AUD="<aud-etiketi>" \
  sudo -E python3 /opt/access-dogrula.py &

Adım 6 — nginx’i doğrulayıcıya bağla

sudo tee /etc/nginx/sites-available/ic-panel.conf >/dev/null <<'EOF'
server {
    listen 80;
    server_name ic-panel.ornek.com;
    root /var/www/ic-panel;
    index index.html;

    location = /_access {
        internal;
        proxy_pass              http://127.0.0.1:8099/dogrula;
        proxy_pass_request_body off;
        proxy_set_header        Content-Length "";
        proxy_set_header        Cf-Access-Jwt-Assertion $http_cf_access_jwt_assertion;
    }

    location / {
        auth_request /_access;
        try_files $uri $uri/ =404;
    }
}
EOF
sudo nginx -t && sudo systemctl reload nginx

Adım 7 — Aynı atlatmayı tekrar dene

echo "--- dogrudan origin'e (artik reddedilmeli) ---"
curl -s -o /dev/null -w "%{http_code}\n" --resolve $HOST:80:$ORIGIN_IP http://$HOST/

echo "--- Cloudflare uzerinden (calismali) ---"
curl -sI https://$HOST/ | head -1

Doğrudan istek artık 403. Cloudflare üzerinden giriş yapınca sayfa açılıyor.

Terminal, tek kare — üstte Adım 4'teki başarılı HTML çıktısı hatırlatması ya da yeniden çalıştırılmış hâli, altta aynı komutun 403 döndürmesi. Öncesi ve sonrası aynı görüntüde olsun

Adım 8 — Sahte token da geçmesin

curl -s -o /dev/null -w "sahte token: %{http_code}\n" \
  -H "Cf-Access-Jwt-Assertion: sahte.token.degeri" \
  --resolve $HOST:80:$ORIGIN_IP http://$HOST/

Yine 403 — başlığın varlığı yetmiyor, imza doğrulanıyor. Bu, dokümanın “Validation of the header alone is not sufficient” uyarısının kanıtı.

Terminal — sahte token ile 403 ve doğrulayıcı sürecinin log çıktısındaki hata mesajı

Adım 9 — Anahtar rotasyonuna hazır olduğunu göster

curl -s https://<takim>.cloudflareaccess.com/cdn-cgi/access/certs | jq '{
  anahtar_sayisi: (.keys | length),
  kid_listesi: [.keys[].kid],
  public_certs_sayisi: (.public_certs | length)
}'

İki anahtar dönüyor: mevcut ve bir önceki. Doğrulayıcın public_cert yerine kid eşleştirdiği için rotasyonda kesinti olmuyor.

Terminal — jq çıktısında anahtar sayısı 2 ve iki kid değeri; rotasyon penceresinin kanıtı

Demo 2: Require tuzağını üret ve düzelt

Bu demo tek bir yapılandırma hatasının nasıl herkesi kilitlediğini gösteriyor — ve hata mesajı yardımcı olmadığı için sahada saatler kaybettiriyor.

Adım 1 — Çalışan bir policy ile başla

Allow │ Include │ Emails ending in │ @sirket.com

# Tarayicidan giris yap, sonra:
curl -sI https://$HOST/ -H "cookie: CF_Authorization=$TOKEN" | head -1

Panel — tek Include kuralı olan policy ekranı, yanında tarayıcıda açılan iç panel

Adım 2 — Ülke kısıtını “doğal” yoldan ekle

Allow │ Include │ Emails ending in │ @sirket.com
      │ Require │ Country          │ Türkiye, Almanya

Sezgi: “kullanıcı Türkiye’de veya Almanya’da olsun.” Gerçek: ikisinde birden olsun.

curl -sI https://$HOST/ | head -1

Kimse giremiyor. Access “erişim reddedildi” diyor ama nedenini söylemiyor.

İki bölmeli görüntü — solda panelde iki satırlı policy, sağda tarayıcıda Access'in erişim reddi ekranı

Adım 3 — Logda ne göründüğüne bak

Panel: Zero Trust → Logs → Access

Panel — Access log satırında kullanıcı, uygulama, sonuç (denied) ve varsa sebep alanı; sebebin ne kadar az bilgi verdiği görünsün

Adım 4 — Rule group ile düzelt

Panel: Access → Policies → Rule groups → Create

Rule group "Ülke kuralları":
  Include │ Country │ Türkiye
  Include │ Country │ Almanya

Sonra policy’yi şuna çevir:

Allow │ Include │ Emails ending in │ @sirket.com
      │ Require │ Rule group       │ Ülke kuralları

sleep 60      # yayilma ~60 saniye
curl -sI https://$HOST/ -H "cookie: CF_Authorization=$TOKEN" | head -1

İki bölmeli görüntü — solda rule group tanımı, sağda düzeltilmiş policy ve çalışan erişim

Adım 5 — Değerlendirme sırasını da gör

Policy listesine bir Bypass ekle ve sıranın listedeki sıra olmadığını kanıtla:

1. Allow      │ Include │ Emails ending in │ @sirket.com
2. Block      │ Include │ Country          │ (test için kendi ülken)
3. Bypass     │ Include │ IP ranges        │ (kendi IP'n)

Sezgi: 2. sıradaki Block önce çalışır. Gerçek: 3. sıradaki Bypass önce çalışıyor ve seni içeri alıyor — “Bypass and Service Auth policies are evaluated first.”

İki bölmeli görüntü — solda üç policy'nin listedeki sırası, sağda erişimin sağlandığını gösteren tarayıcı; Bypass'ın kazandığı net olsun

Adım 6 — Bypass’ın loglamadığını kanıtla

Aynı isteği tekrar at, sonra Zero Trust → Logs → Access ekranına bak. Bypass ile geçen istek logda yok.

Panel — log ekranında son isteklerin listesi; Bypass ile yapılan isteğin kaydı bulunmuyor. Zaman damgaları karşılaştırılabilir olsun

Ölçüm tablosu

Fiyatlandırma

Rakamlar 1 Eylül 2026’da cloudflare.com/sase/products/access sayfasından alındı — bu, fiyatları statik HTML’de sunan tek resmî sayfa.

Her planda dahil olanlar: özelleştirilebilir erişim politikaları ve policy tester, self-hosted / SaaS / web olmayan (SSH, VNC, RDP) uygulamalar, eşzamanlı birden çok IdP, generic SAML ve OIDC, kimlik temelli bağlam, üçüncü taraf cihaz duruşu entegrasyonları, istemcisiz erişim, tarayıcıdan SSH ve VNC, split tunneling, App Launcher, service token’lar, iç DNS ve Local Domain Fallback, Terraform, mTLS kimlik doğrulama, DNS/HTTP/L4 filtreleme, SSH proxy ve komut kaydı, Shadow IT keşfi, DEX.

Lisanslama ve hukuki çerçeve

Access tescilli bir hizmettir ve Cloudflare Hizmet Şartlarına tabidir.

Log saklama — pazarlama ile dokümantasyon çelişiyor. İkisini de veriyoruz:

Pazarlama sayfası: “Standard log retention — up to 24 hours / up to 30 days / Up to 6 months” ve ayrıca “Block policy decisions are stored for a week, and authentication logs for 6 months.”

Dokümantasyon (yetkili tablo):

Üç ayrı uyuşmazlık: plan adları farklı (pazarlama Free/Pay-as-you-go/Contract; doküman Free/Standard/Access/Gateway/Enterprise ve “Pay-as-you-go” sütunu hiç yok), “6 ay” ile “180 gün” aynı şey değil ve doküman 180 günü yalnızca Access ve DNS loglarına veriyor, ve “block policy decisions… a week” ifadesi yalnızca pazarlama sayfasında geçiyor.

Türkiye — Access bu bölgeye sabitlenemiyor.

Cloudflare Türkiye’yi bir Regional Services bölgesi olarak destekliyor: “Cloudflare will only use data centers that are physically located within Turkey to decrypt and service HTTPS traffic.” Ama Access bu bölgeyi kullanamıyor.

Zero Trust dokümantasyonunda Türkiye hiç geçmiyor. 8,4 MB’lık Cloudflare One doküman gövdesinde Turkey, Türkiye, Turkish, Istanbul, KVKK ve kişisel kelimelerinin tamamı sıfır eşleşme veriyor. Pozitif kontrol aynı gövdede: Germany 16, United States 21, India 17, Japan 9, France 7. Ülke adları orada ve aranabiliyor — Türkiye yok.

Gateway tarafında bölge kısmen mümkün, Access’te değil. Karşılaştırma için: Gateway’in HTTPS filtrelemesi Turkey bölgesine sabitlenebiliyor, ama “Gateway DNS (domain name filtering) cannot be regionalized using Regional Services” ve bu bile yalnızca Cloudflare One Client’ın Traffic and DNS modundaki trafiği için geçerli. Ayrıntı Gateway sayfasında.

KVKK. Cloudflare’in KVKK ile ilgili yayımlanmış tek bir sayfası yok. Trust Hub’ın hukuk rejimi dizininde sekiz jurisdiction var — GDPR, Brezilya LGPD, Japonya APPI, Singapur PDPA, Güney Kore PIPA, Hindistan IT Act, Avustralya Privacy Act, ABD — Türkiye yok. Bu, “0 eşleşme”dan daha güçlü bir kanıt: listenin kendisi var, sekiz komşusu var, Türkiye içinde değil.

Panel Türkçe değil. Resmî dil listesi on dil içeriyor ve Türkçe yok: Almanca, İngilizce, İspanyolca, Fransızca, İtalyanca, Japonca, Korece, Portekizce, Basitleştirilmiş ve Geleneksel Çince.

Sık yapılan hatalar

Origin’de JWT doğrulamamak

Access atlanabilir hâle geliyor. Tunnel kullanmıyorsan doğrulama zorunlu, ve başlığın varlığını kontrol etmek yetmiyor — imza doğrulanmalı.

public_cert değerini önbelleğe almak

Anahtar altı haftada bir dönüyor. kid eşleştirmesi yap; eski anahtar rotasyondan sonra yalnızca 7 gün geçerli kalıyor.

Require ile VEYA yazmaya çalışmak

Herkesi kilitliyor ve hata mesajı sebebi söylemiyor. VEYA anlamı için rule group kullan.

Bypass’ı hızlı çözüm olarak kullanmak

Hiçbir kontrol uygulanmıyor ve hiçbir şey loglanmıyor. Kimlik gerekmeyen ama denetlenmesi gereken erişim için Service Auth var.

groups claim’ine güvenmek

1 KB sınırında sondan başlayarak kırpılıyor. Çok gruba üye bir kullanıcı, aynı uygulamadaki başka bir kullanıcıdan farklı bir token alabiliyor.

SameSite=Strict bırakmak

ERR_TOO_MANY_REDIRECTS üretiyor. None veya Lax kullan.

Binding cookie’yi Zaraz veya Worker’lı bir zone’da açmak

Yönlendirme döngüsü oluşuyor. SSH/RDP gibi tarayıcı dışı erişimlerde de açma.

Require WARP ile kurumsal cihaz kontrolü yaptığını sanmak

Tüketici WARP’ı da geçiyor. Require Gateway kullan.

Cihaz duruşunun anında etkili olacağını beklemek

Gateway’de toplam gecikme 15 dakikaya kadar çıkabiliyor, ve aktif oturum duruş bozulsa bile sonlandırılmıyor.

Özel IP uygulamasında virgüllü port listesi yazmak

“Comma-separated lists of ports (such as 80, 443) are not supported.” Aynı IP’yi iki kez ekle.

SaaS uygulamasında oturum süresi kontrol ettiğini sanmak

“Application session durations only control the front door to a SaaS app; Access does not control how long the user can stay in the SaaS app itself.”