Cách bảo vệ hai giao diện vi mô với các nhu cầu truy cập khác nhau trên phần phụ trợ AWS

Cân bằng bảo mật và khả năng truy cập trong Kiến trúc giao diện vi mô AWS

Thiết kế kiến ​​trúc đám mây an toàn và có thể mở rộng thường liên quan đến việc cân bằng khả năng truy cập và quyền truy cập hạn chế. Trong quá trình thiết lập AWS, bạn có hai giao diện người dùng vi mô với các yêu cầu truy cập riêng. FE-A cần được giới hạn ở một IP tĩnh cụ thể, trong khi FE-B phải có thể truy cập công khai. Việc giải quyết đồng thời những nhu cầu này có thể đặt ra một thách thức. 😅

Thử thách nảy sinh khi định cấu hình các nhóm bảo mật trong EC2. Nếu bạn cho phép truy cập vào 0.0.0.0 thì cả hai giao diện người dùng đều có thể truy cập công khai, làm ảnh hưởng đến tính bảo mật của FE-A. Mặt khác, việc hạn chế quyền truy cập vào một IP tĩnh sẽ từ chối tính khả dụng công khai của FE-B. Điều này tạo ra một hành động cân bằng phức tạp giữa tính mở và tính bảo mật.

Mặc dù chức năng Lambda để cập nhật động các dải IP có vẻ khả thi nhưng nó lại gây ra chi phí bổ sung và không phải là giải pháp dài hạn tối ưu. Ví dụ, nó có thể làm tăng chi phí và độ phức tạp theo thời gian. Hơn nữa, việc quản lý cập nhật thường xuyên cho các nhóm bảo mật có thể phức tạp và dễ xảy ra lỗi.

Việc tìm kiếm một giải pháp tiết kiệm chi phí, đáp ứng được những yêu cầu này là rất quan trọng. Mục tiêu là bảo vệ FE-A đồng thời đảm bảo FE-B vẫn có thể truy cập được trên toàn cầu mà không gây ra những phức tạp không cần thiết. Hãy cùng khám phá cách đạt được điều này bằng các biện pháp thực hành tốt nhất của AWS. 🚀

Các chiến lược bảo mật giao diện vi mô với AWS

Tập lệnh đầu tiên tận dụng khả năng của Tường lửa ứng dụng web AWS (WAF) để thực thi các chính sách truy cập riêng biệt cho hai giao diện người dùng vi mô. Bằng cách tạo WebACL, các quy tắc IP cụ thể được áp dụng cho FE-A để chỉ cho phép lưu lượng truy cập từ một địa chỉ được chỉ định IP tĩnh, đảm bảo nó vẫn là một hệ thống khép kín. Đối với FE-B, một quy tắc riêng cho phép truy cập công khai. Cách tiếp cận này tập trung kiểm soát quyền truy cập ở lớp ứng dụng, khiến nó trở nên lý tưởng để quản lý lưu lượng truy cập hiệu quả mà không cần sửa đổi các nhóm bảo mật EC2 cơ bản. Ví dụ: bạn có thể hạn chế FE-A trong mạng văn phòng trong khi cho phép FE-B vẫn có thể truy cập được trên toàn cầu, phục vụ cả bảo mật doanh nghiệp và sự thuận tiện cho người dùng. 🌍

Sau đó, WebACL được liên kết với Trình cân bằng tải ứng dụng (ALB), đảm bảo rằng tất cả lưu lượng truy cập đi qua ALB đều được lọc theo các quy tắc này. Lệnh waf_client.create_web_acl là then chốt trong việc xác định các quy tắc, trong khi waf_client.associate_web_acl liên kết WebACL với tài nguyên. Thiết lập này có khả năng mở rộng cao và cho phép điều chỉnh trong tương lai, chẳng hạn như thêm IP mới hoặc sửa đổi chính sách truy cập mà không tốn nhiều công sức. Các tính năng giám sát như số liệu CloudWatch cũng có thể theo dõi tính hiệu quả của các quy tắc, cung cấp thông tin chi tiết có giá trị về mô hình lưu lượng truy cập.

Ngược lại, giải pháp dựa trên Lambda cập nhật động các quy tắc của nhóm bảo mật EC2. Tập lệnh này tìm nạp các dải IP cụ thể cho khu vực AWS của bạn và định cấu hình chúng làm quy tắc xâm nhập trong nhóm bảo mật. chức năng ec2.authorize_security_group_ingress thêm hoặc cập nhật phạm vi IP được phép, cho phép FE-B có thể truy cập công khai trong khi vẫn duy trì sự kiểm soát chặt chẽ đối với FE-A. Cách tiếp cận này đặc biệt hữu ích trong các môi trường có yêu cầu IP thay đổi thường xuyên, chẳng hạn như thiết lập phát triển dựa trên đám mây hoặc chuyển văn phòng công ty. Ví dụ: nếu một văn phòng chi nhánh mới được thành lập, bạn có thể tự động thêm IP của văn phòng đó vào danh sách trắng mà không cần can thiệp thủ công. 🏢

Hàm Lambda kết hợp với sự kiện CloudWatch đã lên lịch sẽ tự động hóa các cập nhật này hàng ngày, giảm chi phí quản trị. Mặc dù cách tiếp cận này làm tăng thêm độ phức tạp nhưng nó cung cấp khả năng kiểm soát chi tiết đối với lưu lượng truy cập. Các bài kiểm tra đơn vị có trong tập lệnh sẽ xác thực chức năng, đảm bảo các quy tắc bảo mật được áp dụng chính xác mà không gây ra lỗi. Cho dù bạn chọn WAF hay Lambda, cả hai phương pháp đều ưu tiên hiệu quả chi phí và tính linh hoạt, cân bằng nhu cầu truy cập công khai và truy cập hạn chế. Cuối cùng, những giải pháp này thể hiện tính linh hoạt của AWS trong việc đáp ứng các yêu cầu đa dạng đồng thời duy trì khả năng bảo mật mạnh mẽ. 🔒

# Step 1: Define IP restrictions in AWS WAF
# Create a WebACL to allow only specific IP ranges for FE-A and public access for FE-B.
import boto3
waf_client = boto3.client('wafv2')
response = waf_client.create_web_acl(    Name='MicroFrontendAccessControl',    Scope='REGIONAL',    DefaultAction={'Allow': {}},    Rules=[        {            'Name': 'AllowSpecificIPForFEA',            'Priority': 1,            'Action': {'Allow': {}},            'Statement': {                'IPSetReferenceStatement': {                    'ARN': 'arn:aws:wafv2:region:account-id:ipset/ipset-id'                }            },            'VisibilityConfig': {                'SampledRequestsEnabled': True,                'CloudWatchMetricsEnabled': True,                'MetricName': 'AllowSpecificIPForFEA'            }        },        {            'Name': 'AllowPublicAccessForFEB',            'Priority': 2,            'Action': {'Allow': {}},            'Statement': {'IPSetReferenceStatement': {'ARN': 'arn:aws:wafv2:region:account-id:ipset/ipset-id-for-public'}},            'VisibilityConfig': {                'SampledRequestsEnabled': True,                'CloudWatchMetricsEnabled': True,                'MetricName': 'AllowPublicAccessForFEB'            }        }    ],    VisibilityConfig={        'SampledRequestsEnabled': True,        'CloudWatchMetricsEnabled': True,        'MetricName': 'MicroFrontendAccessControl'    })
print("WebACL created:", response)
# Step 2: Associate the WebACL with your Application Load Balancer
response = waf_client.associate_web_acl(    WebACLArn='arn:aws:wafv2:region:account-id:webacl/webacl-id',    ResourceArn='arn:aws:elasticloadbalancing:region:account-id:loadbalancer/app/load-balancer-name')
print("WebACL associated with Load Balancer:", response)

# Import required modules
import boto3
import requests
# Step 1: Fetch public IP ranges for your region
def get_ip_ranges(region):
    response = requests.get("https://ip-ranges.amazonaws.com/ip-ranges.json")
    ip_ranges = response.json()["prefixes"]
    return [prefix["ip_prefix"] for prefix in ip_ranges if prefix["region"] == region]
# Step 2: Update the security group
def update_security_group(security_group_id, ip_ranges):
    ec2 = boto3.client('ec2')
    permissions = [{"IpProtocol": "tcp", "FromPort": 80, "ToPort": 80, "IpRanges": [{"CidrIp": ip} for ip in ip_ranges]}]
    ec2.authorize_security_group_ingress(GroupId=security_group_id, IpPermissions=permissions)
# Step 3: Lambda handler
def lambda_handler(event, context):
    region = "us-west-2"
    security_group_id = "sg-0123456789abcdef0"
    ip_ranges = get_ip_ranges(region)
    update_security_group(security_group_id, ip_ranges)
    return {"statusCode": 200, "body": "Security group updated successfully"}

import unittest
from unittest.mock import patch
class TestSecurityConfigurations(unittest.TestCase):
    @patch("boto3.client")
    def test_update_security_group(self, mock_boto3):
        mock_ec2 = mock_boto3.return_value
        ip_ranges = ["192.168.0.0/24", "203.0.113.0/24"]
        update_security_group("sg-0123456789abcdef0", ip_ranges)
        mock_ec2.authorize_security_group_ingress.assert_called()
    def test_get_ip_ranges(self):
        region = "us-west-2"
        ip_ranges = get_ip_ranges(region)
        self.assertIsInstance(ip_ranges, list)
if __name__ == "__main__":
    unittest.main()

Tối ưu hóa bảo mật và khả năng truy cập cho các ứng dụng có giao diện vi mô trong AWS

Một cách hiệu quả khác để giải quyết thách thức trong việc cân bằng quyền truy cập bị hạn chế và truy cập công khai trong kiến ​​trúc giao diện người dùng vi mô của bạn là tận dụng các tính năng tích hợp của AWS Amplify. Amplify đơn giản hóa việc lưu trữ và triển khai đồng thời cung cấp các công cụ để định cấu hình API phụ trợ một cách an toàn. Đối với FE-A, bạn có thể triển khai kiểm soát truy cập mạng bằng cách hạn chế các điểm cuối API phụ trợ của nó ở các IP cụ thể bằng cách sử dụng Cổng API AWS. Thiết lập này đảm bảo rằng chỉ những IP tĩnh được xác định trước mới có thể tương tác với phần phụ trợ, trong khi các điểm cuối của FE-B có thể không bị hạn chế đối với quyền truy cập công cộng. Điều này không chỉ tăng cường bảo mật mà còn tích hợp hoàn hảo với quy trình làm việc CI/CD của Amplify. 🌐

Một điều cần cân nhắc khác là sử dụng Amazon CloudFront với các chính sách truy cập nguồn gốc tùy chỉnh. CloudFront có thể định tuyến lưu lượng truy cập đến phần phụ trợ thích hợp dựa trên đường dẫn URL, đóng vai trò là người gác cổng cho các giao diện người dùng vi mô của bạn. Lưu lượng truy cập FE-A có thể được lọc thông qua CloudFront bằng chính sách yêu cầu gốc nhằm kiểm tra các hạn chế IP hoặc tiêu đề cụ thể. Ví dụ: một doanh nghiệp triển khai công cụ nội bộ thông qua FE-A có thể thêm bộ lọc dải IP đồng thời cung cấp FE-B trên toàn cầu cho người dùng cuối. Cách tiếp cận này tối ưu hóa cả khả năng mở rộng và hiệu suất, đặc biệt đối với các ứng dụng yêu cầu phân phối toàn cầu. 🚀

Cuối cùng, việc triển khai AWS Cognito để xác thực người dùng sẽ bổ sung thêm một lớp bảo mật. FE-A có thể bị khóa sau hệ thống đăng nhập yêu cầu xác thực người dùng với các vai trò hoặc nhóm cụ thể, trong khi FE-B có thể sử dụng cơ chế xác thực nhẹ hơn hoặc hoàn toàn không sử dụng cơ chế xác thực nào để truy cập công khai. Bằng cách kết hợp các hạn chế xác thực và truy cập mạng, bạn sẽ đạt được mô hình bảo mật mạnh mẽ phù hợp với nhu cầu của từng giao diện người dùng vi mô. Chiến lược này đặc biệt hiệu quả đối với các công ty khởi nghiệp và doanh nghiệp vừa và nhỏ đang tìm kiếm các giải pháp đám mây an toàn, có thể mở rộng và giá cả phải chăng. 🔐