Roller ve izinler

Pathrule tek kişilik bir araç olarak başlar ve zamanla bir ekip ürününe dönüşür. Ekip arkadaşlarınızı davet ettiğinizde asıl soru, kimin neyi görebileceği ve değiştirebileceği olur. Bu sayfada atadığınız roller, erişimin organizasyondan çalışma alanına nasıl daraldığı ve denetimin gerçekte nerede çalıştığı anlatılıyor.

Kısaca: roller organizasyon düzeyinde atanır, erişim çalışma alanı bazında daraltılabilir ve bir Pathrule Cloud çalışma alanındaki her okuma ve yazma, veritabanı tarafından giriş yapmış kullanıcınıza göre denetlenir. İstek ister app.pathrule.io adresindeki web konsolundan, ister Pathrule CLI'dan, VS Code eklentisinden ya da bir yapay zekâ istemcisinin konuştuğu MCP sunucusundan gelsin, aynı denetim uygulanır.

--local ile oluşturulan yerel bir çalışma alanının hesabı yoktur ve tek bir makinede durur. Bu yüzden onu Cloud'a taşıyana kadar roller bu çalışma alanı için geçerli olmaz.

Dört rol

Roller organizasyon düzeyinde kişi bazında atanır. Owner ya da Admin rolündeki biri, bir ekip arkadaşını e-postayla davet eder ve rolünü seçer (varsayılan Editor'dır). Ekip arkadaşı katılmak için daveti kabul eder. Davetleri web konsolundaki Members bölümünden ya da terminalden gönderebilirsiniz:

pathrule invite colleague@example.com --role viewer

Bundan birkaç güvenlik kuralı çıkar:

• Sahiplik değişiklikleri Owner yetkisi gerektirir ve organizasyonda her zaman bir Owner kalmalıdır.
• Sahiplik ve üyelik değişiklikleri, bir Owner'ın kalması şartı da dahil olmak üzere sunucuda denetlenir.

Üyelik değişiklikleri geçerli ve yetkili bir oturum gerektirir. Hassas çalışma alanı arşivleme ve silme işlemleri için ayrıca yeniden kimlik doğrulama gerekir.

Koltuklar ve planlar

Organizasyondaki her kişi, rolü ne olursa olsun bir koltuk kullanır.

• Solo ve Pro tek kişiliktir. Davet özelliği yoktur, başkalarıyla çalışmak için Team planına geçmeniz gerekir.
• Team koltuk başına faturalandırılır, sahibi de dahil en az iki koltukla. Ödediğiniz koltuk sayısının ötesinde davet göndermek için ek koltuk gerekir. Koltuk sayısı üye sayısından azsa herkes erişimini korur, yeni davetler bekletilir.
• Enterprise koltukları satış ekibiyle birlikte belirlenir.

Koltuklar ve faturalar web konsolundaki Billing bölümünde bulunur. pathrule billing komutu bu bölümü terminalden açar. Ayrıntılar için Pathrule Web sayfasına bakın.

Çalışma alanı erişimi: organizasyon geneli ya da özel

Rol, bir kişinin neler yapabileceğini belirler. Çalışma alanının erişim modu ise o çalışma alanına kimin ulaşabileceğini belirler. Her çalışma alanı iki moddan birindedir.

• Organizasyon geneli. Organizasyonun her üyesi, organizasyondaki rolüyle erişebilir.
• Özel. Yalnızca çalışma alanına açıkça eklenen kişiler erişebilir. Organizasyon üyeliği tek başına yeterli değildir.

Owner ve Admin rolündekiler modu web konsolu ayarlarında Workspace, Access altından değiştirir. Bir çalışma alanı özel hale geldiğinde yalnızca açıkça eklenmiş çalışma alanı üyeleri erişebilir. Erişime ihtiyacı olan kişileri gözden geçirip ekleyin, çünkü organizasyon üyeliği artık tek başına erişim sağlamaz. Özel bir çalışma alanında kişinin orada neler yapabileceğini çalışma alanı rolü belirler. Böylece birine, başka yerlerdekinden farklı bir erişim düzeyi verebilirsiniz.

Erişimi kaybetmek hiçbir şeyi silmez

İzin değişiklikleri hiçbir zaman yapılan işi yok etmez ve onu nadiren gizler.

• Yazma erişimini kaybettiğinizde (örneğin Editor'dan Viewer'a geçtiğinizde) hiçbir şey kaybolmaz. Daha önce okuyabildiğiniz her şeyi okumaya devam edersiniz. Sizden ya da sizin adınıza çalışan bir asistandan gelen yazma işlemleri reddedilir.
• Bir çalışma alanına erişimi kaybettiğinizde (özel bir çalışma alanından ya da organizasyondan çıkarıldığınızda) ancak o zaman o çalışma alanının içeriği sizin için görünmez olur. İçerik ekipte kalmaya devam eder.

Aynı sınır asistan için de geçerlidir. Bir yapay zekâ istemcisi, üyenin yazamadığı bir yere yazmaya çalıştığında MCP araç çağrısı açık bir izin reddi sonucuyla döner. Asistan bunu size anlaşılır bir dille aktarabilir, böylece işlem sessizce başarısız olmaz ya da başarılı olmuş gibi görünmez. Asistanın aldığı bağlam ve Pathrule'un onun için yazdığı talimat dosyaları, yalnızca o üyenin okuyabildiği çalışma alanlarından gelir.

Denetim nerede çalışır

Bunların hiçbiri o an kullandığınız uygulamada uygulanmaz. Bir Cloud çalışma alanındaki her okuma ve yazma, giriş yapmış kullanıcınıza, organizasyon üyeliğinize ve çalışma alanının erişim moduna göre değerlendirilen bir veritabanı erişim denetiminden geçer. Erişim denetimleri, arayüzde gizlenmiş bir düğme değil, sunucunun veritabanı işlemlerinin bir parçasıdır.

• Her yüzey için tek denetim. Web konsolu, Pathrule CLI, VS Code eklentisi, yerel MCP sunucusu ve Remote MCP aynı veritabanı düzeyindeki erişim kontrolünden geçer. Terminalden yapılan bir değişiklik de bir yapay zekâ istemcisinden gelen bir yazma da aynı kurallarla sınırlanır.
• Paylaşılan yönetici anahtarı yok. Her yüzey kısa ömürlü, kullanıcıya özel bir token taşır. Başka bir ekibin verilerine erişim açabilecek paylaşılan bir servis anahtarı hiçbir zaman kullanılmaz. Sızdırılmış bir istemci, yalnızca o kullanıcının zaten erişebildiği yerlere ulaşabilir.
• Sunucu tarafında çözümleme. Üyelik ve çalışma alanı rolleri istemciden gelen bilgiye güvenilerek değil, sunucuda çözümlenir. Bu yüzden değiştirilmiş bir istek, kendisine verilmemiş bir erişimi kendine tanıyamaz.

Cloud'da erişimin nasıl sınırlandığının tam resmi için güvenlik özetine bakın.

Kendi sunucunuzda

Kendi sunucunuzda çalışan Enterprise, aynı rol ve izin modelini kendi Cloudflare hesabınızda çalıştırır. Roller ve çalışma alanı erişim modları aynı şekilde davranır. Fark, verilerin ve veritabanının sizin hesabınızda durmasıdır. Kendi kimlik sağlayıcınız üzerinden tek oturum açma, Enterprise sözleşmesi kapsamında ayarlanır ve burada anlatılan aynı organizasyon rollerine eşlenir. Bu kurulumun nasıl çalıştığını öğrenmek için Enterprise kendi sunucunuzda sayfasına bakın.