মানুষকে ঠিক সেই অ্যাক্সেসটুকুই দিন যা তাদের প্রয়োজন — আর কিছুই নয়

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

Developer ভূমিকায় সাইট মুছে ফেলা বা সাইট স্থগিত করার অনুমতি থাকে না — এই চাবিগুলি Owner ভূমিকার অন্তর্গত। এটি সাইট দেখা ও তৈরি করা, পরিষেবা রিস্টার্ট করা, ক্যাশ মুছে ফেলা, API কী পরিচালনা করা এবং টিকিটের কাজ করার অনুমতি প্রদান করে। ডিপ্লয়মেন্ট এবং push-to-live অনুমতিগুলিও Developer অনুদানের অংশ নয়, তাই প্রোডাকশনে স্থানান্তর অ্যাকাউন্টের মালিকের কাছেই থাকে। এটি স্টেজিংয়ের সাথে যুক্ত করুন যাতে বিল্ড সংক্রান্ত কাজ প্রথম থেকেই লাইভ সাইটের বাইরে সম্পন্ন হয়।

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

সদস্যপদ সরিয়ে দিন এবং সেই সংস্থায় তাদের অ্যাক্সেস শেষ হয়ে যাবে — তাদের এখনও নিজস্ব পরিচয় থাকবে, কিন্তু আপনার অ্যাকাউন্টে কোনও ভূমিকা এবং ফলস্বরূপ কোনও অনুমতি থাকবে না। API কীগুলি আলাদাভাবে বাতিল করা হয়, তাই অন্য কিছু বিঘ্নিত না করেই একটি pipeline কী বন্ধ করা যেতে পারে। আপনি যদি SAML single sign-on ব্যবহার করেন, তবে আপনার পরিচয় প্রদানকারীতে deprovisioning সাইন-ইন কেন্দ্রীয়ভাবে পরিচালনা করে। সাইট-স্তরের প্রমাণপত্র যেমন SSH কীগুলি ড্যাশবোর্ডে বাতিল করা হয়, এবং অপসারণটি নিজেই অডিট-লগ করা হয়।

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

হ্যাঁ। আমাদের MCP সার্ভার OAuth 2.1-এর মাধ্যমে এজেন্টদের প্রমাণীকরণ করে এবং আপনার সংস্থা ও আপনার RBAC ভূমিকার মধ্যে সীমাবদ্ধ করে, যেখানে প্রতিটি টুলের জন্য প্রত্যাহারযোগ্য টোকেন থাকে, যাতে আপনি সার্বিক অ্যাক্সেসের পরিবর্তে একটি নির্দিষ্ট সক্ষমতা প্রদান করতে পারেন। ধ্বংসাত্মক পদক্ষেপের জন্য নিশ্চিতকরণ প্রয়োজন, ব্যয়ের সীমা প্রযোজ্য হয় এবং প্রতিটি পদক্ষেপ মানুষের কার্যকলাপের মতো একই অডিট লগে যুক্ত হয়।

Postgres রো-লেভেল সিকিউরিটি ডাটাবেজের মধ্যেই কলারের প্রতিষ্ঠানের সাবট্রিতে কোয়েরির পরিধি সীমাবদ্ধ করে, যেখানে অ্যাপ্লিকেশন-লেভেলের ফিল্টার একমাত্র মাধ্যম না হয়ে প্রতিরক্ষা হিসেবে কাজ করে। পরিধির বাইরের রেকর্ডের অনুরোধগুলোতে অনুমতির ত্রুটির পরিবর্তে ‘নট-ফাউন্ড’ দেখায়, যাতে কী বিদ্যমান রয়েছে সে সম্পর্কে কিছুই প্রকাশ না পায়। সার্ভারের দিকে, CageFS-এর মাধ্যমে প্রতিটি সাইটের পৃথকীকরণ প্রতিটি গ্রাহকের শেল এবং ফাইলগুলোকে তাদের নিজস্ব সাইটেই সীমাবদ্ধ রাখে।

হ্যাঁ। ১৪ দিনের ট্রায়ালটির জন্য কার্ডের প্রয়োজন নেই — কোনও অর্থপ্রদানের বিবরণ নেই, কোনও বাধ্যবাধকতা নেই — এবং এটি পাঁচটি পর্যন্ত সাইট সহ Footprint-Free হোস্টিং কভার করে। প্রতিশ্রুতিবদ্ধ হওয়ার আগে কোনও সহকর্মীকে আমন্ত্রণ জানাতে, একটি ভূমিকা নির্ধারণ করতে এবং সীমানাগুলি আপনার প্রয়োজন অনুসারে কাজ করে কিনা তা নিশ্চিত করার জন্য এটি যথেষ্ট।