Hành trình 20 năm cùng AWS: Từ người dùng tiên phong đến AWS Hero

Hành trình 20 năm cùng AWS: Từ người dùng tiên phong đến AWS Hero

Gần đây, tôi đã nhìn lại chặng đường 20 năm gắn bó với Amazon Web Services (AWS). Điều thú vị là, dù không phải là nhân viên của Amazon, nhưng công việc này dường như chưa bao giờ không phải là trách nhiệm của tôi. Từ những ngày đầu tiên chập chững sử dụng dịch vụ đám mây cho đến việc trở thành một AWS Hero, đây là câu chuyện về mối quan hệ cộng sinh giữa một kỹ sư phần mềm độc lập và gã khổng lồ đám mây.

Những ngày đầu tiên và vấn đề bảo mật

Tôi tạo tài khoản AWS vào năm 2006 vì quan tâm đến Amazon S3, nhưng thú vị là dịch vụ này lúc đó chưa sẵn có ngay lập tức. Trong những ngày đầu của AWS, bạn phải yêu cầu cụ thể để từng dịch vụ mới được kích hoạt cho tài khoản của mình. Tài khoản mới của tôi được bật mặc định hai dịch vụ: Amazon Simple Queue Service (SQS) — được nhiều người biết đến là "dịch vụ AWS đầu tiên", và Amazon E-Commerce Service (ECS) — một API cho phép tiếp cận danh mục sản phẩm của Amazon.com. Thực tế, ECS mới là dịch vụ AWS đầu tiên, nhưng nó đã bị xóa sạch khỏi lịch sử AWS.

Là một người từng giữ vị trí FreeBSD Security Officer, mối quan tâm đầu tiên của tôi với bất cứ thứ gì trên đám mây luôn là bảo mật. Tôi nhanh chóng nhận ra một vấn đề: Các yêu cầu (request) của AWS đều được ký bằng API keys để cung cấp xác thực và bảo toàn tính toàn vẹn, nhưng lại không có chữ ký tương ứng trên các phản hồi (response) từ AWS. Vào thời điểm đó, việc gửi yêu cầu qua HTTP thay vì HTTPS vẫn rất phổ biến, do đó nguy cơ phản hồi bị giả mạo là rất thực tế. Mặc dù ngày nay với TLS vấn đề này ít cấp bách hơn, nhưng tôi vẫn tin rằng việc ký kết đầu cuối (end-to-end signing) luôn tốt hơn bảo mật tầng truyền tải.

Đưa FreeBSD lên EC2: Một hành trình đầy chông gai

Khi Amazon EC2 ra mắt, mục tiêu của tôi rất rõ ràng: Tôi muốn chạy FreeBSD trên đó! Sau khi liên hệ với Jeff Barr, tôi đã được kết nối với đội ngũ nội bộ của Amazon và ký bản NDA đầu tiên vào năm 2007.

Tuy nhiên, hành trình này không hề dễ dàng. EC2 khi đó chạy trên Xen 3.0, có một lỗi ngăn không hỗ trợ bảng trang đệ quy (recursive page tables) — một tối ưu hóa mà mã máy ảo (VM) của FreeBSD sử dụng. Vấn đề đã được sửa trong Xen 3.1, nhưng việc nâng cấp EC2 sẽ làm hỏng các AMI hiện có. Amazon đã chọn cách giữ Xen 3.0 để hỗ trợ khách hàng hiện tại, khiến FreeBSD không thể chạy được trong một thời gian dài.

Phải đến khi loại instance t1.micro ra mắt vào tháng 9 năm 2010, chạy trên Xen 3.4.2 — phiên bản đã sửa lỗi bảng trang — tôi mới có thể SSH vào một instance FreeBSD/EC2 thành công. Sau đó, nhờ sự hỗ trợ của HVM (Hardware Virtual Machine), FreeBSD cuối cùng đã có thể chạy trên tất cả các loại instance 64-bit vào năm 2014.

Đóng góp cho bảo mật và kiến trúc AWS

Trong suốt quá trình đó, tôi đã đóng góp nhiều ý kiến về bảo mật và kiến trúc:

• Kiểm toán Xen: Vào năm 2007, tôi đã khuyến khích Amazon thuê một chuyên gia để kiểm toán mã nguồn của Xen và giới thiệu Tavis Ormandy. Sau đó năm đó, Tavis đã được ghi nhận là người đã báo cáo hai lỗ hổng trong Xen.
• SimpleDB và Chữ ký: Khi phát triển dịch vụ sao lưu Tarsnap sử dụng SimpleDB, tôi phát hiện sơ đồ chuẩn hóa (canonicalization) trong việc ký yêu cầu có sự va chạm (collision). Tôi đã báo cáo vấn đề này và Amazon đã làm việc tốt khi xử lý, dẫn đến việc ra mắt "signature version 2".
• IAM và Khóa truy cập: Tôi đã tranh luận về nhu cầu các khóa truy cập bị hạn chế (constrained access keys) thay vì khóa cấp tài khoản toàn diện. Điều này dẫn đến sự ra đời của IAM (Identity and Access Management) và sau này là SigV4 sử dụng các khóa dẫn xuất.
• IMDS và Vụ Capital One: Vào năm 2016, tôi đã viết blog cảnh báo về tính nguy hiểm của việc lộ thông tin xác thực qua IMDS (Instance Metadata Service). Nỗi lo của tôi đã thành hiện thực vào năm 2019 khi Capital One bị tấn công chính xác theo cách này. Điều này thúc đẩy Amazon ra mắt IMDSv2 như một bản vá lỗi quan trọng.
• Tấn công kênh phụ (Side-channel): Tại hội nghị re:Invent 2012, tôi đã cảnh báo về nguy cơ rò rỉ thông tin giữa hai luồng (threads) chia sẻ một lõi CPU thông qua HyperThreading. Tôi khuyến cáo không bao giờ chạy hai instance EC2 song song trên hai luồng của cùng một lõi. Nhiều gia đình instance EC2 sau đó đã bỏ qua kích thước "medium" và nhảy thẳng lên "large" (2 vCPUs) vì lý do này.

Từ cộng đồng đến đối tác chính thức

Năm 2019, tôi được vinh dự mời tham gia chương trình AWS Heroes, ghi nhận những đóng góp của các cá nhân không phải nhân viên Amazon cho hệ sinh thái AWS. Điều này đặc biệt ý nghĩa vì tôi luôn là người đi ngược lại xu hướng: thay vì giúp các nhà phát triển sử dụng AWS, tôi thường là người tìm lỗi và chỉ trích thiết kế của họ.

Gần đây hơn, vai trò của tôi đã mở rộng. Vào năm 2023, tôi trở thành FreeBSD Release Engineering Lead. Với khối lượng công việc tăng lên, tôi đã chia sẻ với Amazon rằng việc duy trì hỗ trợ FreeBSD trên EC2 đang trở nên quá tải. Amazon đã phản hồi tích cực bằng cách tài trợ cho tôi thông qua GitHub Sponsors. Đây là một bước ngoặt, cho thấy sự tôn trọng và cam kết của Amazon đối với hệ sinh thái mã nguồn mở.

Nhìn lại 20 năm qua, tôi tự hào về những đóng góp của mình, nhưng cũng hiểu rõ rằng tôi không thể làm điều này một mình. Rất nhiều kỹ sư Amazon đã "giúp tay" từ xa, mở ticket, cung cấp tài liệu nội bộ và hỗ trợ tôi. Mối quan hệ hợp tác này đã giúp AWS trở nên an toàn và tốt hơn, đồng thời mang FreeBSD đến với nền tảng đám mây lớn nhất thế giới.