Tháng trước tôi đã viết một bài viết về cách các nền tảng mã thấp / không có mã đang cung cấp dịch vụ chia sẻ thông tin đăng nhập, lý do tại sao họ làm điều đó và cách thức hoạt động này diễn ra như thế nào quan điểm của kẻ tấn công. Trong bài viết này, tôi sẽ tập trung vào tác động của thỏa hiệp đó và ảnh hưởng của nó đến các doanh nghiệp ngày nay như thế nào.
Đây là lý do tại sao việc chia sẻ thông tin đăng nhập doanh nghiệp của bạn với người khác là một cách làm không tốt. Giả sử tôi muốn chuyển thông tin đăng nhập của mình cho một đồng nghiệp để truy vấn nhật ký sản xuất cho một số phân tích hành vi người dùng một lần. Trong một doanh nghiệp điển hình, việc cấp cho ai đó quyền truy vấn nguồn dữ liệu mới có nghĩa là một quá trình xem xét quyền truy cập lâu dài, đặc biệt khi liên quan đến dữ liệu sản xuất hoặc dữ liệu nhạy cảm. Đồng nghiệp của tôi có thể dễ dàng thất vọng. “Tất cả những gì tôi muốn là thực hiện truy vấn nhỏ này một lần duy nhất và tôi đã chờ đợi một tháng!” họ có thể nói. Tôi chỉ có thể chạy truy vấn cho chúng, nhưng tôi đang ngập đầu trong các công việc hàng ngày của riêng mình và các truy vấn một lần có xu hướng trở nên phức tạp.
Tôi chỉ còn lại một giải pháp nhanh chóng: Tôi chỉ có thể chia sẻ tên người dùng / mật khẩu của mình với đồng nghiệp của mình. Nếu họ nhận được một thử thách MFA, tôi sẽ sẵn lòng chấp thuận. Tôi không phải mất thời gian chạy truy vấn và đồng nghiệp của tôi được bỏ chặn. Mọi người đều thắng! Đúng?
Chà, bạn sẽ đúng trong phân tích của mình, nhưng bạn đang bỏ lỡ bức tranh lớn hơn. Mặc dù điều quan trọng đối với doanh nghiệp là đồng nghiệp của bạn thực hiện phân tích hành vi người dùng của họ, nhưng điều quan trọng không kém là doanh nghiệp của bạn phải tuân thủ toàn bộ các tiêu chuẩn về quyền riêng tư và bảo mật cũng như duy trì sự tin tưởng của khách hàng bằng cách duy trì cam kết của công ty về bảo mật .
Nếu các mục tiêu doanh nghiệp cấp cao không thuyết phục bạn, hãy xem xét các nhóm quản lý trung tâm về CNTT hoặc bảo mật. Các nhóm này dựa trên các hoạt động và chiến lược bảo mật của họ dựa trên thực tế là mỗi người dùng có danh tính riêng của họ. Các nhóm CNTT đang thiết lập các chính sách mạng và truy cập giả định rằng mỗi người dùng sẽ đăng nhập từ một IP của công ty hoặc máy tính xách tay của công ty cùng một lúc; nhóm bảo mật đang tương quan các sự kiện dựa trên ID người dùng; nhóm tài chính có thể tổng hợp báo cáo chi phí cho mỗi người dùng và môi trường đám mây cá nhân của họ. Chia sẻ thông tin xác thực làm suy yếu tất cả những giả định đó, trong số những giả định khác. Nó tước bỏ ý nghĩa cơ bản của danh tính trực tuyến.
Một ví dụ trong thế giới thực
Hãy chuyển sang thế giới của mã thấp / không mã và xem xét một kịch bản trong thế giới thực. Trong một doanh nghiệp lớn, Jane, một nhân viên được truyền cảm hứng từ nhóm chăm sóc khách hàng, nhận ra rằng khi nhân viên trong toàn tổ chức tham gia vào một trường hợp khách hàng, họ thường thiếu thông tin quan trọng về khách hàng, chẳng hạn như lịch sử trường hợp hỗ trợ của họ và các giao dịch mua mới nhất. Điều này làm giảm trải nghiệm của khách hàng, vì họ phải giải thích vấn đề của mình nhiều lần trong khi vụ việc được chuyển đến đúng nhân viên có thể giải quyết vấn đề.
Để cải thiện điều này, Jane đã tạo một ứng dụng cho phép nhân viên của công ty xem thông tin quan trọng này về khách hàng khi những nhân viên đó là một phần của nhóm chịu trách nhiệm giải quyết trường hợp hỗ trợ của khách hàng. Trước tiên, chúng ta hãy dành một chút thời gian để thừa nhận sức mạnh của mã thấp / không mã, cho phép Jane xác định nhu cầu và tự giải quyết nó mà không cần yêu cầu ngân sách hoặc chờ phân bổ tài nguyên CNTT.
Trong khi xây dựng ứng dụng, Jane đã phải giải quyết nhiều vấn đề, trong đó vấn đề lớn nhất là quyền. Nhân viên trong toàn tổ chức không có quyền truy cập trực tiếp để truy vấn cơ sở dữ liệu khách hàng để lấy thông tin họ cần. Nếu họ làm như vậy, thì Jane sẽ không phải xây dựng ứng dụng này. Để khắc phục sự cố này, Jane đã đăng nhập vào cơ sở dữ liệu và nhúng phiên xác thực của mình trực tiếp vào ứng dụng. Khi ứng dụng nhận được yêu cầu từ một người dùng, nó sẽ sử dụng danh tính của Jane để thực hiện truy vấn đó và sau đó trả lại kết quả cho người dùng. Tính năng nhúng thông tin xác thực này, như chúng ta đã khám phá vào tháng trước, là một tính năng chính của các nền tảng mã thấp / không mã. Jane đảm bảo thiết lập kiểm soát truy cập dựa trên vai trò (RBAC) trong ứng dụng sao cho mọi người dùng chỉ có thể truy cập các trường hợp khách hàng mà họ được chỉ định.
Ứng dụng đã giải quyết một vấn đề kinh doanh quan trọng và do đó nó nhanh chóng được người dùng chấp nhận trên toàn doanh nghiệp. Mọi người rất vui vì họ có thể cung cấp dịch vụ tốt hơn cho khách hàng bằng cách có bối cảnh phù hợp cho cuộc trò chuyện. Khách hàng cũng rất vui. Một tháng sau khi Jane tạo ra ứng dụng, nó đã được hàng trăm người dùng trên toàn tổ chức sử dụng, với tỷ lệ hài lòng của khách hàng đang tăng lên.
Trong khi đó tại SOC, một cảnh báo mức độ nghiêm trọng cao cho thấy hoạt động bất thường xung quanh cơ sở dữ liệu khách hàng sản xuất đã được kích hoạt và giao cho Amy, một nhà phân tích bảo mật có kinh nghiệm. Điều tra ban đầu của Amy cho thấy một người dùng nội bộ đang cố gắng thu thập toàn bộ cơ sở dữ liệu, truy vấn thông tin về nhiều khách hàng từ nhiều địa chỉ IP trong toàn tổ chức. Mẫu truy vấn rất phức tạp; thay vì một mẫu liệt kê đơn giản mà bạn mong đợi để xem khi cơ sở dữ liệu đang được thu thập, dữ liệu của cùng một khách hàng đã được truy vấn nhiều lần, đôi khi thông qua các địa chỉ IP khác nhau và vào các ngày khác nhau. Đây có thể là một kẻ tấn công đang cố gắng làm nhầm lẫn các hệ thống giám sát an ninh?
Sau một cuộc điều tra nhanh, Amy đã phát hiện ra một thông tin quan trọng: Tất cả các truy vấn trên tất cả các địa chỉ IP và ngày tháng đều sử dụng một danh tính người dùng duy nhất, một người tên là Jane từ nhóm chăm sóc khách hàng.
Amy đã tìm đến Jane để hỏi cô ấy chuyện gì đang xảy ra. Lúc đầu, Jane không biết. Có phải thông tin đăng nhập của cô ấy bị đánh cắp? Có phải cô ấy đã nhấp vào liên kết sai hoặc tin tưởng vào email gửi đến không chính xác? Nhưng khi Jane nói với Amy về ứng dụng mà cô ấy đã xây dựng gần đây, cả hai đều nhận ra có thể có một mối liên hệ nào đó. Amy, nhà phân tích SOC, không quen với mã thấp / không mã, vì vậy họ đã liên hệ với nhóm AppSec. Với sự giúp đỡ của Jane, nhóm nghiên cứu đã phát hiện ra rằng ứng dụng của Jane có thông tin đăng nhập của Jane được nhúng trong đó. Từ quan điểm của cơ sở dữ liệu, không có ứng dụng nào - chỉ có Jane, thực hiện rất nhiều truy vấn.
Jane, Amy và nhóm AppSec đã quyết định tắt ứng dụng cho đến khi tìm ra giải pháp. Người dùng ứng dụng trong toàn tổ chức đã thất vọng vì họ đã dựa vào nó và khách hàng cũng cảm thấy điều đó.
Trong khi Amy giải quyết vấn đề và ghi lại những phát hiện của họ, thì Phó chủ tịch bộ phận chăm sóc khách hàng không hài lòng khi thấy tỷ lệ hài lòng của khách hàng giảm xuống, vì vậy họ đã yêu cầu Jane tìm kiếm một giải pháp lâu dài. Với sự trợ giúp của tài liệu của nền tảng và nhóm Trung tâm xuất sắc của tổ chức, Jane đã xóa danh tính nhúng của mình khỏi ứng dụng, thay đổi ứng dụng để sử dụng danh tính của từng người dùng để truy vấn cơ sở dữ liệu và đảm bảo người dùng chỉ có quyền đối với các trường hợp khách hàng mà họ liên kết . Trong phiên bản mới và cải tiến của nó, ứng dụng đã sử dụng danh tính của từng người dùng để truy vấn cơ sở dữ liệu khách hàng. Jane và những người dùng ứng dụng rất vui vì ứng dụng đã trực tuyến trở lại, Amy và nhóm AppSec rất vui vì danh tính của Jane không còn được chia sẻ nữa và doanh nghiệp đã thấy tỷ lệ hài lòng của khách hàng bắt đầu tăng trở lại. Tất cả đều ổn rồi.
Hai tuần sau, SOC nhận được một cảnh báo khác về việc truy cập bất thường vào cơ sở dữ liệu khách hàng sản xuất. Nó trông giống một cách đáng ngờ với cảnh báo trước đó trên cùng cơ sở dữ liệu đó. Một lần nữa, các địa chỉ IP từ khắp tổ chức đang sử dụng danh tính của một người dùng duy nhất để truy vấn cơ sở dữ liệu. Một lần nữa, người dùng đó là Jane. Nhưng lần này, nhóm bảo mật và Jane biết rằng ứng dụng sử dụng danh tính của người dùng. Chuyện gì đang xảy ra vậy?
Cuộc điều tra cho thấy rằng ứng dụng ban đầu có chia sẻ ngầm Phiên cơ sở dữ liệu đã xác thực của Jane với người dùng của ứng dụng. Bằng cách chia sẻ ứng dụng với người dùng, người dùng đó có quyền truy cập trực tiếp vào liên quan, một trình bao bọc xung quanh một phiên cơ sở dữ liệu đã xác thực được cung cấp bởi nền tảng của mã thấp / không có mã. Sử dụng kết nối đó, người dùng có thể tận dụng phiên được xác thực trực tiếp - họ không còn phải truy cập ứng dụng. Hóa ra là một số người dùng đã phát hiện ra điều này và nghĩ rằng đây là hành vi dự kiến, đã sử dụng phiên cơ sở dữ liệu đã được xác thực của Jane để chạy các truy vấn của họ. Họ yêu thích giải pháp này, vì việc sử dụng kết nối trực tiếp cho phép họ toàn quyền truy cập vào cơ sở dữ liệu, không chỉ cho các trường hợp khách hàng mà họ được chỉ định.
Kết nối đã bị xóa và sự cố đã kết thúc. Nhà phân tích SOC đã liên hệ với những người dùng đã sử dụng kết nối của Jane để đảm bảo họ loại bỏ mọi dữ liệu khách hàng mà họ đã lưu trữ.
Giải quyết Thách thức Bảo mật Mã thấp / Không Mã
Câu chuyện trên là một kịch bản thực tế của một công ty B2C đa quốc gia. Một số chi tiết đã được bỏ qua hoặc điều chỉnh để bảo vệ quyền riêng tư. Chúng tôi đã thấy cách một nhân viên có thiện chí có thể vô tình chia sẻ danh tính của họ với những người dùng khác, gây ra hàng loạt vấn đề về CNTT, bảo mật và doanh nghiệp. Như chúng tôi đã khám phá vào tháng trước, chia sẻ thông tin xác thực là một tính năng chính của mã thấp / không mã. Đó là tiêu chuẩn, không phải là ngoại lệ.
As mã thấp / không mã tiếp tục nở rộ trong doanh nghiệp, có ý thức hay không, điều quan trọng là các nhóm bảo mật và CNTT phải tham gia cuộc trò chuyện phát triển kinh doanh. Các ứng dụng ít mã / không có mã đi kèm với tập hợp các thách thức bảo mật duy nhất, và bản chất sung mãn của chúng có nghĩa là những thách thức đó trở nên cấp bách nhanh hơn bao giờ hết.
