🔻حمله سایبری به NHS باعث مرگ یک بیمار شد

🔹بنیاد درمانی کینگ کالج اعلام کرد که یک بیمار در جریان حمله سایبری سال گذشته به سرویس ملی بهداشت بریتانیا (NHS) پس از آن‌که به دلیل انتظار طولانی برای دریافت نتیجه آزمایش خون خود دچار مشکل شد، به‌طور غیرمنتظره‌ای جان خود را از دست داد.

🔹دریک میچلسون، رئیس سابق امنیت اطلاعات NHS اسکاتلند و مدیر فعلی امنیت سایبری شرکت چک پوینت در این مورد، خطاب به عاملان این حمله گفت: شما فقط به سیستم‌ها یا داده‌ها حمله نکردید بلکه سلامت انسان‌ها را هدف قرار دادید. شما مردم را هدف گرفتید و اکنون یکی از آن‌ها جان خود را از دست داده است. این مسئولیت بزرگی است.

➖شرکت Synnovis که در جنوب شرقی لندن، خدمات آزمایش خون ارائه می‌دهد، سوم ژوئن سال 2024 هدف یک حمله باج‌افزاری قرار گرفت که تصور می‌شود توسط گروه روسی Qilin انجام شده باشد.




در کشور ما قرار هست کی پاسخگو باشند ؟؟؟

گروه APT Iran مدعی نفوذ به سامانه سوخت‌رسانی آمریکا شده است

در بیانیه این گروه آمده است:
ما اعلام می‌داریم که در سه روز گذشته، چندین حمله موفق از نوع "False Data Injection" به دستگاه‌های کنترلی در ایالات متحده آمریکا که از خدمات AT&T استفاده می‌کنند، انجام دادیم. این حملات با تغییر مقادیر ثبت‌کننده‌ها (registers) و تزریق داده‌ها با فرکانس ۶۰۰ دور در دقیقه اجرا شده‌اند. همان‌طور که در تصویر ارسالی مشاهده می‌شود، ابزارهایی توسط ما توسعه یافته‌اند که به‌طور خاص برای ایجاد اخلال و نابودی با سرعت بالا در خواندن و نوشتن اطلاعات در این سیستم‌ها طراحی شده‌اند.

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

گزارش یک نظرسنجی از صد متخصص حوزه‌ ابری و امنیت درباره وضعیت امنیت هوش مصنوعی در سازمان‌هایشان، تصویر نسبتا دقیقی از مراحل اولیه بلوغ امنیت در حوزه‌ هوش مصنوعی و خطرات آن ارائه می‌دهد.
منبع : bleepingcomputer
گزارش یک نظرسنجی از صد متخصص حوزه‌ ابری و امنیت درباره وضعیت امنیت هوش مصنوعی در سازمان‌هایشان، تصویر نسبتا دقیقی از مراحل اولیه بلوغ امنیت در حوزه‌ هوش مصنوعی و خطرات آن ارائه می‌دهد.
 
گزارش نظرسنجی Wiz و Gatepoint Research از صد متخصص حوزه‌ ابری و امنیت ـ از معماران و مهندسان گرفته تا مدیران ارشدـ نشان می‌دهد سازمان‌ها در مسیر ابری خود در چه مرحله‌ای هستند، چطور از هوش مصنوعی استفاده می‌کنند، دغدغه‌های اصلی‌شان چیست و چه راهکارهایی را برای حفاظت از این محیط‌های پویا در پیش گرفته‌اند یا نگرفته‌اند. یافته‌های این نظرسنجی، تصویری واقعی و دست‌اول از مراحل اولیه بلوغ امنیت در حوزه‌ هوش مصنوعی ارائه می‌دهد و خطراتی را که همراه آن است ترسیم می‌کند.
 
استفاده از هوش مصنوعی تقریباً همه‌گیر شده اما تخصص امنیتی در این زمینه عقب مانده است
۸۷٪ از پاسخ‌دهندگان به نوعی از خدمات هوش مصنوعی استفاده می‌کنند. اما ۳۱٪ می‌گویند نبود تخصص در امنیت هوش مصنوعی، بزرگ‌ترین چالش آن‌هاست . در حالی که نوآوری در حوزه‌ هوش مصنوعی سرعت گرفته، تیم‌های امنیتی عقب مانده‌اند.
 
ابزارهای اختصاصی امنیت هوش مصنوعی هنوز کمیاب‌اند و کنترل‌های سنتی همچنان غالب‌اند
فقط ۱۳٪ گفته‌اند که از ابزارهای مدیریت وضعیت اختصاصی برای هوش مصنوعی (AI-SPM) استفاده می‌کنند. در مقابل، راهکارهای امنیتی سنتی بسیار رایج‌ترند: ۵۳٪ شیوه‌های توسعه امن را پیاده کرده‌اند، ۴۱٪ از  tenant isolation  استفاده می‌کنند و ۳۵٪ ممیزی‌های منظم برای شناسایی «هوش مصنوعی در سایه» انجام می‌دهند. این کنترل‌های پایه‌ای اهمیت زیادی دارند، اما به‌تنهایی پاسخگوی سرعت، مقیاس و پیچیدگی رشد هوش مصنوعی نیستند.

#security #ai
@unixmens

زیرساخت‌های ترکیبی و چندابری به یک هنجار جدید تبدیل شده‌اند اما ابزارها هنوز عقب‌اند
۴۵٪ از پاسخ‌دهندگان از رایانش ابری ترکیبی استفاده می‌کنند و ۳۳٪ در محیط‌های چندابری فعالیت دارند. با این حال فقط یک‌سوم از پلتفرم‌های بومی ابری مانند CNAPP یا CSPM بهره می‌برند. بیشتر تیم‌ها همچنان به روش‌های امنیتی نقطه‌ای متکی‌اند که برای زیرساخت‌های مدرن ـ یا بار کاری مرتبط با هوش مصنوعی ـ مقیاس‌پذیر نیستند.

سازمان‌ها می‌دانند از امنیت هوش مصنوعی چه می‌خواهند اما همیشه نمی‌توانند عمل کنند
وقتی از شرکت‌کنندگان درباره اولویت‌های اصلی امنیت هوش مصنوعی پرسیده شد، «حفظ حریم خصوصی داده‌ها» (۶۹٪)، «دید کامل نسبت به تهدیدات» (۶۲٪) و «سهولت در یکپارچه‌سازی» (۵۱٪) را مهم‌ترین موارد دانستند.

با این حال ۲۵٪ هم اعتراف کردند که اصلاً نمی‌دانند چه خدمات هوش مصنوعی در محیط‌هایشان در حال اجراست! یعنی با وجود اهداف مشخص، بسیاری از تیم‌ها هنوز دید کافی یا فرآیندهای عملیاتی لازم را برای رسیدن به این اهداف ندارند، به‌ویژه در محیط‌های غیرمتمرکزی که هوش مصنوعی اغلب بدون نظارت مرکزی وارد می‌شود.

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

با مفهوم pod و deployment و تفاوت های آن آشنا شویم :

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

در کوبرنتیز، پاد به یک کانتینر تنها یا مجموعه‌ای از کانتینرهای مرتبط به هم گفته می‌شود که منابع ذخیره‌سازی اپلیکیشن و شبکه‌های مربوط به آن را به اشتراک می‌گذارند. پاد به عنوان کوچک‌ترین و جزئی‌ترین عضو کلاستر در سرویس کوبرنتیز شناخته می‌شود

یک توسعه‌دهنده یا مدیر پروژه یا دواپس مجموعه‌ای از پادهای لازم برای اجرای یک اپلیکیشن را در کوبرنیتز طراحی می‌کند. سرویس کوبرنتیز نیز به واسطه توانایی در مدیریت داده‌ها می‌تواند این اطلاعات گوناگون در پادهای مختلف را مدیریت کند
دیپلویمنت در سرویس کوبرنتیز رفتار یا ویژگی‌های مدنظر درباره یک کانتینر را مشخص می‌کند. مدیران پروژه‌های مختلف از دیپلویمنت برای شخصی‌سازی و تخصصی‌کردن رفتار هر پاد در پروژه خود استفاده می‌کنند. در واقع ویژگی هایی که در deployment هست . در pod نیست !!!

در زیر به برخی از ویژگی‌ها و قابلیت‌هایی که Deployment دارد و Pod ندارد، اشاره میکنم :
1. مدیریت نسخه‌ها (Versioning)

ا Deployment: امکان مدیریت نسخه‌های مختلف یک برنامه را فراهم می‌کند. شما می‌توانید به راحتی نسخه‌های جدید را مستقر کنید و در صورت نیاز به نسخه‌های قبلی برگردید.
ا Pod: فقط یک نمونه از یک کانتینر را اجرا می‌کند و هیچ قابلیت مدیریت نسخه ندارد.

2. تدریجی بودن استقرار (Rolling Updates)

ا Deployment: به شما این امکان را می‌دهد که به‌روزرسانی‌ها را به صورت تدریجی انجام دهید، به طوری که تعداد مشخصی از پادها به‌روزرسانی شوند و در صورت بروز مشکل، به حالت قبلی برگردند.
ا Pod: به‌روزرسانی‌ها را به صورت دستی و بدون کنترل بر روی تعداد پادهای در حال اجرا انجام می‌دهد.

3. خودکارسازی (Self-healing)

ا Deployment: در صورت بروز خطا در یکی از پادها، به طور خودکار آن را جایگزین می‌کند و اطمینان حاصل می‌کند که تعداد مشخصی از پادها همیشه در حال اجرا هستند.
ا Pod: خود به خود نمی‌تواند پادهای معیوب را جایگزین کند و نیاز به مدیریت دستی دارد.

4. مقیاس‌پذیری (Scaling)

ا Deployment: می‌توانید به راحتی تعداد پادها را افزایش یا کاهش دهید و این تغییرات به طور خودکار در کلاستر اعمال می‌شود.
ا Pod: برای مقیاس‌پذیری، باید پادهای جدید را به صورت دستی ایجاد کنید.

5. مدیریت وضعیت (State Management)

ا Deployment: وضعیت فعلی و مورد انتظار پادها را پیگیری می‌کند و در صورت نیاز به طور خودکار به وضعیت مطلوب برمی‌گردد.
ا Pod: فقط وضعیت خود را نشان می‌دهد و هیچ قابلیت مدیریت وضعیت ندارد.

6. استفاده از الگوها (Templates)

ا Deployment: از الگوهای (templates) برای تعریف نحوه ایجاد پادها استفاده می‌کند، که شامل تنظیمات کانتینر، برچسب‌ها و سایر ویژگی‌ها است.
ا Pod: فقط یک نمونه از یک کانتینر را تعریف می‌کند و هیچ الگوی خاصی ندارد.


خب شیرین بود ؟؟؟؟


خب حالا ما فرضا یه pod داریم . آیا میتونیم تبدیلش کنیم به deployments ؟؟؟؟


باید گفت : بلی


مراحل تبدیل Pod به Deployment

دریافت تنظیمات Pod:
ابتدا باید تنظیمات Pod فعلی خود را دریافت کنید. می‌توانید از دستور زیر استفاده کنید:




kubectl get pod <pod-name> -o yaml > pod.yaml


این دستور تنظیمات Pod را در یک فایل به نام pod.yaml ذخیره می‌کند.

فایل pod.yaml را باز کنید و تغییرات اعمال کنید:

تغییر نوع منبع: در بالای فایل، kind: Pod را به kind: Deployment تغییر دهید.
اضافه کردن metadata: یک بخش spec جدید اضافه کنید که شامل تعداد تکرارها (replicas) و الگوی (template) Pod باشد.
تنظیمات selector: یک بخش selector اضافه کنید که برچسب‌های Pod را مشخص کند.

به عنوان مثال، فایل شما ممکن است به شکل زیر باشد:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  selector:
         ...

در ادامه

kubectl apply -f deployment.yaml

نکته : اگر دیگر به Pod قدیمی نیاز ندارید، می‌توانید آن را حذف کنید

    kubectl delete pod <pod-name>

نکات :

تعداد تکرارها: در بخش replicas می‌توانید تعداد پادهایی که می‌خواهید در حال اجرا باشند را مشخص کنید.
برچسب‌ها: اطمینان حاصل کنید که برچسب‌ها در بخش selector و template یکسان باشند تا Deployment بتواند پادها را به درستی مدیریت کند.

با این مراحل، شما می‌توانید یک Pod را به یک Deployment تبدیل کنید و از قابلیت‌های بیشتر Deployment در کوبرنتیز بهره‌مند شوید.
#kubernetes #k8s #tips

https://t.iss.one/unixmens

Model Context Protocol (MCP) is a powerful protocol from Anthropic that defines how to connect large language models (LLMs) to external tools. It has quickly gained traction due to its ease of use and the benefits it adds in our use of AI. In this article we'll cover some of the potential security risks you'll encounter with MCP and how you can approach mitigating them.How MCP worksMCP does not directly connect LLMs with tools. The MCP client component accesses the LLM, and the MCP server component accesses the tools. One MCP client has access to one or more MCP servers. Users may connect any

via Red Hat Blog https://ift.tt/izaA2So

The topic of virtualization is often the subject of enhanced scrutiny in health insurance organizations. Insurers use it to provide secure, remote access to data and applications for employees, boosting efficiency and collaboration. For their members, virtualization enables virtual care, self-service tools, faster claims and personalized support, improving satisfaction and health outcomes in a digital world.When a U.S.-based health insurer faced the need to move to a more modern virtualization platform, it required a swift and reliable path forward—one that would meet today’s evolving dema

via Red Hat Blog https://ift.tt/YJt8sjK

یارب
الله الله. فریاد
( موسیقی امام حسین - محرم)

امام حسین (ع)
#book

لاله اکبر
( موسیقی امام حسین - محرم)

موسیقی امام حسین - محرم

موسیقی امام حسین - محرم

( موسیقی امام حسین - محرم)

از سنگ صدا آمد از اهل صدا نه

( موسیقی امام حسین - محرم )

تکیه

( موسیقی امام حسین - محرم)

true #fact


«کسانی که بدون دلیل باور کرده‌اند را نمی‌توان با دلیل قانع کرد.»

این جمله یکی از نقل‌قول‌های معروف است که معمولاً به جاناتان سویفت (Jonathan Swift) یا گاهی به کارل پوپر نسبت داده می‌شود (هرچند ممکن است منابع مختلف نویسنده را متفاوت ذکر کنند).



#iran

🌀 ۱. تحلیل دیالکتیکی

«کسانی که بدون دلیل باور کرده‌اند را نمی‌توان با دلیل قانع کرد.»

در منطق دیالکتیک هگلی، حرکت اندیشه در سه مرحله است: تز ← آنتی‌تز ← سنتز.

تز: باور بدون دلیل (dogmatic belief)

آنتی‌تز: ارائه دلایل عقلانی برای نفی آن باور

سنتز: در حالت ایده‌آل، باید تعاملی میان باور اولیه و دلیل جدید رخ دهد و آگاهی جدیدی شکل بگیرد.

اما این جمله نشان می‌دهد که فرد در تز باقی مانده و حاضر به پذیرش آنتی‌تز نیست. یعنی ذهنش به مرحله‌ی دیالکتیکی ورود نکرده است. او در ثبات ایدئولوژیک گیر افتاده، نه در جریان تحول آگاهی.

💡 نتیجه: دیالکتیک نیازمند آمادگی برای مواجهه با تضاد است، اما فردی که از ابتدا انتخابش "بدون دلیل" بوده، از تضاد گریزان است.
🌌 ۲. تحلیل اگزیستانسیالیستی

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

باور بدون دلیل، اغلب از فرار از آزادی (به تعبیر اریک فروم) نشأت می‌گیرد. یعنی فرد به جای مسئولیتِ درک و انتخاب، ترجیح می‌دهد به چارچوب‌های آماده و تحمیل‌شده پناه ببرد.

وقتی کسی به شکل غیر اصیل به چیزی ایمان آورده، آن ایمان به بخش ثابتی از هویت او بدل شده است. به همین خاطر هر گونه چالش منطقی، تهدیدی برای "خودِ وجودی" او تلقی می‌شود.

💡 نتیجه: در اگزیستانسیالیسم، گفت‌وگو فقط با انسانی ممکن است که مسئولیت‌پذیر و ریشه‌دار در آزادی‌اش باشد.
🏛 ۳. تحلیل تحول سازمانی / فرهنگی

در حوزه‌ی تغییر سازمانی یا فرهنگی، این جمله مصداق مقاومت در برابر تغییر ذهنیت‌ها (Mindset Shift) است.

افراد یا سازمان‌هایی که به الگوهای ذهنی غیرمنطقی (یا مبتنی بر سنت صرف، تعصبات، یا عادات قدیمی) باور دارند، با ابزارهای منطقی قابل قانع شدن نیستند.

مدل تغییر ذهنیت "لَوی" (Robert Kegan's Immunity to Change) نیز می‌گوید: تغییر، نه با ارائه دلیل، بلکه با فهم و حلِ "دغدغه‌های پنهان" و "باورهای محافظت‌شده" رخ می‌دهد.

💡 نتیجه: در سازمان‌ها، صرفاً با دیتا یا بیزنس‌کیس نمی‌توان مقاومت را شکست. باید به سطح باورهای پنهان و احساس امنیت روانی ورود کرد.

کسی را که با قلبش به دروغی پناه برده
با عقل، راهی به روشنایی نیست
مگر آنکه در آینه‌ی خودش
جرقه‌ای از شک ببینَد... 🌟

IntroductionDR strategies for virtual machines (VMs) on Red Hat OpenShift are essential to maintaining business continuity during unplanned outages. As organizations migrate critical workloads to Kubernetes platforms, the ability to recover those workloads quickly and reliably becomes a key operational requirement.While ephemeral, stateless VMs have become common in cloud-native environments, most enterprise VM workloads remain stateful. These VMs require persistent block storage that can be reattached during restarts or migrations. As a result, DR for stateful VMs presents challenges that dif

via Red Hat Blog https://ift.tt/uBXIxFZ

TL;DRThe article details the evolution of Red Hat’s AI-driven support case summarization feature through its transition to Granite models. Initially built using a Mistral model, evaluations showed that Granite performed better using Red Hat’s production data, leading to an increase in case summarization use and user productivity. Future plans include evaluating multilingual support and higher context limits for more comprehensive summaries.How we started In Red Hat’s global support organization, “Follow the Sun" (FTS) cases are recognized as a top priority, requiring smooth transitions

via Red Hat Blog https://ift.tt/u9qmMr5