- Sự cố Storm-0558 được biết đến là vụ xâm phạm Exchange Online và Outlook.com, nhưng phân tích cho thấy khóa ký MSA bị lộ cũng có thể bị lạm dụng để giả mạo token OpenID v2.0 của các ứng dụng Azure AD
- Phạm vi có thể bị ảnh hưởng mở rộng tới các ứng dụng Microsoft dùng xác thực tài khoản Microsoft cá nhân, các ứng dụng khách hàng hỗ trợ “Login with Microsoft”, và cả ứng dụng đa tenant trong một số điều kiện nhất định
- Khóa công khai liên quan đã nằm trong danh sách khóa OpenID của Microsoft ít nhất từ năm 2016, được thay vào khoảng từ ngày 27/6/2023 đến 5/7/2023, và trùng với acquired signing key cùng thumbprint mà Microsoft công bố
- Microsoft đã thu hồi khóa nên có thể chặn các token giả mạo mới, nhưng các phiên được tạo trước khi khóa bị thu hồi hoặc các ứng dụng vẫn tiếp tục tin vào bộ nhớ đệm khóa công khai cũ cần được kiểm tra riêng
- Token giả mạo có thể được tạo ngoại tuyến nên không để lại dấu vết phát hành trong Azure Portal; nếu không có raw token hoặc log
kidthì rất khó xác nhận đã bị xâm phạm
Phạm vi ảnh hưởng vượt ra ngoài Exchange Online
- Microsoft và CISA đã công bố một sự cố bảo mật ảnh hưởng đến nhiều khách hàng của Exchange Online và Outlook.com
- Theo Microsoft, Storm-0558, bị quy là tác nhân đe dọa có liên hệ với Trung Quốc, đã lấy được khóa MSA riêng tư và giả mạo access token cho Outlook Web Access và Outlook.com
- Tác nhân đe dọa được cho là cũng đã khai thác đồng thời hai vấn đề bảo mật trong quy trình xác thực token của Microsoft
- Theo phân tích của Wiz Research, khóa bị xâm phạm không chỉ giới hạn ở Outlook.com và Exchange Online mà còn có thể được dùng để giả mạo access token cho nhiều ứng dụng Azure Active Directory
- Ứng dụng hỗ trợ xác thực bằng tài khoản cá nhân
- Ứng dụng do Microsoft quản lý như SharePoint, Teams, OneDrive
- Ứng dụng khách hàng hỗ trợ “Login with Microsoft”
- Ứng dụng đa tenant trong những điều kiện nhất định
Khóa bị xâm phạm được xác nhận như thế nào
- Ngày 11/7/2023, Microsoft công bố rằng kẻ tấn công đã lấy được MSA consumer signing key, cho phép giả mạo access token cho tài khoản Exchange Online và Outlook.com
- Wiz đã xem xét tài liệu chính thức về xác thực token OpenID của Microsoft để xác định các khóa có thể ký token cho tài khoản Microsoft và các ứng dụng Azure Active Directory
- Khi đó, các ứng dụng Azure tài khoản cá nhân v2.0 phụ thuộc vào 8 khóa công khai, còn các ứng dụng Azure đa tenant v2.0 có bật tài khoản Microsoft phụ thuộc vào 7 khóa công khai
- Kiểm tra qua Internet Archive Wayback Machine cho thấy một khóa công khai có mặt trong danh sách ít nhất từ năm 2016 đã được thay vào khoảng 27/6/2023 đến 5/7/2023
- Mốc thời gian này trùng với thời điểm thay khóa bị lộ mà Microsoft nêu trong bài blog
- Chứng chỉ khóa công khai cũ được cấp ngày 5/4/2016 và hết hạn ngày 4/4/2021
- thumbprint trùng với giá trị mà Microsoft công bố trong blog mới nhất là “Thumbprint of acquired signing key”
- Phân tích cho thấy khóa mà Storm-0558 lấy được là khóa riêng cho MSA tenant của Microsoft, nhưng cũng có thể dùng để ký token OpenID v2.0 cho nhiều ứng dụng Azure Active Directory
Vì sao việc lộ khóa ký OpenID lại nguy hiểm
- Azure identity platform công bố các danh sách khóa công khai đáng tin cậy khác nhau theo từng loại ứng dụng và dùng chúng để xác minh tính toàn vẹn của token do Azure Active Directory phát hành
- Ứng dụng AAD xác minh chữ ký token bằng danh sách khóa công khai phù hợp rồi mới quyết định có tin cậy token hay không
- Nếu một khóa trong danh sách đó bị lộ, các ứng dụng xác minh bằng danh sách này có thể chấp nhận access token giả mạo là hợp lệ trong một số điều kiện
- Theo suy luận của Wiz từ blog Microsoft, Storm-0558 dường như đã truy cập được một trong nhiều khóa dùng cho ký và xác minh access token của AAD
- Khóa bị lộ được tin cậy để ký OpenID v2.0 access token cho các ứng dụng AAD dùng tài khoản cá nhân và mixed-audience, tức ứng dụng đa tenant hoặc nhắm đến tài khoản cá nhân
- Kết quả là, về mặt lý thuyết, Storm-0558 có thể giả mạo token xác thực thành người dùng bất kỳ trên các ứng dụng bị ảnh hưởng vốn tin cậy chứng chỉ Microsoft OpenID v2.0 mixed audience và tài khoản cá nhân
- Có thể xem khóa ký của identity provider là bí mật còn mạnh hơn cả khóa TLS
- Ngay cả khi khóa TLS bị lộ, kẻ tấn công vẫn phải giả danh đúng máy chủ để mở rộng tác động
- Khóa identity provider có thể được dùng để giả mạo token, từ đó truy cập email, dịch vụ tệp và tài khoản đám mây chỉ trong một bước
- Rủi ro tương tự không chỉ áp dụng với Microsoft mà còn với các identity provider lớn như Google, Facebook, Okta nếu khóa ký của họ bị lộ
Các loại ứng dụng bị ảnh hưởng
- Phạm vi bị ảnh hưởng chỉ giới hạn ở các ứng dụng Azure Active Directory dùng OpenID v2.0 của Microsoft
- Ứng dụng v1.0 không bị ảnh hưởng vì không dùng khóa bị lộ để xác thực token
-
Ứng dụng chỉ hỗ trợ tài khoản Microsoft cá nhân
- Các ứng dụng Azure Active Directory dùng giao thức Microsoft v2.0 và hỗ trợ “Personal Microsoft accounts only” đều bị ảnh hưởng
- Bao gồm các ứng dụng do Microsoft quản lý như Outlook, SharePoint, OneDrive, Teams và các ứng dụng khách hàng hỗ trợ xác thực bằng Microsoft Account
-
Ứng dụng hỗ trợ cả đa tenant và tài khoản Microsoft cá nhân
- Các ứng dụng Azure Active Directory hỗ trợ “mixed audience” và dùng giao thức Microsoft v2.0 cũng bị ảnh hưởng
- Tác nhân đe dọa có thể đã giả mạo access token hợp lệ để mạo danh người dùng ứng dụng đăng nhập bằng tài khoản Microsoft cá nhân
- Microsoft đã đưa vào một phần mở rộng giao thức OpenID nhằm hạn chế khả năng khóa MSA mạo danh tài khoản tổ chức
- Nhà phát triển phải xác minh bằng cách so sánh issuer claim với trường issuer trong danh sách khóa công khai OpenID
- Cơ chế này nhằm ngăn khóa MSA ký access token có issuer không phải MSA tenant
- Đây là phần mở rộng riêng của Microsoft và trách nhiệm triển khai thuộc về chủ sở hữu ứng dụng
- Wiz cho rằng nhiều ứng dụng có thể chưa có quy trình xác minh này, nên vẫn có khả năng bị mạo danh tài khoản tổ chức
- Theo blog của Microsoft, OWA cũng bị ảnh hưởng bởi một vấn đề tương tự
- Ngày 12/7, Microsoft đã thêm tính năng xác minh này vào Azure SDK chính thức
-
Ứng dụng chỉ hỗ trợ đa tenant
- Nếu ứng dụng đa tenant được cấu hình để phụ thuộc vào endpoint khóa v2.0 common thay vì “Organizations”, thì cũng bị ảnh hưởng
- Cấu hình như vậy nên được xem là cấu hình sai
- Tài liệu chính thức của Microsoft không nói rõ khi nào cần dùng endpoint “common”, nên một số ứng dụng đa tenant cũng có thể bị ảnh hưởng
-
Ứng dụng single-tenant
- Ứng dụng single-tenant chỉ hỗ trợ “Accounts in this organizational directory only” không bị ảnh hưởng
Điều kiện để giả mạo token thành công
- Khi xác thực token OpenID, nhà phát triển ứng dụng phải kiểm tra xem token có được ký bằng khóa riêng hợp lệ cho đúng phạm vi dự kiến hay không, đồng thời xác minh trường
audcó khớp với phạm vi của ứng dụng đích hay không - Ứng dụng lấy các chứng chỉ được phép dùng để xác thực chữ ký token từ endpoint metadata có tên
jwks_uri - Tác nhân đe dọa có thể tạo token JWT, điền dữ liệu như địa chỉ email của nạn nhân, rồi ký bằng khóa bị lộ đã đăng ký tại endpoint chứng chỉ công khai của Azure Active Directory để giả mạo access token hợp lệ
- Ví dụ,
kidcủa khóa bị lộ được nhắc đến là1LTMzakihiRla_8z2BEJVXeWMqo - Theo hướng dẫn của Microsoft, để token hợp lệ thì
issclaim phải là MSA tenant issuer được chỉ định trong trường issuer của endpointjwks_uri, vàtidclaim cũng phải là MSA tenant ID9188040d-6c67-4c5b-b112-36a304b66dad - Trong các ứng dụng AAD mixed-audience, miễn là đang mạo danh tài khoản cá nhân, token được khóa MSA ký cho tài khoản Azure AD có thể vẫn bị xem là hợp lệ
- Chi tiết về việc xác thực ID Token có thể xem trong hướng dẫn chính thức của Microsoft
Rủi ro còn lại sau khi thu hồi khóa
- Do Microsoft đã thu hồi khóa bị lộ, các ứng dụng Azure Active Directory hiện không còn chấp nhận token giả mạo ký bằng khóa đó là hợp lệ nữa
- Ngay cả những token có thời gian hết hạn được đặt dài cũng sẽ bị ứng dụng từ chối
- Tuy nhiên, nếu phiên làm việc đã được tạo trong ứng dụng khách hàng trước khi khóa bị thu hồi, tác nhân đe dọa có thể đã dùng quyền ứng dụng để thiết lập duy trì hiện diện
- Phát hành khóa truy cập riêng theo từng ứng dụng
- Thiết lập backdoor riêng theo từng ứng dụng
- Trường hợp Storm-0558 đã giả mạo access token cho OWA trước khi Microsoft xử lý để lấy access token Exchange Online hợp lệ
- Các ứng dụng lưu bản sao khóa công khai AAD trước khi Microsoft thu hồi chứng chỉ cũng có thể gặp rủi ro
- Nếu dùng kho chứng chỉ cục bộ hoặc khóa đã cache và vẫn tiếp tục tin cậy khóa bị lộ, chúng sẽ dễ bị giả mạo token
- Microsoft khuyến nghị làm mới kho cục bộ và cache chứng chỉ ít nhất mỗi ngày một lần
Người dùng Azure cần kiểm tra gì
- Để xác minh môi trường có dùng khóa bị lộ hay không, cần xác định các ứng dụng có khả năng bị ảnh hưởng, tìm dấu vết sử dụng token giả mạo, và dùng Indicators of Compromise do Microsoft công bố để kiểm tra hoạt động IP liên quan
- Nếu có ứng dụng cache chứng chỉ công khai OpenID của Microsoft thì cần làm mới cache
- Microsoft đã thêm kiểm tra bổ sung vào Azure SDK chính thức để ngăn việc dùng khóa MSA xác thực tài khoản tổ chức; người dùng gói này nên cập nhật lên phiên bản mới nhất
Vì sao khó phát hiện
- Tác nhân đe dọa có thể giả mạo access token ngoại tuyến nên Azure Portal không lưu lại dấu vết phát hành token
- Để xác định khóa có bị dùng hay không, khách hàng đám mây phải xem log riêng của từng ứng dụng AAD có thể bị ảnh hưởng
- Theo Wiz, các ứng dụng bị ảnh hưởng là những ứng dụng dùng các endpoint sau để xác thực access token Microsoft v2.0
- Có thể dùng Azure CLI để xác định các ứng dụng AAD có khả năng bị ảnh hưởng bằng cách truy vấn các app có
signinaudiencelàAzureADMultipleOrgs,AzureADandPersonalMicrosoftAccount,PersonalMicrosoftAccount - Các ứng dụng AAD chuyển hướng tới Azure WebApps cũng có thể được tìm bằng truy vấn CLI riêng
- Nếu giải mã access token đã dùng trong ứng dụng và kiểm tra trường
kidtrong JOSE Header có chuỗi1LTMzakihiRla_8z2BEJVXeWMqohay không, có thể tìm ra token được ký bằng khóa bị lộ - Theo Microsoft, khóa bị lộ đang ở trạng thái không hoạt động, nên mọi access token được ký bằng khóa này đều cần bị xem là đáng ngờ
- Không có thực hành chuẩn hóa đầy đủ cho logging theo từng ứng dụng
- Nhiều chủ sở hữu ứng dụng không có log chi tiết chứa raw access token hoặc khóa ký
- Vì vậy việc nhận diện và điều tra sự kiện có thể cực kỳ khó khăn
- Với các ứng dụng AAD chỉ đa tenant, không hỗ trợ tài khoản Microsoft cá nhân, có thể phát hiện token giả mạo thông qua
issvàtidclaim- Các lần thử liên kết access token được ký với MSA tenant ID
9188040d-6c67-4c5b-b112-36a304b66dadcó thể cho thấy khóa bị lộ đã bị sử dụng
- Các lần thử liên kết access token được ký với MSA tenant ID
- Nếu WebApp đã bật HTTP Logs, có thể dùng Log Analytics để kiểm tra xem các địa chỉ IP liên quan tác nhân đe dọa trong blog Microsoft có truy cập ứng dụng hay không
Câu hỏi còn lại và kết luận thực tế
- Tác động tổng thể lớn hơn rất nhiều so với thông tin ban đầu và có thể để lại ảnh hưởng dài hạn lên niềm tin vào đám mây, đặc biệt là lớp identity vốn là thành phần nền tảng của cloud
- Các ứng dụng từng có thể dễ bị tổn thương bao gồm cả ứng dụng Microsoft lẫn ứng dụng khách hàng, lên tới hàng triệu, và nhiều ứng dụng không có đủ log để xác định có bị xâm phạm hay không
- Chủ sở hữu ứng dụng nên ưu tiên cập nhật Azure SDK lên phiên bản mới nhất và xác minh rằng cache của ứng dụng đã được làm mới
- Các ứng dụng chưa cập nhật cache có thể vẫn còn dễ bị tác nhân đe dọa lợi dụng khóa bị lộ
- Vụ việc vẫn đang được điều tra; chỉ với thông tin công khai hiện có, rất khó trả lời chính xác tác nhân đe dọa đã lấy khóa bằng cách nào, thời điểm chính xác là khi nào, và liệu còn khóa nào khác cũng đã bị xâm phạm hay không
1 bình luận
Ý kiến trên Hacker News
Khóa ký của nhà cung cấp danh tính gần như là loại bí mật mạnh nhất trong thời hiện đại. Ví dụ, nó mạnh hơn khóa TLS rất nhiều
Xét trên nhiều phương diện, nó ngang tầm với khóa của cơ quan chứng thực (CA), và các tổ chức sử dụng dịch vụ Microsoft và Azure cần đánh giá tác động tiềm tàng
Có vẻ mọi người đã quên mất câu nói xưa rằng “đừng bỏ tất cả trứng vào cùng một giỏ”
Tôi cũng thắc mắc vì sao cấu trúc lại là hàng chục, hàng trăm, thậm chí hàng nghìn máy chủ cùng chia sẻ chỉ một số ít khóa
Khóa gốc dựa trên HSM, khóa trung gian theo từng trung tâm dữ liệu, khóa ký tạm thời theo từng máy chủ, danh sách thu hồi chứng chỉ ở đâu?
Tôi còn băn khoăn liệu có thực sự bảo vệ an toàn được bearer token trong các cuộc tấn công kiểu này hay không, hay phải quay về cách đưa số ngẫu nhiên cho dịch vụ gốc để lấy payload một cách an toàn
Thành ra đã xuất hiện những tính năng chỉ dùng được khi gom trứng về một chỗ
Tôi đã chuẩn bị sẵn bắp rang để xem lúc mọi thứ sụp đổ, và điều chắc chắn là công ty sẽ không tự nhận lỗi về mình
Không rõ có phải ý là cứ dùng nhà cung cấp khác chưa làm mất khóa hay không
Giờ có vẻ trên thực tế chỉ còn khoảng 4 đại gia công nghệ
Người ta kết luận rằng “khóa MSA bị xâm phạm có thể đã cho phép kẻ tấn công giả mạo access token cho nhiều loại ứng dụng Azure Active Directory”
Điều này bao gồm SharePoint, Teams, OneDrive, các ứng dụng khách hàng hỗ trợ “Đăng nhập bằng Microsoft”, và mọi ứng dụng hỗ trợ xác thực tài khoản cá nhân như các ứng dụng đa tenant trong một số điều kiện nhất định
Hy vọng việc Microsoft gần đây đổi Azure AD thành Entra ID chỉ là trùng hợp: https://devblogs.microsoft.com/identity/aad-rebrand/
Khi nghĩ đến sản phẩm bảo mật, tôi không muốn lại liên tưởng đến một nhà cung cấp “cho người ta vào trong” thay vì chặn tác nhân độc hại ở bên ngoài. entra đến từ entrar, tức là đi vào/bước vào, nên là vậy /s
Trong tiếng Tây Ban Nha, nó còn là mệnh lệnh thức, nên thậm chí còn cho cảm giác như đang bảo ai đó “vào đi!”
“Chứng chỉ của khóa công khai hiện có được cấp vào ngày 5 tháng 4 năm 2016, hết hạn vào ngày 4 tháng 4 năm 2021, và dấu vân tay của nó khớp với dấu vân tay của khóa mà Microsoft đã đăng là ‘dấu vân tay của khóa ký đã bị lấy được’ trong bài blog mới nhất”
Nếu tôi đọc đúng thì điều đó có nghĩa là khóa đã hết hạn nhưng vẫn tiếp tục được dùng?
Tôi tò mò liệu có ai biết Microsoft đã dùng các khóa này ở đâu và theo cách nào
Một cách là kiểu xác thực TLS, khi kiểm tra chuỗi chứng chỉ mà Cn được Cn-1 ký, rồi tiếp tục … đến C0, thì đại khái hoạt động như sau
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
Ngày hết hạn của từng chứng chỉ được kiểm tra dựa trên thời điểm hiện tại
Cách còn lại là kiểu dùng cho ký mã, đại khái như sau
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 được kiểm tra theo thời điểm hiện tại, còn các chứng chỉ còn lại được kiểm tra theo thời điểm chứng chỉ ngay bên dưới đã được ký
Tôi hiểu vì sao ký mã lại hoạt động như vậy. Về bản chất nó là công chứng số, nên việc công chứng viên sau này mất tư cách và giấy phép hết hạn không thể khiến tài liệu đã được công chứng trở thành chưa được công chứng
Và khi họ nói “do một vấn đề xác thực, khóa này có thể được tin cậy để ký token Azure AD”, đáng ra họ nên nói “do nhiều vấn đề xác thực, khóa này có thể được tin cậy để ký token Azure AD”
Và khi họ nói “các tác nhân hiểu rõ môi trường mục tiêu, chính sách ghi log, yêu cầu xác thực, cũng như chính sách và quy trình”, có lẽ họ nên nói thế này mới đúng hơn
“Các tác nhân có thể chỉ nhắm đến một cú đánh nhanh táo bạo và chẳng bận tâm một giây nào đến mấy thứ linh tinh như chính sách. Hoặc cũng có thể các tác nhân còn non tay, nên thậm chí không biết Bộ Ngoại giao Mỹ đang trả cho chúng tôi nhiều tiền hơn hẳn để có đặc quyền ghi log chi tiết các sự kiện truy cập hộp thư. Boeing với MCAS coi như đã gợi ý rồi. Ngoài ra, các tác nhân dường như cũng bỏ qua việc Chrome 92 được cập nhật lần cuối vào năm 2021, và đây là một lựa chọn user-agent khá tệ để tấn công hệ thống ICT của một cơ quan chính phủ Mỹ, nơi đáng ra phải dùng trình duyệt mới nhất. Họ cũng có vẻ gần như không biết gì về cách truy cập hộp thư của Bộ Ngoại giao Mỹ, và đã đưa ra những suy đoán tệ hại bằng cách dùng các trung tâm dữ liệu công khai ngẫu nhiên khắp châu Âu.”
[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...
Có vẻ rất khó khả năng khóa này nằm trong HSM
Mỗi lần thấy tin một khóa đáng lẽ phải nằm trong HSM lại bị đánh cắp, tôi vẫn luôn ngạc nhiên
Gần đây tôi đã có cơ hội tự xây dựng công cụ lý tưởng để lấp khoảng trống giữa toolchain hiện đại và hardware security enclave: https://keymux.com
Ngay cả xét ở quy mô Azure AD, Microsoft có thể cũng không cần quá nhiều HSM chỉ để phục vụ việc ký
Tuy vậy, HSM không hẳn dễ quản lý, nên đó có thể là một trong những lý do chúng chưa được dùng rộng rãi như cần thiết
[1] https://cpl.thalesgroup.com/encryption/hardware-security-mod...
Thứ nhất, Microsoft đã nạp khóa ký JWT vào bộ nhớ để sử dụng, và kẻ tấn công có thể đã lấy được khóa bằng cách chèn mã hoặc truy cập ảnh bộ nhớ của tiến trình đó
Thứ hai, Microsoft thực sự có dùng HSM, nhưng phải phân tán khóa theo địa lý, và kẻ tấn công có thể đã truy cập được khóa trong quá trình đó
Kịch bản đầu có khả năng cao hơn, nhưng kịch bản thứ hai cũng không thể loại trừ
Chẳng phải nên hợp pháp hóa việc các FAANG tiến hành chiến tranh mạng/gián điệp nhắm vào nhau sao?
Như vậy ít nhất họ có lẽ sẽ phải đạt đến mức thực hành bảo mật tối thiểu, thay vì cứ dựa vào sự mơ hồ
Chừng nào bạn không gây ra thiệt hại thực tế hoặc tải xuống dữ liệu khách hàng thật, rồi công bố những gì mình phát hiện, thì điều đó vốn đã hợp pháp
Có lẽ Satya sẽ phải nói từ AI nhiều hơn nữa trong buổi công bố kết quả kinh doanh tiếp theo thì mới che lấp được mớ hỗn độn này
Thật khó tưởng tượng ra một vụ xâm nhập nào tệ hơn việc một thế lực nước ngoài truy cập được vào tài khoản email của các đại diện của chúng ta đang đối đầu với chính thế lực đó
Tôi hy vọng chính phủ Mỹ sẽ nghiêm túc xem xét lại các chính sách chuyển hạ tầng điện toán sang những nhà cung cấp đám mây lớn hàng đầu
“Cuối cùng, chúng tôi xin cảm ơn đội ngũ Microsoft đã phối hợp chặt chẽ với chúng tôi về bài viết này và giúp xác nhận tính chính xác về mặt kỹ thuật”
Không rõ họ đã quyết định thế nào để công bố tin này vào thứ Sáu?
Tôi tìm “microsoft” trên Google News, xem 5 trang đầu rồi bỏ cuộc, tổng cộng chỉ có 2 chỗ nhắc đến việc này
Phần lớn là những “tin tức” kiểu bài PR, quảng bá sản phẩm, hoặc tiếng ồn liên quan đến giá cổ phiếu
“Tác động toàn diện của sự cố này lớn hơn rất nhiều so với những gì chúng tôi hiểu ban đầu. Sự cố này sẽ để lại ảnh hưởng lâu dài đến niềm tin vào đám mây và các thành phần cốt lõi nâng đỡ nó, trước hết là tầng định danh, lớp nền tảng cơ bản cho mọi việc chúng ta làm trên đám mây. Chúng ta cần học hỏi và cải thiện từ đây”
Có lẽ trước hết nên bắt đầu từ việc đừng đưa mọi thứ lên đám mây
Vấn đề rốt cuộc không hẳn nằm ở bản thân đám mây, mà ở một nền kinh tế tư bản méo mó dẫn tới độc quyền, hoặc cartel của một số ít tập đoàn lớn
Với các công ty nhỏ ở phần đuôi dài, việc dùng sản phẩm và dịch vụ của các tập đoàn lớn vốn không hợp lý, nhưng nếu tiếp tục trao thêm quyền lực cho kẻ thắng trên thị trường thì cuối cùng sẽ sinh ra những công ty quá lớn để sụp đổ
Những tập đoàn như vậy chỉ cần một sai sót, một cú trượt chân là bề mặt tấn công đã trở nên quá lớn. Những sự cố kiểu này không còn là chuyện có xảy ra hay không, mà là khi nào sẽ xảy ra
Về lâu dài, nếu xã hội muốn tồn tại thì dù phải hy sinh một phần sự tiện lợi, các dịch vụ liên hợp mới là câu trả lời
Các lãnh đạo doanh nghiệp không phải là những tay mê công nghệ mơ về các dịch vụ liên hợp ngày càng lớn hơn và tốt hơn
CNTT thường là một khoản chi lớn, cả trên báo cáo lãi lỗ lẫn ở thời gian và nỗi khổ phải bỏ ra để học, quyết định và vật lộn với các vấn đề máy tính
Ví von thì nếu thời tiết có vẻ bất ổn mà bạn vẫn chọn bay với Microsoft Airlines, khi chuyến bị hủy và bạn đến muộn, sẽ có rất nhiều người đồng cảnh ngộ và thông cảm với bạn
Ngược lại, nếu bạn chọn đi tuyến riêng bằng tàu hỏa, gánh nặng tìm hiểu lịch tàu, nhà ga và mọi thứ sẽ đổ hết lên đầu bạn. Vì “máy bay là cách ai cũng biết”
Và nếu Microsoft Air hạ cánh an toàn còn tàu của bạn gặp sự cố, bạn sẽ lòi ra một mình như một đống bốc khói trên sàn bếp
Bài tổng kết rất xuất sắc và cũng đáng sợ
Dù là một chủ đề phức tạp, nó vẫn được giải thích rất dễ tiếp thu