← Blog'a dön
2026-08-21 | 0gulcandogan | Medium'dan aktar&305;ld&305; | 16 dk okuma

Binayı VE Odayı Güvenli Hale Getirdiğinizde

When You Secure the Building AND Room

Bu diziyi takip ediyorsanız, şimdiye kadarki tartışmaların çoğu anahtarın kimin elinde olduğu üzerineydi: IAM kullanıcıları yerine IAM rolleri, statik erişim anahtarları yerine geçici kimlik bilgileri, AWS dışında bulunan iş yükleri için X.509 sertifikaları. Bunların hepsi önemli, ancak bir anahtar, açtığı binanın hâlâ duvarları varsa işe yarar.

Bu sefer kimlik konusundan duvarlar, kapılar ve kameralara geçiyoruz — yani bir isteğin kaynaklarınıza ulaşıp ulaşamayacağını belirleyen katmanlara. Bu aynı zamanda AWS Certified Security Specialty (SCS-C03) sınavında tekrar tekrar karşımıza çıkan konulardan biridir; bu nedenle bunu hem zihinsel bir model hem de bir dizi sınav notu olarak değerlendirin.

En küçük çevreden (tek bir alt ağ) başlayarak DNS ve felaket kurtarmaya kadar ilerleyeceğiz.

Aynı Bina İçin İki Güvenlik Görevlisi

AWS ağları ile ilgili her konuşma eninde sonunda aynı iki kısaltmaya gelir ve bunlar her seferinde karıştırılır. Bu konuyu bir kez ve sonsuza kadar açıklığa kavuşturalım.

Güvenlik grubu, oda güvenliğidir. Tek bir odanın kapısına (bir EC2 örneği, bir RDS örneği, ENI'si olan herhangi bir şey) eklenir ve yalnızca o odaya giren veya o odadan çıkan trafiği ilgilendirir.

Ağ ACL’si ise bina güvenliğidir. Alt ağ düzeyinde bulunur ve hangi odaya gitmekte olduklarına bakılmaksızın, binaya giren veya binadan çıkan herkesi denetler.

Bu tablo sınavda sık sık karşımıza çıkar, çünkü bu iki kontrol mekanizması birbirine benzer görünse de farklı şekillerde başarısız olur. Açık bir kuralı olmayan bir güvenlik grubu, trafiği sessizce reddeder. Yeni oluşturulan bir özel ACL de aynı şeyi yapar; varsayılan olarak her şeyi reddettiğini hatırlayana kadar, daha önce izin verdiğiniz bir isteğe yönelik giden yanıtı da dahil olmak üzere. Ağ alanında, “neden bu sunucuya SSH ile bağlanamıyorum” şeklindeki hata giderme oturumlarının arkasında, neredeyse her şeyden daha çok bu kombinasyon yatmaktadır.

Veriler Ağa Ulaşmadan Önce Yolun Şifrelenmesi

Kendi ağınızı VPN veya Direct Connect aracılığıyla AWS’ye bağladığınızda, farklı bir dizi sorun ortaya çıkar.

Üç hibrit bağlantı seçeneğiniz vardır: AWS tarafından yönetilen VPN (donanım tabanlı), müşteri tarafından yönetilen VPN (yazılım tabanlı, bir EC2 örneğinde veya kendi cihazınızda çalışan) ve Direct Connect.

Hangisini seçerseniz seçin, aktarım halindeki trafiğin üç unsurun korunması gerekir:

AWS tarafından yönetilen VPN, bu üç unsuru da otomatik olarak uygular. Müşteri tarafından yönetilen VPN'i tercih etmenin tek gerçek nedeni, AWS'nin desteklemediği bir algoritmaya ihtiyaç duyulmasıdır.

IPsec tek başına tek bir protokol değildir; üç bölümden oluşan bir pakettir:

IKE, iki aşamada müzakere eder. 1. Aşama, iki eş arasında güvenli bir kanal kurar; bunun tek amacı, 2. Aşama müzakeresi için güvenli bir ortam sağlamaktır. 2. Aşama ise, gerçek VPN trafiğinin nasıl şifreleneceği ve kimlik doğrulamasının nasıl yapılacağı konusunda anlaşmaya varılan aşamadır.

AWS tarafından yönetilen Site-to-Site VPN bağlantısı, her biri bağımsız olarak yapılandırılmış iki tünel sağlar — her birinin kendi Aşama 1/2 şifreleme algoritması, bütünlük algoritması, Diffie-Hellman grubu ve IKE sürümü vardır. Tünelin her iki ucu da aynı ayarlar üzerinde anlaşmalıdır; eğer sizin tarafınızı AES-256’ya kilitlerseniz ve şirket içi cihazınız bunu desteklemiyorsa, tünel kurulamaz. Genel bir kural olarak: DH grup numarası ne kadar yüksekse, anahtar o kadar uzun ve şifreleme o kadar güçlü olur.

Direct Connect Aslında Şifrelenmemiştir

İşte neredeyse herkesin en az bir kez düştüğü tuzak: Direct Connect varsayılan olarak şifrelenmez. Bu, özel bir ağ bağlantısıdır ve “güvenli” anlamına gelmesi gerektiği hissi uyandırır, ancak “özel” ve “şifreli” iki farklı özelliktir. Direct Connect üzerinde şifrelemeye ihtiyacınız varsa, iki seçeneğiniz vardır.

Seçenek 1: Direct Connect üzerinden bir VPN çalıştırın. Bu, size bir Public VIF (Private VIF değil — bu ayrım önemlidir) sağlar, müşteri ağ geçidinizin genel IP adresini ve öneklerini duyurur ve ardından sanal özel ağ geçidi veya transit ağ geçidi aracılığıyla üzerine standart bir Site-to-Site VPN bağlantısı ekler. Sonuç: Direct Connect’in düşük gecikme süresi ve yüksek bant genişliği, bir VPN’in şifrelemesiyle birleştirilir.

Seçenek 2: MACsec'i etkinleştirin. Bu seçeneği ayrıntılı olarak ezberlemeye değer, çünkü kısıtlamaları tam da sınav sorularında sıklıkla test edilen türden:

Bu bölümden başka hiçbir şeyi hatırlamasanız bile şunu unutmayın: Bir soruda Direct Connect ve “şifreleme” aynı cümlede geçiyorsa, ilk olarak şifrelemenin gerçekten açık olup olmadığını kontrol etmelisiniz; zaten açık olduğunu varsaymamalısınız.

VPC’ye Gerçek Bir Güvenlik Duvarı Getirmek

Güvenlik grupları ve NACL’ler size erişim kontrolü sağlar. Ancak size sağlamadıkları şey, derin paket incelemesi, saldırı önleme veya bir VPC’nin tüm trafiği genelinde merkezi günlük kaydıdır. AWS Network Firewall işte bu boşluğu doldurur.

Tamamen yönetilen bir çözümdür; yama gerektiren bir altyapı yoktur, birkaç tıklamayla devreye alınır ve ayrıntılı kuralları, açık kaynaklı kural setlerinin içe aktarılmasını ve üçüncü taraf tehdit istihbaratı beslemelerini destekler. Ayrıca Firewall Manager ile entegre olduğundan, her bir VPC’yi manuel olarak yapılandırmak yerine kuralları tüm kuruluş genelinde uygulayabilirsiniz. Tipik kullanım örnekleri: VPC'den VPC'ye denetim, giden trafik filtreleme, Direct Connect veya VPN üzerinden trafiğin güvenliğini sağlama ve genel internet trafiği filtreleme.

Dikkat edilmesi gereken bazı özellikler:

Güvenlik Duvarını Nereye Yerleştirdiğiniz Her Şeyi Değiştirir

Network Firewall'un varlığını bilmek bir şeydir. Mimarinizde onu nereye yerleştireceğinizi bilmek ise sınavın asıl sizi yakalamaya çalıştığı noktadır, çünkü üç dağıtım modeli vardır ve her biri maliyet, etki alanı ve gerçekte hangi trafiği görebileceği açısından farklılık gösterir.

Doğrudan sormakta fayda var: 50 VPC’niz varsa ve dağıtık modeli seçerseniz, 50 ayrı güvenlik duvarına ihtiyacınız olur mu? Evet. Bu tek gerçek, dağıtık modelin ne zaman mantıklı olduğunu (küçük etki alanı, izole iş yükleri) ve ne zaman mantıklı olmadığını (30. VPC’ye ulaşmadan çok önce yönetim yükü altında boğulursunuz) neredeyse tamamen ortaya koyar.

İş İçin Doğru Güvenlik Duvarını Seçmek

Üç ağ katmanı kontrolü söz konusu olduğunda, asıl karar genellikle kapsam ve derinliğe bağlıdır:

Tam kontrol, günlük kaydı ve uygulama katmanı denetimi gerekiyorsa Network Firewall'u tercih edin. Gerekmiyorsa, NACL gerçekten yeterlidir; belirli bir CIDR aralığına “hayır” demesi gereken bir alt ağ sınırını gereğinden fazla karmaşık hale getirmeye gerek yoktur.

Her Binadaki Tüm Güvenlik Önlemlerini Tek Seferde Yönetme

Tek bir AWS hesabı kullanıyorsanız bunların hiçbiri çok önemli değildir. Ancak elli hesap kullanıyorsanız çok önemlidir. AWS Firewall Manager, birden fazla hesapta güvenlik politikasını merkezi olarak yönetmek için tasarlanmıştır ve beş hizmeti kapsar: AWS WAF, Shield Advanced, Network Firewall, VPC güvenlik grupları ve Route 53 Resolver DNS Firewall.

Kurulumunda sıkı bir işlem sırası vardır ve sınavda bu sıra sıklıkla test edilir:

  1. Hangi hesabın Firewall Manager yönetici hesabı olacağını seçin.
  2. Bu hesap, AWS Organizations'ın bir parçası olmalı ve çok önemli bir nokta olarak, sadece konsolide faturalandırma değil, "tüm özelliklerin etkinleştirilmiş" olması gerekir. Bu, tüm iş akışında en sık karşılaşılan zorluk noktasıdır.
  3. Bu hesabı Firewall Manager yönetici hesabı olarak yapılandırın.
  4. Koruma altına almayı planladığınız her hesapta ve bölgede AWS Config'i etkinleştirin.
  5. Ağ Güvenlik Duvarı veya DNS Güvenlik Duvarı ilkeleri istiyorsanız, AWS RAM'de "AWS Organizations ile paylaşımı etkinleştir" seçeneğini açın.
  6. Hem yönetim hesabında hem de Firewall Manager yönetici hesabında varsayılan olarak devre dışı bırakılmış tüm bölgeleri etkinleştirin.

Bu işlem tamamlandığında, Firewall Manager, yönettiği beş hizmete karşılık gelen beş tür ilke üzerinden çalışır: WAF İlkesi, Shield Advanced İlkesi, Ağ Güvenlik Duvarı İlkesi, VPC Güvenlik Grubu İlkesi ve Route 53 Resolver DNS Güvenlik Duvarı İlkesi. Bir ilke oluşturmak genellikle beş adımı içerir (Ağ Güvenlik Duvarı ve Güvenlik Grubu ilkeleri için altıncı bir adım daha eklenir): ilke türünü ve bölgeyi seçin, ilkenin kendisini tanımlayın (ad, kurallar, eylem), kapsamını tanımlayın (hangi hesaplar ve kaynaklar, etiketlere göre dahil etme/hariç tutma), isteğe bağlı olarak etiketler ekleyin, ardından gözden geçirip oluşturun. Bölge başına politika başına yaklaşık 100 dolarlık bir bütçe ayırın; buna ek olarak, altta yatan kural değerlendirmeleri için AWS Config’in uyguladığı ücretleri de hesaba katın.

İki politika türüne daha yakından bakmaya değer. WAF politikaları, bir Web ACL’nin kendi kurallarından hem önce hem de sonra çalışır; hesap sahipleri bu aralığa kendi kurallarını ekleme özgürlüğüne sahiptir; bu, merkezi kontrol ile yerel esneklik arasında makul bir uzlaşmadır. Güvenlik Grubu ilkeleri üç türde gelir: Ortak SG (yeni bir güvenlik grubunu tüm organizasyona dağıtma), Denetim ve uygulama (mevcut kuralların uyumluluğunu sağlama) ve Denetim ve temizleme (kullanılmayan veya gereksiz güvenlik gruplarını bulup kaldırma).

Güvenlik Görevlisine Kötü Niyetli Ziyaretçileri Tanımayı Öğretmek

Şimdiye kadar her şey, trafiğin nereye gitmesine izin verildiği ile ilgiliydi. AWS WAF ise bu trafiğin gerçekte ne içerdiğiyle ilgilidir. CloudFront, API Gateway REST API’leri, Uygulama Yük Dengeleyicileri ve AppSync GraphQL API’lerinin önünde yer alır ve OWASP Top 10’u (SQL enjeksiyonu, siteler arası komut dosyası çalıştırma) ve belirli IP’leri veya bütün ülkeleri engelleme gibi tanımladığınız herhangi bir özel kriteri yakalamak üzere tasarlanmıştır.

(Bir not: AWS’nin kendi belgelerinde iki sürüm bulunmaktadır — Kasım 2019’dan önceki WAF Classic ve güncel WAF. Sınav sorularında herhangi bir yerde “Classic” ifadesini görürseniz, bunu bir cevap olarak değil, tarihsel bir dipnot olarak değerlendirin.)

İşte bileşen hiyerarşisi; çünkü diğer her şey bunun üzerine inşa edilmiştir:

Web ACL (the main building block — default action: allow or block)
  └── Rules (a statement + an action: allow / block / count)
       └── Rule Groups (reusable collection of rules)

Trafik akışı, en azından CloudFront’un arkasında bulunan bir kaynak için basittir: kullanıcının isteği önce CloudFront’a ulaşır, CloudFront bunu Web ACL’ye iletir, WAF bunu değerlendirir ve sonuç geri gelir — “izin ver” isteğin CloudFront’a devam ettiği anlamına gelirken, “engelle” ise daha ileriye gitmediği anlamına gelir. Temel ilke, WAF’ın çok ötesine de genellenebilir: Bir güvenlik kontrolü çevreye ne kadar yakınsa, kötü niyetli bir istek durdurulana kadar o kadar az hasar verebilir.

Kurallar ve Kural Grupları: Daha Ayrıntılı Bilgi

Bir Web ACL’ye kural eklerken, AWS veya F5, Fortinet, Imperva, GeoGuard gibi satıcılar tarafından yönetilen Yönetilen Kural Grupları arasında seçim yapabilir ya da kendi kurallarınızı yazabilirsiniz.

Burada kullanıcıların kafasını karıştıran rakam WCU, yani Web ACL Kapasite Birimidir. Her Web ACL'nin 1.500 WCU'luk sabit bir üst sınırı vardır. Bir kural grubu oluşturduğunuzda, oluşturulma anında değiştirilemez maksimum kapasitesini belirlersiniz ve bu rakam daha sonra asla değiştirilemez. Bunun nedeni ince ama önemlidir: Eğer başka bir Web ACL de aynı kural grubunu kullanıyorsa, kapasitesinin öngörülemez bir şekilde artmasına izin vermek, o diğer Web ACL’yi uyarı yapılmaksızın kendi 1.500 sınırının üzerine çıkarabilir. Sınırı önceden sabitlemek sadece sizi değil, kural grubunu paylaşan diğer herkesi de korur.

Özel kurallar genellikle birkaç şekilde olabilir:

Kuralların kendisi iki türdür. Normal kurallar, izin verme, engelleme veya sayma eylemiyle birlikte basit bir "eğer/o zaman" yapısına sahiptir. Hız tabanlı kurallar, 5 dakikalık bir zaman aralığı boyunca kaynak IP başına istek sayısını sayar ve eylemleri yalnızca engelleme veya sayma olabilir. Hız tabanlı bir kuralda izin verme eylemi yoktur; bu, kuralın amacına bakıldığında mantıklıdır: bu kural, “çok fazla” demek için vardır, asla “yeterli değil” demek için değil.

İşte, Kural Oluşturucu’ya yapıştırabileceğiniz türden, hız tabanlı bir kuralın JSON biçiminde nasıl göründüğüne dair basit bir örnek:

{
  "Name": "LimitRequestsPerIP",
  "Priority": 2,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 2000,
      "AggregateKeyType": "IP"
    }
  },
  "Action": { "Block": {} },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "LimitRequestsPerIP"
  }
}

Burada öncelik, kelimenin tam anlamıyla önemlidir: kurallar sırayla çalıştırılır ve ilk eşleşen kural geçerlidir. Tipik ve mantıklı bir sıralama şöyledir: önce izin verilen IP’ler (beyaz liste), sonra engellenen IP’ler (kara liste) ve en son olarak da bilinen kötü imzalar (SQLi, XSS kalıpları) engellenir. Bu sırayı tersine çevirirseniz, beyaz listede yer alan bir IP, izin kuralı devreye girme şansı bulamadan önce tetiklenen bir imza kuralı tarafından yine de yakalanabilir.

Özetlenmiş Demo Akışı

Bunu ilk kez kuruyorsanız, uygulamaya yönelik sıra şöyledir: bir IP Kümesi (CIDR artı bölge) oluşturun, bir Kural Grubu oluşturun ve maksimum kapasitesini ayarlarken bu gruba kurallar ekleyin, ardından Web ACL’yi oluşturun, bunu CloudFront dağıtımı gibi bir kaynağa ekleyin, kural grubunu ekleyin ve varsayılan bir eylem seçin.

Dikkat edilmesi gereken bir nokta: Bir kural grubu, o anda kullandığı WCU ne olursa olsun, kuralları bu kapasiteyi dolduracak kadar artsa da artmasa da, Web ACL içinde belirlediğiniz maksimum kapasiteyi işgal eder. 1.500 WCU bütçenizi bunu göz önünde bulundurarak planlayın.

Kalabalık Kendisi Silah Olduğunda

Şimdiye kadar yapılan tüm varsayımlar, savunma sistemlerinize gelen trafiğin meşru ancak istenmeyen olduğu yönündeydi. Bazen bu trafik ne meşru ne de azdır; sadece hacimlidir ve bu hacim başlı başına bir saldırıdır.

DoS, tek bir kaynaktan gelen bir seldir. DDoS ise aynı anda birçok kaynaktan gelen bir seldir; genellikle bir botnet (bot ağı), bir veya daha fazla C&C (komuta ve kontrol) sunucusu ve tüm süreci koordine eden bir botmaster içerir. LOIC ve HOIC (Low/High Orbit Ion Cannon) gibi araçlar, bu tür saldırıları teknik becerisi çok az olan kişilerin bile gerçekleştirebilmesini sağladı; bu da tehdidin bu kadar yaygın kalmasının nedenlerinden biridir.

Adlarını bilmeye değer iki saldırı modeli:

Yönetilen Koruma: AWS Shield

AWS Shield, AWS’nin bu saldırı modellerine yönelik yönetilen yanıtıdır; Katman 3 (ağ), Katman 4 (aktarım) ve Katman 7 (uygulama) düzeylerinde saldırıları algılar ve etkisini azaltır.

Shield etrafında bir CloudWatch panosu oluşturuyorsanız, aslında ihtiyacınız olan metrikler şunlardır: L3/L4 olayları için DDoSDetected, DDoSAttackBitsPerSecond ve DDoSAttackPacketsPerSecond; L7 için ise DDoSAttackRequestsPerSecond.

İçeriği Depodan Değil, Kenardan Sunma

Her savunma, trafiği engellemekle ilgili değildir. Bazı savunma yöntemleri, trafiğin başlangıç noktasına hiç ulaşmamasını sağlamaya yöneliktir.

Bu nedenle CloudFront, bir performans aracı olduğu kadar bir güvenlik aracıdır da: 300'den fazla uç konumunda içeriği önbelleğe alarak, S3'teki statik içerik ile EC2 veya Lambda'dan sunulan dinamik içerik için gecikmeyi azaltır.

Önbellekleme üç katmanda gerçekleşir:

  1. Kenar konumları (300+)
  2. Bölgesel kenar önbellekleri (13)
  3. Origin Shield (isteğe bağlı, varsayılan olarak kapalı, kaynak başına etkinleştirilebilir) → daha iyi önbellek isabet oranı, kaynağınızda daha az yük

Güvenlik açısından CloudFront size şunları sunar:

Sürekli olarak iki kaynak modeli karşımıza çıkar ve her ikisi de aynı temel riski paylaşır: kaynağınıza giden ikinci, korumasız bir yol varsa, CloudFront (ve önündeki her şey) isteğe bağlıdır, zorunlu değildir.

Ardından, bir OAI (Origin Access Identity) ve yalnızca bu OAI'ye güvenen bir kova politikası ile kovayı kilitleyin; böylece genel erişim tamamen kapatılır ve CloudFront, içeriğe giden tek yol haline gelir. Bu adımı atlarsanız, ham S3 depo URL'si hâlâ çalışır; bu da, onu bulan herkesin yukarıdaki ALB modelinde olduğu kadar kolay bir şekilde CloudFront'u (ve önündeki her şeyi) atlayabileceği anlamına gelir.

İnterneti Çalıştıran Telefon Rehberi

Tüm bunların altında DNS yer alır ve AWS’de bu Route 53’tür. Genel Barındırılan Bölge, internet yönlendirmesini yönetir; Özel Barındırılan Bölge ise bir VPC içindeki çözümlemeyi yönetir (bunun çalışması için hem DNS Ana Bilgisayar Adları hem de DNS Desteği’nin etkinleştirilmesi gerekir). Her barındırılan bölge, talep etseniz de etmeseniz de otomatik olarak 4 NS kaydı ve 1 SOA kaydı ile birlikte gelir.

Sağlık Kontroller

Varsayılan olarak Route 53, bir kaynağın durumunu her 30 saniyede bir (daha yüksek bir maliyet karşılığında 10 saniyelik kontroller de mevcuttur) TCP, HTTP veya HTTPS üzerinden kontrol eder; bu kontrol, isteğe bağlı olarak yanıtın ilk 5.120 baytıyla dize eşleştirme yoluyla gerçekleştirilir. Ayrıca bir CloudWatch alarmının durumunu doğrudan izleyebilir: OK, sağlıklı anlamına gelir; ALARM, sağlıksız anlamına gelir; INSUFFICIENT ise her iki şekilde de yapılandırılabilir. Buradaki tuzağa dikkat edin: Sağlık kontrolü eklenmemiş bir kayıt, arkasındaki kaynak tamamen çökmüş olsa bile her zaman sessizce sağlıklı olarak kabul edilir.

Bunlardan ikisi özellikle dikkat gerektirir. Basit yönlendirme, yedekleme mantığına ihtiyacınız varsa gerçekten bir sağlık kontrolü kullanamaz; bu durumda yanlış politika seçmişsiniz demektir. Ayrıca Coğrafi Yakınlık, Trafik Akışı’nın arkasında kilitlidir; bunu basit bir kayıt aracılığıyla yapılandıramazsınız.

Trafik Akışı, birden fazla yönlendirme politikasını ve sağlık kontrolünü tek bir sürümlenmiş Trafik Politikası'nda birleştirmenize olanak tanıyan görsel bir düzenleyicidir. Bir Politika Kaydı, bu trafik politikasını gerçek bir etki alanına veya alt etki alanına bağlar ve tek bir trafik politikası, birden fazla barındırma bölgesinde yüzlerce kayıt oluşturmak için yeniden kullanılabilir.

Tüm Bölge Çöktüğünde

Yukarıdaki tüm açıklamalar, altyapınızın çalışır durumda olduğunu varsaymaktadır. Uygulama Kurtarma Denetleyicisi (ARC), altyapınızın çalışmadığı anlar için tasarlanmıştır ve uygulamanızın Kullanılabilirlik Bölgeleri, bölgeler veya şirket içi ortamlarda kurtarma yeteneğini izler ve denetler.

ARC’nin temel amacı şudur: “Yedek bir bölgemiz var” ve “o bölgeye güvenli bir şekilde yedekleme yapabiliriz” ifadeleri birbirinden çok farklıdır. ARC, bu iki ifade arasındaki boşluğu dolduran unsurdur.

Aynı Çevre, Birçok Katman

Bir adım geriye gidip yukarıdakilere baktığımızda bir örüntü ortaya çıkıyor: burada hiçbir şey izole bir şekilde çalışmıyor ve hiçbir şey bu şekilde tasarlanmadı. NACL'si olmayan bir güvenlik grubu sorun değildir. Ağ Güvenlik Duvarı olmayan bir NACL de sorun değildir. Shield olmayan bir WAF, sorun çıkmadıkça sorun değildir. AWS’nin güvenlik modeli, en azından bu alanda, herhangi bir katmanın er ya da geç arızalanacağı veya yanlış yapılandırılacağı varsayımına dayanır ve sizi asıl kurtaran, onun arkasındaki katmandır.

Özellikle sınava hazırlanıyorsanız, bu alanda en sık karşılaşılan tuzakların özet bir listesi aşağıda yer almaktadır:

Bu, bu serinin sürekli vardığı dersin aynısıdır, sadece bir katman daha öteye uygulanmıştır: kimlik size kapıdan geçmenizi sağlar, ancak bu kimliğin bir anlamı olması için kapının, duvarların ve yanında duran muhafızın gerçekten orada olması ve doğru şekilde yapılandırılması gerekir.

Artık Veri Koruma bölümünü de tamamladığımıza göre, yavaş yavaş rahatlamaya başlayabiliriz. Sonuna gittikçe yaklaşıyoruz.

Bir kez daha, bu seriyi okumak ve uygulamaya koymak size herhangi bir şekilde yardımcı olduysa, bunu duymaktan gerçekten mutluluk duyarım.

Bir sonraki blog yazısında görüşmek üzere, kendinize iyi bakın ❤

Kaynaklar

Orijinal: https://medium.com/@0gulcandogan/when-you-secure-the-building-and-room-25f85a901d47?source=rss-746132cb79a8------2

#network-security#aws-shield#aws#devsecops#aws-waf

İlgili yazılar

2026-07-20Anahtara Sahip Olmak Her Kapıyı Her Zaman Açmaz: Her Yerde Kullanılabilen IAM Rolleri2026-07-17Eski Bir Arkadaş Bir Anahtarla Ortaya Çıktı: İnsan Dışı Kimlik Yönetimi2026-08-25AWS’de Kimse Fark Etmeden Hiçbir Şey Hareket Etmez: Tehdit Algılama Kılavuzu
Okuduğunuz için teşekkürler

Bu yazı işinize yaradıysa paylaşmayı veya logdaki diğer yazıları keşfetmeyi düşünebilirsiniz.

← Tüm yaz&305;lar Yazar hakk&305;nda