নির্ধারিত কাজ নাকি মানুষের লগইন: API কোন পরিচয় দেখবে?

একটি নির্ধারিত কাজ এবং লগইন প্রম্পটে দাঁড়ানো একজন মানুষ একই API ডাকে, কিন্তু ভিন্ন ক্রেডেনশিয়াল, ভিন্ন জীবনকাল ও ভিন্ন মালিক নিয়ে। কাজটির দরকার নেটওয়ার্ক পথ, অ্যাপ্লিকেশন পরিচয় ও অনুমতির সেট; মানুষের দরকার লগইন, দ্বিতীয় ফ্যাক্টর ও সেশন। দুটো মিশিয়ে ফেললে এমন অটোমেশন তৈরি হয় যা মানুষের পাসওয়ার্ড বদলালেই ভেঙে যায়, কিংবা এমন বহু-ফ্যাক্টর নীতি যা cron কাজ বাঁচিয়ে রাখতে ঠিক ততটুকুই দুর্বল করা হয়।

তিনটি গেট যা একটির মতো দেখায়

সোর্স-অ্যাড্রেস নিয়ম জিজ্ঞেস করে অনুরোধটি কোথা থেকে এসেছে। প্রমাণীকরণ জিজ্ঞেস করে কে ডাকছে এবং কোন প্রমাণ দেখানো হয়েছে। অনুমোদন জিজ্ঞেস করে এই প্রিন্সিপাল এই কাজটি করতে পারে কি না। VPN কেবল তিনটির প্রথমটিই বদলায়, আর তা কাজটির জন্য নয়, হোস্টের প্রতিটি প্রসেসের জন্য বদলায়, তাই ঘটনার রেকর্ডে তিনটি পর্যবেক্ষণ আলাদা রাখুন।

এই কারণেই এগ্রেস নোড বদলে সোর্স-অ্যাড্রেস প্রত্যাখ্যান সারানো যায়, অথচ অবৈধ টোকেন অপরিবর্তিত থাকে। এই কারণেই বৈধ API টোকেন থাকলেও এমন কাজ থেকে ব্যক্তিগত এন্ডপয়েন্টে পৌঁছানো যায় না যার সেখানে কোনো রুট নেই।

ইন্টারঅ্যাকটিভ পথ অটোমেশনের জন্য খারাপ টেমপ্লেট

মানুষের লগইন স্ক্রিপ্টে লেখা লোভনীয়, কারণ এটি একবার কাজ করে। স্ক্রিপ্টটি একটি পাসওয়ার্ড, সম্ভবত এক-বার-পাসওয়ার্ডের বীজ সংরক্ষণ করে, তারপর এমন একটি চ্যালেঞ্জের উপর নির্ভর করে যা মানুষের প্রয়োজন ধরে নিয়ে তৈরি। OAuth-এর নিরাপত্তা-বিষয়ক বর্তমান সেরা অনুশীলন, RFC 9700, resource-owner-password-credentials গ্রান্ট নিষিদ্ধ করে এবং ব্যাখ্যা করে কেন এটি দুই-ফ্যাক্টর ও বহু-ধাপ প্রমাণীকরণের সঙ্গে খারাপভাবে মেলে।

সমর্থিত বিকল্প সাধারণত একটি গোপন-ক্লায়েন্ট প্রবাহ, যেখানে অনুমোদন সার্ভার অ্যাপ্লিকেশনকে প্রমাণীকরণ করে ও টোকেন দেয়। RFC 6749-এর 4.4 ধারায় client-credentials গ্রান্ট তার একটি উদাহরণ। এর অস্তিত্বের অর্থ এই নয় যে প্রতিটি API এটি গ্রহণ করে, কিংবা ব্যবহারকারীর ডেলিগেট করা কাজ এটি দিয়ে প্রতিস্থাপন করা যায়, কারণ এসব প্রশ্ন সেবার মালিকের। কোড লেখার আগে জিজ্ঞেস করুন সেবাটি কোন মানবহীন মডেল সমর্থন করে।

VPN এখনও কোথায় প্রযোজ্য

একটি ব্যক্তিগত API-র প্রয়োজনীয় নেটওয়ার্ক পথ VPN দিতে পারে, এবং এটি বৈধ ভূমিকা। এটি অ্যাপ্লিকেশনের কাছে কাজটির প্রমাণীকরণ করে না, আর কাজটি কী করতে পারবে তার পরিধিও নির্ধারণ করে না। ভাগ করা এগ্রেস ঠিকানা কাজটির নয়, হোস্টের পরিচয় দেয়, তাই সেই ঠিকানার জন্য অ্যালাউলিস্টে একটি এন্ট্রি সেখানে চলা প্রতিটি প্রসেসকেই প্রবেশ দেয়।

কাজটি যদি ভাগ করা রানারে চলে, তবে এই পার্থক্য কম নয়, বেশি গুরুত্বপূর্ণ। একই হোস্টের অন্য ওয়ার্কফ্লো রুট ও ঠিকানা উত্তরাধিকারে পায়, আর API দুটিকে আলাদা করতে পারে না। এটি ভাগ করা পাসওয়ার্ডের মতোই একই দুর্বলতা, এক স্তর নিচে নামানো। নিষেধাজ্ঞাটি সেখানে রাখুন যেখানে অ্যাপ্লিকেশন তা প্রয়োগ করতে পারে, আর অ্যালাউলিস্ট আরও সংকীর্ণ করতে না পারলে রানারকে বিচ্ছিন্ন করুন।

দুটি নকশা সৎভাবে তুলনা করুন

মানুষের লগইন আপনাকে দেয় সত্যিকারের একজন ব্যক্তি, সত্যিকারের দ্বিতীয় ফ্যাক্টর ও নিরীক্ষাযোগ্য সেশন, কিন্তু এটি মানবহীনভাবে চলতে পারে না। অ্যাপ্লিকেশন পরিচয় আপনাকে দেয় মানবহীন সম্পাদন, পর্যালোচনাযোগ্য পরিধি ও ঘোরানো যায় এমন ক্রেডেনশিয়াল, কিন্তু এটি এমন ব্যবহারকারীর পক্ষে কাজ করতে পারে না যে কিছুই ডেলিগেট করেনি। কোনোটিই অন্যটির দুর্বল সংস্করণ নয়; তারা ভিন্ন প্রশ্নের উত্তর দেয়। বেছে নিন এই ভেবে যে কাজটি কি কেউ উপস্থিত না থেকেই চলতে হবে, এবং অপারেশনটি কি নির্দিষ্ট একজন ব্যবহারকারীর নামে আরোপিত হতে হবে।

দুটি উত্তরই যদি হ্যাঁ হয়, তবে নকশার ধার করা পাসওয়ার্ড নয়, ডেলিগেশন মডেল দরকার। সেই সিদ্ধান্তটি লিখে রাখুন যেখানে পরের রক্ষণাবেক্ষণকারী তা পাবেন।

হস্তান্তরের আগে কী যাচাই করবেন

প্রকৃত ওয়ার্কার থেকে একটি অনুমোদিত অপারেশন ও একটি আবশ্যক প্রত্যাখ্যান চালান, এবং দুটি ফলাফলই রাখুন। তারপর মেয়াদোত্তীর্ণ ক্রেডেনশিয়াল এবং নেটওয়ার্ক পথ অনুপলব্ধ থাকলে আচরণ পরীক্ষা করুন, কারণ এই দুটিই সেই ব্যর্থতা যা রাতে কাউকে জাগায়।

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

প্রিন্সিপাল, পরিধি, রোটেশনের মালিক ও সম্পাদন পরিবেশ সেই ফলাফলের পাশে লিখে রাখুন। সেই রেকর্ডই পরের রোটেশনকে ঘটনা নয়, রুটিন করে তোলে। এটি সেই অংশও যা একজন নিরীক্ষক চান।