Zabbix’te Kullanıcı ve Yetki Yönetimi

Yazar:komut.io ekibi Zabbix ile Sunucu İzleme ve Yönetimi
0 Yorum

Zabbix kurulumu yapıp her şeyi admin hesabıyla yönetmeye başlamak çok cazip geliyor, biliyorum. Ben de yıllarca öyle yaptım. Sonra bir gün bir junior ekip arkadaşı yanlışlıkla production ortamındaki kritik bir host’un tüm trigger’larını devre dışı bıraktı ve biz üç saat boyunca neden alarm almadığımızı anlamaya çalıştık. O günden sonra Zabbix’te kullanıcı ve yetki yönetimini ciddiye almaya başladım.

Bu yazıda Zabbix’in kullanıcı yönetimi mimarisini, rol ve izin sistemini, pratik senaryolarla birlikte ele alacağım. Zabbix 6.x ve üzeri versiyonları baz alıyorum, bazı kavramlar eski versiyonlarda farklı çalışabilir.

Zabbix Kullanıcı Yönetiminin Temel Kavramları

Zabbix’te erişim kontrolü birkaç katmandan oluşuyor. Bunları anlamadan doğru bir yetki yapısı kurmak mümkün değil.

User Groups (Kullanıcı Grupları): Kullanıcıları mantıksal gruplar halinde organize ettiğiniz yapı. Bir kullanıcı birden fazla gruba üye olabilir.

Roles (Roller): Zabbix 5.2 ile gelen bu özellik, kullanıcıların sistem genelinde ne yapabileceğini belirliyor. Admin, Super Admin, User gibi temel roller var ama özel roller de tanımlayabiliyorsunuz.

Host Groups: İzlediğiniz host’ları gruplamanın yolu. Yetki sistemi host grupları üzerinden işliyor, doğrudan host üzerinden değil.

Permissions: Kullanıcı gruplarının host gruplarına erişim seviyesini belirliyor. Read-only, Read-Write ve Deny seçenekleri var.

Bu dört kavramın birbirine nasıl bağlandığını anlamak kritik. Bir kullanıcı hangi host gruplarını görebilir? Hangi işlemleri yapabilir? Bunların hepsi bu katmanların kesişiminden çıkıyor.

Kullanıcı Rolleri

Zabbix 5.2 öncesinde sadece üç sabit user type vardı: Zabbix User, Zabbix Admin ve Zabbix Super Admin. Artık bu tipler hala var ama üzerine özelleştirilebilir roller katmanı eklendi.

Super Admin Role: Tüm sisteme tam erişim. Host grubu kısıtlamaları bu role uygulanmıyor. Sadece gerçekten sistemi yönetenler bu rolde olmalı.

Admin Role: Yönetimsel işlemler yapabiliyor ama Super Admin’in erişebildiği bazı sistem konfigürasyonlarına erişemiyor. Host grubu kısıtlamaları bu role uygulanıyor.

User Role: Temel izleme işlemleri. Dashboard görüntüleme, grafik inceleme, problem ekranları. Varsayılan olarak konfigürasyon değişikliği yapamıyor.

API üzerinden özel rol oluşturmak için:

curl -s -X POST -H 'Content-Type: application/json' 
  http://zabbix-server/zabbix/api_jsonrpc.php 
  -d '{
    "jsonrpc": "2.0",
    "method": "role.create",
    "params": {
      "name": "NOC_Operator",
      "type": 1,
      "rules": {
        "ui": [
          {"name": "monitoring.problems", "status": 1},
          {"name": "monitoring.hosts", "status": 1},
          {"name": "monitoring.dashboard", "status": 1},
          {"name": "monitoring.graphs", "status": 1}
        ],
        "actions": [
          {"name": "acknowledge_problems", "status": 1},
          {"name": "close_problems", "status": 0}
        ]
      }
    },
    "auth": "YOUR_AUTH_TOKEN",
    "id": 1
  }'

Pratik Senaryo: Çok Katmanlı Ekip Yapısı

Tipik bir şirkette şu ekip yapısını görüyorum:

  • Zabbix yöneticileri (sistem ekibi)
  • NOC operatörleri (7/24 izleme yapan ekip)
  • Uygulama ekipleri (kendi servislerini izleyen geliştiriciler)
  • Yöneticiler (sadece dashboard görmesi gereken C-level veya takım liderleri)
  • Dış müşteriler veya taşeron firmalar (sınırlı erişim)

Her birinin farklı yetkiye ihtiyacı var. Hepsine admin verirseniz ne olduğunu anlatmama gerek yok.

Host Grupları ile Yetki Segmentasyonu

Host gruplarını düzgün organize etmek yetki yönetiminin temelidir. Zabbix’te nested host groups destekleniyor, yani Linux Servers/Production ve Linux Servers/Test şeklinde hiyerarşik yapı kurabiliyorsunuz.

Ben genellikle şu yapıyı kullanıyorum:

Infrastructure/
  Infrastructure/Network
  Infrastructure/Storage
  Infrastructure/Virtualization
Applications/
  Applications/Frontend
  Applications/Backend
  Applications/Database
Environments/
  Environments/Production
  Environments/Staging
  Environments/Development

Bir host birden fazla gruba atanabiliyor. Örneğin production’daki bir PostgreSQL sunucusu hem Applications/Database hem de Environments/Production grubunda olabilir. Bu esnekliği doğru kullanmak önemli.

Zabbix API ile toplu host grup oluşturma:

#!/bin/bash
ZABBIX_URL="http://zabbix-server/zabbix/api_jsonrpc.php"
AUTH_TOKEN="YOUR_TOKEN_HERE"

declare -a GROUPS=(
  "Infrastructure/Network"
  "Infrastructure/Storage"
  "Applications/Database"
  "Applications/Backend"
  "Environments/Production"
  "Environments/Staging"
)

for GROUP in "${GROUPS[@]}"; do
  curl -s -X POST -H 'Content-Type: application/json' 
    "$ZABBIX_URL" 
    -d "{
      "jsonrpc": "2.0",
      "method": "hostgroup.create",
      "params": {"name": "$GROUP"},
      "auth": "$AUTH_TOKEN",
      "id": 1
    }" | python3 -m json.tool
  echo "Created: $GROUP"
done

Kullanıcı Grupları Oluşturma ve Yapılandırma

Kullanıcı grubu oluştururken dikkat edilmesi gereken iki ana alan var: Host group permissions ve Tag-based permissions.

Arayüzden gitmek istiyorsanız: Administration > User groups > Create user group

Ama benim tercihim her zaman API veya Terraform Zabbix provider üzerinden yapmak. Böylece konfigürasyon as-code prensibiyle yönetiliyor ve git’e gidiyor.

API ile kullanıcı grubu oluşturma örneği:

curl -s -X POST -H 'Content-Type: application/json' 
  http://zabbix-server/zabbix/api_jsonrpc.php 
  -d '{
    "jsonrpc": "2.0",
    "method": "usergroup.create",
    "params": {
      "name": "NOC_Team",
      "gui_access": 0,
      "users_status": 0,
      "hostgroup_rights": [
        {
          "id": "15",
          "permission": 2
        },
        {
          "id": "16",
          "permission": 2
        }
      ]
    },
    "auth": "YOUR_AUTH_TOKEN",
    "id": 1
  }'

Permission değerleri:

  • 0: Erişim yok (Deny)
  • 2: Read-only
  • 3: Read-Write

Önemli bir nokta: Eğer bir kullanıcı birden fazla gruba üyeyse ve bu grupların aynı host grubuna farklı permission’ları varsa, en kısıtlayıcı olan geçerli olmuyor, en yüksek izin geçerli oluyor. Bu sezgisel olmayan bir davranış, kafanızı karıştırabilir. Yani bir kullanıcıyı hem Read-only grubuna hem de Read-Write grubuna koyarsanız, Read-Write geçerli olacak.

Tag Tabanlı Yetki Sistemi

Zabbix 5.0 ile gelen tag tabanlı yetki sistemi gerçekten güçlü bir özellik. Host grupları üzerinden yetki vermek bazen granüler olmayabiliyor. Mesela aynı host grubundaki bazı problem’ları gösterip bazılarını gizlemek isteyebilirsiniz.

Örneğin bir e-ticaret şirketinde çalışıyorsunuz ve hem ödeme altyapısı hem de içerik yönetim sistemi aynı Applications/Backend grubunda. PCI-DSS kapsamındaki ödeme sistemlerine sadece güvenlik ekibinin erişmesini istiyorsunuz.

Bunun için host’lara ve trigger’lara team:payments gibi etiketler ekleyip kullanıcı grubu konfigürasyonunda tag filtresi tanımlıyorsunuz. Bu sayede aynı host grubunda bile kimin neyi göreceğini kontrol edebiliyorsunuz.

Authentication: LDAP ve SAML Entegrasyonu

Büyük ortamlarda kullanıcıları Zabbix’e manuel eklemek yönetilemez hale geliyor. LDAP veya SAML entegrasyonu şart.

LDAP konfigürasyonu için: Administration > Authentication > LDAP

Temel parametreler:

  • LDAP host: ldap://your-dc.company.local
  • Port: 389 (LDAP) veya 636 (LDAPS)
  • Base DN: DC=company,DC=local
  • Search attribute: sAMAccountName (AD için) veya uid (OpenLDAP için)
  • Bind DN: CN=zabbix-bind,OU=ServiceAccounts,DC=company,DC=local

LDAP testi için Zabbix sunucusu üzerinde:

ldapsearch -x -H ldap://your-dc.company.local 
  -D "CN=zabbix-bind,OU=ServiceAccounts,DC=company,DC=local" 
  -w "bindpassword" 
  -b "DC=company,DC=local" 
  "(sAMAccountName=testuser)" cn mail memberOf

LDAP ile giriş yapan kullanıcılar Zabbix’te otomatik oluşturulabiliyor ama bunların hangi kullanıcı grubuna atanacağı önemli. LDAP JIT (Just-In-Time) provisioning ile Active Directory gruplarını Zabbix kullanıcı gruplarına eşleyebiliyorsunuz.

Zabbix 6.2 ve üzerinde bu eşleme daha gelişmiş hale geldi. LDAP group membership’e göre otomatik Zabbix grubu ataması yapılabiliyor:

# Zabbix konfigürasyon dosyasında LDAP ayarları
# /etc/zabbix/zabbix_server.conf

# LDAP ayarları arayüzden yapılıyor, burada sadece TLS sertifikası için:
TLSCAFile=/etc/ssl/certs/ca-bundle.crt

Kullanıcı Oluşturma ve Güvenlik Ayarları

API üzerinden kullanıcı oluşturma:

curl -s -X POST -H 'Content-Type: application/json' 
  http://zabbix-server/zabbix/api_jsonrpc.php 
  -d '{
    "jsonrpc": "2.0",
    "method": "user.create",
    "params": {
      "username": "john.doe",
      "name": "John",
      "surname": "Doe",
      "passwd": "InitialPassword123!",
      "roleid": "2",
      "usrgrps": [
        {"usrgrpid": "8"},
        {"usrgrpid": "12"}
      ],
      "user_medias": [
        {
          "mediatypeid": "1",
          "sendto": "[email protected]",
          "active": 0,
          "severity": 63,
          "period": "1-7,00:00-24:00"
        }
      ]
    },
    "auth": "YOUR_AUTH_TOKEN",
    "id": 1
  }'

Parola politikası için Zabbix’in kendi ayarlarına bakmanız gerekiyor: Administration > Authentication > Password policy. Minimum uzunluk, büyük/küçük harf zorunluluğu, özel karakter gibi ayarlar burada.

Audit Log ile Takip

Kim ne zaman ne yaptı? Bu sorunun cevabını Zabbix’in audit log özelliği veriyor. Administration > Audit log bölümünde tüm değişiklikler kayıtlı.

Ama audit log’u düzenli kontrol etmek yerine, kritik değişiklikler için alert almak daha mantıklı. Bunu Zabbix’in kendi internal check’leri ile yapabilirsiniz ya da audit log’u dışarı aktarıp bir SIEM çözümüne besleyebilirsiniz.

PostgreSQL üzerinde audit logları sorgulamak için:

# Zabbix veritabanında audit log sorgusu
psql -U zabbix -d zabbix -c "
SELECT 
  to_timestamp(clock) as action_time,
  username,
  ip,
  action,
  resourcetype,
  resourcename,
  details
FROM auditlog 
WHERE clock > extract(epoch from now()) - 86400
  AND action IN (0,1,2)
ORDER BY clock DESC
LIMIT 50;
"

Action değerleri:

  • 0: Add
  • 1: Update
  • 2: Delete
  • 4: Login
  • 5: Logout
  • 6: Failed login

Automation: Zabbix API ile Kullanıcı Yönetimi Script’i

Büyük ortamlarda kullanıcı ekleme/çıkarma işlemlerini manuel yapmak hem hata prone hem de zaman kaybı. Ben LDAP ile Zabbix arasında senkronizasyon script’i kullanıyorum:

#!/usr/bin/env python3
"""
Zabbix kullanici grubu senkronizasyon script'i
AD grubundaki kullanicilari Zabbix grubuna sync eder
"""

import json
import requests
import ldap3

ZABBIX_URL = "http://zabbix-server/zabbix/api_jsonrpc.php"
ZABBIX_USER = "api_service_account"
ZABBIX_PASS = "securepassword"
LDAP_SERVER = "ldap://dc.company.local"
LDAP_BIND_DN = "CN=zabbix-bind,OU=ServiceAccounts,DC=company,DC=local"
LDAP_BIND_PASS = "ldapbindpassword"
LDAP_BASE_DN = "DC=company,DC=local"

def zabbix_auth():
    payload = {
        "jsonrpc": "2.0",
        "method": "user.login",
        "params": {"username": ZABBIX_USER, "password": ZABBIX_PASS},
        "id": 1
    }
    response = requests.post(ZABBIX_URL, json=payload)
    return response.json()["result"]

def get_ldap_group_members(group_cn):
    server = ldap3.Server(LDAP_SERVER)
    conn = ldap3.Connection(server, LDAP_BIND_DN, LDAP_BIND_PASS, auto_bind=True)
    conn.search(
        LDAP_BASE_DN,
        f"(&(objectClass=group)(cn={group_cn}))",
        attributes=["member"]
    )
    members = []
    if conn.entries:
        for member_dn in conn.entries[0].member:
            conn.search(LDAP_BASE_DN, f"(distinguishedName={member_dn})",
                       attributes=["sAMAccountName", "mail"])
            if conn.entries:
                members.append({
                    "username": str(conn.entries[0].sAMAccountName),
                    "email": str(conn.entries[0].mail)
                })
    return members

if __name__ == "__main__":
    token = zabbix_auth()
    members = get_ldap_group_members("Zabbix-NOC-Operators")
    print(f"Bulunan uye sayisi: {len(members)}")
    for member in members:
        print(f"  - {member['username']} ({member['email']})")

Yaygın Hatalar ve Dikkat Edilmesi Gerekenler

“Deny” kuralını unutmak: Eğer bir kullanıcı grubuna hiç host group permission tanımlamazsanız, o grup hiçbir host’u göremez. Bu bazen istenen davranış olabilir ama çoğu zaman gözden kaçan bir durum.

Disabled user groups: Bir kullanıcı grubunu disable ettiğinizde, o gruptaki tüm kullanıcılar sisteme giremez hale gelir. Maintenance window’larda işe yarıyor ama yanlışlıkla yapılırsa ciddi sorun çıkarabilir.

API token yönetimi: Servis hesapları için şifre yerine API token kullanın. Zabbix 5.4 ile gelen bu özellik, her token için IP kısıtlaması ve son kullanma tarihi tanımlamanıza izin veriyor.

Super Admin’i sınırlandıramazsınız: Super Admin rolündeki kullanıcılar için host group permission tanımlamak işe yaramıyor. Bu role her şeye erişiyor. Bu yüzden Super Admin sayısını minimumda tutun.

Sonuç

Zabbix’te kullanıcı yönetimi ilk bakışta karmaşık görünüyor ama mantığını kavradıktan sonra oldukça esnek bir yapı sunuyor. Temel prensipler şunlar:

Rol sistemiyle ne yapabileceklerini, host group permission’larıyla neyi görebileceklerini, tag tabanlı yetkilendirmeyle daha granüler erişimi yönetin. LDAP entegrasyonunu mümkün olan en kısa sürede devreye alın, manuel kullanıcı yönetimi ölçeklenmiyor. Audit log’ları takip edin ve kritik değişiklikler için alerting kurun.

En önemlisi, bu yapıyı kod olarak yönetin. Terraform Zabbix provider veya direkt API script’leri ile yapılandırmanızı git’e koyun. Bir gün Zabbix sunucunuzu sıfırdan kurmanız gerektiğinde ya da audit sırasında “bu kullanıcıya neden bu yetkiyi verdik?” sorusunu yanıtlamanız gerektiğinde, bu alışkanlık hayat kurtarıyor.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir