- Storm-0558 olayı Exchange Online ve Outlook.com ihlali olarak bilinse de, ele geçirilen MSA imzalama anahtarının Azure AD uygulamalarında OpenID v2.0 token sahteciliği için de kötüye kullanılabildiğine dair analizler ortaya çıktı
- Olası etki alanı; kişisel Microsoft hesabı kimlik doğrulaması kullanan Microsoft uygulamalarına, “Login with Microsoft” destekleyen müşteri uygulamalarına ve belirli koşullardaki çok kiracılı uygulamalara kadar genişliyor
- Söz konusu açık anahtar en az 2016’dan beri Microsoft OpenID anahtar listesinde yer alıyordu; 27 Haziran–5 Temmuz 2023 arasında değiştirildi ve Microsoft’un açıkladığı acquired signing key ile thumbprint değeri eşleşiyor
- Microsoft anahtarı kullanımdan kaldırarak yeni sahte token’ları engelledi; ancak anahtar kullanımdan kaldırılmadan önce oluşturulmuş oturumlara veya eski açık anahtar önbelleklerine güvenmeye devam eden uygulamalar için ayrıca kontrol gerekiyor
- Sahte token’lar çevrimdışı oluşturulabildiğinden Azure portalında verilme izi kalmıyor; ham token veya
kidgünlükleri yoksa ihlali doğrulamak çok zor
Exchange Online’ın Ötesine Geçen Etki Alanı
- Microsoft ve CISA, Exchange Online ve Outlook.com’un birçok müşterisini etkileyen bir güvenlik olayını açıkladı
- Microsoft’a göre Çin bağlantılı tehdit aktörü olarak tanımlanan Storm-0558, kişisel şifreleme anahtarı olan MSA anahtarını elde ederek Outlook Web Access ve Outlook.com için access token’lar sahteledi
- Tehdit aktörünün Microsoft’un token doğrulama sürecindeki iki güvenlik sorununu da birlikte kötüye kullandığı bildirildi
- Wiz Research analizine göre ele geçirilen anahtar yalnızca Outlook.com ve Exchange Online ile sınırlı değildi; çeşitli Azure Active Directory uygulamaları için access token sahteciliğinde de kullanılabiliyordu
- Kişisel hesap kimlik doğrulamasını destekleyen uygulamalar
- SharePoint, Teams, OneDrive gibi Microsoft tarafından yönetilen uygulamalar
- “Login with Microsoft” destekleyen müşteri uygulamaları
- Belirli koşullardaki çok kiracılı uygulamalar
Ele Geçirilen Anahtar Nasıl Doğrulandı?
- 11 Temmuz 2023’te Microsoft, kötü niyetli bir aktörün MSA consumer signing key elde ederek Exchange Online ve Outlook.com hesapları için access token sahteleyebildiğini açıkladı
- Wiz, Microsoft hesapları ve Azure Active Directory uygulamaları için OpenID token’larını imzalayabilen anahtarı doğrulamak amacıyla Microsoft’un OpenID token doğrulamaya ilişkin resmi belgelerini inceledi
- O dönemde Azure kişisel hesap v2.0 uygulamaları 8 açık anahtara, Microsoft hesaplarını etkinleştiren Azure çok kiracılı v2.0 uygulamaları ise 7 açık anahtara dayanıyordu
- Internet Archive Wayback Machine kontrolüne göre, en az 2016’dan beri listede bulunan bir açık anahtar 2023’te 27 Haziran–5 Temmuz arasında değiştirildi
- Bu zamanlama, Microsoft’un blogunda belirttiği elde edilen anahtarı değiştirme zamanıyla örtüşüyor
- Önceki açık anahtar sertifikası 5 Nisan 2016’da verilmiş ve 4 Nisan 2021’de süresi dolmuştu
- Thumbprint değeri, Microsoft’un en son blogunda “Thumbprint of acquired signing key” olarak açıkladığı değerle aynı
- Storm-0558’in elde ettiği anahtar Microsoft’un MSA tenant’ına ait özel anahtardı; ancak çeşitli Azure Active Directory uygulamaları için OpenID v2.0 token’larını da imzalayabildiği değerlendiriliyor
OpenID İmzalama Anahtarının Ele Geçirilmesi Neden Tehlikeli?
- Azure identity platform, uygulama türlerine göre farklı güvenilen açık anahtar listeleri yayımlar ve Azure Active Directory’nin verdiği token’ların bütünlüğünü doğrulamak için bunları kullanır
- AAD uygulamaları, doğru açık anahtar listesiyle token imzasını doğruladıktan sonra token’a güvenilip güvenilmeyeceğine karar verir
- Listedeki anahtarlardan biri ele geçirilirse, bu listeyle doğrulama yapan uygulamalar belirli koşullarda sahte access token’ları geçerli token olarak kabul edebilir
- Wiz’in Microsoft blogundan çıkardığı sonuca göre Storm-0558’in, AAD access token imzalama ve doğrulamada kullanılan birden fazla anahtardan birine eriştiği görülüyor
- Ele geçirilen anahtar; kişisel hesaplar ve mixed-audience, yani çok kiracılı veya kişisel hesap hedefli AAD uygulamalarının OpenID v2.0 access token’larını imzalamak için güvenilir kabul ediliyordu
- Sonuç olarak Storm-0558, teorik olarak Microsoft OpenID v2.0 mixed audience ve kişisel hesap sertifikalarına güvenen etkilenen uygulamalarda, herhangi bir kullanıcı olarak kimlik doğrulaması sağlayan token’lar sahteleyebilirdi
- Identity provider’ın imzalama anahtarı, TLS anahtarından daha güçlü bir sır olarak görülebilir
- TLS anahtarı sızsa bile saldırganın etkiyi genişletmek için ilgili sunucunun kimliğine bürünmesi gerekir
- Identity provider anahtarı; e-posta kutuları, dosya hizmetleri, bulut hesapları gibi yerlere tek adımda erişim sağlayabilen token sahteciliği için kullanılabilir
- Aynı risk yalnızca Microsoft için değil, Google, Facebook, Okta gibi büyük identity provider’ların imzalama anahtarlarının sızması için de geçerlidir
Etkilenen Uygulama Türleri
- Etkilenen kapsam, Microsoft’un OpenID v2.0’ını kullanan Azure Active Directory uygulamalarıyla sınırlıdır
- v1.0 uygulamaları, ele geçirilen anahtarı token doğrulamada kullanmadıkları için etkilenmez
-
Yalnızca Kişisel Microsoft Hesaplarını Destekleyen Uygulamalar
- Microsoft v2.0 protokolünü kullanan ve “Personal Microsoft accounts only” destekleyen Azure Active Directory uygulamaları etkilenir
- Outlook, SharePoint, OneDrive, Teams gibi Microsoft tarafından yönetilen uygulamalar ve Microsoft Account kimlik doğrulamasını destekleyen müşteri uygulamaları buna dahildir
-
Çok Kiracılı ve Kişisel Microsoft Hesaplarını Birlikte Destekleyen Uygulamalar
- “mixed audience” destekleyen ve Microsoft v2.0 protokolünü kullanan Azure Active Directory uygulamaları da etkilenir
- Tehdit aktörü, kişisel Microsoft hesabıyla oturum açmış uygulama kullanıcısının kimliğine bürünen geçerli access token’lar sahteleyebiliyordu
- Microsoft, MSA anahtarının kurumsal hesapların kimliğine bürünme yeteneğini sınırlamak için bir OpenID protokol uzantısı getirdi
- Geliştiriciler issuer claim’i OpenID açık anahtar listesindeki issuer alanıyla karşılaştırarak doğrulamalıdır
- Bu doğrulama, MSA tenant olmayan bir issuer’a sahip access token’ların MSA anahtarıyla imzalanmasını engellemeye yönelik bir mekanizmadır
- Uzantı Microsoft’a özeldir ve uygulama sorumluluğu uygulama sahibindedir
- Wiz, birçok uygulamada bu doğrulama prosedürünün olmayabileceğini ve bunun sonucunda kurumsal hesapların kimliğine bürünme olasılığının da devam edebileceğini düşünüyor
- Microsoft bloguna göre OWA da benzer bir sorundan etkilendi
- Microsoft, 12 Temmuz’da bu doğrulama özelliğini resmi Azure SDK’ye ekledi
-
Yalnızca Çok Kiracılı Uygulamalar
- Çok kiracılı bir uygulama “Organizations” yerine common v2.0 anahtar endpoint’ine dayanacak şekilde yapılandırıldıysa etkilenir
- Bu yapılandırma hatalı yapılandırma olarak kabul edilmelidir
- Microsoft’un resmi belgeleri, “common” endpoint’inin ne zaman kullanılması gerektiği konusunda net olmadığı için bazı çok kiracılı uygulamalar da etkilenebilir
-
Tek Kiracılı Uygulamalar
- “Yalnızca bu kuruluş dizinindeki hesaplar” destekleyen tek kiracılı uygulamalar etkilenmez
Token Sahteciliğinin Geçerli Olması İçin Koşullar
- OpenID token doğrulamasında uygulama geliştiricileri, token’ın amaçlanan kapsam için yetkili bir özel anahtarla imzalanıp imzalanmadığını ve
audalanının hedef uygulama kapsamıyla eşleşip eşleşmediğini kontrol etmelidir - Uygulama, imza doğrulaması için izin verilen sertifikaları
jwks_uriadlı metadata endpoint’inden alarak token’ı doğrular - Tehdit aktörü bir JWT token oluşturup kurbanın e-posta adresi gibi verileri doldurduktan sonra, Azure Active Directory açık sertifika endpoint’ine kayıtlı ele geçirilmiş anahtarla imzalayarak geçerli bir access token sahteleyebilir
- Örnek olarak belirtilen ele geçirilmiş anahtarın
kiddeğeri1LTMzakihiRla_8z2BEJVXeWMqoşeklindedir - Microsoft yönergelerine göre token’ın geçerli olması için
issclaim’ijwks_uriendpoint’inin issuer alanında belirtilen MSA tenant issuer’ı olmalı,tidclaim’i de MSA tenant ID’si olan9188040d-6c67-4c5b-b112-36a304b66dadolmalıdır - AAD mixed-audience uygulamalarında, kişisel hesabın kimliğine bürünüldüğü sürece MSA tenant tarafından Azure AD hesapları için imzalanan token geçerli sayılabilir
- ID Token doğrulama ayrıntıları Microsoft’un resmi yönergelerinde bulunabilir
Anahtar Kullanımdan Kaldırıldıktan Sonra da Kalan Riskler
- Microsoft ele geçirilen anahtarı kullanımdan kaldırdığı için Azure Active Directory uygulamaları artık bu anahtarla sahte olarak imzalanmış token’ları geçerli kabul etmiyor
- Uzun süreli sona erme zamanı ayarlanmış token’lar da uygulamalar tarafından reddediliyor
- Ancak anahtar kullanımdan kaldırılmadan önce müşteri uygulamasında hâlihazırda oturum oluşturulduysa, tehdit aktörü uygulama yetkilerini kullanarak kalıcılık elde etmiş olabilir
- Uygulamaya özel erişim anahtarı verilmesi
- Uygulamaya özel arka kapı ayarlanması
- Microsoft’un önlemleri öncesinde Storm-0558’in OWA için access token sahteleyerek geçerli Exchange Online access token verdiği örnek
- Microsoft sertifikası kullanımdan kaldırılmadan önceki AAD açık anahtar kopyalarını tutan uygulamalar da risk altında olabilir
- Yerel sertifika deposu veya önbelleğe alınmış anahtarları kullanıp ele geçirilmiş anahtara güvenmeye devam ederlerse token sahteciliğine karşı savunmasızdırlar
- Microsoft, yerel depoların ve sertifika önbelleklerinin en az günde bir kez yenilenmesini önerir
Azure Kullanıcılarının Kontrol Etmesi Gerekenler
- Ortamda ele geçirilmiş anahtarın kullanılıp kullanılmadığını kontrol etmek için potansiyel olarak etkilenen uygulamalar belirlenmeli, sahte token kullanım izleri aranmalı ve Microsoft’un açıkladığı Indicators of Compromise kullanılarak ilgili IP etkinliği incelenmelidir
- Microsoft OpenID açık sertifikalarını önbelleğe alan uygulamalar varsa önbellek yenilenmelidir
- Microsoft, MSA anahtarıyla kurumsal hesaplarda kimlik doğrulamayı engellemek için resmi Azure SDK’ye ek doğrulama ekledi; bu paketi kullananlar en son sürüme güncellemelidir
Tespit Etmenin Zor Olmasının Nedenleri
- Tehdit aktörü access token’ları çevrimdışı sahteleyebildiği için Azure portalında token verilme izi kalmaz
- Bulut müşterileri anahtar kullanımını doğrulamak için etkilenebilecek AAD uygulamalarının uygulama bazlı günlüklerini incelemelidir
- Wiz’in belirlediği etki kapsamı, Microsoft v2.0 access token doğrulamasında aşağıdaki endpoint’leri kullanan uygulamalardır
- Potansiyel olarak etkilenen AAD uygulamaları, Azure CLI ile
signinaudiencedeğeriAzureADMultipleOrgs,AzureADandPersonalMicrosoftAccount,PersonalMicrosoftAccountolan uygulamalar sorgulanarak belirlenebilir - Azure WebApps’e yönlendirilen AAD uygulamaları da ayrı bir CLI sorgusuyla bulunabilir
- Uygulamada kullanılan access token çözülerek JOSE Header’daki
kidalanında1LTMzakihiRla_8z2BEJVXeWMqodizgesinin olup olmadığı kontrol edilirse ele geçirilmiş anahtarla imzalanmış token’lar bulunabilir - Microsoft’a göre ele geçirilen anahtar etkin değildi; bu nedenle bu anahtarla imzalanmış tüm access token’lar şüpheli olarak değerlendirilmelidir
- Uygulamaya özel logging için standartlaştırılmış pratikler eksiktir
- Birçok uygulama sahibi ham access token’ları veya imzalama anahtarını içeren ayrıntılı günlüklere sahip değildir
- Bu nedenle olayların belirlenmesi ve incelenmesi çok zor olabilir
- Kişisel Microsoft hesaplarını desteklemeyen, yalnızca çok kiracılı AAD uygulamalarında sahte token’lar
issvetidclaim’leriyle tespit edilebilir- MSA tenant ID’si
9188040d-6c67-4c5b-b112-36a304b66dadile imzalanmış access token bağlantı girişimi, ele geçirilmiş anahtar kullanımına işaret edebilir
- MSA tenant ID’si
- WebApp’te HTTP Logs etkinleştirildiyse Microsoft blogunda yer alan tehdit aktörüyle ilişkili IP adreslerinin uygulamaya erişip erişmediği Log Analytics ile kontrol edilebilir
Kalan Sorular ve Pratik Sonuç
- Toplam etki ilk bilinenden çok daha büyük; bulut güveni ve özellikle bulutun temel bileşeni olan identity layer üzerinde uzun vadeli etkiler yaratabilir
- Potansiyel olarak savunmasız olan uygulama sayısı Microsoft uygulamaları ve müşteri uygulamaları dahil milyonları buluyordu; birçoğunda ihlal olup olmadığını değerlendirmeye yetecek günlük bulunmuyor
- Uygulama sahipleri öncelikle Azure SDK’yi en son sürüme güncellemeli ve uygulama önbelleğinin yenilenip yenilenmediğini kontrol etmelidir
- Önbelleği güncellenmemiş uygulamalar, ele geçirilmiş anahtarı kullanan tehdit aktörlerine karşı hâlâ savunmasız olabilir
- Konu hâlâ araştırılıyor; tehdit aktörünün anahtarı nasıl elde ettiği, tam olarak ne zaman gerçekleştiği ve başka anahtarların da ele geçirilip geçirilmediği yalnızca kamuya açıklanan bilgilerle yanıtlanması zor sorular
1 yorum
Hacker News yorumları
Kimlik sağlayıcısı imzalama anahtarları, modern dünyadaki en güçlü sırlara en yakın şeylerden biri. Örneğin TLS anahtarlarından çok daha güçlüler
Birçok açıdan sertifika otoritesi (CA) anahtarlarıyla aynı seviyedeler; Microsoft ve Azure hizmetlerini kullanan kuruluşların olası etkiyi değerlendirmesi gerekiyor
Görünüşe göre insanlar “tüm yumurtaları aynı sepete koyma” şeklindeki eski sözü unutmuş
Neden onlarca, yüzlerce, belki de binlerce sunucunun az sayıda anahtarı paylaştığı bir mimari var, merak ediyorum
HSM tabanlı kök anahtar, veri merkezi başına ara anahtar, sunucu başına geçici imzalama anahtarı ve sertifika iptal listeleri nerede, merak konusu
Bu tür saldırılarda bearer token’ları güvenli biçimde korumak mümkün mü; yoksa kaynak hizmete bir nonce sunup payload’u güvenli şekilde alma modeline mi dönmek gerekir, diye düşünüyorum
Yalnızca yumurtaları tek yerde toplayınca kullanılabilen özellikler ortaya çıkmış oldu
Her şey çöktüğünde diye patlamış mısırı hazırladım; kesin olan şu ki şirket suçu kendinde bulmayacak
Sadece anahtarını kaybetmemiş başka bir tedarikçi kullanın demek mi, bilmiyorum
Artık fiilen sadece yaklaşık 4 büyük teknoloji şirketi kalmış gibi
“Ele geçirilen MSA anahtarıyla saldırganların çeşitli Azure Active Directory uygulamaları için erişim token’ları sahteleyebilmiş olabileceği” sonucuna varıldı
Buna SharePoint, Teams, OneDrive, “Microsoft ile oturum aç” desteği veren müşteri uygulamaları ve belirli koşullardaki çok kiracılı uygulamalar gibi kişisel hesap kimlik doğrulamasını destekleyen tüm uygulamalar dahil
Microsoft’un yakın zamanda Azure AD’yi Entra ID olarak yeniden adlandırmış olmasının tesadüf olmasını umuyorum: https://devblogs.microsoft.com/identity/aad-rebrand/
Bir güvenlik ürününü düşündüğümde, kötü niyetli aktörleri dışarıda tutan değil de insanları içeri “alan” bir sağlayıcıyı düşünmek istemem. Entra, entrar’dan, yani girmek/içeri gelmekten geliyor /s
İspanyolcada emir kipi olduğu için birine “gir!” diye talimat veriyormuş hissi bile veriyor
“Mevcut açık anahtarın sertifikası 5 Nisan 2016’da düzenlenmiş, 4 Nisan 2021’de süresi dolmuştu; parmak izi de Microsoft’un son blog yazısında ‘elde edilen imzalama anahtarının parmak izi’ olarak paylaştığı anahtarın parmak iziyle eşleşiyordu”
Bunu doğru okuyorsam, anahtarın süresi dolmuş olmasına rağmen kullanılmaya devam edildiği anlamına mı geliyor?
Microsoft bu anahtarları nerede kullandıysa hangi yöntemin geçerli olduğunu bilen var mı merak ediyorum.
Biri TLS doğrulama yöntemi; Cn’nin Cn-1 tarafından imzalandığı ve bunun … C0’a kadar giden bir sertifika zinciri olarak denetlendiği durumda kabaca şöyle çalışır:
1 time_check = now()
2 for cert in Cn to C0
3 if time_check < cert.valid_from || time_check > cert.valid_to
4 return EXPIRED
5 return NOT_EXPIRED
Her sertifikanın son kullanma tarihi mevcut zamana göre kontrol edilir.
Diğeri ise kod imzalamada kullanılan yöntem; kabaca şöyledir:
1 time_check = now()
2 for cert in Cn to C0
3 if time_check < cert.valid_from || time_check > cert.valid_to
4 return EXPIRED
5 time_check = cert.issue_time
6 return NOT_EXPIRED
Cn mevcut zamana göre kontrol edilir, geri kalanlar ise hemen altlarındaki sertifikanın imzalandığı zamana göre kontrol edilir.
Kod imzalamanın neden böyle çalıştığını anlıyorum. Özünde dijital noterlik; noterin sonradan yetkisini kaybetmesi ve lisansının süresinin dolması, daha önce noterlenmiş bir belgenin noterlenmemiş hale gelmesine yol açmamalı.
Ayrıca “bir doğrulama sorunu nedeniyle bu anahtar Azure AD token imzalama için güvenilir sayılabildi” dediğinde, “birden fazla doğrulama sorunu nedeniyle bu anahtar Azure AD token imzalama için güvenilir sayılabildi” demeliydi.
Ve “aktörler hedef ortamı, günlükleme politikalarını, kimlik doğrulama gereksinimlerini, politika ve prosedürleri iyi biliyordu” dediğinde ise bunun yerine şöyle demeliydi:
“Aktörler cesur bir vur-kaç peşindeydi ve politika gibi ayrıntılarla bir saniye bile ilgilenmemiş olabilir. Ya da aktörler acemiydi ve ABD Dışişleri Bakanlığı’nın posta kutusu erişim olaylarını ayrıntılı günlükleyebilme ayrıcalığı için bize çok daha fazla para ödediğinin farkında bile olmayabilirlerdi. Boeing, MCAS ile ipucunu vermişti. Üstelik aktörler Chrome 92’nin en son 2021’de güncellendiğini ve güncel tarayıcı kullanması gereken ABD bakanlık ICT sistemlerine saldırmak için oldukça kötü bir user agent seçimi olduğunu da gözden kaçırmış görünüyor. Ayrıca ABD Dışişleri Bakanlığı posta kutularına nasıl erişildiği konusunda neredeyse hiçbir şey bilmiyor ve Avrupa genelindeki rastgele halka açık veri merkezlerini kullanarak berbat tahminlerde bulunmuş görünüyorlar.”
[1] https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...
[2] https://www.cisa.gov/news-events/cybersecurity-advisories/aa...
[3] https://www.theguardian.com/us-news/2023/jul/20/ambassador-t...
Bu anahtarın HSM içinde olma ihtimali çok düşük görünüyor.
HSM’de olması gerektiğini düşündüğüm bir anahtarın çalındığı haberini her gördüğümde şaşırmaya devam ediyorum.
Yakın zamanda araç zincirleri ile donanımsal güvenlik enklavları arasındaki boşluğu kapatmak için ideal bir aracı kendim geliştirebildim: https://keymux.com
Azure AD ölçeği düşünüldüğünde bile Microsoft’un imzalama amacıyla çok sayıda HSM’e ihtiyaç duymayabilir.
Ancak HSM’lerin yönetimi özellikle kolay değil; bu da gerektiği kadar yaygın kullanılmamalarının nedenlerinden biri olabilir.
[1] https://cpl.thalesgroup.com/encryption/hardware-security-mod...
Birincisi, Microsoft JWT imzalama anahtarını belleğe alıp kullanmış ve saldırgan kod enjeksiyonu ya da ilgili sürecin bellek imajına erişim yoluyla anahtarı elde etmiş olabilir.
İkincisi, Microsoft gerçekten HSM kullanmış ama anahtarı coğrafi olarak dağıtmak zorunda kalmış ve saldırgan bu süreçte anahtara erişmiş olabilir.
İlk seçenek daha olası, ama ikincisi de dışlanamaz.
FAANG’lerin birbirlerine karşı siber savaş/casusluk yapmasının yasallaştırılması gerekmez mi?
O zaman belirsizliğe yaslanmak yerine en azından asgari güvenlik en iyi uygulamaları seviyesine ulaşmaları gerekirmiş gibi geliyor.
Gerçek zarar vermeden ya da gerçek müşteri verisi indirmeden bulgularını açıklarsan bu zaten yasal.
Satya’nın bir sonraki bilanço sunumunda bu karmaşayı örtbas etmek için AI kelimesini çok daha fazla söylemesi gerekecek gibi.
Yabancı bir gücün, o güçle muhatap olan temsilcimizin e-posta hesabına girmesinden daha kötü bir ihlal hayal etmek zor.
ABD hükümetinin bilişimi büyük bulut sağlayıcılarına taşıma politikalarını ciddi biçimde yeniden değerlendirmesini umuyorum
“Son olarak, bu yazı üzerinde bizimle yakın şekilde çalışan ve teknik olarak doğru olduğundan emin olmamıza yardımcı olan Microsoft ekibine teşekkür ederiz”
Bu haberi cuma günü yayımlamaya nasıl karar verdiler acaba?
Google Haberler’de “microsoft” diye aratıp ilk 5 sayfaya baktıktan sonra pes ettim; ilgili bahisten toplam sadece 2 tane vardı
Çoğu PR yazısı, ürün tanıtımı, hisse fiyatıyla ilgili gürültü gibi “haber”lerdi
“Bu olayın toplam etkisi, ilk anladığımızdan çok daha büyük. Bu olayın buluta duyulan güven ve onu ayakta tutan temel bileşenler, en başta da bulutta yaptığımız her şeyin temel dokusu olan kimlik katmanı üzerinde uzun vadeli etkileri olacak. Buradan ders çıkarıp iyileşmemiz gerekiyor”
Belki işe önce her şeyi buluta koymamakla başlasak?
Sorun bulutun kendisinden ziyade, sonunda tekel ya da birkaç büyük şirketten oluşan bir kartel doğuran bozuk kapitalist ekonomide
Uzun kuyruktaki küçük şirketler için büyük şirketlerin ürün ve hizmetlerini kullanmak mantıklı olmasa bile, pazarın kazananına daha fazla güç verdiğinizde sonunda batmasına izin verilemeyecek kadar büyük şirketler ortaya çıkıyor
Böyle büyük şirketlerde tek bir hata, tek bir sendeleme bile saldırı yüzeyini aşırı büyütüyor. Bu tür kazalar olup olmayacağı meselesi değil, ne zaman olacağı meselesi
Uzun vadede toplumun ayakta kalması için, kolaylığın bir kısmından feragat etmek gerekse de yanıt federe hizmetler
İş liderleri, daha büyük ve daha iyi federe hizmetlerin hayalini kuran teknoloji meraklıları değil
IT genelde hem gelir tablosunda hem de bilgisayar sorunlarını öğrenmek, karar vermek ve bunlarla boğuşmak için harcanan zaman ve acı açısından büyük bir maliyet
Bir benzetmeyle, hava belirsizken yine de Microsoft Airlines’a binmeye karar verdiyseniz, uçuş iptal olup geç kalsanız bile yanınızda aynı durumda olan ve sizi anlayan çok kişi olur
Buna karşılık trene binmek gibi bağımsız bir yol seçerseniz, tren saatlerini ve istasyonları çözme yükü tamamen sizin omuzlarınıza biner. Çünkü “uçak herkesin bildiği” yöntemdir
Ve Microsoft Air sorunsuz varırken trende sorun çıkarsa, mutfak zeminindeki dumanı tüten yığın gibi tek başınıza göze batarsınız
Harika bir derlemeydi ve korkutucuydu
Karmaşık bir konu olmasına rağmen sindirimi kolay şekilde anlatılmıştı