#120 - Bài toán Authentication và Authorization trong kiến trúc Microservices.

May 10, 2020

Với tất cả engineer, Engineering Manager là người mà bạn phải dành hầu hết thời gian của mình để làm việc cùng mỗi ngày. Manager vừa là người đứng đầu, vừa là người dẫn dắt và có vai trò vô cùng quan trọng trong mỗi team. Hiểu được công việc của manager sẽ giúp chúng ta làm việc với nhau một cách hiệu quả để cùng nhau phát triển nhanh hơn.

Với mong muốn chia sẻ một góc nhìn về Engineering Manager(EM), Grokking hân hạnh tổ chức Webinar #05: “Engineering Manager 101” để các bạn có cơ hội được hiểu thêm về EM và các vấn đề thực tế trong công việc hàng ngày của họ qua chia sẻ của EMs đến từ Việt Nam cũng như nước ngoài.

Thông tin chi tiết về webinar bạn có thể tham khảo tại đây.

Những bài viết hay

Basic Elliptic Curve Cryptography — blog.goodaudience.com

Elliptic Curve Cryptography (ECC) là một trong các phương pháp mã hoá thuộc nhóm mã hoá sử dụng public key. Tuy nhiên, so với các phương pháp mã hoá khác trong nhóm như RSA, ECC có một lợi thế là chỉ cần dùng một khoá có chiều dài 256 bit là có thể mang đến độ bảo mật tương tự sử dụng phương pháp RSA với key 3072 bit. Do vậy, các hệ thống giới hạn tài nguyên như điện thoại, hệ thống nhúng, ... có thể sử dụng ít hơn 10% không gian đĩa và băng thông so với RSA.

Bài viết dưới đây trình bày chi tiết hơn về phương pháp mã hoá ECC này.

Microservices Authentication and Authorization Solutions — medium.com

Kiến trúc Microservices đem lại rất nhiều lợi ích như khả năng mở rộng cao (scalability), tự do lựa chọn công nghệ, deploy độc lập. Tuy nhiên các thách thức của hệ thống phân tán cũng dần bộc lộ. Xây dựng cơ chế bảo mật (authentication và authorization) trong kiến trúc Microservices là một trong các thách thức đó.

Trước tiên chúng ta cần phân biệt authentication và authorization

Authentication: xác định bạn là ai
Authorization: bạn được phép truy cập tới các thông tin nào hay các tác vụ nào bạn được phép thực hiện trong hệ thống

Ở kiến trúc monolithic, giải pháp có phần đơn giản hơn bằng cách xây dựng module security. Tuy nhiên với kiến trúc Microservices có nhiều thách thức hơn:

Authentication và authorization cần được kiểm tra ở tất cả các services để đảm bảo loại bỏ tất cả các truy cập trái phép
Authentication và authorization logic không nên đặt trong microservice để tuân thủ nguyên tắc single responsibility
Authentication và authorization trong microservices phức tạp hơn so với monolithic. Các kịch bản bao gồm user truy cập vào một service, các service gọi nhau hay một ứng dụng bên thứ 3 cần truy cập vào hệ thống.

Bài viết sau tác giả Mina Ayoub giải thích rõ hơn các thách thức và đưa ra giải pháp cho bài toán Authentication and Authorization trong kiến trúc Microservices.

Rebuilding our tech stack for a new Facebook.com — engineering.fb.com

Facebook trên nền web là ứng dụng được xây dựng từ năm 2004, trải qua hơn 16 năm phát triển, nó đã có nhiều thay đổi với hàng tá tính năng đi kèm và luôn giữ được trải nghiệm người dùng tốt. Điều này đòi hỏi các kĩ sư luôn phải thích ứng với biến đổi của nghiệp vụ. Ứng dụng này một lần nữa được "lột xác" với việc thiết kế lại giao diện web sắp được ra mắt vào thời gian tới.

Câu "thần chú" mà team tâm niệm trong quá trình thiết kế là: As little as possible, as early as possible và Engineering experience in service of user experience.

Bài viết dưới đây chia sẻ các kĩ thuật team áp dụng, trong đó 2 hướng tiếp cận chính là thay đổi code CSS và Javascript.

CSS:

Tạo các đoạn CSS nguyên tử (nhỏ nhất) để có thể hợp lại ở mỗi trang
+ Sử dụng: rem cho font-size để thích ứng với các loại màn hình khác nhau, sử dụng CSS variables để tiện cho việc đổi theme

Javascript:

Dùng SVG trong javascript thay vì để trong thẻ img để tránh icon bị nhấp nháy khi rest of content
Chia code Javascript ra thành 3 tier: tier 1 - khởi tạo, tier 2 - các thành phần hiển thị, tier 3 - các thành phần không liên quan tới hiển thị (log & cập nhật dữ liệu). Việc này rút giúp ngắn thời gian tải trang ban đầu.
Sử dụng quỹ code (code budgets) để tránh việc gia tăng lượng code không đáng có.

Ngoài ra việc kéo dữ liệu hiển thị cũng được sử dụng bằng các kĩ thuật như: defer dữ liệu không cần ngay, tải trước dữ liệu & tải song song với code, sử dụng streaming để giảm thiểu round trip & tăng tính tương tác . . .

Góc Database

TPC-C Benchmark là gì?

Theo bạn nghĩ có bao nhiêu loại database khác nhau đang có trên thị trường hiện tại? 50 hay 100? Thật ra là có không ít hơn 500 loại database đó bạn ạ. Mỗi một loại trong số này sẽ có ưu nhược điểm riêng. Chính vì vậy mà để so sánh giữa các loại database, dần dần những chuẩn, tiêu chí, công cụ benchmark đang được hình thành trong đó có TPC-C.

TPC là một tập các benchmark thường được các database vendor sử dụng để đánh giá và quảng cáo hiệu năng của database của mình. Trong đó TPC-C là các benchmark tập trung vào các tác vụ liên quan đến transaction như OLTP.

TPC-C chú ý nhiều đến hiệu năng và tính chính xác của các transaction. Một trong những chỉ số đánh giá hiệu năng quan trọng là throughput: số lượng transaction mà database có thể xử lý mỗi phút. Ngoài ra, các transaction cũng phải đáp ứng được tiêu chí ACID.

Ngoài ra, đặc tả của TPC-C không chú trọng một lĩnh vực cụ thể mà sẽ đánh giá thông qua việc cung cấp một số tables, entities tổng quát cùng chi tiết, số lượng dòng trong database cần phải test.

Các thông tin khác:

Trang tổng hợp thông tin về hơn 700 database hiện đang có trên thị trường https://dbdb.io/
Trang tổng hợp các tài nguyên liên quan đến MongoDB https://github.com/ramnes/awesome-mongodb

Có thể bạn chưa biết

Khi thiết kế một replication protocol cho distributed database system, mục tiêu nên được cân nhắc để đạt được là độ trễ nhỏ (low latency) và lưu lượng truyền tải dữ liệu cao (high throughput) để đảm bảo có thể đọc và ghi được dữ liệu nhanh nhất có thể. Protocol replica ZAB và CRAQ đều có những hạn chế riêng về ghi dữ liệu. Một nhóm nghiên cứu đã thiết kế protocol tên Hermes để giải quyết vấn đề ghi dữ liệu và tiến hành benchmark với ZAB và CRAQ.

Code & Tools

Tin tức

Vừa qua, tập đoàn BKAV đã cho ra mắt ứng dụng Blue Zone. Đây là ứng dụng giúp bảo vệ cộng đồng, phòng chống COVID-19 do Tập đoàn công nghệ Bkav phối hợp cùng Bộ Thông tin và Truyền thông phát triển. Mặc dù mới ra mắt nhưng ứng dụng cũng đã gặp phải những lo ngại về vấn đề bảo mật thông tin. Theo anh Thái, một chuyên gia trong lĩnh vực an toàn thông tin đang làm việc tại Google, ứng dụng có những lỗ hổng nghiêm trọng liên quan tới việc "thay đổi mã ID Bluezone" cũng như "thuật toán tạo mã ID Bluezone là rất dễ đoán". Trước những thông tin này, một admin tại diễn đàn whitehat.vn đã liên lạc với nhóm phát triển Blue Zone và đưa ra những phản hồi về việc sinh mã ngẫu nhiên và các giải pháp của nhóm trong việc giải quyết các vấn đề liên quan tới mã ID Bluezone - link.

Một ứng dụng khác cũng rất nổi tiếng trong thời gian qua là Zoom, cũng đang gặp nhiều vấn đề liên quan tới an toàn và bảo mật thông tin. Từ đầu năm 2020, nhiều lỗ hổng bảo mật của Zoom đã được công bố nhưng chưa được hãng khắc phục triệt để, như CVE-2020-11500 với mức độ nguy hiểm cao có thể khiến tin tặc xem được hình ảnh trong cuộc họp mà không cần tên, mật khẩu - link. Cục an toàn thông tin đã đưa ra khuyến cáo không nên sử dụng Zoom.

Quotes

Perl – The only language that looks the same before and after RSA encryption

Keith Bostic