AI API Ağ Geçitleri için Kontrol Düzlemi Denetim Yolları: Olaylar Sırasında Anahtarı, Kiracıyı ve Harcama Değişikliklerini Yeniden Oluşturma

Yapay zeka harcamalarında ani artışlar olduğunda veya bir anahtar sızıntısı olduğunda çalışma zamanı telemetrisi yeterli değildir. Güvenlik ve FinOps ekiplerinin kontrol düzlemi değişikliklerini yeniden yapılandırması gerekiyor: API anahtarını kimin oluşturduğu veya değiştirdiği, hangi kiracının veya projenin etkilendiği, hangi yukarı akış kimlik bilgilerinin dahil olduğu, ani artıştan önce bir harcama sınırının değişip değişmediği ve sınırlama sırasında nelerin iptal edildiği.

Pratik model, AI API ağ geçitleri için normalleştirilmiş, salt eklemeli bir denetim olayı hattıdır. Çalışma zamanı izlemeleri bir model çağrısının ne yaptığını yanıtlar. Kontrol düzlemi denetim günlükleri, erişimi, bütçeleri, yönlendirmeyi, anahtarları, hizmet hesaplarını, kiracı durumunu, model profillerini, kredileri ve sağlayıcı kimlik bilgilerini kimin değiştirdiğini yanıtlar.

Gerçekler, öneriler ve tahminler

Gerçekler: Bazı AI sağlayıcıları, kuruluş yapılandırmasını, projeleri, API anahtarlarını, hizmet hesaplarını, çalışma alanlarını, üyeleri, kullanımı ve maliyet raporlamasını kapsayan yönetim veya denetim yüzeylerini açığa çıkarır. Kapsam sağlayıcıya, hesap türüne ve dağıtım bağlamına göre değişir. OpenTelemetry ayrıca olaylar ve GenAI telemetri nitelikleri için genel anlam kuralları sağlarken, yakalanan giriş ve çıkış içeriğinin hassas veriler içerebileceği konusunda uyarıda bulunur.

Öneriler: Ağ geçidini, ağ geçidine özgü kavramlar için standart denetim katmanı olarak değerlendirin: sanal anahtarlar, kiracılar, bayi müşterileri, cüzdanlar, harcama sınırları, model profilleri, İş Ortağı API otomasyonu, yukarı akış kimlik bilgisi havuzları ve acil karantina eylemleri. Mümkün olduğu durumlarda sağlayıcı yönetici olaylarını ilişkilendirin, ancak her yukarı yöndeki konsol eyleminin gözlemlenebilir olduğunu varsaymak yerine boşlukları açıkça işaretleyin.

Tahminler: Yapay zeka kontrol düzlemi denetimleri, özellikle ekiplerin model erişimini yeniden sattığı, müşteri temel hazırlığını otomatikleştirdiği veya yüksek riskli hizmet hesaplarını yönettiği durumlarda kurumsal yapay zeka ağ geçitleri için standart bir gereksinim haline gelecektir. Sağlayıcı denetim API'leri gelişecek ancak sağlayıcı kaynak kavramları farklı kalacağı için ağ geçitlerinin yine de kendi normalleştirilmiş olay modeline ihtiyacı olacak.

Önce araştırma sorularını tanımlayın

Bir denetim izi, bir olay sırasında yanıt verenlerin çalıştıracağı sorgulardan geriye doğru tasarlanmalıdır. Kısa bir soru listesiyle başlayın:

• Anormallikten önce hangi anahtarlar oluşturulmuş, güncellenmiş, yeniden etkinleştirilmiş veya iptal edilmişti?
• Her bir anahtar hangi kiracıyı, müşteriyi, projeyi, çalışma alanını, cüzdanı veya maliyet merkezini etkiledi?
• Değişikliği hangi aktör yaptı: gerçek yönetici, hizmet hesabı, İş Ortağı API müşterisi, SCIM süreci, destek operatörü veya planlanmış otomasyon?
• Hangi kimlik doğrulama yöntemi kullanıldı: TOA oturumu, yönetici API jetonu, hizmet hesabı, kırılma noktası hesabı veya web kancası tekrarı?
• Kullanım artmadan önce harcama sınırları, model erişimi, yönlendirme profilleri, ücret sınırları veya kredi bakiyeleri değişti mi?
• Sonuç olarak ortaya çıkan trafiği hangi yukarı akış sağlayıcı kimlik bilgisi, proje, hizmet hesabı veya çalışma alanı işledi?
• Hangi sınırlama eylemleri gerçekleşti ve bunlar tamamlandı mı?

Ağ geçidinde zaten API anahtar yönetimi, faturalandırma, ekip kontrolleri ve sağlayıcı yönlendirmesi varsa, denetim takibi başka bir yalıtılmış günlük akışı oluşturmak yerine bu sistemlere katılmalıdır.

Normalleştirilmiş bir denetim etkinliği şeması kullanın

Rastgele JSON blob'ları saklamayın ve analistlerin bunları daha sonra yorumlayabileceğini umun. Her kontrol düzlemi etkinliği için kararlı bir şema kullanın, ardından kontrollü bir ad alanı altında kaynağa özgü uzantılara izin verin.

Temel alanlar

{
  "event_id": "evt_01J...",
  "occurred_at": "2026-09-09T13:51:22.481Z",
  "ingested_at": "2026-09-09T13:51:23.040Z",
  "source_system": "gateway_admin_api",
  "action": "key.issued",
  "result": "success",
  "risk_level": "high",
  "actor_type": "service_account",
  "actor_id": "sa_partner_provisioner_42",
  "actor_org_id": "org_acme_reseller",
  "auth_method": "partner_api_key",
  "resource_type": "virtual_api_key",
  "resource_id": "vk_123",
  "tenant_id": "tenant_789",
  "customer_id": "cust_456",
  "project_id": "proj_support_bot",
  "workspace_id": null,
  "key_id_hash": "sha256:...",
  "upstream_provider": "provider_a",
  "upstream_credential_id_hash": "sha256:...",
  "request_correlation_id": "req_abc",
  "idempotency_key_hash": "sha256:...",
  "ip_address": "203.0.113.10",
  "user_agent_hash": "sha256:...",
  "policy_before_hash": null,
  "policy_after_hash": "sha256:..."
}

Şema hem insanların okuyabileceği araştırmayı hem de makine birleştirmelerini desteklemelidir. En önemli alanlar eylem, aktör, kaynak, kiracı, anahtar parmak izi, yukarı akış kimlik bilgisi kökeni, korelasyon kimliği ve politika anlık görüntüsü karmalarıdır.

Neden ham değerler yerine karmalar kullanılıyor?

Denetim yollarının sırlara değil, kararlı birleştirme noktalarına ihtiyacı vardır. Sanal anahtarlar ve yukarı akış kimlik bilgileri için deterministik bir karma veya parmak izi saklayın. Düzenlenen anlık görüntünün yalnızca yetkili denetim görüntüleyicileri tarafından kullanılabileceği şekilde, politika anlık görüntülerinin karmalarını depolayın. Bu, araştırmacıların, dışa aktarılan her günlükte ham kimlik bilgilerini veya hassas dahili yapılandırmayı açığa çıkarmadan bir harcama politikasının, yönlendirme profilinin veya anahtar kapsamının değiştiğini kanıtlamasına olanak tanır.

Çalışma zamanı telemetrisini kontrol düzlemi denetim günlüklerinden ayırın

Yapay zeka ağ geçitleri genellikle çalışma zamanı ölçümlerini toplar: istek kimliği, model, sağlayıcı, jeton sayıları, gecikme, maliyet tahmini, nihai maliyet, önbellek davranışı, güvenlik sinyalleri ve hata durumu. Bu kayıtlar AI API kullanım analizleri için gereklidir, ancak kontrol düzlemi denetim etkinlikleriyle aynı şey değildir.

Bir çalışma zamanı kaydı şunu söyleyebilir:

{
  "request_id": "req_model_001",
  "tenant_id": "tenant_789",
  "key_id_hash": "sha256:...",
  "model_profile_id": "profile_support_premium",
  "provider": "provider_a",
  "started_at": "2026-09-09T13:56:10Z",
  "estimated_cost_usd": "0.18",
  "settled_cost_usd": "0.22",
  "status": "success"
}

Kontrol düzlemi denetim etkinliği şunları söylüyor:

{
  "event_id": "evt_profile_002",
  "action": "model_profile.changed",
  "tenant_id": "tenant_789",
  "resource_id": "profile_support_premium",
  "actor_id": "sa_partner_provisioner_42",
  "occurred_at": "2026-09-09T13:54:03Z",
  "policy_before_hash": "sha256:old",
  "policy_after_hash": "sha256:new",
  "risk_level": "high"
}

Her iki kayıt da paylaşılan bir birleştirme stratejisine ihtiyaç duyar ancak farklı saklama, erişim kontrolleri ve yük kurallarına sahip olmalıdır. Kontrol düzlemi denetim günlükleri örneklenmemelidir. Kullanım ve faturalandırma defterlerinin eksiksiz kalması gerekirken, gözlemlenebilirlik maliyeti için çalışma zamanı izleri örneklenebilir.

Ağ geçidi tarafından verilen sanal anahtarları birleştirme noktası yapın

Çok kiracılı bir ağ geçidinde sanal anahtar en kullanışlı araştırma aracıdır. Ağ geçidi tarafından verilen bir anahtar, kiracıya, müşteriye, kullanıcıya, hizmet hesabına, model profiline, harcama sınırına, yönlendirme politikasına, ücret sınırına, yukarı akış sağlayıcı kimlik bilgilerine ve faturalandırma cüzdanına işaret edebilir.

Bir olay sırasında müdahale ekipleri anahtar parmak izinden şuraya geçiş yapabilmelidir:

• anahtarın sahibi olan kiracı ve müşteri;
• bunu oluşturan veya en son değiştiren aktör;
• zamanın her noktasında etkin olan kapsam, model profili ve harcama sınırı;
• bu anahtarla yapılan çağrılar için kullanılan yukarı akış sağlayıcısının kimlik bilgileri;
• bu anahtar tarafından oluşturulan kullanım ve maliyet kayıtları;
• iptal, rotasyon, karantina ve restorasyon etkinlikleri.

Bu özellikle İş Ortağı API otomasyonu aracılığıyla müşteri kapsamlı anahtarlar yayınlayan platformlar için önemlidir. İstikrarlı bir sanal anahtar parmak izi olmadan, temel hazırlık etkinlikleri, kredi değişiklikleri, kiracı yapılandırması ve çalışma zamanı kullanımı ayrı hikayeler haline gelir.

Birinci sınıf İş Ortağı API etkinliğini yakalayın

İş ortağı API'leri, eskiden yönetici konsolunda manuel olarak gerçekleştirilen işlemleri otomatikleştirdikleri için denetim riski oluşturur. Bunlar aynı zamanda ticari anlaşmazlıklara da yol açar: Satıcı, kredileri kimin doldurduğunu, müşteri anahtarının ne zaman verildiğini veya kiracının bütçeyi neden aştığını sorabilir.

En azından bu etkinlikleri birinci sınıf denetim eylemleri olarak kaydedin:

• customer.created
• customer.updated
• key.issued
• key.scope_changed
• key.revoked
• credit.topup.requested
• credit.topup.settled
• spend_limit.changed
• rate_limit.changed
• model_profile.changed
• tenant.quarantined
• tenant.unquarantined
• webhook.replayed
• idempotency_key.reused

Parayla ilgili etkinlikler için tam ondalık tutarları, para birimini, önceki bakiyeyi, yeni bakiyeyi, harici ödeme referansını ve ödeme durumunu saklayın. Eşgüçlü işlemler için, eşgüçlülük anahtar karmasını ve kurallı işlem kimliğini saklayın, böylece yinelenen yeniden denemeler daha sonra açıklanabilir.

Sağlayıcı yönetici günlüklerini bunlara bağlı kalmadan ilişkilendirin

Sağlayıcı kontrol düzlemleri tek tip değil. Bazı sağlayıcılar kuruluş ayarları, projeler, anahtarlar, kullanıcılar, hizmet hesapları, çalışma alanları, kullanım ve maliyetler için denetim günlüklerini ve yönetici API'lerini açığa çıkarır. Diğerleri ise konsolun dışa aktarılmasını, bulut denetim günlüklerini, faturalandırma raporlarını veya manuel mutabakatı gerektirir. API'ler mevcut olsa bile kaynak adları ve saklama politikaları farklılık gösterir.

Bir ağ geçidi denetim mimarisi bu nedenle yetenek bayraklarını kullanmalıdır:

{
  "provider": "provider_a",
  "capabilities": {
    "admin_audit_api": true,
    "project_key_inventory": true,
    "service_account_inventory": true,
    "workspace_cost_report": false,
    "credential_last_used_at": true
  }
}

Sağlayıcı etkinliklerini içe aktarırken, bunları aynı denetim tablosunda normalleştirin ancak kaynak meta verilerini koruyun:

• source_system: provider_admin_api, provider_console_export, cloud_audit_log, billing_report
• source_event_id: mevcutsa orijinal sağlayıcı etkinlik kimliği
• source_resource_path: orijinal proje, çalışma alanı, anahtar veya hizmet hesabı yolu
• provider_capability_gap: ağ geçidi doğrudan bir etkinlik almak yerine bağlamı çıkardığında doğru

Amaç mükemmel görünürlük iddiasında bulunmak değil. Amaç, olay raporlarının gözlemlenen gerçekleri, çıkarsanan ilişkilerden ayırt edebilmesi için kapsamı ve boşlukları açık hale getirmektir.

Yalnızca ekleme depolama ve düzeltme etkinliklerini kullan

Denetim etkinlikleri değiştirilemez olmalıdır. Bir olay yanlış ayrıştırıldıysa orijinal satırı düzenlemek yerine bir düzeltme olayı yazın. Bu, faturalandırma anlaşmazlıkları, bayi kredisi anlaşmazlıkları, sızdırılan anahtar araştırmaları ve olay sonrası incelemeler için önemlidir.

Pratik bir depolama tasarımında üç katman kullanılır:

• Sıcak sorgu deposu: kiracı, aktör, eylem, anahtar karması, istek korelasyon kimliği ve hızlı olay sorguları için occurred_at tarafından dizine eklenmiştir.
• Değişmez arşiv: yalnızca eklenen nesne depolama alanı veya saklama kontrolleri ve bütünlük kontrolleri içeren defter tarzı tablo.
• Akışı dışa aktar: Kurumsal güvenlik iş akışları için SIEM, depo veya olay veri yolu aktarımı.

Dışa aktarma faydalıdır ancak SIEM'i tek yetkili mağaza yapmayın. Genel bir SIEM, sanal anahtar, kiracı cüzdanı, model profili, satıcı müşterisi veya yukarı akış kimlik bilgisi havuzu gibi ağ geçidine özgü kavramları anlamayabilir. Ağ geçidi defterini yetkili tutun ve normalleştirilmiş kopyaları dışa aktarın.

Bir olay sorgu paketi oluşturun

Olay müdahalesi geçici SQL ile başlamamalıdır. En yaygın senaryolar için kayıtlı sorguları önceden oluşturun.

1. Harcama artışından önce oluşturulan anahtarlar

SELECT occurred_at, actor_type, actor_id, tenant_id, customer_id,
       resource_id, key_id_hash, auth_method, ip_address
FROM audit_events
WHERE action IN ('key.issued', 'key.reenabled', 'key.scope_changed')
  AND tenant_id = :tenant_id
  AND occurred_at BETWEEN :spike_start - INTERVAL '24 hours' AND :spike_start
ORDER BY occurred_at;

2. Anormal kullanım öncesinde harcama sınırı değişiklikleri

SELECT occurred_at, actor_id, resource_id,
       policy_before_hash, policy_after_hash, request_correlation_id
FROM audit_events
WHERE action = 'spend_limit.changed'
  AND tenant_id = :tenant_id
  AND occurred_at BETWEEN :window_start AND :window_end
ORDER BY occurred_at;

3.

SELECT occurred_at, action, actor_id, upstream_provider,
       upstream_credential_id_hash, source_system
FROM audit_events
WHERE upstream_credential_id_hash IS NOT NULL
  AND occurred_at BETWEEN :window_start AND :window_end
ORDER BY occurred_at;

4. Pahalı rotalara yönelik model profili promosyonları

SELECT occurred_at, actor_id, tenant_id, resource_id,
       policy_before_hash, policy_after_hash
FROM audit_events
WHERE action = 'model_profile.changed'
  AND risk_level IN ('medium', 'high', 'critical')
  AND occurred_at BETWEEN :window_start AND :window_end;

5. Muhafaza doğrulaması

SELECT occurred_at, action, actor_id, tenant_id, resource_type,
       resource_id, result
FROM audit_events
WHERE tenant_id = :tenant_id
  AND action IN ('key.revoked', 'tenant.quarantined',
                 'upstream_credential.rotated', 'spend_limit.changed')
  AND occurred_at >= :containment_start
ORDER BY occurred_at;

Bu sorgular, rol tabanlı erişime sahip güvenlik, platform ve FinOps ekiplerinin kullanımına açık olmalıdır. Her araştırmacının politikanın anlık görüntü ayrıntılarını veya ödeme referanslarını görmesi gerekmez.

Örnek inceleme zaman çizelgesi

Bu, verilerin şeklini gösteren kurgusal bir zaman çizelgesidir, gerçek bir olay değildir:

• 13:48 — spend_limit.changed: kiracının aylık sınırı, önceki politika karmasından yeni bir politika karmasına yükseltildi.
• 13:51 — key.issued: İş Ortağı API hizmet hesabı tarafından oluşturulan yeni müşteri kapsamlı anahtar.
• 13:54 — model_profile.changed: kiracı yönlendirme profili, daha pahalı bir model sınıfına izin verecek şekilde değiştirildi.
• 13:56 — yeni anahtar parmak izi için çalışma zamanı kullanımı artmaya başlıyor.
• 14:05 — kiracı için harcama anormallik uyarısı tetiklenir.
• 14:09 — key.revoked: şüpheli sanal anahtar iptal edildi.
• 14:13 — upstream_credential.rotated: sağlayıcı kimlik bilgileri sınırlama olarak değiştirildi.

Bu zaman çizelgesi, yönetim amacını, otomatik temel hazırlığı, yönlendirme politikasını, çalışma zamanı maliyetini ve sınırlamayı birbirine bağladığı için kullanışlıdır. Varsayılan olarak ham istemlerin saklanmasını gerektirmez.

Gizlilik ve saklama konusunda ödünler

Daha fazla denetim ayrıntısı adli tıpı iyileştirir ancak gizlilik ve uyumluluk riskini artırabilir. Ham istemler veya tam istek gövdeleri yerine meta verileri, karmaları, düzeltilmiş politika anlık görüntülerini ve korelasyon kimliklerini tercih edin. Kiracı açıkça daha derin günlük kaydına izin veriyorsa bunu kendi denetim etkinliği, saklama süresi ve erişim kontrolleri ile ayrı bir politika haline getirin.

Önerilen saklama katmanları:

• Kontrol düzlemi denetim etkinlikleri: tam uyumluluk ve anlaşmazlık süresi boyunca örneklenmemiş halde tutulur.
• Kullanım ve fatura defteri: fatura, vergi ve ters ibraz gereksinimlerine ilişkin mali kayıtların tamamını korur.
• Çalışma zamanı izlemeleri: hassasiyet ve gözlemlenebilirlik maliyetine göre elde tutmayı örnekleyin veya kısaltın.
• Ham istemler ve çıktılar: denetim için varsayılan olarak kapalı; yasal ve operasyonel olarak gerekçelendirildiği durumlarda yalnızca açık kiracı politikası aracılığıyla etkinleştirin.

Kiracı kimlikleri, anahtar parmak izleri, istek kimlikleri, iş akışı kimlikleri ve aktör kimlikleri gibi yüksek kardinaliteli alanlar bazı gözlemlenebilirlik sistemlerinde pahalıdır. Bunu kontrol düzlemi denetim olaylarını örnekleyerek çözmeyin. Bunun yerine, denetim olaylarının tamamını deftere yerleştirin ve seçilen alanları yüksek maliyetli gözlemlenebilirlik araçlarına aktarın.

Her değişiklik değil, risk konusunda uyarı

Her yönetici etkinliği için gerçek zamanlı uyarılar gürültü yaratır. Risk puanlamasını kullanın. Şu durumlarda hemen uyarı ver:

• harcama sınırı önemli ölçüde artırıldı;
• anahtar alışılmadık bir aktör tarafından veya alışılmadık bir ağdan oluşturulur;
• kiracı karantinaya alınmadı;
• bir model profili, daha pahalı veya daha az kısıtlı modellere izin verecek şekilde değişir;
• bir yukarı akış sağlayıcı kimlik bilgisi oluşturulur, dışa aktarılır, döndürülür veya devre dışı bırakılır;
• Bir İş Ortağı API idempotency anahtarı farklı bir yük ile yeniden kullanılıyor;
• webhook tekrarı müşterinin kredisini veya anahtar durumunu değiştirir.

Düşük riskli etkinlikler günlük incelemeye veya SIEM korelasyonuna gidebilir. Buradaki amaç, aşağı yöndeki kötüye kullanımı, maliyet artışlarını veya başarısız kontrol altına almayı açıklayan kontrol düzlemi değişikliklerini ortaya çıkarmaktır.

Uygulama kontrol listesi

• Anahtarlar, kiracılar, kullanıcılar, hizmet hesapları, harcama sınırları, krediler, yönlendirme profilleri, sağlayıcı kimlik bilgileri ve karantina için standart eylem adlarını tanımlayın.
• Oluşması ve kullanılması için değişmez olay kimliklerini ve zaman damgalarını saklayın.
• Aktör türünü, aktör kimliğini, kimlik doğrulama yöntemini, kaynak sistemini ve istek korelasyon kimliğini kaydedin.
• Sanal anahtarlar, yukarı akış kimlik bilgileri, kimlik anahtarları, kullanıcı aracıları ve hassas politika içeriği için kararlı karmalar kullanın.
• Kiracı kimliği, anahtar parmak izi, model profili kimliği ve istek korelasyon kimliği aracılığıyla denetim etkinliklerini çalışma zamanı kullanımına ekleyin.
• Mümkün olduğunda, yetenek işaretleri ve boşluk ek açıklamalarıyla birlikte sağlayıcı yönetici etkinliklerini içe aktarın.
• Kontrol düzlemi denetim etkinliklerini örneklenmemiş halde tutun.
• Yerinde güncelleme düzenlemeleri yerine düzeltme etkinliklerini kullanın.
• SIEM'e veya depoya aktarın ancak ağ geçidine özgü kaynaklar için ağ geçidi denetim defterini standart tutun.
• Anahtar oluşturma, harcama sınırı değişiklikleri, model profili değişiklikleri, İş Ortağı API kredi etkinlikleri, yukarı akış kimlik bilgisi değişiklikleri ve sınırlama doğrulaması için önceden oluşturulmuş olay sorguları.

Harekete geçirilebilir sonuç

AI API olayları için temel soru genellikle "hangi istemin gönderildiği?" değildir. “Bu olmadan önce ne değişti?” Ağ geçidi denetim takibi bu yanıtın hızlı olmasını sağlamalıdır: yeni anahtarlar, değişen harcama sınırları, İş Ortağı API otomasyonu, yönlendirme profili güncellemeleri, sağlayıcı kimlik bilgileri değişiklikleri ve tek zaman çizelgesinde sınırlama eylemleri.

Normalleştirilmiş bir şemayla başlayın, sanal anahtar parmak izlerini ana birleştirme noktası yapın, etkinlikleri yalnızca eklenti olarak tutun, çalışma zamanı telemetrisini kontrol düzlemi geçmişinden ayırın ve eşit olmayan sağlayıcı denetim kapsamı için tasarım yapın. Bu, denetim sistemini hızlı bir depoya dönüştürmeden güvenlik, platform ve FinOps ekiplerine savunulabilir bir kayıt sağlar.

İlgili okumalar

• anormallik olayı runbook'larını harcama