هاست ابری امن برای داده حساس؛ ارزیابی، کنترل و Exit

یک ارائه‌دهنده می‌تواند دیتاسنتر و Hypervisor خود را امن نگه دارد، اما یک دسترسی Administrator بدون MFA، Bucket عمومی یا Backup غیرقابل‌بازیابی همچنان داده شما را افشا یا نابود می‌کند. انتخاب «هاست ابری امن» با مقایسه چند لوگو یا Uptime تمام نمی‌شود؛ باید بدانید چه داده و Workloadی دارید، چه تهدیدی محتمل است، هر کنترل با چه کسی است و چه Evidenceای شکست و بازیابی را اثبات می‌کند.

این راهنما برای CTO، CISO، تیم زیرساخت/DevOps، Privacy، Procurement و Founder نوشته شده است. از طبقه‌بندی داده و Shared Responsibility تا IAM، رمزنگاری و کلید، شبکه، Logging، Backup، Incident، قرارداد، Exit و Pilot را پوشش می‌دهد و ریسک‌های عملی استفاده سازمان ایرانی از سرویس داخلی یا خارجی را جداگانه می‌سنجد. برای الزامات قانونی یا بخشی، دامنه را با مشاور واجدصلاحیت همان حوزه تطبیق دهید.

هاستینگ ابری امن یعنی چه؟

امنیت Cloud یک ویژگی بله/خیر نیست. باید احتمال و اثر دسترسی غیرمجاز، تغییر، حذف، اختلال و از دست‌رفتن کنترل داده را تا سطح پذیرفتنی سازمان کاهش دهد و توان کشف، پاسخ و بازیابی داشته باشد. NIST Cybersecurity Framework 2.0 این چرخه را در شش Functionِ Govern، Identify، Protect، Detect، Respond و Recover سازمان می‌دهد.

بنابراین Provider خوب نیز بدون پیکربندی، عملیات و حاکمیت مشتری کافی نیست. از سوی دیگر، تیم مشتری نمی‌تواند ضعف فیزیکی، Hypervisor، Control plane یا فرایند Incident ارائه‌دهنده را جبران کند. امنیت حاصل قرارداد دقیق این دو سمت است.

اول Data و Workload Contract بنویسید

پیش از دریافت پیشنهاد، دامنه را روشن کنید. «داده حساس» عنوان کافی نیست؛ نوع داده، Subject، حجم، محل، جریان، عمر، دسترسی، اثر افشا/تغییر/حذف و نیاز بازیابی را ثبت کنید.

Data residency با Data location یکی نیست

Primary database تنها محل داده نیست؛ Backup، Log، Support attachment، Analytics، CDN، Crash dump و Subprocessor را نیز نقشه کنید. الزامات محل نگهداری و انتقال را بر اساس قرارداد، قانون قابل اعمال و Risk واقعی تعیین کنید؛ این مقاله حکم عمومی درباره مجازبودن یک کشور یا Provider صادر نمی‌کند.

Threat Model را به Control تبدیل کنید

تهدیدها را برای همان Architecture مدل کنید: Credential theft، Privilege abuse، Misconfiguration، Vulnerable workload، Supply-chain compromise، Tenant isolation failure، Data exfiltration، Ransomware، Region outage، Provider account suspension و Insider. سپس هر Threat را به Prevent/Detect/Respond/Recover، Owner و Evidence وصل کنید.

Risk scenario: مهاجم Credential مدیر را می‌گیرد
Prevent: phishing-resistant MFA + conditional access + least privilege
Detect: impossible-travel / privilege-change alert
Respond: revoke session + disable identity + rotate secrets
Recover: break-glass access + verified config restore
Evidence: IdP log, cloud audit log, exercise record

مدل مسئولیت مشترک را در سطح سرویس بنویسید

جمله «Provider امنیت خود ابر و مشتری امنیت داخل ابر» برای قرارداد کافی نیست. مسئولیت با IaaS، PaaS، SaaS و حتی هر Managed service تغییر می‌کند. راهنمای Cloud Controls Matrix ۴.۱ از CSA کنترل‌ها را با مالکیت معمول Provider، Customer یا Shared برای مدل‌های مختلف بررسی می‌کند؛ آن را برای سرویس واقعی Tailor کنید.

عبارت «Shared» بدون RACI خطرناک است. برای هر Control بنویسید چه کسی پیکربندی، اجرا، پایش، Evidence، Incident و Remediation را بر عهده دارد.

گواهی را Evidence بدانید، نه تضمین

ISO/IEC ۲۷۰۰۱، SOC report، PCI DSS یا ارزیابی‌های دیگر می‌توانند شواهد مهمی باشند، اما Scope، تاریخ، Auditor، Exception و سرویس‌های تحت پوشش را بخوانید. گواهی شرکت مادر یا یک Region ممکن است سرویس شما را پوشش ندهد. SOC ۲ Type II نیز گزارش کنترل‌ها در یک دوره و دامنه مشخص است، نه مهر امنیت مطلق.

Evidence pack پیشنهادی

• Audit/attestation جاری با Scope و Exception؛
• Shared-responsibility matrix سرویس؛
• Architecture و Data-location/Subprocessor list؛
• Pen-test summary و Vulnerability/patch policy؛
• Incident notification و نمونه Postmortem قابل اشتراک؛
• BC/DR summary، Restore/failover evidence و Dependency؛
• Security advisory، Status history و SLA performance؛
• Data export/deletion و Contract exit procedure.

IAM را نخستین Hard Gate قرار دهید

SSO/Federation، MFA مقاوم در برابر Phishing در نقش‌های حساس، Least privilege، جداسازی وظایف، JIT/JEA، Access review و Lifecycle ورود/تغییر/خروج را بررسی کنید. Account مشترک، API key بلندعمر، Root روزمره و دسترسی Support بدون Approval/Log باید Red flag باشند.

انسان، Workload و Break-glass را جدا کنید

Service identity نباید از Secret شخصی یا Credential ثابت در Code استفاده کند. Workload identity، Secret manager، Rotation و Scope حداقلی بسازید. Break-glass account باید محدود، خارج از مسیر Failure معمول، با Alert فوری و Drill دوره‌ای باشد؛ «حساب اضطراری» بدون تست ممکن است هنگام حادثه قفل باشد.

Zero Trust اعتماد ضمنی بر پایه Location شبکه را کافی نمی‌داند. NIST SP 800-207A برای Cloud-native، Identity کاربر و Service و Policy گرانولار را محور می‌گیرد؛ برای پیاده‌سازی مرحله‌ای، راهنمای Zero Trust مایندیو را ببینید.

Landing Zone و Guardrail پیش از Migration

ساختار Organization/Account/Project/Subscription، محیط Prod/Non-prod، Billing، Identity، Network، Log archive، Security account، Backup و Policy-as-code را از ابتدا طراحی کنید. Guardrail باید Public exposure، Region نامجاز، Encryption خاموش، Log غیرفعال و Resource بدون Owner/Tag را Prevent یا سریع Detect کند.

minimum resource policy
- owner + workload + environment + data_class tags
- approved region and service
- no public endpoint by default
- encryption and log destination required
- backup policy by tier
- exception_id + expiry for every waiver

رمزنگاری را با Key ownership کامل کنید

TLS در انتقال و Encryption at rest ضروری‌اند، اما سؤال اصلی این است: کلید کجا، تحت اختیار چه کسی، با چه Policy، Rotation، Audit، Backup و Revocationی مدیریت می‌شود؟ اگر همان Administrator هم Data و هم Key policy را کنترل کند، جداسازی دفاع ضعیف است.

راهنمای مدیریت کلید NIST بر Lifecycle و حفاظت Keying material تمرکز دارد. قبل از انتخاب BYOK/HYOK، سناریوی از دست‌رفتن Key، تعطیلی حساب، Restore و جداسازی Duty را تمرین کنید.

شبکه را لایه مکمل Identity بدانید

Private endpoint، Segmentation، Egress control، DNS security، Firewall و محدودکردن Management plane سطح حمله را کاهش می‌دهند، اما Subnet امن جای Authorization را نمی‌گیرد. جریان‌های ورودی و خروجی را Allowlist کنید، اتصال Hybrid را با Route/DNS/Certificate تست کنید و East-west traffic را بی‌دلیل باز نگذارید.

DDoS، WAF و Bot control مرزهای متفاوت دارند

ظرفیت جذب L3/L4، حفاظت L7، Rate limit، WAF rule و Business-logic abuse را در یک عنوان «DDoS protection» ادغام نکنید. Scope، سقف، Always-on/On-demand، زمان Mitigation، Log access، هزینه در Attack و نقش تیم شما را در RFP بنویسید.

Workload امن فقط وظیفه Provider نیست

OS و Container base image، Dependency، Secret، CI/CD، IaC، API، WAF و Runtime باید Secure lifecycle داشته باشند. Provider ممکن است Managed Kubernetes یا Function runtime را Patch کند، اما Vulnerable library و Excessive permission در Image/Function شما باقی می‌ماند.

Risk tier، Paved road، SAST/SCA/IaC scan، Artifact provenance، Finding SLA و Exception expiry را در Delivery workflow قرار دهید. راهنمای DevSecOps این چرخه را از Build تا Evidence و Feedback شرح می‌دهد.

Configuration drift را پیوسته کشف کنید

Snapshot ارزیابی روز خرید کافی نیست. Resource inventory، CSPM/Policy engine، Drift detection و Change log باید Public access، IAM escalation، Encryption/Log disable، Security-group exposure و Resource ناشناس را پایش کنند. Auto-remediation را فقط برای اقدام‌های کم‌خطر و تست‌شده فعال کنید؛ در بقیه موارد Ticket و Owner/Deadline لازم است.

Logging را برای سؤال Incident طراحی کنید

Control-plane audit، Identity، Data access، Network، DNS، WAF، KMS، Workload و Backup event را بر اساس Threat model جمع کنید. Log باید زمان هماهنگ، Actor، Resource، Action، Result، Source و Correlation ID داشته باشد. Retention را با نیاز Investigation و هزینه متناسب کنید.

Log امنیتی را به همان Account/Privilege قابل‌حذف توسط مهاجم محدود نکنید. Export/immutability و دسترسی تیم پاسخ را پیش از بحران تست کنید.

Detection باید Action و Owner داشته باشد

انباشت Alert بدون Runbook امنیت نیست. برای Use caseهای Credential misuse، Privilege change، Public exposure، Exfiltration، Key disable، Log tamper و Backup delete، Severity، Threshold، On-call، Context، Containment و False-positive review بنویسید.

Alert → validate → scope → contain → preserve evidence
      → eradicate → recover → communicate → lessons learned

هر مرحله: owner + time target + authority + evidence

Backup را از Availability جدا کنید

Replication خطای منطقی یا Ransomware را سریع تکثیر می‌کند؛ Snapshot نیز لزوماً Backup مستقل نیست. نسخه خارج از Failure domain و ترجیحاً با Immutability/جداسازی دسترسی، Catalog، Encryption و Retention داشته باشید. مهم‌تر از «روزانه» بودن، توان Restore به RPO/RTO توافق‌شده است.

Restore باید شامل Data، Config، Secret/Key dependency، DNS، Queue و ترتیب سرویس‌ها باشد. برای Runbook، Drill و Reconciliation به راهنمای Backup و بازیابی فاجعه مراجعه کنید.

Availability، Resilience و SLA یکی نیستند

SLA معمولاً تعهد قراردادی و Service credit دارد؛ SLO هدف عملیاتی شماست. درصد Uptime بدون Window، Scope، Exclusion و Dependency معنای کمی دارد. معماری Multi-AZ/Region نیز فقط وقتی Resilient است که Data consistency، Failover، Quota، DNS، Dependency و بازگشت به Primary تست شده باشند.

99.9% availability ≈ 43.8 minutes downtime in a 30.4-day month
اما محاسبه واقعی به تعریف Provider، Window و Exclusion بستگی دارد.

Service credit جای Loss business نیست. BIA تعیین کند چه جریان‌هایی High availability، Warm standby یا Restore ساده می‌خواهند.

Incident Response را با Provider مشترک تمرین کنید

در قرارداد و Runbook مشخص کنید چه کسی Incident را اعلام می‌کند، زمان Notification چیست، چه Log/Evidenceای قابل دریافت است، Support severity چگونه Escalate می‌شود، Snapshot forensic با چه Authorizationی گرفته می‌شود و ارتباط مشتری/نهاد چگونه مدیریت می‌شود.

Tabletop سناریویی انجام دهید

سناریوهای Admin compromise، Public object، Ransomware، Region outage و Account suspension را تمرین کنید. آیا خارج از پنل Cloud راه تماس دارید؟ اگر SSO یا شبکه قطع شود، Break-glass کار می‌کند؟ آیا تیم می‌تواند Key/Token را بدون نابودکردن Evidence Rotate کند؟

حریم خصوصی و Lifecycle داده را عملیاتی کنید

Purpose، Minimum data، Role، Destination، Retention، Delete و Subject request را به Resource و Dataset وصل کنید. «Encryption» مجوز جمع‌آوری نامحدود یا نگهداری بی‌پایان نیست. برای Data map، سناریوی Risk و بودجه کنترل‌ها، راهنمای بودجه حریم خصوصی را ببینید.

Deletion باید Primary، Replica، Search index، Cache، Log و Backup را بر اساس Policy پوشش دهد و محدودیت فنی را صادقانه ثبت کند. Subprocessor change و Model/AI use of data نیز در Contract و Monitor باشد.

پرداخت و داده کارت Scope جدا می‌خواهند

برون‌سپاری Payment processor مسئولیت ارزیابی طرف ثالث را خودکار حذف نمی‌کند. PCI SSC در راهنمای برون‌سپاری پردازش پرداخت بر قرارداد مسئولیت و پایش وضعیت Provider تأکید می‌کند. Scope واقعی را با Acquirer/نهاد پذیرنده Compliance تعیین کنید؛ این متن تأیید انطباق نیست.

امنیت فیزیکی را با Scope و Evidence بسنجید

کنترل ورود، Visitor، CCTV، Media destruction، برق، Cooling و Fire suppression مهم‌اند، اما فهرست ویژگی کافی نیست. بپرسید کدام Facility/Region در Scope Audit است، Media چگونه Sanitized می‌شود، Staff/contractor access چه Approval و Logی دارد و حادثه فیزیکی چگونه به مشتری اطلاع داده می‌شود.

قرارداد و SLA باید Security schedule داشته باشد

SLA را با مشاور حقوقی و Ownerهای فنی/امنیتی مرور کنید؛ وعده Marketing وارد Runbook نمی‌شود مگر در قرارداد و تست Evidence داشته باشد.

Exit و Portability را پیش از ورود تست کنید

Export یک فایل ناقص معادل Exit نیست. Data، Schema، Relation، Permission، Key، Object version، Log، IaC، Container image و Dependency را Inventory کنید. Restore در محیط جایگزین را با Sample نماینده تست و زمان/هزینه را ثبت کنید.

در انتخاب Hyperscaler یا مدل Hybrid، تفاوت Region، Managed service، Skill، Support و Exit را با راهنمای مقایسه AWS، Azure و Google Cloud بسنجید؛ نام برند جای Workload fit و Eligibility را نمی‌گیرد.

ریسک‌های ویژه سازمان ایرانی

Eligibility، حساب و پرداخت

پیش از معماری، شرایط استفاده، KYC، کشور/نوع سازمان مجاز، روش پرداخت و ریسک تعلیق را مستند و با مرجع رسمی Provider/مشاور بررسی کنید. از هویت یا روش پرداخت نامعتبر برای دورزدن Rule استفاده نکنید؛ این کار Access و بازیابی داده را شکننده می‌کند.

دسترسی عملیاتی

Console، API، Registry، Package source، Support و Status page را از چند ISP و مسیر مجاز تست کنید. Artifact و Dependency لازم برای Recovery را در مخزن کنترل‌شده و مجاز نگه دارید. تیم On-call باید Channel جایگزین و Runbook آفلاین داشته باشد.

Location و پشتیبان مستقل

برای Workload و داده، الزام محل، Latency، اتصال کاربر ایرانی، امکان Support، ظرفیت بازیابی و خطر Failure مشترک را بسنجید. «داخلی» یا «خارجی» به‌تنهایی حکم امنیت نیست. Backup مستقل باید از نظر Contract، Encryption، Key و Restore واقعاً قابل استفاده باشد.

نرخ ارز و بودجه امنیت

Log ingestion، Egress، KMS request، WAF/DDoS، Backup، Security tooling و Support می‌توانند هزینه متغیر ارزی داشته باشند. حذف کورکورانه Log یا Backup برای کنترل قبض، Risk را پنهان می‌کند. با راهنمای مدیریت هزینه کلود Budget/Quota/Anomaly و با راهنمای بودجه امنیت کنترل‌ها را Risk-based اولویت‌بندی کنید.

TCO امنیت Cloud را کامل حساب کنید

Cloud security TCO
= provider/service + IAM/SSO + KMS/HSM + network controls
+ logs/SIEM + backup/DR + scanners + support
+ people/training + audit/compliance + incident reserve
+ migration + portability/exit tests

ارزان‌ترین Plan ممکن است Log، SSO، Private access یا Support لازم را Paywall کند؛ گران‌ترین نیز کنترل اشتباه شما را جبران نمی‌کند. Loss range سناریو را با هزینه کنترل مقایسه کنید. راهنمای هزینه نقض داده برای BIA، Residual risk و Reserve مفید است.

فرایند انتخاب Provider در شش Gate

1. Eligibility: کشور، حساب، Contract، Workload و Support قابل اتکا است؟
2. Data/Threat: Classification، Flow، BIA و Threat model کامل است؟
3. Control/Evidence: CCM/RACI، Audit scope و Gapها روشن‌اند؟
4. Architecture: Landing zone، IAM، Key، Network، Log و Backup طراحی شده‌اند؟
5. Pilot: Misconfiguration، Incident، Restore، Failover و Export تست شده‌اند؟
6. Decision: Residual risk، TCO، Owner، Exception و Exit تصویب شده‌اند؟

Pilot امنیتی چه چیزهایی را امتحان کند؟

یک Dataset غیرواقعی اما نماینده، Roleهای واقعی و مسیر کامل Deploy بسازید. دسترسی غیرمجاز، Public exposure، Key revoke، Secret rotation، Alert، Log export، Backup restore، Region/Service failure، Support escalation و خروج داده را تست کنید. Finding باید Owner، Severity، Deadline و Retest داشته باشد.

پس از خرید، Continuous Assurance لازم است

Quarterly/continuous access review، Drift، Backup test، Alert tuning، Dependency/patch، Provider advisory، Audit expiry، Subprocessor change، Incident exercise، Cost anomaly و Exit sample را زمان‌بندی کنید. Control بدون Evidence جاری، صرفاً ادعاست.

اشتباه‌های رایج در انتخاب هاست ابری امن

• Cloud ذاتاً امن‌تر است: Architecture و Control outcome را مقایسه کنید.
• برند بزرگ تضمین می‌دهد: Scope سرویس و مسئولیت مشتری را بخوانید.
• گواهی = انطباق شما: Data flow، پیکربندی و Evidence داخلی باقی می‌ماند.
• Encryption کافی است: IAM، Key lifecycle، Detection و Recovery را اضافه کنید.
• Replication = Backup: نسخه مستقل و Restore drill بسازید.
• Uptime SLA = Resilience: Dependency و Failover واقعی را تست کنید.
• Multi-cloud پیش‌فرض: پیچیدگی، Skill، Consistency و TCO را بسنجید.
• خرید بدون Exit: Export/Restore و Account suspension را پیشاپیش تمرین کنید.

چک‌لیست نهایی انتخاب هاستینگ ابری برای داده حساس

• Data inventory/class/flow/retention و BIA تأیید شده است.
• Threatها به Control، Owner و Evidence نگاشت شده‌اند.
• Shared-responsibility matrix در سطح هر سرویس امضا شده است.
• Audit report با Scope/Exception/تاریخ بررسی شده است.
• SSO، MFA قوی، Least privilege، JIT و Break-glass تست شده‌اند.
• Key ownership/rotation/revocation/recovery و Separation روشن است.
• Landing zone، Network/Egress و Policy-as-code Guardrail دارند.
• Logهای لازم خارج از Failure domain قابل تحلیل‌اند.
• Backup مستقل و Restore end-to-end به RTO/RPO رسیده است.
• Incident/SLA/Subprocessor/Suspension/Exit در Contract آمده است.
• Eligibility، پرداخت، دسترسی و Recovery ایران آزموده شده‌اند.
• Pilot، Gap، Residual risk، TCO و Continuous assurance Owner دارند.

جمع‌بندی: بهترین Cloud برای داده حساس، Provider مشهورتر یا ارزان‌تر نیست؛ گزینه‌ای است که با Workload شما Eligible باشد، مسئولیت‌ها و Evidence آن شفاف باشند و تیم بتواند پیکربندی، تشخیص، پاسخ، Restore و Exit را واقعاً اجرا کند. تصمیم را از Data/Threat شروع کنید و قرارداد را با Pilot شکست، نه با Demo موفق، اعتبارسنجی کنید.

پرسش‌های متداول

آیا هاست ابری ذاتاً از هاست اشتراکی امن‌تر است؟

پاسخ مطلق ندارد. Cloud می‌تواند Isolation، IAM، Logging و Automation قوی‌تری ارائه کند، اما Misconfiguration یا Credential ضعیف همچنان خطرناک است. معماری، Service model، مسئولیت، عملیات و Evidence دو گزینه را برای Workload واقعی مقایسه کنید.

مدل مسئولیت مشترک در امنیت Cloud چیست؟

یعنی Provider و Customer هر دو کنترل‌هایی دارند و مرز با IaaS/PaaS/SaaS و سرویس خاص تغییر می‌کند. به‌جای جمله کلی، ماتریس RACI برای IAM، Patch، Data، Key، Log، Backup، Incident و Compliance بنویسید.

آیا ISO ۲۷۰۰۱ یا SOC ۲ امنیت داده را تضمین می‌کند؟

خیر. این‌ها Evidence ارزشمند درباره کنترل‌ها در Scope و دوره مشخص‌اند. سرویس، Region، Exception و مسئولیت مشتری را بررسی کنید و کنترل‌های خودتان را جداگانه پیاده و آزمون کنید.

BYOK برای هر داده حساسی لازم است؟

نه همیشه. Customer-managed key کنترل و Audit بیشتری می‌دهد، اما هزینه، Availability و خطر Lockout را بالا می‌برد. Threat model، الزام، جداسازی Duty و سناریوی Recovery تعیین می‌کنند Provider-managed، BYOK یا مدل خارجی مناسب است.

مهم‌ترین تست پیش از انتقال داده حساس چیست؟

یک تست واحد کافی نیست. Access منفی، Misconfiguration، Alert، Key/secret rotation، Backup restore، Incident escalation و Export/Exit را با Dataset غیرواقعی اما نماینده اجرا کنید؛ Findingها را اصلاح و Retest کنید.