Отделен потребител, роля и разрешение
Човек получава роля; ролята съдържа правилните разрешения за работното място.Потребителят принадлежи на едно лице с неговото име и имейл. Ролята описва работа като рецепция или домакинство. Разрешенията решават дали може да чете, пише или управлява.
Hotel Nordlicht започва с профили за управление, рецепция, домакинство и финанси. Един човек може да изпълнява няколко задачи, но все още използва един личен акаунт и най-малката подходяща роля.
Дръжте три понятия разделени. Потребителят е едно идентифицируемо лице с лични идентификационни данни, език и активно състояние. Роля групира одобрен обхват на работа. Разрешението позволява конкретно действие като четене на резервации, промяна на финансови настройки или управление на потребители. Никога не създавайте споделен потребител на „рецепция“, защото действията, грешките и по-късните одити вече няма да принадлежат на един човек. Насочете всеки служител към правилния хотел и избягвайте да носите разрешения от друга отговорност само за удобство. Системните роли осигуряват поддържана базова линия; потребителските роли са оправдани само от стабилна оперативна нужда. Документирайте собственика на ролята и датата на одобрение. Преди конфигуриране напишете планирания набор от задачи и чувствителни изключения. Моделът е готов, когато ръководството може да обясни кой е лицето, защо съществува ролята и кои точно действия предоставя или отказва, без да разчита на неофициална длъжност.
| Слой | Пример | Решение |
|---|---|---|
| Потребител | Един конкретен рецепционист | Кой влиза и притежава действието? |
| Роля | Рецепция | Каква работа изпълнява работното място? |
| разрешение | Четете и редактирайте резервации | Кои конкретни действия са необходими? |
Планирай задачите преди разрешенията
Реалният работен ден, а не менюто, определя ролята.Избройте пет до десет често срещани задачи на работно място. Рецепция работи с резервации, гости и съобщения; домакинство с дневен план; финанси с документи и плащания; управление с отчети и конфигурация.
Маркирайте дали всяка задача се нуждае от достъп за четене или запис. Разглеждането на стаи не предполага управление на наличността; разглеждането на фактури не предполага корекция на плащането. Не активирай модули „за всеки случай“.
Проектиране на достъп от задачи и риск. Избройте какво трябва да правят рецепцията, домакинството, финансите, управлението и временното покритие при нормална смяна, след което идентифицирайте най-малкия набор от данни и необходими действия. Отделно четене, създаване, редактиране, одобряване, експортиране и администриране, когато продуктът го поддържа. Обърнете специално внимание на данните за гостите, документите, плащанията, тарифите, хотелските настройки и потребителската администрация. Лице, което се нуждае от отчет, не се нуждае автоматично от права за конфигуриране; икономка, която актуализира работата в стаята, не се нуждае от финансиране за гости. Определете спешна ескалация, вместо да предоставяте на всеки потребител постоянен администраторски достъп. Обърнете внимание кои действия изискват второ одобрение или по-късен преглед. Сравни плана с реални договорености за заместване и поддръжка извън работно време. Планирането на задачи преминава, когато всяко разрешение поддържа наименуван работен поток, всяко чувствително изключване има оперативна алтернатива и не съществува привилегия единствено защото „може да е полезно някой ден“.
| работа | Трябва да е възможно | Остава блокиран |
|---|---|---|
| Рецепция | Резервации, гости, съобщения, преглед на стаята | Управление на роли и широка финансова корекция |
| Housekeeping | Дневен план и състояние на операционната зала | Цени, фактури и потребители |
| Финанси | Документи, плащания и износ | Стая и структура на ролите, когато не е собственост |
| Управление | Контрол на кръстосано свойство и одобрена конфигурация | Акаунтът на собственика е ежедневен по подразбиране за всички |
Прегледайте системните роли и съзнателно добави персонализирани роли
Ролите по подразбиране осигуряват безопасна отправна точка; операциите определят правилното ниво на детайлност.Отвори Настройки → Потребители и роли. STRYK предоставя профили на собственик, администратор, рецепция и домакинство като начални профили. Прегледайте описанието, активното състояние, присвоените потребители и разрешенията на модула.
Създай персонализирана роля само за трайна отделна работа, като финанси без конфигурация на хотел. Използвай ясно име и описание, избери необходимите модули и провери запазеното състояние.
Прегледайте съществуващите системни роли, преди да създадете персонализирана. Сравни действителните разрешения на ролята с матрицата на задачите и тествайте продуктовите области, които излага. Избери най-близката базова линия с най-малко привилегии, след което създай персонализирана роля само когато повтаряща се работа не може да бъде представена безопасно. Дайте на персонализираните роли ясни имена въз основа на отговорността, документирайте собственика им и избягвайте имена, специфични за лица, които стават безсмислени след промени в персонала. Никога не копирайте администраторска роля и премахвайте няколко видими елемента, без да тестваш скрити действия. Отвори отново запазената роля и сравни всяко разрешение. Поддържайте една канонична роля за една и съща работа вместо няколко почти идентични версии. Ако нова функция добави разрешение, прегледайте ефекта му преди широко присвояване. Дизайнът на ролята преминава, когато избраната роля поддържа всички необходими задачи, блокира несвързани чувствителни действия и остава разбираема за мениджър, който не я е създал.
Създавайте сигурно лични потребители
Акаунтът принадлежи на един човек, а не на смяна, отдел или споделен имейл.В потребителската област избери Създаване на потребител и въведи пълното име, достъпен индивидуален имейл и подготвена роля. Споделете надеждно първоначалната парола и провери правописа на имейла, преди да запазите.
Hotel Nordlicht създава отделни потребители за управление, смени на рецепцията, домакинство и финанси. Shifts могат да споделят роля, но никога акаунт.
Създай един акаунт за посочения служител, като използваш потвърден служебен имейл и правилния хотел. Задай желания език, активно състояние и одобрена роля; не конфигурирайте предварително измислени лични данни, за да изглеждат екранните снимки завършени. Осигурете адаптиране чрез одобрения поток от акаунти и изискайте от служителя да пази идентификационните данни поверителни. Никога не изпращайте споделена администраторска парола в чата и не я съхранявайте в бележка на рецепцията. Потвърди, че лицето може да влезе и се приземява на правилния наемател и език. Прегледайте потребителския запис след запазване и провери дали не е наследена нежелана роля. За повишен достъп запиши одобряващия и датата на преглед. Идентичността на павилиона е специален технически потребител, специфичен за клиента, и трябва да отваря изживяването на павилиона, а не нормалният администратор; не е заместител на сметки на служители. Създаването на потребител преминава, когато едно реално лице контролира един приписван акаунт и не трябва да се споделят идентификационни данни или роля, за да се извърши смяна.
Създаване на потребител без преки пътища
- 01Потвърди самоличността
Пълно име и индивидуален имейл.
Точно един човек - 02Задай роля
Избери подготвената роля въз основа на работата.
Няма пълен достъп до одеяло - 03Предаване на достъп
Изпратете първоначалните идентификационни данни сигурно и само на лицето.
Няма отворен списък с пароли - 04Списък за проверка
Прочетете отново името, ролята и активното състояние.
Запазеният потребител е видим
Тествайте всяка роля с положителни и отрицателни случаи
Успешното влизане доказва само паролата, а не правилния достъп.Влезте с потребител с ролеви тестове и провери положителни случаи: рецепцията достига до резервации и гости, поддържа дневния план, финансира правилния документ. Използвай маркирани тестови данни.
След това провери умишлените ограничения. Ако дадена задача липсва, промени централната роля, като използваш най-малкото необходимо разрешение, влезте отново и тествайте отново разрешените и блокираните случаи.
Тествайте всяка роля с положителни и отрицателни случаи, докато си влезли като тестов потребител. Положителните случаи доказват необходимата работа: рецепционист отваря и актуализира одобрена резервация, икономка използва споделения дневен план, потребител на финанси достига до желания документ и ръководството извършва своята разрешена конфигурация. Отрицателните случаи са също толкова важни: едни и същи потребители трябва да се провалят видимо при опит за несвързани финанси, потребителско администриране, чувствителен експорт на гости или настройки на хотел. Тествайте директна навигация, както и скрити записи в менюто; сигурността не може да разчита само на липсваща връзка. Запиши роля, действие, очакван резултат, действителен резултат и доказателства. Третирайте грешка в STRYK, която все още променя данните, като критична грешка и третирайте локално симулиран успех като невалиден. Повторно тестване след редакции на роли и след промени на материалния продукт. Роля се одобрява само когато необходимите действия са успешни, забранените действия са неуспешни от страната на сървъра и резултатът оцелява при излизане и ново влизане.
| Тип тест | Пример | Минава, когато |
|---|---|---|
| Разрешена навигация | Домакинството отваря дневен план | Площ видима и използваема |
| Позволено действие | Рецепцията редактира пробния престой | Запазването е успешно и резултатът се презарежда |
| Умишлен блок | Домакинството отваря управлението на финансите | Достъпът остава блокиран |
| Повторен тест | Промяна на ролята след ново влизане | Разрешено и блокирано отново потвърдено |
Работете чисто с капака, смяната на ролите и напускащите
Достъпът се променя с работата, а не само при следващия годишен преглед.За капак, определете дати и конкретна допълнителна задача. Разграничете четенето на документи от управлението на плащания и запиши кога достъпът трябва да се върне към нормалното.
За постоянна промяна на работата, актуализирайте личния потребител, вместо да създаваш втори акаунт. Деактивирайте напусналите до последния им ден, но запазете историята. Деактивирането на STRYK не замества пълния списък за напускане на хотела.
Обработвайте прикритието, промените в ролята и напусканията като датирани събития за достъп. За временно покритие дайте най-малката допълнителна роля за определения период, запиши одобряващ и дата на премахване и избягвайте споделянето на идентификационни данни. Когато служител смени отдела, сравни старите и новите матрици на задачи и премахнете разрешенията, които вече не са необходими, преди да добавите нови. При напускане деактивирайте незабавно личния потребител, запазете хронологията на одита и преназначете отворена оперативна собственост, като например стаи за почистване или одобрения. Не изтривайте акаунта, за да изтриете историята и не го оставяйте активен „за всеки случай“. Прегледайте активните сесии или свързания достъп, където системата го предоставя, и промени всички споделени външни идентификационни данни, които лицето законно е знаело. Тествайте заместващия служител независимо. Събитието е завършено, когато бившият потребител няма достъп до хотела, необходимата история остава приписвана, отворената работа има нов собственик и наследникът е одобрил само текущите разрешения.
Контролен списък за напускане в последния ден
- Потребителят на STRYK е деактивиран и влизането е проверено.
- Временните роли и правата за покритие са премахнати.
- Нито една споделена парола не се нуждае от преразпределение поради напускането.
- Външни системи, ключове и устройства, прегледани отделно.
Редовно преглеждайте и одобрявайте достъпа
Ролевата структура остава безопасна само докато съответства на текущия екип.Извършете кратко месечно съгласуване на екипа и пълен тримесечен преглед на ролите. Провери активни потребители, работни места, сезонен персонал, покритие, дубликати и неизползвани роли.
Дата на запис, рецензент, промени и следващ преглед. Hotel Nordlicht потвърждава шест лични акаунта, четири оперативни роли и без споделено влизане.
Изпълнявайте периодичен преглед на достъпа, като използваш списъка с активни потребители, дефиниции на роли и скорошна оперативна отговорност. За всеки потребител потвърди самоличност, статус на работа или договор, хотел, роля, повишени разрешения, последно одобрение и продължаваща бизнес нужда. Прегледайте персонализирани роли за дублиране и разрешения, добавени от нови функции. Примерни одиторски доказателства за чувствителни финанси, гости, ценообразуване и административни действия. Помолете мениджърите изрично да одобрят или премахнат достъпа; мълчанието не е одобрение. Проследявайте временни грантове след крайната им дата и неактивни акаунти, които все още остават активирани. Запиши дата на преглед, рецензент, корекции и доказателства за завършване, без да копирате ненужни лични данни във втора електронна таблица. Повтори след големи промени в персонала или продукта и на определен редовен интервал. Прегледът е завършен, когато всеки активен акаунт има настоящ собственик и причина, всяка роля е преминала своите тестове, излишният достъп е премахнат и ръководството може да проследи решението от централната система.
В края на прегледа извършете отделна проверка на наемателя: всички активни потребители трябва да имат достъп само до хотела, за който са били одобрени, а директните заявки, направени с ID на друг наемател, трябва да се провалят от страната на сървъра. Тестовият сертификат не трябва да съдържа данни за гост или парола; потребителят, ролята, хотелът, действието, очакваната забрана и времето са достатъчни. По този начин проверката за авторизация е не само на ниво меню, но също така действително проверява разделянето на данните за няколко хотела.
