TÜRKİYE DEĞERLEME UZMANLARI BİRLİĞİ
TÜRKİYE DEĞERLEME UZMANLARI BİRLİĞİ
TAPU BİLGİLERİ ARAŞTIRMASI (TABA) BİLGİ SİSTEMİ
GELİŞTİRME VE DESTEK HİZMETLERİ SATIN ALMA
TEKNİK ŞARTNAMESİ
İSTEKLİ tarafından verilecek teklifde Teknik Şartların’nin bütün maddeleri, sıra ile ve madde numaralarına göre cevaplandıracaktır. Eksik veya muğlâk verilen cevaplar teklifin değerlendirme dışı bırakılmasına sebep olabilecektir.
1 İşin Tanımı, Kapsamı ve Süresi
Temin edilecek hizmet, TDUB ihtiyaçları doğrultusunda TDUB üyelerine yönelik, TAKBİS sistemi üzerinde temel bilgiler, mülkiyet ve kısıtlar hakkında araştırma yapılabilmesi ve hazırlanacak değerleme raporlarına ulusal düzeyde tekil bir rapor numarası verilmesini sağlayacak bir bilgi sisteminin yazılımların geliştirilmesi,
güncellenmesi, bakımı, işletimi, sunucularının yönetimi için gerekli desteklerinin verilmesi, kullanıcılara yönelik yardım belgelerinin hazırlanması, bilgi sisteminin yönetecek TDUB personelinin eğitim verilmesi ve bu personele destek verilmesi ve sistemin bir bütün olarak sürdürülebilirliğinin sağlanmasına yönelik çalışmalar doğrultusunda, sözleşme süresince “Yazılım Geliştirme, Sisteminin İşletimi ” işini kapsamaktadır.
2 Kısaltmalar ve Tanımlar
2.1 Kısaltmalar
PROJE: “TABA - Tapu Bilgileri Araştırması” Bilgi Sistemi Projesi SİSTEM: Tapu Bilgileri Araştırması (TABA) Bilgi Sistemi
ÜRÜN: Tapu Bilgileri Araştırması (TABA) Bilgi Sistemini oluşturan tüm bileşenler (yazılım kodları, belgeler, ilişkili hizmetler vb.)
BELGE: Tapu Bilgileri Araştırması (TABA) Bilgi Sistemi Proje Analiz Belgesi TDUB: Türkiye Değerleme Uzmanları Birliği
İŞLETME: Türkiye Değerleme Uzmanları Birliği İktisadi İşletme
İSTEKLİ: “TABA - Tapu Bilgileri Araştırması” Bilgi Sistemi Projesi yazılımlarını geliştirmeye istekli yazılım geliştirme YÜKLENİCİsı
YÜKLENİCİ: “TABA - Tapu Bilgileri Araştırması” Bilgi Sistemi Projesi yazılımlarını geliştirmek üzere TDUB tarafından hizmet alımı kararı verilerek sözleşme imzalana yazılım geliştirme YÜKLENİCİsı
TKGM: Tapu ve Kadastro Genel Müdürlüğü TAKBİS: Tapu ve Kadastro Bilgi Sistemi
TAKPAS: TKGM Tapu ve Kadastro Paylaşım Sistemi
TAKPAS2: TKGM Tapu ve Kadastro Paylaşım Sistemi (Sürüm No: 2)
TARA: “TABA - Tapu Bilgileri Araştırması” Bilgi Sistemi Projesi TAKBİS Araştırma Uygulaması
URAN: “TABA - Tapu Bilgileri Araştırması” Bilgi Sistemi Projesi Ulusal Rapor Numarası Uygulaması SPK: Sermaye Piyasası Kurulu
BTK: Bilgi Teknolojileri ve İletişim Kurumu Başkanlığı
2.2 Tanımlar
Veri Merkezi: TDUB tarafından belirlenen SİSTEM sunucularının barındırıldığı ülke içinde yerleşik ve BTK denetimindeki tesis
Erişim Sağlayıcı: TDUB tarafından belirlenen SİSTEM sunucularının internet erişimini sağlayan BTK denetimindeki İnternet Servis Sağlayıcı
Değerleme Kuruluşu: Seri VIII, No: 35 sayılı Sermaye Piyasası Mevzuatı çerçevesinde gayrimenkul değerleme hizmeti verecek şirketler
Değerleme Uzmanı: Gayrimenkul ve/veya menkul kıymetlerin değerini tespit etme konusunda hizmet veren gerçek kişiler
Denetmen: Gayrimenkul ve/veya menkul kıymetlerin değerini tespit etme konusunda hizmet veren ve/veya Değerleme Uzmanı tarafından gerçekleştirilen hizmeti değerlendiren deneyimli gerçek kişiler
Sorumlu Değerleme Uzmanı: Değerleme kuruluşu ortağı ve değerleme uzmanı olan imza yetkisine sahip gerçek kişiler
Üye: TDUB üyesi değerleme uzmanı veya değerleme kuruşu Kullanıcı: SİSTEM’de işlem yapmaya yetkili gerçek kişi
API: (An application programming interface (API)) Uygulama programlama arayüzü, bir yazılımın başka bir yazılımda tanımlanmış işlevlerini kullanabilmesi için oluşturulmuş bir tanım bütünüdür.
3 Sorumluluklar
3.1 TDUB’nin Sorumlulukları
1. YÜKLENİCİ’nin projeyi gerçekleştirmek için ihtiyaç duyduğu dokümanları ve sözleşme ile tanımlanmış bilgi, belge ve kaynakları, özellikleri belirlenmiş standart sunucu donanımları, altyapı ve bileşenleri sağlayacaktır.
2. PROJE kapsamında geliştirilecek tüm yazılımlar, TDUB tarafından belirlenecek Veri Merkezinde çalışır olarak teslim edilecek Ek 1 Donanım Listesi’de detayları belirtilen donanım ile uyumlu olacaktır.
3. YÜKLENİCİ ile koordineli olarak çalışacak Ek 2’de detayları belirtilen proje ekibini sağlayacaktır.
4. PROJE kapsamında, YÜKLENİCİ tarafından atanan proje yöneticisine sorumluluk ve yetki açısından
denk, YÜKLENİCİ proje yöneticisine istediği raporları sunacak, proje yönetimini TDUB tarafında yapacak tam yetkili bir proje yöneticisi atayacaktır.
5. Sözleşmeye göre yükümlülüğü altında olan işler için gerekli kaynakları sağlayarak belirlenmiş görevleri takvime uygun olarak gerçekleştirecektir.
6. YÜKLENİCİ’nın bildirmiş olduğu ve YÜKLENİCİ’nin işbu şartname kapsamında sağlamakla yükümlü olmadığı tüm altyapı sistem ve gereksinimlerin tesisini, yönetilmesini sağlayacaktır.
7. Kabul süreçlerine katılacaktır.
8. YÜKLENİCİ ekibinin TDUB ve Veri Merkezi ofislerinde mesai saatleri içerisinde veya dışında uygun
çalışma zamanlarında çalışmasına imkan sağlayacak ve gerektiğinde YÜKLENİCİ uzmanlarına nezaret edecektir.
9. Şartnamede belirlenen süreler içinde sağlaması gereken bilgi ve dokümanları YÜKLENİCİ’ye iletecek, bunlarla ilgili kararları proje takviminde belirlenen süreler içinde alacaktır.
10. YÜKLENİCİ’nin düzenleyeceği eğitimlere işin takvimini aksatmayacak şekilde katılımı sağlayacaktır.
11. TDUB, satın alacağı uygulama yazılımının analiz sonrasında TDUB ihtiyaçları doğrultusunda geliştirilen tüm kaynak kodlarının (store procedur, back end framework ve front end framework vb.) kullanım haklarına sahip olacak, yapılacak sözleşme süresince yazılım bakım ve geliştirme hizmetleri sadece YÜKLENİCİ tarafından sağlanacaktır.
12. İşbu Teknik Şartlar bölümünde ile tanımlanan tüm yükümlülükleri yerine getirecektir.
3.2 YÜKLENİCİ’nin Sorumlulukları
1. Veri aktarımları, geçiş, teslimat, kurulum, entegrasyon desteği ve eğitimler ile diğer hizmetleri, sözleşmede tanımlanmış koşullara uygun ve zamanında tamamlayacaktır.
2. YÜKLENİCİ, TDUB tarafından belirlenecek Veri Merkezinde çalışır olarak teslim edilecek donanım ilgili hangi donanım üzerinde hangi işletim sistemi, hangi sunucu servisini tercih ettiğini teklifinde belirtmelidir. Tercih ettiği işletim sistemi, sunucu servisi veya ek diğer lisanslama ihtiyaçları (lisanslama yöntemi, lisanslama süresi, kısıtlar vb) ve bunların maliyetleri hakkında teklifinde detaylı bilgi vermelidir.
3. YÜKLENİCİ, TDUB’un bu belge kapsamında istediği herhangi bir özellik için ilave bir donanım veya yazılım gerekmesi halinde, teklifinde bu hususu belirtmelidir.
4. YÜKLENİCİ, TDUB tarafından talep edilmesi durumunda PROJE çalışmalarına TDUB ve Veri Merkezi ofislerinde katılacaktır.
5. PROJENİN başarılı olarak yürütülmesi için yetkin ve yeterli personellerden oluşan ekip üyelerini atayacak ve ihtiyaç duyulan her türlü uygun kaynağı zamanında sağlayacaktır.
6. Yapılacak tüm çalışmalar YÜKLENİCİ’nin hazırlayacağı bir proje yönetimi çerçevesinde, TDUB tarafından onaylanarak yürütülecektir. YÜKLENİCİ, onaylanmış çalışma programına aynen uymak zorundadır.
Ancak zorunlu hallerde TDUB’un oluru ile çalışma programında değişiklikler yapılabilecektir.
7. PROJE kapsamında, TDUB tarafından atanan proje yöneticisine sorumluluk ve yetki açısından denk, TDUB proje yöneticisine istediği raporları sunacak, proje yönetimini YÜKLENİCİ tarafında yapacak tam yetkili bir proje yöneticisi atayacaktır.
8. TDUB ile PROJE kapsamında paylaşılacak bilgilerin güvenliğini sağlamak üzere gizlilik anlaşmasını/taahhütnamesini imzalayacak ve gereklerine uyacaktır.
9. ÜRÜN tanımları içinde geçen ve teklifte belirtilen tüm özelliklerin tamamlanmasını sağlayacaktır.
10. PROJE’nin yaygınlaştırılması esnasında gerekli olacak kurulum ve destek planını hazırlayacaktır.
11. İşbu BELGE’nin Teknik Şartlar bölümünde belirtilen dokümanları zamanında sağlayacaktır.
12. Kesin Kabul şartlarını eksiksiz yerine getirecektir.
13. Sözleşme süresince bakım ve destek hizmetlerini yerine getirecektir.
14. TDUB’nin teknik uzmanlarına sistem yönetimine ilişkin teknik eğitim verecektir.
15. PROJE dokümantasyonlarını kabul yapılmadan önce belirlenecek standartlara uygun olarak hazırlayacaktır.
16. Teklifte verilen proje planının sözleşme imzasına kadar karşılıklı mutabakat ile güncellenmesini sağlayacak ve TDUB’ne onaylatacaktır.
17. PROJE kapsamında, problemler, yeni istekler, analiz, geliştirme, test ve kurulum faaliyetlerinin özetlendiği raporları aylık olarak TDUB’ne gönderecektir.
18. PROJE kapsamında, ÜRÜN’ün performans analizini ve veri tabanı bakımını yaparak, gerekli ise kapasite artırımı incelemelerini aylık rapor şeklinde TDUB’ne iletecektir. Gerektiğinde gerçek ortam
sunucularına erişim sağlanacak ve karşılıklı teknik iletişim sorumlusu atanacaktır. Her türlü erişim,
güncelleme, değişiklik TDUB’nin onay mekanizması içinde onaylandıktan sonra gerçekleştirilecektir.
19. ÜRÜN’ün parçasını oluşturan bileşenlerin, işletim sistemi sürüm değişikliklerinde, veri tabanı taşınması veya her türlü değişikliklerde, geliştirme ve test faaliyetlerini tamamlayarak sorunsuz bir şekilde geçiş faaliyetlerini tamamlayacaktır.
20. TDUB’nin performans (görüntüleme, sorgulama vb.), güvenlik, daha iyi hizmet veya diğer zaruri nedenlerden dolayı alternatif işletim sistemlerini ve platformlarını tercih etmesi durumunda, gerekli çalışmaları yapacaktır.
21. Beklenmedik durumlarda, iş sürekliliğinin sağlanması için, uygulamanın, veri tabanının
yedeklenmesinde gerekli çalışmaları yapacaktır. YÜKLENİCİ yedekleme ve acil kurtarma gibi durumlar için alternatifli yöntemleri ve bunlarla ilgili iş akışlarını TDUB’ne bildirecek ve bu yöntemler tercih edilmese dahi her aşamada destek verecektir.
22. YÜKLENİCİ her türlü veri güncelleme işlerini yerine getirecektir. Xxxxxx yapılması gereken her tür veri güncellemeleri YÜKLENİCİ’nin yükümlülüğünde değildir.
23. YÜKLENİCİ sözleşme süresince yazılım bakım ve ortaya çıkacak yeni istekler hakkında geliştirme hizmetlerini hangi koşulda vereceğini teklifinde belirtmelidir.
24. YÜKLENİCİ, açıklama yapması gereken özellik, yapı, topoloji vb herhangi bir bilgiyi vereceği cevabına ekleyecektir.
25. Kaynak kodları, üzerinde izahatlar bulunacak şekilde elektronik ortamdan bir taşınabilir medya üzerine yazılı halde YÜKLENİCİ ve TDUB tarafından ortak erişilebilen bir kiralık kasada saklanacaktır. TDUB, YÜKLENİCİ’nin ticari faaliyetini sonlandırması durumunda kodlara erişim ve değişiklik hakkında sahip olacaktır. İSTEKLİ bu madde ile ilgili beyan edeceği koşulları detaylandırmalıdır.
26. YÜKLENİCİ, tarafından hazırlanacak arayüz, belge gibi kullanıcıya sunulacak her tür ÜRÜN bileşeni Türkçe olacaktır.
27. İşbu Teknik Şartlar bölümünde ile tanımlanan tüm yükümlülükleri yerine getirecektir.
4 Bilgi Sistem Yazılım Uygulamaları
TABA bileşeni yazılım uygulamaları aşağıda gösterilmiştir. Uygulamalar dahil oldukları grubuna göre renklendirilmiştir.
• Gri Yetki kontrolü olmayan ama ek doğrulama gerektiren uygulamaları
• Xxxx Xxxxx, Yetki kontrolü olan ve Yöneticiler için ara yüz uygulamalarını
• Koyu Yeşil, Yetki kontrolü olan ara yüz uygulamalarını
• Mavi, API uygulamalarını
Şekil 1 TABA Uygulamaları
Kısa Adı | URL | Açıklama |
BELGE | xxxxx.xxxx.xxx.xx | Tapu Bilgileri Araştırma Raporu ve Ulusal Rapor Numarası doğrulama sayfası |
TABA | xxxx.xxxx.xxx.xx | TDUB yönetici ve çalışanları için TABA Yönetim Uygulaması |
TARA-WEB | xxxx.xxxx.xxx.xx | Değerleme Uzmanları için TAKBİS Araştırma Uygulaması Web ara yüzü |
URAN-WEB | xxxx.xxxx.xxx.xx | Değerleme Kuruluşları için Ulusal Rapor Numarası Tahsis Uygulaması Web ara yüzü |
TARA-API | xxx.xxxx.xxx.xx/xxxx | Değerleme Kuruluşları için TAKBİS Araştırma Uygulaması API web servisleri |
URAN-API | xxx.xxxx.xxx.xx/xxxx | Değerleme Kuruluşları Ulusal Rapor Numarası Tahsis Uygulaması API web servisleri |
5 Altyapı – Sistem Altyapısı
5.1 Ortamlar
Bilgi sistemi aşağıdaki ortamlarda çalışıyor olacaktır. DEV: Geliştirme Ortamı (Yüklenici Tarafında olabilir)
UAT: Kullanıcı Testi Ortamı (Veri Merkezinde, fiziki veya sanal sunucular üzerinde olabilir) PROD: Canlı Ortam (Veri Merkezinde)
ODM: Olağan Üstü Durum Merkezi Canlı Ortam (DETAY ANALİZDE değerlendirilecektir)
PROD ortamı aşağıdaki Fiziki ve Sanal Sunucu bileşenlerinden oluşmalıdır. İlgili sunucu özellikleri günde en fazla
20.000 değerleme raporu ve 30.000 gayrimenkul için araştırma yapılacağı varsayılarak öngörülmüştür. NAS
cihazları için kullanım tahmini halen “Tapu Sicil Örneği” olarak isimlendirilen pdf dosyaların arşivlenmesine göre hesaplanmıştır. (Proje fotoğraflarının arşivlenmeyeceği varsayılmıştır.)
Ortamlara erişim için VPN vb. yöntemler ve yetkilendirme konuları DETAY ANALİZDE değerlendirilecektir. Yüklenici teklifinde; Ortamlara özgü beklentilerini belirtmelidir.
5.2 Sunucular ve Ağ Topolojisi
Sunuculara ilişkin öngörülen temel donanım özellikleri aşağıda belirtilmiştir. Sunucuların tedariki, barındırılması ve internet erişimlerinin sağlanması TDUB tarafından sağlanacaktır. Yüklenici sunucuların işletim sistemlerin ve servis hizmetlerine ilişkin sunucu yazılımlarının kurulumu yapacaktır. Kurulum sonrası tüm sunucuların işletimi yüklenici tarafından sağlanacaktır.
Tablo 1 Sunucular (PROD Ortamı için Öngörülen Sunucu Kaynakları)
Sunucu – Ağ Bileşen Adı | Görevi | Donanım Bilgisi ve Açıklama |
FW | Güvenlik Duvarı | Yönetimi Veri Merkezi işleticisi şirket tarafından yapılmalıdır. |
LB01 – Yük Dengeleyici 1 | Dış kullanıcılar için trafik yük dengeleme | 1U, 8C CPU, 8GB RAM, 500 GB RAID1 HDD |
LB02 – Yük Dengeleyici 2 | Dış kullanıcılar için trafik yük dengeleme | 1U, 8C CPU, 8GB RAM, 500 GB RAID1 HDD |
APP01 – Uygulama Sunucusu 1 | Ana Uygulama Web Sunucusu | 1U, 16C CPU, 32GB RAM, 300 GB RAID5 HDD |
APP02 – Uygulama Sunucusu 2 | Xxx Xxxxxxma Web Sunucusu | 1U, 16C CPU, 32GB RAM, 300 GB RAID5 HDD |
CDN01 – CDN İçerik Sunucusu 1 | Resim Dosyası ve Statik İçerik Web Sunucusu | 2U, 8C CPU, 96GB RAM, 146 GB RAID1 HDD |
CDN02 – CDN İçerik Sunucusu 2 | Resim Dosyası ve Statik İçerik Web Sunucusu | 2U, 8C CPU, 96GB RAM, 146 GB RAID1 HDD |
DB01 – Veritabanı Sunucusu 1 | Ana Veritabanı Sunucusu | 2U, 40C CPU, 128GB RAM, 600 GB RAID5 HDD |
DB02 – Veritabanı Sunucusu 2 | Ana Veritabanı Sunucusu | 2U, 40C CPU, 128GB RAM, 600 GB RAID5 HDD |
DB03 – Veritabanı Sunucusu 3 | Ana Veritabanı Sunucusu | 2U, 40C CPU, 128GB RAM, 600 GB RAID5 HDD |
NAS01 – Dosya Sunucusu 1 | Ana Dosya Sunucusu | NAS xU, 8C CPU, 8GB RAM, 24 TB RAID5 HDD |
NAS02 – Dosya Sunucusu 2 | Ana Dosya Sunucusu | NAS xU, 8C CPU, 8GB RAM, 24 TB RAID5 HDD |
DNS, MAIL, ve LOG konuları ayrıca DETAY ANALİZDE değerlendirilecektir.
Yüklenici teklifinde; İhtiyaç duyacağı işletim sistemi, servis sunucusu, anti virüs, 3 parti eklenti vb. lisans maliyetlerini belirtmelidir.
Tablo 2 Temel Ağ Tanımları
Ağ Tanımı | IP Tanımı | Kaynak | Hedef |
Dış Ağ | Kullanıcı | FW | |
1. İç Ağ | FW (Güvenlik Duvarı) | LB (Yük Dengeleyici) | |
2. İç Ağ | LB (Yük Dengeleyici) | APP (Uygulama Sunucuları) ve CDN Sunucu | |
3. İç Ağ | APP (Uygulama Sunucuları) | DB (Veritabanı Sunucuları) ve Web Servislere ait Gatewayler | |
4. İç Ağ | APP (Uygulama Sunucuları) | NAS (Dosya Sunucuları) |
Her bir katman kendine ait bir ağ tanımı üzerinde olacaktır
Yüklenici teklifinde; Sistemin çalışacağı ortamlar ile ilgili geliştireceği sistem bileşenlerini nasıl konumlanacağını, sistem yapılandırma kapsamında servis (web, veritabanı, dosya, e-posta vb.) yapılandırma ve erişimleri ile ilgili beklentilerini iletmelidir. Ayrıca öngördüğü kısıtlamaları paylaşmalıdır.
Tablo 3 Ağ Katmanları
Katman Adı | Açıklama |
Internet | WEB Arayüz kullanıcıları için |
Internet (IP Kısıtlı) | Değerleme Kuruluşları için API erişimi |
Güvenlik | Güvenlik Duvarı ve DDoS |
Yük Dengeleme | Yük Xxxxxleme |
Çekirdek | Uygulama Sunucular |
Veri | Veri Tabanı Sunucuları, NAS Sunucuları |
Entegrasyon | Dış Entegrasyon Servisleri |
Şekil 2 Ağ ve Sunucu Topolojisi
Yüklenici teklifinde; Sistemin ölçeklenebilirliği sadece donanım yatırımı ile değil mimari ve yazılım mühendisliği ile de sağlanacak şekilde zaman içinde iyileştirilmeye gerek gördüğü noktaları belirtmelidir.
5.3 Uygulama Grupları – Sistem Uygulama Grupları
Sistem dört grup uygulamaya sahip olacaktır. Bunlar; temelde standart bir bilgi sistemi için de geçerli olan “Kullanıcı Ara Yüzler Grubu”, “Yönetici Ara Yüzü” ve “İş Grubu” uygulama gruplarına ek olarak entegrasyon yeteneği olan uygulamaların yer aldığı “API Grubu” (Uygulama İletişim Ara Yüzleri) şeklindedir. Her bir
uygulama grubu aslında bir alt sistem olarak değerlendirilmelidir. Uygulama grupları sistem sınırları içinde birbirleriyle etkileşimli olarak çalışırlar.
Kullanıcı Ara Yüzleri Grubu: Bu grup, Sadece gerçek insanlar tarafından oluşan kullanıcılara hizmet veren web ve mobil uygulamaları içermektedir. Hem kullanıcı doğrulaması gereken hem de gerekmeyen tüm uygulamalar bu kapsamdadır. Sistem içinde bir Ara Yüzler Gurubu uygulamaları tek başlarına veri tabanı işlemi yapamaz sadece API veya İş gruplarındaki uygulamaları çağırabilirler.
Yönetici Ara Yüzlü: Bu grupta sadece TABA Yönetici Ara yüzü uygulaması yer almaktadır. TABA Yönetici Ara Yüzü, diğer arayüz ve api uygulamalarının parametre, kullanıcı vb. bilgilerinin yönetimini ve diğer uygulamaların izlenme işlemlerinin yapıldığı uygulamadır.
API Grubu: Bu grup, Sadece bir başka uygulama tarafından kullanılacak ve bu uygulamalara hizmet verecek veya hizmet alacak web servis uygulamaları içermektedir. “API Grubu” uygulamaları hem sistem içi hem de sistem dışı bir başka uygulamaya hizmet verebilir. “API Grubu” uygulamaları veri tabanı işlemi yapabilir.
Sistem İş Grubu: Bu grup, Periyodik veya isteğe göre planlanmış ve sadece veri hazırlama, veri dönüşüm, raporlama, toplu işlem gibi sunucu üzerinde çalışarak çıktılarını yine sistem içinde bir başka uygulamanın kullanımına hazır eden uygulamaları içermektedir. “İş Grubu” uygulamaları veri tabanı işlemi yapabilir.
Tablo 4 Uygulama Grupları İlişkileri
Ara Yüzler | API | Sistem İş Grubu |
TARA – Değerleme Kuruluşu çalışanı için Kullanıcı Ara Yüzü | TARA – Değerleme Kuruluşu API | TAKBİS TAKPAS2 Entegrasyonu E-Fatura Entegrasyonu Zamanlanmış Görevler Bildirim Yönetimi |
URAN - Değerleme Kuruluşu çalışanı için Kullanıcı Ara Yüzü | URAN - Değerleme Kuruluşu API | Zamanlanmış Görevler Bildirim Yönetimi |
TAB – Yönetici Ara Yüzü | TAKBİS TAKPAS2 Entegrasyonu E-Fatura Entegrasyonu Zamanlanmış Görevler Bildirim Yönetimi |
5.4 Teknolojiler – Kullanılacak Teknolojiler
Sistemde ara yüzler için istemci tarafında çalışan HTML5, CSS3, JS bileşenlerine sahip front-end framework kullanılmalıdır. Sunucu tarafında yaygın kullanılan bir yazılım diliyle hazırlanmış back-end framework
kullanılmalıdır. Veri tabanı erişimi olarak procedur kullanılmalıdır.
Yüklenici teklifinde; Sistemde kullanılacak frameworkler, yazılım dilleri, veritabanları, araçlar, servis mimarileri ve diğer tüm teknolojiler teklifle birlikte detaylandırılmalıdır.
5.5 Ara Yüzler –Kullanıcı Ara Yüzleri
Kullanıcı ara yüzleri sadece kullanıcın yetkisi dahilindeki içeriklerin gösterimini gerçekleştirirken tüm alt
sayfalarının sade ve anlaşılabilir olmasına dikkat edilmelidir. Arayüz temel görsel tasarım prensipleri göz önünde bulundurularak tasarlanmalı, arayüzümn tamamında içerik ve öğelerin yerleşimi açısından tutarlılık sağlanmalıdır. Arayüz başlık ve alt bilgi bölümlerinin yanı sıra ana ve diğer menüler, web formlar ve içerik
gösterilen diğer sayfalar oluşturulurken, kullanıcıların aradıkları bilgiye hızlı ve kolay bir şekilde ulaşabilecekleri yapılar tercih edilmelidir. Bu çerçevede Web Kullanıcı Arayüzü TS EN ISO 9241-151 standardınai uyumlu biçimde aşağıdaki tasarım öğelerine dikkat edilmelidir.
• İçeriğin Organizasyonu (TS EN ISO 9241-151 | 7.1.2)
• Sayfalardaki İçerik (TS EN ISO 9241-151 | 7.1.4)
• Sayfa İçeriklerinin Güncel Tutulması (TS EN ISO 9241-151 | 7.2.4; 7.2.5; 9.3.5)
• Kullanılabilir İçerik (TS EN ISO 9241-151 | 6.6)
• Görsel Tasarım Prensipleri (TS EN ISO 9241-151 | 7.1.3; 9.2)
• Xxxxx Xxxxxxxxxxx (TS EN ISO 9241-151 | 6.7)
• Sayfa İçeriğinin Basit Olması (TS EN ISO 9241-151 | 7.1.5)
• Sayfaların Tutarlı Olması (TS EN ISO 9241-151 | 7.1.5; 9.3.2; 9.3.15)
• Sayfanın Ekrana Sığması -
• Sayfa Uzunlukları (TS EN ISO 9241-151 | 7.1.6; 8.4.14; 9.3.6)
• Satır Uzunlukları (TS EN ISO 9241-151 | 7.1.6)
• Boşlukların Kullanımı (TS EN ISO 9241-151 | 9.3.17)
• İşlem Yapılan Sayfalar (TS EN ISO 9241-151 | 7.1.6)
• Renk Kullanımı (TS EN ISO 9241-151 | 9.3.9)
• Çerçeve Kullanımı (TS EN ISO 9241-151 | 9.3.10; 9.3.11; 9.3.12)
• Xxxxx Xxxdırmanın Önlenmesi (TS EN ISO 9241-151 | 9.3.8)
• Kaydırma Çubuğu veya Sayfalama Yapısının Kullanılması (TS EN ISO 9241-151 | 8.4.14; 9.3.7)
• Kullanıcı Kontrolü Dışında Açılan Ekranlar (TS EN ISO 9241-151 | 8.3.10.1; 8.3.10.2)
• Yeni Sayfada Açılan Pencereler (TS EN ISO 9241-151 | 8.3.11)
• Anlaşılır Hata Mesajlarının Sunulması (TS EN ISO 9241-151 | 10.3.2)
• Tablolarda Satır ve Sütun Başlıklarının Kullanılması -
• Tablolarda Satır ve Sütun Büyüklükleri -
• İçeriğin Yazdırılması (TS EN ISO 9241-151 | 9.3.16)
Başarı kriteri olarak TS EN ISO 9241-151 standardında belirtilen AAA düzeyi karşılanmalıdır. AAA düzeyi: Web sayfası AAA düzeyinde uygunluk için, tüm A düzeyi, AA düzeyi ve AAA düzeyi başarı kriterlerini karşılar ya da AAA düzeyinde uygunluk sağlayan alternatif bir model sağlanır.
Ara yüzlere ilişkin başta tasarım özellikleri ve ara yüz yerleşimi gibi diğer konular DETAY ANALİZDE ayrıca değerlendirilecektir.
Yüklenici teklifinde; Sistemde kullanılacak frameworkler, yazılım dilleri, veritabanları, araçlar, servis mimarileri ve diğer tüm teknolojiler teklifle birlikte detaylandırılmalıdır.
5.6 API Yapısı- Uygulama İletişim Ara Yüzleri
“TABA - Tapu Bilgileri Araştırması” Bilgi Sistemi Projesi kapsamında geliştirilecek TARA (TAKBİS Araştırma) ve URAN (Ulusal Rapor Numarası) uygulamaları web arayüzü dışında API arayüzü ile değerleme kuruluşlarına ait bilgi sistemlerine de yanıt verecektir.
API kullanımında Değerleme Kuruluşlarına ait sistemler sadece ön tanımlı bir IPden erişeceklerdir. Ayrıca yine de API anahtarı ile de erişimin doğrulaması gerçekleştirilecektir. API ara yüzünde kullanılacak web servisler
RESTful servisler olarak geliştirilmelidir. API veri paketi olarak JSON kullanacaktır.
Servislerin içerikleri ve erişimlerin yetkilendirmesi gibi diğer konular DETAY ANALİZDE ayrıca değerlendirilecektir.
5.7 Kullanıcılar – TBS Merkezi Kullanıcı Yönetimi
• TDUB Yönetim Kurulu Üyeleri
• TDUB Denetleme Kurulu Üyeleri
• TDUB Çalışanları
• Tüzel Kişi Üye Temsilcileri
• Gerçek Kişi Üyeler
Tüm kullanıcılar için geçerli merkezi bir yetki yapısı olmalıdır. Yetki yapısı ile ilgili değişiklikler mutalaka bilgilendirme ve/veya çift onay ile yönetilmelidir.
Kullanıcı rolleri ve yetkilendirmesi gibi diğer konular DETAY ANALİZDE ayrıca değerlendirilecektir.
5.8 LOG Yapısı – TBS Merkezi Denetim İzi Yönetimi
Merkezi Denetim İzi sunucusu sistemdeki her olay için syslog protokolü ile log yönetim yazılımları üzerinden geçerek kaydedilmelidir. Denetim izi kayıtlarında kullanıcı, zaman ve IP bilgileri bulunmalıdır.
Sistem Denetim İzi Kayıtları
Sistem tarafından tanımlı denetim izi kayıt kaynakları şunlardır
• auth – giriş işlemleri
• cron – zamanlanmış görevler
• daemon – arkaplan hizmetleri
• kernel – çekirdek mesajları
• mail – mail kayıtları
• syslog – syslog’un kendisi ile ilgili kayıtlar
• lpr – yazıcı kayıtları
• ftp – dosya trasfer kayıtları
• local0 – local7 – kullanıcı tanımlı mesajlar
Uygulama Denetim İzi Kayıtları
Uygulamalar tarafından üretilen görüntüleme ve değişiklik işlemleri için denetim izi kayıt kaynakları şunlardır
• URL çağrıları (GET değerleri)
• Güncelleme işlmeleri (POST değerleri)
• Dosya indirme işlemleri
• Toplu veri güncelleme işlmeleri
• E-Posta gönderim işlemleri
• SMS gönderim işlemleri
Denetim izi olarak loglanacak iş ve işlemelere ilişkin log içerikleri, log izleme yapısı, log arşivleme yapısı, loğların zaman damgası ile imzalanması gibi diğer konular DETAY ANALİZDE ayrıca değerlendirilecektir.
6 Ekip Üyeleri
Başlangıçtaki uygulama geliştirilme dönemi ve kullanıma alınması sonrasındaki işletim döneminde (Yüklenici tarafındaki öngörülen kişi bilgileri bu döneme aittir.) proje taraflarının ekip üyeleri aşağıda belirtilmiştir TDUB Tarafı ve TDUB tarafından sağlanacak Veri Merkezi Tarafı ekip üyeleri bilgi amacıyla verilmiştir.
6.1 TDUB Tarafı
• Proje Lideri (1 kişi) (En az 15 yıl deneyimli)
• Proje Yöneticileri (2 kişi) (En az 0 xxx xxxxxxxxx)
• Xxxxxx Xxxxxxxxxxx (0 xxxx) (Xx az 2 yıl deneyimli)
• UAT Test Uzmanları (2 kişi) (En az 2 yıl deneyimli)
6.2 Veri Merkezi Tarafı
• Proje Temsilcisi (Müşteri Temsilcisi) (1 Kişi)
• Ağ Mühendisi (1 Kişi)
• Bilgi Güvenliği Mühendisi (1 Kişi)
6.3 YÜKLENİCİ Tarafı
• Proje Lideri (1 kişi) (En az 15 yıl deneyimli)
• Proje Lider Yardımcısı (1 kişi) (En az 5 yıl deneyimli)
• Proje Yöneticileri (4 kişi) (En az 2 yıl deneyimli)
• Yazılım Yöneticisi (1 kişi) (En az 10 yıl deneyimli)
• Yazılım Takım Liderleri (2 kişi) (En az 0 xxx xxxxxxxxx)
• Xxxxxxx Xxxxxx (0 xxxx) (Xx az 0 xxx xxxxxxxxx)
• Xxxxxx Xxxxxxxxxx (0 xxxx) (Xx az 10 yıl deneyimli)
• Yazılım Test Uzmanı (2 kişi) (En az 5 yıl deneyimli)
• Yazılım Destek Uzmanı (2 kişi) (En az 2 yıl deneyimli)
7 Fonksiyonel Özellikler
7.1 Genel
1. Mevcut rol ve yetkilendirme kısıtlamaları TDUB tarafından detay analizin kesinleştirilmesi aşamasında belirtilecek düzenlemelerle geliştirilebilir esnekliğe sahip olacaktır.
2. Tüm onay mekanizması ve işleyişi TDUB tarafından detay analizin kesinleştirilmesi aşamasında belirtilecek düzenlemelerle geliştirilebilir esnekliğe sahip olacaktır.
3. Tüm arayüzlerdeki sayfalarda, girilmesi gerekli zorunlu alanların etiketlerinde * (yıldız) karakteri görünecektir.
4. Sistemdeki veriler, TAKBİS vb. kaynaklardan gelecek bilgilerle uyumlu olacaktır. Hangi verilerin bu uyuma konu olacağı detay analizin kesinleştirilmesi aşamasında belirlenecektir.
5. KDV oranı gibi sistemsel veriler parametrik olacaktır.
6. Denetim İzleri ile ilgili mevzuata uyum kapsamında veri tabanından yapılacak her tür sorgulama ve veri tabanı güncellemeleri kullanıcı, zaman ve değişiklik detaylarını içerecek şekilde loglanacaktır. Loglama ile ilgili diğer detaylar, detay analizin kesinleştirilmesi aşamasında belirlenecektir.
7. Bildirimler e-Posta ve SMS ile yapılabilecektir. Hangi durumda bildirim yapılacağı ve bildirim mesajlarının yapısı ve bildirim yöntemi, detay analizin kesinleştirilmesi aşamasında belirlenecektir.
8. Toplu veri alabilmek için Raporlama ve Listeleme ile ilgili arayüz sayfalarında excel ile ilgili sonuçlar indirilebilecektir. Liste yapıları detay analizin kesinleştirilmesi aşamasında belirlenecektir.
7.2 Belge Doğrulama Uygulaması İşlevleri
1. Üretilen tüm belgelerin üzerinde tekil bir doğrulama numarası ve bu numaraya ait QRCODE basılı olarak bulunacaktır.
2. Doğrulama numarası sayesinde internet üzerinden her hangi bir ilgili bu belgeyi doğrulayabilecektir.
3. Doğrulama formunda CAPTCHA zorunluluğu bulunacaktır
4. Her bir doğrulama işlemine ilişkin denetim ii kayıtları oluşturulacaktır.
QRCODE standardı, CATPCHA yapısı, doğrulama numarası yapısı ve doğrulama ekranında gösterilecek bilgiler DETAY ANALİZDE ayrıca değerlendirilecektir.
7.3 TABA Yönetim Uygulaması İşlevleri
1. Yazılımın yönetim ekranları bulunacak ve kullanıcılar, değerleme kuruluşları, üyeler, iller, ilçeler, çeşitli parametreler vb. bilgiler kullanıcılar buradan tanımlanacak ve yetkilendirilecektir.
2. Yazılımda dosya yüklenmesi durumunda performans sıkıntıları yaşanmayacaktır. Böyle bir durumda yüklenecek dosyaların büyüklükleri parametrik olacaktır ve bu şekilde dosya boyutları kontrol edilebilecektir.
7.4 Değerleme Uzmanları için TAKBİS Araştırma Uygulaması (TARA) İşlevleri
1. Değerleme Uzmanları ve değerleme şirketlerince yetkilendirilen diğer çalışanlar tarafından TAKBİS veritabanı üzerinde araştırma yapılabilecektir.
2. Araştırma öncesinde değerleme şirketine URAN numarası tahsis edilmemişse URAN numarası tahsis edilmesi sağlanacak. URAN numarası tahsisi için İl ve İlçe yeterli olacaktır.
3. Araştırma çalışmasının mutlaka bir URAN numarası ile ilişkili olması ve bu numaraya ait İl ve İlçe içerisinde yapılabilmesi sağlanacaktır
4. Bir URAN numarası içerisinde birden çok taşınmazın değerlemeye konu olması durumunda URAN uygulaması üzerinden ada ve parsel ile ilgili yakınlık kontrolü yapılacaktır. Birlikte bir değerleme
raporuna konu olamayacak olan gayrimenkuler ile ilgili açıklayışı uyarılar kullanıcıya gösterilecektir.
5. Başarıyla sonuçlandırılan araştırma sonrasında ilgili URAN numarasının TAKBİS Araştırmasına ait durumu EVET olarak güncellenecek ve sorgulama sonucu ile URAN numarasının ilişkisi kurulacaktır.
6. Aynı şirketten farklı kişilerin tekrar tekrar aynı URAN numarasına ait sorgulama yapmaları
engellenecek (Sadece izinli olan uzman ve çalışanlar yerine aynı veye üst ROL tarafından araştırma yapılabilir)
7. Aynı URAN numarası ile en fazla üç gün içinde aynı kişi tarafından birden çok defa sorgulanabilir (iki sorgulama arasında en az 2 saat zaman farkı olmalıdır). Bu durumda kullanıcının durumun nedenini açıkladığı en az 50 karakterli açıklama yazması zorunlu olacaktır.
8. Araştırma sonucunda standardı daha sonra DETAY ANALİZDE belirlenecek “Tapu Sicil Örneği” başlıklı PDF Belge ve JSON Veri Paketi dosyaları üretelecektir.
9. PDF Belge üzerinde Dorğulama Numarası, QRCODE yanı sıra URAN numarası, araştırma yapan şirket ve kullanıcı üye sicil numaraları yer alacaktır.
10. PDF Belge üzerinde ayrıca Belge ID’si bulunacaktır. Belge ID’si aynı gayrimenkul için farklı saatlerde yapılan sorgulamalarda değilşecektir
11. JSON Veri Paketi içeriği mevcut WebTapu JSON veri paketi ile uyumlu olacaktır
12. Araştırma sonucunda ilgili dosyalar zaman damgası basılarak arşivlenecektir.
13. Araştırma sonucunda İŞLETME tarafından mutabakat dönemi sonunda (ay sonu) mutabakata konu olacak biçimde ilgili URAN numarası ve Belge ID’si için işlem dekontu düzenlenecektir.
14. İşlem Dekontunda ayrıca bir Dekont ID bulunacaktır. Dekont içeriği DETAY ANALİZDE detaylandırılacaktır.
7.5 Ulusal Rapor Numarası Tahsis Uygulaması (URAN) İşlevleri
1. Ulusal Rapor Numarası her bir değerleme süreci için tekil olacak
2. URAN numarası ile ilgili Tahsis ve Kullanım olarak iki ana veri güncelleme noktası bulunacaktır
3. Aşağıdaki noktalardan URAN numarası tahsis istekleri gelecek
- TARA uygulamasından Değerleme Kuruluşu, İl, İlçe, Ada ve Xxxxxx, Müşteri (TCKN veya VKN) bilgileri ile
- Diğer entegrasyon noktalarından Değerleme Kuruluşu, İl, İlçe, Ada ve Parsel, Müşteri (TCKN veya VKN) bilgileri ile
4. Aynı Değerleme Kuruluşu aynı müşteri için bir arada hazırlayabilecek için farklı değerleme raporları hazırlıyor ise bu durum izlenerek kontroller konulacak. (Engellenmeyecek ama en az 50 karakter açıklama yazması talep edilecek)
5. URAN numarası ile ilişkili bilgiler tahsis ve kullanım ana adımlarında güncellenecek. Tahsis Adımı Değerleme Sürecinin başlangıcını, kullanım adımı ise değerleme sürecinin sonunu ifade etmektedir.
6. Değerleme sürecinin sonunda başarılı şekilde Kullanım adımına geçebilmek için ilgili değerleme sürecine ilişkin Uzman, Denetmen ve Sorumlu Değerleme Uzmanı TCKN bilgileri iletilecektir.
7. Tahsis edilmesine rağmen kullanılmayan URAN numaraları ile ilgili değerleme kuruluşu kullanmama gerekçesini iletecek (iletmediği durumunda yetki aşımı vb konuları için raporlamaya konu edilecektir)
7.5.1.1 Rapor Numarası Yapısı
Rapor Numarası 2+3+2+2+6+1 şeklinde 16 basamaktan oluşmaktadır.
1. ve 2. rakamlar; rapor yılının son iki rakamı
3.-5. rakamlar; Değerleme kuruluşu TDUB Sicil numarasına karşılık
6. ve 7. rakamalar; İl Plaka kodu
8. ve 9. rakamalar; İl içindeki ilçeler için sıra kodu
10.-15. rakamlar; TABA tarafından belirlenen ve değerleme kuruluşuna özgü rapor yılına özgü tekil rapor numarasını
16. rakam; kontrol numarası
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 |
1 | 9 | 0 | 6 | 0 | 0 | 6 | 0 | 8 | 7 | 2 | 3 | 6 | 4 | 1 | 9 |
Daha kapsamlı olarak DETAY ANALİZDE belirlenecektir.
7.6 Değerleme Uzmanları için TAKBİS Araştırma Uygulaması (API) İşlevleri
1. TARA WEB uygulaması işlevlerinin API aracılığı ile gerçekleştirilmesi sağlanacaktır.
2. API kullanıcıları tanımlanmış ve yetkilendirilmiş kullanıcılar olacaktır. Her bir değerleme kuruluşu sadece 1 adet noktadan API çağrısı yapabilecektir.
3. API servisleri ve diğer ayrıntılar DETAY ANALİZDE belirlenecektir.
7.7 Ulusal Rapor Numarası Tahsis Uygulaması (API) İşlevleri
1. URAN WEB uygulaması işlevlerinin API aracılığı ile gerçekleştirilmesi sağlanacaktır.
2. API kullanıcıları tanımlanmış ve yetkilendirilmiş kullanıcılar olacaktır. Her bir değerleme kuruluşu sadece 1 adet noktadan API çağrısı yapabilecektir.
3. API servisleri ve diğer ayrıntılar DETAY ANALİZDE belirlenecektir.
7.8 TAKBİS İle Entegrasyon İşlevleri
1. TAKBİS veritabanı araştırmasında standart TAKPAS2 web servisleri kullanılacaktır
2. TAKPAS2 web servisleri kullanılırken en az sorgulama maliyeti oluşması sağlanmalıdır.
3. TAKPAS2 web servisleri kullanılırken kullanıcılara paramatre seçimlerinde (İl, İlçe, Mahalle-Köy, Ada,
Parsel vb.) güncel parametreleri seçmeleri sağlanacaktır. Bu parametreler anlık servisten seçilmeyecek belirli süreler için cachelenecektir.
7.9 Değerleme Kuruluşları İle Entegrasyon İşlevleri
1. Değerleme Kuruluşları ile Entegrasyon konusunda yetkilendirme, erişim yönetimi konuları yönetilebilir olacaktır.
2. Değerleme kuruluşları için işlemler bazında ve her bir şirket özelinde limit tanımı yapılabiliecektir. Limit tanımları yönetim arayüzünden yapılabilecektir.
8 Temel Tasarım
8.1 Mimari – Mantıksal Sistem Mimarisi
Sistem beş mantıksal mimari katmandan oluşacaktır. Her bir mantıksal katmanın temel özellikleri aşağıda anlatılmıştır.
8.1.1 Sunum Katmanı
Kullanıcılar ve Paydaşlara ait sistemler tarafından erişilebilen katmandır. Sunum katmanı sistemin tamamı için
sistemin tüm girdilerinin karşılandığı ve yine sistemin çıktılarının sunulduğu tek katmandır. Bu özelliği dolayısıyla Sunum Katmanı sistemin tümüne ilişkin ilgililere fikir veren ve sistemin başarısını gösteren katmandır. Sistem performansı, sistem sürekliliği, erişim yetkilendirme, bilgi güvenliği vb. konularda bu katman göz önünde
olacaktır. Sunum katmanı yetkilendirilmiş kullanıcılara ve belge doğrulama amaçlı erişen diğer kişilere hizmet verecektir.
8.1.2 Bilgi İşleme Katmanı
Hem sunum katmanı tarafından gösterilecek verileri hem de sunum katmanı tarafından iletilecek verilerin paketlendiği ve çeşitli son kontrollerinin yapıldığı katmandır. Aynı zamanda kullanıcıyı yönlendirme amaçlı hata mesajlarının üretildiği de katmandır. Bu katmanda aktarıma konu verilere ilişkin veri paketinin biçimlendirmesi, dinamik dosyalara ilişkin biçimlendirme işlemleri, sık erişilen verilere ait cache yönetimi vb. işlemleri de
yapılacaktır. Ayrıca bu katmanda dinamik olarak üretilen tüm pdf belge dosyalarının zaman damgası ile damgalanması sağlanacaktır.
8.1.3 Entegrasyon Katmanı
Entegrasyon katmanı bilgi işleme katmanının yanı sıra API arayüzlerine de veri paketi olarak hizmet veren
katmandır. Yetki aşımı başta olmak üzere çeşitli bilgi güvenliği kontrollerinin de yapıldığı katmandır. Denetim izine esas olan erişim bilgilerinin kayıt altına alınması ile ilgili hazırlık bu katman tarafından yapılacaktır.
8.1.4 Veri Hazırlama Katmanı
Veri hazırlama katmanı hem veritabanına erişen hem de çeşitli depolama ortamlarına erişen katman olması nedeniyle entegrasyon katmanına gönderilecek verilerin hazırlanması ve saklanacak verilerin hazırlanması
işlemlerinin yapıldığı katmandır. Verilerin hangi aşamalarla nasıl hazırlanacağı bu katman tarafından yönetilir.
8.1.5 Veri Kaynakları Katmanı
Veri hazırlama katmanı tarafından iletilen saklanmaya hazır verilerin birbirleri ile ilişkili biçimde saklanmasının ve saklanan ortamdan getirilmesi istenilen verilerin seçilmesi ile ilgili işlemlerin yapıldığı katmandır.
Yüklenici teklifinde; mantıksal katmanlara karşılık olarak bilgi sisteminin bileşenlerini detaylandırılmalıdır.
9 Gereksinimler
9.1 Gereksinimler – İhtiyaçlar ve Problemler
İhtiyaçlara ilişkin paydaşlar düzeyinde liste aşağıda paylaşılmıştır.
9.1.1 1. Paydaş Grubu: TDUB
9.1.1.1 TDUB Yönetimi ve Çalışanları
• Değerleme kuruluşları ve değerleme uzmanları bazında değerleme süreçlerinin ilişkisinin sonradan kuruluyor oluşu
• Her bir değerleme sürecinin kapsamının izlenemiyor oluşu
• Her bir değerleme sürecinin başlangıç ve bitiş zamanlarının bilinememesi
• Değerleme süreçlerinin ülke düzeyinde tek bir takip numarasına sahip olmaması
• İstatistiki çalışmalara uyumlu merkezi bir veritabanı oluşmaması
• Mesleki denetim anlamında ihtiyaç duyulan verilerin artması
• Ortak parametreleri (il, ilçe, mahalle-köy vb.) sektör genelinde kullandırılamaması
• Şikayetlerin iletilmesinden sonuçlanmasına kadar geçen sürenin uzunluğu
9.1.1.2 TDUB Üyesi Değerleme Kuruluşu
• Çalışanlar için TAKBİS erişim yetkisinin alımındaki zorluklar
• Hizmet kalitesi için kurum içi uygulamalardan veriye erişim ihtiyacı
• Çok aşamalı ve zaman alıcı süreç yerine kısa sürede “Tapu Bilgileri Araştırma Raporu”na erişim
• Elle yazıma ihtiyaç duymadan iş kuralları çerçevesinde sistemsel veri girişi ihtiyacı
• Veriye erişime ait denetim izlerinin detaylandırılması ihtiyacı
• Sistemler arası dosya ve veri aktarım güçlükleri
• Tek bir ortamda TAKBİS verilerine erişim ihtiyacı
• Kesintisiz ve hızlı biçimde TAKBİS verilerine erişim ihtiyacı
• Hizmet bedeli ödeme ve belgeleme işlemlerinin elle yürütülmesi
• KVKK sonrası daha da artan veri güvenliği ihtiyacı
• İlk anda Değerleme Raporu - Taşınmaz arası ilişkinin oluşmaması
• Arşivleme süreçlerinin verimsizliği
• Bildirim ve uyarı eksikliği
• Ödeme aracı bağımlılığı
• Denetim izi kayıtlarının farklı sistemlerde bulunması
9.1.1.3 TDUB Üyesi Değerleme Uzmanı
• Kısıtlı sayıda bir değerleme uzmanının TAKBİS verilerine erişiyor oluşu
• Değerleme anında TAKBİS verilerine erişilemiyor oluşu
• Verilerinin tamamının tekrar elle yazılıyor oluşu
• Eksik ve hatalı gayrimenkullerin tespitinin zaman alması
• Verilerin ihtiyaca göre sistemsel kontrolunun olmaması
• Sistemsel ön değerlendirme, uyarı vb eksikliği
9.1.2 2. Paydaş Grubu: TKGM
• Erişim yetkilendirme süreçlerinin kullanıcı düzeyinde elle yapılması
• Erişim için bir internete açık bir web uygulamanın zorunlu olması
• KVKK sonrası daha da artan veri güvenliği ihtiyacı
9.1.3 3. Paydaş Grubu: Değerleme Raporu Hazırlama Hizmeti Alıcıları
• KVKK sonrası daha da artan veri güvenliği ihtiyacı
• Belge doğrulama ihtiyacı
• Arşivleme süreçlerinin verimsizliği
• Hizmet bedeli ödeme belgesinin kaynağının Fatura olmayışı
9.2 Tapu Bilgileri Araştırması (TABA) Bilgi Sistemi Nedir?
Tapu Bilgileri Araştırması Bilgi Sistemi, değerleme hizmeti üreticisi değerleme kuruluşları ve bu kuruluşun
çalışanı olan değerleme uzmanlarının, değerleme süreci ile ilişkisi kurulmuş biçimde ve değerleme raporunun kapsamındaki tüm taşınmazlara ait ihtiyaç duydukları tapu bilgilerine erişimlerini sağlayan, bunlar ile ilgili mali konuları sistemsel olarak yöneten, “Tapu Bilgileri Araştırma Raporu”nu zaman damgası ile kayıt altına alıp
gelişmiş güvenlik standartları dahilinde saklayacak ulusal ortak veri tabanı sistemidir
9.3 Kurallar – Zorunluluklar
İlgili yasal düzenlemeler kapsamında bilgi sistemi yapısında zorunluluklar bulunmaktadır. Ayrıntılar DETAY ANALİZDE belirlenecektir.
9.4 Kısıtlar – Yasal Kısıtlar
İlgili yasal düzenlemeler kapsamında kısıtlar bulunmaktadır. Ayrıntılar DETAY ANALİZDE belirlenecektir.
9.5 Güvenlik - Bilgi Güvenliği Gereksinimleri
9.5.1 Platformlar ve Bileşenlerinin Ağ İçinde Konumlanma Gereksinimleri
PROD | PRE-PROD (UAT) | TEST | DEV |
Canlı Ortam | Canlı Öncesi Ortam | Yazılım Test Ortamı | Yazılım Geliştirme Ortamı |
Güvenlik Duvarı Arkasında uygulama özelinde yapılandırılan ve bulunduğu WEB ve API sunucuları özgü hizmet veren yük dengeleyici arkasında tanımlı IP bloklarının erişimine açık | Güvenlik duvarı arkasında tanımlı IP bloklarının erişimine açık | Güvenlik duvarı arkasında tanımlı IP bloklarının erişimine açık | Güvenlik duvarı arkasında tanımlı IP bloklarının erişimine açık |
Tüm ortamlarda sunucular ve uygulamalar yapılandırılırken web ve api uygulamalarının bileşenlerin
tasarımı ile mimarisinde aşağıdaki kurallara uyulur ve kullanımlar bu kurallara göre gerçekleştirilmelidir.
1. Uygulama sunucuları ile veri tabanı, servis, dosya, e-posta, log vb. uygulama arkası tüm sunucular arasındaki iletişimde ihtiyaç duyulan en az yetkiye sahip hesaplar kullanılmalıdır.
2. Web uygulamasının çalışma mekanizmasında “WEB APP sunucu - DB” şeklinde aşamalı/fazlı bir yapı
kullanılmalıdır. Web uygulamalarının veritabanı işlemleri ile ilgili işlemlerde procedurel vb. yönetilebilir bir yapı bulunmalıdır.
3. Dışarıya verilen API hizmetlerinde çalışma mekanizmasında API sunucu - APP sunucu - DB” şeklinde aşamalı/fazlı bir yapı kullanılmalıdır. API uygulamalarının veritabanı işlemleri ile ilgili işlemlerde procedurel vb. yönetilebilir bir yapı bulunmalıdır.
4. Tüm WEB ve API sunucuları servis, dosya, e-posta, log vb. uygulama arkası tüm sunuculara erişimlerinde ayrıntılı log üretmelidir.
5. Veri tabanına yapılan erişimlerde her bir uygulamaya özgü tanımlanan SQL kullanıcısının yetkileri veritabanı, tablo ve veritabanı işlem türü bazında ile yönetilebilir olmalıdır.
6. Yük dengeleyici (load balancer) arkasındaki web uygulamaların sertifika çözümleme işlemleri web sunucularında gerçekleştirilir. Yani kullanıcıdan gelen trafik yük dengeleyiciye HTTPS’li geldikten sonra sertifika kaldırılmaz, en uç noktadaki sunucuya kadar trafik HTTPS’li olarak iletilip, sunucu üzerinde sertifikanın çözümleme işlemi gerçekleştirilir.
7. Sunucular ile veri tabanı sunucuları arasındaki iletişim şifrelenebilmelidir.
8. Web uygulamalarının yönetimsel ara yüzleri mümkünse sunucudaki ayrı bir port üzerinden ve/veya sadece tanımlı IP adreslerine yayın yapacak şekilde ayarlanmalı ve güvenlik duvarı üzerinde yönetimsel ara yüzlere sadece ilgili personel erişecek şekilde yetki verilmelidir.
9. Bir sunucuda en fazla bir web uygulaması barındırılmalı, yani birden çok uygulama ortak bir host/sunucu üzerinden yayın yapmamalıdır.
10. Uygulamalar güvenli iletişim kanalı olan HTTPS üzerinden yani sunuculara SSL/TLS sertifikası yüklenerek hizmet vermelidir. Güvenli kanal iletişimi için sunucularda en az TLS v1.2 sürümü
kullanılmalı, düşük sürüm sertifika tanımlamaları (TLSv1.1, TLSv1.0, XXXx0, XXXx0 vb) iptal edilmelidir. Web uygulamasındaki bütün http trafikleri otomatik olarak HTTPS’e yönlendirebilmesi için HSTS (HTTP Strict Transport Security) başlığının kullanılması tavsiye edilir.
11. Sunucularda web uygulamaları için gereksiz olabilecek HTTP metotları (OPTIONS, HEAD, PUT, DELETE, TRACE, CONNECT ve benzeri) metotları kapatılmalıdır.
12. Her türlü sürüm, sanal host, footer (signature) ve banner bilgilerini ifşa eden otomatik tanımlamalar/bilgilendirmeler kapatılmalıdır.
13. Sunuculardaki dizin listelemeleri (directory listing) kapatılmalıdır.
14. Sunuculardaki kullanılmayacak olası gereksiz servisler üretim ortamına çıkmadan önce belirlenerek kapatılmalıdır. Örneğin SNMP, DNS, MAIL ve benzeri gibi.
15. Windows IIS sunucu üzerinde “IIS Tilde Ad Çözümleme Zafiyetini” önleme amacıyla registry de “HKLM\SYSTEM\CurrentControlSet\Control\FileSystem” bölümünde
“NtfsDisable8dot3NameCreation” key i oluşturulmalı ve 1 değeri verilmelidir. Bu işlem yapıldıktan sonra IIS üzerinde bulunan site’ların tekrardan eklenmesi gerekmektedir.
16. Sunuculara uygulamalar için gerekeli olabilecek 3.parti xxxx xxxxxx kütüphaneler, eklentiler ile yan uygulamalar en güncel sürümüyle yüklenmelidir. Bu eklenti, kütüphane ve yan uygulamaların yamaları periyodik olarak takip edilmelidir.
17. Sunucularda HTTP Request Size için de sınırlamalar getirilmelidir.
18. Sunuculardaki tüm web dizinlerinde SSI ve CGI Execution kapatılmalıdır.
19. Sunuculara uygulamalar için gerekeli olabilecek 3.parti xxxx xxxxxx kütüphaneler, eklentiler ile yan uygulamalar en güncel sürümüyle yüklenmelidir. Bu eklenti, kütüphane ve yan uygulamaların yamaları periyodik olarak takip edilmelidir.
Ağ İçinde Konumlanma Gereksinimleri DETAY ANALİZDE ayrıca değerlendirilecektir.
9.5.2 Genel Güvenlik Gereksinimleri
1. TABA’nın dış kullanıcıları ile kurum içi kullanıcıların bağlanacağı web ekranları ayrıştırılmalıdır. Bunun için kurum içi kullanıcıların bağlanacağı PROD web sunucuları sadece tanımlı IP’lere izin verilecek
şekilde güvenlik duvarı arkasında konumlandırılmalıdır.
2. PROD ortamı dışındaki ortamların erişim kısıtı olmaksızın internete açılması söz konusu değildir.
3. WEB ve API kullanıcılarına ait parolalar veri tabanında açık metin (clear-text) olarak tutulmamalı, en az SHA256 (salted) özeti alınarak saklanmalıdır.
4. TABA’nın WEB uygulamaları eğer tanımlı IP bloklarına erişime açılmayacak ise mutlaka WAF (web uygulama güvenlik duvarı) arkasına konumlandırılmalıdır.
5. Erişim yetkilendirilmesi yapılan TABA WEB uygulamalarında kullanıcılar bağlanırken iki adımlı doğrulama (2FA) yapılmalıdır. Bunun için SMS OTP veya mobil uygulama tabanlı bir mobil OTP kullanılmalıdır.
6. TABA’nın herhangi bir noktasında/bileşeninde kriptoloji otoriteleri tarafından sınanmamış ve kriptoloji uzmanları tarafından geliştirilmemiş hiçbir "custom" algoritma kullanılmamalıdır. Bu yüzden özet algoritmalarında en az SHA2, güvenli kanalda HTTPS, statik/simetrik şifreleme de en az AES256
kullanılmalıdır.
7. TABA’nın uygulamaları mümkün olduğunca birbirlerine ait veri tabanlarından izole olarak sadece kendilerine ait veri tabanlarında çalışmalıdır. Her bir uygulama kendine özgü yetkilendirilmiş veri tabanı kullanıcısı ile çalışmalıdır.
8. TABA’nın tüm uygulamarına özgü olarak her tür bilgi güvenliği testi ayrı ayrı uygulanıyor olmalıdır. Uygulama özelindeki majör değişiklikler için de yeni testlerinin yapılması gerekir.
9. TABA genelinde kullanılacak açık-kaynak servis uygulama (LINUX, PHP, Python, MySQL, MariaDB,
PostgreSQL vb.) tercihinde kurumsal desteği olan, güvenlik açıklıkları belli bir düzende kapatılan ve düzenli destek/bakım sunabilen kurumsal lisanslı sürümlerin seçilmesi esastır. Servis uygulamalarının sürüm geçişleri (yama süreci) aktif biçimde planlanıyor ve uygulanıyor olmalıdır.
10. Uygulamaların periyodik güncellemeleri servis uygulamalarının yama sürecine uygun olarak yapmalıdır. Hiçbir şekilde bu uygulamaların kurulduğu haliyle/sürümüyle sürekli olarak kullanılmasına devam edilemez.
Genel Güvenlik Gereksinimleri DETAY ANALİZDE ayrıca değerlendirilecektir.
9.5.3 WEB Güvenliği Standartları
20. Web uygulamalarının kurum içi kullanıcı doğrulaması, kurumsal kimlik yönetim uygulaması ile yapmalıdır.
21. Web uygulamaları, kurum içi kullanıcıların yanı sıra dış kullanıcılara da aynı anda hizmet verecekse kurumsal kimlik yönetim uygulaması yanı sıra birden çok kullanıcı doğrulama mekanizmasını destekleyebilmelidir.
22. Web uygulamalarını kullanmaya yetkili olan kullanıcı hesaplarının hiçbir şekilde kullanıcı tarafından kullanılmaması durumunda hesap en fazla 93 takvim günü sonrasında otomatik olarak kullanım dışı bırakılmalıdır.
23. Web uygulama kullanıcıları kendi istekleri ile kullanıcı hesaplarını kullanım dışı bırakabilmelidir.
24. Her hangi bir kullanıcı hesabının tekrar kullanıma alınması veya bir kullanıcı hesabının ilk defa
kullanıma alınması için en az iki uygulama yöneticisi tarafından onaylanarak aktif hale getirilebilmelidir.
25. Web uygulamaları, kullanıcı doğrulamasının kurumsal kimlik yönetim sistemleri ile yapılamadığı durumlarında aşağıda detayları verilen kurumsal parola standardına uygun olarak kullanıcı parola yönetimini gerçekleştirebilmelidir. Parola yönetiminin asgari ayar gereksinimleri şunlardır:
• parola uzunluğu
• parola kompleksliği
• parola kullanım süresi
• son kullanılan kaç parolanın kullanılamayacağı
• yanlış parola deneme sayısı (hesabı kilitleme)
• parola unutma/sıfırlama akışları
26. Yukarıdaki gereksinimler aynı zamanda tüm sunuculardaki yerel “administrator, admin, root” gibi
kullanıcılar için de uygulanmalıdır. Bu kapsamda TABA’nın dış kullanıcıların parolası için uygulamada aşağıdaki standartlar/kısıtlamalar uygulanır;
• Parolalar en az bir büyük harf, en az bir küçük harf ve en az bir sayı içermelidir.
• Kullanıcı kodu, isim-soyad ve telefon numarası bilgilerini içermemelidir.
• Parola en az 12 karakter olacak şekilde oluşturulmalıdır.
• Ç,Ğ,I,İ,Ö,Ş,Ü,ç,ğ,ı,i,ö,ş,ü karakterleri kesinlikle kullanılmamalıdır.
• Maksimum parola yaşı 62 takvim günüdür.
• Büyük ve küçük harfler bir arada kullanılmalıdır.
• Aynı karakter en fazla 4 kez kullanılabilir.
• Kullanılan son 5 paroladan farklı olmalıdır.
27. Web uygulamaları çalışırken tarayıcıların parolaları kaydetmesine neden olacak özellikleri pasif hale
getirmeli veya engelleyebilmelidir. Bunun için uygulama sunucudan dönen response cevaplarında ilgili uygun parametreler dönülmelidir. (Örneğin, Internet Explorer için “AUTOCOMPLETE=OFF” veya Firefox için “disableautocomplete” cevapları gibi.)
28. Web uygulamalarının kullanıcı girişi yapılan ekranlarında CAPTCHA/reCAPTCHA kullanılmalıdır.
29. Web uygulamaları;
• çoklu yanlış parola denemelerinde,
• hiç var olmayan kullanıcı girişi denemelerinde,
• aynı IP adresinden gelen çoklu “failed” login denemelerinde,
• aynı IP adresinden gelen birden çok kullanıcı adıyla yapılan denemelerde,
• farklı IP adreslerinden gelen aynı kullanıcı hesabına yapılan denemelerde,
• alfabetik bir sırada yapılan çoklu kullanıcı adı ve/veya parola girişi denemelerinde,
bu teşebbüslerden herhangi birini yapan saldırgan uygulamayı tamamen kilitleyerek uygulamaya
erişilmesini engellemelidir. Ayrıca bu teşebbüsleri, kaynak IP adresi belli olacak şekilde ilgili birimlere alarm göndermeli ve log üretmelidir.
30. Web uygulamalarında ilk kurulumda varsayılan olarak gelen hazır kullanıcı adı ve parola ikilileri (admin:admin, admin:root, administrator:root, admin:12345, admin:Abc123 ve benzeri gibi) hemen değiştirilmeli veya hiç kullanılmamalıdır.
31. Tüm sunuculardaki yerel “administrator, admin, root” gibi hesapları Kurumsal Ayrıcalıklı Kullanıcı Yönetimi Uygulaması ile yönetilebilmelidir.
32. Web uygulamaları, kullanıcı yetkilendirmelerini (authorization) öncelikli olarak Kurumsal Kullanıcı Yönetimi Uygulaması üzerinden yapmalıdır. Kurumsal Kullanıcı Yönetimi Uygulaması kullanılamadığı durumlarda ayrıntılı kırılımda (fonksiyon bazlı) yetkilendirmeler sunmalıdır.
33. Web uygulamalarının internete açık olması kaçınılmaz ise yönetimsel hesabına giriş arayüzleri/sayfaları sadece iç ağdan erişilebilecek şekilde ayarlanmalı (örneğin, yetkilendirilmiş IP’lere izin vermek gibi) ve bunun için uygulama tabanlı erişim kısıtlaması konulmalıdır.
34. Web uygulaması kullanıcı adı ve/veya parola bilgilerinin yanlış girilmesi durumunda sisteme giriş yapılmak istenen kullanıcının bilgilerinin gerçekte var olup olmadığı ile ilgili hiçbir bilgi vermemelidir. Giriş denemesi yapan kullanıcı hesabı sistemde var olsa veya olmasa da hep aynı hata/bilgi mesajı dönülmelidir.
35. Web uygulamasında bir şifremi unuttum fonksiyonu varsa, bu bölümde kullanıcının yeniden parola üretme bağlantısı almak için gireceği bilgiler (e-posta adresi gibi) sonrasında uygulamanın kullanıcıya
sayfada döneceği mesajda jenerik ve anonim ifadeler yer almalı, yani o kullanıcı var olsa da olmasa da aynı mesaj gösterilmelidir. Örneğin, “girdiğiniz e-posta adresine bağlı bir kullanıcı varsa, e-posta
kutunuza parola sıfırlama bağlantısı otomatik olarak gönderilecektir” ve benzeri gibi.
36. Dış kullanıcılar için ilk defa oluşturulan hesap için kullanıcıya dönen mesajdaki rastgele üretilmiş parola, sisteme girişte otomatik olarak zorla değiştirilmelidir ve bu parola da yukarıda belirtilen standartlara/kısıtlamalara göre üretilmelidir. Kullanıcı bu sistem tarafından üretilen parolayı değiştirmeden sisteme girememeli, işlem yapamamalıdır.
37. Dış kullanıcılar için ilk defa hesap oluşturulduktan sonra TABA’nın en az iki uygulama yöneticisi tarafından onay/yetki vermeden uygulamada işlem yapmaya başlamamalıdır.
38. Web uygulamasında bir şifremi unuttum fonksiyonu varsa, bu fonksiyon kullanıldığı zaman kullanıcıya parola bilgisi açık metin (clear-text) bir şekilde veriler iletilmemeli, sadece kullanıcının parolasını
yeninden oluşturması amacıyla oluşturulmuş tek kullanımlık özel bir bağlantı adresi gönderilmelidir. Yani yeni parola kullanıcıya asla açık metin (clear-text) bir şekilde gönderilmemeli, kullanıcı bu özel bağlantıya geldikten sonra parolasını oluşturmalı ve bu işlemler sırasında SMS OTP veya Mobil OTP ile doğrulama yapılmalıdır
39. Web uygulamasına bir kullanıcıdan, uygulamada bulunan bir bölüme veya veriye erişim talebi
geldiğinde web uygulaması bu kullanıcının erişim yetkisinin olup olmadığını kontrol etmelidir. Bu
kontrol işlemi hiçbir şekilde istemci (client) tarafında yapılmamalıdır. Kullanıcı sadece yetkilendirildiği uygulamalara, uygulama bileşenlerine ve kaynaklarına erişebilmeli ve bunları kullanabilmelidir.
40. Web uygulamaları, belli bir hareketsizlik/pasiflik süresinden sonra (time-out) kullanıcı oturumunu otomatik olarak sonlandırmalıdır.
41. Web uygulaması kullanıcının oturumunu güvenli bir şekilde sonlandırması için bir logout mekanizması bulundurmalıdır.
42. Web uygulamalarının oturum ID’leri (session ID):
• her yeni oturum için yeniden/baştan oluşturulmalı ve ayrıca bir logout işleminden sonra da aynısı kullanılmamalı,
• rastgele oluşturulmuş olmalı, basit ve tahmin edilebilir olmamalı ve ayrıca istatistiki analizleri önlemek ve güçlü rastsallığı sağlamak için en az 64 bit’lik bir entropi kullanılmalı,
• en az 128 bit (16 bytes) uzunluğunda olmalı,
• basit algoritmalara (MD4, MD5 vb) dayalı olarak oluşturulmamalı, bunun için SHA2 kriptografik özet (hash) fonksiyonu kullanılmalı,
• uygulama içinde gerçekleşen parola değişimleri, izin/yetki değişiklikleri ve standart kullanıcıdan başka bir yetkili kullanıcıya dönüşme gibi aşamalarda yeniden oluşturulmalı,
• GET metodu ile değil, POST metodu ile gönderilmeli,
• isimlendirmelerinde kodlamada kullanılan dillerin “PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion) ve XXX.XXX_SessionId (ASP .NET)“ gibi jenerik takıları kullanılmamalı, bunun yerine sadece “ID” ve benzeri framework’ü ele vermeyen takılar kullanılmalıdır.
43. Oturumlar ve çerezler için belli bir süre sonra sona erme ve maksimum yaşam süresi nitelikleri (expire and max-age attributes) devreye alınmalıdır.
44. Web uygulamada kullanılan kullanıcı ve parola gibi hesap bilgileri GET metodu ile değil, POST metodu ile gönderilmelidir.
45. Çerezler (cookies), “secure” bayrağı (“Secure” cookie flag attribute) ile işaretlenerek sadece HTTPS üzerinden gönderilmelidir.
46. Çerezler, “HTTPOnly” bayrağıyla işaretlenerek web tarayıcılarının, çeşitli scriptlerin “DOM document.cookie object” çağrısı ile çerezlere erişmesi engellenmelidir.
47. Web uygulamaları, bir kullanıcının aynı anda başka bir IP adresi üzerinden veya aynı IP’den ama farklı bir web tarayıcısı üzerinden eşzamanlı yeni bir oturum daha açmasını engellemelidir.
48. Web tarayıcılarının oturum ID’leri ve çerezlerini önbelleğe kaydetmesini önlemek için “Cache-Control: no-cache="Set-Cookie, Set-Cookie2"” ve benzeri başlıklar kullanılmalıdır.
49. Web uygulamasının hesap kurtarma (account recover) akışında güvenlik sorusu içermesi durumunda bu güvenlik sorularında doğum yılı, memleketi ve benzeri şekilde dış kaynaklardan kolaylıkla elde
edilebilecek bilgiler kullanılmamalıdır.
50. Uygulamanın kaynak kodlarındaki resim, CSS, Javascript ve benzeri dosyalar çağrılırken URL adresi HTTP’li olarak değil, ya HTTPS’li adres olarak ya da doğrudan sadece dizin adresi verilerek çağrılmalıdır.
Örneğin, <img src=”xxxxx://xxx.xxxxxxxx.xxx/xxxxxxxx/xxxxx.xxx”> ve/veya <img src=”/resimler/resim.jpg”> şeklinde olmalıdır.
51. Web uygulamalarında HTTP’li ve HTTPS’li içerikler birlikte (mixed content) hiçbir şekilde kullanılmamalıdır.
52. Web uygulaması, bir oturum girişini HTTP’den alıp HTTPS’e çevirmemeli veya yönlendirmemelidir. Web uygulaması ilk giriş anından başlayarak ve hatta uygulamanın bir bütün halinde tamamen HTTPS üzerinden çalışması gerekir.
53. Web uygulaması içeriğinin tarayıcıda ön belleğe alınması esnasında uygulamanın oturum ve diğer kritik içeriği tarayıcı belleğine alınmamalıdır.
54. Uygulamaya ait normalde POST request içinde gönderilen parametreler, aynı zamanda GET request içinden de gönderilememelidir. Yani web uygulaması kritik bilgilerin gönderiminde aynı anda hem POST hem de GET metodunu birlikte kullanılabilecek şekilde çalışmamalıdır.
55. Web uygulamasında kullanılacak 3.parti JavaScript dosyaları mümkün mertebe harici bir domain üzerinden değil yerel host üzerinde barındırılarak çağrılmalıdır.
56. Web uygulamasını yazan birim ve/veya sahibi, web uygulamasında kullanılacak her türlü JavaScript (JS) modüllerinin en güncel sürümde olmasından ve bu modüllerin güncellemelerinden sorumludur.
57. Web uygulamaları, kullanıcı adları ve bazı hassas bilgileri çerezlere şifrelenmeden (kriptolamadan) iliştirerek göndermemelidir. Yani hassas bilgiler çerezler üzerinden iletilmemelidir.
58. Web uygulamaları kaynak kodları yorum satırları içinde ve kaynak kodu depolarında herhangi bir bağlantıya veya işe ait erişim bilgileri ve/veya yapılandırma ayarları (API anahtarları, parolalar vb) hatırlatma amacıyla dahi olsa tutulmamalıdır/saklanmamalıdır.
59. Web uygulamaları üzerindeki bütün işlemlere dair CEF, syslog veya benzeri formatlarda log
üretebilmeli ve/veya bunu merkezi olay ve kayıt sistemine aktarabilmelidir. Loglar HTTPS kanalı üzerinden gönderilmelidir.
60. Web uygulamaları girdi kontrolü, tüm genel uygulama mimarisi için uygulama risk tehdit analizi yapılarak belirlenmeli, uygulama içerisine alınacak veriler ve bu veriler sonucunda kullanıcıya
gösterilecek veriler ayarlanmalıdır. Bunun için beyaz liste yapılmalı, eğer beyaz kiste uygulanamıyorsa kara liste uygulanmalıdır.
61. Web uygulamalarının girdi kontrolü sonucunda oluşabilecek her türlü doğru/yanlış yansımaları/çıktıları kullanıcıya doğrudan göstermek yerine her çıktı türü için önceden oluşturulmuş bir ortak hata sayfasına yönlendirilme yapılmalı ve bu hata sayfasında kullanıcıya herhangi bir detay verilmemelidir.
62. Web uygulamalarındaki bütün form alanlarında herhangi bir beklenmeyen/istenilmeyen kod veya harf enjeksiyonuna karşı, uygulamanın içinde/kodunda (uygulamanın sunucu-backend kısmında, yani web tarayıcısı üzerinden veya bir script üzerinden kullanıcı-frontend kısmında değil) beyaz liste (veya
duruma göre kara liste) mantığına dayalı filtrelemeler ve sıkılaştırmalar uygulanmalıdır. Örneğin:
• Command Injection, xss, sql injection gibi saldırılar için belli başlı karakterleri kara liste mantığıyla engellemesi veya encode edilmesi gibi.
• SQL injection için ek olarak arka tarafta “”prepared statement (Parameterized Queries)” kullanılması gibi.
• XSS önleme amacıyla kullanıcıdan aldığı verideki özel karakterleri HTML encode hale getirip kaydedilmesi gibi.
• Directory Traversal saldırılarına karşı uygulamanın çalıştığı dizinin dışına çıkma amacıyla “../”, “./.”, “../../../..” karakterleri veya aynı karakterlerin farklı encode edilmiş versiyonlarını içeren bir isteğin uygulamaya gelmesi durumunda istek engellenmesi gibi.
63. Web uygulamalarında duruma göre CSP başlığı (Content Security Policy) kullanılması tavsiye edilir. Örneğin, en basit haliyle: “ContentSecurityPolicy: defaultsrc 'self'; reporturi /cspreport”.
64. Web uygulamalarında CSV ve Excel tipinde dışarıya dosya çıkarma (data export) durumlarında “,” ve “=” karakterleri kullanılmamalıdır.
65. Web uygulamaların kaynak kodlarındaki hidden form parametreleri HMAC’li (SHA256) veya kriptolanmış olarak yazılmalıdır.
66. Cross-Origin Resource Sharing (CORS) başlıkları “*” yıldızlı olarak değil, sadece ilgili hedeflerdeki kaynakları kullanabilecek şekilde ayarlanmalıdır.
67. Web uygulamalarında Same-Origin Policy kullanılması tavsiye edilir.
68. Web uygulamalarında Subresource Integrity (SRI) kullanılması tavsiye edilir
69. Web uygulamasında bir “rate limiting” olmalı, bir kullanıcı bir fonksiyonu limitsiz bir şekilde kullanamamalıdır.
70. Web uygulamaları Cross-Site Request Forgery (XSRF/CSRF) açıklığının önüne geçmek amacıyla açılan her yeni oturum için farklı olacak şekilde bir anti-forgery token oluşturmalıdır. Bu anti-forgery token gizli parametre olarak web uygulamasındaki form alanlarında bulunmalıdır. Yapılacak olan her form isteğinde bu gizli parametre iletilmelidir.
71. Anti forgery token en az 128 bit uzunluğunda olmalı ve rastgele oluşturulmalıdır. Bu anti forgery token tek kullanımlık olmalıdır.
72. Web uygulamasında şifresiz “viewstate” kullanılmamalıdır.
73. Web uygulaması dosya yükleme işleminin yapıldığı formlarda kesinlikle “.php”, “.aspx” gibi uzantıları kabul etmemelidir.
74. Web uygulamasında dosya kabul eden (user uploads) formlar için dosya uzantısı, boyut, tip kontrolleri istemciler üzerinden scriptler yoluyla değil, uygulamanın kaynağında sunucu tarafında yapılmalıdır. Dosya yüklenen ilgili dizinlere dosya boyutu ve formatı sınırlaması getirilmelidir.
75. Web uygulamalarında clickjacking saldırılarına karşı “X-Frame-Options DENY” başlığı
etkinleştirilmelidir. Eğer başka bir uygulamada iframe/frame olarak kullanım söz konusu olacak da “X- Frame-Options SAMEORIGIN” kullanılmalıdır.
76. Web uygulamalarında XSS koruması için “X-XSS-Protection "1; mode=block"” başlığı eklenmelidir.
77. Web tarayıcılarının MIME Type sniffing yapılarak içerik tipinin belirlenmesini veya karar verilmesini engellemek için “X-Content-Type-Options nosniff” başlığı kullanılmalıdır.
10 Süreklilik – Sistem Sürekliliği
TABA, SPK tarafından 05.01.2018 tarih 30292 sayılı Resmi Gazete’de yayınlanarak yürürlüğe giren Bilgi Sistemleri Yönetimi Tebliğiii ve Bilgi Sistemleri Bağımsız Denetim Tebliğiiii kapsamındadır.
Bilgi Sistemleri Yönetimi Tebliği ile;
Bilgi sistemlerinin yönetimine ilişkin usul ve esaslar belirlenmiş olup, kapsam dahilindeki kurum, kuruluş ve ortaklıkların;
• Bilgi sistemleri stratejilerinin iş hedefleriyle uyumlu olması, bilgi sistemlerinin güvenliğini, etkinliğini ve sürekliliğini sağlamak için gerekli kaynakları tahsis etmesi, bilgi sistemleri yönetimine ilişkin politika, süreç ve prosedürleri tesis etmesi,
• Üst yönetiminin; kritik bilgi sistemleri projelerini gözden geçirme ve onaylama, bilgi sistemlerine ve süreçlerine ilişkin potansiyel riskleri etkileriyle birlikte tespit etme ve bu çerçevede risk yönetimini gerçekleştirme, bilgi güvenliği ihlallerini izleme ve değerlendirme ve iş sürekliliği planının
hazırlanmasını sağlama sorumluluğu,
• Bilgi sistemlerine ilişkin belirli aralıklarla sızma testleri yaptırması,
• Bilgi sistemleri aracılığıyla edindiği veya sakladığı müşteri bilgilerinin gizliliğini sağlamaya yönelik kontrolleri tesis etmesi,
• Faaliyetlerini destekleyen bilgi sistemlerinin sürekliliğini sağlamak üzere bilgi sistemleri süreklilik
planını hazırlaması ve bu çerçevede ikincil sistemlerini tesis etmesi, birincil ve ikincil sistemlerini yurt içinde bulundurması
düzenlenmiştir.
Bilgi Sistemleri Bağımsız Denetim Tebliği TDUB’yi ilgilendiren kapsam dahilinde;
Diğer Sermaye Piyasası Kanunu’na tabi kurum, kuruluş ve ortaklıklar için ise, bilgi sistemleri yönetim ilkelerine uyum öngörülmekle birlikte, bu aşamada bilgi sistemleri bağımsız denetimi yaptırma yükümlülüğü
getirilmemiştir.
TABA Projesi aşağıda belirtilen “Tarihler” ile uygulamaya geçen ilgili tebliğlerin belirttiği yükümlüklerini sağlamalıdır.
Sistem sürekliliği için “Birincil Sistem” olarak değerlendirilen mevcut PROD ortamının hem donanım hem de TABA bileşenleri ve depolaman veri, dosya vb. ile birlikte mevcut hizmet lokasyonlarında oluşabilecek elektrik kesintisi, arızası, sel baskını, deprem veya daha farklı ancak toplu bir kesintiye sebep olması durumunda tüm
sistemlerin veya kritik sistemlerin bir kopyasının tutulduğu ve böyle bir felaket anında otomatik veya elle ayağa kaldırılan bir mekan - alt yapıya sahip olmalıdır. Belirtilen altyapı “İkincil Sistem” olarak değerlendirilmekte ve mevcut PROD ortamında bir kesinti olması halinde, mevcut faaliyetlerin iş sürekliliği planında belirlenen kabul edilebilir kesinti süreleri içerisinde sürdürülür hale getirilmesini ve TDUB ile ilgili tanımlanan sorumlulukların yerine getirilmesi açısından gerekli olan bütün bilgilere kesintisiz ve istenildiği an erişilmesini sağlayan birincil sistem yedeklerini içeren Olağan Üstü Durum Merkezi olarak tanımlanmaktadır.
Başta Olağan Üstü Durum Merkezi olmak üzere diğer ayrıntılar DETAY ANALİZDE belirlenecektir.
i Web Kullanıcı Arayüzü (TS EN ISO 9241-151) İnsan-Sistem Etkileşiminin Ergonomisi xxxxx://xxx.xxx.xxx.xx/XxxxxxXxxxx?XXx000
ii Sermaye Piyasası Kurulundan: BİLGİ SİSTEMLERİ YÖNETİMİ TEBLİĞİ xxxxx://xxx.xxxxxxxxxxx.xxx.xx/xxxxxxx/0000/00/00000000-0.xxx
iii Sermaye Piyasası Kurulundan: BİLGİ SİSTEMLERİ BAĞIMSIZ DENETİM TEBLİĞİ xxxxx://xxx.xxxxxxxxxxx.xxx.xx/xxxxxxx/0000/00/00000000-0.xxx