امنیت

مهاجرت Post-Quantum یک ضرب‌الاجل آرام دارد: قبل از اضطراب، همه چیز را فهرست کنید

استانداردها دیگر تئوری نیستند، اما سخت‌ترین کار عوض‌کردن یک الگوریتم نیست؛ پیدا کردن همه certificateها، protocolها، libraryها، deviceها و وابستگی‌های vendor است.

سینا فرزان
سینا فرزان

نویسنده امنیت و کسب‌وکار دیجیتال

۱۱ تیر ۱۴۰۵5 دقیقه مطالعه
مهاجرت Post-Quantum یک ضرب‌الاجل آرام دارد: قبل از اضطراب، همه چیز را فهرست کنید

چرا الان مهم است

مهاجرت به رمزنگاری post-quantum دیگر موضوعی مخصوص چند متخصص نیست؛ به یک سؤال عملیاتی برای مدیریت محصول و کسب‌وکار تبدیل شده است. NIST اولین استانداردهای رمزنگاری post-quantum را نهایی کرده و نهادهای امنیتی حالا توصیه می‌کنند دارایی‌های رمزنگاری فهرست شوند، چون داده‌ای که امروز دزدیده می‌شود ممکن است بعداً رمزگشایی شود. معنی‌اش این نیست که همه باید وحشت کنند، اما یعنی فرض قدیمی که «زیرساخت خودش درست می‌شود» دیگر کافی نیست.

اهمیت ماجرا از اینجاست که ریسک این نیست که فردا همه سیستم‌ها می‌شکنند؛ ریسک این است که کسی نداند کدام سیستم‌ها باید اول تغییر کنند. تیم‌های محصول معمولاً این را دیر می‌فهمند. جلسه لانچ درباره فیچر، قیمت و رشد حرف می‌زند، اما محدودیت واقعی ممکن است در permission، بازیابی حساب، برق، certificate، vendor یا پشتیبانی پنهان باشد.

برای تیم‌های امنیت، مدیران زیرساخت، CIOها، auditorها و تیم‌های محصول با داده بلندعمر تغییر اصلی ساده است: تصمیم فنی حالا تبدیل به وعده قابل لمس به کاربر می‌شود. ورود امن یعنی بازیابی قابل فهم. عامل AI یعنی اختیار محدود. دیتاسنتر یعنی برق و سرمایش قابل اتکا. رمزنگاری یعنی محرمانگی امروز و فردا.

برای شرکت‌های فارسی‌زبان، اهمیت موضوع در سرویس‌های مالی، سلامت، قراردادهای بلندمدت، داده‌های آرشیوی و نرم‌افزارهایی است که سال‌ها بدون تغییر جدی کار می‌کنند. به همین دلیل این موضوع فقط یک خبر تکنولوژی نیست. روی بودجه، زمان تحویل، متن پشتیبانی، قرارداد خرید و نحوه توضیح ریسک به مشتری اثر می‌گذارد.

مقاله‌های مرتبط

دیتاسنترهای هوش مصنوعی به گلوگاه تازه رسیده‌اند: برق، خنک‌سازی و اعتماد محلی

واقعیت محصول پشت تیتر خبر

اولین واقعیت این است که تکنولوژی انتزاعی فقط وقتی دردناک می‌شود که به workflow واقعی برسد. تا وقتی همه‌چیز کار می‌کند کسی سراغ معماری نمی‌رود. مشکل وقتی شروع می‌شود که حساب برنگردد، مدل scale نشود، agent کار اشتباه انجام دهد یا vendor جواب امنیتی روشن نداشته باشد.

واقعیت دوم وابستگی است. محصول دیجیتال امروز روی regionهای cloud، provider هویت، مدل AI، مرورگر، API، certificate، موبایل و تیم پشتیبانی سوار است. یک فیچر ساده روی صفحه ممکن است زنجیره‌ای پیچیده زیر خود داشته باشد.

واقعیت سوم اعتماد است. کاربر محدودیت روشن را راحت‌تر از شکست مبهم می‌پذیرد. اگر محصول بگوید چه چیزی مجاز است، چه چیزی مسدود می‌شود، بازیابی چطور انجام می‌شود و مسئول کیست، حس طراحی‌شده بودن می‌دهد. اگر این جواب‌ها بعد از incident پیدا شوند، محصول بداهه به نظر می‌رسد.

برای همین باید یک فهرست رمزنگاری بسازید، داده‌ها را بر اساس عمر حساسیت رتبه‌بندی کنید، از vendorها برنامه بخواهید، hybrid mode را تست کنید و مهاجرت مرحله‌ای بچینید. این کاغذبازی نیست؛ راه تبدیل ابهام به مدل عملیاتی قابل مدیریت است.

شکست‌هایی که آرام شروع می‌شوند

شکست‌های خطرناک معمولاً با بحران بزرگ شروع نمی‌شوند. با استثنا شروع می‌شوند: حساب ویژه، راه‌حل موقت vendor، تغییر دستگاه، محدودیت ظرفیت region، permissionی که در تست داده شد و بعد کسی آن را پس نگرفت.

حالت دوم، کوری متریک است. تیم ممکن است adoption را اندازه بگیرد اما recoverability، فشار پشتیبانی، مصرف انرژی، عمل برگشت‌ناپذیر، drift امنیتی یا آمادگی vendor را نبیند. متریک کاربردی اینجاست: درصد سیستم‌های حیاتی که وابستگی رمزنگاری و مالک مهاجرت مشخص دارند.

حالت سوم زبان سازمانی است. اگر مدیران سیستم را ساده توصیف کنند ولی اپراتورها بدانند شکننده است، سازمان شروع می‌کند به فریب دادن خودش. زبان خوب باید عدم قطعیت را نام‌گذاری کند بدون اینکه تیم را فلج کند.

حالت چهارم اعتمادبه‌نفس بیش از حد است. دمو اول که کار کرد، سیستم آماده نیست. آمادگی واقعی یعنی سیستم بتواند degrade شود، توضیح بدهد، اعتماد کاربر را حفظ کند و وقتی فرض‌ها شکستند، قابل بازیابی باشد.

برنامه عملی ۹۰ روزه

در ۳۰ روز اول سطح تماس را نقشه‌برداری کنید. بنویسید موضوع کجا به کاربر، ابزار داخلی، داده، vendor، زیرساخت، پشتیبانی و compliance وصل می‌شود. هدف اسلاید زیبا نیست؛ هدف inventory مشترکی است که حتی آدم‌های نگران هم بگویند دقیق است.

از روز ۳۱ تا ۶۰ control point تعریف کنید. کدام تغییر review می‌خواهد؟ کدام مسیر کاربر fallback لازم دارد؟ کدام vendor باید جواب مکتوب بدهد؟ چه اتفاقی rollback را فعال می‌کند؟ چه logی قبل از لانچ باید وجود داشته باشد؟

از روز ۶۱ تا ۹۰ failure rehearsal اجرا کنید. گم شدن دستگاه، مسدود شدن region، tool injection، تاخیر vendor، وابستگی certificate یا کمبود ظرفیت را شبیه‌سازی کنید. هدف ترساندن تیم نیست؛ هدف ساختن حافظه عملیاتی است.

در پایان این چرخه، سازمان باید بداند مالک چیست، به چه چیزی وابسته است، چه چیزی را می‌تواند برگرداند و چه چیزی را باید برای کاربر توضیح دهد. همین شفافیت یک trend بزرگ را به roadmap قابل اجرا تبدیل می‌کند.

مزیت پایدار از کجا می‌آید

مزیت پایدار معمولاً شبیه پرصداترین لانچ نیست. شبیه تیمی است که می‌تواند منتشر کند، ببیند، توضیح بدهد، بازیابی کند و بهتر شود بدون اینکه همه اطراف محصول را فرسوده کند.

مشتری‌ها بیشتر از قبل evidence می‌خرند، نه فقط قابلیت. می‌خواهند بدانند تصمیم‌ها چطور log می‌شوند، vendor چطور ارزیابی شده، بازیابی چطور کار می‌کند، هزینه چطور کنترل می‌شود و شرکت وقتی سیستم به مرز می‌رسد چه رفتاری دارد.

سؤال مدیریتی ساده است: اگر فرض اصلی تغییر کند، شرکت هنوز می‌تواند وعده‌اش را نگه دارد؟ اگر جواب وابسته به قهرمانی پنهان چند نفر است، سیستم بالغ نیست. اگر وابسته به کنترل‌های مستند است، محصول در حال تبدیل شدن به زیرساخت واقعی است.

سازمان آرام‌تر آن نیست که شعار quantum بزرگ‌تری دارد؛ سازمانی است که inventory تمیزتری دارد.

خبر خوب، خبری است که کاربر بعد از خواندن آن تصمیم بهتری بگیرد.
NovaNews
رمزنگاری post-quantumNISTامنیت سایبریcryptographic inventoryمهاجرت امنیتی

درباره نویسنده

سینا فرزان

سینا فرزان

نویسنده امنیت و کسب‌وکار دیجیتال

سینا روی امنیت سایبری، بلاک‌چین، اعتماد دیجیتال و کاربرد فناوری در کسب‌وکارهای کوچک تمرکز دارد.

مقاله‌های مرتبط