এপিআই নিরাপত্তার সর্বোত্তম অনুশীলন

এপিআই নিরাপত্তার সর্বোত্তম অনুশীলন: ডেভেলপারদের জন্য চেকলিস্ট

সুচিপত্র

অবশ্যই পঠনীয় পোস্ট

TL; ডিআর

বেশিরভাগ এপিআই লঙ্ঘনের মূল কারণ হলো ত্রুটিপূর্ণ অনুমোদন, কোনো অভিনব এক্সপ্লয়েট নয়। OWASP API Security Top 10-এর শীর্ষ পাঁচটি বিভাগের মধ্যে তিনটিই হলো অনুমোদন ব্যর্থতা, যার নেতৃত্বে রয়েছে বল.

যার অস্তিত্ব সম্পর্কে আপনি জানেন না, তাকে সুরক্ষিত করতে পারবেন না। অনুপযুক্ত মজুদ ব্যবস্থাপনা এর নিজস্ব একটি OWASP ঝুঁকি বিভাগ রয়েছে, এবং এটিই সেই ভিত্তি যার উপর অন্য সব নিয়ন্ত্রণ নির্ভর করে।

মোতায়েনের আগে ঝুঁকি শনাক্ত করুন, পরে নয়। কোড এবং এপিআই স্পেসিফিকেশনের স্ট্যাটিক বিশ্লেষণে একটি ত্রুটিপূর্ণ এন্ডপয়েন্ট পাওয়া গেছে। pull requestএকটির খরচে commitরানটাইম টেস্টিং-এর মাধ্যমে লাইভে একই সমস্যাটি খুঁজে পাওয়া যায়, যার জন্য একটি ইনসিডেন্টের খরচ হয়।

এটি একটি চেকলিস্ট যা ক্রমাগত চালাতে হবে। প্রতিটিতে pull request, এটি লঞ্চ-পূর্ব পর্যালোচনা নয়: ২৪টি অনুশীলনইনভেন্টরি এবং অনুমোদন থেকে শুরু করে রেট লিমিটিং, রেসপন্স ডেটা এক্সপোজার এবং তৃতীয় পক্ষের বিশ্বাসযোগ্যতা পর্যন্ত।

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

কেন এপিআই নিরাপত্তার সর্বোত্তম অনুশীলনগুলো এখন ভিন্ন দেখায়

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

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

নিচের প্রতিটি বিষয়ের মূল বিষয়বস্তু এটাই। ভালো এপিআই ব্যবস্থাপনার সেরা অনুশীলন শুরু হয় আপনার কাছে কী আছে তা জানার মাধ্যমে, শুধু আপনি যা নথিভুক্ত করতে মনে রেখেছেন তা রক্ষা করার মাধ্যমে নয়।

এপিআই নিরাপত্তার সর্বোত্তম অনুশীলনসমূহ এক নজরে

বিস্তারিত চেকলিস্টের আগে, এখানে এর সংক্ষিপ্ত রূপটি দেওয়া হলো: কী বাস্তবায়ন করতে হবে, এটি আসলে কী থেকে সুরক্ষা দেয় এবং কতটা জরুরি ভিত্তিতে তা করতে হবে।

অনুশীলনএটি কিসের বিরুদ্ধে সুরক্ষা দেয়অগ্রাধিকার
HTTPS/TLS এনক্রিপশনডেটা ইন্টারসেপশন, ম্যান-ইন-দ্য-মিডল অ্যাটাকপ্রয়োজনীয়
প্রমাণীকরণ (OAuth 2.0, JWT)অননুমোদিত প্রবেশ, পরিচয় জালিয়াতিপ্রয়োজনীয়
অনুমোদন এবং প্রবেশাধিকার নিয়ন্ত্রণবিশেষাধিকার বৃদ্ধি, তথ্য ফাঁসপ্রয়োজনীয়
ইনপুট যাচাইকরণইনজেকশন আক্রমণ, ত্রুটিপূর্ণ অনুরোধপ্রয়োজনীয়
সম্পূর্ণ এপিআই ইনভেন্টরিনথিবিহীন এবং অপ্রচলিত এন্ডপয়েন্টগুলি উন্মুক্ত রাখা হয়েছে।প্রয়োজনীয়
হার সীমিতব্রুট-ফোর্স অ্যাটাক, ডিডিওএস, অপব্যবহারউচ্চ
এপিআই কী ব্যবস্থাপনাপরিচয়পত্র চুরি, অননুমোদিত ব্যবহারউচ্চ
লগিং এবং পর্যবেক্ষণঅলক্ষিত লঙ্ঘন, ঘটনার ধীর প্রতিক্রিয়াউচ্চ
স্থাপনের আগে স্থির বিশ্লেষণকেউ পর্যালোচনা করার আগেই এক্সপোজারটি প্রোডাকশনে পাঠানো হয়।উচ্চ
নিরাপত্তা পরীক্ষা (SAST + DAST)অজানা দুর্বলতা, পশ্চাদপসরণউচ্চ

যেকোনো এপিআই (API), তা অভ্যন্তরীণ হোক বা সর্বজনীন, তার জন্য “Required” সারিটিকে একটি অলঙ্ঘনীয় ভিত্তি হিসেবে বিবেচনা করুন। “High” অগ্রাধিকারের আইটেমগুলোই একটি প্রোগ্রামকে অন্যদের থেকে আলাদা করে, যা বিভিন্ন সমস্যা দ্রুত শনাক্ত করতে পারে। pull request যে ঘটনা প্রতিবেদন থেকে বিষয়টি জানতে পারে।

এপিআই নিরাপত্তা সর্বোত্তম অনুশীলন চেকলিস্ট

১. প্রতিরক্ষা গড়ে তোলার আগে একটি সম্পূর্ণ মজুদ গড়ে নিন।

যে এন্ডপয়েন্টের অস্তিত্ব সম্পর্কে আপনি জানেন না, তাকে আপনি সুরক্ষিত করতে পারবেন না। এপিআই সুরক্ষার প্রতিটি সেরা অনুশীলন শুরু করার আগে একটি প্রকৃত তালিকা তৈরি করুন: প্রতিটি এন্ডপয়েন্ট, তার মেথড, তার পাথ, এটি যে সার্ভিস ও মডিউলের অন্তর্গত, এবং এর জন্য অথেনটিকেশন প্রয়োজন কিনা। এই তথ্যগুলো শুধু ডকুমেন্টেশন থেকে নয়, বরং সোর্স কোড এবং আপনার এপিআই স্পেসিফিকেশন (OpenAPI, Swagger) উভয় জায়গা থেকেই সংগ্রহ করুন, কারণ এই দুটির মধ্যকার ফাঁকেই বিস্মৃত এবং অনাথ এন্ডপয়েন্টগুলো লুকিয়ে থাকে।

জাইজেনি কোথায় খাপ খায়: জাইজেনি এপিআই নিরাপত্তা এটি আপনার অ্যাপ্লিকেশন সোর্স কোড এবং এপিআই স্পেকস থেকে সরাসরি এই ইনভেন্টরি তৈরি করে, এবং প্রোডাকশনে পৌঁছানোর আগেই আপনার টিম দ্বারা ডকুমেন্ট করা এন্ডপয়েন্টগুলো ও যেগুলো কেউ করেনি, সেগুলোকে সামনে নিয়ে আসে।

২. অবজেক্ট এবং ফাংশন স্তরে অনুমোদন প্রয়োগ করুন

ত্রুটিপূর্ণ অবজেক্ট-লেভেল এবং ফাংশন-লেভেল অথরাইজেশন ধারাবাহিকভাবে OWASP API Security Top 10 তালিকার শীর্ষে থাকে। সর্বোত্তম অনুশীলনটি "অথেনটিকেশন যোগ করা" নয়, বরং প্রতিটি অনুরোধে যাচাই করা যে... এই নির্দিষ্ট ব্যবহারকারী প্রবেশের অনুমতি আছে এই নির্দিষ্ট বস্তুশুধু তারা আদৌ লগ ইন করেছে কি না, তা-ই নয়। অথেনটিকেশন বা প্রমাণীকরণ জানায় একজন ব্যক্তি কে। অথরাইজেশন বা অনুমোদন জানায় যে, তারা কী স্পর্শ করার অনুমতিপ্রাপ্ত, এবং এটি একটি বৈধ টোকেন থেকে অনুমান না করে, প্রতিবারই যাচাই করা প্রয়োজন।

৩. এপিআই যা কিছু গ্রহণ করে, তা যাচাই ও পরিমার্জন করুন।

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

৪. নকশা অনুযায়ীই রেট-লিমিট ও থ্রটল ব্যবহার করুন, পরবর্তীকালে নয়।

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

৫. প্রতিটি প্রতিক্রিয়াকে তথ্য ফাঁসের একটি সম্ভাব্য উৎস হিসেবে বিবেচনা করুন।

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

জাইজেনি কোথায় খাপ খায়: Xygeni API Security সরাসরি API রেসপন্সেই ব্যক্তিগত শনাক্তকরণ তথ্যের (PII) প্রকাশে সতর্কবার্তা পাঠায়, যার ফলে কোনো গ্রাহক বা নিয়ন্ত্রক সংস্থার নজরে আসার আগেই অতিরিক্ত তথ্য শেয়ার করার বিষয়টি ধরা পড়ে।

৬. বাতিল হয়ে যাওয়া এপিআইগুলো সহ একটি নির্ভুল ও হালনাগাদ এপিআই তালিকা রাখুন।

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

৭. আপনার এপিআই তৃতীয় পক্ষের কাছ থেকে কী বিশ্বাস করে তা পুঙ্খানুপুঙ্খভাবে যাচাই করুন।

থার্ড-পার্টি এপিআই-এর অনিরাপদ ব্যবহার একটি অবমূল্যায়িত ঝুঁকি। ডেভেলপাররা ব্যবহারকারীর ইনপুটের চেয়ে অন্য এপিআই থেকে আসা ডেটার ওপর বেশি আস্থা রাখেন, যা আসলে ঠিক উল্টো; একটি থার্ড-পার্টি ইন্টিগ্রেশনও একটি বাহ্যিক, যাচাইবিহীন উৎস এবং সেটিকেও একইভাবে যাচাই করা উচিত।

৮. ডেভেলপারদের সামনে শুধু সতর্কতা নয়, প্রমাণও তুলে ধরুন।

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

জাইজেনি কোথায় খাপ খায়: Xygeni API Security-এর প্রতিটি ফাইন্ডিং সুনির্দিষ্ট হ্যান্ডলার, ফাইল, ক্লাস, মেথড এবং যে লাইন থেকে এটি এসেছে, তা নির্দেশ করে, তাই ফাইন্ডিংটি যুক্ত হওয়ার মুহূর্ত থেকেই সমাধান শুরু হয়।

৯. মোতায়েনের আগে পরিচিতি খুঁজুন, পরে নয়।

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

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

১০. এপিআই (API) ঝুঁকিকে আপনার অ্যাপ্লিকেশনের অন্যান্য ঝুঁকির সাথে একই স্থানে রাখুন।

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

জাইজেনি কোথায় খাপ খায়: এপিআই নিরাপত্তা পাশাপাশি অবস্থান করে SAST, SCAগোপনীয়তা, IaCএবং DAST একটি একক Xygeni প্ল্যাটফর্মে রয়েছে, তাই একটি API ফাইন্ডিং যে কোড এবং ডিপেন্ডেন্সি রিস্ক থেকে তৈরি হয়েছে, তার পাশেই দৃশ্যমান হয়, আলাদাভাবে নয়। login.

চেকলিস্টকে অভ্যাসে পরিণত করা

এপিআই নিরাপত্তার সর্বোত্তম অনুশীলনগুলো কেবল একটি ধারাবাহিক চর্চা হিসেবেই কার্যকর, লঞ্চ-পূর্ববর্তী পর্যালোচনা হিসেবে নয়। প্রতিটির উপর ইনভেন্টরি এবং স্ট্যাটিক অ্যানালাইসিস চালান। pull requestত্রৈমাসিকে একবার নয়। একটি নতুন, ডকুমেন্টেশনবিহীন এন্ডপয়েন্টকে ঠিক সেভাবেই বিবেচনা করুন, যেভাবে আপনি একটি নতুন, ডকুমেন্টেশনবিহীন ডিপেন্ডেন্সিকে বিবেচনা করেন: এটিকে এমন কিছু হিসেবে দেখুন যা অবিলম্বে তদন্ত করা প্রয়োজন, পরে নয়। এবং আপনার এপিআই সুরক্ষার সেরা অনুশীলনগুলোকে ঠিক সেভাবেই পরিমাপ করুন, যেভাবে আপনি আপনার সিস্টেমের অন্য যেকোনো অংশ পরিমাপ করেন। SDLCসমস্যাটি আদৌ ধরতে পেরেছেন কি না, শুধু তা নয়, বরং আপনি কত তাড়াতাড়ি সমস্যাটি ধরতে পেরেছেন, তার ওপরও এটি নির্ভর করে।

দ্রুত উত্তর: এপিআই নিরাপত্তা সেরা অনুশীলন প্রশ্নোত্তর

প্রশ্নউত্তর
এপিআই নিরাপত্তার সবচেয়ে গুরুত্বপূর্ণ সেরা অনুশীলন কোনটি?শক্তিশালী প্রমাণীকরণ এবং অনুমোদন, যা প্রতিটি এন্ডপয়েন্টে প্রয়োগ করা হয়, শুধু সেইগুলোতে নয় যেগুলো আপনি সুরক্ষিত করতে মনে রেখেছেন।
অভ্যন্তরীণ এপিআইগুলোতে কি HTTPS ব্যবহার করা উচিত?হ্যাঁ। শুধু পাবলিক-ফেসিং এন্ডপয়েন্টগুলোই নয়, সার্ভিস-টু-সার্ভিস যোগাযোগ সহ সমস্ত এপিআই ট্র্যাফিক এনক্রিপ্ট করুন।
নিরাপত্তার জন্য এপিআই কী কি যথেষ্ট?না। এপিআই কী একটি অ্যাপ্লিকেশনকে শনাক্ত করে, কোনো ব্যবহারকারীকে নয়। প্রকৃত প্রমাণীকরণের জন্য এগুলিকে OAuth 2.0 বা JWT-এর সাথে যুক্ত করুন।
বোলা কী?ব্রোকেন অবজেক্ট লেভেল অথরাইজেশন: একটি এপিআই কোনো নির্দিষ্ট রিসোর্স অ্যাক্সেস করার জন্য ব্যবহারকারীর অনুমতি আছে কিনা তা যাচাই করতে ব্যর্থ হয়। এটি ২০১৯ সাল থেকে OWASP API Security Top 10-এর তালিকায় প্রথম স্থান ধরে রেখেছে।
আমার কত ঘন ঘন API কী পরিবর্তন করা উচিত?নিয়মিতভাবে, প্রতি ৬০ থেকে ৯০ দিন অন্তর, এবং কোনো সন্দেহজনক সংক্রমণের পর অবিলম্বে।
রেট লিমিটিং-এর জন্য কোন স্ট্যাটাস কোড ফেরত আসা উচিত?429 Too Many Requests, যেখানে একটি Retry-After হেডার ক্লায়েন্টকে জানিয়ে দেয় কখন আবার চেষ্টা করতে হবে।
গেটওয়ের পেছনে থাকলেও কি সার্ভারে ইনপুট যাচাই করা উচিত?সর্বদা। আপস্ট্রিম ক্লায়েন্ট বা গেটওয়ে আগে কী যাচাই করেছে তা নির্বিশেষে এপিআই স্তরে যাচাই করুন।
আমি কীভাবে এপিআই নিরাপত্তা পরীক্ষা করতে পারি CI/CD?প্রতিটিতে প্রমাণীকরণ, অনুমোদন, ইনপুট যাচাইকরণ এবং রেট লিমিটিং পরীক্ষা করুন। pull requestশুধু রিলিজের আগেই নয়, বরং ম্যানুয়াল পর্যালোচনার উপর নির্ভর না করে এটিকে স্বয়ংক্রিয় করুন।

কী Takeaways

  • প্রতিরক্ষার আগে মজুদ আসে। যে এন্ডপয়েন্টের অস্তিত্ব সম্পর্কে আপনি জানেন না, সেটিতে আপনি অনুমোদন, রেট লিমিট বা ডেটা নিয়ন্ত্রণ প্রয়োগ করতে পারবেন না, এবং অনুপযুক্ত ইনভেন্টরি ব্যবস্থাপনা OWASP API Security Top 10-এ একটি স্বতন্ত্র ঝুঁকি হিসেবে চিহ্নিত।
  • শুধু প্রমাণীকরণ নয়, অনুমোদন প্রক্রিয়ায়ই বেশিরভাগ নিরাপত্তা লঙ্ঘন ঘটে থাকে। OWASP API নিরাপত্তার শীর্ষ পাঁচটি ঝুঁকির মধ্যে তিনটিই হলো অনুমোদন ব্যর্থতা। কেউ কে, তা যাচাই করা আর সে কী স্পর্শ করার অনুমতি রাখে, তা যাচাই করা এক জিনিস নয়।
  • স্ট্যাটিক অ্যানালাইসিস এমন কিছু ধরে ফেলে, যা রানটাইম টেস্টিং অনেক দেরিতে ধরতে পারে। একটিতে পরিচিতি খোঁজা pull request খরচ এক commitউৎপাদনে এটি খুঁজে পাওয়ার ফলে একটি ঘটনা ঘটে।
  • প্রতিটি প্রতিক্রিয়াই তথ্য ফাঁসের একটি সম্ভাব্য কারণ। অতিরিক্ত ডেটা প্রকাশ করা একটি অভ্যাস, কোনো বিরল ভুল নয়, এবং রেন্ডার করা UI-এর পরিবর্তে কেউ সরাসরি API-এর প্রতিক্রিয়া পরীক্ষা না করা পর্যন্ত এটি অদৃশ্য থাকে।
  • এপিআই নিরাপত্তার সর্বোত্তম অনুশীলনগুলো কেবল একটি ধারাবাহিক অভ্যাস হিসেবেই কার্যকর হয়।প্রতিটিতে চলে pull requestএটি কোনো ত্রৈমাসিক পর্যালোচনা বা লঞ্চ-পূর্ববর্তী চেকলিস্ট নয়।
  • এপিআই ঝুঁকি কোনো আলাদা টুলে থাকা উচিত নয়। সবচেয়ে কার্যকর এপিআই সুরক্ষা সেরা অনুশীলনগুলো এপিআই থেকে প্রাপ্ত ফলাফলকে কোড, নির্ভরতা এবং অন্যান্য ঝুঁকির চিত্রের অংশ হিসেবে বিবেচনা করে। pipeline securityএকটি বিচ্ছিন্ন কনসোল নয়।

FAQ

শুরু করার জন্য সবচেয়ে গুরুত্বপূর্ণ এপিআই নিরাপত্তা বিষয়ক সেরা অনুশীলনগুলো কী কী?

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

এপিআই নিরাপত্তার সর্বোত্তম অনুশীলন এবং সাধারণ অ্যাপ্লিকেশন নিরাপত্তার সর্বোত্তম অনুশীলনের মধ্যে পার্থক্য কী?

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

এপিআই নিরাপত্তা পরীক্ষা কি ডেপ্লয়মেন্টের আগে নাকি পরে করা উচিত?

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

একটি এপিআই ইনভেন্টরি কত ঘন ঘন আপডেট করা উচিত?

ক্রমাগত, আদর্শগতভাবে প্রতিবার pull requestএকবার তৈরি করা এবং ত্রৈমাসিকভাবে পর্যালোচনা করা একটি ইনভেন্টরি, নতুন কোনো এন্ডপয়েন্ট বাজারে আসার মুহূর্তেই পুরোনো হয়ে যায়, আর ত্রুটিপূর্ণ ইনভেন্টরি ব্যবস্থাপনার মূল ফাঁকটিই হলো এটি।

এপিআই ব্যবস্থাপনার সর্বোত্তম অনুশীলনগুলো কি শুধু সর্বজনীন এপিআইগুলোর ক্ষেত্রেই নয়, বরং অভ্যন্তরীণ এপিআইগুলোর ক্ষেত্রেও প্রযোজ্য?

হ্যাঁ। অভ্যন্তরীণ এপিআইগুলোকে প্রায়শই কম নিরাপত্তা দেওয়া হয়, কারণ সেগুলো “ইন্টারনেটে উন্মুক্ত থাকে না”, কিন্তু তা সত্ত্বেও এগুলোর মাধ্যমে সংবেদনশীল ডেটা আদান-প্রদান করা হয় এবং অভ্যন্তরীণ নেটওয়ার্কে অ্যাক্সেস আছে এমন যে কেউ, এমনকি হ্যাক হওয়া অ্যাকাউন্ট বা ভেতরের কোনো ব্যক্তিও, সেগুলোতে প্রবেশ করতে পারে।

sca-tools-software-composition-analysis-tools
আপনার সফটওয়্যারের ঝুঁকিগুলোকে অগ্রাধিকার দিন, প্রতিকার করুন এবং সুরক্ষিত করুন।
আপনার বিনামূল্যে অ্যাকাউন্টটি নিন।
কোন ক্রেডিট কার্ড প্রয়োজন নেই

আপনার সফটওয়্যার উন্নয়ন ও বিতরণ সুরক্ষিত করুন

Xygeni প্রোডাক্ট স্যুটের সাথে