Sơ lược về S3
1. Tại sao lại chọn lưu trữ trên cloud?
Di chuyển các workload lên cloud là một trong số những cách mà các doanh nghiệp có thể giải quyết các ưu tiên chiến lược hàng đầu của họ:
Tăng tính agile cho tổ chức
Tăng tốc chuyển đổi và sáng tạo
Tăng cường security: Khi lên Cloud, các vấn đề liên quan đến bảo vệ server, các thiết bị lưu trữ khỏi các tấn công hay tổn thất vật lý sẽ do AWS đảm nhận. Bảo mật sẽ không chỉ đơn giản là dựa vào mức độ bảo mật cơ sở của người dùng, mà sẽ còn có sự đóng góp của AWS.
Giảm chi phí: AWS lo các bảo vệ, duy trì hạ tầng vật lý -> Người dùng không phải tự làm -> Giảm các chi phí liên quan đến đầu tư hạ tầng, liên quan đến nhân công
So sánh về chi phí khi lưu trữ dưới on prems và trên cloud:
\=> Do các lợi thế mà cloud đem lại, ngày càng nhiều các doanh nghiệp lớn sử dụng storage cloud như backup hoặc thay thế hẳn các lưu trữ on – premises
2. Các loại lưu trữ chính:
Có 2 loại lưu trữ chính: Block, File và object storage
Block storage:
Lưu trữ thông tin dưới dạng khối, là cấp thấp nhất trong các loại lưu trữ, trong đó thiết bị lưu trữ phần cứng là ổ đĩa hoặc volume dudơcj format và gắn vào hệ thống điện toán để sử dụng. Bộ nhớ được chia thành các segments liên tục trên các thiết bị lưu trữ. Các segments này được gọi là block.
Thiết bị lưu trữ có thể là ổ đĩa cứng (HDD), solid state drives (SSD) hoặc các loại lưu trữ mới hơn, ví dụ như Non-Volatile Memory Express (NVMe)
Protocol thường dùng: iSCSI or Fiber Optic
Đặc trưng:
– Data chia thành các block, khi cần update dữ liệu, update các block. Vì đặc điểm này nên các hoạt động I/O cho performance tốt hơn
– Dữ liệu không phân cấp, các file sẽ được lưu trữ theo dạng blockId -> block.
Nhắc đến block storage trên AWS, ta có thể nhớ ngay đến 1 dịch vụ quen thuộc là EBS.
File Storage
File storage được xây dựng dựa trên block storage, thường đóng vai trò là file server hoặc file share. Thiết bị lưu trữ được sử dụng bởi hệ điều hành hoặc ứng dụng có khả năng quản lý lưu trữ khối trực tiếp. Đối với các trường hợp ứng dụng quản lý lưu trữ khối, ứng dụng thường chia sẻ quyền quản lý với một hệ điều hành.
Hai giao thức lưu trữ phổ biến nhất để lưu trữ tệp là SMB (Sử dụng cho Windows) và NFS (sử dụng cho Linux).
Nhắc đến file storage trên AWS, chúng ta có thể nhớ ngay đến 2 dịch vụ tiêu biểu là EFS và FSx.
Do File storage cũng dựa trên block storage, nên Block Storage và File Storage không phải là 2 loại Storage khác biệt, mà là các cấp độ lưu trữ khác nhau.
Object storage
Object storage cũng được xây dựng dựa trên block storage. Object storage xuất phát từ mục đích sử dụng chính là lưu trữ dữ liệu trong một đối tượng nhị phân. Không giống như lưu trữ file, lưu trữ object không phân biệt giữa các loại dữ liệu. Loại dữ liệu hoặc loại tệp trở thành một phần của metadata của dữ liệu.
Định danh của object storage là object ID. Các thông tin như content-type, permision,… được gọi là metadata.
Giao thức thường sử dụng là HTTP.
Thông thường dữ liệu object storage sẽ được lưu trữ phân tán. Muốn update dữ liệu, chúng ta không thể cứ thế navigate vào phần update mà update, ví dụ điển hình cho object storage là Amazon S3. Muốn thay đổi nội dung file, chúng ta cần phải tải về, thay đổi rồi ghi lên phiên bản mới của object. Do đó, object storage là loại lưu trữ tốt nhất cho các file static, ít thay đổi. Tuy nhiên vì tính linh hoạt mà object storage đang dần trở thành một trong những kiểu lưu trữ phổ biến nhất ở môi trường cloud computing hay cho các ứng dụng cloud native.
Tóm tắt:
| Block Storage | Object Storage | |
| Ưu điểm | •Tốc độ truy xuất I/O cao, update nhanh do chỉ cập nhật từng Block | •Khả năng lưu trữ không giới hạn |
| •Giao thức Http, giúp cho việc flexible access mọi nơi | ||
| Nhược điểm | •Trả phí cho tất cả không gian lưu trữ dù không sử dụng | |
| •Phải được gán với 1 máy chủ đang chạy | ||
| •Hạn chế về giới hạn lưu trữ | •Tốc độ truy xuất I/O và update không thể bằng Block Storage. | |
| Usecase | •OS | |
| •Database | •Lưu các file chỉ upload 1 lần, sử dụng nhiều lần như (Video, Image) |
3. Amazon S3 tổng quan
S3 là dịch vụ storage serverless (serverless: Người dùng không cần manage hay provision bất cứ server nào, công việc này sẽ do AWS lo) cung cấp khả năng mở rộng, tính sẵn có của dữ liệu, bảo mật và hiệu suất hàng đầu trong ngành. Các trường hợp sử dụng S3 bao gồm:
Data lake
Trang web
Sao lưu dữ liệu
Lưu trữ dữ liệu
IoT
…
Amazon S3 có giao diện dịch vụ web đơn giản mà bạn có thể sử dụng để lưu trữ và truy xuất bất kỳ lượng dữ liệu nào từ bất kỳ đâu trên web. Amazon S3 sử dụng các API REST dựa trên tiêu chuẩn được thiết kế để hoạt động với mọi bộ công cụ phát triển internet.
Chúng ta có thể lưu trữ không giới hạn trên S3, việc sử dụng S3 đơn giản, không cần cài thêm bất cứ thành phần nào để có thể sử dụng S3.
Dữ liệu S3 có cấu trúc phẳng, không có khái niệm file hay folder đối với S3, chỉ có object, và prefix.
Các tên của bucket phải là global unique
Chi phí được tính dựa trên nhu cầu lưu trữ và lưu lượng truy xuất.
Là dịch vụ regional, mặc dù màn hình quản lý S3 bucket là global, nhưng bản thân các bucket lại là regional. Khi chúng ta thiết kế và lựa chọn region cho bucket, thì cần lựa chọn region phù hợp, thông thường sẽ là cùng region với các dịch vụ/app cần truy cập đến dữ liệu trong S3 bucket.
Durability: 99.999999999%, Availability: 99.99% -> Những con số này sẽ còn có thể tăng lên theo thời gian, khi công nghệ được optimize hơn (Một lưu ý nhỏ, các dịch vụ của aws chúng ta sẽ thường thấy rất nhiều số 9, chỉ có duy nhất Route 53 là dịch vụ cam kết SLA là 100%, ngoài ra SLA sẽ thường không để 100%)
Tuy là có thể lưu trữ không giới hạn, nhưng vẫn có giới hạn là 5TB cho size của 1 object
Dung lượng tối đa mỗi lần upload là 5GB, nếu vượt quá 5GB sẽ cần bật multipart upload (multipart upload: Multipart upload cho phép upload một object thành từng part. Có thể upload các part một cách độc lập hoặc theo bất kỳ thứ tự nào. Nếu bất kỳ part nào khi upload bị thất bại, có thể upload lại part đó mà không ảnh hưởng đến các part khác. Sau khi tất cả các part của object được upload, AWS sẽ ghép chúng thành object hoàn chỉnh. Khi kích thước object của đạt đến 100MB, nên cân nhắc sử dụng multipart upload thay vì upload cả object trong một thao tác.Khi hoàn tất quá trình multipart upload, Amazon S3 sẽ tạo một object bằng cách nối các part theo thứ tự tăng dần dựa trên STT part.)
Thông thường, dữ liệu trong S3 bucket sẽ được lưu trữ trên tối thiểu 3 AZ, nên đảm bảo được tính HA
Convention cho tên bucket:
– không viết hoa,
– không gạch dưới
– gồm 2-63 ký tự
– không phải là IP hoặc giống với syntax IP
– bắt đầu bằng chữ thường hoặc số
Chi tiết hơn: https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html
Không tạo được bucket do tên có syntax giống IP address:
Không tạo được bucket vì đã có bucket trùng:
Vì bucket trùng tên sẽ không thể tạo được => Khi làm việc trong các dự án, nhất là các dự án outsource, chúng ta không nên lấy tên bucket khách hàng đã define sẵn trong file thiết kế để đặt cho các resource testing. Nếu bạn làm vậy, hãy tưởng tượng điều gì xảy ra khi khách hàng không thể tạo được bucket có tên như đã thiết kế vì bạn quên không xóa bucket testing?
Toàn bộ đường dẫn trỏ đến 1 object sẽ được gọi là key (xem ảnh trên).
Trong ảnh trên, my_folder1 và another_folder được gọi là các prefix.
Khi tạo các object, chúng ta nên thực hiện gắn các thông tin metadata, và tags để phục vụ cho các tác vụ sau này.
Tips: Bạn có thể tạo resource group ở service Tag Editor để quản lý resource tốt hơn
Một số ví dụ về tác dụng của tags:
https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-tagging.html
https://catalog.workshops.aws/applying-abac/en-US/module1/04tag33object
4. S3 Storage classes
S3 Standard dành cho mục đích chung lưu trữ dữ liệu được truy cập thường xuyên
S3 Standard-Infrequent Access (S3 Standard-IA) dành cho dữ liệu ít truy cập thường xuyên hơn
S3 One Zone-Infrequent Access (S3 One Zone-IA) dành cho dữ liệu ít truy cập thường xuyên hơn và yêu cầu về tính khả dụng thấp hơn (do chỉ lưu trữ 1 zone, chứ không phải 3 zone như standard, nên đồng nghĩa nếu có vấn đề với zone bạn lưu trữ, thì dữ liệu có thể bị thất thoát hoặc mất tính khả dụng)
S3 Intelligent-Tiering cho dữ liệu có mẫu truy cập không xác định hoặc đang thay đổi. Khi dùng class này, S3 sẽ tự động detect các pattern tương tác với object và chuyển object vào các type phù hợp. VD: Sau 30 ngày kể từ ngày được lưu trữ, mà object không được access, sẽ tự động chuyển object sang các IA classes.
Amazon S3 Glacier Instant Retrieval: để lưu trữ các dữ liệu với chi phí thấp hơn có thể yêu cầu truy xuất bất kỳ lúc nào.
Amazon S3 Glacier Flexible Retrieval dành cho kho lưu trữ chi phí thấp với thời gian truy xuất từ vài phút đến vài giờ.
Amazon S3 Glacier Deep Archive (S3 Glacier Deep Archive) cho dung lượng lưu trữ có chi phí thấp nhất với thời gian truy xuất lên tới 12 giờ.
Amazon S3 trên Outposts dành cho lưu trữ dữ liệu kết hợp tại on-prem khi dùng chạy các workload hybrid. (Outposts: https://aws.amazon.com/outposts/)
5. Giá của S3
Có 6 loại giá: storage pricing, request and data retrieval pricing, data transfer and transfer acceleration pricing, data management and analytics pricing, replication pricing, và giá cho xử lý dữ liệu bằng S3 Object Lambda.
Chi tiết: https://aws.amazon.com/s3/pricing/
Nếu bạn muốn dự trù chi phí cho S3, bạn có thể sử dụng công cụ AWS Pricing caculator:
Hoặc sử dụng các công cụ tích hợp với tool infrastructure as code như là InfraCost.
6. S3 Consistency model
Sau khi ghi thành công đối tượng mới hoặc ghi đè hoặc xóa đối tượng hiện có, mọi yêu cầu đọc tiếp theo sẽ ngay lập tức nhận được phiên bản mới nhất của đối tượng. -> AWS S3 support strong consistency model.
Có 2 loại consistency model trong lưu trữ dữ liệu phân tán:
Eventual consistency:
Và strong consistency:
Strong Consistency cho phép dữ liệu luôn nhất quán và được cập nhật mới nhất, nhưng nó có độ trễ cao.
Eventual Consistency thì có độ trễ thấp, kết quả trả về nhanh nhưng dữ liệu nhận được có thể không phải mới nhất.
7. S3 batch operation
Bạn có thể sử dụng S3 Batch operation để thực hiện các thao tác hàng loạt quy mô lớn trên các đối tượng Amazon S3.
Bạn có thể sử dụng S3 Batch Operations thông qua Bảng điều khiển quản lý AWS, AWS CLI, Amazon SDK hoặc API REST.
Sử dụng S3 Batch Operations để sao chép object và đặt tag cho object hoặc danh sách kiểm soát truy cập (ACL). Bạn cũng có thể bắt đầu khôi phục đối tượng từ S3 Glacier Flexible Retrieval hoặc gọi một hàm AWS Lambda để thực hiện các hành động tùy chỉnh. Amazon S3 Batch Operations sử dụng cùng các API Amazon S3 mà bạn đã sử dụng với Amazon S3.
Một số từ khóa:
Job: là đơn vị công việc cơ bản cho S3 Batch Operations. Một job chứa tất cả thông tin cần thiết để chạy thao tác đã chỉ định trên các object được liệt kê trong manifest.
Operation: là hành API action, ví dụ như copy các object.
Task: đơn vị thực hiện cho một job. Một task đại diện cho một lệnh gọi đến thao tác API Amazon S3 hoặc AWS Lambda để thực hiện thao tác trên 1 object. Trong suốt vòng đời của một job, A3 Batch Operation tạo một task cho mỗi object được chỉ định trong file manifest.
Link tham khảo: https://docs.aws.amazon.com/AmazonS3/latest/userguide/batch-ops.html
8. S3 security
Shared responsibility model
Khi nhắc đến các vấn đề liên quan security, chúng ta sẽ cần hiểu được mô hình chia sẻ trách nhiệm. Mô hình này sẽ thể hiện các phần việc AWS sẽ đảm nhận và các phần việc mà người dùng phải tự làm, tự quản lý. Nắm được mô hình chia sẻ trách nhiệm, sẽ giúp người dùng đưa ra các action liên quan đến bảo mật chính xác hơn, tốt hơn.
AWS sẽ đảm nhận “Security of the cloud”, tức là các vấn đề liên quan đến hạ tầng bên dưới DC của AWS để chạy các dịch vụ.
Người dùng sẽ đảm nhận “Security in the cloud”, tức là các vấn đề liên quan đến mã hóa dữ liệu, chia sẻ public hay giữ private,… là thuộc trách nhiệm của người dùng.
Do đó, chúng ta cần tránh hiểu nhầm rằng: Dữ liệu lên cloud sẽ mặc định là được bảo mật, bất chấp người dùng có dùng như nào. Chúng ta – đứng ở vị thế người dùng, sẽ cần lên các phương án bảo vệ dữ liệu hợp lý để giảm thiểu rủi ro từ các vấn đề security.
Security in Amazon S3:
Block public access:
Chặn quyền truy cập công khai sẽ ghi đè các quyền truy cập S3 khác để dễ dàng thực thi chính sách cấm truy cập công khai. Bằng cách sử dụng Block public acces, quản trị viên tài khoản và chủ sở hữu bucket có thể dễ dàng thiết lập các biện pháp kiểm soát tập trung để hạn chế quyền truy cập công khai vào các tài nguyên Amazon S3 của họ. Tính năng này được bật mặc định.
IAM:
Amazon S3 cung cấp cả chính sách truy cập dựa trên tài nguyên (resource – based access policies) và dựa trên người dùng (identity – based policies). Access policies là một tập hợp các quyền được đính kèm với tài nguyên của bạn (buckets) hoặc với người dùng của bạn. Bằng cách sử dụng các policy, bạn có thể quản lý quyền truy cập vào tài nguyên. Bucket policy là AWS Identity and Access Management (IAM) resource – based policy. Để cấp cho các tài khoản AWS khác hoặc người dùng IAM quyền truy cập vào bucket và các object trong đó, bạn có thể thêm bucket policy cho S3 bucket.
Access point:
Access point đơn giản hóa việc quản lý quyền truy cập dữ liệu trên quy mô lớn cho các ứng dụng sử dụng bộ dữ liệu dùng chung trên Amazon S3. Access point là các named network endpoints được gắn vào bucket và được sử dụng để thực hiện các thao tác với các object trên Amazon S3, chẳng hạn như GetObject và PutObject. Mỗi accesss point có các quyền và kiểm soát mạng riêng biệt mà S3 áp dụng cho bất kỳ request nào được thực hiện thông qua access point đó.
Presigned URLs:
Với Query String Authentication (presigned URLs), bạn có thể cấp quyền truy cập có giới hạn thời gian cho các đối tượng bằng các URL tạm thời. Bạn có thể sử dụng presigned URLs để chia sẻ đối tượng hoặc cho phép khách hàng/người dùng của mình upload hoặc download object mà không cần có quyền hoặc AWS security credentials.
Các vấn đề liên quan đến presigned URL sẽ được nói chi tiết hơn ở phần 2.
Encryption:
Encryption in transit: VD: Sử dụng giao thức HTTPS để truyền file
Encrypt at rest: Bao gồm việc người dùng sẽ mã hóa dữ liệu dưới local trước khi đưa lên S3 và dữ liệu lưu trữ trên S3 được mã hóa bởi SSE-S3 hoặc SSE- KMS
Trong console của Amazon S3, sẽ có 2 lựa chọn cho bạn: Sử dụng encryption bằng SSE – S3 hay SSE – KMS.
SSE-S3 là cách đơn giản nhất để mã hóa dữ liệu S3 của bạn. SSE – S3 là lựa chọn mặc định. Với phương pháp này, Amazon S3 sẽ tự động quản lý các khóa mã hóa của bạn bằng mã hóa AES-256. SSE-S3 là một tùy chọn tuyệt vời nếu bạn đang tìm kiếm một cách an toàn, dễ sử dụng để mã hóa dữ liệu S3 của mình mà không cần nhiều chi phí quản trị. Bạn không thể nhìn thấy các key được generated bởi S3. Không có role separation và bạn không thể quản lý việc rotation của key. Một ông có quyền admin với S3 sẽ có thể xem được tất cả các dữ liệu trong bucket nếu muốn. Một số tổ chức và công ty có thể yêu cầu quản trị viên không được xem dữ liệu trong S3 bucket (ví dụ trong môi trường bệnh viện với dữ liệu nhạy cảm). Đối với điều này, chúng ta cần một loại khóa khác, đó là SSE – KMS.
Tương tự như S3, AWS quản lý khóa mã hóa cho bộ chứa S3 thông qua AWS Key Management Service (KMS). Khi bạn tải một đối tượng lên S3, bạn có thể chọn KMS key cụ thể mà bạn muốn sử dụng để mã hóa. Quyền xem đối tượng sau đó được nâng cấp lên dịch vụ KMS. Điều này có nghĩa là ngoài quyền với S3, thì bạn cần phải có quyền call API giải mã KMS thì mới có thể xem được dữ liệu trong bucket, khi sử dụng SSE – KMS, bạn cũng sẽ có thể control được quá trình rotate key.
SSE – C cho phép bạn sử dụng các khóa mã hóa của riêng mình, giúp bạn có nhiều quyền kiểm soát hơn đối với tính bảo mật của dữ liệu S3. Với SSE-C, Amazon S3 không lưu trữ hoặc quản lý các khóa mã hóa của bạn, do đó, bạn có trách nhiệm quản lý và bảo vệ chúng. Nếu bạn tải một object lên, bạn sẽ cung cấp cho object cùng với key (key này AWS sẽ loại bỏ và sẽ chỉ giữ lại Hashing version). Bạn sẽ cần cung cấp key mỗi khi bạn tạo request tơi bucket S3 qua HTTPS. Như bạn có thể thấy từ hình ảnh trong bài đăng trên blog này, SSE-C chưa bao giờ được đề cập, nó làm tăng thêm độ phức tạp cho ứng dụng của bạn và mã hóa bằng phương pháp này chỉ có thể được thực hiện được qua API hoặc AWS SDK.
Server-Side Encryption with S3-Managed Keys – SSE-S3: (Source: Oreilly)
Server-Side Encryption with AWS KMS-Managed Keys – SSE-KMS:
VPC endpoints:
VPC endpoint là một thực thể logic trong VPC cho phép kết nối với các dịch vụ AWS như Amazon S3. VPC endpoint định tuyến các request trên mạng Amazon tới S3, sau đó định tuyến các phản hồi trở lại VPC. Vì lưu lượng vẫn nằm trên mạng Amazon nên VPC endpoint cho phép bạn kết nối private với các dịch vụ AWS được hỗ trợ mà không yêu cầu internet gateway, thiết bị NAT, kết nối VPN hoặc kết nối AWS Direct Connect.
Chi tiết hơn về VPC endpoints, sẽ được đề cập trong 1 bài blog khác.
9. Chi tiết hơn về quản lý truy cập tới S3 bằng IAM policy
Access policies
Khi nào thì sử dụng IAM user policy?
Bạn cần quản lý quyền truy cập tới AWS service khác, không chỉ riêng AWS S3. Các chính sách IAM cung cấp khả năng quản lý tập trung hợp lý hơn cho tất cả các quyền của bạn.
Bạn có nhiều bucket Amazon S3, mỗi bucket có các yêu cầu về quyền khác nhau. Ít chính sách IAM hơn sẽ dễ quản lý hơn là phải xác định một số lượng lớn bucket policy cho Amazon S3.
Bạn đơn giản là thích quản lý bằng các policy ngay tại màn hình quản trị IAM luôn
Khi nào thì sử dụng bucket policy?
Bạn cần cấp quyền trên nhiều tài khoản cho các tài khoản AWS khác hoặc người dùng trong tài khoản khác mà không sử dụng IAM role.
IAM policy của bạn đạt đến giới hạn kích thước cho người user, group hoặc role.
Bạn muốn giữ các chính sách kiểm soát truy cập trong môi trường Amazon S3.
Bạn cần đảm bảo kiểm soát quyền truy cập chặt chẽ đối với dữ liệu nhạy cảm được lưu trữ trong một nhóm cụ thể và không muốn quyền truy cập vô tình được cấp cho người dùng trái phép thông qua IAM policy.
Access control list (ACL)
Bạn có thể sử dụng ACL để quản lý quyền truy cập vào bucket và object. Mỗi bucket và object có một ACL được đính kèm với nó dưới dạng subresource. ACL xác định tài khoản hoặc nhóm AWS nào được cấp quyền truy cập và loại quyền truy cập. Khi nhận được một request đối với một tài nguyên, Amazon S3 sẽ kiểm tra ACL tương ứng để xác minh rằng người request có các quyền truy cập cần thiết. Khi bạn tạo một bucket hoặc một object, Amazon S3 sẽ tạo một ACL mặc định cấp cho chủ sở hữu tài nguyên toàn quyền kiểm soát tài nguyên.
Để truy cập cross – account, bạn có thể sử dụng ACL để kiểm soát principals nào trong tài khoản khác có thể truy cập tài nguyên. Bạn không thể sử dụng ACL để kiểm soát quyền truy cập đối với principal trong cùng một tài khoản. ACL tương tự như các resource-based policies, mặc dù chúng là loại policy duy nhất không sử dụng định dạng JSON. Amazon S3, AWS WAF và Amazon VPC là những ví dụ về dịch vụ hỗ trợ ACL.
Lưu ý: Bạn chỉ có thể configure ACL khi bạn bật ACL ở section Bucket ownership.
10. Accesss policy evaluation logic
1) User context
Link: docs.aws.amazon.com/IAM/latest/UserGuide/re..
2) Bucket context:
3) Object context:
Demo của mình về policy evaluation logic, bạn có thể xem thêm tại đây:
11. S3 object ownership
Object writer – Tài khoản ghi object sở hữu object.
Bucket owner preferred – Chủ sở hữu bucket sở hữu đối tượng nếu đối tượng được tải lên với ACL enforce ownership cho chủ sở hữu bucket. Chủ sở hữu bucket lúc này có toàn quyền kiểm soát. Nếu không có cài đặt này và ACL enforce ownership, object ownership vẫn thuộc về tài khoản đã ghi object vào bucket. Điều này có nghĩa là chủ sở hữu chưa chắc đã có quyền sử dụng object. Hiện tại object được AWS recommend disable ACL và enforce quyền sở hữu cho chủ bucket, để tránh các lỗi access denied sau này khi bạn tạo presigned url, hoặc dùng với AWS CloudFront distribution,..
12. S3 CORS
https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html
CORS là một cơ chế cho phép nhiều tài nguyên khác nhau (fonts, Javascript, v.v…) của một trang web có thể được truy vấn từ domain khác với domain của trang đó. CORS là viết tắt của từ Cross-origin resource sharing.
Nếu không setting CORS, thì sẽ thường gặp lỗi “no ‘access-control-allow-origin’ header is present on the requested resource”
CORS được sinh ra là vì same-origin policy (https://www.w3.org/Security/wiki/Same_Origin_Policy), là một chính sách liên quan đến bảo mật được cài đặt vào toàn bộ các trình duyệt hiện nay. Chính sách này ngăn chặn việc truy cập tài nguyên của các domain khác một cách vô tội vạ.
Nói đơn giản thì trình duyệt sẽ so sánh origin (https://datatracker.ietf.org/doc/html/rfc6454): domain sẽ phải giống nhau từ đầu tới cuối từ protocol đến host, port.
Ta có kịch bản như sau:
Bạn truy cập một trang web có mã độc. Trang web đó sử dụng Javascript để truy cập tin nhắn Facebook của bạn ở địa chỉ
https://facebook.com/messages.Nếu bạn đã đăng nhập Facebook từ trước rồi. Nếu không có same-origin policy, trang web độc hại kia có thể thoải mái lấy dữ liệu của bạn và bất cứ điều gì chúng muốn.
Same-origin policy chính là để ngăn chặn những kịch bản như trên để bảo vệ người dùng, giúp an toàn hơn khi lướt web. Bạn có thể thử trên web console và sẽ nhận được lỗi ngay:
$.get('https://facebook.com/messages')
Access to XMLHttpRequest at 'https://facebook.com/messages' from
origin 'xxx' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested
resource.
Truy cập URL trên từ bất kỳ domain nào ngoài facebook.com bạn cũng sẽ nhận được lỗi như vậy. Đó chính là nhờ same-origin policy.
Thế nhưng trong thế giới web, lập trình viên thường xuyên phải thực hiện truy vấn đến các domain khác, đặc biệt là khi làm việc với các API.
Đó là lúc chúng ta cần đến CORS. CORS sử dụng các HTTP header để “thông báo” cho trình duyệt rằng, một ứng dụng web chạy ở origin này (thường là domain này) có thể truy cập được các tài nguyên ở origin khác (domain khác).
Một ứng dụng web sẽ thực hiện truy vấn HTTP cross-origin nếu nó yêu cầu đến các tài nguyên ở origin khác với origin nó đang chạy (khác giao thức, domain, port). Sự khác biệt về giao thức ở đây là khác biệt kiểu như HTTP với FTP chứ không phải HTTP và HTTPS (dù nhiều trình duyệt không cho phép trộn lẫn các tài nguyên truy cập bằng HTTP và HTTPS nhưng đó là vấn đề khác, không liên quan đến CORS).
Các trường hợp cần đến CORS rất phổ biến trong thực tế. Một ví dụ rất điển hình như sau: một ứng dụng web chạy ở domain foo.com và nó cần truy vấn đến bar.com để lấy một vài dữ liệu (thường được thực hiện bởi JavaScript bằng cách sử dụng XMLHttpRequest). Use case dễ hình dung nhất là bạn sử dụng bucket a-example host một S3 static website, nhưng bạn sẽ cần hiển thị webfont và/hoặc hình ảnh từ một bucket tên là b-example chẳng hạn.
Các trình duyệt đều cài đặt same-origin policy và tuân thủ nó rất chặt chẽ. Cài đặt XMLHttpRequest và kể cả Fetch API cũng đều tuân thủ chính sách này. Do đó những truy vấn như ở trên sẽ không thu được kết quả gì, trừ khi máy chủ trả về response có các header CORS phù hợp.
CORS hoạt động như thế nào?
Khi một trình duyệt thực thi một script chuyển đến một tài nguyên trên một domain khác, nó request nội dung trực tiếp từ tên miền thứ hai. Tên miền thứ hai xác định xem có nên phục vụ nội dung hay không bằng cách xác nhận tên miền đầu tiên, đây là một phần của request. Tên miền thứ hai sau đó trả về nội dung hoặc thông báo lỗi trở lại trình duyệt, bỏ qua hoan toàn tên miền đầu tiên.
Quy trình hoạt động của CORS
Bước 1: Một người dùng mở một tài nguyên trên một trang web chuyển đến một tên miền khác. Đây thường là tệp JavaScript, nhưng có thể bao gồm các phông chữ và tài nguyên CSS.
Bước 2: Trình duyệt của người dùng tạo kết nối đến tên miền thứ hai, thêm vào request mot HTTP header “Origin” chứa tên miền đầu tiên.
Bước 3: Tên miền thứ hai trả lời với HTTP header “Access-Control-Allow-Origin” liệt kê các tên miền được phép thực hiện yêu cầu của CORS. Ký tự đại diện (“*”) cho phép tất cả các tên miền thực hiện yêu cầu.
Bước 4: Nếu tên miền đầu tiên được phép thực hiện request, tên miền thứ hai sẽ trả về nội dung được yêu cầu.
Header Access-Control-Allow-Origin được định nghĩa trong cấu hình máy chủ của tên miền thứ hai. Nếu header không chứa ký tự (*) và tên miền đầu tiên không có trong danh sách, trình duyệt sẽ hiển thị thông báo lỗi.
Thông thường các lỗi liên quan đến CORS khi bạn dùng S3 bucket để host static website.
Ví dụ về CORS configuration ở S3:
[
{
"AllowedHeaders": [
"*"
],
"AllowedMethods": [
"PUT",
"POST",
"DELETE"
],
"AllowedOrigins": [
"http://www.example1.com"
],
"ExposeHeaders": []
},
{
"AllowedHeaders": [
"*"
],
"AllowedMethods": [
"PUT",
"POST",
"DELETE"
],
"AllowedOrigins": [
"http://www.example2.com"
],
"ExposeHeaders": []
},
{
"AllowedHeaders": [],
"AllowedMethods": [
"GET"
],
"AllowedOrigins": [
"*"
],
"ExposeHeaders": []
}
]
Chi tiết hơn, bạn xem thêm tại đây: docs.aws.amazon.com/AmazonS3/latest/usergui..
13. Giới thiệu một số tính năng khác của S3:
Bucket versioning
Nếu bạn quen thuộc với các versioning control system như Git hoặc SVN, thì bucket versioning cũng hoạt động tương tự như vậy. Khi bạn bật versioning lên, rồi ghi đè 1 object có trùng tên, S3 sẽ thay thế object cũ bằng object mới, object cũ sẽ chỉ có thể được thấy khi bạn chọn option “Show version” ở tab list object.
Nếu bạn xóa đi, thì object cũng không bị xóa hoàn toàn, mà S3 sẽ đặt đè lên 1 delete marker, bạn vẫn hoàn toàn có thể revert lại version cũ.
Nhược điểm của versioning là vì không xóa hoàn toàn nên sẽ tăng dung lượng lưu trữ. Do đó, với các bucket mà tác vụ đọc ghi nhiều và liên tục, nếu không thực sự cần thiết thì chúng ta sẽ không bật versioning
Versioning một khi đã enable, sẽ không thể disable nữa mà chỉ có thể suspend.
Versioning được bật lên, và các object được upload sau này sẽ có version ID, bạn có thể chỉ định version ID khi gọi API để lấy được đúng version mong muốn. Nhưng các object đã ghi vào bucket trước khi bật versioning sẽ không có version ID, version ID lúc này sẽ hiển thị là “null”.
Intelligent-Tiering Archive configurations:
Đây là nơi bạn configure intelligent tiering cho dữ liệu trong bucket của bạn.
Server access logging
Sẽ có case rằng bạn có 1 bucket chứa dữ liệu nhạy cảm, bạn muốn kiểm soát tất cả các API action liên quan bucket đó, thì bạn có thể sử dụng server access logging. Bạn sẽ ghi lại log API của bucket này vào 1 bucket, để phục vụ mục đích audit về sau.
Event notifications
Bạn sử dụng tính năng này khi bạn muốn trigger hành động nếu có API action với bucket. VD: bạn muốn trigger 1 lambda function cho việc resize ảnh mỗi khi có 1 ảnh được upload vào bucket.
Transfer acceleration:
Tính năng này tận dụng các accelerated endpoint để có thể transfer data nhanh hơn
Object Lock
Khi bạn muốn giữ cho object không thể bị xóa, thậm chí đến cả root user cũng không thể xóa trong một khoảng thời gian thì object lock là giải pháp cho bạn.
Nếu bạn sử dụng Governance mode thì sẽ chỉ có những user có quyền nhất định mới xóa được resource.
Nếu bạn sử dụng compliance mode, thì đến quyền tối cao là root user cũng không thể xóa, mà buộc phải đợi đến khi hết hạn.
Requester pay
Bình thường thì account nào chứa bucket, account đó sẽ bị charge cho các request đến bucket. Nhưng nếu bạn muốn delegate việc trả cho truy cập sang account khác, thì bạn dùng tính năng requester pay.
Có một lưu ý rằng, các request của requester sẽ cần embed giá trị header để thông báo “tôi là requester đây” cho S3 biết, nếu không thì request đó sẽ gặp lỗi Access Denied.
Static website hosting
Bạn dùng tính năng để configure bucket host 1 static website. Sau khi bật tính năng này, S3 sẽ trả cho bạn 1 URL là website endpoint để dùng.
Lifecycle rules
Có 2 loại: expiration – xóa các object sau một khoảng thời gian do bạn quy định
transition – chuyển sang storage class khác sau một khoảng thời gian do bạn quy định
Lưu ý thời gian tối thiểu của lifecycle rule là 1 ngày, nếu bạn cần xóa hay chuyển sang class khác với thời gian ngắn hơn, bạn phải sử dụng giải pháp khác. VD: Lambda function.
Replication rule:
Cài đặt cho hành động replicate dữ liệu từ bucket này sang bucket khác
Access point:
Access point mình đã trình bày bên trên. Ngoài ra còn có Multi-region access point: global endpoint, sử dụng AWS Global Accelerator để route traffic đến bucket gần nhất.
Reinvent năm 2022 có ra đời 1 tính năng mới là Amazon S3 Multi-Region Access Points Failover Controls cho việc testing recovery, DR strategy, nếu bạn quan tâm có thể đọc thêm tại đây: