Blog

Son zamanlarda, AWS Müşteri Olay Müdahale Ekibi (CIRT) ve otomatik güvenlik izleme sistemleri, Amazon Simple Storage Service (Amazon S3) depolama alanlarıyla ilişkili olağandışı şifreleme etkinliklerinde bir artış tespit etti.

Amazon, bu eylemlerin AWS hizmetlerindeki bir güvenlik açığından kaynaklanmadığını vurguluyor. Aksine, bu eylemlerin, yetkisiz bir kullanıcının geçerli kimlik bilgilerini, beklenmedik bir şekilde kullanması gerektiğini ifade ediyor. Bu eylemler, ortak sorumluluk modelinin müşteri alanında gerçekleşse de, AWS müşterilerin bu tür etkinlikleri önlemek veya etkisini azaltmak için kullanabileceği adımları önermektedir.

Müşterilerle birlikte çalışan Amazon güvenlik ekipleri, “SSE-C” (müşteri tarafından sağlanan anahtarlarla sunucu tarafı şifreleme) adı verilen bir şifreleme yöntemi kullanan S3 üzerindeki veri şifreleme olaylarında bir artış tespit etti. Bu, birçok müşteri tarafından kullanılan bir özellik olmakla birlikte, SSE-C kullanan çok sayıda S3 CopyObject işleminin nesneleri üzerine yazarak, müşteri verilerini yeni bir şifreleme anahtarıyla yeniden şifreleme etkisi oluşturduğu bir model fark etti. Yapılan analizler, bunun geçerli müşteri kimlik bilgilerini ele geçiren tehdit aktörleri tarafından yapıldığını ve bu bilgilerin nesneleri yeniden şifrelemek için kullanıldığını ortaya koydu.

Amazon güvenlik ekipleri, aktif savunma araçlarını kullanarak, bu tür yetkisiz etkinlikleri birçok durumda önlemeye yardımcı olacak otomatik önlemleri devreye aldı. Bu önlemler, müşterilerin kendilerini korumak için herhangi bir adım atmasına gerek kalmadan, girişimlerin yüksek bir yüzdesinin başarısız olmasını sağladı. Ancak, tehdit aktörleri geçerli kimlik bilgilerini kullandığı için AWS'nin geçerli kullanımı kötü amaçlı kullanımdan güvenilir bir şekilde ayırt etmesi zordur. Bu nedenle, müşterilerin riskleri azaltmak için en iyi uygulamaları takip etmeleri gerekiyor.

Yetkisiz SSE-C kullanımına karşı korunmak için müşterilerin şu dört güvenlik uygulamasını uygulamaları gerekiyor:

1. Kısa vadeli kimlik bilgileri (Short-Term Credentials) kullanmak

Yukarıdaki teknik SSE-C şifrelemesini kullanıyor olsa da, bu ve birçok güvenlik olayının temel nedeni kimlik bilgilerinin ele geçirilmesidir. Ele geçirilen kimlik bilgileri riskini azaltmanın en etkili yolu, uzun vadeli kimlik bilgilerini hiç oluşturmamaktır. Var olmayan kimlik bilgileri ifşa edilemez veya çalınamaz. Bununla birlikte AWS, kimlik bilgilerini kaynak kodunda veya yapılandırma dosyalarında saklama gereksinimini ortadan kaldıran bir yetenek seti sunar.

IAM rolleri, Amazon Elastic Compute Cloud (Amazon EC2) örneklerinden, Amazon Elastic Container Service (Amazon ECS) veya Amazon Elastic Kubernetes Service (Amazon EKS) kapsayıcılarından ya da Lambda işlevlerinden kısa vadeli kimlik bilgileri kullanarak imzalı API isteklerini güvenli bir şekilde yapmalarına olanak tanır. Ayrıca, AWS Bulutu dışındaki sistemler bile IAM Roles Anywhere özelliğini kullanarak uzun vadeli AWS kimlik bilgileri olmadan kimlik doğrulamalı çağrılar yapabilir. Bunun yanı sıra, AWS IAM Identity Center, geliştirici iş istasyonlarının, Multi-Factor Authentication (MFA) ile korunan daha uzun vadeli kullanıcı kimliklerine dayanan kısa vadeli kimlik bilgileri edinmesini sağlar.

Tüm bu teknolojiler, AWS Security Token Service (AWS STS) üzerine inşa edilmiştir ve kodda veya yapılandırma dosyalarında uzun vadeli AWS güvenlik kimlik bilgileri dağıtılmadan veya gömülmeden AWS kaynaklarına erişimi kontrol edebilen geçici güvenlik kimlik bilgileri sağlar.

2. Geri dönüş prosedürleri uygulamak

Veri koruma mekanizmaları olmadan, veri kurtarma süreleri daha uzun olabilir. Veri koruma uygulaması olarak, verilerin üzerine yazılmasını önlemenizi ve kritik verilerin ikinci bir kopyasını saklamanızı öneririz.

S3 Versiyonlama özelliğini etkinleştirerek bir kovadaki bir nesnenin birden fazla versiyonunu saklayabilir ve kazara silinen veya üzerine yazılan nesneleri geri yükleyebilirsiniz. Ancak, versiyonlama özelliğinin, özellikle bir kovadaki nesnelerin sık sık üzerine yazıldığı uygulamalarda depolama maliyetlerini artırabileceğini unutmayın. Bu durumda, eski versiyonları yönetmek ve depolama maliyetlerini kontrol altında tutmak için S3 Yaşam Döngüsü politikalarını uygulamayı düşünebilirsiniz.

Buna ek olarak, kritik verilerin bir yedeğini farklı bir depolama alanına ve mümkünse farklı bir AWS hesabına veya AWS Bölgesine yedek alın. Bunu yapmak için S3 replikasyonunu kullanarak nesneleri depolama alanları arasında otomatik olarak kopyalayabilirsiniz. Bu depolama alanları aynı AWS hesabında veya farklı AWS hesaplarında ve aynı veya farklı AWS Bölgelerinde bulunabilir. S3 replikasyonu ayrıca, RPO (Recovery Point Objective) ve RTO (Recovery Time Objective) gereksinimleri olan müşteriler için bir SLA sunar. Alternatif olarak, S3 depolama alanlarının periyodik yedeklemesini otomatikleştiren yönetilen bir hizmet olan AWS Backup for S3'ü kullanabilirsiniz.

3. AWS kaynaklarını beklenmedik erişim modelleri için izleyin

İzleme yapılmadığında, S3 depolama alanları üzerindeki yetkisiz işlemler fark edilmeyebilir. Verilerinize erişimi izlemek için AWS CloudTrail veya S3 sunucu erişim logları gibi araçları kullanabilirsiniz.

AWS CloudTrail'i, AWS hizmetlerinde (Amazon S3 dahil) gerçekleşen olayları loglamak için kullanabilirsiniz. Ayrıca, logları tek bir hesapta birleştirerek güvenlik ekiplerinizin erişim sağlaması ve izleme yapması için kullanılabilir hale getirebilirsiniz. Bunun yanı sıra, belirli S3 metrikleri veya loglarına dayalı CloudWatch alarmları oluşturabilirsiniz. Bu alarmlar, olağandışı etkinlikler hakkında hızlıca bilgi edinmenize yardımcı olur.

Ayrıca, Amazon EventBridge ve AWS Lambda'yı kullanarak otomatik düzeltici önlemler alacak bir otomasyon da kurabilirsiniz. 

4. SSE-C şifreleme kullanımını engelleyin

Eğer uygulamalarınız şifreleme yöntemi olarak SSE-C kullanmıyorsa, bir S3 depolama alanına uygulanan kaynak politikasıyla veya AWS Organizations'daki bir organizasyona uygulanan bir kaynak kontrol politikası (RCP) ile SSE-C kullanımını engelleyebilirsiniz.

S3 depolama alanına yönelik kaynak politikaları genellikle "bucket policies" olarak adlandırılır ve müşterilerin S3'teki bireysel epolama alanları için izinleri belirtmesine olanak tanır. Bir bucket politikası, S3 PutBucketPolicy API işlemi, AWS Komut Satırı Arayüzü (CLI) veya AWS Yönetim Konsolu kullanılarak uygulanabilir. Bucket politikalarının nasıl çalıştığı hakkında daha fazla bilgi için S3 belgelerine bakabilirsiniz. Aşağıdaki örnek, <your-bucket-name> adlı bir bucket için SSE-C isteklerini engelleyen bir bucket politikasını göstermektedir:

{

    "Version": "2012-10-17",    

    "Statement": [

        {

            "Sid": "RestrictSSECObjectUploads",

            "Effect": "Deny",

            "Principal": "*",

            "Action": "s3:PutObject",

            "Resource": "arn:aws:s3:::<your-bucket-name>/*",

            "Condition": {

                "Null": {

                    "s3:x-amz-server-side-encryption-customer-algorithm": "false"

                }

            }

        }

    ]

 }

RCP'ler (Kaynak Kontrol Politikaları), müşterilerin AWS Organizations'daki bir organizasyon genelinde kaynaklara uygulanacak maksimum izinleri belirlemelerine olanak tanır. Bir RCP, AWS Organizations UpdatePolicy API işlemi, AWS Komut Satırı Arayüzü (CLI) veya AWS Yönetim Konsolu kullanılarak uygulanabilir. RCP'lerin nasıl çalıştığı hakkında daha fazla bilgi için AWS Organizations belgelerine göz atabilirsiniz. Aşağıdaki örnek, organizasyondaki depolama alanları için SSE-C isteklerini engelleyen bir RCP'yi göstermektedir.

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Sid": "RestrictSSECObjectUploads",

      "Effect": "Deny",

      "Principal": "*",

      "Action": "s3:PutObject",

      "Resource": "*",

      "Condition": {

        "Null": {

          "s3:x-amz-server-side-encryption-customer-algorithm": "false"

        }

      }

    }

  ]

 }

AWS, şifreleme olaylarının genellikle uzun vadeli kimlik bilgilerinin kötü niyetli kişiler tarafından ele geçirilmesinden kaynaklandığını belirtiyor. Bu durumun önlenmesi için kısa vadeli kimlik bilgileri (IAM Rolleri, STS (Security Token Service, IAM Identity Center) yetki kısıtlamaları ve otomatik izleme sistemleri gibi çeşitli yöntemlerle çalışmak, güvenlik risklerini önemli ölçüde azaltır. Ayrıca, özellikle SSE-C (müşteri tarafından sağlanan anahtarlarla sunucu tarafı şifreleme) kullanımını kısıtlamak veya engellemek için uygulanabilir politikalar ve teknik çözümler ayrıntılı bir şekilde yukarıda açıklanmış.

Yazının içeriğinde geçen istem dışı şifreleme olaylarına karşı alınacak dört temel güvenlik uygulamasına bizde katkı sağlayalım :

1. Kısa vadeli kimlik bilgileri kullanımı: Uzun vadeli kimlik bilgileri yerine IAM rolleri, IAM Identity Center ve AWS STS ile kısa vadeli kimlik bilgileri kullanılmalıdır. Bu şekilde kullanılmadığı için uzun vadeli kimlik bilgilerinin çalınmaması ve ifşa edilmemesi söz değildir.
2. Geri dönüş prosedürleri: S3 versiyonlama, geri dönüş politikaları ve replikasyon yöntemleri kullanılarak veri koruma ve kurtarma süreçleri güçlendirilmelidir. Bu alanda yazının içeriğinde bahsi geçen replikasyonların yine aws hizmetleri içersinde barındırılabileceği önerilmiş. Aksine DrDisk Lab olarak replikasyonların ve ek yedeklemelerin farklı lokasyon ve farklı sistemler üzerinde tutulmasını öneriyoruz. Burada aslolan şeyin koruyamadığımız verilere en hızlı ve en güvenilir şekilde geri ulaşmak olduğunu unutmamalıyız.
3. Kaynakları izleme: AWS CloudTrail, CloudWatch ve EventBridge ile S3 üzerindeki beklenmedik erişim modelleri izlenmelidir. Bunların otomasyon ile izlenmesinin yanında ek olarak insan gözüyle de kontrol edilmesini öneriyoruz.
4. SSE-C kullanımını engelleme: SSE-C kullanmayan uygulamalar için bucket politikaları ve RCP'ler uygulanarak bu şifreleme yöntemi sınırlandırılmalıdır.

Sonuç olarak, AWS'nin sunduğu teknolojiler ve politikalar müşterilere güçlü bir güvenlik altyapısı sunarken, ek önlemlerle bu yapı daha da sağlamlaştırılabilir. Müşterilerin, güvenlik uygulamalarını düzenli olarak güncelleyerek ve uygulayarak olası tehditlere karşı hazırlıklı olmaları büyük önem taşır.

Kaynak:

Veriler, ilk defa bu ay sosyal medyada ve hacker formlarında yer alan yeni bir hacker grubu olan "Belsen Group" tarafından sızdırıldı. Grup, kendilerini tanıtmak için bir Tor Web sitesi oluşturdu. Oluşturulan site üzerinden FortiGate cihazlarına ait verileri diğer tehdit aktörleri tarafından kullanılmak üzere ücretsiz olarak yayınladı.

Grup, siber suç forumlarının birinde FortiGate cihazlarına ait verileri kendilerini tanımak amacıyla ücretsiz yayınladıklarını belirten bir post paylaştı.

"Bu yılın başında bizim için olumlu bir başlangıç ​​olarak ve grubumuzun adını 
hafızanızda sağlamlaştırmak adına ilk resmi operasyonumuzu duyurmaktan 
gurur duyuyoruz: 
15.000'den fazla hedefe ait hassas veriler yayınlanacak dünya çapında (hem devlet 
hem de özel sektör) saldırıya uğrayan ve verileri çıkarılan kişiler"

Sızdırılan FortiGate verileri, ülkeye göre sınıflandırılmış klasörleri içeren 1,6 GB'lık büyük bir arşivden oluşuyor. Zira, arşivin içinde bulunan dosyaların genelinin text dosyası olaması 1,6 GB'lık bir büyüklüğün aslında ne kadar fazla veri barındırdığın ürkütücü bir delilidir. Ülkelere ait bu klasörlerin içinde ise, o ülkeye ait FortiGate cihazlarının IP adreslerine göre alt klasörler bulunuyor. Belsen Group, tehdit aktörleri için oldukça kolaylaştırcı bir çalışma yapmış gözüküyor.

Siber güvenlik uzmanı Kevin Beaumont'a göre, her IP adresine ilişkin klasörde “configuration.conf” (Fortigate yapılandırma dökümanı) ve “vpn-passwords.txt” dosyası bulunuyor. Bazı şifrelerin ise düz metin halinde olduğunu, yapılandırmalar için ayrıca özel anahtarlar (private keys) ve güvenlik duvarı (firewall) kuralları gibi hassas bilgileri de içeriyor.

Beaumont, "Kurban kuruluşundaki bir cihazda olay müdahalesi yaptım ve istismar gerçekten de cihazdaki yapılara dayalı olarak CVE-2022-40684 aracılığıyla gerçekleştirilmiş. Ayrıca dökümde görülen kullanıcı adlarının ve şifrenin eşleştiğini de doğrulayabildim. Verilerin Ekim 2022'de 0day güvenlik açığı olarak toplandığı görülüyor. Bazı nedenlerden dolayı, config'in veri dökümü 2 yıldan biraz daha uzun bir süre sonra bugün yayınlandı." diye açıklıyor.

2022'de Fortinet, tehdit aktörlerinin hedeflenen FortiGate cihazlarından yapılandırma dosyalarını indirmek ve ardından "fortigate-tech-support" adı verilen kötü amaçlı bir super_admin hesabı eklemek için CVE-2022-40684 olarak izlenen zero-day açığının kullandığı konusunda uyardı.

Beaumont, FortiGate yöneticilerinin sızıntının kendilerini etkileyip etkilemediğini bilmesi için sızıntıdaki IP adreslerinin bir listesini yayınlamayı planladığını belirtti.

Alman haber sitesi Heise, veri sızıntısını analiz etti.  Analize göre sızıntıdaki bahsi geçen verilerin 2022'de toplandığını ve tüm cihazların FortiOS donanım yazılımı 7.0.0-7.0.6 veya 7.2.0-7.2.2'yi kullandığını söyledi.
“Tüm cihazlar FortiOS 7.0.0-7.0.6 veya 7.2.0-7.2.2 ile donatılmıştı, çoğu da 7.2.0 sürümüne sahipti. Bilgisi sızdırılan cihazların arsında 3 Ekim 2022 tarihinde yayınlanan 7.2.2 sürümünden daha yeni bir FortiOS sürümüne sahip cihaz bulamadık."

DrDisk Lab siber güvenlik uzmanları paylışan verilerin sahte mi yoksa gerçek bir sızıntı mı olduğu hakkkında yapılan analizler sonucunda verinin doğruluğunu belirlemiştir.

Sızıntıdaki verilerin ücretsiz bir şekilde yayınlanmış olmasıyla birlikte, verilere artık erşimin çok daha kolay olduğunu görebiliyoruz. Her ne kadar bu verilerin 2022 0day açığıyla toplanmış olması ve bahsi geçen zaafiyetin Fortinet tarafından yayınlanan yeni FortiOS sürümü ile giderilmesi siber güvenlik noktasında sorunların çözüldüğü anlamına gelmiyor. Zira kullanıcılar söz konusu güncellemenin yapılıp yapılmadığını takip etmemiş ve sistemlerini henüz güncelleme yapmamışlar ise, yazının konu aldığı muhtemel kurbanlardan birisi olmalarının an meselesi olduğunu söylemek, pek de abartılı bir ifade olmaz. 

Yukarıda paylaştığımız ve DrDisk Lab Siber güvenlik uzmanlarının çalışmaları neticesinde elde edilen bilgiler, veri sızıntısında yer alan IP adreslerinde bulunan cihazlarda 2 yıl önce yapılan güncelleme ile bertaraf edilen zafiyetin bu güncellemeyi henüz almamış cihazlarda devam ettiğini gözler önüne sermektedir. Firewall cihazlarınız, sadece elektrik faturasına katkı sağlasın istemiyorsanız, onları güncel tutmak zorunda olduğunuz gerçeğini atlamamalısınız. 2 sene önceki VPN erişim bilgilerini ve Firewall kurallarını kullanmaya devam eden sistemlerin, sızdırılan bu verileri kullanacak olası tehdit aktörlerinin saldırılarına karşı savunmasız olduğunu belirtmek isteriz. Bu durum söz konusu cihazlardan sorumlu olan IT yöneticileri için önem arz etmektedir.

Kaynakça:

BleepingComputer. (2025). Hackers leak configs and VPN credentials for 15,000 FortiGate devices. -Lawrence Abrams Erişim adresi: 

 

Fortinet. (2022). CVE-2022–40684 Güvenlik Duyurusu.

Heise. (2025). FortiGate Veri Sızıntısı Analizi.

2022 zero day was used to raid Fortigate firewall configs. Somebody just released them. - Kevin Beaumont Erişim Adresi:
 

HDD hata yönetimi, sabit disklerin uzun süre güvenilir bir şekilde çalışmasını sağlamak için kullanılan yöntemler bütünüdür. Bu yöntemler, disk üzerindeki hataları tespit edip düzeltmeyi veya yönetmeyi hedefler. HDD hata yönetimi kapsamında sıkça karşılaşılan iki önemli liste, P-List (Primary Defect List) ve G-List (Growth Defect List), diskteki hatalı sektörlerin yönetilmesinde kritik rol oynar

HDD Hata Yönetimi Teknikleri

1. SMART (Self-Monitoring, Analysis, and Reporting Technology):
   • Açıklama: SMART, diskin içsel durumunu izlemek için kullanılan bir teknolojidir. Disk içerisindeki entegre edilmiş sensörler ve yazılımlar, sıcaklık, başarısız okuma/yazma girişimleri, bekleyen sektör (pending sector) sayısı, yeniden yönlendirilen sektör (reallocated sector) sayısı gibi parametreleri izler. SMART, bu verileri kullanarak diskin sağlık durumu hakkında bilgi verir ve potansiyel arızaları önceden tahmin etmeye çalışır. SMART öznitelikleri arasında Raw Read Error Rate, Spin Up Time, Start/Stop Count gibi değerler bulunur.
   • Uygulama: SMART verileri, disk üreticilerinin kendi yazılımları veya genel kullanımda olan araçlarla (örneğin, CrystalDiskInfo, HD Tune. HDD Sentinel) okunabilir. Bu değerlerdeki anormallikler, disk arızası olasılığı konusunda bilgiler verir.
2. Hata Düzeltme Kodları (ECC):
   • Açıklama: ECC, veri okuma ve yazma işlemleri sırasında veri bütünlüğünü korumak için kullanılan matematiksel algoritmalardır. Reed-Solomon kodları veya Hamming kodları gibi ECC algoritmaları, veriye ekstra bilgi ekler. Bu ek bilgi, hatalı bitlerin tespitini ve düzeltilmesini sağlar. ECC, özellikle RAM, HDD ve SSD gibi depolama aygıtlarında kullanılır.
   • Uygulama: ECC, yazılım ve donanım düzeyinde uygulanır. Disk kontrolörü, okunan veriyi ECC ile karşılaştırır ve hata varsa, bu hataları düzeltebilir. Büyük hatalar durumunda, ECC sadece hatayı raporlar ve veri kaybı önlenemezse, kullanıcıya veri bütünlüğünün bozulduğu bilgi verilir.
3. Bad Sector Yönetimi:
   • Açıklama: Bad sector yönetimi, disk üzerinde veri okuma veya yazma işlemlerinde sürekli başarısız olan sektörlerin (bad block) yönetilmesidir. Bu sektörler, SMART tarafından tespit edilir ve disk kontrolörü tarafından işaretlenir. Bad sector yönetimi, disk performansını korurken, hatalı sektörlerin verilere zarar vermesini önler.
   • Uygulama: Hatalı sektörler, yedek sektörlerle değiştirilir. Bu işlem, disk tarafından otomatik olarak yapılır ve kullanıcıya genellikle fark ettirilmez. Disk, bad sector haritalaması için bir tablo tutar ve bu tabloya göre veriye erişim sağlar.
4. Yedekleme ve Yedek Alanlar:
   • Açıklama: Disk üretim sürecinde, potansiyel hatalı sektörler için yedek sektörler ayrılır. Bu yedek sektörler, hatalı sektörlerin yerini almak için kullanılır. Her disk, üretim aşamasında belirli bir sayıda yedek sektörle donatılır. Bu sektörler, bad sector yönetiminde kritik rol oynar ve veri kaybını önler.
   • Uygulama: Yedek sektörler, disk kontrolörü tarafından dinamik olarak yönetilir. Hatalı bir sektör tespit edildiğinde, veri bu yedek alana taşınır ve eski sektör kullanımdan kaldırılır. Bu süreç, SMART tarafından izlenir ve raporlanır.
5. Disk Yeniden Haritalama:
   • Açıklama: Disk yeniden haritalama, hatalı sektörlerin yedek sektörlerle değiştirilmesi sürecidir. Bu işlem, veri kaybını önlemek için disk kontrolörü tarafından otomatik olarak gerçekleştirilir. Yeniden haritalama, bad sector yönetiminin bir parçasıdır ve disk performansını etkilemeden veri bütünlüğünü korur.
   • Uygulama: Bu işlem, bad sector haritalama tablosuna güncellemeler ekleyerek gerçekleştirilir. Disk, veriye erişirken bu tabloyu kullanarak hatalı sektörleri görmezden gelir ve yedek sektörlere yönlendirir.
6. RAID Sistemleri:
   • Açıklama: RAID, birden fazla diskin birlikte kullanılmasıyla veri yedekleme, performans artırma ve hata toleransı sağlanmasıdır. Farklı RAID seviyeleri (RAID 0, RAID 1, RAID 5, RAID 10 vb.) veri parçalama ve yedekleme yöntemlerine dayanır. RAID, disk hatalarına karşı koruma sağlayarak veri kaybını azaltır.
   • Uygulama: RAID sistemlerinde, veri blokları çeşitli disklere dağıtılır. RAID 1'de verilerin bir kopyası iki diske yazılırken, RAID 5'te veri parçalama ve parite bilgisi kullanılır. Hata durumunda, RAID denetleyicisi veri yeniden yapılandırması yapabilir.

P-List (Primary Defect List)

• P-List, üretim sürecinde tespit edilen ve hatalı olarak belirlenen sektörlerin listesidir.
• Özellikler:
  • Sabit: Bu liste, disk ömrü boyunca değişmez. Üretim aşamasında belirlenen hatalı sektörler, disk kullanımı sırasında yeniden değerlendirilmez.
  • Yönetim: Üretim sırasında bu hatalı sektörler yedek sektörlerle değiştirilir, böylece kullanıcı bu hatalardan etkilenmez. Bu işlem, disk üretim sırasında bir kez yapılır.
  • Formatlama: Düşük seviyeli formatlama (low-level formatting) sırasında, disk kontrolörü, P-List'te yer alan sektörlere veri yazmaz, çünkü bu sektörler zaten hatalı olarak işaretlenmiştir.

G-List (Growth Defect List)

• G-List, disk kullanımı sırasında yeni ortaya çıkan hatalı sektörlerin listesidir.
• Özellikler:
  • Dinamik: Bu liste, disk kullanımdayken sürekli güncellenir. Yeni hatalar tespit edildikçe, bu sektörler G-List'e eklenir.
  • Haritalama: Hatalı sektörler, yedek sektörlerle değiştirilir ve veri kaybı önlenir. Bu işlem, kullanıcı verilerinin korunmasını sağlar. G-List, diskin hata yönetim sürecinde dinamik olarak güncellenir.
  • Performans: G-List büyüdükçe, disk performansı olumsuz etkilenebilir çünkü disk, veriye erişmek için daha fazla sektör değişimi yapmak zorunda kalır. Bu, disk erişim sürelerinin artmasına neden olabilir.

P-List ve G-List Karşılaştırması

P-List, G-List ve Yedek Sektörlerin Önemi

• P-List: Diskin üretim aşamasında hatalı sektörlerin yönetilmesini sağlar, kullanıcı bu hatalardan etkilenmeden diski kullanabilir.
• G-List: Disk kullanımı sırasında ortaya çıkan yeni hataları yönetir. G-List’in büyümesi, diskin ömrü ve performansı üzerinde belirleyici olabilir.
• Yedek Sektörler: Yedek sektörler, veri kaybını önlemek için kritik öneme sahiptir. Hatalı sektörler bu yedek alanlarla değiştirildiğinde, veri bütünlüğü korunur. Ancak, yedek sektörler sınırlıdır ve bu kaynak tükendiğinde, disk performansı ve güvenilirliği olumsuz etkilenebilir.

Öneriler

P-List ve G-List yönetimi, HDD’nin güvenilirliğini ve kullanım ömrünü artırır. Kullanıcıların SMART raporlarını, yedek sektörlerin kullanımını ve G-List büyüklüğünü belli periyotlarla takip etmeleri veri bütünlüğü ve güvenliği açısından önemlidir. G-List büyümeye devam ederse veya yedek sektörler tükenmeye yaklaşırsa, diski değiştirmek veya kapsamlı bir yedekleme stratejisi uygulamak gerekecektir.