Rol Tabanlı Erişim Kontrolü (RBAC) ile API İşbirliğini Güvenli Hale Getirme

TL;DR

Rol Tabanlı Erişim Kontrolü (RBAC), bireysel kullanıcılar yerine rollere izinler atayan bir güvenlik modelidir. Bu, API ekip yönetimini ölçeklenebilir ve denetlenebilir hale getirir. API işbirliği için uygun bir RBAC sistemi üç seviyeli izin hiyerarşisi (Kuruluş → Ekip → Proje), ayrıntılı kontrol için özel rol oluşturma ve SSO ve SCIM gibi kurumsal entegrasyonlar sunmalıdır. Apidog, üç seviyede 12 yerleşik rol ve kurumsal ekipler için özel proje rolleriyle kapsamlı bir RBAC çerçevesi sunar; bu da API varlıklarınızı kimlerin görüntüleyebileceği, düzenleyebileceği, test edebileceği veya yönetebileceği üzerinde hassas kontrol sağlar.

API Ekipleri İçin RBAC Neden Önemlidir?

API geliştirme birden fazla paydaşı içerir: uç noktaları yazan geliştiriciler, testleri yürüten QA mühendisleri, spesifikasyonları inceleyen ürün yöneticileri, dokümantasyon oluşturan teknik yazarlar ve erişim günlüklerini denetleyen güvenlik ekipleri. Yapılandırılmış erişim kontrolü olmadan kaos ortaya çıkar.

Gerçek dünya sorunu: Acemi bir geliştirici yanlışlıkla bir üretim API spesifikasyonunu değiştirir. Bir yüklenici görmemesi gereken hassas ödeme uç noktalarına erişim kazanır. Eski bir çalışanın kimlik bilgileri ayrıldıktan aylar sonra bile aktif kalır. Bunlar varsayımsal senaryolar değil; uygun RBAC olmadan API'leri yöneten kuruluşlarda her gün yaşanıyor.

Bir API Güvenlik Raporu, API güvenlik olaylarının %61'inin yetkisiz erişim veya aşırı izinler içerdiğini ortaya koymuştur. Temel neden? Ekiplerin API varlıklarıyla kimin ne yapabileceği üzerinde ayrıntılı kontrole sahip olmaması.

RBAC bunu aşağıdaki yollarla çözer:

1. İzinleri bireylere değil rollere atar — Biri katıldığında veya ayrıldığında, 50 ayrı izni değil, rol atamasını güncellersiniz.
2. En az ayrıcalıklı erişimi zorlar — Her rol en az gerekli izinleri alır.
3. Denetim izleri oluşturur — Her eylem bir role eşlenir, bu da uyumluluk raporlamayı kolaylaştırır.
4. Ekip büyümesini ölçeklendirir — Her hesabı yapılandırmak yerine rolleri atayarak 100 yeni ekip üyesi ekleyin.

Apidog'un RBAC sistemi, özellikle API geliştirme iş akışları için tasarlanmış üç katmanlı bir izin modeli ile bu zorlukları ele alır. Nasıl çalıştığını inceleyelim.

Üç Seviyeli İzin Hiyerarşisi

Etkin API işbirliği RBAC, sadece "bu projeye erişebilir" değil, birden fazla seviyede izinler gerektirir. Apidog, gerçek kuruluşların çalışmalarını nasıl yapılandırdığını yansıtan üç seviyeli bir hiyerarşi uygular:

Neden üç seviye önemlidir: Ödeme, Kimlik ve Analiz olmak üzere üç ekibi olan bir fintech şirketini düşünün. Her ekip birden fazla API projesini yönetir. Ödeme ekibindeki bir geliştirici Ödeme API'lerine erişebilmeli ancak Kimlik veya Analiz projelerine erişememeli. Bir kuruluş yöneticisinin tüm ekipler için SSO'yu yapılandırması gerekir, ancak her API uç noktasını düzenlemesi gerekmez. Bir QA mühendisinin API spesifikasyonlarını değiştirmeden belirli projelerde testler çalıştırması gerekir.

Bu hiyerarşik yaklaşım iki yaygın hatayı önler:

• Aşırı yetkilendirme: Ayrıntılı kontrol çok karmaşık olduğu için herkese yönetici erişimi vermek
• İzin boşlukları: Ekip düzeyinde izinler oluşturmak ancak proje düzeyinde ayrıntıları unutmak

Her seviyenin rollerini ve yeteneklerini inceleyelim.

Kuruluş Düzeyinde Roller ve İzinler

Kuruluş rolleri şirket genelindeki ayarları kontrol eder; faturalandırma, kimlik sağlayıcı entegrasyonları, üye yönetimi ve kaynak yönetişimi. Bu roller, kuruluş çatısı altındaki tüm ekipleri ve projeleri etkiler.

Yerleşik Kuruluş Rolleri

İzin Matrisi: Kuruluş Ayarları

İzin Matrisi: Ekip Yönetimi

İzin Matrisi: Üye Yönetimi

Kuruluş Üyesi rolü kasıtlı olarak sınırlıdır — bu bir "pasif alıcı" rolüdür. Üyeler, ekip ve proje düzeyindeki izinlere göre ekiplere katılabilir ve projelere katılabilir, ancak kuruluş ayarlarını yönetemezler. Bu tasarım, işbirliğini mümkün kılarken yanlışlıkla kuruluş genelinde yapılan değişiklikleri önler.

Faturalandırma Yöneticisi benzersizdir: Bu rol bağımsızdır ve diğerleriyle birleşebilir. Bir kullanıcı hem Kuruluş Üyesi hem de Faturalandırma Yöneticisi olabilir. Faturalandırma Yöneticileri kuruluş ayarlarına erişemez, üyeleri yönetemez veya SSO'yu yapılandıramazlar; yalnızca abonelikleri ve faturalandırmayı yönetirler.

Ekip Düzeyinde Roller ve İzinler

Ekip rolleri departman düzeyindeki işlemleri kontrol eder; ekip üyelerini yönetme, projeler oluşturma ve ekip kaynaklarını yapılandırma. Bir ekip genellikle bir iş birimini, ürün hattını veya işlevsel bir grubu temsil eder (örn. Mobil Ekip, Arka Uç Ekibi, QA Ekibi).

Yerleşik Ekip Rolleri

İzin Matrisi: Ekip Yönetimi

İzin Matrisi: Ekip Ayarları

İzin Matrisi: Proje Operasyonları

Misafir rolü, harici işbirliği için güçlüdür. Danışmanlar, yükleniciler veya departmanlar arası işbirlikçiler, sadece belirli projelere erişimi olan Misafirler olarak bir ekibe katılabilirler; ekip yönetimi özelliklerine veya diğer ekip projelerine değil. Bu, harici kullanıcıların ilgisiz iş alanlarını görmesini engeller.

Proje Düzeyinde Roller ve İzinler

Proje rolleri API düzeyindeki işlemleri kontrol eder: uç noktaları düzenleme, testler çalıştırma, ortamları yönetme, dokümantasyon yayınlama. Günlük API çalışmalarının gerçekleştiği yer burasıdır.

Yerleşik Proje Rolleri

İzin Kategorileri

Proje izinleri sekiz ana kategoriyi kapsar:

1. Dal Yönetimi — Sprint dalları, birleştirme istekleri, korumalı dallar, API versiyonları
2. Uç Nokta Yönetimi — Uç noktalar, durumlar, şemalar, bileşenler, istekler, çöp kutusu işlemleri
3. Otomatik Testler — Test senaryoları, performans testleri, zamanlanmış görevler, test raporları
4. Ortam Yönetimi — Genel değişkenler, parametreler, ortamlar, Kasa Sırları (Vault Secrets)
5. Dokümantasyon Paylaşımı — Hızlı paylaşım, dokümantasyon siteleri yayınlama
6. Proje Ayarları — Temel ayarlar, üye yönetimi, özellik ayarları, bildirimler
7. İstek Geçmişi — Yerel ve paylaşılan istek geçmişi
8. İçe/Dışa Aktarma — Veri içe aktarma, zamanlanmış içe aktarma, dışa aktarma işlemleri

Önemli İzin Vurguları

"Yasaklı" rolü güvenlik için kritiktir. Bir ekip üyesi belirli bir projeye erişmemesi gerektiğinde (örneğin hassas bir ödeme API'si), onları ekipten çıkarmak yerine Yasaklı olarak atayın. Ekip üyesi olarak kalırlar ancak o projeye sıfır erişimleri olur.

Ayrıntılı Kontrol için Özel Roller

Yerleşik roller çoğu senaryoyu kapsasa da, kurumsal ekipler genellikle standart kategorilere uymayan ince ayarlı izinlere ihtiyaç duyar. Apidog'un Kurumsal planı, ayrıntılı izin kontrolüne sahip özel proje rollerini destekler.

Özel Rolleri Ne Zaman İhtiyaç Duyarsınız?

• QA Mühendisi rolü: Testleri çalıştırabilir ve test senaryolarını değiştirebilir ancak API spesifikasyonlarını düzenleyemez.
• Teknik Yazar rolü: Dokümantasyonu düzenleyebilir ancak uç noktaları veya ortamları değiştiremez.
• Güvenlik Denetçisi rolü: Salt okunur erişim ve Kasa Sırlarını görüntüleme yeteneği ancak hiçbir şeyi değiştiremez.
• Stajyer rolü: Uç noktaları görüntüleyebilir ve istekleri çalıştırabilir ancak hiçbir şeyi silemez.

Özel Proje Rolleri Oluşturma

Ekip → Üyeler → Roller ve İzinler veya Kuruluş → Üyeler → Roller ve İzinler'e gidin, ardından özel bir rol oluşturmak için + Ekle'ye tıklayın.

İzinleri sekiz kategoriye göre yapılandırabilirsiniz:

Özel Rol En İyi Uygulamaları

1. Bir kopyayla başlayın — Sıfırdan başlamak yerine mevcut bir rolü (Editör, Salt okunur) kopyalayın ve değiştirin
2. "Tüm İzinler" onay kutularını kullanın — Bir modül için "Tüm İzinler"i işaretlemek, o modüle gelecekte eklenecek izinleri otomatik olarak verir
3. Dağıtmadan önce test edin — Bir test projesi oluşturun, özel rolü atayın ve izinlerin beklendiği gibi çalıştığını doğrulayın
4. Özel rolleri belgeleyin — Bir rol adlandırma kuralı oluşturun ve her özel rolün ne yapabileceğini belgeleyin
5. Üç ayda bir gözden geçirin — Özel rollerin hala ekip ihtiyaçlarına uygun olduğundan emin olmak için periyodik olarak gözden geçirilmesi gerekir

Kurumsal Güvenlik Özellikleri

RBAC temeldir, ancak kurumsal API programları ek güvenlik yeteneklerine ihtiyaç duyar. Apidog, RBAC ile birlikte çalışan kurumsal düzeyde güvenlik özelliklerini entegre eder.

Tek Oturum Açma (SSO)

SAML 2.0 ile SSO, aşağıdaki gibi kimlik sağlayıcılar aracılığıyla merkezi kimlik doğrulamayı sağlar:

• Microsoft Entra ID (Azure Active Directory)
• Okta
• Google Workspace
• OneLogin
• Özel SAML 2.0 sağlayıcıları

SSO'nun RBAC için önemi:

1. Yerel parola risklerini ortadan kaldırır — Zayıf parola yok, parola paylaşımı yok, unutulmuş kimlik bilgileri yok
2. Kimlik yönetimini merkezileştirir — İK kullanıcıları tek bir yerden ekler/kaldırır; değişiklikler Apidog'a senkronize edilir
3. Çok faktörlü kimlik doğrulamayı zorlar — IdP düzeyindeki MFA, Apidog erişimine uygulanır
4. İşe alımı basitleştirir — Yeni çalışanlar kurumsal kimlik bilgileriyle giriş yapar, ayrı hesap oluşturmaya gerek yoktur

SCIM Sağlama

SCIM (System for Cross-domain Identity Management - Alanlar Arası Kimlik Yönetimi Sistemi), kullanıcı sağlama işlemini otomatikleştirir:

SCIM avantajları:

• Anında devre dışı bırakma — Eski çalışanlar erişimi günler içinde değil, dakikalar içinde kaybeder
• Yönetici yükünü azaltma — Manuel davet/kaldırma iş akışları yok
• Uyumluluk uyumu — Denetim izleri, erişimin tam olarak ne zaman verildiğini/kaldırıldığını gösterir
• Hata ortadan kaldırma — Unutulmuş hesaplar veya manuel hatalar yok

Ekiplere Grup Eşlemesi

Apidog, SAML grup eşlemesini destekler; IdP grupları otomatik olarak Apidog ekiplerine eşlenir:

1. IdP'nizde grup iddialarını yapılandırın (örn. Azure AD grupları)
2. Her IdP grubunu bir Apidog ekibine eşleyin
3. Her grup için ekip rol izinlerini ayarlayın

Örnek: Azure AD grubu "API Geliştiricileri", Apidog "Backend Ekibi"ne Ekip Üyesi rolüyle eşlenir. Azure AD grubu "API Yöneticileri", "Platform Ekibi"ne Ekip Yöneticisi rolüyle eşlenir.

Çalışanlar SSO aracılığıyla giriş yaptığında, otomatik olarak doğru ekiplere uygun izinlerle katılırlar; manuel atama gerekmez.

Kasa Sırları

Kasa Sırları (Vault Secrets), merkezi kimlik bilgisi yönetimi sağlar:

Kasa Sırları vs. yerel ortam dosyaları:

Apidog'da RBAC Nasıl Kurulur

Tipik bir API ekibi için eksiksiz bir RBAC yapısını nasıl kuracağımıza bir göz atalım.

Adım 1: Ekip Yapınızı Tanımlayın

Rolleri yapılandırmadan önce kuruluşunuzu eşleyin:

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 Yapılandırın

• Kuruluş Sahibi (1 kişi): CEO, CTO veya Platform Lideri
• Kuruluş Yöneticileri (2-3 kişi): Mühendislik yöneticileri, Güvenlik liderleri
• Kuruluş Üyeleri (diğer herkes): Geliştiriciler, QA, PM'ler, yazarlar

Adım 3: Ekip Rollerini Yapılandırın

Her ekip için:

Adım 4: Proje Rollerini Yapılandırın

Her proje için, sorumluluklara göre roller atayın:

Adım 5: Önceden Yapılandırılmış Rollerle Üye Davet Etme

Kullanıcıları davet ederken rolleri hemen ayarlayabilirsiniz:

1. Ekip daveti — Ekip rolü + varsayılan proje rolü ile ekibe davet et
2. Proje daveti — Proje rolü ile belirli bir projeye davet et + otomatik olarak ekibe Üye olarak eklenir

Harici işbirlikçiler için: Görünürlüğü yalnızca davet edilen projeyle kısıtlamak için Diğer Projeler = Yasaklı ile proje düzeyinde davet kullanın.

Adım 6: SSO ve SCIM'i Yapılandırın (Kurumsal)

1. Kuruluş Ayarlarında SAML SSO'yu kurun
2. IdP panosundan SCIM belirtecini yapılandırın
3. IdP gruplarını Apidog ekiplerine eşleyin
4. Yayınlamadan önce bir pilot grupla test edin

API İşbirliği Güvenliği için En İyi Uygulamalar

1. En Az Ayrıcalık Prensibini Uygulayın

Minimum izinlerle başlayın, gerektiğinde ekleyin:

• Yeni ekip üyeleri: Salt okunur → gösterilen ihtiyaca göre artırın
• Yükleniciler: Çoğu proje için Yasaklı → yalnızca atanmış projeler için Editör
• QA mühendisleri: Testler için Editör, spesifikasyonlar için Salt okunur

2. Geliştirme ve Üretim Erişimini Ayırın

Geliştirme/hazırlık/üretim için ayrı projeler veya dallar oluşturun:

3. Uzmanlaşmış Fonksiyonlar için Özel Roller Kullanın

İşleri uzmanlaşmışken insanları genel rollere zorlamayın:

• Güvenlik ekibi: Salt okunur + Kasa Sırlarına erişim
• Teknik yazarlar: Dokümantasyon için Editör, uç noktalar için Salt okunur
• Performans mühendisleri: Testler için Editör, spesifikasyonlar için Salt okunur

4. İzinleri Üç Ayda Bir Gözden Geçirin

RBAC "kur ve unut" değildir. Üç aylık gözden geçirmeler planlayın:

• Birikmiş izinleri (rol sürünmesi) kontrol edin
• Yüklenici erişiminin proje kapsamını aşmadığını doğrulayın
• Yeni özellikler veya değişen sorumluluklar için özel rolleri güncelleyin
• Ayrılan çalışanların erişimini SCIM aracılığıyla anında kaldırın

5. Rol Tanımlarını Belgeleyin

Açık bir belge oluşturarak şunları gösterin:

• Her rol ne yapabilir ve ne yapamaz
• Her role kim sahip olmalı
• Rol değişiklikleri nasıl istenir
• Erişim anlaşmazlıkları için eskalasyon yolları

6. Denetim Günlüğünü Etkinleştirin

Kurumsal planlar, aşağıdakileri izleyen denetim günlüklerini içerir:

• Kim neye erişti
• Ne zaman erişti
• Ne tür eylemler gerçekleştirdi
• Rol atamaları ve değişiklikleri

Denetim günlüklerini şunlar için kullanın:

• Uyumluluk raporlaması
• Güvenlik olayı araştırması
• İzin optimizasyonu analizi

RBAC Karşılaştırması: Apidog vs Diğer Araçlar

Apidog'un RBAC'si diğer API işbirliği platformlarıyla nasıl karşılaştırılır?

Apidog avantajları:

1. Üç seviyeli hiyerarşi — Postman/SwaggerHub'ın iki seviyesinden daha ayrıntılı
2. Yasaklı rolü — Ekipler içinde açıkça erişim engelleme kontrolü
3. Misafir rolü — Kontrollü görünürlüğe sahip harici işbirlikçiler
4. SCIM entegrasyonu — Otomatik sağlama/devre dışı bırakma
5. Birleşik platform — RBAC; tasarım, test, dokümantasyon, alay (mocking) işlemlerini tek bir araçta kapsar

Apidog RBAC ne zaman idealdir:

• Birden fazla API ekibi olan büyük kuruluşlar
• Kurumsal uyumluluk gereksinimleri (SSO, SCIM, denetlenebilirlik)
• Çapraz fonksiyonel ekipler (geliştirici, QA, PM, güvenlik, yazarlar)
• Kontrollü erişim gerektiren harici işbirlikçiler
• Katı erişim sınırları gerektiren hassas API'ler

Sonuç

Rol Tabanlı Erişim Kontrolü, API işbirliğini kaostan yönetişime dönüştürür. RBAC olmadan, ekip büyümesi izin karmaşıklığı, güvenlik riskleri ve uyumluluk sorunları anlamına gelir. Uygun RBAC ile güvenle ölçeklenirsiniz; kontrolü kaybetmeden ekip üyeleri, yükleniciler ve paydaşlar eklersiniz.

Ana çıkarımlar:

1. Üç seviyeli hiyerarşi (Kuruluş → Ekip → Proje), gerçek ekiplerin çalışma şekliyle eşleşir
2. 12 yerleşik rol, özel yapılandırmaya gerek kalmadan standart senaryoları kapsar
3. Özel proje rolleri, uzmanlaşmış ihtiyaçlar için ince ayarlı izinler sağlar
4. SSO ve SCIM, kurumsal kimlik yönetimiyle entegre olur
5. Kasa Sırları, kimlik bilgisi yönetimini rol tabanlı erişimle merkezileştirir
6. Yasaklı rolü, hassas projeler için açıkça erişim engelleme kontrolü sağlar
7. Grup eşlemesi, IdP gruplarına göre ekip atamasını otomatikleştirir

Apidog'un RBAC sistemi, beş kişilik bir başlangıç şirketi veya bin kişilik bir kurumsal firma olun, yedi prensibin tamamını uygulamanız için size araçlar sunar.

SSS: API Ekipleri için Rol Tabanlı Erişim Kontrolü

API geliştirmede Rol Tabanlı Erişim Kontrolü (RBAC) nedir?

API geliştirmede RBAC, erişim haklarının bireysel kullanıcılara değil, rollere atandığı bir izin modelidir. Kullanıcılar rolleri (Yönetici, Editör, Salt okunur gibi) alır ve bu roller, hangi API kaynaklarını görüntüleyebileceklerini, değiştirebileceklerini, test edebileceklerini veya yönetebileceklerini belirler. Bu, ekip yönetimini basitleştirir, çünkü birinin rolünü değiştirmek, tüm izinlerini aynı anda günceller.

API işbirliğinin neden üç seviyeli izinlere ihtiyacı var?

API ekipleri üç seviyede çalışır: kuruluş genelinde (faturalandırma, SSO), ekip genelinde (proje oluşturma, üye yönetimi) ve projeye özgü (uç nokta düzenleme, test yürütme). Üç seviyeli RBAC bu yapıyla eşleşir, aşırı yetkilendirmeyi (çok fazla erişim verme) ve izin boşluklarını (gerekli kontrollerin eksik olması) önler.

Kuruluş Yöneticisi ile Ekip Yöneticisi arasındaki fark nedir?

Kuruluş Yöneticileri, şirket genelindeki ayarları yönetir: üye davetleri, ekip oluşturma, SSO yapılandırması, özel rol tanımları. Ekip Yöneticileri, ekibe özgü işlemleri yönetir: ekip üyelerini davet etme, ekip içinde projeler oluşturma, ekip kaynaklarını yapılandırma. Kuruluş Yöneticilerinin daha geniş bir kapsamı varken; Ekip Yöneticilerinin odaklanmış ekip kontrolü vardır.

Yasaklı proje rolü nasıl çalışır?

Yasaklı rolü, belirli bir projeye tüm erişimi açıkça reddeder. Bir kullanıcı ekip üyesi olarak kalabilir, ancak Yasaklı projelere sıfır görünürlüğü olur. Bu, belirli ekip üyelerinin hiçbir proje içeriğini görmemesi gereken hassas API'ler (ödeme sistemleri, güvenlik hizmetleri) için kullanışlıdır.

Misafir ekip rolü ne işe yarar?

Misafir, proje erişimine ihtiyaç duyan ancak ekipleri yönetmemesi gereken harici işbirlikçiler (yükleniciler, danışmanlar, departmanlar arası görevlendirilenler) içindir. Misafirler, ekip üyesi detaylarını göremez, üye davet edemez veya ekip ayarlarına erişemez; sadece proje düzeyindeki izinlere göre projelere katılırlar.

Belirli izinlerle özel roller oluşturabilir miyim?

Evet, Apidog Kurumsal planları özel proje rollerini destekler. Dal yönetimi, uç nokta yönetimi, otomatik testler, ortam yönetimi, dokümantasyon paylaşımı, proje ayarları, istek geçmişi ve içe/dışa aktarma olmak üzere sekiz kategoride ayrıntılı izinlere sahip roller tanımlayabilirsiniz. "QA Mühendisi" (yalnızca test düzenleme) veya "Teknik Yazar" (yalnızca dokümantasyon düzenleme) gibi roller oluşturabilirsiniz.

SSO entegrasyonu RBAC ile nasıl çalışır?

SSO, kimlik sağlayıcılar (Okta, Microsoft Entra ID) aracılığıyla kimlik doğrulamasını merkezileştirir. SSO etkinleştirildiğinde, ekip üyeleri kurumsal kimlik bilgileriyle giriş yapar. SSO ayrıca IdP gruplarını Apidog ekiplerine ve rollerine eşleyebilir; grup üyeliğine göre doğru izinleri otomatik olarak atar.

SCIM sağlama nedir ve neden kullanılır?

SCIM, kullanıcı yaşam döngüsü yönetimini otomatikleştirir. Biri şirketinize katıldığında, IdP otomatik olarak Apidog hesabını sağlar. Biri ayrıldığında, SCIM erişimini anında kaldırır. Bu, manuel davet/kaldırma iş akışlarını ortadan kaldırır ve eski çalışan kimlik bilgilerinin kalıcı olmasını önler.

Kasa Sırları RBAC ile nasıl çalışır?

Kasa Sırları, şifreli kimlik bilgilerini (API anahtarları, parolalar, belirteçler) merkezi olarak depolar. Kullanıcılar, gerçek değerleri görmeden sırları isimle referans alır. RBAC, Kasa Sırlarını kimlerin ekleyebileceğini, değiştirebileceğini veya erişebileceğini kontrol eder—genellikle Yöneticiler ve Editörler. Bu, kimlik bilgilerinin ortam dosyaları veya Git depoları aracılığıyla ifşa edilmesini önler.

Yükleniciler Kuruluş Üyesi mi yoksa Misafir mi olmalı?

Yükleniciler genellikle ekip düzeyinde Misafir olmalı ve proje düzeyinde Editör veya Salt okunur olmalıdır. Görünürlüklerini yalnızca atanmış projelerle sınırlamak ve ilgisiz iş alanlarına erişimi önlemek için "Diğer Projeler = Yasaklı" seçeneğiyle proje düzeyinde davetleri kullanın.