LiteLLM gateway সুরক্ষায় API key যথেষ্ট নয়—deployment audit-এর ৭ ধাপ
Production LiteLLM Gateway নিরাপদ করার সরাসরি উপায় হলো একটি API key-কে সম্পূর্ণ নিরাপত্তাব্যবস্থা না ধরে সাতটি আলাদা control যাচাই করা: internet exposure, patched version, admin authentication, virtual-key scope, secret storage, network isolation এবং compromise-পরবর্তী rotation। প্রতিটি control-এর configuration-এর পাশাপাশি এমন observable evidence রাখতে হবে, যা দিয়ে auditor বাস্তব অবস্থা যাচাই করতে পারেন।
এই বিভাজন জরুরি, কারণ Gateway একই control plane-এ provider credential, routing policy ও প্রশাসনিক ক্ষমতা কেন্দ্রীভূত করতে পারে। LiteLLM-এর অফিসিয়াল পরিচিতি Gateway-কে authentication, authorization, virtual key ও admin dashboard-সহ centralized service হিসেবে বর্ণনা করে; তাই একটি valid key থাকলেই deployment-এর অন্য trust boundary নিরাপদ হয় না।
পরিবর্তনের আগে read-only snapshot নিন
Audit শুরুতেই production configuration বদলাবেন না। আগে running image, package version, listener, ingress, service account, secret reference এবং authentication response-এর timestamped snapshot নিন। Kubernetes-এ kubectl get deploy,svc,ingress -n NAMESPACE -o yaml, kubectl get pods -n NAMESPACE -o wide ও kubectl describe pod POD -n NAMESPACE দিয়ে deployment metadata দেখা যায়; Docker host-এ সমতুল্য তথ্যের জন্য docker inspect CONTAINER ব্যবহার করুন।
Output সংগ্রহের সময় secret value যেন audit log বা ticket-এ না আসে। লক্ষ্য হলো secret কোথা থেকে inject হচ্ছে, কোন identity workload চালাচ্ছে এবং কোন port প্রকাশিত—credential-এর আসল মান দেখা নয়। Snapshot-এ image tag-এর সঙ্গে immutable digest রাখুন; শুধু latest বা stable tag পরে একই artifact শনাক্ত করার নির্ভরযোগ্য প্রমাণ নয়।
- বাইরে থেকে পৌঁছানো যায় এমন API, UI ও management route তালিকাভুক্ত করুন।
- চলমান LiteLLM version ও image digest অনুমোদিত patched baseline-এর সঙ্গে মেলান।
- API ও Admin UI উভয়ের authentication এবং role separation যাচাই করুন।
- প্রতিটি workload-এর virtual key scope, owner, মেয়াদ ও সীমা পরীক্ষা করুন।
- Master key, provider key ও database credential কোথায় সংরক্ষিত তা যাচাই করুন।
- Ingress, management access, database path ও outbound traffic-এর network boundary পরীক্ষা করুন।
- Detection evidence সংগ্রহ করে compromise-পরবর্তী rotation drill চালান।
ধাপ ১–২: exposure ও patched version যাচাই
প্রথমে অনুমোদিত corporate network-এর বাইরে থেকে DNS resolution এবং TCP reachability পরীক্ষা করুন। ss -lntp বা cluster service manifest দিয়ে listener দেখুন; এরপর আলাদা external test point থেকে কেবল অনুমোদিত hostname ও port পরীক্ষা করুন। API public রাখা ব্যবসায়িক প্রয়োজন হতে পারে, কিন্তু Admin UI, raw service port, database এবং debugging বা management route সরাসরি internet-facing না রাখাই নিরাপদ baseline।
দ্বিতীয় ধাপে runtime-এর version output, installed package metadata এবং container digest মিলিয়ে software inventory তৈরি করুন। শুধু registry tag দেখে সিদ্ধান্ত নেবেন না। LiteLLM-এর GHSA-v4p8-mg3p-g94g advisory অনুযায়ী MCP stdio test endpoint-এর authenticated command-execution ত্রুটিতে 1.74.2 থেকে 1.83.7-এর আগের সংস্করণ আক্রান্ত এবং 1.83.7-এ সংশোধন এসেছে। এটি একটি নির্দিষ্ট vulnerability-এর minimum fix, সামগ্রিকভাবে নিরাপদ version-এর ঘোষণা নয়; approved baseline তৈরির সময় বর্তমান release এবং সব প্রযোজ্য advisory বিবেচনা করুন।
Running artifact শনাক্ত করা না গেলে, mutable tag ব্যবহৃত হলে, known-vulnerable range পাওয়া গেলে বা rollback image-এ একই দুর্বল build থাকলে version audit ব্যর্থ ধরুন। জরুরি upgrade সম্ভব না হলে advisory-তে চিহ্নিত endpoint reverse proxy-তে block করা সাময়িক compensating control; এটি patch-এর বিকল্প নয়।
ধাপ ৩–৪: admin authentication ও virtual-key scope
Admin UI এবং management API-তে সাধারণ application key দিয়ে প্রবেশ করা যায় কি না আলাদাভাবে পরীক্ষা করুন। একটি non-admin test identity দিয়ে model request সফল হলেও key creation, user management, configuration change এবং privileged MCP operation প্রত্যাখ্যাত হওয়া উচিত। Admin identity-কে নির্ধারিত management network ও প্রতিষ্ঠানের শক্তিশালী authentication ব্যবস্থার মধ্যে সীমিত রাখুন; UI সুরক্ষিত হলেও API route অরক্ষিত থাকলে audit সম্পূর্ণ নয়।
Production application-কে master key না দিয়ে team বা service অনুযায়ী virtual key দিন। অনুমোদিত model ও route-এর পাশাপাশি budget, rate limit, owner এবং expiry নির্ধারণ করুন। Negative test-এ key-টি অনুমোদিত model ব্যবহার করতে পারবে, কিন্তু অন্য model ও management operation সম্পন্ন করতে পারবে না; নির্দিষ্ট status code-এর বদলে server-side rejection ও সংশ্লিষ্ট log-কে evidence ধরুন।
Admin-owned key-এর scope বিশেষভাবে পর্যালোচনা করুন, কারণ owner role ও route permission মিলিয়ে কার্যকর অধিকার প্রত্যাশার চেয়ে বড় হতে পারে। সংলগ্ন management surface মূল্যায়নের সময় MCP deployment audit-এর control ব্যবহার করা যায়, তবে LiteLLM-এর route ও role আলাদাভাবে যাচাই করতে হবে।
ধাপ ৫–৬: secret storage ও network isolation
Configuration repository, container image layer, Helm values, CI output এবং plain Kubernetes manifest-এ master key, provider API key বা database connection string আছে কি না পরীক্ষা করুন। Secret manager বা orchestration secret reference ব্যবহার করলেও workload কোন identity দিয়ে value পড়ছে, কে নতুন version লিখতে পারে এবং access audit log পাওয়া যায় কি না যাচাই করুন। Secret command-line argument বা verbose log-এ গেলে managed vault-এ রাখাও যথেষ্ট সুরক্ষা দেয় না।
Environment variable দিয়ে secret inject করলে runtime compromise-এর সম্ভাব্য blast radius নথিভুক্ত করুন। পরিবেশের সামর্থ্য অনুযায়ী short-lived credential, workload identity বা mounted secret mechanism বেছে নিন এবং Gateway process-কে dedicated non-root identity, read-only filesystem ও অপ্রয়োজনীয় tool ছাড়া চালান। Audit evidence হিসেবে secret reference, access policy, service identity এবং last-rotation metadata রাখুন—secret নিজে নয়।
Network isolation-এ চারটি path আলাদাভাবে পরীক্ষা করুন: client থেকে API ingress, administrator থেকে management surface, Gateway থেকে database এবং Gateway থেকে model provider। Default-deny policy থেকে কেবল প্রয়োজনীয় source, destination, port ও DNS path অনুমোদন করুন। Database private network-এ সীমাবদ্ধ রাখুন; outbound destination নিয়ন্ত্রণ ও log করলে অপ্রত্যাশিত callback বা exfiltration দ্রুত শনাক্ত করা যায়।
ধাপ ৭: detection evidence ও post-compromise rotation
শেষ ধাপে শুধু log চালু আছে কি না নয়, Gateway-এর স্বাভাবিক কাজের সঙ্গে অসামঞ্জস্যপূর্ণ আচরণ শনাক্ত হচ্ছে কি না পরীক্ষা করুন। Microsoft Security Research-এর LiteLLM compromise বিশ্লেষণে Gateway context থেকে shell ও Python execution, process environment ও database-backed record থেকে credential সংগ্রহ, PostgreSQL access, outbound callback এবং persistence activity দেখা গেছে। তাই Gateway process-এর child shell, /proc/1/environ access, অস্বাভাবিক database query, temporary directory থেকে executable, raw-IP egress এবং cron বা SSH configuration পরিবর্তন high-priority indicator হওয়া উচিত।
Rotation runbook-এ containment, clean recovery environment এবং credential dependency স্পষ্ট করুন। সম্ভাব্য host compromise হলে নতুন secret একই সন্দেহভাজন runtime-এ inject করবেন না। Clean artifact চালু করার পর dependency অনুযায়ী provider key, database credential, LiteLLM master key ও virtual key বদলান; identity-provider client secret বা signing material আক্রান্ত runtime থেকে accessible থাকলে সেগুলোকেও exposure scope-এ রাখুন।
Drill-এর pass condition হবে: নতুন credential দিয়ে অনুমোদিত request সফল, পুরোনো credential প্রত্যাখ্যাত, revoked virtual key দিয়ে model বা management operation ব্যর্থ এবং rotation ও rejection উভয় ঘটনাই log-এ দৃশ্যমান। শুধু secret manager-এ নতুন version তৈরি হওয়া rotation সম্পন্ন হওয়ার প্রমাণ নয়; workload পুরোনো value cache করছে কি না এবং rollback manifest পুরোনো secret ফিরিয়ে আনতে পারে কি না পরীক্ষা করুন।
Production approval-এর ন্যূনতম gate
Deployment অনুমোদন দিন তখনই, যখন inventory-তে immutable artifact আছে, applicable vulnerability baseline পূরণ হয়েছে, public route সীমিত, Admin UI ও management API পৃথকভাবে authenticated, application traffic scoped virtual key ব্যবহার করছে, secret repository বা runtime log-এ প্রকাশিত নয়, database private এবং outbound path নিয়ন্ত্রিত। এর সঙ্গে negative authorization test, detection alert এবং পুরোনো credential প্রত্যাখ্যানের evidence সংযুক্ত রাখুন।
কোনো control অনুপস্থিত থাকলে ঝুঁকিটি owner, expiry এবং compensating control-সহ লিখিতভাবে নথিভুক্ত করুন। বিশেষ করে অপ্রয়োজনীয় internet exposure, vulnerable build বা application-এ master key ব্যবহার production blocker হিসেবে ধরা যুক্তিযুক্ত, কারণ এগুলো Gateway compromise-এর প্রভাব downstream provider credential ও database পর্যন্ত বাড়াতে পারে।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।