step-ca در زیرساخت داخلی چه نقشی دارد؟
step-ca مرجع صدور گواهی آنلاین و متن‌باز پروژه Smallstep است. این سرویس برای صدور و مدیریت خودکار گواهی در زیرساختی به کار می‌رود که سازمان می‌خواهد مرز اعتماد آن را خودش تعریف کند. ابزار خط فرمان step نقش کارخواه و مجموعه ابزار کار با کلید و گواهی را دارد؛ step-ca بخش سرور این مجموعه است. اشتباه گرفتن این دو نام ممکن است باعث شود نصب ابزار خط فرمان با راه‌اندازی یک مرجع صدور آماده بهره‌برداری یکسان فرض شود.
نمونه روشن کاربرد، مجموعه‌ای از سرویس‌های داخلی است که باید با ارتباط رمزگذاری‌شده و هویت قابل بررسی با هم گفتگو کنند. صدور گواهی خودامضا برای هر سرویس، توزیع اعتماد و تعویض گواهی را دشوار می‌کند. یک مرجع خصوصی می‌تواند این رابطه را سامان دهد، به شرط آنکه دستگاه‌های مصرف‌کننده ریشه درست را بشناسند و تنها متقاضیان مجاز بتوانند گواهی بگیرند. گواهی صادرشده از مرجع خصوصی به صورت خودکار در همه مرورگرها و سیستم‌عامل‌ها معتبر شناخته نمی‌شود.
فرض کنید تیمی پنل داخلی، سامانه گزارش و رابط پایگاه داده دارد. هدف نخست می‌تواند صدور گواهی برای نام‌های مشخص این سه سرویس و تمدید خودکار آن‌ها باشد. بهتر است در شروع، تمام شبکه سازمان و تمام کاربران وارد دامنه پروژه نشوند. یک محدوده کوچک امکان می‌دهد خطای نام میزبان، توزیع ریشه، رفتار تمدید و راه‌اندازی مجدد سرویس مقصد بررسی شود و سپس الگو به بخش‌های دیگر گسترش یابد.
زنجیره اعتماد و حفاظت از ریشه
در معماری رایج دو سطحی، گواهی ریشه نقطه اعتماد است و یک مرجع میانی کار صدور روزمره را انجام می‌دهد. خصوصی بودن کلید ریشه اهمیت بنیادی دارد؛ داشتن گواهی عمومی ریشه برای بررسی زنجیره لازم است، اما داشتن کلید خصوصی آن امکان ساخت اعتماد تازه می‌دهد. این دو فایل را در مستندات و محل نگهداری به روشنی جدا کنید. شباهت نام فایل‌ها نباید باعث شود کلید خصوصی همراه بسته نصب اعتماد میان کارخواه‌ها توزیع شود.
README رسمی امکان استفاده از step-ca به عنوان مرجع میانی زیر ریشه موجود را توضیح می‌دهد. این انتخاب برای سازمانی که قبلاً زیرساخت کلید عمومی دارد قابل بررسی است. پیش از اتصال، محدودیت نام‌ها، طول زنجیره، زمان اعتبار و سیاست صدور باید با مالک ریشه هماهنگ شود. اجرای موفق یک فرمان امضا به تنهایی نشان نمی‌دهد مرجع جدید از نظر سیاست سازمان مجاز است.
نگهداری ریشه خارج از مسیر صدور روزمره به کاهش سطح دسترسی کمک می‌کند، ولی برای بازیابی نیز باید برنامه داشت. اگر کلید میانی یا میزبان صدور آسیب ببیند، تیم باید بداند چگونه صدور را متوقف می‌کند، مرجع جایگزین می‌سازد و اعتماد لازم را منتقل می‌کند. این تصمیم‌ها را قبل از گسترش به صدها سرویس بگیرید؛ تغییر اعتماد پس از فراگیر شدن، یک عملیات هماهنگ میان چندین تیم خواهد بود.
نصب و راه‌اندازی آزمایش اولیه
نسخه ابزار سرور و ابزار خط فرمان را از مسیر رسمی دریافت و ثبت کنید. هنگام استفاده از بسته یا تصویر کانتینر، منبع و نسخه را در پیکربندی نگه دارید تا نتیجه قابل بازسازی باشد. استفاده از برچسب شناور ممکن است در راه‌اندازی مجدد رفتار متفاوتی ایجاد کند. ابتدا راهنمای نصب متناسب با سیستم‌عامل را دنبال کنید و مطمئن شوید هر دو فرمان مورد نیاز در محیط آزمایش در دسترس هستند.
در آزمایش اولیه، فرمان راه‌اندازی تعاملی می‌تواند فایل‌های پیکربندی و مواد لازم را ایجاد کند. نام مرجع، نام‌های قابل دسترسی سرور و نشانی شنود باید آگاهانه انتخاب شوند. نشانی‌ای که فقط از داخل کانتینر معتبر است برای کارخواه بیرونی مناسب نیست. همچنین نامی که در گواهی سرور آمده باید با نشانی مورد استفاده کارخواه سازگار باشد. اطلاعات رمز عبور را در اسکریپت عمومی یا مخزن ثبت نکنید.
step ca init
step-ca "$(step path)/config/ca.json"
این دو فرمان فقط نمونه آغاز یک محیط آزمایشی هستند. برای بهره‌برداری، حساب سرویس، مجوز فایل‌ها، روش تأمین رمز، ذخیره‌سازی پایدار، ثبت گزارش و راه‌اندازی پس از بازنشانی میزبان باید جداگانه طراحی شوند. فایل پیکربندی تولیدشده را پیش از اجرا بخوانید و مسیرهای کلید و پایگاه داده را شناسایی کنید. پاک شدن کانتینر نباید به از دست رفتن بی‌برنامه وضعیت مرجع منجر شود.
راه‌اندازی اعتماد در کارخواه
کارخواه باید مطمئن شود ریشه‌ای که دریافت می‌کند همان ریشه مورد تأیید سازمان است. اثرانگشت ریشه می‌تواند از یک کانال مستقل و معتبر توزیع شود و هنگام bootstrap بررسی شود. اگر نشانی سرور و اثرانگشت هر دو از یک پیام ناشناس دریافت شوند، استفاده از اثرانگشت به تنهایی اعتماد تازه‌ای ایجاد نمی‌کند. مسئول زیرساخت باید محل انتشار رسمی این اطلاعات را مشخص کند.
نصب ریشه در یک محل به معنای شناخته شدن آن در همه برنامه‌ها نیست. برخی برنامه‌ها از مخزن اعتماد سیستم‌عامل استفاده می‌کنند و برخی محیط اجرای خود را دارند. مرورگر، ماشین مجازی زبان برنامه‌نویسی و کانتینر ممکن است مسیرهای جداگانه داشته باشند. در آزمون پذیرش دقیقاً همان برنامه‌ای را اجرا کنید که در تولید ارتباط را برقرار می‌کند. موفقیت ابزار خط فرمان روی میزبان لزوماً موفقیت برنامه داخل کانتینر را اثبات نمی‌کند.
در تغییر ریشه، دوره هم‌پوشانی اعتماد می‌تواند لازم باشد تا کارخواه‌ها پیش از دریافت گواهی‌های زنجیره جدید آماده شوند. ترتیب توزیع ریشه و تغییر صدور اهمیت دارد. برای هر گروه کارخواه، مالک و روش به‌روزرسانی ثبت کنید. دستگاهی که ماه‌ها خاموش بوده یا تصویر قدیمی کانتینر دارد ممکن است بعداً با اعتماد قدیمی برگردد؛ برنامه مهاجرت باید این حالت را نیز در نظر بگیرد.
مجوز صدور و نقش provisioner
Provisioner در step-ca سازوکاری برای احراز و مجاز کردن درخواست صدور است. منابع رسمی چند روش از جمله توکن کوتاه‌عمر، هویت سازمانی، هویت ماشین ابری و ACME را معرفی می‌کنند. انتخاب روش باید با نوع متقاضی هماهنگ باشد. کاربر انسانی، ماشین خودکار و سرویس وب مسئله یکسانی ندارند. روش مناسب باید مشخص کند متقاضی چگونه شناخته می‌شود و اجازه درخواست چه نام یا هویتی را دارد.
احراز هویت به تنهایی پاسخ کامل نیست. ممکن است یک کاربر معتبر سازمان نباید برای نام سرویس مالی گواهی بگیرد. بنابراین محدودیت نام، نقش و سیاست صدور را جداگانه بازبینی کنید. آزمون منفی درخواست یک نام خارج از محدوده اهمیت زیادی دارد. اگر درخواست پذیرفته شد، مسئله با کوتاه کردن زمان اعتبار حل نمی‌شود؛ مجوز صدور باید اصلاح شود.
در خودکارسازی، توکن اولیه یا اعتبارنامه ثبت‌نام نباید به راز دائمی مشترک میان تمام ماشین‌ها تبدیل شود. مسیر دریافت هویت، عمر آن و محل نگهداری باید مشخص باشد. برای بازسازی یک ماشین از تصویر پایه نیز همین مسیر باید امن و قابل تکرار باقی بماند. حذف ماشین از شبکه باید همراه با بررسی امکان دریافت گواهی تازه از هویت قبلی آن باشد.
ACME خصوصی و انتخاب چالش
step-ca می‌تواند سرور ACME خصوصی باشد و به کارخواه‌های سازگار امکان دریافت و تمدید گواهی بدهد. خصوصی بودن سرور به معنای حذف اثبات کنترل نام نیست. در روش چالش وب، مرجع باید بتواند به پاسخ مورد انتظار دسترسی پیدا کند؛ در روش مبتنی بر DNS باید رکورد لازم در دید درست سامانه نام وجود داشته باشد. شبکه داخلی، پراکسی و DNS دوگانه می‌توانند باعث تفاوت دید مرجع و کارخواه شوند.
برای انتخاب چالش، مسیر دسترسی واقعی را رسم و آزمایش کنید. اگر سرویس پشت متوازن‌کننده بار است، پاسخ چالش باید به گره درست برسد یا میان گره‌ها هماهنگ باشد. اگر تغییر رکورد DNS خودکار می‌شود، مجوز آن اعتبارنامه را به محدوده لازم کاهش دهید. اعتبارنامه‌ای که برای تمدید گواهی استفاده می‌شود نباید بی‌دلیل امکان تغییر تمام منطقه‌های نام سازمان را داشته باشد.
آزمون موفق صدور نخست کافی نیست. درگاه، مسیر یا رکوردی که هنگام نصب موقتاً باز شده ممکن است در تمدید بعدی وجود نداشته باشد. تمدید را با همان حساب سرویس و همان شبکه زمان بهره‌برداری اجرا کنید. گزارش کارخواه و مرجع باید امکان تشخیص مرحله شکست را بدهند: ارتباط، احراز، چالش، صدور یا نصب گواهی. هر مرحله راه بررسی متفاوتی دارد.
تمدید و بارگذاری گواهی تازه
گواهی کوتاه‌عمر بدون تمدید مطمئن می‌تواند به منبع قطعی تبدیل شود. برنامه باید پیش از انقضا اقدام کند و برای خطاهای موقت فرصت تکرار داشته باشد. زمان باقی‌مانده گواهی نصب‌شده را پایش کنید، نه فقط موفقیت آخرین اجرای یک وظیفه زمان‌بندی‌شده. ممکن است گواهی تازه روی دیسک نوشته شده باشد اما برنامه همچنان نسخه قبلی را در حافظه نگه داشته باشد.
پس از تمدید، روش بارگذاری مجدد سرویس مقصد اهمیت دارد. برخی سرویس‌ها فایل را دوباره می‌خوانند و برخی نیازمند فرمان مدیریتی یا راه‌اندازی مجدد هستند. تغییر فایل باید طوری انجام شود که برنامه جفت ناسازگار کلید و گواهی نبیند. در آزمایش، از یک کارخواه مستقل به سرویس متصل شوید و گواهی ارائه‌شده واقعی را بررسی کنید؛ نگاه کردن به فایل محلی کافی نیست.
برای خوشه چندگرهی، هر گره ممکن است کلید و گواهی جداگانه داشته باشد. پایش تنها یک نشانی عمومی می‌تواند انقضای گره‌ای کم‌استفاده را پنهان کند. وضعیت تمام گره‌ها را بررسی کنید و رفتار هنگام خارج شدن موقت یک گره از شبکه را تمرین کنید. پس از بازگشت، گره نباید با گواهی منقضی‌شده وارد مسیر ترافیک شود.
ابطال، انقضا و محدودیت محصول
README رسمی میان پروژه متن‌باز و محصول تجاری Smallstep تمایز می‌گذارد و نباید تمام قابلیت‌های تبلیغ‌شده محصول تجاری را به step-ca نسبت داد. به‌ویژه نیاز به ابطال فعال و سازوکارهایی مانند OCSP یا CRL باید بر اساس مستندات نسخه و قابلیت دقیق ارزیابی شود. وجود یک فرمان ابطال به تنهایی ثابت نمی‌کند تمام کارخواه‌ها فوراً گواهی صادرشده را رد می‌کنند.
در طراحی متکی به گواهی کوتاه‌عمر، پایان اعتبار بخشی از کنترل ریسک است، اما جایگزین پاسخ فوری همه سناریوها نیست. اگر کلید یک سرویس افشا شد، باید دسترسی آن سرویس، امکان صدور مجدد و مسیرهای شبکه را نیز بررسی کرد. نیاز سازمان به توقف فوری اعتماد ممکن است بر انتخاب معماری یا محصول اثر بگذارد. این نیاز را پیش از انتخاب زمان اعتبار مطرح کنید.
SSH و کاربردهای جداگانه
منابع رسمی صدور گواهی SSH برای کاربر و میزبان را نیز توضیح می‌دهند. این کاربرد با گواهی TLS یکسان نیست و تنظیمات اعتماد در سرور و کارخواه SSH مسیر خاص خود را دارد. برای کاربران، نگاشت هویت به principal و سیاست ورود باید روشن باشد. برای میزبان‌ها، نام و اعتماد به مرجع میزبان اهمیت دارد. فعال کردن یک نوع گواهی به معنای آماده بودن نوع دیگر نیست.
اگر سازمان می‌خواهد از کلیدهای پراکنده به گواهی SSH مهاجرت کند، ابتدا گروه محدودی از میزبان‌ها را انتخاب کند. مسیر دسترسی اضطراری، رفتار هنگام قطع مرجع و پایان اعتبار نشست‌های جدید باید مستند باشد. نباید در اولین مرحله تمام روش‌های قبلی حذف شوند و بعد مشخص شود صدور خودکار در یکی از شبکه‌ها کار نمی‌کند. مهاجرت باید آزمون‌پذیر و قابل بازگشت طراحی شود.
عیب‌یابی و پذیرش عملیاتی
در خطای TLS ابتدا نام میزبان، تاریخ اعتبار، ساعت، زنجیره میانی و ریشه اعتماد را بررسی کنید. خاموش کردن بررسی گواهی فقط نشانه خطا را پنهان می‌کند. در خطای صدور، متن درخواست، provisioner انتخاب‌شده و سیاست نام‌ها را بدون افشای کلید خصوصی مقایسه کنید. در خطای تمدید، تفاوت بین مشکل مرجع و نصب گواهی در سرویس مقصد را مشخص کنید.
معیار آماده بودن شامل صدور مجاز، رد درخواست نامجاز، تمدید واقعی، بارگذاری گواهی تازه و بازیابی از نسخه پشتیبان است. تمرین بازیابی باید تنظیمات، داده و مواد کلیدی لازم را پوشش دهد و در محیط جداگانه اجرا شود. با این معیارها step-ca می‌تواند پایه مدیریت گواهی داخلی باشد؛ اعتماد قابل نگهداری زمانی شکل می‌گیرد که چرخه صدور تا پایان اعتبار در عملیات روزانه دیده شود.
