دریافت گواهی امضای الکترونیکی با CSR؛ راهنمای امن و مستقل
CSR فقط درخواست امضای گواهی است، نه خود گواهی و نه کلید خصوصی. این راهنما مراحل فنی و کنترلهای سازمانی را بدون وابستگی به منوی یک فروشنده توضیح میدهد.
CSR چیست و چه چیزی نیست؟
CSR یا درخواست امضای گواهی، ساختاری استاندارد است که کلید عمومی و اطلاعات هویتی یا فنی درخواستکننده را برای مرجع صدور گواهی حمل میکند و با کلید خصوصی متناظر امضا میشود. RFC 2986 قالب PKCS #10 را تعریف میکند. CSR خود گواهی نهایی نیست، اعتبار حقوقی صادر نمیکند و نباید شامل کلید خصوصی باشد. مرجع صدور پس از کنترل هویت و ضوابط، گواهی را صادر و امضا میکند. بنابراین سه شیء را جدا نگه دارید: کلید خصوصی محرمانه، CSR قابل ارسال و گواهی صادرشده قابل توزیع. [۱] [۲]
امضای الکترونیکی یک کاربرد واحد ندارد. گواهی ممکن است برای امضای سند، احراز هویت کاربر یا سامانه، TLS، مهر سازمانی یا خدمت دولتی درخواست شود و هر کاربرد سیاست، فیلد و محل نگهداری متفاوتی دارد. پیش از تولید CSR، نام دقیق خدمت، شخص حقیقی یا حقوقی، صاحب کلید، سامانه مصرفکننده، الگوریتم مجاز، دوره اعتبار و مرجع صدور مورد قبول را از راهنمای جاری همان خدمت بگیرید. استفاده از یک CSR یا یک کلید برای چند کاربرد نامرتبط، دامنه حادثه و ابهام مسئولیت را زیاد میکند. [۵] [۶]
پیشنیازها را پیش از تولید کلید قفل کنید
یک کاربرگ درخواست بسازید: نام حقوقی و شناسه ملی، نام مسئول، دامنه یا نام سامانه، واحد سازمانی در صورت نیاز، استان و کشور، ایمیل سازمانی، کاربرد گواهی، الگوریتم و اندازه کلید، محیط تولید و تاریخ مورد نیاز. متن دقیق فیلدها باید از مرجع صدور و سامانه مقصد بیاید؛ این مقاله مقدار اجباری ثابتی برای همه مراجع تعیین نمیکند. اگر نام حقوقی یا دامنه اشتباه باشد، اصلاح پس از صدور میتواند نیازمند ابطال و درخواست تازه باشد. شخص دوم باید داده را با مدرک ثبت شرکت یا مالکیت دامنه تطبیق دهد. [۵] [۶]
مالک فرایند، مالک کلید و تأییدکننده درخواست را جدا تعریف کنید. تیم فناوری میتواند عملیات فنی را انجام دهد، اما واحد حقوقی یا صاحب خدمت باید هویت و کاربرد را تأیید کند. مسیر پرداخت هزینه، دریافت توکن یا مراجعه حضوری نیز باید از درگاه رسمی کنترل شود. از ارسال تصویر مدارک، گذرواژه یا فایل کلید در پیامرسان شخصی پرهیز کنید. یک پوشه پرونده با دسترسی محدود بسازید که فرم درخواست، مدرک هویت، رسید، CSR، گواهی عمومی و رویدادهای تمدید یا ابطال را نگه دارد؛ راز کلید در این پوشه قرار نمیگیرد. [۲] [۴]
کلید خصوصی را در همان محیط مصرف ایجاد کنید
اصل امن این است که کلید خصوصی در محیطی ایجاد شود که قرار است از آن استفاده کند و بدون ضرورت قابل توجیه از آن خارج نشود. این محیط میتواند ماژول سختافزاری، توکن، مخزن کلید سیستمعامل یا خدمت مدیریت کلید باشد. راهنمای NIST چرخه عمر کلید را از تولید و فعالسازی تا پشتیبان، بازیابی، تعلیق و نابودی پوشش میدهد. الگوریتم و طول کلید باید با سیاست مرجع صدور و سامانه مقصد سازگار باشد. تولید روی لپتاپ ناشناس یا سرویس اینترنتی رایگان، کنترل مالکیت و محرمانگی را از بین میبرد. [۲] [۴]
اگر پشتیبان کلید مجاز و لازم است، روش رمزگذاری، محل، تعداد نسخه، متولی و آزمون بازیابی را پیش از تولید تعیین کنید. عبارت عبور باید از کانال جدا و تحت دسترسی حداقلی نگهداری شود. ثبت رخداد ایجاد و استفاده کلید، بدون ثبت خود راز، برای رسیدگی لازم است. خروج کارمند، خرابی توکن، گمشدن دستگاه و احتمال افشای کلید سناریوهای از پیش تعریفشده میخواهند. بازیابی آزمایشنشده، پشتیبان قابل اتکا نیست؛ و کلیدی که احتمال افشایش وجود دارد نباید صرفاً با تغییر گذرواژه معتبر فرض شود. [۲] [۴]
CSR را بسازید و پیش از ارسال محتوایش را بازبینی کنید
ابزارهایی مانند OpenSSL میتوانند کلید و CSR را تولید یا از کلید موجود درخواست بسازند. فرمان و قالب تنظیمات به محیط، نسخه نرمافزار و سیاست مرجع بستگی دارد؛ دستور ناشناس را بدون درک مسیر خروجی اجرا نکنید. فایل کلید باید مجوز محدود داشته باشد و CSR میتواند برای بازبینی از محیط خارج شود. پس از تولید، محتوای CSR را با ابزار استاندارد نمایش دهید: subject، نامهای جایگزین، الگوریتم کلید عمومی و امضای درخواست را کنترل کنید. موفقیت فرمان به معنای درستبودن هویت یا کاربرد نیست. [۳] [۱]
هش یا شناسه پرونده CSR را ثبت کنید تا فایل ارسالی با فایل بازبینیشده اشتباه نشود. نام فایل شامل راز نباشد و نسخههای آزمایشی از نسخه نهایی جدا بمانند. اگر سامانه مقصد نام دامنه جایگزین، شناسه خاص یا الگوریتم معین میخواهد، آن را پیش از ارسال در خروجی کنترل کنید. کلید خصوصی را همراه CSR، تیکت یا ایمیل نفرستید؛ مرجع صدور برای امضای گواهی فقط به درخواست و مدارک لازم نیاز دارد. اگر فروشنده چنین درخواستی داشت، فرایند را متوقف و از کانال رسمی مرجع راستیآزمایی کنید. [۱] [۳] [۴]
درخواست را فقط از مرجع و مسیر رسمی ارسال کنید
فهرست مراجع مورد اعتماد و شیوه احراز هویت را از مرکز ریشه و زیرساخت رسمی امضای الکترونیکی ایران کنترل کنید. نشانی شبیه، تبلیغ جستوجویی یا لینک پیامرسان برای بارگذاری مدارک کافی نیست. دامنه، گواهی TLS، اطلاعات تماس، نوع گواهی و کارمزد را با صفحه رسمی تطبیق دهید. فایل CSR، مدارک لازم و رسید را با شناسه پرونده نگه دارید. اگر فرایند حضوری یا توکن فیزیکی دارد، تحویل، سریال، دریافتکننده و تاریخ را ثبت کنید. این راهنما نام منو یا قیمت روز را قطعی اعلام نمیکند چون رویه میتواند تغییر کند. [۵] [۶]
جدایی وظایف را حفظ کنید: یک نفر درخواست را آماده کند، صاحب خدمت هویت و دامنه را تأیید نماید و متولی امنیت صدور و نصب را بازبینی کند. پرداخت باید از حساب و مسیر سازمانی باشد و رسید به پرونده وصل شود. پاسخهای مرجع صدور، درخواست اصلاح و دلیل رد را نسخهدار نگه دارید. اگر CSR تازه تولید شد، روشن کنید کلید قبلی کنار گذاشته شده یا همان کلید استفاده شده است. تولید چند کلید ناشناس و باقیماندنشان روی سیستمها ریسک دسترسی و ابهام در زمان حادثه را افزایش میدهد. [۵] [۲]
پس از صدور: گواهی را با کلید، زنجیره و کاربرد تطبیق دهید
گواهی صادرشده را پیش از نصب بررسی کنید: subject و نامهای جایگزین، شماره سریال، صادرکننده، تاریخ شروع و پایان، کاربرد کلید، الگوریتم و زنجیره اعتماد. سپس تطبیق کلید عمومی گواهی با CSR و کلید خصوصی را با ابزار مناسب همان محیط آزمون کنید. گواهی عمومی قابل توزیع است، اما فایل بستهای که کلید خصوصی را در خود دارد محرمانه باقی میماند. گواهی میانی و ریشه باید از منبع رسمی دریافت شوند. نصب موفق بدون آزمون امضا یا اتصال واقعی، پایان کار نیست. [۳] [۱] [۵]
یک آزمون کمریسک انجام دهید: سند نمونه را امضا یا اتصال آزمایشی را برقرار کنید و سپس اعتبار زنجیره، زمان، هویت نمایشدادهشده و امکان راستیآزمایی را کنترل نمایید. خطای ساعت سیستم، زنجیره ناقص، گواهی اشتباه یا نبود کلید خصوصی میتواند نصب را ظاهراً کامل اما خدمت را ناکارآمد کند. نتیجه آزمون، نسخه نرمافزار، محل نصب، صاحب خدمت و برنامه بازگشت را ثبت کنید. اگر گواهی روی چند سرور نصب میشود، فهرست دارایی و مسئول هر نسخه باید معلوم باشد. [۳] [۲]
تمدید، ابطال و پایان خدمت را از روز اول برنامهریزی کنید
تقویم گواهی فقط تاریخ انقضا نیست. موعد آغاز تمدید، تغییر مشخصات شرکت، تغییر دامنه، جابهجایی مسئول، گمشدن توکن، خرابی کلید و احتمال افشا نقاط تصمیماند. هشدارها را برای مالک اصلی و جانشین بفرستید و رسید تمدید را به گواهی تازه متصل کنید. تصمیم درباره استفاده دوباره از کلید یا تولید کلید جدید باید از سیاست مرجع و ارزیابی ریسک بیاید. گواهی منقضی یا باطلشده از سامانهها حذف و وابستگیها دوباره آزمون شوند؛ اما سابقه عمومی و مدارک رسیدگی طبق سیاست نگهداری باقی بمانند. [۲] [۵]
برای حادثه کلید، مسیر توقف روشن لازم است: قطع استفاده، اطلاع به صاحب خدمت و امنیت، درخواست ابطال از مرجع صدور، تعویض گواهی، بررسی امضاها یا اتصالهای تحت اثر و ثبت درسآموخته. پنهانکردن حادثه با صدور گواهی تازه، دوره معرض خطر را مشخص نمیکند. فهرست گواهیها را ماهانه با داراییهای فعال تطبیق دهید و مورد بدون مالک یا نزدیک انقضا را در صف استثنا قرار دهید. ابطال، تمدید و تعویض سه رویداد متفاوتاند و هرکدام شاهد پایان مخصوص میخواهند. [۲] [۴] [۵]
مرز ژرفبان در پرونده امضای الکترونیکی
در قابلیتهای فعال ژرفبان میتوانید هزینه دریافت یا تمدید گواهی، پرداخت، طرفحساب، پیوست رسید، سطح دسترسی و گردش تأیید مالی را در یک پرونده قابل ردیابی نگه دارید. برای دمو یک درخواست نمونه با مبلغ، مسئول، مدرک و تاریخ انقضا آماده کنید و بررسی نمایید آیا سند و تأیید تا گزارش قابل بازسازی است. کلید خصوصی، عبارت عبور و بسته حاوی راز نباید به پیوست مالی اضافه شود. ژرفبان مخزن اسرار یا مرجع صدور گواهی نیست و این مرز باید در رویه داخلی نوشته شود. [۷] [۸]
صدور CSR، تولید و نگهداری کلید، اتصال مستقیم به مرجع گواهی، امضای سند و مدیریت چرخه گواهی تا وقتی در صفحه امکانات یا پیشنهاد کتبی درج نشدهاند قابلیت فعال فرض نمیشوند. از ابزار تخصصی مورد تأیید مرجع برای عملیات رمزنگاری استفاده کنید و در ژرفبان فقط اثر مالی و مدارک غیرمحرمانه را نگه دارید. اگر هدف شما امضای صورتحساب یا خدمت دولتی خاص است، سازگاری دقیق گواهی، توکن و سامانه مقصد را پیش از قرارداد و با داده آزمایشی تأیید نمایید. [۷] [۸]
منابع مستقیم
- PKCS #10؛ قالب درخواست گواهی RFC Editor / IETF
- راهنمای مدیریت کلید رمزنگاری National Institute of Standards and Technology
- مستند رسمی دستور OpenSSL req OpenSSL Project
- راهنمای مدیریت امن کلید OWASP Foundation
- مرکز دولتی صدور گواهی الکترونیکی ریشه مرکز توسعه تجارت الکترونیکی
- اطلاعرسانی رسمی تجارت و امضای الکترونیکی مرکز توسعه تجارت الکترونیکی
- قابلیتهای فعال ژرفبان ژرفبان
- نقشه راه ژرفبان ژرفبان
تحلیلهای مرتبط
مطالب همموضوع که همین تصمیم را از زاویهٔ دیگری کامل میکنند.
حسابداری ارز دیجیتال و صرافی رمزارز؛ راهنمای مستقل ثبت و کنترل
این راهنما بهجای نسخه ثابت برای همه توکنها، مدل کسبوکار، مالکیت، تعهد به مشتری، مبنای گزارشگری و شواهد هر تراکنش را به یک پرونده قابل بازسازی تبدیل میکند.
خواندن گزارش
نحوه دریافت کلید خصوصی سامانه مودیان مالیاتی
این صفحه موضوع «نحوه دریافت کلید خصوصی سامانه مودیان مالیاتی» را بدون بازنشر مطلب رقبا به یک پرونده اجرایی تبدیل میکند: منبع و تاریخ اثر جدا کنترل میشوند، داده به سند متصل میماند و قابلیت تأییدنشدهای به ژرفبان نسبت داده نمیشود.
خواندن گزارش
دو رخنهٔ مورد سوءاستفاده در ویندوز؛ اولویت امروزِ واحد مالی
مایکروسافت برای دو آسیبپذیری ویندوز، سوءاستفادهٔ واقعی را ثبت کرده و CISA نیز هر دو را به فهرست خود افزوده است. تصمیم امروزِ شرکتهای دارای نسخهٔ آسیبپذیر: تعیین اولویت اصلاح بر اساس دسترسی مالی و تأیید بازگشت عملیات، نه اتکا به امتیاز شدت یا درصد کلی نصب.
خواندن گزارش
کنترل هوش مصنوعی در واحد مالی؛ کدام کار را واگذار کنیم؟
مسئله مدیر مالی انتخاب یک ابزار جذاب نیست؛ باید برای هر کار روشن کند هوش مصنوعی فقط پیشنویس بسازد، در یک پایلوت کنترلشده کمک کند یا تا بازطراحی فرایند متوقف بماند. این راهنما همان تصمیم را با پنج محور ریسک و چند خط قرمز عملی میکند.
خواندن گزارش
پشتیبانی 7/24 در نرمافزار ابری یعنی چه؟
این صفحه موضوع «پشتیبانی 7/24 در نرمافزار ابری یعنی چه؟» را بدون بازنشر مطلب رقبا به یک پرونده اجرایی تبدیل میکند: منبع و تاریخ اثر جدا کنترل میشوند، داده به سند متصل میماند و قابلیت تأییدنشدهای به ژرفبان نسبت داده نمیشود.
خواندن گزارش
مزایا و معایب نرم افزار حسابداری ابری رایگان
این صفحه موضوع «مزایا و معایب نرم افزار حسابداری ابری رایگان» را بدون بازنشر مطلب رقبا به یک پرونده اجرایی تبدیل میکند: منبع و تاریخ اثر جدا کنترل میشوند، داده به سند متصل میماند و قابلیت تأییدنشدهای به ژرفبان نسبت داده نمیشود.
خواندن گزارشخلاصه را سریع ببینید؛ گزارش کامل را با یک لمس باز کنید
هر پست با تصویر اختصاصی، دو دلیل اهمیت، یک اقدام مدیریتی، یک مورد قابل رصد و مسیر مستقیم به متن کامل و منابع منتشر میشود.