AWS'te geçen 20 yıl: Bir kez bile "bu benim işim değil" demedim
(daemonology.net)- FreeBSD güvenlik sorumlusu ve Tarsnap'in kurucusu Colin Percival'ın, 2006'da ilk AWS hesabını oluşturmasından bugüne kadar 20 yıl boyunca, resmî çalışan olmayan bir dış katkı sunucu olarak FreeBSD için EC2 desteği kurmaktan güvenlik açıklarını proaktif biçimde bulup bildirmeye, hizmet tasarımına geri bildirim vermeye kadar AWS'nin gelişiminde geniş çapta nasıl yer aldığını kronolojik olarak anlattığı bir yazı
- AWS'nin ilk dönemlerinde her hizmetin hesaba ayrı ayrı etkinleştirilmesi gerekiyordu; başlangıçta varsayılan olarak etkin olan ilk hizmetler Amazon SQS ve çoğu kişinin bilmediği Amazon E-Commerce Service idi
- FreeBSD'yi EC2 üzerinde çalıştırmak için Xen sürüm uyumluluğu, PAE desteği ve HVM'e geçiş gibi yıllara yayılan teknik engellerin aşılması gerekti; ilk başarılı çalıştırma 2010'da t1.micro üzerinde gerçekleşti
- AWS istek imza sistemindeki normalizasyon çakışması açığı, IMDS üzerinden kimlik bilgilerinin açığa çıkma riski (2019'daki Capital One ihlalinde gerçeğe dönüştü) ve Seekable OCI güvenlik sorunu gibi çok sayıda güvenlik meselesi önceden tespit edilip bildirildi
- 2024'ten beri Amazon'un GitHub Sponsors desteğiyle FreeBSD/EC2 bakımı sürdürülüyor; iç sistem erişimi olmadan da Amazon mühendislerinin iş birliğiyle sonuç alınabildiğini gösteren bir dış katkı örneği
AWS hesabı oluşturma ve ilk hizmetler
- 10 Nisan 2006'da Amazon S3 duyurusunu görüp ilk AWS hesabını oluşturdu; çevrimiçi depolama hizmetlerine ilgisi buna vesile oldu ve daha önce 1998'den beri HTTP tabanlı web hizmetleri geliştiriyordu
- AWS'nin ilk dönemlerinde her hizmet için hesapta ayrı etkinleştirme talep etmek gerekiyordu; varsayılan olarak sunulan hizmetler yalnızca Amazon SQS ve Amazon E-Commerce Service idi (Amazon iş ortaklarına yönelik ürün kataloğu API'si)
- Amazon E-Commerce Service fiilen ilk AWS hizmetiydi, ancak pek bilinmiyordu ve AWS tarihçesinden de sessizce çıkarıldı
Güvenliğe erken ilgi ve geri bildirim
- FreeBSD Security Officer deneyimi sayesinde AWS'nin güvenlik yapısına hemen ilgi duydu; AWS istekleri API anahtarıyla imzalanarak kimlik doğrulama ve bütünlük sağlıyordu, ancak yanıtlarda imza bulunmadığını belirtti
- O dönemde AWS isteklerinin HTTP üzerinden yapılması yaygın olduğu için yanıtların tahrif edilmesi gerçek bir riskti; TLS'ye geçildikten sonra da uçtan uca imzalamanın taşıma katmanı güvenliğinden daha üstün olduğu görüşünü korudu
EC2 üzerinde FreeBSD — ilk zorluklar
- Amazon EC2 çıktıktan hemen sonra hedefi FreeBSD'yi çalıştırmaktı; Jeff Barr aracılığıyla Amazon içindeki ilgili kişilerle bağlantı kurdu ve 2007 başında ilk Amazon NDA anlaşmasını imzaladı
- O sırada Amazon hâlâ faks kullanıyordu; kendisinde faks olmadığı için imzalı aslı postayla göndermesi gerekti ve ilk bilgilendirme gecikti
- EC2 başlangıçta özel çekirdek desteği olmadan çıktı (bugünkü AWS Lambda'ya benzer bir modeldi); Kasım 2007'de Red Hat desteğiyle bu özellik açılınca FreeBSD hesabına da dahili "Amazon Kernel Images yayımlama" API'sine erişim verildi
Xen güvenlik denetimi ve yan kanal saldırısı uyarıları
- Mart 2007'de Amazon'daki muhatabına Xen için bir güvenlik denetimi gerektiğini söyledi; uygun denetçiyi bilmedikleri için Tavis Ormandy'yi önerdi
- Aynı yıl Tavis Xen'de iki açık (CVE-2007-1320, CVE-2007-1321) bildirdi, ancak bunun bu öneriyle ilişkili olup olmadığı belirsiz
- Jeff Barr'ın Second Life içindeki AWS kullanıcı buluşmasında salt okunur kök disk ve yeniden başlatmada belleğin sıfırlanmasının garanti edilmesini istedi; bu, güvenilmeyen kod çalıştırma (FreeBSD paket derlemeleri) senaryoları içindi ve EC2 Instance Attestation ancak 18 yıl sonra çıktı
- 2012'de re:Invent'te HyperThreading kullanılarak RSA anahtarı çalma araştırmasını bir EC2 Principal Engineer'a anlattı ve aynı çekirdeğin iki iş parçacığında EC2 instance'larının paralel çalıştırılmamasını kuvvetle tavsiye etti
- Bu tavsiyenin, birçok EC2 instance ailesinin "medium" boyutunu atlayıp doğrudan 2 vCPU'lu ("large") boyutla başlamasının nedeni olduğu söyleniyor
Eventual Consistency ve kuramsal öneriler
- 2007 sonlarında Amazon içinde geniş yankı bulan bir blog yazısında Eventual Consistency sorununa dikkat çekti ve Eventually Known Consistency adını verdiği biraz daha güçlü bir modeli savundu
- CAP teoremindeki "A" (availability) yolunu korurken iç durumu görünür kılarak normal akışta "C"yi (consistency) de sağlayabilen bir modeldi
- Amazon S3 daha sonra kullanılabilirlik optimizasyonundan tutarlılık optimizasyonuna geçti; DynamoDB ise Eventual ve Strongly Consistent okuma arasında seçim sunmaya başladı
Xen uyumluluk sorunları ve FreeBSD'nin açılmaması
- 2008 başında Kip Macy, Xen PAE destekli bir FreeBSD çekirdeği yazdı; dahili AMI araçlarını FreeBSD'ye taşımak ise haftalar sürdü
- Ruby betiklerinin bash betikleri üretip çalıştırdığı yapı için, dil seçiminin yeniden düşünülmesi gerektiğini belirtti
- FreeBSD AMI, EC2 üzerinde açılmıyordu; neden, EC2'nin kullandığı Xen 3.0 sürümündeki ve FreeBSD VM kodunun recursive page table yapısını desteklemeyen bir hataydı
- Bu, Xen 3.1'de düzeltilmişti; ancak kararlı bir ABI sunulmadığından mevcut AMI uyumluluğunu korumak için Amazon Xen 3.0'da kalmayı seçti
AWS imza açığının keşfi ve düzeltilmesi
- Nisan 2008'de Tarsnap beta için Amazon SimpleDB kullanırken imza sistemindeki normalizasyon çakışmasını keşfetti
- O dönemde Amazon'da güvenlik sorunu bildirme kanalı olmadığından bunu Jeff Barr üzerinden iletti
- Amazon, Signature Version 2 tasarımını gözden geçirmesini istedi; belgelerdeki muğlaklıkların düzeltilmesi, tasarım kararlarının revize edilmesi ve hesap allowlist'inin eklenmesi gibi adımların ardından sorun Aralık ayında giderildi
SimpleDB NextToken güvenlik hijyeni sorunu
- Haziran 2008'de SimpleDB'deki NextToken değerinin aslında base64 ile kodlanmış basit bir Java serileştirme nesnesi olduğunu fark etti
- İç bilgi sızmasını önlemek için şifreleme ve tahrifatı önlemek için imza gerektiğini bildirdi, ancak yanıt alamadı
- Altı ay sonra başka bir mühendis üzerinden yeniden bildirdi; iç bilet açıldı, ancak sonrasında da resmî bir yanıt gelmedi
EBS alfa testi ve tasarım geri bildiriminin zamanlaması
- Mart 2008'de EC2 ekibinden Matt Garman, onu Elastic Block Storage'ın (bugünkü Elastic Block Store) kapalı alfa testine davet etti
- Ona göre yeni bir hizmet için en faydalı geri bildirim zamanı, inşa edilmeden önceki tasarım aşamasıydı; matematik ve teori geçmişi nedeniyle alfa testinden çok tasarım dokümanlarını incelemek daha etkiliydi
Amazon'a işe giriş görüşmesi anısı
- 2008'de Jeff Barr'ın teşvikiyle Amazon'a katılmayı düşündü; Al Vermeulen ile yaptığı telefon görüşmesinde 45 dakikanın 30 dakikası exceptions'ın artı ve eksileri tartışmasıyla geçti
- Exception kullanımının, sıradan kod incelemelerinde fark edilmesi zor hatalar üretmeye yatkın, özünde uygunsuz bir hata işleme yöntemi olduğu görüşünü sürdürdü
IAM ve kısıtlı erişim anahtarları — SigV4'e uzanan yol
- Kasım 2008'de Seattle AWS Start-up Tour'da Amazon mühendisleriyle doğrudan görüşüp kısıtlı AWS erişim anahtarları ihtiyacını tartıştı
- Ana sırdan hizmet bazında anahtarların hash ile türetildiği kriptografik türetilmiş anahtar yöntemini savundu; Amazon ise kural tabanlı bir tasarımı tercih etti
- Ocak 2010'da IAM kapalı betasına davet edildi; 2012'de SigV4 çıktığında türetilmiş anahtar yaklaşımı benimsendi
EC2 güvenlik duvarı sorunu ve Path MTU Discovery
- 2009'da EC2'nin varsayılan güvenlik duvarı kurallarının ICMP Destination Unreachable (Fragmentation Required) mesajlarını engelleyerek Path MTU Discovery'yi çalışmaz hale getirdiğini tespit edip bildirdi
- Aralık 2009'da bir EC2 yöneticisi çözüm üzerinde anlaştı, ancak fiilî düzeltme ancak 2012'de konuyu kamuya açık biçimde gündeme getirmesinden sonra yapıldı
NetBSD ile dolaşma ve HVM'e geçiş
- 2010 başında EC2 hâlâ eski Xen sürümünü kullandığı için NetBSD'ye yönelmeyi denedi; bir hafta içinde açılış, dosya sistemi bağlama, ağ ayarı ve
sshdçalıştırma aşamalarına ulaştı - Temmuz 2010'da Cluster Compute instance'ları HVM desteği sununca FreeBSD için de umut doğdu; PV'nin (paravirtualization) teknik bir çıkmaz sokak olduğu netleşti
FreeBSD/EC2'nin ilk çalışması — t1.micro
- Eylül 2010'da çıkan t1.micro instance ailesi içerde Xen 3.4.2 çalıştırıyordu; böylece FreeBSD'nin açılmasını engelleyen hata ortadan kalktı
- Kasım 2010 ortasında FreeBSD/EC2 t1.micro instance'ına SSH ile bağlanmayı başardı; 13 Aralık'ta FreeBSD EC2 t1.micro desteği resmen duyuruldu
Daha fazla instance türü ve "Defenestration" hilesi
- Bir Amazon Solutions Architect, daha büyük instance isteyen FreeBSD kullanıcılarıyla onu buluşturdu ve böylece Cluster Compute instance desteğini hayata geçirdi
- EC2'nin gerçekte hangi işletim sisteminin çalıştığını bilmemesinden yararlanarak defenestration (Windows instance gibi görünme) yöntemiyle tüm 64 bit instance türlerinde FreeBSD kullanımı mümkün oldu
- Bunun için "Windows vergisi" ödemek gerekiyordu ve Amazon da bundan memnun değildi; ama müşteri talebini karşılamak için gerekliydi. Temmuz 2014'te T2 instance'ları HVM "Linux" desteğini tamamlayınca bu hile gereksiz kaldı
S3 yönlendirici donanım arızasının teşhisi
- Nisan 2012'de belirli S3 endpoint'lerinde SignatureDoesNotMatch dahil çok sayıda istek hatası yaşandı
- Hata yanıtlarındaki StringToSign değerinin gönderilen değerle uyuşmama örüntüsünden bir stuck bit tespit etti; traceroute ve milyonlarca ping ile güzergâhtaki belirli bir yönlendiricide donanım arızası olduğunu saptadı
- AWS Developer Forums'ta bildirdikten sonra Amazon birkaç gün içinde arızayı doğrulayıp donanımı değiştirdi
re:Invent 2012 ve yan kanal saldırısı uyarıları
- İlk re:Invent teknik içerik açısından zayıftı ve takım elbiseli katılımcı oranı yüksekti, ancak birçok Amazon mühendisiyle yüz yüze görüşme fırsatı verdi
- Intel'in "sanal makine güvenliği" sunumundaki başkan yardımcısı yan kanal saldırıları hakkında bilgisi olmadığını söyleyince, EC2 standında bir Principal Engineer'a ilgili araştırmayı doğrudan anlattı
FreeBSD/EC2'nin resmileşmesi ve release engineering
- Nisan 2015'te FreeBSD/EC2 için AMI derleme süreci FreeBSD src ağacına entegre edildi; imaj üretimi FreeBSD release engineering ekibine devredilerek kişisel bir projeden resmî FreeBSD projesine dönüştü
- Eylül 2020'de FreeBSD Release Engineering Lead Glen Barber'ın isteğiyle Deputy Release Engineer rolünü kabul etti
- 2022 sonlarında Glen zatürre nedeniyle hastaneye kaldırıldı; uzun süreli etkiler yüzünden geri dönmesi zorlaşınca 17 Kasım 2023'te FreeBSD Release Engineering Lead görevini doğrudan devraldı
- Haftalık snapshot derlemeleri, daha sıkı takvim, öngörülebilir ve daha hızlı sürüm döngüsü oluşturdu; yılda dört sürümü yönetti
IMDS güvenlik uyarısı ve Capital One veri ihlali
- Ekim 2016'da IAM Roles for Amazon EC2 mekanizmasını analiz edip, kimlik doğrulaması olmayan HTTP ile çalışan ve belgelerinde "hassas veri depolamayın" uyarısı bulunan IMDS üzerinden kimlik bilgisi sızmasının tehlikeli olduğunu blogunda yazdı
- Temmuz 2019'da Capital One, tam da bu riskin sömürülmesiyle 106 milyon müşterinin verisini kaptırdı; aynı yıl Kasım'da Amazon'la görüştükten iki hafta sonra IMDSv2 çıktı
- Ona göre IMDSv2 belirli saldırı yollarını hafifletiyor, ancak kimlik bilgilerinin uygunsuz bir arayüz üzerinden açığa çıkması şeklindeki temel sorunu çözmüyor
AWS Heroes programı
- Mayıs 2019'da, Amazon çalışanı olmadan AWS'ye önemli katkılar yapan kişileri tanıyan AWS Heroes programına davet edildi
- Program çoğunlukla geliştirici eğitimi (blog, YouTube, atölye) katkılarıyla öne çıkan kişilere odaklanırken, onun seçilmesi sıra dışıydı; Distinguished Engineer ve Senior Principal Engineer önerileriyle onaylandı
UEFI açılışı ve BootMode=uefi-preferred
- Mart 2021'de EC2, x86 instance'lar için UEFI açılış desteği ekledi; FreeBSD'de UEFI'ye geçince 16 bit mod G/Ç ihtiyacı ortadan kalktı ve açılış süresi 7 saniye kısaldı
- Tüm instance türleri UEFI'yi desteklemediği için hem eski BIOS hem UEFI ile açılabilen imajlar adına BootMode=polyglot ayarını talep etti
- Mart 2023'te bu özellik BootMode=uefi-preferred adıyla hayata geçirildi
Seekable OCI güvenlik sorununun keşfi ve düzeltme gecikmesi
- Ağustos 2023'te Heroes Summit'te Seekable OCI tasarımını görüp belirli kullanım senaryolarında güvenlik iddiasının geçerli olmadığını fark etti ve bunu AWS Security ekibine bildirdi
- İçeride düzeltileceği sözü verildi, ancak pratikte ilerleme olmadı; 2024 re:Invent'te yeniden hatırlattı, Ocak 2025'te tekrar bildirdi ve 2023'teki commit'in yalnızca kazara veri bozulmasını önlediğini, kasıtlı saldırıları engellemediğini doğruladı
- Uyarısından sonra hızlı bir yanıt verildi ve Şubat 2025 sonuna kadar bu özellik müşterilerin çoğu için devre dışı bırakıldı; şimdi "major revision" bekleniyor
Amazon sponsorluğu ve iş birliği modeli
- Nisan 2024'te FreeBSD/EC2 bakımına yeterli zamanı ayıramadığını Amazon'a bildirdi ve maddi destek istedi; birkaç hafta içinde GitHub Sponsors üzerinden haftada 10 saatlik, 1 yıllık destek netleşti
- Çok sayıda birikmiş sorunu kapattıktan sonra altı aylık bir ara verdi (bu sürede büyük ölçüde ücretsiz olarak FreeBSD 15.0 release engineering işine odaklandı) ve ardından ikinci 12 aylık destek başladı
- 20 yıllık katkının tek başına kendi başarısı olmadığını vurgulayarak, AWS iç sistemlerine erişimi olmadan da Amazon mühendislerinin bilet açma, iç bağlantıları bulma, API loglarını inceleme ve teknik doküman temin etme gibi konularda "uzaktaki eller" işlevi gördüğünü anlattı
1 yorum
Hacker News yorumları
Yazar, “Heroes aslında ücretsiz Amazon çalışanları” diye şaka yapmış ama bu şaka değil, gerçeğin ta kendisi
Kendi kişisel araştırmalarımı yayımlamıyorum. Zaten yeterince verimli olan bir değer çıkarma makinesine bedava Ar-Ge sağlamak istemediğim için
Amazon, açık kaynağın ekonomik varsayımlarını yıktı ve bunun sonucunda birçok proje Business Source License'a geçiyor
Bu geliştiriciler Amazon’un ne kadar açgözlü olduğunu biliyor. Sonunda topluluk katkıları dev şirketler için ücretsiz emeğe dönüşüyor ve Amazon, yönetilen hizmetlerle kullanıcıları kendine çekip asıl projenin desteğini ve topluluğunu zayıflatıyor
“Amazon dışındaki herkes serbestçe kullanabilir” diye yazarsanız Amazon hukuki risk yüzünden kullanmaz
Yine de gerekli görürse Amazon’un kendi sürümünü baştan yazması mümkün
Redis örneğinde olduğu gibi, API yüzeyine yönelik hukuki koruma net değil
Eskiden Google v. Oracle kararının böyle bir koruma oluşturmayı ertelediğini hatırlıyorum
Aslında BSL’yi seçen şirketler, gerçek açık kaynak ruhundan çok imaj yönetimi ya da geliştiricilerin sempatisini kazanmak için kodu açmış olabilir
Yine de tamamen katılıyorum. Artık yayımladığım kod ya tam anlamıyla açık kaynak olacak ya da tamamen kapalı kalacak
Eğer birinin bundan para kazanma ihtimali varsa, yayımlamam
Büyük şirketlere zaman vermek istememe bakış açısını anlıyorum ama başka bir perspektif sunmak istiyorum
2006’da yaptığım bir projenin adını, 2012’de başka bir geliştirici kullanmak isteyince memnuniyetle devrettim
O proje scrypt idi, geliştirici de Colin’di
Böyle topluluk nezaketi, ticari beklenti olmasa bile biriken iyi karma haline geliyor
“Jeff Barr’ın AWS kullanıcı buluşması Second Life’ta yapıldı” sözü gerçekten ilginç
Second Life, AWS’in ilk kullanıcılarındandı ve Jeff Bezos 2005’teki yatırım turuna bizzat katıldı
Bu sayede Jeff Barr, Second Life içinde AWS buluşmaları düzenledi; o dönemde Reuters ya da Jonathan Coulton gibi gruplar da sanal alana açılıyordu
Biz Evolution Robotics standındaydık ve ER1 robotunu tanıtıyorduk; Second Life gerçekten etkileyiciydi
Güzel bir anı olarak kaldı
Elbette dizüstü bilgisayar ekranındaki Second Life ile VR gözlüğü tamamen farklı deneyimlerdi
“Amazon için ücretsiz emek” çerçevesi asıl noktayı kaçırıyor
Colin hayır işi yapmadı; Tarsnap FreeBSD/EC2’ye bağlı olduğu için onu iyileştirdi
Bu model, açık kaynağın en sağlıklı biçimi: kendi ürününüzün temelini düzeltirsiniz ve sonuç herkesin yararına olur
Amazon’un doğrudan ilgilenmesini beklemek, sonsuz dek beklemek gibi bir şey
Amazon’un GitHub Sponsors üzerinden haftada 10 saat, 1 yıl boyunca destek verdiğini okuyunca şaşırdım
Saatte 300 dolar, Google L6 mühendis maaşı seviyesinde
Umarım artık daha fazlasını alıyordur
Almanca konuşulan Avrupa’da 120 avroya çok iyi bir mühendis bulunabilir. Doğu Avrupa ise daha da ucuz
Yazarın IAM Roles for EC2 eleştirisine katılmıyorum
IAM, kimlik bilgilerini politika tabanlı yönetmeyi sağlayan temel bir özellik
Outlook, Slack ve Teams’ten çok daha güvenli; hatta takım arkadaşlarının imzalama anahtarını göremeyeceğini matematiksel olarak kanıtlamak bile mümkün
Azure da benzer bir kavramı kullanarak MSSQL erişimini temiz biçimde ele alıyor
Eskiden XenStore üzerinden çekirdeğe kimlik bilgisi aktarılmasını önermiştim. Nitro tabanlı sistemlerde bunu şimdi yapmak daha da kolay olmalı
Çekirdek, kimlik bilgilerini alıp sahiplik ve izin atayabilen sanal bir dosya sistemi olarak sunabilir
Yani sadece CAP_NET_BIND_SERVICE yetkisine sahip süreçler erişebiliyor; bu da hoş bir ayrıntı
vsock(7) soketi kullanılırsa, aldatması daha zor bir bağlantı yöntemi olur ve daha güvenli hale gelir
Hatta DMI verisine bootstrap kimlik bilgileri eklenirse, bunlar yalnızca root’un okuyabildiği bir sysfs dizininde yer alır
2007 tarihli e-postalarıma baktım; başlangıçta AWS hizmetlerine erişimi tek tek talep etmek gerçekten gerekiyormuş
İlk başta sadece “Amazon E-Commerce Service” için onay almıştım, sonra sırayla S3 ve EC2 beta erişimi geldi
O dönemde “Alexa Web Information Service”, sesli asistan değil bir web arama API'siydi. Gerçekten ilginç zamanlardı
Gerçekten ilginç bir teknoloji tarihi kaydı
Tavis Ormandy gibi ünlü mühendislerin bile röportajlarda hata yapabildiğini görmek dikkat çekici
Böyle deneyim anlatısı içeren blog yazılarını seviyorum
20 yıllık değerlendirmede Hetzner ya da OVH adının geçmemesi manidar
Ben AWS, Hetzner ve küçük bulut sağlayıcıları birlikte kullanıyorum; fiyat farkı devasa
AWS aylık 350 dolar, Hetzner ise benzer özellikler ve 20 TB trafik dahil 20~25 avro
AWS’in bugün sattığı şey artık hesaplama gücü değil; IAM modeli, küresel altyapı ve kurum içi uzlaşı
“AWS’i seçersen kimse işten atılmaz” algısı asıl ürün haline geldi
Yakın zamanda AWS’den iş yükü taşıyanlara sormak isterim — beklediğinizden daha acı verici olan kısım neydi?