Zero Trust برای Storage چگونه پیاده‌سازی می‌شود؟

مقدمه

در معماری‌های سنتی امنیت شبکه، معمولاً یک مرز مشخص میان شبکه داخلی و شبکه خارجی تعریف می‌شود و فرض بر این است که کاربران و تجهیزات داخل شبکه تا حد زیادی قابل اعتماد هستند. اما در مدل‌های جدید امنیت سایبری، این فرض دیگر قابل قبول نیست.

Zero Trust بر یک اصل ساده استوار است:

هیچ کاربر، دستگاه، Application یا سرویسی صرفاً به دلیل قرار داشتن در شبکه داخلی، قابل اعتماد نیست.

این رویکرد در سال‌های اخیر از سطح کاربران و Endpointها فراتر رفته و به زیرساخت‌های حیاتی مانند SAN Storage، NAS، Backup Repository، Object Storage و Storage Management Platform نیز رسیده است.

اهمیت این موضوع زمانی بیشتر مشخص می‌شود که بدانیم Storage معمولاً محل نگهداری مهم‌ترین دارایی سازمان است. اگر مهاجم بتواند به Storage Management دسترسی پیدا کند، ممکن است بتواند Volumeها، Snapshotها، Replicationها یا حتی Backupها را حذف کند.

بنابراین پیاده‌سازی Zero Trust در Storage یکی از اجزای مهم معماری امنیتی مدرن Data Center است.

 

Zero Trust در Storage به چه معناست؟

Zero Trust Storage به معنای آن نیست که دسترسی تمام کاربران به Storage را مسدود کنیم.

هدف این معماری، ایجاد دسترسی کنترل‌شده، حداقلی، قابل احراز و قابل نظارت برای هر درخواست است.

در یک معماری Zero Trust، هر درخواست برای دسترسی به Storage بر اساس مجموعه‌ای از عوامل بررسی می‌شود:

• چه کسی درخواست را ارسال کرده است؟
• از چه دستگاهی؟
• از کدام Application؟
• به کدام Storage Resource؟
• با چه سطح دسترسی؟
• در چه زمانی؟
• از چه شبکه‌ای؟
• آیا رفتار کاربر طبیعی است؟
• آیا درخواست با سیاست امنیتی سازمان مطابقت دارد؟

بنابراین حتی اگر کاربر یا مهاجم داخل شبکه سازمان قرار داشته باشد، دسترسی او به Storage به‌صورت خودکار پذیرفته نمی‌شود.

چرا Storage هدف مهمی برای مهاجمان است؟

در حملات باج‌افزاری مدرن، مهاجم معمولاً فقط سرورهای Application را هدف قرار نمی‌دهد.

یکی از اهداف اصلی مهاجم، از بین بردن قابلیت Recovery سازمان است.

برای مثال مهاجم ممکن است تلاش کند:

Production Data → Snapshot → Backup Repository → Replication → Management Server

را هدف قرار دهد.

اگر حساب مدیریتی Storage در اختیار مهاجم قرار گیرد، ممکن است عملیات‌هایی مانند Delete Volume، Delete Snapshot یا تغییر تنظیمات Replication انجام شود.

بنابراین حفاظت از Storage Management Plane به اندازه حفاظت از خود داده اهمیت دارد.

 

معماری Zero Trust Storage

برای پیاده‌سازی Zero Trust بهتر است Storage را حداقل به سه بخش منطقی تقسیم کنیم:

• Data Plane

مسیر واقعی انتقال داده میان Server و Storage.

برای مثال:  ESXi → SAN Switch → Storage

• Management Plane

مسیر مدیریت Storage :

Administrator → Management Network → Storage Controller

• Control Plane

سیستم‌هایی که سیاست‌ها، احراز هویت، مانیتورینگ و مدیریت دسترسی را کنترل می‌کنند.

یکی از اصول مهم این است که این سه مسیر تا حد امکان از یکدیگر تفکیک شوند.

 

• احراز هویت قوی برای Storage Administrator

اولین مرحله Zero Trust، حذف حساب‌های مدیریتی مشترک و استفاده از هویت‌های مشخص و قابل ردیابی است.

بهتر است:

• برای هر Administrator حساب اختصاصی وجود داشته باشد.
• حساب‌های Shared تا حد امکان حذف شوند.
• MFA فعال شود.
• دسترسی Administratorها بر اساس Role تعریف شود.
• حساب‌های غیرفعال حذف یا Disable شوند.
• فعالیت کاربران ثبت و Audit شود.

برای مثال به جای استفاده از یک حساب عمومی مانند storage-admin بهتر است هر مدیر Storage حساب اختصاصی داشته باشد و فعالیت‌های او قابل ردیابی باشد.

 

• استفاده از RBAC

Role-Based Access Control (RBAC) یکی از مهم‌ترین اجزای Zero Trust است.

همه Administratorها نباید دسترسی یکسان داشته باشند.

برای مثال:

Role	دسترسی
Storage Viewer	مشاهده وضعیت
Storage Operator	عملیات روزمره
Storage Administrator	مدیریت Storage
Security Administrator	تنظیمات امنیتی
Backup Operator	مدیریت Backup
Auditor	مشاهده Log و گزارش

یک Operator نباید الزاماً امکان Delete کردن Storage Pool یا Snapshot را داشته باشد.

اصل مهم  اینجا Least Privilege است.

 

• جداسازی Management Network

یکی از مهم‌ترین اقدامات امنیتی، جداسازی شبکه مدیریت Storage از شبکه کاربران و حتی شبکه Data است.

برای مثال User Network نباید مستقیماً به Storage Management Interface دسترسی داشته باشد.

بهتر است Management Interface در یک Management VLAN / Security Zone مجزا قرار گیرد و دسترسی به آن فقط از طریق سیستم‌های مدیریتی مشخص یا Jump Server امکان‌پذیر باشد.

 

• استفاده از Jump Server

به جای اینکه Administratorها مستقیماً از Workstation خود به Storage متصل شوند، می‌توان از یک Privileged Access Workstation (PAW) یا Jump Server استفاده کرد.

معماری می‌تواند به این صورت باشد:

Administrator

↓ MFA

Jump Server

↓

Storage Management Interface

در این حالت، دسترسی مستقیم کاربران به Management Interface حذف می‌شود.

همچنین Sessionهای مدیریتی را می‌توان ثبت و Audit کرد.

 

• تفکیک Data Network و Management Network

در SAN Storage باید بین مسیر انتقال Data و مسیر Management تفاوت قائل شد.

برای مثال:

• Data Path

Server → FC Switch → Storage Front-End Port

 

• Management Path

Administrator → Management Network → Storage Controller

این دو مسیر نباید بدون دلیل روی یک شبکه قرار گیرند.

در محیط‌های حساس، استفاده از Management Network مستقل یا Security Zone جداگانه توصیه می‌شود.

 

• کنترل دسترسی به SAN

در محیط Fibre Channel، Zero Trust فقط مربوط به Login به Storage نیست.

باید مشخص شود:

کدام Host اجازه دسترسی به کدام Volume را دارد؟

اینجا فناوری‌هایی مانند:

• WWPN
• Zoning
• LUN Masking
• Host Group
• Initiator Group
• Multipathing

اهمیت پیدا می‌کنند.

برای مثال اگر یک ESXi Host فقط باید به Datastore مشخصی دسترسی داشته باشد، نباید به Volumeهای سایر سرویس‌ها دسترسی داشته باشد.

این اصل را می‌توان به شکل زیر خلاصه کرد:

Host A فقط Storage Resource A به جای اینکه Host A تمام Storageها

 

• استفاده از Micro-Segmentation

در محیط‌های مدرن، حتی قرار دادن Serverها در یک VLAN مشترک نیز ممکن است کافی نباشد.

Micro-Segmentation اجازه می‌دهد ارتباطات میان Workloadها به‌صورت دقیق کنترل شوند.

برای مثال:

Application Server → Database مجاز است. اما: Application Server → Storage Management مجاز نیست.

یا User Workstation → SAN Management به‌صورت کامل Block شود.

 

• محافظت از Snapshot و Replication

Snapshot یکی از مهم‌ترین قابلیت‌های Storage برای Recovery است، اما اگر حساب مدیریتی مهاجم به Storage دسترسی داشته باشد، Snapshot نیز ممکن است حذف شود.

بنابراین Snapshot باید بخشی از یک معماری چندلایه باشد.

برای داده‌های حساس می‌توان از:

• Immutable Snapshot
• Locked Snapshot
• Replication
• Offsite Copy
• Air-Gapped Backup

استفاده کرد.

اصل مهم این است:

Snapshot به‌تنهایی Backup ضدباج‌افزار نیست.

 

• محافظت از Backup Repository

Zero Trust باید تا Backup نیز ادامه پیدا کند.

سرور Backup و Repository نباید دسترسی بیش از نیاز داشته باشند.

بهتر است:

• Backup Network مستقل باشد.
• Repository از Production جدا شود.
• دسترسی کاربران به Repository محدود شود.
• حساب Backup Administrator از Domain Administrator جدا باشد.
• MFA برای مدیریت Backup فعال شود.
• نسخه Immutable یا Air-Gapped وجود داشته باشد.

این معماری باعث می‌شود در صورت compromise شدن Domain، مهاجم نتواند به‌سادگی تمام Backupها را حذف کند.

 

• Encryption در Zero Trust Storage

Zero Trust فقط کنترل Access نیست؛ Encryption نیز یکی از لایه‌های مهم حفاظت از داده است.

دو نوع Encryption اهمیت زیادی دارد:

• Encryption at Rest

اطلاعات روی Storage به‌صورت رمزگذاری‌شده نگهداری می‌شوند.

• Encryption in Transit

اطلاعات هنگام انتقال میان سیستم‌ها و Storage محافظت می‌شوند.

در محیط‌های حساس، استفاده هم‌زمان از هر دو لایه می‌تواند سطح حفاظت را افزایش دهد.

 

• Continuous Monitoring

Zero Trust بدون Monitoring کامل نیست.

باید فعالیت‌های مهم Storage ثبت و تحلیل شوند؛ مانند:

• Login موفق
• Login ناموفق
• تغییر Role
• ایجاد Volume
• حذف Volume
• ایجاد Snapshot
• حذف Snapshot
• تغییر Replication
• تغییر Configuration
• تغییر Access Control

اگر مثلاً یک Administrator در ساعت ۳ صبح تعداد زیادی Snapshot را حذف کند، این رفتار باید به‌عنوان یک رویداد امنیتی بررسی شود.

 

• اتصال Storage به SIEM

Logهای Storage می‌توانند به یک SIEM مانند Splunk یا سایر پلتفرم‌های SIEM ارسال شوند.

در این حالت می‌توان رویدادهای Storage را با سایر رویدادهای امنیتی Correlate کرد.

برای مثال:

• Suspicious Login
• Privilege Escalation
• Storage Configuration Change
• Snapshot Deletion

می‌تواند یک Incident با اولویت بالا ایجاد کند.

این موضوع در شناسایی حملات Ransomware اهمیت زیادی دارد.

 

• استفاده از MFA و Privileged Access Management

برای حساب‌های دارای دسترسی بالا، MFA باید یک کنترل پایه باشد.

علاوه بر MFA، در سازمان‌های حساس می‌توان از Privileged Access Management (PAM) استفاده کرد.

در این مدل:

Administrator

→ درخواست دسترسی

→ تأیید

→ دریافت Credential موقت

→ انجام عملیات

→ ثبت Session

→ پایان دسترسی

این مدل احتمال سوءاستفاده از Credentialهای دائمی را کاهش می‌دهد.

 

• Zero Trust برای NVMe/TCP و iSCSI

Zero Trust فقط برای Fibre Channel نیست.

در محیط‌های iSCSI و NVMe/TCP نیز باید دسترسی به Storage Targetها کنترل شود.

بسته به معماری می‌توان از مواردی مانند:

• Network Segmentation
• ACL
• Firewall
• CHAP در iSCSI
• TLS در سناریوهای پشتیبانی‌شده
• Initiator Authentication
• VLAN Separation

استفاده کرد.

هدف این است که هر Host فقط به Storage Resource موردنیاز خود دسترسی داشته باشد.

 

 یک معماری پیشنهادی Zero Trust برای SAN

برای یک Data Center سازمانی می‌توان معماری زیر را در نظر گرفت:

Users

↓

Identity Provider + MFA

↓

PAM / Jump Server

↓

Management Network

↓

SAN / Storage Management

و به‌صورت مستقل:

Servers

↓

FC Fabric

↓

SAN Storage

و برای Backup:

Production

↓

Backup Network

↓

Immutable Repository

↓

Tape Library

↓

Offline / Offsite Vault

این تفکیک باعث می‌شود compromise شدن یک بخش الزاماً به معنی دسترسی مهاجم به تمام زیرساخت Storage نباشد.

 

 Zero Trust و اصل Assume Breach

یکی از مهم‌ترین مفاهیم Zero Trust این است که باید فرض کنیم:

مهاجم ممکن است همین الان داخل شبکه باشد.

بنابراین طراحی Storage نباید بر اساس این فرض باشد که:

«چون این Server داخل شبکه داخلی است، پس قابل اعتماد است.»

در عوض باید مشخص شود:

• چه هویتی دارد؟
• چه دستگاهی است؟
• چه Resourceای لازم دارد؟
• چه زمانی باید دسترسی داشته باشد؟
• چه عملیاتی مجاز است؟
• آیا رفتار آن عادی است؟

 

اشتباهات رایج

برخی از خطاهای رایج در پیاده‌سازی Storage Security عبارت‌اند از:

• قرار دادن Storage Management در VLAN کاربران
• استفاده از یک حساب Administrator مشترک
• استفاده نکردن از MFA
• دسترسی مستقیم Administratorها به Storage
• دسترسی بیش از حد Serverها به LUNها
• قرار دادن Backup در همان Security Zone
• عدم استفاده از Immutable Backup
• عدم ارسال Storage Log به SIEM
• استفاده از Domain Administrator برای مدیریت Storage
• عدم بررسی دوره‌ای Access Control

 

چک‌لیست Zero Trust برای Storage

برای ارزیابی اولیه می‌توان این موارد را بررسی کرد:

کنترل	وضعیت مطلوب
MFA	فعال
RBAC	فعال
Least Privilege	اجرا شده
Management Network	جدا
Jump Server / PAM	وجود دارد
SAN Zoning	محدود و مستند
LUN Masking	فعال
Encryption at Rest	فعال در صورت نیاز
Encryption in Transit	فعال در سناریوهای مربوط
Immutable Backup	وجود دارد
Air-Gapped Copy	وجود دارد
Storage Logging	فعال
SIEM Integration	فعال
Periodic Access Review	انجام می‌شود
Recovery Test	دوره‌ای انجام می‌شود

 

جمع‌بندی

پیاده‌سازی Zero Trust برای Storage به معنای اضافه کردن یک محصول امنیتی جدید به SAN نیست؛ بلکه یک رویکرد معماری است که تمام مسیرهای دسترسی به Storage را از منظر هویت، مجوز، شبکه، دستگاه و رفتار بررسی می‌کند.

در یک معماری مناسب، Administrator، Server، Application و Backup System هیچ‌کدام صرفاً به دلیل قرار داشتن در شبکه داخلی مورد اعتماد قرار نمی‌گیرند.

برای SANهای سازمانی، مهم‌ترین اقدامات شامل تفکیک Management و Data Plane، MFA، RBAC، Least Privilege، SAN Zoning، LUN Masking، PAM، Monitoring و SIEM Integration است. در کنار این موارد، استفاده از Immutable Backup و Air Gap باعث می‌شود حتی در صورت عبور مهاجم از لایه‌های اولیه دفاعی، امکان بازیابی اطلاعات حفظ شود.

در نهایت، Storage باید بخشی از معماری Zero Trust کل سازمان باشد؛ نه یک جزیره مستقل که صرفاً به دلیل قرار گرفتن در Data Center قابل اعتماد فرض شود. در معماری مدرن، اصل اساسی این است:

Never Trust – Always Verify

و این اصل باید از Endpoint و Network تا SAN، NAS، Backup و Archive ادامه پیدا کند.

تیم تخصصی شرکت کوشا فناوران مبتکر، آمادگی خود را برای ارائه هرگونه مشاوره و همکاری در پروژه های شبکه و امنیت فضای سایبری اعلام می دارد.

کوشا فناوران مبتکر را در مطالب آموزشی و مجله مبتکر  با جدیدترین اخبار فناوری اطلاعات و مقالات علمی دنبال کنید.