Services Oper Yetkileri: Yönetici Sınıfları ve Yetki Dağıtımı

Bir IRC ağının services yöneticileri, ağ üzerinde çok geniş yetkilere sahip olabilir: Ağ genelinde yasak koymak, herhangi bir kanala müdahale etmek, kullanıcı hesaplarını değiştirmek, services'i yeniden başlatmak. Bu yetkilerin hepsini her yöneticiye vermek, ağ için gereksiz bir risktir. Services oper yetkileri, hangi yöneticinin hangi komutları kullanabileceğini ayrıntılı olarak tanımlamanızı sağlar. Bu rehberde Anope ve Atheme'deki yetki modellerini ve yetki dağıtımının ilkelerini anlatıyoruz.

İki Ayrı Yetki Dünyası

Önce önemli bir ayrımı netleştirelim: IRC sunucusundaki oper yetkisi ile services'teki oper yetkisi farklı şeylerdir.

Yetki	Nerede tanımlanır?	Ne sağlar?
IRC oper	Sunucu yapılandırması (oper bloğu)	KILL, sunucu yasakları, sunucu komutları
Services oper	Services yapılandırması	OperServ komutları, hesap ve kanal müdahalesi

Bir kişi IRC'de oper olabilir ama services üzerinde hiçbir yetkiye sahip olmayabilir; tersi de mümkündür. Çoğu yapılandırmada services, kişinin hem services'te tanımlı olmasını hem de IRC'de oper olmasını şart koşar. Sunucu tarafındaki oper tanımları için UnrealIRCd oper bloğu yazımıza bakın.

Anope: opertype ve oper Blokları

Anope'ta yetki tanımı iki aşamalıdır. Önce bir opertype (yönetici türü) tanımlanır; bu, bir yetki kümesidir:

opertype
{
    name = "Yardimci"
    commands = "operserv/global operserv/akill nickserv/info"
    privs = "nickserv/auspex"
}

Ardından bir oper bloğu ile kişi bu türe bağlanır:

oper
{
    name = "Ayse"
    type = "Yardimci"
    require_oper = yes
}

• commands: Kişinin kullanabileceği services komutları. Joker karakter kullanılabilir, örneğin chanserv/* bütün ChanServ yönetim komutlarını kapsar.
• privs: Komut dışındaki özel yetkiler; örneğin gizli bilgileri görme yetkisi.
• require_oper: Kişinin IRC'de de oper olmasının zorunlu olup olmadığı.
• name: Kişinin NickServ hesabının adı.

Anope, önceden tanımlanmış birkaç opertype ile gelir; bunlar örnek yapılandırmada açıklanır. Kendi türlerinizi oluşturmak, yetkileri ağınızın yönetim yapısına göre şekillendirmenizi sağlar.

Anope: Services Root

Anope'ta en üst yetki, services root kavramıyla temsil edilir. Services root, bütün komutlara ve yapılandırma işlemlerine erişir. Bu yetkiyi yalnızca ağın asıl sahiplerine verin; genellikle bir veya iki kişi yeterlidir. Services root tanımı yapılandırma dosyasında yapılır ve çalışma sırasında değiştirilemez.

Atheme: operclass ve operator Blokları

Atheme'de de benzer bir iki aşamalı yapı vardır. operclass bir yetki sınıfı tanımlar:

operclass "yardimci" {
    privs = "general:auspex, operserv:global, user:vhost";
};

operator bloğu ise bir hesabı bu sınıfa bağlar:

operator "Ayse" {
    operclass = "yardimci";
};

Atheme'de yetkiler, iki nokta ile ayrılmış adlardan oluşan bir liste olarak yazılır. Her yetki belirli komutlara veya yeteneklere karşılık gelir. Atheme'nin örnek yapılandırması, hazır sınıflarla birlikte gelir ve her yetkinin ne sağladığını açıklar.

Önemli bir ayrıntı: Atheme'de operator bloğunda hesap adı kullanılır, nick değil. Bir kişiyi gruplanmış yedek nickiyle tanımlamak çalışmaz. Hesap kavramı için NickServ nick gruplama yazımıza bakın.

Tipik Yetki Kademeleri

Çoğu ağ için üç veya dört kademeli bir yapı yeterlidir:

Kademe	Tipik yetkiler
Yardımcı	Bilgi komutları, ağ geneli duyuru, kullanıcı bilgisi görüntüleme
Operatör	Yasak koyma ve kaldırma, oturum istisnaları, vhost yönetimi
Yönetici	Hesap ve kanal müdahalesi, süresiz yasaklar, muafiyet bayrakları
Services root	Her şey: modül yönetimi, yapılandırma yeniden yükleme, yeniden başlatma

Bu kademeleri ağınızın büyüklüğüne ve ekibinizin yapısına göre uyarlayın. Küçük bir ağda iki kademe yeterli olabilir.

En Az Yetki İlkesi

Yetki dağıtımının altın kuralı şudur: Her yöneticiye yalnızca görevini yapmasına yetecek yetkiyi verin. Bir yardım kanalı gönüllüsünün services'i yeniden başlatma yetkisine ihtiyacı yoktur. Yeni bir operatöre bütün yetkileri vermek yerine, kademeli olarak yetki artırmak hem güvenlik hem de eğitim açısından doğrudur.

Bu ilkenin pratikteki faydaları: Bir yöneticinin hesabı ele geçirildiğinde zarar sınırlı kalır; yanlışlıkla yapılan büyük hatalar azalır; yeni yöneticiler kendilerini aşan işlemleri yapmaya zorlanmaz.

Yetkileri Denetlemek

Yetki listesi zamanla eskir. Topluluktan ayrılan yöneticiler, görevi değişen kişiler ve artık ihtiyaç duyulmayan özel yetkiler listede kalır. Önerilen uygulamalar:

• Düzenli gözden geçirme: Altı ayda bir oper listesini ve yetkilerini kontrol edin.
• Ayrılanları hemen çıkarın: Bir yönetici görevinden ayrıldığında yetkisini aynı gün kaldırın.
• Loglama: Yönetici işlemlerinin loglandığından emin olun. Bkz. services log izleme.
• Hesap güvenliği: Yöneticilerin hesaplarında güçlü parola, SASL ve mümkünse sertifikalı giriş zorunlu olsun. Bkz. NickServ hesap güvenliği.

Yetki Değişikliklerini Uygulamak

Yapılandırmada yetki değişikliği yaptıktan sonra services'i yeniden yükleyin:

/os RELOAD

Bu komut yapılandırma dosyalarını yeniden okur. Yetkisi kaldırılan bir kişinin yetkisi anında geçersiz olur. OperServ komutları için OperServ komutları yazımıza bakın.

Gerçek Bir Senaryo

Bir ağda yıllar içinde sekiz kişiye services root yetkisi verilmiş. Bu kişilerden üçü artık ağda görünmüyor, biri ise başka bir ağa geçmiş. Yöneticiler durumu gözden geçirip yeni bir yapı kuruyorlar: İki kişi services root olarak kalıyor, aktif üç operatör "yönetici" sınıfına alınıyor, yardım kanalı gönüllüleri için ise yalnızca bilgi komutlarını içeren yeni bir sınıf oluşturuluyor. Aktif olmayan hesapların yetkileri kaldırılıyor. Ayrıca bütün yöneticilerden hesaplarında sertifikalı giriş ayarlamaları isteniyor.

Yetkileri Belgelemek

Yetki yapısını yapılandırma dosyasında tanımlamak işin yarısıdır; diğer yarısı bu yapıyı ekibin anlayacağı şekilde belgelemektir. Hangi sınıfın hangi işleri yapabildiğini, bir yöneticinin yetkisinin nasıl artırılacağını ve kimin hangi sınıfta olduğunu kısa bir belgede toplayın. Yeni bir yönetici ekibe katıldığında bu belge, ona neyi yapabileceğini ve neyi yapamayacağını anlatmanın en hızlı yoludur. Belgenin yapılandırma dosyasıyla uyumlu kalması için her yetki değişikliğinde güncellenmesi gerekir.

Devredilemeyen Sorumluluk

Services yetkisi vermek, aynı zamanda bir sorumluluk devretmektir. Yetki verilen kişinin hesabının güvenliği artık ağın güvenliğinin parçasıdır. Bu yüzden yetki verirken kişiden hesabının korunmasına dair somut adımlar beklemek makuldür: güçlü ve benzersiz bir parola, SASL ile bağlantı, mümkünse sertifikalı giriş. Bu beklentileri baştan açıkça söylemek, sonradan yaşanabilecek sorunları önler.

Sonuç

Services oper yetkileri, ağ yönetiminin güvenliğinin temelini oluşturur. Yetki sınıflarını ağınızın yönetim yapısına göre tanımlayın, en az yetki ilkesini uygulayın, services root sayısını minimumda tutun, ayrılan yöneticilerin yetkilerini hemen kaldırın ve listeyi düzenli olarak denetleyin. Yönetici işlemlerini izlemek için sıradaki rehberimiz services log izleme.