Безпечно керуйте працівниками й ролями

Розділи користувача, роль і дозвіл

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

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

Тримай три поняття окремо. Користувач це особа, яку можна ідентифікувати, з особистими обліковими даними, мовою та активним станом. Роль групує затверджений обсяг роботи. Дозвіл дозволяє виконувати конкретні дії, наприклад читати бронювання, змінювати налаштування фінансів або керувати користувачами. Ніколи не створюй спільного користувача «приймання», оскільки дії, помилки та пізніші аудити більше не належатимуть одній особі. Признач кожного працівника до потрібного готелю та уникай отримання дозволів від іншої відповідальної особи лише для зручності. Системні ролі забезпечують підтримувану базову лінію; кастомні ролі виправдані лише стабільною операційною потребою. Задокументуй власника ролі та дату затвердження. Перед налаштуванням запиши передбачуваний набір завдань і конфіденційні виключення. Модель готова, коли керівництво може пояснити, хто ця особа, чому ця посада існує та які саме дії вона надає або забороняє, не покладаючись на неофіційну назву посади.

Плануй завдання перед дозволами

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

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

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

Переглянь системні ролі та свідомо додай власні ролі

Відкрий Налаштування → Користувачі та ролі. STRYK надає як початкові профілі Власник, Адміністратор, Рецепція та Прибирання. Переглянь опис, активний стан, призначених користувачів і дозволи модуля.

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

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

Безпечно створюй персональних користувачів

В області користувача вибери «Створити користувача» та введи повне ім’я, доступну індивідуальну електронну адресу та підготовлену роль. Надійно поділіться початковим паролем і перевір правопис електронної пошти перед збереженням.

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

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

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

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

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

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

Чисто обробляй кришку, зміни ролей і листи

Для прикриття визнач дати і конкретне додаткове завдання. Відрізняй читання документів від керування платежами та записуй, коли доступ має повернутися до нормального стану.

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

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

Регулярно переглядай та підтверджуй доступ

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

Дата запису, рецензент, зміни та наступний огляд. Hotel Nordlicht підтверджує шість особистих облікових записів, чотири операційні ролі та відсутність спільного входу.

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

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