Bu sitede bulunan yazılar memnuniyetsizliğiniz halınde olursa bizimle iletişime geçiniz ve o yazıyı biz siliriz. saygılarımızla

    bcp giriş akışında doldurulması gereken alanlar

    1 ziyaretçi

    bcp giriş akışında doldurulması gereken alanlar bilgi90'dan bulabilirsiniz

    Bilgi Güvenliği Bakış Açısı İle İş Sürekliliği

    Bilgi Güvenliği Bakış Açısı İle İş Sürekliliği

    A) İş Sürekliliği Planı (Business Contiunity Plan – BCP)

    İş Sürekliliği Planlaması’nın genel amacı, kuruluşun bir felaket olayının yaşanmasından önce, bu süre boyunca ve sonrasında hizmet vermeye devam etmesini sağlamaktır. İş Sürekliliği Planlaması sürecinin temel amaçları aşağıdaki gibi sıralanabilir.

    İş sürekliliği bozulup,iş süreçleri durursa ve organizasyon disaster moda geçerse BCP sürecinin başarısız olduğu anlaşılır. Bu durumda da Disaster Recovery Planning (DRPFelaket Kurtarma Planı) devreye girer.

    İş sürekliliği planının alt kırılımları aşağıdaki gibi listelenebilir.

    Her iki plan da kuruluşun karşılaştığı yıkıcı olayların yönetimi için gerekli olsa da hedefleri farklıdır.

    İş Sürekliliği Planlaması yıkıcı bir olaydan sonra devam eden operasyon (iş / business) için uzun vadeli ve iş odaklı bir plan sağlarken, Felaket Kurtarma Planı belirli aksaklıklarla başa çıkmak için kısa vadeli bir plan sağlar.

    Felaket Kurtarma Planı bir felaketin etkisini etkili bir şekilde azaltmaya, önemli bir yıkıcı olay karşısında kritik BT sistemlerine anında müdahele etmeye ve kurtarmaya çalışır. Günümüzde bazı işlerde (business), DRP’ye ihtiyaç duyulmayabilir, hatta dış kaynağa devredilebilir.

    DRP süreci BCP’nin bir alt kümesidir.

    BRP ve DRP süreçleri ile ilgili olarak bir barajın üzerinde bulunan veri merkezi örneğini ele alabiliriz. Şöyle ki;

    BCP süreçleri uygulanarak belediyenin baraj üzerinde bulunan veri merkezi üzerindeki bakım faaliyetlerinin yapılıp yapılmadığı test edilir. Veri merkezi için alınan önlemler BCP kapsamındadır. Tüm alınan önlemlere rağmen veri merkezi su altında kalarak sistem hizmet veremez hale gelebilir ve DRP sürecine geçilir.

    Bir kuruluşun başına bir çok felaket gelebilir.

    Gelebilecek bu felaketler ile ilgili detaylı bilgi için kaynaklardaki Siberportal bağlantısı [ii] incelenebilir.

    B) İş Sürekliliği Planlama Süreci Adımları

    BCP’nin genel hedefi acil bir durumda hızlı, sakin ve verimli bir yanıt sağlamak ve kuruluşu bir felaket durumundan kurtarma yeteneğini hızlı bir şekilde artırmaktır.BCP sürecinin 4 ana adımı vardır .

    Kurumlarda güçlü bir iş sürekliliği planı için bir takım çalışmalar yapılmalıdır. Bu çalışmalar aşağıdaki gibi sıralanabilir.

    Not: Bazı organizasyonların resmi bir BCP süreci bulunmamaktadır. Beklenmedik bir acil durum karşısında “seat-of-the-pants” yaklaşımının işe yarayacağı düşünülür. “Seat-of-the-pants” yaklaşımı, herhangi bir karar alma durumunda, analitik yöntemler ve araçları kullanmak yerine sezgi ve hisler ile hareket etme durumudur.

    BIA aşamasında iş sürekliliği için ilk olarak kritik olan kaynaklar belirlenir ve bu kaynaklara yönelik tehditler tanımlanır.

    Her tehdidin gerçekleşme olasılığı ve iş üzerindeki etkisi değerlendirilir. Değerlendirme sonuçları kaynakların karşı karşıya olduğu yerel, bölgesel ve ulusal risklere karşı önlem alınmasını sağlar.

    İş Sürekliliği ile ilgili plan yaparken 2 farklı analiz türü vardır.

    BCP ekibi için sayısal verilerle ilerlenmesi ve nicel değerlendirme yapması önerilir.

    BIA aşaması aşağıdaki gibi 5 adımdan oluşur.

    İş-etki değerlendirmesi yaparken BCP ekibinin ilk görevi işler için öncelik listesi hazırlamaktır.

    BCP’nin ikinci görevi maksimum tolere edilebilir kesinti süresini belirlemektir. (MTO/MTD)

    MTD = RTO + WRT

    Bu adımdaki temel amaç, RTO’nun MTD’den daha düşük olmasını sağlamaktır.

    Kurumda ortaya çıkan risklerin tanımlanması gerekmektedir.

    BCP ekibi tarafından bir kuruluş için tehdit oluşturabilecek olayların kapsamlı bir listesini hazırlanmalıdır. Risk tanımlama kısmı nitelikseldir (qualitative). Daha belirsiz risklerin tanımlanması BCP ekibinin yaratıcılığına bağlıdır.

    Her tehdidin gerçekleşme olasılığı birbirinden farklıdır.

    Her bir risk için organizasyonun bu riski yaşamayı ne kadar beklediğini (her tehdidin tek bir yıl içinde gerçekleşme olasılığını) yansıtan ARO (Annualized Rate of Occurrence) belirlenmelidir. ARO kurumsal geçmişe, BCP ekip üyelerinin mesleki deneyimine ve gerektiğinde sismolog, yangın önleme uzmanları ve diğer danışmanların tavsiyelerine göre belirlenir.

    Bazı durumlarda, bazı riskler için uzmanlar tarafından hazırlanan olasılık değerlendirmeleri bulunabilir. Aşağıdaki deprem tehlike haritası bu depremlerin ARO’sunu göstermektedir.

    ARO kavramı ve BT risk Yönetimi ile ilgili detaylı bilgi için kaynaklardaki Siberportal bağlantısı [i] incelenebilir.

    Risk tanımlama ve olasılık değerlendirmesi yapıldıktan sonra toplanan veriler analiz edilerek tanımlanan risklerin gerçekleşmesi durumunda kuruma ne gibi bir etkisi olacağı hesaplanmalıdır.

    Bu değerlendirme, The exposure factor (EF), The single loss expectancy (SLE) ve The annualized loss expectancy (ALE) metrikleri ile yapılır. EF, SLE, ALE ve diğer değerlendirme metrikleri ile ilgili detaylı bilgi için kaynaklardaki Siberportal bağlantısı [i] incelenebilir.

    Nitel (Qualitative) bir değerlendirme yapılırsa aşağıdaki faktörler göz önüne alınabilir

    İş sürekliliği kaynaklarının daha önce tanımlanan risklere tahsis edildiği aşamadır. Yukarda analiz edilen tüm risklerin bir listesi çıkarılır ve ALE’ye göre sıralanarak öncelikli risk listesi hazırlanır.

    Bu liste üzerinde hangi riske nasıl bir kaynak hacanacağı ile ilgili bir çalışma yapılır.

    Bu çalışmada nitel (qualitative) ve nicel (quantitative) analiz kullanılır. BCP ekibi ve üst yönetim temsilcileri ile görüşülerek, nitel ve nicel analizler neticesinde risklerin önceliği azaltılabilir ya da artırılabilir.

    Risklerin korunan varlıklar üzerindeki etkisini en aza indirmek için bir süreklilik stratejisi geliştirilir ve uygulamaya konulur. Süreklilik planlaması ile ilgili yapılması gerekenler aşağıdadır.

    Bu aşamada daha önce oluşturulan MTD tahminlerine göre hangi risklerin kabul edilebilir olduğu ve hangi risklerin azaltılması gerektiği belirlenmelidir.

    Örnek olarak Mısır’daki bir operasyon tesisine çarpan bir kar fırtınası göz ardı edilebilir ve risk kabul edilebilir.

    Bu aşamada, strateji geliştirme aşamasında kabul edilemez olarak tanımlanan riskleri azaltacak prosedürler ve mekanizmalar tasarlanır.

    BCP süreci çerçevesinde 3 varlık kategorisi korunmak zorundadır.

    Plana katılacak tüm personel genel plan ve bireysel sorumluluklar ile ilgili doğrudan ve dolaylı olarak bir eğitim almalıdır.

    Kuruluştaki tüm çalışanlar iş sürekliliği planından haberdar olmalıdır.

    Doğrudan BCP sorumlulukları olan kişiler, yıkıcı bir olay sırasında görevlerini etkin bir şekilde tamamlayabilmeleri için özel BCP görevleri konusunda eğitilmelidir.

    Ayrıca, bir acil durum sırasında personelin yaralanması veya işyerine ulaşamaması durumunda işlerin devamlılığını sağlamak için her BCP görevi için en az bir yedek kişi belirlenmeli ve eğitim alması sağlanmalıdır.

    BCP’nin tasarım aşaması tamamlandıktan sonra, planlama ile ilgili üst yönetimden onay alınmaldır. Planın üst düzey yönetici tarafından imzalanması, tüm organizasyon için önemini gösterir ve üst yönetimin iş sürekliliğine olan bağlılığını ortaya koyar.

    Üst yönetimden onay alındıktan sonra, belirtilen hedeflere ulaşmak için programa ayrılan kaynaklar kullanılarak plan uygulamaya konulur. BCP ekibi, gelişen iş ihtiyaçlarına cevap verilmesini sağlamak için bir BCP bakım planı oluşturulmalı ve denetimler yapmalıdır.

    C) İş Sürekliliği Planı Dokümantasyonu

    İş sürekliliğinin işletilmesi için bir takım dokümanların hazırlanması gerekir. Gerçekleştirilecek dokümantasyonun sağlayacağı başlıca yararlar aşağıdaki gibi sıralanabilir.

    Yazılı bir iş sürekliliği planı dokümantasyonunun içermesi gereken bileşenler aşağıdaki gibidir.

    BCP ekibi periyodik olarak toplantılar yaparak değişen organizasyonel ihtiyaçlara cevap verilip verilmediğini test etmelidir. BCP deki her değişikllikte sürüm kontrolü yapılmalı ve eski sürümler imha edilerek yeni sürümle değiştirilmelidir.

    İş sürekliliği planı, çeşitli sebepler ile gözden geçirilebilir. Bu sebeplerden bir kısmı aşağıdaki gibi sıralanabilir:

    İş sürekliği planı dokümanları, Prod (Canlı) ortamda veya iş kritik IT ortamında bir değişiklik gerçekleştiğinde, her bir alıştırma / tatbikat (exercise) sonrasında, yapılandırma (configuration) ve değişiklik (change) yönetimi süreçleri sırasında ele alınarak güncellenir.

    D) SSAE-16 Standardı ve SOC Raporları

    Sistemlerin dış kaynaklarla ilişkili risklerini değerlendirmek için varsayılan olarak yılda (12 ayda) bir SOC (Service Organization Control) Raporları hazırlanabilir. Bu raporlarla ilgili standartlar The American Institute of Certified Public Accountants (AICPA) tarafından SSAE-16 (Standards for Attestation Engagements) adı ile oluşturulmuştur ve ISAE- 3402 standardı ile uyumluluk sağlanmış olur.

    SSAE- 16 standardı çerçevesinde, destek hizmeti sunmakta olan şirketlerin kendi denetçileri tarafından, şirket içindeki denetimlere yönelik olarak düzenlenecek raporlar üçe ayrılmaktadır.

    https://www.amazon.com/CISSP-All-One-Guide-Eighth-ebook/dp/B07J1JQSJY

    [i] https://www.siberportal.org/blue-team/compliance-auditing/bilgi-guvenligi-bakis-acisi-ile-bt-risk-yonetimi#NicelRiskAnalizi
    [ii] https://www.siberportal.org/white-team/governance/bilgi-guvenligi-bakis-acisi-ile-site-ve-tesis-planlama#tehdit-turleri
    https://security-times.net/business-continuity-planning


    https://www.oreilly.com/library/view/cissp-isc2-certified/9781119042716/


    https://www.linkedin.com/pulse/sas-70-ssae-16-isae-3402-denetimlere-ili%C5%9Fkin-okan-altunakar/?articleId=7798402763571567745

    Yazı kaynağı : www.siberportal.org

    Bankacılıkta veri yönetimi

    Bankacılıkta veri yönetimi

    Günümüzde bankalar, güvenlik duvarları içinde çok miktarda değerli bilginin güvenliğini sağlama ve depolama sorumluluğunu üstlemektedir. Bu bilgiler hem müşterileri hem de değişen finansal manzara hakkındadır. Çoğu durumda, verilerin kullanımı birden çok bankacılık etkinliğinde karar almayı geliştirebilse de, bu bilgiler kolayca erişilemediği veya aranamadığı için kullanılmaz.

    Bu verilerle bankalar, krediyi varsayılan olarak alma riski altında olan kişiler hakkında daha hızlı bilgi bulabilir. Bankalar ayrıca hangi piyasa portföyü değerleme ayarlamalarına ihtiyaç duyulduğuna da karar verebilir. Bankalar ayrıca yasal gereksinimleri karşılamak için verilerinin nasıl depolandığına ve yönetildiklerine ilişkin daha net bir görünüme sahip olabilir. Bu şekilde veriler uyumlu hale getirmek için kullanılabilir, saklanabilir, arşivlenebilir veya silinebilir.

    Günlük bankacılık işlev gereksinimlerini karşılamak için büyük ve küçük binlerce karar gereklidir. Sonuç olarak veriler giderek daha önemli hale gelir. Sadece bu değil, bankalara sıkı mevzuat gereksinimleri ve mali suç yükümlülükleri de verilir. Veri deposuna ilk giriş bilgilerine kadar tüm veri çözümleme işlemlerinin sonuçlarını denetleyebilmeleri gerekir. İzlenebilirlik, alımdan eyleme dönüştürülebilir veriler üretmeye kadar saydamlık gerektirir.

    Bankaların hizmet verdikleri birçok hesabı veya işletmeyi yönetmek için tüm bu verileri hızlı ve uygun maliyetli bir şekilde anlamaları gerekir. Bankalar dijital olarak olgunlaştıkça, veri miktarı ve bu verileri uygulamaya yönelik yeni fırsatlar katlanarak artmaktadır. Bu büyüme, bankaların yeni iş modellerini ve müşteri odaklı fırsatların alanlarını takip etmelerini sağlar.

    Uygun veri depolama stratejisinin geçerli olması, operasyonel verimlilikler, iyi uygulama performansı ve mevzuat uyumluluğu açısından önemlidir. Veri depolama stratejisi aynı zamanda verileri iş zekası ve eyleme dönüştürülebilir içgörüler için kullanılabilecek biçimlere getirmenin ilk lynchpin'idir.

    Veri yönetimi için yaygın bir desen aşağıda belirtilmiştir:

    Bu modelde "Veri Hizmetleri", verilerin dönüştürülmesi, birleştirilmesi veya arşivleme dışındaki diğer veri işlemlerini açıklar. Bu, daha bilinçli kararlar almaya yardımcı olmak için verilerden yararlanmak için gereken temel etkinliktir.

    Tüm bankalar ve finans kurumları verileri alır, taşır ve depolar. Bu makalede Azure'a veri getirmeye odaklanmaktadır. Çözüm, geleneksel şirket içi veri depolama, işleme, arşivleme ve silme işlemlerinden uzaklaşmanıza yardımcı olur. Bankalar ve finans kurumları verileri Azure'a taşıyarak aşağıdakileri içeren temel avantajlardan yararlanabilir:

    Bu makalede, Azure'a verimli veri girişi sağlamak için önerilen teknikler ve buluta girdikten sonra kullanılacak temel veri yönetimi teknikleri sağlanır.

    Veri alma

    Finansal Kurumlar, zaten toplanmış ve geçerli uygulamalar tarafından kullanılmakta olan verilere sahip olacaktır. Bu verileri Azure'a taşımak için çeşitli seçenekler vardır. Çoğu durumda mevcut uygulamalar Azure'daki verilere şirket içindeymiş gibi bağlanabilir ve mevcut uygulamalarda en az değişiklik yapılabilir. Bu işlem özellikle Microsoft Azure SQL Veritabanı kullanırken geçerlidir, ancak Oracle, Teradata, MongoDB ve diğerleri için Azure Market çözümleri bulunabilir.

    Verileri şirket içinden Azure'a taşımak için farklı veri geçiş stratejileri vardır ve farklı gecikme sürelerine sahiptir. Aşağıda başvuruda bulunılan tüm teknikler veri saydamlığı ve güvenilir güvenlik sağlar.

    Sanal Ağ (VNet) hizmet uç noktaları

    Müşteri finansal bilgileriyle ilgilenirken güvenlik öncelikli bir konudur. Azure'da kaynakların (veritabanı gibi) güvenliğini sağlamak genellikle Azure'ın içinde bir ağ altyapısı ayarlamaya ve ardından belirli bir uç nokta üzerinden bu ağa erişmeye bağlıdır.

    Verileri Azure'a aktarmadan önce, hem Azure kaynaklarınızın hem de şirket içinden bağlantınızın güvenliğini sağlamak için ağ topolojisini göz önünde bulundurmanız yararlı olur. Sanal Ağ hizmet uç noktaları, Azure tanımlı bir sanal ağa güvenli bir doğrudan bağlantı sağlar.

    Sanal ağlar, sınırlanmış bir sanal ağ içindeki Azure kaynaklarını içerecek şekilde Azure'da tanımlanır. Bu sanal ağın uç noktası, kritik Azure hizmet kaynaklarınıza ve yalnızca tanımlı VNet'te bulunanlara güvenli erişim sağlar.

    Veritabanı lift and shift

    Veritabanı geçişinin "lift and shift" modeli, Azure SQL Veritabanı kullanmaya yönelik en yaygın senaryolardan biridir. Lift and shift yalnızca mevcut şirket içi veritabanlarını alıp doğrudan buluta taşımak anlamına gelir. Bunu yapma nedenleri şunlardır:

    Daha küçük veritabanları söz konusu olduğunda, veri alımının ilk adımı genellikle Azure Portal, Azure CLI veya Azure SDK aracılığıyla gereken veri depolarını ve yapıları (tablolar gibi) oluşturmaktır. Bu küçük veri depoları için, doğru verileri uygun Azure veri depolama alanına kopyalamak için yazılmış özel bir uygulama tarafından sonraki adımlar gerçekleştirilebilir. Genellikle daha büyük veri geçişleri için en hızlı yol, Azure'da yedeklemeleri geri yüklemektir.

    Verileri güvenli ve hızlı bir şekilde Azure'a aktarmanın birçok yolu vardır. Avantajları ve dezavantajları olan bazı standart teknikler için bu makaleye bakın.

    Azure Veritabanı Geçiş Hizmeti

    SQL Server veritabanlarını kaldırırken ve kaydırırken Microsoft Azure Veritabanı Geçiş Hizmeti veritabanlarını Azure'a taşımak için kullanılabilir. Hizmet, şirket içi veritabanınızın Azure SQL'de sunulan özelliklerle uyumlu olmasını sağlamak için Data Migration Yardımcısı kullanır. Veritabanını geçirmeden önce yapılması gereken değişiklikler size göre değişir. Ayrıca, hizmetin kullanılması için şirket içi ağ ile Azure arasında Siteden Siteye İnternet bağlantısı gerekir.

    SQL Server için toplu kopyalama programı (BCP)

    SQL Server bugün şirket içindeyse ve hedef SQL Azure geçmekse, bir diğer harika teknik de verileri SQL Azure taşımak için SQL Server Management Studio ve BCP yardımcı programını kullanmaktır. Özgün şirket içi sunucudan betik oluşturup Azure SQL veritabanları oluşturduktan sonra BCP, verileri hızla Azure SQL aktarmak için kullanılabilir.

    Azure Blob ve Dosya depolama

    Tek tek banka şubelerinin genellikle yerel şirket içi sunucularda kendi dosya depoları vardır. Bu, dallar arasında dosya paylaşımıyla ilgili sorunlara neden olabilir ve belirli bir dosya için tek bir gerçek kaynağına sahip olmamasıyla sonuçlanabilir. Daha da kötüsü, kuruluşun erişimi dallayan bir "resmi" dosya deposu olabilir, ancak aralıklı bağlantı veya dosya paylaşımına erişme konusunda başka sorunları olabilir.

    Azure'ın bu sorunları azaltmaya yardımcı olacak hizmetleri vardır. Bu verileri Azure'a taşımak, merkezi izinler ve erişim denetimleriyle tüm veriler ve evrensel olarak erişilebilir depolama için tek bir gerçeklik kaynağı sağlar.

    Farklı veri depolama çözümleri belirli veri biçimleri için daha uygun olabilir. Örneğin, SQL Server'da şirket içinde depolanan veriler büyük olasılıkla Azure SQL için en uygun olandır. .csv veya Excel dosyalarında depolanan veriler, Blob hizmetinin üzerinde uygulanan Azure Blob depolama veya Azure Dosyalar depolama için büyük olasılıkla en uygun olanıdır.

    Azure'a girip çıkan neredeyse tüm veriler, verilerin hareketinin bir parçası olarak Blob depolamadan geçer. Blob depolama aşağıdaki sütunlara sahiptir.

    Azure'da tüm dalları aynı dosya paylaşımına bağlama işlemi genellikle Şekil 1'de gösterildiği gibi bankanın mevcut veri merkezi aracılığıyla yapılır. Şirket veri merkezi bir SMB (Sunucu İleti Bloğu) bağlantısı aracılığıyla Dosyalar depolamaya bağlanır. Mantıksal olarak ve site ağının bakış açısından, dosya paylaşımı kurumsal veri merkezinde olabilir ve başka bir ağa bağlı dosya paylaşımı olarak bağlanabilir. Bu tekniği kullandığınızda veriler beklemede ve veri merkezi ile Azure arasında aktarım sırasında şifrelenir.

    Şekil 1

    Kuruluşlar genellikle büyük hacimli dosyaları birleştirmek ve güvenliğini sağlamak için Dosya depolamayı kullanır. Bu, eski dosya sunucularının eskisini kaldırmaya veya donanımı yeniden kullanmanıza olanak tanır. Dosya depolamaya geçmenin bir diğer avantajı da veri yönetimi ve kurtarma hizmetlerini merkezileştirmektir.

    Azure Data Box

    Genellikle bankalar, Azure'a getirilecek bilgileri petabaytlar olmasa da terabaytlar halinde alır. Neyse ki Azure'daki veri depoları çok esnek ve yüksek oranda ölçeklenebilir.

    Çok büyük hacimli verileri Azure'a geçirmeye odaklanan bir hizmet , Azure Data Box'tır. Bu hizmet, azure bağlantısı üzerinden veri aktarmadan veya yedekleme yapmadan verileri geçirmek için tasarlanmıştır. Terabaytlarlık veriler için uygun olan Azure Data Box, Azure portal sipariş edilebilen bir gereçtir. Konumunuza gönderilir, burada ağınıza bağlanabilir ve standart NAS protokolleri aracılığıyla verilerle yüklenebilir ve standart256-AES şifrelemesi ile güvenli hale getirilebilir. Veriler alete eklendikten sonra verilerin Azure'da nemlendiği Azure Veri Merkezi'ne geri gönderilir. Cihaz daha sonra güvenli bir şekilde silinir.

    Azure Information Protection

    Azure Information Protection (AIP), kuruluşların belgelerini ve e-postalarını sınıflandırmasına, etiketlemesine ve korumasına yardımcı olan bulut tabanlı bir çözümdür. Bu işlemler, kural ve koşulları tanımlayan yöneticiler tarafından otomatik olarak, kullanıcılar tarafından el ile ya da kullanıcılara önerilerin sunulduğu bir düzenle gerçekleştirilebilir.

    Veri hizmetleri

    Bankalar Ana Veri Yönetimi, farklı çekirdek bankacılık sistemlerinden kaynaklanan meta veri çakışmaları ve kaynak sistemleri, ekleme sistemleri, yönetim sistemleri, CRM sistemleri ve daha birçok farklı kaynaktan gelen verilerle mücadele ediyor. Azure'da bu ve yaygın olarak karşılaşılan diğer veri sorunlarını azaltmaya yardımcı olacak araçlar vardır.

    Kuruluşların verileri üzerinde gerçekleştirmesi gereken birçok operasyon finansal hizmeti vardır. Azure veri depolarına veri yazdığınızda, bu verileri dönüştürmeniz veya alınan verileri genişleten diğer verilerle birleştirmeniz gerekebilir.

    Azure Data Factory

    Microsoft Azure Data Factory, Data Factory işlem hattında veri hareketinin girişi, işlenmesi ve izlenmesine yardımcı olan tam olarak yönetilen bir hizmettir. Data Factory etkinlikleri, veri yönetimi işlem hattının yapısını oluşturur.

    Data Factory, Azure'a akıp diğer Azure hizmetleri arasında veri dönüştürmeye veya artırmaya olanak tanır. Data Factory karmaşık karma ayıklama-dönüştürme-yükleme (ETL), ayıklama-yükleme-dönüştürme (ELT) ve veri tümleştirme projeleri için oluşturulmuş yönetilen bir bulut hizmetidir.

    Örneğin, veriler eyleme dönüştürülebilir içgörülere neden olan analiz işlem hatlarına veya araçlara aktarılabilir. Veriler bir makine öğrenmesi çözümüne akabilir veya daha sonra aşağı akış işleme için başka bir biçime dönüştürülebilir. Örnek olarak .csv dosyaları, makine öğrenmesi sistemleri için daha uygun olan parquet dosyalarına dönüştürme ve bu parquet dosyalarını Blog depolama alanında depolama verilebilir.

    Veriler Azure HDInsight, Spark, Azure Data Lake Analytics ve Azure Machine Learning gibi aşağı akış işlem hizmetlerine de gönderilebilir. Bu, analiz ve akıllı raporlama ile sonuçlanan sistemlerin doğrudan beslenmesine olanak tanır. Veri girişi için yaygın bir model aşağıdaki Şekil 2'de gösterilmiştir. Veriler, aşağı akış analiz hizmetleri tarafından kullanılacak ortak bir Data Lake'te tutulur.

    Şekil 2

    Data Factory işlem hatları, veri kümelerini alan ve çıkış yapan etkinliklerden oluşur. Etkinlikler, verilerinizi nereden almak istediğinizi, nasıl işlenmesini istediğinizi ve sonuçları nerede depolamak istediğinizi tanımlayan bir işlem hattında birleştirilebilir. Etkinliklerle işlem hatları oluşturmak Data Factory'nin merkezinde yer alır ve doğrudan Azure portal görsel bir iş akışı oluşturmak işlem hattı oluşturmayı kolaylaştırır. Etkinliklerin tam listesi için buraya bakın .

    Azure Databricks

    Azure Databricks, Azure'da yönetilen bir Apache Spark tabanlı analiz platformudur. Yüksek oranda ölçeklenebilir ve Spark işleri makine kümelerinde gerektiği kadar büyük çalışır. Databricks, veri bilimcileri, veri mühendisleri ve iş analistleri arasında tek bir işbirliği yeri sağlayan bir Not Defteri'nden çalışır.

    Databricks, veri dönüştürme veya analiz gerektiğinde mantıksal bir işlem hattıdır. İçgörüler arası zamanın kritik olduğu makine öğrenmesi senaryoları veya basit dosya dönüşümleri için doğrudan Data Factory tarafından beslenebilir.

    Veri arşivleme

    Etkin bir veri deposunda artık verilere ihtiyaç duyulmadığında, eyalet ve yerel bankacılık düzenlemelerine uygun olarak uyumluluk veya denetim kaydı nedeniyle arşivlenebilir. Azure,seyrek erişilen verilerin depolanması için kullanılabilir seçeneklere sahiptir. Verilerin yıllarca depolamada tutulmasını gerektiren verilerde genellikle gizlilik sorunları vardır.

    Veri depolama maliyetleri, özellikle şirket içi veritabanlarında depolandığında yüksek olabilir. Bu veritabanlarına bazen seyrek erişilir ve yalnızca yeni arşivlenmiş veriler yazmak veya veritabanından arşivde artık istenen verilerden kurtulmak için kullanılır. Şirket içi makinelere seyrek erişim, donanımın sahip olma maliyetinin daha yüksek olduğu anlamına gelir.

    Azure Arşiv Depolama

    Azure, dosyalar veya görüntüler gibi yapılandırılmamış veriler için Sık erişimli, seyrek erişimli ve arşiv gibi Blob depolama için çeşitli depolama katmanları sunar. Sık erişim katmanı, etkin olan ve en yüksek performansa sahip olması beklenen ve uygulamalarda kullanımda olan veriler içindir. Seyrek erişim katmanı, kısa süreli yedekleme ve olağanüstü durum kurtarma veri kümelerinin yanı sıra bir uygulama için kullanılabilen ancak nadiren erişilen veriler içindir. Arşiv katmanı en düşük maliyete sahiptir ve çevrimdışı veriler için tasarlanmıştır.

    Arşiv katmanı verileri seyrek erişimli veya sık erişimli katmanlarda yeniden doldurulabilir, ancak bu eylemin tamamlanması birkaç saat sürebilir. Verilerinize en az 180 gün boyunca erişilmeyecekse arşiv depolama uygun olabilir. Bir blob arşiv depolama alanındayken okunamaz, ancak meta verileri listeleme, silme ve alma gibi diğer mevcut işlemler gerçekleştirilebilir. Arşiv veri katmanı, blob depolama için en düşük maliyetli veri katmanıdır.

    Azure SQL Veritabanı uzun süreli saklama

    Azure SQL kullandığınızda, yedeklemeleri on yıla kadar depolamak için uzun süreli bir yedekleme bekletme hizmeti vardır. Kullanıcılar, yedeklemenin haftalar, aylar, hatta yıllar boyunca saklanması için uzun süreli depolama için yedekleri zamanlayabilir.

    Veritabanını uzun süreli depolama alanından geri yüklemek için zaman damgasına göre belirli bir yedeklemeyi seçin. Veritabanı, özgün veritabanıyla aynı abonelik altındaki mevcut bir sunucuya geri yüklenebilir.

    İstenmeyen verileri silme

    Veri saklama ile ilgili bankacılık düzenlemelerine veya ilkelerine uyumlu kalmak için, veriler artık istenmiyorsa genellikle silinmelidir. Bu istenmeyen veriler için teknik bir çözüm uygulamadan önce, ilkeler ihlal edilmeyecek şekilde üzerinde anlaşmaya varılan bir temizleme planının uygulanması önemlidir. Veriler arşivden veya Azure'daki diğer veri depolarından herhangi bir zamanda silinebilir.

    İstenmeyen verileri silmek için etkili bir strateji, bunu en yaygın olan gecelik veya haftalık aralıklarla yapmaktır. Bu işi iyi gerçekleştirmek için zaman ile tetiklenen bir Azure İşlevi yazılabilir. Herhangi bir veriyi silerseniz, Microsoft Azure önbelleğe alınmış veya yedek kopyaları da dahil olmak üzere verileri siler.

    Başlarken

    Bugün kullanılan veri modellerinin geçerli kullanımına ve olgunluğuna göre çalışmaya başlamanın birçok yolu vardır. Her durumda, veri depolamayı, işlemeyi ve veri deposu başına gereken saklama modelini gözden geçirmek için mükemmel bir zamandır. Bu adım, mevzuat uyumluluğu senaryolarında veri yönetimi sistemlerinin oluşturulmasında kritik öneme sahiptir. Bulut burada, şu anda şirket içinde mevcut olmayan yeni fırsatlar sunar. Bu, sahip olabileceğiniz mevcut veri modellerinde güncelleştirmeler anlamına gelebilir.

    Yeni veri modeline alıştıktan sonra veri alımı stratejinizi belirleyin. Hangi veri kaynakları var? Veriler Azure'da nerede kalacak? Azure'a nasıl ve ne zaman taşınacak? Burada içerik türüne, boyutuna ve daha fazlasına göre geçişe yardımcı olacak birçok kaynak vardır. Azure Veri Geçiş Hizmeti bu tür örneklerden biridir.

    Verileriniz Azure'da barındırıldıktan sonra, kullanım ömrü veya kullanım süresi dolmuş veriler için bir veri temizleme planı oluşturun. Uzun süreli (soğuk) depolama her zaman arşivleme için harika bir seçenek olsa da, süresi dolan verilerin temizlenmesi ayak izini ve genel depolama maliyetlerini azaltır. Azure çözüm mimarilerini yedekleme ve arşivle, genel stratejinizi planlamanıza yardımcı olacak iyi kaynaklardır.

    Bileşenler

    Aşağıdaki teknolojiler bu çözümle ilgilidir:

    Sonuç

    Bankacılık ve finans sektörü için dijital ortamın hızla değişmesiyle, müşteriler yavaş bir artış süresi olmadan hemen kullanabilecekleri çözümlere ve iş ortaklarına giderek daha fazla bakıyor. Veri alımı katlanarak arttıkça bankaların önemli verilerini depolamak, analiz etmek ve kullanmak için hızlı, yenilikçi ve güvenli yollara ihtiyacı vardır.

    Azure çeşitli teknolojileri ve stratejileri kullanarak veri alımı, işleme, arşivleme ve silme gereksinimlerine yardımcı olabilir. Verileri Azure'a almak basittir ve türüne, yapısına vb. bağlı olarak verileri depolamak için çeşitli veri depoları kullanılabilir. Veri çözümleri, SQL Server ve SQL Azure ötesinde 3. taraf veritabanlarını içerecek şekilde kullanılabilir.

    Databricks ve Data Factory gibi Azure hizmetlerini kullanarak bu veriler üzerinde işlem ve işlem gerçekleştirme basit olabilir. Arşiv depolama, nadiren erişilen verilerin uzun süreli depolaması için kullanılabilir ve gerektiğinde sıralı bir döngüde silinebilir.

    Katkıda Bulunanlar

    Bu makale Microsoft tarafından güncelleştiriliyor ve korunuyor. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

    Asıl yazarlar:

    Sonraki adımlar

    Veri yönetimi planınızı tasarlamaya başlamak için yedekleme ve arşiv depolama için Azure çözümleri kitaplığını ziyaret edin.

    Ürün belgeleri:

    Yazı kaynağı : docs.microsoft.com

    Tablo Değerli Parametreler

    Divit by yasemin toprak

    Yorumların yanıtı sitenin aşağı kısmında

    Ali : bilmiyorum, keşke arkadaşlar yorumlarda yanıt versinler.

    Yazının devamını okumak istermisiniz?
    Yorum yap