Post-quantum migration শুরু করুন inventory দিয়ে—algorithm দিয়ে নয়
Post-quantum cryptography migration-এর শুরুতে নতুন algorithm বাছাই বা production system বদলানোর প্রয়োজন নেই। প্রথম ৯০ দিনে কোথায় public-key cryptography ব্যবহৃত হচ্ছে, কোন ডেটা দীর্ঘদিন গোপন রাখতে হবে, পরিবর্তন কোন vendor-এর ওপর নির্ভরশীল এবং production-এর বাইরে কীভাবে সামঞ্জস্য পরীক্ষা করা যাবে—এসবের প্রমাণভিত্তিক মানচিত্র তৈরি করুন।
এই পর্যায়ের ফল হবে owner-সহ cryptographic inventory, ঝুঁকি অনুযায়ী সাজানো workload, vendor roadmap, lab test-এর evidence এবং ব্যর্থ হলে আগের অবস্থায় ফেরার পরিকল্পনা। NIST-এর PQC নির্দেশনা বলছে, তিনটি finalized standard এখন implementation-এর জন্য প্রস্তুত; একই সঙ্গে প্রতিষ্ঠানকে quantum-vulnerable algorithm কোথায় ব্যবহৃত হচ্ছে তা শনাক্ত করে সেগুলো বদলানো বা হালনাগাদের পরিকল্পনা করতে হবে। Standard প্রস্তুত থাকলেও তাই migration-এর প্রথম সাংগঠনিক কাজ discovery।
৯০ দিনের সীমা ও দায়িত্ব আগে স্থির করুন
CTO বা senior risk owner-কে sponsor এবং security বা platform lead-কে migration owner করুন। ছোট দলে আলাদা programme office দরকার নেই, তবে infrastructure, application, procurement, compliance ও business continuity বিষয়ে সিদ্ধান্ত দিতে পারবেন—এমন যোগাযোগ ব্যক্তি নির্ধারিত থাকতে হবে।
একটি evidence register খুলুন। প্রতিটি সিদ্ধান্তের পাশে configuration export, certificate sample, vendor document, test log বা দায়িত্বশীল ব্যক্তির লিখিত নিশ্চিতকরণ রাখুন। শুধু spreadsheet-এ “PQC-ready” লিখে রাখাকে evidence হিসেবে ধরবেন না।
প্রাথমিক scope-এ internet-facing service, internal identity, cloud ও managed service, mobile application, backup এবং code-signing pipeline রাখুন। ৯০ দিনের success criterion হবে: গুরুত্বপূর্ণ service-এর cryptographic path জানা, long-lived data আলাদা করা, vendor-নির্ভর কাজের লিখিত অবস্থা পাওয়া এবং অন্তত একটি প্রতিনিধিত্বমূলক flow বিচ্ছিন্ন lab-এ পরীক্ষা করা। এটি নিজস্ব cryptographic algorithm বা implementation তৈরির অনুমতি নয়।
দিন ১–৩০: owner-সহ cryptographic inventory বানান
Business service থেকে নিচের দিকে খোঁজা শুরু করুন। Customer login, payment integration, API gateway, VPN, SSH access, certificate issuance, document signature, software update ও backup restore কোন system এবং vendor component-এর ওপর চলে তা লিখুন। এরপর configuration, certificate store, cloud KMS বা HSM metadata, dependency manifest, network observation এবং vendor console থেকে ব্যবহৃত cryptography শনাক্ত করুন।
প্রতি inventory row-তে service ও technical owner, environment, protocol, cryptographic function, algorithm বা key-establishment পদ্ধতি, library ও version, certificate issuer, key location, vendor, data in transit বা at rest, lifecycle এবং evidence সংগ্রহের তারিখ রাখুন। “TLS আছে” যথেষ্ট নয়; endpoint, client population, termination point এবং downstream connection আলাদা করে ধরতে হবে।
NCCoE-এর migration project cryptographic discovery এবং NIST-standardized PQC interoperability testing-কে দুটি workstream হিসেবে নিয়েছে। Project-টি inventory দিয়ে risk ও implementation priority নির্ধারণ এবং compatibility সমস্যা controlled, non-production environment-এ চিহ্নিত করার কথা বলেছে। তাই scanner-এর ফলকে চূড়ান্ত তালিকা না ধরে architecture review ও owner confirmation-এর সঙ্গে মিলিয়ে প্রতিটি finding-কে confirmed, probable বা unknown হিসেবে চিহ্নিত করুন।
এই পর্যায়ে সব symmetric encryption-কে quantum-vulnerable হিসেবে চিহ্নিত করবেন না। কোথায় public-key cryptography key establishment, digital signature, certificate, authentication বা key wrapping-এ যুক্ত আছে, সেটিই খুঁজুন। কোনো service নির্ধারিত সময়ের মধ্যে অবসর নিলে migration-এর বদলে retirement পরিকল্পনা করা যেতে পারে, তবে তার তারিখ ও owner লিখিত থাকতে হবে।
দিন ৩১–৬০: ডেটা ও vendor dependency দিয়ে অগ্রাধিকার দিন
Inventory-কে data register-এর সঙ্গে যুক্ত করুন। প্রতিটি service-এর জন্য ডেটার ধরন, retention period, প্রয়োজনীয় confidentiality period, disclosure-এর business বা regulatory প্রভাব এবং encrypted copy এখন সংগ্রহ করে ভবিষ্যতে পড়ার চেষ্টা করা প্রতিপক্ষের কাছে মূল্যবান হতে পারে কি না—এসব নথিভুক্ত করুন। নির্দিষ্ট quantum computer কবে আসবে, সেই অনুমানের ওপর নির্ভর না করেও দীর্ঘমেয়াদি সংবেদনশীল ডেটাকে আগে রাখা যায়।
তিনটি কাজের queue রাখা যেতে পারে: দীর্ঘমেয়াদি confidentiality বা critical trust-এর জন্য উচ্চ অগ্রাধিকার; routine vendor upgrade-নির্ভর service-এর জন্য পর্যবেক্ষণ; এবং নির্ধারিত সময়ের মধ্যে বন্ধ হবে এমন system-এর জন্য retirement। এটি সার্বজনীন risk formula নয়। প্রতিষ্ঠানের চুক্তি, sector obligation, outage tolerance ও data-retention নিয়ম অনুযায়ী classification অনুমোদন করাতে হবে।
Managed service, cloud, payment gateway, certificate authority, HSM, VPN ও application vendor-কে একই questionnaire পাঠান। তাদের পণ্যে quantum-vulnerable public-key cryptography কোথায় আছে, কোন NIST-standardized capability কোন release-এ আসবে, supported protocol ও client কী, transition mode থাকবে কি না, validation evidence কী, negotiated method telemetry-তে দেখা যাবে কি না এবং fallback ও rollback কীভাবে কাজ করবে—এসব জানতে চান।
যুক্তরাজ্যের NCSC migration guidance discovery-তে data lifetime ও service-provider dependency ধরতে এবং migration plan-এ testing, business continuity ও rollback রাখতে বলেছে। একই guidance অনুযায়ী, বিশেষজ্ঞ cryptographer থাকা অল্প কিছু প্রতিষ্ঠান ছাড়া অধিকাংশ সংস্থা ও supplier-এর নিজস্ব PQC implementation তৈরি করা উচিত নয়; certified implementation ও trusted library-এর ওপর পরিকল্পনা করতে হবে। তাই vendor-এর marketing claim-কে committed delivery না ধরে roadmap-এর version, প্রকাশের তারিখ, দায়ী contact এবং পরবর্তী review date লিখে রাখুন।
দিন ৬১–৯০: lab-এ interoperability ও rollback পরীক্ষা করুন
Production traffic নয়, একটি প্রতিনিধিত্বমূলক flow বেছে নিন—যেমন test API client থেকে gateway হয়ে backend service। পুরোনো ও হালনাগাদ client, server, proxy, certificate chain, load balancer এবং monitoring-এর প্রয়োজনীয় অংশ lab-এ রাখুন, যাতে শুধু algorithm নয়, পুরো dependency path পরীক্ষা হয়।
Test plan-এ successful negotiation-এর পাশাপাশি certificate ও message size, handshake failure, CPU ও memory behaviour, timeout, library error, observability এবং পুরোনো peer-এর সঙ্গে compatibility লিখুন। নতুন capability ব্যর্থ হলে system নিঃশব্দে classical method-এ নেমে যাচ্ছে কি না, তা আলাদাভাবে যাচাই করুন। Service সচল থাকলেই PQC negotiation সফল হয়েছে বলা যায় না।
Rollback-কে পৃথক test case করুন। কোন configuration বা release ফিরবে, key ও certificate state কীভাবে পুনরুদ্ধার হবে, কে সিদ্ধান্ত নেবে, কত সময়ের outage গ্রহণযোগ্য এবং rollback-এর audit evidence কোথায় থাকবে—এসব rehearsal-এ যাচাই করুন। Production pilot বিবেচনার আগে monitoring alert এবং প্রয়োজনীয় backup restore path-ও lab evidence-এ থাকা উচিত।
দিন ৯০-এ যে roadmap হাতে থাকবে
চূড়ান্ত roadmap-এর প্রতিটি row একটি service বা dependency নির্দেশ করবে। সেখানে priority, owner, বর্তমান cryptography, target capability, vendor prerequisite, test evidence, change window, rollback path এবং পরবর্তী decision date রাখুন। সিদ্ধান্তের অবস্থা হতে পারে lab test চালিয়ে যাওয়া, vendor release-এর জন্য অপেক্ষা, platform বদল, service retire করা বা controlled pilot প্রস্তাব করা।
নিচের যেকোনো অবস্থা থাকলে production migration থামান:
- উচ্চ-মূল্যের বা দীর্ঘমেয়াদি ডেটার cryptographic path অসম্পূর্ণ;
- service owner বা rollback authority নির্ধারিত নয়;
- vendor শুধু অস্পষ্ট “quantum-safe” দাবি দিয়েছে, কিন্তু supported standard ও release জানায়নি;
- পুরোনো client, certificate chain বা downstream service-এর compatibility অজানা;
- test-এ silent fallback ধরা পড়ছে বা negotiated method পর্যবেক্ষণ করা যাচ্ছে না;
- backup restore, incident response বা প্রয়োজনীয় compliance approval যাচাই হয়নি।
এই stop-condition ব্যর্থতা নয়; এটি migration-কে নিয়ন্ত্রিত রাখার ব্যবস্থা। প্রথম ৯০ দিনের সবচেয়ে মূল্যবান ফল নতুন algorithm চালু করা নয়, বরং কোন system কখন, কার অনুমোদনে, কোন vendor capability ও পরীক্ষার evidence-এর ভিত্তিতে বদলাবে—তার নির্ভরযোগ্য সিদ্ধান্তপথ তৈরি করা।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।