AWS güvenlik duruşunuzu iyileştirin, 2. Adım: AWS kaynaklarına doğrudan internet erişiminden kaçının

[ This article was originally published here ]

Bu dizide, IAM’yi doğru şekilde kurmayı tartıştık. Şimdi AWS kaynaklarına doğrudan internet erişiminden kaçınarak ikinci adıma geçiyoruz.

EC2 bulut sunucuları veya S3 klasörleri gibi AWS kaynaklarına İnternet üzerinden doğrudan erişildiğinde, saldırılara karşı savunmasızdır. Örneğin, SSH girişine yapılan kaba kuvvet saldırıları, Katman 3, 4 veya 7 taşması yoluyla sunucu kaynaklarına yönelik hizmet reddi (DOS) saldırıları veya bir S3 klasöründeki verilerin yanlışlıkla ifşası. Neyse ki AWS, bu tehditlerin her birini sanal olarak ortadan kaldırabilen araçlar sunar. Geleneksel olarak bir genel alt ağın askerden arındırılmış bölgesine (DMZ) yerleştirilmiş olan kaynakların nasıl korunacağını tartışalım.

Tüm EC2 bulut sunucularını özel alt ağlara yerleştirin

Ağ adresi çevirisinin (NAT) (yani, genel bir IP adresinin özel bir IP adresine eşlenmesi) ortaya çıkmasına rağmen, birçok işletme DMZ’de herkesin erişebileceği kaynaklar koyar. Bu, kaynaklara genel IP adresleri atayarak kaynaklara doğrudan bağlantı sağlar. Buna karşılık, alan adı sistemi (DNS) çözümü aracılığıyla, web sitesi adları, bağlantı sağlayan bu IP adreslerine çevrilir. Normalde, bir DMZ’ye yerleştirilen kaynaklar web sunucularıdır. Her ne kadar bazı şirketler rahatlık veya güvenlik bilinci eksikliği olsa da, DMZ’ye veritabanı, uygulama ve dosya sunucuları da yerleştirecektir. Erişimi IP kaynağına, IP hedefine, protokole ve bağlantı noktası numarasına göre kısıtlamak için yeterli erişim kontrol listeleri (ACL’ler) ve güvenlik grupları mevcut değilse, bu kaynaklar saldırılara açıktır.

Neyse ki artık EC2 bulut sunucularını genel bir alt ağa yerleştirmeye gerek yok. Buna, özel alt ağlardaki EC2 bulut sunucularına erişmek için kullanılan savunma ana bilgisayarları dahildir. Genel bir IP adresini EC2 bulut sunucularıyla ilişkilendirmek yerine, bunun yerine bir elastik yük dengeleyici (ELB) kullanılabilir.

ELB, genel bir IP adresi aracılığıyla web sunucusuna bağlı trafiği sonlandıran ve bu trafiği, varsa, genel bir alt ağda bulunan EC2 bulut sunucularına veya karşılık gelen kapsayıcılara aktaran sanal bir cihazdır. Ne yük dengeleyiciyi kullanan AWS müşterisi ne de herhangi bir harici taraf yük dengeleyiciye doğrudan erişemez, bu nedenle saldırılara karşı savunmasız değildir. Ayrıca, ELB’de sonlandırılan trafiğin Katman 4 (OSI’nin Aktarım katmanı) veya HTTP (Katman 7) olmasına bağlı olarak AWS, geçerli trafiği barındırmak için iki ayrı ELB sunar. Bu ELB seçenekleri, Ağ Yük Dengeleyici (Katman 4) ve Uygulama Yük Dengeleyicidir (Katman 7). Aşağıdaki AWS diyagramı ve adım adım açıklamasının ortaya koyduğu gibi, özel alt ağlarda bulunan sanallaştırılmış sunucu kaynaklarına dış dünya tarafından doğrudan erişilemez.

Eksiksiz trafik akış şeması

Aşağıdaki diyagram, yük dengeleyici yönlendirmesinin eksiksiz bir örneğini sağlamak için gelen ve dönen trafik akışlarını birleştirir.

1. İnternetten gelen trafik, internete dönük bir Uygulama Yük Dengeleyici dağıttığınızda dinamik olarak oluşturulan Elastik IP adresine akar.
2. Uygulama Yük Dengeleyici, gösterilen senaryoda iki genel alt ağ ile ilişkilidir. Application Load Balancer, trafiğin hangi hedef grup ve örneğe yönlendirileceğini belirlemek için kendi iç mantığını kullanır.
3. Application Load Balancer, isteği aynı Erişilebilirlik Alanındaki genel alt ağ ile ilişkilendirilmiş bir düğüm aracılığıyla EC2 bulut sunucusuna yönlendirir.
4. Yönlendirme tablosu, trafiği yerel olarak VPC içinde, genel alt ağ ile özel alt ağ arasında ve EC2 bulut sunucusuna yönlendirir.
5. Özel alt ağdaki EC2 bulut sunucusu, giden trafiği yol tablosu aracılığıyla yönlendirir.
6. Yol tablosunun genel alt ağa yerel bir yolu vardır. Trafiğin girdiği yoldan geri giden yolu izleyerek ilgili genel alt ağdaki düğümdeki Uygulama Yük Dengeleyicisine ulaşır.
7. Uygulama Yük Dengeleyici, trafiği genel Esnek IP adresi üzerinden yönlendirir.
8. Genel alt ağın yönlendirme tablosu, trafiği yeniden internete yönlendiren bir internet ağ geçidine işaret eden varsayılan bir yola sahiptir.

Daha da önemlisi, yerinde bir ELB olsa bile, uygun ACL’lerin ve güvenlik gruplarının yapılandırılması zorunludur. Sanal özel bulutun (VPC) içine ve dışına yalnızca yasal trafiğe izin verilmelidir. Yük dengeleyici, EC2 bulut sunucularının bulunduğu özel alt ağa giren ve çıkan tüm trafiğe uygunsuz bir şekilde izin verirse, bunlara doğrudan İnternet erişimini kısıtlamanın sağladığı yararların çoğu kaybolabilir.

Ayrıca, bir ELB’nin arkasındaki EC2 bulut sunucuları yine de Katman 3, Katman 4 veya Katman 7 DoS saldırılarına karşı savunmasız olabilir. Bir ELB, yalnızca İnternet’teki kişilerin bulut sunucularınıza doğrudan erişme yeteneğini ortadan kaldırır. Katman 3 ve Katman 4 Dağıtılmış Hizmet Reddi (DDoS) saldırılarını durdurmak için AWS, AWS Kalkanı sunar. Bu hizmet, temel ve ileri düzey olmak üzere iki düzeyde sunulur. Temel hizmet ücretsizdir ve Katman 3 ve Katman 4 trafiğini izler ve kısıtlar. Bu nedenle, trafik ELB’nize ulaşmadan önce, AWS’nin DDoS azaltma teknolojisi ile izlenir ve filtrelenir. AWS, gelişmiş kapsam ve özellikler için ek bir ücret karşılığında AWS Shield Advanced’i sunar. Shield Advanced ile, bir saldırı sırasında kullanılan AWS kaynaklarının artmasıyla ilişkili olarak 7/24 AWS Shield Response Team’e, gelişmiş raporlamaya ve maliyet korumasına erişebilirsiniz. AWS Shield hakkında daha fazla bilgiyi buradan edinebilirsiniz: .

AWS, Katman 7 DoS azaltması için bir Web Uygulaması Güvenlik Duvarı (WAF) sunar. AWS’ye göre bu hizmet, “IP adreslerini, HTTP üstbilgilerini ve gövdesini veya özel URI’leri içeren koşullara göre web trafiğini filtrelemek için kurallar oluşturmanıza olanak tanır… Ayrıca AWS WAF, SQL enjeksiyonu gibi yaygın web açıklarından yararlanmaları engelleyen kurallar oluşturmayı kolaylaştırır. ve siteler arası betik oluşturma. İşletmeniz AWS Shield Advanced kullanıyorsa, AWS WAF aylık maliyete dahildir. AWS WAF hakkında daha fazla bilgiyi buradan edinebilirsiniz: .

Özellikle, bazı DoS olayları kötü amaçlı değildir, bunun yerine bir şirketin web hizmetlerinin viral hale gelmesinin sonucudur. Aynı anda çok fazla trafik gelirse içeriğe erişilemez. AWS, hem statik hem de dinamik içerik için CloudFront adlı bir içerik teslim ağı (CDN) sunar. Böylece, artan talep için EC2 bulut sunucularınızı bir ELB’nin arkasında dikey veya yatay olarak ölçeklendirmek yerine içerik, önbelleğe alındığı ve gerekirse küresel olarak kullanıma sunulduğu CloudFront’a yüklenebilir. Bu, sanallaştırılmış sunucu kaynaklarınızı ve cüzdanınızı da korur. AWS CloudFront hakkında daha fazla bilgiyi buradan edinebilirsiniz: .

Özel alt ağlardaki EC2 bulut sunucularına nasıl güvenli bir şekilde erişilir?

Bu noktaya kadar, EC2 bulut sunucularınızı dış dünyadan erişime karşı nasıl koruyabileceğinizi tartıştık. Haklı olarak, SSH veya RDP bağlantısı için genel bir IP adresi yoksa, sistem yöneticilerinin bunları yönetmek için bulut sunucularına nasıl erişebileceğini merak ediyor olabilirsiniz. Normalde, özel bir alt ağdaki kaynaklara erişim için bir genel alt ağda bir savunma ana bilgisayarı sağlanır. Ancak, genel bir alt ağda bir savunma ana bilgisayarı olarak bir EC2 bulut sunucusu sağlayarak, bulut sunucusu ne kadar sağlam olursa olsun, gereksiz bir güvenlik açığı yaratıyor.

Özel alt ağlardaki EC2 bulut sunucularına erişim elde etmenin basit çözümü AWS Systems Manager’dır. Özel alt ağda da SSH veya RDP bağlantı noktalarını açmaya gerek yoktur. AWS konsolu aracılığıyla AWS, EC2 bulut sunucularına programlı olarak SSH veya RDP erişimi sağlayabilir. SSH veya RDP bağlantı noktaları açık olmadan, dahili bir EC2 bulut sunucusunun güvenliği ihlal edilmiş olsa bile, kötü niyetli bir aktörün bir bulut sunucusuna erişmek için çalınan anahtar çiftlerinden yararlanması veya kök hesaba kaba kuvvet saldırısı gerçekleştirmesi mümkün olmayacaktır. Buna göre, EC2 bulut sunucusuna erişmesine izin verilen tek kullanıcılar, uygun IAM kullanıcı, grup veya rol izinlerine sahip kullanıcılar olacaktır. AWS Systems Manager hakkında daha fazla bilgi edinmek için burayı tıklayın: .

Son olarak, özel bir alt ağdaki EC2 bulut sunucularının genel bir IP adresleri yoksa yazılım indirmeleri, yamalar ve bakım için İnternet’e nasıl erişebileceğini de merak ediyor olabilirsiniz. Önceden, özel alt ağlardaki bulut sunucularının İnternet’e erişmesi için, genel bir alt ağdaki bir EC2 NAT bulut sunucusunun sağlanması gerekirdi. Özel alt ağdaki örneklerden gelen internete bağlı trafik, NAT örneği aracılığıyla yönlendirilir.

Ancak savunma ana bilgisayarları gibi EC2 NAT bulut sunucuları da gereksiz güvenlik riski oluşturur. Özel alt ağlardaki bulut sunucularına ve bulut sunucularından İnternet tabanlı trafiği yönlendirmenin çözümü, AWS NAT Ağ Geçitlerini kullanmaktır. ELB’ler gibi NAT Ağ Geçitleri de AWS müşterilerinin veya harici tarafların erişemeyeceği sanallaştırılmış cihazlardır. NAT örneklerinden farklı olarak, bunlar da önceden tanımlanmış CPU, RAM ve aktarım hızıyla donatılmaz. Bunun yerine, üzerlerine yüklenen iş yükünün üstesinden gelmek için dinamik olarak ölçeklenirler. Sonuç olarak, özel alt ağlardaki EC2 bulut sunucuları, genel bir alt ağdaki bir NAT bulut sunucusuyla ilişkili tehdit olmadan İnternet’e güvenli bir şekilde erişebilir. AWS NAT Ağ Geçitleri hakkında daha fazla bilgi edinmek için burayı tıklayın: .

Artık EC2 bulut sunucularını ve dolaylı olarak bunları kullanan konteynerler, uygulamalar ve veritabanları gibi hizmetleri nasıl koruyacağımızı öğrendiğimize göre, S3 Kovalarının güvenliğini nasıl sağlayacağımızı tartışalım.

CloudFront’u kullanarak S3 gruplarını gizli tutun veya genel erişimi kısıtlayın.

Yıllar içinde birçok haber, müşterilerinin verilerini halka açık S3 klasörlerinde yayınlayarak kamuya ifşa eden şirketlerin hatalarını ortaya çıkardı. Yakın zamanda bir S3 klasörü tedarik eden herkesin bileceği gibi, AWS bu hatayı tekrarlamayı son derece zorlaştırdı. Uyarı istemleri ve göze çarpan kırmızı, “Tehlike, Will Robinson!” simgeler, AWS, bir S3 Kovasının ne zaman herkese açık olduğunu bilmenizi sağlar.

Açık nedenlerden ötürü, şirketlerin tüm dünyanın bilmesini istemediği veriler asla halka açık bir S3 kovasına yerleştirilmemelidir. Bu, kişisel olarak tanımlanabilir bilgileri (PII), sağlık bilgilerini, kredi kartı hesap ayrıntılarını, ticari sırları ve diğer tüm özel verileri içerir. Adım 3’te tartışacağımız şifreleme yerinde olsa bile, bu tür verileri halka açık hale getirmek için hiçbir neden yoktur.

Herkese açık olan S3 verileri için nesnelere doğrudan erişim kısıtlanmalıdır. Bunun birkaç nedeni var. Öncelikle varlıklar, müşterilerinin AWS S3 URL’si ile nesnelere erişmesini istemeyebilir. Bunun yerine, müşterilerinin kendi özel etki alanlarını kullanarak nesnelere erişmesini isteyebilirler. İkincisi, kuruluşlar müşterilerinin S3 nesnelerine sınırsız erişime sahip olmasını istemeyebilir. Bunun yerine, son kullanıcıların nesnelere ne kadar süreyle erişebileceğini sınırlamak için önceden imzalanmış URL’leri kullanmayı tercih edebilirler. Son olarak, kuruluşlar, S3 nesnelerini doğrudan bir klasörden okuyan veya indiren son kullanıcılar için gereksiz maliyetler ödemek istemeyebilir. Bu sorunların çözümü, herkese açık S3 klasörlerini yalnızca CloudFront aracılığıyla erişilebilir kılmaktır.

Bu, S3’ü yalnızca CloudFront’tan gelen GET veya POST isteklerini kabul edecek şekilde yapılandırarak elde edilir. Bu nedenle, genel bir S3 kovasındaki nesnelere dış dünya erişemez. AWS CloudFront ve S3 Bucket entegrasyonu hakkında daha fazla bilgi edinmek için burayı tıklayın: .

Artık İnternet üzerinden doğrudan erişimi kısıtlayarak EC2 bulut sunucularını ve S3 gruplarını nasıl düzgün bir şekilde güvenli hale getireceğimizi öğrendiğimize göre, bu dizideki bir sonraki ve son blogda son adımımız olan şifrelemeyi ele alacağız.

reklam