Çok Modelli Yapay Zeka Ağ Geçitleri için Sağlayıcı Kimlik Bilgisi Kasaları: Ayrı Çalışma Zamanı, Yönetici, Faturalandırma ve BYOK Erişimi
Çok modelli yapay zeka ağ geçitleri için pratik bir kimlik bilgisi kasası modeli: yukarı akış sağlayıcı anahtarlarını sınıflandırın, çalışma zamanını yönetici erişiminden yalıtın, BYOK kimlik bilgilerini kiracılara bağlayın, güvenli bir şekilde döndürün ve her kimlik bilgisi kararını denetleyin.
Aşağı akış API anahtarları ve yukarı akış sağlayıcı kimlik bilgileri farklı sorunları çözer. Ağ geçidiniz tarafından verilen geliştirici anahtarı; uygulamayı, ekibi, kiracıyı, bütçeyi ve politika bağlamını tanımlar. Yukarı akış sağlayıcı anahtarı, ağ geçidinin para harcamasına ve sağlayıcı hesabındaki modellere erişmesine olanak tanır. Bunları aynı tür sır olarak ele almak, ekiplerin paylaşılan bir projede sınırsız bir anahtara, çalışma zamanı hizmetlerinde yönetici kimlik bilgilerine ve hangi kiracının hangi sağlayıcı tarafından hangi ücretlendirmeye neden olduğuna yanıt vermenin güvenilir bir yolunun bulunmamasına neden olur.
Pratik model, sağlayıcı kimlik bilgisi kasasıdır: Yukarı akış kimlik bilgilerini içe aktarmak, sınıflandırmak, depolamak, seçmek, döndürmek ve denetlemek için özel bir kontrol düzlemi. Uygulama kodunun, model yapılandırma dosyalarının, kiracı kayıtlarının veya analiz olaylarının içinde değil, yönlendiricinin, fatura defterinin, politika motorunun ve operasyon iş akışının arkasında yer almalıdır.
Okuyucu sorunu: Yukarı akış kimlik bilgileri görünmez bir altyapı haline geliyor
Çok modelli dağıtımların çoğu basit bir hedefle başlar: OpenAI uyumlu bir isteği mevcut en iyi sağlayıcıya yönlendirmek. Ardından daha fazla hesap ortaya çıkıyor: üretim için bir sağlayıcı projesi, değerlendirme için başka bir sağlayıcı projesi, bir iş birimi için Antropik bir çalışma alanı, Gemini için bir Google Cloud projesi ve BYOK sözleşmeleri için müşteri tarafından sağlanan birkaç anahtar.
Risk yalnızca gizli sızıntı değildir. Yetkilendirme bağlamının kaybıdır. Geçerli bir sağlayıcı anahtarı teknik olarak bir uç noktayı arayabilir ancak ağ geçidinin yine de bu anahtara bu kiracı, bu model ailesi, bu veri saklama politikası, bu bütçe, bu bölge ve bu otomasyon yolu için izin verilip verilmediğini bilmesi gerekir.
Gerçek: sağlayıcı platformları farklı hesap sınırlarını ve kimlik bilgisi türlerini ortaya çıkarır. OpenAI, projeleri ve hizmet hesaplarını belgeler ve hizmet hesabı API anahtarı izinleri, projenin API kaynakları için varsayılan okuma ve yazma erişimidir. OpenAI ayrıca Admin API anahtar nesnelerini sıradan proje/çalışma zamanı API kullanımından ayrı olarak kullanıma sunar. Anthropic, çalışma alanlarını kuruluş sınırı olarak belgeliyor ve Admin API uç noktalarının, standart API anahtarlarından farklı Admin API anahtarları gerektirdiğini belirtiyor; Anthropic ayrıca API anahtarlarının oluşturuldukları çalışma alanına bağlı olduğunu ve çalışma alanları arasında taşınamayacağını da belirtiyor. Google'ın Gemini API anahtarı belgelerinde, her Gemini API anahtarının bir Google Cloud projesiyle ilişkili olduğu belirtiliyor ve bir anahtarın güvenliği ihlal edildiğinde hasarı azaltmak için API kısıtlamaları öneriliyor.
Öneri: tek bir genel "provider_key" alanı oluşturup bunu tamamlandı olarak adlandırmayın. Ağ geçidine normalleştirilmiş bir politika modeli sunarken sağlayıcıya özgü sınırları koruyan bir kimlik bilgisi envanteri oluşturun.
Anahtarları kabul etmeden önce bir kimlik bilgisi sınıflandırması tanımlayın
Kasa belirsiz kimlik bilgilerini reddetmelidir. İçe aktarma sırasında operatör veya otomasyon iş akışının kimlik bilgilerini sınıflandırması gerekir. En azından şu kategorileri kullanın:
- Çalışma zamanı çıkarımı kimlik bilgileri: sağlayıcının desteğine bağlı olarak ağ geçidi tarafından sohbet, yanıtlar, yerleştirmeler, denetleme, transkripsiyon veya görüntü oluşturma gibi model çıkarımı uç noktalarını çağırmak için kullanılır.
- Yönetici otomasyonu kimlik bilgileri: sağlayıcı tarafındaki kuruluşları, çalışma alanlarını, projeleri, kullanıcıları, anahtarları veya yönetim kaynaklarını yönetmek için kullanılır. Bunlar hiçbir zaman çalışma zamanı istek yolunda olmamalıdır.
- Faturalandırma ve raporlama kimlik bilgileri: sağlayıcıların bu API'leri desteklediği yerlerde kullanımı, faturaları, maliyetleri veya kuruluş raporlarını almak için kullanılır. Raporlama işlerinin model kullanımı oluşturmaması için bunları çıkarım anahtarlarından ayrı tutun.
- Yalnızca değerlendirme kimlik bilgileri: karşılaştırma, QA, taşıma veya hazırlama iş akışları tarafından kullanılır. Düşük kotalara, anlaşılır ortam etiketlerine sahip olmalı ve üretim yedek uygunluğuna sahip olmamalıdır.
- Müşteri BYOK kimlik bilgileri: belirli bir kiracıya, sağlayıcı hesabına, sözleşmeye ve veri politikasına bağlı, müşteri tarafından sağlanan anahtarlar. Müşteri açıkça etkinleştirmediği sürece bunlar paylaşılan yönlendirmede bir araya getirilmemelidir.
Bu sınıflandırma yalnızca dokümantasyondan ibaret değildir. Erişim kontrolünü, yönlendirme uygunluğunu, uyarıları ve rotasyon iş akışlarını yönlendirmelidir. Bir kimlik bilgisi kategori, sahip, sağlayıcı hesap sınırı ve izin verilen kullanım olmadan içe aktarılırsa devre dışı kalmalıdır.
Gizli bilgileri ürün kayıtlarında değil kasada saklayın
Kasa, yukarı akış kimlik bilgilerinin şifresini çözebilen tek bileşen olmalıdır. Diğer sistemler referansları, karmaları, durum alanlarını ve politika meta verilerini depolayabilir ancak kimlik bilgisi değerinin kendisini depolayamaz.
Bu yerlerde yukarı akış gizli bilgilerini saklamayın
- Kiracı profili satırları.
- Yönlendirme yapılandırma dosyalarını modelleyin.
- İstem günlükleri veya izleme aralıkları.
- Analytics etkinlik verileri.
- Geliştiricinin karşılaştığı CI değişkenleri.
- Destek biletleri, sohbet araçları veya ekran görüntüleri.
Kullanılabilir bir kasa tasarımının iki düzlemi vardır. Gizli düzlem, şifrelenmiş kimlik bilgileri materyalini saklar ve şifre çözme işlemlerini sıkı bir şekilde kontrol eder. Meta veri düzlemi, yönlendirme ve yönetim tarafından kullanılan gizli olmayan nitelikleri saklar. Yönlendiricinin, her sağlayıcı anahtarına geniş veritabanı erişimine değil, genellikle yalnızca bir kimlik bilgisi kimliğine ve dağıtım sırasında kısa süreli bellek içi gizli erişime ihtiyacı olması gerekir.
Kasayı yüksek değerli bir altyapı olarak koruyun: zarf şifrelemesi veya yönetilen KMS, katı hizmet kimlikleri, çığır açan prosedürler, yedekleme ve geri yükleme testleri, erişim incelemesi ve olağandışı şifre çözme hacmi konusunda uyarı. Merkezi bir kasa, yönetimi basitleştirir ancak aynı zamanda riski de yoğunlaştırır. İşte takas budur.
Politika meta verilerini her kimlik bilgisine ekleyin
Meta veri modeli, ağ geçidinin, bir sağlayıcı uç noktasına dokunmadan önce bir kimlik bilgisinin uygun olup olmadığına karar verebileceği kadar açık olmalıdır.
Pratik bir kimlik bilgisi kaydı şunları içerir:
- credential_id: dahili değişmez tanımlayıcı.
- sağlayıcı: OpenAI, Anthropic, Gemini, Azure OpenAI veya başka bir bağdaştırıcı.
- provider_account_boundary: kuruluş, proje, çalışma alanı, bulut projesi, abonelik veya eşdeğeri.
- credential_class: çalışma zamanı, yönetici, faturalandırma, değerlendirme veya BYOK.
- ortam: üretim, hazırlama, geliştirme, değerlendirme, korumalı alan.
- tenant_binding: paylaşılan platform kimlik bilgisi, tek kiracı, kiracı grubu veya müşteri BYOK kiracısı.
- allowed_model_families: örneğin, metin oluşturma, yerleştirmeler, görüntü, resim, ses veya belirli model profilleri.
- allowed_endpoints: sağlayıcı uç noktalarıyla eşlenen normalleştirilmiş ağ geçidi özellikleri.
- data_policy: izin verilen saklama sınıfı, günlük kaydı sınıfı, ikamet gereksinimi ve özellik kısıtlamaları.
- bütçe_kapsamı: maliyet merkezi, bayi müşterisi, dahili departman veya sözleşme.
- sahip: adı verilen ekip veya sorumlu kişi.
- oluşturulma tarihi, sona erme tarihi, rotasyon_due_at, son_used_at.
- health_status: bilinmiyor, sağlıklı, bozulmuş, yetkisiz, quota_exhausted, devre dışı.
- emergency_disable: normal politika durumundan bağımsız olarak anında yönlendirme engellemesi.
Bu modeli sağlayıcı açısından tarafsız tutun, ancak sağlayıcı gerçeklerini silmeyin. Antropik çalışma alanına bağlı anahtar ile bir Google Cloud projesine bağlı Gemini anahtarı, her ikisi de metin oluşturabildiği için birbirinin yerine kullanılamaz. Ağ geçidinin denetimler, ters ibraz ve güvenli yük devretme için bu kaynağa ihtiyacı vardır.
Ayrı çalışma zamanı, yönetici ve faturalandırma erişimi
En önemli kural basittir: Çalışma zamanı çıkarımı için kullanılan bir anahtarın sağlayıcı kuruluşlarını, çalışma alanlarını, kullanıcıları, projeleri veya yönetim kaynaklarını yönetmemesi gerekir.
Çalışma zamanı trafiği yüksek hacimlidir ve en geniş operasyonel yüzeye açıktır. İstek yönlendiricilerinden, yeniden deneme mantığından, akış işleyicilerinden, model bağdaştırıcılarından ve olay iş akışlarından geçer. Yönetici kimlik bilgileri düşük sıklıkta ve yüksek etkiye sahiptir. Kısa TTL'lere sahip, uygun olduğunda insan onayı olarak adlandırılan, güçlü günlük kaydına sahip ve çalışma zamanı yönlendirme uygunluğu olmayan ayrı bir onay yolunun arkasında yaşamaları gerekir.
Faturalandırma kimlik bilgileri de ayrılmayı hak ediyor. Faturaların mutabakatını sağlayan bir raporlama işi tamamlamalar oluşturamamalı ve çalışma zamanı çıkarım anahtarı, kullanım raporlarını almanın tek yolu olmamalıdır. Bir sağlayıcı ayrıntılı bir ayırma sunmadığında, ağ geçidinde telafiyi yapın: kimlik bilgisini yalıtın, hangi dahili hizmet kimliğinin bu bilgiyi alabileceğini sınırlayın ve her kullanımı günlüğe kaydedin.
Öneri: Kimlik bilgisi sınıfını bir etiket değil, kesin bir yetkilendirme sınırı haline getirin. Bir çalışma zamanı dağıtıcısı, bir yapılandırma hatası kimliğine atıfta bulunsa bile yönetici kimlik bilgisinin şifresinin çözülmesini isteyememelidir.
Kimlik bilgisi seçimi politikası motoru oluşturma
Kimlik bilgisi seçimi, ağ geçidi alt arayan kişinin kimliğini doğruladıktan sonra ve herhangi bir sağlayıcı çağrısı yapılmaya çalışılmadan önce gerçekleşmelidir. Politika motoru birkaç girişi birleştirmelidir:
- Kiracı Kimliği ve aşağı akış API anahtarı kapsamı.
- İstenen model profili veya sağlayıcıya özel model kimliği.
- Uç nokta özelliği: sohbet, yerleştirmeler, resim, ses, toplu iş, dosyalar, araçlar veya yönetici otomasyonu.
- Veri saklama ve ikamet gereksinimleri.
- Bütçe, kredi rezervasyonu ve maliyet merkezi.
- Oran sınırı durumu ve kota baskısı.
- Kimlik bilgileri meta verileri, sağlık durumu, ortam ve kiracı bağlama.
Motor üç sonuçtan birini döndürmelidir: seçilen bir kimlik bilgisi ile izin ver, bir politika nedeni ile reddet veya onay gerektir. Reddetmeler, operasyon ekiplerinin gizli materyalleri geliştiricilere ifşa etmeden sorunu çözebilmeleri için yeterince kesin olmalıdır.
Örnek karar:
<ön>"Sonraki anahtarı deneyin" şeklinde geri dönüş uygulamayın. Geri dönüş, politikayı yeniden çalıştırmalı. Paylaşılan bir platform kimlik bilgisi, sağlayıcı erişimi için geçerli olabilir ancak yalnızca BYOK müşterisi için geçersiz olabilir. Başka bir projedeki kimlik bilgilerinin kotası olabilir ancak maliyet ilişkilendirme veya saklama gereksinimlerini ihlal ediyor olabilir.
BYOK'u yedek kapasite olarak değil, kiracının sahip olduğu erişim olarak ele alın
BYOK güven modelini değiştirir. Müşteri, trafiğinin sağlayıcı hesabından ücretlendirilebilmesi, yönetilebilmesi veya izole edilebilmesi için kimlik bilgilerini sağladı. Bu kimlik bilgisi müşteri kiracısına ve sağlayıcı hesabının kaynağına bağlı olmalıdır.
Önerilen BYOK kontrolleri:
- Müşteri, sağlayıcı, hesap sınırı ve ortam başına bir kasa kaydı.
- BYOK kimlik bilgileri aracılığıyla kiracılar arası yönlendirme yapılmaz.
- Müşteri açıkça etkinleştirmediği sürece, paylaşılan yedek kapasite olarak kullanılamaz.
- Ham anahtarı göstermeyen, müşterinin görebileceği durum durumu.
- Müşterinin eski anahtar devre dışı bırakılmadan önce yeni bir anahtar eklemesine olanak tanıyan ayrı rotasyon iş akışı.
- Kullanım analizleri ve faturalarda net ilişkilendirme: ağ geçidi kiracısı, sağlayıcı hesap sınırı, kimlik bilgisi kimliği, model profili ve istek izleme kimliği.
Ajanslar, bayiler ve İş Ortağı API otomasyonu için BYOK, bir hizmetin kiracıları ve kimlik bilgilerini programlı bir şekilde tedarik edebilmesi nedeniyle daha karmaşık olabilir. Aynı kural hâlâ geçerlidir: Otomasyon, kimlik bilgilerini içe aktarabilir ve bağlayabilir ancak kiracının sahipliğini bulanıklaştırmamalıdır.
Sızıntı istemleri olmadan ön kontrol durum kontrollerini ekleyin
Bir kimlik bilgisi birçok nedenden dolayı başarısız olabilir: iptal edilmiş anahtar, yanlış çalışma alanı, eksik model erişimi, devre dışı bırakılmış faturalandırma, kota tükenmesi, uç nokta kısıtlaması, bölgesel politika uyumsuzluğu veya sağlayıcı kesintisi. Bunu ancak bir üretim talebi geldikten sonra keşfetmek gürültülü olaylara neden olur.
Müşteri istemleri göndermeden yeteneği doğrulayan durum kontrollerini kullanın. Sentetik bir kontrol, minimum bir uç noktayı çağırabilir, uygun olduğunda izin verilen modelleri listeleyebilir veya tek pratik seçenek buysa, zararsız bir sabit bilgi istemi gönderebilir. Bu çekleri ucuz, oran sınırlı ve telemetri ve faturalandırmada sentetik trafik olarak etiketlenmiş halde tutun.
Durum kontrolleri yapılmalı:
- Kimlik bilgileri içe aktarılırken.
- Üretim yönlendirmesi için kimlik bilgisini etkinleştirmeden önce.
- Sağlayıcı tarafı kısıtlama değişikliklerinden sonra.
- Döndürme geçişi sırasında.
- Üretime uygun kimlik bilgileri için periyodik olarak.
Ödül: Otomatik kontroller, süresi dolmuş veya kapsamı yetersiz anahtarları erken yakalar, ancak kötü tasarlanmış kontroller, sağlayıcı kesintileri sırasında gereksiz sağlayıcı çağrılarına, faturalandırma gürültüsüne veya yanlış alarmlara neden olabilir. Durum sonucunu zaman damgası, sağlayıcı hata sınıfı, test edilen uç nokta ve test edilen model ailesiyle birlikte saklayın. Gizli değerleri veya hassas istemleri saklamayın.
Riskli tek bir değiştirme yerine iki yuvayla rotasyon yapın
Kimlik bilgisi rotasyonu, sil ve dua et işlemi olmamalıdır. İki yuvalı rotasyon modeli kullanın:
- Tam meta veriler ve sahiple birlikte değiştirilen kimlik bilgilerini etkin değil olarak içe aktarın. Amaçlanan uç noktalar, model aileleri ve hesap sınırı için
- sentetik durum kontrolleri çalıştırın. Uygun olduğunda, güvenli sentetik veya düşük riskli trafiğin küçük bir kısmı için
- gölge uygunluğunu etkinleştirin.
- Üretim trafiğini kademeli olarak eski kimlik bilgisinden yeni kimlik bilgisine geçirin.
- Kimlik bilgisi kimliğine göre hataları, gecikmeyi, kotayı ve maliyet ilişkilendirmesini izleyin.
- Yeni kimlik bilgisi stabil hale geldiğinde eski kimlik bilgilerine geri dönüşü dondurun.
- Sağlayıcıdaki eski kimlik bilgisini iptal edin ve iptal edilen kasa kaydını işaretleyin.
- İptal sonrasında eski kimlik bilgileri aracılığıyla herhangi bir şifre çözme veya sağlayıcı çağrısının gerçekleşmediğini doğrulayın.
Rotasyon son tarihleri operasyon görünümlerinde ve uyarılarda görünür olmalıdır. Acil durum rotasyonunun daha kısa bir yola ihtiyacı vardır: Kimlik bilgilerini devre dışı bırakın, yönlendirmeyi engelleyin, onaylı değiştirmeyi etkinleştirin ve olayın incelenmesi için tüm denetim kayıtlarını saklayın.
Sağlayıcının desteklediği durumlarda sağlayıcı anahtarlarını kısıtlayın
Ağ geçidi politikası gereklidir, ancak bir anahtarın ele geçirilmesi veya kötüye kullanılması durumunda sağlayıcı tarafındaki kısıtlamalar patlama yarıçapını azaltır. Gemini ve diğer bulut platformu API anahtarları için, mevcut olduğunda API/hizmet kısıtlamalarını ve uygun uygulama kısıtlamalarını kullanın. Sağlayıcı projeleri, çalışma alanları ve hizmet hesapları için, proje kapsamlı bir çalışma zamanı anahtarı yeterli olduğunda geniş kurumsal ayrıcalıklardan kaçının.
Öneri: her kimlik bilgisi sınıfı için sağlayıcı tarafında bir kısıtlama kontrol listesi bulundurun. Kontrol listesi, baskı altında atlanabilecek ayrı bir güvenlik görevi değil, ithalat onayı ve rotasyon onayının bir parçası olmalıdır.
Ödül: Sağlayıcı tarafındaki kısıtlamalar operasyonel yükü artırır. Yeni uç noktalar, model aileleri, bölgeler veya otomasyon özellikleri, politika ve kısıtlama değişiklikleri gerektirebilir. Bu, bir sızıntının ardından paylaşılan bir projedeki her iş yüküne tek bir anahtarın erişebileceğinin keşfedilmesine tercih edilir.
Yalnızca eklemeli bir kimlik bilgisi denetim günlüğü tutun
Bir denetim takibi, bir kimlik bilgisini kimin içe aktardığını, ne yapmasına izin verildiğini, hangi yönlendirme kararlarının onu seçtiğini, ne zaman başarısız olduğunu ve ne zaman döndürüldüğünü veya iptal edildiğini yanıtlamalıdır.
Bu etkinlikleri günlüğe kaydedin:
- Kimlik bilgisi oluşturuldu veya içe aktarıldı.
- İzin verilen uç noktalar, kiracı bağlama veya veri politikası dahil olmak üzere meta veriler değiştirildi.
- Durum kontrolü gerçekleştirildi ve sonuç kaydedildi.
- Bir istek için yönlendirme politikası tarafından seçilen kimlik bilgisi.
- Dahili bir hizmet kimliği tarafından istenen kimlik bilgisi şifresinin çözülmesi.
- Kimlik doğrulama, yetkilendirme, kota veya kısıtlama hatası nedeniyle sağlayıcı çağrısı başarısız oldu.
- Rotasyon başladı, trafik değişti, eski kimlik bilgileri iptal edildi.
- Acil durum devre dışı bırakma etkin veya temizlendi.
- Yönetici veya acil durum kimlik bilgilerine erişildi.
Denetim etkinliklerine ham kimlik bilgisi değerleri koymayın. Kimlik bilgisi kimliklerini, sağlayıcı hesap sınırlarını, istek izleme kimliklerini, aktör kimliklerini ve politika kararı nedenlerini kullanın. Yüksek hacimli çalışma zamanı trafiği için ayrıntılı şifre çözme telemetrisini örnekleyebilirsiniz ancak yönlendirme seçimi ve maliyet ilişkilendirme, faturalandırma ve olay müdahalesi için yeterince eksiksiz kalmalıdır.
Uygulama kontrol listesi
- Kimlik bilgisi sınıflandırması oluşturun ve sınıflandırılmamış içe aktarmaları reddedin.
- Tüm sağlayıcı sırlarını özel, şifrelenmiş bir kasaya taşıyın.
- Yönlendirme meta verilerini gizli materyalden ayrı olarak saklayın.
- Çalışma zamanı, yönetici, faturalandırma, değerlendirme ve BYOK kimlik bilgilerini ayrı yetkilendirme sınıfları haline getirin.
- BYOK kimlik bilgilerini kiracı ve sağlayıcı hesabının kaynağına bağlayın.
- Herhangi bir yukarı akış kimlik bilgisini seçmeden önce politika motoru onayını zorunlu kılın.
- Üretime uygunluktan önce hızlı ve güvenli durum kontrolleri gerçekleştirin.
- Kademeli trafik değişimi ve sağlayıcı tarafı iptali ile iki yuvalı rotasyonu kullanın.
- Mümkün olan her yerde sağlayıcı tarafı kısıtlamalarını uygulayın.
- İçe aktarma, kullanım, hatalar, rotasyon ve iptal için yalnızca ekleme denetim günlüklerini tutun.
- Yönetici kimlik bilgilerini çığır açan kontrollerin arkasında tutun: kısa TTL, adlandırılmış onay, güçlü günlük kaydı, çalışma zamanı kullanımı yok.
Harekete geçirilebilir sonuç
Ağ geçidi, komut dosyaları, CI işleri, değerlendirme donanımları ve iş ortağı otomasyonu tarafından halihazırda kullanılan tüm yukarı akış sağlayıcı kimlik bilgilerinin envanterini çıkararak başlayın. Her biri için bir sınıf, sahip, sağlayıcı hesap sınırı, kiracı bağlama, izin verilen uç noktalar, izin verilen model aileleri, rotasyon son tarihi ve acil durum devre dışı bırakma durumu atayın. Sınıflandıramadığınız her şey, net bir amacı olana kadar devre dışı bırakılmalı veya karantinaya alınmalıdır.
Ardından tek bir mimari kuralı uygulayın: Alt geliştiriciler, ağ geçidi kapsamlı anahtarlar alır; ağ geçidi tek başına yukarı akış sağlayıcı erişimini kontrol eder. Bu ayırma, sağlayıcılar, projeler, çalışma alanları ve BYOK müşterileri çoğalırken bile en az ayrıcalığı, kiracı ilişkilendirmesini, fatura doğruluğunu, veri politikası yönlendirmesini ve güvenli otomasyonu korumanıza olanak tanır.