GH GambleHub

חיזוק סביבת הייצור והביקורת

1) מטרות ותחום אחריות

הייצור אינו רק ”הסביבה היציבה ביותר”, אלא גם המותקפת ביותר. המשימה שלנו:
  • למזער את אזור ההתקפה ורדיוס פיצוץ;
  • הגנו על ערוצים, חשבונות, סודות וחפצי משלוח;
  • גלה והגיב לתקריות מהר יותר ממטרות MTTR
  • אשר ציות (GDPR/PCI DSS/כללים מקומיים)
  • לשמר את האודיטציה של כל הפעולות הקריטיות.

עקרונות מפתח: אפס אמון, חיסיון מינימלי, סגמנט, הכל-כקוד, ביטחון-לפי-מחדל.

2) היקף רשת וקטע

קטעים: Edge (WAF, Bot management, DDOS), DMZ (שער), App (מיקרו-רווחים), Data (DB/caches), Backoffice/Ops (CI/CD, תצפית).
מדיניות L4/L7: מכחיש על ידי ברירת מחדל, לאפשר מפורשות על ידי שירותים/אמצעים/נמלים.
MTLS בתוך אשכול TLS 1. 2 + בהיקף, HSTS, צפנים מאובטחים.
מסנן קלט: WAF (OWASP Top-10), אנטי-בוט, מגבלות קצב, בלוקים גיאו/ASN, CAPTCHA במסלולי סיכון.
הגנה על DDOS: תמיד-on + הפחתה אוטומטית, פרופילים נפרדים לתוכן API/סטטי.
בקרת יציאה: רק מארחים חיצוניים נחוצים לספקים (PSP/KYC/games).

3) זהויות, גישה והרשאות (IAM/PAM)

SSO (OIDC/SAML) + MFA לבני אדם; אסימונים של OIDC/Workload Identity עבור שירותים.
RBAC/ABAC: תפקידים עם הרשאות נדרשות מינימום; ”זכוכית שבורה” גישה תחת ביקורת וטי-טי-אל.
פגישה חסויה לפי דרישה, הקלטה מלאה ורישום.
CIEM (עננים): חיפוש אחר זכויות מוגזמות ותפקידים מתים, תיקון אוטומטי.
גישה לנתוני ייצור: רק באמצעות קפיצה/פרוקסי מאושרים, עם מיסוך PII.

4) סודות וקריפטוגרפיה

KMS/HSM: אחסון מפתחות, הצפנת מעטפות, סיבוב עם הודעות.
מנהל סודי: נקודות זכות קצרות טווח, לא כולל סודות של גיט/יומנים.
חתימות: חפצים (cosign), חוברות אינטרנט (HMAC), אסימוני שירות.
שדות PAN/PII: tokenization/הצפנה במנוחה; מסווה ביומנים ותצוגות מקדימות.
מדיניות סיבוב: מפתחות/תעודות/סיסמאות - שגרה ואילוץ.

5) מכולות וקוברנטס (CWPP/KSPM)

תמונות בסיס: פגיעות מינימליות, סריקה על מז "פ; ללא חללים בכל מקום אפשרי.
מדיניות ההרשמה (OPA/Gatekeeper/Kyverno): איסור ”עדכני”, ”מיוחס”, HostPath; דורש חתימות תמונה.
מדיניות Networks: תקשורת שירות לשירות רק בעת הצורך.
PodSecurity: יכולות מוגבלות, FS קריאה בלבד, seccomp, AppArmor.
סודות: מחנות סודית CSI (KMS); אין סוד במניפסטים.
הגנה בזמן ריצה: כללי התנהגות (eBPF), התראות לסטיות.

דוגמה לכלל אופ "א (לא לאפשר תמונות לא חתומות):
rego package k8sadmission deny[msg] {
input. request. kind. kind == "Pod"
some c image:= input. request. object. spec. containers[c].image not startswith(image, "registry. company. com/signed/")
msg:= sprintf("Image must be signed and come from trusted registry: %v", [image])
}

6) שרשרת אספקה: אמון אבל לבדוק

SBOM לכל מבנה; אחסון וקישור לשחרור.
חתימות תמונה/מניפסט, אימות בבקר הכניסה.
תעודות SLSA: מקור מספק של חפצים.
מדיניות-כקוד: Confest/OPA על Terraform/Helm/K8s לפני המיזוג.
איסור על ”תיקון של הרגע האחרון” על המוצר: כל השינויים הם רק דרך הצינור.

7) פגיעות וניהול טלאים

SCA/SAST/DAST absci; חסימת סף עבור קריטי/גבוה.
צרור עדכונים שבועי (תמונות, חבילות מערכת הפעלה, ספריות) + חירום לא מתוכנן.
תיקונים בוצעו בעקבות כרטיסים/שחרורים המקושרים ל ־ CVE/SBOM.
EASM: מבט חיצוני על משטח ההתקפה (תת-דומים, נמלים פתוחים, תעודות).
בדיקות עט רגילות: לפחות פעם בשנה + ממוקדות בזרימות קריטיות (תשלומים/CCM).

8) יומנים, מדדים, עקבות ואחסון של חפצי ביקורת

רישומים סטנדרטיים (JSON) עם ”trace _ id',” request _ id', משתמש/דייר/geo (פסאודנימוס), ללא PII/PAN.
Metrics: p50/p95/p99, שגיאה-קצב, רוויה, DLQ, retrai, business KPI (זמן-לארנק).
OTEL: מקצה לקצה עבור מסלולים קריטיים (הפקדה/CCL/פלט).
SIEM: מתאם אירועים (אימות, שינויי תפקידים, פעולות ניהול, כללי WAF/BOT).
תגובות אוטומטיות (בידוד האח, החזרת סמלים, בלוק IP/ASN, איסור שחרור).
שימור: יומני הפעלה - 30-90 ימים אחסון חם, חפצי ביקורת - ארוך יותר, על פי מדיניות.

תבנית רישום מינימלית (דוגמה):
json
{
"ts":"2025-11-05T15:00:00Z",
"sev":"WARN",
"svc":"payments-api",
"route":"POST /v1/payments",
"trace_id":"2f9f...e1",
"user":"anon",
"tenant":"eu-casino-12",
"geo":"EU",
"event":"circuit_breaker_open",
"provider":"psp-1"
}

9) אנטי-בוטים, הונאות ותרחישי הגנה

ניהול בוט: חתימות/התנהגות, טביעת-התקן, אתגרים דינמיים.
הגבלת קצב/מכסות: לכל משתמש/דייר/IP; הסתגלות בחריגות.
חיישני RASP בנקודות קצה קריטיות (ניסיונות לעקוף חתימות של חוברות אינטרנט, סחף שעון, מסירה מחדש).
אותות הונאה: התאמה לפי ערוצים (התחברות, תשלומים, KYC), הסלמה אוטומטית.

10) הגנה, DR ו ־ BCP

מטרות RTO/RPO מוגדרות ונבדקות (לדוגמה, RTO 1 שעה, RPO 5 דקות עבור בסיסי נתונים בתשלום).
גיבויים: מוצפנים, באופן מחזורי באחסון לא מקוון; בדיקות שחזור רגילות.
Geo-שכפול: נכס-אחריות/נכס-נכס על ידי אזור; כשל DNS עם בקרת TTL.
תיקייה של תלויות קריטיות (PSP/KYC/game aggregators) והחלפת תוכניות.

11) אירועים ותגובה

ספרי ריצה: לצניחת הספק, צמיחת הלינה, פשרה סמלית, DDOS.
בכוננות: 24/7, סיבובים ודפי הדף; אימון משותף של ”חדר מלחמה”.
תקשורת: תבניות הודעה ללקוחות/שותפים ורגולטורים.
פעולות למניעת חזרות, עדכון מדיניות/ספרי משחק.

12) ציות ופרטיות

GDPR: מזעור נתונים, קופות הסכמה, זכות למחוק/יציאה; DPIA לספקים חדשים.
PCI DSS: PAN tokenization/בידוד אזורי, מקטעי רשת, יומני גישה קפדניים.
דרישות מקומיות (תחום שיפוט שוק): אחסון נתונים באזור, דיווח, עדכון חלונות.
שושלת נתונים: היכן וכיצד זרימת PII/PAN; מזימות ו DPIA ב DevPortal.

13) ביקורת: סוגים, חפצים ומחזור

סוגי ביקורת חשבונות:
  • ציות למדיניות, שליטה בשינויים, גישה, סודות, רישומים, צינורות.
  • חיצוני (מדי שנה/לפי דרישות): PCI/GDPR/ויסות מקומי, בדיקות עט, דוחות SOC של ספקים.
חפצי מפתח (מה לבשל מראש):
  • מדיניות אבטחה, תפקיד מטריצת IAM, רשימה יוצאת דופן עם תאריך תפוגה.
  • רישומי שינוי תשתית (IC), דו "חות CI/CD (SBOM, חתימות, בדיקות).
  • רשמים של ספקים (PSP/KYC/games), DPIA/ספקים-הערכות סיכון, חוזים ו-SLAs.
  • יומני גישה למכירות, תוצאות סבב סודי, דו "חות SIEM/SOAR.
  • DR/BCP תוכניות ופרוטוקולים של בדיקות שחזור אחרונות.
גישת ביקורת חשבונות:
  • ”ראיה-ראשונה”: כל פרקטיקה היא חפץ שניתן לאמת.
  • ”אין בני אדם בדרבן”: מקסימום באמצעות צינורות ובקשות מאושרות; כל המפגשים, מתחת ליומן.
  • איתור הכל - שינוי מפה לאירועים/מדדים.

14) מעקות בטיחות כקוד: דוגמאות

Confest for Terraform (איסור מסד נתונים ציבורי):
rego package terraform. deny deny[msg] {
input. resource. type == "aws_db_instance"
input. resource. publicly_accessible == true msg:= "RDS must not be public"
}

מדיניות (K8): דורש תוויות אבטחה ומגבלות משאבים

yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata:
name: enforce-security-labels-and-limits spec:
rules:
- name: require-labels match: {resources: {kinds: ["Deployment","StatefulSet"]}}
validate:
message: "security labels required"
pattern:
metadata:
labels:
security. tier: "?"
data. classification: "?"
- name: require-limits match: {resources: {kinds: ["Deployment","StatefulSet"]}}
validate:
message: "resources limits/requests required"
pattern:
spec:
template:
spec:
containers:
- resources:
limits:
cpu: "?"
memory: "?"
requests:
cpu: "?"
memory: "?"

15) רשימת היגיינה יומית

[ ] מדיניות WAF/BOT פעילה, חתימות מעודכנות; אנטי-DDOS במצב תמיד-על.
[ ] בקרי קבלה באשכול במדינת האכיפה, לא ביקורת.
[ ] כל תמונות ההפקה חתומות; SBOM זמין וקשור לשחרור.
[ ] פגיעות קריטית/גבוהה - חסר או קבוע עם יוצאים מן הכלל תאריך.
[ ] סיבוב של סודות/תעודות - בלוח הזמנים, אין עיכובים.
[ ] SIEM מתאם בין IAM/שחרור אירועים של כניסה/שינוי; ספרי משחק של SOAR נבחנים.
[ ] גיבויים עברו, לשחזר את המבחן בלוח הזמנים; ד "ר תוכנית תקפה.
[ גישה ] למזון - רק באמצעות SSO + MFA/PAM; כל המפגשים מוקלטים.
[ ] "לא מח" ש ביומנים "- תוקף על ידי סורקים; מיסוך מופעל.
[ ] שחררו שערים ותצפית מעודכנת ”כקוד”.

16) מודל בגרות (קצר)

1. שינויים בסיסיים, היקף אחד, ניטור חלקי.
2. פיצול מתקדם, IAM/RBAC, חפצים חתומים, WAF/DDOS, SIEM, טלאים רגילים.
3. מומחה - אפס נאמנות, מעקות בטיחות כקוד, בדיקת SLSA-attestation, הגנה בזמן ריצה, SOAR-אוטומציה, ”אין בני אדם בדרבן”, ביקורת מתמשכת.

17) מימוש מפת דרכים

M0-M1 (MVP): קטעי רשת, WAF/DDOS, SSO + MFA, KMS, מדיניות קבלה בסיסית, לוגים/מדטים/שבילים תקניים, SIEM.
M2-M3: חתימות תמונה ואימות כניסה, SBOM, Confest/OPA ב-IAC, PAM, תוכנית סיבוב, טלאים רגילים, בדיקות DR ראשונות.
M4-M6: ספרי משחק SOAR, eBPF/runtime expection, EASM, חבילת ציות (PCI/GDPR), סט מלא של חפצי ביקורת, אזור הטבעת-DR-by.
M6 +: Zero-Trust Network (MTLS בכל מקום), CIEM, Automated Authority Trail Reports.

תקציר

הדחף החזק הוא לא מערכת של כללי ”ברזל”, אלא מערכת: קטגוריות, זהויות וסודות קפדניים, משלוח מאובטח, מכולות מנוהלות, תצפיות ותגובה אוטומטית. הוספת אימות (ביקורת חפצים, SBOM/חתימות, יומנים), וסביבת הייצור הופכת צפויה, ניתנת לניהול ומוכנה לביקורת חיצונית - ללא פשרות על מהירות שחרור ועסקי SLOs.

Contact

צרו קשר

פנו אלינו בכל שאלה או צורך בתמיכה.אנחנו תמיד כאן כדי לעזור.

Telegram
@Gamble_GC
התחלת אינטגרציה

Email הוא חובה. Telegram או WhatsApp — אופציונליים.

השם שלכם לא חובה
Email לא חובה
נושא לא חובה
הודעה לא חובה
Telegram לא חובה
@
אם תציינו Telegram — נענה גם שם, בנוסף ל-Email.
WhatsApp לא חובה
פורמט: קידומת מדינה ומספר (לדוגמה, +972XXXXXXXXX).

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