در بحث امنیت سلامت و بیمارستان، تمرکز معمولاً روی تجهیزات پزشکی و شبکه‌ی داخلی است. اما دادهی حساس بیمار امروز از مسیر دیگری در دسترس است: پورتال بیمار، سامانه‌ی نوبتدهی آنلاین، پنل مشاهده‌ی نتایج آزمایش و APIهایی که اپلیکیشن‌های سلامت از آن‌ها تغذیه میکنند. همه‌ی این‌ها برنامه‌ی وب‌اند، از اینترنت در دسترس‌اند، و حساس‌ترین دسته‌ی دادهی شخصی را نگه می‌دارند — ترکیبی که آن‌ها را به پرارزش‌ترین هدف این حوزه تبدیل می‌کند.
در یک نگاه
- پورتال بیمار و سامانه‌ی نوبتدهی، برنامه‌ی وب‌اند و همان دسته‌های OWASP Top 10:2025 روی آن‌ها صدق می‌کند.
- OWASP در دسته‌ی
A04:2025صریحاً پروندهی سلامت را در کنار گذرواژه و شماره‌ی کارت، دادهی نیازمند حفاظت در حال انتقال و سکون می‌داند. - پرخطرترین یافته‌ی این حوزه: IDOR روی شناسهی بیمار یا شناسهی نتیجهی آزمایش.
- OWASP نمونه‌ای مستند دارد: رخنه‌ای که ۳٫۵ میلیون کودک را درگیر کرد و از سال ۲۰۱۳ به‌دلیل نبود ثبت رخداد و پایش کشف نشده بود.
سطح حمله‌ی یک سازمان درمانی
آنچه از اینترنت در دسترس است و همگی برنامه‌ی وب‌اند:
- پورتال بیمار: مشاهده‌ی پرونده، نتایج آزمایش، تصاویر تصویربرداری و نسخه‌ها؛
- سامانه‌ی نوبتدهی آنلاین و پرداخت مرتبط با آن؛
- پنل پزشک و کارکنان، که گاهی روی همان دامنه و بدون جداسازی مناسب قرار دارد؛
- APIهای اپلیکیشن موبایل سلامت و سرویس‌های یکپارچه‌سازی با آزمایشگاه‌ها و بیمه؛
- سامانههای پشتیبان مانند فرم‌های ثبت‌نام و سیستم تیکتینگ که فایلهای پزشکی در آن‌ها بارگذاری می‌شود.
نکته‌ی مشترک همه‌ی این موارد این است که هیچکدام «تجهیزات پزشکی» نیستند و هیچکدام هم با کنترل‌های شبکه‌ای محافظت نمیشوند؛ ترافیک‌شان از دید فایروال، درخواست HTTPS کاملاً عادی است.
مورد آخر منبع تکرارشونده‌ی نشت است: فایل‌هایی که کاربران بارگذاری میکنند و در مسیری با نام قابل حدس یا بدون بررسی مجوز ذخیره می‌شوند. این دقیقاً همان الگویی است که در کنترل دسترسی شکسته توضیح داده شده.
چرا دادهی سلامت متفاوت است
سه ویژگی که این داده را از دادهی معمولی جدا می‌کند:
- غیرقابل تغییر است. شماره‌ی کارت را می‌توان باطل کرد؛ سابقه‌ی پزشکی را نمی‌توان.
- پیامد افشا شخصی و بلندمدت است و به سادگی قابل جبران مالی نیست.
- دسترسی داخلی گسترده است. در یک سازمان درمانی، تعداد افرادی که به‌دلیل شغلی به پرونده دسترسی دارند زیاد است و همین، کنترل دسترسی دقیق و مسیر ممیزی را حیاتی می‌کند.
OWASP در دسته‌ی A04:2025 (نقص‌های رمزنگاری) پروندهی سلامت را به‌صراحت در فهرست داده‌هایی می‌آورد که باید در حال انتقال و در حال سکون محافظت شوند، و به تعهدات مقرراتی مرتبط با حفاظت از داده اشاره می‌کند. توصیه‌های همان دسته:
- طبقه‌بندی داده و اعمال رمزنگاری بر پایه‌ی آن؛
- رمزنگاری انتقال با TLS نسخه‌ی ۱٫۲ به بالا؛
- نگه‌داری کلیدها در سرویس مدیریت کلید یا ماژول سخت‌افزاری، نه در فایل پیکربندی؛
- هش گذرواژه با الگوریتم مناسب و نمک‌دار مانند Argon2؛
- کنارگذاشتن الگوریتم‌های منسوخ مانند MD5 و SHA-1.
کنترل دسترسی: پرخطرترین دسته در این حوزه
در سامانههای درمانی، پرتکرارترین یافته‌ی پرخطر IDOR است: تغییر شناسهی بیمار، شناسهی نوبت یا شناسهی نتیجهی آزمایش در آدرس یا بدنه‌ی درخواست، و دریافت دادهی فرد دیگر.
| الگوی نادرست | چرا شکست می‌خورد | کنترل درست |
|---|---|---|
| بررسی مجوز فقط در صفحه‌ی فهرست | صفحه‌ی جزئیات مستقیماً قابل فراخوانی است | بررسی مالکیت در هر درخواست، در لایه‌ی داده |
| پنهان‌کردن گزینه در رابط کاربری | کنترل سمت کاربر، کنترل نیست | رد پیش‌فرض در سمت سرور |
| استفاده از شناسهی تصادفی به‌جای بررسی مجوز | شناسه از گزارش، ارجاع‌دهنده یا نقطه‌ی انتهایی دیگر نشت می‌کند | شناسهی غیرقابل حدس به‌علاوه‌ی بررسی مجوز |
| اتکا به نقش بدون بررسی رابطه | پزشک هست، اما پزشک این بیمار نیست | بررسی رابطهی درمانی، نه فقط نقش |
| فایلهای پزشکی روی مسیر عمومی | نام فایل قابل حدس یا فهرست‌شدنی است | سرو فایل از مسیر کنترل‌شده با بررسی مجوز |
«شناسه‌های ما UUID هستند، پس IDOR نداریم.» شناسهی تصادفی فقط هزینهی کشف را بالا میبرد؛ هیچ بررسی مجوزی اضافه نمیکند. این شناسهها مرتب از جاهای دیگر نشت میکنند: خروجی گزارشها، پیامهای اشتراکگذاری، هدر ارجاع‌دهنده، و نقاط انتهایی دیگری که فهرست برمی‌گردانند. اگر مهاجم شناسه را به‌دست بیاورد و سرور مجوز را بررسی نکند، آسیب‌پذیری همان‌جاست.
توان تشخیص: بخشی که همیشه فراموش می‌شود
OWASP در دسته‌ی A09:2025 نمونه‌ای مستند از همین حوزه نقل می‌کند: رخنه‌ای در یک ارائه‌دهنده‌ی طرح سلامت کودکان که ۳٫۵ میلیون کودک را تحت تأثیر قرار داد و از سال ۲۰۱۳ کشف نشده بود، چون ثبت رخداد و پایش کافی وجود نداشت. کشف نهایی هم با اطلاع یک نهاد بیرونی انجام شد.
حداقل ثبت رخدادی که یک سامانه‌ی درمانی نیاز دارد:
- هر دسترسی به پروندهی بیمار، با شناسهی کاربر، شناسهی بیمار و زمان؛
- هر شکست مجوزدهی — این‌ها ارزشمندترین سیگنال‌اند و معمولاً اصلاً ثبت نمیشوند؛
- خروجیگیری و دانلود انبوه — الگوی رفتاری مهاجم و کارمند متخلف یکسان است؛
- تغییر دسترسی و ایجاد حساب جدید.
شرط اثربخشی این فهرست، وجود قاعده‌ی هشدار است. لاگی که جمع می‌شود و هیچ‌کس آستانه‌ای برایش تعریف نکرده، فقط فضای دیسک مصرف می‌کند — و همین تفاوت میان «پایش» و «هشداردهی» است که OWASP در نام‌گذاری تازه‌ی این دسته بر آن تأکید کرده.
و دو نکته‌ی مکمل از توصیه‌های همان دسته: خروجی لاگ باید کدگذاری شود تا امکان تزریق به لاگ از بین برود، و لاگ نباید خود حاوی دادهی حساس باشد. نشانه‌های عملی این‌که چیزی درست نیست در نشانه‌های هک شدن سایت فهرست شده است.
نقطه‌ی شروع برای یک سازمان درمانی
- موجودی سرویس‌های در معرض اینترنت، شامل پنل‌های قدیمی و سامانههای پیمانکاران.
- بازبینی متمرکز مجوزدهی با تمرکز بر رابطهی درمانی، نه فقط نقش کاربری.
- کنترل مسیر فایل‌ها: سرو تصاویر و نتایج از مسیر کنترل‌شده با بررسی مجوز.
- رمزنگاری و مدیریت کلید مطابق توصیه‌های
A04:2025. - ثبت رخداد و هشدار روی دسترسی به پرونده و خروجیگیری انبوه.
- ارزیابی مستقل — تست نفوذ وب روی پورتال بیمار و APIها.
ترتیب این فهرست عمدی است: کنترل دسترسی پیش از رمزنگاری آمده، چون در این حوزه بیشتر نشت‌های واقعی از نقص مجوزدهی رخ می‌دهند نه از شکسته‌شدن رمزنگاری. چرخه‌ی پیگیری یافته‌ها هم در مدیریت آسیب‌پذیری آمده و اگر ریشه‌ی یافته‌ها الگوی کدنویسی است، دوره‌ی سازمانی توسعه‌ی امن اثر پایدارتری دارد.
پرسش‌های متداول
امنیت سایبری در بیمارستان از کجا باید شروع شود؟
از سامانههای در معرض اینترنت — پورتال بیمار، نوبتدهی و APIها — چون بیشترین دادهی حساس از همانجا در دسترس است. گام نخست، موجودی این سرویسها و سپس بازبینی متمرکز کنترل دسترسی روی پروندهی بیمار است.
چرا دادهی سلامت هدف جذابی است؟
چون غیرقابل تغییر است، پیامد افشایش شخصی و بلندمدت است، و در سازمان درمانی تعداد زیادی کاربر به‌دلیل شغلی به آن دسترسی دارند. همین گستردگی دسترسی داخلی، کنترل دقیق مجوزدهی و مسیر ممیزی را حیاتی می‌کند.
پورتال بیمار چه آسیبپذیریهایی دارد؟
پرتکرارترینها: IDOR روی شناسهی بیمار یا نتیجهی آزمایش، دسترسی به فایلهای پزشکی از مسیر عمومی، بررسی نقش بدون بررسی رابطهی درمانی، و نبود ثبت رخداد روی دسترسی به پرونده. هیچکدام با رمزنگاری یا فایروال حل نمیشوند.
استفاده از UUID جلوی IDOR را میگیرد؟
نه. شناسهی تصادفی فقط هزینهی حدسزدن را بالا میبرد و هیچ بررسی مجوزی اضافه نمیکند. این شناسهها از گزارشها، پیامهای اشتراکگذاری و نقاط انتهایی دیگر نشت میکنند. راهکار درست، ترکیب شناسهی غیرقابل حدس با بررسی مالکیت در سمت سرور است.
چه چیزی را باید در لاگ ثبت کنیم؟
دسترسی به پروندهی بیمار با شناسهی کاربر و بیمار، شکستهای مجوزدهی، خروجیگیری و دانلود انبوه، و تغییرات دسترسی. لاگ نباید خودش دادهی حساس داشته باشد و خروجی آن باید کدگذاری شود تا امکان تزریق به لاگ از بین برود.
منابع
مهدی مرادلو
محقق امنیتی با تمرکز روی منطق کسب‌وکار و زنجیره‌های حمله‌ی پیچیده. اسکوپ‌بندی پروژه‌ها و تضمین کیفیت گزارشها با اوست.