Bulut ortamlar\u0131nda g\u00fcvenlik denildi\u011finde akla ilk gelen genellikle gelen (inbound) trafi\u011fi korumak olur. Sunucular\u0131m\u0131za d\u0131\u015far\u0131dan gelebilecek sald\u0131r\u0131lara, yetkisiz eri\u015fimlere veya k\u00f6t\u00fc ama\u00e7l\u0131 isteklere kar\u015f\u0131 \u00f6nlemler almak, web uygulamalar\u0131m\u0131z\u0131 bir g\u00fcvenlik duvar\u0131n\u0131n (firewall) arkas\u0131na gizlemek \u00e7o\u011fu zaman \u00f6nceliklidir. Ancak, dijital d\u00fcnyada tek y\u00f6nl\u00fc bir tehdit ak\u0131\u015f\u0131 yoktur. Peki ya sistemlerinizden d\u0131\u015far\u0131ya do\u011fru akan (outbound) trafik? AWS altyap\u0131n\u0131zdaki bir sunucunun, bir konteynerin veya sunucusuz (serverless) bir fonksiyonun bilginiz d\u0131\u015f\u0131nda k\u00f6t\u00fc ama\u00e7l\u0131 bir sunucuyla ileti\u015fim kurdu\u011funu, hassas verilerinizi d\u0131\u015far\u0131 s\u0131zd\u0131rd\u0131\u011f\u0131n\u0131 veya bir fidye yaz\u0131l\u0131m\u0131 (ransomware) sald\u0131r\u0131s\u0131 ba\u015flatt\u0131\u011f\u0131n\u0131 hayal edin. \u0130\u015fte tam da bu noktada, giden trafik g\u00fcvenli\u011fi, siber savunma stratejinizin vazge\u00e7ilmez bir par\u00e7as\u0131 haline gelir.<\/p>\n
Gelen trafik g\u00fcvenli\u011fi genellikle “kale duvarlar\u0131” in\u015fa etmek olarak tan\u0131mlan\u0131rken, giden trafik g\u00fcvenli\u011fi “kalenin i\u00e7inden d\u0131\u015far\u0131ya a\u00e7\u0131lan kap\u0131lar\u0131 kontrol etmek” anlam\u0131na gelir. \u00c7o\u011fu kurulu\u015f, d\u0131\u015far\u0131dan i\u00e7eriye y\u00f6nelik tehditlere odaklan\u0131rken, i\u00e7eriden d\u0131\u015far\u0131ya do\u011fru ger\u00e7ekle\u015febilecek potansiyel tehlikeleri g\u00f6z ard\u0131 edebilir. Oysa bu t\u00fcr tehditler, genellikle daha y\u0131k\u0131c\u0131 sonu\u00e7lara yol a\u00e7abilir \u00e7\u00fcnk\u00fc i\u00e7 sistemlere zaten bir \u015fekilde eri\u015fim sa\u011flanm\u0131\u015ft\u0131r.<\/p>\n
Giden trafik g\u00fcvenli\u011fini ihmal etmek, AWS ortam\u0131n\u0131zda bir dizi ciddi riske kap\u0131 aralar. Bu riskler, basit yap\u0131land\u0131rma hatalar\u0131ndan sofistike siber sald\u0131r\u0131lara kadar geni\u015f bir yelpazeyi kapsar. \u00d6ncelikle, k\u00f6t\u00fc ama\u00e7l\u0131 yaz\u0131l\u0131mlar\u0131n (malware) veya fidye yaz\u0131l\u0131mlar\u0131n\u0131n komuta ve kontrol (Command and Control – C2) sunucular\u0131yla ileti\u015fim kurmas\u0131, en yayg\u0131n tehditlerden biridir. Bir sald\u0131rgan, sisteminize s\u0131zd\u0131ktan sonra, genellikle C2 sunucular\u0131 arac\u0131l\u0131\u011f\u0131yla talimatlar al\u0131r, ek k\u00f6t\u00fc ama\u00e7l\u0131 yaz\u0131l\u0131mlar indirir veya sald\u0131r\u0131n\u0131n bir sonraki a\u015famas\u0131n\u0131 planlar. E\u011fer giden trafik kontrol alt\u0131nda de\u011filse, bu ileti\u015fim kolayca ger\u00e7ekle\u015febilir ve tespit edilmesi zorla\u015f\u0131r.<\/p>\n
Bir di\u011fer kritik risk ise veri s\u0131zmas\u0131 (data exfiltration) veya veri h\u0131rs\u0131zl\u0131\u011f\u0131d\u0131r. Sald\u0131rganlar, ele ge\u00e7irdikleri hassas m\u00fc\u015fteri verilerini, fikri m\u00fclkiyet bilgilerini veya finansal kay\u0131tlar\u0131, AWS ortam\u0131n\u0131zdan kendi kontrol\u00fcndeki sunuculara aktarmak isteyebilirler. E\u011fer giden trafik kurallar\u0131 bu t\u00fcr aktar\u0131mlar\u0131 k\u0131s\u0131tlam\u0131yorsa, b\u00fcy\u00fck \u00f6l\u00e7ekli veri ihlalleri meydana gelebilir ve bu durum, ciddi itibar kayb\u0131na, yasal sorunlara ve finansal cezalara yol a\u00e7abilir. \u00d6rne\u011fin, bir veritaban\u0131 sunucusunun normalde sadece belirli bir yedekleme hizmetiyle veya bir analiz platformuyla konu\u015fmas\u0131 gerekirken, aniden bilinmeyen bir IP adresine b\u00fcy\u00fck miktarda veri g\u00f6ndermesi ciddi bir alarm i\u015faretidir.<\/p>\n
Ayr\u0131ca, yap\u0131land\u0131rma hatalar\u0131 veya k\u00f6t\u00fc ama\u00e7l\u0131 i\u00e7 akt\u00f6rler (insider threat) de giden trafik \u00fczerinden sorun yaratabilir. Yanl\u0131\u015fl\u0131kla a\u00e7\u0131lan geni\u015f kapsaml\u0131 giden trafik kurallar\u0131, bir uygulaman\u0131n gereksiz yere internetin tamam\u0131na eri\u015fmesine izin verebilir. Bu durum, uygulaman\u0131n g\u00fcvenlik a\u00e7\u0131klar\u0131ndan yararlan\u0131larak farkl\u0131 k\u00f6t\u00fc ama\u00e7l\u0131 faaliyetler i\u00e7in kullan\u0131lmas\u0131na zemin haz\u0131rlayabilir. \u00d6rne\u011fin, bir EC2 \u00f6rne\u011finin (instance) yanl\u0131\u015fl\u0131kla bir spam botnet’inin par\u00e7as\u0131 haline gelmesi veya bir kripto para madencili\u011fi (cryptocurrency mining) sald\u0131r\u0131s\u0131nda kullan\u0131lmas\u0131 m\u00fcmk\u00fcnd\u00fcr. Bu t\u00fcr durumlar, AWS faturalar\u0131n\u0131zda beklenmedik art\u0131\u015flara ve a\u011f performans\u0131nda d\u00fc\u015f\u00fc\u015flere de neden olabilir.<\/p>\n
Son olarak, uyumluluk (compliance) ve reg\u00fclasyonlar da giden trafik g\u00fcvenli\u011fini zorunlu k\u0131lar. GDPR, HIPAA, PCI DSS gibi bir\u00e7ok d\u00fczenleme, hassas verilerin nas\u0131l i\u015flendi\u011fi, sakland\u0131\u011f\u0131 ve aktar\u0131ld\u0131\u011f\u0131 konusunda kat\u0131 kurallar i\u00e7erir. Giden trafi\u011fin izlenmesi ve kontrol edilmesi, bu d\u00fczenlemelere uyum sa\u011flamak i\u00e7in temel bir gerekliliktir. Kapsaml\u0131 bir giden trafik stratejisi olmadan, denetimlerde (audits) ba\u015far\u0131s\u0131z olma riskiyle kar\u015f\u0131 kar\u015f\u0131ya kalabilirsiniz. T\u00fcm bu nedenler g\u00f6z \u00f6n\u00fcne al\u0131nd\u0131\u011f\u0131nda, giden trafik g\u00fcvenli\u011fi, AWS ortam\u0131n\u0131z\u0131n genel g\u00fcvenlik duru\u015funun ayr\u0131lmaz ve kritik bir bile\u015fenidir.<\/p>\n
AWS’te giden trafik g\u00fcvenli\u011fini sa\u011flamak i\u00e7in kullan\u0131lan temel bile\u015fenler, sanal a\u011f altyap\u0131s\u0131n\u0131n (Virtual Network Infrastructure) kalbinde yer al\u0131r. Bu bile\u015fenler, trafi\u011fi filtrelemek, izlemek ve y\u00f6nlendirmek i\u00e7in birlikte \u00e7al\u0131\u015f\u0131r. Bu b\u00f6l\u00fcmde, AWS ortam\u0131nda giden trafik g\u00fcvenli\u011fini sa\u011flayan ana yap\u0131 ta\u015flar\u0131n\u0131 inceleyece\u011fiz.<\/p>\n
Her \u015feyin ba\u015flad\u0131\u011f\u0131 yer Sanal \u00d6zel Bulut (VPC – Virtual Private Cloud) kavram\u0131d\u0131r. VPC, AWS bulutunda sizin i\u00e7in ayr\u0131lm\u0131\u015f, mant\u0131ksal olarak izole edilmi\u015f bir a\u011fd\u0131r. Kendi IP adres aral\u0131klar\u0131n\u0131z\u0131 tan\u0131mlayabilir, alt a\u011flar (subnets) olu\u015fturabilir ve sanal a\u011f ge\u00e7itleri (gateways) ile y\u00f6nlendirme tablolar\u0131n\u0131 (route tables) yap\u0131land\u0131rabilirsiniz. Giden trafik g\u00fcvenli\u011fi i\u00e7in VPC, a\u011f segmentasyonunun (network segmentation) temelini olu\u015fturur. \u00d6rne\u011fin, veritaban\u0131 sunucular\u0131n\u0131z\u0131, uygulama sunucular\u0131n\u0131z\u0131 ve web sunucular\u0131n\u0131z\u0131 farkl\u0131 alt a\u011flara yerle\u015ftirmek, aralar\u0131ndaki trafi\u011fi daha kolay kontrol etmenizi sa\u011flar. Genellikle, internete do\u011frudan eri\u015fime ihtiya\u00e7 duymayan hassas kaynaklar (veritabanlar\u0131 gibi) \u00f6zel alt a\u011flara (private subnets) yerle\u015ftirilirken, web sunucular\u0131 gibi d\u0131\u015far\u0131dan eri\u015filebilir olmas\u0131 gereken kaynaklar genel alt a\u011flara (public subnets) konumland\u0131r\u0131l\u0131r. Bu ayr\u0131m, giden trafik kontrol\u00fc i\u00e7in ilk ad\u0131md\u0131r.<\/p>\n
G\u00fcvenlik Gruplar\u0131 (Security Groups), AWS’te sanal g\u00fcvenlik duvarlar\u0131 (virtual firewalls) olarak i\u015flev g\u00f6r\u00fcr ve bir EC2 \u00f6rne\u011fi (instance) veya ENI (Elastic Network Interface) seviyesinde \u00e7al\u0131\u015f\u0131r. G\u00fcvenlik gruplar\u0131, durumu koruyan (stateful) g\u00fcvenlik duvarlar\u0131d\u0131r. Bu, giden bir iste\u011fe izin verildi\u011finde, yan\u0131t trafi\u011finin otomatik olarak geri d\u00f6nmesine izin verildi\u011fi anlam\u0131na gelir. Gelen (inbound) ve giden (outbound) trafik i\u00e7in ayr\u0131 kurallar tan\u0131mlayabilirsiniz. Varsay\u0131lan olarak, bir g\u00fcvenlik grubu t\u00fcm giden trafi\u011fe izin verir. Bu, bir\u00e7ok senaryoda uygun olsa da, s\u0131k\u0131 g\u00fcvenlik gereksinimleri olan ortamlar i\u00e7in bir risk olu\u015fturabilir. Giden trafi\u011fi k\u0131s\u0131tlamak i\u00e7in, sadece belirli hedeflere (IP adresleri, di\u011fer g\u00fcvenlik gruplar\u0131) ve belirli portlara (\u00f6rne\u011fin, 443 HTTPS i\u00e7in) izin veren kurallar tan\u0131mlaman\u0131z gerekir. \u00d6rne\u011fin, bir uygulama sunucusunun sadece bir veritaban\u0131 sunucusuna 3306 portundan veya bir d\u0131\u015f API’ye 443 portundan eri\u015fmesine izin verebilirsiniz. Bu, k\u00f6t\u00fc ama\u00e7l\u0131 yaz\u0131l\u0131mlar\u0131n C2 sunucular\u0131yla ileti\u015fim kurmas\u0131n\u0131 veya hassas verilerin istenmeyen hedeflere s\u0131zmas\u0131n\u0131 engellemek i\u00e7in kritik bir ad\u0131md\u0131r.<\/p>\n
A\u011f ACL’leri (Network Access Control Lists – NACLs), alt a\u011f seviyesinde \u00e7al\u0131\u015fan durumsuz (stateless) g\u00fcvenlik duvarlar\u0131d\u0131r. G\u00fcvenlik gruplar\u0131ndan farkl\u0131 olarak, NACL’ler hem gelen hem de giden trafik i\u00e7in ayr\u0131 kurallar gerektirir ve bir iste\u011fe izin verildi\u011finde, yan\u0131t trafi\u011fi i\u00e7in de a\u00e7\u0131k\u00e7a bir kural tan\u0131mlaman\u0131z gerekir. NACL’ler, belirli IP adreslerinden veya IP adreslerine giden veya gelen trafi\u011fi engellemek veya izin vermek i\u00e7in kullan\u0131l\u0131r. Varsay\u0131lan olarak, yeni bir NACL t\u00fcm trafi\u011fe izin verir, ancak \u00f6zel bir NACL olu\u015fturdu\u011funuzda, t\u00fcm trafi\u011fi reddeder ve yaln\u0131zca a\u00e7\u0131k\u00e7a izin verdi\u011finiz trafi\u011fe izin verir. NACL’ler, g\u00fcvenlik gruplar\u0131na ek bir g\u00fcvenlik katman\u0131 sa\u011flar ve genellikle daha geni\u015f kapsaml\u0131 reddetme (deny) kurallar\u0131 uygulamak i\u00e7in kullan\u0131l\u0131r. \u00d6rne\u011fin, bilinen k\u00f6t\u00fc ama\u00e7l\u0131 IP aral\u0131klar\u0131na giden t\u00fcm trafi\u011fi bir NACL ile engelleyebilirsiniz. G\u00fcvenlik gruplar\u0131 genellikle bireysel \u00f6rnekler i\u00e7in hassas kontrol sa\u011flarken, NACL’ler alt a\u011flar i\u00e7indeki t\u00fcm \u00f6rnekler i\u00e7in daha geni\u015f kapsaml\u0131 ve kaba taneli (coarse-grained) kontrol sa\u011flar.<\/p>\n
\u00d6zel alt a\u011flardaki (private subnets) kaynaklar\u0131n internete eri\u015febilmesi i\u00e7in do\u011frudan bir \u0130nternet A\u011f Ge\u00e7idi’ne (Internet Gateway – IGW) ba\u011flanamazlar. \u0130\u015fte burada NAT Gateway devreye girer. NAT Gateway, \u00f6zel alt a\u011flardaki \u00f6rneklerin internete giden trafi\u011fi ba\u015flatmas\u0131na olanak tan\u0131r, ancak d\u0131\u015far\u0131dan gelen istenmeyen ba\u011flant\u0131lara izin vermez. Bu, \u00f6zel sunucular\u0131n\u0131z\u0131n g\u00fcvenlik g\u00fcncellemelerini indirmesi veya d\u0131\u015f API’lere eri\u015fmesi gerekti\u011finde kritik \u00f6neme sahiptir. NAT Gateway’ler y\u00fcksek oranda eri\u015filebilir (highly available) ve y\u00f6netilen bir hizmettir. \u0130nternet A\u011f Ge\u00e7idi (IGW) ise genel alt a\u011flardaki (public subnets) \u00f6rneklerin do\u011frudan internete eri\u015fimini sa\u011flar. Giden trafik g\u00fcvenli\u011fi ba\u011flam\u0131nda, NAT Gateway’i kullanmak, t\u00fcm giden trafi\u011fi tek bir noktadan y\u00f6nlendirme ve bu noktada g\u00fcvenlik kontrolleri (\u00f6rne\u011fin, bir g\u00fcvenlik duvar\u0131) uygulama yetene\u011fi sunarak \u00f6nemli bir avantaj sa\u011flar. Bu sayede, \u00f6zel alt a\u011flar\u0131n\u0131zdaki kaynaklar\u0131n do\u011frudan internete \u00e7\u0131kmas\u0131n\u0131 engelleyerek sald\u0131r\u0131 y\u00fczeyinizi (attack surface) azaltm\u0131\u015f olursunuz.<\/p>\n
Bu temel AWS bile\u015fenlerini do\u011fru bir \u015fekilde yap\u0131land\u0131rmak, giden trafik g\u00fcvenli\u011finizin temelini olu\u015fturur. Her bir bile\u015fenin kendine \u00f6zg\u00fc rol\u00fcn\u00fc ve g\u00fcvenlik grubu ile NACL aras\u0131ndaki farklar\u0131 anlamak, etkili bir savunma stratejisi olu\u015fturmak i\u00e7in hayati \u00f6neme sahiptir.<\/p>\n
AWS’te giden trafi\u011fi filtrelemenin iki temel ve en s\u0131k kullan\u0131lan yolu, G\u00fcvenlik Gruplar\u0131 (Security Groups) ve A\u011f ACL’leridir (Network Access Control Lists – NACLs). Her ikisi de g\u00fcvenlik duvar\u0131 i\u015flevi g\u00f6rse de, \u00e7al\u0131\u015fma \u015fekilleri ve uyguland\u0131klar\u0131 seviyeler farkl\u0131d\u0131r. Bu farklar\u0131 anlamak ve do\u011fru bir \u015fekilde yap\u0131land\u0131rmak, kapsaml\u0131 bir giden trafik g\u00fcvenli\u011fi stratejisi i\u00e7in elzemdir.<\/p>\n
G\u00fcvenlik Gruplar\u0131, bir EC2 \u00f6rne\u011fi veya ENI seviyesinde \u00e7al\u0131\u015fan durum koruyan (stateful) sanal g\u00fcvenlik duvarlar\u0131d\u0131r. Varsay\u0131lan olarak, yeni olu\u015fturulan bir g\u00fcvenlik grubu t\u00fcm giden trafi\u011fe izin verir ( En iyi uygulama, bu varsay\u0131lan kural\u0131 kald\u0131rmak ve sadece uygulaman\u0131z\u0131n ger\u00e7ekten ihtiya\u00e7 duydu\u011fu giden ba\u011flant\u0131lara izin veren minimum ayr\u0131cal\u0131k (least privilege) prensibini uygulamakt\u0131r. \u00d6rne\u011fin, bir web sunucusunun sadece bir veritaban\u0131 sunucusuyla (belirli bir porttan), bir d\u0131\u015f API ile (HTTPS – port 443) ve belki de bir paket y\u00f6neticisi deposuyla (HTTP – port 80 veya HTTPS – port 443) ileti\u015fim kurmas\u0131 gerekiyorsa, sadece bu ba\u011flant\u0131lara izin veren kurallar tan\u0131mlamal\u0131s\u0131n\u0131z. Di\u011fer t\u00fcm giden trafi\u011fi a\u00e7\u0131k\u00e7a reddetmek, veri s\u0131zmas\u0131 veya C2 ileti\u015fimi gibi tehditleri b\u00fcy\u00fck \u00f6l\u00e7\u00fcde azalt\u0131r.<\/p>\n Bir \u00f6rnek senaryo d\u00fc\u015f\u00fcnelim: Bir uygulama sunucunuz ( Bu kurallar\u0131 AWS CLI ile \u015fu \u015fekilde ekleyebilirsiniz:<\/p>\n <\/code>\n<\/div>\n Bu \u00f6rnekte, NACL'ler, alt a\u011f seviyesinde \u00e7al\u0131\u015fan durumsuz (stateless) g\u00fcvenlik duvarlar\u0131d\u0131r. Bu, hem gelen hem de giden trafik i\u00e7in ayr\u0131 kurallar tan\u0131mlaman\u0131z gerekti\u011fi anlam\u0131na gelir. Bir NACL'de her kurala bir numara atan\u0131r ve kurallar en d\u00fc\u015f\u00fck numaradan en y\u00fckse\u011fe do\u011fru i\u015flenir. Bir kural e\u015fle\u015fti\u011finde, di\u011fer kurallar de\u011ferlendirilmez. Son kural (genellikle NACL'ler, g\u00fcvenlik gruplar\u0131na ek bir g\u00fcvenlik katman\u0131 olarak veya daha geni\u015f kapsaml\u0131 reddetme kurallar\u0131 uygulamak i\u00e7in kullan\u0131labilir. \u00d6rne\u011fin, bilinen k\u00f6t\u00fc ama\u00e7l\u0131 IP adres aral\u0131klar\u0131na giden t\u00fcm trafi\u011fi bir alt a\u011fdan engellemek isteyebilirsiniz. Veya, belirli bir alt a\u011fdaki t\u00fcm \u00f6rneklerin sadece belirli bir port \u00fczerinden d\u0131\u015far\u0131 \u00e7\u0131kmas\u0131na izin verirken, di\u011fer t\u00fcm portlar\u0131 engelleyebilirsiniz.<\/p>\n Bir NACL kural\u0131 \u015fu bile\u015fenlerden olu\u015fur:<\/p>\n \u00d6rnek bir NACL senaryosu: Bir \u00f6zel alt a\u011fdaki t\u00fcm kaynaklar\u0131n sadece 443 (HTTPS) portundan d\u0131\u015far\u0131 \u00e7\u0131kmas\u0131na izin vermek, di\u011fer t\u00fcm portlar\u0131 engellemek istiyorsunuz. Ayr\u0131ca, bilinen bir k\u00f6t\u00fc ama\u00e7l\u0131 IP adresine (\u00f6rne\u011fin, Bu durumda, NACL'nize a\u015fa\u011f\u0131daki giden (egress) kurallar\u0131 ekleyebilirsiniz:<\/p>\n Unutulmamal\u0131d\u0131r ki, NACL'ler durumsuz oldu\u011fu i\u00e7in, e\u011fer giden bir iste\u011fe izin veriyorsan\u0131z, bu iste\u011fin yan\u0131t\u0131n\u0131n geri gelmesi i\u00e7in de ilgili gelen (inbound) kural\u0131 tan\u0131mlaman\u0131z gerekir. \u00d6rne\u011fin, 443 portundan giden trafi\u011fe izin veriyorsan\u0131z, dinamik port aral\u0131\u011f\u0131ndan (1024-65535) gelen yan\u0131t trafi\u011fine de izin vermeniz gerekebilir. Bu, NACL'leri g\u00fcvenlik gruplar\u0131na g\u00f6re daha karma\u015f\u0131k hale getirebilir, ancak alt a\u011f seviyesinde g\u00fc\u00e7l\u00fc ve geni\u015f kapsaml\u0131 kontrol sa\u011flar.<\/p>\n \u00d6zetle, G\u00fcvenlik Gruplar\u0131 bireysel \u00f6rnekler i\u00e7in hassas kontrol sa\u011flarken, NACL'ler alt a\u011flar i\u00e7in daha geni\u015f kapsaml\u0131 bir g\u00fcvenlik katman\u0131 sunar. En iyi g\u00fcvenlik duru\u015fu i\u00e7in her ikisini de birlikte ve tamamlay\u0131c\u0131 bir \u015fekilde kullanmak \u00f6nemlidir. G\u00fcvenlik gruplar\u0131n\u0131 minimum ayr\u0131cal\u0131kla yap\u0131land\u0131r\u0131n ve NACL'leri alt a\u011f seviyesinde ek bir reddetme veya geni\u015f filtreleme katman\u0131 olarak kullan\u0131n.<\/p>\n AWS'te sanal sunucular\u0131m\u0131z\u0131n (EC2 instances) internete eri\u015fimi, genellikle Sanal \u00d6zel Bulut (VPC) i\u00e7inde konumland\u0131r\u0131ld\u0131klar\u0131 alt a\u011f t\u00fcr\u00fcne ba\u011fl\u0131d\u0131r. Genel alt a\u011flar (public subnets) ve \u00f6zel alt a\u011flar (private subnets) aras\u0131ndaki bu ayr\u0131m, giden trafik y\u00f6netiminde \u0130nternet A\u011f Ge\u00e7idi (Internet Gateway - IGW) ve NAT Gateway'in rollerini belirler. Bu iki hizmet, farkl\u0131 g\u00fcvenlik ve eri\u015fim ihtiya\u00e7lar\u0131na y\u00f6nelik \u00e7\u00f6z\u00fcmler sunar.<\/p>\n \u0130nternet A\u011f Ge\u00e7idi (IGW), VPC'niz ile internet aras\u0131nda bir k\u00f6pr\u00fc g\u00f6revi g\u00f6r\u00fcr. Genel alt a\u011flarda (public subnets) bulunan \u00f6rneklerin do\u011frudan internete ba\u011flanmas\u0131n\u0131 sa\u011flar. Bir alt a\u011f\u0131 \"genel\" yapmak i\u00e7in, o alt a\u011f\u0131n y\u00f6nlendirme tablosunda (route table) internete ( IGW'nin giden trafik g\u00fcvenli\u011fi ba\u011flam\u0131ndaki rol\u00fc, genellikle genel alt a\u011flardaki web sunucular\u0131, y\u00fck dengeleyiciler (load balancers) veya di\u011fer internete a\u00e7\u0131k hizmetler i\u00e7in do\u011frudan internet eri\u015fimi sa\u011flamakt\u0131r. Bu t\u00fcr \u00f6rneklerin, g\u00fcvenlik g\u00fcncellemelerini indirmesi, d\u0131\u015f API'lere eri\u015fmesi veya kullan\u0131c\u0131 isteklerine yan\u0131t vermesi gerekebilir. Ancak, IGW \u00fczerinden do\u011frudan internete eri\u015fen her \u00f6rne\u011fin, kendi G\u00fcvenlik Grubu (Security Group) ve alt a\u011f\u0131na ba\u011fl\u0131 A\u011f ACL (NACL) kurallar\u0131yla s\u0131k\u0131 bir \u015fekilde korunmas\u0131 esast\u0131r. Do\u011frudan internet eri\u015fimi, potansiyel sald\u0131r\u0131 y\u00fczeyini art\u0131rd\u0131\u011f\u0131 i\u00e7in, bu t\u00fcr \u00f6rneklerde en az ayr\u0131cal\u0131k (least privilege) prensibiyle giden trafik kurallar\u0131n\u0131 uygulamak kritik \u00f6neme sahiptir.<\/p>\n \u00d6zel alt a\u011flarda (private subnets) yer alan kaynaklar, varsay\u0131lan olarak internete do\u011frudan eri\u015femezler. Ancak, bu kaynaklar\u0131n (\u00f6rne\u011fin, veritaban\u0131 sunucular\u0131, uygulama sunucular\u0131, arka u\u00e7 hizmetleri) i\u015fletim sistemi g\u00fcncellemelerini indirmesi, yaz\u0131l\u0131m paketlerini kurmas\u0131 veya d\u0131\u015f API'lere g\u00fcvenli bir \u015fekilde eri\u015fmesi gerekebilir. \u0130\u015fte bu noktada NAT Gateway devreye girer. NAT Gateway, \u00f6zel alt a\u011flardaki \u00f6rneklerin internete giden ba\u011flant\u0131lar ba\u015flatmas\u0131na olanak tan\u0131r, ancak d\u0131\u015far\u0131dan gelen istenmeyen ba\u011flant\u0131lar\u0131 engeller. Bu, \u00f6zel kaynaklar\u0131n\u0131z\u0131n internete \u00e7\u0131karken g\u00fcvenli\u011fini sa\u011flamak i\u00e7in hayati bir hizmettir.<\/p>\n Bir NAT Gateway genellikle bir genel alt a\u011fa (public subnet) yerle\u015ftirilir ve bir Elastic IP adresi ile ili\u015fkilendirilir. \u00d6zel alt a\u011flar\u0131n y\u00f6nlendirme tablolar\u0131, internete ( NAT Gateway kullanman\u0131n giden trafik g\u00fcvenli\u011fi a\u00e7\u0131s\u0131ndan \u00f6nemli avantajlar\u0131 vard\u0131r:<\/p>\n IGW ve NAT Gateway aras\u0131ndaki temel fark, IGW'nin hem gelen hem de giden trafi\u011fe izin vermesi (genel IP'si olan \u00f6rnekler i\u00e7in) ve do\u011frudan internet eri\u015fimi sa\u011flamas\u0131yken, NAT Gateway'in sadece \u00f6zel alt a\u011flardan giden trafi\u011fe izin vermesidir (internete gelen ba\u011flant\u0131lar\u0131 engeller). Bu fark, onlar\u0131 farkl\u0131 kullan\u0131m senaryolar\u0131 i\u00e7in uygun hale getirir:<\/p>\n0.0.0.0\/0<\/code> IP adresine t\u00fcm protokollere ve t\u00fcm portlara izin veren bir kural). Bu varsay\u0131lan kural, \u00e7o\u011fu zaman g\u00fcvenlik a\u00e7\u0131s\u0131ndan bir zafiyet olu\u015fturur \u00e7\u00fcnk\u00fc bir \u00f6rnek (instance) ele ge\u00e7irildi\u011finde, d\u0131\u015far\u0131daki herhangi bir hedefe serbest\u00e7e ileti\u015fim kurabilir.<\/p>\napp-server-sg<\/code> g\u00fcvenlik grubu) var ve bu sunucunun sadece \u015firket i\u00e7i bir veritaban\u0131 sunucusuna (db-server-sg<\/code> g\u00fcvenlik grubu) MySQL (port 3306) \u00fczerinden ve bir d\u0131\u015f analiz hizmetine (api.example.com<\/code> IP adresi 203.0.113.10<\/code>) HTTPS (port 443) \u00fczerinden eri\u015fmesi gerekiyor. Bu durumda, app-server-sg<\/code> g\u00fcvenlik grubuna a\u015fa\u011f\u0131daki giden kurallar\u0131 eklersiniz:<\/p>\n\n
db-server-sg<\/code>, Protokol: TCP, Port Aral\u0131\u011f\u0131: 3306<\/li>\n203.0.113.10\/32<\/code>, Protokol: TCP, Port Aral\u0131\u011f\u0131: 443<\/li>\n<\/ul>\n\naws ec2 authorize-security-group-egress \\\n --group-id sg-0abcdef1234567890 \\\n --protocol tcp \\\n --port 3306 \\\n --destination-security-group-id sg-0fedcba9876543210 \\\n --description \"Uygulama sunucusundan DB sunucusuna MySQL eri\u015fimi\"\n\naws ec2 authorize-security-group-egress \\\n --group-id sg-0abcdef1234567890 \\\n --protocol tcp \\\n --port 443 \\\n --cidr 203.0.113.10\/32 \\\n --description \"Uygulama sunucusundan d\u0131\u015f API'ye HTTPS eri\u015fimi\"\n<\/pre>\nsg-0abcdef1234567890<\/code> uygulama sunucusunun g\u00fcvenlik grubu kimli\u011fi, sg-0fedcba9876543210<\/code> ise veritaban\u0131 sunucusunun g\u00fcvenlik grubu kimli\u011fidir. Bu yakla\u015f\u0131m, uygulama sunucunuzun sadece izin verilen hedeflerle ileti\u015fim kurmas\u0131n\u0131 sa\u011flayarak g\u00fcvenlik duru\u015funuzu \u00f6nemli \u00f6l\u00e7\u00fcde g\u00fc\u00e7lendirir.<\/p>\nA\u011f ACL'leri (NACL'ler) ile Giden Trafik K\u0131s\u0131tlamalar\u0131<\/h4>\n
*<\/code> veya 100<\/code> gibi y\u00fcksek bir numara), a\u00e7\u0131k\u00e7a e\u015fle\u015fmeyen t\u00fcm trafi\u011fi reddeden varsay\u0131lan bir reddetme (deny) kural\u0131d\u0131r.<\/p>\n\n
192.168.1.0\/24<\/code> veya 0.0.0.0\/0<\/code>).<\/li>\n198.51.100.0\/24<\/code>) giden trafi\u011fi tamamen engellemek istiyorsunuz.<\/p>\n\n
198.51.100.0\/24<\/code>, Eylem: Reddet (Deny)<\/li>\n0.0.0.0\/0<\/code>, Eylem: \u0130zin Ver (Allow)<\/li>\n0.0.0.0\/0<\/code>, Eylem: \u0130zin Ver (Allow) (paket y\u00f6neticileri i\u00e7in gerekli olabilir)<\/li>\n0.0.0.0\/0<\/code>, Eylem: Reddet (Deny) (Varsay\u0131lan reddetme kural\u0131)<\/li>\n<\/ul>\nNAT Gateway ve \u0130nternet A\u011f Ge\u00e7idi ile Giden Trafik Y\u00f6netimi Nas\u0131l Yap\u0131l\u0131r?<\/h3>\n
\u0130nternet A\u011f Ge\u00e7idi (Internet Gateway - IGW)<\/h4>\n
0.0.0.0\/0<\/code>) giden trafi\u011fin IGW'ye y\u00f6nlendirilmesi gerekir. Bir EC2 \u00f6rne\u011finin genel bir IP adresi veya bir Elastic IP adresi varsa ve genel bir alt a\u011fda bulunuyorsa, IGW \u00fczerinden internete do\u011frudan eri\u015febilir.<\/p>\nNAT Gateway<\/h4>\n
0.0.0.0\/0<\/code>) giden t\u00fcm trafi\u011fi bu NAT Gateway'e y\u00f6nlendirecek \u015fekilde yap\u0131land\u0131r\u0131l\u0131r. NAT Gateway, \u00f6zel alt a\u011flardaki \u00f6rneklerden gelen giden trafi\u011fi al\u0131r, kaynak IP adresini kendi Elastic IP adresiyle de\u011fi\u015ftirir (A\u011f Adresi \u00c7evirisi - Network Address Translation yapar) ve ard\u0131ndan trafi\u011fi \u0130nternet A\u011f Ge\u00e7idi \u00fczerinden internete g\u00f6nderir. Yan\u0131t trafi\u011fi NAT Gateway'e geri d\u00f6nd\u00fc\u011f\u00fcnde, NAT Gateway bunu orijinal \u00f6zel \u00f6rne\u011fe geri y\u00f6nlendirir.<\/p>\n\n
Farklar ve Kullan\u0131m Senaryolar\u0131<\/h4>\n
\n
\n","protected":false},"excerpt":{"rendered":"Bulut ortamlar\u0131nda g\u00fcvenlik denildi\u011finde akla ilk gelen genellikle gelen (inbound) trafi\u011fi korumak olur.","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1406],"tags":[],"class_list":{"0":"post-41570","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-aws","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\n