Serverless Security: ক্লাউড ফাংশন এবং সার্ভারলেস আর্কিটেকচারের সম্ভাব্য নিরাপত্তা ঝুঁকি!

সার্ভারলেসে Shared Responsibility Model আরও জটিল আকার ধারণ করে। ক্লাউড প্রোভাইডার দায়িত্বশীল থাকেন কম্পিউট অবকাঠামো, OS, রানটাইম এনভায়রনমেন্ট, এবং স্কেলিং মেকানিজমের জন্য। অপরদিকে গ্রাহক দায়ী থাকেন ফাংশনের কোড, IAM Permissions, ফাংশনের মধ্যে ব্যবহৃত লাইব্রেরির নিরাপত্তা, ইনপুট ভ্যালিডেশন এবং ডেটা সুরক্ষার জন্য।

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

১. Function Event Data Injection

সার্ভারলেস ফাংশন বিভিন্ন উৎস থেকে ইভেন্ট গ্রহণ করতে পারে—API Gateway, S3 Bucket, SQS Queue, DynamoDB Stream, IoT Device ইত্যাদি। প্রতিটি উৎস থেকে আসা ডেটা সম্ভাব্য আক্রমণের ভেক্টর হতে পারে। যদি ফাংশন এই ইনপুটগুলো সঠিকভাবে যাচাই না করে, তবে SQL Injection, NoSQL Injection, Command Injection বা XML External Entity (XXE) আক্রমণের মতো দুর্বলতা সৃষ্টি হতে পারে।

বিশেষ করে, ঐতিহ্যবাহী ওয়েব অ্যাপ্লিকেশনে শুধু HTTP রিকোয়েস্ট পরীক্ষা করলেই চলত, কিন্তু সার্ভারলেসে S3-এ আপলোড হওয়া ফাইলের মেটাডেটা, SNS-এর মাধ্যমে আসা মেসেজ, কিংবা CloudWatch Log Event—সব কিছুই ইনপুট হিসেবে আসতে পারে এবং প্রত্যেকটির জন্য আলাদা ভ্যালিডেশন প্রয়োজন।

২. Broken Authentication

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

৩. Over-privileged Function Permissions

এটি সার্ভারলেস সিকিউরিটির সবচেয়ে সাধারণ এবং গুরুতর সমস্যা। ডেভেলপাররা প্রায়ই দ্রুত উন্নয়নের স্বার্থে ফাংশনকে অত্যন্ত প্রশস্ত IAM Role প্রদান করেন, যেমন AdministratorAccess বা s3:*। এর ফলে যদি একটি ফাংশন কোনোভাবে কম্প্রোমাইজ হয়, আক্রমণকারী পুরো ক্লাউড অ্যাকাউন্টের নিয়ন্ত্রণ নিতে পারেন।

Principle of Least Privilege অনুসরণ করে প্রতিটি ফাংশনের জন্য সুনির্দিষ্ট এবং সীমিত পারমিশন নির্ধারণ করতে হবে। AWS IAM Access Analyzer এবং Azure-এর built-in tools এই কাজে সহায়তা করতে পারে।

৪. Insecure Third-party Dependencies

সার্ভারলেস ফাংশনগুলো প্রায়ই npm, PyPI বা NuGet থেকে নেওয়া তৃতীয় পক্ষের প্যাকেজের উপর নির্ভর করে। এই প্যাকেজগুলোতে যদি দুর্বলতা থাকে, তবে পুরো ফাংশন ঝুঁকির মুখে পড়ে। 2018 সালের event-stream incident এবং ua-parser-js attack এর মতো সাপ্লাই চেইন আক্রমণের ঘটনা প্রমাণ করে এই ঝুঁকির গুরুত্ব।

প্রতিরোধের জন্য Software Composition Analysis (SCA) টুল যেমন Snyk, Dependabot, এবং OWASP Dependency-Check ব্যবহার করা উচিত। প্রতিটি ডিপ্লয়মেন্টের আগে নির্ভরশীলতা স্ক্যান করতে হবে এবং Software Bill of Materials (SBOM) তৈরি করতে হবে।

৫. Insecure Application Secrets Storage

ডেভেলপাররা প্রায়ই API Key, Database Password বা Token-গুলো এনভায়রনমেন্ট ভেরিয়েবলে সরাসরি রাখেন। যদিও এটি কোডে hardcode করার চেয়ে ভালো, তবুও এটি সম্পূর্ণ নিরাপদ নয়। যদি কেউ ফাংশনের কনফিগারেশন পড়তে পারে, তবে সকল সিক্রেট প্রকাশ পেয়ে যাবে।

সমাধান হলো AWS Secrets Manager, Azure Key Vault বা Google Secret Manager-এর মতো নিবেদিত সিক্রেট ম্যানেজমেন্ট সিস্টেম ব্যবহার করা। ফাংশন রানটাইমে এই সিক্রেটগুলো ডাইনামিকভাবে রিট্রিভ করবে এবং প্রয়োজনে রোটেট করা যাবে।

৬. Denial of Service এবং Financial Exhaustion

ঐতিহ্যবাহী DoS আক্রমণে সার্ভার ডাউন হলেও বিল বাড়ে না। কিন্তু সার্ভারলেসে আক্রমণকারী যদি লক্ষ লক্ষ রিকোয়েস্ট পাঠায়, তবে ফাংশন স্বয়ংক্রিয়ভাবে স্কেল হয়ে যায় এবং বিশাল অংকের ক্লাউড বিল তৈরি হয়। একে বলা হয় Denial of Wallet (DoW) আক্রমণ।

প্রতিরোধের জন্য Concurrency Limit, Throttling, API Gateway-তে Rate Limiting এবং Budget Alert কনফিগার করা অপরিহার্য। AWS Lambda-তে Reserved Concurrency এবং Provisioned Concurrency সেটিং দিয়ে এই ঝুঁকি কমানো যায়।

৭. Function Flow Manipulation

সার্ভারলেস অ্যাপ্লিকেশন প্রায়ই একাধিক ফাংশনের চেইন ব্যবহার করে—একটি ফাংশনের আউটপুট অন্যটির ইনপুট হয়। আক্রমণকারী যদি এই ফ্লো ম্যানিপুলেট করতে পারেন (যেমন SQS মেসেজ ইনজেক্ট করে), তবে তারা যৌক্তিক ক্রম এড়িয়ে অননুমোদিত অপারেশন সম্পাদন করতে পারেন।

৮. Inadequate Logging and Monitoring

সার্ভারলেস ফাংশনের স্বল্পস্থায়ী প্রকৃতি লগিং এবং মনিটরিংকে চ্যালেঞ্জিং করে তোলে। যদি যথাযথ Observability না থাকে, তবে আক্রমণ শনাক্ত করা প্রায় অসম্ভব হয়ে পড়ে। CloudWatch, AWS X-Ray, Azure Application Insights-এর মতো টুল ব্যবহার করে centralized logging স্থাপন করতে হবে।

২০২০ সালে Capital One-এর ডেটা ব্রিচের ঘটনায় AWS-এর Server Side Request Forgery (SSRF) দুর্বলতা ব্যবহার করে আক্রমণকারী EC2 ইনস্ট্যান্সের IAM Credentials চুরি করেন। যদিও এটি সম্পূর্ণ সার্ভারলেস নয়, তবে এর মূলনীতি Lambda ফাংশনেও প্রযোজ্য—অতিরিক্ত পারমিশন এবং অনিরাপদ মেটাডেটা অ্যাক্সেস কীভাবে বিপর্যয় ডেকে আনতে পারে।

২০২২ সালে Denonia নামের একটি ম্যালওয়্যার আবিষ্কৃত হয় যা সরাসরি AWS Lambda-কে লক্ষ্য করে ডিজাইন করা হয়েছিল। এটি Go ভাষায় লেখা এবং XMRig ক্রিপ্টোমাইনার ব্যবহার করে cloud function-এ ক্রিপ্টোকারেন্সি মাইন করত। এই ঘটনা প্রমাণ করে যে সার্ভারলেস পরিবেশও ম্যালওয়্যার থেকে মুক্ত নয়।

Secure Coding Practices

প্রতিটি ফাংশনের কোড লেখার সময় Input Validation, Output Encoding, Parameterized Queries এবং Safe Deserialization অনুশীলন করতে হবে। ভাষা-নির্দিষ্ট সিকিউরিটি গাইডলাইন (যেমন OWASP Cheat Sheet) অনুসরণ করতে হবে।

Infrastructure as Code (IaC) Security

Terraform, CloudFormation বা Serverless Framework দিয়ে ডিপ্লয় করার সময় Checkov, tfsec, এবং cfn-lint দিয়ে IaC কোড স্ক্যান করতে হবে যাতে কনফিগারেশনের ভুলগুলো আগেই ধরা যায়।

Runtime Protection

Function as a Service (FaaS)-এর জন্য Runtime Application Self-Protection (RASP) সলিউশন যেমন Palo Alto Prisma Cloud, Aqua Security এবং Sysdig ব্যবহার করা যেতে পারে। এগুলো রিয়েল-টাইমে ম্যালিশিয়াস বিহেভিয়ার শনাক্ত করে।

Network Isolation

সংবেদনশীল ফাংশনগুলোকে VPC-এর মধ্যে রেখে Private Subnet-এ চালাতে হবে। এর ফলে তারা সরাসরি ইন্টারনেটে এক্সপোজড হয় না এবং Lateral Movement প্রতিরোধ করা যায়।

Continuous Security Testing

CI/CD পাইপলাইনে SAST (Static Application Security Testing) এবং DAST (Dynamic Application Security Testing) ইন্টিগ্রেট করতে হবে। প্রতিটি Pull Request-এর সাথে সিকিউরিটি স্ক্যান চালানো বাধ্যতামূলক করতে হবে।

Cold Start Considerations

Cold Start-এর সময় ফাংশন প্রথমবার লোড হয় এবং এই সময় কিছু সিকিউরিটি কনট্রোল সম্পূর্ণরূপে সক্রিয় নাও হতে পারে। তাই Provisioned Concurrency ব্যবহার এবং Critical Security Initialization Logic-এর কর্মক্ষমতা পরীক্ষা করা গুরুত্বপূর্ণ।

Multi-tenancy এবং Data Isolation

একই সার্ভারলেস প্ল্যাটফর্মে একাধিক টেন্যান্ট কাজ করলে ডেটা আইসোলেশন নিশ্চিত করতে হবে। প্রতিটি টেন্যান্টের জন্য পৃথক Encryption Key, পৃথক IAM Role এবং পৃথক Logical Database/Bucket ব্যবহার করা উচিত।

সার্ভারলেস স্থাপত্যের দ্রুত পরিবর্তনশীল প্রকৃতি ঐতিহ্যবাহী সিকিউরিটি রিভিউ মডেলের সাথে খাপ খায় না। তাই DevSecOps অপরিহার্য। ডেভেলপমেন্ট, সিকিউরিটি এবং অপারেশনস টিম একসাথে কাজ করবে এবং সিকিউরিটি হবে প্রতিটি ধাপের অংশ—কোড লেখা থেকে শুরু করে প্রোডাকশন মনিটরিং পর্যন্ত।

Shift-Left Security নীতি অনুসরণ করে ডেভেলপারদেরকে আইডিইতে নিরাপত্তা ফিডব্যাক প্রদান করতে হবে যাতে সমস্যাগুলো প্রাথমিক পর্যায়ে সমাধান করা যায়।

সার্ভারলেস সিকিউরিটির ক্ষেত্রে কিছু গুরুত্বপূর্ণ প্রবণতা লক্ষণীয়:

• Confidential Computing: AWS Nitro Enclaves এবং Azure Confidential VMs-এর মতো প্রযুক্তি সার্ভারলেস ফাংশনে আসছে যা মেমোরিতেও ডেটা এনক্রিপ্ট রাখবে।
• eBPF-based Observability: কার্নেল-লেভেল মনিটরিংয়ের মাধ্যমে সার্ভারলেস ফাংশনের আচরণ আরও গভীরভাবে বিশ্লেষণ করা সম্ভব হচ্ছে।
• AI-driven Anomaly Detection: মেশিন লার্নিং ব্যবহার করে স্বাভাবিক ফাংশন আচরণ থেকে বিচ্যুতি দ্রুত শনাক্ত করা যাচ্ছে।
• Policy-as-Code: OPA (Open Policy Agent) এবং Cedar-এর মতো টুল দিয়ে সিকিউরিটি পলিসি কোড আকারে প্রকাশ এবং প্রয়োগ করা যাচ্ছে।