کار زمان‌بندی‌شده یا ورود انسان: API باید کدام هویت را ببیند؟

یک کار زمان‌بندی‌شده و انسانی که پشت صفحه ورود ایستاده است، همان API را با اعتبارنامه‌های متفاوت، طول عمرهای متفاوت و مالک‌های متفاوت فراخوانی می‌کنند. کار به مسیر شبکه، هویت برنامه و مجموعه‌ای از مجوزها نیاز دارد؛ انسان به ورود، عامل دوم و نشست نیاز دارد. آمیختن این دو، خودکارسازی‌ای می‌سازد که هر بار گذرواژه انسان عوض شود می‌شکند، یا سیاستی چندعاملی که دقیقاً به اندازه‌ای تضعیف شده که یک کار cron زنده بماند.

سه دروازه که شبیه یکی هستند

قانون نشانی مبدأ می‌پرسد درخواست از کجا آمده است. احراز هویت می‌پرسد چه کسی تماس می‌گیرد و چه شواهدی ارائه شده است. مجوزدهی می‌پرسد آیا این اصل می‌تواند این عملیات را انجام دهد. یک VPN فقط اولی از این سه را تغییر می‌دهد، و آن را برای هر فرایند روی میزبان تغییر می‌دهد نه فقط برای کار، پس سه مشاهده را در گزارش رخداد جدا نگه دارید.

به همین دلیل تغییر گره خروج می‌تواند رد شدن به‌خاطر نشانی مبدأ را برطرف کند و توکن نامعتبر را دست‌نخورده بگذارد. به همین دلیل هم یک توکن معتبر API، نقطه پایانی خصوصی را از کاری که مسیری به آن ندارد در دسترس نمی‌کند.

مسیر تعاملی الگوی ضعیفی برای خودکارسازی است

اسکریپت کردن ورود یک انسان وسوسه‌انگیز است چون یک بار کار می‌کند. اسکریپت یک گذرواژه و شاید یک بذر گذرواژه یک‌بارمصرف را ذخیره می‌کند و سپس به چالشی وابسته است که برای نیاز به انسان طراحی شده است. بهترین رویه امنیتی کنونی OAuth، یعنی RFC 9700، کمک هزینه resource-owner-password-credentials را ممنوع می‌کند و توضیح می‌دهد چرا با احراز هویت دوعاملی و چندمرحله‌ای به‌خوبی جور درنمی‌آید.

جایگزین پشتیبانی‌شده معمولاً جریان کارخواه محرمانه است که در آن سرور مجوزدهی برنامه را احراز هویت می‌کند و توکن صادر می‌کند. کمک هزینه client-credentials در RFC 6749 بخش 4.4 یک نمونه است. وجود آن به این معنا نیست که هر API آن را می‌پذیرد، یا اینکه وظیفه تفویض‌شده به کاربر را می‌توان با آن جایگزین کرد، چون این‌ها پرسش‌هایی از مالک سرویس است. پیش از نوشتن هر کدی بپرسید سرویس کدام مدل بی‌ناظر را پشتیبانی می‌کند.

VPN هنوز کجا جا دارد

یک VPN می‌تواند مسیر شبکه‌ای را که یک API خصوصی لازم دارد فراهم کند، و این نقش مشروعی است. اما کار را در برابر برنامه احراز هویت نمی‌کند و دامنه کاری که کار می‌تواند انجام دهد را تعیین نمی‌کند. یک نشانی خروج مشترک هم میزبان را شناسایی می‌کند نه کار را، پس یک ورودی در فهرست مجاز برای آن نشانی هر فرایندی را که روی آن اجرا می‌شود می‌پذیرد.

اگر کار روی یک اجراکننده مشترک اجرا شود، این تمایز بیشتر مهم است نه کمتر. یک گردش کار دیگر روی همان میزبان مسیر و نشانی را به ارث می‌برد و API نمی‌تواند آن دو را از هم تشخیص دهد. این همان ضعفی است که یک گذرواژه مشترک دارد، یک لایه پایین‌تر منتقل شده. محدودیت را جایی بگذارید که برنامه بتواند آن را اعمال کند، و اگر نمی‌توانید فهرست مجاز را تنگ‌تر کنید، اجراکننده را جدا کنید.

دو طراحی را صادقانه مقایسه کنید

ورود انسانی به شما یک شخص واقعی، یک عامل دوم واقعی و نشستی قابل حسابرسی می‌دهد، و نمی‌تواند بی‌ناظر اجرا شود. هویت برنامه به شما اجرای بی‌ناظر، دامنه‌ای قابل بازبینی و اعتبارنامه‌ای می‌دهد که می‌توانید بچرخانید، و نمی‌تواند به نیابت از کاربری که چیزی تفویض نکرده عمل کند. هیچ‌کدام نسخه ضعیف‌تر دیگری نیست؛ آن‌ها به پرسش‌های متفاوتی پاسخ می‌دهند. با این پرسش انتخاب کنید که آیا وظیفه باید بدون حضور کسی اجرا شود و آیا عملیات باید به کاربر مشخصی نسبت داده شود.

اگر هر دو پاسخ بله است، طراحی به مدل تفویض نیاز دارد نه به گذرواژه قرض‌گرفته. آن تصمیم را جایی بنویسید که نگهدارنده بعدی آن را پیدا کند.

پیش از تحویل چه چیزی را بررسی کنید

یک عملیات مجاز و یک رد لازم را از کارگر واقعی اجرا کنید و هر دو نتیجه را نگه دارید. سپس اعتبارنامه منقضی و رفتار وقتی مسیر شبکه در دسترس نیست را آزمایش کنید، چون این‌ها همان دو شکستی هستند که کسی را شب بیدار می‌کنند.

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer TOKEN" https://api.example.com/v1/records

اصل، دامنه، مالک چرخش و محیط اجرا را کنار آن نتیجه ثبت کنید. همان ثبت است که چرخش بعدی را به روال تبدیل می‌کند نه به رخداد. آن همچنین همان بخشی است که حسابرس می‌خواهد.