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ể sử dụng trong Apigee để giải quyết các lỗ hổng bảo mật do OWASP xác định. Để biết thêm các phương pháp được ghi nhận cho Apigee, hãy xem bài viết 10 phương án giảm thiểu hàng đầu của OWASP 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 và duy trì các ứng dụng và API đáng tin cậy. Thông qua dự án Bảo mật API của OWASP, OWASP phát hành các rủi ro bảo mật nghiêm trọng nhất đối với ứng dụng web và API REST, đồng thời đưa ra các đề 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ư được xác định trong 10 mối đe doạ bảo mật API hàng đầu năm 2019 của OWASP. Một chủ đề chung trong các mối đe doạ hàng đầu được nêu trong danh sách mới nhất là do việc đặt không đúng cách các biện pháp kiểm soát xác thực và uỷ quyền, chẳng hạn như việc dựa vào việc lọc dữ liệu do yêu cầu API trả về trong ứng dụng khách, bằng cách sử dụng mẫu chống lại việc dựa vào ứng dụng khách tiêu thụ để thực hiện việc thực thi kiểm soát quyền truy cập.

Với tốc độ phát triển nhanh chóng của hệ sinh thái API, việc lạm dụng và sử dụng sai API 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 phương thức tấn công phổ biến nhất hiện nay. Bảo mật tiếp tục là ưu tiên hàng đầu của Apigee, với một số tính năng mới như Advanced API Ops (Quản lý API nâng cao), bao gồm các tính năng báo cáo bảo mật và phát hiện 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à rất quan trọng để giảm khả năng các cuộc tấn công thành công vào API của bạn.

Ứng dụng dành cho người tiêu dùng phải được coi 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 đó, bạn không thể tin tưởng các ứng dụng đó để thực thi quyền kiểm soát truy cập (API1, API5), lọc dữ liệu phản hồi (API6) hoặc lưu trữ an toàn các bí mật của ứng dụng (API2) như khoá API hoặc mã thông báo truy cập. Sau đây là một số đề xuất dựa trên việc kiểm tra 10 mối đe doạ hàng đầu của OWASP năm 2019:

  • Xác định loại ứng dụng khách 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) và 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" (nên sử dụng PKCE)
  • Hãy suy nghĩ về logic nghiệp vụ của ứng dụng, trước tiên hãy xác định thông số kỹ thuật OpenAPI và thiết kế proxy API để lọc tất cả dữ liệu phản hồi từ phần phụ trợ trong Apigee. Đừng bao giờ dựa vào logic mã ứng dụng hạ nguồn để thực hiện việc này!
  • Lọc tất cả các yêu cầu dữ liệu chứa PII dành riêng cho người dùng để chỉ cho phép dữ liệu từ phần phụ trợ thuộc về người dùng yêu cầu.

API1:2019 Lỗi uỷ quyền cấp đối tượng

Mô tả về mối đe doạ

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

Để ngăn chặn mối đe doạ này, điều quan trọng là các nhóm phát triển ứng dụng và bảo mật phải cộng 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à để uỷ quyền chi tiết một cách hiệu quả, bạn cần hiểu rõ logic nghiệp vụ của ứng dụng.

Có hai khía cạnh chính cần xem xét từ góc độ triển khai Apigee:

  • Tính toàn vẹn của mã truy cập
  • Thực thi biện pháp 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à phải xác thực rằng mã thông báo do ứng dụng khách yêu cầu cung cấp không 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ế xác thực hoặc ký thông tin xác thực thích hợp. Apigee hỗ trợ tất cả luồng OAuth thường dùng.

Các chính sách xác minh mã thông báo truy cập Apigee bao gồm:

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ã thông báo truy cập, điều quan trọng là 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 dựa trên 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:

  • 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ã uỷ quyền
  • Được uỷ quyền: sử dụng chú thích dịch vụ đến 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ộ (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ụ: nếu các tuyên bố được trích xuất từ mã truy cập có thể được dùng để trực tiếp đánh giá và uỷ quyền cho yêu cầu đố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á các yêu cầu truy cập bằng cách sử dụng câu lệnh luồng có điều kiện.

Bạn nên sử dụng phương pháp uỷ quyền (minh hoạ trong hình trên) khi không thể trực tiếp sử dụng các thông báo xác nhận được trích xuất từ mã thông báo truy cập để uỷ quyền yêu cầu API cho một đối tượng phụ trợ hoặc đối với các loại luồng OAuth phức tạp hơn, yêu cầu một lệnh gọi riêng đến máy chủ uỷ quyền để lấy mã thông báo 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 quyết định về chính sách uỷ quyền từ một dịch vụ của bên thứ ba hoặc lấy thêm thông tin xác nhận về tác nhân yêu cầu để đưa ra quyết định kiểm soát quyền truy cập bằng luồng có điều kiện

API2:2019 Xác thực người dùng bị hỏng

Mô tả về mối đe doạ

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ỗi triển khai trong quá trình xác thực. Sau đây là một số nguyên tắc xác thực 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 yêu cầu
  • Sử dụng các mẫu uỷ quyền và xác thực được 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 truy cập và đảm bảo rằng tất cả thông tin xác thực truy cập được sử dụng đều có thời gian hết hạn được xác định
  • Ngăn chặn các cuộc tấn công bằng phương thức brute force bằng cách đặt hạn mức và sử dụng Apigee Sense để phát hiện và phản hồi các cuộc tấn công bằng phương thức brute force do bot thực hiện

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

Có một vài thành phần chính cần xem xét ở đây, cả hai thành phần này sẽ được đề cập trong các phần sau:

  • Thiết kế bảo mật: tận dụng 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 trị: đảm bảo việc sử dụng đúng các mẫu xác thực được thiết kế một cách nhất quán trên tất cả các sản phẩm API đã phát hành
  • Bảo mật hoạt động: có thể phát hiện hành vi đáng ngờ hoặc bất thường và các hành vi cố gắng lách hoặc tấn công bằng phương thức brute force vào 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 các luồng 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 và bắt đầu bằng việc hiểu rõ loại quy trình xác thực được uỷ quyền phù hợp để sử dụng dựa trên loại ứng dụng sẽ sử dụng các điểm cuối API của bạn. Bước tiếp theo là xác định, cùng với nhóm danh tính của bạn, các mẫu tích hợp để triển khai với giải pháp danh tính.

RFC OpenID Connect và OAuth cung cấp một số lượng lớn quy trình uỷ quyền và xác thực, cũng như các thực thể 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 việc xác thực bị hỏng là một trong những mối đe doạ hàng đầu đối với API OWASP. Việc cung cấp tài liệu hướng dẫn toàn diện về cách triển khai chính xác các tiêu chuẩn nhận dạng nằm ngoài phạm vi của tài liệu này. 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à bản phát trực tiếp trên web này, cũng như ví dụ về cách triển khai.

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 vấn đề về danh tính và xác thực bao gồm:

Quản lý lưu lượng truy cập

Các tính năng quản lý lưu lượng truy cập Apigee sau đây giúp bảo vệ chống lại các cuộc tấn công bằng phương thức brute force:

  • Chính sách Chặn truy cập khi lưu lượng truy cập tăng đột biến để đặt giới hạn tốc độ trung bình lăn tổng thể trên proxy API
  • Chính sách hạn mức, để đặt giới hạn tốc độ chi tiết cho 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 vào bộ nhớ đệm các mã thông báo truy cập đã lưu trữ dựa trên thời gian hết hạn đã xác định, cũng như khả năng invalidate thông tin xác thực được lưu vào bộ nhớ đệm (ví dụ: trong trường hợp mã thông báo truy cập hợp lệ bị xâm phạm)

Quản lý

Bảo mật là một quá trình liên tục, chứ không phải là dự án "thiết lập và quên". Một trong những nguyên nhân lớn nhất gây ra sự cố bảo mật là định cấu hình không chính xác. Sau khi xác định quy trình 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 quy trình xác thực, điều quan trọng là bạn phải triển khai các quy trình này một cách chính xác và nhất quán.

Apigee cung cấp một số tính năng và công cụ để đảm bảo tính toàn vẹn của quá trình triển khai và ngăn chặn lỗi định cấu hình không chính xác.

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

Cho dù bạn là một doanh nghiệp lớn hay một công ty khởi nghiệp nhỏ, việc tránh lỗi định cấu hình sai bắt đầu 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 hỗ trợ bởi các nhóm đa ngành trong tổ chức của bạn. Điều quan trọng là mỗi nhóm chỉ được cấp các quyền cần thiết để thực hiện công việc của mình trong hành trình sử dụng API.

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

Luồng dùng chung

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ể đã cùng các nhóm bảo mật thiết kế nhiều mẫu thiết kế xác thực dựa trên loại ứng dụng sử dụng API. Nhà phát triển API không cần phải là chuyên gia về danh tính để sử dụng lại thông tin này. Họ chỉ cần biết đúng luồng dùng chung để thêm vào cấu hình proxy API hiện có bằng chính sách Chú thích về luồng.

Hình: Quy trình dùng chung là các gói 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 tổng hợp.

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

Sau khi đảm bảo 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à bạn đã xác định quy trình 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 (Hoạt động API nâng cao) mới của Apigee bao gồm công cụ báo cáo bảo mật nâng cao, cho phép Nhóm vận hành và Nhóm bảo mật dễ dàng xem báo cáo về tất cả 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 như sử dụng luồng dùng chung. Báo cáo, ghi nhật ký và cảnh báo là một phần quan trọng trong bảo mật API. Chúng ta sẽ thảo luận chi tiết hơn về vấn đề này trong phần API10: không ghi nhật ký đầy đủ. Tuy nhiên, từ góc độ ngăn chặn rủi ro xác thực bị hỏng, việc 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 quy trình dùng chung.

An ninh vận hành

Sau khi API của bạn được đưa vào sản xuất bằng các mẫu xác thực phù hợp với việ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à phản hồi hoạt động đáng ngờ, thường bắt đầu bằng các 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 truy cập yêu cầu không mong muốn, bao gồm cả các cuộc tấn công từ ứng dụng độc hại. Apigee Sense phân tích lưu lượng truy cập yêu cầu 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. Bằng cách sử dụng thông tin phân tích này, bạn có thể xác định những ứng dụng khách đưa ra 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 ReCAPTCHA trên lưu lượng truy cập đáng ngờ.

Với 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
  • Các lần thử liên tục từ cùng một địa chỉ IP
  • Tỷ lệ lỗi bất thường
  • Yêu cầu đáng ngờ của ứng dụng
  • Thu thập dữ liệu
  • Thu thập khoá và tấn công xác thực bằng phương thức bạo lực
  • Loạt hoạt động
  • Mẫu theo vị trí địa lý

Thao tác API nâng cao

Mặc dù Sense được thiết kế riêng để phát hiện và phản hồi các mối đe doạ giống như bot, nhưng Advanced API Ops bao gồm cả phát hiện bất thường và định nghĩa cảnh báo nâng cao.

Tính năng phát hiện điểm bất thường hoạt động bằng cách áp dụng các mô hình trí tuệ nhân tạo (AI) và học máy (ML) cho dữ liệu API trong quá khứ của bạn. Sau đó, tính năng phát hiện bất thường có thể đưa ra cảnh báo theo thời gian thực cho các trường hợp mà bạn thậm chí chưa 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.

Advanced API Ops (Hoạt động API nâng cao) dựa trên cơ chế cảnh báo hiện có của API Monitoring (Theo dõi API) để thêm các loại cảnh báo nâng cao sau:

  • Tổng số cảnh báo giao thông. Đưa ra cảnh báo khi lưu lượng truy cập thay đổi theo tỷ lệ phần trăm được chỉ định trong một khoảng thời gian. Ví dụ: bạn có thể gửi 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 10% trở lên trong một tuần
  • Cảnh báo về điểm bất thường. Edge sẽ 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. Sau đó, bạn có thể đưa ra cảnh báo cho những điểm bất thường này
  • Cảnh báo về ngày hết hạn TLS. Đưa ra thông báo khi chứng chỉ TLS sắp hết hạn

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

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 việc lọc cần thiết. Nếu kẻ tấn công truy vấn trực tiếp API cơ sở, thì chú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ế "từ bên ngoài vào" của Apigee cho thiết kế API là tiết kiệm dữ liệu. Làm việc với các nhà thiết kế và nhà phát triển trải nghiệm người dùng để chỉ hiển thị dữ liệu thông qua các 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 mẫu sử dụng công khai, vì vậy, một trong những nhiệm vụ đầu tiên của thiết kế API trước tiên với Apigee là giảm dữ liệu được hiển thị xuống mức tối thiểu cần thiết để cung cấp một sản phẩm API tuyệt vời cho khách hàng và nhà phát triển.

Một nguyên tắc thiết kế khác của Apigee là khả năng sử dụng lại. Ngoài các mối lo ngại về 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 yêu cầu chuyển logic lọc đó trên mọi nền tảng mà bạn phát triển ứng dụng.

Từ góc độ bảo mật, mối đe doạ này là do việc uỷ quyền thực thi quyền cho một ứng dụng, tuy nhiên, 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 ta đã xem xét 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 truy cập trái phép vào dữ liệu.

Các phần tiếp theo sẽ xem xét cách:

  • Viết lại các 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 tính năng xử lý lỗi để ngăn thông báo lỗi chi tiết tiết lộ thông tin môi trường nhạy cảm 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 Edge được thiết kế để cho phép bạn triển khai các sản phẩm API công khai bằng cách bảo vệ phần phụ trợ của bạn khỏi việc rò rỉ dữ liệu quá mức.

Để làm được điều này, Apigee sử dụng 3 chính sách chính:

  • Giao thư
  • Chú thích mã
  • Xử lý lỗi

Chỉ định chính sách về tin nhắn

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

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

Với tính năng Chỉ định thông báo, bạn thường thêm, thay đổi hoặc xoá các 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ể sử dụng tính năng Chỉ định thông báo để tạo một yêu cầu hoặc thông báo phản hồi tuỳ chỉnh 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 xử lý và ghi lại dữ liệu 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 proxy API, sau đó gọi mã đó từ các chính sách được thêm vào luồng proxy. Tính năng hỗ trợ mã quy trình được thiết kế để giúp bạn dễ dàng triển khai việc xử lý phức tạp 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ã xử lý thủ tục, bạn có thể:

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

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 thực hiện việc xử lý ngoại lệ tuỳ chỉnh bằng cách sử dụng chính sách thuộc loại Raise Fault (Nâng lỗi). Chính sách Raise Fault (Gửi lỗi) là một biến thể của chính sách Assign Message (Gán thông báo). Chính sách này cho phép bạn tạo phản hồi lỗi tuỳ chỉnh để phản hồi một điều kiện lỗi.

Luồng dùng chung

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

API4:2019 Thiếu tài nguyên và giới hạn tốc độ

Mô tả về mối đe doạ

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

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

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

Giới hạn tốc độ bằng chính sách Hạn mức và Ngừng hoạt động khi có sự kiện tăng đột biến

Apigee cung cấp hai chính sách để giới hạn tốc độ:

  • Spike arrest (Ngừng hoạt động khi có sự gia tăng đột biến) cung cấp một chính sách chung, được xác định ở cấp proxy API, để giới hạn tốc độ tổng số yêu cầu đến một 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

Spike Arrest

Chính sách Ngăn chặn lưu lượng truy cập tăng đột biến giúp 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 phần phụ trợ, bảo vệ khỏi tình trạng chậm 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 động có thể xác định được trong chính sách.

Hạn mức

Chính sách 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ư một phút, một giờ, một ngày, một tuần hoặc một tháng. Bạn có thể đặt hạn mức giống nhau cho tất 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 tính năng Ngăn chặn sự kiện tăng đột biến và thường được sử dụng đồng thời với tính năng 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ờ 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ự trị cụ thể, dựa trên các ứ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 xử lý các yêu cầu đó. Ví dụ: hệ thống có thể phát hiện một dải IP hoặc một ứng dụng cụ thể có hành vi "đoán mò", sau đó chặn hoặc gắn cờ ứng dụng đó.

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

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

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

Mô tả về mối đe doạ

Đây là một biến thể của API1 và cũng là một lỗ hổng 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 hàm mà chúng không được phép truy cập. Ví dụ: kẻ tấn công có thể chỉnh sửa 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 biện pháp kiểm soát quyền truy cập đủ hạn chế trên đường dẫn URI tài nguyên API, thì đ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 chỉ bằng cách thay đổi đường dẫn trong một 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ì nhiều hệ thống phụ trợ – không được thiết kế để truy cập công khai – theo mặc định có thể cung cấp một điểm cuối duy nhất để thực thi nhiều hàm logic nghiệp vụ, bao gồm cả chức năng quản trị có rủi ro cao.

Các thành phần khái niệm để giảm khả năng xảy ra mối đe doạ này thường được chia thành:

  • Bạn đang bảo vệ điều gì? Hãy suy nghĩ về chiến lược sản phẩm API và triển khai phân đoạn chức năng hợp lý khi sử dụng các phương pháp hay nhất về RESTful để thiết kế các đường dẫn và tài nguyên được hiển thị bởi các proxy API, sản phẩm và tính năng ứng dụng của Apigee.
  • Ai đang truy cập vào tài nguyên API của bạn? Xác định các hồ sơ cấp cao và triển khai quyền truy cập mặc định "quyền ít 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ách thức thực thi chính sách truy cập của bạn? 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ả cá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, sử dụng các phạm vi được cung cấp trong mã thông báo truy cập dưới dạng quyền.

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

Apigee cung cấp một bộ công cụ rất linh hoạt để cho phép phân đoạn hợp lý các tài nguyên API, cho phép proxy API được đóng gói thành số lượng bất kỳ sản phẩm API. 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 API này để đăng ký ứng dụng. Bạn có thể xác định chính sách quyền truy cập ở bất kỳ cấp nào trong số này.

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

Hình: Các tài nguyên API được đóng gói vào một sản phẩm API có thể đến từ một hoặc nhiều API, vì vậy, bạn có thể kết hợp và so khớp các tài nguyên để tạo các cấp sử dụng 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 JWT

Mặc dù các phương pháp uỷ quyền được xem xét ở trên cho API1:2019 Uỷ quyền đối tượng bị hỏng giải quyết việc kiểm soát quyền truy cập chi tiết ở cấp đối tượng, nhưng việc giải quyết việc kiểm soát quyền truy cập ở cấp chức năng cũng quan trọng không ké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 từng vai trò 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 bên thứ ba).

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

Yêu cầu xác thực bằng luồng có điều kiện

Ở cấp cơ bản, lệnh gọi API REST bao gồm những thành phần sau:

  • Điểm cuối
  • Một tài nguyên
  • Động từ hành động
  • Bất kỳ số lượng thuộc tính yêu cầu bổ sung nào, 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 đủ, cho phép 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 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ã thông báo truy cập hoặc thông báo xác nhận, 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 hiểu rõ và xác định logic kinh doanh của một sản phẩm API, các chức năng nào được 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 này thông qua các tính năng sản phẩm Apigee sau:

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

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

Mô tả về mối đe doạ

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

Thách thức này xảy ra khi dữ liệu chưa được lọc (thường ở định dạng JSON hoặc XML) được gửi đến ứng dụng, cho phép kẻ tấn công đoán được thông tin chi tiết về cách triển khai cơ bản của 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. Kết quả của loại hình tấn công này có thể cho phép kẻ tấn công đọc hoặc thao túng dữ liệu không phù hợp, hoặc trong trường hợp xấu nhất, có thể tạo ra các lỗ hổng thực thi mã từ xa.

Có hai khía cạnh thường liên quan đến việc cho phép loại mối đe doạ này:

  • Quan điểm thiết kế API. Đừng bao giờ dựa vào logic ứng dụng để thực hiện việc lọc dữ liệu phía máy khách, vì các ứ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ị dữ liệu tối thiểu, cần thiết để bật dịch vụ API
  • Góc độ 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 bảo mật cho ứng dụng của khách hàng

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 việc triển khai lọc dữ liệu mạnh mẽ của API.

Chính sách lọc theo Quy cách 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 yêu cầu hoặc thông báo phản hồi đến bằng 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 để hiển thị một sản phẩm API một cách an toàn 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 quy cách OAS, bao gồm cả basepath (đường dẫn cơ sở), verb (động từ), request message policy (chính sách về thông báo yêu cầu) và parameters (thông số)

Chính sách về Xác thực thông báo 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 theo lược đồ XSD hoặc xác thực thông báo SOAP theo định nghĩa WSDL. Ngoài ra, bạn có thể sử dụng Chính sách xác thực thông báo để xác nhận rằng tải trọng thông báo JSON hoặc XML được định dạng đúng cách, 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 phần tử gốc duy nhất
  • Nội dung không có ký tự không hợp lệ
  • Các đối tượng và thẻ được lồng đúng cách
  • Thẻ bắt đầu và kết thúc khớp nhau

API7:2019 Cấu hình bảo mật không chính xác

Mô tả về mối đe doạ

Việc định cấu hình sai bảo mật thường là do các cấu hình mặc định không an toàn, cấu hình không đầy đủ hoặc đặc biệt, bộ nhớ trên đám mây mở, tiêu đề HTTP được đị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 (CORS) cho phép và thông báo lỗi chi tiết chứa thông tin nhạy cảm. Kẻ tấn công thường tìm cách tìm ra các lỗ hổng chưa được vá, 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ệ để có quyền truy cập trái phép hoặc thông tin về hệ thống mà chúng muốn tấn công. Việc định cấu hình sai bảo mật không chỉ có thể làm lộ dữ liệu nhạy cảm của người dùng mà còn có thể làm lộ thông tin chi tiết về hệ thống, dẫn đến việc máy chủ bị xâm nhập hoàn toàn. Ngoài ra, một số trường hợp sử dụng khác cho các lỗ hổng về cấu hình bảo mật không chính xác có thể bao gồm:

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

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

  1. Thiết lập và chuẩn hoá các quy trình tăng cường bảo mật và vá lỗi
  2. Phát triển hoạt động quản lý xung quanh hệ sinh thái API
  3. Hạn chế quyền truy cập quản trị và bật tính năng kiểm tra cũng như cảnh báo

Quy trình dùng chung và móc quy trình

Apigee hỗ trợ khái niệm về luồng dùng chung, cho phép 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, 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à dễ dàng quản lý mã hơn. Bạn có thể đưa một luồng dùng chung vào bên trong từng proxy API hoặc bạn có thể tiến thêm một bước nữa và đặt các luồng dùng chung vào lệnh gọi luồng để 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 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 để hỗ trợ các nhóm vận hành có được thông tin minh bạch về các thuộc tính bảo mật của API nhằm:

  • Đả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 lạm dụng 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 của Apigee 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 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 sai trái từ bên trong 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.

Với 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 định cấu hình proxy API cho mục đích bảo mật, cũng như các điều kiện thời gian chạy có thể ảnh hưởng đến bảo mật proxy. Bằng cách sử dụng thông tin này, bạn có thể điều chỉnh cấu hình để đảm bảo có mức độ bảo mật phù hợp cho từng 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, bổ sung cho các tính năng báo cáo bảo mật. Tính năng Giám sát API giúp các tổ chức chủ động phát hiện vấn đề về hiệu suất và lưu lượng truy cập API. Tính năng Theo dõi API của Apigee hoạt động cùng với Apigee Edge cho Google Cloud để cung cấp thông tin chi tiết theo ngữ cảnh theo thời gian thực về hiệu suất API, giúp chẩn đoán nhanh các vấn đề và tạo điều kiện cho các biện pháp khắc phục nhằm duy trì hoạt động kinh doanh.

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

Apigee Sense

Apigee Sense giúp bảo vệ các API khỏi lưu lượng truy cập yêu cầu không mong muốn, bao gồm cả các cuộc tấn công từ ứng dụng độc hại. Apigee Sense phân tích lưu lượng truy cập yêu cầu 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.

Bằng cách sử dụng thông tin phân tích này, các tổ chức có thể xác định những ứng dụng khách đưa ra yêu cầu không mong muốn, sau đó hành động để cho phép, chặn hoặc gắn cờ các yêu cầu đó. Với Apigee Sense, bạn có thể bảo vệ các 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
  • Các lần thử liên tục từ cùng một địa chỉ IP
  • Tỷ lệ lỗi bất thường
  • Yêu cầu đáng ngờ của ứng dụng
  • Thu thập dữ liệu
  • Thu thập khoá
  • Loạt hoạt động
  • Mẫu theo vị trí địa lý

API8:2019 Chèn

Mô tả về mối đe doạ

Việc chèn dữ liệu không đáng tin cậy, 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 cho API dữ liệu độc hại thông qua mọi vectơ chèn có sẵn, chẳng hạn như dữ liệu đầu vào trực tiếp, thông số, dịch vụ tích hợp, v.v., với hy vọng dữ liệu đó sẽ được gửi đến trình thông dịch. Kẻ tấn công có thể dễ dàng phát hiện những lỗ hổng này khi xem xét mã nguồn bằng cách sử dụng trình quét lỗ hổng và trình tạo dữ liệu ngẫu nhiên. Một cuộ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à làm mất dữ liệu hoặc trong một số trường hợp, cuộc tấn công 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/tấn công chèn bao gồm việc 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, thực hiện xác thực dữ liệu đầu vào, kiểm tra giới hạn và thực thi các dữ liệu đó trong thời gian chạy. Nền tảng Apigee cho phép xác thực dữ liệu đến bằng cách sử dụng bộ lọc để chỉ cho phép các giá trị hợp lệ cho mỗi tham số đầu vào.

Apigee Edge, đóng vai trò là máy chủ cho các yêu cầu API đế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, 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ự có nguy cơ rủi ro và thay thế bằng các giá trị an toàn.

Chính sách về tính năng Bảo vệ bằng 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 đề, Tham 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 các biểu thức chính quy được xác định trước. Nếu bất kỳ biểu thức chính quy nào được chỉ định đều đánh giá là đúng, thì thông báo đó sẽ được coi là mối đe doạ và 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 theo phương thức lập trình để tìm mẫu. Ví dụ: bạn có thể sử dụng biểu thức chính quy để đánh giá địa chỉ email nhằm đảm bảo địa chỉ đó có cấu trúc đúng cách.

Cách sử dụng phổ biến nhất của RegularExpressionProtection là đánh giá 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ỏ tất cả các cuộc tấn công dựa trên nội dung và bạn nên kết hợp nhiều cơ chế để bật tính năng phòng thủ chuyên sâu. Phần này mô tả một số mẫu được đề xuất để ngăn chặn quyền truy cập vào nội dung.

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

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

Loại nội dung đề cập đến nội dung của một tệp được chuyển qua HTTP và được phân loại theo cấu trúc hai phần. Apigee đề xuất xác thực các loại nội dung cho Yêu cầu và Phản hồi bằng cách sử dụ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 cung cấp các chức năng liên quan đến báo cáo bảo mật API. Các chức năng này hỗ trợ và cung cấp cho các nhóm vận hành thông tin cần thiết để bảo mật API bằng cách cung cấp cho các nhóm vận hành thông tin cần thiết về các 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à yêu cầu về cấu hình.
  • Bảo vệ dữ liệu nhạy cảm khỏi hành vi lạm dụng 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ý thành phần không đúng cách

Mô tả về mối đe doạ

Việc quản lý và phân tách môi trường không đầy đủ cho phép kẻ tấn công truy cập vào các điểm cuối API chưa được bảo mật. Việc thiếu 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 bị hiển thị không cần thiết.

Bạn có thể giải quyết mối đe doạ này bằng cách tận dụng các chức năng đã phát triển của Apigee để quản lý toàn bộ vòng đời API, cho phép bạn tạo một mô hình quản trị toàn diện, hỗ trợ cộng tác giữa các nhóm, đồng thời áp dụng việc phân tách trách nhiệm giữa các bên liên quan đến 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 và chế độ điều khiển bằng cách sử dụng:

Tổ chức, Môi trường và Bản sửa đổi: Các hàng rào ảo và thực tế đảm bảo tính tách biệt và quy trình quảng bá an toàn thông qua ngữ 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 một API trong cổng thông tin dành cho nhà phát triển, bạn có thể giới hạn chế độ hiển thị của tài liệu bằng cách quản lý đối tượng mục tiêu.

Flow Hooks (Đường dẫn nối): Bạn có thể thực thi các chính sách và mẫu toàn cục có thể được quản lý dưới dạng các hàng rào đặ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 bảo mật có thể xem toàn bộ API đã phát hành và cấu hình hỗ trợ của các API đó. Bạn có thể kiểm tra và đánh giá việc tuân thủ các chính sách bảo mật toàn cầu dựa trên hồ sơ rủi ro cho từng điểm cuối API đã phát hành.

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

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

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

Môi trường: Bạn có thể quảng bá 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 mang theo trong quá trình quảng bá, do đó tránh hiển thị cấu hình nhạy cảm cho người dùng không có đặc quyền.

Bản sửa đổi: Bản sửa đổi cho phép quảng bá API và các tính năng riêng lẻ một cách liền mạch thông qua các 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 phải có định nghĩa rõ ràng và phân tách nhiệm vụ giữa các bên liên quan đến bảo mật và Nhà phát triển API. Như đã nêu trước đó trong tài liệu này, Apigee có các chức năng Kiểm soát quyền truy cập dựa trên vai trò 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 đặt trong phạm vi để có các đặc quyền hạn chế cho 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 các 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 toàn cục (Flow Hooks). Những vai trò bị hạn chế này sẽ ngăn chặn các thay đổi không mong 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ả các điểm cuối đã xuất bản cũ và hiện tại.

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

Cổng thông tin dành cho nhà phát triển là một thành phần quan trọng để chiến lược API của bạn thành công; cổng thông tin này cho phép bạn duy trì một kho lưu trữ toàn diện về tất cả tài liệu liên quan đến API, bao gồm máy chủ lưu trữ/điểm cuối, tài nguyên, thao tác, giản đồ tải trọng, v.v. Trong Apigee, bạn có thể nhóm các API 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 thuộc cùng một bối cảnh kinh doanh và bảo mật (ví dụ: gói dịch vụ, miền kinh doanh, danh mục, hệ thống phân cấp công ty, v.v.).

Với Cổng thông tin tích hợp dành cho nhà phát triển của Apigee, bạn có thể phát hành Sản phẩm API và hạn chế khả năng hiển thị của nội dung đã phát hành bằng cách quản lý đối tượng mục tiêu. Khả 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.

Flow Hook

Quy trình quảng bá và phát hành API phải luôn bao gồm quy trình chứng nhận và tuân thủ quy định bảo mật. Để hoạt động hiệu quả, các nhóm API sử dụng các công cụ thích hợp phải có thể tạo các hàng rào đả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 giúp bạn nâng cao trách nhiệm quản lý 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 Hook. Các chính sách chung này có thể được quản lý dưới dạng các hàng rào đặc quyền mà nhà phát triển API không thể sửa đổi, do đó đảm bảo việc phân tách trách nhiệm và cũng thúc đẩy tính linh hoạt bằng cách áp dụng tính năng bảo mật mặc định và mở rộng phạm vi tuân thủ bảo mật cho tất cả cá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 hàng rào đặc quyền trong Apigee thông qua các Lệnh gọi trong luồng và Luồng dùng chung. Các bên liên quan về bảo mật có trách nhiệm duy trì các chính sách chung liên quan đến 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

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 lý bảo mật toàn diện và đồ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 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 hành động 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: Chế độ xem tổng hợp thông tin chuyên sâu về lưu lượng truy cập của API trên: Máy chủ mục tiêu, Máy chủ lưu trữ ả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 cấu hình proxy API cung cấp khả năng hiển thị toàn diện về tất cả chính sách đang được thực thi ở cấp Proxy API, cũng như phạm vi 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 thao tác 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 xem chi tiết về hoạt động đáng ngờ.

API10:2019 Chưa đủ tính năng ghi nhật ký và giám sát

Mô tả về mối đe doạ

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

Chiến lược quản lý sự kiện và nhật ký cho API cầ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 có thể truy xuất được nguồn gốc. Ngoài ra, bạn phải có thể phân loại sự kiện theo mức độ nghiêm trọng và tác động đến hoạt động kinh doanh
  • Báo cáo và kiểm tra: Các bên liên quan đến hoạt động bảo mật và vận hành 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ỳ củng cố để điều chỉnh các 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 để tạo 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ộ công cụ vận hành trên đám mây của Google: Tận dụng tính năng tích hợp sẵn 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 các luồng nhật ký yêu cầu điểm cuối HTTP để gửi sự kiện.

Analytics: Truy cập và phân tích siêu dữ liệu lưu lượng truy cập trước đây thông qua các báo cáo có sẵn 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 cũng như tìm hiểu các bất thường về lưu lượng truy cập.

Theo dõi 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. Bạn có thể phân tích và xử lý thêm nhật ký lưu lượng truy cập.