Kurumsal API Yönetişim Çerçevesi: Uygulamalı Kontrol Matrisi

API Yönetişimi Çerçevesi: Uygulanabilir Bir İşletim Modeli

Bir API yönetişim çerçevesi, geniş ilkeleri ekiplerin tekrarlayabileceği kararlara dönüştürür. Kapsamı, karar sahiplerini, kontrollerin nerede çalışacağını, hangi kanıtları üreteceğini ve istisnaların nasıl onaylanacağını tanımlar.

Apidog'u bugün deneyin

Bu operasyonel ayrıntılar, bir yönetişim belgesi ile bir yönetişim sistemi arasındaki farkı oluşturur.

Bu kılavuzda kurumsal API programları için şu konuları ele alacağız:

• yedi katmanlı işletim modeli;
• merkezi ve federatif karar hakları;
• yaygın yönetişim faaliyetleri için RACI;
• risk katmanları ve orantılı kontroller;
• yönlendirme, uyarı, engelleme ve inceleme modları;
• örnek API yönetişim kontrol matrisi;
• kanıt ve istisna modeli;
• uygulanabilir yönetişim ilkeleri.

Daha geniş tanım, iş gerekçesi, metrikler ve araç kategorileri için API Yönetişimi Nedir? makalesiyle başlayabilirsiniz. Bu yazı doğrudan uygulamaya odaklanır.

API yönetişim çerçevesi nedir?

API yönetişim çerçevesi, kuruluşun API kararlarını alıp doğrulamak için kullandığı işletim sistemidir. Politikaları ve standartları API yaşam döngüsü boyunca sahiplerle, kontrollerle, kanıtlarla, ölçümlerle ve istisnalarla ilişkilendirir.

Eksiksiz bir çerçeve şu yedi soruyu yanıtlamalıdır:

1. Sonuçlar: Hangi iş, tüketici, güvenlik veya operasyonel sonuçları korumaya çalışıyoruz?
2. Kapsam: Hangi API'ler, ekipler, ortamlar ve yaşam döngüsü aşamaları kapsamda?
3. Karar hakları: Temel çizgiyi kim tanımlıyor, API sahibi kim, istisnaları kim onaylıyor ve bulguları kim çözüyor?
4. Risk: Hangi API'ler daha güçlü kontrollere ihtiyaç duyuyor ve neden?
5. Kontroller: Ekipler ne yapmalı; kontrol yönlendirmeli, uyarmalı, engellemeli veya inceleme mi gerektirmeli?
6. Kanıt: Kontrolün çalıştığını kuruluş nasıl doğrulayacak?
7. Geliştirme: Yönetişimin teslimatı aksatmadan riski azalttığını hangi metrikler gösterecek?

Her kuruluşun olduğu gibi kopyalayabileceği evrensel bir API yönetişim standardı yoktur. Çerçeve; mimariyi, tüketicileri, verileri, dağıtım modelini, düzenleyici bağlamı ve risk iştahını yansıtmalıdır.

Yararlanılabilecek referanslar:

• OpenAPI Spesifikasyonu, makine tarafından okunabilir API sözleşmesi formatı tanımlar.
• OWASP API Güvenliği İlk 10, yaygın API güvenlik risklerini listeler.
• NIST Siber Güvenlik Çerçevesi, yönetişim, roller, politika, risk ve denetim için daha geniş bir model sunar.

Bu kaynaklar kuruluşa özgü sahiplik ve kararların yerini tutmaz.

API yönetişim çerçevesinin yedi katmanı

Çerçeveyi uzun ve statik bir politika belgesi yerine birbiriyle bağlantılı yedi katman olarak tasarlayın:

Katman	Alınacak karar	Minimum çıktı
1. Sonuçlar ve kapsam	Yönetişim neden var ve neyi kapsıyor?	Sonuç beyanı, kapsam, istisnalar ve inceleme tarihi
2. İşletim modeli	Standartların, API'lerin, kontrollerin, kanıtların ve istisnaların sahibi kim?	Karar hakları haritası ve RACI
3. Portföy ve risk	Hangi API'ler mevcut ve her biri ne kadar kontrole ihtiyaç duyuyor?	Envanter, sahip, yaşam döngüsü durumu ve risk katmanı
4. Kontrol alanları	Tasarım, erişim, güvenlik, değişiklik ve operasyonlarda hangi gereksinimler geçerli?	Sürümlü kontrol kitaplığı
5. Teslimat iş akışı	Bir kontrol nerede yönlendirmeli, uyarmalı, engellemeli veya inceleme gerektirmeli?	Kontrol modu, tetikleyici ve iyileştirme yolu
6. Kanıt ve istisnalar	Kontrolün çalıştığını ne kanıtlar ve sapmalar nasıl yönetilir?	Kanıt kaydı, istisna kaydı, sahip ve sona erme tarihi
7. Ölçüm ve geliştirme	Çerçeve sonuçları ve geliştirici deneyimini iyileştiriyor mu?	Puan kartı, inceleme sıklığı ve geliştirme birikimi

Bir katmandaki zayıflık diğerlerini de zayıflatır:

• Sahibi olmayan kesin bir standart zamanla isteğe bağlı hale gelir.
• İstisna süreci olmayan engelleyici kontroller gizli geçici çözümler yaratır.
• Açık gereksinimlere bağlanmayan denetim izleri yalnızca etkinliği kaydeder; doğru riskin ele alındığını kanıtlamaz.

1. Politikaları yazmadan önce sonuçları ve kapsamı tanımlayın

Yöneticilerin, platform ekiplerinin ve teslimat ekiplerinin anlayabileceği küçük bir sonuç kümesiyle başlayın. Örneğin:

• Tüketiciler doğru API'yi ve sorumlu sahibini bulabilir.
• Genel ve iş ortağı sözleşmeleri değişiklikler sırasında öngörülebilir kalır.
• Yüksek riskli API'ler uygun güvenlik ve gizlilik incelemesinden geçer.
• Dokümantasyon, entegrasyonları uygulamak ve test etmek için yeterli ayrıntıyı içerir.
• Üretim kimlik bilgileri paylaşılan API varlıklarında düz metin olarak görünmez.
• Kişiler ayrıldığında veya erişime ihtiyaç kalmadığında izinler kaldırılır.
• Kullanımdan kaldırma süreçleri tüketicilere belgelenmiş bir geçiş yolu sunar.
• İnceleyiciler önemli kararları ve idari eylemleri yeniden oluşturabilir.

“Tüm API'ler uyumlu olmalı” gibi belirsiz hedeflerden kaçının. Şunları netleştirin:

• Neyle uyumlu?
• Hangi API'ler için?
• Hangi yaşam döngüsü aşamasında?
• Kararı kim verecek?
• Başarı nasıl ölçülecek?

Önce ölçülebilir sonucu yazın, ardından bu sonucu destekleyen politika ve kontrolleri tanımlayın.

Kapsam sınırlarını açıkça belirleyin

Çerçevenin neleri kapsadığını belgeleyin:

• REST, GraphQL, gRPC, olay tabanlı API'ler ve diğer arayüz türleri;
• dahili, iş ortağı, genel ve üçüncü taraf API'leri;
• tasarım, geliştirme, sürüm, operasyon, değişiklik, kullanımdan kaldırma ve kullanımdan çekme;
• API sözleşmeleri, dokümantasyon, testler, depolar, kimlik bilgileri ve işbirliği çalışma alanları;
• çalışma zamanı ağ geçitleri, kimlik sistemleri, günlükler, gözlemlenebilirlik ve olay süreçleri;
• yalnızca yeni API'ler veya hem yeni hem de mevcut API'ler.

İstisnaları da kaydedin. Örneğin ilk sürüm; yeni REST API'lerini ve mevcut genel API'lerdeki önemli değişiklikleri kapsayabilir. Eski sistem iyileştirmeleri ise ayrı, risk tabanlı bir plan izleyebilir.

Açık bir istisna yönetilebilir; varsayılan bir istisna ise kör noktaya dönüşür.

2. İşletim modelini seçin ve karar haklarını atayın

API yönetişimi genellikle iki uç noktada başarısız olur:

• Merkezi bir komite her kararı onaylar ve darboğaz oluşturur.
• Her ekip politikayı bağımsız yorumlar ve ortak bir temel çizgi oluşmaz.

Çoğu büyük kuruluş için federatif model daha uygundur:

• Merkezi API platformu veya etkinleştirme grubu kurumsal temel çizgiyi, ortak şablonları, araçları ve raporlamayı sahiplenir.
• Etki alanı yöneticileri temel çizgiyi alana özgü rehberliğe dönüştürür.
• API ürün sahipleri bireysel API'lerden ve tüketici sonuçlarından sorumlu olur.
• Güvenlik, gizlilik, IAM, SRE ve uyumluluk uzmanları kendi alanlarındaki kontrolleri sahiplenir veya inceler.
• Teslimat ekipleri kontrolleri uygular ve bulguları giderir.
• Belirlenmiş bir risk sahibi, süreli istisnaları onaylar.

Federasyon, “ekipler her şeye karar verir” anlamına gelmez. Yetkinin açık sınırlar, kanıtlar ve yükseltme yollarıyla dağıtılması anlamına gelir.

Merkezi, federatif veya merkeziyetsiz?

Model	En iyi çalıştığı durumlar	Ana risk	Koruyucu
Merkezi	API portföyü küçük, sıkı denetimli veya uygulamalar tutarsızsa	İnceleme kuyrukları ve yavaş kararlar	Hizmet seviyesi hedefleri, yeniden kullanılabilir kalıplar ve yetkilendirme kriterleri
Federatif	Birçok etki alanı kurumsal temel çizgiyi paylaşırken yerel uzmanlık ve özerklik gerekiyorsa	Etki alanları arasında düzensiz yorumlama	Sürümlü temel çizgi, yönetici topluluğu, ortak kanıtlar ve periyodik kalibrasyon
Merkeziyetsiz	Ekipler bağımsızsa ve API'lerin ortak tüketicileri veya riski sınırlıysa	Tekrarlanan API'ler, uyumsuz standartlar ve görünmez maruziyet	Envanter, güvenlik ve sahiplik için minimum kurumsal kontroller

Yüksek riskli kararlar için merkezi kontrolü daha katı tutarken rutin tasarım seçimlerini self-servis bırakabilirsiniz. İşletim modeli ideolojiye göre değil, riske göre belirlenmelidir.

Pratik API yönetişim RACI'si

Organizasyonel değişikliklerden etkilenmemek için bireysel isimler yerine rolleri kullanın.

Etkinlik	Sorumlu (Accountable)	Sorumlu (Responsible)	Danışılacak	Bilgilendirilecek
Kurumsal API yönetişim sonuçlarını ve risk iştahını belirlemek	Üst düzey sponsor	API yönetişim/program lideri	Güvenlik, mimari, hukuk/gizlilik, etki alanı liderleri	API ekipleri
Kurumsal kontrol temel çizgisini sürdürmek	API platformu veya mimari lideri	API etkinleştirme ekibi	Güvenlik, IAM, SRE, etki alanı yöneticileri	Ürün ve teslimat ekipleri
Etki alanı standartlarını ve yeniden kullanılabilir kalıpları sürdürmek	Etki alanı mimari lideri	Etki alanı API yöneticisi	Merkezi etkinleştirme, güvenlik, teslimat temsilcileri	Etki alanı ekipleri
API sahibini, tüketicileri, katmanı ve yaşam döngüsü durumunu güncel tutmak	Etki alanı/ürün lideri	API ürün sahibi	Teknik lider, platform ekibi	Tüketiciler
Tasarım, dokümantasyon, test ve sürüm kontrollerini uygulamak	API ürün sahibi	Teslimat ekibi	API yöneticisi, QA, gerektiğinde güvenlik	Platform/program lideri
Çalışma zamanı kimlik doğrulama, trafik, günlükleme ve gözlemlenebilirlik kontrollerini işletmek	Hizmet/platform operasyon lideri	Hizmet ekibi, SRE, ağ geçidi veya güvenlik ekibi	API sahibi, güvenlik	Yönetişim programı
Yönetim çalışma alanı erişimini sağlamak, incelemek ve kaldırmak	IAM sahibi	IAM/BT ve çalışma alanı yöneticileri	Ekip sahipleri, güvenlik	Yönetişim programı
Yüksek riskli istisnayı onaylamak	Belirlenmiş risk sahibi	API sahibi isteği hazırlar	Kontrol sahibi, güvenlik/gizlilik, mimari	Program lideri ve etkilenen tüketiciler
Metrikleri incelemek ve çerçeveyi geliştirmek	API yönetişim/program lideri	Etkinleştirme ve veri sahipleri	Etki alanı yöneticileri, geliştirici temsilcileri, risk sahipleri	Üst düzey sponsor

Her etkinlik için bir accountable rol bulunmalıdır. Birden fazla accountable sahip, çoğu zaman nihai kararı kimsenin verememesi anlamına gelir.

3. API'leri envantere alın ve risk katmanları atayın

Bilinmeyen bir portföye yönetişim uygulayamazsınız. Minimum envanter alanları şunlardır:

• API adı ve kararlı tanımlayıcı;
• iş veya ürün sahibi;
• teknik sahip ve destek kişisi;
• etki alanı ve tüketiciler;
• arayüz tipi ve doğruluk kaynağı;
• maruziyet: dahili, iş ortağı veya genel;
• veri sınıflandırması;
• iş kritikliği;
• yaşam döngüsü durumu ve inceleme tarihi;
• dağıtım ve çalışma zamanı sahibi;
• bağımlılıklar ve bilinen tüketiciler;
• risk katmanı ve gerekçesi.

Bu envanteri API kataloğuna ve API yaşam döngüsü sürecine bağlayın. API kataloğu veya bir e-tabloyla başlayabilirsiniz; ancak sahiplik ve yaşam döngüsü bilgilerinin ekiplerin güncel tutabileceği bir sisteme taşınması gerekir.

Üç katmanlı örnek risk modeli

Katman	Tipik göstergeler	Örnek kontrol uygulaması
1. Kritik veya yüksek riskli	Genel veya iş ortağı maruziyeti; düzenlenmiş ya da yüksek hassasiyetli veriler; finansal veya güvenlik etkisi; geniş tüketici tabanı; kritik iş bağımlılığı	Resmi sahiplik, mimari/güvenlik incelemesi, güçlü sürüm kanıtı, test edilmiş uyumluluk ve kullanımdan kaldırma, kısa iyileştirme hedefleri, periyodik erişim incelemesi ve çalışma zamanı kanıtı
2. Önemli	Dahili veya sınırlı iş ortağı kullanımı; önemli iş akışı; orta düzey veri hassasiyeti; birkaç bağımlı ekip	Kurumsal temel çizgi, otomatik veya kullanıcı tetiklemeli tasarım/dokümantasyon kontrolleri, gerekli testler, adlandırılmış sahip, önemli güncellemelerde değişiklik incelemesi ve planlı erişim incelemesi
3. Düşük riskli veya deneysel	Geçici prototip; düşük hassasiyetli dahili kullanım; sınırlı tüketici ve etki	Hafif temel çizgi, sahip ve sona erme tarihi, minimum kimlik bilgisi ve erişim kuralları, geniş kullanımdan önce açık tanıtım kriterleri

Risk katmanını yalnızca maruziyete göre belirlemeyin. Yüksek hassasiyetli çalışan verilerini işleyen özel bir API, basit bir genel salt okunur API'den daha fazla kontrol gerektirebilir.

Benzer API'leri değerlendiren ekiplerin benzer kararlar verebilmesi için kullanılan faktörleri ve gerekçeyi kaydedin.

4. Sürümlü bir kontrol kitaplığı oluşturun

Aşağıdaki ayrımı koruyun:

• Politika: Gerekli sonucu belirtir.
• Standart: Onaylanmış çalışma şeklini tanımlar.
• Kontrol: Sapmayı önler, tespit eder veya kaydeder.
• Kanıt: Ne olduğunu gösterir.

Örnek:

• Politika: Paylaşılan API varlıkları düz metin üretim kimlik bilgileri içermemelidir.
• Standart: Hassas kimlik doğrulama değerleri yalnızca onaylanmış yerel değişkenler veya Vault referansları kullanır.
• Önleyici kontrol: Kimlik bilgisi politikası, desteklenmeyen düz metin değerlerinin kaydedilmesini engeller.
• Tespit edici kontrol: Tarayıcı, desteklenen varlıklarda olası sırları belirler.
• Düzeltici süreç: Ekip değeri kaldırır, veren sistemde iptal eder veya döndürür; maruziyeti inceler ve çözümü kaydeder.
• Kanıt: Politika sonucu, tarayıcı bulgusu, harici döndürme bileti ve kapatma kaydı.

Temel kontrol alanları

Etki alanı	Kontrol kitaplığının yanıtlaması gereken sorular
Sahiplik ve işletim modeli	Accountable sahip kim? Standartları ve istisnaları kim onaylıyor?
Portföy ve yaşam döngüsü	API envantere alınmış, sınıflandırılmış, incelenmiş, kullanımdan kaldırılmış ve bilinçli olarak kullanımdan çekilmiş mi?
Tasarım ve sözleşmeler	Makine tarafından okunabilir sözleşme var mı? Adlandırma, hatalar, sayfalama, uyumluluk ve yeniden kullanılabilir şemalar ele alınmış mı?
Dokümantasyon ve keşif	Tüketiciler API'yi bulabiliyor ve kimlik doğrulama, parametreler, kısıtlamalar, yanıtlar, hatalar, örnekler ve değişiklik durumunu anlayabiliyor mu?
Test ve sürüm	Sürümden önce hangi sözleşme, işlevsel, güvenlik, performans ve uyumluluk kontrolleri gerekli?
Kimlik ve yönetim erişimi	Kimler katılabilir, yönetebilir, düzenleyebilir, yayınlayabilir, dışa aktarabilir veya görüntüleyebilir? Erişim nasıl incelenip kaldırılacak?
Kimlik bilgileri ve hassas veriler	Sırlar nerede saklanabilir? Maruziyet sonrası nasıl referans alınır, tespit edilir, döndürülür ve kaldırılır?
Kaynak kontrolü ve tedarik zinciri	Hangi depolar, dallar, incelemeler, bağımlılıklar ve yapıt akışları onaylı?
Çalışma zamanı koruması ve operasyonlar	Dağıtımdan sonra hangi ağ geçidi, yetkilendirme, tehdit, günlükleme, izleme, esneklik ve olay kontrolleri uygulanacak?
Kanıt ve istisnalar	Hangi kayıtlar operasyonu kanıtlar, ne kadar saklanır ve sapmayı kim onaylayabilir?

API tasarım yönergeleri test edilebilecek kadar spesifik olmalıdır. Google API Tasarım Kılavuzu ve Microsoft REST API Yönergeleri, genel tercihlerin somut kurallara nasıl dönüştürülebileceğini gösterir.

Yalnızca tüketicilerinize ve mimarinize uyan kuralları benimseyin. Her kurala şu alanları atayın:

• sahip;
• sürüm;
• yürürlük tarihi;
• geçerli örnek;
• geçiş yolu.

5. Kontrol modunu seçin

Her gereksinim katı bir geçit olmamalıdır. Modu; risk, determinizm, olgunluk ve yanlış pozitif maliyetine göre seçin.

Mod	Ne yapar?	En iyi olduğu durumlar	Kaçınılması gereken durumlar
Yönlendirme	Şablonlar, örnekler, yeniden kullanılabilir bileşenler ve satır içi talimatlar sağlar	Yeni standartlar, karmaşık tasarım kararları ve self-servis etkinleştirme	Güvenilir önleme veya kanıt gerekiyorsa
Uyarı	Olası sapmayı bildirir ancak iş akışının devam etmesine izin verir	Benimseme dönemi, düşük riskli sorunlar ve belirsizlik içeren kontroller	Ekipler önemli bir riski süresiz görmezden gelebilecekse
Engelleme	Sorun düzeltilene veya istisna onaylanana kadar kaydetmeyi, birleştirmeyi, sürümlemeyi veya dağıtımı durdurur	Deterministik, yüksek güvenilirliğe sahip ve hızlı iyileştirme yolu olan gereksinimler	Kural öznel, istikrarsız veya yüksek yanlış pozitif üretiyorsa
İnceleme	Kararı yetkili bir kişiye gönderir	Mimari uzlaşmalar, gizlilik bağlamı, yüksek riskli istisnalar ve tüketici yargısı gerektiren değişiklikler	Her rutin değişiklik aynı sınırlı inceleyici havuzuna gidiyorsa

Yaygın bir geçiş modeli şöyledir:

1. Yönlendirme ile örnekleri ve araçları sağlayın.
2. Uyarı modunda benimsemeyi izleyin.
3. Yanlış pozitif oranı ve teslimat etkisi kabul edilebilir olduğunda engellemeye geçin.
4. Bağlam gerektiren kararları inceleme modunda tutun.

Engellemeden önce doğrulayın

1. Kuralın adlandırılmış sahibi ve belgelenmiş gerekçesi var.
2. Kontrol, amaçlanan risk için yeterince deterministik.
3. Ekipler açık hata açıklaması ve uyumlu bir örnek alıyor.
4. Normal iş akışı içinde iyileştirme yolu mevcut.
5. İstisna yolu ve yanıt hedefi tanımlı.
6. Yanlış pozitifler, atlatmalar ve teslimat etkisi ölçülebiliyor.

6. API yönetişim kontrol matrisini oluşturun

Kontrol matrisi çerçevenin çalışma kaydıdır. Uygulanabilecek kadar ayrıntılı, incelenebilecek kadar kompakt olmalıdır.

Minimum alanlar:

• kontrol kimliği ve etki alanı;
• amaç ve gereksinim;
• kapsam ve geçerli risk katmanları;
• yaşam döngüsü tetikleyicisi;
• mod: yönlendirme, uyarı, engelleme veya inceleme;
• accountable ve responsible roller;
• uygulama sistemi;
• kanıt ve kayıt sistemi;
• inceleme veya yürütme sıklığı;
• iyileştirme hedefi;
• istisna onaylayıcısı ve sona erme kuralı;
• durum ve son inceleme tarihi.

Örnek API yönetişim kontrol matrisi

Bu tablo başlangıç noktasıdır; evrensel bir uyumluluk kontrol listesi değildir.

Kimlik	Kontrol amacı	Uygulandığı yer	Mod	Accountable sahip	Örnek kanıt	Sıklık veya tetikleyici
GOV-01	Her yönetilen API'nin sorumlu sahibi, risk katmanı, doğruluk kaynağı ve yaşam döngüsü durumu vardır	Tüm yönetilen API'ler	İnceleme	Etki alanı/ürün lideri	Katalog kaydı ve inceleme geçmişi	Oluşturulduğunda; üç ayda bir
DES-01	Üretim API'leri, uygulanabildiğinde onaylanmış makine tarafından okunabilir sözleşme kullanır	Tüm üretim API'leri	Engelle veya incele	API ürün sahibi	Sürümlü OpenAPI veya başka onaylı sözleşme	Oluşturulduğunda ve önemli değişiklikte
DES-02	Sözleşmeler geçerli tasarım ve hata standartlarını izler	1–2. katman; seçilmiş 3. katman	Uyarı, sonra deterministik kurallar için engelleme	API mimari lideri	Lint/kontrol sonucu ve onaylı istisna	Sözleşme değişikliğinde
DOC-01	Uç noktalar amacı, kimlik doğrulamayı, parametreleri, kısıtlamaları, yanıtları, hataları ve temsili örnekleri belgeler	Tüm tüketiciye yönelik API'ler	Uyarı veya inceleme	API ürün sahibi	Dokümantasyon kontrol listesi veya eksiksizlik raporu	Sürümden önce
CHG-01	Kırıcı değişiklikler ve kullanımdan kaldırmalar, onaylı tüketici bilgilendirme ve geçiş sürecini izler	Genel, iş ortağı ve yaygın biçimde yeniden kullanılan dahili API'ler	Engelle ve incele	API ürün sahibi	Uyumluluk sonucu, onay, bildirim ve geçiş planı	Önemli değişiklikte
TST-01	Gerekli sözleşme ve işlevsel testler sürümden önce geçer	Tüm üretim API'leri	Engelleme	Mühendislik lideri	Sürümle bağlantılı test raporu	Her sürümde
IAM-01	Çalışma alanı izinleri en az ayrıcalık ilkesini ve mevcut iş sorumluluklarını yansıtır	Tüm API çalışma alanları	İnceleme	Ekip/çalışma alanı sahibi	Rol ataması ve erişim inceleme kaydı	Üç ayda bir ve rol değişikliğinde
IAM-02	İdari çalışma alanı erişimi, işten ayrılma sonrasında hızla kaldırılır	Tüm API çalışma alanları	Otomatik eylem ve inceleme	IAM sahibi	Yetki kaldırma olayı ve mutabakat sonucu	Olayda; aylık mutabakat
SEC-01	Hassas kimlik doğrulama değerleri, paylaşılan düz metin yerine onaylı referanslar kullanır	Tüm paylaşılan API varlıkları	Engelleme	Güvenlik/platform sahibi	Politika sonucu veya yapılandırma kaydı	Kaydetme veya değişiklikte
SEC-02	Şüpheli ifşa edilmiş kimlik bilgileri ayrıştırılır, kaldırılır, harici olarak iptal edilir veya döndürülür ve gerekçeyle kapatılır	Tüm desteklenen varlıklar	Tespit et ve incele	Ekip sahibi	Bulgu, kaynak kaldırma, harici döndürme bileti ve kapatma kaydı	Tespit edildiğinde; haftalık eskime incelemesi
SRC-01	Yönetilen sözleşmeler onaylanmış depo, izin, dal ve inceleme yollarını kullanır	1–2. katman	Kaynak kontrolde engelleme	Platform/kaynak kontrol sahibi	Depo ayarları ve çekme isteği geçmişi	Değişiklikte; üç aylık inceleme
AUD-01	Güvenlikle ilgili idari eylemler kanıt planına göre toplanır ve incelenir	1. katman ve düzenlenmiş programlar	Kayıt ve inceleme	Güvenlik/uyumluluk sahibi	Dışa aktarma, API koleksiyonu, SIEM kaydı ve inceleme bileti	Günlük toplama; aylık inceleme
RUN-01	Maruz kalan API'ler onaylı çalışma zamanı kimlik doğrulama, yetkilendirme, trafik, tehdit ve günlükleme kontrollerini kullanır	Genel, iş ortağı ve hassas dahili API'ler	Dağıtım/çalışma zamanında engelleme	Çalışma zamanı platformu/güvenlik sahibi	Ağ geçidi politikası, yetkilendirme testi, çalışma zamanı günlükleri ve izleme	Dağıtım ve sürekli operasyon
LIF-01	Kullanımdan kaldırılan API'lerin sahibi, tüketici planı, tarihleri ve doğrulanmış kullanımdan çekilme kaydı vardır	Genel, iş ortağı ve yeniden kullanılan dahili API'ler	İnceleme	API ürün sahibi	Katalog durumu, bildirimler, geçiş takibi ve kullanımdan çekme onayı	Kullanımdan çekilene kadar aylık

İndirilebilir matris, bu örneği kontrol modu tanımları, RACI alanları, kanıt rehberliği, olgunluk puanlaması, uygulama takibi ve bir Apidog yetenek haritasıyla genişletir.

7. Kanıt ve istisnaları birinci sınıf iş akışları olarak tasarlayın

Kanıt belirli bir soruyu yanıtlamalıdır

Yalnızca mevcut oldukları için günlük toplamayın. Her kontrol için şu alanları tanımlayın:

• kanıtın desteklediği karar veya gereksinim;
• kaynak sistem ve accountable sahip;
• yorumlama için gereken alanlar;
• toplama ve inceleme sıklığı;
• saklama ve erişim gereksinimleri;
• boşlukların veya başarısız kontrollerin nasıl iyileştirme çalışmasına dönüşeceği;
• kanıtın hassas veri sızıntısına karşı nasıl korunacağı.

Kanıtın sınırlarını da açıkça belirleyin:

• Test raporu, belirli bir yapıt üzerinde testin çalışıp geçtiğini gösterebilir; her önemli riski kapsadığını kanıtlamaz.
• İdari denetim olayı, rolü kimin değiştirdiğini gösterebilir; çalışma zamanı istek günlüğü değildir.
• Tasarım incelemesi, bir uç noktanın belirli bir zamanda kontrol edildiğini gösterebilir; sürekli üretim uygulamasını kanıtlamaz.

Kanıtları doğru katmana eşleyin:

• API geliştirme platformu;
• kaynak kontrolü;
• CI/CD;
• kimlik sağlayıcı;
• ağ geçidi;
• bulut platformu;
• SIEM;
• gözlemlenebilirlik sistemi;
• biletleme platformu;
• risk kaydı.

Çoğu kurumsal kontrol birden fazla sisteme ihtiyaç duyar.

Her istisnanın sona erme tarihi olmalıdır

Kullanılabilir bir istisna kaydı şunları içerir:

• etkilenen API, sürüm, ortam ve kontrol kimliği;
• gereksinimin neden şu anda karşılanamadığı;
• risk ve etkilenen tüketiciler veya veriler;
• telafi edici kontrol;
• iyileştirme veya risk kabul kararı;
• accountable sahip ve onaylayıcı;
• başlangıç, sona erme ve inceleme tarihleri;
• kanıt ve bağlantılı iş öğeleri;
• nihai kapatma, yenileme veya yükseltme kararı.

İstisna talep etmek kolay, unutmak zor olmalıdır. İstisnaları yaşa, riske, ekibe ve kontrole göre düzenli olarak inceleyin. Aynı kurala karşı tekrarlanan istisnalar, kuralın veya temel çizginin yeniden değerlendirilmesi gerektiğine işaret eder.