تنها وبسایت رسمی شرکت نوآوران سلامت گستر شریف noavaran-sharif.ir و noavaran-sharif.com

راه ارتباطی ما با شما سامانه پیامکی 50002210801

تنها لوگو رسمی ثبت شده شرکت نو آوران سلامت گستر شریف نوآوران شریف میباشد.

مقاله
سیستم قابل اعتماد وقت‌دهی قرار ملاقات آنلاین برای NHIS سرپایی در بیمارستان‌های آموزش نیجریه
بهمن ۲, ۱۳۹۵
مقاله
MedCloud: سیستم رایانش ابری بهداشت و درمان
بهمن ۲, ۱۳۹۵

مدیریت امنیت پایگاه داده برای نرم افزار به عنوان خدمتِ بهداشت و درمان در ابر AWS آمازون

مقاله

۴ AAA در AWS: موردپژوهی VITAEVER

Vitaever یک خدمت نرم­افزار به عنوان خدمت برای مدیریت خدمات کمک­های پزشکی در خانه و به روشی ساده با یک رابط دوستانه با کاربر و مبتکرانه است که از ظرفیت مدل تجاری فنی رایانش ابری به منظور ذخیره­سازی­های زیادی برای کاربران نهایی استفاده می­کند: بدون هزینه­های جواز، نصب، ارتقا و نگه­داری زیرساخت سخت­افزاری و نرم­افزاری است و تنها هزینه­ی آن، هزینه­ی پرداخت به ازای استفاده و وابسته به تعداد کاربران ایجاد شده و تعداد تعاملات است.

Vitaever تمامی خدمات موردنیاز برای پشتیبانی از تجهیزات بهداشت و درمان در درمان بیماران در خانه­ی خودشان را به وسیله­ی تسهیل ارتباط و تعامل میان تمامی افراد و ساختارهای درگیر در چنین درمانی امکان­پذیر می­سازد به طوری که دارای کنترل بهتری از کل فرآیند و کاهش قابل توجهی در هزینه­های عملیاتی خواهیم بود. Vitaever اجازه­ی سازمان­دهی آسان فعالیت­های کارکنان و بهینه­سازی حرکت در این محدوده را به وسیله­ی اعطای دسترسی فراگیر نرم­افزار به عنوان خدمت مبتنی بر ابر به کاربرد فراهم می­آورد و می­تواند توسط بیمارستان­ها و در یک یا چندین بخش بهداشت و درمان استفاده شود به طوری که تعداد نامحدودی از کاربران از طریق دستگاه­های ثابت یا قابل حمل به آن دسترسی دارند. Vitaever به طور خودکار گزارش­ها را ایجاد کرده و داشبوردهای مبتکرانه­ای به منظور ایجاد خلاصه­ها و نظارت پویا بر فعالیت­های همکاران و منابع استفاده شده توسط سیستم ارائه می­دهد.

Vitaever توجه ویژه­ای به اظهارات محرمانگی دارد و حفاظت از داده­های حساس شخصی هر کاربر که به کاربرد نرم­افزار به عنوان خدمت دسترسی دارد را تضمین می­کند. در ادامه، مؤلفه­های اصلی نرم­افزار به عنوان خدمت Vitaever از دیدگاه امنیت داده معرفی و تحلیل می­شوند و به طور خاص، برای هر یک از آن­ها بر روی تلاش­های مورد نیاز یکپارچگی آن­ها با مؤلفه­های موجود AWS، طراحی اضافه و فعالیت­های پیاده­سازی برای تحلیل مؤلفه­های جدید و مورد نیاز تأکید شده است. به طور کلی، پیش­بینی می­شود که زیرساخت به عنوان خدمت کنونی پشتیبانی و ضمانت امنیت داده­ی در حال حرکت را فراهم می­آورد، در حالی که حصول امنیت داده­ی ثابت نیازمند تغییر کد کاربرد و شمای پایگاه داده برای پشتیبانی از رمزنگاری داده است. برای شرح بهتر تغییرات مورد نیاز، در ادامه معماری کلی مبتنی بر خدمات AWS آمازون بدون امنیت داده­ی ثابت نشان داده می­شود. سپس، در بخش بعد تمامی تغییرات عمده­ی مورد نیاز برای حصول کامل پشتیبانی از امنیتِ سازگار با HL7/ HIPAA به تفصیل شرح داده می­شوند.

معماری اولیه­ی Vitaever در زیرساخت به عنوان خدمتِ AWS در آمازون (شکل ۱) می­تواند به سه سطح تقسیم شود: تعادل بار، خدمت وب، و ذخیره­سازی/ پایگاه داده. در ابتدا، در سطح بالایی یعنی تعادل بار، ELB و AS فراهم­آوری منعطف منابع را مدیریت می­کنند. سطح میانی یعنی خدمت وب، هسته­ی نرم­افزار به عنوان خدمت Vitaever است و شامل یک کاربرد مبتنی بر PHP و بدون حالت است که تمامی عملکردهای کسب­وکار و رابط­های کاربر را تحقق می­بخشد. با تمرکز بر سازمان­دهی داخلی، جزئیات معماری کلی AWS در شکل ۱ بدین صورت است: هر نمونه­ی (کوچک) EC2 از آمازون یک سرور وب ایجادشده توسط PHP را اجرا می­کند. سرانجام، در پایین­ترین سطح یعنی ذخیره­سازی/ پایگاه داده، حجم ذخیره­سازی قطعه­ای EBS، که به طور پویا به صورت یک سیستم­فایل شبکه و توسط ماشین­های مجازی EC2 نصب شده­اند، کد کاربرد را برای تمامی نمونه­های سرور وب قابل دسترس می­سازد، در حالی که پایگاه داده (خدمت RDS اجرا شده بر روی یک نمونه­ی بزرگ EC2) اجازه­ی خواندن/ نوشتن/ ذخیره­سازی داده­ی کاربرد را به صورت دائمی می­دهد.

شکل ۱ نمونه­های Vitaever

در شرح جزئیات فراهم­آوری منعطف منابع، می­توان گفت نرم­افزار به عنوان خدمت Vitaever شامل تعداد ثابتی از نمونه­های دائمی است، یعنی، دو نمونه­ی EC2 که یک سرور وب را به همراه خدمت نرم­افزار به عنوان خدمت Vitaever برای بهبود تحمل خطای نرم­افزار به عنوان خدمت اجرا می­کنند، یک نمونه­­ی اجراکننده­ی EBS، و یک نمونه­ی انجام­دهنده­ی RDS. در زمان اجرا، تابع مقیاس­پذیری خودکار به طور پیوسته اجرای خدمت را نظارت می­­کند و به طور پویا سرورهای وب اضافی را وابسته به نیازهای درخواست­ها/ منابع جاری فعال/ حذف می­کند. به محض این­که یک نمونه­ی جدید فعال/ حذف شد، ELB به طور خودکار ترافیک ورودی HTTPS را بر روی تمامی سرورهای وب فعال گسترش می­دهد.

Vitaever نیازمند حفاظت از داده­ی خدمت بیش­تری نسبت به آن­چه AWS آمازون ارائه می­دهد و مخصوصاً برای آن­چه مربوط به رمزنگاری داده و مدیریت کلید رمزنگاری می­شود است. در ادامه، معماری امن پیشنهادشده شرح داده می­شود که اگرچه به طور خاص برای موردپژوهی Vitaever طراحی شده است، برای استفاده در دیگر خدمات نرم­افزار به عنوان خدمت بهداشت و درمان با نیازمندی­های امنیتی مشابه نیز به اندازه­ی کافی تعمیم­پذیر است.

معماری امنیتی جدید شامل دو زیرسیستم اصلیِ نشان داده شده در شکل ۲ است: نرم­افزار به عنوان خدمت Vitaever و مدیر کلید. زیرسیستم نرم­افزار به عنوان خدمت Vitaever شامل مؤلفه­های عمده­ای است که برای فراهم­آوری نرم­افزار به عنوان خدمت Vitaever همانند آن­چه در بالا شرح داده شد و تحقق بخشیدن به رمزنگاری داده­ی ثابت با یکدیگر همکاری می­کنند. زیرسیستم مدیر کلید نیز تابع مدیریت کلید رمزنگاری که برای ایجاد امنیت داده در بازیابی و ذخیره­سازی تمامی کلیدهای رمزنگاری استفاده­شده در سیستم اساسی است را تحقق می­بخشد.

شکل ۲ معماری AWS برای Vitaever جدید

اولین قدم برای معرفی امنیت داده­ی ثابت در Vitaever استفاده از رمزنگاری برای تمامی داده­های حساس ذخیره­شده در پایگاه­داده­ی زیرسیستم نرم­افزار به عنوان خدمت Vitaever است. برای دستیابی به این هدف، استفاده از توابع رمزنگاری MySQL که ممکن است است به عنوان دستورالعمل­های خاص SQL، مستقیماً درون پرس­وجوهای SQL فراخوانی شوند امکان­پذیر است. با استفاده از این توابع، رمزنگاری قطعاتی از پایگاه داده با هر دانه­بندی­ای، از یک فیلد تنها گرفته تا کل ستون­ها و جداول، ممکن است. ما تصمیم گرفته­ایم از دانه­ی ستون­های جدول استفاده کنیم و داده­های حساس با کلیدهای مختلف که وابسته به نقش­ها و قواعد لیست­های کنترل دسترسی[۱] هستند را برای استفاده­ی کاربران مختلفی که به Vitaever دسترسی دارند مانند مدیران سیستم، پزشکان، همیاران خانگی، بیماران تحت درمان همیاری خانگی و غیره، ذخیره کنیم. بنابراین، تحلیل پایگاه داده و تعیین آن­که هر نقش به دسترسی به کدام ستون­های جدول نیاز دارد ضروری است. رابطه­ی کلید به نقش یک رابطه­ی چند به چند است زیرا نقش­های مختلف ممکن است به یک ستون یکسان دسترسی داشته باشند: زیرسیستم مدیریت کلید، این همکاری­ها و کلیدهای رمزنگاری را نگه­داری می­کند.

در ادامه، مثالی برای درک رمزنگاری مبتنی بر ستون ارائه می­دهیم. همان­طور که شکل ۳ نشان می­دهد، جدول ۱ دارای ۴ ستون است: ستون A، ستون B، ستون C، ستون D. داده­ی موجود در ستون­های A و B با کلید رمزنگاری ۱ و داده­های موجود در ستون­های C و D به ترتیب با کلیدهای ۲ و ۳ رمزنگاری شده­اند. کاربر A بخشی از کارکنان پزشکی است، در حالی که کاربر B در گروه نقشی مدیر حسابداری قرار دارد. بنا بر این نقش­ها، سیستم ما به کاربر A و کاربر B کلیدهای مختلفی اعطا می­کند: کاربر A ستون­های A، B و C که شامل داده­های پزشکی کاربر هستند را رمزگشایی می­کند، در حالی که کاربر B برای کمیت بخشیدن به هزینه­های پزشکی­ای که بیمار باید بپردازد، می­تواند داده­های ستون­های C و D را رمزگشایی کند.

شکل ۳ رمزنگاری کلیدها

تغییرات برای رمزنگاری داده­های ثابت در AWS بسیار محدود هستند و ساختار ابتدایی معماری نرم­افزار به عنوان خدمت مبتنی بر AWS در Vitaever را تغییر نمی­دهند و تنها نیازمند دو تغییر عمده هستند: الف) رمزنگاری داده­های حساس ذخیره­شده درون پایگاه­داده همان­طور که پیش از این شرح داده شد، ب)تغییر بخش­های کوچکی از کد Vitaever که توابع دسترسی به پایگاه داده را پیاده­سازی می­کنند، به طوری که رمزنگاری/ رمزگشایی و خواندن از/ نوشتن بر روی پایگاه داده با به دست آوردن اولین کلیدهای مورد نیاز و سپس تغییر پرس­و­جوهای استفاده شده­ی SQL انجام شود. در این زمان، این تغییرات کوچک باعث می­شوند تا تمامی داده­های ثابت پیش از ذخیره­سازی در پایگاه داده رمزنگاری شوند و در نتیجه چالش­های زیادی در استفاده از آن­ها بدون داشتن کلیدهای رمزنگاری مرتبط به وجود آید.

با تمرکز بر زیرسیستم مدیری کلید، مؤلفه­ی هسته و اصلی آن مدیر امنیت است که مسئول مدیریت تمامی درخواست­ها برای ذخیره­سازی و بازیابی کلیدهای رمزنگاری استفاده شده توسط زیرسیستم نرم­افزار به عنوان خدمت Vitaever می­باشد. در این­جا بر روی اهمیت جدایی فیزیکی موجودیتی که داده­ی ثابت رمزنگاری­شده را از موجودیت حاوی کلیدهای امنیتی تأکید می­شود.  دو جایگزین برای گسترش ممکن هستند: اولی اجرای زیرسیستم­های نرم­افزار به عنوان خدمت Vitaever و مدیر کلید در فراهم­آورندگان متفاوت ابر است، دیگری نیز گسترش زیرسیستم نرم­افزار به عنوان خدمت بر روی یک فراهم­آورنده­ی ابر عمومی، و مدیر کلید فرضاً بر روی زیرساخت فناوری اطلاعات شرکت نرم­افزار به عنوان خدمت محلی است.

هر کاربر که بخواهد از نرم­افزار Vitaever استفاده کند باید تصدیق هویت شود و برای دریافت کلیدهای رمزنگاری و در توافق با عضویت نقشش، اجازه بگیرد. Vitaever این کلید رمزنگاری را از مدیر کلید در زمان ورود و با استفاده از داده­ی کاربر شامل گذرواژه­اش بازیابی می­کند. برای مسائل امنیتی، کلیدهای رمزنگاری به مشتری داده نمی­شوند اما در نشست مشتری در طرف سرور نرم­افزار به عنوان خدمت Vitaever ذخیره می­شود. به علاوه، برای جلوگیری از ورود گذرواژه توسط کاربران در هر بار تعامل آن­ها با نرم­افزار به عنوان خدمت، از روشی مبتنی بر توکن استفاده شده است. در زمان اولین تصدیق هویت، مدیر کلید نه تنها کلید رمزنگاری کاربر را بازیابی می­کند، بلکه یک توکن نیز تولید می­کند که در یک کوکی و توسط نرم­افزار به عنوان خدمت به مشتری بازگردانده می­شود. به طور خاص، این توکن به عنوان یک گذرواژه­ی یک­بار مصرف[۲] که برای بازه­ی زمانی محدودی معتبر است استفاده می­شود. پس از انقضای این زمان، نرم­افزار به عنوان خدمت به منظور به دست آوردن یک توکن جدید برای استفاده در تصدیق هویت کاربر با مدیر کلید تعامل می­کند که برای کاربر نهایی و در تمام مدت فعالیت آن نشست، شفاف است. البته پس از انقضای نشست، کاربر باید داده­های ورود را دوباره وارد کند. استفاده از روش مبتنی بر توکن باعث سادگی بیش­تر استفاده از این نرم­افزار بدون منع حفاظت از کلیدهای رمزنگاری می­شود.

برای پیاده­سازی امنیت ذخیره­سازی کلید، تصمیم به استفاده از پروتکل استاندارد و سبُک راهنمای دسترسی[۳] گرفتیم. به طور خاص، ما یک درخت اطلاعات راهنمای[۴] LDAP تعریف کردیم که نشان­دهنده و ذخیره­کننده­ی تمامی کلیدهای امنیتی، شناسه­های کاربران و نقش­ها است. علاوه بر این، پیوندهای DIT از یک طرف کلیدهایی به نقش­ها و از طرف دیگر کاربرانی به نقش­ها هستند. کاربران با چندین نقش در هنگام ورود باید نقش مورد استفاده­ی خود در طی کل آن نشست را مشخص کنند.

برای درک بهتر معماری پیشنهادشده، شکل ۴ تمامی تعاملات اصلی میان مؤلفه­های معماری توزیع‌شده­ی Vitaever را نشان می­دهد. تأکید می­شود تمامی تبادل­های داده­های در حال انتقال میان مشتری و نرم­افزار به عنوان خدمت، و هم­چنین داده­های میان نرم­افزار به عنوان خدمت و سرور امنیتی، به صورت تعاملات امن HTTPS حفاظت شده­اند.

شکل ۴ تعامل میان مؤلفه­های ابر

در زمان دسترسی اولیه به سیستم، کاربر اطلاعات ورودی خود شامل نام کاربری، گذرواژه، نقش کاربر و شماره­ی شناسایی مجوز Vitaever را وارد می­کند، و Vitaever این داده­های ورود را به مدیر کلید می­فرستد (“داده”، مراحل ۱ و ۲ در شکل ۴). سپس، سرور امنیتی درخت LDAP را تحلیل می­کند تا کاربر را به وسیله­ی بازگشت کلید رمزنگاری متناظر به نقش کاربر شناسایی کند و برای او اجازه صادر کند (“کلید” مراحل ۳ و ۴). علاوه بر این، سرور امنیتی یک توکن تولید می­کند و آن را به همراه کلید برای تصدیق هویت کاربر بعدی می­فرستد. آن­گاه، Vitaever توکن را به کاربر باز می­گرداند (مراحل ۴ و ۵). برای هر عمل بعدی، کاربر به منظور کسب اجازه از Vitaever برای انجام عملیات، توکن خود را ارائه می­دهد و اگر بررسی آن قابل قبول بود، Vitaever برای رمزگشایی داده­های حساس مورد نیاز ذخیره­شده در پایگاه داده و بازگرداندن نتایج پرس‌وجوهای متناظر به آن کاربر، از کلیدهای رمزنگاری به دست آمده استفاده می­کند (مراحل ۶ تا ۸). زمانی که توکن منقضی شود، Vitaever دوباره به توکن برای سرور امنیتی نیاز دارد تا این سرور، توکن جدید را به کاربر و سپس Vitaever این توکن جدید را به کاربر بفرستد (مراحل ۹ تا ۱۱). این عملیات از دید کاربر نهایی شفاف هستند.

این بخش را با توجه به این نکته نتیجه­گیری می­کنیم که کلیدهای رمزنگاری (کلید شکل ۴) تنها در حافظه­ی  ناپایدار ذخیره می­شوند و کاربران متهاجم تنها از طریق بررسی ماشین مجازی می­توانند به آن­ها دست یابند. به علاوه، کلیدهای به سرقت رفته تنها اجازه­ی دسترسی به بخشی از کل پایگاه داده را می­دهند. در آخر، برای افزایش بیش­تر امنیت Vitaever، به طور دوره­ای یک عملیات batch انجام می­شود که تمامی کلیدهای امنیتی را تجدید و اطلاعات حساس را رمزنگاری و رمزگشایی می­کند.

منبع

Bracci, Fabio, Antonio Corradi, and Luca Foschini. “Database security management for healthcare SaaS in the Amazon AWS Cloud.” Computers and Communications (ISCC), 2012 IEEE Symposium on. IEEE, 2012.

[۱] Access Control List (ACL)

[۲] One-Time Password (OTP)

[۳] standard Lightweight Directory Access Protocol (LDAP)

[۴] Directory Information Tree (DIT)

دریافت مقاله

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