PostgreSQL ile PCI-DSS Uyumluluğunu Sağlamak
Not: Yakın zamanda, (Kasım 2017’de bekliyoruz) dördüncü sürümü duyurulacak olan PCI-DSS standartlarında getirilecek olan yenilikleri anlatan yazımız gelecek hafta yayınlanacaktır. Dolayısı ile bu yazı önümüzdeki günlerde güncellenebilir.
PCI-DSS Nedir?
PCI-DSS kredi kartları ile alışveriş yapılırken, güvenlik standartlarını belirlemekte olan ve tüccarların seviyelerine göre sertifikaların zorunlu tutulduğu uluslararası bir güvenlik mevzuatıdır. PCI-DSS standartları (regülasyon), üyeleri arasında Mastercard, Visa, Amerikan Express, Discover Services, Veracode gibi büyük kuruluşların da bulunduğu bir kurul tarafından düzenlenmektedir.
2006 yılında duyurulan ilk sürümünden itibaren çeşitli değişikliklere uğramış ve geçen zaman içerisinde uluslararası olarak geçerlilik kazanmıştır. 28 Ekim 2017 tarihi itibariyle geçerli olan sürüm 3.2 olmakla beraber yakın zamanda PCI-DSS 4.0 sürümü duyurulacaktır.
Kimler PCI-DSS Standartlarına Uymak Zorunda?
Kart verisi tutan her şirket veya kurum PCI-DSS regülasyonuna tabidir.
Hangi Kart Verileri Ne Şekilde Tutulmalı?
Bu bilgiler için kuruluşun kendi belgesine göz atmanızda fayda var, zira denetim yapan kurumlar bazen kuralları kendilerine göre yorumlayabiliyorlar.
Technical Guidelines for PCI Data Storage
Tüccar Seviyeleri ve PCI-DSS Gereksinimleri
Ticarethanenin yaptığı işlem sayısına göre belirlen 4 farklı düzey vardır. İşlem hacmi para birimi cinsinden değil işlem sayısı olarak değerlendirilir.
| # | Level 1 | Level 2 | Level 3 | Level 4 |
|---|---|---|---|---|
| İşlem Hacmi | Yılda 6 milyondan fazla işlem yapan firmalar | Yılda 1-6 milyon arası işlem yapan firmalar | Yılda 20 bin-1 milyon arası işlem yapan firmalar | Yılda 20 binden az işlem yapan firmalar |
| Yerinde Denetleme | Yılda bir kez | Yok | Yok | Yok |
| Ağ Taraması | Üç ayda bir | Üç ayda bir | Üç ayda bir | Üç ayda bir |
| Öz Değerlendirme Formu Doldurulması | Yılda bir kez | Yılda bir kez | Yılda bir kez | Yılda bir kez |
Farklı seviyelere göre farklı yöntem ve sıklıklarla belli dönemlerde resmi denetim kurumları tarafından incelenerek yeterlilik ve uyumlulukları değerlendirilir.
PostgreSQL ile PCI-DSS Nasıl Karşılanır?
1. Kart hamili verilerini korumak için bir güvenlik duvarının (firewall) kurulması
pg_hba.conf herhangi bir firewall olsa da olmasa da içeriden ve dışarıdan bağlantı isteklerine karşı koruma sağlamaktadır. Bu koruma IP adresi, adres bloğu, kullanıcı adı vb şekillerde tanımlanabilir ve kabul et, geri kalanı reddet şeklinde yapılandırılabilir.
Ayrıca log_connections/disconnections ayarı ile bağlantıların takibi merkezi kayıt sunucusu üzerinden takip edilebilir.
2. Tedarikçilerden alınan ilk şifre ve diğer güvenlik parametrelerinin değiştirilmeden kullanılmaması
Veritabanına erişim root kullanıcısı ile yapılmasına izin verilmemektedir. Erişim için kullanılan, varsayılan “postgres” kullanıcısı için güçlü parola atanmalıdır. pg_hba.conf dosyası üzerinde host adı/ip adresi ve kullanıcı tanımları ile güvenilir kullanıcı, host, IP adresi vb kabul edilerek yapılan yetkilendirme kullanılmamalıdır. Ayrıca template1 ve postgres varsayılan veritabanları üzerine uzak bağlantı erişimi kapatılmalıdır.
Monitör kullanıcısına gereken kadar izinler verilmelidir. PUBLIC üzerindeki nesne erişim izinleri kaldırılmalıdır. Örnek monitör kullanıcısı için yetkilendirme ve fonksiyon tanımlama:
CREATE ROLE monitoruser WITH NOSUPERUSER NOCREATEROLE NOCREATEDB LOGIN PASSWORD 'X!2{K@Jnalaks-23<932_1ks2HS’;
ALTER ROLE monitoruser SET search_path TO secure_check_postgres, pg_catalog;
SET search_path to secure_check_postgres;
CREATE FUNCTION pg_ls_dir(text) RETURNS SETOF text AS $begin return query(select pg_catalog.pg_ls_dir('pg_xlog')); end$ LANGUAGE plpgsql SECURITY DEFINER;
3. Kaydedilen kritik kart hamili verilerinin korunması
“Şifreleme, sonunu kesme, maskeleme ve hash kullanmak gibi kart sahibi verilerinde kullanılabilecek olan güvenlik yöntemleri kullanılmalıdır. Bir saldırgan diğer güvenlik yöntemlerini aşar ve bir şekilde kart sahibi verilerine ulaşırsa, bu verilerin kullanılan güvenlik yöntemlerine ait anahtar, sertifika vb araçları olmadan kullanılamaz halde olması beklenir…”
PCI-DSS 3.2 sürümünün 3. gereksinim maddesinin alt maddeleri yukarıda girişi yapılan konuyu maddeler halinde açarak tüm yapılması gerekenleri detaylı olarak anlatmaktadır. Bunların arasında şifreleme için kullanılan sertifika veya anahtarların nasıl korunması gerektiği, kimlerin erişiminde olması gerekliliği gibi konular da detaylıca anlatılmaktadır. Buna yönelik olarak PostgreSQL tarafında kullanılabilecek araç, özellik ve fonksiyonlar mevcuttur.
Örneğin, “PAN bilgisinin tamamı hash’lenerek saklanmalıdır” konusunda kullanılması gereken hash metodu olarak MD5 yerine AES, SHA-256 kriptolama yöntemleri tercih edilmelidir.
pgcrypto paketi, PCI-DSS tarafından gereksinim duyulan tüm şifreleme isteklerini karşılamaktadır. (Bkz: https://www.postgresql.org/docs/current/static/pgcrypto.html)
4. Kamusal ağlar üzerinden iletilen kart hamili verilerinin ve hassas bilgilerin şifrelenmesi
Dışarıya açık, araya girilebilecek olan ağlarda verilerin şifreli olarak iletilmesini, diğer taraftan performans açısından, veri merkeziniz veya kendi güvenli ağınız içerisinde bu verilerin şifrelenmeden trafiğini sağlamak için yine pg_hba.conf dosyasını kullanabilirsiniz. pg_hba.conf dosyası üzerinden sistem yöneticisi rahatlıkla erişim esnasında şifreleme (SSL vb) kullanması gereken host veya ağları ayrı, gerekmeyenleri ayrı olarak belirleyebilir.
5. Anti-virüs yazılımı kullanılması ve yazılımın düzenli olarak güncellenmesi
PostgreSQL sunucu sisteminizin Linux/Unix olması MS Windows olmasından daha güvenlidir. Özellikle anti-virüs vb konularda işletim sisteminizin seçimi ve koruma önlemleri daha önce çıkar.
6. Güvenlik sistemleri ve uygulamaları geliştirilmesi ve devamlılığının sağlanması
Güvenlik güncellemelerinin hızlıca yapılabilmesi için altyapı sunulmaktadır. Community PostgreSQL kullanıyorsanız Linux dağıtımızın iyi olmasına ve güncelleme paketlerinin sürekli yapıldığından emin olun. EnterpriseDB Postgres Advanced Server kullanıyorsanız, güvenlik güncellemeleri kullandığınız sürüm için sürekli olarak repoda olacak ve size duyuruları gelecektir.
7. İş tanımı gereği ihtiyaç duymayan firma çalışanlarının kart hamili verilerine erişiminin sınırlanması
PostgreSQL çok uzun zamandan beri (8.4 sürümünden itibaren) sütun seviyesinde erişim yetkilendirme desteklemektedir. Kart sahibi verilerini veya nitelikli verileri standart kullanıcı ve geliştiricilerden gizlerken kullanabilir veya onlara özel görünümler veya sanal özel veritabanı desteğini kullanabilirsiniz.
8. Bilgisayar erişimi olan her bir kişi için ayrı bir kullanıcı kimliği ve şifre tanımlanması
Ortak kullanıcı ile veritabanına erişim, parola paylaşma kullanmayınız. Yetkilendirmede sadece parola ile yetinmeyip multi-faktör yetkilendirme kullanabilirsiniz.
9. Kart hamili verilerine fiziksel erişimin sınırlandırılması
pg_stat_statements eklentisini kurup tüm veritabanına yapılan sorguları (SELECT, INSERT, UPDATE, DELETE) takibe alabilirsiniz. Audit kayıtlarını uzun süreli olarak tutmanız önerilir. Bağlantı istekleri, özellikle başarısız bağlantı denemelerine alarm atamalısınız. PAN bilgilerinin tutultuğu tabloya yapılan sorgular ve erişimleri mutlaka monitör etmelisiniz.
Ödeme sistemlerinde kullanılan şifreleme mekanizmalarının veritabanı sisteminden farklı olması daha sık rastlanan bir hale gelmiştir. Web servisi, API üzerinden sunulan kart bilgisinin daha veritabanına yazılmadan önce, farklı bir sistem üzerinde tutulan anahtar ve kriptolama cihazı veya uygulaması ile şifrelenerek saklanması en geçerli koruma olarak görünmektedir. Özellikle şifreleme için kullanılan sertifikanınö çözme için kullanılacak olan private anahtarlarını kesinlikle veritabanı sunucusu üzerinde bulundurmamalısınız.
Kayıtların uzun süreli saklamanızı önereceğim. Uzun süreden kasıt en az 3 sene olmalı. Bu tamamen benim şahsi görüşüm olmakla beraber bu yargıya varmamın sebebi, SONY, VISA gibi kurumların uğradığı saldırılar ve bu saldırıların bazen çok sonra farkedilmiş olmasıdır. Eğer geçmiş dönemde yapılan bir saldırıya maruz kaldığınızı öğrenirseniz, bunu bildirme yükümlülüğünün yanı sıra, tekrar maruz kalmamak için açığı bulmanıza yardımcı olabilecek tek şey kayıtlardır.
10. Ağ kaynaklarına ve kart hamili verilerine erişimin izlenmesi
Güvenlik testi yaptırma zorunluluğunuz olmayabilir, ama yatırırsanız kimse size neden yaptırdın demeyecektir. Güvenlik testleri kurum dışı personel tarafından yapılmasını tavsiye ederim veya sadece bu konuda çalışan ayrı bir birim veya personel bulunmalıdır. Yani bu testleri veritabanı veya uygulamayı yöneten sistem yöneticileri yapmamalıdır.
11. Güvenlik sistemlerinin ve süreçlerinin düzenli olarak sınanması
Düzenlinin anlamı takvimi bilinen anlamına gelmemelidir. Mümkün ise dışarıdan yapılan güvenlik testlerinde sistem yöneticilerine haber vermeyebilirsiniz. Bu bir kargaşaya yol açabilir, açarsa da şunu görmüş olursunuz, dışarıdan yapılan bir tarama veya saldırı esnasında kurum personeli nasıl tepki vermektedir…
12. Bilgi güvenliğine yönelik bir politika belirlenmesi
Güvenliğin %80’i insan ve süreçlerden, geri kalanı ancak teknolojiden oluşmaktadır. Bunun kanıtı neredeyse %80 güvenlik ihlallerinin tamamı yetkili kullanıcı parolasının veya bilgilerinin ele geçirilmesinden kaynaklanmaktadır. Dolayısıyla eğer güvenlik konusuna daha fazla yatırım yapmak gerekiyorsa teknolojiden değil insandan başlamalısınız!
