Link Search Menu Expand Document

Bảo mật trong hệ thống Microservices

Giới thiệu tổng quan

Bảo mật luôn là một trong những vấn đề phức tạp nhất khi xây dựng một hệ thống phần mềm. Trong kiến trúc microservices, vấn đề bảo mật càng trở nên khó khăn hơn khi hệ thống chia nhỏ thành nhiều thành phần hoat động độc lập, hoạt động phân tán trên nhiều thiết bị với những công nghệ khác nhau. Việc giao tiếp giữa các thành phần cũng trở nên chồng chéo và phức tạp hơn, từ đó dễ tạo ra những điểm yếu bảo mật trong hệ thống nếu không được thiết kế và quản lý một cách chặt chẽ. Vì lý do đó, khi phát triển một hệ thống theo kiến trúc microservices, chúng ta cần tập trung vào những yêu cầu bảo mật với khả năng mã hoa thông tin đầu cuối, thực hiện các cơ chế giám sát, kiểm soát đối với tất cả những giao tiếp giữa hệ thống với môi trường bên ngoài cũng như giao tiếp giữa các services với nhau.

Thông thường các hoạt động giao tiếp trong một ứng dụng microservices được phân chia thành 2 loại:

  • Giao tiếp frontend: Người dùng sử dụng clients application (mobile, web, IoT devices) giao tiếp với những API phía hệ thống back-end thông qua API gateway. Việc sử dụng API Gateway giúp chúng ta có thể tập trung giám sát hay kiểm soát luồng thông tin vào ra trong hệ thống. Bên cạnh đó, API gateway cũng có thể thực hiện các chức năng khác như Authentication, Audit Log, Data Encryption, DoS Prevention…giúp giảm thiểu những xử lý không cần thiết ở phía microservices. Điều này cũng đảm bảo cho nguyên tắc thiết kế hệ thống: mỗi microservices chỉ thực hiện một chức năng business duy nhất.

  • Giao tiếp backend: Bên trong hệ thống backend, các microservices thường được chia thành nhiều layers: gateway, middle layers/aggregator , core layer. Giao tiếp giữa các microservices, machine-to-machine, được thực hiện thông qua quá trình xác thực dựa trên thông tin đăng nhập từ người dùng, hoặc cũng có thể dựa trên những quyền truy cập được cấp phép từ Identity Provider. Khi quá trình xác thực được thực hiện thành công, Identity Provider gửi về client một Access Token giúp cho clients (microservices) có thể truy cập đến những resources (API / Data Storage) để thực hiện tác vụ yêu cầu.

Microservice Communication Microservice Communication


Khái niệm cơ bản

Trước khi tìm hiểu cơ chế hoạt động trong bảo mật thông tin, chúng ta cần nắm rõ một số khái niệm cơ bản:

  • Authentication: là hoạt động cung cấp thông tin credentials (i.e, username / password) và xác thực danh tính người dùng - user identity. Ví dụ khi vào một công ty khách hàng, chúng ta cần cung cấp thông tin cá nhân (chứng minh nhân dân / passport / driver license) cho phía bảo vệ để xác thực danh tính của mình. Cũng như vậy, khi muốn truy cập vào các ứng dụng như Facebook, Gmail chúng ta cần cung câp email address / password cho hoạt động xác thực.

  • Authorization: là hoạt động ủy quyền cho user / client thực hiện các hoạt động truy cập tài nguyên trong một phạm vi - scope và thời gian xác định. Tài nguyên có thể là những API resources - cho phép client gọi đến các API cung cấp bởi hệ thống (API Access). Tài nguyên cũng có thể là thông tin dữ liệu của người dùng, dịch vụ. Ví dụ: third-party application có thể truy cập thông tin người dùng Facebook sau khi được xác nhận bởi người dùng thông qua màn hình xác nhận - consent view.

Google Consent View

  • Digital signature: là hình thức sử dụng chữ kí điện tử đi kèm theo dữ liệu nhằm mục đích xác nhận tính toàn vẹn của dữ liệu trong quá trình trao đổi thông tin. Chữ kí điện tử được tạo ra bằng cách sử dụng một thuật toán mã hóa nội dung thông tin trao đổi (ví dụ: HMAC - Keyed Hash Message Authentication Code). Sau khi nhận được thông tin tin, bên phía tiếp nhận sẽ sử dụng thuật toán tương tự để tạo lại và đối chiếu chữ kí nhận được, đảm bảo dữ liệu không bị thay đổi bởi một bên thứ ba nào khác.

  • Token: là một dạng thông tin mã hóa thay thế cho việc sử dụng trực tiếp username/password mỗi khi user hoặc client apps muốn truy cập vào các tài nguyên trong hệ thống. Token tạo nên một lớp bảo mật bổ sung cho thông tin credentials của người dùng, khắc phục những điểm hạn chế trong phương pháp Server-side / Stateful Sessions. Bên cạnh đó, do yêu cầu về tính tương thích của hoạt động xác thực trên nhiều nền tảng / môi trường khác nhau (web, mobile, embedded device) token thường được áp dụng theo một định dạng phổ biến là JSON Web Token (JWT / jot). Cấu trúc của một JSON Web Token bao gồm 3 phần chính: [Header].[Payload].[Signature], trong đó:

    • Header: định nghĩa kiểu token và thuật toán sử dụng để mã hóa token.

Ví dụ:

{
  "alg": "HS256",
  "type": "JWT"
}
  • Payload: bao gồm tập hợp các key-value (claims) mô tả thuộc tính của người dùng bên cạnh những thông tin bổ sung khác. Một số thuộc tính cơ bản:
    • iss (issuer) - giá trị đinh dang của nguồn cung cấp token
    • exp (expiration) - thời gian sử dụng token
    • sub (subject) - chủ thể sử dụng token (i.e, định danh người dùng trong ứng dụng)
    • aud (audience) - giá trị định danh của ứng dụng sử dụng token

Ví dụ:

{
  "iss": "https://auth-provider.domain.com/",
  "sub": "auth|some-hash-here",
  "aud": "unique-client-id-hash",
  "iat": 1529496683,
  "exp": 1529532683
}
  • Signature: chữ kí điện tử với mục đích đảm bảo tính toàn vẹn của nội dung trong token.

  • Bearer Token là một dạng token phổ biến khác, đơn giản hơn so với JSON Web Token. Theo hình thức này, client sử dụng một chuỗi kí tự được gửi kèm theo header của mỗi API Request với mục đích xác thực quyền sử dụng API. Bearer token có điểm hạn chế khi chuỗi kí tự token không được mã hóa trong quá trình truyền tin do đó nó có thể bị lấy cắp và lợi dụng để thực hiện những truy cập trái phép trong hệ thống.

Hoạt động Authentication / Authorization thường được tiêu chuẩn hóa thông qua các đặc ta giao thức: SAML, OAuth2, OpenID Connect…Trong phạm vi của bài viết này, chúng ta sẽ chỉ đề cập đến hai giao thức phổ biến nhất bao gồm OAuth2OpenID Connect.


OAuth 2.0 & Open ID Connect

OAuth - Open Authorization là một hệ thống tiêu chuẩn mô tả quá trình cấp phép / ủy quyền truy cập đối với các tài nguyên thông tin. Dựa trên giao thức OAuth, người dùng Internet có thể ủy quyền cho các ứng dụng được truy cập vào các thông tin cá nhân mà không cần phải chia sẻ username/password. Giao thức này trở nên rất phổ biển khi được sử dụng bởi các công ty IT lớn như Amazon, Google, Facebook, Twitter cho phép người dùng của họ chia sẻ thông tin cá nhân đối với những ứng dụng từ bên thứ ba.

Ý tưởng ban đầu của OAuth được đề xuất bởi một kĩ sư làm việc tại Twitter tên là Brain Cook khi triển khai hệ thống Twitter Open ID cho phép Widgets có thể truy cập API resources sau khi được người dùng cho phép. Trong quá trình phát triển, các kĩ sư nhận ra yêu cầu cần phải có một chuẩn hóa đối với quá trình ủy quyền từ người dùng. Đến tháng 4, 2007, một nhóm các thành viên từ các công ty Google, Twitter đã đề xuất bản phác thảo về một tiêu chuẩn mở đối với quá trình ủy quyền trong các ứng dụng dịch vụ. Năm 2010, OAuth 1.0 được chính thức công bố với mã tài liệu RFC 5849 dưới sự quản lý của tổ chức Internet Engineering Task Force (IEFT). Năm 2010, phiên bản OAuth 2.0 ra mắt với mục đích nâng cao khả năng bảo mật và giúp việc phát triển giao thức dễ dàng hơn. Trong tài liệu đặc tả RFC-6749 của OAuth 2.0, các nhà phát triển đã định nghĩa lại một số thuật ngữ cơ bản đồng thời tách biệt giữa đối tượng quản lý resources (Resource Server) và đối tượng thực hiện việc xác thực (Authorization Server).

Với mục tiêu phát triển ban đầu, giao thức OAuth chỉ tập trung vào mục đích thực hiện hoạt động ủy quyền từ người dùng. Để mở rộng cho hoạt động xác thức, một giao thức khác - OpenID Connect được xây dựng dựa trên cơ sở của OAuth2.0. OpenID Connect cũng bổ sung thêm khả năng tích hợp và cung cấp thông tin người dùng (profile) với cơ chế RESTful HTTP API.

Để hiểu rõ hơn về các thành phần cũng như cơ chế hoạt động của OAuth2.0 và OpenID Connect, trong phần tiếp theo chúng ta sẽ tìm hiểu về IdentityServer4, một trong những Identity Provider phổ biến hỗ trợ đồng thời cả hai giao thức OAuth 2.0 / OpenID Connect.

Chú ý

Bên cạnh thuật ngữ Authorization Server / Identity Provider, chúng ta cũng có thể sử dụng các thuật ngữ khác với cùng một chức năng: Token Service, IP-STS, IdP…

Tài liệu tham khảo


Table of contents


Copyright © 2019-2022 Tuan Anh Le.