Пайдаланушылар, шақырулар, рөлдер, 2FA, API-токендер және OIDC SSO
Бұл бөлім Qarvix-та адамдар мен интеграциялардың қолжетімділігін басқаруды сипаттайды: кімді шақыру керек, қандай рөл беру керек, 2FA қашан қосу керек, API-токендер не үшін қажет және OIDC SSO кірудi қалай орталықтандыруға көмектеседі.
Негізгі принцип: пайдаланушы тек өз тапсырмасы үшін қажетті қолжетімділікті алуы тиіс. Әкімшілік құқықтарды "сақтық үшін" бермеңіз және адамдардың есептік жазбаларын автоматты интеграциялар үшін пайдаланбаңыз.
Қысқаша
- Пайдаланушы - Qarvix панеліне кіретін адам.
- Рөл пайдаланушының не істей алатынын анықтайды.
- 2FA кіруді қосымша бір реттік кодпен қорғайды.
- API-токен адамның кіруі үшін емес, интеграциялар мен автоматтандыру үшін қажет.
- OIDC SSO корпоративтік сәйкестендіру жүйесі арқылы кіруге мүмкіндік береді.
- Мердігерлер мен уақытша инженерлердің қолжетімділігінің түсінікті шекарасы мен мерзімі болуы тиіс.
Қолжетімділік түрлері
Qarvix-та қолжетімділікті мақсатына қарай бөлген пайдалы.
| Қолжетімділік түрі | Кімге арналған | Не маңызды |
|---|---|---|
| Әкімшілік | контур иелері, аға инженерлер | толық бақылау, міндетті 2FA |
| Пайдалану | сервистік команда, NOC, инженерлер | тек қажетті нысандар мен журналдарға қолжетімділік |
| Уақытша | мердігерлер, монтажшылар, интеграторлар | жұмыс аясы мен мерзімін шектеу |
| Бақылау | басшылар, клиент тарапы | статустарды, есептер мен журналдарды баптауларды өзгертпей қарау |
| Интеграциялық | мониторинг, биллинг, сыртқы жүйе | ең аз құқығы бар API-токен |
Адам маршруттарды, ACL-ды немесе пайдаланушыларды өзгертпеуі тиіс болса, оған әкімшілік рөл қажет емес.
Пайдаланушылар
Пайдаланушы нақты бір адамды білдіреді. Әртүрлі адамдар жұмыс істейтін болса, support, engineer немесе admin2 сияқты ортақ есептік жазбалар жасау ұсынылмайды.
Жеке есептік жазбалар мынаған нақты жауап береді:
- құрылғыны кім жасады;
- қосылым токенін кім берді;
- маршрутты кім өзгертті;
- ACL-ды кім қосты немесе өшірді;
- нысанға қолжетімділікті кім алды;
- жұмыстан босатылған немесе жұмыс аяқталған кезде кімді ажырату керек.
Командалық жұмыс қажет болса, ортақ логин емес, рөлдерді пайдаланыңыз.
Пайдаланушыны шақыру
Шақырудан бұрын анықтаңыз:
- пайдаланушы қай ұйымға жатады;
- оған қай желілерге қолжетімділік қажет;
- ол баптауларды өзгертуі керек пе, әлде тек қарауы керек пе;
- журналдар мен есептерге қолжетімділік қажет пе;
- қолжетімділік тұрақты ма, әлде уақытша ма;
- production-контурға жіберер алдында 2FA қажет пе.
Шақырғаннан кейін пайдаланушының тек қажетті ұйымдарды, желілер мен құрылғыларды көретінін тексеріңіз.
Рөлдер
Рөлдер нақты міндеттерді көрсетуі тиіс.
Типтік модель:
| Рөл | Мақсаты |
|---|---|
| Ұйым иесі | ұйымды, пайдаланушыларды, лицензияны және жалпы баптауларды басқарады |
| Әкімші | желілер, құрылғылар, қолжетімділік ережелері, маршруттар мен токендер жасайды |
| Инженер | құрылғыларды қосады, статустарды тексереді, журналдармен жұмыс істейді |
| Бақылаушы | конфигурацияны өзгертпей статустарды, есептер мен журналдарды көреді |
| Интеграция | шектеулі сценарий шеңберінде API-ге жүгінеді |
Интерфейстегі рөл атаулары әртүрлі болуы мүмкін, бірақ мағынасы бір болуы тиіс: рөл қолжетімділік пен желілерді басқаруға жақындаған сайын, қауіпсіздік талаптары соғұрлым қатаң болады.
Ең аз құқық принципі
Ең аз құқық дегеніміз - пайдаланушыға тек жұмыс үшін қажетті әрекеттер мен нысандарға ғана қолжетімділік беру.
Мысалдар:
- камера инженеріне, бір ғана нысанға қызмет көрсетсе, барлық филиалға қолжетімділік қажет емес;
- мердігерге басқа пайдаланушыларды шақыру мүмкіндігі қажет емес;
- мониторинг есептік жазбасына ACL-ды өзгертуге қолжетімділік қажет емес;
- басшыға көбіне есептер мен статустарды көру керек, желілерді өзгерту емес;
- монтажшыға жұмыс уақытында нақты нысанға ғана шектеулі қолжетімділік керек.
Мұндай тәсіл кездейсоқ өзгерістер қаупін төмендетеді және оқиғаларды тексеруді жеңілдетеді.
2FA
2FA - кірудің екі факторлы қорғанысы. Құпия сөзден бөлек пайдаланушы қосымшадан немесе басқа екінші фактордан алынған бір реттік кодпен кіруді растайды.
2FA әсіресе мыналар үшін маңызды:
- ұйым иелері;
- әкімшілер;
- қосылым токендерін жасайтын пайдаланушылар;
- бірнеше клиентке қолжетімділігі бар қызметкерлер;
- маршруттарға, ACL мен журналдарға қолжетімді есептік жазбалар.
Пайдаланушының құпия сөзі ұрланса, 2FA екінші фактор болмаса панельге кіру қаупін төмендетеді.
Ұсыныс: барлық әкімшілік рөлдер мен production-нысандарымен жұмыс істейтін сервистік командалар үшін 2FA қосу.
API-токендер
API-токен Qarvix-қа бағдарламалық қолжетімділік үшін пайдаланылады. Бұл пайдаланушының құпия сөзінің орнын басатын нәрсе де, командаға "ортақ кіру" беру тәсілі де емес.
API-токендер мыналарға қолайлы:
- құрылғылар статусын бақылауға;
- есептерге арналған деректерді түсіруге;
- ішкі есеп жүйесімен интеграциялауға;
- нысандарды автоматты жасауға немесе тексеруге;
- жеке сценарий шеңберінде туннель арқылы құрылғылар API-іне қолжетімділікке.
API-токен үшін мыналарды белгілеу маңызды:
- түсінікті ат;
- иесі немесе жауапты жүйе;
- ең аз құқықтар;
- токен уақытша болса, қолданылу мерзімі;
- қайтарып алу процедурасы;
- токен қайда пайдаланылатыны туралы сипаттама.
API-токендерді ортақ чаттарда, қолжетімділігі бақыланбайтын құжаттарда немесе жалпыға ортақ репозиторийлерге түсетін кодта сақтамаңыз.
OIDC SSO
OIDC SSO - корпоративтік сәйкестендіру жүйесі арқылы кіру. Пайдаланушы Qarvix-қа жеке жергілікті құпия сөзбен емес, компанияда бұрыннан қабылданған есептік жазба арқылы кіреді.
OIDC SSO мына жағдайларда пайдалы:
- компанияда бірыңғай кіру бұрыннан бар;
- қызметкерлерді орталықтан ажырату керек;
- бірыңғай MFA/2FA саясаты қажет;
- пайдаланушылар көп болып, қолмен шақыру ыңғайсыз бола бастады;
- жеке құпия сөздер санын азайту керек;
- қолжетімділік корпоративтік топтарға сәйкес келуі тиіс.
SSO әдетте қосылатын жүйелердің мысалдары: Keycloak, Microsoft Entra ID, Okta, Authentik және басқа OIDC-провайдерлер.
SSO қосар алдында мыналарды келісіңіз:
- OIDC-провайдердің әкімшісі кім;
- қандай топтар Qarvix-қа қолжетімділік алады;
- топтар рөлдерге қалай сәйкестендіріледі;
- қызметкер жұмыстан шыққанда не болады;
- SSO істен шыққан жағдайға арналған жергілікті әкімшілік қолжетімділік сақтала ма.
Мердігерлер қолжетімділігі
Мердігерлер мен уақытша инженерлер тек жұмыс уақытына және тек қажетті аймаққа қолжетімділік алуы тиіс.
Қолжетімділік бермес бұрын белгілеңіз:
- қолжетімділікті кім сұрады;
- қай нысанға немесе желіге қолжетімділік қажет;
- қандай әрекеттерге рұқсат етілген;
- LAN-ішкі желіге қолжетімділік қажет пе, әлде тек роутерге ме;
- қолжетімділік қашан қайтарылып алынуы тиіс;
- жұмыс нәтижесін кім тексереді.
Жұмыс аяқталғаннан кейін аудит журналын тексеріп, артық құқықтарды қайтарып алыңыз.
Қолжетімділікті қайтарып алу
Қолжетімділікті қайтарып алу тек жұмыстан босатылған кезде ғана қажет емес. Мұны мердігерлік жұмыстар аяқталғанда, қызметкердің рөлі өзгергенде, пилот аяқталғанда немесе нысан басқа командаға берілгенде де жасаған дұрыс.
Тексеру тәртібі:
- пайдаланушыны ұйымнан ажыратыңыз немесе өшіріңіз;
- уақытша рөлдерді қайтарып алыңыз;
- осы пайдаланушы жасаған API-токендерді тексеріңіз;
- пайдаланушыда әлі пайдаланылып жатқан статикалық клиенттердің жоқтығына көз жеткізіңіз;
- жұмыс кезеңі бойынша аудит журналын тексеріңіз;
- нысанға жауаптылар тізімін жаңартыңыз.
OIDC SSO пайдаланылса, пайдаланушыны корпоративтік жүйеде ажырату Qarvix-қа кіруді бұғаттауы тиіс. Бірақ жергілікті токендер мен статикалық клиенттерді бәрібір жеке тексеру керек.
Туннель арқылы құрылғылар API-іне қолжетімділік
Роутер артындағы құрылғылар API-іне қолжетімділік мониторинг пен интеграциялар үшін ыңғайлы болуы мүмкін, бірақ оны шектеусіз барлық пайдаланушыға ашуға болмайды.
Мұндай қолжетімділікті бермес бұрын анықтаңыз:
- API-ге кім жүгінеді;
- қай құрылғыға немесе ішкі желіге;
- қандай хаттама мен порт пайдаланылады;
- тұрақты қолжетімділік керек пе, әлде уақытша ма;
- әрекеттер есепке немесе журналға түсуі тиіс пе;
- қолжетімділікті жеке маршрутпен немесе ACL-мен шектеуге бола ма.
Мысалы, мониторинг сервисі туннель арқылы датчиктерден деректер ала алады, бірақ Qarvix панеліне әкімшілік қолжетімділігі болмауы тиіс.
Журналдар және бақылау
Қолжетімділікті басқару үшін екі із түрі маңызды:
- аудит журналы панельдегі пайдаланушы әрекеттерін көрсетеді;
- құрылғы журналдары қосылым, конфигурация және құрылғы күйінің оқиғаларын көрсетеді.
Мына жағдайлардан кейін журналдарды тексеріңіз:
- жаңа пайдаланушыны шақырғаннан кейін;
- әкімшілік рөл бергеннен кейін;
- API-токен жасағаннан кейін;
- ACL өзгерткеннен кейін;
- мердігерге қолжетімділік бергеннен кейін;
- нысандағы жұмыс аяқталғаннан кейін.
Осылай қолжетімділікті кім және қашан өзгерткенін дәлелдеу және оқиғаларды жылдам талдау оңайырақ болады.
Практикалық ұсыныстар
- Адамдар үшін ортақ есептік жазбаларды пайдаланбаңыз.
- Әкімшілер үшін 2FA қосыңыз.
- Қызметкерлердің, мердігерлердің және интеграциялардың қолжетімділігін бөліңіз.
- API-токендерді тек нақты тапсырма үшін беріңіз.
- Пайдаланушыларды, рөлдер мен токендерді жүйелі тексеріп тұрыңыз.
- Бірнеше клиент үшін жеке ұйымдарды пайдаланыңыз.
- Production-контурлар үшін рөлдер моделін алдын ала келісіңіз.
- Жұмыс аяқталғаннан кейін уақытша қолжетімділікті қайтарып алыңыз.
Бақылау тізімі
- Әрбір пайдаланушыда жеке есептік жазба бар.
- Әкімшілер 2FA пайдаланады.
- Мердігерлерде артық құқық жоқ.
- API-токендер түсінікті аталған және иесі бар.
- Уақытша қолжетімділіктің тексеру мерзімі бар.
- Рөлдер нақты міндеттерге сәйкес келеді.
- Пайдаланушы тек қажетті ұйымдар мен желілерді көреді.
- LAN/API-ге қолжетімділік ережелермен шектелген.
- Аудит журналында негізгі өзгерістер көрінеді.
- Қолжетімділікті қайтарып алу процедурасы бар.
Байланысты бөлімдер
- Ұйымдар мен желілер - иелену мен есептіліктің шекаралары қайда белгіленеді.
- Құрылғылар және VPN-мекенжайлар - пайдаланушылар мен клиенттер желіде қалай пайда болады.
- Желілер, маршруттар және ACL - қолжетімділікті техникалық ережелермен қалай шектеу керек.
- Туннель арқылы құрылғылар API-і - жергілікті API-ді қауіпсіз қалай ашу керек.
- Журналдар мен есептер - пайдаланушы әрекеттері мен оқиғаларды қайдан тексеру керек.