🔴 تغییر مهم دیگری در اکوسیستم VMware؛ این بار پای IBM در میان است
شرکت IBM توافق کرده بخشی از کسب‌وکار VMware Cloud خود را به شرکت 11:11 Systems منتقل کند؛ معامله‌ای که صدها مشتری سازمانی VMware را شامل می‌شود.
طبق گزارش The Register، این انتقال در شرایطی انجام می‌شود که Broadcom در حال تغییر ساختار برنامه VMware Cloud Service Provider است و ارائه‌دهندگان این حوزه باید خودشان را با مدل جدید تطبیق دهند.
اما چیزی که این خبر را مهم می‌کند فقط IBM نیست.
ماجرا بخشی از تغییر بزرگ‌تری است که بعد از خرید VMware توسط Broadcom در اکوسیستم Virtualization شکل گرفته.
تغییر مدل Licensing، بازطراحی Partner Program، افزایش هزینه در برخی قراردادها و تغییر شرایط Service Providerها باعث شده بسیاری از سازمان‌ها دوباره درباره استراتژی مجازی‌سازی خود فکر کنند.
نکته مهم اینجاست:
مهاجرت از VMware الزاماً به معنی «حذف VMware» نیست.
بعضی سازمان‌ها به سمت مدل‌های ترکیبی می‌روند و در کنار VMware، پلتفرم‌های دیگری را وارد زیرساخت می‌کنند.
در چنین شرایطی مفاهیمی مثل:
🔹 Multi-Hypervisor
🔹 Private Cloud
🔹 KVM
🔹 OpenStack
🔹 Proxmox
🔹 Kubernetes
بیشتر از گذشته وارد تصمیم‌های معماری می‌شوند.
📌 به نظر می‌رسد سؤال مدیران زیرساخت کم‌کم از:
«آیا VMware را عوض کنیم؟»
به این سؤال تغییر کرده:
«اگر روزی مجبور شدیم VMware را عوض کنیم، آیا زیرساخت ما برای این مهاجرت آماده است؟»
و این دو سؤال تفاوت بسیار بزرگی دارند.

منبع: The Register
#VMware #Broadcom #IBM #Virtualization #PrivateCloud #Cloud #Infrastructure
☁️ ابرپلاس | Cloud & Infrastructure
@abrplusdocs

🧩 بخشی از اینترنت روی دوش چند نفر می‌چرخد!

وقتی می‌گوییم Open Source، معمولاً پروژه‌هایی مثل Linux و Kubernetes با هزاران مشارکت‌کننده به ذهن می‌آیند.

اما پشت بسیاری از نرم‌افزارها و Libraryهایی که هر روز در سرورها، Cloud، Containerها و نرم‌افزارهای سازمانی استفاده می‌کنیم، واقعیت دیگری وجود دارد:

گاهی یک پروژه مهم فقط توسط یک یا دو Maintainer اصلی نگهداری می‌شود.

حالا تصور کنید همان پروژه به‌صورت مستقیم یا غیرمستقیم Dependency صدها پروژه دیگر باشد.

یک آسیب‌پذیری امنیتی کشف می‌شود.

Issueها زیاد می‌شوند.

نسخه جدید Runtime منتشر می‌شود.

Maintainer هم دیگر زمان یا انگیزه ادامه پروژه را ندارد.

ناگهان چیزی که برای هزاران سازمان یک Dependency کوچک به نظر می‌رسید، تبدیل به یک Supply Chain Risk می‌شود.

اتفاق‌هایی مثل آسیب‌پذیری Log4Shell قبلاً نشان داده‌اند که یک Component به‌ظاهر کوچک تا چه اندازه می‌تواند در عمق زیرساخت‌های دنیا حضور داشته باشد.

مشکل Open Source بودن نیست.

مشکل زمانی شروع می‌شود که سازمان حتی نمی‌داند نرم‌افزارهایش به چه Componentهایی وابسته‌اند.

برای همین مفاهیمی مثل:

🔹 Software Bill of Materials یا SBOM
🔹 Dependency Management
🔹 Vulnerability Scanning
🔹 Software Supply Chain Security

دیگر فقط موضوع تیم Developer نیستند.

تیم‌های Cloud، DevOps و Security هم باید بدانند چه چیزی واقعاً داخل Stack سازمان در حال اجراست.

📌 شاید سؤال مهم دیگر این نباشد که:

«این نرم‌افزار Open Source هست یا نه؟»

بلکه باید بپرسیم:

چه کسانی آن را نگهداری می‌کنند، چقدر فعال است و اگر فردا رها شود، Plan B ما چیست؟

Open Source رایگان است؛ اما مدیریت ریسک آن رایگان نیست.

#OpenSource #CyberSecurity #DevOps #SupplyChain #CloudSecurity #Infrastructure

☁️ ابرپلاس | Cloud & Infrastructure
@abrplusdocs

#fun
#Security
@abrplusdocs

لایسنس مربوط به VDOM هم روی فایروال اعمال شد و با این فایل میتونید این قابلیت رو فعال کنید و در محیط لابراتوار استفاده کنید.

username:admin
password:123

🐧 ۷ دستور خطرناک لینوکس که می‌تونن سیستم رو نابود کنن!

این دستورات رو باید بشناسی، ولی *هیچ‌وقت روی سیستم اصلی بدون اینکه دقیق بدونی چه کاری انجام میدن اجراشون نکن!* ⚠️

━━━━━━━━━━━━━━━━━━

☠️ 1. حذف کل فایل‌سیستم
rm -rf / --no-preserve-root
کل فایل‌های سیستم رو از ریشه حذف می‌کنه و در حالت عادی عملاً راه برگشتی نداره.

━━━━━━━━━━━━━━━━━━

💣 2. Fork Bomb
:(){ :|:& };:
با ساختن تعداد بسیار زیادی پردازش، جدول پردازش‌ها رو پر می‌کنه و می‌تونه باعث هنگ یا از کار افتادن سیستم بشه.

━━━━━━━━━━━━━━━━━━

💾 3. نابودی اطلاعات دیسک
dd if=/dev/zero of=/dev/sda
روی دیسک صفر می‌نویسه و می‌تونه سیستم‌عامل، پارتیشن‌ها و اطلاعات رو از بین ببره.

━━━━━━━━━━━━━━━━━━

🗑️ 4. فرمت کردن پارتیشن
mkfs.ext4 /dev/sda1
پارتیشن مشخص‌شده رو با فایل‌سیستم جدید فرمت می‌کنه و اطلاعات قبلی اون پارتیشن از بین میره.

━━━━━━━━━━━━━━━━━━

⚠️ 5. نوشتن مستقیم روی دیسک
> /dev/sda
می‌تونه داده‌های مربوط به دیسک رو خراب کنه و باعث بشه سیستم دیگه بوت نشه.

━━━━━━━━━━━━━━━━━━

🔓 6. نابود کردن Permissionها
chmod -R 777 /
مجوزهای کل سیستم رو تغییر میده و می‌تونه باعث خراب شدن Permissionهای حیاتی، مشکل در
sudo
و سرویس‌هایی مثل
sshd
بشه.

━━━━━━━━━━━━━━━━━━

🕳️ 7. انتقال فایل‌ها به /dev/null
mv /* /dev/null
سعی می‌کنه محتویات مسیرهای سیستم رو به
/dev/null
منتقل کنه و می‌تونه باعث از بین رفتن فایل‌های مهم بشه.

━━━━━━━━━━━━━━━━━━

🚨 نکته مهم:

این‌ها فقط «دستورهای ساده لینوکس» نیستن؛ بعضی‌هاشون می‌تونن در چند ثانیه سیستم یا اطلاعاتت رو نابود کنن.

قبل از اجرای هر دستور با
sudo
یا دسترسی
root
، دقیقاً بدون که روی چه مسیری و چه دیسکی داری کار می‌کنی.

@abrplusdocs

🚨 یک CVE ده‌ساله دوباره برگشته؛ قدیمی بودن آسیب‌پذیری یعنی امن بودن نیست!

یک آسیب‌پذیری قدیمی درApache Struts با شناسه:
CVE-2016-3081

دوباره به دلیل مشاهده سوءاستفاده در حملات واقعی مورد توجه قرار گرفته و CISA آن را به فهرست Known Exploited Vulnerabilities (KEV) اضافه کرده است.

نکته جالب؟

این CVE مربوط به سال ۲۰۱۶ است!

یعنی آسیب‌پذیری تقریباً یک دهه است که شناخته شده، اما هنوز سیستم‌هایی در اینترنت وجود دارند که شرایط Exploit شدن آن را فراهم می‌کنند.

و این دقیقاً یکی از مشکلات محیط‌های Enterprise است:

ممکنه یک Application سال‌ها بدون مشکل کار کند و کسی هم جرئت Upgrade کردنش را نداشته باشد.

📌 نکته مهم برای تیم‌های Infrastructure و Security:

Vulnerability Management فقط دنبال کردن آسیب‌پذیری جدید نیست

اگر هنوز Applicationهایی مبتنی بر نسخه‌های قدیمی Apache Struts در سازمان دارید، شاید وقتش رسیده دوباره سراغ Inventory آنها بروید.

#CyberSecurity #ApacheStruts #CVE #CISA #VulnerabilityManagement #PatchManagement #Infrastructure

☁️ ابرپلاس | Cloud & Infrastructure
@abrplusdocs

🚨 هشدار امنیتی؛ مهاجمان فقط دنبال یک CVE نیستند

سازمان های NSA، FBI و شرکای امنیتی بین‌المللی درباره فعالیت مهاجمان سایبری مرتبط با دولت چین هشدار داده‌اند.

نکته مهم گزارش، روش حمله آنهاست.

مهاجمان از ترکیبی از:

🔹 Automated Scanning
🔹 Botnetهای بزرگ
🔹 Exploitation دستی
🔹 ابزارهای مدیریتی موجود در شبکه
🔹 زیرساخت VPN
🔹 و تکنیک‌های Living-off-the-Land

برای شناسایی و نفوذ به شبکه سازمان‌ها استفاده می‌کنند.

طبق گزارش، شرکت چینیIntegrity Technology Group در فراهم‌کردن ابزار و زیرساخت برای بخشی از این فعالیت‌ها نقش داشته و TTPهای مشاهده‌شده با گروه‌هایی که با نام‌هایی مثل:

Flax Typhoon

Ethereal Panda

Red Juliett

شناخته می‌شوند، هم‌خوانی دارد.

اهداف هم فقط شرکت‌های فناوری نیستند.

بخش‌هایی از:

Critical Manufacturing
Healthcare
Government
Information Technology

در میان اهداف گزارش‌شده قرار دارند.

اما برای یک مدیر زیرساخت، مهم‌ترین قسمت این گزارش اسم گروه هکری نیست.

پیام اصلی اینه:

Internet-facing Infrastructure همچنان یکی از مهم‌ترین نقاط ورود مهاجمان است.
Firewall، VPN Gateway، Router، Load Balancer و سایر Edge Deviceها اگر Patch نشده یا End-of-Support باشند، می‌توانند همان نقطه‌ای باشند که مهاجم برای ورود به شبکه منتظرش بوده.

📌 دفاع فقط یعنی «Firewall داریم» نیست.

Asset Inventory، Patch Management، MFA، Log Monitoring، محدودکردن Management Interfaceها و بررسی رفتارهای غیرعادی باید کنار هم قرار بگیرند.

خلاصه ش مهاجم فقط دنبال یک آسیب‌پذیری نیست؛
دنبال ضعیف‌ترین نقطه زیرساخت شماست.

منبع: NSA / FBI Joint Cybersecurity Advisory

#CyberSecurity #CISA #NSA #FBI #NetworkSecurity #SOC #InfrastructureSecurity

☁️ ابرپلاس | Cloud & Infrastructure
@abrplusdocs

🤖 مشکل بعدی AI کمبود GPU نیست؛ پول ساختن زیرساختشه!

مدیرعامل Broadcom, Hock Ta امروز نکته جالبی درباره ادامه موج AI مطرح کرد.

به گفته او، صنعت در حال عبور از محدودیت‌هایی مثل کمبود Wafer و Memory است؛ اما bottleneck بزرگ بعدی می‌تواند چیز دیگری باشد:

💰 Capital

یعنی سرمایه‌ای که برای ادامه توسعه زیرساخت AI نیاز داریم.

چرا؟

چون وقتی درباره AI Infrastructure صحبت می‌کنیم، فقط درباره خرید GPU حرف نمی‌زنیم

پشت یک AI Cluster بزرگ، مجموعه عظیمی از زیرساخت قرار دارد:

🔹 GPU / Accelerator
🔹 High-Speed Network
🔹 Storage
🔹 Server
🔹 Datacenter
🔹 Power
🔹 Cooling
🔹 Backup & Resiliency
🔹 و نیروی متخصص برای نگهداری همه اینها

در مقیاس Hyperscaler، همین زیرساخت‌ها می‌توانند به پروژه‌هایی چند میلیارد دلاری تبدیل شوند.

اینجاست که یک تغییر مهم اتفاق می‌افتد:

تا امروز سؤال اصلی این بود:

«آیا به اندازه کافی GPU داریم؟»

اما سؤال آینده ممکن است این باشد:

«آیا ساخت این حجم از زیرساخت از نظر اقتصادی توجیه دارد؟»

این موضوع برای مهندس‌های Infrastructure هم مهمه.

چون رشد AI یعنی Datacenterهای متراکم‌تر، مصرف برق بیشتر، شبکه‌های سریع‌تر، Storage سنگین‌تر و معماری‌هایی که باید حجم بسیار بالاتری از Compute را مدیریت کنند.

📌 شاید رقابت بعدی AI فقط بر سر ساخت مدل بهتر نباشد؛

برنده می‌تواند کسی باشد که بتواندCompute بیشتری را با هزینه، برق و زیرساخت کمتری ارائه کند.

AI در نهایت فقط یک مسئله Software نیست؛
یک مسئله بسیار بزرگ Infrastructure هم هست.

منبع: Reuters – 12 October 2026

#AI #Datacenter #Infrastructure #Cloud #Broadcom #GPU #Storage #Networking

☁️ ابرپلاس | Cloud & Infrastructure
@abrplusdocs

☁️ ابرک ویراک را 24 ساعت رایگان تست کنید!

قبل از خرید، سرویس ابری VirakCloud را با شرایط واقعی امتحان کنید:

🎁 24 ساعت تست رایگان
🚀 پهنای باند اختصاصی با ترافیک نامحدود
⏱️ پرداخت ساعتی؛ فقط به اندازه مصرفتان هزینه کنید

بدون نیاز به تعهد بلندمدت، ابرک خودتان را بسازید، عملکرد سرویس را بررسی کنید و بعد تصمیم بگیرید.

برای دریافت کد تست رایگان، کلمه «تست» را به آیدی زیر ارسال کنید:
https://t.me/cloud_virak

👇 سپس وارد پنل VirakCloud شوید، کد را وارد کنید و ابرک خود را بسازید:
🔗 https://B2n.ir/qy4432

🔌 انواع کابل شبکه؛ از Cat5 تا Cat8 |
سیو داشته باشید

@abrplusdocs

☁️ وقتی شبکه OpenStack مستقیم با Fabric دیتاسنتر حرف می‌زند
یکی از بخش‌های جذاب OpenStack 2026.2 یا Hibiscus، ادامه توسعه Networking در Neutron و OVN برای محیط‌های مدرن دیتاسنتری است.
اینجا پای یک تکنولوژی مهم وسطه:
BGP EVPN
در معماری سنتی OpenStack معمولاً Tenant Networkها داخل Overlayهایی مثل VXLAN قرار دارند و برای رسیدن به شبکه فیزیکی باید از مسیرهای مشخصی در لایه Network عبور کنند.
اما در معماری‌های جدید، هدف اینه که ارتباط بین:
OpenStack Overlay
و
Physical Data Center Fabric
هوشمندتر و Dynamicتر بشه.
در Neutron/OVN، سرویس BGP می‌تواند Topology و OpenFlow Ruleهای موردنیاز برای Advertisers آماده کند و یک Routing Suite خارجی مثل FRR پروتکل BGP را اجرا کند.

@abrplusdocs

🛠 یک Port استفاده شده ؛ چطور بفهمیم دست کدام Process است؟

یکی از سناریوهای رایج در Linux اینه که می‌خواهیم یک سرویس را Start کنیم ولی با خطایی شبیه این مواجه می‌شویم:

Address already in use

یعنی یک Process دیگر قبلاً آن Port را گرفته.

فرض کنیم Nginx نمی‌تواند روی Port 80 اجرا شود.

اول ببینیم چه چیزی روی این Port در حال Listen است:

ss -lntp | grep ':80 '

پارامترها:

🔹 گزینه -l فقط Socketهای در حال Listen را نمایش می‌دهد.

🔹 گزینه -n اجازه نمی‌دهد Port و IP به Name تبدیل شوند.

🔹 گزینه -t فقط TCP Socketها را نمایش می‌دهد.

🔹 گزینه -p Process و PID مرتبط را نشان می‌دهد.

ممکن است ببینیم:

LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("apache2",pid=1842,fd=4))

پس مقصر پیدا شد:

apache2 → PID 1842

حالا اطلاعات Process را ببینیم:

ps -fp 1842

برای مشاهده Command Line کامل:

cat /proc/1842/cmdline | tr '\0' ' '

روش دیگری هم داریم:

lsof -iTCP:80 -sTCP:LISTEN

دستور lsof به ما نشان می‌دهد کدام Process یک File یا Socket را باز نگه داشته.

حالا اگر بخواهیم تمام Portهای Listening سرور را ببینیم:

ss -lntup

این یکی از دستورهایی است که در Troubleshooting شبکه Linux واقعاً باید به آن مسلط باشید.

اما یک اشتباه رایج:

❌ به محض پیدا کردن PID نزنید:

kill -9 1842

اول بفهمید Process متعلق به چه Serviceای است.

مثلاً:

systemctl status apache2

اگر واقعاً قرار است متوقف شود:

systemctl stop apache2

📌 استفاده از kill -9 باید آخرین گزینه باشد، نه اولین

#Linux
#LPIC2
#LinuxCommands
#Troubleshooting
#SysAdmin
#Networking

☁️ ابرپلاس | Cloud & Infrastructure
@abrplusdocs

بریم سراغ یه موضوع دیگه در زمینه امنیت سرورای لینوکسی صحبت کنیم که کاربرد زیادی هم داره
یکم طولانیه ولی خب کاربردیه 📿☺️

🔐 چطور بفهمیم کی داره روی SSH سرور رمز عبور امتحان می‌کنه؟
یکی از بررسی‌های مهم روی سرورهای لینوکسی، بررسی تلاش‌های ناموفق برای ورود از طریق این پروتکله
اگر سرور از طریق اینترنت تو دسترس باشه یا حتی تو شبکه های داخلی، احتمالاً در Logها تعداد زیادی Login ناموفق میبینید
🔹برای شروع، Logهای مربوط به SSH در یک ساعت گذشته را ببینیم:
journalctl -u ssh --since "1 hour ago"
🔹در بعضی توزیع‌ها نام سرویس sshd است:
journalctl -u sshd --since "1 hour ago"
🔹حالا فقط تلاش‌های ناموفق رو جدا کنیم:
journalctl -u ssh --since "1 hour ago" | grep "Failed password"
ممکنه خروجی مشابه این ببینیم:
Failed password for root from 192.0.2.15 port 51342 ssh2
یعنی از این IP برای ورود به یوزر root تلاش شده ولی Authentication ناموفق بوده است.
حالا فرض کنید چند هزار خط Log داریم.
می‌خواهیم بفهمیم کدوم IP بیشترین تلاش ناموفق را داشته:
journalctl -u ssh --since "24 hours ago" | grep "Failed password" | grep -oE 'from ([0-9]{1,3}\.){3}[0-9]{1,3}' | awk '{print $2}' | sort | uniq -c | sort -nr
مثلاً خروجی:
387 192.0.2.15
142 198.51.100.27
36 203.0.113.8
یعنی IP اول در ۲۴ ساعت گذشته ۳۸۷ بار Login ناموفق داشته
🔎 حالا بیایید خود Command را باز کنیم.
دستور زیر فقط Loginهای ناموفق را جدا می‌کند:
grep "Failed password"
این قسمت IP را از Log استخراج می‌کند:
grep -oE 'from ([0-9]{1,3}\.){3}[0-9]{1,3}'
بعد فقط خود IP را برمی‌داریم:
awk '{print $2}'
آدرس‌ها را مرتب می‌کنیم:
sort
تعداد تکرار هر IP را می‌شماریم:
uniq -c
و در نهایت از بیشترین تعداد مرتب می‌کنیم:
sort -nr
اما اینجا بررسی ما تموم نشده
⚠️ تعداد زیاد Failed Login لزوماً یعنی سرور Hack شده؟
خیر
حالا باید ببینیم Login موفقی هم اتفاق افتاده یا نه.
برای بررسی Authenticationهای موفق:
journalctl -u ssh --since "24 hours ago" | grep "Accepted"
ممکنه ببینیم:
Accepted publickey for admin from 192.0.2.20
یا:
Accepted password for user1 from 192.0.2.30
اینجا باید بررسی کنیم:
آیا این User معتبر بوده؟
آیا IP رو می‌شناسیم؟
آیا زمان Login طبیعی بوده؟
برای مشاهده Loginهای قبلی:
last
و برای مشاهده Loginهای ناموفق ثبت‌شده در btmp:
lastb
📌 یک نکته مهم در Troubleshooting امنیتی:
بین این مراحل تفاوت زیادی وجود دارد:
Scan → Brute Force → Successful Login → Compromise
دیدن ۵۰۰ تلاش ناموفق ممکنه فقط نشان‌دهنده یک Brute Force ناموفق باشه
اما اگر بعد از همان تلاش‌ها یک Login موفق از همان IP ببینیم، ماجرا کاملاً متفاوت میشه
🛡️ برای Hardening سرویس SSH هم تنظیمات زیر رو بررسی کنید:
PermitRootLogin no
و در محیط‌هایی که Public Key Authentication به‌درستی پیاده‌سازی شده:
PasswordAuthentication no
همچنین میتوان دسترسی SSH رو در Firewall فقط به شبکه‌های مدیریتی محدود کرد و در سناریوهای مناسب از ابزارهایی مثل Fail2ban استفاده کرد.

توی Security فقط دنبال این نباشید که:
«چه کسی حمله کرده؟»
سؤال مهم‌تر اینه:
«آیا نشانه‌ای وجود دارد که حمله موفق شده باشد؟»
#Linux
#LPIC3
#LinuxSecurity
#SSH
#CyberSecurity
#Troubleshooting
#SysAdmin
☁️ ابرپلاس | Cloud & Infrastructure
@abrplusdocs

معرفی یک ابزار خفن و ضروری برای مانیتورینگ سایت و سرور: Uptime Kuma

آپتایم کوما (Uptime Kuma) یک ابزار مانیتورینگ کاملاً رایگان، متن‌باز (Open-Source) و Self-hosted هست که می‌تونی روی سرور خودت نصبش کنی و خیالت رو از بابت قطعی‌ها راحت کنی.

چرا باید از Uptime Kuma استفاده کنیم؟
سرعت بالا در تشخیص قطعی: برعکس خیلی از سرویس‌های رایگان که هر ۵ یا ۱۰ دقیقه سایت رو چک می‌کنن، این ابزار می‌تونه هر ۲۰ ثانیه وضعیت رو بررسی کنه

سیستم هشدار (Alert) فوق‌العاده: اگه سایت یا سرورت Down بشه، می‌تونه از طریق بیش از ۹۰ سرویس مختلف مثل تلگرام، دیسکورد، اسلک، ایمیل و حتی پیامک بهت خبر بده.

مانیتورینگ همه‌جانبه: فقط برای وب‌سایت نیست! می‌تونی وضعیت کانتینرهای داکر (Docker)، دیتابیس‌ها، پورت‌های شبکه و حتی سرورهای بازی رو هم باهاش مانیتور کنی.

داشبورد زیبا و کاربردی: یک محیط کاربری بسیار تمیز با نمودارهای پینگ و قابلیت ساخت صفحات وضعیت (Status Pages) برای نمایش به کاربران.

نصبش هم با داکر (Docker) بسیار ساده است و تو چند دقیقه انجام میشه.
@abrplusdocs

🔴معاون توسعه شبکه ملی:

در صورت وقوع مجدد جنگ یا ناآرامی، احتمال قطع اینترنت وجود داره

@abrplusdocs

فرصت #همكارى با تيم فنى آلياسيس

ارتباط شركت آلياسيس ارتباط براى يكى از پروژه هاى بزرگ و حساس زيرساختى خود، از متخصصان توانمند و علاقهمند به حوزه شبكه و زيرساخت دعوت به
#همكارى مىكند. اين پروژه در حوزه پشتيبانى و بهرهبردارى از زيرساخت شبكه Enterprise تعريف شده و همكاران اين تيم به صورت مقيم در محل پروژه فعاليت خواهند داشت؛ با اين حال، نقش تيم صرفأ محدود به نگهدارى و رفع اشكال وزمره نيست.در كنار فعاليتهاى پشتيبانى، عيب يابى و نگهدارى، فرصت مشاركت در موضوعاتى مانند بهينهسازى زيرساخت، بهبود عملكرد، كاهش آسيبپذيرى، توسعه و بهبود معمارى شبكه و ارائه راهكارهاى فنى نيز وجود
خواهد داشت. اگر به دنبال تجربه كار در يك محيط Enterprise مواجهه با چالشهاى واقعى زيرساخت و رشد در كنار يك تيم تخصصى هستيد، اين فرصت
مى تواند براى شما جذاب باشد.

@careers.ts@aliasys.co

شرکت Broadcom از راهکار امنیتی جدیدی با نام VMware HyperArmor رونمایی کرده که تمرکزش مستقیماً روی یکی از حساس‌ترین قسمت‌های زیرساخت مجازی است:
خود Hypervisor
ما معمولاً برای امن‌سازی زیرساخت VMware سراغ Firewall، Segmentation، محدودسازی Management Network، Hardening ماشین‌های مجازی و کنترل دسترسی می‌رویم.
اما یک سؤال مهم باقی می‌ماند:
اگر خود ESX آسیب‌پذیر باشد چه؟
یکی از چالش‌های همیشگی تیم‌های زیرساخت، فاصله زمانی بین شناسایی یک Vulnerability و نصب Patch رسمی است.
فرض کنید یک آسیب‌پذیری جدی برای ESX منتشر شده.
پچ هم وجود دارد، اما نصب آن ممکن است نیازمند Maintenance Window، انتقال Workloadها، ورود Host به Maintenance Mode، Reboot و انجام تست‌های بعد از Upgrade باشد.
در یک محیط بزرگ، این فرآیند ممکن است فوراً قابل انجام نباشد.
در نتیجه یک بازه خطرناک ایجاد می‌شود:
Vulnerability Disclosed
⬇️
Exposure Window
⬇️
Official Patch Applied
ایده HyperArmor این است که برای همین فاصله زمانی، یک لایه دفاعی اضافی در سطح Hypervisor ایجاد کند.
🔹 قابلیت اول: Virtual Patching
یکی از جذاب‌ترین بخش‌های HyperArmor همین قسمت است.
به‌جای اینکه برای کاهش ریسک حتماً منتظر Patch کامل Host بمانیم، این لایه می‌تواند تلاش برای سوءاستفاده از برخی آسیب‌پذیری‌ها را قبل از رسیدن به نقطه Exploit مسدود کند.
مزیت عملیاتی مهم این رویکرد چیست؟
کاهش Exposure Window بدون اینکه الزاماً همان لحظه مجبور به ایجاد اختلال در Workloadهای در حال اجرا باشیم.
اما یک نکته خیلی مهم:
⚠️ Virtual Patching جایگزین Patch رسمی نیست.
باید به آن به چشم یک Compensating Control نگاه کنیم؛ یعنی لایه‌ای موقت یا تکمیلی برای کاهش ریسک تا زمانی که Patch اصلی طبق فرآیند Change Management نصب شود.
🔹 قابلیت دوم: کنترل اجرای File و Script
سناریوی دیگری را تصور کنید.
مهاجم به هر روشی توانسته به سطح مدیریتی Host نزدیک شود و حالا می‌خواهد یک Binary یا Script غیرمجاز اجرا کند.
HyperArmor می‌تواند یک Security Baseline در سطح ESX ایجاد کند تا مشخص شود چه فایل‌ها و Scriptهایی اجازه اجرا دارند.
یعنی به‌جای اینکه فقط بپرسیم:
«چه کسی اجازه Login دارد؟»
یک سؤال دیگر هم اضافه می‌کنیم:
«بعد از Login چه چیزی اجازه اجرا دارد؟»
این موضوع در کاهش ریسک اجرای Payloadهای مخرب اهمیت زیادی دارد.
نکته جالب‌تر اینکه این کنترل در سطح Hypervisor انجام می‌شود و برای آن نیازی به نصب Agent داخل تک‌تک Guest VMها نیست.
🔹 قابلیت سوم: MFA برای دسترسی SSH
فرض کنیم Credential یکی از Administratorهای زیرساخت افشا شده است.
اگر Username و Password تنها سد دفاعی SSH باشند، مهاجم ممکن است بتواند مستقیماً وارد Command Line شود.
HyperArmor امکان اضافه‌کردن Multi-Factor Authentication به مسیر دسترسی SSH در سطح ESX را فراهم می‌کند.
در نتیجه داشتن Credential به‌تنهایی برای ورود کافی نیست و یک عامل احراز هویت دیگر هم موردنیاز خواهد بود.
این قابلیت مخصوصاً برای Management Plane اهمیت زیادی دارد؛ چون دسترسی مدیریتی به Hypervisor با دسترسی به یک Server معمولی قابل مقایسه نیست.
📌 اما HyperArmor دقیقاً کجای معماری امنیت VMware قرار می‌گیرد؟
اینجا مفهوم Defense in Depth مهم می‌شود.
راهکارهایی مثل VMware vDefend بیشتر روی Network Security، Segmentation و کنترل ترافیک تمرکز دارند.
در مقابل، HyperArmor یک لایه حفاظتی نزدیک‌تر به خود Hypervisor اضافه می‌کند.
در نتیجه معماری دفاعی می‌تواند چیزی شبیه این باشد:
Workload Security
⬇️
Network Security / vDefend
⬇️
Hypervisor Security / HyperArmor
⬇️
Hardware & Management Plane
و این دقیقاً نکته مهم این خبر برای تیم‌های زیرساخت است.
امنیت Virtualization فقط یعنی:
❌ Firewall داشته باشیم
❌ Management VLAN را جدا کنیم
❌ VMها را Hardening کنیم
❌ دسترسی vCenter را محدود کنیم
این‌ها لازم‌اند، اما کافی نیستند.
خود Hypervisor هم یک Security Boundary بسیار مهم است.
چون اگر این لایه Compromise شود، دیگر درباره امنیت یک VM صحبت نمی‌کنیم؛ ممکن است چندین Workload روی همان Host تحت تأثیر قرار بگیرند.
به‌نظرم پیام مهم HyperArmor همین تغییر نگاه است:
Hypervisor دیگر فقط بستری برای اجرای VM نیست؛ خودش باید به‌عنوان یک لایه مستقل امنیتی محافظت و پایش شود.
و البته حتی با چنین مکانیزم‌هایی، اصول اصلی همچنان سر جای خودشان هستند: