Đây là bài đăng của khách đồng viết với Siva Bangaru và Leon Liu từ ADP.

ADP giúp các tổ chức thuộc mọi loại hình và quy mô bằng cách cung cấp các giải pháp quản lý nguồn nhân lực (HCM) hợp nhất HR, biên chế, tài năng, thời gian, Thuế, và quản lý phúc lợi. ADP là công ty hàng đầu về dịch vụ gia công phần mềm kinh doanh, phân tích và chuyên môn về tuân thủ. Kinh nghiệm chưa từng có, hiểu biết sâu sắc và tiên tiến của ADP công nghệ đã biến nguồn nhân lực từ một chức năng hành chính hỗ trợ thành một lợi thế kinh doanh chiến lược.

Phân tích con người được cung cấp bởi ADP DataCloud là một ứng dụng cung cấp phân tích và thông tin chi tiết nâng cao cho khách hàng của ADP. Nó mang lại trải nghiệm phân tích có hướng dẫn giúp bạn dễ dàng tạo, sử dụng và phân phối các phân tích phù hợp cho tổ chức của mình. Bảng điều khiển có thể định cấu hình, được sắp xếp hợp lý của ADP People Analytics có thể giúp bạn xác định các vấn đề tiềm ẩn trong các lĩnh vực chính, như làm thêm giờ, doanh thu, lương thưởng, v.v.

ADP cung cấp trải nghiệm phân tích này cho hàng nghìn khách hàng hiện nay. Bảo mật dữ liệu của khách hàng là ưu tiên hàng đầu của ADP. Công ty yêu cầu các tiêu chuẩn bảo mật cao nhất khi triển khai nền tảng phân tích nhiều bên thuê trên Amazon RedShift.

ADP DataCloud tích hợp với Bảo mật cấp hàng Amazon Redshift (RLS) để triển khai các quyền dữ liệu chi tiết và thực thi các hạn chế truy cập trên các bảng của họ trong Amazon Redshift.

Trong bài đăng này, chúng tôi thảo luận về cách nhóm ADP DataCloud triển khai Amazon Redshift RLS trên nền tảng kiểm soát truy cập dựa trên vai trò (RBAC) để đơn giản hóa việc quản lý các đặc quyền cần thiết trong môi trường nhiều đối tượng thuê, đồng thời cho phép và thực thi quyền truy cập vào các quyền dữ liệu chi tiết theo thuật ngữ kinh doanh.

Nhóm ADP DataCloud có các yêu cầu và thách thức chính sau:

• Hỗ trợ ứng dụng nhiều bên thuê để thực thi phân tách hợp lý các hàng dữ liệu của từng bên thuê
• Hỗ trợ cung cấp năng động cho người thuê mới
• Tác động tối thiểu đến hiệu suất

Bảo mật cấp hàng trong Amazon Redshift

Amazon Redshift là dịch vụ kho dữ liệu quy mô petabyte được quản lý hoàn toàn trên đám mây. Một trong những thách thức với bảo mật là các doanh nghiệp muốn cung cấp khả năng kiểm soát truy cập chi tiết ở cấp hàng cho dữ liệu nhạy cảm. Điều này có thể được thực hiện bằng cách tạo các dạng xem hoặc sử dụng các cơ sở dữ liệu và lược đồ khác nhau cho những người dùng khác nhau. Tuy nhiên, phương pháp này không thể mở rộng và trở nên phức tạp để duy trì theo thời gian, đặc biệt là khi hỗ trợ môi trường nhiều đối tượng thuê.

Vào đầu năm 2022, Amazon Redshift đã phát hành bảo mật cấp hàng, được xây dựng trên nền tảng của kiểm soát truy cập dựa trên vai trò. RLS cho phép bạn kiểm soát những người dùng hoặc vai trò nào có thể truy cập các bản ghi dữ liệu cụ thể trong các bảng, dựa trên các chính sách bảo mật được xác định ở cấp đối tượng cơ sở dữ liệu. Khả năng RLS mới này trong Amazon Redshift cho phép bạn lọc động các hàng dữ liệu hiện có trong bảng cùng với các khả năng thiết lập biến ngữ cảnh phiên để gán động cấu hình đối tượng thuê phù hợp. Điều này ngoài kiểm soát truy cập cấp cột, nơi bạn có thể cấp quyền cho người dùng đối với một tập hợp con các cột. Giờ đây, bạn có thể kết hợp kiểm soát quyền truy cập ở cấp độ cột với các chính sách RLS để hạn chế hơn nữa quyền truy cập vào các hàng cụ thể của các cột hiển thị. tham khảo Đạt được bảo mật dữ liệu chi tiết với kiểm soát truy cập cấp hàng trong Amazon Redshift để biết thêm chi tiết.

Tổng quan về giải pháp

Là một phần trong các yêu cầu chính của ADP để hỗ trợ kho lưu trữ dữ liệu nhiều bên thuê, trong đó một bảng duy nhất chứa dữ liệu của nhiều bên thuê, việc thực thi các chính sách bảo mật để đảm bảo không có quyền truy cập dữ liệu giữa nhiều bên thuê là hết sức quan trọng. Một cách rõ ràng để đảm bảo điều này là tạo người dùng cơ sở dữ liệu cho từng đối tượng thuê và triển khai các chính sách RLS để lọc dữ liệu của một đối tượng thuê theo người dùng đã đăng nhập. Nhưng điều này có thể tẻ nhạt và trở nên cồng kềnh để duy trì khi số lượng người thuê nhà tăng lên hàng nghìn người.

Bài đăng này trình bày một cách khác để xử lý trường hợp sử dụng này bằng cách kết hợp các biến ngữ cảnh phiên và chính sách RLS trên bảng để lọc dữ liệu của một đối tượng thuê, nhờ đó giảm bớt gánh nặng tạo và duy trì hàng nghìn người dùng cơ sở dữ liệu. Trên thực tế, một người dùng cơ sở dữ liệu duy nhất là tất cả những gì cần thiết để kết nối và truy vấn dữ liệu của các đối tượng thuê khác nhau trong các phiên khác nhau từ bảng nhiều đối tượng thuê bằng cách đặt các giá trị khác nhau cho biến ngữ cảnh phiên trong mỗi phiên, như được minh họa trong sơ đồ sau.

Hãy bắt đầu bằng cách trình bày các bước triển khai cấp cao. Giả sử có một người dùng cơ sở dữ liệu trong Amazon Redshift app_user (không phải là siêu người dùng, cũng không phải là sys:secadmin vai trò được cấp, cũng không có IGNORE RLS đặc quyền hệ thống được cấp qua vai trò khác). Người dùng app_user sở hữu một lược đồ có cùng tên và tất cả các đối tượng trong đó. Sau đây là một bảng nhiều người thuê điển hình employee trong app_user lược đồ với một số bản ghi mẫu được hiển thị trong bảng:

CREATE TABLE app_user.employee ( tenant_id varchar(50) not null, id varchar(50) not null, name varchar(200), email varchar(200), ssn char(9), constraint employee_pkey primary key (tenant_id,id) );

Để thực hiện điều đó, cần thực hiện các bước sau:

1. Tạo chính sách RLS trên cột bằng cách sử dụng vị ngữ được đặt bằng cách sử dụng biến ngữ cảnh phiên.
2. Bật RLS ở cấp độ bảng và đính kèm chính sách RLS trên bảng.
3. Tạo một thủ tục được lưu trữ để đặt biến bối cảnh phiên được sử dụng trong vị ngữ chính sách RLS.
4. Kết nối và gọi thủ tục được lưu trữ để đặt biến bối cảnh phiên và truy vấn bảng.

Bây giờ RLS có thể được kích hoạt trên bảng này theo cách mà bất cứ khi nào app_user truy vấn bảng nhân viên, người dùng sẽ không thấy hàng nào hoặc chỉ truy xuất các hàng dành riêng cho một đối tượng thuê mặc dù là chủ sở hữu của bảng.

Một quản trị viên, chẳng hạn như app_admin, siêu người dùng hoặc người dùng có sys:secadmin vai trò, có thể thực thi điều này như sau:

1. Tạo chính sách RLS đính kèm một tenant_id vị ngữ sử dụng biến bối cảnh phiên:

   create rls policy tenant_policy
   with (tenant_id varchar(50))
   using (tenant_id = current_setting('app_context.tenant_id'));

2. Bật RLS và đính kèm chính sách trên bảng nhân viên:

   alter table app_user.employee row level security on; attach rls policy tenant_policy on app_user.employee to public;

3. Tạo một thủ tục được lưu trữ để thiết lập tenant_id trong một biến phiên và cấp quyền truy cập cho app_user:

   create or replace procedure app_admin.set_app_context
   (p_tenant_id in varchar) language plpgsql
   as $$ declare v_tenant_id varchar(50);
   begin reset all; v_tenant_id := set_config('app_context.tenant_id',p_tenant_id,false); end; $$
   ; grant execute on app_admin. set_app_context(varchar) to app_user;

4. Kết nối với app_user và gọi thủ tục được lưu trữ để đặt biến bối cảnh phiên:

   call app_admin.set_app_context('T0001');

Khi quá trình thiết lập này hoàn tất, bất cứ khi nào đối tượng thuê kết nối với bảng điều khiển ADP Analytics, nó sẽ kết nối dưới dạng app_user và chạy các thủ tục được lưu trữ bằng cách chuyển tenant_id, đặt biến bối cảnh phiên sử dụng ID đối tượng thuê. Trong trường hợp này, khi có yêu cầu kết nối và truy vấn employee bảng, người dùng sẽ gặp các trường hợp sau:

• Không lấy được dữ liệu nếu current_setting('app_context.tenant_id') không được đặt hoặc là null
• Dữ liệu được lấy ra nếu current_setting('app_context.tenant_id') được thiết lập bằng cách gọi app_admin.set_app_context(varchar) thủ tục thành một giá trị tồn tại trong employee bảng (ví dụ, app_admin.set_app_context(‘T0001’))

Không lấy được dữ liệu nếu current_setting('app_context.tenant_id') được đặt thành một giá trị không tồn tại trong employee bảng (ví dụ, app_admin.set_app_context(‘T9999’))

Xác thực RLS bằng cách kiểm tra các gói truy vấn

Bây giờ, hãy xem lại các tình huống trước đó bằng cách chạy một kế hoạch giải thích và quan sát cách RLS hoạt động đối với thiết lập thử nghiệm. Nếu một truy vấn chứa một bảng tuân theo chính sách RLS, EXPLAIN hiển thị một RLS đặc biệt SecureScan nút. Amazon Redshift cũng ghi lại loại nút tương tự vào STL_EXPLAIN bảng hệ thống. EXPLAIN không tiết lộ vị từ RLS áp dụng cho employee bàn. Để xem một kế hoạch giải thích với các chi tiết vị từ RLS, EXPLAIN RLS đặc quyền hệ thống được cấp cho app_user thông qua một vai trò.

Trong kịch bản đầu tiên này, tenant_id không được đặt bởi thủ tục được lưu trữ và được chuyển dưới dạng giá trị null, do đó, câu lệnh chọn bên dưới không trả về hàng nào.

=> select count(1),tenant_id from employee group by 2; count | tenant_id -------+------------- (0 rows)

Giải thích đầu ra kế hoạch hiển thị bộ lọc là NULL:

=> explain select count(1),tenant_id from employee group by 2; QUERY PLAN -------------------------------------------------------------------------------- XN HashAggregate (cost=0.10..0.11 rows=4 width=20) -> XN RLS SecureScan employee (cost=0.00..0.08 rows=4 width=20) -> XN Result (cost=0.00..0.04 rows=4 width=20) One-Time Filter: NULL::boolean -> XN Seq Scan on employee (cost=0.00..0.04 rows=4 width=20) (5 rows)

Trong kịch bản thứ hai, tenant_id được thiết lập bởi thủ tục được lưu trữ và được chuyển thành giá trị của T0001, do đó chỉ trả lại các hàng tương ứng như được hiển thị trong đầu ra của kế hoạch giải thích:

Gọi thủ tục được lưu trữ để đặt biến bối cảnh phiên là 'T0001' và sau đó chạy select :

=> call app_admin.set_app_context('T0001'); => select count(1),tenant_id from employee group by 2; count | tenant_id
-------+------------------ 3 | T0001
(1 row)

Giải thích đầu ra kế hoạch hiển thị bộ lọc trên tenant_id là 'T0001'

=> explain select count(1),tenant_id from employee group by 2; QUERY PLAN
-------------------------------------------------------------------------- XN HashAggregate (cost=0.07..0.07 rows=1 width=20) -> XN RLS SecureScan employee (cost=0.00..0.06 rows=1 width=20) -> XN Seq Scan on employee (cost=0.00..0.05 rows=1 width=20) Filter: ((tenant_id)::text = 'T0001'::text)
(4 rows)

Trong kịch bản thứ ba, một không tồn tại tenant_id đã được thiết lập bởi thủ tục được lưu trữ, do đó không trả về hàng nào:

=> call app_admin.set_app_context('T9999'); => select count(1),tenant_id from employee group by 2; count | tenant_id
-------+-------------
(0 rows) => explain select count(1),tenant_id from employee group by 2; QUERY PLAN
-------------------------------------------------------------------------- XN HashAggregate (cost=0.07..0.07 rows=1 width=20) -> XN RLS SecureScan employee (cost=0.00..0.06 rows=1 width=20) -> XN Seq Scan on employee (cost=0.00..0.05 rows=1 width=20) Filter: ((tenant_id)::text = 'T9999'::text)
(4 rows)

Một điểm quan trọng khác là bạn có thể áp dụng cùng một chính sách cho nhiều bảng miễn là chúng có cột (tenant_id varchar(50)) được xác định bằng cùng một loại dữ liệu, bởi vì các chính sách RLS được nhập mạnh vào Amazon Redshift. Tương tự, bạn có thể kết hợp nhiều chính sách RLS được xác định bằng cách sử dụng các biến ngữ cảnh phiên khác nhau hoặc các vị từ cột có liên quan khác và đính kèm chúng vào một bảng.

Ngoài ra, việc triển khai RLS này không cần bất kỳ thay đổi nào khi dữ liệu của đối tượng thuê mới được thêm vào bảng, bởi vì nó có thể được truy vấn bằng cách chỉ cần đặt mã định danh của đối tượng thuê mới trong biến ngữ cảnh phiên được sử dụng để xác định vị từ bộ lọc bên trong RLS chính sách. Một đối tượng thuê đối với ánh xạ mã định danh tương ứng của nó thường được thực hiện trong quá trình giới thiệu đối tượng thuê của ứng dụng và thường được duy trì trong một kho dữ liệu di động riêng biệt, cũng được tham chiếu trong quá trình đăng nhập của mỗi đối tượng thuê để lấy mã định danh của đối tượng thuê. Cùng với đó, hàng nghìn đối tượng thuê có thể được cung cấp mà không cần thay đổi bất kỳ chính sách nào trong Amazon Redshift. Trong thử nghiệm của mình, chúng tôi không tìm thấy tác động nào đến hiệu suất của đối tượng thuê sau khi RLS được triển khai.

Kết luận

Trong bài đăng này, chúng tôi đã trình bày cách nhóm ADP DataCloud triển khai bảo mật cấp hàng trong môi trường nhiều đối tượng thuê cho hàng nghìn khách hàng sử dụng Amazon Redshift RLS và các biến ngữ cảnh phiên. Để biết thêm thông tin về các phương pháp hay nhất về RLS, hãy tham khảo Tổng quan về bảo mật Amazon Redshift.

Hãy dùng thử RLS cho các triển khai Amazon Redshift trong tương lai của bạn và vui lòng để lại nhận xét về các trường hợp sử dụng và trải nghiệm của bạn.

Giới thiệu về tác giả

Siva Bangaru là Kiến trúc sư cơ sở dữ liệu tại ADP. Ông có hơn 13 năm kinh nghiệm với chuyên môn kỹ thuật về thiết kế, phát triển, quản trị và điều chỉnh hiệu suất của các giải pháp cơ sở dữ liệu cho nhiều trường hợp sử dụng OLAP và OLTP trên nhiều công cụ cơ sở dữ liệu như Oracle, Amazon Aurora PostgreSQL và Amazon Redshift.

Leon Liu là Kiến trúc sư trưởng tại ADP. Ông có hơn 20 năm kinh nghiệm với khung ứng dụng doanh nghiệp, kiến ​​trúc, kho dữ liệu và xử lý dữ liệu lớn theo thời gian thực.

Neha Daudani là Kiến trúc sư giải pháp tại AWS. Cô ấy có 15 năm kinh nghiệm trong lĩnh vực dữ liệu và phân tích. Cô đã hỗ trợ khách hàng trong các dự án khác nhau về kho dữ liệu doanh nghiệp, quản trị dữ liệu, trực quan hóa dữ liệu, quản lý dữ liệu chính, mô hình hóa dữ liệu và di chuyển dữ liệu để khách hàng sử dụng thông tin kinh doanh và phân tích trong tăng trưởng kinh doanh và hiệu quả hoạt động.

Rohit Bansal là Kiến trúc sư giải pháp chuyên gia phân tích tại AWS. Anh ấy chuyên về Amazon Redshift và làm việc với khách hàng để xây dựng các giải pháp phân tích thế hệ tiếp theo bằng cách sử dụng các dịch vụ AWS Analytics khác.

• Coinsmart. Sàn giao dịch Bitcoin và tiền điện tử tốt nhất Châu Âu.Bấm vào đây
• Platoblockchain. Web3 Metaverse Intelligence. Khuếch đại kiến ​​thức. Truy cập Tại đây.
• nguồn: https://aws.amazon.com/blogs/big-data/implement-row-level-access-control-in-a-multi-tenant-environment-with-amazon-redshift/