تعيين إعدادات AWS الافتراضية الآمنة وتجنب التكوينات الخاطئة

لا توجد ميزات في AWS سيئة الاستخدام، ولكن هناك بعض الميزات التي قد تزيد من خطر وقوع حادث أمني. أحد الأمثلة على ذلك هو استخدام مفاتيح وصول مستخدم IAM، والتي ناقشنا مخاطرها وأظهرنا كيفية تجنبها في سلسلة مدونة بعنوان كيفية التخلص من مفاتيح الوصول إلى AWS. في منشور المدونة هذا، سنناقش التدابير الوقائية التي يمكنك اتخاذها لضمان الإعدادات الافتراضية الآمنة على AWS، ومنع استخدام الميزات الخطرة، ومنع تعديل حواجز الحماية هذه.

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

في كثير من الحالات، توفر بيانات Access Advisor في AWS أيضًا هذه المعلومات، والتي يمكن التحقق منها بسهولة عبر المؤسسة بأكملها من عرض حساب إدارة المؤسسة. في الحالات التي يتم فيها استخدام هذه الوظيفة، يمكنك إنشاء استثناءات في SCPs إذا لزم الأمر، مثل حسابات أساسية محددة أو حسابات AWS. نحن نعتقد أن SCPs التي نقدمها هنا تتمتع بميزة أمنية قوية بما يكفي لتستحق هذا التحقيق وتعديلًا محتملاً للطرق الحالية للقيام بالأشياء.

يفترض منشور المدونة هذا أنك تقوم بتطبيق SCPs من منشور المدونة السابق. هناك حدود لعدد SCPs التي يمكن استخدامها في AWS، لذلك ستحتاج إلى دمج العديد منها في SCP واحد.

منع نشر مستودعات S3 للعامة

الخطر الأول الذي يفكر فيه الكثيرون فيما يتعلق بالسحابة هو وجود حاويات S3 عامة ذات محتويات حساسة. لم تكن مستودعات S3 متاحة للعامة بشكل افتراضي، ولكن حتى بضع سنوات مضت، كان من السهل جعلها عامة. أضافت AWS الكثير من الاحتكاك على مر السنين لعملية جعل مجموعة S3 عامة، مع تمكين S3 Public Block Access افتراضيًا في مجموعات S3 الجديدة اعتبارًا من أبريل 2023. لجعل حاوية S3 عامة، قم بإيقاف تشغيل هذه الميزة ثم قم بتغيير سياسة الحاوية أو قوائم ACL.

توجد هذه الميزة على مستوى الحساب والحاوية ولديها بعض إعدادات التكوين المختلفة إذا كنت لا تزال بحاجة إلى بعض الوظائف التي تمنعها. لم يتم تمكين هذا في حاويات S3 الأقدم بشكل افتراضي، لذلك نوصي بتمكينه على جميع حاويات S3 الحالية غير العامة، وتمكين إعداد مستوى الحساب في جميع حسابات AWS التي لا تحتوي على حاويات S3 العامة الحالية.

بالنسبة لكل حساب AWS، قم بتشغيل ما يلي لفرض أن جميع حاويات S3 في الحساب ليست عامة:

aws s3control put-public-access-block \ 
    --account-id 123456789012 \ 
    --public-access-block-configuration '{"BlockPublicAcls": true, "IgnorePublicAcls": true, "BlockPublicPolicy": true, "RestrictPublicBuckets": true}' 

وبدلاً من ذلك، بالنسبة لكل حاوية S3، قم بتشغيل ما يلي لفرض عدم نشرها للعامة:

aws s3api put-public-access-block \ 
    --bucket my-bucket \ 
    --public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true" 

ثم قم بتطبيق SCP التالي لمنع تعديل عنصر التحكم هذا:

{  
    "Version": "2012-10-17",  
    "Statement": [  
        {  
            "Action": [  
                "s3:PutAccountPublicAccessBlock",  
                "s3:PutBucketPublicAccessBlock" 
            ],  
            "Resource": "*",  
            "Effect": "Deny"  
        }  
    ]  
} 

منع AMIs من أن تكون عامة

يتم إنشاء مثيلات EC2 من Amazon Machine Images (AMIs). يقدم بائعو أنظمة التشغيل هذه الخدمات علنًا ويمكن للعملاء إنشاء أنظمة خاصة بهم. ما لم تكن بائعًا لنظام التشغيل، فمن المرجح أنك لا ترغب في نشر AMI على الإطلاق. في سبتمبر من هذا العام، AWS مطلق سراحه ميزة جديدة لحماية العملاء من نشر AMIs الخاصة بهم للعامة. الحسابات الجديدة، والحسابات التي لم تكن بها AMIs عامة في 16 أكتوبر 2023، تم تمكين هذه الحماية تلقائيًا.

منع تعطيل هذه الحماية من خلال:

{  
    "Version": "2012-10-17",  
    "Statement": [  
        {  
            "Action": [  
                "ec2:DisableImageBlockPublicAccess" 
            ],  
            "Resource": "*",  
            "Effect": "Deny"  
        }  
    ]  
} 

منع المشاركة العامة لمستندات SSM

يمكن استخدام AWS Systems Manager لإرسال الأوامر إلى واحد أو أكثر من EC2s. ويتم ذلك عن طريق إرسال المستندات إليهم. يمكن مشاركة هذه المستندات مع حسابات أخرى أو حتى نشرها للعامة. من الممكن أن تحتوي هذه المعلومات على معلومات لا تريد أن تكون عامة، لذا يمكنك منع حساباتك من مشاركتها علنًا باستخدام الأمر التالي كما هو موضح هنا (يجب تشغيل هذا في كل منطقة مع تغيير المنطقة):

aws ssm update-service-setting  \ 
    --setting-id /ssm/documents/console/public-sharing-permission \ 
    --setting-value Disable \ 
    --region 'us-east-1' 

يجب عليك بعد ذلك تطبيق SCP لمنع التراجع عن هذا:

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
        { 
            "Sid": "DenySSMDocPublicSharingSetting", 
            "Effect": "Deny", 
            "Action": [ "ssm:UpdateServiceSetting", "ssm:ResetServiceSetting" ], 
            "Resource": "arn:aws:ssm:*:*:servicesetting/ssm/documents/console/public-sharing-permission" 
        } 
    ]
} 

منع عناوين URL الخاصة بـ Lambda من أن تكون عامة

اكتسبت الميزة بدون خادم على AWS والمعروفة باسم Lambda القدرة في عام 2022 على أن يتم استدعاؤها مباشرة، بدلاً من الاتصال بها من خلال بوابة API أو آلية أخرى. يمكن استدعاء عناوين URL الخاصة بالوظائف إما مع المصادقة أو بدونها، لذلك يجب تطبيق SCP التالي لمنع الاتصال المباشر المجهول بها. سيفرض SCP هذا أنه في حالة استخدام عناوين URL للوظيفة، يجب عليهم استخدام مصادقة IAM.

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
        { 
            "Action": [ 
                "lambda:CreateFunctionUrlConfig", 
                "lambda:UpdateFunctionUrlConfig" 
            ], 
            "Resource": " arn:aws:lambda:*:*:function:*", 
            "Effect": "Deny", 
            "Condition": { 
                "StringNotEquals": { 
                    "lambda:FunctionUrlAuthType": "AWS_IAM" 
                } 
            } 
        } 
    ] 
} 

منع ذاكرة الوصول العشوائي (RAM) من مشاركة الموارد مع الحسابات الخارجية

يسمح لك AWS Resource Access Manager (RAM) بمشاركة الموارد مثل VPCs مع حسابات AWS الأخرى. ويمكن أيضًا مشاركة هذه الموارد مع حسابات خارج مؤسسة AWS الخاصة بك، كما يمكن للحسابات الخارجية أيضًا مشاركة الموارد معك. لمنع ذلك، قم بتطبيق SCP التالي:

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
        { 
            "Effect": "Deny", 
            "Action": [ 
                "ram:CreateResourceShare", 
                "ram:UpdateResourceShare" 
            ], 
            "Resource": "*", 
            "Condition": { 
                "Bool": { 
                    "ram:RequestedAllowsExternalPrincipals": "true" 
                } 
            } 
        }, 
        { 
            "Effect": "Deny", 
            "Action": "ram:AcceptResourceShareInvitation", 
            "Resource": "*" 
        } 
    ] 
} 

تعرف على المزيد حول أسس AWS

منع استخدام قوائم S3 ACL

يُنظر عادةً إلى قوائم S3 ACL على أنها مهملة لصالح استخدام سياسات مجموعة S3. يمكن تطبيق قوائم S3 ACL على الحاويات أو الكائنات ويمكن أن تخلق صعوبات في فهم ما إذا كانت بيانات S3 قد تمت مشاركتها ومع من. تم حظر هذه الإمكانية في جميع حاويات S3 الجديدة، ويجب عليك تغيير التحكم في الملكية للسماح بذلك. نوصي بتعيين المجموعات الموجودة على “فرض مالك المجموعة”، الأمر الذي سيؤدي إلى تعطيل قوائم التحكم في الوصول (ACL) كما هو موضح هنا. يمكن القيام بذلك للمجموعات الموجودة باستخدام:

aws s3api put-bucket-ownership-controls --bucket EXAMPLE-BUCKET --ownership-controls="Rules=[{ObjectOwnership=BucketOwnerEnforced}]" 

لمنع تعديل ضوابط الملكية، يجب تطبيق SCP التالي:

{   
    "Version": "2012-10-17",   
    "Statement": [   
        {   
            "Action": "s3:PutBucketOwnershipControls",   
            "Resource": "*",   
            "Effect": "Deny"   
        }   
    ]   
} 

منع مستخدمي IAM ومفاتيح الوصول

لقد كتبت سلسلة مدونات من 3 أجزاء حول كيفية التخلص من مفاتيح الوصول إلى AWS وما هي البدائل الأفضل. كملخص موجز: مفاتيح الوصول لا تنتهي صلاحيتها مطلقًا ويمكن أن ينتهي بها الأمر في أماكن لا ينبغي لها وضعها، حيث يجدها المهاجمون. يجب عليك استخدام أدوار IAM بدلاً من مستخدمي IAM.

يمكنك منع إنشاء مستخدمي IAM، بالإضافة إلى أي مفاتيح وصول للمستخدمين الحاليين، باستخدام SCP التالي:

{  
    "Version": "2012-10-17",  
    "Statement": {  
        "Effect": "Deny",  
        "Action": ["iam:CreateAccessKey", "iam:CreateUser", "iam:CreateLoginProfile"],  
        "Resource": "*"  
    }  
} 

منع IMDSv1

تحصل مثيلات EC2 على بيانات الاعتماد الخاصة بها لأدوار IAM الخاصة بها من خلال خدمة بيانات تعريف المثيل (IMDS). IMDSv2 هو الإصدار الأحدث والأكثر أمانًا من هذه الخدمة، والذي يخفف من مخاطر SSRF (تزوير الطلب من جانب الخادم) وبعض الهجمات الأخرى. ولذلك ينبغي منع الإصدار الأقدم، IMDSv1. يأتي SCP التالي من أمثلة AWS SCP هنا، ويفرض IMDSv2 عن طريق منع استخدام IMDSv1. لسوء الحظ، فإن الإنشاء الافتراضي لمثيلات EC2 من واجهات برمجة التطبيقات (API) هو السماح لـ IMDSv1 لذلك قد يكون من الصعب نشر SCP هذا.

{ 
    "Version": "2012-10-17", 
    "Statement":  
    [ 
        { 
            "Effect":"Deny", 
            "Action":"ec2:RunInstances", 
            "Resource":"arn:aws:ec2:*:*:instance/*", 
            "Condition":{ 
                "StringNotEquals":{ 
                    "ec2:MetadataHttpTokens":"required" 
                } 
            } 
        }, 
        { 
            "Effect":"Deny", 
            "Action":"ec2:RunInstances", 
            "Resource":"arn:aws:ec2:*:*:instance/*", 
            "Condition":{ 
                "NumericGreaterThan":{ 
                    "ec2:MetadataHttpPutResponseHopLimit":"3" 
                } 
            } 
        }, 
        { 
            "Effect":"Deny", 
            "Action":"*", 
            "Resource":"*", 
            "Condition":{ 
                "NumericLessThan":{ 
                    "ec2:RoleDelivery":"2.0" 
                } 
            } 
        }, 
        { 
            "Effect":"Deny", 
            "Action":"ec2:ModifyInstanceMetadataOptions", 
            "Resource":"*" 
        } 
    ] 
} 

تعرف على المزيد حول أفضل ممارسات أمان AWS

تقييد تعديلات الشبكة

أحد مخاطر السحابة هو سهولة إتاحة الموارد للعامة في بيئة افتراضية. لمنع الوصول إلى الموارد عبر الشبكة عبر الإنترنت، تقوم بعض المؤسسات بتحديد المستخدمين الذين يمكنهم إعداد بيئات الشبكة. ولتحقيق ذلك، يتم إعداد الحسابات بمنطقة هبوط أولية توفر لها VPC حيث يمكن إنشاء الموارد ولا تحتوي على عناوين IP عامة. يتصل VPC هذا بحساب شبكة منفصل ومخصص. قد يتم ذلك من خلال نظير VPC، أو مشاركة VPC من خلال ذاكرة الوصول العشوائي (RAM)، أو بوابة النقل، أو حلول أخرى.

والنتيجة هي أن لديك حسابًا واحدًا حيث يتم إجراء التكوينات لكشف الموارد الموجودة على الشبكة وإنشاء مراقبة الشبكة أو دفاعاتها. وكجزء من هذا، ستحتاج إلى تطبيق SCP على الحسابات الأخرى لمنعهم من إنشاء مساراتهم الخاصة إلى الإنترنت. توفر AWS إرشاد حول كيفية تحقيق ذلك، باستخدام SCP:

{ 
    "Version": "2012-10-17", 
    "Statement": 
    { 
        "Effect": "Deny", 
        "Action": [ 
            "ec2:AttachInternetGateway", 
            "ec2:CreateInternetGateway", 
            "ec2:CreateEgressOnlyInternetGateway", 
            "ec2:CreateVpcPeeringConnection", 
            "ec2:AcceptVpcPeeringConnection", 
            "globalaccelerator:Create*", 
            "globalaccelerator:Update*" 
        ], 
        "Resource": "*" 
    } 
} 

فرض تشفير EBS

تكون وحدات تخزين EBS (محركات الأقراص الثابتة لمثيلات EC2) غير مشفرة بشكل افتراضي في حالة عدم النشاط. يمكن تشفيرها عن طريق تمكين ميزة على مستوى المنطقة، والتي ستؤدي إلى تشفير وحدات تخزين EBS المستقبلية، ولكن ليس وحدات التخزين الحالية.

لتمكين هذه الميزة، في جميع المناطق وفي جميع الحسابات، قم بتشغيل ما يلي، مع تغيير المنطقة في كل مرة:

aws ec2 enable-ebs-encryption-by-default --region 'us-east-1' 

SCP التالي هو متاح بواسطة AWS لمنع تعطيل هذه الميزة:

{  
    "Version": "2012-10-17",  
    "Statement":  
    { 
        "Effect": "Deny", 
        "Action": [ 
            "ec2:DisableEbsEncryptionByDefault" 
        ], 
        "Resource": "*" 
    } 
} 

تقييد وصول المسؤول باستخدام عناصر التحكم في الشبكة

يجب أن يكون وصول المسؤول محدودًا قدر الإمكان في بيئات الإنتاج أو في أي مكان قد توجد فيه بيانات حساسة. يجب استخدام البنية التحتية كرمز وعمليات مراجعة، ويجب أن تكون الحالات التي يحتاج فيها الإنسان إلى الوصول المباشر نادرة. عندما يحدث ذلك، يمكن لموفري الهوية فرض ضوابط مختلفة للمصادقة، ولكن الكثير منهم ما زالوا يجدون أن شبكات VPN مفيدة لمزيد من التحكم. يمكن استخدام SCP التالي لفرض أنه لا يمكن استخدام دور محدد يسمى “admin” إلا من عنوان IP 1.2.3.4:

{ 
    "Version": "2012-10-17", 
    "Statement": { 
        "Effect": "Deny", 
        "Action": "*", 
        "Resource": "*", 
        "Condition": { 
            "NotIpAddress": { 
                "aws:SourceIp": ["1.2.3.4/32"] 
            }, 
            "Bool": {"aws:ViaAWSService": "false"}, 
            "ArnLike": { 
                "aws:PrincipalARN": [ 
                    "arn:aws:iam::*:role/admin" 
                ] 
            } 
        } 
    } 
} 

نعتقد أن التعديلات على حسابات AWS وSCPs المعروضة في هذه المقالة تمثل تحسينات أمنية يجب على جميع المؤسسات التفكير في تنفيذها. على الرغم من أن إضافة أي SCP إلى بيئة ما يمثل خطرًا على إتلاف البيئة، فقد حاولنا تقييد أنفسنا بقيود أعلى على عائد الاستثمار والتي لا تتطلب تغييرات هيكلية. للمتابعة أكثر، نوصي بالنظر في تنفيذ محيط البيانات، وSCPs التي توفرها AWS لذلك هي هنا.