TÌM HIỂU VỀ RBAC và ABAC

Xin chào các anh chị em. Hôm nay, chúng ta cùng tìm hiểu 1 chút về RBAC và ABAC nhé. Mọi người đã từng nghe nói đến bao giờ chưa ? Nếu chưa nghe thì đây mọi người cùng thử nghiên cứu nhé. 

Trong quá trình học AWS nói chung và có hơi “đụng chạm” 1 chút tới Security, chúng ta có một số thuật ngữ như thế này:

RBAC – Role-based access control: Điều khiển quyền truy cập dựa trên Role. Ở đây IAM thì chắc là không cần nói nữa rồi nhỉ. Các anh chị em từ già đến trẻ, ai vào học AWS hay làm việc với AWS cũng đều biết đến IAM. IAM là service quản lý xác thực và truy cập, và IAM truyền thống đi theo mô hình RBAC.

Mô hình RBAC mô tả mỗi một function, instance hay resource … sẽ được gán một Role khác nhau. Những Role này dành riêng cho function/instance,resource, user … đó. Để làm được việc này, trước tiên chúng ta tiến hành tạo IAM User, IAM Role hoặc IAM Group. Sau đó chúng ta gán cho chúng 1 hay nhiều Policy mô tả những đối tượng đó được phép làm gì. Ở đây, đương nhiên chúng ta theo best practice, là sẽ cần gán các Policy đảm bảo least privilege, có nghĩa là chỉ gán quyền hạn tối thiểu, không gán thừa quyền hay vượt quá quyền hạn. (Nhưng thường thì mọi người cứ gán toẹt 1 cái quyền Admin cho nhanh :D). Thì đó, mô hình RBAC cũng chỉ đơn giản là những gì chúng ta đã biết, đã học, đã làm.

ABAC – Attribute based access control: Điều khiển truy cập dựa trên Attribute. Ở trên AWS, khi chúng ta mới học AWS hay tìm hiểu về các resource trên AWS, chúng ta thấy rất nhiều nơi có sử dụng Tags. Và mọi người có đặt ra câu hỏi là, cái Tags này để làm gì mà chỗ nào cũng thấy có. Và đây là lúc chúng ta sử dụng tới nó – mô hình ABAC.

Mô hình ABAC mô tả rằng: mỗi một function, instance hay resource … sẽ được gán một Attribute riêng biệt (ở đây là Tags). Khi chúng ta cấp quyền hay Policy cho các đối tượng như IAM User, Group, Role, chúng ta không gán cụ thể được phép thao tác tới resource nào, mà chúng ta gán các Policy cho phép thao tác với resource chứa tag gì.

Ví dụ: Chúng ta cần  cho phép User A được truy cập tới S3 bucket demo. 

• Với RBAC, chúng ta khai báo Policy cho phép access tới bucket demo. Sau đó gán Policy này cho User A.

• Với ABAC, chúng ta khái báo Policy cho phép access tới bất cứ resource nào có tag là allowA. Ở phía bucket, chúng ta gán Tag cho bucket đó là allowA. Sau đó gán Policy này cho User A. Đó, giải thích thì lằng nhằng, nhưng nói ra thì chỉ có vậy thôi.

Chúng ta phân tích 1 chút điểm mạnh và yếu của RBAC và ABAC.

Chỉ với RBAC, chúng ta đã rất dễ dàng cấp quyền tương đương, cho một User hay đối tượng nào đó khác. Chỉ việc copy Policy của người đó sang là được. Tuy nhiên việc cấp quyền tương đương cho 1 resource sẽ trở nên khó khăn. Như trong ví dụ trên, nếu cần cấp quyền tương đương cho một bucket tên là demo2 nữa thì sao ? Chúng ta sẽ cần phải sửa Policy đã gán. Việc này cũng không phải là một điều gì quá khó khăn. Tuy nhiên nếu việc này trở nên thường xuyên và liên tục, có vẻ là RBAC chưa được hiệu quả. Đối với ABAC, chúng ta làm thế nào ? Chỉ việc gán tag allowA vào bucket demo2. Rất đơn giản và hợp lý. Đúng không nào ? Đương nhiên là nó sẽ đi kèm với rủi ro là việc gán tag khá dễ dàng nên ai cũng làm được việc này, chúng ta sẽ cần quản lý leo thang quyền (permission escalation). Ngoài ra, các bạn cũng nên theo học trong các khóa học AWS để có thể tiếp cận được nhiều hơn nữa về các kiến thức này.

Hiện nay có rất nhiều trung tâm đang đào tạo về các khóa học AWS, tuy nhiên các bạn cũng nên tìm hiểu kĩ về các trung tâm trước khi theo học. Một trong số đó có CodeStar Academy tại Hà Nội. mọi người có thể tìm hiểu về khóa học AWS tại CodeStar ở đây nhé: https://codestar.vn/product/aws-co-ban/