Database Firewall Nedir ve Neden Kritik Bir İhtiyaçtır?Günümüzde siber saldırılar artık sadece çevre güvenliğini (Network Perimeter) aşmayı değil, doğrudan organizasyonların en değerli varlığı olan veriye ulaşmayı hedefliyor. Klasik ağ güvenlik duvarları (Firewall) veya Web Uygulama Güvenlik Duvarları (WAF) harika işler çıkarsa da, konu veri tabanının derinliklerine inen karmaşık ve içeriden gelen tehditler olduğunda yetersiz kalabiliyorlar.İşte tam bu noktada devreye Database Firewall (Veri Tabanı Güvenlik Duvarı) giriyor.Database Firewall, veri tabanı sunucularınızın hemen önünde konuşlanan, gelen ve giden tüm SQL trafiğini satır satır inceleyen özelleşmiş bir güvenlik çözümüdür.Temel görevi; veri tabanına yöneltilen sorguları analiz etmek, yetkisiz erişimleri engellemek ve veri tabanının “normal” davranış profilini çıkararak bu profilin dışına çıkan şüpheli aktiviteleri gerçek zamanlı olarak bloke etmektir. Bir anlamda, verilerinizin kapısındaki en titiz korumadır.Veri tabanı güvenlik duvarları, sadece “büyük ölçekli” şirketlerin lüksü değil, kritik veri işleyen her yapının standart siber güvenlik mimarisinin bir parçası olmalıdır.SQL Injection (SQLi) Tehditlerine Karşı Kesin ÇözümWAF çözümleri bilinen SQL Injection kalıplarını durdurabilir. Ancak saldırganlar obfuscation (kod gizleme) teknikleri veya sıfırıncı gün (Zero-Day) açıklarıyla web katmanını geçebilir. Database Firewall, sorguyu doğrudan veri tabanına ulaşmadan hemen önce “veri tabanının anladığı dilde” analiz ettiği için, uygulama katmanını aşan anomalileri yakalar ve durdurur.İç Tehditlerin (Insider Threats) EngellenmesiSiber güvenlik olaylarının azımsanmayacak bir kısmı içeriden, yani yetkili kullanıcılardan (çalışanlar, eski çalışanlar veya sistem yöneticileri) kaynaklanır. Database Firewall, yönetici (admin/sa) yetkisine sahip bir hesabın bile normal mesai saatleri dışında veya alışılagelmişin dışında devasa bir veri kümesini (örneğin tüm müşteri tablosunu) dışarı aktarmaya (Data Exfiltration) çalışmasını algılar ve engeller.Mevzuata Uyum ve Regülasyonlar (KVKK, GDPR, PCI-DSS)KVKK, GDPR veya PCI-DSS gibi global ve yerel regülasyonlar, hassas verilerin korunmasını ve bu verilere kimin, ne zaman, hangi sorguyla eriştiğinin değiştirilemez (tamper-proof) bir şekilde günlüklenmesini (logging) zorunlu kılar. Database Firewall, performans kaybı yaratmadan bu detaylı denetim izini (Audit Trail) sunar.Yama Yapılamayan (Legacy) Sistemlerin KorunmasıBirçok kurumsal yapıda, iş kritik süreçler nedeniyle güncellenemeyen veya üretici desteği bitmiş eski veri tabanı sürümleri bulunur. Bu sistemlerdeki güvenlik açıklarını kapatmak (patching) her zaman mümkün olmaz. Database Firewall, bu açıkların sömürülmesini veri tabanına ulaşmadan engelleyerek bir nevi “Sanal Yama” (Virtual Patching) görevi görür.Üçüncü Taraf ve Entegrasyon Risklerinin YönetimiDışarıdan hizmet aldığınız yazılım firmaları, ERP entegrasyonları veya iş ortaklarınız veri tabanınıza doğrudan erişim talep edebilir. Bu dış kaynakların sadece kendilerine tanımlanan sınırlar dahilinde (örneğin sadece belirli tablolarda SELECT yapabilmesi, DROP veya ALTER yetkilerinin kısıtlanması) hareket ettiğinden emin olmak için Database Firewall en güvenilir filtredir.Siber güvenlikte “tek bir kale duvarı” mantığı artık geride kaldı. Veriyi merkezine alan Katmanlı Güvenlik (Defense-in-Depth) yaklaşımında, veri tabanının kendi güvenliğini sağlamak zincirin en kritik halkasıdır. Eğer kritik kurumsal verileri, müşteri kayıtlarını veya finansal tabloları yönetiyorsanız; Database Firewall mimarisini olgunlaştırmak bir tercih değil, sürdürülebilirlik gereksinimidir.#CyberSecurity #DatabaseFirewall #DataProtection #KVKK #GDPR #InfoSec #DatabaseSecurity #EnterpriseArchitecture

Yapay Zekâ ile Yazılım Projesi Geliştirmek: Bir Entegrasyon HikâyesiYapay zekânın (YZ) kod yazabilmesi ve bu sürecin yazılımcıların mesleğine olan etkisi konusunu, bir de benim penceremden dinlemenizi isterim.Yapay zekânın JavaScript, HTML ve CSS’i çok iyi bildiği bir gerçek. Hatta o kadar iyi biliyor ki, bir uygulama geliştirirken doğrudan son kullanıcı gibi düşünüp menü ve form yapılarını ona göre konfigüre edebiliyor. İddia ediyorum; normal bir yazılımcı veya tasarımcı, uygulamanın MVP (Minimum Uygulanabilir Ürün) sürecinde bu derece optimize ve kullanıcı dostu formlar tasarlamakta zorlanabilir.Bu makalede, bizzat şahit olduğum ve sonlarına doğru dâhil edildiğim gerçek bir başarı hikâyesini vaka analizi (case study) mantığıyla detaylandırmak istiyorum.Vizyoner Bir BT Uzmanı ve Projenin DoğuşuBir müşterimize, Menulux sistemiyle Logo ERP ürünü arasında entegrasyon sağlayan bir uygulama satmıştık. Bu müşterimizin BT (Bilişim Teknolojileri) tarafında, dijital kasları son derece gelişmiş uzman bir personeli bulunuyordu. Kendisi, işletmedeki bilişim süreçlerinin tamamını kendi tarafında sağlıklı bir biçimde yönetmekteydi.Genellikle kurumsal şirketlerdeki BT uzmanları; sunucu işleri, ERP süreçleri ve Excel raporlarıyla sınırlı kalır. Fakat bu müşterideki uzman arkadaş işi bir adım daha ileriye taşıdı: “Mevcut sistemi yapay zekâ ile nasıl daha efektif hâle getiririm?” vizyonuyla hareket ederek kendi başına bir proje geliştirmeye başladı.İşin ilginç tarafı; tam da o dönemde ben de paralel olarak yapay zekâya kod yazdırma süreçlerini kısmen tecrübe ediyor, YZ’nin özellikle script kod yazma konusundaki yeteneklerine şahit oluyordum. Bir anda kendimi bu projenin içinde buldum.Yazılan kodlar PHP, JavaScript ve HTML tabanlıydı. Eski bir PHP geliştiricisi olarak uygulamanın tasarımlarını ve çalışma mantığını incelediğimde, ortaya gerçekten çok efektif bir ürünün çıkarıldığını rahatlıkla söyleyebilirim.Sistemin Konumu ve Mimari YapıUygulamanın tam olarak nerede durduğunu netleştirmek adına işletmenin yapısından bahsedelim. Şirket bir gıda işletmesi; hem paketlenmiş hem de dondurulmuş ürün satışı yapıyorlar. Yani işin içinde hem üretim var hem de bu üretilen ürünlerin perakende satıldığı fiziksel mağazalar mevcut.Sistemde kullanılan dikey çözümler ve entegrasyon noktaları şu şekilde:Üretim ve Finans Yönetimi: Logo ERPE-Ticaret Altyapısı: IdeasoftPazaryeri Yönetimi: Hepsiburada, TrendyolRestoran ve Perakende Otomasyonu: MenuluxKullanılan tüm bu sistemler, aslında yeni nesil REST API altyapısına sahip ve entegrasyona oldukça müsait yapılar. Müşteri kendi ihtiyaçlarının farkında olduğu için tam orta noktaya konumlandırılan merkezi bir uygulama geliştirildi.Uygulama Ekranları ve Geliştirilen ModüllerYapay zekâ ve ne istediğini çok iyi bilen bir uzmanın bir araya gelmesiyle, geleneksel yazılım süreçlerinin dışına çıkan, çerçeveyi kıran modüller ortaya çıktıGüzel bir dashboard oluşturmuş.Tüm süreçlerin tek ekranda toplanması konusunda YZ çok başarılı bir iş çıkarmış. Normal yazılım süreçlerinde Dashboard en son yapılır; “içeride veri biriksin, ona göre makyajlarız” mantığı güdülür. Burada ise YZ, veri makyajını ve görsel hiyerarşiyi en baştan itibaren son derece yerinde ve dengeli kurmuş.Sipariş Hazırlama SüreciGerçek saha ihtiyacının ön plana çıktığı bir alan. Depo personelinin kargo etiketini basması ve sipariş detaylarının yazıldığı fişlerin (slip) otomatik çıkartılması süreci, müşteri talebi ve YZ’nin tasarım yeteneğiyle harika bir noktaya getirilmiş.Raporlama ModülüSistemde, ileride daha da büyütülebilecek esnek bir yapıda birçok operasyonel rapor bulunuyor. Özellikle Menulux bağlantılı kasa raporları anlık olarak takip edilebiliyor. İlerleyen süreçte lojistik yönetimine bağlı olarak şube depolarının stokları ve e-ticaret şube satış raporları da bu yapıya entegre edilebilir.Menülüx ile bağlantılı kasa raporlarıTabi istenirse satış raporları vs da bu sisteme entegre edilebilir.Neticede e-ticaret satışları özellikle şubeli yapılarda şube depolarından lojistik sürecinin yönetilmesiyle doğru orantılı olarak değişeceğinden siparişlerin kargo süreçlerini şube depolardan yönetmek gerekecektir ve bu yüzden şube satışları ve menuluxteki stokları da belkide bu sistemin içine entegre etmek gerekecektir.Raf Etiketi oluşturma süreciŞube 1 ve Şube 2 bazında, Logo ERP ile senkronize çalışan dinamik bir raf etiketi basım mekanizması kurgulanmış.Şube 1 ve Şube 2 bazındaLogo üzerinde kesilmiş faturaların XML verilerinin sistemden çekilmesi ve pazaryerlerine otomatik yüklenmesi süreci, e-Logo entegrasyonuyla tamamen otomatikleştirilmiş.Kritik Nokta: Siparişin oluştuğu sistem ile faturalandırmanın yapıldığı ERP sistemi arasında doğrudan bir senkronizasyon olmadığından, arka planda çalışan bir mekanizma belirli periyotlarla Logo’yu sorguluyor. Faturası kesilen siparişleri listeye getirerek pazaryeri bağlantısını otomatik tamamlıyor.Rakip ürün analizi ve öneri sistemiİşte bu modül, uygulamayı standart pazaryeri entegrasyonlarından ayıran ve doğrudan pazarlama teknolojilerine (MarTech) yaklaştıran kısım. Normal bir yazılımcı ürün geliştirirken bu vizyoner modülü ilk faza (MVP) eklemez, sonraki fazlara öteler. Ancak YZ ile süreç sınırları aşıyor.İşte burada ürün diğer pazaryeri entegrasyonu uygulamalarından biraz farklılaşmakta. Konu sadece entegrasyon sürecinden çıkıp biraz da pazarlama sürecine doğru evrilmekte.(Şimdi abartıyorsun bu uygulama diğer pazaryerlerinde zaten var dediğinizi duyar gibiyim)Burada belirtmek istediğim nokta, normal bir yazılımcı ürün geliştirirken bu modülü ilk faz’a eklemez, sonraki fazlarda buradaki süreci düşünür ve geliştirmeye çalışır. Ama YZ ve ne istediğini bilen bir müşterinin elinden çerçevinin dışına çıkabilecek nitelikte bir çıktı ortaya çıkmakta.Buybox UygulamasıBuyBox, Trendyol’da aynı ürünü satan birden fazla satıcı olduğunda, ürün sayfasında “Sepete Ekle” butonunun yanında öne çıkan satıcının kazandığı konumdur.Nasıl Çalışır?Bir müşteri ürün sayfasına girdiğinde tek bir “Sepete Ekle” butonu görür. Bu butonu kim kazanmışsa o satıcı BuyBox sahibidir ve satışın büyük çoğunluğunu o alır. Diğer satıcılar “Diğer Satıcılar” bölümüne düşer.Entegrasyon Açısından ÖnemiTrendyol entegrasyonu yaparken BuyBox’ı korumak için:Fiyat güncellemelerini anlık veya sık aralıklarla API üzerinden göndermekStok bilgisini gerçek zamanlı senkronize etmek (stok bitmesi BuyBox kaybettirir)Sipariş karşılama süresini kısa tutmakÜrün içeriğini (başlık, görsel, açıklama) eksiksiz doldurmakYani;BuyBox = Trendyol’da aynı ürünü satan satıcılar arasındaki görünürlük ve satış rekabeti. Entegrasyonun kalitesi doğrudan BuyBox performansını etkiler.Burada da olay biraz entegrasyondan pazarlamaya kaymış durumda farketmişsinizdir.Müşteri SorularıYapay zeka ya soruları otomatik cevaplatmak ve sadece kullanının onayına düşme süreci. Biraz AI Agentleri pazarlamaya dahil etme sürecinin simüle edilmiş hali diyebiliriz.Burada şöyle bir durum var; özellikle soru cevap kısmı çok kritik ki bugün günümüzde çağrı merkezleri bile bu sürece bağlanmak üzere. Hızlı geri dönüş açısından bu yapı mutlaka olmazsa olmaz bir noktada.Tabi burada önemli olan AI apisinin tüketeceği token sürecinin de müşteri tarafına bir maliyet olduğu ve fiyatlamaya hariç tutulması gerektiği bilgisi.(Bu kısmın özellikle altını çizmek isterim)Kar HesaplamaPazaryeri bazındaki güncel komisyon oranlarını sistem hafızasında tutarak, ürün bazında anlık net kâr analizi yapan iç içe geçmiş bir mekanizma.Burada da önemli nokta, belki diğer entegasyon sistemlerinde bu özellik vardır fakat sistemin içinde bu mekanizmayı yapmak ve pazaryeri bazındaki komisyon oranlarının sistem tarafından biliniyor olması ayrıca bir avantaj.Paket ve Set Öneri SistemiPaket/Set Öneri Sistemi, Örneğin Trendyol’da birbiriyle uyumlu ürünlerin bir arada sunularak müşteriye “Bunları Birlikte Al” veya “Kombin Önerisi” şeklinde gösterildiği sistemdir.Temel KavramlarBundle (Paket): Birden fazla ürünün tek bir liste olarak satışa sunulması.Set: Genellikle aynı kategoriden, birbirini tamamlayan ürünlerin gruplanması (örn. üst + alt giyim, şampuan + saç kremi).Cross-sell Önerisi: Ürün sayfasında “Bununla birlikte sıkça alınanlar” bölümü.Sistem Nasıl Çalışır?Müşteri bir ürüne bakar ↓Trendyol algoritması devreye girer ↓Satın alma geçmişi + birlikte alınan ürünler analiz edilir ↓Uyumlu ürünler "Set Önerisi" olarak gösterilir ↓Müşteri tek tıkla birden fazla ürünü sepete eklerBuyBox ile İlişkisi; paket önerilerinde de BuyBox mantığı geçerlidir. Seti oluşturan her ürün için ayrı ayrı BuyBox rekabeti yaşanır. Bu yüzden setteki tüm ürünlerde rekabetçi fiyat ve yüksek satıcı puanı korunmalıdır.Avantajları🛒 Ortalama sepet tutarını artırır📦 Tek kargoda birden fazla ürün satışı👁️ Görünürlük artar (set sayfası ayrıca listelenir)💰 Set indirimi ile dönüşüm oranı yükselirMüşteri Sadakat SistemiMüşteri sadakat sistemi, alışveriş yapan kullanıcıları platforma bağlı tutmak ve tekrar satın almayı teşvik etmek için çeşitli katmanlı mekanizmalar sunar. Müşterileri alışveriş sıklığı ve harcama miktarına göre otomatik olarak segmentlere ayırır:Örneğin;Yeni Müşteriİlk = alışverişini yapanAktif Müşteri=Belirli periyotta alışveriş yapanSadık Müşteri=Sık ve yüksek tutarda alışveriş yapanKayıp Müşteri=Uzun süredir alışveriş yapmayanKurulması gereken yapıda da :Doğum günü kampanyalarıİlk alışveriş indirimleriBelirli alışveriş tutarını geçen müşterilere otomatik kuponBu sayede;Tekrar alışveriş oranını izleyerek kampanya stratejisi belirlemekOrtalama sepet tutarını artırmak için bundle/set önerileriyle birleştirmekKupon kullanım oranını analiz ederek doğru indirim miktarını bulmakStok YönetimiStoklar Logo ya göre, veya başka bir sisteme göre güncellenebilir ve pazaryerlerine söz konusu bakiyeler entegre edilecektir.İnteraktivite ve AyarlarBir sipariş geldiğinde veya bir duruma(olay) göre sistemin bildirim göndermesi sağlanmaktadır.Entegrasyon Kontrol MerkeziHer kurumsal sistemde olması gereken CSV/XML dosya import/export süreçleri ve detaylı rol bazlı kullanıcı yetkilendirme modülleri de eksiksiz şekilde sisteme eklenmiş durumda.Csv ve Xml Dosya format import veya export süreçleri(Her sistemde olmazsa olmaz özellik)Kullanıcı yönetimi ve yetkilendirmeNihayetinde gördüğünüz gibi neredeyse tüm süreçlerin tamamlandığı bir konumda ortaya bir ürün çıkmış durumda.Peki bu ürünün gelişme sürecinde değerli olan sizce ne ?Kodlama mı ?Tasarım mı ?Yoksa Api bağlantıları ve gerçek veri mi ?Bu projeyi yaparken verilen emekten daha çoğu bu verileri api bağlantısı olmayan yeni bir sisteme taşırken ve mevcut verileri manipüle ederken uğraştık.Aslında bir süreç varsa bir ürün geliştirmek AI ile artık çok basit, fakat olmayan bir sürece kod yazmak ve bir çıktı oluşturmak neredeyse imkansız durumda.Yani aslında değer burada AI sayesinde 2 ye bölünmüş durumda(zaten öyleydi) daha da bu çizgi belirginleşmiş durumda desek yeridir.Müşteri elindeki datayla var olan api bağlantılarıyla kodlamayla uğraşmıyor ve ortaya bir ürün çıkıyor.Peki bir yazılımcı olarak bu süreçle ilgili en önemli yorumum ne ?Bu ürün o müşteri için hazır da diğer müşteriler için de gerçekten hazır mı ?Hazırsa bu ürüne güvenip yıllık sözleşme ve anlaşma imzalanabilir mi ?Müşteri bu ürünü aldığında bu ürünün AI ile yazıldığını bilmeli ve bildiğinde ne düşünecek ?Kendin yaparken iyi de başkasına satarken de bu kadar iyi olacak mı ?Tüm bu süreçleri deneyip göreceğiz. Yani müşteriyle birlikte yapılan ürünü bir başka müşteriye satış pazarlamasını yaptığımızda ürünün uyarlama süreciyle ne kadar ilgileneceğiz ve yapı farklılaştığında, örneğin ürün sayısı arttığında veya ürün varyasonları vs işin içine girdiğinde süreç nasıl bir hal alacak bunu kervan yol hesabı göreceğiz.Fakat önemli nokta şu; PHP kodları ve bugfix süreci biryerde tıkandığında ve AI dan destek alamaz duruma geldiğimizde PURE Php ile yazılımlış ve herhangi bir pattern’e dayanmayan bu kodların bakımı bizleri ne derece uğraştıracak bunu da yaşayıp göreceğiz.YZ Çağında yz ye kod yazdırmayacağım ve kendi bildiğimi kendi bildiğim gibi yapıp bu konuda direteceğim döneminin kapandığı, müşterilerin de hiç kod bilmeden uygulama geliştirebildiği çağa girmiş bulunmaktayız.İşte bu noktada ya mevcut değişime direnip müşterilerin bizim kapalı kaynak kod uygulamalarımıza ciddi yatırımlar yapmasını beklemeye devam edeceğiz, ya da ürün geliştirme sürecinde müşteriyi yönlendirerek neyi ne şekilde yapması gerektiği, çalışmayan bir mekanizmaya ne şekilde müdehale etmesi gerektiği konusunda danışmanlığımıza devam etmeliyiz.Neticede YZ de bu terminolojik bilgileri bir şekilde eğitildiği için biliyor. Fakat tedavi sürecinde hastaya hangi ilaçtan kaç doz alması gerektiğini yine bizler gibi hem teknik hem de mekanik süreçlere hakim olanlar belirleyecek.YZ Bize yoğurt yiyişi yani işin işleyişin formlarını hazırlayacak. Hatta çalıştıracaka ama oradaki mekanizmayı gerekiyorsa söküp kendi kodumuzu implemente edebildiğimizde var olan kodlar yaşamaya ve çalışmaya devam edecek.Şimdi baktığınızda YZ ile yazılan kodlar hep birbirine benziyor ve çıktılar da benzer makyajı yapmış kızlar gibi gözüküyor.“Aynı yaşlarda aynı dönem kızları belli zamanlarda benzer makyaj ve saç tipine büründüğünde aynı gözükür ya” işte buradaki metafor neden var diye sorarsanız, tüm uygulamaların birbirine benzediği bir dünyada aynı hatalar ve aynı yöntemlerin uygulanması süreci, eğer bir sorun varsa hepsinde var algısını doğuracaktır.Kodlar artık kapalı kapılar ardında kapalı kaynak kodlarla değil, açık kaynak kodlarla çalışan, artık herkesin mutfağa girip yemek yapabildiği bir restoranda aşçı başının hangi baharat ile hangi sebzenin hangi fırında kaçderece ısı da ne şekilde pişirileceğine karar vermeye benzedi.Sanıyorum çok fazla benzetme yaptım ama bu konu biraz da benzetmelerle somutlaşıyor. Zaten yazılım o kadar soyut ki, soyut bir konu soyut olan bir konuyla başka bir boyut kazanmış durumda.Son olarak bu konuyu biraz daha sadeleştirmeliyiz.

Öncelikle güvenli veri entegrasyonuyla ilgilendiğim için bu şifreleme konusuna kafayı takmış bulunmaktayım. Tabiki sadece teorik araştırmalar değil aynı zamanda şirket olarak pratikte bu konuyla ilgilendiğimizi söyleyebiliriz.Fakat tabi yapılan her araç iyi amaçlar için kullanılırken kötü taraflarını da düşünmek ve algoritma kurgusunu ona göre yapmak gerekmektedir.Bu makalede tek yönlü şifreleme kavramını irdeleyeceğim.Tek yönlü şifreleme, teknik adıyla Hashing (Özetleme), veriyi bir algoritmadan geçirerek geri döndürülemez, sabit uzunlukta benzersiz bir “parmak izine” dönüştürme işlemidir.Buradaki en kritik nokta, bu işlemin matematiksel olarak tek yönlü olmasıdır; yani elinizde özet (hash) çıktısı varken, orijinal veriye ulaşmanız (teorik olarak) mümkün değildir.Bir veriyi hashing algoritmasına (örneğin SHA-256) soktuğunuzda, girdi ne kadar büyük olursa olsun çıktı her zaman aynı uzunlukta olur.Geri Döndürülemezlik: “Merhaba Dünya” kelimesinin hash karşılığını bulabilirsiniz ama o karmaşık karakter dizisinden “Merhaba Dünya”ya geri dönemezsiniz. Deterministik kavrama göre Aynı girdi, her zaman aynı çıktıyı verir. Bu durumda bir veri setinde değişim uyguladığınızda Çığ Etkisi ortaya çıkar yani girdide tek bir bit bile değişse, çıktı tamamen farklı olur.Kullanım Alanları: Parola Saklamadır.Veritabanlarında şifreleriniz açık metin olarak değil, hash’lenmiş halde tutulur. Veri Bütünlüğü: Bir dosyanın indirme sırasında bozulup bozulmadığını kontrol etmek için “Checksum” olarak kullanılır.Aslında dosyalar tek yönlü şifrelendiğinde ne olur ? dosyalar kurtarılmak üzere “tek yönlü” şifrelenmezler. Eğer bir dosyayı sadece hashing işleminden geçirirseniz, elinizde sadece o dosyanın 64 karakterlik bir özeti kalır, orijinal dosya içeriği yok olur. Bu bir şifreleme değil, bir imzalama veya doğrulama yöntemidir. Yani aslında var olan bir dosyayı bozmak için de kullanılabilir.Eğer saldırgan dosyayı yedekledikten sonra tek yönlü şifrelediğinde saldırgana bitcoin ödemeden dosyaları alma şansınız yoktur.Aslında yani dosyalar şifrelendiyse ve gerçek bir dosya şifreleme uygulandıysa tek yönlü şifreleme uygulanmamış demektir.Fakat fidye yazılımları operasyonel kabiliyet açısından sızdığı sistemde rahat hareket edemeyebileceğinden genellikle tek yönlü şifreleme kullanmazlar.Fidye Yazılımları (Ransomware) Hangi Yöntemi Kullanır?İşte burada yaygın bir kafa karışıklığı var. Fidye yazılımları tek yönlü şifreleme (hashing) kullanmazlar. Eğer kullansalardı, parayı ödeseniz bile dosyalarınızı geri getirecek bir anahtar olmazdı (çünkü hash geri döndürülemez). Bu yüzden fidye yazılımları genellikle Hibrit Şifreleme yöntemini kullanır: Simetrik Şifreleme (Örn: AES-256): Dosyalarınızı çok hızlı bir şekilde şifrelemek için kullanılır. Bu işlem için bir “anahtar” gerekir. Ardından Asimetrik Şifreleme (Örn: RSA): Dosyalarınızı şifreleyen o “anahtarı” şifrelemek için kullanılır.Süreç Şöyle İşler: Yazılım, bilgisayarınızdaki her dosyayı simetrik bir anahtarla kilitler. Ardından bu anahtarı, saldırganın elinde bulunan “açık anahtar” (Public Key) ile şifreler. Sizden fidye istediklerinde aslında sattıkları şey, o simetrik anahtarı çözecek olan “özel anahtar”dır (Private Key).Yani saldırganın amacı eğer paraysa : Fidye yazılımları veriyi yok etmek için değil, veriyi bir kilit altına alıp anahtarı size satmak için iki yönlü şifrelemeyi son derece profesyonelce kullanır.Şimdi gelelim asıl şifreleme konusunda bu söz konusu fidyeciler sızdıkları sistemde nasıl davranırlar.Özellikle izole ve ne olduğu belli olmayan bir ortamda olabildiğince hızlı işlem yapmak gereklidir. Yani içeride anomali tespit eden bir AI ile çalışan antivirüs varsa içeri sızan uygulama karantinaya alınabilir. Bu durumda da yapabilecek birşey kalmaz.Dosya şifreleme süreci uzun süren bir prosesdir. Bu durumda içeride çok fazla kalıp çok fazla oyalanamayacağını bilen saldırgan dosyaların sadece header kısımlarını veya belli bir bölümünü kriptolar. Bu durumda kullanıcı dosyalara erişemez fakat aslında dosyalar tam şifrelenmemiş olabilir.Veri kurtarıcılar işte tam olarak bu süreçte devreye girerler ve tam bozulmayan dosyaların bozulmayan kısımlarını alıp kurtarabilirler.Burada kritik nokta, yedekler ve veritabanı dosyalarının şifrelenmesi çok etkilidir.10 GB’lık bir SQL veritabanını tamamen şifrelemek dakikalar sürer. Ancak sadece başlığını ve her 1 MB’lık bloğun ilk 10 KB’ını şifrelemek saniyeler sürer. Bu, saldırganın sistemde fark edilmeden daha fazla dosyayı kilitlemesini sağlar.Eğer header kısımları şifrelenirse dosyaların açılamamasının sebebi ise İşletim sistemi dosyanın ne olduğunu anlayamaz. Siz dosyaya tıkladığınızda “Dosya biçimi tanınmıyor” veya “Dosya bozuk” uyarısı alırsınız.İşte bu yüzdendir ki, veri kurtarıcılar bu dosyaları kurtarmak için daha kapsamlı OS ler kullanır.Saldırganlar dosya şifreleme yöntemleri için şunları kullanabilir;Sadece Başlık (Head-only): Sadece ilk 1–5 MB şifrelenir. Küçük dosyalar için ölümcüldür.Yüzdelik (Percentage): Dosyanın örneğin %50'si, bir blok şifreli bir blok orijinal olacak şekilde atlanarak işlenir.N-Adım (N-Step): Belirli bir miktar veri şifrelenir, ardından belirli bir miktar veri atlanır. Bu, veritabanı dosyaları gibi yapılandırılmış verilerde içeriği tamamen kullanılamaz hale getirir.Bu işlemleri yaparken profesyonel saldırganlar güvenlik yazılımlarını atlatmak için yine farklı yöntemler kullanabilir. Güvenlik Yazılımlarını Atlatma kavramına (Evasion) denir. Modern antivirüsler dosyaları şifreleyen bir zararlı yazılımı iki şekilde yakalar: İşlem Yoğunluğu: CPU kullanımı aniden tavan yaparsa sistem alarm verir. Ayrıca Entropi Analizi yapılır. Şifrelenmiş veri “kaotik” görünür. Bir dosyanın tamamı aniden yüksek entropili (rastgele görünen) veriye dönüşürse güvenlik yazılımı işlemi durdurur. Aralıklı şifrelemede ise dosyanın %90'ı orijinal haliyle kalır. Yazılım dosyanın sadece küçük parçalarını değiştirdiği için güvenlik araçları bu değişikliği “normal bir dosya güncellemesi” sanarak gözden kaçırabilir.Burada aklınıza dosyaları kurtarmak için bir şansımız var diye düşünebilirsiniz tabi;Burada bir “umut ışığı” ama aynı zamanda bir risk vardır:Umut: Eğer sadece header (başlık) şifrelendiyse, dosyanın geri kalanı (payload) diskte hala “açık” haldedir. Profesyonel veri kurtarma uzmanları, dosya imzasını (magic numbers) manuel olarak onararak veya veriyi ham (raw) şekilde kazıyarak (data carving) içeriğin bir kısmını kurtarabilir.Önemli Not: YZ nin de gelişmesiyle artık bu süreç çok daha profesyonelce ilerletilebilir. (Yani artık teknoloji çok gelişti :))Risk: Ancak veritabanı veya karmaşık yazılım dosyalarında, yapı taşları arasındaki bağlantılar koptuğu için kurtarılan veri genellikle anlamsız bir karakter yığınına dönüşebilir.Veri Güvenliğinde Yeni Trend artık sadece “yedekleme” yetmemektedir; saldırganların bu hızı karşısında “Değişmez Yedekler” (Immutable Backups) ön plana çıkmaktadır. Yani bir kez yazılan ve belirli bir süre boyunca (fidye yazılımı dahil) hiç kimse tarafından silinemeyen veya değiştirilemeyen yedekleme sistemleri kullanılması gerekmektedir.Bu hız ve tespit edilmeme taktikleri göz önüne alındığında, siber savunma tarafında “imza tabanlı” korumadan ziyade davranış analizine odaklanmak neden kritik hale geldi anlayabiliyoruz.Geleneksel antivirüs yazılımları, bir suçlunun “sabıka fotoğrafına” (imza/signature) bakarak onu yakalamaya çalışır. Ancak aralıklı şifreleme yapan veya her seferinde kendini değiştiren modern fidye yazılımlarında bu yöntem sınıfta kalmaktadır. Yapay zeka (AI) ve Makine Öğrenmesi (ML), fotoğraf yerine “suçlunun hareket tarzına” odaklanır.Dinamik Davranış Analizi (Behavioral Analysis) kullanılması gerekmektedir. AI, bir dosyanın ne olduğunu değil, ne yaptığını izler. Bir yazılımın şu davranışları sergilemesi, yapay zeka için “kırmızı alarm” demektir: Hızlı Dosya Değişimi: Normal bir kullanıcı veya uygulama, saniyede binlerce dosyaya erişip onları yeniden adlandırmaz.Toplu API Çağrıları: Dosyaları şifrelemek için kullanılan kriptografik kütüphanelere (örneğin Windows CryptoAPI) yapılan yoğun ve sıra dışı çağrılar.Sistem Geri Yükleme Noktalarını Silme: Yazılımın ilk işi yedekleri silmekse, AI bunu “kötü niyet” olarak etiketler.Bir dosyanın entropisi, içindeki verinin ne kadar rastgele olduğunu ölçer. Normal metin veya fotoğraf dosyalarının belirli bir matematiksel düzeni vardır. Şifrelenmiş veri ise matematiksel olarak “maksimum kaosa” (yüksek entropi) yakındır.Ayrıca gelişmiş sistemlerde saldırganı yakalamak için bal tuzağı denilen yöntemler de kullanılabilir.AI, sistemin çeşitli yerlerine kullanıcıya görünmeyen ama yazılımların kolayca erişebileceği “yem dosyalar” (canary files) yerleştirir. Bu dosyalar normalde hiçbir uygulama tarafından kullanılmaz. Eğer bir işlem bu dosyaya dokunursa veya içeriğini değiştirmeye kalkarsa, AI bunun bir fidye yazılımı olduğunu anlar ve tüm sistemi karantinaya alır.Fidye yazılımları, şifreleme anahtarını almak için saldırganın sunucusuyla (C2 Server) iletişim kurmak zorundadır. AI, ağ trafiğini izleyerek şu anormallikleri yakalar: Daha önce hiç gidilmemiş, şüpheli bir domain ile şifreli bir tünel açılması. Veri sızıntısını işaret eden (Exfiltration) alışılmadık boyutta dışa giden veri trafiği gibi.Bazı gelişmiş AI tabanlı uç nokta (EDR) çözümleri, bir yazılım şüpheli hareketler sergilemeye başladığı an, şifreleme gerçekleşmeden milisaniyeler önce dosyaların gölge kopyasını (snapshot) alır. Eğer yazılım kötü niyetli çıkarsa, AI yazılımı yok eder ve dosyaları o milisaniyelik yedekten otomatik olarak geri yükler. Kullanıcı saldırıya uğradığını fark etmez bile.Artık yapay zeka, sadece “kötüyü” bulmakla kalmıyor, aynı zamanda sistemin “normalini” öğrenerek (Unsupervised Learning) en ufak bir sapmada müdahale edebiliyor. Bu teknolojiler sayesinde, saldırganların “hızlı ve sinsi” olma avantajı yavaş yavaş ellerinden alınıyor.Tabi burada YZ VS YZ kavramı ortaya çıkıyor ki bu da başka bir yazının konusu.Buraya kadar okuduğunuz için teşekkürler 🙂

Bir sistem entegrasyon sırasında aradaki adam saldırısına uğradığında elde edilen paket eğer açılabilirse sistem içindeki güvenlik ne işe yarar ?Günümüzde bir çok sistem artık farklı sistemlerle haberleşmek zorunda.Hatta bir çok uygulama API service katmanı üzerine inşa edildiği için yazılım kendi içinde de entegrasyon mantığında çalışmaktadır.Sistemler kendi içinde haberleşirken standart authentication yöntemleri ile öncelikli handshake yöntemiyle anlaşır ve veri transferi yaparlar.Özellikle mobil çağda yaşadığımız düşünüldüğünde mobil cihazların içinde sadece gerekli ve konfigürasyon verileri tutulup ana verilerin entegrasyon kapsamında ana sunucuyla sürekli haberleşmesi sağlanır.Bu durumda mobil uygulamanın bağlı ağda bir zafiyet varsa hem hedef hem de kaynak sistem hakkında saldırgan bilgi sahibi olur.Bu durumda kayankta gönderilecek olan bilgi şifrelenerek hedefte açılması ve açık uçlu anatarlama yapmak gerekmektedir.Sistem entegrasyonlarında güvenlik, yalnızca kapıyı kilitlemekle değil, anahtarın yolda çalınması ihtimaline karşı verinin kendisini anlamsız bir yığına dönüştürmekle ilgilidir.Burada teknik bir tanımlama yapmak gerekirse; Bir sistem entegrasyonu sırasında, gönderici (istemci) ile alıcı (sunucu) arasındaki iletişim hattına üçüncü bir tarafın gizlice sızmasına Aradaki Adam (MitM) saldırısı denir.Saldırgan, ağ üzerindeki paketleri izleyerek şu iki temel eylemi gerçekleştirebilir:Koklama (Sniffing): İletilen hassas verileri (kullanıcı bilgileri, API anahtarları, finansal veriler) okur.Müdahale (Interception & Manipulation): Paketi sadece okumakla kalmaz, içeriğini değiştirip alıcıya “orijinalmiş gibi” iletir. Örneğin, bir banka transferi isteğinde alıcı IBAN numarasını yol üstünde değiştirebilir.Aslında savunma derinliği (Defense in Depth) kavramının neden önemli olduğunu açıklamak gerekir. Eğer veri paket seviyesinde şifrelenmemişse, saldırgan paketi açtığında sistemin içindeki “veritabanı şifrelemesi” veya “rol tabanlı erişim kontrolü” anlamsızlaşır. Çünkü veri, henüz hedefine ulaşıp bu kontrollere girmeden önce saldırganın eline geçmiştir.Entegrasyon süreçlerinde güvenliği sağlamak için sadece “kapıda el sıkışmak” (Authentication) yeterli değildir; verinin kendisini de zırhlamak gerekir.Uçtan Uca Şifreleme (E2EE): Veri, kaynaktan çıkmadan önce şifrelenir ve yalnızca hedefteki yetkili anahtar ile açılabilir. Bu sayede, aradaki ağ (Wi-Fi, ISP veya yönlendiriciler) güvenli olmasa bile saldırganın eline geçen paket anlamsız bir veri yığınıdır.Asimetrik Şifreleme (Açık Anahtarlı Altyapı): Taslakta bahsedilen “açık uçlu anahtarlama” bu noktada devreye girer. Public Key (Açık Anahtar) veriyi şifrelemek için herkesle paylaşılabilirken, bu şifreyi çözebilecek tek şey sadece hedefte bulunan Private Key (Gizli Anahtar) bilgisidir.Transport Layer Security (TLS): Verinin taşındığı tüneli şifreler. Ancak üst düzey güvenlik gerektiren entegrasyonlarda, TLS’e ek olarak uygulama katmanında da (Payload Encryption) şifreleme yapılması, MitM riskini minimize eder.Yani aslında Entegrasyon güvenliği, “güvenli bir tünel” kurmaktan fazlasıdır. Tünelin içinde taşınan paketin de kilitli bir sandık içinde olması gerekir. Bu sayede aradaki adam sandığı ele geçirse bile, içindeki hazineye (veriye) asla ulaşamaz.Tabiki bu konuda dünyada otorite kabul edilen rehberler vardır.OWASP API Security Top 10: API entegrasyonlarındaki en kritik 10 risk faktörünü açıklar. Özellikle “Broken Object Level Authorization” ve “Unsafe Consumption of APIs” bölümleri konumuzla doğrudan ilgilidir.OWASP Mobile Application Security (MAS): Mobil cihazlar ile sunucular arasındaki trafiğin nasıl güvenli hale getirileceğine (Certificate Pinning, TLS konfigürasyonları) dair pratik rehberler sunar.Akademik ve teorik olarak;“Applied Cryptography” — Bruce Schneier: Şifreleme algoritmaları ve protokol güvenliği konusunda dünya çapında en çok referans gösterilen kitaptır. Asimetrik şifreleme ve anahtar değişimi mantığını detaylandırır.“Computer Networking: A Top-Down Approach” — Kurose & Ross: Ağ katmanlarını ve TLS (Transport Layer Security) protokolünün el sıkışma (handshake) mekanizmasını teknik detaylarıyla açıklar.Bu konuyla ilgili var olan protokollerden örnekler vermek gerekirse;RFC 8446 (The Transport Layer Security (TLS) Protocol Version 1.3): Günümüzde kullanılan en güvenli iletişim protokolünün resmi teknik dokümantasyonudur. MitM saldırılarına karşı nasıl koruma sağladığını teknik düzeyde anlatır.NIST Special Publication 800–52: ABD Ulusal Standartlar ve Teknoloji Enstitüsü tarafından yayınlanan, TLS’in en güvenli şekilde nasıl yapılandırılması gerektiğini anlatan rehberdir.Yani aslında veri yolculuğunda güvenlik tesadüf değildir.Modern yazılım dünyasında “kapalı devre” sistemler artık yerini dinamik, API tabanlı ve sürekli haberleşen entegrasyon yapılarına bırakmıştır. Bu mimari evrim, veriyi sadece durduğu yerde (at rest) değil, sistemler arasındaki yolculuğu sırasında (in transit) de korunması gereken en hassas varlık haline getirmiştir.

Başka bir deyişle STOK MODELLERİBir işletme ya da organizasyon tarafından gelecek bir zaman dilimi içerisinde kullanılmak için elde tutulan atıl mal (ürün) veya malzemeler stok olarak adlandırılırlar. Stok sistemi ise stok düzeyini, stokların ne zaman yenileneceğini ve ne miktarda sipariş verileceğini belirleyen hareket biçimlerinin oluşturduğu bir kümedir. Üretim işletmelerinde stoklar genellikle işletmenin nihai ürününe katkısı ya da bir parçası olan maddi varlıklar olarak ifade edilmektedirler. Üretim işletmelerindeki stoklar, hammadde, satın alınan tamamlayıcı parçalar, yarı işlenmiş ürünler (ara ürünler), tamamlanmış (nihai) ürünler olarak sınıflandırılabilir. Hizmet işletmelerinde stoklar genellikle hizmet sunumu sırasında satılan maddi ürünler ve hizmeti sunmak için gerekli olan gereçler anlamına gelmektedir.Stokların İşlevleriStoklar, müşteri talebindeki belirsizlikler ve mevsimsel veya mevsimsel olmayan dalgalanmalara karşı işletmeyi koruyan bir tampon görevi görürler. İşletme içindeki ara stoklar ise üretim araçlarının daha verimli kullanılmasını sağlarlar. Tedarikçiler tarafından üretimde veya nakliyede ortaya çıkabilecek aksamaların işletmeyi etkilemesini önlerler. Her ne kadar stokların işletmeye sağladığı faydalar oldukça önemli olsa da stokların işletmeye olan maliyetleri oldukça fazladır. Bir işletme yöneticisi stokları etkin şekilde yönetebilmek için şu iki soruya cevap vermelidir.Soru 1. “Ne miktarda sipariş verilmelidir?”Soru 2. “Ne sıklıkta sipariş verilmelidir?”Stoklardan kaynaklanan maliyetlerStok yönetiminin amacı yeterli miktarda materyalin doğru yerde, doğru zamanda ve düşük maliyetle bulunmasını sağlamaktır. Stoklarla ilgili maliyetler stok sisteminin işleyişiyle ilgili olarak ortaya çıkan maliyetlerden ya da stok sistemi içerisinde alınan veya alınmayan kararlardan dolayı ortaya çıkan maliyetlerden oluşmaktadır. Bu maliyetlerin hepsi ya da bazıları herhangi bir stok karar modeline temel ekonomik parametre olarak dahil edilmektedir.Satın alma maliyetiBir kalemin satın alma maliyeti eğer o kalem işletme dışı kaynaklardan elde ediliyor ise o kalemin birim satın alma fiyatıdır. Eğer işletme içinde üretiliyor ise o kalemin birim üretim maliyetidir. Bir kalemin satın alma maliyeti o kalemin stoka girdiği zamandaki maliyeti olarak alınmalıdır. Satın alınan kalemler için birim satın alma fiyatına nakliye/taşıma gibi bir takım maliyetler de ilave edilmelidir. İşletme içinde üretilen kalemler için birim satın alma maliyeti doğrudan işçilik, doğrudan hammadde ve doğrudan işletme giderlerinin toplamıdır. Satın alma maliyeti satın alma miktarına bağlı olarak değişebilmektedir. Örneğin, belli miktarların üzerinde satın alınması durumda tedarikçi firmalar fiyatlarda iskonto yapabilmektedir.Sipariş verme maliyetiBu maliyet sipariş edilen miktardan bağımsızdır. Sipariş verme maliyeti stoka girecek kalemin işletme dışı kaynaklardan elde edilmesi durumda ortaya çıkar ve siparişin verilmesi için katlanılan yönetim, büro ve kırtasiye masraflarından oluşur. Sipariş verme maliyeti, sipariş talebinde bulunulması, satıcıların analiz edilmesi, satın alınan kalemin teslim alınması ve denetlemesi, siparişler için kırtasiye masraflarının yapılması, siparişlere ilişkin ödemelerin yapılması durumlarında ortaya çıkan maliyetleri kapsamaktadır.Üretime Hazırlık MaliyetiÜretime hazırlık maliyeti ise stoka girecek kalemin işletme içinde üretilmesi durumunda söz konusu olmaktadır. Üretime hazırlık maliyeti stok kaleminin üretilmesi için üretim sürecinin değiştirilmesi, ayarlanması, hızlandırılması, üretim işlemlerinin programlanması, üretilen kalemlerin kalite kontrolünün yapılması gibi faaliyetlerin maliyetlerinden oluşmaktadır. Sipariş verme ve üretime hazırlık maliyetleri sipariş miktarına ve üretim miktarına bağlı değildir.Stok bulundurma maliyetiStoklanan kalemin belirli bir süre (genellikle 1 yıl) stokta bulundurmanın sonucu karşılaşılan maliyetlerdir. Stok bulundurma maliyetinin çok büyük bir kısmını ( yaklaşık % 80’ini) stoka bağlanan sermayenin maliyeti oluşturur. Bu maliyet kredi faizi veya stoka bağlanan para ile yapılabilecek yatırımların kazancından yoksun kalmanın bir sonucu olan fırsat maliyeti olarak görülebilir. Elde stok bulundurma maliyetini oluşturan diğer maliyetler; sigorta, vergi, kırılma, bozulma, yıpranma, demode olma ve kaybolma maliyetleridir. Stok bulundurma maliyeti genellikle stokta tutulan malın birim fiyatının bir yüzdesi olarak hesaplanır. Belli bir dönemde (genellikle yıllık) stok bulundurma maliyet oranı I sembolü ile gösterilir.Stok tükenme maliyetiStok tükenme maliyeti işletme içi ya da işletme dışı taleplerin karşılanamadığı durumlarının ekonomik sonucudur. İşletme dışı stok tükenme maliyeti müşteri siparişlerinin karşılanamaması; işletme içi stok tükenme maliyeti ise işletme içindeki bölümler (birimler) arasında siparişlerin karşılanamaması durumunda söz konusudur. İşletme dışı stok tükenme maliyetleri yeniden sipariş verme, satış kayıpları, müşterilerin iyi niyetinin erozyona uğraması gibi maliyetlerden oluşmaktadır. İşletme içi stok tükenme maliyeti ise üretim kaybı, üretim kaynaklarının atıl kalması, taşeron üretim yapılması ve ürünlerin tamamlanmasında meydana gelebilecek gecikmelerin maliyetlerinden oluşmaktadır. Yukarıda sözü edilen stoklarla ilgili maliyetlerin sembolleri aşağıdaki tabloda gösterilmiştir.Stoklarla ilgili maliyetler ve sembollerEkonomik Sipariş Miktarı (ESM) Stok ModeliStokların işletmelere birçok maliyetleri bulunmaktadır. Stoklara ilişkin temel soru “Ne miktarda ve ne zaman sipariş verilmelidir?” Ne miktarda sipariş verileceği kararı stoklardan kaynaklanan iki maliyet (stok bulundurma maliyeti ve sipariş verme maliyeti) arasında denge kurularak verilecek bir karardır. Az miktarda stok bulundurup çok sayıda sipariş vermek ya da çok miktarda stok bulundurup az sayıda sipariş vermek işletmenin stok maliyetlerini etkileyecektir.Stok modellerinde varsayımlarİşletme ESM modelini kullanarak stok maliyetlerini en düşük seviyede gerçekleştiren sipariş miktarını bulabilir.ESM modelini kullanabilmek için stoku yapılacak olan kalemin talebi, stok bulundurma maliyeti ve sipariş verme maliyetlerinin bilinmesi ve aşağıdaki varsayımların yapılması gerekmektedir.Stok tek bir ürün kaleminden oluşmaktadır.Stoku yapılacak kalemin (ürünün) belli bir dönemdeki (genellikle yıllık) talebi (D) kesin olarak bilinmektedir ve talep hızı sabittir.Sipariş edilen miktar (Q) her sipariş için aynı olmakta ve hiç değişmemektedir.Sipariş verme maliyeti (Co) miktara bağlı değildir. Ne miktarda sipariş verilirse verilsin katlanılan sipariş verme maliyeti aynı olmaktadır.Satın alınan ürünün birim maliyeti © sipariş miktarından bağımsız ve sabittir.Stok bulundurma maliyeti (Ch) stok politikası dönemi boyunca sabittir.Stoksuz kalma ve yok satma gibi durumlara izin verilmemektedir.Siparişlerin tedarik süreleri sabittir. Siparişten siparişe farklılık göstermemektedir.Stok düzeyi (miktarı) sürekli bir biçimde gözden geçirilmekte ve stok düzeyi sipariş verme noktasına geldiği zaman sipariş beklemeksizin verilmektedir.Ekonomik Sipariş Miktarı (ESM) Stok ModeliÖRNEK 1. “Starbucks Kahve Çekirdeği” Senaryosu Bir Starbucks şubesi düşün: Yıllık kahve çekirdeği ihtiyacı: D = 10.000 kgSipariş verme maliyeti: Co = 200 TLDepolama maliyeti (kg başına yıllık): Ch = 5 TL“Starbucks her seferinde 894 kg sipariş verirse toplam maliyeti minimum olur. Daha fazla ya da daha az sipariş vermek = para kaybı.”Amazon : Yıllık ürün talebi: 1.000.000 adetSipariş maliyeti: 50 TLDepolama maliyeti: 2 TL“Amazon gibi dev şirketler bile ‘her şeyi toplu alalım’ mantığıyla çalışmaz. Optimum nokta matematikle bulunur.”Bakkal: Düşük talep, Depolama alanı küçük, EOQ küçük çıkarMarket:Yüksek talep, Depolama büyük, EOQ büyük çıkar“EOQ işletmenin büyüklüğüne göre değil, maliyet dengelerine göre değişir.”“Yanlış Karar = Gizli Zarar” Senaryosu Aynı Starbucks örneğinde: EOQ: 894 kg Ama yönetici 2000 kg sipariş veriyor Sonuç: Depolama maliyeti patlar, Nakit akışı bozulur“Yanlış sipariş kararı görünmez zarar üretir. Muhasebede değil, sistemde kaybolur.”“Sipariş Verme Noktası (SVN) — Kritik An” Bir ürün: Günlük talep: 40 adet ve tedarik süresi: 5 gün“Stok 200’e düştüğünde sipariş vermezseniz, müşteri rafta boşluk görür.”