SaaS'ta Müşteri Alan Adı Desteği: Sahiplik Doğrulama, CNAME Hedefi ve TLS Tuzakları

Bir SaaS ürününü müşterinin kendi alan adından sunmak, yani portal.musteri.com adresinin sizin uygulamanıza gelmesi, ilk bakışta bir CNAME kaydından ibaret görünür. Değildir. Aynı istekte üç ayrı problem çözülür: gelen isteğin hangi kiracıya ait olduğunu bulmak, o alan adının gerçekten o müşteriye ait olduğunu kanıtlamak ve tarayıcının kabul edeceği bir TLS sertifikası sunmak. Üçünden biri gevşek kurulursa sonuç ya kesinti ya da bir kiracının başka kiracının trafiğini üstlenmesidir. Bu yazı üç problemi sırayla ele alır ve her birinde nerede tökezlendiğini anlatır.

Yönlendirme: müşteri kaydı nereyi göstermeli

Müşteriye verilecek CNAME hedefi için iki seçenek var. Ortak bir hedef (custom.example.net) ya da kiracıya özel bir hedef (t-4f9a2c.connect.example.net). Ortak hedef kolay anlatılır ama ikinci seçenek daha iyidir, çünkü hedefin kendisi aynı zamanda bir sahiplik kanıtıdır: rastgele üretilmiş bir hedefe yalnızca o kiracının paneline giren biri yönlendirebilir. Ayrıca müşteri ayrıldığında hedefi silmek, adresi artık çözümlenmez hâle getirir ve başka kiracının aynı adı sahiplenmesini engeller.

Apex alan adı (musteri.com, önünde alt ad olmadan) ayrı bir derttir. DNS standardı apex'te CNAME kaydına izin vermez; müşterinin sağlayıcısı ALIAS ya da ANAME benzeri bir kayıt sunmuyorsa tek yol sabit bir IP adresine A kaydıdır. O IP'yi bir kez verdiğinizde yıllarca değiştiremezsiniz. En sağlıklı karar, dokümanda apex yerine bir alt ad (portal.musteri.com gibi) istemek ve apex'i yalnızca gerçekten gerektiğinde, anycast ya da uzun ömürlü bir IP ile kabul etmektir.

Uygulama tarafında yönlendirme bir tablodur: alan_adi -> kiraci. Tabloda olmayan bir Host başlığı için istek varsayılan kiracıya düşmemeli, açıkça 404 dönmelidir. Bilinmeyen adı bir kiracıya bağlamak, hem tarayıcıda yanlış marka göstermek hem de aşağıda anlatılan takeover senaryosunu kolaylaştırmak demektir.

Sahiplik kanıtı: hangi yöntem neyi kanıtlar

Üç yaygın yöntem var ve gücü eşit değil.

HTTP dosyası. Müşteri, alan adının belirli bir yoluna sizin verdiğiniz içeriği koyar. Zayıf yöntemdir, çünkü alan adı zaten size yönlendirildiyse o yolu siz sunuyorsunuzdur; kanıtlaması gereken kişi hiçbir şey yapmadan geçer. Sertifika kuruluşlarının HTTP-01 doğrulaması için bu sorun olmaz, ama kiracı sahipliği için işe yaramaz.

TXT kaydı. Müşteri, _saas-verify.portal.musteri.com gibi bir ada, kiracıya özel rastgele bir değer yazar. DNS'i kontrol eden kişi bunu yapabilir, yönlendirilen trafiği alan kişi yapamaz. Doğru kanıt budur. Kontrolü kendi sunucunuzun önbelleğinden değil, alan adının yetkili sunucularına sorarak yapın; aksi hâlde müşteri kaydı düzelttiğinde saatlerce "doğrulanmadı" görür.

Kiracıya özel CNAME hedefi. Yukarıda anlatıldığı gibi, hedefin tahmin edilemez olması tek başına bir kanıttır. TXT ile birlikte kullanıldığında en az sürtünmeli akıştır: müşteri tek bir kaydı ekler, sistem hem yönlendirmeyi hem sahipliği aynı anda görür.

Bir kanıt tasarlarken sorulacak tek soru şudur: "bu kanıt, kanıtlaması gereken kişi hiçbir şey yapmadan geçer mi?" Bu soruyu atlayan bir yöntem yaygındır: ad sunucuları bizim mi diye bakmak. Alan adı sizin platform bölgenizin altındaysa (örneğin x.app.example.net), ad sunucuları yapı gereği sizindir ve kontrol her ada "doğrulandı" der. Sonuç, bir kiracının başka kiracının alt adını ekleyip anında doğrulanmasıdır. Kendi bölgenizin altındaki adları müşteri alan adı olarak hiç kabul etmeyin ve son ek karşılaştırmasını noktayla yapın: app.example.net ile biten her şeyi reddeden bir kural, kotu-app.example.net gibi bambaşka bir alan adını da reddeder, .app.example.net ile biten kural doğru olandır.

Kanıt bir kez alınıp unutulmamalı. Müşteri alan adını başkasına devredebilir ya da kaydı silebilir. Günlük ya da haftalık bir yeniden doğrulama, başarısız olursa önce uyarı, belli bir süre sonra pasifleştirme, tabloyu temiz tutar.

TLS: sertifikayı kim, nasıl alır

Müşterinin alan adı için sertifikayı siz alırsınız ve elinizde tek seçenek HTTP-01'dir. DNS-01 müşterinin DNS'ine yazmayı gerektirir, bu sizde yoktur. HTTP-01 ise trafik zaten size geldiği için doğal olarak çalışır; tek şart 80 portunun açık olması ve /.well-known/acme-challenge/ yolunun HTTPS'e yönlendirilmeden cevaplanmasıdır. Genel bir "her şeyi HTTPS'e yönlendir" kuralı bu yolu da yönlendirirse doğrulama sessizce düşer.

Kubernetes'te cert-manager ile bu iş bir Ingress açıklamasına iner:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tenant-4f9a2c-custom
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
    - hosts:
        - portal.musteri.com
      secretName: tenant-4f9a2c-portal-musteri-com-tls
  rules:
    - host: portal.musteri.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app
                port:
                  number: 8080

Kubernetes dışında Caddy'nin isteğe bağlı TLS özelliği aynı işi tek başına yapar. Sertifika ilk TLS el sıkışmasında alınır; hangi adlar için alınacağına bir HTTP ucuyla siz karar verirsiniz:

{
  on_demand_tls {
    ask http://127.0.0.1:5555/allowed
  }
}

https:// {
  tls {
    on_demand
  }
  reverse_proxy app:8080
}

ask ucunu boş bırakmayın. O uç "bu alan adı doğrulanmış bir kiracıya mı ait" sorusuna 200 ya da 403 döner; olmadan sunucunuza SNI ile gelen her ad için sertifika istenir ve hem kota hem disk dolar.

Kota konusunda iyi haber, sertifika kuruluşlarının haftalık sınırlarının müşterinin kayıtlı alan adına göre sayılmasıdır; yüz müşteri sizin kotanızı yemez. Kötü haber, aynı ad için tekrar tekrar sertifika istemenin ayrı bir sınırı olmasıdır. Sertifika durumunu dayanıklı bir yerde saklamayan bir kurulum, her yeniden başlatmada aynı adı yeniden ister ve birkaç dağıtımdan sonra o müşteri günlerce sertifikasız kalır.

Tuzaklar

CAA kaydı. Müşterinin alan adında yalnızca belirli bir kuruluşa izin veren bir CAA kaydı varsa sizin kuruluşunuz sertifika veremez ve hata mesajı bunu açıkça söylemez. Onboarding akışında CAA kaydını sorgulayıp müşteriye erken söylemek, destek biletini önlemenin tek yoludur.

Müşterinin önünde proxy. Müşteri alan adını bir CDN'in arkasından yönlendiriyorsa kendi sertifikasını CDN sunar, sizinki kenar ile sizin aranızda kullanılır. Bu durumda HTTP-01 doğrulaması CDN'in HTTPS yönlendirmesine takılabilir. Dokümanda bu senaryoyu ayrı anlatın.

Sertifika hazır olmadan gelen istek. Yönlendirme geldi, sertifika henüz alınmadı. Sunucu varsayılan sertifikayı sunar, tarayıcı uyarı verir. Müşteriye "kaydı ekledikten sonra sertifika birkaç dakika içinde gelir" demek ve panelde durumu göstermek, "bozuk" algısını önler.

Çerez ve önbellek. Oturum çerezini kendi ana alan adınıza bağlı kuran bir uygulama müşteri alan adında oturum açamaz. Önbellek anahtarı Host başlığını içermiyorsa bir kiracının sayfası öbürüne sunulur. İkisi de yönlendirme çalıştıktan sonra, ilk gerçek kullanıcıda ortaya çıkar.

Ayrılan müşteri. Müşteri gidince tablodan satırı silmek yetmez; müşteri kendi DNS'indeki CNAME'i unutursa ad hâlâ size çözümlenir. Kiracıya özel hedef bu noktada kurtarır: hedef silinince çözümleme de biter. Ortak hedef kullanan bir sistemde ise başka bir kiracı aynı adı ekleyip, doğrulama gevşekse, eski müşterinin trafiğini alabilir.

Ne zaman bu yola girmemeli

Müşterinin istediği yalnızca markasını görmekse, musteri.app.example.net gibi bir alt ad ve tek bir joker sertifika bütün bu makineyi gereksiz kılar. Sahiplik doğrulaması yoktur, sertifika bir kez alınır, CAA ve CDN dertleri yaşanmaz. Özel alan adı desteği, kalıcı bir destek yükü getirir: DNS yayılımı, yanlış kayıt, süresi dolan alan adı. Bu yükü sözleşmede karşılığı olan planlara ayırmak, herkese açmaktan daha sürdürülebilirdir.