אבטחת API ואסימונים

תקציר

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

מודלים לאימות API - מתי ומה לבחור

מפתח API (סוד סטטי)

פשוט עבור שילוב B2B ותרחישים בסיכון נמוך. לא נושא את ההקשר, דורש אחסון בצד השירות.
השתמש רק ב ־ IP/ASN רשימה, מכסות קבועות, TTL קצר וסיבובים.

OAuth 2. 1/OIDC

תקן לאינטגרציית משתמש ושותף: אסימון גישה (לטווח קצר) + רענון token (סיבוב) + סקופים.
לקוחות ציבוריים עם PKCE; לקוחות חסויים עם סוד לקוח/mTLS.

אישורי לקוח (מ "מ)

Mashina # mashina: אסימון גישה לשירותים על סקופים וקהל מוגדרים לחלוטין, לעתים קרובות ללא רענון (get again).

MTLS (TLS הדדי)

קושר את הזהות לערוץ. אידיאלי עבור אינטגרציה בסיכון גבוה או תשלום (PoP מעל TLS).
ניתן לשלב עם OAuth (אסימונים רק ללקוחות MTLS).

חתימות בקשה (HMAC/EDDSA)

כאשר אתה צריך טרנספורט עצמאי: כותרת חתימה, חותמת זמן ונמיכות. נוח לפתקי אינטרנט ואימות לא מקוון.

פורמטים טוקן וסוגים

JWT (JWS, חתום)

עצמאי, נבדק באופן מקומי; חובה היא ', משנה', 'אוד', 'exp', 'iat', 'jti', 'היקף'.
סיכון - היזכר בקשיים נוספים: השתמש ב ־ TTL קצר (5-15 דקות) + רשימת ”jti” הנזכרת בתקריות.

JWE (מוצפן JWT)

נחוץ אם המטען רגיש (PII). עלות - מורכבות גבוהה יותר ותקורה.

אסימוני התייחסות

זיהוי אטום, שנבדק על ידי Introspection על ידי שרת ההרשאה - קל יותר להחזרה/ריכוז.

PoP/DPoP

קשירת אסימון למפתח לקוח או להפעלת TLS מקטינה את ערכו של האסימון הגנוב.

תוכן סמלי: כמות מספיקה מינימלית

בולים מומלצים (JWT):

'iss' (issuer),' sub '(נושא),' aud' (מערכת יעד/משאב), 'exp' (מונח), 'iat', 'nbf' (אופציונלי), 'jti'.
'scope '/' הרשאות' (מינימום נדרש), 'דייר' (עבור רב-דייר), 'מכשיר _ תואם '/' amr' (שיטת אימות), 'ip '/' asn' (אם מתאים למדיניות).

כללים:

TTL קצר לגישה (5-15 דקות), רענון - 12-48 h (עם סיבוב).
הקהל הוא משאב ספציפי לחלוטין, אחרת ניתן להשתמש בו מחדש.
סקופים - פעולה ואובייקט (לדוגמה, תשלומים: משיכה. לקרוא ').
גודל - 2-4 KB עבור כותרות ופרוקסי; אחרת עלולות להיות בעיות עם שערים.

אישור ומדיניות

RBAC + ABAC: תפקיד + הקשר (ארגון, גיאו, סיכון, מצב התקן).
PEP/PDP Token Validation and Decision on API Gateway/Proxy (שליח/אופ "א) לפני הגשת הבקשה.
חוקים הצהרתיים: חנות בגיט, לעבור מבחני מדיניות במודיעה.

דוגמה רגו (מפושטת):

rego package policy. withdraw

default allow = false

allow {
input. token. aud == "wallet-api"
input. token. scope[_] == "payments:withdraw. create"
input. device. compliant == true input. risk. score < 70
}

בקשת חתימה (HMAC) ו אנטי-שידור חוזר

בעת הצורך: פתקי אינטרנט, אינטגרציה ללא OAuth, בדיקה כפולה פעולות קריטיות.

סכימת כותרת (דוגמה):


X-Client-Id: <id>
X-Timestamp: 2025-11-05T13:20:10Z
X-Nonce: 4d1f...a2
X-Signature: base64(HMAC_SHA256(secret, method + "\n" + path + "\n" + sha256(body) + "\n" + timestamp + "\n" + nonce))

כללים:

דחיית בקשות עם יישור שגוי של הזמן> cens 300 s.
חנות Nunce במשך 5-15 דקות ולא מקבל הילוך חוזר (מטמון ההילוך החוזר).
חתום על תצוגת שאילתה קנונית (שיטה, נתיב, שאילתה, חשיש גוף).

זהות והגנה עסקית

Idempotency-Key למחיקה/תשלום-out/יצירת פעולות: אותו מפתח = אותו אפקט.
חיי המפתח הם זמן פסק זמן עסקי (בדרך כלל 24-72 שעות).
היגיון בצד השרת - השווה פרמטרים שאילתה לאלה שבוצעו בעבר עבור מפתח זה.

דפדפן ולקוחות ניידים

PKCE היא חובה (לקוחות ציבוריים).
רענן אסימון בדפדפן - להימנע; במידת הצורך - תגובת סיבוב + הילוך חוזר (גילוי חוזר).
אחסון: אחסון הפעלה> אחסון מקומי; גב טוב יותר לחזית (BFF) אחראי על אסימונים.
אתר חיסול, מאובטח, Httpally עוגייה; CORS - רשימות הרשאה מפורשות, כותרות ושיטות; הטפת מטמון היא בטוחה.

m2m ואינטגרציה בסיכון גבוה

MTLS + OAuth2 אישורי לקוח עם סקופים ו 'Aud'.
IP/ASN מאפשר-רשימה על השער.
PoP/DPoP או חתימות HMAC מעל TLS עבור פעולות קריטיות.
מכסות ומגבלות דירוג לכל ארגון/לקוח/מפתח.

rotations, recovery ותגובה תקרית

סיבוב מפתח סודי וחתימה (JWKS): מתוכנן + נאכף בתקרית.
השקת מפתח זוגי: לפרסם זוג מפתח חדש מראש (kid2), לחתום על האסימונים עבורו, לשמור את הישן (kid1) לאימות עד TTL מותש.
רענון-סיבוב: כל החלפת רענון = אסימון חדש, הישן הופך מיד לא תקף; חוזר - אות פשרה.
ביטול: עבור JWT - רשימות של recorder 'jti' לזמן קצר; לאסימונים - חסימה מיידית על AS.
תסריטי פריצה: נקודות זכות סטטיות זמניות עם זכויות מינימליות ו-TTL קשה, שיא ביומן.

קצב מגביל, הגנה בוט והגנת כוח גס

גבולות שלוש שכבות: לכל מפתח/לכל IP/לכל ארגון.
פרץ + מתמשך: חלון טוקן-טנק/הזזה.
בדיקות מורכבות: טביעת אצבע התקן, אותות התנהגותיים, חריגות גיאו/ASN, CAPTCHA רק עבור UI.
השבתה/האטה בעת משא ומתן מחדש על חתימה/NMAC וניסיונות אימות נכשלים.

כריתת עצים, מדדים ו SLO

קבוצת היומנים המינימלית: ”בקשה _ id',” לקוח _ id', ”sub”, ”aude”, ”scope”, ”decision”, ”cost',” jti ”,” ip ”,” asn', ”latency”, ”quate _ state”.

מדדים:

הצלחה באימות Token (%), זמן אימות p95.
תדירות של סטיות בהילוך חוזר, כפילות של מפתח אידמפוטנציה.
אחוז הבקשות עם PoP/DPoP/mTLS.
'אאוד/היקף' טעויות, 'exp פג תוקף', משמרות זמן (NTP).

SLO (דוגמאות):

זמינות Auth/AS-99. 95 %/חודש; P95 introspection look 50.
אפס אסימונים עם TTL <60 S בפרוד (שומר מטרי).
פחות מ-0. 1 %/היקף שגיאות ביום (איכות האינטגרציה).

תצורה דוגמאות

שליח: JWT ובדיקת קהל

yaml http_filters:
- name: envoy. filters. http. jwt_authn typed_config:
providers:
as:
issuer: https://auth. example. com/
audiences: ["wallet-api"]
remote_jwks:
http_uri:
uri: https://auth. example. com/.well-known/jwks. json cluster: jwks_cluster cache_duration: 600s rules:
- match: { prefix: "/v1/withdraw" }
requires:
provider_and_audiences:
provider_name: as audiences: ["wallet-api"]

NGINX: mTLS bund

nginx proxy_ssl_server_name on;
proxy_ssl_name wallet. internal;
proxy_ssl_certificate   /etc/nginx/mtls/client. crt;
proxy_ssl_certificate_key /etc/nginx/mtls/client. key;
proxy_ssl_trusted_certificate /etc/nginx/mtls/ca. crt;
proxy_ssl_verify on;
proxy_ssl_verify_depth 2;

דוגמה של כותרת חתימה (webhooks)


X-Signature: t=1730803210,n=ac12...,s=base64(HMAC_SHA256(secret, "POST\n/webhook\nsha256(body)\n1730803210\nac12..."))

השרת דוחה אם 't' הוא מבוגר יותר מ-300 C, 'n' כבר נפגש, או' s 'לא פועם.

הגנה על נתונים ופרטיות

למזער סימני היכר (במיוחד PII) ותקופות חיים.
הצפן בולים רגישים (JWEs) עבור שילוב צד שלישי.
מסכה/DLP ביומנים: אל תרשום גופים עם PAN/PII, אסימונים - רק 'ילד '/דגלים, לא הסוד עצמו.

שגיאות נפוצות

אסימוני גישה ארוכי חיים ורענון נצחי.
העדר 'אוד '/' סקופ' אסימונים הם רב תכליתיים.
חתימה של קורות אינטרנט ללא ”חותמת זמן ”/” נונס”.
בדיקת JWT בלבד ביישום, לא בשער (PEP).
אין סיבובים וחילופי מפתח כפולים.
"CORs' ואפשר שיטות חסרות ביטחון ללא שליטה על הראש.
מאחסן אסימונים ב ”אחסון” בלי חברות טובות.

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

1. מלאי וסיווג של API (ציבורי/שותף/פנימי, רגישות).
2. בחירת מודל AuthN: OAuth2/OIDC להתאמה אישית, MTLS + Calient Criptials/HMAC עבור M2m.
3. אסימונים: TTL קצר, "Aud' קפדני, סקופים, DPoP/PoP לפעולות קריטיות.
4. אימות JWT, חתימות והגבלת קצב לאפליקציה.
5. אנטי-שידור חוזר ואידמפוטנטיות: Timamp/nonce/Idempotency-Key.
6. סיבובים ו-JWKS: מפתח כפול, אוטומציה והתראה.
7. יכולת תצפית: מדדים/SLO, יומני גישה, אותות UEBA.
8. תרגילים: מפתח חתימה, דליפת רענון, עומס מכסה.

פרטים עבור iGaming/fintech

תשלומים/תשלומים: mTLS + PoP/HMAC בלבד, סקופים קפדניים ("למשוך. ליצור '), אידמפוטנטיות נדרשת.
שותפים (PSP/Content Speckers): לכל שותף מפתחות/תעודות, IP/ASN Loise, מכסות בודדות ולוחות מחוונים.
GDPR/PCI DSS: מזעור בולים, איסור על PII באסימונים של צד שלישי, רישום גישה למשאבים רגישים, סקירת גישה רגילה.
אנטי-ניצול: הגבלות התנהגות, גאו-שליטה, הגנה מפני ניצול בונוס ברמת API.

FAQ

JWT או אסימון התייחסות?
JWT - ביצועים ואוטונומיה; משוב מרכזי ופשטות של תגובת-אירוע. לעתים קרובות היברידי: חיצוני - JWT, התייחסות פנימית.

האם ג 'יי-ווי צריך?
רק אם המטען מכיל מח "ש/סודות. אחרת, ג 'וס עם סימני היכר מינימליים.

האם אני יכול לחיות על מפתחות API?
כן, אבל רק עם TTL קצר, מכסות קפדניות, IP-לאפשר-רשימה וחתימה בקשה. עבור משתמשים, OAuth/OIDC מועדף.

חובה על DPoP/PoP?
לא תמיד. אבל לפעולות בסיכון גבוה (תשלומים, מסקנות) רצוי מאוד.

סך הכל

אבטחת API אמינה בנויה על אסימונים קצרי ימים, סקופים מדויקים וקהלים, ערוצים מאובטחים (TLS/MTLS), בקשת חתימה והגנה נגד שידור חוזר קפדנית, מוגברת על ידי מגבלות ויכולת תצפית. הוספת סיבובים אוטומטיים, זריקת מפתח כפולה ושליטה פוליטית על שערים - וה-API שלך יהיה עמיד בפני הדלפות, הילוכים חוזרים והתעללות, תוך שמירה על ביצועים גבוהים וניהול.