امنیت لینوکستوضیح و تحلیلJul 13, 2026, 10:22 AM· 6 دقیقه مطالعه· #1 از 2 در فناوری

نقص ۱۵ ساله «گوست‌لاک» چگونه دسترسی روت و فرار از کانتینر را در لینوکس فراهم می‌کند؟

آسیب‌پذیری جدیدی به نام «گوست‌لاک» (GhostLock) فاش شده است که به مهاجمان اجازه می‌دهد کنترل کامل اکثر سیستم‌های لینوکس را به دست آورند و از کانتینرهای ابری فرار کنند، که این امر منجر به یک تلاش فوری در سطح صنعت برای وصله‌گذاری شده است.

به قلم تیم سردبیری کوهستان

محققان امنیتی 30%مدیران فناوری اطلاعات سازمانی 30%ارائه‌دهندگان خدمات ابری 20%نگهدارندگان متن‌باز 20%
محققان امنیتی
استدلال می‌کنند که گوست‌لاک نیاز فوری به انتقال اجزای حیاتی هسته به زبان‌های ایمن حافظه مانند Rust را برجسته می‌کند.
مدیران فناوری اطلاعات سازمانی
بر چالش عملیاتی وصله‌گذاری سریع سیستم‌های حیاتی بدون ایجاد اختلال غیرقابل قبول در کسب‌وکار تمرکز دارند.
ارائه‌دهندگان خدمات ابری
بر اثربخشی اقدامات کاهشی در سطح هایپروایزر و وصله‌گذاری شفاف برای محافظت از زیرساخت‌های مدیریت شده تأکید می‌کنند.
نگهدارندگان متن‌باز
بار سنگین ایمن‌سازی کدهای قدیمی چند ده ساله را برجسته کرده و خواستار افزایش بودجه شرکتی برای ممیزی‌های امنیتی خودکار هستند.

زوایای پوشش‌داده‌نشده

  • · توسعه‌دهندگان مستقل اپلیکیشن که به میزبانی VPS مدیریت نشده متکی هستند
  • · تولیدکنندگان دستگاه‌های قدیمی اینترنت اشیا که دیگر نمی‌توانند به‌روزرسانی‌های هسته را دریافت کنند

چرا مهم است

لینوکس نیروی محرکه اکثریت قریب به اتفاق سرورهای وب جهان، زیرساخت‌های ابری و مراکز داده سازمانی است. درک نحوه عملکرد گوست‌لاک و چگونگی خنثی‌سازی آن برای متخصصان فناوری اطلاعات حیاتی است تا لایه‌های زیربنایی اینترنت مدرن را بدون ایجاد اختلال فاجعه‌بار در عملکرد، ایمن سازند.

نکات کلیدی

  • آسیب‌پذیری گوست‌لاک به مهاجمان اجازه می‌دهد تا دسترسی روت را به دست آورند و از کانتینرهای نرم‌افزاری در سیستم‌های لینوکس فرار کنند.
  • این نقص ناشی از یک وضعیت رقابتی (Race Condition) در مکانیسم قفل‌گذاری فایل هسته است که در سال ۲۰۱۱ معرفی شد.
  • ارائه‌دهندگان بزرگ خدمات ابری پیش از افشای عمومی آسیب‌پذیری، اقدامات کاهشی در سطح هایپروایزر را اعمال کردند.
  • تیم‌های فناوری اطلاعات سازمانی از ابزارهای وصله‌گذاری زنده (Live-Patching) برای ایمن‌سازی سرورها بدون نیاز به راه‌اندازی مجدد گسترده استفاده می‌کنند.
  • اگرچه بهره‌برداری فعال تأیید نشده است، اما کد اثبات مفهوم (Proof-of-Concept) اکنون به صورت عمومی در دسترس است.
9.9/10
امتیاز شدت CVSS
15 Years
مدت زمان وجود نقص کشف نشده
80%+
تخمین سرورهای ابری مبتنی بر لینوکس

به مدت پانزده سال، یک نقص خاموش در اعماق هسته سیستم عامل لینوکس پنهان بود و منتظر فعال شدن می‌ماند. این آسیب‌پذیری که توسط محققان امنیتی کشف‌کننده آن «گوست‌لاک» (GhostLock) نامیده شده، یکی از مهم‌ترین تهدیدات علیه زیرساخت‌های رایانش ابری در سال‌های اخیر به شمار می‌رود. این باگ که امتیاز شدت تقریباً حداکثری ۹.۹ از ۱۰ را به خود اختصاص داده است، به مهاجمی با حداقل امتیازات اجازه می‌دهد تا کنترل کامل یک دستگاه را به دست گیرد و مهم‌تر از آن، از کانتینرهای نرم‌افزاری ایزوله خارج شود.[1][2]

این کشف، واکنش گسترده و هماهنگی را در سراسر بخش فناوری برانگیخته است. از آنجایی که لینوکس زیربنای تقریباً ۸۰ درصد از کل سرورهای ابری عمومی است، پیامدهای یک فرار قابل اعتماد از کانتینر بسیار جدی است. در محیط‌های ابری مدرن، چندین مشتری در یک سرور فیزیکی مشترک هستند که تنها توسط مرزهای مجازی از هم جدا شده‌اند. گوست‌لاک یک کلید نظری برای دور زدن این مرزها فراهم می‌کند و یک رخنه محلی را به یک سازش سیستمی تبدیل می‌سازد.[3][8]

برای درک نحوه عملکرد گوست‌لاک، باید به چگونگی مدیریت دسترسی به فایل‌ها توسط هسته لینوکس نگاه کرد. هنگامی که چندین برنامه به طور همزمان تلاش می‌کنند یک فایل را بخوانند یا بنویسند، هسته از مکانیسمی به نام «قفل‌گذاری فایل» برای جلوگیری از خرابی داده‌ها استفاده می‌کند. گوست‌لاک از یک وضعیت رقابتی بسیار خاص در این مکانیسم، به ویژه در زیرسیستم `fs/locks.c`، سوء استفاده می‌کند. با غرق کردن هسته در درخواست‌های قفل همزمان، مهاجم می‌تواند مدیریت حافظه سیستم را دچار سردرگمی کند.[2][5]

این سردرگمی سناریوی «استفاده پس از آزادسازی» (Use-After-Free) را ایجاد می‌کند. هسته به طور تصادفی بلوکی از حافظه را آزاد می‌کند که هنوز تصور می‌کند برای قفل‌گذاری فایل در حال استفاده است. سپس مهاجم به سرعت همان فضای حافظه را با دستورالعمل‌های مخرب خود دوباره تخصیص می‌دهد. هنگامی که هسته متعاقباً تلاش می‌کند قفل فایل اصلی را اجرا کند، در عوض کد مهاجم را با بالاترین امتیازات سیستمی ممکن – یعنی دسترسی روت – اجرا می‌کند.[1][5]

در حالی که به دست آوردن دسترسی روت در یک دستگاه محلی خطرناک است، تهدید واقعی گوست‌لاک در توانایی آن برای تسهیل فرار از کانتینر نهفته است. کانتینرها، که توسط پلتفرم‌هایی مانند داکر و کوبرنتیس محبوب شده‌اند، برای سندباکس کردن برنامه‌ها و محدود کردن آنچه می‌توانند ببینند و انجام دهند، طراحی شده‌اند. با این حال، از آنجایی که کانتینرها در هسته لینوکس زیرین سیستم میزبان مشترک هستند، یک بهره‌برداری در سطح هسته مانند گوست‌لاک به مهاجم اجازه می‌دهد تا به طور کامل سندباکس را دور بزند و وارد سیستم عامل میزبان شود.[4][8]

این آسیب‌پذیری در سال ۲۰۱۱ طی یک بهینه‌سازی روتین کد سیستم فایل معرفی شد. برای بیش از یک دهه، این نقص در معرض دید پنهان ماند و از ممیزی‌های امنیتی متعددی جان سالم به در برد. این نقص تنها ماه گذشته توسط تیمی از محققان دانشگاهی با استفاده از تکنیک‌های پیشرفته «فازینگ» – تست نرم‌افزاری خودکار که حجم زیادی از داده‌های تصادفی را به سمت یک برنامه پرتاب می‌کند تا آن را مجبور به از کار افتادن کند – کشف شد. محققان پس از درک شدت باگ، فرآیند افشای محرمانه را آغاز کردند.[2][4]

این آسیب‌پذیری در سال ۲۰۱۱ طی یک بهینه‌سازی روتین کد سیستم فایل معرفی شد.

این محرمانگی به توزیع‌های اصلی لینوکس و ارائه‌دهندگان خدمات ابری یک مزیت حیاتی داد. شرکت‌هایی مانند Red Hat و Canonical (سازنده اوبونتو) به صورت مخفیانه برای توسعه و آزمایش وصله‌ها کار کردند. به طور همزمان، ارائه‌دهندگان بزرگ زیرساخت ابری، از جمله خدمات وب آمازون (AWS)، اقدامات کاهشی در سطح هایپروایزر را برای محافظت از خدمات مدیریت شده خود قبل از عمومی شدن آسیب‌پذیری اعمال کردند و اطمینان حاصل کردند که ماشین‌های میزبان زیرین از فعالیت‌های مخرب کانتینر محافظت می‌شوند.[5][6][7]

با وجود این اقدامات پیشگیرانه، اکنون بار وصله‌گذاری میلیون‌ها سرور خودمدیریتی بر دوش تیم‌های فناوری اطلاعات سازمانی افتاده است. وصله‌گذاری آسیب‌پذیری هسته به طور سنتی نیازمند راه‌اندازی مجدد سیستم است، که برای خدماتی که به آپتایم ۲۴/۷ نیاز دارند، یک کابوس لجستیکی است. در نتیجه، بسیاری از سازمان‌ها به فناوری‌های وصله‌گذاری زنده روی آورده‌اند که اصلاحیه را مستقیماً به حافظه هسته در حال اجرا تزریق می‌کنند و نیازی به راه‌اندازی مجدد ندارند، و زمان لازم برای پنجره‌های نگهداری برنامه‌ریزی شده را فراهم می‌کنند.[3][6]

در حال حاضر، هیچ مدرکی مبنی بر اینکه گوست‌لاک توسط بازیگران مخرب در فضای عمومی مورد بهره‌برداری قرار گرفته باشد، وجود ندارد. با این حال، ظرف چند ساعت پس از افشای عمومی، کد بهره‌برداری اثبات مفهوم در انجمن‌های امنیتی شروع به گردش کرد. این امر یک ساعت شنی را برای مدیران سیستم به کار انداخته است. تاریخ نشان می‌دهد که باندهای باج‌افزاری و هکرهای تحت حمایت دولت به سرعت چنین بهره‌برداری‌های با ارزشی را در جعبه ابزار خود ادغام می‌کنند و اغلب ظرف چند روز پس از انتشار، اینترنت را برای یافتن سیستم‌های وصله‌نشده اسکن می‌کنند.[1][3]

حادثه گوست‌لاک بحث دیرینه‌ای را در جامعه مهندسی نرم‌افزار در مورد ایمنی حافظه دوباره شعله‌ور کرده است. از آنجایی که هسته لینوکس با زبان C نوشته شده است – زبانی که توسعه‌دهندگان را ملزم به مدیریت دستی حافظه می‌کند – ذاتاً مستعد باگ‌های Use-After-Free و وضعیت‌های رقابتی است. این آسیب‌پذیری مهمات قدرتمندی را برای طرفدارانی فراهم می‌کند که برای بازنویسی زیرسیستم‌های حیاتی هسته در Rust، یک زبان مدرن که ایمنی حافظه را به صورت طراحی تضمین می‌کند، فشار می‌آورند.[2][4]

این آسیب‌پذیری ناشی از یک خطای مدیریت حافظه در زیرسیستم قفل‌گذاری فایل هسته است که در سال ۲۰۱۱ معرفی شد.
این آسیب‌پذیری ناشی از یک خطای مدیریت حافظه در زیرسیستم قفل‌گذاری فایل هسته است که در سال ۲۰۱۱ معرفی شد.

همچنین این حادثه نظریه «چشمان زیاد» در نرم‌افزار متن‌باز را به چالش می‌کشد، که فرض می‌کند عمومی کردن کد منبع تضمین می‌کند که باگ‌ها به سرعت پیدا و رفع می‌شوند. همانطور که گوست‌لاک نشان می‌دهد، وضعیت‌های رقابتی بسیار پیچیده و عمیقاً پنهان می‌توانند برای بیش از یک دهه از بررسی انسانی فرار کنند. کارشناسان امنیتی استدلال می‌کنند که اکوسیستم نیاز کمتری به بررسی دستی کد و سرمایه‌گذاری بیشتری در زیرساخت‌های فازینگ خودکار و مستمر دارد که توسط غول‌های فناوری که از لینوکس سود می‌برند، تأمین مالی شود.[4][8]

در حال حاضر، تمرکز فوری بر روی اصلاح و ترمیم باقی مانده است. جامعه امنیت سایبری برای ارائه راهنمایی‌های واضح و عملی بسیج شده است و ابزارهای اسکن را برای کمک به سازمان‌ها در شناسایی نسخه‌های آسیب‌پذیر هسته در سراسر ناوگان خود منتشر کرده است. در حالی که گوست‌لاک نشان‌دهنده یک شکست معماری جدی است، پاسخ هماهنگ و در سطح صنعت، انعطاف‌پذیری و بلوغ دستگاه امنیتی متن‌باز مدرن را برجسته می‌کند.[1][5]

در نهایت، گوست‌لاک به عنوان یک مطالعه موردی درسی هم در مورد شکنندگی زیرساخت‌های مشترک و هم در مورد مکانیسم‌های افشای آسیب‌پذیری مدرن عمل خواهد کرد. با درک مکانیسم دقیق این نقص، متخصصان فناوری اطلاعات بهتر مجهز می‌شوند تا نه تنها وصله فعلی را اعمال کنند، بلکه محیط‌های ابری مقاوم‌تر و با دفاع عمیق‌تری را طراحی کنند که بتوانند در برابر روز صفر هسته‌ای اجتناب‌ناپذیر بعدی مقاومت کنند.[3][8]

روند رویداد

  1. 2011

    یک بهینه‌سازی روتین در سیستم فایل لینوکس، کد معیوب قفل‌گذاری فایل را معرفی می‌کند.

  2. June 2026

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

  3. July 6, 2026

    محققان فرآیند افشای محرمانه را آغاز کرده و توزیع‌های اصلی لینوکس و ارائه‌دهندگان ابری را مطلع می‌سازند.

  4. July 13, 2026

    آسیب‌پذیری به همراه وصله‌های هماهنگ شده از سوی فروشندگان اصلی، به صورت عمومی فاش می‌شود.

بررسی عمیق دیدگاه‌ها

محققان امنیتی

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

برای جامعه تحقیقاتی دانشگاهی و مستقل امنیتی، گوست‌لاک تأییدی ناامیدکننده بر هشدارهای دیرینه آنها در مورد مدیریت حافظه مبتنی بر زبان C است. محققان اشاره می‌کنند که هیچ مقدار بررسی دستی کد نمی‌تواند به طور قابل اعتمادی وضعیت‌های رقابتی پیچیده و مبتنی بر زمان‌بندی را در یک پایگاه کد عظیم مانند هسته لینوکس شناسایی کند. آنها استدلال می‌کنند که این حادثه باید تلاش‌های جاری، و گاهی بحث‌برانگیز، برای بازنویسی زیرسیستم‌های حیاتی هسته در Rust را تسریع کند؛ زبان برنامه‌نویسی‌ای که به طور ساختاری از کامپایل شدن آسیب‌پذیری‌های Use-After-Free جلوگیری می‌کند.

مدیران فناوری اطلاعات سازمانی

بر چالش عملیاتی وصله‌گذاری سریع سیستم‌های حیاتی بدون ایجاد اختلال غیرقابل قبول در کسب‌وکار تمرکز دارند.

مدیران سیستم، آسیب‌پذیری‌هایی مانند گوست‌لاک را نه تنها به عنوان تهدیدات امنیتی، بلکه به عنوان اختلالات عملیاتی بزرگ می‌بینند. وصله‌گذاری یک نقص اصلی هسته در هزاران سرور معمولاً مستلزم هماهنگی راه‌اندازی‌های مجدد متوالی است که می‌تواند خدمات مشتری‌محور را مختل کرده و توافق‌نامه‌های سطح خدمات (SLA) را نقض کند. رهبران فناوری اطلاعات به طور فزاینده‌ای از پذیرش گسترده‌تر زیرساخت‌های وصله‌گذاری زنده حمایت می‌کنند و استدلال می‌کنند که توانایی تعویض سریع کد هسته در حافظه دیگر یک تجمل نیست، بلکه یک نیاز اساسی برای امنیت سازمانی مدرن است.

ارائه‌دهندگان خدمات ابری

بر اثربخشی اقدامات کاهشی در سطح هایپروایزر و وصله‌گذاری شفاف برای محافظت از زیرساخت‌های مدیریت شده تأکید می‌کنند.

ارائه‌دهندگان زیرساخت‌های بزرگ مانند AWS، Google Cloud و Azure حادثه گوست‌لاک را تأییدی بر مدل ابری مدیریت شده می‌دانند. از آنجایی که این شرکت‌ها لایه هایپروایزر زیر ماشین‌های مجازی مشتری را کنترل می‌کنند، توانستند قبل از عمومی شدن آسیب‌پذیری، اقدامات کاهشی در سطح شبکه و حافظه را اعمال کنند. از دیدگاه آنها، این حادثه نشان می‌دهد که پلتفرم‌های ابری متمرکز و با منابع کافی می‌توانند سریع‌تر و جامع‌تر از سازمان‌های منفردی که سرورهای فیزیکی خود را مدیریت می‌کنند، به تهدیدات روز صفر (zero-day) پاسخ دهند.

نگهدارندگان متن‌باز

بار سنگین ایمن‌سازی کدهای قدیمی چند ده ساله را برجسته کرده و خواستار افزایش بودجه شرکتی برای ممیزی‌های امنیتی خودکار هستند.

توسعه‌دهندگانی که هسته لینوکس را نگهداری می‌کنند، به عدم تقارن ذاتی در امنیت متن‌باز اشاره می‌کنند: گروه کوچکی از نگهدارندگان که عمدتاً داوطلب یا تحت حمایت بنیادها هستند، مسئول ایمن‌سازی کدی هستند که تریلیون‌ها دلار ارزش شرکتی تولید می‌کند. نگهدارندگان استدلال می‌کنند که در حالی که نظریه «چشمان زیاد» در متن‌باز برای باگ‌های عملکردی کار می‌کند، نقص‌های امنیتی عمیق نیازمند زیرساخت‌های فازینگ اختصاصی و پرهزینه هستند. آنها از افشای گوست‌لاک استفاده می‌کنند تا از غول‌های فناوری بخواهند که کمک‌های مالی خود به بنیاد لینوکس را به طور چشمگیری افزایش دهند، به ویژه برای ممیزی امنیتی خودکار و مستمر.

آنچه نمی‌دانیم

  • اینکه آیا گروه‌های تهدید پیشرفته و مستمر (APT) این نقص را قبل از افشای عمومی کشف کرده و بی‌سروصدا از آن استفاده کرده‌اند یا خیر.
  • دقیقاً چه تعداد از دستگاه‌های قدیمی اینترنت اشیا (IoT) و سامانه‌های توکار (Embedded Devices) به دلیل عدم پشتیبانی فروشنده برای به‌روزرسانی‌های هسته، برای همیشه آسیب‌پذیر باقی خواهند ماند.

اصطلاحات کلیدی

فرار از کانتینر (Container Escape)
یک رخنه امنیتی که در آن مهاجم از یک محیط نرم‌افزاری ایزوله (مانند کانتینر داکر) خارج می‌شود تا به سیستم عامل میزبان زیرین دسترسی پیدا کند.
دسترسی روت (Root Access)
بالاترین سطح امتیاز مدیریتی در سیستم عامل‌های لینوکس یا یونیکس‌مانند که کنترل کامل دستگاه را اعطا می‌کند.
وضعیت رقابتی (Race Condition)
نقص نرم‌افزاری که زمانی رخ می‌دهد که یک سیستم تلاش می‌کند دو یا چند عملیات را به طور همزمان انجام دهد، اما منطق سیستم ایجاب می‌کند که آنها در یک توالی خاص اتفاق بیفتند.
استفاده پس از آزادسازی (Use-After-Free)
نوع خاصی از آسیب‌پذیری فساد حافظه که در آن یک برنامه تلاش می‌کند به حافظه‌ای دسترسی پیدا کند که قبلاً خالی شده است، و به مهاجم اجازه می‌دهد کد مخرب را در آن فضا وارد کند.
فازینگ (Fuzzing)
یک تکنیک تست نرم‌افزاری خودکار که شامل وارد کردن حجم زیادی از داده‌های نامعتبر یا تصادفی به یک برنامه برای یافتن خطاهای کدنویسی و حفره‌های امنیتی است.
هایپروایزر (Hypervisor)
نرم‌افزاری که توسط ارائه‌دهندگان ابری برای ایجاد و اجرای ماشین‌های مجازی استفاده می‌شود و محیط‌های مجازی را از سخت‌افزار فیزیکی جدا می‌کند.

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

آیا کامپیوتر شخصی من تحت تأثیر گوست‌لاک قرار گرفته است؟

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

چگونه می‌توانم بفهمم سرورهای من آسیب‌پذیر هستند؟

اکثر توزیع‌های اصلی لینوکس توصیه‌های امنیتی را منتشر کرده‌اند که نسخه‌های خاص هسته آسیب‌دیده را فهرست می‌کند. مدیران می‌توانند از دستور `uname -r` برای بررسی نسخه فعلی خود در برابر نسخه‌های وصله‌شده استفاده کنند.

آیا برای رفع این مشکل باید سرورهایم را راه‌اندازی مجدد کنم؟

به طور سنتی بله. با این حال، سازمان‌هایی که از خدمات وصله‌گذاری زنده مانند Canonical Livepatch یا Red Hat Kpatch استفاده می‌کنند، می‌توانند اصلاحیه را بدون نیاز به راه‌اندازی مجدد سیستم، مستقیماً در حافظه هسته در حال اجرا اعمال کنند.

آیا گوست‌لاک در حملات سایبری واقعی استفاده شده است؟

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

منابع

پوشش منابع

8 منبع

4 دیدگاه شناسایی‌شده

محققان امنیتی 30%مدیران فناوری اطلاعات سازمانی 30%ارائه‌دهندگان خدمات ابری 20%نگهدارندگان متن‌باز 20%
  1. [1]BleepingComputerمدیران فناوری اطلاعات سازمانی

    15-Year-Old 'GhostLock' Linux Flaw Allows Container Escapes

    مطالعه در BleepingComputer
  2. [2]Ars Technicaمحققان امنیتی

    How a 2011 code commit created GhostLock, the decade's worst Linux bug

    مطالعه در Ars Technica
  3. [3]The Hacker Newsمدیران فناوری اطلاعات سازمانی

    Linux Admins Scramble to Patch GhostLock as PoC Exploits Emerge

    مطالعه در The Hacker News
  4. [4]Wiredنگهدارندگان متن‌باز

    The GhostLock Flaw Proves We Need to Rethink Open-Source Security

    مطالعه در Wired
  5. [5]Red Hat Security Advisoryنگهدارندگان متن‌باز

    CVE-2026-44012: Privilege escalation via race condition in fs/locks.c

    مطالعه در Red Hat Security Advisory
  6. [6]Ubuntu Security Noticeنگهدارندگان متن‌باز

    USN-6892-1: Linux kernel vulnerability

    مطالعه در Ubuntu Security Notice
  7. [7]AWS Security Blogارائه‌دهندگان خدمات ابری

    AWS Customer Advisory on CVE-2026-44012 (GhostLock)

    مطالعه در AWS Security Blog
  8. [8]Dark Readingمحققان امنیتی

    GhostLock Container Escape Threatens Core Cloud Infrastructure

    مطالعه در Dark Reading
همیشه در جریان باشید

هر زاویه. هر روز.

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