Network cihazlarında “birkaç yerel admin” kısa vadede pratik görünür; uzun vadede ise üç problem üretir: iz yok, rol yok, geri alma yok. Üstelik ekip büyüdükçe, kim hangi cihaza ne zaman girdi sorusu cevaplanamaz hale gelir. TACACS+ bu yüzden sadece “login” aracı değil, operasyonel denetim katmanıdır.
Hedef: üç şeyi aynı anda çöz
TACACS+’ı üretimde değerli yapan üç kullanım:
- Authentication: Kim girdi?
- Authorization: Bu kişi hangi rol ve hangi komutları çalıştırabilir?
- Accounting: Ne yaptı, hangi komutu çalıştırdı, oturum ne kadar sürdü?
Minimum mimari: iki TACACS+ sunucusu + kimlik kaynağı + log hattı
Pratik bir kurulumda şu bileşenler yeterli olur:
- TACACS+ sunucuları (HA): en az 2 node (site/zone ayrımı mümkünse)
- Kimlik kaynağı: AD/LDAP/SSO (grup eşleme)
- Role policy: grup → rol → izinli komut seti
- Log hattı: TACACS+ accounting logları → merkezi log/SIEM
Ek ama yüksek değerli iki parça:
- Break-glass: kontrollü acil erişim
- Config backup: değişiklik sonrası otomatik “running-config snapshot”
Rol tasarımı: 3 rol ile başla (sonra genişlet)
Sahada en işe yarayan başlangıç rolleri:
- ReadOnly: show/diagnose (no config)
- Operator: sınırlı config (interface up/down, BGP neighbor reset gibi net sınırlı)
- Admin: tam yetki (az kişide)
Rol sayısı arttıkça yönetim maliyeti de artar. Bu yüzden ilk hedef “mükemmel RBAC” değil, yerel hesapları azaltmak ve iz üretmek olmalı.
Komut yetkilendirme: sınırı teknik olarak kanıtla
Komut kontrolünün iki kritik faydası vardır:
- Yanlışlıkla yapılan “tehlikeli” komutları azaltır
- Denetimde “görev ayrılığı” maddesini teknik kanıta bağlar
Pratik yaklaşım:
- “config terminal / write memory / reload” gibi yüksek riskli komutlar sadece admin
- Operasyonel müdahale komutları (ör. belirli reset) operator rolünde, net sınırla
- Readonly rolünü “sadece show” seviyesinde tut
Accounting: oturum kaydını ‘olay kanıtı’ haline getir
TACACS accounting verisi, incident anında iki şeyi hızlandırır:
- “Kim neyi değiştirdi?” sorusunu dakikalar içinde cevaplar
- Postmortem’de “varsayım” yerine kanıt sunar
Minimum log alanları:
- kullanıcı, cihaz, kaynak IP
- oturum başlangıç/bitiş
- çalıştırılan komut(lar)
- result (permit/deny)
Dayanıklılık: TACACS+ yoksa ne olacak?
Burada “fail-open mı fail-closed mu?” kararı kritik:
- Fail-open: TACACS yoksa local fallback ile erişim sürer (operasyon kurtulur, risk artar)
- Fail-closed: TACACS yoksa erişim kesilir (güvenlik artar, kriz anında felaket olabilir)
Sahada genel denge:
- Kritik üretim cihazlarında kontrollü local fallback (break-glass) + güçlü alarm
- Yönetim ağında out-of-band kanal + “TACACS down” runbook
Break-glass: acil erişimi sistematik hale getir
Break-glass, “şifreyi bir yere yazalım” değildir. Sağlıklı model:
- Süreli aktivasyon (örn. 30 dk)
- İki kişi onayı (en azından kritik segmentte)
- Oturum kaydı zorunluluğu
- Tatbikat (yılda birkaç kez)
Operasyonel checklist (ilk 30 gün)
- Yerel admin hesapları envanteri çıkarıldı
- 3 rol tanımlandı (ReadOnly/Operator/Admin)
- Komut allowlist taslağı yazıldı
- Accounting logları merkezi log’a akıyor
- TACACS healthcheck + alarm var
- Break-glass prosedürü ve tatbikat takvimi yazıldı
Sonuç
TACACS+ ile ağ cihazlarında AAA kurmak, kimliği merkezileştirmekten fazlasıdır: rol, komut kontrolü ve audit izi ile operasyonu güvenli hale getirir. Benim sahada gördüğüm en sağlam yaklaşım; önce az rol ile başlamak, accounting’i ilk günden işletmek ve TACACS kesintisi/break-glass senaryosunu runbook’a bağlamaktır. Böyle kurulduğunda TACACS+, “güvenlik projesi” değil, günlük operasyonun güvenli çalışma yüzeyi olur.