Grafana Viewer rolü, dashboard'ların sunduğunun ötesinde organizasyondaki herhangi bir data source'u sorgulayabiliyor

dev.to üzerinde yayınlanan bir güvenlik yazısı, Grafana kurulumlarında yaygın biçimde yanlış anlaşılan bir sınıra dikkat çekiyor: Viewer rolüne sahip kullanıcılar, erişebildikleri dashboard'lara gömülmüş sorgularla sınırlı değil. Grafana'nın kendi güvenlik dokümantasyonuna atıfta bulunan yazıya göre bir Viewer, organizasyonda yapılandırılmış herhangi bir data source'a — Explore arayüzü üzerinden veya özenle hazırlanmış API istekleriyle de dahil olmak üzere — sorgu gönderebiliyor.

Dashboard görünürlüğü veri erişimi değildir

Grafana, veritabanlarına, log depolarına, metrics backend'lerine ve API'lere data source bağlantıları üzerinden ulaşır ve yerleşik bir proxy, istekleri kullanıcı veya servis hesabı adına bu servislere iletir. Yazı, bunun dashboard görünürlüğü ile data source yetkisini birbirinden ayrı iki soru hâline getirdiğini savunuyor. Hassas bir alanı gizleyen veya göstermeyen bir panel yalnızca sunumu kontrol eder; bir Viewer'ın temeldeki bağlantıdan geri ne isteyebileceğini kısıtlamaz. Grafana'nın neleri alabileceği data source ile saklanan kimlik bilgileriyle, bağlantıyı kimin kullanabileceği ise data source izin modeliyle belirlenir — birçok kurulumun olduğu gibi geniş açık bıraktığı bir model.

Proxy yollarının envanterini çıkarın ve kısıtlayın

Yazının ilk önerisi bir denetim. Her data source bir URL, bir proxy ayarı, bir kimlik doğrulama yöntemi ve izin verilen kullanıcı veya ekipler kümesi taşır ve her biri Grafana backend'inden geçen bir ağ rotasını temsil eder. Dahili metadata servislerine, yönetimsel API'lere veya paylaşılan veritabanlarına ulaşabilen bağlantılar özellikle değerli hedefler olarak işaretleniyor.

Host ve ağ katmanında yazı, giden hedefleri kısıtlamayı, hiçbir dashboard'un ihtiyaç duymadığı cloud metadata uç noktalarını, loopback adreslerini ve yönetim ağlarını kapsayan bir reddetme listesi tutmayı ve harici trafiği ayrı bir proxy veya egress gateway üzerinden yönlendirmeyi öneriyor. Kurulum destekliyorsa operatörler, proxy'den geçen her istek için hedefi, yanıt durumunu ve kullanıcı kimliğini kaydetmeli.

Data source'lar ayrıca paylaşmak yerine güven sınırına göre ayrıştırılmalı: üretim finans veritabanı, geliştirme metrics deposu ve paylaşılan log kümesi hepsi tek bir geniş yetkili bağlantı üzerinden erişilebilir olmamalı. Her data source, ihtiyaç duyduğu en az izinlerle kendi servis kimliğine sahip olmalı ve backend destekliyorsa yalnızca okuma kimlik bilgileri tercih edilmeli.

Sorgu yetkisini sıkılaştırın

Yazıya göre Grafana Cloud ve Grafana Enterprise, bir bağlantıyı kimin sorgulayacağını, düzenleyeceğini veya yöneteceğini sınırlayabilen, kullanıcılara, ekiplere ve rollere atanabilen bir data source izin modeli sunuyor. Self-managed kurulumlarda ise rol tasarımı ve kurulu sürümün özellik seti hangi kontrollerin gerçekten mevcut olduğunu belirler; bu yüzden yöneticiler dashboard izinlerinin yeterli olduğunu varsaymak yerine kullandıkları sürümü kontrol etmeli.

Yazar ayrıca etiketlere veya attribute tabanlı erişime dayalı genel yetki vermeler konusunda uyarıyor ve etkin sorgu yolunu yalnızca Viewer erişimi olan bir hesapla doğrulamayı öneriyor: dashboard dışında bir sorgu çalıştırın, farklı bir zaman aralığı deneyin ve data source proxy'sine doğrudan bir API çağrısı yapın. Yüksek yetkili veritabanı kimlik bilgileri, daha kısıtlı bir iletme kimliği işi görebilirken paylaşılan bir data source'a ait olmamalı; kullanıcıların paylaşılan bir veritabanını sorgulaması gerekiyorsa tenant veya satır düzeyi kısıtlamalar veritabanı rolünün kendisinde uygulanmalı. Grafana içinde yapılandırılan görünürlük, veritabanında uygulanan yetkilendirmenin yerini tutmaz.

Dashboard'ları kod olarak ele alın

Dashboard JSON'u sorgular, URL'ler ve değişkenler içerebildiği için yazı, beklenmedik tablo veya servislere yönelik sorgular için version control'teki değişikliklerin gözden geçirilmesini öneriyor. Özellikle dashboard değişkenleri, bir kullanıcının sorguyu yazarının niyet etmediği biçimlerde şekillendirmesine olanak tanıyabilir; parametrelendirme yalnızca sunucu tarafındaki bir data source politikasıyla desteklenen template değişkenleri üzerinden yapılmalı.

Transport hijyeni konusunda: Grafana'yı küçük bir ağ rolüne sahip bir servis hesabı altında çalıştırın, data source bağlantılarında TLS kullanın ve hedef sertifikalarını doğrulayın, özel sertifika otoritesi güvenini yalnızca ilgili bağlantıya göre sınırlandırın ve bir dashboard'un çalışması için hostname doğrulamasını asla kapatmayın. Son olarak hata senaryolarını test edin — bir kullanıcının data source iznini iptal edin ve hem dashboard'un hem de Explore sorgusunun başarısız olduğunu doğrulayın, proxy izin listesini değiştirin ve engellenen bir hedefe ulaşılamadığını teyit edin ve yalnızca yanıt kodları yerine giden loglardaki deneme isteklerini inceleyin.

Neden önemli

dev.to yazısından çıkan temel ders, Grafana'nın bir sunum katmanı olduğu kadar bir sorgu istemcisi olduğu ve yapılandırılmış her data source'un kendi kimliği, ağ rotası ve izinleriyle kimliği doğrulanmış bir API bağlantısı gibi davrandığı. Dashboard'ları güvenlik sınırı olarak gören organizasyonlar, fiilen her Viewer'a organizasyondaki en yetkili data source kimlik bilgilerinin erişimini veriyor. Burada kurulacak bir yama yok — maruziyet mimarisel — bu yüzden çözüm yapılandırma disiplini: en az ayrıcalıklı servis kimlikleri, güven sınırlarıyla eşleşen data source izinleri ve bir dashboard'un gösterdiğiyle bir kullanıcının gerçekten alabileceğini hizalayan ağ egress kontrolleri.