Kunci Microsoft yang Dikompromikan: Dampaknya Lebih Besar dari Perkiraan

 (wiz.io)
1 poin oleh GN⁺ 2023-07-24 | 1 komentar | Bagikan ke WhatsApp
  • Insiden Storm-0558 dikenal sebagai kompromi terhadap Exchange Online dan Outlook.com, tetapi analisis menunjukkan bahwa kunci penandatanganan MSA yang dikompromikan juga dapat disalahgunakan untuk memalsukan token OpenID v2.0 pada aplikasi Azure AD
  • Cakupan potensi dampaknya meluas hingga aplikasi Microsoft yang menggunakan autentikasi akun Microsoft pribadi, aplikasi pelanggan dengan “Login with Microsoft”, dan bahkan aplikasi multitenant dalam kondisi tertentu
  • Kunci publik yang dimaksud telah ada di daftar kunci OpenID Microsoft setidaknya sejak 2016, diganti antara 27 Juni 2023 hingga 5 Juli 2023, dan cocok dengan acquired signing key serta thumbprint yang diungkap Microsoft
  • Microsoft telah mencabut kunci tersebut sehingga token palsu baru dapat diblokir, tetapi sesi yang dibuat sebelum pencabutan kunci atau aplikasi yang masih mempercayai cache kunci publik lama tetap perlu diperiksa secara terpisah
  • Karena token palsu dapat dibuat secara offline, tidak ada jejak penerbitan di portal Azure, dan tanpa token mentah atau log kid, konfirmasi kompromi menjadi sangat sulit

Cakupan dampak melampaui Exchange Online

  • Microsoft dan CISA mengungkap insiden keamanan yang memengaruhi sejumlah pelanggan Exchange Online dan Outlook.com
  • Menurut Microsoft, Storm-0558, yang disebut sebagai aktor ancaman terkait Tiongkok, memperoleh kunci MSA berupa kunci privat dan memalsukan access token untuk Outlook Web Access dan Outlook.com
  • Disebutkan pula bahwa aktor ancaman tersebut turut mengeksploitasi dua masalah keamanan dalam proses validasi token Microsoft
  • Menurut analisis Wiz Research, kunci yang dikompromikan tidak terbatas pada Outlook.com dan Exchange Online, tetapi juga dapat digunakan untuk memalsukan access token bagi berbagai aplikasi Azure Active Directory
    • aplikasi yang mendukung autentikasi akun pribadi
    • aplikasi yang dikelola Microsoft seperti SharePoint, Teams, dan OneDrive
    • aplikasi pelanggan yang mendukung “Login with Microsoft”
    • aplikasi multitenant dalam kondisi tertentu

Bagaimana kunci yang dikompromikan diidentifikasi

  • Pada 11 Juli 2023, Microsoft mengungkap bahwa pelaku berbahaya telah memperoleh MSA consumer signing key sehingga dapat memalsukan access token untuk akun Exchange Online dan Outlook.com
  • Wiz meneliti dokumentasi resmi validasi token OpenID Microsoft untuk memverifikasi kunci yang dapat menandatangani token OpenID untuk akun Microsoft dan aplikasi Azure Active Directory
  • Saat itu, aplikasi Azure akun pribadi v2.0 bergantung pada 8 kunci publik, sementara aplikasi Azure multitenant v2.0 dengan akun Microsoft aktif bergantung pada 7 kunci publik
  • Berdasarkan pengecekan dengan Internet Archive Wayback Machine, satu kunci publik yang ada dalam daftar setidaknya sejak 2016 diganti pada periode 27 Juni 2023 hingga 5 Juli 2023
    • Waktu ini sesuai dengan waktu penggantian kunci yang diperoleh dan disebut Microsoft dalam blognya
    • Sertifikat kunci publik sebelumnya diterbitkan pada 5 April 2016 dan kedaluwarsa pada 4 April 2021
    • Thumbprint-nya sama dengan nilai yang dipublikasikan Microsoft dalam blog terbarunya sebagai “Thumbprint of acquired signing key”
  • Kunci yang diperoleh Storm-0558 adalah kunci privat untuk MSA tenant milik Microsoft, tetapi menurut analisis juga dapat digunakan untuk menandatangani token OpenID v2.0 bagi berbagai aplikasi Azure Active Directory

Mengapa kompromi kunci penandatanganan OpenID berbahaya

  • Azure identity platform memublikasikan daftar kunci publik tepercaya yang berbeda berdasarkan jenis aplikasi, dan menggunakannya untuk memverifikasi integritas token yang diterbitkan Azure Active Directory
  • Aplikasi AAD memutuskan apakah sebuah token dapat dipercaya setelah memverifikasi tanda tangan token menggunakan daftar kunci publik yang benar
  • Jika satu kunci dalam daftar tersebut dikompromikan, aplikasi yang memverifikasi dengan daftar itu dapat, dalam kondisi tertentu, menerima access token palsu sebagai token yang valid
  • Berdasarkan inferensi Wiz dari blog Microsoft, Storm-0558 tampaknya memperoleh akses ke salah satu dari beberapa kunci yang digunakan untuk penandatanganan dan validasi access token AAD
  • Kunci yang dikompromikan dipercaya untuk menandatangani access token OpenID v2.0 bagi aplikasi AAD yang menargetkan akun pribadi dan mixed-audience, yaitu aplikasi multitenant atau akun pribadi
  • Akibatnya, secara teoritis Storm-0558 dapat memalsukan token yang mengautentikasi dirinya sebagai pengguna mana pun pada aplikasi terdampak yang mempercayai sertifikat OpenID v2.0 Microsoft untuk mixed audience dan akun pribadi
  • Kunci penandatanganan milik identity provider dapat dianggap sebagai rahasia yang lebih kuat daripada kunci TLS
    • Meski kunci TLS bocor, penyerang tetap harus menyamar sebagai server terkait untuk memperluas dampak
    • Kunci identity provider dapat digunakan untuk memalsukan token yang memberi akses satu langkah ke kotak email, layanan file, akun cloud, dan lainnya
    • Risiko yang sama berlaku tidak hanya bagi Microsoft, tetapi juga jika terjadi kebocoran kunci penandatanganan milik identity provider besar seperti Google, Facebook, dan Okta

Jenis aplikasi yang terdampak

  • Dampak terbatas pada aplikasi Azure Active Directory yang menggunakan OpenID v2.0 milik Microsoft
  • Aplikasi v1.0 tidak terdampak karena tidak menggunakan kunci yang dikompromikan untuk validasi token

  • Aplikasi yang hanya mendukung akun Microsoft pribadi

    • Aplikasi Azure Active Directory yang menggunakan protokol Microsoft v2.0 dan mendukung “Personal Microsoft accounts only” terdampak
    • Ini mencakup aplikasi yang dikelola Microsoft seperti Outlook, SharePoint, OneDrive, dan Teams, serta aplikasi pelanggan yang mendukung autentikasi Microsoft Account

  • Aplikasi yang mendukung multitenant dan akun Microsoft pribadi sekaligus

    • Aplikasi Azure Active Directory yang mendukung “mixed audience” dan menggunakan protokol Microsoft v2.0 juga terdampak
    • Aktor ancaman dapat memalsukan access token valid untuk menyamar sebagai pengguna aplikasi yang login dengan akun Microsoft pribadi
    • Microsoft memperkenalkan perluasan protokol OpenID untuk membatasi kemampuan kunci MSA dalam menyamar sebagai akun organisasi
    • Pengembang harus memverifikasi issuer claim dengan membandingkannya terhadap field issuer pada daftar kunci publik OpenID
    • Validasi ini dimaksudkan untuk mencegah kunci MSA menandatangani access token dengan issuer selain issuer milik MSA tenant
    • Perluasan ini bersifat khusus Microsoft dan tanggung jawab implementasinya ada pada pemilik aplikasi
    • Wiz menilai banyak aplikasi mungkin tidak memiliki prosedur validasi ini, sehingga kemungkinan penyamaran akun organisasi juga masih dapat terjadi
    • Menurut blog Microsoft, OWA juga terdampak masalah serupa
    • Pada 12 Juli, Microsoft menambahkan fungsi validasi ini ke Azure SDK resmi

  • Aplikasi yang hanya mendukung multitenant

    • Aplikasi multitenant akan terdampak jika dikonfigurasi bergantung pada endpoint kunci v2.0 common alih-alih “Organizations”
    • Konfigurasi seperti ini harus dianggap sebagai misconfiguration
    • Dokumentasi resmi Microsoft tidak menjelaskan dengan jelas kapan endpoint “common” harus digunakan, sehingga sebagian aplikasi multitenant juga bisa terdampak

  • Aplikasi single-tenant

    • Aplikasi single-tenant yang hanya mendukung “Accounts in this organizational directory only” tidak terdampak

Syarat agar pemalsuan token berhasil

  • Dalam validasi token OpenID, pengembang aplikasi harus memastikan token ditandatangani oleh kunci privat yang berwenang untuk cakupan yang dimaksud, serta memastikan field aud sesuai dengan cakupan aplikasi target
  • Aplikasi memvalidasi token dengan mengambil sertifikat yang diizinkan untuk verifikasi tanda tangan dari endpoint metadata bernama jwks_uri
  • Aktor ancaman dapat membuat token JWT, mengisi data seperti alamat email korban, lalu menandatanganinya dengan kunci yang dikompromikan yang terdaftar di endpoint sertifikat publik Azure Active Directory untuk memalsukan access token yang valid
  • Sebagai contoh, kid dari kunci yang dikompromikan adalah 1LTMzakihiRla_8z2BEJVXeWMqo
  • Menurut panduan Microsoft, agar token valid, claim iss harus berupa issuer MSA tenant yang ditentukan pada field issuer di endpoint jwks_uri, dan claim tid juga harus berupa ID MSA tenant 9188040d-6c67-4c5b-b112-36a304b66dad
  • Pada aplikasi AAD mixed-audience, selama menyamar sebagai akun pribadi, token yang ditandatangani oleh MSA tenant untuk akun Azure AD dapat dianggap valid
  • Detail validasi ID Token dapat dilihat pada panduan resmi Microsoft

Risiko yang tersisa setelah pencabutan kunci

  • Karena Microsoft telah mencabut kunci yang dikompromikan, aplikasi Azure Active Directory tidak lagi menerima token palsu yang ditandatangani dengan kunci tersebut sebagai token valid
  • Bahkan token dengan masa berlaku yang disetel panjang akan ditolak oleh aplikasi
  • Namun, jika sesi telah dibuat pada aplikasi pelanggan sebelum kunci dicabut, aktor ancaman mungkin telah memperoleh persistensi dengan memanfaatkan hak akses aplikasi
    • penerbitan access key khusus aplikasi
    • penyiapan backdoor khusus aplikasi
    • kasus ketika Storm-0558 memalsukan access token untuk OWA sebelum tindakan Microsoft dan kemudian memperoleh access token Exchange Online yang valid
  • Aplikasi yang menyimpan salinan kunci publik AAD sebelum sertifikat Microsoft dicabut juga dapat berisiko
    • Jika menggunakan penyimpanan sertifikat lokal atau cache kunci dan terus mempercayai kunci yang dikompromikan, aplikasi tetap rentan terhadap pemalsuan token
    • Microsoft merekomendasikan agar penyimpanan lokal dan cache sertifikat diperbarui setidaknya sekali sehari

Hal yang perlu diperiksa pengguna Azure

  • Untuk memeriksa apakah kunci yang dikompromikan digunakan di lingkungan Anda, perlu mengidentifikasi aplikasi yang berpotensi terdampak, mencari jejak penggunaan token palsu, dan memanfaatkan Indicators of Compromise yang dipublikasikan Microsoft untuk meninjau aktivitas IP terkait
  • Jika ada aplikasi yang meng-cache sertifikat publik OpenID Microsoft, cache tersebut harus diperbarui
  • Microsoft telah memasukkan validasi tambahan ke Azure SDK resmi untuk mencegah autentikasi akun organisasi dengan kunci MSA, dan pengguna paket terkait perlu memperbarui ke versi terbaru

Mengapa deteksinya sulit

  • Karena aktor ancaman dapat memalsukan access token secara offline, tidak ada jejak penerbitan token yang tertinggal di portal Azure
  • Agar pelanggan cloud dapat memverifikasi apakah kunci tersebut digunakan, mereka harus meninjau log per aplikasi dari aplikasi AAD yang mungkin terdampak
  • Menurut Wiz, target yang terdampak adalah aplikasi yang menggunakan endpoint berikut untuk memvalidasi access token Microsoft v2.0
  • Aplikasi AAD yang berpotensi terdampak dapat diidentifikasi dengan Azure CLI dengan mencari aplikasi yang signinaudience-nya adalah AzureADMultipleOrgs, AzureADandPersonalMicrosoftAccount, atau PersonalMicrosoftAccount
  • Aplikasi AAD yang mengarahkan ulang ke Azure WebApps juga dapat ditemukan dengan kueri CLI terpisah
  • Dengan mendekode access token yang digunakan di aplikasi dan memeriksa apakah field kid pada JOSE Header berisi string 1LTMzakihiRla_8z2BEJVXeWMqo, token yang ditandatangani dengan kunci yang dikompromikan dapat diidentifikasi
  • Menurut Microsoft, kunci yang dikompromikan tersebut dalam keadaan nonaktif, sehingga semua access token yang ditandatangani dengan kunci ini harus dianggap mencurigakan
  • Praktik logging per aplikasi belum terstandarisasi
    • Banyak pemilik aplikasi tidak memiliki log rinci yang mencakup access token mentah atau kunci penandatanganan
    • Karena itu, identifikasi dan investigasi insiden dapat menjadi sangat sulit
  • Pada aplikasi AAD multitenant yang tidak mendukung akun Microsoft pribadi, token palsu dapat dideteksi melalui claim iss dan tid
    • Upaya koneksi access token yang ditandatangani dengan MSA tenant ID 9188040d-6c67-4c5b-b112-36a304b66dad dapat menunjukkan penggunaan kunci yang dikompromikan
  • Jika HTTP Logs diaktifkan pada WebApp, Log Analytics dapat digunakan untuk memeriksa apakah alamat IP terkait aktor ancaman yang disebut dalam blog Microsoft pernah mengakses aplikasi

Pertanyaan yang tersisa dan kesimpulan praktis

  • Dampak keseluruhannya jauh lebih besar daripada yang pertama kali diketahui, dan dapat menimbulkan dampak jangka panjang terhadap kepercayaan cloud, khususnya pada lapisan identitas yang menjadi komponen dasar cloud
  • Aplikasi yang berpotensi rentan berjumlah jutaan, mencakup aplikasi Microsoft maupun aplikasi pelanggan, dan banyak di antaranya tidak memiliki log yang cukup untuk menentukan apakah telah terjadi kompromi
  • Pemilik aplikasi harus memprioritaskan pembaruan Azure SDK ke versi terbaru dan memastikan cache aplikasi telah diperbarui
  • Aplikasi yang cache-nya belum diperbarui mungkin masih rentan terhadap aktor ancaman yang menggunakan kunci yang dikompromikan
  • Ini masih merupakan insiden yang sedang diselidiki, dan dari informasi publik saja sulit untuk menjawab bagaimana aktor ancaman memperoleh kunci tersebut, kapan tepatnya itu terjadi, atau apakah ada kunci lain yang juga dikompromikan

Bacaan terkait

1 komentar

 
GN⁺ 2023-07-24
Komentar Hacker News

  • Kunci penandatanganan penyedia identitas adalah hal yang paling mendekati rahasia paling kuat di era modern. Misalnya, ini jauh lebih kuat daripada kunci TLS
    Dalam banyak hal, ini setara dengan kunci otoritas sertifikat (CA), dan organisasi yang memakai layanan Microsoft dan Azure perlu menilai dampak potensialnya
    Tampaknya orang-orang melupakan pepatah lama, “jangan menaruh semua telur dalam satu keranjang”

    • Kalau kunci-kunci ini memang sepenting itu, saya tidak paham kenapa mereka tidak diperlakukan dengan langkah pengamanan setingkat kunci CA
      Kenapa strukturnya membiarkan puluhan, ratusan, bahkan mungkin ribuan server berbagi segelintir kunci juga terasa janggal
      Di mana kunci root berbasis HSM, kunci perantara per pusat data, kunci penandatanganan sementara per server, dan daftar pencabutan sertifikat?
      Saya juga bertanya-tanya apakah token pembawa (bearer token) memang bisa diamankan dengan baik dari serangan seperti ini, atau kita harus kembali ke model di mana layanan asal diberi nonce untuk mengambil payload secara aman
    • Mungkin saat pepatah itu dibuat, ayam-ayam belum gencar mendorong integrasi fungsi sebanyak mungkin demi meningkatkan kualitas hidup
      Jadinya sekarang ada fitur-fitur yang hanya bisa dipakai kalau telurnya dikumpulkan di satu tempat
    • Perusahaan kami juga all-in ke Office 365, Teams, dan semuanya
      Saya sudah menyiapkan popcorn untuk saat semuanya runtuh, dan satu hal yang pasti, perusahaan tidak akan menyalahkan diri sendiri
    • Saya penasaran sebenarnya telur-telur itu harus dibagi seperti apa
      Apa maksudnya cuma pakai vendor lain yang kebetulan belum kehilangan kuncinya?
    • Saya tidak tahu secara realistis bagaimana cara menghindarinya
      Sekarang rasanya pada dasarnya cuma ada sekitar empat perusahaan big tech

  • Kesimpulannya adalah bahwa “dengan kunci MSA yang dibobol, penyerang mungkin bisa memalsukan token akses untuk berbagai jenis aplikasi Azure Active Directory”
    Ini mencakup SharePoint, Teams, OneDrive, aplikasi pelanggan yang mendukung “Masuk dengan Microsoft”, dan semua aplikasi yang mendukung autentikasi akun pribadi seperti aplikasi multi-tenant dalam kondisi tertentu
    Semoga kebetulan saja Microsoft baru-baru ini mengganti nama Azure AD menjadi Entra ID: https://devblogs.microsoft.com/identity/aad-rebrand/

    • Baru pertama kali saya dengar ini, dan bencana penamaan Microsoft selalu jadi hiburan tanpa akhir
      Saat memikirkan produk keamanan, saya tidak ingin teringat pada pemasok yang bukan menghalau pelaku jahat keluar, melainkan “membiarkan” orang masuk. entra berasal dari entrar, yaitu masuk/datang masuk, jadi ya /s
      Dalam bahasa Spanyol, itu bahkan terasa seperti bentuk perintah, seolah menyuruh seseorang, “Masuk!”

  • “Sertifikat untuk kunci publik lama diterbitkan pada 5 April 2016 dan kedaluwarsa pada 4 April 2021, dan sidik jarinya cocok dengan sidik jari kunci yang diposting Microsoft di blog terbarunya sebagai ‘sidik jari kunci penandatanganan yang diperoleh’”
    Kalau saya membacanya dengan benar, apakah itu berarti kuncinya terus dipakai meskipun sudah kedaluwarsa?

    • Saya tidak tahu bagaimana validasi masa berlaku bekerja pada sistem yang memakai kunci-kunci ini, tetapi secara umum ada dua cara menangani kunci/sertifikat kedaluwarsa dalam validasi berbasis kunci atau sertifikat
      Saya penasaran apakah ada yang tahu Microsoft memakai cara yang mana untuk kunci-kunci ini, di mana pun kunci itu digunakan
      Salah satunya adalah metode validasi TLS, ketika memeriksa rantai sertifikat di mana Cn ditandatangani oleh Cn-1, lalu seterusnya … hingga C0, kira-kira bekerja seperti ini
      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
      Tanggal kedaluwarsa setiap sertifikat diperiksa terhadap waktu saat ini
      Yang lainnya adalah metode yang dipakai untuk penandatanganan kode, kira-kira seperti ini
      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 diperiksa berdasarkan waktu saat ini, sedangkan sisanya diperiksa berdasarkan waktu saat sertifikat tepat di bawahnya ditandatangani
      Saya paham mengapa penandatanganan kode bekerja seperti itu. Pada dasarnya itu adalah notaris digital, jadi kalau notarisnya belakangan kehilangan kualifikasi dan lisensinya kedaluwarsa, dokumen yang sudah dinotarisasi sebelumnya tidak boleh tiba-tiba menjadi tidak ternotarisasi
    • Ketika Microsoft menjelaskan kepada pelanggan bahwa “Storm-0558 memperoleh kunci penandatanganan konsumen MSA yang tidak aktif”, seharusnya mereka mengatakan “Storm-0558 memperoleh kunci penandatanganan konsumen MSA yang kedaluwarsa”
      Lalu ketika mereka mengatakan “karena masalah validasi, kunci ini bisa dipercaya untuk penandatanganan token Azure AD”, seharusnya mereka mengatakan “karena sejumlah masalah validasi, kunci ini bisa dipercaya untuk penandatanganan token Azure AD”
      Dan ketika mereka mengatakan “para pelaku sangat memahami lingkungan target, kebijakan logging, persyaratan autentikasi, serta kebijakan dan prosedur”, mungkin lebih baik mereka mengatakan begini
      “Para pelaku mungkin sedang mencoba aksi cepat masuk lalu kabur yang nekat, dan sama sekali tidak peduli pada hal-hal remeh seperti kebijakan. Atau para pelaku mungkin tidak kompeten, sehingga bahkan tidak tahu bahwa Departemen Luar Negeri AS membayar kami jauh lebih mahal demi hak istimewa untuk mencatat peristiwa akses kotak surat secara rinci. Boeing sudah memberi petunjuk lewat MCAS. Selain itu, para pelaku tampaknya juga luput menyadari bahwa Chrome 92 terakhir diperbarui pada 2021, dan itu pilihan user-agent yang cukup buruk untuk menyerang sistem ICT kementerian AS yang seharusnya memakai browser terbaru. Mereka juga tampaknya hampir tidak tahu bagaimana kotak surat Departemen Luar Negeri AS diakses, dan terlihat membuat tebakan yang buruk dengan memakai pusat data publik acak di seluruh Eropa.”
      [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...

  • Kemungkinan besar kunci ini tidak berada di HSM
    Setiap kali melihat berita tentang kunci yang seharusnya ada di HSM tetapi ternyata dicuri, saya tetap saja terkejut

    • Kunci di HSM sulit dipakai oleh tim, dan meskipun ada HSM yang terhubung ke jaringan, integrasinya dengan toolchain yang sering dipakai developer tidak terlalu bagus
      Belakangan ini saya sempat membuat sendiri alat yang ideal untuk menjembatani kesenjangan antara toolchain modern dan enclave keamanan perangkat keras: https://keymux.com
    • Salah satu HSM yang populer, Thales Luna Network HSM, dapat melakukan 20.000 operasi ECC per detik [1]
      Bahkan dengan skala Azure AD, Microsoft mungkin tidak perlu terlalu banyak HSM untuk penandatanganan
      Namun HSM memang tidak terlalu mudah dikelola, jadi itu mungkin salah satu alasan mengapa penggunaannya tidak seluas yang seharusnya
      [1] https://cpl.thalesgroup.com/encryption/hardware-security-mod...
    • Ada dua skenario
      Pertama, Microsoft memuat kunci penandatanganan JWT ke memori saat digunakan, dan penyerang mungkin memperoleh kunci itu melalui injeksi kode atau akses ke image memori proses tersebut
      Kedua, Microsoft benar-benar menggunakan HSM, tetapi harus mendistribusikan kunci tersebut secara geografis, dan penyerang mungkin mendapat akses ke kunci dalam proses itu
      Yang pertama lebih mungkin, tetapi yang kedua juga tidak bisa dikesampingkan
    • Apa itu HSM?

  • Haruskah FAANG dilegalkan untuk melakukan perang siber/aktivitas spionase satu sama lain?
    Dengan begitu, alih-alih mengandalkan ambiguitas, mereka setidaknya harus mencapai tingkat minimum praktik terbaik keamanan

    • Mereka semua sudah menjalankan program bug bounty
      Selama tidak menimbulkan kerusakan nyata atau mengunduh data pelanggan yang nyata, dan temuan yang didapat dipublikasikan, itu sudah legal

  • Sepertinya Satya harus jauh lebih sering menyebut AI di panggilan laporan keuangan berikutnya kalau ingin menutupi kekacauan ini

  • Sulit membayangkan pelanggaran yang lebih buruk daripada kekuatan asing masuk ke akun email perwakilan kita yang berurusan dengan kekuatan tersebut
    Saya berharap pemerintah AS benar-benar meninjau ulang kebijakan-kebijakan yang memindahkan komputasi ke penyedia cloud besar

  • “Terakhir, kami berterima kasih kepada tim Microsoft yang bekerja sangat erat dengan kami dan membantu memastikan tulisan ini akurat secara teknis”
    Bagaimana keputusan untuk merilis kabar ini pada hari Jumat dibuat?

    • Melihat perkembangan setelah pembuangan berita Jumat musim panas itu, bahkan sampai Senin malam pun tetap sepi
      Saya menyerah setelah melihat 5 halaman pertama hasil pencarian “microsoft” di Google News, dan total hanya ada 2 penyebutan terkait
      Sebagian besar adalah “berita” berupa artikel promosi, promosi produk, dan kebisingan soal harga saham

  • “Dampak penuh dari insiden ini jauh lebih besar daripada yang awalnya kami pahami. Insiden ini akan berdampak jangka panjang pada kepercayaan terhadap cloud dan komponen inti yang menopangnya, terutama lapisan identitas yang menjadi fondasi dasar dari semua yang kita lakukan di cloud. Kita harus belajar dan memperbaiki diri dari sini”
    Mungkin kita bisa mulai dengan tidak menaruh semuanya di cloud terlebih dahulu
    Masalahnya pada akhirnya bukan cloud itu sendiri, melainkan kapitalisme ekonomi yang rusak yang menghasilkan monopoli, atau kartel segelintir perusahaan besar
    Bagi perusahaan kecil berekor panjang, memakai produk dan layanan perusahaan besar sebenarnya tidak rasional, tetapi jika pasar terus memberi lebih banyak kekuatan kepada pemenang, pada akhirnya akan muncul perusahaan yang terlalu besar untuk gagal
    Perusahaan besar seperti ini, hanya dengan satu kesalahan atau satu kali terpeleset saja, punya permukaan serangan yang terlalu luas. Insiden seperti ini bukan soal apakah akan terjadi, melainkan kapan akan terjadi
    Dalam jangka panjang, agar masyarakat bisa bertahan, layanan federatif adalah jawabannya meski harus mengorbankan sebagian kenyamanan

    • Di bidang komputer, penyebabnya umumnya lebih dekat ke sifat dasar manusia: “tidak ada yang dipecat karena membeli IBM”
      Para pemimpin bisnis bukanlah kutu buku teknologi yang bermimpi tentang layanan federatif yang lebih besar dan lebih baik
      TI biasanya merupakan biaya besar, baik di laporan laba rugi maupun dalam waktu dan penderitaan yang dihabiskan untuk mempelajari, memutuskan, dan bergulat dengan masalah komputer
      Sebagai analogi, jika cuaca meragukan tetapi Anda memutuskan terbang dengan Microsoft Airlines, saat penerbangan dibatalkan dan Anda terlambat, akan ada banyak orang yang mengalami hal yang sama dan bersimpati
      Sebaliknya, jika Anda memilih jalur sendiri dengan naik kereta, beban memahami jadwal kereta dan stasiun sepenuhnya jatuh ke Anda. Karena “pesawat adalah cara yang semua orang pahami”
      Dan jika Microsoft Air tiba dengan selamat tetapi kereta Anda bermasalah, Anda akan menonjol sendirian seperti tumpukan mengepul di lantai dapur

  • Ringkasannya sangat bagus dan menakutkan
    Meski topiknya rumit, penjelasannya mudah dicerna