كيفية حماية واجهتين أماميتين صغيرتين باحتياجات وصول مختلفة على واجهة AWS الخلفية

تحقيق التوازن بين الأمان وإمكانية الوصول في بنية AWS Micro-Frontend

غالبًا ما يتضمن تصميم بنيات سحابية آمنة وقابلة للتطوير تحقيق التوازن بين إمكانية الوصول والوصول المقيد. في إعداد AWS الخاص بك، لديك واجهتان أماميتان صغيرتان بمتطلبات وصول فريدة. يجب أن يقتصر FE-A على عنوان IP ثابت محدد، بينما يجب أن يكون FE-B متاحًا للعامة. إن تلبية هذه الاحتياجات في وقت واحد يمكن أن تشكل تحديًا. 😅

ينشأ التحدي عند تكوين مجموعات الأمان في EC2. إذا سمحت بالوصول إلى 0.0.0.0، فسيتم الوصول إلى كلا الواجهتين الأماميتين بشكل عام، مما يعرض أمان FE-A للخطر. من ناحية أخرى، يؤدي تقييد الوصول إلى عنوان IP ثابت واحد إلى رفض التوفر العام لـ FE-B. وهذا يخلق توازنًا معقدًا بين الانفتاح والأمن.

على الرغم من أن وظيفة Lambda لتحديث نطاقات IP ديناميكيًا قد تبدو قابلة للتطبيق، إلا أنها تقدم حملاً إضافيًا ولا تمثل حلاً مثاليًا على المدى الطويل. على سبيل المثال، قد يؤدي ذلك إلى زيادة التكاليف والتعقيد بمرور الوقت. علاوة على ذلك، فإن إدارة التحديثات المتكررة لمجموعات الأمان يمكن أن تكون مرهقة وعرضة للأخطاء.

يعد العثور على حل فعال من حيث التكلفة يلبي هذه المتطلبات أمرًا بالغ الأهمية. الهدف هو حماية FE-A مع ضمان بقاء FE-B متاحًا عالميًا دون إدخال تعقيدات غير ضرورية. دعنا نستكشف كيفية تحقيق ذلك باستخدام أفضل ممارسات AWS. 🚀

استراتيجيات تأمين الواجهات الصغيرة باستخدام AWS

يستفيد البرنامج النصي الأول من إمكانات جدار حماية تطبيق الويب AWS (واف) لفرض سياسات وصول مميزة لواجهتين صغيرتين. من خلال إنشاء WebACL، يتم تطبيق قواعد IP محددة على FE-A للسماح فقط بحركة المرور من شبكة محددة IP ثابت، مما يضمن بقاءه نظامًا مغلقًا. بالنسبة لـ FE-B، تسمح قاعدة منفصلة بالوصول العام. يعمل هذا الأسلوب على مركزية التحكم في الوصول في طبقة التطبيق، مما يجعله مثاليًا لإدارة حركة المرور بكفاءة دون تعديل مجموعات أمان EC2 الأساسية. على سبيل المثال، يمكنك تقييد FE-A بشبكة مكتب مع السماح لـ FE-B بالبقاء متاحًا عالميًا، مما يلبي أمان الشركة وراحة المستخدم. 🌍

يتم بعد ذلك ربط WebACL بموازن تحميل التطبيق (ALB)، مما يضمن تصفية كل حركة المرور التي تمر عبر ALB وفقًا لهذه القواعد. الأمر waf_client.create_web_acl أمر محوري في تحديد القواعد، في حين waf_client.associate_web_acl يربط WebACL بالمورد. هذا الإعداد قابل للتطوير بشكل كبير ويسمح بإجراء تعديلات مستقبلية، مثل إضافة عناوين IP جديدة أو تعديل سياسات الوصول، بأقل جهد. يمكن لميزات المراقبة مثل مقاييس CloudWatch أيضًا تتبع فعالية القواعد، مما يوفر رؤى قيمة حول أنماط حركة المرور.

وفي المقابل، يقوم الحل القائم على Lambda بتحديث قواعد مجموعة الأمان EC2 ديناميكيًا. يقوم هذا البرنامج النصي بإحضار نطاقات IP الخاصة بمنطقة AWS الخاصة بك ويقوم بتكوينها كقواعد دخول في مجموعة الأمان. الوظيفة ec2.authorize_security_group_ingres يضيف أو يحدّث نطاقات IP المسموح بها، مما يتيح إمكانية الوصول إلى FE-B بشكل عام مع الحفاظ على رقابة صارمة على FE-A. يعد هذا النهج مفيدًا بشكل خاص في البيئات التي تتغير فيها متطلبات IP بشكل متكرر، مثل إعدادات التطوير المستندة إلى السحابة أو مكاتب الشركات المتغيرة. على سبيل المثال، إذا تم إنشاء مكتب فرعي جديد، فيمكنك إضافة عنوان IP الخاص به تلقائيًا إلى القائمة البيضاء دون تدخل يدوي. 🏢

تعمل وظيفة Lambda، جنبًا إلى جنب مع حدث CloudWatch المجدول، على تشغيل هذه التحديثات تلقائيًا يوميًا، مما يقلل من الحمل الإداري. وفي حين أن هذا الأسلوب يزيد من التعقيد، فإنه يوفر تحكمًا دقيقًا في حركة المرور. تعمل اختبارات الوحدة المضمنة في البرنامج النصي على التحقق من صحة الوظيفة، مما يضمن تطبيق قواعد الأمان بشكل صحيح دون حدوث أخطاء. سواء اخترت WAF أو Lambda، فإن كلا الطريقتين تعطي الأولوية لفعالية التكلفة والمرونة، وموازنة الحاجة إلى الوصول العام والمقيد. في النهاية، تُظهر هذه الحلول تنوع AWS في تلبية المتطلبات المتنوعة مع الحفاظ على الأمان القوي. 🔒

# 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()

تحسين الأمان وإمكانية الوصول لتطبيقات Micro-Frontend في AWS

هناك طريقة أخرى فعالة لمواجهة التحدي المتمثل في تحقيق التوازن بين الوصول المقيد والعام في بنية الواجهة الأمامية الصغيرة الخاصة بك وهي الاستفادة من ميزات AWS Amplify المتكاملة. يعمل Amplify على تبسيط الاستضافة والنشر مع توفير الأدوات اللازمة لتكوين واجهات برمجة التطبيقات الخلفية بشكل آمن. بالنسبة إلى FE-A، يمكنك تنفيذ التحكم في الوصول إلى الشبكة عن طريق تقييد نقاط نهاية واجهة برمجة التطبيقات الخلفية الخاصة بها على عناوين IP محددة باستخدام بوابة AWS API. يضمن هذا الإعداد أن عناوين IP الثابتة المحددة مسبقًا فقط هي التي يمكنها التفاعل مع الواجهة الخلفية، بينما يمكن أن تظل نقاط نهاية FE-B غير مقيدة للوصول العام. وهذا لا يعزز الأمان فحسب، بل يتكامل أيضًا بسلاسة مع سير عمل CI/CD الخاص بـ Amplify. 🌐

هناك اعتبار آخر وهو استخدام Amazon CloudFront مع سياسات الوصول المخصصة للأصل. يمكن لـ CloudFront توجيه حركة المرور إلى الواجهة الخلفية المناسبة بناءً على مسار عنوان URL، ليكون بمثابة حارس البوابة للواجهات الأمامية الصغيرة الخاصة بك. يمكن تصفية حركة مرور FE-A من خلال CloudFront باستخدام سياسة طلب الأصل التي تتحقق من قيود IP أو رؤوس محددة. على سبيل المثال، يمكن لمؤسسة تنشر أداة داخلية من خلال FE-A إضافة عامل تصفية لنطاق IP مع إتاحة FE-B عالميًا للمستخدمين النهائيين. يعمل هذا النهج على تحسين كل من قابلية التوسع والأداء، خاصة بالنسبة للتطبيقات التي تتطلب توزيعًا عالميًا. 🚀

وأخيرًا، يضيف تطبيق AWS Cognito لمصادقة المستخدم طبقة إضافية من الأمان. يمكن قفل FE-A خلف نظام تسجيل دخول يتطلب مصادقة المستخدم بأدوار أو مجموعات محددة، بينما يمكن لـ FE-B استخدام آلية مصادقة أخف أو لا شيء على الإطلاق للوصول العام. من خلال الجمع بين قيود المصادقة والوصول إلى الشبكة، يمكنك تحقيق نموذج أمان قوي مصمم خصيصًا لتلبية احتياجات كل واجهة أمامية صغيرة. تعتبر هذه الإستراتيجية فعالة بشكل خاص للشركات الناشئة والشركات الصغيرة والمتوسطة التي تبحث عن حلول سحابية آمنة وقابلة للتطوير وبأسعار معقولة. 🔐