AI API Ağ Geçitleri için Kontrol Düzlemi Mutabakatı

Bir AI API ağ geçidi, yukarı akış sağlayıcı kontrol düzlemleri sürüklenmeye devam ederken çalışma zamanı erişiminin birleşik görünmesini sağlayabilir. Ekipler genellikle çıkarım çağrılarını, faturalandırmayı, API anahtar yönetimini ve kullanım analitiğini ağ geçidinde merkezileştirir, ardından OpenAI projeyi, Anthropic çalışma alanını, Google Bulut projesini, Gemini anahtarı, hizmet hesaplarını, bütçeleri ve raporlama kapsamlarını manuel olarak yapılandırılacak şekilde bırakır. Bu, sessiz bir hata modu yaratır: Ağ geçidi, bir kiracı politikasının mevcut olduğunu söyler ancak sağlayıcı hesabı başka bir şeyi uygular veya bildirir.

Pratik model, kontrol düzlemi mutabakatıdır. Yukarı akış sağlayıcının yönetim nesnelerine envanter olarak davranın. Gözlenen envanteri ağ geçidindeki istenen kiracı politikasıyla karşılaştırın. Sapma bulguları üretin, düzeltmeleri onaylar yoluyla yönlendirin ve açıkça yüksek riskli durumlar için otomatik eylem rezervasyonu yapın.

Bu makalede gerçekler, öneriler ve tahminler birbirinden ayrılmıştır. Gerçekler, bugün belgelenen sağlayıcı davranışlarıdır. Öneriler, bir ağ geçidi operatörü için mimari tercihleridir. Çok sağlayıcılı yapay zeka yığınları olgunlaştıkça tahminler muhtemelen operasyonel baskılar oluşturacaktır.

Ağ Geçidi Benimsendikten Sonra Kayma Nasıl Görünüyor

Çalışma zamanı ağ geçitleri sorunun bir katmanını çözer: uygulamalar istekleri ortak bir uç noktaya gönderir, kiracılar kapsamı belirlenmiş ağ geçidi anahtarlarını alır ve kullanım tek bir deftere kaydedilir. Ancak yukarı akış sağlayıcı nesneleri hala önemlidir. Hangi proje veya çalışma alanının bir anahtara sahip olduğuna, hangi raporların harcamayı içerdiğine, hangi oran ve kaynak sınırlarının uygulanacağına ve hangi acil durum kontrollerinin mevcut olduğuna karar verirler.

Yaygın sapma örnekleri şunları içerir:

• Bir kiracı, ağ geçidinde bir OpenAI projesiyle eşlenir, ancak bir çalışma zamanı anahtarı hala paylaşılan bir varsayılan projeye aittir.
• Bir Anthropic API anahtarı yanlış çalışma alanında oluşturuldu ve amaçlanan alana taşınamıyor.
• Konsol akışının dışında bir Google API anahtarı oluşturuldu ve kısıtlamalar hiçbir zaman açık bir şekilde ayarlanmadığından sınırsız kalıyor.
• Sağlayıcı harcama eşiği, ağ geçidi kiracı bütçesinden daha düşük olduğundan, ağ geçidi beklemeden sağlayıcı tarafında hatalara neden oluyor.
• Sağlayıcı harcama eşiği, ağ geçidi politikasından daha yüksek olduğundan, sağlayıcı hesabını bir zayıf geri dönüş.
• Kullanım raporları boş veya devralınan çalışma alanı alanları içerdiğinden finans, sağlayıcı maliyetini ağ geçidi kiracılarıyla net bir şekilde uzlaştıramaz.
• Hizmet hesabı, ağ geçidi sahiplik modeline bağlı olmadığı için çalışanların işten ayrılmasından sonra hayatta kalır.

Risk yalnızca güvenlik değildir. Drift kesintileri ilişkilendirme, acil durum müdahalesi, maliyet kontrolü ve denetlenebilirlik.

Tasarımda Korunması Gereken Gerçekler

Sağlayıcı kontrol düzlemleri birbirinin yerine kullanılamaz. Bir uzlaştırıcı, operatörlerin verimli bir şekilde çalışabilmesi için yeterli veriyi normalleştirmeli ancak sağlayıcıya özgü anlambilimi korumalıdır.

OpenAI Projeler

Gerçek: OpenAI Projeler, kuruluşların işleri organize etmesine, erişimi ve sınırlamaları yönetmesine, hizmet hesaplarını hazırlamasına ve bir proje kapsamındaki kullanımı izlemesine olanak tanır. Kullanım projeye göre ayrılabilir ve proje başına harcama sınırları belirlenebilir.

Gerçek: OpenAI proje hizmeti hesapları, oluşturuldukları projeye özeldir. Oluşturulan gizli anahtar bir kez gösterilir ve onu kaybetmek, yeni bir anahtar oluşturulmasını gerektirir.

Gerçek: OpenAI API anahtarlar, Tümü, Kısıtlı ve Salt Okunur gibi izin düzeylerini destekler.Hizmet hesabı API anahtar izinleri, değiştirilmediği sürece varsayılan olarak tüm proje API kaynaklarına okuma ve yazma erişimine sahiptir.

Gerçek: OpenAI belgeleri, bir yardım makalesinde proje aylık harcama sınırlarını yumuşak eşikler olarak tanımlarken, sorun giderme materyali aynı zamanda project_spend_limit_exceeded gibi kesin sınır hatalarını da belgelemektedir. Bir ağ geçidi, yapılandırılmış her sağlayıcı harcama sınırının, her hesap yapılandırmasında eşzamanlı sabit sınır gibi davrandığını varsaymamalıdır.

Anthropic Çalışma Alanları

Gerçek: Anthropic Çalışma alanları API anahtarlarını, ekip erişimini ve maliyetleri düzenler. Ek çalışma alanları; üyeleri, hizmet hesaplarını, API anahtarları ve kaynak sınırlarını içerebilir.

Gerçek: API anahtarları, oluşturuldukları çalışma alanına bağlıdır ve çalışma alanları arasında taşınamaz. Anthropic, her istekte geçerli çalışma alanı ve organizasyon sınırlayıcılarını değerlendirir.

Gerçek: Varsayılan Çalışma Alanının özel raporlama davranışı vardır. Kullanım ve maliyet raporları boş bir workspace_id gösterebilir ve bu, bir ağ geçidinin sağlayıcı raporlarını kiracılarla eşleştirmeye çalıştığında önemlidir.

Gerçek: Anthropic Yönetici ve Analytics API'leri, organizasyon ve çalışma alanı yönetimini, API anahtarlarını, kullanım raporlarını, maliyet raporlarını ve ilgili analizleri kapsar, ancak erişim, yönetici anahtarlarına ve hesap veya rol uygunluğuna bağlıdır.

Google Bulut Ve Gemini Anahtarlar

Gerçek: Google Bulut API anahtar kılavuzu, kısıtlanmamış API anahtarların güvenli olmadığını söylüyor. API kısıtlamaları hangi API'lerin çağrılabileceğini, uygulama kısıtlamaları ise bir anahtarın nerede kullanılabileceğini sınırlar. Google, uygun olan yerlerde her ikisinin de ayarlanmasını önerir.

Gerçek: Google Bulut belgelerinde, konsol aracılığıyla oluşturulan API anahtarların en az bir API kısıtlaması gerektirdiği, gcloud veya REST aracılığıyla oluşturulan anahtarların ise kısıtlamalar açıkça belirtilmediği sürece sınırsız olduğu belirtiliyor.

Gerçek: Google Geliştiriciler için AI belgeleri Gemini API'nin standart anahtarlardan yetkilendirmeye geçtiğini söylüyor anahtarlar, kısıtlamasız standart anahtarlar reddedilir ve hizmet kesintisini önlemek için standart anahtarların Eylül 2026'dan önce yetkilendirme anahtarlarına taşınması gerekir.

Gerçek: Google Uyarı içeren Bulut Faturalandırma bütçeleri harcamayı otomatik olarak sınırlamaz. Programatik Pub/Sub bildirimleri, maliyet kontrolü yanıtlarını otomatikleştirebilir ancak Pub/Sub teslimatı en az bir kez yapılır ve mesajlar sıra dışı olarak gelebilir.

Referans Mimarisi

Öneri: Mutabakatı, sıcak istek yolunun içinde değil, çalışma zamanı ağ geçidinin yanında bir kontrol düzlemi hizmeti olarak oluşturun.Sağlayıcı yönetici yüzeylerini okumalı, bunları ağ geçidi kiracı politikasıyla karşılaştırmalı ve sapma olayları yaymalıdır.

Pratik bir mimari beş bölümden oluşur:

• İstenen durum deposu: ağ geçidi kiracı politikası: kiracı, sahip, izin verilen sağlayıcılar, model profilleri, bütçe politikası, ücret politikası, izin verilen yukarı akış projeleri veya çalışma alanları, anahtar sahipliği ve acil durum durum.
• Gözlemlenen durum envanteri: Yönetici API'leri, faturalandırma dışa aktarmaları, konsol dışa aktarmaları veya planlanmış taramalar yoluyla keşfedilen sağlayıcı nesneleri.
• Sağlayıcı bağdaştırıcıları: OpenAI, Anthropic, Google Bulut ve yerel tanımlayıcıları ve diğer sağlayıcıya özel toplayıcılar semantics.
• Drift motoru: sağlayıcı durumunu sessizce değiştirmek yerine bulgular üreten deterministik karşılaştırmalar.
• İyileştirme iş akışı: yüksek riskli sürüklenme için bildirimler, onaylar, sohbet uyarıları ve dar kapsamlı otomatik eylemler.

Ağ geçidi, kiracının kaynağı olmaya devam ediyor faturalandırma gerçeği. Sağlayıcı maliyet ve kullanım raporları, ödeme girdileri ve anormallik sinyalleri haline gelir. Bu ayrım önemlidir çünkü sağlayıcı raporları gecikebilir, farklı boyutlar kullanabilir veya ağ geçidi kiracılarıyla net bir şekilde eşlenmeyen raporlama alanlarını açığa çıkarabilir.

Envanteri Normalleştirin, Anlam Uzak Değil

Öneri: Normalleştirilmiş bir envanter tablosu kullanın, ancak sağlayıcıya özgü alanları ekleyin. OpenAI projesi, Anthropic çalışma alanı ve Google Bulut projesinin aynı nesne olduğunu iddia etmeyin.

Yararlı bir envanter modeli şunları içerir:

• sağlayıcı: openai, antropik, google, azure veya başka bir bağdaştırıcı name.
• provider_account_id: kuruluş, faturalandırma hesabı veya bulut hesabı tanımlayıcısı.
• container_type: proje, çalışma alanı, bulut projesi, klasör veya hesap.
• container_id: sağlayıcıya özgü proje veya çalışma alanı identifier.
• container_name: sağlayıcıdan insan tarafından okunabilen etiket.
• tenant_id: eşlenen ağ geçidi kiracısı veya eşlenmediğinde null.
• service_account_id: sağlayıcı hizmet hesabı veya iş yükü kimliği burada mevcut.
• api_key_id: anahtar parmak izi, anahtar kimliği veya karma anahtar tanımlayıcı.Ham sağlayıcı sırlarını bu tabloda saklamayın.
• key_scope: proje, çalışma alanı, organizasyon, uygulama kısıtlaması, API kısıtlama veya eşdeğer sağlayıcıya özgü kapsam.
• izinler: yerel izin düzeyi, rol bağlama, kısıtlı yetenek listesi veya okuma/yazma state.
• model_allowlist: anahtarın ulaşabileceği modeller veya API aile; burada sağlayıcı bu denetimi açığa çıkarır.
• rate_policy: gözlemlenen sağlayıcı sınırı ve desteklemesi beklenen ağ geçidi politikası.
• spend_policy: gözlemlenen sağlayıcı eşiği veya bütçe ve ağ geçidi kiracı bütçe politikası.
• reporting_scope:, bilinen boş veya devralınan alanlar dahil, sağlayıcı raporlarında beklenen boyutlar.
• last_seen_at: en son taramadan zaman damgası.
• owner: ağ geçidi kiracısı, ekip, hizmet sahibi veya insan sahibi.
• kaynak: yönetici API, faturalandırmayı dışa aktarma, konsolu dışa aktarma, yapılandırmayı içe aktarma veya manuel doğrulama.

Bu tablo ekleme dostu olmalıdır. Operatörlerin geçmişe ihtiyacı vardır: bir anahtarın ilk kez ne zaman göründüğü, ne zaman görünmeyi bıraktığı, izinlerinin ne zaman değiştiği ve değişikliği hangi tarayıcının gözlemlediği.

İstenen Durumu Açıkça Tanımlayın

Öneri: Mutabakat yalnızca istenen durumun somut olması durumunda işe yarar. Kiracı A'nın Anthropic kullanabileceği gibi bir politika çok belirsizdir. Kiracı A'nın çalışma alanı ws_123, hizmet hesabı svc_billing_prod kullanması gerekir, insana ait çalışma zamanı anahtarları kullanılmaz, model profili desteği hızlıdır ve sağlayıcı harcama eşiği ağ geçidi bütçesinin yüzde 80 ila 110'u arasında olmalıdır gibi bir politika üzerinde işlem yapılabilir.

İstenen durum şunları içermelidir:

• Her biri tarafından hangi yukarı akış kapsayıcıları kullanılabilir kiracı.
• Kiracının ağ geçidine ait kimlik bilgilerini, kiracı BYOK kimlik bilgilerini veya her ikisini birden kullanıp kullanmadığı.
• Çalışma zamanı anahtarlarının hizmet hesabına ait olması gerekip gerekmediği.
• Hangi sağlayıcı API'lerine ve modellerine izin verilir.
• Kabul edilebilir maksimum ve minimum yukarı akış harcama eşikleri.
• Beklenen sağlayıcı raporlaması ödeme için boyutlar.
• Google anahtarlar için gerekli uygulama ve API kısıtlamalar.
• Her sağlayıcı ve kiracı için acil durum devre dışı bırakma davranışı.

İstenen durumu sürümlendirilmiş bir politika tablosunda saklayın. Her sapma bulgusu, karşılaştırma için kullanılan politika versiyonuna referans vermelidir. Bu, politika değişiklikleri birçok yeni bulgu oluşturduğunda incelemeleri ve geri alma işlemlerini mümkün kılar.

Operatörlerin Harekete Geçebileceği Drift Sınıflarını Uygulayın

Öneri: Yazılan drift bulgularını yayınlayın. Genel uyumsuzluk uyarılarından kaçının.Operatörler neyin bozulduğunu, neden önemli olduğunu ve hangi eyleme izin verildiğini bilmelidir.

Yararlı sürüklenme sınıfları şunları içerir:

• missing_container: kiracı politikası, var olmayan veya tarayıcı tarafından görülemeyen bir sağlayıcı projesi veya çalışma alanı bekler.
• unmapped_container: bir sağlayıcı projesi, çalışma alanı veya bulut projesi mevcuttur ancak kiracı eşlemesi yok.
• wrong_container: kiracı trafiği tarafından kullanılan bir anahtar, politikanın izin verdiğinden farklı bir projeye veya çalışma alanına aittir.
• stale_key: bir sağlayıcı anahtarı, ağ geçidi trafiğinde belirli bir süre görülmedi ancak etkin kaldı upstream.
• orphaned_owner: Bir anahtar veya hizmet hesabı, devre dışı bırakılmış bir kullanıcıya veya eşlenmemiş kimliğe aittir.
• excessive_permission: Bir anahtar, ağ geçidi politikasının gerektirdiğinden daha geniş sağlayıcı izinlerine sahiptir.
• unrestricted_google_key: a Google anahtarında gerekli API kısıtlamalar, uygulama kısıtlamaları veya Gemini uyumlu yetkilendirme taşıma durumu bulunmuyor.
• limit_below_policy: sağlayıcı sınırlarının, ağ geçidi politikasının beklediğinden önce trafiği engellemesi muhtemeldir.
• limit_above_policy: sağlayıcı sınırları, bir anahtar olarak hizmet edemeyecek kadar hoşgörülüdür backstop.
• reporting_unreconcilable: sağlayıcı kullanımı veya maliyet raporları kiracı, anahtar, proje veya çalışma alanıyla temiz bir şekilde eşlenemiyor.
• scanner_blind: gerekli yönetici API'leri veya rolleri eksik, bu nedenle uzlaştırıcı bir hak talebinde bulunamaz.

Her bulgu şunları içermelidir: önem derecesi, güven, etkilenen kiracı, sağlayıcının yerel tanımlayıcıları, ilk gözlem zamanı, son gözlem zamanı, önerilen eylem, izin verilen otomatik eylemler ve geri alma meta verileri.

Çözüm: Kuru Başlat, Dar Bir Şekilde Otomatikleştir

Öneri: Mutasyondan önce bulguları varsayılan olarak prova yapın. Sağlayıcı yönetici kimlik bilgileri güçlüdür. Kötü bir eşleme, üretim iş yüklerini devre dışı bırakabilir, ilişkilendirmeyi silebilir veya pahalı bir kesinti oluşturabilir.

İki aşamalı bir model işe yarar:

• Bildirim ve bildirim: eksik sahip etiketleri, eşlenmemiş raporlama alanları veya harcama eşiklerinin biraz dışında olması gibi düşük riskli veya belirsiz sapmalar için Policy.
• Önceden onaylanmış otomatik eylem: Sızdırılan anahtarlar, devre dışı bırakılan kullanıcıların sahip olduğu anahtarlar, kısıtlanmamış Gemini özellikli anahtarlar veya ağ geçidinde zaten devre dışı bırakılmış kiracılara bağlı anahtarlar gibi dar yüksek riskli durumlar için.

Otomasyon mümkün olduğunda geri döndürülebilmelidir. Örneğin, bir ağ geçidi anahtarının devre dışı bırakılmasının tersine çevrilmesi, bir yukarı akış anahtarının silinmesinden daha kolaydır. Kullanıma sunulduktan sonra bir yukarı akış sağlayıcı anahtarının döndürülmesi gerekli olabilir, ancak bu, aşağı yönde dağıtım koordinasyonunu gerektirir.Ağ geçidi bütçesinin sıfıra düşürülmesi anında gerçekleşir ve denetlenebilirken, sağlayıcı bütçe uyarıları gecikebilir veya eşzamansız davranabilir.

Acil Durum Kapatma Çalıştırma Kitabı

Öneri: Acil durum sağlayıcı kapatma çalıştırma kitabını ihtiyaç duyulmadan önce yazın. Hem ağ geçidi denetimlerini hem de sağlayıcı denetimlerini kapsamalıdır.

Pratik bir sıra şöyledir:

1. Yeni çalışma zamanı isteklerinin ağ geçidinde durması için etkilenen ağ geçidi anahtarlarını devre dışı olarak işaretleyin.
2. Kiracı ağ geçidi bütçesini veya rezervasyon harcama sınırını sıfıra ayarlayın.
3. Kiracının etkilenen sağlayıcıya veya model profiline yönlendirmesini engelleyin.
4. İptal edin, devre dışı bırakın veya döndürün. Desteklendiği yerlerde yukarı akış sağlayıcı anahtarları.
5. Varsa ve hesap yapılandırması için yararlıysa, sağlayıcı tarafı eşiklerini düşürün.
6. Her işlemi aktör, zaman damgası, neden, sağlayıcı nesnesi ve geri alma talimatıyla kaydedin.
7. Yayılma gecikmelerini bildirdikten sonra sağlayıcı tarafı kullanımı ile maliyeti uzlaştırın.
8. Olay sonrası sapma incelemesini açın: nesne yönetilmez hale geldi ve hangi politika kontrolünün bunu daha önce yakalaması gerekirdi?

Bu sıra, öncelikle ağ geçidindeki trafiği kasıtlı olarak durdurur. Sağlayıcı kontrolleri hâlâ önemlidir ancak hız, kullanılabilirlik ve yaptırım anlambilimi açısından farklılık gösterebilir.

Ödünleşmeler

Otomatik mutabakat sapmayı azaltır ancak yönetici kimlik bilgileri gerektirir. Öneri: Yönetici kimlik bilgilerini çalışma zamanı kimlik bilgilerinden ayırın, bunları ayrı bir kasa yolunda saklayın, mutasyon ayrıcalıklarını kısıtlayın ve her okuma ve yazmayı denetleyin.

Kiracı başına bir yukarı akış projesi veya çalışma alanı, ilişkilendirmeyi ve patlama yarıçapı kontrolünü iyileştirir. Takas; nesne yayılımı, sağlayıcı sınırları, operasyonel ek yük ve paylaşılan önbellek, sağlanan kapasite veya havuzlanmış aktarım hızı stratejilerine yönelik zorluklardır.

Sağlayıcı sınırları yararlı bir destek sağlar ancak ağ geçidi tarafı bütçe rezervasyonunun yerini almaz. Sağlayıcı sınırları esnek, eşzamansız, plana bağımlı olabilir veya istekler ve raporlarda farklı şekilde değerlendirilebilir.

Sık taramalar sapmayı daha hızlı tespit eder, ancak yönetici API kullanımını, kota basıncını ve uyarı hacmini artırır. Daha iyi bir model, mümkün olduğu durumlarda olaya dayalı güncellemeler ve eksiksizlik için planlanmış mutabakattır.

Normalleştirme, kontrol panellerini kullanılabilir hale getirir, ancak aşırı normalleştirme, önemli farklılıkları gizler. Yerel sağlayıcı alanlarını bulgularda ve raporlarda görünür tutun.

Tahminler

Tahmin: AI API ağ geçidi operatörleri, bulut IAM ve faturalandırma hesabı yapılandırmasına benzer şekilde, sağlayıcı yönetici nesnelerini giderek daha fazla düzenlenmiş yapılandırma olarak ele alacak. Çalışma zamanı proxy'si tek başına finans, güvenlik veya platform ekiplerini birçok kiracı genelinde harcama yapıp ölçeğe eriştikten sonra tatmin etmeyecektir.

Tahmin: Temel modeller değişmeye devam edecek. Gemini standart anahtarlardan yetkilendirme anahtarlarına geçiş gözle görülür bir örnektir. Sağlayıcının yerel nesne türünü, taşıma durumunu ve son görülen kaynağı depolayan mutabakat sistemleri, bu değişiklikleri yalnızca ham bir sır ve sağlayıcı adını depolayan sistemlerden daha iyi işleyecektir.

Tahmin: Sağlayıcı raporları uzlaşma için faydalı olmaya devam edecek ancak gerçek zamanlı uygulama için eşit olmayan bir şekilde çalışacaktır.Kendi istek defterini, rezervasyon modelini ve kiracı ilişkilendirmesini tutan ağ geçitleri, sağlayıcı faturalarının dışa aktarılmasını bekleyen ağ geçitlerinden daha tahmin edilebilir olacaktır.

Uygulama Kontrol Listesi

• Kiracı-sağlayıcı arası eşlemeler için istenen durum politikası tablosu oluşturun.
• Sağlayıcıya özgü tanımlayıcılar ve karma anahtarla gözlemlenen bir envanter tablosu oluşturun Kimlikler.
• Önce salt okunur sağlayıcı bağdaştırıcıları oluşturun.
• Tarayıcı hatalarını gizlemek yerine bulgu olarak sınıflandırın.
• Yazılan sürüklenme olaylarını ciddiyet ve güvenle yayınlayın.
• Bulguları bildirimlere, uyarılara veya onay sıralarına yönlendirin.
• Otomatik eylemi yalnızca dar, önceden onaylanmış yüksek riskli durumlar için etkinleştirin sınıflar.
• Yönetici kimlik bilgilerini çalışma zamanı kimlik bilgilerinden ayrı tutun.
• Anlaşma ve anormallik tespiti için ağ geçidi defter kayıtlarını sağlayıcı raporlarına ekleyin.
• Güvenmeden önce üretim dışı bir kiracıda acil durum kapatmayı test edin.

Uygulamaya Uygun Sonuç

Çıkarım çağrılarını ortak bir ağ üzerinden yönlendirmekle yetinmeyin uç nokta. Yukarı yöndeki kontrol düzlemleri sürüklenirse, ağ geçidi yine de ilişkilendirmeyi kaybedebilir, eski anahtarları kaçırabilir, sağlayıcı harcama davranışını yanlış okuyabilir veya acil bir durumda başarısız olabilir.

En güçlü model basittir: ağ geçidine istenen kiracı politikasını yazın, gözlemlenen sağlayıcı nesnelerini tarayın, sağlayıcıya özgü anlamı koruyun, yazılan sapma bulgularını yayınlayın ve kontrollü bir iş akışı aracılığıyla sorunu düzeltin. Salt okunur olarak başlayın. Envanteri kanıtlayın. Ardından, yalnızca riski düzelttikleri sapmadan daha düşük olan eylemleri otomatikleştirin.

İlgili okuma

• ayrı çalışma zamanı, yönetici, faturalandırma ve BYOK kimlik bilgileri
• ağ geçidi tarafı faturalandırma defteri ve bütçe rezervasyon
• çıkış ve hizmet hesabı sahipliği kuralları