Paylaşılan bir MSP yükseltme şablonu yalnızca etkilenen müşteri adına hareket edebilecek kişilere çözümlendiğinde faydalıdır. Bir analist, bir kimlik doğrulama hatasını fark edebilir ancak iş açısından kritik bir göndereni değiştirme iznine sahip olmayabilir. Bir olay aceleye karar verilmesini gerektirmeden önce soruşturma, kontrol altına alma ve değişikliğin onaylanması arasındaki sınırı tanımlayın.
Etiketler yerine kararlar atayın
Her müşteri için gönderen yetkilendirmesini, DNS değişikliklerini, yaptırım politikasını, acil durum geri alma ve veri ifşasını kimin onayladığını belirleyin. Teknik ve işletme sahiplerini ve alternatiflerini adlandırın. Doğrulanmış iletişim rotalarını ve kapsama saatlerini kaydedin. Bordro arızası sırasında kimsenin cevap verememesi durumunda "müşteri BT" gibi genel bir giriş yetersiz kalır.
Kanıtları inceleme hakkını, bir değişikliği onaylama yetkisinden ayırın. OWASP'ın yetkilendirme kılavuzu Geniş bir kimlik doğrulama durumuna güvenmek yerine tam eylemin ve kapsamın kontrol edilmesini destekler. Bu kontroller MSP personeli, müşteri yöneticileri ve otomasyon kimlikleri için geçerlidir. Acil durum çalışmaları hâlâ tanımlanmış bir hibeye ihtiyaç duyuyor; aciliyet sınırsız yetki yaratmaz.
Saati ve geri dönüşü tanımlayın
Yanıt saatinin ne zaman başladığını, bildirimin ne olduğunu ve üst kademeye iletmenin ne zaman gerçekleşeceğini belirtin. Kapsanan hizmet dakikalarını geçen takvim süresinden ayırın. Saat dilimini ve tatil kurallarını adlandırın. Bir onay, sorumlu bir kişinin görevlendirildiğini belirtir; teşhis veya restorasyon anlamına gelmez.
Birincil onaylayanın müsait olmaması durumunda ne olacağını belgeleyin. Bir yedek, tanımlanmış kapsam dahilinde onay verebilir veya ekip kanıtları saklayabilir ve önerilen değişikliği beklemeye alabilir. Açıkça üzerinde anlaşmaya varılan bir politika söz konusu eyleme gerçekten izin vermedikçe sessizliği onay olarak yorumlamayın. Politika ve karar kanıtlarını saklayın.
Üç varsayımsal olayı farklı şekilde yönlendirin
Bilinmeyen bir gönderenin, yeni bir yetkilendirme öncesinde atıf kanıtına ihtiyacı vardır. Kimlik doğrulama hatasının gözlemlendiği bir faturalama rotasında, hizmet sahibinin ve kapsam değişikliği onaylayıcısının önerilen onarımı değerlendirmesi gerekir. Şüpheli bir çapraz kiracı dışa aktarma girişiminin, DNS onarım kuyruğuna otomatik olarak yerleştirilmesi değil, güvenlik incelemesi ve herhangi bir yetkili sınırlamaya ihtiyacı vardır. Bunlar varsayımsal önceliklendirme kararlarıdır, gerçek olaylar veya bildirimler değildir.
Her vaka için, doğrulanmış birincil irtibat kişisini, alternatif kişiyi, izin verilen eylem kapsamını ve bundan sonra ihtiyaç duyulan kanıtları belirtin. Faturalandırmayı onaylayan kişi müsait değilse ve alternatifin hedef alan adı için yetkisi yoksa, değişikliği beklemede tutun ve yetki boşluğunu artırın. Yanıt süresi hedefini veya iş aciliyetini sessizce yürütme izni olarak değerlendirmeyin. Bu örnekte herhangi bir sözleşme saati, müşteri onayı veya yürütülen saha doğrulayıcısı sağlanmamaktadır.
Kararları koruyun ve gözden geçirin
Tam teklifi, onay kimliğini, zaman damgasını, uygulama makbuzunu ve doğrulama sonucunu bir arada tutun. RFC 9989's hizalama model, başarılı bir kimlik doğrulama onarımının neyi göstermesi gerektiğini belirlemeye yardımcı olur. Bir kayıt tek başına arama, etkilenen uygulamanın mesaj düzeyindeki sonucundan daha zayıftır. Yalnızca en kolay gönderici çalıştığında olayın kapatıldığını bildirmek yerine kalan arızaları kaydedin.
Personel değişikliklerinden sonra kişileri gözden geçirin ve yetkisiz üretim değişiklikleri yapmadan rotayı uygulayın. Bir yükseltme tatbikatı, ulaşılamayan kişileri, belirsiz yetkileri ve eksik kapsamı ortaya çıkarmalıdır. Değişen sorumluluklara güvenmeden önce runbook'u güncelleyin ve uygun müşteri kabulünü alın. Sonuç, bir isimler dizini değil, baskı altında çalışan bir karar yolu olmalıdır.