استقرار هوش مصنوعی در محیطی واجد شرایط HIPAA با Amazon Quick

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

اطلاعات سلامت حفاظت‌شده (Protected Health Information یا PHI) به هرگونه اطلاعاتی گفته می‌شود که هویت یک فرد را مشخص می‌کند و به سلامت او، دریافت خدمات درمانی یا پرداخت هزینه این خدمات مربوط است؛ از جمله یادداشت پزشکی، پرونده مطالبه هزینه درمان یا شناسه عضو. هر نرم‌افزاری که با PHI سروکار داشته باشد، مشمول قانون فدرال قابلیت انتقال و پاسخ‌گویی بیمه سلامت (HIPAA) می‌شود؛ قانونی که نحوه دسترسی به این اطلاعات، حفاظت از آن‌ها و ثبت و ممیزی فعالیت‌های مرتبط را تعیین می‌کند.

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

اتصال‌دهنده‌ها یکپارچه‌سازی‌های ازپیش‌ساخته‌ای هستند که به Amazon Quick امکان می‌دهند اطلاعات را از سامانه‌های خارجی مانند Slack، Microsoft Outlook، Salesforce، Atlassian Jira وMicrosoft SharePoint به‌صورت امن بخواند و در آن‌ها اقداماتی انجام دهد. همچنین می‌توان ابزارهای سفارشی خود را از طریق پروتکل زمینه مدل (Model Context Protocol یا MCP) اضافه کرد. فقط اتصال‌دهنده‌هایی نمایش داده می‌شوند که سازمان استفاده از آن‌ها را مجاز کرده باشد. هنگامی که یک عامل گفت‌وگویی هم می‌تواند PHI را بخواند و هم بر اساس آن اقدام کند، به سازوکارهای حاکمیتی کافی نیاز دارید: محدودیت‌های کنترلی قطعی، سابقه ممیزی رفتار عامل و مسئولیت‌پذیری روشن درباره اقداماتی که بدون دخالت مستقیم انسان انجام می‌شوند. Amazon Quick برای پشتیبانی از این الزامات، بازیابی مبتنی بر فهرست‌های کنترل دسترسی (ACL)، ثبت گزارش گفت‌وگوها و بازخوردها و کنترل‌هایی برای تعیین مجوزهای هر عامل گفت‌وگویی ارائه می‌کند.

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

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

HIPAA شامل چه سازمان‌هایی می‌شود؟

دامنه HIPAA فراتر از بیمارستان‌ها و درمانگاه‌هاست. بر اساس این قانون، دو گروه از سازمان‌ها موظف به رعایت الزامات آن هستند و بیشتر پروژه‌های هوش مصنوعی با هر دو گروه ارتباط پیدا می‌کنند.

نهادهای مشمول قانون (Covered Entities یا CEs)

• طرح‌های بیمه سلامت: شرکت‌های بیمه درمانی، سازمان‌های نگهداری سلامت (HMO)، طرح‌های بیمه مورد حمایت کارفرمایان و برنامه‌های Medicare و Medicaid.
• مراکز پردازش و تسویه اطلاعات سلامت: سازمان‌هایی که اطلاعات سلامت را از قالب‌های غیراستاندارد به قالب‌های الکترونیکی استاندارد تبدیل می‌کنند.
• ارائه‌دهندگان خدمات سلامت: پزشکان، درمانگاه‌ها، بیمارستان‌ها، داروخانه‌ها، خانه‌های سالمندان و هر ارائه‌دهنده‌ای که اطلاعات سلامت را به‌صورت الکترونیکی منتقل می‌کند.

شرکای تجاری (Business Associates یا BAs)

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

نهادهای مشمول قانون و شرکای تجاری باید پیش از انتقال PHI، الحاقیه قرارداد شریک تجاری (Business Associate Agreement یا BAA) را امضا کنند. پس از پذیرش BAA آمازون وب سرویس (AWS) از طریق AWS Artifact، AWS برای همان حساب مشخص AWS نقش شریک تجاری شما را بر عهده می‌گیرد؛ آن هم فقط زمانی که از خدمات واجد شرایط HIPAA، مانند Amazon Quick، برای پردازش PHI در آن حساب استفاده کنید. این قرارداد به حساب‌های دیگر شما، اطلاعات PHI قرارگرفته در خدمات فاقد شرایط HIPAA یا نحوه پیکربندی سرویس تسری پیدا نمی‌کند. مسئولیت این موارد همچنان بر عهده شماست. همواره شرایط جاری BAA شرکت AWS و تعهدات خود را با تیم‌های حقوقی و انطباق سازمان بررسی و تأیید کنید.

واجد شرایط HIPAA بودن با انطباق با HIPAA یکسان نیست

«واجد شرایط HIPAA» بودن عنوانی است که AWS برای برخی خدمات خود به کار می‌برد، اما «منطبق با HIPAA» بودن ویژگی کل محیط عملیاتی شماست. واجد شرایط بودن به این معناست که AWS سرویس را ارزیابی کرده و اجازه می‌دهد با امضای BAA مربوط به AWS از آن برای پردازش، ذخیره‌سازی و انتقال PHI استفاده کنید. Amazon Quick واجد شرایط HIPAA است و ممیزان مستقل آن را در چارچوب برنامه‌های انطباق AWS، از جمله HIPAA، FedRAMP، PCI DSS، SOC و ISO، ارزیابی می‌کنند. برای AWS به‌عنوان یک سرویس ابری، گواهی رسمی مستقلی با عنوان گواهی HIPAA وجود ندارد و خود AWS نیز به‌عنوان یک شرکت «واجد شرایط HIPAA» طبقه‌بندی نمی‌شود.

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

Amazon Quick چیست؟

Amazon Quick اغلب از طریق عامل‌های گفت‌وگویی آن معرفی می‌شود، اما واجد شرایط بودن تحت HIPAA به کل محیط کاری مربوط است، نه فقط یک قابلیت؛ بنابراین برای بررسی انطباق باید پلتفرم را به‌صورت یکپارچه در نظر گرفت. قابلیت‌های Amazon Quick از اجزای اصلی زیر تشکیل شده‌اند:

• گفت‌وگو (Chat): رابط اصلی کاربر است. کاربر می‌تواند پرسشی مطرح کند یا دستوری را به زبان طبیعی ارائه دهد و Amazon Quick نحوه پاسخ‌گویی را تعیین می‌کند.
• عامل‌های گفت‌وگویی (Chat agents): همه درخواست‌ها را پردازش می‌کنند. این بخش در کنسول و زیر منوی Chat agents در دسترس است. می‌توان برای هر عامل دستورالعمل تعیین کرد، آن را به منابع دانشی متصل کرد و ابزارهایی برای انجام اقدام در اختیارش گذاشت. Amazon Quick به‌طور پیش‌فرض عاملی به نام My Assistant دارد و امکان ساخت عامل‌های سفارشی برای حوزه‌های مشخص نیز فراهم است.
• فضاها (Spaces): منابع موردنیاز عامل گفت‌وگویی، مانند اسناد، داشبوردها، مجموعه‌داده‌ها، پایگاه‌های دانش و اتصال‌دهنده‌های عملیاتی را سازمان‌دهی می‌کنند. هر فضا را می‌توان با یک تیم به اشتراک گذاشت.
• یکپارچه‌سازی‌ها (Integrations): Amazon Quick را به محیط سازمان متصل می‌کنند. این قابلیت‌ها شامل پایگاه‌های دانش برای محتوای بدون ساختار، مانند داده‌های ذخیره‌شده در Amazon Simple Storage Service (Amazon S3)، Microsoft SharePoint وAtlassian Confluence؛ اتصال‌های داده ساخت‌یافته که Amazon Quick Sight را به پایگاه‌های داده ساخت‌یافته، انبارهای داده و دریاچه‌های داده متصل می‌کنند؛ اتصال‌دهنده‌های عملیاتی مبتنی بر مشخصات OpenAPI یا سرورهای MCP؛ و افزونه‌های Chrome، Slack، Microsoft Teams و Microsoft 365.

قابلیت‌های مختلف روی این اجزای پایه ساخته می‌شوند. ستون «منابع مورد استفاده» در جدول زیر برای بررسی انطباق اهمیت دارد، زیرا نشان می‌دهد هر قابلیت از کدام اجزای پایه و در نتیجه از کدام مسیرهای داده استفاده می‌کند.

نکته: SPICE موتور پرس‌وجوی درون‌حافظه‌ای Amazon Quick Sight است. مجموعه‌داده SPICE هنگام ایجاد از کلید پیش‌فرض مدیریت‌شده توسط مشتری در حساب استفاده می‌کند. برای انتقال یک مجموعه‌داده موجود به کلید پیش‌فرض جدید، باید یک به‌روزرسانی کامل انجام دهید. اگر داده‌های شما شامل PHI هستند، SPICE را در راهبرد رمزنگاری خود لحاظ کنید؛ در صورت استفاده از کلید اختصاصی، از کلید AWS Key Management Service (KMS) مدیریت‌شده توسط مشتری برای حفاظت از آن استفاده کنید. همچنین هنگام تصمیم‌گیری درباره حداقل‌سازی داده‌ها، مشخص کنید چه اطلاعاتی باید وارد شود؛ برای مثال، آیا می‌توان داده‌ها را به‌صورت زنده پرس‌وجو کرد یا به‌جای آن، نسخه‌ای بدون شناسه‌های هویتی بارگذاری کرد.

وضعیت واجد شرایط بودن، BAA، رمزنگاری، کنترل دسترسی و الزامات ممیزی در همه قابلیت‌ها برقرار است. بااین‌حال، همان‌طور که در ابتدا اشاره شد، PHI از دو مسیر وارد Amazon Quick می‌شود و هر مسیر به شیوه متفاوتی ایمن‌سازی می‌شود. مسیر داده‌های بدون ساختار از پایگاه‌های دانش می‌گذرد؛ در این مسیر، دسترسی در سطح سند با فهرست‌های کنترل دسترسی (ACL) مدیریت و هنگام اجرای پرس‌وجو بررسی می‌شود. مسیر داده‌های ساخت‌یافته از طریق Amazon Quick Sight به پایگاه‌های داده و دریاچه‌های داده شما متصل می‌شود و دسترسی به ردیف‌ها و ستون‌ها با سازوکارهای امنیتی مربوط به همان سطوح کنترل می‌شود. این دو مسیر PHI را به شیوه‌های متفاوت منتقل می‌کنند و، همان‌طور که در بخش بعد توضیح داده می‌شود، کنترل‌ها نیز در هر مسیر به‌صورت متفاوت اعمال می‌شوند.

امکانات Amazon Quick برای محیط‌های تحت نظارت

Amazon Quick واجد شرایط HIPAA است. در ادامه بررسی می‌کنیم این وضعیت در عمل چه امکاناتی فراهم می‌کند.

زیرساخت مدیریت‌شده

Amazon Quick سرویسی کاملاً مدیریت‌شده است. AWS زیرساخت زیربنایی را اداره می‌کند و مسئول امنیت فضای ابری است. ممیزان مستقل این مسئولیت‌ها را مطابق مدل مسئولیت مشترک AWS بررسی می‌کنند.

رمزنگاری

Amazon Quick داده‌های ذخیره‌شده را به‌طور پیش‌فرض رمزنگاری می‌کند و از رمزنگاری داده‌ها هنگام انتقال نیز پشتیبانی می‌کند.

• رمزنگاری داده‌های ذخیره‌شده به‌طور پیش‌فرض با استفاده از کلیدهای متعلق به AWS یا مدیریت‌شده توسط AWS فعال است. ثبت کلید مدیریت‌شده توسط مشتری اختیاری است و HIPAA آن را الزامی نمی‌داند. اگر به کنترل مستقیم کلیدهای رمزنگاری نیاز دارید، می‌توانید برای انواع منابع پشتیبانی‌شده، از جمله مجموعه‌داده‌های SPICE، اعتبارنامه‌های منابع داده، توکن‌های OAuth و فایل‌های گزارش، یک کلید AWS KMS مدیریت‌شده توسط مشتری ثبت کنید. این قابلیت به اشتراک Enterprise نیاز دارد. در مواردی که کلید مدیریت‌شده توسط مشتری اعمال نمی‌شود، AWS از کلید متعلق به خود یا کلید مدیریت‌شده توسط AWS برای رمزنگاری داده‌ها استفاده می‌کند.
• نکته مهم این است که بازخورد کاربران درباره پاسخ‌های گفت‌وگو، از جمله دیدگاه‌های متنی اختیاری، با کلید مدیریت‌شده توسط مشتری یا کلیدی که از داده‌های نمایه‌سازی‌شده هوش مصنوعی Amazon Quick حفاظت می‌کند، رمزنگاری نمی‌شود. بنابراین، بازخورد کاربران باید سطحی بالقوه حاوی PHI در نظر گرفته شود و مطابق آن تحت نظارت قرار گیرد.
• برای داده‌های در حال انتقال، Amazon Quick از پروتکل امنیت لایه انتقال (TLS) استفاده می‌کند. در برخی اتصال‌های پایگاه داده، انتخاب رمزنگاری انتقال بر عهده شماست؛ بنابراین TLS/SSL را صراحتاً برای این اتصال‌ها فعال کنید و فرض نکنید که این قابلیت همیشه روشن است.

داده‌های شما برای آموزش مدل‌ها استفاده نمی‌شوند

Amazon Quick از داده‌های مشتریان برای آموزش یا بهبود مدل‌های زبانی بزرگ (LLM) زیربنایی استفاده نمی‌کند.

کنترل دسترسی و فدراسیون هویت

Amazon Quick از کنترل دسترسی مبتنی بر نقش (RBAC) و ورود یکپارچه (SSO) از طریق AWS IAM Identity Center، Microsoft Active Directory و ارائه‌دهندگان هویت مبتنی بر SAML 2.0 پشتیبانی می‌کند. در بارهای کاری هوش تجاری (BI)، می‌توانید این قابلیت‌ها را با امنیت در سطح ردیف و ستون و نقش‌های اجرایی تکمیل کنید تا دسترسی به داده‌ها هنگام اجرای پرس‌وجو محدود شود. این امکانات به شما کمک می‌کنند هویت یکتای هر کاربر و اصل حداقل سطح دسترسی لازم را اعمال کنید.

سیگنال‌های ممیزی و پایش

Amazon Quick چند نوع سیگنال متمایز تولید می‌کند. این سیگنال‌ها جایگزین یکدیگر نیستند و اشتباه گرفتن آن‌ها یکی از علت‌های رایج ایجاد خلأ در ممیزی است.

• AWS CloudTrail عملیات پشتیبانی‌شده API و مجموعه مشخصی از رویدادهای غیرمرتبط با API، مانند مشاهده داشبوردها و اقدامات مدیریت کاربران، را ثبت می‌کند. این سرویس مشخص می‌کند چه کسی، چه کاری و در چه زمانی انجام داده است، اما متن پیام‌های گفت‌وگو یا محتوای پاسخ‌ها را ثبت نمی‌کند.
• گزارش‌های ارائه‌شده از طریق Amazon CloudWatch، رکوردهای اختصاصی هوش مصنوعی را به مقصدی تحت کنترل شما، مانند CloudWatch Logs، Amazon S3 یا Firehose، منتقل می‌کنند. پنج نوع گزارش وجود دارد: گفت‌وگوها (CHAT_LOGS)، بازخورد کاربران (FEEDBACK_LOGS)، ساعات فعالیت عامل‌ها و پژوهش (AGENT_HOURS_LOGS)، میزان استفاده از فضای ذخیره‌سازی نمایه‌ها (INDEX_USAGE_LOGS) و همگام‌سازی فایل‌های پایگاه دانش (KB_FILE_SYNC_LOGS). اطلاعات مربوط به اینکه «کاربر چه پرسیده و Amazon Quick چه پاسخی داده است» در این گزارش‌ها ثبت می‌شود، نه در CloudTrail.
• معیارها و هشدارهای CloudWatch نیز امکان پایش عملیاتی تقریباً بلادرنگ را فراهم می‌کنند.
• داشبورد تحلیل، اطلاعات مربوط به میزان استفاده و پذیرش سرویس را در اختیار مدیران قرار می‌دهد. توجه داشته باشید که در جریان بررسی بازخوردهای منفی، این داشبورد ممکن است متن دقیق پرس‌وجوها و کل زمینه گفت‌وگو را نمایش دهد؛ بنابراین دسترسی به آن باید فقط به مدیران مجاز داده شود.

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

تبدیل قابلیت‌ها به کنترل‌های HIPAA

مزیت استفاده از Amazon Quick به‌عنوان سرویسی واجد شرایط این است که می‌توان قابلیت‌های آن را به تدابیر حفاظتی مشخص HIPAA مرتبط کرد؛ همان‌طور که در جدول زیر آمده است.

کارهایی که Amazon Quick انجام نمی‌دهد

Amazon Quick کنترل‌های یادشده را ارائه می‌کند، اما برای جبران محدودیت‌های آن باید بدانید چه قابلیت‌هایی در این سرویس وجود ندارند. Amazon Quick دسترسی، بازیابی اطلاعات و تعامل با داده‌ها را مدیریت می‌کند، اما پلتفرمی برای مهندسی داده یا حاکمیت دریاچه داده نیست. در محیط‌های مشمول HIPAA، برخی نیازها خارج از محدوده Amazon Quick قرار دارند و باید با استفاده از سایر خدمات AWS در مراحل پیش از ورود داده‌ها به آن برآورده شوند.

• حذف شناسه‌های هویتی و تبدیل داده‌ها: Amazon Quick اطلاعات PHI را بدون شناسه هویتی نمی‌کند و ساختار داده‌های منبع را تغییر نمی‌دهد. اگر کاربرد شما به مجموعه داده‌ای محدود یا نسخه‌ای بدون شناسه‌های هویتی نیاز دارد، پیش از ورود اطلاعات به Amazon Quick آن را با خدمات مناسب AWS آماده کنید. برای نمونه، می‌توانید از AWS Glue DataBrew، یکی از قابلیت‌های AWS Glue، برای آماده‌سازی بصری داده‌ها و حذف اطلاعات حساس، یا از AWS Glue برای اجرای خطوط لوله استخراج، تبدیل و بارگذاری داده‌ها (ETL) استفاده کنید.
• حاکمیت دریاچه داده و مجوزهای دقیق در سطح جدول: برای داده‌های ساخت‌یافته‌ای که Amazon Quick Sight از طریق دریاچه داده پرس‌وجو می‌کند، مدیریت مجوزها در سطح ردیف و ستون خود دریاچه بر عهده AWS Lake Formation است، نه Amazon Quick. Amazon Quick Sight امنیت ردیف و ستون را در لایه تحلیل اعمال می‌کند، اما مجوزهای مرجع در سطح دریاچه در Lake Formation و AWS Glue Data Catalog نگهداری می‌شوند.
• اقدامات حفاظتی اداری و فیزیکی: آموزش کارکنان، تحلیل ریسک و رویه‌های رسیدگی به نقض امنیت، صرف‌نظر از ابزارهای مورد استفاده، همچنان بر عهده سازمان شماست.

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

طرح بیمه سلامت AnyCompany: نمونه‌ای از کاربرد

طرح بیمه سلامت AnyCompany، سازمانی فرضی، نمونه‌ای از یک کاربرد و الگوی استقرار را نشان می‌دهد. این طرح به‌عنوان یک نهاد مشمول HIPAA می‌خواهد دو هدف را محقق کند: نخست، به تیم مدیریت مراقبت اجازه دهد درباره اسناد سیاست‌های بیمه‌ای و اعتراض‌های اعضا با زبان طبیعی پرسش مطرح کند؛ دوم، به مدیران عملیات امکان دهد بدون وابستگی به تیم تحلیل، از داشبوردهای داده‌های مطالبات بیمه‌ای استفاده کنند. هر دو کاربرد با PHI سروکار دارند؛ بنابراین AnyCompany باید از انطباق راهکار با HIPAA اطمینان حاصل کند. محیط این سازمان دو مسیر داده دارد که پیش از دسترسی Amazon Quick، هرکدام با راهکارهای مجزا طراحی و مدیریت می‌شوند.

مسیر داده‌های بدون ساختار: اسناد سیاست‌ها و سوابق پزشکی

→ مخزن Amazon S3 به‌عنوان منبع پایگاه دانش آگاه از ACL

→ پایگاه دانش Amazon Quick با ACL در سطح سند و رد دسترسی در صورت نامشخص بودن مجوز هنگام اجرای پرس‌وجو

مسیر داده‌های ساخت‌یافته: مطالبات بیمه‌ای

تمام داده‌های مطالبات در حال حاضر در یک دریاچه داده مبتنی بر Amazon S3 قرار دارند.

→ فرایند ETL در Glue برای پالایش داده‌ها → ابزار Glue DataBrew برای حذف شناسه‌های هویتی

→ Lake Formation برای اعطای مجوز در سطح ردیف و ستون و استفاده از AWS Glue Data Catalog

→ مجموعه‌داده Amazon Quick Sight متصل به Amazon Athena، همراه با امنیت در سطح ردیف و ستون و نقش اجرایی

هر دو جریان داده، یعنی مسیر ساخت‌یافته و مسیر بدون ساختار، در نهایت به یک عامل گفت‌وگویی Amazon Quick می‌رسند که از SSO فدرال، فضای دارای حداقل سطح دسترسی، محدودیت‌های کنترلی و گزارش‌های ارائه‌شده از طریق CloudWatch استفاده می‌کند.

مدیر AnyCompany راهکار را به ترتیب زیر پیاده‌سازی می‌کند:

1. امضای BAA و راه‌اندازی سرویس از طریق کنسول مدیریت AWS. مدیر، BAA را در AWS Artifact برای حساب AWS موردنظر می‌پذیرد و سپس Amazon Quick را از طریق کنسول مدیریت AWS همراه با IAM Identity Center راه‌اندازی می‌کند. AnyCompany شناسه قرارداد، زمان پذیرش و مشخصات حساب را در دفتر ثبت انطباق خود نگهداری می‌کند. تنها نسخه وب Amazon Quick که از طریق کنسول مدیریت AWS راه‌اندازی شده است، می‌تواند تحت پوشش BAA امضاشده از طریق AWS Artifact قرار گیرد. این قرارداد برای مشتریانی که قصد ساخت جریان‌های کاری منطبق با HIPAA و مرتبط با PHI را دارند، یکی از الزامات ضروری است؛ البته پیکربندی صحیح و مسئولیت‌های انطباقی خود مشتری نیز باید رعایت شوند.
2. تنظیم کنترل‌های برگشت‌ناپذیر از روز نخست. ازآنجاکه سیاست امنیتی AnyCompany مستلزم کنترل کلیدهای رمزنگاری توسط خود سازمان است، مدیر پیش از ایجاد هرگونه داده هوش مصنوعی در Amazon Quick، یک کلید مدیریت‌شده توسط مشتری را به‌عنوان کلید پیش‌فرض حساب ثبت می‌کند. کلید داده فقط یک بار تعیین می‌شود و بعداً قابل تغییر نیست. رمزنگاری پیش‌فرض مدیریت‌شده توسط AWS نیز واجد شرایط HIPAA است و استفاده از کلید مدیریت‌شده توسط مشتری پیش‌شرط واجد شرایط بودن سرویس نیست. مدیر همچنین مدل هویت را بر پایه IAM Identity Center تعیین می‌کند تا قابلیت شناسایی کاربران غیرفعال قابل استفاده باشد. کلید داده Amazon Quick هنگام نخستین ایجاد داده یک بار تعیین می‌شود و پس از آن هرگز قابل تغییر نیست. اگر کلید حذف شود، تنها راه بازیابی، لغو اشتراک و اشتراک مجدد است که تمام داده‌های Amazon Quick را به‌طور دائمی حذف می‌کند.
3. آماده‌سازی مسیر داده‌های ساخت‌یافته خارج از Amazon Quick. پیش از آنکه Amazon Quick Sight به داده‌های مطالبات دسترسی پیدا کند، تیم داده AnyCompany با AWS Glue جداول پالایش‌شده مطالبات را می‌سازد و با Glue DataBrew نسخه‌ای بدون شناسه‌های هویتی برای داشبوردهای عملیاتی تهیه می‌کند. AWS Lake Formation از طریق AWS Glue Data Catalog دسترسی به این جداول را در سطح ردیف و ستون مدیریت می‌کند. در نتیجه، Amazon Quick هرگز به اطلاعات خام PHI که به آن نیاز ندارد دسترسی پیدا نمی‌کند.
4. ایجاد پایگاه دانش آگاه از ACL برای اسناد. مدیر، مخزن S3 حاوی اسناد سیاست‌ها و اعتراض‌ها را به‌عنوان پایگاه دانش متصل می‌کند و ACL در سطح سند را از همان ابتدا فعال می‌سازد. ازآنجاکه فعال کردن ACL پس از ایجاد پایگاه دانش امکان‌پذیر نیست، این قابلیت باید هنگام ایجاد آن تنظیم شود. Amazon Quick هویت هر کاربر را هنگام اجرای پرس‌وجو بررسی می‌کند و اگر نتواند مجوز دسترسی را تأیید کند، هیچ سندی بازنمی‌گرداند.
5. ایجاد فضای اختصاصی و عامل گفت‌وگویی سفارشی. AnyCompany یک فضای حاوی PHI با عضویت محدود ایجاد می‌کند که از فضاهای بهره‌وری عمومی جداست. عامل گفت‌وگویی تیم مدیریت مراقبت فقط به پایگاه دانش آگاه از ACL دسترسی دارد؛ جست‌وجوی آزاد وب برای آن غیرفعال شده و محدودیت‌های کنترلی نیز تنظیم شده‌اند. برای هر سامانه مرتبط با PHI، اتصال‌دهنده‌های فقط‌خواندنی در نظر گرفته می‌شوند.
6. اتصال داشبوردها با امنیت هنگام اجرای پرس‌وجو. داشبوردهای عملیاتی از مجموعه‌داده بدون شناسه‌های هویتی Amazon Quick Sight که از طریق Athena در دسترس است، استفاده می‌کنند. امنیت ردیف و ستون در Amazon Quick Sight و یک نقش اجرایی نیز در کنار مجوزهای Lake Formation اعمال می‌شود.
7. فعال‌سازی سیگنال‌های ممیزی پیش از افزودن کاربران. مدیر یک مسیر ثبت رویداد در CloudTrail ایجاد می‌کند و انتقال گزارش‌های CloudWatch، از جمله CHAT_LOGS، FEEDBACK_LOGS، KB_FILE_SYNC_LOGS و سایر گزارش‌ها، را به مقصدی با نگهداری و پوشاندن داده‌های حساس پیکربندی می‌کند. بازخورد کاربران نیز به‌عنوان محلی بالقوه حاوی PHI در نظر گرفته می‌شود.
8. اعتبارسنجی و سپس گسترش از داده‌های فاقد PHI به داده‌های مرتبط با PHI. AnyCompany کار را با جریان‌های کاری فاقد PHI، مانند پرسش‌وپاسخ درباره سیاست‌ها و جست‌وجوی اسناد، آغاز می‌کند تا از درستی حاکمیت داده اطمینان حاصل کند. سپس با ورودی‌های خصمانه آزمایش می‌کند تا رفتار رد دسترسی در صورت نامشخص بودن مجوز را بررسی کند و گزارش‌ها را برای تأیید ثبت رویدادها بازبینی می‌کند. تنها پس از این مراحل، فعالیت تیم مدیریت مراقبت را به فرایندهای مرتبط با PHI گسترش می‌دهد.

   Amazon Quick هویت، بازیابی اطلاعات، محدودیت‌های کنترلی و سابقه ممیزی را مدیریت می‌کند؛ اما حذف شناسه‌های هویتی، اجرای ETL و اعطای مجوز در سطح دریاچه داده در خدمات بالادستی Glue، Glue DataBrew و Lake Formation انجام می‌شوند. این تفکیک مسئولیت‌ها الگوی پیشنهادی و راهکار عملی برای توسعه قابلیت‌های Amazon Quick در یک محیط فدرال است.

چگونه انطباق را برقرار کنیم: بهترین رویه‌ها

واجد شرایط بودن به این معناست که پلتفرم از نظر فنی می‌تواند با PHI کار کند؛ اما شما باید آن را به‌گونه‌ای پیکربندی کنید که این کار را به‌درستی انجام دهد.

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

با مدل امنیتی هوش مصنوعی عامل‌محور شروع کنید

عامل‌های Amazon Quick در هر مرحله منتظر دریافت دستور تازه نمی‌مانند. آن‌ها می‌توانند ابزارها را فراخوانی کنند، داده‌ها را تغییر دهند و به‌طور مستقل با سامانه‌های خارجی تعامل داشته باشند. این قابلیت، شیوه ایمن‌سازی محیط را تغییر می‌دهد. AWS در آوریل ۲۰۲۶ چهار اصل امنیتی برای سامانه‌های هوش مصنوعی عامل‌محور منتشر کرد که مستقیماً در این زمینه کاربرد دارند.

اصل اول — تدابیر حفاظتی عامل‌ها را به چارچوب امنیتی موجود اضافه کنید. برای Amazon Quick یک ساختار امنیتی موازی و جداگانه ایجاد نکنید. تدابیر ویژه عامل‌ها، مانند محدودیت‌های کنترلی، مسدود کردن موضوعات و حذف اطلاعات شناسایی شخصی، باید در کنار سیاست‌های موجود IAM، شبکه و رمزنگاری اعمال شوند.

اصل دوم — به کنترل‌های قطعی بیشتر از کنترل‌های مبتنی بر دستور متنی اعتماد کنید. یک ورودی خصمانه که به‌خوبی طراحی شده باشد، ممکن است دستورالعمل متنی عامل را دور بزند. اما نمی‌توان با دستور متنی از سیاست‌های AWS Identity and Access Management (IAM)، فهرست‌های کنترل دسترسی در سطح سند، مرزهای شبکه یا محدودیت‌های کنترلی تنظیم‌شده توسط مدیر عبور کرد. این سازوکارها باید ابزارهای اصلی اعمال سیاست امنیتی باشند. دستورالعمل‌های عامل لایه دوم دفاع هستند، نه تنها لایه دفاعی.

اصل سوم — دفاع چندلایه را در مراحل دریافت اطلاعات، استدلال و اقدام اعمال کنید. هر قابلیت عامل را در یکی از سه لایه زیر قرار دهید:

• دریافت اطلاعات (Perceive): پایگاه‌های دانش، فایل‌های بارگذاری‌شده، جست‌وجوی وب، ورودی‌های اتصال‌دهنده‌ها و خروجی ابزارهای MCP.
• استدلال (Reason): زمینه‌ای که مدل زبانی بزرگ پردازش می‌کند و محدودیت‌های کنترلی و تنظیمات موضوعی بر آن اعمال می‌شوند.
• اقدام (Act): اتصال‌دهنده‌ها، Quick Flows، Quick Automate، وظایف زمان‌بندی‌شده و فراخوانی ابزارهای MCP.

کنترل‌ها را در هر لایه به‌طور مستقل اعمال کنید تا ضعف یک لایه به سایر لایه‌ها سرایت نکند.

توجه داشته باشید که تعهدات BAA تحت HIPAA خدمات و راهکارهای پشتیبان، مانند ابزارهای MCP، را نیز دربرمی‌گیرد.

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

پیش از استقرار تصمیم بگیرید

سه انتخاب زیر دائمی هستند؛ بنابراین پیش از شروع پیاده‌سازی درباره آن‌ها تصمیم بگیرید.

ابتدا کلید KMS را ثبت کنید. اگر سازمان شما باید کنترل کلیدهای رمزنگاری را در اختیار داشته باشد، پیش از ایجاد هرگونه منبع هوش مصنوعی در Amazon Quick، یک کلید مدیریت‌شده توسط مشتری را به‌عنوان کلید پیش‌فرض حساب ثبت کنید. کلید داده در نخستین باری که داده هوش مصنوعی Quick در حساب ایجاد می‌شود تعیین خواهد شد و پس از آن قابل تغییر نیست. پشتیبانی از کلیدهای مدیریت‌شده توسط مشتری به اشتراک Enterprise نیاز دارد. همچنین توجه کنید که استفاده از این کلیدها قابلیت حافظه گفت‌وگو را غیرفعال می‌کند. حساب‌هایی که با کلید مدیریت‌شده توسط مشتری پیکربندی شده‌اند، از این قابلیت پشتیبانی نمی‌کنند.

مدل هویت را آگاهانه انتخاب کنید. چهار گزینه دارید: IAM Identity Center، Active Directory، فدراسیون IAM و کاربران محلی Quick. این گزینه‌ها از نظر تأمین دسترسی، لغو دسترسی کاربران هنگام خروج و رفتار حاکمیتی تفاوت دارند. برای مثال، شناسایی کاربران غیرفعال فقط با IAM Identity Center یا Active Directory کار می‌کند. تغییر ارائه‌دهنده هویت پس از استقرار مستلزم پیکربندی مجدد مجوزها و عضویت همه کاربران در فضاهاست. بنابراین، انتخاب خود را از ابتدا نهایی کنید.

هنگام ایجاد پایگاه‌های دانش حاوی PHI، قابلیت ACL را فعال کنید. در منابع پشتیبانی‌شده، از جمله Amazon S3، Google Drive، SharePoint، Confluence Cloud و OneDrive، باید هنگام ایجاد پایگاه دانش تعیین کنید که آیا دسترسی در سطح سند بر اساس ACL اعمال شود یا خیر. این تنظیم دائمی است و نمی‌توان آن را برای پایگاه دانشی که بدون ACL ساخته شده است، بعداً فعال کرد. بنابراین، هر پایگاه دانش مرتبط با PHI را از ابتدا با قابلیت ACL ایجاد کنید.

هشدار: نگاشت نادرست مخزن هویت کاربران به مجوزهای دسترسی ممکن است باعث شود اسناد محدودشده بدون هیچ خطا یا هشداری در اختیار کاربران اشتباه قرار گیرند. پیش از ورود محتوای PHI، نگاشت هویت کاربران به ACLها را به‌دقت اعتبارسنجی کنید.

منطقه AWS، شبکه و مرزهای حساب

منطقه استقرار خود را بر اساس عوامل زیر انتخاب کنید:

• محل نگهداری داده‌ها: Amazon Quick داده‌ها را در همان منطقه‌ای پردازش و ذخیره می‌کند که سرویس در آن راه‌اندازی شده است. باید اطمینان حاصل کنید که آن منطقه با الزامات سازمان درباره محل نگهداری داده‌ها سازگار است. Amazon Quick سرویسی تک‌منطقه‌ای است؛ از تاب‌آوری چند ناحیه دسترس‌پذیری در داخل یک منطقه بهره می‌برد، اما امکان انتقال خودکار فعالیت به منطقه‌ای دیگر را ندارد. اگر جریان‌های کاری حیاتی شما به تاب‌آوری بین‌منطقه‌ای نیاز دارند، یک استقرار جداگانه Amazon Quick را در منطقه دوم، همراه با داده‌های پشتیبان آن، راه‌اندازی کنید؛ برای مثال، منابع پایگاه دانش مبتنی بر S3 را بین مناطق تکثیر کنید.
• دسترس‌پذیری سرویس: قابلیت‌ها ممکن است در زمان‌های متفاوتی به مناطق مختلف عرضه شوند. پیش از استقرار، بررسی کنید تمام امکانات موردنیاز عامل‌ها، مانند پایگاه‌های دانش، اتصال‌دهنده‌ها و قابلیت‌های Amazon Quick Sight، در منطقه انتخابی شما در دسترس باشند.
• راهبرد چندحسابی: Amazon Quick را در یک حساب اختصاصی برای بار کاری در ساختار AWS Organizations قرار دهید. از سیاست‌های کنترلی سرویس (SCP) برای اعمال محدودیت منطقه‌ای و جلوگیری از راه‌اندازی تصادفی سرویس در مناطق خارج از محدوده مجاز استفاده کنید.

از نظر مرزهای شبکه، Amazon Quick یک سرویس مدیریت‌شده است که از طریق HTTPS در دسترس قرار می‌گیرد و درون یک شبکه خصوصی مجازی (VPC) مستقر نمی‌شود. بااین‌حال، منابع داده شما، از جمله مخازن S3، پایگاه‌های داده و سامانه‌های مستقر در محل سازمان، ممکن است پشت مرزهای VPC قرار داشته باشند. در صورت امکان از نقاط پایانی VPC و AWS PrivateLink استفاده کنید. همچنین مطمئن شوید تنظیمات DNS و قوانین دیواره آتش به اتصال‌دهنده‌های Amazon Quick اجازه می‌دهند به منابع داده مجاز دسترسی داشته باشند، بدون آنکه محدوده دسترسی شبکه بیش از حد لازم گسترش یابد.

سطح حمله عامل را کاهش دهید

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

آنچه عامل می‌تواند بخواند محدود کنید (لایه دریافت اطلاعات). تمام منابعی را که وارد زمینه پردازش عامل می‌شوند، شناسایی کنید: پایگاه‌های دانش، فایل‌های بارگذاری‌شده، جست‌وجوی وب، ارائه‌دهندگان پژوهش شخص ثالث، پاسخ‌های اتصال‌دهنده‌ها، خروجی ابزارهای MCP و حافظه نگهداری‌شده گفت‌وگوها. برای جریان‌های کاری مرتبط با PHI:

• عامل‌ها را به پایگاه‌های دانش مورد اعتماد و آگاه از ACL محدود کنید.
• هرجا جست‌وجوی آزاد وب لازم نیست، آن را غیرفعال کنید.
• اگر عامل به بارگذاری فایل نیاز ندارد، این قابلیت را غیرفعال کنید.
• مدت نگهداری تاریخچه گفت‌وگو را به کوتاه‌ترین بازه مفید محدود کنید.

اقداماتی را که عامل می‌تواند انجام دهد محدود کنید (لایه اقدام). تمام مسیرهای خروجی، از جمله اتصال‌دهنده‌ها، ابزارهای MCP، جست‌وجوهای وب، جریان‌های Quick Flows، گردش‌کارهای Quick Automate و اجرای زمان‌بندی‌شده عامل‌ها را شناسایی کنید. برای عامل‌های مرتبط با PHI:

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

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

حداقل سطح دسترسی و تفکیک داده‌ها را اعمال کنید

• پایگاه‌های دانش و فضاهای حاوی PHI را از پایگاه‌ها و فضاهای بهره‌وری عمومی جدا کنید و عضویت را محدود سازید.
• دسترسی به فضاها و عامل‌ها را بر اساس نیاز واقعی اعطا کنید. هم مجوزهای اشتراک‌گذاری، یعنی اینکه چه کسی می‌تواند از پایگاه دانش استفاده کند، و هم ACL اسناد منبع، یعنی اینکه کدام اسناد نمایه‌سازی‌شده برای کاربر مجاز قابل بازیابی‌اند، بررسی کنید.
• چرخه پیش‌فرض به‌روزرسانی پایگاه دانش ۲۴ ساعت است. اگر الزامات تغییر دسترسی مستلزم اعمال سریع‌تر تغییرات هستند، این بازه را کوتاه کنید. پیش از واگذاری مجدد یا استفاده دوباره از نشانی‌های ایمیل، ACLها را به‌روزرسانی کنید.
• عامل‌های مرتبط با PHI نباید در یک فضا با ابزارهای عمومی بهره‌وری قرار گیرند. در نتیجه، کاربردهای مختلف باید در سطح فضا از یکدیگر جدا شوند.
• مجوزهای اتصال‌دهنده‌ها را به‌طور منظم بازبینی کنید و اعتبارنامه‌های ذخیره‌شده در AWS Secrets Manager را مطابق سیاست مدیریت اعتبارنامه سازمان به‌صورت دوره‌ای تغییر دهید.

حداقل‌سازی داده‌ها

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

• هرجا کاربرد موردنظر اجازه می‌دهد، از داده‌های بدون شناسه‌های هویتی استفاده کنید.
• هنگام دریافت داده‌های ساخت‌یافته از پایگاه‌های داده یا APIها، ستون‌ها و ردیف‌ها را پیش از نمایه‌سازی در همان منبع فیلتر کنید.
• محدودیت‌های کنترلی عامل را برای حذف اطلاعات شناسایی شخصی از پاسخ‌ها تنظیم کنید. با استفاده از فیلترهای داخلی تشخیص اطلاعات شناسایی شخصی، شماره‌های تأمین اجتماعی (SSN)، شماره پرونده‌های پزشکی (MRN) و تاریخ تولد را از پاسخ‌ها پنهان کنید.

پیکربندی ثبت ممیزی و نگهداری گزارش‌ها

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

برای راه‌اندازی این قابلیت‌ها مراحل زیر را انجام دهید:

1. برای حساب‌ها و مناطق موردنظر، یک مسیر ثبت رویداد در CloudTrail ایجاد کنید.
2. کمی پس از فعال‌سازی قابلیت‌های هوش مصنوعی Amazon Quick، انتقال گزارش‌های CloudWatch، از جمله CHAT_LOGS، FEEDBACK_LOGS و KB_FILE_SYNC_LOGS، را پیکربندی کنید.
3. قابلیت پوشاندن داده‌های حساس در CloudWatch Logs را برای گزارش‌های گفت‌وگو اعمال کنید تا PHI به‌صورت متن آشکار ذخیره نشود.
4. دوره نگهداری گزارش‌ها را حداقل شش سال تعیین کنید و استفاده از S3 Object Lock برای بایگانی گزارش‌ها را در نظر بگیرید.
5. برای شناسایی فعالیت‌های غیرعادی، هشدارهای CloudWatch ایجاد کنید.
6. AWS Security Hub را برای بررسی مستمر انطباق فعال کنید.
7. هشدارهای مهم را به سامانه مدیریت اطلاعات و رویدادهای امنیتی (SIEM) یا پلتفرم پاسخ‌گویی به رخدادها ارسال کنید.

پیش از گسترش، اعتبارسنجی کنید

پیش از گسترش دامنه استفاده، موارد زیر را بررسی کنید:

• پذیرش BAA در دفتر ثبت انطباق سازمان ثبت شده باشد.
• طبقه‌بندی داده‌ها مستند شده باشد؛ از جمله اینکه کدام پایگاه‌های دانش و فضاها حاوی PHI هستند و هر عامل به کدام‌یک دسترسی دارد.
• پرس‌وجوهای خصمانه و سناریوهای تزریق دستور آزمایش شده باشند.
• گزارش‌ها به‌درستی ثبت شوند و سازوکار پوشاندن اطلاعات حساس عملکرد صحیحی داشته باشد.
• تمرین شبیه‌سازی‌شده رسیدگی به نقض امنیت داده‌ها انجام شده باشد.
• تیم امنیت اطلاعات (InfoSec) استقرار را تأیید کرده باشد.

محدودیت‌های شناخته‌شده

محدودیت‌های شناخته‌شده Amazon Quick عبارت‌اند از:

• نبود پوشش BAA در مسیرهای Free و Plus: برای برخورداری از پوشش BAA باید از مسیری استفاده کنید که از طریق کنسول مدیریت AWS راه‌اندازی شده است.
• نبود تکثیر بین‌منطقه‌ای: بازیابی پس از بحران (DR) به یک منطقه محدود است.
• ماهیت احتمالاتی محدودیت‌های کنترلی: این سازوکارها خطر را کاهش می‌دهند، اما آن را از بین نمی‌برند. باید آن‌ها را با کنترل‌های سطح زیرساخت که پیش‌تر توضیح داده شد، تکمیل کنید.
• گسترش تعهدات BAA از طریق اتصال‌دهنده‌های شخص ثالث: هنگامی که اتصال‌دهنده‌ای داده‌ها را به سامانه‌ای خارجی می‌فرستد، مسئولیت انطباق شما نیز مسیر انتقال داده را دنبال می‌کند.
• احتمال وجود PHI در حافظه گفت‌وگو: سیاست‌های نگهداری را تعیین کنید و پوشاندن داده‌های حساس را اعمال کنید.

راهنمای پیاده‌سازی

نمونه طرح بیمه سلامت AnyCompany نشان داد که چگونه می‌توان Amazon Quick را مستقر کرد. این بخش همان الگو را به برنامه‌ای مرحله‌به‌مرحله تبدیل می‌کند که می‌توانید در اختیار تیم پلتفرم سازمان قرار دهید.

مرحله اول: اجرای قرارداد BAA ـ روز اول

• با حسابی که مجوزهای لازم برای AWS Artifact را دارد وارد شوید و BAA را بپذیرید.
• شناسه قرارداد، زمان پذیرش، شناسه اصلی امنیتی (Principal ARN) و شناسه حساب را ثبت کنید.
• تیم حقوقی و انطباق سازمان را مطلع کنید.

مرحله دوم: تنظیم کنترل‌های پایه و برگشت‌ناپذیر ـ روزهای اول و دوم

• یک کلید مدیریت‌شده توسط مشتری را به‌عنوان کلید پیش‌فرض حساب ثبت کنید.
• بررسی کنید سیاست کلید مجوزهای لازم را اعطا می‌کند: Encrypt، Decrypt، GenerateDataKey و DescribeKey.
• مدل هویت خود را پیکربندی کنید؛ استفاده از IAM Identity Center توصیه می‌شود.
• تأیید کنید حساب در واحد سازمانی اختصاصی بار کاری (OU) قرار دارد و SCPهای محدودکننده منطقه برای آن اعمال شده‌اند.

مرحله سوم: ایجاد پایگاه‌های دانش آگاه از ACL ـ روزهای سوم تا هفتم

• منابع داده را به سه گروه PHI، داده‌های مرتبط با PHI و داده‌های فاقد PHI طبقه‌بندی کنید.
• برای منابع حاوی PHI و مرتبط با آن، پایگاه‌های دانش را با قابلیت ACL فعال ایجاد کنید.
• مخزن هویت را با مجوزهای منابع نگاشت کنید و تنظیمات را با چند کاربر آزمایشی اعتبارسنجی کنید.
• بررسی کنید گزارش‌های همگام‌سازی، ورود موفق داده‌ها را تأیید می‌کنند. پایگاه‌های دانش حاوی PHI را از محتوای عمومی جدا نگه دارید.

مرحله چهارم: ایجاد فضاها ـ روزهای پنجم تا هشتم

• فضاهای مرتبط با PHI را از فضاهای بهره‌وری عمومی جدا کنید.
• پایگاه‌های دانش، داشبوردها و اتصال‌دهنده‌های عملیاتی را به فضاها اضافه و عضویت را محدود کنید.
• تأیید کنید کاربران غیرمجاز مسدود می‌شوند.

مرحله پنجم: ایجاد عامل‌های سفارشی با محدودیت‌های کنترلی ـ روزهای هفتم تا دوازدهم

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

مرحله ششم: پیکربندی اتصال‌دهنده‌های عملیاتی ـ روزهای دهم تا چهاردهم

• برای داده‌های مرتبط با PHI، کار را با حالت فقط‌خواندنی آغاز کنید و هر اتصال‌دهنده را به منابع مشخص محدود سازید.
• اعتبارنامه‌ها را در AWS Secrets Manager ذخیره کنید و چرخش دوره‌ای آن‌ها را فعال کنید.
• ضرورت هرگونه دسترسی نوشتنی را مستند کنید و پیش از فعال‌سازی آن، تأیید تیم امنیت را بگیرید.
• محدودیت‌های دسترسی را آزمایش کنید تا اتصال‌دهنده‌ها نتوانند به منابع خارج از محدوده تعیین‌شده دسترسی پیدا کنند.

مرحله هفتم: پیکربندی ممیزی، نگهداری و پایش ـ روزهای دوازدهم تا شانزدهم

• CloudTrail و گزارش‌های ارائه‌شده از طریق CloudWatch را فعال کنید.
• قابلیت پوشاندن داده‌های حساس را اعمال کنید، دوره نگهداری را حداقل شش سال تعیین کنید و S3 Object Lock را فعال سازید.
• هشدارها را پیکربندی کنید، Security Hub را فعال کنید و آن را با SIEM سازمان یکپارچه سازید.

مرحله هشتم: اعتبارسنجی با تیم امنیت اطلاعات ـ روزهای چهاردهم تا بیست‌ویکم

• بسته مستندات و شواهد را گردآوری کنید؛ شامل تأیید BAA، پیکربندی KMS، تنظیمات هویت، طبقه‌بندی داده‌ها، نتایج آزمایش‌ها و نمونه گزارش‌ها.
• تمرین شبیه‌سازی‌شده رسیدگی به نقض امنیت را اجرا کنید.
• نتایج را به تیم امنیت اطلاعات ارائه دهید، یافته‌ها را برطرف کنید و تأیید نهایی را دریافت کنید.

مرحله گسترش ـ هفته‌های چهارم تا هشتم

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

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

در این مرحله نظارت را با دقت ادامه دهید: گزارش‌های گفت‌وگو را هر هفته بررسی کنید، نرخ فعال شدن محدودیت‌های کنترلی را بسنجید و الگوهای دسترسی را در ۳۰ روز پس از راه‌اندازی هر گردش‌کار جدید زیر نظر بگیرید.

جمع‌بندی

Amazon Quick محیط کاری هوش مصنوعی مدیریت‌شده‌ای در اختیار سازمان‌های تحت نظارت حوزه سلامت و شرکای تجاری آن‌ها قرار می‌دهد که در تمام طیف قابلیت‌های خود، از هوش مصنوعی عامل‌محور و بازیابی دانش گرفته تا هوش تجاری، خودکارسازی و پژوهش، واجد شرایط استفاده تحت HIPAA است.

برای استقرار منطبق با الزامات، باید مراحل زیر را به‌ترتیب طی کنید:

1. تفاوت میان واجد شرایط بودن و انطباق کامل را درک کنید و مسئولیت‌های سازمان خود را در چارچوب مدل مسئولیت مشترک بپذیرید.
2. قرارداد BAA را برای حسابی که از طریق کنسول مدیریت AWS راه‌اندازی شده است، منعقد کنید.
3. ابتدا کنترل‌های برگشت‌ناپذیر را تعیین کنید: کلیدهای KMS، مدل هویت و پایگاه‌های دانش آگاه از ACL.
4. دسترسی عامل‌ها به داده‌ها و اقدامات را محدود کنید، اصل حداقل سطح دسترسی را اعمال کنید و اطلاعات PHI را در گزارش‌ها بپوشانید.
5. راهکار را با تیم امنیت اطلاعات اعتبارسنجی کنید و سپس استفاده از آن را از گردش‌کارهای فاقد PHI به گردش‌کارهای مرتبط با PHI گسترش دهید.

الزامات انطباق با سرعت پیشرفت فناوری تغییر می‌کنند. AWS چهار اصل امنیتی خود برای هوش مصنوعی عامل‌محور را در آوریل ۲۰۲۶ و چارچوب Well-Architected برای هوش مصنوعی عامل‌محور را در ژوئن ۲۰۲۶ منتشر کرد. سازمان‌هایی که از همین امروز کنترل‌های قطعی در سطح زیرساخت را مبنای کار قرار می‌دهند، احتمالاً در موقعیت مناسبی خواهند بود تا با همگام شدن انتظارات قانونی و نظارتی با قابلیت‌های هوش مصنوعی عامل‌محور، خود را با الزامات جدید تطبیق دهند.

گام بعدی چیست؟

اگر در حال ارزیابی Amazon Quick هستید: از تیم حساب AWS خود درخواست جلسه‌ای با تمرکز بر انطباق کنید. درباره دامنه BAA، مسئولیت مشترک در زمینه هوش مصنوعی عامل‌محور و آخرین خدمات واجد شرایط HIPAA سؤال کنید.

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

اگر هم‌اکنون از Amazon Quick استفاده می‌کنید: استقرار خود را با بهترین رویه‌های این مقاله، به‌ویژه اصول امنیتی هوش مصنوعی عامل‌محور و فهرست محدودیت‌های شناخته‌شده، تطبیق دهید.

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