Видача та повернення брелоків RFID: робочий процес керування доступом до кількох-сайтів

Партія брелоків RFID може пройти перевірку зчитування постачальником і все одно стати проблемою в роботі в день її випуску. Команда об’єктів може мати правильні облікові дані, але не мати достовірних відомостей про те, який офіс їх отримав, який працівник має їх, який номер розпізнає контролер або чи фактично було вимкнено-втрачений брелок.

Для -контролю доступу до кількох сайтів практичним завданням є підключенняфізичний запас, електронний ідентифікатор, названий власник, затверджений профіль доступу та записаний статус життєвого циклу. Система повинна підтримувати ці відносини точними, коли брелок видається, передається, повертається, втрачається або замінюється. Це робоча процедура для команд доступу до офісів, кампусу та підрядників-а не порівняння брелоків чи посібник із закупівлі постачальників.

 

 

Один Fob, п'ять різних записів

Почніть із розділення елементів, які персонал часто поєднує в одній колонці електронної таблиці під назвою «номер картки».

Номер, надрукований на брелоку, може бути зручним інвентарним посиланням, а не його фактичним обліковим даним -з боку читача. Залежно від встановленої платформи може використовуватися код закладу, номер картки, шістнадцяткове представлення чи власне кодування. Синтекпояснення того, як працюють брелоки-контролю доступуволодіє цим питанням технічної сумісності; робочий процес передбачає, що сумісні облікові дані вже затверджено.

 

 

Окрема передача заводу від реєстрації на місці

Є дві передачі. Спочатку покупець приймає фізичну доставку відповідно до затвердженої специфікації постачальника. Потім уповноважений адміністратор реєструє або активує облікові дані для справжнього власника в-системі контролю доступу. Завершення одного не свідчить про інше.

Файл прийому-передачі від постачальника може містити посилання на партію, послідовність товару, друкований номер, затверджений електронний ідентифікатор або формат, місце призначення упаковки/сайту та розподіл якості. Постачальнику зазвичай не потрібен повний список співробітників або історія дозволів. Організація може зіставити надані облікові дані з власником пізніше у власній системі контрольованого доступу.

Для -розгортання кількох сайтів призначте одного власника простору імен нумерації/ідентифікації. Два розташування, які впорядковуються окремо, не повинні випадково створювати конфлікти облікових даних або отримувати діапазони, що збігаються, якщо ці діапазони мають бути унікальними в спільній системі. Постачальник-системи доступу або інтегратор має визначити фактичну межу унікальності.

 

 

Отримайте вантаж як контрольований запас

При отриманні необхідно надати документально підтверджену відповідь на чотири питання: що було доставлено, які електронні ідентифікатори є, який об’єкт відповідає за склад і які одиниці недоступні для видачі.

Для кожної поставки або під-партії перевірте:

• Кількість і група:картонні коробки, мішки та розміщення місць відповідають запису про упаковку.
• Посилальна цілісність:видимі номери або мітки відповідають схваленому файлу відображення, якщо він надається.
• Електронна відповідь:репрезентативні або визначені одиниці можна ідентифікувати за допомогою фактично прийнятого процесу зчитування/кодування.
• Унікальність:порівняння на рівні даних-не знаходить дублікатів у просторі імен, для якого потрібні унікальні активні облікові дані.
• Винятки:пошкоджені, нечитабельні, дубльовані або нерозпізнані одиниці поміщаються в карантин замість того, щоб додаватися до доступного запасу.

Рівні вибірки та пороги прийнятності належать до погодженої специфікації покупця; ані загальний відсоток, ані звуковий сигнал читача не є достатнім доказом для кожного проекту.

 

 

Надайте кожній ділянці зберігача запасів і межу звірки

Одна центральна команда може придбати всі брелоки, поки їх видають окремі офіси. Така домовленість потребує чітких записів зберігання, а не єдиної загальної інвентаризації.

Проста стандартна модель розрізняє:

• Центральний нерозподілений запас:придатні для використання одиниці, ще не призначені для сайту.
• Доступні запаси на сайті:придатні для використання одиниці, які фізично зберігаються названим зберігачем.
• Зарезервований запас:одиниць, відкладених для схваленого запиту, але не переданих.
• Випущені акції:фізичні облікові дані, передані власникам і відстежені в системі доступу.
• Карантинний або вилучений запас:пошкоджені, неоднозначні, відновлені-втрачені або іншим чином-невипускні одиниці.

Перекази між офісами слід реєструвати як дві пов’язані події: звільнення з місця відправлення та отримання пунктом призначення. Відправка в дорозі не має відображатися як доступна в обох місцях.

 

 

Видайте номер FOB лише після того, як ідентифікаційні дані та доступ були схвалені

Мета видачі — довести, що конкретні фізичні облікові дані було надано правильній особі та ввімкнено з правильними дозволами. Нормальний порядок:

1. Підтвердьте особу власника та авторизований запит або спонсора.
2. Виберіть доступний, не-карантинований брелок із правильного списку сайту.
3. Прочитайте або перевірте електронний ідентифікатор облікових даних за допомогою схваленого зчитувача/інструменту.
4. Пов’яжіть ці облікові дані з власником у-системі контролю доступу.
5. Застосовувати затверджений сайт, дверну групу, розклад і правила терміну дії; уникайте копіювання широких дозволів від попереднього власника.
6. Перевірте дозволений доступ і, якщо це можливо, умову відмови{0}}доступу представника.
7. Запишіть фізичну передачу, оператора видачі, підтвердження власника та ефективний статус.

Коли реєстрація програмного забезпечення централізована, адміністратор сайту може не мати привілеїв для створення дозволів. У цьому випадку робочий процес повинен вимагати підтвердження авторизації перед фізичним вивільненням брелка.

 

 

Використовуйте профіль-спеціального доступу для сайту, а не неявний глобальний дозвіл

Облікові дані з кількох-сайтів можуть розпізнаватися читачами в кількох місцях без авторизації відкривати всі двері. Визнання та дозвіл залишаються окремими рішеннями.

Визначте такі профілі, як працівник об’єкта A, підрядник об’єкта B, технічне обслуговування в неробочий час або тимчасовий відвідувач, але розглядайте їх як приклади, а не як універсальні налаштування. Кожен профіль потребує схвалення власника, дозволених дверей, розкладу, терміну дії та правила перегляду. Підрядники можуть вимагати спонсора та часові обмеження; постійний персонал може отримати дозвіл департаменту.

NIST SP 800-53 PE-2вимагає ведення списків авторизованого-доступу, видачі облікових даних, перегляду доступу та видалення людей, коли доступ більше не потрібен. Це корисна система контролю, а не заява про те, що кожен малий офіс повинен запроваджувати певну програму сертифікації NIST.

 

 

Знайте, що записувати для кожної передачі

Корисний обліковий{0}}журнал операцій базується на подіях. Він повинен повідомляти аудитору, що змінилося, хто це схвалив, хто виконав, який фоб зазнав впливу та чи була перевірена зміна.

Не розміщуйте непотрібні конфіденційні відомості про особу в електронній таблиці постачальника та не друкуйте їх на оболонці. Журнали доступу та особисті дані мають відповідати політиці конфіденційності, збереження й-контролю доступу організації.

 

 

Повідомлення про-втрату брелка викликає дві дії

Коли власник повідомляє про відсутність брелока, першочерговим завданням є вимкнути його повноваження-, щоб не чекати відправлення на заміну. По-друге, це оновлення фізичних запасів і записів про випадки.

Практичний процес втрати-фобу полягає в тому, щоб перевірити звіт, визначити точні облікові дані, призупинити або відкликати їх через-платформу керування доступом, підтвердити зміну, поширену на постраждалих сайтах, задокументувати інцидент, а потім видати нові облікові дані під окремим посиланням.Інструкції з підтримки облікових даних HIDтак само вказує операторам деактивувати відсутні облікові дані та призначити заміну.

Деякі установки доступу кешують дозволи в зчитувачах або контролерах, працюють в автономному режимі або синхронізуються між серверами. У таких випадках центральний статус «вимкнено» не може відразу підтвердити відмову в кожній двері. Інтегратор повинен визначити поведінку розповсюдження та метод перевірки. Якщо система дозволяє, перевірте відкликані облікові дані в репрезентативній контрольованій точці входу; інакше перевірте стан підтримуваного контролера або журнали.

 

 

Повернуте не те саме, що вимкнено

Працівник може розмістити брелок на стійці реєстрації, поки база-контролю доступу все ще вважає його активним. Може трапитися й зворотне: скасований брелок залишається фізично відсутнім.

Тримайте ці два виміри окремо:

Ніколи не припускайте, що видалення запису особи автоматично змінює поточний стан доступу кожного контролера чи зчитувача. Перевірте поведінку фактичної платформи.

 

 

Вирішіть, чи можна повернути брелоки повторно

Повторне використання непошкоджених брелоків може мати сенс для контрольованих-операцій із низьким тертям, але це системне-політичне рішення. Застарілий брелок LF, доступний лише для-читання, може містити незмінний ідентифікатор; оператор може змінити призначення-системи доступу без зміни чіпа, якщо програмне забезпечення підтримує цей робочий процес. У розумній системі облікових даних захищені дані програми, персоналізація та ключі можуть ускладнити або заборонити перепризначення.

Перед повторною видачею видаліть доступ колишнього власника, перевірте та прочитайте брелок, перевірте його статус у пов’язаних системах, очистіть або переналаштуйте дані-спеціальної програми, лише якщо вони підтримуються та авторизовані, створіть новий зв’язок і виконайте--тест наскрізного доступу. Якщо старі облікові дані пов’язані з інцидентом безпеки, політика організації може вимагати остаточного скасування.

Повторну видачу ніколи не слід описувати як "скидання UID". Багато облікових даних мають ідентифікатори, які не-перезаписуються; операційна зміна може відбутися лише в базі даних контролера.

 

 

Вихід має закрити всі дозволи сайту

Коли користувач залишає організацію або закінчується завдання підрядника, власник системи повинен видалити їх авторизацію, навіть якщо брелок фізично не відновлено. Для багато-об’єктів достатньо одного забутого сайту або незалежного контролера, щоб залишити прогалину в доступі.

Надайте відповідальному власнику завдання вивезення. Підтвердьте активні облікові дані власника, вимкніть усі відповідні призначення доступу, узгодьте фізичні повернення, зафіксуйте відсутні елементи та закрийте запит лише після завершення встановлених перевірок. Якщо особа має як фізичний брелок, так і мобільний обліковий запис, розглядайте їх як окремі записи облікових даних, якщо платформа не документує уніфіковану поведінку відкликання.

HIDдокументація-керування обліковими данимиілюструє, чому заміна, завершення та статус облікових даних є явними операціями життєвого циклу в системах керованої ідентифікації. Конкретні функції, доступні для звичайного розгортання -доступу до будівлі LF або HF, усе ще залежать від його власного програмного забезпечення.

 

 

Порівняйте фізичний запас із активними обліковими даними

Під час періодичного аудиту слід порівнювати принаймні три джерела: запас-сайту, реєстр призначень і активний список облікових даних-системи контролю доступу. Корисний результат – це не просто «400 брелків під рукою»; це список винятків, які потребують дії.

Шукайте активні облікові дані без затвердженого власника, припинену особу із збереженим доступом, брелок, зареєстрований як повернутий, але все ще активний, дублікати активного зіставлення, де це заборонено, відсутній інвентар на сайті, випадково зареєстрований невикористаний запас і передачі, які не отримали підтвердження призначення.

Встановіть частоту перевірки та терміни відповіді від бізнес-ризику. Підрядники з високим -оборотом можуть потребувати більш частих перевірок, ніж невеликі офіси зі стабільним персоналом. Загальний місячний або квартальний графік не може замінити узгоджену політику.

 

 

Пілотуйте весь життєвий цикл перед розгортанням

Використовуйте репрезентативні облікові дані, принаймні дві конфігурації сайту, якщо проект охоплює різні системи доступу, і тестові випадки, які здійснюють переходи, замість того, щоб просто представляти читачеві новий брелок.

Позначте помилки власником і вимогою повторного тестування. Перевірка фабрики постачальника може продемонструвати реакцію мітки та правильні дані, але не може замінити перевірку реального процесу реєстрації та дозволу організації.

 

 

Попросіть постачальника отримати чисту передачу, а не базу даних співробітників

Під час введення в експлуатацію масових брелоків RFID специфікація купівлі має визначати затверджену технологію чіпа/реєстраційних даних, посилання на сумісність зчитувача, очікуваний електронний формат даних, видиме правило нумерації, вимоги до унікального-діапазону чи відображення, групування упаковки/сайту,-процес затвердження зразка та потреби вхідної перевірки.

Оператор сайту повинен окремо контролювати ідентифікаційні дані співробітників, дозволи, схвалення випуску, відповідь на втрачений-фоб і журнали аудиту. Якщо постачальника просять попередньо-кодувати або попередньо-нумерувати, узгодьте, які саме поля йому потрібні та як оброблятимуться невідповідності. Синтекпосібник із сумісності безконтактного брелокаохоплює технічні рішення про закупівлю, а йогоКатегорія продуктів RFID-брелокзалишається комерційним власником для отримання фізичних облікових даних.

 

 

Контрольна точка – це призначення, а не брелок

Операціями брелоків із кількома-сайтами легше керувати, коли один ланцюжок залишається контрольованим:

затверджені облікові дані → отриманий запас → зберігання на сайті → перевірений власник → авторизований профіль доступу → подія життєвого циклу → підтвердження системи → звірка запасів.

Брелок, який правильно сканує, це лише початок. Видача вважається завершеною, коли його фізичний власник і електронні дозволи зареєстровані та перевірені; Повернення, заміна та видалення є завершеними, коли повноваження повноважень облікових даних і фізичний запис запасів були узгоджені.