الشركات معقدة ، وتتطلب إعدادًا أكبر بكثير لإدارة حسابات AWS لمئات الأشخاص. في هذه المقالة ، نناقش أفضل الممارسات لإدارة الوصول الآمن إلى موارد مؤسستك دون إعاقة مطوريك بالبيروقراطية.
استخدم مستخدمي IAM لحسابات الموظفين
إذا كنت قد استخدمت AWS من قبل ، فمن المحتمل أنك على دراية بمستخدمي IAM. إنها حسابات خدمة تستخدم بشكل أساسي لمصادقة الأشياء التي تعمل على الخوادم البعيدة والسماح لهم بالوصول إلى موارد AWS التي يحتاجون إليها (وضع الأشياء في حاوية S3 وتشغيل وظائف lambda وما إلى ذلك.) دون إعطاء حق الوصول الكامل إلى حسابك الرئيسي. بهذه الطريقة ، إذا تم اختراق خوادمك (من قبل متسلل أو موظف محتال) ، فإن الدخيل لديه حق الوصول فقط إلى الأذونات التي منحتها.
مستخدمو IAM رائعون ، ومفيدون أيضًا لمنح الموظفين إمكانية الوصول إلى الخدمات التي يحتاجونها. عند إنشاء مستخدم IAM ، يكون لديك خيار تمكين الوصول إلى وحدة التحكم الإدارية (على عكس وصول CLI / API) ، مما يمكّنك من منح الحساب لموظف والسماح له بالوصول إلى وحدة التحكم الإدارية بأذونات مقيدة. يمكنك حتى تمكين المصادقة متعددة العوامل (MFA) لمستخدمي IAM من خلال الوصول إلى وحدة التحكم ، مما يجعلها آمنة للغاية.
المشكلة الرئيسية ، مع ذلك ، هي أن الموظفين الذين يستخدمون حسابات IAM لن يكونوا قادرين على إنشاء مستخدمي IAM الخاص بهم دون مساعدة من حساب الجذر. إذا كان لديك مدير مشروع يحتاج إلى منح وصول آمن لـ S3 PUT إلى أحد التطبيقات ، فعليه أن يطلب من صاحب الحساب الجذر إنشاء مستخدم IAM جديد بالكامل خصيصًا لهذا الإذن.بالنظر إلى أن صاحب الحساب الجذر عادة ما يكون المالك ، أو رئيس قسم التكنولوجيا ، أو شخص رفيع المستوى ، فإن ذلك يعد إهدارًا كبيرًا للوقت ، خاصة إذا كنت لا تلمس الإنتاج.
خلاف ذلك ، فإن مستخدمي IAM هم الطريق الذي يجب اتباعه لمنح وصول مُدار إلى خدمات معينة. يمكنك إنشاء مجموعات IAM ، والتي تكون مفيدة لتخطيط الأذونات التي يمتلكها كل دور في مؤسستك. مهما فعلت ، تذكر فقط مبدأ "الأذونات الأقل" - يجب أن يمتلك كل حساب الأذونات التي يحتاجها فقط للقيام بعمله بفعالية ، لا أكثر. تأكد أيضًا من عدم منح IAM حق الوصول إلى مستخدمي IAM ، أو يمكنهم تصعيد الامتيازات.
فصل بيئات التطوير والإنتاج
الحل لمشكلة تنوع الأمان هو مؤسسات AWS. تُمكّنك هذه الخدمة من إدارة عدة حسابات مختلفة ضمن حساب جذر واحد ، مع استكمال الفوترة الموحدة (يدفع المستخدم الجذر لكل حساب طفل).
الحد الافتراضي هو أربعة حسابات ، مما يجعل المؤسسات غير قابلة للاستخدام كحسابات موظفين فردية.لن يكون من المنطقي القيام بذلك على أي حال ، لأن كل حساب منفصل عن الحسابات الأخرى ، ولن تتمكن من رؤية الخدمات أو الخوادم التي تم إطلاقها في حسابات أخرى. يمكنك طلب زيادة الحد إذا كنت بحاجة إلى المزيد من البيئات ، لكن AWS تريد منك استخدام مستخدمي IAM للموظفين.
ما تهدف إليه مؤسسات AWS هو الفصل بين بيئات التطوير والإنتاج. تنطبق قواعد مختلفة على كل بيئة ؛ على سبيل المثال ، قد ترغب في تقييد الموظفين من إنشاء مستخدمي IAM جدد دون المرور عبر جميع القنوات المناسبة والتشاور مع كبار المسؤولين ، ولكن في عملية التطوير ، فإن الاضطرار إلى المرور بكل هذه الفحوصات سيؤدي فقط إلى إبطاء المطورين. يمكنك اختيار منح مديري المشروع حق الوصول إلى حساب التطوير لتمكين الاختبار بشكل أسرع.
فيما يتعلق بالتسلسل الهرمي ، يعمل الحساب الرئيسي كجذر للشجرة ، ويتولى إنشاء حسابات جديدة. يمكن فرز الحسابات في وحدات تنظيمية ، والتي تعمل كمجموعات وتطبق الأذونات لكل حساب تحتها.يمكن دمجها على النحو الذي تراه مناسبًا (حتى إذا كان لديك حسابات كافية للقيام بذلك).
توصية AWS هنا هي على الأرجح كيف يجب أن تبدو مؤسستك. لديك حساب الإنتاج الرئيسي ، وهو آمن للغاية ولا يمكن الوصول إليه بشكل كامل إلا من قبل الإدارة العليا. تعمل بيئة "الاختبار" أو "التدريج" كمرآة للإنتاج ، ويمكن الوصول إليها من قبل مهندسي الجودة وأي شخص آخر يقوم بإجراء الاختبار قبل دفع التغييرات إلى الإنتاج. يمكنك اختيار تقسيم هذه إلى بيئتين منفصلتين: الاختبار مخصص للاختبار الآلي باستخدام بيانات وهمية (وظيفيًا امتداد للتطوير ، ولكنه أكثر نظافة) ، والتقسيم المرحلي هو مرآة كاملة للإنتاج بما في ذلك بيانات العميل والوصول إلى واجهات برمجة التطبيقات العامة الحقيقية.
إذن لديك التطوير ، الذي يمكن الوصول إليه من قبل مديري المشروع والمطورين التابعين لهم.تحتوي هذه البيئة على أذونات أكثر تراخيًا ، نظرًا لأن الأمان العام لها لا يهم بقدر أهمية الإنتاج. يجب ألا تتضمن أي قواعد بيانات تم إنشاؤها أثناء التطوير (أو الاختبار لهذا الأمر) بيانات العملاء.
ربما يعمل معظم مطوريك من حسابات IAM الشخصية في بيئة التطوير ، مما يمنحهم وصولاً أكمل بكثير مما قد يحصلون عليه في الإنتاج. ربما ترغب في منح مطوريك أذونات لاستخدام معظم الخدمات التي تستخدمها في الإنتاج (فقط راقب الأشياء لضمان التحكم في الاستخدام).
تمكّنك الوحدات التنظيمية (OUs) أيضًا من تقييد أذونات كل حساب ، باستخدام سياسات التحكم في الخدمة (SCP). تشبه برامج SCP إلى حد كبير سياسات IAM ، ولكنها مستوى أعلى - تنطبق على الحساب بالكامل تحتها. إذا أنشأ حساب التطوير مستخدم IAM لديه حق الوصول إلى S3 ، ولكن لم يتم تمكين S3 في SCP ، فلن يتمكن مستخدم IAM هذا من استخدام S3 على هذا الحساب. يتم رفض الخدمات افتراضيًا ، لذلك يتعين عليك إدراجها يدويًا في القائمة البيضاء لتتمكن من استخدامها.
يجب أن يكون حساب AWS واحد لكل OU مناسبًا لمعظم التطبيقات ، ولكن لديك خيار إنشاء المزيد. إذا كنت ترغب في الحصول على بيئة تطوير منفصلة لفرق مختلفة ، فيمكنك إنشاء حسابين أو أكثر للتطوير ضمن وحدة تنظيمية واحدة. حتى مع حساب واحد فقط ، لا يزال بإمكانك إدارة الأذونات بقواعد SCP.
راجع بانتظام أمان مؤسستك
إذا كنت تقوم بإعداد مؤسسة في AWS ، فستواجه بسرعة مشكلة الحاجة إلى إجراء فحوصات أمنية منتظمة للتأكد من أن كل شيء آمن. توفر AWS قائمة تحقق للأمان يجب عليك قراءتها والتأكد من امتثالك لكل شيء. حتى شيء بسيط مثل التحقق من وجود كل مستخدم في المكان المناسب يعد ممارسة جيدة.
إذا غادر شخص ما الشركة ، فأنت بحاجة إلى التأكد من إلغاء تنشيط أو تحويل أي حسابات IAM مرتبطة. إذا قام شخص ما بتغيير الأدوار ، فأنت بحاجة أيضًا إلى التأكد من أن سياسات حسابه تعكس هذا الدور ، وأنه ليس لديه أذونات متبقية من الوظائف القديمة.
تحتاج أيضًا إلى التأكد من تعيين أذونات SCP بشكل صحيح لكل وحدة تنظيمية ، وعدم تغييرها كثيرًا بمرور الوقت. أنت لا تريد أن تكون بيئة التطوير قادرة على استئجار 20
c5d.24xlargeمثيل ودفع فاتورتك عبر السقف.
