AWS konsolu internetsiz çalışıyor: Yanlış politika erişimi tamamen kesebilir

İnternete çıkışı olmayan bir VPC’den AWS konsoluna erişmek için console, signin ve console-static interface endpoint’lerini oluşturun, Private DNS’i etkinleştirin ve kullanacağınız servislerin VPC endpoint’lerini ekleyin. AWS’nin zorunlu endpoint tanımı, bu üç temel bileşenin yanı sıra konsolda kullanılacak servisler için de özel erişim yolu gerektiğini belirtiyor.

AWS Management Console Private Access, desteklenen servis konsollarının kimlik doğrulama, statik içerik ve servis çağrılarını internet geçidi ya da NAT olmadan PrivateLink üzerinden taşıyabiliyor. AWS’nin hizmet duyurusu, özelliğin tüm ticari AWS bölgelerinde kullanılabildiğini ve ücretin PrivateLink endpoint kullanımı ile işlenen veriye bağlı olduğunu doğruluyor. Ancak bağlantı kanıtlanmadan uygulanan yanlış bir endpoint veya Sign-In politikası, geçerli kimlik bilgilerine rağmen konsol oturumunu tamamen engelleyebilir.

1. Pilotun sınırını konsol adıyla değil iş akışıyla çizin

Private Access, bütün AWS web yüzeyini otomatik olarak özel ağa taşımaz. Pilot kapsamına bölgeyi, giriş yöntemini, kullanılacak servis konsollarını, kaynak hesapları ve erişimin başlayacağı ağı birlikte yazın. Böylece konsol kabuğunun açılmasıyla gerçek iş akışının tamamlanmasını birbirinden ayırabilirsiniz.

Tarayıcı önce bölgesel konsol adresine ulaşır, AWS Sign-In üzerinden oturum kurar ve arayüz dosyalarını console-static endpoint’inden alır. Bir servis ekranı açıldığında ise bazı çağrılar konsol arka ucu tarafından, bazıları doğrudan tarayıcıdan ilgili servis API’sine gönderilebilir. Bu nedenle yalnızca ana sayfanın yüklenmesi, örneğin KMS anahtarlarının veya EC2 kaynaklarının listelenebildiğini kanıtlamaz.

Tam izolasyonun sınırlarını da baştan kabul edin. Desteklenmeyen servis konsolları ve status.aws.amazon.com, health.aws.amazon.com veya docs.aws.amazon.com gibi Private Access kapsamı dışındaki adresler internet bağlantısı olmadan kullanılamaz. İlk pilot matrisi yalnızca gerçekten desteklenen ve ilk gün gerekli olan ekranları içermelidir.

2. Üç temel endpoint’i servis endpoint’leriyle tamamlayın

Tek bölgeli, internetsiz bir pilotun tabanı üç interface endpoint’tir: com.amazonaws.<region>.console, com.amazonaws.<region>.signin ve com.amazonaws.<region>.console-static. Sonuncusu statik içerik ile konsola özgü API’leri taşır ve internet yolu bulunmayan ağlarda zorunludur.

1. Üretim veya ortak yönetim hesabı yerine ayrılmış bir pilot hesap ve VPC seçin.
2. Üç temel endpoint’i, yönetim istemcisinden erişilebilen alt ağlarda oluşturun.
3. Endpoint güvenlik gruplarında yönetim alt ağlarından gelen TCP 443 trafiğine izin verin.
4. Pilotta açılacak her servis için gereken PrivateLink endpoint’lerini ekleyin.
5. Servis ekranlarında listeleme, arama ve değişiklik işlevlerini ayrı ayrı doğrulayın.

Birden fazla bölgede özel konsol erişimi gerekiyorsa console ve signin endpoint’lerini ilgili her bölgede oluşturun. Bölgeden bağımsız statik içeriği taşıyan console-static endpoint’i tek bölgede bulunabilir; servis endpoint’leri ise kaynakların ve servis çağrılarının gerçekleştiği bölgelere göre kurulmalıdır.

Sayfa açıldığı hâlde kaynak listesi boşsa veya bazı bileşenler hata veriyorsa eksik bir servis endpoint’ini araştırın. Tek bir konsol ekranı birden fazla AWS servis API’sine bağlı olabilir; dolayısıyla yalnızca ekranın adını taşıyan servisin endpoint’i her zaman yeterli değildir.

3. DNS ve trafik kanıtını politikadan önce alın

VPC içindeki istemci Amazon tarafından sağlanan Route 53 Resolver’ı kullanıyorsa interface endpoint’lerinde PrivateDnsEnabled değerini etkinleştirmek normalde konsol alan adlarını endpoint ENI’lerinin özel adreslerine yönlendirir. Özel DNS sunucusu veya şirket içi resolver kullanılıyorsa konsol, Sign-In, statik içerik ve servis API’si alan adları için yönlendirme kuralları ayrıca tanımlanmalıdır.

Tarayıcıyı açmadan önce VPC içindeki istemciden console.aws.amazon.com ve signin.aws.amazon.com çözümlemesini kontrol edin. Sonuçlar VPC endpoint’lerinin özel IP adreslerini göstermelidir. Şirket içinden Direct Connect veya Site-to-Site VPN üzerinden erişiliyorsa aynı sorguyu kurumsal DNS üzerinden tekrarlayın ve endpoint alt ağlarından kurumsal ağa dönüş rotasını doğrulayın.

Ardından izin verici politikayla oturum açın. CloudTrail’deki başarılı ConsoleLogin olayında vpcEndpointId alanının ilgili endpoint kimliğini taşıması, oturumun amaçlanan özel yoldan geçtiğini gösterir. İnternet çıkışı geçici olarak açıksa yalnızca sayfanın yüklenmesine güvenmek, yanlış DNS nedeniyle genel endpoint’e giden trafiği gözden kaçırabilir.

4. Endpoint policy, RCP ve SCP aynı işi yapmaz

Console VPC endpoint policy, oturum açmış kimlikleri aws:PrincipalOrgID veya aws:PrincipalAccount ile; erişilecek kaynakları ise aws:ResourceOrgID veya aws:ResourceAccount ile sınırlayabilir. Sign-In endpoint policy’de kimliğin henüz bilinmediği ön aşama ile kimlik doğrulama sonrası aşama ayrı değerlendirilir.

AWS’nin güvenilir kimlik kuralları, ön aşamada signin:Authenticate, sonraki aşamada ise signin:AuthorizeOAuth2Access ve signin:CreateOAuth2Token eylemlerinin kullanılmasını öngörüyor. Console ve Sign-In endpoint’lerine eşdeğer hesap veya organizasyon sınırları uygulanmalı; izin listesi biçimindeki SCP’lerde signin:* açıkça izin verilen eylemlere eklenmelidir.

Sign-In RCP, AWS Organizations üzerinden organizasyon kapsamındaki girişleri; RBP ise tek bir hesap düzeyindeki girişleri sınırlar. SCP, kimliğin yapabileceği servis çağrılarına üst sınır koyar. Herhangi bir katmandaki açık deny başka bir politikadaki allow ile geçersiz kılınamayacağı için bu kontrolleri aynı anda devreye almak, hatanın hangi katmandan kaynaklandığını ayırmayı güçleştirir.

5. Kısıtları sırayla açın, geri dönüşü konsola bağlamayın

Güvenli pilot sırası bağlantı, gözlem, endpoint kısıtı, Sign-In kısıtı ve kapsam genişletmedir. Önce izin verici endpoint politikalarıyla özel DNS’i, TCP 443 erişimini, servis ekranlarını ve CloudTrail kaydını doğrulayın. Ardından console ve signin endpoint politikalarını daraltın; RCP veya RBP uygulamasını en sona bırakın.

AWS’nin pilot dağıtım modeli, hatalı Sign-In politikasının kullanıcıları konsol dışında bırakabileceğini; uygulama öncesinde politikadan hariç tutulan özel bir acil durum IAM rolü hazırlanmasını ve kısıtların ayrılmış test ortamında denenmesini öneriyor. Politika hem beklenen ağdan başarılı girişi hem de beklenmeyen ağdan reddi üretmeden daha geniş bir organizasyon birimine taşınmamalıdır.

• Kurumsal ağ içindeki oturumun başarılı olduğunu doğrulayın.
• Beklenmeyen ağdaki oturumun Sign-In aşamasında reddedildiğini kontrol edin.
• Başarılı ConsoleLogin olaylarında vpcEndpointId alanını inceleyin.
• Beklenmeyen retlerde CloudTrail’de RBP veya RCP hata mesajını belirleyin.
• Pilot servislerin yalnızca görüntüleme değil, gerekli yönetim işlemlerini de tamamladığını doğrulayın.

Kurtarma yolu konsol oturumuna bağımlı olmamalıdır. Sign-In RCP ve RBP’ler etkileşimli girişi denetlerken SigV4 ile imzalanmış AWS CLI ve SDK çağrıları bu denetimden etkilenmez. Acil durum rolüne signin:DeleteConsoleAuthorizationConfiguration izni vererek hatalı console authorization enforcement yapılandırmasını programatik olarak kaldırabilecek prosedürü dağıtımdan önce sınayın.

Pilotu ancak üç temel endpoint, gerekli servis endpoint’leri, özel DNS, CloudTrail kanıtı ve programatik geri dönüş yolu birlikte çalıştığında genişletin. Hesapları, organizasyon birimlerini ve bölgeleri küçük gruplar hâlinde eklemek, erişimi bozan endpoint veya politika değişikliğini ayırmayı kolaylaştırır.

Ayrıca okuyun:

• Hugging Face’e ilk adım: Yanlış modeli çalıştırmadan önce üç kontrol
• Claude 10 bin bilim insanına açıldı, kritik biyoloji erişimi sınırlı
• SAFE mi convertible note mu? Yanlış madde kurucu payını sessizce eritir