Blog
GRC konusunda yeni trendler, regülasyonlar ve eğitimleri takip etmek için blog yazılarımıza göz atabilirsiniz.
7 Adımda SAP Sistemlerini KVKK/GDPR Uyumlu Hale Getirmek 14 Eylül 2018
KVKK regülasyonu kapsamında yapılacak ç ok iş var hakikaten. Bu ç alışmalar sadece bilginin tutulduğu sistemlerin ö tesinde, ç alışma kültürün baş tan a şağı yenilenmesini gerektiren ç alışmalar. Kişisel veri kapsamında bilgi sistemlerini elden ge ç irirken ERP programını koymamız gereken yeri ve yapılacak ç alışmaların ç er ç evesini bir ö nceki yazımda anlatmaya ç alışmıştım. Bugünkü yazımda ise spesifik olarak SAP kullanan firmalar i ç in SAP sistemlerinin KVKK uyumlu hale getirilmesi i ç in izlenecek yol haritası ile ilgili fikirlerimi yazmaya ç alışacağım.
Tabi bir SAP danışmanı olarak bu yazımda biraz daha teknik detaylardan bahsetmeye ç alışacağım. Zira genelde yapılacak işlerle ilgili teknik mimari ç izildikten sonra spesifik olarak yapılması gereken işleri listelemek ve planlamak zor olabiliyor. Tabi bu adımlara başlamadan ö nce bir ö nceki yazımdaki yol haritasını kısaca bir hatırlatmalıyım sanırım. Hemen altına da SAP sistemleri i ç in ö ng ö rdüğüm yol haritasını ekleyeceğim. Bu sayede her iki yaklaşımın da kesişim noktalarını da do ğrulamış olacağız.
Şekil 1: ERP sistemlerinin KVKK / GDPR uyumlu hale getirilmesi
Şekil 2: SAP sistemlerinin KVKK / GDPR uyumlu hale getirilmesi
Tabi bu iki yol haritasının daha sağlıklı bir karşılaştırmasını yapabilmek i ç in SAP sistemlerinde yapılacak olan ç alışmaları biraz daha detaylı anlatmak gerekecek. Sırasıyla başlayalım;
0. Sistemin İzlenmesi: SAP sistemlerindeki işlemlerin tam anlamıyla izlenmesi ve izleme sonu ç larını n d üzenli analiz edilerek kuşkuya yer bırakmayacak şekilde, kişisel verilerin suistimal edilmediğini ya da bu suistimalin ö nüne ge ç ildiğinin raporlanması beklenmektedir. SAP, kullanıcıların ya da dış sistemlerin sistemdeki hareketlerini kayı t alt ına almak adına bir ç ok veriyi farklı formatlarda kaydediyor. Bunların hepsini a ç mak izlenebilirlik anlamında tabi ki ç ok anlamlı ancak işin performans ve veri maliyeti kısmını da g ö zetmek gerekiyor. Bu konunun uzmanı değilim ancak konunun uzmanlarından aldığım ç ok ç a bilgi ile şunu rahatlıkla ö nerebilirim sanırım;
Performans ve maliyet konularını düşünmeyin. Security Audit Log ’u aktifleştirin.
Peki Security Audit Log (SAL) neden bu kadar ö nemli ve ne olursa olsun hiç bir filtre konulmadan izlenmesi ö neriliyor ;
• Sisteme diyalog ve sistem kullanıcıları tarafından yapılan girişler
• RFC girişleri & Çalıştırılan RFC fonksiyonları
• İşlem kodlarına erişimler
• Programlara erişimler
• Kullanıcı ana verisi üzerinde yapı lan de ğişiklikler SAL üzerinden izlenebiliyor.
Takdir edersiniz ki sisteme kimin girip çıktığını bilmediğiniz, kullanıcı yetkilerindeki değişiklikleri izleyemediğimiz ve ç alıştırılan programların takibini yapamadığımız bir sistemde;
• Şüpheli kullanıcıların sistem aktiviteleri
• Entegrasyonlardan beklenmeyen program ve veri ç ağrıları
• Sistemden lokal cihazlara transfer edilen şüpheli dosyalar
• Debug kodu ile modifiye edilen tablolar ve Excel’e aktarılan dokümanlar
• SQL kodu i ç eren, ya da kritik verileri indiren programların ç alıştırılma kaydını da izleyemeyiz.
Bu verilerin takip edildiğini raporlayamayan bir kurum i ç in ise KVKK ve veri gizliliği ve güvenliği konusunda ge ç er not vermek bence fazla iyimser olur. Tabi bu konuyu sadece KVKK kapsamında ele almak ç ok primitif bir bakış açısı olacaktır. SAP sistemlerindeki verilerin kritikliği ve gizliliği baz alındığında hiç kuşkusuz kişisel verilerin en son sı rada kalaca ğı durumlar da olacaktır. Sıklıkla yazdığım ve s ö ylediğim gibi, KVKK d ö nüşümü veri mahremiyetinin ve gizliliğinin sağlanabilmesi i ç in bir fırsattır. Bu fırsat sayesinde kurumlar bu konuda bilin ç lenmekte, yazılım ekosistemi bu konuda ürünler geliştirerek gelişime ö n ayak olmaktadır.
İşin performans kısmına bakacak olursak, SAP’nin güvenlik kayıtlarını Kernel üzerinde tutması sebebiyle bu işlemin bir performans kaybına sebep olmayacağı bir ç ok SAP Note’ ta da a çıklanmış. İşin veri maliyeti tarafında ise ABAP-Experts ’in yaptığı bir ç alışmaya g ö re 10.000 kullanıcının olduğu bir SAP sisteminde SAL i ç in ihtiyacınız olan veri büyüklüğü 2TB.
Bırakın terabyte’ı gigabyte’ların bile altından değerli olduğu bir d ö nemden kalma şehir efsaneleri sebebiyle hala dünyadaki ç oğu SAP sisteminde SAL kullanımının ç ok büyük bir performans ve veri maliyeti oluşturduğuna dair ö nyargılar var.
SAL’ı hiç bir filtre a ç madan herkes i ç in her zaman a ç manız ö nerilmektedir.
(https://launchpad.support.sap.com/#/solutions/notesv2/?q=BC-SEC-SAL)
Yukarıdaki ö nerme ile ilgili benim uzmanlığımdan ö te daha profesyonel bir yazı i ç in buyurun: https://www.abap-experts.com/blog/item/15-blog-sal-2017-01
Peki SAL’ı herkes i ç in a ç mak yeterli mi ? Tabi ki hayır. SAL üzerinde neyi raporlayacağınızın bir envanterini çıkarmalısınız . Eğer yalnızca kritik ö nemdeki verileri izlemek isterseniz şu bilgileri kaçıracağınızı unutmamalısınız;
• RFC ile sistemden veri ç eken ya da injection yapan bir fonksiyon ç alıştırıldığında bunun farkına varmazsınız.
• Bir kullanıcı yaratılı p, suistimale a çık işlemler yapıldıktan sonra bu kullanıcı silinirse bu işlemin farkına varmazsınız.
• Direkt tablo erişimlerinin takibini yapamazsınız.
Daha fazlasının da mümkün olduğunu yazmama gerek yok sanırım.
Burada lafı çok uzatmadan şunu s ö yleyeyim; SAL’ı hiç bir filtre olmadan herkes i ç in a ç malı, ve sizin belirlediğiniz metriklerle sürekli olarak analiz etmelisiniz. SAP'nin kritik metrikleri ile sizin i ç in kritik seviyede ö nem arz eden metrikler aynı değildir.
1. Kişisel verilerin güncel envanterinin çıkarılması: Bir SAP sisteminde hangi kişisel verilerin tutulduğu, kullanıldığı, transfer edildiği bilgilerini harmanlayarak bir SAP kişisel veri envanteri çıkarmanı n d üşüncesi bile sizi KVKK uyumluluğu konusunda umutsuzluğ a d üşürebilir. Ancak durum o kadar da vahim değ il. Naç izane ö nerim, kişisel verilerin hangi iş süre ç lerinde kullanıldığını belirlemekle başlamalısınız. Unutmamak gerekir ki kişisel verilerin ç ok ö nemli bir b ö lümü personel, müşteri ve satıcı verilerinde tutulmaktadır. Ayrıca SAP’nin bu konuda muntazam bir veri mimarisi kullandığını s ö yleyebiliriz ki, bu sayede kişisel verileri ufak bir yardım* ile çıkarabilirsiniz diye düşünüyorum.
2. Kişisel verilerin ama ç larla eşleştirilmesi: SAP sistemini KVKK uyumlu hale getirmekten bağımsız olarak, hangi ama ç larla kişisel veri tuttuğunuzu belirlemelisiniz. Bir ö nceki yazımda bahsettiğim gibi, tutulan verinin kiracısı olduğunuzu ve bu veriler i ç in ilgili kişilere karşı sorumluluk taşıdığınızı unutmamalısınız. (Ama ç lara bir kaç örnek vermek gerekirse; ö zel sağlık sigortası i ç in medeni durum ve ç ocuk bilgisi, doğum günü hediyesi i ç in doğum tarihi, ramazan ayındaki hakların belirlenmesi i ç in din bilgisi olabilir mesela.) Bu ama ç ları belirledikten sonra ama ç larımızı ger ç ekleştirmek i ç in minimum kişisel verinin ne olduğunu belirlemeliyiz. Örneğ in, do ğum gününde birine hediye g ö ndermek i ç in medeni hal bilgisinim tutuyor olmanız sizin yetki minimizasyonu ilkesine uymadığınızın bir g ö stergesi olacaktır. Bu yüzden ama ç lar ve kişisel verilerin bir arada olduğu bilgi setlerini oluşturmalısınız. *
3. Açık Rızaların Y ö netimi: Sistemde kullanmayı planladığınız tüm verileri haklı sebepler olmaksızın anonimleştirmeden ya da gizlemeden kullanmak istiyorsanız kişilerin açık ve anlaşılabilir rızalarını almalısınız. Tabi bu bilgilerin etkin bir şekilde takip edilmesi gerekiyor. Bu kapsamda açık rızaların iki temel ö zelliğinden bahsetmek istiyorum;
• Rızalar belli ama ç lar i ç in alınmaktadır: Bir veri sahibinin doğum gününde hediye ç eki alımı i ç in doğum günü bilgisinin işlenmesi i ç in rıza vermesi, bu kişinin verilerini sigorta şirketlerine verebileceğiniz anlamına gelmemektedir.
• Rızalar belli bir d ö nem i ç in yapılmaktadır, verilen rızadan herhangi bir anda vazge ç ilebilir: Bu kapsamda rızaların güncel olarak takip edilmesi ve tüm SAP sistemlerindeki veri girişlerinde ö nce r ıza ge ç erlilik kontrolü yapılmalıdır. Açık rızanın bittiği ya da açık rızadan vazge ç ilen durumlarda veri g ö rüntüleme ve kullanma KVKK ihlali olacaktır.
4. Hibrit Yetki Y ö netimi: Art ı k ERP ’ler gibi yüksek hacimde veri tutan kompleks yapılar i ç in yetkilendirme mimarisinin ç ok daha dinamik olması gerekiyor. Dijital d ö nüşüm kapsamında bu güvenlik konuları biraz daha arka planda kalsa da yetkilendirmede de bir ‘’2.0’ ’ d ö nemi yaşayacağız. Mevcut teknolojide SAP’nin rol bazlı yetkilendirme (RBAC) yaklaşımını biraz daha nitelik bazlı yetkilendirme (ABAC) ara ç ları ile zenginleştirmek gerekiyor. Bu konuda apayrı bir yazı yazılabilir ancak, güzel bir karşılaştırma metnine buradan ulaşabilirsiniz:
Buraya girersem çıkamayacağımdan korkuyorum, dolayısıyla kısa tutacağım;
Sadece KVKK kapsamında değil, genel olarak SAP gibi kompleks yapılarda biraz daha detay bir yetkilendirme yaklaşımına ihtiyaç var.
Uygulamaların işlem kodu ya da uygulama bazında erişimlerini mevcut teknolojilerle zaten kontrol edebiliyoruz. Ayrı ca şu noktalarda yetkilendirme yaklaşımımızı geliştirmeliyiz:
• Prosedür bazında ger ç ek zamanlı yetkilendirme (Açık rıza kontrolü , ge ç erlilik kontrolü, amaca uygunluk kontrolü)
• Alan bazlı yetkilendirme (Doğum tarihini yetkilendirip, medeni durumu gizleme vb.)
5. Aktarımların Yetkilendirilmesi: SAP sistemlerinde KVKK uyumluluğunu sağlamak uygulama olarak ikiye ayrılıyor; SAP sistemleri ve SAP verisini tü keten d ış sistemler . Bu dış sistemler; SAP’nin BI sistemleri olabileceği gibi, farklı bir tedarik ç inin BI yazılımı, bir web-servis, farklı bir SAP sisteminin RFC bağlantısı ya da Excel dokümanı olabilir. Dinamik yetkilendirme ç alışmaları ile birlikte SAP sistemleri, dış sistemlerde de açık rı za, r ıza ge ç erliliği ve amaca uygunluk gibi filtrelerden ge ç erek sadece kullanılabilir veriyi aktarmalılar. Bunun i ç in kişisel veri envanterinde bulunan veri öğelerinin aktarıldığı tüm dış sistem ba ğlantılarının bağlantı tipi bazında envanterinin çıkarılması ve her bir bağlantının dinamik kontrollerden ge ç mesi sağlanmalıdır. Bu işlem i ç in;
• Dinamik yetkilendirme kurallarını g ö zeten Web-servisler,
• Download edilen verileri şifreleyen, işaretleyen ve verisini manipüle eden download y ö neticisi,
• BW ’a aktarılan verileri filtreleyen filtreler,
• SAP verilerini tü keten RFC ’ler i ç erisindeki verileri filtreleyen kontroller geliştirilmelidir.*
6. Verilerin Sürekli İzlenmesi & Denetim Bu yazının temeli, gizliliği izlenebilir bir SAP ortamı yaratmak. Dolayısıyla tüm bu konfigürasyonun izlenmesi ve raporlanması yapılan ç alışmanın anlam kazanması i ç in ç ok ama ç ok ö nemli.
Yine burada na ç izane ö nerim, SAP’nin sağladığı standart log ve raporların incelenmesi konusunu prosedürlerinize ekleyerek hiç bir zaman efektif olmayacak kontrollerle boğuşmayın.
SAP’nin SAL kayıtlarını ya da SUIM üzerinden yetki kullanımlarını raporlamak ç ok uzun süren ve tekrar eden işlemler olacağı i ç in bir süre sonra kullanılabilirliğini kaybedecektir. Dolayısıyla bu noktada BO üzerinde ya da farklı BI ara ç larında uygun performans metrikleri ile* (kritik RFC fonksiyonları, kritik yetkiler, debug işlemleri vb.) ama ç ları ve kullanımlarını raporlayan grafikler oluşturmak, KVKK uyumluluk eforlarını çok ama ç ok azaltacaktır.
Art ık toparlamam gerekecek sanırım. SAP sistemi nitelik ve mimarisi itibariyle bir ç ok bilgi sisteminden ayrışıyor. Ancak sistemin kompleks olması KVKK uyumluluğundan bağımsız olduğu anlamına gelmiyor tabi ki.
SAP sistemlerinin de KVKK uyumluluğu kapsamındaki piramidini tekrar hatırlatmakta fayda var. Sanırı m art ık daha anlaşılabilir bir şekil oldu;
Ayrıca konuyu KVKK zorunluluğu kapsamından çıkarıp hassas verilerin etkin y ö netimi ve dijital dünyanın hakettiği yetkilendirme mimarisine yaklaşma olarak algılamak motivasyonu arttıracaktır diye düşünüyorum.
Ayrıca yazının sonuna sakladığım ancak artık yüzleşmemiz gereken üç şeyden bahsedeceğim ki bu noktaya kadar sıkılmamış okurların akıllarında biraz daha yer edelim.
1. Türkiye’deki sistemler SAP güvenliği anlamında inanılmaz primitif kalıyor. Bu açıklar sürekli bir risk oluşturuyor ve her ge ç en g ün biraz daha büyük etkileri olan suistimallere davetiye çıkıyor.
2. SAP’deki yetki açıkları sebebiyle Türkiye’de ve dünyada suistimaller oluyor ve bu suistimaller sanılandan ç ok daha YAYGIN .
3. SAP sistemlerini denetlemek amacıyla dışarıdan alınan denetimler ve prosedürler ne yazık ki engelleyici olmaktan uzak. Kişisel fikrim, SAP ekranları ile 1 yıl civarı bile haşır neşir olan bir kimse, 2 saatlik bir eğitimden sonra power-user ya da key-user / danışman yetkileri ile Türkiye’deki SAP sistemlerinin hemen hepsinde veri suistimali ger ç ekleştirip izini kaybettirebilir.
* Bu yazının ana konusu olmasa da doküman i ç erisinde yıldızladığı m ad ımlar konusunda, geliştirmiş olduğumuz Data Access Manager ürü nü SAP sistemleri üzerinde KVKK yükümlülüklerinizi takip etmenize yardımcı olacaktır. Ü rün hakkında soru ya da ö nerileriniz olursa bize ulaşabilirsiniz.
Öne Çıkan Bloglar
Risk Yönetiminin Dijital Dönüşümü - Bölüm II
Risk yönetimini merkez alan ve organizasyonlarda risk temelli stratejik bir değer yaratmayı hedefleyen bir kurum...
İnsanın ve Kurumun Karar Verme Kabiliyeti ve Riski Yorumlayabilme Yeteneği Üzerine - Bölüm I
Zaten uzun süredir bir çok işçinin sıklıkla haşır neşir...
SAP’de GRC ve Yetki Yönetimi
SAP GRC (Governance, Risk, Compliance) Nedir dediğimizde bir çırpıda sıralayabileceğimiz uygulamaların sayısı bir hayli fazla...
4 Soruda SAP GRC
4 soru ile sizlere SAP GRC ve uygulama şeklini anlatıyoruz. Blogumuzu okuyarak SAP GRC hakkında daha fazla bilgiye sahip olabilirsiniz...