AWS Well-Architected trong Serverless Phần I: Bảo mật

cloudFun

AWS-Well-Architected_featured.jpg
Giới thiệu về Well-Architected Framework 
AWS Well-Architected Framework (WAF) là một tập hợp các phương pháp hay nhất để xây dựng phần mềm với cơ sở hạ tầng là AWS. Framework được chia thành một whitepaper chính cung cấp cái nhìn tổng quan và năm whitepaper chi tiết hơn, được gọi là các pillar. Các pillar này là Operational Excellence (OPS), Security (SEC), Reliability (REL), Performance Efficiency (PERF), và Cost Optimization (COST). Mỗi pillar chứa các câu hỏi mà người dùng có thể trả lời cho phần mềm dựa trên AWS của mình. Những câu trả lời này liên quan đến các quyết định kỹ thuật hoặc tổ chức không liên quan trực tiếp đến các tính năng mà phần mềm của người dùng cung cấp.

Ví dụ: khi xây dựng một blog, dev muốn mọi người viết bài và những người khác đọc bài viết để triển khai các tính năng cho các trường hợp sử dụng này. Nhưng dev cũng muốn hệ thống của mình an toàn, máy chủ có thể xử lý tất cả lưu lượng truy cập và tất cả những điều này phải có một mức giá hợp lý. Câu trả lời cho những câu hỏi này đôi khi đơn giản chỉ là sử dụng một dịch vụ AWS đặc biệt. Đôi khi, họ yêu cầu người dùng thực hiện một số loại quy trình trong công ty (tổ chức) của người dùng vì nó không thể được tự động hóa hoàn toàn.
Các pillar quan trọng nhất là OPS và SEC. Chúng không bao giờ nên được giao dịch để có được nhiều hơn từ ba pillar còn lại. Điều này là do câu trả lời cho các câu hỏi OPS dẫn đến thiết lập nền tảng cần thiết để tạo điều kiện cho câu trả lời cho các câu hỏi của các pillar khác với một lượng công việc lành mạnh. Và số tiền tiết kiệm được trên SEC có thể dẫn đến những vi phạm có thể phá hủy công ty của người dùng chỉ sau một đêm. Ba pillar khác REL, PERF và COST, là một vấn đề của các yêu cầu kinh doanh. Giá quá rẻ có thể khiến hệ thống của người dùng không sử dụng được, nhưng sử dụng 100% trên REL và PERF có thể quá đắt để xây dựng một doanh nghiệp bền vững. Tùy theo túi tiền mà người dùng phải cân các pillar này so với nhau để có phương án tối ưu.

Có thể khách hàng đợi kết quả của họ lâu hơn một chút cũng không sao và người dùng đầu tư nhiều tiền hơn vào việc lưu giữ dữ liệu lâu dài. Có thể không ai sử dụng một hệ thống đắt tiền mang lại kết quả dưới giây, nhưng họ sẽ sử dụng một hệ thống mất vài giây nhưng về cơ bản rẻ hơn đáng kể. AWS cũng cung cấp công cụ Well Architected miễn phí và các hướng dẫn thực hành giúp hiểu WAF và trả lời các câu hỏi về WAF cho phần mềm của người dùng. Bằng cách này, người dùng có thể đào tạo các nguyên tắc WAF ngay cả khi không có phần mềm của riêng người dùng và đánh giá các ý tưởng kiến trúc người dùng có cho phần mềm người dùng muốn hoặc đã xây dựng.    
Có các whitepaper bổ sung, chuyên biệt hơn, được gọi là thấu kính. Những điều này củng cố các ý tưởng chung của các pillar WAF và chỉ rõ các câu hỏi của họ liên quan đến một loại phần mềm cụ thể. Ví dụ: ứng dụng không máy chủ, máy học hoặc IoT.

Trong bài viết này, chúng tôi sẽ tập trung vào Ống kính ứng dụng không máy chủ , “bao gồm các tình huống ứng dụng không máy chủ phổ biến và xác định các yếu tố chính để đảm bảo rằng workload của người dùng được kiến trúc theo các phương pháp hay nhất”. Workload ở đây là một tập hợp các hệ thống phần mềm, được gọi là các thành phần, mang lại giá trị kinh doanh.   
Một monolithic software system có thể là một workload, nhưng một tập hợp các microservice khác nhau cũng có thể tạo thành một workload.

AWS Well-Architected Framework Security Pillar

Như đã nói ở trên, pillar SEC là một trong hai pillar quan trọng nhất, cái còn lại là OPS. Người dùng không nên giao dịch pillar này để tiết kiệm tiền hoặc thực hiện phản hồi nhanh hơn một chút. Nếu một quốc gia mà người dùng hoạt động yêu cầu người dùng sử dụng một số lượng tối thiểu các biện pháp bảo mật cho một loại dữ liệu hoặc hệ thống cụ thể, thì người dùng không thể cắt bỏ.

Điều này không có nghĩa là phải mã hóa tất cả dữ liệu của mình bằng một bảng thời gian và gửi thư cho mọi người ổ cứng chứa đầy khóa mã hóa. Nó chỉ có nghĩa là giữ cho hệ thống của người dùng ít nhất là an toàn theo yêu cầu và vượt qua điều đó nếu người dùng có thể biện minh bằng cách nào đó mà không khiến bản thân và khách hàng gặp rắc rối. Rốt cuộc, vi phạm bảo mật có thể hạ gục một doanh nghiệp trong nháy mắt, vì vậy, điều đó đáng để giữ an toàn và bảo mật!
Bản thân pillar SEC cũng được chia thành năm phần; chúng ta hãy xem xét chúng: 

Quản lý Danh tính và Truy cập
Phần đầu tiên là “quản lý danh tính và quyền truy cập”, tạo thành cốt lõi của pillar. Nó cũng có thể được gọi là xác thực và ủy quyền. Nếu người dùng muốn giữ an toàn cho hệ thống của mình, người dùng cần biết ai (danh tính) đang sử dụng nó và những gì họ đang sử dụng (truy cập).

Công cụ thám tử
Phần thứ hai là "điều khiển thám tử." Nếu người dùng muốn bảo vệ hệ thống của mình, người dùng cần có một cách để giám sát rằng bảo mật đã bị vi phạm; nếu không, người dùng không biết nó an toàn.

Bảo vệ cơ sở hạ tầng
Phần thứ ba là "bảo vệ cơ sở hạ tầng", nghĩa là bảo vệ mạng và tài nguyên tính toán. Về máy chủ, hầu hết điều này được thực hiện bởi AWS vì các dịch vụ người dùng sử dụng không hiển thị trực tiếp mạng hoặc máy chủ. Người dùng vẫn cần sử dụng các quyền truy cập phù hợp, nhưng người dùng thường không cần nghĩ đến các bản vá nhân hoặc kiểm tra TCP.

Bảo vệ dữ liệu
Sau đó là “bảo vệ dữ liệu”. Người dùng không muốn dữ liệu của mình hoặc dữ liệu của người dùng bị đánh cắp. Bước quan trọng nhất trong việc bảo vệ dữ liệu của người dùng là phân loại dữ liệu của người dùng theo nhu cầu bảo mật vì mã hóa mọi thứ càng mạnh càng tốt sẽ rất tốn kém.

Ứng phó sự cố
Cuối cùng nhưng không kém phần quan trọng, đó là “phản ứng sự cố”. Sau khi người dùng đã làm mọi thứ để bảo vệ hệ thống của mình, mọi thứ vẫn có thể xảy ra sai sót và thường toàn bộ danh tiếng của người dùng được đặt vào cách “người dùng dự đoán, phản ứng và phục hồi sau [các] sự cố”. 

Câu hỏi SAL của Pillar bảo mật
SAL hỏi ba câu hỏi về bảo mật của các ứng dụng không máy chủ của người dùng. Hãy xem làm thế nào những điều này có thể được trả lời.

SEC 1: Làm cách nào để người dùng kiểm soát quyền truy cập vào API Serverless của mình?
Người dùng có thể xây dựng các API không máy chủ trên AWS bằng Amazon API Gateway cho các API HTTP, WebSockets và REST hoặc với AWS AppSync cho các API GraphQL.
Để ủy quyền cho các dịch vụ nội bộ (nghĩa là bên trong AWS và bên trong tài khoản của người dùng), người dùng có thể sử dụng các vai trò IAM. Đối với người dùng nội bộ, người dùng IAM là giải pháp.

Nếu người dùng cần khách hàng hoặc “người dùng cuối” truy cập vào các API của mình, người dùng cần có Amazon Cognito User Pools. Họ giúp đăng nhập và đăng nhập và thậm chí tích hợp với các nhà cung cấp xã hội để làm cho “Đăng nhập Facebook” được nhiều người biết đến. Nếu người dùng phải tích hợp với các dịch vụ bên ngoài và biết các dải IP mà chúng được lưu trữ, người dùng có thể định cấu hình các chính sách tài nguyên. Nếu người dùng không biết các dải IP, người dùng nên sử dụng thông tin đăng nhập tạm thời để cấp quyền truy cập.

Cuối cùng, người ủy quyền API Gateway Lambda cho phép người dùng triển khai bất kỳ quy trình xác thực tùy chỉnh nào mà người dùng có thể cần; điều này đặc biệt hữu ích khi tích hợp với các dịch vụ xác thực cũ.

SEC 2: Người dùng đang quản lý ranh giới bảo mật của Ứng dụng Serverless của mình như thế nào?
Nguyên tắc bảo mật của đặc quyền ít nhất cũng được áp dụng trong các hệ thống serverless. Đừng cấp cho mọi người quyền thực thi đối với các hàm Lambda của người dùng và chỉ cấp quyền tối thiểu cho mọi hàm Lambda. Ngoài ra, đừng sử dụng lại các quyền IAM giữa nhiều hàm Lambda và quên loại bỏ các quyền một lần nữa khi chúng trở nên lỗi thời. 
CI / CD pipeline của người dùng cũng phải bao gồm quét lỗ hổng bảo mật để kiểm tra mã của người dùng và tất cả các phụ thuộc của nó để tìm các vấn đề bảo mật ngay trước khi người dùng triển khai.

Các kết nối API Gateway và AppSync được mã hóa khi chuyển tiếp theo mặc định, nhưng người dùng nên lưu ý rằng URL có thể không phải là URL, vì vậy đừng đưa thông tin cá nhân vào đường dẫn hoặc chuỗi truy vấn. Các dịch vụ API AWS cũng hỗ trợ nhật ký truy cập có chọn lọc. Chúng phải được định cấu hình theo cách mà chúng không ghi lại dữ liệu nhạy cảm. Mã hóa ở trạng thái nghỉ nên được bật cho DynamoDB và S3 nếu dữ liệu nhạy cảm được lưu trữ.

SEC 3: Làm thế nào để người dùng triển khai Bảo mật ứng dụng trong workload của mình? 
Người dùng phải luôn xác thực và làm sạch tất cả dữ liệu từ bên ngoài và quét mã của mình để tìm các lỗ hổng giống như cách làm với các hệ thống serverless, không có gì đặc biệt ở đây. Và đừng quên lưu trữ thông tin đăng nhập vào API của bên thứ ba trong Trình quản lý bí mật của AWS, để chúng luôn được mã hóa ở trạng thái yên tâm.

Tóm lược
WAF và SAL là một bộ sưu tập whitepaper thú vị để đọc khi xây dựng các ứng dụng không máy chủ. Không chỉ khi thiết kế các hệ thống này mà còn cả sau khi đưa chúng vào sản xuất. Đó là một tài liệu dày đặc và thường một số thứ trở nên rõ ràng hơn sau khi người dùng xây dựng ứng dụng của mình. Sẽ rất hữu ích nếu xem xét Well-Architected Tool, công cụ này tương tác hơn một chút trong việc hỏi người dùng về hệ thống của họ, điều này cũng có thể hữu ích vì đôi khi chúng ta muốn bỏ qua những thứ mà chúng ta cảm thấy không thoải mái.
Bài viết này đã nói thêm một chút về pillar SEC và tất cả về nó. Xác thực người dùng và dịch vụ, mã hóa dữ liệu cá nhân và phản hồi tương ứng khi có bất kỳ điều gì bị vi phạm. Luôn ghi nhớ nguyên tắc ít đặc quyền nhất khi người dùng đặt quyền; điều này phù hợp với mọi thứ, không chỉ API Gateway công khai của người dùng. Bảo mật phải được áp dụng trên tất cả các lớp kiến trúc của người dùng.
Hãy theo dõi Phần 2, chúng ta sẽ đi sâu vào Operational Excellence pillar. 

Nguồn:
 
Top