Olası günlük senaryo: form hâlâ görüntülenir, fakat arkasındaki arayüz artık istek kabul etmez. Ya da gece içe aktarma, kimlik doğrulaması geçersiz olduğu için durur. Bu bağımlılıklar çoğunlukla iş süreci gerçekleşmediğinde fark edilir.
API erişimi bu yüzden güvenli depodan fazlasını gerektirir. Sorumlu, geçerlilik, değiştirme yöntemi ve gerçek işlev kontrolü birlikte ele alınır. API anahtarları, OAuth istemci bilgileri, hizmet hesapları ve sertifikalar için farklı kurallar geçerlidir.
Süre sonu, rotasyon ve iptal farklı olaylardır
Sabit bitiş tarihi sonraki kullanımı teknik olarak sonlandırabilir. Rotasyon kuralı ise erişimin ne zaman değiştirileceğini belirler. Sağlayıcı zorunlu kılabilir veya işletimde kararlaştırılabilir. İptal, belirli nedenle bir yetkiyi bitirir ve süresi dolmamış kimlik bilgisini de etkileyebilir.
Her anahtar otomatik olarak aynı ömre sahip değildir. Google, kullanıcı tarafından oluşturulan hizmet hesabı anahtarlarının varsayılan olarak süresiz olduğunu belgeler; kuruluş politikaları bunu değiştirebilir. Microsoft Entra istemci sırlarının ise belirli geçerliliği vardır. Tüm hizmetlere aynı aralığı varsaymak yerine gerçek düzenleyenin kuralı kaydedilir.
OAuth’ta erişim belirteci, olası yenileme belirteci ve uygulamanın kimlik bilgileri farklı unsurlardır. Yaşam döngüleri envanterde tek bir “API anahtarı” olarak birleştirilmemelidir. Hizmet hesabı kimliği de ona ait tek bir anahtarla aynı değildir.
Envanter, açık metin sırlar olmadan sorumluluk ister
Her önemli entegrasyon erişimi için en az hizmet, proje, etkilenen süreç, düzenleyen ve kimlik bilgisi türü kaydedilir. Sorumlu kişi veya rol, vekil ve ulaşılabilir eskalasyon yolu eklenir. Uyarıyı alan kişi hangi iş sürecinin buna bağlı olduğunu bilmelidir.
- Kural: Düzenlenme tarihi, gerçek bitiş veya açıkça süresizlik, planlı rotasyon ve olası sağlayıcı değişiklikleri.
- Bağımlılıklar: Erişimi kullanan uygulamalar, işler, kurulumlar ve ayrı ortamlar.
- Depolama: Onaylı sır deposuna ve sorumlu yönetime başvuru; envanterde ham değer yok.
- Değişim: Test yöntemi, hazırlık süresi, onay, geri dönüş ve son başarılı test tarihi.
Sır deposundaki tarih ile düzenleyenin teknik olarak uyguladığı geçerlilik ayrı kontrol edilir. Güncel meta veri kaydı sağlayıcıdaki erişimi kendiliğinden yenilemez.
Erken uyarın ve gerçek işlevi test edin
Süre sonu uyarısı onay, hazırlama ve test için yeterli zaman bırakmalıdır. Ön süre sağlayıcı, risk ve organizasyon yüküne bağlıdır. Vekilsiz alıcı veya etkilenen entegrasyondan geçen uyarı gereksiz bağımlılık yaratır.
Beklenen sürecin çalışması da izlenir: istekler geliyor mu? İçe aktarma çalışıyor mu? Amaçlanan model isteği işlenebiliyor mu? Hata oranları, gerçekleşmeyen işler ve tekrarlanabilir testler yaklaşan bitiş olmadan da sapmaları gösterir. Kontrol olabildiğince az ek veri ve maliyet üretmelidir.
Başarısız çağrı otomatik olarak süresi dolmuş anahtar değildir. Yetkiler, kotalar, fatura veya ödeme durumu, sağlayıcı değişiklikleri ve teknik erişilebilirlik ayrı incelenir. Somut hata ve etkisi sonraki adımı belirler.
| Olay | Anlamı | Uygun hazırlık |
|---|---|---|
| Teknik süre sonu | Kimlik bilgisi düzenleyenin kuralına göre sona erer. | Tarihi kontrol edin, zamanında değiştirin, işlevi test edin. |
| Planlı rotasyon | Mevcut erişim plana göre değiştirilir. | Tüm tüketicileri bilin, geçişi ve geri dönüşü test edin. |
| İptal veya geri çekme | Yetki hedefli olarak sonlandırılır. | Neden, etkilenen erişimler ve süren işlemleri dikkate alın. |
| Diğer entegrasyon hatası | Örneğin yetki, kota, ödeme veya erişilebilirlik. | Somut nedeni ve iş sürecini ayrı inceleyin. |
Değişimi bütün bir süreç olarak planlayın
Sağlayıcı aynı anda birden fazla geçerli kimlik bilgisini destekliyorsa, eskisi çalışırken yenisi hazırlanabilir. Microsoft bu ilkeyi örneğin iki anahtarlı kaynaklar için açıklar. Bu sağlayıcıya özgü imkândır; her API için genel taahhüt değildir.
- Hazırlayın: Yetkileri ve tüm tüketicileri kontrol edin, yeni erişimi belirlenmiş güvenli depoda hazırlayın.
- Test edin: Gerçekte gereken eylemleri yeni kimlik bilgisiyle uygun test ortamında veya kontrollü kapsamda doğrulayın.
- Geçiş yapın: Etkilenen uygulama ve işleri düzenli güncelleyin; yükleme davranışını ve olası önbellekleri dikkate alın.
- İzleyin: İşlev ve hata gelişimini kontrol edin. Gözden kaçan tüketicinin eski erişime hâlâ ihtiyacı var mı?
- Tamamlayın: Doğrulanmış geçişten sonra eski bilgiyi iptal edin, envanteri ve işletim belgelerini güncelleyin.
Aynı anda yalnızca bir erişim geçerliyse değişim daha yakın koordinasyon ister. Kararlaştırılmış bakım penceresi yararlı olabilir. Geri dönüş önceden belirlenir; ele geçirilmiş veya iptal edilmiş eski erişim doğrudan etkinleştirilmez.
Mümkün olduğunda kalıcı anahtar ihtiyacını azaltın
Uygun platformlar uygulamalar için yönetilen kimlik veya federasyonlu doğrulama sunar. Bunlar kendi dağıttığınız uzun ömürlü sırların yönetimini azaltabilir. Uygunluk, hedef yetkileri, ömür ve kurtarma yine kontrol edilir. Sertifika da yaşam döngüsü gerektirir.
Sır tarayıcı, yayımlanmış olabilecek kimlik bilgilerini tespit ederek korumayı tamamlar. İşletim bağımlılık envanterini tutmaz ve tüm tüketicilerin tam değişimini yapmaz. Sızıntı arama ve geçerlilik yönetimi farklı işlerdir.
İş açısından kritik bağlantılarla başlayın
DAXS önemli arayüzleri ve sorumluları kaydeder, uyarı yollarını kontrol eder ve tekrarlanabilir değişim geliştirir. Pilot; form gönderimi, veri aktarımı veya model bağlantısıyla başlayabilir. Bunlar olası testlerdir, müşterilere atfedilen olaylar değildir.
Bizim geliştirme ve entegrasyon hizmetlerimiz ve MCP ve arayüz teknik sayfamız entegrasyonu açıklar. Bizim projeye özel MCP yetkileri yazımız kontrollü erişimi tamamlar. Siz entegrasyon erişimlerinizin envanterini talep edebilirsiniz.
Sık sorulan sorular
Her API anahtarı düzenli yeniden oluşturulmalı mı?
Tüm sağlayıcılara tek kural yoktur. Geçerlilik, düzenleyen kuralları, risk ve işletim değişimi somut incelenir. Sabit bitiş tarihi olmayan anahtar da düzenli yönetim ister.
Süre sonundan kısa önce e-posta yeterli mi?
Uyarı ancak sorumlu, vekil ve test edilmiş süreç varsa yararlıdır. Bağımlı işlevin gerçekte çalışıp çalışmadığı da görünmelidir.
Rotasyon her zaman kesintisiz olabilir mi?
Sağlayıcıya, paralel kimlik bilgilerine ve uygulamanın yükleme davranışına bağlıdır. Örtüşmeli değişim mümkün değilse uygun bakım penceresiyle eşgüdümlü süreç planlanır.
Kaynaklar: Google Cloud: hizmet hesabı anahtarları ve süre sonu (harici bağlantı) · Microsoft: uygulama kimlik bilgileri ve rotasyon (harici bağlantı) · Microsoft: iki kimlik bilgisiyle değişim (harici bağlantı) · Microsoft: tek kimlik bilgisiyle rotasyon (harici bağlantı) · IETF: OAuth belirteçleri ve uygulama doğrulama (harici bağlantı) · OWASP: sırların yaşam döngüsü (harici bağlantı) · GitHub: sır taraması kapsamı (harici bağlantı)
Olası senaryolar ve basitleştirilmiş süreçler; somut kurallar ve değişim imkânları sağlayıcı ve uygulamaya bağlıdır. Şema ve temsili görsel müşteri yapılandırması göstermez.
