Ngày 10 tháng 3 năm 2023Tin tức về tin tặcXác thực đa yếu tố
Xác thực đa yếu tố (MFA) từ lâu đã trở thành một thông lệ bảo mật tiêu chuẩn. Với sự đồng thuận rộng rãi về khả năng chống lại hơn 99% phần trăm các cuộc tấn công chiếm đoạt tài khoản, không có gì ngạc nhiên tại sao các kiến trúc sư bảo mật lại coi nó là thứ bắt buộc phải có trong môi trường của họ. Tuy nhiên, điều dường như ít được biết đến là những hạn chế về phạm vi phủ sóng cố hữu của các giải pháp MFA truyền thống. Mặc dù tương thích với kết nối RDP và thông tin đăng nhập trên máy tính để bàn cục bộ, chúng không cung cấp sự bảo vệ nào đối với các công cụ truy cập dòng lệnh từ xa như PsExec, Remote powershell và các công cụ tương tự của chúng.
Trên thực tế, điều đó có nghĩa là các máy trạm và máy chủ vẫn dễ bị di chuyển ngang, lây lan mã độc tống tiền và các mối đe dọa nhận dạng khác mặc dù đã bật giải pháp MFA đầy đủ chức năng. Đối với kẻ thù, vấn đề chỉ là sử dụng đường dẫn dòng lệnh thay vì RDP để đăng nhập như thể không có cài đặt bảo vệ nào cả. Trong bài viết này, chúng ta sẽ khám phá điểm mù này, hiểu nguyên nhân gốc rễ và ý nghĩa của nó, đồng thời xem các tùy chọn khác nhau mà các nhóm bảo mật có thể khắc phục để duy trì môi trường của họ được bảo vệ.
Mục đích cốt lõi của MFA: Ngăn chặn đối thủ truy cập tài nguyên của bạn bằng thông tin xác thực bị xâm phạm
MFA biện pháp bảo mật hiệu quả nhất một lần nữa tiếp quản tài khoản. Lý do chúng tôi có MFA ngay từ đầu là để ngăn chặn kẻ thù truy cập tài nguyên của chúng tôi bằng thông tin đăng nhập bị xâm phạm. Vì vậy, ngay cả khi kẻ tấn công có thể nắm giữ tên người dùng và mật khẩu của chúng tôi – đây là một tình huống hợp lý hơn – thì kẻ tấn công vẫn không thể tận dụng chúng để truy cập độc hại thay cho chúng tôi. Vì vậy, đó là tuyến phòng thủ cuối cùng cuối cùng chống lại sự thỏa hiệp thông tin xác thực, nhằm mục đích vô hiệu hóa sự thỏa hiệp này dưới bất kỳ hình thức lợi ích nào.
Điểm mù: MFA không được hỗ trợ bởi Công cụ truy cập dòng lệnh trong môi trường Active Directory
Mặc dù MFA hoàn toàn có thể bao gồm quyền truy cập vào SaaS và các ứng dụng web nhưng nó bị hạn chế hơn đáng kể khi nói đến môi trường được quản lý Active Directory. Điều này là do các giao thức xác thực chính được sử dụng trong môi trường này, NTLM và Kerberos, đã được viết trước khi MFA tồn tại và không hỗ trợ giao thức này. Điều đó có nghĩa là mọi phương thức xác thực thực hiện các giao thức này đều không thể được bảo vệ bằng MFA. Điều đó bao gồm mọi công cụ truy cập từ xa dựa trên CMD và PowerShell, trong đó những công cụ nổi bật nhất là PsExec và Remote PowerShell. Đây là những công cụ mặc định mà quản trị viên sử dụng để kết nối từ xa với máy của người dùng nhằm mục đích khắc phục sự cố và bảo trì và do đó thực tế được tìm thấy trong mọi môi trường AD.
Ý nghĩa của an ninh mạng: Chuyển động bên và tấn công ransomware không gặp phải sự phản kháng.
Theo định nghĩa, đường dẫn kết nối từ xa chính thống này không được bảo vệ khỏi kịch bản thông tin đăng nhập bị xâm phạm và kết quả là nó được sử dụng trong hầu hết các cuộc tấn công lây lan chuyển động bên và phần mềm tống tiền. Không có vấn đề gì khi có một giải pháp MFA bảo vệ kết nối RDP và ngăn không cho chúng bị lạm dụng. Đối với kẻ tấn công, việc di chuyển từ máy không có bệnh nhân sang các máy trạm khác trong môi trường bằng PsExec hoặc Remote PowerShell cũng dễ dàng như thực hiện với RDP. Đó chỉ là vấn đề sử dụng một cánh cửa thay vì cánh cửa kia.
Bạn có được bảo vệ như bạn nên được không? Có lẽ đã đến lúc bạn đánh giá lại MFA của mình. Để theo dõi, hãy khám phá Sách điện tử này để tìm hiểu thêm về phương pháp Bảo vệ danh tính hợp nhất của Silverfort đối với MFA và hiểu rõ hơn về cách đánh giá các biện pháp bảo vệ hiện có và mức độ rủi ro tương đối của bạn.
Sự thật phũ phàng: Bảo vệ MFA một phần không phải là sự bảo vệ nào cả
Vì vậy, nếu bạn đã trải qua khó khăn khi cài đặt các tác nhân MFA trên tất cả các máy chủ và máy trạm quan trọng của mình, thì hầu hết các khả năng là bạn đã đạt được rất ít trong việc thực sự bảo vệ chúng khỏi các mối đe dọa danh tính. Đây là một trong những trường hợp bạn không thể đi nửa đường. Đó là hoặc bạn được bảo vệ hoặc bạn không. Khi có một cái lỗ dưới đáy thuyền thì chẳng có gì khác biệt vì tất cả phần còn lại của nó đều là gỗ cứng. Và theo cách tương tự, nếu kẻ tấn công có thể di chuyển ngang trong môi trường của bạn bằng cách cung cấp thông tin xác thực bị xâm phạm cho các công cụ truy cập dòng lệnh, thì việc bạn có bảo vệ MFA cho RDP và đăng nhập máy tính để bàn không còn quan trọng nữa.
Các hạn chế của MFA trong môi trường tại chỗ cũng khiến tài nguyên đám mây của bạn gặp rủi ro
Bất chấp việc chuyển sang đám mây, hơn 90% tổ chức vẫn duy trì cơ sở hạ tầng nhận dạng kết hợp với cả máy trạm và máy chủ được quản lý bởi AD, cũng như các ứng dụng SaaS và khối lượng công việc trên đám mây. Vì vậy, không chỉ các tài nguyên cốt lõi tại chỗ như các ứng dụng cũ và tệp chia sẻ bị lộ khi sử dụng thông tin đăng nhập bị xâm phạm do thiếu bảo vệ MFA, mà cả các ứng dụng SaaS nữa.
Thực tiễn phổ biến hiện nay là đồng bộ hóa mật khẩu giữa tất cả các tài nguyên này, do đó, cùng một tên người dùng và mật khẩu được sử dụng để truy cập cả máy chủ tệp tại chỗ cũng như ứng dụng SaaS của tổ chức. Điều này có nghĩa là bất kỳ cuộc tấn công tại chỗ nào bao gồm việc thỏa hiệp và sử dụng thông tin đăng nhập của người dùng đều có thể dễ dàng xoay vòng để truy cập trực tiếp vào tài nguyên SaaS từ các máy bị tấn công.
Chuyển đổi mô hình: Từ MFA truyền thống sang Bảo vệ danh tính thống nhất
Lỗ hổng mà chúng tôi đã mô tả bắt nguồn từ cách MFA truyền thống được thiết kế và triển khai. Hạn chế chính là các giải pháp MFA ngày nay gắn liền với quá trình xác thực của từng tài nguyên riêng lẻ, vì vậy nếu phần mềm thực hiện xác thực này không hỗ trợ MFA – như trong các công cụ truy cập dòng lệnh AD – thì không thể có điểm bảo vệ trống.
Tuy nhiên, ngày nay có một cách tiếp cận mới chuyển trọng tâm từ việc đặt MFA ở từng tài nguyên riêng lẻ sang thư mục, vượt qua hoàn toàn rào cản.
Silverfort đi tiên phong trong nền tảng Bảo vệ Danh tính Hợp nhất đầu tiên có thể mở rộng MFA cho bất kỳ tài nguyên nào, bất kể tài nguyên đó có hỗ trợ MFA hay không. Bằng cách sử dụng công nghệ không có tác nhân và không có proxy, Silverfort tích hợp trực tiếp với AD. Với sự tích hợp này, bất cứ khi nào AD nhận được yêu cầu truy cập, AD sẽ đợi phán quyết đó và chuyển tiếp yêu cầu đó tới Silverfort. Sau đó, Silverfort sẽ phân tích yêu cầu truy cập và nếu cần, sẽ thách thức người dùng bằng MFA. Dựa trên phản hồi của người dùng, Silverfort xác định có nên tin tưởng người dùng hay không và chuyển phán quyết cho AD để cấp hoặc từ chối quyền truy cập tương ứng.
Sự đổi mới trong cách tiếp cận này là việc yêu cầu truy cập này được thực hiện qua RDP hay dòng lệnh và liệu nó có hỗ trợ MFA hay không không còn quan trọng nữa. Miễn là nó được gửi cho AD, thì AD có thể chuyển nó cho Silverfort. Vì vậy, bằng cách chuyển từ bảo vệ MFA ở cấp tài nguyên sang bảo vệ MFA ở cấp thư mục, điểm mù mà kẻ thù đang lạm dụng trong nhiều năm cuối cùng đã được giải quyết và bảo mật.
Tìm cách tìm hiểu thêm về cách áp dụng MFA cho tất cả các tài nguyên của bạn? Ghé thăm chúng tôi tại https://www.silverfort.com/
