- Konu sahibi
- #1
En az ayrıcalık ilkesi, web uygulamasındaki her kullanıcıya, servise ve işlem hesabına yalnızca görevini yerine getirmek için zorunlu olan izinleri vermektir. Uygulamada bunun karşılığı; web sunucusunu ayrı bir işletim sistemi kullanıcısıyla çalıştırmak, veritabanında sınırlı bir rol kullanmak, yüklenen dosyaları çalıştırılamaz tutmak ve yönetim işlemlerini normal uygulama hesabından ayırmaktır.
Bir isteğin uygulamaya ulaşmasından veritabanına veya dosya sistemine erişmesine kadar her katmanda ayrı bir yetki sınırı bulunur. Bu sınırlar, bir uygulama açığının etkisini daraltır; ek bir ayrıcalık yükseltme açığının hiç bulunmadığına dair garanti vermez.
Örneğin bir blog uygulamasında şu ayrım yapılabilir:
Bu ayrım, tek bir hesabın hem web dosyalarını değiştirmesini hem de veritabanında sınırsız işlem yapmasını engeller. İzinler mümkün olan en dar kapsamda başlatılır; uygulamanın gerçekten ihtiyaç duyduğu bir işlem başarısız olursa yalnızca o işlem için gerekli izin eklenir.
Aşağıdaki örnekte uygulamanın Linux üzerinde
Bir PostgreSQL uygulamasında çalışma rolüne yalnızca gerekli tablo işlemleri verilebilir. Örneğin uygulamanın yalnızca
Bu örnek, uygulama rolünün önceden oluşturulduğu, nesne sahibi/superuser olmadığı ve doğrudan, grup üyeliğinden veya PUBLIC üzerinden geniş hak almadığı varsayımıyla yalnız gerekli izinleri ekler; mevcut fazla izinleri kendiliğinden kaldırmaz. Şemadaki bir REVOKE komutu da tablo, rol üyeliği ve PUBLIC haklarını topluca temizlemez. Var olan kurulumda etkin hakları ve nesne sahipliğini önce denetleyin. Şema ve tablo adlarını kendi test nesnelerinizle eşleştirin. Başarılı uygulama sonucunda uygulama gerekli sorguları çalıştırır; yetki dışı bir sorguda veritabanı erişim hatası alınır. Hata görülürse doğrudan yönetici yetkisi vermek yerine hatanın hangi tablo veya işlemden kaynaklandığını belirleyip yalnızca o izni ekleyin. Serial/nextval kullanılan bir yorum kimliği varsa ilgili sequence için USAGE gibi ayrıca gereken en dar hak da bulunabilir; gerçek sequence adını doğrulayın. INSERT ... RETURNING ile okunan sütunlar için SELECT gereksinimini de hesaba katın. Şema değişiklikleri gerekiyorsa bunları ayrı bakım rolüyle çalıştırın.
Uygulama içindeki nesne erişimini de her istekte kontrol edin: örneğin kullanıcı yalnız kendi belgesini indirebilmeli, URL’deki kimliği değiştirerek başka kullanıcının belgesine erişememelidir. Yönetim düğmesini arayüzde gizlemek sunucudaki yetki kontrolünün yerine geçmez. Tanımlanmamış erişimleri varsayılan olarak reddedin.
Web sunucusunu yönetici hesabıyla çalıştırmak: Bir uygulama açığı, dosya sisteminin ve sunucunun tamamında etkili olabilir. Uygulama için ayrı hesap kullanın.
Tüm dosyalara yazma izni vermek: Kod dizininin yazılabilir olması, ele geçirilen uygulamanın kendi kodunu kalıcı olarak değiştirmesini kolaylaştırır. Yazma ihtiyacını yalnızca önceden belirlenmiş çalışma ve yükleme dizinleriyle sınırlayın.
Veritabanı yöneticisini uygulamaya vermek: Uygulama sorgu çalıştırabilse de rol oluşturma veya tablo silme yetkisine çoğu zaman ihtiyaç duymaz. Yönetici hesabını yalnızca bakım işlemlerinde kullanın.
İzin ekleyip geri değerlendirmemek: Geçici teşhis için verilen geniş yetki kalıcı hale gelebilir. Her değişikliği kaydedin, gereksiz izinleri kaldırın ve düzenli olarak uygulamanın gerçek erişim listesini gözden geçirin.
Hayır. İşletim sistemi hesabı, ağ erişimi, bulut servis rolleri, API anahtarları, yönetici ekranları ve uygulama içindeki kullanıcı rolleri de aynı ilkeye göre sınırlandırılmalıdır.
İşlevi dar bir test ortamında çalıştırın, hangi kaynaklara gerçekten ihtiyaç duyduğunu günlüklerden ve uygulama hatalarından belirleyin, sonra yalnızca bu kaynaklara izin verin. Test tamamlandığında geçici geniş yetkileri kaldırın.
Yazma ihtiyacı varsa gereklidir; ancak bu dizin koddan ayrılmalı, içerik türü ve dosya adı doğrulanmalı, yüklenen içerik doğrudan çalıştırılmamalı ve mümkünse uygulamanın genel web kökünün dışında tutulmalıdır.
İlke nasıl çalışır?
Bir isteğin uygulamaya ulaşmasından veritabanına veya dosya sistemine erişmesine kadar her katmanda ayrı bir yetki sınırı bulunur. Bu sınırlar, bir uygulama açığının etkisini daraltır; ek bir ayrıcalık yükseltme açığının hiç bulunmadığına dair garanti vermez.
Örneğin bir blog uygulamasında şu ayrım yapılabilir:
| Bileşen | Gerekli izin | Verilmemesi gereken yetki |
|---|---|---|
| Web uygulaması | Kendi kodunu ve gerekli yapılandırmayı okuyabilme | Tüm sunucuda yönetici yetkisi |
| Veritabanı rolü | Uygulamanın kullandığı tablolarda gerekli okuma ve yazma işlemleri | Rol oluşturma, sunucu ayarı değiştirme, tüm veritabanlarını yönetme |
| Yükleme dizini | Dosya oluşturma ve gerektiğinde okuma | Yüklenen dosyaları program olarak çalıştırma |
Bu ayrım, tek bir hesabın hem web dosyalarını değiştirmesini hem de veritabanında sınırsız işlem yapmasını engeller. İzinler mümkün olan en dar kapsamda başlatılır; uygulamanın gerçekten ihtiyaç duyduğu bir işlem başarısız olursa yalnızca o işlem için gerekli izin eklenir.
Uygulanabilir kurulum planı
Aşağıdaki örnekte uygulamanın Linux üzerinde
webapp kullanıcısıyla, PostgreSQL veritabanının da app_runtime rolüyle çalıştığı varsayılmıştır. İsimleri kendi ortamınızdaki karşılıklarla değiştirin.- Uygulama için ayrı bir işletim sistemi hesabı oluşturun ve web sürecini bu hesapla çalıştırın. Bu hesapta kabukla oturum açmayı zorunlu bırakmayın; yalnızca uygulamanın dosyalarına ve ihtiyaç duyduğu çalışma dizinlerine erişim verin.
- Kod, yapılandırma ve yükleme dizinlerini ayırın. Kod dizinini çalışma hesabı için mümkünse yalnızca okunabilir tutun; yükleme dizininde yazma izni verin. Yükleme dizininde sunucunun betik veya ikili dosya çalıştırmasını engelleyin.
- Uygulamanın gerektirdiği veritabanı işlemlerini listeleyin. Örneğin ziyaretçi işlemleri için yazı okumaya, yorum eklemeye ve oturum kaydı oluşturmaya izin gerekebilir; ancak şema silme veya yeni veritabanı rolü oluşturma izni gerekmez.
- Çalışma rolünü yönetici rolünden ayırın. Şema oluşturma ve migration işlemleri için ayrı bir bakım hesabı kullanın; bu hesabın parolasını veya erişim bilgisini normal web sürecine vermeyin.
- Gizli bilgileri kod deposuna ve herkese açık web dizinine koymayın. Uygulama hesabının yalnızca kendi gizli yapılandırmasını okuyabilmesini sağlayın; yedek, günlük ve başka uygulamaların sırlarını aynı erişim alanına bırakmayın.
- Yönetim işlemlerini ayrı bir yetki akışıyla sınırlandırın. Normal ziyaretçi isteğiyle dosya silme, kullanıcı rolü değiştirme veya sistem komutu çalıştırma gibi işlemler doğrudan yapılmamalıdır; gerekiyorsa ayrıca kimlik doğrulama, yetki kontrolü ve işlem günlüğü uygulanmalıdır.
- Uygulamanın temel işlevlerini test edin. Sayfa okuma, giriş, kayıt, dosya yükleme ve yönetim işlemlerini ayrı ayrı deneyin. Beklenen sonuç, her işlevin çalışması ve uygulama hesabının ilgisiz dosya, tablo veya yönetim işlemine erişememesidir.
Somut örnek: veritabanı yetkisini daraltma
Bir PostgreSQL uygulamasında çalışma rolüne yalnızca gerekli tablo işlemleri verilebilir. Örneğin uygulamanın yalnızca
posts tablosunu okuması ve comments tablosuna yeni yorum eklemesi gerekiyorsa, rolün tüm veritabanına yönetici yetkisiyle bağlanması yerine bu işlemler açıkça tanımlanır:
SQL:
GRANT USAGE ON SCHEMA public TO app_runtime;
GRANT SELECT ON TABLE public.posts TO app_runtime;
GRANT INSERT ON TABLE public.comments TO app_runtime;Bu örnek, uygulama rolünün önceden oluşturulduğu, nesne sahibi/superuser olmadığı ve doğrudan, grup üyeliğinden veya PUBLIC üzerinden geniş hak almadığı varsayımıyla yalnız gerekli izinleri ekler; mevcut fazla izinleri kendiliğinden kaldırmaz. Şemadaki bir REVOKE komutu da tablo, rol üyeliği ve PUBLIC haklarını topluca temizlemez. Var olan kurulumda etkin hakları ve nesne sahipliğini önce denetleyin. Şema ve tablo adlarını kendi test nesnelerinizle eşleştirin. Başarılı uygulama sonucunda uygulama gerekli sorguları çalıştırır; yetki dışı bir sorguda veritabanı erişim hatası alınır. Hata görülürse doğrudan yönetici yetkisi vermek yerine hatanın hangi tablo veya işlemden kaynaklandığını belirleyip yalnızca o izni ekleyin. Serial/nextval kullanılan bir yorum kimliği varsa ilgili sequence için USAGE gibi ayrıca gereken en dar hak da bulunabilir; gerçek sequence adını doğrulayın. INSERT ... RETURNING ile okunan sütunlar için SELECT gereksinimini de hesaba katın. Şema değişiklikleri gerekiyorsa bunları ayrı bakım rolüyle çalıştırın.
Uygulama içindeki nesne erişimini de her istekte kontrol edin: örneğin kullanıcı yalnız kendi belgesini indirebilmeli, URL’deki kimliği değiştirerek başka kullanıcının belgesine erişememelidir. Yönetim düğmesini arayüzde gizlemek sunucudaki yetki kontrolünün yerine geçmez. Tanımlanmamış erişimleri varsayılan olarak reddedin.
Sık yapılan hatalar
Web sunucusunu yönetici hesabıyla çalıştırmak: Bir uygulama açığı, dosya sisteminin ve sunucunun tamamında etkili olabilir. Uygulama için ayrı hesap kullanın.
Tüm dosyalara yazma izni vermek: Kod dizininin yazılabilir olması, ele geçirilen uygulamanın kendi kodunu kalıcı olarak değiştirmesini kolaylaştırır. Yazma ihtiyacını yalnızca önceden belirlenmiş çalışma ve yükleme dizinleriyle sınırlayın.
Veritabanı yöneticisini uygulamaya vermek: Uygulama sorgu çalıştırabilse de rol oluşturma veya tablo silme yetkisine çoğu zaman ihtiyaç duymaz. Yönetici hesabını yalnızca bakım işlemlerinde kullanın.
İzin ekleyip geri değerlendirmemek: Geçici teşhis için verilen geniş yetki kalıcı hale gelebilir. Her değişikliği kaydedin, gereksiz izinleri kaldırın ve düzenli olarak uygulamanın gerçek erişim listesini gözden geçirin.
Kaynaklar
- OWASP: En az ayrıcalık ve her istekte yetki
- PostgreSQL: Etkin nesne ayrıcalıkları
- PostgreSQL: GRANT ve sequence hakları
Sık sorulan sorular
En az ayrıcalık yalnızca dosya ve veritabanı izinlerinden mi oluşur?
Hayır. İşletim sistemi hesabı, ağ erişimi, bulut servis rolleri, API anahtarları, yönetici ekranları ve uygulama içindeki kullanıcı rolleri de aynı ilkeye göre sınırlandırılmalıdır.
Bir işlev için gereken izni nasıl belirlerim?
İşlevi dar bir test ortamında çalıştırın, hangi kaynaklara gerçekten ihtiyaç duyduğunu günlüklerden ve uygulama hatalarından belirleyin, sonra yalnızca bu kaynaklara izin verin. Test tamamlandığında geçici geniş yetkileri kaldırın.
Yükleme dizinine yazma izni vermek güvenli midir?
Yazma ihtiyacı varsa gereklidir; ancak bu dizin koddan ayrılmalı, içerik türü ve dosya adı doğrulanmalı, yüklenen içerik doğrudan çalıştırılmamalı ve mümkünse uygulamanın genel web kökünün dışında tutulmalıdır.
