Tóm tắt
Các đánh giá bảo mật doanh nghiệp, các quy định tuân thủ và yêu cầu về nơi lưu trú dữ liệu đang cản trở việc áp dụng Postman và thúc đẩy việc di chuyển khỏi nó. Mẫu hình lặp lại vẫn là: kiến trúc ưu tiên đám mây xung đột với các chính sách yêu cầu dữ liệu phải nằm trong nội bộ, và Postman không có tùy chọn tự lưu trữ (self-hosted). Việc triển khai Apidog tự lưu trữ dành cho doanh nghiệp đang trở thành lựa chọn thay thế mà các tổ chức này tìm đến.
Giới thiệu
Postman đã xây dựng vị thế thống trị trên thị trường công cụ API trong hơn một thập kỷ. Hiệu ứng mạng lưới của nó rất lớn: 30 triệu người dùng, một bộ sưu tập API công khai rộng lớn, tích hợp với mọi nền tảng CI/CD lớn, và một bộ tính năng mở rộng vượt xa kiểm thử yêu cầu đơn giản sang thiết kế API, tài liệu và giám sát.
Nhưng trong vài năm qua, một xu hướng ngược lại đã xuất hiện trong các tài khoản doanh nghiệp. Các nhóm bảo mật và tuân thủ đang xem xét kỹ lưỡng hơn các công cụ dành cho nhà phát triển, và kiến trúc ưu tiên đám mây của Postman không vượt qua được các đánh giá đó ở ngày càng nhiều tổ chức.
Vấn đề mang tính cấu trúc. Sản phẩm của Postman được xây dựng xoay quanh khả năng cộng tác trên đám mây. Các không gian làm việc (workspaces), nhóm (teams), môi trường (environments) và đồng bộ hóa bộ sưu tập (collection sync) đều yêu cầu dữ liệu phải nằm trên máy chủ của Postman. Điều đó có ý nghĩa khi sản phẩm nhắm đến các nhà phát triển cá nhân và các nhóm nhỏ. Khi nó tiến vào thị trường doanh nghiệp xử lý dữ liệu nhạy cảm, chính kiến trúc cho phép cộng tác lại trở thành một điểm yếu trong các môi trường được quy định và có ý thức cao về bảo mật.
Yếu tố thúc đẩy 1: Các đánh giá của nhóm bảo mật cản trở việc áp dụng
Kịch bản phổ biến nhất kích hoạt việc di chuyển khỏi Postman là một đánh giá bảo mật. Khi các tổ chức phát triển các chương trình bảo mật phần mềm của mình, các công cụ dành cho nhà phát triển cũng phải chịu sự giám sát tương tự như hạ tầng sản xuất.
Quy trình đánh giá thường diễn ra như sau: một nhóm kỹ thuật muốn mở rộng việc sử dụng Postman, chuyển từ tài khoản cá nhân sang tài khoản doanh nghiệp dùng chung, hoặc chính thức hóa nó trong chuỗi công cụ phát triển. Nhóm bảo mật đánh giá công cụ này như một phần của việc đánh giá nhà cung cấp. Đánh giá cho thấy đồng bộ hóa đám mây của Postman gửi nội dung yêu cầu (request bodies), biến môi trường (environment variables) (bao gồm thông tin xác thực) và dữ liệu phản hồi (response data) đến các máy chủ đặt tại Mỹ của Postman.
Nhóm bảo mật đặt câu hỏi: liệu chính sách xử lý dữ liệu của chúng ta có cho phép lưu trữ dữ liệu yêu cầu API chứa các điểm cuối nội bộ và thông tin xác thực trên đám mây của bên thứ ba không? Đối với các tổ chức có chính sách phân loại dữ liệu coi thông tin xác thực API và thông tin hệ thống nội bộ là bí mật hoặc nhạy cảm, câu trả lời thường là không.
Phản hồi của Postman đối với mối lo ngại này là chứng nhận SOC 2 Type II và tài liệu bảo mật doanh nghiệp của họ. Đối với một số tổ chức, điều này là đủ. Đối với những tổ chức khác, chứng nhận không giải quyết được mối lo ngại về kiến trúc cơ bản: ngay cả một nhà cung cấp được chứng nhận SOC 2 vẫn có quyền truy cập vào dữ liệu của bạn khi dữ liệu chạy trên đám mây của họ.
Kết luận của nhóm bảo mật là Postman, với tư cách là một sản phẩm SaaS ưu tiên đám mây không có tùy chọn tự lưu trữ, không thể được sử dụng cho công việc liên quan đến các hệ thống nội bộ nhạy cảm. Nhóm kỹ thuật đành phải tìm kiếm một giải pháp thay thế vượt qua được đánh giá.
Yếu tố thúc đẩy 2: Các yêu cầu tuân thủ về nơi lưu trú dữ liệu
Các yêu cầu tuân thủ đã trở thành một yếu tố thúc đẩy đáng kể việc di chuyển công cụ, đặc biệt là trong các ngành có quy định nghiêm ngặt về nơi lưu trú dữ liệu.
Các tổ chức châu Âu theo GDPR. GDPR tạo ra xung đột cho các dịch vụ đám mây có trụ sở tại Mỹ. Mặc dù các Điều khoản Hợp đồng Tiêu chuẩn (Standard Contractual Clauses) cung cấp một cơ chế pháp lý cho việc truyền dữ liệu từ EU sang Mỹ, các tổ chức có dữ liệu đặc biệt nhạy cảm có thể muốn tránh sự phức tạp đó bằng cách sử dụng các công cụ giữ dữ liệu ở Châu Âu. Postman không cung cấp tùy chọn lưu trữ dữ liệu tại khu vực EU hoặc tùy chọn tự lưu trữ, vì vậy không có cách nào để giữ dữ liệu trong EU.
Các dịch vụ tài chính theo hướng dẫn của FFIEC và OCC. Các cơ quan quản lý ngân hàng Hoa Kỳ ngày càng nhấn mạnh việc lưu trú dữ liệu và quản lý rủi ro của bên thứ ba. Các ngân hàng và tổ chức tài chính thuộc sự giám sát của OCC hoặc FDIC đang xem xét liệu thông tin hệ thống nhạy cảm (có thể bao gồm thông tin xác thực API cho các hệ thống tài chính) có nên được lưu trữ trên đám mây của bên thứ ba hay không.
Các nhà thầu chính phủ theo CMMC. Chương trình Chứng nhận Mức độ Trưởng thành An ninh mạng (CMMC) dành cho các nhà thầu quốc phòng Hoa Kỳ quy định các yêu cầu về xử lý Thông tin Không phân loại Có kiểm soát (CUI). Việc lưu trữ CUI trong một công cụ đám mây thương mại không phải là dịch vụ được ủy quyền bởi FedRAMP có thể vi phạm các yêu cầu của CMMC. Postman không có ủy quyền FedRAMP.
Chăm sóc sức khỏe theo HIPAA. Như đã thảo luận trong bài viết đánh giá tuân thủ, Postman cung cấp BAA cho HIPAA, nhưng mô hình đồng bộ hóa đám mây vẫn có nghĩa là PHI trong các yêu cầu kiểm thử sẽ được gửi đến máy chủ của Postman. Các tổ chức có chương trình HIPAA nghiêm ngặt có thể ưu tiên một công cụ loại bỏ hoàn toàn luồng dữ liệu đó.
Điểm chung xuyên suốt các bối cảnh tuân thủ này: tổ chức cần kiểm soát nơi dữ liệu của mình di chuyển, và kiến trúc của Postman khiến điều đó không thể thực hiện được.
Yếu tố thúc đẩy 3: Chi phí khi mở rộng quy mô
Bảo mật và tuân thủ không phải là những yếu tố thúc đẩy duy nhất. Chi phí thuần túy cũng là một yếu tố khi các tổ chức kỹ thuật mở rộng quy mô.
Mức giá doanh nghiệp của Postman là tính trên mỗi người dùng, mỗi tháng. Đối với các nhóm nhỏ, chi phí không đáng kể. Đối với các tổ chức kỹ thuật có hàng trăm hoặc hàng nghìn nhà phát triển, chi phí trở nên đáng kể. Các tổ chức thực hiện phân tích chi phí ở quy mô lớn đôi khi nhận thấy rằng việc triển khai một giải pháp thay thế tự lưu trữ một lần có thể mang lại khoản tiết kiệm đáng kể trong nhiều năm.
Việc cân nhắc chi phí này đặc biệt phù hợp với các tổ chức đã và đang đầu tư vào cơ sở hạ tầng nền tảng nội bộ. Việc thêm một công cụ API vào một cụm Kubernetes hiện có hoặc trang trại máy chủ nội bộ chỉ tốn thêm một chi phí cận biên so với phí SaaS định kỳ trên mỗi người dùng.
Yếu tố chi phí hiếm khi đứng riêng lẻ. Các tổ chức di chuyển vì lý do chi phí thường cũng viện dẫn các mối lo ngại về bảo mật hoặc tuân thủ. Chi phí là chất xúc tác thúc đẩy việc xem xét chính thức, từ đó làm nổi bật các vấn đề bảo mật và tuân thủ.
Yếu tố thúc đẩy 4: Phát hiện của CloudSEK và những hệ quả của nó
Phát hiện của CloudSEK vào năm 2023 về hơn 30.000 không gian làm việc công khai của Postman làm rò rỉ khóa API đã có tác động cụ thể đến các nhóm bảo mật doanh nghiệp. Nó cung cấp một ví dụ cụ thể về việc cấu hình sai Postman dẫn đến việc lộ thông tin xác thực trên diện rộng.
Khi các nhóm bảo mật xem báo cáo, họ đã đặt câu hỏi rõ ràng cho chính tổ chức của mình: chúng ta có không gian làm việc công khai nào chứa thông tin xác thực không? Nhiều người nhận thấy họ có. Quá trình kiểm toán sau đó đã dẫn đến việc khắc phục, nhưng cũng dẫn đến việc đánh giá lại liệu kiến trúc mặc định của Postman có tương thích với mức độ chấp nhận rủi ro của tổ chức hay không.
Phát hiện này cũng cung cấp cho các nhóm bảo mật một bằng chứng cụ thể để đưa vào các cuộc thảo luận với lãnh đạo kỹ thuật về rủi ro của công cụ dành cho nhà phát triển. Những lo ngại trừu tượng về “thông tin xác thực được đồng bộ hóa đám mây” khó có thể hành động. Một báo cáo trích dẫn các công ty cụ thể có khóa API bị lộ, kèm theo cơ chế để kiểm tra mức độ phơi nhiễm của chính bạn, là có thể thực hiện được.
Đối với một số tổ chức, cuộc kiểm toán không tìm thấy không gian làm việc công khai nào chứa thông tin xác thực. Họ đã thắt chặt các chính sách của mình và tiếp tục sử dụng Postman. Đối với những tổ chức khác, cuộc kiểm toán đã tìm thấy sự phơi nhiễm, và trải nghiệm phát hiện ra rằng thông tin xác thực sản xuất đã có thể truy cập được bởi bất kỳ ai tìm kiếm trên mạng API của Postman đã đủ động lực để di chuyển.
Mô hình di chuyển: những gì các tổ chức thực sự làm
Các tổ chức di chuyển khỏi đám mây Postman tuân theo một mô hình dễ nhận biết.
Giai đoạn 1: Kích hoạt bảo mật hoặc tuân thủ. Một đánh giá bảo mật, phát hiện kiểm toán, yêu cầu tuân thủ hoặc sự cố (như việc tìm thấy một không gian làm việc bị lộ) thúc đẩy một đánh giá chính thức về các công cụ dành cho nhà phát triển.
Giai đoạn 2: Thu thập yêu cầu. Nhóm bảo mật thiết lập các yêu cầu. Thông thường: nơi lưu trú dữ liệu, không đồng bộ hóa thông tin xác thực trên đám mây, tùy chọn triển khai tự lưu trữ, tính năng cộng tác nhóm, khả năng tương thích với bộ sưu tập Postman (để di chuyển) và hỗ trợ doanh nghiệp.
Giai đoạn 3: Đánh giá. Các công cụ ứng cử viên được đánh giá dựa trên các yêu cầu. Bruno thường không vượt qua được đánh giá cho các nhóm lớn vì nó thiếu các tính năng cộng tác tập trung. Hoppscotch tự lưu trữ được đánh giá nhưng có thể bị hạ thấp ưu tiên nếu nhóm thiếu năng lực DevOps hoặc cần các tính năng mà Hoppscotch không hỗ trợ. Apidog tự lưu trữ là lựa chọn phổ biến nhất cho các nhóm cần bộ tính năng đầy đủ (thiết kế, kiểm thử, tài liệu, mocking) kèm theo khả năng tự lưu trữ.
Giai đoạn 4: Thử nghiệm. Một nhóm nhỏ trong đội ngũ kỹ thuật chạy công cụ ứng cử viên song song với Postman trong 30-90 ngày. Các bộ sưu tập Postman được xuất và nhập. Các quy trình làm việc được xác thực.
Giai đoạn 5: Di chuyển. Các bộ sưu tập được di chuyển, môi trường được thiết lập lại với thông tin xác thực sạch (việc di chuyển là thời điểm tốt để xoay vòng khóa), và các tài khoản Postman bị hủy cấp phép.
Những gì các tổ chức này chọn thay thế
Bối cảnh các giải pháp thay thế đã trưởng thành đến mức các nhóm doanh nghiệp có các lựa chọn khả thi.
Apidog tự lưu trữ. Lựa chọn phổ biến nhất cho các tổ chức cần duy trì khả năng nền tảng đầy đủ của Postman (không chỉ kiểm thử yêu cầu, mà còn thiết kế API, tài liệu và mocking) trong khi vẫn giữ dữ liệu trong cơ sở hạ tầng của riêng họ.
Việc triển khai tự lưu trữ chạy trên Docker và có thể được triển khai tại chỗ (on-premises), trên đám mây riêng (private cloud), hoặc trong một khu vực đám mây cụ thể. Các tính năng cộng tác nhóm hoạt động giống như phiên bản đám mây, nhưng quá trình đồng bộ hóa diễn ra trên máy chủ nội bộ của bạn. Nơi lưu trú dữ liệu hoàn toàn nằm trong tầm kiểm soát của bạn.
Đối với việc mua sắm của doanh nghiệp, Apidog cung cấp mô hình cấp phép tự lưu trữ với hỗ trợ chuyên biệt. Điều này phù hợp với các yêu cầu quản lý nhà cung cấp của các tổ chức lớn.
Bruno dành cho các nhóm tập trung vào kỹ thuật. Các tổ chức có văn hóa DevOps mạnh mẽ và quy trình làm việc lấy git làm trung tâm đôi khi chọn Bruno vì cách tiếp cận 'bộ sưu tập dưới dạng tệp' của nó phù hợp với các nguyên tắc cơ sở hạ tầng dưới dạng mã. Các bộ sưu tập tồn tại cùng với mã ứng dụng trong cùng một kho lưu trữ. Kiểm soát phiên bản là git. Không cần duy trì máy chủ.
Bruno hoạt động tốt nhất khi nhu cầu chính của tổ chức là kiểm thử yêu cầu và nhóm cảm thấy thoải mái với trải nghiệm công cụ tối giản hơn.
Hoppscotch tự lưu trữ. Mã nguồn mở, có thể tự triển khai và dựa trên trình duyệt. Tốt cho các tổ chức muốn có giao diện người dùng web mà các thành viên trong nhóm có thể truy cập mà không cần cài đặt ứng dụng máy tính để bàn. Đòi hỏi đầu tư vận hành nhiều hơn so với tùy chọn tự lưu trữ của Apidog.
Điểm chung của các cuộc di chuyển thành công
Các tổ chức di chuyển thành công khỏi đám mây Postman chia sẻ một số thực tiễn.
Họ thực hiện việc di chuyển như một dự án, không phải là một điều phụ. Các bộ sưu tập không tự di chuyển. Các biến môi trường cần được nhập lại với thông tin xác thực sạch. Các script kiểm thử có thể cần điều chỉnh để phù hợp với sự khác biệt trong API script. Phân bổ thời gian dự án phù hợp giúp việc di chuyển diễn ra suôn sẻ hơn.
Họ coi việc di chuyển là một cơ hội để dọn dẹp thông tin xác thực. Quá trình di chuyển yêu cầu nhập lại các biến môi trường. Đây là thời điểm tự nhiên để xoay vòng khóa API và đảm bảo rằng thông tin xác thực của nhà phát triển được phân quyền chính xác. Các tổ chức làm điều này sẽ có được tình trạng thông tin xác thực sạch sẽ hơn sau khi di chuyển so với trước đó.
Họ đào tạo nhóm về mô hình bảo mật của công cụ mới. Hiểu được lý do tại sao công cụ này được chọn và mô hình dữ liệu của nó khác với Postman như thế nào sẽ giúp nhóm kỹ thuật đưa ra các quyết định đúng đắn. Một nhóm hiểu rằng “dữ liệu của chúng ta nằm trong nội bộ vì nó đồng bộ hóa với máy chủ của chúng ta” ít có khả năng tạo ra các lỗ hổng bảo mật hơn một nhóm chỉ biết rằng “chúng ta đã chuyển đổi công cụ.”
Họ thiết lập các chính sách rõ ràng trên nền tảng mới. Sự quản trị tương tự như đã cần cho Postman cũng cần thiết cho công cụ mới: ai có quyền truy cập vào cái gì, thông tin xác thực nào được lưu trữ ở đâu và quyền truy cập không gian làm việc được quản lý như thế nào. Di chuyển mà không cải thiện chính sách chỉ đơn thuần là chuyển cùng một rủi ro sang một nền tảng khác.
Khoảng trống sản phẩm mà Postman chưa giải quyết
Xu hướng di chuyển của doanh nghiệp cuối cùng được thúc đẩy bởi một khoảng trống sản phẩm: Postman chưa xây dựng tùy chọn tự lưu trữ.
Một Postman tự lưu trữ chạy trên cơ sở hạ tầng của khách hàng và đồng bộ hóa dữ liệu nội bộ sẽ giải quyết mối lo ngại về nơi lưu trú dữ liệu trong khi vẫn giữ tất cả các tính năng đã làm nên sự thống trị của Postman. Nhiều khách hàng doanh nghiệp đã công khai yêu cầu điều này trên các diễn đàn phản hồi của Postman trong nhiều năm qua. Sản phẩm đã không đi theo hướng đó.
Mô hình kinh doanh của Postman phụ thuộc vào các gói đăng ký đám mây. Một tùy chọn tự lưu trữ sẽ chuyển một phần doanh thu đó sang phí cấp phép một lần hoặc hàng năm và sẽ yêu cầu xây dựng và duy trì một cơ sở hạ tầng triển khai mà Postman chưa ưu tiên.
Khoảng trống này đã tạo ra cơ hội cho Apidog và các giải pháp thay thế khác. Nhu cầu về “các tính năng của Postman, triển khai tự lưu trữ” là có thật và chưa được Postman đáp ứng.
Câu hỏi thường gặp
Liệu Postman có đang thực sự mất khách hàng doanh nghiệp vì điều này không?Mô hình di chuyển do đánh giá bảo mật thúc đẩy là có thật và được ghi lại trong các diễn đàn nhà phát triển và thảo luận cộng đồng. Các tổ chức lớn với các chương trình bảo mật trưởng thành là những tổ chức có nhiều khả năng gặp phải các hạn chế về kiến trúc của Postman nhất. Việc Postman có đang mất khách hàng ròng vì điều này hay không là một câu hỏi kinh doanh nằm ngoài phạm vi phân tích này.
Bạn không thể chỉ tắt đồng bộ hóa Postman và sử dụng cục bộ sao?Postman đã loại bỏ Scratch Pad vào khoảng năm 2023, đây là con đường duy nhất để hoạt động hoàn toàn cục bộ. Các phiên bản hiện tại yêu cầu tài khoản đã đăng nhập và đồng bộ hóa dữ liệu theo mặc định. Đối với các doanh nghiệp cần kiểm soát dữ liệu hoàn toàn, các biện pháp giảm thiểu một phần trong Postman là không đủ.
Việc triển khai Apidog tự lưu trữ trông như thế nào về mặt vận hành?Nó chạy trên Docker Compose hoặc Kubernetes. Nó yêu cầu một cơ sở dữ liệu PostgreSQL và một reverse proxy để chấm dứt TLS. Tải trọng vận hành có thể so sánh với việc chạy một ứng dụng web có độ phức tạp trung bình. Các nhóm có kỹ sư nền tảng nội bộ có thể xử lý được.
Điều gì xảy ra với các bộ sưu tập Postman hiện có trong quá trình di chuyển?Các bộ sưu tập Postman được xuất ra định dạng JSON. Apidog, Bruno, Hoppscotch và Insomnia đều nhập định dạng bộ sưu tập Postman. Việc nhập thường sạch sẽ đối với các bộ sưu tập. Các biến môi trường cần được nhập lại thủ công (điều này dù sao cũng là một thực hành tốt cho vệ sinh thông tin xác thực).
Apidog tự lưu trữ có hỗ trợ SSO và xác thực doanh nghiệp không?Giải pháp Apidog tự lưu trữ dành cho doanh nghiệp hỗ trợ tích hợp SSO thông qua SAML và OIDC. Đây là một yêu cầu đối với hầu hết các triển khai doanh nghiệp và có sẵn trong gói doanh nghiệp.
Một cuộc di chuyển Postman điển hình mất bao lâu?Đối với một nhóm kỹ thuật 50 người với 100-200 bộ sưu tập Postman, một cuộc di chuyển thường mất 4-8 tuần kể từ khi ra quyết định đến khi chuyển đổi hoàn toàn, bao gồm cả giai đoạn thử nghiệm và đào tạo. Các nhóm lớn hơn với nhiều bộ sưu tập hơn sẽ mất nhiều thời gian hơn.
Các doanh nghiệp di chuyển khỏi đám mây Postman không phải vì Postman là một sản phẩm tồi. Họ làm như vậy vì kiến trúc sản phẩm không còn phù hợp với yêu cầu của họ khi những yêu cầu đó đã trưởng thành hơn. Các tổ chức thành công với các giải pháp thay thế Postman là những tổ chức coi việc di chuyển như một dự án với các yêu cầu rõ ràng, chứ không chỉ đơn thuần là việc thay đổi công cụ.