6

Để thu thập thông tin chi tiết về tình trạng quản lý API hiện tại và tương lai, chúng tôi đã yêu cầu các chuyên gia CNTT từ 18 công ty chia sẻ suy nghĩ của họ. Chúng tôi hỏi họ, "Kỹ thuật và công cụ nào hiệu quả nhất để bảo mật API?" Đây là những gì họ nói với chúng tôi:

Xác thực

  • Chúng tôi thường xuyên cung cấp quyền truy cập API cho các đối tác B2B đã biết. Trong những tình huống này, khả năng giới hạn quyền truy cập API chỉ vào địa chỉ IP của đối tác (danh sách trắng) là rất mạnh mẽ. Bạn vẫn cần xác thực và giới hạn tỷ lệ, nhưng bạn đã cắt giảm lưu lượng truy cập chỉ cho các đối tác đã biết. Điều này giúp loại bỏ phần lớn lưu lượng truy cập bất chính được nhìn thấy trên các API mở ra Internet rộng lớn hơn, chẳng hạn như các nỗ lực brute force để có được quyền truy cập và các cuộc tấn công từ chối dịch vụ.
    Ngay cả khi có danh sách IP cho phép, việc có cổng API vẫn là phương pháp hay nhất. Điều này hỗ trợ xác thực và đảm bảo chương trình phụ trợ chỉ nhận các lệnh gọi API được định dạng đúng. 
  • Phổ biến nhất là OAuth và OAuth2 để giao tiếp và bảo mật thông tin liên lạc giữa các API. Bên dưới là xác thực dựa trên mã thông báo và dựa trên xác nhận quyền sở hữu trong đó các API chuyển qua lại các mã thông báo được ký điện tử để xác minh mã thông báo là đại diện cho ai đang thực hiện cuộc gọi. 
  • Việc xác thực được các nhà cung cấp thực hiện không đồng đều. Ngay cả với OAuth, cách các mã thông báo được người khác duy trì có thể là một vấn đề. Vòng đời của mã thông báo được quản lý như thế nào? Các mã thông báo có được làm mới không? Trong cơ sở hạ tầng của riêng chúng tôi, chúng tôi sử dụng mã thông báo một lần trong phạm vi rộng rãi cho loại hoạt động mà chúng tôi đang cố gắng thực hiện. Nó đi xuống để quản lý mã thông báo an toàn và xác thực dựa trên chứng nhận. 
  • Luôn xác thực API trước khi Ủy quyền -  Có nhiều cách để thực hiện xác thực API, nhưng xác thực đa yếu tố là cách tiếp cận thường được khuyến nghị. Đối với các API, việc lấy mã thông báo truy cập bằng quy trình bên ngoài, ví dụ như thông qua giao thức OAuth là khá phổ biến. Khóa xác thực là nhạy cảm nhất và phải được giữ an toàn; tuy nhiên, nên sử dụng cửa hàng quản lý để tự động hóa toàn bộ quy trình.
    Điều đó nói rằng, chỉ xác thực không đủ để cấp quyền truy cập vào API, cần phải có một bước ủy quyền để xác định những tài nguyên nào có quyền truy cập vào API. Có nhiều cách khác nhau để kiểm tra ủy quyền phù hợp bao gồm kiểm soát truy cập dựa trên nội dung (CBAC), kiểm soát truy cập dựa trên vai trò (RBAC) hoặc kiểm soát truy cập dựa trên chính sách (PBAC) - những phương pháp này đảm bảo dữ liệu kinh doanh vẫn được bảo vệ đầy đủ trước quyền truy cập không được phê duyệt. 

Giới hạn tỷ lệ

  • Bảo mật môi trường API liên quan đến mọi điểm tiếp xúc API - xác thực và ủy quyền các ứng dụng khách API (ứng dụng bên thứ ba và nhà phát triển hoặc dịch vụ vi mô), các lệnh gọi API giới hạn tốc độ để giảm thiểu các cuộc tấn công từ chối dịch vụ (DDoS) phân tán và bảo vệ các ứng dụng phụ trợ xử lý Lệnh gọi API.
    Một số kỹ thuật và công cụ để bảo mật API là: 
    1)  Sử dụng Mã thông báo web JSON (JWT) trong việc xác thực và cấp phép cho ứng dụng khách API - những mã thông báo này bao gồm thông tin về máy khách như đặc quyền quản trị hoặc ngày hết hạn. Khi khách hàng trình bày một JWT với yêu cầu API của nó, cổng API xác thực JWT và xác minh rằng các xác nhận quyền sở hữu trong nó phù hợp với chính sách truy cập mà bạn đã đặt cho tài nguyên mà khách hàng đang yêu cầu.
    2)Xác định và triển khai các chính sách kiểm soát truy cập chỉ cho phép một số loại khách hàng thực hiện thao tác ghi hoặc truy cập dữ liệu nhạy cảm như giá cả.
    3)  Xác định kiểm soát truy cập dựa trên vai trò chỉ cho phép một số người dùng nhất định (chẳng hạn như các nhà phát triển trong một tổ chức cụ thể) xuất bản các API để lộ thông tin nhạy cảm như giá cả hoặc mức tồn kho.
    4) Tự  bảo mật các API bằng cách áp dụng chính sách giới hạn tốc độ đặt ngưỡng về số lượng yêu cầu mà cổng API chấp nhận mỗi giây (hoặc khoảng thời gian khác) từ một nguồn được chỉ định, chẳng hạn như địa chỉ IP của máy khách.
    5)  Bảo vệ các ứng dụng phụ trợ bằng HTTPS - Giao thức HTTPS nên được sử dụng lưu lượng truy cập giữa cổng API và hệ thống phụ trợ xử lý các yêu cầu API. 
  • Circuit Breakers - Throttling and Quotas -  Một phương pháp hay là thực thi hạn ngạch sử dụng dữ liệu cho mỗi ứng dụng để phần phụ trợ không bị ảnh hưởng trong trường hợp tấn công DoS, DDoS hoặc để ngăn người dùng trái phép sử dụng API không đúng cách. Điều chỉnh và hạn ngạch trên mỗi tài nguyên không chỉ hoạt động như một bộ ngắt mạch mà còn có thể ngăn chặn tác động tiêu cực đến các hệ thống hạ nguồn trong quá trình sử dụng tăng đột biến không mong muốn. Một nền tảng quản lý API phức tạp với các chính sách như hạn ngạch và điều chỉnh có thể cung cấp khả năng này. 

Rộng hơn

  • Ba lĩnh vực chính trong cách tiếp cận bảo mật API của chúng tôi:
    1) Có cách tiếp cận theo quy định
    2) Suy nghĩ kỹ về cách danh tính ứng dụng được kết nối với danh tính người dùng
    3) Suy nghĩ về bảo mật API theo nghĩa rộng nhất ngoài xác thực để giảm thiểu các nỗ lực xâm nhập.
    Mô hình mô tả: Khách hàng hướng tới OAuth 2 và phủ sóng với Open ID Connect. Có rất nhiều lựa chọn được thực hiện với OAuth 2, Open ID hạn chế sự lựa chọn và hướng mọi người về các phương pháp hay nhất. Cuối cùng, tốt hơn là thực hiện một tiêu chuẩn được hiểu rõ ràng. Xem xét sự cân bằng giữa bảo mật, khả năng sử dụng và khả năng mở rộng tương tự như thế giới lưu trữ.
    Vai trò của ứng dụng và danh tính người dùng:Có một số nhà cung cấp quản lý API cố gắng làm cả hai. Nó chỉ là không thể mở rộng. Quản lý danh tính quá mạnh mẽ nên bạn không thể theo kịp tốc độ thay đổi và tiêu chuẩn mới. Chúng tôi tích hợp với các giải pháp quản lý danh tính bên ngoài và tích hợp đầy đủ các trường hợp sử dụng OAuth2 và Open ID. Chúng tôi có các giao diện mở để khách hàng có thể hoán đổi chúng tôi để triển khai riêng nếu họ muốn.
    Đối với các mối quan tâm rộng hơn về bảo mật:Chúng tôi áp dụng phương pháp phân phối việc triển khai bảo mật. Theo mặc định, quản lý API tập trung vào việc cung cấp cổng API. Chúng tôi thực hiện một cách tiếp cận mà cổng API nên tập trung vào xác thực và ủy quyền lưu lượng truy cập. Chúng tôi khuyên bạn nên thực hiện phương pháp tiếp cận nhiều lớp và bao gồm tường lửa ứng dụng web trong một lớp riêng biệt với Apache Mod Security. Khi triển khai bảo mật bổ sung để triển khai đến biên mạng. Cuối cùng là sử dụng heuristics hoặc máy học để theo dõi hành vi của lưu lượng truy cập và xác định xem lưu lượng truy cập có độc hại hay không.

Khác

  • Bảo mật quản lý API vẫn là một trong những lĩnh vực mà mọi người đang gặp khó khăn. Chúng ta cần nhận ra rằng các API vốn không an toàn. Chúng ta cần tìm hiểu lại bảo mật đối với API là gì và hiểu sự mong manh của internet đang bị tấn công. Các nhà cung cấp đám mây đã trưởng thành hơn. Các công cụ quản lý API AWS và Azure cung cấp một lớp bảo mật bổ sung. Hãy nghĩ về tính bảo mật của tên người dùng, mật khẩu, khóa và biết ai đang sử dụng các API của bạn. Bây giờ hãy nghĩ về dữ liệu mà các API đang thể hiện các hệ thống kế thừa có cùng suy nghĩ về việc bảo mật dữ liệu ở đó. Nhiều API tiêu thụ nhiều dữ liệu người dùng hơn - bạn lưu trữ như thế nào và ở đâu? 
  • API có thể là một rủi ro bảo mật theo hai cách chính. Thứ nhất, vì sự phụ thuộc giống như một bộ búp bê Nga. Bên trong các phụ thuộc của bạn là các 'phụ thuộc' ... và bên trong chúng là các phụ thuộc, các phụ thuộc ', các phụ thuộc' của bạn, vân vân và vân vân. Từ góc độ chức năng, điều này cho phép mỗi tổ chức phát triển tập trung vào mã mà họ thêm giá trị nhất.
    Tuy nhiên, từ góc độ bảo mật, với tư cách là người tiêu dùng cuối cùng, bạn thừa hưởng toàn bộ chuỗi lỗ hổng. Các nghiệp vụ bảo mật ứng dụng phải vượt ra ngoài phân tích thành phần phần mềm cơ bản, so khớp các CVE đã biết với các chuỗi phiên bản vì chúng chỉ đi sâu một lớp. Ví dụ: Jackson-databind là một thư viện nguồn mở phổ biến được tận dụng trong nhiều SDK truyền thông của bên thứ ba. 
    Lỗ hổng giải mã “jacksploit” , đã gây khó khăn cho nhiều phiên bản của thư viện, có thể khai thác được đối với một số người dùng SDK, nhưng phiên bản dễ bị tấn công của Jackson-databind đã bị SCA truyền thống làm xáo trộn và không thể xác định được. Do đó, các chuyên gia bảo mật phải tìm kiếm các công cụ đánh giá cách mã nguồn hoạt động, thay vì dựa vào việc tra cứu cơ sở dữ liệu CVE.
    Thứ hai, vì các API thường truyền dữ liệu ra bên ngoài, điều quan trọng là phải lập bản đồ các luồng dữ liệu quan trọng để đảm bảo dữ liệu quan trọng không vô tình bị rò rỉ vào chúng. Điều này có nghĩa là xác định các biến nào là quan trọng và lập bản đồ hành trình của chúng từ nguồn đến điểm chìm và tất cả các biến đổi trên đường đi. Bằng cách đó, dữ liệu quan trọng chưa được mã hóa hoặc chưa được phản hồi có thể bị bắt trong quá trình phát triển trước khi các tuyến bị rò rỉ được đưa vào sản xuất. 
  • Bạn cần có nền tảng quản lý API tốt. Nó sẽ thực thi các quy tắc và vai trò bạn đặt ra để kiểm soát ai có quyền truy cập vào dữ liệu nào. Bạn có thể sử dụng cổng hoặc nền tảng với các tùy chọn hoặc sử dụng các công cụ xác thực và ủy quyền tích hợp sẵn. Có thể kiểm soát quyền truy cập một cách thân thiện, dễ cấu hình. Giao diện web là cách tốt nhất để thực hiện và kiểm soát ai có quyền truy cập mà không yêu cầu triển khai hoặc đào sâu vào máy chủ và cập nhật cấu hình hoặc tệp phức tạp. Kiểm soát ở cấp cổng và sau đó dễ dàng định cấu hình hoặc quản lý. 
  • Bảo mật API rất quan trọng và yêu cầu một cách tiếp cận toàn diện để ngăn chặn rò rỉ dữ liệu. Do cách dữ liệu có thể được chia sẻ thông qua API, người dùng có thể vô tình làm rò rỉ dữ liệu chỉ trong vài cú nhấp chuột. Điều này xảy ra khi nhân viên cho phép kết nối API OAuth giữa các ứng dụng bị xử phạt và các ứng dụng bên thứ ba không được kiểm soát, cấp cho các quyền sau này để đọc và thậm chí ghi dữ liệu (ví dụ: Email, Google Drive, Box, Office 365 và SharePoint). Chức năng này mang lại giá trị kinh doanh lớn nhưng có thể làm lộ dữ liệu khi không được bảo mật đúng cách.
    Dữ liệu có cấu trúc có thể được đồng bộ hóa giữa các ứng dụng thông qua JSON, XML hoặc API dựa trên tệp (tên một số). Dữ liệu có cấu trúc này có thể chứa thông tin nhạy cảm cần được bảo vệ bằng mã hóa hoặc mã hóa. Trong những tình huống này, điều quan trọng là phải tận dụng phương pháp mang theo chìa khóa của riêng bạn (BYOK); điều này là do dữ liệu không thực sự an toàn nếu khóa mã hóa được lưu trữ bằng ứng dụng chứa dữ liệu được mã hóa. May mắn thay, các nhà môi giới bảo mật truy cập đám mây đa chế độ (CASB) hàng đầu cung cấp khả năng hiển thị và bảo vệ theo thời gian thực cho tất cả các trường hợp sử dụng này, đảm bảo dữ liệu được bảo mật trên mọi ứng dụng, mọi thiết bị, ở bất kỳ đâu. 
  • Khi nói đến việc bảo mật các API, việc phân phát chúng qua HTTPS là một yêu cầu cơ bản nhưng tuyệt đối. Nó tương đối đơn giản để thiết lập: các công cụ và quy trình liên quan có sẵn rộng rãi và được hiểu rõ. Di chuyển khỏi cặp tên người dùng / mật khẩu phổ biến cũng là một phương pháp mà chúng tôi khuyên bạn nên thực hiện. Tên người dùng là một mục tiêu dễ dàng cho kỹ thuật xã hội. Mật khẩu, trong khi việc sử dụng đang phát triển, vẫn thường được tạo theo cách thủ công - hạn chế kích thước hoặc thành phần của chúng dẫn đến trải nghiệm khó chịu. Thay vào đó, chúng tôi thích sử dụng khóa API hơn.
    Các khóa API của chúng tôi có dạng mà chúng tôi đã nghĩ ra. Chúng tôi có thể chỉ định một số khóa API cho cùng một khách hàng. Một khóa API duy nhất có thể được trao đổi cho một số thực thể cho một khách hàng nhất định. Chúng tôi có thể thu hồi các khóa API. Tất cả điều này có thể được thực hiện độc lập với việc quản lý tài khoản khách hàng thực tế. 
  • Thực thi mã hóa mọi lúc -  Yêu cầu bảo mật cơ bản là mã hóa dữ liệu bằng các giao thức mật mã mới nhất để đảm bảo bảo vệ thích hợp trong khi dữ liệu được truyền đi. Phiên bản giao thức yếu và mật mã phải luôn bị vô hiệu hóa. TLS1.0 và 1.1. Mã hóa khi chuyển tiếp là rất tốt, nhưng vẫn chưa đủ. Nó phải được thực thi mọi cách, kể cả khi dữ liệu ở trạng thái nghỉ. 
  • Kiểm tra và ghi nhật ký -  Kiểm toán thường là một việc cần cân nhắc trước, trong khi nó nên được coi là một tính năng trong chu trình phát triển API. Ghi càng nhiều càng tốt, vì chi phí để có khả năng này lớn hơn nhiều so với chi phí không có chúng khi bạn cần khả năng này nhất (trong cuộc tấn công). Việc ghi nhật ký phải có hệ thống và độc lập, đồng thời chống lại các cuộc tấn công đưa vào nhật ký. Kiểm toán nên được sử dụng để phát hiện và chủ động ngăn chặn các cuộc tấn công.
  • Cảnh báo và Giám sát -  Cảnh báo và giám sát là chìa khóa để xem những gì đang diễn ra trong thế giới của bạn để bảo vệ khỏi những hành vi xấu. Việc ghi nhật ký và kiểm tra phải được sử dụng một cách chủ động trong việc phát hiện và cảnh báo bạn trước các mối đe dọa và tấn công.
  • Bảo vệ động từ HTTP và truy vấn yêu cầu chéo trang web (CSRF) - Các  API cho phép nhiều phương thức cho một URL cho các hoạt động khác nhau là điều phổ biến. Ví dụ: yêu cầu GET để đọc dữ liệu, PUT để cập nhật dữ liệu, POST để tạo dữ liệu và DELETE để xóa dữ liệu. Điều quan trọng đối với các API là hạn chế các động từ HTTP được phép để chỉ các phương thức được phép hoạt động, trong khi các phương thức khác sẽ dẫn đến một ngoại lệ cùng với một mã phản hồi thích hợp được gửi lại cho máy khách. Điều quan trọng là các phương thức PUT, POST và DELETE phải được bảo vệ khỏi truy vấn yêu cầu chéo trang web (CSRF). Thông thường, người ta sẽ sử dụng cách tiếp cận dựa trên mã thông báo để thực thi khả năng này.
  • Có một cách bên ngoài và một cách bên trong. SSL hoặc TLS bên ngoài để mã hóa, đảm bảo lưu lượng truy cập được bảo mật và mã hóa. Đảm bảo máy khách và máy chủ đều là SSL. Đảm bảo rằng bạn đang mã hóa dữ liệu. Biết ai đang gọi ứng dụng - Kết nối OAuth, OpenID. Điều cuối cùng được bảo mật dựa trên con người của bạn. Bên ngoài là tường lửa ứng dụng web để quét yêu cầu và đảm bảo không có gì đáng ngờ. Nội bộ xem những thứ khác như sau khi đã qua cổng hai dịch vụ vi mô đang nói chuyện với nhau bằng MTLS. Giới hạn đối tượng của công việc. Chỉ cho phép đi đến một nơi nhất định. Quản lý danh tính.
  • Bởi vì chúng tôi đã đưa microservices đến cực điểm hợp lý của chúng, với mỗi nhóm sản xuất các API trên internet công cộng để tiêu dùng trực tiếp, chúng tôi không có lợi ích của cổng như một điểm chặn để truy cập. Trong thế giới của chúng ta, không có thứ gọi là “API phụ trợ”. Điều đó làm cho việc bảo mật các API của chúng tôi trở thành một vấn đề đặc biệt lan rộng, nhưng điều đó cũng có nghĩa là không ai trong công ty của chúng tôi dựa vào cảm giác an toàn sai lầm được xây dựng trên các giả định rằng chỉ những người gọi “đúng” mới có thể tiếp cận các API của họ.
    Do đó, mọi nhóm chịu trách nhiệm bảo mật cho API của họ và chúng tôi đạt được điều này bằng cách tuân theo một số nguyên tắc chính:
    1) Mọi người gọi (con người hoặc có lập trình) xác thực bằng cách sử dụng cùng một tiêu chuẩn (mã thông báo mang OAuth2 ở dạng JWT được ký bởi nhà cung cấp danh tính của chúng tôi, Auth0)
    2)Mọi API xác thực danh tính và quyền truy cập của người gọi cho mỗi hành động
    3) Mỗi API trình bày thông tin đăng nhập ban đầu của người gọi cho các yêu cầu tiếp theo mà nó phải thực hiện đối với các API của chúng tôi.
    Bằng cách này, mọi API đều biết chính xác ai đã khởi xướng một chuỗi cuộc gọi và có thể suy luận chính xác về quyền truy cập của người gọi. Những kỹ thuật này đã phục vụ chúng tôi rất tốt vì mọi nhà phát triển đều có cùng kỳ vọng và trách nhiệm đối với việc đảm bảo quyền truy cập. Chúng tôi chưa tìm thấy công cụ tuyệt vời để tự động hóa kiểm tra bảo mật. Chúng tôi nhận thấy rằng sự khéo léo và cảnh giác của con người luôn cần thiết.
    Chúng tôi sử dụng các dịch vụ kiểm tra nguồn lực cộng đồng cho quan điểm bên ngoài nhưng cũng trao quyền cho các nhóm nội bộ để gắn cờ đỏ, lên đến cấp cao nhất của tổ chức, bất kỳ vấn đề bảo mật nào mà họ xác định trong API của bất kỳ ai. Cái thứ hai hoạt động đặc biệt tốt bởi vì, một lần nữa, tất cả chúng ta đều chịu trách nhiệm về bảo mật của các API được hiển thị trên internet công cộng, vì vậy mọi nhà phát triển đều có ý thức tốt về các phương pháp tốt và xấu.
  • Đối với các API RESTful - OAuth2 và JWT là tiêu chuẩn thực tế khá nhiều. Chúng tôi sử dụng cả hai. OAuth từ khách hàng đến nền tảng đám mây của chúng tôi và JWT nội bộ để có lợi ích về hiệu suất. Với sự phổ biến ngày càng tăng của Webhook, bạn phải ký các tải trọng của mình khi khách hàng “đăng ký” nhận thông báo API.
    Chúng tôi sử dụng chữ ký HMAC để khách hàng có thể xác nhận dữ liệu đến từ chúng tôi và không bị thay đổi. Tôi ngạc nhiên về tần suất chúng tôi gặp phải các nhà cung cấp API vẫn không làm điều đó. Chúng tôi sử dụng các biện pháp nâng cao hơn vào một số trường hợp, nhưng những biện pháp đó là đủ cho hầu hết các trường hợp.
    Bạn cũng phải có một số loại điểm nhập API duy nhất trước khi lệnh gọi API đến các dịch vụ nhỏ hoặc ứng dụng nguyên khối của bạn. Thông thường, đây là một cổng API sẽ chặn mọi cuộc gọi rất nhanh nếu chúng chưa được xác thực đúng cách.
  • Hầu hết các vấn đề bảo mật là do quá phức tạp và quá nhiều API. Sự đơn giản là chìa khóa, với tất cả bảo mật dữ liệu được xử lý tập trung, do đó, có một nơi để giữ cho nó luôn cập nhật. Các giao thức như GraphQL và SPARQL cho phép người tiêu dùng mô tả nhu cầu dữ liệu của riêng họ thông qua một API duy nhất, giảm thiểu đáng kể nhu cầu quản lý quá nhiều API ngay từ đầu.
  • Hạn chế danh sách người dùng được phép truy cập mã thông báo. Ủy quyền dựa trên mã thông báo là có lý do. Thứ hai, cần phải theo dõi và kiểm soát việc sử dụng tài nguyên được phân bổ cho một người dùng, điều này hoàn toàn cần thiết để bảo vệ khỏi các cuộc tấn công DDoS.

Đây là người đã chia sẻ thông tin chi tiết của họ:

|