TL;DR: Rol Tabanlı Erişim Kontrolü (RBAC), izinleri bireysel kullanıcılara değil rollere atayan bir güvenlik modelidir. API ekipleri için RBAC; erişimi ölçeklenebilir, denetlenebilir ve yönetilebilir hale getirir. API işbirliği için iyi bir RBAC yapısı Kuruluş → Ekip → Proje seviyelerinde izin hiyerarşisi, özel rol desteği ve SSO/SCIM gibi kurumsal entegrasyonlar sunmalıdır. Apidog, üç seviyede 12 yerleşik rol ve kurumsal ekipler için özel proje rolleriyle API varlıklarınızı kimlerin görüntüleyebileceğini, düzenleyebileceğini, test edebileceğini veya yönetebileceğini kontrol etmenizi sağlar.
API Ekipleri İçin RBAC Neden Önemlidir?
API geliştirme genellikle birden fazla rolü içerir:
- Geliştiriciler uç noktaları yazar.
- QA mühendisleri testleri çalıştırır.
- Ürün yöneticileri spesifikasyonları inceler.
- Teknik yazarlar dokümantasyon üretir.
- Güvenlik ekipleri erişim günlüklerini denetler.
Yapılandırılmış erişim kontrolü yoksa şu sorunlar ortaya çıkar:
- Acemi bir geliştirici üretim API spesifikasyonunu yanlışlıkla değiştirir.
- Bir yüklenici hassas ödeme uç noktalarını görebilir.
- Ayrılmış bir çalışanın hesabı aylarca aktif kalır.
- Her kullanıcıya ayrı ayrı izin vermek yönetilemez hale gelir.
Bir API Güvenlik Raporu, API güvenlik olaylarının %61'inin yetkisiz erişim veya aşırı izinlerle ilişkili olduğunu göstermiştir. Temel problem çoğu zaman aynıdır: API varlıkları üzerinde kimin ne yapabileceği yeterince ayrıntılı kontrol edilmez.
RBAC bu problemi şu şekilde çözer:
İzinleri rollere bağlar
Kullanıcı değiştiğinde 50 izni değil, rol atamasını güncellersiniz.En az ayrıcalık prensibini uygular
Her kullanıcı yalnızca işi için gerekli yetkileri alır.Denetim izlerini anlamlı hale getirir
Her işlem bir kullanıcıya ve role bağlanabilir.Ekip büyümesini ölçekler
Yeni ekip üyeleri için tek tek izin kopyalamak yerine rol atarsınız.
Apidog, API geliştirme iş akışları için tasarlanmış üç katmanlı bir izin modeli kullanır.
Üç Seviyeli İzin Hiyerarşisi
API işbirliğinde tek bir “projeye erişebilir” kontrolü çoğu zaman yeterli değildir. Kurumsal yapılarda izinlerin farklı kapsamları vardır:
| Seviye | Kapsam | Neyi Kontrol Eder |
|---|---|---|
| Kuruluş | Şirket geneli | Faturalandırma, SSO, üye yönetimi, özel rol tanımları |
| Ekip | Departman / iş birimi | Ekip üyeliği, proje oluşturma, ekip kaynakları |
| Proje | Bireysel API | Uç noktalar, testler, dokümantasyon, ortamlar, dallar |
Örnek senaryo:
Kuruluş: Fintech Şirketi
├── Ekip: Ödemeler
├── Ekip: Kimlik
└── Ekip: Analiz
Bu yapıda:
- Ödeme ekibindeki geliştirici Ödeme API'lerine erişmeli.
- Kimlik veya Analiz projelerine otomatik erişmemeli.
- Kuruluş yöneticisi SSO yapılandırabilmeli.
- QA mühendisi test çalıştırabilmeli ama API spesifikasyonunu değiştirmemeli.
Üç seviyeli RBAC iki yaygın hatayı önler:
- Aşırı yetkilendirme: Herkese yönetici vermek.
- İzin boşlukları: Ekip düzeyini yapılandırıp proje ayrıntılarını atlamak.
Kuruluş Düzeyinde Roller ve İzinler
Kuruluş rolleri, şirket genelindeki ayarları yönetir:
- Faturalandırma
- SSO yapılandırması
- Üye yönetimi
- Ekip yönetimi
- Özel rol tanımları
- Kuruluş kaynakları
Yerleşik Kuruluş Rolleri
| Rol | Açıklama | Ana Yetenekler |
|---|---|---|
| Kuruluş Sahibi | Kuruluş yaratıcısı, en yüksek yetki | Kuruluşu yeniden adlandırma, aktarma, kapatma, tam yönetim |
| Kuruluş Yöneticisi | Kuruluş yönetimi | Üyeleri, ekipleri, SSO'yu, özel rolleri ve kaynakları yönetir |
| Kuruluş Üyesi | Temel katılımcı | Ekip ve proje izinlerine göre çalışır |
| Faturalandırma Yöneticisi | Finans odaklı rol | Abonelikleri ve faturalandırmayı yönetir |
Kuruluş Ayarları İzin Matrisi
| Özellik | Kuruluş Sahibi | Kuruluş Yöneticisi | Kuruluş Üyesi | Faturalandırma Yöneticisi |
|---|---|---|---|---|
| Kuruluş ayarlarına erişim | ✅ | ✅ | ❌ | ❌ |
| Kuruluşu yeniden adlandır | ✅ | ✅ | ❌ | ❌ |
| Kuruluş sahipliğini aktar | ✅ | ❌ | ❌ | ❌ |
| Kuruluşu kapat | ✅ | ❌ | ❌ | ❌ |
Ekip Yönetimi İzin Matrisi
| Özellik | Kuruluş Sahibi | Kuruluş Yöneticisi | Kuruluş Üyesi | Faturalandırma Yöneticisi |
|---|---|---|---|---|
| Yeni ekip oluştur | ✅ | ✅ | ❌ | ❌ |
| Ekibi kuruluşa aktar | ✅ | ✅ | ❌ | ❌ |
| Ekibi kuruluştan aktar | ✅ | ✅ | ❌ | ❌ |
Üye Yönetimi İzin Matrisi
| Özellik | Kuruluş Sahibi | Kuruluş Yöneticisi | Kuruluş Üyesi | Faturalandırma Yöneticisi |
|---|---|---|---|---|
| Üye davet et | ✅ | ✅ | ❌ | ❌ |
| Üyenin kuruluş rolünü değiştir | ✅ | ✅ | ❌ | ❌ |
| Üyeleri kaldır | ✅ | ✅ | ❌ | ❌ |
Kuruluş Üyesi rolü bilinçli olarak sınırlıdır. Bu rol kuruluş ayarlarını yönetmez; ekip ve proje seviyesindeki izinlere göre çalışır.
Faturalandırma Yöneticisi bağımsız bir roldür. Bir kullanıcı hem Kuruluş Üyesi hem de Faturalandırma Yöneticisi olabilir. Bu kullanıcı faturalandırmayı yönetebilir ama SSO veya üyeleri yönetemez.
Ekip Düzeyinde Roller ve İzinler
Ekip rolleri, departman veya iş birimi seviyesindeki işlemleri kontrol eder.
Bir ekip şu yapıları temsil edebilir:
- Mobil Ekip
- Backend Ekibi
- QA Ekibi
- Ödemeler Ekibi
- Platform Ekibi
Yerleşik Ekip Rolleri
| Rol | Açıklama | Ana Yetenekler |
|---|---|---|
| Ekip Sahibi | Ekip yaratıcısı | Ekibi aktarır/kapatır, tüm ekip ayarlarını yönetir |
| Ekip Yöneticisi | Ekip operasyonları | Üye davet eder, rol atar, proje oluşturur/siler |
| Ekip Üyesi | Ekip katılımcısı | Üye detaylarını görüntüler, proje izinlerine göre çalışır |
| Misafir | Harici işbirlikçi | Ekip yönetimi yok, yalnızca proje erişimi |
Ekip Yönetimi İzin Matrisi
| İzin | Ekip Sahibi | Ekip Yöneticisi | Ekip Üyesi | Misafir |
|---|---|---|---|---|
| Ekip üyesi detaylarını görüntüle | ✅ | ✅ | ✅ | ❌ |
| Ekip üyelerini davet et | ✅ | ✅ | ❌ | ❌ |
| Ekip üyesi rollerini ata/kaldır | ✅ | ✅ | ❌ | ❌ |
| Proje rollerini görüntüle | ✅ | ✅ | ❌ | ❌ |
| Proje rolleri ekle/düzenle/sil | ✅ | ✅ | ❌ | ❌ |
Ekip Ayarları İzin Matrisi
| İzin | Ekip Sahibi | Ekip Yöneticisi | Ekip Üyesi | Misafir |
|---|---|---|---|---|
| Ekip adını düzenle | ✅ | ✅ | ❌ | ❌ |
| Ekibi aktar | ✅ | ❌ | ❌ | ❌ |
| Ekibi kapat | ✅ | ❌ | ❌ | ❌ |
Proje Operasyonları İzin Matrisi
| İzin | Ekip Sahibi | Ekip Yöneticisi | Ekip Üyesi | Misafir |
|---|---|---|---|---|
| Yeni proje oluştur | ✅ | ✅ | ❌ | ❌ |
| Projeyi kopyala | ✅ | ✅ | ❌ | ❌ |
| Projeyi sil/aktar | ✅ | ✅ | ❌ | ❌ |
| Proje adını düzenle | ✅ | ✅ | ❌ | ❌ |
Misafir rolü, danışmanlar, yükleniciler veya departmanlar arası işbirlikçiler için kullanışlıdır. Misafirler ekip yönetimi özelliklerine erişmez; yalnızca atandıkları projelerde çalışır.
Proje Düzeyinde Roller ve İzinler
Proje rolleri, günlük API çalışmasının gerçekleştiği seviyeyi kontrol eder:
- Uç nokta düzenleme
- Test çalıştırma
- Ortam yönetimi
- Dokümantasyon yayınlama
- Proje ayarları
- İstek geçmişi
- İçe/dışa aktarma
Yerleşik Proje Rolleri
| Rol | Açıklama | Kullanım Durumu |
|---|---|---|
| Yönetici | Tam proje kontrolü | Proje lideri, API sahibi |
| Editör | İçeriği değiştirebilir | Geliştiriciler, QA mühendisleri |
| Salt Okunur | Görüntüleme ve çalıştırma | Ürün yöneticileri, paydaşlar, gözden geçirenler |
| Yasaklı | Erişim yok | Hassas projeler, kısıtlı kullanıcılar |
Proje İzin Kategorileri
Proje izinleri sekiz ana kategoriye ayrılır:
Dal Yönetimi
Sprint dalları, birleştirme istekleri, korumalı dallar, API versiyonları.Uç Nokta Yönetimi
Uç noktalar, durumlar, şemalar, bileşenler, istekler, çöp kutusu işlemleri.Otomatik Testler
Test senaryoları, performans testleri, zamanlanmış görevler, test raporları.Ortam Yönetimi
Genel değişkenler, parametreler, ortamlar, Kasa Sırları.Dokümantasyon Paylaşımı
Hızlı paylaşım, dokümantasyon sitesi yayınlama.Proje Ayarları
Temel ayarlar, üye yönetimi, özellik ayarları, bildirimler.İstek Geçmişi
Yerel ve paylaşılan istek geçmişi.İçe/Dışa Aktarma
Veri içe aktarma, zamanlanmış içe aktarma, dışa aktarma.
Önemli Proje İzinleri
| İzin | Yönetici | Editör | Salt Okunur | Yasaklı |
|---|---|---|---|---|
| Uç noktaları görüntüle/çalıştır | ✅ | ✅ | ✅ | ❌ |
| Uç noktaları ekle/sil/değiştir | ✅ | ✅ | ❌ | ❌ |
| Fonksiyonel testleri çalıştır | ✅ | ✅ | ✅ | ❌ |
| Test senaryoları ekle/sil/değiştir | ✅ | ✅ | ❌ | ❌ |
| Ortam değişkenlerini görüntüle/düzenle | ✅ | ✅ | ✅ | ❌ |
| Ortamları ekle/sil/değiştir | ✅ | ✅ | ❌ | ❌ |
| Kasa Sırlarına erişim | ✅ | ✅ | ❌ | ❌ |
| Dokümantasyon sitesi ayarlarını yayınla | ✅ | ❌ | ❌ | ❌ |
| Projeyi klonla | ✅ | ❌ | ❌ | ❌ |
| Proje üyelerini yönet | ✅ | ❌ | ❌ | ❌ |
Yasaklı rolü, hassas projeler için önemlidir. Bir kullanıcı ekipte kalabilir ama belirli bir projeye sıfır erişime sahip olabilir. Örneğin ödeme API'lerini yalnızca ilgili ekip üyelerine açmak için kullanılabilir.
Ayrıntılı Kontrol İçin Özel Roller
Yerleşik roller çoğu senaryo için yeterlidir. Ancak kurumsal ekiplerde daha özel izin modellerine ihtiyaç duyulabilir. Apidog'un Kurumsal planı, özel proje rolleri oluşturmayı destekler.
Özel Role Ne Zaman İhtiyaç Duyarsınız?
Örnekler:
- QA Mühendisi: Testleri çalıştırabilir ve test senaryolarını değiştirebilir, ancak API spesifikasyonlarını düzenleyemez.
- Teknik Yazar: Dokümantasyonu düzenleyebilir, uç noktaları veya ortamları değiştiremez.
- Güvenlik Denetçisi: Salt okunur erişim alır, Kasa Sırlarını görüntüleyebilir, değişiklik yapamaz.
- Stajyer: Uç noktaları görüntüler ve istek çalıştırır, hiçbir şeyi silemez.
Özel Proje Rolü Oluşturma
Apidog'da özel rol oluşturmak için:
- Ekip → Üyeler → Roller ve İzinler yoluna gidin. veya Kuruluş → Üyeler → Roller ve İzinler bölümünü açın.
- + Ekle düğmesine tıklayın.
- Rol adını belirleyin.
- İzin kategorilerini seçin.
- Rolü kaydedin ve test projesinde doğrulayın.
Yapılandırılabilir İzin Kategorileri
| Kategori | Ayrıntılı Kontroller |
|---|---|
| Dal Yönetimi | Dalları görüntüle, dalları birleştir, birleştirme istekleri gönder, korumalı dalları değiştir |
| Uç Nokta Yönetimi | Görüntüle/çalıştır, ekle/değiştir/sil, kod oluştur, durumları, şemaları, bileşenleri, istekleri yönet |
| Otomatik Testler | Fonksiyonel testleri çalıştır, performans testlerini çalıştır, senaryoları değiştir, zamanlanmış görevleri yönet |
| Ortam Yönetimi | Mevcut değerleri görüntüle/düzenle, ekle/değiştir/sil, Kasa Sırlarını yönet |
| Dokümantasyon | Hızlı paylaşımı görüntüle/değiştir, belge sitelerini önizle, yayınlama ayarlarını yönet |
| Proje Ayarları | Ayarları görüntüle/değiştir, üyeleri yönet, bildirimleri yapılandır, içe/dışa aktarmayı yönet |
| İstek Geçmişi | Yerel geçmişi görüntüle, geçmişi paylaş, paylaşılan geçmişi görüntüle/sil |
Özel Rol İçin Uygulama Önerileri
Mevcut rolden kopyalayarak başlayın
Sıfırdan oluşturmak yerine Editör veya Salt Okunur rolünü kopyalayın.“Tüm İzinler” kutularını dikkatli kullanın
Bir modül için tüm izinleri seçerseniz gelecekte eklenen izinler de otomatik gelebilir.Üretime almadan önce test edin
Test projesi oluşturun, rolü atayın ve davranışı doğrulayın.Rol adlandırma standardı belirleyin
Örnek:QA-Test-Editor,Docs-Editor,Security-ReadOnly.Üç ayda bir gözden geçirin
Rol sürünmesini ve gereksiz izinleri temizleyin.
Kurumsal Güvenlik Özellikleri
RBAC tek başına yeterli değildir. Kurumsal API ekipleri genellikle kimlik yönetimi, otomatik sağlama ve sır yönetimi gibi ek güvenlik özelliklerine ihtiyaç duyar.
Apidog, RBAC ile birlikte çalışan şu kurumsal güvenlik özelliklerini destekler:
- SSO
- SCIM
- Grup eşlemesi
- Kasa Sırları
- Denetim günlükleri
Tek Oturum Açma: SSO
SAML 2.0 ile SSO, kimlik doğrulamayı merkezi hale getirir.
Desteklenen kimlik sağlayıcı örnekleri:
- Microsoft Entra ID / Azure Active Directory
- Okta
- Google Workspace
- OneLogin
- Özel SAML 2.0 sağlayıcıları
SSO RBAC İçin Neden Önemlidir?
Yerel parola risklerini azaltır
Kullanıcılar kurumsal kimlik bilgileriyle giriş yapar.Kimlik yönetimini merkezileştirir
Kullanıcı ekleme ve kaldırma IdP üzerinden yönetilir.MFA uygulamasını kolaylaştırır
IdP seviyesindeki çok faktörlü kimlik doğrulama Apidog erişimine de yansır.Onboarding sürecini sadeleştirir
Yeni çalışanlar ayrı hesap oluşturmadan erişebilir.
SCIM Sağlama
SCIM, kullanıcı yaşam döngüsünü otomatikleştirir.
| Yetenek | Ne Yapar |
|---|---|
| Kullanıcı ekle | IdP kullanıcı oluşturduğunda kullanıcı Apidog kuruluşuna eklenir |
| Kullanıcı kaldır | IdP kullanıcıyı sildiğinde Apidog erişimi kaldırılır |
| Hesapları bağla | SSO kimlikleri mevcut Apidog hesaplarıyla eşleştirilir |
SCIM Avantajları
- Eski çalışanların erişimi hızlıca kaldırılır.
- Manuel davet/kaldırma iş akışları azalır.
- Uyumluluk için erişim geçmişi netleşir.
- Unutulmuş hesap riski düşer.
Ekiplere Grup Eşlemesi
Apidog, SAML grup eşlemesini destekler. Böylece IdP grupları Apidog ekiplerine bağlanabilir.
Kurulum akışı:
- IdP üzerinde grup iddialarını yapılandırın.
- Her IdP grubunu bir Apidog ekibine eşleyin.
- Her grup için ekip rolünü belirleyin.
- Pilot kullanıcılarla test edin.
Örnek:
Azure AD grubu: API Geliştiricileri
→ Apidog ekibi: Backend Ekibi
→ Rol: Ekip Üyesi
Azure AD grubu: API Yöneticileri
→ Apidog ekibi: Platform Ekibi
→ Rol: Ekip Yöneticisi
Kullanıcılar SSO ile giriş yaptığında doğru ekiplere uygun izinlerle otomatik olarak katılır.
Kasa Sırları
Kasa Sırları / Vault Secrets, API anahtarları, parolalar ve token değerlerini merkezi olarak yönetmek için kullanılır.
| Özellik | Güvenlik Faydası |
|---|---|
| Şifreli depolama | API anahtarları ve token'lar ortam dosyaları yerine şifreli depolanır |
| Referans tabanlı erişim | Kullanıcılar sırları isimle referans alır, gerçek değeri görmez |
| Rol tabanlı görünürlük | Kasa Sırlarını kimlerin yönetebileceği RBAC ile belirlenir |
| Denetim izi | Sır erişimleri uyumluluk için izlenebilir |
Kasa Sırları vs Yerel Ortam Dosyaları
| Yaklaşım | Risk |
|---|---|
| Yerel ortam dosyaları | Sırlar proje erişimi olan herkes tarafından görülebilir, Git'e sızabilir |
| Kasa Sırları | Merkezi, şifreli, rol kontrollü ve denetlenebilir |
Apidog'da RBAC Nasıl Kurulur?
Aşağıdaki örnek, tipik bir API organizasyonu için uygulanabilir RBAC kurulumu gösterir.
Adım 1: Ekip Yapınızı Tanımlayın
Önce kuruluş, ekip ve proje yapınızı modelleyin:
Organizasyon: Şirketiniz
├── Ekip: Ödemeler
│ ├── Proje: Ödeme Ağ Geçidi API'si
│ ├── Proje: Sahtekarlık Tespit API'si
│ └── Proje: Faturalandırma Hizmeti API'si
├── Ekip: Kimlik
│ ├── Proje: Kimlik Doğrulama Hizmeti API'si
│ └── Proje: Kullanıcı Yönetimi API'si
└── Ekip: Analiz
├── Proje: Metrikler API'si
└── Proje: Raporlama API'si
Adım 2: Kuruluş Rollerini Atayın
Önerilen başlangıç dağılımı:
| Rol | Kimlere Verilmeli |
|---|---|
| Kuruluş Sahibi | CTO, CEO veya Platform Lideri gibi 1 kişi |
| Kuruluş Yöneticisi | Mühendislik yöneticileri, güvenlik liderleri |
| Kuruluş Üyesi | Geliştiriciler, QA, PM'ler, teknik yazarlar |
| Faturalandırma Yöneticisi | Finans veya satın alma sorumluları |
Adım 3: Ekip Rollerini Yapılandırın
Her ekip için sahip, yönetici ve üyeleri belirleyin.
| Ekip | Ekip Sahibi | Ekip Yöneticisi | Ekip Üyeleri |
|---|---|---|---|
| Ödemeler | Ödemeler Lideri | Ödemeler Yöneticisi | 5 geliştirici, 2 QA |
| Kimlik | Kimlik Lideri | Kimlik Yöneticisi | 3 geliştirici, 1 QA |
| Analiz | Analiz Lideri | Analiz Yöneticisi | 2 geliştirici |
Adım 4: Proje Rollerini Atayın
Proje seviyesinde sorumluluğa göre en az ayrıcalıklı rolü seçin.
| Kişi | Ödeme Ağ Geçidi API'si | Sahtekarlık Tespit API'si | Kimlik Doğrulama Hizmeti API'si |
|---|---|---|---|
| Kıdemli Geliştirici A | Yönetici | Editör | Yasaklı |
| Kıdemli Geliştirici B | Editör | Yönetici | Yasaklı |
| Acemi Geliştirici C | Editör | Salt Okunur | Yasaklı |
| QA Mühendisi | Editör | Editör | Yasaklı |
| Ürün Yöneticisi | Salt Okunur | Salt Okunur | Yasaklı |
| Yüklenici | Editör | Yasaklı | Yasaklı |
Adım 5: Üyeleri Önceden Belirlenmiş Rollerle Davet Edin
Apidog'da kullanıcı davet ederken rolleri baştan atayabilirsiniz:
Ekip daveti
Kullanıcıyı ekip rolü ve varsayılan proje rolüyle davet edin.Proje daveti
Kullanıcıyı belirli projeye proje rolüyle davet edin. Kullanıcı ekibe otomatik olarak üye olabilir.
Harici işbirlikçiler için öneri:
Proje: Ödeme Ağ Geçidi API'si
Rol: Editör
Diğer Projeler: Yasaklı
Bu yapı, yüklenicinin yalnızca atanmış projeyi görmesini sağlar.
Adım 6: SSO ve SCIM'i Yapılandırın
Kurumsal kullanımda önerilen akış:
- Kuruluş Ayarlarında SAML SSO'yu etkinleştirin.
- IdP panelinden SCIM belirtecini yapılandırın.
- IdP gruplarını Apidog ekiplerine eşleyin.
- Önce pilot bir grupla test edin.
- Sonra tüm kuruluşa yayınlayın.
API İşbirliği Güvenliği İçin En İyi Uygulamalar
1. En Az Ayrıcalık Prensibini Uygulayın
Varsayılan olarak minimum izin verin, ihtiyaç oldukça artırın.
Öneriler:
- Yeni ekip üyeleri: Salt Okunur
- Deneyimli geliştiriciler: Editör
- Proje liderleri: Yönetici
- Yükleniciler: Çoğu projede Yasaklı, atanmış projede Editör veya Salt Okunur
2. Geliştirme ve Üretim Erişimini Ayırın
Geliştirme, hazırlık ve üretim ortamlarını ayrı proje veya dallarla yönetin.
| Ortam | Geliştirici Erişimi | QA Erişimi | Yönetici Erişimi |
|---|---|---|---|
| Geliştirme | Editör | Editör | Yönetici |
| Hazırlık | Salt Okunur | Editör | Yönetici |
| Üretim | Yasaklı | Salt Okunur | Yönetici |
3. Uzman Roller İçin Özel Roller Kullanın
Genel roller her zaman doğru eşleşmeyebilir.
Örnek özel roller:
- Security-ReadOnly: Güvenlik ekibi için salt okunur + gerekli sır görünürlüğü.
- Docs-Editor: Teknik yazarlar için dokümantasyon düzenleme.
- QA-Test-Editor: Testleri düzenleme, API spesifikasyonlarını değiştirmeme.
- Performance-Tester: Performans testlerini çalıştırma ve raporlama.
4. İzinleri Üç Ayda Bir Gözden Geçirin
RBAC “kur ve unut” yaklaşımı değildir.
Üç aylık kontrol listesi:
- Kullanıcıların hâlâ doğru rollerde olduğunu doğrulayın.
- Rol sürünmesini kontrol edin.
- Yüklenici erişimlerini gözden geçirin.
- Ayrılan çalışanların SCIM ile kaldırıldığını doğrulayın.
- Özel rolleri güncelleyin.
5. Rol Tanımlarını Belgeleyin
Basit bir dahili doküman oluşturun:
# API Erişim Rolleri
## Yönetici
- Proje ayarlarını yönetebilir
- Üye ekleyebilir/kaldırabilir
- Dokümantasyon yayınlayabilir
## Editör
- Uç noktaları düzenleyebilir
- Test senaryoları oluşturabilir
- Ortamları düzenleyebilir
## Salt Okunur
- Uç noktaları görüntüleyebilir
- Testleri çalıştırabilir
- Değişiklik yapamaz
## Yasaklı
- Projeye erişemez
Ayrıca şu bilgileri ekleyin:
- Rol değişikliği nasıl istenir?
- Onaylayan kişi kimdir?
- Acil erişim süreci nedir?
- Erişim anlaşmazlığı nasıl eskale edilir?
6. Denetim Günlüğünü Kullanın
Kurumsal planlarda denetim günlükleri şu sorulara yanıt verir:
- Kim erişti?
- Neye erişti?
- Ne zaman erişti?
- Hangi işlemi yaptı?
- Rol ne zaman değiştirildi?
Denetim günlüklerini şu amaçlarla kullanabilirsiniz:
- Uyumluluk raporlaması
- Güvenlik olayı incelemesi
- Gereksiz izinleri tespit etme
- Rol optimizasyonu
RBAC Karşılaştırması: Apidog vs Diğer Araçlar
| Özellik | Apidog | Postman | SwaggerHub | Bruno |
|---|---|---|---|---|
| İzin Seviyeleri | 3: Kuruluş/Ekip/Proje | 2: Kuruluş/Ekip | 2: Kuruluş/Çalışma Alanı | 1: Git tabanlı |
| Yerleşik Roller | 12 rol | 5 rol | 4 rol | Yok, Git izinleri |
| Özel Roller | ✅ Kurumsal | ✅ Kurumsal | ✅ Kurumsal | ❌ |
| SSO/SAML | ✅ | ✅ | ✅ | ❌ |
| SCIM Sağlama | ✅ | ✅ | ❌ | ❌ |
| Grup Eşlemesi | ✅ | ✅ | ✅ | ❌ |
| Kasa Sırları | ✅ | ✅ Kurumsal | ❌ | ❌ |
| Proje İzolasyonu | ✅ Yasaklı rolü | Sınırlı | Sınırlı | Git tabanlı |
| Harici İşbirlikçi Kontrolü | ✅ Misafir + Yasaklı | Sınırlı | Sınırlı | Git erişim kontrolü |
Apidog'un RBAC Avantajları
Üç seviyeli hiyerarşi
Kuruluş, ekip ve proje kapsamlarını ayrı ayrı yönetir.Yasaklı rolü
Ekip içinde kalıp belirli projeye erişimi tamamen kapatabilirsiniz.Misafir rolü
Harici işbirlikçileri ekip yönetiminden izole eder.SCIM entegrasyonu
Kullanıcı sağlama ve devre dışı bırakma otomatikleşir.Birleşik API platformu
RBAC; tasarım, test, dokümantasyon ve mocking iş akışlarıyla birlikte çalışır.
Apidog RBAC Ne Zaman Uygundur?
Apidog RBAC özellikle şu ekipler için uygundur:
- Birden fazla API ekibi olan kuruluşlar
- SSO, SCIM ve denetlenebilirlik gerektiren kurumsal yapılar
- Geliştirici, QA, PM, güvenlik ve teknik yazarların birlikte çalıştığı ekipler
- Harici yüklenicilerle çalışan API ekipleri
- Hassas API'lerde net erişim sınırları gerektiren organizasyonlar
Sonuç
Rol Tabanlı Erişim Kontrolü, API işbirliğini daha güvenli ve yönetilebilir hale getirir. RBAC olmadan ekip büyüdükçe izin karmaşıklığı, güvenlik riski ve uyumluluk yükü artar. Doğru RBAC modeliyle ekip üyelerini, yüklenicileri ve paydaşları kontrolü kaybetmeden sisteme dahil edebilirsiniz.
Özetle:
- Kuruluş → Ekip → Proje hiyerarşisi gerçek ekip yapılarıyla uyumludur.
- 12 yerleşik rol, standart erişim senaryolarını hızlıca kapsar.
- Özel proje rolleri, uzmanlaşmış görevler için ayrıntılı izin sağlar.
- SSO ve SCIM, kimlik yönetimini kurumsal sistemlerle entegre eder.
- Kasa Sırları, kimlik bilgilerini merkezi ve rol kontrollü şekilde yönetir.
- Yasaklı rolü, hassas projeler için açık erişim engelleme sağlar.
- Grup eşlemesi, IdP gruplarına göre ekip atamasını otomatikleştirir.
Apidog'un RBAC sistemi, küçük ekiplerden büyük kurumsal API organizasyonlarına kadar erişim kontrolünü daha uygulanabilir ve denetlenebilir hale getirmek için kullanılabilir.
SSS: API Ekipleri İçin Rol Tabanlı Erişim Kontrolü
API geliştirmede Rol Tabanlı Erişim Kontrolü nedir?
API geliştirmede RBAC, erişim haklarının bireysel kullanıcılara değil rollere atandığı bir izin modelidir. Kullanıcılar Yönetici, Editör veya Salt Okunur gibi roller alır. Bu roller, hangi API kaynaklarını görüntüleyebileceklerini, değiştirebileceklerini, test edebileceklerini veya yönetebileceklerini belirler.
API işbirliği neden üç seviyeli izinlere ihtiyaç duyar?
API ekipleri kuruluş, ekip ve proje seviyelerinde çalışır. Kuruluş seviyesi SSO ve faturalandırmayı; ekip seviyesi üyelik ve proje oluşturmayı; proje seviyesi ise uç nokta, test ve dokümantasyon işlemlerini yönetir. Üç seviyeli RBAC bu yapıyı doğrudan karşılar.
Kuruluş Yöneticisi ile Ekip Yöneticisi arasındaki fark nedir?
Kuruluş Yöneticisi şirket genelindeki ayarları yönetir: üyeler, ekipler, SSO, özel roller ve kaynaklar. Ekip Yöneticisi ise belirli bir ekip içindeki üyeleri, projeleri ve ekip kaynaklarını yönetir.
Yasaklı proje rolü nasıl çalışır?
Yasaklı rolü, belirli bir projeye erişimi tamamen kapatır. Kullanıcı ekipte kalabilir ancak Yasaklı olduğu projeyi göremez ve proje içeriğine erişemez. Bu, ödeme veya güvenlik API'leri gibi hassas projeler için kullanışlıdır.
Misafir ekip rolü ne işe yarar?
Misafir rolü, proje erişimine ihtiyaç duyan ancak ekip yönetmemesi gereken harici işbirlikçiler için kullanılır. Misafirler üye detaylarını göremez, üye davet edemez ve ekip ayarlarını değiştiremez.
Belirli izinlerle özel roller oluşturabilir miyim?
Evet. Apidog Kurumsal planlarında özel proje rolleri oluşturabilirsiniz. Dal yönetimi, uç nokta yönetimi, testler, ortam yönetimi, dokümantasyon, proje ayarları, istek geçmişi ve içe/dışa aktarma gibi kategorilerde ayrıntılı izinler tanımlanabilir.
SSO entegrasyonu RBAC ile nasıl çalışır?
SSO, kimlik doğrulamayı Okta veya Microsoft Entra ID gibi kimlik sağlayıcılar üzerinden merkezi hale getirir. Kullanıcılar kurumsal kimlikleriyle giriş yapar. Grup eşlemesiyle IdP grupları Apidog ekipleri ve rolleriyle ilişkilendirilebilir.
SCIM sağlama nedir?
SCIM, kullanıcı yaşam döngüsünü otomatikleştirir. Yeni çalışanlar IdP üzerinden otomatik olarak Apidog'a eklenebilir. Ayrılan çalışanların erişimi de otomatik kaldırılabilir. Bu, unutulmuş hesap riskini azaltır.
Kasa Sırları RBAC ile nasıl çalışır?
Kasa Sırları, API anahtarları, parolalar ve token'ları merkezi ve şifreli şekilde saklar. Kullanıcılar gerçek değeri görmek yerine sırları isimle referans alır. RBAC, bu sırları kimlerin görüntüleyebileceğini veya yönetebileceğini belirler.
Yükleniciler Kuruluş Üyesi mi yoksa Misafir mi olmalı?
Yükleniciler genellikle ekip düzeyinde Misafir, proje düzeyinde ise ihtiyaçlarına göre Editör veya Salt Okunur olmalıdır. Görünürlüklerini yalnızca atanmış projelerle sınırlamak için diğer projelerde Yasaklı rolü kullanılabilir.
Top comments (0)