أمن ورموز واجهة برمجة التطبيقات

موجز موجز

أمان واجهة برمجة التطبيقات عبارة عن مجموعة من آليات المصادقة والترخيص وحماية التشفير ومكافحة إساءة الاستخدام والمراقبة التي تضمن تنفيذ الطلب لكيان متوقع لمورد متوقع في سياق متوقع. القطعة الأثرية الرئيسية هي رمز (أو طلب توقيع) يثبت الحق في الاتصال. تعتمد البنية الجيدة على الرموز القصيرة الأجل والنطاقات الواضحة والحد الأدنى من الامتيازات وحماية إعادة التشغيل والحد من الأسعار والإجراءات التشغيلية (التناوب والتدقيق والحوادث).

نماذج مصادقة واجهة برمجة التطبيقات - متى وماذا تختار

مفتاح واجهة برمجة التطبيقات (سر ثابت)

بسيطة لدمج B2B والسيناريوهات منخفضة المخاطر. لا يحمل السياق، يتطلب التخزين على جانب الخدمة.
استخدم فقط مع قائمة السماح IP/ASN والحصص الثابتة وقصير TTL والتناوب.

OAuth 2. 1/OIDC

معيار لدمج المستخدم والشريك: رمز الوصول (قصير الأجل) + رمز التحديث (الدوران) + النطاقات.
العملاء العامون - مع PKCE ؛ العملاء السريين - مع سر العميل/mTLS.

وثائق اعتماد العملاء (م 2 م)

Mashina→mashina: رمز الوصول إلى الخدمات على نطاقات محددة بدقة والجمهور، غالبًا دون تحديث (كن مرة أخرى).

mTLS (TLS المتبادل)

يربط الهوية بالقناة. مثالي لتكامل المخاطر العالية أو الدفع (PoP على TLS).
يمكن دمجها مع OAuth (الرموز المميزة فقط لعملاء mTLS).

طلب التوقيعات (HMAC/EdDSA)

عندما تحتاج إلى PoP مستقل عن النقل: رأس مميز وطابع زمني وغير مميز. ملائم للخطابات الشبكية والتحقق غير المتصل بالإنترنت.

تنسيقات وأنواع رمزية

JWT (JWS، توقيع)

الاكتفاء الذاتي، والتحقق محليا ؛ "is'،" sub "،" aud'، "exp"، "iat'،" jti "،" scope ".
المخاطرة - تذكر أكثر صعوبة: استخدم TTL قصير (5-15 دقيقة) + قائمة «jti» المسترجعة في الحوادث.

JWE (مشفر JWT)

مطلوب إذا كانت الحمولة حساسة (PII). التكلفة - زيادة التعقيد والنفقات العامة.

الرموز المرجعية

معرفات غير شفافة، يتم التحقق منها من خلال الاستبطان بواسطة خادم التفويض - استدعاء/مركزية أسهل.

برنامج العمل/برنامج العمل

ربط رمز بمفتاح العميل أو بجلسة TLS يقلل من قيمة الرمز المسروق.

المحتوى الرمزي: الحد الأدنى الكافي

الطوابع الموصى بها (JWT):

«iss' (مُصدر)،» sub «(موضوع)،» aud «(نظام الهدف/المورد)،» exp «(مصطلح)،» iat'، «nbf» (اختياري)، «jti».
"scope "/" الأذونات" (الحد الأدنى المطلوب)، "المستأجر" (بالنسبة للمستأجر المتعدد)، "الجهاز _ الممتثل "/" عمرو" (طريقة التوثيق)، "ip "/" asn' (إذا كان منطبقًا على السياسة).

القواعد:

TTL قصيرة للوصول (5-15 دقيقة)، التحديث - 12-48 ساعة (مع دوران الدوران).
الجمهور ("aud') هو مورد محدد تمامًا، وإلا فإن الرمز" قابل لإعادة الاستخدام ".
النطاقات - الإجراء والكائن (على سبيل المثال، المدفوعات: السحب. ').
الحجم - ≤ 2-4 كيلوبايت للرؤوس والوكلاء ؛ وإلا فقد تكون هناك مشاكل مع البوابات.

الإذن والسياسات

RBAC + ABAC: الدور + السياق (التنظيم، الجغرافيا، المخاطر، حالة الجهاز).
التحقق من صحة الرمز PEP/PDP والقرار بشأن بوابة API/الوكيل (المبعوث/OPA) قبل التقديم.
القواعد الإعلانية: تخزين في Git، اجتياز اختبارات السياسة في CI.

مثال ريغو (مبسط):

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))

القواعد:

رفض الطلبات مع اختلال الوقت> 300 ± s.
متجر Nonce لمدة 5-15 دقيقة ولا تقبل الإعادة (ذاكرة التخزين المؤقت).
وقع على عرض استفسار مقدس (الطريقة، المسار، الاستعلام، تجزئة الجسم).

الهوية وحماية المعاملات

مفتاح الشطب/الدفع/إنشاء العمليات: نفس المفتاح → نفس التأثير.
العمر الرئيسي هو مهلة العمل ≥ (عادة 24-72 ساعة).
منطق جانب الخادم - قارن معلمات الاستعلام بتلك التي تم الالتزام بها سابقًا لهذا المفتاح.

المتصفح وعملاء الهاتف المحمول

PKCE إلزامي (العملاء العامون).
تحديث رمز في المتصفح - تجنب ؛ إذا لزم الأمر - الاستجابة للتناوب + إعادة التشغيل (إعادة الكشف).
التخزين: تخزين الجلسات> التخزين المحلي ؛ أفضل - الظهير الخلفي للواجهة (BFF) مسؤول عن الرموز.
SameSite, Secure, HttpOnly для cookie; CORS - قوائم السماح الصريحة والرؤوس والطرق ؛ التخزين المؤقت آمن.

m2m والتكامل عالي المخاطر

mTLS + OAuth2 وثائق اعتماد العملاء مع النطاقات و "aud'.
قائمة السماح IP/ASN على البوابة.
توقيعات برنامج العمل/منهاج العمل أو HMAC على TLS للعمليات الحرجة.
الحصص وحدود الأسعار لكل منظمة/عميل/مفتاح.

عمليات التناوب والاستدعاء والاستجابة للحوادث

التناوب السري ومفتاح التوقيع (JWKS): مجدول + مفروض على الحادث.
طرح ثنائي المفتاح: انشر زوجًا جديدًا من المفاتيح مقدمًا (kid2)، ووقع الرموز المميزة له، واحتفظ بالزوج القديم (kid1) للتحقق من صحته حتى يستنفد TTL.
التحديث والدوران: كل تبادل تحديث → رمز جديد، يصبح القديم على الفور غير صالح ؛ تكرار - إشارة تسوية.
الإلغاء: بالنسبة لفريق العمل المشترك - قوائم «jti» المسترجعة لفترة قصيرة ؛ للرموز المرجعية - الحظر الفوري على AS.
نصوص زجاج الكسر: أرصدة ثابتة مؤقتة مع الحد الأدنى من الحقوق و TTL الصلب، سجل في السجل.

الحد من المعدل وحماية الروبوت وحماية القوة الغاشمة

حدود ثلاث طبقات: لكل مفتاح/لكل شريك/منظمة.
Burst + مستدام: خزان رمزي/نافذة منزلقة.
الفحوصات المعقدة: بصمة الجهاز، الإشارات السلوكية، الشذوذ الجغرافي/ASN، CAPTCHA فقط لواجهة المستخدم.
الإغلاق/التباطؤ عند فشل إعادة التفاوض بشأن التوقيع/NMAC ومحاولات التوثيق.

قطع الأشجار والمقاييس و SLO

المجموعة الدنيا من السجلات: «طلب _ معرف»، «عميل _ معرف»، «فرعي»، «aud'،» نطاق «،» قرار «،» سبب «،» jti «،» ip «،» asn'، «زمن الوصول»، «حصة _ حالة».

المقاييس:

نجاح التحقق من صحة الرمز (%)، وقت التحقق p95.
تكرار انحرافات إعادة التشغيل، تكرارات مفتاح الحماقة.
النسبة المئوية للطلبات المقدمة في إطار برنامج العمل/برنامج العمل/برنامج العمل/برنامج العمل/برنامج العمل/برنامج العمل في مجال النقل البحري.
أخطاء «aud/scope»، «exp» منتهية الصلاحية، نوبات زمنية (NTP).

SLO (أمثلة):

Auth/AS ≥ 99. 95 في المائة في الشهر ؛ p95 الاستبطان ≤ 50 мс.
رموز صفرية مع TTL <60 s في prod (مقياس الحراسة).
أقل من 0. 1٪ من أخطاء 'aud/scope' يوميًا (جودة التكامل).

أمثلة التكوين

المبعوث: 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 к الخلفية

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;

مثال على ترويسة التوقيع (خطابات الويب)


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

يرفض الخادم ما إذا كان 't' أقدم من 300 c، أو 'n' قد استوفى بالفعل، أو '' لم يتفوق.

حماية البيانات والخصوصية

تقليل السمات المميزة (خاصة PII) والعمر الافتراضي.
قم بتشفير الطوابع الحساسة (JWEs) لدمج الطرف الثالث.
القناع/DLP في جذوع الأشجار: لا تسجل الأجسام باستخدام PAN/PII، الرموز - فقط «الأطفال »/الأعلام، وليس السر نفسه.

أخطاء شائعة

رموز الوصول طويلة العمر والتحديث «الأبدي».
عدم وجود رموز "aud'/" نطاق" → متعددة الأغراض.
توقيع خطوط الويب بدون 'طابع زمني '/' غير مؤقت'.
التحقق من JWT فقط في التطبيق، وليس على البوابة (PEP).
لا دوران وطرح ثنائي المفتاح.
"CORs' وسمحت بطرق غير آمنة دون التحكم بالرأس.
تخزين الرموز في «التخزين المحلي» بدون BFF.

خارطة طريق التنفيذ

1. جرد وتصنيف واجهة برمجة التطبيقات (العام/الشريك/الداخلي، الحساسية).
2. اختيار طراز AuthN: OAuth2/OIDC للمخصص، mTLS + Client Credicals/HMAC لـ m2m.
3. الرموز: TTL قصيرة، "aud' صارمة، نطاقات، DPoP/PO للعمليات الحرجة.
4. PEP على البوابات: التحقق من صحة JWT والتوقيعات وحدود الأسعار للتطبيق.
5. Anti-repay and idempotency: timestamp/nonce/Idempotency-Key.
6. التناوب و JWKS: المفتاح المزدوج والأتمتة والتنبيه.
7. إمكانية الرصد: المقاييس/SLO، سجلات الوصول، إشارات UEBA.
8. التمارين: مفتاح التوقيع، تسرب التحديث، زيادة الحصة.

خصوصية iGaming/fintech

المدفوعات/المدفوعات: mTLS + PoP/HMAC فقط، نطاقات صارمة ('سحب. الخلق ').
الشركاء (PSP/مزودي المحتوى): مفاتيح/شهادات لكل شريك، قائمة السماح IP/ASN، الحصص الفردية ولوحات القيادة.
GDPR/PCI DSS: تقليل الطوابع، وحظر PII في رموز الطرف الثالث، وتسجيل الوصول إلى الموارد الحساسة، والاستعراض المنتظم للوصول.
مكافحة الإساءة: الحدود السلوكية، والتحكم الجغرافي، والحماية من إساءة استخدام المكافآت على مستوى API.

الأسئلة الشائعة

JWT أم رمز مرجعي ؟

JWT - الأداء والاستقلالية ؛ المرجع - التغذية المرتدة المركزية وبساطة الاستجابة للحوادث. غالبًا ما يكون هجينًا: خارجي - JWT، داخلي - مرجع.

هل JWE مطلوب ؟

فقط إذا كانت الحمولة تحتوي على PII/أسرار. خلاف ذلك - JWS مع الحد الأدنى من السمات المميزة.

هل يمكنني العيش على مفاتيح واجهة برمجة التطبيقات ؟

نعم، ولكن فقط مع TTL قصير، وحصص صارمة، وقائمة السماح بـ IP والتوقيع على الطلب. بالنسبة للمستخدمين، يفضل OAuth/OIDC.

DPoP/PO إلزامي ؟

ليس دائما. لكن بالنسبة للعمليات عالية المخاطر (المدفوعات والاستنتاجات) أمر مرغوب فيه للغاية.

المجموع

تم بناء أمان API الموثوق به على رموز قصيرة الأجل ونطاقات دقيقة وجماهير وقنوات آمنة (TLS/mTLS) وتوقيع الطلب وحماية صارمة ضد إعادة التشغيل، معززة بالحدود وقابلية الملاحظة. أضف دورات آلية، وطرح مزدوج المفتاح والتحكم السياسي على البوابات - وستكون واجهة برمجة التطبيقات الخاصة بك مقاومة للتسريبات والإعادة وسوء الاستخدام، مع الحفاظ على الأداء العالي والقدرة على الإدارة.