مدل مسئولیت مشترک AWS (AWS Shared Responsibility Model) چارچوب امنیتی پایهای است که نحوه تقسیم مسئولیتهای امنیتی و انطباق (Compliance) را بین Amazon Web Services و مشتریان آن مشخص میکند. درک این مدل برای هر سازمان در حال مهاجرت به ابر یا فعال در آن حیاتی است، چرا که برداشت اشتباه از نقطه پایان مسئولیت ارائه دهنده ابر و شروع مسئولیت مشتری، همچنان یکی از دلایل اصلی بروز حادثه امنیتی در محیطهای ابری است.
این مدل در هسته خود، بار عملیاتی امنیت را با تقسیم وظایف به دو حوزه اصلی ساده میکند. AWS مسئولیت امنیت OF the cloud را بر عهده میگیرد، در حالی که مشتری مسئول امنیت IN the cloud باقی میماند. با عهدهدار شدن نگهداری، حفاظت و امنیت فیزیکی زیرساخت پایه توسط AWS، سازمانها میتوانند بار عملیاتی سنگینی را از دوش خود بردارند و در عین حال کنترل دقیقی بر روی Applicationها، Data و Access Controlهای خود داشته باشند.
درک این تقسیم کار مستلزم بررسی نحوه تغییر مسئولیتها در Service Modelهای مختلف ابر، نحوه مدیریت Controlهای امنیتی و نحوه عملیاتیسازی این اصول توسط سازمانها برای جلوگیری از Security Blind Spotهای پرهزینه است.
امنیت OF the Cloud: آنچه Amazon Web Services از آن محافظت میکند
امنیت OF the Cloud شامل بخشهای Global Infrastructure است که از تمامی سرویسهای ارائه شده توسط AWS پشتیبانی میکنند. این بخش شامل Hardware، Software، Networking و Data Centerهای فیزیکی است که AWS Cloud Services روی آنها اجرا میشوند. مشتریان نمیتوانند این Assetهای سطح پایین را مستقیماً تغییر داده یا مدیریت کنند، زیرا AWS برای تضمین System Integrity، Availability و Compliance جهانی، کنترل عملیاتی انحصاری آنها را حفظ میکند.
لایه پایه شامل Physical Infrastructure شرکت AWS در Data Centerهای منطقهای، Availability Zoneها و Edge Locationها است. AWS کنترلهای امنیت فیزیکی سختگیرانهای را در این محلها اجرا میکند که شامل Multi-Factor Biometric Access Controls، surveillance ویدئویی ۲۴/۷، سیستمهای Intrusion Detection فیزیکی و ثبت دقیق ورود و خروج بازدیدکنندگان میشود. Hardwareهای فیزیکی به طور مداوم مانیتور میشوند و Storage Deviceهایی که Decommission یا تعویض میشوند، طبق استانداردهای سختگیرانه صنعت مانند NIST 800-88 پاکسازی یا نابود میگردند.
فراتر از سایتهای فیزیکی، AWS لایه Host Infrastructure را مدیریت میکند. این شامل Serverهای فیزیکی دارای Hypervisorهای اختصاصی، لایههای Hardware Virtualization، سیستمهای Storage مانند معماری Host در Amazon S3 و شبکه Global Backbone اتصالدهنده Regionها است. AWS مسئولیت Patch کردن Hypervisorها، حفظ Reliability تجهیزات Host، آپدیت Firmware و جلوگیری از Tamper فیزیکی شبکه یا محافل Tap غیرمجاز روی خطوط ارتباطی را بر عهده دارد.
در نهایت، AWS مجموعه Software پایه اجراکننده سرویسهای Abstract و Managed را مدیریت میکند. هنگام استفاده از Managed Databaseها، Serverless Platformها یا محیطهای Hosted Machine Learning، شرکت AWS مواردی چون Operating System Patching، آپدیتهای Database Engine و نگهداری Runtime Environment را انجام میدهد تا از امن و عملیاتی ماندن لایه Software پایه اطمینان حاصل کند.
امنیت IN the Cloud: آنچه در مالکیت مشتری است
امنیت IN the Cloud نشاندهنده هر آن چیزی است که مشتری در محیط AWS خود Deploy، ذخیره یا Configure میکند. اگرچه AWS امن بودن زیرساخت پایه را تضمین میکند، اما مشتری کاملاً مسئول نحوه پیکربندی، بارگذاری و مدیریت Resourceهای ابری خود باقی میماند. غفلت از وظایف امنیتی سمت مشتری، علت اصلی Data Breach در محیطهای ابری است.
موضوع Data Protection و Encryption بالاترین اولویت را در مسئولیتهای مشتری دارد. سازمانها مالک کامل Data خود هستند، به این معنی که باید Data را Classify کرده، Retention Policyها را تعریف کنند و Encryption را هم در حالت At Rest و هم In Transit پیادهسازی نمایند. AWS ابزارهای Encryption مانند AWS Key Management Service و AWS Secrets Manager را ارائه میدهد، اما خود مشتری باید به طور صریح Encryption Policyها را روی Storage Bucketها، Database Instanceها و Application Volumeها Configure و Enforce کند.
مدیریت Identity and Access Management یکی دیگر از مسئولیتهای اصلی مشتری است. AWS چارچوب اولیه را از طریق AWS IAM فراهم میکند، اما مشتریان باید Policyها را با استفاده از اصل Least Privilege تنظیم کرده، Multi-Factor Authentication را اجباری کنند، Credential Rotation را مدیریت کرده و Role-Based Access Controlها را تعریف نمایند. اگر مشتری دسترسی Public به یک Storage Repository حساس بدهد یا از IAM Policyهای بیش از حد مجاز استفاده کند، AWS همان دستورات پیکربندیشده را اجرا خواهد کرد که منجر به اکسپوز شدن سیستم میشود.
تکالیفی مثل Operating System Configuration، نگهداری Application Software و تنظیم Firewall Ruleهای شبکه نیز در مدلهای Infrastructure as a Service بر عهده مشتری است. مشتریانی که Virtual Machine انتشار میدهند باید Operating System Security Patching را اجرا کنند، Softwareهای Host-Based Intrusion Detection نصب نمایند، Local Firewallها را Configure کرده و امنیت Application Code را حفظ کنند. علاوه بر این، مشتریان باید Security Groupها، Network Access Control Listها (NACL) و Routing Tableها را به درستی تنظیم کنند تا جریان Traffic را هدایت نمایند.
تغییر مسئولیتها در دستهبندیهای مختلف Cloud Service
مرز جداکننده مسئولیتهای مشتری و AWS ثابت نیست؛ این مرز بسته به Service Model انتخابی تغییر میکند. سرویسهای AWS عموماً در سه دسته جای میگیرند: Infrastructure as a Service، Platform as a Service و Software as a Service یا سرویسهای Abstract.
در مدل Infrastructure as a Service، مانند Amazon EC2 یا Amazon VPC، مشتری بیشترین کنترل و در نتیجه بیشترین مسئولیت امنیتی را حفظ میکند. AWS مدیریت Hypervisor، Host فیزیکی و Network Hardware را بر عهده دارد، اما مشتری مسئول همه چیز از Guest Operating System به بالا است. این موارد شامل OS Updateها، Security Patchها، تنظیمات Network Firewall Rule، نصب Application و Data Protection است.
در مدل Managed Service یا Platform as a Service، مانند Amazon Relational Database Service یا AWS Elastic Beanstalk، شرکت AWS سهم بیشتری از بار عملیاتی را به دوش میکشد. به عنوان مثال در Amazon RDS، شرکت AWS مواردی چون Operating System Patching، نصب Database Engine، بکآپهای Automated و نگهداری Host زیرین را مدیریت میکند. مسئولیت مشتری به مدیریت Database Access Controlها، User Accountها، Table Schemaها، Network Access Ruleها و Enforce کردن پارامترهای Encryption تغییر مییابد.
در مدلهای اجرای Containerized و Serverless، مانند AWS Fargate یا AWS Lambda، مسئولیتها باز هم بیشتر به سمت AWS منتقل میشوند. مشتریان نیازی به مدیریت Virtual Serverها، Operating Systemها یا Container Runtimeها ندارند. در عوض، AWS مدیریت Execution Environment، وابستگیهای Operating System و Capacity Scaling زیرین را بر عهده میگیرد. مشتری صرفاً مسئول نوشتن Application Code امن، مدیریت Event Triggerها، تنظیم IAM Execution Roleها و محافظت از Data پردازششده توسط Functionها باقی میماند.
مدیریت Controlهای Shared ،Inherited و Customer-Specific
برای شفافسازی نحوه اجرای امنیت در عمل، Controlهای امنیتی در مدل مسئولیت مشترک به سه گروه عملیاتی تقسیم میشوند: Inherited Controls، Shared Controls و Customer-Specific Controls.
کنترلهای Inherited الزامات امنیتی هستند که مشتری به طور کامل از AWS ارث میبرد. از آنجا که AWS Data Centerهای فیزیکی و Host Systemها را اداره میکند، مشتریان به طور خودکار از Physical Security، Safeguardهای محیطی و Hardware Redundancy تعبیه شده در زیرساخت AWS بهرهمند میشوند. مشتریان نیازی به ساخت Physical Access Control یا نصب Generatorهای برق پشتیبان ندارند؛ این کنترلها از طریق Compliance Reportهای AWS تایید میشوند.
کنترلهای Shared در لایههای مدیریتی کاربرد دارند که در آن هم AWS و هم مشتری الزامات و اجرا را در حوزه مربوط به خود ارائه میدهند. نمونههای کلیدی عبارتند از:
-
مدیریت Patch Management، جایی که AWS اقدام به Patch کردن Hardware Hostها و Hypervisorها میکند، در حالی که مشتری Guest Operating Systemها و Application Softwareها را Patch میکند.
-
مدیریت Configuration Management، جایی که AWS پیکربندی Deviceهای زیرساختی خود را حفظ میکند، در حالی که مشتری Virtual Network Routerها، Firewallها و Operating Systemها را Configure میکند.
-
بخش Awareness and Training، جایی که AWS پرسنل خود را در زمینه امنیت Data Center و Hardware آموزش میدهد، در حالی که مشتریان کارمندان خود را برای Cloud Access امن، رعایت Credential Hygiene و Deployment صحیح Application آموزش میدهند.
کنترلهای Customer-Specific یا کنترلهای هدایتشونده توسط مشتری، تماماً توسط خود مشتری و بر اساس الزامات خاص صنعت، استانداردهای Compliance و میزان Risk Tolerance داخلی پیادهسازی میشوند. این موارد شامل Service and Communications Protection، برنامه Encryption در سطح Application، بخش Network Segmentation با استفاده از Subnetهای اختصاصی و Incident Response Planning متناسب با Workflowهای سازمانی است.
اشتباهات رایج و Security Blind Spotهای خطرناک
با وجود شفافیت این مدل، سازمانها اغلب فرضهایی درباره امنیت ابر میسازند که منجر به Vulnerabilityهای عملیاتی میشود. غلبه بر این تصورات اشتباه برای ساخت یک Cloud Architecture مقاوم ضروری است.
یک تصور غلط فراگیر این است که مهاجرت Workloadها به AWS به طور خودکار آنها را امن و Compliant میکند. اگرچه AWS یک Cloud Foundation امن با Certificationهای متعدد Compliance ارائه میدهد، اما Compliance امری Transitive (انتقالپذیر) نیست. استفاده از یک زیرساخت Compliant در AWS، برنامههای مشتری را به طور خودکار Compliant نمیکند؛ مشتری همچنان باید Access Controlها، Audit Logها و Encryption Protocolها را به درستی پیکربندی کند تا الزامات قانونی برآورده شوند.
غفلت مکرر دیگر مربوط به Data Backup و Disaster Recovery است. مشتریان گاهی فرض میکنند چون AWS قابلیت High Availability و گزینه Multi-AZ Deployment را ارائه میدهد، بکآپگیری از Data به صورت خودکار انجام میشود. در واقعیت، Data Replication در چند Availability Zone از سیستم در برابر Hardware Failure محافظت میکند، نه خطای انسانی، Ransomware یا پاک شدن تصادفی. مشتریان کاملاً مسئول تعریف Backup Policyها، اجرای Periodic Data Snapshotها و تنظیم استراتژیهای Cross-Region Replication هستند.
علاوه بر این، سازمانها اغلب از امنیت API Key و رعایت Hygiene در Access Token غافل میشوند. AWS امنیت Endpointهای Control Plane را تامین میکند، اما اگر یک Developer اقدام به Commit کردن یک AWS Access Key در یک Code Repository عمومی کند، بازیگران غیرمجاز میتوانند از آن Credentialها برای Compromise کردن محیط استفاده کنند. مدیریت Secret Storage، اجباری کردن Short-Lived Session Tokenها و راهاندازی Credential Scanning خودکار کاملاً در سمت مشتری این مرز قرار دارد.
استراتژیهای عملی برای عملیاتیسازی مدل
برای تحقق بخشیدن به وظایف امنیتی مشتری تحت AWS Shared Responsibility Model، سازمانها باید روندهای Governance ساختاریافتهای را پیاده کرده و از Toolingهای امنیتی automated استفاده کنند.
اول، از Automation برای پیکربندیهای امنیتی و Enforce کردن Policyها استقبال کنید. پیکربندی دستی Resourceهای ابری باعث بروز خطای انسانی میشود. استفاده از ابزارهای Infrastructure as Code به تیمها اجازه میدهد Baselineهای زیرساختی امن تعریف کنند، Static Code Analysis روی Templateهای Deployment انجام دهند و اطمینان حاصل کنند هر Resource منتشر شده با استانداردهای امنیتی از پیش تایید شده مطابقت دارد.
دوم، از ابزارهای Native امنیتی و Governance در AWS که برای کمک به مسئولیتهای سمت مشتری طراحی شدهاند استفاده کنید:
-
از AWS IAM Identity Center برای متمرکز کردن Access Management، اجباری کردن Strict Multi-Factor Authentication و حذف Access Keyهای طولانیمدت استفاده کنید.
-
سرویس AWS Config را برای مانیتورینگ مداوم، Audit و ارزیابی Configuration منابع در برابر Guidelineهای Compliance دلخواه Deploy کنید.
-
سرویس AWS CloudTrail را برای Log گرفتن، مانیتورینگ مداوم و نگهداری فعالیتهای Account مربوط به اکشنهای کل زیرساخت AWS فعال کنید.
-
سرویس Amazon GuardDuty را برای Threat Detection هوشمند و مانیتورینگ مداوم AWS Accountها، Workloadها و Data ذخیرهشده در Amazon S3 فعال سازید.
-
از AWS Security Hub برای تجمیع یافتهای امنیتی از چند سرویس AWS و ابزارهای Partner در یک Single Pane of Glass استفاده کنید.
سوم، هنگامی که تواناییهای داخلی یا فشارهای قانونی از ظرفیت تیم فراتر میرود، از دانش تخصصی بیرونی استفاده کنید. همکاری با یک مجموعه تخصصی خارجی، مانند یک ارائه دهنده خدمات مشاوره AWS، میتواند پروژههای Cloud Compliance را سرعت ببخشد، Architecture موجود را برای پیدا کردن Security Gapها Audit کند و چارچوبهای Cloud Governance قوی متناسب با استانداردهای منطقهای و بینالمللی ایجاد نماید.
در نهایت، Third-Party Security Auditها و Penetration Testingهای منظم انجام دهید. در حالی که AWS زیرساخت پایه را تست و Certify میکند، سازمانها باید مرتباً Application Code، Network Security Group Ruleها و IAM Policy Permissionهای خود را Audit کنند تا Vulnerabilityهای جدید را قبل از امکان Exploit شدن شناسایی نمایند.
همراستاسازی Cloud Compliance و مرز مسئولیت
موضوع Regulatory Compliance در ابر نیازمند درک شفافی از نحوه نگاشت Shared Responsibility Model بر روی چارچوبهای صنعتی مانند ISO 27001، SOC 2، PCI DSS و HIPAA است. انطباق یا Compliance یک تلاش مشترک است که در آن مشتریان از Audit Reportهای AWS برای برآورده کردن الزامات سطح زیرساخت استفاده میکنند و در عین حال Evidenceهای خود را برای Controlهای سطح بالاتر ارائه میدهند.
سرویس AWS دسترسی On-Demand به مدارک Compliance را از طریق AWS Artifact برای مشتریان فراهم میکند. از طریق این پورتال، تیمهای امنیتی میتوانند AWS SOC Reportها، PCI DSS Attestations of Compliance و Certificationهای ISO را دانلود کنند. این اسناد به عنوان مدرک رسمی برای Auditorهای خارجی عمل میکنند تا نشان دهند زیرساخت فیزیکی و مجازی پایه، الزامات سختگیرانه قانونی را برآورده میکند.
با این حال، Auditor همچنان نیازمند اثبات Compliance در سمت مشتری خواهد بود. به عنوان مثال تحت PCI DSS، شرکت AWS نشان میدهد که Data Center فیزیکی و Hypervisorها استانداردهای Cardholder Data Environment را دارا هستند. مشتری باید اثبات کند که Payment Applicationهای در حال اجرا روی EC2 Instanceها به صورت امن کدنویسی شدهاند، Cardholder Data با استفاده از Keyهای تحت مدیریت مشتری Encrypt شده است و Access Logها به طور مداوم مانیتور میشوند.
با مستندسازی شفاف تقسیم مسئولیتها در Corporate Security Policyها، سازمانها میتوانند روند Audit را تسهیل کنند، اجراهای تکراری Controlها را حذف نمایند و پوشش کامل را در تمامی حوزههای قانونی تضمین کنند.
بهترین روشهای اصلی برای انجام وظایف مشتری
برای ایجاد یک وضعیت امنیتی قوی و مقاوم در AWS، رهبران امنیتی باید تمرینهای پایهای زیر را در Workflowهای عملیاتی روزانه خود بگنجانند:
-
استانداردسازی بر اساس اصل Least Privilege در تمامی IAM Roleها، Groupها و Service Policyها، تا اطمینان حاصل شود کاربران و Applicationها صرفاً Permissionهای صریح و لازم برای انجام وظایف خود را دریافت میکنند.
-
اجباری کردن Default Encryption در حالت At Rest برای تمامی سرویسهای Storage، شامل Amazon S3 Bucketها، Amazon EBS Volumeها، Amazon RDS Databaseها و DynamoDB Tableها.
-
ایمنسازی دسترسی Network Perimeter با محدود کردن Security Group Ruleها، حذف دسترسیهای Inbound نامحدود از IP Rangeهای عمومی و هدایت ترافیک از طریق Web Application Firewallها.
-
پیادهسازی Centralized Log Management قوی با فعالسازی AWS CloudTrail، VPC Flow Logs و DNS Logها، و ارسال Streamهای Log به یک S3 Bucket امن و ایزوله شده که Object Lock روی آن فعال است.
-
اجرای Vulnerability Management مداوم روی Guest Operating Systemها، Container Imageها و وابستگیهای Application برای شناسایی و Patch کردن نقاط ضعف امنیتی به صورت Proactive.
-
ایجاد و تست یک Incident Response Plan مشخص برای محیطهای ابری، همراه با Workflowهای Automated Containment برای Credentialهای Compromise شده یا Resourceهای اکسپوز شده.
هدایت آینده امنیت ابری و مسئولیتهای AI
همزمان با توسعه سرویسهای AWS در حوزه Generative AI و Platformهای تخصصی Machine Learning مانند Amazon Bedrock و Amazon SageMaker، مدل مسئولیت مشترک نیز به تطبیق خود ادامه میدهد. درک نحوه اعمال مسئولیتها در معماریهای AI به یک الزام حیاتی برای تیمهای تکنولوژی امروزی تبدیل شده است.
در Workloadهای مربوط به Generative AI و Machine Learning، شرکت AWS مسئولیت تامین امنیت زیرساخت پایه، Clusterهای Hardware آموزش، Platformهای میزبانی Foundational Model و معماری Base Modelها را بر عهده میگیرد. AWS تضمین میکند که Data مشتری که همراه با سرویسهایی مثل Amazon Bedrock استفاده میشود Encrypt شده، ایزوله مانده و به طور صریح برای آموزش یا بهبود Base Modelها برای سایر مشتریان استفاده نمیشود.
مؤلفه مشتری همچنان مسئولیت Data Inputها، Fine-Tuning Datasetها، امنیت Prompt Engineering، Validation خروجیها و Access Controlهای سطح Application را حفظ میکند. مشتریان باید اطمینان حاصل کنند که Data حساس ارسالشده به AI Endpointها با Privacy Policyهای داخلی مطابقت دارد، Modelهای اختصاصی Fine-Tune شده با IAM Policyهای سختگیرانه محافظت میشوند و Interfaceهای برنامه از Input Manipulation یا حمله Prompt Injection جلوگیری میکنند.
با حفظ درک شفاف از AWS Shared Responsibility Model همراه با پیشرفت تکنولوژیهای ابری، سازمانها میتوانند با اطمینان روی AWS نوآوری کنند و دقیقاً بدانند چگونه از زیرساخت، برنامه و Assetهای دیجیتال حساس خود محافظت نمایند.
