چرا مدیریت کلیدهای SSH در مقیاس بزرگ دشوار می‌شود؟
در یک محیط کوچک، افزودن کلید عمومی کاربر به فایل مجاز سرور ساده است. اما وقتی تعداد کاربران و ماشین‌ها زیاد می‌شود، پرسش‌های دشوارتری به وجود می‌آید: این کلید متعلق به چه کسی است، هنوز باید دسترسی داشته باشد، در کدام ماشین‌ها نصب شده و هنگام خروج فرد از تیم چگونه حذف می‌شود؟ اگر پاسخ به این پرسش‌ها به جست‌وجوی دستی در ده‌ها فایل وابسته باشد، احتمال باقی ماندن دسترسی قدیمی بالا می‌رود. گواهی‌های OpenSSH یکی از راه‌های تغییر این مدل هستند؛ به جای اعتماد جداگانه به هر کلید، می‌توان به مرجع امضاکننده مشخصی اعتماد کرد.
این تغییر فقط یک ترفند برای کم کردن تعداد فایل‌ها نیست. اعتماد از مجموعه کلیدهای پراکنده به فرایند صدور گواهی منتقل می‌شود. بنابراین باید معلوم باشد چه کسی اجازه صدور دارد، هویت درخواست‌کننده چگونه بررسی می‌شود و چه محدودیت‌هایی در گواهی قرار می‌گیرد. اگر این فرایند ضعیف طراحی شود، مرکزی کردن اعتماد می‌تواند دامنه اثر خطا را بزرگ‌تر کند. هدف این مقاله، توضیح مدل و مسیر آزمایش آن است تا پیش از استفاده در زیرساخت واقعی بدانید کدام مسئله حل می‌شود و کدام مسئولیت تازه به وجود می‌آید.
گواهی OpenSSH چه چیزی را بیان می‌کند؟
گواهی، کلید عمومی را همراه اطلاعات هویتی و محدودیت‌ها به امضای یک CA می‌رساند. در اینجا CA مرجع مورد اعتماد برای امضاست. گیرنده با کلید عمومی CA امضا را بررسی می‌کند. گواهی جای کلید خصوصی دارنده را نمی‌گیرد؛ برای استفاده، دارنده همچنان باید مالکیت کلید خصوصی مربوط را اثبات کند. در نتیجه، داشتن فایل گواهی بدون کلید خصوصی همان دسترسی را فراهم نمی‌کند. از سوی دیگر، حفاظت از کلید خصوصی کاربر همچنان ضروری است و نباید تصور کرد اضافه شدن گواهی، نیاز به حفاظت از آن را حذف کرده است.
قالب گواهی OpenSSH با گواهی‌های X.509 که در بسیاری از کاربردهای TLS می‌بینید متفاوت است. اگر با گواهی وب‌سایت آشنا هستید، مفاهیمی مانند امضا و زمان اعتبار کمک می‌کنند، ولی ابزارها و جزئیات را نباید عیناً تعمیم دهید. برای مثال، مدل توزیع اعتماد و بررسی ابطال باید مطابق قابلیت‌های OpenSSH طراحی شود. نام مشترک «گواهی» به معنی یکسان بودن تمام رفتارها نیست. در مستندات و طراحی داخلی، عبارت گواهی کاربر یا گواهی میزبان SSH را دقیق بنویسید تا با گواهی سرویس وب اشتباه نشود.
گواهی کاربر و گواهی میزبان
گواهی کاربر برای معرفی کاربر به سرور است؛ گواهی میزبان برای معرفی سرور به کلاینت. این دو، دو جهت متفاوت اعتماد را پوشش می‌دهند. ممکن است سازمانی ابتدا فقط گواهی کاربران را پیاده کند و همچنان هویت میزبان‌ها را با روش قبلی بررسی کند. یا برعکس، برای کاهش مشکل کلیدهای میزبان در ماشین‌های موقت از گواهی میزبان استفاده کند. بهتر است مدیریت مرجع صدور این دو حوزه جدا باشد تا خطا یا افشای یک بخش به طور خودکار همه اعتمادهای دیگر را تحت تأثیر قرار ندهد. این جداسازی یک تصمیم طراحی است و باید در رویه‌ها دیده شود.
برای مثال، یک کارشناس عملیات نیاز دارد به گروهی از سرورها متصل شود؛ گواهی کاربر می‌تواند هویت و محدوده مجاز او را بیان کند. همان کارشناس نیز باید بداند سروری که به آن وصل شده واقعاً عضو زیرساخت مورد نظر است؛ گواهی میزبان به این سمت مسئله مربوط می‌شود. موفق شدن احراز هویت کاربر، به تنهایی صحت هویت سرور را توضیح نمی‌دهد. هنگام آزمایش، هر دو جهت را جدا ببینید. پرسش «ورود انجام شد؟» برای ارزیابی کامل مدل اعتماد کافی نیست؛ باید بپرسید هر طرف بر چه مبنایی طرف دیگر را پذیرفته است.
Principal، شناسه و حساب سیستم‌عامل
Principal نامی است که گواهی برای آن اعتبار دارد و در تصمیم مجاز بودن نقش دارد. شناسه گواهی برای پیگیری و گزارش مفید است، ولی نباید آن را با نام حساب مقصد یا مجوز دسترسی یکسان دانست. این تفکیک برای طراحی نقش‌ها مهم است. ممکن است نام هویتی سازمانی با نام حساب روی سرور تفاوت داشته باشد و لازم باشد نگاشت آن‌ها صریح تعریف شود. اگر از نام‌هایی مانند «اپراتور» استفاده می‌کنید، باید روشن باشد چه کسی می‌تواند چنین گواهی‌ای بگیرد و کدام حساب‌ها آن را می‌پذیرند.
ساخت حساب سیستم‌عامل نیز مسئله جداگانه‌ای است. گواهی معتبر به طور جادویی پوشه خانه، گروه‌ها یا مجوز sudo را ایجاد نمی‌کند. فرایند تأمین حساب و نقش باید با سیاست SSH هماهنگ باشد. در یک آزمایش آموزشی، از حساب غیرمدیریتی مشخص استفاده کنید تا نتیجه ساده باشد. سپس بررسی کنید گواهی دارای principal درست پذیرفته و نمونه با principal متفاوت رد شود. این آزمون منفی بسیار مهم است؛ تنها ورود موفق نشان نمی‌دهد محدودیت‌های مورد نظر واقعاً اعمال شده‌اند. اگر همه گواهی‌ها به همه حساب‌ها راه پیدا کنند، مدل مجوز نیاز به اصلاح دارد.
اعتبار زمانی و وابستگی به ساعت
یکی از مزایای مهم گواهی، امکان محدود کردن بازه اعتبار است. به جای نگهداری کلیدی که تا زمان حذف دستی معتبر می‌ماند، می‌توان دسترسی را برای بازه مشخص صادر کرد. مدت مناسب به نوع کار وابسته است. دسترسی موقت یک پیمانکار، کار روزانه اپراتور و حساب خودکار سرویس نیازهای یکسانی ندارند. بازه بسیار طولانی ارزش انقضا را کم می‌کند و بازه بسیار کوتاه بدون فرایند تمدید مناسب می‌تواند عملیات را مختل کند. انتخاب باید همراه با تجربه واقعی کاربر و توانایی سامانه صدور انجام شود.
ساعت سیستم در این مدل اهمیت دارد. اگر زمان کلاینت، سرور یا مرجع صدور ناهماهنگ باشد، گواهی ممکن است هنوز معتبر نشده یا منقضی به نظر برسد. در عیب‌یابی، پیش از صدور دوباره‌های پی‌درپی، زمان را بررسی کنید. همچنین انقضای گواهی برای ورود تازه را با پایان خودکار تمام نشست‌های موجود یکی ندانید؛ سیاست مدیریت نشست مسئله جداگانه‌ای است. این تفاوت باید به مسئولان توضیح داده شود تا از یک بازه اعتبار کوتاه، نتیجه نادرست درباره قطع فوری همه دسترسی‌ها نگیرند. طراحی خروج اضطراری از دسترسی، نیازمند بررسی کل مسیر است.
آزمایش در یک محیط کوچک
برای یادگیری، یک ماشین آزمایشی و حساب محدود انتخاب کنید و کلیدهای مخصوص همان آزمایش بسازید. کلید مرجع آزمایشی را با مرجع واقعی سازمان مخلوط نکنید. ابتدا ارتباط معمول و مسیر بازیابی کنسول را بررسی کنید. سپس گواهی محدود صادر کنید و مشخصات آن را با ابزار مشاهده گواهی بخوانید. پیش از تلاش برای ورود، نام‌ها، بازه زمانی و مرجع امضا را کنترل کنید. این کار بسیاری از خطاها را زودتر آشکار می‌کند و مانع می‌شود هر شکست اتصال به شبکه یا فایروال نسبت داده شود.
سمت سرور، اعتماد به مرجع کاربر از طریق تنظیمات مربوط مانند TrustedUserCAKeys و سیاست principal مدیریت می‌شود. جزئیات را از مستندات نسخه نصب‌شده بخوانید و پیکربندی را پیش از اعمال اعتبارسنجی کنید. نشست مدیریتی فعلی را تا تأیید ورود تازه باز نگه دارید و تغییر را فقط روی همان محیط آزمایشی انجام دهید. پس از موفقیت، چند حالت منفی را امتحان کنید: گواهی منقضی، مرجع ناشناخته، نام نامجاز و کلید خصوصی نامرتبط. برای هر حالت، انتظار و نتیجه واقعی را ثبت کنید. همین جدول کوچک، پایه پذیرش طراحی خواهد بود.
حفاظت از مرجع صدور
کلید خصوصی CA از حساس‌ترین دارایی‌های این طرح است. کسی که بتواند طبق سیاست اعتماد شما گواهی معتبر صادر کند، ممکن است بتواند دسترسی‌های گسترده بسازد. بنابراین آن را روی هر سرور مقصد کپی نکنید؛ سرورها برای راستی‌آزمایی به بخش عمومی اعتماد نیاز دارند. محیط صدور باید دسترسی محدود، ثبت رخداد و روش بازیابی روشن داشته باشد. بسته به مقیاس، امضا می‌تواند در فرایند کنترل‌شده یا سامانه مدیریت‌شده انجام شود. تصمیم درباره آنلاین یا آفلاین بودن باید با نیاز صدور و خطر مورد قبول هماهنگ باشد.
مهم‌تر از محل فایل، سیاست صدور است. درخواست‌کننده چگونه احراز هویت می‌شود؟ آیا می‌تواند principal دلخواه درخواست کند؟ چه کسی مدت اعتبار را تعیین می‌کند؟ اگر یک رابط خودکار هر مقدار ارسالی کاربر را بدون بررسی امضا کند، حفاظت خوب از فایل کلید به تنهایی کافی نیست. ورودی‌های صدور باید با نقش و دارایی مجاز محدود شوند. در گزارش هر صدور، شناسه قابل پیگیری، درخواست‌کننده و محدوده ثبت شود، اما کلید خصوصی یا داده حساس در لاگ قرار نگیرد. این شواهد برای رسیدگی به رخداد و اصلاح اشتباه ضروری‌اند.
ابطال و خروج کاربر از سازمان
انقضای کوتاه به کاهش عمر دسترسی کمک می‌کند، ولی همیشه جای ابطال فوری را نمی‌گیرد. ممکن است کلیدی افشا شود یا کاربری پیش از پایان بازه اعتبار از نقش خود خارج شود. باید از قبل مشخص باشد چگونه گواهی یا کلید مربوط رد می‌شود و این تغییر چگونه به سرورها می‌رسد. OpenSSH امکاناتی مانند فهرست ابطال کلید دارد، اما اثربخشی آن به توزیع و تنظیم درست وابسته است. ساختن فایل ابطال در یک سیستم مرکزی، بدون اینکه مقصد آن را مصرف کند، دسترسی را قطع نمی‌کند.
برای آزمایش این بخش، یک گواهی آموزشی صادر کنید، ورود آن را تأیید کنید و سپس با روش انتخابی خود ابطال را اعمال کنید. در یک اتصال تازه نتیجه را ببینید و زمان رسیدن سیاست به مقصد را اندازه بگیرید. اگر بعضی ماشین‌ها آفلاین یا خارج از مدیریت‌اند، وضعیتشان را مشخص کنید. گزارش خروج کاربر باید شامل حذف یا محدود شدن دسترسی در سامانه صدور نیز باشد؛ وگرنه فرد ممکن است گواهی تازه بگیرد. مدیریت چرخه عمر هویت، گواهی و حساب مقصد باید به هم متصل باشد تا شکاف عملیاتی باقی نماند.
مهاجرت از کلیدهای پراکنده
مهاجرت را با موجودی کلیدها و حساب‌های فعلی شروع کنید. مشخص کنید کدام دسترسی انسانی، کدام خودکار و کدام ناشناخته است. حذف فوری همه کلیدهای قدیمی بدون شناخت کاربردشان می‌تواند کارهای زمان‌بندی‌شده یا بازیابی اضطراری را مختل کند. برای گروهی محدود، روش جدید را در کنار روش فعلی آزمایش کنید و سپس طبق برنامه، مسیر قدیمی را جمع کنید. هم‌زیستی باید موقت و قابل پیگیری باشد؛ اگر کلیدهای قدیمی برای همیشه باقی بمانند، بخش مهمی از مزیت کنترل مرکزی از دست می‌رود.
برای حساب‌های خودکار، به انقضا و تمدید با دقت بیشتری نگاه کنید. فرایندی که نیمه‌شب اجرا می‌شود باید پیش از نیاز، گواهی معتبر داشته باشد و شکست دریافت را واضح گزارش کند. پنهان کردن شکست با باز کردن دسترسی دائمی، مسئله را حل نمی‌کند. همچنین هویت یک سرویس نباید به حساب شخصی یک کارمند وابسته بماند. مسیر اضطراری را جدا، محدود و آزمایش‌شده تعریف کنید. وجود آن برای تاب‌آوری مفید است، اما باید استفاده از آن ثبت و پس از پایان نیاز بازبینی شود تا به راه دائمی دور زدن سیاست تبدیل نشود.
عیب‌یابی و نتیجه قابل اتکا
اگر ورود با گواهی شکست خورد، مسئله را به چند بخش تقسیم کنید: آیا کلاینت همان کلید و گواهی مورد نظر را ارائه می‌دهد، آیا مرجع امضا مورد اعتماد است، آیا زمان معتبر است و آیا principal برای حساب مقصد پذیرفته می‌شود؟ سپس سیاست‌های مستقل سرور مانند وضعیت حساب و محدودیت گروه را بررسی کنید. تغییر هم‌زمان چند گزینه امنیتی برای «راه افتادن» باعث می‌شود علت واقعی پنهان بماند. پیام‌های کلاینت و لاگ سرور را با زمان مشترک کنار هم بگذارید و اطلاعات حساس را هنگام اشتراک گزارش حذف کنید.
مدل گواهی SSH زمانی موفق است که هم ورود درست آسان شود و هم ورود نامجاز قابل پیش‌بینی رد شود. معیار پذیرش فقط کاهش فایل authorized_keys نیست؛ باید بتوانید صدور را پیگیری، دسترسی را محدود، خطا را توضیح و در زمان لازم اعتماد را جمع کنید. برای زیرساخت کوچک، روش ساده کلید عمومی ممکن است هنوز کافی باشد. برای محیط بزرگ‌تر، گواهی می‌تواند نظم بهتری ایجاد کند، به شرطی که فرایند صدور و چرخه عمر هویت به اندازه پیکربندی فنی جدی گرفته شوند. انتخاب نهایی باید بر پایه نیاز واقعی و آزمون عملی باشد.
