অ্যাক্সেস কন্ট্রোল, আইডেন্টিটি এবং সিক্রেট ম্যানেজমেন্ট

লাভ:

• প্রমাণীকরণ এবং অনুমোদন পৃথক করার ক্ষমতা এবং RBAC/ABAC এর সাথে ন্যূনতম অনুমোদন প্রয়োগ করার ক্ষমতা
• ব্যবহারকারী প্রসঙ্গে মডেলটি চালানোর মাধ্যমে মিশ্র প্রক্সি ঝুঁকি এড়ানোর ক্ষমতা
• গোপন ব্যবস্থাপনা সিস্টেমের সাথে API কীগুলি সংরক্ষণ এবং ঘোরানোর ক্ষমতা

একটি AI সিস্টেমে আক্রমণের একটি উল্লেখযোগ্য অংশ মডেলটিকে "প্রতারণা" দিয়ে নয়, একটি চুরি করা API কী বা অতিরিক্ত অনুমোদিত অ্যাকাউন্ট দিয়ে শুরু হয়। নিরাপত্তার এই স্তরটি ধ্রুপদী তথ্য নিরাপত্তা থেকে আসে, কিন্তু AI এর প্রেক্ষাপটে নতুন ঝুঁকি যোগ করে: একটি মডেল অন্য কারও পক্ষে একটি রাইড কল করে, একটি পরিষেবা অ্যাকাউন্ট সমস্ত ডেটা অ্যাক্সেস করে, GitHub-এ একটি কী ফাঁস হয়। এই ইউনিটে, আমরা শিখব কিভাবে প্রমাণীকরণ, অনুমোদন (RBAC/ABAC), ন্যূনতম অনুমোদন এবং গোপন ব্যবস্থাপনা সহ AI সিস্টেমে অ্যাক্সেস সংকুচিত করা যায়।

প্রমাণীকরণ এবং অনুমোদনের মধ্যে পার্থক্য

দুটি পদ প্রায়ই বিভ্রান্ত হয়:

• প্রমাণীকরণ: "আপনি কে?" — প্রমাণ করে যে ব্যবহারকারী/পরিষেবা আসলেই তারা যাকে দাবি করে (পাসওয়ার্ড, টোকেন, সার্টিফিকেট, MFA)।
• অনুমোদন: "আপনি কি করতে পারেন?" — প্রমাণীকৃত পক্ষ কোন সংস্থান/ক্রিয়া অ্যাক্সেস করতে পারে তা নির্ধারণ করুন।

এআই সিস্টেমের সমালোচনামূলক সূক্ষ্মতা হল: যখন মডেলটি একজন ব্যবহারকারীর পক্ষে কাজ করে, তখন এটি কি সেই ব্যবহারকারীর কর্তৃত্বের সাথে বা একটি বিস্তৃত পরিষেবা অ্যাকাউন্টের সাথে কাজ করে? পরবর্তীটি বিপজ্জনক — কারণ ইনজেকশন দ্বারা প্রতারিত মডেলটি পরিষেবা অ্যাকাউন্টে সম্পূর্ণ অ্যাক্সেস লাভ করে।

সতর্কতা: "বিভ্রান্ত ডেপুটি" সমস্যা: একজন নিম্ন-কর্তৃপক্ষ ব্যবহারকারী পরোক্ষভাবে ডেটা অ্যাক্সেস করে যা সে উচ্চ-অথরিটি মডেল আউটসোর্সিং করে অ্যাক্সেস করতে পারে না। মডেলটি সর্বদা ব্যবহারকারীর কর্তৃত্বের প্রেক্ষাপটে কাজ করা উচিত, তার নিজস্ব বিস্তৃত কর্তৃপক্ষের নয়।

RBAC এবং ABAC

• RBAC (ভুমিকা-ভিত্তিক অ্যাক্সেস কন্ট্রোল): অ্যাক্সেস ব্যবহারকারীর ভূমিকার উপর নির্ভর করে। "সহায়তা বিশেষজ্ঞ" ভূমিকা গ্রাহকের নোট পড়তে পারে, কিন্তু মুছে ফেলতে পারে না। সহজ এবং সাধারণ।
• ABAC (অ্যাট্রিবিউট-ভিত্তিক অ্যাক্সেস কন্ট্রোল): অ্যাক্সেস বৈশিষ্ট্যগুলির উপর নির্ভর করে: ব্যবহারকারীর বিভাগ, ডেটার গোপনীয়তা লেবেল, দিনের সময়, যে নেটওয়ার্ক থেকে অনুরোধ আসে। আরো সূক্ষ্ম সুর কিন্তু আরো জটিল.

বেশিরভাগ সংস্থাই RBAC দিয়ে শুরু করে এবং সংবেদনশীল ডেটার জন্য ABAC পর্যন্ত গভীর হয়। AI-এর জন্য থাম্বের নিয়ম: মডেলের উচিত প্রতিটি এজেন্টকে ফিল্টার করা এবং অনুরোধ করা ব্যবহারকারীর ভূমিকা/ বৈশিষ্ট্যের উপর ভিত্তি করে এটি অ্যাক্সেস করা প্রতিটি ডেটা।

ধাপে ধাপে: ন্যূনতম কর্তৃত্ব অনুশীলন করা

1. ইনভেন্টরি নিন। মডেলটি কোন সরঞ্জামগুলিকে কল করে, এটি কোন ডেটা অ্যাক্সেস করে? তাদের সব তালিকা.
2. প্রতিটি অ্যাক্সেস ন্যায্যতা. "এই সহকারীর কি সত্যিই মুছে ফেলার কর্তৃপক্ষের প্রয়োজন আছে?" অন্যথায়, এটি সরান।
3. শুধুমাত্র পঠন ডিফল্ট। মডেলটি ডিফল্টরূপে পড়তে সক্ষম হওয়া উচিত; আলাদা, সংকীর্ণ-স্কোপ টোকেন লিখতে/মুছে দিতে হবে।
4. ব্যবহারকারীর প্রসঙ্গ সরান। পরিষেবা অ্যাকাউন্টের সাথে নয়, ব্যবহারকারীর কর্তৃপক্ষের সাথে গাড়িটিকে কল করুন।
5. স্বল্পস্থায়ী শংসাপত্র। দীর্ঘস্থায়ী কীগুলির পরিবর্তে স্বল্পস্থায়ী, স্বয়ংক্রিয় পুনর্নবীকরণ টোকেনগুলি ব্যবহার করুন৷

গোপন ব্যবস্থাপনা

একটি গোপনীয়তা হল শংসাপত্র যা গোপন থাকতে হবে, যেমন একটি API কী, পাসওয়ার্ড, টোকেন বা শংসাপত্র। AI প্রকল্পে সবচেয়ে সাধারণ দুর্ঘটনা হল যখন মডেল প্রদানকারীর API কী কোডে এম্বেড করা হয় এবং সংস্করণ নিয়ন্ত্রণে (Git) লিক হয়।

সঠিক আবেদন:

• কোডে কখনই কী এম্বেড করবেন না; একটি পরিবেশ পরিবর্তনশীল বা একটি গোপন ব্যবস্থাপনা সিস্টেম ব্যবহার করুন (একটি পরিষেবা যা এনক্রিপ্ট করা কী সংরক্ষণ করে এবং অ্যাক্সেস নিয়ন্ত্রণ করে)।
• ঘূর্ণন: নিয়মিত বিরতিতে কীগুলি পুনর্নবীকরণ করুন (যেমন প্রতি 90 দিনে); যদি লিক সন্দেহ হয়, অবিলম্বে বাতিল করুন.
• সুযোগ হ্রাস: প্রতিটি সুইচ শুধুমাত্র প্রয়োজনীয় পরিষেবা এবং প্রয়োজনীয় অনুমোদন আছে.
• অডিট: কে, কখন, কোথায় কী ব্যবহার করেছে লগ করুন।

চারটি অনুলিপিযোগ্য টেমপ্লেট

অ্যাক্সেস পর্যালোচনা নিয়ন্ত্রণ প্রম্পট:

নীচের টুল তালিকার প্রতিটি টুলের জন্য, মূল্যায়ন করুন:- এই সহকারীর কাজটি সম্পাদন করার জন্য এই টুলটি কি প্রয়োজন? (হ্যাঁ/না) - এটা কি শুধুমাত্র পঠনযোগ্য বা লিখতে/মুছে ফেলার জন্য? - এই টুলটি কি ব্যবহারকারীর অথরিটি বা সার্ভিস অ্যাকাউন্টের সাথে ডাকা হয়? অপ্রয়োজনীয় বা অত্যধিক অনুমোদিতকে "মুছে ফেলুন/রিডাক্ট" হিসাবে চিহ্নিত করুন।<tools>{{ tool_list }}</tools>

গোপন লিক স্ক্যানিং প্রম্পট:

নিম্নলিখিত কোড স্নিপেটে একটি হার্ডকোড করা গোপন হতে পারে এমন কিছু খুঁজুন: API কী, পাসওয়ার্ড, টোকেন, সংযোগ স্ট্রিং, ব্যক্তিগত কী। প্রতিটির জন্য সারি এবং টাইপ দিন। প্রতিক্রিয়াতে মান কপি করুন;মাস্ক (প্রথম 4টি অক্ষর + ***)।<code>{{ উৎস }}</code>

সর্বনিম্ন কর্তৃপক্ষের সিদ্ধান্তের নিয়ম:

যখন একটি নতুন টুল/অ্যাক্সেস অনুরোধ আসে, জিজ্ঞাসা করুন: 1. এই অ্যাক্সেস ছাড়া টাস্ক সঞ্চালিত করা যাবে? -> যদি হ্যাঁ: REJECT2. শুধুমাত্র পঠন যথেষ্ট? -> যদি হ্যাঁ: লিখতে অনুমতি দিন3. সুযোগ কি একটি একক উৎসে সংকুচিত করা যায়? -> যদি হ্যাঁ: darat ডিফল্ট উত্তর "না"; প্রবেশাধিকার কারণ দ্বারা অর্জিত হয়.

ঘূর্ণন ক্যালেন্ডার অনুস্মারক:

প্রতিটি গোপনীয়তার জন্য, রেকর্ড করুন: মালিক, সৃষ্টির তারিখ, মেয়াদ, সুযোগ। 90 দিন অতিক্রম করেছে বা 30 দিনের জন্য "ঘূর্ণন/বাতিল প্রার্থী" হিসাবে ব্যবহার করা হয়নি এমন কোনও কী রিপোর্ট করুন।

দুর্বল প্রম্পট / শক্তিশালী প্রম্পট

দরিদ্র পদ্ধতি

শক্তিশালী পন্থা

মডেল একটি একক পরিষেবা অ্যাকাউন্টের মাধ্যমে সমস্ত ডেটা অ্যাক্সেস করে৷

মডেলটি অনুরোধকারী ব্যবহারকারীর কর্তৃপক্ষের সাথে অ্যাক্সেস করে

API কী কোডে এম্বেড করা আছে, এটি কখনই পরিবর্তন হয় না

কী সিক্রেট ম্যানেজারে আবর্তন, 90 দিন

সহকারীকে ব্রড "যেকোনো কিছু" করার ক্ষমতা

শুধুমাত্র পঠন ডিফল্ট, সংকীর্ণভাবে লিখুন

অ্যাক্সেস কখনও পর্যালোচনা করা হয় না

নিয়মিত অ্যাক্সেস পর্যালোচনা এবং প্রত্যাহার

তিনটি মিনি কেস

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

কেস 2 — লিকড কী, 2 সপ্তাহে 190,000 TL বিল। একজন বিকাশকারী একটি সহায়ক স্ক্রিপ্টে মডেল API কী এম্বেড করে এবং এটিকে একটি সর্বজনীন সংগ্রহস্থলে পুশ করে। একটি বট 40 মিনিটের মধ্যে চাবিটি খুঁজে পেয়েছিল এবং এটি দুই সপ্তাহ ধরে ব্যবহার করেছিল; বিল 190,000 TL পৌঁছেছে। যখন চাবিটি গোপন ব্যবস্থাপকের কাছে সরানো হয়েছিল, ঘূর্ণনের সাথে সংযুক্ত ছিল, এবং সংগ্রহস্থল স্ক্যানিং যোগ করা হয়েছিল, ঘটনাটি পুনরায় ঘটেনি।

কেস 3 — শুধুমাত্র পঠনযোগ্য ডিফল্ট বাধা বাধা। একজন DevOps সহকারী প্রম্পট ইনজেকশনের মাধ্যমে একটি "রিসেট প্রোডাকশন ডাটাবেস" কমান্ড পেয়েছেন। তবে, সহকারীকে শুধুমাত্র পঠনযোগ্য টোকেন দেওয়া হয়েছিল; লিখুন/মুছে ফেলা একটি পৃথক অনুমোদিত প্রবাহে ছিল। আদেশটি অনুমোদন ত্রুটির সাথে প্রত্যাখ্যান করা হয়েছিল এবং ইভেন্টটি একটি অ্যালার্ম হিসাবে লগ করা হয়েছিল; কোন তথ্য ক্ষতি ছিল.

টিপ: একটি নতুন অ্যাক্সেস অনুরোধের জন্য আপনার ডিফল্ট উত্তর "না" করুন। প্রবেশাধিকার ন্যায্যতার মাধ্যমে অর্জিত কিছু; প্রত্যেককে প্রশস্ত দেওয়া এবং তারপরে কেটে ফেলা প্রায় কখনই করা হয় না এবং ঝুঁকি জমে যায়।

সাধারণ ভুল

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

সংক্ষেপে

• প্রমাণীকরণ হল "আপনি কে" এর একটি প্রশ্ন, অনুমোদন হল "আপনি কি করতে পারেন" এর একটি প্রশ্ন; AI-তে, উভয়কেই ব্যবহারকারীর প্রসঙ্গে কাজ করতে হবে।
• মডেলটিকে অনুরোধ করা ব্যবহারকারীর কর্তৃত্বের সাথে কাজ করা উচিত, তার নিজস্ব বিস্তৃত কর্তৃপক্ষের সাথে নয় (মিশ্র সংস্থার ঝুঁকি এড়ানো)।
• RBAC দিয়ে শুরু করুন, সংবেদনশীল ডেটাতে ABAC দিয়ে গভীর করুন; ন্যূনতম কর্তৃত্বকে ডিফল্ট করুন।
• কোডে গোপনীয়তা কবর দেবেন না; এটি গোপন ব্যবস্থাপকের মধ্যে সংরক্ষণ করুন, এটিকে সংকুচিত করুন এবং এটিকে নিয়মিত ঘূর্ণনে রাখুন।
• শুধুমাত্র পঠনযোগ্য ডিফল্ট এবং সংকীর্ণ লেখা ইনজেকশনের প্রভাবকে সীমাবদ্ধ করে।

আবেদন টাস্ক

আপনার AI সহকারী অ্যাক্সেস করে এমন সমস্ত সরঞ্জাম এবং ডেটা তালিকাভুক্ত করুন। প্রতিটির জন্য তিনটি প্রশ্নের উত্তর দাও: (1) এটা কি সত্যিই প্রয়োজনীয়? (2) শুধুমাত্র পঠন যথেষ্ট? (3) এটি কি ব্যবহারকারীর প্রসঙ্গে চলে? তারপরে সমস্ত হার্ড-কোডেড গোপনীয়তা অনুসন্ধান করুন (উপরের স্ক্যান প্রম্পটের মাধ্যমে) এবং আপনি যে প্রতিটি কী খুঁজে পান তার জন্য একটি ঘূর্ণন পরিকল্পনা লিখুন। অন্তত একটি অপ্রয়োজনীয় অনুমোদন সরান.

চেকলিস্ট

• [ ] মডেলটি ব্যবহারকারীর অনুরোধ করার কর্তৃপক্ষের প্রেক্ষাপটে চলে।
• [ ] টুল এবং ডেটা অ্যাক্সেসকে ন্যূনতম বিশেষাধিকারের নীতিতে সংকুচিত করা হয়েছে।
• [] লিখুন/মুছে ফেলা শুধুমাত্র-পঠন, প্রমাণীকৃত এবং সংকীর্ণ থেকে পৃথক।
• [ ] কোন গোপনীয়তা কোডে সমাহিত করা হয় না; এটি গোপন ম্যানেজারে রাখা হয়।
• কীগুলির জন্য একটি ঘূর্ণন সময়সূচী এবং বাতিলকরণ পদ্ধতি রয়েছে।
• [ ] অ্যাক্সেস নিয়মিত পর্যালোচনা করা হয়.