KUNGFU TECH

0
0
Lập trình
Admin Team
Admin Teamtechmely

Mô hình bảo mật Apigee: Sản phẩm API, nhà phát triển và khóa API

Đăng vào 4 ngày trước

• 9 phút đọc

Chủ đề:

#api#apigateway#googlecloud#apigee

Tổng Quan: Mô Hình Bảo Mật Apigee

Apigee sử dụng khóa API như một thông tin xác thực chính để truy cập API. Khóa này không được tạo ra một cách riêng lẻ; nó là kết quả của mối quan hệ giữa một Nhà phát triển, ứng dụng của họ và các Sản phẩm API mà ứng dụng đó được phép tiêu thụ.

Luồng Hoạt Động

Dưới đây là quy trình hoạt động của chúng:

  1. Bạn (nhà cung cấp API) công bố một Sản phẩm API.
  2. Một Nhà phát triển đăng ký trên cổng thông tin nhà phát triển của bạn.
  3. Nhà phát triển tạo một Ứng dụng và chọn các Sản phẩm API mà ứng dụng cần truy cập.
  4. Apigee tạo ra một khóa API duy nhất cho ứng dụng đó.
  5. Nhà phát triển bao gồm khóa này trong các yêu cầu mà ứng dụng của họ thực hiện.
  6. Apigee kiểm tra xem khóa có hợp lệ và có quyền truy cập vào Sản phẩm API được yêu cầu hay không.

1. Sản phẩm API

Sản phẩm API là một gói tài nguyên API (proxy) mà bạn, với tư cách là nhà cung cấp API, cung cấp cho các nhà phát triển. Đây là đơn vị tiêu thụ thương mại và pháp lý chính. Sản phẩm API xác định:

  • Các proxy/điểm cuối nào: Các API proxy (và các đường dẫn cụ thể của chúng) được bao gồm.
  • Hạn mức: Số lượng yêu cầu có thể được thực hiện mỗi phút, giờ, ngày, v.v.
  • Chính sách truy cập: Ai có thể truy cập nó (ví dụ: nhà phát triển nội bộ so với bên ngoài).

Hãy nghĩ về nó như một "gói truyền hình cáp". Bạn không mua từng kênh riêng lẻ; bạn mua một gói (ví dụ: "Gói thể thao nhẹ" hoặc "Gói yêu thích phim").

Ví dụ:
Bạn làm việc tại Công tyX và đã xây dựng nhiều API. Bạn tạo hai sản phẩm:

  • Công tyX-Mức miễn phí
    • Proxy bao gồm: weather-api, news-api
    • Hạn mức: 100 cuộc gọi mỗi ngày, 5 cuộc gọi mỗi phút
    • Môi trường: test (để thử nghiệm)
  • Công tyX-Thời tiết cao cấp
    • Proxy bao gồm: weather-api (bao gồm tất cả các điểm cuối, kể cả các điểm cao cấp như dữ liệu lịch sử)
    • Hạn mức: 10,000 cuộc gọi mỗi ngày, 100 cuộc gọi mỗi phút
    • Môi trường: test, prod

2. Nhà phát triển

Một Nhà phát triển đại diện cho một người dùng hoặc một công ty tiêu thụ API của bạn. Họ thường được đăng ký thông qua cổng thông tin nhà phát triển của bạn.

  • Họ là thực thể sở hữu các Ứng dụng.
  • Họ có một hồ sơ với thông tin liên hệ (email, tên).

Hãy nghĩ về họ như là "người nắm giữ tài khoản" cho đăng ký truyền hình cáp.

Ví dụ:

  • Tên nhà phát triển: Jane Smith
  • Email: jane.smith@example.com
  • Công ty: Cool Mobile Apps Inc.

3. Ứng dụng

Một Ứng dụng là một dự án hoặc ứng dụng cụ thể do một Nhà phát triển tạo ra cần gọi API của bạn. Một Nhà phát triển có thể có nhiều Ứng dụng (ví dụ: một ứng dụng iOS và một ứng dụng Android).

  • Ứng dụng là thực thể được cấp quyền truy cập vào Sản phẩm API.
  • Khi một Ứng dụng được phê duyệt cho một Sản phẩm API, Apigee sẽ tạo ra thông tin xác thực (khóa API) cho nó.

Hãy nghĩ về nó như là "chiếc hộp set-top" trong một phòng cụ thể. Người nắm giữ tài khoản (Nhà phát triển) có thể có nhiều hộp set-top (Ứng dụng), mỗi hộp có điều khiển riêng (khóa API), tất cả dưới cùng một gói đăng ký (Sản phẩm API).

Ví dụ:
Nhà phát triển Jane Smith tạo ra hai ứng dụng:

  • Tên ứng dụng: Weather-Widget-iOS
    • Mục đích: Ứng dụng thời tiết iOS của công ty cô ấy.
  • Tên ứng dụng: Weather-Widget-Android
    • Mục đích: Ứng dụng thời tiết Android của công ty cô ấy.

4. Khóa API

Khóa API là một chuỗi duy nhất (như một mật khẩu) được tạo ra cho một Ứng dụng cụ thể. Đây là mã xác thực bí mật phải được trình bày trong mọi yêu cầu API gửi đến Apigee (thường ở trong tiêu đề x-apikey hoặc dưới dạng tham số truy vấn).

  • Apigee xác thực khóa này để:
    1. Xác thực: Đây có phải là một khóa tôi đã phát hành không? Nó có hoạt động không?
    2. Ủy quyền: Ứng dụng sở hữu khóa này có quyền truy cập vào Sản phẩm API cụ thể chứa proxy API được yêu cầu không?

Hãy nghĩ về nó như là "tín hiệu duy nhất" hoặc "thẻ xác thực" cho chiếc hộp set-top cụ thể đó (Ứng dụng). Nếu không có nó, bạn không thể truy cập các kênh (API) mà bạn đã đăng ký.

Ví dụ:

  • Đối với Ứng dụng Weather-Widget-iOS, Apigee tạo:

    • Khóa API: Rz4uP91KQ2m5cLb3Fv6Hs8dJqA0xWnEy

  • Khóa này được cấu hình trong mã của ứng dụng. Mỗi cuộc gọi API đều bao gồm nó:

    Copy 
    curl -H "x-apikey: Rz4uP91KQ2m5cLb3Fv6Hs8dJqA0xWnEy" \
  "https://companyx.apigee.net/v1/weather/forecast?city=London"

Cách Tất Cả Kết Nối Với Nhau: Một Ví Dụ Thực Tế

Hãy cùng đi qua toàn bộ vòng đời.

Bước 1: Nhà cung cấp API (Bạn) tạo Sản phẩm API.

  • Bạn tạo Công tyX-Mức miễn phí và Công tyX-Thời tiết cao cấp.

Bước 2: Nhà phát triển (Jane) đăng ký.

  • Jane đăng ký trên dev.companyx.com và tài khoản của cô ấy được tạo.

Bước 3: Nhà phát triển (Jane) tạo một Ứng dụng.

  • Jane đăng nhập, vào bảng điều khiển của mình và nhấp vào "Ứng dụng mới".
  • Cô ấy đặt tên cho nó là Weather-Widget-iOS.
  • Cô ấy đánh dấu ô để yêu cầu quyền truy cập vào sản phẩm Công tyX-Mức miễn phí.

Bước 4: Nhà cung cấp API (Bạn) phê duyệt yêu cầu.

  • (Điều này cũng có thể là tự động). Bạn phê duyệt quyền truy cập của ứng dụng cô ấy vào mức miễn phí.

Bước 5: Apigee tạo thông tin xác thực.

  • Trong bảng điều khiển nhà phát triển của Jane, bây giờ cô ấy có thể thấy ứng dụng Weather-Widget-iOS.
  • Trên trang chi tiết của nó, một khóa API mới (ví dụ: Rz4uP91KQ2m5cLb3Fv6Hs8dJqA0xWnEy) được hiển thị. Khóa này được tự động phê duyệt cho sản phẩm Công tyX-Mức miễn phí.

Bước 6: Ứng dụng thực hiện một cuộc gọi.

  • Nhà phát triển iOS của Jane viết mã ứng dụng để bao gồm khóa API trong tất cả các yêu cầu.
  • Ứng dụng gọi: https://companyx.apigee.net/v1/weather/forecast?city=London

Bước 7: Apigee xác thực cuộc gọi.
Khi yêu cầu đến Apigee, nó thực hiện các kiểm tra gần như ngay lập tức:

  1. "Khóa Rz4uP91KQ2m5cLb3Fv6Hs8dJqA0xWnEy có hợp lệ và hoạt động không?" -> Có, nó thuộc về ứng dụng Weather-Widget-iOS.
  2. "Ứng dụng này được phê duyệt cho sản phẩm API nào?" -> Công tyX-Mức miễn phí.
  3. "Sản phẩm Công tyX-Mức miễn phí có bao gồm proxy và đường dẫn đang gọi (/v1/weather/forecast) không?" -> Có, nó bao gồm proxy weather-api.
  4. "Ứng dụng đã vượt quá hạn mức của nó (100/ngày) chưa?" -> Không, nó chỉ thực hiện 50 cuộc gọi hôm nay.
  5. ✅ Kiểm tra thành công! Yêu cầu được chuyển tiếp đến dịch vụ thời tiết phía sau.

Nếu Jane cố gắng gọi một điểm cuối cao cấp như /v1/weather/historical, bước 3 sẽ thất bại vì sản phẩm Công tyX-Mức miễn phí của cô ấy không bao gồm điểm cuối đó. Apigee sẽ chặn yêu cầu và trả về lỗi 403 Forbidden.

Mô hình này cung cấp một cách quản lý và kiếm tiền từ quyền truy cập API mạnh mẽ, linh hoạt và có thể kiểm tra.

Dưới đây là các biểu đồ luồng giúp hình dung mối quan hệ giữa Sản phẩm API, Nhà phát triển, Ứng dụng và Khóa API trong Apigee, từ cả góc độ của nhà cung cấp và người tiêu dùng.

Biểu đồ 1: Góc nhìn quản trị của nhà cung cấp (Cách thức xây dựng)

Copy 
flowchart TD
    A[Nhà cung cấp API] --> B[Tạo proxy API]

    subgraph Proxy [Dịch vụ phía sau]
        B1[weather-api]
        B2[news-api]
        B3[payment-api]
    end

    B --> Proxy

    Proxy --> C[Gói thành Sản phẩm API]

    subgraph Sản phẩm [Sản phẩm API - Các 'Gói']
        P1[Mức miễn phí]<br>Bao gồm: B1, B2<br>Hạn mức: 100/ngày
        P2[Thời tiết cao cấp]<br>Bao gồm: B1 tất cả các điểm cuối<br>Hạn mức: 10,000/ngày
    end

    C --> Sản phẩm
    Sản phẩm --> D[Công bố trên cổng thông tin nhà phát triển]
    D --> E[Các nhà phát triển khám phá & đăng ký]

Biểu đồ 2: Hành trình của người tiêu dùng (Cách thức cấp quyền)

Copy 
flowchart TD
    A[Nhà phát triển] --> B[Đăng ký trên cổng thông tin nhà phát triển]
    B --> C[Tạo một 'Ứng dụng' ví dụ: Weather-Widget-iOS]
    C --> D[Yêu cầu quyền truy cập vào một Sản phẩm API ví dụ: Mức miễn phí]
    D --> E{Phê duyệt của nhà cung cấp<br>Tự động hoặc Thủ công}
    E -- Được phê duyệt --> F
    E -- Bị từ chối --> G[Truy cập bị từ chối]
    F[Apigee Tạo Khóa API Duy nhất cho ứng dụng đó] --> H[Nhà phát triển nhúng Khóa vào mã ứng dụng]
    H --> I[Ứng dụng thực hiện cuộc gọi API với Khóa]
    I --> J{Xác minh Apigee}

    subgraph J [Các bước xác minh]
        J1[Khóa có hợp lệ?]
        J2[Sản phẩm đã được phê duyệt?]
        J3[Đường dẫn URL có bao gồm không?]
        J4[Có hạn mức khả dụng không?]
    end

    J -- Tất cả các kiểm tra đều thành công --> K[Yêu cầu được chuyển tiếp đến dịch vụ phía sau]
    J -- Bất kỳ kiểm tra nào thất bại --> L[Lỗi ví dụ: 403 Forbidden]

Biểu đồ 3: Luồng yêu cầu tại thời gian chạy (Những gì xảy ra trong mỗi cuộc gọi API)

Copy 
flowchart LR
    A[Yêu cầu API đến<br>với Khóa API] --> B{Xác minh Khóa API}
    B -- Không hợp lệ/Đã thu hồi --> C[Chặn yêu cầu: 401 Unauthorized]
    B -- Hợp lệ --> D[Tìm kiếm Thông tin Ứng dụng & Nhà phát triển]
    D --> E{Kiểm tra Quyền truy cập Sản phẩm API}
    E -- Sản phẩm chưa được phê duyệt<br>cho URL này --> F[Chặn yêu cầu: 403 Forbidden]
    E -- Sản phẩm đã được phê duyệt --> G{Kiểm tra Hạn mức & Giới hạn Tốc độ}
    G -- Hạn mức đã vượt quá --> H[Chặn yêu cầu: 429 Quá nhiều yêu cầu]
    G -- Hạn mức khả dụng --> I[Cho phép yêu cầu đến dịch vụ phía sau]
    I --> J[Ghi lại Dữ liệu Phân tích<br>ví dụ: cho Ứng dụng, Nhà phát triển, Sản phẩm]

Mối Quan Hệ Chính Được Hình Thành

Mối quan hệ cốt lõi giữa các thực thể có thể được tóm tắt trong cấu trúc phân cấp này:

Copy 
Sản phẩm API (Gói)
    ^
    | chứa
    |
Proxy API (Kênh)
    ^
    | được truy cập thông qua
    |
Ứng dụng (Chiếc hộp set-top)
    ^
    | sở hữu
    |
Nhà phát triển (Người nắm giữ tài khoản)
    ^
    | sử dụng
    |
Khóa API (Tín hiệu/Mật khẩu)

Điều này cho thấy rằng một Sản phẩm API bao gồm Proxy. Một Ứng dụng (do một Nhà phát triển sở hữu) được phê duyệt cho một sản phẩm. Khóa API là thông tin xác thực cho ứng dụng cụ thể đó, cấp quyền cho nó quyền truy cập vào sản phẩm mà nó được phê duyệt.

Xem quảng cáo để đọc tiếpHoặc nâng cấp tài khoản để tắt quảng cáo

Nội dung bài viết

Gợi ý câu hỏi phỏng vấn
Không có dữ liệu

Không có dữ liệu

Bài viết được đề xuất
Bài viết cùng tác giả

Bình luận

Chưa có bình luận nào

Chưa có bình luận nào