Bir API yönetişim çerçevesi, geniş ilkeleri ekiplerin tekrarlayabileceği kararlara dönüştürür. Hangi API'lerin kapsamda olduğunu, her kararın kime ait olduğunu, hangi kontrollerin uygulandığını, bu kontrollerin nerede çalıştığını, hangi kanıtları ürettiklerini ve istisnaların nasıl onaylandığını belirler.
Bu operasyonel detay, bir yönetişim belgesi ile bir yönetişim sistemi arasındaki farktır.
Bu kılavuz, kurumsal API programları için pratik bir çerçeve sunar. İçeriği:
- yedi katmanlı bir işletim modeli;
- merkezi ve federatif karar hakları;
- yaygın yönetişim faaliyetleri için bir RACI;
- orantılı kontroller uygulamak için risk katmanları;
- yönlendirme, uyarı, engelleme ve inceleme kontrol modları;
- örnek bir API yönetişim kontrol matrisi;
- bir istisna ve kanıt modeli;
- beş seviyeli bir olgunluk modeli;
- 12 haftalık bir uygulama yol haritası.
Öncelikle daha geniş tanım, iş gerekçesi, metrikler ve araç kategorilerine ihtiyacınız varsa, API Yönetişimi Nedir? ile başlayın. Bu makale uygulamayla başlar.
API yönetişim çerçevesi nedir?
Bir API yönetişim çerçevesi, bir kuruluşun API ile ilgili kararları alması ve doğrulaması için kullandığı işletim sistemidir. Politikaları ve standartları API yaşam döngüsü boyunca sahiplere, kontrollere, kanıtlara, ölçümlere ve istisnalara bağlar.
Eksiksiz bir çerçeve yedi soruyu yanıtlamalıdır:
- Sonuçlar: Korumaya çalıştığımız iş, tüketici, güvenlik veya operasyonel sonuç nedir?
- Kapsam: Hangi API'ler, ekipler, ortamlar ve yaşam döngüsü aşamaları kapsanmaktadır?
- Karar hakları: Temel çizgiyi kim tanımlar, her API'nin sahibi kimdir, istisnaları kim onaylar ve bulguları kim çözer?
- Risk: Hangi API'lerin daha güçlü kontrollere ihtiyacı var ve neden?
- Kontroller: Ekipler ne yapmalı ve kontrol yönlendirmeli, uyarmalı, engellemeli veya inceleme mi gerektirmeli?
- Kanıt: Kuruluş, kontrolün çalıştığını nasıl bilecek?
- Geliştirme: Yönetişimin sunumu aksatmadan riski azaltıp azaltmadığını hangi ölçümler gösterir?
Her şirketin olduğu gibi kopyalayabileceği tek bir evrensel API yönetişim standardı yoktur. Çerçeve, kuruluşun mimarisini, tüketicilerini, verilerini, dağıtım modelini, düzenleyici bağlamını ve risk iştahını yansıtmalıdır. Harici referanslar bunu bilgilendirebilir: OpenAPI Spesifikasyonu makine tarafından okunabilir bir API sözleşme formatı tanımlar; OWASP API Güvenliği İlk 10 güvenlik riski girdisi sağlar; ve NIST Siber Güvenlik Çerçevesi yönetişim, roller, politika, risk ve denetim için daha geniş bir model sunar. Bu kaynakların hiçbiri kuruluşa özgü sahiplik ve kararların yerini almaz.
Bir API yönetişim çerçevesinin yedi katmanı
Çerçeveyi uzun bir politika belgesi yerine yedi bağlantılı katman olarak ele alın.
| Katman | Alınacak Karar | Minimum Çıktı |
|---|---|---|
| 1. Sonuçlar ve kapsam | Yönetişim neden var ve neyi kapsar? | Sonuç beyanı, kapsam, istisnalar ve inceleme tarihi |
| 2. İşletim modeli | Standartların, API'lerin, kontrollerin, kanıtların ve istisnaların sahibi kimdir? | Karar hakları haritası ve RACI |
| 3. Portföy ve risk | Hangi API'ler mevcut ve her birinin ne kadar kontrole ihtiyacı var? | Envanter, sahip, yaşam döngüsü durumu ve risk katmanı |
| 4. Kontrol alanları | Tasarım, erişim, güvenlik, değişiklik ve operasyonlar genelinde hangi gereksinimler geçerlidir? | 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 |
| 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 zayıflatır. Sahibi olmayan kesin bir standart isteğe bağlı hale gelir. İstisna süreci olmayan engelleyici bir kontrol, gizli geçici çözümler yaratır. Belirtilmiş bir gereksinim olmayan bir denetim izi, etkinliği kaydeder ancak 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 tanıyabileceğ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şirken öngörülebilir kalır;
- yüksek riskli API'ler uygun güvenlik ve gizlilik incelemesi alır;
- 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 artık ihtiyaç duymadığında erişim kaldırılır;
- kullanımdan kaldırmalar tüketicilere belgelenmiş bir geçiş yolu sunar;
- inceleyiciler önemli kararları ve idari eylemleri yeniden oluşturabilir.
“Tüm API'ler uyumlu olmalı” gibi belirsiz hedeflerden kaçının. Neye uyumlu, hangi API'ler için, hangi noktada ve kimin kararına göre? Ölçülebilir bir sonuç yazın ve ardından bunu desteklemek için gereken politika ve kontrolleri belirleyin.
Açık Sınırlar Belirleyin
Çerçevenin neleri kapsadığını belgeleyin:
- REST, GraphQL, gRPC, olay tabanlı API'ler veya 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. İlk sürüm, mevcut genel API'lerdeki yeni REST API'leri ve önemli değişiklikleri kapsayabilirken, eski sistem iyileştirmesi ayrı bir risk tabanlı planı takip eder. Açık bir istisna yönetilebilir; varsayılan bir istisna ise kör nokta haline gelir.
2. Bir işletim modeli seçin ve karar haklarını atayın
Yönetişim genellikle iki uç noktadan birinde başarısız olur. Merkezi bir komite her kararı onaylar ve bir darboğaz haline gelir veya her ekip politikayı bağımsız olarak yorumlar ve kuruluşun tutarlı bir temel çizgisi olmaz.
Çoğu büyük kuruluşun federatif bir modele ihtiyacı vardır:
- merkezi bir API platformu veya etkinleştirme grubu, kurumsal temel çizgiyi, paylaşılan şablonları, ortak araçları ve program raporlamasını sahiplenir;
- etki alanı yöneticileri temel çizgiyi etki alanına özgü rehberliğe çevirir ve ekiplerin bunu uygulamasına yardımcı olur;
- API ürün sahipleri, bireysel API'ler ve tüketici sonuçları için sorumlu kalır;
- güvenlik, gizlilik, IAM, SRE ve uyumluluk uzmanları kendi alanlarındaki kontrolleri sahiplenir veya inceler;
- teslimat ekipleri kontrolleri uygular ve bulguları giderir;
- tanımlanmış bir risk sahibi, zaman sınırlı istisnaları onaylar.
Federasyon, “ekipler her şeye karar verir” anlamına gelmez. Yetkinin açık sınırlar, kanıtlar ve yükseltme yolları ile dağıtıldığı 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 tutarsız uygulamalarla başlıyor | İnceleme kuyrukları ve yavaş kararlar | Hizmet seviyesi hedefleri, yeniden kullanılabilir kalıplar ve yetkilendirme kriterleri |
| Federatif | Birçok etki alanı kurumsal bir temel çizgiyi paylaşır ancak yerel uzmanlığa ve özerkliğe ihtiyaç duyar | 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ızdır ve API'lerin sınırlı paylaşılan tüketicileri veya riski vardır | Tekrarlanan API'ler, uyumsuz standartlar ve görünmez pozlama | Envanter, güvenlik ve sahiplik için minimum kurumsal kontroller |
Merkezi kontrol, yüksek riskli kararlar için daha katı olabilirken, rutin tasarım seçimleri self-servis olarak kalır. İşletim modeli ideolojiye göre değil, riske göre değişmelidir.
Pratik bir API yönetişim RACI'si
Modelin organizasyonel değişikliklerden etkilenmemesi için bireysel isimler yerine roller kullanın.
| Etkinlik | Sorumlu (Accountable) | Sorumlu (Responsible) | Danışılacak | Bilgilendirilecek |
|---|---|---|---|---|
| Kurumsal API yönetişim sonuçlarını ve risk iştahını belirle | Ü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ür | 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ür | Etki alanı mimari lideri | Etki alanı API yöneticisi | Merkezi etkinleştirme, güvenlik, teslimat temsilcileri | Etki alanı ekipleri |
| Bir API'nin sahibini, tüketicilerini, katmanını ve yaşam döngüsü durumunu güncel tut | 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 uygula | API ürün sahibi | Teslimat ekibi | API yöneticisi, Kalite Güvence (QA), gerektiğinde güvenlik | Platform/program lideri |
| Çalışma zamanı kimlik doğrulama, trafik, günlükleme ve gözlemlenebilirlik kontrollerini işlet | 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ğla, incele ve kaldır | IAM sahibi | IAM/BT ve çalışma alanı yöneticileri | Ekip sahipleri, güvenlik | Yönetişim programı |
| Yüksek riskli bir istisnayı onayla | Belirlenmiş risk sahibi | API sahibi isteği hazırlar | Kontrol sahibi, güvenlik/gizlilik, mimari | Program lideri ve etkilenen tüketiciler |
| Metrikleri incele ve çerçeveyi geliştir | API yönetişim/program lideri | Etkinleştirme ve veri sahipleri | Etki alanı yöneticileri, geliştirici temsilcileri, risk sahipleri | Üst düzey sponsor |
Tam unvanlar farklılık gösterecektir, ancak her etkinlik için bir sorumlu (accountable) rol gereklidir. Birden fazla sorumlu (accountable) sahip olması genellikle kimsenin nihai kararı veremeyeceği anlamına gelir.
3. API'leri envantere al ve risk katmanları ata
Bilinmeyen bir portföye bir çerçeve uygulayamazsınız. Minimum olarak şunları kaydedin:
- API adı ve kararlı tanımlayıcı;
- sorumlu iş veya ürün sahibi;
- teknik sahip ve destek kişisi;
- etki alanı ve tüketiciler;
- arayüz tipi ve doğruluk kaynağı;
- maruz kalma: 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 nedeni.
Bu envanteri API kataloğunuza ve API yaşam döngüsü sürecinize bağlayın. Bir e-tablo işi başlatabilir, ancak sahiplik ve yaşam döngüsü bilgileri sonunda ekiplerin güncel tutabileceği bir yerde olmalıdır.
Üç Katmanlı Örnek Bir Model
| Katman | Tipik göstergeler | Örnek kontrol uygulaması |
|---|---|---|
| 1. Katman: Kritik veya yüksek riskli | Genel veya iş ortağı maruziyeti; düzenlenmiş veya yüksek hassasiyetli veriler; finansal veya güvenlik etkisi; geniş tüketici tabanı; kritik iş bağımlılığı | Resmi sahip ve mimari/güvenlik incelemesi, daha güçlü sürüm kanıtı, test edilmiş uyumluluk ve kullanımdan kaldırma, daha kısa iyileştirme hedefleri, periyodik erişim incelemesi, çalışma zamanı kanıtı |
| 2. Katman: Önemli | Dahili veya sınırlı iş ortağı kullanımı; önemli iş akışı; orta düzeyde 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üncellemeler için değişiklik incelemesi, planlı erişim incelemesi |
| 3. Katman: Düşük riskli veya deneysel | Geçici prototip; düşük hassasiyetli dahili kullanım; sınırlı tüketiciler ve etki | Hafif temel çizgi, sahip ve sona erme, minimum kimlik bilgisi ve erişim kuralları, daha geniş kullanımdan önce açık tanıtım kriterleri |
Katmanları yalnızca maruz kalmaya göre atamayın. 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 iki ekibin benzer kararlar alabilmesi için çeşitli faktörler kullanın ve gerekçeyi kaydedin.
4. Sürümlü bir kontrol kitaplığı oluşturun
Bir politika, gerekli bir sonucu belirtir. Bir standart, onaylanmış bir çalışma şeklini tanımlar. Bir kontrol, bir sapmayı önler, tespit eder veya kaydeder. Kanıtlar ne olduğunu gösterir. Bu yapıtları bağlantılı tutun.
Örneğin:
- Politika: Paylaşılan API varlıkları düz metin üretim kimlik bilgileri içermemelidir.
- Standart: Hassas kimlik doğrulama değerleri, onaylanmış yalnızca yerel değişkenler veya Vault referansları kullanır.
- Önleyici kontrol: Bir kimlik bilgisi politikası, desteklenmeyen düz metin değerlerinin kaydedilmesini engeller.
- Tespit edici kontrol: Bir tarayıcı, desteklenen varlıklarda olası bir sırrı tanımlar.
- Düzeltici süreç: Ekip değeri kaldırır, ihraç eden sistemde iptal eder veya döndürür, maruziyeti kontrol eder 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 | Sorumlu (accountable) bir sahip belirtilmiş mi? Standartları ve istisnaları kim onaylar? |
| Portföy ve yaşam döngüsü | API envantere alınmış, sınıflandırılmış, incelenmiş, kullanımdan kaldırılmış ve kasıtlı olarak kullanımdan çekilmiş mi? |
| Tasarım ve sözleşmeler | Makine tarafından okunabilir bir 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 bulabilir ve kimlik doğrulama, parametreler, kısıtlamalar, yanıtlar, hatalar, örnekler ve değişiklik durumunu anlayabilir mi? |
| Test ve sürüm | Sürümden önce hangi sözleşme, işlevsel, güvenlik, performans ve uyumluluk kontrolleri gereklidir? |
| Kimlik ve yönetim erişimi | API varlıklarına kimler katılabilir, yönetebilir, düzenleyebilir, yayınlayabilir, dışa aktarabilir veya görüntüleyebilir? Erişim nasıl incelenir ve kaldırılır? |
| Kimlik bilgileri ve hassas veriler | Sırlar nerede saklanabilir? Maruz kaldıktan sonra 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ı onaylanmıştır? |
| Çalışma zamanı koruması ve operasyonlar | Dağıtımdan sonra hangi ağ geçidi, yetkilendirme, tehdit, günlükleme, izleme, esneklik ve olay kontrolleri uygulanır? |
| Kanıt ve istisnalar | Hangi kayıtlar operasyonu kanıtlar, ne kadar süreyle saklanır ve bir 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 gibi genel örnekler, kuruluşların genel tercihleri somut kurallara nasıl dönüştürdüğünü gösterir. Yalnızca tüketicilerinize ve mimarinize uyan kuralları benimseyin ve her kurala bir sahip, sürüm, yürürlük tarihi, örnek ve geçiş yolu atayın.
5. Doğru kontrol modunu seçin: yönlendirme, uyarı, engelleme veya inceleme
Her gereksinim katı bir geçit olmamalıdır. Riski, determinizmi, olgunluğu ve yanlış pozitif maliyetini temel alarak bir mod 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 seçimleri ve self-servis etkinleştirme | Risk, güvenilir önleme veya kanıt gerektiriyorsa |
| Uyarı | Olası bir sapmayı bildirir ancak iş akışının devam etmesine izin verir | Benimseme dönemleri, daha düşük riskli sorunlar ve bazı belirsizlik içeren kontroller | Ekipler önemli bir riski süresiz olarak göz ardı edebilir |
| Engelleme | Sorun düzeltilene veya bir istisna onaylanana kadar kaydetmeyi, birleştirmeyi, sürümü veya dağıtımı engeller | Hızlı bir iyileştirme yolu olan deterministik, yüksek güvenilirliğe sahip gereksinimler | Kural sübjektif, istikrarsız veya rahatsız edici yanlış pozitifler üretmeye yatkınsa |
| İnceleme | Kararı yetkili bir insana 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ı kıt inceleyiciyi gerektiriyorsa |
Etkili bir dağıtım genellikle ekiplerin örneklere, araçlara ve ölçülen yanlış pozitif oranına sahip olmasından sonra yönlendirme modundan uyarı moduna ve ardından engelleme moduna geçer. Bağlam önemli olduğu için bazı kararlar her zaman inceleme olarak kalmalıdır.
Engellemeden önce şunları doğrulayın:
- kuralın adlandırılmış bir sahibi ve belgelenmiş bir gerekçesi var;
- kontrol, amaçlanan risk için yeterince deterministiktir;
- ekipler net bir açıklama ve uyumlu bir örnek alır;
- normal iş akışı içinde iyileştirme mevcuttur;
- bir istisna yolu mevcut ve bir yanıt hedefi var;
- kuruluş yanlış pozitifleri, atlatmaları ve teslimat etkisini ölçebilir.
6. API yönetişim kontrol matrisini oluşturun
Kontrol matrisi, çerçevenin çalışma kaydıdır. Uygulanabilecek kadar ayrıntılı ancak incelenebilecek kadar kompakt olmalıdır.
Minimum olarak şunları içerir:
- 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;
- sorumlu (accountable) ve sorumlu (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 örnek bir başlangıç noktasıdır, evrensel bir uyumluluk kontrol listesi değildir.
| Kimlik | Kontrol amacı | Uygulandığı yer | Mod | Sorumlu (Accountable) sahip | Örnek kanıt | Sıklık veya tetikleyici |
|---|---|---|---|---|---|---|
| GOV-01 | Her yönetilen API'nin sorumlu bir 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 bir sözleşme kullanır | Tüm üretim API'leri | Engelle veya incele | API ürün sahibi | Sürümlü OpenAPI veya diğer onaylanmış sözleşme | Oluşturulduğunda ve önemli değişiklikte |
| DES-02 | Sözleşmeler geçerli tasarım ve hata standartlarını takip eder | 1–2. Katman; seçilmiş 3. Katman | Uyarı, sonra deterministik kurallar için engelle | API mimari lideri | Lint/kontrol sonucu ve onaylanmış 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 incele | 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, onaylanmış tüketici bilgilendirme ve geçiş sürecini takip eder | Genel, iş ortağı ve yaygın olarak 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 | Engelle | 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 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, bir işten ayrılma olayından sonra hızla kaldırılır | Tüm API çalışma alanları | Otomatik eylem ve inceleme | IAM sahibi | Sağlamayı kaldırma olayı ve mutabakat sonucu | Olayda; aylık mutabakat |
| SEC-01 | Hassas kimlik doğrulama değerleri, paylaşılan düz metin yerine onaylanmış referanslar kullanır | Tüm paylaşılan API varlıkları | Engelle | 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 bir nedenle 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 | Tespit edildiğinde; haftalık eskime incelemesi |
| SRC-01 | Yönetilen sözleşmeler onaylanmış depolar, izinler, dallar ve inceleme yolları kullanır | 1–2. Katman | Kaynak kontrolde engelle | 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 onaylanmış ç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 engelle | Ç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 bir sahibi, tüketici planı, tarihleri ve doğrulanmış kullanımdan çekilmesi 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ı ile 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 var oldukları için günlükleri toplamayın. Her kontrol için şunları tanımlayın:
- kanıtın desteklediği karar veya gereksinim;
- kaynak sistem ve sorumlu (accountable) sahip;
- yorumlamak 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ı yarattığı;
- kanıtın hassas veri sızıntısından nasıl korunduğu.
Bir test raporu, belirli bir yapıta karşı bir testin çalıştığını ve geçtiğini gösterebilir. Her önemli riski kapsadığını kanıtlamaz. İdari bir denetim olayı, bir rolü kimin değiştirdiğini gösterebilir. Bir çalışma zamanı istek günlüğü değildir. Bir tasarım incelemesi, bir uç noktanın belirli bir zamanda kontrol edildiğini gösterebilir. Sürekli üretim uygulaması değildir.
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 veya risk kaydı. Çoğu kurumsal kontrol birden fazla sisteme ihtiyaç duyar.
Her istisnanın bir 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 şu anda karşılanamama nedeni;
- risk ve etkilenen tüketiciler veya veriler;
- telafi edici kontrol;
- iyileştirme veya risk kabul kararı;
- sorumlu (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ı.
İstisnalar talep etmesi kolay, ancak unutması zor olmalıdır. Bunları yaşa, riske, ekibe ve kontrole göre inceleyin. Aynı kurala karşı