امنیت API و نشانه

خلاصه ای کوتاه

امنیت API مجموعه ای از مکانیزم های احراز هویت، مجوز، حفاظت رمزنگاری، ضد سوء استفاده و قابلیت مشاهده است که تضمین می کند که یک درخواست یک نهاد مورد انتظار را به یک منبع مورد انتظار در یک زمینه مورد انتظار اجرا می کند. مصنوع کلیدی یک توکن (یا امضای درخواست) است که حق تماس را اثبات می کند. یک معماری خوب به نشانه های کوتاه مدت، حوزه های روشن، حداقل امتیازات، حفاظت از پخش، محدود کردن نرخ و روش های عملیاتی (چرخش، ممیزی، حوادث) متکی است.

مدل های احراز هویت API - چه زمانی و چه چیزی را انتخاب کنید

کلید API (راز استاتیک)

ساده برای ادغام B2B و سناریوهای کم خطر. زمینه را حمل نمی کند، نیاز به ذخیره سازی در سمت سرویس دارد.
فقط با لیست مجاز IP/ASN، سهمیه های ثابت، TTL کوتاه و چرخش استفاده کنید.

اوث 2. 1/OIDC

استاندارد برای ادغام کاربر و شریک: رمز دسترسی (کوتاه مدت) + رمز تازه کردن (چرخش) + حوزه.
مشتریان عمومی - با PKCE ؛ مشتریان محرمانه - با راز مشتری/mTLS.

اعتبار مشتری (m2m)

Mashina → mashina: نشانه دسترسی برای خدمات در حوزه ها و مخاطبان به شدت تعریف شده، اغلب بدون تازه کردن (دوباره).

mTLS (TLS متقابل)

هویت را به کانال متصل می کند. ایده آل برای ادغام با ریسک بالا یا پرداخت (PoP بیش از TLS).
می تواند با OAuth ترکیب شود (نشانه ها فقط برای مشتریان mTLS).

امضای درخواست (HMAC/EdDSA)

هنگامی که شما نیاز به یک PoP مستقل از حمل و نقل دارید: هدر امضا، برچسب زمان و nonce. مناسب برای وب سایت ها و تأیید آفلاین.

فرمت ها و انواع نشانه

JWT (JWS، امضا شده)

خودکفا، به صورت محلی بررسی می شود ؛ «iss»، «sub»، «aud»، «exp»، «iat»، «jti»، «scope» اجباری است.
ریسک - یادآوری دشوارتر: استفاده از TTL کوتاه (5-15 دقیقه) + لیست «jti» فراخوان شده در حوادث.

JWE (JWT رمزگذاری شده)

اگر payload حساس باشد (PII) مورد نیاز است. هزینه - پیچیدگی بالاتر و سربار.

نشانه های مرجع

شناسه های مبهم، از طریق خودآزمایی توسط سرور مجوز بررسی می شود - فراخوانی/تمرکز آسان تر.

PoP/DP

اتصال یک توکن به یک کلید مشتری یا یک جلسه TLS، ارزش توکن سرقت شده را کاهش می دهد.

محتوای نشانه: حداقل کافی

• 'IAT'، 'nbf' (اختیاری)، 'زیر' (موضوع)، 'AUD' (سیستم هدف/منابع)، 'EXP' (مدت)، 'IAT'، '،' JTI '.
• 'scope '/' permissions' (حداقل مورد نیاز)، 'tenant' (برای چند مستاجر)، 'device _ compliant '/' amr' (روش احراز هویت)، 'ip '/' asn' (در صورت لزوم به سیاست).

• TTL کوتاه برای دسترسی (5-15 دقیقه)، تازه کردن - 12-48 ساعت (با چرخش چرخشی).
• مخاطب («aud») یک منبع کاملاً خاص است، در غیر این صورت توکن «قابل استفاده مجدد» است.
• دامنه - اقدام و شی (به عنوان مثال، 'پرداخت: برداشت. بخوانید).
• اندازه - ≤ 2-4 کیلوبایت برای هدر ها و پروکسی ها ؛ در غیر این صورت ممکن است مشکلات با دروازه وجود دارد.

مجوز و سیاست

RBAC + ABAC: نقش + زمینه (سازمان، جغرافیایی، خطر، وضعیت دستگاه).
PEP/PDP Token Validation and Decision on API Gateway/Proxy (Envoy/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) و ضد پخش

در صورت نیاز: webhooks، ادغام بدون 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 دقیقه و تکرار (کش پخش) را قبول نمی کند.
• یک نمای پرس و جو canonized (روش، مسیر، پرس و جو، هش بدن) را امضا کنید.

حفاظت هویت و معامله

Idempotency-کلید برای عملیات نوشتن/پرداخت/ایجاد: همان کلید → همان اثر.
طول عمر کلیدی ≥ زمان وقفه کسب و کار (معمولا 24-72 ساعت) است.
منطق سمت سرور - مقایسه پارامترهای پرس و جو به کسانی که قبلا برای این کلید متعهد است.

مرورگر و مشتریان تلفن همراه

PKCE اجباری است (مشتریان عمومی).
تازه کردن نشانه در مرورگر - اجتناب از; در صورت لزوم - ROTATION + پاسخ پخش (تشخیص پخش).
ذخیره سازی: ذخیره سازی جلسه> ذخیره سازی محلی ؛ backend for frontend (BFF) مسئول توکنها است.
کوکی для SameSite، Secure، HttpOnly ؛ CORS - اجازه صریح لیست ها، هدر ها و روش ها ؛ ذخیره سازی preflight امن است.

m2m و یکپارچگی با خطر بالا

mTLS + OAuth2 اعتبار مشتری با دامنه و 'aud'.
لیست مجوز IP/ASN در دروازه.
امضای PoP/DPoP یا HMAC بر روی TLS برای عملیات بحرانی.
سهمیه ها و محدودیت های نرخ در هر سازمان/مشتری/کلید.

چرخش، یادآوری و پاسخ حادثه

چرخش کلید مخفی و امضا (JWKS): برنامه ریزی شده + اجرا شده در حادثه.
انتشار کلید دوگانه: یک جفت کلید جدید را پیش از آن منتشر کنید (kid2)، نشانه ها را برای آن امضا کنید، یکی از قدیمی ها (kid1) را برای اعتبار سنجی نگه دارید تا TTL خسته شود.
Refresh-rotation: هر تبادل refresh → یک توکن جدید، توکن قدیمی بلافاصله نامعتبر میشود ؛ تکرار - سیگنال سازش.
ابطال: برای JWT - لیست «jti» فراخوانی شده برای مدت کوتاهی ؛ برای نشانه های مرجع - مسدود کردن فوری در AS.
اسکریپت شکستن شیشه ای: اعتبار استاتیک موقت با حداقل حقوق و سخت TTL, ثبت در ورود به سیستم.

محدود کردن نرخ، حفاظت از ربات و حفاظت از نیروی بی رحم

محدودیت های سه لایه: در هر کلید/در هر IP/در هر سازمان.
پشت سر هم + پایدار: نشانه مخزن/کشویی پنجره.
بررسی های پیچیده: اثر انگشت دستگاه، سیگنال های رفتاری، ناهنجاری های جغرافیایی/ASN، CAPTCHA فقط برای UI.
قفل کردن/کاهش سرعت هنگام مذاکره مجدد امضا/NMAC و تلاش های احراز هویت شکست می خورد.

ورود به سیستم، معیارها و SLO

حداقل مجموعه سیاهههای مربوط: 'request _ id', 'client _ id', 'sub', 'aud', 'scope', 'decision', 'reason', 'jti', 'ip', 'asn', 'latency', 'quota _ state'.

• موفقیت اعتبار سنجی توکن (٪)، زمان تأیید p95.
• فرکانس انحرافات تکرار، تکراری از Idempotency-کلید.
• درصد درخواستها با PoP/DPoP/mTLS.
• 'aud/scope' errors, expp 'منقضی شده, شیفت زمانی (NTP).

• در دسترس بودن Auth/AS ≥ 99. 95٪ در ماه ؛ خودآزمایی p95 ≤ 50 мс
• صفر نشانه با TTL <60 s در تولید (گارد متریک).
• کمتر از 0 1٪ از 'aud/scope' errors در روز (کیفیت ادغام).

نمونه های پیکربندی

نماینده: 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;

نمونه ای از هدر امضا (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، نشانه ها وارد نکنید - فقط «بچه »/پرچم ها، نه خود راز.

خطاهای رایج

نشانه های دسترسی طولانی مدت و تجدید «ابدی».
عدم وجود «aud »/« scope» → نشانه ها چند منظوره هستند.
امضای وب سایت بدون «برچسب زمان »/« nonce».
چک کردن JWT تنها در برنامه، نه در دروازه (PEP).
بدون چرخش و چرخش کلید دوگانه.
«CORS» و اجازه روش های ناامن بدون کنترل هدر.
ذخیره نشانه ها در «ذخیره سازی محلی» بدون BFF.

نقشه راه پیاده سازی

1. API موجودی و طبقه بندی (عمومی/شریک/داخلی، حساسیت).
2. انتخاب مدل AuthN: OAuth2/OIDC برای سفارشی، mTLS + اعتبار مشتری/HMAC برای m2m.
3. توکن ها: TTL کوتاه، «aud» سخت، دامنه، DPoP/PoP برای عملیات بحرانی.
4. PEP در دروازه: اعتبار سنجی JWT، امضاها و محدودیت های نرخ به برنامه.
5. ضد پخش و idempotency: برچسب زمان/nonce/Idempotency-کلید.
6. چرخش و JWKS: کلید دوگانه، اتوماسیون و هشدار.
7. قابلیت مشاهده: معیارها/SLO، گزارش های دسترسی، سیگنال های UEBA.
8. تمرینات: کلید امضا، نشت تازه کردن، اضافه بار سهمیه.

ویژگی برای iGaming/fintech

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

سوالات متداول

JWT یا نشانه مرجع ؟

JWT - عملکرد و استقلال ؛ مرجع - بازخورد متمرکز و سادگی پاسخ حادثه. اغلب ترکیبی: خارجی - JWT، داخلی - مرجع.

آیا JWE مورد نیاز است ؟

فقط اگر payload حاوی PII/اسرار باشد. در غیر این صورت - JWS با حداقل نشانه ها.

آیا می توانم با کلیدهای API زندگی کنم ؟

بله، اما فقط با یک TTL کوتاه، سهمیه های سخت، لیست اجازه IP و امضای درخواست. برای کاربران، OAuth/OIDC ترجیح داده می شود.

DPoP/PoP اجباری است ؟

نه همیشه. اما برای عملیات با ریسک بالا (پرداخت، نتیجه گیری) بسیار مطلوب است.

مجموع

امنیت API قابل اعتماد بر روی نشانه های کوتاه مدت، حوزه های دقیق و مخاطبان، کانال های امن (TLS/mTLS)، امضای درخواست و حفاظت از ضد پخش دقیق، افزایش محدودیت ها و قابلیت مشاهده ساخته شده است. چرخش خودکار، اجرای دو کلید و کنترل سیاسی در دروازه ها را اضافه کنید - و API شما در برابر نشت، تکرار و سوء استفاده مقاوم خواهد بود، در حالی که حفظ عملکرد بالا و قابلیت مدیریت.