Cloudflare اکنون در محصولات Authenticated Origin Pulls و Custom Origin Trust Store از احراز هویت پستکوانتومی پشتیبانی میکند. این یعنی شما میتوانید یک ارتباط TLS دوطرفه (mutually authenticated TLS) بین Cloudflare و سرور origin خود داشته باشید که از امضاهای Module-Lattice-Based Digital Signature Algorithm (ML-DSA) برای مقاومت در برابر حملات کوانتومی استفاده میکند 🛡️.
چرا این موضوع مهم است؟ حملات «harvest-now / decrypt-later» باعث میشوند مهاجمان دادههای رمزگذاریشده را امروز جمعآوری کنند و امید داشته باشند که در آینده با کامپیوترهای کوانتومی آنها را رمزگشایی کنند. اما فراتر از آن، پیشرفتهای اخیر در محاسبات کوانتومی خطر شکستن اعتبارنامههای کلاسیک و انجام حملات جعل هویت را جلو میاندازد — و اینجاست که احراز هویت پستکوانتومی وارد عمل میشود.
رسیدن به این قابلیت یک نقطه عطف است: طبق نقشه راه اعلامشده، هدف نهایی رسیدن به امنیت کامل پستکوانتومی تا 2029 است و پشتیبانی از ML-DSA در مسیرِ اولین گامهایی است که برداشته شدهاند.
نکتهای که اغلب جا میماند این است که اتصال بین کاربر نهایی و Cloudflare با اتصال بین Cloudflare و origin فرق دارد. حتی اگر مرورگرها هنوز بهطور گسترده پستکوانتومی نباشند، محافظتِ اتصال بین لبهی Cloudflare و origin شما باعث جلوگیری از جعل هویت سرور یا حملات impersonation میشود؛ مخصوصاً زمانی که از mutual TLS و client certificates استفاده میکنید.
برای پیکربندی کلی، روند در سطح بالا چنین است: کلید/گواهی ML-DSA را تولید کنید یا از راهکارهایی که Cloudflare پشتیبانی میکند استفاده کنید، کلید عمومی یا گواهی را در Custom Origin Trust Store بارگذاری کنید و سپس Authenticated Origin Pulls را فعال کنید تا Cloudflare هنگام اتصال به origin با امضاهای ML-DSA احراز هویت شود. توصیه میشود این مراحل را ابتدا در محیط staging اجرا و تست کنید تا سازگاری و مانیتورینگ را بررسی کنید 🔍.
از نظر مهندسی، مجبور شدیم چند کار مهم انجام دهیم: اضافه کردن پشتیبانی از ML-DSA در لایه TLS، مدیریت چرخهی عمر کلیدها در Custom Origin Trust Store، و بهروزآوری مسیر اعتبارسنجی امضاها. یک چالش عملی، اندازهی امضاها و اثرشان روی handshake و پهنای باند است؛ بنابراین نظارت روی latency و حجم handshakeها هنگام فعالسازی ضروری است.
اعتراف کوچکی داریم: در مسیر پیادهسازی فهمیدیم که برخی از فرآیندهای داخلیِ مدیریت کلید و تستهای سازگاریمان برای امضاهای بزرگتر و فرمتهای جدید کفایت نمیکردند، که باعث شد چند بازنگری در ابزارهای اتوماسیون و تستفریمورک انجام دهیم. این تجربه نشان داد که اجرای پستکوانتومی صرفاً به اضافه کردن الگوریتم جدید خلاصه نمیشود؛ لازم است کل خط لولهی کلید و استقرار بازطراحی و سختافزاری مانند HSM در نظر گرفته شود.
نکات عملی برای تیمهای DevOps / SRE:
– کلیدهای خصوصی ML-DSA را در مکانهای امن (ترجیحاً HSM) نگهداری کنید.
– گردش کلید (key rotation) را در برنامهریزیها بگنجانید و تستهای rollback داشته باشید.
– قبل از فعالسازی در تولید، در staging تستهای handshake و latency را بررسی کنید.
– روی متریکهای TLS handshake، نرخ خطا و اندازهی پیامها حساسیت داشته باشید؛ امضاهای lattice-based ممکن است اندازههای بزرگتری داشته باشند.
– لاگها و alertها را برای شکستهای احراز هویت پیکربندی کنید تا شناسایی و رفع سریع انجام شود ⚙️.
در نقشه راه بعدی، انتظار میرود پشتیبانی پستکوانتومی گسترش یابد تا در نهایت شامل مسیرهای کاربر-به-Cloudflare نیز شود؛ در میانه راه ترکیبهای hybrid (ترکیب الگوریتمهای کلاسیک و پستکوانتومی) احتمالاً بهعنوان راهحل میانی مورد استفاده قرار میگیرند تا سازگاری حفظ شود. پیگیری استانداردهای IETF و خروجیهای NIST برای تطبیق پیادهسازیها حیاتی است.
خلاصه اینکه: اگر میخواهید از جعل هویت و تهدیدات ناشی از کامپیوترهای کوانتومی در برابر ارتباطات بین Cloudflare و origin خود محافظت کنید، حالا امکان فعالسازی احراز هویت پستکوانتومی با ML-DSA فراهم است. پیشنهاد میکنم در یک محیط کنترلشده تست کنید، الزامات کلید و امنیت فیزیکی را تامین کنید و تدابیر مانیتورینگ و گردش کلید را از همین امروز آماده کنید 🚀.
