صدور و بازگشت کلید فوب RFID: گردش کار کنترل دسترسی چندگانه{0}}سایت

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

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

 

 

یک فوب، پنج رکورد مختلف

با جدا کردن مواردی که کارکنان اغلب در یک ستون صفحه گسترده به نام «شماره کارت» ترکیب می‌کنند، شروع کنید.

شماره چاپ شده روی فوب ممکن است یک مرجع موجودی مناسب باشد، نه مقدار اعتبار جانبی{0}}خواننده واقعی آن. بسته به پلت فرم نصب شده ممکن است کد تسهیلات، شماره کارت، نمایش هگزادسیمال یا رمزگذاری اختصاصی درگیر باشد. Syntekتوضیح نحوه عملکرد کلیدهای{0}}دسترسیصاحب آن سوال سازگاری فنی است. گردش کار در اینجا فرض می کند که یک اعتبار سازگار قبلاً تأیید شده است.

 

 

واگذاری کارخانه جدا از ثبت نام سایت

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

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

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

 

 

یک محموله را به عنوان انبار کنترل شده دریافت کنید

دریافت باید یک پاسخ مستند به چهار سوال ارائه دهد: چه چیزی تحویل داده شد، چه شناسه‌های الکترونیکی موجود است، کدام سایت مسئول سهام است و کدام واحدها برای صدور در دسترس نیستند.

برای هر تحویل یا زیر{0} دسته، بررسی کنید:

• تعداد و گروه:کارتن ها، کیسه ها و محل تخصیص با رکورد بسته بندی مطابقت دارد.
• یکپارچگی مرجع:اعداد یا برچسب های قابل مشاهده با فایل نقشه برداری تایید شده مطابقت دارند.
• پاسخ الکترونیکی:واحدهای نماینده یا مشخص شده را می توان با استفاده از گردش کار خواننده/رمزگذاری پذیرفته شده واقعی شناسایی کرد.
• منحصر به فرد بودن:یک مقایسه سطح{0}داده هیچ تکراری در فضای نامی که به اعتبارنامه‌های فعال منحصربه‌فرد نیاز دارد، پیدا نمی‌کند.
• استثنائات:واحدهای آسیب دیده، ناخوانا، تکراری یا ناشناخته به جای اضافه شدن به موجودی موجود، قرنطینه می شوند.

سطوح نمونه برداری و آستانه پذیرش به مشخصات مورد توافق خریدار تعلق دارد. نه یک درصد عمومی و نه یک بوق خواننده برای هر پروژه اثبات کافی نیست.

 

 

به هر سایت یک حافظ سهام و یک مرز آشتی بدهید

یک تیم مرکزی ممکن است تمام فوب ها را خریداری کند در حالی که دفاتر فردی آنها را صادر می کنند. این ترتیب به جای یک شمارش کل موجودی، به سوابق نگهداری صریح نیاز دارد.

یک مدل سهام ساده متمایز می کند:

• سهام تخصیص نیافته مرکزی:واحدهای قابل استفاده هنوز به یک سایت اختصاص داده نشده اند.
• موجودی موجود در سایت:واحدهای قابل استفاده به طور فیزیکی توسط یک متولی با نام نگهداری می شود.
• سهام رزرو شده:واحدهایی که برای درخواست تایید شده کنار گذاشته می شوند اما تحویل داده نمی شوند.
• سهام صادر شده:اعتبار فیزیکی به دارندگان تحویل داده می شود و در سیستم دسترسی ردیابی می شود.
• سهام قرنطینه یا بازنشسته:واحدهای آسیب دیده، مبهم، بازیابی شده-از دست رفته یا غیرقابل صدور-.

نقل و انتقالات بین دفاتر باید به عنوان دو رویداد مرتبط ثبت شوند: آزادسازی از محل ارسال و دریافت توسط مقصد. یک محموله در حال حمل و نقل نباید در هر دو مکان موجود باشد.

 

 

فقط پس از تایید هویت و دسترسی، فوب صادر کنید

هدف از صدور این است که ثابت کند یک اعتبار فیزیکی خاص به شخص صحیح داده شده و با مجوزهای صحیح فعال شده است. ترتیب عادی این است:

1. هویت دارنده و درخواست یا حامی مجاز را تأیید کنید.
2. یک فوب موجود و غیر قرنطینه شده را از فهرست موجودی سایت انتخاب کنید.
3. شناسه اعتبار الکترونیکی را با استفاده از خواننده/ابزار تایید شده بخوانید یا تأیید کنید.
4. آن اعتبار را با دارنده در سیستم کنترل دسترسی مرتبط کنید.
5. سایت تایید شده، گروه درب، برنامه زمانی و قوانین انقضا را اعمال کنید. از کپی کردن مجوزهای گسترده از دارنده قبلی خودداری کنید.
6. آزمایش دسترسی مجاز و در صورت امکان، یک نماینده شرط دسترسی را رد کرد.
7. تحویل فیزیکی، اپراتور صادرکننده، تصدیق دارنده و وضعیت مؤثر را ثبت کنید.

هنگامی که ثبت نام نرم افزار متمرکز است، ممکن است مدیر سایت امتیازی برای ایجاد مجوز نداشته باشد. در این صورت، گردش کار باید قبل از رها کردن فیزیکی فوب، به تأیید مجوز نیاز داشته باشد.

 

 

از یک سایت{0}}نمایه دسترسی خاص استفاده کنید، نه از یک مجوز جهانی ضمنی

اعتبار چند سایت ممکن است توسط خوانندگان در چندین مکان بدون مجوز برای باز کردن هر دری شناسایی شود. به رسمیت شناختن و مجوز تصمیمات جداگانه باقی می ماند.

نمایه‌هایی مانند کارمند سایت A، پیمانکار سایت B، تعمیر و نگهداری بعد از{0}ساعت ساعت یا بازدیدکننده موقت را تعریف کنید، اما اینها را به‌عنوان نمونه به‌جای تنظیمات عمومی در نظر بگیرید. هر نمایه به یک مالک تأیید، درهای مجاز، برنامه زمانی، شرایط انقضا و قانون بازبینی نیاز دارد. ممکن است پیمانکاران به یک حامی مالی و محدودیت زمانی نیاز داشته باشند. کارکنان دائمی ممکن است از تایید اداره پیروی کنند.

NIST SP 800-53 PE-2درخواست برای حفظ فهرست‌های دسترسی مجاز، صدور اعتبارنامه، بررسی دسترسی و حذف افراد در زمانی که دیگر نیازی به دسترسی نیست. این یک چارچوب کنترلی مفید است، نه ادعایی مبنی بر اینکه هر دفتر کوچکی باید یک برنامه صدور گواهینامه NIST خاص را اجرا کند.

 

 

بدانید برای هر تحویل چه چیزی باید ضبط کنید

گزارش عملیات اعتبارنامه مفید- مبتنی بر رویداد است. این باید به حسابرس بگوید چه چیزی تغییر کرده است، چه کسی آن را تایید کرده، چه کسی آن را انجام داده است، کدام فوب تحت تأثیر قرار گرفته است و آیا این تغییر تأیید شده است یا خیر.

جزئیات هویت حساس غیرضروری را در صفحه گسترده تامین کننده قرار ندهید یا آنها را روی پوسته چاپ نکنید. گزارش‌های دسترسی و داده‌های شخصی باید از سیاست‌های کنترل حریم خصوصی، حفظ و دسترسی{1}}سازمان پیروی کنند.

 

 

گزارش‌شده-فوب گم‌شده دو اقدام را آغاز می‌کند

هنگامی که دارنده یک فوب مفقود را گزارش می‌کند، اولین اولویت این است که اختیارات آن را غیرفعال کند-نه منتظر یک محموله جایگزین نشود. دوم به روز رسانی سهام فیزیکی و سوابق حوادث است.

یک فرآیند گمشده عملی-فوب تأیید گزارش، شناسایی اعتبار دقیق، تعلیق یا لغو آن از طریق پلت فرم دسترسی{1}}، تأیید تغییر منتشر شده در سایت‌های آسیب‌دیده، مستندسازی حادثه و سپس صدور اعتبار جدید تحت یک مرجع جداگانه است.راهنمای پشتیبانی اعتبار HIDبه همین ترتیب اپراتورها را راهنمایی می کند تا یک اعتبار گمشده را غیرفعال کنند و یک جایگزین اختصاص دهند.

برخی از تأسیسات دسترسی به مجوزهای حافظه پنهان در خواننده ها یا کنترلرها، عملکرد آفلاین یا همگام سازی بین سرورها دارند. در چنین مواردی، وضعیت مرکزی "ناتوان" ممکن است بلافاصله انکار را در هر دری ثابت نکند. یکپارچه ساز باید رفتار انتشار و روش تأیید را تعریف کند. در جایی که سیستم اجازه می دهد، اعتبار ابطال شده را در یک نقطه ورودی کنترل شده نماینده آزمایش کنید. در غیر این صورت وضعیت یا گزارش های کنترل کننده پشتیبانی شده را بررسی کنید.

 

 

بازگشتی مشابه غیرفعال نیست

یک کارمند می‌تواند یک فوب را روی یک میز پذیرش قرار دهد در حالی که پایگاه داده کنترل دسترسی همچنان آن را فعال می‌داند. عکس این امر نیز می تواند اتفاق بیفتد: یک فوب باطل شده از نظر فیزیکی گم شده است.

این دو بعد را از هم جدا نگه دارید:

هرگز تصور نکنید که حذف رکورد یک شخص به طور خودکار وضعیت دسترسی فعلی هر کنترل کننده یا خواننده را تغییر می دهد. بررسی رفتار پلت فرم واقعی.

 

 

تصمیم بگیرید که آیا فوب های برگشتی می توانند مجدداً منتشر شوند یا خیر

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

قبل از انتشار مجدد، دسترسی دارنده سابق را بردارید، فوب را بازرسی و بخوانید، وضعیت آن را در سیستم‌های مرتبط بررسی کنید، داده‌های خاص برنامه{0}} را فقط در صورت پشتیبانی و مجاز پاک کنید یا دوباره پیکربندی کنید، ارتباط جدید ایجاد کنید، و آزمایش دسترسی پایان به-را انجام دهید. اگر اعتبار قدیمی با یک حادثه امنیتی مرتبط باشد، سیاست سازمان ممکن است به جای آن مستلزم بازنشستگی دائم باشد.

صدور مجدد هرگز نباید به عنوان "تنظیم مجدد UID" توصیف شود. بسیاری از اعتبارنامه‌ها دارای شناسه‌های-غیر قابل بازنویسی هستند. تغییر عملیاتی ممکن است فقط در پایگاه داده کنترلر اتفاق بیفتد.

 

 

Offboarding باید مجوز هر سایت را ببندد

هنگامی که یک کاربر سازمان را ترک می کند یا وظیفه پیمانکار به پایان می رسد، مالک سیستم باید مجوز او را حذف کند، حتی اگر fob به طور فیزیکی بازیابی نشده باشد. برای امکانات چند سایت، یک سایت یا کنترلر مستقل فراموش شده کافی است تا شکاف دسترسی ایجاد شود.

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

HID هااسناد مدیریت اعتبار-نشان می دهد که چرا جایگزینی، خاتمه و وضعیت اعتبار، عملیات چرخه حیات صریح در سیستم های هویت مدیریت شده هستند. توابع خاص موجود برای استقرار دسترسی یک ساختمان معمولی LF یا HF-هنوز به نرم افزار خودش بستگی دارد.

 

 

تطبیق سهام فیزیکی در برابر اعتبار فعال

یک ممیزی دوره‌ای باید حداقل سه منبع را با هم مقایسه کند:-سهام نگهداری شده سایت، ثبت واگذاری و فهرست اعتبار فعال سیستم کنترل-. خروجی مفید فقط "400 کلید فوب در دسترس" نیست. این فهرستی از استثنائات است که نیاز به اقدام دارند.

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

فرکانس بازبینی و مهلت‌های پاسخ را از ریسک تجاری تنظیم کنید. سایت‌های پیمانکاری{1}}با گردش مالی بالا ممکن است به بررسی‌های مکرر بیشتری نسبت به یک دفتر کوچک با کارکنان ثابت نیاز داشته باشند. یک برنامه ماهانه یا فصلی کامل نمی تواند جایگزین یک سیاست توافق شده باشد.

 

 

کل چرخه حیات را قبل از عرضه آزمایشی کنید

از اعتبارنامه های نماینده، حداقل دو پیکربندی سایت در صورتی که پروژه شامل سیستم های دسترسی مختلف است، و موارد آزمایشی که انتقال ها را اعمال می کند، به جای ارائه یک fob جدید به خواننده استفاده کنید.

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

 

 

از تأمین‌کننده درخواست کنید یک تحویل تمیز، نه پایگاه داده کارمندان

هنگام راه‌اندازی کلیدهای RFID انبوه، مشخصات خرید باید تراشه/فناوری اعتبار تأیید شده، مرجع سازگاری خواننده، قالب داده الکترونیکی مورد انتظار، قانون شماره‌گذاری قابل مشاهده، -الزام محدوده یا نقشه‌برداری منحصربه‌فرد، بسته‌بندی/گروه‌بندی سایت، فرآیند تأیید نمونه-و نیازهای تأیید ورودی را مشخص کند.

اپراتور سایت باید هویت کارمند، مجوزها، تأییدیه‌های صدور، از دست رفتن{0}}پاسخ فوب و گزارش‌های حسابرسی را به طور جداگانه کنترل کند. در جایی که از یک تامین‌کننده خواسته می‌شود که از قبل شماره-کدگذاری یا از قبل{3}} را کدگذاری کند، دقیقاً توافق کنید که به کدام قسمت‌ها نیاز دارد و چگونه مغایرت‌ها رسیدگی شود. Syntekراهنمای سازگاری فوب کلید مجاورتیتصمیم خرید فنی بالادستی را پوشش می دهد، در حالی که آن استدسته بندی محصولات جا کلیدی RFIDهمچنان مالک تجاری برای منبع یابی اعتبار فیزیکی است.

 

 

نقطه کنترل، تکلیف است، نه حلقه کلید

هنگامی که یک زنجیره قابل بازرسی باقی می ماند، مدیریت عملیات کلید فوب چند سایت آسان تر است:

اعتبار تایید شده ← سهام دریافتی ← نگهداری سایت ← دارنده تایید شده ← نمایه دسترسی مجاز ← رویداد چرخه حیات ← تایید سیستم ← تطبیق موجودی.

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