نرم‌افزار مدیریت کلیدهای فیزیکی باید روشن کند هر نسخه کلید اکنون نزد چه کسی است، با چه مجوزی تحویل شده، چه زمانی باید برگردد و در صورت اختلاف یا مفقودی چه اقدامی لازم است. ثبت نام دریافت‌کننده در یک جدول، به‌تنهایی این نیاز را برطرف نمی‌کند. سامانه باید مجوز دسترسی، تحویل واقعی و وضعیت هر نسخه را از هم جدا نگه دارد؛ همچنین نباید ادعا کند بازگشت یک کلید، نبود نسخه تکثیرشده را ثابت می‌کند.
این راهنما برای سازمان‌هایی است که کلید اتاق‌ها، انبارها، کابینت‌ها یا بخش‌های فنی را میان کارکنان و پیمانکاران جابه‌جا می‌کنند. منظور، کلید فیزیکی است نه کلید رمزنگاری یا رمز ورود نرم‌افزار. هدف، تعریف نیازمندی قابل اجرا برای گردش تحویل و بازگشت است؛ نرم‌افزار جای قفل مناسب، نگهداری امن و تصمیم مسئول حفاظت را نمی‌گیرد.
مسئله کلید با رزرو یک تجهیز چه تفاوتی دارد؟
در رزرو تجهیزات، سؤال اصلی معمولاً این است که چه کسی در چه زمانی می‌تواند از یک وسیله استفاده کند. در مدیریت کلید، خود وسیله راه دسترسی به یک فضا یا دارایی دیگر است. بنابراین پیامد مفقودی آن ممکن است به چیزی فراتر از قیمت جایگزینی کلید مربوط باشد. یک کلید عمومی نیز ممکن است به چند محل دسترسی بدهد و نباید مانند یک قلم معمولی کم‌اهمیت ثبت شود.
اگر مسئله شما زمان‌بندی استفاده از ابزار مشترک است، راهنمای نرم‌افزار رزرو تجهیزات موضوع مناسب‌تری دارد. اما برای کلید، باید نسخه‌های مشابه، محدوده دسترسی، مسئول نگهداری و رویدادهای امنیتی را نیز تعریف کنید. شباهت فرم تحویل نباید باعث شود این تفاوت‌ها در طراحی داده و گزارش نادیده گرفته شوند.
ابتدا موجودی را در سطح نسخه فیزیکی ثبت کنید
نوع کلید با نسخه کلید یکی نیست
ممکن است سه کلید مشابه برای یک در وجود داشته باشد. ثبت یک ردیف با عنوان «کلید انبار» و تعداد سه، برای پیگیری اینکه کدام نسخه نزد چه کسی است کافی نیست. هر نسخه قابل تحویل باید شناسه مشخص داشته باشد. شناسه می‌تواند روی برچسب یا نگهدارنده قرار گیرد، اما روش برچسب‌گذاری نباید اطلاعات حساس محل را برای هر بیننده آشکار کند.
در ثبت اولیه، نوع کلید، نسخه، محل نگهداری معمول و وضعیت آن را مشخص کنید. رابطه میان کلید و محل دسترسی نیز باید برای افراد مجاز قابل مشاهده باشد. عکس دقیق دندانه‌ها یا اطلاعات ساخت کلید را بی‌دلیل در سامانه عمومی ذخیره نکنید؛ برای شناسایی نسخه، معمولاً شناسه نگهدارنده و توصیف کنترل‌شده نقطه شروع مناسب‌تری است.
شمارش اولیه را با مشاهده واقعی تطبیق دهید
فهرست قدیمی را بدون بررسی به‌عنوان موجودی قطعی وارد نکنید. ممکن است نسخه‌ای مفقود، خارج از سرویس یا نزد فردی باشد که دیگر مسئول آن نیست. برای هر اختلاف، وضعیت «نیازمند بررسی» ثبت کنید و مسئول تعیین تکلیف داشته باشید. تبدیل اختلاف به موجودی عادی فقط برای مرتب‌شدن گزارش، خطای اولیه را به همه تحویل‌های بعدی منتقل می‌کند.
مجوز دریافت را از تحویل واقعی جدا کنید
تأیید درخواست به معنی دریافت کلید نیست. سامانه باید درخواست، تأیید، تحویل فیزیکی و بازگشت را رویدادهای جدا بداند. ممکن است درخواست تأیید شود ولی فرد مراجعه نکند؛ در این حالت، موجودی نباید از کمد خارج‌شده نمایش داده شود. زمان تأیید مدیر نیز نباید جای زمان واقعی تحویل بنشیند.
مجوز باید محدوده و اعتبار مشخص داشته باشد. آیا شخص اجازه دریافت همین نسخه یا هر نسخه مجاز از همان نوع را دارد؟ آیا تحویل فقط در شیفت معین ممکن است؟ آیا پیمانکار باید همراه مسئول داخلی باشد؟ این قواعد را مسئول فرایند تعیین می‌کند و نرم‌افزار آن‌ها را اجرا یا برای بررسی نمایش می‌دهد؛ سامانه نباید از روی عنوان شغلی، مجوزهای تعریف‌نشده حدس بزند.
ثبت ورود فرد به ساختمان نیز با اجازه دریافت کلید برابر نیست. مدیریت ورود مهمانان و پیمانکاران می‌تواند اطلاعات مراجعه را فراهم کند، اما تحویل کلید به تأیید جداگانه و ثبت نسخه واقعی نیاز دارد. خروج مهمان هم نباید خودکار تمام کلیدهای او را «بازگشته» کند، مگر دریافت فیزیکی آن‌ها واقعاً ثبت شده باشد.
هنگام تحویل چه چیزی باید ثبت شود؟
فرم تحویل باید کوتاه باشد، اما اطلاعات لازم برای پاسخ‌گویی را داشته باشد: شناسه نسخه، تحویل‌دهنده، دریافت‌کننده، زمان واقعی، مبنای مجوز و موعد بازگشت. اگر کلید به یک کار یا درخواست خدمت مربوط است، پیوند همان رکورد کمک می‌کند علت تحویل بعداً قابل فهم باشد. توضیح آزاد نباید جای فیلدهای اصلی را بگیرد.
در سامانه چندکاربره، دو مسئول نباید بتوانند یک نسخه را هم‌زمان به دو نفر تحویل دهند. کنترل موجودبودن باید هنگام ثبت نهایی در سمت سرور انجام شود، نه فقط با غیرفعال‌کردن دکمه در صفحه. اگر درخواست دوباره ارسال شد، سامانه باید از ایجاد دو تحویل برای یک اقدام جلوگیری کند و نتیجه ثبت قبلی را قابل تشخیص نگه دارد.
تأیید دریافت نیز باید معنای روشن داشته باشد. ثبت توسط مسئول کمد، تأیید شخص دریافت‌کننده و شاهد تحویل، سه نوع اطلاعات متفاوت‌اند. بسته به نیاز سازمان ممکن است یکی یا چند مورد لازم باشند. وجود یک تصویر امضا به‌تنهایی نباید به‌عنوان تضمین هویت یا صحت همه جزئیات معرفی شود؛ روش شناسایی و کنترل عملیاتی باید جدا مشخص باشد.
بازگشت، انتقال مستقیم و تغییر شیفت
بازگشت زمانی ثبت شود که نسخه مشخص واقعاً دریافت و تطبیق داده شده است. گزینه «کار تمام شد» یا «فرد از ساختمان خارج شد» شاهد دریافت کلید نیست. اگر نگهدارنده شکسته یا شناسه ناخواناست، می‌توان بازگشت را با وضعیت بررسی ثبت کرد، اما نباید نسخه را بدون تعیین تکلیف آماده تحویل بعدی نشان داد.
تحویل مستقیم بین دو کارمند نیز نیازمند قاعده است. اگر سازمان آن را مجاز می‌داند، باید انتقال مسئولیت با مشخص‌بودن فرستنده، گیرنده و زمان ثبت شود. اگر مجاز نیست، سامانه باید مسیر بازگشت به متولی و تحویل جدید را حفظ کند. تغییر نام دریافت‌کننده در رکورد قدیمی، تاریخچه مسئولیت را از بین می‌برد.
در تغییر شیفت، گزارش کلیدهای خارج از محل نگهداری را با مشاهده و پیگیری تطبیق دهید. مسئول شیفت بعدی باید بداند کدام نسخه‌ها تحویل شده‌اند، کدام موعد گذشته دارند و کدام اختلاف باز است. یک عدد کلی «تعداد کلیدهای موجود» برای تصمیم عملیاتی کافی نیست، چون وضعیت یک کلید حساس ممکن است پشت مجموع موجودی پنهان شود.
تأخیر و مفقودی دو وضعیت متفاوت‌اند
گذشتن از موعد بازگشت، به‌تنهایی اثبات مفقودی نیست. ابتدا باید وضعیت پیگیری و پاسخ دریافت‌کننده مشخص شود. سامانه می‌تواند یادآوری و ارجاع به مسئول ایجاد کند، اما نباید بدون بررسی، فرد را مقصر معرفی کند یا وضعیت دارایی را قطعی تغییر دهد. پیام‌ها باید واقعیت ثبت‌شده را بیان کنند: «موعد گذشته و بازگشت ثبت نشده است».
گزارش مفقودی، رویدادی جداست و ممکن است نیازمند اقدام فوری مسئول حفاظت باشد. در کنترل PE-3 از NIST SP 800-53 Revision 5، حفاظت از ابزارهای دسترسی فیزیکی، موجودی‌برداری و تغییر کلیدها یا ترکیب‌ها در شرایط مشخص مطرح شده است. این مرجع، مبنای مفهومی کنترل است، نه الزام عمومی یکسان برای همه سازمان‌ها یا جایگزین ارزیابی محل.
نرم‌افزار باید گزارش، زمان اطلاع، دامنه احتمالی و تصمیم مسئول مجاز را پیگیری کند. حذف کلید از فهرست فعال یا بستن حساب دریافت‌کننده، کلید مکانیکی را بی‌اثر نمی‌کند. تصمیم درباره قفل، نسخه‌های دیگر و اقدامات حفاظتی باید توسط مسئول مناسب اتخاذ و نتیجه آن ثبت شود. بازگشت کلید پس از مفقودی هم نباید حادثه را خودکار حل‌شده اعلام کند.
نسخه جایگزین و کلید عمومی را با دقت بیشتری مدیریت کنید
وقتی نسخه جدید ساخته می‌شود، برای آن سابقه مستقل ثبت کنید. نسخه جایگزین نباید با بازنویسی شناسه نسخه مفقود وارد چرخه شود، چون بعداً تشخیص اینکه کدام نسخه پیدا شده دشوار می‌شود. رابطه «جایگزین برای» می‌تواند در سوابق باقی بماند، در حالی که وضعیت هر دو نسخه مستقل است.
کلیدی که چند محل را باز می‌کند، نیازمند محدودیت نمایش و قواعد تحویل متناسب است. فهرست کامل محل‌های قابل دسترسی نباید برای همه کاربران قابل مشاهده باشد. گزارش‌های عمومی می‌توانند وضعیت و مسئول پیگیری را نشان دهند و جزئیات حساس را فقط برای نقش‌های مجاز باز کنند. افزودن داشبورد نباید خودش نقشه دسترسی فیزیکی سازمان را بی‌دلیل منتشر کند.
اتصال به کمد هوشمند را چگونه ارزیابی کنیم؟
اگر کمد یا دستگاه خوانش دارید، ابتدا مشخص کنید رویداد آن چه چیزی را ثابت می‌کند. بازشدن در کمد، خوانده‌شدن برچسب و برداشته‌شدن کلید، لزوماً یک رویداد نیستند. قرارداد اتصال باید معنی داده، زمان، شناسه دستگاه و روش تشخیص خطا را روشن کند. نباید از هر پیام دستگاه، دریافت قطعی توسط یک فرد را نتیجه گرفت.
در قطع ارتباط، رفتار ایمن و قابل اجرا لازم است. ممکن است ثبت موقت کنترل‌شده یا توقف برخی تحویل‌ها بر اساس سیاست سازمان انتخاب شود. پس از اتصال، تطبیق باید اختلاف‌ها را نشان دهد و از ایجاد رویداد تکراری جلوگیری کند. گزارش ثبت دیرهنگام نیز باید زمان وقوع اعلام‌شده را از زمان ثبت در سامانه جدا نگه دارد.
بدون کمد هوشمند هم می‌توان گردش پاسخ‌گو طراحی کرد، به شرط اینکه ثبت دستی با مسئول مشخص و تطبیق واقعی همراه باشد. خرید سخت‌افزار قبل از روشن‌شدن فرایند، الزاماً مشکل تحویل بی‌ثبت یا مجوز مبهم را حل نمی‌کند. برای انتخاب، محدودیت دستگاه و هزینه نگهداری را کنار نیاز عملیاتی بررسی کنید.
سناریوی فرضی: پیمانکار تعمیرات و یک کلید انبار
فرض کنید پیمانکار برای تعمیر تجهیز مراجعه می‌کند و مسئول داخلی، دریافت یک نسخه کلید انبار را تا پایان کار تأیید می‌کند. نگهبان هنگام تحویل، نسخه مشخص را انتخاب و دریافت واقعی را ثبت می‌کند. مراجعه و مجوز از قبل وجود دارند، اما تنها همین رویداد، کلید را از وضعیت موجود به تحویل‌شده تغییر می‌دهد.
در پایان مراجعه، خروج پیمانکار ثبت می‌شود ولی بازگشت کلید هنوز ثبت نشده است. سامانه اختلاف را برای مسئول پیگیری نشان می‌دهد؛ آن را خودکار بازگشته یا مفقود اعلام نمی‌کند. پس از دریافت کلید و تطبیق شناسه، بازگشت ثبت می‌شود. اگر کلید دیگری آورده شده باشد، اختلاف باز می‌ماند تا بررسی شود. این مثال، سناریوی طراحی است و گزارش یک پروژه اجراشده نیست.
معیارهای پذیرش نسخه نخست
پیش از تحویل نرم‌افزار، این حالت‌ها را با داده آزمایشی اجرا کنید:
- چند نسخه مشابه، سابقه و دریافت‌کننده مستقل داشته باشند.
- درخواست تأییدشده بدون تحویل، موجودی را تغییر ندهد.
- ثبت هم‌زمان دو تحویل برای یک نسخه پذیرفته نشود.
- انتقال مسئولیت، تاریخچه قبلی را حذف نکند.
- خروج فرد، بازگشت خودکار و بدون شاهد ایجاد نکند.
- تأخیر، مفقودی و نیاز به بررسی وضعیت‌های جدا باشند.
- کاربر غیرمجاز نتواند جزئیات محل‌های دسترسی را ببیند.
- رویداد تکراری دستگاه یا درخواست تکراری، سابقه عملیاتی مضاعف نسازد.
همچنین جست‌وجوی نسخه و ثبت بازگشت باید در موبایل یا تبلت محل نگهداری قابل استفاده باشد. وضعیت فقط با رنگ بیان نشود و برچسب فیلدها روشن باشد. برای گزارش مدیریتی، کلیدهای خارج از محل، موعدگذشته‌ها و اختلاف‌های باز را از هم جدا نشان دهید. این گزارش‌ها شواهد ثبت سامانه‌اند و جای شمارش و کنترل فیزیکی را نمی‌گیرند.
از فهرست کلید به گردش قابل پیگیری
نسخه نخست را با ثبت نسخه‌ها، مجوز، تحویل، بازگشت، اختلاف و گزارش پیگیری شروع کنید. سپس در صورت نیاز اتصال سخت‌افزار یا فرایندهای پیچیده‌تر را اضافه کنید. پیش از هر توسعه، مسئولیت تصمیم و معنای هر وضعیت را روشن کنید؛ تعداد بیشتر فیلدها به‌تنهایی کنترل بهتری ایجاد نمی‌کند.
در خدمات توسعه نرم‌افزار سفارشی ایزی‌ساز، این گردش می‌تواند مطابق نقش‌ها و محدودیت‌های سازمان طراحی شود. برای بررسی نیاز سامانه مدیریت کلید، نمونه فهرست فعلی، قواعد مجوز، شیوه تحویل و استثناهای پرتکرار را آماده کنید. نتیجه مطلوب، سابقه قابل اتکا از مسئولیت نسخه‌هاست، نه وعده حذف همه خطرهای دسترسی فیزیکی.