Cách xác thực và phân quyền trong Microservices
Nguồn: engineering.tiki.vn
Xác thực (authentication, trả lời câu hỏi bạn là ai) và phân quyền (authorization, trả lời câu hỏi bạn mang thể làm cho được gì) luôn là thành phần ko thể thiếu của đầy đủ hệ thống, nhưng mức độ áp dụng thì lại tùy thuộc vào từng giai đoạn. Nếu bạn khiến hầu hết sản phẩm công nghệ chặt chẽ ngay từ đầu, nó với thể khiến cho tăng độ phức tạp và làm chậm sự vững mạnh của công ty. Nhưng giả dụ bạn khiến cho nó quá muộn, thì mang thể bạn sẽ hứng chịu nguy cơ bị tấn công và rủi ro từ đó. Với một doanh nghiệp e-commerce như Tiki, rủi ro đó rất hiện hữu với các hệ thống liên quan tới thanh toán, tiền ảo (Tiki Xu), mã khuyến mại (coupon), phiếu quà tặng (giftcard) và nhiều kiểu hệ thống nhạy cảm khác…
Bắt đầu từ Monolithic
Tiki căn nguyên là một hệ thống monolithic, thông thường ở hệ thống như vậy sẽ sở hữu 1 module chung quản lý việc xác thực và phân quyền, mỗi user sau khi đăng nhập sẽ được cấp cho một Session ID duy nhất để định danh. Phía client sở hữu thể lưu Session ID lại dưới dạng cookie và gửi kèm nó trong đông đảo request. Hệ thống sau đó sẽ sử dụng Session ID được gửi đi để thỏa thuận danh tính của user truy cập, để người sử dụng ko phải phải nhập lại thông tin đăng nhập lần sau.
Khi Session ID được gửi lên, server sẽ xác định được danh tính của các bạn gắn với Session ID đó, đồng thời sẽ kiểm tra quyền của user xem mang được truy cập tác vụ đó hay không. Giải pháp session và cookie vẫn sở hữu thể sử dụng, tuy nhiên ngay lúc này chúng ta với nhiều kiểu yêu cầu hơn, chẳng hạn như các ứng dụng Hybrid hoặc SPA (Single Page Application) có thể bắt buộc truy cập tới lan rộng hệ thống backend khác nhau, vì vậy session và cookie lấy từ một server có thể ko sử dụng được ở server khác.
Bài toán khó khăn Microservices
Trong kiến trúc microservices, hệ thống được chia nhỏ thành nhiều hệ thống con, đảm nhận những nghiệp vụ và chức năng khác nhau. Mỗi hệ thống con đó cũng phải được xác thực và phân quyền, ví như xử lý theo bí quyết của kiến trúc Monolithic ở trên chúng ta sẽ gặp những vấn đề sau:
- Mỗi service sở hữu phải có|cần thiết|đòi hỏi|lời yêu cầu|nhu cầu|nhu cầu cần thiết|nhu yếu|sự buộc phải dùng|sự đòi hỏi|thiết yếu} đề nghị buộc phải tự đang chạy việc xác thực và phân quyền ở service của mình. Mặc dù chúng ta có thể tiêu dùng những thư viện giống nhau ở mỗi service để việc làm đó tuy nhiên giá tiền để bảo trì thư viện chung đó với nhiều loại nền tảng tiếng nói khác nhau là quá lớn.
- Mỗi service buộc phải tập trung vào xây dựng các nghiệp vụ của mình, việc xây dựng thêm lý tưởng về phân quyền làm cho giảm vận tốc phát triển và tăng độ phức tạp của những service.
- Các service thông thường sẽ thêm vào các interface dưới dạng RESTful API, tiêu dùng protocol HTTP. Các HTTP request sẽ được đi qua đa dạng thành phần của hệ thống. Cách truyền thống tiêu dùng session ở server (stateful) sẽ gây khó khăn cho việc phát triển thêm hệ thống theo chiều ngang.
- Service sẽ được truy cập từ phong phú ứng dụng và đối tượng dùng khác nhau, với thể là người dùng, 1 máy phần cứng, 3rd-party, crontab hay một service khác. Việc bằng lòng định danh (identity) và phân quyền (authorization) ở lan rộng ngữ cảnh (context) khác nhau như vậy là vô cùng phức tạp.
Dưới đây là một số giải pháp, kỹ thuật và hướng tiếp cận mà Tiki đã áp dụng cho bài toán này.
Định danh
Sử dụng JWT
JWT (Json Web Token) là 1 cái token tiêu dùng chuẩn mở tiêu dùng để trao đổi thông tin kèm theo các HTTP request. Thông tin này được xác thực và đánh dấu 1 giải pháp tin cậy dựa vào chữ ký. JWT có cực kỳ phần đông lợi hơn so với session.
- Stateless, thông tin ko được lưu trữ trên server.
- Dễ dạng phát triển, mở rộng.
- Performance tốt hơn do server đọc thông tin ngay trong request (nếu session thì cần đọc ở storage hoặc database)
Mã hóa RSA cho JWT
Phần chữ ký sẽ được mã hóa lại bằng HMAC hoặc RSA.
- HMAC: mục tiêu khởi tạo JWT (token issuer) và đầu nhận JWT (token verifier) dùng chung 1 mã bí mật để mã hóa và kiểm tra.
- RSA: dùng một cặp key, đối tượng khởi tạo JWT sử dụng Private Key để mã hóa, đầu nhận JWT sử dụng Public Key để kiểm tra.
Như vậy với HMAC, cả 2 phía đều cần chia sẻ mã bí mật cho nhau, và đầu nhận JWT hoàn toàn với thể khởi tạo một mã JWT khác hợp lệ dựa trên mã bí mật đó. Còn với RSA, đầu nhận sử dụng Public Key để kiểm tra nhưng ko thể khởi tạo được một JWT mới dựa trên key đó. Vì vậy mã hóa dùng RSA giúp cho việc bảo mật chữ ký tốt hơn khi nên chia sẻ JWT với phổ thông mục tiêu khác nhau.
Sử dụng Opaque Token khi muốn để kiểm soát phiên việc làm tốt hơn
Opaque Token (còn được gọi là stateful token) là dạng token ko chứa thông tin trong nó, thông thường là 1 chuỗi trùng hợp và yêu cầu 1 service trung gian để kiểm tra và lấy thông tin.
Transparent Token (còn được gọi là stateless token) thông thường chính là dạng JWT, token này bản thân cất thông tin và ko phải một service trung gian để kiểm tra. Hãy cùng đối chiếu 2 chiếc token này.
Như vậy ta với thể thấy Transparent Token mang lại vận tốc tốt hơn, đơn giản dễ dùng với cả 2 phía, ko phù thuộc vào một server trung ương để kiểm tra. Còn Opaque Token kiểm soát tốt hơn những phiên việc làm của đối tượng, chẳng hạn khi bạn muốn thoát đại khái các trang bị đang đăng nhập.
OAuth 2
Các token sẽ được khởi tạo thông qua OAuth 2, là phương thức chức thực lan rộng nhất hiện nay, mà qua đó một service, hay một ứng dụng bên vật dụng 3 với thể đại điện (delegation) cho quý khách truy cập vào 1 tài nguyên của người mua nằm trên một chuyên dụng cho nào đó.
OAuth 2 là chuẩn mở, với đại khái tài liệu, thư viện ở hầu hết những tiếng nói khác nhau giúp cho việc tích hợp, lớn lên dựa trên nó phát triển thành dễ dàng và nhanh chóng.
****
Kiến trúc cho xác thực và phân quyền
Sau lúc đã mang định danh và giao thức sử dụng để giao tiếp, câu hỏi tiếp theo là nên trả lời câu hỏi mục tiêu với định danh đó với quyền triển khai một hành động, truy cập 1 tài nguyên nào đó hay không. Ở Tiki, xung quanh những service được xây dựng mới, vẫn còn tồn tại những hệ thống cũ (legacy) chạy song song, thế buộc phải hiện nay Tiki có 2 cách thức tổ chức phân quyền như dưới đây.
Xác thực, phân quyền tại lớp rìa
Theo mô hình gần như đa số request sẽ được xác thực lúc đi qua API Gateway hoặc BFF (Backend For Frontend). BFF chính là lớp service ở rìa (Edge Service) được thiết kế riêng cho từng ứng dụng (ví dụ IOS, Android, Management UI). Chúng ta sẽ đặt xác thực và phân quyền ở lớp rìa này
- API Gateway sẽ bắt buộc đông đảo request sẽ bắt buộc gửi kèm token để định danh
- Nếu token này là JWT (đối với OpenID Connect), Gateway với thể kiểm tra tính hợp lệ của token thông qua chữ ký (signature), thông tin (claim) hoặc mục tiêu khởi tạo (issuer)
- Nết token này là Opaque Token, Gateway sở hữu thể so sánh (introspect) token, đổi (exchange) lấy JWT và truyền tiếp vào trong cho những services.
- API Gateway hoặc BFF kiểm tra các policy xem mang hợp lệ hay ko thông qua Authorization Server trung tâm.
- Các microservices ko đang chạy lớp xác thực và phân quyền nào, sở hữu thể tự do truy cập bên trong vùng nội bộ (internal network).
Mô hình này sở hữu điểm tương đồng với kiến trúc Monolithic khi đặt xác thực phân quyền tại 1 số service nhất định, việc xây dựng và bảo trì sẽ tốn mức giá nhỏ hơn, tuy nhiên sẽ để lộ một không gian bảo mật vô cùng to ở lớp trong do các service sở hữu thể tự do truy cập lẫn nhau. Chúng ta có thể đặt 1 số rule ở góc độ network đối với những service bên trong này tuy nhiên các rule này sẽ tương đối đơn giản và ko thể đạt được ý muốn được các nghiệp vụ truy cập dữ liệu lẫn nhau giữa các team/service (mở rộng ra là những công ty nội bộ) độc lập nhau.
Xác thực, phân quyền tại các service
Ở mô hình này, mỗi service (trừ một số ngoại lệ) khi được thiết kế và xây dựng những giao tiếp APIs (API Interface) tăng diện tích được và có thể phục vụ cho trái đất bên ngoài. Một service hôm nay được xây dựng cho các nghiệp vụ bên trong nội bộ công ty, nhưng ngày mai mang thể sẵn sàng để mở ra cho các đối tác, các lập trình vên ngoài. Điều này sẽ giúp cho những service/team chủ động được đầy đủ về những tài nguyên hiện có, tài nguyên đó được cấp cho những đối tượng nào, được truy cập từng phần hay toàn phần…
Để làm được việc này, vai trò siêu to sẽ nằm ở service IAM (Identity Access Management), IAM nắm giữ những định danh của tất cả các mục tiêu (user, service, command…) cùng với các bộ luật phân quyền chi tiết cho từng chiếc tài nguyên.
Việc mỗi service yêu cầu tự vận hành việc xác thực, phân quyền sẽ khiến tăng giá bán khi xây dựng các service, bên quanh đó các nghiệp vụ chính thì buộc phải thêm lớp middleware để giao tiếp với IAM. Tuy nhiên các service sẽ sở hữu được sự tự chủ hoàn toàn, chủ động về việc tiếp tế tài nguyên cho những đối tượng, và tăng tốc vững mạnh hơn vì lan rộng trường hợp client sở hữu thể truy cập thẳng tới những service mà không đề nghị tăng thêm lớp BFF ở giữa.
Access Control
Xây dựng hệ thống luật (rule) hiệu quả ko bao giờ là dễ dàng, khi yêu cầu về nghiệp vụ tăng cao kéo theo yêu cầu về phân quyền càng phức tạp. Hãy lấy 1 ví dụ cụ thể để làm cho rõ, mỗi ứng sử dụng thông thường sẽ gán quyền cho 1 thành viên cụ thể (ví dụ John được quyền tạo sản phẩm). Mở rộng ra trong một hệ thống microservices, đối tượng ở đây với thể là người dùng, service, crontab…
Có 1 vài giải pháp tiếp cận cho việc phân quyền như trên, hãy thử đi qua các bí quyết khác nhau để sở hữu phổ thông góc nhìn khác nhau.
Access Control List (ACL)
Trong ví dụ trên những bạn với thể thấy một ma trận của mục tiêu và quyền, nó sắp giống như với bí quyết quản lý file trên Linux (chmod) và say mê với những ứng dụng sở hữu ít đối tượng. Khi hệ thống to lên mô hình này sẽ ko thể quản lý nổi bởi ma trận được xây dựng thương hiệu quá to và phức tạp. Do vậy và mô hình này không còn phong phú hiện tại.
Role-Based Access Control (RBAC)
RBAC liên kết mục tiêu tới các vai trò (role), và từ vai trò tới những quyền. Chẳng hạn vai trò Administratorcó thể thừa hưởng gần như quyền mà vai trò Manager có, điều này giúp khiến giảm độ phức tạp của ma trận quyền, thay vì gán mọi quyền cho Administrator thì chỉ yêu cầu cho Administrator thừa hưởng các quyền của Manager.
RBAC cực kỳ nhiều kiểu và bạn với thể thấy ở đa số nơi, so với ACL thì RBAC giúp giảm thiểu độ phức tạp khi số lượng đối tượng + quyền tăng cao. Tuy nhiên RBAC chưa thỏa mãn được một số trường hợp, ví dụ lúc cấp quyền 1 máy chỉ được sửa bởi người tạo, người trải nghiệm nằm trong một phòng ban xác định hoặc quyền phân biệt với những người tiêu dùng từ phổ biến hệ thống (tenant) khác nhau.
Policy-Based Access Control (PBAC)
PBAC được xây dựng dựa trên Attribute Based Access Control (ABAC), qua đó định nghĩa những quyền để diễn đạt một yêu cầu được cho phép hay từ chối. ABAC sử dụng các thuộc tính (attribute) để mô tả cho đối tượng buộc phải được kiểm tra, mỗi thuộc tính là một cặp key-value ví dụ Department = Marketing. Nhờ đó ABAC có thể giúp phân quyền mịn hơn, mê thích với nhiều kiểu ngữ cảnh (context) và nghiệp vụ (business rules) khác nhau.
PABC được định nghĩa thông qua những policy được viết dưới dạng một tiếng nói chung XACML (eXtensible Access Control Markup Language). Một policy định nghĩa 4 đối tượng subject, effect, action và resource. Ví dụ john (subject) được allowed(effect) để mà delete(action) product với ID john-leman(resource).
Luật ưu tiên
- Mặc định ví như ko với policy phù hợp, yêu cầu sẽ bị từ chối
- Nếu không sở hữu policy nào deny, có ít nhất một policy allow thì yêu cầu được cho phép
- Nếu với 1 policy là deny, thì yêu cầu luôn bị từ chối
Regular Expression
Các policy cho phép khai báo sử dụng regular expression, như ở ví dụ này cho phép toàn thể quý khách được xem thông tin product.
Điều kiện
Các policy sở hữu thể bổ sung các điều kiện để thu hẹp phạm vi của quyền, ví dụ như chỉ áp dụng cho 1 dải IP nhất định, hoặc chỉ cho phép người tạo lắp thêm được sửa đồ vật đó.
Tổng kết
Việc liên tục tăng thêm nghiệp vụ và hệ thống yêu cầu có|cần thiết|đòi hỏi|lời yêu cầu|nhu cầu|nhu cầu phải thiết|nhu yếu|sự đề nghị dùng|sự đòi hỏi|thiết yếu} những service pải tự xác thực, qua đó không phân minh service đó là bên trong (internal) hay bên ko kể (external), giúp các team dễ dàng tăng diện tích tích hợp với nhau. Việc này buộc phải có|cần thiết|đòi hỏi|lời yêu cầu|nhu cầu|nhu cầu bắt buộc thiết|nhu yếu|sự phải dùng|sự đòi hỏi|thiết yếu} mô hình xác thực chung pải hoạt động ổn định, tối ưu và hoàn thành được hiệu năng cao.
Techtalk Via engineering.tiki.vn
Nguồn: techtalk.vn
Post a Comment