Vào tháng 1/2018, PureSec đã phát hành Hướng dẫn 10 rủi ro hàng đầu về bảo mật máy chủ hàng đầu thế giới, được những công ty quan trọng trong ngành công nghiệp không có máy chủ đón nhận và được các hãng tin hàng đầu đưa tin. Báo cáo được dựa trên dữ liệu sơ bộ và phản hồi từ các nhà nghiên cứu về các ứng dụng không có máy chủ và các nhà quản lý cấp cao từ các công ty hàng đầu.

Kể từ nỗ lực ban đầu này vào năm 2018, việc áp dụng các ứng dụng không có máy chủ đã chứng kiến sự tăng trưởng vượt bậc, cung cấp quyền truy cập vào nhiều dữ liệu hơn về cách các tổ chức khai thác các ứng dụng không có máy chủ, cách tiếp cận phát triển các ứng dụng không có máy chủ và các lỗi lặp lại phổ biến nhất liên quan đến bảo mật và quyền riêng tư của các các ứng dụng không có máy chủ.

Ngoài ra, theo thời gian, các phương pháp giảm thiểu rủi ro mới đã xuất hiện và trở thành tiêu chuẩn, như các nền tảng bảo mật không có máy chủ, cũng như các tính năng mới được cung cấp bởi các nhà cung cấp dịch vụ đám mây, có thể giúp cải thiện khả năng bảo mật của các ứng dụng không có máy chủ.

Vào tháng 2/2019, Liên minh Bảo mật Đám mây (CSA) đã hợp tác với PureSec để phát hành một hướng dẫn mới có tên "12 rủi ro nghiêm trọng nhất cho các ứng dụng không có máy chủ", bao gồm thông tin đầu vào và phản hồi bổ sung từ hàng chục nhà lãnh đạo đứng đầu trong ngành máy chủ và là nỗ lực toàn diện lớn nhất để phân loại các rủi ro tiềm ẩn cho các ứng dụng được xây dựng trên các kiến ​​trúc không có máy chủ cho đến nay. Báo cáo được viết cho cả đối tượng bảo mật và phát triển xử lý các ứng dụng không có máy chủ và thậm chí nó còn vượt xa việc chỉ ra các rủi ro. Nó cung cấp phương thức giảm thiểu rủi ro, phương pháp thực hành tốt nhất và so sánh giữa các ứng dụng truyền thống với các ứng dụng không có máy chủ của họ.

12 rủi ro hàng đầu được liệt kê trong tài liệu được liệt kê dưới đây, với một mô tả ngắn gọn về từng rủi ro:

1: Chức năng thêm dữ liệu sự kiện

Các chức năng ứng dụng không có máy chủ có thể tiếp nhận thông tin đầu vào từ mỗi loại nguồn sự kiện khác nhau (AWS cung cấp 47 nguồn sự kiện khác nhau có thể kích hoạt chức năng AWS Lambda) và đầu vào sự kiện đó có thể bao gồm các định dạng thông báo khác nhau (tùy thuộc vào loại sự kiện và nguồn của sự kiện). Các phần khác nhau của các thông báo sự kiện này có thể chứa các thông tin đầu vào do kẻ tấn công kiểm soát hoặc yếu tố nguy hiểm khác. Nguồn sự kiện phong phú này làm tăng tiềm năng tấn công bề mặt và gây ra sự phức tạp khi cố gắng bảo vệ các chức năng của ứng dụng không có máy chủ chống lại việc thêm dữ liệu sự kiện. Điều này đặc biệt đúng bởi vì kiến ​​trúc của ứng dụng không có máy chủ gần như không được hiểu rõ như môi trường web, nơi các nhà phát triển biết phần tin nhắn nào đáng tin cậy (ví dụ: tham số GET/POST, tiêu đề HTTP, v.v.).

2: Xác thực bị hỏng

Do các kiến ​​trúc của ứng dụng không có máy chủ thúc đẩy thiết kế hệ thống theo định hướng microservice, các ứng dụng được xây dựng cho các kiến ​​trúc đó có thể chứa hàng tá (hoặc thậm chí hàng trăm) chức năng không có máy chủ riêng biệt, mỗi chức năng có một mục đích cụ thể. Các chức năng này được liên kết với nhau và phối hợp để tạo thành hệ thống logic tổng thể. Một số chức năng của ứng dụng không có máy chủ có thể hiển thị các API web công cộng, trong khi các chức năng khác có thể đóng vai trò là một cầu nối nội bộ của Google giữa các quy trình hoặc các chức năng khác. Ngoài ra, một số chức năng có thể tiếp nhận các sự kiện thuộc các loại nguồn khác nhau, chẳng hạn như các sự kiện lưu trữ đám mây, sự kiện cơ sở dữ liệu NoQuery, tín hiệu từ xa của thiết bị IoT hoặc thậm chí là thông báo SMS. Áp dụng các sơ đồ xác thực mạnh mẽ, cung cấp khả năng kiểm soát và bảo vệ truy cập cho tất cả các chức năng, loại sự kiện và trình kích hoạt có liên quan. Đây là một công việc phức tạp và có thể dễ dàng bị sai lệch nếu không được thực hiện cẩn thận.

3: Cấu hình triển khai ứng dụng không có máy chủ không an toàn

Các dịch vụ đám mây nói chung và các kiến ​​trúc ứng dụng không có máy chủ nói riêng, cung cấp nhiều tùy chọn tùy chỉnh và cài đặt cấu hình để thích ứng với các nhu cầu cụ thể, các tác vụ hoặc môi trường xung quanh. Một số tham số cấu hình có ý nghĩa quan trọng đối với các tư thế bảo mật tổng thể của các ứng dụng và cần được chú ý. Ngoài ra, các cài đặt được cung cấp bởi các nhà cung cấp kiến ​​trúc không có máy chủ có thể không phù hợp với nhu cầu của nhà phát triển. Quy trình xác thực hoặc ủy quyền bị định cấu hình sai là một điểm yếu phổ biến ảnh hưởng đến các ứng dụng sử dụng lưu trữ dựa trên đám mây. Do một trong những thiết kế thực hành tốt nhất được đề xuất cho kiến ​​trúc không có máy chủ là làm cho các chức năng không trạng thái, nên nhiều ứng dụng được xây dựng cho kiến ​​trúc không có máy chủ dựa trên cơ sở hạ tầng lưu trữ đám mây để lưu trữ và duy trì dữ liệu giữa các lần thực thi.

4: Quyền và vai trò chức năng vượt trội

Một chức năng không có máy chủ chỉ nên có các đặc quyền thiết yếu để thực hiện một dự định logic của nó, một nguyên tắc được gọi là "đặc quyền tối thiểu". Vì các chức năng không có máy chủ thường tuân theo các khái niệm microservice (xây dựng ứng dụng dựa trên tập hợp các dịch vụ nhỏ), nhưng nhiều ứng dụng không có máy chủ chứa hàng chục, hàng trăm hoặc thậm chí hàng nghìn chức năng. Kết quả là, quản lý quyền và vai trò chức năng nhanh chóng trở thành một nhiệm vụ tẻ nhạt. Trong các kịch bản như vậy, các tổ chức có thể bị buộc phải sử dụng một mô hình cấp phép hoặc vai trò bảo mật cho tất cả các chức năng mà về cơ bản, cấp cho mỗi chức năng quyền truy cập đầy đủ vào tất cả các thành phần hệ thống khác. Khi tất cả các chức năng chia sẻ cùng một tập hợp các quyền vượt trội, một lỗ hổng trong một chức năng cuối cùng có thể trở thành thành một thảm họa bảo mật trên toàn hệ thống.

5: Theo dõi và ghi nhật ký chức năng không đầy đủ

Một trong những khía cạnh quan trọng của kiến ​​trúc không có máy chủ là thực tế rằng dữ liệu cư trú trong môi trường đám mây, bên ngoài vành đai trung tâm dữ liệu của tổ chức. Như vậy, các điều khiển bảo mật tại nền tảng, trên cơ sở dữ liệu trở nên không liên quan được coi như một giải pháp bảo vệ khả thi. Điều này có nghĩa là bất kỳ quy trình, công cụ và quy trình nào được phát triển để theo dõi sự kiện bảo mật và ghi nhật ký đều trở nên lỗi thời. Mặc dù nhiều nhà cung cấp kiến ​​trúc không có máy chủ cung cấp các phương tiện ghi nhật ký cực kỳ có khả năng, nhưng các nhật ký này trong cấu hình cơ bản hoặc bên ngoài của chúng không phải lúc nào cũng phù hợp cho mục đích cung cấp một bản kiểm tra sự kiện bảo mật đầy đủ. Để đạt được giám sát sự kiện bảo mật thời gian thực đầy đủ với quy trình kiểm định thích hợp, các nhà phát triển ứng dụng không có máy chủ và các nhóm DevOps của họ được yêu cầu kết hợp logic ghi nhật ký phù hợp với nhu cầu tổ chức của họ. Ví dụ: họ phải thu thập nhật ký thời gian thực từ các chức năng máy chủ và dịch vụ đám mây khác nhau. Đẩy các bản ghi này đến một hệ thống quản lý sự kiện và thông tin bảo mật từ xa (SIEM). Điều này đôi khi sẽ yêu cầu các tổ chức trước tiên phải lưu trữ nhật ký trong dịch vụ lưu trữ đám mây trung gian.

6: Phụ thuộc của bên thứ ba không an toàn

Nói chung, một mã (code) không có máy chủ phải là một đoạn mã nhỏ thực hiện một tác vụ riêng lẻ. Các chức năng thường phụ thuộc vào các gói phần mềm của bên thứ ba, thư viện nguồn mở và thậm chí việc tiêu thụ các dịch vụ web từ xa của bên thứ ba thông qua các lệnh API để thực hiện các tác vụ. Tuy nhiên, ngay cả chức năng máy chủ an toàn nhất cũng có thể trở nên dễ bị tấn công khi nhập mã từ sự phụ thuộc của bên thứ ba dễ bị tấn công.

7: Lưu trữ bí mật ứng dụng không an toàn

Một trong những lỗi thường xuyên nhất liên quan đến lưu trữ bí mật ứng dụng chỉ đơn giản là lưu trữ những bí mật này trong một tệp cấu hình văn bản đơn giản là một phần của dự án phần mềm. Trong những trường hợp như vậy, bất kỳ người dùng nào có quyền đọc trên các dự án có thể truy cập vào các bí mật này. Tình hình sẽ trở nên tồi tệ hơn nhiều nếu dự án được lưu trữ trên một kho lưu trữ công cộng. Một lỗi phổ biến khác là lưu trữ những bí mật này trong văn bản thuần túy, dưới dạng các biến môi trường. Mặc dù các biến môi trường là một cách hữu ích để duy trì dữ liệu trên các thực thi chức năng của máy chủ, nhưng trong một số trường hợp, các biến môi trường như vậy có thể bị rò rỉ và tấn công.

8: Từ chối dịch vụ và cạn kiệt nguồn tài chính

Trong khi các kiến ​​trúc không có máy chủ mang đến những lời hứa về khả năng mở rộng tự động và tính sẵn sàng cao, chúng cũng đi kèm với những hạn chế và vấn đề cần được chú ý. Nếu một ứng dụng không được thiết kế để xử lý các thực thi đồng thời đúng cách, kẻ tấn công cuối cùng có thể đưa ứng dụng đạt các giới hạn đồng thời và từ chối dịch vụ từ những người dùng khác của hệ thống hoặc tài khoản đám mây.

9: Thao tác logic máy chủ doanh nghiệp

Thao tác logic nghiệp vụ có thể giúp kẻ tấn công lật đổ logic ứng dụng. Sử dụng kỹ thuật này, kẻ tấn công có thể bỏ qua các điều khoản truy cập, nâng cao đặc quyền của người dùng hoặc gắn kết một cuộc tấn công DoS. Thao tác logic nghiệp vụ là một vấn đề phổ biến trong nhiều loại phần mềm và kiến ​​trúc không có máy chủ. Tuy nhiên, các ứng dụng không có máy chủ là duy nhất, vì chúng thường tuân theo mô hình thiết kế microservice và chứa nhiều chức năng riêng biệt. Các hàm này được kết nối với nhau theo một thứ tự cụ thể, thực hiện logic ứng dụng tổng thể.

Trong một hệ thống có nhiều chức năng tồn tại - và mỗi chức năng có thể gọi một chức năng khác – với lưu ý thứ tự gọi có thể rất quan trọng để đạt được logic mong muốn. Hơn nữa, thiết kế có thể giả định rằng các chức năng nhất định chỉ được gọi trong các tình huống cụ thể và chỉ bởi những người xâm nhập được ủy quyền.

Thao tác logic nghiệp vụ trong các ứng dụng không có máy chủ cũng có thể xảy ra trong một chức năng, trong đó kẻ tấn công có thể khai thác thiết kế xấu hoặc tiêm mã độc trong khi thực thi chức năng, ví dụ, bằng cách khai thác các chức năng tải dữ liệu từ các nguồn không tin cậy hoặc tài nguyên đám mây bị xâm phạm.

Một kịch bản có liên quan khác là trong đó quá trình gọi nhiều chức năng, hệ thống có thể trở thành mục tiêu cho những kẻ tấn công, là các trạng thái máy dựa trên máy chủ. Các ví dụ bao gồm các chức năng AWS Step Functions, Azure Logic Apps, Azure Durable Functions hoặc Chuỗi chức năng đám mây của IBM.

10: Xử lý ngoại lệ không đúng và thông báo lỗi dài dòng

Các tùy chọn gỡ lỗi từng dòng cho các ứng dụng dựa trên máy chủ bị giới hạn (và phức tạp hơn) khi so sánh với khả năng gỡ lỗi cho các ứng dụng tiêu chuẩn. Thực tế này đặc biệt đúng khi các chức năng không có máy chủ sử dụng các dịch vụ dựa trên đám mây không khả dụng khi gỡ lỗi mã cục bộ. Do đó, các nhà phát triển sẽ thường xuyên áp dụng việc sử dụng các thông báo lỗi dài dòng, cho phép gỡ lỗi các biến môi trường và cuối cùng quên làm sạch mã khi chuyển nó sang môi trường sản xuất.

11: Hàm không sử dụng và Tài nguyên đám mây

Tương tự như các loại ứng dụng phần mềm hiện đại khác, theo thời gian, một số chức năng không có máy chủ và tài nguyên đám mây có liên quan có thể trở nên lỗi thời và sẽ ngừng hoạt động. Cắt giảm các thành phần ứng dụng lỗi thời nên được thực hiện định kỳ để giảm chi phí không cần thiết và để giảm các bề mặt tấn công có thể tránh được. Các thành phần ứng dụng không có máy chủ lỗi thời có thể bao gồm:

• Phiên bản chức năng máy chủ không dùng nữa
• Các chức năng không có máy chủ không còn phù hợp nữa
• Tài nguyên đám mây không được sử dụng (ví dụ: cơ sở lưu trữ, cơ sở dữ liệu, tin nhắn chờ, v.v...)
• Kích hoạt nguồn sự kiện không cần thiết của máy chủ
• Người dùng, vai trò hoặc danh tính không sử dụng
• Phần mềm phụ thuộc không sử dụng

12: Tính bền vững của dữ liệu thực thi chéo

Các nền tảng không máy chủ cung cấp cho các nhà phát triển ứng dụng lưu trữ đĩa cục bộ, biến môi trường và bộ nhớ RAM để thực hiện các tác vụ tính toán theo cách tương tự với bất kỳ ngăn xếp phần mềm hiện đại nào.

Để làm cho các nền tảng không có máy chủ hoạt động hiệu quả trong việc xử lý các yêu cầu mới và tránh khởi động lại, các nhà cung cấp dịch vụ đám mây có thể sử dụng lại môi trường thực thi (ví dụ: container) cho các yêu cầu chức năng tiếp theo.

Trong trường hợp môi trường thực thi không có máy chủ được sử dụng lại cho các lần gọi tiếp theo, nó có thể thuộc về người dùng cuối hoặc bối cảnh phiên hoạt động khác nhau, do đó có thể dữ liệu nhạy cảm sẽ bị bỏ lại và có thể bị lộ.

Các nhà phát triển phải luôn coi môi trường thực thi của các chức năng không có máy chủ là phù du và không trạng thái và không nên thừa nhận bất cứ điều gì về tính sẵn có, tính toàn vẹn và quan trọng nhất là việc xử lý dữ liệu được lưu trữ cục bộ giữa các lệnh.

 (Nguồn: http://ictvietnam.vn)