Ransomware সহ্য করতে পারে এমন ব্যাকআপ ── 3-2-1 নিয়ম, ওভাররাইট করা যায় না এমন স্টোরেজ, আর রিস্টোর করা যায় কি না তার যাচাই

Ransomware আক্রমণে এমন অনেক ঘটনা আছে যেখানে প্রতিষ্ঠানের ব্যাকআপ ছিল, তবু রিস্টোর করা যায়নি। সবচেয়ে সাধারণ কারণ হলো ব্যাকআপও বাকি সবকিছুর সঙ্গে এনক্রিপ্ট হয়ে যাওয়া। এই নিবন্ধে ছোট ও মাঝারি প্রতিষ্ঠানের Windows PC আর ফাইল সার্ভারের জন্য আক্রমণ সহ্য করতে পারে এমন ব্যাকআপ কীভাবে তৈরি করতে হয় তা ব্যাখ্যা করা হয়েছে।

মূল কথা তিনটি: এমন একটি কপি রাখা যা সংক্রমিত PC ওভাররাইট করতে পারে না, “Previous Versions”-কে ব্যাকআপের বদলে ব্যবহার না করা, এবং সত্যিই রিস্টোর করা যায় কি না যাচাই করা। 3-2-1 নিয়ম দিয়ে ঠিক হয় কতগুলো কপি রাখবেন আর কোথায়, কিন্তু শুধু এটুকু দিয়ে ransomware-এর বিরুদ্ধে প্রস্তুতিতে কিছু ঘাটতি থেকে যায়।

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

ব্যাকআপ থাকা সত্ত্বেও অনেক প্রতিষ্ঠান রিস্টোর করতে পারেনি

Japan-এর National Police Agency ransomware-এ ক্ষতিগ্রস্ত প্রতিষ্ঠানগুলোর কাছে তাদের ব্যাকআপের অবস্থা জানতে চায়। ২০২৫ সালের প্রথম ছয় মাসের প্রতিবেদনে উত্তর দেওয়া ৫৩টি প্রতিষ্ঠানের মধ্যে ৫১টি ব্যাকআপ নিয়েছিল। কিন্তু ব্যাকআপ থেকে আক্রমণের ঠিক আগের অবস্থায় ফিরতে পেরেছে কি না জানতে চাওয়া ৪৮টির মধ্যে মাত্র ৭টি পেরেছে, আর ৪১টি পারেনি¹।

রিস্টোর করতে না পারার কারণ জানানো ৩৫টি ক্ষেত্রে “ব্যাকআপও এনক্রিপ্ট” ছিল ২৩টি, “পরিচালনার ত্রুটি” ৮টি, আর “অন্যান্য” ৪টি¹। একই প্রতিবেদনে লেখা আছে যে ransomware গোষ্ঠীগুলো চিহ্ন মুছে ফেলতে আর পুনরুদ্ধারের কাজ আটকাতে ক্ষতিগ্রস্ত প্রতিষ্ঠানের লগ ও ব্যাকআপ মুছে দেয়। সেই সঙ্গে প্রতিবেদনটি ব্যাকআপ অফলাইন পরিবেশে রাখার পরামর্শ দেয়²।

flowchart TB
        accTitle: ব্যাকআপ থাকলেও রিস্টোর না হওয়ার প্রবাহ
        accDescr: এই চিত্রে দেখানো হয়েছে যে ব্যাকআপ নিলেও, সেটি সংক্রমিত PC-র নাগালে থাকলে একসঙ্গে এনক্রিপ্ট হয়ে যায়, আর রিস্টোরের পদ্ধতি যাচাই না করা থাকলে পরিচালনার ত্রুটিতে রিস্টোর হয় না।
        A["ব্যাকআপ নেওয়া হচ্ছে"] --> B{"সংক্রমিত PC কি পৌঁছাতে পারে"}
        B -->|"পারে"| C["একসঙ্গে এনক্রিপ্ট বা মুছে যায়"]
        B -->|"পারে না"| D{"রিস্টোরের পদ্ধতি কি যাচাই করা হয়েছে"}
        D -->|"যাচাই করা হয়নি"| E["পরিচালনার ত্রুটিতে রিস্টোর হয় না"]
        D -->|"যাচাই করা হয়েছে"| F["রিস্টোর করা যায়"]

চিত্র 1: ব্যাকআপ তখনই কাজে লাগে যখন সংক্রমিত PC তার নাগাল পায় না এবং রিস্টোরের পদ্ধতি যাচাই করা থাকে।

রিস্টোর করতে পারার উদাহরণও আছে। IPA-র “ছোট ও মাঝারি প্রতিষ্ঠানের তথ্য নিরাপত্তা নির্দেশিকা” (Information Security Guidelines for SMEs)-র ৪র্থ সংস্করণে একটি নির্মাণ প্রতিষ্ঠানের ঘটনা আছে, যার ফাইল সার্ভারসহ অন্যান্য সিস্টেম VPN যন্ত্রের মাধ্যমে অনুপ্রবেশের পরে এনক্রিপ্ট হয়ে গিয়েছিল। প্রতিষ্ঠানটি বছরে দুবার রিস্টোর মহড়া করত, সেটিও কাজে লেগেছিল, এবং আক্রমণ ধরা পড়ার পাঁচ দিন পরে ব্যাকআপ থেকে মূল সিস্টেম আবার চালু করেছিল। তবু প্রতিষ্ঠানের অভ্যন্তরীণ সিস্টেমগুলো আবার শুরু করতে ৪১ দিন আর রিমোট অ্যাক্সেস আবার চালু করতে ৪ মাস লেগেছিল, এবং অভ্যন্তরীণ ফাইলের ২০ শতাংশের কিছু বেশি হারিয়ে গিয়েছিল³। ব্যাকআপ থেকে রিস্টোর করতে পারলেও ক্ষতি মুছে যায় না।

চিত্রে, টানা রেখা সবসময় সত্য এমন সম্পর্ককে এবং ভাঙা রেখা শর্তসাপেক্ষ সম্পর্ককে নির্দেশ করে (শর্তগুলো বিস্তারিত পাতায় প্রতিটি সম্পর্কের ব্যাখ্যায় আছে)। সম্পর্কের সম্পূর্ণ তালিকা (মোট 13, প্রমাণ ও নিশ্চয়তার মাত্রাসহ) এবং প্রধান ধারণাগুলোর সংজ্ঞা জ্ঞান মানচিত্রের বিস্তারিত পাতায় সংগ্রহ করা আছে (জাপানি ভাষায়)। তথ্য: JSON-LD / Turtle

আক্রমণকারীরা নাগালের মধ্যের ব্যাকআপ মুছে দেয়

US-এর CISA ও অন্যান্য সংস্থার #StopRansomware Guide লিখেছে যে অনেক ransomware, মুক্তিপণ না দিলে পুনরুদ্ধার অসম্ভব করতে, নাগালের মধ্যে থাকা ব্যাকআপ খুঁজে মুছে ফেলার বা এনক্রিপ্ট করার চেষ্টা করে। তাই গাইডটি ব্যাকআপ অফলাইনে রাখাকে গুরুত্বপূর্ণ বলে⁴।

Microsoft-ও লিখেছে যে আক্রমণকারীরা ব্যাকআপ সফটওয়্যার আর volume shadow copy-র মতো OS-এর বৈশিষ্ট্য অকেজো করার ওপর জোর দেয়⁵। সংক্রমিত PC-র নাগালে থাকা ব্যাকআপ এরকম হয়:

• PC-তে সবসময় লাগানো এক্সটার্নাল ড্রাইভ
• ড্রাইভ লেটার দেওয়া NAS বা ফাইল সার্ভারের শেয়ারড ফোল্ডার
• সাধারণ অ্যাকাউন্ট দিয়ে লেখা যায় এমন ক্লাউড সিঙ্ক ফোল্ডার
• একই ভলিউমে থাকা শ্যাডো কপি (Previous Versions)

OS-এর নিজস্ব কমান্ড দিয়েও শ্যাডো কপি আর ব্যাকআপ ক্যাটালগ মুছে ফেলা যায়। MITRE ATT&CK এই কৌশলকে “Inhibit System Recovery” (T1490) নামে শ্রেণিবদ্ধ করেছে। সেখানে vssadmin.exe delete shadows /all /quiet দিয়ে সব শ্যাডো কপি মোছা আর wbadmin.exe delete catalog -quiet দিয়ে Windows ব্যাকআপ ক্যাটালগ মোছার উদাহরণ দেওয়া আছে⁶। CISA-র গাইডও vssadmin.exe, wbadmin.exe, wmic.exe (shadowcopy) ইত্যাদির সন্দেহজনক ব্যবহারের ওপর নজর রাখতে বলে⁴।

flowchart TB
        accTitle: সংক্রমিত PC-র নাগালে থাকা ও না-থাকা ব্যাকআপ
        accDescr: এই চিত্রে দেখানো হয়েছে যে সংক্রমিত PC সবসময় লাগানো এক্সটার্নাল ড্রাইভ, ড্রাইভ লেটার দেওয়া শেয়ারড ফোল্ডার, সিঙ্ক ফোল্ডার আর শ্যাডো কপিতে লিখতে পারে, কিন্তু খুলে রাখা মিডিয়া আর ওভাররাইট করা যায় না এমন স্টোরেজে লিখতে পারে না।
        P["সংক্রমিত PC"] --> R["লেখা যায় এমন জায়গা"]
        P -.-x N["খুলে রাখা মিডিয়া ও ওভাররাইট করা যায় না এমন স্টোরেজ"]
        R --> A["সবসময় লাগানো এক্সটার্নাল ড্রাইভ"]
        R --> B["ড্রাইভ লেটার দেওয়া শেয়ারড ফোল্ডার"]
        R --> C["ক্লাউড সিঙ্ক ফোল্ডার"]
        R --> D["শ্যাডো কপি"]

চিত্র 2: যেসব জায়গায় সংক্রমিত PC লিখতে পারে, সেখানে রাখা ব্যাকআপ আক্রমণের লক্ষ্য হয়।

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

“Previous Versions” ব্যাকআপের বিকল্প নয়

Windows-এর “Previous Versions” আর শেয়ারড ফোল্ডারের শ্যাডো কপি Volume Shadow Copy (VSS) ব্যবহার করে। Windows-এর সঙ্গে আসা VSS সিস্টেম প্রোভাইডার copy-on-write পদ্ধতিতে কাজ করে: কোনো ব্লক বদলানোর আগে তার বিষয়বস্তু diff area-তে সরিয়ে রাখে, আর এভাবে একটি নির্দিষ্ট সময়ের ভলিউম আবার গড়ে তোলে⁷।

Microsoft তার VSS নথিতে শ্যাডো কপি আর ব্যাকআপের পার্থক্য এভাবে ব্যাখ্যা করেছে। শ্যাডো কপি থেকে টেপের মতো খুলে ফেলা যায় এমন মিডিয়ায় ডেটা কপি করলে সেই মিডিয়ার বিষয়বস্তুই ব্যাকআপ হয়। কপি করার পরে শ্যাডো কপি নিজে মুছে ফেলা যায়⁷। এটাও লেখা আছে যে diff area-তে জায়গা কম পড়লে পুরনো শ্যাডো কপি থেকে ক্রমানুসারে মুছে যায়⁷।

flowchart TB
        accTitle: শ্যাডো কপি ও ব্যাকআপের পার্থক্য
        accDescr: এই চিত্রে দেখানো হয়েছে যে শ্যাডো কপি মূল ভলিউমের পরিবর্তনের অংশ এবং জায়গার অভাবে বা আক্রমণে মুছে যায়, অথচ আলাদা মিডিয়ায় কপি করা ব্যাকআপ মূল ভলিউম হারালেও থেকে যায়।
        V["মূল ভলিউম"] --> S["শ্যাডো কপি (পরিবর্তনের অংশ)"]
        S --> L["জায়গা কম পড়লে পুরনোটা থেকে মোছে"]
        S --> K["আক্রমণকারী vssadmin দিয়ে মোছে"]
        S -->|"আলাদা মিডিয়ায় কপি"| B["ব্যাকআপ"]
        B --> R["মূল ভলিউম হারালেও থেকে যায়"]

চিত্র 3: শ্যাডো কপি মূল ভলিউমের ডেটার ওপর নির্ভর করে; আলাদা মিডিয়ায় কপি করা অংশই ব্যাকআপ।

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

কোন শ্যাডো কপিগুলো রয়ে গেছে, তা অ্যাডমিনিস্ট্রেটর কমান্ড প্রম্পটে vssadmin list shadows চালিয়ে তালিকা আকারে দেখা যায়। এই সাবকমান্ড ক্লায়েন্ট আর সার্ভার দুটোতেই ব্যবহার করা যায়⁸।

vssadmin list shadows

OneDrive আর SharePoint-এর ভার্সন হিস্টরি ও রিসাইকেল বিনও ব্যবহারকারীদের ফাইল ফিরিয়ে আনার উপায়। Microsoft পরামর্শ দেয় ব্যবহারকারীদের পুরো OneDrive আগের কোনো সময়ে ফিরিয়ে নেওয়ার পদ্ধতি শিখিয়ে রাখতে। সেই সঙ্গে বলে, আক্রমণকারীকে বের করে দেওয়া হয়েছে বলে নিশ্চিত হওয়ার পরেই রিস্টোর করতে দিতে, এবং ব্যবহারকারী যদি ম্যালওয়্যারও ফিরিয়ে আনেন তার জন্য ব্যবস্থা তৈরি রাখতে⁵।

3-2-1 নিয়ম কপির সংখ্যা ও রাখার জায়গা ঠিক করে

3-2-1 নিয়ম ব্যাকআপের কপি রাখার একটি অভিজ্ঞতালব্ধ নিয়ম। US-CERT-এর জন্য ২০১২ সালে তৈরি “Data Backup Options” এটি এভাবে ব্যাখ্যা করে⁹।

• 3: গুরুত্বপূর্ণ ফাইলের মোট তিনটি কপি রাখুন, অর্থাৎ মূলটি একটি আর ব্যাকআপ দুটি।
• 2: ভিন্ন ধরনের দুর্যোগের জন্য দুই ধরনের মিডিয়ায় রাখুন।
• 1: একটি কপি বাড়ি বা অফিসের বাইরে রাখুন।

এই নথি উৎস হিসেবে আলোকচিত্রী Peter Krogh-এর ডিজিটাল ছবি ব্যবস্থাপনার বই “The DAM Book”-এর নাম দেয়⁹। Microsoft-ও ransomware-এর বিরুদ্ধে প্রস্তুতির ব্যাকআপ নথিতে এই নিয়মের কথা বলে, এবং “1”-কে “প্রতিষ্ঠানের বাইরের, বা কোল্ড কপি” হিসেবে ব্যাখ্যা করে⁵।

3-2-1 নিয়ম শুধু এটুকু চায় যে একটি কপি বাইরে রাখা হোক। বাইরের কপিটি অফলাইন বা ওভাররাইট করা যায় না এমন হতে হবে, তা চায় না। তাই বাইরের কপিটি যদি এমন ক্লাউডে থাকে যেখানে সংক্রমিত PC সবসময় লিখতে পারে, তবে সেটি হাতের কাছের কপির সঙ্গে এনক্রিপ্ট হয়ে যেতে পারে। CISA-র গাইড আর Microsoft-এর নথি ransomware-এর বিরুদ্ধে প্রস্তুতি হিসেবে অফলাইন সংরক্ষণের কথা বলে। Microsoft ওভাররাইট করা যায় না এমন স্টোরেজের কথাও বলে⁴⁵।

flowchart TB
        accTitle: 3-2-1 নিয়ম ও ransomware-এর বিরুদ্ধে প্রস্তুতি
        accDescr: এই চিত্রে দেখানো হয়েছে যে তিনটি কপি, দুই ধরনের মিডিয়া ও একটি বাইরে রাখার 3-2-1 নিয়মে একটি অফলাইন বা ওভাররাইট করা যায় না এমন কপি যোগ করতে হবে এবং রিস্টোর করা যায় কি না যাচাই করতে হবে।
        A["তিনটি কপি"] --> B["দুই ধরনের মিডিয়া"]
        B --> C["একটি বাইরে"]
        C --> D["একটি অফলাইন বা ওভাররাইট-অযোগ্য"]
        D --> E["রিস্টোর করা যায় কি না যাচাই"]

চিত্র 4: 3-2-1 নিয়মে এমন একটি কপি যোগ করুন যা সংক্রমিত PC ওভাররাইট করতে পারে না, আর রিস্টোরের যাচাই যোগ করুন।

ব্যাকআপ পণ্য Veeam এটিকে “3-2-1-1-0 নিয়ম” নামে প্রচার করে। Veeam-এর নথিতে বাড়তি “1” মানে একটি অফলাইন, এয়ার-গ্যাপড বা ওভাররাইট করা যায় না এমন কপি রাখা, আর “0” মানে নিয়মিত রিস্টোর যাচাইয়ে কোনো ত্রুটি না থাকা¹⁰। এটি একটি বিক্রেতার নথিতে থাকা নাম, কোনো সরকারি মানদণ্ড নয়। তবে বাড়তি দুটি বিষয় CISA ও IPA যা চায় তার সঙ্গেও মেলে।

এমন একটি কপি রাখুন যা সংক্রমিত PC ওভাররাইট করতে পারে না

ওভাররাইট করা যায় না এমন কপি তৈরির প্রধানত দুটি উপায় আছে। একটি হলো মিডিয়া PC থেকে খুলে রেখে সংরক্ষণ করা। অন্যটি হলো এমন ক্লাউড স্টোরেজ ব্যবহার করা যেখানে নির্দিষ্ট সময় পর্যন্ত ওভাররাইট বা মোছা যায় না। যেটিই বেছে নিন, ব্যাকআপ পরিচালনার অনুমতি দৈনন্দিন কাজ থেকে আলাদা রাখুন।

মিডিয়া PC থেকে খুলে রেখে সংরক্ষণ করুন

IPA-র নির্দেশিকা স্ব-মূল্যায়নের ব্যবস্থার উদাহরণ হিসেবে বলে, ব্যাকআপের জন্য ব্যবহৃত যন্ত্র বা মিডিয়া শুধু ব্যাকআপ নেওয়ার সময় কম্পিউটারের সঙ্গে লাগাতে। এ ছাড়া ব্যাকআপ নেওয়ার পদ্ধতি ঠিক করা, নিরাপদ জায়গায় রাখা এবং রিস্টোর করা যায় কি না নিয়মিত যাচাই করার কথাও বলে¹¹।

আরও গভীরভাবে কাজ করার পর্যায়ে নির্দেশিকাটি “ভৌত বিচ্ছিন্নতা”-র কথা বলে। এতে ব্যাকআপ মূল সিস্টেম থেকে ভৌতভাবে দূরের জায়গায় রাখা হয়, আর এক্সটার্নাল স্টোরেজ বা ব্যাকআপ টেপ যতটা সম্ভব দূরে সংরক্ষণ করা হয়। সংরক্ষণের জায়গার উদাহরণ হিসেবে ব্যাংকের সেফ ডিপোজিট বক্স, বা বিশ্বস্ত ব্যবসায়িক অংশীদার বা সহযোগী প্রতিষ্ঠানের কথা বলা হয়েছে¹²।

উৎপাদন সিস্টেম থেকে এভাবে বিচ্ছিন্ন করে রাখা ব্যাকআপকে অফলাইন ব্যাকআপ বলে। খুলে রাখা মিডিয়ায় সংক্রমিত PC লিখতে পারে না। বদলে লাগানো-খোলা আর বয়ে নেওয়ার কাজ মানুষকে করতে হয়, তাই ব্যাকআপ নিতে ভুলে যাওয়া বা নিয়ে যেতে ভুলে যাওয়ার ঘটনা ঘটে। কে, কখন মিডিয়া লাগাবেন, খুলবেন আর সংরক্ষণের জায়গায় নিয়ে যাবেন তা আগে থেকে ঠিক করে রাখুন।

ওভাররাইট করা যায় না এমন ক্লাউড স্টোরেজ ব্যবহার করুন

ক্লাউড স্টোরেজে এমন বৈশিষ্ট্য আছে যাতে ঠিক করা সময় পর্যন্ত ডেটা ওভাররাইট বা মোছা যায় না। এতে ডেটা WORM (Write Once, Read Many) অবস্থায় রাখা হয়।

Azure Blob Storage-এর immutable storage-এ সময়ভিত্তিক রিটেনশন পলিসি সেট করলে সেই সময়ের মধ্যে ডেটা তৈরি ও পড়া যায়, কিন্তু পরিবর্তন বা মোছা যায় না¹³। পলিসি প্রথমে আনলকড অবস্থায় তৈরি হয়, আর পরীক্ষার পরে লক করা হয়। লক করা পলিসি মোছা যায় না, এবং রিটেনশনের সময় বাড়ানো গেলেও কমানো যায় না¹³। Microsoft ব্যাখ্যা করে যে অ্যাকাউন্টের অ্যাডমিনিস্ট্রেটর অনুমতি থাকা ব্যবহারকারীও ডেটা পরিবর্তন বা মুছতে পারেন না¹³।

Amazon S3-এর Object Lock-এ দুটি মোড আছে। Compliance মোডে রিটেনশনের সময়ে AWS অ্যাকাউন্টের root user-সহ কেউই অবজেক্টের ভার্সন ওভাররাইট বা মুছতে পারে না। Governance মোডে শুধু বিশেষ অনুমতি থাকা ব্যবহারকারীরা রিটেনশন সেটিংস বদলাতে বা মুছতে পারেন¹⁴। Object Lock শুধু সেইসব বাকেটে ব্যবহার করা যায় যেখানে S3 versioning চালু আছে¹⁴।

flowchart TB
        accTitle: ওভাররাইট করা যায় না এমন স্টোরেজের দুটি উদাহরণ
        accDescr: এই চিত্রে দেখানো হয়েছে যে Azure Blob Storage-এর immutable storage-এ লক করা পলিসি মোছা যায় না ও রিটেনশনের সময় কমানো যায় না, আর S3 Object Lock-এর compliance মোডে root user-ও মুছতে পারে না, অথচ governance মোডে বিশেষ অনুমতি দিয়ে বদলানো যায়।
        W["ওভাররাইট করা যায় না এমন স্টোরেজ"] --> AZ["Azure Blob Storage-এর immutable storage"]
        W --> S3["S3 Object Lock"]
        AZ --> AZ1["লকের পরে রিটেনশনের সময় কমানো যায় না"]
        S3 --> C["Compliance মোড"]
        S3 --> G["Governance মোড"]
        C --> C1["Root user-ও মুছতে পারে না"]
        G --> G1["বিশেষ অনুমতি দিয়ে বদলানো যায়"]

চিত্র 5: দুটি স্টোরেজই ঠিক করা সময় পর্যন্ত ওভাররাইট ও মোছা আটকায়। সুরক্ষা কতটা শক্ত তা সেটিংসের ওপর নির্ভর করে।

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

ব্যাকআপ পরিচালনার অনুমতি আলাদা রাখুন

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

PC-র পরিচালনা আর ব্যাকআপের পরিচালনা একই ব্যক্তি করলেও, ব্যাকআপের গন্তব্য পরিচালনার অ্যাকাউন্ট রোজকার PC সাইন-ইনে ব্যবহার করবেন না, আর তাতে মাল্টিফ্যাক্টর অথেনটিকেশন চালু রাখুন।

একাধিক প্রজন্ম রাখুন

IPA-র নির্দেশিকা একাধিক সময়ের ব্যাকআপ রাখার “প্রজন্ম ব্যবস্থাপনা”-র কথা বলে। এতে ডেটা নষ্ট বা হারিয়ে গেলে একটি নির্দিষ্ট সময় পর্যন্ত পিছিয়ে গিয়ে রিস্টোর করা যায়¹²। আগের অংশে যেমন বলা হয়েছে, এনক্রিপশন টের পেতে সময় লাগলে সর্বশেষ ব্যাকআপটি এনক্রিপশনের পরের ডেটা হয়ে থাকে। কতগুলো প্রজন্ম রাখবেন, তা এনক্রিপশন টের পেতে কত সময় লাগতে পারে আর সংরক্ষণের খরচ কত, তা দেখে ঠিক করুন।

flowchart TB
        accTitle: ওভাররাইট করা যায় না এমন কপি রাখার তিনটি উপায়
        accDescr: এই চিত্রে দেখানো হয়েছে যে মিডিয়া খুলে রেখে সংরক্ষণ করুন বা ওভাররাইট করা যায় না এমন স্টোরেজ ব্যবহার করুন, ব্যাকআপ পরিচালনার অনুমতি সাধারণ অ্যাকাউন্ট থেকে আলাদা রাখুন, এবং একাধিক প্রজন্ম রাখুন।
        A["ওভাররাইট করা যায় না এমন কপি"] --> B["মিডিয়া খুলে রেখে সংরক্ষণ"]
        A --> C["ওভাররাইট করা যায় না এমন স্টোরেজ"]
        B --> D["পরিচালনার অনুমতি আলাদা রাখা"]
        C --> D
        D --> E["একাধিক প্রজন্ম রাখা"]

চিত্র 6: রাখার জায়গা ঠিক করার পরে পরিচালনার অনুমতি আলাদা রাখুন, আর প্রজন্ম রাখুন যাতে দেরিতে টের পেলেও ফিরে যাওয়া যায়।

রিস্টোর করা যায় কি না যাচাই করুন

National Police Agency-র প্রতিবেদনে রিস্টোর করতে না পারার দ্বিতীয় সাধারণ কারণ ছিল “পরিচালনার ত্রুটি”¹। নেওয়া ব্যাকআপ সত্যিই রিস্টোর হয় কি না, তা রিস্টোর করে না দেখা পর্যন্ত জানা যায় না। ব্যাকআপ থেকে সত্যিই রিস্টোর করে এটি নিশ্চিত করার কাজকে রিস্টোর টেস্ট বলে।

IPA-র নির্দেশিকা ব্যাকআপ পরিচালনাকে নেওয়া, সংরক্ষণ ও পুনরুদ্ধার, এই তিন ভাগে ভাগ করে। পুনরুদ্ধারের জন্য পুনরুদ্ধার পরিকল্পনা তৈরি করতে এবং সঠিকভাবে পুনরুদ্ধার করা যায় কি না নিশ্চিত করতে বলে³। ব্যবসার জন্য গুরুত্বপূর্ণ সিস্টেমের ক্ষেত্রে বলে, recovery time objective (RTO) আর recovery point objective (RPO) অনুযায়ী ব্যাকআপ নেওয়া ও পদ্ধতি সাজাতে, এবং মহড়ার মাধ্যমে কার্যকারিতা যাচাই করতে। RTO হলো লক্ষ্য মাত্রা পর্যন্ত ফিরিয়ে আনতে যে সময় লাগে, আর RPO হলো কোন সময়বিন্দুতে ফেরানো হবে, অর্থাৎ সর্বশেষ ব্যাকআপের সময়¹⁵। CISA-র গাইডও দুর্যোগ থেকে পুনরুদ্ধারের কথা মাথায় রেখে নিয়মিত যাচাই করতে বলে যে ব্যাকআপ ব্যবহারযোগ্য কি না আর নষ্ট হয়নি কি না⁴।

flowchart TB
        accTitle: রিস্টোর টেস্ট চালানোর ধাপ
        accDescr: এই চিত্রে প্রবাহ দেখানো হয়েছে: রিস্টোরের ক্রম ঠিক করা, আলাদা পরিবেশে রিস্টোর করা, লাগা সময় ও ফিরে আসা সময়বিন্দু RTO ও RPO-র সঙ্গে মেলানো, এবং রানবুক ঠিক করা।
        A["রিস্টোরের ক্রম ঠিক করা"] --> B["আলাদা পরিবেশে রিস্টোর"]
        B --> C["লাগা সময় RTO-র সঙ্গে মেলানো"]
        B --> D["ফিরে আসা সময়বিন্দু RPO-র সঙ্গে মেলানো"]
        C --> E["রানবুক ঠিক করা"]
        D --> E
        E -.->|"পরের যাচাই"| A

চিত্র 7: রিস্টোর করে দেখুন সময় ও সময়বিন্দু লক্ষ্যের সঙ্গে মেলে কি না, আর ফলাফল রানবুকে ফিরিয়ে দিন।

কী যাচাই করবেন

IPA ও Microsoft-এর নথি থেকে যাচাইয়ের বিষয়গুলো এভাবে সাজানো যায়।

Microsoft পরামর্শ দেয় প্রথমে ব্যবসার জন্য অপরিহার্য সিস্টেম ঠিক করে সেগুলোর নিয়মিত ব্যাকআপ নিতে। এভাবে তৈরি ব্যাকআপের অগ্রাধিকারের তালিকাই রিস্টোরের ক্রমের তালিকা হয়ে যায়। অগ্রাধিকারের মধ্যে প্রথমেই Active Directory-র মতো অথেনটিকেশন ব্যবস্থার কথা বলে, যা অন্য সব সিস্টেমে ঢোকার জন্য দরকার⁵। সব সিস্টেম বন্ধ থাকা অবস্থা থেকে ব্যবসা আবার চালু করার মহড়া নিয়মিত করারও পরামর্শ দেয়। সে সময় ধরে নিন যে ইমেইল আর চ্যাটও ব্যবহার করা যাবে না⁵।

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

আক্রমণের পরে রিস্টোর করার সময় সতর্কতা

আসল আক্রমণের পরে আগে ransomware পরিবেশ থেকে সরান, তারপর রিস্টোর করুন⁵। Microsoft বলে, এমন সময়ের ব্যাকআপ বেছে নিতে যখন সংক্রমণ ছিল না বলে জানা আছে, এবং রিস্টোরের আগে ব্যাকআপে ম্যালওয়্যার আছে কি না পরীক্ষা করতে⁵। National Police Agency-র প্রতিবেদন লিখেছে, অনুপ্রবেশের পথ বন্ধ হলেও আবার ঢুকতে পারার জন্য ransomware গোষ্ঠীগুলো কখনো কখনো দূর থেকে নিয়ন্ত্রণ করা যায় এমন সফটওয়্যার ব্যাকডোর হিসেবে বসিয়ে রাখে²। রিস্টোরের আগে অনুপ্রবেশের পথ আর রেখে যাওয়া ব্যবস্থাগুলো খুঁজে দেখতে হবে।

flowchart TB
        accTitle: আক্রমণের পরে ব্যাকআপ থেকে রিস্টোরের ক্রম
        accDescr: এই চিত্রে দেখানো হয়েছে যে ransomware ও অনুপ্রবেশের পথ সরিয়ে, সংক্রমণের আগের সময়ের ব্যাকআপ বেছে, তাতে ম্যালওয়্যার আছে কি না পরীক্ষা করে, তারপর উচ্চ অগ্রাধিকারের সিস্টেম থেকে রিস্টোর করতে হয়।
        A["Ransomware সরানো"] --> B["অনুপ্রবেশের পথ ও ব্যবস্থা খোঁজা"]
        B --> C["সংক্রমণের আগের সময়বিন্দু বাছা"]
        C --> D["ব্যাকআপ পরীক্ষা করা"]
        D --> E["উচ্চ অগ্রাধিকার থেকে রিস্টোর"]

চিত্র 8: আক্রমণের পরে আক্রমণকারীর ব্যবস্থা সরিয়ে আর সময়বিন্দুটি সংক্রমণের আগের বলে নিশ্চিত হয়ে তারপর রিস্টোর করুন।

কত ঘন ঘন যাচাই করবেন

IPA-র নির্দেশিকা আর CISA-র গাইড দুটোই রিস্টোর যাচাই “নিয়মিত” করতে বলে, কিন্তু কোনো সংখ্যা দেয় না¹¹⁴। আগে উল্লেখ করা IPA-র ঘটনার প্রতিষ্ঠানটি বছরে দুবার রিস্টোর মহড়া করত³। ব্যবসা কতক্ষণ বন্ধ থাকতে পারে আর রিস্টোর হওয়া সময়বিন্দু কতটা পুরনো হলে চলবে তা ঠিক করুন, এবং এমন ঘন ঘন যাচাই করুন যাতে নিশ্চিত হওয়া যায় যে আপনি সেগুলো পূরণ করতে পারছেন।

প্রথমে যা ঠিক করবেন

এ পর্যন্ত বলা বিষয়গুলো ছোট ও মাঝারি প্রতিষ্ঠানের প্রথমে ঠিক করার বিষয় হিসেবে সংক্ষেপে দেওয়া হলো।

flowchart TB
        accTitle: Ransomware সহ্য করতে পারে এমন ব্যাকআপ ঠিক করার ক্রম
        accDescr: এই চিত্রে ক্রম দেখানো হয়েছে: পরিধি ঠিক করা, কপির জায়গা ও ওভাররাইট করা যায় না এমন কপি ঠিক করা, অনুমতি ও প্রজন্ম ঠিক করা, RTO ও RPO ঠিক করা, এবং রিস্টোর করা যায় কি না যাচাই করা।
        A["পরিধি ঠিক করা"] --> B["কপির জায়গা ঠিক করা"]
        B --> C["ওভাররাইট-অযোগ্য কপি ঠিক করা"]
        C --> D["অনুমতি ও প্রজন্ম ঠিক করা"]
        D --> E["RTO ও RPO ঠিক করা"]
        E --> F["রিস্টোর করা যায় কি না যাচাই"]

চিত্র 9: পরিধি থেকে শুরু করে শেষে রিস্টোরের যাচাই পর্যন্ত সবকিছু একটানা ঠিক করুন।

IPA-র নির্দেশিকার ৪র্থ সংস্করণে শুরুতে মেনে চলার “৫টি তথ্য নিরাপত্তা নিয়ম”-এ “ব্যাকআপ নিন!” যোগ করা হয়েছে, ফলে সেগুলো ৬টি নিয়ম হয়েছে¹⁶। পুরো নির্দেশিকা কীভাবে এগোবেন, তা “Where Should SMEs Start on Security?“-এ সংক্ষেপে দেওয়া আছে। সার্ভার বদলানোর পরিকল্পনা থাকলে “Preparing for Windows Server 2016 End of Support“-ও দেখে নিন।

সম্পর্কিত নিবন্ধ

• Where Should SMEs Start on Security? — A Walkthrough of IPA’s ‘Information Security Guidelines for SMEs,’ 4th Edition
• ভলিউম শ্যাডো কপি (VSS)-এর কৌশল ও প্রয়োগ — ব্যবহারে থাকা ফাইলের ব্যাকআপ কেন নেওয়া যায়
• Preparing for Windows Server 2016 End of Support

তথ্যসূত্র

সম্পর্কিত নিবন্ধ

কাছাকাছি বিষয়ে গভীরে যেতে একই ট্যাগযুক্ত সাম্প্রতিক নিবন্ধ।

সম্পর্কিত বিষয়

এই বিষয়ের কাছাকাছি টপিক পৃষ্ঠা। নিবন্ধ থেকে শুরু করে সংশ্লিষ্ট সেবা ও অন্য নিবন্ধে যাওয়া যাবে।

এই বিষয়ের সাথে সম্পর্কিত সেবা

এই নিবন্ধ নিচের সেবা পৃষ্ঠাগুলোর সঙ্গে যুক্ত। কাছের প্রবেশপথ থেকে দেখে নিন।

প্রায়শ জিজ্ঞাসিত প্রশ্ন

এই নিবন্ধের বিষয়ে পরামর্শে প্রায়ই আসা প্রশ্ন।

ব্যাকআপ নিলে কি ransomware সংক্রমণের পরে সবকিছু রিস্টোর করা যাবে?

প্রায়ই শুধু ব্যাকআপ নেওয়া রিস্টোরের জন্য যথেষ্ট নয়। Japan-এর National Police Agency ২০২৫ সালের প্রথম ছয় মাসের যে ক্ষয়ক্ষতির হিসাব সংকলন করেছে, তাতে ব্যাকআপ নেওয়া ও উত্তর দেওয়া ৪৮টি প্রতিষ্ঠানের মধ্যে ৪১টি আক্রমণের ঠিক আগের অবস্থায় ফিরতে পারেনি। সবচেয়ে সাধারণ কারণ ছিল ব্যাকআপও এনক্রিপ্ট হয়ে যাওয়া। এমন একটি কপি রাখতে হবে যা সংক্রমিত PC ওভাররাইট করতে পারে না, এবং তা থেকে রিস্টোর করা যায় কি না যাচাই করতে হবে।

Windows-এ Previous Versions থাকলে কি আলাদা ব্যাকআপ লাগে?

হ্যাঁ, লাগে। Previous Versions আসলে volume shadow copy, অর্থাৎ মূল ভলিউমেই রাখা পরিবর্তনের অংশ। Microsoft শ্যাডো কপি থেকে টেপের মতো মিডিয়ায় কপি করা ডেটাকেই ব্যাকআপ হিসেবে ধরে। Ransomware কখনো কখনো vssadmin-এর মতো টুল দিয়ে শ্যাডো কপি মুছে দেয়, তাই আলাদা মিডিয়ায় রাখা ব্যাকআপের সঙ্গে মিলিয়ে ব্যবহার করুন।

3-2-1 নিয়ম মানলেই কি ransomware থেকে রক্ষা পাওয়া যায়?

সবসময় নয়। 3-2-1 নিয়ম তিনটি কপি, দুই ধরনের মিডিয়া এবং একটি কপি প্রতিষ্ঠানের বাইরে রাখতে বলে, কিন্তু বাইরের কপিটি অফলাইন বা immutable হতে হবে এমন কথা বলে না। যে ক্লাউড কপিতে সংক্রমিত PC সবসময় লিখতে পারে, সেটিও একইভাবে এনক্রিপ্ট হতে পারে। অফলাইন মিডিয়ায় বা ওভাররাইট করা যায় না এমন স্টোরেজে আরও একটি কপি যোগ করুন।

ব্যাকআপ থেকে রিস্টোর করা যায় কি না, কত ঘন ঘন যাচাই করা উচিত?

IPA-র নির্দেশিকা আর CISA-র গাইড দুটোই "নিয়মিত" বলে, কোনো সংখ্যা দেয় না। IPA-র নির্দেশিকায় এমন একটি ঘটনা আছে যেখানে বছরে দুবার রিস্টোর মহড়া করা একটি কোম্পানি আক্রমণ ধরা পড়ার পাঁচ দিন পরে মূল সিস্টেম আবার চালু করেছিল। ব্যবসা কতক্ষণ বন্ধ থাকতে পারে আর রিস্টোর হওয়া সময়বিন্দু কতটা পুরনো হলে চলবে তা ঠিক করুন, এবং এমন ঘন ঘন যাচাই করুন যাতে নিশ্চিত হওয়া যায় যে আপনি সেগুলো পূরণ করতে পারছেন।

লেখকের প্রোফাইল

নিবন্ধের লেখকের পরিচিতি পৃষ্ঠা।

Go Komura

KomuraSoft LLC-এর প্রতিনিধি

Windows সফটওয়্যার ডেভেলপমেন্ট, প্রযুক্তিগত পরামর্শ ও বাগ তদন্তকে কেন্দ্র করে কাজ করেন; বিদ্যমান সম্পদ রয়ে গেছে এমন প্রকল্পে এবং কারণ সহজে চোখে পড়ে না এমন ব্যর্থতার তদন্তে তাঁর বিশেষ শক্তি রয়েছে।