Quản trị thay vì ngăn cản: Cách SAP đảm bảo an toàn cấp doanh nghiệp cho kết nối AI

Ngành công nghiệp phần mềm doanh nghiệp đã trải qua một sự thay đổi căn bản, và các nhà cung cấp đang điều chỉnh cách tiếp cận của họ để bảo vệ tốt hơn những khách hàng đang tin tưởng sử dụng dịch vụ của họ. Trong nhiều năm qua, mọi nhà cung cấp nền tảng toàn cầu vận hành hạ tầng đám mây đa thuê bao (multi-tenant) đều duy trì các giới hạn tốc độ (rate limits), kiểm soát việc sử dụng và các hạn chế đối với việc sử dụng các giao diện nội bộ chưa được tài liệu hóa.

Các nền tảng CRM áp dụng giới hạn lệnh gọi API hàng ngày cho từng tổ chức, thực thi các giới hạn ở tầng nền tảng và duy trì sự tách biệt nghiêm ngặt giữa các API dữ liệu hàng loạt và bề mặt REST giao dịch. Các bộ sản phẩm năng suất và cộng tác điều tiết các API đồ thị của họ và chuyển hướng khối lượng công việc lớn sang các kênh truy cập dữ liệu chuyên dụng. Các nền tảng quản lý nhân lực và lực lượng lao động thực thi các giới hạn yêu cầu đồng thời và giới hạn truy xuất dữ liệu theo phiên làm việc. Các nền tảng quản lý dịch vụ CNTT thực thi giới hạn tốc độ cho từng người dùng và điều tiết ở cấp độ phiên bản (instance). Các nhà cung cấp dịch vụ đám mây lớn (hyperscalers) công bố hạn ngạch cho từng dịch vụ, thực thi chúng ở tầng hạ tầng và cấm rõ ràng các ứng dụng gọi các giao diện không phải SDK hoặc không được công bố.

Đây không phải là các biện pháp gây tranh cãi. Chúng là những tiêu chuẩn vệ sinh cơ bản cho các nền tảng phần mềm cấp doanh nghiệp vận hành hạ tầng chia sẻ ở quy mô lớn. Hơn một thập kỷ qua, các biện pháp này đã được áp dụng mà không có sự phản đối nghiêm trọng nào.

Chính sách API của SAP: Quản trị, không phải hạn chế

Khi SAP nhận trách nhiệm bảo vệ các khối lượng công việc quan trọng (mission-critical) của khách hàng trên đám mây, một chính sách API thống nhất với các kiểm soát sử dụng được làm rõ không phải là sự hạn chế mà là biểu hiện của sự quản lý cấp doanh nghiệp. Một số người đã đọc chính sách này như một sự hạn chế mới. Thực tế, chính sách không giới thiệu bất kỳ hạn chế mới nào. Nó chỉ đặt tên và thống nhất các biện pháp kiểm soát đã tồn tại trong các sản phẩm riêng lẻ của SAP trong nhiều năm.

SAP không giới thiệu quản trị API như một khái niệm mới. SAP SuccessFactors, SAP Ariba, SAP LeanIX và một số giải pháp SAP khác đã thực thi các giới hạn tốc độ và kiểm soát sử dụng được tài liệu hóa. Các SAP Note và tài liệu của SAP trước đây cũng đã định nghĩa việc sử dụng API.

Những gì chính sách gần đây làm là thống nhất thực hành hiện có đó thành một tiêu chuẩn duy nhất trên toàn bộ danh mục sản phẩm, một bước đi trở nên cấp thiết do sự xuất hiện của các hệ thống điều phối tác nhân tự chủ (autonomous agentic harnesses) mà SAP cam kết đầy đủ hỗ trợ, nhưng lại đặt một gánh nặng hiệu suất, ổn định và bảo mật hoàn toàn khác lên các bề mặt API vốn chưa bao giờ được thiết kế để điều phối tự chủ và trích xuất dữ liệu quy mô lớn.

Các giao diện tùy chỉnh: Chính sách API của SAP hạn chế và không hạn chế gì?

Các API tùy chỉnh được khách hàng xây dựng trong không gian tên của riêng họ cho mục đích mở rộng, tích hợp và di chuyển là các giao diện do khách hàng phát triển. Nếu bạn đã dành nhiều năm để xây dựng các dịch vụ dữ liệu tùy chỉnh, RFC tùy chỉnh và giao diện ABAP để kết nối hệ thống SAP với thế giới bên ngoài, việc hạn chế các API không được công bố trong chính sách có thể đọc giống như một lệnh phá dỡ khi mới tiếp cận. Nhưng thực tế không phải vậy. Sự hạn chế của chính sách nhắm vào các đối tượng nội bộ chưa được phát hành của chính SAP. Nó không vươn vào không gian tên Z để lên án hai thập kỷ kỹ thuật ABAP.

Khách hàng SAP Private Cloud có vị thế đặc quyền hơn nhiều so với phần lớn thế giới doanh nghiệp, bởi họ đã lâu có khả năng xây dựng trong không gian tên của riêng mình và định hình một môi trường mà họ tự do sửa đổi và mở rộng, và sự tự do đó không bị thu hồi.

Chính sách tập trung vào một vấn đề hẹp hơn: các giao diện nội bộ của SAP chưa bao giờ được công bố, chưa bao giờ được tài liệu hóa để khách hàng sử dụng và chưa bao giờ được cung cấp như một nền tảng tích hợp đáng tin cậy. Hầu hết mã tùy chỉnh không bao giờ chạm vào các nội bộ này và sẽ tiếp tục không bị ảnh hưởng; ở những nơi có chạm tới, rủi ro đối với khách hàng đã luôn hiện hữu, và chính sách chỉ đặt tên cho nó thay vì bịa ra nó.

Tuy nhiên, trong tập hợp đó có một lớp nhỏ hơn các giao diện không phải là vấn đề tranh luận mà là vấn đề cấm đoán. ODP-RFC thuộc về lớp này: nó nằm trong không gian tên của SAP như một giao diện nội bộ, không được phát hành mà SAP phân loại rõ ràng là "không được phép" cho sử dụng của ứng dụng khách hàng hoặc bên thứ ba như được tài liệu hóa trong SAP Note 3255746.

Đây chính xác là loại giao diện mà SAP sẽ gắn cờ là bị cấm trong các ghi chú và công cụ tự động hóa để việc sử dụng như vậy có thể được xác định sớm thông qua công cụ và hướng dẫn, thay vì được phát hiện muộn trong quá trình triển khai hoặc vận hành. Clean Core khác với Chính sách API nhưng chỉ theo cùng một hướng, và đáng chú ý là khách hàng không chỉ chấp nhận nó mà còn yêu cầu nó nhiều lần, sau khi trải qua chi phí nâng cấp của phương án thay thế; trong kỷ nguyên tác nhân (agentic), nơi SAP vận hành ERP quan trọng như một dịch vụ, cả Khuyến nghị Clean Core và Chính sách API đều là những điều kiện cần thiết cho độ tin cậy cấp doanh nghiệp mà hoạt động đám mây mang lại.

Cách các tác nhân AI thay đổi mô hình sử dụng API trong hệ thống SAP

Trong khi một số người bình luận cho rằng chính sách này chủ yếu là một bước đi thương mại, bằng chứng kỹ thuật lại kể một câu chuyện khác.

AI đã thay đổi mọi thứ về quan niệm truyền thống của chúng ta đối với các giao diện giao dịch. Các API mà doanh nghiệp đã sử dụng trong nhiều thập kỷ để tích hợp hệ thống SAP với các ứng dụng bên thứ ba là các giao diện yêu cầu-phản hồi được xây dựng cho khối lượng công việc giao dịch. Chúng được thiết kế để lấy một đơn đặt hàng, ghi nhận việc nhận hàng hoặc kích hoạt một lần thanh toán. Chúng được thiết kế để được gọi chủ yếu bởi luồng tích hợp do con người tạo ra, với tần suất có thể dự đoán, cho một mục đích kinh doanh được xác định. Chúng không được thiết kế để một hệ thống điều phối AI tự chủ chạy hàng nghìn lệnh gọi tuần tự chống lại chúng để theo đuổi ngữ cảnh ngữ nghĩa về mô hình kinh doanh được mã hóa bên trong. Đó không phải là một mẫu tích hợp Clean Core.

Phần lớn cuộc tranh luận đã bỏ qua một sự khác biệt kiến trúc cốt lõi. Một công cụ tích hợp truyền thống đọc một đơn đặt hàng từ SAP, chuyển đổi nó sang định dạng mà lược đồ đích cần và chuyển tiếp nó. Mô hình dữ liệu của SAP không đóng vai trò nào khác ngoài là bước diễn giải nhất thời.

Một tác nhân AI làm một cái gì đó hoàn toàn khác biệt. Nó không chỉ truy xuất một giá trị. Nó đọc dữ liệu tiêu đề đơn đặt hàng và học rằng cấu trúc này đại diện cho cam kết mua hàng của khách hàng. Nó đọc dữ liệu mục dòng và học cách các mục riêng lẻ liên quan đến đơn hàng đó. Nó đọc giá trị ròng và học rằng con số này chỉ có ý nghĩa khi đi kèm với tiền tệ của tài liệu. Nó theo dõi đường đi mà một đơn đặt hàng thực hiện qua giao hàng, thanh toán và cuối cùng vào sổ cái kế toán, và nội hóa cách SAP đối chiếu hoạt động và tài chính trong mô hình đối tượng kinh doanh của mình.

Tác nhân không chỉ tiêu thụ dữ liệu giao dịch của khách hàng. Nó đang tiêu thụ bản thể ngữ nghĩa (semantic ontology): các định nghĩa đối tượng kinh doanh, các mối quan hệ giữa các thực thể, kiến trúc khái niệm mà SAP đã xây dựng và tinh chỉnh trong suốt năm thập kỷ mã hóa kiến thức doanh nghiệp.

SAP đã lâu phân biệt giữa việc cho phép truy cập giao dịch vào dữ liệu khách hàng và việc trích xuất hoặc sao chép rộng rãi hơn bản thể cơ bản. Chính sách không tạo ra ranh giới này, bởi vì nó đã tồn tại từ trước. Các tác nhân tự chủ phải tiếp tục tôn trọng ranh giới đó, thay vì định nghĩa lại nó.

Rủi ro bảo mật trong các triển khai MCP bên thứ ba

Sau đó còn có góc độ bảo mật, và nó không phải là trừu tượng. Cùng tuần mà chính sách này được công bố, một cuộc tấn công chuỗi cung ứng tên là Mini Shai-Hulud - một biến thể của sâu npm, đã âm thầm thỏa hiệp hàng trăm gói phần mềm. Các gói npm trong hệ sinh thái SAP đã bị xâm phạm và chúng tôi đã giải quyết vấn đề này bằng ghi chú bảo mật này cho khách hàng. Đây không phải là mô hình mối đe dọa lý thuyết. Đây là môi trường đe dọa tích cực mà các máy chủ MCP do cộng đồng xây dựng đang được kết nối với các hệ thống SAP sản xuất chạy các quy trình kinh doanh quan trọng.

OWASP MCP Top 10 tài liệu hóa một cách có hệ thống các lớp lỗ hổng: đầu độc công cụ, chèn lệnh (prompt injection), leo thang đặc quyền thông qua sự mở rộng phạm vi, quản lý token sai và thỏa hiệp chuỗi cung ứng. Nghiên cứu gần đây trên hàng nghìn triển khai MCP được phân tích cho thấy đa số hoạt động với thông tin xác thực tĩnh tồn tại lâu hoặc mang các phát hiện bảo mật có thể xác định, và một gói bị xâm phạm duy nhất trong hệ sinh thái MCP có thể lan truyền thành hàng trăm nghìn môi trường phát triển bị lộ. VentureBeat chỉ tuần trước đã báo cáo một lỗ hổng thực thi lệnh nghiêm trọng khiến lên đến 200.000 máy chủ MCP bị tổn thương.

Hãy xem xét điều đó có ý nghĩa gì trong thực tế. Một tác nhân AI vừa nội hóa cấu trúc ngữ nghĩa của mô hình dữ liệu SAP của bạn và đang vận hành thông qua một máy chủ MCP cộng đồng, vượt ra khỏi một công cụ năng suất và bước vào một danh mục rủi ro cao hơn, danh mục kết hợp quyền truy cập hệ thống rộng lớn với bề mặt tấn công vẫn đang phát triển.

Tại sao MCP đơn thuần không thể vận hành quy trình kinh doanh SAP

Cuộc tranh luận về MCP cũng đã che khuất một thực tế kỹ thuật mà các kiến trúc sư doanh nghiệp cần đối mặt trực tiếp. Model Context Protocol (MCP) là hệ thống ống dẫn (plumbing). Nó quy định cách một mô hình AI gọi một công cụ. Nó không nói gì về việc liệu mô hình có hiểu công cụ đó làm gì trong bối cảnh kinh doanh hay không, công cụ phải được gọi theo trình tự nào, tác dụng phụ nào của một lần gọi API nhất định sẽ kích hoạt, hay hậu quả của một tham số không chính xác là gì. Một triển khai MCP ngây thơ kết nối với các dịch vụ SAP OData có thể gọi một công cụ. Nó không thể chạy một quy trình kinh doanh.

Dữ liệu tiêu thụ token từ các triển khai tác nhân sản xuất rất mang tính minh họa. Ví dụ, một truy vấn yêu cầu quản lý của một nhân viên và duyệt qua danh sách đồng nghiệp trong hệ thống SAP SuccessFactors đã tiêu thụ 565.000 token theo triển khai MCP tiêu chuẩn. Cùng một truy vấn theo triển khai nhận biết ngữ cảnh chỉ tiêu thụ 80.000 token. Đó là sự khác biệt giữa một truy vấn tốn 1,70 USD và một truy vấn tốn 0,24 USD, ví dụ, trên một thao tác duy nhất, lặp lại qua hàng nghìn giao dịch hàng ngày. Triển khai MCP tiêu chuẩn không phải là tự động hóa. Nó là một sự xấp xỉ tự động hóa đắt đỏ thất bại trên các truy vấn phức tạp trong khi tải bề mặt API với lưu lượng truy cập mà nó không được thiết kế để chịu đựng.

Kiến trúc của SAP cho tích hợp AI bên thứ ba mở thông qua A2A

Phản hồi của SAP trước những thách thức này không phải là đóng lại hệ sinh thái mà là xây dựng hạ tầng đúng đắn cho một hệ sinh thái mở. Sự phân biệt đó đáng để ngẫm nghĩ.

Chính sách API neo cố định sự tuân thủ trong các kiến trúc được đồng thiết kế và có tài liệu hóa. Các kiến trúc khả năng tương tác tác nhân được đồng phát triển với các đối tác công nghệ lớn được công bố và có sẵn trên Trung tâm Kiến trúc SAP (SAP Architecture Center), được ưu tiên theo nhu cầu của khách hàng và cập nhật khi các mẫu mới được xác thực.

Sự tích hợp song phương giữa SAP Joule và Microsoft 365 Copilot là ví dụ rõ ràng nhất về việc tích hợp tác nhân đồng thiết kế trông như thế nào trong môi trường sản xuất: hai hệ thống AI, từ hai nhà cung cấp khác nhau, hoạt động qua các bề mặt ứng dụng của nhau mà không bên nào bỏ qua mô hình bảo mật của bên kia. Con đường được chấp thuận cho truy cập tác nhân AI bên ngoài vào SAP là Agent Gateway thông qua giao thức A2A, với "Đường vàng AI" (AI Golden Path) tham khảo trên Trung tâm Kiến trúc SAP. Đồ thị Kiến thức SAP, đặc tả Khám phá Tài nguyên Mở (ORD) cho siêu dữ liệu và sản phẩm dữ liệu SAP BDC cung cấp lớp ngữ cảnh biến kết nối giao thức thành tương tác có khả năng kinh doanh. SAP cũng cung cấp các máy chủ MCP được quản lý cho CAP, UI5, Fiori Elements và đã chỉ định ý định mở rộng mô hình này sang các môi trường phát triển bổ sung, bao gồm phát triển ABAP. Đây không phải là những cánh cửa đóng, mà là những cánh cửa đúng đắn.

Vị thế của SAP trong cộng đồng tiêu chuẩn là một người đóng góp tích cực, không phải người gác cổng. SAP là đối tác khởi xướng của giao thức Agent2Agent (A2A) dưới Quỹ Linux và nắm giữ tư cách thành viên Vàng trong Quỹ AI Tác nhân (Agentic AI Foundation), đồng chủ trì nhóm công tác Danh tính và Niềm tin của Tác nhân cùng với các tổ chức định nghĩa cách các tác nhân AI xác thực, ủy quyền và tương tác qua các biên giới doanh nghiệp.

A2A và MCP không phải là các ràng buộc bên ngoài mà SAP miễn cưỡng dung nạp. Chúng là các giao thức mà SAP sử dụng nội bộ và đang chủ động củng cố thông qua công việc tiêu chuẩn. Khi các khung mã nguồn mở và cộng đồng đáp ứng sàn bảo mật mà việc triển khai doanh nghiệp yêu cầu, các đường dẫn tích hợp bên ngoài sẽ theo sau.

Chính sách API do SAP ban hành không đánh dấu sự kết thúc của sự cởi mở. Ngành công nghiệp đã dành hai năm triển khai các tác nhân AI chống lại các hệ thống doanh nghiệp sử dụng các giao thức mà cộng đồng bảo mật doanh nghiệp chưa kết thúc việc củng cố, chống lại các API chưa bao giờ được thiết kế để điều phối tự chủ, với các công cụ cộng đồng mà những kẻ tấn công đã học cách khai thác. Quản trị không phải là tùy chọn, nó là đúng lúc.