Rusya Ödeme Sistemi MIR Türkiye'de...

19 Mayıs 2019 Pazar

MIR Ödeme Sistemi operatörü NSPK (National Payment Card System) 2015'ten bu yana 3123 bankanın 160 değişik kart olarak 56 milyon kişi tarafından kullanılıyor. Ancak MIR diğer uluslararası kart ödeme sistemleri (UnionPay, JCB, Maestro ) ile uyumlu olmadığı için Rusya dışında kullanılamıyor. MIR kartlarının uluslararası kabulünü artırmak için çalışmalar sürdürülürken Türkiye sistemi kabul etmeye başlayan ilk ülke oldu. MIR kartlar, özellikle Rus turistler için çok önemli.

Rusya Ulusal Ödeme Kartları Sistemi  (MIR),  Türkiye İş Bankası'nın MIR kartlarıyla işleme Nisan ayı gibi başladı.

Şu anda Ziraat Bankası’nın POS ve ATM sertifikasyonu Banksoft tarafından yapılıyor. Sonrasında pilot testleri yapılacak ve prod yani saha kullanımı başlayacak.


Share/Bookmark

SQL Server 2017 Veri Güvenliği

Müşterilerimizin veya potansiyel müşterilerimizin verilerini gerek  6698 sayılı Kişisel Verilerin Korunması Kanunu düzenlemelerini göre dikkatlice korumamız gerekiyor.

Microsoft SQL Server ortamlarında aşağıdaki önlemler alınabilir:

1- Ortamları Ayırmak:
Canlı (live/prod), test ve  pre-prod/UAT şeklinde ortamlarınızı ayırın.

2- Görevler Ayrılığı İlkesi:

Veri tabanınıza giriş hakkının sadece ilgili kişilerde olmasını sağlayın.

3- Uygulama/test Kullanıcılara Sınırlama:

Uygulamalarımız için oluşturduğumuz ve adına uygulamal kullanıcı diyebileceğimiz kullanıcıları gerçek kullanıcılar kullanmamalı.

4- Anonim Kullanıcılar:

Birçok ortamda şirketteki tüm çalışanların "sa", "master", "admin" gibi anonim kullanıcıları mümkün olduğu kadar kullanılmamalı.  Veritabanına erişimi olacak çalışanlarına kendi kullanıcısının sorumluluğu anlatılmalıdır.

5- Sadece Gerektiği Kadar Yetki Verilmesi:

Bir yazılımcının temel ihtiyaçları SP/Function/Trigger yetkileri düzenlemeli. Ayrıca, aşağıdaki DML işlemleri (SELECT, INSERT, UPDATE,  DELET) için de yetkiler sınırlandırılmalıdır.

6-Veri Yedeklerken Güvenlik:
Mümkünse veritabanlarınızı şifreleyerek yedekleyin. Bunun için “Transparent Data Encryption” kullanabilirsiniz. Kötü niyetli kişiler bir şekilde yedek dosyalarınıza ele geçirse bile,  veritabanlarını açamazlar.

7-Veritabanı Sunucularına Hatalı Ve Başarılı Girişleri Denetleme:
Eğer veritabanı sunucunuza art arda erişilmeye çalışılıyorsa ve hatalar alınıyorsa ya bir veritabanınız herhangi bir sebeple erişilemez duruma gelmişse sunucunuza içeriden veya dışarıdan "brute force" yöntemiyle erişilmeye çalışılıyordur.

Sadece başarısız giriş denemelerini değil, başarılı girişleri de kontrol etmemiz gerekiyor, ki eğer bir çalışanın veya uygulama kullanıcısının bilgileri kötü niyetli birisinin eline geçerse ve veritabanına bağlanırsa  bilgisi olması gerekir.

8-  SQL Authentication değil, Windows Authentication Kullanın:
Microsoft'a göre SQL Authentication uzun süredir "Deprecated" bir özellik, yani bir süre sonra kaldırılacak;. Microsoft'un bu özelliği kaldırmak istemesinin nedeni de güvenlik.  Windows Authentication kullanmak gerekir.

9-Yerel Güvenlik Politikası Kullanma:
Hem yeni kullanıcılar oluştururken, hem de varolan kullanıcılarınız için Windows işletim seviyesindeki Yerel Güvenlik Politikalarından faydalanın. Bu sayede kullanıcılarınızın Login şifrelerinin belli bir uzunlukta ve zorlukta belirlenmesini sağlayabilirsiniz.


Share/Bookmark

Kitap Tavsiyesi: Körlük - Jose Saramago

Jose Saramago Nobel ödüllü bir yazar. Yazarın yazdığı en etkileyici kitaplardan biri. Konusu da çok ilginç:

Araba kullanmakta olan bir adam, yeşil ışığın yanmasını beklerken ansızın körleşiyor. Körlüğü, başvurduğu doktora da bulaşır.

Bu körlük, bir salgın hastalık gibi bütün kente yayılır. Toplum, görmeyen gözlerle cinayetlere, tecavüzlere tanık olur. Ayakta kalabilenler ancak güçlü olanlardır. Koca kentte körlükten kurtulan tek kişi, göz doktorunun karısıdır.


Share/Bookmark

Nisan 2019 Dergi Paketi

Toplam Boyut 11.94 GB. Link silinmeden indirin!!!

https://turbobit.net/2t28ksxw4aij/Nisan2019Dergiler.WT.rar.html


Share/Bookmark

SQL Server Performans Problemleri

17 Şubat 2019 Pazar

SQL Server’da  en korkulan performans problemleridir. SQL Server performansı denildiğinde ilk akla gelen şey, CPU ve Memory upgrade’nin yapılmasıdır. Genelde yazılım departmanları, SQL Server’a daha fazla CPU ve daha fazla memory verilmesini sistem ekiplerinden isterler. CPU ve memory ilave yapılan SQL Server’lar ilk başta biraz daha iyi gibi çalıştığı görülse de, aslında arka planda değişen hiçbir şey olmamıştır.

Bir SQL klasiği olan CPU ve memory arttırmak yerine, gerçekte SQL Server’ın performansını etkileyen unsurları incelemekte fayda var. İlk olarak SQL Server’a fazlasıyla donanım kaynağı (CPU, Ram) verdiniz, işletim sistemdeki performans ayalarını optimize ettiniz ve son olarak SQL Server’daki temel ayarları yaptığınız diyelim, bundan sonra performans için aşağıdakileri de incelememiz gerekir.

Hatalı indeksleme Problemi: SQL Server’ın en büyük performans problemlerinden biri, yetersiz ve hatalı indekslemedir. Bir sorgudaki indeksleme doğru yapılmadığında, SQL Server bu sorguyu çalıştırmak için, daha fazla data işlemek zorunda kalacak ve bu gereksiz yapılan işlemler, SQL Server’ın kurulu olduğu sunucu üzerinde, gereksiz şekilde CPU ve RAM tüketecektir.

CPU ve RAM’in gereksiz yere kullanılması ile birlikte, sorguların çalışma süreleri de paralel bir şekilde olumsuz etkilenecek, süreleri uzayan sorgular da, blockinglere ve deadlock’lara sebebiyet verecektir.

Blocking ve Deadlock’ların Çok Fazla Oluşması: Bir satırdaki veriyi, aynı anda güncellemek istediğinizde SQL Server buna izin vermez. Veri bütünlüğünü sağlamak için blocking mekanizmasını devreye sokar. Bu mekanizma veri sağlığı için gayet başarılı bir kurgudur. Fakat blockinglerin sürekli ve sık sık yaşanması, SQL Server’da yavaşlıklara neden olmaktadır. Sürekli yaşanan blockingler, bir sorun olduğunun göstergesidir. Deadlock’lar, ortak bir kaynağa erişmeye çalışan iki prosesin birbirini kilitlemesi ile başlayan, ardından query engine’nin en az maliyetli olan prosesi kill etmesiyle yani durdurmasıyla son bulan bir operasyondur. Bu kill edilen prosese deadlock victim denir.

Deadlockların genel olarak bir SQL Server temel sorunu olarak görülür. Veri bütünlüğü bir sorgunun çalışma zamanı; blocking ve deadlocklardan olumsuz bir şekilde etkilenebilir.

Hatalı İstatistikler (Statistics): SQL Server’ın performans hesaplama temelleri, maliyet bazlı optimizasyona dayanır. Verinin kullanımda en çok ihtiyaç duyulan indekslerdir. İndekslerin de etkili bir şekilde kullanılmasında da statisticslerin doğru yapılandırılması çok önemlidir.

Doğru statisticsler olmadığında, SQL Server sorgulardaki satır sayısı tahminlemesin de yanlış yapabilir. Satır sayısını tahminlemenin sorgu performansına etkisi ise, örnek olarak 10bin satır gelecek olan bir sorgunun, estimated row number değeri 1milyon olarak tahminlendiğin de, gereksiz yere IO kullanımı ortaya çıkacak ve sorgu sonucu uzun süren bir işleme girebilir.

Uygun Olmayan Sorgu Tasarımı: İndekslerin etkin bir biçimde kullanılması, SQL sorgularının yazım biçimiyle ilişkili bir yapısı vardır. Bir tabloda çok sayıda satırın döndüğü bir sonuç kümesini olması veya bir tablodan daha büyük bir sonuç döndüren bir filtre kriterini belirtilmesi durumlarında kullanılan indekslerde etkisiz kalabilmektedir.

Maliyet yani cost değerlerine dikkat edilmeden yazılan SQL sorguları, optimizer’ın uygun indeksleri seçmesini engellemektedir, bunun sonucunda da sorgu çalışma zamanlarının uzaması ve blockinglerin artmasına sebep olabilir.

Doğru Set Edilmemiş SQL Operatörleri: Transact SQL dili veri kümeleri üzerinde çalışan bir sorgulama dilidir. Bunun anlamı, satır olarak düşündüğünüz bir yazılım dilinin, kolonlar bazında yani veri alanları açısından düşünmeniz gerektiğidir. T-SQL kodlarını yazarken de, düz yazı gibi yazmak yerine kümelenmiş verilerin kolonlar bazında sorgulanmasını düşünerek olur.

Cursor kullanımları ve gereksiz döngüler kullanıldığında, subquery’lerde ve join’lerdeki döngüyü gözden kaçırmanıza neden olabilir. Özellikle cursor kullanımı için performans killer tabirini kullanmak yerinde olur. Cursor yerine while operatörünü kullanmak ve sorgularınızı while döngüsü ile optimize edilmesi daha iyi olacaktır.

Sıkça yapılan SELECT * kullanımları da gereksiz IO tüketimlerine sebep olacaktır, * yerine ne kadar alan sorgulanmak isteniyor ise bu alanların isimleri üşenmeden yazılmalıdır.

Uygun Olmayan Veritabanı Tasarımı: Veritabanı tasarımları genellikle yazılımı yazanlar tarafından veya yazılım yazımında kullanılan hazır frameworkler tarafından otomatik olarak yapılıyor. Özellikle hızlı ve pratik kod yazmak için, son zamanlarda bu tarz yapıların kullanımı artmaktadır.

Veritabanı tasarlarken ilk dikkat edilmesi gereken nokta, veri işleme manipülasyon ve blockinglerin olmaması için, tablo tasarımlarının optimize şekilde olması gerekiyor.

Optimize bir veritabanı nasıl tasarlanmalı konusu için, bir örnek üzerinden gidelim. Müşteri adresi ve müşteri kart bilgileri bizim verilerimiz olsun. İşin kolayına kaçarak, müşteri adresi ve müşteri kart bilgileri tek tablo üzerinde tutarsanız eğer, verileriniz büyüdükçe, bir müşteri adresini ararken aynı zamanda gereksiz olarak müşteri kart bilgileri içinde kaynak harcayacaksınız. Her veriyi tek tablo üzerinde tuttuğunuz da ise zamanla blockingler çoğalacak ve veritabanınız içinden çıkılmayacak bir hale dönüşecektir.


Share/Bookmark

3D Secure 2.0'a Geçiş Ne Kadar Gerekli?

Daha önceki yazımda (Aşağıdaki linkden ulaşabilirsiniz),

http://ercumentyenikaya.blogspot.com/2017/08/3d-secure-20-hakknda.html

Visa ve MC'nin 2017’de duyurduğu, 3D Secure 2.0 Nisan ve Mayıs 2019  gibi bankalarda devreye alınmaya hazırlanıyor. Tabii ki test ve sertifikasyon süreçleri var. Bankalara toplantı için mail gönderildi.

3D Secure 2.0 ile işlem sürelerinin aşağıya çekilmesi ve işlem tamamlanma oranlarını yükseltme hedefleniyor. Bu konuda Visa’nın paylaştığı rakamlar, her 100 işlemden en az 95’inin kimlik doğrulamaya ihtiyaç duymadan işleme devam edeceği, %85 oranında ödeme sürecinin kısalacağı ve %70 oranında işlem terk etmenin azalacağı yönündedir. Aynı zamanda mobil ve digital cüzdan da destekleniyor.

3D Secure 1.0’dan Beklentiler Neydi?:

Kart sahiplerinin kimlik doğrulama süreci ile dolandırıcılık ve chargeback oranlarında azalma İşlem sayılarında ve cirolarında artış Farklı doğrulama teknolojilerine destek (Şifre Sorgulama, Chip Kartlar, Biometrik Kontrol). İnternet erişiminde kullanılan farklı uygulamalara destek (PC, Mobil Telefon, PDA, TV).

3D Secure 1.0’ın Temel Problemleri:

Uzun işlem akışı nedeniyle düşük conversion’a neden olması standart web browser üzerinden çalışması nedeniyle app, mobil ve digital cüzdanı desteklememesi. Sadece şifre ile kimlik doğrulama yapabilmesi ve her işlemde zorunlu olarak bu doğrulamayı istemesi, doğrulama ekranlarının non-responsive olması nedeniyle tablet ve akıllı telefonlarda kullanım zorluğuolmasıydı.

Bu problemlerden dolayı, bazı beklentileri tam anlamıyla karşılayamaması ve mevcut temel sıkıntılar nedeniyle 3D Secure 2.0‘a geçiş kaçınılmaz oldu.

3-D Secure 2.0’da Bulunan Akış:

-Kart bilgileri işyerinin ödeme sayfasına girilecek ve 3D Secure ödeme yöntemi seçilecek. 

-İşyeri bankası, kart bilgileri ve işlem datasını otorizasyon talebi içinde kart bankasına gönderecek.   

-Kart bankası işlem riskini kendisine ulaşan verilere dayanarak belirleyecek/ölçecek. Eğer işlemi riskli bulursa, kimlik doğrulama talep edecek. İşlemi düşük riskli bulursa herhangi bir ekstra kimlik doğrulama talep etmeyecek. Ve buna göre otorizasyon cevabını dönecek.

-İşyeri bankası, kimlik doğrulama sonucu ile birlikte dönen otorizasyon cevabına göre işlemi tamamlayacak.


Share/Bookmark

SQL Server SP (Store Procedure) Versiyonlama

SQL Server’da genel de kullanılmayan güzel özelliklerden biri olan Stored Procedure ( Saklı Yordamlar) versiyonlamadan bahsediyor olacağım.

Bu özelliği mevcut SP’leri revize ederken ya da değiştireceğiniz zaman yeni bir isimde oluşturmak yerine versiyonlayıp kullanabilirsiniz.

Aşağıda yer alan “Create Procedure” içeriğini inceleyecek olursanız syntax bölümünde “; numara” ile yazan kısım var. Kullanımı aslında gayet basit olmakla beraber aynı isimdeki Stored Procedure’leri gruplamak için kullanılması ve versiyonlamasını göstermektedir.

Bir Örnek ile inceleyelim. Yeni bir sp oluşturuyoruz:

CREATE PROCEDURE dbo.DenemeKayitGetir as
select ‘YeniSP’ as Baslik

Aynı sp’yi “; numara” ifadesi ile versiyonluyoruz.

CREATE PROCEDURE dbo.DenemeKayitGetir ;2
as
select ‘YeniSP_New’ as Baslik


Share/Bookmark