Khi khái niệm DevOps và Public Cloud đã được áp dụng rộng rãi, các nhóm kỹ thuật ở nhiều công ty đã trở nên nhanh nhẹn và thích ứng hơn bao giờ hết. Tuy nhiên, sự nhanh nhẹn trong thích ứng càng lớn đòi hỏi một vai trò lớn hơn trong bảo mật hoạt động. Do đó, DevSecOps và Cloud Native Security là những chủ đề thiết yếu cần được giải quyết để đảm bảo thuận lợi cho mọi dự án và chủ động trong vấn đề bảo mật.

Bài viết này sẽ đề cập đến một số thực tiễn tốt nhất trong ngành về bảo mật đám mây và đưa ra một số mẹo và thủ thuật mà bạn có thể áp dụng trong các hoạt động hàng ngày. Mặc dù những điều này đều có thể được áp dụng cho bất kỳ nền tảng Public Cloud nào nhưng bài viết sẽ sử dụng AWS làm tài liệu tham khảo do phần lớn các doanh nghiệp đều sử dụng AWS.

Tổng Quan Về Bảo Mật Đám Mây 

Trước đây, bảo mật là trách nhiệm chung giữa các nhóm Development và Operation. Nhưng ngày nay, trách nhiệm được phân chia giữa toàn bộ công ty (thông qua nhóm DevOps) và nhà cung cấp Public Cloud. 

AWS minh họa chủ đề này rất tốt trong Mô hình Trách nhiệm: AWS chịu trách nhiệm về bảo mật “của” đám mây, trong khi khách hàng chịu trách nhiệm cho những gì diễn ra “trong” đám mây. Nói cách khác, AWS chịu trách nhiệm bảo vệ cơ sở hạ tầng bên dưới (ví dụ: phần cứng, phần mềm, mạng, cơ sở hạ tầng) và các dịch vụ được quản lý, trong khi khách hàng chịu trách nhiệm quản lý và xác định cấu hình các dịch vụ mà họ xây dựng trên AWS.

Bạn có thể chia các dịch vụ AWS thành ba nhóm: Infrastructure, Container, Abstracted.

  • Infrastructure: Bạn có trách nhiệm hoạt động lớn hơn với các dịch vụ này, chẳng hạn như VPC hoặc EC2. Bạn chịu trách nhiệm áp dụng những thay đổi trong bảo mật cho các hệ thống instances và đảm bảo rằng hệ thống của mình được thiết lập cấu hình thích hợp.
  • Container: Đây là những dịch vụ mà AWS cung cấp cho bạn một dịch vụ bán quản lý, như RDS và EMR. Tại đây, bạn vẫn có trách nhiệm vận hành đối với các tài nguyên cơ bản mà các dịch vụ đó cung cấp, bao gồm các phiên bản EC2 được liên kết với chúng.
  • Abstracted: Thông thường các dịch vụ này được liên kết với các mô hình Serverless, chẳng hạn như S3, SQS và SES. Với những điều này, trách nhiệm của bạn là ít nhất vì bạn không có tài nguyên cơ bản đang chạy trong tài khoản của mình. Tuy nhiên, bạn phải đảm bảo rằng các tài nguyên này được cấu hình đúng.

Điều quan trọng không kém đối với sự phân chia trách nhiệm là hiểu cách tuân thủ các tiêu chuẩn và quy định khi tham gia vận hành trên nền tảng đám mây. Các nhà cung cấp Public Cloud lớn lựa chọn tuân thủ nhiều chương trình nhằm giảm bớt trách nhiệm cho phía khách hàng.

Tin vui là khi cơ sở hạ tầng và nền tảng cơ bản của một nhà cung cấp đám mây nhất định đã được chứng nhận, quá trình cho bạn sẽ trở nên dễ dàng và nhẹ nhàng hơn nhiều.

Giới Thiệu Về Dịch Vụ AWS

Người dùng cá nhân và doanh nghiệp lần đầu chuyển từ trung tâm dữ liệu tại chỗ sang Public Cloud có thể thấy quá trình này khá khó khăn và đáng sợ, ngay cả khi họ là dân IT có hơn 20 năm kinh nghiệm. Điều này là do có một sự thay đổi mô hình giữa cơ sở hạ tầng CNTT truyền thống và Public Cloud. Phần này sẽ cung cấp một cái nhìn tổng quan về sự khác biệt và điểm tương đồng giữa hai thế giới.

Về cốt lõi, Public Cloud có cùng loại tài nguyên có thể tìm thấy trong một trung tâm dữ liệu tại chỗ truyền thống. Những yếu tố nền tảng này bao gồm: điện toán, lưu trữ và tài nguyên mạng.

Yếu Tố Nền Tảng

Tài nguyên đám mây: tương tự như các máy ảo bạn có tại chỗ. AWS cung cấp các phiên bản ảo (AWS EC2), nhưng EC2 chỉ là một trong nhiều dịch vụ tính toán mà AWS cung cấp. Ngoài ra gồm có AWS Lambda (cho máy tính FaaS không có máy chủ), AWS EKS (cho Kubernetes được quản lý) và AWS ECS /Fargate (cho các container không có máy chủ như một dịch vụ). Đây là những dịch vụ đáng để khám phá khi thiết kế ứng dụng dựa trên đám mây vì chúng làm giảm chi phí hoạt động và thực sự cho phép bạn tận dụng các dịch vụ từ Public Cloud mang lại.

Tài nguyên lưu trữ: Có hai dịch vụ trong AWS tương đương với trung tâm dữ liệu tại chỗ truyền thống. AWS EBS cung cấp lưu trữ khối sẽ được sử dụng trong các dịch vụ như AWS EC2 (ví dụ ảo), tương tự như SAN truyền thống cung cấp lưu trữ khối cho các máy ảo trong trung tâm dữ liệu. AWS EFS cung cấp lưu trữ tệp mạng tương tự như NAS truyền thống. Và một dịch vụ lưu trữ thứ ba có sẵn trong AWS và không thường thấy trong một trung tâm dữ liệu tại chỗ truyền thống là AWS S3 (lưu trữ đối tượng). Lưu trữ đối tượng cung cấp lưu trữ không giới hạn cho các đối tượng thông qua REST API. Đây là một khái niệm quan trọng được sử dụng để cung cấp lưu trữ dữ liệu liên tục cho các ứng dụng có nguồn gốc đám mây.

Tài nguyên mạng: Các loại tài nguyên này trong đám mây công cộng đều tương tự nhau (về lý thuyết) nhưng trên thực tế lại rất khác nhau đối với các loại tài nguyên được tìm thấy trong một trung tâm dữ liệu tại chỗ. Mạng trong đám mây công cộng là SDNs (Software Defined Networks), vì vậy tất cả các tài nguyên mạng có thể được tạo, quản lý và chấm dứt hoàn toàn thông qua các yêu cầu API.

Vùng Sẵn Sàng (Availability Zones)

Có nhiều Vùng AWS trên toàn cầu, mỗi Vùng AWS có hai hoặc nhiều Vùng sẵn có. Người ta có thể so sánh một Vùng sẵn sàng có với một trung tâm dữ liệu độc lập, nghĩa là người ta sẽ mong muốn tìm thấy ít nhất hai trung tâm dữ liệu trong mỗi Vùng AWS. Mỗi một mạng con được tạo trong AWS được gán cho Vùng sẵn có cụ thể. Nhiều mạng con có thể được nhóm thành một VPC (Đám mây riêng ảo). Một VPC được gán cho Vùng AWS cụ thể. Điều này cho phép khách hàng có các mạng khả dụng cao trong nhiều Vùng sẵn có, tạo ra các kịch bản lý tưởng cho việc chuyển đổi dự phòng, khắc phục thảm họa và tính sẵn sàng cao.

Hình 1: Ví dụ bố trí mạng AWS với kết nối tại chỗ

Một ví dụ về cấu trúc liên kết mạng điển hình trong AWS, sử dụng các dịch vụ gốc bao gồm kết nối với trung tâm dữ liệu tại chỗ.

Các cân nhắc về bảo mật và các chi tiết chuyên sâu hơn cho cả hai khía cạnh mạng và lưu trữ của AWS sẽ là chủ đề chính của bài viết thứ hai của loạt bài này. Hiện tại, chúng tôi sẽ chuyển sang một số khía cạnh cần được tính đến khi xem xét chuyển sang đám mây công cộng và lập kế hoạch chuyển đổi.

Những Điều Cần Xem Xét Trước Khi Di Chuyển

Trước hết, bạn nên hiểu mục đích của doanh nghiệp đằng sau quá trình dịch chuyển lên đám mây. Chi phí sẽ là yếu tố thường được mọi người quan tâm đầu tiên, nhưng điều đó không nên là điều duy nhất và cũng không phải là sự cân nhắc chính. Đúng là đám mây công cộng cho phép bạn tiết kiệm chi phí trong trung và dài hạn bằng cách chuyển từ CapEx (Chi phí vốn) sang OpEx (Chi phí hoạt động) và hưởng lợi từ tính kinh tế của quy mô mà các nhà cung cấp đám mây công cộng cung cấp. Tuy nhiên, bạn nên nhớ rằng trong thời gian ngắn (trong quá trình chuyển đổi), bạn sẽ thường phải chịu một chi phí cao hơn cho tổ chức.

Từ quan điểm kỹ thuật, có những chiến lược khác nhau để xem xét trong khi chuyển sang đám mây công cộng. Những cách phổ biến nhất là cách tiếp cận “Nâng và Chuyển đổi”, khuyến khích việc di chuyển tại chỗ, và cách tiếp cận kiến trúc Re-Architecting, khuyến khích việc làm lại các ứng dụng tại chỗ để trở thành đám mây tự nhiên. Mặc dù cả hai đều có giá trị, cả hai cũng phụ thuộc rất nhiều vào khung thời gian và tài năng kỹ thuật sẵn có của tổ chức, do đó cần phải được xem xét và lên kế hoạch cẩn thận.

Để được hướng dẫn thêm về di chuyển, xem thêm tài liệu tại Securely Migrating to AWS, ngoài ra còn AWS Cloud Migration portal và The AWS Cloud Adoption Framework sẽ cung cấp một phân tích sâu sắc và phong phú về những gì cần được tính đến trước khi dịch chuyển.

Cấu Tạo Của Các Tài Khoản AWS

Tài khoản AWS là yếu tố chính trong chiến lược Cloud Security của bạn. Ba hành động chính phải được thực hiện cho bất kỳ tài khoản mới nào là:

  • Kích hoạt xác thực nhiều yếu tố cho tên người dùng / mật khẩu gốc của bạn.
  • Kích hoạt CloudTrail để cho phép ghi nhật ký và kiểm tra mọi yêu cầu API với Dịch vụ AWS.
  • Tạo người dùng và vai trò IAM cho mọi hành động trong tương lai (ví dụ: sử dụng người dùng / mật khẩu gốc trong các hoạt động hàng ngày của bạn).

Tùy thuộc vào quy mô và mức độ phức tạp của các trường hợp sử dụng của họ, một số công ty / nhóm lựa chọn chiến lược đa tài khoản. Có nhiều tài khoản cho mỗi dự án (ví dụ: CI / DEV, Dàn dựng và Sản xuất) sẽ mang lại mức độ phức tạp bổ sung từ quan điểm quản lý. Tuy nhiên, dịch vụ Tổ chức AWS có thể đơn giản hóa quy trình bằng cách cho phép bạn quản lý tất cả các tài khoản từ một chế độ xem duy nhất và áp dụng các chính sách bảo mật và hạn chế từ cùng một nơi.

<img src=”awsdataikhoan.png” alt=”AWS đa tài khoản”>
AWS đa tài khoản

Hình 2: Ví dụ về chiến lược AWS đa tài khoản

Mặt khác, một chiến lược tài khoản duy nhất cũng khá phổ biến (đặc biệt là trong các dự án nhỏ hơn với nguồn lực hạn chế) vì việc quản lý đơn giản hơn rất nhiều. Tuy nhiên, điều quan trọng là phải xem xét rằng chiến lược này thường chuyển thành các vai trò IAM phức tạp hơn để đảm bảo rằng bạn tuân theo nguyên tắc đặc quyền tối thiểu trên mỗi dịch vụ và môi trường.

Bạn cũng có thể chọn cách tiếp cận hỗn hợp, với nhiều tài khoản trong toàn tổ chức được ghép nối với một tài khoản hoặc nhiều tài khoản cho mỗi trường hợp dịch vụ / trường hợp sử dụng tùy thuộc vào mức độ phức tạp của từng tài khoản.

Kết Luận 

Bài viết này cung cấp giới thiệu về chủ đề bảo mật trong đám mây công cộng AWS, Microsoft Azure và Google Cloud và một số ví dụ trong thế giới thực trong AWS. Các chủ đề chính được giới thiệu là các chiến lược khác nhau có thể được sử dụng cho các tài khoản AWS cũng như các khối xây dựng chính có thể tìm thấy trong một nhà cung cấp đám mây công cộng như AWS.

Chúng tôi cũng đề cập đến các yếu tố nền tảng có thể tìm thấy cả trong một trung tâm dữ liệu tại chỗ truyền thống và trong một đám mây công cộng (tính toán, mạng và lưu trữ). Hiểu được những điều này là bước đầu tiên quan trọng để có một chiến lược bảo mật vững chắc trong đám mây công cộng. Trong phần hai của loạt bài này, chúng tôi sẽ liên kết sâu hơn vào hai trong số các mạng này và lưu trữ trên mạng và bao gồm các mối quan tâm và chiến lược bảo mật chính của họ đáng để khám phá trong AWS.