Kurumsal yapay zeka erişim denetimleri nasıl çalışmalı?

Kurumsal bir yapay zeka geliştirme çalışma alanı, üretilen her değişikliği belirli bir ortamda, tanımlı bir rol aracılığıyla, insan kimliği altında yapılan bir işlem olarak ele almalıdır. Platform kaynak kodu okuyabiliyor, dış hizmetleri çağırabiliyor, altyapı oluşturabiliyor, uygulama dağıtabiliyor, anlık görüntüleri geri yükleyebiliyor veya kod dışa aktarabiliyorsa, erişim modeli akıllı bir düzenleyiciyi değil, üretim sistemini denetler.

Tedarikte en sık gördüğüm hata, SAML, SCIM ve RBAC'in özellik listesinde yer alıp almadığını kontrol etmektir. Varlıkları, zorunlu tutuldukları hakkında çok az şey söyler. Bir sağlayıcı SAML beyanını kabul ederken parola ile oturum açmayı açık bırakabilir, SCIM askıya alma işlemini yürütürken etkin oturumları koruyabilir ve her geliştiriciye dağıtım izni vererek RBAC sunduğunu iddia edebilir. Alıcıların kimlik sağlayıcısından nihai yan etkiye kadar uzanan zinciri test etmesi gerekir.

Kimlik doğrulama, yaşam döngüsü yönetimi, yetkilendirme, onay, kimlik bilgisi yönetimi, ortam yalıtımı ve denetim kanıtı farklı sorunları çözer. Bunları belirsiz bir güvenlik başlığı altında birleştirmek, denetimler arasındaki boşlukları gizler. Eski çalışanların oturumlarının açık kaldığı, geliştirme ajanlarının üretim kimlik bilgilerine ulaştığı ve onaylı değişikliklerin yayından önce değiştiği yerler bu boşluklardır.

SAML paralel girişleri kapatmalıdır

SAML SSO, çalışma alanına girişte kurumsal kimlik sağlayıcısını normal ve zorunlu yol haline getirmelidir, sağlayıcının parola formunun yanındaki isteğe bağlı bir düğme değil. Bir kurumsal alan adını talep etmek, o alan adı altında yönetilmeyen kimlikler oluşturan kendi kendine kaydı, parola kurtarmayı ve davetleri engellemelidir.

OASIS SAML 2.0 belirtimleri, kimlik doğrulama ve özniteliklerle ilgili beyanları tanımlar. Bir kişi ayrıldığında sağlayıcı hesaplarını devre dışı bırakmaz veya doğrulanmış bir mühendisin üretime dağıtım yapıp yapamayacağına karar vermez. Bu sınır önemlidir, çünkü tedarik anketleri SAML'i genellikle merkezi erişim denetiminin kanıtı sayar; oysa SAML yalnızca kimlik doğrulamanın bir bölümünü kanıtlar.

Ciddi bir uygulama; beyan imzasını, yayıncıyı, hedef kitleyi, alıcıyı, zaman koşullarını ve istek ilişkilendirmesini doğrular. Kesinti olmadan sertifika yenilemeyi destekler ve kullanıcıları değiştirilemez bir tanımlayıcıyla eşler. E-posta, adresler değiştiği, yeniden kullanıldığı ve bazen yalnızca biçim açısından farklı olduğu için zayıf bir birincil tanımlayıcıdır. Hangi SAML özniteliğinin kalıcı hesap kimliği olduğunu ve bu öznitelik değiştiğinde ne olacağını sorun.

Yöneticilerin oturum süresini, hareketsizlik sınırlarını ve hassas işlemler için yeniden kimlik doğrulamayı yapılandırmasını zorunlu tutun. Politika çok faktörlü kimlik doğrulamaya bağlıysa çalışma alanı, kimlik sağlayıcısının kimlik doğrulama bağlamına uymalıdır. Kimlik sağlayıcısının verdiği her beyanı kabul ediyorsa SAML'in otomatik olarak güçlü kimlik doğrulama sağladığını iddia etmemelidir.

Yerel acil durum erişiminin dar bir istisnası olmalıdır. Kimlik sağlayıcısı kesintisi tüm yöneticileri kilitlemesin diye normal SSO yolunun dışında bir veya daha fazla acil durum kimliği tutun. Bunları güçlü kimlik doğrulama, ayrı sorumluluk, anında uyarılar ve belgelenmiş test takvimiyle koruyun. Normal yöneticiler bu hesapları kolaylık için kullanmamalıdır.

Yalnızca oturum açma düğmesini değil, atlatma yollarını test edin. Eski bir daveti açın, parola sıfırlama isteyin, kullanıcının e-postasını değiştirin, kullanıcıyı izin verilen bir kimlik sağlayıcısı grubundan çıkarın ve yanlış kiracıya kimlik sağlayıcısı başlatmalı oturum açmayı deneyin. Çalışma alanının misafir alan adlarını, satın alınan şirket alan adlarını ve birden çok kimlik sağlayıcısını nasıl ele aldığını doğrulayın. Sağlayıcı hesap bağlamayı net biçimde açıklayamıyorsa yinelenen kimliklerin ortaya çıkacağını varsayın.

Oturum sonlandırma kendi kabul ölçütünü hak eder. Kimlik sağlayıcısında bir kişiyi devre dışı bırakmak, mevcut tarayıcı oturumu, komut satırı belirteci veya ajan işi saatlerce sürerken yalnızca sonraki oturum açmayı engelleyebilir. Bir yöneticinin tek bir kimliğe ait tüm oturumları iptal edip edemediğini ve SCIM askıya alma işleminin bunu otomatik tetikleyip tetiklemediğini sorun.

SCIM, hesapları insan hafızasına bağlı kalmadan kapatmalıdır

Kimlik kaynağı kullanıcıyı askıya aldığında SCIM; etkileşimli oturumlar, API kimlik bilgileri, kuyruktaki işler ve ajan yürütmeleri genelindeki etkili erişimi hızla kaldırmalıdır. Bir hesap alanını yalnızca etkin değil olarak ayarlamak işten çıkarma sürecini tamamlamaz.

RFC 7643 temel Kullanıcı ve Grup kaynak şemalarını, RFC 7644 ise bu kaynakları oluşturma, sorgulama, değiştirme ve silmeye yönelik protokol işlemlerini tanımlar. Standartlar sağlayıcılara ortak bir alışveriş sunar, ancak devre dışı bırakmanın her yerel sonucunu belirlemez. Alıcılar, değişikliği aldıktan sonra çalışma alanının gerçekte ne yaptığını sormalıdır.

Sağlama işlemi, ilk oturum açmadan önce hesabı doğru kuruluş ve temel grup üyeliğiyle oluşturmalıdır. Grup güncellemeleri çalışma alanı rollerini öngörülebilir biçimde eklemeli ve kaldırmalıdır. Askıya alma, yeni oturumları reddetmeli, mevcut oturumları ve kişisel belirteçleri iptal etmeli, planlanmış işleri durdurmalı veya yeniden atamalı ve bekleyen onayların askıya alınmış kimlik altında kullanılmasını engellemelidir. Silme işlemi, denetim ilişkilendirmesini silmeden müşterinin saklama politikasına uymalıdır.

Tanıdık bir başarısızlık, yayın grubunda yer alan bir yükleniciyle başlar. Kimlik sağlayıcısı yükleniciyi gruptan çıkarır ve SCIM yaması gönderir. Çalışma alanı görünür rolü günceller, ancak daha önce açılmış bir tarayıcı oturumu hâlâ yayın iznini içerir. Yüklenicinin kaldırılmadan önce kuyruğa aldığı dağıtım da daha sonra bir hizmet kimlik bilgisi altında çalışır. Her ekran doğru görünür, ancak etkili erişim iki yerde yaşamaya devam eder.

Bu başarısızlık, dizin durumu ile çalışma zamanı yetkisi arasındaki farkı ortaya koyar. SCIM dizin durumunu günceller. Çalışma alanı değişikliği oturumlara, belirteçlere, işlere, onay atamalarına ve önbelleğe alınmış yetkilendirme kararlarına yaymalıdır. Tedarik ekibi, hemen veya otomatik gibi sözleri kabul etmek yerine beklenen iptal aralığını belirlemeli ve ölçmelidir.

Grup uzlaştırması da test edilmelidir. Kullanıcıyı bir gruptan çıkarırken diğerinde bırakın, askıya alıp yeniden etkinleştirin, grubu yeniden adlandırın ve üretim erişimi veren bir grubu silin. Yeniden etkinleştirme, kullanıcının artık üyesi olmadığı bir gruptan gelen ayrıcalıkları geri getirmemelidir. Manuel rol atamaları ayrı görünmelidir, çünkü grup temizliğinden sonra da varlıklarını sürdürebilirler.

SCIM bağlayıcısını da inceleyin. Taşıyıcı belirteci yalnızca sağlama izinlerine sahip olmalı, döndürmeyi desteklemeli ve yapılandırma ile kullanım için denetim olayları üretmelidir. Hizmet sağlayıcı yararlı hata yanıtları vermeli ve güvenli yeniden denemeleri tolere etmelidir. Grup değişikliklerini sessizce kaybeden bir bağlayıcı, kimlik ekibini ücretsiz izleme yazılımına dönüştürür.

RBAC, işlemleri kaynaklarla eşleştirmelidir

RBAC, hangi kimliğin hangi kaynak üzerinde hangi işlemi hangi ortamda yapabileceğini ifade etmelidir. Geniş görüntüleyici, üye ve yönetici etiketleri; yazılım geliştiren ve yayımlayan bir çalışma alanını güvenle yönetemez.

İş unvanlarından değil, işlemlerden başlayın. İzin kataloğu; proje görüntülemeyi, yönergeleri düzenlemeyi, ajan çalıştırmayı, üretilen kaynağı okumayı, kaynağı dışa aktarmayı, anlık görüntüleri yönetmeyi, sürüm geri yüklemeyi, alan adı yapılandırmayı, dağıtım oluşturmayı, yapıtı tanıtmayı, gizli bilgi meta verilerini okumayı, kimlik bilgilerini değiştirmeyi, denetim kayıtlarını okumayı ve kuruluş politikasını değiştirmeyi ayırmalıdır. Kesin adlar platforma göre değişir, ancak ayrım ortadan kalkmamalıdır.

İşe yarayan bir başlangıç matrisi şöyledir:

Bu tabloyu körü körüne kopyalamayın. Açık bir karar gerektiren birleşimleri görünür kılmak için kullanın. Bazı kuruluşlar onaylayıcı ile operatörü birleştirirken düzenlemeye tabi ekipler onları ayırır. Tehlikeli varsayılan, değişiklik oluşturabilen, onaylayabilen, kimlik bilgisi ekleyebilen, dağıtım yapabilen ve kanıtı silebilen genel bir yöneticidir.

Rollerin kapsamı olmalıdır. Bir mühendis bir çalışma alanında geliştirme yapabilir, diğerini inceleyebilir ve üçüncüsüne hiç erişemeyebilir. Mühendisin geliştirmeye erişmesi, üretim izninin otomatik gelmesine yol açmamalıdır. Yetkilendirme motoru, belgelenmiş devralma kurallarıyla kuruluş, çalışma alanı, proje, ortam ve kaynak kapsamlarını desteklemelidir. Alıcılar üst kapsamdaki izin kararının alttaki reddi geçersiz kılıp kılmadığını veya tersinin geçerli olup olmadığını bilmelidir.

Özel roller, yalnızca sağlayıcı kararlı izinleri açığa çıkarır ve etkili erişimi raporlarsa yararlıdır. Basit bir araştırma sorusunu yanıtlayan bir görünüm veya dışa aktarma isteyin: Bu kimlik bu işlemi neden yapabiliyor? Yanıt; doğrudan atamaları, gruptan gelen rolleri, devralınan izinleri, geçici izinleri ve politika koşullarını göstermelidir. Bu açıklama olmadan, özel roller ilk yeniden yapılanmadan sonra gözden geçirilmesi zor hale gelir.

İnsan rolleri ile iş yükü kimlikleri de ayrı ele alınmalıdır. Dağıtım ajanı, oluşturan kişinin tam etkileşimli rolünü ödünç almamalı; hizmet kimliği de kullanıcı arayüzünde oturum açmamalıdır. Her iş yüküne adlandırılmış bir sahip, amaç, ortam, izin kümesi, sona erme veya gözden geçirme tarihi ve iptal yolu verin.

Ortamların gerçek güvenlik sınırlarına ihtiyacı vardır

Geliştirme, test ve üretim; zorunlu izinler, kimlik bilgileri, çalışma zamanı kaynakları, veri politikası ve yayın yolları aracılığıyla ayrılmalıdır. Ortam seçici veya renkli etiket yalıtım oluşturmaz.

İlk sınır yetkilendirmedir. Geliştirme kaynaklarını değiştirebilen bir geliştirici, aynı devralınan proje rolüyle üretim erişimi kazanmamalıdır. İkinci sınır kimlik bilgileridir. Geliştirme ajanları, geliştirme veritabanı ve bulut izinlerini almalı; her ortama ulaşabilen bir kuruluş kimlik bilgisi almamalıdır. Üçüncü sınır veridir: Önizlemeler ve testler, ayrı bir süreç bu kullanımı yetkilendirip korumadıkça üretim kayıtlarını kopyalamamalıdır.

Üretilen uygulamalar dış çağrılar yapabildiğinde veya altyapı oluşturabildiğinde çalışma zamanı ayrımı önem kazanır. Ortamların ayrı yürütme kimlikleri, ağ kuralları, depolama konumları ve dağıtım hedefleri kullanıp kullanmadığını sorun. Paylaşımlı bir işçi birden çok ortamı işliyorsa, platformun bir işin diğerinin malzemesini okumasını nasıl engellediğini belirleyin. Mantıksal ayrım iddiası, mimari slaytı değil denetim gösterimi gerektirir.

Tanıtım işlemi, daha geniş üretim izinleri altında değişebilir kaynak kodunu yeniden derlemek yerine incelenmiş yapıtı taşımalıdır. Kaynak revizyonunu, üretilen dosyaları, bağımlılık kilit durumunu, test sonucunu, politika sürümünü ve yapıt özetini kaydedin. Üretim en güncel proje durumundan yeniden derlenirse, onaydan sonra yapılan değişiklik inceleme olmadan yayına girebilir.

Anlık görüntüler ve geri alma aynı sınıra ihtiyaç duyar. Daha eski bir uygulama sürümünü geri yüklemek; güvenlik açığı bulunan kodu, eski yapılandırmayı veya artık veritabanıyla eşleşmeyen şema beklentisini de geri getirebilir. Üretimde geri almayı, yetkilendirme, kanıt ve denetim izi gerektiren bir üretim işlemi olarak ele alın. Geri alma sözcüğünün verdiği rahatlık, yayın politikasını atlamamalıdır.

Veri yerleşimi ile ortam ayrımı ilişkilidir, ancak aynı şey değildir. İş yüklerini seçilmiş bir ülkede çalıştırmak depolama veya aktarım gereksinimlerini karşılayabilir, ancak geliştirme ve üretimin ayrı kimlikler veya veriler kullandığını kanıtlamaz. Tedarik ekipleri, tek bir konum iddiasının iki soruyu yanıtlamasına izin vermek yerine iki gereksinimi de belgelemelidir.

Sağlayıcı bu sınırları tek kuruluş içinde zorunlu kılamıyorsa, ayrı kiracılar gerekli olabilir. Bu yönetim yükünü artırır ve tanıtımı karmaşıklaştırabilir, ancak bir proje etiketinin üretim yetkisini içerdiğini varsaymaktan daha güvenlidir.

Onay kapıları sonuç doğuran eşiklerde olmalıdır

Onay kapıları maddi sonuç doğuran işlemleri korumalı ve her onay değiştirilemez tek bir teklife bağlanmalıdır. Her ajan mesajı için onay istemek yorgunluk yaratır; belirsiz bir sohbeti onaylamak ise inceleyene çok az bilgi verir.

İyi adaylar arasında üretim dağıtımı, kimlik bilgisi eklemek veya kapsamını genişletmek, ağ erişimini değiştirmek, herkese açık alan adı yapılandırmak, hassas kaynak veya veriyi dışa aktarmak, üretim anlık görüntüsünü geri yüklemek, yetkilendirme politikasını değiştirmek ve denetim dışa aktarımını devre dışı bırakmak bulunur. Geliştirme düzenlemeleri, korunan verilere veya dış sistemlere dokunmadıkları sürece genellikle aynı kapıya ihtiyaç duymaz.

İnceleyenin somut bir pakete ihtiyacı vardır: istenen işlem, hedef ortam, kaynak ve yapıt özeti, dosya veya altyapı farkı, testler, politika bulguları, istenen kimlik bilgisi kapsamları, istekte bulunanın kimliği, ajan kimliği ve sona erme zamanı. Arayüz, inceleyen onaylarsa ne olacağını belirtmelidir. İşlem sınırı olmayan bir izin ver düğmesi, onay denetimi değildir.

Politikanın kendisi, alıcının inceleyip test edebileceği biçimde ifade edilebilir:

policy_version: 18
rules:
  - action: deploy
    environment: production
    require:
      approvals: 1
      approver_role: release_approver
      requester_cannot_approve: true
      artifact_digest_must_match: true
      expires_minutes: 30
  - action: credential_scope_change
    require:
      approvals: 1
      approver_role: credential_custodian
      scope_diff_required: true

Bu parça iki yaygın başarısızlığı önler. İstekte bulunan kişi kendi üretim dağıtımını onaylayamaz ve yapıt özeti artık eşleşmediği için her yapıt değişikliği onayı geçersiz kılar. Kısa sona erme süresi de çevredeki operasyonel bağlam değiştikten sonra eski kararın kullanılmasını önler.

Onay durumu bir sohbet dizisi veya kullanıcı oturumuyla değil, işlemle birlikte ilerlemelidir. Kaynağı düzenlemek, hedefi değiştirmek, izni genişletmek, kimlik bilgisini değiştirmek veya üretimi yeniden çalıştırmak, onaylanan teklifi değiştirdiğinde yeni karar gerektirmelidir. Başarısız bir dağıtımın yeniden denenmesi, yalnızca yapıt ve işlem aynı kalırsa ve politika açıkça izin verirse onayı yeniden kullanabilir.

Kuyruktaki ve otomatik işlemler de aynı zorunluluğa tabi olmalıdır. Bir ajan, onaylı zaman aralığında üretim değişikliği planlayıp pencere kapandıktan sonra başka bir sürümü yürütmemelidir. Yürütme hizmeti, yürütme sırasında yetkilendirmeyi, onay geçerliliğini, yapıt kimliğini ve kimlik bilgisi kapsamını yeniden denetlemelidir.

Planlama modu, inceleyenlerin amaçlanan işi anlamasına yardımcı olabilir, ancak plan bir yetkilendirme sınırı değildir. Platform doğru bir plan üretebilir ve ardından araç çağrısı değiştiği, bir entegrasyon beklenmeyen veri döndürdüğü veya model yaklaşımını değiştirdiği için ek işlemler yapabilir. Onayı, etkiyi doğuran işlemde zorunlu kılın.

Gerçek olaylar için acil durum yolları bulunmalıdır. Gerekçe, sınırlı süre, kısıtlı işlem kümesi, anında uyarı ve kullanım sonrası inceleme isteyin. Acil durum geçersiz kılma işlemi sessizce kalıcı yönetici erişimi veriyorsa, istisna denetimin yerini almıştır.

Kimlik bilgileri insanlar unutmadan sona ermelidir

Hedef sistem desteklediğinde çalışma alanı, dar ortam ve işlem kapsamları olan geçici iş yükü kimlik bilgileri kullanmalıdır. Sohbete, proje ayarlarına veya derleme değişkenlerine yerleştirilen kalıcı kuruluş belirteçleri, ajana çoğu görevin gerektirdiğinden çok daha fazla yetki verir.

Üç kavramı ayrı tutun. İnsan oturumu, çalışma alanını kimin kullandığını kanıtlar. İş yükü kimliği ajanı, derlemeyi veya dağıtım sürecini tanımlar. Gizli malzeme, bu iş yüküsünün dış sisteme ulaşmasına yetki verir. İnsan kullanıcının geniş belirtecini bu üçü için yeniden kullanmak ilişkilendirmeyi yok eder ve iptali aksatır.

Doğrulanmış bir iş yükü kimliğini geçici belirteçle değiştiren federasyonu veya kimlik bilgisi aracısını tercih edin. Aracı; hedef kitleyi, rolü, ortamı ve süreyi sınırlayabilir. Ajan süreci belirteci yalnızca onaylı aracı çağırdığında almalıdır; model gizli değeri bağlamında görmemeli veya çıktısında yeniden üretmemelidir.

Gizli bilgi depolama tek başına kapsam sorununu çözmez. Kusursuz biçimde şifrelenmiş bir bulut kimlik bilgisi bile her hesaptaki silme işlemine izin verebilir. Yalnızca kasayı değil, hedef izinlerini inceleyin. Her kimlik bilgisinin sahibi, amacı, izin verilen ortamı, yetkili iş yükleri, oluşturma kaynağı, döndürme yöntemi ve son kullanım kaydı olmalıdır.

İstemler, sohbet geçmişi, üretilen kaynak kodu, günlükler, anlık görüntüler, destek paketleri ve dışa aktarımlar olası sızıntı yollarıdır. Platform kalıcılıktan önce algılanan gizli bilgileri maskelemelidir, ancak biçimler değiştiği ve kodlanmış değerler sızdığı için algılama yedek denetimdir. Daha güçlü tasarım, gizli malzemeyi hiçbir zaman model girdisine veya olağan çıktı kanallarına koymaz.

Kaynak dışa aktarma için bilinçli bir kural gerekir. Dışa aktarma paketleri gizli değerleri atlamalı ve çözümlenmemiş gizli bilgi referanslarını belirtmelidir ki alan ekip neyi yapılandıracağını bilsin. Çalışan bir ortam dosyası içeren dışa aktarma, taşınabilirliği kimlik bilgisi dağıtımına dönüştürür.

Gerçek yetkisi olmayan bir kanarya kimlik bilgisiyle çevrelemeyi test edin. Ayırt edilebilir değerini desteklenen her girdi yoluna koyun, ajanı çalıştırın, anlık görüntü oluşturun, günlükleri inceleyin ve projeyi dışa aktarın. Ardından her ortaya çıkan yapıtta ve denetim akışında arama yapın. Bu test, sağlayıcının gizli bilgi sınırının yalnızca doğrudan gizli girişte değil, olağan ürün özelliklerinde de ayakta kalıp kalmadığını gösterir.

Döndürme ve iptal, tüm çalışma alanını yeniden oluşturmadan çalışmalıdır. Hedef sistem geçici kimlik bilgisi veremediğinde sistemin ne yaptığını, saklanan gizli bilgileri nasıl döndürdüğünü ve işlerin yürütme anında güncel sürümü alıp almadığını sorun. Dün yakalanan kimlik bilgisiyle çalışan bir iş, kimlik bilgisi kaydı güncellenmiş görünse de devam edebilir.

Giden entegrasyonların kendi rıza modeli olmalıdır. Kaynak deposu, veritabanı, bilet sistemi veya bulut hesabı eklemek, istenen kapsamları göstermeli ve bağlantıyı bir çalışma alanına ve ortama bağlamalıdır. Kuruluş genelindeki bağlantılar istisna olmalıdır; bir projedeki ajan hatası her depoyu veya hesabı açığa çıkarmamalıdır.

Dışa aktarılan denetim günlükleri niyeti ve etkiyi yeniden kurmalıdır

Denetim günlükleri, araştırmacının bir insan isteğini sağlayıcının kullanıcı arayüzüne bağlı kalmadan yetkilendirme, ajan yürütmesi, kimlik bilgisi kullanımı ve ortaya çıkan değişiklikle ilişkilendirmesini sağlamalıdır. Dışa aktarılabilirlik, yalnızca yöneticilerin kullanabildiği manuel indirme değil, müşterinin denetlediği depolama veya izlemeye uzanan belgelenmiş ve kesintisiz bir yol demektir.

NIST SP 800-53, AU-12'de denetim olayı üretimini AU-9'daki denetim bilgilerinin korunmasından ayırır. Bu ayrım burada faydalıdır. Bir çalışma alanı yöneticisi tek kopyayı değiştirebiliyor veya silebiliyorsa, dağıtımı kaydetmek yeterli değildir. Olayları, sınırlı yazma erişimi ve müşteri denetimli saklama ile çalışma alanının dışına gönderin.

Her olayda kararlı bir tanımlayıcı, zaman damgası, kiracı, insan aktör, iş yükü veya ajan kimliği, işlem, hedef kaynak, ortam, yetkilendirme kararı, rol veya politika dayanağı, onay referansı, kimlik bilgisi referansı, sonuç ve ilişkilendirme tanımlayıcısı bulunmalıdır. Değişiklik olayları, olayı saklanan yapıtlarla bağlayan bir fark, güvenli önce ve sonra değerleri veya karmalar içermelidir.

Bir dağıtım olayı şu çıktı biçimine sahip olabilir:

{
  "event_id": "evt_01J...",
  "occurred_at": "2026-07-27T14:03:22Z",
  "actor": {"type": "user", "id": "usr_1842"},
  "workload": {"type": "release_agent", "id": "agt_77"},
  "action": "deployment.create",
  "target": {"environment": "production", "application": "app_91"},
  "authorization": {
    "decision": "allow",
    "policy_version": 18,
    "approval_id": "apr_552"
  },
  "artifact_digest": "sha256:8b1c...",
  "credential_ref": "cred_cloud_prod_4",
  "request_id": "req_9031",
  "result": "success"
}

Olay gizli değerleri değil, referansları gösterir. Hem insanı hem de yürütmeyi yapan iş yükünü adlandırır; böylece yalnızca bir ajanın dağıtım yaptığını söyleyen yararsız kaydı önler. İstek tanımlayıcısı, ilişkili model çalıştırmalarını, araç çağrılarını, politika kararlarını ve hedef yanıtlarını bağlamalıdır.

Denetim ile gözlemlenebilirlik farklıdır. Operasyonel izler mühendislere gecikmeyi, model çağrılarını ve başarısızlıkları ayıklamada yardımcı olur. Denetim kayıtları ise kimin neyi yapmaya yetkili olduğunu ve neyin değiştiğini belirler. Sağlayıcılar bazen zengin izler sunarken rol değişikliklerini, gizli bilgi yönetimini, destek erişimini, dışa aktarma işlemlerini veya reddedilen yetkilendirme girişimlerini atlar.

İstem içeriği ölçülü ele alınmalıdır. Tam istemler kaynak kodu, kişisel veri veya gizli bilgi içerebilir; bu nedenle her konuşmayı güvenlik günlüğünde saklamak başka bir hassas depo yaratabilir. Kararlı karmaları, maskelenmiş özetleri, ayrı yönetişime tabi içeriğe referansları ve üretilen somut işlemleri kaydedin. Müşteriye saklama ve maskeleme denetimi verin, ancak hangi güvenlik olaylarının ortadan kalkacağına karar verme yetkisini asla işlem yapan modele bırakmayın.

Sıralamayı, saat tutarlılığını, teslim gecikmesini, yeniden denemeleri, yinelenen kayıt işlemeyi, şema değişikliklerini ve kesinti sırasındaki davranışı test edin. Dışa aktarma sürümlendirmeyi belgelemeli ve kurtarma için imleç veya olay tanımlayıcısı sağlamalıdır. Müşteri alıcısı kullanılamıyorsa sağlayıcı, olayları açıklanan bir sınıra göre arabelleğe almalı ve teslimat yetişemediğinde bunu bildirmelidir.

Destek erişimi de aynı akışta yer almalıdır. Sağlayıcı personelinin kiracıya ne zaman eriştiğini, hangi yetkilendirmenin buna izin verdiğini, neyi görüntülediğini veya değiştirdiğini ve erişimin ne zaman sona erdiğini kaydedin. Müşterilerin dışa aktaramadığı iç sağlayıcı günlüğü, kurumsal bir araştırmanın sorularını yanıtlamaz.

Tedarik testleri denetim düzlemine saldırmalıdır

Tedarik, yalıtılmış değerlendirme kiracısında canlı testler istemeli ve gözlemlenen zorunluluğu kabul kanıtı olarak ele almalıdır. Sunum mimariyi açıklayabilir, ancak askıya alınmış kullanıcının önbelleğe alınmış dağıtım belirtecini kaybettiğini kanıtlayamaz.

Bir kimlik sağlayıcısı, SCIM istemcisi, birkaç test kimliği, iki ortam, zararsız bir dış kimlik bilgisi ve denetim alıcısı hazırlayın. Oturumdan önce beklenen sonuçları sağlayıcıya verin ki çalışma, sunum yapanın doğaçlamasını değil ürünü ölçsün.

1. Her kimlik atlatma yolunu deneyin: yerel parola, davet, parola kurtarma, yinelenen e-posta, yanlış kimlik sağlayıcısı ve askıya alma sonrası eski oturum.
2. Tarayıcı oturumları, kişisel belirteçler, bekleyen onaylar, planlanmış işler ve ajan çalıştırmaları etkin kalırken grup üyeliğini değiştirin ve ayrıcalıklı kullanıcıyı askıya alın.
3. Devralınan roller, özel roller, hizmet kimlikleri, kaynak dışa aktarma, anlık görüntü geri yükleme ve geliştirmeden üretime geçiş üzerinden ayrıcalık yükseltmeyi deneyin.
4. Bir yapıtı onaylayın, kaynağını veya hedefini değiştirin ve eski onayla ve daha geniş bir kimlik bilgisiyle dağıtım yapmayı deneyin.
5. Tüm olayları dışa aktarın, ardından reddedilen girişimler ve sağlayıcı destek erişimi de dahil olmak üzere değişikliği kimin istediğini, onayladığını, yürüttüğünü ve aldığını yeniden kurun.

Her sonuç için ham kanıt kaydedin: hassas değerleri çıkarılmış SAML yanıt ayrıntıları, SCIM istekleri ve yanıtları, etkili izin dışa aktarımları, onay tanımlayıcıları, yapıt özetleri, kimlik bilgisi meta verileri, denetim olayları ve zaman damgaları. Ekran görüntüleri bulguyu açıklamaya yardım eder, ancak makine tarafından okunabilir çıktı sağlayıcı bir denetimi değiştirdikten sonra karşılaştırmayı kolaylaştırır.

Dört sonuç durumu kullanın: geçti, kaldı, kısmi ve vaat edildi. Kısmi, denetimin yalnızca bazı erişim yolları, kaynaklar veya planlar için çalıştığı anlamına gelir. Vaat edildi, sağlayıcının gelecekteki davranışı açıkladığı anlamına gelir. Hesap ekibi yol haritası tarihi verdi diye iki durumu da geçtiye çevirmeyin.

Yapılandırmayı değiştirdikten sonra sağlayıcıdan başarısız testi yinelemesini isteyin. Bu, eksik ürün denetimini kötü varsayılandan ayırır ve yöneticilerin ayarı bulup bulamayacağını gösterir. Belgelenmemiş destek çalışmasının arkasına gizlenmiş güvenlik özelliği, gerçek dağıtım sırasında yeniden başarısız olur.

Plan ve fiyatlandırma sınırlarını birlikte test edin. SSO bir kademede, SCIM diğerinde bulunabilir; denetim dışa aktarımının ayrı saklama veya teslim sınırları olabilir. Tedarik için gereken, tek tek sunulan özellikler koleksiyonu değil, politikanın gerektirdiği bileşimdir. Plan uygunluğunu ve kullanım sınırlarını her kabul ölçütünün yanına koyun.

Yönetimsel kurtarmayı da inceleyin. Son kuruluş yöneticisini kaldırın, SAML yapılandırmasını bozun, SCIM belirtecini yanlış döndürün ve denetim alıcısını kesintiye uğratın. Çalışma alanı görünmez sağlayıcı atlatması oluşturmadan denetimli kurtarma sağlamalıdır. Kurtarma işlemleri sistemdeki en güçlü denetim kanıtını üretmelidir.

Koder.ai'yi değerlendirirken erişim denetimini bu yeteneklerin varlığından çıkarsamak yerine, bu testleri sohbet tabanlı oluşturma akışı, kaynak dışa aktarma, dağıtım ve barındırma, özel alan adları, anlık görüntüler, geri alma ve planlama modu üzerinde isteyin.

Sözleşmeler ve yaygınlaştırma denetimi korumalıdır

Sözleşme ve işletim süreci, düzenli değerlendirme kiracısı ortadan kalktıktan sonra test edilmiş denetimleri korumalıdır. Gerekli özellikleri, geçerli planları, saklama sürelerini, teslim sınırlarını, veri konumlarını, destek erişim kurallarını, dışa aktarma biçimlerini, uyumsuz şema değişiklikleri için bildirimi ve gerekli denetim çalışmayı durdurduğunda uygulanacak çözümü belgeleyin.

Güvenlik belgeleri, her işlemin hangi tarafın sorumluluğunda olduğunu belirtmelidir. Müşteri genellikle kimlik sağlayıcısı gruplarını, rol atamalarını, onay politikasını, kimlik bilgisi kapsamlarını, günlük hedeflerini ve saklamayı yapılandırır. Sağlayıcı zorunlu kılmayı, platform yönetici denetimlerini, olay üretimini, hizmet yalıtımını ve destek erişim kayıtlarını yönetir. Belirsiz sorumluluk, olaylar sırasında öngörülebilir boşluklar yaratır.

Yetkilendirme anlamını değiştiren değişiklikler için bildirim ve inceleme isteyin. Yeni bir ajan aracı, dağıtım hedefi, entegrasyon türü veya yönetici izni, müşteri ataması değişmeden mevcut rolleri genişletebilir. Sağlayıcı yeni izinleri belgelemeli ve bunları sessizce geniş özel rollere yerleştirmemelidir.

Üretimi, üretim dışı kimlikler, politikalar, kimlik bilgisi alışverişi, onaylar ve denetim teslimatı başarısızlık altında da çalıştıktan sonra yaygınlaştırın. Test edilmiş politika sürümünü dondurun, izin matrisini kaydedin ve erişim incelemeleri ile acil durum hesapları için sorumlular atayın. İnceleme aralıklarını evrensel bir takvimi kabul etmek yerine kuruluşun riskine ve personel değişimine göre belirleyin.

Erişim incelemeleri etkili izinleri, etkin olmayan hesapları, grupları atlatan doğrudan izinleri, kullanılmayan iş yükü kimliklerini, eski kimlik bilgilerini, acil durum erişimini, başarısız denetim teslimatını ve destek etkinliğini incelemelidir. İnceleyenlerin, bir iznin hâlâ sahibi ve amacı olduğuna dair kanıta ihtiyacı vardır. Kaynak kapsamı olmayan rol adları tablosu bu soruyu yanıtlamaz.

Bir kabul koşulunu değişmez kılın: Kimlik kaynağı ayrıcalıklı kullanıcıyı askıya aldığında üretime giden her kullanılabilir yol, üzerinde anlaşılan süre içinde kapanmalı ve dışa aktarılan olaylar bunu kanıtlamalıdır. Çalışma alanı bu testi geçemiyorsa denetim sayfasının geri kalanı süsten ibarettir.