API Key là gì? Cách hoạt động và cách bảo vệ nó

Scrapeless Scraping API xác thực các yêu cầu thông qua tiêu đề x-api-token, nơi một API key của tài khoản Scrapeless xác định khách hàng gọi.

API Key là gì?

API key là một giá trị mà nhà cung cấp API cấp cho một khách hàng phần mềm, dự án, tài khoản hoặc tích hợp. Khách hàng sẽ bao gồm key trong một yêu cầu. Cổng API hoặc ứng dụng sẽ tra cứu thông tin xác thực, kiểm tra trạng thái và hạn chế của nó, áp dụng chính sách và liên kết yêu cầu với một chủ sở hữu để mục đích truy cập, sử dụng và kiểm toán.

Từ “key” có thể gây hiểu lầm. Một API key không nhất thiết là một key mật mã được sử dụng để mã hóa hoặc ký dữ liệu. Trong nhiều hệ thống, nó là một thông tin xác thực ngẫu nhiên không minh bạch. Một số thiết kế sử dụng một định danh công khai cộng với một thành phần bí mật; những thiết kế khác mã hóa một tiền tố có thể nhận diện mà giúp các nhà vận hành xác định loại thông tin xác thực mà không tiết lộ bí mật.

API key rất phổ biến cho các API server-to-server, công cụ phát triển, dịch vụ dữ liệu, bản đồ, nhắn tin, tự động hóa và dịch vụ nội bộ. Sức hấp dẫn của chúng là tính đơn giản trong vận hành: khách hàng gửi một thông tin xác thực, và nhà cung cấp có thể quy thuộc cuộc gọi. Tính đơn giản đó chỉ an toàn khi key được tạo ra với đủ độ ngẫu nhiên, được truyền một cách an toàn, được lưu trữ như một bí mật và bị giới hạn với quyền hạn sử dụng nhỏ nhất.

Cách hoạt động của xác thực API Key

1. Nhà cung cấp phát hành một thông tin xác thực. Một bảng điều khiển hoặc API quản trị tạo một key cho một dự án có tên, tài khoản dịch vụ hoặc tích hợp.
2. Khách hàng lưu trữ bí mật. Các ứng dụng máy chủ đọc nó từ một trình quản lý bí mật, môi trường bảo vệ hoặc một cửa hàng thông tin xác thực được phê duyệt khác.
3. Khách hàng gửi một yêu cầu. Key thường xuất hiện trong một tiêu đề HTTP qua TLS.
4. Dịch vụ giải quyết key. Một định danh key hoặc tra cứu an toàn tìm thấy bản ghi thông tin xác thực đã lưu mà không tiết lộ các bí mật không liên quan.
5. Dịch vụ đánh giá chính sách. Nó kiểm tra trạng thái hoạt động, phạm vi, hạn chế tài nguyên, điều kiện mạng, hạn ngạch và các kiểm soát khác.
6. Dịch vụ ghi lại dữ liệu kiểm toán an toàn. Nhật ký sử dụng ID key hoặc dấu vân tay, không phải toàn bộ bí mật, để quy thuộc hoạt động.

Một yêu cầu có thể được xác thực nhưng không được ủy quyền. Xác thực trả lời khách hàng nào đã trình bày thông tin xác thực. Ủy quyền trả lời liệu khách hàng đó có thể thực hiện hành động này trên tài nguyên này hay không. Một dịch vụ nên đưa ra cả hai quyết định một cách rõ ràng.

Nơi nào nên gửi một API Key?

Một tiêu đề cụ thể cho API hoặc tiêu đề tiêu chuẩn Authorization thường là vị trí đúng. Scrapeless Scraping API sử dụng hình dạng tiêu đề này:

x-api-token: REDACTED

Yêu cầu phải sử dụng HTTPS để việc truyền tải bảo vệ các tiêu đề khỏi việc quan sát mạng thụ động và xác thực máy chủ. TLS không bảo vệ một key sau khi nó đến nhật ký ứng dụng, dấu vết gỡ lỗi, tiện ích mở rộng trình duyệt hoặc các điểm cuối bị xâm phạm, do đó việc lưu trữ và kiểm soát khả năng quan sát vẫn cần thiết.

Bảng Hướng dẫn về bảo mật REST của OWASP khuyên không nên đặt các API key và các mã bảo mật khác trong URLs vì URLs bị nhiều hệ thống ghi lại. Xác thực chuỗi truy vấn có thể tồn tại để tương thích, nhưng một API mới nên ưu tiên tiêu đề.

Một API Key có thể và không thể chứng minh điều gì

Một key hợp lệ chứng minh rằng người gọi sở hữu thông tin xác thực đó tại thời điểm yêu cầu. Nó không chứng minh ai đã khởi tạo yêu cầu, liệu thiết bị có đáng tin cậy hay không, hoặc liệu phần mềm trình bày key có phải là phần mềm đã dự định hay không. Một key đã sao chép thường có thể được phát lại từ một máy khác trừ khi nhà cung cấp thêm các hạn chế hoặc chứng minh gắn liền với người gửi.

Các key nhúng trong các trang web công khai, nhị phân máy tính để bàn, tiện ích mở rộng trình duyệt và ứng dụng di động không thể được giữ làm bí mật bền vững vì người dùng kiểm soát những môi trường đó. Việc che giấu có thể làm chậm việc phát hiện nhưng không thay đổi mô hình tin cậy. Các khách hàng công khai nên gọi một backend được kiểm soát hoặc sử dụng một thiết kế ủy quyền được tạo ra cho phần mềm công khai.

Một API key cũng không nên thay thế quyền truy cập cấp độ người dùng cho các tài nguyên nhạy cảm. Nếu mỗi hành động của người dùng chia sẻ một key dự án thì dịch vụ không thể phân biệt đáng tin cậy giữa sự đồng ý, vai trò hoặc thu hồi của từng cá nhân. Xác thực và ủy quyền người dùng thuộc về một lớp riêng.

API Key so với OAuth so với Bearer Token

Những loại này chồng chéo lên nhau. Một mã thông hành truy cập OAuth thường được sử dụng như một mã thông hành bearer. Một khóa API cũng có thể được trình bày với một sơ đồ bearer, mặc dù trình bày đó không biến hệ thống thành OAuth. Một JWT có thể được sử dụng như một mã thông hành bearer, nhưng mã thông hành bearer không minh bạch cũng phổ biến.

Thiết kế Khóa API

Một khóa được thiết kế tốt được tạo ra từ một nguồn ngẫu nhiên bảo mật mã hóa và đủ dài để chống lại việc đoán. Giá trị không nên mã hóa dữ liệu tài khoản nhạy cảm. Một tiền tố dễ nhận biết có thể giúp các công cụ quét bí mật và người vận hành nhận diện nhà cung cấp và loại chứng chỉ, nhưng phần không thể đoán phải mang lại sự bảo mật.

Nhiều dịch vụ chỉ hiển thị bí mật đầy đủ một lần. Hệ thống phía sau lưu trữ một xác minh một chiều hoặc một biểu diễn bí mật được bảo vệ thay vì giữ mọi chứng chỉ văn bản rõ sẵn có để hiển thị. Một ID khóa không bí mật riêng hỗ trợ tìm kiếm, đăng nhập và quản lý.

Hệ thống nên cho phép nhiều khóa hoạt động cho mỗi dự án để các triển khai có thể thay đổi chứng chỉ mà không cần một bí mật chung trên mọi môi trường. Mỗi khóa cần có tên, chủ sở hữu, sự kiện tạo, thông tin lần sử dụng cuối, các hạn chế và kiểm soát thu hồi.

Cách lưu trữ khóa API

Các dịch vụ sản xuất nên truy xuất khóa từ một hệ thống quản lý bí mật tập trung hoặc một kho bí mật trên nền tảng được phê duyệt. Quyền truy cập nên được giới hạn cho danh tính công việc cần bí mật. Quyền truy cập của con người, xuất khẩu và thay đổi quản trị nên có thể kiểm tra.

Bảng cheat lỗi quản lý bí mật của OWASP bao gồm lưu trữ trung tâm, cung cấp, kiểm tra, quay vòng và kiểm soát vòng đời. Biến môi trường có thể là một cơ chế phân phối, nhưng chúng không tự động riêng tư: kiểm tra quy trình, báo cáo sự cố, nhật ký xây dựng, hoặc các chẩn đoán cẩu thả có thể tiết lộ chúng.

Đừng cam kết các khóa trong kiểm soát nguồn, đặt chúng trong hình ảnh chứa, dán chúng vào các trình theo dõi sự cố, hoặc chia sẻ chúng qua chat. Mục CWE-798 về các chứng chỉ mã cứng giải thích tại sao các chứng chỉ nhúng trong phần mềm tạo ra sự tiếp xúc rộng rãi và khó thay đổi.

Giới hạn và Hạn chế

Một khóa nên chỉ cấp quyền cho các API, hoạt động, tài nguyên và môi trường mà công việc của nó cần. Tách biệt các chứng chỉ phát triển, staging và sản xuất. Sử dụng quyền chỉ đọc khi một quy trình không bao giờ ghi. Giới hạn hạn mức để một lỗ hổng không thể tạo ra chi phí hoặc lưu lượng không giới hạn.

Các hạn chế mạng, nguồn gốc cho phép, chữ ký ứng dụng, hoặc danh tính dịch vụ có thể thêm bối cảnh hữu ích, nhưng mỗi kiểm soát đều có giới hạn. Các quy tắc IP nguồn khó áp dụng cho mạng di động và chia sẻ đầu ra. Các hạn chế nguồn gốc trình duyệt chỉ bảo vệ các luồng trình duyệt tham gia và không khiến một khóa bị rò rỉ trở nên bí mật. Đối xử với các hạn chế như là các lớp, không phải là sự thay thế cho việc bảo vệ chứng chỉ.

Quay vòng và Thu hồi

Quay vòng thay thế một chứng chỉ cũ bằng chứng chỉ mới. Một quy trình an toàn tạo ra một khóa thứ hai, cập nhật công việc thông qua con đường giao hàng bí mật, xác nhận lưu lượng dưới ID khóa mới, và sau đó thu hồi khóa cũ. Hỗ trợ nhiều khóa ngăn ngừa việc triển khai đồng thời ép buộc trên mọi phiên bản.

Thu hồi một khóa ngay lập tức khi nghi ngờ có rò rỉ, một chủ sở hữu rời đi, một tích hợp bị ngừng, hoặc chứng chỉ không còn lý do chính đáng. Việc xử lý sự cố nên xác định tài nguyên và hành động bị ảnh hưởng thông qua các bản ghi kiểm tra an toàn, sau đó xem xét cách giá trị đã thoát ra để có thể sửa chữa con đường giao hàng.

Hết hạn giới hạn tuổi thọ của các chứng chỉ bị quên lãng. Thời hạn sử dụng ngắn chỉ hữu ích nếu việc gia hạn được tự động hóa và theo dõi. Một hệ thống mà lặng lẽ thay thế các khóa hết hạn bằng các chứng chỉ khẩn cấp vĩnh viễn làm suy yếu kiểm soát.

Giám sát mà không rò rỉ khóa

Nhật ký nên ghi lại một ID khóa không bí mật, dự án, quyết định, điểm cuối, loại phản hồi, dấu thời gian và ID tương quan yêu cầu. Không bao giờ viết toàn bộ khóa. Việc xóa thông tin cần thực hiện trước khi dữ liệu rời khỏi quá trình ứng dụng và nên bao trùm tiêu đề, tin nhắn ngoại lệ, dấu vết và các gói hỗ trợ.

Cảnh báo về các điểm cuối, khu vực, lưu lượng truy cập không bình thường, mẫu lỗi, và việc sử dụng từ một môi trường không phù hợp với mục đích của khóa. Dấu thời gian lần cuối sử dụng giúp tìm kiếm các khóa bị ngủ quên, nhưng việc thiếu sử dụng quan sát nên được xác nhận trước khi thu hồi vì việc giám sát có thể không đầy đủ.

Những lỗi thông dụng về Khóa API

• Một khóa cho mọi môi trường. Một rò rỉ phát triển có thể ảnh hưởng đến sản xuất.
• Các khóa trong URL. Chuỗi truy vấn lan truyền qua các nhật ký, phân tích, lịch sử trình duyệt và người giới thiệu.
• Các khóa trong mã phía trước. Các khách hàng công khai không thể bảo vệ một bí mật chia sẻ lâu dài.
• Chứng chỉ vĩnh viễn không giới hạn. Quyền lực thừa mở rộng tác động của việc tiết lộ.
• Bí mật đầy đủ trong nhật ký. Các hệ thống quan sát trung tâm trở thành nơi lưu trữ thông tin xác thực.
• Không có chủ sở hữu hoặc mục đích. Không ai biết liệu một khóa cũ có còn cần thiết nữa không.
• Chuyển đổi loại tự động im lặng. Xử lý một khóa như một số có thể thay đổi ký tự đầu hoặc độ chính xác; thông tin xác thực là chuỗi không rõ.

Khi nào sử dụng Khóa API

Kết luận

Khóa API là một thông tin xác thực đơn giản để xác định một khách hàng phần mềm hoặc dự án. Chuỗi này chỉ là một phần của hệ thống. Bảo mật đến từ việc tạo ra gây nhầm lẫn cao, vận chuyển TLS dựa trên tiêu đề, phạm vi hẹp, lưu trữ được bảo vệ, ghi nhật ký an toàn, sử dụng được quan sát, luân chuyển được kế hoạch và thu hồi ngay lập tức. Khóa API phù hợp với quyền truy cập ứng dụng được kiểm soát; chúng không nên bị kéo dài vào một hệ thống ủy quyền người dùng hoặc nhúng nơi mà một khách hàng công khai có thể tiết lộ chúng.