Контрол на достъпа в SPanel, права и логове: Пълно ръководство (2026)
SPanel дава на хостинг акаунта два слоя на достъп за екипа. В Admin Interface можете да създавате множество администраторски акаунти, всеки ограничен единствено до страниците, от които има нужда.
В User Interface създавате подпотребители с точен набор от разрешения на ниво страница. Около това стоят двуфакторна автентикация, API токени с опционално изтичане и обхват по endpoint, както и дневници на активност, които екипът ви може да преглежда, но не може да изтрива.
Проблемът с един споделен вход
Ако управлявате целия проект сами, един вход в контролния панел върши работа. Нещата обаче стават по-сложни когато наемете разработчик за нова функционалност, дизайнер за нова тема и маркетинг мениджър, който трябва да следи неща като бюлетини, трафик и т.н.
В този момент имате общо четирима души (вие включително), които работят по един и същ сайт. Използването на едно потребителско име и парола от всички е лоша идея. На първо място, имате риск за сигурността.
Освен това е много по-добре всеки член на екипа да има достъп само до инструментите, от които се нуждае, за да си върши работата. Така няма да се притеснявате, че дизайнерът случайно ще промени DNS записите на домейна или че маркетинговият мениджър ще счупи базата данни.
С SPanel може да сте сигурни, че всеки може да си върши работата ефективно и безопасно.
Какви контроли за достъп на екипа има SPanel?
SPanel контролира достъпа на екипа на две нива.
На ниво сървър SPanel Admin Interface ви позволява да създадете повече от един администраторски акаунт (вход, който управлява хостинг акаунти, пакети и настройки на сървъра) и да ограничите всеки администратор до конкретни страници и действия. На ниво единичен акаунт SPanel User Interface позволява на собственика на акаунта да създава подпотребители (допълнителни входове към един хостинг акаунт), на всеки от които се дава точен набор от права, страница по страница.
В подкрепа на тези два слоя: двуфакторна автентикация (вход, който изисква второ доказателство освен паролата), API токени за автоматизиране на различни процеси и логове на активност, които записват какво е направил всеки. Всичко това е достъпно на всеки управляем VPS на NS1.
Идеята е да следвате политика на най-малките привилегии: дайте на всеки човек само достъпа, от който работата му се нуждае и нищо повече. Това е разликата между една изтекла парола, която компрометира целия ви акаунт, и една изтекла парола, която разкрива само една пощенска кутия.
Обхватният достъп също се намира в управлявана среда, а не на гол сървър. SShield наблюдава трафика и блокира атаки в реално време във всеки хостинг акаунт на машината, така че най-малките привилегии стават един слой от управлявана система за сигурност, а не самостоятелна настройка. Вие ограничавате до какво може да достигне една парола; платформата наблюдава какво достига до него.
Защо споделянето на един вход вреди на малкия бизнес?
Три проблема идват в комплект със споделени данни за вход и се влошават с растежа.
Губите отчетност. Ако всички влизат като един и същ потребител, няма как да знаете кой какво е направил. Когато настройка е променена и нещо се счупи, не можете да разберете дали е виновен разработчикът, асистентът или хакер, който е откраднал паролата ви.
Губите контрол. Споделеният вход е вход с пълен достъп. Асистентът, който трябва да работи само по бюлетина, може също да изтрива бази данни, да редактира DNS и да чете всяка фактура във файловия мениджър. Не е задължително да е нарочно.при споделен вход, откраднатата парола дава достъп до всичко. Имате една слаба връзка, която компрометира целия акаунт.
Губите лесното прекратяване на достъпа. Когато някой от екипа напусне, единственият начин да отмените споделена парола е да я промените и да я раздадете отново на всички, които остават. Ако пропуснете нещо имате проблем или с достъпа, или със сигурността, или и с двете.
Принципът на най-малките привилегии решава всички тези проблеми. Останалата част от това ръководство показва как SPanel ви позволява да ги приложите.
Как работят двата слоя на достъп в SPanel?
Ето една таблица илюстрираща как работи контролът на достъп и на двете нива в SPanel.
| Администраторски акаунти | Подпотребители | |
|---|---|---|
| Интерфейс | SPanel Admin Interface | SPanel User Interface |
| Обхват | На ниво сървър (всички хостинг акаунти, пакети, настройки) | Един единствен хостинг акаунт |
| За кого е | Служители, които управляват сървъра или създават акаунти | Клиенти, изпълнители, колеги по един акаунт |
| Обхванато по | Права на ниво страница за всеки админ | Разрешения на ниво страница за всеки подпотребител |
| Създава се от | Manage Admin Users | Manage Users |
Единствената реална разлика е обхватът: администраторите работят на ниво сървър, потребителите работят вътре в един акаунт. Изберете слоя, който съответства на това за коя част от проекта е отговорен човекът.
Как работят множеството администраторски акаунти в SPanel?
Администраторският акаунт е вход към SPanel Admin Interface – контролния слой на ниво сървър. SPanel поддържа повече от един и ги създавате и управлявате под Server Management → Manage Admin Users. Формата за създаване е озаглавена „Create Admin User.“
Частта, която прави това полезно, е мрежата от разрешения. Когато отворите Create Admin User, не избирате длъжност от меню. Виждате отделни отметки за страници, групирани под категории, и избирате само инструментите, до които този админ трябва да има достъп.
Категориите са Accounts Management, Server Management, Software и Cluster Management, всяка със своите страници. Само Accounts Management покрива Manage Accounts, Create a New Account, Manage SSH Access, Packages, Skeleton Directory и Manage API Tokens. Има превключвател „Full Access“ за пълен админ достъп и превключвател „Reseller Admin“ за reseller настройки.
Така служителят, който само създава нови хостинг акаунти, получава страниците за създаване на акаунти и нищо друго. Човекът, който има работа в тези акаунти достъпва само инструментите, от които има нужда.
Това са права на ниво страница за всеки админ. SPanel не разчита на предварително изградени именувани роли, които да приписвате на всеки потребител. Вие изграждате еквивалента на ръка, което прави работата ви по-прецизна.
Всичката тази функционалност е достъпна и чрез HTTP API на SPanel (listadminusers, createadminuser, updateadminpermissions, removeadminuser и други), така че агенция, която осигурява достъп на клиентите си може да го автоматизира всичко.
Как подпотребителите получават ограничен достъп до нужните инструменти?
Слезте едно ниво надолу. Подпотребителят е допълнителен вход към SPanel User Interface на същия хостинг акаунт, с точен набор от разрешения, дадени от собственика на акаунта. Създавате ги под Manage Users, достъпно от началната страница на User Interface. Формата е „Add a New User“, а полученото потребителско име следва формата <mainuser>_<subusername>.
Списъкът с права работи по същия начин като от страната на администратора, с категории, които съответстват на това, което съдържа един акаунт: Email, MariaDB Databases, Settings, Domains, Files, Tools, Software. Всяка съдържа отделни страници. Категорията Email включва Email accounts, Forwarders, Webmail, Autoresponders, SpamAssassin и Email filters. Под категорията MariaDB Databases ще намерите MySQL Databases и phpMyAdmin. Така двете най-често срещани искания, които собственик на бизнес чува, имат чисти отговори:
„Клиентът ми иска да управлява собствената си електронна поща, нищо друго.“ Създайте подпотребител, изберете страниците за email, оставете всичко останало празно. Той влиза, управлява пощенските си кутии и пренасочванията и никога не вижда файловия мениджър или DNS редактора.
„Разработчик се нуждае от достъп до базата данни за този един проект.“ Създайте подпотребител със страниците за mysql и нищо повече. Когато проектът приключи, изтрийте подпотребителя. Достъпът му е изчезнал; нищо друго по акаунта не се е променило.
Потребителските имена трябва да са между 3 и 30 буквено-цифрови знака, а паролите трябва да са поне 8 знака с поне една буква и едно число. Същият жизнен цикъл (списък, добавяне, редактиране на привилегии, смяна на парола, изтриване) е достъпен чрез API за екипи, които използват софтуер, за да автоматизират част от работата си.
Как да включите двуфакторна автентикация в SPanel?
Двуфакторната автентикация (2FA) означава, че входът изисква две неща: вашата парола и еднократен код от приложение за автентикация. Идеята е, че открадната парола сама по себе си не е достатъчна за вход. SPanel я поддържа в интерфейса и контролът за записване живее в и двата интерфейса. Функцията трябва първо да бъде активирана от менюто Server Settings в Admin Interface. Оттам собственикът на сървъра може също да наложи 2FA както за администратори, така и за потребители. След като е активирана, членовете на екипа ( администратори, потребители и подпотребители) могат да конфигурират и контролират двуфакторната автентикация от Profile Settings → „Login Security“ → „Two-Factor Authentication (2FA).“
Методът е приложение за автентикация, използващо TOTP: Google Authenticator или всяко съвместимо приложение, което генерира въртящи се шестцифрени кодове. Няма опция за SMS или email, което е правилното решение: кодовете от приложение не се прихващат по начина, по който може SMS.
Можете ли да автоматизирате достъпа на екипа с API токени?
Всичко по-горе е достъпно чрез публичния HTTP API на SPanel, автентикиран с API токен – удостоверение, което изпращате с всяка заявка вместо парола. Ако осигурявате достъп от собствените си инструменти, токените са начинът да го направите, без да хардкодвате човешки вход. Генерирате ги в Admin Interface под Manage API Tokens чрез „Create API Token.“
Токенът може да бъде стеснен по два независими начина и и двата си струва да се използват:
Опционално изтичане. Формата за създаване има превключвател за изтичане, който е изключен по подразбиране; оставете го изключен и Expiration на токена чете „Never.“ Включете го и получавате date picker. Токен, който изтича сам, е едно удостоверение по-малко, което да си спомняте да отмените.
Привилегии по endpoint. След като изберете Token Type (Admin или User), формата показва мрежа от привилегии, където всеки API endpoint има своя отметка, етикетирана с човешкото име и пътя на endpoint (например „List Accounts accounts“). Admin токените излагат 50 endpoint-а; User токените – 191. Прекият път „Unrestricted (all)“ избира всичко и това е подразбирането.
И двете ограничения са по избор. Токен, който не сте стеснили нарочно, е токен с пълен достъп от своя тип, без изтичане. С други думи, SPanel ви позволява да обхванете токен във времето и в повърхността, но трябва да изберете да го направите. За автоматизация навикът, който си струва да изградите, е да дадете на всеки токен изтичане и да отметнете само конкретните endpoint-и, които скриптът действително извиква. Базовият endpoint за всичко е /spanel/api.php, документиран в документацията на SPanel API.
Къде са логовете и можете ли да ги изтриете?
Логовете съдържат запис на всички действия, извършени в интерфейса. В SPanel тези дневници се съхраняват централно на контролния сървър, далеч от вашия собствен хостинг сървър. Можете да ги преглеждате, но не можете да ги изтривате.
Admin Interface излага Admin Activity Logs – следата от действия, с колони за времева марка, изходен IP, потребителско име на админ, предприетото действие (например „Accounts Management / Login As User“) и колона за статус.
Две неща правят това наистина полезно. Първо, записът живее централно на контролния сървър, държан отделно от средата, в която са се случили действията: дневници, съхранени извън собствената среда на клиента. Второ, записите не могат да бъдат изтрити. Така когато настройка се промени и трябва да знаете кой я е променил, има запис, който можете да прочетете, и никой не може да го изтрие.
Какво не прави SPanel
Ето списък на това, което тези функции не правят.
Няма именувани роли. SPanel има разрешения на ниво страница за всеки потребител, а не предварително зададени роли като „Billing Manager“ или „Read-Only Auditor“, които да задавате на администратори и потребители. Получавате гранулярността да изградите еквивалентния достъп на ръка; няма каталог с роли, от който да избирате.
Няма експорт или сваляне на логове. Логовете се съхраняват централно. Могат да се преглеждат, но не и да се трият. Няма SIEM, syslog или CEF feed, няма пренасочване, няма функция за изтегляне към външно хранилище.
Няма автоматично изтичащи логини. Администраторски акаунт или подпотребител не спира да работи по график; достъпът се добавя и премахва ръчно. (Изтичането на токен е отделна, реална функция; животът на токена не е същото като живота на логина.)
Ако някое от тях е задължително за вас, честният ход е да го поискате в бъдеща версия на SPanel, отидете на Cloud Democracy борда, където решението за бъдещото развитие на нашият панел се формира от гласовете на клиентите.
Как да зададете разумен базов достъп още днес?
Не е нужно да преустройвате всичко, за да получите по-голямата част от ползата. Ето базова линия, която пасва на типичен малък бизнес и отнема следобед.
- Спрете да споделяте основния вход. Решете кой наистина се нуждае от достъп на ниво сървър (обикновено само вие или водещ админ) и запазете пълния администраторски акаунт само за него.
- Дайте на сървърните служители ограничени администраторски акаунти. За всеки, който само създава акаунти или обработва поддръжка, създайте администраторски акаунт и отметнете само страниците, които работата му докосва.
- Дайте на хората на ниво акаунт подпотребители. За членове на екипа създайте подпотребители, обхванати само до техните страници: само email, само бази данни, каквото пасва.
- Включете 2FA навсякъде, където можете. Запишете собствените си входове първо, после помолете всеки колега да направи същото и потвърдете, че са го направили. Admin Interface на SPanel също ви позволява да наложите 2FA както за администраторски, така и за потребителски акаунти.
- Конфигурирайте вашите API токени. Всеки API токен получава срок на активност и само endpoint-ите, от които скриптът се нуждае. Не оставяйте настройката „Unrestricted (all)“ за токени, които са свързани с cron задачи.
- Използвайте логовете за преглед и одит. Веднъж на тримесечие и всеки път, когато някой напусне, прочетете логовете, за да видите какво се е променило и да потвърдите, че премахнатите логини са изчезнали.
Ето пример за това как изглежда една разумна настройка:
| Човек | Дайте им | Обхванато до | Никога не давайте |
|---|---|---|---|
| Вие / водещ админ | Пълен администраторски акаунт | Всичко | Нищо |
| Служител по осигуряване | Ограничен админ | Страници Accounts Management | Настройки на сървъра, firewall |
| Изпълнител по поддръжка | Ограничен админ | Само релевантни за поддръжка страници | Създаване на акаунти, SSH |
| Клиент (неговият сайт) | Подпотребител | Email или страниците, които притежава | Бази данни, файлове, DNS |
| Разработчик (един проект) | Подпотребител | File Manager, Git deployment, инструменти за база данни | Всичко останало |
| Автоматизация / инструменти | API токен | Конкретни endpoint-и, с изтичане | Неограничен, без изтичане токен |
Често задавани въпроси
В: Мога ли да имам повече от един администратор в SPanel?
О: Да. SPanel поддържа множество администраторски акаунти в Admin Interface и всеки може да бъде ограничен точно до кои страници и действия може да използва.
В: Има ли SPanel роли като „Administrator“ или „Editor“?
О: Не като именувани роли. SPanel ви дава контрол върху правата на ниво страница за всеки потребител: избирате точния набор от страници, до които всеки админ или потребител може да достигне. Това е същият контрол, който бихте използвали, за да изградите роля, приложен човек по човек, но няма предварително зададен каталог с роли.
В: Как да дам на някого достъп само до email и нищо друго?
О: Създайте подпотребител в User Interface на този акаунт, изберете страниците за email в мрежата от разрешения и оставете останалото празно. Той може да управлява пощенски кутии и пренасочвания и никога не вижда инструментите за база данни, File Manager или DNS редактора.
В: Поддържа ли SPanel двуфакторна автентикация?
О: Да. Включете я под Profile Settings → „Login Security“ → „Two-Factor Authentication (2FA)“, достъпно както в Admin, така и в User интерфейсите. Методът е приложение за автентикация (TOTP), като Google Authenticator. Няма опция за SMS или email.
В: Изтичат ли API токените на SPanel?
О: Могат. Изтичането е опционално: формата за създаване по подразбиране е „Never“ и можете да включите date picker, за да зададете едно. Отделен контрол на същата форма обхваща кои endpoint-и може да извиква токенът, така че можете да ограничите токен както по живот, така и по повърхност.
В: Къде се пазят дневниците на активност и мога ли да ги изтрия?
О: Съхраняват се централно на контролния (manage) сървър на SPanel, извън вашия собствен хостинг сървър. Можете да ги преглеждате; не можете да ги изтривате. Никъде в изгледите на дневниците няма контрол за изтриване, изчистване или прочистване.
В: Мога ли да експортирам дневниците към собствените си инструменти за сигурност?
О: В момента не. Няма експорт или стрийминг на дневници: няма интеграция със SIEM, syslog или CEF. Преглеждате дневниците вътре в SPanel.
В: Как да премахна достъпа на някого, когато напусне?
О: Изтрийте администраторския му акаунт (Admin Interface) или подпотребителя му (User Interface). Удостоверенията му спират да работят и можете да прегледате дневника на активност, за да видите какво е докоснал, докато е имал достъп.
В: Всичко това допълнителен разход ли е?
О: Не. Всяка функция за достъп на екипа тук (множество админи, подпотребители, 2FA, API токени, дневници на активност) е включена безплатно на всеки управляван VPS на NS1. Няма такса на място и няма добавка.
Настройте достъпа правилно още от първия ден
Ако вече сте на управляван VPS на NS1, всичко в това ръководство е в контролния ви панел в момента. Започнете със стъпка едно – спрете да споделяте основната парола – и работете надолу по таблицата. Ще размените една крехка парола за набор от точно конфигурирани логини, които можете да добавяте, преглеждате и премахвате един по един.
