Cần Hỏi Gì Nhà Cung Cấp CSMS Về Bảo Mật Và Độ Sẵn Sàng

Việc lựa chọn nền tảng sạc hiếm khi thất bại vì thiếu tính năng. Trở ngại thường xuất hiện ở vòng rà soát bảo mật, sau khi đội kỹ thuật đã xác nhận sản phẩm đáp ứng nhu cầu. Nguyên nhân thường là trang bảo mật của nhà cung cấp và bộ câu hỏi của bên mua tập trung vào những vấn đề khác nhau. Bài viết này tổng hợp các câu hỏi cần đặt ra cho nhà cung cấp CSMS về bảo mật và độ sẵn sàng, giải thích vì sao từng câu hỏi quan trọng và chỉ ra những câu trả lời cần được xem xét kỹ hơn.

Trước tiên, tách ba thứ thường bị gộp làm một

Câu hỏi “Hệ thống có an toàn và ổn định không?” thực chất gồm ba vấn đề với phạm vi trách nhiệm khác nhau. Một nhà cung cấp có thể làm tốt một mặt nhưng chưa đưa ra câu trả lời rõ ràng ở mặt khác.

Phần lớn bộ câu hỏi rà soát bảo mật bao phủ tốt cột thứ nhất, bao phủ một phần cột thứ hai, và gần như không đề cập đến cột thứ ba. Với doanh nghiệp sạc, đây lại là nơi tập trung nhiều rủi ro vận hành, vì một sự cố nền tảng có thể để một tài xế đứng chờ ngay tại trụ sạc.

Mã hóa và cách xử lý dữ liệu

• Lưu lượng có được mã hóa khi truyền tải trên cả ba hướng? Không chỉ màn hình quản trị — còn ứng dụng cho tài xế và chính kết nối OCPP từ trụ sạc. Hướng kết nối từ trụ sạc là hướng dễ bị bỏ qua nhất, và đó lại là đường truyền mang chỉ số công tơ mà sau này bạn dùng để tính tiền.
• Dữ liệu có được mã hóa khi lưu trữ, và áp dụng cho những kho dữ liệu nào? Một câu trả lời đáng tin cậy cần nêu rõ phạm vi. Khẳng định “toàn bộ, luôn luôn” mà không kèm điều kiện hoặc bằng chứng cần được kiểm tra thêm.
• Khóa bí mật và thông tin xác thực được quản lý thế nào? Chúng phải nằm trong một hệ thống quản lý khóa riêng, tách biệt khỏi dữ liệu ứng dụng — không nhúng trong tệp cấu hình hay mã nguồn.
• Dữ liệu được lưu trữ thực tế ở đâu, và có giới hạn được không? Nếu yêu cầu dữ liệu đặt trong nước là điều kiện bắt buộc theo quy định hoặc theo chính sách nội bộ của doanh nghiệp bạn, câu này cần được trả lời trước khi bàn điều kiện thương mại, không phải sau. Đây cũng là câu hỏi dễ làm thay đổi mô hình triển khai mà bạn chọn nhất.
• Những ai phía nhà cung cấp có thể xem dữ liệu production của chúng tôi, và quyền truy cập được kiểm soát thế nào? Đội hỗ trợ và kỹ thuật có thể cần quyền truy cập nhất định để xử lý sự cố. Hãy hỏi quyền đó có tuân theo nguyên tắc đặc quyền tối thiểu, được ghi log và rà soát định kỳ hay không.

Định danh, phân quyền và cách ly dữ liệu

• Chúng tôi có kết nối được hệ thống định danh của mình qua SAML hoặc OIDC? Nội dung này được trình bày chi tiết trong bài SSO doanh nghiệp cho nền tảng sạc, bao gồm cả câu hỏi tiếp theo về ánh xạ vai trò — phần quan trọng không kém việc đăng nhập.
• Phân quyền có theo vai trò, và vai trò có giới hạn được theo một phần mạng lưới? Một nhà thầu bảo trì không nên có cùng quyền hạn với trưởng bộ phận vận hành — xem vai trò, phân quyền và lịch sử kiểm toán.
• Nếu nền tảng là đa khách hàng, các tenant được cách ly thế nào? Hãy hỏi việc cách ly diễn ra ở tầng nào — dữ liệu và cấu hình — rồi yêu cầu được xem màn hình đăng nhập của một tenant đối tác trong giai đoạn đánh giá, thay vì chấp nhận một lời mô tả. Điều này đặc biệt quan trọng nếu bạn dự định vận hành mô hình nhượng quyền hoặc đối tác, và đó cũng là cốt lõi của một CSMS đa khách hàng.
• Thông tin xác thực API có giới hạn phạm vi và thu hồi độc lập được không? Một tích hợp chỉ cần đọc dữ liệu phiên sạc thì không nên giữ thông tin xác thực có thể dừng một phiên sạc — lý do được trình bày trong bài API, webhook và luồng sự kiện.
• Mọi thao tác quản trị có được ghi log ở cấp từng yêu cầu, kể cả những lần thất bại? Và các bản log đó có lọc, xuất được, kèm thời gian lưu trữ được công bố rõ? Bộ phận kiểm toán của bạn sẽ không đăng nhập vào màn hình vận hành.

Độ sẵn sàng: yêu cầu con số và đọc kỹ phạm vi áp dụng

Hãy yêu cầu cam kết về thời gian hoạt động bằng văn bản, trong hợp đồng, không phải một con số trên slide. Sau đó hỏi ba câu tiếp theo để biết con số đó có ý nghĩa gì:

• Những gì được loại trừ? Các khung thời gian bảo trì theo kế hoạch thường không được tính vào phép tính. Đó là thông lệ bình thường — nhưng bạn cần biết được thông báo trước bao lâu, và khung bảo trì có đặt được ngoài giờ cao điểm của mạng lưới sạc hay không.
• Thời gian gián đoạn được đo thế nào, và do ai đo? Một nền tảng tự đo độ sẵn sàng từ bên trong hạ tầng của chính mình sẽ luôn báo con số tốt hơn những gì tài xế của bạn thực sự trải nghiệm. Hãy hỏi có trang trạng thái công khai và lịch sử sự cố để đọc trước khi ký hay không.
• Chế tài là gì? Phần lớn cam kết chỉ bồi thường bằng tín dụng dịch vụ, thường rất nhỏ so với doanh thu mà một sự cố làm mất — xem chi phí thực của việc trạm sạc ngừng hoạt động. Khoản tín dụng đó không phải là bù đắp thiệt hại; nó là chỉ dấu cho thấy nhà cung cấp coi trọng cam kết đến mức nào.

Câu hỏi đặc thù ngành sạc: phiên sạc đang chạy sẽ thế nào?

Đây là câu hỏi phân biệt việc đánh giá một nền tảng sạc với việc đánh giá một sản phẩm SaaS thông thường, và cũng là câu phần lớn bên mua quên hỏi. Nếu kết nối giữa trụ sạc và hệ thống phía sau bị ngắt — do sự cố nền tảng, do mạng tại địa điểm, hoặc do tín hiệu yếu ở một vị trí xa — thì tài xế đã cắm sạc và đang nạp điện sẽ thế nào?

Phiên sạc nên tiếp tục và được đối soát sau khi kết nối khôi phục, thay vì bị dừng. Nếu sự cố ở hệ thống phía sau làm gián đoạn phiên sạc, một vấn đề hạ tầng sẽ trực tiếp ảnh hưởng đến khách hàng và có thể phát sinh hoàn tiền. Hãy hỏi cụ thể:

• Một phiên sạc đang diễn ra có tiếp tục cấp điện trong thời gian mất kết nối?
• Bản ghi phiên sạc có được lưu tạm trên trụ sạc và đối soát lại khi kết nối trở lại, để vẫn tính tiền chính xác?
• Có bắt đầu được phiên sạc mới trong lúc mất kết nối, và nếu có thì việc xác thực và áp giá diễn ra thế nào?
• Tài xế nhìn thấy gì trên ứng dụng trong khoảng thời gian đó?

Lưu ý rằng một phần trong số này phụ thuộc vào firmware của trụ sạc không kém gì phụ thuộc vào nền tảng, nên đây là câu hỏi cần đặt cho cả hai nhà cung cấp chứ không riêng bên phần mềm.

Sao lưu, phục hồi và khả năng lấy dữ liệu ra

• Mục tiêu phục hồi là gì? Trong tình huống xấu nhất có thể mất bao nhiêu dữ liệu (RPO), và việc phục hồi mất bao lâu (RTO). Hãy yêu cầu con số cụ thể.
• Lần gần nhất kiểm thử phục hồi là khi nào? Lịch sao lưu mới chỉ thể hiện chính sách; một lần phục hồi thành công mới là bằng chứng. Khoảng cách giữa hai việc này thường chỉ lộ ra khi sự cố xảy ra.
• Chúng tôi lấy dữ liệu của mình ra bằng cách nào, chủ động, ở định dạng dùng được? Đây vừa là câu hỏi về khả năng phục hồi, vừa là câu hỏi về phương án rút lui. Một nền tảng bạn không xuất dữ liệu ra được là một nền tảng bạn không rời đi được, và điều đó âm thầm trở thành một điều kiện thương mại thay vì một vấn đề kỹ thuật.

Giám sát, và sự cố thuộc trách nhiệm của ai

Hoạt động sạc có một ranh giới giám sát đặc thù: nền tảng có thể hoạt động bình thường trong khi một trụ sạc ngoài hiện trường đang hỏng, nhưng từ góc nhìn của bên mua, cả hai đều là “hệ thống đang lỗi”. Hãy hỏi nhà cung cấp phân biệt hai trường hợp đó thế nào, kết nối và sự cố ở cấp từng trụ sạc có được giám sát và cảnh báo như một tín hiệu chính thức hay không, và cảnh báo có đến được đội vận hành của bạn chứ không chỉ đến nhà cung cấp. Những chỉ số đáng theo dõi ở phía bạn được trình bày trong bài chỉ số uptime và độ tin cậy.

Thực hành phát triển an toàn và xử lý lỗ hổng

• Thay đổi mã nguồn có qua rà soát trước khi phát hành, và bản phát hành có triển khai theo từng giai đoạn? Triển khai theo giai đoạn là khác biệt giữa một lỗi ảnh hưởng đến một nhóm khách hàng và một lỗi ảnh hưởng đến toàn bộ khách hàng cùng lúc.
• Các thư viện phụ thuộc có được theo dõi và cập nhật thường xuyên? Phần lớn sự cố bảo mật trong thực tế đến từ một lỗ hổng đã biết trong một thư viện chưa được cập nhật, không phải từ một hình thức tấn công mới.
• Có kiểm thử xâm nhập, và chúng tôi xem được bản tóm tắt hoặc thư xác nhận không? Hãy chuẩn bị tinh thần nhận bản tóm tắt theo NDA thay vì báo cáo đầy đủ — đó là thông lệ bình thường.
• Có kênh công bố để báo cáo lỗ hổng, kèm cam kết về thời gian phản hồi? Một nhà cung cấp đã có địa chỉ tiếp nhận bảo mật và quy trình công bố là nhà cung cấp đã nghĩ về việc này trước khi bạn hỏi.

Tuân thủ: phải phân biệt “xây dựng theo” và “được chứng nhận”

Đây là điểm thuật ngữ hữu ích nhất trong cả một vòng rà soát bảo mật. “Xây dựng theo ISO 27001” nghĩa là nhà cung cấp đã thiết lập các thực hành của mình dựa trên khung tiêu chuẩn đó. “Được chứng nhận ISO 27001” nghĩa là một tổ chức đánh giá độc lập được công nhận đã kiểm tra và cấp chứng nhận, kèm phạm vi áp dụng và thời hạn hiệu lực. Cả hai đều có thể là cách tiếp cận hợp lệ, nhưng chúng không thể dùng thay cho nhau, và một nhà cung cấp làm mờ ranh giới này trong cuộc trao đổi bán hàng đang nói cho bạn biết một điều gì đó.

Hãy yêu cầu câu chữ chính xác, và ở những nơi có chứng nhận hoặc xác nhận, hãy hỏi phạm vi — pháp nhân nào, hệ thống nào, mô hình triển khai nào — cùng thời điểm cấp. Chứng nhận và báo cáo thường khác nhau theo từng triển khai, và thường được chia sẻ theo NDA thay vì công bố rộng. Nói rõ về vị trí của chính chúng tôi: CarChargeOS mô tả các thực hành của mình là tuân theo ISO 27001, còn các chứng nhận, xác nhận và báo cáo cụ thể thì khác nhau theo từng triển khai và được chia sẻ cho khách hàng doanh nghiệp theo NDA. Hãy áp dụng với chúng tôi đúng câu hỏi mà bạn sẽ đặt cho bất kỳ nhà cung cấp nào khác.

Trách nhiệm chia sẻ: biết rõ phần nào là của bạn

Không nền tảng nào có thể bảo vệ những thành phần nằm ngoài phạm vi kiểm soát của mình. Trong một mạng lưới sạc, trách nhiệm thường được phân chia như sau:

Nhà cung cấp trình bày rõ ràng ranh giới này thường dễ phối hợp hơn nhà cung cấp ngụ ý rằng họ chịu trách nhiệm cho mọi thành phần. Khẳng định bao quát có thể hấp dẫn trong buổi giới thiệu sản phẩm nhưng ít hữu ích khi sự cố thực sự xảy ra.

Năm câu trả lời nên khiến bạn dừng lại cân nhắc

• “Chúng tôi tuân thủ đầy đủ.” Tuân thủ cái gì, phạm vi đến đâu, ai xác nhận, hiệu lực đến khi nào? Tuân thủ mà không kèm tên tiêu chuẩn chỉ là ngôn ngữ tiếp thị.
• Một con số về thời gian hoạt động nhưng không được ghi trong hợp đồng. Một cam kết đáng tin cậy cần được thể hiện bằng văn bản.
• “Các tenant được tách biệt bằng phân quyền.” Phân quyền là cấu hình, và cấu hình có thể bị thay đổi do sai sót. Hãy hỏi về việc cách ly ở tầng dữ liệu.
• Không có câu trả lời về phiên sạc đang chạy khi mất kết nối. Nhà cung cấp cần mô tả rõ hành vi đã được thiết kế và kiểm thử; một câu trả lời chung chung là chưa đủ.
• Né tránh khi được hỏi về các sự cố đã xảy ra. Mọi nền tảng vận hành đủ lâu đều từng có sự cố. Một nhà cung cấp mô tả được một sự cố và những gì đã thay đổi sau đó là đang cho thấy họ có quy trình. Một nhà cung cấp khẳng định chưa từng có sự cố thì hoặc còn rất mới, hoặc không nói thẳng với bạn.

CarChargeOS công bố các thực hành bảo mật của mình — hạ tầng và lưu trữ, mã hóa, định danh và truy cập, cách ly giữa các tenant, khả năng kiểm toán, tính sẵn sàng và khả năng phục hồi, giám sát, thực hành phát triển an toàn, cùng ranh giới trách nhiệm chia sẻ — tại trang bảo mật, với phần tổng quan ở cấp nền tảng tại trang nền tảng và các tùy chọn triển khai tại trang doanh nghiệp. Với bất cứ điều gì bộ phận an ninh thông tin của bạn cần mà các trang đó chưa nêu, hãy liên hệ và chúng tôi sẽ trao đổi những gì áp dụng cho quá trình đánh giá của bạn.

Câu hỏi thường gặp