Bảo mật môi trường và cơ sở hạ tầng AWS

Hai vấn đề mà tất cả các chủ doanh nghiệp gặp phải là giảm thiểu chi phí công nghệ và duy trì bảo mật cho khách hàng. Nếu bạn là nhà phát triển và / hoặc người hoạt động của nhà phát triển (hoặc mọi người) cho một doanh nghiệp nhỏ, điều này đặt ra những thách thức độc đáo. Bạn chọn đám mây, hay trung tâm dữ liệu truyền thống? Làm thế nào để bạn đảm bảo thời gian hoạt động, tính khả dụng và bảo mật mà không phải hy sinh sự tỉnh táo, tiền bạc cho doanh nghiệp hoặc khiến khách hàng của bạn gặp rủi ro? Đây là những câu hỏi mà tôi phải trả lời khi xây dựng Skweez.Me .

Trong một bài báo trước của DZone, tôi đã viết về sự khác biệt trong bảo mật giữa trung tâm dữ liệu truyền thống và Amazon Web Services (AWS). Trong một bài viết sau đây, tôi đã viết về việc tạo cơ sở hạ tầng tự động trong AWS cho doanh nghiệp mới chớm nở của bạn, một cơ sở hạ tầng cho phép cá nhân tôi ngủ ngon vào ban đêm mà không phải phá vỡ ngân hàng. Trong bài viết này, tôi sẽ chia nhỏ cách thực hiện cả hai bước này theo từng bước như tôi đã làm với Skweez.Me .

Cơ sở hạ tầng VPC

Việc bảo mật VPC trong AWS gần như không gây đau đớn, nhưng yêu cầu một số cơ sở để tách các mạng con công khai và riêng tư của bạn. Để tiết kiệm tiền và giúp lựa chọn VPC dễ dàng nhất cho các trường hợp trong tương lai của bạn, tôi khuyên bạn nên sửa đổi VPC mặc định, tách từng vùng khả dụng thành một mạng con công cộng và một mạng con riêng tư. Cách bạn làm điều này là hoàn toàn tùy thuộc vào bạn; Tôi chia hai vùng khả dụng mà tôi sử dụng thành các mạng con “/ 21”, mang lại nhiều IP khả dụng:

Tôi cũng thiết lập một nhóm mạng con cho các DB RDS của mình để đảm bảo rằng các cá thể cơ sở dữ liệu cũng chỉ được phân bổ trong các mạng con riêng tư của tôi:

Tiếp theo, bạn sẽ cần một cách để các cá thể mạng con riêng của mình truy cập vào mạng. Điều này luôn được thực hiện bằng cách sử dụng cổng NAT.

Bạn sẽ cần đảm bảo rằng có một cổng NAT cho mỗi mạng con công cộng được liên kết với các mạng con riêng tư mà bạn đang cấp giao tiếp ra ngoài. Nói cách khác, nếu bạn muốn giao tiếp ra bên ngoài hoạt động từ mạng con “Riêng tư A”, bạn sẽ cần tạo cổng NAT trong “Công cộng A” và cập nhật bảng định tuyến một cách thích hợp.

 Cho đến nay, cách dễ nhất để làm điều này là tạo cổng NAT thông qua VPC của bạn trực tiếp . Khi làm điều này, AWS sẽ tự động phân bổ và chỉ định các IP đàn hồi cho mỗi cổng NAT mới. Cách thay thế là tạo các phiên bản NAT của riêng bạn . Phân tích ưu và nhược điểm của từng loại:

Khuyến nghị của tôi là quản lý các phiên bản NAT cho đến khi bạn đạt được quy mô / lợi nhuận, lúc đó việc sử dụng các cổng NAT tích hợp sẽ hiệu quả hơn và tiết kiệm chi phí hơn. Việc di chuyển từ các phiên bản sang cổng NAT tích hợp cũng rất dễ thực hiện.

Cơ sở hạ tầng nhà phát triển

Giả định hợp lý là bạn sẽ bắt đầu bằng việc xây dựng một môi trường phát triển, một môi trường nơi bạn có thể cập nhật mã và cơ sở dữ liệu mà không ảnh hưởng đến môi trường sản xuất.

Tôi đã chọn các loại phiên bản nhỏ cho cả phiên bản RDS DB và EC2 (số ít). RDS DB không có sao lưu tự động, không có cập nhật điểm và nằm trong một vùng khả dụng duy nhất. Khi tôi hoàn thành phiên bản DB và EC2, tôi tắt chúng và nếu tôi đã thực hiện bất kỳ thay đổi nào đối với DB, tôi sẽ chụp ảnh nhanh cuối cùng. Lần tiếp theo khi phát triển, tôi khởi động dev DB bằng cách sử dụng ảnh chụp nhanh mới nhất. Điều khó chịu duy nhất của điều này là không thể thay đổi nhóm bảo mật trong quá trình khôi phục ảnh chụp nhanh và chỉ có thể được thay đổi trên một phiên bản đang chạy, kết quả là bạn sẽ khởi động DB và sau đó sửa đổi nó cho nhóm bảo mật thích hợp.

Phiên bản dev DB và EC2 có một bộ yêu cầu bảo mật khác với môi trường sản phẩm:

Do đó, các mạng con cho các cá thể EC2 và các nhóm bảo mật cho DB RDS khác nhau giữa các môi trường.

Bạn cũng có thể chọn tạo ELB dành cho nhà phát triển. Sự cân bằng là nếu bạn sử dụng ELB, bạn sẽ cần phải liên kết phiên bản nhà phát triển với ELB của bạn mỗi lần. Nếu bạn chọn sử dụng phiên bản nhà phát triển công khai (với IP công khai), bạn có thể sẽ muốn sử dụng nhà cung cấp DNS của mình (của tôi là Route53) để trỏ đến IP công khai của phiên bản nhà phát triển của bạn. Sự khác biệt ở đây là nhỏ và kết quả là như nhau về chi phí và công sức.

Cơ sở hạ tầng sản xuất

Ở đây tôi sử dụng thiết lập EC2 truyền thống, với ELB được kết nối với nhóm chia tỷ lệ tự động. Như đã nêu ở trên, tất cả các phiên bản EC2 đều nằm trên mạng con riêng, ELB nằm trên mạng con công cộng và giờ đây, cả kiểm soát định tuyến và truy cập đều đảm bảo rằng người ngoài không thể giao tiếp trực tiếp với các nút web hoặc cơ sở dữ liệu của tôi.

Nhóm chia tỷ lệ tự động đảm bảo rằng dịch vụ có tính khả dụng cao, duy trì ít nhất hai nút tại bất kỳ thời điểm nào. Tôi sử dụng một hộp xây dựng mà tôi triển khai mã trước tiên, cắt AMI và tạo cấu hình khởi chạy mới và cuối cùng cập nhật nhóm tự động mở rộng quy mô, để đảm bảo rằng mã và cài đặt luôn được cập nhật, ngay cả trong các sự kiện quy mô.

Cơ sở dữ liệu đa AZ và được sao lưu đầy đủ mỗi ngày (trong 5 ngày tiếp theo), do đó đảm bảo rằng sự cố ngừng hoạt động trong DB sẽ dẫn đến chuyển đổi dự phòng tự động và việc mất dữ liệu có thể ngăn chặn được thông qua cả ảnh chụp nhanh thời điểm 5 phút cũng như ảnh chụp nhanh hàng ngày đầy đủ.

Tổng quan về cơ sở hạ tầng

Kết hợp tất cả lại với nhau, cơ sở hạ tầng cuối cùng trông như thế này: