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

Bạn đang xem tài liệu về Apigee Edge.
Truy cập vào tài liệu 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 các phương pháp bổ sung được ghi lại cho Apigee, hãy xem Các lựa chọn giảm thiểu 10 mối đe doạ hàng đầu năm 2021 của OWASP 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 cũng như API đáng tin cậy. Thông qua Dự án bảo mật API của OWASP, OWASP xuất bản những rủi ro bảo mật nghiêm trọng nhất đối với các ứ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, theo xác định của 10 mối đe doạ bảo mật API hàng đầu năm 2019 của OWASP. Một chủ đề thường gặp 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 không đúng các chế độ 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 một yêu cầu API trả về trong các ứ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 thi chế độ 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, việc kẻ tấn công lợi dụng và sử dụng sai API dẫn đến việc trích xuất 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à ưu tiên hàng đầu của Apigee, với một số tính năng mới như Advanced API Ops (Hoạt động nâng cao về API), bao gồm cả các tính năng phát hiện điểm bất thường. Tuy nhiên, việc thiết kế và triển khai chính xác các tính năng bảo mật của Apigee là rất quan trọng để giảm khả năng xảy ra các cuộc tấn công thành công vào API của bạn.

Bạn nên coi các Ứng dụng tiêu dùng 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ử rằng mọi ứng dụng công khai đều có thể và sẽ bị xâm nhập, do đó, bạn không thể tin tưởng rằng chúng sẽ 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 khoá bí mật của ứng dụng (API2) như khoá API hoặc mã truy cập. Một số đề xuất xuất phát từ việc xem xét 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 quy trình OAuth hoặc OpenID Connect "máy khách công khai" (bạn nên sử dụng PKCE)
  • Hãy nghĩ về logic nghiệp vụ của ứng dụng, xác định trước quy cách OpenAPI và thiết kế các 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 truyền dữ liệu xuố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ụ thể của người dùng để chỉ cho phép dữ liệu từ phần phụ trợ của bạn thuộc về người dùng yêu cầu.

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

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 yêu cầu truy cập vào đố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ã truy cập. Mối đe doạ này là do cấu hình không đúng cách của quy trình xác thực uỷ quyền. 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 hợp tác chặt chẽ. Uỷ quyền vố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 nghiệp vụ của ứng dụng.

Có hai khía cạnh chính cần xem xét theo quan điểm triển khai Apigee:

  • Tính toàn vẹn của mã truy cập
  • Thực thi quyền kiểm soát 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ị giả mạo 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 đăng nhập thích hợp. Apigee hỗ trợ tất cả các quy trình OAuth thường dùng.

Các chính sách xác minh mã truy cập Apigee bao gồm:

Thực thi chế độ 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, bạn cần 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 2 cơ chế chính để xác minh và thực thi các chính sách uỷ quyền:

  • Nội bộ: sử dụng các 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 tin khai báo được trích xuất dưới dạng các 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 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 xác nhận quyền sở hữu được trích xuất từ mã truy cập có thể dùng để trực tiếp đánh giá và uỷ quyền một 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.

Phương pháp uỷ quyền (minh hoạ trong hình trên) được đề xuất khi các xác nhận quyền sở hữu được trích xuất từ mã truy cập không thể được dùng trực tiếp để uỷ quyền cho một yêu cầu API đến một đối tượng phụ trợ, hoặc đối với 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ột máy chủ uỷ quyền để lấy mã truy cập.

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

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

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 sẽ cho phép kẻ tấn công mạo danh người dùng hợp pháp bằng cách khai thác các lỗi triển khai trong quá trình triển khai xác thực. 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 bao gồm:

  • 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 trực tiếp mật khẩu trong yêu cầu API
  • Luôn xác thực chữ ký của thông tin đăng nhập để truy cập và đảm bảo rằng tất cả thông tin đăng nhập để 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 dò tìm 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 dò tìm dựa trên bot

Theo mô hình từ ngoài vào trong, 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 cho 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, đồng thời 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 với các phương thức triển khai xác thực đủ mạnh để tiếp xúc với các mạng công cộng. Đây là nơi 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ể cung cấp các giải pháp mạnh mẽ để bảo vệ khỏi mối đe doạ này.

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

  • 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 rằng việc sử dụng đúng các mẫu xác thực được thiết kế luôn nhất quán trên tất cả các sản phẩm API đã xuất bản
  • Bảo mật hoạt động: có khả năng phát hiện các hành vi đáng ngờ hoặc bất thường và các nỗ lực lách hoặc tấn công giả mạo 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 cá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 và bắt đầu bằng việc tìm hiểu đúng loại quy trình xác thực được uỷ quyền để 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 cần triển khai bằng giải pháp danh tính của bạn.

Các RFC OpenID Connect và OAuth cung cấp một số lượng lớn các quy trình xác thực và uỷ quyền được uỷ quyền, cũng như các tác nhân 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 xác thực bị lỗi là một trong những mối đe doạ hàng đầu đối với API theo OWASP. Việc cung cấp thông tin cơ bản toàn diện về cách triển khai chính xác các tiêu chuẩn về danh tính 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à webcast 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:

  • 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 được uỷ quyền, nhưng đượ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 và chữ ký web JSON OpenID Connect 1.0
  • Tạo và xác thực các câu khẳng định SAML
  • Xác minh khoá API
  • Mã xác thực thông điệp khoá băm (HMAC) xác minh

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 sau đây của Apigee giúp bảo vệ khỏi các cuộc tấn công dò đoán mật khẩu:

  • Chính sách Ngăn chặn đột biến để đặt giới hạn tốc độ trung bình chung cho một proxy API
  • Chính sách hạn mức, để đặt hạn mức tốc độ chi tiết 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 vào bộ nhớ đệm mã 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 vô hiệu hoá thông tin đăng nhập được 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 liên tục, không phải là một dự án "thiết lập một lần rồi quên" và một trong những nguyên nhân lớn nhất gây ra các vụ vi phạm bảo mật là do cấu hình sai. Sau khi bạn xác định các 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, điều quan trọng tuyệt đối là bạn phải triển khai chúng 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 việc triển khai và ngăn chặn lỗi cấu hình sai.

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

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 các lỗi do 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 của 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 tối 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 quá 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 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 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ố then chốt giúp bạn mở rộng chương trình API một cách an toàn. Bạn cũng có thể sử dụng liên kết để tích hợp với danh mục công ty hiện có và giảm nhu cầu quản lý một bộ thông tin đăng nhập 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ể dùng lại và có thể triển khai trên các proxy API. Ví dụ: bạn có thể đã cùng với 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 một 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 quy trình này, họ chỉ cần biết quy trình dùng chung phù hợp để 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 quy trình.

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

Bảo mật vận hành

Sau khi API của bạn được đưa vào sản xuất bằng cách sử dụng các mẫu xác thực phù hợp với hoạt động quản lý lưu lượng truy cập cơ bản, 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 không mong muốn, bao gồm cả các cuộc tấn công từ những ứ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. Dựa vào thông tin phân tích này, bạn có thể xác định những máy 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ờ những 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 quy trình xác minh bằng reCAPTCHA đối với 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 hoà trộn với hành vi của con người
  • Nhiều lượt truy cập 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
  • Tấn công thu thập khoá và xác thực bằng phương pháp dò đoán
  • Hoạt động diễn ra liên tục
  • Mẫu hình địa lý

Các hoạt động nâng cao về API

Mặc dù Sense được thiết kế riêng để phát hiện và ứng phó với các mối đe doạ tương tự như bot, nhưng Advanced API Ops bao gồm cả phát hiện điểm 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 điểm bất thường có thể đưa ra cảnh báo theo thời gian thực cho những trường hợp mà bạn 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.

API Ops nâng cao dựa trên cơ chế cảnh báo Giám sát API hiện có để thêm các loại cảnh báo nâng cao sau đây:

  • Cảnh báo điểm 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. Sau đó, bạn có thể đưa ra cảnh báo về những điểm bất thường này
  • Cảnh báo 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

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

Một API đã xuất bản 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 trực tiếp truy vấn API cơ bản, 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ừ ngoài vào trong" của Apigee cho thiết kế API là tính tiết kiệm dữ liệu. Làm việc với 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 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ế ưu tiên API bằng Apigee là giảm thiểu dữ liệu được hiển thị ở 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 của bạ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 vấn đề 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.

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

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 nguy cơ rò rỉ dữ liệu
  • Triển khai tính năng xử lý lỗi để ngăn chặ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 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ệ các phần phụ trợ của bạn khỏi việc để lộ quá nhiều dữ liệu.

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

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

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

Chính sách Assign Message (Chỉ định thông báo) sẽ 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 những hành động sau đối với các thông báo đó:

  • 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ừ 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 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 Assign Message, 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 Assign Message để tạo một thông báo yêu cầu hoặc phản hồi tuỳ chỉnh và truyền thông báo đó đến một đích đến 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à viết lại dữ liệu phức tạp có độ 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ữ theo 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. Tính năng hỗ trợ mã theo quy trình được thiết kế để giúp bạn dễ dàng triển khai quy trình xử lý phức tạp các biến luồng, lỗi và nội dung yêu cầu và phản hồi.

Với mã theo quy trình, 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à giá trị phản hồi.
  • Viết lại URL, chẳng hạn như để che giấu URL của đ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 JavaScript, Chính sách Lời gọi Java và Chính sách Tập lệnh Python.

Xử lý lỗi

Apigee cho phép bạn thực hiện quy trình xử lý ngoại lệ tuỳ chỉnh bằng cách sử dụng một chính sách thuộc loại Raise Fault (Tạo lỗi). Chính sách Raise Fault (Tạo lỗi) (một biến thể của chính sách Assign Message (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ể 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ể dùng các chính sách được định cấu hình tương tự để phát hiện một mã lỗi HTTP cụ thể từ phần phụ trợ nhằm viết lại phản hồi lỗi để 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 độ

Nội dung 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ể làm quá tải 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:

  • Hạn mức và chính sách Chống đột biến dưới dạng các biện pháp kiểm soát phòng ngừa để đặt giới hạn lưu lượng truy cập đối với các yêu cầu API đến
  • Apigee Sense để phát hiện và ứng phó linh hoạt với các cuộc tấn công do bot điều khiển
  • Tính năng 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 vấn đề để được 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 hạn mức và chính sách Chặn đột biến

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

  • Ngăn chặn độ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 về hạn mức, ở cấp độ proxy API hoặc cấp độ sản phẩm API

Bắt giữ bằng Spike

Chính sách Ngăn chặn đột biến giúp ngăn chặn 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 một proxy API xử lý và gửi đến một phần phụ trợ, giúp ngăn chặn tình trạng hiệu suất bị chậm 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 trong chính sách.

Hạn mức

Chính sách Quota cho phép định cấu hình số lượng thông báo yêu cầu mà một proxy API cho phép trong một khoảng thời gian, chẳng hạn như một phút, giờ, ngày, tuần hoặc tháng. Bạn có thể đặt hạn mức giống 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 chính sách Ngăn chặn đột biến và thường được dùng đồng thời với chính sách đó.

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ừ những ứng dụng khách, dải IP hoặc tổ chức Hệ thống tự trị cụ thể, dựa trên những ứng dụng khách hoặc vị trí có hành vi độc hại hoặc đáng ngờ. Apigee Edge áp dụng các thao tác này cho các yêu cầu trước khi các proxy API của bạn xử lý chúng. Ví dụ: bạn có thể phát hiện một dải IP hoặc một ứng dụng khách cụ thể có hành vi "đoán mò", sau đó chặn hoặc 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 lưu lượng truy cập để đưa ra 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 cụ thể 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 xảy ra một cuộc 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 Uỷ quyền ở cấp độ chức năng 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ể của API1 và cũng là một lỗ hổng bảo mật về việc 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ể sửa đổi hoặc xoá dữ liệu mà chúng chỉ được phép đọc nếu một điểm cuối API không xác thực động từ yêu cầu HTTP, bằng cách thay thế một GET bằng một PUT hoặc DELETE. Hoặc, bằng cách 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, một đ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 làm nổi 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ế để 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ụ, kể cả chức năng quản trị 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 thành:

  • Bạn muốn bảo vệ điều gì? Hãy suy nghĩ về chiến lược sản phẩm API của bạn và triển khai phân đoạn chức năng logic khi sử dụng các phương pháp hay nhất theo kiểu REST để thiết kế các đường dẫn và tài nguyên mà các tính năng của sản phẩm, ứng dụng và proxy API Apigee đang hiển thị.
  • Ai đang truy cập vào tài nguyên API của bạn? Xác định các nhân vật 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ư được nêu trong API1 và API2.
  • Các chính sách truy cập của bạn đang được thực thi như thế nào? Sử dụng các luồng và lỗi có điều kiện để 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 hoạt động 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 dưới dạng quyền.

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

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

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

Hình: Các tài nguyên API được kết hợp thành 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 các tài nguyên để tạo cấp tiêu thụ và ranh giới uỷ quyền.

Quyền truy cập ở cấp chức năng Kiểm soát bằng phạm vi OAuth và các 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 chế độ 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 chế độ kiểm soát quyền truy cập thô ở 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 hay không? Loại chính sách này thường được xác định theo từng nhân vật 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ơ cấu hình sai, bạn nên làm việc với nhóm bảo mật để đảm bảo rằng các xác nhận về người dùng yêu cầu nằm trong mã thông báo truy cập, bằng cách sử dụng phạm vi OAuth hoặc các xác nhận JWT.

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

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

  • Một đ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 không đủ một yêu cầu API, do đó 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 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 các 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 hiểu rõ và xác định logic nghiệp vụ của một sản phẩm API, những 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:

  • Logic có điều kiện và chính sách Raise Fault để hạn chế các đường dẫn hoặc động từ tài nguyên ở bất kỳ bước nào trong cấu hình luồng proxy
  • JSON và XML Chính sách bảo vệ khỏi mối đe doạ để 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 tải trọng yêu cầu JSON hoặc XML bị lỗi

API6:2019 Mass assignment

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

Dữ liệu chưa được lọc do API cung cấp cho các ứ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 ra manh mối về vị trí thực hiện hành vi sửa đổi hoặc truy cập trái phép vào các thuộc tính trên các đối tượng dữ liệu được lưu trữ ở phần phụ trợ.

Mối đe doạ 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 một máy khách, cho phép kẻ tấn công đoán các chi tiết 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í mật. Kết quả của loại 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ể cho phép các lỗ hổng thực thi mã từ xa.

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

  • Quan điểm về 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 nhằm bật 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 để lộ dữ liệu bí mật cho một ứng dụng khách

Theo quan điểm về 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 tính năng lọc dữ liệu mạnh mẽ cho các API của bạn.

Chính sách lọc theo quy cách OpenAPI

Chính sách OASValidation (Xác thực theo quy cách OpenAPI) cho phép bạn xác thực một thông báo yêu cầu hoặc phản hồi đến dựa trên Quy cách 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 một quy cách OpenAPI (OAS)
  2. Triển khai logic cần thiết về việc dàn xếp, bảo mật và lưu vào bộ nhớ đệm để hiển thị một cách an toàn sản phẩm API từ phần phụ trợ bằng Apigee
  3. Xác thực các yêu cầu đến dựa trên lược đồ dữ liệu được xác định trong quy cách OAS của bạn, bao gồm basepath, verb, request message policy và parameters

Chính sách 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 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ể 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, bao gồm cả việc xác minh những nội dung sau trong thông báo XML hoặc JSON:

  • Chỉ có một phần tử gốc
  • Nội dung không chứa 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à thẻ kết thúc trùng khớp

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

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

Lỗi cấu hình bảo mật thường là do 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ớ đá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 có chứa thông tin nhạy cảm. Kẻ tấn công thường tìm cách phát hiện 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ệ để giành quyền truy cập trái phép hoặc nắm đượ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 về 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 bảo mật do cấu hình bảo mật sai có thể bao gồm:

  • TLS được đị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ảng điều khiển quản lý máy chủ hoặc bộ nhớ bị lộ

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 lỗi cấu hình 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 trị xung quanh 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

Quy trình công việc dùng chung và lệnh gọi quy trình công việc

Apigee hỗ trợ khái niệm về một 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ể dùng lại. Bằng cách ghi lại chức năng có thể dùng lại ở một nơi, một luồng chia sẻ sẽ 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 quy trình 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 quy trình dùng chung trong các lệnh gọi quy trình để tự động thực thi logic quy trình dùng chung cho mọi proxy API được triển khai trong cùng một môi trường dưới dạng một quy trình dùng chung.

Giám sát API

Apigee cung cấp một nền tảng Giám sát API toàn diện. Tính năng Giám sát API giúp các tổ chức chủ động phát hiện lưu lượng truy cập API và các vấn đề về hiệu suất. Apigee API Monitoring hoạt động cùng với Apigee Edge cho Đám mây công cộng để cung cấp thông tin chi tiết theo bối cảnh theo thời gian thực về hiệu suất API, giúp nhanh chóng chẩn đoán các vấn đề và tạo điều kiện cho các biện pháp khắc phục để đảm bảo tính liên tục của hoạt động kinh doanh.

Hình: Apigee API Monitoring 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ừ những ứ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.

Dựa vào kết quả 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 đó thực hiện hành động để cho phép, chặn hoặc gắn cờ những yêu cầu đó. Với Apigee Sense, bạn có thể bảo vệ các API khỏi những mẫu yêu cầu bao gồm:

  • Hành vi tự động hoà trộn với hành vi của con người
  • Nhiều lượt truy cập 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á
  • Hoạt động diễn ra liên tục
  • Mẫu hình địa lý

API8:2019 Tiêm mã

Nội dung 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 không mong muốn hoặc quyền 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 bất kỳ vectơ chèn nào có sẵn, chẳng hạn như đầu vào trực tiếp, tham số, dịch vụ tích hợp, v.v., dự kiến dữ liệu đó sẽ được gửi đến một trình thông dịch. Kẻ tấn công có thể dễ dàng phát hiện ra những điểm yếu 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 kiểm thử ngẫu nhiên. 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, điều 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ư lược đồ, loại, mẫu chuỗi, thực hiện xác thực đầu vào, kiểm tra giới hạn và thực thi chúng 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 các bộ lọc để chỉ cho phép các giá trị hợp lệ cho từng tham số đầu vào.

Apigee Edge, đóng vai trò là một máy chủ cho các yêu cầu API đến, 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 được 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 đầu vào chuyển đổi đầu vào nhằm xoá các chuỗi ký tự rủi ro và thay thế chúng bằng các giá trị an toàn.

Chính sách 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 đánh giá là true, 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 (hoặc 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 chương trình để tìm các mẫu. Bạn có thể sử dụng biểu thức chính quy, chẳng hạn như để đánh giá địa chỉ email nhằm đảm bảo địa chỉ đó có cấu trúc phù hợp.

Cách sử dụng phổ biến nhất của RegularExpressionProtection là đánh giá tải trọng JSON và XML để tìm 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 bảo vệ chuyên sâu. Phần này mô tả một số mẫu được đề xuất để ngăn chặn việc truy cập vào nội dung.

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

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 gồm hai phần. Apigee khuyến nghị bạn 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.

API9:2019 Quản lý tài sản không đúng cách

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 đủ 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 gây ra tình trạng lộ thông tin không cần thiết về các tài nguyên không dùng nữa.

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 hoàn thiệ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 giúp các nhóm cộng tác với nhau, đồng thời áp dụng việc phân chia 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ể thiết lập và duy trì các ranh giới cũng như chế độ kiểm soát bằng cách sử dụng:

Tổ chức, Môi trường và Bản sửa đổi: Các biện pháp bảo vệ ảo và thực tế đảm bảo sự cô lập và quy trình quảng bá an toàn thông qua các 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 và quy trình xúc tiến.

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 khả năng 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: 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 quy tắc đặc quyền mà nhà phát triển API không thể sửa đổi.

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

Bạn có thể đặt phạm vi cho các cấu phần phần mềm cấu hình, người dùng và tính năng trong Apigee theo 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 này có các biện pháp bảo vệ được tạo sẵn có thể được đặt xung quanh các API và cấu hình hỗ trợ của chúng.

Tổ chức: Tổ chức là đối tượng 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 có các tổ chức sản xuất và không sản xuất riêng biệt. Phương pháp này giúp tránh trộn lẫn dữ liệu, người dùng và lưu lượng truy cập trong môi trường sản xuất với các môi trường có cấp độ thấp hơn.

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 truyền đi trong quá trình quảng bá, 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: Bản sửa đổi cho phép các API và từng tính năng riêng lẻ được quảng bá 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 bắt buộc phải có định nghĩa rõ ràng và phân chia 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. Như đã nêu trước đó trong tài liệu này, Apigee có các chức năng linh hoạt về Kiểm soát quyền truy cập dựa trên vai trò, 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 giới hạn phạm vi để có đặc quyền hạn chế cho mỗi tổ chức, môi trường hoặc quyền định cấu hình chi tiết hơn. Theo phương pháp ưu tiên, hãy 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 rằng 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ò có hạn 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 chung có phạm vi áp dụng rộng rãi cho cả các điểm cuối cũ và hiện tại đã được xuất bản.

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 của bạn, bao gồm cả máy chủ/điểm cuối, tài nguyên, thao tác, giản đồ tải trọng và nhiều nội dung khác. 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à thao tác nằm trong 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 nhà phát triển tích hợp của Apigee, bạn có thể xuất bản 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. 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 Hooks

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

Apigee cho phép bạn nâng cao 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 điểm gắn kết luồng). 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 đó, các chính sách này đả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 bảo mật mặc định và do đó, cung cấp khả năng 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 Flow Hooks và Shared Flows. Các bên liên quan về bảo mật chịu 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.

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 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 bạn.

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

  • Chính sách quản lý nhật ký: Lập tài liệu và thực thi các quy tắc để chuẩn hoá và kiểm soát mức độ 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 nguyên đến nguồn của sự kiện đó. Ngoài ra, các sự kiện phải có thể được phân loại theo mức độ nghiêm trọng và tác động đến hoạt động kinh doanh
  • Báo cáo và hoạt động kiểm tra: Các bên liên quan về bảo mật và hoạt động 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 các 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ý sự kiện và nhật ký 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 của bạn. Bạn có thể linh hoạt quyết định mức độ 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 khả 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 dịch vụ: Thêm chế độ 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, đồng thời nắm được các điểm 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 chức 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 thêm và xử lý nhật ký lưu lượng truy cập.