Làm cách nào tôi có thể không khuyến khích chia sẻ các khóa API nội bộ trong một công ty?

Chúng tôi đang làm việc trên một dịch vụ mới - dịch vụ này có khả năng sẽ được gọi trực tiếp từ các ứng dụng trên thiết bị người dùng. Các ứng dụng này sẽ được phát triển và hỗ trợ bởi nhiều nhóm phát triển từ khắp nơi trong tổ chức, tất cả tùy thuộc vào dữ liệu chúng tôi cung cấp.

Chúng tôi muốn xác định ứng dụng nào đang gửi yêu cầu nào, để chúng tôi có thể xác định các kiểu sử dụng và nhà phát triển chịu trách nhiệm. (Để tránh nghi ngờ, xác thực người dùng được xử lý riêng.)

Giải pháp của chúng tôi là yêu cầu các khóa API, mỗi khóa cho một ứng dụng - sau đó chúng tôi có chi tiết liên hệ cho nhóm phát triển.

Chúng tôi không muốn các khóa API trở thành một nguồn ma sát, nhưng chúng tôi lo ngại rằng các nhà phát triển sẽ chia sẻ chúng cho các đồng nghiệp trong các nhóm khác, có nghĩa là chúng tôi không còn có thể xác định lưu lượng truy cập cho chỉ một ứng dụng.

Làm cách nào chúng tôi có thể khuyến khích các nhà phát triển không chia sẻ khóa API trong nội bộ?

Để chia sẻ những chìa khóa đó giữa các đội, các đội cần nói chuyện với nhau, đồng ý chia sẻ, sau đó chia sẻ chúng. Điều này cần có thời gian. Vì vậy, nếu một nhóm có thể yêu cầu khóa API từ bạn nhanh hơn và dễ dàng hơn, không có động lực để chia sẻ.

Và cách dễ nhất để họ yêu cầu các khóa đó là bạn phải lấy trước chúng. Giả sử bạn biết tất cả các nhóm khác sẽ cần khóa API, tạo chúng và chia sẻ chúng trước khi cung cấp dịch vụ cho họ.

Có một ưu đãi khác mà bạn có thể cung cấp: hỗ trợ gỡ lỗi. Những nhóm đó sẽ muốn sự giúp đỡ của bạn khi mọi thứ không hoạt động tốt khi họ tích hợp công việc của họ với dịch vụ của bạn. Các khóa API đó cho phép bạn theo dõi các yêu cầu cụ thể của chúng và do đó hỗ trợ gỡ lỗi những gì đang xảy ra. Vì vậy, hãy bán nó như là lý do cho các khóa, thay vì " xác định mô hình sử dụng và nhà phát triển chịu trách nhiệm ", có vẻ như bạn đang theo dõi các hoạt động của họ.

Đã có câu trả lời tốt, tôi chỉ nghĩ về một cách tiếp cận khác có thể có hoặc không hiệu quả với bạn.

Thay vì đưa ra các khóa được bao gồm, bạn có thể yêu cầu tiêu đề yêu cầu bao gồm tên của ứng dụng giao diện người dùng, được tạo và định dạng bởi nhà phát triển ứng dụng giao diện người dùng, giống như các trình duyệt web. Theo cách đó, front end vẫn có thể giả vờ là một ứng dụng khác nhưng sẽ không có lợi khi làm điều đó nên dường như không thể. Chỉ cần để giao diện người dùng tự xác định và chấp nhận bất kỳ chuỗi không trống nào.

Nói ngắn gọn:

Thứ nhất: tạo thuận lợi và lợi ích; Nếu cần thiết: ma sát và cảnh sát.

Một số từ nữa

Tạo điều kiện : Đầu tiên, giúp nhóm dễ dàng lấy khóa API mới. Chẳng hạn, thêm một lời nhắc trong các thủ tục của công ty để khởi động các dự án mới và cung cấp một dịch vụ dễ sử dụng để yêu cầu khóa mới, mà không yêu cầu biện minh.

Lợi ích : Làm cho việc sử dụng khóa API riêng trở thành lợi ích cho nhóm hoặc chủ sở hữu sản phẩm. Ví dụ: đề xuất một số phản hồi về việc sử dụng ứng dụng dựa trên khóa đó.

Ma sát : Tùy thuộc vào tính năng khóa, bạn có thể tạo ma sát, ví dụ: nếu khóa được liên kết với miền xác định ứng dụng somme (nghĩa là sử dụng lại khóa sẽ không nhất thiết phải cấp quyền truy cập vào tất cả các dịch vụ mong muốn).

Chính sách : Cuối cùng, bạn có thể cần phải thấy trước một số biện pháp kiểm soát. Ví dụ: bạn có thể giám sát việc sử dụng các chức năng api bằng khóa api và sau một thời gian nhất định để thiết lập đường cơ sở, yêu cầu về việc sử dụng các phần api không được mong đợi theo quan điểm của đường cơ sở. Hoặc nếu điều này không thực tế, chỉ cần đưa vào danh sách kiểm tra đánh giá dự án của công ty để xác minh rằng khóa hợp lệ đã được sử dụng.

Lưu ý : bạn có thể cần phải rất rõ ràng về chính sách khóa API của mình: Phiên bản chính mới có yêu cầu khóa API riêng không? Điều gì với một ngã ba, hoặc nếu một ứng dụng được tách ra? Điều gì xảy ra nếu một đội khác phụ trách, v.v ...

Nói chung, cách dễ nhất để khiến các nhà phát triển "làm điều đúng đắn", là làm cho họ dễ dàng làm điều đó.

Vì vậy, tôi sẽ đề nghị xây dựng một trang web / trang web phát hành khóa API. Ở dạng đơn giản nhất, nó có thể chỉ là một thông tin đăng nhập (lý tưởng nhất là gắn với AD / LDAP của công ty bạn) và trang chỉ yêu cầu tên ứng dụng và cấp khóa.

Vào cuối ngày, bạn luôn có thể thu hồi các khóa sau đó, vì vậy tất cả những gì bạn thực sự cần trang web là ghi lại ai (tên người dùng) đã yêu cầu khóa và họ (Tên ứng dụng) họ muốn làm gì với nó - cùng với bất kỳ thông tin nào cần thiết để thu hồi chìa khóa sau.

Bạn có thể làm điều gì đó tương tự với hệ thống bán vé, nhưng vào cuối ngày, tôi rất dễ dàng sao chép và dán khóa từ ứng dụng này sang ứng dụng khác, vì vậy việc yêu cầu một khóa mới là rất dễ dàng, để tránh điều xấu hành vi.

Được chủ động.

Xác định các nhà phát triển có khả năng và GIVE cho họ các khóa API duy nhất trong một kênh an toàn, trước thời hạn. Cung cấp một phương tiện dễ dàng để yêu cầu các khóa API mới. Cung cấp một phương tiện dễ dàng cho những người mới yêu cầu khóa API mới. Khi thực tập sinh hoặc tuyển dụng mới tham gia nhóm, hãy đưa cho họ một vé JIRA hoặc "Yêu cầu khóa API" tương tự với các bước trong mô tả.

Theo dõi những khóa API nào đã được sử dụng và những khóa nào chưa được sử dụng. Nếu Bob đã gửi vé trong dự án nhưng không sử dụng các khóa API của anh ấy, thì có lẽ anh ấy đã mượn của người khác.

Có sự hỗ trợ của ban quản lý. Đừng là một Nosy Nancy sẽ thực hiện bất kỳ quy tắc nào không quan trọng. Nghĩa đen là thuyết phục Quản lý rằng điều đó quan trọng, và sau đó họ là người thuyết phục nhóm rằng điều đó quan trọng. Đừng cố thuyết phục mọi người.

Và gợi ý khó chịu và chuyên chế nhất: Hãy nhận thức được việc sử dụng sai, và trấn áp cùng một ngày. Cùng một giờ là tốt nhất. Đừng nói "Nhà phát triển nghịch ngợm xấu" nói "Đây là các bước thích hợp." Nếu họ làm điều đó nhiều lần, hãy vô hiệu hóa khóa sử dụng sai. Điều này gây rắc rối cho cả Sharer và One Who Borrowed, và người chia sẻ sẽ nói "Không, làm điều đó đúng" trong tương lai. Tránh vô hiệu hóa các khóa trong các dự án trực tiếp.

Làm cách nào chúng tôi có thể khuyến khích các nhà phát triển không chia sẻ khóa API trong nội bộ?

• Tạo khóa là kết quả của việc đăng ký ứng dụng tự phục vụ .
• Yêu cầu một điểm liên lạc trước khi các phím được kích hoạt.
• Và yêu cầu họ không chia sẻ. (Tạo điều khoản dịch vụ và / hoặc cho họ biết lý do tại sao họ không nên chia sẻ.)

Bạn cũng nên thực hiện giới hạn tỷ lệ . Điều này tự nó có thể ngăn cản việc chia sẻ các phím. Nó bảo vệ hệ thống của bạn ở một mức độ nào đó chống lại các ứng dụng lạm dụng. (Và những thứ độc hại hoàn toàn.) Và, nó đảm bảo bạn sẽ được thông báo phần nào trước khi có sự gia tăng lớn về lưu lượng dịch vụ. (Cho bạn thời gian để thêm năng lực, tôi hy vọng!)

Và, với giới hạn tốc độ, khi một ứng dụng yêu cầu giới hạn cao hơn, nó sẽ mở hộp thoại với POC được đăng ký cho khóa. Bạn có cơ hội hỏi xem các khóa có được chia sẻ hay không, giải thích lý do tại sao điều đó có hại và v.v. và bạn có thể cung cấp các khóa bổ sung khi phù hợp thay vì thay đổi giới hạn tỷ lệ được yêu cầu. V.v.

Một cách để thực hiện, đặc biệt là nếu các nhóm sử dụng hệ thống xây dựng chung (hoặc ít nhất là đủ phổ biến) là thiết lập một máy chủ nội bộ tạo và phát hành các khóa API (cung cấp một vài thông tin cơ bản về sản phẩm sử dụng nó ). Sau đó, sử dụng tập lệnh lấy khóa API mới từ máy chủ cho mỗi bản dựng hoặc cho từng bản cập nhật. Hãy để các nhà phát triển chạy tập lệnh để có được một khóa khác cho các bản dựng cục bộ của họ. (Nếu có thể, hãy tự động hóa điều này như một phần của bản dựng để họ thậm chí không cần phải suy nghĩ về nó.)

Điều này sẽ cho bạn biết liệu đó là thứ gì đó trong sản xuất, QA hay dev và ở phiên bản / bản dựng nào thì các vấn đề bắt đầu.

Điều đầu tiên và tốt nhất bạn có thể làm là định dạng các khóa sao cho chúng bao gồm tên ứng dụng ở dạng dễ đọc và không hoạt động nếu bạn thay đổi nó.

Nếu rõ ràng khi các đội đang sử dụng khóa sai, thì họ sẽ không cố gắng.

Sau đó, định kỳ hết hạn khóa. Dù sao thì bạn cũng nên làm điều này và khi một khóa sắp hết hạn, bạn có thể gửi một cái mới cho đội sở hữu nó. Đội sử dụng khóa sau đó sẽ được thúc đẩy để đảm bảo rằng họ là đội sở hữu nó, do đó họ sẽ nhận được khóa mới khi hết hạn.