Bảo mật các ứng dụng phần mềm dưới dạng dịch vụ (SaaS) là ưu tiên hàng đầu đối với tất cả các kiến trúc sư ứng dụng và nhà phát triển. Làm như vậy trong một môi trường được chia sẻ bởi nhiều khách hàng có thể là thách thức càng khó khăn hơn. Các khung định danh và khái niệm có thể mất thời gian để hiểu, và tạo sự cô lập khách hàng trong các môi trường này đòi hỏi sự hiểu biết sâu rộng về các công cụ và dịch vụ khác nhau.

Trong khi bảo mật là một yếu tố cơ bản của bất kỳ ứng dụng phần mềm nào, những quan điểm cụ thể áp dụng cho các ứng dụng SaaS. Bài viết này sẽ đào sâu vào các thách thức, cơ hội và các phương pháp tốt nhất để bảo mật môi trường SaaS đa khách hàng trên Amazon Web Services (AWS).

Những yếu tố bảo mật cho ứng dụng SaaS

Các ứng dụng đơn khách hàng thường được triển khai cho một khách hàng cụ thể và thường chỉ xử lý với thực thể đơn này. Trong khi an ninh là quan trọng trong các môi trường này, nhưng hồ sơ mối đe dọa không bao gồm khả năng truy cập của các khách hàng khác. Ứng dụng SaaS đa khách hàng có các yếu tố bảo mật độc đáo so với các ứng dụng đơn khách hàng.

Đặc biệt, các ứng dụng SaaS đa khách hàng phải chú ý đặc biệt đến định danh và cô lập tenant. Những điều này là bổ sung cho các biện pháp bảo mật mà tất cả các ứng dụng phải thực hiện. Bài đăng này sẽ giới thiệu về các khái niệm liên quan đến định danh và cô lập tenant, và cách AWS có thể giúp các nhà cung cấp SaaS xây dựng các ứng dụng an toàn.

Định danh

Ứng dụng SaaS được truy cập bởi các chủ thể cá nhân (thường được gọi là người dùng). Những chủ thể này có thể tương tác (ví dụ: thông qua ứng dụng web) hoặc dựa trên máy (ví dụ: thông qua API). Mỗi chủ thể được định danh duy nhất và thường được liên kết với thông tin về chủ thể, bao gồm địa chỉ email, tên, vai trò và các siêu dữ liệu khác.

Ngoài việc định danh duy nhất của mỗi chủ thể, một ứng dụng SaaS còn có một khái niệm khác: tenant. Một bài báo về đa khách hàng định nghĩa tenant là một nhóm gồm một hoặc nhiều người dùng chia sẻ cùng một quan điểm về một ứng dụng họ sử dụng. Quan điểm này có thể khác nhau đối với các tenant khác nhau. Mỗi chủ thể cá nhân được liên kết với một tenant, ngay cả khi đó chỉ là một bản đồ 1:1. Mỗi tenant có định danh độc nhất và chứa thông tin về quản trị viên tenant, thông tin thanh toán và các siêu dữ liệu khác.

Khi một chủ thể cá nhân yêu cầu truy cập vào một ứng dụng SaaS, chủ thể cung cấp định danh tenant và người dùng cùng với yêu cầu của mình. Ứng dụng SaaS xác thực thông tin này và đưa ra quyết định ủy quyền. Trong các ứng dụng SaaS được thiết kế tốt, bước ủy quyền này không nên dựa trên một dịch vụ ủy quyền tập trung. Một dịch vụ ủy quyền tập trung là một điểm duy nhất của sự cố trong một ứng dụng. Nếu nó gặp sự cố hoặc bị quá tải với các yêu cầu, ứng dụng sẽ không thể xử lý các yêu cầu nữa.

Có hai kỹ thuật chính để cung cấp loại trải nghiệm này trong một ứng dụng SaaS: sử dụng nhà cung cấp định danh (IdP) và biểu diễn định danh hoặc ủy quyền trong một mã thông báo (token).

Sử dụng nhà cung cấp định danh (IdP)

Trong quá khứ, một số ứng dụng web thường lưu trữ thông tin người dùng trong bảng cơ sở dữ liệu quan hệ. Khi người dùng xác thực thành công, ứng dụng sẽ cấp một ID phiên. Đối với các yêu cầu tiếp theo, người dùng sẽ truyền ID phiên này cho ứng dụng. Ứng dụng sẽ đưa ra quyết định phân quyền dựa trên ID phiên này. Hình 1 cung cấp một ví dụ về cách thiết lập này hoạt động.

Hình 1 – Một ví dụ về ứng dụng kế thừa.

Trong các ứng dụng lớn hơn một ứng dụng web đơn giản, mô hình này không tối ưu. Mỗi yêu cầu thường dẫn đến ít nhất một truy vấn cơ sở dữ liệu hoặc tìm kiếm bộ đệm, tạo ra một điểm nghẽn trên kho lưu trữ dữ liệu chứa thông tin người dùng hoặc phiên. Hơn nữa, vì sự liên kết chặt chẽ giữa ứng dụng và quản lý người dùng của nó, việc liên kết với các nhà cung cấp danh tính bên ngoài trở nên khó khăn.

Khi thiết kế ứng dụng SaaS của bạn, bạn nên xem xét việc sử dụng một nhà cung cấp danh tính như Amazon Cognito, Auth0 hoặc Okta. Sử dụng một nhà cung cấp danh tính giảm bớt các công việc nặng nề cần thiết để quản lý danh tính bằng cách cho phép xác thực người dùng, bao gồm cả liên kết, được xử lý bởi các nhà cung cấp danh tính bên ngoài. Hình 2 cung cấp một ví dụ về cách một nhà cung cấp SaaS có thể sử dụng một nhà cung cấp danh tính thay thế cho giải pháp tự quản lý được thể hiện trong Hình 1.

Hình 2 – Ví dụ về quy trình xác thực liên quan đến nhà cung cấp danh tính.

Khi một người dùng xác thực với một nhà cung cấp danh tính, nhà cung cấp sẽ cấp phát một mã thông báo tiêu chuẩn. Mã thông báo này giống nhau bất kể người dùng xác thực như thế nào, điều này có nghĩa là ứng dụng của bạn không cần phải tích hợp hỗ trợ cho nhiều phương pháp xác thực khác nhau mà khách hàng có thể sử dụng.

Ngoài ra, các nhà cung cấp danh tính thường hỗ trợ truy cập liên kết. Truy cập liên kết có nghĩa là một bên thứ ba duy trì các danh tính, trong khi nhà cung cấp danh tính có mối quan hệ tin tưởng với bên thứ ba này. Khi khách hàng cố gắng đăng nhập với một danh tính được quản lý bởi bên thứ ba, nhà cung cấp danh tính của ứng dụng SaaS sẽ xử lý giao dịch xác thực với nhà cung cấp danh tính của bên thứ ba.

Giao dịch xác thực này thường sử dụng một giao thức như Security Assertion Markup Language (SAML) 2.0. Nhà cung cấp danh tính của ứng dụng SaaS quản lý tương tác với nhà cung cấp danh tính của khách hàng. Nhà cung cấp danh tính của ứng dụng SaaS cấp phát một mã thông báo theo định dạng được hiểu bởi ứng dụng SaaS. Hình 3 cung cấp một ví dụ về cách một ứng dụng SaaS có thể cung cấp hỗ trợ cho việc liên kết bằng cách sử dụng một nhà cung cấp danh tính.

Hình 3 – Ví dụ về xác thực liên quan đến nhà cung cấp danh tính do tenant cung cấp

Ví dụ: hãy xem Cách thiết lập Amazon Cognito để xác thực liên kết bằng Azure AD.

Đại diện cho định danh bằng mã thông báo (tokens)

Trong thế giới công nghệ, danh tính thường được biểu diễn bằng các mã thông báo được ký. JSON Web Signatures (JWS), thường được gọi là JSON Web Tokens (JWT), là các đối tượng JSON được ký trong các ứng dụng web để chứng minh rằng người mang mã thông báo được ủy quyền để truy cập vào tài nguyên cụ thể. Những đối tượng JSON này được ký bởi nhà cung cấp danh tính và có thể được xác thực mà không cần truy vấn vào một cơ sở dữ liệu hoặc dịch vụ tập trung.

Mã thông báo chứa một số cặp khóa-giá trị, được gọi là khai báo, được cấp bởi nhà cung cấp danh tính. Ngoài một số khai báo liên quan đến việc cấp và hết hạn của mã thông báo, mã thông báo cũng có thể chứa thông tin về người dùng chính và khách hàng.

Mẫu các yêu cầu mã thông báo truy cập (access token claims)

Ví dụ bên dưới cho thấy phần xác nhận quyền sở hữu của mã thông báo truy cập điển hình do Amazon Cognito phát hành ở định dạng JWT.

{
  "sub": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
  "cognito:groups": [
"TENANT-1"
  ],
  "token_use": "access",
  "auth_time": 1562190524,
  "iss": "https://cognito-idp.us-west-2.amazonaws.com/us-west-2_example",
  "exp": 1562194124,
  "iat": 1562190524,
  "origin_jti": "bbbbbbbbb-cccc-dddd-eeee-aaaaaaaaaaaa",
  "jti": "cccccccc-dddd-eeee-aaaa-bbbbbbbbbbbb",
  "client_id": "12345abcde"
}

Trong token này, người chủ chính và người thuê kèm theo được đại diện bằng sự kết hợp của mã người dùng (sub claim) và ID người thuê trong claim cognito:groups. Trong ví dụ này, ứng dụng SaaS đại diện cho một người thuê bằng cách tạo một nhóm Cognito cho mỗi người thuê. Các nhà cung cấp danh tính khác có thể cho phép bạn thêm một thuộc tính tùy chỉnh vào người dùng được phản ánh trong mã truy cập.

Khi một ứng dụng SaaS nhận được JWT như một phần của yêu cầu, ứng dụng sẽ xác thực mã và giải nén nội dung để đưa ra quyết định phân quyền. Các khai báo trong token thiết lập những gì được gọi là bối cảnh người thuê. Giống như cách biến môi trường có thể ảnh hưởng đến một ứng dụng dòng lệnh, bối cảnh người thuê ảnh hưởng đến cách ứng dụng SaaS xử lý yêu cầu.

Bằng cách sử dụng JWT, ứng dụng SaaS có thể xử lý yêu cầu mà không cần tham chiếu thường xuyên đến nhà cung cấp danh tính bên ngoài hoặc dịch vụ trung tâm khác.

Cô lập khách hàng (tenant isolation)

Tenant isolation là nền tảng cho mọi ứng dụng SaaS. Mỗi ứng dụng SaaS phải đảm bảo rằng một người thuê không thể truy cập được tài nguyên của người thuê khác. Ứng dụng SaaS phải tạo ra các giới hạn đủ để cô lập một người thuê khỏi người thuê khác.

Xác định những gì đủ để cô lập phụ thuộc vào lĩnh vực của bạn, mô hình triển khai và bất kỳ khung tuân thủ nào có liên quan. Các kỹ thuật để cô lập người thuê với nhau phụ thuộc vào mô hình cô lập và các ứng dụng bạn sử dụng. Phần này cung cấp một tổng quan về các chiến lược cô lập người thuê.

Mô hình triển khai của bạn ảnh hưởng đến sự cô lập (isolation)

Cách một ứng dụng được triển khai ảnh hưởng đến cách tenant bị cô lập. Các ứng dụng SaaS có thể sử dụng ba loại cách ly: silo, pool và bridge.

Mô hình triển khai Silo

Mô hình triển khai silo bao gồm khách hàng triển khai một bộ cơ sở hạ tầng cho mỗi người thuê. Tùy thuộc vào ứng dụng, điều này có thể có nghĩa là một VPC cho mỗi người thuê, một tập hợp các container cho mỗi người thuê, hoặc một tài nguyên khác được triển khai cho mỗi người thuê. Trong mô hình này, có một triển khai cho mỗi người thuê, mặc dù có thể có một số cơ sở hạ tầng chung cho quản trị giữa các người thuê. Hình 4 cho thấy một ví dụ về một triển khai silo sử dụng mô hình VPC cho mỗi người thuê.

Hình 4 – Một ví dụ về triển khai siled cung cấp VPC cho mỗi tenant

Mô hình triển khai Pool

Mô hình triển khai hồ bơi (pool deployment) liên quan đến việc sử dụng chung một tập hợp cơ sở hạ tầng cho tất cả các khách hàng (tenant). Cách ly giữa các khách hàng được thực hiện một cách logic trong ứng dụng thông qua các cấu trúc cấp ứng dụng. Thay vì sử dụng các tài nguyên riêng biệt cho từng khách hàng, việc thực thi cách ly được thực hiện trong ứng dụng. Hình 5 minh họa một ví dụ về mô hình triển khai hồ bơi sử dụng công nghệ phi máy chủ (serverless).

Hình 5 – Một ví dụ về mô hình triển khai gộp bằng cách sử dụng công nghệ không máy chủ

Trong Hình 5, một hàm AWS Lambda được sử dụng để truy xuất một mục từ bảng Amazon DynamoDB được chia sẻ cho tất cả các khách hàng (tenants) cần có các thông tin đăng nhập tạm thời được cấp bởi AWS Security Token Service. Những thông tin này chỉ cho phép người yêu cầu truy cập vào các mục trong bảng thuộc về khách hàng đang yêu cầu. Một người yêu cầu có thể nhận được thông tin đăng nhập tạm thời này bằng cách giả định một vai trò Quản lý danh tính và Truy cập AWS (IAM). Điều này cho phép một ứng dụng SaaS chia sẻ cơ sở hạ tầng cơ bản, trong khi vẫn cách ly các khách hàng với nhau. Xem phần ” Isolation enforcement depends on service” bên dưới để biết thêm chi tiết về mô hình này.

Mô hình triển khai Bridge

Mô hình bridge kết hợp các yếu tố của cả mô hình silo và pool. Một số tài nguyên có thể được tách biệt, trong khi một số khác có thể được chia sẻ. Ví dụ, giả sử ứng dụng của bạn có một lớp ứng dụng chung và một trường hợp Amazon Relational Database Service (RDS) cho mỗi khách hàng. Lớp ứng dụng đánh giá mỗi yêu cầu và kết nối đến cơ sở dữ liệu cho khách hàng đã yêu cầu.

Mô hình này hữu ích trong tình huống mỗi khách hàng có thể yêu cầu một thời gian phản hồi nhất định và một tập hợp tài nguyên hoạt động như một điểm nghẽn. Trong ví dụ về RDS, lớp ứng dụng có thể xử lý các yêu cầu của khách hàng, nhưng một trường hợp RDS duy nhất không thể.

Quyết định triển khai mô hình cách ly nào phụ thuộc vào yêu cầu của khách hàng, nhu cầu tuân thủ quy định hoặc nhu cầu của ngành. Bạn có thể tìm thấy một số khách hàng có thể triển khai trên mô hình pool, trong khi các khách hàng lớn hơn có thể yêu cầu triển khai riêng biệt trên mô hình silo.

Chiến lược phân tầng của bạn cũng có thể ảnh hưởng đến loại mô hình cách ly bạn sử dụng. Ví dụ, một khách hàng ở lớp cơ bản có thể triển khai trên cơ sở hạ tầng được phân chia, trong khi một khách hàng ở lớp doanh nghiệp được triển khai trên cơ sở hạ tầng được phân tách.

Để biết thêm thông tin về các mô hình cách ly khác nhau cho khách hàng, hãy đọc whitepaper về chiến lược cách ly tenant.

Sự thực thi cô lập phụ thuộc vào dịch vụ (Isolation enforcement depends on service)

Hầu hết các ứng dụng SaaS đều cần nơi để lưu trữ thông tin trạng thái. Điều này có thể là cơ sở dữ liệu quan hệ, cơ sở dữ liệu NoSQL hoặc một phương tiện lưu trữ khác nào đó để lưu trữ trạng thái. Các ứng dụng SaaS được xây dựng trên AWS sử dụng các cơ chế khác nhau để bảo đảm cô lập khách hàng khi truy cập vào phương tiện lưu trữ bền vững.

IAM cung cấp kiểm soát truy cập chi tiết cho API của AWS. Một số dịch vụ, chẳng hạn như Amazon Simple Storage Service (Amazon S3) và DynamoDB, cung cấp khả năng kiểm soát truy cập vào các đối tượng hoặc mục cá nhân với chính sách IAM. Khi có thể, ứng dụng của bạn nên sử dụng chức năng tích hợp sẵn của IAM để giới hạn truy cập vào tài nguyên của khách hàng. Xem Isolating SaaS Tenants with Dynamically Generated IAM Policies để biết thêm thông tin về cách sử dụng IAM để thực hiện cô lập khách hàng.

AWS IAM cũng cung cấp khả năng hạn chế truy cập vào tài nguyên dựa trên các thẻ. Điều này được gọi là kiểm soát truy cập dựa trên thuộc tính (ABAC). Kỹ thuật này cho phép bạn áp dụng thẻ cho các tài nguyên được hỗ trợ và ra quyết định kiểm soát truy cập dựa trên các thẻ được áp dụng. Đây là một cơ chế kiểm soát truy cập có khả năng mở rộng hơn kiểm soát truy cập dựa trên vai trò (RBAC), vì bạn không cần phải sửa đổi chính sách IAM mỗi khi thêm hoặc xóa một tài nguyên. Xem How to implement SaaS tenant isolation with ABAC and AWS IAM để biết thêm thông tin về cách áp dụng điều này cho ứng dụng SaaS.

Một số cơ sở dữ liệu quan hệ cung cấp tính năng có thể bảo đảm cô lập khách hàng. Ví dụ, PostgreSQL cung cấp tính năng gọi là bảo mật cấp hàng (RLS). Tùy thuộc vào ngữ cảnh mà truy vấn được gửi đến cơ sở dữ liệu, chỉ những mục cụ thể của khách hàng được trả về trong kết quả. Xem Multi-tenant data isolation with PostgreSQL Row Level Security để biết thêm thông tin về bảo mật cấp hàng trong PostgreSQL.

Các phương tiện lưu trữ bền vững khác không có mô hình quyền hạn chi tiết. Tuy nhiên, chúng có thể cung cấp một loại bộ chứa trạng thái cho mỗi khách hàng. Ví dụ, khi sử dụng MongoDB, mỗi khách hàng được gán một người dùng MongoDB và một cơ sở dữ liệu MongoDB. Bí mật liên quan đến người dùng có thể được lưu trữ trong AWS Secrets Manager. Khi truy xuất dữ liệu của một khách hàng, ứng dụng SaaS trước tiên lấy bí mật, sau đó xác thực với MongoDB. Điều này tạo ra sự cô lập khách hàng vì các thông tin đăng nhập liên quan chỉ có quyền truy cập vào các bộ sưu tập trong cơ sở dữ liệu cụ thể của khách hàng.

Nói chung, nếu phương tiện lưu trữ bền vững mà bạn đang sử dụng cung cấp mô hình quyền hạn riêng của riêng nó để bảo đảm cô lập khách hàng, bạn nên sử dụng nó, vì điều này giúp bạn tránh việc thực hiện cô lập trong ứng dụng của mình. Tuy nhiên, có thể có những trường hợp mà cơ sở dữ liệu của bạn không cung cấp mức độ cô lập này. Trong tình huống này, bạn sẽ cần phải viết phần mềm để thực thi cô lập khách hàng ở mức ứng dụng. Cô lập khách hàng ở mức ứng dụng có nghĩa là ứng dụng SaaS, chứ không phải phương tiện lưu trữ bền vững, đảm bảo rằng một khách hàng không thể truy cập vào dữ liệu của khách hàng khác.

Kết luận

Bài viết này đánh giá những thách thức, cơ hội và các phương pháp tốt nhất cho những yếu tố bảo mật đặc biệt liên quan đến ứng dụng SaaS đa người dùng, và mô tả những yếu tố định danh cụ thể, cũng như các phương pháp cô lập khách hàng.

Nếu bạn muốn tìm hiểu thêm về các chủ đề trên, AWS Well-Architected SaaS Lens Security pillar sẽ đào sâu vào quản lý hiệu suất trong môi trường SaaS. Nó cũng cung cấp các phương pháp tốt nhất và tài nguyên để giúp bạn thiết kế và cải thiện hiệu quả hiệu suất trong ứng dụng SaaS của bạn.

Bắt đầu với AWS Well-Architected SaaS Lens

AWS Well-Architected SaaS Lens tập trung vào khối lượng công việc SaaS và nhằm thúc đẩy tư duy phản biện để phát triển và vận hành khối lượng công việc SaaS. Mỗi câu hỏi trong lens có một danh sách các phương pháp hay nhất và mỗi phương pháp hay nhất đều có một danh sách các kế hoạch cải tiến để giúp hướng dẫn bạn thực hiện chúng.

Lens có thể được áp dụng cho khối lượng công việc hiện có hoặc được sử dụng cho khối lượng công việc mới mà bạn xác định trong công cụ. Bạn có thể sử dụng nó để cải thiện ứng dụng bạn đang làm việc hoặc để hiển thị nhiều khối lượng công việc được sử dụng bởi bộ phận hoặc khu vực bạn đang làm việc.

Lens SaaS khả dụng ở tất cả các Khu vực nơi cung cấp AWS Well-Architected Tool, như được mô tả trong Danh sách dịch vụ khu vực của AWS. Không có chi phí khi sử dụng Công cụ được kiến ​​trúc tốt AWS.

Nếu bạn là khách hàng AWS, hãy tìm Đối tác AWS hiện tại có thể tiến hành đánh giá bằng cách tìm hiểu về  AWS Well-Architected Partners và AWS SaaS Competency Partners.

Nếu bạn có phản hồi về bài đăng này, hãy gửi ý kiến ​​trong phần Bình luận bên dưới. Nếu bạn có câu hỏi về bài đăng này, hãy bắt đầu một chủ đề mới trên Security Hub forum. Để bắt đầu dùng thử Security Hub miễn phí trong 30 ngày, hãy truy cập  AWS Security Hub.

---

Bài được dịch từ bài viết trên AWS Blogs, bạn có thể xem bài viết gốc tại đây.