10 mối đe dọa API OWASP hàng đầu

Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến tài liệu về Apigee X. thông tin

Tài liệu này mô tả nhiều phương pháp mà bạn có thể dùng trong quá trình ứng dụng Apigee để xử lý các lỗ hổng bảo mật do OWASP phát hiện. Để biết các phương pháp khác được ghi nhận cho Apigee, hãy xem 10 phương pháp giảm thiểu OWASP hàng đầu năm 2021 trên Google Cloud.

Giới thiệu

OWASP là một cộng đồng mở chuyên giúp các tổ chức phát triển, mua cũng như duy trì các ứng dụng và API đáng tin cậy. Thông qua dự án Bảo mật API OWASP, OWASP phát hành những rủi ro bảo mật nghiêm trọng nhất cho các ứng dụng web và API REST, đồng thời đưa ra đề xuất để giải quyết những rủi ro đó.

Tài liệu này sẽ thảo luận về các phương pháp bảo vệ chống lại các cuộc tấn công phổ biến dựa trên API, như xác định theo 10 mối đe doạ bảo mật API hàng đầu năm 2019 của OWASP. Một chủ đề phổ biến trong các mối đe doạ hàng đầu được nêu bật trong danh sách mới nhất là do việc đặt các biện pháp kiểm soát xác thực và uỷ quyền không phù hợp, chẳng hạn như dựa vào việc lọc dữ liệu mà yêu cầu API trả về trong các ứng dụng khách, bằng cách sử dụng mô hình chống dựa vào ứng dụng khách tiêu thụ để thực thi biện pháp kiểm soát quyền truy cập.

Khi hệ sinh thái API tiếp tục phát triển với tốc độ nhanh chóng, tình trạng lạm dụng và sử dụng API sai mục đích dẫn đến việc kẻ tấn công đánh cắp dữ liệu đang trở thành một trong những vectơ tấn công phổ biến nhất hiện nay. Bảo mật vẫn là một ưu tiên chính của Apigee, với một số tính năng mới như Advanced API Ops (Vận hành API nâng cao), trong đó có tính năng báo cáo bảo mật và phát hiện hoạt động bất thường. Tuy nhiên, việc thiết kế và triển khai đúng cách các tính năng bảo mật của Apigee là điều tối quan trọng để giảm khả năng tấn công thành công vào các API của bạn.

Ứng dụng dành cho người dùng thông thường nên được xem là không đáng tin cậy hoặc "công khai" vì bạn không kiểm soát nền tảng mà ứng dụng đó đang chạy. Giả sử mọi ứng dụng công khai đều có thể và sẽ bị xâm phạm, do đó, không thể tin tưởng những ứng dụng đó để thực thi biện pháp kiểm soát quyền truy cập (API1, API5), lọc dữ liệu phản hồi (API6) hoặc lưu trữ bí mật ứng dụng một cách an toàn (API2) chẳng hạn như khoá API hoặc mã truy cập. Sau đây là một số đề xuất xuất hiện khi xem xét 10 đề xuất hàng đầu của OWASP năm 2019:

  • Xác định loại ứng dụng khách nào sẽ sử dụng API của bạn (SPA, thiết bị di động hoặc dựa trên trình duyệt), đồng thời thiết kế các mẫu xác thực, uỷ quyền và bảo mật phù hợp.
  • Luôn sử dụng luồng OAuth hoặc OpenID Connect "ứng dụng công khai" (rất nên sử dụng PKCE)
  • Hãy nghĩ về logic kinh doanh của ứng dụng, trước tiên, xác định thông số kỹ thuật OpenAPI, sau đó thiết kế proxy API để lọc tất cả dữ liệu phản hồi từ phần phụ trợ trong Apigee. Không bao giờ dựa vào logic mã ứng dụng xuôi dòng để thực hiện việc này!
  • Lọc tất cả các yêu cầu dữ liệu có chứa thông tin nhận dạng cá nhân của người dùng cụ thể để chỉ cho phép dữ liệu từ phần phụ trợ của bạn thuộc về người dùng đưa ra yêu cầu.

API1:2019 Uỷ quyền cấp đối tượng bị hỏng

Nội dung mô tả về mối đe doạ

Việc xác thực uỷ quyền không đầy đủ đối với một yêu cầu truy cập đối tượng sẽ cho phép kẻ tấn công thực hiện một hành động trái phép bằng cách sử dụng lại mã thông báo truy cập. Mối đe doạ này xuất phát do cấu hình xác thực uỷ quyền không chính xác. Apigee cung cấp các chính sách VerifyApiKey, OAuth và mã thông báo web JSON (JWT) giúp bảo vệ chống lại lỗ hổng bảo mật này. Tuy nhiên, điều thiết yếu là các chính sách này phải được thiết lập chính xác để ngăn chặn mối đe doạ này.

Để ngăn chặn mối đe doạ này, các nhóm phát triển ứng dụng và bảo mật cần phải hợp tác chặt chẽ với nhau. Về bản chất, việc uỷ quyền là một chủ đề phức tạp và việc uỷ quyền chi tiết hiệu quả đòi hỏi bạn phải hiểu rõ logic kinh doanh của ứng dụng.

Khi triển khai Apigee, bạn cần cân nhắc hai khía cạnh chính:

  • Tính toàn vẹn của mã truy cập
  • Thực thi chế độ kiểm soát quyền truy cập

Tính toàn vẹn của mã truy cập

Điều quan trọng là bạn phải xác thực rằng mã thông báo do ứng dụng đưa ra yêu cầu cung cấp chưa bị can thiệp, bằng cách sử dụng quy trình OAuth hoặc OpenID Connect chính xác cùng với cơ chế ký hoặc xác thực thông tin xác thực thích hợp. Apigee hỗ trợ tất cả các quy trình OAuth thường dùng.

Sau đây là các chính sách về việc xác minh mã truy cập của Apigee:

Thực thi kiểm soát quyền truy cập

Sau khi xác minh tính hợp lệ của mã truy cập, điều quan trọng là bạn phải triển khai các chính sách thực thi kiểm soát quyền truy cập để đánh giá từng yêu cầu API đến so với các quyền truy cập của mã thông báo uỷ quyền.

Apigee cung cấp hai cơ chế chính để xác minh và thực thi chính sách uỷ quyền:

  • Internal (Nội bộ): sử dụng luồng có điều kiện để đánh giá các yêu cầu truy cập dựa trên các thông báo xác nhận quyền sở hữu được trích xuất dưới dạng biến luồng từ mã thông báo uỷ quyền
  • Được uỷ quyền: sử dụng chú thích dịch vụ cho một giải pháp quản lý quyền truy cập của bên thứ ba

Bạn nên sử dụng phương pháp nội bộ (được minh hoạ trong hình trên) khi mô hình kiểm soát quyền truy cập tương đối đơn giản. Ví dụ: bạn có thể sử dụng các thông báo xác nhận quyền sở hữu trích xuất từ mã truy cập để trực tiếp đánh giá và cho phép một yêu cầu của đối tượng API.

Sử dụng các biến luồng có sẵn cho chính sách OAuth hoặc JWT để đánh giá yêu cầu truy cập bằng câu lệnh luồng có điều kiện.

Bạn nên sử dụng phương pháp được uỷ quyền (minh hoạ trong hình trên) khi không thể sử dụng trực tiếp các thông báo xác nhận quyền sở hữu trích xuất từ mã truy cập để uỷ quyền cho một yêu cầu API đối với một đối tượng phụ trợ, hoặc cho các loại quy trình OAuth phức tạp hơn đòi hỏi một lệnh gọi riêng đến máy chủ uỷ quyền để lấy mã truy cập.

Khi sử dụng chính sách chú thích dịch vụ, bạn có thể yêu cầu một dịch vụ bên thứ ba đưa ra quyết định về chính sách uỷ quyền, hoặc lấy thêm thông tin xác nhận quyền sở hữu về tác nhân yêu cầu, sau đó đưa ra quyết định kiểm soát quyền truy cập thông qua một luồng có điều kiện

API2:2019 Phương thức xác thực người dùng bị hỏng

Nội dung mô tả về mối đe doạ

Các chính sách xác thực người dùng được triển khai không đúng cách cho phép kẻ tấn công mạo danh người dùng hợp pháp bằng cách lợi dụng các lỗ hổng triển khai trong quá trình triển khai xác thực. Sau đây là một số nguyên tắc xác thực bạn cần lưu ý khi triển khai các phương pháp xác thực:

  • Luôn xác thực cả tác nhân người dùng (ứng dụng) và người dùng đưa ra yêu cầu
  • Sử dụng mẫu xác thực và uỷ quyền, đồng thời tránh truyền mật khẩu trực tiếp trong yêu cầu API
  • Luôn xác thực chữ ký của thông tin xác thực quyền truy cập và đảm bảo rằng tất cả thông tin xác thực quyền truy cập được sử dụng đều có thời gian hết hạn xác định
  • Ngăn chặn các cuộc tấn công brute force bằng cách đặt hạn mức và sử dụng Apigee Sense để phát hiện và ứng phó với các cuộc tấn công brute force do bot thực hiện

Theo mô hình bên ngoài, thiết kế API được xây dựng dựa trên các trường hợp sử dụng dữ liệu của người tiêu dùng thay vì cấu trúc của dữ liệu hiện có trong các hệ thống phụ trợ. Tính bảo mật là một yếu tố quan trọng khi thiết kế API cho người tiêu dùng bên ngoài. Các hệ thống phụ trợ thường không được xây dựng với các phương thức triển khai xác thực đủ mạnh để hiển thị với mạng công cộng. Đây là lúc mà Apigee, kết hợp với một giải pháp quản lý danh tính và quyền truy cập, có thể đưa ra các giải pháp hiệu quả để bảo vệ chống lại mối đe doạ này.

Có một vài yếu tố chính cần xem xét ở đây, cả hai yếu tố này sẽ được giải quyết trong các phần tiếp theo:

  • Thiết kế bảo mật: khai thác tối đa các tính năng của Apigee để triển khai các mẫu xác thực
  • Quản lý: đảm bảo rằng việc sử dụng đúng các mẫu xác thực được thiết kế đều được sử dụng một cách nhất quán trên tất cả các sản phẩm API được phát hành
  • Bảo mật hoạt động: có thể phát hiện các hành vi đáng ngờ hoặc bất thường và các nỗ lực tránh né hoặc tấn công các proxy API đã xác thực

Thiết kế bảo mật

Mục tiêu của thiết kế bảo mật là triển khai chính xác quy trình xác thực và tích hợp với các công cụ nhận dạng của bên thứ ba. Thiết kế bảo mật là một giai đoạn quan trọng. Giai đoạn này bắt đầu từ việc hiểu đúng loại quy trình xác thực được uỷ quyền cần sử dụng dựa trên loại ứng dụng sẽ sử dụng điểm cuối API của bạn. Bước tiếp theo là cùng với nhóm xác định danh tính của bạn, các mẫu tích hợp để triển khai với giải pháp nhận dạng của bạn.

RFC OpenID Connect và OAuth cung cấp một số lượng lớn quy trình xác thực và uỷ quyền được uỷ quyền, cũng như các đối tượng tham gia vào các quy trình này. Đây là một chủ đề phức tạp và không có gì đáng ngạc nhiên khi quy trình xác thực bị lỗi lại là một trong những mối đe doạ API OWASP hàng đầu. Tài liệu này không cung cấp hướng dẫn toàn diện về cách triển khai chính xác các tiêu chuẩn danh tính. Tuy nhiên, Apigee có nhiều tài nguyên bổ sung giúp bạn hiểu rõ hơn về quy trình OAuth, chẳng hạn như sách điện tử và webcast này, cũng như cách triển khai mẫu.

Chính sách xác thực

Các chính sách của Apigee giúp giải quyết các mối lo ngại về danh tính và xác thực bao gồm:

  • Xác minh hoặc tạo mã truy cập, mã làm mới hoặc mã thông báo luồng phản hồi khi sử dụng khung OAuth 2.0. Lưu ý: về mặt kỹ thuật, OAuth là một khung uỷ quyền nhưng vẫn được sử dụng rộng rãi trong các mẫu xác thực được uỷ quyền hoặc liên kết
  • Xác minh, giải mã và tạo Mã thông báo web JSON OpenSL Connect 1.0 và chữ ký web JSON
  • Tạo và xác thực câu nhận định SAML
  • Xác minh khoá API
  • Mã xác thực thông điệp được khoá băm (HMAC) xác minh

Quản lý giao thông

Các tính năng quản lý lưu lượng truy cập sau đây của Apigee giúp ngăn chặn cuộc tấn công brute force:

  • Chính sách Spike bắt giữ, để đặt giới hạn tổng thể về tốc độ trung bình luân phiên cho một proxy API
  • Chính sách về hạn mức, để đặt giới hạn chi tiết về số lượng yêu cầu cho các proxy API dựa trên hạn mức do khoá ứng dụng, nhà phát triển hoặc hạn mức sản phẩm API xác định
  • Chính sách lưu vào bộ nhớ đệm, để lưu mã thông báo truy cập vào bộ nhớ đệm dựa trên thời gian hết hạn đã xác định, cũng như khả năng invalidate thông tin đăng nhập đã lưu vào bộ nhớ đệm (ví dụ: trong trường hợp mã truy cập hợp lệ bị xâm phạm)

Quản lý

Bảo mật là một quy trình đang diễn ra, không phải là một dự án "thiết lập rồi quên đi" và một trong những nguyên nhân lớn nhất gây ra các lỗi vi phạm bảo mật là việc định cấu hình sai. Sau khi xác định luồng xác thực, mẫu tích hợp danh tính và chính sách quản lý lưu lượng truy cập liên quan đến việc xác thực, bạn phải triển khai các quy trình này đúng cách và nhất quán.

Apigee cung cấp một số tính năng và công cụ giúp đảm bảo tính toàn vẹn khi triển khai và ngăn ngừa lỗi cấu hình sai.

Kiểm soát truy cập dựa trên vai trò (RBAC)

Cho dù bạn là doanh nghiệp lớn hay công ty khởi nghiệp nhỏ, bạn bắt đầu tránh các lỗi cấu hình sai bằng cách đảm bảo rằng chỉ những người và nhóm phù hợp mới có thể truy cập và sửa đổi cấu hình proxy API. Các chương trình API được các nhóm đa lĩnh vực trong tổ chức của bạn hỗ trợ. Điều vô cùng quan trọng là mỗi nhóm chỉ được cấp các quyền cần thiết để họ thực hiện công việc của mình trong hành trình API của bạn.

Apigee cung cấp các tính năng giúp bạn quản lý quyền truy cập dựa trên vai trò bằng cách cung cấp cho bạn các tính năng để chỉ định người dùng vào các vai trò được xác định trước hoặc tạo vai trò tuỳ chỉnh cho phù hợp với các nhóm API của mình. Việc xác định và quản lý đúng cách vai trò được chỉ định là rất quan trọng để bạn có thể mở rộng quy mô cho chương trình API của mình một cách an toàn. Bạn cũng có thể dùng liên kết để tích hợp với danh bạ doanh nghiệp hiện có của mình, cũng như để giảm bớt nhu cầu quản lý bộ thông tin đăng nhập của quản trị viên thứ hai trong Apigee.

Luồng được chia sẻ

Luồng dùng chung cho phép bạn xác định các chính sách và tài nguyên thành một đối tượng có thể sử dụng lại và có thể được triển khai trên các proxy API. Ví dụ: bạn có thể đã hợp tác thiết kế với nhóm bảo mật của mình nhiều mẫu thiết kế xác thực dựa trên loại ứng dụng dùng API. Nhà phát triển API không nhất thiết phải là chuyên gia về danh tính để sử dụng lại danh tính này, họ chỉ cần biết chính xác luồng được chia sẻ để thêm vào cấu hình proxy API hiện có bằng cách sử dụng chính sách Chú thích luồng.

Hình: Luồng dùng chung là các nhóm chính sách và logic có điều kiện có thể sử dụng lại, cho phép bạn duy trì một mẫu kết hợp.

Báo cáo bảo mật

Sau khi chắc chắn rằng chỉ những người phù hợp trong tổ chức của bạn mới có thể sửa đổi mẫu xác thực và đã xác định được luồng xác thực dùng chung, bạn phải đảm bảo rằng các proxy API do nhóm API của bạn phát triển đang sử dụng các mẫu xác thực đó một cách nhất quán.

Tính năng Advanced API Ops (Vận hành API nâng cao) mới của Apigee bao gồm báo cáo bảo mật nâng cao, giúp các nhóm vận hành và bảo mật dễ dàng xem báo cáo về mọi proxy API, đồng thời tập trung vào việc tuân thủ các chính sách bảo mật chẳng hạn như việc sử dụng luồng dùng chung. Báo cáo, ghi nhật ký và cảnh báo là yếu tố chính của bảo mật API sẽ được thảo luận chi tiết hơn trong phần API10: ghi nhật ký không đầy đủ. Tuy nhiên, từ góc độ ngăn chặn rủi ro xác thực bị hỏng, tính năng này cực kỳ hữu ích trong việc đảm bảo tuân thủ các tiêu chuẩn xác thực đã xác định được triển khai dưới dạng luồng chung.

Bảo mật hoạt động

Sau khi các API của bạn được phát hành chính thức bằng cách sử dụng mẫu xác thực phù hợp có quản lý lưu lượng truy cập cơ sở, nhóm SecOps cũng phải có khả năng giám sát và ứng phó với hoạt động đáng ngờ, thường bắt đầu bằng những nỗ lực xâm phạm thông tin xác thực.

Apigee Sense

Apigee Sense bảo vệ API của bạn khỏi lưu lượng yêu cầu không mong muốn, bao gồm cả các cuộc tấn công từ các ứng dụng độc hại. Apigee Sense phân tích lưu lượng yêu cầu của API, xác định các mẫu có thể đại diện cho các yêu cầu không mong muốn. Dựa trên dữ liệu phân tích này, bạn có thể xác định những ứng dụng đưa ra các yêu cầu không mong muốn, sau đó thực hiện hành động để cho phép, chặn hoặc gắn cờ các yêu cầu đó. Các tính năng trong tương lai của Sense sẽ bao gồm khả năng tự động bật tính năng xác minh lại hình ảnh xác thực lại (ReCAPTCHA) đối với lưu lượng truy cập đáng ngờ.

Nhờ Apigee Sense, bạn có thể bảo vệ API của mình khỏi các mẫu yêu cầu bao gồm:

  • Hành vi tự động kết hợp với hành vi của con người
  • Liên tục cố gắng thực hiện qua cùng một IP
  • Tỷ lệ lỗi bất thường
  • Yêu cầu đáng ngờ của khách hàng
  • Thu thập dữ liệu
  • Các cuộc tấn công bằng thuật toán brute force và thu thập khoá
  • Loạt hoạt động
  • Các mẫu địa lý

Hoạt động API nâng cao

Mặc dù Sense được thiết kế chuyên biệt để phát hiện và ứng phó với các mối đe doạ giống như bot, nhưng hoạt động API nâng cao bao gồm cả tính năng phát hiện hoạt động bất thường và định nghĩa cảnh báo nâng cao.

Tính năng phát hiện hoạt động bất thường hoạt động bằng cách áp dụng mô hình trí tuệ nhân tạo (AI) và học máy (ML) vào dữ liệu API trước đây của bạn. Sau đó, tính năng phát hiện hoạt động bất thường có thể đưa ra cảnh báo theo thời gian thực cho các tình huống mà bạn thậm chí chưa từng nghĩ đến để cải thiện năng suất và giảm thời gian trung bình để giải quyết (MTTR) các vấn đề về API.

Hoạt động API nâng cao xây dựng dựa trên cơ chế thông báo giám sát API hiện có để thêm các loại thông báo nâng cao sau đây:

  • Tổng số cảnh báo về lưu lượng truy cập. Hiển thị cảnh báo khi lưu lượng truy cập thay đổi theo tỷ lệ phần trăm đã chỉ định trong một phạm vi thời gian. Ví dụ: bạn có thể đưa ra cảnh báo khi lưu lượng truy cập tăng thêm 5% trở lên trong một giờ hoặc giảm từ 10% trở lên trong một tuần
  • Cảnh báo bất thường. Edge phát hiện các vấn đề về lưu lượng truy cập và hiệu suất thay vì bạn phải tự xác định trước các vấn đề này. Sau đó, bạn có thể đưa ra cảnh báo về những điều bất thường này
  • Cảnh báo hết hạn TLS. Hiển thị thông báo khi một chứng chỉ TLS sắp hết hạn

API3:2019 Rò rỉ dữ liệu quá mức

Nội dung mô tả về mối đe doạ

Một API đã phát hành có thể hiển thị nhiều dữ liệu hơn mức cần thiết, dựa vào ứng dụng khách để thực hiện hoạt động lọc cần thiết. Nếu kẻ tấn công trực tiếp truy vấn API cơ bản, thì kẻ tấn công có thể truy cập vào dữ liệu nhạy cảm.

Một trong những nguyên tắc thiết kế “bên ngoài” của Apigee dành cho thiết kế API là phân tích dữ liệu. Hãy làm việc với các nhà thiết kế trải nghiệm người dùng và nhà phát triển để chỉ hiển thị dữ liệu thông qua những API cần thiết trong giao diện người dùng của ứng dụng. Các hệ thống phụ trợ không được xây dựng cho các thói quen sử dụng công khai, vì vậy, một trong những nhiệm vụ đầu tiên trong thiết kế ưu tiên API với Apigee là giảm lượng dữ liệu tiếp xúc ở mức tối thiểu cần thiết để cung cấp một sản phẩm API chất lượng cao cho khách hàng và nhà phát triển của bạn.

Một trong những nguyên tắc thiết kế khác của Apigee là khả năng tái sử dụng. Ngoài vấn đề bảo mật, việc dựa vào một ứng dụng để lọc dữ liệu do API cung cấp sẽ dẫn đến việc phải chuyển logic lọc đó trên mọi nền tảng mà bạn phát triển ứng dụng trên đó.

Từ góc độ bảo mật, mối đe doạ này xuất phát từ việc uỷ quyền thực thi uỷ quyền cho một ứng dụng, nhưng thường là trên một nền tảng hoặc hệ điều hành mà bạn không có quyền kiểm soát. Chúng tôi đã kiểm tra trong API1 và API2 tầm quan trọng của việc triển khai đúng cách quy trình xác thực và uỷ quyền để tránh hành vi truy cập dữ liệu trái phép.

Các phần tiếp theo tìm hiểu cách:

  • Viết lại yêu cầu và phản hồi cho các dịch vụ phụ trợ để giảm thiểu việc rò rỉ dữ liệu
  • Triển khai quy trình xử lý lỗi để ngăn các thông báo lỗi chi tiết tiết lộ thông tin nhạy cảm về môi trường cho kẻ tấn công về các dịch vụ phụ trợ của bạn

Viết lại câu trả lời và yêu cầu

Các hệ thống phụ trợ thường không được thiết kế để sử dụng trên các ứng dụng công khai hoặc trên các mạng công khai không đáng tin cậy. Apigee được thiết kế để giúp bạn triển khai các sản phẩm API công khai bằng cách bảo vệ các phần phụ trợ của bạn khỏi nguy cơ rò rỉ dữ liệu quá mức.

Để làm việc này, Apigee sử dụng ba chính sách chính:

  • Chỉ định tin nhắn
  • Chú thích mã
  • Xử lý lỗi

Chỉ định chính sách Tin nhắn

Chính sách Gán thông báo thay đổi hoặc tạo thông báo yêu cầu và phản hồi mới trong Luồng proxy API. Chính sách này cho phép bạn làm những việc sau đây đối với các thư đó:

  • Thêm tham số biểu mẫu, tiêu đề hoặc tham số truy vấn mới vào thông báo
  • Sao chép các thuộc tính hiện có từ thông báo này sang thông báo khác
  • Xoá tiêu đề, tham số truy vấn, tham số biểu mẫu và/hoặc phần tải trọng của thư khỏi một tin nhắn
  • Đặt giá trị của các cơ sở lưu trú hiện có trong một thông báo

Với chỉ định thông báo, bạn thường thêm, thay đổi hoặc xoá thuộc tính của yêu cầu hoặc phản hồi. Tuy nhiên, bạn cũng có thể dùng tính năng Chỉ định thông báo để tạo một yêu cầu tuỳ chỉnh hoặc thông báo phản hồi và chuyển thông báo đó đến một mục tiêu thay thế, như mô tả trong phần Tạo thông báo yêu cầu tuỳ chỉnh.

Viết lại phức tạp bằng mã tuỳ chỉnh

Đối với các quy tắc viết lại và xử lý dữ liệu phức tạp mà độ phức tạp vượt quá khả năng của chính sách Chỉ định thông báo, bạn có thể sử dụng các ngôn ngữ quy trình như JavaScript, Java hoặc Python. Bạn có thể thêm mã tuỳ chỉnh vào một proxy API, sau đó gọi mã đó từ các chính sách được thêm vào quy trình proxy. Chức năng hỗ trợ mã quy trình được thiết kế để giúp bạn dễ dàng triển khai cách xử lý phức tạp đối với các biến luồng, lỗi cũng như nội dung yêu cầu và phản hồi.

Với mã quy trình, bạn có thể:

  • Tạo hoặc thao túng các giá trị cơ thể phức tạp, chẳng hạn như các giá trị yêu cầu và phản hồi.
  • Viết lại URL, chẳng hạn như để che giấu một URL điểm cuối đích.

Apigee Edge có một chính sách riêng cho các ngôn ngữ được hỗ trợ: chính sách về JavaScript, chính sách về Chú thích Java và chính sách về tập lệnh Python.

Xử lý lỗi

Apigee cho phép bạn xử lý ngoại lệ tuỳ chỉnh bằng chính sách thuộc loại Raise Fault (Tăng lỗi). Chính sách Raise Fault (Tăng lỗi) là một biến thể của chính sách Chỉ định thông báo (Chỉ định thông báo) cho phép bạn tạo một phản hồi lỗi tuỳ chỉnh để phản hồi một điều kiện lỗi.

Luồng được chia sẻ

Bạn có thể dùng luồng dùng chung để thực thi quy trình chuẩn hoá thông báo lỗi. Ví dụ: bạn có thể dùng các chính sách đã định cấu hình tương tự giúp phát hiện mã lỗi HTTP cụ thể từ phần phụ trợ để ghi lại phản hồi lỗi nhằm trả về thông báo lỗi chung.

API4:2019 Thiếu tài nguyên và giới hạn số lượng yêu cầu

Nội dung mô tả về mối đe doạ

Nếu không triển khai các chính sách giới hạn tốc độ, kẻ tấn công có thể làm cho phần phụ trợ bị quá tải bằng các cuộc tấn công từ chối dịch vụ.

Bạn có thể dễ dàng xử lý mối đe doạ này bằng cách sử dụng các tính năng của Apigee:

  • Chính sách về Hạn mức và Hạn chế tăng đột biến đóng vai trò là biện pháp kiểm soát phòng ngừa để đặt ra giới hạn về lưu lượng truy cập đối với các yêu cầu API gửi đến
  • Apigee Sense giúp phát hiện và ứng phó linh hoạt các cuộc tấn công do bot gây ra
  • Giám sát và cảnh báo API nâng cao dưới dạng các biện pháp kiểm soát giúp phát hiện cảnh báo về các cuộc tấn công DDoS đang diễn ra

Giới hạn số lượng yêu cầu bằng chính sách về Hạn mức và Mức tăng đột biến

Apigee cung cấp hai chính sách về giới hạn số lượng yêu cầu:

  • Tính năng ghi lại spike cung cấp một chính sách chung được xác định ở cấp proxy API về tốc độ giới hạn tổng số yêu cầu gửi tới phần phụ trợ
  • Hạn mức cung cấp một công cụ chính sách chi tiết để thực thi các chính sách hạn mức, ở cấp proxy API hoặc ở cấp sản phẩm API

Thiết bị chống đinh

Chính sách Bắt giữ GPS bảo vệ khỏi tình trạng lưu lượng truy cập tăng đột biến. Chính sách này điều tiết số lượng yêu cầu được proxy API xử lý và gửi đến một phần phụ trợ, giúp tránh độ trễ của hiệu suất và thời gian ngừng hoạt động, bằng cách sử dụng giá trị trung bình luân phiên có thể xác định trong chính sách.

Hạn mức

Chính sách về Hạn mức cho phép định cấu hình số lượng thông báo yêu cầu mà proxy API cho phép trong một khoảng thời gian, chẳng hạn như phút, giờ, ngày, tuần hoặc tháng. Bạn có thể đặt hạn mức là như nhau cho tất cả các ứng dụng truy cập vào proxy API, hoặc bạn có thể đặt hạn mức dựa trên:

  • Sản phẩm chứa proxy API
  • Ứng dụng yêu cầu API
  • Nhà phát triển ứng dụng
  • Nhiều tiêu chí khác

Chính sách này chi tiết hơn so với chính sách Bắt giữ đột ngột và thường được sử dụng đồng thời với chính sách này.

Phát hiện bot bằng Apigee Sense

Với Apigee Sense, bạn có thể thực hiện hành động để cho phép, chặn hoặc gắn cờ một cách rõ ràng các yêu cầu từ các ứng dụng, dải IP hoặc tổ chức Hệ thống tự động, dựa trên những ứng dụng hoặc vị trí có hành vi độc hại hoặc đáng ngờ. Apigee Edge áp dụng các hành động này cho các yêu cầu trước khi proxy API của bạn xử lý các yêu cầu đó. Ví dụ: có thể phát hiện một dải IP hoặc ứng dụng cụ thể thể hiện hành vi "dự đoán thô bạo", sau đó bị chặn hoặc bị gắn cờ.

Phát hiện mối đe doạ bằng tính năng Giám sát hoạt động API nâng cao

Sử dụng cảnh báo về lưu lượng truy cập để đưa ra thông báo khi lưu lượng truy cập của một môi trường, proxy hoặc khu vực thay đổi theo tỷ lệ phần trăm được chỉ định trong một khoảng thời gian. Tính năng này có thể linh động đưa ra cảnh báo khi lưu lượng truy cập có sự sai lệch đáng kể so với thông lượng dự kiến của bạn, như trong trường hợp xảy ra một cuộc tấn công DDoS. Những cảnh báo này có thể dễ dàng được gửi đến giải pháp giám sát và ghi nhật ký của bên thứ ba.

API5:2019 Uỷ quyền cấp hàm bị hỏng

Nội dung mô tả về mối đe doạ

Mối đe doạ này là một biến thể trên API1 và cũng là một lỗ hổng bảo mật uỷ quyền. Với mối đe doạ này, kẻ tấn công có thể thực hiện các hành động bằng cách gửi yêu cầu đến các chức năng mà chúng không được phép truy cập. Ví dụ: kẻ tấn công có thể sửa đổi hoặc xoá dữ liệu mà chúng chỉ được phép đọc nếu điểm cuối API không xác thực động từ yêu cầu HTTP, bằng cách thay thế GET bằng PUT hoặc DELETE. Hoặc, nếu không triển khai chế độ kiểm soát quyền truy cập đủ hạn chế trên đường dẫn URI tài nguyên API, điểm cuối API có thể cho phép kẻ tấn công xem dữ liệu của người dùng khác mà chỉ thay đổi đường dẫn trong yêu cầu.

Loại mối đe doạ này nêu bật giá trị của việc sử dụng Apigee làm lớp dàn xếp và trừu tượng, vì theo mặc định, nhiều hệ thống phụ trợ (không được thiết kế cho hoạt động truy cập công khai) có thể cung cấp một điểm cuối duy nhất để thực thi nhiều chức năng logic nghiệp vụ, bao gồm cả chức năng quản trị có mức độ rủi ro cao.

Các yếu tố khái niệm giúp giảm khả năng xảy ra mối đe doạ này thường được chia nhỏ thành:

  • Nội dung nào đang được bảo vệ? Hãy nghĩ về chiến lược cho sản phẩm API của bạn và triển khai phương pháp phân đoạn chức năng theo cách logic khi sử dụng các phương pháp hay nhất về RESTful để thiết kế đường dẫn và tài nguyên mà các tính năng của ứng dụng và proxy API Apigee có thể hiển thị.
  • Ai đang truy cập vào tài nguyên API của bạn? Xác định các chân dung độc giả cấp cao và triển khai các quyền truy cập mặc định "ít đặc quyền nhất" bằng cách sử dụng một số tính năng xác thực và uỷ quyền của Apigee như đã nêu trong API1 và API2.
  • Các chính sách về quyền truy cập của bạn đang được thực thi như thế nào? Sử dụng luồng có điều kiện và lỗi để xác thực đường dẫn URL và động từ của tất cả yêu cầu API.

Hình: Sơ đồ này minh hoạ cách thực thi việc uỷ quyền ở cấp hàm trong Apigee, bằng cách sử dụng các phạm vi được cung cấp trong mã truy cập làm quyền.

Phân đoạn logic với proxy API, sản phẩm và ứng dụng

Apigee cung cấp một bộ công cụ có tính linh hoạt cao để hỗ trợ việc phân đoạn theo logic đối với các tài nguyên API, cho phép đóng gói các proxy API vào số lượng sản phẩm API bất kỳ. Sau đó, các nhà phát triển ứng dụng của bạn sẽ sử dụng các sản phẩm này và có thể đăng ký ứng dụng sử dụng các sản phẩm API của bạn. Bạn có thể xác định các chính sách về quyền truy cập ở bất kỳ cấp nào trong số này.

Tuy nhiên, để triển khai phân đoạn và uỷ quyền chức năng hiệu quả, điều quan trọng là bạn phải xác định chiến lược sản phẩm API. Một phần của quy trình cần thiết và đang diễn ra này là định nghĩa "ai" và "cái gì" của sản phẩm API, bằng cách xem xét tài nguyên API của bạn từ góc độ của khách hàng và nhà phát triển, sau đó xác định tài nguyên đường dẫn và cấp động từ HTTP, cụ thể là những loại yêu cầu nào được cho phép.

Hình: Các tài nguyên API được đóng gói trong một sản phẩm API có thể đến từ một hoặc nhiều API, do đó, bạn có thể kết hợp và so khớp các tài nguyên nhằm tạo ra các cấp tiêu thụ và ranh giới uỷ quyền.

Kiểm soát quyền truy cập ở cấp hàm bằng phạm vi OAuth và thông báo xác nhận quyền sở hữu JWT

Mặc dù các phương pháp uỷ quyền đã xem xét ở trên đối với API1:2019 Uỷ quyền đối tượng bị hỏng giúp xử lý hoạt động kiểm soát quyền truy cập chi tiết ở cấp đối tượng, nhưng điều quan trọng không kém là phải giải quyết hoạt động kiểm soát quyền truy cập ở cấp độ hàm. Người dùng yêu cầu có được phép yêu cầu đường dẫn URL này không? Loại chính sách này thường được xác định theo cá tính của người dùng (khách hàng, nhân viên, quản trị viên, nhà phát triển nội bộ hoặc nhà phát triển bên thứ ba).

Để giảm nguy cơ cấu hình sai, bạn nên làm việc với nhóm bảo mật của mình để đảm bảo những câu nhận định về người dùng đưa ra yêu cầu có trong mã truy cập, bằng cách sử dụng phạm vi OAuth hoặc xác nhận quyền sở hữu JWT.

Yêu cầu xác thực bằng quy trình có điều kiện

Ở cấp độ cơ bản, lệnh gọi API REST bao gồm:

  • Điểm cuối
  • Tài nguyên
  • Một động từ hành động
  • Số lượng thuộc tính yêu cầu bổ sung bất kỳ, chẳng hạn như tham số truy vấn

Loại tấn công được mô tả trong mối đe doạ này thường là do việc lọc yêu cầu API không đầy đủ, do đó tạo điều kiện cho kẻ tấn công thực hiện các hành động trái phép hoặc truy cập vào một tài nguyên được bảo vệ. Ngoài logic có điều kiện cho phép bạn lọc các yêu cầu dựa trên mã truy cập hoặc thông báo xác nhận quyền sở hữu, Apigee còn cho phép triển khai logic lọc dựa trên chính yêu cầu đó.

Sau khi bạn nắm rõ và xác định logic nghiệp vụ của một sản phẩm API, những chức năng mà API của bạn cho phép, bước tiếp theo là hạn chế mọi yêu cầu nằm ngoài phạm vi đó thông qua các tính năng sau của sản phẩm Apigee:

  • Logic có điều kiện và chính sách Raise Fault để hạn chế đường dẫn tài nguyên hoặc động từ tại bất kỳ bước nào trong cấu hình luồng proxy
  • Chính sách về JSON và XML để bảo vệ chống lại các cuộc tấn công dựa trên nội dung bằng cách sử dụng các tải trọng yêu cầu JSON hoặc XML không đúng định dạng

Chỉ định hàng loạt API6:2019

Nội dung mô tả về mối đe doạ

Dữ liệu chưa được lọc được cung cấp qua API cho các ứng dụng khách cho phép kẻ tấn công đoán các thuộc tính của đối tượng thông qua yêu cầu hoặc sử dụng quy ước đặt tên điểm cuối để tìm các gợi ý về nơi thực hiện việc sửa đổi trái phép hoặc truy cập vào các thuộc tính trên đối tượng dữ liệu được lưu trữ trong phần phụ trợ.

Mối đe doạ này xảy ra khi dữ liệu chưa được lọc (thường ở dạng JSON hoặc XML) được gửi đến ứng dụng. Kẻ tấn công có thể đoán thông tin triển khai cơ bản của các hệ thống phụ trợ cũng như tên thuộc tính của các phần tử dữ liệu bảo mật. Kiểu tấn công này có thể tạo điều kiện cho kẻ tấn công đọc hoặc thao túng dữ liệu không phù hợp. Trong trường hợp xấu nhất, kẻ tấn công có thể tạo điều kiện cho các lỗ hổng thực thi mã từ xa.

Loại mối đe doạ này thường có hai khía cạnh:

  • Quan điểm thiết kế API. Đừng bao giờ dựa vào logic ứng dụng để thực hiện lọc dữ liệu phía máy khách, vì ứng dụng có thể bị kẻ tấn công khai thác và được coi là đáng tin cậy. Luôn thiết kế giản đồ dữ liệu API để chỉ hiển thị lượng dữ liệu tối thiểu, cần thiết để hỗ trợ dịch vụ API
  • Quan điểm triển khai API. Triển khai tính năng lọc dữ liệu và xác thực giản đồ để ngăn chặn việc vô tình tiết lộ dữ liệu mật cho ứng dụng khách

Từ góc độ sản phẩm Apigee, chúng tôi cung cấp một số tính năng hữu ích để đảm bảo triển khai tính năng lọc dữ liệu một cách hiệu quả cho các API của bạn.

Chính sách lọc Thông số kỹ thuật của OpenAPI

Chính sách OASValidation (Xác thực thông số kỹ thuật OpenAPI) cho phép bạn xác thực một yêu cầu hoặc thông báo phản hồi đến dựa trên Thông số kỹ thuật OpenAPI 3.0 (JSON hoặc YAML). Chính sách này cho phép bạn:

  1. Thiết kế API bằng cách tạo thông số kỹ thuật OpenAPI (OAS)
  2. Triển khai logic dàn xếp, bảo mật và lưu vào bộ nhớ đệm cần thiết để tiết lộ một cách an toàn một sản phẩm API từ phần phụ trợ của bạn bằng Apigee
  3. Xác thực các yêu cầu đến dựa trên giản đồ dữ liệu được xác định trong thông số kỹ thuật OAS của bạn, bao gồm cả basepath, verb, request message policy và parameter

Chính sách về xác thực thư SOAP

Chính sách xác thực thông báo SOAP cho phép bạn xác thực các yêu cầu dựa trên XML, bằng cách xác thực thông báo XML dựa trên giản đồ XSD hoặc xác thực thông báo SOAP dựa trên định nghĩa WSDL. Ngoài ra, bạn có thể dùng chính sách Xác thực thư để xác nhận rằng tải trọng thông báo JSON hoặc XML được định dạng đúng, bao gồm cả việc xác minh những nội dung sau trong thông báo XML hoặc JSON:

  • Có một thành phần gốc duy nhất
  • Nội dung không có ký tự bất hợp pháp
  • Các đối tượng và thẻ được lồng ghép đúng cách
  • Thẻ bắt đầu và thẻ đóng khớp với nhau

Cấu hình bảo mật API7:2019

Nội dung mô tả về mối đe doạ

Cấu hình bảo mật sai thường do cấu hình mặc định không an toàn, cấu hình không hoàn chỉnh hoặc đặc biệt, bộ nhớ trên đám mây mở, tiêu đề HTTP bị định cấu hình sai, phương thức HTTP không cần thiết, tính năng chia sẻ tài nguyên trên nhiều nguồn gốc được phép (CORS) và các thông báo lỗi chi tiết chứa thông tin nhạy cảm. Những kẻ tấn công thường cố gắng tìm các lỗ hổng chưa được khắc phục, các điểm cuối phổ biến hoặc các tệp và thư mục không được bảo vệ để truy cập trái phép hoặc biết được về hệ thống mà chúng muốn tấn công. Các cấu hình sai bảo mật không chỉ làm lộ dữ liệu nhạy cảm của người dùng mà còn làm lộ thông tin chi tiết về hệ thống cũng có thể khiến toàn bộ máy chủ bị xâm phạm. Ngoài ra, một số trường hợp sử dụng khác đối với các lỗ hổng bảo mật cho cấu hình bảo mật sai có thể bao gồm:

  • TLS bị định cấu hình sai
  • Thông báo lỗi có dấu vết ngăn xếp
  • Hệ thống chưa được vá
  • Bộ nhớ lộ diện hoặc bảng quản lý máy chủ

Các tổ chức có thể thực hiện nhiều bước để giải quyết và giảm thiểu những thách thức liên quan đến cấu hình sai về bảo mật, bao gồm:

  1. Thiết lập và tiêu chuẩn hoá quy trình gia cố và vá lỗi
  2. Phát triển hoạt động quản trị liên quan đến hệ sinh thái API
  3. Hạn chế quyền quản trị và bật tính năng kiểm tra và cảnh báo

Luồng dùng chung và Móc nối luồng

Apigee hỗ trợ khái niệm một quy trình dùng chung, cho phép các nhà phát triển API kết hợp các chính sách và tài nguyên thành một nhóm có thể sử dụng lại. Bằng cách thu thập chức năng có thể sử dụng lại ở một nơi, một luồng dùng chung giúp bạn đảm bảo tính nhất quán, rút ngắn thời gian phát triển và quản lý mã dễ dàng hơn. Bạn có thể đưa một luồng dùng chung vào trong các proxy API riêng lẻ, hoặc bạn có thể tiến thêm một bước bằng cách đặt các luồng dùng chung trong luồng dùng chung (flow hook) để tự động thực thi logic luồng dùng chung cho mọi proxy API được triển khai trong cùng một môi trường với một luồng dùng chung.

Báo cáo bảo mật API

Khi các tổ chức nỗ lực phát triển một khung quản trị, Apigee cung cấp các chức năng liên quan đến báo cáo bảo mật API, giúp các nhóm vận hành nắm được những thuộc tính bảo mật của API mà họ cần để:

  • Đảm bảo tuân thủ các chính sách bảo mật và yêu cầu về cấu hình
  • Bảo vệ dữ liệu nhạy cảm khỏi hành vi sai trái nội bộ và bên ngoài
  • Chủ động xác định, chẩn đoán và giải quyết các sự cố bảo mật

Báo cáo bảo mật API cung cấp thông tin chi tiết chuyên sâu cho các nhóm vận hành để đảm bảo việc tuân thủ các chính sách và yêu cầu về cấu hình, bảo vệ API khỏi hành vi lạm dụng nội bộ và bên ngoài, đồng thời nhanh chóng xác định và giải quyết các sự cố bảo mật.

Nhờ tính năng báo cáo bảo mật, quản trị viên bảo mật có thể nhanh chóng hiểu được cách các proxy API của bạn được định cấu hình cho mục đích bảo mật, cũng như những điều kiện về thời gian chạy có thể ảnh hưởng đến việc bảo mật của proxy. Khi sử dụng thông tin này, bạn có thể điều chỉnh cấu hình để đảm bảo bạn có mức độ bảo mật thích hợp cho mỗi proxy.

Giám sát API

Apigee cung cấp một nền tảng Giám sát API toàn diện giúp bổ sung khả năng báo cáo bảo mật. Dịch vụ Giám sát API giúp các tổ chức chủ động phát hiện các vấn đề về hiệu suất và lưu lượng truy cập API. Dịch vụ Giám sát API của Apigee phối hợp với Apigee Edge for Public Cloud để cung cấp thông tin chi tiết theo thời gian thực về hiệu suất của API, giúp chẩn đoán nhanh các vấn đề và hỗ trợ các biện pháp khắc phục để duy trì hoạt động kinh doanh liên tục.

Hình: Dịch vụ Giám sát API Apigee cung cấp nhiều công cụ để giám sát, điều tra và xử lý các vấn đề. Giải pháp này khai thác các tính năng thông minh hàng đầu trong ngành của Google Cloud Platform.

Apigee Sense

Apigee Sense giúp bảo vệ API khỏi lưu lượng yêu cầu không mong muốn, bao gồm cả các cuộc tấn công từ các ứng dụng độc hại. Apigee Sense phân tích lưu lượng yêu cầu của API, xác định các mẫu có thể đại diện cho các yêu cầu không mong muốn.

Dựa vào thông tin phân tích này, các tổ chức có thể xác định rằng ứng dụng đưa ra các yêu cầu không mong muốn, sau đó có biện pháp xử lý để cho phép, chặn hoặc gắn cờ các yêu cầu đó. Nhờ Apigee Sense, bạn có thể bảo vệ API khỏi các mẫu yêu cầu bao gồm:

  • Hành vi tự động kết hợp với hành vi của con người
  • Liên tục cố gắng thực hiện qua cùng một IP
  • Tỷ lệ lỗi bất thường
  • Yêu cầu đáng ngờ của khách hàng
  • Thu thập dữ liệu
  • Thu hoạch chính
  • Loạt hoạt động
  • Các mẫu địa lý

Chèn API8:2019

Nội dung mô tả về mối đe doạ

Việc chèn dữ liệu không đáng tin cậy vào các yêu cầu API (chẳng hạn như SQL, NoSQL, Trình phân tích cú pháp XML, ORM, LDAP, Lệnh hệ điều hành và JavaScript) vào các yêu cầu API có thể dẫn đến việc thực thi các lệnh ngoài ý muốn hoặc truy cập dữ liệu trái phép. Kẻ tấn công sẽ cung cấp dữ liệu độc hại cho API thông qua bất kỳ vectơ chèn nào hiện có, chẳng hạn như dữ liệu đầu vào trực tiếp, tham số, dịch vụ tích hợp, v.v. hy vọng dữ liệu này sẽ được gửi đến trình thông dịch. Những kẻ tấn công có thể dễ dàng phát hiện những lỗ hổng này trong quá trình xem xét mã nguồn bằng trình quét lỗ hổng và công cụ mờ (fuzzer). Việc chèn thành công có thể dẫn đến việc tiết lộ thông tin ảnh hưởng đến tính bảo mật và mất dữ liệu hoặc trong một số trường hợp, việc này cũng có thể dẫn đến DoS.

Các phương pháp hay nhất để giảm thiểu lỗi chèn/tấn công bao gồm xác định nghiêm ngặt dữ liệu đầu vào chẳng hạn như giản đồ, loại, mẫu chuỗi, tiến hành xác thực dữ liệu đầu vào, giới hạn các bước kiểm tra và thực thi dữ liệu đầu vào trong thời gian chạy. Nền tảng Apigee cho phép xác thực dữ liệu được gửi đến bằng cách sử dụng các bộ lọc để chỉ chấp nhận các giá trị hợp lệ cho mỗi tham số đầu vào.

Apigee, với vai trò là một máy chủ để nhận các yêu cầu API gửi đến, sẽ kiểm tra để đảm bảo rằng cấu trúc tải trọng nằm trong phạm vi chấp nhận được, hay còn gọi là kiểm tra giới hạn. Bạn có thể định cấu hình một proxy API để quy trình xác thực dữ liệu đầu vào chuyển đổi dữ liệu đầu vào nhằm xoá các chuỗi ký tự rủi ro và thay thế các chuỗi đó bằng các giá trị an toàn.

Chính sách Bảo vệ biểu thức chính quy

Chính sách RegularExpressionProtection trích xuất thông tin từ một thông báo (ví dụ: Đường dẫn URI, Tham số truy vấn, Tiêu đề, Thông số biểu mẫu, Biến, Tải trọng XML hoặc Tải trọng JSON) và đánh giá nội dung đó dựa trên biểu thức chính quy được xác định trước. Nếu có bất kỳ biểu thức chính quy nào được chỉ định có kết quả là true, thì thông báo đó sẽ bị coi là một mối đe doạ và sẽ bị từ chối. Biểu thức chính quy, viết tắt là regex, là một tập hợp các chuỗi chỉ định một mẫu trong một chuỗi. Biểu thức chính quy cho phép đánh giá nội dung để lấy mẫu theo phương thức lập trình. Bạn có thể sử dụng biểu thức chính quy, chẳng hạn như để đánh giá một địa chỉ email nhằm đảm bảo địa chỉ đó có cấu trúc đúng.

Cách sử dụng phổ biến nhất của RegularExpressionProtection là đánh giá các tải trọng JSON và XML cho nội dung độc hại.

Không có biểu thức chính quy nào có thể loại bỏ mọi cuộc tấn công dựa trên nội dung. Bạn nên kết hợp nhiều cơ chế để tạo ra khả năng phòng thủ theo chiều sâu. Phần này mô tả một số mẫu ngăn chặn quyền truy cập vào nội dung được đề xuất.

Có một số phương pháp khác để xác thực thông tin đầu vào hiện có trên nền tảng Apigee:

Xác thực loại nội dung

Loại nội dung là nội dung của một tệp được truyền qua HTTP và được phân loại theo cấu trúc gồm hai phần. Apigee khuyên bạn nên xác thực các loại nội dung cho chức năng Yêu cầu và phản hồi bằng logic có điều kiện như giải thích bên dưới.

Báo cáo bảo mật API

Khi các tổ chức nỗ lực phát triển một khung quản trị, Apigee sẽ cung cấp các chức năng liên quan đến báo cáo về tính bảo mật của API, qua đó hỗ trợ và cho các nhóm vận hành thấy được những API mà họ cần để bảo mật các API bằng cách cung cấp cho các nhóm vận hành biết họ cần thuộc tính bảo mật của API để:

  • Đảm bảo tuân thủ các chính sách bảo mật và các yêu cầu về cấu hình.
  • Bảo vệ dữ liệu nhạy cảm khỏi hành vi sai trái nội bộ và bên ngoài.
  • Chủ động xác định, chẩn đoán và giải quyết các sự cố bảo mật.

API9:2019 Quản lý tài sản không phù hợp

Nội dung mô tả về mối đe doạ

Việc quản lý môi trường và phân tách môi trường không đầy đủ sẽ cho phép kẻ tấn công truy cập vào các điểm cuối API không được bảo mật. Việc thiếu các biện pháp bảo vệ quản trị cũng khiến các tài nguyên không dùng nữa hiển thị mà không cần thiết.

Mối đe doạ này có thể được giải quyết bằng cách khai thác các chức năng đã hoàn thiện của Apigee để quản lý toàn bộ vòng đời của API, qua đó tạo ra một mô hình quản trị toàn diện cho phép các nhóm cộng tác, đồng thời tách biệt trách nhiệm giữa các bên liên quan về bảo mật và nhà phát triển API. Bạn có thể định cấu hình và duy trì các ranh giới cũng như chế độ kiểm soát bằng:

Tổ chức, môi trường và bản sửa đổi: Các rào chắn ảo và thực tế đảm bảo tính riêng biệt và quy trình quảng cáo được bảo mật thông qua bối cảnh thời gian chạy.

Kiểm soát quyền truy cập dựa trên vai trò: Chỉ những người cần thiết trong nhóm API của bạn mới có quyền quản lý các thay đổi về cấu hình cũng như quy trình quảng bá.

Quản lý đối tượng cho tài liệu API: Sau khi xuất bản API trong cổng thông tin dành cho nhà phát triển, bạn có thể giới hạn mức độ hiển thị của tài liệu bằng cách quản lý các đối tượng mục tiêu.

Flow Hooks: Bạn có thể thực thi các chính sách và mẫu chung có thể được quản lý dưới dạng các biện pháp bảo vệ đặc quyền mà nhà phát triển API không thể sửa đổi.

Báo cáo bảo mật: Các bên liên quan đến vấn đề bảo mật có thể giám sát toàn bộ các API đã phát hành và cấu hình hỗ trợ của các API đó. Việc tuân thủ các chính sách bảo mật toàn cầu có thể được kiểm tra và đánh giá dựa trên hồ sơ rủi ro cho từng điểm cuối API đã xuất bản.

Tổ chức và môi trường

Phạm vi của các cấu phần phần mềm, người dùng và tính năng cấu hình trong Apigee có thể được mở rộng sang các tổ chức và/hoặc môi trường cụ thể. Điều này có nghĩa là nền tảng đã tạo sẵn các quy tắc bảo vệ có thể đặt xung quanh các API và cấu hình hỗ trợ của các API đó.

Tổ chức: Một tổ chức là đối tượng thuê cấp cao nhất trong Apigee. API này cho phép bạn phân tách toàn bộ lưu lượng truy cập, cấu hình và người dùng. Một phương pháp quản trị hay nhất là bạn nên cân nhắc việc có các tổ chức sản xuất và phi sản xuất riêng biệt. Phương pháp này giúp tránh kết hợp dữ liệu thực tế, người dùng và lưu lượng truy cập với các môi trường thấp hơn một cách hiệu quả.

Môi trường: Bạn có thể quảng bá các API trong Apigee thông qua nhiều trạng thái triển khai; mỗi trạng thái được liên kết với một ngữ cảnh thực thi. Ngữ cảnh môi trường không được cung cấp trong quá trình quảng cáo, do đó, tránh để lộ cấu hình nhạy cảm cho người dùng không có đặc quyền.

Bản sửa đổi: Các bản sửa đổi cho phép quảng bá liền mạch các API và tính năng riêng lẻ thông qua môi trường.

Kiểm soát quyền truy cập dựa trên vai trò

Để giảm thiểu API9, bạn bắt buộc phải có định nghĩa và phân tách rõ ràng nhiệm vụ giữa các bên liên quan về bảo mật và Nhà phát triển API. Như đã đề cập trước đó trong tài liệu này, Apigee có chức năng Kiểm soát quyền truy cập dựa trên vai trò một cách linh hoạt cho phép bạn chỉ định quyền cho các vai trò tuỳ chỉnh. Đối với mối đe doạ cụ thể này, các vai trò có thể có các đặc quyền bị hạn chế đối với mỗi tổ chức, môi trường hoặc các quyền cấu hình chi tiết hơn. Bạn nên cân nhắc việc giới hạn các đặc quyền để thay đổi trạng thái triển khai của API thông qua môi trường, đồng thời đảm bảo nhà phát triển không thể truy cập hoặc sửa đổi các thư viện bảo mật chung (Flow Hooks). Những vai trò giới hạn này sẽ ngăn chặn những thay đổi ngoài ý muốn đối với các chính sách bảo mật toàn cầu (có phạm vi áp dụng rộng rãi trên cả điểm cuối cũ và điểm cuối đã phát hành hiện tại).

Tài liệu Quản lý đối tượng cho API

Cổng thông tin cho nhà phát triển là một thành phần then chốt cho sự thành công của Chiến lược API. Cổng này cho phép bạn lưu trữ toàn bộ tài liệu liên quan đến API của bạn, bao gồm cả máy chủ/điểm cuối, tài nguyên, hoạt động, giản đồ tải trọng, v.v. Trong Apigee, bạn có thể nhóm các API của mình bằng cách sử dụng cấu trúc sản phẩm API. Sản phẩm API được xác định bằng các gói tài nguyên và hoạt động trong cùng bối cảnh kinh doanh và bảo mật (ví dụ: gói dịch vụ, miền doanh nghiệp, danh mục, hệ thống phân cấp công ty, v.v.).

Thông qua Cổng thông tin dành cho nhà phát triển tích hợp của Apigee, bạn có thể phát hành các sản phẩm API và hạn chế khả năng hiển thị của nội dung đã xuất bản bằng cách quản lý đối tượng mục tiêu. Tính năng này tuân thủ chiến lược phân đoạn nội dung phù hợp với các yêu cầu về kinh doanh và bảo mật.

Móc gài

Quy trình quảng bá và phát hành API phải luôn bao gồm các quy trình chứng nhận và tuân thủ về bảo mật. Để đạt được hiệu quả, các nhóm API sử dụng các công cụ thích hợp sẽ có thể tạo ra các biện pháp đảm bảo việc phân tách trách nhiệm và duy trì chu kỳ phát hành linh hoạt.

Apigee cho phép bạn nâng cấp các nhiệm vụ quản trị bảo mật bằng cách thực thi các chính sách toàn cầu thông qua Flow Hooks. Các chính sách chung này có thể được quản lý như những biện pháp bảo vệ đặc quyền mà các nhà phát triển API không thể sửa đổi, nhờ đó đảm bảo việc phân tách trách nhiệm và nâng cao tính linh hoạt bằng cách áp dụng chế độ bảo mật mặc định, và theo đó là đảm bảo tuân thủ quy định về bảo mật cho tất cả API được triển khai trong một môi trường thực thi nhất định.

Hình: Bạn có thể định cấu hình các quy tắc bảo vệ đặc quyền trong Apigee thông qua Flow Hooks và Luồng dùng chung. Các bên liên quan đến bảo mật chịu trách nhiệm duy trì các chính sách toàn cầu liên quan đến tính bảo mật. Các tính năng này đảm bảo việc phân tách trách nhiệm và thúc đẩy vòng đời phát triển linh hoạt.

Báo cáo bảo mật

Mục đích của bài kiểm tra bảo mật là đánh giá và kiểm tra các chính sách bảo mật nhằm bảo vệ dữ liệu và mục tiêu kinh doanh của tổ chức. API là các giao diện công khai hoặc riêng tư được chuẩn hoá cần được bảo vệ bằng một mô hình quản trị bảo mật toàn diện, đồng thời có thể kiểm tra.

Trong Apigee, bạn có quyền truy cập vào các báo cáo bảo mật chuyên biệt giúp đảm bảo việc tuân thủ các chính sách đã xác định và cho phép các nhóm bảo mật của bạn tiến hành xử lý dựa trên thông tin chi tiết toàn diện về:

Lưu lượng truy cập trong thời gian chạy: Một chế độ xem toàn diện giúp bạn xem thông tin chi tiết về lưu lượng truy cập API về: Máy chủ mục tiêu, Máy chủ ảo, cấu hình TLS, thay đổi về lưu lượng truy cập theo môi trường, v.v.

Cấu hình: Khả năng kiểm tra đối với cấu hình proxy API, cung cấp chế độ hiển thị toàn diện đối với mọi chính sách được thực thi ở cấp Proxy API, cũng như phổ thực thi của các luồng dùng chung được đính kèm ở cấp tổ chức hoặc proxy.

Hoạt động của người dùng: Theo dõi các hoạt động nhạy cảm do người dùng nền tảng thực hiện. Phân tích hoạt động đáng ngờ bằng cách tìm hiểu chi tiết về hoạt động đáng ngờ.

API10:2019 Ghi nhật ký và giám sát không đầy đủ

Nội dung mô tả về mối đe doạ

Việc ghi lại, giám sát và cảnh báo không đầy đủ sẽ dẫn đến việc không phát hiện được các cuộc tấn công đang diễn ra. Vì vậy, bạn cần lập chiến lược để thu thập thông tin chi tiết về các sự kiện quan trọng có ảnh hưởng đến công việc kinh doanh của mình.

Chiến lược quản lý sự kiện và ghi nhật ký cho API nên cân nhắc các phương pháp hay nhất sau đây:

  • Chính sách quản lý nhật ký: Ghi lại và thực thi các quy tắc để chuẩn hoá và kiểm soát độ chi tiết của nhật ký, cấp độ nhật ký, tính toàn vẹn của nhật ký, kho lưu trữ tập trung, v.v.
  • Chính sách quản lý sự kiện: Đảm bảo rằng mọi sự kiện đều phải truy xuất được nguồn của sự kiện đó. Ngoài ra, bạn cũng cần phân loại các sự kiện theo mức độ quan trọng và tác động đối với doanh nghiệp
  • Báo cáo và hoạt động kiểm tra: Các bên liên quan đến hoạt động và bảo mật phải có thể truy cập và phản ứng với nhật ký và sự kiện theo thời gian thực. Ngoài ra, các bên liên quan có thể thực hiện chu kỳ tăng cường để điều chỉnh mẫu phát hiện dựa trên dữ liệu trong quá khứ

Apigee cung cấp các công cụ cần thiết để xây dựng một chiến lược quản lý nhật ký và sự kiện toàn diện. Các công cụ này bao gồm:

Chính sách ghi nhật ký thông báo: Tạo luồng nhật ký dựa trên dữ liệu lưu lượng truy cập hoặc siêu dữ liệu từ lưu lượng truy cập API. Bạn có thể linh hoạt quyết định độ chi tiết của luồng bằng cách tận dụng logic có điều kiện và mẫu thông báo.

Bộ hoạt động đám mây của Google: Khai thác khả năng tích hợp ngay từ đầu vào các công cụ giám sát và ghi nhật ký có khả năng mở rộng cao của Google.

Chính sách chú thích về dịch vụ: Thêm tính năng hỗ trợ cho những luồng nhật ký yêu cầu điểm cuối HTTP để gửi sự kiện.

Số liệu phân tích: Truy cập và phân tích siêu dữ liệu về lưu lượng truy cập trước đây thông qua các báo cáo riêng biệt và/hoặc báo cáo tuỳ chỉnh. Tạo và quản lý cảnh báo dựa trên xu hướng và hiểu được các bất thường về lưu lượng truy cập.

Giám sát API: Như đã mô tả trước đó, công cụ này cung cấp các tính năng cảnh báo có thể được kích hoạt dựa trên các sự kiện quan trọng. Chúng tôi có thể phân tích và xử lý thêm nhật ký lưu lượng truy cập.