Series · 5 partsExternal Perimeter IntelligencePart 3 · You are here
- 1Dış Çevre İstihbarat Grafiği: Varlık İlişkilerini Haritalandırmak
- 2Domain Sahipliği ve Varlık Atıf Kanıtı: Dış Yüzeyde Yanılgılar
- 3Üretici Kapsam Dışıydı. Güven Sınırı Değildi: 3. Taraf EntegrasyonlarıYou are here
- 4Servis Gözlemlendi. Uygulama Hâlâ Bilinmiyordu: Dış Keşif
- 5Giriş Sayfası Kamusaldı. Kimlik Sınırı Başka Bir Yerdeydi
60 saniyede üçüncü taraf güveni
Modern bir uygulama nadiren kullanıcı yolculuğunun tamamına tek başına sahip olur. Bir kimlik sağlayıcı (IdP) kullanıcının kimliğini doğrular. Bir ödeme platformu olaylar (events) gönderir. Bir destek sistemi görüşmeleri saklar. Bir CDN trafiği sonlandırır. Nesne depolama (object storage) dosyaları sunar. Analitik ve hata telemetrisi sistemleri uygulama verilerini alır.
Bu sağlayıcılar mimarinin birer parçasıdır ancak otomatik olarak sızma testi kapsamının (scope) bir parçası değildir. Yararlı soru “üreticiyi test edebilir miyiz?” sorusu değildir. Asıl soru şudur:
Bir sağlayıcı mesajını, kimliğini, hostname’ini, dosyasını veya olayını güvenilen bir uygulama durumuna (application state) dönüştüren müşteri kontrollü hangi karardır?
Bu karar müşterinin callback handler’ında, kiracı (tenant) yapılandırmasında, DNS kayıtlarında, rol eşleşmesinde, webhook doğrulayıcısında, önbellek (cache) kuralında, origin politikasında veya destek iş akışında yaşayabilir. Sağlayıcı platform kesin olarak kapsam dışı kalırken, müşteriye ait bu kontroller güvenli bir şekilde incelenebilir.
Ayrım şudur:
- sağlayıcıyı mimari bir bağımlılık olarak haritalandırın;
- entegrasyon sınırındaki güven sözleşmesini (trust contract) tanımlayın;
- müşteri kontrollü taraf için yazılı onay alın;
- sağlayıcı altyapısını yoklamadan mümkün olan en küçük anlamlı davranışı test edin;
- sağlayıcı gözlemlerini değerlendirme yetkiniz olmayan bir sisteme yönelik bulgular olarak değil, bağlam olarak raporlayın.
“Üçüncü taraf” demek “ilgisiz” demek değildir. Bu durum, testin daha iyi bir sınır modeline ihtiyaç duyduğu anlamına gelir.
Tek bir entegrasyonu üç kontrol düzlemine ayırın
Bir mimari diyagramında tek bir kutu gibi görünen bir entegrasyon, genellikle birbirinden çok farklı üç kontrol düzlemi (control plane) barındırır:
Sağlayıcı platformu (Provider platform). Çok kiracılı (multi-tenant) servis, bunun kontrol düzlemi, çalışanları, ağ aralıkları, diğer kiracılar, global API’ler ve sağlayıcıya ait kimlik yapısı. Sağlayıcının kendisi açık bir izin vermediği sürece bu genellikle kapsam dışıdır.
Müşteri kiracısı ve yapılandırması (Customer tenant and configuration). Redirect URI kayıtları, SSO bağlantıları, imzalama gizli anahtarları (signing secrets), webhook hedefleri, özel hostname’ler (custom hostnames), origin eşlemeleri, depolama politikaları, destek rolleri ve veri saklama (data-retention) ayarları. Sağlayıcı bunları barındırsa bile müşteri bu tercihlerin sahibi olabilir veya bunları yönetebilir. Test, yine de Test Kurallarının (Rules of Engagement) kiracıyı, izin verilen hesapları, eylemleri ve durma koşullarını açıkça belirtmesini gerektirir.
Müşteri uygulamasının güven kararı (Customer application trust decision). Sağlayıcının çıktısını tüketen kod ve politika: hangi issuer kabul edilir, hangi olay bir siparişi değiştirir, hangi hostname bir origin’e ulaşır, hangi destek rolü bir kullanıcının kimliğine bürünebilir (impersonate) veya hangi nesne herkese açık hale gelir. Burası genellikle test edilmesi en değerli ve en az belirsiz olan yerdir.
Bu ayrım iki zıt hatayı önler. Güvensiz olan hata, bir tedarikçiyi keşfedip adreslerini taramaya veya genel oturum açma sayfasını test etmeye başlamaktır. Eksik olan hata ise entegrasyonun tamamını “kapsam dışı” olarak etiketleyip müşterinin kabul mantığını tamamen görmezden gelmektir. İyi bir metodoloji her ikisinden de kaçınır.
Tedarikçi listesi değil, bir güven sınırı envanteri oluşturun
Marka adlarından oluşan bir liste —Okta, Stripe, Cloudflare, Zendesk, Sentry— riski tek başına tarif etmez. İlişkiyi bir nesneye ve bir kabul kuralına sahip yönlendirilmiş bir akış olarak kaydedin:
| Güven düzlemi | Gelen nesne veya sinyal | Müşteri kontrollü karar |
|---|---|---|
| Kimlik (Identity) | Kod, token, assertion, claim’ler | Hangi issuer, audience, kiracı, subject ve rol kabul edilir? |
| Olaylar ve webhook’lar | İmzalı istek, olay ID, payload | Otantik, güncel, benzersiz, beklenen ve işlenmesi güvenli mi? |
| Özel domain ve edge | Hostname, TLS isteği, cache key | İsim hangi kiracıyı ve origin’i seçer? |
| Depolama ve dağıtım | Dosya, URL, metadata, content-type | Nesneyi kim yayımlayabilir, çekebilir, değiştirebilir veya dönüştürebilir? |
| Destek ve operasyon | Talep (ticket), rol, kimliğe bürünme eylemi | Hangi destek eylemi müşteri veya yönetici durumuna geçiş yapar? |
| Analitik ve telemetri | Tanımlayıcı, olay, hata bağlamı | Hangi veriler dışarı çıkar, nasıl sınırlandırılır ve bunları kim sorgulayabilir? |
Her akış için sağlayıcıyı, müşteri kiracı tanımlayıcısını, müşteri endpoint’ini, veri sınıfını, yönü, kimlik doğrulama mekanizmasını, yetkilendirme kuralını, replay davranışını, durum değişikliğini, sahibini, kapsam durumunu ve kanıtı kaydedin. Bu alanlardan biri bilinmiyorsa, bu bir sorudur —aktif testlerle tahmin yürütme izni değildir.
Envanter, keşif kanıtını doğrulama kanıtından da ayırmalıdır. Bir CNAME, JavaScript SDK, yanıt header’ı, gizlilik politikası alt işlemcisi veya oturum açma yönlendirmesi, bir ilişkinin muhtemelen var olduğunu ortaya koyabilir. Ancak entegrasyonun dahili olarak nasıl yapılandırıldığını kanıtlayamaz veya onun test edilmesini yetkilendiremez.
Kimlik: Kimlik sağlayıcıyı değil, teslimatı (handoff) test edin
Federated oturum açma iki güvenlik sınırı yaratır. Sağlayıcı kullanıcı hakkında bir şey kanıtlar; müşteri uygulaması ise bu kanıtın yerel olarak ne anlama geldiğine karar verir. İkinci sınır, küçük bir yapılandırma hatasının bir müşteri hesabına veya rolüne dönüşebileceği yerdir.
Onaylanmış test hesaplarıyla normal yolculuğu haritalandırarak başlayın: uygulama girişi, yetkilendirme isteği, sağlayıcı doğrulaması, callback, token değişimi, yerel oturum oluşturma, rol eşleme, çıkış yapma ve yeniden doğrulama. Gerçek kullanıcı token’larını toplamadan veya diğer kiracıları test etmeden domain’leri ve parametreleri kaydedin.
Doğrulama soruları kesindir:
- İstemci yalnızca beklenen issuer ve yetkilendirme sunucusunu mu kabul ediyor?
- Token bu istemci ve kaynak audience için mi hedeflenmiş?
- Callback URI kayıtlı hedefle tam olarak eşleşiyor mu?
state,nonceve PKCE uygulanabildiği yerlerde başlatan tarayıcı işlemine bağlı mı?- Yanlış organizasyon veya kiracıdan gelen bir kimlik yerel bir kullanıcıya dönüşebilir mi?
- Grup, e-posta domain’i veya rol claim’leri yalnızca açık bir harita üzerinden mi ayrıcalıklara dönüştürülüyor?
- Devre dışı bırakılmış veya yetkisi düşürülmüş bir sağlayıcı kimliği bir müşteri oturumunu veya yerel rolü korumaya devam ediyor mu?
OpenID Connect Core; issuer, audience, imza, nonce ve kayıtlı redirect URI’leri etrafındaki doğrulama gereksinimlerini tanımlar. Güncel OAuth 2.0 Security Best Current Practice genel durumda tam yönlendirme eşleşmesini zorunlu tutar, PKCE gibi yetkilendirme kodu korumalarını önerir ve mix-up ile token replay’e karşı issuer ve audience savunmalarını açıklar.
Bu şartnameler “SSO testini” gözlemlenebilir sözleşmelere dönüştürür. Sağlayıcı tarafından barındırılan bir giriş sayfası hedef değildir. Hedef, onaylanmış müşteri uygulamasının belirli bir sağlayıcı yanıtını yerel bir kimlik ve yetkiyle takas etme kararıdır.
Güvenli bir negatif test, değerlendirme için oluşturulmuş hesapları, istemcileri ve kiracıları kullanır. Her seferinde beklenen tek bir özelliği değiştirir ve müşteri uygulamasının sonucu reddedip reddetmediğini gözlemler. Parola püskürtmez, benzer görünümlü kiracılar kaydetmez, sağlayıcı müşterilerini numaralandırmaz veya onaylanmış bir test iş akışının dışındaki sağlayıcı altyapısına payload göndermez.
Webhook’lar: Otantiklik yalnızca ilk kapıdır
Webhook güvenliği sıklıkla “imzayı doğrulamaya” indirgenir. Bu gereklidir, ancak geçerli bir imza yalnızca yapılandırılmış imzalama şemasının kapsadığı şeyleri kanıtlar. Alıcı uygulamanın yine de olayın güncel olup olmadığına, benzersiz olup olmadığına, bu endpoint için beklenip beklenmediğine, doğru müşteri nesnesiyle ilişkili olup olmadığına ve bu durum geçişini tetiklemesine izin verilip verilmediğine karar vermesi gerekir.
Eksiksiz bir kabul yolu şunları yanıtlamalıdır:
- Otantiklik (Authenticity): İstek beklenen endpoint gizli anahtarı veya doğrulama anahtarıyla mı imzalandı?
- Bütünlük (Integrity): Metot, hedef, gövde ve güvenlikle ilgili metadata kapsandı mı?
- Güncellik (Freshness): İmzalanmış oluşturulma zamanı açık bir kabul penceresi içinde mi?
- Benzersizlik (Uniqueness): Bu teslimat, olay veya nonce daha önce işlendi mi?
- Bağlam (Context): Olay beklenen kiracıya, hesaba, ortama ve nesneye mi ait?
- Durum (State): Bu olay nesnenin mevcut iş akışı durumundan geçerli bir geçiş mi?
- Etki (Effect): Yeniden denemeler (retries) veya yeniden sıralamalar para, erişim, bildirim veya kaynak sağlama işlemlerini yineleyebilir mi?
RFC 9421, uygulamaların yeniden oynatma (replay) savunmalarının bir parçası olarak kullanabileceği kapsanan bileşenler, oluşturma ve sona erme süreleri ve nonce’lar dahil olmak üzere HTTP mesaj imzalarını tanımlar. Sağlayıcıya özel şemalar farklılık gösterir. Örneğin, Stripe’ın webhook dokümantasyonu; endpoint’e özgü gizli anahtarları, imzalı zaman damgalarını, güncellik kontrollerini ve yeniden denemelerin meşru teslimatlar olduğu gerçeğini belgeler. Bu da “her yinelenen isteği reddet” yaklaşımının fazla basit olduğu anlamına gelir: Handler genellikle kriptografik doğrulamanın yanı sıra kalıcı olay idempotentliğine (idempotency) ihtiyaç duyar.
Bu noktayı kanıtlamak için asla gerçek bir üretim ödemesini veya abonelik olayını yeniden oynatmayın. Sağlayıcının test modunu, bir lab olayını veya müşteri tarafından sağlanan bir test fikstürünü (fixture) kullanın; iş durumunu değiştiren her test için açık onay alın. Test modu teslimatı bile kullanılamadığında, handler’ı ve yapılandırmayı inceleyin veya sonucu doğrulanmamış bir hipotezle sınırlayın.
Özel domain’ler, CDN’ler ve depolama: Tek bir URL’de iki sahip gizlenir
help.customer.example veya assets.customer.example gibi bir hostname bir tarayıcıya müşteri mülkü gibi görünürken, arkasındaki uygulama bir SaaS veya dağıtım platformunda çalıştırılıyor olabilir. DNS müşteriye isimlendirme yetkisi verir; sağlayıcı yapılandırması ise bu adı bir kiracıya, sertifikaya, origin’e veya depolama ad alanına (storage namespace) bağlar.
Cloudflare’in custom-hostname dokümantasyonu bu ayrımı açıklar: Bir SaaS sağlayıcısı müşteri hostname’lerini sisteme dahil edebilir ve bunlar için origin davranışını seçebilir. Bu nedenle güvenlik incelemesi, sağlayıcı edge noktasını müşteriye ait bir ağ gibi ele almadan hem müşterinin DNS kararını hem de sağlayıcı tarafındaki bağlamayı tanımlamalıdır.
Faydalı müşteri tarafı soruları şunları içerir:
- Eski bir CNAME kaydı, hizmetten çıkarılmış veya yanlış bağlanmış bir kiracıyı işaret edebilir mi?
- Sahiplik doğrulaması başka bir kiracının müşteri hostname’ini talep etmesini engelliyor mu?
- Beklenen hostname CDN üzerinden doğru origin’e kadar korunuyor mu?
- Bir host-header veya yönlendirme uyuşmazlığı başka bir uygulamayı veya geri dönüş (fallback) origin’ini seçebilir mi?
- Cache key’leri güvenlikle ilgili host, yetkilendirme, yerel ayar ve içerik varyantlarını içeriyor mu?
- Yüklenen bir nesne metadata, dönüştürme veya URL inşası yoluyla özelden (private) genele (public) dönüşebilir mi?
- İmzalı teslimat URL’leri hedeflenen nesneye, eyleme, kitleye ve kullanım ömrüne bağlı mı?
Onaylanan hostname’i ve yapılandırmasını gözlemleyin. Bir CNAME kaydını sağlayıcının IP aralıklarına doğru genişletmeyin, genel sağlayıcı endpoint’lerini fuzz etmeyin, kaynakları talep etmeye çalışmayın veya diğer kiracılarla etkileşime girmeyin. Askıda kalan bir bağlama (dangling-binding) hipotezi genellikle müşteri DNS’inden, sağlayıcı dokümantasyonundan ve yıkıcı olmayan bir hata durumundan kurulabilir. Kaynağı fiilen talep etmek trafiğin ele geçirilmesine yol açabilir ve istisnai yazılı onay ile bir çevreleme planı gerektirir.
Destek, analitik ve telemetri de birer yetkilendirme sınırıdır
Operasyonel SaaS platformlarını “düşük etkili” olarak göz ardı etmek kolaydır, ancak taşıdıkları güven genellikle daha küçük değil, sadece farklıdır.
Bir destek platformu; bir temsilcinin hesap verilerini görüntülemesine, MFA’yı sıfırlamasına, bir e-posta adresini değiştirmesine, kimlikleri birleştirmesine, bir yönetim eylemini tetiklemesine veya bir kullanıcının kimliğine bürünmesine (impersonate) izin verebilir. İlgili hedef, tedarikçinin ilgisiz kiracıları veya çalışanları değil; müşterinin rol modeli ve destek iş akışından ulaşılan uygulama eylemidir. Belirtilmiş destek rolleri ve sentetik kullanıcılarla test edin. Kimliğe bürünmeyi kimin onayladığını, bunun nasıl bildirildiğini, nelerin log’landığını ve hangi yüksek riskli eylemlerin kademeli doğrulama veya ikinci bir kişi gerektirdiğini kaydedin.
Analitik, sohbet, çökme raporlama ve gözlemlenebilirlik (observability) platformları; tarayıcılardan, uygulamalardan ve arka uç servislerinden veri alır. Sınırı nelerin aştığını haritalandırın: kullanıcı tanımlayıcıları, URL’ler, arama terimleri, header’lar, istek gövdeleri, yığın izleri (stack traces), oturum yeniden oynatmaları (session replays), token’lar ve kiracı ID’leri. Ardından müşterinin maskeleme (redaction), örnekleme, ortam ayrımı, erişim rolleri, saklama ve silme davranışını test edin. Gerçek kişileri aramayın veya ifşa olan çalışan bilgilerini bir hedefleme veri setine dönüştürmeyin.
Burası aynı zamanda mimari ile tedarik zinciri riskinin kesiştiği yerdir. NIST SP 800-161 Rev. 1; ürünleri, hizmetleri, bunların nasıl entegre edildiğini ve organizasyonun bu bağımlılıklara dair görünürlüğünü siber güvenlik tedarik zinciri risk yönetiminin bir parçası olarak ele alır. Bir sızma testi; tedarikçi durum tespitinin (due diligence), sözleşme incelemesinin, olay planlamasının veya sürekli güvencenin yerini alamaz. Riski iletme potansiyeli en yüksek olan müşteri kontrollü entegrasyon yolları hakkında somut kanıtlar sağlayabilir.
Kapsamı yürütülebilir sınırlara dönüştürün
“Üçüncü taraf sistemler kapsam dışıdır” ifadesi bir analiste rehberlik etmek için fazla belirsizdir. Bunu entegrasyona özgü bir matrisle değiştirin:
| Düzlem veya eylem | Varsayılan durum | Örnek onaylanmış doğrulama |
|---|---|---|
| Genel sağlayıcı dokümantasyonu ve metadata | Gözlemle | Mimariyi ve güvenlik sözleşmesi beklentilerini kaydetme |
| Müşteri hostname’i ve DNS | Karar gerekli | Tam olarak onaylanan ismi çözümleme ve inceleme |
| Müşteri callback veya webhook endpoint’i | Karar gerekli | Hız ve durum sınırları içinde bir test fikstürü (fixture) gönderme |
| Müşteri test kiracısı yapılandırması | Karar gerekli | Geri alma (rollback) imkanıyla yalnızca belirtilen ayarları inceleme veya değiştirme |
| Müşteri uygulaması kabul mantığı | Karar gerekli | Sentetik hesaplar veya olaylarla pozitif ve negatif test yapma |
| Sağlayıcının genel girişi, API’si, ağı veya admin arayüzü | Kapsam dışı | Onaylanan normal yolculuğun ötesinde doğrudan etkileşim yok |
| Diğer sağlayıcı kiracıları, kullanıcıları, çalışanları veya verileri | Yasak | Hiçbiri |
| Üretim ortamında finansal veya yıkıcı olay | Ayrı onay | Yalnızca yedekleme, geri alma, izleme ve acil durum irtibatı ile |
Test Kuralları; müşteri endpoint’ini, kiracıyı veya hesabı, test kimliklerini, olay fikstürlerini, kaynak IP adreslerini, zaman aralığını, maksimum istek hızını, izin verilen durum değişikliklerini, kapsam dışı sağlayıcı varlıklarını, kanıt yönetimini, geri alma sahibini ve acil durdurma koşullarını açıkça belirtmelidir. Değerlendirme, test trafiğini üretim trafiğinden ayıramayan bir sağlayıcı özelliğine dayanıyorsa, bu durum doğaçlama yapmak için bir neden değil, üst yönetime iletilmesi gereken bir kısıttır.
Kurgusal bir sınırlandırılmış değerlendirme
Meridian’ın federe kimlik için login.meridian.example kullandığını, faturalandırma olaylarını api.meridian.example/billing/events adresinden aldığını ve müşteri raporlarını files.meridian.example üzerinden sunduğunu varsayalım. Kamuya açık sinyaller üç farklı sağlayıcının sürece dahil olduğunu göstermektedir.
- Analist kimlik doğrulaması yapmadan veya durumu değiştirmeden yönlendirmeleri, CNAME kayıtlarını, script referanslarını ve müşteri endpoint’lerini haritalandırır. Sağlayıcılar mimari grafiğine bağımlılık olarak girer ve hepsi doğrudan test için
excludedolarak işaretlenir. - Müşteri bir izole kimlik test kiracısını, bir sağlayıcı sandbox’ını, iki sentetik kullanıcıyı ve üretim dışı bir depolama ad alanını onaylar. Tam callback’ler ve hostname’ler onaylanır; bu kiracı ayarları dışındaki sağlayıcı yönetimi kapsam dışı kalır.
- Normal kimlik yolculuğunda uygulama beklenen düşük ayrıcalıklı hesabı oluşturur. Bir negatif senaryo, geçerli bir sağlayıcı yanıtını korurken test kiracısı bağlamını değiştirir. Uygulama, yerel oturum oluşturulmadan önce bunu reddeder. Kanıt; issuer, audience, kiracı, callback, test kimliği ve durum değişikliği olmamasını kaydeder.
- Sandbox imzalı bir faturalandırma olayı yayar. Handler bunu doğrular ve sentetik bir faturayı bir kez değiştirir. Sağlayıcı tarafından oluşturulan bir yeniden deneme başarılı döner ancak geçişi yinelemez. Süresi dolmuş bir değerlendirme fikstürü reddedilir. Hiçbir gerçek ödeme olayı yeniden oynatılmaz.
- Onaylanan dosya hostname’i dağıtım sağlayıcısı üzerinden çözümlenir. Testler, özel bir nesnenin amaçlanan kısa ömürlü yetkilendirme olmadan çekilemeyeceğini ve hostname’i değiştirmenin bir geri dönüş kiracısını veya origin’ini seçmediğini doğrular. Sağlayıcının edge IP aralığı asla taranmaz.
- Rapor her müşteri kontrolünü, test fikstürünü, beklenen ve gözlemlenen davranışı, artık belirsizliği ve test edilmeden kalan sağlayıcı düzlemini açıklar.
Bu değerlendirmedeki hiçbir şey sağlayıcıların kendilerinin güvenli olduğunu kanıtlamaz. Seçilen müşteri kontrollü güven kararlarının onaylanan senaryolar altında doğru davrandığını kanıtlar. Bu sınırlama bir dipnotta değil, sonucun bizzat içinde yer almalıdır.
Kanıt matrisi (Evidence matrix)
| Gözlem veya test | Neyi destekler | Neyi kanıtlayamaz | Sonraki karar |
|---|---|---|---|
| CNAME, SDK, header, yönlendirme veya gizlilik bildirimi | Bir sağlayıcı ilişkisinin muhtemelen var olduğunu | Kiracı mülkiyetini, yapılandırmayı, zafiyeti veya kapsamı | Kesin akışı doğrulayın ve kontrolün kimde olduğunu sorun |
| Sağlayıcı dokümantasyonu bir güvenlik mekanizmasını açıklar | Kullanılabilir sözleşmeyi ve beklenen kontrolü | Müşterinin bunu doğru şekilde etkinleştirdiğini veya uyguladığını | Müşteri yapılandırmasını veya kabul davranışını inceleyin |
| Onaylanmış normal kimlik yolculuğu başarılı olur | Beklenen sağlayıcı-uygulama yolunun işlevsel olduğunu | Yanlış issuer, audience, kiracı veya claim’lerin reddedildiğini | İlgili her sözleşme için sınırlandırılmış bir negatif senaryo çalıştırın |
| Geçersiz webhook imzası reddedilir | Bir otantiklik başarısızlığının ele alındığını | Replay güvenliğini, idempotentliği, olay bağlamını veya durum sırasını | Süre, kopya, bağlam ve iş akışı kontrollerini test edin |
| İmzalı yeniden deneme hiçbir mükerrer durum değişikliğine yol açmaz | O sentetik olay için handler idempotentliğini | Tüm olay türlerini veya eşzamanlı teslimat davranışını | Test edilen olayı belirtin ve eşzamanlılık sınırlarını koruyun |
| Müşteri hostname’i beklenen uygulamaya ulaşır | O gözlem için güncel isim-kiracı yönlendirmesini | Münhasır bağlamayı veya güvenli hizmetten çıkarmayı | Mülkiyet kanıtını ve yaşam döngüsü yapılandırmasını inceleyin |
| Özel nesne süresi dolmuş test URL’sini reddeder | Bir teslimat yetkilendirme koşulunun uygulandığını | Yükleme politikasını, önbellek izolasyonunu veya kiracılar arası davranışı | Yayımlama, dönüştürme, önbelleğe alma ve çekme kararlarını haritalandırın |
| Destek rolü ayrıcalıklı bir test eylemini gerçekleştiremez | Bu rol sınırının söz konusu sentetik hesap için korunduğunu | Sağlayıcı genelindeki RBAC’ı veya her destek iş akışını | Yalnızca müşteri onaylı rol ve eylem haritası üzerinden genişletin |
Kanıtlar kiracıyı, ortamı, hesabı, endpoint’i, sağlayıcı modunu, istek veya yapılandırma referansını, zaman damgasını, beklenen etkiyi, gözlemlenen etkiyi, temizliği (cleanup) ve kalan belirsizliği korumalıdır. Bu bağlantılara sahip olmayan ekran görüntüleri zayıftır çünkü nadiren gerçekte hangi düzlemin test edildiğini gösterirler.
Müşterinin alması gerekenler
Nihai çıktı entegrasyonu yalnızca endişe verici değil, işletilebilir hale getirmelidir:
Bağımlılık haritası (Dependency map). Sağlayıcılar, müşteri hostname’leri, kiracı tanımlayıcıları, akışlar, veri sınıfları, iş birimi sahipleri ve gözlem zamanları.
Güven sözleşmesi defteri (Trust contract ledger). Her kimlik, olay, veri, teslimat ve destek aktarımı için: kabul edilen nesne, doğrulama kuralı, yetkilendirme kuralı, yeniden oynatma kuralı, durum geçişi ve hata davranışı.
Kapsam matrisi (Scope matrix). Kapsam dışı kalan sağlayıcı varlıklarının yanında, tam olarak onaylanan müşteri kiracısı, uygulama endpoint’i, test hesabı, fikstür ve eylem.
Kanıt paketi (Evidence packet). Minimal pozitif ve negatif senaryo, beklenen ile gözlemlenen etkinin karşılaştırması, zaman damgaları, temizlik ve tekrarlanabilir yeniden test talimatları. Gizli anahtarlar ve canlı müşteri verileri bu pakette yer almaz.
Sahiplik teslimi (Ownership handoff). Kimlik mühendisliği claim ve rol eşlemelerinin sahibidir. Uygulama ekipleri callback ve durum geçişi mantığının sahibidir. Platform ekipleri DNS, edge, origin, önbellek ve depolama bağlamalarının sahibidir. Destek ve gizlilik ekipleri operasyonel erişim ve veri yönetiminin sahibidir. Satın alma ve risk ekipleri bir sızma testinin tespit edemeyeceği sağlayıcı güvencesinin sahibidir.
Raporun merkezindeki cümle dürüst kalmalıdır:
Sağlayıcı platformunu test etmedik. Onaylanan kiracı, endpoint, fikstür ve durum geçişi üzerinden müşteri kontrollü güven kararını test ettik.
Bu cümle metodolojinin bir sınırlılığı değildir. Metodolojinin yetkinin nerede bittiğini bildiğinin kanıtıdır.
Bir sonraki makale pasif bir platformun canlı bir servisi ortaya çıkarmasından sonra ne olduğunu takip etmektedir: servis gözlemlenmişti, ancak uygulama —ve neden önemli olduğu— hâlâ bilinmiyordu.
Bu teknik not ne kadar güncel?
En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.
Birincil kamu kayıtları kontrol edildi. Ortama özgü davranış, ayrıca yeniden üretilmedikçe iddianın dışındadır.