AWS Big Data Blog

Cách BMO cải thiện khả năng bảo mật dữ liệu với Amazon Redshift và AWS Lake Formation

Bài post này được viết chung bởi Amy Tseng, Jack Lin và Regis Chow từ BMO.

BMO là ngân hàng lớn thứ 8 ở Bắc Mỹ tính theo giá trị tài sản. Ngân hàng này cung cấp dịch vụ ngân hàng cá nhân và doanh nghiệp, thị trường toàn cầu và dịch vụ ngân hàng đầu tư cho 13 triệu khách hàng. Khi họ tiếp tục triển khai chiến lược Digital First để tăng tốc độ, quy mô và giảm thiểu sự phức tạp, họ luôn tìm cách đổi mới, hiện đại hóa và hợp lý hóa việc kiểm soát truy cập dữ liệu trên Cloud. BMO đã tích lũy một lượng dữ liệu tài chính nhạy cảm và có nhu cầu xây dựng một môi trường phân tích những dữ liệu đó một cách an toàn và hiệu quả. Một trong những thách thức chính của ngân hàng liên quan đến các yêu cầu nghiêm ngặt về an ninh mạng (cybersecurity) là triển khai mã hóa cấp trường (field level) đối với thông tin nhận dạng cá nhân – Personally identifiable information (PII), dữ liệu thẻ thanh toán – Payment Card Industry (PCI) và dữ liệu được phân loại là có rủi ro bảo mật cao – high privacy risk (HPR). Dữ liệu thuộc lớp dữ liệu bảo mật đó sẽ được lưu trữ mã hóa cả trong data warehouse và data lake của họ. Chỉ những user có quyền cần thiết mới được phép truy cập dữ liệu ở dạng văn bản rõ ràng.

Amazon Redshift là dịch vụ kho dữ liệu (data warehouse) được quản lý hoàn toàn (fully managed) bởi AWS mà hàng chục nghìn khách hàng sử dụng để quản lý phân tích dữ liệu với quy mô lớn. Amazon Redshift hỗ trợ khả năng bảo mật hàng đầu trong ngành với tính năng liên kết và quản lý danh tính tích hợp cho single sign-on – đăng nhập một lần (SSO) cùng với multi-factor authentication – xác thực nhiều yếu tố. Tính năng Amazon Redshift Spectrum cho phép truy vấn trực tiếp vào data lake Amazon Simple Storage Service (Amazon S3), và nhiều khách hàng đang sử dụng tính năng này để hiện đại hóa nền tảng dữ liệu của họ.

AWS Lake Formation là một dịch vụ quản lý hoàn toàn (fully managed) giúp đơn giản hóa việc xây dựng, bảo mật và quản lý data lake. Nó cung cấp khả năng kiểm soát truy cập chi tiết, gắn thẻ (tag-based access control (TBAC)), và tích hợp giữa các dịch vụ phân tích. Nó cho phép đơn giản hóa việc quản lý các đối tượng danh mục dữ liệu (data catalog) và truy cập dữ liệu được bảo mật từ các dịch vụ như Amazon Redshift Spectrum.

Trong bài post này, chúng tôi chia sẻ giải pháp sử dụng kiểm soát truy cập dựa trên vai trò của Amazon Redshift – Amazon Redshift role based access control (RBAC) và kiểm soát truy cập dựa trên thẻ AWS Lake Formation – AWS Lake Formation tag-based để người dùng liên kết truy vấn kho dữ liệu data lake bằng Amazon Redshift Spectrum.

Trường hợp sử dụng

BMO có hơn Petabyte(PB) dữ liệu nhạy cảm về tài chính được phân loại như sau:

Personally Identifiable Information – Thông tin cá nhân (PII)
Payment Card Industry – ngành thẻ thanh toán (PCI)
High Privacy Risk – Rủi ro bảo mật cao (HPR)

Ngân hàng đặt mục tiêu lưu trữ dữ liệu trong data warehouse Amazon Redshift và data lake Amazon S3 của họ. Họ có một cơ sở người dùng cuối lớn và đa dạng trải rộng các bộ phận bán hàng, tiếp thị, rủi ro tín dụng và các ngành nghề kinh doanh cũng như đặc trưng khác nhau:

Business analysts – Nhà phân tích nghiệp vụ
Data engineers – Kỹ sư dữ liệu
Data scientists – Nhà khoa học dữ liệu

Cần áp dụng kiểm soát truy cập chi tiết đối với dữ liệu trên cả Amazon Redshift và data lake được truy cập bằng Amazon Redshift Spectrum. Ngân hàng tận dụng các dịch vụ AWS như AWS Glue và Amazon SageMaker trên nền tảng phân tích này. Họ cũng sử dụng một nhà cung cấp danh tính bên ngoài – external identity provider (IdP) để quản lý cơ sở người dùng ưa thích của họ và tích hợp nó với các công cụ phân tích này. Người dùng cuối truy cập dữ liệu này bằng các ứng dụng SQL của bên thứ ba và các công cụ kinh doanh thông minh.

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

Trong bài post này, chúng tôi sẽ sử dụng dữ liệu tổng hợp tương tụ với dữ liệu BMO với các loại dữ liệu PII, PCI, hoặc HPR. Users và groups tồn tại trong External IdP. Những người dùng này liên kết để đăng nhập một lần (single sign on) vào Amazon Redshift bằng cách sử dụng liên kết
IdP gốc – native IdP federation. Chúng tôi sẽ xác định các quyền bằng cách sử dụng Redshift role based access control (RBAC) cho các vai trò – role của người dùng. Đối với người dùng truy cập dữ liệu trong kho dữ liệu data lake bằng Amazon Redshift Spectrum, chúng tôi sẽ sử dụng Lake Formation policies để kiểm soát quyền truy cập.

Giải pháp kỹ thuật

Để đáp ứng nhu cầu bảo mật các loại dữ liệu khác nhau của khách hàng, việc định nghĩa nhiều vai trò (role) AWS IAM khác nhau là cần thiết, điều này đòi hỏi kiến thức về IAM policies và việc duy trì các chính sách (policy) đó khi ranh giới quyền (permission boundary) thay đổi.

Trong bài post này, chúng tôi trình bày cách đơn giản hóa việc quản lý các chính sách phân loại dữ liệu bằng cách sử dụng số lượng tối thiểu các IAM role của Amazon Redshift được xếp theo phân loại dữ liệu, thay vì kết hợp phức tạp các role dựa trên mỗi ngành nghề và phân loại dữ liệu. Các tổ chức khác (ví dụ, Viện Dịch vụ Tài chính [FSI]) có thể học hỏi từ việc triển khai an ninh và tuân thủ dữ liệu của BMO.

Trong phần này của bài viết, dữ liệu sẽ được tải lên Amazon S3. Quyền truy cập vào dữ liệu được kiểm soát bằng các chính sách (policies) được định nghĩa bằng cách sử dụng RBAC của Redshift cho các nhóm người dùng của nhà cung cấp danh tính (Identity provider) tương ứng, và kiểm soát truy cập dựa trên TAG sẽ được triển khai thực hiện bằng việc sử dụng AWS Lake Formation đối với dữ liệu trên S3.

Kiến trúc giải pháp

Sơ đồ sau minh họa kiến trúc giải pháp cùng với các bước chi tiết.

IdP users thuộc các nhóm như lob_risk_public, Lob_risk_pci, hr_public, và hr_hpr được chỉ định/khai báo trong External IdP (Identity Provider).
Mỗi users được ánh xạ tới các role cục bộ của Amazon Redshift được gửi từ IdP, và gồm aad:lob_risk_pci, aad:lob_risk_public, aad:hr_public, và aad:hr_hpr trong Amazon Redshift. Ví dụ: User1 là một phần của Lob_risk_public và hr_hpr sẽ cấp quyền sử dụng role tương ứng.
Gán các IAM role iam_redshift_hpr, iam_redshift_pcipii, và iam_redshift_public vào Amazon Redshift cluster.
AWS Glue databases (ý ở đây là AWS Glue Data Catalog) được hỗ trợ trên S3 (ví dụ: lobrisk,lobmarket,hr và các bảng tương ứng của chúng their respective tables) được tham chiếu trong Amazon Redshift. Sử dụng Amazon Redshift Spectrum, bạn có thể truy vấn các tables và databases external này (ví dụ: external_lobrisk_pci, external_lobrisk_public, external_hr_public, and external_hr_hpr), những bảng mà được tạo với các IAM roles iam_redshift_pcipii, iam_redshift_hpr, iam_redshift_public như được minh họa trong kiến trúc.
AWS Lake Formation được sử dụng để kiểm soát quyền truy cập vào các schema và bảng external.
Bằng cách sử dụng AWS Lake Formation tags, chúng tôi áp dụng biện pháp fine-grained access control cho các external tables cho AWS IAM roles (Ví dụ: iam_redshift_hpr, iam_redshift_pcipii, và iam_redshift_public).
Cuối cùng, cấp quyền sử dụng các external schemas này cho các Amazon Redshift roles của chúng.

Hướng dẫn – Walkthrough

Các phần sau sẽ hướng dẫn bạn cách triển khai giải pháp bằng cách sử dụng dữ liệu tổng hợp.

Download các data files và đưa các files vào buckets

Amazon S3 đóng vai trò là data lake trên AWS có độ bền (durable) và khả năng mở rộng (scalable) cao. Bằng cách sử dụng Data Lake, bạn có thể đưa mọi dữ liệu định dạng mở như CSV, JSON, PARQUET hoặc ORC vào Amazon S3 và thực hiện phân tích trên dữ liệu của mình.

Các giải pháp sử dụng file dữ liệu CSV chứa thông tin được phân loại là PCI, PII, HPR hoặc Public. Bạn có thể tải xuống các input file bằng các liên kết được cung cấp bên dưới. Sử dụng các file đã tải xuống để upload lên Amazon S3 bằng cách tạo thư mục và tệp như trong ảnh chụp màn hình bên dưới bằng cách làm theo hướng dẫn tại đây. Chi tiết của từng file được cung cấp trong danh sách sau:

credit_card_transaction_PCI_public – Chứa các giao dịch thẻ tín dụng được phân loại là dữ liệu công khai và có thể hiển thị cho những người có quyền truy cập vào dữ liệu công khai.
credit_card_transaction_PCI – Chứa số thẻ tín dụng và chỉ được truy cập bởi những người có quyền hoặc được phép truy cập vào dữ liệu PCI.
lob_risk_High_confidential_public – Chứa các báo cáo kinh doanh được truy cập hoặc chia sẻ công khai.
lob_risk_High_confidential– Chứa các báo cáo kinh doanh bí mật chỉ những người được chọn (ví dụ: người đứng đầu hoặc lãnh đạo ngành kinh doanh mới có quyền truy cập)
customers_PII_HPR_public – Chứa dữ liệu của khách hàng được truy cập bởi những người có quyền truy cập công cộng.
customers_PII_HPR– Chứa thông tin nhận dạng cá nhân (PII), dữ liệu này được truy cập bởi HR với một số HPR cụ thể.

Đăng ký các files vào AWS Glue Data Catalog sử dụng các bộ thu thập (crawlers)

Hướng dẫn sau đây minh họa cách đăng ký các files đã tải xuống vào AWS Glue Data Catalog bằng cách sử dụng crawlers. Chúng ta sẽ tổ chức các file vào cơ sở dữ liệu (database) và bảng (table) sử dụng AWS Glue Data Catalog, theo các bước sau đây. Bạn nên xem lại tài liệu để tìm hiểu cách thiết lập AWS Glue Database đúng cách. Crawlers có thể tự động hóa quá trình đăng ký các files đã tải xuống của chúng ta vào danh mục (catalog) thay vì thực hiện thủ công. Bạn sẽ tạo các database sau trong AWS Glue Data Catalog:

lobrisk
lobmarket
hr

Các bước ví dụ để tạo AWS Glue database cho dữ liệu lobrisk như sau:

Truy cập AWS Glue Console.
Tiếp thep, chọn Databases trong Data Catalog.
Chọn Add database và nhập tên databases là lobrisk.
Chọn Create database, như ảnh sau.

Thực hiện các bước tương tự để tạo các database khác như lobmarket và hr.

AWS Glue Crawler sẽ quét các files trên và lập danh mục metadata (catalogs metadata) của chúng vào AWS Glue Data Catalog. Glue Data Catalog tổ chức dữ liệu trong S3 này thành các bảng (table) và cơ sở dữ liệu (database), gán các cột (column) và loại dữ liệu (datatype) để có thể truy vấn dữ liệu bằng cách sử dụng SQL mà Amazon Redshift Spectrum có thể hiểu được. Vui lòng xem AWS Glue documentation về cách tạo Glue Crawler. Sau khi Glue Crawler thực thi xong, bạn sẽ thấy database và table tương ứng sau:

lobrisk
- lob_risk_high_confidential_public
- lob_risk_high_confidential
lobmarket
- credit_card_transaction_pci
- credit_card_transaction_pci_public
hr
- customers_pii_hpr_public
- customers_pii_hpr

Các bước ví dụ để tạo AWS Glue Crawler cho dữ liệu lobrisk như sau:

Chọn Crawlers dưới mục Data Catalog trong AWS Glue Console.
Tiếp theo, chọn Create crawler. Điền tên crawler là lobrisk_crawler và chọn Next.

Đảm bảo đã chọn data source là Amazon S3 và duyệt đường dẫn Amazon S3 đến thư mục lob_risk_high_confidential_public rồi chọn nguồn dữ liệu Amazon S3.

Crawlers có thể thu thập nhiều folders trong Amazon S3. Chọn Add a data source và đảm bảo đã gồm đường dẫn S3://<<Your Bucket >>/ lob_risk_high_confidential.

Sau khi thêm Amazon S3 folder khác, chọn Next.

Tiếp theo, tạo IAM role mới trong Configuration security settings.
Chọn Next.

Chọn Target database là lobrisk. Chọn Next.

Tiếp theo, bên dưới Review, chọn Create crawler.
Chọn Run Crawler. Việc này sẽ tạo ra 2 bảng: lob_risk_high_confidential_public và lob_risk_high_confidential trong database lobrisk.

Tương tự, thực hiện tạo AWS Glue crawler cho dữ liệu lobmarket và hr.

Tạo AWS IAM roles

Sử dụng AWS IAM, tạo các IAM roles sau cung cấp quyền với Amazon Redshift, Amazon S3, AWS Glue, và AWS Lake Formation.

Bạn có thể tạo AWS IAM roles. Sau, bạn có thể đính kèm chính sách (policy) được quản lý vào IAM roles:

iam_redshift_pcipii (AWS IAM role gắn vào Amazon Redshift cluster)
- AmazonRedshiftFullAccess
- AmazonS3FullAccess
- Thêm inline policy (Lakeformation-inline) cung cấp quyền đối với Lake Formation như sau:

{ “Version”: “2012-10-17”, “Statement”: [ { “Sid”: “RedshiftPolicyForLF”, “Effect”: “Allow”, “Action”: [ “lakeformation:GetDataAccess” ], “Resource”: “*” } ]}

iam_redshift_hpr (AWS IAM role gắn vào Amazon Redshift cluster): Thêm các policy sau:
- AmazonRedshiftFullAccess
- AmazonS3FullAccess
- Thêm inline policy (Lakeformation-inline) đã được tạo ở bước trên.
iam_redshift_public (AWS IAM role gắn vào Amazon Redshift cluster): Thêm các policy sau:
- AmazonRedshiftFullAccess
- AmazonS3FullAccess
- Thêm inline policy (Lakeformation-inline) đã được tạo ở bước trên.
LF_admin (Lake Formation Administrator): Thêm các policy sau:
- AWSLakeFormationDataAdmin
- AWSLakeFormationCrossAccountManager
- AWSGlueConsoleFullAccess

Dùng Lake Formation tag-based access control (LF-TBAC) để kiểm soát truy cập vào AWS Glue data catalog tables.

LF-TBAC là một chiến lược ủy quyền xác định các quyền dựa trên các thuộc tính. Sử dụng LF_admin Lake Formation administrator, bạn có thể tạo LF-tags, như được đề cập trong chi tiết sau:

Key	Value
Classification:HPR	no, yes
Classification:PCI	no, yes
Classification:PII	no, yes
Classifications	non-sensitive, sensitive

Thực hiện theo các hướng dẫn sau để tạo Lake Formation tags:

Truy cập Lake Formation Console (https://console.aws.amazon.com/lakeformation/) sử dụng LF-Admin AWS IAM role.
Truy cập LF-Tags and permissions trong mục Permissions.
Chọn Add LF-Tag.

Tạo các LF-Tags còn lại theo hướng dẫn trong bảng bên trên. Sau khi tạo, bạn sẽ thấy LF-Tags như hiển thị bên dưới.

Gán LF-TAG cho AWS Glue catalog tables

Việc gán Lake Formation tags cho các bảng thường liên quan đến cách tiếp cận có cấu trúc. Quản trị viên Lake Formation có thể gán thẻ dựa trên nhiều tiêu chí khác nhau, chẳng hạn như nguồn dữ liệu, loại dữ liệu, lĩnh vực kinh doanh, chủ sở hữu dữ liệu hoặc chất lượng dữ liệu. Bạn có khả thể phân bổ LF-Tags cho tài nguyên Data Catalog, bao gồm databases, tables và columns, cho phép bạn quản lý quyền truy cập tài nguyên một cách hiệu quả. Quyền truy cập vào các tài nguyên này bị hạn chế đối với những người đã được cấp LF-Tags tương ứng (hoặc những người đã được cấp quyền truy cập thông qua phương pháp tên tài nguyên).

Thực hiện theo hướng dẫn trong link sau để gán LF-TAGS vào Glue Data Catalog Tables:

Glue Catalog Tables	Key	Value
customers_pii_hpr_public	Classification	non-sensitive
customers_pii_hpr	Classification:HPR	yes
credit_card_transaction_pci	Classification:PCI	yes
credit_card_transaction_pci_public	Classifications	non-sensitive
lob_risk_high_confidential_public	Classifications	non-sensitive
lob_risk_high_confidential	Classification:PII	yes

Hãy làm theo hướng dẫn bên dưới để gán LF-Tag cho Glue Tables từAWS Console như sau:

Để truy cập databases trong Lake Formation Console, đi tới phần Data catalog và chọn Databases.
Chọn database lobrisk và chọn View Tables.
Chọn table lob_risk_high_confidential và chọn Edit LF-Tags.
Chỉ định Classification:HPR là Assigned Keys và Values là Yes. Chọn Save.

Tương tự, chỉ định Key là Classification và Value là non-sensitive cho lob_risk_high_confidential_public table.

Làm theo hướng dẫn ở trên để thực hiện gán tag cho các bảng còn lại cho database lobmarket và hr.

Cấp quyền cho các tài nguyên bằng cách sử dụng biểu thức cấp quyền LF-Tag LF-Tag expression cho các IAM Roles của Redshift

Cấp quyền select, describe Lake Formation cho LF-Tags và Redshift IAM role bằng cách sử dụng Lake Formation Administrator trong Lake Formation console. Để cấp quyền, vui lòng làm documentation.

Sử dụng bảng sau để gán IAM role tương ứng cho LF-tags:

IAM role	LF-Tags Key	LF-Tags Value	Permission
iam_redshift_pcipii	Classification:PII	yes	Describe, Select
.	Classification:PCI	yes	.
iam_redshift_hpr	Classification:HPR	yes	Describe, Select
iam_redshift_public	Classifications	non-sensitive	Describe, Select

Hãy làm theo hướng dẫn bên dưới để cấp quyền cho LF-tags và IAM roles:

Chọn Data lake permissions trong phần Permissions tại AWS Lake Formation Console.
Chọn Grants. Chọn IAM users and roles tại mục Principals.
Tại phần LF-tags or catalog resources chọn Key là Classifications và values là non-sensitive.

Tiếp theo, tại Table permissions chọn Select & Describe. Chọn grants.

Thực hiện theo hướng dẫn bên trên đối với các LF-Tags và IAM role còn lại như thông tin trong bảng bên trên.

Ánh xạ các nhóm người dùng IdP tới các Redshift roles

Trong Redshift, sử dụng Native IdP federation để ánh xạ các IdP user groups tới các Redshift roles. Sử dụng Query Editor V2.

create role aad:rs_lobrisk_pci_role;create role aad:rs_lobrisk_public_role;create role aad:rs_hr_hpr_role;create role aad:rs_hr_public_role;create role aad:rs_lobmarket_pci_role;create role aad:rs_lobmarket_public_role;

Tạo External schemas

Trong Redshift, tạo các External schema sử dụng AWS IAM roles và dùng AWS Glue Catalog databases. Các External schema được tạo theo phân loại dữ liệu bằng iam_role.

create external schema external_lobrisk_pcifrom data catalogdatabase ‘lobrisk’iam_role ‘arn:aws:iam::571750435036:role/iam_redshift_pcipii’;
create external schema external_hr_hprfrom data catalogdatabase ‘hr’iam_role ‘arn:aws:iam::571750435036:role/iam_redshift_hpr’;
create external schema external_lobmarket_pcifrom data catalogdatabase ‘lobmarket’iam_role ‘arn:aws:iam::571750435036:role/iam_redshift_pcipii’;
create external schema external_lobrisk_publicfrom data catalogdatabase ‘lobrisk’iam_role ‘arn:aws:iam::571750435036:role/iam_redshift_public’;
create external schema external_hr_publicfrom data catalogdatabase ‘hr’iam_role ‘arn:aws:iam::571750435036:role/iam_redshift_public’;
create external schema external_lobmarket_publicfrom data catalogdatabase ‘lobmarket’iam_role ‘arn:aws:iam::571750435036:role/iam_redshift_public’;

Xác thực danh sách các table

Xác thực danh sách các table trong mỗi external schema. Mỗi schema chỉ liệt kê những table mà Lake Formation đã cấp quyền cho IAM_ROLES được sử dụng để tạo external schema. Dưới đây là danh sách các table trả ra của Redshift query edit v2 hiển thị ở phía bên trái.

Cấp quyền sử dụng trên các external schemas cho các Roles cục bộ Redshift khác nhau

Trong Redshift, cấp quyền sử dụng trên các external schemas cho các Roles cục bộ Redshift khác nhau như sau:

grant usage on schema external_lobrisk_pci to role aad:rs_lobrisk_pci_role;grant usage on schema external_lobrisk_public to role aad:rs_lobrisk_public_role;
grant usage on schema external_lobmarket_pci to role aad:rs_lobmarket_pci_role;grant usage on schema external_lobmarket_public to role aad:rs_lobmarket_public_role;
grant usage on schema external_hr_hpr_pci to role aad:rs_hr_hpr_role;grant usage on schema external_hr_public to role aad:rs_hr_public_role;

Xác minh quyền truy cập vào external schema

Xác minh quyền truy cập vào external schema bằng cách sử dụng người dùng từ nhóm Lob Risk. User lobrisk_pci_user được liên kết với role cục bộ Amazon Redshift rs_lobrisk_pci_role. Role rs_lobrisk_pci_role chỉ có quyền được truy cập vào external schema external_lobrisk_pci.

set session_authorization to creditrisk_pci_user;select * from external_lobrisk_pci.lob_risk_high_confidential limit 10;

Trên bảng truy vấn từ schema external_lobmarket_pci, bạn sẽ thấy bạn bị từ chối.

set session_authorization to lobrisk_pci_user;select * from external_lobmarket_hpr.lob_card_transaction_pci;

Cung cấp quyền truy cập tự động của BMO

Chúng tôi đã phát triển một khung (framework) cấp quyền truy cập cùng với ngân hàng, cho phép họ tạo một kho dữ liệu trung tâm về người dùng và dữ liệu họ có quyền truy cập. Tệp chính sách được lưu trữ trong Amazon S3. Khi tệp được cập nhật, nó sẽ được xử lý và thông điệp sẽ được đặt trong Amazon SQS. AWS Lambda sử dụng Data API để áp dụng kiểm soát truy cập cho các vai trò trong Amazon Redshift. Đồng thời, AWS Lambda cũng được sử dụng để tự động hóa kiểm soát truy cập dựa trên thẻ trong AWS Lake Formation.

Làm việc với ngân hàng, chúng tôi đã phát triển một framework cung cấp quyền truy cập cho phép ngân hàng tạo kho dữ liệu trung tâm về người dùng và dữ liệu họ có quyền truy cập. File chính sách (policy file) được lưu trữ trong Amazon S3. Khi file được cập nhật, nó sẽ được xử lý, và thông diệp sẽ được lưu trong Amazon SQS. AWS Lambda sử dụng Data API để áp dụng kiểm soát truy cập cho các role trong Amazon Redshift. Đồng thời, AWS Lambda cũng được sử dụng để tự động hóa việc kiểm soát quyền truy cập dựa trên tags trong AWS Lake Formation.

Lợi ích của việc áp dụng mô hình này là:

Đã tạo một quy trình tự động mở rộng (scale) để cho phép áp dụng linh hoạt các chính sách (policy) thay đổi.
Đơn giản hóa quy trình tiếp nhận và xử lý truy cập người dùng thông qua hệ thống quản lý quyền truy cập doanh nghiệp hiện có.
Trao quyền cho từng lĩnh vực kinh doanh để hạn chế quyền truy cập vào dữ liệu nhạy cảm mà họ sở hữu và bảo vệ dữ liệu cũng như quyền riêng tư của khách hàng ở cấp doanh nghiệp.
Đơn giản hóa việc quản lý và bảo trì AWS IAM role bằng cách giảm đáng kể số lượng các role cần thiết.

Với việc ra mắt tính năng tích hợp Amazon Redshift với AWS Identity Center gần đây, việc mở rộng quyền định danh giữa các dịch vụ AWS có thể được tận dụng để đơn giản hóa và mở rộng phạm vi triển khai này (implementation).

Tổng kết

Trong bài post này, chúng tôi đã hướng dẫn bạn cách triển khai các biện pháp kiểm soát truy cập mạnh mẽ cho dữ liệu khách hàng nhạy cảm trong Amazon Redshift, việc này trở nên thách thức khi cố gắng xác định nhiều AWS IAM role khác nhau. Giải pháp được trình bày trong bài post này minh họa cách các tổ chức có thể đáp ứng nhu cầu tuân thủ và bảo mật dữ liệu bằng cách tiếp cận tổng hợp—sử dụng một nhóm AWS IAM role tối thiểu được tổ chức theo phân loại dữ liệu thay vì theo ngành nghề kinh doanh.

Bằng cách sử dụng tính năng Amazon Redshift’s native integration với External IdP và xác định chính sách RBAC trong cả Redshift và AWS Lake Formation, bạn có thể áp dụng các biện pháp kiểm soát truy cập chi tiết mà không tạo ra quá nhiều role riêng biệt. Điều này mang lại lợi ích cho việc truy cập dựa trên role trong khi giảm thiểu chi phí quản trị.

Các tổ chức dịch vụ tài chính khác đang tìm cách bảo mật dữ liệu khách hàng và quân thủ quy định có thể áp dụng cách tiếp cận RBAC tập trung tương tự. Việc xác định chính sách (policy) cẩn thận, căn cứ vào độ nhạy cảm của dữ liệu hơn là chức năng kinh doanh, có thể giúp giảm sự tăng nhanh của các AWS IAM role. Mô hình này cân bằng giữa tính bảo mật, tuân thủ và khả năng quản lý để quản trị dữ liệu nhạy cảm trong Amazon Redshift và các nền tảng dữ liệu đám mây rộng hơn.

Nói tóm lại, mô hình RBAC tập trung dựa trên phân loại dữ liệu giúp đơn giản hóa việc quản lý trong khi vẫn cung cấp tính tuân thủ và bảo mật dữ liệu mạnh mẽ. Cách tiếp cận này có thể mang lại lợi ích cho bất kỳ tổ chức nào quản lý thông tin khách hàng nhạy cảm trên cloud.

Về tác giả

Link blog tiếng Anh:
https://aws.amazon.com/blogs/big-data/how-bmo-improved-data-security-with-amazon-redshift-and-aws-lake-formation/

	Amy Tseng is a Managing Director of Data and Analytics(DnA) Integration at BMO. She is one of the AWS Data Hero. She has over 7 years of experiences in Data and Analytics Cloud migrations in AWS. Outside of work, Amy loves traveling and hiking.
	Jack Lin is a Director of Engineering on the Data Platform at BMO. He has over 20 years of experience working in platform engineering and software engineering. Outside of work, Jack loves playing soccer, watching football games and traveling.
	Regis Chow is a Director of DnA Integration at BMO. He has over 5 years of experience working in the cloud and enjoys solving problems through innovation in AWS. Outside of work, Regis loves all things outdoors, he is especially passionate about golf and lawn care.
	Nishchai JM is an Analytics Specialist Solutions Architect at Amazon Web services. He specializes in building Big-data applications and help customer to modernize their applications on Cloud. He thinks Data is new oil and spends most of his time in deriving insights out of the Data.
	Harshida Patel is a Principal Solutions Architect, Analytics with AWS.
	Raghu Kuppala is an Analytics Specialist Solutions Architect experienced working in the databases, data warehousing, and analytics space. Outside of work, he enjoys trying different cuisines and spending time with his family and friends.

AWS Study Group

AWS Big Data Blog

Trường hợp sử dụng