Tại sao phải bảo vệ mật khẩu nếu có thể không dùng đến nó?

Vấn đề mà chúng ta đã quen xem là bình thường

Hầu như ứng dụng web nào cũng có bảng điều khiển quản trị. Và bảng điều khiển quản trị thường có địa chỉ đăng nhập, biểu mẫu xác thực, tên đăng nhập và mật khẩu.

Chúng ta đã quá quen với cấu trúc này đến mức gần như không còn tự hỏi: liệu mọi thứ có nhất thiết phải hoạt động theo cách đó không?

Khi bạn chỉ có một trang web, vấn đề dường như không đáng kể. Tạo mật khẩu phức tạp, bật xác thực hai yếu tố, thiết lập giới hạn số lần đăng nhập — rồi tiếp tục công việc.

Nhưng điều gì xảy ra khi số lượng dự án tăng lên mười, hai mươi hay ba mươi?

Trong trường hợp của tôi, đó là hệ sinh thái DigiMeld, gồm hơn ba mươi dự án phần mềm độc lập. Mỗi dự án có kiến trúc, logic máy chủ và giao diện quản trị riêng.

Vì vậy, mỗi dự án đều cần một cơ chế truy cập quản trị.

Trong thời gian dài, tôi sử dụng cách làm khá quen thuộc: thông tin đăng nhập quản trị riêng, mật khẩu phức tạp và lưu chúng trong trình duyệt.

Cách đó vẫn hoạt động.

Nhưng đến một lúc, tôi bắt đầu tự hỏi: tại sao mình phải lưu nhiều mật khẩu quản trị đến vậy? Tại sao tôi phải bảo vệ không chỉ máy chủ mà cả những phương tiện dùng để truy cập chúng?

Liệu có thể không cần đến điều đó không?

Tôi đi đến một ý tưởng mà sau này trở thành nền tảng cho giải pháp của mình:

Có lẽ thay vì bảo vệ một cổng truy cập luôn tồn tại, ta nên bảo vệ chính quyền được cấp quyền truy cập tạm thời.

Nếu hoàn toàn không có trang đăng nhập quen thuộc thì sao?

Tôi quyết định từ bỏ mô hình xác thực quản trị truyền thống trong các dự án của mình.

Không chỉ đơn thuần ẩn biểu mẫu đăng nhập.

Không đổi tên đường dẫn.

Không thay mật khẩu bằng một mật khẩu còn phức tạp hơn.

Mà loại bỏ sự cần thiết phải duy trì một cổng đăng nhập bằng mật khẩu luôn tồn tại.

Dĩ nhiên, các giao diện quản trị vẫn ở đó. Chúng vẫn cần thiết để quản lý ứng dụng.

Điều thay đổi là cách truy cập vào chúng.

Giờ đây, để đăng nhập vào bảng điều khiển quản trị của các dự án đã kết nối, tôi không cần nhập tên đăng nhập và mật khẩu đã lưu.

Thay vào đó, tôi sử dụng hệ thống nhận dạng và quản lý quyền truy cập của riêng mình mang tên MeldID.

Ý tưởng khá đơn giản: quyền truy cập quản trị chỉ được cấp khi thực sự cần, cho một người dùng cụ thể và một dự án cụ thể.

Hơn nữa, chỉ có tài khoản thôi không có nghĩa là người dùng được phép mở bảng điều khiển quản trị.

Quyền đó phải được cấp riêng.

Quyền truy cập chưa tồn tại cách đây một phút

Đây có lẽ là phần thú vị nhất của toàn bộ ý tưởng.

Trong mô hình truyền thống, quản trị viên luôn có sẵn phương tiện đăng nhập. Họ có thể sử dụng chúng hôm nay, ngày mai hay một tháng sau, miễn là những thông tin đó còn hiệu lực.

Tôi quyết định thay đổi nguyên tắc này.

Thay vì thông tin đăng nhập quản trị cố định, hệ thống sử dụng khả năng khởi tạo đăng nhập có thời hạn.

Khả năng này được tạo theo yêu cầu thông qua một thiết bị di động đáng tin cậy, có thành phần ngẫu nhiên mạnh về mặt mật mã và thời hạn hiệu lực giới hạn.

Nhưng ngay cả khi có liên kết tạm thời đó, người dùng vẫn chưa mặc nhiên được cấp quyền truy cập.

Đây là điểm cốt yếu.

Giả sử ai đó bằng cách nào đó lấy được liên kết. Trong một hệ thống thông thường chỉ dựa vào việc giữ bí mật địa chỉ, sự rò rỉ như vậy có thể trở thành vấn đề nghiêm trọng.

Trong mô hình của tôi, liên kết chỉ cho phép bắt đầu quy trình xác nhận.

Để tiếp tục, cần có một sự cho phép riêng thông qua thiết bị di động đáng tin cậy MeldID.

Nếu không có xác nhận tương ứng, phiên quản trị sẽ không được tạo.

Đó là lý do tôi xem liên kết tạm thời không phải là thứ thay thế mật khẩu, mà là một phần của quy trình cấp quyền truy cập.

Biết cần truy cập vào đâu và có quyền đăng nhập là hai chuyện hoàn toàn khác nhau.

Điện thoại trở thành công cụ quản lý quyền truy cập

Trong mô hình này, thiết bị di động đóng vai trò quan trọng hơn nhiều so với một trình tạo mã dùng một lần thông thường.

Nó được dùng để xác nhận các hành động liên quan đến quyền truy cập quản trị.

Khi muốn mở bảng điều khiển quản trị, hệ thống yêu cầu xác nhận thông qua MeldID.

Tôi thấy yêu cầu tương ứng trên thiết bị đáng tin cậy và xác nhận hành động.

Chỉ sau khi xác minh thành công, hệ thống mới cho phép tiếp tục quy trình đăng nhập.

Việc xác nhận gắn với một hành động cụ thể, chứ không chỉ đơn thuần với việc điện thoại được mở khóa.

Sinh trắc học trên thiết bị di động giúp xác minh người dùng tại chỗ, còn phía máy chủ kiểm tra xác nhận mật mã từ thiết bị đã đăng ký.

Cách tiếp cận này giúp chúng ta không phải chỉ dựa vào mật khẩu hoặc thông báo rằng người dùng được cho là đã xác nhận đăng nhập.

Và ở đây xuất hiện thêm một ưu điểm: có thể quản lý các thiết bị đáng tin cậy.

Nếu không còn nên dùng một thiết bị để xác nhận quyền truy cập, trạng thái đáng tin cậy của thiết bị đó có thể bị thu hồi.

Sau đó, thiết bị sẽ không còn là phương tiện xác thực hợp lệ cho các thao tác tương ứng.

Một hệ thống — nhiều dự án độc lập

Khi bắt đầu phát triển cơ chế này, một trong những nhiệm vụ chính là giữ cho mỗi dự án hoạt động độc lập.

Tôi không muốn gộp tất cả bảng điều khiển quản trị vào một ứng dụng khổng lồ.

Mỗi dịch vụ DigiMeld vẫn cần tự quản lý logic, cài đặt, người dùng và dữ liệu của mình.

Vì vậy, tôi tách riêng hai nhiệm vụ.

MeldID chịu trách nhiệm nhận dạng và cấp quyền truy cập quản trị.

Còn bản thân dự án phụ trách các chức năng quản trị riêng và xác minh các quyền hạn đang có hiệu lực.

Kết quả là mô hình quản lý quyền truy cập tập trung mà không cần tập trung hóa chính các ứng dụng.

Ngoài ra, quyền được cấp riêng biệt.

Quản trị viên của một dự án không tự động có quyền truy cập vào những dự án còn lại chỉ vì họ có tài khoản MeldID.

Có thể xác định nhóm người dùng được cấp quyền riêng cho từng phạm vi quản trị.

Đồng thời, quyền của người dùng thông thường và quyền quản trị được tách biệt.

Điều này đặc biệt hữu ích đối với một hệ sinh thái gồm hàng chục dịch vụ.

Vì sao tôi thích quyền truy cập tạm thời hơn quyền truy cập thường trực

Còn một nguyên tắc nữa mà tôi chủ động đưa vào hệ thống.

Quyền truy cập quản trị không nên tồn tại vô thời hạn.

Quyền chỉ có hiệu lực trong một khoảng thời gian giới hạn và sẽ hết hạn bất kể người dùng có tiếp tục làm việc trong trình duyệt hay không.

Muốn tiếp tục làm việc sau khi hết hạn, người dùng phải thực hiện lại quy trình xác nhận.

Nhờ vậy, một lần xác thực không biến thành quyền truy cập có hiệu lực mãi mãi.

Tuy nhiên, chỉ giới hạn thời gian là chưa đủ.

Khả năng chấm dứt quyền truy cập đã cấp trước thời hạn cũng rất quan trọng.

Vì vậy, MeldID có chức năng thu hồi quyền quản trị tập trung.

Khi quyền bị thu hồi, các dự án đã kết nối nhận được sự kiện tương ứng và hủy các phiên quản trị liên quan.

Như vậy, việc quản lý quyền truy cập không kết thúc ngay khi người dùng đăng nhập thành công.

Đối với tôi, khả năng thu hồi quyền hạn cũng quan trọng không kém khả năng cấp quyền.

Đồng thời, hệ thống phân tán phải tính đến độ trễ khi truyền sự kiện, tình trạng một số thành phần tạm thời không khả dụng và các tình huống vận hành khác. Thời hạn của phiên truy cập tạo thêm một ranh giới bảo vệ.

Công việc hằng ngày đã thay đổi ra sao?

Trước hết, tôi không còn cần thường xuyên tìm đến các mật khẩu quản trị đã lưu.

Tôi không còn phải lưu trong trình duyệt một bộ thông tin đăng nhập cho từng bảng điều khiển quản trị đã kết nối.

Thay vào đó, tôi quản lý quyền thông qua một cơ chế thống nhất.

Chọn dự án cần thiết, xác nhận quyền truy cập và làm việc.

Khi không còn cần quyền truy cập quản trị, tôi có thể thu hồi quyền đó.

Điều đặc biệt tiện lợi là khi có dự án mới, tôi không cần thiết kế lại toàn bộ hệ thống xác thực quản trị từ đầu.

Chỉ cần kết nối dự án đó với mô hình hiện có và xác định các quyền cần thiết.

Dĩ nhiên, điều này không có nghĩa là mọi rủi ro bảo mật đều biến mất.

Quyền tạm thời, thiết bị đáng tin cậy, phiên máy chủ và hạ tầng trung tâm cũng cần được bảo vệ.

Nhưng tôi không còn phải giải quyết riêng cùng một bài toán quản lý mật khẩu quản trị cho từng ứng dụng.

Và đó chính là một trong những mục tiêu ban đầu của tôi.

Chẳng phải những công nghệ như vậy đã tồn tại rồi sao?

Dĩ nhiên là có.

Xác thực không mật khẩu, quản lý quyền truy cập đặc quyền, quyền tạm thời và xác nhận thông qua thiết bị đáng tin cậy đã được biết đến từ lâu trong ngành an toàn thông tin.

Các cách tiếp cận này xuất hiện trong những hệ thống Quản lý danh tính và quyền truy cập (Identity and Access Management), Quản lý quyền truy cập đặc quyền (Privileged Access Management) và các mô hình Zero Trust.

Tôi không nhận mình đã phát minh ra những nguyên tắc này.

Nhiệm vụ của tôi là một việc khác.

Tôi cần tạo ra một hệ thống tích hợp của riêng mình để giải quyết những vấn đề cụ thể của hạ tầng DigiMeld và giúp quản lý quyền truy cập quản trị cho nhiều dự án độc lập.

Kết quả là tôi kết hợp một số cách tiếp cận đã được biết đến vào cùng một kiến trúc, phù hợp với các yêu cầu của mình.

Và tôi cho rằng giá trị của công việc kỹ thuật không nhất thiết phải nằm ở việc phát minh ra một công nghệ hoàn toàn mới.

Đôi khi, giá trị ấy nằm ở việc xác định đúng vấn đề và tìm ra giải pháp phù hợp.

MeldID không chỉ dành cho bảng điều khiển quản trị

Cần làm rõ thêm một điểm ở đây.

MeldID không được tạo ra chỉ để phục vụ quyền truy cập quản trị của riêng tôi.

Nền tảng này cũng cung cấp SDK cho nhà phát triển để tích hợp các cơ chế nhận dạng và xác nhận đăng nhập vào ứng dụng của họ.

SDK này được cung cấp miễn phí.

Chẳng hạn, nhà phát triển bên ngoài có thể dùng MeldID như một lớp xác nhận bổ sung cho quy trình xác thực người dùng.

Ngay cả khi ứng dụng vẫn giữ cách đăng nhập truyền thống bằng tên đăng nhập và mật khẩu, nhập đúng thông tin đó vẫn có thể chưa đủ để hoàn tất xác thực.

Người dùng sẽ nhận được yêu cầu trên thiết bị di động đáng tin cậy, tại đó họ có thể xác nhận hoặc từ chối lần đăng nhập.

Điều này giúp giảm nguy cơ truy cập trái phép khi thông tin đăng nhập bị xâm phạm.

Điều quan trọng là phải phân biệt khả năng công khai này của MeldID với mô hình quản lý quyền truy cập quản trị mà tôi phát triển cho các dự án DigiMeld.

Hai giải pháp có chung các nguyên tắc về độ tin cậy và xác nhận hành động, nhưng giải quyết những vấn đề khác nhau.

Bảo mật không chỉ là bảo vệ những gì đang tồn tại

Quá trình phát triển hệ thống này khiến tôi nhìn các cơ chế xác thực quen thuộc theo một cách khác.

Chúng ta thường cố bảo vệ những thứ tồn tại vì lý do lịch sử.

Thêm các bước kiểm tra mới, giới hạn, mật khẩu bổ sung và lớp bảo vệ.

Đôi khi điều đó thực sự cần thiết.

Nhưng đôi khi, đặt một câu hỏi khác sẽ hữu ích hơn:

Liệu cơ chế mà chúng ta đang bảo vệ có nhất thiết phải tiếp tục tồn tại theo cách cũ không?

Trong trường hợp của tôi, câu trả lời là không.

Tôi không cần một biểu mẫu đăng nhập quản trị luôn có thể truy cập.

Tôi cần khả năng nhận quyền quản trị một cách an toàn, đúng vào lúc cần thiết.

Đó là hai nhiệm vụ khác nhau.

Việc chuyển từ nhiệm vụ thứ nhất sang nhiệm vụ thứ hai đã thay đổi không chỉ kiến trúc kỹ thuật mà cả cách tôi làm việc hằng ngày với các dự án.

Không phải điểm kết thúc, mà là hướng đi đã chọn

Ngày nay, kiến trúc này đã hoạt động trong phần lớn hệ sinh thái DigiMeld.

Các dự án còn lại đang dần được chuyển sang mô hình truy cập quản trị mới.

Tôi đang thực hiện việc chuyển đổi theo từng bước, kiểm tra hoạt động của từng ứng dụng và dự định tiến hành kiểm toán bổ sung toàn bộ hệ thống sau khi hoàn tất.

Một số thành phần giao diện và quy tắc quản lý phiên vẫn có thể thay đổi.

Nhưng ý tưởng cốt lõi đã được xác định.

Tôi không muốn quay lại mô hình mà trong đó, để quản lý hàng chục dự án của chính mình, tôi phải liên tục lưu và sử dụng hàng chục mật khẩu quản trị.

Đồng thời, tôi không cho rằng cách triển khai của mình là giải pháp phù hợp cho tất cả mọi người.

Mỗi tổ chức có yêu cầu, hạ tầng, mô hình mối đe dọa và cách thức quản trị khác nhau.

Điều tiện lợi và hợp lý đối với hệ sinh thái DigiMeld chưa chắc đã là lựa chọn tối ưu cho một nhà phát triển khác.

Tuy nhiên, nguyên tắc cấp quyền có thời hạn vẫn đáng để quan tâm.

Lời kết

Tôi quyết định chia sẻ trải nghiệm này không phải vì cho rằng mình đã phát minh ra một phương thức xác thực mới.

Cũng không phải vì muốn giới thiệu thêm một hệ thống và tuyên bố nó an toàn tuyệt đối.

Không có thứ gọi là an toàn tuyệt đối.

Điều khiến tôi thấy thú vị đơn giản là cách đặt vấn đề.

Thay vì không ngừng bảo vệ một cổng đăng nhập quản trị thường trực, ta có thể xem xét lại liệu nó có cần tồn tại hay không.

Thay vì lưu trữ hàng loạt mật khẩu, hãy dùng các quyền cấp có thời hạn.

Thay vì mặc nhiên tin tưởng sau lần xác thực đầu tiên, hãy xác nhận việc cấp những quyền hạn cụ thể.

Thay vì chờ phiên truy cập hết hạn, hãy dự trù khả năng thu hồi quyền truy cập tập trung.

Và cuối cùng, thay vì dùng một cơ chế đăng nhập riêng cho từng dự án, hãy xây dựng một hệ thống quản lý quyền truy cập quản trị thống nhất mà vẫn giữ các ứng dụng độc lập.

Tôi không khẳng định cách tiếp cận này loại bỏ khả năng hệ thống bị xâm phạm.

Nó chỉ chuyển trọng tâm từ việc bảo vệ thông tin đăng nhập luôn tồn tại sang việc cấp và thu hồi quyền một cách có kiểm soát.

Có lẽ đôi khi, cách hiệu quả nhất để giảm bề mặt tấn công không phải là thêm một cơ chế bảo vệ nữa, mà là loại bỏ thứ mà hệ thống hoàn toàn có thể hoạt động mà không cần đến.

Với tôi, chính suy nghĩ đó đã mở đầu câu chuyện về MeldID Admin Gateway.