GCP Security: গুগল ক্লাউড প্ল্যাটফর্মে কর্পোরেট ডেটার সর্বোচ্চ নিরাপত্তা নিশ্চিতকরণ!

Google Cloud-এর নিরাপত্তা স্থাপত্য বহুস্তরীয়। সবচেয়ে নিচের স্তরে রয়েছে Hardware Infrastructure Security, যেখানে Google নিজস্ব Titan Security Chip ডিজাইন করেছে যা প্রতিটি সার্ভারে Boot Integrity নিশ্চিত করে। এর উপরে রয়েছে Service Deployment Security, যা Application Layer Transport Security (ALTS) ব্যবহার করে সমস্ত ইন্টার-সার্ভিস কমিউনিকেশন এনক্রিপ্ট করে।

User Identity Layer-এ Google Identity Service কাজ করে, যা Multi-Factor Authentication, Phishing-Resistant Security Key, এবং Risk-Based Authentication সমর্থন করে। Data Storage Layer-এ Encryption at Rest ডিফল্টভাবে চালু থাকে—AES-256 ব্যবহার করে সমস্ত গ্রাহক ডেটা স্বয়ংক্রিয়ভাবে এনক্রিপ্ট হয়। Internet Communication Layer-এ Google Front End (GFE) DDoS Protection এবং TLS Termination পরিচালনা করে।

Shared Responsibility Model-এ Google নিজে দায়িত্বশীল "Security of the Cloud" নিশ্চিত করার জন্য—হার্ডওয়্যার, নেটওয়ার্ক, হাইপারভাইজার, এবং Core Service। অন্যদিকে গ্রাহক দায়িত্বশীল "Security in the Cloud" নিশ্চিত করার জন্য—তাদের কনফিগারেশন, ডেটা ক্লাসিফিকেশন, অ্যাক্সেস কন্ট্রোল, এবং অ্যাপ্লিকেশন কোডের নিরাপত্তা।

GCP-এর IAM হলো নিরাপত্তার মূল ভিত্তি। এখানে Principal (Identity), Role, এবং Resource-এর ত্রিভুজ সম্পর্ক রয়েছে। Principal হতে পারে Google Account, Service Account, Google Group, বা Workspace Domain। Role হলো অনুমতির সমষ্টি, এবং Resource হলো GCP-এর কোনো বস্তু—যেমন একটি Cloud Storage Bucket বা Compute Engine VM।

GCP তিন ধরনের Role অফার করে: Basic Role (Owner, Editor, Viewer)—যা ব্যাপক অনুমতি দেয় এবং প্রোডাকশনে এড়ানো উচিত; Predefined Role—যা নির্দিষ্ট পরিষেবার জন্য Google-এর তৈরি; এবং Custom Role—যা প্রতিষ্ঠানের নিজস্ব Least Privilege নীতি অনুযায়ী তৈরি করা যায়।

Service Account-এর নিরাপত্তা অত্যন্ত গুরুত্বপূর্ণ। দীর্ঘমেয়াদী Service Account Key এড়ানো উচিত; বরং Workload Identity Federation ব্যবহার করে AWS, Azure, বা GitHub Actions থেকে Short-Lived Token নিয়ে GCP-এ Authenticate করা যায়। GKE-এর জন্য Workload Identity পদ্ধতিতে Kubernetes Service Account-কে GCP Service Account-এ ম্যাপ করা হয়, যা Pod-পর্যায়ের আইডেন্টিটি নিশ্চিত করে।

IAM Conditions ব্যবহার করে Time-Based, IP-Based, বা Resource-Based অ্যাক্সেস কন্ট্রোল প্রয়োগ করা যায়। উদাহরণস্বরূপ, একজন ডেভেলপারকে শুধুমাত্র কর্মঘণ্টায় এবং কর্পোরেট IP থেকে Production Bucket অ্যাক্সেস দেওয়া সম্ভব।

GCP-এর Virtual Private Cloud (VPC) Global Resource হিসেবে কাজ করে—একটি VPC একাধিক রিজিওনে বিস্তৃত হতে পারে, যা AWS বা Azure-এর তুলনায় ভিন্ন। Firewall Rule VPC স্তরে প্রয়োগ হয় এবং Stateful—Ingress এবং Egress উভয় দিকেই কনফিগারেশন করা যায়।

VPC Service Controls হলো GCP-এর অন্যতম শক্তিশালী সিকিউরিটি ফিচার। এটি একটি "Security Perimeter" তৈরি করে যার মাধ্যমে সংবেদনশীল ডেটা (যেমন BigQuery Dataset, Cloud Storage Bucket) থেকে Data Exfiltration প্রতিরোধ করা যায়। পরিধির বাইরে থেকে কেউ যদি বৈধ ক্রেডেনশিয়াল সহ চেষ্টা করে, তবুও অ্যাক্সেস ব্লক হয়।

Private Google Access এবং Private Service Connect ব্যবহার করে Public Internet ছাড়াই GCP API এবং Third-Party SaaS-এ পৌঁছানো যায়। Cloud NAT এবং Cloud Armor যথাক্রমে Outbound এবং Inbound ট্রাফিক নিয়ন্ত্রণে গুরুত্বপূর্ণ ভূমিকা রাখে। Cloud Armor-এ Pre-Configured WAF Rule, Geo-Based Blocking, এবং Rate-Based Rule সমর্থিত।

Identity-Aware Proxy (IAP) ব্যবহার করে VPN ছাড়াই অভ্যন্তরীণ অ্যাপ্লিকেশনে নিরাপদ অ্যাক্সেস নিশ্চিত করা যায়। এটি Zero Trust নীতির বাস্তব রূপ—প্রতিটি রিকোয়েস্ট ইউজার আইডেন্টিটি এবং ডিভাইস কনটেক্সটের ভিত্তিতে যাচাই করা হয়।

GCP-এ ডেটা এনক্রিপশন তিন স্তরে কাজ করে। Encryption at Rest-এ Google ডিফল্ট কী ব্যবহার করে; তবে নিয়ন্ত্রিত শিল্পের জন্য Customer-Managed Encryption Keys (CMEK) Cloud KMS-এর মাধ্যমে ব্যবহার করা যায়। আরও কঠোর প্রয়োজনে Customer-Supplied Encryption Keys (CSEK) প্রদান করা যায়, যেখানে Google কী সংরক্ষণ করে না।

Encryption in Transit ALTS এবং TLS 1.3-এর মাধ্যমে নিশ্চিত হয়। Encryption in Use-এর জন্য Confidential VM সমাধান রয়েছে, যা AMD SEV বা Intel TDX প্রযুক্তি ব্যবহার করে মেমোরিতেও ডেটা এনক্রিপ্ট রাখে—এমনকি Hypervisor-ও সেই ডেটা দেখতে পারে না।

Cloud DLP (Data Loss Prevention) API ব্যবহার করে সংবেদনশীল তথ্য যেমন Credit Card Number, National ID, Email, এবং Custom Pattern স্বয়ংক্রিয়ভাবে শনাক্ত ও Masking, Tokenization, কিংবা Redaction করা যায়। Sensitive Data Protection BigQuery Dataset, Cloud Storage Bucket-এও স্বয়ংক্রিয়ভাবে স্ক্যান চালাতে সক্ষম।

Secret Manager Cloud KMS-এর সাথে ইন্টিগ্রেটেড একটি বিশেষ পরিষেবা যেখানে API Key, Database Password, এবং Certificate নিরাপদে সংরক্ষণ ও Versioning করা যায়। কোডে Secret hardcode করার পরিবর্তে Secret Manager থেকে রানটাইমে লোড করা উত্তম।

বাস্তব জগতে GCP-এ ঘটে যাওয়া অনেক ডেটা ব্রিচ সাধারণ Misconfiguration থেকেই উদ্ভূত। Public Cloud Storage Bucket—যেখানে allUsers বা allAuthenticatedUsers-কে Read পারমিশন দেওয়া আছে—সবচেয়ে ঘন ঘন দেখা সমস্যা। ২০১৯ সালে এমন একটি Misconfigured Bucket থেকে কয়েক মিলিয়ন গ্রাহকের ডেটা ফাঁস হয়েছিল।

Service Account Key Leakage আরেকটি বড় ঝুঁকি। ডেভেলপাররা প্রায়ই GitHub-এ ভুল করে JSON Key Commit করেন, যা GitGuardian-এর গবেষণা অনুযায়ী প্রতি সপ্তাহে হাজার হাজার বার ঘটে। অ্যাটাকার এই Key পেলেই সংশ্লিষ্ট প্রজেক্টে অ্যাক্সেস পেয়ে যায়।

Overly Permissive IAM Binding—বিশেষত roles/owner বা roles/editor সরাসরি ইউজারকে দেওয়া—Privilege Escalation-এর পথ খুলে দেয়। অ্যাটাকার যদি কোনো লো-প্রিভিলেজ অ্যাকাউন্টে অ্যাক্সেস পায় এবং iam.serviceAccountTokenCreator রোল থাকে, তবে সে অন্য Service Account ইমপারসোনেট করে উচ্চ অনুমতি পেতে পারে।

Firewall Rule-এ 0.0.0.0/0 থেকে SSH (port 22) বা RDP (port 3389) খোলা রাখা একটি সাধারণ ভুল। Open SSH পোর্টে অ্যাটাকাররা ক্রমাগত Brute-Force চালায়। বরং IAP TCP Forwarding ব্যবহার করে SSH অ্যাক্সেস দেওয়া উচিত।

Google Cloud Marketplace-এর Public Image-এ পুরনো বা Vulnerable লাইব্রেরি থাকতে পারে। নিয়মিত Container Analysis এবং Artifact Registry Scanning চালানো উচিত যাতে CVE-যুক্ত ইমেজ ব্লক করা যায়।

GCP-এর Cloud Logging সমস্ত API Call, Admin Activity, Data Access, এবং System Event রেকর্ড করে। Admin Activity Log ফ্রি এবং ৪০০ দিন পর্যন্ত সংরক্ষিত থাকে। Data Access Log ডিফল্টভাবে বন্ধ থাকে এবং সংবেদনশীল ডেটা অ্যাক্সেস ট্র্যাক করতে চালু করতে হয়।

Cloud Monitoring-এর সাথে Alerting Policy যুক্ত করে অস্বাভাবিক আচরণ যেমন Failed Login Spike, Unusual API Call, বা Cost Anomaly সনাক্ত করা যায়। Security Command Center (SCC) GCP-এর কেন্দ্রীয় সিকিউরিটি ম্যানেজমেন্ট প্ল্যাটফর্ম, যা Misconfiguration, Vulnerability, এবং Threat Detection একসাথে দেখায়।

Event Threat Detection স্বয়ংক্রিয়ভাবে Brute-Force SSH, Malware-Infected VM, Cryptomining, এবং Data Exfiltration শনাক্ত করতে পারে। Container Threat Detection GKE-এর জন্য বিশেষভাবে কাজ করে এবং Reverse Shell, Suspicious Binary Execution-এর মতো ঘটনা ধরে।

Chronicle Security Operations Google-এর SIEM সমাধান, যা পেটাবাইট স্কেলে লগ অ্যানালাইসিস করতে পারে। Mandiant-এর Threat Intelligence-এর সাথে ইন্টিগ্রেশন থাকায় Modern Threat Detection আরও শক্তিশালী হয়।

GCP-এ শক্তিশালী নিরাপত্তা নিশ্চিত করতে কিছু Best Practice অনুসরণ করা জরুরি। প্রথমত, Organization Policy Service ব্যবহার করে কর্পোরেট-পর্যায়ের নিয়ম প্রয়োগ করতে হবে—যেমন Public IP নিষেধ, নির্দিষ্ট রিজিওনে রিসোর্স তৈরির অনুমতি, এবং Service Account Key Creation নিষেধ।

দ্বিতীয়ত, Infrastructure as Code (IaC) ব্যবহার করে সমস্ত রিসোর্স Terraform বা Deployment Manager-এর মাধ্যমে ডিপ্লয় করা উচিত। এতে Configuration Drift এড়ানো যায় এবং Policy as Code-এর মাধ্যমে Pre-Deployment Validation সম্ভব হয়। Checkov বা tfsec দিয়ে Terraform কোডে Security Misconfiguration আগেই ধরা যায়।

তৃতীয়ত, Least Privilege নীতি কঠোরভাবে প্রয়োগ করতে হবে। Recommender API-এর IAM Recommender ব্যবহার করে অব্যবহৃত অনুমতি স্বয়ংক্রিয়ভাবে চিহ্নিত করা যায়। Just-in-Time Access-এর জন্য Privileged Access Manager বা Third-Party টুল ব্যবহার করে স্বল্পমেয়াদী Elevated Permission প্রদান করা যায়।

চতুর্থত, MFA এবং Phishing-Resistant Authentication আবশ্যক করতে হবে। Google Workspace-এর Context-Aware Access দিয়ে ডিভাইস অবস্থা, লোকেশন, এবং নেটওয়ার্কের ভিত্তিতে কন্ডিশনাল অ্যাক্সেস প্রয়োগ করা যায়।

পঞ্চমত, নিয়মিত Penetration Test এবং Cloud Configuration Review চালানো উচিত। Google-এর Cloud Security Posture Management (CSPM) টুল ছাড়াও Prisma Cloud, Wiz, এবং Orca-এর মতো Third-Party Solution বহু-ক্লাউড নিরাপত্তায় সহায়ক।

ষষ্ঠত, Disaster Recovery এবং Backup Strategy থাকতে হবে। Cloud Storage Object Versioning এবং Bucket Lock ব্যবহার করে Ransomware Attack বা Accidental Deletion থেকে সুরক্ষা পাওয়া যায়। Cross-Region Replication গুরুত্বপূর্ণ ডেটার জন্য অপরিহার্য।