המונחים: Serverless Compliance

מחשוב ללא שרת שינה את האופן שבו ארגונים בונים ופרוסים יישומים, המציעים יכולת דרוג, מופחתים תפעולית מעל פני השטח, וזמן מהיר יותר לשוק.עם זאת, כאשר מטפלים בנתונים אישיים או בריאות רגישים, ארכיטקטורות ללא שרת מציגות אתגרים ייחודיים לציות.שני מארגוני התקנות התובעניים ביותר הם חוק ביטוח הבריאות וחשבונאות (HIP) בארצות הברית ותקנות הגנת הנתונים הכלליים (GDPR) באיחוד האירופי.

מאמר זה מספק מדריך סמכותי לבניית יישומים חסרי שרת HIPAA ו-GDPR.We Covers רגולטוריים, אסטרטגיות אדריכליות, תקני הצפנה, מנגנוני בקרה גישה, בקרת ביקורת, דרישות תושבות נתונים ותגובה אירוע - הכל במסגרת שירותים ללא שרת כמו AWS Lambda, Azure Functions ו-Google Cloud Functions. By the End, יהיה לך תוכנית ייצור עבור מערכת כחולה עבור שרת ללא תואמים.

הבנה של הנוף הפורמלי

HIPAA Review

HIPAA שולטת בהגנה על מידע בריאות מוגן (PHI) בארצות הברית.זה חל על ישויות מכוסה (ספקי בריאות, תוכניות בריאות, מערכות בריאות, שירותי ניקוי) ושותפים העסקיים שלהם.כלל הפרטיות HIPAA מגדיר שימושים וגילויים אפשריים של PHI, בעוד חוק האבטחה מחייב אמצעי הגנה מנהליים, פיזיים וטכניים.

GDPR סקירה

GDPR הוא חוק הגנת נתונים מקיף החל על כל ארגון עיבוד נתונים אישיים של יחידים באזור הכלכלי האירופי (EEA) הוא מדגיש עקרונות כגון חוקיות, הוגנות, שקיפות, צמצום נתונים, דיוק, הגבלה אחסון, יושרה וסודיות. זכויות מפתח כוללות את הזכות לגישה, תיקון, קביעת (זכות להישכח), והגבלות נתונים גם מטילות דרישות מחמירות על נתונים חוצה נתונים, העברות (עם אישור החל מ-72 שעות הפעלה) ואימות (במסגרת) להגשת אישורים של זכויות יוצרים לתקנות (הגנה על פני נתונים).

אחריות משותפת בסביבה ללא Server

ספקי ענן פועלים תחת מודל אחריות משותף.הספק מבטיח את התשתית של תשתיות (מתקנים פיזיים, רשת, היפרביטור, לוח זמנים ייעודי) הלקוח אחראי לתצורה, סיווג נתונים, זהות וניהול גישה (IAM), הצפנה, קוד יישומים וציות. in Serverless, הספק מנהל את מערכת ההפעלה והפעלה, אך הלקוח חייב עדיין להבטיח קוד, סביבת משתנה, וטעויות נפוצות הוא לא מתאים באופן אוטומטי.

עקרונות חובה עבור Serverless

עקרונות מרובים חלים על HIPAA ו-GDPR:

  • (FLT:0Data MinimizationFLT:1) - איסוף ומעבד רק את הנתונים המינימליים הדרושים.הימנע אחסון PHI או נתונים אישיים ביו יומני פונקציה, הודעות שגיאה, או אחסון זמני אלא אם נדרש רק.
  • (FLT:0) קביעת הגבלת הגבלת מידע 1 - עיבוד נתונים רק למטרה ספציפית, מפורשת ולגיטימיות הנחשפה לנושא הנתונים. מקורות אירועים ללא מרשם (למשל, אירועים S3, סטרימינגי דינמוDB) חייבים להיות מוגדרים כדי למנוע חשיפה בלתי מכוונת של נתונים.
  • (FLT:0) הגבלת הגבלת הגבלת גבולות 1:1 - הגדר באופן אוטומטי מצופה על יומני, קבצים זמניים ב- /tmp Directories, והנתונים הקלידים.
  • (FLT:0) אינטגריטיות וקונדומים (ConidentialityFLT:1) - נתוני הצפנה במנוחה ובמעבר, לאכוף גישה לפחות פריצה, וליישם אימות חזק.
  • (ב) ,0) ,AccountabilityFLT:1 - לשמור על עקבות ביקורת של גישה לנתונים ושינויים במערכת, ולחתום על החלטות תאימות.

אסטרטגיות אדריכליות ליישום ללא תשלום

הצפנה של נתונים במנוחה ובמעבר

HIPAA דורש הצפנה של ePHI במנוחה ובמעבר, אלא אם כן הישות המכוסה קובעת אמצעים חלופיים מקבילים.GDPR סעיף 32 מחייב אמצעים טכניים מתאימים, כולל הצפנה.

  • (FLT:0) במנוחה:03FLT:1 השתמש במפתחות הצפנה מנוהלת (AWS KMS, Azure Key Vault, GCP Cloud KMS) הצפנה של שרת על כל שירותי האחסון (S3, RDS, DynamoDB, Cloud Storage) for Lambda/tmp Directories, לשקול צפינו קבצים לפני כתיבתם - שימו לב כי / אמפ הוא אמפירי ולא על ידי ברירת מחדל בספקים מוצפנים.
  • (FLT:0) במעבר:ראהFLT:1 ; Enforce TLS 1.2 ומעלה עבור כל שיחות API, חיבורי מסד נתונים ותקשורת בין-שירות. השתמש ב נקודות קצה VPC עם IP פרטיים כדי להימנע מטראנס מעל האינטרנט הציבורי.עבור אינטגרציה מונחת אירועים (למשל, S3 > Lambda), קביעת מקורות התראה לאירוע לשימוש ב- HTTPS ותעודות.

זהות וניהול גישה

פונקציות ללא שרת חייבות לפעול עם הרשאות המינימליות הדרושות.ליישם בקרת גישה מבוססת תפקיד (RBAC) עם מדיניות גרפית.לדוגמה, הפונקציה AWS Lambda עיבוד PHI צריכה להיות תפקיד ייעודי IAM המאפשר רק לקרוא / לכתוב לטבלאות דינמיות ספציפיות ופענוח באמצעות מפתח KMS ספציפי.לעולם לא להשתמש הרשאות כרטיסיות בר.

  • נדרשת אימות רב-ספק (MFA) לכל גישה מינהלית לסביבה ללא שרת.
  • השתמש באישורים קצרים (למשל, AWS STS, Azure Managed Identity) ולא במפתחי API ארוכים.
  • הגבלת תפקוד וביצוע של רשתות VPC ספציפיות עם קבוצות רשת ACLs ואבטחתיות השולטות בתנועה ריבונית/לא-ממוקדת.

אחסון נתונים מאובטח ועיבוד

בחר שירותי מסד נתונים המציעים הצפנה והסמכת תאימות. עבור HIPAA, להשתמש בשירותים כי הם BAA-eligible (למשל, AWS DynamoDB עם הצפנה, אמזון RDS עם הצפנה, Azure SQL Database עם הצפנה של נתונים Transud) עבור GDPR, להבטיח את חנויות השירות באזור כי תואם דרישות תושבות נתונים.

  • להימנע מאחסן PHI או נתונים אישיים במשתנה הסביבה של פונקציות. השתמש בחנויות פרמטר או למנהלי סודות עם הצפנה (AWS Parameter Store, Azure Appiguration, GCP Secret Manager).
  • השתמש בפונקציות חסרות מדינה במידת האפשר; אם המדינה חייבת להיות נמשכת, חיצוני אותה לחנות נתונים מקבילה עם בקרת גישה.
  • יישום נתונים המסתתרים או אסימוניזציה עבור שדות שאינם בעלי חשיבות.לדוגמה, עדכן רק את ארבעת הספרות האחרונות של מספר אבטחה חברתי או פשטוני מידע אישי.

שבילי ביקורת ו Logging

HIPAA (חוק אבטחה) ו-GDPR (סעיף 30 - רשומות של פעילויות עיבוד) דורשות כניסה מפורטת של גישה לנתונים. יישומים ללא שרת חייבים ליצור יומני ביקורת לכידת:

  • מי ניגש למידע
  • מתי (Timestamp)
  • מאיפה (מקור IP, שירות)
  • איזו פעולה (קריאה, כתיבה, למחוק)
  • הצלחה או כישלון

השתמש בשירותי אחסון מנוהלים (AWS CloudTrail, Azure Monitor, GCP Cloud Audit Logs) כדי להקליט אירועים ניהוליים (למשל, יצירת פונקציה, שינויים הרשאות) ואירועי נתונים (למשל, דינמויי מקבל את זהם) בנוסף, להגדיר את רמת היישום בתוך פונקציות, אך לעולם לא להזין PHI או נתונים אישיים. השתמש ב- מובנים כדי לציית למדיניות שימור - להגדיר 1-ACT לפי תקן עבור פחות מ-ACT.

תושבות נתונים וריבונות

GDPR מגביל העברות נתונים חוצה גבולות למדינות עם הגנה נאותה.HIPAA אינה אוסרת במפורש על אחסון PHI מחוץ לארה"ב, אך ישות מכוסה חייבת להבטיח את הסכם השותפים העסקיים (BAA) והגנה על אבטחה להרחיב את העולם.

  • פונקציות עומק וחנויות נתונים באזורים ספציפיים (למשל, "eu-west-1" עבור נתונים אישיים של האיחוד האירופי, "או-מזרח-1" עבור PHI).
  • השתמש בתכונות תושבות נתונים של ספק (למשל, מדיניות Azure להגביל את האזור, מדיניות בקרת שירות AWS).
  • אם יש לעבד נתונים באזורים (למשל, שחזור אסון), ליישם אמצעי הגנה חוזיים, הסכמי עיבוד נתונים וסעיפים חוזיים סטנדרטיים (SCC) תחת GDPR.
  • להימנע משימוש בנקודות קצה גלובליות עבור שירותים כגון דינמוק טבלאות גלובליות, אלא אם יש לך בסיס משפטי מפורש לעיבוד חוצה גבולות.

הסכמי שיתוף עסקים (BAA) והסכמי עיבוד נתונים (DPA)

כדי לציית ל- HIPAA, עליך להיות בעל BAA חתום עם ספק הענן שלך עבור כל שירותים אשר מטפל ספקיות הראשי PHI (AWS, Azure, GCP) להציע BAA עבור רבים משירותי השרתים שלהם.בדוק את השירותים הספציפיים מכוסה על ידי כל BAA - לדוגמה, AWS Lambda מכוסה, אבל כמה אינטגרציה של צד שלישי אינם. עבור GDPR, לחתום על הסכם עיבוד נתונים (D) עם כל ספק ענן והסכמים חלק זה.

המונחים:

שלב 1: סיווג נתונים וזרימה

לפני כתיבת קוד, סיווג כל הנתונים מעובדים על ידי יישום ללא שרת.זהה שדות המהווים PHI (תחת HIPAA) או נתונים אישיים (תחת GDPR) ממפה את זרימת הנתונים מ ingestion (API Gateway, S3 Event, Queues) באמצעות עיבוד (תפקודי Lambda, פונקציות שלב) לאחסון (DynDB, RDS, S3) לכל שלב, בין אם הצפנה, גישה, בקרה מספקת, ובקרות.

שלב 2: ניהול אבטחה

שירותי אבטחה ספק-native:

  • (FLT:0)AWS:IRFLT:1) השתמש ב-AWS Config כדי לאכוף את כללי ההצפנה, AWS GuardDuty לאיתור איומים, ו-AWS Security Hub לציות.Enable VPC Flow Logs והגבלת פונקציות Lambda ל-VPCnets עם תוקפנות מבוקרת באמצעות שער NAT.
  • (FLT:0Zonee:BuildFLT:1) השתמש במדיניות Azure כדי לאכוף את גרסת TLS, לאפשר ל- Azure Security Center, ולהשתמש ב- Azure Sentinel for SIEM. Deploy פונקציות ב-VNet (אזור רשת וירטואלית) עם נקודות קצה שירות.
  • (FLT:0GCP:igFLT:1) השתמש ב-VPC Service Controls כדי למנוע חדירה של נתונים, לאפשר ל-Cloud Armor להגנה על API, ולהשתמש ב-Cloud Audit Logs עם שמירה.

שלב 3: קוד-רמה הטוב ביותר תרגולים

לכתוב פונקציות שאינן חסרות מצב ולא נתונים רגישים מעבר למעגל החיים של הפונקציה. השתמש בהצפנה המשתנה של הסביבה עבור מיתרי חיבור ומפתחות. להימנע מסודות קודרים קשים - השתמש במנהלי סודות.

const { SecretsManager } = require('@aws-sdk/client-secrets-manager');
const secretsClient = new SecretsManager();
const secret = await secretsClient.getSecretValue({ SecretId: process.env.SECRET_ARN });

ודא שטיפול בשגיאה אינו מדליף נתונים רגישים בלוגים או הודעות תגובה. השתמש בקוביות מובנה המאפשרות סינון.

שלב 4: מעקב מתמשך ותגובה לתקריות

הגדר התראות אוטומטיות להתנהגות בלתי-מועילה, כגון תבניות ביטול בלתי צפויות, גישה לשגיאות שנכחו או לתנודות נפח נתונים. עבור HIPAA, לשמור על תוכנית תגובה המתועדת הכוללת נהלי התראה פורצים.עבור GDPR, להבטיח יכולת להודיע לסמכות פיקוח בתוך 72 שעות. פונקציות Serverless יכולות להשתלב עם זרימות עבודה של אירועים כגון פונקציות של AWS, לוגיקה, או GCP כדי לכלול חקירה.

מלכודות נפוצות וכיצד להימנע מהם

  • (FLT:0) תפקידים IAM ⁇ : ⁇ 1) הצעת חוק סטטית של הרשאות פונקציה מובילה לחשיפה לנתונים. השתמש בלפחות פריבילגיה ולעיין הרשאות לאחר כל פריסה.
  • (FLT:0) אבחון התלויות של צד שלישי: ההרחבה 1 ( Serverless Applications) לעתים קרובות להשתמש בספריות חיצוניות או מוצרי SaaS.
  • (FLT:0) אי-דיוקן שימור: Logs שנמחקו באופן אוטומטי לאחר 7 ימים עלולים להפר את דרישת השימור של 6 שנים של HIPAA.com. Conform Log policy and take Archival to low-cost Storage.
  • (FLT:0) בהנחה ש-VPC מבודד לחלוטין את התנועה: ההרחבה: ⁇ FLT:1 Lambda פועלת ב- VPC עדיין יכולה להגיע לאינטרנט דרך שער NAT אם מותר, אשר עלול לחשוף נתונים במעבר.
  • (FLT:0) לא לטפל בזכויות נושא נתונים: FLT:1 עבור GDPR, אתה חייב להיות מסוגל למחוק או לייצא נתונים של המשתמש על פי בקשה.מערכות ללא שרת צריכות להיות פונקציות אשר, בהתחשב מזהה משתמש, יכול לאתר ולמחוק את כל הרשומות על פני מסדי נתונים, כיבים וגיבויים.

מחקר: Compliant Serverless Health Applicationline

שקול יישום ללא שרת כי ingests רפואי רשומות מן פורטל ספק, מעבד אותם עבור ניתוח, וחנויות תוצאות.אדריכלות משתמשת HP API Gateway, Lambda, DynamoDB ו- S3. Steps שנלקחו עבור תאימות:

  1. BAA חתם עם AWS המכסה את כל השירותים המשמשים.
  2. כל אחסון (DynamoDB, S3) משתמש בהצפנה KMS-mand עם מפתח ייעודי.
  3. תפקידי Lambda היקפו בקפדנות לטבלאות ה-DymoDB הנדרשות ו-KMS מפתח.
  4. API Gateway משתמש ב-TLS 1.2 ודורש אימות IAM.
  5. כל הפונקציות מופצות ב-VPC ללא גישה לאינטרנט מחוץ ל-V – רק נקודות קצה פרטיות ל-DymoDB ו-S3.
  6. זרמי CloudTrail ו-DymoDB ניתנים ל-Switchs, שנשמרו במשך 6 שנים ב-S3 עם מנעול אובייקטים.
  7. פונקציה נפרדת של Lambda מיישמת את הזכות למחיקה: היא סריקות דינמודי, מוחקת את רשומות המשתמש ושולחת אישור.

עיצוב זה מספק את דרישות חוק אבטחת HIPAA ואת זכויות ה-GDPR ואת התחייבויות האחריות.

משאבים חיצוניים להבנה עמוקה יותר

  • (ב) [15] ,HS HIPAA Security Rule SummaryFLT:1
  • (ב) ◄ [17] , ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇
  • (ב) ,0) ,7 ,7 ,
  • (ב) ,0 ,00 דונם (ה)
  • (ב) מרכז המשאבים של Google Cloud Compliance Center

מסקנה

תכנון יישומים ללא שרת עבור HIPAA ו-GDPR תאימות הוא לא לאחר מחשבה - זה דורש אדריכלות מכוונת, תצורה קפדנית, ניטור מתמשך. על ידי יישום הצפנה, גישה לפחות פריצה, שבילי ביקורת, בקרת תושבות נתונים, והסכמים משפטיים מתאימים, ארגונים יכולים לבנות מערכות ללא שרת שמגנות על נתונים רגישים תוך עמידה בסטנדרטים הרגולטוריים הגבוהים ביותר.