Ekip tarayıcısı nasıl değerlendirilir? Pratik kontrol listesi

Fiyatlandırma sayfasını açmadan önce kararı tanımlayın

Yararlı değerlendirme sağlayıcı listesinden değil, işten başlar. Şunları yazın:

• yetkili iş akışları ve bunlara izin veren sistemler;
• kişi, kayıtlı profil, eş zamanlanan profil ve aynı anda açık tarayıcı oturumu sayıları;
• desteklenen işletim sistemleri ve işlemci mimarileri;
• gereken tarayıcı motorları, uzantılar, proxy’ler, kimlik sağlayıcıları ve otomasyon istemcileri;
• veri konumu, saklama, dışa aktarma, silme ve denetim yükümlülükleri;
• kurtarma süresi ve kabul edilebilir veri kaybı beklentileri;
• kullanıcı ve yöneticilerin erişilebilirlik ihtiyaçları;
• bütçe, fatura dönemi, destek kapsamı ve hizmetten ayrılma koşulları;
• ürünün ekibiniz için mümkün kılmaması gereken yasak iş akışları.

Kaynak türlerini ayrı tutun. 500 kayıtlı profil, 100 bulutla eş zamanlanan profil, beş kullanıcı ve on eş zamanlı oturum içeren paket, 500 eş zamanlı ekip oturumu sağlamaz. Her sınırı iş akışınızın tükettiği birime çevirin.

Ardından vazgeçilmez kabul koşullarını belirleyin. Yaygın bir küme şudur:

1. Desteklenen, güncel tarayıcı derlemeleri.
2. Sessiz profil bozulması veya eş zamanlı yazıcı olmaması.
3. İptal edilebilir, en az yetkili erişimi olan bireysel kimlikler.
4. Normal günlüklerde veya otomasyon çıktısında ham sır bulunmaması.
5. Kullanılabilir denetim kanıtı.
6. Test edilmiş geri yükleme ve ayrılma yolu.
7. Geçerli hizmet koşullarıyla uyumlu, yasal ve yetkili kullanım.

Başarısız kabul koşulunu sayısal ortalamada eritmeyin. Şık arayüz, doğrulanmamış güncelleyiciyi veya durum kaybeden geri yüklemeyi telafi edemez.

Basit kanıt ölçeği kullanın

Her madde için hem sonucu hem elde edilen en güçlü kanıtı kaydedin.

Sonuç

• Geçti: Belirtilen gereksinim tanımlı test ortamında gösterildi.
• Kaygı var: Davranış gereksinimle çatışıyor veya önemli bir karşılık yaratıyor.
• Doğrulanmadı: Kanıt eksik, erişilemez, eski veya karar için fazla belirsiz.
• Uygulanamaz: Gereksinim bu iş akışına gerçekten uygulanmıyor; nedeni kaydedildi.

Kanıt

1. Yayımlanmış iddia: Pazarlama veya satış metni.
2. Teknik belge: Sürümlenmiş ürün, güvenlik, API veya destek belgesi.
3. Gözlemlenen gösterim: Sağlayıcının sizin senaryonuzla canlı gösterimi.
4. Kontrollü deneme: Ekibiniz geçici verilerle davranışı yeniden üretir, sürümleri ve sonuçları kaydeder.
5. Bağımsız veya sözleşmesel kanıt: Gereksinimi kapsayan sınırlı değerlendirme, imzalı taahhüt veya destek koşulu.

Daha üst kanıt her durumda daha iyi değildir. Bağımsız rapor masaüstü tarayıcısını dışarıda bırakırken kontrollü deneme doğrudan sınayabilir. Her çıktı için kapsamı, tarihi, sürümü ve sınırları kaydedin.

1. Ürün durumu ve iddia sınırları

• □ Gereken her platform ve mimari için gerçek, kurulabilir derleme var mı?
• □ Sağlayıcı güncel uygulama sürümünü, tarayıcı sürümünü ve yayın tarihini belirtebiliyor mu?
• □ Beta, önizleme, deneysel ve genel kullanıma açık özellikler ayrı işaretlenmiş mi?
• □ Belgeler ve gerçek deneme sınırlar ile davranış konusunda uyuşuyor mu?
• □ Güvenlik, kullanılabilirlik, şifreleme ve performans iddiaları belirli bileşenlere ve kanıtlara bağlanmış mı?
• □ Bilinen sınırlar, desteklenmeyen akışlar ve destek sonu kuralları yayımlanmış mı?
• □ Sağlayıcı görünmezlik, hesapların açık kalması veya üçüncü taraf hizmetlere erişim garantilerinden kaçınıyor mu?

Değerlendirme tarihinde yükleyiciyi, sürüm ekranını, sürüm notlarını ve ilgili belgeleri kaydedin. Sabit referansı olmayan satış yanıtı, doğrulanmış davranış değil yayımlanmış iddia olarak kalır.

2. Profil yalıtımı ve bütünlüğü

Önce ürünün profil dediği şeyi tanımlayın. Kalıcı tarayıcı veri dizini, geçici tarayıcı bağlamı, eş zamanlanan arşiv, uzak oturum veya ayar kümesi olabilir. Bunlar eşdeğer değildir.

Chromium, kullanıcı veri dizinini kullanıcı verilerinin yeri olarak belgeler ve özel dizinin nasıl seçilebildiğini açıklar. İki çalışan örneğin aynı dizini paylaşamadığı durumları da belirtir. Chromium kullanıcı veri dizini belgelerini başlangıç alın; sonra ürüne özel kanıt isteyin.

• □ Her kalıcı profilin açık depolama ve süreç sınırı var mı?
• □ Ürün aynı değiştirilebilir profil durumunu iki yazıcının açmasını önlüyor mu?
• □ Çerezler, depolama, önbellek, geçmiş, uzantılar, indirilenler, izinler ve tercihler belgelendiği gibi ayrılıyor mu?
• □ Geçici oturumlar ve kalıcı profiller farklı adlandırılıyor mu?
• □ Temiz başlatma yalnızca hedeflenen profil verisini kullanıyor mu?
• □ Yeniden başlatma, ürünün korumayı vaat ettiği durumu tam olarak koruyor mu?
• □ Uzantı izinleri ve kurulum kaynakları kontrol ediliyor mu?
• □ İçe aktarılan profiller güvenilmeyen girdi sayılıp kullanımdan önce doğrulanıyor mu?
• □ Hasarlı veya uyumsuz profil, çalıştığı bilinen kopyanın üzerine yazılmadan karantinaya alınabiliyor mu?

Deneme kanıtı profiller arası testleri içermeli. A profilinde zararsız işaret oluşturun, B’de bulunmadığını doğrulayın, ikisini yeniden başlatın ve uygulama güncellemesinden sonra tekrarlayın. Geçici hesaplar ve sentetik veriler kullanın.

3. Tarayıcı güncelliği, korumalı alan ve güncellemeler

Tarayıcı, güvenlik açısından kritik ve sürekli bakım gerektiren bir bileşendir. Chrome, 8 Eylül 2026’da Chrome 153 ile Stable sürümlerini iki haftada bir yayımlamaya başladı. Bu yayın takvimi, her sağlayıcının hizmet taahhüdünü birebir belirlemez; ancak sürüm ve güncelleme kanıtları olmadan “Chromium tabanlı” demenin neden yeterli olmadığını gösterir.

• □ Ürünün tarayıcı derlemesini tam kaynak sürümle eşleştirebiliyor musunuz?
• □ Kaynak güvenlik güncellemelerini alma konusunda yayımlanmış hedef veya geçmiş var mı?
• □ Kaynak yayınları ve acil düzeltmeleri kim izliyor?
• □ Uygulama ve tarayıcı güncellemeleri indirme bağlantısından bağımsız imzalanıp doğrulanıyor mu?
• □ Dosya özetleri, sürümün üretim kaydı veya eşdeğer gözetim zinciri doğrulanabiliyor mu?
• □ Dağıtımlar aşamalı, izlenen ve durdurulabilir mi?
• □ Geri dönüş, güncel güvenlik politikasına göre güvensiz sürümü geri getirmekten kaçınıyor mu?
• □ Profil şeması geçişleri desteklenen yükseltme ve düşürme yollarında test ediliyor mu?
• □ Normal kullanımda tarayıcı korumalı alanı etkin kalıyor mu?
• □ Sağlayıcı korumalı alan dışında veya ayrıcalıklı çalışan süreçleri ve gerekliliklerini açıklayabiliyor mu?

Chromium, korumalı alanını güvenilmeyen kodu kısıtlayan ve hem içerideki koda hem kontrolcüsüne en az yetki uygulayan sınır olarak açıklar. Chromium korumalı alan tasarımını inceleyin; ardından sağlayıcıdan gerçek üretim yapılandırmasını göstermesini isteyin. “Chromium kullanıyor” ifadesi, kaynak projedeki bütün önlemlerin etkin kaldığını kanıtlamaz.

Güncelleme bütünlüğünde The Update Framework, depo ve imzalama anahtarı ele geçirilmesini açıkça ele aldığı için yararlı referanstır. SLSA üretim bilgisi, çıktının nerede, ne zaman ve nasıl üretildiğine ilişkin doğrulanabilir bilgiyi tanımlar. Sağlayıcının bu projeleri aynen kullanması gerekmez; ancak dosya kimliğini, ele geçirilmiş anahtarları, eski sürüme döndürmeyi, güncellemeyi dondurmayı ve derleme kaynağını nasıl yönettiğini açıklamalıdır.

4. Kimlik, cihazlar ve en az yetki

NIST SP 800-53 Rev. 5; erişim kontrolü, denetim, kimlik doğrulama, süreklilik planlaması, olay müdahalesi ve tedarik zinciri riskini kontrol gruplarında ele alır. Çerçeveyle uyumu uygulama kanıtı saymak yerine bu grupları soru kaynağı olarak kullanın.

• □ Her kişiye ortak ekip girişi yerine bireysel kimlik veriliyor mu?
• □ Yöneticiler ve hassas roller için çok faktörlü doğrulama mevcut ve zorunlu kılınabilir mi?
• □ Risk gerektirdiğinde daha güçlü, kimlik avına dayanıklı doğrulama seçenekleri destekleniyor mu?
• □ Gerekirse ürün yetkilendirmesini atlamadan kendi kimlik sağlayıcınızla federasyon kurulabiliyor mu?
• □ Roller; görme, başlatma, düzenleme, paylaşma, dışa aktarma, silme, faturalandırma ve yönetimi ayıracak kadar ayrıntılı mı?
• □ Erişim kuruluş, çalışma alanı, klasör veya açık profil kümesiyle sınırlanabiliyor mu?
• □ Cihaz, oturum, kullanıcı, hizmet kimlik bilgisi veya davet hızla iptal edilebiliyor mu?
• □ Hizmet hesaplarının kendi kimliği, süre sonu, kapsamları ve hız sınırları var mı?
• □ İzin değişiklikleri ve başarısız yetkilendirme denemeleri denetim izinde görünüyor mu?
• □ Ekipten çıkarma, ortak parola değişikliği gerektirmeden erişimi kaldırıyor mu?

Güncel kimlik doğrulama terimleri ve güvence rehberi için 31 Temmuz 2025’te tamamlanan NIST SP 800-63B-4’e bakın. Sağlayıcının iddialarının ürünün hangi bölümlerini kapsadığını doğrulayın: web sitesi girişi, masaüstü kilit açma, yerel API, bulut API, kurtarma ve destek erişimi farklı mekanizmalar kullanabilir.

5. Hassas veri ve güven sınırları

Ürünün veri akışını çizin. Masaüstü yöneticisini, tarayıcı süreçlerini, yerel hizmeti, bulut kontrol düzlemini, eş zamanlama depolamasını, güncelleyiciyi, çökme bildiricisini, destek araçlarını ve üçüncü taraf entegrasyonlarını işaretleyin. Her sınırdan neyin, neden geçtiğini sorun.

• □ Hangi profil içerikleri varsayılan olarak yerelde kalır?
• □ Eş zamanlama açıkken hangi meta veriler ve hassas içerikler yüklenir?
• □ Şifreleme nerede yapılır; hangi taraflar çözme anahtarlarını alabilir?
• □ Yerel anahtarlar nasıl korunur, yedeklenir, yenilenir ve kurtarılır?
• □ Kuruluş yöneticileri, sağlayıcı desteği, altyapı çalışanları ve otomasyon istemcileri neleri okuyabilir?
• □ Çerezler, parolalar, proxy kimlik bilgileri, iki faktörlü doğrulama sırları ve şifreleme anahtarları normal arayüz, günlük, telemetri, API ve ajan çıktısından dışlanıyor mu?
• □ Çökme raporları ve tanılama önizlenebilir, hassas verileri gizlenmiş, rızayı gözeten ve sınırlı süre saklanan yapıda mı?
• □ Destek, ham profil arşivi veya kimlik bilgisi istemeden çalışabiliyor mu?
• □ İçe aktarılan uzantılar, arşivler, tarayıcı indirmeleri ve güncelleme meta verileri güvenilmeyen sayılıyor mu?
• □ Silme; yerel kopyalar, bulut nesneleri, yedekler, günlükler ve destek dosyaları için tanımlı mı?

“Şifreli” ifadesini tam yanıt kabul etmeyin. Veri kategorisini, konumu, şifreleme sınırını, anahtar sahibini, kurtarma yolunu ve açık metnin bulunduğu durumları kaydedin.

6. İş birliği ve denetlenebilirlik

• □ Atama ve devir sırasında profil sahipliği açık kalıyor mu?
• □ Ürün eş zamanlı düzenlemeyi önlüyor veya görünür biçimde çözüyor mu?
• □ Davetler, rol değişiklikleri, başlatmalar, durdurmalar, paylaşımlar, dışa aktarımlar, silmeler, otomasyon çağrıları ve kurtarmalar kaydediliyor mu?
• □ Her olay; insan aktörü, devredilen iş yükünü, kaynağı, zamanı, kararı ve sonucu belirtiyor mu?
• □ Önemli yapılandırma değişikliklerinde sırlar gizlenerek önceki ve sonraki değerler kaydediliyor mu?
• □ Saatler, saat dilimleri, olay sırası ve istek kimlikleri açık mı?
• □ Denetim erişimi, dışa aktarım biçimi, saklama ve silme kontrolleri belgelenmiş mi?
• □ Yönetici, kendisini incelemek için kullanılan kayıtları değiştirebilir veya silebilir mi?
• □ Ekip günlükleri kendi izleme veya inceleme sistemine aktarabiliyor mu?
• □ Denetim hedefi kullanılamıyorsa kayıt sürüyor, güvenle tamponlanıyor veya işlem duruyor mu?

OWASP günlük rehberi, günlük erişimi kontrol edilip teknik sırlar dışarıda tutularak yetkilendirme hatalarının ve yüksek riskli işlemlerin; ne zaman, nerede, kim, ne bilgileriyle kaydedilmesini önerir. Bunu yalnızca güvenlik sayfasındaki ekran görüntülerine değil, ürünün gerçek dışa aktarılmış olaylarına uygulayın.

7. Kurtarma, kesinti ve hizmetten ayrılma

Geri yükleme test edilene kadar yedekleme iddiası eksiktir. NIST Siber Güvenlik Çerçevesi 2.0, yedekleri oluşturma, koruma, sürdürme ve test etme ile geri yükleme varlıklarını ve geri yüklenen sistemleri doğrulama sonuçlarını içerir.

• □ Profil kilitlerine uyarak tutarlı yedek oluşturabiliyor musunuz?
• □ Yerel ve eş zamanlanan sürümler tanımlanabilir ve sıralı mı?
• □ Kullanıcı mevcut kopyayı yok etmeden seçili sürümü geri yükleyebiliyor mu?
• □ Normal kullanım başlamadan geri yüklenen veri ve tarayıcı uyumluluğu doğrulanıyor mu?
• □ Tarayıcı süreci sonlandırılırsa, ağ koparsa, disk dolarsa, yükleme kesilirse veya uygulama çökerse ne olur?
• □ Çalıştığı bilinen son sürüm başarısız onarımdan korunuyor mu?
• □ Erişimi iptal edilmiş veya kayıp cihaz, tek kurtarma yolu kaybedilmeden kaldırılabiliyor mu?
• □ Kurtarma anahtarları veya kodları hem kolay kayba hem sınırsız yönetici erişimine karşı korunuyor mu?
• □ Ekip hizmeti iptal etmeden verisini belgelenmiş biçimde dışa aktarıp doğrulayabiliyor mu?
• □ Kalan saklama kapsamını açıkça anlatan desteklenen silme ve hesap kapatma süreci var mı?

Sağlayıcı ve değişiklik süreciniz üretim denemelerini açıkça desteklemedikçe kurtarmayı yalnızca geçici deneme verileriyle test edin. Kurtarma süresini, kaybolan durumu, elle adımları, uyarıları ve ürün sürümünü kaydedin. Küçük tek profilde başarılı gösterim, üretim ölçeğinizde performans veya bütünlük kanıtlamaz.

8. Otomasyon ve geliştirici kontrolleri

• □ Ürün sınırsız dosya sistemi veya süreç erişimi yerine sürümlenmiş alan işlemleri sunuyor mu?
• □ API, CLI, SDK, Playwright, CDP, WebDriver, webhook ve ajan yetenekleri ayrı belgeleniyor mu?
• □ Tam tarayıcı-istemci uyumluluk matrisi var mı?
• □ Kimlik bilgileri kiracı, profil, işlem, hedef sunucu, süre, hız ve maliyetle sınırlanabiliyor mu?
• □ Yıkıcı, toplu, dışarıdan görünen, sır taşıyan veya harcama doğuran işlemler daha güçlü politika veya onay gerektiriyor mu?
• □ Önizlemeler çalıştırılacak tam isteğe bağlı mı?
• □ Durum değiştiren komutlar yinelendiğinde ek etki yaratmıyor mu veya bilinmeyen sonuçları açıkça belirtiyor mu?
• □ Uzun işlemler iptal edilip güvenle sürdürülebiliyor mu?
• □ Yetki iptali etkin iş sırasında etkili oluyor mu?
• □ Otomasyon kararları insan işlemleriyle aynı denetim izinde sorumlu kimliğe bağlanabiliyor mu?
• □ Olağan otomasyon çıktısı ham oturum durumu döndürmeden yararlı kalabiliyor mu?
• □ Hatalar sır sızdırmadan kurtarmaya yetecek kadar belirli mi?

Ret yollarını test edin. Salt okunur belirteç profil başlatamamalı. Profil kapsamlı belirteç başka klasörde başarısız olmalı. Süresi dolmuş kimlik bilgisi sessizce daha geniş erişime yenilenmemeli. Ajan, isteği yeniden yazarak reddedilmiş çağrıyı yönetici onayına dönüştürememeli.

9. Kullanıcı deneyimi ve erişilebilirlik

• □ Klavye kullanıcıları her kontrole, iletişim kutusuna, tabloya, menüye ve profil işlemine ulaşabiliyor, kullanabiliyor ve çıkabiliyor mu?
• □ Gezinme, hata ve modal değişikliklerinden sonra odak görünür ve mantıklı sırada mı?
• □ Etiketler, hatalar, durum değişiklikleri ve yıkıcı işlem onayları ekran okuyucuyla çalışıyor mu?
• □ Yakınlaştırmada ve büyütülmüş metinde arayüz kullanılabilir kalıyor mu?
• □ Renk, hareket ve zaman sınırları ayarlanabilir veya zorunlu olmayan nitelikte mi?
• □ Kullanıcılar seçili kuruluşu, profili, proxy’yi, ortamı ve risk durumunu yalnızca renge dayanmadan ayırt edebiliyor mu?
• □ Toplu işlemler erişilemez yoğun tablolara zorlanmadan incelenebiliyor mu?
• □ Yerel platform davranışı, bildirimler, dosya seçiciler, kimlik bilgisi istemleri ve güncelleme pencereleri tutarlı çalışıyor mu?

WCAG 2.2; klavye kullanımı, odak sırası, odak görünürlüğü, hedef boyutu, hata tanımlama ve erişilebilir kimlik doğrulama dâhil test edilebilir web içeriği ölçütleri sağlar. Masaüstü ürünü yerel ve web arayüzleri içerebilir; ilgili standart kontrollerini desteklenen her işletim sisteminde yardımcı teknoloji testiyle birleştirin.

10. Ticari ve operasyonel uygunluk

• □ Kullanıcılar, kayıtlı profiller, eş zamanlanan profiller, depolama, trafik, eş zamanlı oturumlar, API hızı, otomasyon çalışanları ve destek düzeyleri ayrı ve açık fiyatlandırılıyor mu?
• □ Hangi sınırlar kesin durma, aşım ücreti veya adil kullanım koşulu?
• □ Yönetici onayı olmadan faturalandırma veya kapasite değişebiliyor mu?
• □ Desteklenen proxy protokolleri, doğrulama yöntemleri, uzantılar ve ağ ortamları belgelenmiş mi?
• □ Destek politikası tarayıcı güncelleme olaylarını, profil bozulmasını, başarısız geri yüklemeyi, güvenlik bildirimlerini ve hesap kurtarmayı kapsıyor mu?
• □ Hizmet durumu, olay iletişimi ve üst desteğe başvuru yolları gerçek ve takip ediliyor mu?
• □ Sözleşme veri iadesini, silmeyi, fiyat değişikliğini, askıya almayı ve sonlandırmayı tanımlıyor mu?
• □ Güvenli geçişi kanıtlamak için gereken kanıtı kaybetmeden ayrılabiliyor musunuz?

Maliyeti en yoğun eş zamanlı işinize, beklenen eş zamanlanan duruma, otomasyon hacmine ve destek ihtiyacına göre hesaplayın. Vergileri, yıllık taahhütleri, aşımları ve taşıma işçiliğini kaydedin. Yalnızca fiyat sayfalarındaki en büyük profil sayısını karşılaştırmayın.

Kontrollü deneme planı

Değerlendirme için oluşturulmuş test hesapları, sentetik kimlik bilgileri ve profiller kullanın. Denemeyi gerçekçi kılmak için üretim çerezleri içe aktarmayın.

1. Ortamı kaydedin. Uygulama ve tarayıcı sürümlerini, işletim sistemini, donanımı, ağı, proxy türünü, uzantı kümesini, hesap paketini ve test tarihini yazın.
2. İki rol ve birkaç profil oluşturun. Yönetici, sınırlı kullanıcı, ayrı klasörler ve kullanıcının erişmemesi gereken en az bir profil dâhil edin.
3. Normal iş akışını çalıştırın. Profilleri başlatın, kullanın, durdurun, devredin ve yeniden açın. Beklenen ve gerçek durumu kaydedin.
4. Reddetmeyi sınayın. Sınırlı kimlikle kapsam dışı profil, dışa aktarma, rol değişikliği ve otomasyon komutu deneyin.
5. Kesintiyi sınayın. Geçici verilerle tarayıcı durdurma veya eş zamanlama adımını sağlayıcının desteklediği ya da başka güvenli yöntemle kesin. Kurtarma yolunu doğrulayın.
6. Geri yükleyip karşılaştırın. Bilinen anlık görüntüyü yeni kopyaya geri yükleyin, bütünlüğünü doğrulayın ve kabul edilene kadar mevcut kopyayı koruyun.
7. Erişimi iptal edin. Kullanıcı, cihaz, oturum ve hizmet kimlik bilgisini kaldırın; hem arayüz hem API reddini doğrulayın, denetim olaylarını inceleyin.
8. Taşınabilirliği kontrol edin. İzinli veriyi dışa aktarın, belgelenmiş biçimini inceleyin, destekleniyorsa geçici hedefe yeniden alın ve dışarıda kalanları belirleyin.
9. Erişilebilirliği inceleyin. Gereken her platformda temel görevleri klavye ve ilgili yardımcı teknolojiyle tamamlayın.
10. Maliyetleri ve iddiaları karşılaştırın. Gözlenen kaynak kullanımını ve destek yanıtlarını teklifle ve sözleşmeyle karşılaştırın.

Karar kaydı şablonu

Gereksinim	Öncelik	Sonuç	Kanıt ve tarih	Sınır veya risk	Sorumlu ve sonraki adım
Örnek: kullanıcı oturum durumunu dışa aktaramaz	Zorunlu koşul	Geçti	Kontrollü deneme, sürüm X, YYYY-MM-DD	Yalnızca API; CLI test edilmedi	Güvenlik sorumlusu CLI’ı test edecek

Değerlendirmeyi dört açık listeyle kapatın:

• yeterli kanıtla geçen zorunlu koşullar;
• adı belli sorumlu ve inceleme tarihiyle kabul edilen kaygılar;
• doğrulanmamış kalan maddeler;
• yeni tarayıcı motoru, kimlik sağlayıcısı, güncelleyici, fiyatlandırma modeli veya profil biçimi gibi yeniden değerlendirme tetikleyicileri.

Yaygın uyarı işaretleri

Şu durumlarda kararı duraklatın:

• tarayıcı sürümü belirlenemiyor;
• normal kullanım için korumalı alan kapatılmalı;
• yöneticiler ve otomasyon kalıcı ortak kimlik bilgisi kullanıyor;
• ekip devri ham çerez veya parola paylaşımına dayanıyor;
• API, arayüzün koruduğunu iddia ettiği sırları dışa aktarabiliyor;
• denetim olaylarında aktör yok veya kayıtlar dışa aktarılamıyor;
• “yedek”, gösterilmiş geri yükleme olmadan yalnızca bulut kopyası demek;
• sağlayıcı kesilen yazmaları veya eş zamanlı profil erişimini açıklayamıyor;
• erişilemeyen kritik iş akışının alternatifi yok;
• güvenlik bildirimi sırları normal e-postayla göndermeyi gerektiriyor;
• ürün iddiaları tespit edilemezlik, garantili hesap erişimi veya platform yaptırımını aşma vaat ediyor.

“Doğrulanmadı” sonucu suçlama değildir. Eksik kanıtı tam olarak belirtir. Sağlayıcı kanıt verene, ekibiniz davranışı test edene veya karar sorumlusu riski kabul edene kadar görünür tutun.