Một nền tảng sạc có thể đáp ứng mọi yêu cầu kỹ thuật - từ tương thích phần cứng, hỗ trợ các phiên bản OCPP đến xuất hóa đơn - nhưng vẫn bị dừng ở khâu mua sắm nếu bộ phận an ninh thông tin không chấp nhận cách tạo và xác thực tài khoản vận hành. Với doanh nghiệp hoặc CPO, vấn đề thường nằm ở khả năng đăng nhập một lần (SSO): nền tảng có tích hợp với hệ thống định danh hiện có hay yêu cầu một bộ tên đăng nhập và mật khẩu riêng?
SAML và OIDC thực chất làm gì
SAML (Security Assertion Markup Language) và OIDC (OpenID Connect) là hai chuẩn để một nền tảng sạc chuyển việc xác thực sang hệ thống định danh của doanh nghiệp - Okta, Azure AD/Entra ID, Google Workspace hoặc tương đương. Về mặt chức năng, cả hai giải quyết cùng một bài toán theo hai cách: thay vì màn hình quản trị tự quản lý một cơ sở dữ liệu mật khẩu riêng, người dùng đăng nhập thông qua hệ thống định danh sẵn có của doanh nghiệp, và nền tảng tin vào một chứng thực (SAML) hoặc một token (OIDC) xác nhận họ là ai, cùng với vai trò hoặc nhóm mà họ thuộc về. Không có chuẩn nào tốt hơn trong mọi trường hợp - SAML lâu đời hơn và phổ biến hơn trong các hệ thống IT doanh nghiệp lớn, OIDC mới hơn và phổ biến hơn khi hệ thống định danh vốn đã đặt trên cloud - và phần lớn nhà cung cấp định danh doanh nghiệp đều hỗ trợ cả hai.
Vì sao bộ phận IT hỏi điều này trước tiên
- Thu hồi quyền khi nhân sự rời đi. Khi một nhân viên nghỉ việc, việc vô hiệu hóa tài khoản của họ trong hệ thống định danh phải lập tức chặn quyền truy cập ở mọi nơi, bao gồm cả màn hình quản trị trạm sạc - chứ không để lại một tài khoản riêng bị bỏ quên nhưng vẫn hoạt động.
- Chính sách mật khẩu và xác thực đa yếu tố. Bộ phận an ninh áp dụng quy định về đổi mật khẩu, độ phức tạp và xác thực đa yếu tố ở một nơi tập trung. Một nền tảng có hệ thống đăng nhập riêng là một lỗ hổng trong chính sách đó, không phải một ngoại lệ được chấp nhận.
- Kiểm toán và tuân thủ. Các kỳ rà soát quyền truy cập được xây dựng trên giả định hệ thống định danh là nguồn dữ liệu duy nhất về việc ai được đăng nhập vào đâu. Một tài khoản riêng của nhà cung cấp sẽ không xuất hiện trong kỳ rà soát đó.
- Giảm số thông tin đăng nhập có thể bị đánh cắp. Mỗi tài khoản độc lập thêm vào là một mật khẩu nữa mà nhân viên có thể dùng lại ở nơi khác hoặc bị lừa đánh cắp. Định danh tập trung thu gọn tất cả về một.
Không điều nào trong số này là đặc thù của ngành sạc xe điện - đây là tiêu chuẩn mà bộ phận IT doanh nghiệp áp dụng cho mọi nhà cung cấp SaaS. Khác biệt là các nền tảng sạc còn khá mới trong nhiều quy trình mua sắm như vậy, nên tốt nhất là xác nhận từ đầu thay vì phát hiện khoảng trống khi đã bước vào vòng rà soát an ninh.
Ánh xạ vai trò quan trọng không kém việc đăng nhập
SSO trả lời câu hỏi “người này là ai”, không trả lời “họ được làm gì sau khi vào”. Nền tảng sạc vẫn cần hệ thống phân quyền theo vai trò riêng - quản lý địa điểm, vận hành khu vực, tài chính, hỗ trợ chỉ đọc - và phần tích hợp thực sự hữu ích là ánh xạ nhóm trong hệ thống định danh sang các vai trò đó, để việc thêm một người vào một nhóm trên Azure AD chính là hành động cấp cho họ quyền truy cập một địa điểm hoặc một vai trò trong màn hình quản trị, thay vì phải thao tác thủ công lần thứ hai trong nền tảng sạc. Hãy hỏi nhà cung cấp cụ thể rằng việc ánh xạ vai trò diễn ra tự động theo nhóm hay vẫn phải gán thủ công - phương án sau tái tạo lại đúng khoảng trống thu hồi quyền mà SSO vốn được dùng để khắc phục. Cách bố trí các vai trò đó được trình bày chi tiết hơn trong bài vai trò, phân quyền và lịch sử kiểm toán.
Những câu hỏi nên đặt ra với nhà cung cấp
- Hỗ trợ chuẩn nào, và đã kiểm thử thực tế với nhà cung cấp định danh nào? “Chúng tôi hỗ trợ SAML” và “chúng tôi đã chạy SAML với Okta, Entra ID và Google Workspace trên môi trường thật” là hai khẳng định khác nhau - hãy yêu cầu khẳng định thứ hai.
- Ánh xạ vai trò có tự động theo nhóm trong hệ thống định danh, hay mỗi người dùng vẫn cần được gán vai trò thủ công trong nền tảng sau lần đăng nhập đầu tiên?
- SSO áp dụng cho màn hình quản trị thôi, hay cả ứng dụng cho tài xế? Đây thường là hai luồng xác thực khác nhau - phần lớn doanh nghiệp chỉ cần SSO cho tài khoản nội bộ của đội vận hành, không cần cho tài xế sử dụng dịch vụ.
- Nếu hệ thống định danh gặp sự cố thì sao? Hãy xác nhận có một phương án dự phòng được quy định rõ, để đội vận hành không bị khóa hoàn toàn khỏi màn hình quản trị khi chính hệ thống định danh gặp vấn đề.
- SSO có bị giới hạn theo gói dịch vụ? Một số nhà cung cấp coi việc tích hợp định danh doanh nghiệp là tính năng mua thêm chứ không phải năng lực cơ bản - nên biết trước khi điều đó trở thành điểm thương lượng ở giai đoạn cuối.
CarChargeOS hỗ trợ SAML và OIDC như một phần của tầng tích hợp, với phân quyền theo vai trò được ánh xạ từ nhóm định danh doanh nghiệp - xem toàn bộ năng lực tích hợp và bảo mật tại trang nền tảng.
Câu hỏi thường gặp
Đội vận hành nhỏ thì có cần SSO không?
Quy mô nhỏ thì mức độ cần thiết thấp hơn, nhưng yêu cầu này thường không xuất phát từ số lượng nhân sự - nó xuất phát từ bộ phận chịu trách nhiệm về chính sách an ninh. Nhiều doanh nghiệp yêu cầu SSO cho mọi hệ thống có quyền vận hành, bất kể thực tế có bao nhiêu người sử dụng.
SSO có phải là xác thực đa yếu tố (MFA) không?
Không. SSO chuyển việc đăng nhập sang hệ thống định danh của doanh nghiệp; MFA là chính sách mà hệ thống định danh đó áp dụng lên lần đăng nhập. Khi nền tảng sạc đã hỗ trợ SSO, MFA thường được thừa hưởng tự động từ những gì hệ thống định danh vốn đã yêu cầu.
Tài xế có dùng chung SSO với người vận hành được không?
Thường là không, và cũng không nên - SSO cho người vận hành tích hợp với hệ thống định danh nội bộ của doanh nghiệp, còn tài xế xác thực qua ứng dụng thương hiệu riêng với luồng đăng ký riêng. Gộp hai luồng này là một lỗi thiết kế thường gặp, cần lưu ý khi đọc đề xuất của nhà cung cấp.