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

پروندهٔ مشخص را در نظر داشته باشید: شریک سندی تأییدشده برای امضا با یک کلید نام‌دار ارائه می‌کند، و نه چیز دیگری. همهٔ آنچه در ادامه می‌آید از همان یک جمله برمی‌آید.

دسترس‌پذیری، هویت و سیاست کلید سه دروازه‌اند

متمرکزکننده VPN تعیین می‌کند چه کسی می‌تواند تونل باز کند و به کدام نشانی‌ها دست بزند. HSM خودش تعیین می‌کند کدام سابقهٔ کاربری که به آن ارائه می‌شود می‌تواند وارد شود. سپس سیاست کلید تعیین می‌کند آن سابقه با یک کلید مشخص چه می‌تواند بکند. عبور از دروازهٔ اول دو دروازهٔ دیگر را دقیقاً همان‌گونه که بودند باقی می‌گذارد، به همین دلیل یک دست‌دادن موفق چیز کمی اثبات می‌کند و به همین دلیل شریک می‌تواند به دستگاه برسد و با این حال در هر عملیاتی شکست بخورد.

پیش از نوشتن الزامات، هر دروازه را به یک مالک نسبت دهید. وقتی دروازهٔ دوم مالکی ندارد، نتیجهٔ معمول این است که یک هویت گستردهٔ مدیر HSM صادر می‌شود، چون تنها اعتبارنامه‌ای است که کار می‌کند.

دروازهٔ یک: مسیر شبکه‌ای که به شریک داده می‌شود

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

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

دروازهٔ دو: چه چیزی واقعاً در برابر HSM احراز هویت می‌شود

هویت VPN و هویت HSM دو شیء جداگانه‌اند مگر آنکه یک یکپارچه‌سازی پشتیبانی‌شده آگاهانه آن‌ها را به هم بپیوندد. با کلاینت PKCS#11، برنامه ورودی به یک اسلات با اعتبارنامه‌ای که جایی روی میزبان شریک ذخیره شده انجام می‌دهد، و همان ورود است که HSM ارزیابی می‌کند.

AWS CloudHSM مرجع مفیدی است چون مستنداتش این دو را جدا نگه می‌دارد: کاربران HSM با کاربران IAM متفاوت‌اند، و نوع کاربر تعیین می‌کند حساب چه می‌تواند بکند. افسر رمزنگاری کاربران و کلیدها را مدیریت می‌کند اما همان هویتی نیست که عملیات رمزنگاری را انجام می‌دهد، در حالی که کاربر رمزنگاری می‌تواند از کلیدها استفاده کند بدون آنکه بتواند آن‌ها را مدیریت کند. این تفکیک همان شکلی است که می‌خواهید، حتی روی دستگاه فروشندهٔ دیگر، جایی که نام نقش‌ها متفاوت خواهد بود.

هر هویتی که صادر می‌کنید باید با همان ریزدانگی که بعداً لازم دارید قابل حذف و قابل انتساب باشد. یک اعتبارنامهٔ عملیاتی مشترک میان چند شریک، مهار و پاسخ‌گویی را دقیقاً در همان حادثه‌ای سخت‌تر می‌کند که هر دو در آن بیشترین اهمیت را دارند.

دروازهٔ سه: کدام کلید و کدام عملیات

امضا، رمزگشایی، تولید کلید، بسته‌بندی کلید و مدیریت کاربر مجوزهای جداگانه‌اند و باید جداگانه فهرست شوند. در اصطلاح PKCS#11، ویژگی‌هایی مانند CKA_SENSITIVE و CKA_EXTRACTABLE توصیف می‌کنند که آیا مادهٔ کلید می‌تواند به شکل قابل استفاده از ماژول خارج شود، و برای هر کلید تنظیم می‌شوند نه برای دستگاه. سیاست واقعی روی کلید را بخوانید، به‌جای آنکه عدم قابلیت صدور را از واژهٔ سخت‌افزار یا از وجود یک تونل استنتاج کنید.

سپس تأیید تجاری را پیدا کنید. اگر فقط اسناد تأییدشده را می‌توان امضا کرد، کدام مؤلفه آن تأیید را پیش از رسیدن درخواست به HSM برقرار می‌کند؟ یک رابط رمزنگاری که درخواست مجاز را می‌پذیرد هیچ نمی‌داند سند بازبینی شده یا نه، پس آن بررسی بر عهدهٔ سرویس جلوی آن است.

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

ردها بخشی از آزمون پذیرش‌اند

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

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

یک دست‌دادن کامل‌شدهٔ VPN به همان سابقه تعلق دارد. نمی‌تواند جای یک نتیجهٔ واحد مخصوص HSM را بگیرد.

مقالات مرتبط